hi all,
lu wants me to help on drafting and formatting the rfc, and i think
this is a good thing. so i started looking at it and have some ideas
for changes to make, but i don't want to step on any feet..
abstract: this should mention the codec-agnosticism and ability to
perform container-level operations without any awareness of the data
format, since these aspects are probably the most novel from a
multimedia standards perspective. i want to add the text "without
regard for the specific formats of the streams, and" before "with
minimal computational cost" and perhaps work more on improving the
content of the abstract.
definitions:
the definition of pts is somewhat confusing in relation to b frames
and out of order decoding. can we do something about "completed by
decoding the coded frame" to make it more clear?
the definition of dts is rather vague...
frame: i had a good formal definition the other day but can't remember
at the moment...
keyframe: rewording for clarity and formal english:
A keyframe is a frame in a stream at which decoding of that stream
can successfully begin independent of prior frames. Keyframe status
of frames within one stream is independent of any other streams.
Assign to each frame in a stream an integer position n. The nth
frame of a stream is a keyframe if and only if the mth frame, for
each m≥n+k, can be decoded successfully without reference to data
contained in the lth frame for any l<n, where k is the smallest
nonnegative integer such that keyframes other than the initial frame
can exist in the stream's coding scheme. This definition coincides
with the ordinary notion of a keyframe for common video coding
schemes where k=0, and also allows for overlapped-window audio
coding schemes where k≥1 accounts for the missing overlap from the
previous frame.
Readers should be aware that this definition of keyframe is
dependent on the ordering of frames according to pts and dts as
mandated by this standard.
data types: strings: the requirement that strings not contain U+0000
is mysteriously missing. also, i would like to change the terminology
from "string" to "text" to align mostly with the posix sense of text
(i.e. bytes must represent characters and must not contain 0). string
is somewhat less precise imo because to some people binary data (or
binary data without embedded 0's) is a "string" but not "text". also
then we could move the requirements of text to a "definition of text"
under the definitions section, which i think would be nice
organizationally speaking.
finally, lu thought this was okay but i'd like to run it by others:
can i commit changes like these directly to the rfc xml file? the
intent would not be to impose my wishes on others, but rather to
accelerate completion of the document. i would certainly welcome
others to revert or heavily alter anything objectionable and start
discussions on the list as appropriate, but i feel now that we're to
the stage of documenting the format we already designed rather than
designing it, the types of potential objections are very different and
much less severe and we always have the authoritative nut.txt to go
back to. if anyone else has differing or better ideas on how to work
on the rfc i'd be happy to hear them too.
rich
