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

[Rich Felker]

On Sun, Jan 29, 2006 at 02:17:42AM +0100, Michael Niedermayer wrote:
> > 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

I wish I knew. The old cdrom drive in my laptop was stuck in
"continuous" mode and would give permenant read error until
eject/reload the moment it found any scratch while reading _data_! :(
I just replaced it with a new DVD drive tho..

> 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 :)

Bleh! :(

> 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?

> 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? :)

Also in some cases (especially streaming over a reliable protocol or
protocol where you have an initial reliable transmission segment)
header repetition might be too expensive and useless since the player
would be expected to finish reliably obtaining the header at the very
beginning before playing the file.

Perhaps we could introduce in the spec a concept of "a nut file
authored for permenant storage medium" and require the header
repetition for this only?

> > 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

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.)

> > > > 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?

Rich