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.

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Edward Hervey]

On Mon, 2010-07-05 at 13:25 -0300, Thadeu Lima de Souza Cascardo wrote:
>
> 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!

  Therefore you should just use decodebin2.

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

  Yes, multiqueue is designed to be smarter at buffering than separate
queues. Bugs filed against decodebin will be ignored.

   Edward


------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel