JP2014529931A - 帯域幅が変化する接続における動的ビットレート適合 - Google Patents

Abstract

【解決手段】トランスコード処理がウォールクロックと同期化された状態を維持することにより、メディアファイルの音声および動画のストリームがジャストインタイムでトランスコードされる。トランスコードがリアルタイムより少し早くされる。トランスコード済フレームはトランスコードされ次第、帯域幅が変化する接続を通じてトランスコーダから押し出される。その後、トランスコード済バッファの送信の間、利用可能であった帯域幅を評価すべくトランスコードが定期的にモニタリングされる。２つの時間間隔が測定される。１つ目は、前の２つの送信のトランスコード済バッファのタイムスタンプの差であるバッファ間隔である。２つ目は、直前のトランスコード済バッファの実際の時刻の送信時間に対応するクロック間隔である。大きな差が観察された場合、当該差から導出される係数によりトランスコーダのビットレートが調整される。【選択図】図３

Description

本願発明は、リアルタイムメディアの送信に関する。

図１は、例えばインターネットなどのネットワーク１０６を介してモバイルユニット、または宛て先ユニット、１０４に接続されるメディアサーバサブシステム１０２を含む、従来技術に係るメディア送信システム１００を示す。

各モバイルユニット１０４は、例えば、メディアセッションを確立する機能を備えたスマートフォンまたはラップトップコンピュータでありうる。

メディアサーバサブシステム１０２は、メディアファイルを生成するためのメディアサーバコンピューティングデバイス１０８と、メディアファイル処理するためのインターネットコンテンツアダプテーションプロトコル（ＩＣＡＰ）サーバコンピューティングデバイス１１０と、モバイルユニット、または端末、１０４からの要求に対応するハイパーテキスト転送プロトコル（ＨＴＴＰ）プロキシサーバコンピューティングデバイス１１２とを含み得、他の機能も実施し得る。

メディアセッションは、モバイル（宛て先）ユニット１０４により要求され得る。メディアセッションの目的は、メディアサーバサブシステム１０２からモバイルユニット１０４へメディアパケットのストリーム（メディアファイル）を送信することである。

要求しているモバイルユニット１０４とメディアサーバサブシステム１０２との間のネットワーク１０６を介した接続の帯域幅が、オリジナルのメディアファイルをリアルタイム送信するのに必要とされる帯域幅よりも小さい場合、メディアファイルは、典型的にはＨＴＴＰプロキシサーバ１１２に付属するＩＣＡＰサーバ１１０内に位置する機器によって、より小さな帯域幅に適合させられ得る。

ネットワーク１０６を介した接続の帯域幅も経時的に変化し得、このことは、メディアファイルの適合において他の問題を生じさせる。

したがって、帯域幅が変化する接続を介した送信のために、メディアファイルの帯域幅の適合を向上させる方法およびシステムが求められている。

本願発明の目的は、帯域幅が変化するリンクを介したモバイルユニットへのリアルタイム送信のために、メディアファイルまたはその一部をエンコードするための方法およびシステムを提供することである。

本願発明の一態様によると、帯域幅が変化するリンクを介したモバイル、または宛て先ユニットへのリアルタイム送信のために、メディアファイルまたはその一部をエンコードするための方法は、少なくとも１つのプロセッサを用いて、
（ｉ）メディアファイルの１以上のフラグメントをトランスコード済メディアフラグメントへエンコードし、ストリームフラグメントを形成する段階と、
（ｉｉ）前に形成されたストリームフラグメントをトランスコーダから伝送し、帯域幅が変化するリンクが消費するのに要する時間間隔である、前に形成されたストリームフラグメントの推定送信時間を判断する段階と、
（ｉｉｉ）推定送信時間の関数として、トランスコード済メディアフラグメントの現エンコードレートを調整する段階と
を実行する。

上述した方法において、段階（ｉ）は、
初期エンコードレートで、メディアファイルの少なくとも第１のフラグメントを、対応する第１のトランスコード済メディアフラグメントにエンコードする段階と、
初期エンコードレートに等しい現エンコードレートを設定する段階と
を有し、
段階（ｉｉｉ）は、調整された現エンコードレートで、メディアファイルの後続のフラグメントを、対応するトランスコード済メディアフラグメントにエンコードする段階を有する。

上述した方法において、段階（ｉｉｉ）はさらに、２つの前に形成されたストリームフラグメントに関連するタイムスタンプから導出される、モバイルユニットにおけるストリームフラグメントの推定表示時間の関数として、現エンコードレートを調整する段階を有する。

段階（ｉｉｉ）はさらに、現エンコードレートの関数として現エンコードレートを調整する段階を有する。

本願発明の一実施形態において、当該関数は、現エンコードレートと、推定表示時間および推定送信時間に応じた調整係数との積である。

調整係数は、推定表示時間を推定送信時間で除算した値であるのが好都合である。

方法はさらに、トランスコード済メディアフラグメントを表示するためにモバイルユニットに送信する段階を備える。

上述した方法において、現エンコードレートを調整する段階は、時折実行され得る。例えば、調整する段階は、定期的に実行され得る。

本願発明の実施形態において、段階（ｉｉ）はさらに、現時刻と直前のエンコード時の時刻である前の時刻との間の現クロック間隔として、推定送信時間を推定する段階を有し、段階（ｉｉｉ）はさらに、
モバイルユニットにおける前のストリームフラグメントの推定表示時間を表し、２つの前に形成されたストリームフラグメントに埋め込まれたタイムスタンプから導出される現バッファ間隔を判断する段階と、
現クロック間隔と現バッファ間隔とを比較する段階と、
現クロック間隔および現バッファ間隔の関数として現エンコードレートを調整する段階と
を有する。

２つの前に形成されたストリームフラグメントは、直近の２つのストリームフラグメントであるのが好都合である。

上述した方法において、調整する段階は、現クロック間隔が現バッファ間隔と所定量の分だけ異なる場合に、現エンコードレートを調整する段階を有する。

例えば、段階（ｉｉｉ）は、Ｎ秒の現クロック間隔が経過した後に現エンコードレートを調整する段階を有し得る。本願発明の実施形態において、Ｎは、２〜５秒の範囲であり、例えばＮ＝３秒である。

現クロック間隔および現バッファ間隔の関数として現エンコードレートを調整する段階は、
現バッファ間隔と現クロック間隔との間の第１の相対差が第１の所定の閾値ＴＨ１より大きい場合に、第１の相対差に基づき計算される第１の増分値の分だけ現エンコードレートを増加させ、
現クロック間隔と現バッファ間隔との間の第２の相対差が第２の所定の閾値ＴＨ２より大きい場合、第２の相対差に基づき計算される第２の増分値の分だけ現エンコードレートを減少させる
ことにより実行され得る。

ＴＨ１として、少なくとも０．０５を選択し、ＴＨ２として少なくとも０．０２を選択するのが好都合である。

上述した方法において、第１の増分値は、第１の相対差を第１の減衰係数ＡＦ１で除算した値に等しく、第２の増分値は、第２の相対差を第２の減衰係数ＡＦ２で除算した値に等しく、第１および第２の減衰係数ＡＦ１、ＡＦ２は、現エンコードレートの過剰または急激かつ過度な調整を防ぎ、調整する段階の安定性を確保するよう選択される。

本願発明の他の実施形態において、段階（ｉｉｉ）は、トランスコード済メディアフラグメントの送信の一時停止が検出されなかった場合にのみ現エンコードレートを調整する段階を含む。

本願発明の当該他の実施形態において、段階（ｉｉｉ）はさらに、一時停止を検出する段階を有し、
検出する段階は、
メディアファイルのエンコードが開始されてからの、現時刻と直前のエンコード時の時刻である前の時刻との間の間隔としてそれぞれが測定される過去の現クロック間隔の平均として平均クロック間隔を計算する段階と、
現クロック間隔が平均クロック間隔より所定の差ＸＣの分だけ大きい場合に、一時停止が検出されたと判断する段階と
を含む。

上述した方法はさらに、
少なくとも２つの現クロック間隔が発生し、
既に検出された一時停止の回数が、最大一時停止検出回数（ＭＰ）より少ない
場合、一時停止が検出されたものと判断する段階を備える。

方法はさらに、現クロック間隔が平均クロック間隔に係数Ｍを乗算した値を超える場合に一時停止が検出されたものと判断する段階を備える。方法はさらに、一時停止が検出された場合に現クロック間隔を平均クロック間隔で入れ替える段階を備える。本願発明の実施形態において、ＭＰは３であり、ＸＣは１であり、Ｍは４である。

本願発明の他の態様によると、帯域幅が変化するリンクを介したモバイルユニットへのリアルタイム送信のために、メディアファイルまたはその一部をエンコードするためのメディア処理システムは、プロセッサと、プロセッサにより実行されるコンピュータ可読命令を格納した非一時的コンピュータ可読記憶媒体とを備え、
プロセッサと非一時的コンピュータ可読記憶媒体とは、
メディアファイルの１以上のフラグメントをトランスコード済メディアフラグメントにトランスコードし、ストリームフラグメントを形成するトランスコーダと、
前に形成されたメディアフラグメントをトランスコーダから伝送し、帯域幅が変化するリンクが消費するのに要する時間間隔である、前に形成されたストリームフラグメントの推定送信時間の関数としてトランスコーダの現エンコードビットレートを調整する動的ビットレートアダプタと
を構成する。

上述したメディア処理システムにおいて、動的ビットレートアダプタはさらに、２つの前に形成されたストリームフラグメントに関連するタイムスタンプから導出される、モバイルユニットにおけるストリームフラグメントの推定表示時間の関数として、現エンコードレートを調整する。

メディア処理システムは、トランスコード済メディアフラグメントをネットワークへ転送し、トランスコード済メディアフラグメントのうち少なくともいくつかに関連するタイムスタンプを動的ビットレートアダプタに送信するトランスコーダバッファをさらに備える。

動的ビットレートアダプタは、
現時刻をトラッキングするためのウォールクロックモジュールと、
トランスコーダのエンコードビットレートを時折調整するために、トランスコーダに送信されるサービス品質（ＱｏＳ）値となるよう現時刻とタイムスタンプとを処理するＱｏＳアジャスタと
を含む。

上述したメディア処理システムにおいて、動的ビットレートアダプタはさらに、トランスコード済メディアフラグメントの送信の中断を検出し、中断が検出された場合に、動的ビットレートアダプタによる現エンコードレートの調整を妨げる一時停止検出器を含む。

動的ビットレートアダプタはさらに、現エンコードレートの関数として現エンコードレートを調整する。

本願発明の一実施形態において、動的ビットレートアダプタはさらに、現時刻と直前のエンコード時の時刻である前の時刻との間の現クロック間隔として推定送信時間を推定する。

動的ビットレートアダプタはさらに、
モバイルユニットにおける前のストリームフラグメントの推定表示時間を表し、２つの前に形成されたストリームフラグメントに埋め込まれたタイムスタンプから導出される現バッファ間隔を判断し、
現クロック間隔と現バッファ間隔とを比較し、
現クロック間隔および現バッファ間隔の関数として現エンコードレートを調整する。

動的ビットレートアダプタはまたさらに、現クロック間隔が現バッファ間隔と所定量の分だけ異なる場合に、現エンコードレートを調整する。

本願発明のさらに他の態様によると、帯域幅が変化するリンクを介したモバイルユニットへのリアルタイム送信のために、メディアファイルまたはその一部をエンコードするための方法は、少なくとも１つのプロセッサを用いて、
（ａ）初期エンコードレートに等しい現エンコードレートで、メディアファイルの少なくとも第１のフラグメントをトランスコード済メディアフラグメントにエンコードしてストリームフラグメントを形成し、ストリームフラグメントを送信する段階と、
（ｂ）帯域幅が変化するリンクがストリームフラグメントを消費するのに要する時間間隔である、前に送信されたストリームフラグメントの推定送信時間に基づいて、現エンコードレートが新たなエンコードレートとなるよう再評価する段階と、
（ｃ）現エンコードレートが新たなエンコードレートに等しくなるよう設定する段階と、
（ｄ）現エンコードレートで、メディアファイルの他のフラグメントをトランスコード済メディアフラグメントにエンコードする段階と、
（ｅ）メディアファイルまたはその一部が完全にトランスコードされるまで段階（ｂ）から段階（ｄ）までを繰り返す段階と
を実行する。

上述した方法において、段階（ｂ）は、現時刻と、直前の再評価時の時刻である前の時刻との間の現クロック間隔として推定送信時間を推定する段階を有する。

段階（ｂ）はさらに、
直前および前のストリームフラグメントのトランスコード済メディアフラグメントのうち少なくともいくつかに埋め込まれたタイムスタンプから導出される、モバイルユニットにおける直前のストリームフラグメントの推定表示時間を表す現バッファ間隔を判断する段階と、
現クロック間隔と現バッファ間隔とを比較する段階と、
現クロック間隔が現バッファ間隔と異なる場合に現エンコードレートを修正する段階と
を有する。

上述した方法において、現エンコードレートは、現クロック間隔および現バッファ間隔の関数として修正される。

上述した方法において、段階（ｂ）はさらに、直前および前のストリームフラグメントのトランスコード済メディアフラグメントのうち少なくともいくつかに埋め込まれたタイムスタンプの関数である、モバイルユニットにおける直前のストリームフラグメントの推定表示時間および現エンコードレートの関数として新たなエンコードレートを計算する段階を有する。

例えば、当該関数は、現エンコードレートと、推定表示時間および推定送信時間に応じた調整係数の積であり得る。

本願発明の実施形態において、段階（ｂ）は、Ｎ秒の現クロック間隔が経過した後にのみ、現エンコードレートを再評価する段階を有する。

本願発明の代替的な実施形態において、段階（ｂ）はさらに、トランスコード済メディアフラグメントの送信の中断を検出する段階と、中断が検出された場合に現エンコードレートの調整を抑制する段階とを有する。

よって、帯域幅が変化するリンクを介したモバイルユニットへのリアルタイム送信のために、メディアファイルまたはその一部をエンコードするための改善された方法およびシステムが提供される。

添付の図面を参照し、例示として本願発明の実施形態を説明する。
図１は、従来技術に係るメディア送信システム１００を示す。 図２は、可変ビットレートトランスコーダ２０２を含む、本願発明の実施形態に係るメディア配信システム２００を示す。 図３は、図２の可変ビットレートトランスコーダ２０２を含む、可変ビットレートトランスコーダシステム３００の簡略化されたブロック図を示す。 図４は、本願発明の実施形態に係る動的ビットレート適合処理４００のフローチャートを示す。 図５は、図４のＱｏＳ再評価段階４０８のより詳細なフローチャートを示す。 図６は、図５の段階５０８「ＱｏＳ計算を初期化」を展開したフローチャートを示す。 図７は、図５の段階５２０「一時停止を検出」を展開したフローチャートを示す。 図８は、図５の段階５２４「一時停止を処理」を展開したフローチャートを示す。 図９は、図５の段階５２８「ＱｏＳを計算」を展開したフローチャートを示す。 図１０は、図４の段階４１２「新たなＱｏＳ値を適用」の展開したフローチャートを示す。 図１１は、本願発明の他の実施形態に係る、修正された動的ビットレート適合処理１１００のフローチャートを示す。 図１２は、図１１のセグメントＱｏＳ再評価段階１１０８のより詳細なフローチャートを示す。 図１３は、図１２の「セグメントＱｏＳ計算を初期化」段階１２０６のより詳細なフローチャートを示す。

本願発明の実施形態は、帯域幅が経時的に変化するネットワークを介したＨＴＴＰマルチメディア配信のユーザ体験を向上させることを目的とする。この目的は、メディアファイルのエンコードレートを動的に変化させて、利用可能な帯域幅に対応させることにより達成される。

この解決方法はＩＣＡＰプロトコルにおいて実装され得るが、デバイスへの最終的な配信はＨＴＴＰに基づき、当該解決方法は、両方のプロトコルに等しく適用される。

ユーザがモバイルネットワークを介して動画をストリーミングする場合、リアルタイム配信に近い配信を提供するために利用可能なネットワークの帯域幅は十分でないことが多い。その結果、エンドデバイス側で動画が中断するため閲覧体験の品質は悪くなる。

この問題を避けるべく、利用可能な帯域幅に略対応するよう現エンコードレートを時折調整する本願発明の実施形態により、メディアのエンコードレートが動的に適合させられる。ストリーミングにＨＴＴＰプロトコルを用いる場合、クライアントアプリケーションはフィードバックをサーバに送信せず、下層の通信制御プロトコル（ＴＣＰ）の接続情報は信頼性の高いものとして用いられ得ない。

従来の解決方法においてはデータ配信のために、ユーザデータグラムプロトコル（ＵＤＰ）の上で、リアルタイムトランスポートプロトコル（ＲＴＰ）と共にリアルタイムストリーミングプロトコル（ＲＴＳＰ）を制御プロトコルとして用いる。これらのプロトコルを用いる場合、動画プレーヤーは１秒毎に数回、フィードバックをモバイルユニットからサーバへ送信する。このフィードバックは、ネットワーク障害（パケット損失、ジッタなど）についての情報も含み、エンコードレートの自動的な調整を可能とする。Ｆｒａｎｃｉｓ Ｒ．Ｌａｂｏｎｔｅらに与えられた、発明の名称が「ＤＡＴＡ ＳＴＲＥＡＭＩＮＧ ＴＨＲＯＵＧＨ ＴＩＭＥ−ＶＡＲＹＩＮＧ ＴＲＡＮＳＰＯＲＴ ＭＥＤＩＡ」である米国特許第７，８４４，７２５は、時間依存の接続を介してのデータストリーミングのための方法を開示している。当該特許は、その内容の全体が参照により本明細書に組み込まれる。

ＨＴＴＰはウェブに関して遍在するプロトコルなので、ＲＴＳＰとＲＴＰとの組み合わせの代わりにＨＴＴＰを用いるのが望ましい。ＨＴＴＰは殆ど全てのタイプのデータを転送するのに用いられる。ウェブクライアントおよびウェブサーバの両方がＨＴＴＰをサポートすることを求められているので、例えばＲＴＳＰ／ＲＴＰなどかなり特定的な目的のために機能するパラレルな（ｐａｒａｌｌｅｌ）プロトコルを用いることなくクライアントとサーバとの間の相互運用性を最大化するには、ＨＴＴＰを介して動画を転送することが当然ながら適している。同様の例として、ファイルのダウンロードについて考える。ファイル転送プロトコル（ＦＴＰ）は特にこの目的のために設計されているが、今日において、ウェブ上のかなり高い割合のファイルが、ＦＴＰではなくＨＴＴＰを介して転送されている。

さらに考えるべきことは、機器間の相互運用性である。ＨＴＴＰは広い相互運用性を有する。ＨＴＴＰは、サーバ側とクライアント側の両方で数限りなく実装されている。ＨＴＴＰには、あらゆるクライアントが相互運用することが出来る事実上のリファレンス実装としてＡｐａｃｈｅがある。他方ＲＴＳＰには、多くの商用の実装において同規格と非準拠であるという不利な点がある（ＨＴＴＰとＲＴＳＰ／ＲＴＰとの対比に関しては、ｈｔｔｐ：／／ｗｗｗ．ｒｅｍｌａｂ．ｎｅｔ／ｏｐ／ｖｏｄ．ｓｈｔｍｌの記事も参照されたい）。

しかし、音声および動画のストリーミングにＨＴＴＰを用いる場合、配信について利用可能な情報は、オペレーティングシステム層で管理され、マルチメディアを意識しないＴＣＰ接続からのみ取得される。またマルチメディアサーバとクライアントとの間にはプロキシサーバが見られることが多い。これらのプロキシは、クライアントデバイスとの接続を取扱い、自身の接続を確立する。本願発明の実施形態によると、受信側のクライアントからストリーミングする側のサーバへの明示的なフィードバックを要することなく、ＨＴＴＰ接続を介して音声および動画の効率的なストリーミングが可能になる。

図２は、可変帯域幅リンク２０４を介してメディアサーバコンピューティングデバイス１０８からモバイルユニット１０４内のモバイル動画アプリケーション２０６へ送信されるメディアファイルのための動的ビットレート適合を提供する可変ビットレートトランスコーダ２０２を含む、本願発明の実施形態に係るメディア配信システム２００を示す。好ましくは、モバイル（宛て先）ユニット１０４への可変帯域幅リンク２０４は、ＨＴＴＰプロキシサーバコンピューティングデバイス１１２にＨＴＴＰ接続を提供する。図２は、モバイルユニット１０４へのＨＴＴＰリンク２０４を示す。このリンクは、例えば実験室内での直接的なリンクであり得、または、インターネットを通り得、モバイルユニット１０４自体へのワイヤレスドロップ（ｗｉｒｅｌｅｓｓ ｄｒｏｐ）を含み得る。

モバイルユニット１０４は、例えば、メディアセッションを確立する機能を備えた、スマートフォン、ラップトップ、タブレットなどのデバイス、または他のコンピュータのようなデバイスである。

モバイル動画アプリケーション２０６は、プロセッサにより実行される、メモリなどのコンピュータ可読記憶媒体に格納されたコンピュータ可読命令を備える。

一実施形態において、可変ビットレートトランスコーダ２０２は、プロセッサにより実行される、メモリなどのコンピュータ可読媒体に格納されたコンピュータ可読命令を備える。代替的に、可変ビットレートトランスコーダ２０２はファームウェアで実装されてもよい。

可変ビットレートトランスコーダ２０２は、ＩＣＡＰリンクを介してＨＴＴＰプロキシサーバ１１２に結合されたＩＣＡＰサーバ１１０に埋め込まれた状態で示されているが、可変ビットレートトランスコーダ２０２は代替的にＨＴＴＰプロキシサーバ１１２に埋め込まれていてもよく、或いは、メディアサーバ１０８に埋め込まれていてもよいことを理解されたい。

図３は、可変ビットレートトランスコーダシステム３００の簡略化されたブロック図を示す。可変ビットレートトランスコーダシステム３００は、図２の可変ビットレートトランスコーダ２０２と併せて、プログラム格納メモリ３０４、ＣＰＵ３０６、およびネットワークインタフェース３０８を少なくとも備えたコンピューティングデバイスであるメディア処理サーバ３０２を含む。好ましくは、可変ビットレートトランスコーダ２０２は、プログラム格納メモリ３０４に格納されＣＰＵ３０６により実行される命令を含むソフトウェアモジュールとして実現される。本願発明の様々な実施形態において、メディア処理サーバ３０２は、メディアサーバ１０８、インターネットコンテンツアダプテーションプロトコル（ＩＣＡＰ）サーバ１０８、または、ハイパーテキスト転送プロトコル（ＨＴＴＰ）プロキシサーバ１１２を表し得る。

可変ビットレートトランスコーダ２０２は、動的ビットレートアダプタ３１０、セッション変数格納モジュール３１２、トランスコーダ３１４、トランスコーダバッファ３１６、およびウォールクロック３１８を備える。動的ビットレートアダプタ３１０は、ＱｏＳアジャスタモジュール３２０および一時停止検出器モジュール３２２を含む。セッション変数格納モジュール３１２は、構成ファイル３２４および保存済み変数格納部３２６を含む。よって、本願発明の一実施形態において、可変ビットレートトランスコーダ２０２の上述したモジュール３１０、３１２、３１４、３１６、３１８、３２０、３２２、３２４は、プロセッサにより実行される、コンピュータメモリに格納されたコンピュータ可読命令を備える。

ネットワークインタフェース３０８は、ハードウェア（物理インタフェース）とソフトウェア（プロトコル）との両方を含む。

ＣＰＵ３０６は、例えばＬｉｎｕｘ（登録商標）など、プロトコルを含むオペレーティングシステム（ＯＳ。図示せず）を実行する。

ＯＳは、現時刻（ＣＴ）が導出される、コンピュータ内で利用可能なクロックチップに基づいて計時機能も提供する。このことは、ウォールクロック３１８モジュールに示されている。

ＤＢＲＡ３１０モジュールは、必要に応じてＯＳソフトウェア（カーネル）から時間（ウォールクロック時間）を読み取るが、ウォールクロック３１８モジュールは、これを修正してもよく、例えば増減または相殺してもよく、トランスコード済メディアフラグメントの送信が開始されたゼロからの時間をカウントし得るローカルな「ウォールクロック」変数を記録してもよく、これにより、現時刻（ＣＴ）をＤＢＲＡ３１０が利用出来るようにする。

動作において、トランスコーダ３１４はメディアファイル３２８を受信し、トランスコーダバッファ３１６およびネットワークインタフェース３０８を通り可変帯域幅リンク２０４を介したモバイルユニット１０４への送信に適したビットレートとなるようメディアファイル３２８をトランスコードまたはエンコードする。ここでネットワークインタフェース３０８はその機能として、ＨＴＴＰなどアプリケーションプロトコルの下層の信頼性のある通信制御プロトコル（ＴＣＰ）を実装する。

ストリームフラグメントとも呼ばれる、１以上のトランスコード済メディアフラグメントの送信に用いられる時間間隔は、可変帯域幅リンク２０４で利用可能な、信頼性のある通信制御プロトコル（ＴＣＰ）の制御下にある帯域幅に応じて異なる。１つのストリームフラグメントの送信に用いられるおよその時間は、連続するストリームフラグメントがトランスコーダバッファ３１６を離れる時間の複数の例を観察することにより計算され得る。時間の値はウォールクロック３１８の出力から取得される。計算された送信時間は、「推定送信時間」と呼ぶ。

「送信時間」または「推定送信時間」という表現の意味を明確にすると、これらは実質的に、トランスコード済フラグメントを可変帯域幅リンク２０４のビットレートで順次送信するのに必要な期間、つまり、トランスコード済フラグメントが可変ビットレートトランスコーダ２０２を離れる際に占有する時間である。これらの時間は可変ビットレートトランスコーダ２０２とモバイルユニット１０４との間の、知られない、本願発明の実施形態の動作に関係しない遅延時間ではない。

推定送信時間は、１以上の前のストリームフラグメントをトランスコーダから伝送し、帯域幅が変化するリンクが消費するのに要する時間間隔である。

好ましい実施形態の変形例において、推定送信時間は、推定を行う時点の直前ではない、より前のストリームフラグメントからも導出され得ることを理解されたい。

動的ビットレートアダプタ３１０は、トランスコーダバッファ３１６からのタイムスタンプをモニタリングし、ウォールクロックおよびセッション変数格納モジュール３１２を用いて、可変帯域幅リンク２０４上で利用可能な帯域幅を推定し、現在のサービス品質（ＱｏＳ）値をそれに応じて調整するためのアルゴリズムを実行する。その後トランスコーダ３１４は、現ＱｏＳ値を適用し、それに応じて現エンコードビットレートを調整する。以下において、「トランスコードビットレート」、「エンコードレート」、および「ＱｏＳ値」という用語は本願において互換的に用いられる。「トランスコードビットレート」および「エンコードレート」は、トランスコーダ３１４のトランスコード動作の結果として得られるビットレートを直接的に指す。「ＱｏＳ値」は、エンコードレートを制御するためにトランスコーダ３１４に入力され、よってエンコードレートを間接的に特定するパラメータである。

セッションが開始されると、初期のＱｏＳ値を含むセッションパラメータが決定され、構成ファイル３２４に格納される。

ＱｏＳアジャスタモジュール３２０において新たなＱｏＳ値が定期的に計算される。ＱｏＳアジャスタモジュール３２０はビットレート適合機能を用い、推定送信時間と（１以上のトランスコード済フラグメントを備える）ストリームフラグメントを可変ビットレートトランスコーダ２０２から送信するのにかかった時間とを比較する。推定送信時間は現クロック間隔とも呼ばれ、推定表示時間は、ストリームに埋め込まれたタイムスタンプにより示される、モバイルユニット１０４において同じストリームフラグメントを表示するのに必要とされる時間である。現バッファ間隔とも呼ばれる推定表示時間は、モバイルユニットの表示機能がストリームフラグメントをリアルタイム表示する際に用いるために、ストリームフラグメントのタイムスタンプに暗黙的に特定される時間である。ストリームフラグメントの送信の開始よりも前に観察され計算された、ウォールクロック時間およびタイムスタンプなどの値、並びに、平均間隔を計算するのに必要な値は、保存済み変数格納部３２６に保持される。本願発明の一実施形態において、現クロック間隔は、少なくとも３秒の適合リフレッシュ間隔に等しい。

リンク２０４上で利用可能なビットレートは直接的には観察可能ではなく、モバイルユニット１０４内のバッファの占有率についての情報は、利用可能ではないことを理解されたい。しかし、埋め込まれたタイムスタンプにより指示されるように動画ストリームをリアルタイムで受信し、バッファリングし、表示する間、モバイルユニット１０４は時折、追加のストリームフラグメントを自動的に受信するであろう。この場合、送信レートは例えば、下層のネットワークプロトコル（ＴＣＰ）に基づき調節される。可変ビットレートトランスコーダ２０２がそのようなフラグメントのそれぞれをウォールクロック時間で測られるようにリアルタイム送信出来る限り、リンクビットレートは十分である。しかし、ビットレートが不十分な場合、前のストリームフラグメントを十分に短い時間で送信出来ないため、この不十分であることは可変ビットレートトランスコーダ２０２で検出されるであろう。モバイルユニット１０４はビットレートの変化を軽減する受信バッファを有することが想定されるが、この受信バッファはリンクビットレートが長時間に亘り不十分であれば欠乏してしまうであろう。このことを避けるべく、可変ビットレートトランスコーダ２０２はエンコードレート（ＱｏＳ）を減少させる必要がある。

同様に、利用可能なビットレートがかなり高い場合、１つのストリームフラグメントの送信にかかる時間は、タイムスタンプにより示される時間間隔よりも短い時間となり、ＱｏＳ値は高められ得る。ＱｏＳアジャスタモジュール３２０の機能は、以下の図９に詳細に説明する。

モバイルユニット１０４におけるストリームの表示が一時的に停止した場合、つまり、トランスコード済メディアフラグメントの送信の中断が発生した場合、可変ビットレートトランスコーダ２０２は、追加のストリームフラグメントを送信することが出来ない。一時停止検出器モジュール３２２は、このような状況を検出し、ＱｏＳ値を誤って調整することを避けるために設けられている。

タイムスタンプは、任意のオリジナルのメディアファイルフォーマット、およびトランスコード済メディアファイルフォーマットに関してフォーマット規格文書に指定されるように、オリジナルのメディアおよびトランスコード済メディアに埋め込まれている。タイムスタンプは、フォーマットに関わらず、少なくともいくつかのトランスコード済メディアフラグメントに埋め込まれている。以下の表１は、タイムスタンプをサポートする一般的なメディアファイルフォーマットおよび標準的なコーデックの一部を示すリストである。タイムスタンプは相対的な実際の時刻のインスタンスを規定し、モバイルユニット１０４における受信された動画シーケンスのリアルタイム表示を、オリジナルの動画シーケンスの対応するリアルタイムシーケンスにロックするために用いられる。その結果、「表示時間」、つまり、１以上のトランスコード済メディアフラグメントをモバイルユニットにおいて通常通り（早送りせずに）表示することにより占有される時間間隔は、可変ビットレートトランスコーダ２０２において、トランスコード済メディアフラグメントが送信された時間のタイムスタンプを観察し、それにより「推定表示時間」を計算することにより推定され得る。表１：ファイルフォーマットおよびコーデック規格

表１は、様々なフォーマットおよび対応するコーデックの名前に関して用いられる一般的に理解されている頭字語を示す。

Ｆ４ＶおよびＦＬＶは、Ａｄｏｂｅ ＳｙｓｔｅｍｓによるＦｌａｓｈ Ｖｉｄｅｏとして知られる動画ファイルフォーマットである。３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）および３ＧＰＰ２（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ ２）はそれぞれ、ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ）およびＣＤＭＡ２０００（Ｃｏｄｅ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）技術に基づくセルラーフォンネットワークに関する３Ｇ技術を提供する。ＭＯＶは、Ｑｕｉｃｋｔｉｍｅ（Ａｐｐｌｅ Ｉｎｃ．）で用いられるファイルフォーマットである。ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）ＴＳ（Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）は、ＭＰＥＧストリームのファイルフォーマットを規定する。ＷｅｂＭは、Ｇｏｏｇｌｅがスポンサの、ＨＴＭＬ５動画で用いられる公開された動画圧縮フォーマットを提供するべく設計された音声／動画フォーマットである。

ここで列挙した音声コーデックの頭字語は、ＡＡＣ（Ａｄｖａｎｃｅｄ Ａｕｄｉｏ Ｃｏｄｉｎｇ）、ＡＭＲ（Ａｄａｐｔｉｖｅ Ｍｕｌｔｉ−Ｒａｔｅ ａｕｄｉｏ ｃｏｄｅｃ）、ＡＭＲ−ＷＢ（Ａｄａｐｔｉｖｅ Ｍｕｌｔｉ−Ｒａｔｅ ａｕｄｉｏ ｃｏｄｅｃ−ｗｉｄｅｂａｎｄ）ＭＰ２（ＭＰＥＧ−２ Ａｕｄｉｏ ｓｔａｎｄａｒｄｓ）、およびＭＰ３である。ＭＰはＭＰＥＧ−Ｐａｒｔの略語である。

Ｖｏｒｂｉｓは、音声フォーマットの名前であり、Ｘｉｐｈ．Ｏｒｇ Ｆｏｕｎｄａｔｉｏｎのコーデック実装を規定する。

動画コーデックには、Ｈ．２６３およびＨ．２６４に規定されるＩＴＵ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｕｎｉｏｎ）規格に準拠したコーデックが含まれ、ＭＰＥＧ−２およびＭＰＥＧ−４は、ＭＰＥＧコーデック規格の異なるバージョンである。ＶＰ６はＯｎ２ Ｔｅｃｈｎｏｌｏｇｉｅｓによる動画コーデック実装であり、ＶＰ８は、元々はＯｎ２ Ｔｅｃｈｎｏｌｏｇｉｅｓにより作成され、Ｇｏｏｇｌｅによりリリースされた公開の動画圧縮フォーマットである。

トランスコーダ３１４は、現在利用可能であり、様々なシステムで用いられている、列挙されたフォーマットのいずれのトランスコードも（分け隔てなく）実装し得る。しかし、トランスコーダ３１４の詳細は本願発明の範囲外であり、本願発明は、トランスコード後のビットレートを利用可能なネットワーク帯域幅に適合させるためにＱｏＳ（またはエンコードビットレート）パラメータをトランスコーダ３１４へ供給することに焦点を当てている。

動的ビットレートアダプタ３１０により提供される動的ビットレート適合（ＤＢＲＡ）は、オンザフライでトランスコードされるセッションを対象としている。このことが意味するのは、トランスコード処理がウォールクロックと同期化された状態を維持することにより、メディアファイルの音声および動画のストリームがジャストインタイムでトランスコードされるということである。ＤＢＲＡアルゴリズムを機能させるには、トランスコードをリアルタイムより少し早くすることが重要である。トランスコーダ３１４は、トランスコーダバッファ３１６内に、送出されることになるトランスコード済データを格納する。トランスコード済フレームはトランスコードされ次第、ＨＴＴＰ接続を通じてトランスコーダバッファ３１６から押し出される。

ＤＢＲＡが有効化されると、ウォールクロック３１８により測定される、１以上の動画フラグメントを表すある量のトランスコード済データを送信するのにかかる時間（上記にて定義した送信時間、または推定送信時間）と、動画フラグメントに埋め込まれたタイムスタンプにより示される、モバイルユニット１０４で動画フラグメントをリアルタイム表示するのにかかる時間、またはかかるであろう時間（上記にて定義した表示時間、または推定表示時間）とを比較することによりある間隔の間に利用可能であった帯域幅を評価すべく、トランスコードセッション（トランスコードセッションは単にセッションとも呼ぶ）が時折、例えば定期的に（例えば３秒間隔で）モニタリングされる。

言い換えると、送信時間は、ネットワークリンクの利用可能なビットレート（帯域幅）に基づき調節され、表示時間は、受信デバイス、例えばモバイルユニット１０４が受信したフラグメントを表示する時間である。明らかに、中断を防ぐには、実際の動画フラグメントの表示期間の長さ以下の期間でフラグメントを送信する必要がある。

したがって、本願発明の実施形態は、あるフラグメントの送信の間利用可能であった帯域幅を開ループのやり方で推定し、当該帯域幅を同フラグメントの表示時間と比較し、必要であればそれに応じて、次に送信されるフラグメントのトランスコードビットレートを調整することを提案する。以下において、「フラグメント」および「バッファ」または「トランスコード済バッファ」は互換的に用いられる。

自身のファイルフォーマットに準拠しタイムスタンプでマークされたトランスコード済データ（フラグメント）は、トランスコーダバッファ３１６を通じてネットワークインタフェース３０８に転送される。トランスコーダバッファ３１６内のトランスコード済データが送出される際、それらのタイムスタンプがチェックされ、間隔（ＣｕｒｒｅｎｔＢｕｆｆｅｒＩｎｔｅｒｖａｌとも呼ばれる間隔Ａ。以下の表２の変数名を参照されたい）が計算される。システムは、トランスコーダバッファ３１６内のトランスコード済データをクライアントへ送信し、完了すると、当該バッファのタイムスタンプが何であったかをＤＢＲＡがチェックする。

２つの時間間隔が判断される。間隔Ａ＝直前に送信されたバッファのタイムスタンプ−（マイナス）前の反復において送信された最後のバッファのタイムスタンプ。間隔Ｂ＝現ウォールクロック時間−（マイナス）前の反復のウォールクロック時間。

間隔Ｂは、ＣｕｒｒｅｎｔＣｌｏｃｋＩｎｔｅｒｖａｌとも呼ぶ。以下の表２の変数名を参照されたい。

これら２つの間隔が時折比較され、（正または負の）大きな差が算出された場合、その差に応じた係数によりビットレートが調整される（増加または減少させられる）。なお、ビットレートは、セッションの開始時において確立された初期ビットレートよりも大きくされることはない。

間隔Ａが間隔Ｂよりも長い場合、このことが意味するのは、現ビットレートでリアルタイムよりも早くメディアを配信することが出来、よって、ビットレートを増加させることが可能であるということである。間隔Ｂが間隔Ａよりも長い場合、このことが意味するのは、利用可能な帯域幅でメディアをリアルタイム配信することが出来ず、エンコードビットレートを減少させなければならないということである。

現クロック間隔（間隔Ｂ）は、その間隔の間の推定送信時間、または上限、つまり、トランスコード済メディアフラグメントをバッファからモバイルユニットへ送信するのにかかる時間（つまり、上述したように、バッファを離れ、リンクにより消費される時間）を提供する。現バッファ間隔（間隔Ａ）は、現クロック間隔の間に送信されたトランスコード済メディアフラグメントの表示時間の推定値である。本願発明の実施形態に係るシステムは、メディアを表示するものと想定される、モバイルユニット内の動画プレーヤーには直接的または間接的にアクセスすることが出来ない。しかし、トランスコード済メディアフラグメントのうち少なくともいくつかに埋め込まれ、モバイルユニット内の動画プレーヤーが動画をリアルタイム表示するために用いるタイムスタンプがこの情報を提供する。

本説明において、「フラグメント」という用語は、必要に応じて明確にするために様々な修飾語句と共に用いられる。（トランスコードの前の）メディアファイル３２８は、「メディアフラグメント」とも呼ばれるフラグメントを備える。各メディアフラグメントは例えば、トランスコーダが動作を行うのに十分な、１以上の動画フレーム、または、ある最小数のミリ秒の音声に対応する。各メディアフラグメントのサイズは、トランスコードされ得るような十分なサイズである。トランスコードの後、対応する「トランスコード済メディアフラグメント」は、「メディアフラグメント」と同じ意味内容を有するが、一般的に、より少ないビット数を有する。「トランスコード済メディアフラグメント」がモバイルユニットへ送信される（ストリーミングされる）。ここで、連続する複数のトランスコード済メディアフラグメントから成るグループによって、「ストリームフラグメント」が形成される。本願発明の実施形態によると、「ストリームフラグメント」は、モバイルユニットでリアルタイム表示されるのにおよそ３秒かかるであろうある量のトランスコード済メディアフラグメントである、およそ３秒分のリアルタイム動画または音声を表す複数の「トランスコード済メディアフラグメント」を備える。この「表示時間」は、オリジナルの「メディアフラグメント」、および「トランスコード済メディアフラグメント」に埋め込まれたタイムスタンプによって特定される。「トランスコード済メディアフラグメント」はトランスコードバッファを通じて送信されるので、トランスコード済メディアのこれらのバッファリングされたフラグメントは単に、「トランスコード済バッファ」または「トランスコード済バッファフラグメント」とも呼ばれ得る。

ＨＴＴＰ接続は動画プレーヤーからのフィードバックを提供しないので、ＤＢＲＡアルゴリズムは動画プレーヤーが一時停止されたことの検出または「推測」を試みる。そのような場合、遠隔のユニット内のプレーヤーバッファは最終的に満たされ、プレーヤーは、データの読み取りを停止するであろう。このことにより、間隔の比較によって得られるエンコードレートと配信レートとの間の差は大きなものとなる。このことはネットワークまたは帯域幅の問題ではないので、ビットレートを減少させる理由とはならない。

ユーザによる一時停止に関する以下の特性が認識されている。なぜならこれらは、ユーザによる一時停止を示すものと推定されるからである。
１．ウォールクロック間隔が、各反復において調整される平均ウォールクロック間隔よりも長い。
２．ウォールクロック間隔が１秒超長い。
３．ウォールクロック間隔が、平均ウォールクロック間隔を係数４で乗算した値よりも長い。
４．発生した一時停止がまだ２回以下である。

一時停止されたことが検出された場合、ビットレートは修正されず、この不規則な反復のウォールクロック間隔は破棄される。つまり、他の反復が影響を受けるのを防ぐために平均ウォールクロック間隔が再調整される。

ＤＢＲＡ３１０の機能のより詳細な説明は、以下の図面におけるフローチャートを参照して行う。

図４は、以下の段階を備える動的ビットレート適合処理４００のフローチャートを示す。
４０２：「トランスコードを開始」
４０４：「次のトランスコード済バッファを生成」
４０６：「トランスコード済バッファを送信」
４０８：「ＱｏＳを再評価」
４１０：「ＱｏＳ値が変更されたか？」
４１２：「新たなＱｏＳ値を適用」
４１４：「トランスコードが完了したか？」
４１６：「終了」

段階４０４「次のトランスコード済バッファを生成」から段階４１４「トランスコードが完了したか？」までが、メディアが完全にトランスコードされ送信されるまでに実行される動的ビットレート適合ループ４１８を形成する。ループは、セッションがアボートされた場合も停止され得る。

段階４０２「トランスコードを開始」が、メディアのトランスコードの開始点である。この開始点は、メディアをトランスコードしクライアントへ送信するために新たなセッションが作成される時点を表す。

段階４０４「次のトランスコード済バッファを生成」は、単に「トランスコード済バッファ」とも呼ばれるトランスコード済メディアのバッファリングされたフラグメントを生成することにより、メディアファイル３２８のフラグメントをトランスコード済メディアフラグメントにトランスコードする段階を表す。トランスコード済メディアフラグメントは、オリジナルのメディア、つまりメディアファイル３２８に対してトランスコーダ３１４のエンコードアルゴリズムを適用することにより作成される。

段階４０６「トランスコード済バッファを送信」において、オリジナルのメディアから生成された１つのトランスコード済バッファ（トランスコード済メディアフラグメント）が、確立されたセッションを介してクライアントへ送信される。

段階４０８「ＱｏＳを再評価」において、現ＱｏＳ値が再評価または調整される。この段階は、以下の図５においてより詳細に展開される。ＱｏＳ値は、トランスコード済バッファが送信される毎に再評価（調整）されてもよい。このことにより、バッファが送出される際にビットレートを動的に調整することが可能となる。

段階４１０「ＱｏＳ値が変更されたか？」において、前の段階の再評価の結果として、ＱｏＳ値が変更されたか否かの判断が行われる。ＱｏＳ値が変更された場合（段階４１０を「はい」から出る）、以下の図１０においてより詳細に展開される段階４１２「新たなＱｏＳ値を適用」において詳細に示されるように、新たなＱｏＳ値を用いて、次のトランスコード済バッファの生成のためのエンコードビットレートが変更される。そうでない場合、段階４１４「トランスコードが完了したか？」の実行に続く（段階４１０を「いいえ」から出る）。

段階４１４「トランスコードが完了したか？」において、メディアが完全にトランスコードされ送信されたか否かの判断が行われる。判断の結果が肯定的な場合（段階４１４を「はい」から出る）、動的ビットレート適合処理４００は段階４１６「終了」で終了する。そうでない場合、ループを戻って段階４０４「次のトランスコード済バッファを生成」が実行される。

ＤＢＲＡアルゴリズムで用いられるセッション変数はセッション変数モジュール３１２（図３）に格納され、以下の表２に一覧にされている。表２：ＤＢＲＡアルゴリズムで用いられるセッション変数

図５は、以下の段階を含む、図４のＱｏＳ再評価段階４０８のより詳細なフローチャートである。
５０２：「移行」
５０４：「ＴＴＲ≧１．０？」
５０６：「最初のＱｏＳ計算？」
５０８：「ＱｏＳ計算を初期化」
５１０：「現クロック間隔（ＣＣＩ）および現バッファ間隔（ＣＢＩ）を計算」
５１２：「ＣＣＩ＞Ｎ秒？」
５１４：「間隔インデックスをインクリメント」
５１６：「合計クロック間隔を計算」
５１８：「平均クロック間隔を計算」
５２０：「一時停止を検出」
５２２：「一時停止を検出したか？」
５２４：「一時停止を処理」
５２６：「ＣＣＩ＝ＣＢＩ？」
５２８：「ＱｏＳを計算」
５３０：「復帰」

ＱｏＳ再評価段階４０８へは段階５０２「移行」で移行し、段階５０４〜５２８で新たなＱｏＳ値を計算し、段階５３０「復帰」で復帰する。

段階５０４「ＴＴＲ≧１．０？」において、現トランスコードスロットリングレートが１．０以上であるか否か判断される。判断の結果が肯定的な場合（段階５０４を「はい」から出る）、次の段階５０６の実行に続く。そうでない場合（段階５０４を「いいえ」から出る）、ビットレートを減少させるためのトランスコードは必要ではなく、手順が復帰する（段階５３０）。

セッションが構成されると、パラメータＴＴＲが確立される。ＴＴＲが１．０未満の場合、トランスコードは実行されず、即座に手順が復帰する。ＴＴＲにより、オリジナルのメディアがトランスコードされる速度を制御することが可能となる。ＴＴＲが１．０の場合、１分のメディアは、およそ１分でトランスコードされるであろう。ＴＴＲが２．０の場合、同メディアはおよそ３０秒でトランスコードされるであろう。この値により、ＣＰＵ使用率に対するトランスコード速度を微調整することが可能となる。ＴＴＲを増加させることによりトランスコード済メディアはより速くなるが、ＣＰＵをさらに用いることになる。ビットレートは、オリジナルのメディアとトランスコード済メディアとの両方に適用される。両方がエンコードビットレートを有するが、ＤＢＲＡ３１０の役割は、例えばより低いビットレートでトランスコードするようトランスコーダ３１４に指示し、オリジナルよりも低いビットレートを有するトランスコード済メディアが得られるようにするなどにより、必要に応じてトランスコード済メディアのビットレートを動的に修正することである。

段階５０６「最初のＱｏＳ計算？」において、これがこのセッションの最初のＱｏＳ計算であるか否かの判断が行われる。判断の結果が肯定的な場合（段階５０６を「はい」から出る）、様々なセッション変数が初期化される段階５０８「ＱｏＳ計算を初期化」の実行に続く。段階５０８は以下の図６において展開される。これがこのセッションの最初のＱｏＳ計算ではない場合（段階５０６を「いいえ」から出る）、段階５１０の実行に続く。

段階５１０「現クロック間隔（ＣＣＩ）および現バッファ間隔（ＣＢＩ）を計算」において、現クロック間隔および現バッファ間隔が以下のように計算される。
ＣＣＩ≒ＣＴ−ＰＱＣＴ，
ここで、ＣＴは現時刻であり、
ＰＱＣＴは前ＱｏＳ計算時刻である。
ＣＢＩ≒（ＣＢＴ−ＰＢＴ）／ＴＴＲ
ここで、ＰＢＴは前バッファタイムスタンプであり、
ＴＴＲはトランスコードスロットリングレートである。

ＣＣＩおよびＣＢＩは、新たなＱｏＳ値の計算に用いられる。現クロック間隔は、段階５２８で計算される前ＱｏＳ計算時刻から現時刻までの期間である。現バッファ間隔は、段階５２８で計算される前バッファタイムスタンプから現バッファタイムスタンプまでの期間をトランスコードスロットリングレートで除算することより得られる。トランスコードスロットリングレート（ＴＴＲ）は、メディアセッションが確立される際に構成ファイルに特定される（段階４０２、図４）。

段階５１２「ＣＣＩ＞Ｎ秒？」において、現クロック間隔（ＣＣＩ）が、Ｎ秒である最小の現クロック間隔より長いか否かの判断が行われる。ここでＮは好ましくは３に設定されるが、例えば２〜５秒の範囲であってもよい。判断の結果が肯定的な場合（段階５１２を「はい」から出る）、次の段階５１４の実行に続く。そうでない場合（段階５１２を「いいえ」から出る）、手順が復帰する（段階５３０）。Ｎの値は、動画バッファが過剰に、または過少に伝送されることを防ぐために、利用可能な帯域幅の変化に対して十分に迅速に応答出来るよう選択される。段階５１２は、現エンコードレートの実際の再評価（段階５２８、「ＱｏＳを計算」）が実質的に定期的に、およそＮ秒毎に確実に行われるようにする。

段階５１４「間隔インデックスをインクリメント」において、現間隔インデックス（ＣＩＩ）がインクリメントされる。間隔インデックスは、ＱｏＳが再計算される毎に増加させられなければならない。間隔インデックスは、平均間隔を計算する際の除数として用いられる。

段階５１６「合計クロック間隔を計算」において、新たなクロック間隔（現クロック間隔ＣＣＩ）でインクリメントすることにより現合計クロック間隔（ＣＩＳ）が更新される。次の段階において平均クロック間隔が計算され得るよう合計クロック間隔が保持される。

段階５１８「平均クロック間隔を計算」において、クロック間隔（ＣＩＳ）の現在の合計を上記の段階５１４で設定された現間隔インデックス（ＣＩＩ）で除算した結果として、平均クロック間隔（ＣＩＡ）を計算する。

段階５２０「一時停止を検出」において、推測として恐らくユーザがメディアを一時停止したであろうとヒューリスティックに示すのに十分な条件が分析される。これは情報に基づいた推測であり、確実であるというわけではない。段階５２０は、以下の図７において展開される。

段階５２２「一時停止を検出？」において、前の段階５２０の結果を用いて、恐らくユーザがメディアを一時停止したはずであるか否かの判断が行われる。一時停止が検出された場合（段階５２２を「はい」から出る）、次の段階５２４において一時停止の処理がされる。そうでない場合（段階５２２を「いいえ」から出る）、段階５２６の実行に続く。

段階５２４「一時停止を処理」において、利用可能な帯域幅が誤って過少評価されないようにアルゴリズムの変数が調整される。以下の図８により詳細に展開される段階５２４は、帯域幅の問題とユーザにより行われるメディアの一時停止とを区別しようと試みるために必要である。帯域幅の問題とユーザにより行われるメディアの一時停止との両方が、バッファの伝送の速度低下または停止に繋がる。

段階５２６「ＣＣＩ＝ＣＢＩ？」において、直前のトランスコーダバッファの送信時刻が、ウォールクロックにより示される実際の時刻に対応するか否かの判断が行われる。このことは、現バッファ間隔（ＣＢＩ）と現クロック間隔（ＣＣＩ）とが等しいことによって示される。それらが等しい場合（段階５２６を「はい」から出る）、ＱｏＳを再計算する必要はなく、段階５３０で復帰することにより段階４０８は終了される。そうでない場合（段階５２６を「いいえ」から出る）、次の段階５２８において新たなＱｏＳ値が計算される。

前の段階５２６の判断においてクロック間隔とバッファ間隔との間に差がある場合のみ、かつ、上記の段階５２２における判断で一時停止が検出されなかった場合のみ、段階５２８「ＱｏＳを計算」において、動的ビットレート適合ループ４１８の次の反復に備えて新たなＱｏＳ値が計算される。段階５２８の後、段階５３０で復帰することにより段階４０８の処理が終了される。段階５２８は、以下の図９においてより詳細に展開される。

図６は、以下の段階を含む、図５の段階５０８「ＱｏＳ計算を初期化」を展開したフローチャートを示す。
６０２：「前ＱｏＳ計算時刻≒現時刻」
６０４：「前バッファタイムスタンプ≒現バッファタイムスタンプ」
６０６：「間隔インデックス≒０」
６０８：「合計クロック間隔≒０」

トランスコード済バッファが送出される際、ＰｒｅｖｉｏｕｓＱｏＳＣａｌｃｕｌａｔｉｏｎＴｉｍｅ、ＰｒｅｖｉｏｕｓＢｕｆｆｅｒＴｉｍｅｓｔａｍｐ、ＩｎｔｅｒｖａｌＩｎｄｅｘ、および、ＣｌｏｃｋＩｎｔｅｒｖａｌＳｕｍの値が保存される。しかし、新たなセッションが開始される時であり、最初のトランスコード済バッファが送出される前に、これらの保存された値は初期化される必要がある（段階６０２〜６０８）。

段階６０２「前ＱｏＳ計算時刻≒現時刻」において、ＰｒｅｖｉｏｕｓＱｏＳＣａｌｃｕｌａｔｉｏｎＴｉｍｅが現時刻に初期化される。これはまだ最初のＱｏＳ計算であるので、実際には前ＱｏＳ計算時刻はない。この値は次のＱｏＳ計算で用いるために保存される。

段階６０４「前バッファタイムスタンプ≒現バッファタイムスタンプ」において、前バッファタイムスタンプの値が現バッファタイムスタンプに初期化される。これは最初のバッファであるので、実際には前バッファタイムスタンプはない。この値は次のＱｏＳ計算で用いるために保存される。

段階６０６「間隔インデックス≒０」において、間隔インデックスは０に初期化される。第１の間隔は最初の２つのバッファから計算されるので、これはまだ第１の間隔ではない。

段階６０８「合計クロック間隔≒０」において、合計クロック間隔は０に初期化される。段階６０６に関して説明したように第１の間隔はまだ存在しないので、まだ合計クロック間隔はない。

図７は、以下の段階を含む、図５の段階５２０「一時停止を検出」を展開したフローチャートを示す。
７０２：「間隔インデックス＞１？」
７０４：「一時停止推測回数＜ＭＰ？」
７０６：「（ＣＣＩ−ＣＩＡ）＞ＸＣ秒？」
７０８：「ＣＣＩ＞（ＣＩＡ×Ｍ）？」
７１０：「一時停止を検出≒「ＴＲＵＥ」」
７１２：「一時停止を検出≒「ＦＡＬＳＥ」」

段階７０２〜７０８は、一時停止が検出されたか否かを判断するために検証される複数の条件を備える。これらの条件の全てがＴＲＵＥであった場合のみ、一時停止が発生したものと見なされる。

段階７０２「間隔インデックス＞１？」において、間隔インデックスが１より大きいか否かの判断が行われる。判断の結果が否定的な場合（段階７０２を「いいえ」から出る）、段階７１２へスキップして実行する。そうでない場合、段階７０４において次の条件が検証される。

段階７０４「一時停止推測回数＜ＭＰ？」において、一時停止推測回数、つまり、一時停止検出回数が最大一時停止検出回数よりも少ないか否かの判断が行われる。好ましくはＭＰの値は、３に設定される。判断の結果が否定的な場合（段階７０４を「いいえ」から出る）、段階７１２へスキップして実行する。そうでない場合、段階７０６の次の条件が検証される。

段階７０６「（ＣＣＩ−ＣＩＡ）＞ＸＣ秒？」において、現クロック間隔（ＣＣＩ）が計算された平均クロック間隔（ＣＩＡ）よりも差「ＸＣ」秒超大きいか否かの判断が行われる。好ましくは、差ＸＣの値は１に設定される。判断の結果が否定的な場合（段階７０６を「いいえ」から出る）、段階７１２にスキップして実行される。そうでない場合、段階７０８において次の条件が検証される。

段階７０８「ＣＣＩ＞（ＣＩＡ×Ｍ）？」において、現クロック間隔（ＣＣＩ）の値が、計算された平均クロック間隔（ＣＩＡ）の係数「Ｍ」倍よりも大きいか否かの判断が行われる。判断の結果が否定的な場合（段階７０８を「いいえ」から出る）、段階７１２にスキップして実行される。そうでない場合、段階７１０の実行に続く。好ましくは係数「Ｍ」は４に設定される。

段階７１０「一時停止を検出≒「ＴＲＵＥ」」において、ブール変数ＰａｕｓｅＤｅｔｅｃｔｅｄ（ＰＤ）が「ＴＲＵＥ」に設定され、段階５２０の処理が完了する。

段階７１２「一時停止を検出≒「ＦＡＬＳＥ」」において、ブール変数ＰａｕｓｅＤｅｔｅｃｔｅｄ（ＰＤ）が「ＦＡＬＳＥ」に設定され、段階５２０の処理が完了する。

なお、定数「ＭＰ」、「ＸＣ」、および「Ｍ」の好ましい値は、単に利用可能な帯域幅の減少の検出ではなく、一時停止が発生したことを検出する際に合理的な「推測」が出来るように選択される。異なる値も有効でありうる。

図８は、以下の段階を含む、図５の段階５２４「一時停止を処理」を展開したフローチャートを示す。
８０２：「前の合計クロック間隔≒合計クロック間隔−現クロック間隔」
８０４：「合計クロック間隔≒前の合計クロック間隔＋（前の合計クロック間隔／（間隔インデックス−１））
８０６：「一時停止推測回数をインクリメント」

段階５２４の処理において、検出されたユーザによる一時停止は、関連する変数を更新することにより処理される。

段階８０２「前の合計クロック間隔≒合計クロック間隔−現クロック間隔」はより簡潔にＰＣＩＳ≒ＣＩＳ−ＣＣＩと表され得る。現合計クロック間隔から現クロック間隔の値が減算され、前の合計クロック間隔の値は、その前の値にリセットされる。

段階８０４「合計クロック間隔≒前の合計クロック間隔＋（前の合計クロック間隔／（間隔インデックス−１））はより簡潔にＣＩＳ≒ＰＣＩＳ＋（ＰＣＩＳ／（ＩＩ−１））と表され得る。現合計クロック間隔の値は、前の合計クロック間隔を間隔の数より１だけ少ない数（現在の一時停止間隔）で除算することにより計算される平均増分値だけインクリメントされた補正された前の合計クロック間隔から推定される値に設定される。

より簡潔にＰＧＣ≒ＰＧＣ＋１とも表され得る段階８０６「一時停止推測回数をインクリメント」において、一時停止推測回数が１だけインクリメントされ、所定の制限回数を超えて一時停止が検出されるのを防ぐ（上記の段階７０４を参照されたい）。

段階５２４の処理は主に、異常に長いクロック間隔によりユーザによる一時停止が検出された後の、合計クロック間隔の（よって、平均クロック間隔の）補正のための再計算である。その後の計算に影響を及ぼさないようにそのようなクロック間隔は廃棄され、平均クロック間隔で置き換えられる。ユーザによる一時停止は帯域幅の問題ではなく、ビットレートの修正に繋がるべきではないので、ユーザによる一時停止は基本的に無視される。

図９は、以下の段階を含む、図５の段階５２８「ＱｏＳを計算」を展開したフローチャートである。
９０２：「ＣＢＩ＞ＣＣＩ？」
９０４：「Ｄｅｌｔａ１≒ＣＢＩ−ＣＣＩ」
９０６：「Ｄｉｆｆｅｒｅｎｃｅ１≒Ｄｅｌｔａ１／ＣＢＩ」
９０８：「Ｄｉｆｆｅｒｅｎｃｅ１＞ＴＨ１？」
９１０：「ＱｏＳ≒１．０＋Ｄｉｆｆｅｒｅｎｃｅ１／ＡＦ１」
９１２：「Ｄｅｌｔａ２≒ＣＣＩ−ＣＢＩ」
９１４：「Ｄｉｆｆｅｒｅｎｃｅ２≒Ｄｅｌｔａ２／ＣＣＩ」
９１６：「Ｄｉｆｆｅｒｅｎｃｅ２＞ＴＨ２？」
９１８：「ＱｏＳ≒１．０＋Ｄｉｆｆｅｒｅｎｃｅ２／ＡＦ２」
９２０：「前ＱｏＳ計算時刻≒現時刻」
９２２：「前バッファタイムスタンプ≒現バッファタイムスタンプ」

段階５２８の処理において、ＱｏＳ値は、ＣｕｒｒｅｎｔＣｌｏｃｋＩｎｔｅｒｖａｌ（ＣＣＩ）とＣｕｒｒｅｎｔＢｕｆｆｅｒＩｎｔｅｒｖａｌ（ＣＢＩ）との間の差から推定される見かけ上のリンク帯域幅の変化を評価し、それに応じて変化に対応すべくＱｏＳをインクリメントまたはデクリメントすることにより再計算される。

段階９０２〜９１８は、図３のＱｏＳアジャスタモジュール３２０の機能の例示としてのビットレート適合機能９２４に設けられる。

段階９０２「ＣＢＩ＞ＣＣＩ？」において、ＣＢＩ（現バッファ間隔）の値が、ＣＣＩ（現クロック間隔）の値よりも大きいか否かの判断が行われる。ＣＢＩがＣＣＩよりも大きい場合、ＱｏＳの値は段階９０４〜９１０で計算されるように増加させられる。そうでない場合、ＱｏＳの値は、段階９１２〜９１８で計算されるように減少させられる。先の段階５２６（図５）でＣＢＩがＣＣＩに等しくないと判断された場合にのみ段階９０２に移行する。

段階９０４「Ｄｅｌｔａ１≒ＣＢＩ−ＣＣＩ」は、現バッファ間隔が現クロック間隔より大きい場合、つまり、ビットレートが増加させられるべきである場合の、現クロック間隔と現バッファ間隔との間の差分（Ｄｅｌｔａ１）の計算を示す。

段階９０６「Ｄｉｆｆｅｒｅｎｃｅ１≒Ｄｅｌｔａ１／ＣＢＩ」は、現バッファ間隔がどの程度比例して現クロック間隔よりも大きいのかを示すための、第１の相対差（Ｄｉｆｆｅｒｅｎｃｅ１）の計算を示す。Ｄｉｆｆｅｒｅｎｃｅ１の値は、段階９０４で計算される差分（Ｄｅｌｔａ１）を現バッファ間隔で除算することにより得られる。その後新たなＱｏＳ値が段階９１０で計算されるが、これは、段階９０８「Ｄｉｆｆｅｒｅｎｃｅ１＞ＴＨ１？」でＤｉｆｆｅｒｅｎｃｅ１が第１の閾値「ＴＨ１」よりも大きいと判断された場合のみである。閾値は、非常に小さな変動に応じてビットレートが修正されるのを防ぐのに役立つ。

段階９０８「Ｄｉｆｆｅｒｅｎｃｅ１＞ＴＨ１？」において、前の段階で計算された第１の相対差が第１の閾値を超えるか否かの判断が行われる。好ましくは第１の閾値ＴＨ１は、５％の相対差に対応して少なくとも０．０５に設定される。第１の相対差が第１の閾値を超える場合（段階９０８を「はい」から出る）、次の段階９１０が続いて実行され、ＱｏＳの値が調整される。そうでない場合、ＱｏＳは調整されず、段階９２０にスキップして実行される。

段階９１０「ＱｏＳ≒１．０＋差１／ＡＦ１」は、ビットレートが第１の増分値だけ増加させられるべきであると判断された場合に新たなＱｏＳ値がどのように計算されるかを示す。１．０という値は修正を行わないことを示し、より小さいＱｏＳ値はビットレートを減少させることを示し、より高いＱｏＳ値はビットレートを増加させることを示す。よって、調整されたＱｏＳ値は、この場合１．０よりも大きい。段階９１０において、第１の増分値は、上記の段階９０６からの第１の相対差（Ｄｉｆｆｅｒｅｎｃｅ１）を、好ましくはおよそ８．０である第１の減衰係数「ＡＦ１」で除算することにより計算される。１．０に加算される第１の増分値は新たなＱｏＳ値となり、エンコーダに送信され（段階４１２、図４）、（エンコードビットレートに対応する）ＱｏＳ係数が第１の増分値だけ増加させられる。

段階９１２「Ｄｅｌｔａ２≒ＣＣＩ−ＣＢＩ」は、現バッファ間隔が現クロック間隔よりも大きくない場合、つまり、ビットレートを減少させるべき、または変更しないでおくべきである場合の、現クロック間隔と現バッファ間隔との間の差分（Ｄｅｌｔａ２）の計算を示す。

段階９１４「差２≒Ｄｅｌｔａ２／ＣＣＩ」は、現クロック間隔がどれくらい現バッファ間隔よりも大きいかを示す割合としての第２の相対差の計算を示す。差２の値は、段階９１２で計算される差分（Ｄｅｌｔａ２）を現クロック間隔で除算することにより得られる。その後新たなＱｏＳ値が段階９１８で計算されるが、これは、段階９１６「差２＞ＴＨ２？」で差２が第２の閾値「ＴＨ２」よりも大きいと判断された場合のみである。このことは、非常に小さな変動に応じてビットレートが修正されるのを防ぐのに役立つ。

段階９１６「差２＞ＴＨ２？」において、前の段階で計算された第２の相対差が第２の閾値を超えるか否かの判断が行われる。好ましくは第２の閾値ＴＨ２は、２％の相対差に対応して少なくとも０．０２に設定される。第２の相対差が第２の閾値を超える場合（段階９１６を「はい」から出る）、次の段階９１８が続いて実行され、ＱｏＳの値が調整される。そうでない場合、ＱｏＳは調整されず、段階９２０にスキップして実行される。

閾値ＴＨ１、ＴＨ２は、非常に小さな変動に応じて不必要にビットレートが修正されるのを防ぐのに役立つ。

段階９１８「ＱｏＳ≒１．０＋差２／ＡＦ２」は、ビットレートが第２の増分値だけ減少させられるべきであると判断された場合に新たなＱｏＳ値がどのように計算されるかを示す。段階９１８において、第２の増分値は、段階９１４からの第２の相対差（差２）を、好ましくはおよそ６．０である第２の減衰係数「ＡＦ２」で除算することにより計算される。１．０に加算される第２の増分値は新たなＱｏＳ値となり、エンコーダに送信され（段階４１２、図４）、（エンコードビットレートに対応する）ＱｏＳ係数が第２の増分値だけ減少させられる。

減衰係数ＡＦ１、ＡＦ２の値は、調整アルゴリズムの安定性を確保すべく、つまり、エンコードレート（ＱｏＳ値）の過剰な、または急激過ぎる過度な補正を防ぐべく選択される。調整係数を用いない場合、エンコードレートの調整毎に、エンコードレートが高過ぎる値と低過ぎる値の間をいつまでも行ったり来たりすることになるであろう。調整係数は各補正の影響を低減させ、ある種の減衰効果を有するので、理想的にはエンコードレートは複数の調整間隔を経て送信ビットレートにいずれ近づく。他方、調整係数が大き過ぎる場合（過剰な減衰）、エンコードレートが送信ビットレートへ近づくのは遅過ぎるようになる。調整係数ＡＦ１、ＡＦ２を公正に選択することにより、補正が十分に早く達成される。

段階９２０「前ＱｏＳ計算時刻≒現時刻」において、各ＱｏＳ計算の後、現時刻が前ＱｏＳ計算時刻（ＰＱＣＴ）として保存されるので、ＰＱＣＴの値は、動的ビットレート適合ループ４１８（図４）の次の反復の計算段階５１０（図５）において用いられ得る。

同様に、段階９２２「前バッファタイムスタンプ≒現バッファタイムスタンプ」において、各ＱｏＳ計算の後、現バッファタイムスタンプが前バッファタイムスタンプ（ＰＢＴＳ）として保存されるので、ＰＢＴＳの値は、動的ビットレート適合ループ４１８（図４）の次の反復の計算段階５１０（図５）において用いられ得る。

パラメータ「ＴＨ１」、「ＴＨ２」、「ＡＦ１」、「ＡＦ２」の好ましい値は、説明されるような所望される調整処理を実現するように選択された。他の値も同様に良好に、またはより良好に機能し得る。例えば、「ＴＨ１」および「ＴＨ２」はそれぞれ、少なくとも０．０５および０．０２に設定されることが提案され、「ＡＦ１」および「ＡＦ２」の提案される値（それぞれ８．０および６．０）はおよその値に過ぎない。

図１０は、以下の段階を含む、図４の段階４１２「新たなＱｏＳ値を適用」を展開したフローチャートである。
１００２：「ＱｏＳ修正要求をエンコーダに通知」
１００４：「ＱｏＳ修正要求を受け付け」
１００６：「ＱｏＳを現エンコードビットレートに適用」
１００８：「エンコードビットレートを制限」

動的ビットレートアダプタ３１０（図３）において段階１００２が実行され、更新されたＱｏＳ値が、動的ビットレートアダプタ３１０からトランスコーダ３１４（図３）へ伝えられ、トランスコーダ３１４において残りの段階１００４〜１００８が実行される。なおトランスコーダ３１４は、可変ビットレートトランスコーダサブシステム２０２内のＤＢＲＡアダプタ３１０からＱｏＳ修正通知を受信可能である。

段階１００２「エンコーダにＱｏＳ修正要求を通知」において、ＱｏＳの通知を備えるイベントが動的ビットレートアダプタ３１０からトランスコーダ３１４へ送信される。

段階１００４「ＱｏＳ修正要求を受け付け」において、トランスコーダ３１４がＱｏＳの通知を受信し、受け付ける。

段階１００６「現エンコードビットレートにＱｏＳを適用」において、この変更通知を受信するとトランスコーダ３１４は、有効なエンコードビットレートを修正する。ビットレートの差は、新たなＱｏＳ値に応じて、かつ比例して変化する。

段階１００８「エンコードビットレートを制限」において、エンコードビットレートを新たなＱｏＳ値に対応するように修正する際、新たなＱｏＳ値を適用した計算の結果、ビットレートが、設定された最低値と最高値との範囲外になったとしても、実際のエンコードビットレートを当該範囲内に収める。

本願発明の実施形態に係る、（オリジナルのサービスとも呼ばれる）ＤＢＲＡアルゴリズムは、以下の段階にまとめられ得る。
（ａ１）サーバまたはプロキシと、モバイルユニットとの間にＨＴＴＰセッション（トランスコードセッション、または単に「セッション」）が確立される。
（ｂ１）モバイルユニットとの初期ビットレート（エンコードレート）が設定される。
（ｃ１）モバイルユニットがＨＴＴＰ−ＧＥＴを用いてメディアファイルを要求する。
（ｄ１）上述したようにビットレートを操作しつつ、トランスコード済メディアの全体がサーバから送信される。追加のＧＥＴ要求をモバイルユニットから受信しない。
（ｅ１）トランスコード済メディアの送信が完了すると、ＨＴＴＰセッションが閉じられる。

初期ビットレートは、セッションの構成において、トランスコードされているオリジナルのメディアのビットレート、およびモバイルユニットのプロフィールに基づき決定される。オリジナルのサービスは追加のＨＴＴＰ要求を受信することなく、徐々にメディアをトランスコードしクライアントへ送信する。メディアの送信が完了すると（またはクライアントがアボートすると）セッションは閉じられる。ビットレートは、各バッファが送信された後に修正され得る。

本願発明の他の実施形態において、（修正されたサービスとも呼ばれる）修正されたＤＢＲＡアルゴリズムが提案され、修正されたＤＢＲＡアルゴリズムは、以下の段階にまとめられ得る。
（ａ２）サーバまたはプロキシと、モバイルユニットとの間にトランスコード（ＨＴＴＰ）セッションが確立される。
（ｂ２）モバイルユニットとの初期ビットレートが設定される。
（ｃ２）モバイルユニットがＨＴＴＰ−ＧＥＴを用いてメディアファイルのセグメントを１つだけ要求する。
（ｄ２）セグメントを送信する間、ビットレートを操作せずに、トランスコード済メディアセグメントがサーバから送信される。
（ｅ２）セグメントの送信が完了すると、モバイルユニットが他のセグメントを要求（ＧＥＴ）することを決定するまでセッションが中断される。決定した場合、次に進む。
（ｆ）前のセグメント送信の保存されたパラメータに基づき次のセグメントのために新たなビットレートが計算される。
（ｇ）トランスコードセッションが継続される。つまり、段階（ｃ２）に進む。

なお、モバイルユニットにより要求される各セグメントは、１以上のメディアフラグメントにより構成される。修正されたサービスのトランスコード済メディアセグメントは、エンコードレートの調整に関し、オリジナルのサービスのストリームフラグメントに実質的に対応する。異なる点は、オリジナルのサービスのストリームフラグメントが時間（およそＮ秒の間隔）によって区切られており、修正されたサービスにおいては、トランスコード済メディアセグメント（ストリームフラグメント）は、モバイルユニットに要求されるセグメントに従って画定されるという点である。

修正されたＤＢＲＡアルゴリズムは、例えばＡｐｐｌｅ Ｉｎｃ．により製造されるｉＰｈｏｎｅ（登録商標）などの特定のスマートフォンの使用規格に対応するよう設計されており、トランスコードセッション（ＨＴＴＰセッション）内の個別の、しかし関連した短いセグメントセッション（ＴＣＰセッション）がメディアコンテンツをダウンロードするために確立される。

修正されたＤＢＲＡアルゴリズムにおいて、トランスコードされているオリジナルのメディアのビットレート、およびモバイルユニットのプロフィール（構成）に基づき初期ビットレートが決定される。クライアント、つまりモバイルユニットは、ＨＴＴＰを用いてメディアを要求する。クライアントは最初に、どのセグメントが存在し、どこに位置するのかを知らせるプレイリストを受信する。まだトランスコードは関わらない。その後クライアントはＨＴＴＰを用いてセグメントを要求する。そのような最初の要求があると、修正されたサービスによりサーバ上でトランスコードセッションが作成される。トランスコードセグメント状態、つまり時間間隔などに保持される情報に基づき、各セグメントに適用される連続的なビットレートの調整が決定される。修正されたサービスは、セグメントをトランスコードし、トランスコード済メディアフラグメントに含まれるトランスコード済セグメントを送信する。トランスコード済メディアフラグメント（トランスコード済バッファ）は、セグメントの最後に到達するまでクライアントへ送信される。その後クライアントは、送信されたセグメントがプレイリストの最後のセグメントでない限り、または、クライアントがアボートしない限り次のセグメントを要求する。送信されたセグメントが最後のセグメントである場合、または、クライアントがアボートした場合、その時点でトランスコードセッションはサーバ上で終了する。修正されたサービスはトランスコードされている各セグメントが同じトランスコードセッションの一部であることを認識し、要求された次のセグメントのそれぞれを再調整されたビットレートでトランスコードし、送信する。

あるセグメントがトランスコードされる前に、トランスコードセグメント状態を用いて、初期の（元の）ビットレートに適用する割合を判断する。トランスコード後のビットレートは初期ビットレートよりも高くなり得ないので、割合は１００％より高くはなり得ない。

オリジナルのサービスは１つのセッション内でのメディアファイルの送信を実現し、当該１つのセッションの間に、（少ない場合には１つのトランスコード済メディアフラグメントを含み得る）それぞれのトランスコード済ストリームフラグメントが送信された後にトランスコーダのビットレートが調整され得る。他方、修正されたサービスにおいては、（メディアセグメントとも呼ばれる）個々のセグメントがそれぞれ別個の関連するセグメントセッションで送信され、最初に確立されたビットレートが用いられる第１のセッションの前を除き各セグメントセッションの前にトランスコーダのビットレートが調整される。１つのセグメントが一連のトランスコード済バッファ（トランスコード済メディアフラグメント）としても送信されるが、同じセグメント内のバッファ単位ではビットレートの修正を行うことは提案されない。

最初のセグメントのＱｏＳ値（ビットレート）はモバイルユニットにより確立され、モバイルユニットの特性の関数である。続くセグメントのそれぞれのトランスコードが開始される前に、以下の図１２に詳細に説明されるようにＱｏＳ値が計算される（直前のセグメントの期間の長さをセグメント開始間隔で除算し、前のセグメントが要求された時に最後に保存されたＱｏＳで乗算する）。「累積の」保存されたＱｏＳ値を直前のセグメントに基づいて計算された値で乗算することにより、セグメントが要求される毎にトランスコーダのビットレート（つまりＱｏＳ）が再調整される。その値は、次のセグメントのトランスコードを開始する前にセグメントの初期ビットレートに適用される係数を提供する。セグメント要求は要求に示される（元の）初期ビットレートを有するセグメントファイルの新たな接続であるので、初期ビットレートのどの割合で次のセグメントをトランスコードすべきかを覚えておく必要がある。その後その割合は、他のセグメントが要求される毎に調整される。

修正されたサービスの「開始間隔」は、オリジナルのサービスの「現クロック間隔」に対応する。それら両方が、推定表示時間との比較のために推定送信時間を計算するのに用いられる。推定表示時間は、修正されたサービスにおいてはフラグメントのセグメントの表示時間であり、オリジナルのサービスにおいてはストリームフラグメント、つまり、およそ３秒の間隔毎に送信されるトランスコード済メディアフラグメントの表示時間である。

修正されたサービスにおいては、メディアセグメントが十分に短いものと想定されているので、ビットレートはセグメントの間に変更される必要がない、つまり、複数のトランスコード済バッファ（トランスコード済メディアフラグメント）が、前のメディアセグメントが送信された後に確立されたビットレートで送信される。ビットレートはセグメント間のみで変更され得る。

オリジナルのサービスにおける一時停止の検出は、平均クロック間隔を用いて直前のクロック間隔が「異常に」長いか否かを判断する。修正されたサービスにおける一時停止の検出は、対応する、平均開始間隔（２つのセグメント要求間の時間）を用いて、直前の開始間隔がかなり長過ぎるか否かを判断する。よって、セグメントの送信の間には一時停止の検出は試みられない。一時停止が検出された場合、これはセグメントが要求されたということであり、直前のセグメントが要求されてから長い時間が経ったということが理解される。他の条件（一時停止が検出された回数、および間隔が通常とどの程度異なるか、など）が満たされた場合、動画が一時停止されたものと想定または推測され、ビットレートの修正は行われない。

両方の実施形態を組み合わせる、または少なくとも部分的に組み合わせることが可能である。つまり、各セグメントのトランスコード済バッファに関して、あるセグメントの間の一時停止の検出を含むオリジナルのサービスを実行し、その後累積の平均のセグメントビットレートに従って次のセグメントに関しＱｏＳをリセットする。セグメント内のバッファの処理に関してオリジナルのサービスのいくつかを組み込むことが可能である。

図１１は、以下の段階を含む、本願発明の他の実施形態に係る修正された動的ビットレート適合処理１１００のフローチャートを示す。
１１０２：「１つのセグメントをダウンロードするためにモバイルが接続」
１１０４：「セッションが存在するか？」
１１０６：「セッションを作成」
１１０８：「セグメントＱｏＳを再評価」
１１１０：「セグメントＱｏＳ値を保存」
１１１２：「保存されたセグメントＱｏＳを適用」
１１１４：「セグメントのトランスコードを開始」
１１１６：「次のトランスコード済バッファを生成」（＝４０４）
１１１８：「トランスコード済バッファを送信」（＝４０６）
１１２０：「セグメントの最後に到達したか？」

修正された動的ビットレート適合（ＭＤＢＲＡ）処理１１００は、モバイルユニットがメディア処理サーバ３０２（図３）から複数のセグメントを含むプレイリストを取得した後に開始される段階１１０２〜１１２０を含むループを備える。ＭＤＢＲＡ処理１１００は、必要に応じてセグメントをダウンロードするために接続するモバイルユニットにより発せられる要求に応答してのメディアセグメントのトランスコードおよび送信を網羅する。トランスコードセッションは第１の接続が確立された時に作成され、続く要求のために用いられる。ＭＤＢＲＡ処理１１００は、モバイルユニットがサーバとの接続を切断した場合、またはアボートした場合に終了する（図１１に図示せず）。

第２のセグメントについて開始すると、新たなセグメントが要求される毎に段階１１０８「セグメントＱｏＳを再評価」および段階１１１０「セグメントＱｏＳ値を保存」が、現在のセグメントの開始間隔が知られるトランスコードの直前に実行される。その時、段階１１０８で説明したように、直前のセグメントの期間の長さを現セグメント開始間隔で除算することにより計算されるＱｏＳ調整係数で最後（つまり、セグメントが要求された前の時刻）に保存されたＱｏＳ値を乗算することにより、新たなＱｏＳ値（エンコードビットレート）が計算され得る。言い換えると、ＱｏＳ値は計算される毎に保存され、直前のセグメントに基づき計算された値で保存された値を乗算することにより、他のセグメントが要求される毎に再調整される。この値は、トランスコードする前のセグメントの初期ビットレートに適用される係数を提供する。各セグメント要求は（元の）初期ビットレートを有するセグメントファイルの新たな接続であるので、初期ビットレートのどの割合でトランスコードすべきかをセグメント単位で覚えておく必要がある。その後その割合は、セグメントが要求される毎に調整される。

段階１１０２「１つのセグメントをダウンロードするためにモバイルが接続」において、モバイルユニットは接続を行い１つのセグメントを要求する。

段階１１０４「セッションが存在するか？」において、サーバとモバイルユニットとの間のトランスコードセッションが既に存在するか否かの判断が行われる。判断の結果が肯定的な場合（段階１１０４を「はい」から出る）、段階１１０８の実行に続く。そうでない場合（段階１１０４を「いいえ」から出る）、次の段階１１０６においてトランスコードセッションが作成される。

段階１１０６「セッションを作成」において、モバイルユニットのプロフィール（構成）に従って初期トランスコードビットレート（ＱｏＳ＝１．０）が確立される。その後、段階１１１４の実行に続く。

段階１１０８「セグメントＱｏＳを再評価」において、最後に完了したセグメントをトランスコードするのに用いられた保存されたＱｏＳ値を、この最後に完了したセグメントと前のセグメントとの間の時間間隔に基づき再評価する。段階１１０８は以下の図１２においてより詳細に展開されている。

段階１１１０「セグメントＱｏＳ値を保存」において、新たに計算されたセグメントＱｏＳ値が、次のセグメントのトランスコードに備えて保存される。

段階１１１２「保存されたセグメントＱｏＳを適用」において、図１０に詳細に説明された段階４１２と類似して、新たに保存されたＱｏＳ値が適用され、つまりトランスコーダ３１４に送信される。

段階１１１４「セグメントのトランスコードを開始」において、現在のセグメントのトランスコードが開始される。この段階は段階４０２と類似している。

ＭＤＢＲＡ処理１１００の段階１１１６「次のトランスコード済バッファを生成」および段階１１１８「トランスコード済バッファを送信」はそれぞれ、ＤＢＲＡ処理４００の段階４０４および４０６と類似している。

段階１１２０「セグメントの最後に到達したか？」において、現在送信されているセグメントの最後に到達したか否かが判断される。判断の結果が否定的な場合（段階１１２０を「いいえ」から出る）、次のバッファを処理するためにループを戻って段階１１１６が実行される。そうでない場合（段階１１２０を「はい」から出る）、段階１１０２が続いて実行され、モバイルユニットにより次のセグメントが要求されるのを待つ。

図１２は、以下の工程を含む、図１１のセグメントＱｏＳ再評価段階１１０８のより詳細なフローチャートである。
１２０２：「ＴＴＲ≧１．０？」
１２０４：「最初のセグメントＱｏＳ計算か？」
１２０６：「セグメントＱｏＳ計算を初期化」
１２０８：「現開始間隔（ＣＳＩ）および出力されたセグメントの期間の長さ（ＯＳＤ）を計算」
１２１０：「間隔インデックスをインクリメント」
１２１２：「合計開始間隔を計算」
１２１４：「平均開始間隔を計算」
１２１６：「セグメントの一時停止を検出」
１２１８：「セグメントの一時停止（ＳＰ）が検出されたか？」
１２２０：「セグメントの一時停止を処理」
１２２２：「ＬａｓｔＳｅｇｍｅｎｔＱｏＳ≒ＯＳＤ／ＣＳＩ」
１２２４：「ＳＱｏＳ≒ＳＱｏＳ×ＬａｓｔＳｅｇｍｅｎｔＱｏＳ」

セグメントＱｏＳ再評価段階１１０８は、（図５で展開される）図４のＤＢＲＡ処理のＱｏＳ再評価段階４０８に似ている。両者の差異は、クロック間隔およびバッファ間隔のそれぞれの代わりに、セグメント開始間隔および出力されたセグメントの期間の長さの値を用いることに起因する。

段階１２０２「ＴＴＲ≧１．０？」において、現在のＴｒａｎｓｃｏｄｉｎｇＴｈｒｏｔｔｌｉｎｇＲａｔｅが１．０以上か否かの判断が行われる。判断の結果が肯定的な場合（段階１２０２を「はい」から出る）、次の段階１２０４の実行に続く。そうでない場合（段階１２０２を「いいえ」から出る）、ビットレートを減少させるためのトランスコードは必要ではなく、手順が復帰する。

段階１２０４「最初のセグメントＱｏＳ計算か？」において、これがセグメントに関して最初のＱｏＳ計算か否かの判断が行われる。セグメントＱｏＳによりトランスコーダバッファの送信だけでなくセグメント全体のトランスコーダのビットレートが決まるのでセグメントＱｏＳは図５の単純なＱｏＳとは異なる。これが最初のセグメントＱｏＳ計算である場合（段階１２０４を「はい」から出る）、図１３において以下に展開される段階１２０６「セグメントＱｏＳ計算を初期化」の実行に続く。これが最初のセグメントＱｏＳ計算ではない場合（段階１２０４を「いいえ」から出る）、段階１２０８の実行に続く。

段階１２０８「現開始間隔（ＣＳＩ）および出力されたセグメントの期間の長さ（ＯＳＤ）を計算」において、現開始間隔および出力されたセグメントの期間の長さが以下のように計算される。
ＣＳＩ≒ＣＴ−ＰＳＳＴ
ここでＣＴは現時刻であり、
ＰＳＳＴはＰｒｅｖｉｏｕｓＳｅｇｍｅｎｔＳｔａｒｔＴｉｍｅである。
ＯＳＤ≒直前に出力されたセグメントの期間の長さ

段階１２０８は幾分、図５の段階５１０と同様であるが、直前のセグメントのトランスコード済メディアフラグメントに埋め込まれたタイムスタンプにより提供される、直前のセグメントの開始時刻（現開始間隔）および期間の長さ（表示時間）を頼りとする。

段階１２１０「間隔インデックスをインクリメント」において、現間隔インデックス（ＣＩＩ）がインクリメントされる。間隔インデックスは、ＱｏＳが再計算される毎に増加させられる。これは平均間隔を計算する際の除数として用いられる。段階１２１０は図５の段階５１４と同一である。

段階１２１２「合計開始間隔を計算」において、ＳｔａｒｔＩｎｔｅｒｖａｌＳｕｍ（ＳＩＳ）がＣｕｒｒｅｎｔＳｔａｒｔＩｎｔｅｒｖａｌの分だけインクリメントさせられる。段階１２１２が図５の段階５１６と同様であるが、クロック間隔（ＣＣＩ）の代わりに開始間隔（ＣＳＩ）の合計を提供する。

段階１２１４「平均開始間隔を計算」において、ＳｔａｒｔＩｎｔｅｒｖａｌＳｕｍをＩｎｔｅｒｖａｌＩｎｄｅｘで除算することによりＳｔａｒｔＩｎｔｅｒｖａｌＡｖｅｒａｇｅ（ＳＩＡ）が計算される。段階１２１４は、図５の段階５１８と同様であるが、クロック間隔の代わりに開始間隔の平均を提供する。

段階１２１６「セグメントの一時停止を検出」は図５の段階５２０「一時停止を検出」に類似しているが、ＣＣＩおよびＣＩＡの代わりに、ＰａｕｓｅＤｅｔｅｃｔｅｄのブール値を決定するのにＣＳＩおよびＳＩＡ変数をそれぞれ用いる。

段階１２１８「セグメントの一時停止（ＳＰ）が検出されたか？」は、図５の段階５２２「一時停止を検出」に類似している。段階１２１８において、前の段階１２１６の結果を用いて、恐らくユーザがメディアを一時停止したであろうか否かの判断が行われる。セグメントが要求され、直前のセグメントが要求されてから長い時間が経っていることが理解された場合、セグメントの一時停止が検出される。セグメントの一時停止が検出された場合（段階１２１８を「はい」から出る）、次の段階１２２０においてセグメントの一時停止が処理される。そうでない場合（段階１２１８を「いいえ」から出る）、段階１２２２の実行に続く。

段階１２２０「セグメントの一時停止を処理」は図５の段階５２４「一時停止を処理」と類似しており、主に、異常に長いセグメントの間隔に基づきユーザによる一時停止が検出された後に、合計セグメント開始間隔（段階５２４の合計クロック間隔の代わりに。図８を参照されたい）の補正のための再計算である。

段階１２２２「ＬａｓｔＳｅｇｍｅｎｔＱｏＳ≒ＯＳＤ／ＣＳＩ」において、直前のセグメントのトランスコードに用いられた（相対的なビットレートに対応する）ＱｏＳ調整係数である変数「ＬａｓｔＳｅｇｍｅｎｔＱｏＳ」は、直前に出力されたセグメントの期間の長さ（ＯＳＤ）、つまり、直前のセグメントの推定表示時間を、現開始間隔、つまり、直前のセグメントの推定送信時間で除算することにより計算される。

段階１２２４「ＳｅｇｍｅｎｔＱｏＳ（ＳＱｏＳ）≒ＳＱｏＳ×ＬａｓｔＳｅｇｍｅｎｔＱｏＳ」において、ＬａｓｔＳｅｇｍｅｎｔＱｏＳが現セグメントＱｏＳで乗算され、次のセグメントのトランスコードに用いられるセグメントＱｏＳを求める。段階１２２４の後、セグメントのＱｏＳの再評価処理１１０８が完了し、新たに計算されたＳｅｇｍｅｎｔＱｏＳ値が保存される（図１１の段階１１１０）。

図１３は、以下の段階を含む、図１２の「セグメントＱｏＳ計算を初期化」段階１２０６のより詳細なフローチャートである。
１３０２：セグメントＱｏＳを１．０に初期化するための「セグメントＱｏＳ≒１．０」
１３０４：前のセグメントがまだ存在しないので、前のセグメントの開始時間を「利用不可能（Ｎ／Ａ）」の値に初期化するための「前のセグメントの開始時間≒Ｎ／Ａ」
１３０６：間隔インデックスを０に初期化するための「間隔インデックス≒０」
１３０８：合計開始間隔を０に初期化するための「合計開始間隔≒０」

段階１２０６の目的は図５の段階５０８と類似しており、最初のセグメントがトランスコードされる前に変数を初期化することである。

帯域幅が変化する接続を介した送信のためのメディアファイルの帯域幅の適合を提供する方法およびシステムが本願発明の実施形態により提供されるので、経時的に帯域幅が変化するネットワークを介してのＨＴＴＰマルチメディア配信のユーザ体験が向上する。

ＨＴＴＰ以外の、ネットワークを介してメディアファイルをストリーミングするためのプロトコルが本願発明の範囲に含まれる。そのようなプロトコルは、モバイルユニットから動的ビットレートアダプタへアプリケーションレベルのフィードバックを提供する必要はなく、信頼出来る配信メカニズムを提供するものと想定される。

一時停止を検出するための追加のパラメータまたは方法も想到され得、理論的に検討することにより、または純粋に実験的に開発され得る。そのような改良は、本開示の範囲に含まれるものと見なされる。

本願発明の実施形態において、トランスコーダ３１４は、プロセッサにより実行される、メモリに格納されたコンピュータ可読命令を有するソフトウェアを備える。しかし代替的に、トランスコーダ３１４は、デジタル信号プロセッサ（ＤＳＰ）チップまたは特定用途向け集積回路（ＡＳＩＣ）内のコプロセッサなど別個のプロセッサ上のハードウェアとしても実装され得る。

本願発明の特定の実施形態について詳細に説明してきたが、説明された実施形態は例示的であり限定的ではないことを理解されたい。本願発明の幅広い態様内でその範囲から逸脱することなく、実施形態の様々な変更および修正が以下の請求項の範囲内で加えられ得る。

図９は、以下の段階を含む、図５の段階５２８「ＱｏＳを計算」を展開したフローチャートである。
９０２：「ＣＢＩ＞ＣＣＩ？」
９０４：「Ｄｅｌｔａ１≒ＣＢＩ−ＣＣＩ」
９０６：「Ｄｉｆｆｅｒｅｎｃｅ１≒Ｄｅｌｔａ１／ＣＢＩ」
９０８：「Ｄｉｆｆｅｒｅｎｃｅ１＞ＴＨ１？」
９１０：「ＱｏＳ≒１．０＋Ｄｉｆｆｅｒｅｎｃｅ１／ＡＦ１」
９１２：「Ｄｅｌｔａ２≒ＣＣＩ−ＣＢＩ」
９１４：「Ｄｉｆｆｅｒｅｎｃｅ２≒Ｄｅｌｔａ２／ＣＣＩ」
９１６：「Ｄｉｆｆｅｒｅｎｃｅ２＞ＴＨ２？」
９１８：「ＱｏＳ≒１．０−Ｄｉｆｆｅｒｅｎｃｅ２／ＡＦ２」
９２０：「前ＱｏＳ計算時刻≒現時刻」
９２２：「前バッファタイムスタンプ≒現バッファタイムスタンプ」

段階９１８「ＱｏＳ≒１．０−Ｄｉｆｆｅｒｅｎｃｅ２／ＡＦ２」は、ビットレートが第２の増分値だけ減少させられるべきであると判断された場合に新たなＱｏＳ値がどのように計算されるかを示す。段階９１８において、第２の増分値は、段階９１４からの第２の相対差（Ｄｉｆｆｅｒｅｎｃｅ２）を、好ましくはおよそ６．０である第２の減衰係数「ＡＦ２」で除算することにより計算される。１．０から第２の増分値を減算することにより得られる値が新たなＱｏＳ値となり、エンコーダに送信され（段階４１２、図４）、（エンコードビットレートに対応する）ＱｏＳ係数が第２の増分値だけ減少させられる。

Claims (16)

1. 帯域幅が変化するリンクを介した宛て先ユニットへのリアルタイム送信のために、メディアファイルまたはその一部をエンコードするための方法であり、
   前記方法は、少なくとも１つのプロセッサを用いて、
   （ｉ）前記メディアファイルの１以上のフラグメントをトランスコード済メディアフラグメントへエンコードし、ストリームフラグメントを形成する段階と、
   （ｉｉ）前に形成されたストリームフラグメントをトランスコーダから伝送し、前記帯域幅が変化するリンクが消費するのに要する時間間隔である、前記前に形成されたストリームフラグメントの推定送信時間を判断する段階と、
   （ｉｉｉ）前記推定送信時間の関数として、前記トランスコード済メディアフラグメントの現エンコードレートを調整する段階と
   を実行する方法。
2. 前記段階（ｉ）は、
   初期エンコードレートで、前記メディアファイルの少なくとも第１のフラグメントを、対応する第１のトランスコード済メディアフラグメントにエンコードする段階と、
   前記初期エンコードレートに等しい前記現エンコードレートを設定する段階と
   を有し、
   前記段階（ｉｉｉ）は、調整された前記現エンコードレートで、前記メディアファイルの後続のフラグメントを、対応するトランスコード済メディアフラグメントにエンコードする段階を有する、請求項１に記載の方法。
3. 前記段階（ｉｉｉ）はさらに、２つの前に形成されたストリームフラグメントに関連するタイムスタンプから導出される、前記宛て先ユニットにおける前記ストリームフラグメントの推定表示時間の関数として、前記現エンコードレートを調整する段階を有する、請求項１または２に記載の方法。
4. 前記段階（ｉｉ）はさらに、現時刻と直前のエンコード時の時刻である前の時刻との間の現クロック間隔として、前記推定送信時間を推定する段階を有する、請求項１から３のいずれか１項に記載の方法。
5. 前記段階（ｉｉｉ）はさらに、
   前記宛て先ユニットにおける前のストリームフラグメントの推定表示時間を表し、２つの前に形成されたストリームフラグメントに埋め込まれたタイムスタンプから導出される現バッファ間隔を判断する段階と、
   前記現クロック間隔と前記現バッファ間隔とを比較する段階と、
   前記現クロック間隔および前記現バッファ間隔の関数として前記現エンコードレートを調整する段階と
   を有する、請求項４に記載の方法。
6. 前記調整する段階はさらに、
   前記現バッファ間隔と前記現クロック間隔との間の第１の相対差が第１の所定の閾値ＴＨ１より大きい場合に、前記第１の相対差に基づき計算される第１の増分値の分だけ前記現エンコードレートを増加させる段階と、
   前記現クロック間隔と前記現バッファ間隔との間の第２の相対差が第２の所定の閾値ＴＨ２より大きい場合、前記第２の相対差に基づき計算される第２の増分値の分だけ前記現エンコードレートを減少させる段階と
   を含む、請求項５に記載の方法。
7. 前記段階（ｉｉｉ）はさらに、
   前記トランスコード済メディアフラグメントの送信の中断を検出する段階と、
   前記中断が検出された場合に、前記現エンコードレートの前記調整を抑制する段階と
   を有する、請求項１から６のいずれか１項に記載の方法。
8. 前記送信の前記中断を前記検出する段階は、
   前記メディアファイルの前記エンコードが開始されてからの、現時刻と直前のエンコード時の時刻である前の時刻との間の間隔としてそれぞれが測定される過去の現クロック間隔の平均として平均クロック間隔を計算する段階と、
   前記現クロック間隔が前記平均クロック間隔より所定の差ＸＣの分だけ大きい場合に、前記中断が検出されたと判断する段階と
   を含む、請求項７に記載の方法。
9. 帯域幅が変化するリンクを介した宛て先ユニットへのリアルタイム送信のために、メディアファイルまたはその一部をエンコードするためのメディア処理システムであり、
   前記メディア処理システムは、プロセッサと、前記プロセッサにより実行されるコンピュータ可読命令を格納した非一時的コンピュータ可読記憶媒体とを備え、
   前記プロセッサと前記非一時的コンピュータ可読記憶媒体とは、
   前記メディアファイルの１以上のフラグメントをトランスコード済メディアフラグメントにトランスコードし、ストリームフラグメントを形成するトランスコーダと、
   前に形成されたストリームフラグメントを前記トランスコーダから伝送し、前記帯域幅が変化するリンクが消費するのに要する時間間隔である、前記前に形成されたストリームフラグメントの推定送信時間の関数として前記トランスコーダの現エンコードビットレートを調整する動的ビットレートアダプタと
   を構成する、メディア処理システム。
10. 前記動的ビットレートアダプタはさらに、現時刻と直前のエンコード時の時刻である前の時刻との間の現クロック間隔として前記推定送信時間を推定する、請求項９に記載のメディア処理システム。
11. 前記動的ビットレートアダプタはさらに、２つの前に形成されたストリームフラグメントに関連するタイムスタンプから導出される、前記宛て先ユニットにおける前記ストリームフラグメントの推定表示時間の関数として、前記現エンコードビットレートを調整する、請求項９または１０に記載のメディア処理システム。
12. トランスコード済メディアフラグメントをネットワークへ転送し、前記トランスコード済メディアフラグメントのうち少なくともいくつかに関連するタイムスタンプを前記動的ビットレートアダプタに送信するトランスコーダバッファをさらに備える、請求項９から１１のいずれか１項に記載のメディア処理システム。
13. 前記動的ビットレートアダプタはさらに、
    前記宛て先ユニットにおける前のストリームフラグメントの推定表示時間を表し、２つの前に形成されたストリームフラグメントに埋め込まれたタイムスタンプから導出される現バッファ間隔を判断し、
    前記現クロック間隔と前記現バッファ間隔とを比較し、
    前記現クロック間隔および前記現バッファ間隔の関数として前記現エンコードビットレートを調整する
    請求項１０に記載のメディア処理システム。
14. 前記動的ビットレートアダプタは、
    前記現時刻をトラッキングするためのウォールクロックモジュールと、
    前記トランスコーダの前記エンコードビットレートを調整するために、前記トランスコーダに送信されるサービス品質（ＱｏＳ）値となるよう前記現時刻と前記タイムスタンプとを処理するＱｏＳアジャスタと
    を含む、請求項１３に記載のメディア処理システム。
15. 前記動的ビットレートアダプタはさらに、前記現エンコードビットレートの関数として前記現エンコードビットレートを調整する、請求項９から１４のいずれか１項に記載のメディア処理システム。
16. 前記動的ビットレートアダプタはさらに、前記トランスコード済メディアフラグメントの送信の中断を検出し、前記中断が検出された場合に、前記動的ビットレートアダプタによる前記現エンコードビットレートの前記調整を妨げる一時停止検出器を含む、請求項９から１５のいずれか１項に記載のメディア処理システム。

Images