[Bug 743905] multiqueue: handle the BUFFERING query

[GStreamer (GNOME Bugzilla)]

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

--- Comment #6 from Thiago Sousa Santos <thiagossantos at gmail.com> ---
(In reply to Duncan Palmer from comment #4)
> Hi Thiago, no worries on the late reply.
> 
> The use case I'm trying to hit;
> 
> - Our software has a module which creates the pipeline, and once it's
> reached the paused state, it hands it over to another module. This second
> module subscribes for messages from the pipeline, and then uses a buffering
> query to determine what the current buffering state is.

Why isn't just getting the buffering level from the messages enough here? What
do you gain by using queries?

> - Seeing as queue2 supports the buffering query, I thought it would also
> make sense to have the multiqueue support it; my thinking was that both
> elements support buffering, so why not support the buffering query in both.

Yes, it makes sense to me. Went to revisit playbin's buffering and it seems
like this is a good idea. Would like to confirm with Edward to check if this is
aligned with decodebin3/playbin3 plans.

> 
> It's worth noting that the multiqueue will only respond to a buffering query
> if it's configured to buffer.

ACK

> 
> In the case of ABR content, I think it makes sense to buffer using the
> multiqueue, with the queue size specified in units of time; see as we're
> adaptive, there's no point buffering in a queue2 element by units of time
> (since it has no useful notion of time with ABR content), or by units of
> bytes, since we don't know in advance what our likely bitrate will be. Would
> you agree?

Yes, your idea makes sense to me. Would like a second opinion here to make sure
I didn't miss something.

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