Upstream driving elements such as dashdemux often do reverse playback by
feeding qtdemux with the fragments containing the requested playback
range in reverse order.
But the requested playback range stop may be somewhere in the
middle of a fragment. In that case, a naive pts >= segment.stop
condition may declare end of segment prematurely when demuxing this
first fragment.
This used not to happen because there were places in moov parsing where
segment.stop was overwritten to GST_CLOCK_TIME_NONE even if
upstream_format_is_time -- resulting in this case in a segment with rate
< 0 and stop == -1 and hence not triggering the EOS check, but that was
likely an accident.
This patch modifies the EOS check to take this case into account, not
sending EOS when upstream_format_is_time if rate < 0.
This fixes adaptive.dash.playback.seek_end_live.DASHIF_livestream_testpic_2s
https://bugzilla.gnome.org/show_bug.cgi?id=752603
/* check for segment end */
if (G_UNLIKELY (demux->segment.stop != -1
- && demux->segment.stop <= pts && stream->on_keyframe)) {
+ && demux->segment.stop <= pts && stream->on_keyframe)
+ && !(demux->upstream_format_is_time && demux->segment.rate < 0)) {
GST_DEBUG_OBJECT (demux, "we reached the end of our segment.");
stream->time_position = GST_CLOCK_TIME_NONE; /* this means EOS */