Shulou(Shulou.com)06/03 Report--

1) Demo program\Mfc Category Demo has 04. Remote capture 19. Gun-ball linkage and other functional descriptions

There are two data formats for audio and video

//encoding formats, including audio and video

struct AV_CFG_EncodeFormat

{

AV_int32 nStructSize;

AV_BOOL bAudioEnable; //Audio Enable

AV_int32 nAudioBitRate; //Audio BitRate

CFG_AUDIO_FORMAT emAudioCompression; //Audio compression mode

AV_int32 nAudioDepth; //Audio Sample Depth

AV_int32 nAudioFrequency; //Audio sampling frequency

AV_int32 nAudioMode; //Audio encoding mode

AV_int32 nAudioPack; //Audio Pack Mode, 0-DHAV, 1-PS

AV_BOOL bVideoEnable; //Video Enable

AV_int32 nVideoBitRate; //Video bitrate

CFG_BITRATE_CONTROL emVideoBitRateControl; //stream control mode

CFG_VIDEO_COMPRESSION emVideoCompression; //Video compression mode

AV_int32 nVideoFPS; //video frame rate

AV_int32 nVideoGOP; //Video I frame interval

AV_int32 nVideoWidth; //video width

AV_int32 nVideoHeight; //Video Height

CFG_IMAGE_QUALITY emVideoQuality; //Video Image Quality

AV_int32 nVideoPack; //Video pack mode, 0-DHAV, 1-PS

};

Try to use the following code to set the format of video and audio data to PS, instead of Dahua's private stream protocol, which is temporarily invalid.

NET_ENCODE_VIDEO_PACK_INFO struEnCodeInfo = { 0 };

struEnCodeInfo.dwSize = sizeof(struEnCodeInfo);

//specify the main stream

struEnCodeInfo.emFormatType = EM_FORMAT_MAIN_NORMAL;

//check the current video stream format first

bool bRet = CLIENT_GetConfig(id, NET_EM_CFG_ENCODE_VIDEO_PACK, 1, (void*)&struEnCodeInfo, sizeof(struEnCodeInfo));

DWORD err = 0;

if (! bRet)

{

err = CLIENT_GetLastError()&(0x7fffffff);

}

//Set PS stream format

struEnCodeInfo.emPackType = EM_PACK_PS;

bRet = CLIENT_SetConfig(id, NET_EM_CFG_ENCODE_VIDEO_PACK, 1, (void*)&struEnCodeInfo, sizeof(struEnCodeInfo));

bRet = CLIENT_GetConfig(id, NET_EM_CFG_ENCODE_VIDEO_PACK, 1, (void*)&struEnCodeInfo, sizeof(struEnCodeInfo));

Note: 06. In the encoding configuration example, the encoding of video and audio can be set. At present, PS is set through OnVideoDlgToStu. The corresponding PS header field is not found in packet capture. File analysis needs to be saved.

2) Engineering compilation problems

Question 1)

1>BSWndContainer.obj : error LNK2019: Unresolved external symbol_xMonitorFromWindow@8 in function "int __cdecl GetCurrentScreenMonitorRect(struct HWND__ *,struct tagRECT &)" (? GetCurrentScreenMonitorRect@@YAHPAUHWND__@@AAUtagRect@@@Z)

1>BSWndContainer.obj : error LNK2019: Unresolved external symbol_xGetMonitorInfo@8 in function "int __cdecl GetCurrentScreenMonitorRect(struct HWND__ *,struct tagRECT &)" (? GetCurrentScreenMonitorRect@@YAHPAUHWND__@@AAUtagRect@@@Z)

source code

#include "BSWndContainer.h"

#pragma warning(disable:4706)

//#define COMPILE_MULTIMON_STUBS

#include

#pragma warning(default:4706)

modified

#include "BSWndContainer.h"

#pragma warning(disable:4706)

#define COMPILE_MULTIMIN_STUBS //uncomment

#include

#pragma warning(default:4706)

Question 2)

error C3861: "_Min": Identifier not found

Source Code:

int nMinChannel = _Min(m_ChannelNum, _Min(nNum, MAX_RECORD_CHANNEL));

After modification:

int nMinChannel = min(m_ChannelNum, min(nNum, MAX_RECORD_CHANNEL));

Dahua Private Flow Docking Advantage

1) It takes 1500 ms for Dahua equipment to perform rtsp interaction.

2) SDK private protocol docking takes 600 ms

3) The following is a description of Dahua private video stream

1.2 Analysis of DHFS Video Surveillance Frame Format

Frame is the basic unit of video surveillance data, video surveillance data is composed of many frames according to a certain order, there are many types of frames, and the size of the frame is not fixed, the starting position of each frame does not necessarily only appear in the sector or block The starting address, it can appear in any reasonable physical address range. The video frames in Dahua video surveillance file are composed of H. 264 code stream encapsulated by RTP payload of its self-defined network communication protocol. Dahua video frames are different from general H. 264 encoded video frames, and it encapsulates the original H. 264 video data for many times.

Because each frame of Dahua video contains specific network communication protocol header information and tail information, searching and positioning of video frames can be realized by analyzing the data characteristics of network communication protocol header or tail in frames. After a large number of experiments, it is found that the frame start specific flag is capital letter DHAV, represented as 0x44484156 in hexadecimal, and the frame end flag is lowercase letter dhav, represented as 0x64686176 in hexadecimal (see Figure 1). The header structure of Dahua frame records basic video attribute information, such as frame number, channel number of frame, frame length and frame creation time. These attributes are the key information for channel separation and recombination of video surveillance data, among which attribute information related to video surveillance recovery is shown in Table 1. In the header structure, the frame type is described with an offset of 0x04 relative to DHAV identification; as shown in Figure 1, the channel number is described at an offset of 0x06, and the channel number of this frame is 0x005, which means 6 channels, because the channel number is 0 as the base to represent 1 channel; 0x08 describes the frame number, which is represented as 0x47D0 in hexadecimal considering the size end expression form; 0x0C offset from DHFS is the length of the frame, which is 0x0000F80 in decimal, which is 3698 bytes; 0x10 offset from DHAV is the creation time information describing the frame, which is represented as 0x39308EBB in hexadecimal. As shown in Figure 1, the last four bytes of dhav are the frame length, and the hexadecimal expression is 0x20F8, which is converted into decimal 8840 bytes for verification. The tail end sign is lowercase letter dhav. See Table 2 for the specific frame tail structure.

Figure 1. Header and trailer of DHFS file system

Fig.1 Frame head and tail in DHFS

2 DHFS video surveillance storage mode research

2.1 Analysis of DHFS Video File Storage Mode

Video surveillance adopts real-time file sequential storage mode. The overall basic layout structure is shown in Figure 2. From the file system data area, information such as the ID of Dahua video surveillance file system and the size of video surveillance storage block can be analyzed. These parameters play a very important role in the recovery of Dahua video surveillance data. For example, DHFS will allocate 2 MB storage space to each video channel in real time. This value is defined by the corresponding parameters in the startup sector. Video segments of each channel are divided into 2 MB segments and stored alternately in order on disk. However, in some cases, 2 MB video segments of a single channel are stored continuously. Suppose CHn represents 2 MB video segments of the channel to which it belongs. In a video surveillance system with only 3 channels, the storage arrangement of video segments of each channel in DHFS file system is shown in Figure 2. A video segment represents a 2 MB video data block during video storage. The video clips numbered 1~6 are recorded normally for video surveillance, and the video clips of each channel are stored alternately. Numbers 6 to 10 belong to the case where the same channel surveillance video is recorded continuously. If the DHFS file system is formatted incorrectly or partially covered by video, the file system of the video surveillance system is damaged, and the recovery of video surveillance needs to be restored through channel separation and recombination, that is, separating video segments numbered 1, 4 and 8, recombining into video surveillance files of channel 1, separating video segments numbered 2, 5, 9 and 10, recombining into video surveillance files of channel 2, separating video segments numbered 3, 6 and 7, Into the video surveillance files for channel three. So the problem of DHFS file system data forensics translates into how to make sure

Table 1 DHFS frame header structure

Table 1 Frame head structure of DHFS

┌───────┬───────┬─────────────────────┐

offset occupied byte Meaning │

├───────┼───────┼─────────────────────┤

│0x00 │4 <$Frame Start ID 0x44484156 │

├───────┼───────┼─────────────────────┤

│0x04 │2 Frame Type │

├───────┼───────┼─────────────────────┤

│0x06 │2 frame channel │

├───────┼───────┼─────────────────────┤

│0x08 │4 Frame Number │

├───────┼───────┼─────────────────────┤

│0x0C │4 Frame Length │

├───────┼───────┼─────────────────────┤

│0x10 │4 Frame creation time │

└───────┴───────┴─────────────────────┘

Table 2 DHFS frame tail structure

Table 2 Frame tail structure of DHFS

┌────────┬────────┬───────────────────┐

offset occupied byte Meaning │

├────────┼────────┼───────────────────┤

│0x00 │4 END OF FRAME IDENTIFICATION 0x64686176 │

├────────┼────────┼───────────────────┤

│0x04 │4 Frame Length │

└────────┴────────┴───────────────────┘

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.