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

[Michael Niedermayer]

Hi

On Sat, Jan 28, 2006 at 09:49:14PM +0200, Oded Shimon wrote:
[...]
> > > Right.. IMO splitting the index really won't help either, cause damage 
> > > comes in blocks, not bytes, only repeated index will save you.
> > 
> > ok, does anyone have a URL/paper/... which analyzes length and distribution
> > of errors on common media?
> 
> I don't... I'm not really sure the cause of errors really, IMO the 3 main 
> types are - damaged cd-rom's, incomplete files from p2p, and streaming...
> 
> I dunno what to do with streaming. with damaged cd rom you'll not be able 
> to play anything anyway cause the player will keep freezing trying to read 
> data from the ever spinning cd rom, 

AFAIK both SCSI and IDE cdroms have a configureable retry count and
have a "read continuous" mode which doesnt delay anything (obviously these
are needed if you want to play audio cds without getting a headache)
how to change these i dunno, sdparm seems to be the tool which should be able
to do this for SCSI cdroms, dunno about IDE, but the IDE/ATAPI spec 
(http://www.stanford.edu/~csapuntz/specs/INF-8020.PDF) says
they support this too, my hdparm doesnt though

and yeah if you use a old kernel the high level drivers will do another 8
retries of the low level read function :)


> and incomplete files obviously only 
> have errors in chunks...
> Also incomplete files are filled by 0x00 or 0xFF, which I always use as 
> invalid frame codes. :)

maybe we should make 00 and FF invalid in the spec?


> 
> > > Ok, but what do you expect us to do? NUT can't do miracles, if your data is 
> > > damaged, you're screwed... If you have some idea to improove error 
> > > recovery, suggest it... We already allow both repeated headers and repeated 
> > > index, and suggest where to put it so it's easily found...
> > 
> > we do not only allow repeated headers we require at least 3 copies of the
> > headers, less and its not a valid nut file
> 
> I guess that's another old legacy bad rule, we all know a truncated nut 
> file is still 100% valid... libnut doesn't comply to this rule anyway.

i will never agree to a spec which has less then 3 copies of the critical
headers


[...]

> 
> > > Again, the syncpoint is as good as a checksum... the only frames that can 
> > > destroy the entire file are ones immediately after a syncpoint.. the 
> > > likelyhood of it is very low. :/
> > > If you are very worried about recovery for a specific file, you can make 
> > > all frame codes invalid except one...
> > 
> > lets assume 1 syncpoint every 32k, and a high bitrate file where most
> > framecodes encode some framesize, for fun lets also assume most framecodes
> > are invalid, this case still has >16k:1 chance per error to hit the framesize
> > and nothing before it which will render the file useless in 1/4-1/8 of the
> > cases, this means that 1 file every 64k errors is useless and thats just the
> > best case in reality it will be many more
> 
> 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


[...]
> > > 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

[...]
-- 
Michael