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

[Rich Felker]

On Sat, Jan 07, 2006 at 12:24:48PM +0100, Michael Niedermayer wrote:
> > You never really answered the question, does the overhead really bother you 
> > that much Michael? I want to make NUT done already. Rich wants keyframe 
> > exact seeking (and I agree), we all want demuxer and muxer simplicity, and 
> > the only solution for this is per stream pts and ptr in every syncpoint.
> 
> i dont think pts per stream are needed for this, what exactly was the problem
> anyway if we just have a rule like
> output a syncpoint immedeatly if a back_ptr changes by more then t
> doesnt that ensure that we never have to search more then t?

The problem is: how do you find the correct syncpoint to start your
search at? How do you properly assign timestamps to make it work?

I worked out a solution without per-stream pts (per-stream backptrs
only) and I believe it can be made to work, but it complicates both
the muxer and demuxer significantly. Oded and I both tend to agree
that solutions that require complicated implementations (especially in
the muxer, since the muxer must behave correctly but the demuxer can
ignore the advanced stuff) are bad. Not only do they make it difficult
to implement and scare people off from NUT (and possibly also
encourage them to make incorrect implementations); they also tie you
into a single algorithm for demuxing rather than leaving the full
information for the implementor to decide what to do with it.

> > The overhead is 50 to 70kb for every additional stream for a 700mb file, it 
> > really is not that bad. :/
> 
> hmm, then lets add a 50-70kb jpeg captured from whatever video input device is
> available ;)
> 
> its not only the overhead but also what you gain or loose

I think this is a lot more useful than a stupid jpeg attachment which
could just as easily be in a separate file..

Rich