videomixer problems

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view

videomixer problems

Krzysztof Borowczyk

I'm trying to create a pipeline that gets video from a source, splits the
stream into parallel branches, do some (different) processing on each branch
and mix them side by side into single sink.
The most basic version in gst-launch syntax looks like this:

gst-launch-1.0 filesrc location="big_buck_bunny_480p_surround-fix.avi" !
decodebin ! \
tee name=t ! queue ! mix.sink_0 \
t. ! queue ! mix.sink_1 \
videomixer name=mix sink_1::xpos=1500 ! autovideosink

It  works from the command line.

In the code I add the branch dynamically after some seconds of playback. The
pipeline worked OK when the branch was playing to filesink (so I got the tee
element right). When I replaced filesink with videomixer the playback hangs.
I narrowed the freeze cause to the request_pad call:

GstPad* mixPad = gst_element_request_pad(mixerElement, mixerTemplate, NULL,

If I comment this line out the playback does not stop (of course it does not
work as expected, the branch is not linked to the pipeline).

The branch is set to state PAUSED before adding it to the pipeline, when all
the linking is finished I call:


on the branch bin.
Can you point me to the possible causes of this freeze? What might I forget?

Best regards,
Krzysztof Borowczyk

gstreamer-devel mailing list
[hidden email]
Reply | Threaded
Open this post in threaded view

Re: videomixer problems

Lautaro Woites

2014-02-17 12:59 GMT-03:00 Krzysztof Borowczyk <[hidden email]>:

I had some trouble with videomixer and dynamic releasing of pads. Maybe is similar to your case.
My pipe is a videomixer with 2 filesrc inputs. When I change one of the inputs, the pipeline freezes because of deadlock (this occurs sometimes).
Tracing the videomixer and collectpads code I found that the deadlock was produced by the chain function of one of the sinks (on collectpads.c) and the release_request_pad code on the other sink_pad (on videomixer.c).

I don't remember exactly theĀ  code but the problem occurs when this sequence succeeds:

1) gst_collect_pads_chain function acquires GST_COLLECT_PADS_STREAM_LOCK.
2) gst_videomixer2_release_pad function acquires GST_VIDEO_MIXER2_LOCK.
2 )gst_collect_pads_chain function calls to gst_videomixer2_collected() function.
3) gst_videomixer2_collected() function tries to acquire GST_VIDEO_MIXER2_LOCK.
4) gst_videomixer2_release_pad() function tries to acquire GST_COLLECT_PADS_STREAM_LOCK.

So, gst_videomixer2_release_pad waits on COLLECT_PADS_STREAM_LOCK (acquired by gst_videomixer2_collected) and gst_videomixer2_collected waits on GST_VIDEO_MIXER2_LOCK(acquired by gst_videomixer2_release_pad).

I've also attached an example that reproduces this behaviour. Sometimes this example produces a segfault. When the segfault doesn't occurs the videomixer runs a nondeterministic amount of time and then freezes.

If the gstreamer's guys want I can create a new bug or update the already uploaded bug.
Also I can try to make a fix.

Hope it helps.

P.D: on this thread I've talked with sebastian about this.

gstreamer-devel mailing list
[hidden email]