similar to: [libopusfile PATCH] build: implement autotools build system for libopusfile.

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

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

I am writing a program that retrieves and plays .opus files over the network. I am using the C# PInvoke wrapper OpusFileSharp, which calls into libopusfile and passes callbacks for read, seek, and tell. I want to enable seeking via the seek callback by not returning -1, but I find that as soon as I do libopusfile requests the last 64K of the .opus file, probably so it can calculate the

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

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

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

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

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

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

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

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

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 > op_fetch_and_process_page: fix int64 overflow > > src/opusfile.c | 11 +++++++++-- > 1 file

On Thu, Dec 7, 2017 at 12:18 PM, Timothy B. Terriberry <tterribe at xiph.org> wrote: > [...] > > Sorry, I can't reply to the original patches because I didn't actually get > that e-mail due to local trouble with my mail server. I could pull the > patches from the list archive, however. Thanks for the reports. > Thanks for recovering them and having a look. I

James Zern wrote: > 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):

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

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

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

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