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

[D Richard Felker III]

On Mon, Oct 04, 2004 at 02:38:05AM +0200, Michael Niedermayer wrote:
> > my idea is to provide a "back-reference" packet type for streams to
> > use. essentially it would be optional, but it would work like this.
> > before writing a syncpoint (startcode), check each stream to see if
> > you've written a packet for that stream since the previous syncpoint.
> > if not, write a back-reference packet for the stream containing just
> > the (negative) byte offset to the previous packet in the stream. that
> > way the player can easily find the previous packet, check its
> > duration, and see if it still applies.
> 
> and how does this work with realtime streams? for example the song info for 
> the first played song would then be unavailable, the 5min subtitle too if we 
> missed it due to the startpos or packet drop ...

actually i said all this with realtime streams in mind too. if i made
a realtime streaming server, i would make it always send any
still-relevant info packets at the beginning of the transmission when
a new client connects.

> IMHO info packets or packets in an info stream need to be repeated frequently 
> enough to avoid the above issues, and if we do repeat them frequently then 

naturally something else needs to be done if it's a realtime stream
the client passively receives, e.g. over radio or something. in a case
like this, repetition might be useful. but imo repetition is just
wasteful when streaming over any medium where a reliable channel is
available.

> the back reference becomes pretty much unnecessary as searching through 0.5 
> or so seconds of the bitstream is easy

yes. but repeating data again and again could be very wasteful.
especially if it's big data. (and who knows what someone will want to
store in info packets...)

> 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...

maybe this feature would be useful for keyframes too. in my
description, i said a backreference would be used when there has been
no packet from the stream between the last 2 syncpoints. but it could
instead be used whenever there's been no keyframe between the last two
syncpoints. on the other hand, this is a lot of overhead with the
fairly-frequent syncpoints we're using now.

anyway, the keyframe search algorithm basically goes like this, iirc:
1. seek to a syncpoint (index O(1) or binary search O(n log n))
2. scan for keyframe (linear search O(keyint))
there are several variations based on whether you're seeking forward
or back, etc., but the O's are right anyway. this looks ok for
keyframe search because the keyframe interval is small and bounded,
but for other stuff...

i'm not adamant about the above proposal, and in fact i just
recommended putting it on hold and making sure it's possible to add in
the future, if desired. basically it's not all that important, because
the data we're talking about finding (subtitles and info) is probably
highly nonessential right after a seek. still it's an interesting
question...

rich