|Revision as of 13:08, 14 June 2009
Kostya (Talk | contribs)
← Previous diff
|Revision as of 03:04, 15 June 2009
Compn (Talk | contribs)
(add rtmpe specs. wonder why adobe has its panties in a bunch...)
Next diff →
|Line 9:||Line 9:|
|*RTMPdump - http://linuxcentre.net/getiplayer/download/||*RTMPdump - http://linuxcentre.net/getiplayer/download/|
|*Videolan - http://www.videolan.org||*Videolan - http://www.videolan.org|
|+||*Specifications (RTMPE) : http://lkcl.net/rtmp/|
Revision as of 03:04, 15 June 2009
- Description: http://rtmpy.org/wiki/RTMP
- Server: http://www.osflash.org/rtmp_os
- Server: http://osflash.org/red5
- Server: http://www.rtmpd.com/
- Server: http://code.google.com/p/rubyizumi/
- Client: http://swfdec.freedesktop.org/
- RTMPdump - http://linuxcentre.net/getiplayer/download/
- Videolan - http://www.videolan.org
- Specifications (RTMPE) : http://lkcl.net/rtmp/
- RTMP uses port 1935.
- RTMPT (RTMP Tunnelled) uses port 80 (protocol is encapsulated by HTTP).
- RTMPS (RTMP Secure) uses port 443 (protocol is encapsulated by HTTPS).
Mostly used for streaming Flash Video.
Protocol technical description
Streaming consists of exchanging messages with server by TCP protocol.
It is worth noting that path in URL serves two functions: first two directory levels (if present, only one otherwise) serve as an application name, the rest is played file name. Prefixed with colon (for FLV) or "mp4:" (for MP4) it is called "playpath".
Old Plain Handshake
This type of handshake is described everywhere (but not working with all servers):
- client sends 0x03 and 1536 bytes of random data
- server sends 0x03 and 1536 bytes of its own random data
- server sends 1536 bytes of data, containing exactly what client has sent
- client sends 1536-bytes of server-generated data back to server
Common packet passing
Each packet is transmitted in chunks. If packet is bigger than chunk size, each new chunk is prefixed with
Initial chunk size is 128 (some sources say it's 64 for audio packets but 128 otherwise). Server (client too?) may change chunk size any time.
|Packet header size||2 bits||0 - 12 bytes, 1 - 8 bytes (no ext. timestamp), 2 - 4 bytes (header data is taken from previous packet with the same stream_id), 3 - next chunk marker|
|Stream ID||6 bits||packet stream id, usually has some relation to packet contents|
|Timestamp||24 bits BE||packet timestamp|
|Packet type||8 bits||describes what data this packet holds|
|Packet size||24 bits BE|
|?||32 bits LE||probably contains extended timestamp when it's too big to fit into 24 bits|
Usual stream ID meanings:
- 2 - network-related stuff
- 3 - actions
- 8 - video data
- 9 - audio data
- 1 - change chunk type, contains 32-bit BE number with new chunk size
- 3 - "bytes read" message
- 4 - ping
- 5 - server bandwidth, contains 32-bit BE number with server bandwidth
- 6 - client bandwidth, contains 32-bit BE number with client bandwidth
- 8 - audio data, as in FLV starts with flags
- 9 - video data, as in FLV starts with flags
- 20 - invoke (server or client function call), body contains arguments to the call
- 22 - FLV metadata
Typical workflow for playing
- Client handshakes with server
- Client sends invoke with 'connect'
- Server responds with either '_result' or '_error' invoke
- If succeeded client invokes 'createStream'
- Server may respond with something
- If succeeded client invokes 'play'