[MPlayer-dev-eng] a few nut suggestions [back-reference packets]

[D Richard Felker III]

On Mon, Oct 04, 2004 at 07:06:31PM +0200, Michael Niedermayer wrote:
> > > yes, if we reverse the keyframe -> syncpoint index change u purposed we
> > > could use the index to find this data very efficiently in non realtime
> > > streams, and for realtime we must repeat the packets anyway due to packet
> > > loss and similar
> >
> > how do you propose doing that, though? if we index every keyframe, the
> > index will be huge since audio is typically all-keyframes! then nut
> > will suck just like avi... :(
> 
> if we put a sync point between every packet it will also be huge, actually far 
> huger but noone will do this, neither will anyone put every keyframe in the 
> index

i never said to do this...

> > i know you proposed the rule of only using startcodes & indexing a
> > keyframe when it's the first keyframe to come after a non-keyframe,
> > but this optimization just works based off the assumptions of current
> > codecs. what if you had a codec (audio or video) with a pattern like
> > IBIBIBI or IBBIBBIBBI? adding tons more startcodes and index entries
> > would be a serious overhead burden.
> 
> what about the following rule: (1 index per stream and only keyframes in the 
> index)
> if the distance between 2 consecutive index entries is larger then 0.5 seconds 
> then there may be no keyframe between them

i'm against any rule with seconds in it, or any other arbitrary
physical constant. it puts an unnecessary scale in the format. for
example what if someone wants to record 1000 frames of video
comprising 0.01 second for scientific purposes, and similarly insane
"audio" samplerate for some high-frequency phenomenon? granted this is
very special-purpose, but there's no reason to limit nut by "normal"
human time scales.

> > > > > furthermore the demuxer is able to find video keyframes, so why
> > > > > shouldnt it also use the same method to find audio or subtitle
> > > > > keyframes?
> > > >
> > > > there will be a sane upper bound on distance between keyframes. is
> > > > there necessarily a sane upper bound on distance between subtitles or
> > > > infopackets? imo not...
> > >
> > > imo there should be
> >
> > i meant a natural upper bound. whether we want to impose one is
> > another matter.
> 
> there is no natural upper bound for video keyframes

not an absolute constant, but in practice there is, and it corresponds
to the precision to which the person encoding wants to allow seeking.
on the other hand, there's no such notion with subtitles or info.

rich