Re: [FFmpeg-devel] [PATCH v0] Implement promeg decoder.

From: Michael Niedermayer <michael@niedermayer.cc>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH v0] Implement promeg decoder.
Date: Wed, 22 Jan 2025 17:36:57 +0100
Message-ID: <20250122163657.GY4991@pb2> (raw)
In-Reply-To: <CABGuwEm6+-uU1gQpxRUa2kGNV-USZXbJv_=QoSrCpYFVc_=u3A@mail.gmail.com>

[-- Attachment #1.1: Type: text/plain, Size: 2526 bytes --]

Hi

On Mon, Jan 20, 2025 at 03:00:17PM +0000, Kieran Kunhya via ffmpeg-devel wrote:
[...]

> Error recovery protocols are complicated -

everything is complicated

> this project lacks
> experience in them

The project is made of many developers, and several of them do have
experience in protocols and also error correction

Just about myself,
i have written a teletext decoder that used raw 8bit data over 20 years ago
and it was more robust than TV sets

I recently as part of the SDR work wrote a RDS decoder, which also worked
better than the decoders i compared it to. Its less than 300 lines of code
and certainly can be improved alot but there is nothing magic along the
lines you suggest here. RDS needs both demodulation and error correction

Also i have written a reed solomon decoder based on my own algorithm
that had better asymptotic speed than what i could find at the time.

> 
> I have no issue with it being marked experimental.

> But the idea of
> incremental improvement is false.

You have experience with mpeg FEC and other protocols but
you mix your practical experience with ridiculous claims

> Error recovery implementations
> require careful design from the outset with numerous heuristics
> needed.

Can you please stop this "my way or no way"

You can design things first then implement them
you can evolutionary write code
you can do it incrementally
you can write a implementation learn from it discard it and write a 2nd one
based on lessons lerned
and there are probably hundreads of other paradigms along which you can
implement something

For some people one way works better than others. For someone else
another might work better

Someone might enjoy writing, tuning and testing heuristics. Another might
have a strong background in probability and statistics and they might design
a model about all the restarts and damages and implement an optimal solution
for teh model with no heuristics. At that level they can then even tune that
model for the particular source of packets and everything adapts to be optimal
for that then as there are no or few hardcoded heuristics.
Noone ever did that before maybe, ok, but doesnt mean it cannot be done

I dont like how you talk down on others, as if what you did is the only
way things can be done.

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are best at talking, realize last or never when they are wrong.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

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