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

Rich Felker dalias at aerifal.cx
Tue Jan 3 06:00:53 CET 2006


On Tue, Jan 03, 2006 at 05:27:31AM +0100, Michael Niedermayer wrote:
> > > 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.
> 
> NO you MUST search the 1-10megs! nothing will avoid this you can have 
> complete knowlegde of all keyframes its still needed

No, I'll outline the algorithm right here, allowing myself to make
additional assumptions like no out-of-order frames and perfect
timestamps just because we haven't finished working out how it works
in more complicated real-world situations. Here we go...

1. Start at the closest syncpoint A prior to the desired timestamp.

2. For each stream, this syncpoint contains a back_ptr pointing to the
   latest syncpoint B before the most recent keyframe prior to the
   syncpoint timestamp.

3. For each stream there are two possibilities. Either the latest
   keyframe before the desired pts is between the syncpoint A and the
   desired pts (in which case the back_ptr can't know about it), or it
   is within the max_distance bytes following syncpoint B.

4. In order to start at the latest point such that all streams will
   have keyframes before pts, simply choose the earliest of the
   back_ptrs and then the latest keyframes before the next syncpoint
   (if a stream has more than one). Exclude the streams which have a
   keyframe between syncpoint A and requested pts when making this
   choice of earliest back_ptr.

This last exclusion is what Oded has been worrying about, trying to
make syncpoint-placing rules to ensure that it doesn't happen. He
wants to avoid having to linear search this region before following
the back_ptrs.

It should be noted that in many (but not all) situations you can avoid
searching between A and the requested pts just by looking at the next
syncpoint C's back_ptrs, which you would know if you know the index.

> > > 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.
> 
> and that will work fine with an index it will work fine with a binary
> search without back pointers (implemented and working in lavc so dont tell
> me it wont)

I don't want to challenge you or say you're wrong on this, but I
really don't understand how you can seek to the closest keyframe
before a given timestamp without back_ptr. Could you explain? I'm not
looking for pathological examples like uau is. I just want to know
things work. If you have a system that works I'm sure it would settle
Oded down and keep him from wasting all my time thinking about
problems with NUT so I could get back to finishing libc.. :)

Rich





More information about the MPlayer-dev-eng mailing list