similar to: opusfile 0.4 release

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

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]

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

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

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

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

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

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

On 13-08-21 12:35 AM, alpha thinktink wrote: > I just had a thought and tested it out and it seemed correct. By > loading the libeay32.dll and ssleay32.dll libraries myself before > loading libopusurl-0.dll then libopusurl-0.dll loads and I can use it. > Before I was just trying to load libopusurl-0.dll without loading its > support DLLs at all assuming it would pick them up on

oops: /**Use the given user name for authentication when proxying connections. > All proxy parameters are ignored for non-http and non-https URLs. > \param _user const char *: The proxy server user name. > This may be <code>NULL</code> to disable > proxy > authentication. >

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 >

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

Just a report about compiler warnings generated when building opusfile from current git. Regards. # x86-Linux builds / gcc48 and clang-3.3 (no warnings) # x86-Linux builds / gcc34 src/opusfile.c: In function `op_calc_bitrate': src/opusfile.c:1777: warning: integer constant is too large for "long" type src/opusfile.c: In function `op_open2': src/opusfile.c:1131: warning:

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

On 2016-11-14 6:09 AM, Deepak K wrote: > 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. If you don't want to use opusfile's http client implementation (libopusurl) you can still use its seeking implementation. Just provide the

[this time compeled the mail]. The autogen.sh of opusfile doesn't work for me: Updating build configuration files for opusfile, please wait.... configure.ac:8: installing `./install-sh' configure.ac:8: installing `./missing' Makefile.am:10: Libtool library used but `LIBTOOL' is undefined Makefile.am:10: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'

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

Hi, I was look on the website ( http://www.opus-codec.org/downloads/ ) for the latest version of opusfile and it currently says 0.9 is the latest version. However, there is a 0.10 version available at https://archive.mozilla.org/pub/opus/ and there is a Git tag for the 0.10 release ( https://git.xiph.org/?p=opusfile.git;a=tag;h=2979040b8e9086f6f452c1d567c588961bc8b5a8 ). Did you forget to

Hi, Would you be interested in a patch to add CMake support to Opusfile? Opus already seems to have it, but I had to roll my own for Opusfile. I've attached a patch if you're interested, I've been using for a while now and it does what I need, it may not be exhaustive enough for wider distribution though. Hope it helps, Simon -------------- next part -------------- An HTML attachment