<div dir="ltr"><div><div><div><div><div><div><div><div><div>I have recently come across an.. inadequacy lets call it, in gstreamer, and am uncertain of how to go about handling it. Basically, nothing is able to handle 0x0 video frames, (ie, no content) despite my finding out that I have a corner case in which I need such a thing.<br>
<br></div>I am working on video wall code, and the user is allowed a large latitude in setting up how the incoming video is processed and displayed on a wall. <br><br></div>In particular, I've had complaints from the field that if someone sets up a row of three monitors, and asks to play a movie, the video wall will sometimes crash. (ie, exit with a "not-negotiated" error). It turns out that this happens when the aspect ratio of the movie is the same as a monitor and the scaling has been set to add black bars so as not to lose any video.<br>
<br></div>In this case we end up calculating (for example) that the 1920x1080 movie will take up the 1920x1080 pixels of the central monitor, and that each of the side monitors should be cropped to 0x1080 by videocrop and then expanded to 1920x1080 by adding borders by videobox.<br>
<br></div>Naturally, videocrop refuses to output a 0x1080 frame of video, and even if it did, videobox refuses to take a 0x1080 video to expand with borders.<br><br></div>This is a natural consequence of our decision (for performance reasons) to have our video wall pipeline first tee an incoming video for each output monitor, and then individually crop, add borders, and scale the individual outputs on a case-by-case basis.<br>
<br></div>We could re-arrange the pipeline to do the cropping and borders first, but tests have showed that asking videobox, for instance, to expand a 1920x1080 video to 5760x1080 with borders is quite slow, and we'd lose much of the performance we have doing it the current way.<br>
<br></div>So, now I'm scrambling to figure out how to elegantly handle the obscure case when I discover I need to generate a monitor's worth of pure 'border'.<br><br></div>I'm also wondering if it would be too much to ask that gstreamer consider adding a null-frame case to its video handling so that frames with one (or both) dimensions being zero could be handled and negotiated. For the vast majority of video elements, such frames would be absolutely trivial to deal with, and future users wouldn't have to jump through hoops to handle the kind of special case I now have to deal with.<br>
<br></div>Oh, and BTW, my first impulse was to just fudge the calculations so that no monitor ever shows less than one pixel, but 1x1 video frames often generate internal errors on elements, so that idea is ruled out too...<br>
<br clear="all"><div><div><div><div><div><div><div><div><div><div><div><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></div></div></div></div></div></div></div></div></div>