Multiplex communications – Pathfinding or routing – Switching a message which includes an address header
Reexamination Certificate
1998-08-25
2004-06-01
Hsu, Alpus H. (Department: 2665)
Multiplex communications
Pathfinding or routing
Switching a message which includes an address header
C370S474000, C370S477000, C345S215000, C709S231000
Reexamination Certificate
active
06744763
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to methods and apparatuses for preparing time related sequences of media data for transmission, and more particularly to packetized transmission of such media data.
INTRODUCTION AND BACKGROUND
There are various different file structures used today to store time-based media: audio formats such as AIFF, video formats such as AVI, and streaming formats such as RealMedia. One reason that such file structures are different is their different focus and applicability. Some of these formats are sufficiently relatively widely accepted, broad in their application, and somewhat simple to implement, and thus, may be used not only for content delivery but also as interchange formats. Foremost among these general formats is the QuickTime file format. It is used today in the majority of web sites serving time-based data; in the majority of authoring environments, including professional ones; and on the majority of multimedia CDROM titles.
The QuickTime media layer supports the efficient display and management of general multimedia data, with an emphasis on time-based material (video, audio, etc.). The media layer uses the QuickTime file format as the storage and interchange format for media information. The architectural capabilities of the layer are generally broader than the existing implementations, and the file format is capable of representing more information than is currently demanded by the existing QuickTime implementations.
In contrast to formats such as AVI, which were generally designed to support local random access of synchronized media, QuickTime allows systems to manage the data, relationships and timing of a general multimedia presentation. In particular, the QuickTime file format has structures to represent the temporal behavior of general time-based streams, a concept which covers the time-based emission of network packets, as well as the time-based local presentation of multimedia data.
The existing QuickTime file format is publicly described by Apple Computer in the May 1996 File format specification, which may be found at the QuickTime Web site, <http://.www.apple.com/quicktime>.
One aspect of the QuickTime file format is the concept that the physical structure of media data (the layout in disk records) is independent of, and described by, a logical structure for the file. The file is fully described by a set of “movie” meta-data. This meta-data provides declarative, structural and temporal information about the actual media data.
The media data may be in the same file as the description data, (the “movie” meta-data), or in other file(s). A movie structured into one file is commonly called “flat”, and is self-contained. Non-flat movies can be structured to reference some, or all, of the media data in other files.
As such, the format is generally suited for optimization in different applications. For example, when editing (compositing), data need not be rewritten as edits are applied and media is re-ordered; the meta-data file may be extended and temporal mapping information adjusted. When edits are complete, the relevant media data and meta-data may be rewritten into a single, interleaved, and optimized file for local or network access. Both the structured and the optimized files are valid QuickTime files, and both may be inspected, played, and reworked.
The use of structured (“non-flat”) files enables the same basic media data to be used and re-used in any number of presentations. This same advantage applies when serving, as will be seen below.
In both editing and serving, this also permits a number of other files to be treated as part of a movie without copying the media data. Thus editing and serving may be done directly from files such as Sun Microsystem's “au” audio format or the AVI video format, greatly extending the utility of these formats.
The QuickTime file is divided into a set of objects, called atoms. Each object starts with an atom header, which declares its'size and type:
class Atom {
int(32)
size;
char
type[4];
byte
contents[ ];
}
The size is in bytes, including the size and type header fields. The type field is four characters (usually printable), to permit easy documentation and identification. The data in an object after the type field may be fields, a sequence of contained objects, or both.
A file therefore is simply a sequence of objects:
class File {
Atom[ ];
}
The two important top-level objects are the media-data (mdat) and the meta-data (moov).
The media-data object(s) contain the actual media (for example, sequences of sound samples). Their format is not constrained by the file format; they are not usually objects. Their format is described in the meta-data, not by any declarations physically contiguous with them. So, for example, in a movie consisting solely of motion-JPEG, JPEG frames are stored contiguously in the media data with no intervening extra headers. The media data within the media data objects is logically divided into chunks; however, there are no explicit chunk markers within the media data.
When the QuickTime file references media data in other files, it is not required that these ‘secondary’ files be formatted according to the QuickTime specification, since such media data files may be formatted as if they were the contents of a media object. Since the QuickTime format does not necessarily require any headers or other information physically contiguous with the media data, it is possible for the media data to be files which contain ‘foreign’ headers (e.g. UNIX “.au” files, or AVI files) and for the QuickTime meta-data to contain the appropriate declarative information and reference the media data in the ‘foreign’ file. In this way the QuickTime file format can be used to update, without copying, existing bodies of material in disparate formats. The QuickTime file format is both an established format and is able to work with, include, and thereby bring forward, other established formats.
Free space (e.g. deleted by an editing operation) can also be described by an object. Software reading a file that includes free space objects should ignore such free space objects, as well as objects at any level which it does not understand. This permits extension of the file at virtually any level by introducing new objects.
The primary meta-data is the movie object. A QuickTime file has exactly one movie object which is typically at the beginning or end of the file, to permit its easy location:
class Movie {
int(32)
size;
char
type[4] = ‘moov’;
MovieHeader
mh;
contents
Atom[ ];
}
The movie header provides basic information about the overall presentation (its creation date, overall timescale, and so on). In the sequence of contained objects there is typically at least one track, which describes temporally presented data.
class Track {
int(32)
size;
char
type[4] = ‘trak’;
TrackHeader
th;
contents
Atom[ ];
}
The track header provides relatively basic information about the track (its ID, timescale, and so on). Objects contained in the track might be references to other tracks (e.g. for complex compositing), or edit lists. In this sequence of contained objects there may be a media object, which describes the media which is presented when the track is played.
The media object contains declarations relating to the presentation required by the track (e.g. that it is sampled audio, or MIDI, or orientation information for a 3Dscene). The type of track is declared by its handler:
class handler {
int(32)
size;
char
type[4] = ‘hdlr’;
int(8)
version;
bit(24)
flags;
char
handlertype[4]; -- mhlr for media handlers
char
handlersubtype[4]; -- vide for video, soun
for audio
char
manufacturer[4];
bit(32)
handlerflags;
bit(32)
handlerflagsmask;
string
componentname;
}
Within the media information there is likewise a handler declaration for the data handler (which fetches media data), and a data information
Geagan Jay
Gong Kevin L.
Jones Anne
Periyannan Alagu
Singer David W.
Apple Computer Inc.
Blakely , Sokoloff, Taylor & Zafman LLP
Hsu Alpus H.
LandOfFree
Method and apparatus for media data transmission does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for media data transmission, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for media data transmission will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3359148