Multicast TV Distribution on My Home Network
apalrd.net
apalrd.net
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.)
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.
Even extremely small users are leveraging systems like the DISH Smartbox to distribute satellite TV inside their properties as multicast IPTV.
https://info.dishbusiness.com/smartbox
Alternatively, slightly larger operators use Smartboxes and feed the multicast into their own repackaging and DRM to kick out to their end-users as a streaming TV product. We also used lots of HDHomeRuns to provide local television channel insertion where it was required on top of it.
I will say - I LOVE the Smartbox platform and how far it's transformed television distribution. We've gone from 3-4 full 40U racks all wired up with individual satellite boxes down to a very, very elegant power-sipping 3RU box that can pull in 192 channels and IPTV from the Web.
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.
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.
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.
AT&T does (or did) use multicast for cable tv replacement...
"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.
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?
Put it on RPi (as it could skip transcodnig and pass media streams as-is) and put into the box :)
We are on HN, after all!
So multicast is when you want hardware outboard of the server to do all the distribution, the maximum number of simultaneous client users is then not limited by the server resources since the server itself only serves that one stream to a single IP address no matter how many users or not tap into the stream beyond that point.
The more familiar default approach for more common servers and routers is not multicast, but regular unicast instead. Where the server allows individual asynchronous interactions directly with each user like you expect in a common office network (or the internet), hardly anything identical is intended to be accessed simultaneously by the clients. But of course the server then needs to handle the distribution to each user individually like in a basic office network, which can add up to a lot of IP connections for the server to contend with compared to only a single IP if it was multicast.
So the number of simultaneous users is then limited by the number of connections that the server itself can maintain under unicast, which is an un-necessary additional bottleneck that can be avoided by using multicast if everything on that "channel" is going to always be simultaneous anyway.
Not my downvote btw.