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

[Rich Felker]

On Wed, Jan 04, 2006 at 08:26:24PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Wed, Jan 04, 2006 at 01:39:42PM -0500, Rich Felker wrote:
> > On Wed, Jan 04, 2006 at 11:52:03AM +0100, Michael Niedermayer wrote:
> > > > Well, what is it about it that bothers you? The overhead? I've already 
> > > > prooved that in high bitrate files, the overhead is irrelavent, and in low 
> > > > bitrate files, the frame headers are most of the overhead anyway. (If you 
> > > > do not agree with my tests please offer a better testing scenario)
> > > 
> > > i suggest to make per stream pts and back_ptrs optional
> > 
> > If they're optional they're useless -- this is like stupid matroska
> > where it's optional whether you want to store pts (lacing crap). As
> > soon as the essential information is optional, the container sucks
> > because idiots will omit it, plus the demuxer has to be MUCH more
> 
> and if its not omitable someone will fork and it would be omited again
> trying to enforce philosophical rules does not work, people will do
> what they think is best, if they dont need some stuff in the files for
> their purposes but that stuff means overhead they will find a way
> to remove it, this is one reason why open source is better then closed 
> source its easy to change stuff against the developers will

Open well-designed file formats don't get forked, especially when the
forked version would be inherently incompatible with the standard
demuxer. Hacks and forks only happen on top of broken formats that
were originally closed, like avi and quicktime.

> also if the muxer can go back and update past syncpoints then the method

This is not possible. The one thing I'm unwilling to compromise on
more than anything else is ability to write without seeking. This is
basic unix philosophy and there's no legitimate reason to break
pipability/streamability for a file that contans sequential data.

> with no back pointers and only a single pts per syncpoint allows frame
> exact seeking, if the muxer cant seek back its quite questionable how
> important frame exact seeking is

How does the limitations of the muxer have anything to do with what
the person playing the file would want to do with it??

> > I'm totally willing to drop per-stream pts in syncpoints entirely if
> > you have a O(log n) algorithm (without index) and O(1) with only a
> > single media seek algorithm (with index) to seek to the optimal point,
> > and any linear searching is bounded by small constant * max_distance
> > (i.e. not O(keyint)).
> 
> why is finding the optimal point important at all? if we can find it in

Because the case I have in mind is where the optimal point is exact
and any other point is nonexact -- particularly seeking to an exact
audio location in a file with audio and video.

> 99% of the cases and a near point in the remaining that seems fine
> why should the user have to accept 2x overhead for something she doesnt
> need?

It's not 2x, and as Oded has shown the overhead is trivial. For low
bitrates where overhead matters it's several orders of magnitude
smaller than the frame headers, and for high bitrate it's something
like 25% IIRC.

Rich