[NUT-devel] a few things about nut.txt

[Rich Felker]

On Sun, Nov 26, 2006 at 09:35:17PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Sun, Nov 26, 2006 at 01:57:54PM -0500, Rich Felker wrote:
> [...]
> > > > well! It also means seeking will be _incorrect_, in the sense that if
> > > > you disable video and just enable audio and subs, seeks will go
> > > > farther back than they need to in order to find the _useless_ blank
> > > > subtitle.
> > > 
> > > which will cause a few milliseconds of useless computations after a seek
> > 
> > Depends on the behavior of the player, but hopefully yes.
> > 
> > More fundamentally, the principle of "correct seeking" is violated,
> > and if we're going to violate that we might as well not have put so
> > much effort into ensuring that it works to begin with. You never cared
> > much about it but I did...
> 
> yes
> btw, last time i checked 50% of the code in libnuts demuxer is for seeking
> and its O(n) or more precissely it will in some not unreasonable scenarios
> (watch middle to end of movie then watch begin) have to move O(n) data
> around for every demuxed frame, in the cache used for seeking ...

yes, this is an implementation issue. if i were writing it (i might
actually write a third implementation just to have several approaches) i
would use a linked list instead of an array here, and linear search it
when seeking. compared to media seeks, any search operation in memory is
O(0) anyway; however, O(n) is very bad if it happens at times other than 
seeking (anything but O(1) is unacceptable there).

btw, a quick fix would be to always just append new syncpoint entries
when building the cache, and then move them into place only when it's
time to seek. but i always prefer implementations that don't require
special considerations like that.

> > > it means IMHO the thing is too complex already or the
> > > case which needs it is pretty obscure or the reasoning hasnt been 
> > > documented, in which case disscussing the issue and documenting the reasoning
> > > seems like a good idea ...
> > 
> > OK if someone can come up with a list of requirements/features/etc. in
> > NUT that seem unjustified, I will write up detailed documentation on
> > what they're needed for. Maybe I'll be wrong and it will be easy to
> > understand once I've written this...
> 
> ok, the following is a list of things which i think might look unjustified
> to at least some people (some people actually asked on nut devel about some
> of these) ...

thanks, i'll take a look at writing some stuff about them.

rich