[FFmpeg-user] AC3 decoder now decoding to AV_SAMPLE_FMT_S32P? WTF?

[Thomas Worth]

On Fri, Jun 28, 2013 at 7:47 AM, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
> Thomas Worth <dev <at> rarevision.com> writes:
>
>> >> Correction, that should have said the decoded AVFrame is in
>> >> AV_SAMPLE_FMT_FLTP, not AV_SAMPLE_FMT_S32P.
>> >
>> > Correct: In your old version, the (definitely non-free)
>> > conversion from float to s32 was done inside the decoder,
>> > now you can either directly use the floats (for higher
>> > performance) or use the (optimised) converter in
>> > libswresample (that allows you to do other conversions
>> > at the same time) if you need ints.
>>
>> Thanks, Carl. My code takes the decoded AVFrame from
>> avcodec_decode_audio4 (now in float format) and passes
>> it directly to avcodec_encode_audio2 to transcode to
>> PCM S16. Since my output audio needs to be signed PCM
>> 16 bit, do I have no choice but to resample the
>> audio manually using swresample?
>
> If you mean pcm_s16le or pcm_s16be (there is no "PCM S16"
> encoder iirc), yes you have to call swresample for the
> conversion because the two mentioned encoders require
> AV_SAMPLE_FMT_S16. Note that the overall process may still
> be faster than before, it should at least not be much
> slower (and some common decoding - encoding processes are
> definitely faster now because the two conversions to and
> from s16 are not needed anymore.)

Thanks again. That all makes sense. I've started working on an update
and noticed that swr_convert wants plain uint8_t buffers for in/out
samples. However, avcodec_encode_audio2 wants an AVFrame. I just
pointed the AVFrame's data pointer to swr_convert's output buffer:

my_avframe->data[0] = outbuf_from_swr;

It seems to work, but is there any hidden danger in doing this? The
comments for AVFrame->extradata say "For packed audio, there is just
one data pointer, and linesize[0] contains the total size of the
buffer for all channels."