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

[Michael Niedermayer]

Hi

On Wed, Jan 04, 2006 at 07:05:00PM -0500, Rich Felker wrote:
> 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.

ogg -> ogm is not a closed format, avis design wasnt broken, it just wasnt
designed for variable framerate or codecs with dts!=pts
quicktime didnt support dts!=pts either until the extensions by .mp4
(ok it did support it by mpeg-ps in mov or so maybe but thats sick)
quicktime is what happens when you try to design a format which can handle
all non existing / theoretical things you get a bloated format where neither
muxer nor demuxer supports even a fraction of the features and new stuff
like b frames still needed changes ...
i strongly belive somehing similar will happen with nut if we overdo the
futureproofness, noone can predict what weird things codecs might do in
the future, so being prepared to adapt the format is better then trying
to support everything imagnable IMHO at least

about inherently incompatible, people always find a way to break the rules
if theres a reason to break them, here its not even hard
the compression methods oded and me came up with all lead to the possibility
to set all ptrs and pts equal to significantly reduce their overhead, i
can already almost see the windows kids writing nut compressers which remove
the pts&ptrs and encoding guides recommanding to run these over the files
as noone has ever noticed any disadvantages except maybe the reference 
(de)muxer failing ...


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

well, lets see, what i meant but didnt clearly say is somethnig like:
the only realistic case i can imagine ATM where you cant seek
during muxing is when you send the data away immedeatly like realtime 
streaming, broadcasting and so on, well the user might want to seek to the
future here but he wont be able to no matter what :)
and seeking into the past, well the player had seen this part so it has
complete knowledge about it, furthermore the file on the server can be
updated


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

the case with 10 streams IIRC had 2x addtional overhead but i
might be wrong, still 25% is alot too

[...]
-- 
Michael