dm365 aac code encode will delay when decode on PC

Hi DongFeng,

Will look into this and get back.

regards

Yashwant

Hi Feng,

Encoder will insert  delay frames (each frame of 23 ms) at the starting depding on the object type(LC, HE or HEv2)and at the end of stream,1 frame of silence in case of incomplete frame.

Hence we can expect maximum 2 second extra in the encoded stream. But in your case you are observing 12 seconds.

Can you please try out with a smaller duration input capture and let me know the observation?

Ram

Dear Mr.Dong Feng,

We will look into the problem you are facing.

However could you please check your application. It is possible that when the audio capture is done that the 12 seconds of silence gets padded to the original data. This would be since the size of the buffers used for capture are of a particular size and application looks to pass filled buffers forward. As indicated by Mr.Ramprasad, when you look to encode a small duration file you should face the same problem. A 2-3 second capture will yield a file that plays for 10-12 seconds on the PC.

Regards,

Akshaya Mukund

Dear friends,

Mr. Dongfeng was reporting an error we’ve experienced. We are a TI customer using DM368 as our TV channel encoder.

The problem we are trying to solve is that we are experiencing an accumulated play delay of about 1.5%. That is, when we decode a 368 encoded stream(5 minutes) using a Hi3716 set-top-box or a PC, we actully saw 5min+5s of play(10minutes encoding will generate 10min+10sec of play,etc., this is 1.5%). This accumulated delay is particular true when we compare the original video(pre-encoding) and 368-encoded streaming.

In order to make the decoding synchronized with original input video, we found two facts: 1. When trying to make a H264 TS steam, video is patched according to aac audio timing.   2. When we tried to determine the AAC acuracy, we used 44100hz,two-way line-in audio input @96kbps, Observations: AAC cuts audio signal to many pieces and compress each piece to frame. Normally each piece would contain 1024 sampling porints. this would yield 44100/1024=43.066frames. But we noticed that encoder actually generated 43.785frames, precisely 1/60=1.5% more than thoeretical 43.066 frames. This matches precisely with our observed video delay rate. So we highly suspect that the delay of aac caused our video TS treaming delay.

But the questions is: why would AAC generate such 1/60 diffences?

Your timely help is greatly apprecaited.

Carl Yang

Dear Akshaya Mukund

    We used the minimized "4096" as the AACLC encoder input buffer size in our application. And we initialize, process, close the AACLC encoder using the DMAI interface, not as how the ittiam demo app doing, which path is "aaclc_enc_3_5_00_production_dm365_mvl\packages-production\ittiam\app\aaclc_enc_app".

    I don't know whether we do wrong or not. If wrong, how could we do?

    any help will be apprecaited!

Since it would be tough for us to try and reproduce those issues here would it be possible to try out the following experiment. It would help us identify where the problem is.

The recorded pcm (captured data from the input buffers) could be dumped into a file and fed to the demo application. The output from the demo application can then be observed. If there is still an extra silence at the end then I think it would indicate that the problem should be with the sound capture and buffer handling there. The reason I say this is since the demo application would only encode the available data in the input file that you are feeding it, so there should not be any extra silence at the end. Also if possible could this input dump be shared.

Another check would be to work on the application side and feed it a pre-recorded input instead of sound capture and feeding the same to the application. If there is no silence in the second case then trying to imitate this behavior in your application (sound capture) should solve your problem.

Do let me know the results of these experiments.