[Bug 743905] multiqueue: handle the BUFFERING query

[GStreamer (GNOME Bugzilla)]

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

--- Comment #12 from Duncan Palmer <dpalmer at digisoft.tv> ---
(In reply to Thiago Sousa Santos from comment #11)

> I'd propose returning the individual queues buffering if the query arrives
> on the pad, multiqueue could aggregate if the query is sent directly to it
> as an element query. GstBin could also aggregate returns if it gets a query,
> it already does some of that for other queries.

No problem.

> The only remaining question is how to properly aggregate the returns from
> multiple queues?

We could implement something like this;
- buffering, percent
  - Nothing, unless all queries return buffering, percent.
  - If any queue is buffering, then buffering is True, and we take percent
    from the same queue (note that this may not be the lowest percent value).
  - If no queue is buffering, percent is the lowest value returned.
- Stats
  - Nothing, unless all queries return stats.
  - avg_in, avg_out are averages of each result.
  - buffering_left is the lowest value returned.
- single range
  - Nothing, unless all queries return a single range.
  - start is the highest value returned, and stop the lowest. start must be <=
stop.
  - estimated_total is the lowest value returned.
- multiple ranges
  - Nothing, unless all queries return multiples ranges.
  - The intersections of all ranges.

Problems I see here;
- I'm not really sure what makes sense with the single range. It depends on
  what you're using it for. Use cases which spring to mind;
   - Seeking to a buffered location. But, in this case you're likely to be
     using a single queue before a demux anyway.
   - Displaying a range of buffered data. You could make a case here for what
     I've suggested, or using the lowest value of start and highest value of
     stop. I think what I've suggested makes more sense tho.
- Mutliple ranges support as I've suggested is complex, and I'm not really
  sure what the point of having that support would be; as with my example in
  the previous point, I think if you wanted to seek to a buffered range, you'd
  likely be using a single queue before a demux.

I think I'd be inclined to discard data for multiple ranges, but implement
everything else as I've suggested.

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