Requirements
Prerequisite knowledge
You should have a basic understanding of media encoding concepts.
User level
Advanced
Preparing video files for playback on the Adobe Flash Platform is a relatively straightforward process. One detail that is often perplexing, however, is the moov atom. An atom is a self-contained data unit that contains information about the video file. The moov atom, also referred to as the movie atom, defines the timescale, duration, display characteristics of the movie, as well as subatoms containing information for each track in the movie. The optimal location of the moov atom depends on the selected delivery method. This article delves into the details around the moov atom, what data it contains, and how to move it to the proper location for your delivery method.
This article is targeted to anyone who is publishing H.264 video for delivery in Adobe Flash Player or Adobe AIR. It provides technical details about the metadata that can hamper good encoding and delivery, causing poor playback performance.
Delivering video
Four different methods are available for video delivery in Adobe Flash Player: progressive download, RTMP streaming, HTTP dynamic streaming, or P2P via RTMFP. Regardless of the method you choose, the experience for viewers is very similar. Your choice depends on your budget, the Flash Player version you require, and the level of content protection needed. The moov atom will be handled differently in each delivery method, as you'll see when I explain the details of container structure.
Progressive download
The progressive download method downloads and caches video on the viewer's computer. A short period of time is required to buffer and cache the beginning of the media file before it starts playing. Flash Player can calculate an appropriate buffer time based on the rate the data is being received and the total length of the video. Once the video has been cached, subsequent viewing does not require any buffering. Progressively downloaded files are generally delivered through a content delivery network (CDN) using the standard HTTP protocol. In this case, Flash Player establishes a direct HTTP connection with the CDN's servers to retrieve the content. Low-traffic progressive delivery can be served from your standard web server along with other website content.
RTMP streaming
The RTMP streaming method delivers the video bits in real time, as they are requested. The bits are viewed and then discarded. The user experience is virtually the same as with progressive download but has a few key differences:
- Viewers do not have to wait for video to download before seeking throughout the video.
- Video is not cached on the viewer's computer, so it cannot be viewed offline.
- Flash Player can deliver streaming video via the RTMP or RTMPE protocols supported by Adobe Flash Media Server.
HTTP dynamic streaming
Flash Player 10.1 introduced support for HTTP dynamic streaming—enabling an adaptive-bitrate, protected streaming experience with common HTTP servers, caching devices, and networks, using a standard MPEG-4 media format (also known as MP4). HTTP dynamic streaming shares some features with RTMP streaming:
- It supports both live and on demand delivery.
- It adjusts video quality to viewers' connection speed and processing power.
- Viewers do not have to wait for video to download before seeking throughout the video.
- Live DVR functionality is supported, enabling pausing and rewinding live streams.
Like standard progressive delivery, content is cached on the viewer's computer. Integration with Adobe Flash Access is available if content protection is desired.
Peer-assisted delivery via RTMFP
Peer-to-peer media delivery is supported in Flash Player 10.1 and later using the Real Time Media Flow Protocol (RTMFP). This enables Flash Player clients to share video, audio, and data through a direct connection, rather than through a server. This enables high-capacity delivery via multicast, as well as ultra-low-latency communication for applications such as VoIP, videoconferencing, and multiplayer games.
Note: Live streaming does not utilize the moov atom; therefore, this article will not address live streaming.
MPEG-4 stream packaging
For Flash Player to be able to play back an MPEG-4 (MP4) file, the file must be packaged in a specific type of container—one that follows the MPEG-4 Part 12 (ISO/IEC 14496-12) specification. Stream packaging is the process of making a multiplexed media file. Also known as muxing, this procedure combines multiple elements that enable control of the distribution delivery process into a single file. Some of these elements are represented in self-contained atoms. As I mentioned at the outset, an atom is a basic data unit that contains a header and a data field. The header contains referencing metadata that describes how to find, process, and access the contents of the data field, which may include (but is not limited to) the following components:
- Video frames
- Audio samples
- Interleaving AV data
- Captioning data
- Chapter index
- Title
- Poster
- User data
- Various technical metadata: codec, timescale, version, preferred playback rate, preferred playback volume, movie duration, etc.
In an MPEG-4–compliant container, every movie contains a moov atom. Normally, a movie atom contains a movie header atom (an mvhd atom) that defines the timescale and duration information for the entire movie, as well as its display characteristics. The movie atom also contains one track atom (a trak atom) for each track in the movie. Each track atom contains one or more media atoms (an mdia atom) along with other atoms that define other track and movie characteristics.
In this tree-like hierarchy, the moov atom acts an index of the video data. It is here that the MPEG-4 muxer stores information about the file to enable the viewer to play and scrub the file. The file will not start to play until the player can access this index.
Unless specified otherwise, the moov atom is normally stored at the end of the file in on-demand content, after all of the information describing the file has been generated. Depending on the type of on demand delivery method selected—progressive download, streaming, or local playback—the location will need to move either to the end or to the beginning of the file.
If the planned delivery method is progressive download or streaming (RTMP or HTTP), the moov atom will have to be moved to the beginning of the file. This ensures that the required movie information is downloaded first, enabling playback to start right away. If the moov atom is located at the end of the file, it forces the download of the entire file first before it will start playback. If the file is intended for local playback, then the location of the moov atom will not impact the start time, since the entire file is available for playback right away.
The placement of the moov atom is specified in various software packages through settings such as "progressive download," "fast start," "use streaming mode," or similar options. Software packages such as MP4creator or AtomicParsley enable you to analyze the location of the moov atom in your encoded files (Figures 1 and 2).
Some tools enable relocation of the moov atom to the beginning of the file's structure through post processing of the compressed MPEG-4 (MP4) file. One such tool is MP4Creator, mentioned earlier, and another is MP4 FastStart. The best way to handle the moov atom location, however, is to set it during the compression and muxing portion of the encoding process. This minimizes the probability of the moov atom inadvertently being placed at the end.
Importance of moov atom location
As I mentioned earlier, positioning the moov atom at the beginning of the file structure expedites the playback experience and access to the data payload for decoding and presentation by the client player. This is especially true for progressive delivery, where the moov atom data must be received before playback will begin.
However, another vital reason for having the moov atom at the beginning relates to the file, server, and CDN relationship in RTMP streaming. When the user requests a video asset via RTMP, Flash Media Server checks for availability of the asset on the local cache. If FMS does not locate the asset locally, it then requests the asset via a local service while leveraging HTTP cache hierarchy. This is a crucial point: initially, Flash Media Server requests a "range" at the beginning of the file to get the table of contents. If FMS sees that the metadata is stored at the end of the file, it then requests a range at the end of the file where metadata is stored, and then it requests the file from the beginning again. Since range requests are not cacheable, and because they can overlap, this process of back-and-forth requests may cause rebuffering. This is especially true if the user is watching video randomly or in small segments instead of the entire video from start to finish, as it's never cached in its entirety. Therefore, always encoding or muxing files with the moov atom at the beginning is recommended to avoid rebuffering caused by moov atom location.
Issues with edts atom handling
An edts atom contained in the trak atom of a moov atom located within an MP4 container hierarchy is responsible for tracking times and durations of the media. Flash Player architecture is designed to ignore the existence of an edts atom; however, an edts atom containing invalid or broken data may interfere with smooth and stable switching of HTTP packaged streams. Therefore, it is important to repair or remove an invalid edts atom prior to packaging the file for HTTP dynamic streaming.
The broken edts atom can be eliminated from a file using tools such as FLVCheck for file conformance, MP4Creator for structure analysis, and AtomicParsley for removal of metadata (see Figures 3 and 4).
The AtomicParsley command responsible for removing atoms is represented in the following string:
AtomicParsley.exe filename.mp4 --manualAtomRemove "moov.trak.edts" --manualAtomRemove "moov[2].trak.edts" --overWrite
Here, filename.mp4 is the name of the file being processed and--manualAtomRemoveis a command that initiates the removal of the specific atom, edts, which is hierarchically located within the trak atom, which is within the moov atom. If the file contains more than one trak atom, such as audio and video media elements, then the track number is added to the "moov.trak.edts" as shown above. By default, AtomicParsley removes the atom from the first moov atom track. Adding the next track number in sequence, or a track number of your choice, forces AtomicParsley to proceed to that atom number next (for example,moov[2].trak.edts). To edit all track numbers, repeat the command for each track. Adding the command string--overWriteoverwrites your original processed file.
Where to go from here
Many useful references and software tools are available to help you get a handle on the moov atom:
References
- MPEG-4 Standard Overview
- MPEG-4 Audio FAQ
- ISO base media file format (Wikipedia)
- QuickTime File Format Specification
- Adobe Flash Video File Format Specification
- Flash video (Wikipedia)
- Atoms within an MP4 compliant container (MultimediaWiki)
- MP4 Registration Authority
Tools
- AtomicParsley (command-line program for reading, parsing MPEG-4 files)
- FLVCheck (MPEG-4 checker)
- MP4Box (multimedia packager)
- MP4Creator (MPEG-4 file creater and modifier)
- MP4 FastStart (starts MPEG-4 progressive downloads immediately)
- QTIndexSwapper (starts H.264 progressive downloads immediately)
转自：https://www.adobe.com/devnet/video/articles/mp4_movie_atom.html