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

[Michael Niedermayer]

Hi

On Sat, Jan 28, 2006 at 07:26:13PM +0200, Oded Shimon wrote:
> On Sat, Jan 28, 2006 at 05:50:21PM +0100, Michael Niedermayer wrote:
> > Hi
> > 
> > On Sat, Jan 28, 2006 at 05:26:03PM +0200, Oded Shimon wrote:
> > > On Sat, Jan 28, 2006 at 04:06:13PM +0100, Michael Niedermayer wrote:
> > > > Hi
> > > > 
> > > > 1. (key)frame repeation
> > > > at least in some cases like info streams or subtitles the muxer might wish to
> > > > repeat frames
> > > > demuxers must know about repeated frames, and should know about repeated
> > > > keyframes
> > > > should we add a is_redundant flag to the flags in the frame code table? 
> > > > IMHO yes otherwise we wont know / be able to discard repeated keyframes during
> > > > remuxing
> > > 
> > > Sounds weird, if you see a frame with redundancy flag, how do you know if 
> > > you've seen it or not? you keep a cache of all pts's you've seen? redundant 
> > > frames can only repeat right after the frames they repeat? either way this 
> > > can be implemented without the flag...
> > 
> > ok, forget it 
> > pts difference == 0 <-> redundant
> 
> 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


> 
> > > > 2. split index
> > > > if theres a single damaged byte in the index it becomes useless, maybe we
> > > > should split it into chunks covering x..x+n syncpoints each?
> > > > think about cddrom/dvd these do get damaged, yeah the index can be rebuild and
> > > > a new cd burned and it is possible to seek without an index but thats slow
> > > > on slow media ...
> > > 
> > > Well, the problem is the index isn't interleaved by syncpoints, it's 
> > > interleaved by streams... At most you can split it to index per stream. 
> > > That's about it...
> > 
> > this doesnt help
> 
> 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?


[...]

> 
> > > > 6. behavior of damaged files on slow media (cdrom/dvd use case)
> > > 
> > > Well, what do you expect to be done? you can't just guess where the damaged 
> > > area stops, you have to linear search it... you could use the index to 
> > > do a syncpoint binary search i guess, but thats about it.
> > 
> > 6a. damaged header (detect, search copy, go back play file)
> > 6b. damaged index (very slow seeking, tell user to buy/make new cd)
> 
> 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


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


> 
> > 6d. damaged frame size (MUST be detected or we skip the whole file, but how?)
> >     originally forward ptrs allowed trivial detection but richs no buffering
> >     rules killed them
> >     with just the syncpoint placement rules its more tricky, if the framesize
> >     is larger then the max syncpoint distantance there should be no syncpoint
> >     before the end and one at the end of the frame, we cant check the end as
> >     that wouldnt solve the issue for notseekable streams
> 
> 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



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


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


> 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

[...]

-- 
Michael