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

[Rich Felker]

On Mon, Jan 02, 2006 at 09:29:48PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Mon, Jan 02, 2006 at 08:02:17PM +0200, Oded Shimon wrote:
> [...]
> > The small addition I have to the goals:
> > If there is an index, promise that no more than a single file seek are 
> > necessary for seeking to pts.
> 
> this is not a clearly defined goal, requiring seeking to the last syncpoint
> from which a given pts can be decoded in a given set of streams is a better
> definition
> 
> 
> > 
> > I will not give up this goal.
> 
> no matter what consequences it has? without ANY justification why this goal
> does any good for the end user?

Michael, Oded is saying that he's unwilling to accept any seeking
soluton where more than one seek operation on the underlying stream is
required. This is a reasonable demand since the media might be
extremely slow, e.g. a network protocol or even non-random-access
media like tape! :)

(For anyone laughing at tape, don't! It makes a lot of sense for a
high bitrate hardware camera device -- large storage capacity and very
very cheap.)

> > > > This solution is overcomplicated and makes a compliant muxer harder to 
> > > > write. When I thought it was the only viable solution, I voted for it, but 
> > > > I now like the "pts per stream" idea much much better. It is much simpler, 
> > > > and I've yet to find a flaw in it except overhead, and I think it might be 
> > > > possible to reduce that. The steps to find the syncpoint you want:
> > > 
> > > personally iam much more liking the idea of droping multiple backpointers
> > > and store a single one per syncpoint, i still have great doubt about the
> > > advantages of multiple ones, you at least need 2 streams with large keyframe
> > > distances, but this already means large distance in bytes and that simply isnt
> > > possible on slow media, not to mention large distance might mean lots of time
> > > to decode to a common timestamp ...
> > 
> > I'm pretty lost by what you have said here?...
> > 
> > A single back pointer CAN work, but only if you linear search the ENTIRE 
> > region it is pointing to, which can be 2 or even 10mb. And to fullfill my 
> > index promise, you'll also need to CACHE that, which is additionally 
> > insane. The basic problem with a single back pointer is that there is no 
> > way to avoid it sending you too far back.
> 
> my claim is that your "solution" does not avoid linear searching that region
> you just dont realize it, ill try to show this again, lets assume we are
> "interrested" in all streams, i hope you will agree that in that case there
> is no difference between 1 back pointer and per stream back pointers? now
> if there is no difference we will need to search that region too ...

Search what region? Only the max_distance following the syncpoint
which backptr points to, not the whole span between keyframes. This is
the difference in 32k and 1-10 megs.

> you could agrue that things are different if we are just interrested in a
> subset of the streams but IMHO such a file is simply broken its like adding
> a broken stream and then designing a container which can "ignore" it

No, it's not nonsense. The most common example I can think of is a
music video, where the audio is the "primary" stream. If you're just
playing the audio you want to be able to seek to any timestamp, not
just the video keyframes. Even if you will be playing the video you
might want to ignore it for seeking and just display a black frame
until the next video keyframe comes.

Rich