マルチメディア配信システム
【課題】マルチメディア・ファイル、ならびに、そのマルチメディア・ファイルを生成、配信および使用する方法を提供する。
【解決手段】本発明の実施例によるマルチメディア・ファイルは、複数のビデオ・トラックと、複数のオーディオ・トラックと、複数のサブタイトルトラックと、そのファイルの内容にアクセスするメニュー・インタフェースを生成すべく使用され得るデータと、そのファイルの内容に関する「メタデータ」とを含み得る。本発明の幾つかの実施例によるマルチメディア・ファイルは、そのファイルの外部であるビデオ・トラック、オーディオ・トラック、サブタイトルトラックおよび「メタデータ」に対するリファレンスも含む。本発明によるマルチメディア・ファイルの一実施例は、複数の符号化ビデオ・トラックを含む。
【解決手段】本発明の実施例によるマルチメディア・ファイルは、複数のビデオ・トラックと、複数のオーディオ・トラックと、複数のサブタイトルトラックと、そのファイルの内容にアクセスするメニュー・インタフェースを生成すべく使用され得るデータと、そのファイルの内容に関する「メタデータ」とを含み得る。本発明の幾つかの実施例によるマルチメディア・ファイルは、そのファイルの外部であるビデオ・トラック、オーディオ・トラック、サブタイトルトラックおよび「メタデータ」に対するリファレンスも含む。本発明によるマルチメディア・ファイルの一実施例は、複数の符号化ビデオ・トラックを含む。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は一般に、マルチメディア・ファイルの符号化、送信および復号化に関する。より詳細には、本発明は、単一のオーディオ・トラックおよび単一のビデオ・トラックに加えて複数のトラックを含み得るマルチメディア・ファイルの符号化、送信および復号化に関する。
【発明の概要】
【発明が解決しようとする課題】
【0002】
インターネットの発展は、標準化されたファイルの生成、配信および表示を可能とするマルチメディア情報用ファイル・フォーマットの発展を促進した。典型的には、単一のマルチメディア・ファイルは単一のビデオ・トラックおよび単一のオーディオ・トラックを含む。マルチメディアがデジタル・ビデオ・ディスク(DVD)などの高容量で物理的に搬送可能なメディアに書き込まれたときには、多数のビデオ・トラック、オーディオ・トラックおよびサブタイトルトラックを提供するために複数のファイルが使用され得る。インタラクティブなメニューを生成すべく使用され得る情報を含む付加的ファイルが提供され得る。
【課題を解決するための手段】
【0003】
本発明の実施例は、マルチメディア・ファイル、および、マルチメディア・ファイルを生成、配信および復号化するシステムを含む。本発明の一つの形態において、マルチメディア・ファイルは、複数の符号化ビデオ・トラックを含む。本発明の別の形態おいて、マルチメディア・ファイルは複数の符号化オーディオ・トラックを含む。本発明の別の形態において、マルチメディア・ファイルは少なくとも一つのサブタイトルトラックを含む。
本発明の別の形態において、マルチメディア・ファイルは符号化「メタデータ(meta data)」を含む。本発明の別の形態において、マルチメディア・ファイルは符号化されたメニュー情報を含む。
【0004】
本発明の実施例によるマルチメディア・ファイルは、複数の符号化ビデオ・トラックを含む。本発明の更なる実施例において、マルチメディア・ファイルは連結された複数の「リフ(RIFF)」チャンクを備え、かつ、各符号化ビデオ・トラックは別個の「RIFF」チャンク内に含まれる。これに加え、ビデオは心理視覚的強化(psychovisual enhancement)で符号化され、かつ、各ビデオ・トラックは、それに関係付けられた少なくとも1つのオーディオ・トラックを有する。
【0005】
別実施例において、各ビデオ・トラックは、「RIFF」チャンク内における一連の「映像(video)」チャンクとして符号化され、かつ、各ビデオ・トラックに付随するオーディオ・トラックは、関係付けられたビデオ・トラックの「ビデオ」チャンクを含む「RIFF」チャンク内に交互配置(interleave)された一連の「オーディオ(audio)」チャンクとして符号化される。更に、各「ビデオ」チャンクは、ビデオ・トラックからビデオの単一フレームを生成すべく使用され得る情報を含み得ると共に、各「オーディオ」チャンクは、「ビデオ」チャンクを用いて生成されたフレームに付随するオーディオ・トラックの部分からのオーディオ情報を含む。これに加え、「オーディオ」チャンクは「RIFF」チャンク内において対応する「ビデオ」チャンクの前に交互配置され得る。
【0006】
本発明の実施例によるマルチメディア・ファイルを符号化するシステムは、複数のビデオ・トラックを符号化し、符号化ビデオ・トラックを連結し、かつ、連結された符号化ビデオ・トラックを単一ファイルへと書き込むように構成されたプロセッサを含む。別な実施例において、プロセッサは各ビデオ・トラックが別個の「RIFF」チャンク内に含まれるようなビデオ・トラックに符号化すべく構成され、かつ、プロセッサは、心理視覚的強化を用いてビデオを符号化すべく構成される。これに加え、各ビデオ・トラックは自身に関係付けられた少なくとも一つのオーディオ・トラックを有し得る。
【0007】
別な実施例においてプロセッサは、各ビデオ・トラックを「RIFF」チャンク内における一連の「ビデオ」チャンクとして符号化し、かつ、各ビデオ・トラックに付随する少なくとも一つのオーディオ・トラックを、関係付けられたビデオ・トラックの「ビデオ」チャンクを含む「RIFF」チャンク内に交互配置された一連の「オーディオ」チャンクとして符号化するように構成される。
【0008】
さらに別の実施例において、プロセッサは、各「ビデオ」チャンクが、ビデオ・トラックからビデオの単一フレームを生成すべく使用され得る情報を含むようなビデオ・トラックを符号化し、かつ、ビデオ・トラックに関係付けられたオーディオ・トラックを、各「オーディオ」チャンクが、ビデオ・トラックから生成された「ビデオ」チャンクを用いて生成されたフレームに付随するオーディオ・トラックの部分からのオーディオ情報を含む如く、符号化するように構成される。これに加え、プロセッサは、各「オーディオ」チャンクを「RIFF」チャンク内において対応する「ビデオ」チャンクに先立ち交互配置するように構成され得る。
【0009】
本発明の実施例による複数の符号化ビデオ・トラックを含むマルチメディア・ファイルを復号化するシステムは、マルチメディア・ファイルから情報を抽出すべく構成されたプロセッサを含む。そのプロセッサは、マルチメディア・ファイル内に含まれた符号化ビデオ・トラックの数に関する情報を抽出すべく構成される。
【0010】
更なる実施例においてプロセッサは、「RIFF」チャンク内において符号化ビデオ・トラックを検索(locate)すべく構成される。これに加え、標準的な4ccコードを有する第1「RIFF」チャンク内には第1の符号化ビデオ・トラックが含まれ得ると共に、特殊な4ccコードを有する第2「RIFF」チャンク内には第2のビデオ・トラックが含まれ、かつ、特殊化4ccコードは、その特殊化4ccコードの最後の2キャラクタとして、標準的な4ccコードの最初の2キャラクタを有し得る。
【0011】
付加的な実施例において、各符号化ビデオ・トラックは別個に「RIFF」チャンク内に含まれる。
【0012】
更なる別の実施例において、復号化されたビデオ・トラックは、マルチメディア・ファイルを生成する際に符号化されたオリジナルのビデオ・トラックと同様であり、かつ、復号化されたビデオ・トラックとオリジナルのビデオ・トラックとの間における相違点の少なくとも幾つかは、ビデオ・トラックの各フレームの暗い部分内に配置される。更に、復号化されたビデオ・トラックとオリジナルのビデオ・トラックとの間における相違点の少なくとも幾つかは、ビデオ・トラックの速い動作のシーンに配置され得る。
【0013】
再び付加的な実施例において各ビデオ・トラックは、自身に関係付けられた少なくとも1つのオーディオ・トラックを有する。
【0014】
更なる付加的な実施例において、プロセッサは、「RIFF」チャンク内の一連の「ビデオ」チャンクを復号化することにより、ビデオ・トラックからのビデオを表示し、かつ、関係付けられたビデオ・トラックの「ビデオ」チャンクを含む「RIFF」チャンク内に交互配置された一連の「オーディオ」チャンクを復号化することにより、ビデオ・トラックに付随するオーディオ・トラックからオーディオを生成するように構成される。
【0015】
更に別の更なる実施例において、プロセッサは、各「ビデオ」チャンクから抽出された情報を使用してビデオ・トラックの単一フレームを生成し、かつ、各「オーディオ」チャンクから抽出された情報を使用して、「ビデオ」チャンクを使用して生成されたフレームに付随するオーディオ・トラックの部分を生成するように構成される。これに加えてプロセッサは、「RIFF」チャンクにおいて「オーディオ」チャンクが関係付けられた「ビデオ」チャンクに先立ち、「オーディオ」チャンクを位置決定(locate)すべく構成され得る。
【0016】
本発明の実施例によるマルチメディア・ファイルは、一連の符号化ビデオ・フレームと、符号化ビデオ・フレームの間に交互配置された符号化オーディオとを含む。符号化オーディオはオーディオ情報の2つ以上のトラックを含む。
【0017】
更なる実施例において、オーディオ情報のトラックの内の少なくとも1つのトラックは複数のオーディオチャネルを含む。
【0018】
別実施例は更に、マルチメディア・ファイルに含まれたオーディオ・トラックの個数を特定するヘッダ情報と、オーディオ情報のトラックの内の少なくとも1つのトラックに関する説明情報とを含む。
【0019】
再び更なる実施例において、各符号化ビデオ・フレームは、符号化オーディオ情報によって発し、かつ、ビデオ・フレームを発生する符号化オーディオ情報は、符号化ビデオ・フレームに付随する各オーディオ・トラックの部分のためのオーディオ情報を含む。
【0020】
再び別実施例において、ビデオ情報はマルチメディア・ファイル内にチャンクとして記憶される。これに加え、ビデオ情報の各チャンクは、ビデオの単一フレームを含み得る。
更に、オーディオ情報はマルチメディア・ファイル内にチャンクとして記憶され得ると共に、2つの別個のオーディオ・トラックからのオーディオ情報は、オーディオ情報の単一チャンク内には含まれない。
【0021】
更なる実施例において、ビデオ・チャンクは、オーディオ・トラックの各々からの少なくとも1つのオーディオ・チャンクにより分離され、かつ、ビデオ・チャンクを分離するオーディオ・チャンクは、オーディオ・チャンクに追随するビデオ・チャンク内に含まれたビデオ情報に付随するオーディオ・トラックの部分のためのオーディオ情報を含む。
【0022】
本発明の実施例によるマルチメディア・ファイルを符号化するシステムは、ビデオ・トラックを符号化し、複数のオーディオ・トラックを符号化し、ビデオ・トラックからの情報を複数のオーディオ・トラックからの情報と交互配置し、かつ、交互配置されたビデオおよびオーディオ情報を単一ファイルへと書き込むように構成されたプロセッサを含む。
【0023】
更なる実施例において、オーディオ・トラックの内の少なくとも1つのオーディオ・トラックは複数のオーディオチャネルを含む。
【0024】
別実施例においてプロセッサは更に、符号化オーディオ・トラックの数を特定するヘッダ情報を符号化し、かつ、そのヘッダ情報を単一ファイルに書き込みむように構成される。
【0025】
再び更なる実施例において、プロセッサは更に、符号化オーディオ・トラック内の少なくとも1つの符号化オーディオ・トラックに関する説明情報を特定するヘッダ情報を符号化し、かつ、そのヘッダ情報を単一ファイルに書き込むべく構成される。
【0026】
再び別実施例において、プロセッサはビデオ・トラックをビデオ情報のチャンクとして符号化する。これに加え、プロセッサは各オーディオ・トラックをオーディオ情報の一連のチャンクとして符号化し得る。更に、オーディオ情報の各チャンクは単一のオーディオ・トラックからのオーディオ情報を含み得ると共に、プロセッサは、ビデオ情報のチャンク間にオーディオ情報のチャンクを交互配置するように構成され得る。
【0027】
更なる実施例において、プロセッサは、「ビデオ」チャンクにおけるビデオ情報に付随する各オーディオ・トラックの部分を「オーディオ」チャンク内に符号化すべく構成され、かつ、プロセッサは、各「ビデオ」チャンクが、その「ビデオ」チャンクに含まれたビデオ情報に付随するオーディオ・トラックの各々からのオーディオ情報を含む「オーディオ」チャンクにより発生するように、「ビデオ」チャンクおよび「オーディオ」チャンクを交互配置すべく構成される。これに加え、プロセッサは、各ビデオ・チャンク内にビデオの単一フレームが含まれるようにビデオ・トラックを符号化すべく構成され得る。
【0028】
再び更に別の実施例において、プロセッサは汎用プロセッサである。
【0029】
付加的な更なる実施例において、プロセッサは専用回路である。
【0030】
本発明による複数のオーディオ・トラックを含むマルチメディア・ファイルを復号化するシステムは、マルチメディア・ファイルから情報を抽出すべく構成されたプロセッサを含む。プロセッサは、マルチメディア・ファイル内に含まれたオーディオ・トラックの個数に関する情報を抽出すべく構成される。
【0031】
更なる実施例において、プロセッサは、複数のオーディオ・トラックから単一のオーディオ・トラックを選択すべく構成され、かつ、プロセッサは、選択されたオーディオ・トラックからのオーディオ情報を復号化すべく構成される。
【0032】
別実施例において、オーディオ・トラックの内の少なくとも一つのオーディオ・トラックは複数のオーディオチャネルを含む。
【0033】
更なる実施例において、プロセッサは、マルチメディア・ファイルにおけるヘッダからの情報であってオーディオ・トラックの内の少なくとも一つのオーディオ・トラックに関する説明情報を含む情報を抽出すべく構成される。
【0034】
本発明の実施例によるマルチメディア情報を通信するシステムは、ネットワークと、マルチメディア・ファイルを含むと共に、サーバを介してネットワークに対して接続された記憶デバイスと、ネットワークに接続されたクライアントとを含む。クライアントは、サーバからのマルチメディア・ファイルの転送を要求することができ、かつ、マルチメディア・ファイルは、少なくとも一つのビデオ・トラックと、そのビデオ・トラックに付随する複数のオーディオ・トラックとを含む。
【0035】
本発明によるマルチメディア・ファイルは、一連の符号化ビデオ・フレームと、符号化ビデオ・フレーム間に交互配置された少なくとも一つの符号化サブタイトルトラックとを含む。
【0036】
更なる実施例において、少なくとも一つの符号化サブタイトルトラックは複数の符号化サブタイトルトラックから成る。
【0037】
別な実施例は更に、マルチメディア・ファイルに含まれた符号化サブタイトルトラックの個数を特定するヘッダ情報を更に含む。
【0038】
更なる実施例もまた、符号化サブタイトルトラックの内の少なくとも一つの符号化サブタイトルトラックに関する説明情報を含むヘッダ情報を含む。
【0039】
更なる別実施例において、各サブタイトルトラックは一連のビットマップを含み、かつ、各サブタイトルトラックは一連の圧縮ビットマップを含み得る。これに加え、各ビットマップはランレングス符号化方法を用いて圧縮される。
【0040】
更なる実施例において、一連の符号化ビデオ・フレームは一連のビデオ・チャンクとして符号化され、かつ、各符号化サブタイトルトラックは一連のサブタイトル・チャンクとして符号化される。各サブタイトル・チャンクは、表示上にテキストとして表され得る情報を含む。これに加え、各サブタイトル・チャンクは単一のサブタイトルに関する情報を含み得る。更に、各サブタイトル・チャンクは、サブタイトルがスーパーインポーズ(superimpose)されるべきビデオ・シーケンスの部分に関する情報を含み得る。
【0041】
更に別の実施例において、各サブタイトル・チャンクは、サブタイトルが配置されるべき表示の部分に関する情報を含む。
【0042】
再び更なる実施例において、各サブタイトル・チャンクは、サブタイトルの色に関する情報を含み、かつ、色に関する情報は色パレート(palate)を含み得る。これに加え、サブタイトル・チャンクは、第1色パレートに関する情報を含む第1サブタイトル・チャンクと、第1色パレートに関する情報に成り代わる第2色パレートに関する情報を含む第2サブタイトル・チャンクとを備え得る。
【0043】
本発明の実施例によるマルチメディア・ファイルを符号化するシステムは、ビデオ・トラックを符号化し、少なくとも一つのサブタイトルトラックを符号化し、ビデオ・トラックからの情報を、少なくとも一つのサブタイトルトラックからの情報と交互配置し、かつ、交互配置されたビデオおよびサブタイトル情報を単一ファイルに書き込むように構成されたプロセッサを含み得る。
【0044】
更なる実施例において、少なくとも一つのサブタイトルトラックは複数のサブタイトルトラックを含む。
【0045】
別実施例において、プロセッサは更に、マルチメディア・ファイルに含まれたサブタイトルトラックの個数を特定するヘッダ情報を符号化して単一ファイルに書き込むべく構成される。
【0046】
再び更なる実施例において、プロセッサは更に、サブタイトルトラックの内の少なくとも一つのサブタイトルトラックに関する説明情報を符号化して単一ファイルに書き込むべく構成される。
【0047】
別の更なる実施例において、ビデオ・トラックはビデオ・チャンクとして符号化され、かつ、少なくとも一つのサブタイトルトラックの各々はサブタイトル・チャンクとして符号化される。これに加え、サブタイトル・チャンクの各々は、ビデオ・トラックの一部に付随する単一のサブタイトルを含み得ると共に、インタリーバ(interleaver)は、ビデオ・トラックの部分であってサブタイトル・チャンク内のサブタイトルが付随する部分を含むビデオ・チャンクの前に、各サブタイトル・チャンクを交互配置すべく構成され得る。
【0048】
更なる実施例において、プロセッサは、サブタイトルをビットマップとして符号化することによりサブタイトル・チャンクを生成すべく構成される。
【0049】
更なる別実施例において、サブタイトルは圧縮ビットマップとして符号化される。これに加え、ビットマップはランレングス符号化方法を用いて圧縮され得る。更に、プロセッサは各サブタイトル・チャンク内に、サブタイトルがスーパーインポーズされるべきビデオ・シーケンスの部分に関する情報を含み得る。
【0050】
更なる実施例において、プロセッサは各サブタイトル・チャンク内に、サブタイトルが配置されるべき表示の部分に関する情報を含む。
【0051】
更に別の実施例において、プロセッサは各サブタイトル・チャンク内に、サブタイトルの色に関する情報を含む。
【0052】
更なる実施例において、色に関する情報は色パレートを含む。これに加え、サブタイトル・チャンクは、第1色パレートに関する情報を含む第1サブタイトル・チャンクと、第1色パレートに関する情報に成り代わる第2色パレートに関する情報を含む第2サブタイトル・チャンクとを含み得る。
【0053】
本発明の実施例によるマルチメディア・ファイルは、マルチメディア・ファイルから情報を抽出すべく構成されたプロセッサを含む。プロセッサは、マルチメディア・ファイルを検査して、少なくとも一つのサブタイトルトラックが在るか否かを決定すべく構成される。これに加え、少なくとも一つのサブタイトルトラックは、複数のサブタイトルトラックを備え得ると共に、プロセッサはマルチメディア・ファイル内におけるサブタイトルトラックの数を決定すべく構成され得る。
【0054】
更なる実施例において、プロセッサは更に、サブタイトルトラックの数を特定するヘッダ情報を、マルチメディア・ファイルから抽出すべく構成される。
【0055】
別な実施例において、プロセッサは更に、サブタイトルトラックの内の少なくとも一つのサブタイトルトラックに関する説明情報をマルチメディア・ファイルから抽出すべく構成される。
【0056】
再び更なる実施例において、マルチメディア・ファイルは、ビデオ・チャンクとして符号化された少なくとも一つのビデオ・トラックを含み、かつ、マルチメディア・ファイルは、サブタイトル・チャンクとして符号化された少なくとも一つのサブタイトルトラックを含む。
【0057】
再び別実施例において、各サブタイトル・チャンクは単一のサブタイトルに関する情報を含む。
【0058】
更なる実施例において、各サブタイトルはサブタイトル・チャンク内においてビットマップとして符号化され、プロセッサは、ビデオ・トラックを復号化すべく構成され、かつ、プロセッサは、ビットマップをビデオ・シーケンスの一部上にスーパーインポーズすることにより、表示のためのビデオのフレームを構築すべく構成される。これに加え、サブタイトルは圧縮ビットマップとして符号化され得ると共に、プロセッサはビットマップを解凍すべく構成され得る。更に、プロセッサは、ランレングス符号化されたビットマップを解凍すべく構成され得る。
【0059】
更なる別実施例において、各サブタイトル・チャンクは、サブタイトルがスーパーインポーズされるべきビデオ・トラックの部分に関する情報を含み、かつ、プロセッサは、サブタイトル・チャンクにおける情報により表された各ビデオ・フレーム上にサブタイトルのビットマップをスーパーインポーズすることにより、表示のための一連のビデオ・フレームを生成すべく構成される。
【0060】
付加的な更なる実施例において、各サブタイトル・チャンクは、サブタイトルが配置されるべきフレーム内の位置に関する情報を含み、かつ、プロセッサは、サブタイトル・チャンク内の情報により表された各ビデオ・フレーム内の位置にサブタイトルをスーパーインポーズすべく構成される。
【0061】
別の付加的な実施例において、各サブタイトル・チャンクは、サブタイトルの色に関する情報を含み、かつ、プロセッサは、サブタイトル・チャンク内の色情報により表される単一もしくは複数の色でサブタイトルをスーパーインポーズすべく構成される。これに加え、サブタイトル・チャンク内における色情報は色パレートを含み得ると共に、プロセッサは、色パレートを用いてサブタイトルのビットマップにおいて使用される色情報を獲得して、サブタイトルをスーパーインポーズすべく構成される。更に、サブタイトル・チャンクは、第1色パレートに関する情報を含む第1サブタイトル・チャンクと、第2色パレートに関する情報を含む第2サブタイトル・チャンクとを備え得ると共に、プロセッサは、第1色パレートを用いて、第1チャンクが処理された後にサブタイトルのビットマップにおいて使用される色に関する情報を獲得して、サブタイトルをスーパーインポーズすべく構成されることが可能であり、かつ、プロセッサは、第2色パレートを用いて、第2チャンクが処理された後にサブタイトルのビットマップにおいて使用される色に関する情報を獲得して、サブタイトルをスーパーインポーズすべく構成され得る。
【0062】
本発明の実施例によるマルチメディア情報を通信するシステムは、ネットワークと、マルチメディア・ファイルを含むと共に、サーバを介してネットワークに対して接続された記憶デバイスと、ネットワークに接続されたクライアントとを含む。クライアントは、サーバからのマルチメディア・ファイルの転送を要求し、かつ、マルチメディア・ファイルは、少なくとも一つのビデオ・トラックと、そのビデオ・トラックに付随する少なくとも一つのサブタイトルトラックとを含む。
【0063】
本発明の実施例によるマルチメディア・ファイルは、一連の符号化ビデオ・フレームと、符号化されたメニュー情報とを含む。これに加え、符号化されたメニュー情報はチャンクとして記憶され得る。
【0064】
更なる実施例は少なくとも2つの別個のメニュー情報の「menu(メニュー)」チャンクも含み、かつ、少なくとも2つの別個の「menu」チャンクは少なくとも2つの別個の「RIFF」チャンクに含まれ得る。
【0065】
別実施例において、「menu」チャンクを含む第1「RIFF」チャンクは標準的な4ccコードを含むと共に、「menu」チャンクを含む第2「RIFF」チャンクは特殊な4ccコードを含み、標準的な4ccコードの最初の2個のキャラクタは特殊化4ccコードの最後の2個のキャラクタとして現れる。
【0066】
再び更なる実施例において、単一の「RIFF」チャンク内には少なくとも2つの別個の「menu」チャンクが含まれる。
【0067】
再び別実施例において、「menu」チャンクは、一連のメニューを記述するチャンクと、一連のメニューに関係付けられたメディアを含む「MRIF」チャンクとを含む。これに加え、「MRIF」チャンクは、ビデオ・トラック、オーディオ・トラックおよびオーバレイトラックを含むメディア情報を含み得る。
【0068】
更なる実施例において、一連のメニューを記述するチャンクは、メニュー・システム全体を記述するチャンクと、各メニューを言語によりグループ化する少なくとも一つのチャンクと、個々のメニュー表示と、付随するバックグラウンド・オーディオとを記述する少なくとも一つのチャンクと、メニュー上のボタンを記述する少なくとも一つのチャンクと、画面上におけるボタンの箇所を記述する少なくとも一つのチャンクと、ボタンに関係付けられた種々の動作を記述する少なくとも一つのチャンクとを含み得る。
【0069】
更なる別実施例は、第2ファイルに対するリンクも含む。符号化されたメニュー情報は第2ファイル内に含まれる。
【0070】
本発明の実施例によるマルチメディア・ファイルを符号化するシステムは、メニュー情報を符号化すべく構成されたプロセッサを含む。そのプロセッサはまた、符号化ビデオ・トラックおよび符号化されたメニュー情報を含むマルチメディア・ファイルを生成するようにも構成される。これに加え、プロセッサは、メニューのオブジェクト・モデルを生成し、オブジェクト・モデルを設定ファイルへと変換し、設定ファイルを解析してチャンクとし、メディア情報を含むAVIファイルを生成し、AVIファイル内のメディアを「MRIF」チャンク内へと交互配置し、かつ、解析されたチャンクを「MRIF」チャンクと連結して「menu」チャンクを生成するように構成され得る。また、プロセッサは更に、オブジェクト・モデルを使用して第2の更に小さな「menu」チャンクを生成すべく構成され得る。
【0071】
更なる実施例において、プロセッサは第2メニューを符号化すべく構成され、かつ、プロセッサは、第1の符号化メニューを第1「RIFF」チャンクに挿入しかつ第2の符号化メニューを第2「RIFF」チャンクに挿入し得る。
【0072】
別実施例において、プロセッサは第1および第2の符号化メニューを単一の「RIFF」チャンク内に含む。
【0073】
再び更なる実施例において、プロセッサは、マルチメディア・ファイル内に、第2ファイルにおける符号化メニューに対するリファレンスを挿入すべく構成される。
【0074】
本発明によるマルチメディア・ファイルを復号化するシステムは、マルチメディア・ファイルから情報を抽出すべく構成されたプロセッサを含む。プロセッサは、マルチメディア・ファイルを検査して、それが符号化されたメニュー情報を含むか否かを決定すべく構成される。これに加え、プロセッサは、「RIFF」チャンク内の「menu」チャンクからメニュー情報を抽出すべく構成され得ると共に、プロセッサは、「menu」チャンクに記憶されたビデオ情報を用いてメニュー表示を構築すべく構成され得る。
【0075】
更なる実施例において、プロセッサは、「menu」チャンクに記憶されたオーディオ情報を用い、メニュー表示に付随するバックグラウンド・オーディオを生成すべく構成される。
【0076】
別実施例において、プロセッサは、「menu」チャンクからのオーバレイを、その「menu」チャンクからのビデオ情報に重ね合わせることによりメニュー表示を生成すべく構成される。
【0077】
本発明によるマルチメディア情報を通信するシステムは、ネットワークと、マルチメディア・ファイルを含むと共に、サーバを介してネットワークに対して接続された記憶デバイスと、ネットワークに接続されたクライアントとを含む。クライアントは、サーバからのマルチメディア・ファイルの転送を要求することができ、かつ、マルチメディア・ファイルは符号化されたメニュー情報を含む。
【0078】
マルチメディア・ファイルは、一連の符号化ビデオ・フレームと、そのマルチメディア・ファイルに関する符号化メタデータとを含む。符号化メタデータは、主部(subject)、述部、目的部(object)および出典(authority)を備える少なくとも一つのステートメント(statement)を含む。主部は、メタデータにより記述されるファイル、項目、人物または組織を特定する情報を含むことができ、述部は主部の特性を表す情報を含むことができ、目的部は、述部により特定された主部の特性を記述する情報を含むことができ、かつ、出典はステートメントのソースに関する情報を含むことができる。
【0079】
更なる実施例において、主部はタイプおよび値を含むチャンクであり、値は情報を含み、かつ、タイプは、チャンクがリソースであるか匿名ノードであるかを表す。
【0080】
別実施例において、述部は、タイプおよび値を含むチャンクであり、値は情報を含み、かつ、タイプは、値情報が記述URIであるか順序リスト・エントリであるかを表す。
【0081】
再び更なる実施例において、目的部は、タイプ、言語、データタイプおよび値を含むチャンクであり、値は情報を含み、タイプは、値情報がUTF-8リテラル、リテラル整数またはリテラルXMLデータであるかを表し、データタイプは値情報のタイプを表し、かつ、言語は特定言語を指定する情報を含む。
【0082】
再び別実施例において、出典はタイプおよび値を含むチャンクであり、値は情報を含み、かつ、タイプは、値情報がステートメントの出典であることを表す。
【0083】
更なる実施例において、符号化データの少なくとも一部は2値データとして表される。
【0084】
更に別の実施例において、符号化データの少なくとも一部は64ビットASCIデータとして表される。
【0085】
更なる実施例において、符号化データの少なくとも第1部分は2値データとして表され、かつ、符号化データの少なくとも第2部分は第2フォーマットで表されたデータを含む付加的チャンクとして表される。これに加え、付加的チャンクは各々、単一のメタデータを含み得る。
【0086】
本発明の実施例によるマルチメディア・ファイルを符号化するシステムは、ビデオ・トラックを符号化すべく構成されたプロセッサを含む。プロセッサは、マルチメディア・ファイルに関するメタデータを符号化する様にも構成され、かつ、符号化メタデータは、主部、述部、目的部および出典を備える少なくとも一つのステートメントを含む。これに加え、主部は、メタデータにより記述されるファイル、項目、人物または組織を特定する情報を含むことができ、述部は主部の特性を表す情報を含むことができ、目的部は、述部により特定された主部の特性を記述する情報を含むことができ、かつ、出典はステートメントのソースに関する情報を含むことができる。
【0087】
更なる実施例において、プロセッサは主部を、タイプおよび値を含むチャンクとして符号化すべく構成され、値は情報を含み、かつ、タイプは、チャンクがリソースであるか匿名ノードであるかを表す。
【0088】
別実施例において、プロセッサは述部を、タイプおよび値を含むチャンクとして符号化すべく構成され、値は情報を含み、かつ、タイプは、値情報が記述URIであるか順序リスト・エントリであるかを表す。
【0089】
再び更なる実施例において、プロセッサは目的部を、タイプ、言語、データタイプおよび値を含むチャンクとして符号化すべく構成され、値は情報を含み、タイプは、値情報がUTF-8リテラル、リテラル整数またはリテラルXMLデータであるかを表し、データタイプは値情報のタイプを表し、かつ、言語は特定言語を指定する情報を含む。
【0090】
再び別実施例において、プロセッサは出典を、タイプおよび値を含むチャンクとして符号化すべく構成され、値は情報を含み、かつ、タイプは、値情報がステートメントの出典であることを表す。
【0091】
更なる実施例において、プロセッサは更に、マルチメディア・ファイルに関するメタデータの少なくとも一部を2値データとして符号化すべく構成される。
【0092】
更なる別実施例において、プロセッサは更に、マルチメディア・ファイルに関するメタデータの少なくとも一部を64ビットASCIデータとして符号化すべく構成される。
【0093】
付加的な実施例において、プロセッサは更に、マルチメディア・ファイルに関するメタデータの少なくとも第1部分を2値データとして符号化し、かつ、マルチメディア・ファイルに関するメタデータの少なくとも第2部分を、第2フォーマットで表されたデータを含む付加的チャンクとして符号化するように構成される。これに加え、プロセッサは更に、付加的チャンクを単一のメタデータを以て符号化すべく構成され得る。
【0094】
本発明によるマルチメディア・ファイルを復号化するシステムは、マルチメディア・ファイルから情報を抽出すべく構成されたプロセッサを含む。プロセッサは、マルチメディア・ファイルに関するメタデータ情報を抽出すべく構成され、かつ、メタデータ情報は、主部、述部、目的部および出典を備える少なくとも一つのステートメントを含む。これに加え、プロセッサは主部から、メタデータにより記述されるファイル、アイテム、人物または組織を特定する情報を抽出すべく構成され得る。更に、プロセッサは、述部から主部の特性を表す情報を抽出すべく構成されることができ、プロセッサは目的部から、述部により特定される主部の特性を記述する情報を抽出すべく構成されることができ、かつ、プロセッサは、出典からステートメントのソースに関する情報を抽出すべく構成されることができる。
【0095】
更なる実施例において、主部はタイプおよび値を含むチャンクであり、プロセッサは、タイプを検査することにより、チャンクは主部情報を含むことを特定すべく構成され、かつ、プロセッサは、値から情報を抽出すべく構成される。
【0096】
別実施例において、述部は、タイプおよび値を含むチャンクであり、プロセッサは、タイプを検査することにより、チャンクは述部情報を含むことを特定すべく構成され、かつ、プロセッサは、値から情報を抽出すべく構成される。
【0097】
再び更なる実施例において、目的部は、タイプ、言語、データタイプおよび値を含むチャンクであり、プロセッサは、タイプを検査することにより、チャンクは目的部情報を含むことを特定すべく構成され、プロセッサは、データタイプを検査することで、値に含まれる情報のデータタイプを決定すべく構成され、プロセッサは、データタイプにより表されるタイプの情報を値から抽出すべく構成され、かつ、プロセッサは、特定言語を指定する情報を値から抽出すべく構成される。
【0098】
再び別実施例において、出典はタイプおよび値を含むチャンクであり、プロセッサは、タイプを検査することにより、チャンクは出典情報を含むことを特定すべく構成され、かつ、プロセッサは、値から情報を抽出すべく構成される。
【0099】
更なる実施例において、プロセッサは、メタデータ・ステートメントから情報を抽出してその情報の少なくとも一部を表示すべく構成される。
【0100】
更なる別実施例において、プロセッサは、メタデータを用い、メモリ内にラベル付き有向グラフを表すデータ構造を構築すべく構成される。
【0101】
更なる実施例において、プロセッサは、複数のステートメントに対して主部、述部、目的部および出典の内の少なくとも一つを検査することにより、メタデータを介して情報を検索するように構成される。
【0102】
更に別の実施例において、プロセッサは、検索の結果を、グラフィカル・ユーザ・インタフェースの一部として表示すべく構成される。これに加え、プロセッサは、外部デバイスからの要求に応じて検索を実施すべく構成され得る。
【0103】
付加的な更なる実施例において、マルチメディア・ファイルに関するメタデータ情報の少なくとも一部は2値データとして表される。
【0104】
別の付加的な実施例において、マルチメディア・ファイルに関するメタデータ情報の少なくとも一部は64ビットASCIデータとして表される。
【0105】
別の更なる実施例において、マルチメディア・ファイルに関するメタデータ情報の少なくとも第1部分は2値データとして表され、かつ、マルチメディア・ファイルに関するメタデータ情報の少なくとも第2部分は第2フォーマットで表されたデータを含む付加的チャンクとして表される。これに加え、付加的チャンクは単一のメタデータを含み得る。
【0106】
本発明によるマルチメディア情報を通信するシステムは、ネットワークと、マルチメディア・ファイルを含むと共に、サーバを介してネットワークに対して接続された記憶デバイスと、ネットワークに接続されたクライアントとを含む。クライアントは、サーバからのマルチメディア・ファイルの転送を要求することができ、マルチメディア・ファイルはそのマルチメディア・ファイルに関するメタデータを含み、かつ、メタデータは、主部、述部、目的部および出典を備える少なくとも一つのステートメントを含む。
【0107】
本発明によるマルチメディア・ファイルは、少なくとも一つの符号化ビデオ・トラックと、少なくとも一つの符号化オーディオ・トラックと、複数の符号化テキスト文字列とを含む。符号化テキスト文字列は、少なくとも一つのビデオ・トラックおよび少なくとも一つのオーディオ・トラックの特性を記述する。
【0108】
更なる実施例において、複数のテキスト文字列は、異なる言語を用い、ビデオ・トラックまたはオーディオ・トラックと同一の特性を記述する。
【0109】
別実施例は、少なくとも一つの符号化サブタイトルトラックも含む。複数の符号化テキスト文字列はサブタイトルトラックの特性を記述する文字列を含む。
【0110】
本発明によるマルチメディア・ファイルを生成するシステムは、少なくとも一つのビデオ・トラックを符号化し、少なくとも一つのオーディオ・トラックを符号化し、符号化オーディオ・トラックの内の少なくとも一つの符号化オーディオ・トラックをビデオ・トラックと交互配置し、少なくとも一つのビデオ・トラックおよび少なくとも一つのオーディオ・トラックの所定数の特性の各々を複数の言語で記述するテキスト文字列を挿入するように構成されたプロセッサを含む。
本発明による符号化オーディオ、ビデオおよびテキスト文字列を含むマルチメディア・ファイルを表示するシステムは、マルチメディア・ファイルから符号化テキスト文字列を抽出し、かつ、テキスト文字列を用いてプルダウン・メニュー表示を生成するように構成されたプロセッサを含む。
【図面の簡単な説明】
【0111】
【図1.】本発明の実施例によるファイルを符号化、配信および復号化するシステムの図である。
【図2.0.】本発明の実施例によるマルチメディア・ファイルの構造の図である。
【図2.0.1】本発明の別な実施例によるマルチメディア・ファイルの構造の図である。
【図2.1.】本発明の一実施例による「hdrl」リスト・チャンクの概略図である。
【図2.2.】本発明の実施例による「strl」チャンクの概略図である。
【図2.3.】本発明の実施例によるマルチメディア・ファイルの「DXDT」チャンクを記憶すべく割当てられたメモリの概略図である。
【図2.3.1.】本発明の実施例によるマルチメディア・ファイルの「DXDT」チャンク内に含まれ得る「メタデータ」チャンクの概略図である。
【図2.4.】本発明の実施例による「DMNU」チャンクの概略図である。
【図2.5.】本発明の実施例による「WowMenuManager」チャンクに含まれたメニュー・チャンクの概略図である。
【図2.6.】本発明の別な実施例による「WowMenuManager」チャンク内に含まれたメニュー・チャンクの概略図である。
【図2.6.1.】本発明の実施例による「DMNU」チャンク内に含まれた種々のチャンク間の関係を示す概略図である。
【図2.7.】本発明の実施例によるマルチメディア・ファイルの「movi」リスト・チャンクの概略図である。
【図2.8.】DRMを含む本発明の実施例によるマルチメディア・ファイルの「movi」リスト・チャンクの概念的概略図である。
【図2.9.】本発明の実施例による「DRM」チャンクの概略図である。
【図3.0.】本発明の実施例によるマルチメディア・ファイルを生成するシステムのブロック図である。
【図3.1.】本発明の実施例による「DXDT」チャンクを生成するシステムのブロック図である。
【図3.2.】本発明の実施例による「DMNU」チャンクを生成するシステムのブロック図である。
【図3.3.】本発明の実施例によるメディア・モデルの概略図である。
【図3.3.1.】本発明の実施例によるスモール・メニューを自動的に生成すべく使用され得るメディア・モデルからのオブジェクトの概略図である。
【図3.4.】本発明の実施例によるオーディオを再チャンクすべく使用され得る処理のフローチャートである。
【図3.5.】本発明の実施例によるビデオ・エンコーダのブロック図である。
【図3.6.】本発明の実施例によるIフレーム上で円滑な心理視覚的強化を実施する方法のフローチャートである。
【図3.7.】本発明の実施例によるマクロブロックSADの心理視覚的強化を実施する処理のフローチャートである。
【図3.8.】本発明の実施例によるワンパス速度制御のための処理のフローチャートである。
【図3.9.】本発明の実施例による第NパスVBV速度制御を実施する処理のフローチャートである。
【図4.0.】本発明の実施例によるマルチメディア・ファイルから必要なマルチメディア情報を検索し、そのマルチメディア情報を表示する処理のフローチャートである。
【図4.1.】本発明の実施例によるデコーダのブロック図である。
【図4.2.】本発明の実施例による表示されたメニューの例を示す図である。
【図4.3.】本発明の実施例による図4.2.に示された表示を生成すべく使用される情報のソースを示す概略図である。
【発明を実施するための形態】
【0112】
図面を参照する本発明の実施例は、マルチメディア・ファイルを符号化、送信および復号化することができる。本発明の実施例によるマルチメディア・ファイルは、複数のビデオ・トラックと、複数のオーディオ・トラックと、複数のサブタイトルトラックと、ファイルの内容にアクセスするメニュー・インタフェースを生成すべく使用され得るデータと、ファイルの内容に関する「メタデータ」とを含み得る。本発明の幾つかの実施例によるマルチメディア・ファイルは、ビデオ・トラック、オーディオ・トラック、サブタイトルトラック、およびファイル外部の「meta data」へのリファレンスも含む。
【実施例】
【0113】
1.システムの説明
次に図1を参照すると、ファイルを符号化、配信および復号化する本発明の実施例によるシステムが示される。システム10は、ネットワーク14を介して他の種々の演算デバイスに対して接続されるコンピュータ12を含む。ネットワークに接続され得るデバイスとしては、サーバ16、ラップトップ・コンピュータ18およびパーソナル・デジタル・アシスタント(PDA)20が挙げられる。種々の実施例においてデバイスとネットワークとの間の接続は、有線もしくは無線でされると共に、種々のネットワーク用プロトコル内の任意のプロトコルを用いて実施され得る。
【0114】
作動時にコンピュータ12は、本発明の実施例によるマルチメディア・ファイルを符号化すべく使用され得る。コンピュータ12はまた、本発明の実施例によるマルチメディア・ファイルを復号化すると共に本発明の実施例によるマルチメディア・ファイルを配信するためにも使用され得る。コンピュータは、ピアツーピア・ネットワークを介するなどの種々のファイル転送プロトコルの内の任意のプロトコルを用いてファイルを配信し得る。
これに加えてコンピュータ12は、本発明の実施例によるマルチメディア・ファイルをラップトップ・コンピュータ18へと転送でき、そこでファイルは他のデバイスによりアクセスされ得る。その他のデバイスとしては、任意の種々の演算デバイス、または、専用のデコーダ・デバイスも含まれる。図示の実施例においては、ラップトップ・コンピュータおよびPDAが示される。他の実施例においては、デジタル・セットトップボックス、デスクトップ・コンピュータ、ゲーム機、家電機器および他のデバイスがネットワークに接続され、マルチメディア・ファイルをダウンロードしてそれを復号化し得る。
【0115】
一実施例において、デバイスはサーバからネットワークを介してマルチメディア・ファイルにアクセスする。他の実施例において、デバイスは、多数のコンピュータからピアツーピア・ネットワークを介してマルチメディア・ファイルにアクセスする。幾つかの実施例においてマルチメディア・ファイルは、ディスク・ドライブ、CD−ROMまたはDVDなどの可搬的記憶デバイスに対して書き込まれ得る。多くの実施例において、電子的デバイスは可搬的記憶デバイスに書き込まれたマルチメディア・ファイルにアクセスし得る。
【0116】
2.ファイル構造の説明
本発明の実施例によるマルチメディア・ファイルは、ワシントン州、レドモンド市のMicrosoft社およびニューヨーク州、アーモンク市のIBM(International Business Machines)社により策定されたリソース交換ファイル・フォーマット(「RIFFファイル・フォーマット」)に準拠すべく構造化され得る。RIFFは、マルチメディア・データおよび関連情報を記憶するためのファイル・フォーマットである。RIFFファイルは典型的に、ファイルを特定する8バイトのRIFFヘッダであり、RIFFヘッダは、そのファイルを識別し、かつ、そのヘッダの後におけるファイルの残存長(すなわちファイル長−8)を提供する。RIFFファイルの残りの全ては、“チャンク(chunk)”および“リスト(list)”から成る。各チャンクは、チャンクのタイプを特定する8バイトのチャンク・ヘッダを有し、そのチャック・ヘッダは、そのチャンク・ヘッダに続くデータの長さをバイト単位で与える。各リストは、8バイトのリスト・ヘッダを有し、そのリスト・ヘッダは、そのリスト・ヘッダに続くデータの長さをバイト単位で与える。リストにおけるデータは、チャンクおよび/または他のリスト(これは更にチャンクおよび/または他のリストを備え得る)を備える。RIFFリストは、一定の場合には“リスト・チャンク”とも称される。
【0117】
AVIファイルはRIFFファイルの特定形態であり、RIFFファイルのフォーマットに追随するが、特定フォーマットにおけるマルチメディア・データを含む定義済み識別子を備えた種々のチャンクおよびリストを含んでいる。AVIフォーマットは、Microsoft社により開発かつ規定された。AVIファイルは典型的に、AVIフォーマットでマルチメディア・データを出力し得るエンコーダを用いて生成される。AVIファイルは典型的に、集合的にAVIデコーダとして知られた一群のソフトウェア内の任意のソフトウェアにより復号化される。
【0118】
RIFFおよびAVIフォーマットは、規定されたファイル・フォーマットの一部であるチャンクおよびリストを規定するだけでなく、そのファイルが、RIFFおよび/またはAVIデコーダによるそのファイルを読取不能とせずにRIFFおよび/またはAVIファイル・フォーマット定義外のリストおよび/またはチャンクを含むことも許容する点において、融通性が高い。実際問題としてAVI(および同様のRIFF)デコーダは、AVIファイル・フォーマット定義に見出されないヘッダ情報を含むリストおよびチャンクを単に無視する様に実現される。AVIデコーダは、それでもこれらの非AVIチャンクおよびリストを読み取らなければならい場合、AVIデコーダの動作は遅くなるが、その他の場合は、一般に、それらはAVIデコーダに対して効果を有さずにAVIデコーダにより無視される。
【0119】
図2.0.には、本発明の実施例によるマルチメディア・ファイルが示される。図示されたマルチメディア・ファイル30は、キャラクタ・セット・チャンク(「CSET」チャンク)32、情報リスト・チャンク(「INFO」リスト・チャンク)34、ファイル・ヘッダ・チャンク(「hdrl」リスト・チャンク)36、メタデータ・チャンク(「DXDT」チャンク)38、メニュー・チャンク(「DMNU」チャンク)40、ジャンク・チャンク(「junk」チャンク)41、ムービー・リスト・チャンク(「movi」リスト・チャンク)42、選択的インデックス・チャンク(「idxl」チャンク)44および第2メニュー・チャンク(「DMNU」チャンク)46を含む。これらのチャンクの一定部分および他のチャンクの一部はAVIファイル・フォーマットにおいて規定されるが、その他のチャンクはAVIファイル・フォーマットには含まれない。全ての場合ではないが多くの場合に以下の考察は、AVIファイル・フォーマットの一部として規定されたチャンクまたはチャンク部分を特定する。
【0120】
図2.0.1.には、本発明の実施例による別のマルチメディア・ファイルが示される。マルチメディア・ファイル30’は、そのファイルが複数の連結「RIFF」チャンクを含むことを除き、図2.0.に示されたファイルと同様である。その「RIFF」チャンクは、図2.0.に示された「RIFF」チャンクであって第2「DMNU」チャンク46を除外し得るか又は「DMNU」チャンク46’の形態のメニュー情報を含み得る「RIFF」チャンクを含み得る。
【0121】
図示の実施例においてマルチメディアは、複数の連結「RIFF」チャンクを含み、その場合に第1「RIFF」チャンク50は、キャラクタ・セット・チャンク(「CSET」チャンク)32’、情報リスト・チャンク(「INFO」リスト・チャンク)34’、ファイル・ヘッダ・チャンク(「hdrl」リスト・チャンク)36’、メタデータ・チャンク(「DXDT」チャンク)38’、メニュー・チャンク(「DMNU」チャンク)40’、ジャンク・チャンク(「junk」チャンク)41’、ムービー・リスト・チャンク(「movi」リスト・チャンク)42’および選択的インデックス・チャンク(「idxl」チャンク)44’を含む。第2「RIFF」チャンク52は、第2メニュー・チャンク(「DMNU」チャンク)46’を含む。「RIFF」メニュー・チャンク52の後には、付加的「RIFF」チャンク54が含まれ得る。付加的「RIFF」チャンクは、AVIファイル・フォーマットに準拠する独立メディアを含み得る。一実施例において第2メニュー・チャンク46’および付加的「RIFF」チャンクは、その4個のキャラクタ・コードの第1の2個のキャラクタは、第2の2個のキャラクタとして現れ、かつ、その4個のキャラクタ・コードの第2の2個のキャラクタは第1の2個のキャラクタとして現れるように、(AVIフォーマットで規定されると共に以下で論じられる)特殊な4個のキャラクタ・コードを有する。
【0122】
2.1.「CSET」チャンク
「CSET」チャンク32は、Microsoft社により策定されたオーディオ・ビデオ・インターリーブ・ファイル・フォーマット(AVIファイル・フォーマット)において規定されたチャンクである。「CSET」チャンクは、マルチメディア・ファイルのキャラクタ・セットおよび言語情報を規定する。本発明の実施例による「CSET」チャンクを包含することはオプション的である。
【0123】
本発明の一実施例によるマルチメディア・ファイルは、「CSET」チャンクを使用せずに、言語情報に対してインターネット・エンジニアリング・タスク・フォースにより規定されたRFC 3066言語仕様と組み合わされた既定によるキャラクタ・セットに対して、ユニコード・コンソーシアムにより規定されたUTF-8を使用する。
【0124】
2.2.「INFO」リスト・チャンク
「INFO」リスト・チャンク34は、マルチメディア・ファイルの内容の識別を助力する情報を記憶し得る。「INFO」リストはAVIファイル・フォーマットにおいて規定されると共に、本発明の実施例によるマルチメディア・ファイルにそれを含めることは選択的である。「DXDT」チャンクを含む多くの実施例は、「INFO」リスト・チャンクを含まない。
【0125】
2.3.「hdrl」リスト・チャンク
「hdrl」リスト・チャンク38は、AVIファイル・フォーマットに規定されると共に、マルチメディア・ファイルにおけるデータのフォーマットに関する情報を提供する。「hdrl」リスト・チャンク、または、同様の記述情報を含むチャンクは、概略的に必要とされる。「hdrl」リスト・チャンクは、各ビデオ・トラック、各オーディオ・トラックおよび各サブタイトルトラックに対するチャンクを含む。
【0126】
図2.1.には、1つのビデオトラック62、2つのオーディオ・トラック64、外部のオーディオトラック66、2つのサブタイトルトラック68および外部のサブタイトルトラック70を含む本発明の一実施例による「hdrl」リストチャンク38が示される。「hdrl」リスト60は、「avih」チャンクを含む。「avih」チャンク60は、ファイル内におけるストリームの本数、マルチメディア・ファイル内に含まれたビデオの幅および高さなどのファイル全体に対する包括的情報を含む。その「avih」チャンクは、AVIファイル・フォーマットに従い実現され得る。
【0127】
「avih」チャンクに加え、「hdrl」リストは各オーディオ、ビデオおよびサブタイトルトラックに対するストリーム記述子リストを含む。一実施例においてそのストリーム記述子リストは、「strl」チャンクを用いて実現される。図2.2.には、本発明の実施例による「strl」チャンクが示される。各「strl」チャンクは、マルチメディア・ファイルにおける各トラックを記述する役割を果たす。マルチメディア・ファイル内におけるオーディオ、ビデオおよびサブタイトルトラックに対する「strl」チャンクは、「strh」チャンク92、「strf」チャンク94、「strd」チャンク96および「strn」チャンク98を参照する「strl」チャンクを含む。これらのチャンクの全ては、AVIファイル・フォーマットに従い実現され得る。特に興味があるのは、メディア・トラックのタイプを特定する「strh」チャンク92、および、ビデオがデジタル著作権管理により保護されているか否かを表すべく改変され得る「strd」チャンク96である。本発明の実施例によるデジタル著作権管理の種々の実施方式の考察は、以下に提供される。
【0128】
本発明の実施例によるマルチメディア・ファイルは、付加的オーディオ・トラックまたは付加的サブタイトルトラックなどのマルチメディア情報を保持する外部ファイルに対するリファレンスを含み得る。これらのトラックに対するリファレンスは、「hdrl」チャンクまたは「junk」チャンク41のいずれかに含まれ得る。いずれの場合でもリファレンスは、ローカル・ファイルまたはリモートで記憶されたファイルのいずれかを参照する「strl」チャンク90の「strh」チャンク92内に含まれ得る。参照されるファイルは、標準的なAVIファイル、または、付加的トラックを含む本発明の実施例によるマルチメディア・ファイルであり得る。
【0129】
付加的な実施例において、参照されるファイルは、参照を行うファイル内に存在し得るチャンクであって、「DMNU」チャンク、「DXDT」チャンク、および、マルチメディア・プレゼンテーションに対してオーディオ、ビデオおよび/またはサブタイトルトラックと関係付けられたチャンクの内の任意のものを含み得る。たとえば第1マルチメディア・ファイルは、その第1マルチメディア・ファイルの「movi」リスト・チャンク内に配置された第1マルチメディア・プレゼンテーションと、第2マルチメディア・ファイルの「movi」リスト・チャンク内の第2マルチメディア・プレゼンテーションとを参照する(以下において更に詳細に論じられる)「DMNU」チャンクを含み得る。代替的に、両方の「movi」リスト・チャンクは同一のマルチメディア・ファイル内に含まれ得るが、これは、「DMNU」チャンクが配置されるファイルと同一のファイルである必要はない。
【0130】
2.4.「DXDT」チャンク
「DXDT」チャンク38は、いわゆる「メタデータ」を含む。本発明の実施例によるマルチメディア・ファイルの「DXDT」チャンク内に記憶された「meta data」は、タイトル、作者、著作権保持者およびキャストなどのコンテンツ固有情報を記憶すべく使用され得る。
これに加え、使用されるCLIオプションおよび各パスの後における量子化数(quantizer)分布などの、マルチメディア・ファイルを符号化すべく使用されるコーデック(codec)に関する技術的詳細が提供され得る。
【0131】
一実施例においてメタデータは一連のステートメントとして「DXDT」チャンク内に表され、その場合に各ステートメントは主部(subject)、述部(predicate)、目的部(object)および出典(authority)を含む。主部は、記述されている処に対する参照である。
主部は、ファイル、アイテム、人物または組織を参照し得る。主部は、記述を行い得る特性を有する任意のものを参照し得る。述部は、記述されている主部の特性を特定する。目的部は特定された主部の特性の記述であり、かつ、出典は情報のソースを特定する。
【0132】
以下の表は、種々の「meta data」が目的部、述部、主部および出典として如何に表され得るかの例を示している。
【0133】
【表1】
【0134】
【表2】
【0135】
【表3】
【0136】
一実施例において、主部、述部、目的部および出典の表現は、ラベル付き有向グラフ(DLG:Directed-Labeled Graphs)を形成し得るデータの2進表現を用いて実現される。DLGは、リソースもしくはリテラル(literal)のいずれかであるノードから成る。
リソースは、インターネット・エンジニアリング・タスク・フォースによりRFC2396(http://www.ictf.org/rfc/rfc2396.txt)において規定された汎用リソース識別子(URI)などの命名規則に準じ得るか、または、システム自体に固有のデータを参照し得る識別子である。リテラルは、リファレンスではなく実際の値の表現である。
【0137】
DLGの利点は、これによれば、映画の出演者などの同一タイプである可変数のデータが含まれ得ることである。表1に示された例においては、3人の出演者が含まれる。但し、任意数の出演者が含まれ得る。DLGはまた、他のデータタイプに対する関連接続も許容する。表1においては、主部「_: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)により特定されるタイトルは、「マトリックス・リローデッド」であるというデータを含む。
【0138】
表1における付加的な「meta data」ステートメントは、キアヌ・リーブスはネオの役を演じた出演者であったこと、および、ラリーおよびアンディ・ウォシャウスキーの両名は監督であったことを特定している。「meta data」においては技術的情報も表現される。「meta data」ステートメントは、“_:file281”はトラック“_:track#dc00”を含むことを特定する。「meta data」は、ビデオ・トラックの解像度、ビデオ・トラックの認証レベル、および、コーデックの設定を含む情報を提供する。表1においては示されないが、「meta data」は、符号化の時点でトラックに割当てられた一意的識別子も含み得る。
一意的識別子が使用されるときに同一のコンテンツを複数回符号化すると、コンテンツの符号化バージョンの各々に対して異なる識別子に帰着する。但し、符号化されたビデオ・トラックの複製物は、それがコピーされた元のトラックの識別子を保持する。
【0139】
表1に示されたエントリは、UPnPフォーラムにより規定されたUPnPボキャブラリ(http://www.upnpforum.org参照)などの他のボキャブラリにより置換され得る。別の代替策は、MPEG−21規格に向けた作業の一部として国際標準化機構により開発されたデジタルアイテム宣言言語(DIDL:Degital Item Declaration Language)またはDIDL-Liteボキャブラリである。以下は、UPnPボキャブラリにおける述部の例である。
【0140】
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
【0141】
全ての「meta data」に対する出典は、「_:auth42」である。「meta data」ステートメントは、「_:auth42」は「ワーナー・ブラザース」であることを示している。出典によれば、ファイルの品質と、そのファイルに関係付けられた「meta data」ステートメントとの両方の評価が可能とされる。
【0142】
グラフ内へのノードは、命名されたリソース・ノードを介して接続される。「meta data」のステートメントは、主部ノード、述部ノードおよび目的部ノードから成る。オプション的に、出典ノードは「meta data」ステートメントの一部としてのDLGに対して接続され得る。
【0143】
各ノードに対し、そのノードの機能性を更に説明する一定の特性が在る。可能なタイプは、ANSIのCプログラミング言語を用いて以下の如く表され得る。
/**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
【0144】
「DXDT」チャンク内に含まれる「meta data」チャンクを表す(ANSIのCプログラミング言語で表される)データ構造の例は以下のようである。
typedef struct RDFDataStruct
{
RDFHeader Header;
uint32_t numOfStatements;
RDFStatement statements[RDF_MAX_STATEMENTS];
} RDFData
「RDFData」チャンクは、「RDFHeader」チャンクと称されるチャンク、値「numOfStatements」、および、「RDFStatement」チャンクのリストを含む。
【0145】
「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;
【0146】
「RDFHeader」チャンクは、上位互換性を可能とするリソース記述フォーマットのバージョンを表す数「バージョン(version)」を含む。ヘッダは、「RDFHeader」チャンクの一部をも形成するリスト「スキーマ(Schema)」における「RDFSchema」チャンクの個数を表す第2の数「numOfSchemas」を含む。幾つかの実施例において「RDFSchema」チャンクは、複雑なリソースが更に効率的に表されるのを可能とすべく用いられる。一実施例において「RDFSchema」チャンクに含まれるデータは以下のように表され得る(ANSI Cで表される)。
typedef struct RDFSchemaStruct
{
wchar_t* prefix;
wchar_t* uri;
} RDFSchema;
【0147】
「RDFSchema」チャンクは、「接頭辞(prefix)」として識別される「dc」などの第1のテキスト文字列と、「uri」として識別される「http://purl.org/dc/elements/1.1/」などの第2のテキスト文字列とを含む。「prefix」は、「uri」の代わりに「meta data」で使用され得る用語を定義する。「uri」は、特定の規格化ボキャブラリに準じ得るか、特定システムに対する特定ボキャブラリとされ得る汎用リソース識別子である。
【0148】
「RDFData」チャンクの考察に戻る。「RDFHeader」チャンクに加えて「RDFData」チャンクは、値「numOfStatements」、および、「RDFStatement」チャンクのリスト「Statement」をも含んでいる。値「numOfStatements」は、情報を含むリスト「Statement」における「RDFStatement」チャンクの実際の個数を表す。一実施例において「RDFStatement」チャンクに含まれるデータは以下の如く表され得る(ANSI Cで表される)。
typedef struct RDFStatementStruct
{
RDFSubject subject;
RDFPredicate predicate;
RDFObject object;
RDFAuthority authority;
} RDFStatement;
【0149】
各「RDFStatement」チャンクは、マルチメディア・ファイルに関する「meta data」を含む。チャンク「subject」、「predicate」、「object」および「authority」は、上述の「meta data」の種々の構成要素を含むべく用いられる。
【0150】
「subject」は、上述の「meta data」の主部部分を表す「RDFSubject」チャンクである。一実施例において「RDFSubject」チャンクに含まれたデータは、以下の如く表され得る(ANSI Cで表される)。
typedef struct RDFSubjectStruct
{
uint16_t type;
wchar_t* value;
} RDFSubject;
【0151】
上記「RDFSubject」チャンクは、データがリソースであるかまたは「meta data」の匿名ノードであることを表す値「type」と、「meta data」の主部を表すデータを含むユニコード・テキスト文字列とを含む。「RDFSchema」チャンクが定義されている実施例において値は、リソースに対する直接的リファレンスの代わりに、定義済み用語とされ得る。
【0152】
「RDFStatement」チャンクにおける「predicate」は、「meta data」の述部部分を表す「RDFPredicate」チャンクである。一実施例において「RDFPredicate」チャンク内に含まれるデータは、以下の如く表され得る(ANSI Cで表される)。
{
uint16_t type;
wchar_t* value;
} RDFPredicate;
【0153】
上記の「RDFPredicate」チャンクは、データが述部URIであるかまたは「meta data」の順序リスト・エントリであることを表す値「type」と、「meta data」の述部を表すデータを含むテキスト文字列「value」とを含む。「RDFSchema」チャンクが定義されている実施例において値は、リソースに対する直接的リファレンスの代わりに、定義済み用語とされ得る。
【0154】
「RDFStatement」チャンクにおける「object」は、「meta data」の目的部部分を表す「RDFObject」チャンクである。一実施例において「RDFObject」チャンクに含まれたデータは、以下の如く表され得る(ANSI Cで表される)。
typedef struct RDFObjectStruct
{
uint16_t type;
wchar_t* language;
wchar_t* dataTypeURI;
wchar_t* value;
} RDFObject;
【0155】
上記の「RDFObject」チャンクは、データが、UTF−8リテラル文字列、リテラル整数または「meta data」のリテラルXMLデータであることを表す値「type」を含む。チャンクは、3個の値も含む。第1の値「language」は、「meta data」が表現される言語を表すべく用いられる(たとえば映画のタイトルは異なる言語に変更され得る)。幾つかの実施例においては、言語を識別すべく標準的な表現(インターネット・エンジニアリング・タスク・フォースにより指定された言語の識別に対するタグであるRFC3066など、http://www.ietf.org/rfc/rfc3066.txtを参照)が使用され得る。第2の値である「dataTypeURI」は、「value」フィールド内に含まれたデータのタイプが「type」フィールドにより明示的に表され得ないのであれば、そのデータのタイプを表すべく用いられる。dataTypeURIにより指定されたURIは、使用される特定形式のデータを記述すべく使用された一般的なRDF URIボキャブラリを指し示す。URIが表現され得る異なるフォーマットは、http://www.w3.org/TR/rdf-concepts/#section-Datatypesで記述される。一実施例において「value」は「ワイド文字(wide character)」である。他の実施例において「value」は、画像またはビデオシーケンスに対する単一ビットからの種々の形式のデータの内の任意のものとされ得る。「value」は、「meta data」の目的部部分を含む。
【0156】
「RDFStatement」チャンクにおける「authority」は、「meta data」の出典部分を表す「RDFAuthority」チャンクである。一実施例において「RDFAuthority」チャンクに含まれるデータは以下の如く表され得る(ANSI Cで表される)。
typedef struct RDFAuthorityStruct
{
uint16_t type;
wchar_t* value;
} RDFAuthority;
【0157】
上記の「DFAuthority」データは、そのデータがリソースであるか「meta data」の匿名ノードであるかを表す値「type」を含む。「value」は、「meta data」に対する出典を表すデータを含む。「RDFSchema」チャンクが定義された実施例において、値はリソースに対する直接的リファレンスの代わりに定義済み用語とされ得る。
【0158】
図2.3.には、本発明の実施例によるマルチメディア・ファイルの「DXDT」チャンクを記憶する概念的表現が示される。「DXDT」チャンク38は、「RDFHeader(RDFヘッダ)」チャンク110、「numOfStatements(ステートメント数)」値112、および、RDFStatementチャンク114の表を含む。RDFHeaderチャンク110は、「バージョン(version)」値116、「numOfSchemas(スキーマ数)」値118、「スキーマ(Schema)」チャンク120の表を含む。各「RDFステートメント(RDFStatement)」チャンク114は、「RDF主部(RDFSubject)」チャンク122、「RDF述部(RDFPredicate)」チャンク124、「RDF目的部(RDFObject)」チャンク126および「RDF出展(RDFAuthority)」チャンク128を含む。「RDF主部(RDFSubject)」チャンクは、「タイプ(type)」値130および「バリュー(value)」値132を含む。「RDF述部(RDFPredicate)」チャンク124もまた、「タイプ(type)」値134および「バリュー(value)」値136を含む。「RDF述部(RDFObject)」チャンク126は、「タイプ(type)」値138、(図においては「lang」として示された)「言語(language)」値140、(図においては「dataT」として示された)「URIデータタイプ(dataTypeURI)」値142、および、「バリュー(value)」値144を含む。「RDF出展(RDFAuthority)」チャンク128は、「タイプ(type)」値146および「バリュー(value)」値148を含む。図示された「DXDT」チャンクは、1つの「スキーマ(Schema)」チャンクおよび1つの「RDFステートメント(RDFStatement)」チャンクを含んで示されるが、当業者であれば、異なる個数の「スキーマ(Schema)」チャンクおよび「RDFステートメント(RDFStatement)」チャンクが「メタデータ」を記述するチャンクにおいて使用され得ることを容易に理解し得よう。
【0159】
以下において論じられるように、本発明の実施例によるマルチメディア・ファイルは連続的に改変および更新され得る。予め「meta data」を決定し、ファイル自体、および(たとえばインターネットを介して)遠隔的にアクセスされる「meta data」に対して関係付けることは困難であり得る。典型的には、ファイルの内容を記述するために本発明の実施例によるマルチメディア・ファイル内に十分な「meta data」が含まれる。そのファイルをレビューするデバイスが、そのファイル内から参照された「meta data」を含む他のデバイスに対してネットワークを介してアクセスし得る場合、付加的情報が獲得され得る。
【0160】
上述の「meta data」を表す方法は拡張可能であると共に、ファイルに対する必要性が経時的に変化するにつれ、そのファイル内に記憶される異なる「meta data」フィールドを付加および除去する能力を提供し得る。これに加え、「meta data」の表現は改訂版間で上位互換であり得る。
【0161】
本発明の実施例に従い「meta data」が表される構造化様式は、デバイスが、マルチメディア・ファイルのコンテンツを良好に決定すべくそのマルチメディア・ファイルに対して問合せ(query)を行うことを可能にする。その場合の問合せは、マルチメディア・ファイルの内容を更新し、マルチメディア・ファイルに関する付加的な「meta data」を獲得し、そのファイルの内容に関するメニューを生成し、または、標準的フォーマットで表されたデータの自動処理を伴う他の任意の機能を実施するために使用され得る。これに加え、「meta data」の解析可能な各エレメントの長さを定義すると、家電機器などの様にメモリの量が限られたデバイスが「meta data」にアクセスする容易さが高められ得る。
【0162】
他の実施例において「meta data」は、各「meta data」断片に対する個々のチャンクを用いて表される。本発明による幾つかの「DXDT」チャンクとしては、上述の如く符号化された「meta data」を含む2進チャンク、および、上述の如くまたは別のフォーマットのいずれかでフォーマットされた個別の「meta data」断片を含む付加的チャンクが含まれる。「DXDT」チャンクに2進「meta data」が含まれる実施例において、その2進「meta data」は64ビットの符号化ASCIIを用いて表され得る。他の実施例においては、他の2進表現が使用され得る。
【0163】
図2.3.1.には、本発明による「DXDT」チャンクに含まれ得る個別チャンクの例が示される。「メタデータ」は、「PixelAspectRatioMetaData(ピクセル縦横比メタデータ)」チャンク152a、「EncoderURIMetaData(エンコードURIメタデータ)」チャンク152b、「CodecSettingsMetaData(コーデック設定メタデータ)」チャンク152c、「FrameTypeMetaData(フレームタイプメタデータ)」チャンク152d、「VideoResolutionMetaData(ビデオ解像度メタデータ)」チャンク152e、「PublisherMetaData(出版社メタデータ)」チャンク152f、「CreatorMetaData(創作者メタデータ)」チャンク152g、「GenreMetaData(ジャンルメタデータ)」チャンク152h、「CreatorToolMetaData(創作者ツールメタデータ)」チャンク152i、「RightsMetaData(権利メタデータ)」チャンク152j、「RunTimeMetaData(ランタイムメタデータ)」チャンク152k、「QuantizerMetaData(量子化器メタデータ)」チャンク152l、「CodecInfoMetaData(コーデック情報メタデータ)」チャンク152m、「EncoderNameMetaData(エンコーダ名称メタデータ)」チャンク152n、「FrameRateMetaData(フレーム速度メタデータ)」チャンク152o、「InputSourceMetaData(入力ソースメタデータ)」チャンク152p、「FileldMetaData(フィールドメタデータ)」チャンク152q、「TypeMetaData(タイプメタデータ)」チャンク152r、「TitleMetaData(タイトルメタデータ)」チャンク152sおよび/または「CertLevelMetaData(認証レベルメタデータ)」チャンク152tを含み得る「メタデータ」チャンク150を含む。
【0164】
「PixelAspectRatioMetaData」チャンク152aは、符号化されたビデオのピクセル・アスペクト比に関する情報を含む。「EncoderURIMetaData」チャンク152bは、エンコーダに関する情報を含む。「CodecSettingsMetaData」チャンク152cは、ビデオを符号化するために使用されたコーデックの設定に関する情報を含む。「FrameTypeMetaData」チャンク152dは、ビデオ・フレームに関する情報を含む。「VideoResolutionMetaData」チャンク152eは、符号化されたビデオのビデオ解像度に関する情報を含む。「PublisherMetaData」チャンク152fは、メディアを発行した人物または組織に関する情報を含む。「CreatorMetaData」チャンク152gは、内容の創作者に関する情報を含む。「GenreMetaData」チャンク152hは、メディアのジャンルに関する情報を含む。「CreatorToolMetaData」チャンク152iは、ファイルを生成すべく使用されたツールに関する情報を含む。「RightsMetaData」チャンク152jは、DRMに関する情報を含む。
「RunTimeMetaData」チャンク152kは、メディアの実行時間に関する情報を含む。「QuantizerMetaData」チャンク152lは、ビデオを符号化すべく使用された量子化器に関する情報を含む。「CodecInfoMetaData」チャンク152mは、コーデックに関する情報を含む。「EncoderNameMetaData」チャンク152nは、エンコーダの名称に関する情報を含む。「FrameRateMetaData」チャンク152oは、メディアのフレーム速度に関する情報を含む。「InputSourceMetaData」チャンク152pは、入力ソースに関する情報を含む。「FileldMetaData」チャンク152qは、ファイルに対する一意的識別子を含む。「TypeMetaData」チャンク152rは、マルチメディア・ファイルの形式に関する情報を含む。「TitleMetaData」チャンク152sはメディアのタイトルを含み、かつ、「CertLevelMetaData」チャンク152tはメディアの認証レベルに関する情報を含む。他の実施例においては、付加的な「メタデータ」を含む付加的チャンクが含まれ得る。幾つかの実施例において「メタデータ」チャンク内には、上述された如く2進フォーマットで「メタデータ」を含むチャンクが含まれ得る。一実施例において2進「メタデータ」のチャンクは、64ビットASCIIとして符号化される。
【0165】
2.5.「DMNU」チャンク
図2.0.および図2.0.1.を参照すると、第1「DMNU」チャンク40(40’)および第2「DMNU」チャンク46(46’)が示される。図2.0.において第2「DMNU」チャンク46は、マルチメディア・ファイル30の一部を形成する。図2.0.1.に示された実施例において「DMNU」チャンク46’は、別個のRIFFチャンク内に含まれる。
両方の場合、第1および第2の「DMNU」チャンクは、索行可能メニューを表示すべく使用され得るデータを含む。一実施例において第1「DMNU」チャンク40(40’)は、拡張バックグラウンド動画などの進歩的特徴を含まない簡素なメニューを生成すべく使用され得るデータを含む。これに加えて第2「DMNU」チャンク46(46’)は、拡張動画式バックグラウンドなどの進歩的特徴を含む更に複雑なメニューを生成すべく使用され得るデータを含む。
【0166】
幾つかの実施例において、単純なメニューおよび複雑なメニューを配備すると、デバイスは自身が表示を意図するメニューを選択することが可能とされ得る。「movi」リスト・チャンク42の前に、その2つのメニューの内の小寸の方を載置すると、メニューを表示し得ない本発明の実施例によるデバイスは、表示され得ない情報を迅速に飛び越し得る。
【0167】
他の実施例において、単一メニューを生成するために必要なデータは、第1および第2「DMNU」チャンク間に分割される。代替的に「DMNU」チャンクは、単一群のメニューまたは複数群のメニューに対するデータを含む「movi」チャンクの前の単一チャンクとされ得る。他の実施例において「DMNU」チャンクは、マルチメディア・ファイルの全体における他の箇所に配置された単一または複数のチャンクとされ得る。
【0168】
本発明による幾つかのマルチメディア・ファイルにおいて第1「DMNU」チャンク40(40’)は、第2「DMNU」チャンク46(46’)における「richer」メニューに基づき自動的に生成され得る。メニューの自動生成は、以下においてより詳細に論じられる。
【0169】
図2.4.には、本発明の実施例による「DMNU」チャンクの構造が示される。「DMNU」チャンク158は、メニュー・チャンク160および「MRIF」チャンク162を含むリスト・チャンクである。メニュー・チャンクは、各メニューを構築して索行するために必要な情報を含む。「MRIF」チャンクは、各メニューに対してサブタイトル、バックグラウンド・ビデオおよびバックグラウンド・オーディオを提供すべく使用され得るメディア情報を含む。幾つかの実施例において「DMNU」チャンクは、各メニューを幾つかの異なる言語で表示させ得るメニュー情報を含む。
【0170】
一実施例において「WowMenu」チャンク160は、図2.5.に概念的に示されたメニュー・チャンク・オブジェクトの階層を含む。その階層の頂部には、「ワウメニューマネージャ(WowMenuManager)」チャンク170が在る。その「WowMenuManager」チャンクは、1つ以上の「言語メニュー(LanguageMenus)」チャンク172および1つの「メディア(Media)」チャンク174を含み得る。
【0171】
「LanguageMenus」チャンク172を使用すると、「DMNU」チャンク158は異なる言語でメニュー情報を含み得る。各「LanguageMenus」チャンク172、指定された言語で完全なメニュー群を生成すべく使用される情報を含む。ゆえに「LanguageMenus」チャンクはその「LanguageMenus」チャンクに関係付けられた情報の言語を特定する識別子を含む。その「LanguageMenus」チャンクはまた、「ワウメニュー(WowMenu)」チャンク175のリストも含む。
【0172】
各「WowMenu」チャンク175は、特定メニューに対して画面上に表示されるべき情報の全てを含む。この情報は、バックグラウンド・ビデオおよびオーディオを含み得る。情報はまた、他のメニューにアクセスすべく、または、メニューを抜け出してマルチメディア・ファイルの一部の表示を開始すべく使用され得るボタン動作に関するデータも含み得る。一実施例において「WowMenu」チャンク175は、メディアに対するリファレンスのリストを含む。これらのリファレンスは「Media」チャンク174内に含まれた情報を参照するが、これは以下において更に論じられる。メディアに対するリファレンスは、メニューに対するバックグラウンド・ビデオおよびバックグラウンド・オーディオを定義し得る。「WowMenu」チャンク175はまた、メニューが最初にアクセスされたときに特定ボタンを強調するために使用され得るオーバレイも定義する。
【0173】
これに加えて各「WowMenu」チャンク175は、所定数の「ボタンメニュー(ButtonMenu)」チャンク176を含む。各「ButtonMenu」チャンクは、画面上ボタンのプロパティを定義する。「ButtonMenu」チャンクは、ユーザによりボタンが強調されたときに使用するオーバレイ、ボタンの名称、および、メニューを通してナビゲートしているユーザにより実施された種々の動作に応じて行うべきことなどの事項を記述し得る。動作に対する応答は、「アクション(Action)」チャンク178を参照することで定義される。たとえばボタンを選択するなどの単一動作は、幾つかの「アクション」チャンクに対するアクセスに帰着し得る。画面上ポインタが制約のない様式でディスプレイ上を動き回ることを可能とするマウスなどのデバイスを用いてユーザがメニューと対話し得るという実施例において、ボタンの画面上箇所は「MenuRectangle(メニュー矩形)」チャンク180を用いて定義され得る。ボタンの画面上箇所を認識すると、システムは、自由範囲のデバイスを用いるときにユーザはボタンを選択しているか否かを決定し得る。
【0174】
各「Action」チャンクは、「プレイアクション(PlayAction)」チャンク182、「MenuTransitionAction(メニュー遷移アクション)」チャンク184、「ReturnToPlayAction(プレイに戻るアクション)」チャンク186、「AudioSelectAction(オーディオ選択アクション)」チャンク188、「SubtitleSelectAction(サブタイトル選択アクション)」チャンク190および「ButtonTransitionAction(ボタン遷移アクション)」チャンク191などの多数の異なる種々の動作関連チャンクの内の1つ以上を特定する。「プレイアクション」チャンク182は、マルチメディア・ファイル内におけるビデオ、オーディオおよびサブタイトルトラックの各々の一部を特定する。「プレイアクション」チャンクは、「MediaTrack」チャンク(以下の考察を参照)に対するリファレンスを用いてビデオ・トラックの一部を参照する。「プレイアクション」チャンクは、「SubtitleTrack(サブタイトルトラック)」チャンク192および「AudioTrack(オーディオトラック)」194チャンクを用いてオーディオおよびサブタイトルトラックを特定する。「SubtitleTrack」および「AudioTrack」チャンクは両者ともに、「MediaTrack(メディアトラック)」チャンク198に対するリファレンスを含む。「プレイアクション」チャンクが本発明の実施例による動作の基礎を形成するとき、選択されたオーディオおよびサブタイトルトラックは、既定として最初に設定された変数の値であって可能的にはその後にメニューに対するユーザの対話により改変される変数の値により決定される。
【0175】
各「MenuTransitionAction」チャンク184は、「WowMenu」チャンク175に対するリファレンスを含む。このリファレンスは、別のメニューへと遷移してそれを表示するための情報を獲得すべく使用され得る。
【0176】
各「ReturnToPlayAction」チャンク186は、ユーザがメニューを呼び出す前にアクセスされていたマルチメディア・ファイルの部分へとプレーヤが戻るのを可能とする情報を含む。
【0177】
各「AudioSelectAction」チャンク188は、特定のオーディオ・トラックを選択すべく使用され得る情報を含む。一実施例においてオーディオ・トラックは、本発明の実施例によるマルチメディア・ファイル内に含まれたオーディオ・トラックから選択される。他の実施例においてオーディオ・トラックは、外部的に参照されるファイル内に配置され得る。
【0178】
各「SubtitleSelectAction」チャンク190は、特定のサブタイトルトラックを選択すべく使用され得る情報を含む。一実施例においてサブタイトルトラックは、本発明の実施例によるマルチメディア・ファイル内に含まれたサブタイトルから選択される。他の実施例においてサブタイトルトラックは、外部的に参照されるファイル内に配置され得る。
【0179】
各「ButtonTransitionAction」チャンク191は、同一メニューにおける別のボタンへと遷移するために使用され得る情報を含む。これは、ボタンに関係付けられた他の動作が実施されてから実施される。
【0180】
「メディア(Media)」チャンク174は、所定数の「MediaSource」チャンク166および「MediaTrack」チャンク198を含む。「メディア」チャンクは、機能およびメニュー・システムにより使用されるマルチメディア・トラックの全て(たとえばオーディオ、ビデオ、サブタイトルなど)を定義する。各「MediaSource」チャンク196は、本発明の実施例によるマルチメディア・ファイル内のRIFFチャンクであって、それが更に複数のRIFFチャンクを含み得るというRIFFチャンクを特定する。各「MediaTrack」チャンク198は、「MediaSource」チャンクにより特定されたRIFFチャンク内のマルチメディア・トラックの一部を特定する。
【0181】
「MRIF」チャンク162は本質的に、RIFFフォーマットに従うそれ自体のスモール・マルチメディア・ファイルである。「MRIF」チャンクは、メニューに対するバックグラウンド・オーディオおよびビデオおよびオーバレイを提供するために使用され得るオーディオ、ビデオおよびサブタイトルトラックを含む。「MRIF」チャンクは、強調されたメニュー・ボタンを表すオーバレイとして使用されるべきビデオも含む。必要とされるメニュー・データが少ない実施例においてバックグラウンド・ビデオは、静止フレーム(AVIフォーマットの変形例)または同一フレームのスモール・シーケンスとされ得る。他の実施例においては、バックグラウンド・ビデオを提供すべく更に精巧なシーケンスのビデオが使用され得る。
【0182】
上述の如く、「WowMenu」チャンク175の一部および「WowMenu」チャンク自体を形成する種々のチャンクは、実際のメディア・トラックに対するリファレンスを含む。これらのリファレンスの各々は典型的に、RIFFチャンクの「hdrl」リスト・チャンク内に定義されたメディア・トラックに対するものである。
【0183】
図2.6.には、本発明による「DMNU」チャンクを生成すべく使用され得る他のチャンクが示される。「DMNU」チャンクは「WowMenuManager」チャンク170’を含む。「WowMenuManager」チャンク170’は、少なくとも一個の「LanguageMenus」チャンク172’、少なくとも一個の「メディア」チャンク174’、および、少なくとも一個の「TranslationTable」チャンク200を含み得る。
【0184】
「LanguageMenus」チャンク172’の内容は、図2.5.に示された「LanguageMenus」チャンク172のそれと非常に似ている。主な相違点は、「プレイアクション」チャンク182’が「SubtitleTrack」チャンク192および「AudioTrack」チャンク194を含まないことである。
【0185】
「Media」チャンク174’は、図2.5.に示された「Media」チャンク174と相当に異なる。「Media」チャンク174’は、少なくとも一個の「タイトル(Title)」チャンク202および少なくとも一個の「メニュートラック(MenuTracks)」チャンク204を含む。「タイトル」チャンクは、マルチメディア・ファイル内のタイトルを参照する。
上述された如く本発明の実施例によるマルチメディア・ファイルは1つ以上のタイトル(たとえば、テレビ・シリーズにおける複数のエピソード、完全長の番組の関連シリーズ、または、単に異なる番組の選択)を含み得る。「メニュートラック」チャンク204は、メニュー表示、および、その表示に付随するオーディオ・サウンドトラックおよびサブタイトルを生成すべく使用されるメディア情報に関する情報を含む。
【0186】
「タイトル」チャンクは、少なくとも一個の「チャプター(Chapter)」チャンク206を含み得る。「チャプター」チャンク206は、特定タイトル内のシーンを参照する。
「チャプター」チャンク206は、その「チャプター」チャンクにより表されるシーンに対応するビデオ・トラック、各オーディオ・トラックおよび各サブタイトルトラックの部分に対するリファレンスを含む。一実施例においてリファレンスは、図2.5.に関して上述されたのと同様の「メディアソース(MediaSource)」チャンク196’および「メディアトラック(MediaTrack)」チャンク198’を用いて実現される。幾つかの実施例において「メディアトラック」チャンクはビデオ・トラックの適切な部分を参照し、かつ、所定数の付加的な「メディアトラック」チャンクは各々、オーディオ・トラックまたはサブタイトルトラックの内の1つのトラックを参照する。一実施例において、特定のビデオ・トラックに対応するオーディオ・トラックおよびサブタイトルトラックの全ては、別個の「メディアトラック」チャンクを用いて参照される。
【0187】
上述された如く「メディアトラック」チャンク204は、メニューのオーディオ、ビデオおよびオーバレイ・メディアを生成すべく使用されるメディアに対するリファレンスを含む。一実施例においてメディア情報に対する参照は、「メディアトラック」チャンク内に含まれた「メディアソース」チャンク196’および「メディアトラック」チャンク198’を用いて為される。一実施例において「メディアソース」チャンク196’および「MediaTrack」チャンク198’は、図2.5.に関して記述された様式で実現される。
【0188】
「翻訳テーブル(TranslationTable)」チャンク200は、各タイトルおよびチャプタを種々の言語で記述するテキスト文字列を含むべく使用され得る。一実施例において「翻訳テーブル」チャンク200は、少なくとも一個の「翻訳検索(TranslationLookup)」チャンク208を含む。各「翻訳検索」チャンク208に対しては「タイトル」チャンク202、「チャプター」チャンク206または「メディアトラック」チャンク196’が関係付けられ、かつ、その「TranslationLookup」チャンクは所定数の「翻訳(Translation)」チャンク210を含んでいる。「TranslationLookup」チャンクにおける「Translation」チャンクの各々は、「翻訳検索」チャンクに関係付けられたチャンクを、「翻訳」チャンクにより表された言語で記述するテキスト文字列を含む。
【0189】
図2.6.1.には、「DMNU」チャンク内に含まれた種々のチャンク間の関係を概念的に示す図が示される。この図は実線矢印を用いて、1つのチャンクによる別のチャンクの包含関係を示している。矢印が示す方向は、矢印が出ているチャンクにより含まれるチャンクを表している。ひとつのチャンクによる別のチャンクに対する参照は点線により表され、その場合に参照されたチャンクは点線矢印により表される。
【0190】
2.6.「junk」チャンク
「ジャンク(junk)」チャンク41は、本発明の実施例によるマルチメディア・ファイルに含まれ得る選択的チャンクである。「junk」チャンクの性質は、AVIファイル・フォーマットにおいて仕様が定められている。
【0191】
2.7.「movi」リスト・チャンク
「movi」リスト・チャンク42は、所定数の「データ(data)」チャンクを含む。「データ」チャンクが含み得る情報の例は、オーディオ、ビデオまたはサブタイトル・データである。一実施例において「movi」リスト・チャンクは、少なくとも一個のビデオ・トラック、複数のオーディオ・トラックおよび複数のサブタイトルトラックに対するデータを含む。
【0192】
図2.7.には、1つのビデオ・トラックと、3つのオーディオ・トラックと、3つのサブタイトルトラックとを含むマルチメディア・ファイルの「movi」リスト・チャンク42内における「データ」チャンクの交互配置様式が示される。便宜のために、ビデオを含む「データ」チャンクは「ビデオ」チャンクと称され、オーディオを含む「データ」チャンクは「オーディオ」チャンクと称され、かつ、サブタイトルを含む「データ」チャンクは「サブタイトル(subtitle)」チャンクと称される。図示された「movi」リスト・チャンク42において、各「ビデオ」チャンク262は、オーディオ・トラックの各々からの「オーディオ」チャンク264により、次の「ビデオ」チャンクから分離されている。幾つかの実施例において夫々の「オーディオ」チャンクは、1つの「オーディオ」チャンクに追随する「ビデオ」チャンクに含まれたビデオの一部に対応するオーディオ・トラックの一部を含む。
【0193】
隣接する「ビデオ」チャンク同士はまた、複数のサブタイトルトラックの内の1つのサブタイトルトラックからの1つ以上の「サブタイトル(subtitle)」チャンク266によっても分離され得る。一実施例において「サブタイトル」チャンク266は、サブタイトル、開始時間および停止時間を含む。幾つかの実施例において「サブタイトル」チャンクは、その「サブタイトル」チャンクに追随する「ビデオ」チャンクが、そのサブタイトルの開始時間にて行われるビデオの部分を含む如く、「movi」リスト・チャンクに交互配置される。他の実施例において、全ての「サブタイトル」および「オーディオ」チャンクの開始時間は、ビデオの同等の開始時間に先んじる。一実施例において「オーディオ」および「subtitle」チャンクは対応する「ビデオ」チャンクの5秒以内に載置され得ると共に、他の実施例において「オーディオ」および「サブタイトル」チャンクは、ファイル内のオーディオおよびビデオを表示し得るデバイスによりバッファされ得るビデオの量に関連する時間内に載置され得る。
【0194】
一実施例において「データ」チャンクは、その「データ」チャンクが属するストリームを特定する「FOURCC」コードを含む。その「FOURCC」コードは、2数字ストリーム番号と、これに続くと共にチャンクにおける情報の形式を定義する2文字コードとから成る。(Raider)代替的な「FOURCC」コードは、チャンクにおける情報の形式を定義する2文字コードと、それに続く2数字ストリーム番号とから成る。2文字コードの例は、以下の表に示される。
【0195】
【表4】
【0196】
一実施例において「ビデオ(video)」チャンク262および「オーディオ(audio)」チャンク264の構造は、AVIファイル・フォーマットに従う。他の実施例においては、メディアの性質を特定すると共に符号化メディアを含むチャンク用の他のフォーマットが使用され得る。
【0197】
幾つかの実施例において「サブタイトル(subtitle)」チャンク266に含まれるデータは、以下の如く表される。
typedef struct_subtitlechunk{
FOURCC fcc;
DWORD cb;
STR duration;
STR subtitle;
} SUBTITLECHUNK;
【0198】
値「fcc」は、サブタイトルトラックと、そのサブタイトルトラックの性質とを表すFOURCCコードである(テキストまたはビットマップ・モード)。値「cb」は、構造のサイズを指定する。値「duration」は、サブタイトルの開始および終了時点における時間を指定する。一実施例においてそれは、hh:mm:ss-hh:mm:ss.xxxの形態とされ得る。hhは時間を、mmは分を、ssは秒を、かつ、xxxはミリ秒を表す。値「subtitle」は、テキスト・モードにおけるサブタイトルのユニコード・テキスト、または、ビットマップ・モードにおけるサブタイトルのビットマップ・イメージのいずれかを含む。本発明の幾つかの実施例は、サブタイトル情報を表す圧縮ビットマップ・イメージを用いる。一実施例において「subtitle」フィールドは、サブタイトルの幅、高さおよび画面上位置に関する情報を含む。
これに加えて「subtitle」フィールドはまた、ビットマップの色情報および実際のピクセルも含み得る。幾つかの実施例においては、ビットマップを表すために必要なピクセル情報の量を減少するために、ランレングス・コーディングが用いられる。
【0199】
本発明の実施例によるマルチメディア・ファイルは、デジタル著作権管理を包含し得る。この情報は、ビデオ・オンデマンド・アプリケーションにおいて使用され得る。デジタル著作権管理により保護されたマルチメディア・ファイルは、特定の再生権利が許可されたプレーヤ上でのみ正しく再生され得る。一実施例において、トラックがデジタル著作権管理により保護されているという事実は、「hdrl」リスト・チャンクにおけるトラックに関する情報において表され得る(上記の記述を参照)。デジタル著作権管理により保護されたトラックを含む本発明の実施例によるマルチメディア・ファイルは、「movi」リスト・チャンク内にデジタル著作権管理に関する情報も含み得る。
【0200】
図2.8.には、1つのビデオ・トラックと、複数のオーディオ・トラックと、少なくとも一つのサブタイトルトラックと、デジタル著作権管理を有効化する情報とを含む本発明の実施例によるマルチメディア・ファイルの「movi」リスト・チャンクが示される。「movi」リスト・チャンク42’は図2.7.に示された「movi」リスト・チャンクと類似するが、各「ビデオ」チャンク262’に先立ち「DRM」チャンク270が付加されている。「DRM」チャンク270は、FOURCCコード「nndd」により特定され得るデジタル著作権管理情報を含む「data」チャンクである。最初の2個の文字「nn」はトラック番号を参照し、かつ、第2の2個の文字は、そのチャンクがデジタル著作権管理情報を含むことを意味する「dd」である。一実施例において「DRM」チャンク270は、その「DRM」チャンクに追随する「ビデオ」チャンク262’に対するデジタル著作権管理情報を提供する。
デジタル著作権管理により保護されたビデオ・トラックを再生しようとするデバイスは、「DRM」チャンクにおける情報を使用して、「ビデオ」チャンクにおけるビデオ情報を復号化する。典型的に、「ビデオ」チャンクの前に「DRM」チャンクが無ければ、その「ビデオ」チャンクは非保護であることが意味されると解釈される。
【0201】
本発明の実施例による暗号化システムにおいて、ビデオ・チャンクは部分的にのみ暗号化される。部分的暗号化が使用される場合、「DRM」チャンクは、「ビデオ」チャンクの暗号化された部分に対するリファレンスと、その暗号化部分を復号化するために使用され得るキーに対するリファレンスとを含む。復号化キーは、「strd」チャンク(の記述を参照)の一部である「DRM」ヘッダ内に配置され得る。復号化キーは、スクランブルが掛けられると共に、マスタ・キーにより暗号化される。「DRM」ヘッダは、マスタ・キーを特定する情報も含む。
【0202】
図2.9.には、「DRM」チャンク内の情報の概念的表現が示される。「DRM」チャンク270は、「フレーム(frame)」値280、「ステータス(status)」値282、「オフセット(offset)」値284、「数(number)」値286および「キー(key)」値288を含み得る。「フレーム(frame)」値は、ビデオの暗号化フレームを参照すべく使用され得る。「ステータス(status)」値はフレームが暗号化されているか否かを表すべく使用され得ると共に、「オフセット(offset)」値284は、フレーム内の暗号化ブロックの開始部分を指し示し、「数(number)」値286はブロックにおける暗号化バイトの個数を表す。「キー(key)」値288は、ブロックを復号化すべく使用され得る復号化キーを参照する。
【0203】
2.8.「idxl」チャンク
「idxl」チャンク44は、「movi」リスト・チャンク42内の「data」チャンクをインデックス付けすべく使用され得る選択的チャンクである。一実施例において「idxl」チャンクは、AVIフォーマットにおいて指定された如く実現され得る。他の実施例において「idxl」チャンクは、「movi」リスト・チャンク内の「data」チャンクの各々のファイル内の箇所を参照するデータ構造を用いて実現され得る。幾つかの実施例において「idxl」チャンクは、データのトラック番号とデータの形式とにより、各「data」チャンクを識別する。上記で言及されたFOURCCコードは、この目的のために使用され得る。
【0204】
3.マルチメディア・ファイルの符号化方法
本発明の実施例は、種々の様式でマルチメディア・ファイルを生成すべく使用され得る。ある場合において本発明の実施例によるシステムは、別個のビデオ・トラック、オーディオ・トラックおよびサブタイトルトラックを含むファイルからマルチメディア・ファイルを生成し得る。かかる場合、メニュー情報および「メタデータ」などの他の情報は、オーサリングされてファイル内へと挿入され得る。
【0205】
本発明の実施例による他のシステムは、デジタル・ビデオ・ディスク(“DVD”)上の種々のファイルから情報を抽出すべく、かつ、本発明の実施例による単一のマルチメディア・ファイルをオーサリングすべく使用され得る。DVDが情報の最初の供給源である場合に本発明の実施例によるシステムは、相当に圧縮すべくコーデックを使用し得ると共に、新たに生成されたマルチメディア・ファイルにおけるビデオ・チャンクに対してオーディオ・チャンクが対応する様にオーディオを再チャンキングし得る。これに加え、マルチメディア・ファイルに含まれるメニュー情報を生成すべく、DVDメニュー・システムにおけるメニュー情報が解析して使用され得る。
【0206】
他の実施例は、本発明の実施例による既存のマルチメディア・ファイルに対して付加的なコンテンツを追加することにより、新たなマルチメディア・ファイルを生成し得る。付加的コンテンツの追加の例は、注釈(たとえばディレクタのコメント、バケーション・ビデオに対して事後作成されたナレーションなど)を含むオーディオ・トラックなどの付加的なオーディオ・トラックをファイルに追加することである。マルチメディア・ファイル内へと交互配置された付加的オーディオ・トラック情報には、新たなオーディオ・トラックの再生を可能とするそのマルチメディア・ファイル内のメニュー情報の改変が付属し得る。
【0207】
3.1.記憶されたデータ・トラックを用いる生成方法
図3.0.には、マルチメディア・ファイルを生成する本発明の実施例によるシステムが示される。システム350の主要構成要素は、インタリーバ352である。そのインタリーバは、情報のチャンクを受信してそれらを交互配置することで、本発明の実施例によるマルチメディア・ファイルを上述のフォーマットで生成する。インタリーバはまた、メタデータ・マネージャ354から「メタデータ」に関する情報も受信する。インタリーバは、本発明の実施例によるマルチメディア・ファイルを記憶デバイス356に対して出力する。
【0208】
典型的に、インタリーバに対して提供されたチャンクは記憶デバイスに記憶される。幾つかの実施例においてチャンクの全ては、同一の記憶デバイスに記憶される。他の実施例においてチャンクは、種々の記憶デバイスからインタリーバに対して提供され得るか、または、リアルタイムで生成されてインタリーバに対して提供され得る。
【0209】
図3.0.に示された実施例においては、「DMNU」チャンク358および「DXDT」チャンク360がすでに生成されて記憶デバイスに記憶されている。記憶デバイスにはビデオ・ソース362が記憶され、そのビデオ・ソースはビデオ・デコーダ364を用いて復号化されてからビデオ・エンコーダ366を用いて符号化されて「ビデオ」チャンクが生成される。記憶デバイスにはオーディオ・ソース368も記憶される。オーディオ・チャンクは、オーディオ・デコーダ370を用いてオーディオ・ソースを復号化してから、復号化されたオーディオをオーディオ・エンコーダ372で符号化することにより生成される。「サブタイトル(subtitle)」チャンクは、記憶デバイスに記憶されたテキスト・サブタイトル374から生成される。サブタイトルは、所定数のサブタイトル・フォーマットの内の任意のフォーマットを生のビットマップ・フォーマットへと変換する第1トランスコーダ376に対して提供される。一実施例において、記憶されたサブタイトル・フォーマットはSRT、SUBまたはSSAなどのフォーマットである。これに加えてビットマップ・フォーマットは、色パレート(color palate)ルックアップ・テーブルを含む4ビットのビットマップである。色パレート・ルックアップ・テーブルは、16種の可能な4ビット・カラー・コードの各々に対する24ビットのカラー深度識別を含む。単一のマルチメディア・ファイルは、1つより多い色パレート・ルックアップ・テーブルを含み得る(上記の表2における「pc」パレートFOURCCコードを参照)。ゆえに4ビットのビットマップによれば各メニューは、1,600万色のパレートから取り出された16個の異なる同時的な色を有し得る。代替実施例においては、ピクセル毎に異なるビット数および異なるカラー深度が用いられる。第1トランスコーダ376の出力は、ビットマップを圧縮する第2トランスコーダ378へと提供される。一実施例においては、ビットマップを圧縮するためにランレングス・コーディングが用いられる。他の実施例においては、他の適切な圧縮フォーマットが用いられる。
【0210】
一実施例において、種々のエンコーダ、デコーダおよびトランスコーダ間のインタフェースは、Microsoft社により仕様を定められたDirectShow規格に準じる。他の実施例において、符号化、復号化およびトランスコードを実施すべく使用されるソフトウェアは、斯かる規格に従う必要はない。
【0211】
図示実施例においては、各メディア・ソースに対して別個の処理構成要素が示される。
他の実施例においては、リソースが共有され得る。たとえば単一のオーディオ・デコーダおよびオーディオ・エンコーダは、全てのソースからのオーディオ・チャンクを生成すべく使用され得る。典型的には、システム全体が、ソフトウェアを用いてコンピュータ上に実現されると共に、ハードディスク・ドライブなどの記憶デバイスに対して接続され得る。
【0212】
上述の様式でインタリーバを利用するために、本発明の実施例による「DMNU」チャンク、「DXDT」チャンク、「ビデオ(video)」チャンク、「オーディオ(audio)」チャンクおよび「サブタイトル(subtitle)」チャンクは、生成されてインタリーバに対して提供されねばならない。本発明の実施例によるマルチメディア・ファイルにおける種々のチャンクの各々を生成するプロセスは、以下においてより詳細に論じられる。
【0213】
3.2.「DXDT」チャンクの生成方法
「DXDT」チャンクは、多数の様式の内の任意の様式で生成され得る。一実施例において「メタデータ」はグラフィカル・ユーザ・インタフェースを介してデータ構造内へと入力されてから、「DXDT」チャンクへと解析される。一実施例において「メタデータ」は、一連の主部、述部、目的部および出典ステートメントとして表現される。別実施例において「メタデータ」ステートメントは、種々のフォーマットの内の任意のフォーマットで表現される。幾つかの実施例において各「メタデータ」ステートメントは、別個のチャンクへと解析される。他の実施例においては、(主部、述部、目的部および出典表現などの)第1フォーマットの幾つかの「メタデータ」ステートメントが第1チャンクへと構文解析され、かつ、他のフォーマットの他の「メタデータ」ステートメントは別個のチャンクへと構文解析される。一実施例において「メタデータ」ステートメントは、XMLコンフィグファイル(XML configuration file)に書き込まれ、そのXMLコンフィグファイルが解析されて「DXDT」チャンク内のチャンクが生成される。
【0214】
図3.1.には、XMLコンフィグファイル内に含まれた一連の「メタデータ」ステートメントから「DXDT」チャンクを生成するシステムの実施例が示される。システム380は、パーサ(parser)384に対して提供され得るXMLコンフィグファイル382を含む。XMLコンフィグファイルは、XMLとして符号化された「メタデータ」を含む。パーサはXMLを解析し、かつ、そのパーサは、「メタデータ」ステートメントを、の「メタデータ」チャンク・フォーマットの内の任意のフォーマットに従い「DXDT」チャンクに対して書き込まれるチャンクへと変換することにより、「DXDT」チャンク386を生成する。
【0215】
3.3.「DMNU」チャンクの生成方法
図3.2.には、本発明の実施例による「DMNU」チャンクを生成するために使用され得るシステムが示される。メニュー・チャンク生成システム420は、入力として、メディア・モデル422およびメディア情報を必要とする。メディア情報は、ビデオ・ソース424、オーディオ・ソース426およびオーバレイ・ソース428の形態を取り得る。
【0216】
メニュー・チャンク生成システムに対する入力を用いる「DMNU」チャンクの生成は、多数の中間ファイルの生成を伴う。メディア・モデル422はXMLコンフィグファイル430を生成するために使用され、かつ、メディア情報は所定数のAVIファイル432を生成するために使用される。XMLコンフィグファイルは、モデル・トランスコーダ434により生成される。AVIファイル432は、インタリーバ436を用いてビデオ、オーディオおよびオーバレイ情報を交互配置することで生成される。ビデオ情報は、ビデオ・デコーダ438およびビデオ・エンコーダ440を用いてビデオ・ソース424を復号化し、以下において論じられる様式でそれを再コード化することで求められる。オーディオ情報は、オーディオ・デコーダ442およびオーディオ・エンコーダ444を用いてオーディオを復号化して、以下に記述される様式でそれを符号化することで求められる。オーバレイ情報は、第1トランスコーダ446および第2トランスコーダ448を用いて生成される。第1トランスコーダ446はオーバレイを標準的ビットマップなどのグラフィック表現へと変換すると共に、第2トランスコーダは、そのグラフィック情報を受けて、それを、マルチメディア・ファイル内への包含に対して必要とされる如くフォーマットする。メニューを構築するために必要な情報を含むXMLファイルおよびAVIファイルが一旦生成されたなら、メニュージェネレータ450はその情報を使用して「DMNU」チャンク358’を生成し得る。
【0217】
3.3.1.メニュー・モデル
一実施例においてメディア・モデルは、各メニューおよびそれらの下位構成要素の全てを表すオブジェクト指向モデルである。そのメディア・モデルはメニューを、言語選択により各メニューが体系化されるのを許容する階層構造へと体系化する。図3.3.には、本発明の実施例によるメディア・モデルが示される。メディア・モデル460は、多数の「LanguageMenus(言語メニュー)」オブジェクト(object)463、「Media(メディア)」オブジェクト464および「翻訳テーブル(TranslationTable)」オブジェクト465と関係付けられた最高レベルの「メディアマネージャ(MediaManager)」オブジェクト462を含む。「メニューマネージャ(Menu Manager)」は、既定のメニュー言語も含む。一実施例において既定言語は、ISO 639の2文字言語コードにより表され得る。
【0218】
「言語メニュー(LanguageMenus)」オブジェクトは、種々のメニューに対する情報を言語選択により体系化する。所定の言語に対する「メニュー(menu)」オブジェクト466の全てには、その言語に対する「言語メニュー(LanguageMenus)」オブジェクト463が関係付けられる。各「メニュー」オブジェクトには、所定数の「ボタン(Button)」オブジェクト468が関係付けられると共に、「メニュー」オブジェクトは所定数の「メディアトラック(MediaTrack)」オブジェクト488を参照する。参照された「メディアトラック」オブジェクト488は、「メニュー」オブジェクト466に対するバックグラウンド・ビデオおよびバックグラウンド・オーディオを表している。
【0219】
各「ボタン(Button)」オブジェクト468には、「アクション(Action)」オブジェクト470および「矩形(Rectangle)」オブジェクト484が関係付けられる。「ボタン(Button)」オブジェクト468はまた、そのボタンが表示上で強調されたときに使用されるべきオーバレイを表す「メディアトラック(MediaTrack)」オブジェクト488に対するリファレンスも含む。各「アクション(Action)」オブジェクト470に対しては、「メニュー遷移(MenuTransition)」オブジェクト472、「ButtonTransition(ボタン遷移)」オブジェクト474、「ReturnToPlay(プレイに戻る)」オブジェクト476、「SubtitleSelection(サブタイトル選択)」オブジェクト478、「AudioSelection(オーディオ選択)」オブジェクト480および「プレイアクション(PlayAction)」オブジェクト482を含み得る所定数のオブジェクトが関係付けられる。これらのオブジェクトの各々は、ユーザからの種々の入力に対するメニュー・システムの応答を定義する。
「MenuTransition(メニュー遷移)」オブジェクトは、動作に応じて遷移されるべきメニューを表す「メニュー」オブジェクトに対するリファレンスを含む。「ButtonTransition(ボタン遷移)」オブジェクトは、動作に応じて強調されるべきボタンを表す。「ReturnToPlay(プレイに戻る)」によればプレーヤは番組の再生に戻り得る。「SubtitleSelection(サブタイトル選択)」および「AudioSelection(オーディオ選択)」オブジェクトは、(以下で論じられる)「タイトル(Title)」オブジェクト487に対するリファレンスを含む。「プレイアクション」オブジェクトは、(以下で論じられる)「チャプター(Chapter)」オブジェクト492に対するリファレンスを含む。「矩形(Rectangle)」オブジェクト484は、ボタンにより占有された画面の部分を表す。
【0220】
「メディア(Media)」オブジェクト464は、メニュー・システムにおいて参照されたメディア情報を表す。「メディア(Media)」オブジェクトは、「メニュートラック(MenuTracks)」オブジェクト486と、それに関係付けられた所定数の「タイトル(Title)」オブジェクト487とを有する。「メニュートラック(MenuTracks)」オブジェクト486は、メニューを構築すべく使用されるメディア(すなわちバックグラウンド・オーディオ、バックグラウンド・ビデオおよびオーバレイ)を表す「メディアトラック(MediaTrack)」オブジェクト488を参照する。
【0221】
「タイトル」オブジェクト487は、マルチメディア・プレゼンテーションを表すと共に、所定数の「チャプター」オブジェクト492と、それらに関係付けられた「メディアソース(MediaSource)」オブジェクト490とを有する。「タイトル」オブジェクトは、「翻訳検索(TranslationLookup)」オブジェクト494に対するリファレンスも含む。「チャプター」オブジェクトはマルチメディア・プレゼンテーションにおける一定箇所を表すと共に、それに関係付けられた所定数の「メディアトラック(MediaTrack)」オブジェクト488を有する。「チャプター」オブジェクトは、「TranslationLookup(翻訳検索)」オブジェクト494に対するリファレンスも含む。「チャプター」オブジェクトが関係付けられた各「メディアトラック」オブジェクトは、マルチメディア・プレゼンテーションのオーディオ、ビデオまたはサブタイトルトラックのいずれかにおける箇所を表すと共に、(以下で論じられる)「メディアソース(MediaSource)」オブジェクト490および「翻訳検索(TranslationLookup)」オブジェクト494を参照する。
【0222】
「翻訳テーブル(TranslationTable)」オブジェクト465は、「タイトル(Title)」オブジェクト、「チャプター」オブジェクトおよび「メディアトラック(MediaTrack)」オブジェクトにより表されるマルチメディア・プレゼンテーションの種々の部分を記述する所定数のテキスト文字列をグループ化する。「翻訳テーブル(TranslationTable)」オブジェクト465は、それに対して関係付けられた所定数の「翻訳検索(TranslationLookup)」オブジェクト494を有する。各「翻訳検索」オブジェクトは、特定オブジェクトを表すと共に、それに関係付けられた所定数の「翻訳(Translation)」オブジェクト496を有する。その「翻訳オブジェクトは各々、「翻訳検索(TranslationLookup)」オブジェクトにより表されたオブジェクトを特定言語で記述するテキスト文字列を表す。
【0223】
上述の種々のオブジェクトを生成すべく構成されたソフトウェアであってオブジェクト間の必要な関係付けおよび参照を確立するソフトウェアを用いて、メディア・オブジェクト・モデルが構築され得る。
【0224】
3.3.2XMLファイルの生成方法
XMLコンフィグファイルは、各メニューおよびそれらの下位構成要素の全てを表すメニュー・モデルから生成される。XMLコンフィグファイルはまた、各メニューにより使用されるメディア・ファイルの全ても特定する。XMLは、オブジェクト・モデルをXMLコードへと解析する適切なパーサ・アプリケーションを実現することで生成され得る。
【0225】
他の実施例においてはビデオ編集アプリケーションがユーザに対してインタフェースを提供することで、メニュー・モデルを生成せずにXMLコンフィグファイルの直接的生成が可能とされ得る。
【0226】
DVDメニューなどの別のメニュー・システムがメニュー・モデルの基礎であるという実施例において、メニューはユーザにより切り詰められ、本発明の実施方法に従い生成されるマルチメディア・ファイルに含まれない内容に関するメニュー・オプションが排除され得る。一実施例においてこれは、メニュー・モデルからのオブジェクトの排除を可能とするグラフィカル・ユーザ・インタフェースを配備することで行われ得る。別実施例においてメニューの切り詰めは、XMLコンフィグファイルを編集し得るグラフィカル・ユーザ・インタフェースまたはテキスト・インタフェースを配備することにより達成され得る。
【0227】
3.3.3.メディア情報
「DMNU」チャンクが生成されるとき、メニュージェネレータ450に対して提供されるメディア情報は、メニュー・モデル(上記の記述を参照)において特定されたボタンに対するバックグラウンド・ビデオ、バックグラウンド・オーディオおよびフォアグラウンド・オーバレイを提供するために必要なデータを含む。一実施例においては、カリフォルニア州、サンタクララのロキシオ社(Roxio, Inc.)により配給されるVideoWaveなどのビデオ編集アプリケーションが使用されることで、個別メニューの各々に対するビデオ、オーディオおよびボタン選択オーバレイを表すソース・メディア・トラックが提供される。
【0228】
3.3.4.中間AVIファイルの生成方法
上記の如く、バックグラウンド・ビデオ、バックグラウンド・オーディオおよびフォアグラウンド・ボタン・オーバレイとして使用されるメディア・トラックは、1つ以上のメニューに対して単一のAVIファイル内に記憶される。メニューAVIファイル内にメディア・トラックを含むチャンクは、ビデオ、オーディオおよびボタン・オーバレイトラックを交互配置すべく設計されたソフトウェアを用いて生成され得る。「オーディオ」、「ビデオ」および「オーバーレイ」チャンク(すなわちオーバレイ情報を含む「サブタイトルチャンク)は、インタリーバを用いてAVIフォーマット準拠ファイルへと交互配置される。
【0229】
上述された如く、各メニューに対しては別個のAVIファイルが生成され得る。他の実施例においては、バックグラウンド・オーディオ、バックグラウンド・ビデオおよびフォアグラウンド・オーバレイ情報を提供すべく使用されたメディア情報を含む他のファイル・フォーマットまたは単一ファイルが使用され得る。
【0230】
3.3.5.XMLコンフィグファイルおよびAVIファイルを結合する方法
一実施例においてコンピュータは、XMLコンフィグファイルからの情報を解析して(上述の)「WowMenu」チャンクを生成すべく構成される。これに加えてそのコンピュータは、各メニューに対するメディアを含むAVIファイルを用いて(上述の)「MRIF」チャンクを生成し得る。コンピュータは次に、「WowMenu」チャンクと「MRIF」チャンクにおけるメディア・チャンクとの間に必要なリファレンスを生成することにより「DMNU」チャンクの生成を完了し得る。幾つかの実施例において、メニュー情報は暗号化され得る。暗号化は、「MRIF」チャンクに含まれたメディア情報を、「ビデオ(video)」チャンクに関して以下に記述されるのと同様の様式で暗号化することで達成され得る。他の実施例においては、種々の代替的な暗号化技術が使用される。
【0231】
3.3.6.オブジェクト・モデルからのメニューの自動生成
図3.3.に戻ると、フルメニューよりも少ない内容を含むメニューは、「メディア」オブジェクト464に関係付けられた「タイトル」オブジェクト487を単に検証することにより、メニュー・モデルから自動的に生成され得る。図3.3.1.には、本発明の実施例によるメニューを自動的に生成すべく使用されるオブジェクトが示される。単に、マルチメディア・プレゼンテーションの特定セクションの選択と、使用されるオーディオおよびサブタイトルトラックの選択とを可能とする単純なメニューに対するXMLコンフィグファイルは、ソフトウェアにより生成され得る。
【0232】
3.3.7.単一の設定ファイルを用いて「DXDT」および「DMNU」チャンクを生成する方法
本発明の幾つかの実施例によるシステムは、「メタデータ」およびメニュー情報の両方を含む単一のXMLコンフィグファイルを生成し、かつ、そのXMLファイルを用いて「DXDT」および「DMNU」チャンクを生成し得る。これらのシステムは、「メタデータ」情報およびメニュー・オブジェクト・モデルを用いてXMLコンフィグファイルを導出する。
他の実施例において設定ファイルは、XMLである必要はない。
【0233】
3.4.「オーディオ」チャンクの生成方法
本発明の実施例によるマルチメディア・ファイルの「movi」リスト・チャンクにおける「オーディオ」チャンクは、本発明の実施方法に従い、オーディオ・ソースを復号化してから、そのソースを「オーディオ」チャンクへ符号化することにより生成され得る。一実施例において「オーディオ」チャンクは、MP3コーデックを用いて符号化され得る。
【0234】
3.4.1.オーディオを再チャンキングする方法
オーディオ・ソースが、対応「ビデオ」チャンクのコンテンツに対応するオーディオ情報を含まないチャンクで提供されたとき、本発明の実施例はそのオーディオを再チャンクし得る。図3.4.には、オーディオを再チャンクするために使用され得る処理が示される。処理480は、「ビデオ」チャンクを識別するステップ(482)と、その「ビデオ」チャンクに付随するオーディオ情報を識別するステップ(484)と、既存のオーディオ・チャンクからオーディオ情報を抽出(486)して新たな「オーディオ」チャンクを生成(488)するステップとを含む。処理は、オーディオ・ソース全体が再チャンクされたとの判断(490)が為されるまで反復される。その時点において、オーディオの再チャンクは完了(492)する。
【0235】
3.5.「ビデオ」チャンクの生成方法
上述された如く、ビデオ・チャンクを生成するプロセスはビデオ・ソースを復号化するステップと、復号化されたビデオを「ビデオ」チャンクへと符号化するステップとを包む。一実施例において各「ビデオ」チャンクは、ビデオの単一フレームに対する情報を含む。復号化プロセスは単に、特定フォーマットのビデオを取り込むステップと、そのビデオをそのフォーマットから、非圧縮ともされ得る標準的なビデオ・フォーマットへと復号化するステップとを包含する。符号化プロセスは、標準的なビデオを取り込むステップと、そのビデオを符号化するステップと、符号化されたビデオを用いて「ビデオ」チャンクを生成するステップとを含む。
【0236】
図3.5.には、本発明の実施例によるビデオ・エンコーダが概念的に示される。ビデオ・エンコーダ500は、標準的ビデオ情報504を前処理502する。次に、前処理済みビデオに対して動作評価506が実施されることで、前処理済みビデオに対する動作補償508が提供される。動作補償されたビデオに対しては、離散余弦変換(DCT変換)510が実施される。そのDCT変換に続き、ビデオは量子化512されると共に、予測514が実施される。次に、ビデオのテクスチャ・コード化518バージョンを、動作評価の結果を用いて生成された動作コーディング520と組み合わせることにより、圧縮ビットストリーム516が生成される。圧縮ビットストリームは次に、「ビデオ」チャンクを生成すべく用いられる。
【0237】
動作評価506を実施するために、(例えば、圧縮されたビデオがプレーヤによる視認のために解凍されたときに)システムは、ビデオの先行処理フレームが復号化デバイスにより如何にして復号化されたかに関する知見を有さねばならない。この情報は、量子化器512の出力を逆量子化522することにより求められ得る。次に、逆量子化器の出力に関して逆DCT524が実施され得ると共に、その結果は動作評価プロセスの間におけるアクセスのためにフレーム記憶器526に載置される。
【0238】
本発明の実施例によるマルチメディア・ファイルはまた、所定数の心理視覚的強化(psychovisual enhancement)528も含み得る。その心理視覚的強化は、人間の視覚の認識に基づきビデオを圧縮する方法とされ得る。これらの技術は、以下において更に論じられると共に、概略的には、量子化器により使用される所定数のビットを改変してビデオの種々の側面を表す段階を包含する。符号化プロセスの他の側面もまた、心理視覚的強化を含み得る。
【0239】
一実施例において符号化システム500は、上述の種々の機能を実施すべく構成されたコンピュータを用いて実現され得る。これらの機能の詳細な実施方式の例は以下に提供される。
【0240】
3.5.1.前処理方法
本発明の実施例によるエンコーダ500により選択的に実施される前処理操作502は、符号化されたビデオの品質を改善する多数の信号処理技術を使用し得る。一実施例において前処理502は、インターレース解除、時間的/空間的ノイズ減少およびサイズ再設定のひとつもしくは全てを包含し得る。これらの前処理技術の3つ全てが使用される実施例において、典型的には最初に交互配置解除が行われ、時間的/空間的ノイズ減少およびサイズ再設定が追随する。
【0241】
3.5.2.動作評価および補償
本発明の実施例によるビデオ・エンコーダは、複数のフレームにおいて反復されるピクセルを検索することにより、ビデオ・トラックを表すために必要なピクセルの個数を減少し得る。本質的に、ビデオにおける各フレームは典型的に、ひとつ前のフレームと同一のピクセルの多くを含んでいる。エンコーダは、(マクロブロック、ピクセル、ハーフ・ピクセルおよびクォータ・ピクセルとして)各フレーム間におけるピクセルの整合に対して幾つかの形式の検索を行い得ると共に、可能な場合は常に、イメージ品質を低下させずにこれらの冗長性を排除する。動作評価を用いることでエンコーダは、全てのフレームに対してピクチャ全体を記憶する代わりに、最後のフレームから生じた変化を記録するだけでピクチャの殆どを表し得る。動作評価の間にエンコーダは、自身が分析しつつあるフレームを、多くの場合に「macroblock(マクロブロック)」と称される均一な格子のブロックへと分割する。フレームにおける各「macroblock」に対し、エンコーダは先行フレームにおける整合ブロックを見出そうと試行し得る。整合ブロックを見出そうと試行するプロセスは、「モーション・サーチ」と称される。「macroblock」の動作は、2次元ベクトルすなわち(x,y)表現として表される。動作検索アルゴリズムは、種々の度合いの精度を以て実施され得る。ホール・ペル(whole pel)検索は、いずれかの次元において一度に1個のピクセルで基準フレームを全体に亙り踏破することで整合ブロックの位置決定をエンコーダが試行するという検索である。ハーフ・ピクセル検索においてエンコーダは、いずれかの次元において一度に半分のピクセルで基準フレームを全体に亙り踏破することで整合ブロックを検索する。エンコーダは、クォータ・ピクセル、他のピクセル割合、または、1個のピクセルより大きな粒度を包含する検索を使用し得る。
【0242】
図3.5.に示されたエンコーダ実施例は、本発明の実施例による動作評価を実施する。動作評価の間においてエンコーダは、前処理済みビデオ502と、フレーム記憶器526に記憶された先行フレームとに対してアクセスする。先行フレームは、量子化器の出力を取り込むと共に、逆量子化522および逆DCT変換524を実施することで生成される。上記の各逆関数を実施する理由は、本発明の実施例によるプレーヤにより復号化されたときに、フレーム記憶器におけるフレームがそのまま現れる様にするためである。
【0243】
動作補償は、動作評価の結果として生成されたブロックおよびベクトルを取り込むことにより実施される。結果は、付加的なテクスチャ情報を提供することにより実際のイメージに整合され得る符号化イメージの近似である。
【0244】
3.5.3.離散余弦変換
図3.5.に示されたエンコーダにより実施されるDCTおよび逆DCTは、ISO/IEC 14496-2:2001(E)、付属文書A.1(コーディング変換)において仕様を定められた規格に従う。
【0245】
3.5.3.1.変換の説明
DCTは、一群の空間領域データ点を周波数領域表現へと変換する方法である。ビデオ圧縮の場合には2次元DCTが、イメージ・ブロックを、冗長性が更に容易に利用され得る形態へと変換する。周波数領域ブロックは、エントロピ・コーディングにより容易に圧縮される疎(まば)らな行列であり得る。
【0246】
3.5.3.2.変換に対する心理視覚的強化
DCT係数は、人的視認者に対して容易に明らかである領域における量子化ノイズを減少することにより量子化イメージの品質を改善すべく改変され得る。これに加え、人的視認者により容易には認識され得ないイメージの部分における量子化ノイズは増加することにより、ファイル・サイズは減少され得る。
【0247】
本発明の実施例によるエンコーダは、「低速」心理視覚的強化と称されるものを実施し得る。「低速」心理視覚的強化は、ビデオ・イメージの各ブロックを分析し、かつ、そこにおける一定のノイズを許容するとビデオの外観を劣化させずに一定のビットを節約し得るか否かを判断するものである。その処理は、ブロック毎に1つの測定値を使用する。その処理は「低速」処理と称される、と言うのも、それは相当量の演算を実施してブロッキング(blocking)またはリンギング(ringing)アーチファクトを回避するからである。
【0248】
本発明の実施例によるエンコーダの他の実施例は、「高速」心理視覚的強化を実施する。その「高速」心理視覚的強化は、ブロック内でノイズが出現して量子化ノイズを形状化し得る箇所を制御し得る。
【0249】
「低速」および「高速」心理視覚的強化の両方が、以下においてより詳細に論じられる。本発明の実施例に依れば、イメージエッジ部におけるノイズを制御する処理であって人間の視覚に対して容易に明らかではないイメージの領域において更に高レベルの量子化ノイズを集中しようとする処理などの心理視覚的強化が実施され得る。
【0250】
3.5.3.3.「低速」心理視覚的強化
「低速」心理視覚的強化は、ビデオ・イメージの各ブロックを分析し、一定のノイズを許容するとビデオの外観を劣化させずにビットが節約され得るか否かを決定する。一実施例においてアルゴリズムは、2つの段階を含む。第1段階は、入力された輝度ピクセルに対する差分イメージ(differentiated image)の生成を含む。差分イメージは、以下に記述される様式で生成される。第2段階は、量子化に先立ちDCT係数を改変する段階を含む。
【0251】
3.5.3.3.1.差分イメージの生成
差分イメージの各ピクセルp’xyは、非圧縮のソース・ピクセルpxyから、以下に従い算出される。
【0252】
【数1】
【0253】
式中、p’xyは(8ビットのビデオを仮定すると)0〜255の範囲である。
【0254】
3.5.3.3.2.DCT係数の改変
DCT係数の改変は、ブロック・リンギング係数の算出、ブロック・エネルギの算出、および、係数値の実際の改変を包含し得る。
【0255】
3.5.3.3.3.ブロック・リンギング係数の算出
イメージの各ブロックに対し、「リンギング係数(ringing factor)」は差分イメージのローカル領域に基いて算出される。ブロックが8×8ブロックとして定義される実施例において、リンギング係数は以下の方法を用いて決定され得る。
【0256】
最初に、8×8ブロック内における最大および最小の輝度ピクセル値に基づき、閾値が決定される。
thresholdblock=floor((maxblock−minblock)/8)+2
【0257】
差分イメージおよび閾値は、ブロックの近傍における「フラット(flat)」ピクセルのマップを生成すべく用いられる。各ブロックが異なる閾値を有する可能性は、フレーム全体に対するフラット・ピクセルのマップの生成を阻害する。マップは以下の如く生成される。
flatxy=1 p’xy<thresholdblockのとき
flatxy=0 それ以外
【0258】
フラット・ピクセルのマップは、単純な論理演算に従いフィルタリングされる。
flat’xy=1 flatxy=1 flatx-1y=1 flatxy-1=1 flatx-1y-1=1
flat’xy それ以外
【0259】
フィルタリングされたマップにおけるフラット・ピクセルは次に、その8×8ブロックをカバーする9×9領域の全体に亙りカウントされる。
【0260】
0=x=8および0=y=8に対し、
【0261】
【数2】
【0262】
視認可能なリンギング・アーチファクトのリスクは、以下の式を用いて評価され得る。
ringingbriskblock=((flatcountblock−10)x256+20)/40
【0263】
次に、以下の式を用いて8×8ブロックのリンギング係数が導出され得る。
Ringingfactor=0 ringingrisk>255のとき
=255 ringingrisk<0のとき
=255−ringingrisk その他の場合
【0264】
3.5.3.3.4.ブロック・エネルギの算出
イメージのブロックに対するエネルギは、以下の手順を用いて計算され得る。
【0265】
ソース・イメージに対して順方向DCTが実施される。
T=fDCT(S)
式中、Sは問題となる8×8ブロックの64個のソース・イメージ輝度値であり、かつ、Tはソース・イメージの同一部分の変換バージョンである。
【0266】
特定の係数位置におけるエネルギは、その係数の値の二乗として定義される。
0=k=63に対し、ek=tk2
【0267】
式中、tkは変換されたブロックTの第k番目の係数である。
【0268】
3.5.3.3.5.係数の改変
DCT係数の改変は、以下の処理に従い実施され得る。幾つかの実施例においてその処理は、量子化の前に、全ての非ゼロのAC DCT係数に対して実施される。各係数の大きさは、心理視覚的技術に従い決定された小さなデルタだけ変化せしめられる。
【0269】
非ゼロAC係数ckの各々のDCT係数改変は、以下の式を用いてローカルおよびブロック・エネルギに基づくエネルギを計算することで実施される。
【0270】
energyk=max(ak × ek,0.12 × totalenergy)
【0271】
式中、akは、以下の表に記述された係数位置に値が依存する定数である。
【0272】
【表5】
【0273】
エネルギは、以下の関係を用いてブロックのリンギング係数に従い改変され得る。
energy’k=ringingfactor × energyk
【0274】
結果的な値は、ルックアップ・テーブル(LUT)に対する入力として使用される前にシフトかつクリップされる。
ek=min(1023,4×energy’k)
dk=LUTi そこで i=ek
【0275】
ルックアップ・テーブルは、以下の如く算出される。
【0276】
【数3】
【0277】
また以下の表に記述された様に値「オフセット(offset)」は、量子化数Qpに依存する。
【0278】
【表6】
【0279】
変数ktextureおよびkflatは夫々、フラットな領域およびテクスチャ化された領域における心理視覚的効果の強さを制御する。一実施例においてそれらは0〜1の範囲の値を取り、0は効果なしを意味しかつ1は完全効果を意味する。一実施例においてktextureおよびkflatに対する値は以下の如く確立される。
【0280】
輝度: ktexture=1.0
: kflat=1.0
色度: kflat=1.0
: kflat=0.0
【0281】
検索テーブル(lookup table)からの出力(dk)は、以下の付加的プロセスによりDCT係数の大きさを改変すべく用いられる。
【0282】
c’k=ck−min(dk,|ck|) x sgn(ck)
最後に、DCT係数ckは、改変された係数c’kにより置換され、量子化のために前送りされる。
【0283】
3.5.3.4.「高速」心理視覚的強化
「高速」心理視覚的強化は、入力輝度ピクセルに対する「重要性」マップを算出してからDCT係数を改変することにより、DCT係数に関して実施され得る。
【0284】
3.5.3.4.1.「重要性」マップの算出方法
「重要性」マップは、入力ビデオ・フレームの輝度箇所における各ピクセルに対して「重要性」値を計算することにより生成され得る。幾つかの実施例において「重要性」値は、その特定のピクセルに配置された一切の歪曲に対する人間の目の感度を近似する。「重要性」マップは、ピクセルの「重要性」値の配列である。
【0285】
ピクセルの「重要性」は、ピクセル(dxy)の周りのピクセルのブロックのダイナミック・レンジを先ず計算することにより決定され得る。幾つかの実施例において、ピクセル箇所(x,y)に中心合わせされた3×3ブロックのダイナミック・レンジは、その領域において最も暗いピクセルの値を、その領域において最も明るいピクセルの値から減算することで算出される。
【0286】
ピクセル(mxy)の「重要性」は、以下の如く、そのピクセルのダイナミック・レンジから導出され得る。
mxy=0.08/max(dxy,3)+0.001
【0287】
3.5.3.4.2.DCT係数の改変方法
一実施例においてDCT係数の改変は、基底関数のエネルギ行列およびデルタ・ルックアップ・テーブルの生成を含む。
【0288】
3.5.3.4.3.基底関数のエネルギ行列の生成
DCT係数を改変する際には、一群の基底関数エネルギ行列が使用され得る。これらの行列は、符号化に先立ち算出され得る定数値を含む。64個のDCT基底関数の各々に対しては、8×8行列が用いられる。各行列は、8×8ブロックにおける全てのピクセルがその対応係数の改変により如何に影響されるかを記述する。第k番目の基底関数エネルギ行列は、100に設定された対応係数と0に設定された他の係数とを有する8×8行列Akを採用することにより導出される。
【0289】
akn=100 n=kの場合
=0 それ以外
式中、nは8×8行列内における係数の位置を表す。0=n=63
逆DCTは行列に関して実施され、更なる8×8行列A’kが生成される。行列の要素(a’kn)は、第k番目のDCT基底関数を表す。
【0290】
A’k=iDCT(Ak)
変換された行列における各値は次に二乗される。
0=n=63に対して、bkn=a’kn2
【0291】
処理は64回実施され、各々が64個の自然数を備える、0=k=63である基底関数エネルギ行列Bkが生成される。各行列値は、8×8ブロックにおける第n番目の位置におけるピクセルが係数kの任意のエラーまたは改変により如何に影響されるかの尺度である。
【0292】
3.5.3.4.4デルタ・ルックアップ・テーブルの生成
係数改変デルタの算出を促進すべく、ルックアップ・テーブル(LUT)が使用され得る。そのテーブルの内容は、「高速」心理視覚的強化の所望の強度と量子化数・パラメータ(Qp)とに依存する様式で生成され得る。
【0293】
ルックアップ・テーブルの値は、次の関係に従い生成され得る。
【0294】
【数4】
【0295】
式中、iはテーブルにおける位置であり、0=i=1023である。
【0296】
以下のテーブルに記述された如く、strength、およびoffsetは、量子化数(Quantizer)Qpに依存する。
【0297】
【表7】
【0298】
変数ktextureおよびkflatは夫々、フラットな領域およびテクスチャ化された領域における心理視覚的効果の強さを制御する。一実施例においてそれらは0〜1の範囲の値を取り、0は効果なしを意味しかつ1は完全効果を意味する。一実施例においてktextureおよびkflatに対する値は以下の如く確立される。
【0299】
輝度: ktexture=1.0
: kflat=1.0
色度: kflat=1.0
: kflat=0.0
【0300】
3.5.3.4.5.DCT係数の改変
DCT係数は、で計算された値を用いて改変され得る。一実施例において各非ゼロAC DCT係数は、量子化に先立ち以下の手順に従い改変される。
【0301】
最初に「エネルギ」値(ek)は、対応する基底関数エネルギ行列と、重要性マップからの適切な8×8ブロックとの内積を取ることにより算出される。この「エネルギ」は、特定係数における量子化エラーが人的視認者により如何に認識されるかの尺度である。それは、ピクセル重要性とピクセル基底関数エネルギとの積の合計である。
【0302】
ek=M・Bk
式中、
Mは8×8ブロックの重要性マップ値であり、かつ、
Bkは第k番目の基底関数エネルギ行列である。
【0303】
結果的な「エネルギ」値は、デルタ・ルックアップ・テーブルへのインデックス(dk)として使用される前に、シフトかつクリップされる。
【0304】
ek=min[1023, floor(ek/32768)]
dk=LUTi
そこで、i=e’k
【0305】
デルタ・ルックアップ・テーブルの出力は、付加的プロセスによりDCT係数の大きさを改変すべく用いられる。
【0306】
c’k=ck−min(dk,|ck|)×sign(ck)
【0307】
DCT係数ckは、改変されたc’kにより置換されて、量子化のために前送りされる。
【0308】
3.5.4.量子化
本発明の実施例によるエンコーダは、1996年のITU−T勧告H.263、低ビットレート通信に対するビデオ・コーディングとして国際電気通信連合により策定された量子化器などの標準的な量子化器を使用し得る。
【0309】
3.5.4.1.量子化に対する心理視覚的強化
本発明の実施例による幾つかのエンコーダは、人間の視覚の心理的効果を利用して更に効率的な圧縮を達成する心理視覚的強化を使用する。心理視覚的効果は、フレーム・レベルおよびマクロブロック・レベルで適用され得る。
【0310】
3.5.4.2.フレーム・レベルの心理視覚的強化
フレーム・レベルにて適用されたとき、その強化は速度制御アルゴリズムの一部であり、その目標は、人間の目により認識される最高の視覚的品質を確実にすべく所定量のビットレートが最適に使用される様に符号化方法を調節することである。フレーム速度の心理視覚的強化は、動作が早いときに人間の視覚は詳細を無視する傾向がありかつ人間の視覚はイメージが静止的であるときに詳細に注目する傾向があるという理論により動機付けられる。一実施例において動作の量は、フレームに対する絶対的差の合計(SAD)を調べることで決定される。一実施例においてSAD値は、2つのブロックの共配置された輝度ピクセルの絶対的差を合計することにより決定される。幾つかの実施例においては、16×16ピクセル・ブロックの絶対的差が用いられる。部分的ピクセル・オフセットを取り扱う実施例においては、絶対的差の合計が計算される前に、MPEG-4規格(ISO/IECの動画専門委員会により開発されたISO/IEC規格)において仕様を定められた様に、内挿が実施される。
【0311】
フレーム・レベルの心理視覚的強化はビデオ・トラックのPフレームに対してのみその当し、そのフレームのSAD値に基づく。符号化の間に心理視覚的モジュールは、ビデオ・トラックのPフレームの全ての平均SAD(すなわち^SAD)と、各フレームの全体的SADからの各フレームのSADの平均距離(すなわち^DSAD)との記録を維持する。平均化は、指数移動平均アルゴリズムを用いて行われ得る。一実施例においては、上述のワンパス速度制御アルゴリズムが此処での平均化期間(averaging period)として使用され得る。
【0312】
符号化されたビデオ・トラックの各Pフレームに対し、(速度制御モジュールから獲得された)フレーム・量子化数Qは、それに適用される心理視覚的補正値を有する。一実施例においてプロセスは、以下の式を用いて比率Rを計算する段階を包含する。
【0313】
【数5】
【0314】
式中、Iは定数でありかつ現在は0.5に設定される。Rは[−1, 1]の境界内に短縮される。
【0315】
量子化数は次に、比率Rに従い、以下に示される計算を介して調節される。
【0316】
【数6】
【0317】
式中、Sframeはフレーム・レベル心理視覚的強化に対する強度定数である。
【0318】
Sframe定数は、フレーム・レベル心理視覚に対して調節が如何に強力であり得るかを決定する。コーデックの一実施例においては、Sframeを0.2、0.3または0.4に設定するオプションが利用可能である。
【0319】
3.5.4.3.マクロブロック・レベルの心理視覚的強化
マクロブロック・レベルで心理視覚的強化を利用する本発明の実施例によるエンコーダは、人的視認者に対するビデオの視覚的品質に対して目立つマクロブロックを識別することを試行すると共に、これらのマクロブロックを更に高品質でコード化することを試行する。マクロブロック・レベルの心理視覚的強化の効果は、フレームに対して重要さが少ない部分からビットを取り去り、それらを、フレームの更に重要な部分に適用することである。幾つかの実施例においては、円滑度、明るさ、および、マクロブロックSADに基づく3つの技術を用いて達成される。他の実施例においては、技術の内の任意のひとつの技術がそれのみで、もしくは、技術の別のものと組み合わされて、または、完全に別の技術が使用され得る。
【0320】
一実施例においては、上述の3通りのマクロブロック・レベルの心理視覚的強化の全てが、マクロブロック・レベルの心理視覚的強化の強度を制御する共通パラメータSMBを共有する。次に、各マクロブロックに対する最大および最小の量子化数が、以下に示される計算を介して強度パラメータおよびフレーム・量子化数Qframeから導出される。
【0321】
【数7】
【0322】
値QMBMaxは、最大量子化数であり、値QMBMaxは、最小量子化数である。
値QMBMaxおよびQMBMaxは、フレーム全体に対するマクロブロック・量子化数に対する上下の境界を定義する。一実施例においては、値SMBを値0.2、0.3および0.4の内の任意の値に設定するオプションが提供される。他の実施例においては、SMBに対する他の値が利用され得る。
【0323】
3.5.4.3.1.明るさ強化
心理視覚的強化がマクロブロックの明るさに基づいて実施される実施例において、エンコーダは更に明るいマクロブロックを更なる高品質で符号化することを試行する。この強化の理論的根拠は、フレームの比較的に暗い部分は人的視認者により概略的に無視されるということである。このマクロブロックの心理視覚的強化は、ビデオ・トラックのIフレームおよびPフレームに対して適用される。各フレームに対してエンコーダは、最初にフレーム全体を一覧する。平均明るさ(^BR)が計算され、かつ、平均からの明るさの平均差(^DBR)も計算される。これらの値は次に、心理視覚的強化が適用されるべきか否かに対するインディケータとして使用され得る2つの閾値(TBRLower,TBRUpper)を作成すべく用いられる。
【0324】
【数8】
【0325】
明るさ強化は次に、以下に述べられる条件を用いて2つの閾値に基づいて適用され、マクロブロックに対して意図された量子化数(QMB)が生成される。
QMB=QMBMin BR>TBRUpperのとき、
QMB=Qframe TBRLower≦BR≦TBRUpperのとき、および、
QMB=QMBMax BR<TBRLowerのとき;
式中、BRはその特定のマクロブロックに対する明るさ値である。式中、BRはその特定のマクロブロックに対する明るさ値である。
【0326】
エンコーダがMPEG−4規格に準拠するという実施例において、マクロブロック・レベルの心理視覚的明るさ強化技術は、ひとつのマクロブロックから次のマクロブロックにかけて±2より多く量子化数を変更し得ない。故に計算されたQMBは、先行するマクロブロックにおいて使用された量子化数に基づく改変を必要とし得る。
【0327】
3.5.4.3.2.円滑度強化
円滑度の心理視覚的強化を含む本発明の実施例によるエンコーダは、符号化されつつあるイメージの空間的変動に基づき量子化数を改変する。円滑度の心理視覚的強化の使用は、人間の視覚はイメージの円滑部分における量子化アーチファクトに対して大きな感度を有するという理論により動機付けられ得る。故に円滑度の心理視覚的強化は、イメージの更に円滑な部分を表すビットの個数を増大すると共にイメージの空間的変動の度合いが高い箇所ではビットの個数を減少するというステップを含む。
【0328】
一実施例においてイメージの一部分の円滑度は、マクロブロックの明るさ(brightness)に対するそのマクロブロックのピクセルの輝度(luminance)における平均差(^DR)として測定される。図3.6.には、本発明の実施例に従いIフレームに対して円滑度の心理視覚的強化を実施する方法が示される。プロセス540は、フレーム全体を検証して^DRを計算(542)するステップを含む。次に、円滑度強化TDRを適用する閾値は、以下の計算を用いて導出(544)され得る。
【0329】
【数9】
【0330】
以下の円滑度強化は、閾値に基づいて実施(546)される。
QMB=Qframe DR≧TDRのとき、および、
QMB=QMBMin DR<TDRのとき。
式中、
QMBは、マクロブロックに対して意図された量子化数であり、
DRは、マクロブロックに対する偏差値(すなわち、平均輝度−平均明るさ)である。
MPEG−4規格に従いファイルを符号化する実施例は、上述された如く、マクロブロック・レベルの量子化数変化はひとつのマクロブロックから次のマクロブロックへと多くとも±2とされ得るという点において制限される。
【0331】
3.5.4.3.3.マクロブロックSAD強化
本発明の実施例によるエンコーダは、マクロブロックSAD心理視覚的強化を利用し得る。マクロブロックSAD心理視覚的強化は、静止的マクロブロックに対する詳細を高めると共に、速い動作のシーンで使用されるフレームの部分における詳細は低減させ得るべく使用され得る。図3.7.には、本発明の実施例に従いマクロブロックSAD心理視覚的強化を実施するプロセスが示される。プロセス570は、Iフレーム全体を検査(572)し、フレーム全体における全てのマクロブロックに対する平均SAD(すなわち^MBSAD)を決定する段階を含み、かつ、平均からのマクロブロックのSADの平均差(すなわち^DMBSAD)も求められる。一実施例においてはこれらのマクロブロックの両方が、フレーム間コード化されたマクロブロック(すなわち、動作補償、または、先行する符号化ビデオ・フレームに対する他の依存性を用いて符号化されたマクロブロック)の全体に亙り平均化される。次にこれらの平均から、以下の式を用いてマクロブロックSAD強化を適用する2つの閾値が導出(574)される。
【0332】
【数10】
【0333】
そこで、
TMBSADLowerは下側閾値であり、
TMBSADUpperは上側閾値であり、必要であればこれらは1024だけ境界付けられ得る。
【0334】
次にマクロブロックSAD強化はこれらの2つの閾値に基づき以下の条件に従い適用(576)される。
QMB=QMBMax MBSAD>TMBSADUpperのとき、
QMB=Qframe TMBSADLower≦MBSAD≦TMBSADUpperのとき、
QMB=QMBMin MBSAD<TMBSADLowerのとき。
そこで、
QMBはマクロブロックに対して意図された量子化数であり、
MBSADはその特定のマクロブロックに対するSAD値である。
【0335】
MPEG−4仕様に従いファイルを符号化する実施例は、上述された如く、マクロブロック・レベルの量子化数変化はひとつのマクロブロックから次のマクロブロックへと多くとも±2とされ得るという点において制限される。
【0336】
3.5.5.速度制御
本発明の実施例によるエンコーダにより使用される速度制御技術は、割当てられたビットレートをエンコーダが使用してビデオ・シーケンスを符号化する方法を決定し得る。エンコーダは典型的に所定ビットレートへと符号化することを目的とする共に、速度制御技術は、エンコーダにより生成されるビットレートを所定ビットレートに対して可及的に近付けて整合せねばならない。速度制御技術はまた、ビデオ・シーケンスが復号化されるときにそのビデオ・シーケンスの最高の視覚的品質を確実にする様式でビットレートを割当てることも目的とし得る。速度制御の多くは、量子化数を調節することにより実施される。量子化数は、エンコーダがビデオ・シーケンスを如何に精細にコード化するかを決定する。量子化数が小さいほど品質は高く、ビット消費が多くなる結果となる。故に速度制御アルゴリズムは、ビデオ品質およびビット消費という競合関係をバランスさせる様式で量子化数を改変することを目的とする。
【0337】
本発明の実施例によるエンコーダは、種々の異なる速度制御技術の内の任意の技術を利用し得る。一実施例においては、単一パス速度制御技術が用いられる。他の実施例においては、二重(もしくは多重)パス速度制御技術が用いられる。これに加え、必要に応じて「ビデオ・バッファ検証式」速度制御が実施され得る。これらの技術の特定例は、以下で論じられる。但し、本発明の実施方法に従うエンコーダにおいては任意の速度制御技術が使用され得る。
【0338】
3.5.5.1.ワンパス速度制御
本発明の実施例によるワンパス速度制御技術の実施例は、速い動作のシーンに対して高いビットレート・ピークを許容することを目的とする。幾つかの実施例においてワンパス速度制御技術は、シーンにおける動作の量の増大に応じてビットレートを徐々に増大すると共に、シーンにおける動作の減少に応じてビットレートを迅速に減少することを目的とする。
【0339】
一実施例においてワンパス速度制御アルゴリズムは、ビットレートを追尾すべく2つの平均化期間を用いる。長期平均は全体的なビットレート収束を確実にし、短期平均はシーンにおける動作の量の変動に対する応答を可能とする。
【0340】
図3.8.には、本発明の実施例によるワンパス速度制御技術が示される。ワンパス速度制御技術580は、所望のビットレート、ビデオ・フレーム速度および(以下において更に論じられる)種々の他のパラメータによりエンコーダを初期化(584)することにより開始(582)する。量子化数を表す浮動小数点変数が記憶される。もしフレームが量子化(586)を必要とするなら、浮動小数点変数が読み出され(588)、量子化数はその浮動小数点変数を最も近い整数に丸めることで求められる。フレームは次に符号化(590)される。フレームの符号化の間においては観察が為され、新たな量子化数値の決定(592)が可能とされる。プロセスは、更なるフレームが無くなるまで反復することを判断(594)する。その時点において、符号化は完了(596)する。
【0341】
で論じられた如くエンコーダは種々のパラメータにより初期化(584)される。これらのパラメータは、「ビットレート」、「フレーム速度」、「最大キー・フレーム間隔」、「最大量子化数」、「最小量子化数」、「平均化期間」、「反応期間」および「上/下比率」である。以下の内容は、これらのパラメータの各々に対する考察である。
【0342】
3.5.5.1.1.「ビットレート」
「ビットレート」パラメータは、符号化の目標ビットレートを設定する。
【0343】
3.5.5.1.2.「フレーム速度」
「フレーム速度」は、ビデオの各フレーム間の期間を定義する。
【0344】
3.5.5.1.3.「最大キー・フレーム間隔」
「最大キー・フレーム間隔」は、キー・フレーム間の最大間隔を特定する。キー・フレームは通常、コーデックがシーン変化を検出したときに、符号化ビデオに自動的に挿入される。シーンが単一カットなしで長い間隔に亙り継続的するという状況において、当該キー・フレーム間の間隔が常に「最大キー・フレーム間隔」以下であることを確実にすべくキー・フレームが挿入され得る。一実施例において「最大キー・フレーム間隔」パラメータは300フレームの値に設定され得る。他の実施例においては、他の値が使用され得る。
【0345】
3.5.5.1.4.「最大量子化数」および「最小量子化数」
「最大量子化数」および「最小量子化数」パラメータは、符号化において使用される量子化数の上下の境界を設定する。一実施例において量子化数境界は、1〜31の値に設定される。
【0346】
3.5.5.1.5.「平均化期間」
「平均化期間」パラメータは、量子化数を改変するときに考慮されるビデオの量を制御する。平均化期間が長いと、典型的には、更に正確な全体的速度を有する符号化ビデオに帰着する。一実施例においては2000の「平均化期間」が用いられる。但し、他の実施例においては他の値が使用され得る。
【0347】
3.5.5.1.6.「反応期間」
「反応期間」パラメータは、最近のシーンにおける動作の変化に対してエンコーダが如何に迅速に適合するかを決定する。「反応期間」値が長いと、品質は更に良好で速い動作のシーン、および、品質は更に低下して遅い動作のシーンに帰着する。一実施例においては、10の「反応期間」が用いられる。但し、他の実施例においては他の値が使用され得る。
【0348】
3.5.5.1.7.「上/下比率」
「上/下比率」パラメータは、速いまたは遅い動作のシーンに応じた量子化数調節に対する相対感度を制御する。大きな値は典型的に、高品質で速い動作のシーンおよび大きなビット消費に帰着する。一実施例においては20の「上/下比率」が用いられる。但し、他の実施例においては他の値が使用され得る。
【0349】
3.5.5.1.8.量子化数値の計算方法
で論じられた如くワンパス速度制御技術は、各フレームの符号化の後で量子化数値の計算を包含する。以下の内容は、量子化数値を更新すべく使用され得る本発明の実施例による技術の説明である。
【0350】
エンコーダは、ビットレートの移動平均の「平均化期間」(Paverage)および「反応期間」(Preaction)に等しい2つの指数的移動平均を維持する。その2つの指数的移動平均は以下の関係に従い計算され得る。
【0351】
【数11】
【0352】
そこで、
Atは瞬間tにおける平均であり、
At-1は瞬間t−Tにおける平均(通常は先行フレームにおける平均)であり、
Tは間隔期間(通常はフレーム時間)を表し、かつ、
Pは、Paverageおよび/またはPreactionとされ得る平均期間である。
【0353】
で計算された移動平均は次に、以下の計算を用いてビデオにおける現在の瞬間と最後の瞬間との間の時的間隔により除算されることで、ビットレートへと調節される。
【0354】
【数12】
【0355】
そこで、
Rtはビットレートであり、
Atは移動平均のいずれかであり、かつ、
Tは現在の瞬間と最後の瞬間との間の時的間隔(それは通常はフレーム速度の逆数)である。
【0356】
エンコーダは以下の如く、次のフレームの目標ビットレート(Rtarget)を計算し得る。
Rtarget = Roverall + (Roverall − Raverage)
そこで、
Roverallは、ビデオ全体に対して設定された全体的ビットレートであり、かつ、
Raverageは、長い平均化期間を用いる平均ビットレートである。
【0357】
幾つかの実施例において目標ビットレートは、全体的ビットレートの75%にて下方に境界付けられる。もし目標ビットレートが境界より低く低下したなら、それは境界の上方に押しやられ、ビデオの品質が確実とされる。
【0358】
エンコーダは次に、RtargetとRreactionとの間の差に基づいて内部量子化数を更新する。もしRreactionがRtargetより小さければ、先行フレームは比較的に複雑さが少なかった可能性が在る。故に量子化数は、以下の計算を実施することにより減少され得る。
【0359】
【数13】
【0360】
RreactionがRtargetより大きいとき、先行フレームは比較的に高レベルの複雑さを保有していた可能性が高い。故に量子化数は、以下の計算を実施することで増大され得る。
【0361】
【数14】
【0362】
式中、Sは「上/下比率」である。
【0363】
3.5.5.1.9.B−VOP符号化方法
上述のアルゴリズムは、B−VOP符号化方法に対しても適用され得る。符号化方法においてB−VOPが有効化されたとき、B−VOPに対する量子化数(QB)は、B−VOPに追随するP−VOPの量子化数(QP)に基づいて選択される。値は、次の関係に従い求められ得る。
QB=2・QP QP≦4の場合、
QB=5+(3/4)・QP 4<QP≦20の場合、
QB=QP QP≧20の場合。
【0364】
3.5.5.2.ツーパス速度制御
2回の(または複数回の)パスの速度制御を使用する本発明の実施例によるエンコーダは、第1のパスにおいてはビデオ・シーケンスのプロパティを決定してから、シーケンス全体のプロパティの知見を以てビデオ・シーケンスを符号化し得る。故にエンコーダは各フレームの量子化レベルを、ビデオ・シーケンスにおける他のフレームと比較した相対的な複雑さに基づいて調節し得る。
【0365】
本発明の実施例によるツーパス速度制御技術においてエンコーダは、ビデオは上述のワンパス速度制御技術に従い符号化されかつ各フレームの複雑さが記録される(複雑さを測定する種々の異なる測定値の内の任意のものが使用され得る)という第1のパスを実施する。平均の複雑さ、故に平均量子化数(Qref)は、第1のパスに基づいて決定され得る。
第2のパスにおいては、第1のパスの間に計算された複雑さの値に基づいて決定される量子化数を以て符号化される。
【0366】
3.5.5.2.1.I-VOPに対する量子化数
次のフレームがI−VOPでないとすれば、I−VOPに対する量子化数Qは0.75×Qrefに設定される。もし次のフレームもI−VOPであれば、(現在のフレームに対する)Qは1.25×Qrefに設定される。
【0367】
3.5.5.2.2.P−VOPに対する量子化数
P−VOPに対する量子化数は以下の式を用いて決定され得る。
【0368】
【数15】
【0369】
そこで、
Ccomplexityはフレームの複雑さであり、
^Ccomplexityはビデオ・シーケンスの平均の複雑さである。
F(x)は、量子化値xを有する量子化数を用いてフレームを符号化するために必要なビットの個数を与えるためにフレームの複雑さが乗算されるべき数を提供する関数である。F-1(x)はF(x)の逆関数であり、かつ、kは強度パラメータである。
【0370】
以下の表は、量子化数Qと共にエンコーダを用いてフレームを符号化するために必要なビットの個数を決定するためにフレームの複雑さと乗算されるべき係数を生成すべく使用され得る関数F(Q)の実施例を定義している。
【0371】
【表8】
【0372】
もし強度パラメータkがゼロに選択されるべきであれば、結果は一定の量子化数である。強度パラメータが1に選択されるべきとき、量子化数はCcomplexityに比例する。本発明の実施例による幾つかのエンコーダは、0.5に等しい強度パラメータkを有する。
【0373】
3.5.5.2.3.B−VOPに対する量子化数
B−VOPに対する量子化数Qは、上述のワンパス技術においてB−VOPに対する量子化数を選択したのと同一の技術を使用して選択され得る。
【0374】
3.5.5.3.ビデオ・バッファ照合式の速度制御
フレームを表すために必要なビットの個数は、ビデオ・シーケンスの特性に依存して変化し得る。殆どの通信システムは、一定のビットレートで動作する。可変的ビットレート通信が遭遇し得る問題は、リソース使用におけるピークを取り扱うために十分なリソースを割当てることである。本発明の実施例による幾つかのエンコーダは、可変的ビットレート通信のビットレートが急激に上昇するときにおけるデコーダのビデオ・バッファのオーバーフローを阻止する意図でビデオを符号化する。
【0375】
ビデオ・バッファ照合器(VBV)速度制御の目的としては、送信されたときにデコーダのバッファを超過しないビデオの生成が挙げられる。これに加え、符号化されたビデオは目標ビットレートと整合すること、および、速度制御により高品質ビデオが生成されることが望ましい。
【0376】
本発明の幾つかの実施例によるエンコーダは、少なくとも2つのVBV速度制御技術の選択肢を提供する。一方のVBV速度制御技術は因果的速度制御(causal rate control)と称され、他方の技術は第Nパス速度制御(Nth pass rate control)と称される。
【0377】
3.5.5.3.1.因果的速度制御
因果的なVBV速度制御は、ワンパス速度制御技術と組み合わせて使用され得ると共に、単に現在の量子化数値と先行量子化数値とに基づいて出力を生成する。
【0378】
本発明の実施例によるエンコーダは、以下の関係に従いフレームnに対する量子化数(すなわちQn)を設定する段階を包含する因果的速度制御を含む。
【0379】
【数16】
【0380】
式中、
Q’nは、単一パス速度制御により評価された量子化数であり、
Xbitrateは、所望ビットレートからのドリフトに基づき目標ビットレートを決定することにより計算され、
Xvelocityは、VBVバッファがオーバーフローまたはアンダーフローするまでの見積もり時間に基づき計算され、
Xsizeは、P−VOPの結果のみに適用され、かつ、圧縮されたP−VOPのサイズが経時的に変化する速度に基づいて計算され、
Xdriftは、所望ビットレートからのドリフトである。
【0381】
幾つかの実施例において因果的VBV速度制御は、フレームを脱落させると共に補充物を挿入してVBVモデルを顧慮することを強いられ得る。もし、圧縮されたフレームが意外に多すぎるまたは少なすぎるビットを含むなら、それは除外もしくは補充され得る。
【0382】
3.5.5.3.2.第NパスVBV速度制御
第NパスVBV速度制御は、多重パス速度制御技術と組み合わせて使用され得ると共に、それは、ビデオ・シーケンスの先行分析の間に生成された情報を使用する。本発明の幾つかの実施例によるエンコーダは、図3.9.に示された処理に従い第NパスVBV速度制御を実施する。処理600は第1パスで開始し、その間に分析(602)が実施される。マップ生成が実施(604)され、かつ、方針が生成(606)される。次に、第nパス速度制御が実施(608)される。
【0383】
3.5.5.3.3.分析
一実施例において、第1のパスは一定形態の因果的速度制御を使用し、かつ、データは、フレームの持続時間、フレームのコード化形式、使用される量子化数、生成される動作ビット、および、生成されたテクスチャ・ビットなどの事項に関して各フレームに対して記録される。これに加え、時間目盛、解像度およびコーデック設定などの包括的情報も記録され得る。
【0384】
3.5.5.3.4.マップ生成
分析からの情報は、ビデオ・シーケンスのマップを生成すべく用いられる。そのマップは、各フレーム(I/B/P)に対して使用されたコード化形式を特定し得ると共に、フレームの持続時間、動作の複雑さおよびテクスチャの複雑さに関して各フレームに対するデータを含み得る。他の実施例においてそのマップは、圧縮されたフレーム・サイズおよび認識的歪曲に対する量子化数および他のパラメータの影響の更に良好な予測を可能とする情報も含み得る。幾つかの実施例において、マップ生成は第N-1パスが完了した後で実施される。
【0385】
3.5.5.3.5.方針作成
マップは、第Nパス速度制御が如何に動作するかに関する方針を計画するために使用され得る。各フレームが符号化された後におけるVBVバッファの理想的レベルが、計画され得る。一実施例において方針を作成すると、所望の圧縮フレーム・サイズ、見積もられたフレーム・量子化数を含め、各フレームに対する情報に帰着する。幾つかの実施例において方針作成は、マップ生成の後で第Nパスに先立って実施される。
【0386】
一実施例において方針作成プロセスは、エンコーダをシミュレートする反復的プロセスであって、可及的に量子化数の中央値に近く量子化数の維持を試行することにより各フレームに対する所望の量子化数値を決定する反復的プロセスを使用する段階を包含する。ビデオ・シーケンス全体に対する基礎量子化数を生成すべく、2進検索が使用され得る。基礎量子化数は、シミュレータに対して所望の目標ビットレートを達成させる一定値である。基礎量子化数が一旦見出されたなら、方針作成プロセスは、VBV制約を考慮する段階を包含する。一実施例において、当該一定の量子化数がVBV制約を改変しないのであれば、一定の量子化数が用いられる。他の実施例において量子化数は、ビデオ・フレームにおける動作の複雑さに基づいて変調される。これは更に、シーン変化および他の一時的効果からのマスキングの取入れへと拡張され得る。
【0387】
3.5.5.3.6.インループ第Nパス速度制御
一実施例において、インループ(in-loop)第Nパス速度制御は方針を使用すると共にマップを使用して、圧縮フレーム・サイズおよび認識的歪曲に関する量子化数および他のパラメータの影響の最適な可能的予測を行う。短期補正方針を採用すべく方針から逸脱する自由裁量は、限られ得る。典型的には、方針に追随すると、VBVモデルからの逸脱は防止される。一実施例においてループ内における第Nパス速度制御は、PID制御ループを使用する。その制御ループにおけるフィードバックは、理想的ビットレートからの蓄積ドリフトである。
【0388】
方針作成はフレームの脱落を伴わないが、VBVバッファが別様にアンダーフローするならば、ループ内における第N速度制御はフレームを脱落させることもある。同様に、ループ内における第Nパス速度制御はVBVオーバーフローを防止すべく、ビデオ補充物の挿入を要求し得る。
【0389】
3.5.6.予測
一実施例においては、ISO/IEC 14496-2:2001(E)、セクション7.4.3.(DCおよびAC予測)および7.7.1.(フィールドDCおよびAC予測)と称される規格に準拠する様式でAD/DC予測が実施される。
【0390】
3.5.7.テクスチャ・コーディング
本発明の実施例によるエンコーダは、ISO/IEC 14496-2:2001(E)、付属文書B(可変長コード)および7.4.1.(可変長復号化)と称される規格に準拠する様式でテクスチャ・コーディングを実施し得る。
【0391】
3.5.8.動作コーディング
本発明の実施例によるエンコーダは、ISO/IEC 14496-2:2001(E)、付属文書B(可変長コード)および7.6.3.(動作ベクトル復号化)と称される規格に準拠する様式で動作コーディングを実施し得る。
【0392】
3.5.9.「ビデオ」チャンクの生成方法
ビデオ・トラックは、フレーム1〜Nのシーケンスと見做され得る。本発明の実施例によるシステムは、シーケンスを復号化して圧縮ビットストリームを生成し得る。そのビットストリームは、それをチャンク1〜Nにセグメント化することによりフォーマットされる。各ビデオ・フレームnは、対応するチャンクnを有する。
【0393】
各チャンクは、本発明の実施例によるデコーダがビデオ・フレームnを復号化するに十分な情報を、チャンクnがチャンク1〜n-1と共に含むまで、ビットストリームからのビットをそのチャンクnに追加することにより生成される。ビデオ・フレームnを生成するに十分な情報がチャンク1〜n-1に含まれた場合、本発明の実施例によるエンコーダはマーカ・チャンクを含み得る。一実施例においてそのマーカ・チャンクは、コード化されていないPフレームであって先行フレームと同一のタイミング情報を備えたPフレームである。
【0394】
3.6,「subtitle」チャンクの生成方法
本発明の実施例によるエンコーダは、一連の標準的フォーマットの内のひとつのフォーマットでサブタイトルを取り込んでから、そのサブタイトルをビットマップへと変換し得る。そのビットマップにおける情報は次に、ランレングス符号化方法を用いて圧縮される。ランレングス符号化されたビットマップはフォーマットされてチャンクとされるが、これは、そのチャンク内に含まれた特定サブタイトルに対する開始時間および停止時間に関する情報も含んでいる。幾つかの実施例においては、画面上におけるサブタイトルの色、サイズおよび位置に関する情報もチャンク内に含まれ得る。チャンクは、サブタイトルに対するパレットを設定するサブタイトルトラックであってそのパレットが変更されたことを表すサブタイトルトラックへと含まれ得る。サブタイトルのテキストを生成するためには、標準的なサブタイトル・フォーマットでサブタイトルを生成し得る任意のアプリケーションが使用され得る。代替的に、ユーザにより入力されたテキストを直接的にサブタイトル情報へと変換するソフトウェアが使用され得る。
【0395】
3.7.交互配置方法
上述のチャンクの全てをインタリーバが一旦受信したなら、そのインタリーバはマルチメディア・ファイルを構築する。マルチメディア・ファイルの構築は、「CSET」チャンク、「INFO」リスト・チャンク、「hdrl」チャンク、「movi」リスト・チャンクおよびidxlチャンクを生成する段階を包含し得る。これらのチャンクを生成してマルチメディア・ファイルを生成する本発明の実施例による方法は、以下に記述される。
【0396】
3.7.1.「CSET」チャンクの生成方法
上述された如く「CSET」チャンクは選択的であり、かつ、AVIコンテナ・フォーマット仕様に従いインタリーバにより生成され得る。
【0397】
3.7.2.「INFO」リスト・チャンクの生成方法
上述された如く「INFO」リスト・チャンクは選択的であり、かつ、AVIコンテナ・フォーマット仕様に従いインタリーバにより生成され得る。
【0398】
3.7.3.「hdrl」リスト・チャンクの生成方法
「hdrl」リスト・チャンクは、インタリーバに対して提供される種々のチャンクにおける情報に基づき、そのインタリーバにより生成される。「hdrl」リスト・チャンクは、参照されたチャンクのリスト内の箇所を参照する。一実施例において「hdrl」リスト・チャンクは、リファレンスを確立するためにファイル・オフセットを使用する。
【0399】
3.7.4.「movi」リスト・チャンクの生成方法
上述された如く「movi」リスト・チャンクはオーディオ、ビデオおよびサブタイトルトラックを符号化して「オーディオ」、「ビデオ」および「subtitle」チャンクを生成してからこれらのチャンクを交互配置することにより生成される。幾つかの実施例において「movi」リスト・チャンクは、デジタル著作権管理情報も含み得る。
【0400】
3.7.4.1.ビデオ/オーディオ/サブタイトルの交互配置方法
オーディオ、ビデオおよびサブタイトル・チャンクを交互配置するために、種々の規則が使用され得る。典型的にインタリーバは、ビデオおよびオーディオ・トラックの各々に対して所定数の待ち行列(queue)を確立する。そのインタリーバは、どの待ち行列が出力ファイルに書き込まれるべきかを決定する。待ち行列選択は、最低数の被書き込み交互配置期間を有する待ち行列から書き込むことにより、交互配置期間に基づき得る。インタリーバは、チャンクがファイルに対して書き込まれ得る前に、待ち行列内に存在する交互配置期間全体を待機すべきこともある。
【0401】
一実施例において、生成された「オーディオ」、「ビデオ」および「subtitle」チャンクは、当該「ビデオ」チャンクが対応するビデオ・フレームに関する情報を含む「ビデオ」チャンクに先立ち「オーディオ」および「subtitle」チャンクがファイル内に配置される様に交互配置される。他の実施例において「オーディオ」および「subtitle」チャンクは、それらが対応する「ビデオ」チャンクの後に配置され得る。「オーディオ」、「ビデオ」および「subtitle」チャンクの箇所間の時間差は、デバイスを再生するために使用されるプレーヤのバッファ能力に大きく依存する。バファリングが制限されもしくは未知である実施例においてインタリーバは、「オーディオ」および「subtitle」チャンクが「ビデオ」チャンクの間に配置される如く「オーディオ」、「ビデオ」および「subtitle」チャンクを交互配置し、その場合、「オーディオ」および「subtitle」チャンクの直後に追随する「ビデオ」チャンクは、そのオーディオもしくはサブタイトルに対応する最初のビデオ・フレームを含む。
【0402】
3.7.4.2.DRM情報の生成方法
マルチメディア・ファイルのビデオ内容を保護すべくDRMが使用される実施例において、DRM情報はビデオ・チャンクの符号化と同時的に生成され得る。各チャンクが生成されるにつれ、そのチャンクは暗号化され得ると共に、ビデオ・チャンクの暗号化に関する情報を含むDRMチャンクが生成され得る。
【0403】
3.7.4.3.DRM情報の交互配置方法
本発明の実施例によるインタリーバは、ビデオ・チャンクに先立ち、ビデオ・チャンクの暗号化に関する情報を含むDRMチャンクを交互配置する。一実施例において、ビデオ・チャンクnに対するDRMチャンクはビデオ・チャンクn-1およびビデオ・チャンクnの間に配置される。他の実施例において、ビデオ・チャンクnの前後におけるDRMの間隔は、マルチメディア・ファイルを復号化するデバイス内に配備されたバファリングの量に依存する。
【0404】
3.7.5.「idxl」チャンクの生成方法
「movi」チャンクが生成されたなら、「idxl」チャンクの生成は単純なプロセスである。「idxl」チャンクは、「movi」リスト・チャンク内での各「data」チャンクの位置を読み取ることで生成される。この情報は、「data」チャンクから読み取られた情報であってその「data」チャンクが属するトラックに関する情報と、その「data」チャンクの内容とに対して組み合わされる。この情報の全ては次に、上述のフォーマットのいずれであれ、情報を表すべく使用されているフォーマットに対して適切な様式で「idxl」チャンク内に挿入される。
【0405】
4.マルチメディア・ファイルの送信および配信
マルチメディア・ファイルが生成されたなら、そのファイルは種々のネットワークの内の任意のネットワークに亙り配信され得る。多くの実施例において特に、マルチメディア・プレゼンテーションおよびメニューを生成するために必要な要素は単一ファイル内に含まれるという事実により、情報の転送が簡素化される。幾つかの実施例においてマルチメディア・ファイルは、そのマルチメディア・ファイルの内容を復号化するに必要な情報とは別体的に配信され得る。
【0406】
一実施例においてマルチメディア内容は、第1サーバに提供されると共に、符号化されて本発明によるマルチメディア・ファイルを生成する。そのマルチメディア・ファイルは次に、第1サーバまたは第2サーバのいずれかに配置され得る。他の実施例においては、第1サーバ、第2サーバまたは第3サーバにDRM情報が配置され得る。一実施例において第1サーバは、符号化されたマルチメディア・ファイルの箇所を確認すべく、および/または、DRM情報の箇所を確認すべく、照会され得る。
【0407】
5.マルチメディア・ファイルの復号化方法
本発明の実施例によるマルチメディア・ファイルからの情報は、適切なソフトウェアと、マルチメディア・ファイルから情報をアクセスすべくハード結線された専用プレーヤまたはAVIファイルを解析し得る他の任意のデバイスとを用いて構成されたコンピュータによりアクセスされ得る。幾つかの実施例においてデバイスは、マルチメディア・ファイル内の全ての情報にアクセスし得る。他の実施例においてデバイスは、本発明の実施例によるマルチメディア・ファイル内の全ての情報にアクセスし得なくても良い。特定実施例においてデバイスは、上述の情報であってAVIファイル・フォーマットにおいて仕様を定められていないチャンク内に記憶された情報のいずれにもアクセスし得ない。情報の全てがアクセスはされ得ない実施例において、当該デバイスは典型的に、そのデバイスにより認識されないチャンクを切り捨てる。
【0408】
典型的に、本発明の実施例によるマルチメディア・ファイルに含まれた情報にアクセスし得るデバイスは、多数の機能を実施し得る。そのデバイスは、ビデオの表示を含むマルチメディア・プレゼンテーションを視覚的ディスプレイ上に表示し、可能的には多数のオーディオ・トラックの内のひとつのトラックからのオーディオをオーディオ・システム上に生成し、かつ、可能的には多数のサブタイトルトラックの内のひとつのトラックからのサブタイトルを表示し得る。幾つかの実施例は、付随するオーディオおよび/またはビデオを再生する一方、視覚的ディスプレイ上にメニューも表示し得る。これらの表示メニューは、選択可能なボタン、プルダウン・メニューおよび下位メニューなどの特徴により、インタラクティブである。一定の実施例においてメニュー項目は、現在においてアクセスされているマルチメディア・ファイル以外のオーディオ/ビデオ・コンテンツを指し示し得る。外部コンテンツは、マルチメディア・ファイルにアクセスしているデバイスに対してローカル的に配置され得るか、または、それはローカル・エリア・ネットワーク、広域ネットワークまたは公衆回線網などを介して遠隔的に配置され得る。また多くの実施例は、単一もしくは複数のマルチメディア・ファイル内に含まれる「メタデータ」、または、ひとつ以上のマルチメディア・ファイルにより参照された「メタデータ」に従い、ひとつ以上のマルチメディア・ファイルを検索することも可能である。
【0409】
5.1.マルチメディア・プレゼンテーションの表示
本発明の実施例によるマルチメディア・ファイルの能力であって複数のオーディオ・トラック、複数のビデオ・トラックおよび複数のサブタイトルトラックをサポートする能力が与えられたなら、ビデオ、オーディオおよび/またはサブタイトルを組み合わせたマルチメディア・ファイルを用いるマルチメディア・プレゼンテーションを表示するためには、視覚的メニュー・システムもしくはプルダウン・メニュー・システム(その動作は以下で論じられる)により、または、マルチメディア・プレゼンテーションを生成すべく使用されるデバイスの既定設定を介し、特定のオーディオ・トラック、ビデオ・トラックおよび/またはサブタイトルトラックを選択する必要があり得る。オーディオ・トラック、ビデオ・トラックおよび可能的にはサブタイトルトラックが選択されたなら、マルチメディア・プレゼンテーションの表示が進展し得る。
【0410】
図4.0.には、マルチメディア・ファイルからDRMを含む必要なマルチメディア情報を位置決定すると共にマルチメディア情報を表示する本発明の実施例によるプロセスが示される。処理620は、DRMヘッダを復号化するに必要な暗号化キーを獲得(622)する段階を含む。暗号化キーは次に、DRMヘッダを復号化(624)すべく使用され、かつ、第1のDRMチャンクがマルチメディア・ファイルの「movi」リスト・チャンク内で検索(626)される。「DRM」チャンクを復号化するに必要な暗号化キーは「DRM」ヘッダ内のテーブルから獲得(628)され、その暗号化キーは、暗号化されたビデオ・チャンクを復号化すべく用いられる。次に、必要とされるオーディオ・チャンクおよびビデオ・チャンクに付随する一切の必要なサブタイトル・チャンクが復号化(630)され、かつ、オーディオ、ビデオおよび一切のサブタイトル情報はディスプレイおよび音響システムを介して提示される(632)。
【0411】
幾つかの実施例において、選択されたオーディオ・トラックはステレオまたはサラウンド音響オーディオを提供する多重チャネルを含み得る。サブタイトルトラックが表示されるべく選択されたとき、先行ビデオはサブタイトルを含んでいたか否かに関する決定が為され得る(この決定は、現在において復号化されたビデオ・フレームに亙り表示されるべきサブタイトル情報を含んでいた先行「subtitle」チャンクを識別するという結果を達成する種々の様式の内の任意の様式で為され得る)。もし先行サブタイトルがサブタイトルを含んでおりかつそのサブタイトルに対するタイミング情報がそのサブタイトルは現在のフレームと共に表示されるべきことを表すなら、そのサブタイトルは、復号化されたビデオ・フレーム上にスーパーインポーズされる。先行フレームがサブタイトルを含んでおらず、または、先行フレーム上のサブタイトルに対するタイミング情報は、現在復号化されたフレームと組み合わせてそのサブタイトルが表示されてはならないことを表すなら、選択されたサブタイトルトラックに対する「subtitle」チャンクが探索される。もし「subtitle」チャンクが位置決定されたなら、そのサブタイトルは、復号化されたビデオにスーパーインポーズされる。(スーパーインポーズされた一切のサブタイトルを含む)ビデオは次に、付随するオーディオと共に表示される。
【0412】
図4.0.の考察を参照するとプロセスは、何らかの付加的なDRMチャンクが在るか否かを決定(634)する。もし在れば、次のDRMチャンクが位置決定(626)され、そのプロセスは付加的なDRMチャンクが無くなるまで継続する。その時点において、オーディオ、ビデオおよび/またはサブタイトルトラックのプレゼンテーションは完了(636)する。
【0413】
幾つかの実施例においてデバイスは、本発明によるマルチメディア・ファイルの「hdrl」チャンク内に含まれた情報を用い、マルチメディア情報の特定部分(たとえば、映画の特定シーンであって特定の付随オーディオ・トラックおよび選択的には特定の付随サブタイトルトラックなど)を探索し得る。多くの実施例において、「ビデオ(video)」チャンク、「オーディオ(audio)」チャンクおよび/または「サブタイトル(subtitle)」チャンクの復号化は、他のタスクと並行して実施され得る。
【0414】
マルチメディア・ファイルからの情報にアクセスし得ると共に特定のオーディオ・トラックおよび/または特定のサブタイトルトラックと組み合わせてビデオを表示し得るデバイスの例は、ソフトウェアを用いて上述の様式で構成されたコンピュータである。別の例は、これらの機能を含むコーデックを備えたDVDプレーヤである。他の実施例において、(意図的であれ任意的であれ)特定メディア・トラックに対応する「data」チャンクを検索もしくは選択し、かつ、プレゼンテーションのためにこれらのトラックを復号化すべく構成された任意のデバイスは、本発明の実施方法に係るマルチメディア・ファイルを用いてマルチメディア・プレゼンテーションを生成し得る。
【0415】
幾つかの実施例においてデバイスは、マルチメディア・ファイルからの情報を、外部ファイルからのマルチメディア情報と組み合わせて再生し得る。典型的に斯かるデバイスは、上述の形式のマルチメディア・ファイルにおいて参照されたローカル・ファイルからのオーディオ・トラックもしくはサブタイトルトラックを調達することにより、それを行う。参照されたファイルがローカル的には記憶されておらず、かつ、デバイスが、デバイスが記憶された箇所に対してネットワークされていれば、そのデバイスはファイルのローカル・コピーを獲得し得る。デバイスは次に両方のファイルにアクセスし、マルチメディアの種々のトラックが異なるファイル・ソースから供給されるというビデオ、オーディオおよび(必要であれば)サブタイトルのパイプラインを確立する。
【0416】
5.2.メニューの生成
図4.1.には、本発明の実施例によるデコーダが示される。デコーダ650は、本発明の実施例によるマルチメディア・ファイル652をデマルチプレクサ654に対して提供することにより、そのファイルを処理する。デマルチプレクサはマルチメディア・ファイルから「DMNU」チャンクを抽出すると共に、その「DMNU」チャンクから全ての「LanguageMenus」チャンクを抽出し、それらをメニュー・パーサ656に対して提供する。デマルチプレクサはまた、「DMNU」チャンクから全ての「Media」チャンクも抽出し、それらをメディア・レンダラ(media renderer)658に対して提供する。メニュー・パーサ656は、「LanguageMenus」チャンクからの情報を解析することで、その「LanguageMenus」チャンクにおいて定義されたメニュー構造を表す状態マシンを構築する。メニュー構造を表す状態マシンは、ユーザに対する表示を提供すべくかつユーザの命令に応答すべく使用され得る。状態マシンは、メニュー状態コントローラ660に対して提供される。そのメニュー状態コントローラは、メニュー状態マシンの現在状態を追尾すると共に、ユーザから命令を受ける。ユーザからの命令は、状態遷移を引き起こし得る。ユーザに対して提供される初期表示、および、表示に対する一切の更新であってメニュー状態遷移を伴う更新は、メニュー・プレーヤ・インタフェース662を用いて制御され得る。メニュー・プレーヤ・インタフェース662は、メニュー状態コントローラおよびメディア・レンダラに対して接続され得る。メニュー・プレーヤ・インタフェースはメディア・レンダラに対し、メディア・チャンクからどのメディアが抽出されかつそのメディア・レンダラに接続されたプレーヤ664を介してユーザに対して提供されるべきかを指示する。ユーザはプレーヤに対し、キーボード、マウスまたはリモコンなどの入力デバイスを用いて指示を与え得る。概略的にマルチメディア・ファイルはユーザに対して最初に表示されるメニューを決定し、かつ、ユーザの指示は初期メニューの生成に続いて表示されるオーディオおよびビデオを決定する。図4.1.に示されたシステムは、コンピュータおよびソフトウェアを用いて実現され得る。他の実施例においてシステムは、機能固有集積回路、または、ソフトウェアおよびファームウェアの組み合わせを用いて実現され得る。
【0417】
図4.2.には、本発明の実施例によるメニューの例が示される。メニュー表示670は、4個のボタンエリア672と、タイトル676を含むバックグラウンド・ビデオ674と、ポインタ678とを含む。メニューは、(図示しない)バックグラウンド・オーディオも含む。表示により生成される視覚的効果は外面的とされ得る。各ボタンの視覚的外観は典型的にはバックグラウンド・ビデオの一部であり、かつ、ボタン自体は、バックグラウンド・ビデオの単なる定義領域であってポインタにより起動されたときにその領域に関係付けられた特定動作を有するという定義領域である。ポインタは典型的にはオーバレイである。
【0418】
図4.3.は、図4.2.に示された表示における全ての情報のソースを概念的に示している。バックグラウンド・ビデオ674は、メニュー・タイトル、ボタンの視覚的外観、および、表示のバックグラウンドを含み得る。これらの要素および付加的要素の全ては、静止的または動画的に出現し得る。バックグラウンド・ビデオは、「メディアトラック(MediaTrack)」チャンク700に含まれる情報であってビデオ・トラック702内におけるバックグラウンド・ビデオの箇所を表す情報を用いて抽出される。メニューに付随し得るバックグラウンド・オーディオ706は、オーディオ・トラック710内におけるそのバックグラウンド・オーディオの箇所を表す「メディアトラック(MediaTrack)」チャンク708を用いて検索され得る。上述された如く、ポインタ678はオーバレイ713の一部である。オーバレイ713は、バックグラウンド・ビデオの一部分であってボタンとして現れる一部分を強調すべく現れるグラフィックも含み得る。一実施例においてオーバレイ713は、オーバレイトラック714内におけるそのオーバレイの箇所を表す「MediaTrack」チャンク712を用いて獲得される。メニューがユーザと対話する様式は、ボタンの各々に関係付けられた(図示しない)「Action」チャンクにより定義される。図示実施例においては、「PlayAction」チャンク716が示される。その「PlayAction」チャンクは、マルチメディア・ファイル内に含まれたマルチメディア・プレゼンテーション(すなわちオーディオ、ビデオ、および、可能的にはサブタイトルトラック)内のシーンを間接的に参照する(「PlayAction」チャンクにより参照される他のチャンクは示されない)。「PlayAction」チャンク716は最終的に、番組トラック内のシーンを表す「MediaTrack」チャンク718を用いてそのシーンを参照する。選択されたまたは既定のオーディオ・トラックの箇所、および、可能的にはサブタイトルトラックも参照される。
【0419】
ユーザが入力デバイスを用いて命令を入力するにつれて表示は、ボタンエリアの選択に応じて更新されるだけでなく、単にボタンエリア内に配置されつつあるポインタによっても更新され得る。で論じられた如く、メニューを生成すべく使用されるメディア情報の典型的には全てが、マルチメディア・ファイル内、より詳細には「DMNU」チャンク内に配置される。但し他の実施例において、情報はファイル内の他の箇所、および/または、別のファイル内に配置され得る。
【0420】
5.3.メタデータのアクセス
「メタデータ」は、情報を表す標準化方法である。「メタデータ」の標準化性質によれば、データは自動的プロセスによりアクセスされて理解され得る。一実施例において「メタデータ」は、抽出されると共に視認のためにユーザに対して提供される。幾つかの実施例によれば、サーバ上のマルチメディア・ファイルが検査されることで、ユーザの鑑賞習慣および鑑賞選好性に関する情報が提供され得る。斯かる情報はソフトウェア・アプリケーションにより使用されることで、ユーザが鑑賞を楽しみ得る他のマルチメディア・ファイルが推奨され得る。一実施例において推奨は、他のユーザのサーバ上に含まれたマルチメディア・ファイルに基づき得る。他の実施例においてユーザはマルチメディア・ファイルを要求することが可能であり、そのファイルは、種々の箇所におけるマルチメディア・ファイルの「メタデータ」を検査する検索エンジンおよび/またはインテリジェント・エージェントにより位置決定され得る。これに加えてユーザは、マルチメディア・プレゼンテーションの異なるバージョンの各々が符号化された様式に関する「メタデータ」に基づき、種々のマルチメディア・ファイルの中から特定のマルチメディア・プレゼンテーションを含むものを選択し得る。
【0421】
幾つかの実施例において、本発明の実施例によるマルチメディア・ファイルの「メタデータ」は、目録を作成する目的で、または、ファイルの内容にアクセスする単純なメニューを生成するためにアクセスされ得る。
【0422】
上記の記述は発明の多くの特定実施例を含むが、これらは発明の有効範囲に対する制限と解釈されるべきでなく、寧ろ発明のひとつの実例と解釈されるべきである。たとえば本発明の実施例によるマルチメディア・ファイルは、単一のマルチメディア・プレゼンテーションまたは複数のマルチメディア・プレゼンテーションを含み得る。これに加え、斯かるファイルはひとつ以上のメニューと、任意の種々の異なる形式の「メタデータ」を含み得る。故に発明の有効範囲は、図示された実施例によってではなく、添付の各請求項および他の均等物により決定されるべきである。
【技術分野】
【0001】
本発明は一般に、マルチメディア・ファイルの符号化、送信および復号化に関する。より詳細には、本発明は、単一のオーディオ・トラックおよび単一のビデオ・トラックに加えて複数のトラックを含み得るマルチメディア・ファイルの符号化、送信および復号化に関する。
【発明の概要】
【発明が解決しようとする課題】
【0002】
インターネットの発展は、標準化されたファイルの生成、配信および表示を可能とするマルチメディア情報用ファイル・フォーマットの発展を促進した。典型的には、単一のマルチメディア・ファイルは単一のビデオ・トラックおよび単一のオーディオ・トラックを含む。マルチメディアがデジタル・ビデオ・ディスク(DVD)などの高容量で物理的に搬送可能なメディアに書き込まれたときには、多数のビデオ・トラック、オーディオ・トラックおよびサブタイトルトラックを提供するために複数のファイルが使用され得る。インタラクティブなメニューを生成すべく使用され得る情報を含む付加的ファイルが提供され得る。
【課題を解決するための手段】
【0003】
本発明の実施例は、マルチメディア・ファイル、および、マルチメディア・ファイルを生成、配信および復号化するシステムを含む。本発明の一つの形態において、マルチメディア・ファイルは、複数の符号化ビデオ・トラックを含む。本発明の別の形態おいて、マルチメディア・ファイルは複数の符号化オーディオ・トラックを含む。本発明の別の形態において、マルチメディア・ファイルは少なくとも一つのサブタイトルトラックを含む。
本発明の別の形態において、マルチメディア・ファイルは符号化「メタデータ(meta data)」を含む。本発明の別の形態において、マルチメディア・ファイルは符号化されたメニュー情報を含む。
【0004】
本発明の実施例によるマルチメディア・ファイルは、複数の符号化ビデオ・トラックを含む。本発明の更なる実施例において、マルチメディア・ファイルは連結された複数の「リフ(RIFF)」チャンクを備え、かつ、各符号化ビデオ・トラックは別個の「RIFF」チャンク内に含まれる。これに加え、ビデオは心理視覚的強化(psychovisual enhancement)で符号化され、かつ、各ビデオ・トラックは、それに関係付けられた少なくとも1つのオーディオ・トラックを有する。
【0005】
別実施例において、各ビデオ・トラックは、「RIFF」チャンク内における一連の「映像(video)」チャンクとして符号化され、かつ、各ビデオ・トラックに付随するオーディオ・トラックは、関係付けられたビデオ・トラックの「ビデオ」チャンクを含む「RIFF」チャンク内に交互配置(interleave)された一連の「オーディオ(audio)」チャンクとして符号化される。更に、各「ビデオ」チャンクは、ビデオ・トラックからビデオの単一フレームを生成すべく使用され得る情報を含み得ると共に、各「オーディオ」チャンクは、「ビデオ」チャンクを用いて生成されたフレームに付随するオーディオ・トラックの部分からのオーディオ情報を含む。これに加え、「オーディオ」チャンクは「RIFF」チャンク内において対応する「ビデオ」チャンクの前に交互配置され得る。
【0006】
本発明の実施例によるマルチメディア・ファイルを符号化するシステムは、複数のビデオ・トラックを符号化し、符号化ビデオ・トラックを連結し、かつ、連結された符号化ビデオ・トラックを単一ファイルへと書き込むように構成されたプロセッサを含む。別な実施例において、プロセッサは各ビデオ・トラックが別個の「RIFF」チャンク内に含まれるようなビデオ・トラックに符号化すべく構成され、かつ、プロセッサは、心理視覚的強化を用いてビデオを符号化すべく構成される。これに加え、各ビデオ・トラックは自身に関係付けられた少なくとも一つのオーディオ・トラックを有し得る。
【0007】
別な実施例においてプロセッサは、各ビデオ・トラックを「RIFF」チャンク内における一連の「ビデオ」チャンクとして符号化し、かつ、各ビデオ・トラックに付随する少なくとも一つのオーディオ・トラックを、関係付けられたビデオ・トラックの「ビデオ」チャンクを含む「RIFF」チャンク内に交互配置された一連の「オーディオ」チャンクとして符号化するように構成される。
【0008】
さらに別の実施例において、プロセッサは、各「ビデオ」チャンクが、ビデオ・トラックからビデオの単一フレームを生成すべく使用され得る情報を含むようなビデオ・トラックを符号化し、かつ、ビデオ・トラックに関係付けられたオーディオ・トラックを、各「オーディオ」チャンクが、ビデオ・トラックから生成された「ビデオ」チャンクを用いて生成されたフレームに付随するオーディオ・トラックの部分からのオーディオ情報を含む如く、符号化するように構成される。これに加え、プロセッサは、各「オーディオ」チャンクを「RIFF」チャンク内において対応する「ビデオ」チャンクに先立ち交互配置するように構成され得る。
【0009】
本発明の実施例による複数の符号化ビデオ・トラックを含むマルチメディア・ファイルを復号化するシステムは、マルチメディア・ファイルから情報を抽出すべく構成されたプロセッサを含む。そのプロセッサは、マルチメディア・ファイル内に含まれた符号化ビデオ・トラックの数に関する情報を抽出すべく構成される。
【0010】
更なる実施例においてプロセッサは、「RIFF」チャンク内において符号化ビデオ・トラックを検索(locate)すべく構成される。これに加え、標準的な4ccコードを有する第1「RIFF」チャンク内には第1の符号化ビデオ・トラックが含まれ得ると共に、特殊な4ccコードを有する第2「RIFF」チャンク内には第2のビデオ・トラックが含まれ、かつ、特殊化4ccコードは、その特殊化4ccコードの最後の2キャラクタとして、標準的な4ccコードの最初の2キャラクタを有し得る。
【0011】
付加的な実施例において、各符号化ビデオ・トラックは別個に「RIFF」チャンク内に含まれる。
【0012】
更なる別の実施例において、復号化されたビデオ・トラックは、マルチメディア・ファイルを生成する際に符号化されたオリジナルのビデオ・トラックと同様であり、かつ、復号化されたビデオ・トラックとオリジナルのビデオ・トラックとの間における相違点の少なくとも幾つかは、ビデオ・トラックの各フレームの暗い部分内に配置される。更に、復号化されたビデオ・トラックとオリジナルのビデオ・トラックとの間における相違点の少なくとも幾つかは、ビデオ・トラックの速い動作のシーンに配置され得る。
【0013】
再び付加的な実施例において各ビデオ・トラックは、自身に関係付けられた少なくとも1つのオーディオ・トラックを有する。
【0014】
更なる付加的な実施例において、プロセッサは、「RIFF」チャンク内の一連の「ビデオ」チャンクを復号化することにより、ビデオ・トラックからのビデオを表示し、かつ、関係付けられたビデオ・トラックの「ビデオ」チャンクを含む「RIFF」チャンク内に交互配置された一連の「オーディオ」チャンクを復号化することにより、ビデオ・トラックに付随するオーディオ・トラックからオーディオを生成するように構成される。
【0015】
更に別の更なる実施例において、プロセッサは、各「ビデオ」チャンクから抽出された情報を使用してビデオ・トラックの単一フレームを生成し、かつ、各「オーディオ」チャンクから抽出された情報を使用して、「ビデオ」チャンクを使用して生成されたフレームに付随するオーディオ・トラックの部分を生成するように構成される。これに加えてプロセッサは、「RIFF」チャンクにおいて「オーディオ」チャンクが関係付けられた「ビデオ」チャンクに先立ち、「オーディオ」チャンクを位置決定(locate)すべく構成され得る。
【0016】
本発明の実施例によるマルチメディア・ファイルは、一連の符号化ビデオ・フレームと、符号化ビデオ・フレームの間に交互配置された符号化オーディオとを含む。符号化オーディオはオーディオ情報の2つ以上のトラックを含む。
【0017】
更なる実施例において、オーディオ情報のトラックの内の少なくとも1つのトラックは複数のオーディオチャネルを含む。
【0018】
別実施例は更に、マルチメディア・ファイルに含まれたオーディオ・トラックの個数を特定するヘッダ情報と、オーディオ情報のトラックの内の少なくとも1つのトラックに関する説明情報とを含む。
【0019】
再び更なる実施例において、各符号化ビデオ・フレームは、符号化オーディオ情報によって発し、かつ、ビデオ・フレームを発生する符号化オーディオ情報は、符号化ビデオ・フレームに付随する各オーディオ・トラックの部分のためのオーディオ情報を含む。
【0020】
再び別実施例において、ビデオ情報はマルチメディア・ファイル内にチャンクとして記憶される。これに加え、ビデオ情報の各チャンクは、ビデオの単一フレームを含み得る。
更に、オーディオ情報はマルチメディア・ファイル内にチャンクとして記憶され得ると共に、2つの別個のオーディオ・トラックからのオーディオ情報は、オーディオ情報の単一チャンク内には含まれない。
【0021】
更なる実施例において、ビデオ・チャンクは、オーディオ・トラックの各々からの少なくとも1つのオーディオ・チャンクにより分離され、かつ、ビデオ・チャンクを分離するオーディオ・チャンクは、オーディオ・チャンクに追随するビデオ・チャンク内に含まれたビデオ情報に付随するオーディオ・トラックの部分のためのオーディオ情報を含む。
【0022】
本発明の実施例によるマルチメディア・ファイルを符号化するシステムは、ビデオ・トラックを符号化し、複数のオーディオ・トラックを符号化し、ビデオ・トラックからの情報を複数のオーディオ・トラックからの情報と交互配置し、かつ、交互配置されたビデオおよびオーディオ情報を単一ファイルへと書き込むように構成されたプロセッサを含む。
【0023】
更なる実施例において、オーディオ・トラックの内の少なくとも1つのオーディオ・トラックは複数のオーディオチャネルを含む。
【0024】
別実施例においてプロセッサは更に、符号化オーディオ・トラックの数を特定するヘッダ情報を符号化し、かつ、そのヘッダ情報を単一ファイルに書き込みむように構成される。
【0025】
再び更なる実施例において、プロセッサは更に、符号化オーディオ・トラック内の少なくとも1つの符号化オーディオ・トラックに関する説明情報を特定するヘッダ情報を符号化し、かつ、そのヘッダ情報を単一ファイルに書き込むべく構成される。
【0026】
再び別実施例において、プロセッサはビデオ・トラックをビデオ情報のチャンクとして符号化する。これに加え、プロセッサは各オーディオ・トラックをオーディオ情報の一連のチャンクとして符号化し得る。更に、オーディオ情報の各チャンクは単一のオーディオ・トラックからのオーディオ情報を含み得ると共に、プロセッサは、ビデオ情報のチャンク間にオーディオ情報のチャンクを交互配置するように構成され得る。
【0027】
更なる実施例において、プロセッサは、「ビデオ」チャンクにおけるビデオ情報に付随する各オーディオ・トラックの部分を「オーディオ」チャンク内に符号化すべく構成され、かつ、プロセッサは、各「ビデオ」チャンクが、その「ビデオ」チャンクに含まれたビデオ情報に付随するオーディオ・トラックの各々からのオーディオ情報を含む「オーディオ」チャンクにより発生するように、「ビデオ」チャンクおよび「オーディオ」チャンクを交互配置すべく構成される。これに加え、プロセッサは、各ビデオ・チャンク内にビデオの単一フレームが含まれるようにビデオ・トラックを符号化すべく構成され得る。
【0028】
再び更に別の実施例において、プロセッサは汎用プロセッサである。
【0029】
付加的な更なる実施例において、プロセッサは専用回路である。
【0030】
本発明による複数のオーディオ・トラックを含むマルチメディア・ファイルを復号化するシステムは、マルチメディア・ファイルから情報を抽出すべく構成されたプロセッサを含む。プロセッサは、マルチメディア・ファイル内に含まれたオーディオ・トラックの個数に関する情報を抽出すべく構成される。
【0031】
更なる実施例において、プロセッサは、複数のオーディオ・トラックから単一のオーディオ・トラックを選択すべく構成され、かつ、プロセッサは、選択されたオーディオ・トラックからのオーディオ情報を復号化すべく構成される。
【0032】
別実施例において、オーディオ・トラックの内の少なくとも一つのオーディオ・トラックは複数のオーディオチャネルを含む。
【0033】
更なる実施例において、プロセッサは、マルチメディア・ファイルにおけるヘッダからの情報であってオーディオ・トラックの内の少なくとも一つのオーディオ・トラックに関する説明情報を含む情報を抽出すべく構成される。
【0034】
本発明の実施例によるマルチメディア情報を通信するシステムは、ネットワークと、マルチメディア・ファイルを含むと共に、サーバを介してネットワークに対して接続された記憶デバイスと、ネットワークに接続されたクライアントとを含む。クライアントは、サーバからのマルチメディア・ファイルの転送を要求することができ、かつ、マルチメディア・ファイルは、少なくとも一つのビデオ・トラックと、そのビデオ・トラックに付随する複数のオーディオ・トラックとを含む。
【0035】
本発明によるマルチメディア・ファイルは、一連の符号化ビデオ・フレームと、符号化ビデオ・フレーム間に交互配置された少なくとも一つの符号化サブタイトルトラックとを含む。
【0036】
更なる実施例において、少なくとも一つの符号化サブタイトルトラックは複数の符号化サブタイトルトラックから成る。
【0037】
別な実施例は更に、マルチメディア・ファイルに含まれた符号化サブタイトルトラックの個数を特定するヘッダ情報を更に含む。
【0038】
更なる実施例もまた、符号化サブタイトルトラックの内の少なくとも一つの符号化サブタイトルトラックに関する説明情報を含むヘッダ情報を含む。
【0039】
更なる別実施例において、各サブタイトルトラックは一連のビットマップを含み、かつ、各サブタイトルトラックは一連の圧縮ビットマップを含み得る。これに加え、各ビットマップはランレングス符号化方法を用いて圧縮される。
【0040】
更なる実施例において、一連の符号化ビデオ・フレームは一連のビデオ・チャンクとして符号化され、かつ、各符号化サブタイトルトラックは一連のサブタイトル・チャンクとして符号化される。各サブタイトル・チャンクは、表示上にテキストとして表され得る情報を含む。これに加え、各サブタイトル・チャンクは単一のサブタイトルに関する情報を含み得る。更に、各サブタイトル・チャンクは、サブタイトルがスーパーインポーズ(superimpose)されるべきビデオ・シーケンスの部分に関する情報を含み得る。
【0041】
更に別の実施例において、各サブタイトル・チャンクは、サブタイトルが配置されるべき表示の部分に関する情報を含む。
【0042】
再び更なる実施例において、各サブタイトル・チャンクは、サブタイトルの色に関する情報を含み、かつ、色に関する情報は色パレート(palate)を含み得る。これに加え、サブタイトル・チャンクは、第1色パレートに関する情報を含む第1サブタイトル・チャンクと、第1色パレートに関する情報に成り代わる第2色パレートに関する情報を含む第2サブタイトル・チャンクとを備え得る。
【0043】
本発明の実施例によるマルチメディア・ファイルを符号化するシステムは、ビデオ・トラックを符号化し、少なくとも一つのサブタイトルトラックを符号化し、ビデオ・トラックからの情報を、少なくとも一つのサブタイトルトラックからの情報と交互配置し、かつ、交互配置されたビデオおよびサブタイトル情報を単一ファイルに書き込むように構成されたプロセッサを含み得る。
【0044】
更なる実施例において、少なくとも一つのサブタイトルトラックは複数のサブタイトルトラックを含む。
【0045】
別実施例において、プロセッサは更に、マルチメディア・ファイルに含まれたサブタイトルトラックの個数を特定するヘッダ情報を符号化して単一ファイルに書き込むべく構成される。
【0046】
再び更なる実施例において、プロセッサは更に、サブタイトルトラックの内の少なくとも一つのサブタイトルトラックに関する説明情報を符号化して単一ファイルに書き込むべく構成される。
【0047】
別の更なる実施例において、ビデオ・トラックはビデオ・チャンクとして符号化され、かつ、少なくとも一つのサブタイトルトラックの各々はサブタイトル・チャンクとして符号化される。これに加え、サブタイトル・チャンクの各々は、ビデオ・トラックの一部に付随する単一のサブタイトルを含み得ると共に、インタリーバ(interleaver)は、ビデオ・トラックの部分であってサブタイトル・チャンク内のサブタイトルが付随する部分を含むビデオ・チャンクの前に、各サブタイトル・チャンクを交互配置すべく構成され得る。
【0048】
更なる実施例において、プロセッサは、サブタイトルをビットマップとして符号化することによりサブタイトル・チャンクを生成すべく構成される。
【0049】
更なる別実施例において、サブタイトルは圧縮ビットマップとして符号化される。これに加え、ビットマップはランレングス符号化方法を用いて圧縮され得る。更に、プロセッサは各サブタイトル・チャンク内に、サブタイトルがスーパーインポーズされるべきビデオ・シーケンスの部分に関する情報を含み得る。
【0050】
更なる実施例において、プロセッサは各サブタイトル・チャンク内に、サブタイトルが配置されるべき表示の部分に関する情報を含む。
【0051】
更に別の実施例において、プロセッサは各サブタイトル・チャンク内に、サブタイトルの色に関する情報を含む。
【0052】
更なる実施例において、色に関する情報は色パレートを含む。これに加え、サブタイトル・チャンクは、第1色パレートに関する情報を含む第1サブタイトル・チャンクと、第1色パレートに関する情報に成り代わる第2色パレートに関する情報を含む第2サブタイトル・チャンクとを含み得る。
【0053】
本発明の実施例によるマルチメディア・ファイルは、マルチメディア・ファイルから情報を抽出すべく構成されたプロセッサを含む。プロセッサは、マルチメディア・ファイルを検査して、少なくとも一つのサブタイトルトラックが在るか否かを決定すべく構成される。これに加え、少なくとも一つのサブタイトルトラックは、複数のサブタイトルトラックを備え得ると共に、プロセッサはマルチメディア・ファイル内におけるサブタイトルトラックの数を決定すべく構成され得る。
【0054】
更なる実施例において、プロセッサは更に、サブタイトルトラックの数を特定するヘッダ情報を、マルチメディア・ファイルから抽出すべく構成される。
【0055】
別な実施例において、プロセッサは更に、サブタイトルトラックの内の少なくとも一つのサブタイトルトラックに関する説明情報をマルチメディア・ファイルから抽出すべく構成される。
【0056】
再び更なる実施例において、マルチメディア・ファイルは、ビデオ・チャンクとして符号化された少なくとも一つのビデオ・トラックを含み、かつ、マルチメディア・ファイルは、サブタイトル・チャンクとして符号化された少なくとも一つのサブタイトルトラックを含む。
【0057】
再び別実施例において、各サブタイトル・チャンクは単一のサブタイトルに関する情報を含む。
【0058】
更なる実施例において、各サブタイトルはサブタイトル・チャンク内においてビットマップとして符号化され、プロセッサは、ビデオ・トラックを復号化すべく構成され、かつ、プロセッサは、ビットマップをビデオ・シーケンスの一部上にスーパーインポーズすることにより、表示のためのビデオのフレームを構築すべく構成される。これに加え、サブタイトルは圧縮ビットマップとして符号化され得ると共に、プロセッサはビットマップを解凍すべく構成され得る。更に、プロセッサは、ランレングス符号化されたビットマップを解凍すべく構成され得る。
【0059】
更なる別実施例において、各サブタイトル・チャンクは、サブタイトルがスーパーインポーズされるべきビデオ・トラックの部分に関する情報を含み、かつ、プロセッサは、サブタイトル・チャンクにおける情報により表された各ビデオ・フレーム上にサブタイトルのビットマップをスーパーインポーズすることにより、表示のための一連のビデオ・フレームを生成すべく構成される。
【0060】
付加的な更なる実施例において、各サブタイトル・チャンクは、サブタイトルが配置されるべきフレーム内の位置に関する情報を含み、かつ、プロセッサは、サブタイトル・チャンク内の情報により表された各ビデオ・フレーム内の位置にサブタイトルをスーパーインポーズすべく構成される。
【0061】
別の付加的な実施例において、各サブタイトル・チャンクは、サブタイトルの色に関する情報を含み、かつ、プロセッサは、サブタイトル・チャンク内の色情報により表される単一もしくは複数の色でサブタイトルをスーパーインポーズすべく構成される。これに加え、サブタイトル・チャンク内における色情報は色パレートを含み得ると共に、プロセッサは、色パレートを用いてサブタイトルのビットマップにおいて使用される色情報を獲得して、サブタイトルをスーパーインポーズすべく構成される。更に、サブタイトル・チャンクは、第1色パレートに関する情報を含む第1サブタイトル・チャンクと、第2色パレートに関する情報を含む第2サブタイトル・チャンクとを備え得ると共に、プロセッサは、第1色パレートを用いて、第1チャンクが処理された後にサブタイトルのビットマップにおいて使用される色に関する情報を獲得して、サブタイトルをスーパーインポーズすべく構成されることが可能であり、かつ、プロセッサは、第2色パレートを用いて、第2チャンクが処理された後にサブタイトルのビットマップにおいて使用される色に関する情報を獲得して、サブタイトルをスーパーインポーズすべく構成され得る。
【0062】
本発明の実施例によるマルチメディア情報を通信するシステムは、ネットワークと、マルチメディア・ファイルを含むと共に、サーバを介してネットワークに対して接続された記憶デバイスと、ネットワークに接続されたクライアントとを含む。クライアントは、サーバからのマルチメディア・ファイルの転送を要求し、かつ、マルチメディア・ファイルは、少なくとも一つのビデオ・トラックと、そのビデオ・トラックに付随する少なくとも一つのサブタイトルトラックとを含む。
【0063】
本発明の実施例によるマルチメディア・ファイルは、一連の符号化ビデオ・フレームと、符号化されたメニュー情報とを含む。これに加え、符号化されたメニュー情報はチャンクとして記憶され得る。
【0064】
更なる実施例は少なくとも2つの別個のメニュー情報の「menu(メニュー)」チャンクも含み、かつ、少なくとも2つの別個の「menu」チャンクは少なくとも2つの別個の「RIFF」チャンクに含まれ得る。
【0065】
別実施例において、「menu」チャンクを含む第1「RIFF」チャンクは標準的な4ccコードを含むと共に、「menu」チャンクを含む第2「RIFF」チャンクは特殊な4ccコードを含み、標準的な4ccコードの最初の2個のキャラクタは特殊化4ccコードの最後の2個のキャラクタとして現れる。
【0066】
再び更なる実施例において、単一の「RIFF」チャンク内には少なくとも2つの別個の「menu」チャンクが含まれる。
【0067】
再び別実施例において、「menu」チャンクは、一連のメニューを記述するチャンクと、一連のメニューに関係付けられたメディアを含む「MRIF」チャンクとを含む。これに加え、「MRIF」チャンクは、ビデオ・トラック、オーディオ・トラックおよびオーバレイトラックを含むメディア情報を含み得る。
【0068】
更なる実施例において、一連のメニューを記述するチャンクは、メニュー・システム全体を記述するチャンクと、各メニューを言語によりグループ化する少なくとも一つのチャンクと、個々のメニュー表示と、付随するバックグラウンド・オーディオとを記述する少なくとも一つのチャンクと、メニュー上のボタンを記述する少なくとも一つのチャンクと、画面上におけるボタンの箇所を記述する少なくとも一つのチャンクと、ボタンに関係付けられた種々の動作を記述する少なくとも一つのチャンクとを含み得る。
【0069】
更なる別実施例は、第2ファイルに対するリンクも含む。符号化されたメニュー情報は第2ファイル内に含まれる。
【0070】
本発明の実施例によるマルチメディア・ファイルを符号化するシステムは、メニュー情報を符号化すべく構成されたプロセッサを含む。そのプロセッサはまた、符号化ビデオ・トラックおよび符号化されたメニュー情報を含むマルチメディア・ファイルを生成するようにも構成される。これに加え、プロセッサは、メニューのオブジェクト・モデルを生成し、オブジェクト・モデルを設定ファイルへと変換し、設定ファイルを解析してチャンクとし、メディア情報を含むAVIファイルを生成し、AVIファイル内のメディアを「MRIF」チャンク内へと交互配置し、かつ、解析されたチャンクを「MRIF」チャンクと連結して「menu」チャンクを生成するように構成され得る。また、プロセッサは更に、オブジェクト・モデルを使用して第2の更に小さな「menu」チャンクを生成すべく構成され得る。
【0071】
更なる実施例において、プロセッサは第2メニューを符号化すべく構成され、かつ、プロセッサは、第1の符号化メニューを第1「RIFF」チャンクに挿入しかつ第2の符号化メニューを第2「RIFF」チャンクに挿入し得る。
【0072】
別実施例において、プロセッサは第1および第2の符号化メニューを単一の「RIFF」チャンク内に含む。
【0073】
再び更なる実施例において、プロセッサは、マルチメディア・ファイル内に、第2ファイルにおける符号化メニューに対するリファレンスを挿入すべく構成される。
【0074】
本発明によるマルチメディア・ファイルを復号化するシステムは、マルチメディア・ファイルから情報を抽出すべく構成されたプロセッサを含む。プロセッサは、マルチメディア・ファイルを検査して、それが符号化されたメニュー情報を含むか否かを決定すべく構成される。これに加え、プロセッサは、「RIFF」チャンク内の「menu」チャンクからメニュー情報を抽出すべく構成され得ると共に、プロセッサは、「menu」チャンクに記憶されたビデオ情報を用いてメニュー表示を構築すべく構成され得る。
【0075】
更なる実施例において、プロセッサは、「menu」チャンクに記憶されたオーディオ情報を用い、メニュー表示に付随するバックグラウンド・オーディオを生成すべく構成される。
【0076】
別実施例において、プロセッサは、「menu」チャンクからのオーバレイを、その「menu」チャンクからのビデオ情報に重ね合わせることによりメニュー表示を生成すべく構成される。
【0077】
本発明によるマルチメディア情報を通信するシステムは、ネットワークと、マルチメディア・ファイルを含むと共に、サーバを介してネットワークに対して接続された記憶デバイスと、ネットワークに接続されたクライアントとを含む。クライアントは、サーバからのマルチメディア・ファイルの転送を要求することができ、かつ、マルチメディア・ファイルは符号化されたメニュー情報を含む。
【0078】
マルチメディア・ファイルは、一連の符号化ビデオ・フレームと、そのマルチメディア・ファイルに関する符号化メタデータとを含む。符号化メタデータは、主部(subject)、述部、目的部(object)および出典(authority)を備える少なくとも一つのステートメント(statement)を含む。主部は、メタデータにより記述されるファイル、項目、人物または組織を特定する情報を含むことができ、述部は主部の特性を表す情報を含むことができ、目的部は、述部により特定された主部の特性を記述する情報を含むことができ、かつ、出典はステートメントのソースに関する情報を含むことができる。
【0079】
更なる実施例において、主部はタイプおよび値を含むチャンクであり、値は情報を含み、かつ、タイプは、チャンクがリソースであるか匿名ノードであるかを表す。
【0080】
別実施例において、述部は、タイプおよび値を含むチャンクであり、値は情報を含み、かつ、タイプは、値情報が記述URIであるか順序リスト・エントリであるかを表す。
【0081】
再び更なる実施例において、目的部は、タイプ、言語、データタイプおよび値を含むチャンクであり、値は情報を含み、タイプは、値情報がUTF-8リテラル、リテラル整数またはリテラルXMLデータであるかを表し、データタイプは値情報のタイプを表し、かつ、言語は特定言語を指定する情報を含む。
【0082】
再び別実施例において、出典はタイプおよび値を含むチャンクであり、値は情報を含み、かつ、タイプは、値情報がステートメントの出典であることを表す。
【0083】
更なる実施例において、符号化データの少なくとも一部は2値データとして表される。
【0084】
更に別の実施例において、符号化データの少なくとも一部は64ビットASCIデータとして表される。
【0085】
更なる実施例において、符号化データの少なくとも第1部分は2値データとして表され、かつ、符号化データの少なくとも第2部分は第2フォーマットで表されたデータを含む付加的チャンクとして表される。これに加え、付加的チャンクは各々、単一のメタデータを含み得る。
【0086】
本発明の実施例によるマルチメディア・ファイルを符号化するシステムは、ビデオ・トラックを符号化すべく構成されたプロセッサを含む。プロセッサは、マルチメディア・ファイルに関するメタデータを符号化する様にも構成され、かつ、符号化メタデータは、主部、述部、目的部および出典を備える少なくとも一つのステートメントを含む。これに加え、主部は、メタデータにより記述されるファイル、項目、人物または組織を特定する情報を含むことができ、述部は主部の特性を表す情報を含むことができ、目的部は、述部により特定された主部の特性を記述する情報を含むことができ、かつ、出典はステートメントのソースに関する情報を含むことができる。
【0087】
更なる実施例において、プロセッサは主部を、タイプおよび値を含むチャンクとして符号化すべく構成され、値は情報を含み、かつ、タイプは、チャンクがリソースであるか匿名ノードであるかを表す。
【0088】
別実施例において、プロセッサは述部を、タイプおよび値を含むチャンクとして符号化すべく構成され、値は情報を含み、かつ、タイプは、値情報が記述URIであるか順序リスト・エントリであるかを表す。
【0089】
再び更なる実施例において、プロセッサは目的部を、タイプ、言語、データタイプおよび値を含むチャンクとして符号化すべく構成され、値は情報を含み、タイプは、値情報がUTF-8リテラル、リテラル整数またはリテラルXMLデータであるかを表し、データタイプは値情報のタイプを表し、かつ、言語は特定言語を指定する情報を含む。
【0090】
再び別実施例において、プロセッサは出典を、タイプおよび値を含むチャンクとして符号化すべく構成され、値は情報を含み、かつ、タイプは、値情報がステートメントの出典であることを表す。
【0091】
更なる実施例において、プロセッサは更に、マルチメディア・ファイルに関するメタデータの少なくとも一部を2値データとして符号化すべく構成される。
【0092】
更なる別実施例において、プロセッサは更に、マルチメディア・ファイルに関するメタデータの少なくとも一部を64ビットASCIデータとして符号化すべく構成される。
【0093】
付加的な実施例において、プロセッサは更に、マルチメディア・ファイルに関するメタデータの少なくとも第1部分を2値データとして符号化し、かつ、マルチメディア・ファイルに関するメタデータの少なくとも第2部分を、第2フォーマットで表されたデータを含む付加的チャンクとして符号化するように構成される。これに加え、プロセッサは更に、付加的チャンクを単一のメタデータを以て符号化すべく構成され得る。
【0094】
本発明によるマルチメディア・ファイルを復号化するシステムは、マルチメディア・ファイルから情報を抽出すべく構成されたプロセッサを含む。プロセッサは、マルチメディア・ファイルに関するメタデータ情報を抽出すべく構成され、かつ、メタデータ情報は、主部、述部、目的部および出典を備える少なくとも一つのステートメントを含む。これに加え、プロセッサは主部から、メタデータにより記述されるファイル、アイテム、人物または組織を特定する情報を抽出すべく構成され得る。更に、プロセッサは、述部から主部の特性を表す情報を抽出すべく構成されることができ、プロセッサは目的部から、述部により特定される主部の特性を記述する情報を抽出すべく構成されることができ、かつ、プロセッサは、出典からステートメントのソースに関する情報を抽出すべく構成されることができる。
【0095】
更なる実施例において、主部はタイプおよび値を含むチャンクであり、プロセッサは、タイプを検査することにより、チャンクは主部情報を含むことを特定すべく構成され、かつ、プロセッサは、値から情報を抽出すべく構成される。
【0096】
別実施例において、述部は、タイプおよび値を含むチャンクであり、プロセッサは、タイプを検査することにより、チャンクは述部情報を含むことを特定すべく構成され、かつ、プロセッサは、値から情報を抽出すべく構成される。
【0097】
再び更なる実施例において、目的部は、タイプ、言語、データタイプおよび値を含むチャンクであり、プロセッサは、タイプを検査することにより、チャンクは目的部情報を含むことを特定すべく構成され、プロセッサは、データタイプを検査することで、値に含まれる情報のデータタイプを決定すべく構成され、プロセッサは、データタイプにより表されるタイプの情報を値から抽出すべく構成され、かつ、プロセッサは、特定言語を指定する情報を値から抽出すべく構成される。
【0098】
再び別実施例において、出典はタイプおよび値を含むチャンクであり、プロセッサは、タイプを検査することにより、チャンクは出典情報を含むことを特定すべく構成され、かつ、プロセッサは、値から情報を抽出すべく構成される。
【0099】
更なる実施例において、プロセッサは、メタデータ・ステートメントから情報を抽出してその情報の少なくとも一部を表示すべく構成される。
【0100】
更なる別実施例において、プロセッサは、メタデータを用い、メモリ内にラベル付き有向グラフを表すデータ構造を構築すべく構成される。
【0101】
更なる実施例において、プロセッサは、複数のステートメントに対して主部、述部、目的部および出典の内の少なくとも一つを検査することにより、メタデータを介して情報を検索するように構成される。
【0102】
更に別の実施例において、プロセッサは、検索の結果を、グラフィカル・ユーザ・インタフェースの一部として表示すべく構成される。これに加え、プロセッサは、外部デバイスからの要求に応じて検索を実施すべく構成され得る。
【0103】
付加的な更なる実施例において、マルチメディア・ファイルに関するメタデータ情報の少なくとも一部は2値データとして表される。
【0104】
別の付加的な実施例において、マルチメディア・ファイルに関するメタデータ情報の少なくとも一部は64ビットASCIデータとして表される。
【0105】
別の更なる実施例において、マルチメディア・ファイルに関するメタデータ情報の少なくとも第1部分は2値データとして表され、かつ、マルチメディア・ファイルに関するメタデータ情報の少なくとも第2部分は第2フォーマットで表されたデータを含む付加的チャンクとして表される。これに加え、付加的チャンクは単一のメタデータを含み得る。
【0106】
本発明によるマルチメディア情報を通信するシステムは、ネットワークと、マルチメディア・ファイルを含むと共に、サーバを介してネットワークに対して接続された記憶デバイスと、ネットワークに接続されたクライアントとを含む。クライアントは、サーバからのマルチメディア・ファイルの転送を要求することができ、マルチメディア・ファイルはそのマルチメディア・ファイルに関するメタデータを含み、かつ、メタデータは、主部、述部、目的部および出典を備える少なくとも一つのステートメントを含む。
【0107】
本発明によるマルチメディア・ファイルは、少なくとも一つの符号化ビデオ・トラックと、少なくとも一つの符号化オーディオ・トラックと、複数の符号化テキスト文字列とを含む。符号化テキスト文字列は、少なくとも一つのビデオ・トラックおよび少なくとも一つのオーディオ・トラックの特性を記述する。
【0108】
更なる実施例において、複数のテキスト文字列は、異なる言語を用い、ビデオ・トラックまたはオーディオ・トラックと同一の特性を記述する。
【0109】
別実施例は、少なくとも一つの符号化サブタイトルトラックも含む。複数の符号化テキスト文字列はサブタイトルトラックの特性を記述する文字列を含む。
【0110】
本発明によるマルチメディア・ファイルを生成するシステムは、少なくとも一つのビデオ・トラックを符号化し、少なくとも一つのオーディオ・トラックを符号化し、符号化オーディオ・トラックの内の少なくとも一つの符号化オーディオ・トラックをビデオ・トラックと交互配置し、少なくとも一つのビデオ・トラックおよび少なくとも一つのオーディオ・トラックの所定数の特性の各々を複数の言語で記述するテキスト文字列を挿入するように構成されたプロセッサを含む。
本発明による符号化オーディオ、ビデオおよびテキスト文字列を含むマルチメディア・ファイルを表示するシステムは、マルチメディア・ファイルから符号化テキスト文字列を抽出し、かつ、テキスト文字列を用いてプルダウン・メニュー表示を生成するように構成されたプロセッサを含む。
【図面の簡単な説明】
【0111】
【図1.】本発明の実施例によるファイルを符号化、配信および復号化するシステムの図である。
【図2.0.】本発明の実施例によるマルチメディア・ファイルの構造の図である。
【図2.0.1】本発明の別な実施例によるマルチメディア・ファイルの構造の図である。
【図2.1.】本発明の一実施例による「hdrl」リスト・チャンクの概略図である。
【図2.2.】本発明の実施例による「strl」チャンクの概略図である。
【図2.3.】本発明の実施例によるマルチメディア・ファイルの「DXDT」チャンクを記憶すべく割当てられたメモリの概略図である。
【図2.3.1.】本発明の実施例によるマルチメディア・ファイルの「DXDT」チャンク内に含まれ得る「メタデータ」チャンクの概略図である。
【図2.4.】本発明の実施例による「DMNU」チャンクの概略図である。
【図2.5.】本発明の実施例による「WowMenuManager」チャンクに含まれたメニュー・チャンクの概略図である。
【図2.6.】本発明の別な実施例による「WowMenuManager」チャンク内に含まれたメニュー・チャンクの概略図である。
【図2.6.1.】本発明の実施例による「DMNU」チャンク内に含まれた種々のチャンク間の関係を示す概略図である。
【図2.7.】本発明の実施例によるマルチメディア・ファイルの「movi」リスト・チャンクの概略図である。
【図2.8.】DRMを含む本発明の実施例によるマルチメディア・ファイルの「movi」リスト・チャンクの概念的概略図である。
【図2.9.】本発明の実施例による「DRM」チャンクの概略図である。
【図3.0.】本発明の実施例によるマルチメディア・ファイルを生成するシステムのブロック図である。
【図3.1.】本発明の実施例による「DXDT」チャンクを生成するシステムのブロック図である。
【図3.2.】本発明の実施例による「DMNU」チャンクを生成するシステムのブロック図である。
【図3.3.】本発明の実施例によるメディア・モデルの概略図である。
【図3.3.1.】本発明の実施例によるスモール・メニューを自動的に生成すべく使用され得るメディア・モデルからのオブジェクトの概略図である。
【図3.4.】本発明の実施例によるオーディオを再チャンクすべく使用され得る処理のフローチャートである。
【図3.5.】本発明の実施例によるビデオ・エンコーダのブロック図である。
【図3.6.】本発明の実施例によるIフレーム上で円滑な心理視覚的強化を実施する方法のフローチャートである。
【図3.7.】本発明の実施例によるマクロブロックSADの心理視覚的強化を実施する処理のフローチャートである。
【図3.8.】本発明の実施例によるワンパス速度制御のための処理のフローチャートである。
【図3.9.】本発明の実施例による第NパスVBV速度制御を実施する処理のフローチャートである。
【図4.0.】本発明の実施例によるマルチメディア・ファイルから必要なマルチメディア情報を検索し、そのマルチメディア情報を表示する処理のフローチャートである。
【図4.1.】本発明の実施例によるデコーダのブロック図である。
【図4.2.】本発明の実施例による表示されたメニューの例を示す図である。
【図4.3.】本発明の実施例による図4.2.に示された表示を生成すべく使用される情報のソースを示す概略図である。
【発明を実施するための形態】
【0112】
図面を参照する本発明の実施例は、マルチメディア・ファイルを符号化、送信および復号化することができる。本発明の実施例によるマルチメディア・ファイルは、複数のビデオ・トラックと、複数のオーディオ・トラックと、複数のサブタイトルトラックと、ファイルの内容にアクセスするメニュー・インタフェースを生成すべく使用され得るデータと、ファイルの内容に関する「メタデータ」とを含み得る。本発明の幾つかの実施例によるマルチメディア・ファイルは、ビデオ・トラック、オーディオ・トラック、サブタイトルトラック、およびファイル外部の「meta data」へのリファレンスも含む。
【実施例】
【0113】
1.システムの説明
次に図1を参照すると、ファイルを符号化、配信および復号化する本発明の実施例によるシステムが示される。システム10は、ネットワーク14を介して他の種々の演算デバイスに対して接続されるコンピュータ12を含む。ネットワークに接続され得るデバイスとしては、サーバ16、ラップトップ・コンピュータ18およびパーソナル・デジタル・アシスタント(PDA)20が挙げられる。種々の実施例においてデバイスとネットワークとの間の接続は、有線もしくは無線でされると共に、種々のネットワーク用プロトコル内の任意のプロトコルを用いて実施され得る。
【0114】
作動時にコンピュータ12は、本発明の実施例によるマルチメディア・ファイルを符号化すべく使用され得る。コンピュータ12はまた、本発明の実施例によるマルチメディア・ファイルを復号化すると共に本発明の実施例によるマルチメディア・ファイルを配信するためにも使用され得る。コンピュータは、ピアツーピア・ネットワークを介するなどの種々のファイル転送プロトコルの内の任意のプロトコルを用いてファイルを配信し得る。
これに加えてコンピュータ12は、本発明の実施例によるマルチメディア・ファイルをラップトップ・コンピュータ18へと転送でき、そこでファイルは他のデバイスによりアクセスされ得る。その他のデバイスとしては、任意の種々の演算デバイス、または、専用のデコーダ・デバイスも含まれる。図示の実施例においては、ラップトップ・コンピュータおよびPDAが示される。他の実施例においては、デジタル・セットトップボックス、デスクトップ・コンピュータ、ゲーム機、家電機器および他のデバイスがネットワークに接続され、マルチメディア・ファイルをダウンロードしてそれを復号化し得る。
【0115】
一実施例において、デバイスはサーバからネットワークを介してマルチメディア・ファイルにアクセスする。他の実施例において、デバイスは、多数のコンピュータからピアツーピア・ネットワークを介してマルチメディア・ファイルにアクセスする。幾つかの実施例においてマルチメディア・ファイルは、ディスク・ドライブ、CD−ROMまたはDVDなどの可搬的記憶デバイスに対して書き込まれ得る。多くの実施例において、電子的デバイスは可搬的記憶デバイスに書き込まれたマルチメディア・ファイルにアクセスし得る。
【0116】
2.ファイル構造の説明
本発明の実施例によるマルチメディア・ファイルは、ワシントン州、レドモンド市のMicrosoft社およびニューヨーク州、アーモンク市のIBM(International Business Machines)社により策定されたリソース交換ファイル・フォーマット(「RIFFファイル・フォーマット」)に準拠すべく構造化され得る。RIFFは、マルチメディア・データおよび関連情報を記憶するためのファイル・フォーマットである。RIFFファイルは典型的に、ファイルを特定する8バイトのRIFFヘッダであり、RIFFヘッダは、そのファイルを識別し、かつ、そのヘッダの後におけるファイルの残存長(すなわちファイル長−8)を提供する。RIFFファイルの残りの全ては、“チャンク(chunk)”および“リスト(list)”から成る。各チャンクは、チャンクのタイプを特定する8バイトのチャンク・ヘッダを有し、そのチャック・ヘッダは、そのチャンク・ヘッダに続くデータの長さをバイト単位で与える。各リストは、8バイトのリスト・ヘッダを有し、そのリスト・ヘッダは、そのリスト・ヘッダに続くデータの長さをバイト単位で与える。リストにおけるデータは、チャンクおよび/または他のリスト(これは更にチャンクおよび/または他のリストを備え得る)を備える。RIFFリストは、一定の場合には“リスト・チャンク”とも称される。
【0117】
AVIファイルはRIFFファイルの特定形態であり、RIFFファイルのフォーマットに追随するが、特定フォーマットにおけるマルチメディア・データを含む定義済み識別子を備えた種々のチャンクおよびリストを含んでいる。AVIフォーマットは、Microsoft社により開発かつ規定された。AVIファイルは典型的に、AVIフォーマットでマルチメディア・データを出力し得るエンコーダを用いて生成される。AVIファイルは典型的に、集合的にAVIデコーダとして知られた一群のソフトウェア内の任意のソフトウェアにより復号化される。
【0118】
RIFFおよびAVIフォーマットは、規定されたファイル・フォーマットの一部であるチャンクおよびリストを規定するだけでなく、そのファイルが、RIFFおよび/またはAVIデコーダによるそのファイルを読取不能とせずにRIFFおよび/またはAVIファイル・フォーマット定義外のリストおよび/またはチャンクを含むことも許容する点において、融通性が高い。実際問題としてAVI(および同様のRIFF)デコーダは、AVIファイル・フォーマット定義に見出されないヘッダ情報を含むリストおよびチャンクを単に無視する様に実現される。AVIデコーダは、それでもこれらの非AVIチャンクおよびリストを読み取らなければならい場合、AVIデコーダの動作は遅くなるが、その他の場合は、一般に、それらはAVIデコーダに対して効果を有さずにAVIデコーダにより無視される。
【0119】
図2.0.には、本発明の実施例によるマルチメディア・ファイルが示される。図示されたマルチメディア・ファイル30は、キャラクタ・セット・チャンク(「CSET」チャンク)32、情報リスト・チャンク(「INFO」リスト・チャンク)34、ファイル・ヘッダ・チャンク(「hdrl」リスト・チャンク)36、メタデータ・チャンク(「DXDT」チャンク)38、メニュー・チャンク(「DMNU」チャンク)40、ジャンク・チャンク(「junk」チャンク)41、ムービー・リスト・チャンク(「movi」リスト・チャンク)42、選択的インデックス・チャンク(「idxl」チャンク)44および第2メニュー・チャンク(「DMNU」チャンク)46を含む。これらのチャンクの一定部分および他のチャンクの一部はAVIファイル・フォーマットにおいて規定されるが、その他のチャンクはAVIファイル・フォーマットには含まれない。全ての場合ではないが多くの場合に以下の考察は、AVIファイル・フォーマットの一部として規定されたチャンクまたはチャンク部分を特定する。
【0120】
図2.0.1.には、本発明の実施例による別のマルチメディア・ファイルが示される。マルチメディア・ファイル30’は、そのファイルが複数の連結「RIFF」チャンクを含むことを除き、図2.0.に示されたファイルと同様である。その「RIFF」チャンクは、図2.0.に示された「RIFF」チャンクであって第2「DMNU」チャンク46を除外し得るか又は「DMNU」チャンク46’の形態のメニュー情報を含み得る「RIFF」チャンクを含み得る。
【0121】
図示の実施例においてマルチメディアは、複数の連結「RIFF」チャンクを含み、その場合に第1「RIFF」チャンク50は、キャラクタ・セット・チャンク(「CSET」チャンク)32’、情報リスト・チャンク(「INFO」リスト・チャンク)34’、ファイル・ヘッダ・チャンク(「hdrl」リスト・チャンク)36’、メタデータ・チャンク(「DXDT」チャンク)38’、メニュー・チャンク(「DMNU」チャンク)40’、ジャンク・チャンク(「junk」チャンク)41’、ムービー・リスト・チャンク(「movi」リスト・チャンク)42’および選択的インデックス・チャンク(「idxl」チャンク)44’を含む。第2「RIFF」チャンク52は、第2メニュー・チャンク(「DMNU」チャンク)46’を含む。「RIFF」メニュー・チャンク52の後には、付加的「RIFF」チャンク54が含まれ得る。付加的「RIFF」チャンクは、AVIファイル・フォーマットに準拠する独立メディアを含み得る。一実施例において第2メニュー・チャンク46’および付加的「RIFF」チャンクは、その4個のキャラクタ・コードの第1の2個のキャラクタは、第2の2個のキャラクタとして現れ、かつ、その4個のキャラクタ・コードの第2の2個のキャラクタは第1の2個のキャラクタとして現れるように、(AVIフォーマットで規定されると共に以下で論じられる)特殊な4個のキャラクタ・コードを有する。
【0122】
2.1.「CSET」チャンク
「CSET」チャンク32は、Microsoft社により策定されたオーディオ・ビデオ・インターリーブ・ファイル・フォーマット(AVIファイル・フォーマット)において規定されたチャンクである。「CSET」チャンクは、マルチメディア・ファイルのキャラクタ・セットおよび言語情報を規定する。本発明の実施例による「CSET」チャンクを包含することはオプション的である。
【0123】
本発明の一実施例によるマルチメディア・ファイルは、「CSET」チャンクを使用せずに、言語情報に対してインターネット・エンジニアリング・タスク・フォースにより規定されたRFC 3066言語仕様と組み合わされた既定によるキャラクタ・セットに対して、ユニコード・コンソーシアムにより規定されたUTF-8を使用する。
【0124】
2.2.「INFO」リスト・チャンク
「INFO」リスト・チャンク34は、マルチメディア・ファイルの内容の識別を助力する情報を記憶し得る。「INFO」リストはAVIファイル・フォーマットにおいて規定されると共に、本発明の実施例によるマルチメディア・ファイルにそれを含めることは選択的である。「DXDT」チャンクを含む多くの実施例は、「INFO」リスト・チャンクを含まない。
【0125】
2.3.「hdrl」リスト・チャンク
「hdrl」リスト・チャンク38は、AVIファイル・フォーマットに規定されると共に、マルチメディア・ファイルにおけるデータのフォーマットに関する情報を提供する。「hdrl」リスト・チャンク、または、同様の記述情報を含むチャンクは、概略的に必要とされる。「hdrl」リスト・チャンクは、各ビデオ・トラック、各オーディオ・トラックおよび各サブタイトルトラックに対するチャンクを含む。
【0126】
図2.1.には、1つのビデオトラック62、2つのオーディオ・トラック64、外部のオーディオトラック66、2つのサブタイトルトラック68および外部のサブタイトルトラック70を含む本発明の一実施例による「hdrl」リストチャンク38が示される。「hdrl」リスト60は、「avih」チャンクを含む。「avih」チャンク60は、ファイル内におけるストリームの本数、マルチメディア・ファイル内に含まれたビデオの幅および高さなどのファイル全体に対する包括的情報を含む。その「avih」チャンクは、AVIファイル・フォーマットに従い実現され得る。
【0127】
「avih」チャンクに加え、「hdrl」リストは各オーディオ、ビデオおよびサブタイトルトラックに対するストリーム記述子リストを含む。一実施例においてそのストリーム記述子リストは、「strl」チャンクを用いて実現される。図2.2.には、本発明の実施例による「strl」チャンクが示される。各「strl」チャンクは、マルチメディア・ファイルにおける各トラックを記述する役割を果たす。マルチメディア・ファイル内におけるオーディオ、ビデオおよびサブタイトルトラックに対する「strl」チャンクは、「strh」チャンク92、「strf」チャンク94、「strd」チャンク96および「strn」チャンク98を参照する「strl」チャンクを含む。これらのチャンクの全ては、AVIファイル・フォーマットに従い実現され得る。特に興味があるのは、メディア・トラックのタイプを特定する「strh」チャンク92、および、ビデオがデジタル著作権管理により保護されているか否かを表すべく改変され得る「strd」チャンク96である。本発明の実施例によるデジタル著作権管理の種々の実施方式の考察は、以下に提供される。
【0128】
本発明の実施例によるマルチメディア・ファイルは、付加的オーディオ・トラックまたは付加的サブタイトルトラックなどのマルチメディア情報を保持する外部ファイルに対するリファレンスを含み得る。これらのトラックに対するリファレンスは、「hdrl」チャンクまたは「junk」チャンク41のいずれかに含まれ得る。いずれの場合でもリファレンスは、ローカル・ファイルまたはリモートで記憶されたファイルのいずれかを参照する「strl」チャンク90の「strh」チャンク92内に含まれ得る。参照されるファイルは、標準的なAVIファイル、または、付加的トラックを含む本発明の実施例によるマルチメディア・ファイルであり得る。
【0129】
付加的な実施例において、参照されるファイルは、参照を行うファイル内に存在し得るチャンクであって、「DMNU」チャンク、「DXDT」チャンク、および、マルチメディア・プレゼンテーションに対してオーディオ、ビデオおよび/またはサブタイトルトラックと関係付けられたチャンクの内の任意のものを含み得る。たとえば第1マルチメディア・ファイルは、その第1マルチメディア・ファイルの「movi」リスト・チャンク内に配置された第1マルチメディア・プレゼンテーションと、第2マルチメディア・ファイルの「movi」リスト・チャンク内の第2マルチメディア・プレゼンテーションとを参照する(以下において更に詳細に論じられる)「DMNU」チャンクを含み得る。代替的に、両方の「movi」リスト・チャンクは同一のマルチメディア・ファイル内に含まれ得るが、これは、「DMNU」チャンクが配置されるファイルと同一のファイルである必要はない。
【0130】
2.4.「DXDT」チャンク
「DXDT」チャンク38は、いわゆる「メタデータ」を含む。本発明の実施例によるマルチメディア・ファイルの「DXDT」チャンク内に記憶された「meta data」は、タイトル、作者、著作権保持者およびキャストなどのコンテンツ固有情報を記憶すべく使用され得る。
これに加え、使用されるCLIオプションおよび各パスの後における量子化数(quantizer)分布などの、マルチメディア・ファイルを符号化すべく使用されるコーデック(codec)に関する技術的詳細が提供され得る。
【0131】
一実施例においてメタデータは一連のステートメントとして「DXDT」チャンク内に表され、その場合に各ステートメントは主部(subject)、述部(predicate)、目的部(object)および出典(authority)を含む。主部は、記述されている処に対する参照である。
主部は、ファイル、アイテム、人物または組織を参照し得る。主部は、記述を行い得る特性を有する任意のものを参照し得る。述部は、記述されている主部の特性を特定する。目的部は特定された主部の特性の記述であり、かつ、出典は情報のソースを特定する。
【0132】
以下の表は、種々の「meta data」が目的部、述部、主部および出典として如何に表され得るかの例を示している。
【0133】
【表1】
【0134】
【表2】
【0135】
【表3】
【0136】
一実施例において、主部、述部、目的部および出典の表現は、ラベル付き有向グラフ(DLG:Directed-Labeled Graphs)を形成し得るデータの2進表現を用いて実現される。DLGは、リソースもしくはリテラル(literal)のいずれかであるノードから成る。
リソースは、インターネット・エンジニアリング・タスク・フォースによりRFC2396(http://www.ictf.org/rfc/rfc2396.txt)において規定された汎用リソース識別子(URI)などの命名規則に準じ得るか、または、システム自体に固有のデータを参照し得る識別子である。リテラルは、リファレンスではなく実際の値の表現である。
【0137】
DLGの利点は、これによれば、映画の出演者などの同一タイプである可変数のデータが含まれ得ることである。表1に示された例においては、3人の出演者が含まれる。但し、任意数の出演者が含まれ得る。DLGはまた、他のデータタイプに対する関連接続も許容する。表1においては、主部「_: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)により特定されるタイトルは、「マトリックス・リローデッド」であるというデータを含む。
【0138】
表1における付加的な「meta data」ステートメントは、キアヌ・リーブスはネオの役を演じた出演者であったこと、および、ラリーおよびアンディ・ウォシャウスキーの両名は監督であったことを特定している。「meta data」においては技術的情報も表現される。「meta data」ステートメントは、“_:file281”はトラック“_:track#dc00”を含むことを特定する。「meta data」は、ビデオ・トラックの解像度、ビデオ・トラックの認証レベル、および、コーデックの設定を含む情報を提供する。表1においては示されないが、「meta data」は、符号化の時点でトラックに割当てられた一意的識別子も含み得る。
一意的識別子が使用されるときに同一のコンテンツを複数回符号化すると、コンテンツの符号化バージョンの各々に対して異なる識別子に帰着する。但し、符号化されたビデオ・トラックの複製物は、それがコピーされた元のトラックの識別子を保持する。
【0139】
表1に示されたエントリは、UPnPフォーラムにより規定されたUPnPボキャブラリ(http://www.upnpforum.org参照)などの他のボキャブラリにより置換され得る。別の代替策は、MPEG−21規格に向けた作業の一部として国際標準化機構により開発されたデジタルアイテム宣言言語(DIDL:Degital Item Declaration Language)またはDIDL-Liteボキャブラリである。以下は、UPnPボキャブラリにおける述部の例である。
【0140】
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
【0141】
全ての「meta data」に対する出典は、「_:auth42」である。「meta data」ステートメントは、「_:auth42」は「ワーナー・ブラザース」であることを示している。出典によれば、ファイルの品質と、そのファイルに関係付けられた「meta data」ステートメントとの両方の評価が可能とされる。
【0142】
グラフ内へのノードは、命名されたリソース・ノードを介して接続される。「meta data」のステートメントは、主部ノード、述部ノードおよび目的部ノードから成る。オプション的に、出典ノードは「meta data」ステートメントの一部としてのDLGに対して接続され得る。
【0143】
各ノードに対し、そのノードの機能性を更に説明する一定の特性が在る。可能なタイプは、ANSIのCプログラミング言語を用いて以下の如く表され得る。
/**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
【0144】
「DXDT」チャンク内に含まれる「meta data」チャンクを表す(ANSIのCプログラミング言語で表される)データ構造の例は以下のようである。
typedef struct RDFDataStruct
{
RDFHeader Header;
uint32_t numOfStatements;
RDFStatement statements[RDF_MAX_STATEMENTS];
} RDFData
「RDFData」チャンクは、「RDFHeader」チャンクと称されるチャンク、値「numOfStatements」、および、「RDFStatement」チャンクのリストを含む。
【0145】
「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;
【0146】
「RDFHeader」チャンクは、上位互換性を可能とするリソース記述フォーマットのバージョンを表す数「バージョン(version)」を含む。ヘッダは、「RDFHeader」チャンクの一部をも形成するリスト「スキーマ(Schema)」における「RDFSchema」チャンクの個数を表す第2の数「numOfSchemas」を含む。幾つかの実施例において「RDFSchema」チャンクは、複雑なリソースが更に効率的に表されるのを可能とすべく用いられる。一実施例において「RDFSchema」チャンクに含まれるデータは以下のように表され得る(ANSI Cで表される)。
typedef struct RDFSchemaStruct
{
wchar_t* prefix;
wchar_t* uri;
} RDFSchema;
【0147】
「RDFSchema」チャンクは、「接頭辞(prefix)」として識別される「dc」などの第1のテキスト文字列と、「uri」として識別される「http://purl.org/dc/elements/1.1/」などの第2のテキスト文字列とを含む。「prefix」は、「uri」の代わりに「meta data」で使用され得る用語を定義する。「uri」は、特定の規格化ボキャブラリに準じ得るか、特定システムに対する特定ボキャブラリとされ得る汎用リソース識別子である。
【0148】
「RDFData」チャンクの考察に戻る。「RDFHeader」チャンクに加えて「RDFData」チャンクは、値「numOfStatements」、および、「RDFStatement」チャンクのリスト「Statement」をも含んでいる。値「numOfStatements」は、情報を含むリスト「Statement」における「RDFStatement」チャンクの実際の個数を表す。一実施例において「RDFStatement」チャンクに含まれるデータは以下の如く表され得る(ANSI Cで表される)。
typedef struct RDFStatementStruct
{
RDFSubject subject;
RDFPredicate predicate;
RDFObject object;
RDFAuthority authority;
} RDFStatement;
【0149】
各「RDFStatement」チャンクは、マルチメディア・ファイルに関する「meta data」を含む。チャンク「subject」、「predicate」、「object」および「authority」は、上述の「meta data」の種々の構成要素を含むべく用いられる。
【0150】
「subject」は、上述の「meta data」の主部部分を表す「RDFSubject」チャンクである。一実施例において「RDFSubject」チャンクに含まれたデータは、以下の如く表され得る(ANSI Cで表される)。
typedef struct RDFSubjectStruct
{
uint16_t type;
wchar_t* value;
} RDFSubject;
【0151】
上記「RDFSubject」チャンクは、データがリソースであるかまたは「meta data」の匿名ノードであることを表す値「type」と、「meta data」の主部を表すデータを含むユニコード・テキスト文字列とを含む。「RDFSchema」チャンクが定義されている実施例において値は、リソースに対する直接的リファレンスの代わりに、定義済み用語とされ得る。
【0152】
「RDFStatement」チャンクにおける「predicate」は、「meta data」の述部部分を表す「RDFPredicate」チャンクである。一実施例において「RDFPredicate」チャンク内に含まれるデータは、以下の如く表され得る(ANSI Cで表される)。
{
uint16_t type;
wchar_t* value;
} RDFPredicate;
【0153】
上記の「RDFPredicate」チャンクは、データが述部URIであるかまたは「meta data」の順序リスト・エントリであることを表す値「type」と、「meta data」の述部を表すデータを含むテキスト文字列「value」とを含む。「RDFSchema」チャンクが定義されている実施例において値は、リソースに対する直接的リファレンスの代わりに、定義済み用語とされ得る。
【0154】
「RDFStatement」チャンクにおける「object」は、「meta data」の目的部部分を表す「RDFObject」チャンクである。一実施例において「RDFObject」チャンクに含まれたデータは、以下の如く表され得る(ANSI Cで表される)。
typedef struct RDFObjectStruct
{
uint16_t type;
wchar_t* language;
wchar_t* dataTypeURI;
wchar_t* value;
} RDFObject;
【0155】
上記の「RDFObject」チャンクは、データが、UTF−8リテラル文字列、リテラル整数または「meta data」のリテラルXMLデータであることを表す値「type」を含む。チャンクは、3個の値も含む。第1の値「language」は、「meta data」が表現される言語を表すべく用いられる(たとえば映画のタイトルは異なる言語に変更され得る)。幾つかの実施例においては、言語を識別すべく標準的な表現(インターネット・エンジニアリング・タスク・フォースにより指定された言語の識別に対するタグであるRFC3066など、http://www.ietf.org/rfc/rfc3066.txtを参照)が使用され得る。第2の値である「dataTypeURI」は、「value」フィールド内に含まれたデータのタイプが「type」フィールドにより明示的に表され得ないのであれば、そのデータのタイプを表すべく用いられる。dataTypeURIにより指定されたURIは、使用される特定形式のデータを記述すべく使用された一般的なRDF URIボキャブラリを指し示す。URIが表現され得る異なるフォーマットは、http://www.w3.org/TR/rdf-concepts/#section-Datatypesで記述される。一実施例において「value」は「ワイド文字(wide character)」である。他の実施例において「value」は、画像またはビデオシーケンスに対する単一ビットからの種々の形式のデータの内の任意のものとされ得る。「value」は、「meta data」の目的部部分を含む。
【0156】
「RDFStatement」チャンクにおける「authority」は、「meta data」の出典部分を表す「RDFAuthority」チャンクである。一実施例において「RDFAuthority」チャンクに含まれるデータは以下の如く表され得る(ANSI Cで表される)。
typedef struct RDFAuthorityStruct
{
uint16_t type;
wchar_t* value;
} RDFAuthority;
【0157】
上記の「DFAuthority」データは、そのデータがリソースであるか「meta data」の匿名ノードであるかを表す値「type」を含む。「value」は、「meta data」に対する出典を表すデータを含む。「RDFSchema」チャンクが定義された実施例において、値はリソースに対する直接的リファレンスの代わりに定義済み用語とされ得る。
【0158】
図2.3.には、本発明の実施例によるマルチメディア・ファイルの「DXDT」チャンクを記憶する概念的表現が示される。「DXDT」チャンク38は、「RDFHeader(RDFヘッダ)」チャンク110、「numOfStatements(ステートメント数)」値112、および、RDFStatementチャンク114の表を含む。RDFHeaderチャンク110は、「バージョン(version)」値116、「numOfSchemas(スキーマ数)」値118、「スキーマ(Schema)」チャンク120の表を含む。各「RDFステートメント(RDFStatement)」チャンク114は、「RDF主部(RDFSubject)」チャンク122、「RDF述部(RDFPredicate)」チャンク124、「RDF目的部(RDFObject)」チャンク126および「RDF出展(RDFAuthority)」チャンク128を含む。「RDF主部(RDFSubject)」チャンクは、「タイプ(type)」値130および「バリュー(value)」値132を含む。「RDF述部(RDFPredicate)」チャンク124もまた、「タイプ(type)」値134および「バリュー(value)」値136を含む。「RDF述部(RDFObject)」チャンク126は、「タイプ(type)」値138、(図においては「lang」として示された)「言語(language)」値140、(図においては「dataT」として示された)「URIデータタイプ(dataTypeURI)」値142、および、「バリュー(value)」値144を含む。「RDF出展(RDFAuthority)」チャンク128は、「タイプ(type)」値146および「バリュー(value)」値148を含む。図示された「DXDT」チャンクは、1つの「スキーマ(Schema)」チャンクおよび1つの「RDFステートメント(RDFStatement)」チャンクを含んで示されるが、当業者であれば、異なる個数の「スキーマ(Schema)」チャンクおよび「RDFステートメント(RDFStatement)」チャンクが「メタデータ」を記述するチャンクにおいて使用され得ることを容易に理解し得よう。
【0159】
以下において論じられるように、本発明の実施例によるマルチメディア・ファイルは連続的に改変および更新され得る。予め「meta data」を決定し、ファイル自体、および(たとえばインターネットを介して)遠隔的にアクセスされる「meta data」に対して関係付けることは困難であり得る。典型的には、ファイルの内容を記述するために本発明の実施例によるマルチメディア・ファイル内に十分な「meta data」が含まれる。そのファイルをレビューするデバイスが、そのファイル内から参照された「meta data」を含む他のデバイスに対してネットワークを介してアクセスし得る場合、付加的情報が獲得され得る。
【0160】
上述の「meta data」を表す方法は拡張可能であると共に、ファイルに対する必要性が経時的に変化するにつれ、そのファイル内に記憶される異なる「meta data」フィールドを付加および除去する能力を提供し得る。これに加え、「meta data」の表現は改訂版間で上位互換であり得る。
【0161】
本発明の実施例に従い「meta data」が表される構造化様式は、デバイスが、マルチメディア・ファイルのコンテンツを良好に決定すべくそのマルチメディア・ファイルに対して問合せ(query)を行うことを可能にする。その場合の問合せは、マルチメディア・ファイルの内容を更新し、マルチメディア・ファイルに関する付加的な「meta data」を獲得し、そのファイルの内容に関するメニューを生成し、または、標準的フォーマットで表されたデータの自動処理を伴う他の任意の機能を実施するために使用され得る。これに加え、「meta data」の解析可能な各エレメントの長さを定義すると、家電機器などの様にメモリの量が限られたデバイスが「meta data」にアクセスする容易さが高められ得る。
【0162】
他の実施例において「meta data」は、各「meta data」断片に対する個々のチャンクを用いて表される。本発明による幾つかの「DXDT」チャンクとしては、上述の如く符号化された「meta data」を含む2進チャンク、および、上述の如くまたは別のフォーマットのいずれかでフォーマットされた個別の「meta data」断片を含む付加的チャンクが含まれる。「DXDT」チャンクに2進「meta data」が含まれる実施例において、その2進「meta data」は64ビットの符号化ASCIIを用いて表され得る。他の実施例においては、他の2進表現が使用され得る。
【0163】
図2.3.1.には、本発明による「DXDT」チャンクに含まれ得る個別チャンクの例が示される。「メタデータ」は、「PixelAspectRatioMetaData(ピクセル縦横比メタデータ)」チャンク152a、「EncoderURIMetaData(エンコードURIメタデータ)」チャンク152b、「CodecSettingsMetaData(コーデック設定メタデータ)」チャンク152c、「FrameTypeMetaData(フレームタイプメタデータ)」チャンク152d、「VideoResolutionMetaData(ビデオ解像度メタデータ)」チャンク152e、「PublisherMetaData(出版社メタデータ)」チャンク152f、「CreatorMetaData(創作者メタデータ)」チャンク152g、「GenreMetaData(ジャンルメタデータ)」チャンク152h、「CreatorToolMetaData(創作者ツールメタデータ)」チャンク152i、「RightsMetaData(権利メタデータ)」チャンク152j、「RunTimeMetaData(ランタイムメタデータ)」チャンク152k、「QuantizerMetaData(量子化器メタデータ)」チャンク152l、「CodecInfoMetaData(コーデック情報メタデータ)」チャンク152m、「EncoderNameMetaData(エンコーダ名称メタデータ)」チャンク152n、「FrameRateMetaData(フレーム速度メタデータ)」チャンク152o、「InputSourceMetaData(入力ソースメタデータ)」チャンク152p、「FileldMetaData(フィールドメタデータ)」チャンク152q、「TypeMetaData(タイプメタデータ)」チャンク152r、「TitleMetaData(タイトルメタデータ)」チャンク152sおよび/または「CertLevelMetaData(認証レベルメタデータ)」チャンク152tを含み得る「メタデータ」チャンク150を含む。
【0164】
「PixelAspectRatioMetaData」チャンク152aは、符号化されたビデオのピクセル・アスペクト比に関する情報を含む。「EncoderURIMetaData」チャンク152bは、エンコーダに関する情報を含む。「CodecSettingsMetaData」チャンク152cは、ビデオを符号化するために使用されたコーデックの設定に関する情報を含む。「FrameTypeMetaData」チャンク152dは、ビデオ・フレームに関する情報を含む。「VideoResolutionMetaData」チャンク152eは、符号化されたビデオのビデオ解像度に関する情報を含む。「PublisherMetaData」チャンク152fは、メディアを発行した人物または組織に関する情報を含む。「CreatorMetaData」チャンク152gは、内容の創作者に関する情報を含む。「GenreMetaData」チャンク152hは、メディアのジャンルに関する情報を含む。「CreatorToolMetaData」チャンク152iは、ファイルを生成すべく使用されたツールに関する情報を含む。「RightsMetaData」チャンク152jは、DRMに関する情報を含む。
「RunTimeMetaData」チャンク152kは、メディアの実行時間に関する情報を含む。「QuantizerMetaData」チャンク152lは、ビデオを符号化すべく使用された量子化器に関する情報を含む。「CodecInfoMetaData」チャンク152mは、コーデックに関する情報を含む。「EncoderNameMetaData」チャンク152nは、エンコーダの名称に関する情報を含む。「FrameRateMetaData」チャンク152oは、メディアのフレーム速度に関する情報を含む。「InputSourceMetaData」チャンク152pは、入力ソースに関する情報を含む。「FileldMetaData」チャンク152qは、ファイルに対する一意的識別子を含む。「TypeMetaData」チャンク152rは、マルチメディア・ファイルの形式に関する情報を含む。「TitleMetaData」チャンク152sはメディアのタイトルを含み、かつ、「CertLevelMetaData」チャンク152tはメディアの認証レベルに関する情報を含む。他の実施例においては、付加的な「メタデータ」を含む付加的チャンクが含まれ得る。幾つかの実施例において「メタデータ」チャンク内には、上述された如く2進フォーマットで「メタデータ」を含むチャンクが含まれ得る。一実施例において2進「メタデータ」のチャンクは、64ビットASCIIとして符号化される。
【0165】
2.5.「DMNU」チャンク
図2.0.および図2.0.1.を参照すると、第1「DMNU」チャンク40(40’)および第2「DMNU」チャンク46(46’)が示される。図2.0.において第2「DMNU」チャンク46は、マルチメディア・ファイル30の一部を形成する。図2.0.1.に示された実施例において「DMNU」チャンク46’は、別個のRIFFチャンク内に含まれる。
両方の場合、第1および第2の「DMNU」チャンクは、索行可能メニューを表示すべく使用され得るデータを含む。一実施例において第1「DMNU」チャンク40(40’)は、拡張バックグラウンド動画などの進歩的特徴を含まない簡素なメニューを生成すべく使用され得るデータを含む。これに加えて第2「DMNU」チャンク46(46’)は、拡張動画式バックグラウンドなどの進歩的特徴を含む更に複雑なメニューを生成すべく使用され得るデータを含む。
【0166】
幾つかの実施例において、単純なメニューおよび複雑なメニューを配備すると、デバイスは自身が表示を意図するメニューを選択することが可能とされ得る。「movi」リスト・チャンク42の前に、その2つのメニューの内の小寸の方を載置すると、メニューを表示し得ない本発明の実施例によるデバイスは、表示され得ない情報を迅速に飛び越し得る。
【0167】
他の実施例において、単一メニューを生成するために必要なデータは、第1および第2「DMNU」チャンク間に分割される。代替的に「DMNU」チャンクは、単一群のメニューまたは複数群のメニューに対するデータを含む「movi」チャンクの前の単一チャンクとされ得る。他の実施例において「DMNU」チャンクは、マルチメディア・ファイルの全体における他の箇所に配置された単一または複数のチャンクとされ得る。
【0168】
本発明による幾つかのマルチメディア・ファイルにおいて第1「DMNU」チャンク40(40’)は、第2「DMNU」チャンク46(46’)における「richer」メニューに基づき自動的に生成され得る。メニューの自動生成は、以下においてより詳細に論じられる。
【0169】
図2.4.には、本発明の実施例による「DMNU」チャンクの構造が示される。「DMNU」チャンク158は、メニュー・チャンク160および「MRIF」チャンク162を含むリスト・チャンクである。メニュー・チャンクは、各メニューを構築して索行するために必要な情報を含む。「MRIF」チャンクは、各メニューに対してサブタイトル、バックグラウンド・ビデオおよびバックグラウンド・オーディオを提供すべく使用され得るメディア情報を含む。幾つかの実施例において「DMNU」チャンクは、各メニューを幾つかの異なる言語で表示させ得るメニュー情報を含む。
【0170】
一実施例において「WowMenu」チャンク160は、図2.5.に概念的に示されたメニュー・チャンク・オブジェクトの階層を含む。その階層の頂部には、「ワウメニューマネージャ(WowMenuManager)」チャンク170が在る。その「WowMenuManager」チャンクは、1つ以上の「言語メニュー(LanguageMenus)」チャンク172および1つの「メディア(Media)」チャンク174を含み得る。
【0171】
「LanguageMenus」チャンク172を使用すると、「DMNU」チャンク158は異なる言語でメニュー情報を含み得る。各「LanguageMenus」チャンク172、指定された言語で完全なメニュー群を生成すべく使用される情報を含む。ゆえに「LanguageMenus」チャンクはその「LanguageMenus」チャンクに関係付けられた情報の言語を特定する識別子を含む。その「LanguageMenus」チャンクはまた、「ワウメニュー(WowMenu)」チャンク175のリストも含む。
【0172】
各「WowMenu」チャンク175は、特定メニューに対して画面上に表示されるべき情報の全てを含む。この情報は、バックグラウンド・ビデオおよびオーディオを含み得る。情報はまた、他のメニューにアクセスすべく、または、メニューを抜け出してマルチメディア・ファイルの一部の表示を開始すべく使用され得るボタン動作に関するデータも含み得る。一実施例において「WowMenu」チャンク175は、メディアに対するリファレンスのリストを含む。これらのリファレンスは「Media」チャンク174内に含まれた情報を参照するが、これは以下において更に論じられる。メディアに対するリファレンスは、メニューに対するバックグラウンド・ビデオおよびバックグラウンド・オーディオを定義し得る。「WowMenu」チャンク175はまた、メニューが最初にアクセスされたときに特定ボタンを強調するために使用され得るオーバレイも定義する。
【0173】
これに加えて各「WowMenu」チャンク175は、所定数の「ボタンメニュー(ButtonMenu)」チャンク176を含む。各「ButtonMenu」チャンクは、画面上ボタンのプロパティを定義する。「ButtonMenu」チャンクは、ユーザによりボタンが強調されたときに使用するオーバレイ、ボタンの名称、および、メニューを通してナビゲートしているユーザにより実施された種々の動作に応じて行うべきことなどの事項を記述し得る。動作に対する応答は、「アクション(Action)」チャンク178を参照することで定義される。たとえばボタンを選択するなどの単一動作は、幾つかの「アクション」チャンクに対するアクセスに帰着し得る。画面上ポインタが制約のない様式でディスプレイ上を動き回ることを可能とするマウスなどのデバイスを用いてユーザがメニューと対話し得るという実施例において、ボタンの画面上箇所は「MenuRectangle(メニュー矩形)」チャンク180を用いて定義され得る。ボタンの画面上箇所を認識すると、システムは、自由範囲のデバイスを用いるときにユーザはボタンを選択しているか否かを決定し得る。
【0174】
各「Action」チャンクは、「プレイアクション(PlayAction)」チャンク182、「MenuTransitionAction(メニュー遷移アクション)」チャンク184、「ReturnToPlayAction(プレイに戻るアクション)」チャンク186、「AudioSelectAction(オーディオ選択アクション)」チャンク188、「SubtitleSelectAction(サブタイトル選択アクション)」チャンク190および「ButtonTransitionAction(ボタン遷移アクション)」チャンク191などの多数の異なる種々の動作関連チャンクの内の1つ以上を特定する。「プレイアクション」チャンク182は、マルチメディア・ファイル内におけるビデオ、オーディオおよびサブタイトルトラックの各々の一部を特定する。「プレイアクション」チャンクは、「MediaTrack」チャンク(以下の考察を参照)に対するリファレンスを用いてビデオ・トラックの一部を参照する。「プレイアクション」チャンクは、「SubtitleTrack(サブタイトルトラック)」チャンク192および「AudioTrack(オーディオトラック)」194チャンクを用いてオーディオおよびサブタイトルトラックを特定する。「SubtitleTrack」および「AudioTrack」チャンクは両者ともに、「MediaTrack(メディアトラック)」チャンク198に対するリファレンスを含む。「プレイアクション」チャンクが本発明の実施例による動作の基礎を形成するとき、選択されたオーディオおよびサブタイトルトラックは、既定として最初に設定された変数の値であって可能的にはその後にメニューに対するユーザの対話により改変される変数の値により決定される。
【0175】
各「MenuTransitionAction」チャンク184は、「WowMenu」チャンク175に対するリファレンスを含む。このリファレンスは、別のメニューへと遷移してそれを表示するための情報を獲得すべく使用され得る。
【0176】
各「ReturnToPlayAction」チャンク186は、ユーザがメニューを呼び出す前にアクセスされていたマルチメディア・ファイルの部分へとプレーヤが戻るのを可能とする情報を含む。
【0177】
各「AudioSelectAction」チャンク188は、特定のオーディオ・トラックを選択すべく使用され得る情報を含む。一実施例においてオーディオ・トラックは、本発明の実施例によるマルチメディア・ファイル内に含まれたオーディオ・トラックから選択される。他の実施例においてオーディオ・トラックは、外部的に参照されるファイル内に配置され得る。
【0178】
各「SubtitleSelectAction」チャンク190は、特定のサブタイトルトラックを選択すべく使用され得る情報を含む。一実施例においてサブタイトルトラックは、本発明の実施例によるマルチメディア・ファイル内に含まれたサブタイトルから選択される。他の実施例においてサブタイトルトラックは、外部的に参照されるファイル内に配置され得る。
【0179】
各「ButtonTransitionAction」チャンク191は、同一メニューにおける別のボタンへと遷移するために使用され得る情報を含む。これは、ボタンに関係付けられた他の動作が実施されてから実施される。
【0180】
「メディア(Media)」チャンク174は、所定数の「MediaSource」チャンク166および「MediaTrack」チャンク198を含む。「メディア」チャンクは、機能およびメニュー・システムにより使用されるマルチメディア・トラックの全て(たとえばオーディオ、ビデオ、サブタイトルなど)を定義する。各「MediaSource」チャンク196は、本発明の実施例によるマルチメディア・ファイル内のRIFFチャンクであって、それが更に複数のRIFFチャンクを含み得るというRIFFチャンクを特定する。各「MediaTrack」チャンク198は、「MediaSource」チャンクにより特定されたRIFFチャンク内のマルチメディア・トラックの一部を特定する。
【0181】
「MRIF」チャンク162は本質的に、RIFFフォーマットに従うそれ自体のスモール・マルチメディア・ファイルである。「MRIF」チャンクは、メニューに対するバックグラウンド・オーディオおよびビデオおよびオーバレイを提供するために使用され得るオーディオ、ビデオおよびサブタイトルトラックを含む。「MRIF」チャンクは、強調されたメニュー・ボタンを表すオーバレイとして使用されるべきビデオも含む。必要とされるメニュー・データが少ない実施例においてバックグラウンド・ビデオは、静止フレーム(AVIフォーマットの変形例)または同一フレームのスモール・シーケンスとされ得る。他の実施例においては、バックグラウンド・ビデオを提供すべく更に精巧なシーケンスのビデオが使用され得る。
【0182】
上述の如く、「WowMenu」チャンク175の一部および「WowMenu」チャンク自体を形成する種々のチャンクは、実際のメディア・トラックに対するリファレンスを含む。これらのリファレンスの各々は典型的に、RIFFチャンクの「hdrl」リスト・チャンク内に定義されたメディア・トラックに対するものである。
【0183】
図2.6.には、本発明による「DMNU」チャンクを生成すべく使用され得る他のチャンクが示される。「DMNU」チャンクは「WowMenuManager」チャンク170’を含む。「WowMenuManager」チャンク170’は、少なくとも一個の「LanguageMenus」チャンク172’、少なくとも一個の「メディア」チャンク174’、および、少なくとも一個の「TranslationTable」チャンク200を含み得る。
【0184】
「LanguageMenus」チャンク172’の内容は、図2.5.に示された「LanguageMenus」チャンク172のそれと非常に似ている。主な相違点は、「プレイアクション」チャンク182’が「SubtitleTrack」チャンク192および「AudioTrack」チャンク194を含まないことである。
【0185】
「Media」チャンク174’は、図2.5.に示された「Media」チャンク174と相当に異なる。「Media」チャンク174’は、少なくとも一個の「タイトル(Title)」チャンク202および少なくとも一個の「メニュートラック(MenuTracks)」チャンク204を含む。「タイトル」チャンクは、マルチメディア・ファイル内のタイトルを参照する。
上述された如く本発明の実施例によるマルチメディア・ファイルは1つ以上のタイトル(たとえば、テレビ・シリーズにおける複数のエピソード、完全長の番組の関連シリーズ、または、単に異なる番組の選択)を含み得る。「メニュートラック」チャンク204は、メニュー表示、および、その表示に付随するオーディオ・サウンドトラックおよびサブタイトルを生成すべく使用されるメディア情報に関する情報を含む。
【0186】
「タイトル」チャンクは、少なくとも一個の「チャプター(Chapter)」チャンク206を含み得る。「チャプター」チャンク206は、特定タイトル内のシーンを参照する。
「チャプター」チャンク206は、その「チャプター」チャンクにより表されるシーンに対応するビデオ・トラック、各オーディオ・トラックおよび各サブタイトルトラックの部分に対するリファレンスを含む。一実施例においてリファレンスは、図2.5.に関して上述されたのと同様の「メディアソース(MediaSource)」チャンク196’および「メディアトラック(MediaTrack)」チャンク198’を用いて実現される。幾つかの実施例において「メディアトラック」チャンクはビデオ・トラックの適切な部分を参照し、かつ、所定数の付加的な「メディアトラック」チャンクは各々、オーディオ・トラックまたはサブタイトルトラックの内の1つのトラックを参照する。一実施例において、特定のビデオ・トラックに対応するオーディオ・トラックおよびサブタイトルトラックの全ては、別個の「メディアトラック」チャンクを用いて参照される。
【0187】
上述された如く「メディアトラック」チャンク204は、メニューのオーディオ、ビデオおよびオーバレイ・メディアを生成すべく使用されるメディアに対するリファレンスを含む。一実施例においてメディア情報に対する参照は、「メディアトラック」チャンク内に含まれた「メディアソース」チャンク196’および「メディアトラック」チャンク198’を用いて為される。一実施例において「メディアソース」チャンク196’および「MediaTrack」チャンク198’は、図2.5.に関して記述された様式で実現される。
【0188】
「翻訳テーブル(TranslationTable)」チャンク200は、各タイトルおよびチャプタを種々の言語で記述するテキスト文字列を含むべく使用され得る。一実施例において「翻訳テーブル」チャンク200は、少なくとも一個の「翻訳検索(TranslationLookup)」チャンク208を含む。各「翻訳検索」チャンク208に対しては「タイトル」チャンク202、「チャプター」チャンク206または「メディアトラック」チャンク196’が関係付けられ、かつ、その「TranslationLookup」チャンクは所定数の「翻訳(Translation)」チャンク210を含んでいる。「TranslationLookup」チャンクにおける「Translation」チャンクの各々は、「翻訳検索」チャンクに関係付けられたチャンクを、「翻訳」チャンクにより表された言語で記述するテキスト文字列を含む。
【0189】
図2.6.1.には、「DMNU」チャンク内に含まれた種々のチャンク間の関係を概念的に示す図が示される。この図は実線矢印を用いて、1つのチャンクによる別のチャンクの包含関係を示している。矢印が示す方向は、矢印が出ているチャンクにより含まれるチャンクを表している。ひとつのチャンクによる別のチャンクに対する参照は点線により表され、その場合に参照されたチャンクは点線矢印により表される。
【0190】
2.6.「junk」チャンク
「ジャンク(junk)」チャンク41は、本発明の実施例によるマルチメディア・ファイルに含まれ得る選択的チャンクである。「junk」チャンクの性質は、AVIファイル・フォーマットにおいて仕様が定められている。
【0191】
2.7.「movi」リスト・チャンク
「movi」リスト・チャンク42は、所定数の「データ(data)」チャンクを含む。「データ」チャンクが含み得る情報の例は、オーディオ、ビデオまたはサブタイトル・データである。一実施例において「movi」リスト・チャンクは、少なくとも一個のビデオ・トラック、複数のオーディオ・トラックおよび複数のサブタイトルトラックに対するデータを含む。
【0192】
図2.7.には、1つのビデオ・トラックと、3つのオーディオ・トラックと、3つのサブタイトルトラックとを含むマルチメディア・ファイルの「movi」リスト・チャンク42内における「データ」チャンクの交互配置様式が示される。便宜のために、ビデオを含む「データ」チャンクは「ビデオ」チャンクと称され、オーディオを含む「データ」チャンクは「オーディオ」チャンクと称され、かつ、サブタイトルを含む「データ」チャンクは「サブタイトル(subtitle)」チャンクと称される。図示された「movi」リスト・チャンク42において、各「ビデオ」チャンク262は、オーディオ・トラックの各々からの「オーディオ」チャンク264により、次の「ビデオ」チャンクから分離されている。幾つかの実施例において夫々の「オーディオ」チャンクは、1つの「オーディオ」チャンクに追随する「ビデオ」チャンクに含まれたビデオの一部に対応するオーディオ・トラックの一部を含む。
【0193】
隣接する「ビデオ」チャンク同士はまた、複数のサブタイトルトラックの内の1つのサブタイトルトラックからの1つ以上の「サブタイトル(subtitle)」チャンク266によっても分離され得る。一実施例において「サブタイトル」チャンク266は、サブタイトル、開始時間および停止時間を含む。幾つかの実施例において「サブタイトル」チャンクは、その「サブタイトル」チャンクに追随する「ビデオ」チャンクが、そのサブタイトルの開始時間にて行われるビデオの部分を含む如く、「movi」リスト・チャンクに交互配置される。他の実施例において、全ての「サブタイトル」および「オーディオ」チャンクの開始時間は、ビデオの同等の開始時間に先んじる。一実施例において「オーディオ」および「subtitle」チャンクは対応する「ビデオ」チャンクの5秒以内に載置され得ると共に、他の実施例において「オーディオ」および「サブタイトル」チャンクは、ファイル内のオーディオおよびビデオを表示し得るデバイスによりバッファされ得るビデオの量に関連する時間内に載置され得る。
【0194】
一実施例において「データ」チャンクは、その「データ」チャンクが属するストリームを特定する「FOURCC」コードを含む。その「FOURCC」コードは、2数字ストリーム番号と、これに続くと共にチャンクにおける情報の形式を定義する2文字コードとから成る。(Raider)代替的な「FOURCC」コードは、チャンクにおける情報の形式を定義する2文字コードと、それに続く2数字ストリーム番号とから成る。2文字コードの例は、以下の表に示される。
【0195】
【表4】
【0196】
一実施例において「ビデオ(video)」チャンク262および「オーディオ(audio)」チャンク264の構造は、AVIファイル・フォーマットに従う。他の実施例においては、メディアの性質を特定すると共に符号化メディアを含むチャンク用の他のフォーマットが使用され得る。
【0197】
幾つかの実施例において「サブタイトル(subtitle)」チャンク266に含まれるデータは、以下の如く表される。
typedef struct_subtitlechunk{
FOURCC fcc;
DWORD cb;
STR duration;
STR subtitle;
} SUBTITLECHUNK;
【0198】
値「fcc」は、サブタイトルトラックと、そのサブタイトルトラックの性質とを表すFOURCCコードである(テキストまたはビットマップ・モード)。値「cb」は、構造のサイズを指定する。値「duration」は、サブタイトルの開始および終了時点における時間を指定する。一実施例においてそれは、hh:mm:ss-hh:mm:ss.xxxの形態とされ得る。hhは時間を、mmは分を、ssは秒を、かつ、xxxはミリ秒を表す。値「subtitle」は、テキスト・モードにおけるサブタイトルのユニコード・テキスト、または、ビットマップ・モードにおけるサブタイトルのビットマップ・イメージのいずれかを含む。本発明の幾つかの実施例は、サブタイトル情報を表す圧縮ビットマップ・イメージを用いる。一実施例において「subtitle」フィールドは、サブタイトルの幅、高さおよび画面上位置に関する情報を含む。
これに加えて「subtitle」フィールドはまた、ビットマップの色情報および実際のピクセルも含み得る。幾つかの実施例においては、ビットマップを表すために必要なピクセル情報の量を減少するために、ランレングス・コーディングが用いられる。
【0199】
本発明の実施例によるマルチメディア・ファイルは、デジタル著作権管理を包含し得る。この情報は、ビデオ・オンデマンド・アプリケーションにおいて使用され得る。デジタル著作権管理により保護されたマルチメディア・ファイルは、特定の再生権利が許可されたプレーヤ上でのみ正しく再生され得る。一実施例において、トラックがデジタル著作権管理により保護されているという事実は、「hdrl」リスト・チャンクにおけるトラックに関する情報において表され得る(上記の記述を参照)。デジタル著作権管理により保護されたトラックを含む本発明の実施例によるマルチメディア・ファイルは、「movi」リスト・チャンク内にデジタル著作権管理に関する情報も含み得る。
【0200】
図2.8.には、1つのビデオ・トラックと、複数のオーディオ・トラックと、少なくとも一つのサブタイトルトラックと、デジタル著作権管理を有効化する情報とを含む本発明の実施例によるマルチメディア・ファイルの「movi」リスト・チャンクが示される。「movi」リスト・チャンク42’は図2.7.に示された「movi」リスト・チャンクと類似するが、各「ビデオ」チャンク262’に先立ち「DRM」チャンク270が付加されている。「DRM」チャンク270は、FOURCCコード「nndd」により特定され得るデジタル著作権管理情報を含む「data」チャンクである。最初の2個の文字「nn」はトラック番号を参照し、かつ、第2の2個の文字は、そのチャンクがデジタル著作権管理情報を含むことを意味する「dd」である。一実施例において「DRM」チャンク270は、その「DRM」チャンクに追随する「ビデオ」チャンク262’に対するデジタル著作権管理情報を提供する。
デジタル著作権管理により保護されたビデオ・トラックを再生しようとするデバイスは、「DRM」チャンクにおける情報を使用して、「ビデオ」チャンクにおけるビデオ情報を復号化する。典型的に、「ビデオ」チャンクの前に「DRM」チャンクが無ければ、その「ビデオ」チャンクは非保護であることが意味されると解釈される。
【0201】
本発明の実施例による暗号化システムにおいて、ビデオ・チャンクは部分的にのみ暗号化される。部分的暗号化が使用される場合、「DRM」チャンクは、「ビデオ」チャンクの暗号化された部分に対するリファレンスと、その暗号化部分を復号化するために使用され得るキーに対するリファレンスとを含む。復号化キーは、「strd」チャンク(の記述を参照)の一部である「DRM」ヘッダ内に配置され得る。復号化キーは、スクランブルが掛けられると共に、マスタ・キーにより暗号化される。「DRM」ヘッダは、マスタ・キーを特定する情報も含む。
【0202】
図2.9.には、「DRM」チャンク内の情報の概念的表現が示される。「DRM」チャンク270は、「フレーム(frame)」値280、「ステータス(status)」値282、「オフセット(offset)」値284、「数(number)」値286および「キー(key)」値288を含み得る。「フレーム(frame)」値は、ビデオの暗号化フレームを参照すべく使用され得る。「ステータス(status)」値はフレームが暗号化されているか否かを表すべく使用され得ると共に、「オフセット(offset)」値284は、フレーム内の暗号化ブロックの開始部分を指し示し、「数(number)」値286はブロックにおける暗号化バイトの個数を表す。「キー(key)」値288は、ブロックを復号化すべく使用され得る復号化キーを参照する。
【0203】
2.8.「idxl」チャンク
「idxl」チャンク44は、「movi」リスト・チャンク42内の「data」チャンクをインデックス付けすべく使用され得る選択的チャンクである。一実施例において「idxl」チャンクは、AVIフォーマットにおいて指定された如く実現され得る。他の実施例において「idxl」チャンクは、「movi」リスト・チャンク内の「data」チャンクの各々のファイル内の箇所を参照するデータ構造を用いて実現され得る。幾つかの実施例において「idxl」チャンクは、データのトラック番号とデータの形式とにより、各「data」チャンクを識別する。上記で言及されたFOURCCコードは、この目的のために使用され得る。
【0204】
3.マルチメディア・ファイルの符号化方法
本発明の実施例は、種々の様式でマルチメディア・ファイルを生成すべく使用され得る。ある場合において本発明の実施例によるシステムは、別個のビデオ・トラック、オーディオ・トラックおよびサブタイトルトラックを含むファイルからマルチメディア・ファイルを生成し得る。かかる場合、メニュー情報および「メタデータ」などの他の情報は、オーサリングされてファイル内へと挿入され得る。
【0205】
本発明の実施例による他のシステムは、デジタル・ビデオ・ディスク(“DVD”)上の種々のファイルから情報を抽出すべく、かつ、本発明の実施例による単一のマルチメディア・ファイルをオーサリングすべく使用され得る。DVDが情報の最初の供給源である場合に本発明の実施例によるシステムは、相当に圧縮すべくコーデックを使用し得ると共に、新たに生成されたマルチメディア・ファイルにおけるビデオ・チャンクに対してオーディオ・チャンクが対応する様にオーディオを再チャンキングし得る。これに加え、マルチメディア・ファイルに含まれるメニュー情報を生成すべく、DVDメニュー・システムにおけるメニュー情報が解析して使用され得る。
【0206】
他の実施例は、本発明の実施例による既存のマルチメディア・ファイルに対して付加的なコンテンツを追加することにより、新たなマルチメディア・ファイルを生成し得る。付加的コンテンツの追加の例は、注釈(たとえばディレクタのコメント、バケーション・ビデオに対して事後作成されたナレーションなど)を含むオーディオ・トラックなどの付加的なオーディオ・トラックをファイルに追加することである。マルチメディア・ファイル内へと交互配置された付加的オーディオ・トラック情報には、新たなオーディオ・トラックの再生を可能とするそのマルチメディア・ファイル内のメニュー情報の改変が付属し得る。
【0207】
3.1.記憶されたデータ・トラックを用いる生成方法
図3.0.には、マルチメディア・ファイルを生成する本発明の実施例によるシステムが示される。システム350の主要構成要素は、インタリーバ352である。そのインタリーバは、情報のチャンクを受信してそれらを交互配置することで、本発明の実施例によるマルチメディア・ファイルを上述のフォーマットで生成する。インタリーバはまた、メタデータ・マネージャ354から「メタデータ」に関する情報も受信する。インタリーバは、本発明の実施例によるマルチメディア・ファイルを記憶デバイス356に対して出力する。
【0208】
典型的に、インタリーバに対して提供されたチャンクは記憶デバイスに記憶される。幾つかの実施例においてチャンクの全ては、同一の記憶デバイスに記憶される。他の実施例においてチャンクは、種々の記憶デバイスからインタリーバに対して提供され得るか、または、リアルタイムで生成されてインタリーバに対して提供され得る。
【0209】
図3.0.に示された実施例においては、「DMNU」チャンク358および「DXDT」チャンク360がすでに生成されて記憶デバイスに記憶されている。記憶デバイスにはビデオ・ソース362が記憶され、そのビデオ・ソースはビデオ・デコーダ364を用いて復号化されてからビデオ・エンコーダ366を用いて符号化されて「ビデオ」チャンクが生成される。記憶デバイスにはオーディオ・ソース368も記憶される。オーディオ・チャンクは、オーディオ・デコーダ370を用いてオーディオ・ソースを復号化してから、復号化されたオーディオをオーディオ・エンコーダ372で符号化することにより生成される。「サブタイトル(subtitle)」チャンクは、記憶デバイスに記憶されたテキスト・サブタイトル374から生成される。サブタイトルは、所定数のサブタイトル・フォーマットの内の任意のフォーマットを生のビットマップ・フォーマットへと変換する第1トランスコーダ376に対して提供される。一実施例において、記憶されたサブタイトル・フォーマットはSRT、SUBまたはSSAなどのフォーマットである。これに加えてビットマップ・フォーマットは、色パレート(color palate)ルックアップ・テーブルを含む4ビットのビットマップである。色パレート・ルックアップ・テーブルは、16種の可能な4ビット・カラー・コードの各々に対する24ビットのカラー深度識別を含む。単一のマルチメディア・ファイルは、1つより多い色パレート・ルックアップ・テーブルを含み得る(上記の表2における「pc」パレートFOURCCコードを参照)。ゆえに4ビットのビットマップによれば各メニューは、1,600万色のパレートから取り出された16個の異なる同時的な色を有し得る。代替実施例においては、ピクセル毎に異なるビット数および異なるカラー深度が用いられる。第1トランスコーダ376の出力は、ビットマップを圧縮する第2トランスコーダ378へと提供される。一実施例においては、ビットマップを圧縮するためにランレングス・コーディングが用いられる。他の実施例においては、他の適切な圧縮フォーマットが用いられる。
【0210】
一実施例において、種々のエンコーダ、デコーダおよびトランスコーダ間のインタフェースは、Microsoft社により仕様を定められたDirectShow規格に準じる。他の実施例において、符号化、復号化およびトランスコードを実施すべく使用されるソフトウェアは、斯かる規格に従う必要はない。
【0211】
図示実施例においては、各メディア・ソースに対して別個の処理構成要素が示される。
他の実施例においては、リソースが共有され得る。たとえば単一のオーディオ・デコーダおよびオーディオ・エンコーダは、全てのソースからのオーディオ・チャンクを生成すべく使用され得る。典型的には、システム全体が、ソフトウェアを用いてコンピュータ上に実現されると共に、ハードディスク・ドライブなどの記憶デバイスに対して接続され得る。
【0212】
上述の様式でインタリーバを利用するために、本発明の実施例による「DMNU」チャンク、「DXDT」チャンク、「ビデオ(video)」チャンク、「オーディオ(audio)」チャンクおよび「サブタイトル(subtitle)」チャンクは、生成されてインタリーバに対して提供されねばならない。本発明の実施例によるマルチメディア・ファイルにおける種々のチャンクの各々を生成するプロセスは、以下においてより詳細に論じられる。
【0213】
3.2.「DXDT」チャンクの生成方法
「DXDT」チャンクは、多数の様式の内の任意の様式で生成され得る。一実施例において「メタデータ」はグラフィカル・ユーザ・インタフェースを介してデータ構造内へと入力されてから、「DXDT」チャンクへと解析される。一実施例において「メタデータ」は、一連の主部、述部、目的部および出典ステートメントとして表現される。別実施例において「メタデータ」ステートメントは、種々のフォーマットの内の任意のフォーマットで表現される。幾つかの実施例において各「メタデータ」ステートメントは、別個のチャンクへと解析される。他の実施例においては、(主部、述部、目的部および出典表現などの)第1フォーマットの幾つかの「メタデータ」ステートメントが第1チャンクへと構文解析され、かつ、他のフォーマットの他の「メタデータ」ステートメントは別個のチャンクへと構文解析される。一実施例において「メタデータ」ステートメントは、XMLコンフィグファイル(XML configuration file)に書き込まれ、そのXMLコンフィグファイルが解析されて「DXDT」チャンク内のチャンクが生成される。
【0214】
図3.1.には、XMLコンフィグファイル内に含まれた一連の「メタデータ」ステートメントから「DXDT」チャンクを生成するシステムの実施例が示される。システム380は、パーサ(parser)384に対して提供され得るXMLコンフィグファイル382を含む。XMLコンフィグファイルは、XMLとして符号化された「メタデータ」を含む。パーサはXMLを解析し、かつ、そのパーサは、「メタデータ」ステートメントを、の「メタデータ」チャンク・フォーマットの内の任意のフォーマットに従い「DXDT」チャンクに対して書き込まれるチャンクへと変換することにより、「DXDT」チャンク386を生成する。
【0215】
3.3.「DMNU」チャンクの生成方法
図3.2.には、本発明の実施例による「DMNU」チャンクを生成するために使用され得るシステムが示される。メニュー・チャンク生成システム420は、入力として、メディア・モデル422およびメディア情報を必要とする。メディア情報は、ビデオ・ソース424、オーディオ・ソース426およびオーバレイ・ソース428の形態を取り得る。
【0216】
メニュー・チャンク生成システムに対する入力を用いる「DMNU」チャンクの生成は、多数の中間ファイルの生成を伴う。メディア・モデル422はXMLコンフィグファイル430を生成するために使用され、かつ、メディア情報は所定数のAVIファイル432を生成するために使用される。XMLコンフィグファイルは、モデル・トランスコーダ434により生成される。AVIファイル432は、インタリーバ436を用いてビデオ、オーディオおよびオーバレイ情報を交互配置することで生成される。ビデオ情報は、ビデオ・デコーダ438およびビデオ・エンコーダ440を用いてビデオ・ソース424を復号化し、以下において論じられる様式でそれを再コード化することで求められる。オーディオ情報は、オーディオ・デコーダ442およびオーディオ・エンコーダ444を用いてオーディオを復号化して、以下に記述される様式でそれを符号化することで求められる。オーバレイ情報は、第1トランスコーダ446および第2トランスコーダ448を用いて生成される。第1トランスコーダ446はオーバレイを標準的ビットマップなどのグラフィック表現へと変換すると共に、第2トランスコーダは、そのグラフィック情報を受けて、それを、マルチメディア・ファイル内への包含に対して必要とされる如くフォーマットする。メニューを構築するために必要な情報を含むXMLファイルおよびAVIファイルが一旦生成されたなら、メニュージェネレータ450はその情報を使用して「DMNU」チャンク358’を生成し得る。
【0217】
3.3.1.メニュー・モデル
一実施例においてメディア・モデルは、各メニューおよびそれらの下位構成要素の全てを表すオブジェクト指向モデルである。そのメディア・モデルはメニューを、言語選択により各メニューが体系化されるのを許容する階層構造へと体系化する。図3.3.には、本発明の実施例によるメディア・モデルが示される。メディア・モデル460は、多数の「LanguageMenus(言語メニュー)」オブジェクト(object)463、「Media(メディア)」オブジェクト464および「翻訳テーブル(TranslationTable)」オブジェクト465と関係付けられた最高レベルの「メディアマネージャ(MediaManager)」オブジェクト462を含む。「メニューマネージャ(Menu Manager)」は、既定のメニュー言語も含む。一実施例において既定言語は、ISO 639の2文字言語コードにより表され得る。
【0218】
「言語メニュー(LanguageMenus)」オブジェクトは、種々のメニューに対する情報を言語選択により体系化する。所定の言語に対する「メニュー(menu)」オブジェクト466の全てには、その言語に対する「言語メニュー(LanguageMenus)」オブジェクト463が関係付けられる。各「メニュー」オブジェクトには、所定数の「ボタン(Button)」オブジェクト468が関係付けられると共に、「メニュー」オブジェクトは所定数の「メディアトラック(MediaTrack)」オブジェクト488を参照する。参照された「メディアトラック」オブジェクト488は、「メニュー」オブジェクト466に対するバックグラウンド・ビデオおよびバックグラウンド・オーディオを表している。
【0219】
各「ボタン(Button)」オブジェクト468には、「アクション(Action)」オブジェクト470および「矩形(Rectangle)」オブジェクト484が関係付けられる。「ボタン(Button)」オブジェクト468はまた、そのボタンが表示上で強調されたときに使用されるべきオーバレイを表す「メディアトラック(MediaTrack)」オブジェクト488に対するリファレンスも含む。各「アクション(Action)」オブジェクト470に対しては、「メニュー遷移(MenuTransition)」オブジェクト472、「ButtonTransition(ボタン遷移)」オブジェクト474、「ReturnToPlay(プレイに戻る)」オブジェクト476、「SubtitleSelection(サブタイトル選択)」オブジェクト478、「AudioSelection(オーディオ選択)」オブジェクト480および「プレイアクション(PlayAction)」オブジェクト482を含み得る所定数のオブジェクトが関係付けられる。これらのオブジェクトの各々は、ユーザからの種々の入力に対するメニュー・システムの応答を定義する。
「MenuTransition(メニュー遷移)」オブジェクトは、動作に応じて遷移されるべきメニューを表す「メニュー」オブジェクトに対するリファレンスを含む。「ButtonTransition(ボタン遷移)」オブジェクトは、動作に応じて強調されるべきボタンを表す。「ReturnToPlay(プレイに戻る)」によればプレーヤは番組の再生に戻り得る。「SubtitleSelection(サブタイトル選択)」および「AudioSelection(オーディオ選択)」オブジェクトは、(以下で論じられる)「タイトル(Title)」オブジェクト487に対するリファレンスを含む。「プレイアクション」オブジェクトは、(以下で論じられる)「チャプター(Chapter)」オブジェクト492に対するリファレンスを含む。「矩形(Rectangle)」オブジェクト484は、ボタンにより占有された画面の部分を表す。
【0220】
「メディア(Media)」オブジェクト464は、メニュー・システムにおいて参照されたメディア情報を表す。「メディア(Media)」オブジェクトは、「メニュートラック(MenuTracks)」オブジェクト486と、それに関係付けられた所定数の「タイトル(Title)」オブジェクト487とを有する。「メニュートラック(MenuTracks)」オブジェクト486は、メニューを構築すべく使用されるメディア(すなわちバックグラウンド・オーディオ、バックグラウンド・ビデオおよびオーバレイ)を表す「メディアトラック(MediaTrack)」オブジェクト488を参照する。
【0221】
「タイトル」オブジェクト487は、マルチメディア・プレゼンテーションを表すと共に、所定数の「チャプター」オブジェクト492と、それらに関係付けられた「メディアソース(MediaSource)」オブジェクト490とを有する。「タイトル」オブジェクトは、「翻訳検索(TranslationLookup)」オブジェクト494に対するリファレンスも含む。「チャプター」オブジェクトはマルチメディア・プレゼンテーションにおける一定箇所を表すと共に、それに関係付けられた所定数の「メディアトラック(MediaTrack)」オブジェクト488を有する。「チャプター」オブジェクトは、「TranslationLookup(翻訳検索)」オブジェクト494に対するリファレンスも含む。「チャプター」オブジェクトが関係付けられた各「メディアトラック」オブジェクトは、マルチメディア・プレゼンテーションのオーディオ、ビデオまたはサブタイトルトラックのいずれかにおける箇所を表すと共に、(以下で論じられる)「メディアソース(MediaSource)」オブジェクト490および「翻訳検索(TranslationLookup)」オブジェクト494を参照する。
【0222】
「翻訳テーブル(TranslationTable)」オブジェクト465は、「タイトル(Title)」オブジェクト、「チャプター」オブジェクトおよび「メディアトラック(MediaTrack)」オブジェクトにより表されるマルチメディア・プレゼンテーションの種々の部分を記述する所定数のテキスト文字列をグループ化する。「翻訳テーブル(TranslationTable)」オブジェクト465は、それに対して関係付けられた所定数の「翻訳検索(TranslationLookup)」オブジェクト494を有する。各「翻訳検索」オブジェクトは、特定オブジェクトを表すと共に、それに関係付けられた所定数の「翻訳(Translation)」オブジェクト496を有する。その「翻訳オブジェクトは各々、「翻訳検索(TranslationLookup)」オブジェクトにより表されたオブジェクトを特定言語で記述するテキスト文字列を表す。
【0223】
上述の種々のオブジェクトを生成すべく構成されたソフトウェアであってオブジェクト間の必要な関係付けおよび参照を確立するソフトウェアを用いて、メディア・オブジェクト・モデルが構築され得る。
【0224】
3.3.2XMLファイルの生成方法
XMLコンフィグファイルは、各メニューおよびそれらの下位構成要素の全てを表すメニュー・モデルから生成される。XMLコンフィグファイルはまた、各メニューにより使用されるメディア・ファイルの全ても特定する。XMLは、オブジェクト・モデルをXMLコードへと解析する適切なパーサ・アプリケーションを実現することで生成され得る。
【0225】
他の実施例においてはビデオ編集アプリケーションがユーザに対してインタフェースを提供することで、メニュー・モデルを生成せずにXMLコンフィグファイルの直接的生成が可能とされ得る。
【0226】
DVDメニューなどの別のメニュー・システムがメニュー・モデルの基礎であるという実施例において、メニューはユーザにより切り詰められ、本発明の実施方法に従い生成されるマルチメディア・ファイルに含まれない内容に関するメニュー・オプションが排除され得る。一実施例においてこれは、メニュー・モデルからのオブジェクトの排除を可能とするグラフィカル・ユーザ・インタフェースを配備することで行われ得る。別実施例においてメニューの切り詰めは、XMLコンフィグファイルを編集し得るグラフィカル・ユーザ・インタフェースまたはテキスト・インタフェースを配備することにより達成され得る。
【0227】
3.3.3.メディア情報
「DMNU」チャンクが生成されるとき、メニュージェネレータ450に対して提供されるメディア情報は、メニュー・モデル(上記の記述を参照)において特定されたボタンに対するバックグラウンド・ビデオ、バックグラウンド・オーディオおよびフォアグラウンド・オーバレイを提供するために必要なデータを含む。一実施例においては、カリフォルニア州、サンタクララのロキシオ社(Roxio, Inc.)により配給されるVideoWaveなどのビデオ編集アプリケーションが使用されることで、個別メニューの各々に対するビデオ、オーディオおよびボタン選択オーバレイを表すソース・メディア・トラックが提供される。
【0228】
3.3.4.中間AVIファイルの生成方法
上記の如く、バックグラウンド・ビデオ、バックグラウンド・オーディオおよびフォアグラウンド・ボタン・オーバレイとして使用されるメディア・トラックは、1つ以上のメニューに対して単一のAVIファイル内に記憶される。メニューAVIファイル内にメディア・トラックを含むチャンクは、ビデオ、オーディオおよびボタン・オーバレイトラックを交互配置すべく設計されたソフトウェアを用いて生成され得る。「オーディオ」、「ビデオ」および「オーバーレイ」チャンク(すなわちオーバレイ情報を含む「サブタイトルチャンク)は、インタリーバを用いてAVIフォーマット準拠ファイルへと交互配置される。
【0229】
上述された如く、各メニューに対しては別個のAVIファイルが生成され得る。他の実施例においては、バックグラウンド・オーディオ、バックグラウンド・ビデオおよびフォアグラウンド・オーバレイ情報を提供すべく使用されたメディア情報を含む他のファイル・フォーマットまたは単一ファイルが使用され得る。
【0230】
3.3.5.XMLコンフィグファイルおよびAVIファイルを結合する方法
一実施例においてコンピュータは、XMLコンフィグファイルからの情報を解析して(上述の)「WowMenu」チャンクを生成すべく構成される。これに加えてそのコンピュータは、各メニューに対するメディアを含むAVIファイルを用いて(上述の)「MRIF」チャンクを生成し得る。コンピュータは次に、「WowMenu」チャンクと「MRIF」チャンクにおけるメディア・チャンクとの間に必要なリファレンスを生成することにより「DMNU」チャンクの生成を完了し得る。幾つかの実施例において、メニュー情報は暗号化され得る。暗号化は、「MRIF」チャンクに含まれたメディア情報を、「ビデオ(video)」チャンクに関して以下に記述されるのと同様の様式で暗号化することで達成され得る。他の実施例においては、種々の代替的な暗号化技術が使用される。
【0231】
3.3.6.オブジェクト・モデルからのメニューの自動生成
図3.3.に戻ると、フルメニューよりも少ない内容を含むメニューは、「メディア」オブジェクト464に関係付けられた「タイトル」オブジェクト487を単に検証することにより、メニュー・モデルから自動的に生成され得る。図3.3.1.には、本発明の実施例によるメニューを自動的に生成すべく使用されるオブジェクトが示される。単に、マルチメディア・プレゼンテーションの特定セクションの選択と、使用されるオーディオおよびサブタイトルトラックの選択とを可能とする単純なメニューに対するXMLコンフィグファイルは、ソフトウェアにより生成され得る。
【0232】
3.3.7.単一の設定ファイルを用いて「DXDT」および「DMNU」チャンクを生成する方法
本発明の幾つかの実施例によるシステムは、「メタデータ」およびメニュー情報の両方を含む単一のXMLコンフィグファイルを生成し、かつ、そのXMLファイルを用いて「DXDT」および「DMNU」チャンクを生成し得る。これらのシステムは、「メタデータ」情報およびメニュー・オブジェクト・モデルを用いてXMLコンフィグファイルを導出する。
他の実施例において設定ファイルは、XMLである必要はない。
【0233】
3.4.「オーディオ」チャンクの生成方法
本発明の実施例によるマルチメディア・ファイルの「movi」リスト・チャンクにおける「オーディオ」チャンクは、本発明の実施方法に従い、オーディオ・ソースを復号化してから、そのソースを「オーディオ」チャンクへ符号化することにより生成され得る。一実施例において「オーディオ」チャンクは、MP3コーデックを用いて符号化され得る。
【0234】
3.4.1.オーディオを再チャンキングする方法
オーディオ・ソースが、対応「ビデオ」チャンクのコンテンツに対応するオーディオ情報を含まないチャンクで提供されたとき、本発明の実施例はそのオーディオを再チャンクし得る。図3.4.には、オーディオを再チャンクするために使用され得る処理が示される。処理480は、「ビデオ」チャンクを識別するステップ(482)と、その「ビデオ」チャンクに付随するオーディオ情報を識別するステップ(484)と、既存のオーディオ・チャンクからオーディオ情報を抽出(486)して新たな「オーディオ」チャンクを生成(488)するステップとを含む。処理は、オーディオ・ソース全体が再チャンクされたとの判断(490)が為されるまで反復される。その時点において、オーディオの再チャンクは完了(492)する。
【0235】
3.5.「ビデオ」チャンクの生成方法
上述された如く、ビデオ・チャンクを生成するプロセスはビデオ・ソースを復号化するステップと、復号化されたビデオを「ビデオ」チャンクへと符号化するステップとを包む。一実施例において各「ビデオ」チャンクは、ビデオの単一フレームに対する情報を含む。復号化プロセスは単に、特定フォーマットのビデオを取り込むステップと、そのビデオをそのフォーマットから、非圧縮ともされ得る標準的なビデオ・フォーマットへと復号化するステップとを包含する。符号化プロセスは、標準的なビデオを取り込むステップと、そのビデオを符号化するステップと、符号化されたビデオを用いて「ビデオ」チャンクを生成するステップとを含む。
【0236】
図3.5.には、本発明の実施例によるビデオ・エンコーダが概念的に示される。ビデオ・エンコーダ500は、標準的ビデオ情報504を前処理502する。次に、前処理済みビデオに対して動作評価506が実施されることで、前処理済みビデオに対する動作補償508が提供される。動作補償されたビデオに対しては、離散余弦変換(DCT変換)510が実施される。そのDCT変換に続き、ビデオは量子化512されると共に、予測514が実施される。次に、ビデオのテクスチャ・コード化518バージョンを、動作評価の結果を用いて生成された動作コーディング520と組み合わせることにより、圧縮ビットストリーム516が生成される。圧縮ビットストリームは次に、「ビデオ」チャンクを生成すべく用いられる。
【0237】
動作評価506を実施するために、(例えば、圧縮されたビデオがプレーヤによる視認のために解凍されたときに)システムは、ビデオの先行処理フレームが復号化デバイスにより如何にして復号化されたかに関する知見を有さねばならない。この情報は、量子化器512の出力を逆量子化522することにより求められ得る。次に、逆量子化器の出力に関して逆DCT524が実施され得ると共に、その結果は動作評価プロセスの間におけるアクセスのためにフレーム記憶器526に載置される。
【0238】
本発明の実施例によるマルチメディア・ファイルはまた、所定数の心理視覚的強化(psychovisual enhancement)528も含み得る。その心理視覚的強化は、人間の視覚の認識に基づきビデオを圧縮する方法とされ得る。これらの技術は、以下において更に論じられると共に、概略的には、量子化器により使用される所定数のビットを改変してビデオの種々の側面を表す段階を包含する。符号化プロセスの他の側面もまた、心理視覚的強化を含み得る。
【0239】
一実施例において符号化システム500は、上述の種々の機能を実施すべく構成されたコンピュータを用いて実現され得る。これらの機能の詳細な実施方式の例は以下に提供される。
【0240】
3.5.1.前処理方法
本発明の実施例によるエンコーダ500により選択的に実施される前処理操作502は、符号化されたビデオの品質を改善する多数の信号処理技術を使用し得る。一実施例において前処理502は、インターレース解除、時間的/空間的ノイズ減少およびサイズ再設定のひとつもしくは全てを包含し得る。これらの前処理技術の3つ全てが使用される実施例において、典型的には最初に交互配置解除が行われ、時間的/空間的ノイズ減少およびサイズ再設定が追随する。
【0241】
3.5.2.動作評価および補償
本発明の実施例によるビデオ・エンコーダは、複数のフレームにおいて反復されるピクセルを検索することにより、ビデオ・トラックを表すために必要なピクセルの個数を減少し得る。本質的に、ビデオにおける各フレームは典型的に、ひとつ前のフレームと同一のピクセルの多くを含んでいる。エンコーダは、(マクロブロック、ピクセル、ハーフ・ピクセルおよびクォータ・ピクセルとして)各フレーム間におけるピクセルの整合に対して幾つかの形式の検索を行い得ると共に、可能な場合は常に、イメージ品質を低下させずにこれらの冗長性を排除する。動作評価を用いることでエンコーダは、全てのフレームに対してピクチャ全体を記憶する代わりに、最後のフレームから生じた変化を記録するだけでピクチャの殆どを表し得る。動作評価の間にエンコーダは、自身が分析しつつあるフレームを、多くの場合に「macroblock(マクロブロック)」と称される均一な格子のブロックへと分割する。フレームにおける各「macroblock」に対し、エンコーダは先行フレームにおける整合ブロックを見出そうと試行し得る。整合ブロックを見出そうと試行するプロセスは、「モーション・サーチ」と称される。「macroblock」の動作は、2次元ベクトルすなわち(x,y)表現として表される。動作検索アルゴリズムは、種々の度合いの精度を以て実施され得る。ホール・ペル(whole pel)検索は、いずれかの次元において一度に1個のピクセルで基準フレームを全体に亙り踏破することで整合ブロックの位置決定をエンコーダが試行するという検索である。ハーフ・ピクセル検索においてエンコーダは、いずれかの次元において一度に半分のピクセルで基準フレームを全体に亙り踏破することで整合ブロックを検索する。エンコーダは、クォータ・ピクセル、他のピクセル割合、または、1個のピクセルより大きな粒度を包含する検索を使用し得る。
【0242】
図3.5.に示されたエンコーダ実施例は、本発明の実施例による動作評価を実施する。動作評価の間においてエンコーダは、前処理済みビデオ502と、フレーム記憶器526に記憶された先行フレームとに対してアクセスする。先行フレームは、量子化器の出力を取り込むと共に、逆量子化522および逆DCT変換524を実施することで生成される。上記の各逆関数を実施する理由は、本発明の実施例によるプレーヤにより復号化されたときに、フレーム記憶器におけるフレームがそのまま現れる様にするためである。
【0243】
動作補償は、動作評価の結果として生成されたブロックおよびベクトルを取り込むことにより実施される。結果は、付加的なテクスチャ情報を提供することにより実際のイメージに整合され得る符号化イメージの近似である。
【0244】
3.5.3.離散余弦変換
図3.5.に示されたエンコーダにより実施されるDCTおよび逆DCTは、ISO/IEC 14496-2:2001(E)、付属文書A.1(コーディング変換)において仕様を定められた規格に従う。
【0245】
3.5.3.1.変換の説明
DCTは、一群の空間領域データ点を周波数領域表現へと変換する方法である。ビデオ圧縮の場合には2次元DCTが、イメージ・ブロックを、冗長性が更に容易に利用され得る形態へと変換する。周波数領域ブロックは、エントロピ・コーディングにより容易に圧縮される疎(まば)らな行列であり得る。
【0246】
3.5.3.2.変換に対する心理視覚的強化
DCT係数は、人的視認者に対して容易に明らかである領域における量子化ノイズを減少することにより量子化イメージの品質を改善すべく改変され得る。これに加え、人的視認者により容易には認識され得ないイメージの部分における量子化ノイズは増加することにより、ファイル・サイズは減少され得る。
【0247】
本発明の実施例によるエンコーダは、「低速」心理視覚的強化と称されるものを実施し得る。「低速」心理視覚的強化は、ビデオ・イメージの各ブロックを分析し、かつ、そこにおける一定のノイズを許容するとビデオの外観を劣化させずに一定のビットを節約し得るか否かを判断するものである。その処理は、ブロック毎に1つの測定値を使用する。その処理は「低速」処理と称される、と言うのも、それは相当量の演算を実施してブロッキング(blocking)またはリンギング(ringing)アーチファクトを回避するからである。
【0248】
本発明の実施例によるエンコーダの他の実施例は、「高速」心理視覚的強化を実施する。その「高速」心理視覚的強化は、ブロック内でノイズが出現して量子化ノイズを形状化し得る箇所を制御し得る。
【0249】
「低速」および「高速」心理視覚的強化の両方が、以下においてより詳細に論じられる。本発明の実施例に依れば、イメージエッジ部におけるノイズを制御する処理であって人間の視覚に対して容易に明らかではないイメージの領域において更に高レベルの量子化ノイズを集中しようとする処理などの心理視覚的強化が実施され得る。
【0250】
3.5.3.3.「低速」心理視覚的強化
「低速」心理視覚的強化は、ビデオ・イメージの各ブロックを分析し、一定のノイズを許容するとビデオの外観を劣化させずにビットが節約され得るか否かを決定する。一実施例においてアルゴリズムは、2つの段階を含む。第1段階は、入力された輝度ピクセルに対する差分イメージ(differentiated image)の生成を含む。差分イメージは、以下に記述される様式で生成される。第2段階は、量子化に先立ちDCT係数を改変する段階を含む。
【0251】
3.5.3.3.1.差分イメージの生成
差分イメージの各ピクセルp’xyは、非圧縮のソース・ピクセルpxyから、以下に従い算出される。
【0252】
【数1】
【0253】
式中、p’xyは(8ビットのビデオを仮定すると)0〜255の範囲である。
【0254】
3.5.3.3.2.DCT係数の改変
DCT係数の改変は、ブロック・リンギング係数の算出、ブロック・エネルギの算出、および、係数値の実際の改変を包含し得る。
【0255】
3.5.3.3.3.ブロック・リンギング係数の算出
イメージの各ブロックに対し、「リンギング係数(ringing factor)」は差分イメージのローカル領域に基いて算出される。ブロックが8×8ブロックとして定義される実施例において、リンギング係数は以下の方法を用いて決定され得る。
【0256】
最初に、8×8ブロック内における最大および最小の輝度ピクセル値に基づき、閾値が決定される。
thresholdblock=floor((maxblock−minblock)/8)+2
【0257】
差分イメージおよび閾値は、ブロックの近傍における「フラット(flat)」ピクセルのマップを生成すべく用いられる。各ブロックが異なる閾値を有する可能性は、フレーム全体に対するフラット・ピクセルのマップの生成を阻害する。マップは以下の如く生成される。
flatxy=1 p’xy<thresholdblockのとき
flatxy=0 それ以外
【0258】
フラット・ピクセルのマップは、単純な論理演算に従いフィルタリングされる。
flat’xy=1 flatxy=1 flatx-1y=1 flatxy-1=1 flatx-1y-1=1
flat’xy それ以外
【0259】
フィルタリングされたマップにおけるフラット・ピクセルは次に、その8×8ブロックをカバーする9×9領域の全体に亙りカウントされる。
【0260】
0=x=8および0=y=8に対し、
【0261】
【数2】
【0262】
視認可能なリンギング・アーチファクトのリスクは、以下の式を用いて評価され得る。
ringingbriskblock=((flatcountblock−10)x256+20)/40
【0263】
次に、以下の式を用いて8×8ブロックのリンギング係数が導出され得る。
Ringingfactor=0 ringingrisk>255のとき
=255 ringingrisk<0のとき
=255−ringingrisk その他の場合
【0264】
3.5.3.3.4.ブロック・エネルギの算出
イメージのブロックに対するエネルギは、以下の手順を用いて計算され得る。
【0265】
ソース・イメージに対して順方向DCTが実施される。
T=fDCT(S)
式中、Sは問題となる8×8ブロックの64個のソース・イメージ輝度値であり、かつ、Tはソース・イメージの同一部分の変換バージョンである。
【0266】
特定の係数位置におけるエネルギは、その係数の値の二乗として定義される。
0=k=63に対し、ek=tk2
【0267】
式中、tkは変換されたブロックTの第k番目の係数である。
【0268】
3.5.3.3.5.係数の改変
DCT係数の改変は、以下の処理に従い実施され得る。幾つかの実施例においてその処理は、量子化の前に、全ての非ゼロのAC DCT係数に対して実施される。各係数の大きさは、心理視覚的技術に従い決定された小さなデルタだけ変化せしめられる。
【0269】
非ゼロAC係数ckの各々のDCT係数改変は、以下の式を用いてローカルおよびブロック・エネルギに基づくエネルギを計算することで実施される。
【0270】
energyk=max(ak × ek,0.12 × totalenergy)
【0271】
式中、akは、以下の表に記述された係数位置に値が依存する定数である。
【0272】
【表5】
【0273】
エネルギは、以下の関係を用いてブロックのリンギング係数に従い改変され得る。
energy’k=ringingfactor × energyk
【0274】
結果的な値は、ルックアップ・テーブル(LUT)に対する入力として使用される前にシフトかつクリップされる。
ek=min(1023,4×energy’k)
dk=LUTi そこで i=ek
【0275】
ルックアップ・テーブルは、以下の如く算出される。
【0276】
【数3】
【0277】
また以下の表に記述された様に値「オフセット(offset)」は、量子化数Qpに依存する。
【0278】
【表6】
【0279】
変数ktextureおよびkflatは夫々、フラットな領域およびテクスチャ化された領域における心理視覚的効果の強さを制御する。一実施例においてそれらは0〜1の範囲の値を取り、0は効果なしを意味しかつ1は完全効果を意味する。一実施例においてktextureおよびkflatに対する値は以下の如く確立される。
【0280】
輝度: ktexture=1.0
: kflat=1.0
色度: kflat=1.0
: kflat=0.0
【0281】
検索テーブル(lookup table)からの出力(dk)は、以下の付加的プロセスによりDCT係数の大きさを改変すべく用いられる。
【0282】
c’k=ck−min(dk,|ck|) x sgn(ck)
最後に、DCT係数ckは、改変された係数c’kにより置換され、量子化のために前送りされる。
【0283】
3.5.3.4.「高速」心理視覚的強化
「高速」心理視覚的強化は、入力輝度ピクセルに対する「重要性」マップを算出してからDCT係数を改変することにより、DCT係数に関して実施され得る。
【0284】
3.5.3.4.1.「重要性」マップの算出方法
「重要性」マップは、入力ビデオ・フレームの輝度箇所における各ピクセルに対して「重要性」値を計算することにより生成され得る。幾つかの実施例において「重要性」値は、その特定のピクセルに配置された一切の歪曲に対する人間の目の感度を近似する。「重要性」マップは、ピクセルの「重要性」値の配列である。
【0285】
ピクセルの「重要性」は、ピクセル(dxy)の周りのピクセルのブロックのダイナミック・レンジを先ず計算することにより決定され得る。幾つかの実施例において、ピクセル箇所(x,y)に中心合わせされた3×3ブロックのダイナミック・レンジは、その領域において最も暗いピクセルの値を、その領域において最も明るいピクセルの値から減算することで算出される。
【0286】
ピクセル(mxy)の「重要性」は、以下の如く、そのピクセルのダイナミック・レンジから導出され得る。
mxy=0.08/max(dxy,3)+0.001
【0287】
3.5.3.4.2.DCT係数の改変方法
一実施例においてDCT係数の改変は、基底関数のエネルギ行列およびデルタ・ルックアップ・テーブルの生成を含む。
【0288】
3.5.3.4.3.基底関数のエネルギ行列の生成
DCT係数を改変する際には、一群の基底関数エネルギ行列が使用され得る。これらの行列は、符号化に先立ち算出され得る定数値を含む。64個のDCT基底関数の各々に対しては、8×8行列が用いられる。各行列は、8×8ブロックにおける全てのピクセルがその対応係数の改変により如何に影響されるかを記述する。第k番目の基底関数エネルギ行列は、100に設定された対応係数と0に設定された他の係数とを有する8×8行列Akを採用することにより導出される。
【0289】
akn=100 n=kの場合
=0 それ以外
式中、nは8×8行列内における係数の位置を表す。0=n=63
逆DCTは行列に関して実施され、更なる8×8行列A’kが生成される。行列の要素(a’kn)は、第k番目のDCT基底関数を表す。
【0290】
A’k=iDCT(Ak)
変換された行列における各値は次に二乗される。
0=n=63に対して、bkn=a’kn2
【0291】
処理は64回実施され、各々が64個の自然数を備える、0=k=63である基底関数エネルギ行列Bkが生成される。各行列値は、8×8ブロックにおける第n番目の位置におけるピクセルが係数kの任意のエラーまたは改変により如何に影響されるかの尺度である。
【0292】
3.5.3.4.4デルタ・ルックアップ・テーブルの生成
係数改変デルタの算出を促進すべく、ルックアップ・テーブル(LUT)が使用され得る。そのテーブルの内容は、「高速」心理視覚的強化の所望の強度と量子化数・パラメータ(Qp)とに依存する様式で生成され得る。
【0293】
ルックアップ・テーブルの値は、次の関係に従い生成され得る。
【0294】
【数4】
【0295】
式中、iはテーブルにおける位置であり、0=i=1023である。
【0296】
以下のテーブルに記述された如く、strength、およびoffsetは、量子化数(Quantizer)Qpに依存する。
【0297】
【表7】
【0298】
変数ktextureおよびkflatは夫々、フラットな領域およびテクスチャ化された領域における心理視覚的効果の強さを制御する。一実施例においてそれらは0〜1の範囲の値を取り、0は効果なしを意味しかつ1は完全効果を意味する。一実施例においてktextureおよびkflatに対する値は以下の如く確立される。
【0299】
輝度: ktexture=1.0
: kflat=1.0
色度: kflat=1.0
: kflat=0.0
【0300】
3.5.3.4.5.DCT係数の改変
DCT係数は、で計算された値を用いて改変され得る。一実施例において各非ゼロAC DCT係数は、量子化に先立ち以下の手順に従い改変される。
【0301】
最初に「エネルギ」値(ek)は、対応する基底関数エネルギ行列と、重要性マップからの適切な8×8ブロックとの内積を取ることにより算出される。この「エネルギ」は、特定係数における量子化エラーが人的視認者により如何に認識されるかの尺度である。それは、ピクセル重要性とピクセル基底関数エネルギとの積の合計である。
【0302】
ek=M・Bk
式中、
Mは8×8ブロックの重要性マップ値であり、かつ、
Bkは第k番目の基底関数エネルギ行列である。
【0303】
結果的な「エネルギ」値は、デルタ・ルックアップ・テーブルへのインデックス(dk)として使用される前に、シフトかつクリップされる。
【0304】
ek=min[1023, floor(ek/32768)]
dk=LUTi
そこで、i=e’k
【0305】
デルタ・ルックアップ・テーブルの出力は、付加的プロセスによりDCT係数の大きさを改変すべく用いられる。
【0306】
c’k=ck−min(dk,|ck|)×sign(ck)
【0307】
DCT係数ckは、改変されたc’kにより置換されて、量子化のために前送りされる。
【0308】
3.5.4.量子化
本発明の実施例によるエンコーダは、1996年のITU−T勧告H.263、低ビットレート通信に対するビデオ・コーディングとして国際電気通信連合により策定された量子化器などの標準的な量子化器を使用し得る。
【0309】
3.5.4.1.量子化に対する心理視覚的強化
本発明の実施例による幾つかのエンコーダは、人間の視覚の心理的効果を利用して更に効率的な圧縮を達成する心理視覚的強化を使用する。心理視覚的効果は、フレーム・レベルおよびマクロブロック・レベルで適用され得る。
【0310】
3.5.4.2.フレーム・レベルの心理視覚的強化
フレーム・レベルにて適用されたとき、その強化は速度制御アルゴリズムの一部であり、その目標は、人間の目により認識される最高の視覚的品質を確実にすべく所定量のビットレートが最適に使用される様に符号化方法を調節することである。フレーム速度の心理視覚的強化は、動作が早いときに人間の視覚は詳細を無視する傾向がありかつ人間の視覚はイメージが静止的であるときに詳細に注目する傾向があるという理論により動機付けられる。一実施例において動作の量は、フレームに対する絶対的差の合計(SAD)を調べることで決定される。一実施例においてSAD値は、2つのブロックの共配置された輝度ピクセルの絶対的差を合計することにより決定される。幾つかの実施例においては、16×16ピクセル・ブロックの絶対的差が用いられる。部分的ピクセル・オフセットを取り扱う実施例においては、絶対的差の合計が計算される前に、MPEG-4規格(ISO/IECの動画専門委員会により開発されたISO/IEC規格)において仕様を定められた様に、内挿が実施される。
【0311】
フレーム・レベルの心理視覚的強化はビデオ・トラックのPフレームに対してのみその当し、そのフレームのSAD値に基づく。符号化の間に心理視覚的モジュールは、ビデオ・トラックのPフレームの全ての平均SAD(すなわち^SAD)と、各フレームの全体的SADからの各フレームのSADの平均距離(すなわち^DSAD)との記録を維持する。平均化は、指数移動平均アルゴリズムを用いて行われ得る。一実施例においては、上述のワンパス速度制御アルゴリズムが此処での平均化期間(averaging period)として使用され得る。
【0312】
符号化されたビデオ・トラックの各Pフレームに対し、(速度制御モジュールから獲得された)フレーム・量子化数Qは、それに適用される心理視覚的補正値を有する。一実施例においてプロセスは、以下の式を用いて比率Rを計算する段階を包含する。
【0313】
【数5】
【0314】
式中、Iは定数でありかつ現在は0.5に設定される。Rは[−1, 1]の境界内に短縮される。
【0315】
量子化数は次に、比率Rに従い、以下に示される計算を介して調節される。
【0316】
【数6】
【0317】
式中、Sframeはフレーム・レベル心理視覚的強化に対する強度定数である。
【0318】
Sframe定数は、フレーム・レベル心理視覚に対して調節が如何に強力であり得るかを決定する。コーデックの一実施例においては、Sframeを0.2、0.3または0.4に設定するオプションが利用可能である。
【0319】
3.5.4.3.マクロブロック・レベルの心理視覚的強化
マクロブロック・レベルで心理視覚的強化を利用する本発明の実施例によるエンコーダは、人的視認者に対するビデオの視覚的品質に対して目立つマクロブロックを識別することを試行すると共に、これらのマクロブロックを更に高品質でコード化することを試行する。マクロブロック・レベルの心理視覚的強化の効果は、フレームに対して重要さが少ない部分からビットを取り去り、それらを、フレームの更に重要な部分に適用することである。幾つかの実施例においては、円滑度、明るさ、および、マクロブロックSADに基づく3つの技術を用いて達成される。他の実施例においては、技術の内の任意のひとつの技術がそれのみで、もしくは、技術の別のものと組み合わされて、または、完全に別の技術が使用され得る。
【0320】
一実施例においては、上述の3通りのマクロブロック・レベルの心理視覚的強化の全てが、マクロブロック・レベルの心理視覚的強化の強度を制御する共通パラメータSMBを共有する。次に、各マクロブロックに対する最大および最小の量子化数が、以下に示される計算を介して強度パラメータおよびフレーム・量子化数Qframeから導出される。
【0321】
【数7】
【0322】
値QMBMaxは、最大量子化数であり、値QMBMaxは、最小量子化数である。
値QMBMaxおよびQMBMaxは、フレーム全体に対するマクロブロック・量子化数に対する上下の境界を定義する。一実施例においては、値SMBを値0.2、0.3および0.4の内の任意の値に設定するオプションが提供される。他の実施例においては、SMBに対する他の値が利用され得る。
【0323】
3.5.4.3.1.明るさ強化
心理視覚的強化がマクロブロックの明るさに基づいて実施される実施例において、エンコーダは更に明るいマクロブロックを更なる高品質で符号化することを試行する。この強化の理論的根拠は、フレームの比較的に暗い部分は人的視認者により概略的に無視されるということである。このマクロブロックの心理視覚的強化は、ビデオ・トラックのIフレームおよびPフレームに対して適用される。各フレームに対してエンコーダは、最初にフレーム全体を一覧する。平均明るさ(^BR)が計算され、かつ、平均からの明るさの平均差(^DBR)も計算される。これらの値は次に、心理視覚的強化が適用されるべきか否かに対するインディケータとして使用され得る2つの閾値(TBRLower,TBRUpper)を作成すべく用いられる。
【0324】
【数8】
【0325】
明るさ強化は次に、以下に述べられる条件を用いて2つの閾値に基づいて適用され、マクロブロックに対して意図された量子化数(QMB)が生成される。
QMB=QMBMin BR>TBRUpperのとき、
QMB=Qframe TBRLower≦BR≦TBRUpperのとき、および、
QMB=QMBMax BR<TBRLowerのとき;
式中、BRはその特定のマクロブロックに対する明るさ値である。式中、BRはその特定のマクロブロックに対する明るさ値である。
【0326】
エンコーダがMPEG−4規格に準拠するという実施例において、マクロブロック・レベルの心理視覚的明るさ強化技術は、ひとつのマクロブロックから次のマクロブロックにかけて±2より多く量子化数を変更し得ない。故に計算されたQMBは、先行するマクロブロックにおいて使用された量子化数に基づく改変を必要とし得る。
【0327】
3.5.4.3.2.円滑度強化
円滑度の心理視覚的強化を含む本発明の実施例によるエンコーダは、符号化されつつあるイメージの空間的変動に基づき量子化数を改変する。円滑度の心理視覚的強化の使用は、人間の視覚はイメージの円滑部分における量子化アーチファクトに対して大きな感度を有するという理論により動機付けられ得る。故に円滑度の心理視覚的強化は、イメージの更に円滑な部分を表すビットの個数を増大すると共にイメージの空間的変動の度合いが高い箇所ではビットの個数を減少するというステップを含む。
【0328】
一実施例においてイメージの一部分の円滑度は、マクロブロックの明るさ(brightness)に対するそのマクロブロックのピクセルの輝度(luminance)における平均差(^DR)として測定される。図3.6.には、本発明の実施例に従いIフレームに対して円滑度の心理視覚的強化を実施する方法が示される。プロセス540は、フレーム全体を検証して^DRを計算(542)するステップを含む。次に、円滑度強化TDRを適用する閾値は、以下の計算を用いて導出(544)され得る。
【0329】
【数9】
【0330】
以下の円滑度強化は、閾値に基づいて実施(546)される。
QMB=Qframe DR≧TDRのとき、および、
QMB=QMBMin DR<TDRのとき。
式中、
QMBは、マクロブロックに対して意図された量子化数であり、
DRは、マクロブロックに対する偏差値(すなわち、平均輝度−平均明るさ)である。
MPEG−4規格に従いファイルを符号化する実施例は、上述された如く、マクロブロック・レベルの量子化数変化はひとつのマクロブロックから次のマクロブロックへと多くとも±2とされ得るという点において制限される。
【0331】
3.5.4.3.3.マクロブロックSAD強化
本発明の実施例によるエンコーダは、マクロブロックSAD心理視覚的強化を利用し得る。マクロブロックSAD心理視覚的強化は、静止的マクロブロックに対する詳細を高めると共に、速い動作のシーンで使用されるフレームの部分における詳細は低減させ得るべく使用され得る。図3.7.には、本発明の実施例に従いマクロブロックSAD心理視覚的強化を実施するプロセスが示される。プロセス570は、Iフレーム全体を検査(572)し、フレーム全体における全てのマクロブロックに対する平均SAD(すなわち^MBSAD)を決定する段階を含み、かつ、平均からのマクロブロックのSADの平均差(すなわち^DMBSAD)も求められる。一実施例においてはこれらのマクロブロックの両方が、フレーム間コード化されたマクロブロック(すなわち、動作補償、または、先行する符号化ビデオ・フレームに対する他の依存性を用いて符号化されたマクロブロック)の全体に亙り平均化される。次にこれらの平均から、以下の式を用いてマクロブロックSAD強化を適用する2つの閾値が導出(574)される。
【0332】
【数10】
【0333】
そこで、
TMBSADLowerは下側閾値であり、
TMBSADUpperは上側閾値であり、必要であればこれらは1024だけ境界付けられ得る。
【0334】
次にマクロブロックSAD強化はこれらの2つの閾値に基づき以下の条件に従い適用(576)される。
QMB=QMBMax MBSAD>TMBSADUpperのとき、
QMB=Qframe TMBSADLower≦MBSAD≦TMBSADUpperのとき、
QMB=QMBMin MBSAD<TMBSADLowerのとき。
そこで、
QMBはマクロブロックに対して意図された量子化数であり、
MBSADはその特定のマクロブロックに対するSAD値である。
【0335】
MPEG−4仕様に従いファイルを符号化する実施例は、上述された如く、マクロブロック・レベルの量子化数変化はひとつのマクロブロックから次のマクロブロックへと多くとも±2とされ得るという点において制限される。
【0336】
3.5.5.速度制御
本発明の実施例によるエンコーダにより使用される速度制御技術は、割当てられたビットレートをエンコーダが使用してビデオ・シーケンスを符号化する方法を決定し得る。エンコーダは典型的に所定ビットレートへと符号化することを目的とする共に、速度制御技術は、エンコーダにより生成されるビットレートを所定ビットレートに対して可及的に近付けて整合せねばならない。速度制御技術はまた、ビデオ・シーケンスが復号化されるときにそのビデオ・シーケンスの最高の視覚的品質を確実にする様式でビットレートを割当てることも目的とし得る。速度制御の多くは、量子化数を調節することにより実施される。量子化数は、エンコーダがビデオ・シーケンスを如何に精細にコード化するかを決定する。量子化数が小さいほど品質は高く、ビット消費が多くなる結果となる。故に速度制御アルゴリズムは、ビデオ品質およびビット消費という競合関係をバランスさせる様式で量子化数を改変することを目的とする。
【0337】
本発明の実施例によるエンコーダは、種々の異なる速度制御技術の内の任意の技術を利用し得る。一実施例においては、単一パス速度制御技術が用いられる。他の実施例においては、二重(もしくは多重)パス速度制御技術が用いられる。これに加え、必要に応じて「ビデオ・バッファ検証式」速度制御が実施され得る。これらの技術の特定例は、以下で論じられる。但し、本発明の実施方法に従うエンコーダにおいては任意の速度制御技術が使用され得る。
【0338】
3.5.5.1.ワンパス速度制御
本発明の実施例によるワンパス速度制御技術の実施例は、速い動作のシーンに対して高いビットレート・ピークを許容することを目的とする。幾つかの実施例においてワンパス速度制御技術は、シーンにおける動作の量の増大に応じてビットレートを徐々に増大すると共に、シーンにおける動作の減少に応じてビットレートを迅速に減少することを目的とする。
【0339】
一実施例においてワンパス速度制御アルゴリズムは、ビットレートを追尾すべく2つの平均化期間を用いる。長期平均は全体的なビットレート収束を確実にし、短期平均はシーンにおける動作の量の変動に対する応答を可能とする。
【0340】
図3.8.には、本発明の実施例によるワンパス速度制御技術が示される。ワンパス速度制御技術580は、所望のビットレート、ビデオ・フレーム速度および(以下において更に論じられる)種々の他のパラメータによりエンコーダを初期化(584)することにより開始(582)する。量子化数を表す浮動小数点変数が記憶される。もしフレームが量子化(586)を必要とするなら、浮動小数点変数が読み出され(588)、量子化数はその浮動小数点変数を最も近い整数に丸めることで求められる。フレームは次に符号化(590)される。フレームの符号化の間においては観察が為され、新たな量子化数値の決定(592)が可能とされる。プロセスは、更なるフレームが無くなるまで反復することを判断(594)する。その時点において、符号化は完了(596)する。
【0341】
で論じられた如くエンコーダは種々のパラメータにより初期化(584)される。これらのパラメータは、「ビットレート」、「フレーム速度」、「最大キー・フレーム間隔」、「最大量子化数」、「最小量子化数」、「平均化期間」、「反応期間」および「上/下比率」である。以下の内容は、これらのパラメータの各々に対する考察である。
【0342】
3.5.5.1.1.「ビットレート」
「ビットレート」パラメータは、符号化の目標ビットレートを設定する。
【0343】
3.5.5.1.2.「フレーム速度」
「フレーム速度」は、ビデオの各フレーム間の期間を定義する。
【0344】
3.5.5.1.3.「最大キー・フレーム間隔」
「最大キー・フレーム間隔」は、キー・フレーム間の最大間隔を特定する。キー・フレームは通常、コーデックがシーン変化を検出したときに、符号化ビデオに自動的に挿入される。シーンが単一カットなしで長い間隔に亙り継続的するという状況において、当該キー・フレーム間の間隔が常に「最大キー・フレーム間隔」以下であることを確実にすべくキー・フレームが挿入され得る。一実施例において「最大キー・フレーム間隔」パラメータは300フレームの値に設定され得る。他の実施例においては、他の値が使用され得る。
【0345】
3.5.5.1.4.「最大量子化数」および「最小量子化数」
「最大量子化数」および「最小量子化数」パラメータは、符号化において使用される量子化数の上下の境界を設定する。一実施例において量子化数境界は、1〜31の値に設定される。
【0346】
3.5.5.1.5.「平均化期間」
「平均化期間」パラメータは、量子化数を改変するときに考慮されるビデオの量を制御する。平均化期間が長いと、典型的には、更に正確な全体的速度を有する符号化ビデオに帰着する。一実施例においては2000の「平均化期間」が用いられる。但し、他の実施例においては他の値が使用され得る。
【0347】
3.5.5.1.6.「反応期間」
「反応期間」パラメータは、最近のシーンにおける動作の変化に対してエンコーダが如何に迅速に適合するかを決定する。「反応期間」値が長いと、品質は更に良好で速い動作のシーン、および、品質は更に低下して遅い動作のシーンに帰着する。一実施例においては、10の「反応期間」が用いられる。但し、他の実施例においては他の値が使用され得る。
【0348】
3.5.5.1.7.「上/下比率」
「上/下比率」パラメータは、速いまたは遅い動作のシーンに応じた量子化数調節に対する相対感度を制御する。大きな値は典型的に、高品質で速い動作のシーンおよび大きなビット消費に帰着する。一実施例においては20の「上/下比率」が用いられる。但し、他の実施例においては他の値が使用され得る。
【0349】
3.5.5.1.8.量子化数値の計算方法
で論じられた如くワンパス速度制御技術は、各フレームの符号化の後で量子化数値の計算を包含する。以下の内容は、量子化数値を更新すべく使用され得る本発明の実施例による技術の説明である。
【0350】
エンコーダは、ビットレートの移動平均の「平均化期間」(Paverage)および「反応期間」(Preaction)に等しい2つの指数的移動平均を維持する。その2つの指数的移動平均は以下の関係に従い計算され得る。
【0351】
【数11】
【0352】
そこで、
Atは瞬間tにおける平均であり、
At-1は瞬間t−Tにおける平均(通常は先行フレームにおける平均)であり、
Tは間隔期間(通常はフレーム時間)を表し、かつ、
Pは、Paverageおよび/またはPreactionとされ得る平均期間である。
【0353】
で計算された移動平均は次に、以下の計算を用いてビデオにおける現在の瞬間と最後の瞬間との間の時的間隔により除算されることで、ビットレートへと調節される。
【0354】
【数12】
【0355】
そこで、
Rtはビットレートであり、
Atは移動平均のいずれかであり、かつ、
Tは現在の瞬間と最後の瞬間との間の時的間隔(それは通常はフレーム速度の逆数)である。
【0356】
エンコーダは以下の如く、次のフレームの目標ビットレート(Rtarget)を計算し得る。
Rtarget = Roverall + (Roverall − Raverage)
そこで、
Roverallは、ビデオ全体に対して設定された全体的ビットレートであり、かつ、
Raverageは、長い平均化期間を用いる平均ビットレートである。
【0357】
幾つかの実施例において目標ビットレートは、全体的ビットレートの75%にて下方に境界付けられる。もし目標ビットレートが境界より低く低下したなら、それは境界の上方に押しやられ、ビデオの品質が確実とされる。
【0358】
エンコーダは次に、RtargetとRreactionとの間の差に基づいて内部量子化数を更新する。もしRreactionがRtargetより小さければ、先行フレームは比較的に複雑さが少なかった可能性が在る。故に量子化数は、以下の計算を実施することにより減少され得る。
【0359】
【数13】
【0360】
RreactionがRtargetより大きいとき、先行フレームは比較的に高レベルの複雑さを保有していた可能性が高い。故に量子化数は、以下の計算を実施することで増大され得る。
【0361】
【数14】
【0362】
式中、Sは「上/下比率」である。
【0363】
3.5.5.1.9.B−VOP符号化方法
上述のアルゴリズムは、B−VOP符号化方法に対しても適用され得る。符号化方法においてB−VOPが有効化されたとき、B−VOPに対する量子化数(QB)は、B−VOPに追随するP−VOPの量子化数(QP)に基づいて選択される。値は、次の関係に従い求められ得る。
QB=2・QP QP≦4の場合、
QB=5+(3/4)・QP 4<QP≦20の場合、
QB=QP QP≧20の場合。
【0364】
3.5.5.2.ツーパス速度制御
2回の(または複数回の)パスの速度制御を使用する本発明の実施例によるエンコーダは、第1のパスにおいてはビデオ・シーケンスのプロパティを決定してから、シーケンス全体のプロパティの知見を以てビデオ・シーケンスを符号化し得る。故にエンコーダは各フレームの量子化レベルを、ビデオ・シーケンスにおける他のフレームと比較した相対的な複雑さに基づいて調節し得る。
【0365】
本発明の実施例によるツーパス速度制御技術においてエンコーダは、ビデオは上述のワンパス速度制御技術に従い符号化されかつ各フレームの複雑さが記録される(複雑さを測定する種々の異なる測定値の内の任意のものが使用され得る)という第1のパスを実施する。平均の複雑さ、故に平均量子化数(Qref)は、第1のパスに基づいて決定され得る。
第2のパスにおいては、第1のパスの間に計算された複雑さの値に基づいて決定される量子化数を以て符号化される。
【0366】
3.5.5.2.1.I-VOPに対する量子化数
次のフレームがI−VOPでないとすれば、I−VOPに対する量子化数Qは0.75×Qrefに設定される。もし次のフレームもI−VOPであれば、(現在のフレームに対する)Qは1.25×Qrefに設定される。
【0367】
3.5.5.2.2.P−VOPに対する量子化数
P−VOPに対する量子化数は以下の式を用いて決定され得る。
【0368】
【数15】
【0369】
そこで、
Ccomplexityはフレームの複雑さであり、
^Ccomplexityはビデオ・シーケンスの平均の複雑さである。
F(x)は、量子化値xを有する量子化数を用いてフレームを符号化するために必要なビットの個数を与えるためにフレームの複雑さが乗算されるべき数を提供する関数である。F-1(x)はF(x)の逆関数であり、かつ、kは強度パラメータである。
【0370】
以下の表は、量子化数Qと共にエンコーダを用いてフレームを符号化するために必要なビットの個数を決定するためにフレームの複雑さと乗算されるべき係数を生成すべく使用され得る関数F(Q)の実施例を定義している。
【0371】
【表8】
【0372】
もし強度パラメータkがゼロに選択されるべきであれば、結果は一定の量子化数である。強度パラメータが1に選択されるべきとき、量子化数はCcomplexityに比例する。本発明の実施例による幾つかのエンコーダは、0.5に等しい強度パラメータkを有する。
【0373】
3.5.5.2.3.B−VOPに対する量子化数
B−VOPに対する量子化数Qは、上述のワンパス技術においてB−VOPに対する量子化数を選択したのと同一の技術を使用して選択され得る。
【0374】
3.5.5.3.ビデオ・バッファ照合式の速度制御
フレームを表すために必要なビットの個数は、ビデオ・シーケンスの特性に依存して変化し得る。殆どの通信システムは、一定のビットレートで動作する。可変的ビットレート通信が遭遇し得る問題は、リソース使用におけるピークを取り扱うために十分なリソースを割当てることである。本発明の実施例による幾つかのエンコーダは、可変的ビットレート通信のビットレートが急激に上昇するときにおけるデコーダのビデオ・バッファのオーバーフローを阻止する意図でビデオを符号化する。
【0375】
ビデオ・バッファ照合器(VBV)速度制御の目的としては、送信されたときにデコーダのバッファを超過しないビデオの生成が挙げられる。これに加え、符号化されたビデオは目標ビットレートと整合すること、および、速度制御により高品質ビデオが生成されることが望ましい。
【0376】
本発明の幾つかの実施例によるエンコーダは、少なくとも2つのVBV速度制御技術の選択肢を提供する。一方のVBV速度制御技術は因果的速度制御(causal rate control)と称され、他方の技術は第Nパス速度制御(Nth pass rate control)と称される。
【0377】
3.5.5.3.1.因果的速度制御
因果的なVBV速度制御は、ワンパス速度制御技術と組み合わせて使用され得ると共に、単に現在の量子化数値と先行量子化数値とに基づいて出力を生成する。
【0378】
本発明の実施例によるエンコーダは、以下の関係に従いフレームnに対する量子化数(すなわちQn)を設定する段階を包含する因果的速度制御を含む。
【0379】
【数16】
【0380】
式中、
Q’nは、単一パス速度制御により評価された量子化数であり、
Xbitrateは、所望ビットレートからのドリフトに基づき目標ビットレートを決定することにより計算され、
Xvelocityは、VBVバッファがオーバーフローまたはアンダーフローするまでの見積もり時間に基づき計算され、
Xsizeは、P−VOPの結果のみに適用され、かつ、圧縮されたP−VOPのサイズが経時的に変化する速度に基づいて計算され、
Xdriftは、所望ビットレートからのドリフトである。
【0381】
幾つかの実施例において因果的VBV速度制御は、フレームを脱落させると共に補充物を挿入してVBVモデルを顧慮することを強いられ得る。もし、圧縮されたフレームが意外に多すぎるまたは少なすぎるビットを含むなら、それは除外もしくは補充され得る。
【0382】
3.5.5.3.2.第NパスVBV速度制御
第NパスVBV速度制御は、多重パス速度制御技術と組み合わせて使用され得ると共に、それは、ビデオ・シーケンスの先行分析の間に生成された情報を使用する。本発明の幾つかの実施例によるエンコーダは、図3.9.に示された処理に従い第NパスVBV速度制御を実施する。処理600は第1パスで開始し、その間に分析(602)が実施される。マップ生成が実施(604)され、かつ、方針が生成(606)される。次に、第nパス速度制御が実施(608)される。
【0383】
3.5.5.3.3.分析
一実施例において、第1のパスは一定形態の因果的速度制御を使用し、かつ、データは、フレームの持続時間、フレームのコード化形式、使用される量子化数、生成される動作ビット、および、生成されたテクスチャ・ビットなどの事項に関して各フレームに対して記録される。これに加え、時間目盛、解像度およびコーデック設定などの包括的情報も記録され得る。
【0384】
3.5.5.3.4.マップ生成
分析からの情報は、ビデオ・シーケンスのマップを生成すべく用いられる。そのマップは、各フレーム(I/B/P)に対して使用されたコード化形式を特定し得ると共に、フレームの持続時間、動作の複雑さおよびテクスチャの複雑さに関して各フレームに対するデータを含み得る。他の実施例においてそのマップは、圧縮されたフレーム・サイズおよび認識的歪曲に対する量子化数および他のパラメータの影響の更に良好な予測を可能とする情報も含み得る。幾つかの実施例において、マップ生成は第N-1パスが完了した後で実施される。
【0385】
3.5.5.3.5.方針作成
マップは、第Nパス速度制御が如何に動作するかに関する方針を計画するために使用され得る。各フレームが符号化された後におけるVBVバッファの理想的レベルが、計画され得る。一実施例において方針を作成すると、所望の圧縮フレーム・サイズ、見積もられたフレーム・量子化数を含め、各フレームに対する情報に帰着する。幾つかの実施例において方針作成は、マップ生成の後で第Nパスに先立って実施される。
【0386】
一実施例において方針作成プロセスは、エンコーダをシミュレートする反復的プロセスであって、可及的に量子化数の中央値に近く量子化数の維持を試行することにより各フレームに対する所望の量子化数値を決定する反復的プロセスを使用する段階を包含する。ビデオ・シーケンス全体に対する基礎量子化数を生成すべく、2進検索が使用され得る。基礎量子化数は、シミュレータに対して所望の目標ビットレートを達成させる一定値である。基礎量子化数が一旦見出されたなら、方針作成プロセスは、VBV制約を考慮する段階を包含する。一実施例において、当該一定の量子化数がVBV制約を改変しないのであれば、一定の量子化数が用いられる。他の実施例において量子化数は、ビデオ・フレームにおける動作の複雑さに基づいて変調される。これは更に、シーン変化および他の一時的効果からのマスキングの取入れへと拡張され得る。
【0387】
3.5.5.3.6.インループ第Nパス速度制御
一実施例において、インループ(in-loop)第Nパス速度制御は方針を使用すると共にマップを使用して、圧縮フレーム・サイズおよび認識的歪曲に関する量子化数および他のパラメータの影響の最適な可能的予測を行う。短期補正方針を採用すべく方針から逸脱する自由裁量は、限られ得る。典型的には、方針に追随すると、VBVモデルからの逸脱は防止される。一実施例においてループ内における第Nパス速度制御は、PID制御ループを使用する。その制御ループにおけるフィードバックは、理想的ビットレートからの蓄積ドリフトである。
【0388】
方針作成はフレームの脱落を伴わないが、VBVバッファが別様にアンダーフローするならば、ループ内における第N速度制御はフレームを脱落させることもある。同様に、ループ内における第Nパス速度制御はVBVオーバーフローを防止すべく、ビデオ補充物の挿入を要求し得る。
【0389】
3.5.6.予測
一実施例においては、ISO/IEC 14496-2:2001(E)、セクション7.4.3.(DCおよびAC予測)および7.7.1.(フィールドDCおよびAC予測)と称される規格に準拠する様式でAD/DC予測が実施される。
【0390】
3.5.7.テクスチャ・コーディング
本発明の実施例によるエンコーダは、ISO/IEC 14496-2:2001(E)、付属文書B(可変長コード)および7.4.1.(可変長復号化)と称される規格に準拠する様式でテクスチャ・コーディングを実施し得る。
【0391】
3.5.8.動作コーディング
本発明の実施例によるエンコーダは、ISO/IEC 14496-2:2001(E)、付属文書B(可変長コード)および7.6.3.(動作ベクトル復号化)と称される規格に準拠する様式で動作コーディングを実施し得る。
【0392】
3.5.9.「ビデオ」チャンクの生成方法
ビデオ・トラックは、フレーム1〜Nのシーケンスと見做され得る。本発明の実施例によるシステムは、シーケンスを復号化して圧縮ビットストリームを生成し得る。そのビットストリームは、それをチャンク1〜Nにセグメント化することによりフォーマットされる。各ビデオ・フレームnは、対応するチャンクnを有する。
【0393】
各チャンクは、本発明の実施例によるデコーダがビデオ・フレームnを復号化するに十分な情報を、チャンクnがチャンク1〜n-1と共に含むまで、ビットストリームからのビットをそのチャンクnに追加することにより生成される。ビデオ・フレームnを生成するに十分な情報がチャンク1〜n-1に含まれた場合、本発明の実施例によるエンコーダはマーカ・チャンクを含み得る。一実施例においてそのマーカ・チャンクは、コード化されていないPフレームであって先行フレームと同一のタイミング情報を備えたPフレームである。
【0394】
3.6,「subtitle」チャンクの生成方法
本発明の実施例によるエンコーダは、一連の標準的フォーマットの内のひとつのフォーマットでサブタイトルを取り込んでから、そのサブタイトルをビットマップへと変換し得る。そのビットマップにおける情報は次に、ランレングス符号化方法を用いて圧縮される。ランレングス符号化されたビットマップはフォーマットされてチャンクとされるが、これは、そのチャンク内に含まれた特定サブタイトルに対する開始時間および停止時間に関する情報も含んでいる。幾つかの実施例においては、画面上におけるサブタイトルの色、サイズおよび位置に関する情報もチャンク内に含まれ得る。チャンクは、サブタイトルに対するパレットを設定するサブタイトルトラックであってそのパレットが変更されたことを表すサブタイトルトラックへと含まれ得る。サブタイトルのテキストを生成するためには、標準的なサブタイトル・フォーマットでサブタイトルを生成し得る任意のアプリケーションが使用され得る。代替的に、ユーザにより入力されたテキストを直接的にサブタイトル情報へと変換するソフトウェアが使用され得る。
【0395】
3.7.交互配置方法
上述のチャンクの全てをインタリーバが一旦受信したなら、そのインタリーバはマルチメディア・ファイルを構築する。マルチメディア・ファイルの構築は、「CSET」チャンク、「INFO」リスト・チャンク、「hdrl」チャンク、「movi」リスト・チャンクおよびidxlチャンクを生成する段階を包含し得る。これらのチャンクを生成してマルチメディア・ファイルを生成する本発明の実施例による方法は、以下に記述される。
【0396】
3.7.1.「CSET」チャンクの生成方法
上述された如く「CSET」チャンクは選択的であり、かつ、AVIコンテナ・フォーマット仕様に従いインタリーバにより生成され得る。
【0397】
3.7.2.「INFO」リスト・チャンクの生成方法
上述された如く「INFO」リスト・チャンクは選択的であり、かつ、AVIコンテナ・フォーマット仕様に従いインタリーバにより生成され得る。
【0398】
3.7.3.「hdrl」リスト・チャンクの生成方法
「hdrl」リスト・チャンクは、インタリーバに対して提供される種々のチャンクにおける情報に基づき、そのインタリーバにより生成される。「hdrl」リスト・チャンクは、参照されたチャンクのリスト内の箇所を参照する。一実施例において「hdrl」リスト・チャンクは、リファレンスを確立するためにファイル・オフセットを使用する。
【0399】
3.7.4.「movi」リスト・チャンクの生成方法
上述された如く「movi」リスト・チャンクはオーディオ、ビデオおよびサブタイトルトラックを符号化して「オーディオ」、「ビデオ」および「subtitle」チャンクを生成してからこれらのチャンクを交互配置することにより生成される。幾つかの実施例において「movi」リスト・チャンクは、デジタル著作権管理情報も含み得る。
【0400】
3.7.4.1.ビデオ/オーディオ/サブタイトルの交互配置方法
オーディオ、ビデオおよびサブタイトル・チャンクを交互配置するために、種々の規則が使用され得る。典型的にインタリーバは、ビデオおよびオーディオ・トラックの各々に対して所定数の待ち行列(queue)を確立する。そのインタリーバは、どの待ち行列が出力ファイルに書き込まれるべきかを決定する。待ち行列選択は、最低数の被書き込み交互配置期間を有する待ち行列から書き込むことにより、交互配置期間に基づき得る。インタリーバは、チャンクがファイルに対して書き込まれ得る前に、待ち行列内に存在する交互配置期間全体を待機すべきこともある。
【0401】
一実施例において、生成された「オーディオ」、「ビデオ」および「subtitle」チャンクは、当該「ビデオ」チャンクが対応するビデオ・フレームに関する情報を含む「ビデオ」チャンクに先立ち「オーディオ」および「subtitle」チャンクがファイル内に配置される様に交互配置される。他の実施例において「オーディオ」および「subtitle」チャンクは、それらが対応する「ビデオ」チャンクの後に配置され得る。「オーディオ」、「ビデオ」および「subtitle」チャンクの箇所間の時間差は、デバイスを再生するために使用されるプレーヤのバッファ能力に大きく依存する。バファリングが制限されもしくは未知である実施例においてインタリーバは、「オーディオ」および「subtitle」チャンクが「ビデオ」チャンクの間に配置される如く「オーディオ」、「ビデオ」および「subtitle」チャンクを交互配置し、その場合、「オーディオ」および「subtitle」チャンクの直後に追随する「ビデオ」チャンクは、そのオーディオもしくはサブタイトルに対応する最初のビデオ・フレームを含む。
【0402】
3.7.4.2.DRM情報の生成方法
マルチメディア・ファイルのビデオ内容を保護すべくDRMが使用される実施例において、DRM情報はビデオ・チャンクの符号化と同時的に生成され得る。各チャンクが生成されるにつれ、そのチャンクは暗号化され得ると共に、ビデオ・チャンクの暗号化に関する情報を含むDRMチャンクが生成され得る。
【0403】
3.7.4.3.DRM情報の交互配置方法
本発明の実施例によるインタリーバは、ビデオ・チャンクに先立ち、ビデオ・チャンクの暗号化に関する情報を含むDRMチャンクを交互配置する。一実施例において、ビデオ・チャンクnに対するDRMチャンクはビデオ・チャンクn-1およびビデオ・チャンクnの間に配置される。他の実施例において、ビデオ・チャンクnの前後におけるDRMの間隔は、マルチメディア・ファイルを復号化するデバイス内に配備されたバファリングの量に依存する。
【0404】
3.7.5.「idxl」チャンクの生成方法
「movi」チャンクが生成されたなら、「idxl」チャンクの生成は単純なプロセスである。「idxl」チャンクは、「movi」リスト・チャンク内での各「data」チャンクの位置を読み取ることで生成される。この情報は、「data」チャンクから読み取られた情報であってその「data」チャンクが属するトラックに関する情報と、その「data」チャンクの内容とに対して組み合わされる。この情報の全ては次に、上述のフォーマットのいずれであれ、情報を表すべく使用されているフォーマットに対して適切な様式で「idxl」チャンク内に挿入される。
【0405】
4.マルチメディア・ファイルの送信および配信
マルチメディア・ファイルが生成されたなら、そのファイルは種々のネットワークの内の任意のネットワークに亙り配信され得る。多くの実施例において特に、マルチメディア・プレゼンテーションおよびメニューを生成するために必要な要素は単一ファイル内に含まれるという事実により、情報の転送が簡素化される。幾つかの実施例においてマルチメディア・ファイルは、そのマルチメディア・ファイルの内容を復号化するに必要な情報とは別体的に配信され得る。
【0406】
一実施例においてマルチメディア内容は、第1サーバに提供されると共に、符号化されて本発明によるマルチメディア・ファイルを生成する。そのマルチメディア・ファイルは次に、第1サーバまたは第2サーバのいずれかに配置され得る。他の実施例においては、第1サーバ、第2サーバまたは第3サーバにDRM情報が配置され得る。一実施例において第1サーバは、符号化されたマルチメディア・ファイルの箇所を確認すべく、および/または、DRM情報の箇所を確認すべく、照会され得る。
【0407】
5.マルチメディア・ファイルの復号化方法
本発明の実施例によるマルチメディア・ファイルからの情報は、適切なソフトウェアと、マルチメディア・ファイルから情報をアクセスすべくハード結線された専用プレーヤまたはAVIファイルを解析し得る他の任意のデバイスとを用いて構成されたコンピュータによりアクセスされ得る。幾つかの実施例においてデバイスは、マルチメディア・ファイル内の全ての情報にアクセスし得る。他の実施例においてデバイスは、本発明の実施例によるマルチメディア・ファイル内の全ての情報にアクセスし得なくても良い。特定実施例においてデバイスは、上述の情報であってAVIファイル・フォーマットにおいて仕様を定められていないチャンク内に記憶された情報のいずれにもアクセスし得ない。情報の全てがアクセスはされ得ない実施例において、当該デバイスは典型的に、そのデバイスにより認識されないチャンクを切り捨てる。
【0408】
典型的に、本発明の実施例によるマルチメディア・ファイルに含まれた情報にアクセスし得るデバイスは、多数の機能を実施し得る。そのデバイスは、ビデオの表示を含むマルチメディア・プレゼンテーションを視覚的ディスプレイ上に表示し、可能的には多数のオーディオ・トラックの内のひとつのトラックからのオーディオをオーディオ・システム上に生成し、かつ、可能的には多数のサブタイトルトラックの内のひとつのトラックからのサブタイトルを表示し得る。幾つかの実施例は、付随するオーディオおよび/またはビデオを再生する一方、視覚的ディスプレイ上にメニューも表示し得る。これらの表示メニューは、選択可能なボタン、プルダウン・メニューおよび下位メニューなどの特徴により、インタラクティブである。一定の実施例においてメニュー項目は、現在においてアクセスされているマルチメディア・ファイル以外のオーディオ/ビデオ・コンテンツを指し示し得る。外部コンテンツは、マルチメディア・ファイルにアクセスしているデバイスに対してローカル的に配置され得るか、または、それはローカル・エリア・ネットワーク、広域ネットワークまたは公衆回線網などを介して遠隔的に配置され得る。また多くの実施例は、単一もしくは複数のマルチメディア・ファイル内に含まれる「メタデータ」、または、ひとつ以上のマルチメディア・ファイルにより参照された「メタデータ」に従い、ひとつ以上のマルチメディア・ファイルを検索することも可能である。
【0409】
5.1.マルチメディア・プレゼンテーションの表示
本発明の実施例によるマルチメディア・ファイルの能力であって複数のオーディオ・トラック、複数のビデオ・トラックおよび複数のサブタイトルトラックをサポートする能力が与えられたなら、ビデオ、オーディオおよび/またはサブタイトルを組み合わせたマルチメディア・ファイルを用いるマルチメディア・プレゼンテーションを表示するためには、視覚的メニュー・システムもしくはプルダウン・メニュー・システム(その動作は以下で論じられる)により、または、マルチメディア・プレゼンテーションを生成すべく使用されるデバイスの既定設定を介し、特定のオーディオ・トラック、ビデオ・トラックおよび/またはサブタイトルトラックを選択する必要があり得る。オーディオ・トラック、ビデオ・トラックおよび可能的にはサブタイトルトラックが選択されたなら、マルチメディア・プレゼンテーションの表示が進展し得る。
【0410】
図4.0.には、マルチメディア・ファイルからDRMを含む必要なマルチメディア情報を位置決定すると共にマルチメディア情報を表示する本発明の実施例によるプロセスが示される。処理620は、DRMヘッダを復号化するに必要な暗号化キーを獲得(622)する段階を含む。暗号化キーは次に、DRMヘッダを復号化(624)すべく使用され、かつ、第1のDRMチャンクがマルチメディア・ファイルの「movi」リスト・チャンク内で検索(626)される。「DRM」チャンクを復号化するに必要な暗号化キーは「DRM」ヘッダ内のテーブルから獲得(628)され、その暗号化キーは、暗号化されたビデオ・チャンクを復号化すべく用いられる。次に、必要とされるオーディオ・チャンクおよびビデオ・チャンクに付随する一切の必要なサブタイトル・チャンクが復号化(630)され、かつ、オーディオ、ビデオおよび一切のサブタイトル情報はディスプレイおよび音響システムを介して提示される(632)。
【0411】
幾つかの実施例において、選択されたオーディオ・トラックはステレオまたはサラウンド音響オーディオを提供する多重チャネルを含み得る。サブタイトルトラックが表示されるべく選択されたとき、先行ビデオはサブタイトルを含んでいたか否かに関する決定が為され得る(この決定は、現在において復号化されたビデオ・フレームに亙り表示されるべきサブタイトル情報を含んでいた先行「subtitle」チャンクを識別するという結果を達成する種々の様式の内の任意の様式で為され得る)。もし先行サブタイトルがサブタイトルを含んでおりかつそのサブタイトルに対するタイミング情報がそのサブタイトルは現在のフレームと共に表示されるべきことを表すなら、そのサブタイトルは、復号化されたビデオ・フレーム上にスーパーインポーズされる。先行フレームがサブタイトルを含んでおらず、または、先行フレーム上のサブタイトルに対するタイミング情報は、現在復号化されたフレームと組み合わせてそのサブタイトルが表示されてはならないことを表すなら、選択されたサブタイトルトラックに対する「subtitle」チャンクが探索される。もし「subtitle」チャンクが位置決定されたなら、そのサブタイトルは、復号化されたビデオにスーパーインポーズされる。(スーパーインポーズされた一切のサブタイトルを含む)ビデオは次に、付随するオーディオと共に表示される。
【0412】
図4.0.の考察を参照するとプロセスは、何らかの付加的なDRMチャンクが在るか否かを決定(634)する。もし在れば、次のDRMチャンクが位置決定(626)され、そのプロセスは付加的なDRMチャンクが無くなるまで継続する。その時点において、オーディオ、ビデオおよび/またはサブタイトルトラックのプレゼンテーションは完了(636)する。
【0413】
幾つかの実施例においてデバイスは、本発明によるマルチメディア・ファイルの「hdrl」チャンク内に含まれた情報を用い、マルチメディア情報の特定部分(たとえば、映画の特定シーンであって特定の付随オーディオ・トラックおよび選択的には特定の付随サブタイトルトラックなど)を探索し得る。多くの実施例において、「ビデオ(video)」チャンク、「オーディオ(audio)」チャンクおよび/または「サブタイトル(subtitle)」チャンクの復号化は、他のタスクと並行して実施され得る。
【0414】
マルチメディア・ファイルからの情報にアクセスし得ると共に特定のオーディオ・トラックおよび/または特定のサブタイトルトラックと組み合わせてビデオを表示し得るデバイスの例は、ソフトウェアを用いて上述の様式で構成されたコンピュータである。別の例は、これらの機能を含むコーデックを備えたDVDプレーヤである。他の実施例において、(意図的であれ任意的であれ)特定メディア・トラックに対応する「data」チャンクを検索もしくは選択し、かつ、プレゼンテーションのためにこれらのトラックを復号化すべく構成された任意のデバイスは、本発明の実施方法に係るマルチメディア・ファイルを用いてマルチメディア・プレゼンテーションを生成し得る。
【0415】
幾つかの実施例においてデバイスは、マルチメディア・ファイルからの情報を、外部ファイルからのマルチメディア情報と組み合わせて再生し得る。典型的に斯かるデバイスは、上述の形式のマルチメディア・ファイルにおいて参照されたローカル・ファイルからのオーディオ・トラックもしくはサブタイトルトラックを調達することにより、それを行う。参照されたファイルがローカル的には記憶されておらず、かつ、デバイスが、デバイスが記憶された箇所に対してネットワークされていれば、そのデバイスはファイルのローカル・コピーを獲得し得る。デバイスは次に両方のファイルにアクセスし、マルチメディアの種々のトラックが異なるファイル・ソースから供給されるというビデオ、オーディオおよび(必要であれば)サブタイトルのパイプラインを確立する。
【0416】
5.2.メニューの生成
図4.1.には、本発明の実施例によるデコーダが示される。デコーダ650は、本発明の実施例によるマルチメディア・ファイル652をデマルチプレクサ654に対して提供することにより、そのファイルを処理する。デマルチプレクサはマルチメディア・ファイルから「DMNU」チャンクを抽出すると共に、その「DMNU」チャンクから全ての「LanguageMenus」チャンクを抽出し、それらをメニュー・パーサ656に対して提供する。デマルチプレクサはまた、「DMNU」チャンクから全ての「Media」チャンクも抽出し、それらをメディア・レンダラ(media renderer)658に対して提供する。メニュー・パーサ656は、「LanguageMenus」チャンクからの情報を解析することで、その「LanguageMenus」チャンクにおいて定義されたメニュー構造を表す状態マシンを構築する。メニュー構造を表す状態マシンは、ユーザに対する表示を提供すべくかつユーザの命令に応答すべく使用され得る。状態マシンは、メニュー状態コントローラ660に対して提供される。そのメニュー状態コントローラは、メニュー状態マシンの現在状態を追尾すると共に、ユーザから命令を受ける。ユーザからの命令は、状態遷移を引き起こし得る。ユーザに対して提供される初期表示、および、表示に対する一切の更新であってメニュー状態遷移を伴う更新は、メニュー・プレーヤ・インタフェース662を用いて制御され得る。メニュー・プレーヤ・インタフェース662は、メニュー状態コントローラおよびメディア・レンダラに対して接続され得る。メニュー・プレーヤ・インタフェースはメディア・レンダラに対し、メディア・チャンクからどのメディアが抽出されかつそのメディア・レンダラに接続されたプレーヤ664を介してユーザに対して提供されるべきかを指示する。ユーザはプレーヤに対し、キーボード、マウスまたはリモコンなどの入力デバイスを用いて指示を与え得る。概略的にマルチメディア・ファイルはユーザに対して最初に表示されるメニューを決定し、かつ、ユーザの指示は初期メニューの生成に続いて表示されるオーディオおよびビデオを決定する。図4.1.に示されたシステムは、コンピュータおよびソフトウェアを用いて実現され得る。他の実施例においてシステムは、機能固有集積回路、または、ソフトウェアおよびファームウェアの組み合わせを用いて実現され得る。
【0417】
図4.2.には、本発明の実施例によるメニューの例が示される。メニュー表示670は、4個のボタンエリア672と、タイトル676を含むバックグラウンド・ビデオ674と、ポインタ678とを含む。メニューは、(図示しない)バックグラウンド・オーディオも含む。表示により生成される視覚的効果は外面的とされ得る。各ボタンの視覚的外観は典型的にはバックグラウンド・ビデオの一部であり、かつ、ボタン自体は、バックグラウンド・ビデオの単なる定義領域であってポインタにより起動されたときにその領域に関係付けられた特定動作を有するという定義領域である。ポインタは典型的にはオーバレイである。
【0418】
図4.3.は、図4.2.に示された表示における全ての情報のソースを概念的に示している。バックグラウンド・ビデオ674は、メニュー・タイトル、ボタンの視覚的外観、および、表示のバックグラウンドを含み得る。これらの要素および付加的要素の全ては、静止的または動画的に出現し得る。バックグラウンド・ビデオは、「メディアトラック(MediaTrack)」チャンク700に含まれる情報であってビデオ・トラック702内におけるバックグラウンド・ビデオの箇所を表す情報を用いて抽出される。メニューに付随し得るバックグラウンド・オーディオ706は、オーディオ・トラック710内におけるそのバックグラウンド・オーディオの箇所を表す「メディアトラック(MediaTrack)」チャンク708を用いて検索され得る。上述された如く、ポインタ678はオーバレイ713の一部である。オーバレイ713は、バックグラウンド・ビデオの一部分であってボタンとして現れる一部分を強調すべく現れるグラフィックも含み得る。一実施例においてオーバレイ713は、オーバレイトラック714内におけるそのオーバレイの箇所を表す「MediaTrack」チャンク712を用いて獲得される。メニューがユーザと対話する様式は、ボタンの各々に関係付けられた(図示しない)「Action」チャンクにより定義される。図示実施例においては、「PlayAction」チャンク716が示される。その「PlayAction」チャンクは、マルチメディア・ファイル内に含まれたマルチメディア・プレゼンテーション(すなわちオーディオ、ビデオ、および、可能的にはサブタイトルトラック)内のシーンを間接的に参照する(「PlayAction」チャンクにより参照される他のチャンクは示されない)。「PlayAction」チャンク716は最終的に、番組トラック内のシーンを表す「MediaTrack」チャンク718を用いてそのシーンを参照する。選択されたまたは既定のオーディオ・トラックの箇所、および、可能的にはサブタイトルトラックも参照される。
【0419】
ユーザが入力デバイスを用いて命令を入力するにつれて表示は、ボタンエリアの選択に応じて更新されるだけでなく、単にボタンエリア内に配置されつつあるポインタによっても更新され得る。で論じられた如く、メニューを生成すべく使用されるメディア情報の典型的には全てが、マルチメディア・ファイル内、より詳細には「DMNU」チャンク内に配置される。但し他の実施例において、情報はファイル内の他の箇所、および/または、別のファイル内に配置され得る。
【0420】
5.3.メタデータのアクセス
「メタデータ」は、情報を表す標準化方法である。「メタデータ」の標準化性質によれば、データは自動的プロセスによりアクセスされて理解され得る。一実施例において「メタデータ」は、抽出されると共に視認のためにユーザに対して提供される。幾つかの実施例によれば、サーバ上のマルチメディア・ファイルが検査されることで、ユーザの鑑賞習慣および鑑賞選好性に関する情報が提供され得る。斯かる情報はソフトウェア・アプリケーションにより使用されることで、ユーザが鑑賞を楽しみ得る他のマルチメディア・ファイルが推奨され得る。一実施例において推奨は、他のユーザのサーバ上に含まれたマルチメディア・ファイルに基づき得る。他の実施例においてユーザはマルチメディア・ファイルを要求することが可能であり、そのファイルは、種々の箇所におけるマルチメディア・ファイルの「メタデータ」を検査する検索エンジンおよび/またはインテリジェント・エージェントにより位置決定され得る。これに加えてユーザは、マルチメディア・プレゼンテーションの異なるバージョンの各々が符号化された様式に関する「メタデータ」に基づき、種々のマルチメディア・ファイルの中から特定のマルチメディア・プレゼンテーションを含むものを選択し得る。
【0421】
幾つかの実施例において、本発明の実施例によるマルチメディア・ファイルの「メタデータ」は、目録を作成する目的で、または、ファイルの内容にアクセスする単純なメニューを生成するためにアクセスされ得る。
【0422】
上記の記述は発明の多くの特定実施例を含むが、これらは発明の有効範囲に対する制限と解釈されるべきでなく、寧ろ発明のひとつの実例と解釈されるべきである。たとえば本発明の実施例によるマルチメディア・ファイルは、単一のマルチメディア・プレゼンテーションまたは複数のマルチメディア・プレゼンテーションを含み得る。これに加え、斯かるファイルはひとつ以上のメニューと、任意の種々の異なる形式の「メタデータ」を含み得る。故に発明の有効範囲は、図示された実施例によってではなく、添付の各請求項および他の均等物により決定されるべきである。
【特許請求の範囲】
【請求項1】
複数の符号化ビデオトラックを有することを特徴とするマルチメディアファイル。
【請求項2】
前記マルチメディアファイルは、連結した複数の「RIFF」チャンクを有する請求項2に記載のマルチメディアファイル。
【請求項3】
各符号化ビデオトラックは、別個の「RIFF」チャンク内に含まれる請求項2に記載のマルチメディアファイル。
【請求項4】
前記ビデオは、心理視覚的強化を用いて符号化される請求項1に記載のマルチメディアファイル。
【請求項5】
各ビデオトラックは、それに対して関係付けられた少なくとも一つのオーディオトラックを有する請求項1に記載のマルチメディアファイル。
【請求項6】
前記各ビデオトラックは、「RIFF」チャンク内における一連の「ビデオ」チャンクとして符号化され、かつ、
前記各ビデオトラックに付随するオーディオトラックは、関係付けられたビデオトラックの「ビデオ」チャンクを含む前記「RIFF」チャンク内に交互配置される一連の「オーディオ」チャンクとして符号化される請求項5に記載のマルチメディアファイル。
【請求項7】
前記各「ビデオ」チャンクは、ビデオトラックからビデオの単一フレームを生成すべく使用され得る情報を含み、かつ、
前記各「オーディオ」チャンクは、「ビデオ」チャンクを用いて生成されるフレームに付随するオーディオトラックの部分からのオーディオ情報を含む請求項6に記載のマルチメディアファイル。
【請求項8】
前記「オーディオ」チャンクは前記「RIFF」チャンク内において対応する前記「ビデオ」チャンクの前に交互配置される請求項7に記載のマルチメディアファイル。
【請求項9】
複数のビデオトラックを符号化し、
前記符号化ビデオトラックを連結し、かつ、
連結された前記符号化ビデオトラックを単一ファイルへと書き込む、
ように構成されるプロセッサを有するマルチメディアファイルを符号化するシステム。
【請求項10】
前記プロセッサは、前記各ビデオトラックが別個の「RIFF」チャンク内に含まれるように前記ビデオトラックを符号化すべく構成される請求項9に記載のシステム。
【請求項11】
前記プロセッサは、心理視覚的強化を用いて前記ビデオを符号化すべく構成される請求項9に記載のシステム。
【請求項12】
各ビデオトラックは、それに関係付けられた少なくとも一つのオーディオトラックを有する請求項9に記載のシステム。
【請求項13】
前記プロセッサは、
前記各ビデオトラックを、「RIFF」チャンク内における一連の「ビデオ」チャンクとして符号化し、かつ、
前記各ビデオトラックに付随する少なくとも一つのオーディオトラックを、前記関係付けられたビデオトラックの「ビデオ」チャンクを含む「RIFF」チャンク内に交互配置された一連の「オーディオ」チャンクとして符号化するように構成される請求項12に記載のマルチメディアファイル。
【請求項14】
前記プロセッサは、
前記ビデオトラックを、各「ビデオ」チャンクが、ビデオトラックからビデオの単一フレームを生成すべく使用され得る情報を含むように符号化し、かつ、
ビデオトラックに関係付けられた前記オーディオトラックを、各「オーディオ」チャンクが、該ビデオトラックから生成された「ビデオ」チャンクを用いて生成されたフレームに付随する前記オーディオトラックの部分からのオーディオ情報を含むように符号化するように構成される請求項13に記載のマルチメディアファイル。
【請求項15】
前記プロセッサは、前記各「オーディオ」チャンクを前記「RIFF」チャンク内の対応する前記「ビデオ」チャンク前に交互配置するように構成される請求項14に記載のマルチメディアファイル。
【請求項16】
マルチメディアファイルから情報を抽出すべく構成されたプロセッサを有し、
前記プロセッサは、前記マルチメディアファイル内に含まれた符号化ビデオトラックの数に関する情報を抽出すべく構成される、
複数の符号化ビデオトラックを含むマルチメディアファイルを復号化するシステム。
【請求項17】
前記プロセッサは、「RIFF」チャンク内で符号化ビデオトラックを検索するために構成される請求項16に記載のシステム。
【請求項18】
第1の符号化ビデオトラックは、標準4ccコードを有する第1「RIFF」チャンク内には含まれ、
第2のビデオトラックは、特殊化4ccコードを有する第2「RIFF」チャンク内には含まれ、かつ、
前記特殊化4ccコードは、その特殊化4ccコードの最後の2個のキャラクタとして、標準4ccコードの最初の2個のキャラクタを有する請求項17に記載のシステム。
【請求項19】
各符号化ビデオトラックは別個の「RIFF」チャンク内に含まれる請求項17に記載のシステム。
【請求項20】
復号化されたビデオトラックは、前記マルチメディアファイルを生成する際に符号化されたオリジナルのビデオトラックと類似する請求項16に記載のシステム。
【請求項21】
前記復号化されたビデオトラックと前記オリジナルのビデオトラックとの間における相違点の少なくとも幾つかは、ビデオトラックの各フレームの暗い部分内に配置される請求項20に記載のシステム。
【請求項22】
前記復号化されたビデオトラックと前記オリジナルのビデオトラックとの間における相違点の少なくとも幾つかは、ビデオトラックの速い動作シーンに配置される請求項20に記載のシステム。
【請求項23】
各ビデオトラックは、それ自身に関係付けられた少なくとも一つのオーディオトラックを有する請求項16に記載のシステム。
【請求項24】
前記プロセッサは、
「RIFF」チャンク内の一連の「ビデオ」チャンクを復号化することによりビデオトラックからビデオを表示し、かつ、
関係付けられたビデオトラックの「ビデオ」チャンクを含む「RIFF」チャンク内に交互配置された一連の「オーディオ」チャンクを復号化することにより、前記ビデオトラックに付随するオーディオトラックからオーディオを生成するように構成される請求項23に記載のシステム。
【請求項25】
前記プロセッサは、
前記ビデオトラックの単一フレームを生成するために、各「ビデオ」チャンクから抽出された情報を使用し、かつ、
「ビデオ」チャンクを使用して生成されたフレームに付随する前記オーディオトラックの部分を生成するために、各「オーディオ」チャンクから抽出された情報を使用するように構成される請求項24に記載のマルチメディアファイル。
【請求項26】
前記プロセッサは、前記「RIFF」チャンクにおいて前記「オーディオ」チャンクが関係付けられた「ビデオ」チャンクの前に、前記「オーディオ」チャンクを検索するように構成される請求項25に記載のマルチメディアファイル。
【請求項27】
一連の符号化ビデオ・フレームと、
前記符号化ビデオ・フレームの間に交互配置された符号化オーディオとを備え、
前記符号化オーディオは、オーディオ情報の2つ以上のトラックを含むことを特徴とするマルチメディアファイル。
【請求項28】
前記オーディオ情報のトラックの内の少なくとも一つのトラックは、複数のオーディオチャネルを含む請求項27に記載のマルチメディアファイル。
【請求項29】
当該マルチメディアファイルに含まれたオーディオトラックの数を特定するヘッダ情報を更に有する請求項27に記載のマルチメディアファイル。
【請求項30】
前記オーディオ情報のトラックの内の少なくとも一つのトラックに関する説明情報を含むヘッダ情報を更に有する請求項27に記載のマルチメディアファイル。
【請求項31】
各符号化ビデオ・フレームは、符号化オーディオ情報により先行され、かつ、
ビデオ・フレームに先行する符号化オーディオ情報は、前記符号化ビデオ・フレームに付随する各オーディオトラックの部分に対するオーディオ情報を含む請求項27に記載のマルチメディアファイル。
【請求項32】
前記ビデオ情報は、当該マルチメディアファイル内にチャンクとして記憶される請求項27に記載のマルチメディアファイル。
【請求項33】
ビデオ情報の各チャンクは、ビデオの単一フレームを含む請求項32に記載のマルチメディアファイル。
【請求項34】
前記オーディオ情報は当該マルチメディアファイル内にチャンクとして記憶され、
2つの別個のオーディオトラックからのオーディオ情報はオーディオ情報の単一チャンク内には含まれない、請求項33に記載のマルチメディアファイル。
【請求項35】
前記ビデオ・チャンクは、前記オーディオトラックの各々からの少なくとも一つのオーディオ・チャンクにより分離される請求項34に記載のマルチメディアファイル。
【請求項36】
前記ビデオ・チャンクを分離する前記オーディオ・チャンクは、そのオーディオ・チャンクに追随するビデオ・チャンク内に含まれたビデオ情報に付随するオーディオトラックの部分に対するオーディオ情報を含む請求項35に記載のマルチメディアファイル。
【請求項37】
ビデオトラックを符号化し、
複数のオーディオトラックを符号化し、
前記ビデオトラックからの情報を、前記複数のオーディオトラックからの情報と交互配置し、かつ、
交互配置されたビデオおよびオーディオ情報を単一ファイルへと書き込む、
ように構成されるプロセッサを有する、マルチメディアファイルを符号化するシステム。
【請求項38】
前記オーディオトラックの内の少なくとも一つのオーディオトラックは複数のオーディオチャネルを含む請求項37に記載のシステム。
【請求項39】
前記プロセッサは、更に、前記符号化オーディオトラックの数を特定するヘッダ情報を符号化し、かつ、そのヘッダ情報を前記単一ファイルに書き込みむべく構成される請求項37に記載のシステム。
【請求項40】
前記プロセッサは、更に、前記符号化オーディオトラックの内の少なくとも一つに関する説明情報を特定するヘッダ情報を符号化し、かつ、そのヘッダ情報を前記単一ファイルに書き込むべく構成される、請求項37に記載のシステム。
【請求項41】
前記プロセッサは、前記ビデオトラックをビデオ情報のチャンクとして符号化する、請求項37に記載のシステム。
【請求項42】
前記プロセッサは、各オーディオトラックをオーディオ情報の一連のチャンクとして符号化する請求項41に記載のシステム。
【請求項43】
オーディオ情報の各チャンクは、単一のオーディオトラックからのオーディオ情報を含む請求項42に記載のシステム。
【請求項44】
前記プロセッサは、ビデオ情報のチャンク間にオーディオ情報のチャンクを交互配置すべく構成される請求項43に記載のシステム。
【請求項45】
前記プロセッサは、「ビデオ」チャンクにおけるビデオ情報に付随する各オーディオトラックの部分を「オーディオ」チャンク内に符号化すべく構成され、かつ、
前記プロセッサは、前記各「ビデオ」チャンクが、その「ビデオ」チャンクに含まれるビデオ情報に付随するオーディオトラックの各々からのオーディオ情報を含む「オーディオ」チャンクにより先行されるように、前記「ビデオ」チャンクで前記「オーディオ」チャンクを交互配置するために構成される請求項44に記載のシステム。
【請求項46】
前記プロセッサは、各ビデオ・チャンク内にビデオの単一フレームが含まれるように前記ビデオトラックを符号化すべく構成される請求項45に記載のシステム。
【請求項47】
前記プロセッサは、汎用プロセッサである請求項45に記載のシステム。
【請求項48】
前記プロセッサは、専用回路である請求項45に記載のシステム。
【請求項49】
マルチメディアファイルから情報を抽出すべく構成されたプロセッサを備え、
前記プロセッサは、前記マルチメディアファイル内に含まれるオーディオトラックの数に関する情報を抽出すべく構成される複数のオーディオトラックを含むマルチメディアファイルを復号化するシステム。
【請求項50】
前記プロセッサは、前記複数のオーディオトラックから単一のオーディオトラックを選択すべく構成され、
前記プロセッサは、前記選択されたオーディオトラックからのオーディオ情報を復号化すべく構成される請求項49に記載のシステム。
【請求項51】
前記オーディオトラックの内の少なくとも一つは、複数のオーディオチャネルを含む、請求項49に記載のシステム。
【請求項52】
前記プロセッサは、前記マルチメディアファイルにおけるヘッダから、前記オーディオトラックの内の少なくとも一つのオーディオトラックに関する説明情報を含む情報を抽出すべく構成される請求項49に記載のシステム。
【請求項53】
ネットワークと、
マルチメディアファイルを含むと共に、サーバを介して前記ネットワークに対して接続された記憶デバイスと、
前記ネットワークに接続されたクライアントとを有し、
前記クライアントは、前記サーバからの前記マルチメディアファイルの転送を要求することができ、かつ、
前記マルチメディアファイルは、少なくとも一つのビデオトラックと、そのビデオトラックに付随する複数のオーディオトラックとを含む、
マルチメディア情報を通信するシステム。
【請求項54】
一連の符号化ビデオ・フレームと、
前記符号化ビデオ・フレーム間に交互配置される少なくとも一つの符号化サブタイトルトラックとを有する、
ことを特徴とするマルチメディアファイル。
【請求項55】
前記少なくとも一つの符号化サブタイトルトラックは、複数の符号化サブタイトルトラックを有する請求項54に記載のマルチメディアファイル。
【請求項56】
当該マルチメディアファイルに含まれた符号化サブタイトルトラックの数を特定するヘッダ情報を更に有する請求項54に記載のマルチメディアファイル。
【請求項57】
前記符号化サブタイトルトラックの内の少なくとも一つに関する説明情報を含むヘッダ情報を更に有する請求項54に記載のマルチメディアファイル。
【請求項58】
各サブタイトルトラックは一連のビットマップを含む請求項54に記載のマルチメディアファイル。
【請求項59】
各サブタイトルトラックは一連の圧縮ビットマップを含む請求項58に記載のマルチメディアファイル。
【請求項60】
各ビットマップはランレングス符号化方法を用いて圧縮される請求項59に記載のマルチメディアファイル。
【請求項61】
前記一連の符号化ビデオ・フレームは、一連のビデオ・チャンクとして符号化され、
各符号化サブタイトルトラックは、一連のサブタイトル・チャンクとして符号化され、
各サブタイトル・チャンクは、表示上にテキストとして表され得る情報を含む請求項54に記載のマルチメディアファイル。
【請求項62】
各サブタイトル・チャンクは、単一のサブタイトルに関する情報を含む請求項61に記載のマルチメディアファイル。
【請求項63】
各サブタイトル・チャンクは、サブタイトルがスーパーインポーズされるべきビデオ・シーケンスの部分に関する情報を含む請求項62に記載のマルチメディアファイル。
【請求項64】
各サブタイトル・チャンクは、サブタイトルが配置されるべき表示の部分に関する情報を含む請求項62に記載のマルチメディアファイル。
【請求項65】
各サブタイトル・チャンクは、サブタイトルの色に関する情報を含む請求項62に記載のマルチメディアファイル。
【請求項66】
色に関する前記情報は、色パレートを含む請求項65に記載のマルチメディアファイル。
【請求項67】
前記サブタイトル・チャンクは、第1色パレートに関する情報を含む第1サブタイトル・チャンクと、該第1色パレートに関する情報に成り代わる第2色パレートに関する情報を含む第2サブタイトル・チャンクとを有する請求項66に記載のマルチメディアファイル。
【請求項68】
ビデオトラックを符号化し、
少なくとも一つのサブタイトルトラックを符号化し、
前記ビデオトラックからの情報を、前記少なくとも一つのサブタイトルトラックからの情報と交互配置し、かつ、
交互配置されたビデオおよびサブタイトル情報を単一ファイルに書き込む、
ように構成されたプロセッサを有するマルチメディアファイルを符号化するシステム。
【請求項69】
前記少なくとも一つのサブタイトルトラックは、複数のサブタイトルトラックを有する請求項68に記載のシステム。
【請求項70】
前記プロセッサは、更に、前記マルチメディアファイルに含まれたサブタイトルトラックの数を特定するヘッダ情報を符号化し、かつ、前記単一ファイルに書き込むべく構成される請求項68に記載のシステム。
【請求項71】
前記プロセッサは、更に、前記サブタイトルトラックの内の少なくとも一つについての説明情報を符号化し、かつ、前記単一ファイルに書き込むべく構成される請求項68に記載のシステム。
【請求項72】
前記ビデオトラックはビデオ・チャンクとして符号化され、かつ、
前記少なくとも一つのサブタイトルトラックの各々は、サブタイトル・チャンクとして符号化される請求項68に記載のシステム。
【請求項73】
前記サブタイトル・チャンクの各々は、前記ビデオトラックの一部に付随する単一のサブタイトルを含み、
インタリーバは、サブタイトル・チャンク内のサブタイトルが付随するビデオトラックの部分を含むビデオ・チャンクに先行して、各サブタイトル・チャンクを交互配置すべく構成される請求項72に記載のシステム。
【請求項74】
前記プロセッサは、前記サブタイトルをビットマップとして符号化することによりサブタイトル・チャンクを生成すべく構成される請求項72に記載のシステム。
【請求項75】
前記サブタイトルは、圧縮ビットマップとして符号化される請求項72に記載のシステム。
【請求項76】
前記ビットマップは、ランレングス符号化方法を用いて圧縮される請求項75に記載のシステム。
【請求項77】
前記プロセッサは、各サブタイトル・チャンク内に、サブタイトルがスーパーインポーズされるべきビデオ・シーケンスの部分に関する情報を含める請求項76に記載のシステム。
【請求項78】
前記プロセッサは、各サブタイトル・チャンク内に、サブタイトルが配置されるべき表示の部分に関する情報を含める請求項73に記載のシステム。
【請求項79】
前記プロセッサは、各サブタイトル・チャンク内に、サブタイトルの色に関する情報を含める請求項73に記載のシステム。
【請求項80】
前記色に関する情報は、色パレートを含む請求項73に記載のシステム。
【請求項81】
前記サブタイトル・チャンクは、第1色パレートに関する情報を含む第1サブタイトル・チャンクと、該第1色パレートに関する情報に成り代わる第2色パレートに関する情報を含む第2サブタイトル・チャンクとを有する請求項80に記載のシステム。
【請求項82】
マルチメディアファイルから情報を抽出すべく構成されるプロセッサを有し、
前記プロセッサは、少なくとも一つのサブタイトルトラックが在るか否かを決定するためマルチメディアファイルを検査するように構成されるマルチメディアファイルを復号化するシステム。
【請求項83】
前記少なくとも一つのサブタイトルトラックは、複数のサブタイトルトラックを有し、かつ、前記プロセッサは、前記マルチメディアファイル内におけるサブタイトルトラックの数を決定すべく構成される請求項82に記載のシステム。
【請求項84】
前記プロセッサは、更に、サブタイトルトラックの数を特定するヘッダ情報を前記マルチメディアファイルから抽出すべく構成される請求項82に記載のシステム。
【請求項85】
前記プロセッサは、更に、前記サブタイトルトラックの内の少なくとも一つのサブタイトルトラックについての説明情報を、前記マルチメディアファイルから抽出すべく構成される請求項82に記載のシステム。
【請求項86】
前記マルチメディアファイルは、ビデオ・チャンクとして符号化された少なくとも一つのビデオトラックを含み、かつ、
前記マルチメディアファイルは、サブタイトル・チャンクとして符号化された少なくとも一つのサブタイトルトラックを含む請求項82に記載のマルチメディアファイルを復号化するシステム。
【請求項87】
各サブタイトル・チャンクは、単一のサブタイトルに関する情報を含む、請求項86に記載のマルチメディアファイルを復号化するシステム。
【請求項88】
各サブタイトルは、前記サブタイトル・チャンク内においてビットマップとして符号化され、
前記プロセッサは、前記ビデオトラックを復号化すべく構成され、かつ、
前記プロセッサは、ビットマップを前記ビデオ・シーケンスの一部上にスーパーインポーズすることにより、表示のためのビデオのフレームを構築すべく構成される請求項87に記載のマルチメディアファイルを復号化するシステム。
【請求項89】
前記サブタイトルは、圧縮ビットマップとして符号化され、かつ、
前記プロセッサは、ビットマップを解凍すべく構成される請求項88に記載のマルチメディアファイルを復号化するシステム。
【請求項90】
前記プロセッサは、ランレングス符号化されたビットマップを解凍すべく構成される、請求項89に記載のマルチメディアファイルを復号化するシステム。
【請求項91】
各サブタイトル・チャンクは、サブタイトルがスーパーインポーズされるべきビデオトラックの部分に関する情報を含み、かつ、
前記プロセッサは、前記サブタイトル・チャンクにおける情報により指示される各ビデオ・フレーム上に前記サブタイトルの前記ビットマップをスーパーインポーズすることにより、表示のための一連のビデオ・フレームを生成すべく構成される請求項88に記載のマルチメディアファイルを復号化するシステム。
【請求項92】
各サブタイトル・チャンクは、該サブタイトルが配置されるべきフレーム内の位置に関する情報を含み、かつ、
前記プロセッサは、前記サブタイトル・チャンク内の情報により指示される各ビデオ・フレーム内の位置に前記サブタイトルをスーパーインポーズすべく構成される請求項88に記載のマルチメディアファイルを復号化するシステム。
【請求項93】
各サブタイトル・チャンクは、前記サブタイトルの色に関する情報を含み、かつ、
前記プロセッサは、前記サブタイトル・チャンク内の色情報により指示される単一もしくは複数の色で前記サブタイトルをスーパーインポーズすべく構成される請求項88に記載のマルチメディアファイルを復号化するシステム。
【請求項94】
前記サブタイトル・チャンク内における前記色情報は、色パレートを含み、かつ、
前記プロセッサは、前記サブタイトルの前記ビットマップにおいて使用される色情報を取得するために前記色パレートを用いて、前記サブタイトルをスーパーインポーズすべく構成される請求項93に記載のマルチメディアファイルを復号化するシステム。
【請求項95】
前記サブタイトル・チャンクは、第1色パレートに関する情報を含む第1サブタイトル・チャンクと、第2色パレートに関する情報を含む第2サブタイトル・チャンクとを有し、かつ、
前記プロセッサは、
第1チャンクが処理された後に前記サブタイトルの前記ビットマップにおいて使用される色に関する情報を取得するために、第1色パレートを用いて、サブタイトルをスーパーインポーズすべく構成され、かつ、
第2チャンクが処理された後にサブタイトルのビットマップにおいて使用される色に関する情報を取得するために、第2色パレートを用いて、サブタイトルをスーパーインポーズすべく構成される請求項94に記載のシステム。
【請求項96】
ネットワークと、
マルチメディアファイルを含むと共に、サーバを介して前記ネットワークに対して接続された記憶デバイスと、
前記ネットワークに接続されたクライアントとを有し、
前記クライアントは、前記サーバからの前記マルチメディアファイルの転送を要求することができ、かつ、
前記マルチメディアファイルは、少なくとも一つのビデオトラックと、そのビデオトラックに付随する少なくとも一つのサブタイトルトラックとを含むマルチメディア情報を通信するシステム。
【請求項97】
一連の符号化ビデオ・フレームと、
符号化されたメニュー情報とを有することを特徴とするマルチメディアファイル。
【請求項98】
前記符号化されたメニュー情報は、チャンクとして記憶される請求項97に記載のマルチメディアファイル。
【請求項99】
少なくとも2つの別個のメニュー情報の「メニュー」チャンクを更に有する請求項98に記載のマルチメディアファイル。
【請求項100】
前記少なくとも2つの別個の「メニュー」チャンクは、少なくとも2つの別個の「RIFF」チャンクに含まれる請求項99に記載のマルチメディアファイル。
【請求項101】
「メニュー」チャンクを含む第1「RIFF」チャンクは、標準4ccコードを含むと共に、「メニュー」チャンクを含む第2「RIFF」チャンクは、特殊化4ccコードを含み、前記標準4ccコードの最初の2個のキャラクタは、前記特殊化4ccコードの最後の2個のキャラクタとして現れる請求項100に記載のマルチメディアファイル。
【請求項102】
少なくとも2つの別個の「menu」チャンクは、単一の「RIFF」チャンク内に含まれる請求項99に記載のマルチメディアファイル。
【請求項103】
前記「メニュー」チャンクは、一連のメニューを記述するチャンクと、該一連のメニューに関係付けられたメディアを含む「MRIF」チャンクとを含む請求項99に記載のマルチメディアファイル。
【請求項104】
前記「MRIF」チャンクは、ビデオトラック、オーディオトラックおよびオーバレイトラックを含むメディア情報を含む、請求項103に記載のマルチメディアファイル。
【請求項105】
一連のメニューを記述する前記チャンクは、
メニュー・システム全体を記述するチャンクと、
前記メニューを言語によりグループ化する少なくとも一つのチャンクと、
個々のメニュー表示と、付随するバックグラウンド・オーディオとを記述する少なくとも一つのチャンクと、
メニュー上のボタンを記述する少なくとも一つのチャンクと、
画面上における前記ボタンの位置を記述する少なくとも一つのチャンクと、
ボタンに関係付けられる種々な動作を記述する少なくとも一つのチャンクとを含む、
請求項103に記載のマルチメディアファイル。
【請求項106】
第2ファイルに対するリンクを更に有し、
符号化されたメニュー情報は、前記第2ファイル内に含まれる請求項97に記載のマルチメディアファイル。
【請求項107】
メニュー情報を符号化すべく構成されたプロセッサを備え、
前記プロセッサは、符号化ビデオトラックおよび符号化メニュー情報を含むマルチメディアファイルを生成するようにも構成されるマルチメディアファイルを符号化するシステム。
【請求項108】
前記プロセッサは、
前記メニューのオブジェクト・モデルを生成し、
前記オブジェクト・モデルをコンフィグ・ファイルへと変換し、
前記コンフィグ・ファイルをチャンクに解析し、
メディア情報を含むAVIファイルを生成し、
前記AVIファイル内のメディアを「MRIF」チャンク内へと交互配置し、かつ、
「メニュー」チャンクを生成するために、前記解析されたチャンクを「MRIF」チャンクと連結するように構成される請求項107に記載のシステム。
【請求項109】
前記プロセッサは更に、第2の更に小さな「メニュー」チャンクを生成するために前記オブジェクト・モデルを使用すべく構成される請求項108に記載のシステム。
【請求項110】
前記プロセッサは、第2メニューを符号化すべく構成される請求項107に記載のシステム。
【請求項111】
前記プロセッサは、第1の符号化メニューを第1「RIFF」チャンクに挿入し、かつ、第2の符号化メニューを第2「RIFF」チャンクに挿入する請求項110に記載のシステム。
【請求項112】
前記プロセッサは、前記第1および第2の符号化メニューを単一の「RIFF」チャンク内に含める請求項110に記載のシステム。
【請求項113】
前記プロセッサは、第2ファイルにおける符号化メニューに対するリファレンスを、前記マルチメディアファイル内に挿入すべく構成される請求項107に記載のシステム。
【請求項114】
マルチメディアファイルから情報を抽出すべく構成されたプロセッサを有し、
前記プロセッサは、前記マルチメディアファイルが符号化されたメニュー情報を含むか否かを決定するために、前記マルチメディアファイルを検査すべく構成されるマルチメディアファイルを復号化するシステム。
【請求項115】
前記プロセッサは、「RIFF」チャンク内の「メニュー」チャンクからメニュー情報を抽出すべく構成される請求項114に記載のシステム。
【請求項116】
前記プロセッサは、前記「メニュー」チャンクに記憶されたビデオ情報を用いてメニュー表示を構築すべく構成される請求項115に記載のシステム。
【請求項117】
前記プロセッサは、前記「メニュー」チャンクに記憶されたオーディオ情報を用いてメニュー表示に付随するバックグラウンド・オーディオを生成すべく構成される請求項115に記載のシステム。
【請求項118】
前記プロセッサは、前記「メニュー」チャンクからのオーバレイを、前記「メニュー」チャンクからのビデオ情報に重ね合わせることによりメニュー表示を生成すべく構成される請求項115に記載のシステム。
【請求項119】
ネットワークと、
マルチメディアファイルを含むと共に、サーバを介して前記ネットワークに対して接続された記憶デバイスと、
前記ネットワークに接続されたクライアントとを備え、
前記クライアントは、前記サーバからの前記マルチメディアファイルの転送を要求することができ、かつ、
前記マルチメディアファイルは、符号化されたメニュー情報を含む、
マルチメディア情報を通信するシステム。
【請求項120】
一連の符号化ビデオ・フレームと、
前記マルチメディアファイルについての符号化メタデータとを有し、
前記符号化メタデータは、主部、述部、目的部および出典を有する少なくとも一つのステートメントを含む、
マルチメディアファイル。
【請求項121】
前記主部は、前記メタデータにより記述されるファイル、項目、人物または組織を特定する情報を含む請求項120に記載のマルチメディアファイル。
【請求項122】
前記述部は、前記主部の特性を表す情報を含む請求項121に記載のマルチメディアファイル。
【請求項123】
前記目的部は、前記述部により特定された前記主部の特性を記述する情報を含む請求項122に記載のマルチメディアファイル。
【請求項124】
前記出典は、前記ステートメントのソースに関する情報を含む請求項123に記載のマルチメディアファイル。
【請求項125】
前記主部は、タイプおよび値を含むチャンクであり、
前記値は、情報を含み、かつ、
前記タイプは、前記チャンクがリソースであるか匿名ノードであるかを指示する請求項120に記載のマルチメディアファイル。
【請求項126】
前記述部は、タイプおよび値を含むチャンクであり、
前記値は、情報を含み、かつ、
前記タイプは、前記値情報が記述URIであるか順序リスト・エントリであるかを指示する請求項120に記載のマルチメディアファイル。
【請求項127】
前記目的部は、タイプ、言語、データタイプおよび値を含むチャンクであり、
前記値は、情報を含み、
前記タイプは、前記値情報がUTF−8リテラル、リテラル整数またはリテラルXMLデータであるかを指示し、
前記データタイプは、前記値情報のタイプを指示し、かつ、
前記言語は特定言語を指定する情報を含む請求項120に記載のマルチメディアファイル。
【請求項128】
前記出典は、タイプおよび値を含むチャンクであり、
前記値は情報を含み、かつ、
前記タイプは、前記値情報が前記ステートメントの出典であることを表す、請求項127に記載のマルチメディアファイル。
【請求項129】
前記符号化データの少なくとも一部は2値データとして表される請求項120に記載のマルチメディアファイル。
【請求項130】
前記符号化データの少なくとも一部は、64ビットASCIデータとして表される請求項120に記載のマルチメディアファイル。
【請求項131】
前記符号化データの少なくとも第1部分は、2値データとして表され、かつ、前記符号化データの少なくとも第2部分は第2フォーマットで表されたデータを含む付加的チャンクとして表される請求項120に記載のマルチメディアファイル。
【請求項132】
前記付加的チャンクは各々、単一断片のメタデータを含む請求項131に記載のマルチメディアファイル。
【請求項133】
ビデオトラックを符号化すべく構成されたプロセッサを備え、
前記プロセッサは、前記マルチメディアファイルに関するメタデータを符号化するようにも構成され、かつ、
前記符号化メタデータは、主部、述部、目的部および出典を備える少なくとも一つのステートメントを含むマルチメディアファイルを符号化するシステム。
【請求項134】
前記主部は、前記メタデータにより記述されるファイル、項目、人物または組織を特定する情報を含む請求項133に記載のシステム。
【請求項135】
前記述部は、前記主部の特性を表す情報を含む請求項134に記載のシステム。
【請求項136】
前記目的部は、前記述部により特定された前記主部の特性を記述する情報を含む請求項135に記載のシステム。
【請求項137】
前記出典は前記ステートメントのソースに関する情報を含む、請求項136に記載のシステム。
【請求項138】
前記プロセッサは、前記主部を、タイプおよび値を含むチャンクとして符号化すべく構成され、
前記値は、情報を含み、かつ、
前記タイプは、チャンクがリソースであるか匿名ノードであるかを表す請求項133に記載のシステム。
【請求項139】
前記プロセッサは、前記述部を、タイプおよび値を含むチャンクとして符号化すべく構成され、
前記値は情報を含み、かつ、
前記タイプは、前記値情報が記述URIであるか順序リスト・エントリであるかを指示する請求項133に記載のシステム。
【請求項140】
前記プロセッサは前記目的部を、タイプ、言語、データタイプおよび値を含むチャンクとして符号化すべく構成され、
前記値は情報を含み、
前記タイプは、前記値情報がUTF−8リテラル、リテラル整数またはリテラルXMLデータであるかを指示し、
データタイプは、前記値情報のタイプを指示し、かつ、
前記言語は特定言語を指定する情報を含む請求項133に記載のシステム。
【請求項141】
前記プロセッサは、前記出典を、タイプおよび値を含むチャンクとして符号化すべく構成され、
前記値は、情報を含み、かつ、
前記タイプは、前記値情報が前記ステートメントの出典であることを指示する請求項133に記載のシステム。
【請求項142】
前記プロセッサは、更に、マルチメディアファイルに関する前記メタデータの少なくとも一部を2値データとして符号化すべく構成される請求項133に記載のシステム。
【請求項143】
前記プロセッサは、更に、前記マルチメディアファイルに関する前記メタデータの少なくとも一部を64ビットASCIデータとして符号化すべく構成される請求項133に記載のシステム。
【請求項144】
前記プロセッサは、更に、
前記マルチメディアファイルに関する前記メタデータの少なくとも第1部分を2値データとして符号化し、かつ、
前記マルチメディアファイルに関する前記メタデータの少なくとも第2部分を、第2フォーマットで表されたデータを含む付加的チャンクとして符号化するように構成される請求項133に記載のシステム。
【請求項145】
前記プロセッサは、更に、前記付加的チャンクを単一断片のメタデータで符号化すべく構成される請求項144に記載のシステム。
【請求項146】
マルチメディアファイルから情報を抽出すべく構成されたプロセッサを有し、
前記プロセッサは、前記マルチメディアファイルに関するメタデータ情報を抽出すべく構成され、かつ、
前記メタデータ情報は、主部、述部、目的部および出典を有する少なくとも一つのステートメントを含むマルチメディアファイルを復号化するシステム。
【請求項147】
前記プロセッサは、前記主部から、前記メタデータにより記述されるファイル、アイテム、人物または組織を特定する情報を抽出すべく構成される請求項146に記載のシステム。
【請求項148】
前記プロセッサは、前記述部から前記主部の特性を表す情報を抽出すべく構成される請求項147に記載のシステム。
【請求項149】
前記プロセッサは、前記目的部から、前記述部により特定される前記主部の特性を記述する情報を抽出すべく構成される請求項148に記載のシステム。
【請求項150】
前記プロセッサは、前記出典から前記ステートメントのソースに関する情報を抽出すべく構成される請求項149に記載のシステム。
【請求項151】
前記主部は、タイプおよび値を含むチャンクであり、
前記プロセッサは、前記タイプを検査することにより、前記チャンクは主部情報を含むことを特定すべく構成され、かつ、
前記プロセッサは、前記値から情報を抽出すべく構成される請求項146に記載のシステム。
【請求項152】
前記述部は、タイプおよび値を含むチャンクであり、
前記プロセッサは、前記タイプを検査することにより、前記チャンクは述部情報を含むことを特定すべく構成され、かつ、
前記プロセッサは、前記値から情報を抽出すべく構成される請求項146に記載のシステム。
【請求項153】
前記目的部は、タイプ、言語、データタイプおよび値を含むチャンクであり、
前記プロセッサは、前記タイプを検査することにより、前記チャンクは、目的部情報を含むことを特定すべく構成され、
前記プロセッサは、前記値に含まれる情報のデータタイプを決定するために、前記データタイプを検査すべく構成され、
前記プロセッサは、前記データタイプにより指示されるタイプの情報を前記値から抽出すべく構成され、かつ、
前記プロセッサは、前記言語から、特定言語を指定する情報を抽出すべく構成される、請求項146に記載のシステム。
【請求項154】
前記出典はタイプおよび値を含むチャンクであり、
前記プロセッサは、前記タイプを検査することにより、チャンクは出典情報を含むことを特定すべく構成され、かつ、
プロセッサは、値から情報を抽出すべく構成される請求項146に記載のシステム。
【請求項155】
前記プロセッサは、前記メタデータ・ステートメントから情報を抽出し、かつ、その情報の少なくとも一部を表示すべく構成される請求項146に記載のシステム。
【請求項156】
前記プロセッサは、前記メタデータを用いて、メモリ内にラベル付き有向グラフを表すデータ構造を構築すべく構成される請求項146に記載のシステム。
【請求項157】
前記プロセッサは、複数のステートメントのための前記主部、述部、目的部および出典の内の少なくとも一つを検査することにより、前記メタデータを介して情報を検索すべく構成される請求項146に記載のシステム。
【請求項158】
前記プロセッサは、前記検索の結果を、グラフィカル・ユーザ・インタフェースの一部として表示すべく構成される請求項157に記載のシステム。
【請求項159】
前記プロセッサは、外部デバイスからの要求に応じて検索を実施すべく構成される請求項157に記載のシステム。
【請求項160】
前記マルチメディアファイルに関する前記メタデータ情報の少なくとも一部は、2値データとして表される請求項146に記載のシステム。
【請求項161】
前記マルチメディアファイルに関する前記メタデータ情報の少なくとも一部は、64ビットASCIデータとして表される請求項146に記載のシステム。
【請求項162】
前記マルチメディアファイルに関する前記メタデータ情報の少なくとも第1部分は、2値データとして表され、かつ、
前記マルチメディアファイルに関する前記メタデータ情報の少なくとも第2部分は第2フォーマットで表されたデータを含む付加的チャンクとして表される請求項146に記載のシステム。
【請求項163】
前記付加的チャンクは単一断片のメタデータを含む請求項162に記載のシステム。
【請求項164】
ネットワークと、
マルチメディアファイルを含むと共に、サーバを介して前記ネットワークに対して接続された記憶デバイスと、
前記ネットワークに接続されたクライアントとを備え、
前記クライアントは、前記サーバからの前記マルチメディアファイルの転送を要求することができ、
前記マルチメディアファイルは、そのマルチメディアファイルに関するメタデータを含み、かつ、
前記メタデータは、主部、述部、目的部および出典を備える少なくとも一つのステートメントを含む、マルチメディア情報を通信するシステム。
【請求項165】
少なくとも一つの符号化ビデオトラックと、
少なくとも一つの符号化オーディオトラックと、
複数の符号化テキスト文字列とを有し、
前記符号化テキスト文字列は、少なくとも一つのビデオトラックおよび少なくとも一つのオーディオトラックの特性を記述する、マルチメディアファイル。
【請求項166】
前記複数のテキスト文字列は、異なる言語を用い、ビデオトラックまたはオーディオトラックと同一の特性を記述する請求項165に記載のマルチメディアファイル。
【請求項167】
少なくとも一つの符号化サブタイトルトラックを更に有し、
前記複数の符号化テキスト文字列は前記サブタイトルトラックの特性を記述する文字列を含む請求項166に記載のマルチメディアファイル。
【請求項168】
少なくとも一つのビデオトラックを符号化し、
少なくとも一つのオーディオトラックを符号化し、
前記符号化オーディオトラックの内の少なくとも一つをビデオトラックと交互配置し、
少なくとも一つのビデオトラックおよび少なくとも一つのオーディオトラックの多数の特性の各々を複数の言語で記述するテキスト文字列を挿入するように構成されたプロセッサを有する、マルチメディアファイルを生成するシステム。
【請求項169】
マルチメディアファイルから符号化テキスト文字列を抽出し、かつ、
テキスト文字列を用いてプルダウン・メニュー表示を生成する、ように構成されたプロセッサを有する、
符号化オーディオ、ビデオおよびテキスト文字列を含むマルチメディアファイルを表示するシステム。
【請求項1】
複数の符号化ビデオトラックを有することを特徴とするマルチメディアファイル。
【請求項2】
前記マルチメディアファイルは、連結した複数の「RIFF」チャンクを有する請求項2に記載のマルチメディアファイル。
【請求項3】
各符号化ビデオトラックは、別個の「RIFF」チャンク内に含まれる請求項2に記載のマルチメディアファイル。
【請求項4】
前記ビデオは、心理視覚的強化を用いて符号化される請求項1に記載のマルチメディアファイル。
【請求項5】
各ビデオトラックは、それに対して関係付けられた少なくとも一つのオーディオトラックを有する請求項1に記載のマルチメディアファイル。
【請求項6】
前記各ビデオトラックは、「RIFF」チャンク内における一連の「ビデオ」チャンクとして符号化され、かつ、
前記各ビデオトラックに付随するオーディオトラックは、関係付けられたビデオトラックの「ビデオ」チャンクを含む前記「RIFF」チャンク内に交互配置される一連の「オーディオ」チャンクとして符号化される請求項5に記載のマルチメディアファイル。
【請求項7】
前記各「ビデオ」チャンクは、ビデオトラックからビデオの単一フレームを生成すべく使用され得る情報を含み、かつ、
前記各「オーディオ」チャンクは、「ビデオ」チャンクを用いて生成されるフレームに付随するオーディオトラックの部分からのオーディオ情報を含む請求項6に記載のマルチメディアファイル。
【請求項8】
前記「オーディオ」チャンクは前記「RIFF」チャンク内において対応する前記「ビデオ」チャンクの前に交互配置される請求項7に記載のマルチメディアファイル。
【請求項9】
複数のビデオトラックを符号化し、
前記符号化ビデオトラックを連結し、かつ、
連結された前記符号化ビデオトラックを単一ファイルへと書き込む、
ように構成されるプロセッサを有するマルチメディアファイルを符号化するシステム。
【請求項10】
前記プロセッサは、前記各ビデオトラックが別個の「RIFF」チャンク内に含まれるように前記ビデオトラックを符号化すべく構成される請求項9に記載のシステム。
【請求項11】
前記プロセッサは、心理視覚的強化を用いて前記ビデオを符号化すべく構成される請求項9に記載のシステム。
【請求項12】
各ビデオトラックは、それに関係付けられた少なくとも一つのオーディオトラックを有する請求項9に記載のシステム。
【請求項13】
前記プロセッサは、
前記各ビデオトラックを、「RIFF」チャンク内における一連の「ビデオ」チャンクとして符号化し、かつ、
前記各ビデオトラックに付随する少なくとも一つのオーディオトラックを、前記関係付けられたビデオトラックの「ビデオ」チャンクを含む「RIFF」チャンク内に交互配置された一連の「オーディオ」チャンクとして符号化するように構成される請求項12に記載のマルチメディアファイル。
【請求項14】
前記プロセッサは、
前記ビデオトラックを、各「ビデオ」チャンクが、ビデオトラックからビデオの単一フレームを生成すべく使用され得る情報を含むように符号化し、かつ、
ビデオトラックに関係付けられた前記オーディオトラックを、各「オーディオ」チャンクが、該ビデオトラックから生成された「ビデオ」チャンクを用いて生成されたフレームに付随する前記オーディオトラックの部分からのオーディオ情報を含むように符号化するように構成される請求項13に記載のマルチメディアファイル。
【請求項15】
前記プロセッサは、前記各「オーディオ」チャンクを前記「RIFF」チャンク内の対応する前記「ビデオ」チャンク前に交互配置するように構成される請求項14に記載のマルチメディアファイル。
【請求項16】
マルチメディアファイルから情報を抽出すべく構成されたプロセッサを有し、
前記プロセッサは、前記マルチメディアファイル内に含まれた符号化ビデオトラックの数に関する情報を抽出すべく構成される、
複数の符号化ビデオトラックを含むマルチメディアファイルを復号化するシステム。
【請求項17】
前記プロセッサは、「RIFF」チャンク内で符号化ビデオトラックを検索するために構成される請求項16に記載のシステム。
【請求項18】
第1の符号化ビデオトラックは、標準4ccコードを有する第1「RIFF」チャンク内には含まれ、
第2のビデオトラックは、特殊化4ccコードを有する第2「RIFF」チャンク内には含まれ、かつ、
前記特殊化4ccコードは、その特殊化4ccコードの最後の2個のキャラクタとして、標準4ccコードの最初の2個のキャラクタを有する請求項17に記載のシステム。
【請求項19】
各符号化ビデオトラックは別個の「RIFF」チャンク内に含まれる請求項17に記載のシステム。
【請求項20】
復号化されたビデオトラックは、前記マルチメディアファイルを生成する際に符号化されたオリジナルのビデオトラックと類似する請求項16に記載のシステム。
【請求項21】
前記復号化されたビデオトラックと前記オリジナルのビデオトラックとの間における相違点の少なくとも幾つかは、ビデオトラックの各フレームの暗い部分内に配置される請求項20に記載のシステム。
【請求項22】
前記復号化されたビデオトラックと前記オリジナルのビデオトラックとの間における相違点の少なくとも幾つかは、ビデオトラックの速い動作シーンに配置される請求項20に記載のシステム。
【請求項23】
各ビデオトラックは、それ自身に関係付けられた少なくとも一つのオーディオトラックを有する請求項16に記載のシステム。
【請求項24】
前記プロセッサは、
「RIFF」チャンク内の一連の「ビデオ」チャンクを復号化することによりビデオトラックからビデオを表示し、かつ、
関係付けられたビデオトラックの「ビデオ」チャンクを含む「RIFF」チャンク内に交互配置された一連の「オーディオ」チャンクを復号化することにより、前記ビデオトラックに付随するオーディオトラックからオーディオを生成するように構成される請求項23に記載のシステム。
【請求項25】
前記プロセッサは、
前記ビデオトラックの単一フレームを生成するために、各「ビデオ」チャンクから抽出された情報を使用し、かつ、
「ビデオ」チャンクを使用して生成されたフレームに付随する前記オーディオトラックの部分を生成するために、各「オーディオ」チャンクから抽出された情報を使用するように構成される請求項24に記載のマルチメディアファイル。
【請求項26】
前記プロセッサは、前記「RIFF」チャンクにおいて前記「オーディオ」チャンクが関係付けられた「ビデオ」チャンクの前に、前記「オーディオ」チャンクを検索するように構成される請求項25に記載のマルチメディアファイル。
【請求項27】
一連の符号化ビデオ・フレームと、
前記符号化ビデオ・フレームの間に交互配置された符号化オーディオとを備え、
前記符号化オーディオは、オーディオ情報の2つ以上のトラックを含むことを特徴とするマルチメディアファイル。
【請求項28】
前記オーディオ情報のトラックの内の少なくとも一つのトラックは、複数のオーディオチャネルを含む請求項27に記載のマルチメディアファイル。
【請求項29】
当該マルチメディアファイルに含まれたオーディオトラックの数を特定するヘッダ情報を更に有する請求項27に記載のマルチメディアファイル。
【請求項30】
前記オーディオ情報のトラックの内の少なくとも一つのトラックに関する説明情報を含むヘッダ情報を更に有する請求項27に記載のマルチメディアファイル。
【請求項31】
各符号化ビデオ・フレームは、符号化オーディオ情報により先行され、かつ、
ビデオ・フレームに先行する符号化オーディオ情報は、前記符号化ビデオ・フレームに付随する各オーディオトラックの部分に対するオーディオ情報を含む請求項27に記載のマルチメディアファイル。
【請求項32】
前記ビデオ情報は、当該マルチメディアファイル内にチャンクとして記憶される請求項27に記載のマルチメディアファイル。
【請求項33】
ビデオ情報の各チャンクは、ビデオの単一フレームを含む請求項32に記載のマルチメディアファイル。
【請求項34】
前記オーディオ情報は当該マルチメディアファイル内にチャンクとして記憶され、
2つの別個のオーディオトラックからのオーディオ情報はオーディオ情報の単一チャンク内には含まれない、請求項33に記載のマルチメディアファイル。
【請求項35】
前記ビデオ・チャンクは、前記オーディオトラックの各々からの少なくとも一つのオーディオ・チャンクにより分離される請求項34に記載のマルチメディアファイル。
【請求項36】
前記ビデオ・チャンクを分離する前記オーディオ・チャンクは、そのオーディオ・チャンクに追随するビデオ・チャンク内に含まれたビデオ情報に付随するオーディオトラックの部分に対するオーディオ情報を含む請求項35に記載のマルチメディアファイル。
【請求項37】
ビデオトラックを符号化し、
複数のオーディオトラックを符号化し、
前記ビデオトラックからの情報を、前記複数のオーディオトラックからの情報と交互配置し、かつ、
交互配置されたビデオおよびオーディオ情報を単一ファイルへと書き込む、
ように構成されるプロセッサを有する、マルチメディアファイルを符号化するシステム。
【請求項38】
前記オーディオトラックの内の少なくとも一つのオーディオトラックは複数のオーディオチャネルを含む請求項37に記載のシステム。
【請求項39】
前記プロセッサは、更に、前記符号化オーディオトラックの数を特定するヘッダ情報を符号化し、かつ、そのヘッダ情報を前記単一ファイルに書き込みむべく構成される請求項37に記載のシステム。
【請求項40】
前記プロセッサは、更に、前記符号化オーディオトラックの内の少なくとも一つに関する説明情報を特定するヘッダ情報を符号化し、かつ、そのヘッダ情報を前記単一ファイルに書き込むべく構成される、請求項37に記載のシステム。
【請求項41】
前記プロセッサは、前記ビデオトラックをビデオ情報のチャンクとして符号化する、請求項37に記載のシステム。
【請求項42】
前記プロセッサは、各オーディオトラックをオーディオ情報の一連のチャンクとして符号化する請求項41に記載のシステム。
【請求項43】
オーディオ情報の各チャンクは、単一のオーディオトラックからのオーディオ情報を含む請求項42に記載のシステム。
【請求項44】
前記プロセッサは、ビデオ情報のチャンク間にオーディオ情報のチャンクを交互配置すべく構成される請求項43に記載のシステム。
【請求項45】
前記プロセッサは、「ビデオ」チャンクにおけるビデオ情報に付随する各オーディオトラックの部分を「オーディオ」チャンク内に符号化すべく構成され、かつ、
前記プロセッサは、前記各「ビデオ」チャンクが、その「ビデオ」チャンクに含まれるビデオ情報に付随するオーディオトラックの各々からのオーディオ情報を含む「オーディオ」チャンクにより先行されるように、前記「ビデオ」チャンクで前記「オーディオ」チャンクを交互配置するために構成される請求項44に記載のシステム。
【請求項46】
前記プロセッサは、各ビデオ・チャンク内にビデオの単一フレームが含まれるように前記ビデオトラックを符号化すべく構成される請求項45に記載のシステム。
【請求項47】
前記プロセッサは、汎用プロセッサである請求項45に記載のシステム。
【請求項48】
前記プロセッサは、専用回路である請求項45に記載のシステム。
【請求項49】
マルチメディアファイルから情報を抽出すべく構成されたプロセッサを備え、
前記プロセッサは、前記マルチメディアファイル内に含まれるオーディオトラックの数に関する情報を抽出すべく構成される複数のオーディオトラックを含むマルチメディアファイルを復号化するシステム。
【請求項50】
前記プロセッサは、前記複数のオーディオトラックから単一のオーディオトラックを選択すべく構成され、
前記プロセッサは、前記選択されたオーディオトラックからのオーディオ情報を復号化すべく構成される請求項49に記載のシステム。
【請求項51】
前記オーディオトラックの内の少なくとも一つは、複数のオーディオチャネルを含む、請求項49に記載のシステム。
【請求項52】
前記プロセッサは、前記マルチメディアファイルにおけるヘッダから、前記オーディオトラックの内の少なくとも一つのオーディオトラックに関する説明情報を含む情報を抽出すべく構成される請求項49に記載のシステム。
【請求項53】
ネットワークと、
マルチメディアファイルを含むと共に、サーバを介して前記ネットワークに対して接続された記憶デバイスと、
前記ネットワークに接続されたクライアントとを有し、
前記クライアントは、前記サーバからの前記マルチメディアファイルの転送を要求することができ、かつ、
前記マルチメディアファイルは、少なくとも一つのビデオトラックと、そのビデオトラックに付随する複数のオーディオトラックとを含む、
マルチメディア情報を通信するシステム。
【請求項54】
一連の符号化ビデオ・フレームと、
前記符号化ビデオ・フレーム間に交互配置される少なくとも一つの符号化サブタイトルトラックとを有する、
ことを特徴とするマルチメディアファイル。
【請求項55】
前記少なくとも一つの符号化サブタイトルトラックは、複数の符号化サブタイトルトラックを有する請求項54に記載のマルチメディアファイル。
【請求項56】
当該マルチメディアファイルに含まれた符号化サブタイトルトラックの数を特定するヘッダ情報を更に有する請求項54に記載のマルチメディアファイル。
【請求項57】
前記符号化サブタイトルトラックの内の少なくとも一つに関する説明情報を含むヘッダ情報を更に有する請求項54に記載のマルチメディアファイル。
【請求項58】
各サブタイトルトラックは一連のビットマップを含む請求項54に記載のマルチメディアファイル。
【請求項59】
各サブタイトルトラックは一連の圧縮ビットマップを含む請求項58に記載のマルチメディアファイル。
【請求項60】
各ビットマップはランレングス符号化方法を用いて圧縮される請求項59に記載のマルチメディアファイル。
【請求項61】
前記一連の符号化ビデオ・フレームは、一連のビデオ・チャンクとして符号化され、
各符号化サブタイトルトラックは、一連のサブタイトル・チャンクとして符号化され、
各サブタイトル・チャンクは、表示上にテキストとして表され得る情報を含む請求項54に記載のマルチメディアファイル。
【請求項62】
各サブタイトル・チャンクは、単一のサブタイトルに関する情報を含む請求項61に記載のマルチメディアファイル。
【請求項63】
各サブタイトル・チャンクは、サブタイトルがスーパーインポーズされるべきビデオ・シーケンスの部分に関する情報を含む請求項62に記載のマルチメディアファイル。
【請求項64】
各サブタイトル・チャンクは、サブタイトルが配置されるべき表示の部分に関する情報を含む請求項62に記載のマルチメディアファイル。
【請求項65】
各サブタイトル・チャンクは、サブタイトルの色に関する情報を含む請求項62に記載のマルチメディアファイル。
【請求項66】
色に関する前記情報は、色パレートを含む請求項65に記載のマルチメディアファイル。
【請求項67】
前記サブタイトル・チャンクは、第1色パレートに関する情報を含む第1サブタイトル・チャンクと、該第1色パレートに関する情報に成り代わる第2色パレートに関する情報を含む第2サブタイトル・チャンクとを有する請求項66に記載のマルチメディアファイル。
【請求項68】
ビデオトラックを符号化し、
少なくとも一つのサブタイトルトラックを符号化し、
前記ビデオトラックからの情報を、前記少なくとも一つのサブタイトルトラックからの情報と交互配置し、かつ、
交互配置されたビデオおよびサブタイトル情報を単一ファイルに書き込む、
ように構成されたプロセッサを有するマルチメディアファイルを符号化するシステム。
【請求項69】
前記少なくとも一つのサブタイトルトラックは、複数のサブタイトルトラックを有する請求項68に記載のシステム。
【請求項70】
前記プロセッサは、更に、前記マルチメディアファイルに含まれたサブタイトルトラックの数を特定するヘッダ情報を符号化し、かつ、前記単一ファイルに書き込むべく構成される請求項68に記載のシステム。
【請求項71】
前記プロセッサは、更に、前記サブタイトルトラックの内の少なくとも一つについての説明情報を符号化し、かつ、前記単一ファイルに書き込むべく構成される請求項68に記載のシステム。
【請求項72】
前記ビデオトラックはビデオ・チャンクとして符号化され、かつ、
前記少なくとも一つのサブタイトルトラックの各々は、サブタイトル・チャンクとして符号化される請求項68に記載のシステム。
【請求項73】
前記サブタイトル・チャンクの各々は、前記ビデオトラックの一部に付随する単一のサブタイトルを含み、
インタリーバは、サブタイトル・チャンク内のサブタイトルが付随するビデオトラックの部分を含むビデオ・チャンクに先行して、各サブタイトル・チャンクを交互配置すべく構成される請求項72に記載のシステム。
【請求項74】
前記プロセッサは、前記サブタイトルをビットマップとして符号化することによりサブタイトル・チャンクを生成すべく構成される請求項72に記載のシステム。
【請求項75】
前記サブタイトルは、圧縮ビットマップとして符号化される請求項72に記載のシステム。
【請求項76】
前記ビットマップは、ランレングス符号化方法を用いて圧縮される請求項75に記載のシステム。
【請求項77】
前記プロセッサは、各サブタイトル・チャンク内に、サブタイトルがスーパーインポーズされるべきビデオ・シーケンスの部分に関する情報を含める請求項76に記載のシステム。
【請求項78】
前記プロセッサは、各サブタイトル・チャンク内に、サブタイトルが配置されるべき表示の部分に関する情報を含める請求項73に記載のシステム。
【請求項79】
前記プロセッサは、各サブタイトル・チャンク内に、サブタイトルの色に関する情報を含める請求項73に記載のシステム。
【請求項80】
前記色に関する情報は、色パレートを含む請求項73に記載のシステム。
【請求項81】
前記サブタイトル・チャンクは、第1色パレートに関する情報を含む第1サブタイトル・チャンクと、該第1色パレートに関する情報に成り代わる第2色パレートに関する情報を含む第2サブタイトル・チャンクとを有する請求項80に記載のシステム。
【請求項82】
マルチメディアファイルから情報を抽出すべく構成されるプロセッサを有し、
前記プロセッサは、少なくとも一つのサブタイトルトラックが在るか否かを決定するためマルチメディアファイルを検査するように構成されるマルチメディアファイルを復号化するシステム。
【請求項83】
前記少なくとも一つのサブタイトルトラックは、複数のサブタイトルトラックを有し、かつ、前記プロセッサは、前記マルチメディアファイル内におけるサブタイトルトラックの数を決定すべく構成される請求項82に記載のシステム。
【請求項84】
前記プロセッサは、更に、サブタイトルトラックの数を特定するヘッダ情報を前記マルチメディアファイルから抽出すべく構成される請求項82に記載のシステム。
【請求項85】
前記プロセッサは、更に、前記サブタイトルトラックの内の少なくとも一つのサブタイトルトラックについての説明情報を、前記マルチメディアファイルから抽出すべく構成される請求項82に記載のシステム。
【請求項86】
前記マルチメディアファイルは、ビデオ・チャンクとして符号化された少なくとも一つのビデオトラックを含み、かつ、
前記マルチメディアファイルは、サブタイトル・チャンクとして符号化された少なくとも一つのサブタイトルトラックを含む請求項82に記載のマルチメディアファイルを復号化するシステム。
【請求項87】
各サブタイトル・チャンクは、単一のサブタイトルに関する情報を含む、請求項86に記載のマルチメディアファイルを復号化するシステム。
【請求項88】
各サブタイトルは、前記サブタイトル・チャンク内においてビットマップとして符号化され、
前記プロセッサは、前記ビデオトラックを復号化すべく構成され、かつ、
前記プロセッサは、ビットマップを前記ビデオ・シーケンスの一部上にスーパーインポーズすることにより、表示のためのビデオのフレームを構築すべく構成される請求項87に記載のマルチメディアファイルを復号化するシステム。
【請求項89】
前記サブタイトルは、圧縮ビットマップとして符号化され、かつ、
前記プロセッサは、ビットマップを解凍すべく構成される請求項88に記載のマルチメディアファイルを復号化するシステム。
【請求項90】
前記プロセッサは、ランレングス符号化されたビットマップを解凍すべく構成される、請求項89に記載のマルチメディアファイルを復号化するシステム。
【請求項91】
各サブタイトル・チャンクは、サブタイトルがスーパーインポーズされるべきビデオトラックの部分に関する情報を含み、かつ、
前記プロセッサは、前記サブタイトル・チャンクにおける情報により指示される各ビデオ・フレーム上に前記サブタイトルの前記ビットマップをスーパーインポーズすることにより、表示のための一連のビデオ・フレームを生成すべく構成される請求項88に記載のマルチメディアファイルを復号化するシステム。
【請求項92】
各サブタイトル・チャンクは、該サブタイトルが配置されるべきフレーム内の位置に関する情報を含み、かつ、
前記プロセッサは、前記サブタイトル・チャンク内の情報により指示される各ビデオ・フレーム内の位置に前記サブタイトルをスーパーインポーズすべく構成される請求項88に記載のマルチメディアファイルを復号化するシステム。
【請求項93】
各サブタイトル・チャンクは、前記サブタイトルの色に関する情報を含み、かつ、
前記プロセッサは、前記サブタイトル・チャンク内の色情報により指示される単一もしくは複数の色で前記サブタイトルをスーパーインポーズすべく構成される請求項88に記載のマルチメディアファイルを復号化するシステム。
【請求項94】
前記サブタイトル・チャンク内における前記色情報は、色パレートを含み、かつ、
前記プロセッサは、前記サブタイトルの前記ビットマップにおいて使用される色情報を取得するために前記色パレートを用いて、前記サブタイトルをスーパーインポーズすべく構成される請求項93に記載のマルチメディアファイルを復号化するシステム。
【請求項95】
前記サブタイトル・チャンクは、第1色パレートに関する情報を含む第1サブタイトル・チャンクと、第2色パレートに関する情報を含む第2サブタイトル・チャンクとを有し、かつ、
前記プロセッサは、
第1チャンクが処理された後に前記サブタイトルの前記ビットマップにおいて使用される色に関する情報を取得するために、第1色パレートを用いて、サブタイトルをスーパーインポーズすべく構成され、かつ、
第2チャンクが処理された後にサブタイトルのビットマップにおいて使用される色に関する情報を取得するために、第2色パレートを用いて、サブタイトルをスーパーインポーズすべく構成される請求項94に記載のシステム。
【請求項96】
ネットワークと、
マルチメディアファイルを含むと共に、サーバを介して前記ネットワークに対して接続された記憶デバイスと、
前記ネットワークに接続されたクライアントとを有し、
前記クライアントは、前記サーバからの前記マルチメディアファイルの転送を要求することができ、かつ、
前記マルチメディアファイルは、少なくとも一つのビデオトラックと、そのビデオトラックに付随する少なくとも一つのサブタイトルトラックとを含むマルチメディア情報を通信するシステム。
【請求項97】
一連の符号化ビデオ・フレームと、
符号化されたメニュー情報とを有することを特徴とするマルチメディアファイル。
【請求項98】
前記符号化されたメニュー情報は、チャンクとして記憶される請求項97に記載のマルチメディアファイル。
【請求項99】
少なくとも2つの別個のメニュー情報の「メニュー」チャンクを更に有する請求項98に記載のマルチメディアファイル。
【請求項100】
前記少なくとも2つの別個の「メニュー」チャンクは、少なくとも2つの別個の「RIFF」チャンクに含まれる請求項99に記載のマルチメディアファイル。
【請求項101】
「メニュー」チャンクを含む第1「RIFF」チャンクは、標準4ccコードを含むと共に、「メニュー」チャンクを含む第2「RIFF」チャンクは、特殊化4ccコードを含み、前記標準4ccコードの最初の2個のキャラクタは、前記特殊化4ccコードの最後の2個のキャラクタとして現れる請求項100に記載のマルチメディアファイル。
【請求項102】
少なくとも2つの別個の「menu」チャンクは、単一の「RIFF」チャンク内に含まれる請求項99に記載のマルチメディアファイル。
【請求項103】
前記「メニュー」チャンクは、一連のメニューを記述するチャンクと、該一連のメニューに関係付けられたメディアを含む「MRIF」チャンクとを含む請求項99に記載のマルチメディアファイル。
【請求項104】
前記「MRIF」チャンクは、ビデオトラック、オーディオトラックおよびオーバレイトラックを含むメディア情報を含む、請求項103に記載のマルチメディアファイル。
【請求項105】
一連のメニューを記述する前記チャンクは、
メニュー・システム全体を記述するチャンクと、
前記メニューを言語によりグループ化する少なくとも一つのチャンクと、
個々のメニュー表示と、付随するバックグラウンド・オーディオとを記述する少なくとも一つのチャンクと、
メニュー上のボタンを記述する少なくとも一つのチャンクと、
画面上における前記ボタンの位置を記述する少なくとも一つのチャンクと、
ボタンに関係付けられる種々な動作を記述する少なくとも一つのチャンクとを含む、
請求項103に記載のマルチメディアファイル。
【請求項106】
第2ファイルに対するリンクを更に有し、
符号化されたメニュー情報は、前記第2ファイル内に含まれる請求項97に記載のマルチメディアファイル。
【請求項107】
メニュー情報を符号化すべく構成されたプロセッサを備え、
前記プロセッサは、符号化ビデオトラックおよび符号化メニュー情報を含むマルチメディアファイルを生成するようにも構成されるマルチメディアファイルを符号化するシステム。
【請求項108】
前記プロセッサは、
前記メニューのオブジェクト・モデルを生成し、
前記オブジェクト・モデルをコンフィグ・ファイルへと変換し、
前記コンフィグ・ファイルをチャンクに解析し、
メディア情報を含むAVIファイルを生成し、
前記AVIファイル内のメディアを「MRIF」チャンク内へと交互配置し、かつ、
「メニュー」チャンクを生成するために、前記解析されたチャンクを「MRIF」チャンクと連結するように構成される請求項107に記載のシステム。
【請求項109】
前記プロセッサは更に、第2の更に小さな「メニュー」チャンクを生成するために前記オブジェクト・モデルを使用すべく構成される請求項108に記載のシステム。
【請求項110】
前記プロセッサは、第2メニューを符号化すべく構成される請求項107に記載のシステム。
【請求項111】
前記プロセッサは、第1の符号化メニューを第1「RIFF」チャンクに挿入し、かつ、第2の符号化メニューを第2「RIFF」チャンクに挿入する請求項110に記載のシステム。
【請求項112】
前記プロセッサは、前記第1および第2の符号化メニューを単一の「RIFF」チャンク内に含める請求項110に記載のシステム。
【請求項113】
前記プロセッサは、第2ファイルにおける符号化メニューに対するリファレンスを、前記マルチメディアファイル内に挿入すべく構成される請求項107に記載のシステム。
【請求項114】
マルチメディアファイルから情報を抽出すべく構成されたプロセッサを有し、
前記プロセッサは、前記マルチメディアファイルが符号化されたメニュー情報を含むか否かを決定するために、前記マルチメディアファイルを検査すべく構成されるマルチメディアファイルを復号化するシステム。
【請求項115】
前記プロセッサは、「RIFF」チャンク内の「メニュー」チャンクからメニュー情報を抽出すべく構成される請求項114に記載のシステム。
【請求項116】
前記プロセッサは、前記「メニュー」チャンクに記憶されたビデオ情報を用いてメニュー表示を構築すべく構成される請求項115に記載のシステム。
【請求項117】
前記プロセッサは、前記「メニュー」チャンクに記憶されたオーディオ情報を用いてメニュー表示に付随するバックグラウンド・オーディオを生成すべく構成される請求項115に記載のシステム。
【請求項118】
前記プロセッサは、前記「メニュー」チャンクからのオーバレイを、前記「メニュー」チャンクからのビデオ情報に重ね合わせることによりメニュー表示を生成すべく構成される請求項115に記載のシステム。
【請求項119】
ネットワークと、
マルチメディアファイルを含むと共に、サーバを介して前記ネットワークに対して接続された記憶デバイスと、
前記ネットワークに接続されたクライアントとを備え、
前記クライアントは、前記サーバからの前記マルチメディアファイルの転送を要求することができ、かつ、
前記マルチメディアファイルは、符号化されたメニュー情報を含む、
マルチメディア情報を通信するシステム。
【請求項120】
一連の符号化ビデオ・フレームと、
前記マルチメディアファイルについての符号化メタデータとを有し、
前記符号化メタデータは、主部、述部、目的部および出典を有する少なくとも一つのステートメントを含む、
マルチメディアファイル。
【請求項121】
前記主部は、前記メタデータにより記述されるファイル、項目、人物または組織を特定する情報を含む請求項120に記載のマルチメディアファイル。
【請求項122】
前記述部は、前記主部の特性を表す情報を含む請求項121に記載のマルチメディアファイル。
【請求項123】
前記目的部は、前記述部により特定された前記主部の特性を記述する情報を含む請求項122に記載のマルチメディアファイル。
【請求項124】
前記出典は、前記ステートメントのソースに関する情報を含む請求項123に記載のマルチメディアファイル。
【請求項125】
前記主部は、タイプおよび値を含むチャンクであり、
前記値は、情報を含み、かつ、
前記タイプは、前記チャンクがリソースであるか匿名ノードであるかを指示する請求項120に記載のマルチメディアファイル。
【請求項126】
前記述部は、タイプおよび値を含むチャンクであり、
前記値は、情報を含み、かつ、
前記タイプは、前記値情報が記述URIであるか順序リスト・エントリであるかを指示する請求項120に記載のマルチメディアファイル。
【請求項127】
前記目的部は、タイプ、言語、データタイプおよび値を含むチャンクであり、
前記値は、情報を含み、
前記タイプは、前記値情報がUTF−8リテラル、リテラル整数またはリテラルXMLデータであるかを指示し、
前記データタイプは、前記値情報のタイプを指示し、かつ、
前記言語は特定言語を指定する情報を含む請求項120に記載のマルチメディアファイル。
【請求項128】
前記出典は、タイプおよび値を含むチャンクであり、
前記値は情報を含み、かつ、
前記タイプは、前記値情報が前記ステートメントの出典であることを表す、請求項127に記載のマルチメディアファイル。
【請求項129】
前記符号化データの少なくとも一部は2値データとして表される請求項120に記載のマルチメディアファイル。
【請求項130】
前記符号化データの少なくとも一部は、64ビットASCIデータとして表される請求項120に記載のマルチメディアファイル。
【請求項131】
前記符号化データの少なくとも第1部分は、2値データとして表され、かつ、前記符号化データの少なくとも第2部分は第2フォーマットで表されたデータを含む付加的チャンクとして表される請求項120に記載のマルチメディアファイル。
【請求項132】
前記付加的チャンクは各々、単一断片のメタデータを含む請求項131に記載のマルチメディアファイル。
【請求項133】
ビデオトラックを符号化すべく構成されたプロセッサを備え、
前記プロセッサは、前記マルチメディアファイルに関するメタデータを符号化するようにも構成され、かつ、
前記符号化メタデータは、主部、述部、目的部および出典を備える少なくとも一つのステートメントを含むマルチメディアファイルを符号化するシステム。
【請求項134】
前記主部は、前記メタデータにより記述されるファイル、項目、人物または組織を特定する情報を含む請求項133に記載のシステム。
【請求項135】
前記述部は、前記主部の特性を表す情報を含む請求項134に記載のシステム。
【請求項136】
前記目的部は、前記述部により特定された前記主部の特性を記述する情報を含む請求項135に記載のシステム。
【請求項137】
前記出典は前記ステートメントのソースに関する情報を含む、請求項136に記載のシステム。
【請求項138】
前記プロセッサは、前記主部を、タイプおよび値を含むチャンクとして符号化すべく構成され、
前記値は、情報を含み、かつ、
前記タイプは、チャンクがリソースであるか匿名ノードであるかを表す請求項133に記載のシステム。
【請求項139】
前記プロセッサは、前記述部を、タイプおよび値を含むチャンクとして符号化すべく構成され、
前記値は情報を含み、かつ、
前記タイプは、前記値情報が記述URIであるか順序リスト・エントリであるかを指示する請求項133に記載のシステム。
【請求項140】
前記プロセッサは前記目的部を、タイプ、言語、データタイプおよび値を含むチャンクとして符号化すべく構成され、
前記値は情報を含み、
前記タイプは、前記値情報がUTF−8リテラル、リテラル整数またはリテラルXMLデータであるかを指示し、
データタイプは、前記値情報のタイプを指示し、かつ、
前記言語は特定言語を指定する情報を含む請求項133に記載のシステム。
【請求項141】
前記プロセッサは、前記出典を、タイプおよび値を含むチャンクとして符号化すべく構成され、
前記値は、情報を含み、かつ、
前記タイプは、前記値情報が前記ステートメントの出典であることを指示する請求項133に記載のシステム。
【請求項142】
前記プロセッサは、更に、マルチメディアファイルに関する前記メタデータの少なくとも一部を2値データとして符号化すべく構成される請求項133に記載のシステム。
【請求項143】
前記プロセッサは、更に、前記マルチメディアファイルに関する前記メタデータの少なくとも一部を64ビットASCIデータとして符号化すべく構成される請求項133に記載のシステム。
【請求項144】
前記プロセッサは、更に、
前記マルチメディアファイルに関する前記メタデータの少なくとも第1部分を2値データとして符号化し、かつ、
前記マルチメディアファイルに関する前記メタデータの少なくとも第2部分を、第2フォーマットで表されたデータを含む付加的チャンクとして符号化するように構成される請求項133に記載のシステム。
【請求項145】
前記プロセッサは、更に、前記付加的チャンクを単一断片のメタデータで符号化すべく構成される請求項144に記載のシステム。
【請求項146】
マルチメディアファイルから情報を抽出すべく構成されたプロセッサを有し、
前記プロセッサは、前記マルチメディアファイルに関するメタデータ情報を抽出すべく構成され、かつ、
前記メタデータ情報は、主部、述部、目的部および出典を有する少なくとも一つのステートメントを含むマルチメディアファイルを復号化するシステム。
【請求項147】
前記プロセッサは、前記主部から、前記メタデータにより記述されるファイル、アイテム、人物または組織を特定する情報を抽出すべく構成される請求項146に記載のシステム。
【請求項148】
前記プロセッサは、前記述部から前記主部の特性を表す情報を抽出すべく構成される請求項147に記載のシステム。
【請求項149】
前記プロセッサは、前記目的部から、前記述部により特定される前記主部の特性を記述する情報を抽出すべく構成される請求項148に記載のシステム。
【請求項150】
前記プロセッサは、前記出典から前記ステートメントのソースに関する情報を抽出すべく構成される請求項149に記載のシステム。
【請求項151】
前記主部は、タイプおよび値を含むチャンクであり、
前記プロセッサは、前記タイプを検査することにより、前記チャンクは主部情報を含むことを特定すべく構成され、かつ、
前記プロセッサは、前記値から情報を抽出すべく構成される請求項146に記載のシステム。
【請求項152】
前記述部は、タイプおよび値を含むチャンクであり、
前記プロセッサは、前記タイプを検査することにより、前記チャンクは述部情報を含むことを特定すべく構成され、かつ、
前記プロセッサは、前記値から情報を抽出すべく構成される請求項146に記載のシステム。
【請求項153】
前記目的部は、タイプ、言語、データタイプおよび値を含むチャンクであり、
前記プロセッサは、前記タイプを検査することにより、前記チャンクは、目的部情報を含むことを特定すべく構成され、
前記プロセッサは、前記値に含まれる情報のデータタイプを決定するために、前記データタイプを検査すべく構成され、
前記プロセッサは、前記データタイプにより指示されるタイプの情報を前記値から抽出すべく構成され、かつ、
前記プロセッサは、前記言語から、特定言語を指定する情報を抽出すべく構成される、請求項146に記載のシステム。
【請求項154】
前記出典はタイプおよび値を含むチャンクであり、
前記プロセッサは、前記タイプを検査することにより、チャンクは出典情報を含むことを特定すべく構成され、かつ、
プロセッサは、値から情報を抽出すべく構成される請求項146に記載のシステム。
【請求項155】
前記プロセッサは、前記メタデータ・ステートメントから情報を抽出し、かつ、その情報の少なくとも一部を表示すべく構成される請求項146に記載のシステム。
【請求項156】
前記プロセッサは、前記メタデータを用いて、メモリ内にラベル付き有向グラフを表すデータ構造を構築すべく構成される請求項146に記載のシステム。
【請求項157】
前記プロセッサは、複数のステートメントのための前記主部、述部、目的部および出典の内の少なくとも一つを検査することにより、前記メタデータを介して情報を検索すべく構成される請求項146に記載のシステム。
【請求項158】
前記プロセッサは、前記検索の結果を、グラフィカル・ユーザ・インタフェースの一部として表示すべく構成される請求項157に記載のシステム。
【請求項159】
前記プロセッサは、外部デバイスからの要求に応じて検索を実施すべく構成される請求項157に記載のシステム。
【請求項160】
前記マルチメディアファイルに関する前記メタデータ情報の少なくとも一部は、2値データとして表される請求項146に記載のシステム。
【請求項161】
前記マルチメディアファイルに関する前記メタデータ情報の少なくとも一部は、64ビットASCIデータとして表される請求項146に記載のシステム。
【請求項162】
前記マルチメディアファイルに関する前記メタデータ情報の少なくとも第1部分は、2値データとして表され、かつ、
前記マルチメディアファイルに関する前記メタデータ情報の少なくとも第2部分は第2フォーマットで表されたデータを含む付加的チャンクとして表される請求項146に記載のシステム。
【請求項163】
前記付加的チャンクは単一断片のメタデータを含む請求項162に記載のシステム。
【請求項164】
ネットワークと、
マルチメディアファイルを含むと共に、サーバを介して前記ネットワークに対して接続された記憶デバイスと、
前記ネットワークに接続されたクライアントとを備え、
前記クライアントは、前記サーバからの前記マルチメディアファイルの転送を要求することができ、
前記マルチメディアファイルは、そのマルチメディアファイルに関するメタデータを含み、かつ、
前記メタデータは、主部、述部、目的部および出典を備える少なくとも一つのステートメントを含む、マルチメディア情報を通信するシステム。
【請求項165】
少なくとも一つの符号化ビデオトラックと、
少なくとも一つの符号化オーディオトラックと、
複数の符号化テキスト文字列とを有し、
前記符号化テキスト文字列は、少なくとも一つのビデオトラックおよび少なくとも一つのオーディオトラックの特性を記述する、マルチメディアファイル。
【請求項166】
前記複数のテキスト文字列は、異なる言語を用い、ビデオトラックまたはオーディオトラックと同一の特性を記述する請求項165に記載のマルチメディアファイル。
【請求項167】
少なくとも一つの符号化サブタイトルトラックを更に有し、
前記複数の符号化テキスト文字列は前記サブタイトルトラックの特性を記述する文字列を含む請求項166に記載のマルチメディアファイル。
【請求項168】
少なくとも一つのビデオトラックを符号化し、
少なくとも一つのオーディオトラックを符号化し、
前記符号化オーディオトラックの内の少なくとも一つをビデオトラックと交互配置し、
少なくとも一つのビデオトラックおよび少なくとも一つのオーディオトラックの多数の特性の各々を複数の言語で記述するテキスト文字列を挿入するように構成されたプロセッサを有する、マルチメディアファイルを生成するシステム。
【請求項169】
マルチメディアファイルから符号化テキスト文字列を抽出し、かつ、
テキスト文字列を用いてプルダウン・メニュー表示を生成する、ように構成されたプロセッサを有する、
符号化オーディオ、ビデオおよびテキスト文字列を含むマルチメディアファイルを表示するシステム。
【図1.】
【図2.0.】
【図2.0.1】
【図2.1.】
【図2.2.】
【図2.3.】
【図2.3.1.】
【図2.4.】
【図2.5.】
【図2.6.】
【図2.6.1.】
【図2.7.】
【図2.8.】
【図2.9.】
【図3.0.】
【図3.1.】
【図3.2.】
【図3.3.】
【図3.3.1.】
【図3.4.】
【図3.5.】
【図3.6.】
【図3.7.】
【図3.8.】
【図3.9.】
【図4.0.】
【図4.1.】
【図4.2.】
【図4.3.】
【図2.0.】
【図2.0.1】
【図2.1.】
【図2.2.】
【図2.3.】
【図2.3.1.】
【図2.4.】
【図2.5.】
【図2.6.】
【図2.6.1.】
【図2.7.】
【図2.8.】
【図2.9.】
【図3.0.】
【図3.1.】
【図3.2.】
【図3.3.】
【図3.3.1.】
【図3.4.】
【図3.5.】
【図3.6.】
【図3.7.】
【図3.8.】
【図3.9.】
【図4.0.】
【図4.1.】
【図4.2.】
【図4.3.】
【公開番号】特開2013−13146(P2013−13146A)
【公開日】平成25年1月17日(2013.1.17)
【国際特許分類】
【外国語出願】
【出願番号】特願2012−221387(P2012−221387)
【出願日】平成24年10月3日(2012.10.3)
【分割の表示】特願2006−544074(P2006−544074)の分割
【原出願日】平成16年12月8日(2004.12.8)
【出願人】(506194243)ディブエックス,インコーポレイティド (6)
【Fターム(参考)】
【公開日】平成25年1月17日(2013.1.17)
【国際特許分類】
【出願番号】特願2012−221387(P2012−221387)
【出願日】平成24年10月3日(2012.10.3)
【分割の表示】特願2006−544074(P2006−544074)の分割
【原出願日】平成16年12月8日(2004.12.8)
【出願人】(506194243)ディブエックス,インコーポレイティド (6)
【Fターム(参考)】
[ Back to top ]