A Smarter Decodebin?

Sebastian Dröge sebastian at centricular.com
Sat Mar 1 07:19:08 PST 2014


On Fr, 2014-02-28 at 17:29 -0500, Stirling Westrup wrote:
> We have a gstreamer application for dealing with UHD video content. Lately
> we've been working with gstreamer-vaapi and updating vaapidecode to work
> with version 1.2 of gstreamer. We've given vaapidecode a very high rank, so
> it will be chosen first, and it does a test for vaapi compatible hardware
> in its init function and returns true or false accordingly. This is all
> working fine.
> 
> However, we now have run into an issue farther along in the video pipeline.
> We're using decodebin to decode incoming videos so we won't have to
> implement our own type-finding system. It will successfully start using
> vaapidecode if the hardware is available. So far so good. However, the
> earliest vaapi hardware cannot support videos higher than 1920x1080, so we
> can find the hardware overloaded in a UHD environment and be unable to work.
> 
> Ideally, in this situation we'd like to somehow bow out of the pipeline and
> have decodebin replace us with a lower-ranked software implementation that
> CAN work with the content (albeit much slower). Of course, we currently
> only learn how big the frames are we'll be expected to decode during caps
> negotiation, and if we fail negotiation at that point, decodebin just gives
> up, rather than replacing our element.
> 
> Are we missing a trick here, or is our only option to modify decodebin (or
> write our own) to have some smarter fallback system in place?

You could put the resolution restrictions into the sinkpad template caps
of the decoder. Having width=[1,1920],height=[1,1080] in there should
cause decodebin to skip it for higher resolutions.

And the resolution information is fortunately available to decodebin
before plugging the decoder because of the demuxer (most of the time) or
in the worst case the parser.

-- 
Sebastian Dröge, Centricular Ltd - http://www.centricular.com
Expertise, Straight from the Source
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140301/5efba19f/attachment.pgp>


More information about the gstreamer-devel mailing list