rtmp Protocol
The RTMP protocol packet consists of a header and a package, and the header can be any of 4 lengths: 8, 4, 1 byte (s). The full rtmp header should be 12bytes, containing timestamps, amfsize,amftype,streamid information, The 8-byte header only records timestamps, Amfsize,amftype, and other bytes of header record information in turn. The maximum length of the package is 128 bytes by default, and the maximum length of the package can be changed by chunksize, usually when the AFM data exceeds 128 bytes, more than 128 of the parts are placed in the other rtmp packets, and the packet header is a byte.
The full 12-byte rtmp header each byte meaning:
| Use |
Size (Byte) |
Meaning |
| Head_type |
1 |
Baotou |
| TiMMER |
3 |
Time stamp |
| Amfsize |
3 |
Data size |
| Amftype |
1 |
Data type |
| Streamid |
4 |
Stream ID |
First, Head_type
The first two bits of head_type determine the length of the header. It can be calculated with the mask 0xc0 for "and":
Head_type first two bit and length correspondence:
| Bits |
Header Length |
| 00 |
bytes |
| 01 |
8 bytes |
| 10 |
4 bytes |
| 11 |
1 byte |
Head_type's back 6 bits and streamid determine the channelid. Streamid and Channelid Correspondence: streamid= (ChannelID-4)/5+1 reference Red5
| Channelid |
Use |
| 02 |
Ping and Byteread Channels |
| 03 |
Invoke channel our Connect () publish () and self-writing netconnection.call () data are all in this channel |
| 04 |
Audio and Vidio channels |
| 05 06 07 |
Server reserved, observed FMS2 Use these channel also to send audio or video data |
For example, in the rtmp package is often seen in the 0xc2, it represents a byte of Baotou, channel=2.
Second, TiMMER
Timmer accounted for 3 bytes is the timestamp, the time stamp of the audio and video stream is unified row. Can be divided into absolute timestamp and relative time stamp.
FMS for the same stream, the timestamp of the time stamp accepted by the publication is different
Publish timestamp, with a relative timestamp, the timestamp value equals the difference between the absolute timestamp of the current media packet and the absolute timestamp of the last media packet, which means that the audio and video time is stamped on a timeline. Unit milliseconds.
Play timestamp, relative timestamp, timestamp value is equal to the difference between the absolute timestamp of the current media packet and the absolute timestamp of the last same type of media packet, that is, the audio and video timestamps are separate time axes, in milliseconds.
FLV format file timestamp, absolute timestamp, timestamp length of 3 bytes. The timestamp value after 0xFFFFFF is equal to timestamp & 0xFFFFFF.
FLV format File The total length of time is stored in the Duration property of Onmetadata, which is 8 bytes long and is a double type that flips.
Third, Amfsize
The Amfsize occupies three bytes, which is a AMF length that can exceed the maximum length of the rtmp packet by 128 bytes. If more than 128 bytes are exceeded, then the header of each subsequent rtmp packet is composed of multiple subsequent rtmp packets, each of which takes up only one byte. In general, it is 0xC. Beginning.
Iv. Amftype
The Amfsize occupies three bytes, which is a AMF length that can exceed the maximum length of the rtmp packet by 128 bytes.
Amftype is the type of package
| 0x01 |
Chunk Size |
Changes the chunk size for packets |
| 0x02 |
Unknown |
|
| 0x03 |
Bytes Read |
Send every x bytes read by both sides |
| 0x04 |
Ping |
Ping is a stream control message, have subtypes |
| 0x05 |
Server BW |
The servers downstream BW |
| 0x06 |
Client BW |
The clients upstream BW |
| 0x07 |
Unknown |
|
| 0x08 |
Audio Data |
Packet containing audio |
| 0x09 |
Video Data |
Packet containing video data |
| 0x0a-0x0e |
Unknown |
|
| 0x0F |
Flex_stream_send |
Type_flex_stream_send |
| 0x10 |
Flex_shared_object |
Type_flex_shared_object |
| 0x11 |
Flex_message |
Type_flex_message |
| 0x12 |
Notify |
An invoke which does not expect a reply |
| 0x13 |
Shared Object |
Has subtypes |
| 0x14 |
Invoke |
Like remoting call, used for stream actions too. |
| 0x16 |
Streamdata |
This is the new data type after FMS3, this type of data contains Audiodata and Videodata |
Wu, Streamid
Streamid is the ID of the audio and video stream, if amftype!=0x08 or!=0x09 so Streamid is 0.
Calculation formula between Channelid and Streamid: streamid= (ChannelID-4)/5+1 reference Red5
For example, when Channelid is 2, 3, 4 o'clock Streamid is 1 when Channelid is 9 Streamid is 2
six, packet analysis
For example, there is data for an RTMP packet. at 00 00 00 00 00 08,,,,,, and at the same date, the 6F 6E 6E
Meaning of data parsing in sequence
03 indicates 12 byte header, channelid=3
000000 = timmer=0
000102 = amfsize=18
14 represents the Amftype=invoke method call
00 00 00 00 means Streamid = 0
To this, the 12-byte rtmp header ends
The following is the AMF data analysis, the specific AMF0 data format, please refer to
Http://www.cnweblog.com/fly2700/archive/2008/04/09/281432.html
02 means string
0007 = string Length 7
6F 6E 6E 65 63 74 is a string of Ascall value "Connect"
00 means double
3F F0 00 00 00 00 00 00 represents a double of 0.0
08 indicates the start of the map data
AMF0 Data types
RTMP packet Default maximum length is 128 bytes, (or through chunksize change the maximum length of rtmp packet), when the AMF data more than 128Byte may have a plurality of rtmp packets, If the rtmp packet that needs to be decoded is too long, it is split into multiple TCP packets by the TCP protocol. Then the decoding will need to first include the RTMP packet of the TCP packets merged, and then decode the merged data, decoding can be obtained in AMF format data, The AMF data can be decoded by taking these data out. The commands between the server and the Flash client are transmitted in AMF format, such as commands in the Publish () and server as scripts. The commonly used data types are organized as follows:
| Type description (ObjType) |
Data |
DataSize |
| Core_string |
0x02 |
2 bytes (2 bytes of data record the actual length of the string) |
| Core_object |
0x03 |
0 bytes (start nested 0x00000009 to indicate nested end) |
| Null |
0x05 |
0 bytes Empty byte meaningless |
| Core_number |
0x00 |
8 bytes |
| Core_map |
0x08 |
4 bytes (Start nesting) |
| Core_boolean |
0x01 |
1 bytes |
The nesting relationships of AMF0 data are as follows:
Object={objtype + ObjValue}
Objtype={core_boolean, Core_number, core_string, Core_date, Core_array, Core_map, Core_object}
Core_boolean={value (1 bytes)}
Core_number={value (8 bytes)}
Core_string={stringlen (2 bytes) + stringvalue (Stringlen byte)}
Core_date={value (ten bytes)}
Core_array={arraylen (4 Byte) + Object}
Core_map={mapnum (4 bytes) + Core_object}
Core_object={core_string + Object}
For example, after the handshake is completed, Flash sends the first RTMP data to the FMS, with the following contents:
The above data consists of 2 rtmp packets, 2 rtmp headers in blue, the first Blue is 12 bytes of Baotou, the back of a blue C3 is a byte header, the green part is AMF data, the red is the AMF data type, the entire rtmp decoding process is as follows
[2008-06-18 16:59:20] Decodeinvoke:
[2008-06-18 16:59:20] InvokeName:String:connect
[2008-06-18 16:59:20] invokeid:double:0
[2008-06-18 16:59:20] map:mapnum:0
[2008-06-18 16:59:20] params:{
[2008-06-18 16:59:20] Key:String:objectEncoding
[2008-06-18 16:59:20] value:double:0
[2008-06-18 16:59:20] Key:String:app
[2008-06-18 16:59:20] Value:String:mediaserver
[2008-06-18 16:59:20] Key:String:fpda
[2008-06-18 16:59:20] value:bool:0
[2008-06-18 16:59:20] Key:String:tcUrl
[2008-06-18 16:59:20] Value:string:rtmp://127.0.0.1/mediaserver
[2008-06-18 16:59:20] Key:String:audioCodecs
[2008-06-18 16:59:20] value:double:615
[2008-06-18 16:59:20] Key:String:videoCodecs
[2008-06-18 16:59:20] value:double:76
[2008-06-18 16:59:20]} End Params
[2008-06-18 16:59:20] InvokeParams:String:PUBLISHER
[2008-06-18 16:59:20] InvokeParams:String:streamRecode
For a detailed data type, refer to Red5
In order to achieve the live stream of H. FMS3 data, a data type is added, the value of this type is 0x16, this type is not in the table below, if necessary, see http://www.cnweblog.com/fly2700/archive/2009/02/06/297957.html
Enum AMF
{
/**
* Boolean Value Marker constant
*/
Type_boolean = 0x01,
/**
* String Marker constant
*/
type_string = 0x02,
/**
* Object Marker constant
*/
Type_object = 0x03,
/**
* Movieclip Marker constant
*/
Type_movieclip = 0x04,
/**
* Null Marker constant
*/
Type_null = 0x05,
/**
* Undefined Marker constant
*/
type_undefined = 0x06,
/**
* Object Reference Marker constant
*/
Type_reference = 0x07,
/**
* Mixed Array Marker constant
*/
Type_mixed_array = 0x08,
/**
* End of Object marker constant
*/
Type_end_of_object = 0x09,
/**
* Array Marker constant
*/
Type_array = 0x0A,
/**
* Date Marker constant
*/
Type_date = 0x0B,
/**
* Long String Marker constant
*/
type_long_string = 0x0C,
/**
* Unsupported Type marker constant
*/
type_unsupported = 0x0D,
/**
* Recordset Marker constant
*/
Type_recordset = 0x0E,
/**
* XML Marker constant
*/
Type_xml = 0x0F,
/**
* Class Marker constant
*/
Type_class_object = 0x10,
/**
* Object marker constant (for AMF3)
*/
Type_amf3_object = 0x11,
/**
* True Marker constant
*/
Value_true = 0x01,
/**
* False Marker constant
*/
Value_false = 0x00
};
About packets with the data type 0x16 in the RTMP packet
When you use the RTMP protocol to pull audio and video data from a FMS3, you receive a amftype=0x16 packet that never appeared in FMS2.
The 8th byte of the rtmp header is Amftype, which is the data type. For example, amftype=0x08 represents an audio packet, amftype=0x04 represents a ping packet, and so on. A data type has been added to the FMS3 in order to achieve the live broadcast of the data, and the value of this type is 0x16. The amftype=0x16 package contains both an audio frame and a video frame. Where the audio frame and video frame is a new format to store, similar to the FLV file storage format, each audio and video package as a tag, many of the tags make up this amftype=0x16 data type, the format of the tag is as follows:
Purpose Size (Byte) data meaning
Streamtype 1 Stream Type (0x08= audio, 0x09= video)
Mediasize 3 Media Data area size
TiMMER 3 Absolute Timestamp, unit milliseconds
Reserve 4 reserved with a value of 0
Mediadata mediasize Media data, audio or video
Taglen 4 frame size, value for media data region size + parameter length (mediasize+1+3+3+4)
About packets with the data type 0x16 in the RTMP packet
When you use the RTMP protocol to pull audio and video data from a FMS3, you receive a amftype=0x16 packet that never appeared in FMS2.
The 8th byte of the rtmp header is Amftype, which is the data type. For example, amftype=0x08 represents an audio packet, amftype=0x04 represents a ping packet, and so on. A data type has been added to the FMS3 in order to achieve the live broadcast of the data, and the value of this type is 0x16. The amftype=0x16 package contains both an audio frame and a video frame. Where the audio frame and video frame is a new format to store, similar to the FLV file storage format, each audio and video package as a tag, many of the tags make up this amftype=0x16 data type, the format of the tag is as follows:
Purpose Size (Byte) data meaning
Streamtype 1 Stream Type (0x08= audio, 0x09= video)
Mediasize 3 Media Data area size
TiMMER 3 Absolute Timestamp, unit milliseconds
Reserve 4 reserved with a value of 0
Mediadata mediasize Media data, audio or video
Taglen 4 frame size, value for media data region size + parameter length (mediasize+1+3+3+4)
