qtdemux: Don't send EOS during upstream reverse playback

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
This commit is contained in:
Alicia Boya García 2018-06-17 02:01:59 +02:00 committed by Thibault Saunier
parent 8ab3b91a8b
commit 2c394304b7

View file

@ -7240,7 +7240,8 @@ gst_qtdemux_process_adapter (GstQTDemux * demux, gboolean force)
/* 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 */