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

[Michael Niedermayer]

Hi

On Mon, Jan 02, 2006 at 07:25:51PM -0500, Rich Felker wrote:
> 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! :)

iam not against a single seek iam against requireing that the seek
to be to the very last syncpoint from which the pts can be decoded ...
i also would like to add the condition that this rule should only
apply to files in which we can actually seek (if the subtitle packets
are megabytes away from the video keyframes you just cant correctly seek,
no subtitles will be displayed or you must wait wait wait ...)


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

cheap tape? where? last time i saw tapes they where more expensive then
HDs and CDR but that was quite some time ago ...

and anyway overhead will affect everyone, how many will use tape? i really
think your priorities are not hmm optimal ;)
i want a simple and effective container format not one which supports every
non existant theoretical possible codec on every type of media noone uses
ill use quicktime for these


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

NO you MUST search the 1-10megs! nothing will avoid this you can have 
complete knowlegde of all keyframes its still needed
its dead simple if you want all streams 1 pointer is equal to per stream
pointers (you require a single seek not 1 per stream and even if we did 
1 per stream it wouldnt work)


> 
> > 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) sure t will fail in some obscure example you will reply with
here but a feature people probably dont need and which will work exactly
in 99% of the cases and approximately in the remaining 1% just doenst
justify a fundamental design change which has significant disadvantages
in more likely cases

[...]

-- 
Michael