I'm receiving a number of encrypted satellite channels with two Motorola DSR4410MD (multi-decrypter) satellite receivers. As the name implies, they can decrypt multiple encrypted channels (up to 64!). And the output can be ASI or Ethernet. They are output as a MPTS. Can getstream accept an MPTS over Ethernet and break them up into individual multicasts, also over Ethernet? Dave -- David Devereaux-Weber, P.E. Room B111 Network Services Division of Information Technology The University of Wisconsin - Madison 1210 W Dayton St. Madison, WI 53706 (608)262-3584 dave@doit.wisc.edu http://cable.doit.wisc.edu/
On Tue, Jan 13, 2009 at 09:03:24AM -0600, David Devereaux-Weber wrote:
I'm receiving a number of encrypted satellite channels with two Motorola DSR4410MD (multi-decrypter) satellite receivers. As the name implies, they can decrypt multiple encrypted channels (up to 64!). And the output can be ASI or Ethernet. They are output as a MPTS. Can getstream accept an MPTS over Ethernet and break them up into individual multicasts, also over Ethernet?
Currently not - getstream does currently only support direct dvb card input. Flo -- Florian Lohoff flo@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin
On Tue, Jan 13, 2009 at 09:03:24AM -0600, David Devereaux-Weber wrote:
I'm receiving a number of encrypted satellite channels with two Motorola DSR4410MD (multi-decrypter) satellite receivers. As the name implies, they can decrypt multiple encrypted channels (up to 64!). And the output can be ASI or Ethernet. They are output as a MPTS. Can getstream accept an MPTS over Ethernet and break them up into individual multicasts, also over Ethernet?
I just had a quick look - in the end it should be too hard to add. For making it clean i'd abstract away the demuxing in dvr.c. Basically dmx.c handles the hardware/kernel filters and dvr.c reads from the device and demultiplexes the stream into the individual added pid callbacks. So id make it a demux.c which calls the leave/join pid functions of the input channel, and gets feeded the packets ... If somebody adds a callback in dvr.c to a certain pid, dvr.c calls the appropriate dmx_join_pid. When rewriting to also handle network/pipe input id seperate the demultiplexing and making the callbacks to join/leave a pid be depending on an input type. Basically for network/pipe input the leave/join pids would be nops (as they are mostly for budget cards now). I am unshure how to handle this in the config file though. Currently the master of all is the adapter as its an exclusive resource. Now we have instances which have an input which can either be an adapter or a network stream (even be multicast, unicast, rtp or udp or tcp) or an adapter with all the lnb/transponder etc settings. Flo -- Florian Lohoff flo@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin
2009/1/13 Florian Lohoff <flo@rfc822.org>:
On Tue, Jan 13, 2009 at 09:03:24AM -0600, David Devereaux-Weber wrote:
I'm receiving a number of encrypted satellite channels with two Motorola DSR4410MD (multi-decrypter) satellite receivers. As the name implies, they can decrypt multiple encrypted channels (up to 64!). And the output can be ASI or Ethernet. They are output as a MPTS. Can getstream accept an MPTS over Ethernet and break them up into individual multicasts, also over Ethernet?
I just had a quick look - in the end it should be too hard to add. For making it clean i'd abstract away the demuxing in dvr.c.
Basically dmx.c handles the hardware/kernel filters and dvr.c reads from the device and demultiplexes the stream into the individual added pid callbacks.
So id make it a demux.c which calls the leave/join pid functions of the input channel, and gets feeded the packets ...
If somebody adds a callback in dvr.c to a certain pid, dvr.c calls the appropriate dmx_join_pid.
When rewriting to also handle network/pipe input id seperate the demultiplexing and making the callbacks to join/leave a pid be depending on an input type. Basically for network/pipe input the leave/join pids would be nops (as they are mostly for budget cards now).
I am unshure how to handle this in the config file though. Currently the master of all is the adapter as its an exclusive resource. Now we have instances which have an input which can either be an adapter or a network stream (even be multicast, unicast, rtp or udp or tcp) or an adapter with all the lnb/transponder etc settings.
I'm wondering if anyone is working on this? I've a similar Problem, I need a RTP (via multicast) to HTTP gateway (no remuxing needed).
Hallo, Frederik Kriewitz napsal(a):
I've a similar Problem, I need a RTP (via multicast) to HTTP gateway (no remuxing needed) You can try rtp2httpd, simple program of mine for just this purpose. http://shell.sh.cvut.cz/~oskar/blog/index.php?entry=entry090107-213013
Or, you may accomplish that by running dumprtp (or my enhanced version dumprtp6: http://shell.sh.cvut.cz/~oskar/blog/index.php?entry=entry090116-145531 ) from Apache via CGI interface (would need some extra script to work) Cheers, O. Caletka
On Mon, Mar 2, 2009 at 5:14 PM, Ondřej Caletka <O.Caletka@sh.cvut.cz> wrote:
You can try rtp2httpd, simple program of mine for just this purpose. http://shell.sh.cvut.cz/~oskar/blog/index.php?entry=entry090107-213013
Thank you. Too late for me now, I already hacked something together myself. I took a quick look at I and noticed that you're forking a new process for each connection. Did you ever test it with a lot of clients? I did a quick test of my hacked version which is single threaded (using libevent) on my desktop system (Intel Q9300 CPU) and it was working fine for up to 300 clients (1,7Gbit/s).
Frederik Kriewitz napsal(a):
On Mon, Mar 2, 2009 at 5:14 PM, Ondřej Caletka <O.Caletka@sh.cvut.cz> wrote:
You can try rtp2httpd, simple program of mine for just this purpose. http://shell.sh.cvut.cz/~oskar/blog/index.php?entry=entry090107-213013
Thank you. Too late for me now, I already hacked something together myself.
I took a quick look at I and noticed that you're forking a new process for each connection. Did you ever test it with a lot of clients?
No, I did not test more than cca. 6 clients. In my setup, the limiting factor is Fast Ethernet :), CPU usage is very low. Cheers O. Caletka
On Mon, Mar 02, 2009 at 11:26:24PM +0100, Ondřej Caletka wrote:
Frederik Kriewitz napsal(a):
On Mon, Mar 2, 2009 at 5:14 PM, Ondřej Caletka <O.Caletka@sh.cvut.cz> wrote:
You can try rtp2httpd, simple program of mine for just this purpose. http://shell.sh.cvut.cz/~oskar/blog/index.php?entry=entry090107-213013
Thank you. Too late for me now, I already hacked something together myself.
I took a quick look at I and noticed that you're forking a new process for each connection. Did you ever test it with a lot of clients?
No, I did not test more than cca. 6 clients. In my setup, the limiting factor is Fast Ethernet :), CPU usage is very low.
Typically all threaded/forked models fall apart because the working set gets bigger than the caches. Just think about 600 stacks, buffers, fd tables etc So a single threaded (per cpu), non blocking, event driven approach most of the time scales much better. My guess is that with getstream on a half way modern cpu the TS packet never actually gets read twice from memory - It gets received by DMA from the DVB card, gets copied to the userspace buffer which also puts it into the cache. And before it gets evicted from the cache the TS packet will be written to the kernel buffers which will on any decent hardware be sent by DMA to the networking card. Flo -- Florian Lohoff flo@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin
participants (4)
-
David Devereaux-Weber -
Florian Lohoff -
Frederik Kriewitz -
Ondřej Caletka