[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

Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nicolas.dufresne at collabora.
                   |                            |co.uk

--- Comment #11 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> ---
I was discussing this yesterday, and I'm thinking that with negative rate, the
queue won't report the proper duration. Specially with video data, the reason
is that in reverse playback, we push GOP in reverse order, with buffer inside
in the normal order (when encoded). So for GOP of 3 seconds and 9 seconds
queue, we'd have in positive rate:

  [0 ..... 3] [3 ..... 6] [6 ..... 9]

Which in reverse would be:

  [6 ..... 9] [3 ..... 6] [0 ..... 3]

As we only look at the first and last buffer, we will report a shorter duration
(3s) which will lead to over buffering. At least this is what I think happens,
I hope this is useful. For the case of out of segment DTS, this need fixing,
there is bugs for multiqueue already bug 757193. 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 ?

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