Thanks Jean-Baptiste, Mark, and Marc for your comments. Also thank you Ron for your support.
On Sat, May 28, 2016 at 1:47 AM, Jean-Baptiste Kempf <[email protected]> wrote: > Sorry, what I meant is that it would be nice that the info from this RFC > carries the same kind of information than SA3D, so that a player like > VLC only need to have one identical filter to process them, post > decoder. In lieu of the SA3D box's explicit metadata, this draft requires that the ambisonic streams use ACN channel ordering and SN3D normalization. The channel count and channel mapping are contained in the Ogg identification header. I believe the only thing missing here is the SA3D box's "ambisonic_type" field. I would like to require periphonic (full 3D) ambisonics in this draft. I added the word "periphonic" to section 3.1. On Sat, May 28, 2016 at 10:35 PM, Mark Harris <[email protected]> wrote: > In section 3.2 perhaps it should be clarified that the first ambisonic > channel (W) may be used directly for mono playback, particularly if > streams with channel mapping family 2 might only have one channel. I added a short paragraph to the end of 3.2. What do you think? > Also there is a typo "definied" in section 4. Thanks, fixed On Sun, May 29, 2016 at 7:42 AM, Marc Lavallée <[email protected]> wrote: > I would suggest to not include decoding of Ambisonics streams in the > Opus decoders. Exceptions would be decoding/down-mixing to mono > and stereo, as defaults for compatibility reasons, but in a carefully > unobtrusive way; users of Opus for Ambisonics should easily have access > to all channels, even if the Opus decoder (and the system) wants to > "help" them. Right. I do not want to include ambisonic decoding in the Opus decoder. I reworded section 3.2 to make it clear that downmixing MAY be done by Ogg Opus players, not decoders. > Support for mixed-order is important too, mostly for horizontal-only ... The draft allows users to send mixed-order ambisonics > Normalisation is not the responsibility of a codec. It is used for > Ambisonics format conversion (ex: A to B, FuMa to Ambix). That said, > gain factors could be included to maximize dynamics, but it is > unrelated to Ambisonics. Right. Just to be clear, the Opus encoder and decoder do not do the normalization, nor do they _need_ to know anything about it. The encoder could perform masking computations that require knowledge of the normalization, but the main purpose of including it in this draft is to give Opus ambisonc streams an unambiguous semantic meaning. When an Ogg Opus ambisonic player receives a stream with channel mapping 2, that player needs to know the normalization. As written, this draft promises that the stream would be SN3D normalized. _______________________________________________ codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/codec
