On Wed, Feb 06, 2008 at 12:10:34AM -0500, Rich Felker wrote:
I think we need a reality check here, as NUT is a FROZEN spec. I'm not sure if the term frozen was ever clearly defined, but roughly speaking it should mean that changes should be made only in cases where they do not change anything for the ordinary cases (common codecs in use, e.g. the whole keyframes thing) or where a serious bug/mistake/limitation is discovered during testing.
This whole broadcast issue has brought up a lot of "new requirements" with no legitimate argument for how they fulfill any need that NUT does not already meet. "Because MPEG does it" is NOT A REASON!!
I think people felt that the arguments where obvious. Anyway i think ive stated some of the arguments now explicitly.
Moreover, folks with MPEG broadcast experience (and who ACTUALLY LIKE MPEG) are not qualified to make recommendations about what's needed!
Not listening to anyone who has worked in a gived field is rarely a good idea.
NUT's goal was never to copy MPEG but to redo things and do them correctly from the ground up.
Yes, and i certainly would prefer if things can be done better than mpeg. The problem ATM is that "things" can not be done.
"People in the industry do it this way" is not an argument. As far as I can tell, everything done with MPEG broadcast can be done much simpler, for instance the time synchronization issue. Due to NUT's extremely strict interleaving rules, frame dts ALREADY serves as a synchronization timestamp!! There's no need for separate timestamps!
Please stop the insanity! NUT IS FINISHED. If anyone claims not, please show real, demonstratable bugs, not differences from MPEG. A difference from MPEG is not a bug but a sign of good design.
I think ive shown a few fatal deficiencies in the current design in my previous mail. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin