[gstreamer-bugs] [Bug 625722] New: new plugin: cheeseeffects

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=625722
  GStreamer | gst-plugins-bad | unspecified

           Summary: new plugin: cheeseeffects
    Classification: Desktop
           Product: GStreamer
           Version: unspecified
        OS/Version: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: fargiolas at gnome.org
         QAContact: gstreamer-bugs at lists.sourceforge.net
      GNOME target: ---
     GNOME version: ---


Hi, I'd like to propose for inclusion a new set of video filters meant for
use with camera applications like Cheese and Empathy.

It's an almost straightforward port of gleffects (from gst-plugins-gl)
distortion (and maybe some of the lut mapping ones, e.g. heat and sepia,
soon) filters to GstVideoFilter.

The rationale behind this port is that gst-plugins-gl support in Cheese is
still far away to be done, even farther now that we're moving to a Clutter
based UI because sharing texture data between different threads is still
tricky. This will eventually become easier when GPU data will be a first
class citizen in the gstreamer pipeline (when Benjamin's plan of taking
over the world will succeed).

Meanwhile, this filter set works around the issue porting some of the
effects from gst-gl to work on the cpu so that they are immediately (well,
if and when you will accept them :-P) usable from Cheese.
It also enables a wider range of setups to use the filters (no need for
modern graphic hardware).

Implementation wise, all filters share almost the same code, they fill a
distortion map in set_caps with a pair of transformed coordinates for each
source pixel and then fill the dest buffer with source pixels sampled at
coords from the distortion map.

Given that the transformed pixel could fall at fractional coordinates all
the filters but "cheesemirror" (which doesn't need it because it gives
exact results with integer math) provide two interpolation methods:
- nearest-neighbour: the dest pixel is taken to be the nearest one in src
  buffer to the fractional transformed coords
- bilinear: the dest pixel is calculated from a weighted average of the 4
  pixels in the neighbourhood of the fractional transformed coords

Transformed coords are stored in fixed point into 32bit integers with 8
bits for the fractional part. This turned out to be faster than floating
point for bilinear interpolation. 

Bilinear interpolation is still slow enough to make the filters drop
frames in my netbook (with 640x480 at 30fps webcam video) so nearest-neighbor
is enabled by default. It could probably use some optimization love, it
seems the kind of thing orc could improve a lot (if anyone wants to step
in any help is welcome).

Plugin's name and cheese namespace seemed the most obvious ones, if you
have better ideas please suggest.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.