dadreamer

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.

Just save and look at it. It's just for a one-time test anyway, so doesn't matters which moment you're capturing on your camera. You don't need that inner "2" Case Structure, remove it.

1 hour ago, alvise said:

What I can briefly explain is that if I set it in the UI thread, I can run unsafe DLLs. But if I run it as "Any thread", I will run it in the unsuitable thread. This can cause problems

I doubt there would be problems. Rolf already has set the CLFNs in his HikVision examples to any thread, so I could conclude that those functions are reenterant (thread-safe). Of course, it must be clarified with the documentation from the developer, but I accepted it on faith. 🙂

Moreover, you should move your GetJPEG call to a parallel loop as it's blocking your callback event frame, not letting it to process another events. Hence you see freezes of the GUI. Or limit the event queue in the Event Structure settings. Or use Flush Event Queue as suggested.

1 hour ago, alvise said:

or is it just one image? I guess not.

It is. Why do you think otherwise?

11 minutes ago, alvise said:

I'm struggling with how to save it as a jpeg.

What's your issue? Just write the array into a binary file with a ".jpg" extension exactly one time and you're done.

But if GetJPEG call is blocking, you don't have any other ways except implementing PlayM4 callback in the C code.

4 minutes ago, alvise said:

Should I select all function nodes as Any thread?

46 minutes ago, dadreamer said:

What if you switch all the HikVision and PlayM4 CLFNs from UI thread to any thread (yellow coloring)?

5 minutes ago, alvise said:

Everything to UI thread

To any thread. They should become yellow. But yes, you have a way too much events queued!

Re-read my previous message. And maybe you have a large bunch of events in the queue? Check with the Event Inspector.

1 hour ago, alvise said:

Do you have any suggestions for finding the array size?

Only those stated in the documentation.

Quote

pJpeg [in] Address assigned by users for storing JPEG data, no less then jpeg file size: suggested w * h * 3/2, in which w and h stand for the width and height of the image.

This is the minimum size required. But it may occur that this size is not enough - this needs some testing on your side. If you would use BMP, then there's a more or less precise formula, but BMPs are quite larger in size, as you know.

Also I, as Rolf did few posts ago, suggest using PlayM4_GetPictureSize function to know the actual image size. Insert it between InputData and GetJPEG nodes.

2 hours ago, alvise said:

I can't close the VI unless the array is already finished with the specified size. labVIEW freezes.

Are you saying that those GetJPEG/GetBMP functions are synchronous and don't return until the buffer is filled? What if you switch all the HikVision and PlayM4 CLFNs from UI thread to any thread (yellow coloring)? Then it would run in another thread and not freeze the GUI.

Well, I see from your data that you're finally getting a valid JPEG stream. Can you save that pJpeg array into a binary file and open it in a viewer? Just to make sure it's the cam image. And now you need to figure out the proper array size so the GetJPEG function wouldn't error on you anymore. And in your "Stop" frame you should accomplish the cleanup procedures such as stopping the playback, freeing the port etc. Just find the opposite functions according to your UserEvent frame calls.

1 hour ago, alvise said:

if i add the number ''20130528'' here

It's date when pzj coder added that define to the header.

1 hour ago, alvise said:

I get an output like below but it's just outputting an image

What do you mean?..

@alvise Based on what Rolf said try to run this VI and report the PlayM4_GetJPEG Error Number.

Preview CAM.vi

3 minutes ago, Rolf Kalbermatter said:

I think you have to use the PlayM4_GetPictureSize() to calculate a reasonably large buffer and allocate that and pass it directly to the PlayM4_GetJPEG() function to MAYBE make it work.

He already tried to allocate a huge buffer of 3000000 bytes. This buffer is definitely large enough to hold not only a single JPEG content, but even a several BMP ones. But this doesn't work as well.