[NUT-devel] [nut]: r507 - docs/draft-niedermayer-nut-00.xml

Luca Barbato lu_zero at gentoo.org
Sun Oct 28 09:57:12 CET 2007


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




More information about the NUT-devel mailing list