similar to: How to link files needed for opus encoding to Qt project

I would like to decode an Opus file in chunks (e.g. 16K byte array). Is this possible with the Opusfile library or would I need to interface directly with libogg and libopus? It seems like the Opusfile decoder functions maintain an internal pointer/state for OggOpusFile during multiple calls to op_read(OggOpusFile *_op ...) and a complete byte array of the entire Opus file would be needed. Any

You might want to take a look at the op_open_callbacks API: https://opus-codec.org/docs/opusfile_api-0.7/group__stream__open__close.html#ga5b81c0b685f3d3c9c7d7091e5536c759 libopusfile will only call your provided read() function as needed. If you don't implement the seeking functions, it will only read it in a linear order. On 04/06/2018 09:08 AM, Chris McGowan wrote: > I would like to

Drew Allen wrote: > Please feel free to ask any questions or give any feedback you might > have. :) A few comments from a quick glance through the opusfile patch: You unconditionally #include <opus_projection.h> in the public header, but you haven't updated the libopus version requirement in configure.ac. Ideally, of course, libopusfile would continue to work with older

Excellent, thanks Tim for writing back so quickly! Cheers, Drew On Tue, Mar 6, 2018 at 6:25 PM, Timothy B. Terriberry <tterribe at xiph.org> wrote: > Drew Allen wrote: > >> Please feel free to ask any questions or give any feedback you might >> have. :) >> > > A few comments from a quick glance through the opusfile patch: > > You unconditionally

Hi I’m currently trying to implement the Opus codec on a nRF 52 DK (from Nordic). One main goal of my project is a low power application that can record and send audio data (16+ kHz) over BLE. Therefore, the Opus audio codec would be suitable to encode audio data, send it over BLE and decode it on another chip. Unfortunately, I have some trouble implementing it. There are different parts to the

Hello all! I've attached an updated patch for opusfile, based on formatting suggestions I got for the opus and libopusenc patches. Cheers! Drew On Thu, Mar 22, 2018 at 9:19 AM Drew Allen <bitllama at google.com> wrote: > Thanks! 2 down, 2 to go. :D :D :D > > On Wed, Mar 21, 2018 at 11:19 PM Jean-Marc Valin <jmvalin at jmvalin.ca> > wrote: > >> Thanks, the

Minor thing missed: Adding the files to the VS project file. (Sorry for the direct reply, Drew, Gmail's interface always trips me up on mailing lists.) On Fri, Jul 6, 2018 at 6:06 PM Joshua Bowman <silverbacknet at gmail.com> wrote: > Minor thing missed: Adding the files to the VS project file. > > (Sorry for the direct reply, Drew, Gmail's interface always trips me up

Hello all, Sorry for the delay (got really sick last week). Attached are updated patches for libopus, libopusenc, opusfile and opus-tools. Note that the patches for libopusenc, opusfile and opus-tools are dependent on the patch for libopus. Please let me know if you have any additional followup comments or questions. Cheers, Drew -------------- next part -------------- An HTML attachment was

Hi Jean-Marc, I've modified my patches for libopus and libopusenc based on your suggestions. Cheers, Drew On Mon, Mar 19, 2018 at 2:05 PM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Drew, > > I think the libopusenc patch is better, but there's still a few issues > left: > 1) The static MAX_PACKET_BUFFER_SIZE value is still problematic because > if you

Hi Mark, Drew, On 03/20/2018 02:40 AM, Mark Harris wrote: > + int _oge_use_projection(int channel_mapping); > > These functions are part of libopusenc, so I'd expect them to have an > ope prefix like the other functions in the libopusenc library. I'd like to avoid using the ope_ prefix for functions that's aren't in the public API. Right now there are other functions

On 03/20/2018 11:51 AM, Drew Allen wrote: > Just to confirm, I would use opeint_* for all the > OpusGenericEncoder-related functions? Correct. Or you can also use oge_ if you like. Just don't use something that starts with an underscore. > On Tue, Mar 20, 2018 at 8:38 AM Jean-Marc Valin <jmvalin at jmvalin.ca > <mailto:jmvalin at jmvalin.ca>> wrote: > > Hi

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 opusfile version 0.6 I'm pleased to annouce the latest development release of the opusfile playback library. Changes since the v0.5 release: - Fix bugs with comment handling - Fix build for BSD - Fix bugs handling invalid and non-opus streams Some of these bugs kept basic functionality of the APIs from working at all, so we recommend all

opusfile version 0.9 is availble. Thanks to everyone who contributed! The opusfile and opusurl libraries provide a high-level API for decoding and seeking within .opus files on disk or over http(s). opusfile depends on libopus and libogg. opusurl depends on opusfile and openssl. Binaries for macOS will be available through homebrew soon. Changes since the v0.8 release: - Fix an invalid free

Thanks, the libopus and the libopusenc patches are now merged. Cheers, Jean-Marc On 03/20/2018 12:36 PM, Drew Allen wrote: > Attached is an updated patch based on Jean-Marc and Mark's comments. :) > > Cheers, > Drew > > On Tue, Mar 20, 2018 at 9:20 AM Jean-Marc Valin <jmvalin at jmvalin.ca > <mailto:jmvalin at jmvalin.ca>> wrote: > > On

I'm pleased to announce the release of opusfile v0.7. The opusfile and opusurl libraries provide a high-level API for decoding and seeking within .opus files on disk or over http(s). Changes since the v0.6 release: - Add API to access and preserve binary metadata. - Add support for R128_ALBUM_GAIN metadata tag. - Better seeking with continued packets and multiplexed streams. - Portability

A new opusfile source release is available. The opusfile and opusurl libraries provide a high-level API for decoding and seeking within .opus files on disk or over http(s). opusfile depends on libopus and libogg. opusurl depends on opusfile and openssl. Changes since the v0.7 release: - Add support for OpenSSL 1.1.x. - Fix issues with tag parsing introduced in v0.7. - Fix skip logic for

On Mon, Mar 19, 2018 at 11:52 AM Drew Allen <bitllama at google.com> wrote: > Hello all, > > Sorry for the delay (got really sick last week). > > Attached are updated patches for libopus, libopusenc, opusfile and > opus-tools. > > Note that the patches for libopusenc, opusfile and opus-tools are > dependent on the patch for libopus. > > Please let me know if

Apologies! That patch will not work correctly with Opus 1.2. Will send an updated patch shortly!! On Mon, Mar 26, 2018 at 11:56 AM Drew Allen <bitllama at google.com> wrote: > Hello all! > > I've attached an updated patch for opusfile, based on formatting > suggestions I got for the opus and libopusenc patches. > > Cheers! > Drew > > On Thu, Mar 22, 2018 at

Hi Drew, I think the libopusenc patch is better, but there's still a few issues left: 1) The static MAX_PACKET_BUFFER_SIZE value is still problematic because if you link libopusenc with a new version of libopus that supports higher order projection or just more projection channels for order 3, then you will overflow the buffer. I think what you'd want is a _ope_opus_header_get_size() call

I'm pleased to announce the release of opusfile 0.12 The opusfile library provides seeking, decode, and playback of Opus streams in the Ogg container (.opus files) including over http(s) on posix and windows systems. opusfile depends on libopus and libogg. The included opusurl library for http(s) access depends on opusfile and openssl. Changes since the v0.11 release: - Fix stack overflow