[FFmpeg-devel] [PATCH v0] Implement promeg decoder.
Kieran Kunhya
kieran618 at googlemail.com
Wed Jan 22 18:29:36 EET 2025
On Wed, Jan 22, 2025 at 3:33 PM Michael Niedermayer
<michael at 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
More information about the ffmpeg-devel
mailing list