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

[Michael Niedermayer]

Hi

On Fri, Jan 06, 2006 at 03:54:43PM -0500, Rich Felker wrote:
> 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... ;)

hmm, actually this is easier then it seemed, and needs nearly no overhead i
think, just store per syncpoint a flag for each stream if it has a non-key
frame, this could be stored the same way as the has_keyframe is stored in
my suggested index, for intra only streams it would only be a single v for
the whole file :)


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

ok, i think you convinced me here ...

[...]

-- 
Michael