Are you sure those 2 bytes aren't the AudioSpecificConfig()? It is not unusual for the AAC AudioSpecificConfig() to be 2 bytes. Have you tried manually checking those first 2 bytes against the syntax defined in the ISO/IEC document?
On Nov 14, 11:59 am, chrisk_ti <[EMAIL PROTECTED]> wrote: > Greg, > Thanks again, what you said above is what I expected. I have captured > the data sent to the input port of my omx aac decoder and there seems > to be an extra 2 bytes at the very beginning, before the start of the > expected config data. If I delete these two bytes, my decoder will > work properly. Is there any reason that these extra 2 bytes are sent? > > On Nov 14, 9:04 am, GregS <[EMAIL PROTECTED]> wrote: > > > The entire AudioSpecificConfig(), as defined in the referenced ISO/IEC > > document, is sent to the OMX level. Nothing is removed or added by > > the file parser or streaming components. When I mentioned the > > variable length nature of the configuration data in my previous > > response, I was simply referring to the fact that the > > AudioSpecificConfig() is defined to have a variable-length encoding. > > If you need to audit your decoder for gaps, you really need to check > > against the referenced document. > > > On Nov 13, 1:34 pm, chrisk_ti <[EMAIL PROTECTED]> wrote: > > > > Greg, > > > Thanks for the help. I don't have a copy of this table in front of me, > > > could you give me a little more detail about which parts of the config > > > data are sent to OMX level. I need to understand if there are any gaps > > > in the current implementation of my decoder. > > > > On Nov 12, 1:34 pm, GregS <[EMAIL PROTECTED]> wrote: > > > > > The initial bytes you mention are the audio configuration data, which > > > > carries information on aac clip properties such as number of channels, > > > > sampling rate, etc. The data coming from the parser is in a raw > > > > format, which has the following high-level structure: > > > > <audio configuration> < aac raw bitstream > > > > > The audio configuration takes at least 2 bytes, but it is not unusual > > > > to see 20 bytes. The bitstream syntax of the audio config is defined > > > > in ISO/IEC14496-3, Part 3, Subpart 1, in subclause 1.6.2.1, table > > > > 1.8. Please let me know if there are additional questions. > > > > > On Nov 12, 10:41 am, chrisk_ti <[EMAIL PROTECTED]> wrote: > > > > > > Hello, > > > > > > I am working to integrate the TI OMX solution and have run into some > > > > > problems with AAC decoding. > > > > > > I have some questions about the aac file parser used in openCore. > > > > > Primarily, when decoding m4a or mp4 files, the data is sent to OMX in > > > > > raw > > > > > format. In general the data looks like I expect, but there are some > > > > > bytes of data at the beginning that cause errors in my hardware codec. > > > > > This problem > > > > > is consistent from input file to input file. > > > > > > I have looked at the header definition in the MPEG spec and I don't > > > > > see any field > > > > > defined for this data. Can anybody say if this is expected or why it > > > > > is happening? > > > > > > Thanks- --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "android-framework" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-framework?hl=en -~----------~----~----~----~------~----~------~--~---
