On Thu, 16 Jan 2025, 20:48 Kieran Kunhya, <kieran...@googlemail.com> wrote:
> On Thu, 16 Jan 2025, 20:15 Romain Beauxis, <romain.beau...@gmail.com> > wrote: > >> This patch implements the decoding logic for the FEC error- >> correction method described in the Pro-MPEG CoP #3-R2 FEC[1] >> >> We are still in the process of testing this patch with our encoders but >> I wanted to send it now in case it could use some early review. >> >> The code seems clean enough and straight forward: >> > > As someone who wrote an FEC receiver in Upipe, I'm surprised to see the > word "straight forward" and FEC used in the same sentence. The Upipe > implementation (which was never merged) is extremely messy and complex and > commercial implementations are even worse as I understand. There are tons > of edge cases. > > The biggest question I have, is how do you decide to schedule packets? In > the FEC spec, the incoming streams are CBR so the matrix duration is fixed. > So if there is packet loss you know when to schedule the output packets > because the latency is fixed. But in FFmpeg you don't know the incoming > streams are CBR, nor do you have a concept of time. Min and max packets is > complete guesswork in a VBR stream and the code takes a bursty stream and > makes it even more bursty. And you of course destroy the CBR nature of a > valid FEC stream. > > The other thing that's difficult is handling a change in stream without > causing an infinite loop and keeping FEC behaviour Heuristics are needed > for this. > > It's not clear from your code how you handle the matrix recursion. i.e the > fact you recovered one packet allows you to rerun the recovery and > potentially recover more from a different column/row. > > I also question the need for FEC in 2025. I am happy to see this awful > protocol gone and am not sure maintaining something like this is possible > in FFmpeg apart from use cases where latency doesn't matter (so why use > FEC?). > > Kieran > I forgot to add min/max are meaningless in a data path that's *losing* packets. In reality you are meant to buffer (an estimate of if necessary) two matrices worth of values. The spec is vague about this but it's the only way to do it to handle both aligned and non-block aligned sources. 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".