similar to: Minor API change

Displaying 20 results from an estimated 50000 matches similar to: "Minor API change"

2009 Oct 16
3
API Change
Hi everyone, I've just changed the API for CELT, but at least there's a good reason for that. It's now possible to use the same mode data for both mono and stereo. So here's the change: - The celt_mode_create() function has a "channels" parameter - The celt_encode_create() and celt_decoder_create() functions now have an additional "channels" parameter. - I
2010 May 18
9
Variable frame size and API changes
Hi everyone, I've recently been making various changes to the way the modes work and the supported frame size. On new feature that may be of interest to some is that CELT should soon support changing the frame size dynamically within a stream. By that I mean varying the amount of audio (in time) transmitted at once, not the compressed size -- which has always been variable. That would
2013 Oct 30
1
libopus API question - 120ms encoding
Thanks Jean-Marc and Benjamin for the answers. One follow-up question. If I use a repacketizer as Jean-Marc suggested by combining two 60ms frames to form a 120ms frame, without extracting individual frames and using a new TOC, I would need to have a "de-packetizer" that does the exact opposite of repacketizer. De-packetizer would need to separate this 120ms frame into two 60ms frames
2013 Oct 26
0
libopus API question - 120ms encoding
On 10/26/2013 01:11 PM, Wang, Chris wrote: > A simpler question. How does opus_encode() generate packets of 20ms > (SILK-only or Hybrid)? Concatenating two 10ms frames or doing it > straight with just one 20ms frame? Just one 20 ms frame. It always returns a single frame except when it just can't (e.g. 60 ms CELT). > From your explanations below, opus_encode() will concatenate
2009 Jul 06
2
CELT 0.6.0 released, submitted as IETF draft
Hi everyone, I'm pleased to announce version 0.6.0 of CELT, with many quality improvements. This includes better stereo coupling, better handling of transients, and better handling of highly tonal signals. In addition, packet loss robustness has been improved through the optional use of independent (intra) frames. CELT now supports a larger dynamic range, suitable for encoding 24-bit audio
2010 Apr 03
2
Speex API when Executing giving --->* *Access Violation
Hi Jean , ( You can obtain a BSD license by printing the header of most of the CELT source code files. ) How to obtain BSD License for my win32 console application ? ( printing the header of most of the CELT source code files. ) Can u explain in detail Unfortunately i didnt understand the printing header of sx code .... Ur Help will greatly appreciable Thanks Aparna 2010/4/2 Jean-Marc
2010 Aug 18
2
C Prog
Hi, does anyone have small programms in C, one to encode and one to decode with celt, that I could use for a fpga chip softcore? greets yon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attachments/20100819/7cd96a41/attachment-0002.htm
2010 Aug 17
3
Total Harmonic Distortion THD
Hi Has anybody done THD or THD-N measurements with the CELT Codec (bext would be on various bit rates) If someone could share results for Mono at 64kBit and Stereo at 128 and 196kBit it would be great. thank you very much Jochen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attachments/20100817/b1da17cc/attachment-0002.htm
2015 Jul 06
1
Disable SILK/CELT only?
I saw the custom API, but nothing explicitly says "CELT-only" just "custom sample rate and frame size". I'll dig further now that you've pointed me in a direction. Thanks, -a On 7/6/15, 6:18 PM, Jean-Marc Valin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I believe what you want is called Opus custom (OPUS_CUSTOM in the > code).
2015 Nov 27
1
Test failed!!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Indeed, the reason that -msse* are there is because it's needed for actually compiling the tests (because of the #include of the intrinsics). But of course, -msse* has the side effect of (sometimes) producing illegal instructions. We'll definitely need to fix this, but I don't know how yet. In the mean time, you can either trust that the
2009 Oct 02
1
Many changes recently
Hi Everyone, I just merged a lot of changes in the CELT master branch. This should solve the following issues: - tonal artefacts (birdies) at low bit-rate - tonal artefacts in stereo at all rates - low-frequency noise (roughness) on low bit-rate speech The code has been simplified a lot, but there's lots of changes, so please give this a try and see if anything got broken. Cheers,
2010 Jul 02
1
CELT 0.8.0 is out
Hi everyone, Just wanted to let you know that 0.8.0 is out. You can get it from the usual place and here's the small notes that go with it: "CELT 0.8.0 brings quality improvements for high bit-rates and for transients in general. It also adds the possibility of changing the frame size dynamically, which requires a minor change in the API. At last, the new PLC algorithm from 0.7.1 is
2015 Nov 26
2
Test failed!!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Jesus, Thanks for the report. As far as I can tell, what's happening is that when intrinsics are enabled, we compile all tests with -msse4.1, even when it's only run-time detected. In most cases, that doesn't cause any issue, but sometimes the compiler will take the C code and generate an SSEx instruction on its own. I think this is
2010 Jul 06
3
V0.8.0 Problems
Tim, et al, I have run into several problems with V0.8.0. I will address them seperately. 1. My compiler is complaining about the following code in celt.c which seems to define metric first as celt_word32, then as celt_word16. Am I mis-interpreting something? ?? VARDECL(celt_word32, metric); ?? ALLOC(metric, len, celt_word16); Thx MikeH -------------- next part -------------- An HTML attachment
2010 Apr 03
1
Speex API when Executing giving --->* *Access Violation
I am not clear, How to do can u tell exactly tell me wat to do ??? Plz Thanks Aparna On Sat, Apr 3, 2010 at 5:53 PM, Jean-Marc Valin < jean-marc.valin at usherbrooke.ca> wrote: > > > On 2010-04-03 04:47, Nikki Appu wrote: > >> >> Hi Jean , >> >> ( You can obtain a BSD license by printing the header of most of the >> CELT source >> code
2014 Nov 07
0
opus Digest, Vol 70, Issue 3
Hi All, Cortex-M4 is a single issue CPU whereas A8 is dual issue so this is the main reason you are seeing a slow-down, use of NEON I would say is secondary, certainly for CELT. We (ESPICO) have done optimisation work on OPUS v1.1 and have ARM implementations about twice the speed of the 'off the shelf' version. Please contact me directly if you want to discuss further. Cliff
2015 Nov 27
0
Test failed!!
On 26/11/15 20:00, Jean-Marc Valin wrote: > Hi Jesus, > > Thanks for the report. As far as I can tell, what's happening is that > when intrinsics are enabled, we compile all tests with -msse4.1, even > when it's only run-time detected. In most cases, that doesn't cause > any issue, but sometimes the compiler will take the C code and > generate an SSEx instruction
2015 Jan 29
0
[RFC PATCH v1 2/2] armv7(float): Optimize encode usecase using NE10 library
Hi Timothy, Appreciate the comprehensive code review. The biggest issue I see is the peak stack usage.... rest looks like fairly straight forward cleanup. Is the peak stack usage a complete blocker in current form? If it is indeed a blocker, would it be acceptable if we can reduce additional buffer requirement from 2 buffers (current) to 1, possibly by moving scaling inside
2015 Nov 26
0
Test failed!! (was: Re: Opus 1.1.1 is out!)
On 26/11/15 16:40, Jean-Marc Valin wrote: > Please report any issue you find in this release. Using the new SS4.1 code I see a 30% performance increase in my 7 years old AMD laptop. I compile with this: ./configure --disable-static --enable-intrinsics \ --enable-float-approx "make test" runs fine. Great. When I try to do the same on a server running Ubuntu
2018 Feb 26
0
opus Digest, Vol 109, Issue 8
We have found that it is possible to achieve a 30 to 50% reduction in MHz requirement for implementation of OPUS on Cortex M4 compared to the public version (v1.3 beta/v1.2.1). For the CELT configuration you mention (complexity 0, 16kHz, mono, 20ms) we are measuring a 4ms encode time and a 3ms decode time for that platform (32kbit/s). An important issue that I haven't seen much discussion