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

31–40 of 84 posts

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

#31

Post by at_a_remove »

Karrot_Kream wrote: post #28
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.

Said friends are not technical. They want something on their Roku, their Firestick, etc.

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

#32

Post by [deleted] »

j1elo wrote: post #29
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.

[deleted]

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

#33

Post by at_a_remove »

j1elo wrote: post #29
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.

Well, and understand I haven't yet attempted this, but apparently the discontinuities between switching files has caused a lot of problems downstream for Jellyfin, so OBS Studio would exist as kind of a way to smooth out the transitions.

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

#34

Post by Karrot_Kream »

parineum wrote: post #26
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…

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 they'll be sending data to port n, that the data will be encoded using codec foo, etc)

2. Media streams that are opened based on the metadata transferred over the signaling layer that are usually just streams of encoded packets being pushed over the wire as fast as the media source and the network allows.

Most IP Media stacks (RTSP, RTMP, WebRTC, SIP, XMPP, Matrix, etc) follow this same pattern. This is different than "modern" protocols like HTTP where signaling is bound together with data using framing (e.g. HTTP headers for signaling vs the HTTP request/response body for data.) This design makes IP media stacks especially fragile to NAT connectivity issues and especially hard to proxy. There are typically good reasons this is done (due to latency, non-blocking reads, head-of-line blocking, etc) but these "good reasons" are becoming less good as innovations in lower networking layers (like QUIC or TCPLS) create conditions that make it much easier to organize IP Media in a manner more similar to HTTP. Hopefully one day you'll just be able to take IP Media streams and "convert" or "proxy" them from one format to another.

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

#35

Post by Sean-Der »

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

Earlier quoted context omitted.

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.

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.

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

#36

Post by Karrot_Kream »

at_a_remove wrote: post #31
Karrot_Kream wrote: post #28

Earlier quoted context omitted.

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.

Said friends are not technical. They want something on their Roku, their Firestick, etc.

Oh gotcha. Ya, then your setup sounds great, and it looks like ffplayout will simplify a lot of the steps!

I just proposed that setup because that's what my partner and friends do to view livestreams of movies together or, specifically with my partner, our home security camera setup. We're all technical though and I don't offer the rest of my family this setup.

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

#37

Post by vr000m »

Karrot_Kream wrote: post #18
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…

> 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 encoding. I agree that capability negotiation can be vastly simplified given some of the capabilities can be inferred later in the session.

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

#38

Post by sumy23 »

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.

1) WebRTC and RTP both have RT in their name. RT stands for real-time. If I recall correctly, the only buffer WebRTC has is the jitter buffer, which is used for packet ordering, not for ensuring that enough has buffered to handle bitrate spikes.

2) Yes, you either need a high keyframe interval or some type of out-of-band signaling framework to generate keyframes. WebRTC uses RTCP. A good question is why does WebRTC feel RTCP is necessary at all? Why not generate a keyframe every N seconds like you do with HLS and remove the complexity of RTCP entirely? The answer is that many clients cannot handle the bitrate at real-time speeds.

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

#39

Post by vr000m »

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…

Webrtc protocol doesn’t dictate 1 or 2. Although browsers do implement some of their own assumptions for this. By default the client side buffer can be orders of 100s of milliseconds. this is as you pointed out tuned for real-time or live applications.

If you’re doing something like YouTube/Netflix and want to avoid going to a lower definition of the stream, that too can be tuned, albeit you’d want to use simulcast and implement your own player (to feed the video and audio frames for decoding at the pace you dictate).

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

#40

Post by at_a_remove »

Karrot_Kream wrote: post #36
at_a_remove wrote: post #31

Earlier quoted context omitted.

Said friends are not technical. They want something on their Roku, their Firestick, etc.

Oh gotcha. Ya, then your setup sounds great, and it looks like ffplayout will simplify a lot of the steps! I just proposed that setup because that's what my partner and friends do to view livestreams of movies together or, specifically with my partner, our home security camera setup. We're all technical though and I don't offer the rest of my family this setup.

I somehow ended up as Technical Guy out of the people I know. It can be a burden.

Livestreaming is, well, "the space" exists but it largely occupied by solutions where the Hollywood types figured this time they won't be caught on the back foot, so they're busy policing what is sent around, so the homegrown stuff is largely where it is at if you want shove movies around, but then you're veering into "how technical are the recipients?" and it gets interesting.

I used to run a RealServer decades ago. Video is always ... interesting.

Post reply on HN