<div dir="ltr">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. </div><div class="gmail_extra"> <div class="gmail_quote"> On Mon, Mar 3, 2014 at 1:57 PM, Sebastian Dröge <<a href="mailto:sebastian@centricular.com" target="_blank">sebastian@centricular.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="HOEnZb"><div class="h5">On Mo, 2014-03-03 at 11:41 -0500, Stirling Westrup wrote: > On Sat, Mar 1, 2014 at 10:19 AM, Sebastian Dröge > <<a href="mailto:sebastian@centricular.com">sebastian@centricular.com</a>>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. </div></div>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. <div class=""> > > 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... </div>Well, then the parser should extract that information before the decoder :) Not all container formats always provide this information. <div class="HOEnZb"><div class="h5"> -- Sebastian Dröge, Centricular Ltd - <a href="http://www.centricular.com" target="_blank">http://www.centricular.com</a> Expertise, Straight from the Source </div></div></blockquote></div> -- Stirling Westrup Programmer, Entrepreneur. <a href="https://www.linkedin.com/e/fpf/77228" target="_blank">https://www.linkedin.com/e/fpf/77228</a> <a href="http://www.linkedin.com/in/swestrup" target="_blank">http://www.linkedin.com/in/swestrup</a> <a href="http://technaut.livejournal.com" target="_blank">http://technaut.livejournal.com</a> <a href="http://sourceforge.net/users/stirlingwestrup" target="_blank">http://sourceforge.net/users/stirlingwestrup</a> </div>