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

[Oded Shimon]

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...
Also I think this causes problems with back_ptr and etc... 2 syncpoints 
with same pts but different back_ptr are a bad thing.

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

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

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

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

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

> 7. behavior with packet loss (network streaming use case)

Not sure what can be done for this, this is upto to the transport layer 
imo... Do you mean the problem is last_pts state?

> 8. dropable flag
> conventional b frames may be droped should these be optionaly marked in the 
> framecode the overhead would be tiny due to delta pts - frametype relations
> the advantage? if a packet gets lost and it just contained dropable frames
> no need to ask for a retransmit ...

Abstain...


BTW, I'm considering removing EOR altogether, NUT is getting pretty complex 
(atleast, libnut is, and so are the seeking algos...), and if we end up 
with just another complex format we might as well use mkv...
Index suggestion you just gave might be trivial to implement though, we'll 
see...

- ods15