Bug? Feature? Dream? I need null-frame support.

[Stirling Westrup]

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.

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.

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.

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.

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.

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.

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.

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'.

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.

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...


-- 
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/20140617/9f71f521/attachment.html>