[Bug 722686] omxvideodec: integrate resize component

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #23 from Sebastian Dröge (slomo) <slomo at coaxion.net> 2014-04-09 07:39:56 UTC ---
(In reply to comment #20)
> 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).

Yes, that would be better. So let's WONTFIX this bug here?

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

Going from the element factory classification should be enough. Just needs to
be implemented, and especially need to autoplug a converter that handles the
relevant caps.

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

Also acceptable, but 1) should definitely be implemented.

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

I think egl_render would be good to keep inside the decoder. It's uncommon that
this is a separate component (other OMX implementations just allow
OMX_UseEGLImage() on the decoder ports) and adding generic autoplugging support
for that seems unlikely to happen.

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