[opus] Strange behavior with OGG packets?

[Drew Allen]

Hey Mark / Jean-Marc,

Thanks for the quick response. I'm implementing inside opus-tools.

Mark - Bingo! That did the trick, thanks! :)
Jean-Marc - I'll take a look at the project and add support for the
proposed mappings on my end.

Thank you both so much!
Cheers,
Drew

On Thu, May 18, 2017 at 12:51 PM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote:

> 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 mixing matrix into the
> > header of OPUS files for the proposed channel mapping 3 seen
> > here:
> https://tools.ietf.org/html/draft-ietf-codec-ambisonics-03#section-3.2
> >
> > My implementation simply replaces writing the stream mapping char array
> > with the Q15 col-wise matrix vals described in the above document.
> >
> > I'm able to write/read matrices of 4x4 and 9x9 and encode->decode first
> > and second order just fine, but writing larger matrices causes what
> > seems to be some sort of packet corruption. The OpusHead packet is never
> > found, but in it's place we have a packet at b_o_s=256 (which is where
> > OpusHead usually lives), but the byte size is reported to be 0 and
> > e_o_s=0 as well. (This is generated by parsing the packets via
> > ogg's *ogg_stream_packetout* function. It appears a matrix larger than
> > 7x16 causes this issue. (The matrix values are all signed short vals, so
> >>224 bytes seems to fail.
> >
> > I'm not very familiar with ogg internals so any advice would be greatly
> > appreciated! Thanks so much! :)
> >
> > Cheers,
> > Drew
> >
> >
> > _______________________________________________
> > opus mailing list
> > opus at xiph.org
> > http://lists.xiph.org/mailman/listinfo/opus
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/opus/attachments/20170519/5f20a8c5/attachment.html>