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

[D Richard Felker III]

On Tue, Oct 05, 2004 at 03:30:51AM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Tuesday 05 October 2004 02:58, D Richard Felker III wrote:
> > On Tue, Oct 05, 2004 at 01:55:19AM +0200, Michael Niedermayer wrote:
> [...]
> > > 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).
> 
> u can have the same by adding a few fixed bits into the framecode or adding 
> some fixed bytes afterwards, it doesnt require any change to the spec or 
> (de)muxers

adding fixed bits to framecode will double the overhead for
low-bitrate files, and won't provide much error resilience at all.
you're basically guaranteed to find many many bytes that have those
few fixed bits set....

> > > 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, 
> 
> every stream should have an index

maybe so, but i'm not convinced yet. the problems i see:

1. imo it wastes a huge amount of space -- there's a lot of redundancy
   between the indices for separate streams.

2. when you seek to a point in the file, you need to know the new
   timestamps for _all_ streams. if each stream has a separate index
   (and assuming we don't index every single audio packet), then you
   have to look up a location for each stream from its respective
   index, then seek to all the locations and find the full pts, and
   finally walk to the common starting point you want to use
   (typically the video keyframe) so you know the final pts there.
   this is way too complicated!

3. of course this algorithm breaks down really bad with respect to
   subtitle streams. you could be walking a VERY LONG distance if your
   movie doesn't have much dialogue.

using a common syncpoint system, whereby all streams have their new
"full" timestamps coded at the same point in the file, got rid of all
these problems. maybe you can do it another way with the old keyframe
startcode method, but i don't see how...

> > > 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... :)
> 
> i wanted to name my nut experiment mncf, so u can than make rfcf, abcf, 
> ikcf, ... thats nice and systematic :)

well these names are useless if we're making something intended for
people to use, rather than just an experimental toy... :) so if you
don't object i think we'll keep nut. (unless alex prefers one of the
names i liked better to begin with)

rich