Intel® Integrated Performance Primitives
Deliberate problems developing high-performance vision, signal, security, and storage applications.

AAC Encoder/Decoder codec "precharge"

GrassValley_Eng
Beginner
484 Views
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.
0 Kudos
4 Replies
Chao_Y_Intel
Moderator
484 Views


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

0 Kudos
GrassValley_Eng
Beginner
484 Views

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
0 Kudos
Chao_Y_Intel
Moderator
484 Views


Wes,

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

Thanks,
Chao

0 Kudos
Chao_Y_Intel
Moderator
484 Views

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

0 Kudos
Reply