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

[Michael Niedermayer]

Hi

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
> 
> if we cant agree maybe we should do some voting on the per stream pts
> which are the main point of dissagreement?

or what about the idea oded had, IIRC that syncpoints have only one
ptr & pts and the index has them per stream?

[...]
-- 
Michael