RTMP Part 8 - Packets Examples

This part, I will show a packet trace and description I had done on Red 5 for streaming a vlc file.

Below is the complete packets list from a remote browser connecting to a Red 5 olfaDemo streaming server. This demo provide vlc publishing and streaming service. As you can see, it complete 3 parts of handshakes before the first invoke command. I will ignore handshake in this discussion. Also, please note that bytes are represented in hexadecimal format


Command Message

It is used to perform RPC in the server. In Wireshark, it is named as Invoke message.

I will go through the RTMP header for this packets

03 00 00 7F 00 00 2F 14 00 00 00 00

03 - It is the FMT 0 and Chunk Stream Id 3.

FMT 0 means it is use Chunk Type 0 of 11 bytes

Chunk Stream Id 3 means this AMF object identification number is 3

Since it is Type 0 chunk, the remaining header means

00 00 7F - timestamp delta

00 00 2F - message length

14 - message type id. It is 0x14 (20) . Message type value 20 means it is a AMF 0 encoding command message. Please note that if it is 0x11 (17), it means it is a AMF 3 encoding command message

00 00 00 00 - message stream id


Now, look at the RTMP body, it starts with 02 00 22 64 65 6D ....... 00 40 00 00 00 00 00 00 00 05

This is a encoded AMF 0 message, I will just explain it meaning

First byte is 0x02 (String marker). It follows by 0x 00 22 (String length of 34 bytes). Then, 34 bytes of UTF-8 String

After 32 bytes of string data, the next byte is 0 (Number marker). It following by 8 bytes of IEEE-754 double precision floating point value in network byte order (big-endian).

The message end with 05 (Null marker)


Below show a reply from the server after an Command Message (Invoke).

Header and body information is the same format. Most important note is the first AMF message is a string with value _result


CreateStream Command

createStream command is called using Invoke function call of message type id 0x14 (AMF 0 Command Message).

As you can see, the RTMP header is the same while the RTMP body start with a string marker with createStream as value. Please note that the value after the createStream are argument for the RPC


Play Command

play command is sent as 0x14 message type id (AMF 0 Command Message) as well. This example is clearer to show that the AMF message is asking the server to play (command) ironman2.flv (argument)



Chunk Size Command

After play command, you can see that the server send the chunk size to client.

It is a RTMP protocol command. Let go through the header 42 00 00 00 00 00 04 01

42 - this show FMT as 1 and Chunk Stream Id as 2

FMT 1 refers to Type 1 of Chunk Message header

As this is a RTMP protocol message, the Chunk Stream Id must be 2

FMT 1 tells us that the header is 7 bytes, so, the remaining header is

00 00 00 - timestamp delta

00 00 04 - message length

01 - message type id (this is a Set Chunk Size message)

Since it is a Set Chunk Size message, it have a payload of 4 bytes, that is, 00 00 04 00


User Control Message

As you can see, the server and client send Ping message to one another occasionally. Please note that Wireshark named it as Ping message, however, it is just a User Control Message and may not mean "Ping". You have to look at the content of the payload for the real meaning.

The header is 02 00 00 00 00 00 06 04 00 00 00 00.

02 - It is a FMT is 0 and Chunk Stream id is 02

This tells you it is using 11 bytes chunk message header and it is a protocol message. So, the remaining header is

00 00 00 - timestamp delta

00 00 06 - message length

04 - message type id. This show that it is a User Control Message

00 00 00 00 - message stream id

Since it is a User Control Message, the payload has a format of 2 bytes event type and follow event data. The payload is 00 04 00 00 00 01

00 04 - This mean server is telling client that this is a recorded stream (StreamIsRecorded). It has 4 bytes of event data

00 00 00 01 - This is the stream ID of the recorded stream.

Please refer to previosus RTMP discussion for the event id and meaning. Also, please see the message flow discussion


Data Message

The server is now sending Metadata to the client with Data Message. In Wireshark, it named it as Notify message

The header is 04 00 00 00 00 00 F4 12 01 00 00 00

04 - FMT is 0 and Chunk Stream Id is 4. Thus, it has a chunk stream header size of 11 bytes

00 00 00 - timestamp delta

00 00 F4 - message length

12 - message type id. 0x12 (18) means this is a Data Message using AMF 0 encoding. If it is 0x0F (15), it is a Data Message using AMF 3 encoding

01 00 00 00 - message stream id. The message stream id is 1 because it is stored in little-endian format

Another Note is that message stream id 0x 00 00 00 00 (Integer 0) is reserved for NetConnection Object while 0x 01 00 00 00 (Integer 1) is reserved for NetStream.

I will not go through onMetaData here. These are the decoding audio/video configuration information. It will be needed to initialize the decoder for decoding process.



Audio Data

As you can see, it has a message type id (function call) of 0x08



Incoming Video Data

As you can see, it has a message type id (function call) of 0x09


Comments

  1. Thanks a lot. Could you tell me what the video data is exactly? It seems to be a part of the flv format. Could it be just body of the VIDEODATA tag as in E 4.3.1 of the ADOBE FLASH VIDEO FILE FORMAT SPECIFICATION VERSION 10.1?

    ReplyDelete
  2. Here I am again. I did some reverse engineering myself. I have an RTMP video message (typeid 0x09) with these first eight bytes in the message payload: (hex) 12 00 00 84 03 02 99 c7. I discovered these same eight bytes at offset 0x36 in the flv file.

    I analysed this file with the help of Adobe's FLV specification version 10.1 at appendix E.2 page 68 (by the way UB = one bit):

    Offset 00: FLV header, length 9 bytes
    Offset 09: First back pointer, always zero, length 4 bytes.
    Offset 0d: Empty audio tag, length 11 bytes.
    Offset 18: Second back pointer, value 11, length 4 bytes.
    Offset 1c: Empty video tag, length 11 bytes.
    Offset 28: Third back pointer, value 11, length 4 bytes.
    Offset 2b: Video tag header, length 11 bytes.
    Offset 36: Video data which I also find in RTMP.

    Heureka! It seems that RTMP only transmits raw video data without headers. A media server needs to know the flash file format and extract the data from the tags.

    And these empty video and audio tags? A wee bit strange but not forbidden and quite manageable. What do you think about them?

    Here the hex dump of the first 64 bytes of my test video:
    0000 46 4c 56 01 05 00 00 00 09 00 00 00 00 08 00 00
    0010 00 00 00 00 00 00 00 00 00 00 00 0b 09 00 00 00
    0020 00 00 00 00 00 00 00 00 00 00 0b 09 00 05 60 00
    0030 00 00 00 00 00 00 12 00 00 84 03 02 99 c7 c8 c6

    ReplyDelete

Post a Comment

Popular Posts