> > FEC requires tons of heuristics to work in the real world. > > Besides your word, is there some evidence ? > > (and the question is not that YOUR implementation needs > "tons of heuristics to work in the real world." or the reference > does but that EVERY implementation does) > > You seem to claim that mpeg FEC cannot be implemented cleanly >
A receiver of any protocol designed to be transmitted over a lossy network can by definition not be implemented cleanly as there are real world practicalities that need to be dealt with. Note how FFmpeg doesn't have any of these protocols and they are all implement by the OS or by exceedingly complex libraries. See also SRT, WebRTC, TCP, QUIC etc. This form of FEC is particularly difficult because it looks easy (XOR isn't hard, right) just like the OP says, but the real world throws tons of issues at you. Conveniently the patch handwaves away one of the most complicated parts which is the matrix buffering to maintain a fixed latency. Similarly for a source stop/start. You could say the same about TCP. The kernel has lots of hacks to handle real world cases and issues. Writing a toy TCP won't work in the real world. IMO, just like the kernel, FFmpeg isn't the place for toy protocol implementations that need to work over lossy networks. I am the author of the only known functional OSS implementation of FEC. It took months of testing on a lot of network behaviour and a lot of old third-party products to get right. One change affects another and it's hard to unit test. I also asked developers of proprietary implementations and they said theirs is much more messy but substantially more advanced than mine (doing full matrix recursion). Regards, Kieran Kunhya _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
