<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 1, 2014 at 10:19 AM, Sebastian Dröge <span dir="ltr"><<a href="mailto:sebastian@centricular.com" target="_blank">sebastian@centricular.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Fr, 2014-02-28 at 17:29 -0500, Stirling Westrup wrote:<br>
> We have a gstreamer application for dealing with UHD video content. Lately<br>
> we've been working with gstreamer-vaapi and updating vaapidecode to work<br>
> with version 1.2 of gstreamer. We've given vaapidecode a very high rank, so<br>
> it will be chosen first, and it does a test for vaapi compatible hardware<br>
> in its init function and returns true or false accordingly. This is all<br>
> working fine.<br>
><br>
> However, we now have run into an issue farther along in the video pipeline.<br>
> We're using decodebin to decode incoming videos so we won't have to<br>
> implement our own type-finding system. It will successfully start using<br>
> vaapidecode if the hardware is available. So far so good. However, the<br>
> earliest vaapi hardware cannot support videos higher than 1920x1080, so we<br>
> 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<br>
> have decodebin replace us with a lower-ranked software implementation that<br>
> CAN work with the content (albeit much slower). Of course, we currently<br>
> only learn how big the frames are we'll be expected to decode during caps<br>
> negotiation, and if we fail negotiation at that point, decodebin just gives<br>
> up, rather than replacing our element.<br>
><br>
> Are we missing a trick here, or is our only option to modify decodebin (or<br>
> write our own) to have some smarter fallback system in place?<br>
<br>
</div>You could put the resolution restrictions into the sinkpad template caps<br>
of the decoder. Having width=[1,1920],height=[1,1080] in there should<br>
cause decodebin to skip it for higher resolutions.<br></blockquote><div><br></div><div>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.<br>
 <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
And the resolution information is fortunately available to decodebin<br>
before plugging the decoder because of the demuxer (most of the time) or<br>
in the worst case the parser.<br></blockquote><div><br></div><div>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...<br>
</div><div><br>-- <br></div></div>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>