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

[Michael Niedermayer]

Hi

On Monday 04 October 2004 01:39, D Richard Felker III wrote:
> 6. back-reference packets
>
> ok hear me out, these aren't the stupid idea you think they are... :)
>
> suppose you've just performed seeking, and your file has subtitles.
> maybe the point you seeked to is right in the middle of dialogue, and
> you'd like to see the subtitle, but the subtitle packet actually came
> a little sooner, so it gets missed. a smart demuxer/player would
> probably have found the most recent subtitle packet while performing
> the searching to seek, assuming subtitle durations are fairly short.
> but what if you have a subtitle that's supposed to last for five
> minutes? granted this seems absurd, but maybe there's a good purpose
> that nobody's thought of.
>
> with the current system, you'll never see this five-minute subtitle
> unless you happened to seek to its starting time and let the movie
> play from there without seeking. this is frustrating. the same issue
> comes up for the proposed info streams, where you might have an info
> packet describing a long segment of the file, e.g. a whole song.
>
> what's worse, in the future, the same problem might occur for audio
> packets, if someone makes a codec with an insanely long window size.
> so there should be some solution.
>
> 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 ...

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 
the back reference becomes pretty much unnecessary as searching through 0.5 
or so seconds of the bitstream is easy
furthermore the demuxer is able to find video keyframes, so why shouldnt it 
also use the same method to find audio or subtitle keyframes?

[...]
-- 
Michael

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