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

[Rich Felker]

On Sat, Jan 28, 2006 at 05:50:21PM +0100, Michael Niedermayer wrote:
> > > 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

If we allow the old pts to be reused we need to make a special
exception to muxing order and possibly complicate the seeking
algorithm a lot (since it can't immediately tell that the frame is
duplicate just from the pts, because it doesn't know the previous
pts).

I would rather have a flag so that these frames can be totally ignored
if desired, and then probably use new/current pts values for the
repetitions.

BTW I'd like to restrict this type of repetition to EOR-able streams,
and restrict EOR to subtitle and info streams with decode_delay=0.
Otherwise there's lots of unneeded complexity. If there's a legitimate
need we could lift these restrictions in the future but I doubt there
would be.

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

I don't think it will be terribly painful to do the binary search.
Oded, have you tried your demuxer on optical media?

> 6c. damaged pts or back_ptr during binary search
>     maybe we should add a checksum to the syncpoints so the pts&ptrs are
>     protected?

I'm not against checksum, but not sure it's very helpful either.
Misordered dts will detect invalid timestamps right away during binary
search, and so will misordered back_ptr. (i.e. back_ptr of a later
syncpoint always points to position >= back_ptr of earlier syncpoint).

> 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

A frame size is invalid if it's > max_distance and one of the
following is true:
- it wasn't immediately preceded by a syncpoint.
- it doesn't point to a syncpoint.

Testing the former is easy. The latter is more painful but for all
practical purposes a demuxer can probably make some heuristics that
makes it efficient for real world files.

One method:
When encountering a frame larger than max_distance, search
max_distance for a syncpoint startcode. If you found it, you're
99.999999% ;) sure that the frame size is invalid.

This seems to be close to what you had in mind.

Error checking/recovery will always have higher memory or time costs
than simple demuxing and may not be feasible for embedded demuxers. I
don't know any good solution. Your concerns about making sure it works
with streaming are certainly valid though.

Rich