AAC LC encoder issue in DVR RDK

O.K.   Have found the answer to my own question....

I needed to have the correct bitrate set (found the answer to what the bitrate should be in post: http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/p/250489/892218.aspx#892218

Only, in my case, the system just hangs if I give an invalid bit rate, rather than returning an error.

Once I have a good bit rate, then I get a valid return from the Rpe_create() call.

This is a problem..  should have gotten and error indication returned, not a hang!!

AAC Encode as such works in 3.0 release. Have you done some changes?
You can rebuild rpe and debug using CCS @ DSP. 

• All updates done in DVR RDK to integrate RPE are under DSP_RPE_AUDIO_ENABLE macro.
• RPE source is present here - ti_tools/rpe.
• make rpe_all should rebuild rpe libraries if there is any update to rpe as such.
• System init should be done before invoking any RPE APIs to allow msg queue creation (used by RPE) to happen

Thanks for the info, Sivagamy.

I have the encoder (apparently) working - sorta.

It gets invoked, and returns data.

When that data is sent to a file, it is recognized as an AAC file.  (by VLC and by Audacity using FFMpeg libraries)

However.....

a.   The playback of the file creates nothing but silence - under Audacity, and under VLC

b.  Audacity shows no "trace" in the window, not even a flat line.

c. They both have about the right time frame (about 10 seconds)  - it is a file that is within the DVR RDK called davinci.aac - which has been decoded to a .wav file, and then the attempt is made to encode the file.  The .wav file has been played back, and looks great.

d.  I am trying to encode a mono version of the file (used audacity to mix the two channels to a single mono file)

e.  When I attempt to encode at a 56,000 bit rate (the minimum allowable) and at 160,000 bit rate (the maximum allowable), the encoder gives me the exact same input buffer size, output buffer size, and actual encoded data.

Something is very strange here, and I don't really know where to start to track down what is going on.

Further (quite confusing) information:

I found a program called MediaInfo that will show the information contents of an audio file (and others).

When I write the output of the AAC encoder output directly to a file, this is what it says about it:

General
CompleteName                     : D:\vmshared\KSI\Audio\davinci_mono_160k.aac
Format                           : ADTS
Format/Info                      : Audio Data Transport Stream
FileSize/String                  : 328 KiB
OverallBitRate_Mode/String       : Constant

Audio
Format                           : AAC
Format/Info                      : Advanced Audio Codec
Format_Version                   : Version 4
Format_Profile                   : Main
BitRate_Mode/String              : Constant
BitRate/String                   : 267 Kbps
Channel(s)/String                : 1 channel
ChannelPositions                 : Front: C
SamplingRate/String              : 44.1 KHz
Compression_Mode/String          : Lossy
StreamSize/String                : 328 KiB (100%)

There are a couple of things there that seem "just wrong"...

a.  The profile should be LC, not Main - right?

b.  The bitrate is marked as 267 Kbps (both when 56K and when 160K is the requested encode bit rate)

Hi stephen,

Can you please let us know which version of AAC_LC encoder & the platform you are using ? As per our observations, with AAC_LC encoder version 01.00.01 on C674x DSP, the generated output is proper as per the encode bit-bate & with profile as LC when opened with Mediainfo.

Regards,

Deepthi

First off, let me apologize - I think I have posted this in the wrong forum - should be in the DM816x, C6A816x and AM389x Processors Forum (as we are using the DM8168 and the DVRRDK version 3.0)

The encoder is the one included in the DVRRDK 3.0 - I don't know what version of the encoder that is, though the documentation included and the file names indicate that it is version AAC_E_C674X_1_00_01 or "c674x_aaclcenc_01_00_01_00_elf_patched".

I have not been making any changes to the code.

I am using the MCFW interface <Aenc_create(), Aenc_process(), and Aenc_delete()> to invoke the encoder.

Might this be caused by my trying to do mono encoding rather than stereo??

And ...

let me apologize once again...

The data is not being written directly to file - there is a piece of code being invoked (in our application) that appears to be writing the ADTS header info into that file...

I still am concerned that I am getting the same amount of encoded data regardless of the bitrate I set, but let me do some more research before I get back on this one.

OK   After doing a bunch of research...

a.  Cannot encode as mono - result is a (somewhat) formatted adts file with samples of all zeroes...

b. The adts file header that comes out with the stereo data looks like this (hex): FF FF FF FF 80 5F 97

   This is the data coming directly from the encoder, with no extra data added by our application (not this time :) )

c. According to the format specs for adts files that I found (here: http://wiki.multimedia.cx/index.php?title=ADTS), this is not a valid adts header.  I would expect something like: FF F9 50 80 80 5F 94  (the frame length and buffer fullness fields have not been checked).  The last two bits should be zeros (only 1 AAC frame per ADTS frame)  Also, the (in 4th nibble) layer bits should always be 0.  i.e. the fourth nibble should be 1 or 9 if no CRC information is present.

I have found nothing (not even the TI decoder) that can take this file and do something with it.

Just for reference, the test vector file for the decoder starts with the (adts) header bytes:  FF F9 50 80 2E 62 44

ok. I have tested encoding mono & stereo streams in stand-alone & observed that the adts header for mono stream looks like this (ff f1 4c 40 13 22 64) & for a stereo stream , it looks like this ( ff f1 4c 80 1d 82 88 ) .You have mentioned that " there is a piece of code being invoked (in our application) that appears to be writing the ADTS header info into that file". We doubt that may be this portion of the code is corrupting the ADTS header .

Regards,

Deepthi 

What do you mean by "stand-alone"?   Does this include the MCFW "wrapping" that the DVRRDK has in place?

I have double checked the output I am getting.

The above mentioned data is coming from the Aenc_process() call in the buffer contents.

Our code that was adding headers was adding headers, not changing what is already there.  When we were adding headers, we got our header, followed by the FF FF FF FF 80 5F 97 header.  (Of course, that did not decode :))

I am including some snippets of what I am seeing as debug output to help figure out what this issue might be:

a.  The debug print from calling Aenc_create() in the MCFW:

AUDIO: ENC Handle 4C0B80, Int Handle 4C0B8C
AUDIO: ENC -> bitrate 160000 inputBitsPerSample 16, sampleRate - 44100, numberOfChannels - 2...
AUDIO: ENC -> Rpe_create(AAC_ENC) done....
[g4av_dvr] Audio encoder 1 minimum input buffer size = 4096
[g4av_dvr] Audio encoder 1 minimum output buffer size = 1536
[g4av_dvr] Audio encoder 1 will use input buffer size = 4096
[g4av_dvr] Audio encoder actual input buffer size = 8192 @ 44E52480
AUDIO: ENC Handle 4C0CF8, Int Handle 4C0D04
AUDIO: ENC -> bitrate 160000 inputBitsPerSample 16, sampleRate - 44100, numberOfChannels - 2...
AUDIO: ENC -> Rpe_create(AAC_ENC) done....
[g4av_dvr] Audio encoder 2 minimum input buffer size = 4096
[g4av_dvr] Audio encoder 2 minimum output buffer size = 1536
[g4av_dvr] Audio encoder 2 will use input buffer size = 4096
[g4av_dvr] Audio encoder actual input buffer size = 8192 @ 44E5FA80
AUDIO: ENC Handle 4C0DF0, Int Handle 4C0DFC
AUDIO: ENC -> bitrate 160000 inputBitsPerSample 16, sampleRate - 44100, numberOfChannels - 2...
AUDIO: ENC -> Rpe_create(AAC_ENC) done....
[g4av_dvr] Audio encoder 3 minimum input buffer size = 4096
[g4av_dvr] Audio encoder 3 minimum output buffer size = 1536
[g4av_dvr] Audio encoder 3 will use input buffer size = 4096
[g4av_dvr] Audio encoder actual input buffer size = 8192 @ 44E6D080
[g4av_dvr] Audio encoder actual output buffer size = 1536 @ 44E6F080

b.  Some debug prints while encoding is in progress:

ENC1 - 1, Bytes Generated - 1536 <total 1536>, bytesConsumed - 4096
ENC1 - 2, Bytes Generated - 1536 <total 3072>, bytesConsumed - 4096
ENC1 - 3, Bytes Generated - 1536 <total 4608>, bytesConsumed - 4096
ENC1 - 4, Bytes Generated - 1536 <total 6144>, bytesConsumed - 4096
ENC1 - 5, Bytes Generated - 1536 <total 7680>, bytesConsumed - 4096
ENC1 - 6, Bytes Generated - 1536 <total 9216>, bytesConsumed - 4096
ENC1 - 7, Bytes Generated - 1536 <total 10752>, bytesConsumed - 4096
ENC1 - 8, Bytes Generated - 1536 <total 12288>, bytesConsumed - 4096
ENC1 - 9, Bytes Generated - 1536 <total 13824>, bytesConsumed - 4096
ENC1 - 10, Bytes Generated - 1536 <total 15360>, bytesConsumed - 4096
ENC1 - 11, Bytes Generated - 1536 <total 16896>, bytesConsumed - 4096
ENC1 - 12, Bytes Generated - 1536 <total 18432>, bytesConsumed - 4096
ENC1 - 13, Bytes Generated - 1536 <total 19968>, bytesConsumed - 4096
ENC1 - 14, Bytes Generated - 1536 <total 21504>, bytesConsumed - 4096
ENC1 - 15, Bytes Generated - 1536 <total 23040>, bytesConsumed - 4096
ENC1 - 16, Bytes Generated - 1536 <total 24576>, bytesConsumed - 4096
  etc ......

c:  The first bytes of data as encoded:

FF FF FF FF 80 5F 97 09 B4 A4 14 47 48 15 48 4E 41 80 A0 20 AE 82 26 B0 44 21 37 08 CC 01 02 41 A9 F1 CE C8 9C C2 A1 08 25 D4 04 41 04 00 81 4D 40 85 80 2A 06 A0 C2 29 54 02 7B 88 5D 4B E5 80 42 95 C4 74 60 11 32 A0 0C 24 99 86 70 2C 14 80

d:  The input data is in the attached file, it should match the reference output file from the decoder <Client/Test/TestVecs/Reference/davinci_ref.pcm>

We don't have DVRRDK & MCFW "wrapping" at our place. We have tested few streams on stand-alone codec , which means we are not integrating the codec with any of the framework applications. I have encoded the shared stream with 160 kbps bit-rate for which header looks like this (ff f9 50 80 3a 02 14).

I could not upload the encoded stream in the external forum. I have observed bytes generated per process call is around 464 in this case.

Regards,

Deepthi

OK - I understand that you (Prashanth) do not have DVRRDK and MCFW.

Who should be picking up this thread (from TI) then?

We do have (and need to use) the DVRRDK and MCFW (which are from/through TI)

This is a fairly urgent issue for us.

Should this thread be moved to the DM816x, C6A816x and AM389x Processors Forum ?

if so, can I do this, or is this something a TI employee needs to do?

AAC Encode as such works in 3.0 release. Have you done some changes?

DO you see any issue in RDK 3.0 release without your changes?

Thanks

Satish

I am not entirely sure how to answer this...

To the best of my knowledge, we have not changed any relevant code in this area.  However, I am not the only team member to have been working on this project.

Our code is a new application using the DVRRDK and McFW as a lower code layer.

I have indeed created a new use case for the application (for the video side of things).  The video stuff is all working well at this point.

So, I am not sure if we have changed code or not.  If we have changed something pertinent, I would appreciate help in identifying what it is.

We have seen a number of issues in RDK 3.0 (mostly in our code).  I know of one bug that messed us up quite a bit (in the audio decoder side where mono was given the value 1 and stereo the value 2 - see this report http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/t/250489.aspx?pi199607=1  and this post:

)

Seeing that post led me to be able to get the AAC-LC decoder working properly - I had assumed that the example code was correct in using 1 for mono and 2 for stereo.

We also reported an issue where the application hung up on the Rpe_create() call (within the Aenc_create() code) when we were passing invalid bitrate parameter values (rather than telling us there was a problem).  Strangely, just giving a correct bitrate parameter produced something close to the right results - we thought.

However, when we examined the contents returned by the encoder, we saw problems with the data found there as detailed in this thread.

We are doing this development on a new hardware platform (not the EVM kit), so I cannot run the stock encode demo (we have no audio capture facility, and are instead passing data from a file).

I have been looking at the McFW code, and it all seems pretty straightforward, but I have not followed my investigation into the code layers that run on the other hardware processors.. (i.e.  to the syslink or Rpe layers)

My next approach would probably be to do direct calls to the AAC LC encoder function (link API - based on code in the McFW) from my application, which would allow me to show/examine the parameters passed down to the lower layers (the McFW layer is not all that complicated or big, just a big convenience).

McFW layer is just adding a wrapper to the RPE mechanism (even RPE is just for IPC communication), McFW or RPE doesnt touch the input / output buffers and codec output is passed as is to the application.

Few things you can check -

- I hope your input / output buffer allocation is done in shared region (SR1) as done in dvr rdk demo code. If not there could be data integrity issues as SR1 is cached and framework assumes that buffers are in SR1 and do caching operations

- Just try to create single channel file in / out demo which is part of standard demo and see if you see same issue here

- Our sample use cases are tested with 16KHz mono sample capture / encode and encoding is verified. You can feed in a file input of same input parameters and verify the output just for testing purpose.

Hi Sivagamy,

I understand that McFW is "just a wrapper".  The thing I am worried about are that it sets a number of parameters transparent to the user, and this might (or might not) have some bearing on the issue, not that the data contents are changed.

The input and output buffers are (I think) allocated in the shared region.  The allocations are done as:

    inBuf[ i ] = Audio_allocateSharedRegionBuf( inBufSize[ i ] * 2 );        
    outBuf = Audio_allocateSharedRegionBuf( outBufSize );

The first thing I will try is the 16Khz sample rate (though our final application will need the 44.1Khz rate)

I will also try to create a demo derivative that uses single channel file in - that will take some time, though.

Just tried 16000 sample rate (with 30000 bit rate) and got the following results:

AUDIO: ENC Handle 4C0B80, Int Handle 4C0B8C
AUDIO: ENC -> bitrate 30000 inputBitsPerSample 16, sampleRate - 16000, numberOfChannels - 1...
AUDIO: ENC -> Rpe_create(AAC_ENC) done....
[g4av_dvr] Audio encoder 1 minimum input buffer size = 2048
[g4av_dvr] Audio encoder 1 minimum output buffer size = 768
[g4av_dvr] Audio encoder 1 will use input buffer size = 4096
[g4av_dvr] Audio encoder actual input buffer size = 8192 @ 44E67480
AUDIO: ENC Handle 4C0CF8, Int Handle 4C0D04
AUDIO: ENC -> bitrate 30000 inputBitsPerSample 16, sampleRate - 16000, numberOfChannels - 1...
AUDIO: ENC -> Rpe_create(AAC_ENC) done....
[g4av_dvr] Audio encoder 2 minimum input buffer size = 2048
[g4av_dvr] Audio encoder 2 minimum output buffer size = 768
[g4av_dvr] Audio encoder 2 will use input buffer size = 4096
[g4av_dvr] Audio encoder actual input buffer size = 8192 @ 44E74A80
AUDIO: ENC Handle 4C0DF0, Int Handle 4C0DFC
AUDIO: ENC -> bitrate 30000 inputBitsPerSample 16, sampleRate - 16000, numberOfChannels - 1...
AUDIO: ENC -> Rpe_create(AAC_ENC) done....
[g4av_dvr] Audio encoder 3 minimum input buffer size = 2048
[g4av_dvr] Audio encoder 3 minimum output buffer size = 768
[g4av_dvr] Audio encoder 3 will use input buffer size = 4096
[g4av_dvr] Audio encoder actual input buffer size = 8192 @ 44E82080
[g4av_dvr] Audio encoder actual output buffer size = 768 @ 44E84080
[g4av_dvr] Waiting to start source plugins
GOT START OF FILE SOURCE!
[g4av_dvr] --------------- CHANNEL DETAILS-------------
[g4av_dvr] Enc Channels => Primary 5, Secondary 0
[g4av_dvr] Dec Channels => 4
[g4av_dvr] -------------------------------------------
ENC1 - 1, Bytes Generated - 768 <total 768>, bytesConsumed - 4096
ENC1 - Data Buffer: FF FF FF FF 80 5F 97 09 B0 80 14 01 08 10 08 0E 01 80 20 20 AC 00 22 20 00 21 25 00 48 01 02 41
ENC1 - 2, Bytes Generated - 768 <total 1536>, bytesConsumed - 4096
ENC1 - Data Buffer: FF FF FF FF 80 5F 97 09 B0 80 14 01 08 10 08 0E 01 80 20 20 AC 00 22 20 00 21 25 00 48 01 02 41
ENC1 - 3, Bytes Generated - 768 <total 2304>, bytesConsumed - 4096
ENC1 - Data Buffer: FF FF FF FF 80 5F 97 09 B0 80 14 01 08 10 08 0E 01 80 20 20 AC 00 22 20 00 21 25 00 48 01 02 41
ENC1 - 4, Bytes Generated - 768 <total 3072>, bytesConsumed - 4096
ENC1 - Data Buffer: FF FF FF FF 80 5F 97 09 B0 80 14 01 08 10 08 0E 01 80 20 20 AC 00 22 20 00 21 25 00 48 01 02 41
ENC1 - 5, Bytes Generated - 768 <total 3840>, bytesConsumed - 4096
ENC1 - Data Buffer: FF FF FF FF 80 5F 97 09 B0 80 14 01 08 10 08 0E 01 80 20 20 AC 00 22 20 00 21 25 00 48 01 02 41
ENC1 - 6, Bytes Generated - 768 <total 4608>, bytesConsumed - 4096
ENC1 - Data Buffer: FF FF FF FF 80 5F 97 09 B0 80 14 01 08 10 08 0E 01 80 20 20 AC 00 22 20 00 21 25 00 48 01 02 41
ENC1 - 7, Bytes Generated - 768 <total 5376>, bytesConsumed - 4096
ENC1 - Data Buffer: FF FF FF FF 80 5F 97 09 B0 80 14 01 08 10 08 0E 01 80 20 20 AC 00 22 20 00 21 25 00 48 01 02 41
ENC1 - 8, Bytes Generated - 768 <total 6144>, bytesConsumed - 4096
ENC1 - Data Buffer: FF FF FF FF 80 5F 97 09 B0 80 14 01 08 10 08 0E 01 80 20 20 AC 00 22 20 00 21 25 00 48 01 02 41

Ignore the bytes consumed number, it is inaccurate in this context  (I am actually throwing away many samples in this situation because of buffer size changes)

Note that none of the first 32 bytes of output is changing from invocation to invocation - beginning to look like a buffer addressing problem somewhere...

I will make some more investigations based on that idea...

OK, I think I have found the problem.  And it is my problem, just not terribly obvious...

Thanks for the help.

The problem basically was that I was not passing the proper handle (from Aenc_create) back to the Aenc_process call.

It was not seeing either AUDIO_CODEC_TYPE_AAC_LC or AUDIO_CODEC_TYPE_G711 as the codecType and was just returning a zero.

(Since the example code did not check the return code, neither was I, and even now, when it is working, the returned status is still zero....)

Good to know that its resolved. We will add a check for this case.