This is gnash_ref.info, produced by makeinfo version 4.8 from gnashref.texi. START-INFO-DIR-ENTRY * Gnash Reference Manual: (gnash_ref). [MISSING TEXT] END-INFO-DIR-ENTRY  File: gnash_ref.info, Node: Top, Next: Introduction, Up: (dir) Gnash Reference Manual ********************** * Menu: * Introduction:: * RTMP Protocol:: * Authors:: * GNU Free Documentation License:: --- The Detailed Node Listing --- Introduction * Audience:: * What Is Supported ?:: RTMP Protocol * AMF Format:: GNU Free Documentation License * 0. PREAMBLE: 0_ PREAMBLE. * 1. APPLICABILITY AND DEFINITIONS: 1_ APPLICABILITY AND DEFINITIONS. * 2. VERBATIM COPYING: 2_ VERBATIM COPYING. * 3. COPYING IN QUANTITY: 3_ COPYING IN QUANTITY. * 4. MODIFICATIONS: 4_ MODIFICATIONS. * 5. COMBINING DOCUMENTS: 5_ COMBINING DOCUMENTS. * 6. COLLECTIONS OF DOCUMENTS: 6_ COLLECTIONS OF DOCUMENTS. * 7. AGGREGATION WITH INDEPENDENT WORKS: 7_ AGGREGATION WITH INDEPENDENT WORKS. * 8. TRANSLATION: 8_ TRANSLATION. * 9. TERMINATION: 9_ TERMINATION. * 10. FUTURE REVISIONS OF THIS LICENSE: 10_ FUTURE REVISIONS OF THIS LICENSE. * Addendum::  File: gnash_ref.info, Node: Introduction, Next: RTMP Protocol, Prev: Top, Up: Top 1 Introduction ************** Gnash is a free SWF movie player. It is available as a stand-alone application or as a plugin for several popular web browsers. It supports playing media from a disk or streaming over a network connection. Some popular video sharing sites like YouTube are supported from a wide vaariety of devices from embedded ones to modern desktops. Gnash has a better focus on security, allowing the user tight control of all network or disk based I/O. Gnash also supports extending ActionScript by creating your own. You can write wrappers for any development library, and import them into the player much like perl or python does. * Menu: * Audience:: * What Is Supported ?::  File: gnash_ref.info, Node: Audience, Next: What Is Supported ?, Up: Introduction 1.1 Audience ============ This manual is primarily focused on users interested in how to get Gnash installed from a package, and basic usage as a web browser plugin. For more technical details, please refer to the Gnash Reference manual.  File: gnash_ref.info, Node: What Is Supported ?, Prev: Audience, Up: Introduction 1.2 What Is Supported ? ======================= Gnash is known to compile for most any POSIX and ANSI C++ conforming system if you have all the dependent libraries installed. Systems we test on, and which Gnash is know to run on are Ubuntu, Fedora, Debian, OpenBSD, NetBSD, FreeBSD, Win32, and Darwin (OSX) primarily. Occasionally other platforms are built, primarily by those distribution maintainers. This includes BeOS, Haiku, Syllable, OS/2, Solaris, Slackware, and Gentoo. Gnash is a capable of reading up to SWF v9 files and opcodes, but primarily supports SWF v7, with better SWF v8 and v9 support under heavy developement. With the 0.8.2 release, Gnash includes initial parser support for SWF v8 and v9. Not all ActionScript 2 classes are implemented yet, but all of the most heavily used ones are. Many ActionScript 2 classes are partially implemented; there is support for all of the commonly used methods of each class. Gnash has implemented about 80% of ActionScript v. 2.0, and has begun implementing ActionScript v. 3.0. Gnash supports the majority of Flash opcodes up to SWF version 9, and a wide sampling of ActionScript classes for SWF version 8. As ActionsScript 3 is a more developed version of ActionScript 2, many of the same classes work for both. Support has been added to Gnash's ActionScript library to support the new ActionScript 3 filters, which get applied to every class. Implementing ActionScript clases is often the easiest way for new Gnash developers to make a contribution without a deep internal knpowledge of Gnash. Gnash has included video support since early 2007, but this is an every changing field of reverse engineering. Many of the popular video sharing sites use SWF v8 or v9, which Gnash still has imperfect support for. This is improving all the time, so often builds from a development snapshot will work when using the older release packaged in your distribution doesn't. You can find daily snapshots of the latest CVS tree at: http://www.gnashdev.org/dev_snapshots (http://www.gnashdev.org/dev_snapshots/). Gnash uses ffmpeg for codecs, so any file supported by Mplayer should work with Gnash. Gnash supports the loading of patent free codecs like Ogg Vorbis or Theora from disk based files, while work is being done to support these codecs when embedded in a SWF file. Ffmpeg contains the codecs used by the current SWF defintion, FLV, VP6 (ON2), H.263, H.264, and MP3.  File: gnash_ref.info, Node: RTMP Protocol, Next: Authors, Prev: Introduction, Up: Top 2 RTMP Protocol *************** This document is based mostly on my own reverse engineering of the RTMP protocol and AMF format. _tcpdump_ and _ethereal_ are your friend. Some additional info that got me started was from the Red5 (http://www.osflash.org/red5) project. _Red5_ is the only other open source Flash server. So some details are still vague, but as the implementation appears to work, we'll figure out what they are later. The Real Time Messaging Protocol was created by MacroMedia (now Adobe) for delivering Flash objects and video over a network connection. Currently the only servers which support this format are the MacroMedia Media sever, and the Open Source Red5 project. This is a simple protocol, optimized for poor bandwidth connections. It can support up to 64 concurrent streams over the same network connection. Part of each AMF packet header contains the index number of the stream. A single RTMP message can contain multiple AMF packets. An RTMP connection uses Tcp/ip port 1935. It is also possible to tunnel RTMP over an HTTP connection using port 80. Each AMF packet is 128 bytes long except for streaming audio, which has 64 byte packets. The basics of the RTMP protocol are as follows. All communications are initiated by the client. Image of the RTMP protocol. The client starts the RTMP connection by sending a single byte with a value of 0x3. This byte is followed by a data block of 1536 bytes. The format if this data block is unknown, but it appears to not be actually used by the protocol except as a handshake. The server receives this packet, stores the 1536 byte data block, and then send a single byte with the value of 0x3, followed by two 1536 data blocks. The second data block is the full contents of the original data block as sent by the client. The client receives the 1536 byte data block, and if they match, the connection is established. After the handshake process is done, there are three other messages that the client sends to the sever to start the data flowing. The first AMF packet sent to the server contains the _connect_ packet. This doesn't appear to do much but notify the server the client is happy with the handshake, and ready to start reading packets. The second packet is the _NetConnection_ object from the client. This ActionScript class is used by the Flash movie to create the network connection to the server. The third packet is the _NetStream_ object from the client. This is the ActionScript class used to specify the file to be streamed by the server. The RTMP packet for our example looks like this: 030000190000c91400000000020007connect00?f0000000000000030003app0200# software/gnash/tests/1153948634.flv0008flashVer02000cLNX 6,0,82,0 0006 swfUrl02001dfile:///file|%2Ftmp%2Fout.swfc30005tcUrl\002\0004 rtmp://localhost/software/gnash/tests/1153948634.flv\000\000\t \002\000\005userx We'll take this apart in a bit, but you can see how all three AMF packets are in the same message. The message is received in several 128 byte blocks, with the last one being less than that. The total size of the RTMP message is in the header, so the reader can tell if the entire message was read or not. The RTMP header is first, followed by the connect message as an ASCII string as the message body. The following AMF packet is the _NetConnection_ one, which specifies that this is coming from a Flash application. This also contains the file path the server can use to find the file to stream. This is then followed by the version number, which I assume is the version of the Flash player, so the server knows what it is talking to. The third packet is the one from _NetStream_, which specifies the URL used for the movie, followed by the user name for a semblance of security. For the next level of detail, we'll explain the format of AMF. AMF is used by the RTMP protocol to transfer data. Each Flash object is encapsulated in an AMF packet, including streaming audio or video. The first byte of the RTMP header determines two things about the rest of the message. The first 2 bits of this byte signify the total size of the RTMP header. The RTMP header is of a variable size, so this is important. 00 This specifies the header contains 12 bytes, including this one. 01 This specifies the header contains 8 bytes, including this one. 02 This specifies the header contains 4 bytes, including this one. 03 This specifies the header contains 1 byte, so this is the complete header. The other 6 bits in this byte represent the AMF index. As a single RTMP connection can support multiple data streams, this signifies which stream this packet is for. Once an AMF object is fully received by the client, the AMF index may be reused. For messages with headers of at least 4 bytes, the next 3 bytes are used by audio and video data packets, but at this time the meaning of this field is unknown. For messages with a 8 byte or larger header, the next 3 bytes determine the size of the RTMP message being transmitted. Messages with a 1 byte or 4 byte header use a standard size, 128 bytes for video, and 64 bytes for audio. For messages with an 8 byte or larger header, the next byte is the type of the AMF object. 0x3 This specifies the content type of the RTMP packet is the number of bytes read. This is used to start the RTMP connection. 0x4 This specifies the content type of the RTMP message is a _ping_ packet. 0x5 This specifies the content type of the RTMP message is server response of some type. 0x6 This specifies the content type of the RTMP packet is client request of some type. 0x8 This specifies the content type of the RTMP packet is an audio message. 0x9 This specifies the content type of the RTMP message is a video packet. 0x12 This specifies the content type of the RTMP message is notify. 0x13 This specifies the content type of the RTMP message is shared object. 0x14 This specifies the content type of the RTMP message is remote procedure call. This invokes the method of a Flash class remotely. There are two sets of data types to consider. One set is used by the to specify the content type of the AMF object, the other is an ActionScript data type tag used to denote which type of object is being transferred. The values of the initial type byte are: 0x0 This specifies the data in the AMF packet is a numeric value. All numeric values in Flash are 64 bit, _big-endian_. 0x1 This specifies the data in the AMF packet is a boolean value. 0x2 This specifies the data in the AMF packet is an _ASCII_ string. 0x3 This specifies the data in the AMF packet is a Flash object. The Flash object data type field further along in the message specifies which type of ActionScript object it is. 0x4 This specifies the data in the AMF packet is a Flash movie, ie. another Flash movie. 0x5 This specifies the data in the AMF packet is a NULL value. NULL is often used as the return code from calling Flash functions. 0x6 This specifies the data in the AMF packet is a undefined. This is also used as the return code from calling Flash functions. 0x7 This specifies the data in the AMF packet is a reference. 0x8 This specifies the data in the AMF packet is a ECMA array. 0x9 This specifies the data in the AMF packet is the end of an object definition. As an object is transmitted with multiple AMF packets, this lets the server know when the end of the object is reached. 0xa This specifies the data in the AMF packet is a Strict array. 0xb This specifies the data in the AMF packet is a date. 0xc This specifies the data in the AMF packet is a multi-byte string. Multi-byte strings are used for international language support to represent non _ASCII_ fonts. 0xd This specifies the data in the AMF packet is a an unsupported feature. 0xe This specifies the data in the AMF packet is a record set. 0xf This specifies the data in the AMF packet is a AML object. XML objects are then parsed by the _XML_ ActionScript class. 0x10 This specifies the data in the AMF packet is a typed object. For messages with a 12 byte header, the last 4 bytes are the routing of the message. If the destination is the server, this value is the NetStream object source. If the destination is the client, this is the NetStream object for this RTMP message. A value of 0x00000000 appears to be reserved for the NetConnection object. Multiple AMF streams can be contained in a single RTMP messages, so it's important to check the index of each AMF packet. An example RTMP header might look like this. (spaces added between fields for clarity) All the numbers are in hex. 03 000019 0000c9 14 000000000 03 The first two bits of this byte are the size of the header, which in this example is 00, for a 12 byte header. The next 6 bits is the AMF stream index number, which in this example is 0x3. 000019 These 3 bytes currently have an unknown purpose. 000c9 Since this example has a 12 byte header, this is the size of the RTMP message, in this case 201 bytes. 14 This is the content type of the RTMP message, which in this case is to invoke a remote function call. (which we later see is the connect function). 00000000 The source is the NetConnection object used to start this connection. * Menu: * AMF Format::  File: gnash_ref.info, Node: AMF Format, Up: RTMP Protocol 2.1 AMF Format ============== The AMF format is used in the LocalConnection, SharedObject, NetConnection, and NetStream ActionScript classes. This is a means of binary data interchange between Flash movies, or between a Flash player and a Flash server. Like the RTMP messages, an AMF packet header can be of a variable size. The size is either the same as the initial header of the RTMP message, or a 1 byte header, which is commonly used for streaming audio or video data. The body of an AMF packet may look something like this example. The spaces have been added for clarity. 02 0007 636f6e6e656374 02 This is a single byte header. The value of the first 2 bits is 0x3, and the AMF index is also 0x3. 0007 This is the length in bytes of the string. 63 6f 6e 6e 65 63 74 This is the string. Note that there is no null terminator since the length is specified.  File: gnash_ref.info, Node: Authors, Next: GNU Free Documentation License, Prev: RTMP Protocol, Up: Top 3 Authors ********* Gnash is maintained by Rob Savoye. Other active developers are: Sandro Santilli, Bastiaan Jacques, Udo Giacomozzi, Chad Musick, Benjamin Wolsey, and Zou Lunkai. Please send all comments and suggestions to . Past and sometimes current developers are Tomas Groth and Markus Gothe. Gnash was initially derived from GameSWF. GameSWF is maintained by Thatcher Ulrich . The following people contributed to GameSWF: Mike Shaver, Thierry Berger-Perrin, Ignacio Castan~o, Willem Kokke, Vitaly Alexeev, Alexander Streit, and Rob Savoye.  File: gnash_ref.info, Node: GNU Free Documentation License, Prev: Authors, Up: Top Appendix A GNU Free Documentation License ***************************************** * Menu: * 0. PREAMBLE: 0_ PREAMBLE. * 1. APPLICABILITY AND DEFINITIONS: 1_ APPLICABILITY AND DEFINITIONS. * 2. VERBATIM COPYING: 2_ VERBATIM COPYING. * 3. COPYING IN QUANTITY: 3_ COPYING IN QUANTITY. * 4. MODIFICATIONS: 4_ MODIFICATIONS. * 5. COMBINING DOCUMENTS: 5_ COMBINING DOCUMENTS. * 6. COLLECTIONS OF DOCUMENTS: 6_ COLLECTIONS OF DOCUMENTS. * 7. AGGREGATION WITH INDEPENDENT WORKS: 7_ AGGREGATION WITH INDEPENDENT WORKS. * 8. TRANSLATION: 8_ TRANSLATION. * 9. TERMINATION: 9_ TERMINATION. * 10. FUTURE REVISIONS OF THIS LICENSE: 10_ FUTURE REVISIONS OF THIS LICENSE. * Addendum::  File: gnash_ref.info, Node: 0_ PREAMBLE, Next: 1_ APPLICABILITY AND DEFINITIONS, Up: GNU Free Documentation License A.1 0. PREAMBLE =============== The purpose of this License is to make a manual, textbook, or other written document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or non-commercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others. This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software. We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.  File: gnash_ref.info, Node: 1_ APPLICABILITY AND DEFINITIONS, Next: 2_ VERBATIM COPYING, Prev: 0_ PREAMBLE, Up: GNU Free Documentation License A.2 1. APPLICABILITY AND DEFINITIONS ==================================== This License applies to any manual or other work that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language. A "Secondary Section" is a named appendix or a front-matter section of the Document (*note fdl-document::) that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (For example, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them. The "Invariant Sections" are certain Secondary Sections (*note fdl-secondary::) whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document (*note fdl-document::) is released under this License. The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document (*note fdl-document::) is released under this License. A "Transparent" copy of the Document (*note fdl-document::) means a machine-readable copy, represented in a format whose specification is available to the general public, whose contents can be viewed and edited directly and straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup has been designed to thwart or discourage subsequent modification by readers is not Transparent. A copy that is not "Transparent" is called "Opaque". Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML designed for human modification. Opaque formats include PostScript, PDF, proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML produced by some word processors for output purposes only. The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.  File: gnash_ref.info, Node: 2_ VERBATIM COPYING, Next: 3_ COPYING IN QUANTITY, Prev: 1_ APPLICABILITY AND DEFINITIONS, Up: GNU Free Documentation License A.3 2. VERBATIM COPYING ======================= You may copy and distribute the Document (*note fdl-document::) in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3 (*note 3_ COPYING IN QUANTITY::). You may also lend copies, under the same conditions stated above, and you may publicly display copies.  File: gnash_ref.info, Node: 3_ COPYING IN QUANTITY, Next: 4_ MODIFICATIONS, Prev: 2_ VERBATIM COPYING, Up: GNU Free Documentation License A.4 3. COPYING IN QUANTITY ========================== If you publish printed copies of the Document (*note fdl-document::) numbering more than 100, and the Document's license notice requires Cover Texts (*note fdl-cover-texts::), you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document (*note fdl-document::) and satisfy these conditions, can be treated as verbatim copying in other respects. If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages. If you publish or distribute Opaque (*note fdl-transparent::) copies of the Document (*note fdl-document::) numbering more than 100, you must either include a machine-readable Transparent (*note fdl-transparent::) copy along with each Opaque copy, or state in or with each Opaque copy a publicly-accessible computer-network location containing a complete Transparent copy of the Document, free of added material, which the general network-using public has access to download anonymously at no charge using public-standard network protocols. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public. It is requested, but not required, that you contact the authors of the Document (*note fdl-document::) well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.  File: gnash_ref.info, Node: 4_ MODIFICATIONS, Next: 5_ COMBINING DOCUMENTS, Prev: 3_ COPYING IN QUANTITY, Up: GNU Free Documentation License A.5 4. MODIFICATIONS ==================== You may copy and distribute a Modified Version (*note fdl-modified::) of the Document (*note fdl-document::) under the conditions of sections 2 (*note 2_ VERBATIM COPYING::) and 3 (*note 3_ COPYING IN QUANTITY::) above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version: * *A. * Use in the Title Page (*note fdl-title-page::) (and on the covers, if any) a title distinct from that of the Document (*note fdl-document::), and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission. * *B. * List on the Title Page (*note fdl-title-page::), as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version (*note fdl-modified::), together with at least five of the principal authors of the Document (*note fdl-document::) (all of its principal authors, if it has less than five). * *C. * State on the Title Page (*note fdl-title-page::) the name of the publisher of the Modified Version (*note fdl-modified::), as the publisher. * *D. * Preserve all the copyright notices of the Document (*note fdl-document::). * *E. * Add an appropriate copyright notice for your modifications adjacent to the other copyright notices. * *F. * Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version (*note fdl-modified::) under the terms of this License, in the form shown in the Addendum below. * *G. * Preserve in that license notice the full lists of Invariant Sections (*note fdl-invariant::) and required Cover Texts (*note fdl-cover-texts::) given in the Document's (*note fdl-document::) license notice. * *H. * Include an unaltered copy of this License. * *I. * Preserve the section entitled "History", and its title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version (*note fdl-modified::)as given on the Title Page (*note fdl-title-page::). If there is no section entitled "History" in the Document (*note fdl-document::), create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence. * *J. * Preserve the network location, if any, given in the Document (*note fdl-document::) for public access to a Transparent (*note fdl-transparent::) copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission. * *K. * In any section entitled "Acknowledgements" or "Dedications", preserve the section's title, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein. * *L. * Preserve all the Invariant Sections (*note fdl-invariant::) of the Document (*note fdl-document::), unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles. * *M. * Delete any section entitled "Endorsements". Such a section may not be included in the Modified Version (*note fdl-modified::). * *N. * Do not retitle any existing section as "Endorsements" or to conflict in title with any Invariant Section (*note fdl-invariant::). If the Modified Version (*note fdl-modified::) includes new front-matter sections or appendices that qualify as Secondary Sections (*note fdl-secondary::) and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections (*note fdl-invariant::) in the Modified Version's license notice. These titles must be distinct from any other section titles. You may add a section entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version (*note fdl-modified::) by various parties-for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard. You may add a passage of up to five words as a Front-Cover Text (*note fdl-cover-texts::), and a passage of up to 25 words as a Back-Cover Text (*note fdl-cover-texts::), to the end of the list of Cover Texts (*note fdl-cover-texts::) in the Modified Version (*note fdl-modified::). Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document (*note fdl-document::) already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one. The author(s) and publisher(s) of the Document (*note fdl-document::) do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version (*note fdl-modified::).  File: gnash_ref.info, Node: 5_ COMBINING DOCUMENTS, Next: 6_ COLLECTIONS OF DOCUMENTS, Prev: 4_ MODIFICATIONS, Up: GNU Free Documentation License A.6 5. COMBINING DOCUMENTS ========================== You may combine the Document (*note fdl-document::) with other documents released under this License, under the terms defined in section 4 (*note 4_ MODIFICATIONS::) above for modified versions, provided that you include in the combination all of the Invariant Sections (*note fdl-invariant::) of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice. The combined work need only contain one copy of this License, and multiple identical Invariant Sections (*note fdl-invariant::) may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work. In the combination, you must combine any sections entitled "History" in the various original documents, forming one section entitled "History"; likewise combine any sections entitled "Acknowledgements", and any sections entitled "Dedications". You must delete all sections entitled "Endorsements."  File: gnash_ref.info, Node: 6_ COLLECTIONS OF DOCUMENTS, Next: 7_ AGGREGATION WITH INDEPENDENT WORKS, Prev: 5_ COMBINING DOCUMENTS, Up: GNU Free Documentation License A.7 6. COLLECTIONS OF DOCUMENTS =============================== You may make a collection consisting of the Document (*note fdl-document::) and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects. You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.  File: gnash_ref.info, Node: 7_ AGGREGATION WITH INDEPENDENT WORKS, Next: 8_ TRANSLATION, Prev: 6_ COLLECTIONS OF DOCUMENTS, Up: GNU Free Documentation License A.8 7. AGGREGATION WITH INDEPENDENT WORKS ========================================= A compilation of the Document (*note fdl-document::) or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, does not as a whole count as a Modified Version (*note fdl-modified::) of the Document, provided no compilation copyright is claimed for the compilation. Such a compilation is called an "aggregate", and this License does not apply to the other self-contained works thus compiled with the Document , on account of their being thus compiled, if they are not themselves derivative works of the Document. If the Cover Text (*note fdl-cover-texts::) requirement of section 3 (*note 3_ COPYING IN QUANTITY::) is applicable to these copies of the Document, then if the Document is less than one quarter of the entire aggregate, the Document's Cover Texts may be placed on covers that surround only the Document within the aggregate. Otherwise they must appear on covers around the whole aggregate.  File: gnash_ref.info, Node: 8_ TRANSLATION, Next: 9_ TERMINATION, Prev: 7_ AGGREGATION WITH INDEPENDENT WORKS, Up: GNU Free Documentation License A.9 8. TRANSLATION ================== Translation is considered a kind of modification, so you may distribute translations of the Document (*note fdl-document::) under the terms of section 4 (*note 4_ MODIFICATIONS::). Replacing Invariant Sections (*note fdl-invariant::) with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License provided that you also include the original English version of this License. In case of a disagreement between the translation and the original English version of this License, the original English version will prevail.  File: gnash_ref.info, Node: 9_ TERMINATION, Next: 10_ FUTURE REVISIONS OF THIS LICENSE, Prev: 8_ TRANSLATION, Up: GNU Free Documentation License A.10 9. TERMINATION =================== You may not copy, modify, sublicense, or distribute the Document (*note fdl-document::) except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.  File: gnash_ref.info, Node: 10_ FUTURE REVISIONS OF THIS LICENSE, Next: Addendum, Prev: 9_ TERMINATION, Up: GNU Free Documentation License A.11 10. FUTURE REVISIONS OF THIS LICENSE ========================================= The Free Software Foundation (http://www.gnu.org/fsf/fsf.html) may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/ (http://www.gnu.org/copyleft). Each version of the License is given a distinguishing version number. If the Document (*note fdl-document::) specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.  File: gnash_ref.info, Node: Addendum, Prev: 10_ FUTURE REVISIONS OF THIS LICENSE, Up: GNU Free Documentation License A.12 Addendum ============= To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page: Copyright 2008, Free Software Foundation. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with noInvariant Sections (*note fdl-invariant::), with no Front-Cover Texts (*note fdl-cover-texts::), and with no Back-Cover Texts (*note fdl-cover-texts::). A copy of the license is included in the section entitled "GNU Free Documentation License". If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License (http://www.gnu.org/copyleft/gpl.html), to permit their use in free software.  Tag Table: Node: Top175 Node: Introduction1113 Node: Audience1907 Node: What Is Supported ?2235 Node: RTMP Protocol4767 Node: AMF Format14538 Node: Authors15514 Node: GNU Free Documentation License16215 Node: 0_ PREAMBLE16978 Node: 1_ APPLICABILITY AND DEFINITIONS18284 Ref: fdl-document18509 Ref: fdl-modified18800 Ref: fdl-secondary18987 Ref: fdl-invariant19632 Ref: fdl-cover-texts19881 Ref: fdl-transparent20094 Ref: fdl-title-page21384 Node: 2_ VERBATIM COPYING21773 Node: 3_ COPYING IN QUANTITY22753 Node: 4_ MODIFICATIONS25110 Node: 5_ COMBINING DOCUMENTS31170 Node: 6_ COLLECTIONS OF DOCUMENTS32667 Node: 7_ AGGREGATION WITH INDEPENDENT WORKS33558 Node: 8_ TRANSLATION34786 Node: 9_ TERMINATION35689 Node: 10_ FUTURE REVISIONS OF THIS LICENSE36344 Node: Addendum37484  End Tag Table