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

[Michael Niedermayer]

Hi

On Mon, Jan 09, 2006 at 03:28:28PM -0500, Rich Felker wrote:
> On Mon, Jan 09, 2006 at 08:56:28PM +0100, Michael Niedermayer wrote:
> > Hi
> > 
> > On Mon, Jan 09, 2006 at 09:18:13PM +0200, Oded Shimon wrote:
> > [...]
> > > > then theres the issue that players probably wont support inactivating streams
> > > > which will lead to very different behaviour with what i call broken files
> > > > and its also unlikly that (m)any players will support optimal seeking,
> > > > mplayer at least would need to be rewritten for it to be possible as far
> > > > as i can see, actually any player which uses float, double or a common
> > > > ms/ns timebase for seeking cant do optimal seeking, now which players
> > > > could support this without a rewrite? xine? vlc? ...
> > > 
> > > MPlayer's demux_nut.c will probably just use only audio and video streams 
> > > as active streams.
> > 
> > lavf will have sub streams active too, i see no logic reason why not and if
> 
> Certainly they shouldn't be active if the user doesn't want to see subs..

sure but if the user wants to see them they will be active and shown
immedeatly after seeking, IMHO a format which displays something else
at timestamp X depending upon how you reched X is broken dont you agree?


> 
> > it makes seeking slow ill fork nut and fix it
> 
> It doesn't make seeking slow with our method. See pros and cons below;
> with our method seeking is always fast regardless of which streams are
> active.

well there are no restrictions upon keyframe repeation, keyframe distance
or enough information in the index to skip from a subtitle keyframe to
a video keyframe, so that is going to be slow in practice no matter if
you accept it or not and with some additional restrictions and info it
would be much faster, avi, for example doesnt has that problem as it 
has enough info in its index to do that skip ...


[...]
> > > > even though iam
> > > > aware i will loose, rich is much better then me at convincing people
> > > > i just dont want to agree to a 30-100% increase of the overhead, and 
> > > > 1000% for the index without any gain for the end user
> > > 
> > > At least say "with little gain", it's certainely not without ANY gain...
> > 
> > sorry, its "with little gain"
> 
> Yes. Please don't get angry with Oded for slight inaccuracies in his
> evaluation of stuff either. We've all been making mistakes.

fully agree


[...]
> Anyway advantages for the end user were not the original goal of NUT,
> at least not _directly_. Many of them were things like simplicity of
> the implementation (which leads to the ability to support the format
> in a wide variety of tools and players, which is good for users),
> correctness (correct timestamps everywhere), etc.
> 
> Here is my summary of the pros and cons of both methods:
> 
> "Full seek info" (me & Oded's method)
> - moderately larger overhead but still smaller than mkv or
>   anything else
> - correct seeking is fast
> - muxer and demuxer are easy to implement and small
> 
> "Limited seek info" (your method)
> - extremely low overhead
> - approximate seeking is very fast
> - accurate seeking is very slow, even with index

its slower but the only cases where its
very slow are the ones with weird and "broken" streams and these will give
you a headache no matter what index and syncpoints you use unless of coarse
you dont display some streams after seeking but that again is something i
consider wrong


> - demuxer implementation is somewhat more complex

i dont see why

[...]
-- 
Michael