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

[Rich Felker]

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.

> * store the whole index again at the very end
> 
> seeking: (without the very end index otherwise trivial anyway)
> do binary search the find the index chunk which contains the time you want
> (the compare function first finds the next syncpoint and then goes back to
> the previous index chunk)
> if this one doesnt conatin keyframes for all the wanted streams try the
> previous index chunk and so on

IMO this requires a lot more complexity in the muxer and demuxer for
very small space savings, and the information is spread out farther
from the data it applies to such that the effects of damage to the
file could be a lot worse.

> > > > 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..
> 
> NOOOO, thats not good, rich you dont understand, the idea is to store a
> pic of the face of the person sitting infront of the computer without him
> knowing and hide that in the file ;)

Yeah I think I missed this, sorry. :)

Rich