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

[Michael Niedermayer]

Hi

On Thu, Mar 02, 2006 at 10:38:54AM +0200, Oded Shimon wrote:
> 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... :/

i did post a patch and adapted it based on comments ...


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

fixed


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

cut randomly -> u very likely loose something as it has been cut in the middle
cut after a frame -> why dont you just add 8 zero bytes then too if you 
already do parse things?
anyway, if you and rich want we could add the thing back in the index but
before the reserved bytes and store a index packet with 0 syncpoints and
reserved_bytes always none at the end or do you have a alternative idea?


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

and i disagree


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

every additional field adds complexity, what do we gain here with that field?
personally i would fix max_distance and not store it at all, as i fear people
will set it to random values


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

if its >64bits just store the 64 least significant, and look at the closest
such point from the end -> identical to relative ptr
note, the alternative of putting a "v" style index_ptr in an zero syncpoint
index at the end would solve this though IMO the complexity is not worth it


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

yes, we dont want to use arbitrary precission math for chapter ids
without this rule, someone could simply come up with the idea of
using strings as chapter ids, which wont be fun for most demuxers

[...]

-- 
Michael