similar to: opusfile 0.2 release

This is the initial release of libopusfile. Like libvorbisfile for Vorbis files, libopusfile provides a high-level API for decoding and seeking within .opus files. It includes: - Support for all files with at least one Opus stream (including multichannel files or Ogg files where Opus is muxed with something else). - Full support, including seeking, for chained files. - A simple stereo

Traditionally, Vorbis provided a high-level API for decoding and seeking in Ogg Vorbis streams, called libvorbisfile, which was packaged alongside libvorbis. This was very useful for simple players and applications which just wanted to decode a file, without building an entire media framework. The basic libopus is meant to be used in many contexts that do not require Ogg (such as RTP), and

On 2016-11-08 1:59 AM, Philipp Schafft wrote: > Some notes: > * libvorbisfile has a nice implementation of that, it also takes > care of matching the signal at the very point of the jump. I would recommend the opusfile library, which implements seeking specifically for Opus streams. https://archive.mozilla.org/pub/opus/opusfile-0.8.zip

-----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 *

Hi Ralph, I am using Http Progressive download technique to download the opus audio in chunks. So I am not sure if the Opusfile seek API will work in this case. Please correct me if I am wrong. Is there anyway to get or calculate the byte offset corresponding to the PCM time position? Then I can ask the server to serve the file from that byte onwards. Regards, Deepak. On Tue, Nov 8, 2016 at

-----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

Thanks for the quick response. That makes sense. I just wanted to make sure it wasn't an easy fix, or that I wasn't overlooking something. My scenario calls for very low latency playback with a user being able to jump between many files quickly, or seek quickly. This means I am priming the pump by downloading the first chunk of many files that are likely to be started soon. I was

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

Hi, please find attached two patches for opusfile: 1. Fix invalid pkg-config files on MinGW. 2. (trivial) Add some files to .gitignore. Two other random things I noticed: - The API reference for libopusfile linked from http://opus-codec.org/docs/ is for version 0.1. - The pkg-config files say "Description: Opus playback library". Well, the library doesn't do playback, does it?

-----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

I've developed the unofficial Opus codec support plugin for Winamp and I have been able to keep the libopusfile libraries inside a folder inside the application's install path - "%PROGRAMFILES%\WinampNarf\opusfile" - and all seemed to be fine and dandy. However, if I try to load the new libopusurl-0.dll from the same folder as I have always done as with the other libraries, I

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

AC_SEARCH_LIBS will give a result of "none required" if the relevant function is available without any special libraries. (This is the case for lrintf on MinGW.) Make sure this special value isn't put verbatim into the pkg-config files, as it would cause the linker to search for files named "none" and "required", and fail. --- configure.ac | 6

AC_SEARCH_LIBS will give a result of "none required" if the relevant function is available without any special libraries. (This is the case for lrintf on MinGW.) Make sure this special value isn't put verbatim into the pkg-config files, as it would cause the linker to search for files named "none" and "required", and fail. --- configure.ac | 6

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

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

Drew Allen wrote: > Friendly ping for supporting ambisonics in opus-tools & opusfile > > Please LMK any ?s you might have. Sorry for the long delay on the review. The high-level design looks a lot better. I have a number of comments on the implementation details. I didn't really like the way that opus_head_projection_parse() turned out. I was originally thinking something

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

Includes - A make debug target that disables optimizations and enables assertions, - Proper ./configure switches for the optional features, - A configuration summary, - libtool versioning information, - Visibility and warning flags, - API documentation, and - Support for out-of-tree builds. Signed-off-by: Diego Elio Petten? <flameeyes at flameeyes.eu> --- .gitignore | 29 +++++