[NUT-devel] revisions for nut-english.txt?

[Nico Sabbi]

On Monday 04 February 2008 05:50:48 Rich Felker wrote:
> On Mon, Feb 04, 2008 at 05:14:32AM +0100, Michael Niedermayer wrote:
> > > There's nothing keeping you from partitioning a physical
> > > channel via a separate protocol layer. For example, a DSL line
> > > has far more bandwidth than needed to watch youtube, but that
> > > doesn't mean that html, email, etc. is interleaved into the FLV
> > > container!! Rather, you have TCP for multiplex unrelated
> > > connections over a single physical network line. The same
> > > principle applies to broadcast channels as well. There is no
> > > excuse for container/transport incest!!!!!
> >
> > Thats all nice and well, just that the reason why nut cant be
> > used directly is because of maybe 2-3 lines in the spec.
>
> There are lots of things that could be added to NUT with just 2-3
> lines in the spec, but which have no place in a media container...
> Ease of adding to the spec is not an argument for something.
> Rather, one must think of all the troubles it makes. Remember,
> perfection is reached not when there's nothing left to add but when
> there's nothing left to remove.
>
> > And as solution you suggest
> > an additional protocol layer. Which is equivalent to double layer
> > muxing. Which actually violates the spec ...
>
> Storing other containers inside NUT violates the spec. Transmitting
> many NUT streams at once on a single physical link does not violate
> the spec anymore than sending NUT over TCP or storing it
> interleaved with other data on physical disk platters does.
>

the intention is not to incest the container with the transport,
but to 
- store N streams in a single NUT multiplex
- identify which of the N streams belong together (in what mpegts
calls program: 1 video, 1+ audio etc) by means of some
info packet.

Requiring multiple NUT streams is simply not practical and 
out of question in certain environments (e.g. broadcast channels) .
Simply look at how difficult it can be receiving crappy rt*p streams
that require more than 1 socket.
On the other side having a program map shouldn't require much
of an effort