From ea588ae0e0c0754ab3cc8470e6427f3806e0d6ac Mon Sep 17 00:00:00 2001 From: Seungha Yang Date: Fri, 24 Mar 2017 15:04:21 +0900 Subject: [PATCH] adaptivedemux: Retry downloading a fragment immediately if any in live streaming At the moment that demux is waiting manifest update, the target sequence of fragment was advanced already. So, checking stream_has_next_fragment() means looking for the next fragment of target fragment. This might cause unexpected buffering if each fragment has large duration and manifest is listing only limited number of fragments. https://bugzilla.gnome.org/show_bug.cgi?id=780494 --- gst-libs/gst/adaptivedemux/gstadaptivedemux.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/gst-libs/gst/adaptivedemux/gstadaptivedemux.c b/gst-libs/gst/adaptivedemux/gstadaptivedemux.c index 6152b0217e..d0c662e929 100644 --- a/gst-libs/gst/adaptivedemux/gstadaptivedemux.c +++ b/gst-libs/gst/adaptivedemux/gstadaptivedemux.c @@ -2643,7 +2643,8 @@ gst_adaptive_demux_stream_wait_manifest_update (GstAdaptiveDemux * demux, g_mutex_unlock (&stream->fragment_download_lock); /* Got a new fragment or not live anymore? */ - if (gst_adaptive_demux_stream_has_next_fragment (demux, stream)) { + if (gst_adaptive_demux_stream_update_fragment_info (demux, stream) == + GST_FLOW_OK) { GST_DEBUG_OBJECT (demux, "new fragment available, " "not waiting for manifest update"); ret = TRUE;