[FFmpeg-devel] Audio conversion and floating-point codecs

[Michael Niedermayer]

On Sat, Jul 17, 2010 at 08:15:58PM +1000, Peter Ross wrote:
> On Sat, Jul 10, 2010 at 11:49:57PM +0200, Michael Niedermayer wrote:
> > On Sat, Jul 10, 2010 at 11:47:45PM +0200, Michael Niedermayer wrote:
> > > On Sat, Jul 10, 2010 at 04:53:48PM -0400, Ronald S. Bultje wrote:
> > > > Hi,
> > > > 
> > > > On Sat, Jul 10, 2010 at 4:11 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > > > > AVFrame could be extended and used for audio frames for example
> > > > 
> > > > That takes all this a little far, isn't AVAudioFrame easier?
> > > 
> > > I dont mind but there should be a parent struct that contains the common
> > > fields so generic code is possible
> > 
> > This has the problem though that adding more common fields means breaking
> > ABI
> 
> I am swaying towards AVAudioFrame:
> 
> * the only field shared between audio and video is frame->data.

linesize (as to allow easy generic access to packed & planar)

base (as to allow freeing data when there is additional allocated space
prior to data[0][0] which will be needed for some optimiztions, this is
used that way for video as well)

key_frame (semantically not video specific and if you split base packets from
           packets containing higher frequencies or more channels then this
           could be required to be 0 even for some existing audio codecs)

pict_type (always I for current audio codecs but is semantically not video
           specific)

pts (obvious)

coded/display_"picture"_number (if theres a coded packet number in the packets)

quality (audio has quality too, a encoder might want to adapt it per
         frame depending on available channel bandwidth or cpu)

reference (to indicate if a frame is a reference frame, this exists in
           audio codecs too, at least at a experimetal level)

opaque (obvious)

error (to export PSNR or other per frame error on encoding)

type (internal or direct rendering buffer)

dct_coeffs (yes audio decoders could export them as well the same reasons
            apply as for video)

reordered_opaque (if there ever will be B frame like reordering in audio)

hwaccel_"picture"_private (obvious too)



> 
> * need a variable number of channels. makes sense to dynamically
>   allocate the frame->data array, to avoid having an
>   AVCODEC_MAX_CHANNELS macro.

dynamically allocated data array means an additional pointer dereference
for every use of it

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes
-------------- 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/20100717/6042623c/attachment.pgp>