JP5410549B2 - 事前計算動き情報を用いたビデオ・エンコード - Google Patents

Description

[0001] インターネットのようなネットワーク上におけるストリーミング・オーディオおよびビデオを再生することが増々普及するにつれて、再生中のネットワーク条件に一貫性がなくてもクライアントの体験を最大化するように、サーバーからクライアントに転送されるデータを最適化することが必要になっている。クライアントの体験を最適化するには、ビデオ再生のオーディオ部分およびビデオ部分をエンコードする品質レベルを選択して、ビデオ・コンテンツの品質を保存しつつ、ビデオを中断することなく転送し再現できるようにしなければならない。

[0002] 品質レベルは、一般に、入力ストリームにおいてエンコードされているオーディオまたはビデオ部分に対して指定されたビット・レートによって決められる。ビット・レートが高い程、一般に、元のオーディオまたはビデオについてエンコードされ保持されている情報量が多いことを示し、したがって、ビデオの再生中に、元の入力オーディオまたはビデオが一層精度良く再現され提示されることになる。逆に、ビット・レートが低い程、元の入力オーディオまたはビデオについてエンコードされ保持されている情報が少なく、したがって、ビデオ再生中に、元のオーディオまたはビデオが、精度を低くして再現され提示されることを示す。

[0003] 一般に、ビット・レートは、様々な要因に基づいてビデオおよびオーディオの各々をエンコードするために指定される。第１の要因は、サーバーとクライアントとの間におけるネットワーク状態である。大量のデータを転送することができるネットワーク接続は、このネットワーク接続を通じて後に転送される入力ビデオに対してより高いビット・レートを指定できることを示す。第２の要因は、所望の起動レイテンシーである。起動レイテンシーとは、大量のデータを受信し、処理し、バッファーしなければならないために、最初に起動するときにビデオ再生ツールに生ずる遅れのことである。第３の要因は、グリッチング(glitching)に対する耐性である。グリッチングとは、データが失われたためにビデオ再生を停止しなければならないときのことである。殆どの場合、起動レイテンシーまたはグリッチングは、いかなる量であっても許容できず、したがって、起動レイテンシーやグリッチングを最小限に抑えるまたは排除するように、指定されるビット・レートを最適化することが望ましい。

[0004] 現在入手可能な市販のストリーミング・メディア・システムは、コーディング・レート制御を行う際に多ビット・レート（ＭＢＲ）コーディングを拠り所としている。ＭＢＲコーディングでは、ソース・ビデオ・コンテンツは異なるコーディング・レートで代用ビット・ストリームにエンコードされ、サーバーにおいて同じメディア・ファイルに格納されるのが通例である。これによって、変化するネットワーク状態にしたがって、異なるコーディング・レートに対応する様々なレベルの品質で、セグメント単位またはチャンク(chunk)単位で、通例セグメント間でビット・ストリーム切り替えを用いて、コンテンツを再生することが可能となる。
ビデオ・エンコードにおける動き推定および補償
[0005] ビデオをエンコードして所望のビット・レートに圧縮する技法は、多数開発されている。このような技法には、フレーム内圧縮技法（フレームが静止画像として圧縮される）、およびフレーム間圧縮技法（1つ又は複数の他のフレームからフレームが予測または推定される）が含まれる。フレーム内圧縮は、データに対する周波数変換、ならびにそれに続く非可逆(lossy) 圧縮および可逆(lossless)圧縮を伴うことが多い。フレーム間圧縮は、動き推定を含むことができる。

[0006] 動き推定は、フレーム間における動きを推定するプロセスである。ビデオ用動き推定は、非適切問題であると言われる。何故なら、見られる場面内における動きは三次元で発生するが、ビデオの連続フレームは３Ｄ場面の二次元画像平面への投影であるからである。広く行き渡った１つの技法では、動き推定を用いるエンコーダーが、現フレームにおける画素のブロックを、他のフレーム（基準フレームと呼ぶ）の中にある検索エリアにおける同様の画素のブロック（ピクチャー・エレメントまたはサンプル）と照合しようとする。エンコーダーが基準フレームの検索エリアにおいて正確な一致または「十分に近い」一致を発見したとき、エンコーダーはこれらのブロックの位置変化を動きデータ（動きベクトルのような）としてパラメータ化する。

[0007] 逆に、動き補償は、動きデータを用いて基準フレームからフレームを再現するプロセスである。広く行き渡った１つの技法では、エンコーダーまたはデコーダーが、現フレームの動きデータを基準フレームに適用することによって、現フレームを再現し、予測フレームを作成する。エンコーダーは、予測フレームと現フレームの元のバージョンとの間の差（残差と呼ばれることもある）を、フレーム内圧縮（例えば、損失付随または損失なし圧縮）に用いられるのと同じ技法を用いて圧縮することができる。カメラ・ビデオの総体的ビット・レートは、残差のビット・レートに非常に依存し、残差のビット・レートは、動きデータのビット・レートと比較すると、総体的ビット・レートにおいてひときわ目立つ可能性がある。残差のビット・レートは、残差が単純である（例えば、何らかの規準にしたがって正確な一致または正当な一致に導く動き推定のために）場合、または非可逆圧縮が残差の複雑度を劇的に低下させる場合には低くなる。一方、複素残差(complex residual)（即ち、動き推定が正当な一致を見いだせなかった場合の残差）のビット・レートは、残差の複雑度を低下させるために適用される非可逆圧縮の度合いに応じて、一層高くなる可能性がある。

[0008] 以下の詳細な説明は、多ビット・レートおよびマルチ・コアの用途におけるように、事前に計算された動き情報を用いるビデオ・エンコーディング技法（方法、デバイス、およびシステムによって実現される）に関する。これら種々の用途では、ビデオ・エンコーダーが生ビデオ・コンテンツおよび事前に計算された動き情報を入力として取り込む。次いで、ビデオ・エンコーダーは、この事前に計算された動き情報に基づいて、動き補償を適用し、生ビデオ・コンテンツの予測フレームをエンコードすることができる。種々の用途では、これによって、ビデオ・エンコーダーは一層効率的に動き推定および補償を適用することが可能になる。

[0009] 多ビット・レート用途の一例では、事前に計算した動き情報入力を有するビデオ・エンコーダーを用いて、ソース・ビデオをエンコードして、連続的に低くなるビット・レートとした複数のビット・ストリームを得る。連続的に低くなるビット・レートでエンコードしたビット・ストリーム毎に、ビデオ・エンコーダーは、それよりも高いビット・レートで以前のビット・ストリームについて計算した動き情報を、その事前に計算した動き情報入力として受ける。ビデオ・エンコーダーは、次に低いビット・レートでビット・ストリームの動き補償エンコードを実行するために、それよりも高いビット・レートで以前のビット・ストリームについて計算したこの入力動き情報を用いることを選択することができる。しかしながら、ビデオ・エンコーダーは、ビット・レートの低下を達成するためには、他のエンコーディング・パラメータの中でもとりわけ、量子化の度合いおよびビデオ解像度というような、エンコーディング・パラメータの種々の調節を行う必要がある。ビデオ用動き推定は、先に背景において論じたように、「非適切問題」であるので（理由の中でもとりわけ）、より高いエンコーディング・ビット・レートでのビデオについて事前に計算された動き情報は、より低いビット・レートを達成するために調節されたエンコーディング・パラメータを用いて同じソース・ビデオをエンコードするには、低精度であることが分かる。例えば、予測フレームの所与のブロックに対して高い一致度（小さな残差）が得られる動きベクトルは、高い方のビット・レートのエンコーディング・パラメータで基準フレームがエンコードされたときと、低い方のビット・レートで基準フレームがエンコードされたときとの間で比較すると、変化する可能性がある。前述の多ビット・レートの用途の例では、ビデオ・エンコーダーは、次の連続ビット・レートのエンコードがビデオ解像度の変化を含むか否かに応じて、より高いビット・レートについて計算された入力動き情報を用いるか否か選択する。ビデオ解像度が次の連続ビット・レートでは変化していない場合、ビデオ・エンコーダーは、より高いビット・レートに合わせて事前に計算された入力動き情報を用いる。しかし、ビデオ解像度が変化する場合、ビデオ・エンコーダーは、代わりに、現在のビット・レートでビット・ストリームをエンコードするために、新たに動き情報を計算する。この新たに計算された動き情報は、事前に計算された動き情報入力として、次に低いビット・レートにおけるビット・ストリームのために、ビデオ・エンコーダーに受け渡される。

[0010] マルチ・コア・プロセッサーの用途の一例では、動き推定は、ビデオ・エンコーダーに入力される前に、別の事前計算フェーズとして実行される。フレーム内圧縮が、ソース・ビデオの基準フレームに対して最初に行われる。次に、動き推定事前計算を、マルチ・コア・コンピューターにおいてほぼ並列な動作として実行することができる。コンピューターの各プロセッサー・コアが、別々のフレームの動き推定を計算するために割り当てられ、別々のフレームは、それぞれの基準フレームに対してフレーム間（予測）エンコードを用いてエンコードされる。このようにプロセッサー・コア間で動き推定の計算を分割することによって、ビデオ・エンコーダーはマルチ・コア・コンピューターの処理能力を最大限利用することが可能になる。

[0011] この摘要は、詳細な説明において以下で更に説明する概念から選択したものを、簡略化した形態で紹介するために設けられている。この摘要は、特許請求する主題の主要な特徴や必須の特徴を特定することを意図するのではなく、特許請求する主題の範囲を決定するときに補助として用いられることを意図するのでもない。本発明の更に別の特徴や利点は、添付図面を参照しながら進められる、以下の実施形態の詳細な説明から明白となろう。

図１は、事前計算された動き情報入力を有するビデオ・エンコーダーのブロック図である。 図２は、図１のビデオ・エンコーダーの一般化した実施態様のブロック図である。 図３は、可変ビット・レートで、ビデオの区分ストリーミングを供給するビデオ・ストリーミング・システムのブロック図である。 図４は、図３のビデオ・ストリーミング・システムによる区分ストリーミングにおいて用いる、図１のビデオ・エンコーダーを用いて区分ビデオ・ストリーミングをエンコードするビデオ・エンコーディング・システムのブロック図である。 図５は、図４のビデオ・エンコーディング・システムによって実行されるプロセスのフロー・チャートである。 図６は、図１のビデオ・エンコーダーのための動き情報の事前計算にマルチ・コア・プロセッサーを用いるビデオ・エンコーディング・システムのデータ・フロー図である。 図７は、種々の記載する実施形態を実現することができる動作環境を一般化したブロック図である。

[0019] 以下の詳細な説明は、事前に計算された動き情報を用いるビデオ・エンコードのための種々の技法およびシステムに関する。これらの技法は、多ビット・レート・ストリーミングへの応用、およびマルチ・コア・ビデオ・エンコードへの応用というコンテキストで説明する。しかしながら、これらの技法は、更に広く他のビデオ・エンコードの用途にも適用することができる。

[0020] 本明細書において記載する種々の技法およびツールは、独立して用いることができる。これらの技法およびツールの中には、組み合わせて用いることができるものもある。以下では、処理動作(act)のフローチャートを参照しながら種々の技法について説明する。フローチャートにおいて示される種々の処理動作は、それらよりも少ない動作に統合すること、またはそれらよりも多い動作に分離することもできる。簡素化のために、個々のフローチャートに示される動作の、別の場所で説明される動作に対する関係は、示されないことが多い。多くの場合、フローチャートにおける動作は、順序を変更することができる。
Ｉ．事前計算された動き情報を用いるビデオ・エンコーダー
[0021] 図１は、以下で説明する多ビット・レートおよびマルチ・コアの用途において用いることができるビデオ・エンコーダー１００の一例を示す。ビデオ・エンコーダー１００は、ビデオ・コンテンツの「生の」（圧縮されていない）フレーム、およびこのビデオ・コンテンツについて事前に計算された動き情報を受けるために入力１１０、１２０を有する。次いで、このビデオ・エンコーダーは、ビデオ・コンテンツの基準フレームのフレーム内コーディングを実行し、動き情報を利用して、ビデオ・コンテンツの予測フレームのフレーム間コーディングを実行する。このエンコードは、Windows Media Videoフォーマット、SMPTE-421-Mフォーマット、ＭＰＥＧ−ｘフォーマット（例えば、ＭＰＥＧ−１、ＭＰＥＧ−２、またはＭＰＥＧ−４）、Ｈ．２６ｘフォーマット（例えば、Ｈ．２６１、Ｈ．２６２、Ｈ．２６３、またはＨ．２６４）、または他のフォーマットというような、既知のビデオ・エンコード規格にしたがって実行することができる。しかしながら、フレーム間コーディングの場合、ビデオ・エンコーダーは、それ自体の動き推定をフレームについて実行する代わりに、予測フレームのフレーム間コーディングについて予め計算されている動き情報を用いることを選択することができる。ビデオ・エンコーダーは、ビデオ・コンテンツをエンコードして圧縮ビットストリームとし、これを出力１３０として供給する。また、ビデオ・エンコーダーは、入力ビデオ・コンテンツのフレーム間圧縮に用いた動き情報も、動き情報出力１４０として出力することができる。

[0022] 図２は、ビデオ・エンコーダー１００の適した実施態様の一例を示す、一般化したブロック図であり、これと共に、以下で更に詳細に説明する多ビット・レートおよびマルチ・コア技法を実現することができる。ビデオ・エンコーダー１００は、ビデオ・ピクチャー（フレーム）のシーケンスをその生ビデオ・コンテンツ入力１１０として事前計算動き情報入力１２０と共に受信し、圧縮ビット・ストリーム１３０を出力として生成する。

[0023] ビデオ・エンコーダー１００は、ビデオ・ピクチャーを処理する。「ピクチャー」という用語は、一般に、ソース画像データ、コード化画像データ、または再現された画像データを指す。プログレシブ・ビデオ(progressive video)では、ピクチャーはプログレシブ・ビデオ・フレームとなる。インターレース・ビデオでは、ピクチャーは、コンテキストに応じて、インターレース・ビデオ・フレーム、フレームの最上位フィールド、またはフレームの最下位フィールドを指す場合もある。

[0024] ビデオ・エンコーダー１００は、入力ビデオのインター・コード化予測ピクチャー、および入力ビデオのイントラ・コード化ピクチャーを圧縮する。提示のために、図２は、エンコーダー１００を通過するイントラ・コード化フレームの経路と、インター・コード化予測フレームの経路とを示す。ビデオ・エンコーダー１００のコンポーネントの多くは、イントラ・コード化コンテンツおよびインター・コード化予測コンテンツの双方を圧縮するために用いられる。これらのコンポーネントによって行われる正確な動作は、圧縮される情報のタイプに応じて変化する可能性がある。

[0025] 一般に、ビデオ・エンコーダー１００内では、インター・コード化予測フレーム（ピクチャーのような）が、事前に再現されたコンテンツ（1つ又は複数の他のピクチャーのような。これらは通例基準ピクチャーまたはアンカーと呼ばれる）からの予測に関して表される。例えば、所与の時点におけるコンテンツは、プログレッシブＰ−フレームまたはＢ−フレーム、インターレースＰ−フィールドまたはＢ−フィールド、あるいはインターレースＰ−フレームまたはＢ−フレームとしてエンコードされる。ビデオ・エンコーダー１００内部では、予測された情報と対応するイントラ・コード化フレームとの間の差が、予測残差となる。

[0026] インター−パス上にある入力ビデオ１１０のコンテンツは、動き情報に基づいて、予測ピクチャーとしてエンコードされる。ある種の条件を満たす場合、ビデオ・エンコーダー１００は、入力１２０からの事前計算動き情報を用いる（選択スイッチ２５６によって図示されるように）。この動き情報は、マクロブロックに対する１組のまたは一連の動きベクトル、あるいは1つ又は複数の基準ピクチャーに関する他のインター−パス・ビデオ・ピクチャーのサンプル集合という形態をなすことができる。一般に、事前計算動き情報を用いる選択は、第１に、事前計算動き情報の利用可能性に基づき、第２に、動き情報の直前の計算からどのエンコーディング・パラメータが変化したか、そして変化したか否か、更にビデオ・コンテンツの現在のエンコードに用いられているパラメータに基づく。一例では、動き情報が、ビデオ・エンコーダーが現在エンコードしているビデオ・コンテンツとは異なるビデオ解像度を有するビデオ・コンテンツをエンコードするために計算されたのである場合、ビデオ・エンコーダーは、入力１３０からの、事前に計算した動き情報を用いないことを選択する。

[0027] しかしながら、ビデオ・エンコーダー１００は、代わりに、動き推定部２５８を用いて、インター−パス・ビデオ・コンテンツ１１０に対して新たな動き推定を実行することを選択することができる（この場合も、選択スイッチ２５６によって図示されている）。動き推定部２５８は、事前にエンコードされたビデオ・コンテンツ・フレームの再現を表す、1つ又は複数の基準ピクチャーに対するビデオ・ピクチャーのマクロブロックまたは他のサンプル集合の動きを推定する。ピクチャー・ストア２６４は、この再現されたビデオ・コンテンツ２６６を、１つまたは複数の基準ピクチャーとしてバッファーする。多数の基準ピクチャーが用いられる場合、多数の基準ピクチャーは異なる時間方向または同じ時間方向から得ることができる。動き推定部２５８は、動きベクトル情報のような動き情報２６０を出力する。

[0028] 動き補償部２６２は、動き補償した現ピクチャー２６８を形成するときに、動きベクトルをある種の再現されたビデオ・コンテンツ２６６（基準ピクチャー（１つまたは複数）として格納されている）に適用する。動き補償ピクチャー２６８のブロックと元のインター−パス・ビデオ・ピクチャーの対応するブロックとの間における差（少しでもある場合）は、そのブロックに対する予測残差２７０となる。後にインター−パス・ビデオ・フレーム（例えば、ビデオ・デコーダーにおいて）を再現する間に、再現される予測残差は動き補償残差ビデオ２６８に加算されて、元のインター−パス・ビデオ２５６に更に近い再現コンテンツが得られる。しかしながら、非可逆圧縮の場合、一部の情報が元のインター−パス・ビデオから失われることに変わりはない。代わりに、動き推定部および動き補償部が他のタイプの動き推定／補償を適用する。

[0029] 周波数変換器２８０は、空間ドメイン・ビデオ情報を周波数ドメイン（即ち、空間、変換）データに変換する。ブロック基準のビデオ・コンテンツでは、周波数変換器２８０はＤＣＴ、ＤＣＴの異形、または他の前方ブロック変換(forward block transform)をサンプルまたは予測残差データのブロックに適用して、周波数変換係数のブロックを生成する。周波数変換器２８０は、８×８、８×４、４×８、４×４、または他のサイズの周波数変換を適用することができる。

[0030] 次に、量子化器２８２が変換係数のブロックを量子化する。量子化器２８２は、ピクチャー毎に、マクロブロック毎に、または他の単位毎に空間的に変化するステップ・サイズで、非均一スカラー量子化をスペクトル・データに適用する。加えて、場合によっては、量子化器がインター−レイヤー残差ビデオ・ピクチャーの色チャネルにわたって量子化を変化させることもある。また、量子化器２８２は、少なくとも一部の空間データ係数に対して他のタイプの量子化、例えば、均一または適応量子化を適用することもでき、あるいは周波数変換を用いないエンコーダー・システムにおいて空間ドメイン・データを直接量子化する。

[0031] 再現されたビデオ・コンテンツが、後続のインター−パス・ビデオ・ピクチャーの動き推定／補償に必要とされる場合、逆量子化器２９０が、量子化されたスペクトル・データ係数に対して逆量子化を実行する。逆周波数変換器２９２は、逆周波数変換を実行して、再現された予測残差（予測されたインター−パス残差ビデオ・コンテンツに対して）またはサンプル（イントラ−パス残差ビデオ・コンテンツに対して）のブロックを生成する。残差ビデオ・コンテンツ２５６が動き補償予測されていた場合、再現された予測残差を動き補償予測部２６８に加算して、再現残差ビデオを形成する。ピクチャー・ストア２６４は、後続の動き補償予測において用いるために、再現された残差ビデオをバッファーする。

[0032] エントロピー・コーダー２８４は、量子化器２８２の出力およびある種の副次情報（例えば、量子化パラメータ値）を圧縮する。典型的なエントロピー・コーディング技法は、算術コーディング、差分コーディング、ハフマン・コーディング、ラン・レングス・コーディング、ＬＺコーディング、辞書型コーディング、およびこれらの組み合わせを含む。エントロピー・コーダー２８４は、通例、異なる種類の情報毎に異なるコーディング技法を用い、特定のコード化技法内にある多数のコード表から選択することができる。

[0033] ビデオ・エンコーダー２４０がイントラ−パス・ビデオ・コンテンツのイントラ−圧縮を実行するとき、このエンコーダーは、動き補償せずに、それをイントラ・コード化ピクチャーとして圧縮する。ビデオ２５６は、直接、周波数変換器２８０、量子化器２８２、およびエントロピー・コーダー２８４に供給され、エンコードされたビデオとして出力される。イントラ−コード化ビデオの再現バージョンは、後続の他のインター−パス・ビデオの動き補償に用いるために、バッファーすることができる。

[0034] コントローラー２９４は、動き推定部２５８、周波数変換器２８０、量子化器２８２、逆量子化器２９０、およびエントロピー・コーダー２８４のような、種々のモジュールから入力を受ける。コントローラー２９４は、エンコードの間中間結果を評価して、例えば、量子化ステップ・サイズを設定し、レート−歪み分析を実行する。コントローラー２９４は、他のモジュールと共に動作して、エンコードの間にコード化パラメータを設定および変更する。コントローラー２９４が異なるコード化パラメータの選択肢を評価するとき、コントローラー２９４は異なるパラメータ設定値を評価するためにある種の段階を繰り返し実行することができ、あるいはコントローラー２９４は異なるコード化パラメータを纏めて評価することもできる。評価すべきコード化パラメータ決定のツリー、および対応するエンコードのタイミングは、実施態様に依存する。実施形態によっては、コントローラー２９４がエンコーディング・セッション・ウィザード・インターフェース、他のエンコーダー・アプリケーション・インターフェース、または他のソースからも入力を受け取り、特定の規則を用いてエンコードするビデオを指定する場合もある。

[0035] ある種の用途では、ビデオ・エンコーダー１００は、他の変化するエンコーディング・パラメータを用いて生ビデオ・コンテンツをエンコードして、以下で論ずる多ビット・レート用途において異なるビット・レートを得るために、事前計算動き情報として用いるためというように、インター−パス・ビデオ・コンテンツ（事前計算動き情報入力１３０からかまたは動き推定部２５８からかには関係なく）の動き補償に用いられた動き情報を出力することもできる。
ＩＩ．多ビット・レート・ビデオ・エンコーダー
[0036] 図１および図２に示したビデオ・エンコーダー１００は、多ビット・レート・ストリーミングの用途のためにインデックス化ファイルを生成するために用いることができる。インデックス化ファイルは、一般に、マルチメディア・プログラムのビデオを多数のストリーミング・セグメントに分割し、種々のビット・レートのビデオ・セグメントを表す多数の圧縮ビット・ストリームを収容する。

[0037] 一般に、多ビット・レート・ストリーミング用のインデックス化ファイルは、標準的なＨＴＴＰサーバーが、多数のビット・レートでマルチメディア・コンテンツを配給するために用いることができる。ビット・レートの選択（レート制御）は、クライアント側（例えば、クライアント側のみ）で行われる。クライアントは、最初にプログラムのストリーミング・セグメントに利用可能な種々のビット・レートを記載したインデックス情報をサーバーから入手することによって、レート制御を実行することができる。インデックス情報に基づいて、そして可能であれば他の情報（例えば、ネットワーク帯域幅、バッファー情報等）に基づいて、クライアントは所望のユーザー体験（利用可能なビット・レートおよび現在のネットワーク状態に基づいて、可能な限り最良のユーザー体験）を提供するためには、どのビット・レートでストリーミング・セグメントをサーバーからダウンロードするか判断することができる。
[0038] 他のタイプのコンピューティング・デバイス（例えば、従前からのＨＴＴＰサーバー以外）が、インデックス化ファイルを用いて、ファイルを提供することもできる。例えば、コンピューティング・デバイス（例えば、パーソナル・コンピューター、サーバー・コンピューター、または特殊目的ストリーミング・メディア・サーバー）がインデックス化ファイル・レイアウトを用いて、種々のファイル配給プロトコル（例えば、ファイル転送プロトコル（ＦＴＰ）、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、リアル・タイム・ストリーミング・プロトコル（ＲＴＳＰ）、ＭＭＳ（Microsoft Media Services)等）を用いてマルチメディア・コンテンツを配給することができる。

[0039] ビット・レートの切り替えをサポートするために、プログラムは、ストリーミング・セグメント（自己完結ユニット）と呼ばれる時間チャンク(temporal chunk)に分割される。サーバーは、各ストリーミング・セグメントを1つ又は複数のビット・レートで格納する（例えば、各ストリーミング・セグメント−ビット・レートの組み合わせが、別のストリーミング・セグメント・エンコードとなる）。各ストリーミング・セグメントは、プログラムの特定のトラック（例えば、英語のオーディオ・トラックのような特定のオーディオ・トラック、または特定のビデオ・トラック）に利用可能な1つ又は複数のビット・レート・エンコードを有する。次いで、クライアントは、利用可能なビット・レートから（例えば、利用可能なストリーミング・セグメント・エンコードから）どのビット・レートにするか判断して、ストリーミング・セグメント毎にダウンロードする。例えば、クライアントは２５０Ｋｂ／秒（キロビット毎秒）でエンコードされたビデオ・トラック用第１ストリーミング・セグメント（第１ストリーミング・セグメントに利用可能な1つ又は複数のストリーミング・セグメント・エンコードから）、５００Ｋｂ／秒でエンコードされたビデオ・トラック用第２ストリーミング・セグメント（第２ストリーミング・セグメントに利用可能な1つ又は複数のストリーミング・セグメント・エンコードから）、および１Ｍｂ／秒（メガビット毎秒）でエンコードされたビデオ・トラック用第３ストリーミング・セグメント（第３ストリーミング・セグメントに利用可能な1つ又は複数のストリーミング・セグメント・エンコードから）を入手することができる。各ストリーミング・セグメント・エンコードは、一定ビット・レート（ＣＢＲ）または可変ビット・レート（ＶＢＲ）とすることができる（そして、ＣＢＲおよびＶＢＲの使用は、ストリーミング・セグメント・エンコード毎に混合することができる）。

[0040] 図３は、インデックス化ファイル・レイアウトを用いた、マルチメディア・コンテンツの区分ストリーミングのシステムを一般化したブロック図３００で示す。図３００において、サーバー３１０（例えば、標準的なＨＴＴＰサーバーのようなサーバー・コンピューター・システム）がマルチメディア・コンテンツをクライアント３２０（例えば、ラップトップまたはデスクトップ・コンピューターのようなクライアント・コンピューター・システム、あるいはＰＤＡまたは移動体電話機のような他のタイプのコンピューティング・デバイス）にネットワーク３３０（例えば、インターネット）を通じて供給する。図３００では、サーバー３１０はプログラムをインデックス化ファイルに格納する。クライアント３２０は、クライアント側レート制御ソフトウェアおよび／またはハードウェアを備えている。

[0041] 具体的な一実施態様例では、サーバー３１０は標準的なＨＴＴＰサーバーであり、ファイルを配給することができる以外には、特別のストリーミング能力が全くない。サーバー３１０は特殊ビット・レート選択能力を全くサポートしないので、クライアント３２０が全てのビット・レート選択動作(activities)を実行しなければならない。この実施態様では、クライアント３２０は全てのビット・レート選択動作を実行する。例えば、クライアント３２０は、サーバー３１０から入手したインデックス情報を用いて（例えば、単独で、またはクライアント・バッファー情報、ネットワーク帯域幅等というような他の情報と組み合わせて）、レート制御を実行することができる。しかしながら、他の実施態様では、レート制御機能の一部または全部をサーバーにおいて行うことができる。

[0042] 図４は、多ビット・レート・ビデオ・ストリーミング・システム３００（図３）において用いるために、種々のビット・レートでマルチメディア・プログラムのビデオをエンコードして１組のビット・ストリーム４１０〜４１２を得るために、事前計算動き情報と共にビデオ・エンコーダー１００（図１）を用いる多ビット・レート・ビデオ・エンコーディング・システム４００を示す。この図に示すように、ビデオ・エンコーディング・システム４００は、初期のビット・レートが最も高いストリーム４１０から開始して、連続的にビット・レートが低下するビット・ストリーム４１１〜４１２を含む１組のビット・ストリームを生成する。例示の目的で、図４は連続的にビット・レートが低下する３つのストリームを生成する多ビット・レート・ビデオ・エンコーディング・システム４００を示す。しかしながら、多ビット・レート・ビデオ・エンコーディング・システムは、種々のビット・レートでいかなる数のストリームでも生成するように設計することもできることは明白なはずである。

[0043] 図５は、１組のビット・ストリーム４１０〜４１２をエンコードするために、多ビット・レート・ビデオ・エンコーディング・システムが実行するプロセス・フロー５００を示す。最初の動作において、多ビット・レート・ビデオ・エンコーディング・システム４００は、最初に、初期のビット・レートが最も高いストリーム４１０をエンコードする。初期のビット・レートが最も高いストリーム４１０に対して、ビデオ・エンコーディング・システム４００は、生ビデオ・コンテンツをビデオ・エンコーダー１００のビデオ入力１１０に入力する。これはビデオ・コンテンツの最初のエンコードであるので、事前計算された動き情報は一般に入手可能ではなく、ビデオ・エンコーダーの動き情報入力１２０は０となる。この場合、ビデオ・エンコーダー１００の動き推定部２５８（図２）が動き推定プロセスを実行して、ビット・レートが最も高いストリームに対するビデオ・コンテンツのフレーム間の動き補償のための動き情報を生成する。あるいは、事前計算動き情報が入手可能である場合（以下で論ずるマルチ・コア動き事前計算を用いて、動き情報を事前計算する場合等）、事前計算された動き情報がビデオ・エンコーダー１００の入力１２０に供給される。次いで、ビデオ・エンコーダーは、エンコードの間フレーム間の動き補償のために、この入力された動き情報を用いることを選択することができる（例えば、図２における動き情報選択スイッチ２５６を通じて）。

[0044] 動作５１１〜５１８の繰り返しループにおいて、多レート・ビデオ・エンコーディング・システムは、次に、後続の各ビット・レート・ストリーム４１１〜４１２をエンコードする。これら後続のストリーム４１１〜４１２に対して、連続的に低下するビット・レートで、多ビット・レート・ビデオ・エンコーディング・システム４００は再度同じ生ビデオ・コンテンツをビデオ・エンコーダー１００の入力１１０に供給する。加えて、各ストリーム４１０〜４１２の動き補償に用いられる動き情報が、ビデオ・エンコーダー１００の出力に供給され、動作５１２に示すように、次のストリーム４１１〜４１２のビデオ・エンコーダーの動き情報入力１２０に受け渡される。つまり、例えば、ビデオ・エンコーダーにおいて初期ストリーム４１０のために動き推定部２５８によって計算された動き情報は、次にビット・レートが低いストリーム４１１のビデオ・エンコーダーによって用いられるために受け渡される。

[0045] 動作５１３〜５１７によって示すように、後続のビット・レート・ストリーム毎のビデオ・エンコーダーは、次に、直前のストリームからその入力１２０に受け渡された動き情報を用いるか否か（動作５１５）、または新たな動き推定を行うか否か（動作５１６）選択する。一般に、予期計算された動き情報を用いるか、または動き推定を新たに行うかについての判断は、所望のエンコーディング効率および品質で動き補償を実行するには動き情報に十分な信頼性がなくなるまでに限って、エンコーディング・パラメータが、次に低いビット・レートが得られるように変化しつつあるか否かに基づいて行われる。多ビット・レート・ビデオ・エンコーディング・システム４００の一実施態様例では、動き情報の選択は、現ストリーム４１１〜４１２に新たな更に低いビット・レートが得られるように、ビデオ解像度を変化させたか否かに基づくことができる。したがって、ビデオ・エンコーダーは、動作５１３において、ストリームをエンコードするために用いるべきビデオ解像度を決定する。判断５１４において、動き情報選択スイッチ２５６は、ビデオ解像度が直前のストリームのそれに対して変更される(resize)か否かに基づいて、どの動き情報を用いるべきか決定する。ビデオ解像度が不変のままである場合、ビデオ・エンコーダーは、動作５１５によって示すように、直前のストリームのエンコードから受け渡された動き情報を用いて、後続のストリームをエンコードすることを選択する。しかしながら、ビデオ解像度が変更される場合、ビデオ・エンコーダーは代わりにその動き推定部２８５を用いて、新たなビデオ解像度でイントラ・コード化される基準フレームを用いて、ビデオ・コンテンツに対して新たな動き推定（動作５１６）を行う。動作５１７において、ビデオ・エンコーダーは次にこの新たな動き情報を用いてストリームをエンコードする。次に、新たに計算された動き情報は、次にビット・レートが低いストリームのビデオ・エンコーダーに受け渡される（次の後続ストリームをエンコードするループ５１１〜５１８の次の繰り返しにおける動作５１２において）。

[0046] このように、以前のビット・レート・ストリームのエンコードの間に動き推定から計算された動き情報を受け渡し、次にビット・レートが低いストリームのフレーム間エンコードのために、多ビット・レート・ビデオ・エンコーディング・システム４００によって用いることができる。
ＩＩＩ．マルチ・コア動き計算ビデオ・エンコーダー
[0047] 先に論じたビデオ・エンコーダー１００の動き推定部２５８と同様、動き推定は、通例、フレーム間ピクチャーのブロック単位または他の同様のサンプル集合単位で、一般的には事前にエンコードされたフレーム（例えば、通例ではビデオの事前にエンコードされたイントラ・フレーム）から再現された（即ち、ビデオ・デコーダーによって行われるように）基準ピクチャーに関して行われる。動き推定は、通例、基準ピクチャーにおいて一致度が最も高いブロックを検索することを伴う。言い換えると、動き推定は、基準ピクチャーにおいて、インター・フレーム・ピクチャーの所与のブロックに対して最も小さな残差を生成するブロックを突き止めようとして、この所与のイントラ・フレーム・ピクチャー・ブロックと基準フレームとの一致度が最も高いブロックとの間の空間的変位である動き情報（動きベクトルのような）を発生する。再現されたイントラ・コード化フレームである基準フレームを動き推定に用いる理由は、このように事前にエンコードされたフレームのみが、デコーダーにおいてイントラ・コード化フレームを再現する際に用いるために、全く同じように利用可能であるからである。

[0048] 以下の章では、マルチ・コア・プロセッサー・コンピューターを用いて、生ビデオ・コンテンツに対して動き推定事前計算を実行し、次いでビデオ・エンコーダー１００への事前計算動き情報入力としてビデオ・コンテンツを用いることを可能にする技法を紹介する。従来の動き推定とは異なり、この動き推定事前計算は、ビデオ・コンテンツのあらゆるエンコード（フレーム内コーディングを含む）の前に行われる。したがって、事前にエンコードされたフレームは未だ入手可能ではなく、基準フレームとして用いるために再現することができるフレームはない。このマルチ・コア動き情報事前計算技法は、再現されたイントラ・コード化フレーム・ピクチャーの代わりに、動き推定の基準ピクチャーに、生ビデオ・コンテンツのフレームを用いる。ビデオ・エンコーダー１００によって後にエンコードされるときの量子化およびその他の圧縮損失のために、基準フレームとして用いられるこれらの生ビデオ・フレームは、一般に、デコーダーにおいて全く同じように再現することはできない。このマルチ・コア動き推定事前計算では生ビデオ・フレームを基準ピクチャーとして用いるために、動き情報は、事前にエンコードされて再現されたイントラ・フレームに基づくビデオ・エンコードの間の動き推定程には精度が高くない可能性があり、その結果、フレーム間エンコードに用いるときに、圧縮効率が低くなる可能性がある。

[0049] 図６は、マルチ・コア・プロセッサー・コンピューター上に動き情報事前計算を含むビデオ・エンコーディング・システム６００の実施態様の一例を、事前計算動き情報入力ビデオ・エンコーダー１００（図１）を用いるエンコードと共に示す。ビデオ・エンコーディング・システム６００は、動き推定を事前計算として（ビデオ・エンコードに先立って）実行する。

[0050] ビデオ・エンコーディング・システム６００は、動き推定の計算負荷を、マルチ・コア・プロセッサー・コンピューター６１０の別個のＣＰＵコア６２０〜６２３間で分割することによって、性能上の利点を達成する。マルチ・コア・プロセッサー・コンピューター６１０は、あらゆる数「ｎ」のＣＰＵコアでも有することができ、これらのＣＰＵコア上で動き推定を処理する。例えば、Intel社およびその他によって製造されている現在入手可能なマルチ・コア・コンピューターは、４、８、１６、３２、６４個、更にこれらよりも多いプロセッサー・コアを有する。

[0051] 動き推定のために、ＣＰＵコア６２０〜６２３は、各々、生ビデオ・コンテンツのフレーム群の内別のインター・フレームの動き推定を実行するために割り当てられる。このように、動き推定事前計算は、ＣＰＵコア間におけるメモリー競合を回避する。生ビデオ・コンテンツの別個のインター・フレーム（図ではＦ０...Ｆｎで示す）が、それぞれの基準フレームと共に、コンピューター６１０の別個のＣＰＵコアに供給される。ＣＰＵコアは、それらのそれぞれのインター・フレーム・ピクチャーに対して動き推定を実行して、動き情報（インター・フレームのブロックに対する１組の動きベクトルのような）を生成する。次いで、生ビデオ・コンテンツの次のインター・フレーム・ピクチャー群（例えば、１回の繰り返し当たり「ｎ」個のフレームから成る１群）についてこれを繰り返して、ビデオ・シーケンスまたはプログラム全体についての動き情報を生成する。

[0052] 次に、ＰＣＵコアを用いて動き推定事前計算によって生成した動き情報を、生ビデオ・コンテンツと共に、ビデオ・エンコーダー１００（図１）に入力することができる。次いで、ビデオ・エンコーダー１００は先に進んで、ビデオをエンコードする。このビデオのエンコードは、マルチ・コア動き推定事前計算からの動き情報を用いて、ビデオ・コンテンツのインター・フレームをエンコードすることを含む。ビデオ・エンコーダー１００はマルチ・コア動き推定事前計算からの動き情報を用いるので、ビデオ・エンコーダー１００は、それ自体が動き推定を（動き推定部２５８において）実行することを回避し、ビデオ・エンコードの大部分が省かれる。動き推定は、ビデオ・フレームがエンコードされる毎に順次行われるのではなく、マルチＣＰＵコア間で本質的に並列に事前計算として行われるので、このマルチ・コア・ビデオ・エンコーダーは、遙かに速いビデオのエンコードを達成する。
ＩＶ．代表的なコンピューティング環境
[0053] 図７は、記載した実施形態、技法、および技術を実現することができる、適したコンピューティング環境７００の一般化した例を示す。コンピューティング環境７００は、本技術の使用範囲や機能に関して何の限定をも示唆することは意図していない。何故なら、本技術は多様な汎用または特殊目的コンピューティング環境においても実現できるからである。例えば、開示した技術は、ハンド・ヘルド・デバイス、マルチプロセッサー・システム、マイクロプロセッサーに基づくまたはプログラマブルな消費者用電子機器、ネットワークＰＣ、ミニコンピューター、メインフレーム・コンピューター等を含む、他のコンピューター・システム構成でも実現することができる。また、開示した技術は、分散型コンピューティング環境においても実施することができ、この場合、通信ネットワークによってリンクされたリモート処理デバイスによってタスクが実行される。分散型コンピューティング環境では、プログラム・モジュールをローカルおよびリモート双方のメモリー記憶デバイスに位置付けることができる。

[0061] 図７を参照すると、コンピューティング環境７００は、少なくとも１つの中央演算装置７１０とメモリー７２０とを含む。先に論じたマルチ・コア動き情報事前計算のために、コンピューターは複数のＣＰＵコアを有するマルチ・コアＣＰＵを含む。図７では、この最も基本的な構成７３０が破線の内部に含まれている。中央演算装置７１０は、コンピューター実行可能命令を実行し、実在のプロセッサーであってもまたは仮想プロセッサーであってもよい。マルチ処理システムでは、多数の演算装置がコンピューター実行可能命令を実行することによって、処理パワーを増大させ、したがって、多数のプロセッサーが同時に実行することができる。メモリー７２０は、揮発性メモリー（例えば、レジスター、キャッシュ、ＲＡＭ）、不揮発性メモリー（例えば、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリー等）、またはこれら２つの何らかの組み合わせとすることができる。メモリー７２０は、例えば、本明細書において記載した技術を実現することができるソフトウェア７８０を格納する。コンピューティング環境は、更に別の機構を有することもある。例えば、コンピューティング環境７００は、ストレージ７４０、1つ又は複数の入力デバイス７５０、1つ又は複数の出力デバイス７６０、および1つ又は複数の通信接続７７０を含む。バス、コントローラー、またはネットワークのような相互接続メカニズム（図示せず）が、コンピューティング環境７００のコンピューターを相互接続する。通例、オペレーティング・システム・ソフトウェア（図示せず）が、コンピューティング環境７００において実行する他のソフトウェアに合わせて動作環境を提供し、コンピューティング環境７００のコンポーネントの動作(activities)を調整する。

[0055] ストレージ７４０は、リムーバブルまたは非リムーバブルであってもよく、磁気ディスク、磁気テープまたはカセット、ＣＤ−ＲＯＭ、ＣＤ−ＲＷ、ＤＶＤ、あるいは情報を格納するために用いることができ、コンピューティング環境７００内でアクセスすることができるのであれば他のいずれの媒体でも含む。ストレージ７４０は、本明細書において記載した技術を実現することができるソフトウェア７８０の命令を格納する。

[0056] 入力デバイス（１つまたは複数）７５０は、キーボード、キーパッド、マウス、ペン、またはトラックボールのような接触入力デバイス、音声入力デバイス、走査デバイス、またはコンピューティング環境７００に入力を供給するその他のデバイスとすることができる。オーディオについては、入力デバイス（１つまたは複数）７５０は、サウンド・カード、あるいはオーディオ入力をアナログまたはデジタル形態で受け入れる同様のデバイス、あるいはオーディオ・サンプルをコンピューティング環境７００に供給するＣＤ−ＲＯＭリーダーとすることができる。出力デバイス（１つまたは複数）７６０は、ディスプレイ、プリンター、スピーカー、ＣＤ−ライター、またはコンピューティング環境７００からの出力を供給するその他のデバイスとすることができる。

[0057] 通信接続（１つまたは複数）７７０は、通信媒体（例えば、接続ネットワーク）を通じた他のコンピューティング・エンティティとの通信を可能にする。通信媒体は、コンピューター実行可能命令、圧縮グラフィクス情報、または変調データ信号の中にある他のデータというような情報を伝える。

[0058] コンピューター読み取り可能媒体は、コンピューティング環境７００内部においてアクセスすることができる利用可能なあらゆる媒体である。一例として、そして限定ではなく、コンピューティング環境７００では、コンピューター読み取り可能媒体はメモリー７２０、ストレージ７４０、通信媒体、および以上の内のいずれかの組み合わせを含む。容易に理解できてしかるべきであるが、コンピューター読み取り可能記憶媒体という用語は、メモリー６２０およびストレージ６４０のようなデータ記憶媒体や、変調データ信号のような単純でない伝送媒体を含む。

[0059] 本明細書において記載した方法は、そのいずれも、1つ又は複数のコンピューター読み取り可能媒体（例えば、ストレージまたは他の有形媒体）を通じて実行することができ、このような方法を実行する（例えば、コンピューティング・デバイス、オーディオおよび／またはビデオ処理デバイス、あるいはコンピューターに実行させる）コンピューター実行可能命令を備えている（例えば、有するまたは格納する）。動作は、完全自動、半自動とすることができ、または手作業の介入を伴うことができる。

[0060] 以上、本改革の原理について詳細な説明および添付図面において説明し図示したが、このような原理から逸脱することなく、種々の実施形態の構成および詳細を変更できることは認められよう。尚、本明細書において記載したプログラム、プロセス、または方法は、特に指示されていない限り、いずれの特定のタイプのコンピューティング環境にも関係付けられていないまたは限定されないことは言うまでもない。様々なタイプの汎用または特殊コンピューティング環境を、本明細補において記載した教示と共に用いることができ、あるいはこれらのコンピューティング環境が、本明細書において記載した教示にしたがって動作を実行することもできる。ソフトウェアとして示した実施形態のエレメントをハードウェアで実現することもでき、その逆も可能である。

[0061] 本発明の原理を適用することができる数多くの実施形態があり得ることに鑑み、以下の特許請求の範囲およびその均等物の範囲および主旨に該当すると考えられる実施形態全てを、我々の発明として特許請求する。

Claims (8)

1. 多ビット・レート・ビデオにエンコードするために生ビデオ・コンテンツを処理する方法であって、
   徐々に低下するビット・レートで連続的に、圧縮ビデオ・ビット・ストリームとしてエンコードするために、生ビデオ・コンテンツを受けるステップと、
   初期圧縮ビデオ・ビット・ストリームを最も高いビット・レートでエンコードするステップであって、前記初期圧縮ビデオ・ビット・ストリームをエンコードすることによって、前記ビデオのインター・フレーム・ピクチャーのエンコードのために動き情報を生成する、ステップと、
   徐々に低下するビット・レートで後続の圧縮ビデオ・ビット・ストリームをエンコードするために、
   以前の圧縮ビデオ・ビット・ストリームをエンコードすることによって生成された前記動き情報を、前記後続の圧縮ビデオ・ビット・ストリームのエンコードに受け渡すステップと、
   前記後続の圧縮ビデオ・ビット・ストリームについてのビデオ・エンコーディング・パラメータに基づく条件が満たされているか否か判断するステップと、
   前記条件が満たされている場合、前記後続の圧縮ビデオ・ビット・ストリームをエンコードするステップであって、前記後続の圧縮ビデオ・ビット・ストリームのインター・フレームが、直前の圧縮ビデオ・ビット・ストリームをエンコードすることから受け渡された前記動き情報を用いて、エンコードされる、ステップと、
   前記条件が満たされない場合、前記後続の圧縮ビデオ・ビット・ストリームの再現された基準フレームに基づいて動き推定を実行し、前記後続の圧縮ビデオ・ビット・ストリームをエンコードすることによって、新たな動き情報を生成するステップであって、前記後続の圧縮ビデオ・ビット・ストリームのインター・フレームが、前記新たな動き情報を用いて、エンコードされる、ステップと、
   前記初期および後続の圧縮ビデオ・ストリームを含む出力多ビット・レート・ビデオを生成するステップと、
   を備えている、方法。
2. 請求項１記載の方法において、前記条件が、直前の圧縮ビデオ・ビット・ストリームと後続の圧縮ビデオ・ビット・ストリームとの間においてビデオ解像度が不変のままであることである、方法。
3. マルチ・コアＣＰＵを有するコンピューター上においてビデオをエンコードする方法であって、
   ビデオのエンコードに先だって、前記ビデオのインター・フレーム・ピクチャー群についての動き情報を、動き推定事前計算として生成するステップを備えており、前記動き情報を生成するステップが、
   １群におけるインター・フレーム・ピクチャー毎に、前記コンピューターの複数のＣＰＵコアの別々の１つにおいて、動き推定を実行するステップであって、前記動き推定が、前記それぞれのインター・フレーム・ピクチャーの複数の組のエレメントについて動き情報を生成する、ステップと、
   前記ビデオをエンコードするステップであって、このエンコードが、前記動き推定事前計算によって生成された前記動き情報に基づいて、前記インター・フレーム・ピクチャーをエンコードすることを含む、ステップと、
   前記エンコードしたビデオを収録した出力圧縮ビデオ・ビット・ストリームを生成するステップと、
   を備えている、方法。
4. 請求項３記載の方法であって、更に、
   徐々に低下するビット・レートで、前記ビデオを1つ又は複数の追加ストリームとしてエンコードするステップを備えており、前記追加ストリームをエンコードする前記ステップが、
   直前の圧縮ビデオ・ビット・ストリームをエンコードすることによって生成された前記動き情報を、後続の圧縮ビデオ・ビット・ストリームのエンコードに受け渡すステップと、
   前記後続の圧縮ビデオ・ビット・ストリームについてのビデオ・エンコーディング・パラメータに基づく条件が満たされているか否か判断するステップと、
   前記条件が満たされている場合、前記後続の圧縮ビデオ・ビット・ストリームをエンコードするステップであって、前記後続の圧縮ビデオ・ビット・ストリームのインター・フレームが、直前の圧縮ビデオ・ビット・ストリームをエンコードすることから受け渡された前記動き情報を用いて、エンコードされる、ステップと、
   前記条件が満たされない場合、前記後続の圧縮ビデオ・ビット・ストリームの再現された基準フレームに基づいて動き推定を実行し、前記後続の圧縮ビデオ・ビット・ストリームをエンコードすることによって、新たな動き情報を生成するステップであって、前記後続の圧縮ビデオ・ビット・ストリームのインター・フレームが、前記新たな動き情報を用いて、エンコードされる、ステップと、
   前記初期および後続の圧縮ビデオ・ストリームを含む出力多ビット・レート・ビデオを生成するステップと、
   を備えている、方法。
5. 請求項４記載の方法において、前記条件が、直前の圧縮ビデオ・ビット・ストリームと後続の圧縮ビデオ・ビット・ストリームとの間においてビデオ解像度が不変のままであることである、方法。
6. 多ビット・レート・ビデオ・ストリーミングのために圧縮ビデオ・ストリームをエンコードするビデオ処理システムであって、
   エンコードしようとする生ビデオ・コンテンツを格納するメモリーと、
   前記生ビデオ・コンテンツを複数の圧縮ビデオ・ストリームとしてエンコードするようにプログラミングされているコンピューター処理手段と、
   を備えており、
   前記圧縮ビデオ・ストリームの前記エンコードが、
   動き推定によって前記生ビデオ・コンテンツのインター・フレーム・ピクチャーをエンコードするために、元の動き情報を生成し、
   前記生ビデオ・コンテンツのインター・フレーム・ピクチャーをエンコードするための前記元の動き情報を用いて、前記生ビデオ・コンテンツから最上位品質の圧縮ビデオ・ビット・ストリームをエンコードし、
   後続の圧縮ビデオ・ビット・ストリームをより低いビット・レートでエンコードするためのビデオ解像度を決定し、
   前記後続の圧縮ビデオ・ビット・ストリームをエンコードするための前記ビデオ解像度が不変である場合、前記生ビデオ・コンテンツのインター・フレーム・ピクチャーをエンコードするための前記元の動き情報を用いて、前記生ビデオ・コンテンツから前記後続の圧縮ビデオ・ビット・ストリームをエンコードし、
   それ以外の場合、前記後続の圧縮ビデオ・ビット・ストリームをエンコードするための前記ビデオ解像度が、前記最上位品質の圧縮ビデオ・ビット・ストリームのそれから変更されている場合、前記後続の圧縮ビデオ・ビット・ストリームのイントラ・フレーム基準ピクチャーに対する動き推定によって、前記生ビデオ・コンテンツのイントラ・フレーム・ピクチャーをエンコードするために新たな動き情報を生成し、前記生ビデオ・コンテンツのインター・フレーム・ピクチャーをエンコードするための前記新たな動き情報を用いて、前記生ビデオ・コンテンツから前記後続の圧縮ビデオ・ビット・ストリームをエンコードする、
   ことを含む、ビデオ処理システム。
7. 請求項６記載のビデオ処理システムにおいて、前記コンピューター処理手段が、多数の処理コアを有するマルチ・コア・コンピューター・プロセッサーであり、前記元の動き情報を生成する際に、前記生ビデオ・コンテンツのイントラ・フレーム・ピクチャーをエンコードするのに先立つ事前計算として、前記生ビデオ・コンテンツのインター・フレーム・ピクチャー群におけるインター・フレーム・ピクチャー毎に、前記処理コアの内別個の１つにおいて動き推定を実行する、ビデオ処理システム。
8. 請求項７記載のビデオ処理システムにおいて、前記生ビデオ・コンテンツのインター・フレーム・ピクチャー群に対して動き推定を実行する際に、
   前記群の各インター・フレーム・ピクチャーを、前記マルチ・コア・コンピューター・プロセッサーの別個の処理コアに割り当て、
   それぞれのインター・フレーム・ピクチャー毎に、その割り当てられた別個の処理コアにおいて動き推定を実行する、
   ことを含む、ビデオ処理システム。

Images