similar to: Strange behavior with OGG packets?

Hi Drew, In what code are you implementing this? Note that I've been working on a library called libopusenc to make it easier to create Ogg Opus files. Maybe you want to have a look at that. The code is currently at: https://github.com/jmvalin/libopusenc Cheers, Jean-Marc On 18/05/17 03:19 PM, Drew Allen wrote: > Hello all, > > I'm currently in the process of implementing a

I should also say the the ogg_packet.packet[] char array is zero-filled for packet mentioned. On Thu, May 18, 2017 at 12:19 PM Drew Allen <bitllama at google.com> wrote: > Hello all, > > I'm currently in the process of implementing a mixing matrix into the > header of OPUS files for the proposed channel mapping 3 seen here: >

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:

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

Apologies! That patch will not work correctly with Opus 1.2. Will send an updated patch shortly!! On Mon, Mar 26, 2018 at 11:56 AM Drew Allen <bitllama at google.com> wrote: > Hello all! > > I've attached an updated patch for opusfile, based on formatting > suggestions I got for the opus and libopusenc patches. > > Cheers! > Drew > > On Thu, Mar 22, 2018 at

Hi Drew, I think the libopusenc patch is better, but there's still a few issues left: 1) The static MAX_PACKET_BUFFER_SIZE value is still problematic because if you link libopusenc with a new version of libopus that supports higher order projection or just more projection channels for order 3, then you will overflow the buffer. I think what you'd want is a _ope_opus_header_get_size() call

Friendly ping for the opus-tools patch... ---------- Forwarded message --------- From: Drew Allen <bitllama at google.com> Date: Mon, Mar 19, 2018 at 2:53 PM Subject: Re: [PATCH] Support for Ambisonics To: opus at xiph.org <opus at xiph.org> On Mon, Mar 19, 2018 at 11:52 AM Drew Allen <bitllama at google.com> wrote: > Hello all, > > Sorry for the delay (got really

Just to confirm, I would use opeint_* for all the OpusGenericEncoder-related functions? On Tue, Mar 20, 2018 at 8:38 AM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Mark, Drew, > > On 03/20/2018 02:40 AM, Mark Harris wrote: > > + int _oge_use_projection(int channel_mapping); > > > > These functions are part of libopusenc, so I'd expect them to have an

Thanks! 2 down, 2 to go. :D :D :D On Wed, Mar 21, 2018 at 11:19 PM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Thanks, the libopus and the libopusenc patches are now merged. > > Cheers, > > Jean-Marc > > On 03/20/2018 12:36 PM, Drew Allen wrote: > > Attached is an updated patch based on Jean-Marc and Mark's comments. :) > > > >

Attached is an updated patch based on Jean-Marc and Mark's comments. :) Cheers, Drew On Tue, Mar 20, 2018 at 9:20 AM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > On 03/20/2018 11:51 AM, Drew Allen wrote: > > Just to confirm, I would use opeint_* for all the > > OpusGenericEncoder-related functions? > > Correct. Or you can also use oge_ if you like. Just

Since the opusenc and opusinfo changes were independent I split them up and landed the opusinfo changes (with updated mapping family numbers). - Mark On Thu, Sep 6, 2018 at 4:22 AM, Mark Harris <mark.hsj at gmail.com> wrote: > Hi Drew, > > Sorry for the delay. > > FYI the patch that you attached is not your latest version. This > thread that you replied to is an older

Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://westfish.xiph.org/pipermail/vorbis-dev/attachments/20040618/e7bee431/attachment.pgp

Hi Drew, Some comments on the libopusenc patch: + int _oge_use_projection(int channel_mapping); These functions are part of libopusenc, so I'd expect them to have an ope prefix like the other functions in the libopusenc library. + if (_oge_use_projection(h->channel_mapping)) + { + len=27+(h->channels*(h->nb_streams+h->nb_coupled)*2); + } + else + { +

Hello Jean-Marc et all, I've attached an updated patch which I feel addresses all 3 cases. PTAL, Thanks! Cheers, Drew On Wed, Mar 7, 2018 at 8:39 PM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Make sure the modified libraries work in all of these three cases: > 1) libopus 1.2.1 > 2) libopus master (or 1.3-beta) with --enable-ambisonics > 3) libopus master (or

Hi, I'm the main author of Speex (http://speex.sourceforge.net), an open-source speech codec that uses Ogg for file storage. I'd like to have feedback on the way we store Speex data in Ogg files to make sure we do the right thing. The Speex documentation can be found at http://speex.sourceforge.net/manual/ but here's the part about Ogg: <p><p>Speex bit-streams can be

Move demixing matrix defines to opus_define to better determine availability of Projection API. Allows libopusenc, opusfile and opus-tools to much more easily determine availability of Projection API. Cheers, Drew -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20180307/110f7aaf/attachment.html>

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

Good day. I have some questions dealing with merging Ogg Vorbis files. Suppose I want merge two Ogg Vorbis files encoded with the same parameters into one file that composed of one logical bitstream. In this connection some questions: A) Are codebooks in file headers depend only on Vorbis version and encoding parameters and don't depend on the particular source file? B) Are the following

Hi. I assume that I am deeply stupid and have missed something obvious, but why does this bare-bones code not generate a valid (If trivial) opus file? Running opusinfo I ge the following which I interpret this to mean that not even the first packet gets a pass: New logical stream (#1, serial: 1f0cce42): type opus WARNING: Could not decode Opus header packet 0 - invalid Opus stream (1) WARNING:

On 25-Feb-08, at 9:34 AM, xiphmont@xiph.org wrote: > I'd say both; libogg should ignore the incomplete packet or flag a > structural error, and the spec should be clarified. I guess libogg should return -1 if you try to ogg_stream_packetout() after the eos packet. The eos flag pretty clearly applies to the *page* not the packet, so I think how that gets translated into the