Hi David, Could please let everyone know the changes which you have made to add support for Qcelp. This will help others in a big way.
Thanks APT On Tue, Apr 21, 2009 at 1:02 PM, david 1 <[email protected]> wrote: > I've made Android support encoding Qcelp well successfully. Thank you all. > > david > > > 2009/4/1 david 1 <[email protected]> > > So far, I've tested the 'RunCompressedTest' and 'RunUnCompressedTest' >> respectively by using the below test command lines, and relative log being >> printed, too. >> >> Case 1 : >> # test_pvauthorengine -audio amrtestinput.amr -output /sdcard/1.amr >> -audioconfigfile /sdcard/amr.cfg -test 11 11 >> SDK Labeled: PVDEV_CORE_RELEASE_6.101.1.1 built on 20090121 >> PVAuthorEngine Unit Test >> [test range from: 11 to: 11] >> Input audio file name:amrtestinput.amr >> Input video filename: >> Output filename:/sdcard/1.amr >> Audio Configfile name:/sdcard/amr.cfg >> Video Configfilename: >> Test case range 11 to 11 >> >> Starting Test 11: AMR Input to .amr Test >> ERROR: Leave Occurred! Reason 103 >> >> Case 2: >> # test_pvauthorengine -test 207 207 -source pcm16testinput.pcm -output >> /sdcard/1.amr >> SDK Labeled: PVDEV_CORE_RELEASE_6.101.1.1 built on 20090121 >> PVAuthorEngine Unit Test >> [test range from: 207 to: 207] >> Source type unknown so setting to unknown and have the player engine >> recognize it >> Begin test with the following parameters: >> Input File Name : pcm16testinput.pcm >> Output File Name: /sdcard/1.amr, >> Video Encoder: /x-pvmf/video/encode/mp4, >> Audio Encoder: /x-pvmf/audio/encode/amr-nb, >> Composer: /x-pvmf/ff-mux/amr-nb >> Starting Test 207: >> Test:207: PCM16 to ARM Test >> Test output begins >> Number of tests: 0 >> Successes: 0 >> Failures: 0 >> Errors: 0 >> Test output ends >> >> The above 2 results show that the two case all failed to execute the >> recording procedure for .amr even though the .pcm & .amr input data are >> provided respectively. Is it correct that if I do not think that the >> Recording function of OpenCore is ready presently? If that is not the truth, >> could you please provide me a way with which I could experience this >> recording of PV? It's very necessary & critical for me to go further to add >> QCELP recorder to OpenCore. Thanks a lot. >> >> david >> >> 2009/4/1 rktb <[email protected]> >> >>> >>> Ok...it is more involved than I originally thought. The below is the >>> format: >>> >>> /* >>> * Some of the compressed inputs need a log file to go along with >>> the bitstream. This logfile is provided >>> * using the "-audiologfile" or "-videologfile" commandline >>> option. In case of audio and video bitstreams >>> * the log file format is as follows: >>> * unsigned int(32) total_num_samples; >>> * unsigned int(32) avg_bitrate; // could be 0 if not available >>> * unsigned int(32) timescale; //this is the timescale of all >>> sample timestamps below >>> * unsigned int(32) max_sample_size; // could be 0 if not >>> available >>> * unsigned int(32) config_size; //could be 0 for streams that >>> have no config, say AMR >>> * unsigned int(32) height; //zero if it is audio stream >>> * unsigned int(32) width; //zero if it is audio stream >>> * unsigned int(32) frame_rate; //zero if audio stream >>> * for (j=0; j < total_num_samples; j++) >>> * { >>> * unsigned int(32) sample_length_in_bytes; >>> * unsigned int(32) sample_timestamp; >>> * } >>> */ >>> >>> Just to confirm, are you trying to use compressed input? It looks like >>> you are taking a .amr file and trying to compose a .amr file again. Is >>> that what you intend to do? >>> >>> -Ravi >>> >>> On Mar 31, 7:03 pm, david 1 <[email protected]> wrote: >>> > many thanks for your quick reply anyway and being anxious for your >>> further >>> > info. >>> > >>> > david >>> > >>> > 2009/3/31 rktb <[email protected]> >>> > >>> > >>> > >>> > > hmm... this is unfamiliar territory. and I can't find it either :). I >>> > > will make an action item on my end to get this documented. >>> > >>> > > For now, you can look at the API LoadAudioConfiguration() that >>> > > attempts to read the the config file. From here, it looks like the >>> > > file requires 3 lines of data: >>> > > 1st line -- No. of audio samples >>> > > 2nd line -- Average bitrate >>> > > 3rd line -- Timescale >>> > >>> > > Please try that and I will try to get more concrete information. >>> > >>> > > -Ravi >>> > >>> > > On Mar 31, 2:41 am, david <[email protected]> wrote: >>> > > > Hi rktb, >>> > >>> > > > Thanks for your response. >>> > >>> > > > Now trying to record .amr by using test_pvauthorengine appended >>> with '- >>> > > > audio amrtestinput.amr -output /sdcard/1.amr -test 11 11', but >>> always >>> > > > failed at 'Audio Config File not available!!! Specify >>> -audioconfigfile >>> > > > <filename>'. What does the configure file look like? I'm sorry I >>> can't >>> > > > find out such the file or a sample of it in the OpenCore package. >>> If I >>> > > > should create it myself, with what format should I comply? THANKS >>> in >>> > > > advance. >>> > >>> > > > david >>> > >>> > > > On Mar 23, 8:06 pm, rktb <[email protected]> wrote: >>> > >>> > > > > Ahh..you wanted AAC composer as a reference. Sorry...missed that >>> > > > > point. >>> > >>> > > > > Yes. You would require support composing a new format. The >>> > > > > implementation, would however depend on the actual format. For >>> very >>> > > > > simple formats such as AMR and AAC, there is no need for any true >>> > > > > composing. What is required is to directly dump the output of the >>> > > > > encoder to a file, and hence, in such cases, we use the file >>> output >>> > > > > node that will serve as the *composer*. On the other hand, in >>> cases >>> > > > > where there is a requirement for a *container* that is not >>> obtained as >>> > > > > part of the encoder output, you would require a composer (and an >>> > > > > associating node). mp4 composer is one such example. >>> > >>> > > > > Now, I am not aware of the QCELP format. So, you would need to >>> make a >>> > > > > decision whether or not it requires a composer or not. Or, you >>> could >>> > > > > discuss it here and we can come to a common solution. >>> > >>> > > > > Hope that helps, >>> > > > > Ravi >>> > >>> > > > > On Mar 23, 12:23 am, David Wan <[email protected]> wrote: >>> > >>> > > > > > I'm sorry if this is a newbie question. >>> > > > > > The truth is I plan to let PVAuthor support the recording of >>> QCELP. >>> > > > > > According to the info of pvauthor found on Google, it seems >>> that a >>> > > composer >>> > > > > > for qcelp is necessary. But I'm not sure of that. I'm sorry I >>> have >>> > > no >>> > > > > > sense where I should start to handle this issue. As you >>> mentioned, >>> > > does ADIF >>> > > > > > or ADTS suffice? Could you please specify more detail? THANKS. >>> > >>> > > > > > 2009/3/23 rktb <[email protected]> >>> > >>> > > > > > > AAC can be composed in two ways. (i) In a mp4 container, >>> which then >>> > > > > > > uses mp4 composer. And, (ii) as ADIF or ADTS format, which >>> then >>> > > uses >>> > > > > > > the fileoutput node. There is no specific composer required. >>> > >>> > > > > > > Please note: You still require an AAC encoder, which is not >>> part of >>> > > > > > > OpenCORE. >>> > >>> > > > > > > -Ravi >>> > >>> > > > > > > On Mar 22, 9:19 pm, david <[email protected]> wrote: >>> > > > > > > > Hi Rktb, >>> > >>> > > > > > > > According to your announce - 'Added support for authoring >>> files >>> > > with >>> > > > > > > > AAC audio', can I think that there should be a composer for >>> AAC >>> > > > > > > > enclosed in this latest package? But I do not find it even >>> though >>> > > I've >>> > > > > > > > 'repo sync' for several times. >>> > >>> > > > > > > > The real issue I'm facing is that I want to create a >>> composer for >>> > > > > > > > QCELP, but the only one sample of composer existing in >>> OpenCore >>> > > is the >>> > > > > > > > one for MP4. It's complicated and have nothing with QCELP, >>> I >>> > > think. >>> > > > > > > > So, I want to get the latest version for the AAC composer >>> and get >>> > > > > > > > reference to it to create QCELP's composer. >>> > >>> > > > > > > > Could you please help me this issue? THANKS. >>> > >>> > > > > > > > On Mar 23, 9:43 am, david <[email protected]> wrote: >>> > >>> > > > > > > > > Great, many thanks to you. >>> > >>> > > > > > > > > On Mar 21, 3:51 pm, rktb <[email protected]> wrote: >>> > >>> > > > > > > > > > fyi...2.1 release was renamed 2.01. And, there is an >>> update >>> > > to that >>> > > > > > > > > > release as well, i.e., we are now at OpenCORE 2.02. >>> > >>> > > > > > > > > > The latest using "repo sync" would get you 2.02. >>> > >>> > > > > > > > > > -Ravi >>> > >>> > > > > > > > > > On Mar 21, 1:50 am, david <[email protected]> wrote: >>> > >>> > > > > > > > > > > Hi, I'm a newbie on Android & OpenCore. And now I got >>> the >>> > > OpenCore >>> > > > > > > 2.0 >>> > > > > > > > > > > source by using 'repo sync'. But I don't know how to >>> get >>> > > this >>> > > > > > > > > > > latest version 2.1 of OpenCore. Could you help me >>> with >>> > > this? >>> > > > > > > Thanks >>> > > > > > > > > > > a lot. >>> > >>> > > > > > > > > > > On Feb 26, 10:27 pm, GregS <[email protected]> wrote: >>> > >>> > > > > > > > > > > > OpenCORE 2.1 has been released and is now available >>> on >>> > > the master >>> > > > > > > > > > > > branch. There is a git tag "v2.1" marking the >>> version. >>> > > It >>> > > > > > > contains a >>> > > > > > > > > > > > number of new features and improvements on top of >>> the >>> > > OpenCORE >>> > > > > > > 2.0 >>> > > > > > > > > > > > release that happened about 1 month ago. Here's a >>> link >>> > > to the >>> > > > > > > > > > > > previous announcement in case you missed it: >>> > >>> > > >>> http://groups.google.com/group/android-framework/browse_thread/thread.. >>> .. >>> > > > > > > > > > > > Below is a description of the changes that have >>> been >>> > > introduced >>> > > > > > > since >>> > > > > > > > > > > > then as part of OpenCORE 2.1: >>> > >>> > > > > > > > > > > > New Features >>> > > > > > > > > > > > * OpenMAX Codec-related: >>> > > > > > > > > > > > - Introduced the OMXConfigParser API to help in >>> > > determining >>> > > > > > > > > > > > which OpenMAX components can support the input >>> > > bitstream. >>> > > > > > > > > > > > It is used to narrow the list of candidate >>> OpenMAX >>> > > components >>> > > > > > > > > > > > to be used for playback. See the OpenMAX Core >>> > > Integration >>> > > > > > > Guide >>> > > > > > > > > > > > document in the doc directory for more >>> information. >>> > > > > > > > > > > > - Added OMX AAC encoder support in the OMX >>> encoder. >>> > > > > > > > > > > > - Modified to use separate component roles for >>> AMR-NB >>> > > and >>> > > > > > > AMR-WB as >>> > > > > > > > > > > > described in the OpenMAX IL spec version 1.1.2. >>> > > > > > > > > > > > - Added support for a new buffer format for >>> H.264/AVC >>> > > decode >>> > > > > > > and >>> > > > > > > > > > > > encode >>> > > > > > > > > > > > to allow passing multiple NALs in a single >>> buffer. >>> > > The >>> > > > > > > format >>> > > > > > > > > > > > uses >>> > > > > > > > > > > > OMX_OTHER_EXTRADATA structure defined in >>> section >>> > > 4.2.33 of >>> > > > > > > the >>> > > > > > > > > > > > OpenMAX IL spec version 1.1.2 to pass NAL >>> lengths. >>> > > See the >>> > > > > > > > > > > > OpenMAX Core Integration Guide document in the >>> doc >>> > > directory >>> > > > > > > > > > > > for more information. >>> > > > > > > > > > > > * Author-related: >>> > > > > > > > > > > > - Added support for authoring files with AAC >>> audio. >>> > > > > > > > > > > > - Added support for authoring AMR-WB audio to >>> MP4/3GP >>> > > files and >>> > > > > > > > > > > > IETF storage format. >>> > > > > > > > > > > > - Added support for writing to an open file >>> descriptor >>> > > as an >>> > > > > > > option >>> > > > > > > > > > > > instead of simply providing a filename. The >>> file >>> > > descriptor >>> > > > > > > > > > > > option >>> > > > > > > > > > > > is useful for cases where another process needs >>> to >>> > > open the >>> > > > > > > file >>> > > > > > > > > > > > because >>> > > > > > > > > > > > of permissions. >>> > > > > > > > > > > > * Added large file support in OSCL (i.e., 64-bit >>> file >>> > > size/offset >>> > > > > > > > > > > > support) >>> > > > > > > > > > > > to handle files greater than 2 GiB on filesystems >>> that >>> > > support >>> > > > > > > it. >>> > > > > > > > > > > > * Added rotation support in the 32-bit >>> color-conversion >>> > > class. >>> > >>> > > > > > > > > > > > Improvements >>> > > > > > > > > > > > * Removed dynamically loaded modules from the >>> prelink map >>> > > to >>> > > > > > > avoid >>> > > > > > > > > > > > clutter >>> > > > > > > > > > > > and to make both the prelink map and loadable >>> modules >>> > > easier to >>> > > > > > > > > > > > manage. >>> > > > > > > > > > > > There may be an issue if a single instance of >>> process >>> > > tries to >>> > > > > > > load >>> > > > > > > > > > > > libraries not in the prelink map more than 256 >>> times >>> > > > > > > (Seehttp://code.google.com/p/android/issues/detail?id=2042). >>> > > > > > > > > > > > * Update to the MP3 Decoder to fix security issue >>> > > > > > > (oCERT_2009-002, >>> > > > > > > > > > > > CVE-2009-0475) >>> > > > > > > > > > > > * Renamed the OSCL config directory linux_nj to >>> android >>> > > to match >>> > > > > > > the >>> > > > > > > > > > > > platform name. >>> > > > > > > > > > > > Replaced all references of nj with android in the >>> > > codebase. >>> > > > > > > > > > > > * General security improvements found from static >>> > > analysis in the >>> > > > > > > > > > > > following areas: >>> > > > > > > > > > > > - Buffer and type overruns and underruns >>> > > > > > > > > > > > - Null pointer references >>> > > > > > > > > > > > * Refactored the jitter buffer node into a more >>> modular >>> > > > > > > architecture >>> > > > > > > > > > > > for >>> > > > > > > > > > > > better support of different streaming use-cases >>> and >>> > > protocols. >>> > > > > > > > > > > > * Fixed an issue in the MP3 decoder when decoding >>> for >>> > > very of >>> > > > > > > long >>> > > > > > > > > > > > durations (over 2 GiB of data). >>> > > > > > > > > > > > * General improvements found during 3GPP >>> packet-switched >>> > > > > > > streaming >>> > > > > > > > > > > > interoperability testing. >>> > > > > > > > > > > > * General improvements and resolution of issues >>> found >>> > > from module >>> > > > > > > > > > > > level and engine (player, author, 2-way) level >>> unit >>> > > testing. >>> > >>> > > > > > > > > > > > New APIs / behaviors >>> > > > > > > > > > > > * Added support in the player engine to cancel a >>> single >>> > > pending >>> > >>> > ... >>> > >>> > read more ยป >>> >>> >> > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
