Thank you everyone for your contributions.

a) I was indeed bucking up against rampant asshattery.

b) Not sure how any of that is even slightly relevant to this thread.

You’re bringing it up in some sort of attempt to shame or embarrass because you’ve lost on facts? For the record, I meant it when I said it then, and I don’t feel any differently now. And asshat is indeed a fabulous word.

[FTR, you've had two patches rejected and several more accepted if the twelve hits from Xiph.Org Trac are a complete set.]

Monty

Speaking of memorable quotes I cannot help but point at the following classic out of your feather after trying and failing to get patches into MPlayer:
http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2007-November/054865.html

======
Fine. I give up.

There are plenty of things about the design worth arguing about… but
you guys are more worried about the color of the mudflaps on this
dumptruck. You’re rejecting considered decisions out of hand with
vague, irrelevant dogma. I’ve seen two legitimate bugs brought up so
far in a mountain of “WAAAH! WE DON’T LIKE YOUR INDEEEEENT.”

I have the only mplayer/mencoder on earth that can always dump WMV2
and WMV3 without losing sync. I just needed it for me. I thought it
would be nice to submit it for all your users who have been asking for
this for years. But it just ceased being worth it.

Patch retracted. You can all go fuck yourselves. Life is too short
for this asshattery.

Monty
=====

We remember you fondly. I and many others didn’t know what asshat meant before, but now it found a place in everybody’s active vocabulary. I’m not being ironic BTW, sometimes nothing warms the heart more than a good flame and few have generated more laughter than yours

The ironic thing is that your fame brought you attention and the attention brought detailed reviews, which made patch acceptance harder.

I also failed getting patches into Tremor. You rejected them for silly reasons, but, admittedly, I did not have the energy to flame it through…

For the record: I have no vested interest in NUT. Some of the comments above could be read to suggest that Ogg would be a good base when starting from a clean slate. This is wrong, Ogg is the weakest part of the Xiph stack. You know that, but there are people all around the internet proclaiming otherwise. This does not help your case, on the contrary, so I try to inject facts into the discussion. Admittedly, sometimes I do it with a little bit of flair of my own

Cheers, Diego

>So in this application, Ogg has more than 300% the overhead of MP4.
>Ogg is known to produce large overhead, but I did not expect this
>order of magnitude.

Yes, Ogg is using more overhead. Let’s assume that a better muxer gets me .7% overhead (yeah, even our own muxer is overly straightforward and doesn’t try anything fancy; it hasn’t been updated since 1998 or so. “Have to extend to container for every new codec” jeesh…)

So this is really a screaming fight over the difference between .7% and .3%?

I don’t debate for a second that Nut’s packet length encoding is better, and that’s the lion’s share of the difference assuming the file is muxed properly. And if/when (long term view, ‘when’ is almost certainly correct) Ogg needs to be refreshed in some way that has to break spec anyway, the Nut packet encoding will be one of the first things added because at that point it’s a ‘why not?’. But until then there’s no sensible way to defend the havoc a container change would wreak and all for reducing a .7% bitstream overhead down to .3%. It would be optimising something completely insignificant at great practical cost.

17307153 bbb_theora_486kbit.ogv (the complete file)
- 15009926 bbb_theora_486kbit.theora (the video track)
- 02107404 bbb_theora_486kbit.vorbis (the audio track)
========
00189823 (container overhead)

17753616 bbb_youtube_h264_499kbit.mp4 (the complete file)
- 13898515 bbb_youtube_h264_499kbit.h264 (the video track)
- 03796188 bbb_youtube_h264_499kbit.aac (the audio track)
========
00058913 (container overhead)

So in this application, Ogg has more than 300% the overhead of MP4. Ogg is known to produce large overhead, but I did not expect this order of magnitude. Now I believe Monty that it’s possible to reduce this, but the purpose of Greg’s comparison was to test this particular configuration without additional tweaks. Otherwise the H.264 and AAC encoding settings could be tweaked further as well…

I wonder what you tested when you say that in your experience Ogg files come out smaller than MPEG files. The term “MPEG files” is about as broad as it gets in the multimedia world. Yes, the MPEG-TS container has very high overhead, but it is designed for streaming over lossy sattelite links. This special purpose warrants the overhead tradeoff.

Was NUT designed before MKV was released?