Jump to content


  • Posts

  • Joined

  • Last visited


LabVIEW Information

  • Version
    LabVIEW 2018
  • Since

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

alvise's Achievements


Collaborator (7/14)

  • One Month Later
  • Reacting Well Rare
  • Week One Done
  • Dedicated Rare
  • Collaborator Rare

Recent Badges



  1. Without buttons, I want the video to be displayed directly when the VI is run. I tried several methods to use the event structure without the button, but in a way that I can't understand, the video capture speed drops. But in general, in the method I currently use, the frame capture rate decreases over time. I have assigned a Numeric indicator for each event frame and I assign values to the indicators with Value sign, this way I start the Frames one after the other. It's not much problem when it works first time, after a while I notice that the video flow starts to seem slow. Does this occur due to the accumulation of undesirable events? The example I'm using right now is the example here, only the flat sequence plugin in the picture was made. Does anyone have an idea what is wrong with this code?
  2. Thanks for your answer. -I think you created something similar in the example you posted before. But it was just necessary to decode the extra compressed images, right? -Currently, there are 2 kinds of image output formats in the camera's own settings, one is JPEG and the other is BMP, the desired output format can be selected. And as an extra, H.264 or MPEG4 video output can be selected. I tested both separately and the video can be read. Of course, I don't know what is in the background here. Does it really decode H.264 data or does it still receive data in MPEG4 format even though I choose H.264 video output format? I don't know.I tested it with a different camera. It only works with a camera with an H.264 output format. -To be honest, I don't know if I can work harder right now.I guess it will still require a lot of effort.Maybe there will be people who can add to it in the future And I don't want to bother you any more. You and dadreamer have been very helpful so far, thanks for your help, this example we created will probably help other people as well. It was nice to know that precious people like you still exist. -The last thing I want to do (using my last energy for this job) is to create an example instead of buttons that are displayed when the VI is run directly and can be turned off when the Windows shutdown button is pressed.
  3. Thanks for your answer. Actually I was able to get the stream using GetBMP function and even view it with "Win32 Decoder Img Stream.vi" with NI IMAQ but I don't think that is the right way. -What should be done to decode video stream information with ''GetBmp'' instead of ''GetJpeg'' function directly? - In the example you shared, I couldn't get a video stream from the example that uses the "GetPlayedFrames" function. I tried to fix the problem but couldn't find the source.
  4. I did what you said above, but I couldn't get any results. Therefore, I used it with the first state. Finally, the sample project I created is as follows. memory usage increases over time, but not that fast and not that much (0.1MB). I tested this increased memory usage in the sample application shared with the SDK and it was also increasing the memory usage in that example.The sudden changing memory usage does not occur much in the method I use below. However, it increases by 3-5 MB from time to time and returns to normal. This way If I read video in 1280x720 resolution it is using 13% CPU. Hikvision-labviewSDK-Test-v1.1.4.rar
  5. in an interesting way.When I run the "Preview Demo" example built with C# that comes with the SDK, it seems to increase memory usage, is this normal? In the example we created in Labview, it is seen that the memory increase observed over time is the same as in the example created with C#. This seems to explain the reason for the increase in memory usage. by the way,It seems harmless but I want to understand why it still seems to have something to do with "CoUnitialize" because If I uninstall Win32 Decode Img Stream.vi this problem won't occur.
  6. I removed the lines that you said have a problem and compiled it again, #define LibAPI(retval) __declspec(dllexport) EXTERNC retval __cdecl #define Callback(retval) __declspec(dllexport) EXTERNC retval __stdcall #include "lv_prolog.h" typedef struct { int32_t size; uint8_t elm[1]; } LVByteArrayRec, * LVByteArrayPtr, ** LVByteArrayHdl;// ** LVByteArrayHdl;pointer to a pointer typedef struct { LONG realHandle; DWORD dataType; LVByteArrayHdl handle; } LVEventData; #include "lv_epilog.h" extern "C" __declspec(dllexport) void __cdecl SetCbState(LVBoolean * state); // where Standard Boolean type case is set: typedef uInt8 LVBoolean LVBoolean cbState = LVBooleanFalse; // always set to false on startup extern "C" __declspec(dllexport) void __cdecl SetCbState(LVBoolean * state) { cbState = *state; } extern "C" __declspec(dllexport) void __stdcall DataCallBack(LONG lRealHandle, DWORD dwDataType, BYTE * pBuffer, DWORD dwBufSize, DWORD dwUser) { if (cbState == LVBooleanTrue || dwDataType == 1 ) { if (dwDataType == 1) { DbgPrintf("NET_DVR_SYSHEAD received-test 1"); } LVEventData eventData = { 0 }; MgErr err = NumericArrayResize(uB, 1, (UHandle*)&(eventData.handle), dwBufSize); if (!err)// send callback data if there is no error and the cbstatus is true. { LVUserEventRef userEvent = (LVUserEventRef)dwUser; MoveBlock(pBuffer, (*(eventData.handle))->elm, dwBufSize); (*(eventData.handle))->size = (int32_t)dwBufSize; eventData.realHandle = lRealHandle; eventData.dataType = dwDataType; PostLVUserEvent(userEvent, &eventData); DSDisposeHandle(eventData.handle); } } } //If the above if condition does not occur, the LVUserEventRef here does not take a value. typedef BOOL(__stdcall* Type_SetStandardDataCallBack)(LONG lRealHandle, void(CALLBACK* fRealDataCallBack) (LONG lRealHandle, DWORD dwDataType, BYTE* pBuffer, DWORD dwBufSize, DWORD dwUser), DWORD dwUser); extern "C" __declspec(dllexport) MgErr __cdecl InstallStandardCallback(LONG lRealHandle, LVUserEventRef * refnum) { HMODULE hDLL = LoadLibraryW(L"HCNetSDK.dll"); if (hDLL) { Type_SetStandardDataCallBack installFunc = (Type_SetStandardDataCallBack)GetProcAddress(hDLL, "NET_DVR_SetRealDataCallBack"); if (installFunc) { BOOL retval; if (refnum && *refnum) retval = installFunc(lRealHandle, DataCallBack, (DWORD)(*refnum)); else retval = installFunc(lRealHandle, NULL, 0); if (retval) return mgNoErr; else return 5000 + NET_DVR_GetLastError(); } FreeLibrary(hDLL); } return mgNotSupported; } I think the problem is solved. Currently, memory usage has remained stable. Exiting VI releases used memory. It has a memory usage and CPU usage as follows. But; When running -VI, memory usage sometimes goes up and down. For example: 178.3MB to 182.3MB then be 178.3MB again. -I still think it's a slight memory leak because memory usage is increasing albeit very slowly. Example: By the way, I tested again by removing PlayM4 and Win32 Decode Img Stream.vi. Again, there are small leaks as in the picture above.
  7. I guess I'll go step by step again. -In the example we created in C++, we will export a pointer as an export function with PostLVUserEvent and re-reference it in lab view with CFLN in lab view. Is it true so far?
  8. actually I don't think the problem is in "Win32 Decode Img Stream.vi" because as you can see in the pictures I shared before, I completely removed it and observed the memory usage, nothing changed.memory usage continued to increase.
  9. By the way, you mentioned CoInitializE(), but when I remove Decode Image Stream VI, there is no change in memory usage, which increases over time, so it still increases. -How do we eliminate all CoInitialize work by returning BMP? Why does returning BMP have such an advantage? -Does taking it as BMP also cause a drop in camera FPS? As far as I know, BMP is bigger in size. By the way, I tried to find the source of the problem in the example you edited earlier (which takes the video as BMP), but I couldn't find the source of the problem.
  10. Yes just the callback does not cause a memory leak per se it is not a memory leak that is happening right now. So how can we solve this problem, is there a solution to it?
  11. Currently, when I run the VI, the memory consumption remains the same as when I close the VI. I guess the memory space used is not freed when the VI is shut down. Currently I have a problem like this when trying to read images from a single camera and I was intending to run 2 cameras That's what I think too, something I shouldn't do on my own because it can cause new memory leak issues, but it can also cause other issues (like RAM burnt out). -So if you tell me what to do step by step to solve this problem, I think I can handle it.
  12. The memory usage observed after 40 minute in the photo below. This app used PlayM4 decoder and the image conversion In this application, the dll used for callback is not used, only the video is taken from the picturebox. In this application, callback is used but PlayM4.dll is not used.
  13. As you said, I removed everything used in the "LVEventData" framework, as in the picture below, but again, increasing memory usage is observed.
  14. By the way, while the application is running, the memory usage is increasing. If I stop the application, the memory used by the labview remains the same as when I closed the application. If I run the application again, it continues to increase the memory usage from where it left off. Is there any possibility that the callback dll is causing this? We are not overwriting the labview data, are we, because if I close and open the labview completely, the memory usage returns to normal.
  15. I guess it's a memory leak. The memory usage used when the problem came out is as follows, which I viewed in the task manager.when I run the app again. When I restart Labview, the memory usage is displayed in the task manager as follows.when I run the app again. Meanwhile, the memory usage is increasing while the application is running.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.