similar to: Question about libopusfile downloading the last 64K when duration is not needed

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

Ian Reed wrote: > It explains why libopusfile requires the last 64K to calculate the > duration, but again, I don't need libopusfile to get the duration for > me, I only want it to allow me to seek within parts of the file that > have already been downloaded. Unfortunately, this is not currently supported. > Is there a reason libopusfile forces the retrieval of the last 64K

Hello, Been playing with libopusfile today. Ideally would like an MSVC dll rather than a static lib, but I can't see dllexports hidiing in an #ifdef anywhere. Am I just being stupid, or....? BTW that static lib is working nicely in vs2010 and up for streaming radio, though it was a real pain to have to piddle about compiling openssl on Windows! I want to write a streaming URL source filter

Hi all, I am a developer for embedded system and totally new to Opus and open source audio codec. I'm now using Microchip dsPIC33 to develop a decoder for Opus. I am now using sources of libopus. The first question is for calling opus_decode(), do I need to skip the header bytes of an opus file before I can input the file data to opus_decode()? Or will libopus handle this automatically?

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

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

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

Just an attempt to avoid overflows with an explicit check, I don't know if there's a better way to identify corrupt input here. James Zern (2): op_pcm_seek: fix int64 overflow op_fetch_and_process_page: fix int64 overflow src/opusfile.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) -- 2.15.0.448.gf294e3d99a-goog

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

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 +++++ configure.ac | 66 ++++++++++++ m4/attributes.m4 | 321

Hello all, Attached are patches for libopusenc, opusfile and opus-tools in order to provide support for Ambisonics and the Projection API for encoding/decoding channel mapping 253 and 254. Please feel free to ask any questions or give any feedback you might have. :) Cheers, Drew -------------- next part -------------- An HTML attachment was scrubbed... URL:

Would it be possible to include a re-export of the malloc, calloc, realloc, and free being used by opus file's implementation of OpusTags handling? This might seem redundant or ridiculous but I'm having difficulty getting the right versions that my compiler allows that's compatible with libopusfile. In the debugger I can see that the memory location that my malloc is returning is

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

Hi, I had found a Opus TODO list in https://wiki.xiph.org/index.php?title=OpusTodo&mobileaction=toggle_view_desktop . The item "Opus-tools" interest me. And here is my question about "Port opusdec to libopusfile/libopusurl": 1. Does this function have achieved? On one hand, I think not literally. On the other hand, after briefly reviewing opusdec.c of opus-tools, I found

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 have been challenged by someone that opusfile's 48kHz most of the time forced resampling but I didn't have good arguments to counter. I've checked the opus-codec.org pages and Monty's pages without finding good arguments. If you encode files to .opus with opusenc and decode with opusfile's api the sampling rate is constantly 48kHz ignoring output hardware isn't it? Is

On 23/02/15 10:30 AM, Tony wrote: > I __think__ opus-tools' opusenc has code which can be used as a > template/sample for how to create an .Ogg file with Opus content. As > expected, it makes use of libopus and libogg. Sadly that's the best option currently. As you say it's a bit complicated, although oggenc has a lot of extra support for controlling encoder options you

On Tue, Nov 28, 2017 at 3:22 PM, James Zern <jzern at google.com> wrote: > On Mon, Nov 20, 2017 at 1:07 PM, James Zern <jzern at google.com> wrote: >> Just an attempt to avoid overflows with an explicit check, I don't know if >> there's a better way to identify corrupt input here. >> >> James Zern (2): >> op_pcm_seek: fix int64 overflow

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

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