GNOME Bugzilla – Bug 342155
[basesink] add API to determine "prerolled" state dynamically?
Last modified: 2010-03-23 13:33:51 UTC
use case: My 'sink' element talks to a external resource. This resource takes a long time to initialize. This is undesirable to have initialization after pipeline is PLAYING. In order to init the resource, some amount of data is required (ex: 10000 bytes), because the sink element has to analyze this data and choose the right maner to init the resource, based on the info collected. So initialization should happen at preroll, and preroll should allow the element to ask for more data before finish the prerolling phase. proposed solution: if preroll function returns GST_FLOW_WRONG_STATE (or a newer GST_FLOW_NEED_MORE_DATA), GstBaseSink doens't commit the state, but waits for more data or EOS. It is up to the element to hold/discard the received data from previuos call to preroll function.
Created attachment 65724 [details] [review] add a member "preroll_need_more_data" to GstBaseSink, a new GST_FLOW_NEED_MORE_DATA to gstpad.h and some code to gstbasesink.c Hi Wim, I havent tested it with a sink that requires more data, yet. Despite of that, does it sounds good. There are some tests case you want I run and report you?
Created attachment 65789 [details] [review] this one works (not 100% yet) Hi Wim, This second patch works like that: 1- like before, where preroll is called once - FINE 2- when preroll is called N times - FINE 3- when preroll is called N+1 times - DEADLOCK I have tested some pipeline heres and N could be 100, 215, ... It seems we have deadlock in g_cond_wait if preroll doesn't finish after some amoout of time. If you want to test it: 1- aply the patch 2- change the function gst_base_audio_sink_preroll to just return GST_BASE_SINK_PREROLL_NEED_MORE_DATA the first 500 times it is called 3- try playbin with http://gstreamer.freedesktop.org/media/medium/alien.mpg
Well, after talk few minutes ago with MikeS at #gstreamer, I think the patch is ok. It is because there is a limit in decodebin queues and in the queue elements too. For example, you can get a high "N" by increasing the queue size with queue max-size-buffers.
What's up with this? Can this be closed? Did you solve this otherwise, like via a chunker as suggested on IRC? Or are you still persuing this?
Hi Tim, it is still desirable. Wtay, What could I do to make things easy to you apply this patch. BR, Edgard
Edgard, do we still need this (it's been 2 years and a half) ? Or did you solve it in another way ?
Changing summary (hopefully for the better).
Let's close it now... Edgard, feel free to reopen this bug if it is still valid.
*** Bug 489275 has been marked as a duplicate of this bug. ***