User's Manual
Table Of Contents
- Chapter 1 Introduction
- Chapter 2 Basic Setup
- Chapter 3 Viewing Live Video
- Chapter 4 Advanced Viewing Setup
- Chapter 5 Web-based Management
- Introduction
- Connecting to Video Server
- Welcome Screen
- Administration Menu
- System Screen
- Network Screen
- Wireless Screen (Wireless Model Only)
- DDNS Screen
- IP Filter Screen
- I/O Port Screen
- RS485 Screen
- Streamings
- Video & Audio Screen
- Video Access Screen
- User Database Screen
- Motion Detection Screen
- Audio Detection Screen
- E-Mail Screen
- FTP Screen
- HTTP Screen
- SMB/CIFS Client Screen
- Event Trigger Screen
- Maintenance Screen
- Status Screen
- Log Screen
- Chapter 6 WindowsViewing/Recording Utility
- Chapter 7 Troubleshooting
- Appendix A Specifications
- Appendix B Network Camera HTTP CGI
Motion Vector Data
To include the motion vector values in the streaming packets.
Whatever the streaming method is - ASF (through HTTP) or RTP (through UDP), the
streaming data will include such information to let the client side S/W to judge whether the
motion event is triggered or not.
The data locates in the padding bytes of the streaming data.
As to the data format in the streaming packet, please refer to the next section
.
Padding Data Format
The purpose of the padding data field is to let the PC side software (ActiveX or Utility…)
could parse the padding data to get the relative information.
The F/W (camera side) should always pad the data if it supports some features (even is
disabled).
1. MPEG-4 platform.
1.1. The F/W always pad the data over video.asf streaming
1.2. The F/W does not pad anything over the RTP/RTSP streaming
2. H.264 platform
The F/W pads the data over the streamings if the client bring the extension
parameter “padding=yes” by request, please refer to the chapter ” Extension to
the streaming URL defines” for details.
The following padding data starts from the 1
st
byte of the padding area (after the normal
streaming frames)
Padding format (Intel format):
4 Bytes 1 Byte 1 ~ 4 Byte XXX Byte 1 Byte 1 ~ 4 Byte XXX Byte …. 2 Bytes
Total Length Command_1 Length Data Command_2 Length Data Padding End
Rules:
1. The 1
st
4 bytes padding is to declaim the total padding length, including these 4 bytes and
the “Padding End” (from 1
st
byte to the last byte, including length and end command).
2. The following padding data will divide into 3 parts:
A. Padding command (1 byte)
B. Padding length for the specific command (1~4 bytes)
C. Padding data for the specific command
3. The length of the “padding length” depends on the command range.
A. 0x00 ~ 0xBF: the length field is in “1 byte”
B. 0xC0 ~ 0xDF: the length field is in “2 bytes”
C. 0xE0 ~ 0xFF: the length field is in “4 bytes”
4. The last 2 bytes are the “Padding End” (0xBF00) command. It equals to the
“command=END” + “length=0”.
5. The padding command could be in any sequence.
103