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

[Rich Felker]

On Tue, Feb 05, 2008 at 12:29:40AM +0100, Michael Niedermayer wrote:
> > > 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...

Code is only justified for implementing a solution that's already
designed and specified. Throwing code at something new is a sign of
amateurs.

> 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.

Depends on what you're talking about it "coming out" of. No one says
that an interleaved mess of video, html, email, pings, etc. comes out
of the ethernet, because there's an appropriate layer delivering to
the application only the data it's interested in (and which belongs to
it).

My intent was never for such monstrosities to be written to disk as a
single file, but separated at the transport level. Of course even if
they did remain on disk, it's like talking about zip or rar files. The
possibility that someone might put two separate nut programs in some
ugly wrapping structure on disk doesn't mean nut should support
multiple programs internally any more than the possibility that
someone might create a .rar file containing a nut file and windows
codec binaries together means that nut should support embedding
windows codec dlls in the headers...

Rich