[MPlayer-dev-eng] Patches for NUT

[Rich Felker]

On Fri, Feb 10, 2006 at 02:34:30AM +0200, Oded Shimon wrote:
> On Thu, Feb 09, 2006 at 06:43:30PM +0100, Michael Niedermayer wrote:
> > On Thu, Feb 09, 2006 at 03:04:18PM +0200, Oded Shimon wrote:
> > [...]
> > > > and iam not happy about the 24bit hack either, either store adler32 or crc32
> > > > everywhere IMHO
> > > 
> > > I suppose crc32 then, it's more common...
> > 
> > ok
> 
> Can I use the lutless crc in libnut or is it unusably slow? The biggest 
> single chunk passed to it is 80kb index, and a total of 200-300kb of 
> syncpoint data, with 15 byte chunks 30,000 times...

IMO it's no problem at all. Reading headers does not need to be fast,
and it won't be slow for summing 10-15 bytes. In fact for this
purpose, I expect overall decoding will be faster than with the
table-based one because it won't pollute the cache with tables.

> > hmm somehow i dont like this, convert_ts & compare_ts are slow, we
> > should avoid executing them too often, this would need 3xconvert_ts() per
> > frame on the _demuxer_ side just to check if the pts are ok
> > a common timebase would only need 1 convert_ts()

Agree, but Oded's implementation already does convert_ts to
check/enforce monotonicity rule (MN). That's why...

> Rich suggested an implementation for compare_ts that does not require 
> convert_ts or division (long 1st grade multiplication). As for convert_ts, 
> it's use could be eliminated by preparing threshold in every timebase at 
> init, and:
> (t2 - t1 > thres)
> 
> Is identical to:
> (t2 - thres > t1)

It's not identical because thres can't necessarily be expressed in the
timebase of t2. But maybe it can be used somehow.

> I'm not sure how I feel about 'checksum flag' regardless. It might be nice, 
> but on other hand it's more spec/muxer/demuxer bloat...

I agree it's bloat. Let's not have that..

> > i think we need to better understand the distribuion of errors on common
> > media, it would be silly to complicate the index unneccesariely but it
> > would also be silly if a 1k lost block in a 100k index makes a files
> > sloooow-seekable

"sloooow-seekable" is only for extremely slow media. We've been
testing libnut on files on hdd, and seeking with the binary search is
instantaneous (not noticably slower than with index) and gives perfect
results. Still waiting for some tests to be done on cdrom/dvd, but I
expect the results will be acceptable.

BTW if you're using the reference implementation, seeking gets
progressively faster each time you seek, due to caching of syncpoints
and building of a dynamic index in memory. Unless there's a major
obstacle to using this (like very restricted memory space) I expect
people will just use libnut in most cases because it performs so well.

> If you are talking about index, then you are not talking about 
> streaming, then the only damage left is either p2p and local storage. 
> AFAIK, those 2 only ever give damage in chunks, usually big chunks... BTW, 
> if you truncate a NUT file by a single byte (or, even append a single byte), 
> libnut will not be able to read the index, because there is no index_ptr...

It could still search for the index; however, the likelihood of 1-4
bytes being truncated without part of the index itself also being
truncated is very low, I think.. :)

Rich