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

[Michael Niedermayer]

On Mon, Feb 04, 2008 at 05:43:01PM -0500, Rich Felker wrote:
> 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.

Iam still waiting for the patch for ffmpeg...
It is either
A. easy, so it should be only a few minutes work for you.
B. not easy, in which case its likely not such a good idea as the
   alternative seems easier. It after all just has to pass the program
   info to AVProgram.

And keep in mind if its a nightmare to implement in ffmpeg it likely will
be as well for most other applications. The same applies to it being easy.


And the protocol "whatever its called ;)" will give you a multi nut in your
case, like it or not. You will either need a double layer protocol or double
layer demuxer. Because mpeg-ts comes out of it currently, and if you replace
it by your protocol+nut, then your protocol+nut will come out.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/nut-devel/attachments/20080205/b8578173/attachment.pgp>