>Michael Williams observed,
>
>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.
You are touching on another subject, like MPLS control vs.
forwarding, that the marketdroids tend to get confused. Multimedia
does not require multicast, even though they often get lumped
together. You are describing a a multicast applications that have
the extra QoS requirements of multimedia, just as there are
multimedia applications (e.g., VoIP) that have no multicast
requirement. There are major multicast applications, such as
financial information distribution, that have no multimedia aspects.
In the example you cite, I would hope that the egress device at the
bar is a router with enough intelligence to recognize that more than
one host TV wants to join the multicast group (i.e., via IGMP). The
router would then send out a multicast or broadcast frame for the
group, and, with 100 Mbps or faster, I suspect the synchronization
problem would be lost in the noise. Remember that you, as a human,
are going to be at different distances from the various TV sets, and
the sound from each is going to reach you at a significantly
different time -- the speed of sound in air is far slower than the
speed of electrons or photons on a cable. Indeed, you may experience
different propagation times through the air and the lower tones that
conduct through the floor.
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=9696&t=9655
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
