dadreamer

11 minutes ago, Łukasz said:

It also works. The service can be started and stopped. However, the stop function wasn’t defined so Linux sent KillSignal and the application was killed. I think it's not safe, I don't know what happened with all those open references etc. but I’m sure that I don't have any log from the application. So the first question is how to send the signal/message to the LabVIEW app? There is a possibility to specify the execution file which will be triggered on service stop, so this can be used.

From my very limited experiments with a common app (not a service), the OS kills it no matter what, leaving no chance to do even some basic cleanup. You may browse through this idea and comments: Notification in Event Structure When Linux is Shuting down Sadly all the attachments there are long gone and I didn't succeed in finding their copies. But even if you would implement that workaround in your application, I highly doubt it would allow to interrupt the shutdown process to do some work in the application as it's provided by modern Windows or Mac OS.

"IMKH" FourCC says it's MPEG-PS format. Most decoders should recognize it. Now you can build some logic around PlayCtrl.dll or any other decoder such as ffmpeg.

Use that HikVision example and Windows Player SDK Programmer Manual to implement the decoder calls.

It was obvious. Strange that we couldn't get to it so long. I think the easiest way would be to alter the callback condition like this.

if (cbState == LVBooleanTrue || dwDataType == 1)
{
}

In this case the NET_DVR_SYSHEAD packet will be posted regardless of the state of cbState button. You should receive it right after starting the playback.

22 minutes ago, alvise said:

There is a dll file like below, isn't there a shorter way to get video stream information using it?

Yes, PlayM4 headers appear to be a C wrapper around that DLL. So it could be called even from the Event Structure, thus no C code modifications needed. But you need to receive NET_DVR_SYSHEAD in LabVIEW somehow, because it sends a MPEG-4 header, based on which the stream gets decoded later. So you need to figure out what happens in NET_DVR_SYSHEAD case in your DLL and why the event is not posted.

So, try to move that DbgPrintf condition to the if (cbState == LVBooleanTrue) {...} and check this. Then if it's called OK, after NumericArrayResize add something like this:

if (dwDataType==1) DbgPrintf("NumericArrayResize returned %d", err);

Check this then. And so on. Keep debugging until you find something.

4 hours ago, alvise said:

Isn't that a problem?

If you're planning to implement PlayM4 API in your code, then yes. You won't be able to get NET_DVR_SYSHEAD called. But I don't know why it suddenly stopped working on your side. Maybe when you have switched from NET_DVR_SetRealDataCallBack to NET_DVR_SetStandardDataCallBack... You may try switch back just for a test. Or insert something like this into the beginning of your DataCallBack:

if (dwDataType==1) DbgPrintf("NET_DVR_SYSHEAD received");

11 minutes ago, alvise said:

Yes the header file contains these calls but I don't know how to use them in C++ code. I will try to do that.

In order to use them you need to adapt the callback function as shown in their examples:

void CALLBACK g_RealDataCallBack_V30(LONG lRealHandle, DWORD dwDataType, BYTE *pBuffer,DWORD dwBufSize,DWORD dwUser)
{
    HWND hWnd = GetConsoleWindow();

	switch (dwDataType)
	{
	case NET_DVR_SYSHEAD: //系统头

		if (!PlayM4_GetPort(&lPort))  //获取播放库未使用的通道号
		{
			break;
		}
		//m_iPort = lPort; //第一次回调的是系统头，将获取的播放库port号赋值给全局port，下次回调数据时即使用此port号播放
		if (dwBufSize > 0)
		{
			if (!PlayM4_SetStreamOpenMode(lPort, STREAME_REALTIME))  //设置实时流播放模式
			{
				break;
			}

			if (!PlayM4_OpenStream(lPort, pBuffer, dwBufSize, 1024*1024)) //打开流接口
			{
				break;
			}

			if (!PlayM4_Play(lPort, hWnd)) //播放开始
			{
				break;
			}
		}
	case NET_DVR_STREAMDATA:   //码流数据
		if (dwBufSize > 0 && lPort != -1)
		{
			if (!PlayM4_InputData(lPort, pBuffer, dwBufSize))
			{
				break;
			} 
		}
	}
}

But there are a lot of things to be reworked as well.

- You will need to prepare a proper bitmap buffer to have your pixels loaded into.

- You will likely need to replace or complement PlayM4_InputData call with PlayM4_GetBMP / PlayM4_GetJPEG call.

- You will need to remake PostLVUserEvent call and some other functions around it.

3 hours ago, alvise said:

When I make a change like below, it only saves one file, shouldn't it save a new file for each event iteration? Why does it only save one file? Is the method I'm using correct?

- The "1" case is for NET_DVR_SYSHEAD capture, but you assign NET_DVR_STREAMDATA name inside it; the "2" case is for NET_DVR_STREAMDATA capture.

- You have unwired tunnel for blue wire in some frames of the Event Structure. Don't you see that small rect is not painted completely?..

49 minutes ago, alvise said:

Are you saying it's unnecessary to send any value to "dwDataType" like in the photo?

It's senseless! You can input any values in that cluster constant and this changes literally nothing. This constant is only to define the User Event data type and that's all.

51 minutes ago, alvise said:

I'm looking at this sample code as I don't have a solution at the moment. How can we use this sample code to achieve the desired result?

So can you call the functions from the PlayM4 SDK now? You need to find a suitable function to decode the stream and receive a ready-to-use bitmap or pixels array. I don't know exactly which one is okay as I can't find the documentation (but I barely searched, to be honest, because was busy today).

Ok, I found these:

//get bmp or jpeg
PLAYM4_API BOOL __stdcall PlayM4_GetBMP(LONG nPort,PBYTE pBitmap,DWORD nBufSize,DWORD* pBmpSize);
PLAYM4_API BOOL __stdcall PlayM4_GetJPEG(LONG nPort,PBYTE pJpeg,DWORD nBufSize,DWORD* pJpegSize);

Do you have them in your headers?

7 minutes ago, alvise said:

Yes, I'm getting errors like the following.

It's difficult for me to find the errors source from your screenshot.

7 minutes ago, alvise said:

With the method you suggested, it is necessary to stop and restart the VI for each new package.

No. Just replace the filename string constant with your randomised filename and the frame will be recorded to a new file on each event.

10 hours ago, alvise said:

-I'm looking at the example here. I think it is necessary to read the 'NET_DVR_SYSHEAD' package.

Maybe. I've been browsing their samples too. Looks like they use a custom MPEG-4 decoder. In NET_DVR_SYSHEAD case they just initialize the decoder as this is the very first frame. But seems that the actual pBuffer contents of the system header aren't used in any way. Or I'm wrong? Later in NET_DVR_STREAMDATA case they obtain the packets and render them into a separate window using that MP4 decoder. Maybe it would be easier to use it instead of reinventing not only a wheel, but an entire car. Could you try to #include "plaympeg4.h" header to your code and recompile? Do you receive any errors?

10 hours ago, alvise said:

I took a few records as below and created the records with a normal button.

Normal button is not suitable here due to the reasons I explained earlier. You could try to generate a random file name on each packet arrival (say, packet number or current date + time or something else), so the data gets recorded into a new file instead of being written to the same file.

SetCbState returns nothing! Its return value is defined as void. That means that the function does not have a return value at all (in Pascal and Delphi such a function is called procedure). So after you set some return value for it in the CLFN settings, you keep getting some totally unrelated numbers, e.g. return values of some internal functions in LV core or whatever. It's useless to search for some correlations between that fictional return value and dwDataType. And even if there would be some connection (as after you change some constant and LabVIEW recompiles all and it affects the memory layout in some 'unusual' way), it's of no use absolutely.

6 hours ago, alvise said:

-I try as follows, but the size of the array does not remain constant, it constantly changes between 0 and 4350

It seems to be more complicated then. Honestly I even don't have an idea how and where to start from. Maybe you could collect several (or more) files with different sizes and upload them?

13 hours ago, alvise said:

I can only capture the ''NET_DVR_STREAM DATA'' packet.

In some of your previous tests you showed that NET_DVR_SYSHEAD arrives first and is followed by a sequence of NET_DVR_STREAM_DATA packets. I can't say now, whether we really need NET_DVR_SYSHEAD to analyse NET_DVR_STREAM_DATA, but it would be useful to have both of them.

13 hours ago, alvise said:

I saved 2 different samples.

There's something strange in those samples.

20 bytes only? Really? Well, very good compression achieved! 🙂 Could you add Array Size node to your handle wire to check its actual size at runtime?

I've thought of something like this.

The way you're showing above you catch several packets at once, because the packets arrive much faster than you do "pressing -> un-pressing" the button.

My assumption is that if you already have MKL Runtime installed (I see that it is so), then your PATH environment variable should contain full path to the \bin\ directory of the MKL parent directory (as stated in mklvars_intel64.bat or mklvars.bat). But I have never compiled DLLs with MKL linking, so you better to ask on some C/C++ forums or stackoverflow or experiment with it on your own.

3 hours ago, alvise said:

I think the problem arises when using "NET_DVR_SetRealDataCallBack" function. Using this 'NET_DVR_SetRealDataCallBack' function fixed the problem.

You mean using NET_DVR_SetRealDataCallBack instead of NET_DVR_SetStandardDataCallBack?

3 hours ago, alvise said:

Data can now be read without any problems.

So could you do this then? We can't go on without looking at the data as nobody except you has that hardware here. Of course, you may figure out the format of the data on your own, if you wish.

29 minutes ago, alvise said:

The problem here has reoccurred, even though I have made no changes

I suppose you did something in either your Visual Studio project settings or in your DLL code... This is odd. Check the library dependencies again. Check if you are on Release build. Clean up / remove the output build folders and rebuild everything from scratch.

BTW NI recommends using Dependencies - An open-source modern Dependency Walker 😉

4 hours ago, JKSH said:

Actually, your earlier screenshot shows https://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html

I know. I followed this phrase.

But it no longer matters after Jim Kring's message.

2 hours ago, alvise said:

I guess 5017= NET_DVR_PARAMETER_ERROR

If you are using the VI posted in your last message with the attachment, then you have made a mistake there.

Why so inattentive? This trait brings nothing good to programming at all.

@alvise Yes, you better to adapt your DLL code as written in order to see the error numbers according to the SDK and no more guess on coffee grounds. I see on your screenshots that "callback start return" is 0 (FALSE), but "callback stop return" is 1 (TRUE). As per the documents FALSE indicates some error and if it occurs when calling NET_DVR_SetStandardDataCallBack it would be good to know the reasons.

By the way here's HCNetSDK Error Codes list online to easily correspond error numbers with their text messages.

3 hours ago, Youssef Menjour said:

are there routines to integrate into my code in order to remove these objections?

In fact your app requires the libraries on the very first level shown in Dependency Walker. The others are needed too, but they are being loaded by their "parent" DLLs, so you don't need to worry about them. Could you collapse that DLL list on the left of the DW, so we could see the first level libraries except sycl.dll and kernel32.dll? Don't look at those red warnings as they are about not finding some libraries, which likely are loaded during the runtime or have delayed loading or could even be absent in the system (as some .NET assemblies) and the app is able to run fine without them. So if only sycl is necessary, then you could either provide the path to it in your PATH environment variable or try to put it near your own DLL and check, whether LabVIEW loads it all without errors.

9 hours ago, KumarB said:

Actually client need the license link to refer in their documents but www.OpenG.org website not opening.

https://www.gnu.org/licenses/gpl-3.0.en.html

There's the license information on almost every OpenG VI's front panel.

7 hours ago, alvise said:

- After pressing the "Run" button, I press the "Stream" button, the data can be read, then I press the "Stop" button and the data flow is stopped. If I press the "Start" button again without pressing the "Exit" button, the data will not be read. I press the stop button again.

Press 'Start" -> press "Stream" -> the data is being read -> un-press "Stream" -> press "Stop" -> again press "Start" -> again press "Stream" -> the data is being NOT read... Is that your order of actions?

By the way, do you know that InstallStandardCallback has return value?

You have set it to void in the CLFN settings, but it should be Numeric -> Signed 32-bit Integer. So let's check that value. Put two indicators on your FP from both InstallStandardCallback calls and watch which values they obtain in "good" and in "bad" case. According to the documentation for NET_DVR_SetStandardDataCallBack TRUE (1) means success, FALSE (0) means failure and NET_DVR_GetLastError should be called to find out the reason behind the error.

Now you're about to debug this everything. It's going to be painful a lot! Because there are dozens of things, which could go wrong. First I would start with debugging the DLL by inserting a debug output (like DbgPrintf call or console cout) after each function, that is able to produce errors. But I'm afraid if we go this route, this thread is going to reach 50 pages, if not more.

10 minutes ago, alvise said:

Finally, this way everything should work properly, right?

Looks pretty much like it should. 🙂

Maybe the reason is that LabVIEW cannot find some DPC++ Runtime library during the DLL load process (sycl.dll for instance or another one). Could you check with Dependency Walker, which libraries are in dependencies of your DLL?