A Smarter Decodebin?

[Stirling Westrup]

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?



-- 
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/20140228/34c8f89e/attachment.html>