After requesting a preset on a Vivotek Cam through MIP SDK, when requesting the stream from SDK , the TCP request to the recording server fails, and retries after 5 seconds. Is there a timeout for accepting TCP connection from diffrerent clients?

MIP
, ,
2

I am wondering if this might be a general issue that has not been caused by your integration.. If you test the same camera doing PTZ operations in the Smart Client, does the camera fail then?

I do not think there is such a timeout.

Does it work if you reverse the order?

Does it work for other cameras?

Please add some more information, perhaps you can show with snippets of code the exact use.

3

Thank you Bo for you answer.

As the letters were limited to ask the question, there is one point I would like to add : the request for the preset and for the stream are sent by 2 different stations, so the issue does not happen everytime.
The order is as follows : 1. Our server request the preset via SDK. 2. The client request the video stream.

Please find my answers :

I am wondering if this might be a general issue that has not been caused by your integration.. If you test the same camera doing PTZ operations in the Smart Client, does the camera fail then?

We cannot reproduce the same behaviour in SmartClient since if we need to call a preset, the video stream is already displayed and we don’t need to send a request to display it again

I do not think there is such a timeout.

We did some tests with wireshark, but I cannot find the capture at the moment. I shows that the preset request is accepted and treated, but 0.2 sec later the request for the live stream is rejected. 5 seconds later an « automatic » retry can be seen… and this one is accepted.

Does it work if you reverse the order?

It is hard to reverse the order without reworking all the code

Does it work for other cameras?

Yes it does work perfectly for other cameras of the same type/reference

Please add some more information, perhaps you can show with snippets of code the exact use.
It is hard to reproduce with 2 stations … We did try to reproduce with 1 station with SDK samples but we did not manage to reproduce

Best regards,

4

If you in the Smart Client do the PTZ preset operation, making the camera turn, does the live streaming get an interruption?

If you have one camera behaving like this while other cameras of the same models work I must primarily suspect the camera to be faulty.

5

Hi Bo,

Thank you for your answer.

The live streaming doesn’t get an interruption when the PTZ request is sent.
There are a few random cameras that have this behaviour. Most of the time, there is no problem even on said camera so I don’t think it’s a problem with the equipment.

I also had another question, Is it possible to use the UDP protocol beetween Recording servers and the clients (be it SmartClient or MIP SDK based ) ?

6

You could use Multicast, this is using UDP. Please look it up in the manual and evaluate if that would be an option. If you have questions on using Multicast please direct them to the Support Community. https://supportcommunity.milestonesys.com

7

Hi Bo and Rie,

Thank you for your answers, but after many further investigation we discovered the problem is trickier.

The issue is caused by long PTZ movement: when the movement is longer than 2-3 secs, there is a delay before displaying the video, the screen showing only “Connected to camera” and displays the video only during the last second of movement.

There is no issue in SmartClient.

We also discovered that this happens only with Vivotek SD9362-EHL cameras. We did the same tests with HIKVision PTZ camera and there is no video loss.

The issue seems to be in the communication between Vivotek SD9362-EHL and SDK. Camera Firmware is 0103f and DP is 9.9 which should be compatible.

To test the issue, we tried requesting the video first and then calling the preset or doing the other way around which has the same result…

Would you have some hints on what could be done to solve this issue ?

8

According to Milestone product’s architecture, cameras never communicate with SDK directly, cameras always communicate with the Recording Server.

I am wondering if you send PTZ command from your application what will happen in Smart Client then? Can you see the same issue as your application? Does the disruption in the video in your application appear the same way for the Smart Client watching the same camera? I am asking because I wonder whether the disruption in video images is happening between the camera and recording server or between the recording server and your application. My suspicion is that if there is a disruption it is in the camera and its communication with the recording server which will mean that the disruption will happen for any client using the camera.

9

Actually, if the video stream is already displayed in SmartClient ( or in a SDK based player) the video is not interrupted and we see the whole PTZ movement in the SmartClient tile.

The issue happens only when opening a “new” video display and requesting PTZ (even if there is already a video stream from the camera displayed elsewhere).

My guess is that the disruption is between recorder and player.

10

Which version and edition of the XProtect VMS are you using?

Views in Smart Client and ImageViewerControl are the same, so are you using ImageViewerControl in your application?

11

We’re using XProtect 2017R3 Corporate. And we also use imageViewerControl

12

ImageViewerControl in the Smart Client camera views and ImageViewerControl in the SDK are the same.

I think the only interruption is network interruption, so can you please check if the network connection is stable without any interruption?

13

In fact after further investigation, this behaviour can be reproduced using SmartClient, using Matrix and rules elements.

A rule requesting the video commutation and preset movement in the same rule has the same behaviour with no display of video until PTZ movement is done.

If this is splitted in to rules:

  • first video commute then Preset call, the video is displayed at once and PTZ Movement is seen
  • first Preset Call then video commute, no video connection before the movement is finished and then video is displayed.

It seems the preset call waits for an answer from the camera to process next actions. Is there a way not to wait for this answer ( if this is the real issue) ?

14

Dear Jean-Philippe,

I have been asked to look at this issue, and here is my comment.

First and foremost, you have already isolated the problem very precisely:

  • As long as the camera is physically moving (after activating a PTZ preset), it does not react to new stream requests.
  • Existing streams are not affected by the PTZ movement.

Only one single note on this: You could probably have reproduced this from a SmartClient - just not from a view items where you already have a stream. Instead, you can set up a rule which is triggered by a user-efined event and as an action activates a PTZ preset. Now you can - in the SmartClient - activate the rule from the left pane, and immediately afterwards bring the camera into the view (possibly speed this up by using a camera shortcut).

But in the end, you would only confirm what you have written already: The camera does not react to stream requests while moving - and this is unfortunately a camera issue of the purest kind.

Thinking of a solution for this: Does the camera have a kind of “freeze” function? Some cameras have such a feature which freezes the video stream while the camera is moving, in order to avoid a blurred image which only makes operators dizzy. I wonder if a side-effect of this feature is not establishing a new stream, and if turning it off might help.

But in the end, this is a camera issue, and you might have to contact Vovotek for assistance.

Should Vivotek disagree with my conclusion, or if you need more help, I would like you to create a support case with Milstone Technical Support. Should you do so, pls refer to this thread, refer to my name, and request that the new case be assigned directly to me.

Best regards,

Torsten