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

[Rich Felker]

On Thu, Sep 08, 2005 at 07:01:05PM +0200, Michael Niedermayer wrote:
> > > i still think the single pointer is enough, a file which stores keyframes
> > > once every 2 hours, can only be seeked to at 2hour granularity and yes
> > 
> > But obviously this isn't true at all for subtitle streams.
> > The key condition is that you only need to find a keyframe for stream
> > N if there will be another non-key frame for stream N before the
> > following keyframe for stream N.
> 
> 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

ok, that's a good explanation.
i don't like the idea of holes anyway, and i especially hate the idea
of people using them for intervals with no audio since it makes player
design very difficult. 

> just add a 0byte keyframe for subtitle streams every second where
> there is nothing displayed

and if the reference muxer requires a pending frame for each stream
before it can write anything (or at least a minimum-next-pts for each)
then this will strongly encourage apps using it to write sufficiently
many 0byte keyframes. :)

> or alternatively we could add some frame 
> duration or end-of-frame support but these will be less easy

There was always the issue of duration for subtitles, whether it's
something at the container level or the codec level. IMO it's best to
keep it at the codec level. Of course if a particular subtitle codec
wants to use a 'clear subtitle' packet at the end of a sub's duration,
rather than storing the duration in the initial 'display subtitle'
packet, that's even better. why? because 'clear subtitle' packets can
be marked as non-keyframe, so that the player will find a subtitle
that appeared before the destination seek point that's still supposed
to be visible. :)

(of course, the 'idle' packets inserted at regular intervals would be
keyframes, like you said. just the initial 'clear sub' packets would
be non-key.)

so you like this solution? i do. the only additional thing i can think
of, is that zero-byte packets might actually have a defined meaning to
some codecs. if necessary this could be worked around with a sort of
"do not send this packet to the decoder" flag. not sure if it's
necessary tho.

ideas?
i'm satisfied. the best way to kill the gap problem is to kill gaps.
:)

rich