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 772810 - hlsdemux: Always start playback at first fragment
hlsdemux: Always start playback at first fragment
Status: RESOLVED OBSOLETE
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: 2016-10-12 15:15 UTC by GstBlub
Modified: 2018-11-03 13:56 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
hlsdemux: Always start playback at first fragment (1.67 KB, patch)
2016-10-12 15:15 UTC, GstBlub 		none Details | Review
hlsdemux: Always start playback at first fragment (1.67 KB, patch)
2016-10-12 22:51 UTC, GstBlub 		none Details | Review

Description GstBlub 2016-10-12 15:15:48 UTC 
Created attachment 337517 [details] [review]
hlsdemux: Always start playback at first fragment

Section 6.3.3 of the spec does not specify playback should be started three fragments from the end.  It merely states that a client should not start playback closer than three fragments from the end on a live stream.

Until we have support for EXT-X-START, we should probably start at the first fragment unconditionally.
Comment 1 GstBlub 2016-10-12 22:51:20 UTC 
Created attachment 337542 [details] [review]
hlsdemux: Always start playback at first fragment

Updated patch
Comment 2 Jan Schmidt 2016-10-15 14:40:48 UTC 
The intent of starting as late as possible in live streams is because people generally want minimum latency compared to the live feed.
Comment 3 GstBlub 2016-10-28 15:21:40 UTC 
(In reply to Jan Schmidt from comment #2)
> The intent of starting as late as possible in live streams is because people
> generally want minimum latency compared to the live feed.

Valid point.  As the spec is ambiguous in this regard and actually suggests that it is application/implementation dependent, what do you think about a new property that enables and application to override the default behavior? Maybe call it "first-fragment-live" with a default value of -3, and any negative number indicating the fragment from the end of the playlist (automatically guaranteeing at least more than 3 fragments as per spec), and a positive number or zero as the fragment from beginning:

  first-fragment-live : Number of fragments from the beginning (positive number) or end (negative number) of a live playlist.
                        flags: readable, writable
                        Integer. Range: -2147483648 - 2147483647 Default: -3

This way, an application could customize this behavior as needed, or just leave it at the default behavior.  Thoughts?
Comment 4 GStreamer system administrator 2018-11-03 13:56:06 UTC 
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/432.