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
