[MPlayer-dev-eng] a few nut suggestions [a couple additions]

[D Richard Felker III]

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.

i don't have a particular recommendation for the bitstream encoding of
this. naturally we must be careful not to do something stupid that
increases overhead.

also, imo something like this should be totally optional, since it's
usually not necessary and complicates the muxer slightly. in fact we
could (and perhaps should) omit any specification for it at this
point, and just ensure that it will be possible to add such an
extension later if we want to.

7. finalization packets.

for every audio and video packet except the very last ones in the
file, the duration of the packet is specified implicitly by the
relative pts of the next packet. however, duration is not currently
specified for the final packets in the file. imo this is a slight
limitation. if a player wants to take two files and string them
together as one virtual file by remapping the timestamps in the second
file, it needs to know exactly where the first file's streams end.
there could be other nice uses too.

what about ending each stream with a null packet (zero length) to
mark the duration of the final frame and an "end timestamp" for the
stream?



rich