Re: [FFmpeg-devel] [PATCH v0] Implement promeg decoder. - Kieran Kunhya via ffmpeg-devel

From: Kieran Kunhya via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Cc: Kieran Kunhya <kieran618@googlemail.com>
Subject: Re: [FFmpeg-devel] [PATCH v0] Implement promeg decoder.
Date: Mon, 20 Jan 2025 06:05:11 +0000
Message-ID: <CABGuwE=jrijF6gOVaRf5LqoWzcAU6bWTnM=q6va8yGKxguL7hQ@mail.gmail.com> (raw)
In-Reply-To: <20250119222239.GU4991@pb2>

On Sun, 19 Jan 2025, 22:22 Michael Niedermayer, <michael@niedermayer.cc>
wrote:

> The part i do not agree with and iam not convinced about is that this
> cannot be done in a clean and fully working and heuristics free
> way in the real world.
>

Protocols are not the same as codecs. Just because you have a hammer,
everything isn't a nail.

Have you ever written a protocol for a lossy network transport before?
Protocols are exceptionally difficult to unit test (and this one is
relatively non complex as it's unidirectional).

Let's pick a simple problem. How do you detect a source encoder restart,
considering this spec forces you to set SSRC=0? (why I don't know, but some
devices do require it). You are forced to use heuristics. I picked a
sequence number gap of 200 packets as this is twice as big as the maximum
allowed matrix. This will false positive roughly 0.3% of the time but if
you've lost 200 packets you probably will be in a resync condition anyway.

You could also use RTP timestamps in the heuristics (but some RTP stream
payloads have constant timestamps per frame or timestamps are set
incorrectly), you could try packet arrival times, but there are stream
splicers out there that splice two RTP streams without packet timing gaps.

Note that this simple issue already exists and has existed for years in the
RTP demux, a protocol that is much more important than legacy FEC. The only
way to solve this is to use heuristics.

Rinse and repeat for another hundred or so edge cases, and make sure they
don't interact. Like I said, it's hard to unit test, so remember, you'll
have to test all of these by hand.

Protocols are not easy. There's a reason Zoom is so good and all the
alternatives (OSS included) suck.

Regards,
Kieran Kunhya

>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".