[MPlayer-dev-eng] Patches for NUT

[Rich Felker]

On Fri, Feb 10, 2006 at 10:58:35AM +0200, Oded Shimon wrote:
> > > 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.
> 
> Given the implementation I showed, it is identical, this is what I hated 
> about this threshold idea, it's very impercise, which is why now I 
> suggest..
> pts_threshold, per stream, from last_pts . Same idea Michael had before my 
> suggestion, however, last_pts is _NOT_ the pts of the last frame in the 
> same stream (which would be very far in case of subtitles), it is the 
> last_pts CONTEXT, which is reset by syncpoints all over. So, even for 
> subtitles, it will never be more than 1 second away or so. This won't even 
> need an extra variable. I think it is the best solution...

Yes, I favor this solution strongly.

> > > > 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.
> 
> Using a cd-rw and a 350mb file, unsurprisngly, index seek is far more 
> enjoyable than binary search. Index is nearly immediate seeking, binary 
> search is about 1-2 seconds for each seek (not horrible, but annoying 
> frozen window...), and syncpoint cache isn't very helpful except for cases 

As I commented on irc, this performance isn't much different than my
experience with some other formats which don't even end up in the
right place after seeking. I agree index is desirable when using
optical media, but I don't think it's _essential_.

Rich