<div dir="ltr"><div>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.<br>
<br>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.<br>
<br>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.<br>
<br></div>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?<br><div><div><br><br clear="all"><div><br>-- <br>Stirling Westrup<br>Programmer, Entrepreneur.<br>
<a href="https://www.linkedin.com/e/fpf/77228" target="_blank">https://www.linkedin.com/e/fpf/77228</a><br><a href="http://www.linkedin.com/in/swestrup" target="_blank">http://www.linkedin.com/in/swestrup</a><br><a href="http://technaut.livejournal.com" target="_blank">http://technaut.livejournal.com</a><br>
<a href="http://sourceforge.net/users/stirlingwestrup" target="_blank">http://sourceforge.net/users/stirlingwestrup</a>
</div></div></div></div>