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

[Oded Shimon]

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.

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

> > > 5. convert_ts() overflow behavior
> > > _IIRC_ this can overflow if timestamps are > 10 or 50years or so
> > > is that an issue, it could be fixed if it is ...
> > 
> > Uhh, let's say you use timebase sampling rate for audio, 44100..
> > If I did my math right, that's 13264000 years until 64 bit overflow, not 
> > sure how many bits convert_ts gives you before overflow, either way, I 
> > think by then we'll have native 128 bit math...
> 
> lets say your timebase is 31bit/31bit (thats legal and with AVI as source
> you will have no difficulty finding such files ...)
> 
> the value within the () of (ln/d1*sn + ln%d1*sn/d1)/d2 is the dst_timestamp *
> the dst_numerator if we assume 64bit unsigned then we have 33bit left for the
> timestamp -> <300 years

... 300 years is sufficient...
I know, "32kb should be enough for everybody", but seriously, 300 years is 
sufficient until we have 128bit math... By then none of us will be around
to be blamed anyway :)

I've never seen such an AVI file btw. Also NUT spec disallows such 
timebase... Sort of...

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

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

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

>     so we would have to speculatively linear search until the next syncpoint
>     that should be mentioned in some error robustness section
>     maybe (optionally) store some max framesize for each stream?

We should add an entire "NUT tips" guide, regarding seeking, error 
recovery, etc. ...
max framesize could be added I suppose, it's rather trivial. (and obviously 
impossible, but still simple...)

General idea is if you detect any of the many different errors, seek abck 
(if possible) to last syncpoint seen, and then linear search...

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

What do you mean by max dts-pts difference?..


BTW, are you being mind controlled by Ivan? When did you become so worried 
about error detection/recovery. :)


- ods15