[Bug 722686] omxvideodec: integrate resize component

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=722686
  GStreamer | gst-omx | git

--- Comment #20 from Julien Isorce <julien.isorce at gmail.com> 2014-03-26 12:46:34 UTC ---
As the plan is to add tunnelling support
https://bugzilla.gnome.org/show_bug.cgi?id=726325, I think OMX.broadcom.resize
should be put in its one gstelement (omxcolorscale ? as it does scaling and
colorspace conversion).

But then what about using it automatically through playbin ? I am thinking
about 2 solutions:

1 * selectable videoscale / videoconvert based on ranks:
http://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/gst/playback/gstplaysinkvideoconvert.c#n63
Does it require to have a GstBaseVideoScale base class ?
So that playbin can use the most ranked scaler element.

2 * having a omxvideodecbin  that is a GstBin with omxvideodec and
omxcolorscale in-there and linked together. (This way videoconvert ! videoscale
will work in passthrough)

3 * using current "video-sink" property of playbin and just doing manually:
video-sink="omxcolorscale ! videosink"

What do you think ? Other ideas ? Same questions about OMX.broadcom.egl_render.

In the mean time to have tunnelling support what do you think about pushing the
attached patch ? (I'll soon rebase it on current master)

Because it's confined in  "#if defined (USE_OMX_TARGET_RPI)" blocks so that
when tunnelling will be there it will not be difficult to remove it
(considering the on going dev during this time frame).

-- 
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.