similar to: Decoding Opus File in Chunks

Displaying 20 results from an estimated 600 matches similar to: "Decoding Opus File in Chunks"

2018 Apr 06
0
Decoding Opus File in Chunks
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
2017 Nov 20
7
[PATCH 0/2] libopusfile int64 overflows
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
2013 Dec 05
1
playback of opus files using portaudio
I am making a lightweight opus audio player. This is my portaudio callback function. But i hear a stammering song when i try to play a .opus song file. Can anybody say what is wrong or provide me link to any code which can play opus file written in c/c++(light). I tried to see some open source(vlc opus play) but was unable to follow. int MyCallback(const void* input, void* output, unsigned
2020 Aug 12
2
Opusfile Docs Not Displaying
The Opusfile docs do not seem to be showing after clicking links from the landing page Landing (works): https://opus-codec.org/docs/opusfile_api-0.12/index.html Subpage (blank content): https://opus-codec.org/docs/opusfile_api-0.12/group__stream__open__close.html -------------- next part -------------- An HTML attachment was scrubbed... URL:
2017 Dec 07
2
[PATCH 0/2] libopusfile int64 overflows
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
2018 Apr 10
2
[PATCH] opus-tools/opusfile: Support for Ambisonics
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:
2017 Nov 20
0
[PATCH 1/2] op_pcm_seek: fix int64 overflow
check for overflow with a negative diff --- src/opusfile.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/opusfile.c b/src/opusfile.c index 72f1272..df326af 100644 --- a/src/opusfile.c +++ b/src/opusfile.c @@ -2605,7 +2605,11 @@ int op_pcm_seek(OggOpusFile *_of,ogg_int64_t _pcm_offset){ would be better just to do a full seek.*/
2017 Nov 20
0
[PATCH 2/2] op_fetch_and_process_page: fix int64 overflow
check for overflow with a negative diff --- src/opusfile.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/opusfile.c b/src/opusfile.c index df326af..2bef277 100644 --- a/src/opusfile.c +++ b/src/opusfile.c @@ -2078,7 +2078,10 @@ static int op_fetch_and_process_page(OggOpusFile *_of, &&OP_LIKELY(diff<total_duration)){
2017 Dec 07
0
[PATCH 0/2] libopusfile int64 overflows
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):
2015 Mar 21
0
use xmm intrinsics for lrintf() with mingw-w64
The following tiny patches make opus and opusfile to use xmm intrinsics for lrintf() with mingw-w64 builds when targetting x64 instead of their default x87 asm. Regards. -- O.S. diff --git a/celt/float_cast.h b/celt/float_cast.h index ed5a39b..b9b8484 100644 --- a/celt/float_cast.h +++ b/celt/float_cast.h @@ -61,7 +61,14 @@ ** the config.h file. */ -#if (HAVE_LRINTF) +#if
2013 Aug 20
4
opusfile 0.4 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 *
2012 Sep 29
2
[libopusfile PATCH] build: implement autotools build system for libopusfile. (v4)
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 +++++
2018 May 25
0
[PATCH] opus-tools/opusfile: Support for Ambisonics
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
2017 Jan 28
2
How to use op_test_callbacks ?
Hello. I have succeffully open a memory buffer from a url-opus-file with (from Pascal fpc): HandleOP := op_test_memory(BufferURL[0],PipeBufferSize, Err); op_test_open(StreamIn[x].Data.HandleOP); I can retrieve the tags infos, all seems ok. But for reading, using this gives 0 outframes: outframes := op_read_float(Data.HandleOP, at Buffer[0], Wantframesm, nil); I suspect that some callback
2017 Aug 31
3
opusfile Include fix
Hi all! When compiling the program using opusfile the #include <opus/opusfile.h> generates error that # include <opus_multistream.h> is not found. Actually it should be included as # include <opus/opus_multistream.h> just like the ogg.h in the previous line. A small patch attached. -- Best regards, Alexander -------------- next part -------------- A non-text attachment
2015 Nov 05
3
Opusfile seeking bug
Hi, I seem to have found a bug with seeking in opusfile in some situations, though this might be better directed to the ogg list. I?ve included a short description below and a test case C program that describes it more detail (comments) and reproduces the issue when used with a file which contains packets that have been split over a page boundary (less common than I thought). The test program is
2018 Mar 19
3
[PATCH] Support for Ambisonics
Hello all, Sorry for the delay (got really sick last week). Attached are updated patches for libopus, libopusenc, opusfile and opus-tools. Note that the patches for libopusenc, opusfile and opus-tools are dependent on the patch for libopus. Please let me know if you have any additional followup comments or questions. Cheers, Drew -------------- next part -------------- An HTML attachment was
2013 May 01
2
[PATCH] stream.c needs sys/types.h
For definition of off_t type, stream.c needs including sys/types.h. I hit this requirement at least once when compiling against Mac OSX 10.4 SDK. Trivial patch inlined below. --- opusfile/src/stream.c~ +++ opusfile/src/stream.c @@ -14,6 +14,7 @@ last mod: $Id: vorbisfile.c 17573 2010-10-27 14:53:59Z xiphmont $ ********************************************************************/ +#include
2016 Nov 08
2
Help with Opus Streaming
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
2017 Dec 07
1
[PATCH 0/2] libopusfile int64 overflows
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