JP2014233086A - マルチメディア配信システム - Google Patents

Abstract

【課題】マルチメディア・ファイル、ならびに、そのマルチメディア・ファイルを生成、配信および使用する方法が記述される。【解決手段】本発明の実施例によるマルチメディア・ファイルは、複数のビデオ・トラックと、複数のオーディオ・トラックと、複数のサブタイトルトラックと、そのファイルの内容にアクセスするメニュー・インタフェースを生成すべく使用され得るデータと、そのファイルの内容に関する「メタデータ」とを含み得る。本発明の幾つかの実施例によるマルチメディア・ファイルは、そのファイルの外部であるビデオ・トラック、オーディオ・トラック、サブタイトルトラックおよび「メタデータ」に対するリファレンスも含む。本発明によるマルチメディア・ファイルの一実施例は、複数の符号化ビデオ・トラックを含む。【選択図】図２．０．

Description

本発明は一般に、マルチメディア・ファイルの符号化、送信および復号化に関する。より詳細には、本発明は、単一のオーディオ・トラックおよび単一のビデオ・トラックに加えて複数のトラックを含み得るマルチメディア・ファイルの符号化、送信および復号化に関する。

インターネットの発展は、標準化されたファイルの生成、配信および表示を可能とするマルチメディア情報用ファイル・フォーマットの発展を促進した。典型的には、単一のマルチメディア・ファイルは単一のビデオ・トラックおよび単一のオーディオ・トラックを含む。マルチメディアがデジタル・ビデオ・ディスク（ＤＶＤ）などの高容量で物理的に搬送可能なメディアに書き込まれたときには、多数のビデオ・トラック、オーディオ・トラックおよびサブタイトルトラックを提供するために複数のファイルが使用され得る。インタラクティブなメニューを生成すべく使用され得る情報を含む付加的ファイルが提供され得る。

本発明の実施例は、マルチメディア・ファイル、および、マルチメディア・ファイルを生成、配信および復号化するシステムを含む。本発明の一つの形態において、マルチメディア・ファイルは、複数の符号化ビデオ・トラックを含む。本発明の別の形態おいて、マルチメディア・ファイルは複数の符号化オーディオ・トラックを含む。本発明の別の形態において、マルチメディア・ファイルは少なくとも一つのサブタイトルトラックを含む。本発明の別の形態において、マルチメディア・ファイルは符号化「メタデータ（meta data）」を含む。本発明の別の形態において、マルチメディア・ファイルは符号化されたメニュー情報を含む。

本発明の実施例によるマルチメディア・ファイルは、複数の符号化ビデオ・トラックを含む。本発明の更なる実施例において、マルチメディア・ファイルは連結された複数の「リフ（RIFF）」チャンクを備え、かつ、各符号化ビデオ・トラックは別個の「RIFF」チャンク内に含まれる。これに加え、ビデオは心理視覚的強化（psychovisual enhancement）で符号化され、かつ、各ビデオ・トラックは、それに関係付けられた少なくとも１つのオーディオ・トラックを有する。

別実施例において、各ビデオ・トラックは、「RIFF」チャンク内における一連の「映像（video）」チャンクとして符号化され、かつ、各ビデオ・トラックに付随するオーディオ・トラックは、関係付けられたビデオ・トラックの「ビデオ」チャンクを含む「RIFF」チャンク内に交互配置（interleave）された一連の「オーディオ（audio）」チャンクとして符号化される。更に、各「ビデオ」チャンクは、ビデオ・トラックからビデオの単一フレームを生成すべく使用され得る情報を含み得ると共に、各「オーディオ」チャンクは、「ビデオ」チャンクを用いて生成されたフレームに付随するオーディオ・トラックの部分からのオーディオ情報を含む。これに加え、「オーディオ」チャンクは「RIFF」チャンク内において対応する「ビデオ」チャンクの前に交互配置され得る。

本発明の実施例によるマルチメディア・ファイルを符号化するシステムは、複数のビデオ・トラックを符号化し、符号化ビデオ・トラックを連結し、かつ、連結された符号化ビデオ・トラックを単一ファイルへと書き込むように構成されたプロセッサを含む。別な実施例において、プロセッサは各ビデオ・トラックが別個の「RIFF」チャンク内に含まれるようなビデオ・トラックに符号化すべく構成され、かつ、プロセッサは、心理視覚的強化を用いてビデオを符号化すべく構成される。これに加え、各ビデオ・トラックは自身に関係付けられた少なくとも一つのオーディオ・トラックを有し得る。

別な実施例においてプロセッサは、各ビデオ・トラックを「RIFF」チャンク内における一連の「ビデオ」チャンクとして符号化し、かつ、各ビデオ・トラックに付随する少なくとも一つのオーディオ・トラックを、関係付けられたビデオ・トラックの「ビデオ」チャンクを含む「RIFF」チャンク内に交互配置された一連の「オーディオ」チャンクとして符号化するように構成される。

さらに別の実施例において、プロセッサは、各「ビデオ」チャンクが、ビデオ・トラックからビデオの単一フレームを生成すべく使用され得る情報を含むようなビデオ・トラックを符号化し、かつ、ビデオ・トラックに関係付けられたオーディオ・トラックを、各「オーディオ」チャンクが、ビデオ・トラックから生成された「ビデオ」チャンクを用いて生成されたフレームに付随するオーディオ・トラックの部分からのオーディオ情報を含む如く、符号化するように構成される。これに加え、プロセッサは、各「オーディオ」チャンクを「RIFF」チャンク内において対応する「ビデオ」チャンクに先立ち交互配置するように構成され得る。

本発明の実施例による複数の符号化ビデオ・トラックを含むマルチメディア・ファイルを復号化するシステムは、マルチメディア・ファイルから情報を抽出すべく構成されたプロセッサを含む。そのプロセッサは、マルチメディア・ファイル内に含まれた符号化ビデオ・トラックの数に関する情報を抽出すべく構成される。

更なる実施例においてプロセッサは、「RIFF」チャンク内において符号化ビデオ・トラックを検索（locate）すべく構成される。これに加え、標準的な4ccコードを有する第１「RIFF」チャンク内には第１の符号化ビデオ・トラックが含まれ得ると共に、特殊な4ccコードを有する第２「RIFF」チャンク内には第２のビデオ・トラックが含まれ、かつ、特殊化4ccコードは、その特殊化4ccコードの最後の２キャラクタとして、標準的な4ccコードの最初の２キャラクタを有し得る。

付加的な実施例において、各符号化ビデオ・トラックは別個に「RIFF」チャンク内に含まれる。

更なる別の実施例において、復号化されたビデオ・トラックは、マルチメディア・ファイルを生成する際に符号化されたオリジナルのビデオ・トラックと同様であり、かつ、復号化されたビデオ・トラックとオリジナルのビデオ・トラックとの間における相違点の少なくとも幾つかは、ビデオ・トラックの各フレームの暗い部分内に配置される。更に、復号化されたビデオ・トラックとオリジナルのビデオ・トラックとの間における相違点の少なくとも幾つかは、ビデオ・トラックの速い動作のシーンに配置され得る。

再び付加的な実施例において各ビデオ・トラックは、自身に関係付けられた少なくとも１つのオーディオ・トラックを有する。

更なる付加的な実施例において、プロセッサは、「RIFF」チャンク内の一連の「ビデオ」チャンクを復号化することにより、ビデオ・トラックからのビデオを表示し、かつ、関係付けられたビデオ・トラックの「ビデオ」チャンクを含む「RIFF」チャンク内に交互配置された一連の「オーディオ」チャンクを復号化することにより、ビデオ・トラックに付随するオーディオ・トラックからオーディオを生成するように構成される。

更に別の更なる実施例において、プロセッサは、各「ビデオ」チャンクから抽出された情報を使用してビデオ・トラックの単一フレームを生成し、かつ、各「オーディオ」チャンクから抽出された情報を使用して、「ビデオ」チャンクを使用して生成されたフレームに付随するオーディオ・トラックの部分を生成するように構成される。これに加えてプロセッサは、「RIFF」チャンクにおいて「オーディオ」チャンクが関係付けられた「ビデオ」チャンクに先立ち、「オーディオ」チャンクを位置決定（locate）すべく構成され得る。

本発明の実施例によるマルチメディア・ファイルは、一連の符号化ビデオ・フレームと、符号化ビデオ・フレームの間に交互配置された符号化オーディオとを含む。符号化オーディオはオーディオ情報の２つ以上のトラックを含む。

更なる実施例において、オーディオ情報のトラックの内の少なくとも１つのトラックは複数のオーディオチャネルを含む。

別実施例は更に、マルチメディア・ファイルに含まれたオーディオ・トラックの個数を特定するヘッダ情報と、オーディオ情報のトラックの内の少なくとも１つのトラックに関する説明情報とを含む。

再び更なる実施例において、各符号化ビデオ・フレームは、符号化オーディオ情報によって発し、かつ、ビデオ・フレームを発生する符号化オーディオ情報は、符号化ビデオ・フレームに付随する各オーディオ・トラックの部分のためのオーディオ情報を含む。

再び別実施例において、ビデオ情報はマルチメディア・ファイル内にチャンクとして記憶される。これに加え、ビデオ情報の各チャンクは、ビデオの単一フレームを含み得る。更に、オーディオ情報はマルチメディア・ファイル内にチャンクとして記憶され得ると共に、２つの別個のオーディオ・トラックからのオーディオ情報は、オーディオ情報の単一チャンク内には含まれない。

更なる実施例において、ビデオ・チャンクは、オーディオ・トラックの各々からの少なくとも１つのオーディオ・チャンクにより分離され、かつ、ビデオ・チャンクを分離するオーディオ・チャンクは、オーディオ・チャンクに追随するビデオ・チャンク内に含まれたビデオ情報に付随するオーディオ・トラックの部分のためのオーディオ情報を含む。

本発明の実施例によるマルチメディア・ファイルを符号化するシステムは、ビデオ・トラックを符号化し、複数のオーディオ・トラックを符号化し、ビデオ・トラックからの情報を複数のオーディオ・トラックからの情報と交互配置し、かつ、交互配置されたビデオおよびオーディオ情報を単一ファイルへと書き込むように構成されたプロセッサを含む。

更なる実施例において、オーディオ・トラックの内の少なくとも１つのオーディオ・トラックは複数のオーディオチャネルを含む。

別実施例においてプロセッサは更に、符号化オーディオ・トラックの数を特定するヘッダ情報を符号化し、かつ、そのヘッダ情報を単一ファイルに書き込みむように構成される。

再び更なる実施例において、プロセッサは更に、符号化オーディオ・トラック内の少なくとも１つの符号化オーディオ・トラックに関する説明情報を特定するヘッダ情報を符号化し、かつ、そのヘッダ情報を単一ファイルに書き込むべく構成される。

再び別実施例において、プロセッサはビデオ・トラックをビデオ情報のチャンクとして符号化する。これに加え、プロセッサは各オーディオ・トラックをオーディオ情報の一連のチャンクとして符号化し得る。更に、オーディオ情報の各チャンクは単一のオーディオ・トラックからのオーディオ情報を含み得ると共に、プロセッサは、ビデオ情報のチャンク間にオーディオ情報のチャンクを交互配置するように構成され得る。

更なる実施例において、プロセッサは、「ビデオ」チャンクにおけるビデオ情報に付随する各オーディオ・トラックの部分を「オーディオ」チャンク内に符号化すべく構成され、かつ、プロセッサは、各「ビデオ」チャンクが、その「ビデオ」チャンクに含まれたビデオ情報に付随するオーディオ・トラックの各々からのオーディオ情報を含む「オーディオ」チャンクにより発生するように、「ビデオ」チャンクおよび「オーディオ」チャンクを交互配置すべく構成される。これに加え、プロセッサは、各ビデオ・チャンク内にビデオの単一フレームが含まれるようにビデオ・トラックを符号化すべく構成され得る。

再び更に別の実施例において、プロセッサは汎用プロセッサである。

付加的な更なる実施例において、プロセッサは専用回路である。

本発明による複数のオーディオ・トラックを含むマルチメディア・ファイルを復号化するシステムは、マルチメディア・ファイルから情報を抽出すべく構成されたプロセッサを含む。プロセッサは、マルチメディア・ファイル内に含まれたオーディオ・トラックの個数に関する情報を抽出すべく構成される。

更なる実施例において、プロセッサは、複数のオーディオ・トラックから単一のオーディオ・トラックを選択すべく構成され、かつ、プロセッサは、選択されたオーディオ・トラックからのオーディオ情報を復号化すべく構成される。

別実施例において、オーディオ・トラックの内の少なくとも一つのオーディオ・トラックは複数のオーディオチャネルを含む。

更なる実施例において、プロセッサは、マルチメディア・ファイルにおけるヘッダからの情報であってオーディオ・トラックの内の少なくとも一つのオーディオ・トラックに関する説明情報を含む情報を抽出すべく構成される。

本発明の実施例によるマルチメディア情報を通信するシステムは、ネットワークと、マルチメディア・ファイルを含むと共に、サーバを介してネットワークに対して接続された記憶デバイスと、ネットワークに接続されたクライアントとを含む。クライアントは、サーバからのマルチメディア・ファイルの転送を要求することができ、かつ、マルチメディア・ファイルは、少なくとも一つのビデオ・トラックと、そのビデオ・トラックに付随する複数のオーディオ・トラックとを含む。

本発明によるマルチメディア・ファイルは、一連の符号化ビデオ・フレームと、符号化ビデオ・フレーム間に交互配置された少なくとも一つの符号化サブタイトルトラックとを含む。

更なる実施例において、少なくとも一つの符号化サブタイトルトラックは複数の符号化サブタイトルトラックから成る。

別な実施例は更に、マルチメディア・ファイルに含まれた符号化サブタイトルトラックの個数を特定するヘッダ情報を更に含む。

更なる実施例もまた、符号化サブタイトルトラックの内の少なくとも一つの符号化サブタイトルトラックに関する説明情報を含むヘッダ情報を含む。

更なる別実施例において、各サブタイトルトラックは一連のビットマップを含み、かつ、各サブタイトルトラックは一連の圧縮ビットマップを含み得る。これに加え、各ビットマップはランレングス符号化方法を用いて圧縮される。

更なる実施例において、一連の符号化ビデオ・フレームは一連のビデオ・チャンクとして符号化され、かつ、各符号化サブタイトルトラックは一連のサブタイトル・チャンクとして符号化される。各サブタイトル・チャンクは、表示上にテキストとして表され得る情報を含む。これに加え、各サブタイトル・チャンクは単一のサブタイトルに関する情報を含み得る。更に、各サブタイトル・チャンクは、サブタイトルがスーパーインポーズ（superimpose）されるべきビデオ・シーケンスの部分に関する情報を含み得る。

更に別の実施例において、各サブタイトル・チャンクは、サブタイトルが配置されるべき表示の部分に関する情報を含む。

再び更なる実施例において、各サブタイトル・チャンクは、サブタイトルの色に関する情報を含み、かつ、色に関する情報は色パレート（palate）を含み得る。これに加え、サブタイトル・チャンクは、第１色パレートに関する情報を含む第１サブタイトル・チャンクと、第１色パレートに関する情報に成り代わる第２色パレートに関する情報を含む第２サブタイトル・チャンクとを備え得る。

本発明の実施例によるマルチメディア・ファイルを符号化するシステムは、ビデオ・トラックを符号化し、少なくとも一つのサブタイトルトラックを符号化し、ビデオ・トラックからの情報を、少なくとも一つのサブタイトルトラックからの情報と交互配置し、かつ、交互配置されたビデオおよびサブタイトル情報を単一ファイルに書き込むように構成されたプロセッサを含み得る。

更なる実施例において、少なくとも一つのサブタイトルトラックは複数のサブタイトルトラックを含む。

別実施例において、プロセッサは更に、マルチメディア・ファイルに含まれたサブタイトルトラックの個数を特定するヘッダ情報を符号化して単一ファイルに書き込むべく構成される。

再び更なる実施例において、プロセッサは更に、サブタイトルトラックの内の少なくとも一つのサブタイトルトラックに関する説明情報を符号化して単一ファイルに書き込むべく構成される。

別の更なる実施例において、ビデオ・トラックはビデオ・チャンクとして符号化され、かつ、少なくとも一つのサブタイトルトラックの各々はサブタイトル・チャンクとして符号化される。これに加え、サブタイトル・チャンクの各々は、ビデオ・トラックの一部に付随する単一のサブタイトルを含み得ると共に、インタリーバ（interleaver）は、ビデオ・トラックの部分であってサブタイトル・チャンク内のサブタイトルが付随する部分を含むビデオ・チャンクの前に、各サブタイトル・チャンクを交互配置すべく構成され得る。

更なる実施例において、プロセッサは、サブタイトルをビットマップとして符号化することによりサブタイトル・チャンクを生成すべく構成される。

更なる別実施例において、サブタイトルは圧縮ビットマップとして符号化される。これに加え、ビットマップはランレングス符号化方法を用いて圧縮され得る。更に、プロセッサは各サブタイトル・チャンク内に、サブタイトルがスーパーインポーズされるべきビデオ・シーケンスの部分に関する情報を含み得る。

更なる実施例において、プロセッサは各サブタイトル・チャンク内に、サブタイトルが配置されるべき表示の部分に関する情報を含む。

更に別の実施例において、プロセッサは各サブタイトル・チャンク内に、サブタイトルの色に関する情報を含む。

更なる実施例において、色に関する情報は色パレートを含む。これに加え、サブタイトル・チャンクは、第１色パレートに関する情報を含む第１サブタイトル・チャンクと、第１色パレートに関する情報に成り代わる第２色パレートに関する情報を含む第２サブタイトル・チャンクとを含み得る。

本発明の実施例によるマルチメディア・ファイルは、マルチメディア・ファイルから情報を抽出すべく構成されたプロセッサを含む。プロセッサは、マルチメディア・ファイルを検査して、少なくとも一つのサブタイトルトラックが在るか否かを決定すべく構成される。これに加え、少なくとも一つのサブタイトルトラックは、複数のサブタイトルトラックを備え得ると共に、プロセッサはマルチメディア・ファイル内におけるサブタイトルトラックの数を決定すべく構成され得る。

更なる実施例において、プロセッサは更に、サブタイトルトラックの数を特定するヘッダ情報を、マルチメディア・ファイルから抽出すべく構成される。

別な実施例において、プロセッサは更に、サブタイトルトラックの内の少なくとも一つのサブタイトルトラックに関する説明情報をマルチメディア・ファイルから抽出すべく構成される。

再び更なる実施例において、マルチメディア・ファイルは、ビデオ・チャンクとして符号化された少なくとも一つのビデオ・トラックを含み、かつ、マルチメディア・ファイルは、サブタイトル・チャンクとして符号化された少なくとも一つのサブタイトルトラックを含む。

再び別実施例において、各サブタイトル・チャンクは単一のサブタイトルに関する情報を含む。

更なる実施例において、各サブタイトルはサブタイトル・チャンク内においてビットマップとして符号化され、プロセッサは、ビデオ・トラックを復号化すべく構成され、かつ、プロセッサは、ビットマップをビデオ・シーケンスの一部上にスーパーインポーズすることにより、表示のためのビデオのフレームを構築すべく構成される。これに加え、サブタイトルは圧縮ビットマップとして符号化され得ると共に、プロセッサはビットマップを解凍すべく構成され得る。更に、プロセッサは、ランレングス符号化されたビットマップを解凍すべく構成され得る。

更なる別実施例において、各サブタイトル・チャンクは、サブタイトルがスーパーインポーズされるべきビデオ・トラックの部分に関する情報を含み、かつ、プロセッサは、サブタイトル・チャンクにおける情報により表された各ビデオ・フレーム上にサブタイトルのビットマップをスーパーインポーズすることにより、表示のための一連のビデオ・フレームを生成すべく構成される。

付加的な更なる実施例において、各サブタイトル・チャンクは、サブタイトルが配置されるべきフレーム内の位置に関する情報を含み、かつ、プロセッサは、サブタイトル・チャンク内の情報により表された各ビデオ・フレーム内の位置にサブタイトルをスーパーインポーズすべく構成される。

別の付加的な実施例において、各サブタイトル・チャンクは、サブタイトルの色に関する情報を含み、かつ、プロセッサは、サブタイトル・チャンク内の色情報により表される単一もしくは複数の色でサブタイトルをスーパーインポーズすべく構成される。これに加え、サブタイトル・チャンク内における色情報は色パレートを含み得ると共に、プロセッサは、色パレートを用いてサブタイトルのビットマップにおいて使用される色情報を獲得して、サブタイトルをスーパーインポーズすべく構成される。更に、サブタイトル・チャンクは、第１色パレートに関する情報を含む第１サブタイトル・チャンクと、第２色パレートに関する情報を含む第２サブタイトル・チャンクとを備え得ると共に、プロセッサは、第１色パレートを用いて、第１チャンクが処理された後にサブタイトルのビットマップにおいて使用される色に関する情報を獲得して、サブタイトルをスーパーインポーズすべく構成されることが可能であり、かつ、プロセッサは、第２色パレートを用いて、第２チャンクが処理された後にサブタイトルのビットマップにおいて使用される色に関する情報を獲得して、サブタイトルをスーパーインポーズすべく構成され得る。

本発明の実施例によるマルチメディア情報を通信するシステムは、ネットワークと、マルチメディア・ファイルを含むと共に、サーバを介してネットワークに対して接続された記憶デバイスと、ネットワークに接続されたクライアントとを含む。クライアントは、サーバからのマルチメディア・ファイルの転送を要求し、かつ、マルチメディア・ファイルは、少なくとも一つのビデオ・トラックと、そのビデオ・トラックに付随する少なくとも一つのサブタイトルトラックとを含む。

本発明の実施例によるマルチメディア・ファイルは、一連の符号化ビデオ・フレームと、符号化されたメニュー情報とを含む。これに加え、符号化されたメニュー情報はチャンクとして記憶され得る。

更なる実施例は少なくとも２つの別個のメニュー情報の「menu（メニュー）」チャンクも含み、かつ、少なくとも２つの別個の「menu」チャンクは少なくとも２つの別個の「RIFF」チャンクに含まれ得る。

別実施例において、「menu」チャンクを含む第１「RIFF」チャンクは標準的な4ccコードを含むと共に、「menu」チャンクを含む第２「RIFF」チャンクは特殊な4ccコードを含み、標準的な4ccコードの最初の２個のキャラクタは特殊化4ccコードの最後の２個のキャラクタとして現れる。

再び更なる実施例において、単一の「RIFF」チャンク内には少なくとも２つの別個の「menu」チャンクが含まれる。

再び別実施例において、「menu」チャンクは、一連のメニューを記述するチャンクと、一連のメニューに関係付けられたメディアを含む「MRIF」チャンクとを含む。これに加え、「MRIF」チャンクは、ビデオ・トラック、オーディオ・トラックおよびオーバレイトラックを含むメディア情報を含み得る。

更なる実施例において、一連のメニューを記述するチャンクは、メニュー・システム全体を記述するチャンクと、各メニューを言語によりグループ化する少なくとも一つのチャンクと、個々のメニュー表示と、付随するバックグラウンド・オーディオとを記述する少なくとも一つのチャンクと、メニュー上のボタンを記述する少なくとも一つのチャンクと、画面上におけるボタンの箇所を記述する少なくとも一つのチャンクと、ボタンに関係付けられた種々の動作を記述する少なくとも一つのチャンクとを含み得る。

更なる別実施例は、第２ファイルに対するリンクも含む。符号化されたメニュー情報は第２ファイル内に含まれる。

本発明の実施例によるマルチメディア・ファイルを符号化するシステムは、メニュー情報を符号化すべく構成されたプロセッサを含む。そのプロセッサはまた、符号化ビデオ・トラックおよび符号化されたメニュー情報を含むマルチメディア・ファイルを生成するようにも構成される。これに加え、プロセッサは、メニューのオブジェクト・モデルを生成し、オブジェクト・モデルを設定ファイルへと変換し、設定ファイルを解析してチャンクとし、メディア情報を含むAVIファイルを生成し、AVIファイル内のメディアを「MRIF」チャンク内へと交互配置し、かつ、解析されたチャンクを「MRIF」チャンクと連結して「menu」チャンクを生成するように構成され得る。また、プロセッサは更に、オブジェクト・モデルを使用して第２の更に小さな「menu」チャンクを生成すべく構成され得る。

更なる実施例において、プロセッサは第２メニューを符号化すべく構成され、かつ、プロセッサは、第１の符号化メニューを第１「RIFF」チャンクに挿入しかつ第２の符号化メニューを第２「RIFF」チャンクに挿入し得る。

別実施例において、プロセッサは第１および第２の符号化メニューを単一の「RIFF」チャンク内に含む。

再び更なる実施例において、プロセッサは、マルチメディア・ファイル内に、第２ファイルにおける符号化メニューに対するリファレンスを挿入すべく構成される。

本発明によるマルチメディア・ファイルを復号化するシステムは、マルチメディア・ファイルから情報を抽出すべく構成されたプロセッサを含む。プロセッサは、マルチメディア・ファイルを検査して、それが符号化されたメニュー情報を含むか否かを決定すべく構成される。これに加え、プロセッサは、「RIFF」チャンク内の「menu」チャンクからメニュー情報を抽出すべく構成され得ると共に、プロセッサは、「menu」チャンクに記憶されたビデオ情報を用いてメニュー表示を構築すべく構成され得る。

更なる実施例において、プロセッサは、「menu」チャンクに記憶されたオーディオ情報を用い、メニュー表示に付随するバックグラウンド・オーディオを生成すべく構成される。

別実施例において、プロセッサは、「menu」チャンクからのオーバレイを、その「menu」チャンクからのビデオ情報に重ね合わせることによりメニュー表示を生成すべく構成される。

本発明によるマルチメディア情報を通信するシステムは、ネットワークと、マルチメディア・ファイルを含むと共に、サーバを介してネットワークに対して接続された記憶デバイスと、ネットワークに接続されたクライアントとを含む。クライアントは、サーバからのマルチメディア・ファイルの転送を要求することができ、かつ、マルチメディア・ファイルは符号化されたメニュー情報を含む。

マルチメディア・ファイルは、一連の符号化ビデオ・フレームと、そのマルチメディア・ファイルに関する符号化メタデータとを含む。符号化メタデータは、主部（subject）、述部、目的部（object）および出典（authority）を備える少なくとも一つのステートメント（statement）を含む。主部は、メタデータにより記述されるファイル、項目、人物または組織を特定する情報を含むことができ、述部は主部の特性を表す情報を含むことができ、目的部は、述部により特定された主部の特性を記述する情報を含むことができ、かつ、出典はステートメントのソースに関する情報を含むことができる。

更なる実施例において、主部はタイプおよび値を含むチャンクであり、値は情報を含み、かつ、タイプは、チャンクがリソースであるか匿名ノードであるかを表す。

別実施例において、述部は、タイプおよび値を含むチャンクであり、値は情報を含み、かつ、タイプは、値情報が記述URIであるか順序リスト・エントリであるかを表す。

再び更なる実施例において、目的部は、タイプ、言語、データタイプおよび値を含むチャンクであり、値は情報を含み、タイプは、値情報がUTF-8リテラル、リテラル整数またはリテラルXMLデータであるかを表し、データタイプは値情報のタイプを表し、かつ、言語は特定言語を指定する情報を含む。

再び別実施例において、出典はタイプおよび値を含むチャンクであり、値は情報を含み、かつ、タイプは、値情報がステートメントの出典であることを表す。

更なる実施例において、符号化データの少なくとも一部は２値データとして表される。

更に別の実施例において、符号化データの少なくとも一部は64ビットASCIデータとして表される。

更なる実施例において、符号化データの少なくとも第１部分は２値データとして表され、かつ、符号化データの少なくとも第２部分は第２フォーマットで表されたデータを含む付加的チャンクとして表される。これに加え、付加的チャンクは各々、単一のメタデータを含み得る。

本発明の実施例によるマルチメディア・ファイルを符号化するシステムは、ビデオ・トラックを符号化すべく構成されたプロセッサを含む。プロセッサは、マルチメディア・ファイルに関するメタデータを符号化する様にも構成され、かつ、符号化メタデータは、主部、述部、目的部および出典を備える少なくとも一つのステートメントを含む。これに加え、主部は、メタデータにより記述されるファイル、項目、人物または組織を特定する情報を含むことができ、述部は主部の特性を表す情報を含むことができ、目的部は、述部により特定された主部の特性を記述する情報を含むことができ、かつ、出典はステートメントのソースに関する情報を含むことができる。

更なる実施例において、プロセッサは主部を、タイプおよび値を含むチャンクとして符号化すべく構成され、値は情報を含み、かつ、タイプは、チャンクがリソースであるか匿名ノードであるかを表す。

別実施例において、プロセッサは述部を、タイプおよび値を含むチャンクとして符号化すべく構成され、値は情報を含み、かつ、タイプは、値情報が記述URIであるか順序リスト・エントリであるかを表す。

再び更なる実施例において、プロセッサは目的部を、タイプ、言語、データタイプおよび値を含むチャンクとして符号化すべく構成され、値は情報を含み、タイプは、値情報がUTF-8リテラル、リテラル整数またはリテラルXMLデータであるかを表し、データタイプは値情報のタイプを表し、かつ、言語は特定言語を指定する情報を含む。

再び別実施例において、プロセッサは出典を、タイプおよび値を含むチャンクとして符号化すべく構成され、値は情報を含み、かつ、タイプは、値情報がステートメントの出典であることを表す。

更なる実施例において、プロセッサは更に、マルチメディア・ファイルに関するメタデータの少なくとも一部を２値データとして符号化すべく構成される。

更なる別実施例において、プロセッサは更に、マルチメディア・ファイルに関するメタデータの少なくとも一部を64ビットASCIデータとして符号化すべく構成される。

付加的な実施例において、プロセッサは更に、マルチメディア・ファイルに関するメタデータの少なくとも第１部分を２値データとして符号化し、かつ、マルチメディア・ファイルに関するメタデータの少なくとも第２部分を、第２フォーマットで表されたデータを含む付加的チャンクとして符号化するように構成される。これに加え、プロセッサは更に、付加的チャンクを単一のメタデータを以て符号化すべく構成され得る。

本発明によるマルチメディア・ファイルを復号化するシステムは、マルチメディア・ファイルから情報を抽出すべく構成されたプロセッサを含む。プロセッサは、マルチメディア・ファイルに関するメタデータ情報を抽出すべく構成され、かつ、メタデータ情報は、主部、述部、目的部および出典を備える少なくとも一つのステートメントを含む。これに加え、プロセッサは主部から、メタデータにより記述されるファイル、アイテム、人物または組織を特定する情報を抽出すべく構成され得る。更に、プロセッサは、述部から主部の特性を表す情報を抽出すべく構成されることができ、プロセッサは目的部から、述部により特定される主部の特性を記述する情報を抽出すべく構成されることができ、かつ、プロセッサは、出典からステートメントのソースに関する情報を抽出すべく構成されることができる。

更なる実施例において、主部はタイプおよび値を含むチャンクであり、プロセッサは、タイプを検査することにより、チャンクは主部情報を含むことを特定すべく構成され、かつ、プロセッサは、値から情報を抽出すべく構成される。

別実施例において、述部は、タイプおよび値を含むチャンクであり、プロセッサは、タイプを検査することにより、チャンクは述部情報を含むことを特定すべく構成され、かつ、プロセッサは、値から情報を抽出すべく構成される。

再び更なる実施例において、目的部は、タイプ、言語、データタイプおよび値を含むチャンクであり、プロセッサは、タイプを検査することにより、チャンクは目的部情報を含むことを特定すべく構成され、プロセッサは、データタイプを検査することで、値に含まれる情報のデータタイプを決定すべく構成され、プロセッサは、データタイプにより表されるタイプの情報を値から抽出すべく構成され、かつ、プロセッサは、特定言語を指定する情報を値から抽出すべく構成される。

再び別実施例において、出典はタイプおよび値を含むチャンクであり、プロセッサは、タイプを検査することにより、チャンクは出典情報を含むことを特定すべく構成され、かつ、プロセッサは、値から情報を抽出すべく構成される。

更なる実施例において、プロセッサは、メタデータ・ステートメントから情報を抽出してその情報の少なくとも一部を表示すべく構成される。

更なる別実施例において、プロセッサは、メタデータを用い、メモリ内にラベル付き有向グラフを表すデータ構造を構築すべく構成される。

更なる実施例において、プロセッサは、複数のステートメントに対して主部、述部、目的部および出典の内の少なくとも一つを検査することにより、メタデータを介して情報を検索するように構成される。

更に別の実施例において、プロセッサは、検索の結果を、グラフィカル・ユーザ・インタフェースの一部として表示すべく構成される。これに加え、プロセッサは、外部デバイスからの要求に応じて検索を実施すべく構成され得る。

付加的な更なる実施例において、マルチメディア・ファイルに関するメタデータ情報の少なくとも一部は２値データとして表される。

別の付加的な実施例において、マルチメディア・ファイルに関するメタデータ情報の少なくとも一部は64ビットASCIデータとして表される。

別の更なる実施例において、マルチメディア・ファイルに関するメタデータ情報の少なくとも第１部分は２値データとして表され、かつ、マルチメディア・ファイルに関するメタデータ情報の少なくとも第２部分は第２フォーマットで表されたデータを含む付加的チャンクとして表される。これに加え、付加的チャンクは単一のメタデータを含み得る。

本発明によるマルチメディア情報を通信するシステムは、ネットワークと、マルチメディア・ファイルを含むと共に、サーバを介してネットワークに対して接続された記憶デバイスと、ネットワークに接続されたクライアントとを含む。クライアントは、サーバからのマルチメディア・ファイルの転送を要求することができ、マルチメディア・ファイルはそのマルチメディア・ファイルに関するメタデータを含み、かつ、メタデータは、主部、述部、目的部および出典を備える少なくとも一つのステートメントを含む。

本発明によるマルチメディア・ファイルは、少なくとも一つの符号化ビデオ・トラックと、少なくとも一つの符号化オーディオ・トラックと、複数の符号化テキスト文字列とを含む。符号化テキスト文字列は、少なくとも一つのビデオ・トラックおよび少なくとも一つのオーディオ・トラックの特性を記述する。

更なる実施例において、複数のテキスト文字列は、異なる言語を用い、ビデオ・トラックまたはオーディオ・トラックと同一の特性を記述する。

別実施例は、少なくとも一つの符号化サブタイトルトラックも含む。複数の符号化テキスト文字列はサブタイトルトラックの特性を記述する文字列を含む。

本発明によるマルチメディア・ファイルを生成するシステムは、少なくとも一つのビデオ・トラックを符号化し、少なくとも一つのオーディオ・トラックを符号化し、符号化オーディオ・トラックの内の少なくとも一つの符号化オーディオ・トラックをビデオ・トラックと交互配置し、少なくとも一つのビデオ・トラックおよび少なくとも一つのオーディオ・トラックの所定数の特性の各々を複数の言語で記述するテキスト文字列を挿入するように構成されたプロセッサを含む。
本発明による符号化オーディオ、ビデオおよびテキスト文字列を含むマルチメディア・ファイルを表示するシステムは、マルチメディア・ファイルから符号化テキスト文字列を抽出し、かつ、テキスト文字列を用いてプルダウン・メニュー表示を生成するように構成されたプロセッサを含む。

本発明の実施例によるファイルを符号化、配信および復号化するシステムの図である。 本発明の実施例によるマルチメディア・ファイルの構造の図である。 本発明の別な実施例によるマルチメディア・ファイルの構造の図である。 本発明の一実施例による「hdrl」リスト・チャンクの概略図である。 本発明の実施例による「strl」チャンクの概略図である。 本発明の実施例によるマルチメディア・ファイルの「DXDT」チャンクを記憶すべく割当てられたメモリの概略図である。 本発明の実施例によるマルチメディア・ファイルの「DXDT」チャンク内に含まれ得る「メタデータ」チャンクの概略図である。 本発明の実施例による「DMNU」チャンクの概略図である。 本発明の実施例による「WowMenuManager」チャンクに含まれたメニュー・チャンクの概略図である。 本発明の別な実施例による「WowMenuManager」チャンク内に含まれたメニュー・チャンクの概略図である。 本発明の実施例による「DMNU」チャンク内に含まれた種々のチャンク間の関係を示す概略図である。 本発明の実施例によるマルチメディア・ファイルの「movi」リスト・チャンクの概略図である。 DRMを含む本発明の実施例によるマルチメディア・ファイルの「movi」リスト・チャンクの概念的概略図である。 本発明の実施例による「DRM」チャンクの概略図である。 本発明の実施例によるマルチメディア・ファイルを生成するシステムのブロック図である。 本発明の実施例による「DXDT」チャンクを生成するシステムのブロック図である。 本発明の実施例による「DMNU」チャンクを生成するシステムのブロック図である。 本発明の実施例によるメディア・モデルの概略図である。 本発明の実施例によるスモール・メニューを自動的に生成すべく使用され得るメディア・モデルからのオブジェクトの概略図である。 本発明の実施例によるオーディオを再チャンクすべく使用され得る処理のフローチャートである。 本発明の実施例によるビデオ・エンコーダのブロック図である。 本発明の実施例によるＩフレーム上で円滑な心理視覚的強化を実施する方法のフローチャートである。 本発明の実施例によるマクロブロックＳＡＤの心理視覚的強化を実施する処理のフローチャートである。 本発明の実施例によるワンパス速度制御のための処理のフローチャートである。 本発明の実施例による第ＮパスＶＢＶ速度制御を実施する処理のフローチャートである。 本発明の実施例によるマルチメディア・ファイルから必要なマルチメディア情報を検索し、そのマルチメディア情報を表示する処理のフローチャートである。 本発明の実施例によるデコーダのブロック図である。 本発明の実施例による表示されたメニューの例を示す図である。 本発明の実施例による図４．２．に示された表示を生成すべく使用される情報のソースを示す概略図である。

図面を参照する本発明の実施例は、マルチメディア・ファイルを符号化、送信および復号化することができる。本発明の実施例によるマルチメディア・ファイルは、複数のビデオ・トラックと、複数のオーディオ・トラックと、複数のサブタイトルトラックと、ファイルの内容にアクセスするメニュー・インタフェースを生成すべく使用され得るデータと、ファイルの内容に関する「メタデータ」とを含み得る。本発明の幾つかの実施例によるマルチメディア・ファイルは、ビデオ・トラック、オーディオ・トラック、サブタイトルトラック、およびファイル外部の「meta data」へのリファレンスも含む。

１．システムの説明
次に図１を参照すると、ファイルを符号化、配信および復号化する本発明の実施例によるシステムが示される。システム１０は、ネットワーク１４を介して他の種々の演算デバイスに対して接続されるコンピュータ１２を含む。ネットワークに接続され得るデバイスとしては、サーバ１６、ラップトップ・コンピュータ１８およびパーソナル・デジタル・アシスタント（ＰＤＡ）２０が挙げられる。種々の実施例においてデバイスとネットワークとの間の接続は、有線もしくは無線でされると共に、種々のネットワーク用プロトコル内の任意のプロトコルを用いて実施され得る。

作動時にコンピュータ１２は、本発明の実施例によるマルチメディア・ファイルを符号化すべく使用され得る。コンピュータ１２はまた、本発明の実施例によるマルチメディア・ファイルを復号化すると共に本発明の実施例によるマルチメディア・ファイルを配信するためにも使用され得る。コンピュータは、ピアツーピア・ネットワークを介するなどの種々のファイル転送プロトコルの内の任意のプロトコルを用いてファイルを配信し得る。これに加えてコンピュータ１２は、本発明の実施例によるマルチメディア・ファイルをラップトップ・コンピュータ１８へと転送でき、そこでファイルは他のデバイスによりアクセスされ得る。その他のデバイスとしては、任意の種々の演算デバイス、または、専用のデコーダ・デバイスも含まれる。図示の実施例においては、ラップトップ・コンピュータおよびＰＤＡが示される。他の実施例においては、デジタル・セットトップボックス、デスクトップ・コンピュータ、ゲーム機、家電機器および他のデバイスがネットワークに接続され、マルチメディア・ファイルをダウンロードしてそれを復号化し得る。

一実施例において、デバイスはサーバからネットワークを介してマルチメディア・ファイルにアクセスする。他の実施例において、デバイスは、多数のコンピュータからピアツーピア・ネットワークを介してマルチメディア・ファイルにアクセスする。幾つかの実施例においてマルチメディア・ファイルは、ディスク・ドライブ、ＣＤ−ＲＯＭまたはＤＶＤなどの可搬的記憶デバイスに対して書き込まれ得る。多くの実施例において、電子的デバイスは可搬的記憶デバイスに書き込まれたマルチメディア・ファイルにアクセスし得る。

２．ファイル構造の説明
本発明の実施例によるマルチメディア・ファイルは、ワシントン州、レドモンド市のＭｉｃｒｏｓｏｆｔ社およびニューヨーク州、アーモンク市のＩＢＭ（International Business Machines）社により策定されたリソース交換ファイル・フォーマット（「RIFFファイル・フォーマット」）に準拠すべく構造化され得る。RIFFは、マルチメディア・データおよび関連情報を記憶するためのファイル・フォーマットである。RIFFファイルは典型的に、ファイルを特定する８バイトのRIFFヘッダであり、RIFFヘッダは、そのファイルを識別し、かつ、そのヘッダの後におけるファイルの残存長（すなわちファイル長−８）を提供する。RIFFファイルの残りの全ては、“チャンク（chunk）”および“リスト（list）”から成る。各チャンクは、チャンクのタイプを特定する８バイトのチャンク・ヘッダを有し、そのチャック・ヘッダは、そのチャンク・ヘッダに続くデータの長さをバイト単位で与える。各リストは、８バイトのリスト・ヘッダを有し、そのリスト・ヘッダは、そのリスト・ヘッダに続くデータの長さをバイト単位で与える。リストにおけるデータは、チャンクおよび／または他のリスト（これは更にチャンクおよび／または他のリストを備え得る）を備える。RIFFリストは、一定の場合には“リスト・チャンク”とも称される。

AVIファイルはRIFFファイルの特定形態であり、RIFFファイルのフォーマットに追随するが、特定フォーマットにおけるマルチメディア・データを含む定義済み識別子を備えた種々のチャンクおよびリストを含んでいる。AVIフォーマットは、Microsoft社により開発かつ規定された。AVIファイルは典型的に、AVIフォーマットでマルチメディア・データを出力し得るエンコーダを用いて生成される。AVIファイルは典型的に、集合的にAVIデコーダとして知られた一群のソフトウェア内の任意のソフトウェアにより復号化される。

RIFFおよびAVIフォーマットは、規定されたファイル・フォーマットの一部であるチャンクおよびリストを規定するだけでなく、そのファイルが、RIFFおよび／またはAVIデコーダによるそのファイルを読取不能とせずにRIFFおよび／またはAVIファイル・フォーマット定義外のリストおよび／またはチャンクを含むことも許容する点において、融通性が高い。実際問題としてAVI（および同様のRIFF）デコーダは、AVIファイル・フォーマット定義に見出されないヘッダ情報を含むリストおよびチャンクを単に無視する様に実現される。AVIデコーダは、それでもこれらの非AVIチャンクおよびリストを読み取らなければならい場合、AVIデコーダの動作は遅くなるが、その他の場合は、一般に、それらはAVIデコーダに対して効果を有さずにAVIデコーダにより無視される。

図２．０．には、本発明の実施例によるマルチメディア・ファイルが示される。図示されたマルチメディア・ファイル３０は、キャラクタ・セット・チャンク（「CSET」チャンク）３２、情報リスト・チャンク（「INFO」リスト・チャンク）３４、ファイル・ヘッダ・チャンク（「hdrl」リスト・チャンク）３６、メタデータ・チャンク（「DXDT」チャンク）３８、メニュー・チャンク（「DMNU」チャンク）４０、ジャンク・チャンク（「junk」チャンク）４１、ムービー・リスト・チャンク（「movi」リスト・チャンク）４２、選択的インデックス・チャンク（「idxl」チャンク）４４および第２メニュー・チャンク（「DMNU」チャンク）４６を含む。これらのチャンクの一定部分および他のチャンクの一部はAVIファイル・フォーマットにおいて規定されるが、その他のチャンクはAVIファイル・フォーマットには含まれない。全ての場合ではないが多くの場合に以下の考察は、AVIファイル・フォーマットの一部として規定されたチャンクまたはチャンク部分を特定する。

図２．０．１．には、本発明の実施例による別のマルチメディア・ファイルが示される。マルチメディア・ファイル３０’は、そのファイルが複数の連結「RIFF」チャンクを含むことを除き、図２．０．に示されたファイルと同様である。その「RIFF」チャンクは、図２．０．に示された「RIFF」チャンクであって第２「DMNU」チャンク４６を除外し得るか又は「DMNU」チャンク４６’の形態のメニュー情報を含み得る「RIFF」チャンクを含み得る。

図示の実施例においてマルチメディアは、複数の連結「RIFF」チャンクを含み、その場合に第１「RIFF」チャンク５０は、キャラクタ・セット・チャンク（「CSET」チャンク）３２’、情報リスト・チャンク（「INFO」リスト・チャンク）３４’、ファイル・ヘッダ・チャンク（「hdrl」リスト・チャンク）３６’、メタデータ・チャンク（「DXDT」チャンク）３８’、メニュー・チャンク（「DMNU」チャンク）４０’、ジャンク・チャンク（「junk」チャンク）４１’、ムービー・リスト・チャンク（「movi」リスト・チャンク）４２’および選択的インデックス・チャンク（「idxl」チャンク）４４’を含む。第２「RIFF」チャンク５２は、第２メニュー・チャンク（「DMNU」チャンク）４６’を含む。「RIFF」メニュー・チャンク５２の後には、付加的「RIFF」チャンク５４が含まれ得る。付加的「RIFF」チャンクは、AVIファイル・フォーマットに準拠する独立メディアを含み得る。一実施例において第２メニュー・チャンク４６’および付加的「RIFF」チャンクは、その４個のキャラクタ・コードの第１の２個のキャラクタは、第２の２個のキャラクタとして現れ、かつ、その４個のキャラクタ・コードの第２の２個のキャラクタは第１の２個のキャラクタとして現れるように、（AVIフォーマットで規定されると共に以下で論じられる）特殊な４個のキャラクタ・コードを有する。

２．１．「CSET」チャンク
「CSET」チャンク３２は、Microsoft社により策定されたオーディオ・ビデオ・インターリーブ・ファイル・フォーマット（AVIファイル・フォーマット）において規定されたチャンクである。「CSET」チャンクは、マルチメディア・ファイルのキャラクタ・セットおよび言語情報を規定する。本発明の実施例による「CSET」チャンクを包含することはオプション的である。

本発明の一実施例によるマルチメディア・ファイルは、「CSET」チャンクを使用せずに、言語情報に対してインターネット・エンジニアリング・タスク・フォースにより規定されたRFC 3066言語仕様と組み合わされた既定によるキャラクタ・セットに対して、ユニコード・コンソーシアムにより規定されたUTF-8を使用する。

２．２．「INFO」リスト・チャンク
「INFO」リスト・チャンク34は、マルチメディア・ファイルの内容の識別を助力する情報を記憶し得る。「INFO」リストはAVIファイル・フォーマットにおいて規定されると共に、本発明の実施例によるマルチメディア・ファイルにそれを含めることは選択的である。「DXDT」チャンクを含む多くの実施例は、「INFO」リスト・チャンクを含まない。

２．３．「hdrl」リスト・チャンク
「hdrl」リスト・チャンク38は、AVIファイル・フォーマットに規定されると共に、マルチメディア・ファイルにおけるデータのフォーマットに関する情報を提供する。「hdrl」リスト・チャンク、または、同様の記述情報を含むチャンクは、概略的に必要とされる。「hdrl」リスト・チャンクは、各ビデオ・トラック、各オーディオ・トラックおよび各サブタイトルトラックに対するチャンクを含む。

図２．１．には、１つのビデオトラック６２、２つのオーディオ・トラック６４、外部のオーディオトラック６６、２つのサブタイトルトラック６８および外部のサブタイトルトラック７０を含む本発明の一実施例による「hdrl」リストチャンク３８が示される。「hdrl」リスト６０は、「avih」チャンクを含む。「avih」チャンク６０は、ファイル内におけるストリームの本数、マルチメディア・ファイル内に含まれたビデオの幅および高さなどのファイル全体に対する包括的情報を含む。その「avih」チャンクは、AVIファイル・フォーマットに従い実現され得る。

「avih」チャンクに加え、「hdrl」リストは各オーディオ、ビデオおよびサブタイトルトラックに対するストリーム記述子リストを含む。一実施例においてそのストリーム記述子リストは、「strl」チャンクを用いて実現される。図２．２．には、本発明の実施例による「strl」チャンクが示される。各「strl」チャンクは、マルチメディア・ファイルにおける各トラックを記述する役割を果たす。マルチメディア・ファイル内におけるオーディオ、ビデオおよびサブタイトルトラックに対する「strl」チャンクは、「strh」チャンク９２、「strf」チャンク９４、「strd」チャンク９６および「strn」チャンク９８を参照する「strl」チャンクを含む。これらのチャンクの全ては、AVIファイル・フォーマットに従い実現され得る。特に興味があるのは、メディア・トラックのタイプを特定する「strh」チャンク９２、および、ビデオがデジタル著作権管理により保護されているか否かを表すべく改変され得る「strd」チャンク９６である。本発明の実施例によるデジタル著作権管理の種々の実施方式の考察は、以下に提供される。

本発明の実施例によるマルチメディア・ファイルは、付加的オーディオ・トラックまたは付加的サブタイトルトラックなどのマルチメディア情報を保持する外部ファイルに対するリファレンスを含み得る。これらのトラックに対するリファレンスは、「hdrl」チャンクまたは「junk」チャンク４１のいずれかに含まれ得る。いずれの場合でもリファレンスは、ローカル・ファイルまたはリモートで記憶されたファイルのいずれかを参照する「strl」チャンク９０の「strh」チャンク９２内に含まれ得る。参照されるファイルは、標準的なAVIファイル、または、付加的トラックを含む本発明の実施例によるマルチメディア・ファイルであり得る。

付加的な実施例において、参照されるファイルは、参照を行うファイル内に存在し得るチャンクであって、「DMNU」チャンク、「DXDT」チャンク、および、マルチメディア・プレゼンテーションに対してオーディオ、ビデオおよび／またはサブタイトルトラックと関係付けられたチャンクの内の任意のものを含み得る。たとえば第１マルチメディア・ファイルは、その第１マルチメディア・ファイルの「movi」リスト・チャンク内に配置された第１マルチメディア・プレゼンテーションと、第２マルチメディア・ファイルの「movi」リスト・チャンク内の第２マルチメディア・プレゼンテーションとを参照する（以下において更に詳細に論じられる）「DMNU」チャンクを含み得る。代替的に、両方の「movi」リスト・チャンクは同一のマルチメディア・ファイル内に含まれ得るが、これは、「DMNU」チャンクが配置されるファイルと同一のファイルである必要はない。

２．４．「DXDT」チャンク
「DXDT」チャンク38は、いわゆる「メタデータ」を含む。本発明の実施例によるマルチメディア・ファイルの「DXDT」チャンク内に記憶された「meta data」は、タイトル、作者、著作権保持者およびキャストなどのコンテンツ固有情報を記憶すべく使用され得る。これに加え、使用されるＣＬＩオプションおよび各パスの後における量子化数（quantizer）分布などの、マルチメディア・ファイルを符号化すべく使用されるコーデック（codec）に関する技術的詳細が提供され得る。

一実施例においてメタデータは一連のステートメントとして「DXDT」チャンク内に表され、その場合に各ステートメントは主部（subject）、述部（predicate）、目的部（object）および出典（authority）を含む。主部は、記述されている処に対する参照である。主部は、ファイル、アイテム、人物または組織を参照し得る。主部は、記述を行い得る特性を有する任意のものを参照し得る。述部は、記述されている主部の特性を特定する。目的部は特定された主部の特性の記述であり、かつ、出典は情報のソースを特定する。

以下の表は、種々の「meta data」が目的部、述部、主部および出典として如何に表され得るかの例を示している。

一実施例において、主部、述部、目的部および出典の表現は、ラベル付き有向グラフ（ＤＬＧ：Directed-Labeled Graphs）を形成し得るデータの２進表現を用いて実現される。ＤＬＧは、リソースもしくはリテラル（literal）のいずれかであるノードから成る。リソースは、インターネット・エンジニアリング・タスク・フォースによりRFC2396（http://www.ictf.org/rfc/rfc2396.txt）において規定された汎用リソース識別子（ＵＲＩ）などの命名規則に準じ得るか、または、システム自体に固有のデータを参照し得る識別子である。リテラルは、リファレンスではなく実際の値の表現である。

ＤＬＧの利点は、これによれば、映画の出演者などの同一タイプである可変数のデータが含まれ得ることである。表１に示された例においては、３人の出演者が含まれる。但し、任意数の出演者が含まれ得る。ＤＬＧはまた、他のデータタイプに対する関連接続も許容する。表１においては、主部「_:file281」、述部「シリーズ」および目的部「_:file321」を有する「メタデータ（meta data）」アイテムが在る。主部「_:file281」は、「meta data」が（この場合には映画「マトリックス（The Matrix）」である）「_:file321」として参照されたファイルの内容を参照することを表している。述部は「シリーズ（Series）」であり、目的部が「マトリックス」が属するシリーズの別の映画に関する情報を有することを表している。但し、「_:file321」はタイトルでも、「マトリックス」を含むシリーズに関する他の一切の特定情報でもなく、「_:file321」に関する更なる情報を提供する別のエントリに対するリファレンスである。但し、主部「_:file321」を有する次の「meta data」エントリは、「_:file321」に関するデータ、すなわち、この続編の「http://purl.org/dc/elements/1.1/title」により表されるダブリン・コア・ボキャブラリ（Dublin Core Vocabulary）により特定されるタイトルは、「マトリックス・リローデッド」であるというデータを含む。

表１における付加的な「meta data」ステートメントは、キアヌ・リーブスはネオの役を演じた出演者であったこと、および、ラリーおよびアンディ・ウォシャウスキーの両名は監督であったことを特定している。「meta data」においては技術的情報も表現される。「meta data」ステートメントは、“_:file281”はトラック“_:track#dc00”を含むことを特定する。「meta data」は、ビデオ・トラックの解像度、ビデオ・トラックの認証レベル、および、コーデックの設定を含む情報を提供する。表１においては示されないが、「meta data」は、符号化の時点でトラックに割当てられた一意的識別子も含み得る。一意的識別子が使用されるときに同一のコンテンツを複数回符号化すると、コンテンツの符号化バージョンの各々に対して異なる識別子に帰着する。但し、符号化されたビデオ・トラックの複製物は、それがコピーされた元のトラックの識別子を保持する。

表１に示されたエントリは、ＵＰｎＰフォーラムにより規定されたＵＰｎＰボキャブラリ（http://www.upnpforum.org参照）などの他のボキャブラリにより置換され得る。別の代替策は、ＭＰＥＧ−２１規格に向けた作業の一部として国際標準化機構により開発されたデジタルアイテム宣言言語（ＤＩＤＬ：Degital Item Declaration Language）またはDIDL-Liteボキャブラリである。以下は、UPnPボキャブラリにおける述部の例である。

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

全ての「meta data」に対する出典は、「_:auth42」である。「meta data」ステートメントは、「_:auth42」は「ワーナー・ブラザース」であることを示している。出典によれば、ファイルの品質と、そのファイルに関係付けられた「meta data」ステートメントとの両方の評価が可能とされる。

グラフ内へのノードは、命名されたリソース・ノードを介して接続される。「meta data」のステートメントは、主部ノード、述部ノードおよび目的部ノードから成る。オプション的に、出典ノードは「meta data」ステートメントの一部としてのＤＬＧに対して接続され得る。

各ノードに対し、そのノードの機能性を更に説明する一定の特性が在る。可能なタイプは、ＡＮＳＩのＣプログラミング言語を用いて以下の如く表され得る。
/**Invalid Type*/
#define RDF_IDENTIFIER_TYPE_UNKNOWN 0x00
/** Resource URI rdf:about*/
#define RDF_IDENTIFIER_TYPE_RESOURCE 0x01
/**rdf:NodeId,_:file or generated N-Triples*/
#define RDF_IDENTIFIER_TYPE_ANONYMOUS 0x02
/** Predicate URI*/
#define RDF_IDENTIFIER_TYPE_PREDICATE 0x03
/**rdf:li, rdf:<n>*/
#define RDF_IDENTIFIER_TYPE_ORDINAL 0x04
/** Authority URI*/
#define RDF_IDENTIFIER_TYPE_AUTHORITY 0x05
/**UTF-8 formatted literal*/
#define RDF_IDENTIFIER_TYPE_LITERAL 0x06
/**Literal Integer**/
#define RDF_IDENTIFIER_TYPE_INT 0x07
/**Literal XML data*/
#define RDF_IDENTIFIER_TYPE_XML_LITERAL 0x08

「DXDT」チャンク内に含まれる「meta data」チャンクを表す（ＡＮＳＩのＣプログラミング言語で表される）データ構造の例は以下のようである。
typedef struct RDFDataStruct
｛
RDFHeader Header;
uint32_t numOfStatements;
RDFStatement statements[RDF_MAX_STATEMENTS];
｝ RDFData
「RDFData」チャンクは、「RDFHeader」チャンクと称されるチャンク、値「numOfStatements」、および、「RDFStatement」チャンクのリストを含む。

「RDFHeader」チャンクは、「meta data」がそのチャンク内でフォーマットされる様式に関する情報を含む。一実施例において「RDFHeader」チャンク内のデータは以下のように表され得る（ANSI Cで表される）。
typedef struct RDFHeaderStruct
｛
uint16_t versionMajor;
uint16_t versionMinor;
uint16_t versionFix;
uint16_t numOfSchemas;
RDFSchema schemas[RDF_MAX_SCIIEMAS];
｝ RDFHeader;

「RDFHeader」チャンクは、上位互換性を可能とするリソース記述フォーマットのバージョンを表す数「バージョン（version）」を含む。ヘッダは、「RDFHeader」チャンクの一部をも形成するリスト「スキーマ（Schema）」における「RDFSchema」チャンクの個数を表す第２の数「numOfSchemas」を含む。幾つかの実施例において「RDFSchema」チャンクは、複雑なリソースが更に効率的に表されるのを可能とすべく用いられる。一実施例において「RDFSchema」チャンクに含まれるデータは以下のように表され得る（ＡＮＳＩ Ｃで表される）。
typedef struct RDFSchemaStruct
｛
wchar_t* prefix;
wchar_t* uri;
｝ RDFSchema;

「RDFSchema」チャンクは、「接頭辞（prefix）」として識別される「dc」などの第１のテキスト文字列と、「uri」として識別される「http://purl.org/dc/elements/1.1/」などの第２のテキスト文字列とを含む。「prefix」は、「uri」の代わりに「meta data」で使用され得る用語を定義する。「uri」は、特定の規格化ボキャブラリに準じ得るか、特定システムに対する特定ボキャブラリとされ得る汎用リソース識別子である。

「RDFData」チャンクの考察に戻る。「RDFHeader」チャンクに加えて「RDFData」チャンクは、値「numOfStatements」、および、「RDFStatement」チャンクのリスト「Statement」をも含んでいる。値「numOfStatements」は、情報を含むリスト「Statement」における「RDFStatement」チャンクの実際の個数を表す。一実施例において「RDFStatement」チャンクに含まれるデータは以下の如く表され得る（ＡＮＳＩ Ｃで表される）。
typedef struct RDFStatementStruct
｛
RDFSubject subject;
RDFPredicate predicate;
RDFObject object;
RDFAuthority authority;
｝ RDFStatement;

各「RDFStatement」チャンクは、マルチメディア・ファイルに関する「meta data」を含む。チャンク「subject」、「predicate」、「object」および「authority」は、上述の「meta data」の種々の構成要素を含むべく用いられる。

「subject」は、上述の「meta data」の主部部分を表す「RDFSubject」チャンクである。一実施例において「RDFSubject」チャンクに含まれたデータは、以下の如く表され得る（ANSI Cで表される）。
typedef struct RDFSubjectStruct
｛
uint16_t type;
wchar_t* value;
｝ RDFSubject;

上記「RDFSubject」チャンクは、データがリソースであるかまたは「meta data」の匿名ノードであることを表す値「type」と、「meta data」の主部を表すデータを含むユニコード・テキスト文字列とを含む。「RDFSchema」チャンクが定義されている実施例において値は、リソースに対する直接的リファレンスの代わりに、定義済み用語とされ得る。

「RDFStatement」チャンクにおける「predicate」は、「meta data」の述部部分を表す「RDFPredicate」チャンクである。一実施例において「RDFPredicate」チャンク内に含まれるデータは、以下の如く表され得る（ANSI Cで表される）。
｛
uint16_t type;
wchar_t* value;
｝ RDFPredicate;

上記の「RDFPredicate」チャンクは、データが述部ＵＲＩであるかまたは「meta data」の順序リスト・エントリであることを表す値「type」と、「meta data」の述部を表すデータを含むテキスト文字列「value」とを含む。「RDFSchema」チャンクが定義されている実施例において値は、リソースに対する直接的リファレンスの代わりに、定義済み用語とされ得る。

「RDFStatement」チャンクにおける「object」は、「meta data」の目的部部分を表す「RDFObject」チャンクである。一実施例において「RDFObject」チャンクに含まれたデータは、以下の如く表され得る（ANSI Cで表される）。
typedef struct RDFObjectStruct
｛
uint16_t type;
wchar_t* language;
wchar_t* dataTypeURI;
wchar_t* value;
｝ RDFObject;

上記の「RDFObject」チャンクは、データが、ＵＴＦ−８リテラル文字列、リテラル整数または「meta data」のリテラルＸＭＬデータであることを表す値「type」を含む。チャンクは、３個の値も含む。第１の値「language」は、「meta data」が表現される言語を表すべく用いられる（たとえば映画のタイトルは異なる言語に変更され得る）。幾つかの実施例においては、言語を識別すべく標準的な表現（インターネット・エンジニアリング・タスク・フォースにより指定された言語の識別に対するタグであるRFC3066など、http://www.ietf.org/rfc/rfc3066.txtを参照）が使用され得る。第２の値である「dataTypeURI」は、「value」フィールド内に含まれたデータのタイプが「type」フィールドにより明示的に表され得ないのであれば、そのデータのタイプを表すべく用いられる。dataTypeURIにより指定されたＵＲＩは、使用される特定形式のデータを記述すべく使用された一般的なＲＤＦ ＵＲＩボキャブラリを指し示す。ＵＲＩが表現され得る異なるフォーマットは、http://www.w3.org/TR/rdf-concepts/#section-Datatypesで記述される。一実施例において「value」は「ワイド文字（wide character）」である。他の実施例において「value」は、画像またはビデオシーケンスに対する単一ビットからの種々の形式のデータの内の任意のものとされ得る。「value」は、「meta data」の目的部部分を含む。

「RDFStatement」チャンクにおける「authority」は、「meta data」の出典部分を表す「RDFAuthority」チャンクである。一実施例において「RDFAuthority」チャンクに含まれるデータは以下の如く表され得る（ＡＮＳＩ Ｃで表される）。
typedef struct RDFAuthorityStruct
｛
uint16_t type;
wchar_t* value;
｝ RDFAuthority;

上記の「DFAuthority」データは、そのデータがリソースであるか「meta data」の匿名ノードであるかを表す値「type」を含む。「value」は、「meta data」に対する出典を表すデータを含む。「RDFSchema」チャンクが定義された実施例において、値はリソースに対する直接的リファレンスの代わりに定義済み用語とされ得る。

図２．３．には、本発明の実施例によるマルチメディア・ファイルの「DXDT」チャンクを記憶する概念的表現が示される。「DXDT」チャンク３８は、「RDFHeader（ＲＤＦヘッダ）」チャンク１１０、「numOfStatements（ステートメント数）」値１１２、および、RDFStatementチャンク１１４の表を含む。RDFHeaderチャンク１１０は、「バージョン（version）」値１１６、「numOfSchemas（スキーマ数）」値１１８、「スキーマ（Schema）」チャンク１２０の表を含む。各「ＲＤＦステートメント（RDFStatement）」チャンク１１４は、「ＲＤＦ主部（RDFSubject）」チャンク１２２、「ＲＤＦ述部（RDFPredicate）」チャンク１２４、「ＲＤＦ目的部（RDFObject）」チャンク１２６および「ＲＤＦ出展（RDFAuthority）」チャンク１２８を含む。「ＲＤＦ主部（RDFSubject）」チャンクは、「タイプ（type）」値１３０および「バリュー（value）」値１３２を含む。「ＲＤＦ述部（RDFPredicate）」チャンク１２４もまた、「タイプ（type）」値１３４および「バリュー（value）」値１３６を含む。「ＲＤＦ述部（RDFObject）」チャンク１２６は、「タイプ（type）」値１３８、（図においては「lang」として示された）「言語（language）」値１４０、（図においては「dataT」として示された）「ＵＲＩデータタイプ（dataTypeURI）」値１４２、および、「バリュー（value）」値１４４を含む。「ＲＤＦ出展（RDFAuthority）」チャンク１２８は、「タイプ（type）」値１４６および「バリュー（value）」値１４８を含む。図示された「DXDT」チャンクは、１つの「スキーマ（Schema）」チャンクおよび１つの「ＲＤＦステートメント（RDFStatement）」チャンクを含んで示されるが、当業者であれば、異なる個数の「スキーマ（Schema）」チャンクおよび「ＲＤＦステートメント（RDFStatement）」チャンクが「メタデータ」を記述するチャンクにおいて使用され得ることを容易に理解し得よう。

以下において論じられるように、本発明の実施例によるマルチメディア・ファイルは連続的に改変および更新され得る。予め「meta data」を決定し、ファイル自体、および（たとえばインターネットを介して）遠隔的にアクセスされる「meta data」に対して関係付けることは困難であり得る。典型的には、ファイルの内容を記述するために本発明の実施例によるマルチメディア・ファイル内に十分な「meta data」が含まれる。そのファイルをレビューするデバイスが、そのファイル内から参照された「meta data」を含む他のデバイスに対してネットワークを介してアクセスし得る場合、付加的情報が獲得され得る。

上述の「meta data」を表す方法は拡張可能であると共に、ファイルに対する必要性が経時的に変化するにつれ、そのファイル内に記憶される異なる「meta data」フィールドを付加および除去する能力を提供し得る。これに加え、「meta data」の表現は改訂版間で上位互換であり得る。

本発明の実施例に従い「meta data」が表される構造化様式は、デバイスが、マルチメディア・ファイルのコンテンツを良好に決定すべくそのマルチメディア・ファイルに対して問合せ（query）を行うことを可能にする。その場合の問合せは、マルチメディア・ファイルの内容を更新し、マルチメディア・ファイルに関する付加的な「meta data」を獲得し、そのファイルの内容に関するメニューを生成し、または、標準的フォーマットで表されたデータの自動処理を伴う他の任意の機能を実施するために使用され得る。これに加え、「meta data」の解析可能な各エレメントの長さを定義すると、家電機器などの様にメモリの量が限られたデバイスが「meta data」にアクセスする容易さが高められ得る。

他の実施例において「meta data」は、各「meta data」断片に対する個々のチャンクを用いて表される。本発明による幾つかの「DXDT」チャンクとしては、上述の如く符号化された「meta data」を含む２進チャンク、および、上述の如くまたは別のフォーマットのいずれかでフォーマットされた個別の「meta data」断片を含む付加的チャンクが含まれる。「DXDT」チャンクに２進「meta data」が含まれる実施例において、その２進「meta data」は６４ビットの符号化ASCIIを用いて表され得る。他の実施例においては、他の２進表現が使用され得る。

図２．３．１．には、本発明による「DXDT」チャンクに含まれ得る個別チャンクの例が示される。「メタデータ」は、「PixelAspectRatioMetaData（ピクセル縦横比メタデータ）」チャンク１５２ａ、「EncoderURIMetaData（エンコードＵＲＩメタデータ）」チャンク１５２ｂ、「CodecSettingsMetaData（コーデック設定メタデータ）」チャンク１５２ｃ、「FrameTypeMetaData（フレームタイプメタデータ）」チャンク１５２ｄ、「VideoResolutionMetaData（ビデオ解像度メタデータ）」チャンク１５２ｅ、「PublisherMetaData（出版社メタデータ）」チャンク１５２ｆ、「CreatorMetaData（創作者メタデータ）」チャンク１５２ｇ、「GenreMetaData（ジャンルメタデータ）」チャンク１５２ｈ、「CreatorToolMetaData（創作者ツールメタデータ）」チャンク１５２ｉ、「RightsMetaData（権利メタデータ）」チャンク１５２ｊ、「RunTimeMetaData（ランタイムメタデータ）」チャンク１５２ｋ、「QuantizerMetaData（量子化器メタデータ）」チャンク１５２ｌ、「CodecInfoMetaData（コーデック情報メタデータ）」チャンク１５２ｍ、「EncoderNameMetaData（エンコーダ名称メタデータ）」チャンク１５２ｎ、「FrameRateMetaData（フレーム速度メタデータ）」チャンク１５２ｏ、「InputSourceMetaData（入力ソースメタデータ）」チャンク１５２ｐ、「FileldMetaData（フィールドメタデータ）」チャンク１５２ｑ、「TypeMetaData（タイプメタデータ）」チャンク１５２ｒ、「TitleMetaData（タイトルメタデータ）」チャンク１５２ｓおよび／または「CertLevelMetaData（認証レベルメタデータ）」チャンク１５２ｔを含み得る「メタデータ」チャンク１５０を含む。

「PixelAspectRatioMetaData」チャンク１５２ａは、符号化されたビデオのピクセル・アスペクト比に関する情報を含む。「EncoderURIMetaData」チャンク１５２ｂは、エンコーダに関する情報を含む。「CodecSettingsMetaData」チャンク１５２ｃは、ビデオを符号化するために使用されたコーデックの設定に関する情報を含む。「FrameTypeMetaData」チャンク１５２ｄは、ビデオ・フレームに関する情報を含む。「VideoResolutionMetaData」チャンク１５２ｅは、符号化されたビデオのビデオ解像度に関する情報を含む。「PublisherMetaData」チャンク１５２ｆは、メディアを発行した人物または組織に関する情報を含む。「CreatorMetaData」チャンク１５２ｇは、内容の創作者に関する情報を含む。「GenreMetaData」チャンク１５２ｈは、メディアのジャンルに関する情報を含む。「CreatorToolMetaData」チャンク１５２ｉは、ファイルを生成すべく使用されたツールに関する情報を含む。「RightsMetaData」チャンク１５２ｊは、ＤＲＭに関する情報を含む。「RunTimeMetaData」チャンク１５２ｋは、メディアの実行時間に関する情報を含む。「QuantizerMetaData」チャンク１５２ｌは、ビデオを符号化すべく使用された量子化器に関する情報を含む。「CodecInfoMetaData」チャンク１５２ｍは、コーデックに関する情報を含む。「EncoderNameMetaData」チャンク152nは、エンコーダの名称に関する情報を含む。「FrameRateMetaData」チャンク１５２ｏは、メディアのフレーム速度に関する情報を含む。「InputSourceMetaData」チャンク１５２ｐは、入力ソースに関する情報を含む。「FileldMetaData」チャンク１５２ｑは、ファイルに対する一意的識別子を含む。「TypeMetaData」チャンク１５２ｒは、マルチメディア・ファイルの形式に関する情報を含む。「TitleMetaData」チャンク１５２ｓはメディアのタイトルを含み、かつ、「CertLevelMetaData」チャンク１５２ｔはメディアの認証レベルに関する情報を含む。他の実施例においては、付加的な「メタデータ」を含む付加的チャンクが含まれ得る。幾つかの実施例において「メタデータ」チャンク内には、上述された如く２進フォーマットで「メタデータ」を含むチャンクが含まれ得る。一実施例において２進「メタデータ」のチャンクは、64ビットASCIIとして符号化される。

２．５．「DMNU」チャンク
図２．０．および図２．０．１．を参照すると、第１「DMNU」チャンク４０（４０’）および第２「DMNU」チャンク４６（４６’）が示される。図２．０．において第２「DMNU」チャンク４６は、マルチメディア・ファイル３０の一部を形成する。図２．０．１．に示された実施例において「DMNU」チャンク４６’は、別個のRIFFチャンク内に含まれる。両方の場合、第１および第２の「DMNU」チャンクは、索行可能メニューを表示すべく使用され得るデータを含む。一実施例において第１「DMNU」チャンク４０（４０’）は、拡張バックグラウンド動画などの進歩的特徴を含まない簡素なメニューを生成すべく使用され得るデータを含む。これに加えて第２「DMNU」チャンク４６（４６’）は、拡張動画式バックグラウンドなどの進歩的特徴を含む更に複雑なメニューを生成すべく使用され得るデータを含む。

幾つかの実施例において、単純なメニューおよび複雑なメニューを配備すると、デバイスは自身が表示を意図するメニューを選択することが可能とされ得る。「movi」リスト・チャンク４２の前に、その２つのメニューの内の小寸の方を載置すると、メニューを表示し得ない本発明の実施例によるデバイスは、表示され得ない情報を迅速に飛び越し得る。

他の実施例において、単一メニューを生成するために必要なデータは、第１および第２「DMNU」チャンク間に分割される。代替的に「DMNU」チャンクは、単一群のメニューまたは複数群のメニューに対するデータを含む「movi」チャンクの前の単一チャンクとされ得る。他の実施例において「DMNU」チャンクは、マルチメディア・ファイルの全体における他の箇所に配置された単一または複数のチャンクとされ得る。

本発明による幾つかのマルチメディア・ファイルにおいて第１「DMNU」チャンク４０（４０’）は、第２「DMNU」チャンク４６（４６’）における「richer」メニューに基づき自動的に生成され得る。メニューの自動生成は、以下においてより詳細に論じられる。

図２．４．には、本発明の実施例による「DMNU」チャンクの構造が示される。「DMNU」チャンク１５８は、メニュー・チャンク１６０および「MRIF」チャンク１６２を含むリスト・チャンクである。メニュー・チャンクは、各メニューを構築して索行するために必要な情報を含む。「MRIF」チャンクは、各メニューに対してサブタイトル、バックグラウンド・ビデオおよびバックグラウンド・オーディオを提供すべく使用され得るメディア情報を含む。幾つかの実施例において「DMNU」チャンクは、各メニューを幾つかの異なる言語で表示させ得るメニュー情報を含む。

一実施例において「WowMenu」チャンク１６０は、図２．５．に概念的に示されたメニュー・チャンク・オブジェクトの階層を含む。その階層の頂部には、「ワウメニューマネージャ（WowMenuManager）」チャンク１７０が在る。その「WowMenuManager」チャンクは、１つ以上の「言語メニュー（LanguageMenus）」チャンク１７２および１つの「メディア（Media）」チャンク１７４を含み得る。

「LanguageMenus」チャンク１７２を使用すると、「DMNU」チャンク１５８は異なる言語でメニュー情報を含み得る。各「LanguageMenus」チャンク１７２、指定された言語で完全なメニュー群を生成すべく使用される情報を含む。ゆえに「LanguageMenus」チャンクはその「LanguageMenus」チャンクに関係付けられた情報の言語を特定する識別子を含む。その「LanguageMenus」チャンクはまた、「ワウメニュー（WowMenu）」チャンク１７５のリストも含む。

各「WowMenu」チャンク１７５は、特定メニューに対して画面上に表示されるべき情報の全てを含む。この情報は、バックグラウンド・ビデオおよびオーディオを含み得る。情報はまた、他のメニューにアクセスすべく、または、メニューを抜け出してマルチメディア・ファイルの一部の表示を開始すべく使用され得るボタン動作に関するデータも含み得る。一実施例において「WowMenu」チャンク１７５は、メディアに対するリファレンスのリストを含む。これらのリファレンスは「Media」チャンク１７４内に含まれた情報を参照するが、これは以下において更に論じられる。メディアに対するリファレンスは、メニューに対するバックグラウンド・ビデオおよびバックグラウンド・オーディオを定義し得る。「WowMenu」チャンク１７５はまた、メニューが最初にアクセスされたときに特定ボタンを強調するために使用され得るオーバレイも定義する。

これに加えて各「WowMenu」チャンク１７５は、所定数の「ボタンメニュー（ButtonMenu）」チャンク１７６を含む。各「ButtonMenu」チャンクは、画面上ボタンのプロパティを定義する。「ButtonMenu」チャンクは、ユーザによりボタンが強調されたときに使用するオーバレイ、ボタンの名称、および、メニューを通してナビゲートしているユーザにより実施された種々の動作に応じて行うべきことなどの事項を記述し得る。動作に対する応答は、「アクション（Action）」チャンク１７８を参照することで定義される。たとえばボタンを選択するなどの単一動作は、幾つかの「アクション」チャンクに対するアクセスに帰着し得る。画面上ポインタが制約のない様式でディスプレイ上を動き回ることを可能とするマウスなどのデバイスを用いてユーザがメニューと対話し得るという実施例において、ボタンの画面上箇所は「MenuRectangle（メニュー矩形）」チャンク１８０を用いて定義され得る。ボタンの画面上箇所を認識すると、システムは、自由範囲のデバイスを用いるときにユーザはボタンを選択しているか否かを決定し得る。

各「Action」チャンクは、「プレイアクション（PlayAction）」チャンク１８２、「MenuTransitionAction（メニュー遷移アクション）」チャンク１８４、「ReturnToPlayAction（プレイに戻るアクション）」チャンク１８６、「AudioSelectAction（オーディオ選択アクション）」チャンク１８８、「SubtitleSelectAction（サブタイトル選択アクション）」チャンク１９０および「ButtonTransitionAction（ボタン遷移アクション）」チャンク１９１などの多数の異なる種々の動作関連チャンクの内の１つ以上を特定する。「プレイアクション」チャンク１８２は、マルチメディア・ファイル内におけるビデオ、オーディオおよびサブタイトルトラックの各々の一部を特定する。「プレイアクション」チャンクは、「MediaTrack」チャンク（以下の考察を参照）に対するリファレンスを用いてビデオ・トラックの一部を参照する。「プレイアクション」チャンクは、「SubtitleTrack（サブタイトルトラック）」チャンク１９２および「AudioTrack（オーディオトラック）」１９４チャンクを用いてオーディオおよびサブタイトルトラックを特定する。「SubtitleTrack」および「AudioTrack」チャンクは両者ともに、「MediaTrack（メディアトラック）」チャンク１９８に対するリファレンスを含む。「プレイアクション」チャンクが本発明の実施例による動作の基礎を形成するとき、選択されたオーディオおよびサブタイトルトラックは、既定として最初に設定された変数の値であって可能的にはその後にメニューに対するユーザの対話により改変される変数の値により決定される。

各「MenuTransitionAction」チャンク１８４は、「WowMenu」チャンク１７５に対するリファレンスを含む。このリファレンスは、別のメニューへと遷移してそれを表示するための情報を獲得すべく使用され得る。

各「ReturnToPlayAction」チャンク１８６は、ユーザがメニューを呼び出す前にアクセスされていたマルチメディア・ファイルの部分へとプレーヤが戻るのを可能とする情報を含む。

各「AudioSelectAction」チャンク１８８は、特定のオーディオ・トラックを選択すべく使用され得る情報を含む。一実施例においてオーディオ・トラックは、本発明の実施例によるマルチメディア・ファイル内に含まれたオーディオ・トラックから選択される。他の実施例においてオーディオ・トラックは、外部的に参照されるファイル内に配置され得る。

各「SubtitleSelectAction」チャンク１９０は、特定のサブタイトルトラックを選択すべく使用され得る情報を含む。一実施例においてサブタイトルトラックは、本発明の実施例によるマルチメディア・ファイル内に含まれたサブタイトルから選択される。他の実施例においてサブタイトルトラックは、外部的に参照されるファイル内に配置され得る。

各「ButtonTransitionAction」チャンク１９１は、同一メニューにおける別のボタンへと遷移するために使用され得る情報を含む。これは、ボタンに関係付けられた他の動作が実施されてから実施される。

「メディア（Media）」チャンク１７４は、所定数の「MediaSource」チャンク１６６および「MediaTrack」チャンク１９８を含む。「メディア」チャンクは、機能およびメニュー・システムにより使用されるマルチメディア・トラックの全て（たとえばオーディオ、ビデオ、サブタイトルなど）を定義する。各「MediaSource」チャンク１９６は、本発明の実施例によるマルチメディア・ファイル内のRIFFチャンクであって、それが更に複数のRIFFチャンクを含み得るというRIFFチャンクを特定する。各「MediaTrack」チャンク１９８は、「MediaSource」チャンクにより特定されたRIFFチャンク内のマルチメディア・トラックの一部を特定する。

「MRIF」チャンク１６２は本質的に、RIFFフォーマットに従うそれ自体のスモール・マルチメディア・ファイルである。「MRIF」チャンクは、メニューに対するバックグラウンド・オーディオおよびビデオおよびオーバレイを提供するために使用され得るオーディオ、ビデオおよびサブタイトルトラックを含む。「MRIF」チャンクは、強調されたメニュー・ボタンを表すオーバレイとして使用されるべきビデオも含む。必要とされるメニュー・データが少ない実施例においてバックグラウンド・ビデオは、静止フレーム（ＡＶＩフォーマットの変形例）または同一フレームのスモール・シーケンスとされ得る。他の実施例においては、バックグラウンド・ビデオを提供すべく更に精巧なシーケンスのビデオが使用され得る。

上述の如く、「WowMenu」チャンク１７５の一部および「WowMenu」チャンク自体を形成する種々のチャンクは、実際のメディア・トラックに対するリファレンスを含む。これらのリファレンスの各々は典型的に、RIFFチャンクの「hdrl」リスト・チャンク内に定義されたメディア・トラックに対するものである。

図２．６．には、本発明による「DMNU」チャンクを生成すべく使用され得る他のチャンクが示される。「DMNU」チャンクは「WowMenuManager」チャンク１７０’を含む。「WowMenuManager」チャンク１７０’は、少なくとも一個の「LanguageMenus」チャンク１７２’、少なくとも一個の「メディア」チャンク１７４’、および、少なくとも一個の「TranslationTable」チャンク２００を含み得る。

「LanguageMenus」チャンク１７２’の内容は、図２．５．に示された「LanguageMenus」チャンク１７２のそれと非常に似ている。主な相違点は、「プレイアクション」チャンク１８２’が「SubtitleTrack」チャンク１９２および「AudioTrack」チャンク１９４を含まないことである。

「Media」チャンク１７４’は、図２．５．に示された「Media」チャンク１７４と相当に異なる。「Media」チャンク１７４’は、少なくとも一個の「タイトル（Title）」チャンク２０２および少なくとも一個の「メニュートラック（MenuTracks）」チャンク２０４を含む。「タイトル」チャンクは、マルチメディア・ファイル内のタイトルを参照する。上述された如く本発明の実施例によるマルチメディア・ファイルは１つ以上のタイトル（たとえば、テレビ・シリーズにおける複数のエピソード、完全長の番組の関連シリーズ、または、単に異なる番組の選択）を含み得る。「メニュートラック」チャンク２０４は、メニュー表示、および、その表示に付随するオーディオ・サウンドトラックおよびサブタイトルを生成すべく使用されるメディア情報に関する情報を含む。

「タイトル」チャンクは、少なくとも一個の「チャプター（Chapter）」チャンク２０６を含み得る。「チャプター」チャンク２０６は、特定タイトル内のシーンを参照する。「チャプター」チャンク２０６は、その「チャプター」チャンクにより表されるシーンに対応するビデオ・トラック、各オーディオ・トラックおよび各サブタイトルトラックの部分に対するリファレンスを含む。一実施例においてリファレンスは、図２．５．に関して上述されたのと同様の「メディアソース（MediaSource）」チャンク１９６’および「メディアトラック（MediaTrack）」チャンク１９８’を用いて実現される。幾つかの実施例において「メディアトラック」チャンクはビデオ・トラックの適切な部分を参照し、かつ、所定数の付加的な「メディアトラック」チャンクは各々、オーディオ・トラックまたはサブタイトルトラックの内の１つのトラックを参照する。一実施例において、特定のビデオ・トラックに対応するオーディオ・トラックおよびサブタイトルトラックの全ては、別個の「メディアトラック」チャンクを用いて参照される。

上述された如く「メディアトラック」チャンク２０４は、メニューのオーディオ、ビデオおよびオーバレイ・メディアを生成すべく使用されるメディアに対するリファレンスを含む。一実施例においてメディア情報に対する参照は、「メディアトラック」チャンク内に含まれた「メディアソース」チャンク１９６’および「メディアトラック」チャンク１９８’を用いて為される。一実施例において「メディアソース」チャンク１９６’および「MediaTrack」チャンク１９８’は、図２．５．に関して記述された様式で実現される。

「翻訳テーブル（TranslationTable）」チャンク２００は、各タイトルおよびチャプタを種々の言語で記述するテキスト文字列を含むべく使用され得る。一実施例において「翻訳テーブル」チャンク２００は、少なくとも一個の「翻訳検索（TranslationLookup）」チャンク２０８を含む。各「翻訳検索」チャンク２０８に対しては「タイトル」チャンク２０２、「チャプター」チャンク２０６または「メディアトラック」チャンク１９６’が関係付けられ、かつ、その「TranslationLookup」チャンクは所定数の「翻訳（Translation）」チャンク２１０を含んでいる。「TranslationLookup」チャンクにおける「Translation」チャンクの各々は、「翻訳検索」チャンクに関係付けられたチャンクを、「翻訳」チャンクにより表された言語で記述するテキスト文字列を含む。

図２．６．１．には、「DMNU」チャンク内に含まれた種々のチャンク間の関係を概念的に示す図が示される。この図は実線矢印を用いて、１つのチャンクによる別のチャンクの包含関係を示している。矢印が示す方向は、矢印が出ているチャンクにより含まれるチャンクを表している。ひとつのチャンクによる別のチャンクに対する参照は点線により表され、その場合に参照されたチャンクは点線矢印により表される。

２．６．「junk」チャンク
「ジャンク（junk）」チャンク４１は、本発明の実施例によるマルチメディア・ファイルに含まれ得る選択的チャンクである。「junk」チャンクの性質は、ＡＶＩファイル・フォーマットにおいて仕様が定められている。

２．７．「movi」リスト・チャンク
「movi」リスト・チャンク４２は、所定数の「データ（data）」チャンクを含む。「データ」チャンクが含み得る情報の例は、オーディオ、ビデオまたはサブタイトル・データである。一実施例において「movi」リスト・チャンクは、少なくとも一個のビデオ・トラック、複数のオーディオ・トラックおよび複数のサブタイトルトラックに対するデータを含む。

図２．７．には、１つのビデオ・トラックと、３つのオーディオ・トラックと、３つのサブタイトルトラックとを含むマルチメディア・ファイルの「movi」リスト・チャンク４２内における「データ」チャンクの交互配置様式が示される。便宜のために、ビデオを含む「データ」チャンクは「ビデオ」チャンクと称され、オーディオを含む「データ」チャンクは「オーディオ」チャンクと称され、かつ、サブタイトルを含む「データ」チャンクは「サブタイトル（subtitle）」チャンクと称される。図示された「movi」リスト・チャンク４２において、各「ビデオ」チャンク２６２は、オーディオ・トラックの各々からの「オーディオ」チャンク２６４により、次の「ビデオ」チャンクから分離されている。幾つかの実施例において夫々の「オーディオ」チャンクは、１つの「オーディオ」チャンクに追随する「ビデオ」チャンクに含まれたビデオの一部に対応するオーディオ・トラックの一部を含む。

隣接する「ビデオ」チャンク同士はまた、複数のサブタイトルトラックの内の１つのサブタイトルトラックからの１つ以上の「サブタイトル（subtitle）」チャンク２６６によっても分離され得る。一実施例において「サブタイトル」チャンク２６６は、サブタイトル、開始時間および停止時間を含む。幾つかの実施例において「サブタイトル」チャンクは、その「サブタイトル」チャンクに追随する「ビデオ」チャンクが、そのサブタイトルの開始時間にて行われるビデオの部分を含む如く、「movi」リスト・チャンクに交互配置される。他の実施例において、全ての「サブタイトル」および「オーディオ」チャンクの開始時間は、ビデオの同等の開始時間に先んじる。一実施例において「オーディオ」および「subtitle」チャンクは対応する「ビデオ」チャンクの５秒以内に載置され得ると共に、他の実施例において「オーディオ」および「サブタイトル」チャンクは、ファイル内のオーディオおよびビデオを表示し得るデバイスによりバッファされ得るビデオの量に関連する時間内に載置され得る。

一実施例において「データ」チャンクは、その「データ」チャンクが属するストリームを特定する「FOURCC」コードを含む。その「FOURCC」コードは、２数字ストリーム番号と、これに続くと共にチャンクにおける情報の形式を定義する２文字コードとから成る。（Raider）代替的な「FOURCC」コードは、チャンクにおける情報の形式を定義する２文字コードと、それに続く２数字ストリーム番号とから成る。２文字コードの例は、以下の表に示される。

一実施例において「ビデオ（video）」チャンク２６２および「オーディオ（audio）」チャンク２６４の構造は、AVIファイル・フォーマットに従う。他の実施例においては、メディアの性質を特定すると共に符号化メディアを含むチャンク用の他のフォーマットが使用され得る。

幾つかの実施例において「サブタイトル（subtitle）」チャンク２６６に含まれるデータは、以下の如く表される。
typedef struct_subtitlechunk｛
FOURCC fcc;
DWORD cb;
STR duration;
STR subtitle;
｝ SUBTITLECHUNK;

値「fcc」は、サブタイトルトラックと、そのサブタイトルトラックの性質とを表すFOURCCコードである（テキストまたはビットマップ・モード）。値「cb」は、構造のサイズを指定する。値「duration」は、サブタイトルの開始および終了時点における時間を指定する。一実施例においてそれは、hh:mm:ss-hh:mm:ss.xxxの形態とされ得る。hhは時間を、mmは分を、ssは秒を、かつ、xxxはミリ秒を表す。値「subtitle」は、テキスト・モードにおけるサブタイトルのユニコード・テキスト、または、ビットマップ・モードにおけるサブタイトルのビットマップ・イメージのいずれかを含む。本発明の幾つかの実施例は、サブタイトル情報を表す圧縮ビットマップ・イメージを用いる。一実施例において「subtitle」フィールドは、サブタイトルの幅、高さおよび画面上位置に関する情報を含む。これに加えて「subtitle」フィールドはまた、ビットマップの色情報および実際のピクセルも含み得る。幾つかの実施例においては、ビットマップを表すために必要なピクセル情報の量を減少するために、ランレングス・コーディングが用いられる。

本発明の実施例によるマルチメディア・ファイルは、デジタル著作権管理を包含し得る。この情報は、ビデオ・オンデマンド・アプリケーションにおいて使用され得る。デジタル著作権管理により保護されたマルチメディア・ファイルは、特定の再生権利が許可されたプレーヤ上でのみ正しく再生され得る。一実施例において、トラックがデジタル著作権管理により保護されているという事実は、「hdrl」リスト・チャンクにおけるトラックに関する情報において表され得る（上記の記述を参照）。デジタル著作権管理により保護されたトラックを含む本発明の実施例によるマルチメディア・ファイルは、「movi」リスト・チャンク内にデジタル著作権管理に関する情報も含み得る。

図２．８．には、１つのビデオ・トラックと、複数のオーディオ・トラックと、少なくとも一つのサブタイトルトラックと、デジタル著作権管理を有効化する情報とを含む本発明の実施例によるマルチメディア・ファイルの「movi」リスト・チャンクが示される。「movi」リスト・チャンク４２’は図２．７．に示された「movi」リスト・チャンクと類似するが、各「ビデオ」チャンク２６２’に先立ち「DRM」チャンク２７０が付加されている。「DRM」チャンク２７０は、FOURCCコード「nndd」により特定され得るデジタル著作権管理情報を含む「data」チャンクである。最初の２個の文字「nn」はトラック番号を参照し、かつ、第２の２個の文字は、そのチャンクがデジタル著作権管理情報を含むことを意味する「dd」である。一実施例において「DRM」チャンク２７０は、その「DRM」チャンクに追随する「ビデオ」チャンク２６２’に対するデジタル著作権管理情報を提供する。デジタル著作権管理により保護されたビデオ・トラックを再生しようとするデバイスは、「DRM」チャンクにおける情報を使用して、「ビデオ」チャンクにおけるビデオ情報を復号化する。典型的に、「ビデオ」チャンクの前に「DRM」チャンクが無ければ、その「ビデオ」チャンクは非保護であることが意味されると解釈される。

本発明の実施例による暗号化システムにおいて、ビデオ・チャンクは部分的にのみ暗号化される。部分的暗号化が使用される場合、「DRM」チャンクは、「ビデオ」チャンクの暗号化された部分に対するリファレンスと、その暗号化部分を復号化するために使用され得るキーに対するリファレンスとを含む。復号化キーは、「strd」チャンク（の記述を参照）の一部である「DRM」ヘッダ内に配置され得る。復号化キーは、スクランブルが掛けられると共に、マスタ・キーにより暗号化される。「DRM」ヘッダは、マスタ・キーを特定する情報も含む。

図２．９．には、「DRM」チャンク内の情報の概念的表現が示される。「DRM」チャンク270は、「フレーム（frame）」値２８０、「ステータス（status）」値２８２、「オフセット（offset）」値２８４、「数（number）」値２８６および「キー（key）」値２８８を含み得る。「フレーム（frame）」値は、ビデオの暗号化フレームを参照すべく使用され得る。「ステータス（status）」値はフレームが暗号化されているか否かを表すべく使用され得ると共に、「オフセット（offset）」値２８４は、フレーム内の暗号化ブロックの開始部分を指し示し、「数（number）」値２８６はブロックにおける暗号化バイトの個数を表す。「キー（key）」値２８８は、ブロックを復号化すべく使用され得る復号化キーを参照する。

２．８．「idxl」チャンク
「idxl」チャンク４４は、「movi」リスト・チャンク４２内の「data」チャンクをインデックス付けすべく使用され得る選択的チャンクである。一実施例において「idxl」チャンクは、ＡＶＩフォーマットにおいて指定された如く実現され得る。他の実施例において「idxl」チャンクは、「movi」リスト・チャンク内の「data」チャンクの各々のファイル内の箇所を参照するデータ構造を用いて実現され得る。幾つかの実施例において「idxl」チャンクは、データのトラック番号とデータの形式とにより、各「data」チャンクを識別する。上記で言及されたＦＯＵＲＣＣコードは、この目的のために使用され得る。

３．マルチメディア・ファイルの符号化方法
本発明の実施例は、種々の様式でマルチメディア・ファイルを生成すべく使用され得る。ある場合において本発明の実施例によるシステムは、別個のビデオ・トラック、オーディオ・トラックおよびサブタイトルトラックを含むファイルからマルチメディア・ファイルを生成し得る。かかる場合、メニュー情報および「メタデータ」などの他の情報は、オーサリングされてファイル内へと挿入され得る。

本発明の実施例による他のシステムは、デジタル・ビデオ・ディスク（“ＤＶＤ”）上の種々のファイルから情報を抽出すべく、かつ、本発明の実施例による単一のマルチメディア・ファイルをオーサリングすべく使用され得る。ＤＶＤが情報の最初の供給源である場合に本発明の実施例によるシステムは、相当に圧縮すべくコーデックを使用し得ると共に、新たに生成されたマルチメディア・ファイルにおけるビデオ・チャンクに対してオーディオ・チャンクが対応する様にオーディオを再チャンキングし得る。これに加え、マルチメディア・ファイルに含まれるメニュー情報を生成すべく、ＤＶＤメニュー・システムにおけるメニュー情報が解析して使用され得る。

他の実施例は、本発明の実施例による既存のマルチメディア・ファイルに対して付加的なコンテンツを追加することにより、新たなマルチメディア・ファイルを生成し得る。付加的コンテンツの追加の例は、注釈（たとえばディレクタのコメント、バケーション・ビデオに対して事後作成されたナレーションなど）を含むオーディオ・トラックなどの付加的なオーディオ・トラックをファイルに追加することである。マルチメディア・ファイル内へと交互配置された付加的オーディオ・トラック情報には、新たなオーディオ・トラックの再生を可能とするそのマルチメディア・ファイル内のメニュー情報の改変が付属し得る。

３．１．記憶されたデータ・トラックを用いる生成方法
図３．０．には、マルチメディア・ファイルを生成する本発明の実施例によるシステムが示される。システム３５０の主要構成要素は、インタリーバ３５２である。そのインタリーバは、情報のチャンクを受信してそれらを交互配置することで、本発明の実施例によるマルチメディア・ファイルを上述のフォーマットで生成する。インタリーバはまた、メタデータ・マネージャ３５４から「メタデータ」に関する情報も受信する。インタリーバは、本発明の実施例によるマルチメディア・ファイルを記憶デバイス３５６に対して出力する。

典型的に、インタリーバに対して提供されたチャンクは記憶デバイスに記憶される。幾つかの実施例においてチャンクの全ては、同一の記憶デバイスに記憶される。他の実施例においてチャンクは、種々の記憶デバイスからインタリーバに対して提供され得るか、または、リアルタイムで生成されてインタリーバに対して提供され得る。

図３．０．に示された実施例においては、「DMNU」チャンク３５８および「DXDT」チャンク３６０がすでに生成されて記憶デバイスに記憶されている。記憶デバイスにはビデオ・ソース３６２が記憶され、そのビデオ・ソースはビデオ・デコーダ３６４を用いて復号化されてからビデオ・エンコーダ３６６を用いて符号化されて「ビデオ」チャンクが生成される。記憶デバイスにはオーディオ・ソース３６８も記憶される。オーディオ・チャンクは、オーディオ・デコーダ３７０を用いてオーディオ・ソースを復号化してから、復号化されたオーディオをオーディオ・エンコーダ３７２で符号化することにより生成される。「サブタイトル（subtitle）」チャンクは、記憶デバイスに記憶されたテキスト・サブタイトル３７４から生成される。サブタイトルは、所定数のサブタイトル・フォーマットの内の任意のフォーマットを生のビットマップ・フォーマットへと変換する第１トランスコーダ３７６に対して提供される。一実施例において、記憶されたサブタイトル・フォーマットはSRT、SUBまたはSSAなどのフォーマットである。これに加えてビットマップ・フォーマットは、色パレート（color palate）ルックアップ・テーブルを含む４ビットのビットマップである。色パレート・ルックアップ・テーブルは、１６種の可能な４ビット・カラー・コードの各々に対する２４ビットのカラー深度識別を含む。単一のマルチメディア・ファイルは、１つより多い色パレート・ルックアップ・テーブルを含み得る（上記の表２における「ｐｃ」パレートFOURCCコードを参照）。ゆえに４ビットのビットマップによれば各メニューは、1,600万色のパレートから取り出された１６個の異なる同時的な色を有し得る。代替実施例においては、ピクセル毎に異なるビット数および異なるカラー深度が用いられる。第１トランスコーダ３７６の出力は、ビットマップを圧縮する第２トランスコーダ３７８へと提供される。一実施例においては、ビットマップを圧縮するためにランレングス・コーディングが用いられる。他の実施例においては、他の適切な圧縮フォーマットが用いられる。

一実施例において、種々のエンコーダ、デコーダおよびトランスコーダ間のインタフェースは、Microsoft社により仕様を定められたDirectShow規格に準じる。他の実施例において、符号化、復号化およびトランスコードを実施すべく使用されるソフトウェアは、斯かる規格に従う必要はない。

図示実施例においては、各メディア・ソースに対して別個の処理構成要素が示される。他の実施例においては、リソースが共有され得る。たとえば単一のオーディオ・デコーダおよびオーディオ・エンコーダは、全てのソースからのオーディオ・チャンクを生成すべく使用され得る。典型的には、システム全体が、ソフトウェアを用いてコンピュータ上に実現されると共に、ハードディスク・ドライブなどの記憶デバイスに対して接続され得る。

上述の様式でインタリーバを利用するために、本発明の実施例による「DMNU」チャンク、「DXDT」チャンク、「ビデオ（video）」チャンク、「オーディオ（audio）」チャンクおよび「サブタイトル（subtitle）」チャンクは、生成されてインタリーバに対して提供されねばならない。本発明の実施例によるマルチメディア・ファイルにおける種々のチャンクの各々を生成するプロセスは、以下においてより詳細に論じられる。

３．２．「DXDT」チャンクの生成方法
「DXDT」チャンクは、多数の様式の内の任意の様式で生成され得る。一実施例において「メタデータ」はグラフィカル・ユーザ・インタフェースを介してデータ構造内へと入力されてから、「DXDT」チャンクへと解析される。一実施例において「メタデータ」は、一連の主部、述部、目的部および出典ステートメントとして表現される。別実施例において「メタデータ」ステートメントは、種々のフォーマットの内の任意のフォーマットで表現される。幾つかの実施例において各「メタデータ」ステートメントは、別個のチャンクへと解析される。他の実施例においては、（主部、述部、目的部および出典表現などの）第１フォーマットの幾つかの「メタデータ」ステートメントが第１チャンクへと構文解析され、かつ、他のフォーマットの他の「メタデータ」ステートメントは別個のチャンクへと構文解析される。一実施例において「メタデータ」ステートメントは、ＸＭＬコンフィグファイル（XML configuration file）に書き込まれ、そのＸＭＬコンフィグファイルが解析されて「DXDT」チャンク内のチャンクが生成される。

図３．１．には、ＸＭＬコンフィグファイル内に含まれた一連の「メタデータ」ステートメントから「DXDT」チャンクを生成するシステムの実施例が示される。システム３８０は、パーサ（parser）３８４に対して提供され得るＸＭＬコンフィグファイル３８２を含む。ＸＭＬコンフィグファイルは、XMLとして符号化された「メタデータ」を含む。パーサはXMLを解析し、かつ、そのパーサは、「メタデータ」ステートメントを、の「メタデータ」チャンク・フォーマットの内の任意のフォーマットに従い「DXDT」チャンクに対して書き込まれるチャンクへと変換することにより、「DXDT」チャンク３８６を生成する。

３．３．「DMNU」チャンクの生成方法
図３．２．には、本発明の実施例による「DMNU」チャンクを生成するために使用され得るシステムが示される。メニュー・チャンク生成システム４２０は、入力として、メディア・モデル４２２およびメディア情報を必要とする。メディア情報は、ビデオ・ソース４２４、オーディオ・ソース４２６およびオーバレイ・ソース４２８の形態を取り得る。

メニュー・チャンク生成システムに対する入力を用いる「DMNU」チャンクの生成は、多数の中間ファイルの生成を伴う。メディア・モデル４２２はＸＭＬコンフィグファイル４３０を生成するために使用され、かつ、メディア情報は所定数のＡＶＩファイル４３２を生成するために使用される。ＸＭＬコンフィグファイルは、モデル・トランスコーダ４３４により生成される。ＡＶＩファイル４３２は、インタリーバ４３６を用いてビデオ、オーディオおよびオーバレイ情報を交互配置することで生成される。ビデオ情報は、ビデオ・デコーダ４３８およびビデオ・エンコーダ４４０を用いてビデオ・ソース４２４を復号化し、以下において論じられる様式でそれを再コード化することで求められる。オーディオ情報は、オーディオ・デコーダ４４２およびオーディオ・エンコーダ４４４を用いてオーディオを復号化して、以下に記述される様式でそれを符号化することで求められる。オーバレイ情報は、第１トランスコーダ４４６および第２トランスコーダ４４８を用いて生成される。第１トランスコーダ４４６はオーバレイを標準的ビットマップなどのグラフィック表現へと変換すると共に、第２トランスコーダは、そのグラフィック情報を受けて、それを、マルチメディア・ファイル内への包含に対して必要とされる如くフォーマットする。メニューを構築するために必要な情報を含むＸＭＬファイルおよびＡＶＩファイルが一旦生成されたなら、メニュージェネレータ４５０はその情報を使用して「DMNU」チャンク３５８’を生成し得る。

３．３．１．メニュー・モデル
一実施例においてメディア・モデルは、各メニューおよびそれらの下位構成要素の全てを表すオブジェクト指向モデルである。そのメディア・モデルはメニューを、言語選択により各メニューが体系化されるのを許容する階層構造へと体系化する。図３．３．には、本発明の実施例によるメディア・モデルが示される。メディア・モデル４６０は、多数の「LanguageMenus（言語メニュー）」オブジェクト（object）４６３、「Media（メディア）」オブジェクト４６４および「翻訳テーブル（TranslationTable）」オブジェクト４６５と関係付けられた最高レベルの「メディアマネージャ（MediaManager）」オブジェクト４６２を含む。「メニューマネージャ（Menu Manager）」は、既定のメニュー言語も含む。一実施例において既定言語は、ISO 639の２文字言語コードにより表され得る。

「言語メニュー（LanguageMenus）」オブジェクトは、種々のメニューに対する情報を言語選択により体系化する。所定の言語に対する「メニュー（menu）」オブジェクト４６６の全てには、その言語に対する「言語メニュー（LanguageMenus）」オブジェクト４６３が関係付けられる。各「メニュー」オブジェクトには、所定数の「ボタン（Button）」オブジェクト４６８が関係付けられると共に、「メニュー」オブジェクトは所定数の「メディアトラック（MediaTrack）」オブジェクト４８８を参照する。参照された「メディアトラック」オブジェクト４８８は、「メニュー」オブジェクト４６６に対するバックグラウンド・ビデオおよびバックグラウンド・オーディオを表している。

各「ボタン（Button）」オブジェクト４６８には、「アクション（Action）」オブジェクト４７０および「矩形（Rectangle）」オブジェクト４８４が関係付けられる。「ボタン（Button）」オブジェクト４６８はまた、そのボタンが表示上で強調されたときに使用されるべきオーバレイを表す「メディアトラック（MediaTrack）」オブジェクト４８８に対するリファレンスも含む。各「アクション（Action）」オブジェクト４７０に対しては、「メニュー遷移（MenuTransition）」オブジェクト４７２、「ButtonTransition（ボタン遷移）」オブジェクト４７４、「ReturnToPlay（プレイに戻る）」オブジェクト４７６、「SubtitleSelection（サブタイトル選択）」オブジェクト４７８、「AudioSelection（オーディオ選択）」オブジェクト４８０および「プレイアクション（PlayAction）」オブジェクト４８２を含み得る所定数のオブジェクトが関係付けられる。これらのオブジェクトの各々は、ユーザからの種々の入力に対するメニュー・システムの応答を定義する。「MenuTransition（メニュー遷移）」オブジェクトは、動作に応じて遷移されるべきメニューを表す「メニュー」オブジェクトに対するリファレンスを含む。「ButtonTransition（ボタン遷移）」オブジェクトは、動作に応じて強調されるべきボタンを表す。「ReturnToPlay（プレイに戻る）」によればプレーヤは番組の再生に戻り得る。「SubtitleSelection（サブタイトル選択）」および「AudioSelection（オーディオ選択）」オブジェクトは、（以下で論じられる）「タイトル（Title）」オブジェクト４８７に対するリファレンスを含む。「プレイアクション」オブジェクトは、（以下で論じられる）「チャプター（Chapter）」オブジェクト４９２に対するリファレンスを含む。「矩形（Rectangle）」オブジェクト４８４は、ボタンにより占有された画面の部分を表す。

「メディア（Media）」オブジェクト４６４は、メニュー・システムにおいて参照されたメディア情報を表す。「メディア（Media）」オブジェクトは、「メニュートラック（MenuTracks）」オブジェクト４８６と、それに関係付けられた所定数の「タイトル（Title）」オブジェクト４８７とを有する。「メニュートラック（MenuTracks）」オブジェクト４８６は、メニューを構築すべく使用されるメディア（すなわちバックグラウンド・オーディオ、バックグラウンド・ビデオおよびオーバレイ）を表す「メディアトラック（MediaTrack）」オブジェクト４８８を参照する。

「タイトル」オブジェクト４８７は、マルチメディア・プレゼンテーションを表すと共に、所定数の「チャプター」オブジェクト４９２と、それらに関係付けられた「メディアソース（MediaSource）」オブジェクト４９０とを有する。「タイトル」オブジェクトは、「翻訳検索（TranslationLookup）」オブジェクト４９４に対するリファレンスも含む。「チャプター」オブジェクトはマルチメディア・プレゼンテーションにおける一定箇所を表すと共に、それに関係付けられた所定数の「メディアトラック（MediaTrack）」オブジェクト４８８を有する。「チャプター」オブジェクトは、「TranslationLookup（翻訳検索）」オブジェクト４９４に対するリファレンスも含む。「チャプター」オブジェクトが関係付けられた各「メディアトラック」オブジェクトは、マルチメディア・プレゼンテーションのオーディオ、ビデオまたはサブタイトルトラックのいずれかにおける箇所を表すと共に、（以下で論じられる）「メディアソース（MediaSource）」オブジェクト４９０および「翻訳検索（TranslationLookup）」オブジェクト４９４を参照する。

「翻訳テーブル（TranslationTable）」オブジェクト４６５は、「タイトル（Title）」オブジェクト、「チャプター」オブジェクトおよび「メディアトラック（MediaTrack）」オブジェクトにより表されるマルチメディア・プレゼンテーションの種々の部分を記述する所定数のテキスト文字列をグループ化する。「翻訳テーブル（TranslationTable）」オブジェクト４６５は、それに対して関係付けられた所定数の「翻訳検索（TranslationLookup）」オブジェクト４９４を有する。各「翻訳検索」オブジェクトは、特定オブジェクトを表すと共に、それに関係付けられた所定数の「翻訳（Translation）」オブジェクト４９６を有する。その「翻訳オブジェクトは各々、「翻訳検索（TranslationLookup）」オブジェクトにより表されたオブジェクトを特定言語で記述するテキスト文字列を表す。

上述の種々のオブジェクトを生成すべく構成されたソフトウェアであってオブジェクト間の必要な関係付けおよび参照を確立するソフトウェアを用いて、メディア・オブジェクト・モデルが構築され得る。

３．３．２ＸＭＬファイルの生成方法
ＸＭＬコンフィグファイルは、各メニューおよびそれらの下位構成要素の全てを表すメニュー・モデルから生成される。ＸＭＬコンフィグファイルはまた、各メニューにより使用されるメディア・ファイルの全ても特定する。ＸＭＬは、オブジェクト・モデルをＸＭＬコードへと解析する適切なパーサ・アプリケーションを実現することで生成され得る。

他の実施例においてはビデオ編集アプリケーションがユーザに対してインタフェースを提供することで、メニュー・モデルを生成せずにＸＭＬコンフィグファイルの直接的生成が可能とされ得る。

ＤＶＤメニューなどの別のメニュー・システムがメニュー・モデルの基礎であるという実施例において、メニューはユーザにより切り詰められ、本発明の実施方法に従い生成されるマルチメディア・ファイルに含まれない内容に関するメニュー・オプションが排除され得る。一実施例においてこれは、メニュー・モデルからのオブジェクトの排除を可能とするグラフィカル・ユーザ・インタフェースを配備することで行われ得る。別実施例においてメニューの切り詰めは、ＸＭＬコンフィグファイルを編集し得るグラフィカル・ユーザ・インタフェースまたはテキスト・インタフェースを配備することにより達成され得る。

３．３．３．メディア情報
「DMNU」チャンクが生成されるとき、メニュージェネレータ４５０に対して提供されるメディア情報は、メニュー・モデル（上記の記述を参照）において特定されたボタンに対するバックグラウンド・ビデオ、バックグラウンド・オーディオおよびフォアグラウンド・オーバレイを提供するために必要なデータを含む。一実施例においては、カリフォルニア州、サンタクララのロキシオ社（Roxio, Inc.）により配給されるVideoWaveなどのビデオ編集アプリケーションが使用されることで、個別メニューの各々に対するビデオ、オーディオおよびボタン選択オーバレイを表すソース・メディア・トラックが提供される。

３．３．４．中間ＡＶＩファイルの生成方法
上記の如く、バックグラウンド・ビデオ、バックグラウンド・オーディオおよびフォアグラウンド・ボタン・オーバレイとして使用されるメディア・トラックは、１つ以上のメニューに対して単一のＡＶＩファイル内に記憶される。メニューＡＶＩファイル内にメディア・トラックを含むチャンクは、ビデオ、オーディオおよびボタン・オーバレイトラックを交互配置すべく設計されたソフトウェアを用いて生成され得る。「オーディオ」、「ビデオ」および「オーバーレイ」チャンク（すなわちオーバレイ情報を含む「サブタイトルチャンク）は、インタリーバを用いてＡＶＩフォーマット準拠ファイルへと交互配置される。

上述された如く、各メニューに対しては別個のＡＶＩファイルが生成され得る。他の実施例においては、バックグラウンド・オーディオ、バックグラウンド・ビデオおよびフォアグラウンド・オーバレイ情報を提供すべく使用されたメディア情報を含む他のファイル・フォーマットまたは単一ファイルが使用され得る。

３．３．５．ＸＭＬコンフィグファイルおよびＡＶＩファイルを結合する方法
一実施例においてコンピュータは、ＸＭＬコンフィグファイルからの情報を解析して（上述の）「WowMenu」チャンクを生成すべく構成される。これに加えてそのコンピュータは、各メニューに対するメディアを含むAVIファイルを用いて（上述の）「MRIF」チャンクを生成し得る。コンピュータは次に、「WowMenu」チャンクと「MRIF」チャンクにおけるメディア・チャンクとの間に必要なリファレンスを生成することにより「DMNU」チャンクの生成を完了し得る。幾つかの実施例において、メニュー情報は暗号化され得る。暗号化は、「MRIF」チャンクに含まれたメディア情報を、「ビデオ（video）」チャンクに関して以下に記述されるのと同様の様式で暗号化することで達成され得る。他の実施例においては、種々の代替的な暗号化技術が使用される。

３．３．６．オブジェクト・モデルからのメニューの自動生成
図３．３．に戻ると、フルメニューよりも少ない内容を含むメニューは、「メディア」オブジェクト４６４に関係付けられた「タイトル」オブジェクト４８７を単に検証することにより、メニュー・モデルから自動的に生成され得る。図３．３．１．には、本発明の実施例によるメニューを自動的に生成すべく使用されるオブジェクトが示される。単に、マルチメディア・プレゼンテーションの特定セクションの選択と、使用されるオーディオおよびサブタイトルトラックの選択とを可能とする単純なメニューに対するＸＭＬコンフィグファイルは、ソフトウェアにより生成され得る。

３．３．７．単一の設定ファイルを用いて「DXDT」および「DMNU」チャンクを生成する方法
本発明の幾つかの実施例によるシステムは、「メタデータ」およびメニュー情報の両方を含む単一のＸＭＬコンフィグファイルを生成し、かつ、そのＸＭＬファイルを用いて「DXDT」および「DMNU」チャンクを生成し得る。これらのシステムは、「メタデータ」情報およびメニュー・オブジェクト・モデルを用いてＸＭＬコンフィグファイルを導出する。他の実施例において設定ファイルは、ＸＭＬである必要はない。

３．４．「オーディオ」チャンクの生成方法
本発明の実施例によるマルチメディア・ファイルの「movi」リスト・チャンクにおける「オーディオ」チャンクは、本発明の実施方法に従い、オーディオ・ソースを復号化してから、そのソースを「オーディオ」チャンクへ符号化することにより生成され得る。一実施例において「オーディオ」チャンクは、ＭＰ３コーデックを用いて符号化され得る。

３．４．１．オーディオを再チャンキングする方法
オーディオ・ソースが、対応「ビデオ」チャンクのコンテンツに対応するオーディオ情報を含まないチャンクで提供されたとき、本発明の実施例はそのオーディオを再チャンクし得る。図３．４．には、オーディオを再チャンクするために使用され得る処理が示される。処理４８０は、「ビデオ」チャンクを識別するステップ（４８２）と、その「ビデオ」チャンクに付随するオーディオ情報を識別するステップ（４８４）と、既存のオーディオ・チャンクからオーディオ情報を抽出（４８６）して新たな「オーディオ」チャンクを生成（４８８）するステップとを含む。処理は、オーディオ・ソース全体が再チャンクされたとの判断（４９０）が為されるまで反復される。その時点において、オーディオの再チャンクは完了（４９２）する。

３．５．「ビデオ」チャンクの生成方法
上述された如く、ビデオ・チャンクを生成するプロセスはビデオ・ソースを復号化するステップと、復号化されたビデオを「ビデオ」チャンクへと符号化するステップとを包む。一実施例において各「ビデオ」チャンクは、ビデオの単一フレームに対する情報を含む。復号化プロセスは単に、特定フォーマットのビデオを取り込むステップと、そのビデオをそのフォーマットから、非圧縮ともされ得る標準的なビデオ・フォーマットへと復号化するステップとを包含する。符号化プロセスは、標準的なビデオを取り込むステップと、そのビデオを符号化するステップと、符号化されたビデオを用いて「ビデオ」チャンクを生成するステップとを含む。

図３．５．には、本発明の実施例によるビデオ・エンコーダが概念的に示される。ビデオ・エンコーダ５００は、標準的ビデオ情報５０４を前処理５０２する。次に、前処理済みビデオに対して動作評価５０６が実施されることで、前処理済みビデオに対する動作補償５０８が提供される。動作補償されたビデオに対しては、離散余弦変換（ＤＣＴ変換）５１０が実施される。そのＤＣＴ変換に続き、ビデオは量子化５１２されると共に、予測５１４が実施される。次に、ビデオのテクスチャ・コード化５１８バージョンを、動作評価の結果を用いて生成された動作コーディング５２０と組み合わせることにより、圧縮ビットストリーム５１６が生成される。圧縮ビットストリームは次に、「ビデオ」チャンクを生成すべく用いられる。

動作評価５０６を実施するために、（例えば、圧縮されたビデオがプレーヤによる視認のために解凍されたときに）システムは、ビデオの先行処理フレームが復号化デバイスにより如何にして復号化されたかに関する知見を有さねばならない。この情報は、量子化器５１２の出力を逆量子化５２２することにより求められ得る。次に、逆量子化器の出力に関して逆ＤＣＴ５２４が実施され得ると共に、その結果は動作評価プロセスの間におけるアクセスのためにフレーム記憶器５２６に載置される。

本発明の実施例によるマルチメディア・ファイルはまた、所定数の心理視覚的強化（psychovisual enhancement）５２８も含み得る。その心理視覚的強化は、人間の視覚の認識に基づきビデオを圧縮する方法とされ得る。これらの技術は、以下において更に論じられると共に、概略的には、量子化器により使用される所定数のビットを改変してビデオの種々の側面を表す段階を包含する。符号化プロセスの他の側面もまた、心理視覚的強化を含み得る。

一実施例において符号化システム５００は、上述の種々の機能を実施すべく構成されたコンピュータを用いて実現され得る。これらの機能の詳細な実施方式の例は以下に提供される。

３．５．１．前処理方法
本発明の実施例によるエンコーダ５００により選択的に実施される前処理操作５０２は、符号化されたビデオの品質を改善する多数の信号処理技術を使用し得る。一実施例において前処理５０２は、インターレース解除、時間的／空間的ノイズ減少およびサイズ再設定のひとつもしくは全てを包含し得る。これらの前処理技術の３つ全てが使用される実施例において、典型的には最初に交互配置解除が行われ、時間的／空間的ノイズ減少およびサイズ再設定が追随する。

３．５．２．動作評価および補償
本発明の実施例によるビデオ・エンコーダは、複数のフレームにおいて反復されるピクセルを検索することにより、ビデオ・トラックを表すために必要なピクセルの個数を減少し得る。本質的に、ビデオにおける各フレームは典型的に、ひとつ前のフレームと同一のピクセルの多くを含んでいる。エンコーダは、（マクロブロック、ピクセル、ハーフ・ピクセルおよびクォータ・ピクセルとして）各フレーム間におけるピクセルの整合に対して幾つかの形式の検索を行い得ると共に、可能な場合は常に、イメージ品質を低下させずにこれらの冗長性を排除する。動作評価を用いることでエンコーダは、全てのフレームに対してピクチャ全体を記憶する代わりに、最後のフレームから生じた変化を記録するだけでピクチャの殆どを表し得る。動作評価の間にエンコーダは、自身が分析しつつあるフレームを、多くの場合に「macroblock（マクロブロック）」と称される均一な格子のブロックへと分割する。フレームにおける各「macroblock」に対し、エンコーダは先行フレームにおける整合ブロックを見出そうと試行し得る。整合ブロックを見出そうと試行するプロセスは、「モーション・サーチ」と称される。「macroblock」の動作は、２次元ベクトルすなわち（x,y）表現として表される。動作検索アルゴリズムは、種々の度合いの精度を以て実施され得る。ホール・ペル（whole pel）検索は、いずれかの次元において一度に１個のピクセルで基準フレームを全体に亙り踏破することで整合ブロックの位置決定をエンコーダが試行するという検索である。ハーフ・ピクセル検索においてエンコーダは、いずれかの次元において一度に半分のピクセルで基準フレームを全体に亙り踏破することで整合ブロックを検索する。エンコーダは、クォータ・ピクセル、他のピクセル割合、または、１個のピクセルより大きな粒度を包含する検索を使用し得る。

図３．５．に示されたエンコーダ実施例は、本発明の実施例による動作評価を実施する。動作評価の間においてエンコーダは、前処理済みビデオ５０２と、フレーム記憶器５２６に記憶された先行フレームとに対してアクセスする。先行フレームは、量子化器の出力を取り込むと共に、逆量子化５２２および逆ＤＣＴ変換５２４を実施することで生成される。上記の各逆関数を実施する理由は、本発明の実施例によるプレーヤにより復号化されたときに、フレーム記憶器におけるフレームがそのまま現れる様にするためである。

動作補償は、動作評価の結果として生成されたブロックおよびベクトルを取り込むことにより実施される。結果は、付加的なテクスチャ情報を提供することにより実際のイメージに整合され得る符号化イメージの近似である。

３．５．３．離散余弦変換
図３．５．に示されたエンコーダにより実施されるＤＣＴおよび逆ＤＣＴは、ISO/IEC 14496-2:2001（E）、付属文書A.1（コーディング変換）において仕様を定められた規格に従う。

３．５．３．１．変換の説明
ＤＣＴは、一群の空間領域データ点を周波数領域表現へと変換する方法である。ビデオ圧縮の場合には２次元ＤＣＴが、イメージ・ブロックを、冗長性が更に容易に利用され得る形態へと変換する。周波数領域ブロックは、エントロピ・コーディングにより容易に圧縮される疎（まば）らな行列であり得る。

３．５．３．２．変換に対する心理視覚的強化
ＤＣＴ係数は、人的視認者に対して容易に明らかである領域における量子化ノイズを減少することにより量子化イメージの品質を改善すべく改変され得る。これに加え、人的視認者により容易には認識され得ないイメージの部分における量子化ノイズは増加することにより、ファイル・サイズは減少され得る。

本発明の実施例によるエンコーダは、「低速」心理視覚的強化と称されるものを実施し得る。「低速」心理視覚的強化は、ビデオ・イメージの各ブロックを分析し、かつ、そこにおける一定のノイズを許容するとビデオの外観を劣化させずに一定のビットを節約し得るか否かを判断するものである。その処理は、ブロック毎に１つの測定値を使用する。その処理は「低速」処理と称される、と言うのも、それは相当量の演算を実施してブロッキング（blocking）またはリンギング（ringing）アーチファクトを回避するからである。

本発明の実施例によるエンコーダの他の実施例は、「高速」心理視覚的強化を実施する。その「高速」心理視覚的強化は、ブロック内でノイズが出現して量子化ノイズを形状化し得る箇所を制御し得る。

「低速」および「高速」心理視覚的強化の両方が、以下においてより詳細に論じられる。本発明の実施例に依れば、イメージエッジ部におけるノイズを制御する処理であって人間の視覚に対して容易に明らかではないイメージの領域において更に高レベルの量子化ノイズを集中しようとする処理などの心理視覚的強化が実施され得る。

３．５．３．３．「低速」心理視覚的強化
「低速」心理視覚的強化は、ビデオ・イメージの各ブロックを分析し、一定のノイズを許容するとビデオの外観を劣化させずにビットが節約され得るか否かを決定する。一実施例においてアルゴリズムは、２つの段階を含む。第１段階は、入力された輝度ピクセルに対する差分イメージ（differentiated image）の生成を含む。差分イメージは、以下に記述される様式で生成される。第２段階は、量子化に先立ちＤＣＴ係数を改変する段階を含む。

３．５．３．３．１．差分イメージの生成
差分イメージの各ピクセルｐ’_xyは、非圧縮のソース・ピクセルｐ_xyから、以下に従い算出される。

式中、ｐ’_xyは（８ビットのビデオを仮定すると）０〜２５５の範囲である。

３．５．３．３．２．ＤＣＴ係数の改変
ＤＣＴ係数の改変は、ブロック・リンギング係数の算出、ブロック・エネルギの算出、および、係数値の実際の改変を包含し得る。

３．５．３．３．３．ブロック・リンギング係数の算出
イメージの各ブロックに対し、「リンギング係数（ringing factor）」は差分イメージのローカル領域に基いて算出される。ブロックが８×８ブロックとして定義される実施例において、リンギング係数は以下の方法を用いて決定され得る。

最初に、８×８ブロック内における最大および最小の輝度ピクセル値に基づき、閾値が決定される。
ｔｈｒｅｓｈｏｌｄ_block＝ｆｌｏｏｒ（（ｍａｘ_block−ｍｉｎ_block）／８）＋２

差分イメージおよび閾値は、ブロックの近傍における「フラット（flat）」ピクセルのマップを生成すべく用いられる。各ブロックが異なる閾値を有する可能性は、フレーム全体に対するフラット・ピクセルのマップの生成を阻害する。マップは以下の如く生成される。
ｆｌａｔ_xy＝１ ｐ’_xy＜ｔｈｒｅｓｈｏｌｄ_blockのとき
ｆｌａｔ_xy＝０ それ以外

フラット・ピクセルのマップは、単純な論理演算に従いフィルタリングされる。
ｆｌａｔ’_xy＝１ ｆｌａｔ_xy＝１ ｆｌａｔ_x-1y＝１ ｆｌａｔ_xy-1＝１ ｆｌａｔ_x-1y-1＝１
ｆｌａｔ’_xy それ以外

フィルタリングされたマップにおけるフラット・ピクセルは次に、その８×８ブロックをカバーする９×９領域の全体に亙りカウントされる。

０＝ｘ＝８および０＝ｙ＝８に対し、

視認可能なリンギング・アーチファクトのリスクは、以下の式を用いて評価され得る。
ｒｉｎｇｉｎｇｂｒｉｓｋ_block＝（（ｆｌａｔｃｏｕｎｔ_block−１０）ｘ２５６＋２０）／４０

次に、以下の式を用いて8×8ブロックのリンギング係数が導出され得る。
Ｒｉｎｇｉｎｇｆａｃｔｏｒ＝０ ｒｉｎｇｉｎｇｒｉｓｋ＞２５５のとき
＝２５５ ｒｉｎｇｉｎｇｒｉｓｋ＜０のとき
＝２５５−ｒｉｎｇｉｎｇｒｉｓｋ その他の場合

３．５．３．３．４．ブロック・エネルギの算出
イメージのブロックに対するエネルギは、以下の手順を用いて計算され得る。

ソース・イメージに対して順方向ＤＣＴが実施される。
Ｔ＝ｆＤＣＴ（Ｓ）
式中、Ｓは問題となる８×８ブロックの６４個のソース・イメージ輝度値であり、かつ、Ｔはソース・イメージの同一部分の変換バージョンである。

特定の係数位置におけるエネルギは、その係数の値の二乗として定義される。
０＝ｋ＝６３に対し、ｅ_k＝ｔ_k ²

式中、ｔ_kは変換されたブロックＴの第ｋ番目の係数である。

３．５．３．３．５．係数の改変
ＤＣＴ係数の改変は、以下の処理に従い実施され得る。幾つかの実施例においてその処理は、量子化の前に、全ての非ゼロのＡＣ ＤＣＴ係数に対して実施される。各係数の大きさは、心理視覚的技術に従い決定された小さなデルタだけ変化せしめられる。

非ゼロＡＣ係数ｃｋの各々のＤＣＴ係数改変は、以下の式を用いてローカルおよびブロック・エネルギに基づくエネルギを計算することで実施される。

ｅｎｅｒｇｙ_k＝ｍａｘ（ａ_k × ｅ_k，０．１２ × ｔｏｔａｌｅｎｅｒｇｙ）

式中、ａ_kは、以下の表に記述された係数位置に値が依存する定数である。

エネルギは、以下の関係を用いてブロックのリンギング係数に従い改変され得る。
ｅｎｅｒｇｙ’_k＝ｒｉｎｇｉｎｇｆａｃｔｏｒ × ｅｎｅｒｇｙ_k

結果的な値は、ルックアップ・テーブル（ＬＵＴ）に対する入力として使用される前にシフトかつクリップされる。
ｅ_k＝ｍｉｎ（１０２３，４×ｅｎｅｒｇｙ’_k）
ｄ_k＝ＬＵＴ_i そこで ｉ＝ｅｋ

ルックアップ・テーブルは、以下の如く算出される。

また以下の表に記述された様に値「オフセット（offset）」は、量子化数Ｑｐに依存する。

変数ktextureおよびkflatは夫々、フラットな領域およびテクスチャ化された領域における心理視覚的効果の強さを制御する。一実施例においてそれらは0〜1の範囲の値を取り、0は効果なしを意味しかつ1は完全効果を意味する。一実施例においてktextureおよびkflatに対する値は以下の如く確立される。

輝度： ｋ_texture＝１．０
： ｋ_flat＝１．０
色度： ｋ_flat＝１．０
： ｋ_flat＝０．０

検索テーブル（lookup table）からの出力（dk）は、以下の付加的プロセスによりDCT係数の大きさを改変すべく用いられる。

ｃ’_k＝ｃ_k−ｍｉｎ（ｄ_k，｜ｃ_k｜） ｘ ｓｇｎ（ｃ_k）
最後に、ＤＣＴ係数ｃ_kは、改変された係数ｃ’_kにより置換され、量子化のために前送りされる。

３．５．３．４．「高速」心理視覚的強化
「高速」心理視覚的強化は、入力輝度ピクセルに対する「重要性」マップを算出してからDCT係数を改変することにより、DCT係数に関して実施され得る。

３．５．３．４．１．「重要性」マップの算出方法
「重要性」マップは、入力ビデオ・フレームの輝度箇所における各ピクセルに対して「重要性」値を計算することにより生成され得る。幾つかの実施例において「重要性」値は、その特定のピクセルに配置された一切の歪曲に対する人間の目の感度を近似する。「重要性」マップは、ピクセルの「重要性」値の配列である。

ピクセルの「重要性」は、ピクセル（dxy）の周りのピクセルのブロックのダイナミック・レンジを先ず計算することにより決定され得る。幾つかの実施例において、ピクセル箇所（x,y）に中心合わせされた3×3ブロックのダイナミック・レンジは、その領域において最も暗いピクセルの値を、その領域において最も明るいピクセルの値から減算することで算出される。

ピクセル（mxy）の「重要性」は、以下の如く、そのピクセルのダイナミック・レンジから導出され得る。
ｍ_xy＝０．０８／ｍａｘ（ｄ_xy，３）＋０．００１

３．５．３．４．２．ＤＣＴ係数の改変方法
一実施例においてＤＣＴ係数の改変は、基底関数のエネルギ行列およびデルタ・ルックアップ・テーブルの生成を含む。

３．５．３．４．３．基底関数のエネルギ行列の生成
ＤＣＴ係数を改変する際には、一群の基底関数エネルギ行列が使用され得る。これらの行列は、符号化に先立ち算出され得る定数値を含む。６４個のＤＣＴ基底関数の各々に対しては、８×８行列が用いられる。各行列は、８×８ブロックにおける全てのピクセルがその対応係数の改変により如何に影響されるかを記述する。第ｋ番目の基底関数エネルギ行列は、１００に設定された対応係数と０に設定された他の係数とを有する８×８行列Ａｋを採用することにより導出される。

ａ_kn＝１００ ｎ＝ｋの場合
＝０ それ以外
式中、ｎは８×８行列内における係数の位置を表す。０＝ｎ＝６３
逆ＤＣＴは行列に関して実施され、更なる８×８行列Ａ’_kが生成される。行列の要素（ａ’_kn）は、第ｋ番目のＤＣＴ基底関数を表す。

Ａ’_k＝ｉＤＣＴ（Ａ_k）
変換された行列における各値は次に二乗される。
０＝ｎ＝６３に対して、ｂ_kn＝ａ’_kn ²

処理は６４回実施され、各々が６４個の自然数を備える、０＝ｋ＝６３である基底関数エネルギ行列Ｂｋが生成される。各行列値は、８×８ブロックにおける第ｎ番目の位置におけるピクセルが係数ｋの任意のエラーまたは改変により如何に影響されるかの尺度である。

３．５．３．４．４デルタ・ルックアップ・テーブルの生成
係数改変デルタの算出を促進すべく、ルックアップ・テーブル（ＬＵＴ）が使用され得る。そのテーブルの内容は、「高速」心理視覚的強化の所望の強度と量子化数・パラメータ（Ｑ_p）とに依存する様式で生成され得る。

ルックアップ・テーブルの値は、次の関係に従い生成され得る。

式中、ｉはテーブルにおける位置であり、０＝ｉ＝１０２３である。

以下のテーブルに記述された如く、strength、およびoffsetは、量子化数（Quantizer）Qpに依存する。

変数ｋ_textureおよびｋ_flatは夫々、フラットな領域およびテクスチャ化された領域における心理視覚的効果の強さを制御する。一実施例においてそれらは０〜１の範囲の値を取り、０は効果なしを意味しかつ１は完全効果を意味する。一実施例においてｋ_textureおよびｋ_flatに対する値は以下の如く確立される。

輝度： ｋ_texture＝１．０
： ｋ_flat＝１．０
色度： ｋ_flat＝１．０
： ｋ_flat＝０．０

３．５．３．４．５．ＤＣＴ係数の改変
ＤＣＴ係数は、で計算された値を用いて改変され得る。一実施例において各非ゼロＡＣ ＤＣＴ係数は、量子化に先立ち以下の手順に従い改変される。

最初に「エネルギ」値（ek）は、対応する基底関数エネルギ行列と、重要性マップからの適切な８×８ブロックとの内積を取ることにより算出される。この「エネルギ」は、特定係数における量子化エラーが人的視認者により如何に認識されるかの尺度である。それは、ピクセル重要性とピクセル基底関数エネルギとの積の合計である。

ｅ_k＝Ｍ・Ｂ_k
式中、
Ｍは８×８ブロックの重要性マップ値であり、かつ、
Ｂ_kは第ｋ番目の基底関数エネルギ行列である。

結果的な「エネルギ」値は、デルタ・ルックアップ・テーブルへのインデックス（dk）として使用される前に、シフトかつクリップされる。

ｅ_k＝ｍｉｎ［１０２３， ｆｌｏｏｒ（ｅ_k／３２７６８）］
ｄ_k＝ＬＵＴ_i
そこで、ｉ＝ｅ’_k

デルタ・ルックアップ・テーブルの出力は、付加的プロセスによりDCT係数の大きさを改変すべく用いられる。

ｃ’_k＝ｃ_k−ｍｉｎ（ｄ_k，｜ｃ_k｜）×ｓｉｇｎ（ｃ_k）

ＤＣＴ係数ｃｋは、改変されたｃ’ｋにより置換されて、量子化のために前送りされる。

３．５．４．量子化
本発明の実施例によるエンコーダは、１９９６年のＩＴＵ−Ｔ勧告Ｈ．２６３、低ビットレート通信に対するビデオ・コーディングとして国際電気通信連合により策定された量子化器などの標準的な量子化器を使用し得る。

３．５．４．１．量子化に対する心理視覚的強化
本発明の実施例による幾つかのエンコーダは、人間の視覚の心理的効果を利用して更に効率的な圧縮を達成する心理視覚的強化を使用する。心理視覚的効果は、フレーム・レベルおよびマクロブロック・レベルで適用され得る。

３．５．４．２．フレーム・レベルの心理視覚的強化
フレーム・レベルにて適用されたとき、その強化は速度制御アルゴリズムの一部であり、その目標は、人間の目により認識される最高の視覚的品質を確実にすべく所定量のビットレートが最適に使用される様に符号化方法を調節することである。フレーム速度の心理視覚的強化は、動作が早いときに人間の視覚は詳細を無視する傾向がありかつ人間の視覚はイメージが静止的であるときに詳細に注目する傾向があるという理論により動機付けられる。一実施例において動作の量は、フレームに対する絶対的差の合計（ＳＡＤ）を調べることで決定される。一実施例においてＳＡＤ値は、２つのブロックの共配置された輝度ピクセルの絶対的差を合計することにより決定される。幾つかの実施例においては、16×１６ピクセル・ブロックの絶対的差が用いられる。部分的ピクセル・オフセットを取り扱う実施例においては、絶対的差の合計が計算される前に、MPEG-4規格（ISO/IECの動画専門委員会により開発されたISO/IEC規格）において仕様を定められた様に、内挿が実施される。

フレーム・レベルの心理視覚的強化はビデオ・トラックのＰフレームに対してのみその当し、そのフレームのＳＡＤ値に基づく。符号化の間に心理視覚的モジュールは、ビデオ・トラックのＰフレームの全ての平均ＳＡＤ（すなわち＾ＳＡＤ）と、各フレームの全体的ＳＡＤからの各フレームのＳＡＤの平均距離（すなわち＾ＤＳＡＤ）との記録を維持する。平均化は、指数移動平均アルゴリズムを用いて行われ得る。一実施例においては、上述のワンパス速度制御アルゴリズムが此処での平均化期間（averaging period）として使用され得る。

符号化されたビデオ・トラックの各Ｐフレームに対し、（速度制御モジュールから獲得された）フレーム・量子化数Ｑは、それに適用される心理視覚的補正値を有する。一実施例においてプロセスは、以下の式を用いて比率Ｒを計算する段階を包含する。

式中、Ｉは定数でありかつ現在は０．５に設定される。Ｒは［−１， １］の境界内に短縮される。

量子化数は次に、比率Ｒに従い、以下に示される計算を介して調節される。

式中、Ｓ_frameはフレーム・レベル心理視覚的強化に対する強度定数である。

Ｓ_frame定数は、フレーム・レベル心理視覚に対して調節が如何に強力であり得るかを決定する。コーデックの一実施例においては、Ｓ_frameを０．２、０．３または０．４に設定するオプションが利用可能である。

３．５．４．３．マクロブロック・レベルの心理視覚的強化
マクロブロック・レベルで心理視覚的強化を利用する本発明の実施例によるエンコーダは、人的視認者に対するビデオの視覚的品質に対して目立つマクロブロックを識別することを試行すると共に、これらのマクロブロックを更に高品質でコード化することを試行する。マクロブロック・レベルの心理視覚的強化の効果は、フレームに対して重要さが少ない部分からビットを取り去り、それらを、フレームの更に重要な部分に適用することである。幾つかの実施例においては、円滑度、明るさ、および、マクロブロックＳＡＤに基づく３つの技術を用いて達成される。他の実施例においては、技術の内の任意のひとつの技術がそれのみで、もしくは、技術の別のものと組み合わされて、または、完全に別の技術が使用され得る。

一実施例においては、上述の３通りのマクロブロック・レベルの心理視覚的強化の全てが、マクロブロック・レベルの心理視覚的強化の強度を制御する共通パラメータSMBを共有する。次に、各マクロブロックに対する最大および最小の量子化数が、以下に示される計算を介して強度パラメータおよびフレーム・量子化数Qframeから導出される。

値Ｑ_MBMaxは、最大量子化数であり、値Ｑ_MBMaxは、最小量子化数である。
値Ｑ_MBMaxおよびＱ_MBMaxは、フレーム全体に対するマクロブロック・量子化数に対する上下の境界を定義する。一実施例においては、値Ｓ_MBを値０．２、０．３および０．４の内の任意の値に設定するオプションが提供される。他の実施例においては、Ｓ_MBに対する他の値が利用され得る。

３．５．４．３．１．明るさ強化
心理視覚的強化がマクロブロックの明るさに基づいて実施される実施例において、エンコーダは更に明るいマクロブロックを更なる高品質で符号化することを試行する。この強化の理論的根拠は、フレームの比較的に暗い部分は人的視認者により概略的に無視されるということである。このマクロブロックの心理視覚的強化は、ビデオ・トラックのIフレームおよびPフレームに対して適用される。各フレームに対してエンコーダは、最初にフレーム全体を一覧する。平均明るさ（＾ＢＲ）が計算され、かつ、平均からの明るさの平均差（＾ＤＢＲ）も計算される。これらの値は次に、心理視覚的強化が適用されるべきか否かに対するインディケータとして使用され得る２つの閾値（TBRLower，TBRUpper）を作成すべく用いられる。

明るさ強化は次に、以下に述べられる条件を用いて２つの閾値に基づいて適用され、マクロブロックに対して意図された量子化数（QMB）が生成される。
Ｑ_MB＝Ｑ_MBMin ＢＲ＞Ｔ_BRUpperのとき、
Ｑ_MB＝Ｑ_frame Ｔ_BRLower≦ＢＲ≦Ｔ_BRUpperのとき、および、
Ｑ_MB＝Ｑ_MBMax ＢＲ＜Ｔ_BRLowerのとき；
式中、ＢＲはその特定のマクロブロックに対する明るさ値である。 式中、ＢＲはその特定のマクロブロックに対する明るさ値である。

エンコーダがＭＰＥＧ−４規格に準拠するという実施例において、マクロブロック・レベルの心理視覚的明るさ強化技術は、ひとつのマクロブロックから次のマクロブロックにかけて±２より多く量子化数を変更し得ない。故に計算されたQMBは、先行するマクロブロックにおいて使用された量子化数に基づく改変を必要とし得る。

３．５．４．３．２．円滑度強化
円滑度の心理視覚的強化を含む本発明の実施例によるエンコーダは、符号化されつつあるイメージの空間的変動に基づき量子化数を改変する。円滑度の心理視覚的強化の使用は、人間の視覚はイメージの円滑部分における量子化アーチファクトに対して大きな感度を有するという理論により動機付けられ得る。故に円滑度の心理視覚的強化は、イメージの更に円滑な部分を表すビットの個数を増大すると共にイメージの空間的変動の度合いが高い箇所ではビットの個数を減少するというステップを含む。

一実施例においてイメージの一部分の円滑度は、マクロブロックの明るさ（brightness）に対するそのマクロブロックのピクセルの輝度（luminance）における平均差（＾ＤＲ）として測定される。図３．６．には、本発明の実施例に従いＩフレームに対して円滑度の心理視覚的強化を実施する方法が示される。プロセス５４０は、フレーム全体を検証して＾ＤＲを計算（５４２）するステップを含む。次に、円滑度強化ＴＤＲを適用する閾値は、以下の計算を用いて導出（５４４）され得る。

以下の円滑度強化は、閾値に基づいて実施（５４６）される。
Ｑ_MB＝Ｑ_frame ＤＲ≧Ｔ_DRのとき、および、
Ｑ_MB＝Ｑ_MBMin ＤＲ＜Ｔ_DRのとき。
式中、
Ｑ_MBは、マクロブロックに対して意図された量子化数であり、
ＤＲは、マクロブロックに対する偏差値（すなわち、平均輝度−平均明るさ）である。
ＭＰＥＧ−４規格に従いファイルを符号化する実施例は、上述された如く、マクロブロック・レベルの量子化数変化はひとつのマクロブロックから次のマクロブロックへと多くとも±２とされ得るという点において制限される。

３．５．４．３．３．マクロブロックＳＡＤ強化
本発明の実施例によるエンコーダは、マクロブロックＳＡＤ心理視覚的強化を利用し得る。マクロブロックＳＡＤ心理視覚的強化は、静止的マクロブロックに対する詳細を高めると共に、速い動作のシーンで使用されるフレームの部分における詳細は低減させ得るべく使用され得る。図３．７．には、本発明の実施例に従いマクロブロックＳＡＤ心理視覚的強化を実施するプロセスが示される。プロセス５７０は、Ｉフレーム全体を検査（５７２）し、フレーム全体における全てのマクロブロックに対する平均ＳＡＤ（すなわち＾ＭＢＳＡＤ）を決定する段階を含み、かつ、平均からのマクロブロックのＳＡＤの平均差（すなわち＾ＤＭＢＳＡＤ）も求められる。一実施例においてはこれらのマクロブロックの両方が、フレーム間コード化されたマクロブロック（すなわち、動作補償、または、先行する符号化ビデオ・フレームに対する他の依存性を用いて符号化されたマクロブロック）の全体に亙り平均化される。次にこれらの平均から、以下の式を用いてマクロブロックＳＡＤ強化を適用する２つの閾値が導出（５７４）される。

そこで、
Ｔ_MBSADLowerは下側閾値であり、
Ｔ_MBSADUpperは上側閾値であり、必要であればこれらは１０２４だけ境界付けられ得る。

次にマクロブロックSAD強化はこれらの２つの閾値に基づき以下の条件に従い適用（５７６）される。
Ｑ_MB＝Ｑ_MBMax ＭＢＳＡＤ＞Ｔ_MBSADUpperのとき、
Ｑ_MB＝Ｑ_frame Ｔ_MBSADLower≦ＭＢＳＡＤ≦Ｔ_MBSADUpperのとき、
Ｑ_MB＝Ｑ_MBMin ＭＢＳＡＤ＜Ｔ_MBSADLowerのとき。
そこで、
Ｑ_MBはマクロブロックに対して意図された量子化数であり、
ＭＢＳＡＤはその特定のマクロブロックに対するＳＡＤ値である。

ＭＰＥＧ−４仕様に従いファイルを符号化する実施例は、上述された如く、マクロブロック・レベルの量子化数変化はひとつのマクロブロックから次のマクロブロックへと多くとも±２とされ得るという点において制限される。

３．５．５．速度制御
本発明の実施例によるエンコーダにより使用される速度制御技術は、割当てられたビットレートをエンコーダが使用してビデオ・シーケンスを符号化する方法を決定し得る。エンコーダは典型的に所定ビットレートへと符号化することを目的とする共に、速度制御技術は、エンコーダにより生成されるビットレートを所定ビットレートに対して可及的に近付けて整合せねばならない。速度制御技術はまた、ビデオ・シーケンスが復号化されるときにそのビデオ・シーケンスの最高の視覚的品質を確実にする様式でビットレートを割当てることも目的とし得る。速度制御の多くは、量子化数を調節することにより実施される。量子化数は、エンコーダがビデオ・シーケンスを如何に精細にコード化するかを決定する。量子化数が小さいほど品質は高く、ビット消費が多くなる結果となる。故に速度制御アルゴリズムは、ビデオ品質およびビット消費という競合関係をバランスさせる様式で量子化数を改変することを目的とする。

本発明の実施例によるエンコーダは、種々の異なる速度制御技術の内の任意の技術を利用し得る。一実施例においては、単一パス速度制御技術が用いられる。他の実施例においては、二重（もしくは多重）パス速度制御技術が用いられる。これに加え、必要に応じて「ビデオ・バッファ検証式」速度制御が実施され得る。これらの技術の特定例は、以下で論じられる。但し、本発明の実施方法に従うエンコーダにおいては任意の速度制御技術が使用され得る。

３．５．５．１．ワンパス速度制御
本発明の実施例によるワンパス速度制御技術の実施例は、速い動作のシーンに対して高いビットレート・ピークを許容することを目的とする。幾つかの実施例においてワンパス速度制御技術は、シーンにおける動作の量の増大に応じてビットレートを徐々に増大すると共に、シーンにおける動作の減少に応じてビットレートを迅速に減少することを目的とする。

一実施例においてワンパス速度制御アルゴリズムは、ビットレートを追尾すべく２つの平均化期間を用いる。長期平均は全体的なビットレート収束を確実にし、短期平均はシーンにおける動作の量の変動に対する応答を可能とする。

図３．８．には、本発明の実施例によるワンパス速度制御技術が示される。ワンパス速度制御技術５８０は、所望のビットレート、ビデオ・フレーム速度および（以下において更に論じられる）種々の他のパラメータによりエンコーダを初期化（５８４）することにより開始（５８２）する。量子化数を表す浮動小数点変数が記憶される。もしフレームが量子化（５８６）を必要とするなら、浮動小数点変数が読み出され（５８８）、量子化数はその浮動小数点変数を最も近い整数に丸めることで求められる。フレームは次に符号化（５９０）される。フレームの符号化の間においては観察が為され、新たな量子化数値の決定（５９２）が可能とされる。プロセスは、更なるフレームが無くなるまで反復することを判断（５９４）する。その時点において、符号化は完了（５９６）する。

で論じられた如くエンコーダは種々のパラメータにより初期化（584）される。これらのパラメータは、「ビットレート」、「フレーム速度」、「最大キー・フレーム間隔」、「最大量子化数」、「最小量子化数」、「平均化期間」、「反応期間」および「上／下比率」である。以下の内容は、これらのパラメータの各々に対する考察である。

３．５．５．１．１．「ビットレート」
「ビットレート」パラメータは、符号化の目標ビットレートを設定する。

３．５．５．１．２．「フレーム速度」
「フレーム速度」は、ビデオの各フレーム間の期間を定義する。

３．５．５．１．３．「最大キー・フレーム間隔」
「最大キー・フレーム間隔」は、キー・フレーム間の最大間隔を特定する。キー・フレームは通常、コーデックがシーン変化を検出したときに、符号化ビデオに自動的に挿入される。シーンが単一カットなしで長い間隔に亙り継続的するという状況において、当該キー・フレーム間の間隔が常に「最大キー・フレーム間隔」以下であることを確実にすべくキー・フレームが挿入され得る。一実施例において「最大キー・フレーム間隔」パラメータは300フレームの値に設定され得る。他の実施例においては、他の値が使用され得る。

３．５．５．１．４．「最大量子化数」および「最小量子化数」
「最大量子化数」および「最小量子化数」パラメータは、符号化において使用される量子化数の上下の境界を設定する。一実施例において量子化数境界は、１〜３１の値に設定される。

３．５．５．１．５．「平均化期間」
「平均化期間」パラメータは、量子化数を改変するときに考慮されるビデオの量を制御する。平均化期間が長いと、典型的には、更に正確な全体的速度を有する符号化ビデオに帰着する。一実施例においては2000の「平均化期間」が用いられる。但し、他の実施例においては他の値が使用され得る。

３．５．５．１．６．「反応期間」
「反応期間」パラメータは、最近のシーンにおける動作の変化に対してエンコーダが如何に迅速に適合するかを決定する。「反応期間」値が長いと、品質は更に良好で速い動作のシーン、および、品質は更に低下して遅い動作のシーンに帰着する。一実施例においては、10の「反応期間」が用いられる。但し、他の実施例においては他の値が使用され得る。

３．５．５．１．７．「上／下比率」
「上／下比率」パラメータは、速いまたは遅い動作のシーンに応じた量子化数調節に対する相対感度を制御する。大きな値は典型的に、高品質で速い動作のシーンおよび大きなビット消費に帰着する。一実施例においては20の「上／下比率」が用いられる。但し、他の実施例においては他の値が使用され得る。

３．５．５．１．８．量子化数値の計算方法
で論じられた如くワンパス速度制御技術は、各フレームの符号化の後で量子化数値の計算を包含する。以下の内容は、量子化数値を更新すべく使用され得る本発明の実施例による技術の説明である。

エンコーダは、ビットレートの移動平均の「平均化期間」（Paverage）および「反応期間」（Preaction）に等しい２つの指数的移動平均を維持する。その２つの指数的移動平均は以下の関係に従い計算され得る。

そこで、
Ａ_tは瞬間ｔにおける平均であり、
Ａ_t-1は瞬間ｔ−Ｔにおける平均（通常は先行フレームにおける平均）であり、
Ｔは間隔期間（通常はフレーム時間）を表し、かつ、
Ｐは、Ｐ_averageおよび／またはＰ_reactionとされ得る平均期間である。

で計算された移動平均は次に、以下の計算を用いてビデオにおける現在の瞬間と最後の瞬間との間の時的間隔により除算されることで、ビットレートへと調節される。

そこで、
Ｒ_tはビットレートであり、
Ａ_tは移動平均のいずれかであり、かつ、
Ｔは現在の瞬間と最後の瞬間との間の時的間隔（それは通常はフレーム速度の逆数）である。

エンコーダは以下の如く、次のフレームの目標ビットレート（Ｒ_target）を計算し得る。
Ｒ_target ＝ Ｒ_overall ＋ （Ｒ_overall − Ｒ_average）
そこで、
Ｒ_overallは、ビデオ全体に対して設定された全体的ビットレートであり、かつ、
Ｒ_averageは、長い平均化期間を用いる平均ビットレートである。

幾つかの実施例において目標ビットレートは、全体的ビットレートの75％にて下方に境界付けられる。もし目標ビットレートが境界より低く低下したなら、それは境界の上方に押しやられ、ビデオの品質が確実とされる。

エンコーダは次に、Ｒ_targetとＲ_reactionとの間の差に基づいて内部量子化数を更新する。もしＲ_reactionがＲ_targetより小さければ、先行フレームは比較的に複雑さが少なかった可能性が在る。故に量子化数は、以下の計算を実施することにより減少され得る。

Ｒ_reactionがＲ_targetより大きいとき、先行フレームは比較的に高レベルの複雑さを保有していた可能性が高い。故に量子化数は、以下の計算を実施することで増大され得る。

式中、Ｓは「上／下比率」である。

３．５．５．１．９．Ｂ−ＶＯＰ符号化方法
上述のアルゴリズムは、Ｂ−ＶＯＰ符号化方法に対しても適用され得る。符号化方法においてＢ−ＶＯＰが有効化されたとき、Ｂ−ＶＯＰに対する量子化数（ＱＢ）は、Ｂ−ＶＯＰに追随するＰ−ＶＯＰの量子化数（ＱＰ）に基づいて選択される。値は、次の関係に従い求められ得る。
Ｑ_B＝２・Ｑ_P Ｑ_P≦４の場合、
Ｑ_B＝５＋（３／４）・Ｑ_P ４＜Ｑ_P≦２０の場合、
Ｑ_B＝Ｑ_P Ｑ_P≧２０の場合。

３．５．５．２．ツーパス速度制御
２回の（または複数回の）パスの速度制御を使用する本発明の実施例によるエンコーダは、第１のパスにおいてはビデオ・シーケンスのプロパティを決定してから、シーケンス全体のプロパティの知見を以てビデオ・シーケンスを符号化し得る。故にエンコーダは各フレームの量子化レベルを、ビデオ・シーケンスにおける他のフレームと比較した相対的な複雑さに基づいて調節し得る。

本発明の実施例によるツーパス速度制御技術においてエンコーダは、ビデオは上述のワンパス速度制御技術に従い符号化されかつ各フレームの複雑さが記録される（複雑さを測定する種々の異なる測定値の内の任意のものが使用され得る）という第１のパスを実施する。平均の複雑さ、故に平均量子化数（Qref）は、第１のパスに基づいて決定され得る。第２のパスにおいては、第１のパスの間に計算された複雑さの値に基づいて決定される量子化数を以て符号化される。

３．５．５．２．１．I-VOPに対する量子化数
次のフレームがＩ−ＶＯＰでないとすれば、Ｉ−ＶＯＰに対する量子化数Ｑは０．７５×Ｑｒｅｆに設定される。もし次のフレームもＩ−ＶＯＰであれば、（現在のフレームに対する）Ｑは１．２５×Ｑ_refに設定される。

３．５．５．２．２．Ｐ−ＶＯＰに対する量子化数
Ｐ−ＶＯＰに対する量子化数は以下の式を用いて決定され得る。

そこで、
Ｃ_complexityはフレームの複雑さであり、
＾Ｃ_complexityはビデオ・シーケンスの平均の複雑さである。
Ｆ（ｘ）は、量子化値ｘを有する量子化数を用いてフレームを符号化するために必要なビットの個数を与えるためにフレームの複雑さが乗算されるべき数を提供する関数である。Ｆ^-1（ｘ）はＦ（ｘ）の逆関数であり、かつ、ｋは強度パラメータである。

以下の表は、量子化数Qと共にエンコーダを用いてフレームを符号化するために必要なビットの個数を決定するためにフレームの複雑さと乗算されるべき係数を生成すべく使用され得る関数Ｆ（Ｑ）の実施例を定義している。

もし強度パラメータkがゼロに選択されるべきであれば、結果は一定の量子化数である。強度パラメータが１に選択されるべきとき、量子化数はCcomplexityに比例する。本発明の実施例による幾つかのエンコーダは、0.5に等しい強度パラメータkを有する。

３．５．５．２．３．Ｂ−ＶＯＰに対する量子化数
Ｂ−ＶＯＰに対する量子化数Ｑは、上述のワンパス技術においてＢ−ＶＯＰに対する量子化数を選択したのと同一の技術を使用して選択され得る。

３．５．５．３．ビデオ・バッファ照合式の速度制御
フレームを表すために必要なビットの個数は、ビデオ・シーケンスの特性に依存して変化し得る。殆どの通信システムは、一定のビットレートで動作する。可変的ビットレート通信が遭遇し得る問題は、リソース使用におけるピークを取り扱うために十分なリソースを割当てることである。本発明の実施例による幾つかのエンコーダは、可変的ビットレート通信のビットレートが急激に上昇するときにおけるデコーダのビデオ・バッファのオーバーフローを阻止する意図でビデオを符号化する。

ビデオ・バッファ照合器（ＶＢＶ）速度制御の目的としては、送信されたときにデコーダのバッファを超過しないビデオの生成が挙げられる。これに加え、符号化されたビデオは目標ビットレートと整合すること、および、速度制御により高品質ビデオが生成されることが望ましい。

本発明の幾つかの実施例によるエンコーダは、少なくとも２つのVBV速度制御技術の選択肢を提供する。一方のVBV速度制御技術は因果的速度制御（causal rate control）と称され、他方の技術は第Nパス速度制御（Nth pass rate control）と称される。

３．５．５．３．１．因果的速度制御
因果的なVBV速度制御は、ワンパス速度制御技術と組み合わせて使用され得ると共に、単に現在の量子化数値と先行量子化数値とに基づいて出力を生成する。

本発明の実施例によるエンコーダは、以下の関係に従いフレームnに対する量子化数（すなわちQn）を設定する段階を包含する因果的速度制御を含む。

式中、
Ｑ’_nは、単一パス速度制御により評価された量子化数であり、
Ｘ_bitrateは、所望ビットレートからのドリフトに基づき目標ビットレートを決定することにより計算され、
Ｘ_velocityは、ＶＢＶバッファがオーバーフローまたはアンダーフローするまでの見積もり時間に基づき計算され、
Ｘ_sizeは、Ｐ−ＶＯＰの結果のみに適用され、かつ、圧縮されたＰ−ＶＯＰのサイズが経時的に変化する速度に基づいて計算され、
Ｘ_driftは、所望ビットレートからのドリフトである。

幾つかの実施例において因果的VBV速度制御は、フレームを脱落させると共に補充物を挿入してVBVモデルを顧慮することを強いられ得る。もし、圧縮されたフレームが意外に多すぎるまたは少なすぎるビットを含むなら、それは除外もしくは補充され得る。

３．５．５．３．２．第NパスVBV速度制御
第NパスVBV速度制御は、多重パス速度制御技術と組み合わせて使用され得ると共に、それは、ビデオ・シーケンスの先行分析の間に生成された情報を使用する。本発明の幾つかの実施例によるエンコーダは、図３．９．に示された処理に従い第ＮパスＶＢＶ速度制御を実施する。処理６００は第１パスで開始し、その間に分析（６０２）が実施される。マップ生成が実施（６０４）され、かつ、方針が生成（６０６）される。次に、第ｎパス速度制御が実施（６０８）される。

３．５．５．３．３．分析
一実施例において、第１のパスは一定形態の因果的速度制御を使用し、かつ、データは、フレームの持続時間、フレームのコード化形式、使用される量子化数、生成される動作ビット、および、生成されたテクスチャ・ビットなどの事項に関して各フレームに対して記録される。これに加え、時間目盛、解像度およびコーデック設定などの包括的情報も記録され得る。

３．５．５．３．４．マップ生成
分析からの情報は、ビデオ・シーケンスのマップを生成すべく用いられる。そのマップは、各フレーム（I/B/P）に対して使用されたコード化形式を特定し得ると共に、フレームの持続時間、動作の複雑さおよびテクスチャの複雑さに関して各フレームに対するデータを含み得る。他の実施例においてそのマップは、圧縮されたフレーム・サイズおよび認識的歪曲に対する量子化数および他のパラメータの影響の更に良好な予測を可能とする情報も含み得る。幾つかの実施例において、マップ生成は第N-1パスが完了した後で実施される。

３．５．５．３．５．方針作成
マップは、第Ｎパス速度制御が如何に動作するかに関する方針を計画するために使用され得る。各フレームが符号化された後におけるＶＢＶバッファの理想的レベルが、計画され得る。一実施例において方針を作成すると、所望の圧縮フレーム・サイズ、見積もられたフレーム・量子化数を含め、各フレームに対する情報に帰着する。幾つかの実施例において方針作成は、マップ生成の後で第Ｎパスに先立って実施される。

一実施例において方針作成プロセスは、エンコーダをシミュレートする反復的プロセスであって、可及的に量子化数の中央値に近く量子化数の維持を試行することにより各フレームに対する所望の量子化数値を決定する反復的プロセスを使用する段階を包含する。ビデオ・シーケンス全体に対する基礎量子化数を生成すべく、２進検索が使用され得る。基礎量子化数は、シミュレータに対して所望の目標ビットレートを達成させる一定値である。基礎量子化数が一旦見出されたなら、方針作成プロセスは、ＶＢＶ制約を考慮する段階を包含する。一実施例において、当該一定の量子化数がＶＢＶ制約を改変しないのであれば、一定の量子化数が用いられる。他の実施例において量子化数は、ビデオ・フレームにおける動作の複雑さに基づいて変調される。これは更に、シーン変化および他の一時的効果からのマスキングの取入れへと拡張され得る。

３．５．５．３．６．インループ第Nパス速度制御
一実施例において、インループ（in-loop）第Nパス速度制御は方針を使用すると共にマップを使用して、圧縮フレーム・サイズおよび認識的歪曲に関する量子化数および他のパラメータの影響の最適な可能的予測を行う。短期補正方針を採用すべく方針から逸脱する自由裁量は、限られ得る。典型的には、方針に追随すると、ＶＢＶモデルからの逸脱は防止される。一実施例においてループ内における第Ｎパス速度制御は、ＰＩＤ制御ループを使用する。その制御ループにおけるフィードバックは、理想的ビットレートからの蓄積ドリフトである。

方針作成はフレームの脱落を伴わないが、ＶＢＶバッファが別様にアンダーフローするならば、ループ内における第Ｎ速度制御はフレームを脱落させることもある。同様に、ループ内における第Ｎパス速度制御はＶＢＶオーバーフローを防止すべく、ビデオ補充物の挿入を要求し得る。

３．５．６．予測
一実施例においては、ISO/IEC 14496-2:2001（E）、セクション７．４．３．（ＤＣおよびＡＣ予測）および７．７．１．（フィールドＤＣおよびＡＣ予測）と称される規格に準拠する様式でＡＤ／ＤＣ予測が実施される。

３．５．７．テクスチャ・コーディング
本発明の実施例によるエンコーダは、ISO/IEC 14496-2:2001（E）、付属文書Ｂ（可変長コード）および７．４．１．（可変長復号化）と称される規格に準拠する様式でテクスチャ・コーディングを実施し得る。

３．５．８．動作コーディング
本発明の実施例によるエンコーダは、ISO/IEC 14496-2:2001（E）、付属文書Ｂ（可変長コード）および７．６．３．（動作ベクトル復号化）と称される規格に準拠する様式で動作コーディングを実施し得る。

３．５．９．「ビデオ」チャンクの生成方法
ビデオ・トラックは、フレーム１〜Ｎのシーケンスと見做され得る。本発明の実施例によるシステムは、シーケンスを復号化して圧縮ビットストリームを生成し得る。そのビットストリームは、それをチャンク１〜Ｎにセグメント化することによりフォーマットされる。各ビデオ・フレームnは、対応するチャンクnを有する。

各チャンクは、本発明の実施例によるデコーダがビデオ・フレームnを復号化するに十分な情報を、チャンクnがチャンク1〜n-1と共に含むまで、ビットストリームからのビットをそのチャンクnに追加することにより生成される。ビデオ・フレームnを生成するに十分な情報がチャンク1〜n-1に含まれた場合、本発明の実施例によるエンコーダはマーカ・チャンクを含み得る。一実施例においてそのマーカ・チャンクは、コード化されていないPフレームであって先行フレームと同一のタイミング情報を備えたPフレームである。

３．６，「subtitle」チャンクの生成方法
本発明の実施例によるエンコーダは、一連の標準的フォーマットの内のひとつのフォーマットでサブタイトルを取り込んでから、そのサブタイトルをビットマップへと変換し得る。そのビットマップにおける情報は次に、ランレングス符号化方法を用いて圧縮される。ランレングス符号化されたビットマップはフォーマットされてチャンクとされるが、これは、そのチャンク内に含まれた特定サブタイトルに対する開始時間および停止時間に関する情報も含んでいる。幾つかの実施例においては、画面上におけるサブタイトルの色、サイズおよび位置に関する情報もチャンク内に含まれ得る。チャンクは、サブタイトルに対するパレットを設定するサブタイトルトラックであってそのパレットが変更されたことを表すサブタイトルトラックへと含まれ得る。サブタイトルのテキストを生成するためには、標準的なサブタイトル・フォーマットでサブタイトルを生成し得る任意のアプリケーションが使用され得る。代替的に、ユーザにより入力されたテキストを直接的にサブタイトル情報へと変換するソフトウェアが使用され得る。

３．７．交互配置方法
上述のチャンクの全てをインタリーバが一旦受信したなら、そのインタリーバはマルチメディア・ファイルを構築する。マルチメディア・ファイルの構築は、「CSET」チャンク、「INFO」リスト・チャンク、「hdrl」チャンク、「movi」リスト・チャンクおよびidxlチャンクを生成する段階を包含し得る。これらのチャンクを生成してマルチメディア・ファイルを生成する本発明の実施例による方法は、以下に記述される。

３．７．１．「CSET」チャンクの生成方法
上述された如く「CSET」チャンクは選択的であり、かつ、AVIコンテナ・フォーマット仕様に従いインタリーバにより生成され得る。

３．７．２．「INFO」リスト・チャンクの生成方法
上述された如く「INFO」リスト・チャンクは選択的であり、かつ、AVIコンテナ・フォーマット仕様に従いインタリーバにより生成され得る。

３．７．３．「hdrl」リスト・チャンクの生成方法
「hdrl」リスト・チャンクは、インタリーバに対して提供される種々のチャンクにおける情報に基づき、そのインタリーバにより生成される。「hdrl」リスト・チャンクは、参照されたチャンクのリスト内の箇所を参照する。一実施例において「hdrl」リスト・チャンクは、リファレンスを確立するためにファイル・オフセットを使用する。

３．７．４．「movi」リスト・チャンクの生成方法
上述された如く「movi」リスト・チャンクはオーディオ、ビデオおよびサブタイトルトラックを符号化して「オーディオ」、「ビデオ」および「subtitle」チャンクを生成してからこれらのチャンクを交互配置することにより生成される。幾つかの実施例において「movi」リスト・チャンクは、デジタル著作権管理情報も含み得る。

３．７．４．１．ビデオ／オーディオ／サブタイトルの交互配置方法
オーディオ、ビデオおよびサブタイトル・チャンクを交互配置するために、種々の規則が使用され得る。典型的にインタリーバは、ビデオおよびオーディオ・トラックの各々に対して所定数の待ち行列（queue）を確立する。そのインタリーバは、どの待ち行列が出力ファイルに書き込まれるべきかを決定する。待ち行列選択は、最低数の被書き込み交互配置期間を有する待ち行列から書き込むことにより、交互配置期間に基づき得る。インタリーバは、チャンクがファイルに対して書き込まれ得る前に、待ち行列内に存在する交互配置期間全体を待機すべきこともある。

一実施例において、生成された「オーディオ」、「ビデオ」および「subtitle」チャンクは、当該「ビデオ」チャンクが対応するビデオ・フレームに関する情報を含む「ビデオ」チャンクに先立ち「オーディオ」および「subtitle」チャンクがファイル内に配置される様に交互配置される。他の実施例において「オーディオ」および「subtitle」チャンクは、それらが対応する「ビデオ」チャンクの後に配置され得る。「オーディオ」、「ビデオ」および「subtitle」チャンクの箇所間の時間差は、デバイスを再生するために使用されるプレーヤのバッファ能力に大きく依存する。バファリングが制限されもしくは未知である実施例においてインタリーバは、「オーディオ」および「subtitle」チャンクが「ビデオ」チャンクの間に配置される如く「オーディオ」、「ビデオ」および「subtitle」チャンクを交互配置し、その場合、「オーディオ」および「subtitle」チャンクの直後に追随する「ビデオ」チャンクは、そのオーディオもしくはサブタイトルに対応する最初のビデオ・フレームを含む。

３．７．４．２．DRM情報の生成方法
マルチメディア・ファイルのビデオ内容を保護すべくDRMが使用される実施例において、DRM情報はビデオ・チャンクの符号化と同時的に生成され得る。各チャンクが生成されるにつれ、そのチャンクは暗号化され得ると共に、ビデオ・チャンクの暗号化に関する情報を含むDRMチャンクが生成され得る。

３．７．４．３．DRM情報の交互配置方法
本発明の実施例によるインタリーバは、ビデオ・チャンクに先立ち、ビデオ・チャンクの暗号化に関する情報を含むDRMチャンクを交互配置する。一実施例において、ビデオ・チャンクnに対するDRMチャンクはビデオ・チャンクn-1およびビデオ・チャンクnの間に配置される。他の実施例において、ビデオ・チャンクnの前後におけるDRMの間隔は、マルチメディア・ファイルを復号化するデバイス内に配備されたバファリングの量に依存する。

３．７．５．「idxl」チャンクの生成方法
「movi」チャンクが生成されたなら、「idxl」チャンクの生成は単純なプロセスである。「idxl」チャンクは、「movi」リスト・チャンク内における各「data」チャンクの箇所を読み取ることで生成される。この情報は、「data」チャンクから読み取られた情報であってその「data」チャンクが属するトラックに関する情報と、その「data」チャンクの内容とに対して組み合わされる。この情報の全ては次に、上述のフォーマットのいずれであれ、情報を表すべく使用されているフォーマットに対して適切な様式で「idxl」チャンク内に挿入される。

４．マルチメディア・ファイルの送信および配信
マルチメディア・ファイルが生成されたなら、そのファイルは種々のネットワークの内の任意のネットワークに亙り配信され得る。多くの実施例において特に、マルチメディア・プレゼンテーションおよびメニューを生成するために必要な要素は単一ファイル内に含まれるという事実により、情報の転送が簡素化される。幾つかの実施例においてマルチメディア・ファイルは、そのマルチメディア・ファイルの内容を復号化するに必要な情報とは別体的に配信され得る。

一実施例においてマルチメディア内容は、第１サーバに提供されると共に、符号化されて本発明によるマルチメディア・ファイルを生成する。そのマルチメディア・ファイルは次に、第１サーバまたは第２サーバのいずれかに配置され得る。他の実施例においては、第１サーバ、第２サーバまたは第３サーバにDRM情報が配置され得る。一実施例において第１サーバは、符号化されたマルチメディア・ファイルの箇所を確認すべく、および／または、DRM情報の箇所を確認すべく、照会され得る。

５．マルチメディア・ファイルの復号化方法
本発明の実施例によるマルチメディア・ファイルからの情報は、適切なソフトウェアと、マルチメディア・ファイルから情報をアクセスすべくハード結線された専用プレーヤまたはAVIファイルを解析し得る他の任意のデバイスとを用いて構成されたコンピュータによりアクセスされ得る。幾つかの実施例においてデバイスは、マルチメディア・ファイル内の全ての情報にアクセスし得る。他の実施例においてデバイスは、本発明の実施例によるマルチメディア・ファイル内の全ての情報にアクセスし得なくても良い。特定実施例においてデバイスは、上述の情報であってAVIファイル・フォーマットにおいて仕様を定められていないチャンク内に記憶された情報のいずれにもアクセスし得ない。情報の全てがアクセスはされ得ない実施例において、当該デバイスは典型的に、そのデバイスにより認識されないチャンクを切り捨てる。

典型的に、本発明の実施例によるマルチメディア・ファイルに含まれた情報にアクセスし得るデバイスは、多数の機能を実施し得る。そのデバイスは、ビデオの表示を含むマルチメディア・プレゼンテーションを視覚的ディスプレイ上に表示し、可能的には多数のオーディオ・トラックの内のひとつのトラックからのオーディオをオーディオ・システム上に生成し、かつ、可能的には多数のサブタイトルトラックの内のひとつのトラックからのサブタイトルを表示し得る。幾つかの実施例は、付随するオーディオおよび／またはビデオを再生する一方、視覚的ディスプレイ上にメニューも表示し得る。これらの表示メニューは、選択可能なボタン、プルダウン・メニューおよび下位メニューなどの特徴により、インタラクティブである。一定の実施例においてメニュー項目は、現在においてアクセスされているマルチメディア・ファイル以外のオーディオ／ビデオ・コンテンツを指し示し得る。外部コンテンツは、マルチメディア・ファイルにアクセスしているデバイスに対してローカル的に配置され得るか、または、それはローカル・エリア・ネットワーク、広域ネットワークまたは公衆回線網などを介して遠隔的に配置され得る。また多くの実施例は、単一もしくは複数のマルチメディア・ファイル内に含まれる「メタデータ」、または、ひとつ以上のマルチメディア・ファイルにより参照された「メタデータ」に従い、ひとつ以上のマルチメディア・ファイルを検索することも可能である。

５．１．マルチメディア・プレゼンテーションの表示
本発明の実施例によるマルチメディア・ファイルの能力であって複数のオーディオ・トラック、複数のビデオ・トラックおよび複数のサブタイトルトラックをサポートする能力が与えられたなら、ビデオ、オーディオおよび／またはサブタイトルを組み合わせたマルチメディア・ファイルを用いるマルチメディア・プレゼンテーションを表示するためには、視覚的メニュー・システムもしくはプルダウン・メニュー・システム（その動作は以下で論じられる）により、または、マルチメディア・プレゼンテーションを生成すべく使用されるデバイスの既定設定を介し、特定のオーディオ・トラック、ビデオ・トラックおよび／またはサブタイトルトラックを選択する必要があり得る。オーディオ・トラック、ビデオ・トラックおよび可能的にはサブタイトルトラックが選択されたなら、マルチメディア・プレゼンテーションの表示が進展し得る。

図４．０．には、マルチメディア・ファイルからＤＲＭを含む必要なマルチメディア情報を位置決定すると共にマルチメディア情報を表示する本発明の実施例によるプロセスが示される。処理６２０は、ＤＲＭヘッダを復号化するに必要な暗号化キーを獲得（６２２）する段階を含む。暗号化キーは次に、ＤＲＭヘッダを復号化（６２４）すべく使用され、かつ、第１のＤＲＭチャンクがマルチメディア・ファイルの「ｍｏｖｉ」リスト・チャンク内で検索（６２６）される。「ＤＲＭ」チャンクを復号化するに必要な暗号化キーは「ＤＲＭ」ヘッダ内のテーブルから獲得（６２８）され、その暗号化キーは、暗号化されたビデオ・チャンクを復号化すべく用いられる。次に、必要とされるオーディオ・チャンクおよびビデオ・チャンクに付随する一切の必要なサブタイトル・チャンクが復号化（６３０）され、かつ、オーディオ、ビデオおよび一切のサブタイトル情報はディスプレイおよび音響システムを介して提示される（６３２）。

幾つかの実施例において、選択されたオーディオ・トラックはステレオまたはサラウンド音響オーディオを提供する多重チャネルを含み得る。サブタイトルトラックが表示されるべく選択されたとき、先行ビデオはサブタイトルを含んでいたか否かに関する決定が為され得る（この決定は、現在において復号化されたビデオ・フレームに亙り表示されるべきサブタイトル情報を含んでいた先行「subtitle」チャンクを識別するという結果を達成する種々の様式の内の任意の様式で為され得る）。もし先行サブタイトルがサブタイトルを含んでおりかつそのサブタイトルに対するタイミング情報がそのサブタイトルは現在のフレームと共に表示されるべきことを表すなら、そのサブタイトルは、復号化されたビデオ・フレーム上にスーパーインポーズされる。先行フレームがサブタイトルを含んでおらず、または、先行フレーム上のサブタイトルに対するタイミング情報は、現在復号化されたフレームと組み合わせてそのサブタイトルが表示されてはならないことを表すなら、選択されたサブタイトルトラックに対する「subtitle」チャンクが探索される。もし「subtitle」チャンクが位置決定されたなら、そのサブタイトルは、復号化されたビデオにスーパーインポーズされる。（スーパーインポーズされた一切のサブタイトルを含む）ビデオは次に、付随するオーディオと共に表示される。

図４．０．の考察を参照するとプロセスは、何らかの付加的なＤＲＭチャンクが在るか否かを決定（６３４）する。もし在れば、次のＤＲＭチャンクが位置決定（６２６）され、そのプロセスは付加的なＤＲＭチャンクが無くなるまで継続する。その時点において、オーディオ、ビデオおよび／またはサブタイトルトラックのプレゼンテーションは完了（６３６）する。

幾つかの実施例においてデバイスは、本発明によるマルチメディア・ファイルの「hdrl」チャンク内に含まれた情報を用い、マルチメディア情報の特定部分（たとえば、映画の特定シーンであって特定の付随オーディオ・トラックおよび選択的には特定の付随サブタイトルトラックなど）を探索し得る。多くの実施例において、「ビデオ（video）」チャンク、「オーディオ（audio）」チャンクおよび／または「サブタイトル（subtitle）」チャンクの復号化は、他のタスクと並行して実施され得る。

マルチメディア・ファイルからの情報にアクセスし得ると共に特定のオーディオ・トラックおよび／または特定のサブタイトルトラックと組み合わせてビデオを表示し得るデバイスの例は、ソフトウェアを用いて上述の様式で構成されたコンピュータである。別の例は、これらの機能を含むコーデックを備えたＤＶＤプレーヤである。他の実施例において、（意図的であれ任意的であれ）特定メディア・トラックに対応する「data」チャンクを検索もしくは選択し、かつ、プレゼンテーションのためにこれらのトラックを復号化すべく構成された任意のデバイスは、本発明の実施方法に係るマルチメディア・ファイルを用いてマルチメディア・プレゼンテーションを生成し得る。

幾つかの実施例においてデバイスは、マルチメディア・ファイルからの情報を、外部ファイルからのマルチメディア情報と組み合わせて再生し得る。典型的に斯かるデバイスは、上述の形式のマルチメディア・ファイルにおいて参照されたローカル・ファイルからのオーディオ・トラックもしくはサブタイトルトラックを調達することにより、それを行う。参照されたファイルがローカル的には記憶されておらず、かつ、デバイスが、デバイスが記憶された箇所に対してネットワークされていれば、そのデバイスはファイルのローカル・コピーを獲得し得る。デバイスは次に両方のファイルにアクセスし、マルチメディアの種々のトラックが異なるファイル・ソースから供給されるというビデオ、オーディオおよび（必要であれば）サブタイトルのパイプラインを確立する。

５．２．メニューの生成
図４．１．には、本発明の実施例によるデコーダが示される。デコーダ６５０は、本発明の実施例によるマルチメディア・ファイル６５２をデマルチプレクサ６５４に対して提供することにより、そのファイルを処理する。デマルチプレクサはマルチメディア・ファイルから「DMNU」チャンクを抽出すると共に、その「DMNU」チャンクから全ての「LanguageMenus」チャンクを抽出し、それらをメニュー・パーサ６５６に対して提供する。デマルチプレクサはまた、「DMNU」チャンクから全ての「Media」チャンクも抽出し、それらをメディア・レンダラ（media renderer）６５８に対して提供する。メニュー・パーサ６５６は、「LanguageMenus」チャンクからの情報を解析することで、その「LanguageMenus」チャンクにおいて定義されたメニュー構造を表す状態マシンを構築する。メニュー構造を表す状態マシンは、ユーザに対する表示を提供すべくかつユーザの命令に応答すべく使用され得る。状態マシンは、メニュー状態コントローラ６６０に対して提供される。そのメニュー状態コントローラは、メニュー状態マシンの現在状態を追尾すると共に、ユーザから命令を受ける。ユーザからの命令は、状態遷移を引き起こし得る。ユーザに対して提供される初期表示、および、表示に対する一切の更新であってメニュー状態遷移を伴う更新は、メニュー・プレーヤ・インタフェース662を用いて制御され得る。メニュー・プレーヤ・インタフェース６６２は、メニュー状態コントローラおよびメディア・レンダラに対して接続され得る。メニュー・プレーヤ・インタフェースはメディア・レンダラに対し、メディア・チャンクからどのメディアが抽出されかつそのメディア・レンダラに接続されたプレーヤ６６４を介してユーザに対して提供されるべきかを指示する。ユーザはプレーヤに対し、キーボード、マウスまたはリモコンなどの入力デバイスを用いて指示を与え得る。概略的にマルチメディア・ファイルはユーザに対して最初に表示されるメニューを決定し、かつ、ユーザの指示は初期メニューの生成に続いて表示されるオーディオおよびビデオを決定する。図４．１．に示されたシステムは、コンピュータおよびソフトウェアを用いて実現され得る。他の実施例においてシステムは、機能固有集積回路、または、ソフトウェアおよびファームウェアの組み合わせを用いて実現され得る。

図４．２．には、本発明の実施例によるメニューの例が示される。メニュー表示６７０は、４個のボタンエリア６７２と、タイトル６７６を含むバックグラウンド・ビデオ６７４と、ポインタ６７８とを含む。メニューは、（図示しない）バックグラウンド・オーディオも含む。表示により生成される視覚的効果は外面的とされ得る。各ボタンの視覚的外観は典型的にはバックグラウンド・ビデオの一部であり、かつ、ボタン自体は、バックグラウンド・ビデオの単なる定義領域であってポインタにより起動されたときにその領域に関係付けられた特定動作を有するという定義領域である。ポインタは典型的にはオーバレイである。

図４．３．は、図４．２．に示された表示における全ての情報のソースを概念的に示している。バックグラウンド・ビデオ６７４は、メニュー・タイトル、ボタンの視覚的外観、および、表示のバックグラウンドを含み得る。これらの要素および付加的要素の全ては、静止的または動画的に出現し得る。バックグラウンド・ビデオは、「メディアトラック（MediaTrack）」チャンク７００に含まれる情報であってビデオ・トラック７０２内におけるバックグラウンド・ビデオの箇所を表す情報を用いて抽出される。メニューに付随し得るバックグラウンド・オーディオ７０６は、オーディオ・トラック７１０内におけるそのバックグラウンド・オーディオの箇所を表す「メディアトラック（MediaTrack）」チャンク７０８を用いて検索され得る。上述された如く、ポインタ６７８はオーバレイ７１３の一部である。オーバレイ７１３は、バックグラウンド・ビデオの一部分であってボタンとして現れる一部分を強調すべく現れるグラフィックも含み得る。一実施例においてオーバレイ７１３は、オーバレイトラック７１４内におけるそのオーバレイの箇所を表す「MediaTrack」チャンク７１２を用いて獲得される。メニューがユーザと対話する様式は、ボタンの各々に関係付けられた（図示しない）「Action」チャンクにより定義される。図示実施例においては、「PlayAction」チャンク７１６が示される。その「PlayAction」チャンクは、マルチメディア・ファイル内に含まれたマルチメディア・プレゼンテーション（すなわちオーディオ、ビデオ、および、可能的にはサブタイトルトラック）内のシーンを間接的に参照する（「PlayAction」チャンクにより参照される他のチャンクは示されない）。「PlayAction」チャンク７１６は最終的に、番組トラック内のシーンを表す「MediaTrack」チャンク７１８を用いてそのシーンを参照する。選択されたまたは既定のオーディオ・トラックの箇所、および、可能的にはサブタイトルトラックも参照される。

ユーザが入力デバイスを用いて命令を入力するにつれて表示は、ボタンエリアの選択に応じて更新されるだけでなく、単にボタンエリア内に配置されつつあるポインタによっても更新され得る。で論じられた如く、メニューを生成すべく使用されるメディア情報の典型的には全てが、マルチメディア・ファイル内、より詳細には「DMNU」チャンク内に配置される。但し他の実施例において、情報はファイル内の他の箇所、および／または、別のファイル内に配置され得る。

５．３．メタデータのアクセス
「メタデータ」は、情報を表す標準化方法である。「メタデータ」の標準化性質によれば、データは自動的プロセスによりアクセスされて理解され得る。一実施例において「メタデータ」は、抽出されると共に視認のためにユーザに対して提供される。幾つかの実施例によれば、サーバ上のマルチメディア・ファイルが検査されることで、ユーザの鑑賞習慣および鑑賞選好性に関する情報が提供され得る。斯かる情報はソフトウェア・アプリケーションにより使用されることで、ユーザが鑑賞を楽しみ得る他のマルチメディア・ファイルが推奨され得る。一実施例において推奨は、他のユーザのサーバ上に含まれたマルチメディア・ファイルに基づき得る。他の実施例においてユーザはマルチメディア・ファイルを要求することが可能であり、そのファイルは、種々の箇所におけるマルチメディア・ファイルの「メタデータ」を検査する検索エンジンおよび／またはインテリジェント・エージェントにより位置決定され得る。これに加えてユーザは、マルチメディア・プレゼンテーションの異なるバージョンの各々が符号化された様式に関する「メタデータ」に基づき、種々のマルチメディア・ファイルの中から特定のマルチメディア・プレゼンテーションを含むものを選択し得る。

幾つかの実施例において、本発明の実施例によるマルチメディア・ファイルの「メタデータ」は、目録を作成する目的で、または、ファイルの内容にアクセスする単純なメニューを生成するためにアクセスされ得る。

上記の記述は発明の多くの特定実施例を含むが、これらは発明の有効範囲に対する制限と解釈されるべきでなく、寧ろ発明のひとつの実例と解釈されるべきである。たとえば本発明の実施例によるマルチメディア・ファイルは、単一のマルチメディア・プレゼンテーションまたは複数のマルチメディア・プレゼンテーションを含み得る。これに加え、斯かるファイルはひとつ以上のメニューと、任意の種々の異なる形式の「メタデータ」を含み得る。故に発明の有効範囲は、図示された実施例によってではなく、添付の各請求項および他の均等物により決定されるべきである。

Claims (169)

1. 複数の符号化ビデオトラックを有することを特徴とするマルチメディアファイル。
2. 前記マルチメディアファイルは、連結した複数の「ＲＩＦＦ」チャンクを有する請求項２に記載のマルチメディアファイル。
3. 各符号化ビデオトラックは、別個の「ＲＩＦＦ」チャンク内に含まれる請求項２に記載のマルチメディアファイル。
4. 前記ビデオは、心理視覚的強化を用いて符号化される請求項１に記載のマルチメディアファイル。
5. 各ビデオトラックは、それに対して関係付けられた少なくとも一つのオーディオトラックを有する請求項１に記載のマルチメディアファイル。
6. 前記各ビデオトラックは、「ＲＩＦＦ」チャンク内における一連の「ビデオ」チャンクとして符号化され、かつ、
   前記各ビデオトラックに付随するオーディオトラックは、関係付けられたビデオトラックの「ビデオ」チャンクを含む前記「ＲＩＦＦ」チャンク内に交互配置される一連の「オーディオ」チャンクとして符号化される請求項５に記載のマルチメディアファイル。
7. 前記各「ビデオ」チャンクは、ビデオトラックからビデオの単一フレームを生成すべく使用され得る情報を含み、かつ、
   前記各「オーディオ」チャンクは、「ビデオ」チャンクを用いて生成されるフレームに付随するオーディオトラックの部分からのオーディオ情報を含む請求項６に記載のマルチメディアファイル。
8. 前記「オーディオ」チャンクは前記「ＲＩＦＦ」チャンク内において対応する前記「ビデオ」チャンクの前に交互配置される請求項７に記載のマルチメディアファイル。
9. 複数のビデオトラックを符号化し、
   前記符号化ビデオトラックを連結し、かつ、
   連結された前記符号化ビデオトラックを単一ファイルへと書き込む、
   ように構成されるプロセッサを有するマルチメディアファイルを符号化するシステム。
10. 前記プロセッサは、前記各ビデオトラックが別個の「ＲＩＦＦ」チャンク内に含まれるように前記ビデオトラックを符号化すべく構成される請求項９に記載のシステム。
11. 前記プロセッサは、心理視覚的強化を用いて前記ビデオを符号化すべく構成される請求項９に記載のシステム。
12. 各ビデオトラックは、それに関係付けられた少なくとも一つのオーディオトラックを有する請求項９に記載のシステム。
13. 前記プロセッサは、
    前記各ビデオトラックを、「ＲＩＦＦ」チャンク内における一連の「ビデオ」チャンクとして符号化し、かつ、
    前記各ビデオトラックに付随する少なくとも一つのオーディオトラックを、前記関係付けられたビデオトラックの「ビデオ」チャンクを含む「ＲＩＦＦ」チャンク内に交互配置された一連の「オーディオ」チャンクとして符号化するように構成される請求項１２に記載のマルチメディアファイル。
14. 前記プロセッサは、
    前記ビデオトラックを、各「ビデオ」チャンクが、ビデオトラックからビデオの単一フレームを生成すべく使用され得る情報を含むように符号化し、かつ、
    ビデオトラックに関係付けられた前記オーディオトラックを、各「オーディオ」チャンクが、該ビデオトラックから生成された「ビデオ」チャンクを用いて生成されたフレームに付随する前記オーディオトラックの部分からのオーディオ情報を含むように符号化するように構成される請求項１３に記載のマルチメディアファイル。
15. 前記プロセッサは、前記各「オーディオ」チャンクを前記「ＲＩＦＦ」チャンク内の対応する前記「ビデオ」チャンク前に交互配置するように構成される請求項１４に記載のマルチメディアファイル。
16. マルチメディアファイルから情報を抽出すべく構成されたプロセッサを有し、
    前記プロセッサは、前記マルチメディアファイル内に含まれた符号化ビデオトラックの数に関する情報を抽出すべく構成される、
    複数の符号化ビデオトラックを含むマルチメディアファイルを復号化するシステム。
17. 前記プロセッサは、「ＲＩＦＦ」チャンク内で符号化ビデオトラックを検索するために構成される請求項１６に記載のシステム。
18. 第１の符号化ビデオトラックは、標準４ｃｃコードを有する第１「ＲＩＦＦ」チャンク内には含まれ、
    第２のビデオトラックは、特殊化４ｃｃコードを有する第２「ＲＩＦＦ」チャンク内には含まれ、かつ、
    前記特殊化４ｃｃコードは、その特殊化４ｃｃコードの最後の２個のキャラクタとして、標準４ｃｃコードの最初の２個のキャラクタを有する請求項１７に記載のシステム。
19. 各符号化ビデオトラックは別個の「ＲＩＦＦ」チャンク内に含まれる請求項１７に記載のシステム。
20. 復号化されたビデオトラックは、前記マルチメディアファイルを生成する際に符号化されたオリジナルのビデオトラックと類似する請求項１６に記載のシステム。
21. 前記復号化されたビデオトラックと前記オリジナルのビデオトラックとの間における相違点の少なくとも幾つかは、ビデオトラックの各フレームの暗い部分内に配置される請求項２０に記載のシステム。
22. 前記復号化されたビデオトラックと前記オリジナルのビデオトラックとの間における相違点の少なくとも幾つかは、ビデオトラックの速い動作シーンに配置される請求項２０に記載のシステム。
23. 各ビデオトラックは、それ自身に関係付けられた少なくとも一つのオーディオトラックを有する請求項１６に記載のシステム。
24. 前記プロセッサは、
    「ＲＩＦＦ」チャンク内の一連の「ビデオ」チャンクを復号化することによりビデオトラックからビデオを表示し、かつ、
    関係付けられたビデオトラックの「ビデオ」チャンクを含む「ＲＩＦＦ」チャンク内に交互配置された一連の「オーディオ」チャンクを復号化することにより、前記ビデオトラックに付随するオーディオトラックからオーディオを生成するように構成される請求項２３に記載のシステム。
25. 前記プロセッサは、
    前記ビデオトラックの単一フレームを生成するために、各「ビデオ」チャンクから抽出された情報を使用し、かつ、
    「ビデオ」チャンクを使用して生成されたフレームに付随する前記オーディオトラックの部分を生成するために、各「オーディオ」チャンクから抽出された情報を使用するように構成される請求項２４に記載のマルチメディアファイル。
26. 前記プロセッサは、前記「ＲＩＦＦ」チャンクにおいて前記「オーディオ」チャンクが関係付けられた「ビデオ」チャンクの前に、前記「オーディオ」チャンクを検索するように構成される請求項２５に記載のマルチメディアファイル。
27. 一連の符号化ビデオ・フレームと、
    前記符号化ビデオ・フレームの間に交互配置された符号化オーディオとを備え、
    前記符号化オーディオは、オーディオ情報の２つ以上のトラックを含むことを特徴とするマルチメディアファイル。
28. 前記オーディオ情報のトラックの内の少なくとも一つのトラックは、複数のオーディオチャネルを含む請求項２７に記載のマルチメディアファイル。
29. 当該マルチメディアファイルに含まれたオーディオトラックの数を特定するヘッダ情報を更に有する請求項２７に記載のマルチメディアファイル。
30. 前記オーディオ情報のトラックの内の少なくとも一つのトラックに関する説明情報を含むヘッダ情報を更に有する請求項２７に記載のマルチメディアファイル。
31. 各符号化ビデオ・フレームは、符号化オーディオ情報により先行され、かつ、
    ビデオ・フレームに先行する符号化オーディオ情報は、前記符号化ビデオ・フレームに付随する各オーディオトラックの部分に対するオーディオ情報を含む請求項２７に記載のマルチメディアファイル。
32. 前記ビデオ情報は、当該マルチメディアファイル内にチャンクとして記憶される請求項２７に記載のマルチメディアファイル。
33. ビデオ情報の各チャンクは、ビデオの単一フレームを含む請求項３２に記載のマルチメディアファイル。
34. 前記オーディオ情報は当該マルチメディアファイル内にチャンクとして記憶され、
    ２つの別個のオーディオトラックからのオーディオ情報はオーディオ情報の単一チャンク内には含まれない、請求項３３に記載のマルチメディアファイル。
35. 前記ビデオ・チャンクは、前記オーディオトラックの各々からの少なくとも一つのオーディオ・チャンクにより分離される請求項３４に記載のマルチメディアファイル。
36. 前記ビデオ・チャンクを分離する前記オーディオ・チャンクは、そのオーディオ・チャンクに追随するビデオ・チャンク内に含まれたビデオ情報に付随するオーディオトラックの部分に対するオーディオ情報を含む請求項３５に記載のマルチメディアファイル。
37. ビデオトラックを符号化し、
    複数のオーディオトラックを符号化し、
    前記ビデオトラックからの情報を、前記複数のオーディオトラックからの情報と交互配置し、かつ、
    交互配置されたビデオおよびオーディオ情報を単一ファイルへと書き込む、
    ように構成されるプロセッサを有する、マルチメディアファイルを符号化するシステム。
38. 前記オーディオトラックの内の少なくとも一つのオーディオトラックは複数のオーディオチャネルを含む請求項３７に記載のシステム。
39. 前記プロセッサは、更に、前記符号化オーディオトラックの数を特定するヘッダ情報を符号化し、かつ、そのヘッダ情報を前記単一ファイルに書き込みむべく構成される請求項３７に記載のシステム。
40. 前記プロセッサは、更に、前記符号化オーディオトラックの内の少なくとも一つに関する説明情報を特定するヘッダ情報を符号化し、かつ、そのヘッダ情報を前記単一ファイルに書き込むべく構成される、請求項３７に記載のシステム。
41. 前記プロセッサは、前記ビデオトラックをビデオ情報のチャンクとして符号化する、請求項３７に記載のシステム。
42. 前記プロセッサは、各オーディオトラックをオーディオ情報の一連のチャンクとして符号化する請求項４１に記載のシステム。
43. オーディオ情報の各チャンクは、単一のオーディオトラックからのオーディオ情報を含む請求項４２に記載のシステム。
44. 前記プロセッサは、ビデオ情報のチャンク間にオーディオ情報のチャンクを交互配置すべく構成される請求項４３に記載のシステム。
45. 前記プロセッサは、「ビデオ」チャンクにおけるビデオ情報に付随する各オーディオトラックの部分を「オーディオ」チャンク内に符号化すべく構成され、かつ、
    前記プロセッサは、前記各「ビデオ」チャンクが、その「ビデオ」チャンクに含まれるビデオ情報に付随するオーディオトラックの各々からのオーディオ情報を含む「オーディオ」チャンクにより先行されるように、前記「ビデオ」チャンクで前記「オーディオ」チャンクを交互配置するために構成される請求項４４に記載のシステム。
46. 前記プロセッサは、各ビデオ・チャンク内にビデオの単一フレームが含まれるように前記ビデオトラックを符号化すべく構成される請求項４５に記載のシステム。
47. 前記プロセッサは、汎用プロセッサである請求項４５に記載のシステム。
48. 前記プロセッサは、専用回路である請求項４５に記載のシステム。
49. マルチメディアファイルから情報を抽出すべく構成されたプロセッサを備え、
    前記プロセッサは、前記マルチメディアファイル内に含まれるオーディオトラックの数に関する情報を抽出すべく構成される複数のオーディオトラックを含むマルチメディアファイルを復号化するシステム。
50. 前記プロセッサは、前記複数のオーディオトラックから単一のオーディオトラックを選択すべく構成され、
    前記プロセッサは、前記選択されたオーディオトラックからのオーディオ情報を復号化すべく構成される請求項４９に記載のシステム。
51. 前記オーディオトラックの内の少なくとも一つは、複数のオーディオチャネルを含む、請求項４９に記載のシステム。
52. 前記プロセッサは、前記マルチメディアファイルにおけるヘッダから、前記オーディオトラックの内の少なくとも一つのオーディオトラックに関する説明情報を含む情報を抽出すべく構成される請求項４９に記載のシステム。
53. ネットワークと、
    マルチメディアファイルを含むと共に、サーバを介して前記ネットワークに対して接続された記憶デバイスと、
    前記ネットワークに接続されたクライアントとを有し、
    前記クライアントは、前記サーバからの前記マルチメディアファイルの転送を要求することができ、かつ、
    前記マルチメディアファイルは、少なくとも一つのビデオトラックと、そのビデオトラックに付随する複数のオーディオトラックとを含む、
    マルチメディア情報を通信するシステム。
54. 一連の符号化ビデオ・フレームと、
    前記符号化ビデオ・フレーム間に交互配置される少なくとも一つの符号化サブタイトルトラックとを有する、
    ことを特徴とするマルチメディアファイル。
55. 前記少なくとも一つの符号化サブタイトルトラックは、複数の符号化サブタイトルトラックを有する請求項５４に記載のマルチメディアファイル。
56. 当該マルチメディアファイルに含まれた符号化サブタイトルトラックの数を特定するヘッダ情報を更に有する請求項５４に記載のマルチメディアファイル。
57. 前記符号化サブタイトルトラックの内の少なくとも一つに関する説明情報を含むヘッダ情報を更に有する請求項５４に記載のマルチメディアファイル。
58. 各サブタイトルトラックは一連のビットマップを含む請求項５４に記載のマルチメディアファイル。
59. 各サブタイトルトラックは一連の圧縮ビットマップを含む請求項５８に記載のマルチメディアファイル。
60. 各ビットマップはランレングス符号化方法を用いて圧縮される請求項５９に記載のマルチメディアファイル。
61. 前記一連の符号化ビデオ・フレームは、一連のビデオ・チャンクとして符号化され、
    各符号化サブタイトルトラックは、一連のサブタイトル・チャンクとして符号化され、 各サブタイトル・チャンクは、表示上にテキストとして表され得る情報を含む請求項５４に記載のマルチメディアファイル。
62. 各サブタイトル・チャンクは、単一のサブタイトルに関する情報を含む請求項６１に記載のマルチメディアファイル。
63. 各サブタイトル・チャンクは、サブタイトルがスーパーインポーズされるべきビデオ・シーケンスの部分に関する情報を含む請求項６２に記載のマルチメディアファイル。
64. 各サブタイトル・チャンクは、サブタイトルが配置されるべき表示の部分に関する情報を含む請求項６２に記載のマルチメディアファイル。
65. 各サブタイトル・チャンクは、サブタイトルの色に関する情報を含む請求項６２に記載のマルチメディアファイル。
66. 色に関する前記情報は、色パレートを含む請求項６５に記載のマルチメディアファイル。
67. 前記サブタイトル・チャンクは、第１色パレートに関する情報を含む第１サブタイトル・チャンクと、該第１色パレートに関する情報に成り代わる第２色パレートに関する情報を含む第２サブタイトル・チャンクとを有する請求項６６に記載のマルチメディアファイル。
68. ビデオトラックを符号化し、
    少なくとも一つのサブタイトルトラックを符号化し、
    前記ビデオトラックからの情報を、前記少なくとも一つのサブタイトルトラックからの情報と交互配置し、かつ、
    交互配置されたビデオおよびサブタイトル情報を単一ファイルに書き込む、
    ように構成されたプロセッサを有するマルチメディアファイルを符号化するシステム。
69. 前記少なくとも一つのサブタイトルトラックは、複数のサブタイトルトラックを有する請求項６８に記載のシステム。
70. 前記プロセッサは、更に、前記マルチメディアファイルに含まれたサブタイトルトラックの数を特定するヘッダ情報を符号化し、かつ、前記単一ファイルに書き込むべく構成される請求項６８に記載のシステム。
71. 前記プロセッサは、更に、前記サブタイトルトラックの内の少なくとも一つについての説明情報を符号化し、かつ、前記単一ファイルに書き込むべく構成される請求項６８に記載のシステム。
72. 前記ビデオトラックはビデオ・チャンクとして符号化され、かつ、
    前記少なくとも一つのサブタイトルトラックの各々は、サブタイトル・チャンクとして符号化される請求項６８に記載のシステム。
73. 前記サブタイトル・チャンクの各々は、前記ビデオトラックの一部に付随する単一のサブタイトルを含み、
    インタリーバは、サブタイトル・チャンク内のサブタイトルが付随するビデオトラックの部分を含むビデオ・チャンクに先行して、各サブタイトル・チャンクを交互配置すべく構成される請求項７２に記載のシステム。
74. 前記プロセッサは、前記サブタイトルをビットマップとして符号化することによりサブタイトル・チャンクを生成すべく構成される請求項７２に記載のシステム。
75. 前記サブタイトルは、圧縮ビットマップとして符号化される請求項７２に記載のシステム。
76. 前記ビットマップは、ランレングス符号化方法を用いて圧縮される請求項７５に記載のシステム。
77. 前記プロセッサは、各サブタイトル・チャンク内に、サブタイトルがスーパーインポーズされるべきビデオ・シーケンスの部分に関する情報を含める請求項７６に記載のシステム。
78. 前記プロセッサは、各サブタイトル・チャンク内に、サブタイトルが配置されるべき表示の部分に関する情報を含める請求項７３に記載のシステム。
79. 前記プロセッサは、各サブタイトル・チャンク内に、サブタイトルの色に関する情報を含める請求項７３に記載のシステム。
80. 前記色に関する情報は、色パレートを含む請求項７３に記載のシステム。
81. 前記サブタイトル・チャンクは、第１色パレートに関する情報を含む第１サブタイトル・チャンクと、該第１色パレートに関する情報に成り代わる第２色パレートに関する情報を含む第２サブタイトル・チャンクとを有する請求項８０に記載のシステム。
82. マルチメディアファイルから情報を抽出すべく構成されるプロセッサを有し、
    前記プロセッサは、少なくとも一つのサブタイトルトラックが在るか否かを決定するためマルチメディアファイルを検査するように構成されるマルチメディアファイルを復号化するシステム。
83. 前記少なくとも一つのサブタイトルトラックは、複数のサブタイトルトラックを有し、かつ、前記プロセッサは、前記マルチメディアファイル内におけるサブタイトルトラックの数を決定すべく構成される請求項８２に記載のシステム。
84. 前記プロセッサは、更に、サブタイトルトラックの数を特定するヘッダ情報を前記マルチメディアファイルから抽出すべく構成される請求項８２に記載のシステム。
85. 前記プロセッサは、更に、前記サブタイトルトラックの内の少なくとも一つのサブタイトルトラックについての説明情報を、前記マルチメディアファイルから抽出すべく構成される請求項８２に記載のシステム。
86. 前記マルチメディアファイルは、ビデオ・チャンクとして符号化された少なくとも一つのビデオトラックを含み、かつ、
    前記マルチメディアファイルは、サブタイトル・チャンクとして符号化された少なくとも一つのサブタイトルトラックを含む請求項８２に記載のマルチメディアファイルを復号化するシステム。
87. 各サブタイトル・チャンクは、単一のサブタイトルに関する情報を含む、請求項８６に記載のマルチメディアファイルを復号化するシステム。
88. 各サブタイトルは、前記サブタイトル・チャンク内においてビットマップとして符号化され、
    前記プロセッサは、前記ビデオトラックを復号化すべく構成され、かつ、
    前記プロセッサは、ビットマップを前記ビデオ・シーケンスの一部上にスーパーインポーズすることにより、表示のためのビデオのフレームを構築すべく構成される請求項８７に記載のマルチメディアファイルを復号化するシステム。
89. 前記サブタイトルは、圧縮ビットマップとして符号化され、かつ、
    前記プロセッサは、ビットマップを解凍すべく構成される請求項８８に記載のマルチメディアファイルを復号化するシステム。
90. 前記プロセッサは、ランレングス符号化されたビットマップを解凍すべく構成される、請求項８９に記載のマルチメディアファイルを復号化するシステム。
91. 各サブタイトル・チャンクは、サブタイトルがスーパーインポーズされるべきビデオトラックの部分に関する情報を含み、かつ、
    前記プロセッサは、前記サブタイトル・チャンクにおける情報により指示される各ビデオ・フレーム上に前記サブタイトルの前記ビットマップをスーパーインポーズすることにより、表示のための一連のビデオ・フレームを生成すべく構成される請求項８８に記載のマルチメディアファイルを復号化するシステム。
92. 各サブタイトル・チャンクは、該サブタイトルが配置されるべきフレーム内の位置に関する情報を含み、かつ、
    前記プロセッサは、前記サブタイトル・チャンク内の情報により指示される各ビデオ・フレーム内の位置に前記サブタイトルをスーパーインポーズすべく構成される請求項８８に記載のマルチメディアファイルを復号化するシステム。
93. 各サブタイトル・チャンクは、前記サブタイトルの色に関する情報を含み、かつ、
    前記プロセッサは、前記サブタイトル・チャンク内の色情報により指示される単一もしくは複数の色で前記サブタイトルをスーパーインポーズすべく構成される請求項８８に記載のマルチメディアファイルを復号化するシステム。
94. 前記サブタイトル・チャンク内における前記色情報は、色パレートを含み、かつ、
    前記プロセッサは、前記サブタイトルの前記ビットマップにおいて使用される色情報を取得するために前記色パレートを用いて、前記サブタイトルをスーパーインポーズすべく構成される請求項９３に記載のマルチメディアファイルを復号化するシステム。
95. 前記サブタイトル・チャンクは、第１色パレートに関する情報を含む第１サブタイトル・チャンクと、第２色パレートに関する情報を含む第２サブタイトル・チャンクとを有し、かつ、
    前記プロセッサは、
    第１チャンクが処理された後に前記サブタイトルの前記ビットマップにおいて使用される色に関する情報を取得するために、第１色パレートを用いて、サブタイトルをスーパーインポーズすべく構成され、かつ、
    第２チャンクが処理された後にサブタイトルのビットマップにおいて使用される色に関する情報を取得するために、第２色パレートを用いて、サブタイトルをスーパーインポーズすべく構成される請求項９４に記載のシステム。
96. ネットワークと、
    マルチメディアファイルを含むと共に、サーバを介して前記ネットワークに対して接続された記憶デバイスと、
    前記ネットワークに接続されたクライアントとを有し、
    前記クライアントは、前記サーバからの前記マルチメディアファイルの転送を要求することができ、かつ、
    前記マルチメディアファイルは、少なくとも一つのビデオトラックと、そのビデオトラックに付随する少なくとも一つのサブタイトルトラックとを含むマルチメディア情報を通信するシステム。
97. 一連の符号化ビデオ・フレームと、
    符号化されたメニュー情報とを有することを特徴とするマルチメディアファイル。
98. 前記符号化されたメニュー情報は、チャンクとして記憶される請求項９７に記載のマルチメディアファイル。
99. 少なくとも２つの別個のメニュー情報の「メニュー」チャンクを更に有する請求項９８に記載のマルチメディアファイル。
100. 前記少なくとも２つの別個の「メニュー」チャンクは、少なくとも２つの別個の「ＲＩＦＦ」チャンクに含まれる請求項９９に記載のマルチメディアファイル。
101. 「メニュー」チャンクを含む第１「ＲＩＦＦ」チャンクは、標準４ｃｃコードを含むと共に、「メニュー」チャンクを含む第２「ＲＩＦＦ」チャンクは、特殊化４ｃｃコードを含み、前記標準４ｃｃコードの最初の２個のキャラクタは、前記特殊化４ｃｃコードの最後の２個のキャラクタとして現れる請求項１００に記載のマルチメディアファイル。
102. 少なくとも２つの別個の「ｍｅｎｕ」チャンクは、単一の「ＲＩＦＦ」チャンク内に含まれる請求項９９に記載のマルチメディアファイル。
103. 前記「メニュー」チャンクは、一連のメニューを記述するチャンクと、該一連のメニューに関係付けられたメディアを含む「ＭＲＩＦ」チャンクとを含む請求項９９に記載のマルチメディアファイル。
104. 前記「ＭＲＩＦ」チャンクは、ビデオトラック、オーディオトラックおよびオーバレイトラックを含むメディア情報を含む、請求項１０３に記載のマルチメディアファイル。
105. 一連のメニューを記述する前記チャンクは、
     メニュー・システム全体を記述するチャンクと、
     前記メニューを言語によりグループ化する少なくとも一つのチャンクと、
     個々のメニュー表示と、付随するバックグラウンド・オーディオとを記述する少なくとも一つのチャンクと、
     メニュー上のボタンを記述する少なくとも一つのチャンクと、
     画面上における前記ボタンの位置を記述する少なくとも一つのチャンクと、
     ボタンに関係付けられる種々な動作を記述する少なくとも一つのチャンクとを含む、
     請求項１０３に記載のマルチメディアファイル。
106. 第２ファイルに対するリンクを更に有し、
     符号化されたメニュー情報は、前記第２ファイル内に含まれる請求項９７に記載のマルチメディアファイル。
107. メニュー情報を符号化すべく構成されたプロセッサを備え、
     前記プロセッサは、符号化ビデオトラックおよび符号化メニュー情報を含むマルチメディアファイルを生成するようにも構成されるマルチメディアファイルを符号化するシステム。
108. 前記プロセッサは、
     前記メニューのオブジェクト・モデルを生成し、
     前記オブジェクト・モデルをコンフィグ・ファイルへと変換し、
     前記コンフィグ・ファイルをチャンクに解析し、
     メディア情報を含むＡＶＩファイルを生成し、
     前記ＡＶＩファイル内のメディアを「ＭＲＩＦ」チャンク内へと交互配置し、かつ、 「メニュー」チャンクを生成するために、前記解析されたチャンクを「ＭＲＩＦ」チャンクと連結するように構成される請求項１０７に記載のシステム。
109. 前記プロセッサは更に、第２の更に小さな「メニュー」チャンクを生成するために前記オブジェクト・モデルを使用すべく構成される請求項１０８に記載のシステム。
110. 前記プロセッサは、第２メニューを符号化すべく構成される請求項１０７に記載のシステム。
111. 前記プロセッサは、第１の符号化メニューを第１「ＲＩＦＦ」チャンクに挿入し、かつ、第２の符号化メニューを第２「ＲＩＦＦ」チャンクに挿入する請求項１１０に記載のシステム。
112. 前記プロセッサは、前記第１および第２の符号化メニューを単一の「ＲＩＦＦ」チャンク内に含める請求項１１０に記載のシステム。
113. 前記プロセッサは、第２ファイルにおける符号化メニューに対するリファレンスを、前記マルチメディアファイル内に挿入すべく構成される請求項１０７に記載のシステム。
114. マルチメディアファイルから情報を抽出すべく構成されたプロセッサを有し、
     前記プロセッサは、前記マルチメディアファイルが符号化されたメニュー情報を含むか否かを決定するために、前記マルチメディアファイルを検査すべく構成されるマルチメディアファイルを復号化するシステム。
115. 前記プロセッサは、「ＲＩＦＦ」チャンク内の「メニュー」チャンクからメニュー情報を抽出すべく構成される請求項１１４に記載のシステム。
116. 前記プロセッサは、前記「メニュー」チャンクに記憶されたビデオ情報を用いてメニュー表示を構築すべく構成される請求項１１５に記載のシステム。
117. 前記プロセッサは、前記「メニュー」チャンクに記憶されたオーディオ情報を用いてメニュー表示に付随するバックグラウンド・オーディオを生成すべく構成される請求項１１５に記載のシステム。
118. 前記プロセッサは、前記「メニュー」チャンクからのオーバレイを、前記「メニュー」チャンクからのビデオ情報に重ね合わせることによりメニュー表示を生成すべく構成される請求項１１５に記載のシステム。
119. ネットワークと、
     マルチメディアファイルを含むと共に、サーバを介して前記ネットワークに対して接続された記憶デバイスと、
     前記ネットワークに接続されたクライアントとを備え、
     前記クライアントは、前記サーバからの前記マルチメディアファイルの転送を要求することができ、かつ、
     前記マルチメディアファイルは、符号化されたメニュー情報を含む、
     マルチメディア情報を通信するシステム。
120. 一連の符号化ビデオ・フレームと、
     前記マルチメディアファイルについての符号化メタデータとを有し、
     前記符号化メタデータは、主部、述部、目的部および出典を有する少なくとも一つのステートメントを含む、
     マルチメディアファイル。
121. 前記主部は、前記メタデータにより記述されるファイル、項目、人物または組織を特定する情報を含む請求項１２０に記載のマルチメディアファイル。
122. 前記述部は、前記主部の特性を表す情報を含む請求項１２１に記載のマルチメディアファイル。
123. 前記目的部は、前記述部により特定された前記主部の特性を記述する情報を含む請求項１２２に記載のマルチメディアファイル。
124. 前記出典は、前記ステートメントのソースに関する情報を含む請求項１２３に記載のマルチメディアファイル。
125. 前記主部は、タイプおよび値を含むチャンクであり、
     前記値は、情報を含み、かつ、
     前記タイプは、前記チャンクがリソースであるか匿名ノードであるかを指示する請求項１２０に記載のマルチメディアファイル。
126. 前記述部は、タイプおよび値を含むチャンクであり、
     前記値は、情報を含み、かつ、
     前記タイプは、前記値情報が記述ＵＲＩであるか順序リスト・エントリであるかを指示する請求項１２０に記載のマルチメディアファイル。
127. 前記目的部は、タイプ、言語、データタイプおよび値を含むチャンクであり、
     前記値は、情報を含み、
     前記タイプは、前記値情報がＵＴＦ−８リテラル、リテラル整数またはリテラルＸＭＬデータであるかを指示し、
     前記データタイプは、前記値情報のタイプを指示し、かつ、
     前記言語は特定言語を指定する情報を含む請求項１２０に記載のマルチメディアファイル。
128. 前記出典は、タイプおよび値を含むチャンクであり、
     前記値は情報を含み、かつ、
     前記タイプは、前記値情報が前記ステートメントの出典であることを表す、請求項１２７に記載のマルチメディアファイル。
129. 前記符号化データの少なくとも一部は２値データとして表される請求項１２０に記載のマルチメディアファイル。
130. 前記符号化データの少なくとも一部は、６４ビットＡＳＣＩデータとして表される請求項１２０に記載のマルチメディアファイル。
131. 前記符号化データの少なくとも第１部分は、２値データとして表され、かつ、前記符号化データの少なくとも第２部分は第２フォーマットで表されたデータを含む付加的チャンクとして表される請求項１２０に記載のマルチメディアファイル。
132. 前記付加的チャンクは各々、単一断片のメタデータを含む請求項１３１に記載のマルチメディアファイル。
133. ビデオトラックを符号化すべく構成されたプロセッサを備え、
     前記プロセッサは、前記マルチメディアファイルに関するメタデータを符号化するようにも構成され、かつ、
     前記符号化メタデータは、主部、述部、目的部および出典を備える少なくとも一つのステートメントを含むマルチメディアファイルを符号化するシステム。
134. 前記主部は、前記メタデータにより記述されるファイル、項目、人物または組織を特定する情報を含む請求項１３３に記載のシステム。
135. 前記述部は、前記主部の特性を表す情報を含む請求項１３４に記載のシステム。
136. 前記目的部は、前記述部により特定された前記主部の特性を記述する情報を含む請求項１３５に記載のシステム。
137. 前記出典は前記ステートメントのソースに関する情報を含む、請求項１３６に記載のシステム。
138. 前記プロセッサは、前記主部を、タイプおよび値を含むチャンクとして符号化すべく構成され、
     前記値は、情報を含み、かつ、
     前記タイプは、チャンクがリソースであるか匿名ノードであるかを表す請求項１３３に記載のシステム。
139. 前記プロセッサは、前記述部を、タイプおよび値を含むチャンクとして符号化すべく構成され、
     前記値は情報を含み、かつ、
     前記タイプは、前記値情報が記述ＵＲＩであるか順序リスト・エントリであるかを指示する請求項１３３に記載のシステム。
140. 前記プロセッサは前記目的部を、タイプ、言語、データタイプおよび値を含むチャンクとして符号化すべく構成され、
     前記値は情報を含み、
     前記タイプは、前記値情報がＵＴＦ−８リテラル、リテラル整数またはリテラルＸＭＬデータであるかを指示し、
     データタイプは、前記値情報のタイプを指示し、かつ、
     前記言語は特定言語を指定する情報を含む請求項１３３に記載のシステム。
141. 前記プロセッサは、前記出典を、タイプおよび値を含むチャンクとして符号化すべく構成され、
     前記値は、情報を含み、かつ、
     前記タイプは、前記値情報が前記ステートメントの出典であることを指示する請求項１３３に記載のシステム。
142. 前記プロセッサは、更に、マルチメディアファイルに関する前記メタデータの少なくとも一部を２値データとして符号化すべく構成される請求項１３３に記載のシステム。
143. 前記プロセッサは、更に、前記マルチメディアファイルに関する前記メタデータの少なくとも一部を６４ビットＡＳＣＩデータとして符号化すべく構成される請求項１３３に記載のシステム。
144. 前記プロセッサは、更に、
     前記マルチメディアファイルに関する前記メタデータの少なくとも第１部分を２値データとして符号化し、かつ、
     前記マルチメディアファイルに関する前記メタデータの少なくとも第２部分を、第２フォーマットで表されたデータを含む付加的チャンクとして符号化するように構成される請求項１３３に記載のシステム。
145. 前記プロセッサは、更に、前記付加的チャンクを単一断片のメタデータで符号化すべく構成される請求項１４４に記載のシステム。
146. マルチメディアファイルから情報を抽出すべく構成されたプロセッサを有し、
     前記プロセッサは、前記マルチメディアファイルに関するメタデータ情報を抽出すべく構成され、かつ、
     前記メタデータ情報は、主部、述部、目的部および出典を有する少なくとも一つのステートメントを含むマルチメディアファイルを復号化するシステム。
147. 前記プロセッサは、前記主部から、前記メタデータにより記述されるファイル、アイテム、人物または組織を特定する情報を抽出すべく構成される請求項１４６に記載のシステム。
148. 前記プロセッサは、前記述部から前記主部の特性を表す情報を抽出すべく構成される請求項１４７に記載のシステム。
149. 前記プロセッサは、前記目的部から、前記述部により特定される前記主部の特性を記述する情報を抽出すべく構成される請求項１４８に記載のシステム。
150. 前記プロセッサは、前記出典から前記ステートメントのソースに関する情報を抽出すべく構成される請求項１４９に記載のシステム。
151. 前記主部は、タイプおよび値を含むチャンクであり、
     前記プロセッサは、前記タイプを検査することにより、前記チャンクは主部情報を含むことを特定すべく構成され、かつ、
     前記プロセッサは、前記値から情報を抽出すべく構成される請求項１４６に記載のシステム。
152. 前記述部は、タイプおよび値を含むチャンクであり、
     前記プロセッサは、前記タイプを検査することにより、前記チャンクは述部情報を含むことを特定すべく構成され、かつ、
     前記プロセッサは、前記値から情報を抽出すべく構成される請求項１４６に記載のシステム。
153. 前記目的部は、タイプ、言語、データタイプおよび値を含むチャンクであり、
     前記プロセッサは、前記タイプを検査することにより、前記チャンクは、目的部情報を含むことを特定すべく構成され、
     前記プロセッサは、前記値に含まれる情報のデータタイプを決定するために、前記データタイプを検査すべく構成され、
     前記プロセッサは、前記データタイプにより指示されるタイプの情報を前記値から抽出すべく構成され、かつ、
     前記プロセッサは、前記言語から、特定言語を指定する情報を抽出すべく構成される、請求項１４６に記載のシステム。
154. 前記出典はタイプおよび値を含むチャンクであり、
     前記プロセッサは、前記タイプを検査することにより、チャンクは出典情報を含むことを特定すべく構成され、かつ、
     プロセッサは、値から情報を抽出すべく構成される請求項１４６に記載のシステム。
155. 前記プロセッサは、前記メタデータ・ステートメントから情報を抽出し、かつ、その情報の少なくとも一部を表示すべく構成される請求項１４６に記載のシステム。
156. 前記プロセッサは、前記メタデータを用いて、メモリ内にラベル付き有向グラフを表すデータ構造を構築すべく構成される請求項１４６に記載のシステム。
157. 前記プロセッサは、複数のステートメントのための前記主部、述部、目的部および出典の内の少なくとも一つを検査することにより、前記メタデータを介して情報を検索すべく構成される請求項１４６に記載のシステム。
158. 前記プロセッサは、前記検索の結果を、グラフィカル・ユーザ・インタフェースの一部として表示すべく構成される請求項１５７に記載のシステム。
159. 前記プロセッサは、外部デバイスからの要求に応じて検索を実施すべく構成される請求項１５７に記載のシステム。
160. 前記マルチメディアファイルに関する前記メタデータ情報の少なくとも一部は、２値データとして表される請求項１４６に記載のシステム。
161. 前記マルチメディアファイルに関する前記メタデータ情報の少なくとも一部は、６４ビットＡＳＣＩデータとして表される請求項１４６に記載のシステム。
162. 前記マルチメディアファイルに関する前記メタデータ情報の少なくとも第１部分は、２値データとして表され、かつ、
     前記マルチメディアファイルに関する前記メタデータ情報の少なくとも第２部分は第２フォーマットで表されたデータを含む付加的チャンクとして表される請求項１４６に記載のシステム。
163. 前記付加的チャンクは単一断片のメタデータを含む請求項１６２に記載のシステム。
164. ネットワークと、
     マルチメディアファイルを含むと共に、サーバを介して前記ネットワークに対して接続された記憶デバイスと、
     前記ネットワークに接続されたクライアントとを備え、
     前記クライアントは、前記サーバからの前記マルチメディアファイルの転送を要求することができ、
     前記マルチメディアファイルは、そのマルチメディアファイルに関するメタデータを含み、かつ、
     前記メタデータは、主部、述部、目的部および出典を備える少なくとも一つのステートメントを含む、マルチメディア情報を通信するシステム。
165. 少なくとも一つの符号化ビデオトラックと、
     少なくとも一つの符号化オーディオトラックと、
     複数の符号化テキスト文字列とを有し、
     前記符号化テキスト文字列は、少なくとも一つのビデオトラックおよび少なくとも一つのオーディオトラックの特性を記述する、マルチメディアファイル。
166. 前記複数のテキスト文字列は、異なる言語を用い、ビデオトラックまたはオーディオトラックと同一の特性を記述する請求項１６５に記載のマルチメディアファイル。
167. 少なくとも一つの符号化サブタイトルトラックを更に有し、
     前記複数の符号化テキスト文字列は前記サブタイトルトラックの特性を記述する文字列を含む請求項１６６に記載のマルチメディアファイル。
168. 少なくとも一つのビデオトラックを符号化し、
     少なくとも一つのオーディオトラックを符号化し、
     前記符号化オーディオトラックの内の少なくとも一つをビデオトラックと交互配置し、 少なくとも一つのビデオトラックおよび少なくとも一つのオーディオトラックの多数の特性の各々を複数の言語で記述するテキスト文字列を挿入するように構成されたプロセッサを有する、マルチメディアファイルを生成するシステム。
169. マルチメディアファイルから符号化テキスト文字列を抽出し、かつ、
     テキスト文字列を用いてプルダウン・メニュー表示を生成する、ように構成されたプロセッサを有する、
     符号化オーディオ、ビデオおよびテキスト文字列を含むマルチメディアファイルを表示するシステム。

Images