Greg, I have done some more analysis, specifically for the case of 3gp nb files. I have confirmed that the parameters are being set correctly. The frame format, DTX mode, mime mode, band mode values all match for a given input 3gp file.
This leads me to believe that our codec is expecting the data to be provided in a manner differently than how open core is currently doing. I will need to dump the OMX input buffers from the existing/working amr implementation to compare with the format I was expecting. I have seen some bool flag in the amr file parser to set includeHeader. Does this flag actually cause the frame header to be removed from the data stream? While I continue this analysis, can you offer any alternative suggestions or give general guidance to which nodes are created in the 3gp amr file case? Thanks, Chris On Dec 10, 7:18 am, GregS <[email protected]> wrote: > Can you provide more details on your problem? Exactly what file > format are you attempting (e.g., IETF storage format (specify whether > it is using NB or WB), 3GP file, etc)? What format is being signaled > to your OMX component? And please give some details on what is > missing from the data versus the format specifications? > > On Dec 9, 10:10 am, chrisk_ti <[email protected]> wrote: > > > Greg, > > I have reviewed these components, but also found that there is an amr > > file parser. > > Can you give any insight to what exactly is done in this node? > > > At OMX level, it seems that the frame headers that I need at hardware > > level have already been stripped from the file. > > > Thanks again for the reply- > > > On Dec 6, 1:14 pm, GregS <[email protected]> wrote: > > > > The exact format of the AMR audio data at the OMX level is signaled to > > > OMX > > > decoder as specified in section 4.1.18 of OpenMax IL version 1.1.2 > > > document. > > > Please look at the pvomxaudiodecnode (under nodes) and the existing > > > OMX > > > AMR decoder component under codecs_v2/omx/omx_amr. The OMX audio > > > component is a complete, working implementation of an OMX AMR decoder > > > so it should help resolve uncertainties about how the data is passed > > > and > > > parameters are signaled. The formats and protocols supported for AMR > > > include: > > > 3GP files, IETF storage format files (as defined in RFC-3267 now > > > RFC-4867), > > > and RTP payload format (as defined in RFC-3267 now RFC-4867). > > > > On Dec 2, 10:57 pm, Dave Sparks <[email protected]> wrote: > > > > > I believe the 3GP parser in the OpenCore framework strips off > > > > everything but the rawAMRstream. Hopefully someone from PV will be > > > > able to give you a definitive response. > > > > > On Dec 2, 11:55 am, chrisk_ti <[email protected]> wrote: > > > > > > Hi all, > > > > > > Does anybody know what exactly is the format ofamrdata at the OMX > > > > > input level? Also, is there any info on what file types and formats > > > > > are supported by openCore? > > > > > > I have had limited success playing 3gp NB-AMRfiles and also some > > > > > success playing basicamrfiles at 4.75kbps, but no other formats are > > > > > working at this time. > > > > > > If the file is File Storage Format, the MIME header has to be removed > > > > > from the file before decoding. Is this done by any openCore node, or > > > > > should the OMX component handle this? > > > > > > Thanks for any insight or feedback- --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
