You are correct. Those leading bytes in the first buffer I capture are the confg data. I was misunderstanding some previous internal info. Now that I am clear on that, I still have some concerns. These are probably more global concerns for other OMX decoders in opencore use, but we can limit the discussion to AAC.
There seem to be some mismatches between opencore OMX and TI OMX use: TI: 1. OMX component is created, buffers are allocated 2. Then a series of get/set parameter calls are made (at this point our OMX expects all the parameter values to be correct so we can configure the codec correctly). 3. Transition to executing - Buffer processing begins. Codec crash follows due to config data prepending the raw data. opencore: (forgive me making some assumptions - this is the part that is unclear to me) 1, 2. same as above 3. Buffer Processing begins. First buffer has the audio config data. 4. PortDisable? config data is parsed and more setParameter calls are made. 5. PortEnable? 6. Resume processing My question now becomes: why do you need to send the config data to OMX? Why can't the pvmf node parse the config data and set the parameters accordingly? In our use of OMX, the media framework (usually GST) always provides the correct parameter info before the first buffer is sent to OMX. Can you clarify the differences and make any recommendations? Thanks again for spending the time to help me understand this. On Nov 15, 11:09 am, GregS <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
