コーデック適用フレーム・サイズでの音声スプリッティング
境界アーチファクトを導入することなく、メディア・コンテンツの音声を別々のコンテンツ・ファイルにスプリットする方法および装置について説明する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、インターネットを介したメディア・コンテンツの配信の分野に関し、より具体的には、境界アーチファクトを導入せずに、メディア・コンテンツの音声を、分離した複数のコンテンツ・ファイルにスプリットすることに関する。
【背景技術】
【０００２】
インターネットは、メディア・コンテンツ（例、映像および音声または音声）ならびに他の情報をエンド・ユーザに分配する主要な方法になっている。現在、音楽、映像、ゲーム、他のメディア情報を、コンピュータ、携帯電話、また、実質的にいかなるネットワーク可能デバイスにもダウンロードすることが可能である。人々がメディア・コンテンツを求めてインターネットにアクセスする割合は、急速に伸びている。視聴者体験のクオリティーが、オンラインでの映像視聴の成長のキーとなる障壁である。需要者のテレビ視聴体験および映画視聴体験が、オンライン映像に対する需要者期待をもたらす。
【０００３】
ウェブ上で映像をストリーミングする視聴者数は急速に増えており、映像をインターネットで視聴することへの興味および需要は増している。データ・ファイルのストリーミングまたは「メディアのストリーミング」とは、大きな中断なしに本来期待される再生速度でメディアをユーザに提供するのに十分なレートで、連続したメディア・コンテンツを配信する技術を指す。メディア・ファイルのダウンロードされたデータとは違い、ストリーム化されたデータは、それを再生するまでメモリに格納し、次いで、指定時間が経過した後削除することができる。
【０００４】
電波、衛星、またはケーブルを介した通常のブロードキャストと比較すると、インターネットを介したメディア・コンテンツのストリーミングには、いくつかの課題がある。メディア・コンテンツの音声の符号化の場面で生じる懸念の１つは、映像および音声を複数の固定時間（fixed-time）部分にセグメント化する際の境界アーチファクトの導入である。従来手法の１つでは、音声が、たとえば２秒間といった対応する映像の固定時間幅に合う固定時間幅を有する複数の部分にセグメント化される。この手法では、音声境界が、常に映像境界に整合する。この従来手法では、たとえばＡＡＣ ＬＣ（Ｌｏｗ Ｃｏｍｐｌｅｘｉｔｙ Ａｄｖａｎｃｅｄ Ａｕｄｉｏ Ｃｏｄｉｎｇ）を使用することにより、コンテンツ・ファイルごとに各音声部分を符号化するために音声コーデックの新たな符号化セッションが開始される。音声の各部分ごとに新たな符号化セッションを使用することにより、音声コーデックが、波形の開始および終了を０からの遷移として解釈し、これにより、図１に示すような部分境界での符号化部分の再生中のポップ雑音（pop noise）またはクリック雑音（click noise）が引き起こされる。こうしたポップ雑音またはクリック雑音を、境界アーチファクトと称する。また、音声コーデックが、コーデック適用（codec-enforced）フレーム・サイズに従って固定時間幅の音声を符号化する。これによっても、音声コーデックの作り出すサンプル数がコーデック適用フレーム・サイズで等しく割り切れない場合、境界アーチファクトが導入される。
【０００５】
図１は、ある従来手法を使用した音声の２部分についての例示的音声波形１００を示す図である。音声波形１００は、映像の第１、第２の部分間の０からの遷移１０２を示す。音声コーデックが固定フレーム・サイズ（以降本明細書では、コーデック適用フレーム・サイズと称する）を有する場合、音声コーデックでは、コーデック適用フレーム・サイズに従ったフレーム毎のサンプル数でその部分のサンプル数が等しく割り切れないと、最終フレーム１０４を０で埋める必要がある。たとえば、サンプリング・レート４８ｋＨｚを使用する場合、２秒間の音声セグメントに対して９６０００個のサンプルが生成される。このサンプル数９６０００をフレーム毎のサンプル数（たとえば、ＡＡＣ ＬＣの場合のサンプル数は１０２４、ＨＥ ＡＡＣ（Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ ＡＡＣ）の場合のサンプル数は２０４８）で割ると、フレーム数は９３．７５となる。９３．７５は整数でないので、音声コーデックは、最終フレーム１０４を０で埋める。この例では、最終フレームの最後の２５６個のサンプルに、値０が付与される。値０はサイレント音声を表すが、最終フレームを０で埋めているので、音声の符号化部分の再生中に部分境界でポップ音声またはクリック音声が確認される。０からの遷移１０２および最終フレーム１０４に埋め込まれた０により、境界アーチファクトが導入される。境界アーチファクトが導入されると、音声の全体的な質が低減されることがあり、このことは、メディア・コンテンツの再生中のユーザ体験に影響を及ぼす。
【０００６】
他の従来手法では、フレーム境界との整合をとるために、音声の中からより期間の長い部分を使用することにより、境界アーチファクトの数を制限しようとする。しかし、使用される音声の期間部分がより大きくなると、音声および映像を別々にまとめる必要がある場合がある。このことは、音声および映像を有するメディア・コンテンツのストリーミングに障害をもたらすことがあり、こうした障害は、たとえば、メディア・コンテンツの再生中に様々なクオリティー・レベルへのシフトを可能にするアダプティブ・ストリーミングの場面のように、同一のメディア・コンテンツが様々なクオリティー・レベルで符号化されるときに特にもたらされる。
【図面の簡単な説明】
【０００７】
本発明は、以下の説明、および、本発明の実施形態を図示するのに使用する添付の図面を参照することにより最適に理解することができる。
【図１】ある従来手法を使用した音声の２部分についての例示的音声波形を示す図である。
【図２】本実施形態のエンコーダを用いることのできるコンピューティング環境の一実施形態を示す概略ブロック図である。
【図３Ａ】図２のエンコーダをそれぞれが用いた複数のホストを含めた符号化システムを用いることのできるコンピューティング環境の他の実施形態を示す概略ブロック図である。
【図３Ｂ】一実施形態によるストリームレット（streamlet）の並行符号化の一実施形態を示す概略ブロック図である。
【図４】コーデック適用フレーム・サイズに従ってメディア・コンテンツの音声を符号化して、このメディア・コンテンツの固定時間映像部分を有するコンテンツ・ファイル間で隙間のない音声フレームをスプリットする方法の一実施形態の流れ図である。
【図５Ａ】固定時間映像部分とコーデック適用フレーム・サイズを有する隙間のない音声フレームとを伴うコンテンツ・ファイルの生成の一実施形態の流れ図である。
【図５Ｂ】固定時間映像部分とコーデック適用フレーム・サイズを有する隙間のない音声フレームとを伴うコンテンツ・ファイルの生成の一実施形態の流れ図である。
【図５Ｃ】固定時間映像部分とコーデック適用フレーム・サイズを有する隙間のない音声フレームとを伴うコンテンツ・ファイルの生成の一実施形態の流れ図である。
【図６Ａ】音声スプリッティングの一実施形態による音声部分、映像部分、ストリームレットの図である。
【図６Ｂ】音声スプリッティングを使用した音声の４部分についての音声波形の一実施形態を示す図である。
【図７】一実施形態による音声スプリッティング用のコンピュータ・システムの例示的形態のマシンの図である。
【発明を実施するための形態】
【０００８】
境界アーチファクトを導入せずに、メディア・コンテンツの音声を、分離したコンテンツ・ファイルにスプリットする方法および装置を説明する。一実施形態では、オペレーションを実行するようにプログラムされたコンピューティング・システムにより行われる方法が、音声および映像を含むメディア・コンテンツを受け取ることと、フレーム・レートに従って映像を符号化することと、コーデック適用フレーム・サイズ（すなわち、固定されたフレーム・サイズ）に従って音声を符号化することと、映像のうち固定時間幅を有する符号化済部分と、音声のうち、コーデック適用フレーム・サイズを有する隙間のない音声フレームを有する符号化済部分とをそれぞれが含んだコンテンツ・ファイルを生成することとを含む。一実施形態では、従来行われているようには、音声フレームの最後を０で埋めることはしない。
【０００９】
本発明の実施形態により、音声をストリーミングする改善手法が提供される。メディア・コンテンツの音声の各部分毎に新たな符号化セッションを使用する従来手法と異なり、本明細書に記載する実施形態は、境界アーチファクトを導入することなく、メディア・コンテンツを複数の小部分にセグメント化することを可能にする。本明細書に記載の実施形態では、隙間のない音声フレームを使用することにより、音声がセグメント化される。音声が再生のためにステージ（stage）される際、音声は、境界アーチファクトを有する多数の小セグメントではなく、単一のストリームとしてデコーダに提供される。本明細書に記載の実施形態では、エンコーダが、コーデック・フレーム・サイズ（たとえば、ＡＡＣ-ＬＣの場合のサンプル数は１０２４、または、ＨＥ ＡＡＣの場合のサンプル数は２０４８）、および、コーデックの起動毎にいくつの音声フレームが作られるかを認識する。エンコーダは、符号化されたストリームレット（すなわち、コンテンツ・ファイル）に収めることの可能な数の音声フレームを格納するが、この符号化されたストリームレットは、映像のうち固定時間幅に基づいた部分を有する。最終音声フレームを０で埋めるのではなく、音声の次の部分の隙間のないフレームを符号化し、現在のストリームレットに加える。これにより、普通なら次のストリームレットに書き込まれるはずの少量の音声が、現在のストリームレットに書き込まれる。こうした次のストリームレットには、次いで、音声ストリームが隙間（gap）を示すための時間オフセットが付与され、したがって、音声を再生する際に、連続したストリームとしてデコーダに音声を提供することができる。これと同量の時間が、このストリームレットに対する音声のターゲット期間から差し引かれる。上記次のストリームレットの音声の終わりがフレーム境界に載らない場合、最終フレームを埋めるために、再度次のストリームレットから音声を借りる。このプロセスは、メディア・コンテンツのストリームの最後に達するまで繰り返される。音声が借りられているストリームレットの先頭に挿入された隙間は、このストリームレットの音声部分を復号および再生する前にステージする際に除去することができる。ランダムなストリームレットを得ようとする際には、音声／映像同期を維持するために、隙間の期間にサイレント音声を再生することができる。
【００１０】
本明細書に記載した音声スプリッティングの実施形態により、コーデック適用フレーム・サイズの大きい（例、ＡＡＣ、ＡＣ３等）音声コーデックを使用して、映像に対する同一の固定時間幅を維持しながら、境界アーチファクトを導入することなくメディア・コンテンツの音声を符号化することが可能になる。
【００１１】
以下の説明では、多数の詳細を言及する。ただし、本開示内容から恩恵を受ける当業者には、こうした具体的詳細なしに本発明の実施形態を実践することができることが明らかであろう。いくつかの例では、本発明の実施形態を不明確にすることを避けるために、周知の構造およびデバイスを詳細に図示するのではなく、ブロック図形式で図示している。
【００１２】
以下の詳細な説明のいくつかの部分は、コンピュータ・メモリ内のデータ・ビットへのオペレーションの象徴表現およびアルゴリズムの観点から提供している。こうしたアルゴリズム的な記述および表現は、データ処理技術の当業者が他の当業者に自身の研究の本質を最も効果的に伝えるために使用する手段である。ここでまた一般にアルゴリズムとは、所望の結果をもたらす首尾一貫した一連のステップであると理解される。これらステップは、物理量の物理的操作を必要とするものである。必ずではないが通常、これらの量は、格納すること、転送すること、組み合わせること、比較すること、あるいは操作することの可能な電気信号または磁気信号の形態をとる。一般的な使用法であるということが主な理由であるが、これらの信号を、ビット、値、エレメント、シンボル、キャラクター、ターム（term）、番号等と呼ぶことが都合の良いこともあることが分かっている。
【００１３】
ただし、これらの用語および同様の用語は全て、適当な物理量に関連付けられるべきであり、これらの量に適用される都合の良いラベルにすぎないことを覚えておかれたい。以下の議論から明確であるように具体的に記載がない限り、記載全体を通じて、「受け取ること（receiving）」、「符号化すること（encoding）」、「生成すること（generating）」、「スプリットすること（splitting）」、「処理すること（processing）」、「計算すること（computing）」、「算出すること（calculating）」、「決定すること（determining）」、「表示すること（displaying）」等の用語を利用した議論は、コンピュータ・システムのレジスタおよびメモリ内の物理的（例、電子的）量で表されたデータを操作し、コンピュータ・システム・メモリもしくはレジスタまたは他のこうした情報記憶デバイス、情報送信デバイスもしくは情報表示デバイス内で同様に物理的量を用いて表された他のデータに変換するコンピュータ・システムまたは同様の電子コンピューティング・システムの動作および処理を言及することが理解される。
【００１４】
本発明の実施形態はまた、本明細書内のオペレーションを実行するための装置に関する。この装置は、必要な目的のために具体的に構築することも、自体の中に記憶されたコンピュータ・プログラムに具体的にプログラムされた汎用コンピュータ・システムを備えることもできる。こうしたコンピュータ・プログラムは、フロッピー・ディスク、光学ディスク、ＣＤ-ＲＯＭ、光磁気ディスクを含めた任意の種類のディスクや、ＲＯＭ（リード-オンリ・メモリ）、ＲＡＭ（ランダム・アクセス・メモリ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カードまたは光学カードや、電子的命令を記憶するのに適した任意の種類のメディア等のコンピュータ可読記憶媒体中に記憶することができるが、記憶先はこれらに限定されない。
【００１５】
本明細書で使用する「符号化済ストリームレット」という用語は、メディア・コンテンツの一部分の単一の符号化表現を指す。各ストリームレットは、メディアの一部分を含む個別のコンテンツ・ファイルとすることができ、また、独立したメディア対象として封入することができ、これにより、そのストリームレットを個別にキャッシュに入れること、メディア・プレイヤで独立して要求することおよび独立して再生することが可能になる。本明細書では、これらの個別のファイルをＯＳＳファイルとも称する。一実施形態では、ストリームレットは、特化されたメディア・サーバによってではなく、特化されていないサーバによりサーブ（serve）されることのある静的ファイルである。一実施形態では、ストリームレット内のメディア・コンテンツが、所定の長さの再生時間（固定時間幅とも称する）を有することがある。この所定の長さの時間は、たとえば、約０．１〜８．０秒とすることができる。あるいは、他の所定の長さを使用することもできる。ストリームレット内のメディア・コンテンツは、ストリームに含まれるメディア・コンテンツの先頭に関して一意の時間インデックスを有することがある。ファイル名が、時間インデックスの一部分を含むことがある。あるいは、ストリームレットを、時間インデックスではなくファイルのサイズに従って分割することもできる。本明細書で使用する「ストリーム」という用語は、メディア・コンテンツのうち同一の映像クオリティー・プロファイルで符号化されたストリームレットの集合を指すことがあり、たとえば、映像のうち同一の映像ビット・レートで符号化された部分である。ストリームは、オリジナルのメディア・コンテンツのコピーを表す。ストリームレットは別々のファイルとして、コンテンツ・サーバ、ウェブ・サーバ、キャッシュ・サーバ、プロキシ・キャッシュ、または、コンテンツ・デリバリ・ネットワーク（ＣＤＮ）に見られるようなネットワーク上の他のデバイスのうちの１つまたは複数上に格納することができる。こうした別々のファイル（たとえば、ストリームレット）は、クライアント・デバイスによって、ウェブ・サーバからＨＴＴＰを使用して要求されうる。ＨＴＴＰ等の標準プロトコルを使用することにより、ネットワーク管理者が、ファイアウォールを、ＲＴＳＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）等の特化した新たなプロトコルについてのネットワーク・トラフィックを認識し通過させるように構成する必要がなくなる。さらに、メディア・プレイヤが要求を開始するので、たとえば、ウェブ・サーバは、ストリーム全体ではなく、要求されたストリームレットを取り出し供給することのみ必要とされる。メディア・プレイヤは、２つ以上のウェブ・サーバからストリームレットを取り出すこともできる。これらのウェブ・サーバは、要求された部分を取り出すための、特化したサーバ側知能を伴わないことがある。他の実施形態では、ストリームレットは、ネットワーク・インフラ・オペレータ（例、ＩＳＰ）のキャッシュ・サーバまたはＣＤＮの他のコンポーネント上に別々のファイルとして格納される。本実施形態のうちいくつかはストリームレットの使用について説明するが、本明細書に記載の実施形態は、ストリームレットを使用するコンピューティング・システム内での使用に限定されず、インターネットを介してライブ・メディア・コンテンツを配信する他の技法を使用する他のシステム内で実行することもできる。たとえば、他の実施形態では、ＨＴＴＰ範囲の要求を使用することにより要求でき、ＣＤＮ内でキャッシュに入れることの可能な複数部分に分けられる単一のファイル内にメディア・コンテンツが格納される。
【００１６】
２つの一般的タイプのメディア・ストリーミング、すわわち、プッシュ（push）-ベース・ストリーミングおよびプル（pull）-ベース・ストリーミングが存在する。プッシュ技術は、発行者のコンテンツ・サーバ等のサーバが所与のトランザクションについての要求を開始するインターネット-ベースの通信の方法を説明するものである。対照的に、プル技術は、情報の送信の要求がクライアント・デバイスにより開始され、次いで、サーバにより応答されるインターネット-ベースの通信の方法について説明するものである。ＨＴＴＰ要求（例、ＨＴＴＰ ＧＥＴ要求）は、プル技術における要求の１種類である。対照的に、プッシュ-ベースの技術では、通常、専用のサーバが、ＲＴＳＰ等の専用のプロトコルを使用して、クライアント・デバイスにデータを送り込む。あるいは、いくつかのプッシュ-ベースの技術では、ＨＴＴＰを使用してメディア・コンテンツを配信することがある。プル-ベースの技術では、複数のクライアント・デバイスにメディアを配信するために、ＣＤＮを使用することがある。
【００１７】
本明細書に記載の様々な実施形態はプル-ベースのモデルを対象としたものであるが、プッシュ-ベースの構成等の他の構成内で、これら実施形態を実行することができることに留意されたい。プッシュ-ベースの構成では、エンコーダによる音声スプリッティングの実施形態を、図２に関連して説明するプル-ベースの構成と同様に実行することができ、符号化されたコンテンツ・ファイルをメディア・サーバ等のコンテンツ・サーバ上に格納して、プッシュ-ベースの技術を使用することにより、このメディア・コンテンツを再生用にクライアント・デバイスに配信することができる。これらの実施形態を使用して、メディア・コンテンツの様々なクオリティー・レベルをもたらすことができ、また、これらの実施形態により、一般にアダプティブ・ストリーミングと称される、様々なクオリティー・レベル間での切替えが可能になることにも留意されたい。プッシュ-ベースのモデルでは、メディア・サーバがどのコンテンツ・ファイルをクライアント・デバイスに送るかを決定し、プル-ベースのモデルでは、クライアント・デバイスがどの（１つまたは複数の）コンテンツ・ファイルをコンテンツ・サーバから要求するかを決定することが違いの１つであることがある。
【００１８】
図２は、本実施形態のエンコーダ２２０を用いることのできるコンピューティング環境２００の一実施形態を示す概略ブロック図である。コンピューティング環境２００は、ソース２０５、エンコーダ２２０、コンテンツ配信ネットワーク２４０のオリジン（origin）・コンテンツ・サーバ２１０（メディア・サーバまたはオリジン・サーバとも称する）、それぞれクライアント・デバイス２０４上で動作する複数のメディア・プレイヤ２００を含む。コンテンツ・サーバ２１０と、エンコーダ２２０と、クライアント・デバイス２０４とは、データ通信ネットワークで結合することができる。データ通信ネットワークには、インターネットが含まれることがある。あるいは、コンテンツ・サーバ２１０、エンコーダ２２０、クライアント・デバイス２０４を、共通のＬＡＮ（ローカル・エリア・ネットワーク）、ＰＡＮ（パーソナル・エリア・ネットワーク）、ＣＡＮ（キャンパス・エリア・ネットワーク）、ＭＡＮ（メトロポリタン・エリア・ネットワーク）、ＷＡＮ（ワイド・エリア・ネットワーク）、無線ＬＡＮ、セルラ・ネットワーク、バーチャルＬＡＮ等上に置くこともできる。クライアント・デバイス２０４は、クライアント・ワークステーション、サーバ、コンピュータ、携帯型電子デバイス、もしくは、セット-トップ・ボックス、デジタル・レシーバ、デジタル・テレビ等のネットワークを介して通信を行うように構成されたエンターテイメント・システム、または他の電子デバイスとすることができる。たとえば、携帯型電子デバイスには、携帯電話、携帯型ゲーム・システム、携帯型コンピューティング・デバイス等が含まれることがあるが、これらに限定されない。クライアント・デバイス２０４は、ファイアウォール、ルータ、または他のパケット交換デバイスを介してインターネットにアクセスすることができる。
【００１９】
図示の実施形態では、ソース２０５は、発行者サーバまたは発行者コンテンツ・リポジトリであることがある。ソース２０５は、メディア・コンテンツの作成者または分配者であることもある。たとえば、ストリーム化されるべきメディア・コンテンツがテレビ番組の放送である場合、ソース２０５は、テレビのサーバ、またはＡＢＣ（登録商標）チャンネルやＭＴＶ（登録商標）チャンネル等のケーブル・ネットワーク・チャンネルであることがある。発行者は、インターネットを介してメディア・コンテンツをエンコーダ２２０に転送することができるが、エンコーダ２２０は、メディア・コンテンツを受け取って処理し、このメディア・コンテンツの（１つまたは複数の）コンテンツ・ファイルをオリジン・コンテンツ・サーバ２１０内に格納するように構成することができる。一実施形態では、コンテンツ・サーバ２１０が、メディア・コンテンツをクライアント・デバイス２０４に配信するが、このクライアント・デバイス２０４は、自体上で動作するメディア・プレイヤ上でこのコンテンツを再生するように構成される。コンテンツ・サーバ２１０は、メディア・コンテンツをストリーミングすることにより、これをクライアント・デバイス２０４に配信する。後により詳細に説明するように、更なる実施形態では、クライアント・サーバ２０４が、メディア・コンテンツの様々な部分を、複数の位置から同時にまたは一斉に受け取るように構成される。
【００２０】
コンテンツ・サーバ２１０で格納されたメディア・コンテンツは、他のウェブ・サーバに対して、あるいはＣＤＮ２４０のプロキシ・キャッシュ・サーバに対して複製することができる。複製は、コンテンツ・サーバ２１０から計画的に押し進められることにより、または、コンテンツ・サーバ２１０の外のウェブ・サーバ、キャッシュ・サーバもしくはプロキシ・サーバがクライアント・デバイス２０４のためにコンテンツを求めることにより発生することがある。たとえば、クライアント・デバイス２０４は、複数のウェブ・サーバ、エッジ・キャッシュ、またはプロキシ・キャッシュ・サーバのうちのいずれかからコンテンツを要求し受け取ることができる。図示の実施形態では、ウェブ・サーバ、プロキシ・キャッシュ、エッジ・キャッシュおよびコンテンツ・サーバ２１０をＣＤＮ２４０の階層で編成して、メディア・コンテンツをクライアント・デバイス２０４に配信している。ＣＤＮは、コンテンツを配信するために透過的に協働する、インターネット中でネットワーク化された複数のコンピュータのシステムであり、たとえば、１つまたは複数のオリジン・コンテンツ・サーバ、ウェブ・サーバ、キャッシュ・サーバ、エッジ・サーバ等を含むことがある。通常、ＣＤＮは、たとえば、クライアント・デバイスがエッジ・キャッシュからデータを要求するような階層に構成され、エッジ・キャッシュが要求されたデータを含んでいない場合、その要求は、次には親キャッシュといった具合に、オリジン・コンテンツ・サーバに至るまで送られていく。ＣＤＮは、メディア・コンテンツを配信するために、相互接続されたコンピュータ・ネットワークまたはノードを含むこともある。ＣＤＮのいくつかの例には、Akamai Technologies社、Level3 Communications社、またはLimelight Networks社に開発されたＣＤＮがある。あるいは、他の種類のＣＤＮを使用することもできる。他の実施形態では、オリジン・コンテンツ・サーバ２１０は、本開示内容の恩恵を受ける当業者には理解されるはずの他の構成を使用することにより、メディア・コンテンツをクライアント・デバイス２０４に配信することができる。
【００２１】
一実施形態では、発行者が、ソース２０５から分配するべきオリジナルのコンテンツ・ファイル内にメディア・コンテンツを格納する。コンテンツ・ファイルは、テレビ放送、スポーツ・イベント、映画、音楽、コンサート等に相当する映像および／または音声に相当するデータを含むことがある。オリジナルのコンテンツ・ファイルは、圧縮されていない映像および音声、あるいは圧縮されていない映像または音声を含むことがある。あるいは、コンテンツ・ファイルは、標準的な符号化スキームまたは独自開発の符号化スキームを使用した圧縮済コンテンツ（例、映像および／または音声）を含むことがある。ソース２０５からのオリジナルのコンテンツ・ファイルは、デジタル形式でもよく、たとえば約５Ｍｂｐｓ以上といった高ビット・レートのメディア・コンテンツを含むことができる。
【００２２】
図示の実施形態では、エンコーダ２２０が、たとえば、オリジナルのコンテンツ・ファイル、ライブ・イベント放送の直接供給からの信号、ライブでのテレビ・イベント放送のストリーム等を受け取ることにより、ソース２０５からオリジナルのメディア・コンテンツ２３１を受け取る。エンコーダ２２０は、１つもしくは複数のサーバ・コンピュータ、ゲートウェイまたは他のコンピューティング・デバイスを含む１つまたは複数のマシンに実装することができる。一実施形態では、エンコーダ２２０は、オリジナルのメディア・コンテンツ２３１を、１つまたは複数のコンテンツ・ファイルとして発行システム（図示せず）（例、発行者のサーバまたは発行者のコンテンツ・リポジトリ）から受け取る。あるいは、エンコーダ２２０は、キャプチャ（capture）時のオリジナルのメディア・コンテンツ２３１を受け取る。たとえば、エンコーダ２２０は、被キャプチャ・ブロードキャスト（captured broadcast）等のライブ・テレビ放送の直接供給をストリーム形式または信号形式で受け取ることができる。オリジナルのメディア・コンテンツ２３１は、たとえば、カナダ、オンタリオのDigital Rapids社から入手可能なＤＲＣ-２６００キャプチャ・カード等、テレビ・キャプチャおよび／またはビデオ・キャプチャ向けに構成されたキャプチャ・カードでキャプチャすることができる。あるいは、音声および映像のキャプチャが可能な任意のキャプチャ・カードを本発明では利用することができる。キャプチャ・カードは、エンコーダと同一のサーバ上に置くことも、別のサーバ上に置くこともできる。オリジナルのメディア・コンテンツ２３１は、電波、ケーブル、および／もしくは衛星を介して同時にブロードキャストされる型のブロードキャスト等の被キャプチャ・ブロードキャスト、または、ライブ・イベントのスケジュールに従って特定の時点で再生されるように予定されたプレレコ型（pre-recorded）のブロードキャストであることがある。エンコーダ２２０は、ＤｉｖＸ（登録商標）コーデック、Ｗｉｎｄｏｗｓ Ｍｅｄｉａ Ｖｉｄｅｏ９（登録商標）シリーズ・コーデック、Ｓｏｒｅｎｓｏｎ Ｖｉｄｅｏ（登録商標）３映像コーデック、On2 Technologies（登録商標）社のＴｒｕｅＭｏｔｉｏｎ ＶＰ７コーデック、ＭＰＥＧ-４映像コーデック、Ｈ．２６３映像コーデック、ＲｅａｌＶｉｄｅｏ１０コーデック、ＯＧＧ Ｖｏｒｂｉｓ、ＭＰ３等の符号化スキームを利用することができる。あるいは、カスタマイズした符号化スキームを利用することもできる。
【００２３】
他の実施形態では、エンコーダ２２０は、たとえば２秒間のチャンク等、映像および音声のうちの固定時間幅の部分（本明細書では「メディア・コンテンツの一部分」と称する）としてオリジナルのビデオ・コンテンツ２３１を受け取る。この２秒間のチャンクは、生音声（raw audio）および生映像（raw video）を含むことがある。あるいは、この２秒間のチャンクは、符号化された音声および生映像であることもある。このような場合、エンコーダ２２０は、メディア・コンテンツを展開する。他の実施形態では、エンコーダ２２０は、オリジナルのメディア・コンテンツ２２１を複数の生ストリームレットとして受け取るが、これら生ストリームレットはそれぞれ、メディア・コンテンツの固定時間部分（例、生音声および映像を含んだ複数の２秒間生ストリームレット）を含んでいる。本明細書で使用するように、用語「生ストリームレット」は、圧縮されていないストリームレット、または、著しくクオリティーを失うことなくサイズを実質的に縮減させるために軽く圧縮されたストリームレットのことを指す。軽く圧縮した生ストリームレットは、より急速に送信することが可能である。他の実施形態では、エンコーダ２２０は、オリジナルのメディア・コンテンツ２３１をストリームまたは信号として受け取り、生ストリームレット等、メディア・コンテンツの複数の固定時間部分にセグメント化する。
【００２４】
図示の実施形態では、エンコーダ２２０は、スプリッタ２２２、固定フレーム音声エンコーダ２２４、音声フレーム・バッファ２２５、固定時間映像エンコーダ２２６、映像フレーム・バッファ２２７、音声スプリッティング・マルチプレクサ２２８を有する。スプリッタ２２２は、オリジナルのメディア・コンテンツ２３１を、たとえば音声および映像の連続したストリームとして受け取り、これを生音声２３３および生映像２３５にスプリットする。一実施形態では、固定フレーム音声エンコーダ２２４は音声コーデックである。一実施形態では、スプリッタ２２２が、音声および映像の連続したストリームを音声および映像の複数の２秒間チャンクにスプリットする。コーデック（コンプレッサ-デコンプレッサまたはコーダ-デコーダとも称する）とは、デジタル・データ・ストリームまたはデジタル・データ信号を符号化することおよび／または復号することの可能なデバイスまたはコンピュータ・プログラムである。一実施形態では、固定フレーム音声コーデック２２４は、エンコーダ２２０の１つまたは複数のコンピューティング・デバイスに実行されて生音声２３３を符号化するソフトウェアである。あるいは、固定フレーム音声コーデック２２４は、生音声２３３を符号化するのに使用されるハードウェア論理素子であってもよい。具体的には、固定フレーム音声エンコーダ２２４は、生音声２３３を受け取り、コーデック適用フレーム・サイズ、たとえば、ＡＡＣ-ＬＣではサンプル数１０２４またはＨＥ ＡＡＣではサンプル数２０４８に従って、この音声を符号化する。固定フレーム音声エンコーダ２２４は、符号化済音声フレーム２３７を音声フレーム・バッファ２２５に出力する。同様に、固定時間映像エンコーダ２２６は、生映像２３５をスプリッタ２２０から受け取るが、たとえば、２秒毎に６０フレーム（３０ｆｐｓ（ｆｒａｍｅｓ ｐｅｒ ｓｅｃｏｎｄ））といった固定時間幅に従ってこの映像を符号化する。固定時間映像エンコーダ２２６は、符号化済映像フレーム２３９を映像フレーム・バッファ２２７に出力する。一実施形態では、固定時間映像コーデック２２６は、エンコーダ２２０の１つまたは複数のコンピューティング・デバイスにより実行されて、生映像２３５を符号化するソフトウェアである。あるいは、固定時間映像コーデック２２６は、生映像２３５を符号化するのに使用されるハードウェア論理素子であってもよい。
【００２５】
音声スプリッティング・マルチプレクサ２２８は、符号化済音声フレーム２３７および符号化済映像フレーム２３９を使用して、符号化済メディア・コンテンツ・ファイル２３２（本明細書では「ＱＳＳファイル」と称する）を生成する。上で説明したように、従来のエンコーダは、それぞれが固定された時間幅である映像の一部分および音声の一部分を伴うコンテンツ・ファイルを生成するが、こうしたコンテンツ・ファイルにおいては、音声コーデックに使用されるコーデック適用フレーム・サイズに従って、その部分のサンプル数をフレーム毎のサンプル数で均等に割り切ることができないので、音声の最終フレームが０で埋められる。最終フレームを埋める従来のエンコーダと異なり、音声スプリッティング・マルチプレクサ２２８は、隙間のない音声フレームを使用して、固定時間の映像部分と、コーデック適用フレーム・サイズを有する隙間のない音声フレームを有する音声部分とを有するコンテンツ・ファイルを生成する。音声スプリッティング・マルチプレクサ２２８は、コンテンツ・ファイル２３２を満たすために隙間のない音声フレームを使用するので、従来から行われているようにフレームの最後の数サンプルを０で埋めるのではなく、現在のコンテンツ・ファイル２３２に隙間のないフレームを加えるために音声の次の部分を符号化する。
【００２６】
一実施形態では、音声スプリッティング・マルチプレクサ２２８は、次のコンテンツ・ファイルに使用されるフレーム数を求めるために、次の部分から使用されるサンプルの量を表すサンプル・オフセットを記録する。音声スプリッティング・マルチプレクサ２２８は、音声再生における隙間を示すプレゼンテーション・オフセットも記録する。普通なら次のコンテンツ・ファイルの一部分として再生されるはずのサンプルが、現在のコンテンツ・ファイルの一部分になるので、次のコンテンツ・ファイルのプレゼンテーション・オフセットが、音声再生における隙間を示し、これにより、現在および次のコンテンツ・ファイルの音声部分が、連続したストリームとしてデコーダに提供される。本質的には、音声再生中、コンテンツ・ファイルの音声部分が復号および再生の前にステージされると、コンテンツ・ファイルの先頭に挿入された隙間は除去することができる。プレゼンテーション・オフセットにより、境界アーチファクトを有する多くの小セグメントではなく、連続したストリームとして音声をデコーダに提供することが可能になる。一実施形態では、映像の任意の一部分を探す際、音声／映像同期を維持するために、その隙間の期間はサイレント音声を再生することができる。
【００２７】
一実施形態では、音声スプリッティング・マルチプレクサ２２８が、固定時間幅（例、２秒間）を有する第１の映像部分（例、６０フレーム）と、バッファリングされた隙間のない音声フレームをいくつか有する第１の音声部分とで満たすことにより第１のコンテンツ・ファイルを生成する。このバッファリングされた音声フレームの期間は、固定時間幅よりも長い。
【００２８】
一実施形態では、音声スプリッティング・マルチプレクサ２２８は、現在のコンテンツ・ファイルを満たすのに必要な符号化済音声フレーム２３７の数を求めることによりコンテンツ・ファイル２３２を生成する。一実施形態では、フレームの数は、現在のコンテンツ・ファイルを満たすのに必要なサンプルの数を、コーデック適用フレーム・サイズで割った数（例、フレーム毎のサンプル）以上の最小の整数である。一実施形態では、この数は、たとえば「ｃｅｉｌｉｎｇ（ｘ）＝［ｘ］はｘ以上の最小の整数」といった、実数を次に大きい整数にマップする天井関数（ceiling function）を使用することにより算出することができる。天井関数の一例を以下の式（１）に示す。
ｃｅｉｌ（（ストリームレット当たりのサンプル−オフセット・サンプル）／フレーム当たりのサンプル) （１）
あるいは、他の式を使用することもできる。
【００２９】
音声スプリッティング・マルチプレクサ２２８は、現在のコンテンツ・ファイルを満たすのに十分な符号化済音声フレーム２３７が音声フレーム・バッファ２２５内に存在するかどうかを判定する。十分な符号化済フレームがバッファリングされている場合、音声スプリッティング・マルチプレクサ２２８は、求めた数のフレームで現在のコンテンツ・ファイルを満たす。十分な符号化済フレームがバッファリングされていない場合、音声スプリッティング・マルチプレクサ２２８は、十分な符号化済フレームがバッファ２２５内に格納されるまで待ち、バッファ２２５内に格納された求めた数の符号化済フレームで現在のコンテンツ・ファイルを満たす。一実施形態では、音声スプリッティング・マルチプレクサ２２８は、１）バッファリングされたフレームの数をフレーム当たりのサンプルで掛け、２）前のコンテンツ・ファイルからのサンプル・オフセットがあれば、これを掛け算の積に加え、３）この和が現在のコンテンツ・ファイルを満たすのに必要なサンプル数以上であるかどうかを判定することにより、十分な符号化済フレームがバッファリングされているかどうかを判定する。この演算の一例を以下の式（２）に示す。
バッファリングされたフレーム数＊フレーム当たりのサンプル＋オフセット・サンプル＞＝ストリームレット当たりのサンプル （２）
【００３０】
音声スプリッティング・マルチプレクサ２２８は、次のコンテンツ・ファイルについて、サンプル・オフセットがあればこれを求める。一実施形態では、音声スプリッティング・マルチプレクサ２２８は、コーデック適用フレーム・サイズ（すなわち、フレーム当たりのサンプル）を符号化済フレーム数に掛け、ここから、現在のコンテンツ・ファイルを満たすのに必要なサンプルの数を引き、前のコンテンツ・ファイルからのサンプル・オフセットがあればこれを足すことによりサンプル・オフセットを求める。この演算の一例を以下の式（３）および（４）に示す。
オフセット・サンプル＝送るべきフレーム＊フレーム当たりのサンプル−ストリームレット当たりのサンプル−オフセット・サンプル （３）
送るべきフレーム＝ｃｅｉｌ（（ストリームレット当たりのサンプル−オフセット・サンプル）／フレーム当たりのサンプル） （４）
【００３１】
他の実施形態では、音声スプリッティング・マルチプレクサ２２８は、現在のコンテンツ・ファイルを満たすのに必要なサンプルの数（例、９６０００）を算出することにより、コンテンツ・ファイル２２１を生成する。音声スプリッティング・マルチプレクサ２２８は、現在のコンテンツ・ファイルに必要なフレームの数（例、２秒間部分につき４８Ｋサンプリング・レートの場合９３フレーム）を算出し、サンプルの数がフレーム当たりのサンプルで均等に割り切れない場合には、フレームの数を追加する（たとえば、合計で９４フレームになる）。このことは実質的に、フレーム数を次に大きな整数に切り上げる。音声スプリッティング・マルチプレクサ２２８は、この切り上げた数のフレームで現在のコンテンツを満たす。
【００３２】
一実施形態では、音声スプリッティング・マルチプレクサ２２８は、サンプリング・レート（例、４８Ｋ）に固定時間幅の期間（例、２秒間）を掛けることで、現在のコンテンツ・ファイルを満たすのに必要なサンプルの数（例、９６０００）を算出することによりコンテンツ・ファイル２２１を生成する。音声スプリッティング・マルチプレクサ２２８は、コーデック適用フレーム・サイズ（例、フレーム当たり１０２４サンプル）でサンプル数を割ることにより、現在のコンテンツ・ファイルに必要なフレームの数を算出する。この除算の余りが０であれば、音声スプリッティング・マルチプレクサ２２８は、その数のフレームで現在のコンテンツ・ファイルを満たす。しかし、この除算の余りが０より大きければ、音声スプリッティング・マルチプレクサ２２８は、フレームの数を１だけインクリメントし、このインクリメントした数のフレームで現在のコンテンツ・ファイルを満たす。
【００３３】
更なる実施形態では、音声スプリッティング・マルチプレクサ２２８は、コーデック適用フレーム・サイズをフレームの数に掛けて、現在のコンテンツ・ファイルを満たすのに必要なサンプル数に戻し、サンプル数をサンプリング・レートで割ることで現在のコンテンツ・ファイルの音声の期間を算出（例、ストリームレット期間＝ストリームレット当たりのサンプル／サンプリング・レート）することによりコンテンツ・ファイル２２１を生成する。音声スプリッティング・マルチプレクサ２２８は、固定時間幅からこの期間を引くことにより、次のコンテンツ・ファイルについてのプレゼンテーション・オフセットを求める。音声スプリッティング・マルチプレクサ２２８は、フレーム数にコーデック適用フレーム・サイズを掛け、ここから、現在のコンテンツ・ファイルを満たすのに使用されるサンプルの数を引き、前のコンテンツ・ファイルからのサンプル・オフセットがあればこれを足すことにより（例、式（３））、次のコンテンツ・ファイルについてサンプル・オフセットをアップデートする。
【００３４】
再度図２を参照すると、一実施形態では、スプリッタ２２２がオリジナルのメディア・コンテンツ２３１を生ストリームレットとして受け取る時、スプリッタ２２２は、第１および第２の生ストリームレットを受け取り、この第１および第２の生ストリームレットの音声および映像をスプリットする。固定時間映像エンコーダ２２６が、第１および第２の生ストリームレットの映像を符号化し、音声スプリッティング・マルチプレクサ２２８が、第１の生ストリームレットの符号化された映像を第１のコンテンツ・ファイルに格納し、第２の生ストリームレットの符号化された映像を第２のコンテンツ・ファイルに格納する。固定フレーム音声エンコーダ２２４は、第１の生ストリームレットの音声を音声フレームの第１の組に符号化し、この第１の組を音声フレーム・バッファ２２５に格納する。音声スプリッティング・マルチプレクサ２２８は、第１のコンテンツ・ファイルを満たすのに十分なバッファリングされたフレームが存在するかどうかを判定する。十分でなければ、固定フレーム音声エンコーダ２２４は、第２の生ストリームレットの音声を音声フレームの第２の組に符号化し、この第２の組を音声フレーム・バッファ２２５に格納する。第１のコンテンツ・ファイルを満たすだけの十分なバッファリングされたフレームが存在すれば（場合によっては、もう１つの隙間のないフレームがバッファ２２５に格納されれば）、音声スプリッティング・マルチプレクサ２２８は、バッファリングされた音声フレームを第１のコンテンツ・ファイルに格納する。エンコーダ２２０は、メディア・コンテンツが終了するまでこのプロセスを継続する。
【００３５】
また、音声スプリッティング・マルチプレクサ２２８は隙間のない音声フレームを使用するので、図６Ａおよび６Ｂに示すように、１つのコンテンツ・ファイル２３２内の音声フレームは、映像部分境界と必ずしも整合する必要はない。たとえば、コンテンツ・ファイル２３２の音声部分の期間が、２．００５３秒であり、コンテンツ・ファイル２３２の映像部分の固定時間幅が、２．００秒であることがある。この例では、コーデック適用フレーム・サイズがフレーム当たり１０２４サンプルであり、音声のサンプリング・レートが４８Ｋであり、９４フレームからなる９６２５６サンプルが、コンテンツ・ファイル２３２に記憶された音声部分に格納されている。コンテンツ・ファイル２３２には余分な５３ミリ秒（ｍｓ）が存在するゆえに、固定時間幅音声符号化スキームを使用する場合には次のコンテンツ・ファイル内にあるはずの５３ｍｓの期間を有するサンプルが現在のコンテンツ・ファイル２３２により使用されるので、音声スプリッティング・マルチプレクサ２２８は、次のコンテンツ・ファイルに５３ｍｓのプレゼンテーション・オフセットを与える。また、音声スプリッティング・マルチプレクサ２２８は、次のコンテンツ・ファイルを満たすのに必要な音声フレーム数を求めるためにサンプル・オフセットを記録する。一実施形態では、音声スプリッティング・マルチプレクサ２２８は、固定時間幅を有する符号化済映像部分のうちの１つで、それぞれのコンテンツ・ファイルを満たす（たとえば、フレーム・レートが３０ｆｐｓであれば、６０映像フレーム当たり２秒間）。音声スプリッティング・マルチプレクサ２２８は、コンテンツ・ファイルのうちのいくつかを、いくつかのバッファリングされた音声フレームで満たすが、これら音声フレームの期間は、音声スプリッティング・マルチプレクサ２２８により決まる映像部分境界に音声フレームが整合するかどうかに応じて、固定時間幅よりも大きいこと、固定時間幅よりも小さいこと、または、固定時間幅と等しいことがある。
【００３６】
図６Ａを参照すると、一実施形態では、音声スプリッティング・マルチプレクサ２２８は、２秒間からなる固定時間幅に等しい期間の約６０の映像フレームを有する第１の映像部分６１１と、それぞれがフレーム当たり１０２４のサンプルを有し、合計９６２５６サンプルとなる９４の音声フレームを有する第１の音声部分６２１とで満たすことにより、第１のストリームレット（すなわち、コンテンツ・ファイル）６０１を生成する。第１の音声部分６２１の期間は、約２．００５３秒である。第１のストリームレット６０１の音声境界６５２と映像境界６５４とが再生について整合しているので、音声スプリッティング・マルチプレクサ２２８は、第１のストリームレット６０３の第１の音声部分６３１のプレゼンテーション・オフセットを０と判定する。
【００３７】
音声スプリッティング・マルチプレクサ２２８は、第２の映像部分６１２（６０フレーム、２秒間）と、９４の音声フレームを有する第２の音声部分６２２とで満たすことにより第２のストリームレット６０２を生成する。第２の音声部分６２２の期間は、約２．００５３秒である。第１のストリームレット６０１の第１の音声部分６２１の期間が約２．００５３秒なので、音声スプリッティング・マルチプレクサ２２８は、第２のストリームレット６０２の第２の音声部分６３２のプレゼンテーション・オフセットを約５．３ミリ秒（ｍｓ）と判定する。このプレゼンテーション・オフセットは、第１のストリームレット６０１と第２のストリームレット６０２との間の音声の隙間を示す。図６Ｂに示すように、第２のストリームレット６０２の音声境界６５２と映像境界６５４とは、再生について整合していない。このプレゼンテーション・オフセットを使用して、第１および第２のストリームレット６０１および６０２の音声部分が、連続したストリームとしてデコーダに提供されるようにステージされることを可能にすることができる。
【００３８】
音声スプリッティング・マルチプレクサ２２８は、第３の映像部分６１３（６０フレーム、２秒間）と、９４の音声フレームを有する第３の音声部分６２３とで満たすことにより第３のストリームレット６０３を生成する。第３の音声部分６２３の期間は、約２．００５３秒である。第２のストリームレット６０２の第２の音声部分６２２の期間が約２．００５３秒なので、音声スプリッティング・マルチプレクサ２２８は、第３のストリームレット６０３の第３の音声部分６３３のプレゼンテーション・オフセットを約１０．６６ｍｓと判定する。このプレゼンテーション・オフセットは、第２のストリームレット６０２と第３のストリームレット６０３との間の音声の隙間を示す。図６Ｂに示すように、第３のストリームレット６０３の音声境界６５２と映像境界６５４とは、再生について整合していない。このプレゼンテーション・オフセットを使用して、第２および第３のストリームレット６０２および６０３の音声部分が、連続したストリームとしてデコーダに提供されるようにステージされることを可能にすることができる。
【００３９】
音声スプリッティング・マルチプレクサ２２８は、第４の映像部分６１４（６０フレーム、２秒間）と、９３の音声フレームを有する第４の音声部分６２４とで満たすことにより第４のストリームレット６０４を生成する。第４の音声部分６２４の期間は、約１．９８４秒である。第３のストリームレット６０３の第３の音声部分６２３の期間が約２．００５３秒なので、音声スプリッティング・マルチプレクサ２２８は、第４のストリームレット６０４の第４の音声部分６３４のプレゼンテーション・オフセットを約１６ｍｓと判定する。このプレゼンテーション・オフセットは、第３のストリームレット６０３と第４のストリームレット６０４との間の音声の隙間を示す。図６Ｂに示すように、第４のストリームレット６０３の音声境界６５２と映像境界６５４とは、再生について整合していない。このプレゼンテーション・オフセットを使用して、第３および第４のストリームレット６０３および６０４の音声部分が、連続したストリームとしてデコーダに提供されるようにステージされることを可能にすることができる。しかし、第４のストリームレット６０４の後、音声境界６５２と映像境界６５４とは整合し、このことは、第５のストリームレット（図示せず）が０のプレゼンテーション・オフセットを有することを意味する。図６Ａおよび６Ｂの実施形態では、サンプリング・レートが４８ｋＨｚであり、固定時間幅が２秒間であり、コーデック適用フレーム・サイズがフレーム当たり１０２４サンプルであることに留意されたい。
【００４０】
上記の実施形態では、３つの第１のストリームレット６０１〜６０３の音声部分が、９４の音声フレームを有し、第４のストリームレット６０４の音声部分が、９３の音声フレームを有する。この実施形態では、映像が３０ｆｐｓで符号化される場合、第４のコンテンツ・ファイル６０１〜６０４の映像部分のそれぞれは、約６０の映像フレームを有する。このパターンは、メディア・コンテンツの終わりに達するまで繰り返される。この実施形態では、各第４のコンテンツ・ファイルの後に、プレゼンテーション・オフセットおよびサンプル・オフセットが０になり、このことは、各第４のコンテンツ・ファイルの後に、音声境界６５２と映像境界６５４とが整合することを意味することに留意されたい。
【００４１】
図６Ｂから分かるように、８秒間のメディア・コンテンツの後、映像境界と音声境界とが整合する。よって、境界アーチファクトの頻度を減らし、ＡＡＣフレーム・サイズを整合させる他の手法の１つは、８秒間を固定時間幅に使用するものになるはずである。しかし、こうした手法には、以下の不利な点がある。１）この手法には、８、１６、３２秒等のチャンク・サイズの大きな映像が必要である。２）この手法では、特定のフレーム・サイズ、すなわちフレーム当たり１０２４サンプルに実施が拘束される。フレーム・サイズをたとえば２０４８等に変更する場合、この手法では、異なるフレーム・サイズを伴う音声コーデックに切り替えねばならず、映像のチャンク期間も変更せねばならない。３）この手法では、音声サンプル・レートが常に４８ｋＨｚである必要がある。４４．１ｋＨｚ等の他の一般的なサンプル・レートでは、異なる、かつ、場合によってはずっと大きなチャンク・サイズが必要である。あるいは、ソース（source）音声を４８ｋＨｚにアップ・サンプルしなければならない。しかし、アップ・サンプルすれば、アーチファクトが導入され、音声コーデックの効率が低減されることがある。しかし、本明細書に記載の実施形態では、同一のチャンク期間を維持しながら、チャンク境界アーチファクトを導入することなく、大きなフレーム・サイズ（ＡＡＣ、ＡＣ３等）を伴う音声コーデックを使用することにより符号化を行うことができる。
【００４２】
あるいは、他のサンプリング・レート（例、４４．１ｋＨｚ）、固定時間幅（例、０．１〜５．０秒）、映像フレーム・レート（例、２４ｆｐｓ、３０ｆｐｓ等）、および／またはコーデック適用フレーム・サイズ（例、２０４８）を使用することもできる。ソース映像が異なれば、異なるフレーム・レートが使用される。米国のほとんどの無線信号は、３０ｆｐｓ（実際には、２９．９７）である。いくつかのＨＤ信号は、６０ｆｐｓ（５９．９４）である。ファイル-ベースのコンテンツのいくつかは２４ｆｐｓである。一実施形態では、エンコーダ２２０は、追加のフレームを生成することが必要になるので映像のフレーム・レートを上昇させない。しかし、追加のフレームを生成することは、この追加の負荷ついて大した恩恵をもたらさない。したがって、たとえば、オリジナルのメディア・コンテンツのフレーム・レートが２４ｆｐｓの場合、エンコーダ２２０は、３０ｆｐｓにアップ・サンプルするのではなく２４ｆｐｓのフレーム・レートを使用する。しかし、いくつかの実施形態では、エンコーダ２２０は、フレーム・レートをダウン・サンプルすることがある。たとえば、オリジナルのメディア・コンテンツのフレーム・レートが６０ｆｐｓの場合、エンコーダ２２０は、３０ｆｐｓにダウン・サンプルすることがある。６０ｆｐｓを使用すると、目標とするビット・レートで符号化することが必要なデータの量が２倍になって、クオリティーが損なわれることがあるので、こうしたダウン・サンプルが行われることがある。一実施形態では、エンコーダ２２０は、ダウン・サンプリング後のまたは受け取られるフレーム・レート（通常は３０ｆｐｓまたは２４ｆｐｓ）を求めると、クオリティー・プロファイルのほとんどについてこのフレーム・レートを使用する。最低クオリティー・プロファイル等のいくつかのクオリティー・プロファイルには、より低いフレーム・レートが使用されることがある。しかし、他の実施形態では、たとえば、携帯電話や計算能力が劣っている等の資源の限られた他のデバイスを対象とするために、エンコーダ２２０は、異なるクオリティー・プロファイルに対して異なるフレーム・レートを使用することができる。これらのケースでは、より低いフレーム・レートを伴うプロファイルをより多く有することが有益なことがある。
【００４３】
これらのパラメータに対して他の値を使用する場合、音声境界６５２および映像境界６５４が図６Ｂに示す実施形態とは異なってくる場合があることに留意されたい。たとえば、サンプリング・レートとして４４．１ｋＨｚ、コーデック適用フレーム・サイズとして１０２４、固定時間幅として２秒間を使用する場合、第１のコンテンツ・ファイルの音声部分は、８７の音声フレームを有することとなり、第２〜第７のコンテンツ・ファイルは、８６の音声フレームを有することとなる。このパターンは、メディア・コンテンツ内に残る映像が不十分になるまで繰り返される。この実施形態では、１２８のコンテンツ・ファイルの後毎に、プレゼンテーション・オフセットおよびサンプル・オフセットが０になり、このことは、略表１-１に示すように、音声境界６５２と映像境界６５４とが１２８番目のコンテンツ・ファイルの後毎に整合することを意味することに留意されたい。
【表１】
上の表中のサンプル・オフセットは、説明を簡単にするために、秒やミリ秒ではなく、サンプル単位で示していることに留意されたい。サンプル・オフセットをプレゼンテーション・オフセットに変換する場合、サンプル・オフセットを４４１００で割って、秒で表したプレゼンテーション・オフセットを求め、これに１０００を掛けて、ミリ秒で表したプレゼンテーション・オフセットを得ることができる。一実施形態では、ミリ秒で表したプレゼンテーション・オフセットが、ストリームレット・ヘッダに記憶されることがある。あるいは、プレゼンテーション・オフセットまたはサンプル・オフセットが、他の単位でストリームレット・ヘッダに記憶されることもある。
【００４４】
他の実施形態では、音声スプリッティング・マルチプレクサ２２８は、固定時間幅を有する符号化済映像フレーム２３９（例、固定時間幅部分）でそれぞれを埋めることにより複数の符号化済コンテンツ・ファイル２３２を生成し、これらコンテンツ・ファイル２３２をいくつかの隙間のない音声フレーム２３７で満たすが、コンテンツ・ファイル２３２内で使用されている隙間のない音声フレームを収容するように、音声フレーム２３７の期間は、固定時間幅より短く、またはこれより長くなっている。たとえば、映像のうち２秒間等の固定時間幅を有する部分と、固定時間幅よりも長い期間を有する隙間のない複数の音声フレームを有する音声部分とで第１のコンテンツ・ファイルを満たすことができる。そのうち、サンプル・オフセットが大きくなって、使用することのできる音声フレームの数が小さくなり、この場合、音声フレームの期間が、固定時間幅より短くなる場合がある。折に触れて、音声の音声境界が、映像の映像境界にマッチすることができる。
【００４５】
他の実施形態では、音声スプリッティング・マルチプレクサ２２８は、映像の第１の部分の映像フレームと、音声の第１の部分からの音声フレームと、第２の部分からの音声フレームとを有する第１のコンテンツ・ファイルを生成することにより、符号化済コンテンツ・ファイル２３２を生成する。音声スプリッティング・マルチプレクサ２２８は、映像の第２の部分の映像フレームを有する第２のコンテンツ・ファイルを生成する。音声の場合、音声スプリッティング・マルチプレクサ２２８は、音声境界が映像境界に載るかどうかを判定する。音声境界が映像境界に載る場合、音声スプリッティング・マルチプレクサ２２８は、第２の部分の残りの音声フレームで第２のコンテンツ・ファイルを満たす。しかし、音声境界が映像境界に載らない場合、音声スプリッティング・マルチプレクサ２２８は、メディア・コンテンツの第３の部分の音声フレームを符号化し、第２の部分の残りの音声フレームおよび第３の部分からの音声フレームで第２のコンテンツ・ファイルを満たす。このプロセスは、コンテンツ・ファイルの終わりに達するまで繰り返される。
【００４６】
再度図２を参照すると、エンコーダ２２０は、オリジナルのメディア・コンテンツ２３１を符号化すると、オリジン・コンテンツ・サーバ２１０に符号化済メディア・コンテンツ・ファイル２３２を送り、オリジン・コンテンツ・サーバ２１０は、ネットワーク接続２４１を介して、符号化済メディア・コンテンツ２３２をメディア・プレイヤ２００に配信する。メディア・プレイヤ２００は、映像の固定時間幅および音声の可変時間幅を有するコンテンツ・ファイルを受け取ると、これらコンテンツ・ファイルのプレゼンテーション・オフセットを使用して、音声を連続したストリームとしてデコーダに提供するようにステージし、これにより、境界アーチファクトにもたらされるポップ雑音またはクリック雑音を除去または低減する。本質的に、音声の再生中、メディア・プレイヤ２００は、コンテンツ・ファイルの音声部分が復号および再生の前にステージされると、コンテンツ・ファイルの先頭に挿入された隙間を除去する。他の実施形態では、本明細書に記載する音声スプリッティングを行わず、最終フレームを０で埋める場合は、メディア・プレイヤ２００を、音声をデコーダに送る前に最終フレームの埋められたサンプルを除去するように構成することができる。しかし、この手法は、特定の状況では実用的でないことがあり、たとえば、メディア・プレイヤが第３者により提供されるとき、または、復号後の音声フレームのデータへのアクセスが制限されるときである。
【００４７】
各メディア・プレイヤ２００に１つの線を示しているが、各線２４１がＣＤＮ２４０への複数のネットワーク接続を表すこともあることに留意されたい。一実施形態では、各メディア・プレイヤ２００が、ＣＤＮ２４０への複数のＴＣＰ（伝送制御プロトコル）接続を確立することがある。他の実施形態では、メディア・コンテンツが、複数のＣＤＮ、たとえば、複数のＣＤＮのそれぞれに関連するオリジン・サーバに格納される。ＣＤＮ２４０は、帯域幅コストを削減し、コンテンツの全体的使用可能度を増大させることにより、エンド・ユーザ（例、視聴者）に対する性能、スケーラビリティ、費用効果性の改善の目的で使用することができる。ＣＤＮは様々なやり方で実現することができ、それらのオペレーションについての詳細は、当業者には理解されるはずである。したがって、それらのオペレーションについての更なる詳細は含めていない。他の実施形態では、ピア・ツー・ピア・ネットワーク等の他の配信技法を使用して、オリジン・サーバからメディア・プレイヤにメディア・コンテンツを配信することができる。
【００４８】
上で説明した実施形態では、コンテンツ・ファイル２３２は、オリジナルのメディア・コンテンツ・ストリーム２３１のコピーの１つを表す。しかし、他の実施形態では、オリジナルのメディア・コンテンツ２３１の各部分を符号化して、コンテンツの同一部分の複数の符号化表現とすることができる。これら複数の符号化表現は、様々なクオリティー・プロファイルに従って符号化し、クライアント・デバイス２０４から独立して要求すること、クライアント・デバイス２０４により独立して再生することのできる別々のファイルとして格納することができる。これらのファイルはそれぞれ、１つまたは複数のコンテンツ・サーバ２１０内、ＣＤＮ２４０のウェブ・サーバ、プロキシ・キャッシュ、エッジ・キャッシュ上に格納することができ、別々に要求し、クライアント・デバイス２０４に配信することができる。一実施形態では、エンコーダ２２０は、たとえば１０または１３等のいくつかの異なるクオリティー・レベルでオリジナルのコンテンツ・メディア２３１を同時に符号化する。各クオリティー・レベルをクオリティー・プロファイルまたはプロファイルと称する。たとえば、メディア・コンテンツが１時間の期間を有し、２秒間の期間を有する複数のＱＳＳファイルにセグメント化される場合、メディア・コンテンツの符号化表現毎に１８００のＱＳＳファイルが存在する。メディア・コンテンツを異なる１０個のクオリティー・プロファイルに従って符号化する場合、このメディア・コンテンツについて１８０００のＱＳＳファイルが存在する。こうしたクオリティー・プロファイルは、どのようにストリームを符号化するかを示すことがあり、たとえば、画像の幅および高さ（すなわち、画像サイズ）、映像ビット・レート（すなわち、映像を符号化する速度）、音声ビット・レート、音声サンプル・レート（すなわち、キャプチャする際に音声をサンプリングする速度）、音声トラックの数（例、モノ、ステレオ等）、フレーム・レート（例、ｆｐｓ）、ステージング・サイズ等のパラメータを特定することがある。たとえば、複数のメディア・プレイヤ２００が、異なるクオリティー・レベルの同一のメディア・コンテンツ２３２を個別に要求することができる。たとえば、各メディア・プレイヤ２００が、メディア・コンテンツ２３２の同一の部分（例、同一の時間インデックス）を様々なクオリティー・レベルで要求することができる。たとえば、あるメディア・プレイヤが、自体のコンピューティング・デバイスが十分な計算能力および十分なネットワーク帯域幅を有するがゆえに、ＨＤクオリティー映像を有するストリームレットを要求し、他のメディア・プレイヤが、たとえば、自体のコンピューティング・デバイスが十分なネットワーク帯域幅を有することができないがゆえに、クオリティーのより低いストリームレットを要求することがある。一実施形態では、出願日２００５年４月２８日の米国特許出願公開第２００５／０２６２２５７号に記載されるように、メディア・プレイヤ２００は、メディア・コンテンツの様々なコピー（例、様々なクオリティー・ストリームレット）からそれぞれの部分を要求することにより、部分境界においてクオリティー・レベルをシフトする。あるいは、メディア・プレイヤ２００は、本開示内容の恩恵を受ける当業者に理解されるべき他の技法を使用することにより、それらの部分を要求することもできる。
【００４９】
エンコーダ２２０は、メディア・コンテンツの特定の部分にどのクオリティー・プロファイルが利用可能かを特定することもでき、また、どのくらいのメディア・コンテンツが、たとえばＱＭＸファイルを使用することによる配信に使用可能かを特定することができる。ＱＭＸファイルは、利用可能なＱＳＳファイルで表されたメディア・コンテンツの現在の期間を示す。ＱＭＸファイルは、メディア・コンテンツに対する目次として機能して、どのＱＳＳファイルが配信のために利用可能か、及び、どこからＱＳＳファイルを取り出すことができるかを示すことができる。ＱＭＸファイルは、たとえば、ＣＤＮ２４０を介してメディア・プレイヤ２００に送ることができる。あるいは、メディア・プレイヤ２００が、特定のメディア・コンテンツに対して利用可能なクオリティー・プロファイルを要求することもできる。他の実施形態では、ＣＤＮのスケーリング能力を使用することによりこの構成のスケール変えを行って、ＨＴＴＰトラフィックを複数のメディア・プレイヤ２００に配信することができる。たとえば、符号化されたメディア・コンテンツを格納するデータ・センタが、このデータ・センタからの符号化されたメディア・コンテンツを要求する複数のメディア・プレイヤにサービスするためにオリジン・コンテンツ・サーバ２１０からなるクラスタを有することがある。あるいは、本開示内容の恩恵を受ける当業者には理解されるはずの他の構成を使用することもできる。
【００５０】
熟考した一実施形態では、メディア・プレイヤ２００は、個々のストリームレット・ファイル（例、ＱＳＳファイル）を要求することによりメディア・コンテンツのそれぞれの部分を要求する。メディア・プレイヤ２００は、メタデータ・ディスクリプタ・ファイル（例、ＯＭＸファイル）に従ってＱＳＳファイルを要求する。メディア・プレイヤ２００は、たとえば、提供用のメディア・コンテンツをユーザが選択することに応答して、ＱＭＸファイルをフェッチし、また、このＱＭＸファイルを読んで、現在の期間を使用することによるメディア・コンテンツの再生の開始をいつにするか、どこにＱＳＳファイルを要求するかを決定する。ＱＭＸファイルは、いつ符号化プロセスを開始するか（例、メディア・コンテンツの開始時刻）を示すＵＴＣ（協定世界時）インジケータ等のＱＭＸタイムスタンプと、どれくらい多くのメディア・コンテンツが配信に使用可能かを示す現在の期間（current duration）とを含む。たとえば、ＱＭＸタイムスタンプは、符号化プロセスが午後６時に開始され（ＭＤＴ）、メディア・コンテンツの４５００個のＱＳＳファイルが配信に使用可能であることを示すことができる。メディア・プレイヤ２００は、コンテンツの期間（ライブ再生）が約１５分であると判定し、プログラム開始後の１５分間またはこれよりやや前のポイントにおけるプログラムの再生に対応するＱＳＳファイルの要求を開始することを決定することができる。一実施形態では、メディア・プレイヤ２００は、メディア・コンテンツ内のオフセットにおける対応するストリームレットをフェッチすることにより、メディア・プレイヤ２００がコンテンツの再生を開始すべきメディア・コンテンツ内のポイントを求めることができる。エンコーダがＱＳＳファイルの他の組をコンテンツ・サーバ上に格納する毎に（例、メディア・コンテンツの次の２秒間をそれぞれ異なる１０のクオリティー・レベルで表す１０個のＱＳＳファイルの組）、ＱＭＸファイルはアップデートされ、メディア・プレイヤ２００でＱＭＸファイルをフェッチして、インターネットを介して更に２秒間が配信に使用可能であることを示すことができる。メディア・プレイヤ２００は、アップデートされるＱＭＸファイルについて定期的にチェックすることができる。あるいは、ＱＭＸファイルおよび任意のアップデートをメディア・プレイヤ２００に送り込んで、メディア・コンテンツがいつインターネット介した配信に使用可能であるのかを示すこともできる。
【００５１】
オリジン・コンテンツ・サーバ２１０は、ＣＤＮ２４０内にあるものとして図示しているが、これがＣＤＮ２４０の外側にあり、やはりＣＤＮ２４０に関連することができることに留意されたい。たとえば、１つのエンティティが、ストリームレットを格納するコンテンツ・サーバを所有、動作することができるが、自体のデバイスが１つまたは複数の別々のエンティティにより所有、動作されることのあるＣＤＮ２４０が、ストリームレットを配信する。
【００５２】
メディア・コンテンツは、（電子デバイス（すなわち、クライアント・デバイス）上で動作している）メディア・プレイヤ２００により処理されると、メディア・プレイヤ２００がイベントの視覚および／または音声表現をメディア・プレイヤ２００の視聴者に提供することを可能にするデータであることに留意されたい。メディア・プレイヤ２００は、メディア・コンテンツを再生する（たとえば、映像を表示し、音声を再生する）ソフトウェアの１つであってもよく、スタンドアロンのソフトウェア・アプリケーション、またはウェブ・ブラウザ・プラグイン等であってもよく、あるいはブラウザ・プラグインと支援ウェブ・ページ・ロジック（supporting web page logic）との組合せ等であってもよい。たとえば、イベントは、スポーツ・イベント等のテレビ放送、生演奏または録画もしくは録音された演奏、生の報道または録画もしくは録音された報道等であってもよい。このコンテキストでのライブ・イベントまたは予定されたテレビ・イベントとは、スケジュールに従って特定の時点で再生されるように予定されたメディア・コンテンツを指す。ライブ・イベントは、その中の重要なイベントのスローモーション・クリップ等（例、リプレイ）の、ライブ・メディア・コンテンツと混合されたプレレコ型のコンテンツを有することもあるが、こうしたコンテンツは、生のテレビ放送の合間に再生される。本明細書に記載の実施形態は、ビデオ・オン・デマンド（ＶＯＤ）のストリーミングに使用することもできることに留意されたい。
【００５３】
図３Ａは、エンコーダ２２０をそれぞれが用いた複数のホスト３１４を含めた符号化システム３２０を用いることのできるコンピューティング環境３００の他の実施形態を示す概略ブロック図である。一実施形態では、符号化システム３２０が、マスタ・モジュール３２２および複数のホスト・コンピューティング・モジュール（以降、「ホスト」）３１４を含む。図２に関連して説明したように、ホスト３１４はそれぞれエンコーダ２２０を用いる。ホスト３１４は、１つまたは複数のパーソナル・コンピュータ、サーバ等に実装することができる。更なる実施形態では、ホスト３１４は、たとえば、単一のコンピュータに差し込むカード等の専用のハードウェアであることがある。
【００５４】
一実施形態では、マスタ・モジュール（以降、「マスタ」）３２２は、ストリームレット生成システム３０１から生のストリームレット３１２を受け取るように構成されるが、このストリームレット生成システム３０１は、メディア・コンテンツを発行者３１０から受け取る受取モジュール３０２と、メディア・コンテンツを生のストリームレット３１２にセグメント化するストリームレット・モジュール３０３とを含む。マスタ・モジュール３２２は、生ストリームレット３１２を処理のためにステージする。他の実施形態では、マスタ３２２は、符号化および／または圧縮されたソース（source）・ストリームレットを受け取り、各ソース・ストリームレットを展開して生ストリームレットを作り出すことができる。本明細書で使用するように、用語「生ストリームレット」は、圧縮されていないストリームレット３１２、または、著しくクオリティーを失うことなくサイズを実質的に縮減させるために軽く圧縮されたストリームレット３１２のことを指す。軽く圧縮した生ストリームレットは、より急速により多くのホストへ送信することが可能である。各ホスト３１４は、マスタ３２２に結合されており、マスタ３２２から符号化すべき生ストリームレットを受け取るように構成される。一例では、ホスト３１４は、同一の時間インデックスおよび同一の固定時間幅ならびに様々なビット・レートを有する複数のストリームレットを生成する。一実施形態では、各ホスト３１４は、マスタ３２２から送られる生ストリームレット３１２から符号化済ストリームレットの組３０６を生成するように構成され、ただし、組３０６の符号化済ストリームレットは、メディア・コンテンツの同一部分を、サポートされたビット・レート毎に表す（すなわち、各ストリームレットが、使用可能なクオリティー・プロファイルのうちの１つに従って符号化される）。あるいは、符号化に要する時間を減らすために、各ホスト３１４を、サポートされたビット・レートのうちの１つで単一の符号化済ストリームレットを作り出すように確保することもできる。
【００５５】
符号化が完了すると、ホスト３１４は、組３０６をマスタ３２２に戻し、これにより、符号化システム３２０は、組３０６をストリームレット・データベース３０８に格納することができる。マスタ３２２は更に、符号化ジョブをホスト３１４に割り当てるように構成される。一実施形態では、各ホスト３１４は、符号化ジョブ完了ビッド（bid）（以降、「ビッド」）をマスタ３２２に提示するように構成される。マスタ３２２は、ホスト３１４からのビッドに応じて符号化ジョブを割り当てる。各ホスト３１４は、複数のコンピューティング変数に応じてビッドを生成するが、これらコンピューティング変数には、現在の符号化ジョブ完了パーセンテージ、平均ジョブ完了時間、プロセッサ速度、物理的メモリ容量等が含まれることがあるが、これらに限定されない。
【００５６】
たとえば、ホスト３１４は、過去のパフォーマンス履歴に基づいて、ホスト３１４が符号化ジョブを１５秒で完了させることができるであろうことを示すビッドを提示することができる。マスタ３２２は、複数のビッドから最善のビッドを選択し、これに続いて、最善のビッドを伴うホスト３１４に符号化ジョブを提示するように構成される。したがって、説明している符号化システム３２０は、各ホスト３１４が同一のハードウェアを有することが必要でなく、有益なことに、ホスト３１４の使用可能な計算能力を活用する。あるいは、マスタ３２２は、早いものから順にホスト３１４を選択するか、または、特定の符号化ジョブに適したものと考えられる他のアルゴリズムに基づいてホスト３１４を選択する。
【００５７】
１つのストリームレットを符号化するのに要する時間は、ホスト３１４の計算能力、および、オリジナルのメディア・コンテンツのコンテンツ・ファイルの符号化要件に依存する。符号化要件の例には、２パスまたは複数パス符号化、様々なビット・レートの複数のストリームが含まれことがあるが、これらに限定されない。本発明の利点の１つは、ライブ・コンテンツ・ファイルに２パス符号化を行うことができることである。通常は、２パス符号化を行うためには、従来技術のシステムは、符号化の前にコンテンツ・ファイルが完全になるのを待たなければならない。しかし、ストリームレットは、必要と思われる回数だけ符号化することができる。ストリームレットは、期間の小さな（例、２秒間）密封されたメディア対象なので、初めのストリームレットがキャプチャされると、ライブ・イベントに対して複数パス符号化を開始することができる。
【００５８】
一実施形態では、エンコーダ２２０は、オリジナルのコンテンツ・ファイルを複数のソース・ストリームレットにセグメント化し、たとえば、テレビ番組が終了するのを待つことなく、複数のコピー（例、ストリーム）の２パス符号化を対応する生ストリームレット３１２毎に行う。よって、ストリームレット生成システム３０１がオリジナルのコンテンツ・ファイルのキャプチャを開始するすぐ後に、ウェブ・サーバ３１６は、インターネットを介してストリームレットをストリーミングすることが可能である。発行者３１０から送信されるライブ・ブロードキャストとコンテンツが使用可能になることとの間の遅延は、ホスト３１４の計算能力に依存する。
【００５９】
図３Ｂは、一実施形態によるストリームレット３１２の並行符号化の一実施形態を示す概略ブロック図である。一例では、ストリームレット生成システム３０１が、オリジナルのコンテンツ・ファイルのキャプチャを開始し、第１のストリームレット３１２ａを生成し、これを符号化システム３２０に渡す。符号化システム３２０は、複数のストリームレット３０４ａ（３０４ａ１、３０４ａ２、３０４ａ３等は、互いに異なるビット・レートのストリームレット３０４を表す）からなる第１の組３０６ａを生成するのに、たとえば１０秒間かかることがある。符号化システム３２０に関連して上で説明したように、生のストリームレット３１２または軽く符号化したストリームレット３１２を処理するのに要する時間幅を視覚的に示すために、図３Ｂでは、符号化プロセスを概括的にブロック３０８として示している。符号化システム３２０は、２つ以上のストリームレット３１２を同時に処理することができ、ストリームレット生成モジュール３０１からストリームレットが到着すると、ストリームレットの処理が開始されることとなる。
【００６０】
第１のストリームレット３１２ａを符号化するのに必要な１０秒の間に、ストリームレット・モジュール４０４は、符号化すべき更なる５つの２秒間ストリームレット、ストリームレット３１２ｂ、３１２ｃ、３１２ｄ、３１２ｅ、３１２ｆを生成し、マスタ３２２は、対応する生ストリームレットを作成し、これをステージする。第１の組３０６ａが使用可能になると、その２秒後に次の組３０６ｂが使用可能になり、以降この流れが繰り返される。こうして、オリジナルのコンテンツ・ファイルは、様々なクオリティー・レベルで符号化されてインターネットを介してストリーミングされ、ライブで現れる。本明細書で１０秒間の遅延が与えられているのは、例としてのみのことである。符号化システム３２０の処理能力を増大させるために、複数のホスト３１４を符号化システム３２０に加えることができる。高ＣＰＵ性能システムを加えることにより、あるいは、複数の低性能システムを加えることにより、遅延をほぼ感知できないレベルにまで短くすることができる。
【００６１】
ストリームレットに適用されるどんな特定の符号化スキームも完全になるのに、ストリームレット自体の時間幅より長く時間がかかる可能性がある。たとえば、２秒間のストリームレットに対して、クオリティーの極めて高い符号化を終えるのに５秒間かかることがある。あるいは、各ストリームレットについて要する処理時間が、ストリームレットの時間幅よりも小さいこともある。しかし、連続したストリームレットのオフセット並行符号化は、符号化システム３２０により規則正しい間隔で符号化が行われる（これらのストリームレットが符号化システム３２０に提示される間隔にマッチする。例えば、２秒）ので、符号化システム３２０の出力タイミングが、非符号化ストリームレット３１２のリアルタイムでの提示速度より遅れることはない。
【００６２】
ここで図３Ａを参照すると、マスタ３２２およびホスト３１４は、図示のように、単一のローカル・エリア・ネットワーク内に位置することができ、言い換えると、ホスト３１４を、マスタ３２２に物理的に近接させることができる。あるいは、ホスト３１４は、インターネットまたは他の通信ネットワークを介して、マスタ３２２から符号化ジョブを受け取ることもできる。たとえば、複数のホストをセットアップするのが困難な遠隔地でのライブでのスポーツ・イベントを考えられたい。この例では、マスタは、ストリームレットのオンラインでの発行前に符号化も軽い符号化も行わない。それゆえに、ホスト３１４は、それらのストリームレットを取り出し、上で説明したように、これらを複数のビット・レート組３０６に符号化する。
【００６３】
さらに、符号化ジョブを再始動することおよび／またはストリームレットの発行を中断することなく、ホスト３１４を、符号化システム３２０に動的に追加するまたは符号化システム３２０から動的に取り除くことができる。あるホスト３１４がクラッシュまたは何らかの故障を起こした場合、その符号化ワークは、シンプルに他のホストに再度割り当てられる。
【００６４】
一実施形態では、符号化システム３２０を、特定の再生プラットフォームに特有のストリームレットを作り出すように構成することもできる。たとえば、単一の生ストリームレットについて、単一のホスト３１４が、パーソナル・コンピュータ再生のための様々なクオリティー・レベル向けのストリームレット、独自の異なるコーデックを有する複数の携帯電話での再生向けのストリームレット、（プログラミング・ガイドのような）ストリームのサムネイル表示のみでの再生時の使用向けの映像専用の小ストリームレット、及びアーカイビングでの使用向けの非常に高クオリティーなストリームレットを作り出すことができる。
【００６５】
図示の実施形態では、コンピューティング環境３４０は、コンテンツ管理システム（ＣＭＳ）３００を含む。ＣＭＳ３４０は、たとえばストリームレット・データベース３０８を使用することにより、符号化済メディア・コンテンツ２２０を管理し、発行者がタイムライン（本明細書では仮想タイムライン（ＱＶＴ）と称する）を生成、改変して、メディア・コンテンツ２３２の再生を計画することを可能にする発行システムである。ＱＶＴは、視聴者向けの再生リストを規定し、いつメディア・プレイヤ２００がメディア・コンテンツを再生すべきかを示すことのできるメタデータである。たとえば、タイムラインは、メディア・コンテンツ２３２の開始時刻と、メディア・コンテンツ２３２の現在の期間（例、メディア・コンテンツのうち配信に使用することのできる部分の量）とを指定して、スケジュールに従ってメディア・イベントを再生することを可能にすることができる。上の例では、エンコーダ２２０が、ストリーム（例、メディア・コンテンツ２３２のコピー）についての情報でＣＭＳ２４０をアップデートして、ストリームのうちの特定の部分（例、ストリームレット）がＣＤＮ２４０に関連するオリジン・コンテンツ・サーバ２１０に送られたことを示す。この実施形態では、ＣＭＳ３４０は、エンコーダ２２０から、たとえば以下の中のいずれかの情報を受け取る。それは、暗号化キー／エンコーダ２２０の組が符号化済メディア・コンテンツ２３２の一部分をオリジン・コンテンツ・サーバ２１０に送ったということを示すアベイラビリティ情報／メディア・コンテンツ２３２の特定部分に対してどのクオリティー・レベルが利用可能であるかを示す情報／たとえば、コンテンツの放送日、タイトル、女優、男優、開始インデックス、終了インデックス、権利所有発行者データ、暗号化レベル、コンテンツ所要時間、エピソードまたはプログラム名、発行者を含むメタデータ／使用可能なメニュー、サムネイル、サイドバー、広告、早送り、巻戻し、一時停止、再生等のエンド・ユーザのナビゲーション環境に使用可能なツール／フレーム・サイズ、音声チャネル情報、コーデック、サンプル・レート、フレーム・パーサ情報を含めたビット・レート値である。あるいは、エンコーダ２２０は、上で述べた情報より多くの情報を送ることも、これより少ない情報を送ることもある。
【００６６】
図示の実施形態では、コンピューティング環境３００は、デジタル権利管理能力をシステムに提供するデジタル権利管理サーバ（ＤＲＭ）３５０を含む。ＤＲＭ３５０は、エンド・ユーザの認証によりこのエンド・ユーザに暗号化キーを供給するように更に構成される。一実施形態では、ＤＲＭサーバ３５０は、ログイン証明に基づいてユーザを認証するように構成される。当業者には、ＤＲＡＭサーバ３５０がエンド・ユーザを認証することのできる異なる様々な方法が理解されるであろうが、こうした方法には、暗号化されたクッキー、ユーザ・プロファイル、地理的位置、ソース・ウェブサイト等が含まれるが、これらに限定されない。
【００６７】
他の実施形態では、コンピューティング環境３００が、ディレクトリ・サーバ、管理サーバ、メッセージング・サーバ、統計サーバ、ネットワーク・インフラ・オペレータ（例、ＩＳＰ）のデバイス等の他のデバイスを含むことがある。
【００６８】
図４は、コーデック適用フレーム・サイズに従ってメディア・コンテンツの音声を符号化して、このメディア・コンテンツの固定時間映像部分を有するコンテンツ・ファイル間で隙間のない音声フレームをスプリットする方法４００の一実施形態の流れ図である。方法４００は、ハードウェア（回路、専用論理回路等）、（汎用コンピュータ・システムまたは専用マシン上で実行されるような）ソフトウェア、または、ファームウェア（例、組込みソフトウェア）を含むことのある、あるいは、これらの要素の任意の組合せを含むことのある処理ロジック（processing logic）により実行される。一実施形態では、方法４００は、図２および３Ａのエンコーダ２２０により実行される。他の実施形態では、これら方法のオペレーションのいくつかが、図２の固定フレーム音声エンコーダ２２４および音声スプリッティング・マルチプレクサ２２８により実行されることもある。
【００６９】
図４では、処理ロジックが、サンプル・オフセットを０に初期化することにより開始され（ブロック４０２）、メディア・コンテンツの音声の生部分を受け取る（ブロック４０４）。処理ロジックは、固定フレーム音声コーデックを使用することにより、音声の生部分を符号化し（ブロック４０６）、音声コーデックにより出力される符号化済音声フレームをバッファリングする（ブロック４０８）。処理ロジックは、ストリームレットを満たすのに十分な音声フレームが存在するかどうかを判定する（ブロック４１０）。この実施形態では、本明細書で説明するように、各ストリームレットが、期間の固定された映像フレームも含む。ストリームレットを満たすのに十分な音声フレームが存在しない場合、処理ロジックは、ブロック４０４に戻り、音声の次の生部分を受け取り、この音声の生部分を符号化し、ブロック４０８においてこれらをバッファリングする。処理ロジックは、ブロック４１０において、ストリームレットを満たすのに十分な音声フレームがあると判断した場合、音声フレームを音声スプリッティング・マルチプレクサに送り、バッファから送信フレームを除去する（ブロック４１２）。処理ロジックは、サンプル・オフセットをアップデートし（ブロック４１４）、メディア・コンテンツが終了かどうかを判定する（ブロック４１６）。ブロック４１６においてメディア・コンテンツが終了でなければ、処理ロジックは、ブロック４０４に戻って、音声の他の生部分を受け取る。そうでなければ、本方法は終了する。
【００７０】
図２について上で説明したように、処理ロジックは、エンコーダ２２０のコンポーネントの様々なオペレーションを実行するように構成することができる。たとえば、方法４００は、固定フレーム音声エンコーダ２２４により実行されることもあるが、固定フレーム音声エンコーダ２２４は、スプリッタ２２２から生音声２３３を受け取り、音声フレームを符号化し、符号化済音声フレーム２３７を音声フレーム・バッファ２２５内に格納する。この実施形態では、ブロック４０２〜４０８のオペレーションは、固定フレーム音声エンコーダ２２４が実行することができ、ブロック４１０〜４１６のオペレーションは、音声スプリッティング・マルチプレクサ２２８が実行することができる。あるいは、こうしたオペレーションは、エンコーダ２２０のコンポーネントの他の組合せにより実行することもできる。
【００７１】
図５Ａ〜５Ｃは、固定時間映像部分とコーデック適用フレーム・サイズを有する隙間のない音声フレームとを伴うコンテンツ・ファイルの生成の一実施形態の流れ図である。方法５００、５５０、５７０は、ハードウェア（回路、専用論理回路等）、（汎用コンピュータ・システムまたは専用マシン上で実行されるような）ソフトウェア、または、ファームウェア（例、組込みソフトウェア）を含むことのある、あるいは、これらの要素の任意の組合せを含むことのある処理ロジックにより実行される。一実施形態では、方法５００、５５０、５７０は、図２および３Ａのエンコーダ２２０により実行される。他の実施形態では、方法５００が、固定フレーム音声エンコーダ２２４に実行され、方法５５０が、固定時間映像エンコーダ２２６に実行され、方法５７０が、音声スプリッティング・マルチプレクサ２２８に実行される。あるいは、方法５００、５５０、５７０のオペレーションは、エンコーダ２２０のコンポーネントの他の組合せにより実行することもできる。
【００７２】
図５Ａでは、方法５００の処理ロジックが、音声の生部分を受け取ることにより開始される（ブロック５０２）。処理ロジックは、コーデック適用フレーム・サイズに従って、音声の生部分を符号化し（ブロック５０４）、符号化済音声フレームをバッファリングする（ブロック５０６）。処理ロジックは、メディア・コンテンツが終了かどうかを判定する（ブロック５０８）。ブロック５０８においてメディア・コンテンツが終了でなければ、処理ロジックは、ブロック５０２に戻って、音声の他の生部分を受け取る。そうでなければ、本方法は終了する。
【００７３】
図５Ｂでは、方法５５０の処理ロジックが、映像の生部分を受け取ることにより開始される（ブロック５５２）。処理ロジックは、フレーム・レートに従って、映像の生部分を符号化し（ブロック５５４）、符号化済映像フレームをバッファリングする（ブロック５５６）。処理ロジックは、メディア・コンテンツが終了かどうかを判定する（ブロック５５８）。ブロック５５８においてメディア・コンテンツが終了でなければ、処理ロジックは、ブロック５５２に戻って、映像の他の生部分を受け取る。そうでなければ、本方法は終了する。
【００７４】
図５Ｃでは、方法５７０の処理ロジックが、符号化済音声フレームをバッファから受け取り（ブロック５７２）、映像フレームをバッファから受け取ることにより開始される（ブロック５７４）。処理ロジックは、ストリームレットを生成し（ブロック５７６）、それをオリジン・コンテンツ・サーバに送る（ブロック５７８）。処理ロジックは、メディア・コンテンツが終了かどうかを判定する（ブロック５８０）。ブロック５８０においてメディア・コンテンツが終了でなければ、処理ロジックは、ブロック５７２に戻る。そうでなければ、本方法は終了する。
【００７５】
一実施形態では、処理ロジックは、ブロック５７６で、ストリームレットを満たすのに必要な映像フレームの数、および、ストリームレットを満たすのに必要な音声フレームの数を求める。一実施形態では、ストリームレット毎の映像フレームの数は、固定時間幅に従っておおよそ固定される。たとえば、フレーム・レートが３０ｆｐｓの場合、２秒間のストリームレットに６０フレームが存在する。ただし、実際には、映像は常に正確に３０ｆｐｓというわけではなく、むしろ２９．９７ｆｐｓであることに留意されたい。よって、いくつかの２秒間ストリームレットは５９フレームを有することがあり、いくつかは６０フレーム有することがあり、いくつかは６１フレームの場合でさえある。ストリームレット内の各フレームは、ストリームレットの開始に対する提供時間を有する。よって、あるストリームレットが３０〜３２秒を表す場合、そのストリームレット内の初めのフレームは、０ｍｓではなく６ｍｓの提供時間を有することがある。このフレームは、ストリームの開始から３０００６ｍｓで表示されるはずである。ライブの場合、計算リソースが限られ、エンコーダがライブの流れについていけない場合、エンコーダは、キャッチアップするためにフレームを落とすことがある。したがって、いくつかのストリームレットは映像内に隙間を有することがあり、これが、ストリームレット毎のフレーム数のばらつきのもう１つの原因となる場合がある。あるいは、２４ｆｐｓ等、３０ｆｐｓ以外の他のフレーム・レートを使用することもできる。ストリームレット毎の音声フレームの数は固定されない。音声フレームの数は、音声スプリッティング・マルチプレクサ２２８について先に説明したオペレーションで求まる。処理ロジックは、現在のストリームレットを満たすのに十分な隙間のないフレームがバッファ内に格納されているかどうかを判定する。音声フレームが十分にない場合、処理ロジックは、音声の次の部分、たとえば、本明細書で説明するように、音声の隙間のないフレーム１つを次の部分から受け取り、符号化する。いくつかのケースでは、ストリームレット内の音声フレームの期間が、固定時間幅よりも大きいことがあり、他のケースでは、音声フレームの期間が、固定時間幅よりも小さいことがある。
【００７６】
図７は、一実施形態による音声スプリッティング用のコンピュータ・システム７００の例示的形態のマシンの図である。コンピュータ・システム７００内で、本明細書で議論する音声スプリッティング方法論のうちの１つまたは複数のいずれかをマシンに行わせる命令の組を実行することができる。代替実施形態では、ＬＡＮ、イントラネット、エクストラネット、またはインターネット内でマシンを他のマシンに接続（例、ネットワーク化）することができる。このマシンは、クライアント-サーバ・ネットワーク環境内でサーバまたはクライアント・マシンの能力内で動作することも、ピア・ツー・ピア（分散型）・ネットワーク環境内でピア・マシンとして動作することもできる。このマシンは、ＰＣ、タブレットＰＣ、ＳＴＢ、ＰＤＡ、携帯電話、ウェブ・アプライアンス、サーバ、ネットワーク・ルータ、スイッチまたはブリッジ、あるいは、マシンがとるべきアクションを指定する（連続した、またはそれ以外の）命令の組を実行することの可能な任意のマシンとすることができる。さらに、単一のマシンのみ図示しているが、音声スプリッティングのオペレーションについて本明細書に記載する上記の方法４００、５００、５５０、５７０等の本明細書で議論する方法論のうちの１つまたは複数のいずれかを行うために、個別にまたは共同して１組の（または複数組の）命令を実行する複数のマシンの任意の集合も、用語「マシン」に含まれるものとする。一実施形態では、コンピュータ・システム７００は、上で説明したようにエンコーダ２２０または符号化システム３２０に実装することのできる様々なコンポーネントを表す。あるいは、エンコーダ２２０または符号化システム３２０が、コンピュータ・システム７００内に図示しているものより多くのコンポーネント、またはこれより少ないコンポーネントを含むこともある。
【００７７】
この例示的コンピュータ・システム７００は、処理デバイス７０２、メイン・メモリ７０４（例、ＲＯＭ（リードオンリ・メモリ）、フラッシュ・メモリ、ＳＤＲＡＭ（シンクロナスＤＲＡＭ）やＤＲＡＭ（ＲＤＲＡＭ）等のＤＲＡＭ（ダイナミック・ランダム・アクセス・メモリ）等）、スタティック・メモリ７０６（例、フラッシュ・メモリ、ＳＲＡＭ（スタティック・ランダム・アクセス・メモリ）等）、データ記憶デバイス７１６を含み、これら要素は、それぞれバス７３０を介して互いに通信を行っている。
【００７８】
処理デバイス７０２は、マイクロプロセッサや中央処理ユニット等の１つまたは複数の汎用処理デバイスを表す。より具体的には、処理デバイス７０２は、ＣＩＳＣ（複合命令セット・コンピューティング）マイクロプロセッサ、ＲＩＳＣ（縮小命令セット・コンピューティング）マイクロプロセッサ、ＶＬＩＷ（超長命令語）マイクロプロセッサ、または、他の命令の組を実装するプロセッサもしくは命令の組の組合せを実装するプロセッサでもよい。処理デバイス７０２は、ＡＳＩＣ（特定用途向け集積回路）、ＦＰＧＡ（フィールド・プログラマブル・ゲート・アレイ）、ＤＳＰ（デジタル信号プロセッサ）、ネットワーク・プロセッサ等の１つまたは複数の特別用途処理デバイスであってもよい。処理デバイス７０２は、本明細書で議論するオペレーションおよびステップを実施するための処理ロジック（例、音声スプリッティング７２６）を実行するように構成される。
【００７９】
コンピュータ・システム７００は、ネットワーク・インタフェース・デバイス７２２を更に含むこともある。コンピュータ・システム７００は、映像表示ユニット７１０（例、液晶ディスプレイ（ＬＣＤ）または陰極線管（ＣＲＴ））、アルファニューメリック入力デバイス７１２（例、キーボード）、カーソル制御デバイス７１４（例、マウス）、信号生成デバイス７２０（例、スピーカ）を含むこともある。
【００８０】
データ記憶デバイス７１６は、本明細書に記載する方法論または機能のうちの１つまたは複数を実現する１組または複数の組の命令（例、音声スプリッティング７２６）が記憶されるコンピュータ可読記憶媒体７２４を含むことがある。音声スプリッティング７２６は、コンピュータ・システム７００による実行中、メイン・メモリ７０４および／または処理デバイス７０２内に完全にまたは少なくとも部分的に含まれるように存在することがあるが、これらメイン・メモリ７０４および処理デバイス７０２もまた、コンピュータ可読記憶媒体を構成する。さらに、ネットワーク・インタフェース・デバイス７２２により、音声スプリッティング７２６を、ネットワークを介して送ることまたは受け取ることができる。
【００８１】
一例示的実施形態では、コンピュータ可読記憶媒体７２４を単一の媒体として図示しているが、用語「コンピュータ可読媒体」には、１組または複数組の命令を記憶する単一または複数の媒体（例、集中もしくは分散データベース、ならびに／または関連キャッシュおよびサーバ）も含まれることがあるとみなされたい。また、用語「コンピュータ可読記憶媒体」には、マシンによる実行用の命令の組を記憶することが可能で、本実施形態の方法論のうちの１つまたは複数をマシンに実行させる任意の媒体も含まれるものとする。したがって、用語「コンピュータ可読記憶媒体」には、ソリッド・ステート・メモリ、光学式媒体、磁気媒体、または、命令を記憶するための他の種類の媒体が含まれることとするが、これらに限定されない。用語「コンピュータ可読伝送媒体」には、マシンによる実行用の命令の組を送信して、本実施形態の方法論のうちの１つまたは複数をマシンに行わせることの可能な任意の媒体が含まれるものとする。
【００８２】
音声スプリッティング・モジュール７３２、それぞれのコンポーネント、および（たとえば、図２および３Ａに関連して）本明細書に記載する他の特徴を、分離したハードウェア・コンポーネントとして実現すること、または、ＡＳＩＣＳ、ＦＰＧＡ、ＤＳＰ、これらと同様のデバイス等のハードウェア・コンポーネントの機能内に集積化することができる。さらに、音声スプリッティング・モジュール７３２は、ハードウェア・デバイス内のファームウェアまたは機能回路として実現することもできる。さらに、音声スプリッティング・モジュール７３２は、任意の組合せハードウェア・デバイスおよびソフトウェア・コンポーネント内で実現することもできる。
【００８３】
説明目的で、上記の記載を特定の実施形態に関連して提供してきた。しかし、上記の例示的議論は、網羅的になることを意図しておらず、開示した厳密な形態に本発明を限定することを意図していない。上記の教示内容に鑑みて、多くの修正形態および変形形態が考えられる。本発明の原理およびその実用的応用例を最もうまく説明するために、上記の実施形態を選択し説明したが、これにより、当業者が本発明と様々な修正形態を伴う様々な実施形態とを、企図される特定の用途に適した形で利用することが可能になる。
【技術分野】
【０００１】
本発明の実施形態は、インターネットを介したメディア・コンテンツの配信の分野に関し、より具体的には、境界アーチファクトを導入せずに、メディア・コンテンツの音声を、分離した複数のコンテンツ・ファイルにスプリットすることに関する。
【背景技術】
【０００２】
インターネットは、メディア・コンテンツ（例、映像および音声または音声）ならびに他の情報をエンド・ユーザに分配する主要な方法になっている。現在、音楽、映像、ゲーム、他のメディア情報を、コンピュータ、携帯電話、また、実質的にいかなるネットワーク可能デバイスにもダウンロードすることが可能である。人々がメディア・コンテンツを求めてインターネットにアクセスする割合は、急速に伸びている。視聴者体験のクオリティーが、オンラインでの映像視聴の成長のキーとなる障壁である。需要者のテレビ視聴体験および映画視聴体験が、オンライン映像に対する需要者期待をもたらす。
【０００３】
ウェブ上で映像をストリーミングする視聴者数は急速に増えており、映像をインターネットで視聴することへの興味および需要は増している。データ・ファイルのストリーミングまたは「メディアのストリーミング」とは、大きな中断なしに本来期待される再生速度でメディアをユーザに提供するのに十分なレートで、連続したメディア・コンテンツを配信する技術を指す。メディア・ファイルのダウンロードされたデータとは違い、ストリーム化されたデータは、それを再生するまでメモリに格納し、次いで、指定時間が経過した後削除することができる。
【０００４】
電波、衛星、またはケーブルを介した通常のブロードキャストと比較すると、インターネットを介したメディア・コンテンツのストリーミングには、いくつかの課題がある。メディア・コンテンツの音声の符号化の場面で生じる懸念の１つは、映像および音声を複数の固定時間（fixed-time）部分にセグメント化する際の境界アーチファクトの導入である。従来手法の１つでは、音声が、たとえば２秒間といった対応する映像の固定時間幅に合う固定時間幅を有する複数の部分にセグメント化される。この手法では、音声境界が、常に映像境界に整合する。この従来手法では、たとえばＡＡＣ ＬＣ（Ｌｏｗ Ｃｏｍｐｌｅｘｉｔｙ Ａｄｖａｎｃｅｄ Ａｕｄｉｏ Ｃｏｄｉｎｇ）を使用することにより、コンテンツ・ファイルごとに各音声部分を符号化するために音声コーデックの新たな符号化セッションが開始される。音声の各部分ごとに新たな符号化セッションを使用することにより、音声コーデックが、波形の開始および終了を０からの遷移として解釈し、これにより、図１に示すような部分境界での符号化部分の再生中のポップ雑音（pop noise）またはクリック雑音（click noise）が引き起こされる。こうしたポップ雑音またはクリック雑音を、境界アーチファクトと称する。また、音声コーデックが、コーデック適用（codec-enforced）フレーム・サイズに従って固定時間幅の音声を符号化する。これによっても、音声コーデックの作り出すサンプル数がコーデック適用フレーム・サイズで等しく割り切れない場合、境界アーチファクトが導入される。
【０００５】
図１は、ある従来手法を使用した音声の２部分についての例示的音声波形１００を示す図である。音声波形１００は、映像の第１、第２の部分間の０からの遷移１０２を示す。音声コーデックが固定フレーム・サイズ（以降本明細書では、コーデック適用フレーム・サイズと称する）を有する場合、音声コーデックでは、コーデック適用フレーム・サイズに従ったフレーム毎のサンプル数でその部分のサンプル数が等しく割り切れないと、最終フレーム１０４を０で埋める必要がある。たとえば、サンプリング・レート４８ｋＨｚを使用する場合、２秒間の音声セグメントに対して９６０００個のサンプルが生成される。このサンプル数９６０００をフレーム毎のサンプル数（たとえば、ＡＡＣ ＬＣの場合のサンプル数は１０２４、ＨＥ ＡＡＣ（Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ ＡＡＣ）の場合のサンプル数は２０４８）で割ると、フレーム数は９３．７５となる。９３．７５は整数でないので、音声コーデックは、最終フレーム１０４を０で埋める。この例では、最終フレームの最後の２５６個のサンプルに、値０が付与される。値０はサイレント音声を表すが、最終フレームを０で埋めているので、音声の符号化部分の再生中に部分境界でポップ音声またはクリック音声が確認される。０からの遷移１０２および最終フレーム１０４に埋め込まれた０により、境界アーチファクトが導入される。境界アーチファクトが導入されると、音声の全体的な質が低減されることがあり、このことは、メディア・コンテンツの再生中のユーザ体験に影響を及ぼす。
【０００６】
他の従来手法では、フレーム境界との整合をとるために、音声の中からより期間の長い部分を使用することにより、境界アーチファクトの数を制限しようとする。しかし、使用される音声の期間部分がより大きくなると、音声および映像を別々にまとめる必要がある場合がある。このことは、音声および映像を有するメディア・コンテンツのストリーミングに障害をもたらすことがあり、こうした障害は、たとえば、メディア・コンテンツの再生中に様々なクオリティー・レベルへのシフトを可能にするアダプティブ・ストリーミングの場面のように、同一のメディア・コンテンツが様々なクオリティー・レベルで符号化されるときに特にもたらされる。
【図面の簡単な説明】
【０００７】
本発明は、以下の説明、および、本発明の実施形態を図示するのに使用する添付の図面を参照することにより最適に理解することができる。
【図１】ある従来手法を使用した音声の２部分についての例示的音声波形を示す図である。
【図２】本実施形態のエンコーダを用いることのできるコンピューティング環境の一実施形態を示す概略ブロック図である。
【図３Ａ】図２のエンコーダをそれぞれが用いた複数のホストを含めた符号化システムを用いることのできるコンピューティング環境の他の実施形態を示す概略ブロック図である。
【図３Ｂ】一実施形態によるストリームレット（streamlet）の並行符号化の一実施形態を示す概略ブロック図である。
【図４】コーデック適用フレーム・サイズに従ってメディア・コンテンツの音声を符号化して、このメディア・コンテンツの固定時間映像部分を有するコンテンツ・ファイル間で隙間のない音声フレームをスプリットする方法の一実施形態の流れ図である。
【図５Ａ】固定時間映像部分とコーデック適用フレーム・サイズを有する隙間のない音声フレームとを伴うコンテンツ・ファイルの生成の一実施形態の流れ図である。
【図５Ｂ】固定時間映像部分とコーデック適用フレーム・サイズを有する隙間のない音声フレームとを伴うコンテンツ・ファイルの生成の一実施形態の流れ図である。
【図５Ｃ】固定時間映像部分とコーデック適用フレーム・サイズを有する隙間のない音声フレームとを伴うコンテンツ・ファイルの生成の一実施形態の流れ図である。
【図６Ａ】音声スプリッティングの一実施形態による音声部分、映像部分、ストリームレットの図である。
【図６Ｂ】音声スプリッティングを使用した音声の４部分についての音声波形の一実施形態を示す図である。
【図７】一実施形態による音声スプリッティング用のコンピュータ・システムの例示的形態のマシンの図である。
【発明を実施するための形態】
【０００８】
境界アーチファクトを導入せずに、メディア・コンテンツの音声を、分離したコンテンツ・ファイルにスプリットする方法および装置を説明する。一実施形態では、オペレーションを実行するようにプログラムされたコンピューティング・システムにより行われる方法が、音声および映像を含むメディア・コンテンツを受け取ることと、フレーム・レートに従って映像を符号化することと、コーデック適用フレーム・サイズ（すなわち、固定されたフレーム・サイズ）に従って音声を符号化することと、映像のうち固定時間幅を有する符号化済部分と、音声のうち、コーデック適用フレーム・サイズを有する隙間のない音声フレームを有する符号化済部分とをそれぞれが含んだコンテンツ・ファイルを生成することとを含む。一実施形態では、従来行われているようには、音声フレームの最後を０で埋めることはしない。
【０００９】
本発明の実施形態により、音声をストリーミングする改善手法が提供される。メディア・コンテンツの音声の各部分毎に新たな符号化セッションを使用する従来手法と異なり、本明細書に記載する実施形態は、境界アーチファクトを導入することなく、メディア・コンテンツを複数の小部分にセグメント化することを可能にする。本明細書に記載の実施形態では、隙間のない音声フレームを使用することにより、音声がセグメント化される。音声が再生のためにステージ（stage）される際、音声は、境界アーチファクトを有する多数の小セグメントではなく、単一のストリームとしてデコーダに提供される。本明細書に記載の実施形態では、エンコーダが、コーデック・フレーム・サイズ（たとえば、ＡＡＣ-ＬＣの場合のサンプル数は１０２４、または、ＨＥ ＡＡＣの場合のサンプル数は２０４８）、および、コーデックの起動毎にいくつの音声フレームが作られるかを認識する。エンコーダは、符号化されたストリームレット（すなわち、コンテンツ・ファイル）に収めることの可能な数の音声フレームを格納するが、この符号化されたストリームレットは、映像のうち固定時間幅に基づいた部分を有する。最終音声フレームを０で埋めるのではなく、音声の次の部分の隙間のないフレームを符号化し、現在のストリームレットに加える。これにより、普通なら次のストリームレットに書き込まれるはずの少量の音声が、現在のストリームレットに書き込まれる。こうした次のストリームレットには、次いで、音声ストリームが隙間（gap）を示すための時間オフセットが付与され、したがって、音声を再生する際に、連続したストリームとしてデコーダに音声を提供することができる。これと同量の時間が、このストリームレットに対する音声のターゲット期間から差し引かれる。上記次のストリームレットの音声の終わりがフレーム境界に載らない場合、最終フレームを埋めるために、再度次のストリームレットから音声を借りる。このプロセスは、メディア・コンテンツのストリームの最後に達するまで繰り返される。音声が借りられているストリームレットの先頭に挿入された隙間は、このストリームレットの音声部分を復号および再生する前にステージする際に除去することができる。ランダムなストリームレットを得ようとする際には、音声／映像同期を維持するために、隙間の期間にサイレント音声を再生することができる。
【００１０】
本明細書に記載した音声スプリッティングの実施形態により、コーデック適用フレーム・サイズの大きい（例、ＡＡＣ、ＡＣ３等）音声コーデックを使用して、映像に対する同一の固定時間幅を維持しながら、境界アーチファクトを導入することなくメディア・コンテンツの音声を符号化することが可能になる。
【００１１】
以下の説明では、多数の詳細を言及する。ただし、本開示内容から恩恵を受ける当業者には、こうした具体的詳細なしに本発明の実施形態を実践することができることが明らかであろう。いくつかの例では、本発明の実施形態を不明確にすることを避けるために、周知の構造およびデバイスを詳細に図示するのではなく、ブロック図形式で図示している。
【００１２】
以下の詳細な説明のいくつかの部分は、コンピュータ・メモリ内のデータ・ビットへのオペレーションの象徴表現およびアルゴリズムの観点から提供している。こうしたアルゴリズム的な記述および表現は、データ処理技術の当業者が他の当業者に自身の研究の本質を最も効果的に伝えるために使用する手段である。ここでまた一般にアルゴリズムとは、所望の結果をもたらす首尾一貫した一連のステップであると理解される。これらステップは、物理量の物理的操作を必要とするものである。必ずではないが通常、これらの量は、格納すること、転送すること、組み合わせること、比較すること、あるいは操作することの可能な電気信号または磁気信号の形態をとる。一般的な使用法であるということが主な理由であるが、これらの信号を、ビット、値、エレメント、シンボル、キャラクター、ターム（term）、番号等と呼ぶことが都合の良いこともあることが分かっている。
【００１３】
ただし、これらの用語および同様の用語は全て、適当な物理量に関連付けられるべきであり、これらの量に適用される都合の良いラベルにすぎないことを覚えておかれたい。以下の議論から明確であるように具体的に記載がない限り、記載全体を通じて、「受け取ること（receiving）」、「符号化すること（encoding）」、「生成すること（generating）」、「スプリットすること（splitting）」、「処理すること（processing）」、「計算すること（computing）」、「算出すること（calculating）」、「決定すること（determining）」、「表示すること（displaying）」等の用語を利用した議論は、コンピュータ・システムのレジスタおよびメモリ内の物理的（例、電子的）量で表されたデータを操作し、コンピュータ・システム・メモリもしくはレジスタまたは他のこうした情報記憶デバイス、情報送信デバイスもしくは情報表示デバイス内で同様に物理的量を用いて表された他のデータに変換するコンピュータ・システムまたは同様の電子コンピューティング・システムの動作および処理を言及することが理解される。
【００１４】
本発明の実施形態はまた、本明細書内のオペレーションを実行するための装置に関する。この装置は、必要な目的のために具体的に構築することも、自体の中に記憶されたコンピュータ・プログラムに具体的にプログラムされた汎用コンピュータ・システムを備えることもできる。こうしたコンピュータ・プログラムは、フロッピー・ディスク、光学ディスク、ＣＤ-ＲＯＭ、光磁気ディスクを含めた任意の種類のディスクや、ＲＯＭ（リード-オンリ・メモリ）、ＲＡＭ（ランダム・アクセス・メモリ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カードまたは光学カードや、電子的命令を記憶するのに適した任意の種類のメディア等のコンピュータ可読記憶媒体中に記憶することができるが、記憶先はこれらに限定されない。
【００１５】
本明細書で使用する「符号化済ストリームレット」という用語は、メディア・コンテンツの一部分の単一の符号化表現を指す。各ストリームレットは、メディアの一部分を含む個別のコンテンツ・ファイルとすることができ、また、独立したメディア対象として封入することができ、これにより、そのストリームレットを個別にキャッシュに入れること、メディア・プレイヤで独立して要求することおよび独立して再生することが可能になる。本明細書では、これらの個別のファイルをＯＳＳファイルとも称する。一実施形態では、ストリームレットは、特化されたメディア・サーバによってではなく、特化されていないサーバによりサーブ（serve）されることのある静的ファイルである。一実施形態では、ストリームレット内のメディア・コンテンツが、所定の長さの再生時間（固定時間幅とも称する）を有することがある。この所定の長さの時間は、たとえば、約０．１〜８．０秒とすることができる。あるいは、他の所定の長さを使用することもできる。ストリームレット内のメディア・コンテンツは、ストリームに含まれるメディア・コンテンツの先頭に関して一意の時間インデックスを有することがある。ファイル名が、時間インデックスの一部分を含むことがある。あるいは、ストリームレットを、時間インデックスではなくファイルのサイズに従って分割することもできる。本明細書で使用する「ストリーム」という用語は、メディア・コンテンツのうち同一の映像クオリティー・プロファイルで符号化されたストリームレットの集合を指すことがあり、たとえば、映像のうち同一の映像ビット・レートで符号化された部分である。ストリームは、オリジナルのメディア・コンテンツのコピーを表す。ストリームレットは別々のファイルとして、コンテンツ・サーバ、ウェブ・サーバ、キャッシュ・サーバ、プロキシ・キャッシュ、または、コンテンツ・デリバリ・ネットワーク（ＣＤＮ）に見られるようなネットワーク上の他のデバイスのうちの１つまたは複数上に格納することができる。こうした別々のファイル（たとえば、ストリームレット）は、クライアント・デバイスによって、ウェブ・サーバからＨＴＴＰを使用して要求されうる。ＨＴＴＰ等の標準プロトコルを使用することにより、ネットワーク管理者が、ファイアウォールを、ＲＴＳＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）等の特化した新たなプロトコルについてのネットワーク・トラフィックを認識し通過させるように構成する必要がなくなる。さらに、メディア・プレイヤが要求を開始するので、たとえば、ウェブ・サーバは、ストリーム全体ではなく、要求されたストリームレットを取り出し供給することのみ必要とされる。メディア・プレイヤは、２つ以上のウェブ・サーバからストリームレットを取り出すこともできる。これらのウェブ・サーバは、要求された部分を取り出すための、特化したサーバ側知能を伴わないことがある。他の実施形態では、ストリームレットは、ネットワーク・インフラ・オペレータ（例、ＩＳＰ）のキャッシュ・サーバまたはＣＤＮの他のコンポーネント上に別々のファイルとして格納される。本実施形態のうちいくつかはストリームレットの使用について説明するが、本明細書に記載の実施形態は、ストリームレットを使用するコンピューティング・システム内での使用に限定されず、インターネットを介してライブ・メディア・コンテンツを配信する他の技法を使用する他のシステム内で実行することもできる。たとえば、他の実施形態では、ＨＴＴＰ範囲の要求を使用することにより要求でき、ＣＤＮ内でキャッシュに入れることの可能な複数部分に分けられる単一のファイル内にメディア・コンテンツが格納される。
【００１６】
２つの一般的タイプのメディア・ストリーミング、すわわち、プッシュ（push）-ベース・ストリーミングおよびプル（pull）-ベース・ストリーミングが存在する。プッシュ技術は、発行者のコンテンツ・サーバ等のサーバが所与のトランザクションについての要求を開始するインターネット-ベースの通信の方法を説明するものである。対照的に、プル技術は、情報の送信の要求がクライアント・デバイスにより開始され、次いで、サーバにより応答されるインターネット-ベースの通信の方法について説明するものである。ＨＴＴＰ要求（例、ＨＴＴＰ ＧＥＴ要求）は、プル技術における要求の１種類である。対照的に、プッシュ-ベースの技術では、通常、専用のサーバが、ＲＴＳＰ等の専用のプロトコルを使用して、クライアント・デバイスにデータを送り込む。あるいは、いくつかのプッシュ-ベースの技術では、ＨＴＴＰを使用してメディア・コンテンツを配信することがある。プル-ベースの技術では、複数のクライアント・デバイスにメディアを配信するために、ＣＤＮを使用することがある。
【００１７】
本明細書に記載の様々な実施形態はプル-ベースのモデルを対象としたものであるが、プッシュ-ベースの構成等の他の構成内で、これら実施形態を実行することができることに留意されたい。プッシュ-ベースの構成では、エンコーダによる音声スプリッティングの実施形態を、図２に関連して説明するプル-ベースの構成と同様に実行することができ、符号化されたコンテンツ・ファイルをメディア・サーバ等のコンテンツ・サーバ上に格納して、プッシュ-ベースの技術を使用することにより、このメディア・コンテンツを再生用にクライアント・デバイスに配信することができる。これらの実施形態を使用して、メディア・コンテンツの様々なクオリティー・レベルをもたらすことができ、また、これらの実施形態により、一般にアダプティブ・ストリーミングと称される、様々なクオリティー・レベル間での切替えが可能になることにも留意されたい。プッシュ-ベースのモデルでは、メディア・サーバがどのコンテンツ・ファイルをクライアント・デバイスに送るかを決定し、プル-ベースのモデルでは、クライアント・デバイスがどの（１つまたは複数の）コンテンツ・ファイルをコンテンツ・サーバから要求するかを決定することが違いの１つであることがある。
【００１８】
図２は、本実施形態のエンコーダ２２０を用いることのできるコンピューティング環境２００の一実施形態を示す概略ブロック図である。コンピューティング環境２００は、ソース２０５、エンコーダ２２０、コンテンツ配信ネットワーク２４０のオリジン（origin）・コンテンツ・サーバ２１０（メディア・サーバまたはオリジン・サーバとも称する）、それぞれクライアント・デバイス２０４上で動作する複数のメディア・プレイヤ２００を含む。コンテンツ・サーバ２１０と、エンコーダ２２０と、クライアント・デバイス２０４とは、データ通信ネットワークで結合することができる。データ通信ネットワークには、インターネットが含まれることがある。あるいは、コンテンツ・サーバ２１０、エンコーダ２２０、クライアント・デバイス２０４を、共通のＬＡＮ（ローカル・エリア・ネットワーク）、ＰＡＮ（パーソナル・エリア・ネットワーク）、ＣＡＮ（キャンパス・エリア・ネットワーク）、ＭＡＮ（メトロポリタン・エリア・ネットワーク）、ＷＡＮ（ワイド・エリア・ネットワーク）、無線ＬＡＮ、セルラ・ネットワーク、バーチャルＬＡＮ等上に置くこともできる。クライアント・デバイス２０４は、クライアント・ワークステーション、サーバ、コンピュータ、携帯型電子デバイス、もしくは、セット-トップ・ボックス、デジタル・レシーバ、デジタル・テレビ等のネットワークを介して通信を行うように構成されたエンターテイメント・システム、または他の電子デバイスとすることができる。たとえば、携帯型電子デバイスには、携帯電話、携帯型ゲーム・システム、携帯型コンピューティング・デバイス等が含まれることがあるが、これらに限定されない。クライアント・デバイス２０４は、ファイアウォール、ルータ、または他のパケット交換デバイスを介してインターネットにアクセスすることができる。
【００１９】
図示の実施形態では、ソース２０５は、発行者サーバまたは発行者コンテンツ・リポジトリであることがある。ソース２０５は、メディア・コンテンツの作成者または分配者であることもある。たとえば、ストリーム化されるべきメディア・コンテンツがテレビ番組の放送である場合、ソース２０５は、テレビのサーバ、またはＡＢＣ（登録商標）チャンネルやＭＴＶ（登録商標）チャンネル等のケーブル・ネットワーク・チャンネルであることがある。発行者は、インターネットを介してメディア・コンテンツをエンコーダ２２０に転送することができるが、エンコーダ２２０は、メディア・コンテンツを受け取って処理し、このメディア・コンテンツの（１つまたは複数の）コンテンツ・ファイルをオリジン・コンテンツ・サーバ２１０内に格納するように構成することができる。一実施形態では、コンテンツ・サーバ２１０が、メディア・コンテンツをクライアント・デバイス２０４に配信するが、このクライアント・デバイス２０４は、自体上で動作するメディア・プレイヤ上でこのコンテンツを再生するように構成される。コンテンツ・サーバ２１０は、メディア・コンテンツをストリーミングすることにより、これをクライアント・デバイス２０４に配信する。後により詳細に説明するように、更なる実施形態では、クライアント・サーバ２０４が、メディア・コンテンツの様々な部分を、複数の位置から同時にまたは一斉に受け取るように構成される。
【００２０】
コンテンツ・サーバ２１０で格納されたメディア・コンテンツは、他のウェブ・サーバに対して、あるいはＣＤＮ２４０のプロキシ・キャッシュ・サーバに対して複製することができる。複製は、コンテンツ・サーバ２１０から計画的に押し進められることにより、または、コンテンツ・サーバ２１０の外のウェブ・サーバ、キャッシュ・サーバもしくはプロキシ・サーバがクライアント・デバイス２０４のためにコンテンツを求めることにより発生することがある。たとえば、クライアント・デバイス２０４は、複数のウェブ・サーバ、エッジ・キャッシュ、またはプロキシ・キャッシュ・サーバのうちのいずれかからコンテンツを要求し受け取ることができる。図示の実施形態では、ウェブ・サーバ、プロキシ・キャッシュ、エッジ・キャッシュおよびコンテンツ・サーバ２１０をＣＤＮ２４０の階層で編成して、メディア・コンテンツをクライアント・デバイス２０４に配信している。ＣＤＮは、コンテンツを配信するために透過的に協働する、インターネット中でネットワーク化された複数のコンピュータのシステムであり、たとえば、１つまたは複数のオリジン・コンテンツ・サーバ、ウェブ・サーバ、キャッシュ・サーバ、エッジ・サーバ等を含むことがある。通常、ＣＤＮは、たとえば、クライアント・デバイスがエッジ・キャッシュからデータを要求するような階層に構成され、エッジ・キャッシュが要求されたデータを含んでいない場合、その要求は、次には親キャッシュといった具合に、オリジン・コンテンツ・サーバに至るまで送られていく。ＣＤＮは、メディア・コンテンツを配信するために、相互接続されたコンピュータ・ネットワークまたはノードを含むこともある。ＣＤＮのいくつかの例には、Akamai Technologies社、Level3 Communications社、またはLimelight Networks社に開発されたＣＤＮがある。あるいは、他の種類のＣＤＮを使用することもできる。他の実施形態では、オリジン・コンテンツ・サーバ２１０は、本開示内容の恩恵を受ける当業者には理解されるはずの他の構成を使用することにより、メディア・コンテンツをクライアント・デバイス２０４に配信することができる。
【００２１】
一実施形態では、発行者が、ソース２０５から分配するべきオリジナルのコンテンツ・ファイル内にメディア・コンテンツを格納する。コンテンツ・ファイルは、テレビ放送、スポーツ・イベント、映画、音楽、コンサート等に相当する映像および／または音声に相当するデータを含むことがある。オリジナルのコンテンツ・ファイルは、圧縮されていない映像および音声、あるいは圧縮されていない映像または音声を含むことがある。あるいは、コンテンツ・ファイルは、標準的な符号化スキームまたは独自開発の符号化スキームを使用した圧縮済コンテンツ（例、映像および／または音声）を含むことがある。ソース２０５からのオリジナルのコンテンツ・ファイルは、デジタル形式でもよく、たとえば約５Ｍｂｐｓ以上といった高ビット・レートのメディア・コンテンツを含むことができる。
【００２２】
図示の実施形態では、エンコーダ２２０が、たとえば、オリジナルのコンテンツ・ファイル、ライブ・イベント放送の直接供給からの信号、ライブでのテレビ・イベント放送のストリーム等を受け取ることにより、ソース２０５からオリジナルのメディア・コンテンツ２３１を受け取る。エンコーダ２２０は、１つもしくは複数のサーバ・コンピュータ、ゲートウェイまたは他のコンピューティング・デバイスを含む１つまたは複数のマシンに実装することができる。一実施形態では、エンコーダ２２０は、オリジナルのメディア・コンテンツ２３１を、１つまたは複数のコンテンツ・ファイルとして発行システム（図示せず）（例、発行者のサーバまたは発行者のコンテンツ・リポジトリ）から受け取る。あるいは、エンコーダ２２０は、キャプチャ（capture）時のオリジナルのメディア・コンテンツ２３１を受け取る。たとえば、エンコーダ２２０は、被キャプチャ・ブロードキャスト（captured broadcast）等のライブ・テレビ放送の直接供給をストリーム形式または信号形式で受け取ることができる。オリジナルのメディア・コンテンツ２３１は、たとえば、カナダ、オンタリオのDigital Rapids社から入手可能なＤＲＣ-２６００キャプチャ・カード等、テレビ・キャプチャおよび／またはビデオ・キャプチャ向けに構成されたキャプチャ・カードでキャプチャすることができる。あるいは、音声および映像のキャプチャが可能な任意のキャプチャ・カードを本発明では利用することができる。キャプチャ・カードは、エンコーダと同一のサーバ上に置くことも、別のサーバ上に置くこともできる。オリジナルのメディア・コンテンツ２３１は、電波、ケーブル、および／もしくは衛星を介して同時にブロードキャストされる型のブロードキャスト等の被キャプチャ・ブロードキャスト、または、ライブ・イベントのスケジュールに従って特定の時点で再生されるように予定されたプレレコ型（pre-recorded）のブロードキャストであることがある。エンコーダ２２０は、ＤｉｖＸ（登録商標）コーデック、Ｗｉｎｄｏｗｓ Ｍｅｄｉａ Ｖｉｄｅｏ９（登録商標）シリーズ・コーデック、Ｓｏｒｅｎｓｏｎ Ｖｉｄｅｏ（登録商標）３映像コーデック、On2 Technologies（登録商標）社のＴｒｕｅＭｏｔｉｏｎ ＶＰ７コーデック、ＭＰＥＧ-４映像コーデック、Ｈ．２６３映像コーデック、ＲｅａｌＶｉｄｅｏ１０コーデック、ＯＧＧ Ｖｏｒｂｉｓ、ＭＰ３等の符号化スキームを利用することができる。あるいは、カスタマイズした符号化スキームを利用することもできる。
【００２３】
他の実施形態では、エンコーダ２２０は、たとえば２秒間のチャンク等、映像および音声のうちの固定時間幅の部分（本明細書では「メディア・コンテンツの一部分」と称する）としてオリジナルのビデオ・コンテンツ２３１を受け取る。この２秒間のチャンクは、生音声（raw audio）および生映像（raw video）を含むことがある。あるいは、この２秒間のチャンクは、符号化された音声および生映像であることもある。このような場合、エンコーダ２２０は、メディア・コンテンツを展開する。他の実施形態では、エンコーダ２２０は、オリジナルのメディア・コンテンツ２２１を複数の生ストリームレットとして受け取るが、これら生ストリームレットはそれぞれ、メディア・コンテンツの固定時間部分（例、生音声および映像を含んだ複数の２秒間生ストリームレット）を含んでいる。本明細書で使用するように、用語「生ストリームレット」は、圧縮されていないストリームレット、または、著しくクオリティーを失うことなくサイズを実質的に縮減させるために軽く圧縮されたストリームレットのことを指す。軽く圧縮した生ストリームレットは、より急速に送信することが可能である。他の実施形態では、エンコーダ２２０は、オリジナルのメディア・コンテンツ２３１をストリームまたは信号として受け取り、生ストリームレット等、メディア・コンテンツの複数の固定時間部分にセグメント化する。
【００２４】
図示の実施形態では、エンコーダ２２０は、スプリッタ２２２、固定フレーム音声エンコーダ２２４、音声フレーム・バッファ２２５、固定時間映像エンコーダ２２６、映像フレーム・バッファ２２７、音声スプリッティング・マルチプレクサ２２８を有する。スプリッタ２２２は、オリジナルのメディア・コンテンツ２３１を、たとえば音声および映像の連続したストリームとして受け取り、これを生音声２３３および生映像２３５にスプリットする。一実施形態では、固定フレーム音声エンコーダ２２４は音声コーデックである。一実施形態では、スプリッタ２２２が、音声および映像の連続したストリームを音声および映像の複数の２秒間チャンクにスプリットする。コーデック（コンプレッサ-デコンプレッサまたはコーダ-デコーダとも称する）とは、デジタル・データ・ストリームまたはデジタル・データ信号を符号化することおよび／または復号することの可能なデバイスまたはコンピュータ・プログラムである。一実施形態では、固定フレーム音声コーデック２２４は、エンコーダ２２０の１つまたは複数のコンピューティング・デバイスに実行されて生音声２３３を符号化するソフトウェアである。あるいは、固定フレーム音声コーデック２２４は、生音声２３３を符号化するのに使用されるハードウェア論理素子であってもよい。具体的には、固定フレーム音声エンコーダ２２４は、生音声２３３を受け取り、コーデック適用フレーム・サイズ、たとえば、ＡＡＣ-ＬＣではサンプル数１０２４またはＨＥ ＡＡＣではサンプル数２０４８に従って、この音声を符号化する。固定フレーム音声エンコーダ２２４は、符号化済音声フレーム２３７を音声フレーム・バッファ２２５に出力する。同様に、固定時間映像エンコーダ２２６は、生映像２３５をスプリッタ２２０から受け取るが、たとえば、２秒毎に６０フレーム（３０ｆｐｓ（ｆｒａｍｅｓ ｐｅｒ ｓｅｃｏｎｄ））といった固定時間幅に従ってこの映像を符号化する。固定時間映像エンコーダ２２６は、符号化済映像フレーム２３９を映像フレーム・バッファ２２７に出力する。一実施形態では、固定時間映像コーデック２２６は、エンコーダ２２０の１つまたは複数のコンピューティング・デバイスにより実行されて、生映像２３５を符号化するソフトウェアである。あるいは、固定時間映像コーデック２２６は、生映像２３５を符号化するのに使用されるハードウェア論理素子であってもよい。
【００２５】
音声スプリッティング・マルチプレクサ２２８は、符号化済音声フレーム２３７および符号化済映像フレーム２３９を使用して、符号化済メディア・コンテンツ・ファイル２３２（本明細書では「ＱＳＳファイル」と称する）を生成する。上で説明したように、従来のエンコーダは、それぞれが固定された時間幅である映像の一部分および音声の一部分を伴うコンテンツ・ファイルを生成するが、こうしたコンテンツ・ファイルにおいては、音声コーデックに使用されるコーデック適用フレーム・サイズに従って、その部分のサンプル数をフレーム毎のサンプル数で均等に割り切ることができないので、音声の最終フレームが０で埋められる。最終フレームを埋める従来のエンコーダと異なり、音声スプリッティング・マルチプレクサ２２８は、隙間のない音声フレームを使用して、固定時間の映像部分と、コーデック適用フレーム・サイズを有する隙間のない音声フレームを有する音声部分とを有するコンテンツ・ファイルを生成する。音声スプリッティング・マルチプレクサ２２８は、コンテンツ・ファイル２３２を満たすために隙間のない音声フレームを使用するので、従来から行われているようにフレームの最後の数サンプルを０で埋めるのではなく、現在のコンテンツ・ファイル２３２に隙間のないフレームを加えるために音声の次の部分を符号化する。
【００２６】
一実施形態では、音声スプリッティング・マルチプレクサ２２８は、次のコンテンツ・ファイルに使用されるフレーム数を求めるために、次の部分から使用されるサンプルの量を表すサンプル・オフセットを記録する。音声スプリッティング・マルチプレクサ２２８は、音声再生における隙間を示すプレゼンテーション・オフセットも記録する。普通なら次のコンテンツ・ファイルの一部分として再生されるはずのサンプルが、現在のコンテンツ・ファイルの一部分になるので、次のコンテンツ・ファイルのプレゼンテーション・オフセットが、音声再生における隙間を示し、これにより、現在および次のコンテンツ・ファイルの音声部分が、連続したストリームとしてデコーダに提供される。本質的には、音声再生中、コンテンツ・ファイルの音声部分が復号および再生の前にステージされると、コンテンツ・ファイルの先頭に挿入された隙間は除去することができる。プレゼンテーション・オフセットにより、境界アーチファクトを有する多くの小セグメントではなく、連続したストリームとして音声をデコーダに提供することが可能になる。一実施形態では、映像の任意の一部分を探す際、音声／映像同期を維持するために、その隙間の期間はサイレント音声を再生することができる。
【００２７】
一実施形態では、音声スプリッティング・マルチプレクサ２２８が、固定時間幅（例、２秒間）を有する第１の映像部分（例、６０フレーム）と、バッファリングされた隙間のない音声フレームをいくつか有する第１の音声部分とで満たすことにより第１のコンテンツ・ファイルを生成する。このバッファリングされた音声フレームの期間は、固定時間幅よりも長い。
【００２８】
一実施形態では、音声スプリッティング・マルチプレクサ２２８は、現在のコンテンツ・ファイルを満たすのに必要な符号化済音声フレーム２３７の数を求めることによりコンテンツ・ファイル２３２を生成する。一実施形態では、フレームの数は、現在のコンテンツ・ファイルを満たすのに必要なサンプルの数を、コーデック適用フレーム・サイズで割った数（例、フレーム毎のサンプル）以上の最小の整数である。一実施形態では、この数は、たとえば「ｃｅｉｌｉｎｇ（ｘ）＝［ｘ］はｘ以上の最小の整数」といった、実数を次に大きい整数にマップする天井関数（ceiling function）を使用することにより算出することができる。天井関数の一例を以下の式（１）に示す。
ｃｅｉｌ（（ストリームレット当たりのサンプル−オフセット・サンプル）／フレーム当たりのサンプル) （１）
あるいは、他の式を使用することもできる。
【００２９】
音声スプリッティング・マルチプレクサ２２８は、現在のコンテンツ・ファイルを満たすのに十分な符号化済音声フレーム２３７が音声フレーム・バッファ２２５内に存在するかどうかを判定する。十分な符号化済フレームがバッファリングされている場合、音声スプリッティング・マルチプレクサ２２８は、求めた数のフレームで現在のコンテンツ・ファイルを満たす。十分な符号化済フレームがバッファリングされていない場合、音声スプリッティング・マルチプレクサ２２８は、十分な符号化済フレームがバッファ２２５内に格納されるまで待ち、バッファ２２５内に格納された求めた数の符号化済フレームで現在のコンテンツ・ファイルを満たす。一実施形態では、音声スプリッティング・マルチプレクサ２２８は、１）バッファリングされたフレームの数をフレーム当たりのサンプルで掛け、２）前のコンテンツ・ファイルからのサンプル・オフセットがあれば、これを掛け算の積に加え、３）この和が現在のコンテンツ・ファイルを満たすのに必要なサンプル数以上であるかどうかを判定することにより、十分な符号化済フレームがバッファリングされているかどうかを判定する。この演算の一例を以下の式（２）に示す。
バッファリングされたフレーム数＊フレーム当たりのサンプル＋オフセット・サンプル＞＝ストリームレット当たりのサンプル （２）
【００３０】
音声スプリッティング・マルチプレクサ２２８は、次のコンテンツ・ファイルについて、サンプル・オフセットがあればこれを求める。一実施形態では、音声スプリッティング・マルチプレクサ２２８は、コーデック適用フレーム・サイズ（すなわち、フレーム当たりのサンプル）を符号化済フレーム数に掛け、ここから、現在のコンテンツ・ファイルを満たすのに必要なサンプルの数を引き、前のコンテンツ・ファイルからのサンプル・オフセットがあればこれを足すことによりサンプル・オフセットを求める。この演算の一例を以下の式（３）および（４）に示す。
オフセット・サンプル＝送るべきフレーム＊フレーム当たりのサンプル−ストリームレット当たりのサンプル−オフセット・サンプル （３）
送るべきフレーム＝ｃｅｉｌ（（ストリームレット当たりのサンプル−オフセット・サンプル）／フレーム当たりのサンプル） （４）
【００３１】
他の実施形態では、音声スプリッティング・マルチプレクサ２２８は、現在のコンテンツ・ファイルを満たすのに必要なサンプルの数（例、９６０００）を算出することにより、コンテンツ・ファイル２２１を生成する。音声スプリッティング・マルチプレクサ２２８は、現在のコンテンツ・ファイルに必要なフレームの数（例、２秒間部分につき４８Ｋサンプリング・レートの場合９３フレーム）を算出し、サンプルの数がフレーム当たりのサンプルで均等に割り切れない場合には、フレームの数を追加する（たとえば、合計で９４フレームになる）。このことは実質的に、フレーム数を次に大きな整数に切り上げる。音声スプリッティング・マルチプレクサ２２８は、この切り上げた数のフレームで現在のコンテンツを満たす。
【００３２】
一実施形態では、音声スプリッティング・マルチプレクサ２２８は、サンプリング・レート（例、４８Ｋ）に固定時間幅の期間（例、２秒間）を掛けることで、現在のコンテンツ・ファイルを満たすのに必要なサンプルの数（例、９６０００）を算出することによりコンテンツ・ファイル２２１を生成する。音声スプリッティング・マルチプレクサ２２８は、コーデック適用フレーム・サイズ（例、フレーム当たり１０２４サンプル）でサンプル数を割ることにより、現在のコンテンツ・ファイルに必要なフレームの数を算出する。この除算の余りが０であれば、音声スプリッティング・マルチプレクサ２２８は、その数のフレームで現在のコンテンツ・ファイルを満たす。しかし、この除算の余りが０より大きければ、音声スプリッティング・マルチプレクサ２２８は、フレームの数を１だけインクリメントし、このインクリメントした数のフレームで現在のコンテンツ・ファイルを満たす。
【００３３】
更なる実施形態では、音声スプリッティング・マルチプレクサ２２８は、コーデック適用フレーム・サイズをフレームの数に掛けて、現在のコンテンツ・ファイルを満たすのに必要なサンプル数に戻し、サンプル数をサンプリング・レートで割ることで現在のコンテンツ・ファイルの音声の期間を算出（例、ストリームレット期間＝ストリームレット当たりのサンプル／サンプリング・レート）することによりコンテンツ・ファイル２２１を生成する。音声スプリッティング・マルチプレクサ２２８は、固定時間幅からこの期間を引くことにより、次のコンテンツ・ファイルについてのプレゼンテーション・オフセットを求める。音声スプリッティング・マルチプレクサ２２８は、フレーム数にコーデック適用フレーム・サイズを掛け、ここから、現在のコンテンツ・ファイルを満たすのに使用されるサンプルの数を引き、前のコンテンツ・ファイルからのサンプル・オフセットがあればこれを足すことにより（例、式（３））、次のコンテンツ・ファイルについてサンプル・オフセットをアップデートする。
【００３４】
再度図２を参照すると、一実施形態では、スプリッタ２２２がオリジナルのメディア・コンテンツ２３１を生ストリームレットとして受け取る時、スプリッタ２２２は、第１および第２の生ストリームレットを受け取り、この第１および第２の生ストリームレットの音声および映像をスプリットする。固定時間映像エンコーダ２２６が、第１および第２の生ストリームレットの映像を符号化し、音声スプリッティング・マルチプレクサ２２８が、第１の生ストリームレットの符号化された映像を第１のコンテンツ・ファイルに格納し、第２の生ストリームレットの符号化された映像を第２のコンテンツ・ファイルに格納する。固定フレーム音声エンコーダ２２４は、第１の生ストリームレットの音声を音声フレームの第１の組に符号化し、この第１の組を音声フレーム・バッファ２２５に格納する。音声スプリッティング・マルチプレクサ２２８は、第１のコンテンツ・ファイルを満たすのに十分なバッファリングされたフレームが存在するかどうかを判定する。十分でなければ、固定フレーム音声エンコーダ２２４は、第２の生ストリームレットの音声を音声フレームの第２の組に符号化し、この第２の組を音声フレーム・バッファ２２５に格納する。第１のコンテンツ・ファイルを満たすだけの十分なバッファリングされたフレームが存在すれば（場合によっては、もう１つの隙間のないフレームがバッファ２２５に格納されれば）、音声スプリッティング・マルチプレクサ２２８は、バッファリングされた音声フレームを第１のコンテンツ・ファイルに格納する。エンコーダ２２０は、メディア・コンテンツが終了するまでこのプロセスを継続する。
【００３５】
また、音声スプリッティング・マルチプレクサ２２８は隙間のない音声フレームを使用するので、図６Ａおよび６Ｂに示すように、１つのコンテンツ・ファイル２３２内の音声フレームは、映像部分境界と必ずしも整合する必要はない。たとえば、コンテンツ・ファイル２３２の音声部分の期間が、２．００５３秒であり、コンテンツ・ファイル２３２の映像部分の固定時間幅が、２．００秒であることがある。この例では、コーデック適用フレーム・サイズがフレーム当たり１０２４サンプルであり、音声のサンプリング・レートが４８Ｋであり、９４フレームからなる９６２５６サンプルが、コンテンツ・ファイル２３２に記憶された音声部分に格納されている。コンテンツ・ファイル２３２には余分な５３ミリ秒（ｍｓ）が存在するゆえに、固定時間幅音声符号化スキームを使用する場合には次のコンテンツ・ファイル内にあるはずの５３ｍｓの期間を有するサンプルが現在のコンテンツ・ファイル２３２により使用されるので、音声スプリッティング・マルチプレクサ２２８は、次のコンテンツ・ファイルに５３ｍｓのプレゼンテーション・オフセットを与える。また、音声スプリッティング・マルチプレクサ２２８は、次のコンテンツ・ファイルを満たすのに必要な音声フレーム数を求めるためにサンプル・オフセットを記録する。一実施形態では、音声スプリッティング・マルチプレクサ２２８は、固定時間幅を有する符号化済映像部分のうちの１つで、それぞれのコンテンツ・ファイルを満たす（たとえば、フレーム・レートが３０ｆｐｓであれば、６０映像フレーム当たり２秒間）。音声スプリッティング・マルチプレクサ２２８は、コンテンツ・ファイルのうちのいくつかを、いくつかのバッファリングされた音声フレームで満たすが、これら音声フレームの期間は、音声スプリッティング・マルチプレクサ２２８により決まる映像部分境界に音声フレームが整合するかどうかに応じて、固定時間幅よりも大きいこと、固定時間幅よりも小さいこと、または、固定時間幅と等しいことがある。
【００３６】
図６Ａを参照すると、一実施形態では、音声スプリッティング・マルチプレクサ２２８は、２秒間からなる固定時間幅に等しい期間の約６０の映像フレームを有する第１の映像部分６１１と、それぞれがフレーム当たり１０２４のサンプルを有し、合計９６２５６サンプルとなる９４の音声フレームを有する第１の音声部分６２１とで満たすことにより、第１のストリームレット（すなわち、コンテンツ・ファイル）６０１を生成する。第１の音声部分６２１の期間は、約２．００５３秒である。第１のストリームレット６０１の音声境界６５２と映像境界６５４とが再生について整合しているので、音声スプリッティング・マルチプレクサ２２８は、第１のストリームレット６０３の第１の音声部分６３１のプレゼンテーション・オフセットを０と判定する。
【００３７】
音声スプリッティング・マルチプレクサ２２８は、第２の映像部分６１２（６０フレーム、２秒間）と、９４の音声フレームを有する第２の音声部分６２２とで満たすことにより第２のストリームレット６０２を生成する。第２の音声部分６２２の期間は、約２．００５３秒である。第１のストリームレット６０１の第１の音声部分６２１の期間が約２．００５３秒なので、音声スプリッティング・マルチプレクサ２２８は、第２のストリームレット６０２の第２の音声部分６３２のプレゼンテーション・オフセットを約５．３ミリ秒（ｍｓ）と判定する。このプレゼンテーション・オフセットは、第１のストリームレット６０１と第２のストリームレット６０２との間の音声の隙間を示す。図６Ｂに示すように、第２のストリームレット６０２の音声境界６５２と映像境界６５４とは、再生について整合していない。このプレゼンテーション・オフセットを使用して、第１および第２のストリームレット６０１および６０２の音声部分が、連続したストリームとしてデコーダに提供されるようにステージされることを可能にすることができる。
【００３８】
音声スプリッティング・マルチプレクサ２２８は、第３の映像部分６１３（６０フレーム、２秒間）と、９４の音声フレームを有する第３の音声部分６２３とで満たすことにより第３のストリームレット６０３を生成する。第３の音声部分６２３の期間は、約２．００５３秒である。第２のストリームレット６０２の第２の音声部分６２２の期間が約２．００５３秒なので、音声スプリッティング・マルチプレクサ２２８は、第３のストリームレット６０３の第３の音声部分６３３のプレゼンテーション・オフセットを約１０．６６ｍｓと判定する。このプレゼンテーション・オフセットは、第２のストリームレット６０２と第３のストリームレット６０３との間の音声の隙間を示す。図６Ｂに示すように、第３のストリームレット６０３の音声境界６５２と映像境界６５４とは、再生について整合していない。このプレゼンテーション・オフセットを使用して、第２および第３のストリームレット６０２および６０３の音声部分が、連続したストリームとしてデコーダに提供されるようにステージされることを可能にすることができる。
【００３９】
音声スプリッティング・マルチプレクサ２２８は、第４の映像部分６１４（６０フレーム、２秒間）と、９３の音声フレームを有する第４の音声部分６２４とで満たすことにより第４のストリームレット６０４を生成する。第４の音声部分６２４の期間は、約１．９８４秒である。第３のストリームレット６０３の第３の音声部分６２３の期間が約２．００５３秒なので、音声スプリッティング・マルチプレクサ２２８は、第４のストリームレット６０４の第４の音声部分６３４のプレゼンテーション・オフセットを約１６ｍｓと判定する。このプレゼンテーション・オフセットは、第３のストリームレット６０３と第４のストリームレット６０４との間の音声の隙間を示す。図６Ｂに示すように、第４のストリームレット６０３の音声境界６５２と映像境界６５４とは、再生について整合していない。このプレゼンテーション・オフセットを使用して、第３および第４のストリームレット６０３および６０４の音声部分が、連続したストリームとしてデコーダに提供されるようにステージされることを可能にすることができる。しかし、第４のストリームレット６０４の後、音声境界６５２と映像境界６５４とは整合し、このことは、第５のストリームレット（図示せず）が０のプレゼンテーション・オフセットを有することを意味する。図６Ａおよび６Ｂの実施形態では、サンプリング・レートが４８ｋＨｚであり、固定時間幅が２秒間であり、コーデック適用フレーム・サイズがフレーム当たり１０２４サンプルであることに留意されたい。
【００４０】
上記の実施形態では、３つの第１のストリームレット６０１〜６０３の音声部分が、９４の音声フレームを有し、第４のストリームレット６０４の音声部分が、９３の音声フレームを有する。この実施形態では、映像が３０ｆｐｓで符号化される場合、第４のコンテンツ・ファイル６０１〜６０４の映像部分のそれぞれは、約６０の映像フレームを有する。このパターンは、メディア・コンテンツの終わりに達するまで繰り返される。この実施形態では、各第４のコンテンツ・ファイルの後に、プレゼンテーション・オフセットおよびサンプル・オフセットが０になり、このことは、各第４のコンテンツ・ファイルの後に、音声境界６５２と映像境界６５４とが整合することを意味することに留意されたい。
【００４１】
図６Ｂから分かるように、８秒間のメディア・コンテンツの後、映像境界と音声境界とが整合する。よって、境界アーチファクトの頻度を減らし、ＡＡＣフレーム・サイズを整合させる他の手法の１つは、８秒間を固定時間幅に使用するものになるはずである。しかし、こうした手法には、以下の不利な点がある。１）この手法には、８、１６、３２秒等のチャンク・サイズの大きな映像が必要である。２）この手法では、特定のフレーム・サイズ、すなわちフレーム当たり１０２４サンプルに実施が拘束される。フレーム・サイズをたとえば２０４８等に変更する場合、この手法では、異なるフレーム・サイズを伴う音声コーデックに切り替えねばならず、映像のチャンク期間も変更せねばならない。３）この手法では、音声サンプル・レートが常に４８ｋＨｚである必要がある。４４．１ｋＨｚ等の他の一般的なサンプル・レートでは、異なる、かつ、場合によってはずっと大きなチャンク・サイズが必要である。あるいは、ソース（source）音声を４８ｋＨｚにアップ・サンプルしなければならない。しかし、アップ・サンプルすれば、アーチファクトが導入され、音声コーデックの効率が低減されることがある。しかし、本明細書に記載の実施形態では、同一のチャンク期間を維持しながら、チャンク境界アーチファクトを導入することなく、大きなフレーム・サイズ（ＡＡＣ、ＡＣ３等）を伴う音声コーデックを使用することにより符号化を行うことができる。
【００４２】
あるいは、他のサンプリング・レート（例、４４．１ｋＨｚ）、固定時間幅（例、０．１〜５．０秒）、映像フレーム・レート（例、２４ｆｐｓ、３０ｆｐｓ等）、および／またはコーデック適用フレーム・サイズ（例、２０４８）を使用することもできる。ソース映像が異なれば、異なるフレーム・レートが使用される。米国のほとんどの無線信号は、３０ｆｐｓ（実際には、２９．９７）である。いくつかのＨＤ信号は、６０ｆｐｓ（５９．９４）である。ファイル-ベースのコンテンツのいくつかは２４ｆｐｓである。一実施形態では、エンコーダ２２０は、追加のフレームを生成することが必要になるので映像のフレーム・レートを上昇させない。しかし、追加のフレームを生成することは、この追加の負荷ついて大した恩恵をもたらさない。したがって、たとえば、オリジナルのメディア・コンテンツのフレーム・レートが２４ｆｐｓの場合、エンコーダ２２０は、３０ｆｐｓにアップ・サンプルするのではなく２４ｆｐｓのフレーム・レートを使用する。しかし、いくつかの実施形態では、エンコーダ２２０は、フレーム・レートをダウン・サンプルすることがある。たとえば、オリジナルのメディア・コンテンツのフレーム・レートが６０ｆｐｓの場合、エンコーダ２２０は、３０ｆｐｓにダウン・サンプルすることがある。６０ｆｐｓを使用すると、目標とするビット・レートで符号化することが必要なデータの量が２倍になって、クオリティーが損なわれることがあるので、こうしたダウン・サンプルが行われることがある。一実施形態では、エンコーダ２２０は、ダウン・サンプリング後のまたは受け取られるフレーム・レート（通常は３０ｆｐｓまたは２４ｆｐｓ）を求めると、クオリティー・プロファイルのほとんどについてこのフレーム・レートを使用する。最低クオリティー・プロファイル等のいくつかのクオリティー・プロファイルには、より低いフレーム・レートが使用されることがある。しかし、他の実施形態では、たとえば、携帯電話や計算能力が劣っている等の資源の限られた他のデバイスを対象とするために、エンコーダ２２０は、異なるクオリティー・プロファイルに対して異なるフレーム・レートを使用することができる。これらのケースでは、より低いフレーム・レートを伴うプロファイルをより多く有することが有益なことがある。
【００４３】
これらのパラメータに対して他の値を使用する場合、音声境界６５２および映像境界６５４が図６Ｂに示す実施形態とは異なってくる場合があることに留意されたい。たとえば、サンプリング・レートとして４４．１ｋＨｚ、コーデック適用フレーム・サイズとして１０２４、固定時間幅として２秒間を使用する場合、第１のコンテンツ・ファイルの音声部分は、８７の音声フレームを有することとなり、第２〜第７のコンテンツ・ファイルは、８６の音声フレームを有することとなる。このパターンは、メディア・コンテンツ内に残る映像が不十分になるまで繰り返される。この実施形態では、１２８のコンテンツ・ファイルの後毎に、プレゼンテーション・オフセットおよびサンプル・オフセットが０になり、このことは、略表１-１に示すように、音声境界６５２と映像境界６５４とが１２８番目のコンテンツ・ファイルの後毎に整合することを意味することに留意されたい。
【表１】
上の表中のサンプル・オフセットは、説明を簡単にするために、秒やミリ秒ではなく、サンプル単位で示していることに留意されたい。サンプル・オフセットをプレゼンテーション・オフセットに変換する場合、サンプル・オフセットを４４１００で割って、秒で表したプレゼンテーション・オフセットを求め、これに１０００を掛けて、ミリ秒で表したプレゼンテーション・オフセットを得ることができる。一実施形態では、ミリ秒で表したプレゼンテーション・オフセットが、ストリームレット・ヘッダに記憶されることがある。あるいは、プレゼンテーション・オフセットまたはサンプル・オフセットが、他の単位でストリームレット・ヘッダに記憶されることもある。
【００４４】
他の実施形態では、音声スプリッティング・マルチプレクサ２２８は、固定時間幅を有する符号化済映像フレーム２３９（例、固定時間幅部分）でそれぞれを埋めることにより複数の符号化済コンテンツ・ファイル２３２を生成し、これらコンテンツ・ファイル２３２をいくつかの隙間のない音声フレーム２３７で満たすが、コンテンツ・ファイル２３２内で使用されている隙間のない音声フレームを収容するように、音声フレーム２３７の期間は、固定時間幅より短く、またはこれより長くなっている。たとえば、映像のうち２秒間等の固定時間幅を有する部分と、固定時間幅よりも長い期間を有する隙間のない複数の音声フレームを有する音声部分とで第１のコンテンツ・ファイルを満たすことができる。そのうち、サンプル・オフセットが大きくなって、使用することのできる音声フレームの数が小さくなり、この場合、音声フレームの期間が、固定時間幅より短くなる場合がある。折に触れて、音声の音声境界が、映像の映像境界にマッチすることができる。
【００４５】
他の実施形態では、音声スプリッティング・マルチプレクサ２２８は、映像の第１の部分の映像フレームと、音声の第１の部分からの音声フレームと、第２の部分からの音声フレームとを有する第１のコンテンツ・ファイルを生成することにより、符号化済コンテンツ・ファイル２３２を生成する。音声スプリッティング・マルチプレクサ２２８は、映像の第２の部分の映像フレームを有する第２のコンテンツ・ファイルを生成する。音声の場合、音声スプリッティング・マルチプレクサ２２８は、音声境界が映像境界に載るかどうかを判定する。音声境界が映像境界に載る場合、音声スプリッティング・マルチプレクサ２２８は、第２の部分の残りの音声フレームで第２のコンテンツ・ファイルを満たす。しかし、音声境界が映像境界に載らない場合、音声スプリッティング・マルチプレクサ２２８は、メディア・コンテンツの第３の部分の音声フレームを符号化し、第２の部分の残りの音声フレームおよび第３の部分からの音声フレームで第２のコンテンツ・ファイルを満たす。このプロセスは、コンテンツ・ファイルの終わりに達するまで繰り返される。
【００４６】
再度図２を参照すると、エンコーダ２２０は、オリジナルのメディア・コンテンツ２３１を符号化すると、オリジン・コンテンツ・サーバ２１０に符号化済メディア・コンテンツ・ファイル２３２を送り、オリジン・コンテンツ・サーバ２１０は、ネットワーク接続２４１を介して、符号化済メディア・コンテンツ２３２をメディア・プレイヤ２００に配信する。メディア・プレイヤ２００は、映像の固定時間幅および音声の可変時間幅を有するコンテンツ・ファイルを受け取ると、これらコンテンツ・ファイルのプレゼンテーション・オフセットを使用して、音声を連続したストリームとしてデコーダに提供するようにステージし、これにより、境界アーチファクトにもたらされるポップ雑音またはクリック雑音を除去または低減する。本質的に、音声の再生中、メディア・プレイヤ２００は、コンテンツ・ファイルの音声部分が復号および再生の前にステージされると、コンテンツ・ファイルの先頭に挿入された隙間を除去する。他の実施形態では、本明細書に記載する音声スプリッティングを行わず、最終フレームを０で埋める場合は、メディア・プレイヤ２００を、音声をデコーダに送る前に最終フレームの埋められたサンプルを除去するように構成することができる。しかし、この手法は、特定の状況では実用的でないことがあり、たとえば、メディア・プレイヤが第３者により提供されるとき、または、復号後の音声フレームのデータへのアクセスが制限されるときである。
【００４７】
各メディア・プレイヤ２００に１つの線を示しているが、各線２４１がＣＤＮ２４０への複数のネットワーク接続を表すこともあることに留意されたい。一実施形態では、各メディア・プレイヤ２００が、ＣＤＮ２４０への複数のＴＣＰ（伝送制御プロトコル）接続を確立することがある。他の実施形態では、メディア・コンテンツが、複数のＣＤＮ、たとえば、複数のＣＤＮのそれぞれに関連するオリジン・サーバに格納される。ＣＤＮ２４０は、帯域幅コストを削減し、コンテンツの全体的使用可能度を増大させることにより、エンド・ユーザ（例、視聴者）に対する性能、スケーラビリティ、費用効果性の改善の目的で使用することができる。ＣＤＮは様々なやり方で実現することができ、それらのオペレーションについての詳細は、当業者には理解されるはずである。したがって、それらのオペレーションについての更なる詳細は含めていない。他の実施形態では、ピア・ツー・ピア・ネットワーク等の他の配信技法を使用して、オリジン・サーバからメディア・プレイヤにメディア・コンテンツを配信することができる。
【００４８】
上で説明した実施形態では、コンテンツ・ファイル２３２は、オリジナルのメディア・コンテンツ・ストリーム２３１のコピーの１つを表す。しかし、他の実施形態では、オリジナルのメディア・コンテンツ２３１の各部分を符号化して、コンテンツの同一部分の複数の符号化表現とすることができる。これら複数の符号化表現は、様々なクオリティー・プロファイルに従って符号化し、クライアント・デバイス２０４から独立して要求すること、クライアント・デバイス２０４により独立して再生することのできる別々のファイルとして格納することができる。これらのファイルはそれぞれ、１つまたは複数のコンテンツ・サーバ２１０内、ＣＤＮ２４０のウェブ・サーバ、プロキシ・キャッシュ、エッジ・キャッシュ上に格納することができ、別々に要求し、クライアント・デバイス２０４に配信することができる。一実施形態では、エンコーダ２２０は、たとえば１０または１３等のいくつかの異なるクオリティー・レベルでオリジナルのコンテンツ・メディア２３１を同時に符号化する。各クオリティー・レベルをクオリティー・プロファイルまたはプロファイルと称する。たとえば、メディア・コンテンツが１時間の期間を有し、２秒間の期間を有する複数のＱＳＳファイルにセグメント化される場合、メディア・コンテンツの符号化表現毎に１８００のＱＳＳファイルが存在する。メディア・コンテンツを異なる１０個のクオリティー・プロファイルに従って符号化する場合、このメディア・コンテンツについて１８０００のＱＳＳファイルが存在する。こうしたクオリティー・プロファイルは、どのようにストリームを符号化するかを示すことがあり、たとえば、画像の幅および高さ（すなわち、画像サイズ）、映像ビット・レート（すなわち、映像を符号化する速度）、音声ビット・レート、音声サンプル・レート（すなわち、キャプチャする際に音声をサンプリングする速度）、音声トラックの数（例、モノ、ステレオ等）、フレーム・レート（例、ｆｐｓ）、ステージング・サイズ等のパラメータを特定することがある。たとえば、複数のメディア・プレイヤ２００が、異なるクオリティー・レベルの同一のメディア・コンテンツ２３２を個別に要求することができる。たとえば、各メディア・プレイヤ２００が、メディア・コンテンツ２３２の同一の部分（例、同一の時間インデックス）を様々なクオリティー・レベルで要求することができる。たとえば、あるメディア・プレイヤが、自体のコンピューティング・デバイスが十分な計算能力および十分なネットワーク帯域幅を有するがゆえに、ＨＤクオリティー映像を有するストリームレットを要求し、他のメディア・プレイヤが、たとえば、自体のコンピューティング・デバイスが十分なネットワーク帯域幅を有することができないがゆえに、クオリティーのより低いストリームレットを要求することがある。一実施形態では、出願日２００５年４月２８日の米国特許出願公開第２００５／０２６２２５７号に記載されるように、メディア・プレイヤ２００は、メディア・コンテンツの様々なコピー（例、様々なクオリティー・ストリームレット）からそれぞれの部分を要求することにより、部分境界においてクオリティー・レベルをシフトする。あるいは、メディア・プレイヤ２００は、本開示内容の恩恵を受ける当業者に理解されるべき他の技法を使用することにより、それらの部分を要求することもできる。
【００４９】
エンコーダ２２０は、メディア・コンテンツの特定の部分にどのクオリティー・プロファイルが利用可能かを特定することもでき、また、どのくらいのメディア・コンテンツが、たとえばＱＭＸファイルを使用することによる配信に使用可能かを特定することができる。ＱＭＸファイルは、利用可能なＱＳＳファイルで表されたメディア・コンテンツの現在の期間を示す。ＱＭＸファイルは、メディア・コンテンツに対する目次として機能して、どのＱＳＳファイルが配信のために利用可能か、及び、どこからＱＳＳファイルを取り出すことができるかを示すことができる。ＱＭＸファイルは、たとえば、ＣＤＮ２４０を介してメディア・プレイヤ２００に送ることができる。あるいは、メディア・プレイヤ２００が、特定のメディア・コンテンツに対して利用可能なクオリティー・プロファイルを要求することもできる。他の実施形態では、ＣＤＮのスケーリング能力を使用することによりこの構成のスケール変えを行って、ＨＴＴＰトラフィックを複数のメディア・プレイヤ２００に配信することができる。たとえば、符号化されたメディア・コンテンツを格納するデータ・センタが、このデータ・センタからの符号化されたメディア・コンテンツを要求する複数のメディア・プレイヤにサービスするためにオリジン・コンテンツ・サーバ２１０からなるクラスタを有することがある。あるいは、本開示内容の恩恵を受ける当業者には理解されるはずの他の構成を使用することもできる。
【００５０】
熟考した一実施形態では、メディア・プレイヤ２００は、個々のストリームレット・ファイル（例、ＱＳＳファイル）を要求することによりメディア・コンテンツのそれぞれの部分を要求する。メディア・プレイヤ２００は、メタデータ・ディスクリプタ・ファイル（例、ＯＭＸファイル）に従ってＱＳＳファイルを要求する。メディア・プレイヤ２００は、たとえば、提供用のメディア・コンテンツをユーザが選択することに応答して、ＱＭＸファイルをフェッチし、また、このＱＭＸファイルを読んで、現在の期間を使用することによるメディア・コンテンツの再生の開始をいつにするか、どこにＱＳＳファイルを要求するかを決定する。ＱＭＸファイルは、いつ符号化プロセスを開始するか（例、メディア・コンテンツの開始時刻）を示すＵＴＣ（協定世界時）インジケータ等のＱＭＸタイムスタンプと、どれくらい多くのメディア・コンテンツが配信に使用可能かを示す現在の期間（current duration）とを含む。たとえば、ＱＭＸタイムスタンプは、符号化プロセスが午後６時に開始され（ＭＤＴ）、メディア・コンテンツの４５００個のＱＳＳファイルが配信に使用可能であることを示すことができる。メディア・プレイヤ２００は、コンテンツの期間（ライブ再生）が約１５分であると判定し、プログラム開始後の１５分間またはこれよりやや前のポイントにおけるプログラムの再生に対応するＱＳＳファイルの要求を開始することを決定することができる。一実施形態では、メディア・プレイヤ２００は、メディア・コンテンツ内のオフセットにおける対応するストリームレットをフェッチすることにより、メディア・プレイヤ２００がコンテンツの再生を開始すべきメディア・コンテンツ内のポイントを求めることができる。エンコーダがＱＳＳファイルの他の組をコンテンツ・サーバ上に格納する毎に（例、メディア・コンテンツの次の２秒間をそれぞれ異なる１０のクオリティー・レベルで表す１０個のＱＳＳファイルの組）、ＱＭＸファイルはアップデートされ、メディア・プレイヤ２００でＱＭＸファイルをフェッチして、インターネットを介して更に２秒間が配信に使用可能であることを示すことができる。メディア・プレイヤ２００は、アップデートされるＱＭＸファイルについて定期的にチェックすることができる。あるいは、ＱＭＸファイルおよび任意のアップデートをメディア・プレイヤ２００に送り込んで、メディア・コンテンツがいつインターネット介した配信に使用可能であるのかを示すこともできる。
【００５１】
オリジン・コンテンツ・サーバ２１０は、ＣＤＮ２４０内にあるものとして図示しているが、これがＣＤＮ２４０の外側にあり、やはりＣＤＮ２４０に関連することができることに留意されたい。たとえば、１つのエンティティが、ストリームレットを格納するコンテンツ・サーバを所有、動作することができるが、自体のデバイスが１つまたは複数の別々のエンティティにより所有、動作されることのあるＣＤＮ２４０が、ストリームレットを配信する。
【００５２】
メディア・コンテンツは、（電子デバイス（すなわち、クライアント・デバイス）上で動作している）メディア・プレイヤ２００により処理されると、メディア・プレイヤ２００がイベントの視覚および／または音声表現をメディア・プレイヤ２００の視聴者に提供することを可能にするデータであることに留意されたい。メディア・プレイヤ２００は、メディア・コンテンツを再生する（たとえば、映像を表示し、音声を再生する）ソフトウェアの１つであってもよく、スタンドアロンのソフトウェア・アプリケーション、またはウェブ・ブラウザ・プラグイン等であってもよく、あるいはブラウザ・プラグインと支援ウェブ・ページ・ロジック（supporting web page logic）との組合せ等であってもよい。たとえば、イベントは、スポーツ・イベント等のテレビ放送、生演奏または録画もしくは録音された演奏、生の報道または録画もしくは録音された報道等であってもよい。このコンテキストでのライブ・イベントまたは予定されたテレビ・イベントとは、スケジュールに従って特定の時点で再生されるように予定されたメディア・コンテンツを指す。ライブ・イベントは、その中の重要なイベントのスローモーション・クリップ等（例、リプレイ）の、ライブ・メディア・コンテンツと混合されたプレレコ型のコンテンツを有することもあるが、こうしたコンテンツは、生のテレビ放送の合間に再生される。本明細書に記載の実施形態は、ビデオ・オン・デマンド（ＶＯＤ）のストリーミングに使用することもできることに留意されたい。
【００５３】
図３Ａは、エンコーダ２２０をそれぞれが用いた複数のホスト３１４を含めた符号化システム３２０を用いることのできるコンピューティング環境３００の他の実施形態を示す概略ブロック図である。一実施形態では、符号化システム３２０が、マスタ・モジュール３２２および複数のホスト・コンピューティング・モジュール（以降、「ホスト」）３１４を含む。図２に関連して説明したように、ホスト３１４はそれぞれエンコーダ２２０を用いる。ホスト３１４は、１つまたは複数のパーソナル・コンピュータ、サーバ等に実装することができる。更なる実施形態では、ホスト３１４は、たとえば、単一のコンピュータに差し込むカード等の専用のハードウェアであることがある。
【００５４】
一実施形態では、マスタ・モジュール（以降、「マスタ」）３２２は、ストリームレット生成システム３０１から生のストリームレット３１２を受け取るように構成されるが、このストリームレット生成システム３０１は、メディア・コンテンツを発行者３１０から受け取る受取モジュール３０２と、メディア・コンテンツを生のストリームレット３１２にセグメント化するストリームレット・モジュール３０３とを含む。マスタ・モジュール３２２は、生ストリームレット３１２を処理のためにステージする。他の実施形態では、マスタ３２２は、符号化および／または圧縮されたソース（source）・ストリームレットを受け取り、各ソース・ストリームレットを展開して生ストリームレットを作り出すことができる。本明細書で使用するように、用語「生ストリームレット」は、圧縮されていないストリームレット３１２、または、著しくクオリティーを失うことなくサイズを実質的に縮減させるために軽く圧縮されたストリームレット３１２のことを指す。軽く圧縮した生ストリームレットは、より急速により多くのホストへ送信することが可能である。各ホスト３１４は、マスタ３２２に結合されており、マスタ３２２から符号化すべき生ストリームレットを受け取るように構成される。一例では、ホスト３１４は、同一の時間インデックスおよび同一の固定時間幅ならびに様々なビット・レートを有する複数のストリームレットを生成する。一実施形態では、各ホスト３１４は、マスタ３２２から送られる生ストリームレット３１２から符号化済ストリームレットの組３０６を生成するように構成され、ただし、組３０６の符号化済ストリームレットは、メディア・コンテンツの同一部分を、サポートされたビット・レート毎に表す（すなわち、各ストリームレットが、使用可能なクオリティー・プロファイルのうちの１つに従って符号化される）。あるいは、符号化に要する時間を減らすために、各ホスト３１４を、サポートされたビット・レートのうちの１つで単一の符号化済ストリームレットを作り出すように確保することもできる。
【００５５】
符号化が完了すると、ホスト３１４は、組３０６をマスタ３２２に戻し、これにより、符号化システム３２０は、組３０６をストリームレット・データベース３０８に格納することができる。マスタ３２２は更に、符号化ジョブをホスト３１４に割り当てるように構成される。一実施形態では、各ホスト３１４は、符号化ジョブ完了ビッド（bid）（以降、「ビッド」）をマスタ３２２に提示するように構成される。マスタ３２２は、ホスト３１４からのビッドに応じて符号化ジョブを割り当てる。各ホスト３１４は、複数のコンピューティング変数に応じてビッドを生成するが、これらコンピューティング変数には、現在の符号化ジョブ完了パーセンテージ、平均ジョブ完了時間、プロセッサ速度、物理的メモリ容量等が含まれることがあるが、これらに限定されない。
【００５６】
たとえば、ホスト３１４は、過去のパフォーマンス履歴に基づいて、ホスト３１４が符号化ジョブを１５秒で完了させることができるであろうことを示すビッドを提示することができる。マスタ３２２は、複数のビッドから最善のビッドを選択し、これに続いて、最善のビッドを伴うホスト３１４に符号化ジョブを提示するように構成される。したがって、説明している符号化システム３２０は、各ホスト３１４が同一のハードウェアを有することが必要でなく、有益なことに、ホスト３１４の使用可能な計算能力を活用する。あるいは、マスタ３２２は、早いものから順にホスト３１４を選択するか、または、特定の符号化ジョブに適したものと考えられる他のアルゴリズムに基づいてホスト３１４を選択する。
【００５７】
１つのストリームレットを符号化するのに要する時間は、ホスト３１４の計算能力、および、オリジナルのメディア・コンテンツのコンテンツ・ファイルの符号化要件に依存する。符号化要件の例には、２パスまたは複数パス符号化、様々なビット・レートの複数のストリームが含まれことがあるが、これらに限定されない。本発明の利点の１つは、ライブ・コンテンツ・ファイルに２パス符号化を行うことができることである。通常は、２パス符号化を行うためには、従来技術のシステムは、符号化の前にコンテンツ・ファイルが完全になるのを待たなければならない。しかし、ストリームレットは、必要と思われる回数だけ符号化することができる。ストリームレットは、期間の小さな（例、２秒間）密封されたメディア対象なので、初めのストリームレットがキャプチャされると、ライブ・イベントに対して複数パス符号化を開始することができる。
【００５８】
一実施形態では、エンコーダ２２０は、オリジナルのコンテンツ・ファイルを複数のソース・ストリームレットにセグメント化し、たとえば、テレビ番組が終了するのを待つことなく、複数のコピー（例、ストリーム）の２パス符号化を対応する生ストリームレット３１２毎に行う。よって、ストリームレット生成システム３０１がオリジナルのコンテンツ・ファイルのキャプチャを開始するすぐ後に、ウェブ・サーバ３１６は、インターネットを介してストリームレットをストリーミングすることが可能である。発行者３１０から送信されるライブ・ブロードキャストとコンテンツが使用可能になることとの間の遅延は、ホスト３１４の計算能力に依存する。
【００５９】
図３Ｂは、一実施形態によるストリームレット３１２の並行符号化の一実施形態を示す概略ブロック図である。一例では、ストリームレット生成システム３０１が、オリジナルのコンテンツ・ファイルのキャプチャを開始し、第１のストリームレット３１２ａを生成し、これを符号化システム３２０に渡す。符号化システム３２０は、複数のストリームレット３０４ａ（３０４ａ１、３０４ａ２、３０４ａ３等は、互いに異なるビット・レートのストリームレット３０４を表す）からなる第１の組３０６ａを生成するのに、たとえば１０秒間かかることがある。符号化システム３２０に関連して上で説明したように、生のストリームレット３１２または軽く符号化したストリームレット３１２を処理するのに要する時間幅を視覚的に示すために、図３Ｂでは、符号化プロセスを概括的にブロック３０８として示している。符号化システム３２０は、２つ以上のストリームレット３１２を同時に処理することができ、ストリームレット生成モジュール３０１からストリームレットが到着すると、ストリームレットの処理が開始されることとなる。
【００６０】
第１のストリームレット３１２ａを符号化するのに必要な１０秒の間に、ストリームレット・モジュール４０４は、符号化すべき更なる５つの２秒間ストリームレット、ストリームレット３１２ｂ、３１２ｃ、３１２ｄ、３１２ｅ、３１２ｆを生成し、マスタ３２２は、対応する生ストリームレットを作成し、これをステージする。第１の組３０６ａが使用可能になると、その２秒後に次の組３０６ｂが使用可能になり、以降この流れが繰り返される。こうして、オリジナルのコンテンツ・ファイルは、様々なクオリティー・レベルで符号化されてインターネットを介してストリーミングされ、ライブで現れる。本明細書で１０秒間の遅延が与えられているのは、例としてのみのことである。符号化システム３２０の処理能力を増大させるために、複数のホスト３１４を符号化システム３２０に加えることができる。高ＣＰＵ性能システムを加えることにより、あるいは、複数の低性能システムを加えることにより、遅延をほぼ感知できないレベルにまで短くすることができる。
【００６１】
ストリームレットに適用されるどんな特定の符号化スキームも完全になるのに、ストリームレット自体の時間幅より長く時間がかかる可能性がある。たとえば、２秒間のストリームレットに対して、クオリティーの極めて高い符号化を終えるのに５秒間かかることがある。あるいは、各ストリームレットについて要する処理時間が、ストリームレットの時間幅よりも小さいこともある。しかし、連続したストリームレットのオフセット並行符号化は、符号化システム３２０により規則正しい間隔で符号化が行われる（これらのストリームレットが符号化システム３２０に提示される間隔にマッチする。例えば、２秒）ので、符号化システム３２０の出力タイミングが、非符号化ストリームレット３１２のリアルタイムでの提示速度より遅れることはない。
【００６２】
ここで図３Ａを参照すると、マスタ３２２およびホスト３１４は、図示のように、単一のローカル・エリア・ネットワーク内に位置することができ、言い換えると、ホスト３１４を、マスタ３２２に物理的に近接させることができる。あるいは、ホスト３１４は、インターネットまたは他の通信ネットワークを介して、マスタ３２２から符号化ジョブを受け取ることもできる。たとえば、複数のホストをセットアップするのが困難な遠隔地でのライブでのスポーツ・イベントを考えられたい。この例では、マスタは、ストリームレットのオンラインでの発行前に符号化も軽い符号化も行わない。それゆえに、ホスト３１４は、それらのストリームレットを取り出し、上で説明したように、これらを複数のビット・レート組３０６に符号化する。
【００６３】
さらに、符号化ジョブを再始動することおよび／またはストリームレットの発行を中断することなく、ホスト３１４を、符号化システム３２０に動的に追加するまたは符号化システム３２０から動的に取り除くことができる。あるホスト３１４がクラッシュまたは何らかの故障を起こした場合、その符号化ワークは、シンプルに他のホストに再度割り当てられる。
【００６４】
一実施形態では、符号化システム３２０を、特定の再生プラットフォームに特有のストリームレットを作り出すように構成することもできる。たとえば、単一の生ストリームレットについて、単一のホスト３１４が、パーソナル・コンピュータ再生のための様々なクオリティー・レベル向けのストリームレット、独自の異なるコーデックを有する複数の携帯電話での再生向けのストリームレット、（プログラミング・ガイドのような）ストリームのサムネイル表示のみでの再生時の使用向けの映像専用の小ストリームレット、及びアーカイビングでの使用向けの非常に高クオリティーなストリームレットを作り出すことができる。
【００６５】
図示の実施形態では、コンピューティング環境３４０は、コンテンツ管理システム（ＣＭＳ）３００を含む。ＣＭＳ３４０は、たとえばストリームレット・データベース３０８を使用することにより、符号化済メディア・コンテンツ２２０を管理し、発行者がタイムライン（本明細書では仮想タイムライン（ＱＶＴ）と称する）を生成、改変して、メディア・コンテンツ２３２の再生を計画することを可能にする発行システムである。ＱＶＴは、視聴者向けの再生リストを規定し、いつメディア・プレイヤ２００がメディア・コンテンツを再生すべきかを示すことのできるメタデータである。たとえば、タイムラインは、メディア・コンテンツ２３２の開始時刻と、メディア・コンテンツ２３２の現在の期間（例、メディア・コンテンツのうち配信に使用することのできる部分の量）とを指定して、スケジュールに従ってメディア・イベントを再生することを可能にすることができる。上の例では、エンコーダ２２０が、ストリーム（例、メディア・コンテンツ２３２のコピー）についての情報でＣＭＳ２４０をアップデートして、ストリームのうちの特定の部分（例、ストリームレット）がＣＤＮ２４０に関連するオリジン・コンテンツ・サーバ２１０に送られたことを示す。この実施形態では、ＣＭＳ３４０は、エンコーダ２２０から、たとえば以下の中のいずれかの情報を受け取る。それは、暗号化キー／エンコーダ２２０の組が符号化済メディア・コンテンツ２３２の一部分をオリジン・コンテンツ・サーバ２１０に送ったということを示すアベイラビリティ情報／メディア・コンテンツ２３２の特定部分に対してどのクオリティー・レベルが利用可能であるかを示す情報／たとえば、コンテンツの放送日、タイトル、女優、男優、開始インデックス、終了インデックス、権利所有発行者データ、暗号化レベル、コンテンツ所要時間、エピソードまたはプログラム名、発行者を含むメタデータ／使用可能なメニュー、サムネイル、サイドバー、広告、早送り、巻戻し、一時停止、再生等のエンド・ユーザのナビゲーション環境に使用可能なツール／フレーム・サイズ、音声チャネル情報、コーデック、サンプル・レート、フレーム・パーサ情報を含めたビット・レート値である。あるいは、エンコーダ２２０は、上で述べた情報より多くの情報を送ることも、これより少ない情報を送ることもある。
【００６６】
図示の実施形態では、コンピューティング環境３００は、デジタル権利管理能力をシステムに提供するデジタル権利管理サーバ（ＤＲＭ）３５０を含む。ＤＲＭ３５０は、エンド・ユーザの認証によりこのエンド・ユーザに暗号化キーを供給するように更に構成される。一実施形態では、ＤＲＭサーバ３５０は、ログイン証明に基づいてユーザを認証するように構成される。当業者には、ＤＲＡＭサーバ３５０がエンド・ユーザを認証することのできる異なる様々な方法が理解されるであろうが、こうした方法には、暗号化されたクッキー、ユーザ・プロファイル、地理的位置、ソース・ウェブサイト等が含まれるが、これらに限定されない。
【００６７】
他の実施形態では、コンピューティング環境３００が、ディレクトリ・サーバ、管理サーバ、メッセージング・サーバ、統計サーバ、ネットワーク・インフラ・オペレータ（例、ＩＳＰ）のデバイス等の他のデバイスを含むことがある。
【００６８】
図４は、コーデック適用フレーム・サイズに従ってメディア・コンテンツの音声を符号化して、このメディア・コンテンツの固定時間映像部分を有するコンテンツ・ファイル間で隙間のない音声フレームをスプリットする方法４００の一実施形態の流れ図である。方法４００は、ハードウェア（回路、専用論理回路等）、（汎用コンピュータ・システムまたは専用マシン上で実行されるような）ソフトウェア、または、ファームウェア（例、組込みソフトウェア）を含むことのある、あるいは、これらの要素の任意の組合せを含むことのある処理ロジック（processing logic）により実行される。一実施形態では、方法４００は、図２および３Ａのエンコーダ２２０により実行される。他の実施形態では、これら方法のオペレーションのいくつかが、図２の固定フレーム音声エンコーダ２２４および音声スプリッティング・マルチプレクサ２２８により実行されることもある。
【００６９】
図４では、処理ロジックが、サンプル・オフセットを０に初期化することにより開始され（ブロック４０２）、メディア・コンテンツの音声の生部分を受け取る（ブロック４０４）。処理ロジックは、固定フレーム音声コーデックを使用することにより、音声の生部分を符号化し（ブロック４０６）、音声コーデックにより出力される符号化済音声フレームをバッファリングする（ブロック４０８）。処理ロジックは、ストリームレットを満たすのに十分な音声フレームが存在するかどうかを判定する（ブロック４１０）。この実施形態では、本明細書で説明するように、各ストリームレットが、期間の固定された映像フレームも含む。ストリームレットを満たすのに十分な音声フレームが存在しない場合、処理ロジックは、ブロック４０４に戻り、音声の次の生部分を受け取り、この音声の生部分を符号化し、ブロック４０８においてこれらをバッファリングする。処理ロジックは、ブロック４１０において、ストリームレットを満たすのに十分な音声フレームがあると判断した場合、音声フレームを音声スプリッティング・マルチプレクサに送り、バッファから送信フレームを除去する（ブロック４１２）。処理ロジックは、サンプル・オフセットをアップデートし（ブロック４１４）、メディア・コンテンツが終了かどうかを判定する（ブロック４１６）。ブロック４１６においてメディア・コンテンツが終了でなければ、処理ロジックは、ブロック４０４に戻って、音声の他の生部分を受け取る。そうでなければ、本方法は終了する。
【００７０】
図２について上で説明したように、処理ロジックは、エンコーダ２２０のコンポーネントの様々なオペレーションを実行するように構成することができる。たとえば、方法４００は、固定フレーム音声エンコーダ２２４により実行されることもあるが、固定フレーム音声エンコーダ２２４は、スプリッタ２２２から生音声２３３を受け取り、音声フレームを符号化し、符号化済音声フレーム２３７を音声フレーム・バッファ２２５内に格納する。この実施形態では、ブロック４０２〜４０８のオペレーションは、固定フレーム音声エンコーダ２２４が実行することができ、ブロック４１０〜４１６のオペレーションは、音声スプリッティング・マルチプレクサ２２８が実行することができる。あるいは、こうしたオペレーションは、エンコーダ２２０のコンポーネントの他の組合せにより実行することもできる。
【００７１】
図５Ａ〜５Ｃは、固定時間映像部分とコーデック適用フレーム・サイズを有する隙間のない音声フレームとを伴うコンテンツ・ファイルの生成の一実施形態の流れ図である。方法５００、５５０、５７０は、ハードウェア（回路、専用論理回路等）、（汎用コンピュータ・システムまたは専用マシン上で実行されるような）ソフトウェア、または、ファームウェア（例、組込みソフトウェア）を含むことのある、あるいは、これらの要素の任意の組合せを含むことのある処理ロジックにより実行される。一実施形態では、方法５００、５５０、５７０は、図２および３Ａのエンコーダ２２０により実行される。他の実施形態では、方法５００が、固定フレーム音声エンコーダ２２４に実行され、方法５５０が、固定時間映像エンコーダ２２６に実行され、方法５７０が、音声スプリッティング・マルチプレクサ２２８に実行される。あるいは、方法５００、５５０、５７０のオペレーションは、エンコーダ２２０のコンポーネントの他の組合せにより実行することもできる。
【００７２】
図５Ａでは、方法５００の処理ロジックが、音声の生部分を受け取ることにより開始される（ブロック５０２）。処理ロジックは、コーデック適用フレーム・サイズに従って、音声の生部分を符号化し（ブロック５０４）、符号化済音声フレームをバッファリングする（ブロック５０６）。処理ロジックは、メディア・コンテンツが終了かどうかを判定する（ブロック５０８）。ブロック５０８においてメディア・コンテンツが終了でなければ、処理ロジックは、ブロック５０２に戻って、音声の他の生部分を受け取る。そうでなければ、本方法は終了する。
【００７３】
図５Ｂでは、方法５５０の処理ロジックが、映像の生部分を受け取ることにより開始される（ブロック５５２）。処理ロジックは、フレーム・レートに従って、映像の生部分を符号化し（ブロック５５４）、符号化済映像フレームをバッファリングする（ブロック５５６）。処理ロジックは、メディア・コンテンツが終了かどうかを判定する（ブロック５５８）。ブロック５５８においてメディア・コンテンツが終了でなければ、処理ロジックは、ブロック５５２に戻って、映像の他の生部分を受け取る。そうでなければ、本方法は終了する。
【００７４】
図５Ｃでは、方法５７０の処理ロジックが、符号化済音声フレームをバッファから受け取り（ブロック５７２）、映像フレームをバッファから受け取ることにより開始される（ブロック５７４）。処理ロジックは、ストリームレットを生成し（ブロック５７６）、それをオリジン・コンテンツ・サーバに送る（ブロック５７８）。処理ロジックは、メディア・コンテンツが終了かどうかを判定する（ブロック５８０）。ブロック５８０においてメディア・コンテンツが終了でなければ、処理ロジックは、ブロック５７２に戻る。そうでなければ、本方法は終了する。
【００７５】
一実施形態では、処理ロジックは、ブロック５７６で、ストリームレットを満たすのに必要な映像フレームの数、および、ストリームレットを満たすのに必要な音声フレームの数を求める。一実施形態では、ストリームレット毎の映像フレームの数は、固定時間幅に従っておおよそ固定される。たとえば、フレーム・レートが３０ｆｐｓの場合、２秒間のストリームレットに６０フレームが存在する。ただし、実際には、映像は常に正確に３０ｆｐｓというわけではなく、むしろ２９．９７ｆｐｓであることに留意されたい。よって、いくつかの２秒間ストリームレットは５９フレームを有することがあり、いくつかは６０フレーム有することがあり、いくつかは６１フレームの場合でさえある。ストリームレット内の各フレームは、ストリームレットの開始に対する提供時間を有する。よって、あるストリームレットが３０〜３２秒を表す場合、そのストリームレット内の初めのフレームは、０ｍｓではなく６ｍｓの提供時間を有することがある。このフレームは、ストリームの開始から３０００６ｍｓで表示されるはずである。ライブの場合、計算リソースが限られ、エンコーダがライブの流れについていけない場合、エンコーダは、キャッチアップするためにフレームを落とすことがある。したがって、いくつかのストリームレットは映像内に隙間を有することがあり、これが、ストリームレット毎のフレーム数のばらつきのもう１つの原因となる場合がある。あるいは、２４ｆｐｓ等、３０ｆｐｓ以外の他のフレーム・レートを使用することもできる。ストリームレット毎の音声フレームの数は固定されない。音声フレームの数は、音声スプリッティング・マルチプレクサ２２８について先に説明したオペレーションで求まる。処理ロジックは、現在のストリームレットを満たすのに十分な隙間のないフレームがバッファ内に格納されているかどうかを判定する。音声フレームが十分にない場合、処理ロジックは、音声の次の部分、たとえば、本明細書で説明するように、音声の隙間のないフレーム１つを次の部分から受け取り、符号化する。いくつかのケースでは、ストリームレット内の音声フレームの期間が、固定時間幅よりも大きいことがあり、他のケースでは、音声フレームの期間が、固定時間幅よりも小さいことがある。
【００７６】
図７は、一実施形態による音声スプリッティング用のコンピュータ・システム７００の例示的形態のマシンの図である。コンピュータ・システム７００内で、本明細書で議論する音声スプリッティング方法論のうちの１つまたは複数のいずれかをマシンに行わせる命令の組を実行することができる。代替実施形態では、ＬＡＮ、イントラネット、エクストラネット、またはインターネット内でマシンを他のマシンに接続（例、ネットワーク化）することができる。このマシンは、クライアント-サーバ・ネットワーク環境内でサーバまたはクライアント・マシンの能力内で動作することも、ピア・ツー・ピア（分散型）・ネットワーク環境内でピア・マシンとして動作することもできる。このマシンは、ＰＣ、タブレットＰＣ、ＳＴＢ、ＰＤＡ、携帯電話、ウェブ・アプライアンス、サーバ、ネットワーク・ルータ、スイッチまたはブリッジ、あるいは、マシンがとるべきアクションを指定する（連続した、またはそれ以外の）命令の組を実行することの可能な任意のマシンとすることができる。さらに、単一のマシンのみ図示しているが、音声スプリッティングのオペレーションについて本明細書に記載する上記の方法４００、５００、５５０、５７０等の本明細書で議論する方法論のうちの１つまたは複数のいずれかを行うために、個別にまたは共同して１組の（または複数組の）命令を実行する複数のマシンの任意の集合も、用語「マシン」に含まれるものとする。一実施形態では、コンピュータ・システム７００は、上で説明したようにエンコーダ２２０または符号化システム３２０に実装することのできる様々なコンポーネントを表す。あるいは、エンコーダ２２０または符号化システム３２０が、コンピュータ・システム７００内に図示しているものより多くのコンポーネント、またはこれより少ないコンポーネントを含むこともある。
【００７７】
この例示的コンピュータ・システム７００は、処理デバイス７０２、メイン・メモリ７０４（例、ＲＯＭ（リードオンリ・メモリ）、フラッシュ・メモリ、ＳＤＲＡＭ（シンクロナスＤＲＡＭ）やＤＲＡＭ（ＲＤＲＡＭ）等のＤＲＡＭ（ダイナミック・ランダム・アクセス・メモリ）等）、スタティック・メモリ７０６（例、フラッシュ・メモリ、ＳＲＡＭ（スタティック・ランダム・アクセス・メモリ）等）、データ記憶デバイス７１６を含み、これら要素は、それぞれバス７３０を介して互いに通信を行っている。
【００７８】
処理デバイス７０２は、マイクロプロセッサや中央処理ユニット等の１つまたは複数の汎用処理デバイスを表す。より具体的には、処理デバイス７０２は、ＣＩＳＣ（複合命令セット・コンピューティング）マイクロプロセッサ、ＲＩＳＣ（縮小命令セット・コンピューティング）マイクロプロセッサ、ＶＬＩＷ（超長命令語）マイクロプロセッサ、または、他の命令の組を実装するプロセッサもしくは命令の組の組合せを実装するプロセッサでもよい。処理デバイス７０２は、ＡＳＩＣ（特定用途向け集積回路）、ＦＰＧＡ（フィールド・プログラマブル・ゲート・アレイ）、ＤＳＰ（デジタル信号プロセッサ）、ネットワーク・プロセッサ等の１つまたは複数の特別用途処理デバイスであってもよい。処理デバイス７０２は、本明細書で議論するオペレーションおよびステップを実施するための処理ロジック（例、音声スプリッティング７２６）を実行するように構成される。
【００７９】
コンピュータ・システム７００は、ネットワーク・インタフェース・デバイス７２２を更に含むこともある。コンピュータ・システム７００は、映像表示ユニット７１０（例、液晶ディスプレイ（ＬＣＤ）または陰極線管（ＣＲＴ））、アルファニューメリック入力デバイス７１２（例、キーボード）、カーソル制御デバイス７１４（例、マウス）、信号生成デバイス７２０（例、スピーカ）を含むこともある。
【００８０】
データ記憶デバイス７１６は、本明細書に記載する方法論または機能のうちの１つまたは複数を実現する１組または複数の組の命令（例、音声スプリッティング７２６）が記憶されるコンピュータ可読記憶媒体７２４を含むことがある。音声スプリッティング７２６は、コンピュータ・システム７００による実行中、メイン・メモリ７０４および／または処理デバイス７０２内に完全にまたは少なくとも部分的に含まれるように存在することがあるが、これらメイン・メモリ７０４および処理デバイス７０２もまた、コンピュータ可読記憶媒体を構成する。さらに、ネットワーク・インタフェース・デバイス７２２により、音声スプリッティング７２６を、ネットワークを介して送ることまたは受け取ることができる。
【００８１】
一例示的実施形態では、コンピュータ可読記憶媒体７２４を単一の媒体として図示しているが、用語「コンピュータ可読媒体」には、１組または複数組の命令を記憶する単一または複数の媒体（例、集中もしくは分散データベース、ならびに／または関連キャッシュおよびサーバ）も含まれることがあるとみなされたい。また、用語「コンピュータ可読記憶媒体」には、マシンによる実行用の命令の組を記憶することが可能で、本実施形態の方法論のうちの１つまたは複数をマシンに実行させる任意の媒体も含まれるものとする。したがって、用語「コンピュータ可読記憶媒体」には、ソリッド・ステート・メモリ、光学式媒体、磁気媒体、または、命令を記憶するための他の種類の媒体が含まれることとするが、これらに限定されない。用語「コンピュータ可読伝送媒体」には、マシンによる実行用の命令の組を送信して、本実施形態の方法論のうちの１つまたは複数をマシンに行わせることの可能な任意の媒体が含まれるものとする。
【００８２】
音声スプリッティング・モジュール７３２、それぞれのコンポーネント、および（たとえば、図２および３Ａに関連して）本明細書に記載する他の特徴を、分離したハードウェア・コンポーネントとして実現すること、または、ＡＳＩＣＳ、ＦＰＧＡ、ＤＳＰ、これらと同様のデバイス等のハードウェア・コンポーネントの機能内に集積化することができる。さらに、音声スプリッティング・モジュール７３２は、ハードウェア・デバイス内のファームウェアまたは機能回路として実現することもできる。さらに、音声スプリッティング・モジュール７３２は、任意の組合せハードウェア・デバイスおよびソフトウェア・コンポーネント内で実現することもできる。
【００８３】
説明目的で、上記の記載を特定の実施形態に関連して提供してきた。しかし、上記の例示的議論は、網羅的になることを意図しておらず、開示した厳密な形態に本発明を限定することを意図していない。上記の教示内容に鑑みて、多くの修正形態および変形形態が考えられる。本発明の原理およびその実用的応用例を最もうまく説明するために、上記の実施形態を選択し説明したが、これにより、当業者が本発明と様々な修正形態を伴う様々な実施形態とを、企図される特定の用途に適した形で利用することが可能になる。
【特許請求の範囲】
【請求項１】
オペレーションを実行するようにプログラムされたコンピューティング・システムに実行される方法であって、
音声および映像を含むメディア・コンテンツを受け取ることと、
前記映像をフレーム・レートに従って符号化することと、
前記音声を、コーデック適用フレーム・サイズに従って符号化することと、
複数のコンテンツ・ファイルを生成することであって、前記複数のコンテンツ・ファイルのそれぞれが、前記映像のうちで固定時間幅を有する符号化済部分と、前記音声のうちで、前記コーデック適用フレーム・サイズを有する複数の隙間のない音声フレームを有する符号化済部分とを含むことと、
を含む方法。
【請求項２】
前記複数の音声フレームの最後が、０で埋められることがない、
請求項１に記載の方法。
【請求項３】
前記メディア・コンテンツを前記音声および前記映像にスプリットすることを更に含み、
前記映像を符号化することが、前記固定時間幅に従って映像コーデックを使用することにより前記映像を符号化することを含み、
前記音声を符号化することが、前記コーデック適用フレーム・サイズに従って音声コーデックを使用することにより前記音声を符号化することを含む、
請求項１に記載の方法。
【請求項４】
前記音声の符号化済フレームをバッファリングすることと、
前記複数のコンテンツ・ファイルのうちの現在のコンテンツ・ファイルを満たすのに必要な符号化済フレーム数を求めることであって、前記フレーム数が、前記複数のファイルのうち前記現在のファイルを満たすのに必要なサンプル数を、前記コーデック適用フレーム・サイズで割った数以上の最小の整数であることと、
前記複数のコンテンツ・ファイルのうちの現在のコンテンツ・ファイルを満たすのに十分な前記符号化済フレームがバッファリングされたかどうかを判定することと、
前記符号化済フレームが十分にバッファリングされている場合、前記複数のコンテンツ・ファイルのうちの前記現在のコンテンツ・ファイルを前記フレーム数のフレームで満たすことと、
前記符号化済フレームが十分にバッファリングされていない場合、前記音声の追加のフレームをバッファリングし、前記複数のコンテンツ・ファイルのうちの前記現在のコンテンツ・ファイルを、前記フレーム数のフレームおよび前記追加のフレームで満たすことと、
を更に含む請求項１に記載の方法。
【請求項５】
十分な符号化済フレームがバッファリングされたかどうかを前記判定することが、
バッファリングされたフレームの数と、前記コーデック適用フレーム・サイズとを乗算することと、
前記複数のコンテンツ・ファイルのうちの前のコンテンツ・ファイルからのサンプル・オフセットがあればこれを、前記乗算の積に加えることと、
その和が、前記複数のコンテンツ・ファイルのうちの第１のコンテンツ・ファイルを満たすのに必要なサンプルの数以上であるかどうかを判定することと、
を含む
請求項４に記載の方法。
【請求項６】
前記複数のコンテンツ・ファイルのうちの次のコンテンツ・ファイルについてサンプル・オフセットがあればこれを求めることを更に含む、
請求項４に記載の方法。
【請求項７】
前記サンプル・オフセットを求めることが、
前記符号化済フレームの数に前記コーデック適用フレーム・サイズを掛け、ここから、前記複数のコンテンツ・ファイルのうちの第１のコンテンツ・ファイルを満たすのに必要なサンプルの数を引き、前記複数のコンテンツ・ファイルのうちの前のコンテンツ・ファイルからの前記サンプル・オフセットがあればこれを足すことを含む、
請求項６に記載の方法。
【請求項８】
前記音声の符号化済フレームをバッファリングすることを更に含み、
前記複数のコンテンツ・ファイルを前記生成することが、
前記複数のコンテンツ・ファイルのうちの現在のコンテンツ・ファイルを満たすのに必要なサンプルの数を算出することと、
前記複数のコンテンツ・ファイルのうちの前記現在のコンテンツ・ファイルに必要なフレームの数を算出することと、
前記サンプルの数が前記コーデック適用フレーム・サイズで均等に割り切れない場合、前記フレーム数のフレームにフレームを追加することと、
前記複数のコンテンツ・ファイルのうちの前記現在のコンテンツ・ファイルを前記フレーム数のフレームで満たすことと、
を含む、
請求項１に記載の方法。
【請求項９】
前記音声の符号化済フレームをバッファリングすることを更に含み、
前記複数のコンテンツ・ファイルを前記生成することが、
前記固定時間幅をサンプリング・レートに掛け、これに、前記複数のコンテンツ・ファイルのうちの前のコンテンツ・ファイルからのサンプル・オフセットがあればこれを足すことにより、前記複数のコンテンツ・ファイルのうちの現在のコンテンツ・ファイルを満たすのに必要なサンプルの数を算出することと、
前記サンプルの数を、前記コーデック適用フレーム・サイズで割ることにより、前記複数のコンテンツ・ファイルのうちの前記現在のコンテンツ・ファイルを満たすのに必要なフレームの数を算出することと、
前記除算の余りが０の場合、前記複数のコンテンツ・ファイルのうちの前記現在のコンテンツ・ファイルを前記フレーム数のフレームで満たすことと、
前記除算の余りが０より大きい場合、前記フレーム数を１だけインクリメントし、前記インクリメントしたフレーム数のフレームで前記複数のコンテンツ・ファイルのうちの前記現在のコンテンツ・ファイルを満たすことと
を含む、
請求項１に記載の方法。
【請求項１０】
前記複数のコンテンツ・ファイルを前記生成することが、
前記複数のコンテンツ・ファイルのうちの前記現在のコンテンツ・ファイルを満たすのに必要な前記サンプルの数に戻すために、前記フレームの数と、前記コーデック適用フレーム・サイズとを掛けることと、
前記サンプルの数を前記サンプリング・レートで割ることにより、前記複数のコンテンツ・ファイルのうちの前記現在のコンテンツ・ファイルの前記音声の期間を算出することと、
前記固定時間幅から前記期間を引くことにより、前記複数のコンテンツ・ファイルのうちの次のコンテンツ・ファイルについてのプレゼンテーション・オフセットを求めることと、
前記フレームの数に前記コーデック適用フレーム・サイズを掛け、ここから、前記複数のコンテンツ・ファイルのうちの前記第１のコンテンツ・ファイルを満たすのに必要な前記サンプルの数を引き、前記複数のコンテンツ・ファイルのうちの前のコンテンツ・ファイルからの前記サンプル・オフセットがあればこれを足すことにより、前記複数のコンテンツ・ファイルのうちの前記次のコンテンツ・ファイルについての前記サンプル・オフセットをアップデートすることと
を更に含む、
請求項９に記載の方法。
【請求項１１】
前記受け取ることが、前記メディア・コンテンツを複数の生のストリームレットとして受け取ることを含み、
前記複数の生のストリームレットのそれぞれが、前記メディア・コンテンツのうちで前記固定時間幅を有する部分を含む、
請求項１に記載の方法。
【請求項１２】
前記メディア・コンテンツを前記受け取ることが、
前記複数の生のストリームレットのうちの第１の生のストリームレットおよび前記複数の生のストリームレットのうちの第２の生のストリームレットを受け取ることと、
前記第１の生のストリームレットの前記音声および前記映像をスプリットし、前記第２の生のストリームレットの前記音声および前記映像をスプリットすることと、
を含み、
前記映像を前記符号化することが、
前記第１の生のストリームレットの前記映像を符号化することであって、前記第１の生のストリームレットの前記映像が、前記複数のコンテンツ・ファイルのうちの第１のコンテンツ・ファイル内に格納されることと、
前記第２の生のストリームレットの前記映像を符号化することであって、前記第２の生のストリームレットの前記映像が、前記複数のコンテンツ・ファイルのうちの第２のコンテンツ・ファイル内に格納されることと、
を含み、
前記音声を前記符号化することが、
前記第１の生のストリームレットの前記音声を、第１の複数の音声フレームに符号化することと、
前記第１の複数の音声フレームをバッファリングすることと、
前記第１のコンテンツ・ファイルを満たすのに十分なフレームがバッファリングされたかどうかを判定することと、
前記第１のコンテンツ・ファイルを満たすのに十分なフレームがバッファリングされていない場合、前記第２の生のストリームレットの前記音声を、第２の複数の音声フレームに符号化し、前記第２の複数の音声フレームをバッファリングすることと、
前記第１のコンテンツ・ファイルを満たすのに十分なフレームがバッファリングされている場合、前記バッファリングされた音声フレームを前記第１のコンテンツ・ファイル内に格納することと、
を含む、
請求項１１に記載の方法。
【請求項１３】
前記固定時間幅が約２秒間であり、
前記音声が、１秒間に約４８０００サンプルでサンプリングされ、
前記コーデック適用フレーム・サイズが、１フレームにつき１０２４サンプルであり、
前記複数のコンテンツ・ファイルのうちの初めの３つのコンテンツ・ファイルの音声部分がそれぞれ、９４の音声フレームを含み、
前記複数のコンテンツ・ファイルのうちの第４のコンテンツ・ファイルの音声部分が、９３の音声フレームを含み、
前記第４のコンテンツ・ファイルの映像部分がそれぞれ、約６０の映像フレームを含む、
請求項１に記載の方法。
【請求項１４】
前記固定時間幅が約２秒間であり、
前記音声が、１秒間に約４４１００サンプルでサンプリングされ、
前記コーデック適用フレーム・サイズが、１フレームにつき１０２４サンプルであり、
前記複数のコンテンツ・ファイルのうちの第１のコンテンツ・ファイルの音声部分が、８７の音声フレームを含み、前記複数のコンテンツ・ファイルのうちの第２のコンテンツ・ファイルが、８６の音声フレームを含む、
請求項１に記載の方法。
【請求項１５】
前記コーデック適用フレーム・サイズが、１フレームにつき２０４８サンプルである、
請求項１に記載の方法。
【請求項１６】
映像および音声を含むメディア・コンテンツを受け取る手段と、
前記映像をフレーム・レートに従って符号化する手段と、
前記音声を固定フレーム・サイズに従って符号化する手段と、
前記映像を複数の部分にセグメント化する手段であって、前記映像の各部分が、別々のコンテンツ・ファイル内に格納される手段と、
境界アーチファクトを導入することなく、前記音声を前記別々のコンテンツ・ファイルにスプリットする手段と、
を備える装置。
【請求項１７】
前記コンテンツ・ファイルのそれぞれについて、サンプル・オフセットがあればこれを記録する手段と、
前記コンテンツ・ファイルのそれぞれについて、プレゼンテーション・オフセットがあればこれを記録する手段と、
を更に備える請求項１６に記載の装置。
【請求項１８】
音声および映像を含むメディア・コンテンツを受け取り、前記音声および前記映像をスプリットするためのスプリッタと、
前記スプリッタから前記映像を受け取るように結合され、前記映像をフレーム・レートに従って符号化するための映像エンコーダと、
前記スプリッタから前記音声を受け取るように結合され、前記音声を、コーデック適用フレーム・サイズに従って符号化するための音声エンコーダと、
複数のコンテンツ・ファイルを生成するための音声スプリッティング・マルチプレクサであって、前記複数のコンテンツ・ファイルのそれぞれが、前記映像のうちで固定時間幅を有する符号化済部分と、前記音声のうちで、前記コーデック適用フレーム・サイズを有する複数の隙間のない音声フレームを有する符号化済部分とを含む、音声スプリッティング・マルチプレクサと、
を含むコンピューティング・デバイス
を備える装置。
【請求項１９】
前記複数の音声フレームの最後が、０で埋められることがない、
請求項１８に記載の装置。
【請求項２０】
前記コンピューティング・デバイスが、前記音声の符号化済フレームをバッファリングするための音声フレーム・バッファを更に備える、
請求項１８に記載の装置。
【請求項２１】
コンピューティング・デバイスに実行されると前記コンピューティング・デバイスにある方法を行わせる命令を格納するコンピュータ可読記憶媒体であって、
前記方法が、
音声および映像を含むメディア・コンテンツを受け取ることと、
前記映像をフレーム・レートに従って符号化することと、
前記音声を、コーデック適用フレーム・サイズに従って符号化することと、
複数のコンテンツ・ファイルを生成することであって、前記複数のコンテンツ・ファイルのそれぞれが、前記映像のうちで固定時間幅を有する符号化済部分と、前記音声のうちで、前記コーデック適用フレーム・サイズを有する複数の隙間のない音声フレームを有する符号化済部分とを含むことと、
を含む、
コンピュータ可読記憶媒体。
【請求項２２】
前記方法が、
前記音声の符号化済フレームをバッファリングすることと、
前記複数のコンテンツ・ファイルのうちの現在のコンテンツ・ファイルを満たすのに必要な符号化済フレーム数を求めることであって、前記フレーム数が、前記複数のファイルのうちの前記現在のファイルを満たすのに必要なサンプル数を、前記コーデック適用フレーム・サイズで割った数以上の最小の整数であることと、
前記複数のコンテンツ・ファイルのうちの現在のコンテンツ・ファイルを満たすのに十分な前記符号化済フレームがバッファリングされたかどうかを判定することと、
前記符号化済フレームが十分にバッファリングされている場合、前記複数のコンテンツ・ファイルのうちの前記現在のコンテンツ・ファイルを前記フレーム数のフレームで満たすことと、
前記符号化済フレームが十分にバッファリングされていない場合、前記音声の追加のフレームをバッファリングし、前記複数のコンテンツ・ファイルのうちの前記現在のコンテンツ・ファイルを、前記フレーム数のフレームおよび前記追加のフレームで満たすことと、
を更に含む、
請求項２１に記載のコンピュータ可読記憶媒体。
【請求項１】
オペレーションを実行するようにプログラムされたコンピューティング・システムに実行される方法であって、
音声および映像を含むメディア・コンテンツを受け取ることと、
前記映像をフレーム・レートに従って符号化することと、
前記音声を、コーデック適用フレーム・サイズに従って符号化することと、
複数のコンテンツ・ファイルを生成することであって、前記複数のコンテンツ・ファイルのそれぞれが、前記映像のうちで固定時間幅を有する符号化済部分と、前記音声のうちで、前記コーデック適用フレーム・サイズを有する複数の隙間のない音声フレームを有する符号化済部分とを含むことと、
を含む方法。
【請求項２】
前記複数の音声フレームの最後が、０で埋められることがない、
請求項１に記載の方法。
【請求項３】
前記メディア・コンテンツを前記音声および前記映像にスプリットすることを更に含み、
前記映像を符号化することが、前記固定時間幅に従って映像コーデックを使用することにより前記映像を符号化することを含み、
前記音声を符号化することが、前記コーデック適用フレーム・サイズに従って音声コーデックを使用することにより前記音声を符号化することを含む、
請求項１に記載の方法。
【請求項４】
前記音声の符号化済フレームをバッファリングすることと、
前記複数のコンテンツ・ファイルのうちの現在のコンテンツ・ファイルを満たすのに必要な符号化済フレーム数を求めることであって、前記フレーム数が、前記複数のファイルのうち前記現在のファイルを満たすのに必要なサンプル数を、前記コーデック適用フレーム・サイズで割った数以上の最小の整数であることと、
前記複数のコンテンツ・ファイルのうちの現在のコンテンツ・ファイルを満たすのに十分な前記符号化済フレームがバッファリングされたかどうかを判定することと、
前記符号化済フレームが十分にバッファリングされている場合、前記複数のコンテンツ・ファイルのうちの前記現在のコンテンツ・ファイルを前記フレーム数のフレームで満たすことと、
前記符号化済フレームが十分にバッファリングされていない場合、前記音声の追加のフレームをバッファリングし、前記複数のコンテンツ・ファイルのうちの前記現在のコンテンツ・ファイルを、前記フレーム数のフレームおよび前記追加のフレームで満たすことと、
を更に含む請求項１に記載の方法。
【請求項５】
十分な符号化済フレームがバッファリングされたかどうかを前記判定することが、
バッファリングされたフレームの数と、前記コーデック適用フレーム・サイズとを乗算することと、
前記複数のコンテンツ・ファイルのうちの前のコンテンツ・ファイルからのサンプル・オフセットがあればこれを、前記乗算の積に加えることと、
その和が、前記複数のコンテンツ・ファイルのうちの第１のコンテンツ・ファイルを満たすのに必要なサンプルの数以上であるかどうかを判定することと、
を含む
請求項４に記載の方法。
【請求項６】
前記複数のコンテンツ・ファイルのうちの次のコンテンツ・ファイルについてサンプル・オフセットがあればこれを求めることを更に含む、
請求項４に記載の方法。
【請求項７】
前記サンプル・オフセットを求めることが、
前記符号化済フレームの数に前記コーデック適用フレーム・サイズを掛け、ここから、前記複数のコンテンツ・ファイルのうちの第１のコンテンツ・ファイルを満たすのに必要なサンプルの数を引き、前記複数のコンテンツ・ファイルのうちの前のコンテンツ・ファイルからの前記サンプル・オフセットがあればこれを足すことを含む、
請求項６に記載の方法。
【請求項８】
前記音声の符号化済フレームをバッファリングすることを更に含み、
前記複数のコンテンツ・ファイルを前記生成することが、
前記複数のコンテンツ・ファイルのうちの現在のコンテンツ・ファイルを満たすのに必要なサンプルの数を算出することと、
前記複数のコンテンツ・ファイルのうちの前記現在のコンテンツ・ファイルに必要なフレームの数を算出することと、
前記サンプルの数が前記コーデック適用フレーム・サイズで均等に割り切れない場合、前記フレーム数のフレームにフレームを追加することと、
前記複数のコンテンツ・ファイルのうちの前記現在のコンテンツ・ファイルを前記フレーム数のフレームで満たすことと、
を含む、
請求項１に記載の方法。
【請求項９】
前記音声の符号化済フレームをバッファリングすることを更に含み、
前記複数のコンテンツ・ファイルを前記生成することが、
前記固定時間幅をサンプリング・レートに掛け、これに、前記複数のコンテンツ・ファイルのうちの前のコンテンツ・ファイルからのサンプル・オフセットがあればこれを足すことにより、前記複数のコンテンツ・ファイルのうちの現在のコンテンツ・ファイルを満たすのに必要なサンプルの数を算出することと、
前記サンプルの数を、前記コーデック適用フレーム・サイズで割ることにより、前記複数のコンテンツ・ファイルのうちの前記現在のコンテンツ・ファイルを満たすのに必要なフレームの数を算出することと、
前記除算の余りが０の場合、前記複数のコンテンツ・ファイルのうちの前記現在のコンテンツ・ファイルを前記フレーム数のフレームで満たすことと、
前記除算の余りが０より大きい場合、前記フレーム数を１だけインクリメントし、前記インクリメントしたフレーム数のフレームで前記複数のコンテンツ・ファイルのうちの前記現在のコンテンツ・ファイルを満たすことと
を含む、
請求項１に記載の方法。
【請求項１０】
前記複数のコンテンツ・ファイルを前記生成することが、
前記複数のコンテンツ・ファイルのうちの前記現在のコンテンツ・ファイルを満たすのに必要な前記サンプルの数に戻すために、前記フレームの数と、前記コーデック適用フレーム・サイズとを掛けることと、
前記サンプルの数を前記サンプリング・レートで割ることにより、前記複数のコンテンツ・ファイルのうちの前記現在のコンテンツ・ファイルの前記音声の期間を算出することと、
前記固定時間幅から前記期間を引くことにより、前記複数のコンテンツ・ファイルのうちの次のコンテンツ・ファイルについてのプレゼンテーション・オフセットを求めることと、
前記フレームの数に前記コーデック適用フレーム・サイズを掛け、ここから、前記複数のコンテンツ・ファイルのうちの前記第１のコンテンツ・ファイルを満たすのに必要な前記サンプルの数を引き、前記複数のコンテンツ・ファイルのうちの前のコンテンツ・ファイルからの前記サンプル・オフセットがあればこれを足すことにより、前記複数のコンテンツ・ファイルのうちの前記次のコンテンツ・ファイルについての前記サンプル・オフセットをアップデートすることと
を更に含む、
請求項９に記載の方法。
【請求項１１】
前記受け取ることが、前記メディア・コンテンツを複数の生のストリームレットとして受け取ることを含み、
前記複数の生のストリームレットのそれぞれが、前記メディア・コンテンツのうちで前記固定時間幅を有する部分を含む、
請求項１に記載の方法。
【請求項１２】
前記メディア・コンテンツを前記受け取ることが、
前記複数の生のストリームレットのうちの第１の生のストリームレットおよび前記複数の生のストリームレットのうちの第２の生のストリームレットを受け取ることと、
前記第１の生のストリームレットの前記音声および前記映像をスプリットし、前記第２の生のストリームレットの前記音声および前記映像をスプリットすることと、
を含み、
前記映像を前記符号化することが、
前記第１の生のストリームレットの前記映像を符号化することであって、前記第１の生のストリームレットの前記映像が、前記複数のコンテンツ・ファイルのうちの第１のコンテンツ・ファイル内に格納されることと、
前記第２の生のストリームレットの前記映像を符号化することであって、前記第２の生のストリームレットの前記映像が、前記複数のコンテンツ・ファイルのうちの第２のコンテンツ・ファイル内に格納されることと、
を含み、
前記音声を前記符号化することが、
前記第１の生のストリームレットの前記音声を、第１の複数の音声フレームに符号化することと、
前記第１の複数の音声フレームをバッファリングすることと、
前記第１のコンテンツ・ファイルを満たすのに十分なフレームがバッファリングされたかどうかを判定することと、
前記第１のコンテンツ・ファイルを満たすのに十分なフレームがバッファリングされていない場合、前記第２の生のストリームレットの前記音声を、第２の複数の音声フレームに符号化し、前記第２の複数の音声フレームをバッファリングすることと、
前記第１のコンテンツ・ファイルを満たすのに十分なフレームがバッファリングされている場合、前記バッファリングされた音声フレームを前記第１のコンテンツ・ファイル内に格納することと、
を含む、
請求項１１に記載の方法。
【請求項１３】
前記固定時間幅が約２秒間であり、
前記音声が、１秒間に約４８０００サンプルでサンプリングされ、
前記コーデック適用フレーム・サイズが、１フレームにつき１０２４サンプルであり、
前記複数のコンテンツ・ファイルのうちの初めの３つのコンテンツ・ファイルの音声部分がそれぞれ、９４の音声フレームを含み、
前記複数のコンテンツ・ファイルのうちの第４のコンテンツ・ファイルの音声部分が、９３の音声フレームを含み、
前記第４のコンテンツ・ファイルの映像部分がそれぞれ、約６０の映像フレームを含む、
請求項１に記載の方法。
【請求項１４】
前記固定時間幅が約２秒間であり、
前記音声が、１秒間に約４４１００サンプルでサンプリングされ、
前記コーデック適用フレーム・サイズが、１フレームにつき１０２４サンプルであり、
前記複数のコンテンツ・ファイルのうちの第１のコンテンツ・ファイルの音声部分が、８７の音声フレームを含み、前記複数のコンテンツ・ファイルのうちの第２のコンテンツ・ファイルが、８６の音声フレームを含む、
請求項１に記載の方法。
【請求項１５】
前記コーデック適用フレーム・サイズが、１フレームにつき２０４８サンプルである、
請求項１に記載の方法。
【請求項１６】
映像および音声を含むメディア・コンテンツを受け取る手段と、
前記映像をフレーム・レートに従って符号化する手段と、
前記音声を固定フレーム・サイズに従って符号化する手段と、
前記映像を複数の部分にセグメント化する手段であって、前記映像の各部分が、別々のコンテンツ・ファイル内に格納される手段と、
境界アーチファクトを導入することなく、前記音声を前記別々のコンテンツ・ファイルにスプリットする手段と、
を備える装置。
【請求項１７】
前記コンテンツ・ファイルのそれぞれについて、サンプル・オフセットがあればこれを記録する手段と、
前記コンテンツ・ファイルのそれぞれについて、プレゼンテーション・オフセットがあればこれを記録する手段と、
を更に備える請求項１６に記載の装置。
【請求項１８】
音声および映像を含むメディア・コンテンツを受け取り、前記音声および前記映像をスプリットするためのスプリッタと、
前記スプリッタから前記映像を受け取るように結合され、前記映像をフレーム・レートに従って符号化するための映像エンコーダと、
前記スプリッタから前記音声を受け取るように結合され、前記音声を、コーデック適用フレーム・サイズに従って符号化するための音声エンコーダと、
複数のコンテンツ・ファイルを生成するための音声スプリッティング・マルチプレクサであって、前記複数のコンテンツ・ファイルのそれぞれが、前記映像のうちで固定時間幅を有する符号化済部分と、前記音声のうちで、前記コーデック適用フレーム・サイズを有する複数の隙間のない音声フレームを有する符号化済部分とを含む、音声スプリッティング・マルチプレクサと、
を含むコンピューティング・デバイス
を備える装置。
【請求項１９】
前記複数の音声フレームの最後が、０で埋められることがない、
請求項１８に記載の装置。
【請求項２０】
前記コンピューティング・デバイスが、前記音声の符号化済フレームをバッファリングするための音声フレーム・バッファを更に備える、
請求項１８に記載の装置。
【請求項２１】
コンピューティング・デバイスに実行されると前記コンピューティング・デバイスにある方法を行わせる命令を格納するコンピュータ可読記憶媒体であって、
前記方法が、
音声および映像を含むメディア・コンテンツを受け取ることと、
前記映像をフレーム・レートに従って符号化することと、
前記音声を、コーデック適用フレーム・サイズに従って符号化することと、
複数のコンテンツ・ファイルを生成することであって、前記複数のコンテンツ・ファイルのそれぞれが、前記映像のうちで固定時間幅を有する符号化済部分と、前記音声のうちで、前記コーデック適用フレーム・サイズを有する複数の隙間のない音声フレームを有する符号化済部分とを含むことと、
を含む、
コンピュータ可読記憶媒体。
【請求項２２】
前記方法が、
前記音声の符号化済フレームをバッファリングすることと、
前記複数のコンテンツ・ファイルのうちの現在のコンテンツ・ファイルを満たすのに必要な符号化済フレーム数を求めることであって、前記フレーム数が、前記複数のファイルのうちの前記現在のファイルを満たすのに必要なサンプル数を、前記コーデック適用フレーム・サイズで割った数以上の最小の整数であることと、
前記複数のコンテンツ・ファイルのうちの現在のコンテンツ・ファイルを満たすのに十分な前記符号化済フレームがバッファリングされたかどうかを判定することと、
前記符号化済フレームが十分にバッファリングされている場合、前記複数のコンテンツ・ファイルのうちの前記現在のコンテンツ・ファイルを前記フレーム数のフレームで満たすことと、
前記符号化済フレームが十分にバッファリングされていない場合、前記音声の追加のフレームをバッファリングし、前記複数のコンテンツ・ファイルのうちの前記現在のコンテンツ・ファイルを、前記フレーム数のフレームおよび前記追加のフレームで満たすことと、
を更に含む、
請求項２１に記載のコンピュータ可読記憶媒体。
【図１】
【図２】
【図３Ａ】
【図３Ｂ】
【図４】
【図５Ａ】
【図５Ｂ】
【図５Ｃ】
【図６Ａ】
【図６Ｂ】
【図７】
【図２】
【図３Ａ】
【図３Ｂ】
【図４】
【図５Ａ】
【図５Ｂ】
【図５Ｃ】
【図６Ａ】
【図６Ｂ】
【図７】
【公表番号】特表２０１３−５１５４０１（Ｐ２０１３−５１５４０１Ａ）
【公表日】平成２５年５月２日（２０１３．５．２）
【国際特許分類】
【出願番号】特願２０１２−５４４９５８（Ｐ２０１２−５４４９５８）
【出願日】平成２２年１２月２１日（２０１０．１２．２１）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０６１６５８
【国際公開番号】ＷＯ２０１１／０８４８２３
【国際公開日】平成２３年７月１４日（２０１１．７．１４）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．フロッピー
２．ＥＥＰＲＯＭ
【出願人】（５１１０６６５４０）エコスター アドバンスト テクノロジーズ エル．エル．シー． (1)
【氏名又は名称原語表記】ＥｃｈｏＳｔａｒ Ａｄｖａｎｃｅｄ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｌ．Ｌ．Ｃ．
【住所又は居所原語表記】１００ Ｉｎｖｅｒｎｅｓｓ Ｔｅｒｒａｃｅ Ｅａｓｔ，Ｅｎｇｌｅｗｏｏｄ，Ｃｏｌｏｒａｄｏ ８０１１２，Ｕｎｉｔｅｄ Ｓｔａｔｅｓ ｏｆ Ａｍｅｒｉｃａ
【Ｆターム（参考）】
【公表日】平成２５年５月２日（２０１３．５．２）
【国際特許分類】
【出願日】平成２２年１２月２１日（２０１０．１２．２１）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０６１６５８
【国際公開番号】ＷＯ２０１１／０８４８２３
【国際公開日】平成２３年７月１４日（２０１１．７．１４）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．フロッピー
２．ＥＥＰＲＯＭ
【出願人】（５１１０６６５４０）エコスター アドバンスト テクノロジーズ エル．エル．シー． (1)
【氏名又は名称原語表記】ＥｃｈｏＳｔａｒ Ａｄｖａｎｃｅｄ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｌ．Ｌ．Ｃ．
【住所又は居所原語表記】１００ Ｉｎｖｅｒｎｅｓｓ Ｔｅｒｒａｃｅ Ｅａｓｔ，Ｅｎｇｌｅｗｏｏｄ，Ｃｏｌｏｒａｄｏ ８０１１２，Ｕｎｉｔｅｄ Ｓｔａｔｅｓ ｏｆ Ａｍｅｒｉｃａ
【Ｆターム（参考）】
[ Back to top ]