[MPlayer-dev-eng] Patches for NUT

[Oded Shimon]

On Sat, Feb 04, 2006 at 02:52:42PM -0500, Rich Felker wrote:
> On Sat, Feb 04, 2006 at 10:49:15AM +0200, Oded Shimon wrote:
> > > > > > remove 2^n header restriction, 03-header-repeat.patch .
> > > > 
> > > > ok
> > > 
> > > IMO the wording is slightly confusing and makes it sound like the
> > > headers must be repeated at EACH 2^n position.
> > 
> > well, it says SHOULD, not MUST, I haven't got any better ideas.. We can 
> > polish it later.
> 
> The issue isn't SHOULD/MUST, it's that your wording implied that
> headers should appear at _each_ 2^n position.

OK, using your phrasing:
Each set of repeated headers not at the beginning or end of the file should 
be stored at the earliest possible position after 2^n for some integer 
power n
Note: this allows an implementation reading the nut file to locate backup 
headers in O(log filesize) time as opposed to O(filesize)

Can I commit?

> > > > ok, but that still leaves the issue with abnormally high pts and damaged pts
> > > > during binary search
> > 
> > I'm now inclined back to checksum, because checking checksum in binary 
> > search is much easier than varifying timestamp or any other hack.
> > 
> > As for damaged pts, there is no good fix for that except optional 
> > max_pts_diff in header... The player should just not be that 
> > dumb...
> 
> You should still check and reject invalid pts, even if checksum is
> valid. This indicates (most likely) an incorrectly authored file.

We (will) have nutlint for that... If checksum is valid, I might add an 
assert to check pts is ok. :)

> > > Hmm..
> > > I'm ok with having checksums but I'd like to hear other ideas too.
> > 
> > We considered adding checksums and shortening startcodes to 4 bytes, but it 
> > makes the startcodes very silly: 0x7A56U + ((('N'<<8) + 'M')<<16)
> > 
> > I also considered 16 bit checksum, as adler32 is kind of a waste on 10-20 
> > bytes, but 16 bits is too weak. :/
> 
> How is using 32 bits to verify 80-160 bits overkill?

Because of adler's behavior... after testing, I found that about 8 bits are 
almost always zero (15 byte message), so it's effectively a 27 bit checksum 
taking up 32 bits... (max values are 12 bits 'a' and 15 bits 'b')

24 bit adler is even weirder than adler16, so that's no good. Does anyone 
have any other thoughts regarding this?

- ods15
-------------- next part --------------
--- mpcf.txt	2006-02-04 10:56:51.000000000 +0200
+++ mpcf.1.txt	2006-02-05 19:23:07.000000000 +0200
@@ -680,10 +680,15 @@
 
 headers may be repeated, but if they are, then they MUST all be repeated
 together and repeated headers MUST be identical
-headers MAY only repeat at the closest possible positions after 2^x where x is
+
+Each set of repeated headers not at the beginning or end of the file SHOULD
+be stored at the earliest possible position after 2^x where x is
 an integer and the file end, so the headers may be repeated at 4102 if that is
 the closest position after 2^12=4096 at which the headers can be placed
 
+Note: this allows an implementation reading the nut file to locate backup
+headers in O(log filesize) time as opposed to O(filesize)
+
 headers MUST be placed at least at the start of the file and immediately before
 the index or at the file end if there is no index
 headers MUST be repeated at least twice (so they exist three times in a file)