background:
I used to be a video surveillance client for many years. For a while, I connected to Dahua, Hikvision, axis, Yichuan and other SDKs, and used them in our own surveillance system.
This was a problem ten years ago. When Dahua sdk was used, there were problems such as speed control, reverse playback, slow exit, positioning control, and stopping the playback screen. It was recorded at that time (2012).
I tested it and there are a few problems
1. Check whether the speed control can be performed through the interface, and it shows that it is not possible, but it can be fast forwarded
void CDevMng::CheckSpeedCtrl()
{
LONG LoginId = GetLoginId();
if(0 == LoginId)return;
#if 0
DH_DEV_ENABLE_INFO stuEnableInfo = {0};
int nRetLen = 0;
BOOL bRet = CLIENT_QuerySystemInfo(LoginId, ABILITY_DEVALL_INFO, (char*)&stuEnableInfo, sizeof(DH_DEV_ENABLE_INFO), &nRetLen);
if (!bRet)return;
if(stuEnableInfo.IsFucEnable[EN_PLAYBACK_SPEED_CTRL] != 0)
{
if(m_pDevReplay)
{
m_pDevReplay->m_bSpeedCtrl = TRUE;
}
}
else
{
::MessageBox(NULL,_T("cannot control speed!"), _T("Prompt"),MB_OK);
}
#endif
m_pDevReplay->m_bSpeedCtrl = TRUE; //The query interface shows that the speed control is not allowed, and now the default is enabled.
}
The frame rate can be set using CLIENT_SetFramePlayBack, which is successful
BOOL bRet = CLIENT_SetFramePlayBack(m_lPlayBack, nRate);
did not use
CLIENT_FastPlayBack, CLIENT_SlowPlayBack, CLIENT_NormalPlayBack
Reply
This interface is only supported by specific models.
Please use with caution the interfaces that are not reflected in the remote demo
2. Set the playback direction to reverse, but it is invalid, and there is no example to test whether it can be reversed.
Call
BOOL bRet = CLIENT_PlayBackControlDirection(m_lPlayBack,TRUE);
then call
BOOL bRet = CLIENT_SetFramePlayBack(m_lPlayBack,25);
or
BOOL bRet = CLIENT_NormalPlayBack(m_lPlayBack);
BOOL bRet = CLIENT_FastPlayBack(m_lPlayBack);
the result is invalid
Reply:
Only specific devices and specific SDK programs support reverse playback,
as long as it is not customized, it does not support reverse playback
The interface does not provide 3x speed playback.
Do the implementation by yourself, do the display by yourself, after calling back the code stream, send it to the playback library for decoding, you can control the decoding speed by yourself, and decode the YUV to refresh the screen by yourself
3. When the program exits, 4 threads in Dahua dhplay.dll exit slowly, but this problem does not exist when the sample program exits.
I don't know what interface needs to be called to exit? CLIENT_Cleanup(); The function has been called.
The sample program of sdk exits very quickly. There are 4 threads that time out and exit.
The playback window in the example program is a picture ctrl, but what I use in my program is an atlcom window.
Main thread blocked
ntdll.dll!76e47094()
[frame below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
ntdll.dll!76e46a24()
KernelBase.dll!74f5179c()
KernelBase.dll!74f5c31c( )
kernel32.dll!76a4baf3()
kernel32.dll!76a4baa2()
dhplay.dll!01fa0deb()
dhplay.dll!01fa009c()
dhplay.dll!01fc66de()
dhplay.dll!01fc6681()
dhplay.dll!01fc6545()
dhplay.dll!01fc65dd()
ntdll.dll!76e58968()
ntdll.dll!76e22708()
ntdll.dll!76e226e7()
ntdll.dll!76e5c8b8()
KernelBase.dll!74f588bc()
ole32.dll!7584c12b()
ole3 .dll!7584c1e1()
ole32.dll!7584c1f5()
ole32.dll!7585b749()
ole32.dll!7585b68f()
ole32.dll!758a0ccb()
> TestPlayer.exe!AfxOleTerm(int bJustRevoke=0) Line 123 C++ //::OleUninitialize() ;
TestPlayer.exe!AfxOleTermOrFreeLib(int bTerm=1, int bJustRevoke=0) line 138 C++
TestPlayer.exe!AfxWinTerm() line 47 C++
other threads
> ntdll.dll!76e47094()
[frame below may be incorrect and/ or missing, no symbols loaded for ntdll.dll]
ntdll.dll!76e46a04()
KernelBase.dll!74f569dc()
kernel32.dll!76a4bc8e
() kernel32.dll!76a4bcfc()
dhplay.dll!01fa0b4a()
kernel32.dll! 76a53c45()
ntdll.dll!76e6377b()
ntdll.dll!76e6374e()
The performance is that the thread returns -1, which should be a forced termination of the thread.
Thread 'Win32 thread' (0x17c0) has exited with return value -1 (0xffffffff).
Thread 'memcmp' (0xea8) has exited with return value -1 (0xffffffff).
Thread 'Win32 Thread' (0x12f0) has exited with return value -1 (0xffffffff).
Thread 'Win32 thread' (0xd18) has exited with return value -1 (0xffffffff).
Call these interfaces in turn
m_bInitOK = CLIENT_Init(DisConnectFunc, (DWORD)this);
LIENT_Login(pchDVRIP,wDVRPort,pchUserName,pchPassword,&deviceInfo,&err);
DWORD dwError = CLIENT_GetLastError();
Ret = CLIENT_RealPlay(LoginID,nChannel,m_hWndDisp);/ /Play video directly
CLIENT_SetRealDataCallBackEx(lRet, RealDataCallBackEx, (DWORD)this, 0x1f);
bRealPlay = CLIENT_StopRealPlay(m_DispHandle);First close CLIENT_RealPlay
BOOL bSuccess = CLIENT_Logout(m_pDevMng->GetLoginId());
CLIENT_Cleanup();
When exiting, some threads need to time out to exit
. I installed perl before, but found that the sdk interface could not be called successfully after installation, and then uninstalled it.
Does this have an effect?
What does the reply
CLIENT_SetRealDataCallBackEx callback do? If you look at the callback, can we quickly release
our demo without delayed release?
Edge (9611153) 10:40:20
is the same, and I used the wrong ip, user name, password, and there was a delay when logging out.
I packaged this sdk into atlcom, the player's window is the interface of atl, and then use the CreateControl method to create the window, and place it in a large activex window. It's not directly placed in the mfc. I don't know if you have tested this situation.
4. Problems with playback control
[5616] CDevReplay::PlayBackByTime nChannelId=0 StartTime=(2012/10/10 13:00:00) StopTime=(2012/10/10 13:27:25)
[5616] CDevReplay::GetCurTime CurOsdTime=(2012/ 10/10 13:22:32)
Call the playback interface CLIENT_PlayBackByTimeEx, and start playing from 2012/10/10 13:00:00,
but the current time obtained by calling the CLIENT_GetPlayBackOsdTime interface is from 2012/10/10 13:22:32.
Not sure why?
But you can use the CLIENT_SeekPlayBack function to manually locate the position between 2012/10/10 13:00:00 and 2012/10/10 13:22:32, and the time on the screen can be seen, for example, it shows 13:12:12.
5. Positioning problem
There is no problem with the normal playback of Dahua video files, but there is a problem with positioning. Either the progress returned is incorrect, or the returned data is incorrect.
Play by time: From 2012/10/10 14:00:00 to 15:00, when the location reaches 14:40, the data obtained by calling PlayCallBack at the time point of 14:10 is
played by file: the file size is 400000B, When the location reaches 300000B, the video will play the data at 100000B.
6. Screen stay problem
The Dahua sdk plays, and the image remains after the playback is stopped, and the window is not refreshed.
about:
qq : 9611153 Wechat lgs9611153