Prog wrote:1. No ECM on your picture. Then no way for plugin.
2. Per PID mode looks like very slow. Because usually software (and plugins) send commands for open/close by one PID. Not all pids like in sample from you link.

Sorry Prog!

Have you readed doc specs in the first post?
Please, review the document: http://www.satip.info/sites/satip/files ... on_1_2.pdf

I really need to say this:

1) The SAT>IP protocol has the same functionalities and drawbacks that any USB 2.0 DVB device.
2) Using current "programID" requests the ECM pids are not present in the TS. Yes! but this is tunnable with commands.
3) Using "pid commands" is possible to request the FULL TS (without any filtering) with just only one RTSP request.
4) PID mode is really FAST: When you like to tune a channel, you can request ALL pids that you like in ANY frequency that you like in just ONE RTSP request. Why you say that this mode is "slow"? It's the same that with any BDA device!

I feel that you don't have readed anything about the procotol!

Prog wrote:2. Per PID mode looks like very slow. Because usually software (and plugins) send commands for open/close by one PID. Not all pids like in sample from you link.

See this command In pids you can list ANY pids that you like, all in just one request. Slow?

When you say: "Send commands for open/close by one PID" this is only "if you like to open/close ONE pid", but you can "open/close" a LIST of pids. Also, in the SETUP request you can list any list of pids.

Review page 61 of http://www.satip.info/sites/satip/files ... on_1_2.pdf

I know. But plugins (and some ProgDVB parts) open by ONE pid. For example if plugin ask pid=123 then ProgDVB must open pid=123. No any list of pids... Best if you device support for stream all DVB traffic (all pids without remux)

Prog wrote:I know. But plugins (and some ProgDVB parts) open by ONE pid. For example if plugin ask pid=123 then ProgDVB must open pid=123. No any list of pids... Best if you device support for stream all DVB traffic (all pids without remux)

Ok, now I understand the problem... thank you for the explanation.

So, I try to do some testing with commands for receive the full TS without filtering. My idea is: provide a m3u file with URLs for TRANSPONDERS that sends the entire content. This will be good for you? In this case you will implement the plugin support?

Regards.

Yes, in this case device looks like DVB device. Of course that is request scanner (because more one channel per mux) and request 50-100 mbit of network.

Prog wrote:Yes, in this case device looks like DVB device. Of course that is request scanner (because more one channel per mux) and request 50-100 mbit of network.

Ok, I'll try to do!

In the meantime, please, fix the TEARDOWN command (I suggest, variables for tweak behaviour: number of repeated command and delay between them). Also the window for manual scan is very slow (blocking) with the DVB over IP device. Can you please, not automatically scan, but insert a "init" button?

Regards.

Dear Prog,

I have news about SAT>IP support!

First, I explain the setup that I have done:

A) I have downloaded this simple RTSP client: https://code.google.com/p/rtsprequest/
I modified the source code to control the calls and do any request that I need.

B) I execute TSReader Lite on the same machine waiting for a RTP stream over a specific udp port.

Using this environment I can send any request to RTSP in the device and analyze the TS received.

The results:

a) To receive the TS stream is mandatory to use RTP. If you use plain UDP, because the encapsulation is adding a header, you miss packets. I feel this is the reason for packet loss in the first pre-releases.

b) The device has support, and responds, to a request of a full transport stream (no filtering). If the URL command contains "pids=all" you receive all pids.

c) To operate a SAT>IP server, you don't need to use the DESCRIBE request. Moreover, this command isn't supported by SAT>IP devices. The standard overcomes this request, because is not relevant (you don't need to receive a sdp description of the stream, because is always a TS).

d) When you use "pids commands" (and not the "programID" URL), the typical list of commands is: So in the next post I will explain my suggestions if you like to include support for it in ProgDVB. You agree?
Regards!

pids=all is not bad way for me. I hope your network is good for that

And I think my TV Sources is total bad for DVB over IP without m3u

Prog wrote:pids=all is not bad way for me. I hope your network is good for that

Hi Prog,

My network ins't a problem: it's Gigabit.

So, my idea is this:

- I create a m3u file with one entry for each Transponder in the sat. Example (show only one transporder): - Then, you add an option in the "DVB over IP" device to disable DESCRIBE request (I suggest enable/disable to not broke your code and maintain support for other devices that use RTSP). And implement the behaviour of the "com.ses.streamID" header to use it in the PLAY request.

- Additionally you need to enable plugins for this "DVB over IP" device, so it's the goal of this support (initial support with programID is already done)

I feel it's easy for you to impleted this. Right?

Prog wrote:And I think my TV Sources is total bad for DVB over IP without m3u

Don't care about this now! Autodiscovering is the easy part, and can be done with external tools. If you support the SAT>IP RTSP Control, you have done the most important part!

Regards!

rtsp://192.168.1.111:554/?src=1&fe=1&freq=12402&pol=v&msys=dvbs&sr=27500&fec=34&pids=all
must working in current version after scan. About plugins yes, it is possible. But not very easy (I am not like start plugins for all network devices). And some technical problem with teardown on my side...

Prog wrote:rtsp://192.168.1.111:554/?src=1&fe=1&freq=12402&pol=v&msys=dvbs&sr=27500&fec=34&pids=all
must working in current version after scan. About plugins yes, it is possible. But not very easy (I am not like start plugins for all network devices). And some technical problem with teardown on my side...

Hi Prog,

This works on version "7.05.7c"? If yes I'll try now.

Nevertheless, Why you say "after scan"?

Related to plugins, please, this is the most important think! You don't need to enable it to any network device, only leave to the use the option the enable/disable it on "DVB over IP" devices. No more, no less!

Related to TEARDOWN. After my tests with "rtsprequest", no problems at all. Never I found any trouble for select a new channel after end previous session. I feel that the problem is that you are not waiting for the response, and if you close the socket, the server don't execute the command. You are doing in this way?

Regards!

Hi Prog,

Log from last "7.05.7c" pre-release: Please, please, please, include an option to disable DESCRIBE command!!!

Yes, I do this in near versions. Please wait some days (week?) I am very busy now.