- Source: RTMPDump
RTMPDump is a free software project dedicated to developing a toolkit for RTMP streams. The package includes three programs, rtmpdump, rtmpsrv and rtmpsuck.
rtmpdump is used to connect to RTMP servers just like normal Flash video player clients, and capture the stream from the network, and save it to a file. With it, commands may be constructed using connection and authentication information previously obtained from the RTMP server by rtmpsrv.
rtmpsrv is used to watch connections and streams
rtmpsuck can also be used to capture streams, but can be used to detect parameters to be used with rtmpdump
It has been reviewed as "an excellent utility for recording streams broadcasting TV and video on demand" and has been used in academic research on video streaming rate selection and a developmental media framework. The utility has been noted for its small size and its ability to decrypt both RTMPE (Encrypted RTMP) and RTMPS (Secure RTMP) digital rights management technologies.
In a 2009 Digital Millennium Copyright Act Cease and Desist order issued against SourceForge, Adobe Systems Inc. asserted that rtmpdump "can be used" to infringe copyrights, without claiming actual use. As of 2009, SourceForge had removed the project files, providing the message "The project specified has been flagged as deleted". From November 2009 onwards, the project has been hosted as a Git repository at MPlayer's website, MplayerHQ.hu.
On-demand streams
In negotiating a connection, an RTMP client sends and receives a data stream containing multiple elements, as a single command line. An on-demand stream typically includes the following elements:
= For a Limelight server
=-r rtmp://server address
-a: authentication elements (the alternative --app may be used instead)
Typically in the format -application?as=data&av=data&te=data&mp=data&et=data&fmta-token=data
application: A path address. For example, a1414/e3
as: For example, as=adobe-hmac-sha256
av: For example, av=1
te: For example, te=connect
mp: Typically, two or more comma-separated URL addresses, for alternative bitrate streams (MPEG format, MP3 or MP4)
et: Typically, a ten-character number (numerical)
fmta-token: Typically, a 64-character authentication (auth) string [that is, an authentication token] (alphanumeric)
-y: playpath (URL address of the desired bitstream, one of those specified in mp above)
Typically, in the format mp3:path/filename.mp3 or mp4:path/filename.mp4
-o: Output filename
The foregoing are typically the only elements (or "switches") that are essential to a connection, if neither Tunnelling nor Encryption are in use by the server. Although other elements may be encountered in practice, they are normally non-essential.
Hence the following elements are typically sent by the client software application, as a single command line -
The parts comprising the -a (or --app) element must be incorporated in it in the order shown above, as the sequence in which its parts are received by the RTMP server is critical.
The authentication strings (et= and fmta-token=) contain session information, so will change on each fresh connection made to the server (which in practice typically means they will expire if a new session is begun, not literally on every attempt to resume a connection), but the other elements will not usually vary from session to session.
= For an Akamai server
=The command line is typically as above, except that the -a (or --app) element contains the following parts instead -
auth: Typically, a 62-character authentication (auth) string [i.e. an authentication token] (alphanumeric)
aifp: For example, aifp=v001
slist: Typically, the URL address of the stream
Hence the following elements are typically sent by the client software application, as a single command line -
The parts comprising the -a (or --app) element must be incorporated in it in the order shown above, as the sequence in which its parts are received by the RTMP server is critical.
The authentication string (auth=) contains session information, so will change on each fresh connection made to the server (typically, if a new session is begun, e.g. the computer is restarted, not literally on every attempt to resume a connection). The other parts will not usually vary from session to session.
Note - The above describes the simplified form, whereby the stream is first saved to the user's hard disk, to be played back thereafter in a media player capable of playing an FLV encoded file (H.263 or H.264 encoding), such as GOM Player. If it's desired, instead, to play the stream directly from the RTMP server, thus giving immediate playback, additional elements will be needed in the command line including -
-f: This specifies the version of the Flash plugin installed on the user's computer. For example, -f "WIN 9,0,260,0" would indicate the user has the Windows version of Flash Player 9, release 260.
-W: The capital W command. This is the URL address of the SWF player used to play the stream, as indicated by the web page from which the stream is derived. For example, path/9player.swf?revision=18269_21576.
Live streams
The command line for an Akamai server is typically as for an Akamai on-demand stream. But the -a (or --app) element contains the following parts
auth: Typically, a 62-character authentication (auth) string [i.e. an authentication token] (alphanumeric)
aifp: For example, aifp=v001
slist: Typically, the URL address of the stream, in the format xxxxx_x_@xxxx (e.g. Radio_7_Int@6463); or more than one URL if more than one bitrate is available [see note]
Note - If the slist string contains two or more alternative streams (i.e. offers a choice of streams at alternative bitrates), the playpath element (--playpath or -y) specifies the one chosen by the user, as the identifier item.
Hence the following sequence is typically sent by the client software application, as a single command line -
All these items are mandatory, and must be included in the order shown above. The string following the ? (question mark) in both the -a and --playpath elements will typically be identical. The identifier item will typically be a sub-set of the slist data (if the latter offers a choice), otherwise they too will be identical. The -o element can specify an output filename chosen by the user.
Specifying the complete playpath is unnecessary, as that element is constructed in memory by the client application. Typically, in memory it takes the following form:
-y xxxxx_x_@xxxx?auth=[62 characters]&aifp=v001&slist=xxxxx_x_@xxxx,xxxxx_x_@xxxx
References
External links
Official website
