[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