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

[Rich Felker]

On Mon, Jan 09, 2006 at 09:15:01PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Mon, Jan 09, 2006 at 02:44:42PM -0500, Rich Felker wrote:
> > On Mon, Jan 09, 2006 at 09:18:13PM +0200, Oded Shimon wrote:
> > > IMO That's backwards. If the idiot translator messed up the subs, that's no 
> > > reason to ruin the entire file. Also most likely you won't even have the 
> > > subs set as an active stream even if you were interested in them, they'd 
> > > just reduce acruaccy of seeking wildly, but if I really want to see the 
> > > subs always, I want the ability to turn it on.
> > > A single stream should not break the entire file...
> > 
> > Agree strongly.
> 
> disagree strongly, this is like having a single bug not break a whole html
> page, you know where that lead to ...
> and you also contradict yourself, you said you want to make the spec hard to
> violate so why now allow a broken stream?

I didn't mean to allow a broken stream. Rather I meant that you might
have a legitimate but irrelevant stream with huge frame durations or
keyint.

> > > > > 10kb an hour was never a realistic goal for the index IMO... (And as I've 
> > > > > said, with max_index_distance of 32kb, index really was 100kb. Only 2 cases 
> > > > > it was 10kb an hour, with max_index_distance of 512kb, and with collapsed 
> > > > > syncpoint index with single back ptr)
> > > > 
> > > > 10kb was a realistic goal and it was what the original spec would have used
> > > 
> > > Original do you mean what we have now? The spec currently suggests using 
> > > max_index_distance of 32kb, which gives a 100kb index with audio and video 
> > > for a 1 hour file. Also current spec is just wrong, see below.
> > 
> > It's realistic in the sense that, if you _only_ want to index video
> > keyframes, and they come once every 3 seconds, you have 1200 keyframes
> > per hour and thus less then 10kb of index.
> > 
> > However common this case is, I don't see the value in making ugly
> > hacks (omitting most of the seekability) 
> 
> seekaility to what? audio with green video?

Audio with no video. Just because a file contains both, why should I
necessarily want to watch/listen to both?

If you don't like my example of using your music video files as normal
music files, what about the opposite? i.e. huge audio frames to
exploit long-term redundancy, or I/P audio codecs? If I have the audio
turned off, or if I'm using this in an editor, etc. then why should I
have to go all the way back to the audio's back_ptr if I just want
video?

> > just for the sake of making
> > index overhead tiny in one special case. Every other case (intra-only,
> > audio files, etc.) will have at least 100-200kb of index.
> 
> this is false the original index didnt behave that way as it didnt conatain
> all keyframes, i remember that you strongly wanted that but i repeatly
> rejected it, my index definitly did not behave this way

OK fair enough. I forgot about that part. And I still strongly oppose
any method that leaves you with an unbounded (or even long) linear
search to find the keyframe you want. Such an index is almost
worthless unless you want super-low-resolution seeks, since a binary
search will be just as fast..

> > and I really doubt most of the developers
> > have even followed this or know or understand the differences. I know
> > one developer who will just vote whichever way he thinks will make NUT
> > suck, out of spite...
> 
> well IMO you dont need to understand the details to vote, its about the
> effects for the end user not if the details match your philosophy of
> how it should be done

I think it's about both, but which it should be about is part of the
matter under discussion. Matching the philosophy is part of matching
the needs of an advanced user, imo. If you want to make Windows users
happy, anything that can store multiple streams and subtitles will do.
Hell, they're even happy with AVI. One of my big goals for NUT all
along has been universality. This does not mean bloating it with every
optional feature someone might want, but it has always meant things
like zero-buffer muxing and demuxing, pipability/streamability, full
pts info, and IMO it should also include sufficient information to
seek to any point in constant-bounded time.

(This last thing is not strictly a requirement since you can always do
exact seeking with a big enough linear search, but that's extremely
slow, ugly, and hackish.)

> > Hundreds of streams is rather stupid.. BTW, overhead already increases
> > as O(log n) anyway because of space needed to store stream number. IMO
> > the overhead for pts/backptr can be closer to O(log n) too if it's
> > compressed well and exploits the redundancy between streams.
> 
> i disagree i think the overhead is O(n) not O(log n) but that might
> be proofable if you think otherwise

Ultimately it's O(n); however if the backptrs and pts are similar (or
identical) between many streams, it's something like O(# of distinct
values + log n).

> and your system has a problem too, you wont display half of the
> streams after seeking (subtitle streams for example)
> now most solutions to this will make per stream ptrs&pts obsolete
> IMHO

I think you misunderstand my proposal. I never said that you _should_
ignore some streams for seeking, just that it's your choice. With my
proposed system, it's easy to find the latest point such that an
arbitrary subset of the streams all have a keyframe between that point
and the requested pts. As a special case, if the subset is just a
single stream, you get the exact latest keyframe for that stream
before the requested pts.

I can outline the algorithm in pseudocode if you like.

Rich