[MPlayer-dev-eng] NUT cleanup

Michael Niedermayer michaelni at gmx.at
Tue Sep 6 21:00:03 CEST 2005


Hi

On Tue, Sep 06, 2005 at 01:36:11PM -0400, Rich Felker wrote:
> On Tue, Sep 06, 2005 at 07:05:19PM +0200, Michael Niedermayer wrote:
[...]
> > > 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?

stream ids should uniquely identify a stream otherwise you must keep track
of streamid/class pairs everyhwere but its not too difficult to remap things
around so iam fine with this if you think it has some advantage


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

ok

[...]

-- 
Michael




More information about the MPlayer-dev-eng mailing list