On Wed, Jan 22, 2025 at 3:33 PM Michael Niedermayer <mich...@niedermayer.cc> wrote: > > On Mon, Jan 20, 2025 at 06:46:46AM +0000, Kieran Kunhya via ffmpeg-devel > wrote: > > > > > > > The data arrives on multiple sockets, leading to all sorts > > > > of opportunities for timing behavior and reordering issues. > > > > > > how does this matter? > > > > > > > There are routers that put traffic on a different port down a different ISP > > so you have to compensate for latency delays between the two links. You > > can't just "buffer N packets". > > > > Another edge case. > > I dont know why you assume "buffer N packets". > > Packets enter this buffer when they are received > Packets should exit that (buffer + FEC) when they are needed for decompression > (for presentation to the user) or slightly prior > > Removing them from the buffer earlier has a higher propability of failure > so it is strictly worse.
Wrong, the packets leave the buffer at a fixed duration corresponding to (an estimate of) 2 times the matrix duration (the spec was written for CBR so this is a constant) so that latency is fixed. There is packet loss (by definition) so a buffer of N packets may be much larger than 2 times the matrix duration. "when they are needed for decompression" -> this is real-time RTP, not a file. The issue you have with FEC going down a different path is the FEC packets can arrive a lot earlier than the latency window or a lot later and you have to compensate for this with heuristics. All packets can be reordered or even duplicated which as far as I know this code doesn't cover either. 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".
