On Mon, Aug 6, 2018 at 10:33 AM, Jan Skoglund <j...@google.com> 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
>
>
>
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/mailman/listinfo/codec
