Comments
Hacker News
I'm not sure I understand the point. For small home networks, there is no bandwidth difference between this and streaming solutions like Jellyfin. Yes, this was a cool technology, and if some large provider like AT&T wanted to use this to broadcast channels to everyone at once it would've made more sense than streaming... but even for that use case the world has moved on. Does anyone watch scheduled television anymore except local news and sportsball?
I worked on Google Fiber's TV distribution system so know something about this although GFiber's TV offering was IPv4 multicast not IPv6.
For anyone unfamiliar, modern video codecs tend to break up a video into a group of pictures (GOP) and you have a mix of different frame types. Some of these are the entire image. Most are just differences. It gets more complex as the video codecs allow you to pull objects from previous and future frames. But I digress.
The point is one of the things you have to decide is how often you send a complete image. Typically that's every 1-2 seconds. It may be more often with scene changes. The bigger the minimum gap in full images, the lower the bandwidth. The downside? The longer it takes to start playing a channel. Also, it makes network interruptions worse as you may have distorted the image and sound for up to 2 seconds instead of 1.
You also have to make a choice between CBR (constant bit rate) and VBR (variable bit rate). CBR is often preferred for mass distribution because it doesn't overload what are usually lower powered CPUs but that will also lead to a delay in channel changes as a full image may take longer than 1/24 or 1/30 of a second to actually send.
And then when you get into sending video over a network you have to worry about some Russian dolls of various standards. The video has a format. So does the audio. Those are in a container format (eg MKV). And then you have a transport format. For Fiber this was (and probably still is but I'm guessing) MPEG-TS (Transport Streams), which is a weird format that goes all the way back to ATM. Basically 7 packets were put into a single multicast IPv4 packet. Why 7? Because it's the most you could fit while staying under an MTU of 1500. As anyone who has dealt with IP, things just stop working or get more difficult with large MTUs.
Now on top of all of that and minimum 2-3 second channel switches you need to deal with multicast channel subscription delays. I don't know if this was changed with IPv6 but IPv4 multicast just wasn't designed with low latency subscription changes in mind. This goes to an underlying philosophy TCP/IP had in its inception of at-most once delivery. In the modern world, we've come to realize that's wrong for streaming content and we want at-least once delivery instead.
But it gets worse than that. When playing video you generally want to have a reasonable buffer. This way you have time to recover if you have some lost or damaged packets. Multicast doesn't give you a way of dealing with that so you need to build a whole different set of infrastructure for that.
Video playback in general is really difficult to get right, reliably. As an eample, my Chrome for reasons I haven't been able to ascertain, stutters every second when playing certain csources. Firefox doesn't. I suspect it's something to do with the aofrementioned full image frame every second. If Google can't get that right, is it any wonder that so many problems exist?
Circling back, multicast is a really awkward fit for something like this and it's not going to be a great user experience but, somewhat surprisingly, the alternatives still have issues.
Take for example DASH. This is a more modern method of video transport except it's kind of weird because you have an XML manifest file. This works quite well for VODs. There are space-saving variants that allow for essentially templated frame names rather than listing each frame and stream idnividually. But when you get to streaming live video, it gets rather awkward because the client may end up requesting a segment that doesn't exist yet. What should you do? Do you block the HTTP request and wait for it? Do you return a 404?
I guess this is a really long-winded way of saying I'd never do multicast distribution unless I had to. Or I was just playing around. It would be interesting to see what devices just absolutely choke when trying to consume multicast IPv6 video and the various container and stream formats that may entail.
by cletus
Interestingly multicast is used extensively by exchanges to distribute trading data to participants. I think it's the primary commercial usage outside of some IoT things.
by urams
The N Is For Networking podcast (from Packet Pushers) has a recent two-parter on multicast:
by throw0101d
Anyone know any "friendly" IPTV set-top boxes that you can point at your own feed of multicast channels? I'm looking for something more 'turnkey' than having to rely on an Android TV box or similar.
I've been experimenting on free time with a bunch of fiber distribution (cheap Chinese GPON OLTs are out there for under $200 on Aliexpress and can serve 64 users downstream) - I already essentially have the "double play" on fiber with an ONU able to connect and get online and provision its VoIP ports. Adding TV to the mix would make it more fun. It'd just be slicing off another IPTV VLAN down the pipe with the multicast streams, then whatever set top boxes on the same VLAN.
(I've /also/ got a small Arris CMTS, and I'm looking at experimenting with RFoG with a return path on top of this - so I theoretically have both fiber and cable to experiment with inside the homelab.)
by kotaKat
Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- I'm not sure I understand the point. For small home networks, there is no bandwidth difference between this and streaming solutions like Jellyfin. Yes, this was a cool technology, and if some large provider like AT&T wanted to use this to broadcast channels to everyone at once it would've made more sense than streaming... but even for that use case the world has moved on. Does anyone watch scheduled television anymore except local news and sportsball?
- I worked on Google Fiber's TV distribution system so know something about this although GFiber's TV offering was IPv4 multicast not IPv6.
For anyone unfamiliar, modern video codecs tend to break up a video into a group of pictures (GOP) and you have a mix of different frame types. Some of these are the entire image. Most are just differences. It gets more complex as the video codecs allow you to pull objects from previous and future frames. But I digress.
The point is one of the things you have to decide is how often you send a complete image. Typically that's every 1-2 seconds. It may be more often with scene changes. The bigger the minimum gap in full images, the lower the bandwidth. The downside? The longer it takes to start playing a channel. Also, it makes network interruptions worse as you may have distorted the image and sound for up to 2 seconds instead of 1.
You also have to make a choice between CBR (constant bit rate) and VBR (variable bit rate). CBR is often preferred for mass distribution because it doesn't overload what are usually lower powered CPUs but that will also lead to a delay in channel changes as a full image may take longer than 1/24 or 1/30 of a second to actually send.
And then when you get into sending video over a network you have to worry about some Russian dolls of various standards. The video has a format. So does the audio. Those are in a container format (eg MKV). And then you have a transport format. For Fiber this was (and probably still is but I'm guessing) MPEG-TS (Transport Streams), which is a weird format that goes all the way back to ATM. Basically 7 packets were put into a single multicast IPv4 packet. Why 7? Because it's the most you could fit while staying under an MTU of 1500. As anyone who has dealt with IP, things just stop working or get more difficult with large MTUs.
Now on top of all of that and minimum 2-3 second channel switches you need to deal with multicast channel subscription delays. I don't know if this was changed with IPv6 but IPv4 multicast just wasn't designed with low latency subscription changes in mind. This goes to an underlying philosophy TCP/IP had in its inception of at-most once delivery. In the modern world, we've come to realize that's wrong for streaming content and we want at-least once delivery instead.
But it gets worse than that. When playing video you generally want to have a reasonable buffer. This way you have time to recover if you have some lost or damaged packets. Multicast doesn't give you a way of dealing with that so you need to build a whole different set of infrastructure for that.
Video playback in general is really difficult to get right, reliably. As an eample, my Chrome for reasons I haven't been able to ascertain, stutters every second when playing certain csources. Firefox doesn't. I suspect it's something to do with the aofrementioned full image frame every second. If Google can't get that right, is it any wonder that so many problems exist?
Circling back, multicast is a really awkward fit for something like this and it's not going to be a great user experience but, somewhat surprisingly, the alternatives still have issues.
Take for example DASH. This is a more modern method of video transport except it's kind of weird because you have an XML manifest file. This works quite well for VODs. There are space-saving variants that allow for essentially templated frame names rather than listing each frame and stream idnividually. But when you get to streaming live video, it gets rather awkward because the client may end up requesting a segment that doesn't exist yet. What should you do? Do you block the HTTP request and wait for it? Do you return a 404?
I guess this is a really long-winded way of saying I'd never do multicast distribution unless I had to. Or I was just playing around. It would be interesting to see what devices just absolutely choke when trying to consume multicast IPv6 video and the various container and stream formats that may entail.
by cletus - Interestingly multicast is used extensively by exchanges to distribute trading data to participants. I think it's the primary commercial usage outside of some IoT things.by urams
- The N Is For Networking podcast (from Packet Pushers) has a recent two-parter on multicast:by throw0101d
- Anyone know any "friendly" IPTV set-top boxes that you can point at your own feed of multicast channels? I'm looking for something more 'turnkey' than having to rely on an Android TV box or similar.
I've been experimenting on free time with a bunch of fiber distribution (cheap Chinese GPON OLTs are out there for under $200 on Aliexpress and can serve 64 users downstream) - I already essentially have the "double play" on fiber with an ONU able to connect and get online and provision its VoIP ports. Adding TV to the mix would make it more fun. It'd just be slicing off another IPTV VLAN down the pipe with the multicast streams, then whatever set top boxes on the same VLAN.
(I've /also/ got a small Arris CMTS, and I'm looking at experimenting with RFoG with a return path on top of this - so I theoretically have both fiber and cable to experiment with inside the homelab.)
by kotaKat