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

[Nicolas Gaullier]

>De : ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> de la part de Anton Khirnov <anton at khirnov.net>
>Envoyé : jeudi 12 décembre 2024 09:36
 >
>I am not intimately familiar with these formats and their mutual
>relationship, so these problems you refer to are not clear to me.
>What I am familiar with is our APIs, and from that position I can say
>this:
>1) Nested decoders are huge red flag. For one thing, they are very
>   tricky to implement properly - almost every one I've touched had
>   subtle bugs that were fixed by moving to a non-nested design.
>
>   But even more importantly it's a sign that there is something fishy
>   going on, and maybe the thing you're dealing with is not really a
>   codec and should be handled in some other layer. It's more of a rule
>   of thumb than a hard rule, but it does mean that nested decoders need
>   a strong argument justifying them.
>2) In-decoder resampling is another big red flag. We have consciously
>   moved a long time ago towards decoders exporting their native format
>   and (whenever feasible) not doing any format conversion internally.
>   Opus is a special case in that resampling there is required by the
>   spec to combine CELT with SILK.
>
>   Again, you could claim that resampling is also fundamentally required
>   in your case, but then you should have a strong supporting argument.
>

Thank you Anton for taking time to precise your mind.
I understand your point.
Unfortunately, I don't know how to move on.
I think I will shelve this work until someone has an idea how to deal with it.

Nicolas