[FFmpeg-devel] Audio conversion and floating-point codecs
Michael Niedermayer
michaelni
Sat Jul 10 22:11:46 CEST 2010
On Sat, Jul 10, 2010 at 10:09:12AM +0100, M?ns Rullg?rd wrote:
> Peter Ross <pross at xvid.org> writes:
>
> > On Tue, Jul 06, 2010 at 03:13:26PM +0100, M?ns Rullg?rd wrote:
> >> Peter Ross <pross at xvid.org> writes:
> >>
> >> > On Sat, May 15, 2010 at 08:17:51PM +0100, M?ns Rullg?rd wrote:
> >> >> There is a long-standing desire from some to make the floating-point
> >> >> decoders output float samples instead of converting to int16
> >> >> internally, and I agree with the reasons for this. However, making
> >> >> this change hastily will make decoding orders of magnitude slower on
> >> >> many CPUs. The reason is that when a decoder outputs float samples,
> >> >> the fast asm code for float-to-int conversion is not used.
> >> >>
> >> >> In order to change the output format of these decoders without
> >> >> impacting performance, we must first make a few improvements to the
> >> >> avcodec API and to the generic audio format conversion code.
> >> > [...]
> >> >
> >> >> - The decoders should output planar audio instead of interleaved for
> >> >> multichannel streams. This probably means introducing
> >> >> avcodec_decode_audio4() with an AVFrame output.
> >> >
> >> > Q: does it make sense to expand the existing AVFrame structure, or
> >> > define a new struct specific to audio?
> >> >
> >> > #define FF_MAX_CHANNELS 8
> >> > struct AVAudioFrame {
> >> > uint16_t *data[FF_MAX_CHANNELS];
> >> > };
> >>
> >> I've posed the same question myself, without finding a good answer.
> >> Some codecs support a huge number of channels. I can say for sure,
> >
> > Second contenious point:
> > At present, the user allocates the samples buffer that is handed
> > of to avcodec_decode_audioN().
> >
> > IMHO this is sloppy. Just look at how ffmpeg.c guesses the buffer size.
> > The alternative is to have the decoder do it, e.g. by calling
> > avctx->get_buffer() with the number the samples/channels to be output.
> > Thoughts?
>
> Makes sense, although get_buffer() is presently rather image-centric.
yes,
AVFrame could be extended and used for audio frames for example
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 1
"Used only once" - "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
-------------- 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/20100710/61cc6aa9/attachment.pgp>
More information about the ffmpeg-devel
mailing list