[Bug 744587] queue2: incorrect current-level-time reported after seek (with packetized data)

[GStreamer (GNOME Bugzilla)]

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

--- Comment #12 from Aleksander Wabik <awabik at opera.com> ---
(In reply to Nicolas Dufresne (stormer) from comment #11)
> What I'm
> unsure for this second case is if we should let the queue grow for out of
> segment, so we queue in duration a certain amount of in-segment data ?

I think that if you report out-of-segment data as buffered, then a player that
uses queue2 for buffering when playing from network may misbehave. Eg. the key
frame is in T=5 and T2=15, the time limit is 3 seconds, you seek to t=10. The
queue obtains buffers [5..8], reports 100% buffered, and the player unpauses
playback. The buffers are out of segment, so will be dropped immedately when
they reach the sink (or even before that?), and the player will pause for
buffering, while the purpose of the 3s limit was to be able to know when to
unpause after the seek to have fluent playback.

In players which shuold limit memory usage because of other constraints (eg.
embedded with low RAM), the additional limit max-size-bytes should be used,
that will prevent overbuffering.

Also, if we can merge the first patch, leaving the negative playback rates for
further investigation, that would be great. My original issue was that first
one. Maybe there should be a separate bug created for negative rates in
queue/queue2/multiqueue.

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