In message <5.2.0.9.0.20030627141054.038683c0(a)pele.citylink.co.nz>, Richard Naylor writes:
[Multicast] Well the biggest part of the business is video on demand and that can really only be unicast as getting viewers to agree on what they watch is like agreeing on a TV Channel in a huge flat - hopeless.
Even aside from the live situation you mention (eg, LOTR last year), general overseas experience with video-on-demand has shown that people really only want (to pay for) video-soon-after-demanded. Eg, for a 1-2 hour thing, having to wait, say, 2-5 minutes for it to start isn't a big deal. Even waiting 1 minute for a 10 minute thing isn't _that big a deal. Which means that for popular stuff that is "on demand" it might not be enough to have one channel with it, where the wait time is, say, 15 minutes for it to cycle around -- but it might be fine to have 10-20 channels, suitably staggered, where the wait time was 1-2 minutes. (Add channels to reduce the wait time.) Especially if there was some nice front end whereby people could find out which channel would be showing their thing starting next, and tune into that one. And it's much easier to scale channels-starting-every-minute (say) than it is to scale each-stream-is-unicast-with-its-own-start-point. (Particularly if you don't both starting/continuing the channels if there's nobody receiving it after a few minutes -- that requires some feedback outside multicast, but wouldn't be hard to do with a suitable client application and, say, UDP upstream responses every minute or so.)
back to streaming live and did the LOTR premiere last year with 10,000 clients. Its a lot of fun and didn't really stress much other than a few ISPs.
At least once some traction was made on the urgent call for more peering from the source point to the main sink points. But multicast fully deployed would definitely have helped a lot there. Ewen