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!! Moreover, folks with MPEG broadcast experience (and who ACTUALLY LIKE MPEG) are not qualified to make recommendations about what's needed! NUT's goal was never to copy MPEG but to redo things and do them correctly from the ground up. "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. Rich
On Wed, Feb 06, 2008 at 12:10:34AM -0500, Rich Felker wrote:
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!! Moreover, folks with MPEG broadcast experience (and who ACTUALLY LIKE MPEG) are not qualified to make recommendations about what's needed! NUT's goal was never to copy MPEG but to redo things and do them correctly from the ground up.
"People in the industry do it this way" is not an argument. As far as
One more related point: "Broadcast people will not adopt NUT unless we do X" is also not a valid argument, especially when X is simply "make it more similar to what they're used to", i.e. MPEG. There's no indication that they will adopt NUT if we bend over backwards for them, and in fact the more similar NUT is to MPEG, the less of a valid reason there is for switching. If anyone is ever to adopt NUT for broadcast (which I don't think should be a major goal early on anyway; video mastering/editing/production tools, underground scenes, etc. would be much better early-adoptors) it will be for the revolutionary qualities of NUT, not for its ability to immitate MPEG. If they want MPEG they'll just stick with MPEG, not chase after an MPEG-immitator. If NUT can get any major penetration/niche in other fields and prove its worth, universality, and device-independence, broadcast people might take notice 5-10 years down the line. But expecting them to jump to something new immediately is naive, and sacrificing good design principles for the sake of enticing them is utterly stupid. Rich
Rich Felker wrote:
I think we need a reality check here, as NUT is a FROZEN spec.
Ok
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!!
We could make it an addendum, have the broadcast stuff kept in compatible mode and just first help me converting the current nut in rfc (I don't have much time lately so help IS needed) and start pushing it there.
Moreover, folks with MPEG broadcast experience (and who ACTUALLY LIKE MPEG) are not qualified to make recommendations about what's needed! NUT's goal was never to copy MPEG but to redo things and do them correctly from the ground up.
Better know what is done and why. I have experience with RTP, I dislike some details of it and I could see the weak and the strong points of it. I think people that used MPEG a lot could give some informed input.
"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!
That is a good point.
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.
NUT doesn't have an rfc, NUT doesn't have a complete implementation (try remuxing a mkv in nut and see what happens with subtitles.) lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
On Wednesday 06 February 2008 11:11:50 Luca Barbato wrote:
Rich Felker wrote:
I think we need a reality check here, as NUT is a FROZEN spec.
Ok
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!!
the matter is reversed: MPEG works that way for a reason, although the targets aimed at by NUT and MPEG may be different and consequently the solutions chosen don't necessarily need to be the same. Surely NUT will never be used by DTV broadcasters, so multi-program delivery may not be an issue to consider, but -IMO- adding a lot of requisites to the stream layer for the purpose of delivering NUT muxes will not make the adoption of NUT easier. Not that I care too much: I intend to use it only on files and I don't work in the MM field, so...
We could make it an addendum, have the broadcast stuff kept in compatible mode and just first help me converting the current nut in rfc (I don't have much time lately so help IS needed) and start pushing it there.
addendums, extension and spec specializations are the recipe for disaster, whatever direction NUT chooses. A unified NUT spec encompassing *from the very start* everything needed is the only sane way to proceed, IMO
Nico Sabbi wrote:
We could make it an addendum, have the broadcast stuff kept in compatible mode and just first help me converting the current nut in rfc (I don't have much time lately so help IS needed) and start pushing it there.
addendums, extension and spec specializations are the recipe for disaster, whatever direction NUT chooses. A unified NUT spec encompassing *from the very start* everything needed is the only sane way to proceed, IMO
From my experience lots of discussion and some informed input happens once you submit anything to ietf. The way NUT is done adding optional fields and detail them in an appendix wouldn't cause that many issues.
considering that for broadcast we are discussing synchronization hints fields that could be completely disregarded once you have the file stored. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
On Wed, Feb 06, 2008 at 11:30:57AM +0100, Luca Barbato wrote:
considering that for broadcast we are discussing synchronization hints fields that could be completely disregarded once you have the file stored.
These should not even be discussed further since they were already demonstrated redundant. I'm fine with a formal document describing how NUT's existing framework supports synchronization for broadcast/streaming, but not new optional features to duplicate what we already have. Rich
On Wed, Feb 06, 2008 at 11:25:45AM +0100, Nico Sabbi wrote:
On Wednesday 06 February 2008 11:11:50 Luca Barbato wrote:
Rich Felker wrote:
I think we need a reality check here, as NUT is a FROZEN spec.
Ok
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!!
the matter is reversed: MPEG works that way for a reason, although
MPEG works that way for lack of good design. There's total codec-container-transport incest --- wow that makes 3 generations! The MPEG folks never had any interest in making things universal and codec-agnostic or application-agnostic. Their only aim was being able to make closed-box consumer-oriented applications capable of delivering the audio and video packets to decoder chips. NUT's philosophy is that the container should not dictate what you can or can't do with it; it's up to the recipient of the data, not the author, to decide whether they want to use it in simple playback, efficient nonlinear editing (within the limitations of the codec used), streaming to others, piping between unix-style tools, etc. As part of this, I agree that the container should not artificially preclude broadcast applications even though we do not anticipate any adoption by broadcast folks. But I believe the existing NUT design covers the requirements of broadcast, especially timing, in full.
We could make it an addendum, have the broadcast stuff kept in compatible mode and just first help me converting the current nut in rfc (I don't have much time lately so help IS needed) and start pushing it there.
addendums, extension and spec specializations are the recipe for disaster, whatever direction NUT chooses. A unified NUT spec encompassing *from the very start* everything needed is the only sane way to proceed, IMO
I mostly agree, though I would rather see useless things in an addendum that no one bothers with than polluting the core spec. Throwing premature design at a problem without understanding whether there really is a problem to be solved, especially when that design is influenced by such a design atrocity as MPEG, is even more of a recipe for disaster. Rich
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
On Wed, Feb 06, 2008 at 04:37:27PM +0100, Michael Niedermayer wrote:
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.
This is a plain falsehood. No one has demonstrated anything concrete that cannot 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.
And I debunked them, yet again. Rich
On Wed, Feb 06, 2008 at 10:52:17AM -0500, Rich Felker wrote:
On Wed, Feb 06, 2008 at 04:37:27PM +0100, Michael Niedermayer wrote:
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.
This is a plain falsehood. No one has demonstrated anything concrete that cannot be done.
Ohh yes i have. But we can start a game where i give you nut packets and you tell me the clock drift between your and my clock.
"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.
And I debunked them, yet again.
You have not debunked any single argument brought up in the broadcast discussion. You just ignore what people say and repeat in different words sketched solutions like a kid telling me i can divide by 0. Of course while keeping the standard axioms of a field valid. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes
participants (4)
-
Luca Barbato -
Michael Niedermayer -
Nico Sabbi -
Rich Felker