User's Manual

107
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”.