[gst-devel] Demuxers + Collectpads versus Multiqueue

[Thadeu Lima de Souza Cascardo]

Hello, folks.

I've just reduced one problem we've hit to a pipeline like the
following:

filesrc location=foo.avi ! decodebin name=v ! queue max-size-buffers=1 ! \
theoraenc ! queue max-size-buffers=1 ! oggmux name=o ! filesink \
location=/tmp/voodoo.ogg \
v. ! queue ! audioconvert ! vorbisenc ! o.

This deadlocks very fast. Our application did deadlock too when the
audio source that was linked to the muxer came from a demuxer in front
of a file source. I could test that using another audio source "fixes"
the problem. The original issue was regarding a DV/Firewire source, and
I didn't have the chance to test the "fix" with it yet. But I believe it
would not deadlock.

The problem is that the video queues get full (including the one created
by decodebin) while the audio queues get empty. oggmux, which uses
collectpads blocks waiting for a buffer from the audio path and does not
empty the queues from the video path. avimux is blocked trying to
enqueue a video buffer and never gets the chance to enqueue an audio
buffer. Using leaky for the queues degrades the quality of the video
produced a lot. And using unlimited sized queues reaches the memory
space limit in 32-bit machines in less than a minute in our application.

I thought one possible solution would be to leak/drop buffers in the
full queue when the other is empty. Then, I took a brief look at
multiqueue, found out decodebin2 uses it and gave it a try. And it
works!

I would like to know from GStreamer experts if this deadlock is known
and multiqueue was designed to solve it. Or if I should report a bug.
And... is multiqueue really designed to solve this? Or should I take a
closer look at the source code?

Best regards,
Cascardo.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20100705/bdee8f86/attachment.pgp>