[MPlayer-dev-eng] a few nut suggestions [short startcodes]

[Michael Niedermayer]

Hi

On Wednesday 06 October 2004 17:55, D Richard Felker III wrote:
[...]
> > > - with real framecodes (especially with low bitrates where startcodes
> > >   won't be super-frequent) many of the framecodes will have a fixed
> > >   data_size_lsb and not set data_size_msb_coded. thus it will be very
> > >   unlikely to actually get a data size that's way too large and jumps
> > >   all the way too or beyond the next startcode in just one or two
> > >   steps.
> >
> > well the simple framecode used, uses 128 of the 256 values with
> > data_size_msb_coded set and 128 with it unset, IMHO thats pretty good
> > approximation for low bitrate
> >
> > u could also interpret the used framecode table as 256 streams and
> > data_size_msb_coded always set or 128 stream 1 keyframe flag and
> > data_size_msb_coded always set, or 64 streams 1 keyframe flag, 1
> > timestamp flag, or ... ; in either case the we will have the absolutely
> > same result
>
> ok unless anyone else has a major complaint or sees something i
> overlooked, i'm pretty much satisfied with your results. you've made
> good arguments why the limited case you cover with the test code is
> actually the general case.
>
> btw like i said before, i agree with basically all your changes except
> the keyframe startcode stuff. is there a good reason we can't discuss
> all these changes and reach a common ground instead of forking?

certainly, lets discuss the syncpoint vs. keyframe index stuff :)
what is the problem with the current (mncf) variant of it, it still has 
syncpoints but the index points to keyframes instead of the syncpoints
iam not against changing to a syncpoint index system, if there are problems 
with the keyframe based indexes, but IMHO the syncpoint index is more 
problematic
for example the case of subtitles where "keyframes" are 5min apart leads to 
the "how do we find the last subtitle" problem with a keyframe index its 
trivial, and for realtime streams where there is no index we have no hope of 
seeking back anyway
furthermore if we do cache the keyframe positions for seeking like its done in 
lavf/nut.c then we need to deal with keyframe indexes anyway

[...]
-- 
Michael

"I do not agree with what you have to say, but I'll defend to the death your
right to say it." -- Voltaire