[FFmpeg-devel] [PATCH] convert to S16 when resampling is requested
David DeHaven
dave
Sun Feb 1 07:24:31 CET 2009
>>> + AVAudioConvert *convert_ctx[2];
>>> + enum SampleFormat sample_fmt; ///< input sample format
>>> + unsigned sample_size; ///< size of one sample in
>>> sample_fmt
>>> + short *buffer[2]; ///< buffers used for conversion
>>> to S16
>>> + unsigned buffer_size[2]; ///< sizes of allocated buffers
>>
>> If you convert back, you could end up with three convert contexts if
>> the output format doesn't like S16. I did this with one convert
>> context in resample.c and most of the time it doesn't have to convert
>> after resampling since the encoder likes S16 anyways.
>
> Humm, why not submitting a patch before ?
I would have done it the other way if I hadn't been time constrained
so I didn't feel it was an appropriate solution.
> Besides I did the 2 approaches and you only need at most 2 contexts,
> since when you use resampling API, the conversion is done for you.
> ...
> S32 decoding -> S16 resampling -> FLOAT32 output. (2 context)
> S32 decoding -> S16 resampling -> S16 output (1 context)
> S16 decoding -> S16 resampling -> FLOAT32 output. (1 context)
I misunderstood it then.
I think the most common case (for us anyways) is non-S16 decode->S16
resample->S16 output.
Does anyone ever resample S32 or double? That doesn't seem a very
audiophile thing to do :)
>> Ideally, the resampling should be part of the converter. Then you
>> could remove the resampling code in ffmpeg.c and simplify the API a
>> bit.
>
> Yes, definitely, it justs need a volunteer :>
> Im only fixing a regression here.
I'm willing to do it when I get a chance, but I still have fires
burning in other projects I'm working on. Baby steps for now.
-DrD-
More information about the ffmpeg-devel
mailing list