DelphiUdIT

You can use the System.Diagnostic unit, and the TStopWatch for high precision timing. With that you can "timing" every line of your code (of course if the code is blocking). If you use not blocking code the free method is recording all the "Windows messages" in that time (10 seconds) and analyze the events timing. For those who are old enough, they will surely remember WinSight. I never used tools other the TStopWatch, with this i resolved all the issues.

Hallo to all, since 10.4 (and 10.4.1) debugging c++ DLL for x64 Windows S.O. is impossible (for me of course). ALL THE PROJECTS ARE COMPILED FOR X64. If I launch standard debug from Delphi project, the DLL source code (made in c++) is ignored and no breakpoints are used in the DLL. If I launch LLDB debug from c++ DLL (setting the correct host of course), an error like this is generated and the app doesn't start. If you launch the app with or without Delphi debugger all is working. Same situation with remote debugger (via "old style debugger" or paserver). Before LLVM all is working and i can debug DLL c++ code. I miss something or do something wrong ? Attached is a very simple project group to test. Thanks for your attention. Test.zip

Reported, https://quality.embarcadero.com/browse/RSP-30893

LOL … That is really strange: hoping that it's only my problem. I will insert a ISSUE in QP as soon as possible.

I strongly doubt that the eventual problem is due to a "logic" error linked to multithreading, because normally this would generate exceptions with memory access errors recorded in the Windows system log. Many years ago I also made the mistake of calling CoInitialezeEx without CoUninitialize and there were several problems especially when closing the application. Since then I ALWAYS use the CoInitializeEx (nil, COINIT_MULTITHREADED) at the beginning of the threading EXECUTE method (not in the while block, of course) and the CoUninitialize at the end of EXECUTE (when the thread terminates. Obviously, ONLY within the EXECUTE method (or in the methods subsequently called by it) will it be possible to access the OLE / ACTIVEX resources for that thread.

Hallo, I have tried to create a "standard" component using RFC guidelines, but this fails to overcome the different interpretation of the standard (tag, CRC, UDP or TCP, hidden channels, video compressor, ...) that the manufacturers of cameras and video recorders (speaking of video surveillance) have then applied on their products. I have not found anything better than VLC (I use PASLIB VLC as a wrapper) for the general use of RTSP. I hope you find something better and independent. Report it if you find it.