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

[Oded Shimon]

On Sat, Jan 28, 2006 at 08:25:53PM +0100, Michael Niedermayer wrote:
> On Sat, Jan 28, 2006 at 07:26:13PM +0200, Oded Shimon wrote:
> > I still don't like the idea of redundant frames, if you lost some data, you 
> > can't play the nut file at all until the next syncpoint anyway... I guess 
> > it's helpful for info streams.. And that actually fixes the back_ptr 
> > problem we had with info streams.
> 
> yes, back_ptrs are the reason why i suggested it, but the issue isnt info 
> stream specific, its also subtitle streams, think about some larger amount of 
> text shown for 10 seconds, if its just stored as ASCII repeatng the packet 
> would be negligible amount of overhead and quite nice for seeking

Then just repeat it with a real pts... That was the original intention. If 
it's only info or subtitles, it won't have any speed impact on player or 
other serious problem.

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

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

> > > 6c. damaged pts or back_ptr during binary search
> > >     maybe we should add a checksum to the syncpoints so the pts&ptrs are
> > >     protected?
> > 
> > The syncpoint is about as good as a checksum on it's own... there's is some 
> > easy logic tests to see if data is valid - back ptr can't be bigger than 
> > previous syncpoint back ptr, pts must be monotone...
> 
> yes but during binary search your knowledge about the previous and next 
> ptrs/pts is limited and if one is wrong and not detected recovery is not easy

I suppose... I'm not even sure how binary search should behave with 
damage..

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

> > > 6e. damaged pts (could lead to stuck player, not nut specific i know ...)
> > >     too small pts are detectable due to ts ordering but too large are not
> > >     maybe (optionally) store some max dts-pts difference somewhere?
> > 
> > This actually reminds me, if you remember fixed_fps, for non delayed 
> > streams pts diff must always be exactly 1... for delayed it can only be 
> > max_b_frames+1 i think...
> > 
> > Too large pts diffs are also detectable I think.. Heh you only know it by 
> > the next frame...
> 
> right after the user waited an hour to see the previous one

Dumb player :)

Maybe we should have max_pts_distance as well as max_distance .... 
(syncpoint placement rule that is)
however pts's are obviously non monotone and checking just dts is 
useless... (it's as good as mn rule)

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

> > BTW, are you being mind controlled by Ivan? When did you become so worried 
> > about error detection/recovery. :)
> 
> i always was, rich is the one who doesnt care about error recovery

Heh I though you were the one worried about overhead as you were very 
reluctant to allow bigger index... now you want it repeated and checksums 
on syncpoints, heh.

- ods15