Multiqueue buffer empty => Buffer full

[Srinath, Kamaldeep]

On 11/7/14, 11:30 PM, "Sebastian Dröge" <sebastian at centricular.com> wrote:

>On Fr, 2014-11-07 at 23:06 +0530, Srinath, Kamaldeep wrote:
>> In a multiqueue-like element, I have the low_percent val set to 10, the
>>high_percent val set to 100 and the use_buffering property set to true.
>>This enables buffering messages when the level falls below low or
>>reaches high.
>> 
>> Let's say the level falls below low threshold at 'x' and reaches back
>>to high at 'x+20'. The standard gstreamer pipeline behavior seems to be
>>that playback starts from x+20 instead of x. Buffers are dropped instead
>>of delaying the clock to insure no buffers are lost.
>> 
>> Can this standard behavior be overridden and the stream be made to
>>start from where it was blocked due to the buffering? Is the flush to
>>maintain sync with the master clock necessary? I have further things to
>>discuss based on any helpful direction to this query on this mailing
>>list.
>
>Buffering works by handling it inside the application as desired.
>Usually you would set your pipeline to PAUSED when you get BUFFERING
>messages with percent<100, and set it to PLAYING when you get BUFFERING
>messages with percent==100.

Yes, handling it inside the application is doable. Though I want to be
able to do specific calculations inside the filter element during
buffering_state < 10 and buffering_state ~100 events. How would a
multiqueue-like element listen to these states? Doing a gst_bus_post or a
gst_element_post_message at these times on this specific element from the
app did not work. Looks like we cannot have a bus callback method on the
pipeline and this element simultaneously as they point to the same bus. Is
it safe to create a new bus for the element through gst_bus_new and use
that separately for messaging?


>
>The percentages in the buffering messages are scaled according to the
>high/low properties on the multiqueue, so setting high-percent=100 is
>usually not a good idea.


Thanks for this suggestion. Good to know this.

>
>-- 
>Sebastian Dröge, Centricular Ltd · http://www.centricular.com