RTSP_UDP not selected in Custom URL when RTSP_TCP selected from ONVIF profile


#1

Hello,

A screenshot to explain the problem, quick fix is to “force” to RTSP_UDP in “stream type” listbox but if you do not notice it you get connect failure if camera is not TCP capable.


#2

Thanks!
Forward to @Steve
-Henrik


#3

It is on purpose because most cameras will return RTSP_UDP when queried in onvif but in reality offer both udp & tcp so netcam studio is trying to set it in tcp as tcp is much better and guarantees that the packets will arrive in the good order and none will be missing.

If it fails it will warns you in the event log and tell you that you need to force it to udp (which you did)


#4

Hello,

Yes it is true that it is written in event log but if you have a lot of events you will not see it (nor think to scroll down to search for it) and you see a lot of “connection lost trying again in 1000ms” so the line with information about “try UDP” is not really visible as it is lost in backlog.

But as you are aware that you try TCP on purpose (and your reason to try it is good) whenever the camera tell you to use UDP, may be a better option would be to try TCP first but if it fails go to UDP automatically and if it is a success then change/save automatically the settings to RTSP_UDP.

By the way, talking about event logs, in the log files you write the type of information level before the timestamp, this is unusual and make it difficult to read, you may start with timestamp (and this closer to the “standard” way of writting log files) also whenever you do one file per day it’s always easier to see a full date/time especially when you need to “grep” into multiple days logs.

regards.


#5

Well normally your read the logs from NCS UI where they are presented in a better way. Log files are usually for deeper investigations already.

As for these decision of which mode first and how to handle it’s always complicated when you have to support thousands of different models. Having perfect support for a specific model is usually easy but coming by default in what will be the most common and what makes sense for most users is where it becomes tricky.

Yes it’s probably possible to improve that however the idea is that the user configures it correctly once and then it’s ok. The fact of testing first one then switching will then occur at every reconnection / waking up of the source if it’s not somehow set / defined in the settings during the setup…

The fact that ONVIF was by default setting UDP for most cameras (incl. these supporting TCP) resulted in artefacts and decoding issues for several users this is why if UDP has to be used we prefer that the user takes an action/decision and that it’s not NCS having to take this one on its own…


#6

No[quote=“Steve, post:5, topic:1862”]
The fact of testing first one then switching will then occur at every reconnection / waking up of the source
[/quote]

I am not talking about doing this TCP vs UDP test at each camera startup/reconnection but only when user add the camera.

As I said the message about “try UDP” in event log console viewer has been lost among many other events so I did not notice it at all (and did not need it as I am aware about all those IP cam and network protocols things and being developper help a lot too) but I guess other users may miss it too and may get lost because of it.

But of course all what I write are only ideas I have in mind and want to share and you decide to follow or not… you’re the boss on this project anyway :wink:


#7

And that’s a bit my problem here. Nothing is actually being tested at this stage. It’s then at much lower level of the software where we actually try to connect the camera that we can see if it works or not. This part is not aware of the settings and cannot change them (it’s actually not even the same programming language). Of course it’s always possible but quite complex to put in place and why i didnt do it so far.

Maybe one day but it will require some effort to achieve.


#8

By the way which languages do you use with NetcamStudio ? C#, C, C++, Delphi (well not Delphi… too old laguage but so cool, I used for years and still use it time to time when I need to do quick development or high usage low level TCP/UDP network stuff ) ? I also suppose you use Third Party libraries/modules like ffmpeg as DLL or do you compile it for your own integration ?


#9

75% is c# but lower level parts interracting with ffmpeg and opencv are in c++.

webcamXP and webcam 7 are mainly in delphi apart the parts they share with netcam studio which are in c++.


#10

You still use Delphi :slight_smile: I kept Delphi 7 as they killed the product after this version adding tons of features making IDE unsuable :frowning: but Lazarus is still interesting but today it’s easier to go for Visual Studio to do C#/C++


#11

I survived until Delphi 2010 but i agree they killed the product. This is one of the reason why i somehow had to give up and started NCS in 2012…