On Sun, 19 Jan 2025, 22:22 Michael Niedermayer, <mich...@niedermayer.cc> wrote:
> The part i do not agree with and iam not convinced about is that this > cannot be done in a clean and fully working and heuristics free > way in the real world. > Protocols are not the same as codecs. Just because you have a hammer, everything isn't a nail. Have you ever written a protocol for a lossy network transport before? Protocols are exceptionally difficult to unit test (and this one is relatively non complex as it's unidirectional). Let's pick a simple problem. How do you detect a source encoder restart, considering this spec forces you to set SSRC=0? (why I don't know, but some devices do require it). You are forced to use heuristics. I picked a sequence number gap of 200 packets as this is twice as big as the maximum allowed matrix. This will false positive roughly 0.3% of the time but if you've lost 200 packets you probably will be in a resync condition anyway. You could also use RTP timestamps in the heuristics (but some RTP stream payloads have constant timestamps per frame or timestamps are set incorrectly), you could try packet arrival times, but there are stream splicers out there that splice two RTP streams without packet timing gaps. Note that this simple issue already exists and has existed for years in the RTP demux, a protocol that is much more important than legacy FEC. The only way to solve this is to use heuristics. Rinse and repeat for another hundred or so edge cases, and make sure they don't interact. Like I said, it's hard to unit test, so remember, you'll have to test all of these by hand. Protocols are not easy. There's a reason Zoom is so good and all the alternatives (OSS included) suck. 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".
