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

[Rich Felker]

On Mon, Jan 09, 2006 at 12:37:36PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Mon, Jan 09, 2006 at 12:24:29PM +0200, Oded Shimon wrote:
> > On Sat, Jan 07, 2006 at 09:38:54PM -0500, Rich Felker wrote:
> > > On Sat, Jan 07, 2006 at 09:07:05PM +0100, Michael Niedermayer wrote:
> > > > Hi
> > > > 
> > > > On Sat, Jan 07, 2006 at 01:41:52PM -0500, Rich Felker wrote:
> > > > > 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?
> > > > 
> > > > hmmmmmmm, what about the following
> > > > 
> > > > * store syncpoints with timestamp and a single back pointer and a pointer
> > > > to the last index chunk
> > > > * regularely store index chunks using my proposed index format (syncpoint
> > > > timestamp+pos and keyframe flags for all streams and syncpoints since the last
> > > > index chunk)
> > > 
> > > The proposal still has per-stream pts, even for the index. Without it
> > > you won't be able to find the correct position with just a single
> > > media seek.
> > 
> > Index still needs improoving. I want this committed...
> 
> iam against reseting the tmp_* variables, the per stream pts in the
> syncpoints and index, the removial of the index repeation possibility
> and increasing the index overhead by a factor of 10 without a clear
> advantage for the end user

The index overhead is only increased by 10x for files that would
otherwise have artificially small overhead. It's never bigger than
what it would already be for an intra-only file.

Rich