Let's talk about HTML5 live streaming. There are two competing technologies for it: DASH and HLS. They are terrible.
When both were implemented, there already existed several established, simple, standardized, and broadly supported options for live streaming video. Browsers wanted none of it.
This garbage is patent encumbered.
Therefore, Google made basically the exact same thing except they used XML, fucking XML, for the manifest.
@sir you've had me at "They are terrible".
@sir You missed the reason why they exist - because web people wanted to use their existing caching infrastructure for streaming.
Guess what - they don't use files at all anymore and keep all chunks in memory, since otherwise the latency is too great. Something that could have easily been done with existing UDP streaming setups long ago - just cache GOPs.
So now the reason why streaming sucks is purely historical.
Oh, and here's a depressing bit of news: Twitch are planning to replace RTMP for user->server streaming with WebRTC. Something that's now xml or m3u based but is just as bad. Not something rational like RIST.
@Wolf480pl @sir FTL is weird. First, on the streamer side: they've replaced RTMP with a minimal container that does not support reordering or DTS, hence the "Mixer doesn't support bframes. So force them off." comment in the OBS source. So that's a lot of compression gains wasted for a negligible decrease in latency. And they hardcode H264, while one of the main reasons to move away from RTMP was to have support for non-H264 codecs. However, they also hardcode Opus, which is nice, instead of AAC. So its weird, but I don't like it because no specs, hardcodes codecs, and doesn't give you a few bytes to put a DTS in to support frame reordering (they'll say its a feature).
I don't believe there ia a client side FTL protocol, just streamer side. For client side they probably do the same thing Twitch does and stream HLS with Twitch's extension for low latency.
That doesn't make sense, beam.pro was the first to have low latency, twitch only caught up later. So either the extension you're talking about isn't Twitch's, or beam's advantage came neither from streamer side nor from viewer side protocol, but from their CDN...
@sir Yeah unfortunately I'm forced to use HLS for streaming because my upload is very instable and HLS buffers are long... long... oh so so long.
@sir i’m giving up on anything being sane in current year. i guess i should pursue NDN and other research tech and build stuff on that: fuck interop with this insanity tbfh
@sir There is a niche third option:
Continuous data stream. It's been around since the 90s.
Icecast implements it and currently officially supports WebM (VP8 or VP9; Vorbis or Opus) and Ogv (Theora + Vorbis in Ogg).
Most browsers should actually be able to play those if pointed to in a <video> element.
No JS needed. Admittedly has some downsides, like not dealing gracefully with connectivity changes or bandwidth fluctuation.
disclosure: I work on Icecast
@sir @jalcine RTSP may have been the nicer design on paper, but in practice, I’ve found HLS to be far more reliable. This probably comes down to fast, cacheable and non-firewalled HTTP being broadly available.
I wouldn’t blame the browser folks for this one. _Maybe_ admins/IT, who have a long-standing “everything that isn’t port 80/443 is poorly understood by me and therefore bad” culture that has ruined many protocols.
HLS and DASH are pragmatic.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!