[MPlayer-dev-eng] NUT cleanup

[Rich Felker]

On Tue, Sep 06, 2005 at 07:05:19PM +0200, Michael Niedermayer wrote:
> > No, It's a bigger problem - I realized, if you just put a 64bit int at the 
> > end, how the hell do you know if you have the end or not? Say I have an 
> > incomplete file, The end data could be any random junk, and i'd have no way 
> > of knowing if i really have the entire file or not!
> 
> 1. check if the 64bit ptr points within the file (check needed no matter how
> its stored anyway)
> 2. seek there and check if the index_startcode is there (again we need to
> check this for all variants anyway)
> -> so IMHO the 64bit variant is much simpler

IMO not, it requires 2 seeks to know if it's valid. I.e. if you have a
truncated file, you'll do an extra seek looking for nonexistant index.
The end startcode prevents this. However it's really not a big deal.

> > It has a slight muxer implementation advantage - in my muxer it decides 
> > global timestamp by looking at 'stream[0].last_pts' - with this limitation, 
> > i can be sure that the first stream is the most "important" one...
> > And, well, I don't see it as a big limitation.. not much of a big advantage 
> > either though.
> 
> many muxers will have to remap stream ids because they are user / input file
> supplied, many muxers simple will ignore the rule ...

Again, IMO the nut library code should treat stream id's as zero-based
within each class, and just remap them to a single group of id's for
internal nut purposes. But maybe there's a reason this is bad?

> > > > @@ -478,9 +478,15 @@
> > > >  
> > > >  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 
> > 
> > It makes more "sense", but it's harder to implement. Also it really won't 
> > protect you any more from corruption..
> 
> ok, if rich agrees iam fine with this though iam slightly in favor of having
> the forward_ptr in the checksumed area

I don't really care one way or the other, but I see no advantage to
including the forward_ptr in the checksum. So if omitting it makes
implementations simpler, let's omit it.

> > Well, I really considered this last_pts thing as a mere cosmetic issue, to 
> > know the total length of a file. Didn't realize it would get so 
> > complicated. :) IMO it's just fine if it's the pts of LAST FRAME, whatever 
> > it may be, even if it's not the "biggest" pts in the video. (basically it's 
> > whatever pts the muxer and demuxer have to keep internally anyway for pts 
> > calculations)
> 
> i think it should be the biggest pts if we do store it at all

Definitely. Anything else is blatently wrong and misleading to the
player.

Rich