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

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 744587
           Summary: queue2: incorrect current-level-time reported after
                    seek (with packetized data)
    Classification: Platform
           Product: GStreamer
           Version: 1.4.5
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: awabik at opera.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 296913
  --> https://bugzilla.gnome.org/attachment.cgi?id=296913&action=edit
The testcase

Steps to reproduce the bug:

1) Have a queue2 element,
2) Send SEGMENT (GST_FORMAT_TIME) event with non-zero start/position/time.
3) Start pushing buffers with PTSes starting at 0 to the queue.

Effects:
1) As soon the queue obtains buffers with valid in-segment PTS, it reports
buffered time level correctly,
2) As soon the queue pushes first buffer with PTS < segment.start to the
srcpad, the queue stops reporting buffered time level correctly, it reports 0
buffered.

This is caused by rewriting src_segment.position with buffer's PTS, and then
gst_segment_to_running_time() returns GST_CLOCK_TIME_NONE.

At this point, if we have a very fast source element, and a very slow decoder,
the decoder may block on the first frame (with PTS below segment start) for
quite a long time (especially if it's a software decoder decoding 1080p HEVC or
VP9 frame). In this time, the queue reports current-level-time == 0, and what's
worse, if the queue has buffer & byte limits 0, and only the time limit set,
fast source may push megabytes of data, tens of seconds of data, even though
the limit may be 0.5 seconds. The queue will not block, as it thinks it's 0%
filled.

Additional bug (fixed by the same fix): some streams have non-monotonic PTSes.
Push buffer with PTS=1s, duration=1s, and then push buffer with PTS=0s,
duration=1s. The queue has now 2 seconds of data buffered, but it will report
only one second.

I am attaching the extended unit tests for queue2 element that demonstrate both
these problems.

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