On Mon, Feb 04, 2008 at 10:24:27AM +0100, Nico Sabbi wrote:
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,
Regardless of the intent, that's what it is.
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.
It's easy to identify which ones belong together as a program: THEY ALL DO! If they don't, then they don't belong in the same container.
Requiring multiple NUT streams is simply not practical and out of question in certain environments (e.g. broadcast channels) .
How so?
Simply look at how difficult it can be receiving crappy rt*p streams that require more than 1 socket.
This is unrelated. For sockets, surely you would not want to send unrelated, irrelevant-to-the-recipient data; it's just a waste of bandwidth. Where the issue comes in is with broadcast channels over unidirectional links where all recipients receive the same content and the physical channel's bandwidth is large enough for multiple programs. It's really the fault of the hardware and protocol layers for not already partitioning such channels into multiple virtual channels. If they were going to switch to NUT (which I don't see them doing regardless of what idiotic tailored-to-their-broken-systems features we bloat NUT up with) they could just as well add a proper protocol layer for channel partitioning at the same time. Rich