[MPlayer-dev-eng] nut seeking without an index

[Rich Felker]

On Fri, Sep 09, 2005 at 03:24:48AM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Thu, Sep 08, 2005 at 08:34:55PM -0400, Rich Felker wrote:
> > On Thu, Sep 08, 2005 at 09:52:48PM +0200, Michael Niedermayer wrote:
> > > > > > no, thats wrong, it depends upon the duration of the keyframe, the
> > > > > > current definition in nut is that it lasts until the next frame
> > > > > > theres no concept for "holes" in streams like you seem to somehow
> > > > > > have invented for subtitle streams, all problems here seem to be 
> > > > > > caused by that
> > > > > > just add a 0byte keyframe for subtitle streams every second where
> > > > > > there is nothing displayed or alternatively we could add some frame 
> > > > > > duration or end-of-frame support but these will be less easy
> > > > > 
> > > > > we could also place just 1 0byte keyframe at the point where subtitles
> > > > > disapear and handle this differently from other keyframes, its also
> > > > > easy to detect by the zero size in the index on the demuxer side ...
> > > > 
> > > > yes but i don't see how this alone prevents having to use insanely
> > > > long backward pointers..
> > > 
> > > indeed alone it does not, but if streams for which the last packet is a 
> > > 0-key packet are ignored in the backpointer calculation then it does prevent
> > > them
> > 
> > btw both this method and the 'frequent zero-byte frames' method fail
> > to provide any way to seek to the closest "real" frame in a stream
> > with gaps, without using the index. whether this is a problem, i'm not
> > sure. (mainly it matters if you want to search for info stream frames
> > that describe some sort of chapter/song type boundaries, imo..)
> 
> it seems we somehow dont understand each other, zero KEYframes are not
> random fillers, they signify that there is nothing (silence/black/
> no subtitle/no applicable info)

ok, i see. :)
sorry i'm being stupid; thanks for clarifying.

> if a info stream frame applies to a period of an hour then its not legal to 
> put a zero keyframe in the middle, instead the info packet should be repeated
> thats needed anyway, just think of streaming/broadcast with no backchanel
> ->no way to seek

yes, this makes sense. i was thinking of a streaming system where each
client would get their own personally-muxed stream, but naturally the
way you're describing makes more sense in the (more common) broadcast
scenario.

rich