dadreamer

Generally I agree with Rolf here. That ArrayMemInfo node even though looks neat and easy-to-use could easily be removed in the future versions of LabVIEW as it's for internal use only. NI has already removed many undocumented or obsoleted stuff from the core of LV 2022, including all the NXG helper functions like that NCGGetOperateDataPointer. If it goes to production, I'd prefer conventional Memory Manager functions like DSNewPtr and friends.

1 hour ago, X___ said:

Refer to the LabVIEW Help, accessible by selecting Help»LabVIEW Help from LabVIEW, for information about LabVIEW 2022 Q3.

Selecting this context menu entry opens the browser and displays this page. No more built-in help?.. If so, I assume they didn't fill all the documents yet.

2022 Q3 is already available for download from NI website. All the three OS'es are in place and the Community edition too. Not touching the subscription issues, nobody stops me from using a trial and during that time I could specify "2022" in my profile 🙂

What about 2022? I suppose expect it being out soon. I've seen some guys are using 2022 Beta meantime.

1 hour ago, Bruniii said:

The real problem is that the following Matlab code, running on the same file, has no problem and the converted array is as expected:

Why do you use Read from Text File VI instead of Read from Binary File VI?

Read from Text File VI does End-Of-Line chars conversion by default. It could be disabled in the RMB context menu of the node.

13 hours ago, Rolf Kalbermatter said:

To turn them into interpreting a byte stream array, will be some work.

Windows Imaging Component already has native bitmap decoder for BMP format, that works "out-of-box". So why reinvent all that from the scratch? Of course, there would be a reason, if we were on Linux or macOS. As it's about Windows only, then the WinAPI decoder should be already optimized to process the formats fast enough. I doubt it would be worse in performance than the LabVIEW built-in instruments.

On 6/12/2022 at 6:38 AM, Rolf Kalbermatter said:

Well, how many times per second do you call that VI?

It was a project with MOXA video server, that was digitalizing an analog video signal and outputting it each 25 to 30 frames per second. That SDK was providing only a JPEG stream, hence I had to use some helper decoder of mine. Later we switched to another video server, that was able to output in many other formats besides, including a RTSP one.

On 6/12/2022 at 6:38 AM, Rolf Kalbermatter said:

And make that VI subroutine.

There exists one more way to make the CLFNs run in the same thread and stay in 'any thread' all the time. I recall that I was having some thread unsafe DLL, that I wanted to use in my project, but I absolutely didn't want it to run in UI thread. Then I used Timed Loop for that and it worked like a charm.

Quote

Each timed structure on the block diagram creates and runs in its own execution system that contains a single thread, so no parallel tasks can occur. A Timed Loop executes in the data flow of a block diagram ahead of any VI not configured to run at a time-critical priority.

But I have never dug those built-in XNodes deep enough to see, how they work internally.

On 6/12/2022 at 2:34 PM, alvise said:

it still seems to have something to do with "CoUnitialize" because If I uninstall Win32 Decode Img Stream.vi this problem won't occur.

Remove this and try again.

I think, if your memory stays on nearly the same level (say, 180 MB) for a few hours and does not jump high drastically, then no need to worry.

For this you would need to:

- change the type of the user event in two locations: on the diagram and in the callback code;

- slightly change the callback logic, trying some things: first try to post the cluster with the data handle address instead of the array, second try to not allocate the array and copy the data into it, but post the original SDK pointer to LV directly. Plus in fact we even don't decode the data ourselves - the PlayM4 decoder does it for us! As we need the data type mostly and don't need the actual data contents, we could ease the callback logic a little.

But I neither want to say you to do this right now, nor I'm inclined to do this myself. I think Rolf is going to come with more advanced diagnostics or solutions.

Actually I would try to eliminate one handle allocation by passing a pointer with PostLVUserEvent and dereferencing it in LabVIEW (+ deallocate it manually, of course) (as I already mentioned on the first pages of this thread). It would be more of a test to see if the large memory consumption goes away. If not, then it's reasonable to allocate the space just one time (when the DLL is loaded, for example, or right on the diagram with DSNewPtr) and free it when the app ends (when the DLL is unloaded or with DSDisposePtr on the diagram).

Win32 Decode Img Stream.vi does not produce memory leaks of any sort. I've been running it on a production for months. Never ever received errors from that VI. As to CoInitializeEx, it was implemented this way in the original thread on SO, I just borrowed the solution. But I checked now, CoInitializeEx always returns TRUE, no matter what. Extra resources are not allocated. I assume it's safe enough to call it multiple times from the same thread. But you may easily add CoUninitialize to there, if you're afraid it works improperly. I'm just thinking this might be not a good idea, given that description of the function:

Quote

Closes the COM library on the current thread, unloads all DLLs loaded by the thread, frees any other resources that the thread maintains, and forces all RPC connections on the thread to close.

A lot of work would be done on each call. Better to do this once on the app exit. Or leave it to the OS, when LabVIEW quits.

Does it get to 1GB after running for 1 hour?

5 minutes ago, alvise said:

Is there any possibility that the callback dll is causing this?

You may relatively easy check this. Make a test VI and remove there everything related to the PlayM4 decoder and the image conversion. Leave the User Event completely empty. Get the memory space measurements during the run of that VI.

Yeah, something is not freed properly and eating your resources. You need to find what it is.

12 minutes ago, alvise said:

By search order error do you mean "playM4.dll" or for any language?

I'm afraid you need to check and test everything. By the way. Do you see a memory leak in Windows Task Manager when running the app for a long time? Compare the occupied memory space, when you've just started the stream, with that one after a hour.

14 minutes ago, alvise said:

I get this error if ''JpegSize'' reaches over 9000.

You mean GetJPEG returning 0? If that occurs on the recent version of your VI, then it might be that when the image is very large, it takes too much time to process the data, and your LV User Event doesn't have a chance to handle it all in time. You need to view the Event Inspector and watch the amount of events in there.

1 hour ago, alvise said:

it happens like this, what could be the reason?

Very hard to tell. You need to check the functions return values one by one, and not only in LabVIEW, but in the DLL as well. Use DbgPrintf window to ease the debugging. To me it seems more like a call sequence mistake of some sort. But it may be resource leaking too, as if for example you'd forget to close some handle or free some pointer.

Better now. I would move that Stop, CloseStream and FreePort stuff to the main loop (to "stop" frame), but it's your decision.

1 hour ago, alvise said:

I think this application alone consumes 35-40% CPU. Is this normal? Or is there an error?

Not that normal for sure. Usually such a video translation takes about 10 to 15 percent of CPU load. I suggest to try:

- increase the loop delay from 10 to 50 ms;

- as you know, that your image size is constant (1280x720), eliminate the GetPictureSize CLFN completely and move the Initialize Array node outside the loop.

Something like that, but...

- Why all your CLFNs are orange again?

- You did not introduce a minimum delay for the loop.

- Better to use some button, pressing which you would capture the image. So you would need a Case Structure or an Event Structure in that second loop to handle the button actions.

1 hour ago, alvise said:

What am I missing here?

You should have moved only PlayM4_GetPictureSize and PlayM4_GetJPEG to a parallel loop. The other functions should remain as they are, i.e. in the callback event frame. Now as you moved everything PlayM4 related and did not introduce a minimum delay for the loop, your While loop runs with a very high frequency, not only hogging up the system resources, but also executing few unnecessary runs for one User Event! To clarify, in each callback event you need to call InputData once, but you call it one, two, three times in a row or even more!

4 minutes ago, alvise said:

saving to an image file and reading from the image file may cause some slowdown. What can be done as an alternative to this?

Yes, that is why it was an one-time test. Remove all that file writing stuff and add the Decode Image Stream VI instead. It will decode the stream in memory.

4 minutes ago, alvise said:

But I still don't understand how you solved this photo.

Obviously I just deleted first 4 bytes from the file as you forgot to connect the boolean constant and the VI was adding an extra integer of the array size to the beginning of the file. Plus it's known how the JPEG header starts, so it's relatively easy to find its first bytes in almost any file.

6 minutes ago, alvise said:

I have to use the method here, right?

You may stick with that Decode Image Stream VI, if you prefer JPEG format.

33 minutes ago, alvise said:

how did you do this?

Look at the Write to Binary File VI more closely.

You forgot something.

I meant that testt.jpg .............

Can you zip it? The forum tries to handle it in its own way.