4 ms·
Since you care more about cost and don't mind building it yourself, just build it yourself. ffmpeg -> MPEG-DASH -> nginx + MPEG-DASH -> your own video player.
by manv1 4y ago
Since you care more about cost and don't mind building it yourself, just build it yourself.
ffmpeg -> MPEG-DASH -> nginx + MPEG-DASH -> your own video player.
- mobilio 4y ago+1
- sitkack 4y agoIf the video isn’t streaming IN, then you can use anything that can serve https
- mobilio 4y agoThis isn't true. Using ffmpeg you can transcode one stream to HLS stream. Example: https://www.martin-riedl.de/2018/08/24/using-ffmpeg-as-a-hls-streaming-server-part-1/ https://www.martin-riedl.de/2018/08/24/using-ffmpeg-as-a-hls...
- sitkack 4y ago> The data is delivered over a HTTP/HTTPS connection, so it can be also perfectly cached on server side or used in combination with an CDN. We are not in disagreement.
- sascha_sl 4y agoNothing prevents you from doing this live either though, except maybe if you need very low latency.
- manv1 4y agoFrom what I've noticed in our setup latency these days is in the encoder. Everyone is pretty good at pumping out segments and stuffing them into disk. Of course, I'm on AWS using SSDs, MediaStore, and CloudFront (as a testbed; we use medialive for production). If you're on a spinning disk you'll have contention and throughput issues (ie: you can't expect to write and read to that guy effectively). I'd suggest dropping to 24fps, since you're not doing fast action sports. Also, use the Apple HLS authoring guidelines as a baseline for your bandwidth settings. Overall they seem to be pretty good. As with any compression, high quality in is better, because it gives the encoders more data to work with. 360p is pretty worthless. What you can try and do, if you want to ride the edge of legality, is start an unlisted youtube livestream then extract the m3u8 out of it and send it to your clients.