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

[Stirling Westrup]

Duh, the obvious solution just occurred to me, and so far seems to work.
The problem I was having stemmed from having a pipeline like this:

... tee ! videocrop ! videobox ! videoscale ! xvimagesink

If videocrop was asked to remove all of a frame, videobox would not have
anything to add borders to, and the pipeline would fail.

While looking through the element documentation for a solution, I
rediscovered that videobox is supposed to be able to do both cropping AND
border padding. I say "supposed" because when I wrote the first version of
the videowall for gstreamer 1.0.3, videobox had many bugs that prevented us
using its cropping features, and which resulted in our adding videocrop to
the pipeline. However, I think that much bug fixing has occurred since
then, and we're going to give videobox a chance to redeem itself.



On Tue, Jun 17, 2014 at 6:26 PM, Louis Simons <lousimons at gmail.com> wrote:

> On Tue, Jun 17, 2014 at 2:16 PM, Stirling Westrup <swestrup at gmail.com>
> wrote:
>
>> On Tue, Jun 17, 2014 at 1:47 PM, Andrew Burgess <aab at cichlid.com> wrote:
>>
>>> i am a total noobie at this but how about writing a pipeline element
>>> that converts zero dimension frames to max dimension (instead of 1x1)
>>> and make them black?
>>>
>>> I can't even *make* zero dimension frames without breaking gstreamer,
>> but the idea of an element which just generates blank backgrounds of an
>> appropriate size and color had occurred to me (I might not even need to
>> write it. It may be doable with existing elements).
>>
>> The trouble is, I would need to dynamically arrange to have this element
>> added and removed from a working pipeline as the user adjusts his
>> configuration, such as by changing how scaling is done. Doing that in a
>> neat and clean way would be a real pain.
>>
>
> To avoid the adding and removing, I've been using the intervideosrc/sink
> elements to get blank (black) frames downstream when parts of a pipeline
> are being modified.  I don't think it's the most gstreamer way of doing
> things, but it has sort-of worked.  I may hit a performance bottleneck down
> the road, though.
>
>


-- 
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/20140619/44f74fb8/attachment.html>