similar to: opusfile 0.1 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 *

We've made a new release of Tim's opusfile library. Like libvorbisfile for Vorbis files, libopusfile provides a high-level API for decoding and seeking within .opus files. Changes since the previous release: - Accept valid SSL certificates. - Various build and packaging fixes. The library is functional, but there are likely issues we didn't find in our own testing. Please give

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

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

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

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

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

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

--- This includes the check target that Tim requested. Signed-off-by: Diego Elio Petten? <flameeyes at flameeyes.eu> --- .gitignore | 24 ++++++++++++++++++++++++ Makefile.am | 22 ++++++++++++++++++++++ configure.ac | 14 ++++++++++++++ 3 file modificati, 60 inserzioni(+) create mode 100644 .gitignore create mode 100644 Makefile.am create mode 100644 configure.ac diff --git

On 20/08/13 08:38 PM, alpha thinktink wrote: > 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 get a NULL HMODULE > handle from LoadLibraryW and GetLastError() return error code 126 - "The > specified module could not be found." In addition to what Tim said, do you get the same error loading

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

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

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

Friendly ping for supporting ambisonics in opus-tools & opusfile Please LMK any ?s you might have. Cheers, Drew -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20180410/fd4a3709/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name:

alpha thinktink wrote: > On Sun, Aug 25, 2013 at 8:53 PM, Timothy B. Terriberry > <tterribe at xiph.org <mailto:tterribe at xiph.org>> wrote: > > alpha thinktink wrote: > > You've got "_host" instead of "_user" in the definition for the macro > > for "OP_HTTP_PROXY_USER" > > Yeah, already fixed in >

This time it's complete with assertions on make debug, proper ./configure switches for the optional features, visibility and warning flags, and summary at the end of the configuration. Signed-off-by: Diego Elio Petten? <flameeyes at flameeyes.eu> --- .gitignore | 29 +++++ Makefile.am | 24 +++++ autogen.sh | 3 + configure.ac | 66 ++++++++++++

Hello Jean-Marc, Thanks for the quick reply and comments. On Thu, May 26, 2016 at 5:41 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Michael, > > Here's some more minor comments below. As long as you address the two > comments from my previous email (254 -> 2 and the draft name), the draft > is good for submitting as initial version on the IETF website (even