* https://www.youtube.com/watch?v=sOJgqu3jRMA

* https://www.youtube.com/watch?v=mlP-NAescuA

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'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.)