Michael Niedermayer wrote:
On Sun, Oct 28, 2007 at 02:34:36AM +0200, lu_zero wrote:
Author: lu_zero Date: Sun Oct 28 02:34:35 2007 New Revision: 507
Log: yet another update
this is not a acceptable svn log message
I'll update the message soon (was too tired to think something better probably)
Modified: docs/draft-niedermayer-nut-00.xml
Modified: docs/draft-niedermayer-nut-00.xml ============================================================================== --- docs/draft-niedermayer-nut-00.xml (original) +++ docs/draft-niedermayer-nut-00.xml Sun Oct 28 02:34:35 2007 @@ -101,8 +101,8 @@ providing citations here. --> synchronous 1-in-1-out decoder. </t> <t hangText="frame"> Minimal unit of information that can be - decoded completely, it is usually holds a full frame video frame, - a group of audio samples or a subtitle line. + decoded, it is usually holds a part of video frame, a group of + audio samples or a subtitle line.
huh? a frame is part of a (video) frame ?
a nut frame can hold a slice?
</t> <t hangText="Keyframe"> A keyframe is a frame from which you can start decoding. @@ -212,10 +212,89 @@ providing citations here. -->
<section title="NUT file layout">
- <t></t> - + <t>Every NUT file starts with an identification string, main (global) + headers and per stream headers follow, frame data is interleaved with + syncpoint packets. Optional info packets and index packet MAY be present, + in multiple copies, in order to improve resilience</t>
this is unclear if not outright wrong it makes it look as if only index and info packets may be repeated also the "may" is not correct headers at least have strict repeation rules
check the definition of MAY. Repetition rules doesn't change the fact you can have 0,N copies of them. I agree it could be clarified.
[...]
+ <t>The structure of an undamaged file SHOULD consist in the + file_id_string, the main header, the stream headers, the optional + info packets, the optional index, frames intermixed with syncpoints.
i dont think this is an english sentence
I removed "followed by" but I didn't put "following fields:", my bad
+ Demuxers SHOULD be flexible and be able to deal with damaged headers so is RECOMMENDED to use a loop able to adapt to corruptions and + misordering, the file scheme in figure <xref="file representation" /> + shows a possible parsing method. Demuxers MUST be able to deal with new + and unknown headers.</t>
s/be able to deal with/ignore/ or something like that same for nut.txt if thats containing this as well
cf. nut.txt: 171 Note: Demuxers MUST be able to deal with new and unknown headers. the nut.txt is unclear about that in the very same way. updating the commit message right now. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero