"Howard C. Berkowitz" wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> One of the things that I personally find flawed in using multicast in
> distributing video to end users is that the channels are synchronized
> in time -- in other words, a given program starts at a given time,
> and if you're late, you miss it. I think a VCR-like function has
> more commercial appeal, where multicast is used to distribute content
> to video caches at the provider edge or even in set-top boxes, but
> the end user then can access the content on random-access storage.
I was discussing this the other day at work. Where I work, many of use
listen to streaming audio on our PCs, and when I asked someone to turn up a
song they said, "Pull it up on yours". I tried to explain that if I did,
our two versions would not be synchronized and it wouldn't sound good......
I then had a discussion with my brother-in-law about using multicast to
distribute video, and we used the "picture a bar with 5 TVs.... if all 5
TVs aren't in sync then this technology won't be widely accepted". The only
thing we could come up with was multicast and if used with CGMP (or a
CGMP-like standard) at least at that pont, you know that each packet gets
delivered to each station connected to that switch at virtually exactly the
same time, at least within a few milliseconds, which is close enough to "in
sync" IMHO. The only thing is, you would have to make your application on
the "TVs" that receive this broadcast so that they didn't employ a buffer,
or else you could run into having the buffers on the units getting out of
sync. We also speculated that what you could do is to have a central unit
control the buffer and timing of the playback on the collection of units
(i.e. have a server in the bar that took in the multicast video and then
doled it to the "TVs" in a manner that would let them synchronize).
Alternatively, you could make a protocol that each of the end stations in a
place (i.e. the bar) could run between them that would let you coordinate
their own sync.
The only problem with making it "on demand" is that your multicast
infrastructure is of no use (i.e. each person would be in their own
multicast group). Also by having the video "on demand" it would have an
affect of many units close to each other being in sync (like in the bar
example from above). If indeed the "on demand" route was taken, multicast
support wouldn't be important, but QoS would be of utmost importance. The
biggest problem I see with relying on QoS though is that at some point,
*everyone's* traffic will need to be considered important enough......
This, to me, is a very interesting topic, because these issue represent the
future of all audio/video delivery IMO. A friend of mine just implemented a
huge multicast setup for a large financial firm and used the multicast to
broadcast IPTV. He told me that with IPTV there was no buffer, or if there
was it was small because when you clicked "join this broadcast" the video
(broadcast quality MPEG2 video mind you) started playing instantly. I asked
him about if there were multiple units in close proximity, if they were in
sync. He said he'd never tried that........
I'm sure we'll think of something =)
Mike W.
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=9694&t=9655
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
