Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Video Live Streaming: Notes on RTMP, HLS, and WebRTC

daily.co

Post reply on HN
Print view View original

41–50 of 84 posts

Re: Video Live Streaming: Notes on RTMP, HLS, and WebRTC

#41

Post by csmpltn »

fiestajetsam wrote: post #4

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…

> "Where's the future? A likely candidate may come out of the "Media over QUIC" work in the IETF"

The "future" is going to be a goddamned UDP socket sending compressed media streams across the web. We've reached peak abstraction. We need to come back to first principles, instead of piling on more crap on-top of the browser.

Re: Video Live Streaming: Notes on RTMP, HLS, and WebRTC

#42

Post by vr000m »

Sean-Der wrote: post #35
sumy23 wrote: post #24

Earlier quoted context omitted.

1) The point of WebRTC is that it’s real-time. If you buffer then it’s not real-time. 2) Adding key frames increases the bitrate greatly which exacerbates problem 1.

1) I don't think WebRTC has a specific point. Lots of users came together with their use cases and was designed by consensus. WebRTC can (and does) have toggles around latency/buffering. 2.) I am not aware of a way you can no keyframes, but be decodable at anytime. I just have done it 'HLS Style' or WebRTC 1:1. Curious if anyone else has different solutions.

Most common browser implementations use an Open GOP. That means an IFrame is implemented when needed. On scene change or when there’s high motion.

Only naive implementations would burst an IFrame on to the network, most pace them. And if needed, you could split your iframe into several frame intervals and decode them without creating a burst by bit rate.

Actually a lot of webrtc implementations use 1s or 2s GOP length. Again depends on how much control you’ve on your pipeline. Browsers implementations do make some assumptions on usecase.

Re: Video Live Streaming: Notes on RTMP, HLS, and WebRTC

#43

Post by mchusma »

kwindla wrote: post #7
liuliu wrote: post #2

There is a new Low Latency HLS protocol: https://developer.apple.com/documentation/http_live_streamin... that claims can get down to 300ms latency.

[post author here] In addition to what vr000m said above, I'll just add that when you make HLS chunks smaller, you're reducing the leverage you get from HLS's core design decisions. I tried to cover some of this in the post. One way to think about this intuitively is that HLS and WebRTC are opposite ends of one important trade-offs axis. HLS is about delivering media streams in a way that scales as cost-effectively a…

I appreciated your post so thank you. I would be more interested in understanding why you don't see <1s HLS chunk sizes as working in most cases? I feel like p99 real world latency stuff would show some natural buffer sizes.

Re: Video Live Streaming: Notes on RTMP, HLS, and WebRTC

#44

Post by themerone »

fiestajetsam wrote: post #4

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…

Corporate firewalls will be blocking QUIC until the end of time. Anyone implementing streaming over QUIC will have to have to implement an HTTP/2 fallback, probably WebRTC, but maybe we will get something new.

Re: Video Live Streaming: Notes on RTMP, HLS, and WebRTC

#45

Post by pavlov »

jzer0cool wrote: post #23

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?

Daily's API will let you record the stream as a MP4 video file stored on Amazon S3 where it's immediately available after the live stream ends. Everything happens automatically on the same server that encodes the live stream.

(The original post is written by Daily's CEO.)

Re: Video Live Streaming: Notes on RTMP, HLS, and WebRTC

#46

Post by vr000m »

themerone wrote: post #44
fiestajetsam wrote: post #4

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…

Corporate firewalls will be blocking QUIC until the end of time. Anyone implementing streaming over QUIC will have to have to implement an HTTP/2 fallback, probably WebRTC, but maybe we will get something new.

In the case of QUIC, it is likely that the streaming would be over H/3 (HTTP3) or HTTP over QUIC. They may fallback to H1 or H2 but typically over a long enough time, firewall rules become more relaxed.

Re: Video Live Streaming: Notes on RTMP, HLS, and WebRTC

#47

Post by vr000m »

pavlov wrote: post #45
jzer0cool wrote: post #23

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?

Daily's API will let you record the stream as a MP4 video file stored on Amazon S3 where it's immediately available after the live stream ends. Everything happens automatically on the same server that encodes the live stream. (The original post is written by Daily's CEO.)

Pavlov’s comment is correct. I came to add that soon the stream can be stored on customer’s own S3. Ergo, you’d be able to do a call in real-time, store it on your S3 account and make it available for streaming.

On your own S3, this would be a multipart upload.

Re: Video Live Streaming: Notes on RTMP, HLS, and WebRTC

#48

Post by rexreed »

vr000m wrote: post #47
pavlov wrote: post #45

Earlier quoted context omitted.

Daily's API will let you record the stream as a MP4 video file stored on Amazon S3 where it's immediately available after the live stream ends. Everything happens automatically on the same server that encodes the live stream. (The original post is written by Daily's CEO.)

Pavlov’s comment is correct. I came to add that soon the stream can be stored on customer’s own S3. Ergo, you’d be able to do a call in real-time, store it on your S3 account and make it available for streaming. On your own S3, this would be a multipart upload.

If we use Vimeo for video hosting would there be some way to automatically post to Vimeo or some other way to get the file up there and available for immediate viewing? Other approaches besides S3?

Re: Video Live Streaming: Notes on RTMP, HLS, and WebRTC

#49

Post by Karrot_Kream »

vr000m wrote: post #37
Karrot_Kream wrote: post #18

Earlier quoted context omitted.

> QUIC/WebTransport seems simple because it doesn't address all the things WebRTC does. Partially agree here, but the design of QUIC(/WebTransport/TCPLS) make some of the features in WebRTC unnecessary: 1. No need for STUN/TURN/ICE. With QUIC you can have the NATed party make an outbound request to a non-NATed party, then use QUIC channels to send/receive RDP from the sender and receiver. 2. QUIC comes with encryptio…

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.

Re: Video Live Streaming: Notes on RTMP, HLS, and WebRTC

#50

Post by vr000m »

Karrot_Kream wrote: post #34
parineum wrote: post #26

Earlier quoted context omitted.

I don't know much about webrtc but I do have some security cameras, frigate and home assistant all working together with rtmp streams. There are some webrtc solution for getting those streams into home assistant with low latency but they are... I don't know the word. They aren't difficult to set up because the instructions are very simple, however, they don't work when I follow them and, from reading forums, that's n…

Heh, welcome to the world of livestreaming media. The reason why it's hard to create this kind of simple "stream in, stream out" abstraction is because most IP Voice/Video stacks are architected very differently than stateless net protocols that are popular today. IP streaming generally works by: 1. A signaling layer that helps setup the connection metadata (a layer where the sender can say they're the sender, that t…

All the listed protocols came after HTTP. RTSP, SIP borrowed heavily (albeit badly in retrospect) from HTTP.

I do not have all the historical context (early 90s), but for WebRTC, the idea was to not define any new protocol(s) or do a clean slate design. but rather to just agree on the flavors of the various protocols, and then to universally implement those. We already had SDP, RTSP, RTP, SAP, etc. And the idea was to cobble together the existing protocols into something everyone could agree on (the young companies, the old companies, etc)

We ended up defining variations to the flavors that we already had and for the most part everything turned out okay (maybe the SDP plan wars did not end up where we wanted it, but… it was a good enough compromise).

For realtime media, if we are able combine “locator:identifier” issue, we will be able to make media and signaling work inband.

Post reply on HN