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

[Michael Niedermayer]

Hi

On Fri, Dec 13, 2024 at 01:40:43AM +0000, Kieran Kunhya via ffmpeg-devel wrote:
> On Thu, 12 Dec 2024, 13:07 Nicolas Gaullier, <nicolas.gaullier at cji.paris>
> wrote:
> 
> > >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.
> >
> 
> It is required in his patchset because you could have PCM at 48khz, then
> Dolby E at some other sample rate that's expected to be output at 48khz.
> Any of these can change on the fly but the base rate is 48khz (in order to
> have a simple frame cadence with NTSC video)

At the risk of steping on some specs and some expectations.

what would happen if the decoder simply outputs what is stored ?
I mean if a packet on the input that encodes 1234 samples at 48khz
it outputs 1234 samples at 48khz. If the next packet contains
7654 samples at 23khz then it outputs a packet of 7654 samples at 23khz

I do guess/understand that the intend is likely that the decoder would
output a fixed pattern of 1602 and 1601 sample PCM packets at 48khz.

But this is not what FFmpeg calls a decoder. That might be called
a decoder plus filter graph containing some resampler and frame split
filter.
(these extra parts after the decoder may in fact be unwanted by some
 users, they add latency and extra processing on the stored data)

thx

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

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20241213/60301979/attachment.sig>