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

[Michael Niedermayer]

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


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


> 
> > 3. index repeation
> > why not?
> 
> IMO:
> It can appear anywhere, it SHOULD appear after repeated headers, the last 
> index in the file MUST be pointed to by index_ptr if it does exist. That's 
> about my idea for index repetition.

ok


> 
> > 4. 2^x header repeat rule
> > completely breaks streaming, id say change it to "repeat headers either
> > often, never, at the end or at positions after 2^x"
> 
> It's not a rule at all, it's a guideline, spec allows headers to be 
> repeated anywhere... 2^n can't be enforced anyway.
> Wait, I just re-read:
> 
> -
> headers MAY only repeat at the closest possible positions after 2^x where x is
> an integer and the file end, so the headers may be repeated at 4102 if that is
> the closest position after 2^12=4096 at which the headers can be placed
> -
> 
> Heh, dumb restriction. yeah they should be able to appear anywhere...

exactly ...


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


> 
> > 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)
6c. damaged pts or back_ptr during binary search
    maybe we should add a checksum to the syncpoints so the pts&ptrs are
    protected?
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
    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?
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?

[...]

-- 
Michael