On Sat, 26 Feb 2005 13:05:54 -0500, Kon Wilms <kon@xxxxxxxxxxxx> wrote: > > Packet loss is evil - any lost paclets show up either as lost video or > > audio. You can add FEC, but some SIP STBs are not going to have the > > processing power to do FEC in software and there aren't any IP STBs > > with hardware FEC support. Some MPEG-4 system do really long time > > jitter buffers and retry on lost multicast packets. > > FEC on IP is rather pointless unless you want to start modifying the IP stack > drivers. The > packets get ditched at the TCP or UDP decode layer if the checksum doesn't > compute, so they > aren't even present for the error correcting decoder to attempt to repair > them. The desired > mode for IP is to do plain ECC using large blocks - so you can recover > complete packets. For > this you need vandermonde matrix based ECC, LDPC ECC, or similar. I think that the IPTV people using FEC are FECing at the UDP/IP packet level, not at the video stream level. So a discarded packet gets reconstructed. I have not direct experience with this, but this is what I have been told. Not my preferred mthod of handling this problem. > As for jitter, it is/can be a problem for IP networks. We've had to do jitter > analysis on IP > streams (MPEG2 over UDP, RTSP, etc.) many a time, even when using large > decoder buffers. > Can you name a manufacturer that doesn't make use of a SmartBits or similar > testing system > when testing IP video servers and receivers? They do it, but it just doesn't matter for a system based on MPEG-4/VC-1. With MPEG=4/VC-1 STBs, the buffering time in the STB can be many seconds to handle the long time between I=Frames. In most MPEG-2 streams the I-frames show up twice a second, so when we change channels and grab a new stream we had a half second worst case before we get to display a picture. SO we buffered anywhere from a couple of 100 MS to about 700 MS of video. To save bandwidth, people are moving to more advanced codecs. TANSTAAFL - now we have huge amounts of times between I-frames, so we end up buffering a LOT more data and have to do magic tricks to make channel change times usable. Given the size of the buffers, we could tolerate multi-second jitter at the IP level, which is way beyond what we would ever see in real life. Prashant, if you are using an advanced codec, ask the vendors how they get quick channel change times on broadcast video, where we are joining streams at random times. This is not an easy problem to solve. For VOD, we always start the stream at an I-Frame, so this isn't a problem, but for live video it is ugly... ---------------------------------------------------------------------- You can UNSUBSCRIBE from the OpenDTV list in two ways: - Using the UNSUBSCRIBE command in your user configuration settings at FreeLists.org - By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word unsubscribe in the subject line.