> 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". Kieran _______________________________________________ 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".
