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