Lists

Terms and Conditions
Lists hosted on this site
Email the Postmaster
Tips for posting to public mailing lists

Pre-initialising AudioConverter codec decoder

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Pre-initialising AudioConverter codec decoder

Subject: Pre-initialising AudioConverter codec decoder
From: Tim Hewett <email@hidden>
Date: Tue, 13 Nov 2007 03:33:47 +0000

I am implementing a plugin codec and also an application which will use it via AudioConverter.

It is all working except that I am trouble seeing how to have the app tell the decoder the packets size. of the incoming stream when it is the decoder which has the ability to work that out from each packet header.

The stream uses fixed size packets for a given encoding bitrate (which doesn't change while the stream is running), so I am trying to avoid using packet descriptions to keep the complexity down. In any case it is the decoder which understands the framing structure of the stream so I would prefer it to handle all that internally.

The problem is that AudioConverterFillComplexBuffer() and its associated ComplexInputDataProc() operate on whole packets and it seems that the packets length has to be set before decoding starts. Yet it is not until the decoder has received some data that it knows what the stream parameters are.

It seems to be a chicken-and-egg situation and I am wondering if there is a solution. Is there a way to initially pass some data to the decoder only for analysing the stream parameters rather than producing decoded output? Or is it ok for the decoder to set these things when it decodes the first frame? For the latter it seems to me that the ComplexInputDataProc() must pass in an initial packet of the maximum size, then get the new size and rewind to the stream start..... etc.

This all seems convoluted, is there a better way? I would prefer not to have to have the encoder stream the packet descriptions so as to keep the stream complexity down, and I would also prefer to keep the knowledge of internal stream data to the plugin codec rather than the application analyse the stream to setup the codec. I also like my breakfast cooked for me. Am I asking for too much, or missing something perhaps? Maybe set the packet size to one byte and let the decoder take what it wants as it runs and handle all framing internally (as it does so well)? I sense there must be a more elegant solution... _______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden Follow-Ups: Re: Pre-initialising AudioConverter codec decoder From: William Stewart <email@hidden> Prev by Date: Re: kAudioUnitProperty_PresentationLatency supported in LogicPro 7.2 and/or 8? Next by Date: Re: User-land CoreAudio driver and Leopard Previous by thread: Re: Leopard xcode 3, and audio-unit compile error. Next by thread: Re: Pre-initialising AudioConverter codec decoder Index(es): Date Thread