A Smarter Decodebin?

[Sebastian Dröge]

On Mo, 2014-03-03 at 11:41 -0500, Stirling Westrup wrote:
> 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.

Are you using GStreamer 0.10 or 1.x? If the latter, could you get a
debug log with that? That would basically mean you found a case where
unsupported caps are configured on your decoder... which must not
happen.

If it's 0.10... well, it's a known limitation of 0.10.

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

Well, then the parser should extract that information before the
decoder :) Not all container formats always provide this information.

-- 
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/20140303/08d6fe24/attachment.pgp>