(57)【要約】【課題】  ストリーミングメディアを処理する方法およびシステムを提供する。【解決手段】  本発明にかかる方法は、ストリーミングメディアを受け取ること、利用可能な処理資源およびメモリ資源の配分を決定することとを含む。さらに、本方法は、ストリーミングメディアに対して多段階処理を実行すること、多段階プロセスの中の１つの段階からの中間結果をキャッシングすることとを含む。中間結果は利用可能な処理資源およびメモリ資源に従って選択される。【選択図】図６
2005020729.tif 000002
【特許請求の範囲】
【請求項１】
ストリーミングメディアを処理する方法であって、
前記ストリーミングメディアを受け取ること（６０１）と、
利用可能な処理資源およびメモリ資源の配分を決定すること（６０３）と、
前記ストリーミングメディアに対して多段階処理を実行すること（６０５）と、
前記多段階プロセスの中の１つの段階からの中間結果をキャッシングすること（６０７）であって、前記結果は前記利用可能な処理資源およびメモリ資源に従って選択される中間結果をキャッシングすること（６０７）と
を含むストリーミングメディアを処理する方法。
【請求項２】
前記処理は、演算集約的なメディア処理である
請求項１記載のストリーミングメディアを処理する方法。
【請求項３】
前記資源は、
トランスコーダ、第１のキャッシュおよび第２のキャッシュからなる群から選択される
請求項２記載のストリーミングメディアを処理する方法。
【請求項４】
前記処理は、
トランスコード機能
を含む
請求項１記載のストリーミングメディアを処理する方法。
【請求項５】
前記結果は、最終トランスコード結果である
請求項１記載のストリーミングメディアを処理する方法。
【請求項６】
前記トランスコード機能は、フレームレートの低減、ビットレートの低減および解像度の低減からなる群から選択される
請求項４記載のストリーミングメディアを処理する方法。
【請求項７】
前記キャッシングすることは、
前記ストリーミングメディアの出力ストリームのターゲットビットレートが前記ストリーミングメディアのデータキャッシュレートよりも大きい場合、前記ストリーミングメディアの前記出力ストリームの中間トランスコード結果をキャッシングすること
を含む
請求項１記載のストリーミングメディアを処理する方法。
【請求項８】
前記中間トランスコード結果は、
ピクセル、ブロック、マクロブロック、ピクチャおよびシーケンスからなる群から選択されるメタデータ
を含む請求項７記載のストリーミングメディアを処理する方法。
【請求項９】
前記トランスコード機能は、動きベクトル発生器、ビットレートコントローラ、およびパーサからなる群から選択される資源によって実行される
請求項４記載のストリーミングメディアを処理する方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、包括的にストリーミングメディアに関する。
特に、本発明の実施形態は、ストリーミングメディアを処理する方法およびシステムに関する。
【背景技術】
【０００２】
ストリーミングメディアの処理には、記憶資源および演算資源両方を消費する必要がある。
こういった資源に固有の制約により、処理プロセスにおけるボトルネックは確実に、これら制約がシステム資源の適宜配分によって調停されない限り緩和されない。
システム資源の制約は、システム資源の誤った配分に起因する非効率性によって悪化する。
これら非効率性によって助長されるボトルネックは、ストリーミングメディア処理システムの演算資源および記憶資源への過負荷および全体のパフォーマンスの悪化を助長する役割を果たす恐れがある。
【０００３】
従来のシステムは、上記処理プロセスボトルネック問題を克服しない。
実際、多くの従来のシステムは、問題を悪化させる可能性のある処理システムの出力からとられる完全に処理済みのデータのキャッシングに的を絞っている。
容易に認められるように、このように完全に処理済みのデータのキャッシングは、記憶資源に対して深刻な負荷をかける。
これは、このような方法が過度の量のシステム記憶資源を消費し、それによって、それ以降の処理を行うのに必要な演算資源の消費が減るためである。
しかし、記憶資源のこのような誤った配分に由来する記憶可用性の欠如に起因するボトルネックは蔓延している。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
データの処理および送出を行う従来システムの主な欠点は、一種のシステム資源に対する緊張が、別種のシステム資源が豊富に存在するのと同時に過度に伸張されることである。
このようなメディア処理の誤った配分に起因する非効率性は、システムパフォーマンスを劣化させるボトルネックを助長する。
【課題を解決するための手段】
【０００５】
ストリーミングメディアを処理する方法およびシステムが開示される。
一実施形態において、本方法は、ストリーミングメディアを受け取ること、利用可能な処理資源およびメモリ資源の配分を決定することとを含む。
さらに、本方法は、ストリーミングメディアに対して多段階処理を実行すること、多段階プロセスの中の１つの段階からの中間結果をキャッシングすることとを含む。
中間結果は利用可能な処理資源およびメモリ資源に従って選択される。
【０００６】
本明細書に組み込まれて本明細書の一部をなす添付図面は、本発明の実施形態を示し、説明とともに本発明の原理を説明する役割を果たす。
【発明を実施するための最良の形態】
【０００７】
これより、例を添付図面に示す本発明の実施形態を詳細に参照する。
本発明についてこれら実施形態と併せて説明するが、本発明をこれら実施形態に限定する意図がないことを理解されたい。
反対に、本発明は、添付の特許請求の範囲によって規定される本発明の精神および範囲内に包含し得る代替形態、変更形態、および同等物を保護範囲に含むことを意図する。
さらに、以下の本発明の詳細な説明では、本発明の完全な理解を提供するために多くの特定の詳細が述べられる。
しかし、本発明はこれら特定の詳細なしでも実施し得ることが当業者に認められよう。
一方、既知の方法、手順、構成要素、および回路については、本発明の態様を不必要に曖昧にしないように詳細に説明しなかった。
【０００８】
［発明の実施形態による例示的なシステム］
図１Ａは、本発明の一実施形態によるトランスコードシステムの機能ブロック図１００である。
機能ブロックは、図示および考察を明確にするために、図１において別個に示されていることが理解される。
しかし、これらブロックは、別個の要素として存在しなくてもよく、実用では、１つの装置または複数の装置として具現し得る。
一般に、本発明のトランスコードシステムは、これから説明する機能を提供する１つまたは複数（の装置）を含むことができる。
【０００９】
本発明の実施形態は、データ（たとえば、ストリーミングメディアデータ）の処理およびデータ（たとえば、ストリーミングメディアデータ）の記憶に配分されるシステム資源間の最適なバランスを見つけることによって、システム動作を最適化する。
図１は、入力ストリーム１０１、メタトランスコーダ１０３、出力ストリーム１０５、資源バランサ１０７、メタキャッシュ１０９、正規のキャッシュ１１１、メタデータ１１３、オリジナルコンテンツサーバ１１５、およびクライアント装置（複数可）１１７を示す。
【００１０】
入力ストリーム１０１は、クライアント装置１１７（たとえば、ラップトップ、デスクトップ、ＰＤＡ、携帯電話等）に送出することができるストリーミングメディアを搬送する。
一実施形態によれば、入力ストリーム１０１は、システム資源を最適化する様式でトランスコーダ１０３によってトランスコーディングされる。
一実施形態によれば、入力ストリーム１０１はコンテンツサーバ１１５（たとえば、ビデオコンテンツプロバイダ等）によって供給される。
他の実施形態によれば、入力ストリームは他のソース（たとえば、ローカル記憶媒体、リモート記憶媒体）から提供される。
【００１１】
メタトランスコーダ（たとえば、１０３）は、前のトランスコードセッションにおいて生成されキャッシングされたメタデータを現在のトランスコードセッションに採用するトランスコーダである。
さらに、メタトランスコーダは、現在のセッションにおいて、それ以降の同様のトランスコードセッションに使用されるメタデータを生成することができる。
一実施形態によれば、本発明のメタトランスコーダ１０３は、メタデータ（メタキャッシュ１０９から検索される中間トランスコードデータ）およびデータ全体（たとえば、コンテンツサーバ１１５によって供給されるものなど）を両方とも入力として受け取ることができることに留意されたい。
【００１２】
一実施形態では、メタトランスコーダ１０３は、入力ストリーム１０１を提供するオリジナルコンテンツサーバ１１５と、出力ストリーム１０５を供給することができるクライアント１１７のグループとの間に配置される。
メタトランスコーダ１０３は、メタキャッシュ１０９および正規のキャッシュ１１１に回復することができるキャッシュを備える。
処理されるデータは、トランスコーディングの最終結果および「メタデータ」１１３と呼ばれるトランスコーディングの中間結果の両方からなることができる。
これらデータ構成要素それぞれの最適な使用が、システムパフォーマンスの最適化につながり得る。
【００１３】
メタトランスコーダ１０３によって実行されるトランスコーディングは、多段階プロセスである。
プロセスの１つの段階の結果は通常、少なくとも他の１つの段階への入力として使用される。
本明細書において使用する「中間結果」は、トランスコーディングの最終段階前の各種段階の出力前の各種段階の出力を指し、「最終結果」は、すべての段階を完了したデータを指す。
【００１４】
メタキャッシュ１０９は、メタデータ１１３のキャッシングに使用される。
メタデータ１１３は、トランスコードプロセスの中間結果と定義することができる。
メタキャッシュ１０９は、中間トランスコード結果を表すメタデータ１１３をキャッシングする。
たとえば、データがａ、ｂ、およびｃを加算することによってトランスコーディングされて「Ｘ」を得る場合を考える。
中間結果ａ＋ｂをメタデータ（たとえば、１１３）とみなすことができる。
【００１５】
ａ＋ｂをメタトランスコーダ１０３にキャッシングするという決定を行うこともできる。
したがって、「Ｘ」を得るための後続のトランスコーディングで必要なのは、２つ（たとえば、ａ＋ｂの加算、そしてこれにｃを加算）ではなく１つの追加処理ステップ（たとえば、ａ＋ｂへの加算）のみである。
分かるように、これは、処理の節約によりａ＋ｂの格納に追加のキャッシュ空間の使用が保証される場合に有利である。
本発明は、各種実施形態において、メタトランスコーダが利用できる処理資源および記憶資源の最適なバランスを実現する。
【００１６】
正規のキャッシュ１１１は、トランスコードプロセスの最終結果のキャッシングに使用される。
一実施形態によれば、これら結果は、キャッシングに消費する記憶空間が中間結果よりも少ない場合に格納することができる。
本実施形態によれば、本発明は、従来のシステムによって提供される単一レベルではなく複数レベルのキャッシュを導入する。
【００１７】
本実施形態では、資源バランサ１０７がキャッシュ資源と処理資源との間の配分を指示する。
資源バランサは、キャッシュ資源よりも多いまたは少ないトランスコード（処理）資源を採用することができるか否かを決定する。
中間トランスコード結果であれ、最終トランスコード結果であれ、いずれもキャッシングすることができる。
資源バランサ１０７は、利用可能なキャッシュ空間および利用可能な演算サイクル等の要因に基づいて決定を行う。
一般に、システムが十分なアイドル演算サイクルを有するが十分なキャッシュ空間を有していない場合、最終トランスコード結果ではなく中間トランスコード結果（たとえば、メタデータ）をキャッシングすることができる。
これとは反対に、システムが十分なキャッシュ空間を有するが十分な演算サイクルを有していない場合、中間結果（たとえば、メタデータ）ではなく最終結果をキャッシングすることができる。
【００１８】
一実施形態によれば、メタトランスコーディングはメタデータに基づくトランスコーディングと定義される。
現在のトランスコードセッション中、トランスコーダはメタデータを生成することができ、そこから、続けて行われ得る同様のトランスコードセッション中に恩恵を受け得ることを理解されたい。
さらに、トランスコードセッション中、トランスコーダは、前のトランスコードセッションにおいて生成されたメタデータの恩恵を受けることができる。
【００１９】
図１Ｂは、本発明の一実施形態による例示的なトランスコーダ構造のブロック図である。
トランスコードセッションは複数の離散したトランスコード段階（たとえば、図１Ｂ中の段階１〜段階Ｎとして示す）を含むことができ、それぞれトランスコード完了の中間（非最終）段階に存在するメタデータを出力することを理解されたい。
一実施形態によれば、任意のトランスコーダ段階それぞれから出力されるメタデータは、後続の同様のトランスコードセッションにおいてそれ以降に使用するためにキャッシングすることができる。
例示的な実施形態によれば、メタデータがキャッシングされるトランスコードプロセス段階は、最も有利な演算と記憶のバランスを提供するものが選択されることを理解されたい。
図１Ｂは、入力ストリーム１０１、メタトランスコーダ１０３、出力ストリーム１０５、および出力１〜出力Ｎと示された出力を有する（図１Ｂ参照）トランスコード段階１〜Ｎを示す。
【００２０】
図１Ｂを参照すると、入力ストリーム１０１はオリジナルコンテンツサーバからメタトランスコーダ１０３に供給される。
図１Ｂに示すように、ストリーミングビデオは、最終トランスコード結果の出力ストリーム１０５が生成される（たとえば、クライアント装置に供給するためなどに）までにＮ個のトランスコーダ段階（たとえば、図１Ｂには段階１〜段階Ｎと示される）を通過しなければならない。
各トランスコーダ段階のいずれの出力も（たとえば、図１Ｂでは出力１〜出力Ｎと示される）キャッシングし、メタトランスコーダへの入力として使用することができ、それによってそれ以降の同様のセッションにおける演算負荷が低減することを理解されたい。
しかし、メタデータが実際にキャッシングされる段階は、最も有利な演算と記憶のバランスを提供するものが選択される。
【００２１】
［キャッシングするメタデータの様々なレベル］
一実施形態によれば、キャッシングするメタデータ（たとえば、１１３）の選択には、トランスコードセッションの処理ボトルネックを考慮に入れる必要がある。
文脈として、圧縮されたＭＰＥＧ（モーションピクチャエキスパートグループ）ビデオストリームに対するビデオトランスコーディングを使用して、以下の図２を参照して行う考察において、これをどのように実現することができるかについて説明する。
図２は、本発明の一実施形態によりシーケンスレベルからピクセルレベルにキャッシングすることができる５つの中間レベルのメタデータの間の関係を示すグラフ２００である。
図２は、「キャッシュヌル」２０１、「キャッシュフル」２１３、演算軸２０５、記憶軸２０７、シーケンス２０９、ピクチャ２１２、マクロブロック２１５、ブロック２１７、およびピクセル２１９を示す。
【００２２】
本発明の一実施形態によれば、図２に示す配分法に従ってトランスコードセッション中に得ることができる空間レベルは２つある。
すなわち、（１）「キャッシュヌル」２０１、および（２）「キャッシュフル」２１３である。
「キャッシュヌル」２０１レベルは、最終結果も、また図２に示す５つのレベルのいずれも、トランスコード中の特定のビデオストリーム部分にキャッシングされない場合に得られる。
「キャッシュヌル」２０１の場合、ヌルキャッシュをもたらしたトランスコードセッション中に生成されたデータに対してそれ以降に要求がある場合、処理システムは、使用可能な最終結果も、またメタデータもキャッシングされていないため、１００％の演算資源を要し得る新しいトランスコードセッションを開始する。
しかし、新しいトランスコードセッションでは、必要とされる記憶資源は０％である。
これは、前のトランスコードセッション中に、この空間を占有するものが何もキャッシングされなかったためである。
【００２３】
「キャッシュフル」２１３レベルは、トランスコードセッションの最終結果がキャッシングされる場合に得られる。
「キャッシュフル」２１３の場合、フルキャッシュをもたらしたトランスコードセッション中に生成されたデータに対してそれ以降に要求がある場合、トランスコーダは、キャッシュ記憶装置がフルであるため、１００％の記憶資源を要し得る新しいトランスコードセッションを開始することができる。
しかし、新しいトランスコードセッションに必要な演算資源は０％であり、これは、前のトランスコードセッション中にキャッシングされた最終トランスコード結果を利用することができるためである。
【００２４】
シーケンスレベル２０９メタデータは、ヘッダ情報、フレーム総数等を含むことができるが、これらに限定されない。
一般に、シーケンスレベル２０９メタデータは、ビデオストリームのセグメント全体の全体的な特徴を記述し、通常、限られた量の記憶空間を占める。
一実施形態によれば、システムが中間データをシーケンスレベル２０９にキャッシングする場合、このデータに対するそれ以降の要求に応答してトランスコーディングの完了に必要な演算資源は、「キャッシュヌル」２０１の場合と比較して少ない。
【００２５】
トランスコードセッションが開始されると、ＣＰＵ（中央演算処理装置）に対する負荷は、シーケンスレベル２０９メタデータ等、キャッシングされた中間メタデータを使用することによって低減することができる。
たとえば、キャッシングされたシーケンスレベル２０９メタデータを使用することにより、ビデオの初期部分をパーズしてそこに提供される情報を得る必要なく、新しいトランスコードセッションを実行することができ、初期化プロセスの簡易化につながる。
さらに、使用されるキャッシング資源も低減される。
【００２６】
図２に示す中間データレベルをピクチャレベルメタデータ２１２からピクセルレベルメタデータ２１９に通過するとき、トランスコードプロセスに関わるシステム記憶資源の量は、ポイントに位置するメタデータが記憶軸２０７に沿って達する縦方向の大きさが大きくなるにつれて増大し得る。
しかし、関わる記憶資源の量は、処理資源の利用が多くなるにつれて低減していく。
【００２７】
図２に示す中間データレベルをピクセルレベルメタデータ２１９からピクチャレベルメタデータ２１２に通過するとき、トランスコードプロセスに必要なシステム演算資源の量は、ポイントに位置するメタデータ（たとえば、１１３）が演算軸２０５に沿って達する横方向の大きさが大きくなるにつれて増大し得る。
しかし、必要な演算資源の量は一般に、キャッシング資源の利用が多くなるにつれて低減していく。
【００２８】
一実施形態において上に述べたように、本発明は、従来のキャッシングシステムによって提供される１つのレベルではなく、いくつかのキャッシングレベルを提供する。
本発明の実施形態は、提供される様々なキャッシングレベルを利用し、資源の配分を適応的に調整する。
たとえば、同じトランスコード処理に対して複数の要求がある状況に応答して、システムは、より多くのメタデータ（または演算要件が低いメタデータ）を格納するよう選択することにより、または極端な場合では、最終結果−出力ストリーム（たとえば、１０５）をキャッシングすることによって適応的に応答することができる。
こうして促進される細かい粒度により、処理プラットフォーム上で利用可能なすべての資源（たとえば、演算および記憶）をより効率的に利用することができる。
【００２９】
図２に示すように、本発明の一実施形態によるストリーミングメディア（たとえば、ビデオ、テキスト、スピーチ等）トランスコードシステムをサポートするために、いくつかの種類の中間データ（たとえば、メタデータ）が、キャッシングの際に識別される。
これらの種類の中間データのキャッシングにより、以下述べる記憶と演算の良好なトレードオフの実現を容易にすることができる。
【００３０】
［フレームレート低減のメタキャッシング］
図３は、本発明の一実施形態による、ＭＰＥＧビデオストリームに対してフレームレート低減トランスコーディングを実行するシステムに採用される機能ブロックを示すブロック図３００である。
一実施形態によれば、フレームレートの低減は、フレームドロップ等の対策を採用することによって実現することができる。
たとえば、２／３のフレームレート低減は、ＧＯＰ（ピクチャグループ）構造ＩＢＢＰＢＢＰＢＢを有するＭＰＥＧビデオストリーム中の「Ｂ」ピクチャを落とすことによって実現される。
フレームを「通す」かそれとも「落とす」かについての決定に関わるメタデータをキャッシングすることにより、図１のメタトランスコーダ１０３にかかる演算負荷は、このキャッシングデータにアクセスする後続のトランスコードセッションにおいて低減される。
図３は、入力ビデオストリーム３０１、パーサ３０３、フレームレートコントローラ３０７、出力ビデオストリーム３０５、およびメタキャッシュ３０９を示す。
さらに、図３は、本発明の図３の実施形態のメタトランスコーダ（たとえば、１０３）の構成要素（たとえば、３０３および３０７）の周囲に線を描いた破線３１１の図を示す。
【００３１】
本発明の実施形態は、図３に示すビデオストリームパーズ機能ブロック３０３に存在し得るＭＰＥＧビデオストリームトランスコードプロセスにおけるボトルネックを軽減する。
一実施形態によれば、パーズ機能の目的は、ピクチャタイプおよび各フレームに関連するバイト境界データを確認することである。
この情報はフレームレートコントローラ３０７に供給され、特定のフレームを「通す」かそれとも「落とす」かを判断する際に使用することができる。
先に触れたように、フレームを「通す」かそれとも「落とす」かの判断に関わるメタデータをキャッシングすることにより、このデータが使用される後続のトランスコードセッションにおいて、メタトランスコーダに対する演算負荷が低減する。
【００３２】
一実施形態によれば、フレームレート低減トランスコーディングの場合、フレームレートｆｆｐｓ（たとえば、フレーム／秒）を有する入力ストリームが与えられる場合、メタデータのデータキャッシングのデータレートしきい値は、以下のように計算される。
Ｒ＝４０ｆビット／秒
【００３３】
上記式は、以下のように導き出される。
キャッシングビットレートは、ピクチャタイプ（たとえば、Ｉ、Ｂ、またはＰ）の記録に２ビット、およびピクチャ境界のバイトオフセットの記録に３８ビット（組み合わせて５バイト、すなわち４０ビット）を使用して計算することができる。
２ビットは４つのピクチャタイプを記録するに十分であり、３８ビットは最大で５１２ＧＢ（たとえば、ギガバイト）サイズのメディアファイルにおけるオフセットを記録するに十分であることを理解されたい。
これは、現在利用可能なメディアファイルのタイプのすべてではなくともその大半をカバーするのに十分すぎると予期される。
【００３４】
本明細書における考察では、Ｒは「キャッシングレートしきい値」を指す。
一実施形態では、出力ストリームのターゲットビットレートがＲよりも小さい場合、最終トランスコード結果（たとえば、「キャッシュフル」２１３）は、中間結果（たとえば、キャッシュメタ）とは対照的にキャッシングされる。
これは、メタデータのキャッシングに必要なデータレートがしきい値「Ｒ」を満たさないためである。
一実施形態によれば、資源バランサ（たとえば、１０７）が採用されて、最終トランスコード結果がキャッシングされるか、それとも中間トランスコード結果がキャッシングされるかが決定される。
【００３５】
以下の例に、フレームレート３０ｆｐｓを有するビデオストリーム３０１に関してこれを示す。
上に提供した式（たとえば、Ｒ＝４０ｆビット／秒）を使用すると、キャッシングビットレートは４０＊３０＝１２００ビット／秒（たとえば、１．２キロビット／秒）と計算することができる。
したがって、出力ストリーム３０５のターゲットビットレートがＲよりも小さい場合、メタキャッシュ（たとえば、３０９）へのキャッシングではなく「キャッシュフル」を選択すべきである。
上で参照した式中の定数「４０」は、ＭＰＥＧビデオストリームが処理されている場合用に特別に導出されたものであることを理解されたい。
他の場合（たとえば、テキストからスピーチ、スピーチからテキストへのトランスコーディング等）では、他の定数を導出することができる。
【００３６】
１メガバイト／秒のビデオを約１Ｋｂｐｓのレートでキャッシングすることができるため、必要な記憶資源は１０００分の１に低減することができる。
さらに、ピクチャのタイプおよび関連するバイトオフセットはここではメタキャッシュ３０９において容易に利用することができるため、メタトランスコーダは、パーサ３０３なしで、後続の同じ種類のトランスコード要求を容易に処理することができる。
したがって、メタトランスコーダにかかる演算負荷が大幅に低減する。
【００３７】
キャッシングされたピクチャタイプおよびバイト境界メタデータは、図２に示すグラフに表されるメタデータスキームのピクチャレベルで見つけられる。
したがって、シーケンスレベル（たとえば、２０９）にあるメタデータと比較して、このようなメタデータをキャッシングするにあたってより多くの記憶資源が使用され得るが、それ以降のトランスコード（たとえば、処理）セッションに必要な演算資源は大幅に低減することになる。
【００３８】
要約すると、一実施形態では、フレームレートｆｆｔｐを有する入力ストリーム（たとえば、３０１）が与えられる場合、ピクチャタイプおよびバイト境界メタデータのキャッシングに必要なデータレートはＲ＝４０ｆビット／秒である。
フレームレートの低減は通常、ビットレートの低減につながる。
出力ストリーム３０５のターゲットビットレートがＲよりも小さい場合、メタキャッシュ（たとえば、３０９）へのキャッシングではなく「キャッシュフル」が選択される。
【００３９】
［ビットレート低減トランスコーディングのメタキャッシング］
図４は、本発明の一実施形態による、ＭＰＥＧビデオストリームに対してビットレート低減トランスコーディングを実行するシステムに採用される機能ブロックを示すブロック図４００である。
一実施形態によれば、出力ストリーム（たとえば、４０９）のビットレートのみが、ビットレート低減トランスコーディングのために低減される。
一実施形態によれば、トランスコードビデオ信号のビデオフレームレートおよびビデオフレーム解像度等のパラメータが、ビットレート低減トランスコーディングのために一定レベルに維持される。
さらに、図４は、本発明の図４の実施形態のメタトランスコーダ（たとえば、１０３）の構成要素（例えば、４０３、４０５、４０７、および４１１）の周囲に線を描いた破線４１５の図を示す。
【００４０】
ビットレート低減を実現する１つの方法は、変換領域係数の再量子化を通してのものである。
考え得る従来のプロセスにはいくつかのボトルネックがあるが、再量子化係数（Ｍｑｕａｎｔ）のキャッシングは、記憶資源の使用と演算資源の使用の間の良好なトレードオフを実現する。
再量子化係数は、最終トランスコード結果よりもキャッシングが容易な中間トランスコード結果である。
一実施形態によれば、この中間トランスコード結果のキャッシングにより、このようなデータを再生する必要なく、それ以降のトランスコードセッションを実行することが可能になる。
図４は、入力ビデオストリーム４０１、ＶＬＣ（可変長コード）デコーダ４０３、逆量子化４０５、量子化４０７、ビットレートコントローラ４１１、メタキャッシュ４１３、および出力ストリーム４０９を示す。
【００４１】
一実施形態によれば、メタキャッシュ４１３は、再量子化係数（Ｍｑｕａｎｔ）を格納するため、再量子化係数をビットレートコントローラ４１１によって生成する必要なく、メタキャッシュ４１３から得ることができる。
キャッシングされたＭｑｕａｎｔデータは、それ以降のトランスコードセッションをスピードアップする役割を果たすことができる。
これは、このようなそれ以降のトランスコードセッション中にこのデータを生成する必要であった処理を報告する必要がないためである。
先に触れたように、中間トランスコード結果は、メモリ消費と残りの処理量の間のトレードオフに応じてキャッシングされる。
【００４２】
一実施形態によれば、ビットレートトランスコーディングの場合、解像度ｗ×ｈおよびフレームレートｆｆｐｓを有する入力ストリーム（たとえば、４０１）が与えられる場合、メタデータのデータキャッシングのデータレートしきい値は、以下のように計算される。
Ｒ＝ｗｈｆ／３２ｂｐｓ（ビット／秒）
【００４３】
出力ストリーム４０９のターゲットビットレートがＲよりも小さい場合、中間結果（たとえば、メタキャッシュにおけるキャッシュ）ではなく最終トランスコード結果（たとえば、キャッシュフル）をキャッシングすべきである。
これは、最終結果のキャッシングが同じくらい容易に対応することができる（たとえば、メタデータのキャッシングに必要なデータレートがしきい値「Ｒ」を満たさない）ためである。
一実施形態によれば、資源バランサ（たとえば、１０７）が採用されて、最終トランスコード結果をキャッシングするか、それとも中間トランスコード結果をキャッシングするかが決定される。
【００４４】
以下の例にこのポイントを示す。
一実施形態によれば、３０秒の３５２×２８８、３０ｆｐｓのビデオクリップの場合、Ｍｑｕａｎｔデータの格納に必要なキャッシュのサイズは３５６４００バイトになり、Ｍｑｕａｎｔメタデータのキャッシングに必要なデータレートは９５０４０ｂｐｓになる（たとえば、毎秒９５０４０ビットのＭｑｕａｎｔデータがキャッシングされる）。
したがって、ターゲットビットレートが９５Ｋｂｐｓ以上の場合、Ｍｑｕａｎｔメタデータは、このようなメタデータをキャッシングしたほうが有利なため（たとえば、メタデータのキャッシングを促進するのに必要なデータレートが存在し、データにより、それ以降の同様のトランスコードセッションのスピードアップが図られる）、キャッシングされることになる。
しかし、ターゲットビットレートが９５Ｋｂｐｓ未満の場合、Ｍｑｕａｎｔメタデータをキャッシングしないほうが有利である。
これは、最終トランスコード結果のキャッシングに同じくらい容易に対応することができる（たとえば、ターゲットデータレートがＭｑｕａｎｔメタデータのキャッシングに必要なデータレートよりも低い）ためである。
さらに、ランレングス符号化を使用して、後でＭｑｕａｎｔデータを圧縮する、または記憶空間の半分のバイトを個々のＭｑｕａｎｔデータに使用する（それにより、必要な空間が半分だけになる）等、キャッシュ空間の節約に他のキャッシュ記憶空間節約技法を採用してもよい。
キャッシングされるメタデータは、図２に示すグラフの（ＭＰＥＧの場合、１６×１６サイズの）マクロブロックレベル２１５にあることを理解されたい。
【００４５】
要約すると、一実施形態では、解像度ｗ×ｈおよびフレームレートｆｆｐｓを有する出力ビデオストリーム４０１が与えられる場合、再量子化メタデータのキャッシングに必要なデータレートは、Ｒ＝ｗｈｆ／３２ビット／秒である。
出力ストリームのターゲットビットレートがＲよりも小さい場合、「キャッシュメタ」４１３ではなく「キャッシュフル」（たとえば、２１３）が選択される。
【００４６】
図４に示す他の構造（たとえば、ＶＬＣデコーダ４０３、逆量子化４０５、量子化４０７機能ブロック）は、ビデオ処理分野において既知の構成要素であり、本明細書においてこれ以上説明しない。
【００４７】
解像度低減トランスコーディングのメタキャッシング
図５は、本発明の一実施形態による、ＭＰＥＧビデオストリームに対して空間または解像度低減トランスコーディングを実行するシステムに採用される機能ブロックを示すブロック図５００である。
空間解像度の低減は、各フレームの解像度を低減し、その結果をより低いビットレートでコーディングすることによって実現することが可能である。
従来のプロセスにはいくつかのボトルネックが存在し得るが、動き情報および再量子化係数のキャッシングにより、記憶資源と演算資源の間の良好なトレードオフが実現される。
図５は、入力ストリーム５０１、動きベクトル発生器５０７、レート制御モジュール５２１、出力ストリーム５２３、動きベクトル（５２９および５３１）およびメタキャッシュ５２７を示す。
さらに、図５は、本発明の図５の実施形態のメタトランスコーダ（たとえば、１０３）の構成要素（たとえば、図５において破線５３７によって囲まれている構成要素を参照）の周囲に線を描いた破線５３７の図を示す。
【００４８】
空間解像度低減トランスコードプロセスでは、多くの演算集約的なブロックがあり得ることを理解されたい。
しかし、一実施形態によれば、２つの機能ブロック、すなわち、動きベクトル発生器５０７およびレート制御モジュール５２１が、メタキャッシングを適用して良好な記憶と演算とのトレードオフを実現することができる、トランスコードプロセスにおけるポイントとして識別されている。
【００４９】
ビデオ符号化プロセスでは、動きベクトル（５２９および５３１）の生成が、演算集約的な作業である。
一実施形態によれば、動きベクトル発生器５０７のトランスコード結果をキャッシングすることにより（出力ストリーム５２３ではなく中間結果）、後続の同様の処理（たとえば、トランスコードセッション）に対する要求に、より少ない演算で応えることができる。
【００５０】
一実施形態によれば、空間解像度低減トランスコーディングの場合、解像度ｗ×ｈおよびフレームレートｆｆｐｓ、ＧＯＰサイズｎを有する入力ストリームが与えられる場合、メタデータのデータキャッシングのデータレートしきい値は、以下のように計算される。
Ｒ＝ｗｈｆ（ｎ−１）／８ｎ（ビット／秒）
【００５１】
出力ストリーム５２３のターゲットビットレートがＲよりも小さい場合、中間結果（たとえば、キャッシュメタ５２７）ではなく最終トランスコード結果（たとえば、「キャッシュフル」２１３）をキャッシングすべきである。
これは、最終結果のキャッシングが同じくらい容易に対応することができる（たとえば、メタデータのキャッシングに必要なデータレートが存在しない）ためである。
一実施形態によれば、資源バランサ（たとえば、１０７）が採用されて、最終トランスコード結果をキャッシングするか、それとも中間トランスコード結果をキャッシングするかが決定される。
【００５２】
以下の例にこのポイントを示す。
ＭＰＥＧ標準によれば、ピクチャ間にあるマクロブロックには、最大で４つの動きベクトル（たとえば、５２９、５３１）が関連付けられる。
各動きベクトルは１バイトで表すことが可能である。
出力ストリーム５２３が、ビットレート１Ｍｂｐｓおよびフレームレート３０ｆｐｓを有するサイズ３５２×２４０の典型的なウェブビデオであると仮定すると、メタデータのキャッシングに必要なデータレートは２＊１４＊３３０＊４＊８＝２８８Ｋｂｐｓであり、これは最終結果のキャッシングに必要なレートの３分の１に近い。
【００５３】
したがって、２８８Ｋｂｐｓ以上のターゲットビットレートの場合、動きベクトルメタデータはキャッシングされる。
これは、このようなメタデータのキャッシングがそれ以降の同様のセッションに有利であるためである（たとえば、メタデータのキャッシングの促進に必要なデータレートが存在し、そのデータにより、それ以降の同様のトランスコードセッションのスピードアップが図られる）。
しかし、２８８Ｋｂｐｓ以下のターゲットビットレートの場合、動きベクトルメタデータのキャッシングは有利ではない可能性がある。
これは、このような場合、最終トランスコード結果のキャッシングに同じくらい容易に対応することができるためである（たとえば、ターゲットデータレートが、動きベクトルメタデータのキャッシングに必要なデータレートよりも低い）。
【００５４】
キャッシングされた動きベクトルメタデータは、図２に示す（ＭＰＥＧの場合、１６×１６の）マクロブロックレベル２１５にあることを理解されたい。
したがって、キャッシングし得る他のレベルのメタデータ（たとえば、ピクチャ、シーケンス）と比較してより多くの記憶資源を使用し得るが、それ以降の要求の処理に必要な演算資源は少なくなる。
他の事項として、空間解像度低減トランスコーディングのパフォーマンスは通常、ビットレートの低減につながることに留意されたい。
【００５５】
一実施形態によれば、レート制御モジュール５２１からの中間トランスコード結果は、空間解像度低減トランスコーディングの一貫として、図４を参照して上述したビットレート低減トランスコーディングの文脈の中で行われた方法と同様の方法でキャッシングすることができる。
これら結果のキャッシングにより、すでに生成されキャッシングされている量子化係数を再生成する必要をなくすことができる。
図４を参照して考察したものと同じ解析がこの文脈にも当てはまることを理解されたい。
【００５６】
要約すると、一実施形態では、解像度ｗ×ｈ、フレームレートｆｆｐｓ、およびＧＯＰサイズｎを有する出力ビデオストリーム５２３が与えられる場合、動きベクトルメタデータ（たとえば、５２９）のキャッシングに必要なデータレートは、Ｒ＝ｗｈｆ（ｎ−１）／８ｎビット／秒である。
出力ストリーム５２３のターゲットビットレートがＲよりも小さい場合、「キャッシュメタ」５２７ではなく「キャッシュフル」（たとえば、２１３）が選択される。
【００５７】
図５に示す他の構造（たとえば、ＶＬＣデコーダ５０３、逆量子化５０５、量子化５１７、ＶＬＣエンコーダ５１９、順方向量子化器（forward quantizer）５１７、ＦＤＣＴ（高速離散コサイン変換）５１５、ＩＤＣＴ（逆離散コサイン変換）５０７、動き補償５０９および５１３、ダウンサンプリング５１１、ならびにフレームバッファ５３３および５３５機能ブロック）は、ビデオ処理技術分野において既知の構成要素であり、本明細書においてこれ以上説明しない。
【００５８】
［本発明の実施形態による動作例］
図６は、本発明の一実施形態によるストリーミングメディアを処理するコンピュータ制御方法を表すフローチャート６００を示す。
フローチャート６００は、一実施形態では、コンピュータ可読かつコンピュータ実行可能な命令の制御下でプロセッサおよび電子構成要素によって実行されるプロセスを含む。
コンピュータ可読かつコンピュータ実行可能な命令は、たとえば、コンピュータ使用可能な揮発性メモリおよび／またはコンピュータ使用可能な不揮発性メモリ等、データ記憶機構に常駐する。
しかし、コンピュータ可読かつコンピュータ実行可能な命令は、あらゆるタイプのコンピュータ可読媒体に常駐してよい。
特定のステップがフローチャートに開示されるが、このようなステップは例示である。
すなわち、本発明は、他の様々なステップまたはフローチャートに記されたステップの変形形態の実行に適している。
本実施形態内では、フローチャートのステップはソフトウェア、ハードウェア、またはこれら両方の組み合わせによって実行し得ることを理解されたい。
【００５９】
ステップ６０１において、ストリーミングデータ入力を受け取る。
入力データはリモートサーバ、ローカル記憶媒体、リモート記憶媒体等から供給し得ることを理解されたい。
【００６０】
ステップ６０３において、利用可能な処理資源およびメモリ資源の配分が決定される。
一実施形態によれば、資源の配分は、利用可能なキャッシュ空間および利用可能な演算サイクルに基づく。
キャッシュ空間は中間トランスコード結果（たとえば、メタデータ）に、または最終トランスコード結果に配分可能なことを理解されたい。
【００６１】
ステップ６０５において、ステップ６０１において受け取ったデータに対して、ステップ６０３において決定された資源配分に基づいて、多段階処理が実行される。
一実施形態によれば、実行される処理は、ビデオトランスコーディング、テキストからスピーチへのトランスコーディング、およびスピーチからテキストへのトランスコーディングを含むことができるがこれらに限定されない。
【００６２】
ステップ６０７において、上記多段階プロセスの１つの段階からの中間結果がキャッシングされる。
中間結果は、利用可能な処理資源およびメモリ資源に従って選択される。
一実施形態によれば、中間結果のキャッシングは、ストリーミングデータ出力のターゲットビットレートがレートしきい値を満たしていることに依存し得ることに留意されたい。
一実施形態によれば、このしきい値はキャッシングビットレートしきい値「Ｒ」である。
このしきい値が満たされると、資源配分を、一実施形態によれば、資源バランサによって決定することができる。
【００６３】
本発明の例示的な実施形態を参照して上述されるように、本発明は、ストリーミングメディアを処理する方法およびシステムを提供する。
本方法は、ストリーミングメディアを受け取ること、利用可能な処理資源およびメモリ資源の配分を決定することとを含む。
さらに、本方法は、ストリーミングメディアに対して多段階処理を実行すること、多段階プロセスの中の１つの段階からの中間結果をキャッシングすることとを含む。
中間結果は利用可能な処理資源およびメモリ資源に従って選択される。
【００６４】
本発明の特定の実施形態についての上記説明は、図示および説明を目的として提示されたものである。
網羅的である、すなわち本発明を開示した厳密な形態に限定する意図はなく、明らかに、上記教示を鑑みて多くの変更形態および変形形態が可能である。
実施形態は、本発明の原理およびその実際の応用を最良に説明するように選択され説明され、それによって、当業者が、考えられる特定の用途に適した各種変更によって本発明および各種実施形態を最良に利用することができる。
本発明の範囲は添付の特許請求の範囲およびその等価物によって規定されることを意図する。
【図面の簡単な説明】
【００６５】
【図１Ａ】本発明の一実施形態によるトランスコードシステムの機能ブロック図である。
【図１Ｂ】本発明の一実施形態による例示的なトランスコーダ構造のブロック図である。
【図２】本発明の一実施形態によるシーケンスレベルからピクセルレベルにキャッシングすることができるメタデータの５つの中間レベル間の演算と記憶との間のトレードオフを示すグラフである。
【図３】本発明の一実施形態によるＭＰＥＧ（モーションピクチャエキスパートグループ）ビデオストリームに対してフレームレート低減トランスコーディングを実行するシステムに採用される機能ブロックを示すブロック図である。
【図４】本発明の一実施形態による、ＭＰＥＧビデオストリームに対してビットレート低減トランスコーディングを実行するシステムに採用される機能ブロックを示すブロック図である。
【図５】本発明の一実施形態による、ＭＰＥＧビデオストリームに対して空間解像度低減トランスコーディングを実行するシステムに採用される機能ブロックを示すブロック図である。
【図６】本発明の一実施形態によるストリーミングメディアを処理するコンピュータ制御方法を表すフローチャートを示す。
【符号の説明】
【００６６】
１０１・・・入力ストリーム、
１０３・・・メタトランスコーダ、
１０５・・・出力ストリーム、
１０７・・・資源バランサ、
１０９・・・メタキャッシュ、
１１１・・・正規のキャッシュ、
１１３・・・メタデータ、
１１５・・・コンテンツサーバ、
１１７・・・クライアント装置、
３０１・・・入力ビデオストリーム、
３０３・・・パーサ、
３０５・・・出力ビデオストリーム、
３０７・・・フレームレートコントローラ、
３０９・・・メタキャッシュ、
４０１・・・入力ストリーム、
４０３・・・ＶＬＣデコーダ、
４０５・・・逆量子化、
４０７・・・量子化、
４０９・・・出力ストリーム、
４１１・・・ビットレートコントローラ、
４１３・・・メタキャッシュ、
５０１・・・入力ストリーム、
５０３・・・ＶＬＣデコーダ、
５０５・・・逆量子化器、
５０７・・・ＭＶ発生器、
５０９，５１３・・・動き補償、
５１１・・・ダウンサンプリング、
５１７・・・順方向量子化器、
５１９・・・ＶＬＣエンコーダ、
５２１・・・レート制御、
５２３・・・出力ストリーム、
５２７・・・メタキャッシュ、
５２９・・・動きベクトル、
５３１・・・新しい動きベクトル、
５３３，５３５  フレームバッファ、
【図１Ａ】
2005020729.tif 000003
【図１Ｂ】
2005020729.tif 000004
【図２】
2005020729.tif 000005
【図３】
2005020729.tif 000006
【図４】
2005020729.tif 000007
【図５】
2005020729.tif 000008
【図６】
2005020729.tif 000009