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

Michael Niedermayer michaelni
Mon May 26 00:01:49 CEST 2008


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:
> > Hi all,
> > 
> > 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


> 
> BTW sometime ago someone proposed to extend the API to encode audio
> data using AVFrame, I think about something like:
> int avcodec_encode_audio2(AVCodecContext *avctx, uint8_t *buf, int buf_size, const AVFrame *frame);
> 
> is there some progress with it?

AFAIK no, do you volunteer to work on it ?

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

The worst form of inequality is to try to make unequal things equal.
-- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080526/f5cb94fb/attachment.pgp>



More information about the ffmpeg-devel mailing list