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