A Smarter Decodebin?

[Stirling Westrup]

We're working with gstreamer 1.2 as our target, so that's what we did the
tests on. I'll see if I can't produce a debug log and file a bug report.


On Mon, Mar 3, 2014 at 1:57 PM, Sebastian Dröge
<sebastian at centricular.com>wrote:

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



-- 
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/20140304/cb6f0db9/attachment.html>