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.
In Japan IPv6 multicast is used for IPTV services[0] over GPON, competing with satellite TV (cable TV is not nearly as widely deployed as fiber). I imagine it's similar anywhere else that offers linear IPTV over fiber.
To use it you need to make sure your router supports MLD snooping
It's used within at least one streaming TV company to get the streams from the identical-to-pirate satellite decoder boxes to the ffmpeg encoder boxes.
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.
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?
> Does anyone watch scheduled television anymore except local news and sportsball?
Yes, especially for folks not at home. It’s common to see multicast used in places where internet bandwidth is constrained, but network maybe not so much.
For example, maybe you have an older hotel, or a cruise ship or a hospital or a retirement home. It’s expensive to just buy better internet backhaul, and it’s expensive to retrofit those rooms, and you can lose a lot of money for every day the room is down.
But, with multicast, you can use the legacy internet connection and the legacy wiring in the room, but easily/cheaply ensure every room has a working TV with full broadcast TV or satellite TV, and anyone watching that is not pulling 5mbps to 10mbps from your internet backhaul.
It also all works from a single remote control, and it doesn’t ask you to log into anything, it doesn’t need your cell phone for anything, etc.
It’s niche, but there’s a number of places where it makes sense.
Yes. I watched scheduled TV less than 3 (waking) hours ago.
I have a gigabit down, and a ~50TB local Plex server.
Sometimes, well… often, it’s just nice to channel-surf as a low-commitment way to find something to watch, to be surprised by something, etc. I’ll otherwise frequently be paralysed by choice and/or fall back on the same playlist of shows, over and over.
Plenty of others online have documented similar experiences. It’s why there’s an ecosystem of projects looking to emulate traditional TV experiences using Plex / local media libraries. To use a Claude-ism: it’s not just nostalgia-bait, there are genuine advantages to watching things this way. I’ve been doing it long enough for any novelty / shine to have worn off.
To demonstrate...multicast TV distribution on a home network?
> For small home networks, there is no bandwidth difference between this and streaming solutions like Jellyfin.
Jellyfin and multicast TV distribution are not the same things, though. They're very different.
Some other things that are very different include: The temperature of Lake Superior, my mother's collection of weird ceramic houses that light up, and red herring.
> Yes, this was a cool technology,
Multicast has ceased to be a cool technology? That's hot.
> and if some large provider like AT&T wanted to use this to broadcast channels to everyone at once
They do that.
> it would've made more sense than streaming
They do that, as well.
> but even for that use case the world has moved on.
All of it? Uniformly?
> Does anyone watch scheduled television anymore except local news and sportsball?
We should not use multicast TV distribution on home networks for local news and sportsball?
IPTV from your ISP is typically multicast (even if your connection is point-to-point), and if you have more than one network behind your router (for example, you have separate networks for wire clients, owner's wifi and guests wifi) you need to understand hot it works to setup your router correctly that you can watch IPTV on any device in any of yours networks.
The N Is For Networking podcast (from Packet Pushers) has a recent two-parter on multicast:
* https://www.youtube.com/watch?v=sOJgqu3jRMA
* https://www.youtube.com/watch?v=mlP-NAescuA
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.
In Japan IPv6 multicast is used for IPTV services[0] over GPON, competing with satellite TV (cable TV is not nearly as widely deployed as fiber). I imagine it's similar anywhere else that offers linear IPTV over fiber.
To use it you need to make sure your router supports MLD snooping
[0]https://ja.wikipedia.org/wiki/ひかりTV
Triple-play networks can use it to distribute TV.
It's used within at least one streaming TV company to get the streams from the identical-to-pirate satellite decoder boxes to the ffmpeg encoder boxes.
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.
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?
> Does anyone watch scheduled television anymore except local news and sportsball?
Yes, especially for folks not at home. It’s common to see multicast used in places where internet bandwidth is constrained, but network maybe not so much.
For example, maybe you have an older hotel, or a cruise ship or a hospital or a retirement home. It’s expensive to just buy better internet backhaul, and it’s expensive to retrofit those rooms, and you can lose a lot of money for every day the room is down.
But, with multicast, you can use the legacy internet connection and the legacy wiring in the room, but easily/cheaply ensure every room has a working TV with full broadcast TV or satellite TV, and anyone watching that is not pulling 5mbps to 10mbps from your internet backhaul.
It also all works from a single remote control, and it doesn’t ask you to log into anything, it doesn’t need your cell phone for anything, etc.
It’s niche, but there’s a number of places where it makes sense.
> 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...
AT&T does (or did) use multicast for cable tv replacement...
> Does anyone watch scheduled television anymore except local news and sportsball?
"Except for"? Sportsball events are some of the simultaneously most-watched things out there.
Heck, I bet a lot of the streaming services wish they could do multicast over the Internet instead of CDNs for episodic releases.
Yes. I watched scheduled TV less than 3 (waking) hours ago.
I have a gigabit down, and a ~50TB local Plex server.
Sometimes, well… often, it’s just nice to channel-surf as a low-commitment way to find something to watch, to be surprised by something, etc. I’ll otherwise frequently be paralysed by choice and/or fall back on the same playlist of shows, over and over.
Plenty of others online have documented similar experiences. It’s why there’s an ecosystem of projects looking to emulate traditional TV experiences using Plex / local media libraries. To use a Claude-ism: it’s not just nostalgia-bait, there are genuine advantages to watching things this way. I’ve been doing it long enough for any novelty / shine to have worn off.
What's a "waking hour"?
> I'm not sure I understand the point.
To demonstrate...multicast TV distribution on a home network?
> For small home networks, there is no bandwidth difference between this and streaming solutions like Jellyfin.
Jellyfin and multicast TV distribution are not the same things, though. They're very different.
Some other things that are very different include: The temperature of Lake Superior, my mother's collection of weird ceramic houses that light up, and red herring.
> Yes, this was a cool technology,
Multicast has ceased to be a cool technology? That's hot.
> and if some large provider like AT&T wanted to use this to broadcast channels to everyone at once
They do that.
> it would've made more sense than streaming
They do that, as well.
> but even for that use case the world has moved on.
All of it? Uniformly?
> Does anyone watch scheduled television anymore except local news and sportsball?
We should not use multicast TV distribution on home networks for local news and sportsball?
IPTV from your ISP is typically multicast (even if your connection is point-to-point), and if you have more than one network behind your router (for example, you have separate networks for wire clients, owner's wifi and guests wifi) you need to understand hot it works to setup your router correctly that you can watch IPTV on any device in any of yours networks.