alvise

3 hours ago, ShaunR said:

It solved the symptom, not the problem.

Yes, I think it just solved one symptom. In general, the problem persists. I guess it has an effect on the slow streaming received.

1 hour ago, Rolf Kalbermatter said:

No, the opposite if you have a DLL version 6.1.1.17 or newer. In that case it SHOULD be safe to set all Call Library Nodes for the PlayCtrl.dll functions to reentrant.

I set it as you said. I think you said it's safe for us to choose this as the UI thread. But Only for PlayM4.

48 minutes ago, dadreamer said:

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.

clever reasoning

48 minutes ago, dadreamer said:

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.

 

I was able to read the video now and it was extremely delayed. And the labview started to get heavy again.
I think if I follow your previous suggestion (creating a parallel while loop), I will have solved this problem.(Does really adding all the playM4 calls to a parallel while loop fix the video slowdown and LabVIEW freezing?)

I found.

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

9 minutes ago, dadreamer said:

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

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

30 minutes ago, dadreamer said:

You forgot something.

 

 

I have to use the method here, right?

11 minutes ago, Rolf Kalbermatter said:

The documentation for the Play4M shared library states explicitly that the DLL should be since version 6.0. multithreading safe. Of course that statement can be as true or false as anything but it is probably safe to assume for now that it SHOULD work if we don't do massive multithreading. And since we run pretty much everything actually in our test VI eventu structure it is actually executing very sequentially so the multithreading aspect shouldn't even come into play for now. For a more generic library there would need to be a lot of more testing however. 

Then you say that choosing "UI thread" for "Play4M" and "HCNetSDK.dll" makes more sense for now.

hat did I forget? how did you do this?

 of course

testt.rar

of course.

Hikvision-labviewSDK-Test-v1.0.9.rar

I removed the case structure you told me to remove and nothing is saved in the saved jpg file.

I created something like below, but I don't understand how to save it only once. Because there are numbers of elements that come one after another, constantly changing.how do I know and save only one whole picture is taken.

20 minutes ago, ShaunR said:

You can use the Flush Event Queue if you want it to stop immediately instead of waiting for it to consume all events.

If you are not consuming fast enough then eventually you will run out of memory so this VI can also be used to keep a maximum number of events (or over a time) and drop some if that occurs. That would ensure you never run out of memory and you will notice that you get discontinuities in the video (frames dropped) when it is happening.You can even have a boolean on screen to tell you that frames are being dropped.

Thanks for the answer, as I said above, actually 1280x720 resolution is enough right now and making a correction in this way solved the problem.
-Currently I'm just trying to save a jpeg array as a photo, but I can't find a clear solution. Currently I'm saving the data as binary using a method like below, but I'm struggling with how to save it as a jpeg.

I set the resolution of the camera to 1280x720 and the problem was solved.

I guess this was a problem because the data was too much.

3 hours ago, dadreamer said:

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.

I'm trying to use the method you suggested earlier here but what do I need to do to save it as just one image. or is it just one image? I guess not.

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

rolf:If you set the Cal Library Node to "run in any thread" it will be executed in whatever thread the actual VI happens to execute at that moment. Unless you set the VI or one of its callers to execute explicitly in the UI thread, there is absolutely no chance that the Call Library Node will be executed in the UI thread.

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

19 minutes ago, dadreamer said:

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

.That's exactly what I don't know.

Should I select all function nodes as Any thread?

I read your previous post and set Everything to UI thread. But the problem is not solved. Labview runs slow when I use the event inspector window. But I guess there are too many events in the queue.

I just created and tested something like below, but still, if I press the stream button once and the data starts to be received, when I press the "Stream" button again to stop the data flow, the stream does not stop immediately, but after a certain time it stops and I can stop the VI.

Ok, I will follow what you said step by step.

1 hour ago, dadreamer said:

And now you need to figure out the proper array size so the GetJPEG function wouldn't error on you anymore.

I guess I need to find the correct array size first because if I press the 'Stream' button, the VI ''pJpegSize'' does not allow pressing the 'stop' button until the specified array size is reached. Because the labVIEW becomes heavy.
Therefore, I will try to find the right ''pJpegSize''first.
I created a test with different values to find the array size, either I get error 34 or the problem I mentioned above occurs.
Do you have any suggestions for finding the array size?

12 minutes ago, dadreamer said:

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

What do you mean?..

Yes it's a big number  

The array fills the specified size. I can't close the VI unless the array is already finished with the specified size. labVIEW freezes. But I mean, the numbers don't change and that's why I only treated it as 1 image

What do you think is the real solution here?

20 minutes ago, Rolf Kalbermatter said:

Well 2 means there is no data yet to work with, 34 means PLAYM4_NEED_LARGER_BUFFER. Seems obvious what's the problem here.

How can we solve this?

if i add the number ''20130528'' here
I get an output like below but it's just outputting an image and labVIEW is getting heavy.

1 hour ago, dadreamer said:

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

Returns 2 values.

But if I take a little long to get the stream it returns 34.

22 minutes ago, dadreamer said:

You could try to switch to PlayM4_GetBMP, but I assume it gives nothing new. This is odd that even the last error number is zero.

Yes, interesting things one after the other However, there is such a function here.
But I see that there are many dll files in SDKs. I think there must be an easy way somewhere.

12 minutes ago, Rolf Kalbermatter said:

What has happened to your Google?

https://letmegooglethat.com/?q=BITMAPINFOHEADER

search button is broken

5 minutes ago, dadreamer said:

Doesn't this work also? Do you ever see PlayM4_GetJPEG returning 1 sometimes?

No, it never returns 1.

I tested but got a result like below.