similar to: opusfile 0.8 release

Displaying 20 results from an estimated 12000 matches similar to: "opusfile 0.8 release"

2016 Jan 06
0
opusfiles 0.7 release
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
2014 Jun 13
0
opusfile 0.6 released
-----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
2017 Aug 03
0
opusfile 0.9 release
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
2020 Jun 30
0
opusfile 0.12 release
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
2013 Aug 20
4
opusfile 0.4 release
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm pleased to announce the availability of opusfile v0.4. The opusfile and opusurl libraries provide a high-level API for decoding and seeking within .opus files on disk or over http(s). * https://ftp.mozilla.org/pub/mozilla.org/opus/opusfile-0.4.tar.gz * https://ftp.mozilla.org/pub/mozilla.org/opus/opusfile-0.4.zip *
2013 Aug 26
1
Fwd: Re: opusfile 0.4 release
I don't know. Derf? -r -------- Original Message -------- Subject: Re: [opus] opusfile 0.4 release Date: Sat, 24 Aug 2013 14:20:35 -0700 From: alpha thinktink With my old streaming thread I am able to retrieve a unicode file from a web server by converting the resource name to UTF-8 MBCS then uri encoding it before sending it to the server with "GET /[resourcename]
2018 Mar 26
0
[PATCH] Support for Ambisonics
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
2017 Jul 26
1
Building opusfile as a shared library
Dear Opus community, I'm trying to build opusfile as a shared (.dll) library on Windows 10 using Visual Studio 2017. I know there are prebuilt libraries, but those are depending on a whole bunch of other libraries and x86 (32 bit) only. Whenever I try to build opusfile, it generates opusfile.dll, which is basically empty (no functions), which makes it unuseable. This is most likely because
2018 Jul 07
0
[PATCH] Support for Ambisonics
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
2018 Mar 19
0
[PATCH] Support for Ambisonics
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
2018 Mar 19
3
[PATCH] Support for Ambisonics
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
2018 Mar 20
0
[PATCH] Support for Ambisonics
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
2018 Mar 20
0
[PATCH] Support for Ambisonics
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
2018 Mar 22
0
[PATCH] Support for Ambisonics
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
2018 Mar 19
0
[PATCH] Support for Ambisonics
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
2018 Mar 26
3
[PATCH] Support for Ambisonics
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
2014 Jan 10
0
opusfile v0.5 release
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm pleased to announce the release of version 0.5 of Tim's opusfile library for decoding and seeking inside .opus files and remote streams over http(s). This release includes some new API calls and fixes a number of mostly minor bugs from the previous release. Programming documentation for this release is available from
2018 Mar 20
2
[PATCH] Support for Ambisonics
Just to confirm, I would use opeint_* for all the OpusGenericEncoder-related functions? On Tue, Mar 20, 2018 at 8:38 AM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > 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
2018 Mar 22
2
[PATCH] Support for Ambisonics
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 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. :) > > > >
2018 Mar 19
3
[PATCH] Support for Ambisonics
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