71–80 of 84 posts
Some history reminders. Internet video conferencing: we used to have multicast and realtime videoconferencing in the 90s: https://ee.lbl.gov/vic/ Before that we had analog videoconferencing, eg AT&T Picturephone service went GA in 1970.
WebRTC is not the future of low latency live streaming... at least not outside of video conferencing. It's incredibly complex as a specification, has limitations and numerous issues that set limits in how scalable it can be. Conversely, for HTTP segment based formats like HLS and DASH have limits due to their design (and that of HTTP) which set how low latency can actually go. Where's the future? A likely candidate m…
It's been almost 3 years since I first presented on WebTransport + WebCodecs: https://youtu.be/VD5GBLBiSxo Live streaming was a motivating example for both of those, as you can tell from the video. And both of them grew out of our efforts to make WebRTC better for live streaming.
Twitch latency in low-latency mode is ~2s (you can check for yourself in the settings cog menu -> advanced -> video stats) because of "prefetch segments", which are delivered via HTTP 1.1 streaming body responses. The client requests this segment and long polls while frames are delivered as they're being encoded. It's simpler and cheaper than WebRTC or Apple's low-latency HLS parts, and scales to hundreds of thousand…
For me, DASH and HLS are just manifests or playlist definitions, of how best to find the resource. It is not dissimilar to webrtc signalling, i.e., go to a resource to discover where to get other parts of the resource.
We're using DASH and experimenting with LL-HLS to get reliable and affordable (using CDNS) end to end latency of 3 seconds with which you can already interact live with your audience without too much trouble. Latencies down to about 1 second are also feasible already at the cost of some client side buffering. So I would have expected to see more information about DASH than HLS here. It's usable on all platforms excep…
Interesting, since it was Apple who designed & built both the original HLS and the LL extensions. What's currently preventing LL from being usable there?
Some history reminders. Internet video conferencing: we used to have multicast and realtime videoconferencing in the 90s: https://ee.lbl.gov/vic/ Before that we had analog videoconferencing, eg AT&T Picturephone service went GA in 1970.
Unfortunately modern routers made multicast unrounable, otherwise, we’d all be using mbone
Earlier quoted context omitted.
ICE is needed when both parties are NATes, if one party was not mated, we’d not need ICE in webrtc either. Agree on 2. On 3. The videobridge needs state on who is on the session and who to forward to. that requirement doesn’t go away with QUIC. Unless you’re thinking that the video streams are some kind of a named resource or object. I think the most people gripe about is SDP and it’s prescription of negotiation and…
1. Fair on ICE. But if only one party is NATed, then you don't need STUN (or TURN if there's CGNAT involved.) 3. Yeah I was thinking about named resources/objects. If you could generate them predictably, QUIC+RTP can simplify a lot of things.
Earlier quoted context omitted.
1. Fair on ICE. But if only one party is NATed, then you don't need STUN (or TURN if there's CGNAT involved.) 3. Yeah I was thinking about named resources/objects. If you could generate them predictably, QUIC+RTP can simplify a lot of things.
Re: 1.- You'll probably still need it if the NATed party is recvonly, i.e. it expects to just recrive data without it explicitly sending any first.
Earlier quoted context omitted.
Re: 1.- You'll probably still need it if the NATed party is recvonly, i.e. it expects to just recrive data without it explicitly sending any first.
I would presume that the receiver will still make an output request to the QUIC endpoint to at least bring-up the connection/stream, which should be enough to populate the path in NAT tables, no? It shouldn't be any more wasteful than the regular process which receives packets out-of-band but still needs a signaling channel. This just does in-band signaling, so you bring up the connection, perform signaling, then ope…
We're using DASH and experimenting with LL-HLS to get reliable and affordable (using CDNS) end to end latency of 3 seconds with which you can already interact live with your audience without too much trouble. Latencies down to about 1 second are also feasible already at the cost of some client side buffering. So I would have expected to see more information about DASH than HLS here. It's usable on all platforms excep…
In each of these approaches will any of these (or something else) also provide approaches to getting the stream saved for viewing again later on a remote server? I'm guessing I need some client which also connects to the stream and save which can then be served again. Or is still a solution already baked in available?