Hello everyone, I have been having trouble utilizing the PLC function (I think). In older versions (0.7.1) a pointer to NULL did the trick, but with code from the tip of the GIT repository, this method causes the codec to crash on the C55x fixed point platform. I have not determined where the crash occurs. I have also attempted to pass in an array of zero's and this creates an echoey, reverby effect, but does not have any loud, full-scale artifacts. Is this the correct method for calling PLC? This does not sound nearly as good as the samples on the website. Also, while I am here, I thought I would ask if any CELT enthusiasts are migrating over to the OPUS code base? My main applications for the codec will use a fixed frame and packet size, so I will not take much advantage of the dynamic nature of the codec. But are there any other benefits in terms of audio quality/latency/error robustness that OPUS will have over CELT? Cheers bob -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attachments/20110622/c9bbae20/attachment-0002.htm
> think). In older versions (0.7.1) a pointer to NULL did the trick, but > with code from the tip of the GIT repository, this method causes theThis is the correct way to invoke PLC, not passing in an array of zeros.> codec to crash on the C55x fixed point platform. I have not determined > where the crash occurs.This sounds like a bug. We'll try to track it down, but last I checked the C55x port didn't build with the free TI tools, and I was never able to get the code actually running on my C55x.> Also, while I am here, I thought I would ask if any CELT enthusiasts are > migrating over to the OPUS code base? My main applications for theWe've migrated libcelt over to the Opus repository, so future bugfixes, etc., are all going to be over there, and not in the CELT git repository. This is a much better way of doing things than what we had before, where CELT, SILK, and Opus were all in different repositories and linked via git submodules. You can still use the libcelt API with the Opus codebase. If you have a fixed frame size and audio bandwidth, you can even strip the first byte of the Opus packet produced on the encoder side and restore it on the receiver side, so you don't have to pay any of the overhead for Opus's flexibility (assuming you're willing to give up compatibility, but if you've got a fixed packet size, etc., you probably are). I've also argued that the Opus repository should build a separate libcelt (with custom modes enabled by default) instead of just a libopus that exports the old libcelt API, but so far Jean-Marc has been resistant to that idea.
Thanks for the reply Timothy. I will work today and tomorrow to see where the NULL pointer crashes CELT on the C55x. Hopefully I'll be able to pinpoint the issue for you guys. So from your statements, it sounds like I should migrate over. I'll give this a try sometime soon. Since CELT updates seem to be on an indefinite leave of absence, can I assume it will never hit 1.0? bob -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attachments/20110622/2fa839a4/attachment-0002.htm
On 06/22/2011 10:09 AM, Bob Bang wrote:> My main applications for the codec > will use a fixed frame and packet size, so I will not take much advantage > of the dynamic nature of the codec. But are there any other benefits in > terms of audio quality/latency/error robustness that OPUS will have over CELT?If you are using frame sizes smaller than 10 ms, Opus is essentially identical to CELT. Opus also generally has about 2.5ms longer latency, i.e. 15 ms latency on 10ms frames, instead of 12.5 ms with CELT*. For speech, at rates below about 24 kbps (or 48 for stereo) and packet sizes of 10 ms or greater, Opus should sound better than CELT. Currently you must tell the encoder whether you are coding speech or music, but the developers are working on adding automatic content type detection to the encoder. The encoder would then dynamically switch between speech and music coding modes while maintaining constant frame size and duration. Also, even at fixed size and duration you could still benefit from Opus's dynamic lowpass, which allows the encoder to choose which frequencies to code for each frame. This feature is also optionally available in CELT starting in libcelt 0.11.3. The encoder currently only uses this with VBR mode, but a future encoder may also employ it in CBR. --Ben *: If you use the libcelt API with the libopus codebase, you should still get the lower CELT-style latency (2.5ms lookahead). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature Url : http://lists.xiph.org/pipermail/opus/attachments/20110622/baaa3d2c/attachment-0002.pgp
On 11-06-22 11:13 AM, Bob Bang wrote:> So from your statements, it sounds like I should migrate over. I'll give > this a try sometime soon. Since CELT updates seem to be on an indefinite > leave of absence, can I assume it will never hit 1.0?Sure it will. It'll just change spelling to O-P-U-S. Jean-Marc