[MPlayer-dev-eng] A few minor things about NUT

[Oded Shimon]

On Sat, Jan 28, 2006 at 09:54:26PM -0500, Rich Felker wrote:
> On Sun, Jan 29, 2006 at 02:17:42AM +0100, Michael Niedermayer wrote:
> > maybe we should make 00 and FF invalid in the spec?
> 
> I don't care, but isn't 0xff just a stupid misdesign of bittorrent
> clients?

Bittorrent are the only ones I've seen do this, yes. IMO the spec shouldn't 
specify they are illegal, leave it to the muxer/user...

> > i will never agree to a spec which has less then 3 copies of the critical
> > headers
> 
> I agree it's good to have copies of the headers, but I don't like the
> basic conformance requirements not being locally verifiable. For
> example if you start playing a network stream, and stop it before you
> reach the third header repetition, did you just play an invalid nut
> file? :)

How do you even comply to this rule. My muxer puts headers at begginning, 
at end, and the very first at 8MB, so for small files it doesn't comply and 
wouldn't even know how to... Just repeat the headers twice at end? That's 
illegal I think. (Headers are always followed by syncpoint, and this is 2 
syncpoints with no data between them)

> > > Well, I'm willing to a tiny 1 byte or 2 byte checksum with syncpoint...
> > > It should cover syncpoint data and following frame header... Maybe if we 
> > > add a 2 byte checksum we can reduce syncpoint length to 6 bytes...
> > 
> > 4byte per 32k are 0.01% overhead IMHO not worth the complexity of another
> > checksum

It can still be adler, just with a different prime... Also since the 
message here is extremely tiny, 20 bytes, adler32 would even be a waste of 
a checksum, it would be half zero...

One thing that sucks about this checksum is that it rquires knowing the 
next frame header when writing it, and when reading it you also need to 
look ahead at the next frame header. But I supposed that's not a big deal 
to implement...
What do you do with the syncpoint that must appear after headers at EOF?.. 
Just checksum the syncpoint pts and ptr?

> Agree 4byte checksum is ok if you want it. The problem of course is
> not that we _need_ a checksum, just that we need a little bit of
> delocalization to ensure that the startcode didn't happen to be right
> before the start of corruption. (I'm not proposing this, but a fixed
> 32bit startcode or splitting the startcode into two pieces at the
> beginning and end of the syncpoint should work just as well.)

It makes it much harder to find by binary search...

> > > > > What do you mean by max dts-pts difference?..
> > > > 
> > > > every frame has a dts and a pts, i mean their maximum difference which is
> > > > max_b_frames(+1) or so for mpeg1/2/4
> > > 
> > > Right.. this will be quite useless for non delayed streams as dts=pts 
> > > always, so if anything i suggest max (abs) difference from last pts...
> > 
> > ok
> 
> I assume this is only an "if known" property?

Of course.

- ods15