[MPlayer-dev-eng] a few nut suggestions [seeking algorithm]

[D Richard Felker III]

On Tue, Oct 05, 2004 at 01:55:19AM +0200, Michael Niedermayer wrote:
> great, just dont forget to consider that
> 1. seeking of damaged streams should be possible without inconsistencies
> 2. we want to cache keyframe positions to speed future seeking up
> 
> both are fine with the current and past spec, and fully implemented in 
> libavformat/nut.c 

ok.

> anyway i will not contribute to current nut any further, i havnt decided yet 
> if i will fork it and reverse many things or leave nut development and work 
> on other things, but we clearly have very different opinions about how things 
> should be done, and many of your ideas simply lead to problems which are 
> quite complicated to workaround and iam the one who has to write 98% of these 
> workarounds, maybe i just dont understand the reasons behind some of your 
> suggestions but i simply dont see the need to redesign well working code 
> several times

imo there were serious problems we needed to correct, but i'm sorry
for leaving you with all the work of rewriting, and it was probably
very lame of me to always talk about how the lavf muxer was "probably
broken/suboptimal/whatever".

> the original nut spec with subpackets had problems, like buffering 
> requirements and such, a redesign was needed no doubt

agree.

> alex`s info packet change made storing arbitrary info data impossible and 
> complicated the design

don't blame alex because he committed it. i was behind that too. and
now i agree it was a bad change, but i didn't like the old way either.

> the short startcodes while cute serve no purpose at all

i disagree. they allow you to have a reasonable degree of error
resilience without putting tons of syncpoints (which cause massive
overhead).

> the syncpoints instead of keyframe based indexes create a heap of problems 
> which we havnt found solutions for yet
> ....

but it also solved a heap of problems, like when full-timestamps had
to be coded, which stream to base the index on, the whole debate about
whether all keyframes have a startcode (infeasible for intra-only!) or
just some & which ones, etc. i agree with you totally that a keyframe
based index is _nicer_ from a seeking standpoint, but i just don't
know how to write sane guidelines for which keyframes you assign
startcodes too. so in the absence of a good rule, i prefer having no
rule at all, and instead dispersing syncpoints with max_distance. this
also aids in error recovery a lot, since you can rely on max_distance,
which would not be possible if just keyframes had startcodes...

> but please dont missunderstand me, if i do fork nut iam not doing it with the 
> goal to finish it alone, instead its supposed to be some experimental variant 
> which i can freely change as i like without long discussions and which we 
> will hopefully merge back at the end

i don't misunderstand, and i won't hold it against you. but imo we
should decide what to do with the name. it's bad if there are two
incompatible containers floating around both called nut. do you want
to rename yours, or do you want us (me, alex, whoever else..) to
rename ours? if we need to rename, i have some good names in mind
still from the original list... :)

rich