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

[Rich Felker]

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.

> And which i then have to somehow support in ffmpeg in addition to mpeg-ts
> and everything else that implements things the other way around.

FFmpeg does not need its own TCP stack or filesystem code, because the
task of transmitting/storing multiple unrelated data streams on a
single physical link/device belongs to the operating system and/or
hardware, not to applications.

Rich