GNOME Bugzilla – Bug 654192
[PATCH] New sink for HTTP live streaming
Last modified: 2018-05-04 09:45:37 UTC
This is a request to include the new hlssink element in gst-plugins-bad, a sink for HTTP Live Streaming that I'm developing here [1] This element fragments incoming buffers using the format defined in the HLS draft[2] and generates a playlist that follows the format defined in the same draft. This element relies in the downstream GstForceKeyUnit events to delimit the fragments boundaries using the fields 'timestamp' and 'count' of the event to retrieve the fragment's duration and their index. It uses the proposed API in Bug #607742, and therefore depends on it. Another element called keyunitscheduler is also included in the same branch, which purpose is to schedule GstForceKeyUnit events at a fixed interval to generate fragments of the same duration starting with a keyframe. The hlssink plugin writes the fragments and the playlist to disk but it does not serve them, understanding that its goal is to generate both the fragments and the playlist, relying on an external HTTP server to serve them. Both the playlist and the last fragment can be retrieved using signal actions, in case someone would need it to feed an custom HTTP server that do not reads them from disk, but rather uses an in-memory ring-buffer to serve them. Example pipeline usage for live generating 10 seconds fragments an sliding playlist for a live stream: gst-launch videotestsrc is-live ! keyunitsscheduler interval=10000000000 ! x264enc b_frames=0 cabac=false profile=1 byte-stream=true ! mpegtsmux ! hlssink playlist-max-window=5 output-directory=/var/www/hls/live playlist-url-prefix=http://myserv.er/hls/live [1] https://gitorious.org/ylatuya-gstreamer/gst-plugins-bad/commits/hlssink [2] http://tools.ietf.org/html/draft-pantos-http-live-streaming-06
I need to update the branch with some fixes I did last week, but I didn't have time yet to clean them.
Andoni, any update on this?
I have updated the branch hlssink in my github clone (git@github.com:ylatuya/gst-plugins-bad.git) I'll be given some days to work on a DASH sink, and I'll will abstract part of this sink to a base class, so that it can be reused for DASH and Smooth. I know that Alessandro has been working on a similar sink based on multifdsink, but I would use the current design since DASH on-demand can use both fragments or a single file. The base class would provide a virtual method that is called each time a new fragment is receive on the sinks, allowing the subclasses to update accordingly their playlists. This base class could also be configured by subclasses to create a new file for each fragment or append each new fragment to the same file, being able to create non-fragmented DASH content too.
And HLS also supports single files using byte ranges in the last revision of the draft: http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-pantos-http-live-streaming-07.txt
We already have hlssink. Is this still meant to be open ?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!