On Sun, 2005-02-27 at 04:54 -0600, John McClenny wrote: > 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. Right, cause the IP layer will discard a corrupted packet (or it just won't arrive). Hence you are not really doing forward error correction, but rather erasure correction. With the entire packet missing you can't do your standard bit error reconstruction, you have to do block error reconstruction. Reed-solomon is also useless for this application. Also to do it correctly, one has to randomize the processed block and parity blocks (you don't want your parity blocks in sequence, it defeats the purpose) - the impact of this is latency in the decoder buffer... > 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. We had severe jitter on IPTV streams, but the blame was (correctly) put on the decoder chipset vendor (who has buggy driver code for linux but doesn't open source it - maybe they don't want people seeing the spaghetti). I also find it interesting that some manufacturers who support decode of both MPEG2 and MPEG4 with buffering at the driver layer require one to change the buffer model depending on the codec used (another jitter issue). > 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. Yes like using two decoder buffers :-) Cheers Kon ---------------------------------------------------------------------- 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.