AAC Encoder/Decoder codec "precharge"

AAC Encoder/Decoder codec "precharge"

I am trying to wrap aac encoder and decoder codecs (they came with the
ipp sample) into DirectShow filters. I need to understand the
"precharging" of the decoder. According to a document from Apple(

http://developer.apple.com/iphone/library/technotes/tn2009/tn2258.html), all
their AAC streams have 2112 samples of audio to precharge the decoder.
Since we will support loop play, shuffle forward/backword, I need to
understand how Intel IPP codecs deal with this precharging issue. Is
there precharging needed? The encoded AAC streams has extra data at the
beginning and the end of the bit streams?

Any information and pointers will be very helpful. Thanks.

5 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Hello,

Our AAC expert suggested that IPP AAC encoder delay is 2048 samples (actually it encoder + decoder delay). You could check it comparing input and decoded streams.

Thanks,
Chao

Hi Chao,

Thank you for the answer.

Now I have several following up questions and hopefully you can enlight me.

1. How do we detect
this precharge in the bitstream generated by the IPP (anything in the AAC acess
unit headers)? Because apparently, different decoders will assume different numbers of precharging samples.

2. Is the "precharging" in IPP encoder configurable? I mean how can we configure
the IPP encoder to say use x number of samples as precharge?

3. What value is a
good value and why? I assume in IPP case, is it 2048? I am a little confused about your comment on "encoder + decoder delay".

Thanks.

Wes

Wes,

We are checking this problem, and will provide more information.

Thanks,
Chao

Hi,

some more suggestion from the engineer owner:

How do we detect this precharge in the bitstream generated by the IPP (anything in the AAC acess unit headers)? Because apparently, different decoders will assume different numbers of precharging samples.

> There is no such possibility. The following is the quote from document mentioned below (http://developer.apple.com/iphone/library/technotes/tn2009/tn2258.html)

With MPEG-4 and ADTS/MPEG-2 bitstreams and file containers, there is still no satisfactory and explicit signaling mechanism for either the encoding delay or remainder padding.

Is the "precharging" in IPP encoder configurable? I mean how can we configure the IPP encoder to say use x number of samples as precharge?

> No, precharging is not configurable in IPP encoder. You can increase this delay by additionally delaying input signal (for example on 64 samples to achieve 2112 samples delay recommended by Apple (2112 = 2048+64).

What value is a good value and why? I assume in IPP case, is it 2048? I am a little confused about your comment on "encoder + decoder delay".

>For the good value? Encoder delay is implementation dependent. It depended on encoders algorithms. I think that the less delay the better.

AAC uses MDCT for stream transformation. Forward and inverse MDCTs introduce 1024 samples delay together. Encoder performs forward MDCT, decoder inverse one. Additional delay (1024 samples in IPP encoder case) is needed as look ahead to choose which types of transform should be used (short or long).

Thanks,
Chao

Leave a Comment

Please sign in to add a comment. Not a member? Join today