[FFmpeg-devel] [PATCH 0/7] RFC: complete rework of s337m support

[Nicolas Gaullier]

>De : Anton Khirnov <anton at khirnov.net>
>Envoyé : jeudi 5 décembre 2024 15:06
>Hi,
>I believe a similar approach was tried by Gyan earlier this year and
>unanimously rejected by the TC [1-3].
>
>[1] https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240127103854.9971-1-ffmpeg@gyani.pro/
>[2] Message-Id <9be400cf-949f-4eb1-93a1-b352a1b807e6 at gyani.pro>
>    https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2024-February/321564.html
>[3] Message-Id <20240412122920.GB3370 at haasn.xyz>
>    https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2024-April/325588.html

Anton,
Yes, of course, I followed this work.
I thought I had highlighted many new elements (including many s337m issues in current code),
and my work is not focused on s302m,
so I would have expected some discussions to start.
You certainely noticed that I posted this as an "RFC", so it is more "open".

To take an example, I will quote one point of the TC:
"The opposition to the patch was based on the opinion that this implementation of
S302M should be handled by libavformat, not libavcodec."

In my patch serie, the s302m decoder IS moved to libavformat, which is what was asked.
So: even if there are some strong/hard points against the s337m decoder I designed,
maybe part of this work can be helpful. Maybe just the s302m decoder moved to libavformat,
I don't know.

Nicolas