Timothy B. Terriberry wrote:
I've never been particularly happy with our usage of encoder/decoder
(without a definition, even, though to be clear I'm responsible for the
current state of this text, since I wrote it). Mark's suggestion sounds
like a solid improvement to me.
I went through and implemented it. The only remaining uses of
encoder/decoder should be describing what happens in an RFC 6716
implementation, without imposing any additional normative requirements
on such an implementation. This involved downgrading one normative
statement to non-normative:
From "Opus uses the pre-skip mechanism for this purpose instead, since
the encoder MAY introduce more than a single packet's worth of latency,
and since very large packets in streams with a very large number of
channels might not fit on a single page."
To "Opus uses the pre-skip mechanism for this purpose instead, since the
encoder might introduce more than a single packet's worth of latency,
and since very large packets in streams with a very large number of
channels might not fit on a single page."
A few encoder/decoder references were also changed to muxer/demuxer
where this was appropriate.
Abstract
- The first 2 sentences seem sufficient. Consider moving the rest to the
Introduction, since it merely highlights Ogg features.
I think it's useful to include some motivation for why a draft is
interesting in the draft in the abstract. The overview of Ogg's features
is really just defining terms for the last paragraph. I'll see if I can
come up with something better.
And in particular the reason I added them was to motivate why someone
might need this draft over and above RFC 6716. But I've no objection to
cutting them if you don't manage to come up with something better.
Moved.
packets with gaps in the timestamps. Perhaps we need to add a MUST NOT
to reinforce the constraints laid out elsewhere in the document, since
there seems to be some misunderstanding here.
I added, "Implementations that fail to do so still MUST NOT increment
the granule position for a page by anything other than the number of
samples contained in packets that actually complete on that page."
I believe the intent of the MAY was to clarify that the preceding
"...MUST NOT reject it for containing additional data..." did not give
muxers carte blanche to add an unbounded amount of additional data. I
would be okay making the RFC 2119 keyword stronger, but it shouldn't be
stronger than the "..SHOULD reject ID headers which do not contain
enough data..." earlier in the paragraph (upgrading both to MUST
wouldn't be unreasonable).
I simply rephrased this as, "...MUST NOT...unless...", which I think
wound up clearer.
I believe all other comments should be addressed in the -09 version that
I just submitted.
_______________________________________________
codec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/codec
