[FFmpeg-devel] avcodec_encode_audio() and libavcodec/pcm.c

[Diego Biurrun]

On Mon, May 26, 2008 at 12:01:49AM +0200, Michael Niedermayer wrote:
> On Sun, May 25, 2008 at 11:52:31PM +0200, Stefano Sabatini wrote:
> > On date Sunday 2008-05-25 20:36:25 +0200, Stefano Sabatini encoded:
> > > 
> > > maybe this belongs to libav-user, anyway...
> > > 
> > > According to documentation for avcodec_encode_audio():
> > > 
> > >  * @param[in] samples the input buffer containing the samples
> > >  * The number of samples read from this buffer is frame_size*channels,
> > >  * both of which are defined in \p avctx.
> > > 
> > > This isn't true for PCM audio, for example with PCM 16 the function
> > > reads exactly a number of bytes which is buf_size/sample_size, and
> > > this causes also the strange switch in ffmpeg.c:
> > > 
> > >         /* output a pcm frame */
> > >         /* XXX: change encoding codec API to avoid this ? */
> > >         switch(enc->codec->id) {
> > >         case CODEC_ID_PCM_S32LE:
> > >         case CODEC_ID_PCM_S32BE:
> > >         case CODEC_ID_PCM_U32LE:
> > >         case CODEC_ID_PCM_U32BE:
> > >             size_out = size_out << 1;
> > >             break;
> > >         case CODEC_ID_PCM_S24LE:
> > >         case CODEC_ID_PCM_S24BE:
> > >         case CODEC_ID_PCM_U24LE:
> > >         case CODEC_ID_PCM_U24BE:
> > >         case CODEC_ID_PCM_S24DAUD:
> > >             size_out = size_out / 2 * 3;
> > >             break;
> > >         case CODEC_ID_PCM_S16LE:
> > >         case CODEC_ID_PCM_S16BE:
> > >         case CODEC_ID_PCM_U16LE:
> > >         case CODEC_ID_PCM_U16BE:
> > >             break;
> > >         default:
> > >             size_out = size_out >> 1;
> > >             break;
> > >         }
> > > 
> > > Can someone comment on this (pretty weird) behaviour, there is some
> > > hope to change it to make it match the documentation for
> > > avcodec_encode_audio() or application writers have to hardcode the
> > > above logic into every application which deals with PCM audio?
> > > 
> > > Thanks in advance for any clarification/suggestion.
> > 
> > Well, now I see it is required in order to be able to encode large
> > chunks of data at once, attched patch document it.
> 
> looks ok

Applied.

Diego