A Smarter Decodebin?

Stirling Westrup swestrup at gmail.com
Mon Mar 3 08:41:59 PST 2014


On Sat, Mar 1, 2014 at 10:19 AM, Sebastian Dröge
<sebastian at centricular.com>wrote:

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

This was the first thing we tried. We hard coded the sinkpad template caps
to width=320,height=240, and we still ended up being used by decodebin.


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

In our experiments, we've never had resolution caps available from the
demuxer. I wonder if its just the set of videos we are using for testing...

-- 
Stirling Westrup
Programmer, Entrepreneur.
https://www.linkedin.com/e/fpf/77228
http://www.linkedin.com/in/swestrup
http://technaut.livejournal.com
http://sourceforge.net/users/stirlingwestrup
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140303/7bc7c59d/attachment.html>


More information about the gstreamer-devel mailing list