After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 757603 - dashdemux: incorrect waiting for fragments to be available
dashdemux: incorrect waiting for fragments to be available
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-11-04 18:39 UTC by Florin Apostol
Modified: 2015-11-05 20:27 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed patch (5.62 KB, patch)
2015-11-04 18:40 UTC, Florin Apostol
none Details | Review

Description Florin Apostol 2015-11-04 18:39:13 UTC
For a live stream, adaptive demux will call gst_adaptive_demux_stream_get_fragment_waiting_time to determine how much it needs to wait until a fragment is available. But that function uses gst_mpd_client_get_next_segment_availability_end_time in order to determine the availability. It should use the segment's availability start time (the beginning of the segment, not the end).

As a consequence, a live stream will be delayed if the segment end is in the future, even if the start is in the past (so it is available on server). For example, if the live stream started to be available 10s ago (mpd->availabilityStartTime = now - 10s) and the first segment has a duration of 15s, adaptive demux will wait for another 5 seconds before playing. Normally, it should start playing right away, because first segment's availability start time is equal to mpd->availabilityStartTime which is in the past.
Comment 1 Florin Apostol 2015-11-04 18:40:26 UTC
Created attachment 314849 [details] [review]
proposed patch
Comment 2 Florin Apostol 2015-11-05 20:26:40 UTC
wrong report. The gst_mpd_client_get_next_segment_availability_end_time actually returns the availability start time. I will soon rename this function to avoid future confusion.