[MPlayer-dev-eng] NUT cleanup

[Rich Felker]

On Tue, Sep 06, 2005 at 06:10:14PM +0200, Michael Niedermayer wrote:
> > @@ -234,19 +239,21 @@
> >          
> >  sync_point:
> >  	frame_startcode				f(64)
> > -		global_timestamp		v
> > +		global_pts			v
> 
> i object against changing global_timestamp to global_pts, pts/dts has no
> meaning in respect to the global timestamps of sync points

Agree.

> if you dont agree yet, think about the interleaing rule, its per dts
> so how do we change global_pts -> global_dts which we would need for
> correct interleaving?

BTW.. is there any requirement that global_timestamp actually
correspond to the new time we're looking at? Or should it be possible
to store 0 in all the global timestamps and then code a full timestamp
in the next packet of each stream?

> > @@ -292,6 +301,8 @@
> >  	0xDD672F23E64EULL + (((uint64_t)('N'<<8) + 'X')<<48)
> >  info_startcode
> >  	0xAB68B596BA78ULL + (((uint64_t)('N'<<8) + 'I')<<48)
> > +end_startcode
> > +	0xE8154EDB2A7CULL + (((uint64_t)('N'<<8) + 'E')<<48)
> 
> what is the end_startcode good for? i dont remember any arguments against

It was partly my idea.. at first I thought it was stupid when Oded
proposed it, but then I realized it was sort of strange to have a
u(64) field with no header whatsoever before it.

> simply storing a 64bit index_ptr at the end except its "bleh" which well
> i dont really care about, i prefer a nut spec which is bleh over one which
> is complicated and bloated
> btw, FAQ: 
> Q: why didnt you just store a 64bit int at the end?
> A: because its bleh
> Q2: but dont u see that now we have to search backward for that startcode,
> then parse th vlc forward, keep track of where the vlc started and subtract
> its value from that to find the index?
> A2: ?

Seek to filesize-ceil(log2(filesize)/7)-8, then 'search' the next
couple bytes for startcode.. :)

If you really hate it, scrap it I guess. But I don't think it involves
any seeking backwards.

> >  version
> >  	NUT version. The current value is 2.
> > @@ -327,6 +335,8 @@
> >  	3	metadata
> >  	Note: the remaining values are reserved and MUST NOT be used
> >  	     a demuxer MUST ignore streams with reserved classes
> > +	Note: stream_class MUST be bigger or equal to the stream_class of
> > +	the previous stream.
> 
> what is this good for? yeah i know it is in the current spec and just
> moved but still i dont like it ...


> >  checksum
> >  	adler32 checksum
> > +	checksum is calculated for the area pointed to by forward_ptr not
> > +	including the checksum itself (from first byte after the
> > +	forward_ptr until last byte before the checksum).
> 
> somehow i think forward_ptr should be included in the checksum, dunno 

Well if the correct checksum occurs immediately before the point that
forward_ptr points to, that already validates the forward_ptr. And if
not, you don't get any additional information by including the
forward_ptr in the checksum -- you know something is broken, but not
what.

Note: I don't care about this, just clarifying it.

> > -index_timestamp
> > -	value of the timestamp of a keyframe relative to the last keyframe
> > +last_pts
> > +	The starting pts of the last frame
> > +
> > +index_pts
> > +	value of the pts of a keyframe relative to the last keyframe
> >  	stored in this index
> >  
> >  index_position
> 
> ok, but we must clarify what the last frame is, think about IBP which is 
> stored in IPB order, B is stored last but P has a larger pts

Yes. last_pts = max { all pts values in the stream }

> > @@ -601,6 +614,10 @@
> >  headers starting at offset 2^x for each x players SHOULD end their search from
> >  a particular offset when any startcode is found (including syncpoint)
> >  
> > +			Semantic requirements
> > +
> > +If more than one stream of a given stream class is present, each one MUST
> > +have info tags specifying disposition, and if applicable, language.
> 
> ok

Glad you like it. IMO this is a good compromise, allowing files with
single streams to skip the info, but making sure multistream files are
sane.

BTW I proposed the semantic requirements section so that we could add
requirements that are difficult/impossible to specify formally, but
still very useful. Another thing that should go here is the rule
against nested containers and such. :)

Rich