On Mon, Feb 04, 2008 at 09:39:04PM +0000, Måns Rullgård wrote:
Rich Felker <dalias@aerifal.cx> writes:
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.
There are standards for IP over MPEG-TS. One could supposedly use that for NUT over RTSP over IP over MPEG-TS...
I don't see how the extra layer of IP helps anything here. :) Really what I'm looking for is just a way that the _stream_ layer (byteio or whatever it's called in ffmpeg framework) would output a plain NUT stream for the selected program among whatever programs are being transmitted over the physical channel that the hardware is receiving. I don't care so much how it's done. My point all along has just been that I believe this is at a very different layer from multiplexing different parts of a single program which are meant to be synchronized and presented together. Rich