Multimedia distribution system

Information

  • Patent Grant
  • 11735228
  • Patent Number
    11,735,228
  • Date Filed
    Friday, June 3, 2022
    2 years ago
  • Date Issued
    Tuesday, August 22, 2023
    a year ago
Abstract
A multimedia file and methods of generating, distributing and using the multimedia file are described. Multimedia files in accordance with embodiments of the present invention can contain multiple video tracks, multiple audio tracks, multiple subtitle tracks, a complete index that can be used to locate each data chunk in each of these tracks and an abridged index that can enable the location of a subset of the data chunks in each track, data that can be used to generate a menu interface to access the contents of the file and ‘meta data’ concerning the contents of the file. Multimedia files in accordance with several embodiments of the present invention also include references to video tracks, audio tracks, subtitle tracks and ‘meta data’ external to the file.
Description
BACKGROUND OF THE INVENTION

The present invention relates generally to encoding, transmission and decoding of multimedia files. More specifically, the invention relates to the encoding, transmission and decoding of multimedia files that can include tracks in addition to a single audio track and a single video track.


The development of the internet has prompted the development of file formats for multimedia information to enable standardized generation, distribution and display of multimedia information. Typically, a single multimedia file includes a single video track and a single audio track. When multimedia is written to a high volume and physically transportable medium, such as a CD-R multiple files can be used to provide a number of video tracks, audio tracks and subtitle tracks. Additional files can be provided containing information that can be used to generate an interactive menu.


SUMMARY OF THE INVENTION

Embodiments of the present invention include multimedia files and systems for generating, distributing and decoding multimedia files. In one aspect of the invention, the multimedia files include a plurality of encoded video tracks. In another aspect of the invention, the multimedia files include a plurality of encoded audio tracks. In another aspect of the invention, the multimedia files include at least one subtitle track. In another aspect of the invention, the multimedia files include encoded information indexing the audio, video and/or subtitle tracks.


In one embodiment, the invention includes a series of encoded video frames, a first index that includes information indicative of the location within the file and characteristics of each encoded video frame, a separate second index that includes information indicative of the location within the file of a subset of the encoded video frames.


In a further embodiment, the second index includes at least one tag that references an encoded video frame in the subset of encoded video frames and each tag includes the location within the file of the referenced encoded video frame and the frame number of the encoded video frame in the sequence of encoded video frames.


Another embodiment also includes at least one audio track. In addition, each tag further comprises a reference to a portion of at least one of the audio tracks and the portion of the track that is referenced accompanies the encoded video frame referenced by the tag.


In a still further embodiment, each tag further comprises a reference to information located within the first index and the information referenced in the first index is indicative of the location within the file and characteristics of the encoded video frame referenced by the tag.


Still another embodiment includes a processor and a memory including a file containing at least one sequence of encoded video frames. In addition, the processor is configured to generate an abridged index that references a subset of the encoded video frames in the sequence of encoded video frames.


In a yet further embodiment, the processor is configured to generate a complete index that references all of the encoded video frames in the sequence of encoded video frames and each reference to an encoded video frame in the abridged index includes a reference to the reference to that frame in the complete index.


In yet another embodiment, each reference to an encoded video frame in the abridged index includes the sequence number of the encoded video frame.


In further embodiment again, the processor is configured to include in each reference to an encoded video frame a reference to a location within at least one sound track.


Another embodiment again includes a processor and a memory containing a multimedia file. In addition, the multimedia file includes a sequence of encoded video frames, a complete index referencing each encoded video frame in the sequence of encoded video frames and an abridged index referencing a subset of the encoded video frames in the sequence of encoded video frames. Furthermore, the processor is configured to locate a particular encoded video frame within the multimedia file using the abridged index.


In a further additional embodiment, the processor is configured to locate reference information in the complete index using the abridged index.


In another additional embodiment, the multimedia file includes at least one audio track accompanying the sequence of encoded video frames and each reference to an encoded video frame in the abridged index includes a reference to a portion of at least one of the video tracks.


An embodiment of the method of the invention includes obtaining a sequence of encoded video frames, identifying a subset of frames from the sequence of encoded video frames and generating an abridged index that references the location within the multimedia file of each encoded video frame in the subset of encoded video frames.


In a further embodiment of the method of the invention, the generation of an abridged index further includes generating a reference to the location of each encoded video frame within the subset of encoded video frames and recording the sequence number of each encoded video frame within the subset of encoded video frames.


Another embodiment of the method of the invention also includes obtaining at least one audio track accompanying the sequence of encoded video frames. In addition, the generation of an abridged index further comprises associating with each referenced encoded video frame a reference to a location with at least one of the audio tracks.


A still further embodiment of the method of the invention also includes obtaining a complete index that includes a reference to each encoded video frame in the sequence of encoded video frames. In addition, the generation of an index further comprises associating with each referenced encoded video frame a reference to a location within the second index.


Still another embodiment of the method of the invention includes identifying a desired encoded video frame, determining the encoded video frame that is closest to the desired video frame in the second index and displaying an encoded video frame.


In a yet further embodiment of the method of the invention, each reference in the second index to an encoded video frame also includes a reference to the portion of the first index that refers to that encoded video frame, displaying an encoded video frame, further includes using the reference to the encoded video frame in the second index that is closest to the desired encoded video frame to locate that encoded frame within the first index, searching in the first index for the desired encoded video frame and displaying the desired encoded video frame.


In yet another embodiment of the method of the invention, the closest frame is the closest preceding frame in the sequence to the desired frame.


In a further additional embodiment of the invention, displaying an encoded video frame further includes displaying the encoded video frame that is determined to be closest to the desired video frame.





BRIEF DESCRIPTION OF THE DRAWINGS


FIG. 1. is a diagram of a system in accordance with an embodiment of the present invention for encoding, distributing and decoding files.



FIG. 2.0. is a diagram of the structure of a multimedia file in accordance with an embodiment of the present invention.



FIG. 2.0.1. is a diagram of the structure of a multimedia file in accordance with another embodiment of the present invention.



FIG. 2.1. is a conceptual diagram of a ‘hdrl’ list chunk in accordance with one embodiment of the invention.



FIG. 2.2. is a conceptual diagram of a ‘strl’ chunk in accordance with an embodiment of the invention.



FIG. 2.3. is a conceptual diagram of the memory allocated to store a ‘DXDT’ chunk of a multimedia file in accordance with an embodiment of the invention.



FIGS. 2.3.1A-2.3.1B. are a conceptual diagram of ‘meta data’ chunks that can be included in a ‘DXDT’ chunk of a multimedia file in accordance with an embodiment of the invention.



FIG. 2.3.2. is a conceptual diagram of an ‘index’ chunk that can be included in a ‘DXDT’ chunk of a multimedia file in accordance with an embodiment of the invention.



FIG. 2.4. is a conceptual diagram of the ‘DMNU’ chunk in accordance with an embodiment of the invention.



FIG. 2.5. is a conceptual diagram of menu chunks contained in a WowMenuManager chunk in accordance with an embodiment of the invention.



FIG. 2.6. is a conceptual diagram of menu chunks contained within a WowMenuManager chunk in accordance with another embodiment of the invention.



FIG. 2.6.1. is a conceptual diagram illustrating the relationships between the various chunks contained within a ‘DMNU’ chunk.



FIG. 2.7. is a conceptual diagram of the ‘movi’ list chunk of a multimedia file in accordance with an embodiment of the invention.



FIG. 2.8. is a conceptual diagram of the ‘movi’ list chunk of a multimedia file in accordance with an embodiment of the invention that includes DRM.



FIG. 2.9. is a conceptual diagram of the ‘DRM’ chunk in accordance with an embodiment of the invention.



FIG. 3.0. is a block diagram of a system for generating a multimedia file in accordance with an embodiment of the invention.



FIG. 3.1. is a block diagram of a system to generate a ‘DXDT’ chunk in accordance with an embodiment of the invention.



FIG. 3.2. is a block diagram of a system to generate a ‘DMNU’ chunk in accordance with an embodiment of the invention.



FIG. 3.3. is a conceptual diagram of a media model in accordance with an embodiment of the invention.



FIG. 3.3.1. is a conceptual diagram of objects from a media model that can be used to automatically generate a small menu in accordance with an embodiment of the invention.



FIG. 3.4. is a flowchart of a process that can be used to re-chunk audio in accordance with an embodiment of the invention.



FIG. 3.5. is a block diagram of a video encoder in accordance with an embodiment of the present.



FIG. 3.6. is a flowchart of a method of performing smoothness psychovisual enhancement on an I frame in accordance with embodiments of the invention.



FIG. 3.7. is a flowchart of a process for performing a macroblock SAD psychovisual enhancement in accordance with an embodiment of the invention.



FIG. 3.8. is a flowchart of a process for one pass rate control in accordance with an embodiment of the invention.



FIG. 3.9. is a flowchart of a process for performing Nth pass VBV rate control in accordance with an embodiment of the invention.



FIG. 4.0. is a flowchart for a process for locating the required multimedia information from a multimedia file and displaying the multimedia information in accordance with an embodiment of the invention.



FIG. 4.0.1. is a flowchart showing a process for locating a specific encoded video frame within a multimedia file using an ‘index’ chunk in accordance with an embodiment of the invention.



FIG. 4.0.2. is a flowchart showing a process for locating the ‘tag’ chunk within an ‘index’ chunk that references the preceding frame closest to a desired video frame within a video sequence in accordance with an embodiment of the invention.



FIG. 4.1. is a block diagram of a decoder in accordance with an embodiment of the invention.



FIG. 4.2. is an example of a menu displayed in accordance with an embodiment of the invention.



FIG. 4.3. is a conceptual diagram showing the sources of information used to generate the display shown in FIG. 4.2 in accordance with an embodiment of the invention.





DETAILED DESCRIPTION OF THE INVENTION

Referring to the drawings, embodiments of the present invention are capable of encoding, transmitting and decoding multimedia files. Multimedia files in accordance with embodiments of the present invention can contain multiple video tracks, multiple audio tracks, multiple subtitle tracks, a complete index that can be used to locate each data chunk in each of the tracks and an abridged index that can be used to locate a subset of the data chunks in each track, data that can be used to generate a menu interface to access the contents of the file and ‘meta data’ concerning the contents of the file. Multimedia files in accordance with several embodiments of the present invention also include references to video tracks, audio tracks, subtitle tracks and ‘meta data’ external to the file.


1. Description of System


Turning now to FIG. 1, a system in accordance with an embodiment of the present invention for encoding, distributing and decoding files is shown. The system 10 includes a computer 12, which is connected to a variety of other computing devices via a network 14. Devices that can be connected to the network include a server 16, a consumer electronics (CE) device 17, a lap-top computer 18 and a personal digital assistant (PDA) 20. In various embodiments, the connections between the devices and the network can be either wired or wireless and implemented using any of a variety of networking protocols.


In operation, the computer 12 can be used to encode multimedia files in accordance with an embodiment of the present invention. The computer 12 can also be used to decode multimedia files in accordance with embodiments of the present invention and distribute multimedia files in accordance with embodiments of the present invention. The computer can distribute files using any of a variety of file transfer protocols including via a peer-to-peer network. In addition, the computer 12 can transfer multimedia files in accordance with embodiments of the present invention to a server 18, where the files can be accessed by other devices. The other devices can include any variety of computing device or even a dedicated decoder device. In the illustrated embodiment, a set-top cable box, a lap-top computer and a PDA are shown. In other embodiments, various types of digital set-top boxes, desk-top computers, game machines, CE devices and other devices can be connected to the network, download the multimedia files and decode them.


In one embodiment, the devices access the multimedia files from the server via the network. In other embodiments, the devices access the multimedia files from a number of computers via a peer-to-peer network. In several embodiments, multimedia files can be written to a portable storage device such as a disk drive, CD-ROM or DVD. In many embodiments, electronic devices can access multimedia files written to portable storage devices.


2. Description of File Structure


Multimedia files in accordance with embodiments of the present invention can be structured to be compliant with the Resource Interchange File Format (‘RIFF file format’), defined by Microsoft Corporation of Redmond, Wash. and International Business Machines Corporation of Armonk, N.Y. RIFF is a file format for storing multimedia data and associated information. A RIFF file typically has an 8-byte RIFF header, which identifies the file and provides the residual length of the file after the header (i.e. file_length−8). The entire remainder of the RIFF file comprises “chunks” and “lists.” Each chunk has an 8-byte chunk header identifying the type of chunk, and giving the length in bytes of the data following the chunk header. Each list has an 8-byte list header identifying the type of list and giving the length in bytes of the data following the list header. The data in a list comprises chunks and/or other lists (which in turn may comprise chunks and/or other lists). RIFF lists are also sometimes referred to as “list chunks.”


An AVI file is a special form of RIFF file that follow the format of a RIFF file, but include various chunks and lists with defined identifiers that contain multimedia data in particular formats. The AVI format was developed and defined by Microsoft Corporation. AVI files are typically created using a encoder that can output multimedia data in the AVI format. AVI files are typically decoded by any of a group of software collectively known as AVI decoders.


The RIFF and AVI formats are flexible in that they only define chunks and lists that are part of the defined file format, but allow files to also include lists and/or chunks that are outside the RIFF and/or AVI file format definitions without rendering the file unreadable by a RIFF and/or AVI decoder. In practice, AVI (and similarly RIFF) decoders are implemented so that they simply ignore lists and chunks that contain header information not found in the AVI file format definition. The AVI decoder must still read through these non-AVI chunks and lists and so the operation of the AVI decoder may be slowed, but otherwise, they generally have no effect on and are ignored by an AVI decoder.


A multimedia file in accordance with an embodiment of the present invention is illustrated in FIG. 2.0. The illustrated multimedia file 30 includes a character set chunk (‘CSET’ chunk) 32, an information list chunk (‘INFO’ list chunk) 34, a file header chunk (‘hdrl’ list chunk) 36, a meta data chunk (‘DXDT’ chunk) 38, a menu chunk (‘DMNU’ chunk) 40, a junk chunk (‘junk’ chunk) 41, the movie list chunk (‘movi’ list chunk) 42, an optional index chunk (‘idx1’ chunk) 44 and a second menu chunk (‘DMNU’ chunk) 46. Some of these chunks and portions of others are defined in the AVI file format while others are not contained in the AVI file format. In many, but not all, cases, the discussion below identifies chunks or portions of chunks that are defined as part of the AVI file format.


Another multimedia file in accordance with an embodiment of the present invention is shown in FIG. 2.0.1. The multimedia file 30′ is similar to that shown in FIG. 2.0. except that the file includes multiple concatenated ‘RIFF’ chunks. The ‘RIFF’ chunks can contain a ‘RIFF’ chunk similar to that shown in FIG. 2.0. that can exclude the second ‘DMNU’ chunk 46 or can contain menu information in the form of a ‘DMNU’ chunk 46′.


In the illustrated embodiment, the multimedia file 30′ includes multiple concatenated ‘RIFF’ chunks, where the first ‘RIFF’ chunk 50 includes a character set chunk (‘CSET’ chunk) 32′, an information list chunk (‘INFO’ list chunk) 34′, a file header chunk (‘hdrl’ list chunk) 36′, a meta data chunk (‘DXDT’ chunk) 38′, a menu chunk (‘DMNU’ chunk) 40′, a junk chunk (‘junk’ chunk) 41′, the movie list chunk (‘movi’ list chunk) 42′ and an optional index chunk (‘idx1’ chunk) 44′. The second ‘RIFF’ chunk 52 contains a second menu chunk (‘DMNU’ chunk) 46′. Additional ‘RIFF’ chunks 54 containing additional titles can be included after the ‘RIFF’ menu chunk 52. The additional ‘RIFF’ chunks can contain independent media in compliant AVI file format. In one embodiment, the second menu chunk 46′ and the additional ‘RIFF’ chunks have specialized 4 character codes (defined in the AVI format and discussed below) such that the first two characters of the 4 character codes appear as the second two characters and the second two characters of the 4 character codes appear as the first two characters.


2.1. The ‘CSET’ Chunk


The ‘CSET’ chunk 32 is a chunk defined in the Audio Video Interleave file format (AVI file format), created by Microsoft Corporation. The ‘CSET’ chunk defines the character set and language information of the multimedia file. Inclusion of a ‘CSET’ chunk in accordance with embodiments of the present invention is optional.


A multimedia file in accordance with one embodiment of the present invention does not use the ‘CSET’ chunk and uses UTF-8, which is defined by the Unicode Consortium, for the character set by default combined with RFC 3066 Language Specification, which is defined by Internet Engineering Task Force for the language information.


2.2. The ‘INFO’ List Chunk


The ‘INFO’ list chunk 34 can store information that helps identify the contents of the multimedia file. The ‘INFO’ list is defined in the AVI file format and its inclusion in a multimedia file in accordance with embodiments of the present invention is optional. Many embodiments that include a ‘DXDT’ chunk do not include an ‘INFO’ list chunk.


2.3. The ‘hdrl’ List Chunk


The ‘hdrl’ list chunk 38 is defined in the AVI file format and provides information concerning the format of the data in the multimedia file. Inclusion of a ‘hdrl’ list chunk or a chunk containing similar description information is generally required. The ‘hdrl’ list chunk includes a chunk for each video track, each audio track and each subtitle track.


A conceptual diagram of a ‘hdrl’ list chunk 38 in accordance with one embodiment of the invention that includes a single video track 62, two audio tracks 64, an external audio track 66, two subtitle tracks 68 and an external subtitle track 70 is illustrated in FIG. 2.1. The ‘hdrl’ list 60 includes an ‘avih’ chunk. The ‘avih’ chunk 60 contains global information for the entire file, such as the number of streams within the file and the width and height of the video contained in the multimedia file. The ‘avih’ chunk can be implemented in accordance with the AVI file format.


In addition to the ‘avih’ chunk, the ‘hdrl’ list includes a stream descriptor list for each audio, video and subtitle track. In one embodiment, the stream descriptor list is implemented using ‘strl’ chunks. A ‘strl’ chunk in accordance with an embodiment of the present invention is illustrated in FIG. 2.2. Each ‘strl’ chunk serves to describe each track in the multimedia file. The ‘strl’ chunks for the audio, video and subtitle tracks within the multimedia file include a ‘strl’ chunk that references a ‘strh’ chunk 92, a ‘strf’ chunk 94, a ‘strd’ chunk 96 and a ‘strn’ chunk 98. All of these chunks can be implemented in accordance with the AVI file format. Of particular interest is the ‘strh’ chunk 92, which specifies the type of media track, and the ‘strd’ chunk 96, which can be modified to indicate whether the video is protected by digital rights management. A discussion of various implementations of digital rights management in accordance with embodiments of the present invention is provided below.


Multimedia files in accordance with embodiments of the present invention can contain references to external files holding multimedia information such as an additional audio track or an additional subtitle track. The references to these tracks can either be contained in the ‘hdrl’ chunk or in the ‘junk’ chunk 41. In either case, the reference can be contained in the ‘strh’ chunk 92 of a ‘strl’ chunk 90, which references either a local file or a file stored remotely. The referenced file can be a standard AVI file or a multimedia file in accordance with an embodiment of the present invention containing the additional track.


In additional embodiments, the referenced file can contain any of the chunks that can be present in the referencing file including ‘DMNU’ chunks, ‘DXDT’ chunks and chunks associated with audio, video and/or subtitle tracks for a multimedia presentation. For example, a first multimedia file could include a ‘DMNU’ chunk (discussed in more detail below) that references a first multimedia presentation located within the ‘movi’ list chunk of the first multimedia file and a second multimedia presentation within the ‘movi’ list chunk of a second multimedia file. Alternatively, both ‘movi’ list chunks can be included in the same multimedia file, which need not be the same file as the file in which the ‘DMNU’ chunk is located.


2.4. The ‘DXDT’ Chunk


The ‘DXDT’ chunk 38 contains so called ‘meta data’. ‘Meta data’ is a term used to describe data that provides information about the contents of a file, document or broadcast. The ‘meta data’ stored within the ‘DXDT’ chunk of multimedia files in accordance with embodiments of the present invention can be used to store such content specific information as title, author, copyright holder and cast. In addition, technical details about the codec used to encode the multimedia file can be provided such as the CLI options used and the quantizer distribution after each pass.


In one embodiment, the meta data is represented within the ‘DXDT’ chunk as a series of statements, where each statement includes a subject, a predicate, an object and an authority. The subject is a reference to what is being described. The subject can reference a file, item, person or organization. The subject can reference anything having characteristics capable of description. The predicate identifies a characteristic of the subject that is being described. The object is a description of the identified characteristic of the subject and the authority identifies the source of the information.


The following is a table showing an example of how various pieces of ‘meta data’, can be represented as an object, a predicate, a subject and an authority:









TABLE 1







Conceptual representation of ‘meta data’










Subject
Predicate
Object
Authority





_:file281
http://purl.org/
‘Movie Title’
_:auth42



dc/elements/1.





1/title




_:file281
http://xmlns.di
_:cast871
_:auth42



vxnetworks.co





m/2004/11/cas





t#Person




_:file281
http://xmlns.di
_:cast872
_:auth42



vxnetworks.co





m/2004/11/cas





t#Person




_:file281
http://xmlns.di
_:cast873
_:auth42



vxnetworks.co





m/2004/11/cas





t#Person




_:cast871
http://xmlns.di
‘Actor 1’
_:auth42



vxnetworks.co





m/2004/11/cas





t#name




_:cast871
http://xmlns.di
Actor
_:auth42



vxnetworks.co





m/2004/11/cas





t#role




_:cast871
http://xmlns.di
‘Character Name 1’
_:auth42



vxnetworks.co





m/2004/11/cas





t#character




_:cast282
http://xmlns.di
‘Director 1’
_:auth42



vxnetworks.co





m/2004/11/cas





t#name




_:cast282
http://xmlns.di
Director
_:auth42



vxnetworks.co





m/2004/11/cas





t#role




_:cast283
http://xmlns.di
‘Director 2’
_:auth42



vxnetworks.co





m/2004/11/cas





t#name




_:cast283
http://xmlns.di
Director
_:auth42



vxnetworks.co





m/2004/11/cas





t#role




_:file281
http://purl.org/
Copyright 1998 ‘Studio Name’.
_:auth42



dc/elements/1.
A11 Rights Reserved.




1/rights




_:file281
Series
_:file321
_:auth42


_:file321
Episode
2
_:auth42


_:file321
http://purl.org/
‘Movie Title 2’
_:auth42



dc/elements/1.





1/title




_:file321
Series
_file1 22
_:auth42


_:file122
Episode
3
_:auth42


_:file122
http://purl.org/
‘Movie Title 3’
_:auth42



dc/elements/1.





1/title




_auth42
http://xmlns.co
_:foaf92
_:auth42



m/foaf/0.l/Org





anization




_:foaf92
http://xmlns.co
‘Studio Name’
_:auth42



m/foaf/0.1/na





me




_:file281
http://xm11ns.d
_:track#dc00
_:auth42



ivxnetworks.c





om/2004/11/tr





ack#track




_:track#dc00
http://xmlns.di
1024x768
_:auth42



vxnetworks.co





m/2004/11/tra





ck#re solution




_:file281
http://xmlns.di
HT
_:auth42



vxnetworks.co





m/2004/11/con





tent#certificati





onLevel




_:track#dc00
http://xmlns.di
32, 1, 3, 5
_:auth42



vxnetworks.co





m/2004/11/tra





ck#frameType





Dist




_:track#dc00
http://xmlns.di
bv1276-psy0-key 300-b1-sc
_:auth42



vxnetworks.co
50-pq5-vbv




m/2004/11/tra
6951200,3145728,2359296-




ck#codecSetti
profile3-nf




ngs









In one embodiment, the expression of the subject, predicate, object and authority is implemented using binary representations of the data, which can be considered to form Directed-Labeled Graphs (DLGs). A DLG consists of nodes that are either resources or literals. Resources are identifiers, which can either be conformant to a naming convention such as a Universal Resource Identifier (“URI”) as defined in RFC 2396 by the Internet Engineering Taskforce (http://www.ietf.org/rfc/rfc2396.txt) or refer to data specific to the system itself. Literals are representations of an actual value, rather than a reference.


An advantage of DLGs is that they allow the inclusion of a flexible number of items of data that are of the same type, such as cast members of a movie. In the example shown in Table 1, three cast members are included. However, any number of cast members can be included. DLGs also allow relational connections to other data types. In Table 1, there is a ‘meta data’ item that has a subject “_:file281,” a predicate “Series,” and an object “_:file321.” The subject “_:file281” indicates that the ‘meta data’ refers to the content of the file referenced as “_:file321” (in this case, a movie—“Movie Title 1”). The predicate is “Series,” indicating that the object will have information about another movie in the series to which the first movie belongs. However, “_:file321” is not the title or any other specific information about the series, but rather a reference to another entry that provides more information about “_:file321”. The next ‘meta data’ entry, with the subject “_:file321”, however, includes data about “_:file321,” namely that the Title as specified by the Dublin Core Vocabulary as indicated by “http://purl.org/dc/elements/1.1/title” of this sequel is “Movie Title 2.”


Additional ‘meta data’ statements in Table 1 specify that “Actor 1” was a member of the cast playing the role of “Character Name 1” and that there are two directors. Technical information is also expressed in the ‘meta data.’ The ‘meta data’ statements identify that “_:file281” includes track “_:track#dc00.” The ‘meta data’ provides information including the resolution of the video track, the certification level of the video track and the codec settings. Although not shown in Table 1, the ‘meta data’ can also include a unique identifier assigned to a track at the time of encoding. When unique identifiers are used, encoding the same content multiple times will result in a different identifier for each encoded version of the content. However, a copy of the encoded video track would retain the identifier of the track from which it was copied.


The entries shown in Table 1 can be substituted with other vocabularies such as the UPnP vocabulary, which is defined by the UPnP forum (see http://www.upnpforum.org). Another alternative would be the Digital Item Declaration Language (DIDL) or DIDL-Lite vocabularies developed by the International Standards Organization as part of work towards the MPEG-21 standard. The following are examples of predicates within the UPnP vocabulary:


urn:schemas-upnp-org:metadata-1-0/upnp/artist


urn:schemas-upnp-org:metadata-1-0/upnp/actor


urn:schemas-upnp-org:metadata-1-0/upnp/author


urn:schemas-upnp-org:metadata-1-0/upnp/producer


urn:schemas-upnp-org:metadata-1-0/upnp/director


urn:schemas-upnp-org:metadata-1-0/upnp/genre


urn:schemas-upnp-org:metadata-1-0/upnp/album


urn:schemas-upnp-org:metadata-1-0/upnp/playlist


urn:schemas-upnp-org:metadata-1-0/upnp/originalTrackNumber


urn:schemas-upnp-org:metadata-1-0/upnp/userAnnotation


The authority for all of the ‘meta data’ is ‘_:auth42.’ ‘Meta data’ statements show that ‘_:auth42’ is ‘Studio Name.’ The authority enables the evaluation of both the quality of the file and the ‘meta data’ statements associated with the file.


Nodes into a graph are connected via named resource nodes. A statement of ‘meta data’ consist of a subject node, a predicate node and an object node. Optionally, an authority node can be connected to the DLG as part of the ‘meta data’ statement.


For each node, there are certain characteristics that help further explain the functionality of the node. The possible types can be represented as follows using the ANSI C programming language:















/** Invalid Type */



#define RDF_IDENTIFIER_TYPE_UNKNOWN
0 × 00


/** Resource URI rdf:about */



#define RDF_IDENTIFIER_TYPE_RESOURCE
0 × 01


/** rdf:NodeId, _:file or generated N-Triples */



#define RDF_IDENTIFIER_TYPE_ANONYMOUS
0 × 02


/** Predicate URI */



#define RDF_IDENTIFIER_TYPE_PREDICATE
0 × 03


/** rdf:li, rdf:_<n> */



#define RDF_IDENTIFIER_TYPE_ORDINAL
0 × 04


/** Authority URI */



#define RDF_IDENTIFIER_TYPE_AUTHORITY
0 × 05


/** UTF-8 formatted literal */



#define RDF_IDENTIFIER_TYPE_LITERAL
0 × 06


/** Literal Integer */



#define RDF_IDENTIFIER_TYPE_INT
0 × 07







/** Literal XML data */








#define RDF_IDENTIFIER_TYPE_XML_LITERAL
0 × 08










An example of a data structure (represented in the ANSI C programming language) that represents the ‘meta data’ chunks contained within the ‘DXDT’ chunk is as follows:
















typedef struct RDFDataStruct



{










 RDFHeader
Header;



 uint32_t
numOfStatements;



 RDFStatement
 statements[RDF_MAX_STATEMENTS];









} RDFData;









The ‘RDFData’ chunk includes a chunk referred to as an ‘RDFHeader’ chunk, a value ‘numOfStatements’ and a list of ‘RDFStatement’ chunks.


The ‘RDFHeader’ chunk contains information about the manner in which the ‘meta data’ is formatted in the chunk. In one embodiment, the data in the ‘RDFHeader’ chunk can be represented as follows (represented in ANSI C):
















typedef struct RDFHeaderStruct










{




 uint16_t
versionMajor;



 uint16_t
versionMinor;



 uint16_t
versionFix;



 uint16_t
numOfSchemas;



 RDFSchema
 schemas[RDF_MAX_SCHEMAS];



} RDFHeader;









The ‘RDFHeader’ chunk includes a number ‘version’ that indicates the version of the resource description format to enable forward compatibility. The header includes a second number ‘numOfSchemas’ that represents the number of ‘RDFSchema’ chunks in the list ‘schemas’, which also forms part of the ‘RDFHeader’ chunk. In several embodiments, the ‘RDFSchema’ chunks are used to enable complex resources to be represented more efficiently. In one embodiment, the data contained in a ‘RDFSchema’ chunk can be represented as follows (represented in ANSI C):
















typedef struct RDFSchemaStruct










{




 wchar_t*
prefix;



 wchar_t*
uri;



} RDFSchema;









The ‘RDFSchema’ chunk includes a first string of text such as ‘dc’ identified as ‘prefix’ and a second string of text such as ‘http://purl.org/dc/elements/1.1/’ identified as ‘uri’. The ‘prefix’ defines a term that can be used in the ‘meta data’ in place of the ‘uri’. The ‘uri’ is a Universal Resource Identifier, which can conform to a specified standardized vocabulary or be a specific vocabulary to a particular system.


Returning to the discussion of the ‘RDFData’ chunk. In addition to a ‘RDFHeader’ chunk, the ‘RDFData’ chunk also includes a value ‘numOfStatements’ and a list ‘statement’ of ‘RDFStatement’ chunks. The value ‘numOfStatements’ indicates the actual number of ‘RDFStatement’ chunks in the list ‘statements’ that contain information. In one embodiment, the data contained in the ‘RDFStatement’ chunk can be represented as follows (represented in ANSI C):

















typedef struct RDFStatementStruct




{




 RDFSubject 
subject;



 RDFPredicate
 predicate;



 RDFObject 
object;



 RDFAuthority
 authority;



} RDFStatement;









Each ‘RDFStatement’ chunk contains a piece of ‘meta data’ concerning the multimedia file. The chunks ‘subject’, ‘predicate’, ‘object’ and ‘authority’ are used to contain the various components of the ‘meta data’ described above.


The ‘subject’ is a ‘RDFSubject’ chunk, which represents the subject portion of the ‘meta data’ described above. In one embodiment the data contained within the ‘RDFSubject’ chunk can be represented as follows (represented in ANSI C):
















typedef struct RDFSubjectStruct










{




 uint16_t
type;



 wchar_t*
value;









} RDFSubject;









The ‘RDFSubject’ chunk shown above includes a value ‘type’ that indicates that the data is either a Resource or an anonymous node of a piece of ‘meta data’ and a unicode text string ‘value’, which contains data representing the subject of the piece of ‘meta data’. In embodiments where an ‘RDFSchema’ chunk has been defined the value can be a defined term instead of a direct reference to a resource.


The ‘predicate’ in a ‘RDFStatement’ chunk is a ‘RDFPredicate’ chunk, which represents the predicate portion of a piece of ‘meta data’. In one embodiment the data contained within a ‘RDFPredicate’ chunk can be represented as follows (represented in ANSI C):
















typedef struct RDFPredicateStruct










{




 uint16_t
type;



 wchar_t*
value;



} RDFPredicate;









The ‘RDFPredicate’ chunk shown above includes a value ‘type’ that indicates that the data is the predicate URI or an ordinal list entry of a piece of ‘meta data’ and a text string ‘value,’ which contains data representing the predicate of a piece of ‘meta data.’ In embodiments where an ‘RDFSchema’ chunk has been defined the value can be a defined term instead of a direct reference to a resource.


The ‘object’ in a ‘RDFStatement’ chunk is a ‘RDFObject’ chunk, which represents the object portion of a piece of ‘meta data.’ In one embodiment, the data contained in the ‘RDFObject’ chunk can be represented as follows (represented in ANSI C):
















typedef struct RDFObjectStruct










{




 uint16_t
type;



 wchar_t*
language;



 wchar_t*
dataTypeURI;



 wchar_t*
value;



} RDFObject;









The ‘RDFObject’ chunk shown above includes a value ‘type’ that indicates that the piece of data is a UTF-8 literal string, a literal integer or literal XML data of a piece of ‘meta data.’ The chunk also includes three values. The first value ‘Language’ is used to represent the language in which the piece of ‘meta data’ is expressed (e.g. a film's title may vary in different languages). In several embodiments, a standard representation can be used to identify the language (such as RFC 3066—Tags for the Identification of Languages specified by the Internet Engineering Task Force, see http://www.ietf.org/rfc/rfc3066.txt). The second value ‘dataTypeURI’ is used to indicate the type of data that is contained within the ‘value’ field if it can not be explicitly indicated by the ‘type’ field. The URI specified by the dataTypeURI points to general RDF URI Vocabulary used to describe the particular type of the Data is used. Different formats in which the URI can be expressed are described at http://www.w3.org/TR/rdf-concepts/#section-Datatypes. In one embodiment, the ‘value’ is a ‘wide character.’ In other embodiments, the ‘value’ can be any of a variety of types of data from a single bit, to an image or a video sequence. The ‘value’ contains the object piece of the ‘meta data.’


The ‘authority’ in a ‘RDFStatement’ chunk is a ‘RDFAuthority’ chunk, which represents the authority portion of a piece of ‘meta data.’ In one embodiment the data contained within the ‘RDFAuthority’ chunk can be represented as follows (represented in ANSI C):

















typedef struct RDFAuthorityStruct




{




 uint16_t
type;



 wchar_t*
value;



} RDFAuthority;









The ‘RDFAuthority’ data structure shown above includes a value ‘type’ that indicates the data is a Resource or an anonymous node of a piece of ‘meta data.’ The ‘value’ contains the data representing the authority for the ‘meta data.’ In embodiments where an ‘RDFSchema’ chunk has been defined the value can be a defined term instead of a direct reference to a resource.


A conceptual representation of the storage of a ‘DXDT’ chunk of a multimedia file in accordance with an embodiment of the present invention is shown in FIG. 2.3. The ‘DXDT’ chunk 38 includes an ‘RDFHeader’ chunk 110, a ‘numOfStatements’ value 112 and a list of RDFStatement chunks 114. The RDFHeader chunk 110 includes a ‘version’ value 116, a ‘numOfSchemas’ value 118 and a list of ‘Schema’ chunks 120. Each ‘RDFStatement’ chunk 114 includes a ‘RDFSubject’ chunk 122, a ‘RDFPredicate’ chunk 124, a ‘RDFObject’ chunk 126 and a ‘RDFAuthority’ chunk 128. The ‘RDFSubject’ chunk includes a ‘type’ value 130 and a ‘value’ value 132. The ‘RDFPredicate’ chunk 124 also includes a ‘type’ value 134 and a ‘value’ value 136. The ‘RDFObject’ chunk 126 includes a ‘type’ value 138, a ‘Language’ value 140 (shown in the figure as ‘lang’), a ‘dataTypeURI’ value 142 (shown in the figure as ‘dataT’) and a ‘value’ value 144. The ‘RDFAuthority’ chunk 128 includes a ‘type’ value 146 and a ‘value’ value 148. Although the illustrated ‘DXDT’ chunk is shown as including a single ‘Schema’ chunk and a single ‘RDFStatement’ chunk, one of ordinary skill in the art will readily appreciate that different numbers of ‘Schema’ chunks and ‘RDFStatement’ chunks can be used in a chunk that describes ‘meta data.’


As is discussed below, multimedia files in accordance with embodiments of the present invention can be continuously modified and updated. Determining in advance the ‘meta data’ to associate with the file itself and the ‘meta data’ to access remotely (e.g. via the internet) can be difficult. Typically, sufficient ‘meta data’ is contained within a multimedia file in accordance with an embodiment of the present invention in order to describe the contents of the file. Additional information can be obtained if the device reviewing the file is capable of accessing via a network other devices containing ‘meta data’ referenced from within the file.


The methods of representing ‘meta data’ described above can be extendable and can provide the ability to add and remove different ‘meta data’ fields stored within the file as the need for it changes over time. In addition, the representation of ‘meta data’ can be forward compatible between revisions.


The structured manner in which ‘meta data’ is represented in accordance with embodiments of the present invention enables devices to query the multimedia file to better determine its contents. The query could then be used to update the contents of the multimedia file, to obtain additional ‘meta data’ concerning the multimedia file, generate a menu relating to the contents of the file or perform any other function involving the automatic processing of data represented in a standard format. In addition, defining the length of each parseable element of the ‘meta data’ can increase the ease with which devices with limited amounts of memory, such as consumer electronics devices, can access the ‘meta data’.


In other embodiments, the ‘meta data’ is represented using individual chunks for each piece of ‘meta data.’ Several ‘DXDT’ chunks in accordance with the present invention include a binary chunk containing ‘meta data’ encoded as described above and additional chunks containing individual pieces of ‘meta data’ formatted either as described above or in another format. In embodiments where binary ‘meta data’ is included in the ‘DXDT’ chunk, the binary ‘meta data’ can be represented using 64-bit encoded ASCII. In other embodiments, other binary representations can be used.


Examples of individual chunks that can be included in the ‘DXDT’ chunk in accordance with the present invention are illustrated in FIGS. 2.3.1A-2.3.1B. The ‘meta data’ includes a ‘MetaData’ chunk 150 that can contain a PixelAspectRatioMetaData′ chunk 152a, an ‘EncoderURIMetaData’ chunk 152b, a ‘CodecSettingsMetaData’ chunk 152c, a ‘FrameTypeMetaData’ chunk 152d, a VideoResolutionMetaData′ chunk 152e, a PublisherMetaData′ chunk 152f, a ‘CreatorMetaData’ chunk 152g, a ‘GenreMetaData’ chunk 152h, a ‘CreatorToolMetaData’ chunk 152i, a RightsMetaData′ chunk 152j, a ‘RunTimeMetaData’ chunk 152k, a ‘QuantizerMetaData’ chunk 152l, a ‘CodecInfoMetaData’ chunk 152m, a ‘EncoderNameMetaData’ chunk 152n, a ‘FrameRateMetaData’ chunk 152o, a ‘InputSourceMetaData’ chunk 152p, a ‘FilelDMetaData’ chunk 152q, a ‘TypeMetaData’ chunk 152r, a ‘TitleMetaData’ chunk 152s and/or a ‘CertLevelMetaData’ chunk 152t.


The ‘PixelAspectRatioMetaData’ chunk 152a includes information concerning the pixel aspect ratio of the encoded video. The ‘EncoderURIMetaData’ chunk 152b includes information concerning the encoder. The ‘CodecSettingsMetaData’ chunk 152c includes information concerning the settings of the codec used to encode the video. The ‘FrameTypeMetaData’ chunk 152d includes information concerning the video frames. The VideoResolutionMetaData′ chunk 152e includes information concerning the video resolution of the encoded video. The PublisherMetaData′ chunk 152f includes information concerning the person or organization that published the media. The ‘CreatorMetaData’ chunk 152g includes information concerning the creator of the content. The ‘GenreMetaData’ chunk 152h includes information concerning the genre of the media. The ‘CreatorToolMetaData’ chunk 152i includes information concerning the tool used to create the file. The RightsMetaData′ chunk 152j includes information concerning DRM. The RunTimeMetaData′ chunk 152k includes information concerning the run time of the media. The ‘QuantizerMetaData’ chunk 152l includes information concerning the quantizer used to encode the video. The ‘CodecInfoMetaData’ chunk 152m includes information concerning the codec. The EncoderNameMetaData′ chunk 152n includes information concerning the name of the encoder. The FrameRateMetaData′ chunk 152o includes information concerning the frame rate of the media. The ‘InputSourceMetaData’ chunk 152p includes information concerning the input source. The ‘FilelDMetaData’ chunk 152q includes a unique identifier for the file. The ‘TypeMetaData’ chunk 152r includes information concerning the type of the multimedia file. The ‘TitleMetaData’ chunk 152s includes the title of the media and the ‘CertLevelMetaData’ chunk 152t includes information concerning the certification level of the media. In other embodiments, additional chunks can be included that contain additional ‘meta data.’ In several embodiments, a chunk containing ‘meta data’ in a binary format as described above can be included within the ‘MetaData’ chunk. In one embodiment, the chunk of binary ‘meta data’ is encoded as 64-bit ASCII.


2.4.1. The ‘Index’ Chunk


In one embodiment, the ‘DXDT’ chunk can include an ‘index’ chunk that can be used to index ‘data’ chunks in the ‘movi’ list chunk 42 corresponding to specific frames in a sequence of encoded video (the ‘movi’ list chunk is discussed further below). The ‘index’ chunk can be differentiated from the ‘idx1’ chunk on the basis that the ‘index’ chunk does not include information concerning every ‘data’ chunk in the ‘movi’ list chunk. Typically, the ‘index’ chunk includes information concerning a subset of the ‘data’ chunks. Appropriate selection of the ‘data’ chunks referenced in the ‘index’ chunk can enable rapid location of a specific video frame.


An embodiment of an ‘index’ chunk in accordance with the present invention is shown in FIG. 2.3.2. The ‘index’ chunk 153 includes a list of ‘tag’ chunks 154. In many embodiments, each ‘tag’ chunk 154 contains information that can be used to locate a particular encoded frame of video within a multimedia file. In several embodiments, ‘tag’ chunks reference encoded video frames that are approximately evenly spaced throughout a sequence of encoded video frames. In one embodiment, the list of ‘tag’ chunks references frames that are spaced at least ten seconds apart. In another embodiments, the ‘tag’ chunks reference frames that are spaced at least five seconds apart. In a further embodiment, the list of ‘tag’ chunks references frames that are spaced at least one second apart. In numerous embodiments, the ‘tag’ chunks reference frames that are spaced approximately evenly with respect to the bits in the multimedia file or ‘movi’ list chunk. In many embodiments, ‘tag’ chunks are used to identify frames that are the start of specific scenes and/or chapters within a sequence of video frames. In many embodiments, the ‘index’ chunk includes a distinct fourcc code such as “idxx”.


In the illustrated embodiment, each ‘tag’ chunk 154 includes information that can be used to reference a specific encoded video frame and the portions of one or more audio tracks that accompany the encoded video frame. The information includes information concerning a chunk offset 155a, information concerning an index offset 155b, information identifying a video frame 155c and information identifying a portion of an audio track 155d.


In many embodiments, the chunk offset 155a can be used to locate the ‘data’ chunks within the multimedia file corresponding to the particular encoded video frame and/or accompanying audio track(s) referenced by the ‘tag’ chunk. In one embodiment, the chunk offset is the location of the relevant ‘data’ chunk relative to the start of the ‘movi’ list chunk.


In many embodiments, the index offset 155b can be used to locate information about a particular video frame in the ‘idx1’ chunk. In one embodiment, the index offset 155b is the location of the relevant piece of information relative to the beginning of the ‘idx1’ chunk.


The information identifying the video frame 155c designates the position of the encoded video frame referenced by the ‘tag’ chunk within a sequence of encoded video frames. In one embodiment, the information 155c can simply be an integer indicating a frame number in a sequence of encoded video frames. In other embodiments, other information indicative of the position of the encoded video frame referenced by the ‘tag’ chunk within the video sequence can be used.


In many embodiments, the information identifying a portion of an audio track 155d references a specific section of an audio track. In several embodiments, the identified section corresponds to the portion of a soundtrack that accompanies the encoded video frame referenced by the ‘tag’ chunk. In embodiments where there are multiple audio tracks, the information identifying a portion of an audio track 155d can in fact include multiple pieces of information capable of referencing sections within each of the multiple audio tracks. In many embodiments, the sections identified by the multiple pieces of information correspond to the portion of each sound track that accompanies an encoded video frame referenced by the ‘tag’ chunk.


In many embodiments of ‘tag’ chunks in accordance with the present invention, various pieces of information are used to identify the ‘data’ chunk within a multimedia file corresponding to a specific encoded video frame. In addition, various types of information can be used to identify portions of audio and subtitle tracks that accompany an encoded video frame. In several embodiments, at least some of the ‘tag’ chunks in an ‘index’ chunk reference a portion of an audio track and do not reference an encoded video frame.


Including a chunk containing index information before the ‘movi’ list chunk can enable a device to start playing and performing other functions, such as fast forward, rewind and scene skipping, prior to the downloading of the ‘idx1’ chunk. In one embodiment, the ‘index’ chunk is included in a chunk other than the ‘DXDT’ chunk preceding the ‘movi’ list chunk (e.g. the junk chunk). In other embodiments, the ‘index’ chunk is not located within the ‘junk’ chunk. In several embodiments, the ‘index’ chunk is a separate chunk. In one embodiment, the ‘index’ chunk is located after the ‘movi’ list chunk.


2.5. The ‘DMNU’ Chunks


Referring to FIGS. 2.0. and 2.0.1., a first ‘DMNU’ chunk 40 (40′) and a second ‘DMNU’ chunk 46 (46′) are shown. In FIG. 2.0. the second ‘DMNU’ chunk 46 forms part of the multimedia file 30. In the embodiment illustrated in FIG. 2.0.1., the ‘DMNU’ chunk 46′ is contained within a separate RIFF chunk. In both instances, the first and second ‘DMNU’ chunks contain data that can be used to display navigable menus. In one embodiment, the first ‘DMNU’ chunk 40 (40′) contains data that can be used to create a simple menu that does not include advanced features such as extended background animations. In addition, the second ‘DMNU’ chunk 46 (46′) includes data that can be used to create a more complex menu including such advanced features as an extended animated background.


The ability to provide a so-called ‘lite’ menu can be useful for consumer electronics devices that cannot process the amounts of data required for more sophisticated menu systems. Providing a menu (whether ‘lite’ or otherwise) prior to the ‘movi’ list chunk 42 can reduce delays when playing embodiments of multimedia files in accordance with the present invention in streaming or progressive download applications. In several embodiments, providing a simple and a complex menu can enable a device to choose the menu that it wishes to display. Placing the smaller of the two menus before the ‘movi’ list chunk 42 enables devices in accordance with embodiments of the present invention that cannot display menus to rapidly skip over information that cannot be displayed.


In other embodiments, the data required to create a single menu is split between the first and second ‘DMNU’ chunks. Alternatively, the ‘DMNU’ chunk can be a single chunk before the ‘movi’ chunk containing data for a single set of menus or multiple sets of menus. In other embodiments, the ‘DMNU’ chunk can be a single or multiple chunks located in other locations throughout the multimedia file.


In several multimedia files in accordance with the present invention, the first ‘DMNU’ chunk 40 (40′) can be automatically generated based on a ‘richer’ menu in the second ‘DMNU’ chunk 46 (46′). The automatic generation of menus is discussed in greater detail below.


The structure of a ‘DMNU’ chunk in accordance with an embodiment of the present invention is shown in FIG. 2.4. The ‘DMNU’ chunk 158 is a list chunk that contains a menu chunk 160 and an ‘MRIF’ chunk 162. The menu chunk contains the information necessary to construct and navigate through the menus. The ‘MRIF’ chunk contains media information that can be used to provide subtitles, background video and background audio to the menus. In several embodiments, the ‘DMNU’ chunk contains menu information enabling the display of menus in several different languages.


In one embodiment, the ‘WowMenu’ chunk 160 contains the hierarchy of menu chunk objects that are conceptually illustrated in FIG. 2.5. At the top of the hierarchy is the WowMenuManager chunk 170. The WowMenuManager chunk can contain one or more ‘LanguageMenus’ chunks 172 and one ‘Media’ chunk 174.


Use of ‘LanguageMenus’ chunks 172 enables the ‘DMNU’ chunk 158 to contain menu information in different languages. Each ‘LanguageMenus’ chunk 172 contains the information used to generate a complete set of menus in a specified language. Therefore, the ‘LanguageMenus’ chunk includes an identifier that identifies the language of the information associated with the ‘LanguageMenus’ chunk. The ‘LanguageMenus’ chunk also includes a list of ‘WowMenu’ chunks 175.


Each ‘WowMenu’ chunk 175 contains all of the information to be displayed on the screen for a particular menu. This information can include background video and audio. The information can also include data concerning button actions that can be used to access other menus or to exit the menu and commence displaying a portion of the multimedia file. In one embodiment, the ‘WowMenu’ chunk 175 includes a list of references to media. These references refer to information contained in the ‘Media’ chunk 174, which will be discussed further below. The references to media can define the background video and background audio for a menu. The ‘WowMenu’ chunk 175 also defines an overlay that can be used to highlight a specific button, when a menu is first accessed.


In addition, each ‘WowMenu’ chunk 175 includes a number of ‘ButtonMenu’ chunks 176. Each ‘ButtonMenu’ chunk defines the properties of an onscreen button. The ‘ButtonMenu’ chunk can describe such things as the overlay to use when the button is highlighted by the user, the name of the button and what to do in response to various actions performed by a user navigating through the menu. The responses to actions are defined by referencing an ‘Action’ chunk 178. A single action, e.g. selecting a button, can result in several ‘Action’ chunks being accessed. In embodiments where the user is capable of interacting with the menu using a device such as a mouse that enables an on-screen pointer to move around the display in an unconstrained manner, the on-screen location of the buttons can be defined using a ‘MenuRectangle’ chunk 180. Knowledge of the on-screen location of the button enables a system to determine whether a user is selecting a button, when using a free ranging input device.


Each ‘Action’ chunk identifies one or more of a number of different varieties of action related chunks, which can include a ‘PlayAction’ chunk 182, a ‘MenuTransitionAction’ chunk 184, a ‘ReturnToPlayAction’ chunk 186, an ‘AudioSelectAction’ chunk 188, a ‘SubtitileSelectAction’ chunk 190 and a ‘ButtonTransitionAction’ chunk 191. A ‘PlayAction’ chunk 182 identifies a portion of each of the video, audio and subtitle tracks within a multimedia file. The ‘PlayAction’ chunk references a portion of the video track using a reference to a ‘MediaTrack’ chunk (see discussion below). The ‘PlayAction’ chunk identifies audio and subtitle tracks using ‘SubtitleTrack’ 192 and ‘AudioTrack’ 194 chunks. The ‘SubtitleTrack’ and ‘AudioTrack’ chunks both contain references to a ‘MediaTrack’ chunk 198. When a ‘PlayAction’ chunk forms the basis of an action in accordance with embodiments of the present invention, the audio and subtitle tracks that are selected are determined by the values of variables set initially as defaults and then potentially modified by a user's interactions with the menu.


Each ‘MenuTransitionAction’ chunk 184 contains a reference to a ‘WowMenu’ chunk 175. This reference can be used to obtain information to transition to and display another menu.


Each ‘ReturnToPlayAction’ chunk 186 contains information enabling a player to return to a portion of the multimedia file that was being accessed prior to the user bringing up a menu.


Each ‘AudioSelectAction’ chunk 188 contains information that can be used to select a particular audio track. In one embodiment, the audio track is selected from audio tracks contained within a multimedia file in accordance with an embodiment of the present invention. In other embodiments, the audio track can be located in an externally referenced file.


Each ‘SubtitleSelectAction’ chunk 190 contains information that can be used to select a particular subtitle track. In one embodiment, the subtitle track is selected from a subtitle contained within a multimedia file in accordance with an embodiment of the present invention. In other embodiments, the subtitle track can be located in an externally referenced file.


Each ‘ButtonTransitionAction’ chunk 191 contains information that can be used to transition to another button in the same menu. This is performed after other actions associated with a button have been performed.


The ‘Media’ chunk 174 includes a number of ‘MediaSource’ chunks 166 and ‘MediaTrack’ chunks 198. The ‘Media’ chunk defines all of the multimedia tracks (e.g., audio, video, subtitle) used by the feature and the menu system. Each ‘MediaSource’ chunk 196 identifies a RIFF chunk within the multimedia file in accordance with an embodiment of the present invention, which, in turn, can include multiple RIFF chunks.


Each ‘MediaTrack’ chunk 198 identifies a portion of a multimedia track within a RIFF chunk specified by a ‘MediaSource’ chunk.


The ‘MRIF’ chunk 162 is, essentially, its own small multimedia file that complies with the RIFF format. The ‘MRIF’ chunk contains audio, video and subtitle tracks that can be used to provide background audio and video and overlays for menus. The ‘MRIF’ chunk can also contain video to be used as overlays to indicate highlighted menu buttons. In embodiments where less menu data is required, the background video can be a still frame (a variation of the AVI format) or a small sequence of identical frames. In other embodiments, more elaborate sequences of video can be used to provide the background video.


As discussed above, the various chunks that form part of a ‘WowMenu’ chunk 175 and the ‘WowMenu’ chunk itself contain references to actual media tracks. Each of these references is typically to a media track defined in the ‘hdrl’ LIST chunk of a RIFF chunk.


Other chunks that can be used to create a ‘DMNU’ chunk in accordance with the present invention are shown in FIG. 2.6. The ‘DMNU’ chunk includes a ‘WowMenuManager chunk 170’. The WowMenuManager chunk 170′ can contain at least one ‘LanguageMenus’ chunk 172′, at least one ‘Media’ chunk 174′ and at least one ‘TranslationTable’ chunk 200.


The contents of the ‘LanguageMenus’ chunk 172′ is largely similar to that of the ‘LanguageMenus’ chunk 172 illustrated in FIG. 2.5. The main difference is that the ‘PlayAction’ chunk 182′ does not contain ‘SubtitleTrack’ chunks 192 and ‘AudioTrack’ chunks 194.


The ‘Media’ chunk 174′ is significantly different from the ‘Media’ chunk 174 shown in FIG. 2.5. The ‘Media’ chunk 174′ contains at least one ‘Title’ chunk 202 and at least one ‘MenuTracks’ chunk 204. The ‘Title’ chunk refers to a title within the multimedia file. As discussed above, multimedia files in accordance with embodiments of the present invention can include more than one title (e.g. multiple episodes in a television series, a related series of full length features or simply a selection of different features). The ‘MenuTracks’ chunk 204 contains information concerning media information that is used to create a menu display and the audio soundtrack and subtitles accompanying the display.


The ‘Title’ chunk can contain at least one ‘Chapter’ chunk 206. The ‘Chapter’ chunk 206 references a scene within a particular title. The ‘Chapter’ chunk 206 contains references to the portions of the video track, each audio track and each subtitle track that correspond to the scene indicated by the ‘Chapter’ chunk. In one embodiment, the references are implemented using ‘MediaSource’ chunks 196′ and ‘MediaTrack’ chunks 198′ similar to those described above in relation to FIG. 2.5. In several embodiments, a ‘MediaTrack’ chunk references the appropriate portion of the video track and a number of additional ‘MediaTrack’ chunks each reference one of the audio tracks or subtitle tracks. In one embodiment, all of the audio tracks and subtitle tracks corresponding to a particular video track are referenced using separate ‘MediaTrack’ chunks.


As described above, the ‘MenuTracks’ chunks 204 contain references to the media that are used to generate the audio, video and overlay media of the menus. In one embodiment, the references to the media information are made using ‘MediaSource’ chunks 196′ and ‘MediaTrack’ chunks 198′ contained within the ‘MenuTracks’ chunk. In one embodiment, the ‘MediaSource’ chunks 196′ and ‘MediaTrack’ chunks 198′ are implemented in the manner described above in relation to FIG. 2.5.


The ‘TranslationTable’ chunk 200 can be used to contain text strings describing each title and chapter in a variety of languages. In one embodiment, the ‘TranslationTable’ chunk 200 includes at least one ‘TranslationLookup’ chunk 208. Each ‘TranslationLookup’ chunk 208 is associated with a ‘Title’ chunk 202, a ‘Chapter’ chunk 206 or a ‘MediaTrack’ chunk 196′ and contains a number of ‘Translation’ chunks 210. Each of the ‘Translation’ chunks in a ‘TranslationLookup’ chunk contains a text string that describes the chunk associated with the ‘TranslationLookup’ chunk in a language indicated by the ‘Translation’ chunk.


A diagram conceptually illustrating the relationships between the various chunks contained within a ‘DMNU’ chunk is illustrated in FIG. 2.6.1. The figure shows the containment of one chunk by another chunk using a solid arrow. The direction in which the arrow points indicates the chunk contained by the chunk from which the arrow originates. References by one chunk to another chunk are indicated by a dashed line, where the referenced chunk is indicated by the dashed arrow.


2.6. The ‘Junk’ Chunk


The ‘junk’ chunk 41 is an optional chunk that can be included in multimedia files in accordance with embodiments of the present invention. The nature of the ‘junk’ chunk is specified in the AVI file format.


2.7. The ‘Movi’ List Chunk


The ‘movi’ list chunk 42 contains a number of ‘data’ chunks. Examples of information that ‘data’ chunks can contain are audio, video or subtitle data. In one embodiment, the ‘movi’ list chunk includes data for at least one video track, multiple audio tracks and multiple subtitle tracks.


The interleaving of ‘data’ chunks in the ‘movi’ list chunk 42 of a multimedia file containing a video track, three audio tracks and three subtitle tracks is illustrated in FIG. 2.7. For convenience sake, a ‘data’ chunk containing video will be described as a ‘video’ chunk, a ‘data’ chunk containing audio will be referred to as an ‘audio’ chunk and a ‘data’ chunk containing subtitles will be referenced as a ‘subtitle’ chunk. In the illustrated ‘movi’ list chunk 42, each ‘video’ chunk 262 is separated from the next ‘video’ chunk by ‘audio’ chunks 264 from each of the audio tracks. In several embodiments, the ‘audio’ chunks contain the portion of the audio track corresponding to the portion of video contained in the ‘video’ chunk following the ‘audio’ chunk.


Adjacent ‘video’ chunks may also be separated by one or more ‘subtitle’ chunks 266 from one of the subtitle tracks. In one embodiment, the ‘subtitle’ chunk 266 includes a subtitle and a start time and a stop time. In several embodiments, the ‘subtitle’ chunk is interleaved in the ‘movi’ list chunk such that the ‘video’ chunk following the ‘subtitle’ chunk includes the portion of video that occurs at the start time of the subtitle. In other embodiments, the start time of all ‘subtitle’ and ‘audio’ chunks is ahead of the equivalent start time of the video. In one embodiment, the ‘audio’ and ‘subtitle’ chunks can be placed within 5 seconds of the corresponding ‘video’ chunk and in other embodiments the ‘audio’ and ‘subtitle’ chunks can be placed within a time related to the amount of video capable of being buffered by a device capable of displaying the audio and video within the file.


In one embodiment, the ‘data’ chunks include a ‘FOURCC’ code to identify the stream to which the ‘data’ chunk belongs. The ‘FOURCC’ code consists of a two-digit stream number followed by a two-character code that defines the type of information in the chunk. An alternate ‘FOURCC’ code consists of a two-character code that defines the type of information in the chunk followed by the two-digit stream number. Examples of the two-character code are shown in the following table:









TABLE 2







Selected two-character codes used in FOURCC codes










Two-character code
Description







db
Uncompressed video frame



de
Compressed video frame



dd
DRM key info for the video frame



pc
Palette change



wb
Audio data



st
Subtitle (text mode)



sb
Subtitle (bitmap mode)



ch
Chapter










In one embodiment, the structure of the ‘video’ chunks 262 and ‘audio’ chunks 264 complies with the AVI file format. In other embodiments, other formats for the chunks can be used that specify the nature of the media and contain the encoded media.


In several embodiments, the data contained within a ‘subtitle’ chunk 266 can be represented as follows:



















typedef struct_subtitlechunk {




 FOURCC fee;




 DWORD cb;




 STR duration;




 STR subtitle;




} SUBTITLECHUNK;










The value ‘fcc’ is the FOURCC code that indicates the subtitle track and nature of the subtitle track (text or bitmap mode). The value ‘cb’ specifies the size of the structure. The value ‘duration’ specifies the time at the starting and ending point of the subtitle. In one embodiment, it can be in the form hh:mm:ss.xxx-hh:mm:ss.xxx. The hh represent the hours, mm the minutes, ss the seconds and xxx the milliseconds. The value ‘subtitle’ contains either the Unicode text of the subtitle in text mode or a bitmap image of the subtitle in the bitmap mode. Several embodiments of the present invention use compressed bitmap images to represent the subtitle information. In one embodiment, the ‘subtitle’ field contains information concerning the width, height and onscreen position of the subtitle. In addition, the ‘subtitle’ field can also contain color information and the actual pixels of the bit map. In several embodiments, run length coding is used to reduce the amount of pixel information required to represent the bitmap.


Multimedia files in accordance with embodiments of the present invention can include digital rights management. This information can be used in video on demand applications. Multimedia files that are protected by digital rights management can only be played back correctly on a player that has been granted the specific right of playback. In one embodiment, the fact that a track is protected by digital rights management can be indicated in the information about the track in the ‘hdrl’ list chunk (see description above). A multimedia file in accordance with an embodiment of the present invention that includes a track protected by digital rights management can also contain information about the digital rights management in the ‘movi’ list chunk.


A ‘movi’ list chunk of a multimedia file in accordance with an embodiment of the present invention that includes a video track, multiple audio tracks, at least one subtitle track and information enabling digital rights management is illustrated in FIG. 2.8. The ‘movi’ list chunk 42′ is similar to the ‘movi’ list chunk shown in FIG. 2.7. with the addition of a DRM′ chunk 270 prior to each video chunk 262′. The DRM′ chunks 270 are ‘data’ chunks that contain digital rights management information, which can be identified by a FOURCC code ‘nndd’. The first two characters ‘nn’ refer to the track number and the second two characters are ‘dd’ to signify that the chunk contains digital rights management information. In one embodiment, the DRM′ chunk 270 provides the digital rights management information for the ‘video’ chunk 262′ following the DRM′ chunk. A device attempting to play the digital rights management protected video track uses the information in the DRM′ chunk to decode the video information in the ‘video’ chunk. Typically, the absence of a DRM′ chunk before a ‘video’ chunk is interpreted as meaning that the ‘video’ chunk is unprotected.


In an encryption system in accordance with an embodiment of the present invention, the video chunks are only partially encrypted. Where partial encryption is used, the DRM′ chunks contain a reference to the portion of a ‘video’ chunk that is encrypted and a reference to the key that can be used to decrypt the encrypted portion. The decryption keys can be located in a DRM′ header, which is part of the ‘strd’ chunk (see description above). The decryption keys are scrambled and encrypted with a master key. The DRM′ header also contains information identifying the master key.


A conceptual representation of the information in a DRM′ chunk is shown in FIG. 2.9. The DRM′ chunk 270 can include a ‘frame’ value 280, a ‘status’ value 282, an ‘offset’ value 284, a ‘number’ value 286 and a ‘key’ value 288. The ‘frame’ value can be used to reference the encrypted frame of video. The ‘status’ value can be used to indicate whether the frame is encrypted, the ‘offset’ value 284 points to the start of the encrypted block within the frame and the ‘number’ value 286 indicates the number of encrypted bytes in the block. The ‘key’ value 288 references the decryption key that can be used to decrypt the block.


2.8. The ‘Idx1’ Chunk


The ‘idx1’ chunk 44 is an optional chunk that can be used to index the ‘data’ chunks in the ‘movi’ list chunk 42. In one embodiment, the ‘idx1’ chunk can be implemented as specified in the AVI format. In other embodiments, the ‘idx1’ chunk can be implemented using data structures that reference the location within the file of each of the ‘data’ chunks in the ‘movi’ list chunk. In several embodiments, the ‘idx1’ chunk identifies each ‘data’ chunk by the track number of the data and the type of the data. The FOURCC codes referred to above can be used for this purpose.


3. Encoding a Multimedia File


Embodiments of the present invention can be used to generate multimedia files in a number of ways. In one instance, systems in accordance with embodiments of the present invention can generate multimedia files from files containing separate video tracks, audio tracks and subtitle tracks. In such instances, other information such as menu information and ‘meta data’ can be authored and inserted into the file.


Other systems in accordance with embodiments of the present invention can be used to extract information from a number of files and author a single multimedia file in accordance with an embodiment of the present invention. Where a CD-R is the initial source of the information, systems in accordance with embodiments of the present invention can use a codec to obtain greater compression and can re-chunk the audio so that the audio chunks correspond to the video chunks in the newly created multimedia file. In addition, any menu information in the CD-R can be parsed and used to generate menu information included in the multimedia file.


Other embodiments can generate a new multimedia file by adding additional content to an existing multimedia file in accordance with an embodiment of the present invention. An example of adding additional content would be to add an additional audio track to the file such as an audio track containing commentary (e.g. director's comments, after-created narrative of a vacation video). The additional audio track information interleaved into the multimedia file could also be accompanied by a modification of the menu information in the multimedia file to enable the playing of the new audio track.


3.1. Generation Using Stored Data Tracks


A system in accordance with an embodiment of the present invention for generating a multimedia file is illustrated in FIG. 3.0. The main component of the system 350 is the interleaver 352. The interleaver receives chunks of information and interleaves them to create a multimedia file in accordance with an embodiment of the present invention in the format described above. The interleaver also receives information concerning ‘meta data’ from a meta data manager 354. The interleaver outputs a multimedia file in accordance with embodiments of the present invention to a storage device 356.


Typically the chunks provided to the interleaver are stored on a storage device. In several embodiments, all of the chunks are stored on the same storage device. In other embodiments, the chunks may be provided to the interleaver from a variety of storage devices or generated and provided to the interleaver in real time.


In the embodiment illustrated in FIG. 3.0, the ‘DMNU’ chunk 358 and the ‘DXDT’ chunk 360 have already been generated and are stored on storage devices. The video source 362 is stored on a storage device and is decoded using a video decoder 364 and then encoded using a video encoder 366 to generate a ‘video’ chunk. The audio sources 368 are also stored on storage devices. Audio chunks are generated by decoding the audio source using an audio decoder 370 and then encoding the decoded audio using an audio encoder 372. ‘Subtitle’ chunks are generated from text subtitles 374 stored on a storage device. The subtitles are provided to a first transcoder 376, which converts any of a number of subtitle formats into a raw bitmap format. In one embodiment, the stored subtitle format can be a format such as SRT, SUB or SSA. In addition, the bitmap format can be that of a four bit bitmap including a color palette look-up table. The color palette look-up table includes a 24 bit color depth identification for each of the sixteen possible four bit color codes. A single multimedia file can include more than one color palette look-up table (see “pc” palette FOURCC code in Table 2 above). The four bit bitmap thus allows each menu to have 16 different simultaneous colors taken from a palette of 16 million colors. In alternative embodiments different numbers of bit per pixel and different color depths are used. The output of the first transcoder 376 is provided to a second transcoder 378, which compresses the bitmap. In one embodiment run length coding is used to compress the bitmap. In other embodiments, other suitable compression formats are used.


In one embodiment, the interfaces between the various encoders, decoder and transcoders conform with Direct Show standards specified by Microsoft Corporation. In other embodiments, the software used to perform the encoding, decoding and transcoding need not comply with such standards.


In the illustrated embodiment, separate processing components are shown for each media source. In other embodiments resources can be shared. For example, a single audio decoder and audio encoder could be used to generate audio chunks from all of the sources. Typically, the entire system can be implemented on a computer using software and connected to a storage device such as a hard disk drive.


In order to utilize the interleaver in the manner described above, the ‘DMNU’ chunk, the ‘DXDT’ chunk, the ‘video’ chunks, the ‘audio’ chunks and the ‘subtitle’ chunks in accordance with embodiments of the present invention must be generated and provided to the interleaver. The process of generating each of the various chunks in a multimedia file in accordance with an embodiment of the present invention is discussed in greater detail below.


3.2. Generating a ‘DXDT’ Chunk


The ‘DXDT’ chunk can be generated in any of a number of ways. In one embodiment, ‘meta data’ is entered into data structures via a graphical user interface and then parsed into a ‘DXDT’ chunk. In one embodiment, the ‘meta data’ is expressed as series of subject, predicate, object and authority statements. In another embodiment, the ‘meta data’ statements are expressed in any of a variety of formats. In several embodiments, each ‘meta data’ statement is parsed into a separate chunk. In other embodiments, several ‘meta data’ statements in a first format (such as subject, predicate, object, authority expressions) are parsed into a first chunk and other ‘meta data’ statements in other formats are parsed into separate chunks. In one embodiment, the ‘meta data’ statements are written into an XML configuration file and the XML configuration file is parsed to create the chunks within a ‘DXDT’ chunk.


An embodiment of a system for generating a ‘DXDT’ chunk from a series of ‘meta data’ statements contained within an XML configuration file is shown in FIG. 3.1. The system 380 includes an XML configuration file 382, which can be provided to a parser 384. The XML configuration file includes the ‘meta data’ encoded as XML. The parser parses the XML and generates a ‘DXDT’ chunk 386 by converting the ‘meta data’ statement into chunks that are written to the ‘DXDT’ chunk in accordance with any of the ‘meta data’ chunk formats described above.


3.3.1. Generating an ‘Index’ Chunk


As discussed above, many embodiments of ‘DXDT’ chunks in accordance with the present invention can include an ‘index’ chunk. An ‘index’ chunk can be automatically generated following the completion of the encoding of the audio, video and/or subtitle tracks contained within a multimedia file. In one embodiment, an ‘index’ chunk is generated by referencing encoded video frames and any accompanying audio at approximately evenly spaced intervals within an encoded video track. In other embodiments, video frames associated with scenes and/or chapters within an encoded video track can be identified and used to automatically generate an ‘index’ chunk. In many embodiments, ‘index’ chunks can be generated manually, generated automatically using menu information or generated using any number of algorithms appropriate to the sequence of video indexed by the ‘index’ chunk.


3.3. Generating a ‘DMNU’ Chunk


A system that can be used to generate a ‘DMNU’ chunk in accordance with an embodiment of the present invention is illustrated in FIG. 3.2. The menu chunk generating system 420 requires as input a media model 422 and media information. The media information can take the form of a video source 424, an audio source 426 and an overlay source 428.


The generation of a ‘DMNU’ chunk using the inputs to the menu chunk generating system involves the creation of a number of intermediate files. The media model 422 is used to create an XML configuration file 430 and the media information is used to create a number of AVI files 432. The XML configuration file is created by a model transcoder 434. The AVI files 432 are created by interleaving the video, audio and overlay information using an interleaver 436. The video information is obtained by using a video decoder 438 and a video encoder 440 to decode the video source 424 and recode it in the manner discussed below. The audio information is obtained by using an audio decoder 442 and an audio encoder 444 to decode the audio and encode it in the manner described below. The overlay information is generated using a first transcoder 446 and a second transcoder 448. The first transcoder 446 converts the overlay into a graphical representation such as a standard bitmap and the second transcoder takes the graphical information and formats it as is required for inclusion in the multimedia file. Once the XML file and the AVI files containing the information required to build the menus have been generated, the menu generator 450 can use the information to generate a ‘DMNU’ chunk 358′.


3.3.1. The Menu Model


In one embodiment, the media model is an object-oriented model representing all of the menus and their subcomponents. The media model organizes the menus into a hierarchical structure, which allows the menus to be organized by language selection. A media model in accordance with an embodiment of the present invention is illustrated in FIG. 3.3. The media model 460 includes a top-level ‘MediaManager’ object 462, which is associated with a number of ‘LanguageMenus’ objects 463, a ‘Media’ object 464 and a ‘TranslationTable’ object 465. The ‘Menu Manager’ also contains the default menu language. In one embodiment, the default language can be indicated by ISO 639 two-letter language code.


The ‘LanguageMenus’ objects organize information for various menus by language selection. All of the ‘Menu’ objects 466 for a given language are associated with the ‘LanguageMenus’ object 463 for that language. Each ‘Menu’ object is associated with a number of ‘Button’ objects 468 and references a number of ‘MediaTrack’ objects 488. The referenced ‘MediaTrack’ objects 488 indicated the background video and background audio for the ‘Menu’ object 466.


Each ‘Button’ object 468 is associated with an ‘Action’ object 470 and a ‘Rectangle’ object 484. The ‘Button’ object 468 also contains a reference to a ‘MediaTrack’ object 488 that indicates the overlay to be used when the button is highlighted on a display. Each ‘Action’ object 470 is associated with a number of objects that can include a ‘MenuTransition’ object 472, a ‘ButtonTransition’ object 474, a ‘ReturnToPlay’ object 476, a ‘Subtitle Selection’ object 478, an ‘AudioSelection’ object 480 and a ‘PlayAction’ object 482. Each of these objects define the response of the menu system to various inputs from a user. The ‘MenuTransition’ object contains a reference to a ‘Menu’ object that indicates a menu that should be transitioned to in response to an action. The ‘ButtonTransition’ object indicates a button that should be highlighted in response to an action. The ‘ReturnToPlay’ object can cause a player to resume playing a feature. The ‘SubtitleSelection’ and ‘AudioSelection’ objects contain references to ‘Title’ objects 487 (discussed below). The ‘PlayAction’ object contains a reference to a ‘Chapter’ object 492 (discussed below). The ‘Rectangle’ object 484 indicates the portion of the screen occupied by the button.


The ‘Media’ object 464 indicates the media information referenced in the menu system. The ‘Media’ object has a ‘MenuTracks’ object 486 and a number of ‘Title’ objects 487 associated with it. The ‘MenuTracks’ object 486 references ‘MediaTrack’ objects 488 that are indicative of the media used to construct the menus (i.e. background audio, background video and overlays).


The ‘Title’ objects 487 are indicative of a multimedia presentation and have a number of ‘Chapter’ objects 492 and ‘MediaSource’ objects 490 associated with them. The ‘Title’ objects also contain a reference to a ‘TranslationLookup’ object 494. The ‘Chapter’ objects are indicative of a certain point in a multimedia presentation and have a number of ‘MediaTrack’ objects 488 associated with them. The ‘Chapter’ objects also contain a reference a ‘TranslationLookup’ object 494. Each ‘MediaTrack’ object associated with a ‘Chapter’ object is indicative of a point in either an audio, video or subtitle track of the multimedia presentation and references a ‘MediaSource’ object 490 and a ‘TransalationLookup’ object 494 (discussed below).


The ‘TranslationTable’ object 465 groups a number of text strings that describe the various parts of multimedia presentations indicated by the ‘Title’ objects, the ‘Chapter’ objects and the ‘MediaTrack’ objects. The ‘TranslationTable’ object 465 has a number of ‘TranslationLookup’ objects 494 associated with it. Each ‘TranslationLookup’ object is indicative of a particular object and has a number of ‘Translation’ objects 496 associated with it. The ‘Translation’ objects are each indicative of a text string that describes the object indicated by the ‘TranslationLookup’ object in a particular language.


A media object model can be constructed using software configured to generate the various objects described above and to establish the required associations and references between the objects.


3.3.2. Generating an XML File


An XML configuration file is generated from the menu model, which represents all of the menus and their sub-components. The XML configuration file also identifies all the media files used by the menus. The XML can be generated by implementing an appropriate parser application that parses the object model into XML code.


In other embodiments, a video editing application can provide a user with a user interface enabling the direct generation of an XML configuration file without creating a menu model.


In embodiments where another menu system is the basis of the menu model, such as a DVD menu, the menus can be pruned by the user to eliminate menu options relating to content not included in the multimedia file generated in accordance with the practice of the present invention. In one embodiment, this can be done by providing a graphical user interface enabling the elimination of objects from the menu model. In another embodiment, the pruning of menus can be achieved by providing a graphical user interface or a text interface that can edit the XML configuration file.


3.3.3. The Media Information


When the ‘DMNU’ chunk is generated, the media information provided to the menu generator 450 includes the data required to provide the background video, background audio and foreground overlays for the buttons specified in the menu model (see description above). In one embodiment, a video editing application such as VideoWave distributed by Roxio, Inc. of Santa Clara, Calif. is used to provide the source media tracks that represent the video, audio and button selection overlays for each individual menu.


3.3.4. Generating Intermediate AVI Files


As discussed above, the media tracks that are used as the background video, background audio and foreground button overlays are stored in a single AVI file for one or more menus. The chunks that contain the media tracks in a menu AVI file can be created by using software designed to interleave video, audio and button overlay tracks. The ‘audio’, ‘video’ and ‘overlay’ chunks (i.e. ‘subtitle’ chunks containing overlay information) are interleaved into an AVI format compliant file using an interleaver.


As mentioned above, a separate AVI file can be created for each menu. In other embodiments, other file formats or a single file could be used to contain the media information used to provide the background audio, background video and foreground overlay information.


3.3.5. Combining the XML Configuration File and the AVI Files


In one embodiment, a computer is configured to parse information from the XML configuration file to create a ‘WowMenu’ chunk (described above). In addition, the computer can create the ‘MRIF’ chunk (described above) using the AVI files that contain the media for each menu. The computer can then complete the generation of the ‘DMNU’ chunk by creating the necessary references between the ‘WowMenu’ chunk and the media chunks in the ‘MRIF’ chunk. In several embodiments, the menu information can be encrypted. Encryption can be achieved by encrypting the media information contained in the ‘MRIF’ chunk in a similar manner to that described below in relation to ‘video’ chunks. In other embodiments, various alternative encryption techniques are used.


3.3.6. Automatic Generation of Menus from the Object Model


Referring back to FIG. 3.3., a menu that contains less content than the full menu can be automatically generated from the menu model by simply examining the ‘Title’ objects 487 associated with the ‘Media object 464. The objects used to automatically generate a menu in accordance with an embodiment of the invention are shown in FIG. 3.3.1. Software can generate an XML configuration file for a simple menu that enables selection of a particular section of a multimedia presentation and selection of the audio and subtitle tracks to use. Such a menu can be used as a first so-called ‘lite’ menu in several embodiments of multimedia files in accordance with the present invention.


3.3.7. Generating ‘DXDT’ and ‘DMNU’ Chunks Using a Single Configuration File


Systems in accordance with several embodiments of the present invention are capable of generating a single XML configuration file containing both ‘meta data’ and menu information and using the XML file to generate the ‘DXDT’ and ‘DMNU’ chunks. These systems derive the XML configuration file using the ‘meta data’ information and the menu object model. In other embodiments, the configuration file need not be in XML.


3.4. Generating ‘Audio’ Chunks


The ‘audio’ chunks in the ‘movi’ list chunk of multimedia files in accordance with embodiments of the present invention can be generated by decoding an audio source and then encoding the source into ‘audio’ chunks in accordance with the practice of the present invention. In one embodiment, the ‘audio’ chunks can be encoded using an mp3 codec.


3.4.1. Re-Chunking Audio


Where the audio source is provided in chunks that don't contain audio information corresponding to the contents of a corresponding ‘video’ chunk, then embodiments of the present invention can re-chunk the audio. A process that can be used to re-chunk audio is illustrated in FIG. 3.4. The process 480 involves identifying (482) a ‘video’ chunk, identifying (484) the audio information that accompanies the ‘video’ chunk and extracting (486) the audio information from the existing audio chunks to create (488) a new ‘audio’ chunk. The process is repeated until the decision (490) is made that the entire audio source has been re-chunked. At which point, the rechunking of the audio is complete (492).


3.5. Generating ‘Video’ Chunks


As described above the process of creating video chunks can involve decoding the video source and encoding the decoded video into ‘video’ chunks. In one embodiment, each ‘video’ chunk contains information for a single frame of video. The decoding process simply involves taking video in a particular format and decoding the video from that format into a standard video format, which may be uncompressed. The encoding process involves taking the standard video, encoding the video and generating ‘video’ chunks using the encoded video.


A video encoder in accordance with an embodiment of the present invention is conceptually illustrated in FIG. 3.5. The video encoder 500 preprocesses 502 the standard video information 504. Motion estimation 506 is then performed on the preprocessed video to provide motion compensation 508 to the preprocessed video. A discrete cosine transform (DCT transformation) 510 is performed on the motion compensated video. Following the DCT transformation, the video is quantized 512 and prediction 514 is performed. A compressed bitstream 516 is then generated by combining a texture coded 518 version of the video with motion coding 520 generated using the results of the motion estimation. The compressed bitstream is then used to generate the ‘video’ chunks.


In order to perform motion estimation 506, the system must have knowledge of how the previously processed frame of video will be decoded by a decoding device (e.g. when the compressed video is uncompressed for viewing by a player). This information can be obtained by inverse quantizing 522 the output of the quantizer 512. An inverse DCT 524 can then be performed on the output of the inverse quantizer and the result placed in a frame store 526 for access during the motion estimation process.


Multimedia files in accordance with embodiments of the present invention can also include a number of psychovisual enhancements 528. The psychovisual enhancements can be methods of compressing video based upon human perceptions of vision. These techniques are discussed further below and generally involve modifying the number of bits used by the quantizer to represent various aspects of video. Other aspects of the encoding process can also include psychovisual enhancements.


In one embodiment, the entire encoding system 500 can be implemented using a computer configured to perform the various functions described above. Examples of detailed implementations of these functions are provided below.


3.5.1. Preprocessing


The preprocessing operations 502 that are optionally performed by an encoder 500 in accordance with an embodiment of the present invention can use a number of signal processing techniques to improve the quality of the encoded video. In one embodiment, the preprocessing 502 can involve one or all of deinterlacing, temporal/spatial noise reduction and resizing. In embodiments where all three of these preprocessing techniques are used, the deinterlacing is typically performed first followed by the temporal/spatial noise reduction and the resizing.


3.5.2. Motion Estimation and Compensation


A video encoder in accordance with an embodiment of the present invention can reduce the number of pixels required to represent a video track by searching for pixels that are repeated in multiple frames. Essentially, each frame in a video typically contains many of the same pixels as the one before it. The encoder can conduct several types of searches for matches in pixels between each frame (as macroblocks, pixels, half-pixels and quarter-pixels) and eliminates these redundancies whenever possible without reducing image quality. Using motion estimation, the encoder can represent most of the picture simply by recording the changes that have occurred since the last frame instead of storing the entire picture for every frame. During motion estimation, the encoder divides the frame it is analyzing into an even grid of blocks, often referred to as ‘macroblocks’. For each ‘macroblock’ in the frame, the encoder can try to find a matching block in the previous frame. The process of trying to find matching blocks is called a ‘motion search’. The motion of the ‘macroblock’ can be represented as a two dimensional vector, i.e. an (x,y) representation. The motion search algorithm can be performed with various degrees of accuracy. A whole-pel search is one where the encoder will try to locate matching blocks by stepping through the reference frame in either dimension one pixel at a time. Ina half-pixel search, the encoder searches for a matching block by stepping through the reference frame in either dimension by half of a pixel at a time. The encoder can use quarter-pixels, other pixel fractions or searches involving a granularity of greater than a pixel.


The encoder embodiment illustrated in FIG. 3.5. performs motion estimation in accordance with an embodiment of the present invention. During motion estimation the encoder has access to the preprocessed video 502 and the previous frame, which is stored in a frame store 526. The previous frame is generated by taking the output of the quantizer, performing an inverse quantization 522 and an inverse DCT transformation 524. The reason for performing the inverse functions is so that the frame in the frame store is as it will appear when decoded by a player in accordance with an embodiment of the present invention.


Motion compensation is performed by taking the blocks and vectors generated as a result of motion estimation. The result is an approximation of the encoded image that can be matched to the actual image by providing additional texture information.


3.5.3. Discrete Cosine Transform


The DCT and inverse DCT performed by the encoder illustrated in FIG. 3.5. are in accordance with the standard specified in ISO/IEC 14496-2:2001(E), Annex A.1 (coding transforms).


3.5.3.1. Description of Transform


The DCT is a method of transforming a set of spatial-domain data points to a frequency domain representation. In the case of video compression, a 2-dimensional DCT converts image blocks into a form where redundancies are more readily exploitable. A frequency domain block can be a sparse matrix that is easily compressed by entropy coding.


3.5.3.2. Psychovisual Enhancements to Transform


The DCT coefficients can be modified to improve the quality of the quantized image by reducing quantization noise in areas where it is readily apparent to a human viewer. In addition, file size can be reduced by increasing quantization noise in portions of the image where it is not readily discernable by a human viewer.


Encoders in accordance with an embodiment of the present invention can perform what is referred to as a ‘slow’ psychovisual enhancement. The ‘slow’ psychovisual enhancement analyzes blocks of the video image and decides whether allowing some noise there can save some bits without degrading the video's appearance. The process uses one metric per block. The process is referred to as a ‘slow’ process, because it performs a considerable amount of computation to avoid blocking or ringing artifacts.


Other embodiments of encoders in accordance with embodiments of the present invention implement a ‘fast’ psychovisual enhancement. The ‘fast’ psychovisual enhancement is capable of controlling where noise appears within a block and can shape quantization noise.


Both the ‘slow’ and ‘fast’ psychovisual enhancements are discussed in greater detail below. Other psychovisual enhancements can be performed in accordance with embodiments of the present invention including enhancements that control noise at image edges and that seek to concentrate higher levels of quantization noise in areas of the image where it is not readily apparent to human vision.


3.5.3.3. ‘Slow’ Psychovisual Enhancement


The ‘slow’ psychovisual enhancement analyzes blocks of the video image and determines whether allowing some noise can save bits without degrading the video's appearance. In one embodiment, the algorithm includes two stages. The first involves generation of a differentiated image for the input luminance pixels. The differentiated image is generated in the manner described below. The second stage involves modifying the DCT coefficients prior to quantization.


3.5.3.3.1. Generation of Differentiated Image


Each pixel p′xy of the differentiated image is computed from the uncompressed source pixels, pxy, according to the following:

p′xy=max(|px+1y−pxy|,|px−1y−pxy|,|pxy+1−pxy|,|pxy−1−pxy|)


where


p′xy will be in the range 0 to 255 (assuming 8 bit video).


3.5.3.3.2. Modification of DCT Coefficients


The modification of the DCT coefficients can involve computation of a block ringing factor, computation of block energy and the actual modification of the coefficient values.


3.5.3.3.3. Computation of block ringing factor


For each block of the image, a “ringing factor” is calculated based on the local region of the differentiated image. In embodiments where the block is defined as an 8×8 block, the ringing factor can be determined using the following method.


Initially, a threshold is determined based on the maximum and minimum luminance pixels values within the 8×8 block:

thresholdblock=floor((maxblock−minblock)/8)+2


The differentiated image and the threshold are used to generate a map of the “flat” pixels in the block's neighborhood. The potential for each block to have a different threshold prevents the creation of a map of flat pixels for the entire frame. The map is generated as follows:

flatxy=1 when p′xy<thresholdblock
flatxy=0 otherwise


The map of flat pixels is filtered according to a simple logical operation:

flat′xy=1 when flatxy=1 and flatx−1y=1 and flatxy−1=1 and flatx−1y−1=1 flat′xy otherwise


The flat pixels in the filtered map are then counted over the 9×9 region that covers the 8×8 block.

flatcountblock=Σflat′xy for 0=x=8 and 0=y=8


The risk of visible ringing artifacts can be evaluated using the following expression:

ringingbriskblock=((flatcountblock−10)×256+20)/40


The 8×8 block's ringing factor can then be derived using the following expression:







Ringingfactor
=



0


when


ringingrisk

>
255

=



255


when


ringingrisk


<
0

=
255







ringingrisk


otherwise






3.5.3.3.4. Computation of Block Energy


The energy for blocks of the image can be calculated using the following procedure. In several embodiments, 8×8 blocks of the image are used.


A forward DCT is performed on the source image:

T=fDCT(S)


where S is the 64 source-image luminance values of the 8×8 block in question and T is the transformed version of the same portion of the source image.


The energy at a particular coefficient position is defined as the square of that coefficient's value:

ek=tk2 for 0=k=63


where tk is the kth coefficient of transformed block T.


3.5.3.3.5. Coefficient Modification


The modification of the DCT coefficients can be performed in accordance with the following process. In several embodiments, the process is performed for every non-zero AC DCT coefficient before quantization. The magnitude of each coefficient is changed by a small delta, the value of the delta being determined according to psychovisual techniques.


The DCT coefficient modification of each non-zero AC coefficient ck is performed by calculating an energy based on local and block energies using the following formula:

energyk=max(ak×ek,0.12×totalenergy)


where ak is a constant whose value depends on the coefficient position as described in the following table:









TABLE 3





Coefficient table






















0.0
1.0
1.5
2.0
2.0
2.0
2.0
2.0


1.0
1.5
2.0
2.0
2.0
2.0
2.0
2.0


1.5
2.0
2.0
2.0
2.0
2.0
2.0
2.0


2.0
2.0
2.0
2.0
2.0
2.0
2.0
2.0


2.0
2.0
2.0
2.0
2.0
2.0
2.0
2.0


2.0
2.0
2.0
2.0
2.0
2.0
2.0
2.0


2.0
2.0
2.0
2.0
2.0
2.0
2.0
2.0


2.0
2.0
2.0
2.0
2.0
2.0
2.0
2.0









The energy can be modified according to the block's ringing factor using the following relationship:

energy′k=ringingfactor×energyk


The resulting value is shifted and clipped before being used as an input to a look-up table (LUT).

ek=min(1023,4×energy′k)
dk=LUTi where i=ek


The look-up table is computed as follows:

LUTi=min(floor(ktexture×((i+0.5)/4)1/2+kflat×offset),2×Qp)


The value ‘offset’ depends on quantizer, Qp, as described in the following table:









TABLE 4







offset as a function of Qp values










Qp
offset














1
−0.5



2
1.5



3
1.0



4
2.5



5
1.5



6
3.5



7
2.5



8
4.5



9
3.5



10
5.5



11
4.5



12
6.5



13
5.5



14
7.5



15
6.5



16
8.5



17
7.5



18
9.5



19
8.5



20
10.5



21
9.5



22
11.5



23
10.5



24
12.5



25
11.5



26
13.5



27
12.5



28
14.5



29
13.5



30
15.5



31
14.5










The variable ktexture and kflat control the strength of the of the psychovisual effect in flat and textured regions respectively. In one embodiment, they take values in the range 0 to 1, with 0 signifying no effect and 1 meaning full effect. In one embodiment, the values for ktexture and kflat are established as follows:

    • Luminance:
      • ktexture=1.0
      • kflat=1.0
    • Chrominance:
      • ktexture=1.0
      • kflat=0.0


The output from the look-up table (dk) is used to modify the magnitude of the DCT coefficient by an additive process:

c′k=ck−min(dk,|ck|)×sgn(ck)


Finally, the DCT coefficient ck is substituted by the modified coefficient c′k and passed onwards for quantization.


3.5.3.4. ‘Fast’ Psychovisual Enhancement


A ‘fast’ psychovisual enhancement can be performed on the DCT coefficients by computing an ‘importance’ map for the input luminance pixels and then modifying the DCT coefficients.


3.5.3.4.1. Computing an ‘Importance’ Map


An ‘importance’ map can be generated by calculating an ‘importance’ value for each pixel in the luminance place of the input video frame. In several embodiments, the ‘importance’ value approximates the sensitivity of the human eye to any distortion located at that particular pixel. The ‘importance’ map is an array of pixel ‘importance’ values.


The ‘importance’ of a pixel can be determined by first calculating the dynamic range of a block of pixels surrounding the pixel (dxy). In several embodiments the dynamic range of a 3×3 block of pixels centered on the pixel location (x, y) is computed by subtracting the value of the darkest pixel in the area from the value of the lightest pixel in the area.


The ‘importance’ of a pixel (mxy) can be derived from the pixel's dynamic range as follows:

mxy=0.08/max(dxy,3)+0.001

3.5.3.4.2. Modifying DCT Coefficients


In one embodiment, the modification of the DCT coefficients involves the generation of basis-function energy matrices and delta look up tables.


3.5.3.4.3. Generation of Basis-Function Energy Matrices


A set of basis-function energy matrices can be used in modifying the DCT coefficients. These matrices contain constant values that may be computed prior to encoding. An 8×8 matrix is used for each of the 64 DCT basis functions. Each matrix describes how every pixel in an 8×8 block will be impacted by modification of its corresponding coefficient. The kth basis-function energy matrix is derived by taking an 8×8 matrix Ak with the corresponding coefficient set to 100 and the other coefficients set to 0.







a

k

n


=


100


if


n

=

k
=

0


otherwise









    • where

    • n represents the coefficient position within the 8×8 matrix; 0=n=63





An inverse DCT is performed on the matrix to yield a further 8×8 matrix A′k. The elements of the matrix (a′kn) represent the kth DCT basis function.

A′k=iDCT(Ak)


Each value in the transformed matrix is then squared:

bkn=a′kn2 for 0=n=63


The process is carried out 64 times to produce the basis function energy matrices Bk, 0=k=63, each comprising 64 natural values. Each matrix value is a measure of how much a pixel at the nth position in the 8×8 block will be impacted by any error or modification of the coefficient k.


3.5.3.4.4. Generation of Delta Look-Up Table


A look-up table (LUT) can be used to expedite the computation of the coefficient modification delta. The contents of the table can be generated in a manner that is dependent upon the desired strength of the ‘fast’ psychovisual enhancement and the quantizer parameter (Qp).


The values of the look-up table can be generated according to the following relationship:

LUTi=min(floor(128×ktexture×strength/(i+0.5)+kflat×offset+0.5),2×Qp)

    • where
    • i is the position within the table, 0=i=1023.
    • strength and offset depend on the quantizer, Qp, as described in the following table:









TABLE 5







Relationship between values of


strength and offset and the value of Qp









Qp
strength
offset












1
0.2
−0.5


2
0.6
1.5


3
1.0
1.0


4
1.2
2.5


5
1.3
1.5


6
1.4
3.5


7
1.6
2.5


8
1.8
4.5


9
2.0
3.5


10
2.0
5.5


11
2.0
4.5


12
2.0
6.5


13
2.0
5.5


14
2.0
7.5


15
2.0
6.5


16
2.0
8.5


17
2.0
7.5


18
2.0
9.5


19
2.0
8.5


20
2.0
10.5


21
2.0
9.5


22
2.0
11.5


23
2.0
10.5


24
2.0
12.5


25
2.0
11.5


26
2.0
13.5


27
2.0
12.5


28
2.0
14.5


29
2.0
13.5


30
2.0
15.5


31
2.0
14.5









The variable ktexture and kflat control the strength of the of the psychovisual effect in flat and textured regions respectively. In one embodiment, they take values in the range 0 to 1, with 0 signifying no effect and 1 meaning full effect. In one embodiment, the values for ktexture and kflat are established as follows:

    • Luminance:
      • ktexture=1.0
      • kflat=1.0
    • Chrominance:
      • ktexture=1.0
      • k=0.0


        3.5.3.4.5. Modification of DCT Coefficients


The DCT coefficients can be modified using the values calculated above. In one embodiment, each non-zero AC DCT coefficient is modified in accordance with the following procedure prior to quantization.


Initially, an ‘energy’ value (ek) is computed by taking the dot product of the corresponding basis function energy matrix and the appropriate 8×8 block from the importance map. This ‘energy’ is a measure of how quantization errors at the particular coefficient would be perceived by a human viewer. It is the sum of the product of pixel importance and pixel basis-function energy:

ek=M·Bk

    • where
    • M contains the 8×8 block's importance map values; and
    • Bk is the kth basis function energy matrix.


The resulting ‘energy’ value is shifted and clipped before being used as an index (dk) into the delta look-up table.

e′k=min[1023,floor(ek/32768)]
dk=LUTi

    • where
    • i=e′k


The output of the delta look-up table is used to modify the magnitude of the DCT coefficient by an additive process:

c′k=ck−min(dk,|ck|)×sign(ck)


The DCT coefficient ck is substituted with the modified c′k and passed onwards for quantization.


3.5.4. Quantization


Encoders in accordance with embodiments of the present invention can use a standard quantizer such as a the quantizer defined by the International Telecommunication Union as Video Coding for Low Bitrate Communication, ITU-T Recommendation H.263, 1996.


3.5.4.1. Psychovisual Enhancements to Quantization


Some encoders in accordance with embodiments of the present invention, use a psychovisual enhancement that exploits the psychological effects of human vision to achieve more efficient compression. The psychovisual effect can be applied at a frame level and a macroblock level.


3.5.4.2. Frame Level Psychovisual Enhancements


When applied at a frame level, the enhancement is part of the rate control algorithm and its goal is to adjust the encoding so that a given amount of bit rate is best used to ensure the maximum visual quality as perceived by human eyes. The frame rate psychovisual enhancement is motivated by the theory that human vision tends to ignore the details when the action is high and that human vision tends to notice detail when an image is static. In one embodiment, the amount of motion is determined by looking at the sum of absolute difference (SAD) for a frame. In one embodiment, the SAD value is determined by summing the absolute differences of collocated luminance pixels of two blocks. In several embodiments, the absolute differences of 16×16 pixel blocks is used. In embodiments that deal with fractional pixel offsets, interpolation is performed as specified in the MPEG-4 standard (an ISO/IEC standard developed by the Moving Picture Experts Group of the ISO/IEC), before the sum of absolute differences is calculated.


The frame-level psychovisual enhancement applies only to the P frames of the video track and is based on SAD value of the frame. During the encoding, the psychovisual module keeps a record of the average SAD (i.e. SAD) of all of the P frames of the video track and the average distance of the SAD of each frame from its overall SAD (i.e. DSAD). The averaging can be done using an exponential moving average algorithm. In one embodiment, the one-pass rate control algorithm described above can be used as the averaging period here (see description above).


For each P frame of the video track encoded, the frame quantizer Q (obtained from the rate control module) will have a psychovisual correction applied to it. In one embodiment, the process involves calculating a ratio R using the following formula:






R
=



SAD
-

SAD
_



DSAD
_


-
I







    • where

    • I is a constant and is currently set to 0.5. The R is clipped to within the bound of [−1, 1].





The quantizer is then adjusted according to the ration R, via the calculation shown below:

Qadj=Q└Q·(1+R·Sframe)┘

    • where
    • Sframe is a strength constant for the frame level psychovisual enhancements.


The Sframe constant determines how strong an adjustment can be for the frame level psychovisual. In one embodiment of the codec, the option of setting Sframe to 0.2, 0.3 or 0.4 is available.


3.5.4.3. Macroblock Level Psychovisual Enhancements


Encoders in accordance with embodiments of the present invention that utilize a psychovisual enhancement at the macroblock level attempt to identify the macroblocks that are prominent to the visual quality of the video for a human viewer and attempt to code those macroblocks with higher quality. The effect of the macroblock level psychovisual enhancements it to take bits away from the less important parts of a frame and apply them to more important parts of the frame. In several embodiments, enhancements are achieved using three technologies, which are based on smoothness, brightness and the macroblock SAD. In other embodiments any of the techniques alone or in combination with another of the techniques or another technique entirely can be used.


In one embodiment, all three of the macroblock level psychovisual enhancements described above share a common parameter, SMB, which controls the strength of the macroblock level psychovisual enhancement. The maximum and minimum quantizer for the macroblocks are then derived from the strength parameter and the frame quantizer Qframe via the calculations shown below:








Q
MBMax

=


Q
frame


(

1
-

S

M

B



)



,




and



Q
MBMin


=


Q
frame

.

(

1
-

S

M

B



)









    • where

    • QMBMax is the maximum quantizer

    • QMBMax is the minimum quantizer





The values QMBMax and QMBMax define the upper and lower bounds to the macroblock quantizers for the entire frame. In one embodiment, the option of setting the value SMB to any of the values 0.2, 0.3 and 0.4 is provided. In other embodiments, other values for SMB can be utilized.


3.5.4.3.1. Brightness Enhancement


In embodiments where psychovisual enhancement is performed based on the brightness of the macroblocks, the encoder attempts to encode brighter macroblocks with greater quality. The theoretical basis of this enhancement is that relatively dark parts of the frame are more or less ignored by human viewers. This macroblock psychovisual enhancement is applied to I frames and P frames of the video track. For each frame, the encoder looks through the whole frame first. The average brightness (BR) is calculated and the average difference of brightness from the average (DBR) is also calculated. These values are then used to develop two thresholds (TBRLower, TBRUpper), which can be used as indicators for whether the psychovisual enhancement should be applied:

TBRLower=BRDBR
TBRUpperBR+(BR−TBRLower)


The brightness enhancement is then applied based on the two thresholds using the conditions stated below to generate an intended quantizer (QMB) for the macroblock:

QMB=QMBMin when BR>TBRUpper
QMB=Qframe when TBRLower≤BR≤TBRUpper, and
QMB=QMBMax when BR<TBRLower

    • where
    • BR is the brightness value for that particular macroblock


In embodiments where the encoder is compliant with the MPEG-4 standard, the macroblock level psychovisual brightness enhancement technique cannot change the quantizer by more than ±2 from one macroblock to the next one. Therefore, the calculated QMB may require modification based upon the quantizer used in the previous macroblock.


3.5.4.3.2. Smoothness Enhancement


Encoders in accordance with embodiments of the present invention that include a smoothness psychovisual enhancement, modify the quantizer based on the spatial variation of the image being encoded. Use of a smoothness psychovisual enhancement can be motivated by the theory that human vision has an increased sensitivity to quantization artifacts in smooth parts of an image. Smoothness psychovisual enhancement can, therefore, involve increasing the number of bits to represent smoother portions of the image and decreasing the number of bits where there is a high degree of spatial variation in the image.


In one embodiment, the smoothness of a portion of an image is measured as the average difference in the luminance of pixels in a macroblock to the brightness of the macroblock (DR). A method of performing smoothness psychovisual enhancement on an I frame in accordance with embodiments of the present invention is shown in FIG. 3.6. The process 540, involves examining the entire frame to calculate (542) DR. The threshold for applying the smoothness enhancement, TDR, can then be derived (544) using the following calculation:







T

D

R


=


DR
_

2





The following smoothness enhancement is performed (546) based on the threshold.

QMB=Qframe when DR≥TDR, and
QMB=QMBMin when DR<TDR

    • where
    • QMB is the intended quantizer for the macroblock
    • DR is the deviation value for the macroblock (i.e. mean luminance−mean brightness)


Embodiments that encode files in accordance with the MPEG-4 standard are limited as described above in that the macroblock level quantizer change can be at most ±2 from one macroblock to the next.


3.5.4.3.3. Macroblock SAD Enhancement


Encoders in accordance with embodiments of the present invention can utilize a macroblock SAD psychovisual enhancement. A macroblock SAD psychovisual enhancement can be used to increase the detail for static macroblocks and allow decreased detail in portions of a frame that are used in a high action scene.


A process for performing a macroblock SAD psychovisual enhancement in accordance with an embodiment of the present invention is illustrated in FIG. 3.7. The process 570 includes inspecting (572) an entire I frame to determine the average SAD (i.e. MBSAD) for all of the macroblocks in the entire frame and the average difference of a macroblock's SAD from the average (i.e. DMBSAD) is also obtained. In one embodiment, both of these macroblocks are averaged over the inter-frame coded macroblocks (i.e. the macroblocks encoded using motion compensation or other dependencies on previous encoded video frames). Two thresholds for applying the macroblock SAD enhancement are then derived (574) from these averages using the following formulae:

TMBSADLower=MBSADDMBSAD, and
TMBSADUpper=MBSAD+DMBSAD

    • where
    • TMBSADLower is the lower threshold
    • TMBSADUpper is the upper threshold, which may be bounded by 1024 if necessary


The macroblock SAD enhancement is then applied (576) based on these two thresholds according to the following conditions:

QMB=QMBMax when MBSAD>TMBSADUpper
QMB=Qframe when TMADLower≤MBSAD≤TMBSADUpper
QMB=QMBMin when MBSAD<TMBSADLower

    • where
    • QMB is the intended quantizer for the macroblock
    • MBSAD is the SAD value for that particular macroblock


Embodiments that encode files in accordance with the MPEG-4 specification are limited as described above in that the macroblock level quantizer change can be at most ±2 from one macroblock to the next.


3.5.5. Rate Control


The rate control technique used by an encoder in accordance with an embodiment of the present invention can determine how the encoder uses the allocated bit rate to encode a video sequence. An encoder will typically seek to encode to a predetermined bit rate and the rate control technique is responsible for matching the bit rate generated by the encoder as closely as possible to the predetermined bit rate. The rate control technique can also seek to allocate the bit rate in a manner that will ensure the highest visual quality of the video sequence when it is decoded. Much of rate control is performed by adjusting the quantizer. The quantizer determines how finely the encoder codes the video sequence. A smaller quantizer will result in higher quality and higher bit consumption. Therefore, the rate control algorithm seeks to modify the quantizer in a manner that balances the competing interests of video quality and bit consumption.


Encoders in accordance with embodiments of the present invention can utilize any of a variety of different rate control techniques. In one embodiment, a single pass rate control technique is used. In other embodiments a dual (or multiple) pass rate control technique is used. In addition, a ‘video buffer verified’ rate control can be performed as required. Specific examples of these techniques are discussed below. However, any rate control technique can be used in an encoder in accordance with the practice of the present inventions.


3.5.5.1. One Pass Rate Control


An embodiment of a one pass rate control technique in accordance with an embodiment of the present invention seeks to allow high bit rate peaks for high motion scenes. In several embodiments, the one pass rate control technique seeks to increase the bit rate slowly in response to an increase in the amount of motion in a scene and to rapidly decrease the bit rate in response to a reduction in the motion in a scene.


In one embodiment, the one pass rate control algorithm uses two averaging periods to track the bit rate. A long-term average to ensure overall bit rate convergence and a short-term average to enable response to variations in the amount of action in a scene.


A one pass rate control technique in accordance with an embodiment of the present invention is illustrated in FIG. 3.8. The one pass rate control technique 580 commences (582) by initializing (584) the encoder with a desired bit rate, the video frame rate and a variety of other parameters (discussed further below). A floating point variable is stored, which is indicative of the quantizer. If a frame requires quantization (586), then the floating point variable is retrieved (588) and the quantizer obtained by rounding the floating point variable to the nearest integer. The frame is then encoded (590). Observations are made during the encoding of the frame that enable the determination (592) of a new quantizer value. The process decides (594) to repeat unless there are no more frames. At which point, the encoding in complete (596).


As discussed above, the encoder is initialized (584) with a variety of parameters. These parameters are the ‘bit rate’, the ‘frame rate’, the ‘Max Key Frame Interval’, the ‘Maximum Quantizer’, the ‘Minimum Quantizer’, the ‘averaging period’, the ‘reaction period’ and the ‘down/up ratio’. The following is a discussion of each of these parameters.


3.5.5.1.1. The ‘Bit Rate’


The ‘bit rate’ parameter sets the target bit rate of the encoding.


3.5.5.1.2. The ‘Frame Rate’


The ‘frame rate’ defines the period between frames of video.


3.5.5.1.3. The ‘Max Key Frame Interval’


The ‘Max Key Frame Interval’ specifies the maximum interval between the key frames. The key frames are normally automatically inserted in the encoded video when the codec detects a scene change. In circumstances where a scene continues for a long interval without a single cut, key frames can be inserted in insure that the interval between key frames is always less or equal to the ‘Max Key Frame Interval’. In one embodiment, the ‘Max Key Frame Interval’ parameter can be set to a value of 300 frames. In other embodiments, other values can be used.


3.5.5.1.4. The ‘Maximum Quantizer’ and the ‘Minimum Quantizer’


The ‘Maximum Quantizer’ and the ‘Minimum Quantizer’ parameters set the upper and lower bound of the quantizer used in the encoding. In one embodiment, the quantizer bounds are set at values between 1 and 31.


3.5.5.1.5. The ‘Averaging Period’


The ‘averaging period’ parameter controls the amount of video that is considered when modifying the quantizer. A longer averaging period will typically result in the encoded video having a more accurate overall rate. In one embodiment, an ‘averaging period’ of 2000 is used. Although in other embodiments other values can be used.


3.5.5.1.6. The ‘Reaction Period’


The ‘reaction period’ parameter determines how fast the encoder adapts to changes in the motion in recent scenes. A longer ‘reaction period’ value can result in better quality high motion scenes and worse quality low motion scenes. In one embodiment, a ‘reaction period’ of 10 is used. Although in other embodiments other values can be used.


3.5.5.1.7. The ‘Down/Up Ratio’


The ‘down/up ratio’ parameter controls the relative sensitivity for the quantizer adjustment in reaction to the high or low motion scenes. A larger value typically results in higher quality high motion scenes and increased bit consumption. In one embodiment, a ‘down/up ratio’ of 20 is used. Although in other embodiments, other values can be used.


3.5.5.1.8. Calculating the Quantizer Value


As discussed above, the one pass rate control technique involves the calculation of a quantizer value after the encoding of each frame. The following is a description of a technique in accordance with an embodiment of the present invention that can be used to update the quantizer value.


The encoder maintains two exponential moving averages having periods equal to the ‘averaging period’ (Paverage) and the ‘reaction period’ (Preaction) a moving average of the bit rate. The two exponential moving averages can be calculated according to the relationship:







A
t

=



A

t
-
1


.


P
-
T

P


+

B
.

T
P









    • where

    • At is the average at instance t;

    • At−1 is the average at instance t−T (usually the average in the previous frame);

    • T represents the interval period (usually the frame time); and

    • P is the average period, which can be either Paverage and or Preaction.





The above calculated moving average is then adjusted into bit rate by dividing by the time interval between the current instance and the last instance in the video, using the following calculation:







R
t

=


A
t



1
T








    • where

    • Rt is the bitrate;

    • At is either of the moving averages; and

    • T is the time interval between the current instance and last instance (it is usually the inverse of the frame rate).





The encoder can calculate the target bit rate (Rtarget) of the next frame as follows:

Rtarget=Roverall+(Roverall−Raverage)

    • where
    • Roverall is the overall bit rate set for the whole video; and
    • Raverage is the average bit rate using the long averaging period.


In several embodiments, the target bit rate is lower bounded by 75% of the overall bit rate. If the target bit rate drops below that bound, then it will be forced up to the bound to ensure the quality of the video.


The encoder then updates the internal quantizer based on the difference between Rtarget and Rreaction. If Rreaction is less than Rtarget, then there is a likelihood that the previous frame was of relatively low complexity. Therefore, the quantizer can be decreased by performing the following calculation:







Q
internal


=


Q
internal

.

(

1
-

1

P
reaction



)






When Rreaction is greater than Rtarget, there is a significant likelihood that previous frame possessed a relatively high level of complexity. Therefore, the quantizer can be increased by performing the following calculation:







Q
internal


=


Q
internal

.

(

1
+

1

S


P
reaction




)








    • where

    • S is the ‘up/down ratio’.


      3.5.5.1.9. B-VOP Encoding





The algorithm described above can also be applied to B-VOP encoding. When B-VOP is enabled in the encoding, the quantizer for the B-VOP (QB) is chosen based on the quantizer of the P-VOP (QP) following the B-VOP. The value can be obtained in accordance with the following relationships:









Q
B

=



2
.

Q
P




for



Q
P



4









Q
B

=


5
+



3
4

.

Q
P




for


4


<

Q
P


20








Q
B

=



Q
P



for



Q
P




2

0








3.5.5.2. Two Pass Rate Control


Encoders in accordance with an embodiment of the present invention that use a two (or multiple) pass rate control technique can determine the properties of a video sequence in a first pass and then encode the video sequence with knowledge of the properties of the entire sequence. Therefore, the encoder can adjust the quantization level for each frame based upon its relative complexity compared to other frames in the video sequence.


A two pass rate control technique in accordance with an embodiment of the present invention, the encoder performs a first pass in which the video is encoded in accordance with the one pass rate control technique described above and the complexity of each frame is recorded (any of a variety of different metrics for measuring complexity can be used). The average complexity and, therefore, the average quantizer (Qref) can be determined based on the first. In the second pass, the bit stream is encoded with quantizers determined based on the complexity values calculated during the first pass.


3.5.5.2.1. Quantizers for I-VOPs


The quantizer Q for I-VOPs is set to 0.75×Qref, provided the next frame is not an I-VOP. If the next frame is also an I-VOP, the Q(for the current frame) is set to 1.25×Qref.


3.5.5.2.2. Quantizers for P-VOPs


The quantizer for the P-VOPs can be determined using the following expression.

Q=F−1{F(Qref)·(Ccomplexity/Ccomplexity)k}

    • where
    • Ccomplexity is the complexity of the frame;

      Ccomplexity is the average complexity of the video sequence;


F(x) is a function that provides the number which the complexity of the frame must be multiplied to give the number of bits required to encode the frame using a quantizer with a quantization value x;

    • F−1(x) is the inverse function of F(x); and
    • k is the strength parameter.


The following table defines an embodiment of a function F(Q) that can be used to generator the factor that the complexity of a frame must be multiplied by in order to determine the number of bits required to encode the frame using an encoder with a quantizer Q.









TABLE 6







Values of F(Q) with


respect to Q.










Q
F(Q)














1
1



2
0.4



3
0.15



4
0.08



5
0.05



6
0.032



7
0.022



8
0.017



9
0.013



10
0.01



11
0.008



12
0.0065



13
0.005



14
0.0038



15
0.0028



16
0.002










If the strength parameter k is chosen to be 0, then the result is a constant quantizer. When the strength parameter is chosen to be 1, the quantizer is proportional to Ccomplexity. Several encoders in accordance with embodiments of the present invention have a strength parameter k equal to 0.5.


3.5.5.2.3. Quantizers for B-VOPs


The quantizer Q for the B-VOPs can be chosen using the same technique for choosing the quantizer for B-VOPs in the one pass technique described above.


3.5.5.3. Video Buffer Verified Rate Control


The number of bits required to represent a frame can vary depending on the characteristics of the video sequence. Most communication systems operate at a constant bit rate. A problem that can be encountered with variable bit rate communications is allocating sufficient resources to handle peaks in resource usage. Several encoders in accordance with embodiments of the present invention encode video with a view to preventing overflow of a decoder video buffer, when the bit rate of the variable bit rate communication spikes.


The objectives of video buffer verifier (VBV) rate control can include generating video that will not exceed a decoder's buffer when transmitted. In addition, it can be desirable that the encoded video match a target bit rate and that the rate control produces high quality video.


Encoders in accordance with several embodiments of the present invention provide a choice of at least two VBV rate control techniques. One of the VBV rate control techniques is referred to as causal rate control and the other technique is referred to as Nth pass rate control.


3.5.5.3.1. Causal Rate Control


Causal VBV rate control can be used in conjunction with a one pass rate control technique and generates outputs simply based on the current and previous quantizer values.


An encoder in accordance with an embodiment of the present invention includes causal rate control involving setting the quantizer for frame n (i.e. Qn) according to the following relationship.









1

Q
n



=


1

Q

n
-
1




+

x
birate

+

x
velocity

+

x
size









1

Q
n


=


1

Q
n



+

X
drift









    • where

    • Q′n is the quantizer estimated by the single pass rate control;

    • Xbitrate is calculated by determining a target bit rate based on the drift from the desired bit rate;

    • Xvelocity is calculated based on the estimated time until the VBV buffer over- or under-flows;

    • Xsize is applied on the result of P-VOPs only and is calculated based on the rate at which the size of compressed P-VOPs is changing over time;

    • Xdrift is the drift from the desired bit rate.





In several embodiments, the causal VBV rate control may be forced to drop frames and insert stuffing to respect the VBV model. If a compressed frame unexpectedly contains too many or two few bits, then it can be dropped or stuffed.


3.5.5.3.2. Nth Pass VBV Rate Control


Nth pass VBV rate control can be used in conjunction with a multiple pass rate control technique and it uses information garnered during previous analysis of the video sequence. Encoders in accordance with several embodiments of the present invention perform Nth pass VBV rate control according to the process illustrated in FIG. 3.9. The process 600 commences with the first pass, during which analysis (602) is performed. Map generation is performed (604) and a strategy is generated (606). The nth pass Rate Control is then performed (608).


3.5.5.3.3. Analysis


In one embodiment, the first pass uses some form of causal rate control and data is recorded for each frame concerning such things as the duration of the frame, the coding type of the frame, the quantizer used, the motion bits produced and the texture bits produced. In addition, global information such as the timescale, resolution and codec settings can also be recorded.


3.5.5.3.4. Map Generation


Information from the analysis is used to generate a map of the video sequence. The map can specify the coding type used for each frame (I/B/P) and can include data for each frame concerning the duration of the frame, the motion complexity and the texture complexity. In other embodiments, the map may also contain information enabling better prediction of the influence of quantizer and other parameters on compressed frame size and perceptual distortion. In several embodiments, map generation is performed after the N-lth pass is completed.


3.5.5.3.5. Strategy Generation


The map can be used to plan a strategy as to how the Nth pass rate control will operate. The ideal level of the VBV buffer after every frame is encoded can be planned. In one embodiment, the strategy generation results in information for each frame including the desired compressed frame size, an estimated frame quantizer. In several embodiments, strategy generation is performed after map generation and prior to the Nth pass.


In one embodiment, the strategy generation process involves use of an iterative process to simulate the encoder and determine desired quantizer values for each frame by trying to keep the quantizer as close as possible to the median quantizer value. A binary search can be used to generate a base quantizer for the whole video sequence. The base quantizer is the constant value that causes the simulator to achieve the desired target bit rate. Once the base quantizer is found, the strategy generation process involves consideration of the VBV constrains. In one embodiment, a constant quantizer is used if this will not modify the VBV constrains. In other embodiments, the quantizer is modulated based on the complexity of motion in the video frames. This can be further extended to incorporate masking from scene changes and other temporal effects.


3.5.5.3.6. In-Loop Nth Pass Rate Control


In one embodiment, the in-loop Nth pass rate control uses the strategy and uses the map to make the best possible prediction of the influence of quantizer and other parameters on compressed frame size and perceptual distortion. There can be a limited discretion to deviate from the strategy to take short-term corrective strategy. Typically, following the strategy will prevent violation of the VBV model. In one embodiment, the in-loop Nth pass rate control uses a PID control loop. The feedback in the control loop is the accumulated drift from the ideal bitrate.


Although the strategy generation does not involve dropping frames, the in-loop Nth rate control may drop frames if the VBV buffer would otherwise underflow. Likewise, the in-loop Nth pass rate control can request video stuffing to be inserted to prevent VBV overflow.


3.5.6. Predictions


In one embodiment, AD/DC prediction is performed in a manner that is compliant with the standard referred to as ISO/IEC 14496-2:2001(E), section 7.4.3. (DC and AC prediction) and 7.7.1. (field DC and AC prediction).


3.5.7. Texture Coding


An encoder in accordance with an embodiment of the present invention can perform texture coding in a manner that is compliant with the standard referred to as ISO/IEC 14496-2:2001(E), annex B (variable length codes) and 7.4.1. (variable length decoding).


3.5.8. Motion Coding


An encoder in accordance with an embodiment of the present invention can perform motion coding in a manner that is compliant with the standard referred to as ISO/IEC 14496-2:2001(E), annex B (variable length codes) and 7.6.3. (motion vector decoding).


3.5.9. Generating ‘Video’ Chunks


The video track can be considered a sequence of frames 1 to N. Systems in accordance with embodiments of the present invention are capable of encoding the sequence to generate a compressed bitstream. The bitstream is formatted by segmenting it into chunks 1 to N. Each video frame n has a corresponding chunk n.


The chunks are generated by appending bits from the bitstream to chunk n until it, together with the chunks 1 through n−1 contain sufficient information for a decoder in accordance with an embodiment of the present invention to decode the video frame n. In instances where sufficient information is contained in chunks 1 through n−1 to generate video frame n, an encoder in accordance with embodiments of the present invention can include a marker chunk. In one embodiment, the marker chunk is a not-coded P-frame with identical timing information as the previous frame.


3.6. Generating ‘Subtitle’ Chunks


An encoder in accordance with an embodiment of the present invention can take subtitles in one of a series of standard formats and then converts the subtitles to bit maps. The information in the bit maps is then compressed using run length encoding. The run length encoded bit maps are the formatted into a chunk, which also includes information concerning the start time and the stop time for the particular subtitle contained within the chunk. In several embodiments, information concerning the color, size and position of the subtitle on the screen can also be included in the chunk. Chunks can be included into the subtitle track that set the palette for the subtitles and that indicate that the palette has changed. Any application capable of generating a subtitle in a standard subtitle format can be used to generate the text of the subtitles. Alternatively, software can be used to convert text entered by a user directly into subtitle information.


3.7. Interleaving


Once the interleaver has received all of the chunks described above, the interleaver builds a multimedia file. Building the multimedia file can involve creating a ‘CSET’ chunk, an ‘INFO’ list chunk, a ‘hdrl’ chunk, a ‘movi’ list chunk and an idx1 chunk. Methods in accordance with embodiments of the present invention for creating these chunks and for generating multimedia files are described below.


3.7.1. Generating a ‘CSET’ Chunk


As described above, the ‘CSET’ chunk is optional and can generated by the interleaver in accordance with the AVI Container Format Specification.


3.7.2. Generating a ‘INFO’ List Chunk


As described above, the ‘INFO’ list chunk is optional and can be generated by the interleaver in accordance with the AVI Container Format Specification.


3.7.3. Generating the ‘Hdrl’ List Chunk


The ‘hdrl’ list chunk is generated by the interleaver based on the information in the various chunks provided to the interleaver. The ‘hdrl’ list chunk references the location within the file of the referenced chunks. In one embodiment, the ‘hdrl’ list chunk uses file offsets in order to establish references.


3.7.4. Generating the ‘Movi’ List Chunk


As described above, ‘movi’ list chunk is created by encoding audio, video and subtitle tracks to create ‘audio’, ‘video’ and ‘subtitle chunks and then interleaving these chunks. In several embodiments, the ‘movi’ list chunk can also include digital rights management information.


3.7.4.1. Interleaving the Video/Audio/Subtitles


A variety of rules can be used to interleave the audio, video and subtitle chunks. Typically, the interleaver establishes a number of queues for each of the video and audio tracks. The interleaver determines which queue should be written to the output file. The queue selection can be based on the interleave period by writing from the queue that has the lowest number of interleave periods written. The interleaver may have to wait for an entire interleave period to be present in the queue before the chunk can be written to the file.


In one embodiment, the generated ‘audio,’ ‘video’ and ‘subtitle’ chunks are interleaved so that the ‘audio’ and ‘subtitle’ chunks are located within the file prior to the ‘video’ chunks containing information concerning the video frames to which they correspond. In other embodiments, the ‘audio’ and ‘subtitle’ chunks can be located after the ‘video’ chunks to which they correspond. The time differences between the location of the ‘audio,’ ‘video’ and ‘subtitle’ chunks is largely dependent upon the buffering capabilities of players that are used to play the devices. In embodiments where buffering is limited or unknown, the interleaver interleaves the ‘audio,’ ‘video’ and ‘subtitle’ chunks such that the ‘audio’ and ‘subtitle’ chunks are located between ‘video’ chunks, where the ‘video’ chunk immediately following the ‘audio’ and ‘subtitle’ chunk contains the first video frame corresponding to the audio or subtitle.


3.7.4.2. Generating DRM Information


In embodiments where DRM is used to protect the video content of a multimedia file, the DRM information can be generated concurrently with the encoding of the video chunks. As each chunk is generated, the chunk can be encrypted and a DRM chunk generated containing information concerning the encryption of the video chunk.


3.7.4.3. Interleaving the DRM Information


An interleaver in accordance with an embodiment of the present invention interleaves a DRM chunk containing information concerning the encryption of a video chunk prior to the video chunk. In one embodiment, the DRM chunk for video chunk n is located between video chunk n−1 and video chunk n. In other embodiments, the spacing of the DRM before and after the video chunk n is dependent upon the amount of buffering provided within device decoding the multimedia file.


3.7.5. Generating the ‘idx1’ chunk


Once the ‘movi’ list chunk has been generated, the generation of the ‘idx1’ chunk is a simple process. The ‘idx1’ chunk is created by reading the location within the ‘movi’ list chunk of each ‘data’ chunk. This information is combined with information read from the ‘data’ chunk concerning the track to which the ‘data’ chunk belongs and the content of the ‘data’ chunk. All of this information is then inserted into the ‘idx1’ chunk in a manner appropriate to whichever of the formats described above is being used to represent the information.


4. Transmission and Distribution of Multimedia File


Once a multimedia file is generated, the file can be distributed over any of a variety of networks. The fact that in many embodiments the elements required to generate a multimedia presentation and menus, amongst other things, are contained within a single file simplifies transfer of the information. In several embodiments, the multimedia file can be distributed separately from the information required to decrypt the contents of the multimedia file.


In one embodiment, multimedia content is provided to a first server and encoded to create a multimedia file in accordance with the present invention. The multimedia file can then be located either at the first server or at a second server. In other embodiments, DRM information can be located at the first server, the second server or a third server. In one embodiment, the first server can be queried to ascertain the location of the encoded multimedia file and/or to ascertain the location of the DRM information.


5. Decoding Multimedia File


Information from a multimedia file in accordance with an embodiment of the present invention can be accessed by a computer configured using appropriate software, a dedicated player that is hardwired to access information from the multimedia file or any other device capable of parsing an AVI file. In several embodiments, devices can access all of the information in the multimedia file. In other embodiments, a device may be incapable of accessing all of the information in a multimedia file in accordance with an embodiment of the present invention. In a particular embodiment, a device is not capable of accessing any of the information described above that is stored in chunks that are not specified in the AVI file format. In embodiments where not all of the information can be accessed, the device will typically discard those chunks that are not recognized by the device.


Typically, a device that is capable of accessing the information contained in a multimedia file in accordance with an embodiment of the present invention is capable of performing a number of functions. The device can display a multimedia presentation involving display of video on a visual display, generate audio from one of potentially a number of audio tracks on an audio system and display subtitles from potentially one of a number of subtitle tracks. Several embodiments can also display menus on a visual display while playing accompanying audio and/or video. These display menus are interactive, with features such as selectable buttons, pull down menus and sub-menus. In some embodiments, menu items can point to audio/video content outside the multimedia file presently being accessed. The outside content may be either located local to the device accessing the multimedia file or it may be located remotely, such as over a local area, wide are or public network. Many embodiments can also search one or more multimedia files according to ‘meta data’ included within the multimedia file(s) or ‘meta data’ referenced by one or more of the multimedia files.


5.1. Display of Multimedia Presentation


Given the ability of multimedia files in accordance with embodiments of the present invention to support multiple audio tracks, multiple video tracks and multiple subtitle tracks, the display of a multimedia presentation using such a multimedia file that combines video, audio and/or subtitles can require selection of a particular audio track, video track and/or subtitle track either through a visual menu system or a pull down menu system (the operation of which are discussed below) or via the default settings of the device used to generate the multimedia presentation. Once an audio track, video track and potentially a subtitle track are selected, the display of the multimedia presentation can proceed.


A process for locating the required multimedia information from a multimedia file including DRM and displaying the multimedia information in accordance with an embodiment of the present invention is illustrated in FIG. 4.0. The process 620 includes obtaining the encryption key required to decrypt the DRM header (622). The encryption key is then used to decrypt (624) the DRM header and the first DRM chunk is located (626) within the ‘movi’ list chunk of the multimedia file. The encryption key required to decrypt the DRM′ chunk is obtained (628) from the table in the DRM′ header and the encryption key is used to decrypt an encrypted video chunk. The required audio chunk and any required subtitle chunk accompany the video chunk are then decoded (630) and the audio, video and any subtitle information are presented (632) via the display and the sound system.


In several embodiments the chosen audio track can include multiple channels to provide stereo or surround sound audio. When a subtitle track is chosen to be displayed, a determination can be made as to whether the previous video frame included a subtitle (this determination may be made in any of a variety of ways that achieves the outcome of identifying a previous ‘subtitle’ chunk that contained subtitle information that should be displayed over the currently decoded video frame). If the previous subtitle included a subtitle and the timing information for the subtitle indicates that the subtitle should be displayed with the current frame, then the subtitle is superimposed on the decoded video frame. If the previous frame did not include a subtitle or the timing information for the subtitle on the previous frame indicates that the subtitle should not be displayed in conjunction with the currently decoded frame, then a ‘subtitle’ chunk for the selected subtitle track is sought. If a ‘subtitle’ chunk is located, then the subtitle is superimposed on the decoded video. The video (including any superimposed subtitles) is then displayed with the accompanying audio.


Returning to the discussion of FIG. 4.0, the process determines (634) whether there are any additional DRM chunks. If there are, then the next DRM chunk is located (626) and the process continues until no additional DRM chunks remain. At which point, the presentation of the audio, video and/or subtitle tracks is complete (636).


In several embodiments, a device can seek to a particular portion of the multimedia information (e.g. a particular scene of a movie with a particular accompanying audio track and optionally a particular accompanying subtitle track) using information contained within the ‘hdrl’ chunk of a multimedia file in accordance with the present invention. In many embodiments, the decoding of the ‘video’ chunk, ‘audio’ chunk and/or ‘subtitle’ chunk can be performed in parallel with other tasks.


An example of a device capable of accessing information from the multimedia file and displaying video in conjunction with a particular audio track and/or a particular subtitle track is a computer configured in the manner described above using software. Another example is a DVD player equipped with a codec that includes these capabilities. In other embodiments, any device configured to locate or select (whether intentionally or arbitrarily) ‘data’ chunks corresponding to particular media tracks and decode those tracks for presentation is capable of generating a multimedia presentation using a multimedia file in accordance with the practice of the present invention.


In several embodiments, a device can play multimedia information from a multimedia file in combination with multimedia information from an external file. Typically, such a device would do so by sourcing an audio track or subtitle track from a local file referenced in a multimedia file of the type described above. If the referenced file is not stored locally and the device is networked to the location where the device is stored, then the device can obtain a local copy of the file. The device would then access both files, establishing a video, an audio and a subtitle (if required) pipeline into which the various tracks of multimedia are fed from the different file sources.


5.1.1. Non-Sequential Display of Multimedia Presentation


Many embodiments of decoders in accordance with the present invention are capable of displaying a multimedia presentation contained within a multimedia file non-sequentially. Non-sequential display can include playing the sequence in reverse and/or increasing the apparent speed with which the sequence is displayed by skipping frames in the sequence. Non-sequential display can also include skipping in an irregular fashion between different portions of a multimedia presentation.


In several embodiments, the decoder uses an ‘index’ chunk within the ‘DXDT’ of a multimedia file to locate particular encoded video frames. Knowledge of the location of specific encoded video frames can be used to skip frames either in a regular fashion (such as during fast forwarding or rewinding) or in an irregular fashion (such as when skipping between scenes or chapters).


A process that can be used in accordance with an embodiment of the method of the invention to locate a specific video frame using an ‘index’ chunk is shown in FIG. 4.0.1. The process 640 commences with the identification (641a) of the particular frame in a video sequence that is being sought. A search (641b) can then be performed through an ‘index’ chunk to locate the ‘tag’ chunk that references a video frame closest to the frame being sought. In one embodiment, the closest preceding video frame is sought. Once the closest video frame has been located, information within the ‘tag’ chunk can be used to provide (641c) information concerning the location of the encoded video frame referenced by the ‘tag’ chunk within the multimedia file. In many embodiments, information within the ‘tag’ chunk can also be used to locate information concerning the encoded video frame within the ‘idx1’ chunk. Knowing the corresponding location of the ‘idx1’ chunk can increase search time through the ‘idx1’ chunk, when attempting to locate associated information.


A process for locating the ‘tag’ chunk within an ‘index’ chunk that references the preceding frame closest to a desired video frame within a video sequence is shown in FIG. 4.0.2. The process 142 commences with the identification (143a) of a current ‘tag’ chunk. The current ‘tag’ chunk is typically the first chunk in the ‘Index’ chunk. The position of the desired video frame relative to the video frame referenced by the current ‘tag’ chunk is then determined (143b). The process then attempts (143c) to locate a next ‘tag’ chunk. If there are no more ‘tag’ chunks remaining in the ‘index’ chunk, then the search is complete (143d). In one embodiment, the position of the encoded video frame and/or audio information referenced by the last ‘tag’ chunk in the ‘index’ chunk is returned. In other embodiments, such as embodiments where the last frame of the video sequence is referenced by a ‘tag’ chunk, the inability to locate a next ‘tag’ chunk is an indication that either the encoded video frame could not be located in the multimedia file or that an error has occurred.


When a next ‘tag’ chunk can be located from within the ‘index’ chunk, the process compares (143e) the positions of the encoded video frame referenced by the next ‘tag’ chunk and the desired video chunk. A decision (143f) is then made based upon whether the desired video frame lies between the encoded video frames in the sequence referenced by the current and next ‘tag’ chunks. If the desired video frame lies between the referenced frames, then the position of the video frame and any audio referenced by the current ‘tag’ chunk within the multimedia file are returned (143g) by the process.


When the desired video frame is not located between the frames referenced by the current and next ‘tag’ chunks, then the next ‘tag’ chunk becomes (143h) the current ‘tag’ chunk. The process repeats (143a) until the condition that the desired video frame be located between the encoded video frames referenced by the current and next ‘tag’ chunks is satisfied (143g) or all of the ‘tag’ chunks have been inspected (143d).


In further embodiments, the location of a desired frame can be further refined by using the references within the ‘index’ chunk to the corresponding information within the ‘idx1’ chunk to search for a reference within the ‘idx1’ chunk to a specifically desired encoded video frame that is not referenced in the ‘index’ chunk.


Although the processes shown in FIGS. 4.0.1. and 4.0.2. are discussed with reference to the location of a desired video frame, similar processes in accordance with an embodiment of the invention could also be used to locate a desired portion of one or more audio or subtitle tracks. In addition, similar processes in accordance with embodiments of the present invention can be used to locate the video frame, portion of audio track or portion of subtitle track referenced in an ‘index’ chunk that is closest to a particular time, where the time is measured relative to the running time of a video, audio or multimedia presentation stored within a multimedia file. Furthermore, similar processes can be used to locate information within the ‘idx1’ chunk.


5.2. Generation of Menus


A decoder in accordance with an embodiment of the present invention is illustrated in FIG. 4.1. The decoder 650 processes a multimedia file 652 in accordance with an embodiment of the present invention by providing the file to a demultiplexer 654. The demultiplexer extracts the ‘DMNU’ chunk from the multimedia file and extracts all of the ‘LanguageMenus’ chunks from the ‘DMNU’ chunk and provides them to a menu parser 656. The demultiplexer also extracts all of the ‘Media’ chunks from the ‘DMNU’ chunk and provides them to a media renderer 658. The menu parser 656 parses information from the ‘LanguageMenu’ chunks to build a state machine representing the menu structure defined in the ‘LanguageMenu’ chunk. The state machine representing the menu structure can be used to provide displays to the user and to respond to user commands. The state machine is provided to a menu state controller 660. The menu state controller keeps track of the current state of the menu state machine and receives commands from the user. The commands from the user can cause a state transition. The initial display provided to a user and any updates to the display accompanying a menu state transition can be controlled using a menu player interface 662. The menu player interface 662 can be connected to the menu state controller and the media render. The menu player interface instructs the media renderer which media should be extracted from the media chunks and provided to the user via the player 664 connected to the media renderer. The user can provide the player with instructions using an input device such as a keyboard, mouse or remote control. Generally the multimedia file dictates the menu initially displayed to the user and the user's instructions dictate the audio and video displayed following the generation of the initial menu. The system illustrated in FIG. 4.1. can be implemented using a computer and software. In other embodiments, the system can be implemented using function specific integrated circuits or a combination of software and firmware.


An example of a menu in accordance with an embodiment of the present invention is illustrated in FIG. 4.2. The menu display 670 includes four button areas 672, background video 674, including a title 676, and a pointer 678. The menu also includes background audio (not shown). The visual effect created by the display can be deceptive. The visual appearance of the buttons is typically part of the background video and the buttons themselves are simply defined regions of the background video that have particular actions associated with them, when the region is activated by the pointer. The pointer is typically an overlay.



FIG. 4.3. conceptually illustrates the source of all of the information in the display shown in FIG. 4.2. The background video 674 can include a menu title, the visual appearance of the buttons and the background of the display. All of these elements and additional elements can appear static or animated. The background video is extracted by using information contained in a ‘MediaTrack’ chunk 700 that indicates the location of background video within a video track 702. The background audio 706 that can accompany the menu can be located using a ‘MediaTrack’ chunk 708 that indicates the location of the background audio within an audio track 710. As described above, the pointer 678 is part of an overlay 713. The overlay 713 can also include graphics that appear to highlight the portion of the background video that appears as a button. In one embodiment, the overlay 713 is obtained using a ‘MediaTrack’ chunk 712 that indicates the location of the overlay within a overlay track 714. The manner in which the menu interacts with a user is defined by the ‘Action’ chunks (not shown) associated with each of the buttons. In the illustrated embodiment, a ‘PlayAction’ chunk 716 is illustrated. The ‘PlayAction’ chunk indirectly references (the other chunks referenced by the ‘PlayAction’ chunk are not shown) a scene within a multimedia presentation contained within the multimedia file (i.e. an audio, video and possibly a subtitle track). The ‘PlayAction’ chunk 716 ultimately references the scene using a ‘MediaTrack’ chunk 718, which indicates the scene within the feature track. A point in a selected or default audio track and potentially a subtitle track are also referenced.


As the user enters commands using the input device, the display may be updated not only in response to the selection of button areas but also simply due to the pointer being located within a button area. As discussed above, typically all of the media information used to generate the menus is located within the multimedia file and more specifically within a ‘DMNU’ chunk. Although in other embodiments, the information can be located elsewhere within the file and/or in other files.


5.3. Access the Meta Data


‘Meta data’ is a standardized method of representing information. The standardized nature of ‘Meta data’ enables the data to be accessed and understood by automatic processes. In one embodiment, the ‘meta data’ is extracted and provided to a user for viewing. Several embodiments enable multimedia files on a server to be inspected to provide information concerning a users viewing habits and viewing preferences. Such information could be used by software applications to recommend other multimedia files that a user may enjoy viewing. In one embodiment, the recommendations can be based on the multimedia files contained on servers of other users. In other embodiments, a user can request a multimedia file and the file can be located by a search engine and/or intelligent agents that inspect the ‘meta data’ of multimedia files in a variety of locations. In addition, the user can chose between various multimedia files containing a particular multimedia presentation based on ‘meta data’ concerning the manner in which each of the different versions of the presentation were encoded.


In several embodiments, the ‘meta data’ of multimedia files in accordance with embodiments of the present invention can be accessed for purposes of cataloging or for creating a simple menu to access the content of the file.


While the above description contains many specific embodiments of the invention, these should not be construed as limitations on the scope of the invention, but rather as an example of one embodiment thereof. For example, a multimedia file in accordance with an embodiment of the present invention can include a single multimedia presentation or multiple multimedia presentations. In addition, such a file can include one or more menus and any variety of different types of ‘meta data’. Accordingly, the scope of the invention should be determined not by the embodiments illustrated, but by the appended claims and their equivalents.

Claims
  • 1. A method for playing back video stored in at least a portion of a multimedia file, wherein: the multimedia file comprises: a track of encoded video frames;a first index that includes information indicative of locations of chunks within the multimedia file, where the chunks include segments of the track of encoded video frames; anda separate second index that includes information indicative of locations of each encoded video frame within the multimedia file; and the method comprises:processing the first index to identify location information for a specific chunk within the at least a portion of the multimedia file;processing the second index to identify location information for a particular encoded video frame within the specific chunk identified using the first index;locating the particular encoded video frame identified using the second index within the specific chunk identified using the first index;decoding the particular encoded video frame identified using the second index to obtain a decoded video frame; andplaying back video frames including the decoded video frame.
  • 2. The method of claim 1, wherein the information indicative of locations of chunks within the multimedia file from the first index includes a plurality of chunk offsets, wherein at least one of the plurality of chunk offsets indicates the location of the specific chunk identified using the first index.
  • 3. The method of claim 1, wherein the second index further comprises frame type information.
  • 4. The method of claim 1, wherein the first index further comprises information indicative of locations of at least one encoded video frame within each chunk.
  • 5. The method of claim 1, wherein the second index is located at the end of the multimedia file.
  • 6. The method of claim 1, wherein the second index is distributed throughout the multimedia file.
  • 7. The method of claim 1, wherein: the particular encoded video frame identified using the second index is at least partially encrypted; andthe method further comprises decrypting an at least partially encrypted video frame prior to decoding the decrypted video frame.
  • 8. The method of claim 7, wherein at least a first portion of the particular encoded video frame identified using the second index is encrypted and at least a second portion of the particular encoded video frame identified using the second index is unencrypted.
  • 9. The method of claim 8, wherein: the multimedia file comprises Digital Rights Management (DRM) information that identifies at least one portion of the particular encoded video frame identified using the second index that is encrypted; andthe method further comprises decrypting the at least one portion of the particular encoded video frame identified using the second index using the DRM information.
  • 10. The method of claim 9, wherein the DRM information further comprises cryptographic information that can be used to decrypt the at least one portion of the particular encoded video frame identified using the second index that is encrypted.
  • 11. The method of claim 9, wherein the DRM information comprises: an offset value that indicates the start of an encrypted block of data within the particular encoded video frame identified using the second index; and a number value that indicates a size of the encrypted block of data.
  • 12. The method of claim 11, wherein the DRM information further comprises cryptographic information that can be used to decrypt at least the encrypted block of data indicated by the offset value and the number value.
  • 13. The method of claim 9, wherein the information indicative of the locations of chunks within the multimedia file from the first index includes a plurality of chunk offsets, wherein at least one of the plurality of chunk offsets indicates the location of the specific chunk identified using the first index within the multimedia file.
  • 14. The method of claim 9, wherein the second index further comprises frame type information.
  • 15. The method of claim 9, wherein the first index further comprises information indicative of locations of at least one encoded video frame within each chunk.
  • 16. The method of claim 9, wherein the second index is located at the end of the multimedia file.
  • 17. The method of claim 9, wherein the second index is distributed throughout the multimedia file.
  • 18. A method for playing back video stored in at least a portion of a multimedia file, wherein: the multimedia file comprises: a track of encoded video frames, where a number of the encoded video frames are at least partially encrypted encoded video frames that each include at least one encrypted block of data;a first index that includes information indicative of locations of chunks within the multimedia file, where: the chunks include segments of the track of encoded video frames; andthe information indicative of the locations of chunks within the multimedia file comprises a plurality of chunk offsets;a separate second index that includes information indicative of locations of each encoded video frame within the track of encoded video frames; anda set of digital rights management (DRM) information where comprising DRM information corresponding to an at least partially encrypted encoded video frame, where the DRM information corresponding to the at least partially encrypted encoded video frame comprises: an offset value that indicates the start of an encrypted block of data within the at least partially encrypted encoded video frame;a number value that indicates a size of the encrypted block of data; andcryptographic information that can be used to decrypt at least the encrypted block of data indicated by the offset value and the number value, wherein at least a first portion of the at least partially encrypted encoded video frame is encrypted and at least a second portion of the at least partially encrypted video frame is unencrypted; andthe method comprises: processing the first index to locate at least one chunk offset identifying a location of a specific chunk within the multimedia file;obtaining the specific chunk identified using the first index using the at least one chunk offset;processing the second index to identify location information for the at least partially encrypted encoded video frame within the specific chunk identified using the first index;locating the at least partially encrypted encoded video frame identified using the second index within the specific chunk identified using the first index;identifying the DRM information corresponding to the at least partially encrypted encoded video frame from the set of DRM information;decrypting the at least one encrypted block of data of the at least partially encrypted encoded video frame identified using the second index using the offset and number values, and the cryptographic information from the DRM information corresponding to the at least partially encrypted encoded video frame to obtain a decrypted encoded video frame, where the decryption of the at least partially encrypted encoded video frame occurs prior to decoding of the decrypted encoded video frame;decoding the decrypted encoded video frame to obtain a decoded video frame; andplaying back video frames including the decoded video frame.
  • 19. The method of claim 18, wherein the second index further comprises frame type information.
  • 20. The method of claim 18, wherein the first index further comprises information indicative of locations of at least one encoded video frame within each chunk.
  • 21. The method of claim 18, wherein the second index is located at the end of the multimedia file.
  • 22. The method of claim 18, wherein the second index is distributed throughout the multimedia file.
  • 23. The method of claim 18, wherein the first index further includes information indicative of timing information for the chunks within the multimedia file.
  • 24. The method of claim 18 further comprising: downloading a first portion of the multimedia file via a network; anddownloading a second portion of the multimedia file containing at least a portion of the second index via the network.
  • 25. The method of claim 18, wherein the first index further includes frame numbers indicative of the locations of the chunks within the multimedia file.
  • 26. The method of claim 25, wherein the frame number is an integer number indicating the location of a video frame in relation to the encoded video frames within the track.
  • 27. The method of claim 18, wherein the information indicative of the location of a given chunk comprises multiple pieces of information indicative of the location of the given chunk.
  • 28. A method for playing back video from a media file, wherein: the media file comprises: a track of encoded video frames;a first index that includes an entry for each of a plurality of chunks in the media file, where: each of the plurality of chunks in the media file includes a segment of the track of encoded video frames, the entry in the first index for a given chunk of the plurality of chunks in the media file contains information indicative of: a location of the given chunk within the media file; andtiming information for the given chunk; anda separate second index that includes an entry for each encoded video frame of the track of encoded video frames, where the entry in the second index for a given encoded video frame of the track of encoded video frames includes information indicative of a location of the given encoded video frame within the media file; andthe method comprises: downloading a first portion of the media file via a network;prior to downloading the second index, processing the first index to identify information indicative of a location of a specific chunk within the media file based upon a time value;downloading a second portion of the media file containing at least a portion of the second index via the network;processing the at least a portion of the second index to identify information indicative of a location of a particular encoded video frame within the specific chunk identified using the first index;decoding the particular encoded video frame located using the second index to obtain a decoded video frame within the specific chunk located using the first index; andplaying back video frames including the decoded video frame.
  • 29. The method of claim 28, wherein the first portion of the media file contains the specific chunk.
  • 30. The method of claim 28, wherein the second portion of the media file contains the specific chunk.
  • 31. The method of claim 28 further comprising downloading a third portion of the media file that contains the specific chunk.
  • 32. The method of claim 28, wherein the timing information for the given chunk comprises a reference to a frame in the given chunk.
  • 33. The method of claim 28, wherein the timing information comprises a frame number.
  • 34. The method of claim 28, wherein the first index contains information about less than all the encoded video frames in the track of encoded video frames.
  • 35. The method of claim 28 further comprising using the second index to identify frames which are not referenced by the first index.
  • 36. The method of claim 28, wherein each of the entries within the first index for each of the plurality of chunks also references a video frame.
  • 37. The method of claim 28, wherein sequential entries within the first index reference video frames equally spaced apart in time from each other.
  • 38. The method of claim 37, wherein the referenced video frames are spaced apart by 5 seconds.
  • 39. The method of claim 37, wherein the referenced video frames spaced are apart by 10 seconds.
  • 40. The method of claim 37, wherein the referenced video frames are spaced apart by 15 seconds.
  • 41. The method of claim 37, wherein the referenced video frames each identify at least one of: a start of a scene; and a chapter.
  • 42. The method of claim 37, wherein the referenced video frames are referenced by a position of the referenced video frames relative to other video frames within the track.
  • 43. The method of claim 28 further comprising using the timing information of the first index to skip between scenes.
  • 44. The method of claim 28 further comprising using the timing information of the first index to locate a video frame closest to a requested frame.
  • 45. The method of claim 44, wherein locating the video frame closest to the requested frame comprises: using the timing information associated with a first chunk to find a position of a first frame;using the timing information associated with a next chunk to find the position of a second frame;determining whether the frame resides between the first frame and the second frame;when the requested frame resides between the first frame and the second frame, determining that the first chunk is associated with the location of the video frame closest to the requested frame.
  • 46. The method of claim 28, wherein: the particular encoded video frame identified using the second index is at least partially encrypted; andthe method further comprises decrypting the particular encoded video frame that is at least partially encrypted prior to decoding.
  • 47. The method of claim 28, wherein at least a first portion of the particular encoded video frame identified using the second index is encrypted and at least a second portion is unencrypted.
  • 48. The method of claim 47, wherein: the media file comprises Digital Rights Management (DRM) information that identifies at least one portion of the particular encoded video frame identified using the second index that is encrypted; andthe method further comprises decrypting the at least one portion of the particular encoded video frame identified using the second index using the DRM information.
  • 49. The method of claim 48, wherein the DRM information further comprises cryptographic information that can be used to decrypt the at least one portion of the particular encoded video frame identified using the second index that is encrypted.
  • 50. The method of claim 48, wherein the DRM information comprises: an offset value that indicates the start of an encrypted block of data within the particular encoded video frame identified using the second index; and a number value that indicates a size of the encrypted block of data.
  • 51. The method of claim 50, wherein the DRM information further comprises cryptographic information that can be used to decrypt at least the encrypted block of data indicated by the offset value and the number value.
  • 52. A method for playing back video stored in at least a portion of a media file, wherein: the media file comprises: a track of encoded video frames, where a number of the encoded video frames are at least partially encrypted encoded video frames that include at least one encrypted block of data;a first index that includes an entry for each of a plurality of chunks in the media file, where: each of the plurality of chunks in the media file includes a segment of the track of encoded video frames, the entry in the first index for a given chunk of the plurality of chunks in the media file contains information indicative of: a location of the given chunk within the media file; andtiming information for the given chunk; anda separate second index that includes an entry for each encoded video frame of the track of encoded video frames, where the entry in the second index for a given encoded video frame of the track of encoded video frames includes information indicative of a location of the given encoded video frame within the media file; anda set of digital rights management (DRM) information comprising DRM information corresponding to an at least partially encrypted encoded video frame, where the DRM information corresponding to the at least partially encrypted encoded video frame comprises: an offset value that indicates the start of an encrypted block of data within the at least partially encrypted encoded video frame;a number value that indicates a size of the encrypted block of data; andcryptographic information that can be used to decrypt at least the encrypted block of data indicated by the offset value and the number value;wherein at least a first portion of the at least partially encrypted encoded video frame is encrypted and at least a second portion of the at least partially encrypted video frame is unencrypted; andthe method comprises: downloading a first portion of the media file via a network;prior to downloading the second index, processing the first index to identify information indicative of a location of a specific chunk within the media file based upon a time value;downloading a second portion of the media file containing at least a portion of the second index via the network;processing the at least a portion of the second index to identify information indicative of a location for the at least partially encrypted encoded video frame within the specific chunk identified using the first index;identifying the DRM information corresponding to the at least partially encrypted encoded video frame from the set of DRM information;decrypting the at least one encrypted block of data of the at least partially encrypted encoded video frame using the offset and number values, and the cryptographic information from the DRM information corresponding to the at least partially encrypted encoded video frame to obtain a decrypted encoded video frame, where the decryption of the at least partially encrypted encoded video frame occurs prior to decoding of the decrypted encoded video frame;decoding the decrypted encoded video frame to obtain a decoded video frame; andplaying back video frames including the decoded video frame.
Priority Claims (1)
Number Date Country Kind
PCT/US2004/041667 Dec 2004 WO international
CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of U.S. patent application Ser. No. 17/453,314 filed Nov. 2, 2021, entitled “Multimedia Distribution System”, which application continuation of U.S. patent application Ser. No. 17/307,990 filed May 4, 2021, entitled “Multimedia Distribution System”, which application continuation of U.S. patent application Ser. No. 16/039,752 filed Jul. 19, 2018, entitled “Multimedia Distribution System” and issued on May 25, 2021 as U.S. Pat. No. 11,017,816, which application is a continuation of U.S. patent application Ser. No. 15/217,894 filed Jul. 22, 2016, entitled “Multimedia Distribution System” and issued on Jul. 24, 2018 as U.S. Pat. No. 10,032,485, which application is a continuation of U.S. patent application Ser. No. 13/913,187 filed Jun. 7, 2013, entitled “Multimedia Distribution System” and issued on Aug. 16, 2016 as U.S. Pat. No. 9,420,287, which application is a continuation of U.S. patent application Ser. No. 11/258,496 filed Oct. 24, 2005, entitled “Multimedia Distribution System” and issued on Jun. 25, 2013 as U.S. Pat. No. 8,472,792, which application is a continuation-in-part of U.S. patent application Ser. No. 11/016,184, filed on Dec. 17, 2004, entitled “Multimedia Distribution System” and issued on May 20, 2014 as U.S. Pat. No. 8,731,369, which application is a continuation-in-part of U.S. patent application Ser. No. 10/731,809, filed on Dec. 8, 2003, entitled “File Format for Multiple Track Digital Data” and issued on Apr. 14, 2009 as U.S. Pat. No. 7,519,274, and also claims priority from Patent Cooperation Treaty Patent Application No. PCT/US2004/041667, filed on Dec. 8, 2004, entitled “Multimedia Distribution System”, the disclosures of which are incorporated herein by reference in their entirety.

US Referenced Citations (685)
Number Name Date Kind
3609227 Kuljian Sep 1971 A
4009331 Goldmark et al. Feb 1977 A
4694357 Rahman et al. Sep 1987 A
4694491 Horne et al. Sep 1987 A
4802170 Trottier Jan 1989 A
4964069 Ely Oct 1990 A
5119474 Beitel et al. Jun 1992 A
5132992 Yurt et al. Jul 1992 A
5274758 Beitel et al. Dec 1993 A
5341474 Gelman et al. Aug 1994 A
5361332 Yoshida et al. Nov 1994 A
5396497 Veltman Mar 1995 A
5400401 Wasilewski et al. Mar 1995 A
5404436 Hamilton Apr 1995 A
5412773 Carlucci et al. May 1995 A
5420801 Dockter et al. May 1995 A
5420974 Morris et al. May 1995 A
5428529 Hartrick et al. Jun 1995 A
5471576 Yee Nov 1995 A
5477263 Ocallaghan et al. Dec 1995 A
5485611 Astle Jan 1996 A
5487167 Dinallo et al. Jan 1996 A
5533021 Branstad et al. Jul 1996 A
5537408 Branstad et al. Jul 1996 A
5539908 Chen et al. Jul 1996 A
5541662 Adams et al. Jul 1996 A
5544318 Schmitz et al. Aug 1996 A
5550863 Yurt et al. Aug 1996 A
5574785 Ueno et al. Nov 1996 A
5583652 Ware Dec 1996 A
5600721 Kitazato Feb 1997 A
5614940 Cobbley et al. Mar 1997 A
5619338 Nakai et al. Apr 1997 A
5621794 Matsuda et al. Apr 1997 A
5627936 Prasad et al. May 1997 A
5630005 Ort May 1997 A
5633472 DeWitt et al. May 1997 A
5642171 Baumgartner et al. Jun 1997 A
5642338 Fukushima et al. Jun 1997 A
5655117 Goldberg et al. Aug 1997 A
5664044 Ware Sep 1997 A
5675382 Bauchspies Oct 1997 A
5675511 Prasad et al. Oct 1997 A
5684542 Tsukagoshi Nov 1997 A
5715356 Hirayama et al. Feb 1998 A
5719786 Nelson et al. Feb 1998 A
5745643 Mishina Apr 1998 A
5751280 Abbott May 1998 A
5761417 Henley et al. Jun 1998 A
5763800 Rossum et al. Jun 1998 A
5765164 Prasad et al. Jun 1998 A
5794018 Vrvilo et al. Aug 1998 A
5805700 Nardone et al. Sep 1998 A
5809173 Liu et al. Sep 1998 A
5813010 Kurano et al. Sep 1998 A
5822524 Chen et al. Oct 1998 A
5828370 Moeller et al. Oct 1998 A
5838791 Torii et al. Nov 1998 A
5844575 Reid Dec 1998 A
5848217 Tsukagoshi et al. Dec 1998 A
5852664 Iverson et al. Dec 1998 A
5854873 Mori et al. Dec 1998 A
5874986 Gibbon et al. Feb 1999 A
5878135 Blatter et al. Mar 1999 A
5892915 Duso et al. Apr 1999 A
5903261 Walsh et al. May 1999 A
5907597 Mark May 1999 A
5907658 Murase et al. May 1999 A
5915066 Katayama Jun 1999 A
5923869 Kashiwagi et al. Jul 1999 A
5956729 Goetz et al. Sep 1999 A
5959690 Toebes, VIII et al. Sep 1999 A
5970147 Davis Oct 1999 A
5973679 Abbott et al. Oct 1999 A
6002834 Hirabayashi et al. Dec 1999 A
6009237 Hirabayashi et al. Dec 1999 A
6016381 Taira et al. Jan 2000 A
6021199 Ishibashi Feb 2000 A
6031622 Ristow et al. Feb 2000 A
6038000 Hurst, Jr. Mar 2000 A
6038316 Dwork et al. Mar 2000 A
6044175 Taira et al. Mar 2000 A
6046778 Nonomura et al. Apr 2000 A
6057832 Lev et al. May 2000 A
6065050 DeMoney May 2000 A
6079566 Eleftheriadis et al. Jun 2000 A
6108422 Newby et al. Aug 2000 A
6151634 Glaser et al. Nov 2000 A
6169242 Fay et al. Jan 2001 B1
6195388 Choi et al. Feb 2001 B1
6199107 Dujari Mar 2001 B1
6204883 Tsukagoshi Mar 2001 B1
6219043 Yogeshwar et al. Apr 2001 B1
6253025 Kitamura et al. Jun 2001 B1
6266483 Okada et al. Jul 2001 B1
6269063 Fujinami et al. Jul 2001 B1
6282320 Hasegawa et al. Aug 2001 B1
6308005 Ando et al. Oct 2001 B1
6320905 Konstantinides Nov 2001 B1
6330286 Lyons et al. Dec 2001 B1
6347145 Kato et al. Feb 2002 B2
6351538 Uz Feb 2002 B1
6373803 Ando et al. Apr 2002 B2
6374144 Viviani et al. Apr 2002 B1
6389473 Carmel et al. May 2002 B1
6395969 Fuhrer May 2002 B1
6415031 Colligan et al. Jul 2002 B1
6445877 Okada et al. Sep 2002 B1
6453115 Boyle Sep 2002 B1
6453116 Ando et al. Sep 2002 B1
6498865 Brailean et al. Dec 2002 B1
6504873 Vehvilaeinen Jan 2003 B1
6512883 Shim et al. Jan 2003 B2
6516064 Osawa et al. Feb 2003 B1
6535920 Parry et al. Mar 2003 B1
6573907 Madrane Jun 2003 B1
6578200 Takao et al. Jun 2003 B1
6594699 Sahai et al. Jul 2003 B1
6611537 Edens et al. Aug 2003 B1
6654933 Abbott et al. Nov 2003 B1
6658056 Duruöz et al. Dec 2003 B1
6665835 Gutfreund et al. Dec 2003 B1
6671408 Kaku Dec 2003 B1
6690838 Zhou Feb 2004 B2
6693959 Eckart et al. Feb 2004 B1
6697568 Kaku Feb 2004 B1
6714984 Jones et al. Mar 2004 B2
6721794 Taylor et al. Apr 2004 B2
6724944 Kalevo et al. Apr 2004 B1
6725281 Zintel et al. Apr 2004 B1
6742082 Lango et al. May 2004 B1
6751623 Basso et al. Jun 2004 B1
6807306 Girgensohn et al. Oct 2004 B1
6810131 Nakagawa et al. Oct 2004 B2
6813437 Ando et al. Nov 2004 B2
6819394 Nomura et al. Nov 2004 B1
6856997 Lee et al. Feb 2005 B2
6859496 Boroczky et al. Feb 2005 B1
6865747 Mercier Mar 2005 B1
6871006 Oguz et al. Mar 2005 B1
6912513 Candelore Jun 2005 B1
6917652 Lyu Jul 2005 B2
6931531 Takahashi Aug 2005 B1
6931534 Jandel et al. Aug 2005 B1
6931543 Pang et al. Aug 2005 B1
6944621 Collart Sep 2005 B1
6944629 Shioi et al. Sep 2005 B1
6956901 Boroczky et al. Oct 2005 B2
6957350 Demos Oct 2005 B1
6965646 Firestone Nov 2005 B1
6970564 Kubota et al. Nov 2005 B1
6983079 Kim Jan 2006 B2
6985588 Glick et al. Jan 2006 B1
6988144 Luken et al. Jan 2006 B1
7006757 Ando et al. Feb 2006 B2
7007170 Morten Feb 2006 B2
7020287 Unger Mar 2006 B2
7023992 Kubota et al. Apr 2006 B1
7035335 Iacobelli et al. Apr 2006 B1
7043021 Graunke et al. May 2006 B2
7051110 Hagai et al. May 2006 B2
7058177 Trimberger et al. Jun 2006 B1
7073191 Srikantan et al. Jul 2006 B2
7103906 Katz et al. Sep 2006 B1
7110542 Tripathy Sep 2006 B1
7120250 Candelore Oct 2006 B2
7124303 Candelore et al. Oct 2006 B2
7127155 Ando et al. Oct 2006 B2
7139470 Lopez-estrada et al. Nov 2006 B2
7139868 Parry et al. Nov 2006 B2
7143289 Denning et al. Nov 2006 B2
7151832 Fetkovich et al. Dec 2006 B1
7167560 Yu Jan 2007 B2
7188183 Paul et al. Mar 2007 B1
7203313 England et al. Apr 2007 B2
7206940 Evans et al. Apr 2007 B2
7209892 Galuten et al. Apr 2007 B1
7212726 Zetts May 2007 B2
7231516 Sparrell et al. Jun 2007 B1
7233669 Candelore Jun 2007 B2
7233948 Shamoon et al. Jun 2007 B1
7237061 Boic Jun 2007 B1
7242772 Tehranchi Jul 2007 B1
7243346 Seth et al. Jul 2007 B1
7246127 Murakami et al. Jul 2007 B2
7274861 Yahata et al. Sep 2007 B2
7292691 Candelore et al. Nov 2007 B2
7295673 Grab et al. Nov 2007 B2
7302059 Candelore et al. Nov 2007 B2
7302490 Gupta et al. Nov 2007 B1
7315829 Tagawa et al. Jan 2008 B1
7330875 Parasnis et al. Feb 2008 B1
7340528 Noblecourt et al. Mar 2008 B2
7346163 Pedlow, Jr. et al. Mar 2008 B2
7349886 Morten et al. Mar 2008 B2
7349976 Glaser et al. Mar 2008 B1
7352956 Winter et al. Apr 2008 B1
7356245 Belknap et al. Apr 2008 B2
7363647 Fakharzadeh Apr 2008 B1
7366788 Jones et al. Apr 2008 B2
7376233 Candelore et al. May 2008 B2
7380120 Garcia May 2008 B1
7382879 Miller Jun 2008 B1
7397853 Kwon et al. Jul 2008 B2
7400679 Kwon et al. Jul 2008 B2
7406176 Zhu et al. Jul 2008 B2
7418132 Hoshuyama Aug 2008 B2
7443449 Momosaki et al. Oct 2008 B2
7454780 Katsube et al. Nov 2008 B2
7457359 Mabey et al. Nov 2008 B2
7457415 Reitmeier et al. Nov 2008 B2
7478325 Foehr Jan 2009 B2
7484103 Woo et al. Jan 2009 B2
7493018 Kim Feb 2009 B2
7499930 Naka et al. Mar 2009 B2
7499938 Collart Mar 2009 B2
7519274 Li Apr 2009 B2
7539213 Guillemot et al. May 2009 B2
7546641 Robert et al. Jun 2009 B2
7548565 Sull et al. Jun 2009 B2
7577980 Kienzle et al. Aug 2009 B2
7623759 Shimoda Nov 2009 B2
7624337 Sull et al. Nov 2009 B2
7627750 Chan Dec 2009 B1
7627888 Ganesan et al. Dec 2009 B2
7639921 Seo et al. Dec 2009 B2
7640435 Morten Dec 2009 B2
7644172 Stewart et al. Jan 2010 B2
7653686 Yoneda Jan 2010 B2
7664872 Osborne et al. Feb 2010 B2
7681035 Ayars et al. Mar 2010 B1
7702925 Hanko et al. Apr 2010 B2
7711052 Hannuksela et al. May 2010 B2
7747853 Candelore Jun 2010 B2
7756270 Shimosato et al. Jul 2010 B2
7756271 Zhu et al. Jul 2010 B2
7787622 Sprunk Aug 2010 B2
7788271 Soma et al. Aug 2010 B2
7797720 Gopalakrishnan et al. Sep 2010 B2
7853980 Pedlow, Jr. et al. Dec 2010 B2
7864186 Robotham et al. Jan 2011 B2
7869691 Kelly et al. Jan 2011 B2
7877002 Ikeda et al. Jan 2011 B2
7881478 Derouet Feb 2011 B2
7882034 Hug et al. Feb 2011 B2
7885405 Bong Feb 2011 B1
7895616 Unger Feb 2011 B2
7907833 Lee Mar 2011 B2
7945143 Yahata et al. May 2011 B2
7949703 Matsuzaki et al. May 2011 B2
7974714 Hoffberg Jul 2011 B2
8023562 Zheludkov et al. Sep 2011 B2
8046453 Olaiya Oct 2011 B2
8054880 Yu et al. Nov 2011 B2
8073900 Guedalia et al. Dec 2011 B2
8082442 Keljo et al. Dec 2011 B2
8131875 Chen Mar 2012 B1
8135041 Ramaswamy Mar 2012 B2
8160157 Lamy-Bergot et al. Apr 2012 B2
8169916 Pai et al. May 2012 B1
8170210 Manders et al. May 2012 B2
8195714 Mckibben et al. Jun 2012 B2
8218439 Deshpande Jul 2012 B2
8225061 Greenebaum Jul 2012 B2
8233768 Soroushian et al. Jul 2012 B2
8243924 Chen et al. Aug 2012 B2
8249168 Graves Aug 2012 B2
8270473 Chen et al. Sep 2012 B2
8270819 Vannier Sep 2012 B2
8286213 Seo Oct 2012 B2
8289338 Priyadarshi et al. Oct 2012 B2
8311094 Kamariotis et al. Nov 2012 B2
8311115 Gu et al. Nov 2012 B2
8312079 Newsome et al. Nov 2012 B2
8321556 Chatterjee et al. Nov 2012 B1
8341715 Sherkin et al. Dec 2012 B2
8369421 Kadono et al. Feb 2013 B2
8380041 Barton et al. Feb 2013 B2
8386621 Park Feb 2013 B2
8396114 Gu et al. Mar 2013 B2
8397265 Henocq et al. Mar 2013 B2
8407753 Kuo Mar 2013 B2
8423889 Zagorie et al. Apr 2013 B1
8456380 Pagan Jun 2013 B2
8472792 Butt et al. Jun 2013 B2
8526610 Shamoon et al. Sep 2013 B2
8543842 Ginter et al. Sep 2013 B2
8555329 Fröjdh et al. Oct 2013 B2
8571993 Kocher et al. Oct 2013 B2
8595760 Singh Nov 2013 B1
8649669 Braness et al. Feb 2014 B2
8650599 Shindo et al. Feb 2014 B2
8677428 Lewis et al. Mar 2014 B2
8683066 Hurst et al. Mar 2014 B2
8731369 Li et al. May 2014 B2
RE45052 Li Jul 2014 E
8767825 Wang et al. Jul 2014 B1
8782268 Pyle et al. Jul 2014 B2
8818896 Candelore Aug 2014 B2
8819116 Tomay et al. Aug 2014 B1
8832434 Apostolopoulos et al. Sep 2014 B2
8849950 Stockhammer et al. Sep 2014 B2
8856218 Inskip Oct 2014 B1
8914534 Braness et al. Dec 2014 B2
8918535 Ma et al. Dec 2014 B2
8948249 Sun et al. Feb 2015 B2
9025659 Soroushian et al. May 2015 B2
9038116 Knox et al. May 2015 B1
9203816 Brueck et al. Dec 2015 B2
9215466 Zhai et al. Dec 2015 B2
9253178 Blom et al. Feb 2016 B2
9344721 Dikvall May 2016 B2
9369687 Braness et al. Jun 2016 B2
9420287 Butt et al. Aug 2016 B2
9479805 Rothschild et al. Oct 2016 B2
9485469 Kahn et al. Nov 2016 B2
9485546 Chen et al. Nov 2016 B2
9584557 Panje et al. Feb 2017 B2
9584847 Ma et al. Feb 2017 B2
9615061 Carney et al. Apr 2017 B2
9674254 Pare et al. Jun 2017 B2
9761274 Delpuch et al. Sep 2017 B2
9813740 Panje et al. Nov 2017 B2
9967521 Kahn et al. May 2018 B2
10032485 Ahsan et al. Jul 2018 B2
10141024 Soroushian et al. Nov 2018 B2
10171873 Krebs Jan 2019 B2
10257443 Braness et al. Apr 2019 B2
10708521 Braness et al. Jul 2020 B2
10902883 Soroushian et al. Jan 2021 B2
11012641 Braness et al. May 2021 B2
11017816 Ahsan et al. May 2021 B2
11159746 Braness et al. Oct 2021 B2
11297263 Braness et al. Apr 2022 B2
11355159 Ahsan et al. Jun 2022 B2
11495266 Soroushian et al. Nov 2022 B2
11509839 Braness et al. Nov 2022 B2
20010021276 Zhou Sep 2001 A1
20010030710 Werner Oct 2001 A1
20010052077 Fung et al. Dec 2001 A1
20010052127 Seo et al. Dec 2001 A1
20010053222 Wakao et al. Dec 2001 A1
20020018475 Ofek et al. Feb 2002 A1
20020034252 Owen et al. Mar 2002 A1
20020048450 Zetts Apr 2002 A1
20020051494 Yamaguchi et al. May 2002 A1
20020062313 Lee et al. May 2002 A1
20020067432 Kondo et al. Jun 2002 A1
20020075572 Boreczky et al. Jun 2002 A1
20020076112 Devara Jun 2002 A1
20020087569 Fischer et al. Jul 2002 A1
20020091665 Beek et al. Jul 2002 A1
20020093571 Hyodo Jul 2002 A1
20020107802 Philips Aug 2002 A1
20020110193 Yoo et al. Aug 2002 A1
20020114330 Cheung et al. Aug 2002 A1
20020118953 Kim Aug 2002 A1
20020135607 Kato et al. Sep 2002 A1
20020141503 Kobayashi et al. Oct 2002 A1
20020143413 Fay et al. Oct 2002 A1
20020143547 Fay et al. Oct 2002 A1
20020147980 Satoda Oct 2002 A1
20020154779 Asano et al. Oct 2002 A1
20020161462 Fay et al. Oct 2002 A1
20020161797 Gallo et al. Oct 2002 A1
20020164024 Arakawa et al. Nov 2002 A1
20020169926 Pinckney et al. Nov 2002 A1
20020169971 Asano et al. Nov 2002 A1
20020180929 Tseng et al. Dec 2002 A1
20020184129 Arena et al. Dec 2002 A1
20020184159 Tadayon et al. Dec 2002 A1
20020184515 Oho et al. Dec 2002 A1
20020186842 Sabet-Sharghi et al. Dec 2002 A1
20020191112 Akiyoshi et al. Dec 2002 A1
20020191960 Fujinami et al. Dec 2002 A1
20020194606 Tucker et al. Dec 2002 A1
20020198846 Lao Dec 2002 A1
20030001964 Masukura et al. Jan 2003 A1
20030002577 Pinder Jan 2003 A1
20030002578 Tsukagoshi et al. Jan 2003 A1
20030005442 Brodersen et al. Jan 2003 A1
20030031128 Kim et al. Feb 2003 A1
20030035488 Barrau Feb 2003 A1
20030043847 Haddad Mar 2003 A1
20030044080 Frishman et al. Mar 2003 A1
20030051149 Robert Mar 2003 A1
20030051237 Sako et al. Mar 2003 A1
20030053541 Sun et al. Mar 2003 A1
20030061369 Aksu et al. Mar 2003 A1
20030063675 Kang et al. Apr 2003 A1
20030077071 Lin et al. Apr 2003 A1
20030078930 Surcouf et al. Apr 2003 A1
20030079222 Boykin et al. Apr 2003 A1
20030080980 Riek et al. May 2003 A1
20030081776 Candelore May 2003 A1
20030093799 Kauffman et al. May 2003 A1
20030047262 Xue et al. Jun 2003 A1
20030123855 Okada et al. Jul 2003 A1
20030128296 Lee Jul 2003 A1
20030131117 Jones et al. Jul 2003 A1
20030133506 Haneda Jul 2003 A1
20030135633 Dror et al. Jul 2003 A1
20030135742 Evans Jul 2003 A1
20030142594 Tsumagari et al. Jul 2003 A1
20030152224 Candelore et al. Aug 2003 A1
20030152370 Otomo et al. Aug 2003 A1
20030159139 Candelore et al. Aug 2003 A1
20030165328 Grecia Sep 2003 A1
20030182297 Murakami et al. Sep 2003 A1
20030185302 Abrams Oct 2003 A1
20030185542 McVeigh et al. Oct 2003 A1
20030188182 Sato et al. Oct 2003 A1
20030202773 Dow et al. Oct 2003 A1
20030206558 Parkkinen et al. Nov 2003 A1
20030206717 Yogeshwar et al. Nov 2003 A1
20030212993 Obrador Nov 2003 A1
20030216922 Gonzales et al. Nov 2003 A1
20030231863 Eerenberg et al. Dec 2003 A1
20030231867 Gates et al. Dec 2003 A1
20030236836 Borthwick Dec 2003 A1
20030236907 Stewart et al. Dec 2003 A1
20040001594 Krishnaswamy et al. Jan 2004 A1
20040003008 Wasilewski et al. Jan 2004 A1
20040006701 Kresina Jan 2004 A1
20040021684 Millner Feb 2004 A1
20040022391 Obrien Feb 2004 A1
20040025180 Begeja et al. Feb 2004 A1
20040028227 Yu Feb 2004 A1
20040037421 Truman Feb 2004 A1
20040047592 Seo et al. Mar 2004 A1
20040047607 Seo et al. Mar 2004 A1
20040047614 Green Mar 2004 A1
20040049690 Candelore et al. Mar 2004 A1
20040049694 Candelore Mar 2004 A1
20040052501 Tam Mar 2004 A1
20040071453 Valderas Apr 2004 A1
20040073917 Pedlow et al. Apr 2004 A1
20040076237 Kadono et al. Apr 2004 A1
20040081333 Grab et al. Apr 2004 A1
20040088557 Malcolm et al. May 2004 A1
20040091247 Shimomura et al. May 2004 A1
20040093494 Nishimoto et al. May 2004 A1
20040101059 Joch et al. May 2004 A1
20040101142 Nasypny May 2004 A1
20040107356 Shamoon et al. Jun 2004 A1
20040114687 Ferris et al. Jun 2004 A1
20040117347 Seo et al. Jun 2004 A1
20040123094 Sprunk Jun 2004 A1
20040136698 Mock Jul 2004 A1
20040143760 Alkove et al. Jul 2004 A1
20040146276 Ogawa Jul 2004 A1
20040196975 Zhu et al. Oct 2004 A1
20040202322 Chavanne et al. Oct 2004 A1
20040213094 Suzuki Oct 2004 A1
20040217971 Kim Nov 2004 A1
20040243714 Wynn et al. Dec 2004 A1
20040255236 Collart Dec 2004 A1
20040267952 He et al. Dec 2004 A1
20050005025 Harville et al. Jan 2005 A1
20050005143 Lang et al. Jan 2005 A1
20050013494 Srinivasan et al. Jan 2005 A1
20050015797 Noblecourt et al. Jan 2005 A1
20050019014 Yoo et al. Jan 2005 A1
20050038826 Bae et al. Feb 2005 A1
20050055399 Savchuk Mar 2005 A1
20050063541 Candelore Mar 2005 A1
20050066063 Grigorovitch et al. Mar 2005 A1
20050076232 Kawaguchi Apr 2005 A1
20050078948 Yoo et al. Apr 2005 A1
20050086501 Woo et al. Apr 2005 A1
20050102371 Aksu May 2005 A1
20050114534 Lee May 2005 A1
20050120132 Hutter Jun 2005 A1
20050123136 Shin et al. Jun 2005 A1
20050123283 Li et al. Jun 2005 A1
20050138655 Zimler et al. Jun 2005 A1
20050144468 Northcutt Jun 2005 A1
20050154987 Otsuka et al. Jul 2005 A1
20050177741 Chen et al. Aug 2005 A1
20050180641 Clark Aug 2005 A1
20050180733 Yatomi Aug 2005 A1
20050190911 Pare et al. Sep 2005 A1
20050192904 Candelore Sep 2005 A1
20050193070 Brown et al. Sep 2005 A1
20050193322 Lamkin et al. Sep 2005 A1
20050196147 Seo et al. Sep 2005 A1
20050198364 Vai et al. Sep 2005 A1
20050207442 Zoest et al. Sep 2005 A1
20050207578 Matsuyama et al. Sep 2005 A1
20050216752 Hofmeyr et al. Sep 2005 A1
20050227773 Lu et al. Oct 2005 A1
20050243912 Kwon et al. Nov 2005 A1
20050262257 Major et al. Nov 2005 A1
20050265555 Pippuri Dec 2005 A1
20050271353 Kelly et al. Dec 2005 A1
20050273695 Schnurr Dec 2005 A1
20050275656 Corbin et al. Dec 2005 A1
20060013568 Rodriguez Jan 2006 A1
20060026302 Bennett et al. Feb 2006 A1
20060026654 An et al. Feb 2006 A1
20060037057 Xu Feb 2006 A1
20060072509 Lindoff et al. Apr 2006 A1
20060078301 Ikeda et al. Apr 2006 A1
20060093318 Cohen et al. May 2006 A1
20060093320 Hallberg et al. May 2006 A1
20060095472 Krikorian et al. May 2006 A1
20060109856 Deshpande May 2006 A1
20060129909 Butt et al. Jun 2006 A1
20060165163 Burazerovic et al. Jul 2006 A1
20060168298 Aoki et al. Jul 2006 A1
20060168639 Gan et al. Jul 2006 A1
20060173887 Breitfeld et al. Aug 2006 A1
20060181965 Collart Aug 2006 A1
20060210245 Mccrossan et al. Sep 2006 A1
20060212370 Shear et al. Sep 2006 A1
20060218251 Tanabe Sep 2006 A1
20060235880 Qian Oct 2006 A1
20060235883 Krebs Oct 2006 A1
20060245727 Nakano et al. Nov 2006 A1
20060259588 Lerman et al. Nov 2006 A1
20060263056 Lin et al. Nov 2006 A1
20060267986 Bae Nov 2006 A1
20060274835 Hamilton et al. Dec 2006 A1
20070005333 Setiohardjo et al. Jan 2007 A1
20070031110 Rijckaert Feb 2007 A1
20070044010 Sull et al. Feb 2007 A1
20070047645 Takashima Mar 2007 A1
20070047901 Ando et al. Mar 2007 A1
20070055982 Spilo Mar 2007 A1
20070067472 Maertens et al. Mar 2007 A1
20070083467 Lindahl et al. Apr 2007 A1
20070083617 Chakrabarti et al. Apr 2007 A1
20070086528 Mauchly et al. Apr 2007 A1
20070140647 Kusunoki et al. Jun 2007 A1
20070154165 Hemmeryckz-Deleersnijder et al. Jul 2007 A1
20070162981 Morioka et al. Jul 2007 A1
20070166000 Nallur et al. Jul 2007 A1
20070168287 Mccarthy et al. Jul 2007 A1
20070168541 Gupta et al. Jul 2007 A1
20070168542 Gupta et al. Jul 2007 A1
20070180051 Kelly et al. Aug 2007 A1
20070180125 Knowles et al. Aug 2007 A1
20070239839 Buday et al. Oct 2007 A1
20070250536 Tanaka et al. Oct 2007 A1
20070292107 Yahata et al. Dec 2007 A1
20080008455 De Lange et al. Jan 2008 A1
20080022005 Wu et al. Jan 2008 A1
20080077592 Brodie et al. Mar 2008 A1
20080080842 Katsuo et al. Apr 2008 A1
20080086570 Dey et al. Apr 2008 A1
20080101466 Swenson et al. May 2008 A1
20080101718 Yang et al. May 2008 A1
20080104633 Noblecourt et al. May 2008 A1
20080120330 Reed et al. May 2008 A1
20080120342 Reed et al. May 2008 A1
20080126248 Lee et al. May 2008 A1
20080137736 Richardson et al. Jun 2008 A1
20080137847 Candelore et al. Jun 2008 A1
20080137848 Kocher et al. Jun 2008 A1
20080177775 Kawate et al. Jul 2008 A1
20080192818 DiPietro et al. Aug 2008 A1
20080201705 Wookey Aug 2008 A1
20080256105 Nogawa et al. Oct 2008 A1
20080263354 Beuque et al. Oct 2008 A1
20080279535 Haque et al. Nov 2008 A1
20080294691 Chang et al. Nov 2008 A1
20080310496 Fang Dec 2008 A1
20090010622 Yahata et al. Jan 2009 A1
20090013195 Ochi et al. Jan 2009 A1
20090031220 Tranchant et al. Jan 2009 A1
20090037959 Suh et al. Feb 2009 A1
20090060452 Chaudhri Mar 2009 A1
20090064341 Hartung et al. Mar 2009 A1
20090066839 Jung et al. Mar 2009 A1
20090067367 Buracchini et al. Mar 2009 A1
20090077143 Macy, Jr. Mar 2009 A1
20090106082 Senti et al. Apr 2009 A1
20090132599 Soroushian et al. May 2009 A1
20090132721 Soroushian et al. May 2009 A1
20090150557 Wormley et al. Jun 2009 A1
20090165148 Frey et al. Jun 2009 A1
20090169181 Priyadarshi et al. Jul 2009 A1
20090178090 Oztaskent Jul 2009 A1
20090201988 Gazier et al. Aug 2009 A1
20090226148 Nesvadba et al. Sep 2009 A1
20090245749 Ueda et al. Oct 2009 A1
20090249081 Zayas Oct 2009 A1
20090282162 Mehrotra et al. Nov 2009 A1
20090293116 DeMello Nov 2009 A1
20090303241 Priyadarshi et al. Dec 2009 A1
20090307258 Priyadarshi et al. Dec 2009 A1
20090307267 Chen et al. Dec 2009 A1
20090310819 Hatano Dec 2009 A1
20090313544 Wood et al. Dec 2009 A1
20090313564 Rottler et al. Dec 2009 A1
20090319563 Schnell Dec 2009 A1
20090328124 Khouzam et al. Dec 2009 A1
20100040351 Toma et al. Feb 2010 A1
20100094969 Zuckerman et al. Apr 2010 A1
20100095121 Shetty et al. Apr 2010 A1
20100104261 Liu et al. Apr 2010 A1
20100111192 Graves May 2010 A1
20100142915 Mcdermott et al. Jun 2010 A1
20100158109 Dahlby et al. Jun 2010 A1
20100189183 Gu et al. Jul 2010 A1
20100218208 Holden Aug 2010 A1
20100228795 Hahn Sep 2010 A1
20110010466 Fan et al. Jan 2011 A1
20110055585 Lee Mar 2011 A1
20110058675 Brueck et al. Mar 2011 A1
20110080940 Bocharov Apr 2011 A1
20110083009 Shamoon et al. Apr 2011 A1
20110096828 Chen et al. Apr 2011 A1
20110103374 Lajoie et al. May 2011 A1
20110126191 Hughes et al. May 2011 A1
20110129011 Cilli et al. Jun 2011 A1
20110135090 Chan et al. Jun 2011 A1
20110142415 Rhyu Jun 2011 A1
20110145858 Philpott et al. Jun 2011 A1
20110150100 Abadir Jun 2011 A1
20110153785 Minborg et al. Jun 2011 A1
20110173345 Knox et al. Jul 2011 A1
20110179185 Wang et al. Jul 2011 A1
20110197261 Dong et al. Aug 2011 A1
20110197267 Gravel et al. Aug 2011 A1
20110239078 Luby et al. Sep 2011 A1
20110246659 Bouazizi Oct 2011 A1
20110246661 Manzari et al. Oct 2011 A1
20110268178 Park et al. Nov 2011 A1
20110296048 Knox et al. Dec 2011 A1
20110302319 Ha et al. Dec 2011 A1
20110305273 He et al. Dec 2011 A1
20110314130 Strasman Dec 2011 A1
20110314176 Frojdh et al. Dec 2011 A1
20110314500 Gordon Dec 2011 A1
20120005312 Mcgowan et al. Jan 2012 A1
20120017282 Kang et al. Jan 2012 A1
20120023251 Pyle et al. Jan 2012 A1
20120042090 Chen et al. Feb 2012 A1
20120047542 Lewis et al. Feb 2012 A1
20120093214 Urbach Apr 2012 A1
20120110120 Willig et al. May 2012 A1
20120167132 Mathews et al. Jun 2012 A1
20120170642 Braness et al. Jul 2012 A1
20120170643 Soroushian et al. Jul 2012 A1
20120170906 Soroushian et al. Jul 2012 A1
20120170915 Braness et al. Jul 2012 A1
20120173751 Braness et al. Jul 2012 A1
20120278496 Hsu Nov 2012 A1
20120307883 Graves Dec 2012 A1
20120311174 Bichot et al. Dec 2012 A1
20120331167 Hunt Dec 2012 A1
20130013803 Bichot et al. Jan 2013 A1
20130044821 Braness et al. Feb 2013 A1
20130046902 Villegas Nuñez et al. Feb 2013 A1
20130055084 Soroushian et al. Feb 2013 A1
20130061045 Kiefer et al. Mar 2013 A1
20130080267 McGowan Mar 2013 A1
20130196292 Brennen et al. Aug 2013 A1
20140140253 Lohmar et al. May 2014 A1
20140149557 Lohmar et al. May 2014 A1
20140211840 Butt et al. Jul 2014 A1
20140250473 Braness et al. Sep 2014 A1
20150104153 Braness et al. Apr 2015 A1
20150288530 Oyman Oct 2015 A1
20160360123 Braness et al. Dec 2016 A1
20170004862 Soroushian et al. Jan 2017 A1
20170011055 Pitts Jan 2017 A1
20170025157 Ahsan et al. Jan 2017 A1
20180046949 Kahn et al. Feb 2018 A1
20180255366 Lockett et al. Sep 2018 A1
20180270497 Mukherjee et al. Sep 2018 A1
20190080723 Ahsan et al. Mar 2019 A1
20190096440 Soroushian et al. Mar 2019 A1
20190289226 Braness et al. Sep 2019 A1
20200288069 Braness et al. Sep 2020 A1
20210258514 Braness et al. Aug 2021 A1
20210398566 Soroushian et al. Dec 2021 A1
20220046188 Braness et al. Feb 2022 A1
20220051697 Ahsan et al. Feb 2022 A1
20220076709 Ahsan et al. Mar 2022 A1
20220086485 Côté et al. Mar 2022 A1
20220256102 Braness et al. Aug 2022 A1
20220345643 Braness et al. Oct 2022 A1
20220408032 Braness et al. Dec 2022 A1
Foreign Referenced Citations (120)
Number Date Country
PI0416738 Jan 2007 BR
PI0416738-4 Dec 2018 BR
2237293 Jul 1997 CA
1221284 Jun 1999 CN
1723696 Jan 2006 CN
1873820 Dec 2006 CN
101124561 Feb 2008 CN
101861583 Oct 2010 CN
101861583 Jun 2014 CN
0637172 Feb 1995 EP
644692 Mar 1995 EP
0677961 Oct 1995 EP
757484 Feb 1997 EP
813167 Dec 1997 EP
1158799 Nov 2001 EP
1187483 Mar 2002 EP
1420580 May 2004 EP
1453319 Sep 2004 EP
1536646 Jun 2005 EP
1692859 Aug 2006 EP
1283640 Oct 2006 EP
1718074 Nov 2006 EP
2180664 Apr 2010 EP
2223232 Sep 2010 EP
2360923 Aug 2011 EP
2927816 Oct 2015 EP
2927816 Jan 2020 EP
3641317 Apr 2020 EP
3641317 Jun 2022 EP
2398210 Aug 2004 GB
1112988 Sep 2008 HK
1147813 Aug 2011 HK
1215889 Jan 2021 HK
07334938 Dec 1995 JP
08163488 Jun 1996 JP
08287613 Nov 1996 JP
H1175178 Mar 1999 JP
11328929 Nov 1999 JP
02001043668 Feb 2001 JP
2002170363 Jun 2002 JP
2002218384 Aug 2002 JP
2003023607 Jan 2003 JP
2003250113 Sep 2003 JP
2005027153 Jan 2005 JP
2005173241 Jun 2005 JP
2005284041 Oct 2005 JP
2007532044 Nov 2007 JP
4516082 May 2010 JP
2011505648 Feb 2011 JP
2012019548 Jan 2012 JP
2013013146 Jan 2013 JP
5513400 Jun 2014 JP
5589043 Aug 2014 JP
2014233086 Dec 2014 JP
100221423 Sep 1999 KR
2002013664 Feb 2002 KR
1020020064888 Aug 2002 KR
20040039852 May 2004 KR
20060030164 Apr 2006 KR
20060106250 Oct 2006 KR
20060116967 Nov 2006 KR
20060122893 Nov 2006 KR
20070020727 Jan 2007 KR
20110124325 Nov 2011 KR
101127407 Mar 2012 KR
20130006717 Jan 2013 KR
101380262 Apr 2014 KR
101380265 Apr 2014 KR
2328040 Jun 2008 RU
123104 Jul 2006 SG
161354 Dec 2012 SG
201508443 Aug 2015 TR
1995015660 Jun 1995 WO
199800973 Jan 1998 WO
199834405 Aug 1998 WO
1998046005 Oct 1998 WO
1998047290 Oct 1998 WO
1999037072 Jul 1999 WO
2000049762 Aug 2000 WO
2000049763 Aug 2000 WO
0104892 Jan 2001 WO
0126377 Apr 2001 WO
2001031497 May 2001 WO
2001050732 Jul 2001 WO
2002001880 Jan 2002 WO
200223315 Mar 2002 WO
2003028293 Apr 2002 WO
2002035832 May 2002 WO
2002054776 Jul 2002 WO
2002073437 Sep 2002 WO
2002087241 Oct 2002 WO
2003046750 Jun 2003 WO
2003047262 Jun 2003 WO
2003061173 Jul 2003 WO
03098475 Nov 2003 WO
200401378 Feb 2004 WO
2004054247 Jun 2004 WO
2004097811 Nov 2004 WO
2004100158 Nov 2004 WO
2004102571 Nov 2004 WO
2005008385 Jan 2005 WO
2005015935 Feb 2005 WO
2005057906 Jun 2005 WO
2005125214 Dec 2005 WO
2007026837 Mar 2007 WO
2009006302 Jan 2009 WO
2009065137 May 2009 WO
2009109976 Sep 2009 WO
2010060106 May 2010 WO
2010108053 Sep 2010 WO
2010111261 Sep 2010 WO
2010122447 Oct 2010 WO
2011087449 Jul 2011 WO
2011101371 Aug 2011 WO
2011103364 Aug 2011 WO
2012094171 Jul 2012 WO
2012094181 Jul 2012 WO
2012094189 Jul 2012 WO
20120094181 Jul 2012 WO
20120094189 Jul 2012 WO
Non-Patent Literature Citations (282)
Entry
International Standard, Information technology—Generic coding of moving pictures and associated audio information: Systems, ISO/IEC 13818-1:2000(E), Dec. 1, 2000 174 pgs. (presented in 2 parts).
“Order” Conduct of the Proceeding, Case No. IPR2020-00614, U.S. Pat. No. 7,295,673 B2 and Case No. IPR2020-00646, U.S. Pat. No. 8,472,792 B2, filed Jun. 30, 2020, 4 pgs.
Broadq—The Ultimate Home Entertainment Software, printed May 11, 2009 from ittp://web.srchive.org/web/20030401122010/www.broadq.com/qcasttuner/, 1 pg.
Decision Denying Institution of Inter Partes Review for U.S. Pat. No. 7,295,673, Case No. IPR2020-00614, Sep. 11, 2020, 22 pgs.
Decision Granting Institution of Inter Partes Review for U.S. Pat. No. 8,472,792, Case No. IPR2020-00646, Sep. 15, 2020, 57 pgs.
Decision Granting Petitioner's Request on Rehearing 37 C.F.R. § 42.71(d) Granting Institution of Inter Partes Review 35 U.S.C. § 314, IPR2020-00614 U.S. Pat. No. 7,295,673, 29 pgs.
Declaration of Dr. Clifford Reader, Inter Partes Review of U.S. Pat. No. 8,472,792, 205 pgs, IPR filed Mar. 6, 2020.
Declaration of Dr. Sylvia D. Hall-Ellis, Case No. IPR2020-00646, U.S. Pat. No. 8,472,792, 33 pgs, IPR filed Mar. 6, 2020.
Declaration of Patrick McDaniel, Ph.D., Inter Partes Review of U.S. Pat. No. 7,295,673, Case No. IPR2020-00614, IPR filed Feb. 28, 2020, 218 pgs.
Defendant Hulu, LLC's Invalidity Contentions for U.S. Patent No. 7,295,673; U.S. Pat. No. 8,139,651; U.S. Pat. No. 8,472,792; U.S. Pat. No. 9,270,720; U.S. Pat. No. 9,998,515; U.S. Pat. No. 10,212,486; U.S. Pat. No. 10,225,588, DIVX, LLC v. Hulu, LLC, Case No. 2:19-cv-1606-PSG-DFMx, C.D. Cal., Apr. 2, 2020, 136 pgs.
Defendant Netflix, Inc.'s Invalidity Contentions for U.S. Patent No. 7,295,673; U.S. Pat. No. 8,139,651; U.S. Pat. No. 8,472,792; U.S. Pat. No. 9,270,720; U.S. Pat. No. 9,998,515; U.S. Pat. No. 10,212,486; U.S. Pat. No. 10,225,588; U.S. Pat. No. 9,184,920, DIVX, LLC v. Netflix, Inc., Case No. 2:19-cv-1602-PSG-DFM, C.D. Cal., Apr. 2, 2020, 148 pgs.
European Search Report for Application 11855103.5, search completed Jun. 26, 2014, 9 pgs.
European Search Report for Application 11855237.1, search completed Jun. 12, 2014, 9 pgs.
European Supplementary Search Report for Application EP09759600, completed Jan. 25, 2011, 11 pgs.
Extended European Search Report for European Application EP15162562.1,Report Completed Jul. 21, 2015, dated Jul. 29, 2015, 4 Pgs.
Extended European Search Report for European Application No. 19214057.2, Search completed Mar. 10, 2020, dated Mar. 20, 2020, 8 Pgs.
Federal Computer Week, “Tool Speeds Info to Vehicles”, Jul. 25, 1999, 5 pages.
Final draft ETSI ES 202 109, V1.1.1, ETSI Standard, Terrestrial Trunked Radio (TETRA); Security; Synchronization mechanism for end-to-end encryption, Oct. 2002, 17 pgs.
First Amended Complaint for Patent Infringement, DivX, LLC v. Netflix, Inc., No. 2:19-cv-1602-PSG, Am. Compl. (C.D. Cal Aug. 21, 2019), 229 pgs, IPR filed Mar. 6, 2020.
HTTP Live Streaming Overview, Networking & Internet, Apple, Inc., Apr. 1, 2011, 38 pages.
Hulu Invalidity Chart for U.S. Pat. No. 7,295,673, Case No. IPR2020-00614, IPR filed Feb. 29, 2020, 17 pgs.
IBM Corporation and Microsoft Corporation, “Multimedia Programming Interface and Data Specifications 1.0”, Aug. 1991, printed from http://www.kk.iij4u.or.jp/˜kondo/wave/mpidata.txt on Mar. 6, 2006, 100 pgs.
Information Technology—MPEG Systems Technologies—Part 7: Common Encryption in ISO Base Media File Format Files (ISO/IEC 23001-7), Apr. 2015, 24 pgs.
InformationWeek, “Internet on Wheels”, InformationWeek: Front End: Daily Dose, Jul. 20, 1999, Printed on Mar. 26, 2014, 3 pgs.
International Preliminary Report on Patentability for International Application No. PCT/US2004/041667, Report dated Jul. 10, 2007, 7 pgs.
International Preliminary Report on Patentability for International Application No. PCT/US2006/000456, report dated Oct. 9, 2007.
International Preliminary Report on Patentability for International Application No. PCT/US2008/083816, dated May 18, 2010, 6 pgs.
International Search Report and Written Opinion for International Application No. PCT/US09/46588, completed Jul. 13, 2009, dated Jul. 23, 2009, 7 pgs.
International Search Report and Written Opinion for International Application No. PCT/US2004/041667, completed May 24, 2007, dated Jun. 20, 2007, 6 pgs.
International Search Report and Written Opinion for International Application No. PCT/US2008/083816, completed Jan. 10, 2009, dated Jan. 22, 2009, 7 pgs.
International Search Report and Written Opinion for International Application PCT/US2011/066927, completed Apr. 3, 2012, dated Apr. 20, 2012, 14 pgs.
International Search Report and Written Opinion for International Application PCT/US2011/067167, completed Jun. 19, 2012, dated Jul. 2, 2012, 11 pgs.
International Search Report for International Publication No. PCT./US2006/000456, completed May 19, 2007, dated Sep. 24, 2007.
International Telecommunication Union, Telecommunication Standardization Sector of ITU, H.233, Line Transmission of Non-Telephone Signals, Confidentiality System for Audiovisual Services, ITU-T Recommendation H.233, Mar. 1993, 18 pgs.
ISO/IEC 14496-12 Information technology—Coding of audio-visual objects—Part 12: ISO base media file format, Feb. 2004 (“MPEG-4 Part 12 Standard”), 62 pgs.
ISO/IEC 14496-12:2008(E) Informational Technology—Coding of Audio-Visual Objects Part 12: ISO Base Media File Format, Oct. 2008, 120 pgs.
ISO/IEC 14496-2:2001(E), Information technology—Coding of audio-visual objects, Part 2: Visual, Dec. 1, 2001, 536 pgs, Annex A.1, section 7.4.1., section, 7.4.3., section 7.6.3, section 7.7.1., Annex B.
ISO/IEC FCD 23001-6 MPEG systems technologies Part 6: Dynamic adaptive streaming over HTTP (DASH), Jan. 28, 2011, 86 pgs.
ITS International, “Fleet System Opts for Mobile Server”, Aug. 26, 1999, Printed on Oct. 21, 2011 from http://www.itsinternational.com/News/article.cfm?recordID=547, 2 pgs.
Linksys Wireless-B Media Adapter Reviews, printed May 4, 2007 from http://reviews.cnet.com/Linksys_Wireless_B_Media_Adapter/4505-6739_7-30421900.html?tag=box, 5 pgs.
Linksys, KISS DP-500, printed May 4, 2007 from http://www.kiss-technology.com/?p=dp500, 2 pgs.
LINKSYS® : “Enjoy your digital music and pictures on your home entertainment center, without stringing wires!”, Model No. WMA 11B, printed May 9, 2007 from http://www.linksys.com/servlet/Satellite?c=L_Product_C2&childpagename=US/Layout&cid=1115416830950&p.
Microsoft Corporation, “Chapter 8, Multimedia File Formats” 1991, Microsoft Windows Multimedia Programmer's Reference, 3 cover pgs., pp. 8-1 to 8-20.
Microsoft Corporation, Advanced Systems Format (ASF) Specification, Revision Jan. 20, 2003, Dec. 2004, 121 pgs.
Microsoft Media Platform: Player Framework, “Microsoft Media Platform: Player Framework v2.5 (formerly Silverlight Media Framework)”, May 3, 2011, 2 pages.
Microsoft Media Platform: Player Framework, “Silverlight Media Framework v1.1”, Jan. 2010, 2 pages.
Microsoft Windows® XP Media Center Edition 2005, Frequently asked Questions, printed May 4, 2007 from http://www.microsoft.com/windowsxp/mediacenter/evaluation/faq.mspx.
Microsoft Windows® XP Media Center Edition 2005: Features, printed May 9, 2007, from http://www.microsoft.com/windowsxp/mediacenter/evaluation/features.mspx, 4 pgs.
MPEG-DASH presentation at Streaming Media West 2011, Nov. 2011, 14 pgs.
Netflix Invalidity Chart for U.S. Pat. No. 7,295,673, Case No. IPR2020-00614, IPR filed Feb. 29, 2020, 17 pgs.
Open DML AVI-M-JPEG File Format Subcommittee, “Open DML AVI File Format Extensions”, Version 1.02, Feb. 28, 1996, 29 pgs.
Patent Assignment Conveying U.S. Pat. No. 7,212,726 to Hulu, LLC, 8 pgs. Recorded Jun. 17, 2016.
Patent Owner's Preliminary Response to Petition for Inter Partes Review of U.S. Pat. No. 7,295,673, Case No. IPR2020-00614, filed Jun. 17, 2020, 52 pgs.
Patent Owner's Preliminary Response to Petition for Inter Partes Review of U.S. Pat. No. 8,472,792, Case No. IPR2020-00646, filed Jun. 17, 2020, 40 pgs.
Patent Owner's Preliminary Surreply to Petition for Inter Partes Review, Case No. IPR2020-00614, U.S. Pat. No. 7,295,673, filed Feb. 29, 2020, 14 pgs.
Patent Owner's Preliminary Surreply to Petition for Inter Partes Review, Case No. IPR2020-00646, U.S. Pat. No. 8,472,792, filed Jul. 15, 2020, 14 pgs.
pc world.com, Future Gear: PC on the HiFi, and the TV, from http://www.pcworld.com/article/id,108818-page,1/article.html, printed May 4, 2007, from IDG Networks, 2 pgs.
Petition for Inter Partes Review of U.S. Pat. No. 7,295,673, IPR2020-00614, 89 pgs, IPR filed Feb. 29, 2020.
Petition for Inter Partes Review of U.S. Pat. No. 8,472,792, IPR2020-00646, 90 pgs, IPR filed Mar. 6, 2020.
Petitioners' Reply to Patent Owner's Preliminary Response, Case No. IPR2020-00614, U.S. Pat. No. 7,295,673, Jul. 8, 2020, 13 pgs.
Petitioners' Reply to Patent Owner's Preliminary Response, Case No. IPR2020-00646, U.S. Pat. No. 8,472,792, filed Jul. 8, 2020, 13 pgs.
Petitioner's Request for Rehearing, Case No. IPR2020-00614, U.S. Pat. No. 7,295,673, filed Oct. 12, 2020, 14 pgs.
Pomelo, LLC Tech Memo, Analysis of Netflix's Security Framework for ‘Watch Instantly’ Service, Mar.-Apr. 2009, 18 pgs.
Power of Attorney—Hulu, LLC (IPR2020-00646), 4 pgs., IPR filed Mar. 6, 2020.
Power of Attorney—Netflix, Inc. (IPR2020-00646), 4 pgs., IPR filed Mar. 6, 2020.
Prosecution File History for U.S. Pat. No. 8,472,792, 1450 pgs., IPR filed Mar. 6, 2020. (presented in 10 parts).
Qtv—About BroadQ, printed May 11, 2009 from http://www.broadq.com/en/about.php, 1 pg.
Search Report and Written Opinion for International Application No. SG 200603807-9, Report dated Oct. 22, 2007, 15 pgs.
Server-Side Stream Repackaging (Streaming Video Technologies Panorama, Part 2), Jul. 2011, 15 pgs.
Sony U.S. Appl. No. 60,409,675, filed Sep. 9, 2002, 144 pgs.
Supplementary European Search Report for Application No. EP 04813918, Search Completed Dec. 19, 2012, 3 pgs.
Text of ISO/IEC 23001-6: Dynamic adaptive streaming over HTTP (DASH), Oct. 2010, 71 pgs.
Transmission of Non-Telephone Signals, Video Coding for Low Bit Rate Communication, ITU-T Recommendation H.263, ITU-T Telecommunication Standardization Sector of ITU, Mar. 1996, 52 pgs.
Unified Patents Patroll Winning Subimission, Patroll—Prior Art Crowdsourcing, http://patroll.unifiedpatents.com, 5 pgs.
United States Patent and Trademark Office, In re Campana, Jr et al., Control Nos. U.S. Appl. No. 90/007,726, U.S. Appl. No. 90/007,726, U.S. Appl. No. 90/007,726, Decision Denying Petition, Feb. 22, 2007, 11 pgs.
Universal Mobile Telecommunications System (UMTS), ETSI TS 126 233 V9.1.0 (Jun. 2011) 3GPP TS 26.233 version 9.1.0 Release 9, 18 pgs.
Universal Mobile Telecommunications Systems (UMTS); ETSI TS 126 244 V9.4.0 (May 2011) 3GPP TS 26.244 version 9.4.0 Release 9, 58 pgs.
W3C, Eds. Klyne, G. et al., Resource Description Framework (RDF): Concepts and Abstract Syntax, Section 3.3, Oct. 10, 2003, available online at https://www.w3.org/TR/2003/WD-rdf-concepts-20031010/#section-Datatypes-intro.
Windows Media Center Extender for Xbox, printed May 9, 2007 from http://www.xbox.com/en-US/support/systemuse/xbox/console/mediacenterextender.htm, 2 pgs.
Windows® XP Media Center Edition 2005, “Experience more entertainment”, retrieved from http://download.microsoft.com/download/c/9/a/c9a7000a-66b3-455b-860b-1c16f2eecfec/MCE.pdf on May 9, 2007, 2 pgs.
Written Opinion for International Application No. PCT/US2006/000456, report completed May 19, 2007.
Extended European Search Report for European Application EP08849996.7, Report Completed Dec. 19, 2014, dated Jan. 23, 2015, 7 Pgs.
3GPP TS 26.247, V1.3.0, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects Transparent end-to-end Packet-switches Streaming Services (PSS);, Progressive Download and Dynamic Adaptive Streaming over HTTP (3GP-DASH) (Release 10), Mar. 2011, 72 pgs.
Written Opinion for International Application No. PCT/US2008/083816, Opinion completed Jan. 10, 2009, dated Jan. 22, 2009, 5 pgs.
Written Opinion for International Application No. PCT/US2009/046588, completed Jul. 14, 2009, dated Jul. 23, 2009, 5 pgs.
Innovation of technology arrived, I-O Data, Nov. 2004, Retrieved from http://www.iodata.com/catalogs/AVLP2DVDLA_Flyer200505.pdf on May 30, 2013, 2 pgs., I-O Data, 2 pgs.
“0penDML AVI File Format Extensions”, XP002179318,Retrieved from the Internet: URL:http://www.rahul.net/jfm/odmlff2.pdf [retrieved on Oct. 4, 2001], Sep. 1997.
“Adaptive Streaming Comparison”, Jan. 28, 2010, 5 pgs.
“Apple HTTP Live Streaming specification”, Aug. 2017, 60 pgs.
“AVI”, OpenNET, Mar. 5, 2003, available at https://web.archive.org/web/20030305042201/http://www.opennet.ru/docs/formats/avi.txt.
“AVI files and common problems”, virtualdub.org, Current version: v1.10.4 , Nov. 11, 2004, Retrieved from: http://www.virtualdub.org/blog/pivot/entry.php?id=25, 14 pgs.
“Best Practices for Multi-Device Transcoding”, Kaltura Open Source Video, Printed on Nov. 27, 2013 from knowledge.kaltura.com/best-practices-multi-device-transcoding, 13 pgs.
“Common Interface Specification for Conditional Access and other Digital Video Broadcasting Decoder Applications”, European Standard, EN 50221, Feb. 1997, 86 pgs.
“Container format (digital)”, printed Aug. 22, 2009 from http://en.wikipedia.org/wiki/Container_format_(digital), 4 pgs.
“Data Encryption Decryption using AES Algorithm, Key and Salt with Java Cryptography Extension”, Available at https://www.digizol.com/2009/10/java-encrypt-decrypt-jce-salt.html, Oct. 200, 6 pgs.
“DCMI Metadata Terms: A complete historical record”, Dublin Core Metadata Initiative, Dec. 18, 2006, showing Term name: title, version 004, Date modified Oct. 14, 2002, available at http://dublincore.org/usage/terms/history/#title-004.
“Delivering Live and On-Demand Smooth Streaming”, Microsoft Silverlight, 2009, 28 pgs.
“Draft CR: Trick Mode for HTTP Streaming”, 3GPP TSG-SA4 Meeting #58, Apr. 26-30, 2010, Vancouver, Canada, S4-100237, 3 pgs.
“DVD—MPeg differences”, printed Jul. 2, 2009 from http://dvd.sourceforge.net/dvdinfo/dvdmpeg.html, 1 pg.
“DVD subtitles”, sam.zoy.org/writings/dvd/subtitles, dated Jan. 9, 2001, printed Jul. 2, 2009, 4 pgs.
“Final Committee Draft of MPEG-4 streaming text format”, International Organisation for Standardisation, Feb. 2004, 22 pgs.
“HTTP Based Adaptive Streaming over HSPA”, Apr. 2011, 73 pgs.
“HTTP Live Streaming”, Mar. 2011, 24 pgs.
“HTTP Live Streaming”, Sep. 2011, 33 pgs.
“Information Technology—Coding of audio-visual objects—Part 17: Streaming text”, International Organisation for Standardisation, Feb. 2004, 22 pgs.
“Information technology—Coding of audio-visual objects—Part 18: Font compression and streaming”, ISO/IEC 14496-18, First edition Jul. 1, 2004, 26 pgs.
“Information Technology—Coding of Audio Visual Objects—Part 2: Visual”, International Standard, ISO/IEC 14496-2, Third Edition, Jun. 1, 2004, pp. 1-724. (presented in three parts).
“ISO/IEC 8859-1”, Wikipedia, Last updated Aug. 8, 2017, Retrieved from: https://en.wikipedia.org/wiki/ISO/IEC_8859-1, 8 pgs.
“Java Cryptography Architecture API Specification & Reference”, Available at https://docs.oracle.eom/javase/1.5.0/docs/guide/security/CryptoSpec.html, Jul. 25, 2004, 68 pgs.
“Java Cryptography Extension, javax.crypto.Cipher class”, Available at https://docs.oracle.com/javase/1,5.0/docs/api/javax/crypto/Cipher.html, 2004, 24 pgs.
“JCE Encryption—Data Encryption Standard (DES) Tutorial”, Available at https://mkyong.com/java/jce-encryption-data-encryption-standard-des-tutorial/, Feb. 25, 2009, 2 pgs.
KISS Players, “KISS DP-500”, retrieved from http://www.kiss-technology.com/?p=dp500 on May 4, 2007, 1 pg.
“Liaison Statement from ITU-T SG 9 to SC 29/WG 11 on Draft New Recommendation J.123 (j.mfweb) [SC 29 M 4877]”, 61. MPEG Meeting; Jul. 22, 2002-Jul. 26, 2002, Klagenfurt; (Motion Picture Expert Group or ISO/IEC JTC1/SC29/WG11), No. M8488. Jul. 25, 2002 (Jul. 25, 2002). XP030037444.
“Live and On-Demand Video with Silverlight and IIS Smooth Streaming”, Microsoft Silverlight, Windows Server Internet Information Services 7.0, Feb. 2010, 15 pgs.
“Microsoft and Leading Professional Media Companies Release Advanced Authoring Format Specification”, Retrieved from https://news.microsoft.com/1998/04/03/microsoft-and-leading-professional-media-companiesrelease-advanced-authoring-format-specification/, Apr. 3, 1998, 10 pgs.
“Microsoft Smooth Streaming specification”, Jul. 22, 2013, 56 pgs.
“Multimedia Programming Interface and Data Specifications 1.0”, IBM Corporation and Microsoft Corporation, Ch. 2 (RIFF), Aug. 1991.
“Netflix turns on subtitles for PC, Mac streaming”, Yahoo! News, Apr. 21, 2010, Printed on Mar. 26, 2014, 3 pgs.
“OpenDML AVI File Format Extensions Version 1.02”, OpenDMLAVI MJPEG File Format Subcommittee. Last revision: Feb. 28, 1996. Reformatting: Sep. 1997, 42 pgs.
“QCast Tuner for PS2”, printed May 11, 2009 from http://web.archive.org/web/20030210120605/www.divx.com/software/detail.php?ie=39, 2 pgs.
“QuickTime File Format”, Apple Computer, Inc., Mar. 1, 2001, 274 pgs. (presented in 3 parts).
“Single-Encode Streaming for Multiple Screen Delivery”, Telestream Wowza Media Systems, 2009, 6 pgs.
“Smooth Streaming Client”, The Official Microsoft IIS Site, Sep. 24, 2010, 4 pages.
“Supported Media Formats”, Supported Media Formats, Android Developers, Printed on Nov. 27, 2013 from developer.android.com/guide/appendix/media-formats.html, 3 pgs.
“Text of ISO/IEC 14496-18/COR1, Font compression and streaming”, ITU Study Group 16—Video Coding Experts Group—ISO/IEC MPEG & ITU-T VCEG(ISO/IEC JTC1/SC29/WG11 and ITU-T SG16 06), No. N8664, Oct. 27, 2006, 8 pgs.
“Text of ISO/IEC 14496-18/FDIS, Coding of Moving Pictures and Audio”, ITU Study Group 16—Videocoding Experts Group—ISO/IEC MPEG & ITU-T VCEG(ISO/IEC JTC1/SC29/WG11 and ITU-T SG16 06), No. N6215, Dec. 2003, 26 pgs.
“The MPEG-DASH Standard for Multimedia Streaming Over the Internet”, IEEE MultiMedia, vol. 18, No. 4, 2011, 7 pgs.
“Thread: SSME (Smooth Streaming Medial Element) config.xml review (Smooth Streaming Client configuration file)”, Printed on Mar. 26, 2014, 3 pgs.
“Transcoding Best Practices”, From movideo, Printed on Nov. 27, 2013 from code.movideo.com/Transcoding_Best_Practices, 5 pgs.
“Using HTTP Live Streaming”, iOS Developer Library, http://developer.apple.com/library/ios/#documentation/networkinginternet/conceptual/streamingmediaguide/UsingHTTPLiveStreaming/UsingHTTPLiveStreaming.html#//apple_ref/doc/uid/TP40008332-CH102-SW1, Feb. 11, 2014, 10 pgs.
“Video Manager and Video Title Set IFO file headers”, printed Aug. 22, 2009 from http://dvd.sourceforge.net/dvdinfo/ifo.htm, 6 pgs.
“What is a DVD?”, printed Aug. 22, 2009 from http://www.videohelp.com/dvd, 8 pgs.
“What is a VOB file”, http://www.mpucoder.com/DVD/vobov.html, printed on Jul. 2, 2009, 2 pgs.
“What's on a DVD?”, printed Aug. 22, 2009 from http://www.doom9.org/dvd-structure.htm, 5 pgs.
“Windows Media Player 9”, Microsoft, Mar. 23, 2017, 3 pgs.
“DVD-Mpeg differences”, printed on Jul. 2, 2009, http://dvd.sourceforge.net/dvdinfo/dvdmpeg.html, 1 pg.
U.S. Appl. No. 13/224,298, “Final Office Action Received”, dated May 19, 2014, 26 pgs.
Abomhara et al., “Enhancing Selective Encryption for H.264/AVC Using Advanced Encryption Standard”, International Journal of computer Theory and Engineering, Apr. 2010, vol. 2, No. 2, pp. 223-229.
Adhikari et al., “Unreeling Netflix: Understanding and Improving Multi-CDN Movie Delivery”, 2012 Proceedings IEEE InfoCom, Mar. 25-30, 2012, Orlando, Florida, 9 pgs.
Agi et al., “An Empirical Study of Secure MPEG Video Transmissions”, IEEE, Mar. 1996, 8 pgs., DOI: 10.1109/NDSS.1996.492420.
Akhshabi et al., “An Experimental Evaluation of Rate-Adaptation Algorithms in Adaptive Streaming over HTTP”, MMSys'11, Feb. 23-25, 2011, 12 pgs.
Alattar et al., A.M., “Improved selective encryption techniques for secure transmission of MPEG video bit-streams”, In Proceedings 1999 International Conference on Image Processing (Cat. 99CH36348), vol. 4, IEEE, 1999, pp. 256-260.
Alvestrand, “Tags for the Identification of Languages”, Jan. 2001, Retrieved from: http://www.ietf.org/rfc/rfc3066.txt, 12 pgs.
Anonymous, “Method for the encoding of a compressed video sequence derived from the same video sequence compressed at a different bit rate without loss of data”, ip.com, ip.com No. IPCOM000008165D, May 22, 2002, pp. 1-9.
Antoniou et al., “Adaptive Methods for the Transmission of Video Streams in Wireless Networks”, 2015, 50 pgs.
Apostolopoulos et al., “Secure Media Streaming and Secure Transcoding”, Multimedia Security Technologies for Digital Rights Management, 2006, 33 pgs.
Asai et al., “Essential Factors for Full-Interactive VOD Server: Video File System, Disk Scheduling, Network”, Proceedings of Globecom '95, Nov. 14-16, 1995, 6 pgs.
Beker et al., “Cipher Systems, The Protection of Communications”, 1982, 40 pgs.
Blasiak, “Video Transrating and Transcoding: Overview of Video Transrating and Transcoding Technologies”, Ingenient Technologies, Tl Developer Conference, Aug. 6-8, 2002, 22 pgs.
Bloom et al., “Copy Protection for DVD Video”, Proceedings of the IEEE, vol. 87, No. 7, Jul. 1999, pp. 1267-1276.
Bocharov et al., “Portable Encoding of Audio-Video Objects, The Protected Interoperable File Format (PIFF)”, Microsoft Corporation, First Edition Sep. 8, 2009, 30 pgs.
Bochicchio et al., “X-Presenter: a tool for video-based hypermedia applications”, AVI '04 Proceedings of the Working Conference on Advanced Visual Interfaces, May 28, 2004, pp. 437-440, XP002733976, Association for Computing Machinery USA, DOI: 10.1145/989863.989945, ISBN.
Bulterman et al., “Synchronized Multimedia Integration Language (SMIL 3.0)”, W3C Recommendation, Dec. 1, 2008, https://www.w3.org/TR/2008/REC-SMIL3-20081201/, 321 pgs. (presented in five parts).
Cahill et al., “Locally Adaptive Deblocking Filter for Low Bit Rate Video”, Proceedings 2000 International Conference on Image Processing, Sep. 10-13, 2000, Vancouver, BC, Canada, 4 pgs.
Candelore, U.S. Appl. No. 60/372,901, filed Apr. 17, 2002, 5 pgs.
Casares et al., “Simplifying Video Editing Using Metadata”, DIS2002, 2002, pp. 157-166.
Chaddha et al., “A Frame-work for Live Multicast of Video Streams over the Internet”, Proceedings of 3rd IEEE International Conference on Image Processing, Sep. 19, 1996, Lausanne, Switzerland, 4 pgs.
Cheng, “Partial Encryption for Image and Video Communication”, Thesis, Fall 1998, 95 pgs.
Cheng et al., “Partial encryption of compressed images and videos”, IEEE Transactions on Signal Processing, vol. 48, No. 8, Aug. 2000, 33 pgs.
Cheung et al., “On the Use of Destination Set Grouping to Improve Fairness in Multicast Video Distribution”, Proceedings of IEEE INFOCOM'96, Conference on Computer Communications, vol. 2, IEEE, 1996, 23 pgs.
Collet, “Delivering Protected Content, An Approach for Next Generation Mobile Technologies”, Thesis, 2010, 84 pgs.
Concolato et al., “Live HTTP Streaming of Video and Subtitles within a Browser”, MMSys 2013, Feb. 26-Mar. 1, 2013, Oslo, Norway, 5 pgs.
Conklin et al., “Video coding for streaming media delivery on the Internet”, IEEE Transactions on Circuits and Systems for Video Technology, Mar. 2001, vol. 11, No. 3, pp. 269-281.
Deshpande et al., “Scalable Streaming of JPEG2000 Images Using Hypertext Transfer Protocol”, Multimedia '01: Proceedings of the Ninth ACM International Conference on Multimedia, Oct. 2001, pp. 372-381. https://doi.org/10.1145/500141.500197.
Deutscher, “IIS Transform Manager Beta—Using the MP4 to Smooth Task”, Retrieved from https://web.archive.org/web/20130328111303/http://blog.johndeutscher.com/category/smooth-streaming, Blog post of Apr. 29, 2011, 14 pgs.
Diamantis et al., “Real Time Video Distribution using Publication through a Database”, Proceedings SIBGRAPI'98. International Symposium on Computer Graphics, Image Processing, and Vision (Cat. No. 98EX237), Oct. 1990, 8 pgs.
Dworkin, “Recommendation for Block Cipher Modes of Operation: Methods and Techniques”, NIST Special Publication 800-38A, 2001, 66 pgs.
Eskicioglu et al., “An Integrated Approach to Encrypting Scalable Video”, Proceedings IEEE International Conference on Multimedia and Expo, Aug. 26-29, 2002, Lausanne, Switzerland, 4 pgs.
ETSI, “Digital Video Broadcasting (DVB) Support for use of scrambling and Conditional Access (CA) within digital broadcasting systems”, Oct. 1996, 13 pgs.
ETSI, “Digital Video Broadcasting (DVB); Implementation guidelines for the use of Video and Audio Coding in Contribution and Primary Distribution Applications based on the MPEG-2 Transport Stream”, ETSI TS 102 154 V1.2.1, May 2004, 73 pgs.
Fahmi et al., “Proxy Servers for Scalable Interactive Video Support”, Computer, Sep. 2001, vol. 45, No. 9, pp. 54-60, https://doi.org/10.1109/2.947092.
Fan et al., “Class View: Hierarchical Video Shot Classification, Indexing, and Accessing”, IEEE Transactions on Multimedia, IEEE Service Center, Piscataway, NJ, US, vol. 6, No. 1, Feb. 1, 2004, pp. 70-86, XP011105807, ISSN: 1520-9210, DOI: 10.1I09/TMM.2003.8195.
Fang et al., “Real-time deblocking filter for MPEG-4 systems”, Asia-Pacific Conference on Circuits and Systems, Oct. 28-31, 2002, Bail, Indonesia, pp. 541-544.
Fecheyr-Lippens, “A Review of HTTP Live Streaming”, Jan. 2010, 38 pgs.
Fielding et al., “Hypertext Transfer Protocol—HTTP1.1”, Network Working Group, RFC 2616, Jun. 1999, 114 pgs.
Fitzek et al., “A Prefetching Protocol for Continuous Media Streaming in Wireless Environments”, IEEE Journal on Selected Areas in Communications, Oct. 2001, vol. 19, No. 10, pp. 2015-2028, DOI:10.1109/49.957315.
Fukuda et al., “Reduction of Blocking Artifacts by Adaptive DCT Coefficient Estimation in Block-Based Video Coding”, Proceedings 2000 International Conference on Image Processing, Sep. 10-13, 2000, Vancouver, BC, Canada, pp. 969-972.
Gannes, “The Lowdown on Apple's HTTP Adaptive Bitrate Streaming”, GigaOM, Jun. 10, 2009, 12 pgs.
Ghosh, “Enhancing Silverlight Video Experiences with Contextual Data”, Retrieved from: http://msdn.microsoft.com/en-us/magazine/ee336025.aspx, 2010, 15 pgs.
Griffith, Eric, “The Wireless Digital Picture Frame Arrives”, Wi-Fi Planet, printed May 4, 2007 from http://www.wi-fiplanet.com/news/article.php/3093141, Oct. 16, 2003, 3 pgs.
Hartung et al., “DRM Protected Dynamic Adaptive HTTP Streaming”, MMSys 2011 Proceedings of the Second Annual ACM Conference on Multimedia Systems, San Jose, California, Feb. 23-25, 2011, pp. 277-282.
Ho, “Digital Video Broadcasting Conditional Access Architecture”, Report prepared for CS265-Section 2, Fall 2002, Prof Stamp, 7 pgs.
Huang, U.S. Pat. No. 7,729,426, U.S. Appl. No. 11/230,794, filed Sep. 20, 2005, 143 pgs.
Huang et al., “Adaptive MLP post-processing for block-based coded images”, IEEE Proceedings—Vision, Image and Signal Processing, vol. 147, No. 5, Oct. 2000, pp. 463-473.
Huang et al., “Architecture Design for Deblocking Filter in H.264/JVT/AVC”, 2003 International Conference on Multimedia and Expo., Jul. 6-9, 2003, Baltimore, MD, 4 pgs.
Hurtado Guzman, “Development and Implementation of an Adaptive HTTP Streaming Framework for H264/MVC Coded Media”, Politecnico di Torino, Nov. 2010, 108 pgs.
Hwang et al., “Efficient and User Friendly Inter-domain Device Authentication/Access control for Home Networks”, Proceedings of the 2006 International Conference on Embedded and Ubiquitous Computing, Seoul, Korea, Aug. 1-4, 2006, pp. 131-140.
INCITS/ISO/IEC, “Information Technology—Generic Coding Of Moving Pictures And Associated Audio Information: Video (Formerly ANSI/ISO/IEC 13818—Feb. 2000)”, Second edition, Dec. 15, 2000, 220 pgs., (presented in two parts).
Inlet Technologies, “Adaptive Delivery to iDevices”, 2010, 2 pages.
Inlet Technologies, “Adaptive delivery to iPhone 3.0”, 2009, 2 pgs.
Inlet Technologies, “HTTP versus RTMP”, 2009, 3 pages.
Inlet Technologies, “The World's First Live Smooth Streaming Event: The French Open”, 2009, 2 pages.
I-O Data, “Innovation of technology arrived”, Nov. 2004, Retrieved from http://www.iodata.com/catalogs/AVLP2DVDLA_Flyer200505.pdf, 2 pgs.
ITU-T, “Series J: Cable Networks and Transmission of Television, Sound Programme and Other Multimedia Signals”, Technical method for ensuring privacy in long-distance international MPEG-2 television transmission conforming to ITU-T J.89, ITU-T Recommendation J.96, Mar. 2001, 34 pgs.
Jain et al., U.S. Appl. No. 61/522,623, filed Aug. 11, 2011, 44 pgs.
Jung et al., “Design and Implementation of an Enhanced Personal Video Recorder for DTV”, IEEE Transactions on Consumer Electronics, vol. 47, No. 4, Nov. 2001, 6 pgs.
Kabir, “Scalable and Interactive Multimedia Streaming Over the Internet”, Thesis, 2005, 207 pgs.
Kalva, Hari, “Delivering MPEG-4 Based Audio-Visual Services”, 2001, 113 pgs.
Kang et al., “Access Emulation and Buffering Techniques for Steaming of Non-Stream Format Video Files”, IEEE Transactions on Consumer Electronics, vol. 43, No. 3, Aug. 2001, 7 pgs.
Kim et al, “A Deblocking Filter with Two Separate Modes in Block-Based Video Coding”, IEEE transactions on circuits and systems for video technology, vol. 9, No. 1, 1999, pp. 156-160.
Kim et al., “Tree-Based Group Key Agreement”, Feb. 2004, 37 pgs.
Kurzke et al., “Get Your Content Onto Google TV”, Google, Retrieved from: http://commondatastorage.googleapis.com/io2012/presentations/live%20to%20website/1300.pdf, 2012, 58 pgs.
Lang, “Expression Encoder, Best Practices for live smooth streaming broadcasting”, Microsoft Corporation, 2010, retrieved from http://www.streamingmedia.com/conferences/west2010/presentations/SMWest-12010-Expression-Encoder.pdf, 20 pgs.
Laukens, “Adaptive Streaming—A Brief Tutorial”, EBU Technical Review, 2011, 6 pgs.
Lee et al., “Uniform Resource Identifiers (URI): Generic Syntax”, Aug. 1998, Retrieved from: http://ietf.org/rfc/rfc2396.txt, 35 pgs.
Legault et al., “Professional Video Under 32-bit Windows Operating Systems”, SMPTE Journal, vol. 105, No. 12, Dec. 1996, 10 pgs.
Levkov, “Mobile Encoding Guidelines for Android Powered Devices”, Adobe Systems Inc., Addendum B, Dec. 22, 2010, 42 pgs.
Li et al., “Layered Video Multicast with Retransmission (LVMR): Evaluation of Hierarchical Rate Control”, Proceedings of IEEE INFOCOM'98, the Conference on Computer Communications. Seventeenth Annual Joint Conference of the IEEE Computer and Communications Societies. Gateway to the 21st Century, Cat. No. 98, vol. 3, 1998, 26 pgs.
Lian et al., “Efficient video encryption scheme based on advanced video coding”, Multimed. Tools Appl. vol. 38, 2008, pp. 75-89.
Lian et al., “Selective Video Encryption Based on Advanced Video Coding”, PCM, Nov. 2005, Part II, LNCS 3768, pp. 281-290.
Lievaart, “Characteristics that differentiate CA Systems”, Irdeto access, Nov. 2001, 5 pgs.
List et al., “Adaptive deblocking filter”, IEEE transactions on circuits and systems for video technology, vol. 13, No. 7, Jul. 2003, pp. 614-619.
Liu et al., “A Formal Framework for Component Deployment”, OOPSLA 2006, Proceedings of the 21st Annual ACM SIGPLAN Conference on Object-Oriented Programming Systems, Language, and Applications, Portland, Oregon, Oct. 22-26, 2006, pp. 325-344.
Lloyd, “Supporting Trick Mode Playback Universally Across the Digital Television Industry”, Thesis, 2005, 111 pgs.
Long et al., “Silver: Simplifying Video Editing with Metadata”, Demonstrations, CHI 2003: New Horizons, Apr. 5-10, 2003, pp. 628-629.
Macaulay et al., “Whitepaper—IP Streaming of MPEG-4: Native RTP vs MPEG-2 Transport Stream”, Envivio, Oct. 2005, 12 pgs.
Mark D. Pesce, “Programming Microsoft DirectShow for Digital Video and Television”, Washington: Microsoft Press, 2003, 17 pgs.
Massoudi et al., “Overview on Selective Encryption of Image and Video: Challenges and Perspectives”, EURASIP Journal on Information Security, Nov. 2008, 18 pgs.
Mccanne et al., “Receiver-driven Layered Multicast”, Conference proceedings on Applications, technologies, architectures, and protocols for computer communications, Aug. 1996, 14 pgs.
Meier, “Reduction of Blocking Artifacts in Image and Video Coding”, IEEE Transactions on Circuits and Systems for Video Technology, vol. 9, No. 3, Apr. 1999, pp. 490-500.
Meyer et al., “Security mechanisms for Multimedia-Data with the Example MPEG-I-Video”, SECMPEG, 1992, 10 pgs.
Molavi et al., “A Security Study of Digital TV Distribution Systems”, Thesis, Jun. 2005, 112 pgs.
Morrison, “EA IFF 85 Standard for Interchange Format Files”, Jan. 14, 1985, printed from http://www.dcs.ed.ac.uk/home/mxr/gfx/2d/IFF.txt on Mar. 6, 2006, 24 pgs.
Moscoso, Pedro Gomes, “Interactive Internet TV Architecture Based on Scalable Video Coding”, Instituto Superior Techico, Universidad Technica de Lisboa, May 2011, 103 pgs.
MSDN, “Adaptive streaming, Expression Studio 2.0”, Apr. 23, 2009, 2 pgs.
Nelson, “Arithmetic Coding + Statistical Modeling = Data Compression: Part 1—Arithmetic Coding”, Doctor Dobb's Journal, Feb. 1991, USA, pp. 1-12.
Nelson, “Smooth Streaming Deployment Guide”, Microsoft Expression Encoder, Aug. 2010, 66 pgs.
Nelson, “The Data Compression Book”, M&T Publishing, 1992, 533 pgs., (presented in two parts).
Newton et al., “Preserving Privacy by De-identifying Facial Images”, Carnegie Mellon University School of Computer Science, Technical Report, CMU-CS-03-119, Mar. 2003, 26 pgs.
Noboru, “Play Fast and Fine Video on Web! codec”, Co.9 No. 12, Dec. 1, 2003, pp. 178-179.
Noe, A., “Matroska File Format (under construction!)”, Retrieved from the Internet: URL:http://web.archive.orgweb/20070821155146/www.matroska.org/technical/specs/matroska.pdf [retrieved on Jan. 19, 2011], Jun. 24, 2007, 1-51.
Noe, Alexander, “AVI File Format”, http://www.alexander-noe.com/video/documentation/avi.pdf, Dec. 14, 2006, pp. 1-26.
Noe, Alexander, “Definitions”, Apr. 11, 2006, retrieved from http://www.alexander-noe.com/video/amg/definitions.html on Oct. 16, 2013, 2 pages.
O'Brien, U.S. Appl. No. 60/399,846, filed Jul. 30, 2002, 27 pgs.
O'Rourke, “Improved Image Decompression for Reduced Transform Coding Artifacts”, IEEE Transactions on Circuits and Systems for Video Technology, vol. 5, No. 6, Dec. 1995, pp. 490-499.
Ozer, “The 2012 Encoding and Transcoding Buyers' Guide”, Streamingmedia.com, Retrieved from http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/The-2012-Encoding-and-Transcoding-Buyers-Guide-84210.aspx, 2012, 8 pgs.
Ozer, Jan, “Adaptive Streaming in the Field”, Streaming Media, Dec. 2010-Jan. 2011, pp. 36-47.
Padiadpu, Rashmi, “Towards Mobile Learning: A SCORM Player for the Google Android Platform”, Master Thesis, Hamburg University of Applied Sciences, 2008, 66 pgs.
Pantos, “HTTP Live Streaming, draft-pantos-http-live-streaming-10”, IETF Tools, Oct. 15, 2012, Retrieved from: http://tools.ietf.org/html/draft-pantos-http-live-streaming-10, 37 pgs.
Park et al., “A postprocessing method for reducing quantization effects in low bit-rate moving picture coding”, IEEE Transactions on Circuits and Systems for Video Technology, vol. 9, No. 1, Feb. 1999, pp. 161-171.
Pearce, Chris, “Indexing keyframes in Ogg videos for fast seeking”, Retrieved from: http://blog.pearce.org.nz/2010/01/indexing-keyframes-in-ogg-videos-for.html, Jan. 11, 2010, 4 pgs.
Peek, David, “Consumer Distributed File Systems”, Dissertation, Doctor of Philosophy, Computer Science and Engineering, The University of Michigan, 2009, 118 pgs.
Phamdo, “Theory of Data Compression”, printed on Oct. 10, 2003, 12 pgs.
Qiao et al., “Comparison of MPEG Encryption Algorithms”, Comput. & Graphics, 1998, vol. 22, No. 4, pp. 437-448.
RGB Networks, “Comparing Adaptive HTTP Streaming Technologies”, Nov. 2011, Retrieved from: http://btreport.net/wp-content/uploads/2012/02/RGB-Adaptive-HTTP-Streaming-Comparison-1211-01.pdf, 20 pgs.
Richardson, “H.264 and MPEG-4 Video Compression”, Wiley, 2003, 306 pgs. (presented in 2 parts).
Rosenberg et al., “Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)”, Network Working Group, RFC 3840, Aug. 2004, 36 pgs.
Senoh et al., “DRM Renewability & Interoperability”, IEEE Xplore, Conference: Consumer Communications and Networking Conference, 2004, Feb. 2004, pp. 424-429, DOI: 10.1109/CCNC.2004.1286899.
Shojania et al., “Experiences with MPEG-4 Multimedia Streaming”, CiteSeer, Jan. 2001, 3 pgs., DOI: 10.1145/500141.500221.
Siglin, “HTTP Streaming: What You Need to Know”, streamingmedia.com, 2010, 15 pages.
Siglin, “Unifying Global Video Strategies, MP4 File Fragmentation for Broadcast, Mobile and Web Delivery”, Nov. 16, 2011, 16 pgs.
Sima et al., “An Efficient Architecture for Adaptive Deblocking Filter of H.264 AVC Video Coding”, IEEE Transactions on Consumer Electronics, vol. 50, No. 1, Feb. 2004, pp. 292-296.
Spanos et al., “Performance Study of a Selective Encryption Scheme for the Security of Networked, Real-Time Video”, Proceedings of the Fourth International Conference on Computer Communications and Networks, IC3N'95, Sep. 20-23, 1995, Las Vegas, NV, pp. 2-10.
Srinivasan et al., “Windows Media Video 9: overview and applications”, Signal Processing: Image Communication, 2004, 25 pgs.
Stockhammer, “Dynamic Adaptive Streaming over HTTO—Standards and Design Principles”, Proceedings of the second annual ACM conference on Multimedia, Feb. 2011, pp. 133-145.
Symes, “Video Compression Demystified”, McGraw-Hill, 2001, 353 pgs., (presented in two parts).
Taxan, “AVel LinkPlayer2 for Consumer”, I-O Data USA—Products—Home Entertainment, printed May 4, 2007 from http://www.iodata.com/usa/products/products.php?cat=HNP&sc=AVEL&pld=AVLP2/DVDLA&ts=2&tsc, 1 pg.
Timmerer et al., “HTTP Streaming of MPEG Media”, Proceedings of Streaming Day, 2010, 4 pgs.
Tiphaigne et al., “A Video Package for Torch”, Jun. 2004, 46 pgs.
Tosun et al., “Efficient multi-layer coding and encryption of MPEG video streams”, 2000 IEEE International Conference on Multimedia and Expo. ICME2000. Proceedings. Latest Advances in the Fast Changing World of Multimedia (Cat. NO. 00TH8532), Jul. 30-Aug. 2, 2000, pp. 119-122, DOI: 10.1109/ICME.2000.869559.
Trappe et al., “Key Management and Distribution for Secure Multimedia Multicast”, IEEE Transaction on Multimedia, vol. 5, No. 4, Dec. 2003, pp. 544-557.
Trott et al., “File format provides a useful tool to multimedia authors”, Infoworld, Apr. 13, 1998, 1 pg.
Unknown, “AVI RIFF File Reference (Direct X 8.1 C++ Archive)”, printed from http://msdn.microsoft.com/archive/en-us/dx81_c/directx_cpp/htm/avirifffilereference.asp?fr . . . on Mar. 6, 2006, 7 pgs.
Unknown, “Entropy and Source Coding (Compression)”, TCOM 570, 1999-9, pp. 1-22.
Unknown, “MPEG-4 Video Encoder: Based on International Standard ISO/IEC 14496-2”, Patni Computer Systems, Ltd., publication date unknown, 15 pgs.
Van Deursen et al., “On Media Delivery Protocols in the Web”, 2010 IEEE International Conference on Multimedia and Expo, Jul. 19-23, 2010, 6 pgs.
Venkatramani et al., “Securing Media for Adaptive Streaming”, Multimedia 2003 Proceedings of the Eleventh ACM International Conference on Multimedia, Nov. 2-8, 2003, Berkeley, California, 4 pgs.
Ventura, Guillermo Albaida, “Streaming of Multimedia Learning Objects”, AG Integrated Communication System, Mar. 2003, 101 pgs.
Waggoner, “Compression for Great Digital Video”, 2002, 184 pgs.
Wan et al, “Variance-Based Color Image Quantization for Frame Buffer Display”, Color Research & Application 15, No. 1 (1990), pp. 52-58.
Wang, “Lightweight Encryption in Multimedia”, Thesis, Jun. 2005, 184 pgs.
Watanabem et al., “MPEG-2 decoder enables DTV trick plays”, esearcher System LSI Development Lab, Fujitsu Laboratories Ltd., Kawasaki, Japan, Jun. 2001, 2 pgs.
Wiegand, “Joint Video Team (JVT) of ISO/IEC MPEG and ITU-T VCEG”, Jan. 2002, 70 pgs.
Willig et al., U.S. Appl. No. 61/409,285, filed Nov. 2, 2010, 43 pgs.
Wong, “Web Client Programming with Perl”, 1997, printed Jan. 8, 2021 from: https://www.oreilly.com/openbook-webclientch03.html, 31 pgs.
Wu, “A Fast MPEG Encryption Algorithm and Implementation of AES on CAM”, Thesis, Oct. 6, 2003, 91 pgs.
Yang et al., “Projection-Based Spatially Adaptive Reconstruction of Block-Transform Compressed Images”, IEEE Transactions on Image Processing, vol. 4, No. 7, Jul. 1995, pp. 896-908.
Yang et al., “Regularized Reconstruction to Reduce Blocking Artifacts of Block Discrete Cosine Transform Compressed Images”, IEEE Transactions on Circuits and Systems for Video Technology, vol. 3, No. 6, Dec. 1993, pp. 421-432.
Yu et al., “Video deblocking with fine-grained scalable complexity for embedded mobile computing”, Proceedings 7th International Conference on Signal Processing, Aug. 31-Sep. 4, 2004, pp. 1173-1178.
Yuksel, “Partial Encryption of Video for Communication and Storage”, Thesis, Sep. 2003, 78 pgs.
Zakhor, “Iterative Procedures for Reduction of Blocking Effects in Transform Image Coding”, IEEE Transactions on Circuits and Systems for Video Technology, vol. 2, No. 1, Mar. 1992, pp. 91-95.
Zambelli, “IIS Smooth Streaming Technical Overview”, Microsoft Corporation, Mar. 2009.
Related Publications (1)
Number Date Country
20230123545 A1 Apr 2023 US
Continuations (6)
Number Date Country
Parent 17453314 Nov 2021 US
Child 17805420 US
Parent 17307990 May 2021 US
Child 17453314 US
Parent 16039752 Jul 2018 US
Child 17307990 US
Parent 15217894 Jul 2016 US
Child 16039752 US
Parent 13913187 Jun 2013 US
Child 15217894 US
Parent 11258496 Oct 2005 US
Child 13913187 US
Continuation in Parts (2)
Number Date Country
Parent 11016184 Dec 2004 US
Child 11258496 US
Parent 10731809 Dec 2003 US
Child 11016184 US