[MPlayer-dev-eng] Lots of stuff for NUT

[Rich Felker]

On Fri, Jan 06, 2006 at 09:20:40PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Fri, Jan 06, 2006 at 01:59:52PM -0500, Rich Felker wrote:
> [...]
> > > now if the subtitle stream actually does contain non keyframes then you will
> > > either have to go with non-interleaving or find a way to find all the
> > > non-keyframes, repeating them wont work anymore
> > 
> > Now you're the one making unrealistic examples. :)
> > 
> > It's known that there will never be any low-cost way to seek in the
> > presence of multiple streams with inter frames that don't line up at
> > same (or nearly same) times. I dont think people will make such files
> > since other containers have little hope of handling them well too.
> 
> hmm i dont see a problem here at all, subtitles need very little time
> to decode, its finding the interleaved inter frames which is the problem

It's a problem with almost all containers -- that was my point. :)
If we can solve it, that's cool, but I don't think it's the most
important issue.

BTW the one container that's already solved this, albeit poorly, is
AVI. The index has _all_ frame locations so naturally you can grab up
whatever subtitle frames you need while seeking past everything else.
Hopefully we can find a way to accomplish the same goal without 24
byte-per-frame overhead... ;)

> anyway we would simply store the subtitles bziped in a single place,
> this is much more compact then spreading them over the file and
> it solves all the seeking problems without extra overhead ...
> please put flames below this line :)

Yes there will be "flames", albeit nothing hostile:

- impossible to play without loading all subtitles ahead of time.
- impossible to mux without knowing all subtitles ahead of time
  (consider e.g. closed captioning for live stream)
- bzip is bloated and ugly, kills simplicity criterion.
- for large files, storing all the subs in memory could be
  prohibitive, especially if they're bitmap subs.

Subtitles really are a dynamic stream like audio and video. They're a
sequence of objects which represent a presentation that applies during
a particular interval in time, and thus they should be treated as
such. I'd much rather deal with having the subs not appear for a
second or two after seeking on a hardware player with slow media
access, than have all kinds of horrible hacks that preclude sane
treatment of subs as a real stream.

Rich