PROFILPELAJAR.COM

Action Message Format (AMF)
Internet media type	application/octet-stream
Developed by	Adobe Systems
Type of format	Data exchange format
Container for	Structured data

Action Message Format (AMF) is a binary format used to serialize object graphs such as ActionScript objects and XML, or send messages between an Adobe Flash client and a remote service, usually a Flash Media Server or third party alternatives. The Actionscript 3 language provides classes for encoding and decoding from the AMF format.

The format is often used in conjunction with Adobe's RTMP to establish connections and control commands for the delivery of streaming media. In this case, the AMF data is encapsulated in a chunk which has a header which defines things such as the message length and type (whether it is a "ping", "command" or media data).

Format analysis

AMF was introduced with Flash Player 6, and this version is referred to as AMF0. It was unchanged until the release of Flash Player 9 and ActionScript 3.0, when new data types and language features prompted an update, called AMF3.^[1] Flash Player 10 added vector and dictionary data types documented in a revised specification of January 2013.

Adobe Systems published the AMF binary data protocol specification in December 2007^[2]^[3] and announced that it will support the developer community to make this protocol available for every major server platform.

AMF self-contained packet

The following amf-packet is for transmission of messages outside of defined Adobe/Macromedia containers or transports such as Flash Video or the Real Time Messaging Protocol.

amf-packet-structure
Length	Name	Type	Default
16 bits	version	uimsbf	0 or 3
16 bits	header-count	uimsbf	0
header-count*56+ bits	header-type-structure	binary	free form
16 bits	message-count	uimsbf	1
message-count*64+ bits	message-type-structure	binary	free form

header-type-structure
Length	Name	Type	Default
16 bits	header-name-length	uimsbf	0
header-name-length*8 bits	header-name-string	UTF-8	empty
8 bits	must-understand	uimsbf	0
32 bits	header-length	simsbf	variable
header-length*8 bits	AMF0 or AMF3	binary	free form

message-type-structure
Length	Name	Type	Default
16 bits	target-uri-length	uimsbf	variable
target-uri-length*8 bits	target-uri-string	UTF-8	variable
16 bits	response-uri-length	uimsbf	2
response-uri-length*8 bits	response-uri-string	UTF-8	"/1"
32 bits	message-length	simsbf	variable
message-length*8 bits	AMF0 or AMF3	binary	free form

If either the header-length or message-length are unknown then they are set to -1 or 0xFFFFFFFF

uimsbf: unsigned integer, most significant bit first

simsbf: signed integer, most significant bit first

AMF0

The format specifies the various data types that can be used to encode data. Adobe states that AMF is mainly used to represent object graphs that include named properties in the form of key-value pairs, where the keys are encoded as strings and the values can be of any data type such as strings or numbers as well as arrays and other objects. XML is supported as a native type. Each type is denoted by a single byte preceding the actual data. The values of that byte are as below (for AMF0):

Number - 0x00 (Encoded as IEEE 64-bit double-precision floating point number)
Boolean - 0x01 (Encoded as a single byte of value 0x00 or 0x01)
String - 0x02 (16-bit integer string length with UTF-8 string)
Object - 0x03 (Set of key/value pairs)
Null - 0x05
ECMA Array - 0x08 (32-bit entry count)
Object End - 0x09 (preceded by an empty 16-bit string length)
Strict Array - 0x0a (32-bit entry count)
Date - 0x0b (Encoded as IEEE 64-bit double-precision floating point number with 16-bit integer time zone offset)
Long String - 0x0c (32-bit integer string length with UTF-8 string)
XML Document - 0x0f (32-bit integer string length with UTF-8 string)
Typed Object - 0x10 (16-bit integer name length with UTF-8 name, followed by entries)
Switch to AMF3 - 0x11

AMF objects begin with a (0x03) followed by a set of key-value pairs and end with a (0x09) as value (preceded by 0x00 0x00 as empty key entry). Keys are encoded as strings with the (0x02) 'type-definition' byte being implied (not included in the message). Values can be of any type including other objects and whole object graphs can be serialized in this way. Both object keys and strings are preceded by two bytes denoting their length in number of bytes. This means that strings are preceded by a total of three bytes which includes the 0x02 type byte. Null types only contain their type-definition (0x05). Numbers are encoded as double-precision floating point and are composed of eight bytes.

As an example, when encoding the object below in actionscript 3 code.

var person:Object = {name:'Mike', age:'30', alias:'Mike'};
var stream:ByteArray = new ByteArray();
stream.objectEncoding = ObjectEncoding.AMF0; // ByteArray defaults to AMF3
stream.writeObject(person);

The data held in the ByteArray is:

Hex code	ASCII
`03 00 04 6e 61 6d 65 02 00 04 4d 69 6b 65 00 03 61 67 65 00 40 3e 00 00 00 00 00 00 00 05 61 6c 69 61 73 02 00 04 4d 69 6b 65 00 00 09`	`. . . n a m e . . . M i k e . . a g e . @ > . . . . . . . . a l i a s . . . M i k e . . .`

Note: the object properties can be sorted in a different order from the one in which they are placed in actionscript. For coloring/markup, refer to the legend below.

The code above will work only for built-in classes like Object. To serialise and deserialise custom classes, the user needs to declare them using the registerClassAlias command or else an error will be thrown by the player.

// for a hypothetical class Person
registerClassAlias("personTypeAlias", Person);

Although, strictly speaking, AMF is only a data encoding format, it is usually found encapsulated in a RTMP message or Flex RPC call. An example of the former can be found below (it is the "_result" message returned in response to the "connect" command sent from the flash client):

Hex code	ASCII
03 00 00 00 00 01 05 14 00 00 00 00 02 00 07 5F 72 65 73 75 6C 74 00 3F F0 00 00 00 00 00 00 03 00 06 66 6D 73 56 65 72 02 00 0E 46 4D 53 2F 33 2C 35 2C 35 2C 32 30 30 34 00 0C 63 61 70 61 62 69 6C 69 74 69 65 73 00 40 3F 00 00 00 00 00 00 00 04 6D 6F 64 65 00 3F F0 00 00 00 00 00 00 00 00 09 03 00 05 6C 65 76 65 6C 02 00 06 73 74 61 74 75 73 00 04 63 6F 64 65 02 00 1D 4E 65 74 43 6F 6E 6E 65 63 74 69 6F 6E 2E 43 6F 6E 6E 65 63 74 2E 53 75 63 63 65 73 73 00 0B 64 65 73 63 72 69 70 74 69 6F 6E 02 00 15 43 6F 6E 6E 65 63 74 69 6F 6E 20 73 75 63 63 65 65 64 65 64 2E 00 04 64 61 74 61 08 00 00 00 01 00 07 76 65 72 73 69 6F 6E 02 00 0A 33 2C 35 2C 35 2C 32 30 30 34 00 00 09 00 08 63 6C 69 65 6E 74 49 64 00 41 D7 9B 78 7C C0 00 00 00 0E 6F 62 6A 65 63 74 45 6E 63 6F 64 69 6E 67 00 40 08 00 00 00 00 00 00 00 00 09	. . . . . . . . . . . . . . . _ r e s u l t . ? . . . . . . . . . . f m s V e r . . . F M S / 3 , 5 , 5 , 2 0 0 4 . . c a p a b i l i t i e s . @ ? . . . . . . . . m o d e . ? . . . . . . . . . . . . . l e v e l . . . s t a t u s . . c o d e . . . N e t C o n n e c t i o n . C o n n e c t . S u c c e s s . . d e s c r i p t i o n . . . C o n n e c t i o n s u c c e e d e d . . . d a t a . . . . . . . v e r s i o n . . . 3 , 5 , 5 , 2 0 0 4 . . . . . c l i e n t I d . A . . x . . . . . . o b j e c t E n c o d i n g . @ . . . . . . . . . .

legend: object start/end object keys object values ecma_array

The AMF message starts with a 0x03 which denotes an RTMP packet with Header Type of 0, so 12 bytes are expected to follow. It is of Message Type 0x14, which denotes a command in the form of a string of value "_result" and two serialized objects as arguments. The message can be decoded as follows:

(command) "_result"
(transaction id) 1
(value)
[1] { fmsVer: "FMS/3,5,5,2004"
        capabilities: 31.0
        mode: 1.0 },
[2] { level: "status",
        code: "NetConnection.Connect.Success",
        description: "Connection succeeded.",
        data: (array) {
               version: "3,5,5,2004" },
        clientId: 1584259571.0,
        objectEncoding: 3.0 }

Here one can see an array (in turquoise) as a value of the 'data' key which has one member. We can see the objectEncoding value to be 3. This means that subsequent messages are going to be sent with the 0x11 message type, which will imply an AMF3 encoding.

AMF3

The latest version of the protocol specifies significant changes that allow for a more compressed format. The data markers are as follows:

Undefined - 0x00
Null - 0x01
Boolean False - 0x02
Boolean True - 0x03
Integer - 0x04 (expandable 8+ bit integer)
Double - 0x05 (Encoded as IEEE 64-bit double-precision floating point number)
String - 0x06 (expandable 8+ bit integer string length with a UTF-8 string)
XMLDocument - 0x07 (expandable 8+ bit integer string length and/or flags with a UTF-8 string)
Date - 0x08 (expandable 8+ bit integer flags with an IEEE 64-bit double-precision floating point UTC offset time)
Array - 0x09 (expandable 8+ bit integer entry count and/or flags with optional expandable 8+ bit integer name lengths with a UTF-8 names)
Object - 0x0A (expandable 8+ bit integer entry count and/or flags with optional expandable 8+ bit integer name lengths with a UTF-8 names)
XML - 0x0B (expandable 8+ bit integer flags)
ByteArray - 0x0C (expandable 8+ bit integer flags with optional 8 bit byte length)

The first 4 types are not followed by any data (Booleans have two types in AMF3).

Additional markers used by Flash Player 10 (the format is still referred to as AMF3) are as follows:

VectorInt - 0x0D
VectorUInt - 0x0E
VectorDouble - 0x0F
VectorObject - 0x10
Dictionary - 0x11

AMF3 aims for more compression and one of the ways it achieves this is by avoiding string duplication by saving them into an array against which all new string are checked. The byte following the string marker is no longer denoting pure length but it is a complex byte where the least significant bit indicated whether the string is 'inline' (1) i.e. not in the array or 'reference' (0) in which case the index of the array is saved. The table includes keys as well as values.

In older versions of Flash Player there existed one number type called 'Number' which was a 64-bit double precision encoding. In the latest releases there is an int and a uint which are included in AMF3 as separate types. Number types are identical to AMF0 encoding while Integers have variable length from 1 to 4 bytes where the most significant bit of bytes 1-3 indicates that they are followed by another byte.

Support for AMF

The various AMF Protocols are supported by many server-side languages and technologies, in the form of libraries and services that must be installed and integrated by the application developer.

Platforms: