A strong option for MPEG-DASH streaming with an open source toolchain is gpac[0] - especially in the 0.9 preview, which implements a "filter chain" concept.
The thing is, the "dasher" is only one component of a useful system - in order to do low-latency streaming (less than 6-20 seconds between source and viewer), you need a special HTTP server which can serve files as they're being generated, a solid low-latency connection to both your source and your clients (implying a CDN in many cases), and a few other bits and pieces. In production, you'll also want integration with things like connection bonding so your source can distribute to the server over a fallback connection when their main internet connection drops out, falling back to a "technical issues" screen when the source does drop out entirely, ensuring the source can come back again without starting a new stream, and so on. It's a lot of polish to build something of acceptable quality, and that's all after you've actually got your stream to a server in the first place - the process of generating a production-quality stream to broadcast in the first place is even more work.
I've honestly had much better luck using ffmpeg, especially now that it can generate both HLS and DASH manifests for the same encoded content.
Next major release will support a zmq pub-sub source/destination which will make dynamic creation of multiple publishing streams from the same live MPEG-TS source be cake.
There is an argument "hls_playlist" documented there that also generates an hls_playlist in addition to the dash manifest. They use the same segment files.
The DASH-IF group just finished a work item with the FFMPEG maintainers to build in all the functionality necessary for low latency DASH streaming. The parameters necessary have been documented in the standing "Low Latency Modes for DASH" CR: https://dashif.org/docs/CR-Low-Latency-Live-r8.pdf
Section 9.X.6.3.6 Example: FFmpeg Configuration will give you a full sample command.
8 comments
[ 3.0 ms ] story [ 31.9 ms ] threadThe thing is, the "dasher" is only one component of a useful system - in order to do low-latency streaming (less than 6-20 seconds between source and viewer), you need a special HTTP server which can serve files as they're being generated, a solid low-latency connection to both your source and your clients (implying a CDN in many cases), and a few other bits and pieces. In production, you'll also want integration with things like connection bonding so your source can distribute to the server over a fallback connection when their main internet connection drops out, falling back to a "technical issues" screen when the source does drop out entirely, ensuring the source can come back again without starting a new stream, and so on. It's a lot of polish to build something of acceptable quality, and that's all after you've actually got your stream to a server in the first place - the process of generating a production-quality stream to broadcast in the first place is even more work.
[0] https://github.com/gpac/gpac/tree/filters
Next major release will support a zmq pub-sub source/destination which will make dynamic creation of multiple publishing streams from the same live MPEG-TS source be cake.
There is an argument "hls_playlist" documented there that also generates an hls_playlist in addition to the dash manifest. They use the same segment files.
Section 9.X.6.3.6 Example: FFmpeg Configuration will give you a full sample command.