[Bug 733235] decodebin:Handle the multi-queue size flexible

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=733235

--- Comment #46 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to Myoungsun Lee from comment #45)
> (In reply to Sebastian Dröge (slomo) from comment #41)
> > This causes the playbin-complex test in gst-plugins-base to fail.
> > 
> > 
> > Problem here is that overrun is also emitted on EOS, so in those tests we
> > overrun at EOS but never expose any pads because after EOS nothing else
> > comes anymore. And no-more-pads does not happen in this test.
> > 
> > Actually this patch is also not great in general for demuxers that don't
> > emit no-more-pads. They will all get 8MB more of buffering, and then it
> > takes 8MB more before the streams are exposed.
> > 
> > Reverting for now, and attaching the patches to the bug. Does anybody have a
> > better idea how to fix this?
> 
> I tested it, and I wonder why the EOS comes up before no-more-pad. It could
> be related in very small file size. 

demuxers are not required to ever do no-more-pads, you'll have to work properly
without no-more-pads and with EOS happening before no-more-pads.

> Anyway, in this patch, I set overrun setting(group->overrun) to FALSE,
> because I want to make decode-group is not completed. In 4K video case,
> decode-group have to wait the audio data which is located far from the video
> data. Therefore decode-group is not completed until decodebin get
> no-more-pad signal. It means that extra_buffer_required is set FALSE by only
> no-more-pad signal. 

Understood, for the case where no-more-pads happens, your patch is definitely
going to solve some problems :)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.