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