[MPlayer-dev-eng] Lots of stuff for NUT

[Rich Felker]

On Wed, Jan 04, 2006 at 11:52:03AM +0100, Michael Niedermayer wrote:
> > Well, what is it about it that bothers you? The overhead? I've already 
> > prooved that in high bitrate files, the overhead is irrelavent, and in low 
> > bitrate files, the frame headers are most of the overhead anyway. (If you 
> > do not agree with my tests please offer a better testing scenario)
> 
> i suggest to make per stream pts and back_ptrs optional

If they're optional they're useless -- this is like stupid matroska
where it's optional whether you want to store pts (lacing crap). As
soon as the essential information is optional, the container sucks
because idiots will omit it, plus the demuxer has to be MUCH more
complicated to handle both cases correctly. The whole reason we have
pts per-frame is that we insist on allowing frame-exact seeking (well
also remuxing and ease of playback :), so it doesn't make sense to
make frame-exact seeking infeasible..

I'm totally willing to drop per-stream pts in syncpoints entirely if
you have a O(log n) algorithm (without index) and O(1) with only a
single media seek algorithm (with index) to seek to the optimal point,
and any linear searching is bounded by small constant * max_distance
(i.e. not O(keyint)).

But without such an algorithm, the overhead seems small enough that I
see no reason not to include them.

As far as I've seen, we've been unable to make a perfect interleaving
rule in the presence of delayed frames sufficiently good to assign
single sane timestamps to syncpoints. What I like about the per-stream
pts is that we no longer have to do that! Ultimately, with per-stream
pts in the syncpoints, the demuxer can treat each stream as a
completely separate entity and pretend all the other streams are just
padding. It's exactly like what would happen if each stream was a
separate file, except that they're interleaved in order to facilitate
sequential read for playback.

Rich