progdvb.com

Posted: **Thu Jul 24, 2014 6:34 am**

Hello again.
I am debugging RTSP/TS and GET_PARAMETER "must have" operation for keepalive. And I think this is not problem for satip.

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/ is bad link. Must be allts

First PLAY with stream id and other PLAYs with new parameters? Protocol is really crazy

It is from China developers?

Posted: **Thu Jul 24, 2014 7:34 am**

And still no reports from you about plugins. I they think won't work

Posted: **Thu Jul 24, 2014 9:16 am**

Prog wrote:And still no reports from you about plugins. I they think won't work

No, no! Plugins are WORKING! Thank you to enable the function for "DVB over IP" devices. Now, I suggest to enable also for "Home Media Server". I like to play channels over different devices!

Posted: **Thu Jul 24, 2014 9:28 am**

Prog wrote:Hello again.
I am debugging RTSP/TS and GET_PARAMETER "must have" operation for keepalive. And I think this is not problem for satip.

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/ is bad link. Must be allts

First PLAY with stream id and other PLAYs with new parameters? Protocol is really crazy It is from China developers?

Hi Prog,

1) You're wrong: the keep alive command is "OPTIONS" not "GET_PARAMETER". Please, review the specification of SAT>IP protocol as I suggest to you some posts before. viewtopic.php?p=63130#p63130 Your current "GET_PARAMETER" command is generating an error response, and the server interrupts the stream. Please, fix this!
The example command for keep alive in the document is:

Code: Select all

OPTIONS rtsp://192.168.178.57:554/stream=3 RTSP/1.0 
CSeq:5 
Session:2180f601c42957d 
Connection:close

Just use the stream number received (com.ses.streamID) with the response to the SETUP command, and the session ID of the RTSP.

2) The URL with "pids=..." is VALID, as equal "pids=all". The SAT>IP server accepts it, also your program. It's not a problem for you... it's work. I test this to reduce/optimize network use. Please, don't care about this and continue supporting any URL. I do all tests with "pids=all" and works, but also some tests with "reduced pids" to reduce the stream size (that for sure continues to work equally!).

3) The protocol isn't crazy. It's the SES specification of the SAT>IP protocol. Is an european protocol, not a china hack. The device is manufactured (I think) in China as any STB, but software is developed (I feel) in Europe. You only need to implement the specificaction, that is easy: SETUP for reserve the tuner, PLAY for set parameters and change channel, TEARDOWN at end to close the tuner. It's REALLY SIMPLE!
Note: Typical implementations use the SETUP command with "pids=none" to only reserve the tuner; and after receive the OK response, use the command PLAY to set parameters (freq, pids, etc.), and when channel changes send a new PLAY command with new parameters... and it's really fast!

Please, don't stop to suport SAT>IP protocol. At time, we only need that you replace the "GET_PARAMETER" with "OPTIONS" command for keep alive, use PLAY command to change the channel instead of the full SETUP-PLAY-TEARDOWN sequence, and enable HMS for "DVB over IP". With all of this, the first release of ProgDVB for SAT>IP will be complete! You are very close!

Posted: **Thu Jul 24, 2014 10:03 am**

2. I am mean that is bad for ProgDVB.
3. Crazy because he use RTSP but self RTSP. For example in RTSP GET_PARAMETER used for keepalive and some other point. "Fortunately Microsoft developed self TCP/IP" (c) from some old book.

Posted: **Thu Jul 24, 2014 10:37 am**

Prog wrote:2. I am mean that is bad for ProgDVB.
3. Crazy because he use RTSP but self RTSP. For example in RTSP GET_PARAMETER used for keepalive and some other point. "Fortunately Microsoft developed self TCP/IP" (c) from some old book.

Hi Prog,

2) Why? I repeat: I do my test with "pids=all" and with "pids=..." and both are WORKING (for only around 50 seconds, because the keep alive problem) with PLUGINS. Don't worry more about this.

3) Please, consider that RTSP != SAT>IP. The first is an ancient protocol, the last is a new protocol. SAT>IP only resuses RTSP as a part of the protocol to complete the transfering of the stream over the network. It's good to not rebuild the wheel when you create a new technology. SAT>IP reuses part of RTSP, UPnP and HTTP. You can support full RTSP (for IPTV sources) as the complete protocol, and RTSP for SAT>IP. As you can show it's simple/easy, you're close to complete it. Only need minor checks (if-then-else) if you use it for IPTV or SAT>IP to send or not some commands. For example, GET_PARAMETERS is a keep alive command "for a server" in the ancient RTSP protocol. In case of SAT>IP the server like to do a keep alive of "each" stream. So the specification is different. But very esay to do! Think that architects of SAT>IP have think about fast speed (open/close pids on the fly) so ancient RTSP aren't the best... but with a simple PLAY command with "addpids" or "delpids" you can do this like with a USB tuner. Please, change you mind: SAT>IP is FAST!

Please, don't stop the developement! I hope soon you can complete the first version for SAT>IP.
Thank you!

Posted: **Thu Jul 24, 2014 11:53 am**

You can try "c" prerelease also.

Posted: **Thu Jul 24, 2014 3:07 pm**

Prog wrote:Hello again.

First PLAY with stream id and other PLAYs with new parameters? Protocol is really crazy It is from China developers?

no Craftwork BBSky and SES have it designed

Posted: **Thu Jul 24, 2014 6:23 pm**

Prog wrote:You can try "c" prerelease also.

Hi Prog,

With last pre-relase (c), the keep alive problem is solved! Thank you!
However a vey annoying bug is introduced: When I open ProgDVB and select one channel (from SAT>IP), the channels shows well. If I change the channel (or after a scanning process), the RTSP commands are send out-of-the-order. See this log:

1) Open and select channel: OPTIONS, DESCRIBE, PLAY ... loops of OPTIONS. OK!

2) Channel to another channel: first PLAY, after TEARDOWN. Fail!

3) Repeat the channel: first OPTIONS, then SETUP, then OPTIONS... Fail!

4) Also, at close you send a TEARDOWN without streamID.

Please, if you try to implement the fast channel change (without TEARDOWN) the correct algorithm (in my opinion is):

1) OPTIONS only check if the tuner is free.
2) SETUP to any transponder with "pids=none" to reserve the tuner (OK if it's free).
3) When you like to show a channel: PLAY with the correct frequency values + pids.
4) Keep Alive with OPTIONS stream
5) For channel change repeat from "3".
6) When exit, free the tuner with a TEARDOWN channel.

It's simple, right?

So, for the last pre-release I can only open one channel, for change I need to close ProgDVB and reopen. Moreover, the logs continues missing the RTSP server response. Now I show one error message, I suppose that you omit OK responses. Nevertheless, it's very useful to have the full protocol (send and receive) to debug problems. Please, can you enable it?

Regards!

Posted: **Fri Jul 25, 2014 6:05 am**

This is simple but I am not can test on PC and RTSP code not simple...

Posted: **Fri Jul 25, 2014 11:48 am**

Prog wrote:This is simple but I am not can test on PC and RTSP code not simple...

you have all time that you Need i will help you at tis time range no Problem

Posted: **Fri Jul 25, 2014 1:26 pm**

Prog wrote:This is simple but I am not can test on PC and RTSP code not simple...

Hi Prog,

I'm your betatester!

Related to the last bug. Now I can change the channel... the workaround is disable "one click for channel change" option in the config. The crash is created when I do fast channel change (two clicks, are tow commands). From the logs, my opinion is that you are doing calls async. When you send a RSTP command you need to wait for the response, and not send more commands before. My suggestion is use a queue of commands and send commands from the queue. SAT>IP protocol is robuts, and now I'm checking that is fast... very fast! The server do commands as it just receive the command.

If you prepare a new pre-release with full logs of RTSP commands, perhaps I'll provide to you more info.

Regards!

Posted: **Fri Jul 25, 2014 1:39 pm**

Diefenthal wrote: and PS here as what News a new Appendix for the sat>ip Spec
SATIP-DVB-C-C2-draft-v1-2.zip
with other words Sat>ip supports now Satellite Cable and Terrestrial

Hi Kay,

I feel you are close to people that works with the standard. I have a suggestion: now when some client don't supports SAT>IP but RTSP it's difficult to provide compatibility. But it's easy to achieve this if the SAT>IP servers answer to non-SAT>IP commands using OK and not ERROR. A very simple experiment: compose a RTSP call to receive a channel and open VLC (videoLAN) with this URL. You can't open the channel, but only because the server respons with an error to the command DESCRIBE. The fix is easy: always respond to DESCRIBE with OK, and use a more detailed info in the response to indicate that this command don't have do it any real interaction. With this simple extension, any legacy software can use RTSP with SAT>IP servers using M3U files, and the protocol don't changes. The specification only needs to enforce the server to answer with OK to (unkown) SAT>IP commands.

What you thing?

Posted: **Fri Jul 25, 2014 2:05 pm**

evarost wrote: Hi Kay,

I feel you are close to people that works with the standard. I have a suggestion: now when some client don't supports SAT>IP but RTSP it's difficult to provide compatibility. But it's easy to achieve this if the SAT>IP servers answer to non-SAT>IP commands using OK and not ERROR. A very simple experiment: compose a RTSP call to receive a channel and open VLC (videoLAN) with this URL. You can't open the channel, but only because the server respons with an error to the command DESCRIBE. The fix is easy: always respond to DESCRIBE with OK, and use a more detailed info in the response to indicate that this command don't have do it any real interaction. With this simple extension, any legacy software can use RTSP with SAT>IP servers using M3U files, and the protocol don't changes. The specification only needs to enforce the server to answer with OK to (unkown) SAT>IP commands.

What you thing?

speake we over sat>ip Client or every Client that have rtsp Support?

vlc has rtsp Support right but is not a Sat>ip Confirmed Client
the same is for Mx or GoodPlayer

you becomes StatusCodes and if it not ok =200
becomes you the reasons too

Posted: **Sun Jul 27, 2014 7:36 pm**

Hi Prog,

Last version works! Thank you!

Some "minor" bugs exists:

1) If I'm playing some channel with plugins enabled, when I select "Settings/DVB over IP" then always the program crashes with this exception:

Type: Unhandled .NET Thread Exception
Method: System.Net.NetworkInformation.SystemNetworkInterface[] GetAdaptersAddresses(System.Net.Sockets.AddressFamily, System.Net.NetworkInformation.FixedInfo)

Stack:
at System.Net.NetworkInformation.SystemNetworkInterface.GetAdaptersAddresses(AddressFamily family, FixedInfo fixedInfo)
at System.Net.NetworkInformation.SystemNetworkInterface.PostWin2KGetNetworkInterfaces(AddressFamily family)
at System.Net.NetworkInformation.SystemNetworkInterface.GetNetworkInterfaces(AddressFamily family)
at System.Net.NetworkInformation.SystemNetworkInterface.GetNetworkInterfaces()
at System.Net.NetworkInformation.NetworkInterface.GetAllNetworkInterfaces()
at ProgDvbNet.IptvProviderForm.SetNetworkParameters()
at ProgDvbNet.IptvProviderForm.IptvProviderForm_Shown(Object sender, EventArgs e)
at System.Windows.Forms.Form.OnShown(EventArgs e)
at System.Windows.Forms.Form.CallShownEvent()
at System.Windows.Forms.Control.InvokeMarshaledCallbackDo(ThreadMethodEntry tme)
at System.Windows.Forms.Control.InvokeMarshaledCallbackHelper(Object obj)
at System.Threading.ExecutionContext.runTryCode(Object userData)
at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Windows.Forms.Control.InvokeMarshaledCallback(ThreadMethodEntry tme)
at System.Windows.Forms.Control.InvokeMarshaledCallbacks()

Extra details:

Howerver, If first I stop the channel, then sometimes no error (and sometimes crash). I feel is a simple bug easy to fix.

2) Now, channel change works (thank you!), but the first time I select the new channel it fails ("Error! Resource not found (404)." is the message in the status bar). Howerver, when I retry a second time for the same channel, always works. I feel the problem is you don't need to send the TEARDOWN for channel change. I can leave with this bug up to you implement the correct SAT>IP specification for channel change (no TEARDOWN, no OPTIONS, just new PLAY). Nevertheless, in the meantime I suggest to insert a "double" channel change as a workaroung (an option to repeat the channel change automatically).

Regards, and good job!

progdvb.com

SAT>IP Protocol support

Re: SAT>IP Protocol support

Re: SAT>IP Protocol support

Re: SAT>IP Protocol support

Re: SAT>IP Protocol support

Re: SAT>IP Protocol support

Re: SAT>IP Protocol support

Re: SAT>IP Protocol support

Re: SAT>IP Protocol support

Re: SAT>IP Protocol support

Re: SAT>IP Protocol support

Re: SAT>IP Protocol support

Re: SAT>IP Protocol support

Re: SAT>IP Protocol support

Re: SAT>IP Protocol support

Re: SAT>IP Protocol support