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

Rich Felker dalias at aerifal.cx
Mon Feb 4 23:43:01 CET 2008


On Mon, Feb 04, 2008 at 09:39:04PM +0000, Måns Rullgård wrote:
> Rich Felker <dalias at 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



More information about the NUT-devel mailing list