Le jeu. 23 janv. 2025 à 12:31, Kieran Kunhya <kieran...@googlemail.com> a écrit : > > > The FEC decoder works on the demuxer/transport layer and is > > independent from the content layer. > > > > The FEC decoder parameters can be set by the user according to their > > content settings to determine the delay incurred by buffering and > > packet loss for a CBR content. > > A buffer of N packets does not map to a fixed duration when there is > packet loss (even if that packet loss is corrected) irrespective of > CBR. This means you have bursty output throughout the process. In a > realtime application you will then have pops and clicks. > > For example in the beginning you buffer 200 packets and that > corresponds to a duration of 200ms (for simplicity). Then you have > packet loss that's corrected, but then that 200 packets corresponds to > a longer period of time, say 250ms. What will you do about this gap of > 50ms in a realtime application? > > >This process is not clear to me, am I supposed to work with you on > > getting this patch accepted? > > No, I'm just explaining the real world of protocols is a lot more > complex than your claims of "elegance". But it's clear you want to > move the goalposts (e.g ignoring encoder restarts) to maintain that > belief. You say heuristics are not needed and then just claim an issue > that obviously needs heuristics is "out of scope".
I understand these two points clearly. I responded in context of the ffmpeg project with specific questions: How do you think these two points should/would be articulated in the context of the ffmpeg codebase? Thanks, -- Romain _______________________________________________ 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".
