[NUT-devel] CVS: main/DOCS/tech mpcf.txt,1.117,1.118

[Oded Shimon]

On Wed, Mar 01, 2006 at 03:19:40PM +0100, Michael Niedermayer CVS wrote:
> CVS change done by Michael Niedermayer CVS
> 
> Update of /cvsroot/mplayer/main/DOCS/tech
> In directory mail:/var2/tmp/cvs-serv10365
> 
> Modified Files:
> 	mpcf.txt 
> Log Message:
> add forward_ptr to syncpoint (+0.006% overhead)
> give syncpoint and frameheader their own checksums (worst case overhead increase <0.006%)
> fix filestructure so that extendability is restored
> move index_ptr to the fileend so that index packets arent a special case with their reserved_bytes position
> -> all packets follow the same structure now
> 
> remove "optional" word from info packets, they are not more optional then index packets
> 
> split index packets
> note, this is entirely optional and a muxer which has difficulty with it can always output a single index packet
> 
> remove the index MUST be at the file end if anywher rule, its not needed anymore as index_ptr will always be at the end
> 
> info frames must be keyframes
> 
> last info frame is the most correct
> 
> comments, flames?

I'm not strongly against anything here, but it would've been better if you 
would have showed the patch (and resolved conflicts) before committing... :/

>  index:
> -    index_startcode                     f(64)
> -    forward_ptr                         v
>      max_pts                             v
> +    syncpoint_start                     v

Is syncpoint_start necessary? Seems redundant to me. BTW, it is non obvious 
from this spec that the index is split by syncpoints and how to use, it 
should be elaborated better (by an entry for syncpoint_start perhaps..)

> +file:
> +    file_id_string
> +    while(bytes_left > 8){

I'm a bit weirded out by this, In a very extreme and silly example, in a 
truncated NUT file you could loose the last frame because it (and the 
frame header) was smaller than 8 bytes...

> @@ -474,12 +508,15 @@
>        1  is_key             if set, frame is keyframe
>        2  end_of_relevance   if set, stream has no relevance on
>                              presentation. (EOR)
> +      4  has_checksum       if set then the frame header contains a checksum

Like I said, this should be a NUT flag...

>      EOR frames MUST be zero-length and must be set keyframe.
>      All streams SHOULD end with EOR, where the pts of the EOR indicates the
>      end presentation time of the final frame.
>      An EOR set stream is unset by the first content frames.
>      EOR can only be unset in streams with zero decode_delay .
> +    has_checksum must be set if the frame is larger then 2*max_distance or its

I still feel this should be a seperate variable, the only reason you gave 
so far against it is that poor demuxers won't be able to decide... And IMO 
that's a very poor argument...

> @@ -612,11 +645,8 @@
>      that EOR. EOR is unset by the first keyframe after it.
>  
>  index_ptr
> -    Length in bytes of the entire index, from the first byte of the
> -    startcode until the last byte of the checksum.
> -    Note: A demuxer can use this to find the index when it is written at
> -    EOF, as index_ptr will always be 12 bytes before the end of file if
> -    there is an index at all.
> +    absolute location in the file of the first byte of the startcode of the 
> +    first index packet, or 0 if there is no index

This would be a silly argument, but it does limit the filesize to 64 
bits... Doesn't matter, it's not very different from limiting the index to 
64 bits...

>  Info tags:
>  ----------
> @@ -630,6 +660,8 @@
>      file. Positive chapter_id's are real chapters and MUST NOT overlap.
>      Negative chapter_id indicate a sub region of file and not a real
>      chapter. chapter_id MUST be unique to the region it represents.
> +    chapter_id n MUST not be used unless there are at least n chapters in the
> +    file

Could you explain this, I'm confused...

- ods15