search

lars18th / satip-rtp

multicast-rtp tool for controlling a SAT>IP server
8 stars 2 forks source link

Subscription limit #2

Open estimadarocha opened 6 years ago

estimadarocha commented 6 years ago

Did you test the limit of subscriptions using this tool?

Does this tool work as sat>ip client protocol, or each channel will be a request? i am asking this cause perexg said that when grab multiple streams through one tuner, the input TS stream must be parsed to split PIDs to the right HTTP session and the CPU is limited to do this..

lars18th commented 6 years ago

Hi @estimadarocha ,

Did you test the limit of subscriptions using this tool?

No. But I don't see any problem doing it!

Does this tool work as sat>ip client protocol, or each channel will be a request?

This tool acts as a "client" for a SAT>IP server. However, it's not a real client, as it not consumes the stream. More or less, it's like a Control Point for another Renderer that consumes from a SAT>IP Server (these terms are common in the UPnP standard). The output is a stream sended by the Server to the Renderer. An in fact the stream is a regular RTP MPEG-TS sended to a unicast or multicast address. So any client that can receive this kind of MPEG-TS can use the SAT>IP server using this tool.

In the other hand, it NOT requests "channels". It requests "STREAMS" (one stream per session); and these streams can contain one or more programs/channels.

i am asking this cause perexg said that when grab multiple streams through one tuner, the input TS stream must be parsed to split PIDs to the right HTTP session and the CPU is limited to do this..

Yes and not.

In a SAT>IP server the source is a tuner. Each tuner can get data from ONE MPEG-TS stream. And usually these streams are MPTS (multiple programs in one TS). That the server (or the tuner) does is FILTER the stream. If you don't like to filter it, and you like to receive the full transport stream, then you need to use the parameter "pids=all". However, a lot of SAT>IP servers use low powerful hardware. Then, when NOT using pid filtering the bitrate of the output can be very high. So, in this case you can receive a wrong stream o not receive it at all. But, usually when receiving just one program (or channel) the pid list is small and you receive an stream with a low bitrate.

So, yes. When you receive multiple programs from one tuner, you can be in troubles. But the reason is the bitrate and not the CPU.

I hope this helps you! Regards.

estimadarocha commented 6 years ago

how can i make multiple channels from same frequency/tuner? i tried it yesterday, but it doesn't work, they are always going up/down and just one keep working!

example multicast-rtp -s 192.168.1.81:554 -d 239.0.0.1 -p 5554 -u "msys=dvbs2&freq=12476&pol=h&sr=27500&pids=0,1,16,17,817,1286,6418,6419" multicast-rtp -s 192.168.1.81:554 -d 239.0.0.1 -p 5555 -u "msys=dvbs2&freq=12476&pol=h&sr=27500&pids=0,1,16,17,817,1285,6410,6411"

thanks for the previous answers!

lars18th commented 6 years ago

Hi @estimadarocha ,

In your example, you're generating TWO sessions. So the SAT>IP server can be smart (and use just one tuner for both) or dumb (and use two tuners). Then the solution is use ONE session for both programs:

multicast-rtp -s 192.168.1.81:554 -d 239.0.0.1 -p 5554 \
 -u "msys=dvbs2&freq=12476&pol=h&sr=27500&pids=0,1,16,17,817,1286,6418,6419,1285,6410,6411"

That's all! You only need to aggregate the pids in the pid list. :wink: And remember to select the correct program in the client, as both programs are streamed in the same multicast address (@239.0.0.1:5554).

And another tip: the destination port ("-p" parameter) isn't related to RTSP port (default 554). You can use any free port, like "12345", "10000", or whatever.

Regards.

estimadarocha commented 6 years ago

@lars18th

but i intend to have each program in a different door, this is not the multicast standard?

something like: 239.0.0.1:1234 - program 1 239.0.0.1:1235 - program 2 ....

the idea here was creat multicast channels and them use udpxy to convert to unicast.

i am just using this cause send full mux rtsp or http its hard over wan.

i already did the test in http mode... and i can't send full mux, first because the connection between datacenter and home make satipaxe have buffered and them dropped packages, and second because after a while satipaxe crash.

However if i send multiple http session's (one for each channel) it works perfect but satipaxe start to have problem's with cpu and i exaust the number of pids filtering before i have all the channels from a single tp!

lars18th commented 6 years ago

Hi @estimadarocha ,

I feel you need to reconsider your platform.

First of all, if you like to use "standard" multicast, or more precisely "one program in one multicast address", then the best is:

  1. Use one multicast address of each program, like:
    239.0.0.1:10000 - program 1 239.0.0.2:10000 - program 2 ...
    This has sense because multicast switches don't manage ports, only addresses. So, when you use the same multicast address and different port then you're flooding your network ports with all programs.

  2. And in this case, it's best to use the multicast config file like in the original multicast-rtp tool.
    See the example at: https://github.com/lars18th/satip-rtp/blob/master/multicast-rtp#L13

But, I suspect this is not that you like to do, as this mode runs all programs at the same time (it streams all!). If you like to use udpxy should be because you like to stream-on-demand.

In this case, you don't need at all the udpxy & multicast-rtp. What you need it's a SAT>IP server with HTTP support. Fortunately the minisatip included in the satipaxeproject has support! :wink:

You only need to create your ".m3u" with one line for each program with the correct pids; and use the SAT>IP server address as the address of the minisatip server. And you can proxy/tunnel the connection if you use a remote site.

I hope this helps you. Regards.

Note: This multicast-rtp tool is for clients (renderers) that only receive RTP MPEG-TS streams, and they don't accept HTTP and don't support the SAT>IP protocol. In this case the tool impersonates the client and it controls the SAT>IP server. The client is then passive and only receives the stream.

lars18th commented 6 years ago

Hi @estimadarocha ,

However if i send multiple http session's (one for each channel) it works perfect but satipaxe start to have problem's with cpu and i exaust the number of pids filtering before i have all the channels from a single tp!

In this specific case, I suggest another approach:

Using this environment all transport is done over TCP channels, so no errors (with sufficient bandwith). And the tvheadend requests multiple programs at the same frequency in just only one stream. So, your CPU problem with the satipaxe is gone.

Plese, test it! :wink:

estimadarocha commented 6 years ago

Hi @estimadarocha ,

However if i send multiple http session's (one for each channel) it works perfect but satipaxe start to have problem's with cpu and i exaust the number of pids filtering before i have all the channels from a single tp!

In this specific case, I suggest another approach:

  • Remote site: one satipaxe server (or any other SAT>IP server with RTP-over-RTSP support).
  • Local site: install one tvheadend instance and configure the satipaxe as a "remote" SAT>IP server. Enable RTP-over-RTSP support for this tuner. And configure it too as a SAT>IP server.
  • Local site: use any SAT>IP client to connect to the local tvheadend.

Using this environment all transport is done over TCP channels, so no errors (with sufficient bandwith). And the tvheadend requests multiple programs at the same frequency in just only one stream. So, your CPU problem with the satipaxe is gone.

Plese, test it! 😉

I have it running this way.... and its my prefered way... however i have big issues with descrambling!

trying to reach you on skype no answer... sorry to disturb!

estimadarocha commented 5 years ago

Hi @lars18th... This is kind a new test project... So if you want I can open a new issue.

I am trying to accomplish this:

Minisatip on source site Your tool on remote location subscribing to minisatip and multicasting it to 2nd network adapter of remote connection.

The purpose is to multiple instances of third party software to connect to your multicast results and not make multiple subscriptions to minisatip avoiding bandwidth problems and cpu.

Any ideas?

lars18th commented 5 years ago

Any ideas?

Yes!

  1. If you want a permanent multicast, then I suggest to run the multicast server in the remote site and use some "reliable remote multicast transfer tool". Test the good SRT tool: https://github.com/Haivision/srt

  2. If you need an on-demand multicast, then I suggest to use RTSP-over-TCP for the transmission between a local SAT>IP client and the remote SAT>IP server. Then use the multicast streamer to feed the stream from the local SAT>IP client (that's need to be a SAT>IP server too).

Other solutions will suffer transmission errors.

This is kind a new test project... So if you want I can open a new issue.

Please, open a new issue to discuss it.

Regards.

estimadarocha commented 5 years ago

Hmmm... will have to test...

the complete idea is to have minisatip (home) -----> minisatip (remote)

the minisatip (remote) will serve multiple instances (2-3) of Cesbo.

The only reason to have minisatip (remote) multicasting and not let cesbo connect directly to it it's because having 2-3 subscriptions with pids=all in a few adapters will exaust cpu probably.

lars18th commented 5 years ago

Astra-Cesbo... Great! :wink:

The only reason to have minisatip (remote) multicasting and not let cesbo connect directly to it it's because having 2-3 subscriptions with pids=all in a few adapters will exaust cpu probably.

Ok. Now I think I get the point. You want to make multiple subscriptions to the same transponder and pass just only one the transponder with only the necessary pids. It's that?

estimadarocha commented 5 years ago

Astra-Cesbo have already preliminar support for sat>ip!

However it doesn't act as a real sat>ip client it always subscribe pids=all even it only needs one channels... but this is Astra filosofy.

So if i have in the same lan as minisatip (remote) 3 x Astra-Cesbo (let's call them astra01,astra02,astra03)... i will have 3 request's exactly equal to each adapter... that's non sense... so if i find a way to multicast it to lan network maybe each astra could join it and not make requests for it self to minisatip.

is it clear?

lars18th commented 5 years ago

Astra-Cesbo have already preliminar support for sat>ip!

Great news! But as the forum is now closed, I'm far of news about Astra-Cesbo.

However it doesn't act as a real sat>ip client it always subscribe pids=all even it only needs one channels... but this is Astra filosofy.

That's a very poor solution. It's a simple "full MPTS tunning". You can do that without Astra support, with a simple SAT>IP-to-multicast streamer!

So if i have in the same lan as minisatip (remote) 3 x Astra-Cesbo (let's call them astra01,astra02,astra03)... i will have 3 request's exactly equal to each adapter... that's non sense... so if i find a way to multicast it to lan network maybe each astra could join it and not make requests for it self to minisatip.

is it clear?

Two questions:

  1. You really need to use Astra-Cesbo?
  2. Why you not use the SAT>IP protocol end-to-end?
estimadarocha commented 5 years ago

Is your nick on Skype lars18th? if so can you add me estimadarocha@gmail.com?

You really need to use Astra-Cesbo? is the only thing capable of make correct descrambling at least for the caids i use!

lars18th commented 5 years ago

Is your nick on Skype lars18th?

Sorry, no. I don't use Skype.

You really need to use Astra-Cesbo? is the only thing capable of make correct descrambling at least for the caids i use!

OK. I understand. Please, response to this: you need to process "continously" (decrypt 24/7), or "on demand". From my point of view this is the key question.

estimadarocha commented 5 years ago

continously!

lars18th commented 5 years ago

continously!

OK. Then you like to send the streaming from remote-to-local one time, and distribute it as multicast in the local LAN. Right? In this case Astra-Cesbo can do it alone. Why you need then the SAT>IP protocol?

estimadarocha commented 5 years ago

image

home have the first sat>ip server

lars18th commented 5 years ago

Ok, I see it. Thank you!

So my proposal it's this:

That's a solution for you?

estimadarocha commented 5 years ago

In Home: Configure your SAT>IP server to stream the entire TS (or only the pids that you need) to a multicast stream. Some servers can do it (like DigitalDevices) or you can use the satip-rtp with minisatip as the SAT>IP server (you can use the client mode if you have one hardware SAT>IP server that can't stream to a multicast address). With this you can obtain one multicast with the encrypted program (or programs).

i don't understand why do i need multicast on source site.... in my opinion on source site (home) i just need a minisatip sending MPTS streams throught internet to DC.

In DC (Remote): Install you Astra instances to decrypt the programs. And feed them with an additional Astra server (we can call it Remote Master) that feeds the stream from the home this master Astra. The Astra in the home then reads from the multicast, and it forwards it the the Master Astra in DC. Then every Astra client can read from a local multicast and decrypt the signal.

this is one possibilitie... one astra receive the MPTS in http or even with primitive support and multicast it to network so other astras can pick it! correct?