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

21–30 of 84 posts

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

#21

Post by liuliu »

vr000m wrote: post #3
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.

Low latency HLS is creating partial segments by bucketing 200ms of frames instead of 6s segments in standard HLS. Whereas in webrtc, the endpoint is sending the frame as soon as it is ready. The apples apples comparison here is 0ms (in webrtc, no send side buffering) vs 200ms (in low latency HLS) or 6s (in standard HLS). This is independent of latency of the endpoint from CDN or source. Another distinction is playbac…

You don't necessarily need to wait for a reference picture to start playback. Modern codecs all support "intra-refresh", which allows you to reconstruct a reference frame from a set of existing frames. With that, you can set periodic intra refresh much lower than 6s keyframe intervals.

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

#22

Post by Sean-Der »

sumy23 wrote: post #17
Sean-Der wrote: post #9

Earlier quoted context omitted.

I am heavily biased toward WebRTC. Here is my take on it though! > It's incredibly complex as a specification What is complex about it? I can go and read the IETF drafts, webrtcforthecurious.com, https://github.com/adalkiran/webrtc-nuts-and-bolts and multiple implementations. QUIC/WebTransport seems simple because it doesn't address all the things WebRTC does. > has limitations and numerous issues that set limits in…

Having attempted to WebRTC as a generic video transport, I can say that WebRTC has insurmountable problems. The two biggest issues are: 1) Lack of client-side buffering. This is a benefit in real-time communication, but it limits your maximum bitrate to your maximum download speed. It’s also incredibly insensitive to network blips. 2) Extremely expensive. To keep bitrate down, video codecs only send key frames every…

1.) Why can't you buffer on the client side for WebRTC? That sounds like a client issue (what library were you using?) not the protocol.

2.) I use the same tactic as HLS. Generate your video with a reasonable (~2 seconds) keyframe interval. When a new client connects start sending at the keyframe.

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

#23

Post by jzer0cool »

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?

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

#24

Post by sumy23 »

Sean-Der wrote: post #22
sumy23 wrote: post #17

Earlier quoted context omitted.

Having attempted to WebRTC as a generic video transport, I can say that WebRTC has insurmountable problems. The two biggest issues are: 1) Lack of client-side buffering. This is a benefit in real-time communication, but it limits your maximum bitrate to your maximum download speed. It’s also incredibly insensitive to network blips. 2) Extremely expensive. To keep bitrate down, video codecs only send key frames every…

1.) Why can't you buffer on the client side for WebRTC? That sounds like a client issue (what library were you using?) not the protocol. 2.) I use the same tactic as HLS. Generate your video with a reasonable (~2 seconds) keyframe interval. When a new client connects start sending at the keyframe.

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.

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

#25

Post by Karrot_Kream »

sumy23 wrote: post #17
Sean-Der wrote: post #9

Earlier quoted context omitted.

I am heavily biased toward WebRTC. Here is my take on it though! > It's incredibly complex as a specification What is complex about it? I can go and read the IETF drafts, webrtcforthecurious.com, https://github.com/adalkiran/webrtc-nuts-and-bolts and multiple implementations. QUIC/WebTransport seems simple because it doesn't address all the things WebRTC does. > has limitations and numerous issues that set limits in…

Having attempted to WebRTC as a generic video transport, I can say that WebRTC has insurmountable problems. The two biggest issues are: 1) Lack of client-side buffering. This is a benefit in real-time communication, but it limits your maximum bitrate to your maximum download speed. It’s also incredibly insensitive to network blips. 2) Extremely expensive. To keep bitrate down, video codecs only send key frames every…

None of these problems are specific to WebRTC. You'll run into them in a WebRTC implementation, you'll run into them with QUIC, even with ffmpeg on the CLI you'll need to specify buffer sizes. As you mention these are both problems with livestreaming and the more you buffer, the less "live" your stream becomes. If you're interested in transmitting static videos, then why not go with HLS or even just making the static file available for direct download through HTTP instead of a live technology?

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

#26

Post by parineum »

Sean-Der wrote: post #9
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…

I am heavily biased toward WebRTC. Here is my take on it though! > It's incredibly complex as a specification What is complex about it? I can go and read the IETF drafts, webrtcforthecurious.com, https://github.com/adalkiran/webrtc-nuts-and-bolts and multiple implementations. QUIC/WebTransport seems simple because it doesn't address all the things WebRTC does. > has limitations and numerous issues that set limits in…

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 not uncommon. I have _no_ idea why it doesn't work.

I don't really understand why I can't spin up a docker container that will take my rtmp streams and convert them to webrtc then hook that into home assistant.

I've gathered that webrtc just doesn't work that way but why can't it?

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

#27

Post by sumy23 »

Karrot_Kream wrote: post #25
sumy23 wrote: post #17

Earlier quoted context omitted.

Having attempted to WebRTC as a generic video transport, I can say that WebRTC has insurmountable problems. The two biggest issues are: 1) Lack of client-side buffering. This is a benefit in real-time communication, but it limits your maximum bitrate to your maximum download speed. It’s also incredibly insensitive to network blips. 2) Extremely expensive. To keep bitrate down, video codecs only send key frames every…

None of these problems are specific to WebRTC. You'll run into them in a WebRTC implementation, you'll run into them with QUIC, even with ffmpeg on the CLI you'll need to specify buffer sizes. As you mention these are both problems with livestreaming and the more you buffer, the less "live" your stream becomes. If you're interested in transmitting static videos, then why not go with HLS or even just making the static…

The buffer sizes in ffmpeg are more about ensuring that the calculated bitrate is accurate iirc than ensuring smooth streaming (although you need your bitrate enforced to guarantee smooth streaming).

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

#28

Post by Karrot_Kream »

at_a_remove wrote: post #15

This all looks like a lot of Very New Design Decisions. I tend not to be an early adopter on these, although it is mostly moot because I am no longer in the video delivery business. I have been considering streaming sets of short films, commercials, trailers, and movies to friends in a live stream via a pipeline of comparatively hoary old tech: 1) A playlist of multiple different video files in VLC as a source for ..…

If your friends have access to VLC on all of their devices, and have some appetite for tech, why not use an RTSP server and just hand them RTSP URLs as "channels"? You don't get browser playback, but as long as everyone has VLC or an RTSP capable media player they can just open the stream on whatever device they have.

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

#29

Post by j1elo »

at_a_remove wrote: post #15

This all looks like a lot of Very New Design Decisions. I tend not to be an early adopter on these, although it is mostly moot because I am no longer in the video delivery business. I have been considering streaming sets of short films, commercials, trailers, and movies to friends in a live stream via a pipeline of comparatively hoary old tech: 1) A playlist of multiple different video files in VLC as a source for ..…

Why steps 2 and 3? I mean, I don't totally see the reasons for not consuming the video files directly with ffmpeg, instead of going in such roundabout way to bring the media into it.

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

#30

Post by Karrot_Kream »

sumy23 wrote: post #27
Karrot_Kream wrote: post #25

Earlier quoted context omitted.

None of these problems are specific to WebRTC. You'll run into them in a WebRTC implementation, you'll run into them with QUIC, even with ffmpeg on the CLI you'll need to specify buffer sizes. As you mention these are both problems with livestreaming and the more you buffer, the less "live" your stream becomes. If you're interested in transmitting static videos, then why not go with HLS or even just making the static…

The buffer sizes in ffmpeg are more about ensuring that the calculated bitrate is accurate iirc than ensuring smooth streaming (although you need your bitrate enforced to guarantee smooth streaming).

IIRC (it's been a bit since I've configured this), you can specify both codec buffers and buffers for streaming to smooth out issues reading from the codec output. I could be wrong though.
Post reply on HN