topic AAC Encoder/Decoder codec "precharge" in Intel® Integrated Performance Primitives

AAC Encoder/Decoder codec "precharge"

GrassValley_Eng — Wed, 28 Jul 2010 22:14:01 GMT

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.

AAC Encoder/Decoder codec "precharge"

Chao_Y_Intel — Mon, 02 Aug 2010 05:03:38 GMT

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

AAC Encoder/Decoder codec "precharge"

GrassValley_Eng — Wed, 04 Aug 2010 18:33:08 GMT

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

AAC Encoder/Decoder codec "precharge"

Chao_Y_Intel — Fri, 10 Sep 2010 01:02:26 GMT

Wes,

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

Thanks,
Chao

AAC Encoder/Decoder codec "precharge"

Chao_Y_Intel — Mon, 13 Sep 2010 02:08:06 GMT

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