
<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""></div><div class=""><br class=""></div><div class="">This is primarily based on the Ambisonics draft, as it's generally making additions to the same areas.</div><div class=""><br class=""></div><div class="">A few areas I'd expect could be improved:</div><div class=""><ul class="MailOutline"><li class="">Currently I'm using Microsoft's WAVEFORMATEXTENSIBLE structure's dwChannelMask field to define channel positions. These values are reasonably standard, but I'm not sure if citing Microsoft's documentation directly is the best way to handle this. We might want to copy the channel names into the spec, or cite some other document from a standards body naming and numbering speaker positions (does anyone know anything applicable?).</li><ul class=""><li class="">Should this list be made into its own registry, for later extensibility? ffmpeg additionally defines "stereo left/right" (for an embedded downmix), "wide left/right", "surround direct left/right", and "low frequency #2".</li></ul><li class="">The downmixing algorithm is largely a description of ffmpeg's libswresample's behavior. Documenting some downmixing behavior was suggested by mark4o in the #opus channel on Freenode; not sure if the current formatting is optimal.</li><li class="">I'm referring to (and using terminology from) the struct defined in section 5.1.1 of RFC7845. Should I copy the relevant portions into this document as well?</li><li class="">I'm redefining the mapping table for this mapping family. This was an easy place to specify channel positions, but it means that the "multiple channels copied from the same stream" feature isn't available. I don't particularly expect this to be an issue, but if people have problems with it, we can instead keep the existing table and add a simple bitmask before or after it.</li></ul><div class=""><br class=""></div></div><div class="">I've looked into the relevant changes in libavcodec and libopus. It's reasonably simple to add on the decode side in libavcodec's native decoder (largely changes to ff_opus_parse_extradata), but it's a bit trickier in libopus, because there's no support in the API for channel layouts (and thus stereo stream counts) other than those in the standard. I'd expect to need to take one of these routes:</div><div class=""><ul class="MailOutline"><li class="">Add new opus_multistream_surround_encoder_create and opus_multistream_surround_encoder_init variants that take a uint32_t (or uint64_t for future expansion) bitmask</li><li class="">Have opus_multistream_surround_encoder_create/opus_multistream_surround_encoder_init read from streams and coupled_streams when mapping_family == 4 (and require the consumer to set them, and adjust the resulting mapping)</li><li class="">Have opus_multistream_surround_encoder_create/opus_multistream_surround_encoder_init read from mapping when mapping_family == 4 (and require the consumer to set it)</li></ul><div class="">Anyone have preferences on this?</div></div><div class=""><br class=""></div><div class="">Additionally, I'd expect that once this draft is finalized, I'll be writing up a similar extension for FLAC.</div><div class=""><br class=""></div><div class="">Thanks in advance for the feedback!</div><div class="">--rcombs</div></body></html>