In a case of a scr different from 0, after a seek,
the src_segment.stop has been updated with the duration
not including the base_time (scr). The segment position
needs to be tested upon segment.stop + base_time (scr)
to check for an EOS.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2048>
If we have no DTS but a PTS then this means both are the same, and we
should update the last_ts with the PTS. Only if both are unknown then we
don't know the current position and should not update it at all.
Previously we would always update the last_ts to GST_CLOCK_TIME_NONE if
the DTS is unknown, which caused the position to jump around and to
cause spurious gap events to be sent.
Instead of doing it on each packet and doing it based on the distance to
the previous SCR instead of based on the DTS.
Previously we would send gap events for audio all the time if the SCR
distance was 400ms because the threshold for audio is 300ms and by only
ever updating the position when the SCR updates we would always be 100ms
above the threshold and send needless gap events.
This fixes audio glitches on various files caused by gap events.
It is only relevant in deciding whether or not send SEGMENT_DONE.
In this case, not detecting EOS leads to a busy loop when encountering
the originally recorded end-of-file of a file that is still growing.
When scanning for SCR / PTS / DTS, handle the case where
the pack header is followed by the optional system header,
so we can correctly collect timestamps in such cases.
https://bugzilla.gnome.org/show_bug.cgi?id=623860
When the file size is smaller than the configured 4MB scan
limit for timestamps, don't underflow the guard variable
when checking if it's time to stop.
Limit the backward SCR scan to the same 4MB as the PTS scan.
Add some comments.
found is initialized to FALSE to then only be used in two conditional statements
that will always be false, making the blocks inside them dead code. Looking back
in the file's history the setting of the variable's value before it is checked
was dropped as part of the port to 0.11, bringing that value setting back.
https://bugzilla.gnome.org/show_bug.cgi?id=742638
The whole not_linked optimisation is really a bit dodgy here, but
let's leave it in place for now and at least start pushing data
again when a pad got linked later, in which case we should get a
RECONFIGURE event.
(Identical to commit 612cdeec80 which
was for resindvd)
When we'd see an unknown stream type, then a SDDS stream.
Then we'd get to the end of the switch with a NULL temp stream
pointer, and dereference it.
Coverity 1139708
This should not harm regular files, since those are the last 4 bytes of
a normal file.
This allows to handle playback of concatenated mpeg-ps files. Seeking and
duration reporting is still wrong though.
