Display posts from previous
Sort by

Re: SAT>IP Protocol support

#136 by Diefenthal
Prog has yesterday run a Marathon

but the good news is he is on a good way
progdvb.png
things that he must correct are

he use for each frequency a new tuner (Initialize a new Session with Setup! can with Teardown the Session or Play ChangeChannel fixed

than the SSDP ( for getting Server Information IP Frontend Types and Counts) should be inbuild so that Prog can use in the scan normal Transponder lists and build the rtsp URL so Server Information + Tuning Details the Goal is that the user must not use m3u list

Re: SAT>IP Protocol support

#137 by evarost
Prog wrote:Still wait result of last prerelease. I think that is good.

ps: DESCRIBE impossible test in VLC because no control link...
Hi Prog,

Sorry for delay in response: I'm very busy!

I checked last pre-release (7.06.03b): great news! With the skip DESCRIBE command I can receive the FULL TS !!! :D
Also, plugins are enabled (at time, I can't test it, but it's enabled), thank you! Plase, can you also enable Media Server Home for "DVB over IP"?

Nevertheless, several other problems:

1) Using the "program" mode (the original one), now it works worst. Several times when I change the channel, always fails. Please, review this. I feel the TEARDOWN command isn't fixed.

2) Now the LOGs of RTSP not includes responses, only the command you send. Without this info I can't view the problem. Please, re-enable full logs.

3) Now, using more than one "DVB over IP" device at time the system crashes. Up to now, I set 3 different devices with different configs: one for "program" mode, one for a FULL TS on ONE transponder, and one for testing. Up to now, with last releases I can use these "devices" without problems. However, with the last version, this config crash the ProgDVB! I can't work with more than one device. Please, can you fix this and support several of these devices with different config for each?

Thank you for your hard work! Your software is the best in the Windows platform for DVB!
:D :D :D :D
Last edited by evarost on Wed Jul 23, 2014 12:16 pm, edited 2 times in total.

Re: SAT>IP Protocol support

#138 by evarost
Diefenthal wrote:...the Goal is that the user must not use m3u list
Hi Die,

Yes this is the goal: full support of SAT>IP tuners. However, I suggest to support also, not autodiscovering sources, and other "simple" implementations. This will be compatible with software only solutions, or non full standard devices (like my stb).

Another question: How many FULL TS streams can provide at time your current device? It has 4 tuners, but can provide 4 Transponders with the Full TS concurrently without errors?

Re: SAT>IP Protocol support

#139 by Diefenthal
evarost wrote:
Prog wrote:Still wait result of last prerelease. I think that is good.

ps: DESCRIBE impossible test in VLC because no control link...
Hi Prog,

Sorry for delay in response: I'm very busy!

I checked last pre-release (7.06.03b): great news! With skip TEARDOWN I can receive the FULL TS !!! :D
Also, plugins are enabled (at time, I can't test it, but it's enabled), thank you! Plase, can you also enable Media Server Home for "DVB over IP"?

Nevertheless, several other problems:

1) Using the "program" mode (the original one), now it works worst. Several times when I change the channel, always fails. Please, review this. I feel the TEARDOWN command isn't fixed.

2) Now the LOGs of RTSP not includes responses, only the command you send. Without this info I can't view the problem. Please, re-enable full logs.

3) Now, using more than one "DVB over IP" devices creates a bug. Up to now, I set 3 different devices with different configs: one for "program" mode, one for a FULL TS on ONE transponder, and one for testing. However, with the last version, this always crash! I can't work with more than one device of this kind. Please, can you fix this and support several of these devices?

Thank you for your hard work! Your software is the best in the Windows platform for DVB!
:D :D :D :D
install Wireshark and you see all rtsp Messages rtp rtcp the full communication if you Need help with wireshark let it me know
evarost wrote:
Diefenthal wrote:...the Goal is that the user must not use m3u list
Hi Die,

Yes this is the goal: full support of SAT>IP tuners. However, I suggest to support also, not autodiscovering sources, and other "simple" implementations. This will be compatible with software only solutions, or non full standard devices (like my stb).

Another question: How many FULL TS streams can provide at time your current device? It has 4 tuners, but can provide 4 Transponders with the Full TS concurrently without errors?
the most devices have and use this Schema 1 tuner one Stream (sadly)
but with the DigitalDevices had 4 Tuners and can send 8 Streams but only one with Paytv

Re: SAT>IP Protocol support

#140 by evarost
Diefenthal wrote: the most devices have and use this Schema 1 tuner one Stream (sadly)
but with the DigitalDevices had 4 Tuners and can send 8 Streams but only one with Paytv
Hi Die,

Not really: The specification of the standard defines that one device can support more than one stream over the same tuner. In this case the device needs to create multiple filterings for each client. The problem, isn't the server... are the clients. Why? Because at time clients/servers use UNICAST, if they support MULTICAST then sharing one transponder ins't a problem.

But my questions is different: your DigitalDevice with 4 tuners has sufficient power to send 4 full TS to the network?

And finally, I like to clarify a misconception of the PayTV streams using SAT>IP. This protocol don't defines anything about decryption in the server... All CA is in the client. So you can receive ANY number of PayTV channels, the limit is the same than with FTA channels. If your serer can provide 8 streams, it can provide up to 8 encryted channels... the decryption will be done in the client side. If some device has support for a central CA this is out the scope of the standard, and nobody likes to support this technology as a mass market. When all TVs and STB devices supports SAT>IP, you will continue to use your current CI/CI+ system to access to PayTV services. Remember that this protocol only targets TUNERS OVER NETWORK and anything more.

Re: SAT>IP Protocol support

#141 by Diefenthal
evarost wrote:
Diefenthal wrote: the most devices have and use this Schema 1 tuner one Stream (sadly)
but with the DigitalDevices had 4 Tuners and can send 8 Streams but only one with Paytv
Hi Die,

Not really: The specification of the standard defines that one device can support more than one stream over the same tuner. In this case the device needs to create multiple filterings for each client. The problem, isn't the server... are the clients. Why? Because at time clients/servers use UNICAST, if they support MULTICAST then sharing one transponder ins't a problem.

But my questions is different: your DigitalDevice with 4 tuners has sufficient power to send 4 full TS to the network?

And finally, I like to clarify a misconception of the PayTV streams using SAT>IP. This protocol don't defines anything about decryption in the server... All CA is in the client. So you can receive ANY number of PayTV channels, the limit is the same than with FTA channels. If your serer can provide 8 streams, it can provide up to 8 encryted channels... the decryption will be done in the client side. If some device has support for a central CA this is out the scope of the standard, and nobody likes to support this technology as a mass market. When all TVs and STB devices supports SAT>IP, you will continue to use your current CI/CI+ system to access to PayTV services. Remember that this protocol only targets TUNERS OVER NETWORK and anything more.
i think you have me missunderstood

i had wrote that the most i have seen devices Schema one tuner 1 stream use and not what is in the spec is describe this are two shoes

whre the descrambling should be is not defined on Server or Client Side please Show me the descrambling way in spec on a mobile Telefon
what the industry want is clear what the user want is what other

Re: SAT>IP Protocol support

#142 by evarost
Prog wrote:Still wait result of last prerelease. I think that is good.

ps: DESCRIBE impossible test in VLC because no control link...
Hi Prog,

More tests:

1) Now, I can use a MultiDec plugin with "DVB over IP"... and works! Great! Nevertheless, some problems.

2) The channel change is a pain! If some program sends a command that generates an error, the tuner blocks it until 60 seconds. If you don't send the correct TEARDOWN, and wait until receive response, and wait until you send a new OPTIONS/SETUP/PLAY, I feel is imposible to do a correct channel change. Also, if I use plugins the problem it's that I need to retune the channel, but generates errors. But now I can't show in the logs the response. Please, reanable full log of RTSP calls.

3) To minimize network use I'm doing some optimization of the m3u file using "tune" commands (I use "tune" in contraposition to "program" mode). Please, see this simple tune file:

Code: Select all

#EXTM3U
#EXTINF:0,Two channels on Transponder
rtsp://192.168.210.181:554/?src=1&fe=1&freq=12402&pol=v&msys=dvbs&sr=27500&fec=34&pids=0,1,2,3,10,11,16,17,18,20,33,100,101,110,121,122,127,141,171,172,173,174,181,182,186,187,188,189,190,191,4058,4910
This call includes in the TS two channels, one encrypted and one in clear (FTA). I don't found any problem with the number of pids (I supose that the server is doing filtering in software, so no limit in the number of pids), and I think this is a simple way to receive all pids (including ECM) for a channel. However, using this URL your software not ever seems to work.

Why I need to provide to you to help in the fix of the channel change?

Re: SAT>IP Protocol support

#144 by evarost
Hi Prog,

I found another relevant point using "tune" commands... At time, are you sending the "refresh" command to maintaing the streaming?

See the specification of the SAT>IP protocol:

"The OPTIONS method may be invoked by clients to query servers on supported RTSP methods.
Clients also invoke the OPTIONS method in order to keep the RTSP session alive within the timeout
period."

With "program" commands, I feel that you don't need to do this. But using "tune" commands mode, you need to "refresh" the PLAY command. Now, each 50-60 second the channel starts to suffer stops.

Please, enable full rtsp logs to debug the problem, and add this OPTIONS method to maintain the session opened.
Regards.

More info 1:
After show the log, when the play stops you send a GET_PARAMETERS command. This is writed in the log:

Code: Select all

PLAY rtsp://192.168.210.181:554/stream=110 RTSP/1.0
CSeq: 19171
Range: npt=now-
Session: DA9B2389
User-Agent: ProgDVB


marker
GET_PARAMETER rtsp://192.168.210.181:554/?src=1&fe=1&freq=11436&pol=v&msys=dvbs2&mtype=8psk&ro=0.35&plts=on&sr=22000&fec=23&pids=0,1,2,3,10,11,16,17,18,20,33,44,45,46,47,96,97,98,99,164,1032,2190/ RTSP/1.0
CSeq: 19172
Session: DA9B2389
User-Agent: ProgDVB
Please, remove this GET_PARAMETER and change it to OPTIONS keep alive command, like write in the document in page 25 section "3.5.4 Maintaining a session (OPTIONS)"
When you complete this change, the channel don't stops/interrupts.
Last edited by evarost on Wed Jul 23, 2014 4:32 pm, edited 1 time in total.

Re: SAT>IP Protocol support

#145 by evarost
Diefenthal wrote:whre the descrambling should be is not defined on Server or Client Side please Show me the descrambling way in spec on a mobile Telefon
what the industry want is clear what the user want is what other
Hi,

In my opinion, the Industry needs to be more flexible with CA systems to enable multi-window use. My preference will be that the operators (aka CA developers, like Nagra) will provide new methods to access to the CWs. For example, using a mobile and 3G signal, they can register one user using the SIM card, and send in the DVB stream the code to access to the CW. At these days, the CSA algorithm can be executed in software, and it's feasible to incorporate it in mobile CPUs. So, the problem isn't the technology, but the closed mind of the companies around CA systems. Obviosly, more open is less strong, but the users really likes/needs to consume digital television not only in the TV, but in any device that can receive the signal... and using SAT>IP protocol, it can be ANY device with network support. So the option is go forward and begin to think in another way!

Related to the devices that you have: they support full ts (using "pids=all") with more than one transponder at time? I like to know this before purchase (or not) one of them.

Regards.

Re: SAT>IP Protocol support

#146 by evarost
Hi Prog,

I found where is the problem with the channel change using the "tune" commands.
Please, see the secion "A1.3 Channel Change Implementation" page 61 of the standard specification (http://www.satip.info/sites/satip/files ... on_1_2.pdf):

As you can see here, when a channel change is requested, no TEARDOWN command is send. Also no new SETUP or OPTIONS is send. Only a new Play!
The logic that I understand is:

1) Setup the tuner, using SETUP command. This reserves a tuner for you, and the server assigns to you a streamID (com.ses.streamID, not the RTSP Session).
2) You start to receive the stream sending a PLAY command over the stream.
3) When you like to change the tuner parameters, you send a new PLAY command using the same streamID and the new parameters.
4) You can repeat as many times as you like.
5) When you like to free the tuner, you send a TEARDOWN command over the stream.

Please, can you implement this different logic?
I hope I don't disturb you. Thank you for your support!

Re: SAT>IP Protocol support

#147 by Diefenthal
evarost wrote:Hi Prog,

I found where is the problem with the channel change using the "tune" commands.
Please, see the secion "A1.3 Channel Change Implementation" page 61 of the standard specification (http://www.satip.info/sites/satip/files ... on_1_2.pdf):

As you can see here, when a channel change is requested, no TEARDOWN command is send. Also no new SETUP or OPTIONS is send. Only a new Play!
The logic that I understand is:

1) Setup the tuner, using SETUP command. This reserves a tuner for you, and the server assigns to you a streamID (com.ses.streamID, not the RTSP Session).
2) You start to receive the stream sending a PLAY command over the stream.
3) When you like to change the tuner parameters, you send a new PLAY command using the same streamID and the new parameters.
4) You can repeat as many times as you like.
5) When you like to free the tuner, you send a TEARDOWN command over the stream.

Please, can you implement this different logic?
I hope I don't disturb you. Thank you for your support!

yes that i say/write yesterday to prog in emails that the Setup Play Options all is what he Need and teardown as last command
and today morning have i send him a link http://1drv.ms/1nThzd9 to him this capture Shows how it can be used
without comment at time

Re: SAT>IP Protocol support

#148 by Diefenthal
evarost wrote:
Diefenthal wrote:Related to the devices that you have: they support full ts (using "pids=all") with more than one transponder at time? I like to know this before purchase (or not) one of them.

Regards.

if i say buy this or that can it be that it not run by you
there are some more things that only the Server /Transmitter related

i run here on a fiberline network with enough bandwitch as exsample

if you really want a opinion from me , you live in Germany and have enough Money for playing with Sat>ip Servers
than order a Digital Devices Octopus Net test it if it not good for you send it back

regards Kay and not Die

Re: SAT>IP Protocol support

#150 by evarost
Diefenthal wrote: if i say buy this or that can it be that it not run by you
there are some more things that only the Server /Transmitter related

i run here on a fiberline network with enough bandwitch as exsample

if you really want a opinion from me , you live in Germany and have enough Money for playing with Sat>ip Servers
than order a Digital Devices Octopus Net test it if it not good for you send it back

regards Kay and not Die
Hi Kay (sorry for Die!)!

I'm also using wired networks, at gigabit speed, so don't need to care about this.

Mi question is because I don't think that all SAT>IP servers are equal. I feel several of them are using software only solutions. So, not all have the suficient power to achieve to put the FULL TS of each transponder to the network. So, I prefer to ask to people that has the real devices. To check the support it's easy: just to recall for tune with "pids=all", and check continuity of the stream with 1, 2, 3 or 4 tuners used.

Thank you in any case!