[NUT-devel] rfc drafting

[Michael Niedermayer]

On Fri, Nov 16, 2007 at 01:13:34AM -0500, Rich Felker wrote:
> 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.

very good, i fully agree


> 
> 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.

ok


> 
>   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.

what about normal b frames?
IPBBIBBBBBPPP

here if we start decoding from the 2nd I frame none of the B frames
can be decoded as they need the pevious frames but they are after the
I frame position wise


> 
>   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.

ok


> 
> 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.

ok, commit as you see fit, ill flame you as i see fit :)

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/nut-devel/attachments/20071116/4e55f07c/attachment.pgp>