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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20170518/6b1edbee/attachment.html>
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: > 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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20170518/614ccfdd/attachment.html>
On Thu, May 18, 2017 at 12:23 PM, Drew Allen <bitllama at google.com> wrote:> 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: >> 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, >> DrewHi Drew, The packet is probably larger than the buffer. In opus-tools, see src/opusenc.c lines 849-853. - Mark
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 >
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>