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