videomixer with videotestsrc and udpsrc

[filnet]

Tim Müller wrote
>> Might be worth looking at the compositor element (as a replacement for
>> the videomixer) which is now in git master. I think I read somewhere
>> that it is supposed to replace the videomixer in the future. 
>> 
>> 
>> If someone could explain the differences between the compositor and
>> videomixer it would be great. Just from the description I cannot
>> understand between both. 
> 
> One of the key differences is that compositor is designed to work
> properly with live input (such as from udpsrc). If you have multiple
> inputs and one of them doesn't produce data (e.g. because of signal loss
> or packet loss), it can still continue to output something instead of
> waiting forever.
> 
> There are many other differences as well, like handling re-negotiation
> of inputs better, it can convert and scale inputs on the fly if needed.

Thanks Sérgio and Tim, thanks to your input, I made huge progress.

The pipeline is now like this:

compositor name=mixer ! videoconvert ! autovideosink
videotestsrc ! video/x-raw, width=320, height=240, framerate=20/1 ! mixer.
udpsrc port=9000 ! textrender halignment=left ! video/x-raw, width=320,
height=120 ! videorate ! video/x-raw, framerate=10/1 ! mixer.

It works as advertised with some glitches (more about them later...).
It works with master branch on linux. I could not test master on windows as
it currently does not compile.
Compositor is also available in the 1.4 branch but it seems to have the same
shortcomings as videomixer.

The glitches are:
- still need to send two upd packets to get it started
- once started, the videosink will emit a number of qos event while dropping
the accumulated videotestsrc frames
- but, good news, the pipeline will then run on as expected :)

The videorate element is retaining one frame. In other words it is always
producing the N-1 frame.
That is why you need to send two packets to get the pipeline started and
why, later on, the pipeline will always display the 2nd last textrender
frame.

Setting drop-only=true on the videorate element improves the situation:
- the pipeline starts when receiving the 1st udp packet
- further udp packets are displayed immediately
With that change, my understanding is that the videorate element will not
duplicate frames. So it is strange that the compositor still displays the
textrender output. I guess the compositor repeats the last frame received
(?).

So I almost have the desired behavior.
All I am missing at this stage is how to start the pipeline right away
without the need to send a 1st udp packet.
Is there a way to achieve that?

Cheers,
Philippe.

PS : this is how I send packet to the udpsrc should someone want to test
this pipeline.

On linux : echo -n 'Hello' | nc -4u -w1 127.0.0.1 9000

On windows : you'll need to download one of the packet sender utilities
available on the net.





--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/videomixer-with-videotestsrc-and-udpsrc-tp4671726p4671771.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.