Re: [codec] Eric Rescorla's No Objection on draft-ietf-codec-ambisonics-07: (with COMMENT)

[Eric Rescorla <[e-mail]>]

On Mon, Aug 6, 2018 at 10:33 AM, Jan Skoglund <[e-mail]> wrote:

> Thanks for the comments! Our responses are inline below. A new version of
> the doc has been uploaded.
>
> Cheers,
> Jan
>
>
>> S 3.2.
>> >                                                        | Stream Count  |
>> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>> +-+-+
>> >        | Coupled Count | Demixing Matrix                               :
>> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>> +-+-+
>> >
>> >          Figure 4: Channel Mapping Table for Channel Mapping Family 3
>>
>> Are you saying I MUST use family 3?
>>
>>
> No, we say that if you use family 3 you MUST provide a matrix in the
> channel mapping table.
>
>
>> S 5.2.
>> >         The remaining channel mapping families (2...254) are reserved.
>> A
>> >         demuxer implementation encountering a 'channel mapping family'
>> >         value that it does not recognize SHOULD NOT attempt to decode
>> the
>> >         packets and SHOULD NOT use any information except for the first
>> 19
>> >         octets of the ID header packet (Fig. 2) and the comment header
>> >         (Fig. 10).
>>
>> What is the rationale for this change? Also, why are you doing it in
>> this document? This seems like it's going to be extremely hard for
>> implementors to find in future.
>>
>
> These paragraphs are updates to RFC 7845, which needed to be revised to
> accommodate the proposed channel mapping families in this draft.
>

Sorry, I don't understand. Why did they need to be revised to have this
change?


The authors of RFC 7845 and RFC 6716 suggested that the necessary updates
> to RFC 7845 should be included in this draft.
>

I understand, but my point is that people are likely to ignore this draft
if they don't care about ambisonics and thereby miss out on a relevant
information. In any case, I'll defer to the WG and AD.


S 5.1.
>> >      Figure 6: Stereo Downmixing Matrix for Channel Mapping Family 2
>> and 3
>> >             - Ambisonic Channels Plus a Non-diegetic Stereo Stream
>> >
>> >   5.  Updates to RFC 7845
>> >
>> >   5.1.  Format of the Channel Mapping Table
>>
>> What are the interop implications of this? I.e., is a file formatted
>> according to this document at all playable with an existing Ogg
>> decoder? If not, perhaps say so
>>
>
> This is the reason the changes below to 7845 are necessary. I.e., not
> interpreting as channel mapping family 255, and instead “A
> demuxer implementation encountering a 'channel mapping family'
> value that it does not recognize SHOULD NOT attempt to decode the
> packets“
>

Sorry, I'm not following. Is your point that previously it would have
misdecoded it and now it will just refuse to play? That's a reasonable
design choice, but it seems like it was always present in this design, so
why does it need to change?

I think that, depending on implementation, an old decoder would interpret a
> Q15 value as an index and either, most likely, decide the value to be
> invalid and not decode, or, if the index is lower-valued, decode the
> streams according to the old rule
> “If 'index' is less than 2*M, the output MUST be taken from
> decoding stream ('index'/2) as stereo and selecting the left
> channel if 'index' is even, and the right channel if 'index' is
> odd. If 'index' is 2*M or larger, but less than 255, the output
> MUST be taken from decoding stream ('index' - M) as mono. If
> 'index' is 255, the corresponding output channel MUST contain
> pure silence”
>
> So, it would either decode and play an unintended mixing, or not produce
> audio at all.
>

All right.

-Ekr


>
>
>