8 ms·

One really funny story about this. When AT&T was creating U-verse way back when they picked IP Multicast as the deliver method for the video. In one of their fi

One really funny story about this. When AT&T was creating U-verse way back when they picked IP Multicast as the deliver method for the video. In one of their first test rollouts to the engineers on the projects house they found an issue. The engineers kid picked up the remote and started hitting the channel up button rapidly. It takes a few second for the Multicast join to be processed so this really did not work that well. The fix was that when you join say channel 100, the box joins the streams for channel 96-104 so you get the picture ASAP if you push the up/down channel button. This is why you see a delay if you jump to 200 from 100. The Multicast join has to be processed. Anyway that is the story I heard from one of their router vendors. Technically it is all correct.

iforgotpassword 8y ago
I think other (more modern?) systems solve that by requesting the first few seconds after a channel switch via unicast in parallel to the join request, to cover up the time until the join is completed. I discovered this when I swapped my ISP router for a Linux box and didn't forward igmp. When turning on the TV I saw a frozen image. After switching the channel I got about 4 seconds of TV and then freeze again. Some wiresharking hinted me at the igmp and multicast I forgot to properly handle, and after setting it all up I saw a couple of seconds of unicast UDP data after every channel switch.
- myrandomcomment 8y ago
  The time to start the single stream would be not much faster or at all to the mcast join. Most channels are broadcast to the local head node (main router in an service area). The join just builds the tree down past the head to the end user. Last time I looked at / worked on / designed these systems was maybe 8 years ago, but I do not except it to have changed to much. But you never know. I think the most interesting thing was this use case was what mcast was really designed for and the only real world use case I have seen beyond stuff in the finance market (market data feeds from the exchanges are multicast). Well there is OSPF...
  - iforgotpassword 8y ago
    Yes, these setups are really just a big mystery regarding the inner workings if you don't happen to work in that field. The unicast stream really started almost instantaneously when switching channels (sub second), so they somehow got this optimized well, but multicast always took 2 to 3 seconds...

iforgotpassword 8y ago

I think other (more modern?) systems solve that by requesting the first few seconds after a channel switch via unicast in parallel to the join request, to cover up the time until the join is completed. I discovered this when I swapped my ISP router for a Linux box and didn't forward igmp. When turning on the TV I saw a frozen image. After switching the channel I got about 4 seconds of TV and then freeze again. Some wiresharking hinted me at the igmp and multicast I forgot to properly handle, and after setting it all up I saw a couple of seconds of unicast UDP data after every channel switch.

myrandomcomment 8y ago
The time to start the single stream would be not much faster or at all to the mcast join. Most channels are broadcast to the local head node (main router in an service area). The join just builds the tree down past the head to the end user. Last time I looked at / worked on / designed these systems was maybe 8 years ago, but I do not except it to have changed to much. But you never know. I think the most interesting thing was this use case was what mcast was really designed for and the only real world use case I have seen beyond stuff in the finance market (market data feeds from the exchanges are multicast). Well there is OSPF...
- iforgotpassword 8y ago
  Yes, these setups are really just a big mystery regarding the inner workings if you don't happen to work in that field. The unicast stream really started almost instantaneously when switching channels (sub second), so they somehow got this optimized well, but multicast always took 2 to 3 seconds...