Mahantesh Belakhindi
2013-May-13 19:53 UTC
[opus] DSPs which are suitable for porting OPUS
Dear Christian van Bijleveld, You can use any of the below DSPs of Texas Instruments 1. TMS320C674x - This supports floating point implementation of opus 2. TMS320C66x - This supports both floating and fixed point implementations 3. TMS320C64x - This supports only fixed point implementation Regards, Mahantesh On Mon, May 13, 2013 at 10:12 PM, <opus-request at xiph.org> wrote:> Send opus mailing list submissions to > opus at xiph.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.xiph.org/mailman/listinfo/opus > or, via email, send a message with subject or body 'help' to > opus-request at xiph.org > > You can reach the person managing the list at > opus-owner at xiph.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of opus digest..." > > > Today's Topics: > > 1. opus_demo produces garbage (Hermann Weber) > 2. Re: opus_demo produces garbage (Jean-Marc Valin) > 3. Re: opus_demo produces garbage (Hermann Weber) > 4. Exact audio position (Hermann Weber) > 5. Quality difference between opus_demo.exe and opusenc.exe > (Hermann Weber) > 6. OPUS in embedded platform (van Bijleveld Christian (ST-CO/ENG1.3)) > 7. Re: opus file trimming/clipping (Matt Ruck) > 8. Re: Exact audio position (Ian Malone) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 13 May 2013 07:43:55 +0200 > From: Hermann Weber <hermie.weber at gmx.de> > Subject: [opus] opus_demo produces garbage > To: opus at xiph.org > Message-ID: <51907D9B.50803 at gmx.de> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello! > > I am running opus_demo.exe with the following cmds: > > -e audio 48000 1 16 -cbr m:\test\test1.raw m:\test\test1.opus > > When I open the .opus file with a hex editor, I see only > > > 00000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000 > > This pattern repeats over and over again. > > What might go wrong here? > > Greetings, > Hermann > > > > ------------------------------ > > Message: 2 > Date: Mon, 13 May 2013 02:04:42 -0400 > From: Jean-Marc Valin <jmvalin at jmvalin.ca> > Subject: Re: [opus] opus_demo produces garbage > To: Hermann Weber <hermie.weber at gmx.de> > Cc: opus at xiph.org > Message-ID: <5190827A.1090305 at jmvalin.ca> > Content-Type: text/plain; charset=ISO-8859-1 > > What you're looking at is the compressed result of trying to encode your > file at 16 *bits* per second (0.016 kbit/s). > > Jean-Marc > > On 05/13/2013 01:43 AM, Hermann Weber wrote: > > Hello! > > > > I am running opus_demo.exe with the following cmds: > > > > -e audio 48000 1 16 -cbr m:\test\test1.raw m:\test\test1.opus > > > > When I open the .opus file with a hex editor, I see only > > > > > 00000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000 > > > > This pattern repeats over and over again. > > > > What might go wrong here? > > > > Greetings, > > Hermann > > > > _______________________________________________ > > opus mailing list > > opus at xiph.org > > http://lists.xiph.org/mailman/listinfo/opus > > > > > > ------------------------------ > > Message: 3 > Date: Mon, 13 May 2013 08:16:59 +0200 > From: Hermann Weber <hermie.weber at gmx.de> > Subject: Re: [opus] opus_demo produces garbage > To: Jean-Marc Valin <jmvalin at jmvalin.ca> > Cc: opus at xiph.org > Message-ID: <5190855B.8060304 at gmx.de> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Okay, got it, thanks. > > opus_demo.exe solved all my problems, I think. > Good sample code. > > Thanks. > Hermie > > Am 13.05.2013 08:04, schrieb Jean-Marc Valin: > > What you're looking at is the compressed result of trying to encode your > > file at 16 *bits* per second (0.016 kbit/s). > > > > Jean-Marc > > > > On 05/13/2013 01:43 AM, Hermann Weber wrote: > >> Hello! > >> > >> I am running opus_demo.exe with the following cmds: > >> > >> -e audio 48000 1 16 -cbr m:\test\test1.raw m:\test\test1.opus > >> > >> When I open the .opus file with a hex editor, I see only > >> > >> > 00000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000 > >> > >> This pattern repeats over and over again. > >> > >> What might go wrong here? > >> > >> Greetings, > >> Hermann > >> > >> _______________________________________________ > >> opus mailing list > >> opus at xiph.org > >> http://lists.xiph.org/mailman/listinfo/opus > >> > > > > > > ------------------------------ > > Message: 4 > Date: Mon, 13 May 2013 10:45:00 +0200 > From: Hermann Weber <hermie.weber at gmx.de> > Subject: [opus] Exact audio position > To: opus at xiph.org > Message-ID: <5190A80C.6020201 at gmx.de> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello! > > I need to extract audio data at a certain position in respect to the > original audio data. > > Is the "-cbr" switch meant to ensure that data can be found on a > specific position? > > I want to be able to predict where certain audio can be found in the > encoded data. > > An example: > If you put 10 apples into a box and then compress the box, you will not > be able to predict where apple C can be found in the box. > Perhaps apple B could be compressed more than apple C, and now the > "position" of apple C is not predictable anymore. > This is exactely NOT what I want :-) > > Greetings, > Hermann > > > ------------------------------ > > Message: 5 > Date: Mon, 13 May 2013 13:24:06 +0200 > From: Hermann Weber <hermie.weber at gmx.de> > Subject: [opus] Quality difference between opus_demo.exe and > opusenc.exe > To: opus at xiph.org > Message-ID: <5190CD56.80103 at gmx.de> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello! > > I encoded a voice file (48kHz) with opusbin\opusenc.exe with the > standard settings and decoded it. > The output was amazing. I could not hear any loss at all. > > Then i encoded the same file with opus_demo.exe and standard settings > and then decoded it. > The output had a sizzling noise, even when I used full bandwidth. > > I think I have played around with any of the settings in opus_demo.exe, > but I just can not get these amazing results as with opusbin\opusenc.exe. > > What may I have missed? > > Thank you. > > Hermann > > > ------------------------------ > > Message: 6 > Date: Mon, 13 May 2013 14:57:55 +0200 > From: "van Bijleveld Christian (ST-CO/ENG1.3)" > <Christian.vanBijleveld at nl.bosch.com> > Subject: [opus] OPUS in embedded platform > To: "opus at xiph.org" <opus at xiph.org> > Message-ID: > <8E99D2CE27782C4BA15262EE04CE7AA37952CEC3E9 at SI-MBX18.de.bosch.com> > Content-Type: text/plain; charset="us-ascii" > > Hello, > > > I am interested in porting OPUS to an embedded platform. The idea is that > the encoder and decoder will run on different processors. In order to > choose the proper platform, I need an estimate of the resources which are > needed for OPUS. > > I read the following in the OPUS wiki: > > "The Opus code base is written in C89 and should run on the vast majority > of recent (and not so recent) CPUs. A few of the platforms on which Opus > has been tested and is known to run include x86, x86-64, ARM, Itanium, > Blackfin, and SPARC." > Are there, or is it known, figures regarding the resources needed for OPUS > to run on an embedded platform such as DSP or microprocessor? If exact > figures are not available, but if anyone can give an indication about which > type of platform is required at least, I would appreciate very much. I can > image that the amount of resources for the encoder and the decoder may be > different. > > Another question: does OPUS need the support of an Operating System or > Real Time Kernel (ie; threads,...)? > > > Met vriendelijke groeten | Best Regards, > Christian van Bijleveld > > Bosch Security Systems BV > Bosch Communications Systems, BL Public Address and Conference Systems > (ST-CO/ENG1.3) > P.O. Box 80 002 > 5600 JB Eindhoven > The Netherlands > www.boschsecurity.com<http://www.boschsecurity.com> > T. +31 (0)40 257 7076 > F. +31 (0)40 257 7091 > christian.vanbijleveld at nl.bosch.com<mailto: > christian.vanbijleveld at nl.bosch.com> > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.xiph.org/pipermail/opus/attachments/20130513/1e31aa21/attachment-0001.htm > > ------------------------------ > > Message: 7 > Date: Mon, 13 May 2013 09:17:45 -0400 > From: Matt Ruck <ultymatt at gmail.com> > Subject: Re: [opus] opus file trimming/clipping > To: Ralph Giles <giles at thaumas.net> > Cc: opus <opus at xiph.org> > Message-ID: > <CAPNsZ0wLhOjdZKPakGKqMKRop_=07TnWfKEBzcOk> e8XKJfmNg at mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Thanks for your responses. I am potentially interested in developing a > simple tool to trim a section of an Opus file, similar to the functionality > of vcut or sox. What I would need to know is an estimate of how involved > (difficulty and time commitment ) it would be for someone like me, with > very little experience working with audio or programming in C (although I > am much more comfortable with higher level languages). I have the source > code for vcut for reference -- assuming that a similar tool for Opus could > be based on this, could most of this be reused? > > > On Thu, May 9, 2013 at 7:17 PM, Ralph Giles <giles at thaumas.net> wrote: > > > On 13-05-09 2:06 PM, Matt Ruck wrote: > > > > > Would trimming in another format like WAV or Ogg using existing tools, > > > and then encoding to Opus be a good way accomplish trimming a sound > > > track for Opus, and if so, what tools might be best (e.g., vcut was > > > previously mentioned)? > > > > Trimming WAV and then encoding to Opus would give you equivalent quality > > and is something which can be done with existing tools. You can trim a > > wave file with the command-line sox tool, or e.g. Audacity, a graphical > > audio editor. > > > > Something like 'sox in.wav trim 12:53.6 30 out.wav' will cut out 30 > > seconds of audio starting at 12 minutes 53.6 seconds into the file. > > > > That said, if you want to try writing a lossless Opus trimmer, we'd be > > happy to help. That' something the Ogg Opus draft which hasn't seen any > > implementation feedback on. > > > > -r > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.xiph.org/pipermail/opus/attachments/20130513/7ce5d621/attachment-0001.htm > > ------------------------------ > > Message: 8 > Date: Mon, 13 May 2013 17:42:26 +0100 > From: Ian Malone <ibmalone at gmail.com> > Subject: Re: [opus] Exact audio position > To: opus at xiph.org > Message-ID: > < > CAL3-7MqRv-Ku-uHYTfH0+qt3KZyK3_bP1hHt5mW5O--rCfP_WQ at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On 13 May 2013 09:45, Hermann Weber <hermie.weber at gmx.de> wrote: > > > Hello! > > > > I need to extract audio data at a certain position in respect to the > > original audio data. > > > > Is the "-cbr" switch meant to ensure that data can be found on a > > specific position? > > > > I want to be able to predict where certain audio can be found in the > > encoded data. > > > > An example: > > If you put 10 apples into a box and then compress the box, you will not > > be able to predict where apple C can be found in the box. > > Perhaps apple B could be compressed more than apple C, and now the > > "position" of apple C is not predictable anymore. > > This is exactely NOT what I want :-) > > > > > > > (Oops, replied off-list by mistake) > > The encapsulation records this information, for Opus in Ogg you want > 'granule position': > http://tools.ietf.org/html/draft-ietf-codec-oggopus-00#section-4 > https://wiki.xiph.org/GranulePosAndSeeking > > I'm less familiar with RTP, but I think the RTP timestamp is probably the > equivalent thing: > http://tools.ietf.org/html/draft-spittka-payload-rtp-opus-03 > > > > -- > imalone > http://ibmalone.blogspot.co.uk > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.xiph.org/pipermail/opus/attachments/20130513/4a30dc2e/attachment.htm > > ------------------------------ > > _______________________________________________ > opus mailing list > opus at xiph.org > http://lists.xiph.org/mailman/listinfo/opus > > > End of opus Digest, Vol 52, Issue 12 > ************************************ >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attachments/20130514/00f81baf/attachment-0001.htm
Possibly Parallel Threads
- opus Digest, Vol 52, Issue 15
- Quality difference between opus_demo.exe and opusenc.exe
- OPUS in embedded platform
- [Attachment has been removed]Audio Mode vs. VoIP Mode
- Decoding only a certain frame results in different values than when decoding the entire file