queue2: incorrect current-level-time reported after seek (with packetized data)
Submitted by Aleksander Wabik
Created attachment 296913
Steps to reproduce the bug:
- Have a queue2 element,
- Send SEGMENT (GST_FORMAT_TIME) event with non-zero start/position/time.
- Start pushing buffers with PTSes starting at 0 to the queue.
- As soon the queue obtains buffers with valid in-segment PTS, it reports buffered time level correctly,
- 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.
Patch 296913, "The testcase":