All things related to multicast

["Marshall Eubanks" <>]

On Wed, 27 Feb 2002 23:25:53 -0800

Hello Goorah;

   We decided a while ago that FEC was essential to a good
user experience, and have implemented and deployed a lossy
FEC to our audio streams for On-the-I.com (see
www.mctplayer.com). 
This actually works really well, and we hope to apply the
same to video in the relatively near future.

One advantage of FEC is that it is something that you can
actually do on the Internet. I might point out that much of
the packet loss that we see in our multicast receiver
reports are _not_ due to congestion, and it is hard to see
how QOS is going to help that. IMHO, the money and effort
put into QOS would frequently be better spent in improving
the underlying network.

Of course, there are things that you can do without an FEC
implementation. For example, we use a small GOP (Group of
Pictures) in our MPEG-1 broadcasts, which helps keep the
effects of packet loss down. A GOP of 15+ pictures is just
asking for trouble, as (as Toerless said) one dropped packet
can ruin 1/2 second of video.

Regards
Marshall Eubanks


 Toerless Eckert 
<>
 wrote:
> Most of the video-conferencing / video broadcast software
> out on the
> market today is not doing stream redundancy or forward
> error correction (FEC)
> when using ip multicast. In result, every lost packet
> causes visible loss
> in quality. For this reason you want to have traffic of
> such application
> to be in a higher priority queuing based class than best
> effort
> TCP traffic: Best effort typically does not cut it.
> Different
> codecs have different sensitivity to packet loss. From my
> experience,
> MPEG2 is worst - a single packet loss in an I frame of a
> 4Mbps stream
> can stop your whole video signal for the better part of a
> second.
> 
> Theoretically this "real-time-behavior" is of course
> independent of
> wether or not you use FEC or not - as long as you get
> quality deterioration
> by packet loss and as long as you don't do retransmits,
> you are in
> the real-time traffic class. Practically, FEC can
> actually avoid 
> visible quality degradation upon predictable packet loss
> (most of the
> packet loss in real networks has predictable
> characteristics), so that's
> why you practically could well classivy video streaming
> application with
> FEC into the best effort class like TCP - unles you're
> really stressing
> your network so much that that best efforts class packet
> loss becomes
> not predictable enough.
> 
> So that's just about live streaming video services. If
> you consider
> other classes of ip multicast applications, you may end
> up with
> different CoS requirements. Interestingly enough even a
> less-than-best-effort
> traffic class would be very useful for valuable type of
> applications
> with ip multicast, and this is something often overseen
> in most QoS
> architectures that just view the world wthin the
> boundaries of best-effort
> TCP web traffic and real-time Voice-Over-IP traffic  -
> all unicast of
> course ;-(
> 
> Cheers
>       Toerless
>