Display posts from previous
Sort by

Re: SAT>IP Protocol support

#121 by evarost
Diefenthal wrote:
evarost wrote:
Diefenthal wrote: 1. Software Emulation of an Sat>Ip Server for BDA Cards ?
Hi,

This sounds interesting! Can be feasible? :D

that is possible but for an hobbiest like me too much
for that is deep directshow C++ knowlege required
but a test implementation is in work ;-) https://github.com/MediaPortal/MediaPor ... rver_merge

and is really offtopic
if i can helping prog with his progdvb than will i try to help him
so good i can
So, I'll follow this MediaPortal development only for fun! :D

Related to assist to Prog in the testing, he ask for a VPN for do some tests with a SAT>IP server.

Re: SAT>IP Protocol support

#123 by evarost
Prog wrote: evarost: Last prerelease for you.
Hi,

I check pre-release "7.06.0c"

- No changes with DESCRIBE command (continues inside the code).

- Bug with channel change not fixed. I attach last rtsp.log. Related to this is suspicious: First "PLAY" command don't wait for response, you send after it a "TEARDOWN" command. I feel that the problem can be you need to wait for a response before send any new command. So, please, check "CSeq" values, I see them with a non common order.

Regards!
Attachments
Logs10-rtsp.zip
(963 Bytes) Downloaded 154 times

Re: SAT>IP Protocol support

#125 by Diefenthal
evarost wrote:
Prog wrote: evarost: Last prerelease for you.
Hi,

I check pre-release "7.06.0c"

- No changes with DESCRIBE command (continues inside the code).

- Bug with channel change not fixed. I attach last rtsp.log. Related to this is suspicious: First "PLAY" command don't wait for response, you send after it a "TEARDOWN" command. I feel that the problem can be you need to wait for a response before send any new command. So, please, check "CSeq" values, I see them with a non common order.

Regards!
my SatIp Rtsp Sample logs too
ProgramData Folder that can you share with prog with some luck helps this prog

Re: SAT>IP Protocol support

#126 by evarost
Diefenthal wrote: my SatIp Rtsp Sample logs too
ProgramData Folder that can you share with prog with some luck helps this prog
Yes! Enable "logs" in ProbDVB config, and in "\ProgramData\ProfDVB\Logs\" you will found them.

Related to current support in ProgDVB: My device has SAT>IP support in two variants: normal "pid" commands, and "program" commands. So it exports a .m3u file with all pre-scanned channels:
#EXTM3U
#EXTINF:0,Das Erste HD
rtsp://192.168.210.181:554/programID=5316609
#EXTINF:0,ZDF HD
rtsp://192.168.210.181:554/programID=5309441
#EXTINF:0,BR Süd HD
rtsp://192.168.210.181:554/programID=5272577
#EXTINF:0,RTL Television
...
So in this mode you can open any channel with any RTSP client (like VLC) without SAT>IP support.

Re: SAT>IP Protocol support

#129 by evarost
Prog wrote:About DESCRIBE: How I can detect it?
1. Your device not send "support" string.
2. DESCRIBE in list of supported commands "Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY"
Hi Prog,

The device always responds with an error to command DESCRIBE, except when you use "program" mode. This mode ins't part of SAT>IP protocol, but it's implemented for easy compatibility with non-SAT>IP clients (RTSP). Remember that now my objective is to use a RTSP url that request the FULL TRANSPORT STREAM (pids=all), one URL for each transponder in the sat (simple to create outside of your program). But to accept this, you need to NOT USE the DESCRIBE command. Yes, the server lists DESCRIBE as a supported command, but I feel this is a hardcoded response. The SAT>IP protocol don't use this command.

So, please, implement this easy and simple solution:

1) In the "DVB over IP" configuration window add one check box: "disable DESCRIBE commands".
2) The previous check box sets/unsets a var of the device (disable_describe).
3) In your current source that manages the RTSP protocol, add a simple if-then-else to check "disable_describe" to overcome the DESCRIBE request.

Remember: this command is only useful to receive info about the content of the stream. But using RTSP in the SAT>IP protocol always receives a DVB Transport Steam. So this is the reason to not use this command.

Please, please, please: can you di it?
Thank you! :wink:

Re: SAT>IP Protocol support

#131 by Diefenthal
evarost wrote:
Diefenthal wrote:i can him help on both sites sourcecode and testing and with some Infos from SES they look on my code too and let me know where it can give Problems
So, you work with SES?

i work not for SES astra it is an Hobby Project
but Tom Christophery look into that Project
evarost wrote:Yes, the server lists DESCRIBE as a supported command, but I feel this is a hardcoded response. The SAT>IP protocol don't use this command
with Describe becomes you the Tuner informations frontend, locked ?,Level,quality and so long

Re: SAT>IP Protocol support

#132 by evarost
Diefenthal wrote:with Describe becomes you the Tuner informations frontend, locked ?,Level,quality and so long
Ok, but my device (an STB, not a pure SAT>IP server) don't supports well this command (in fact, all SAT>IP software that I test don't reflects any info about the status of the tuner). So I suggest to Prog to add a simple checkbox to enable/disable this command. I have do it several tests with custom commands to my unit using a custom tweaked rtsp client (http://code.google.com/p/rtsprequest/). As far as I know, the use of this command isn't a requirement to request for receiving a stream. So my idea for ProgDVB is this:

* Create (manually) a m3u file with rtsp url's for each transponder in a sat. This url requests the full transport stream (without filtering). With this, Prog can do it all the processing like with any BDA tuner with software filtering. So functions are: tune frequency and receive stream.

Example:

Code: Select all

#EXTM3U
#EXTINF:0,Astra 12402 V 27500 3/4 DVBS
rtsp://192.168.1.111:554/?src=1&fe=1&freq=12402&pol=v&msys=dvbs&sr=27500&fec=34&pids=all
...
I feel this is the most simple way to integrate initial support of SAT>IP protocol in ProgDVB. After achieve that, I think Prog can start to add other functions: autodiscovering, multi-antena support, pid filtering, tuner status, etc. I hope with your support he can add these functions soon.

Regards!

Re: SAT>IP Protocol support

#133 by evarost
Diefenthal wrote: i work not for SES astra it is an Hobby Project
but Tom Christophery look into that Project
Great! So we can receive feedback from SES... interesting. I feel that for the Community a software only SAT>IP server will be an inflection point. What you think?

Re: SAT>IP Protocol support

#135 by Diefenthal
evarost wrote:
Diefenthal wrote:with Describe becomes you the Tuner informations frontend, locked ?,Level,quality and so long
Ok, but my device (an STB, not a pure SAT>IP server) don't supports well this command (in fact, all SAT>IP software that I test don't reflects any info about the status of the tuner). So I suggest to Prog to add a simple checkbox to enable/disable this command. I have do it several tests with custom commands to my unit using a custom tweaked rtsp client (http://code.google.com/p/rtsprequest/). As far as I know, the use of this command isn't a requirement to request for receiving a stream. So my idea for ProgDVB is this:

* Create (manually) a m3u file with rtsp url's for each transponder in a sat. This url requests the full transport stream (without filtering). With this, Prog can do it all the processing like with any BDA tuner with software filtering. So functions are: tune frequency and receive stream.

Example:

Code: Select all

#EXTM3U
#EXTINF:0,Astra 12402 V 27500 3/4 DVBS
rtsp://192.168.1.111:554/?src=1&fe=1&freq=12402&pol=v&msys=dvbs&sr=27500&fec=34&pids=all
...
I feel this is the most simple way to integrate initial support of SAT>IP protocol in ProgDVB. After achieve that, I think Prog can start to add other functions: autodiscovering, multi-antena support, pid filtering, tuner status, etc. I hope with your support he can add these functions soon.

Regards!
right, for stream initialze is Describe not required it give only informations
Setup, Play, Options and Teardown are the most needed Requests

to get SatIp Server IP is UPnP /SSDP required
for "src" and "fe" a Frontend Config page where the user can define the Diseq c Port


more in Detail

Detect Transmitter
-> Read Device Description - get Frontend Type and Count

Code: Select all

<satip:X_SATIPCAP xmlns:satip="urn:ses-com:satip">DVBS2-4</satip:X_SATIPCAP>
Comes from the device Description but is an optional Field

-> or send Rtsp Describe there is FrontendType and Count referenced too



Configure the Frontends "fe"= index of Count +1 "src" = Diseqc (must user set )

so have you all for tune something

Prog what think you are Wireshark captures filtered by rtsp rtp rtcp better for you to see how Satip Server working ?