特許 6016778 チャンクの形態でストリーミングされたコンテンツを回復する方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6016778

(24)【登録日】2016年10月7日

(45)【発行日】2016年10月26日

(54)【発明の名称】チャンクの形態でストリーミングされたコンテンツを回復する方法

(51)【国際特許分類】

   H04N 21/238 20110101AFI20161013BHJP

   G06F 13/00 20060101ALI20161013BHJP

【ＦＩ】

   H04N21/238

   G06F13/00 550L

【請求項の数】8

【全頁数】14

(21)【出願番号】特願2013-501855(P2013-501855)

(86)(22)【出願日】2011年3月31日

(65)【公表番号】特表2013-524603(P2013-524603A)

(43)【公表日】2013年6月17日

(86)【国際出願番号】EP2011055030

(87)【国際公開番号】WO2011121083

(87)【国際公開日】20111006

【審査請求日】2014年3月24日

(31)【優先権主張番号】10305336.9

(32)【優先日】2010年4月1日

(33)【優先権主張国】EP

(73)【特許権者】

【識別番号】501263810

【氏名又は名称】トムソン ライセンシング

【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100091214

【弁理士】

【氏名又は名称】大貫 進介

(72)【発明者】

【氏名】ビシヨー，ギローム

(72)【発明者】

【氏名】ガツシユ，シユテフアン

【審査官】 岡本 正紀

(56)【参考文献】

【文献】 米国特許出願公開第２００３／０１９５９７７（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２００８／０２９４７８９（ＵＳ，Ａ１）

【文献】 特開２００７−０３６６６６（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｎ ２１／２３８

Ｇ０６Ｆ １３／００

(57)【特許請求の範囲】

【請求項1】

クライアント装置で、ビデオ・コンテンツの時間長に対応する複数のチャンクに分割されたビデオ・コンテンツを受信するストリーミング方法であって、該複数のチャンクは少なくとも第１および第２のフォーマットに符号化され、該第２のフォーマットが該第１のフォーマットよりも良好なビデオのレンダリング品質レベルに対応し、チャンクがチャンク受信期間に受信され、当該方法は、該クライアント装置において、
第１のチャンクをサーバから受信すると、該第１のチャンクの符号化されたビデオ・コンテンツをレンダリングし、該第１のチャンクをメモリに記憶することと、
次のチャンク受信期間に前記クライアント装置と前記サーバとの間の利用可能な帯域幅を推定することと、
前記利用可能な帯域幅に従って前記次のチャンク受信期間に第２のチャンクを受信できるように、前記少なくとも第１または第２のフォーマットのうちのいずれか一方に符号化された該第２のチャンクを送信するように前記サーバにリクエストすることと、
前記記憶された第１のチャンクが前記第１のフォーマットで符号化されている場合であって、前記次のチャンク受信期間に更なる帯域幅が利用可能であるときは、該第１のチャンクの一部分が前記次のチャンク受信期間に受信できるように、前記利用可能な更なる帯域幅に従って前記第２のフォーマットで符号化された該第１のチャンクの一部分を送信するように前記サーバにリクエストすることと、
を含む、前記ストリーミング方法。

【請求項2】

前記第１のチャンクの一部分をリクエストすることは、前記第１のチャンクが動きの激しいシーケンスに対応するビデオ・コンテンツを含む場合に行われる、請求項１に記載のストリーミング方法。

【請求項3】

前記第１のフォーマットで符号化された前記第１のチャンクは、前記クライアント装置と前記サーバ間との第１の接続を介して受信され、前記第２のフォーマットで符号化された前記第１のチャンクの一部分は、前記クライアント装置と前記サーバ間との第２の接続を介して受信される、請求項１または２に記載のストリーミング方法。

【請求項4】

前記第１の接続と前記第２の接続がＴＣＰ／ＩＰ接続である、請求項３に記載のストリーミング方法。

【請求項5】

クライアント装置で、ビデオ・コンテンツの時間長に対応する複数のチャンクに分割されたビデオ・コンテンツを受信するストリーミング方法であって、前記複数のチャンクはスケーラブルビデオ符号化（ＳＶＣ）技術に従って基本レイヤーと少なくとも１つの拡張レイヤーに符号化され、チャンクがチャンク受信期間に受信され、当該方法は、該クライアント装置で、
チャンクをサーバから受信すると、該チャンクの符号化されたビデオ・コンテンツをレンダリングし、前記チャンクをメモリに記憶することと、
次のチャンク受信期間に前記クライアント装置と前記サーバとの間で利用可能な帯域幅を推定することと、
前記次のチャンク受信期間に該チャンクを受信できるように、少なくとも１つのＳＶＣレイヤーを用いて符号化されたチャンクを送信するように前記サーバにリクエストすることと、
前記次のチャンク受信期間に帯域幅が利用可能である場合には、少なくとも１つの拡張レイヤー無しで以前に受信されたチャンクの１つの拡張レイヤーの部分を送信するように前記サーバにリクエストし、前記拡張レイヤーを前記メモリに記憶することと、
を含む、前記ストリーミング方法。

【請求項6】

前記１つの拡張レイヤーの部分を送信するように前記サーバにリクエストすることは、前記チャンクが動きの激しいシーケンスに対応するビデオ・コンテンツを含む場合に行われる、請求項５に記載のストリーミング方法。

【請求項7】

プログラムであって、コンピュータ上で当該プログラムが実行されたときに、請求項１〜６に従ったストリーミング方法を実行するプログラム・コード・インストラクションを含む、前記プログラム。

【請求項8】

ビデオ・コンテンツの時間長に対応する複数のチャンクに分割されたビデオ・コンテンツを受信するクライアント装置であって、該複数のチャンクは少なくとも第１および第２のフォーマットに符号化され、該第２のフォーマットが該第１のフォーマットよりも良好なビデオのレンダリング品質レベルに対応し、チャンクがチャンク受信期間と呼ばれる期間に受信され、該クライアント装置は、サーバに接続するための通信インターフェースと、メモリと、プロセッサとを備え、該プロセッサは、
第１のチャンクをサーバから受信すると、該第１のチャンクの符号化されたビデオ・コンテンツをレンダリングし、前記第１のチャンクをメモリに記憶し、
次のチャンク受信期間に前記クライアント装置と前記サーバとの間で利用可能な帯域幅を推定し、
前記利用可能な帯域幅に従って前記次のチャンク受信期間に第２のチャンクを受信できるように、前記少なくとも第１または第２のフォーマットのうちのいずれか一方に符号化された該第２のチャンクを送信するように前記サーバにリクエストし、
前記記憶された第１のチャンクが第１のフォーマットで符号化されている場合であって、前記次のチャンク受信期間に更なる帯域幅が利用可能であるときは、該第１のチャンクの一部分が前記次のチャンク受信期間に受信できるように、前記利用可能な帯域幅に従って前記第２のフォーマットで符号化された該第１のチャンクの一部分を送信するように前記サーバにリクエストする、
前記クライアント装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、一般的には、適応型のビデオ・ストリーミングに関し、特に、適応型のビデオ・ストリーミング・コンテンツを回復する方法に関する。

【背景技術】

【0002】

この項は、読者に対し、様々な技術的な態様を紹介することを意図している。これらの技術的な態様は、以下に説明する、さらに／または、以下の請求項に記載する本発明の様々な態様に関連することがある。この説明が本発明の様々な態様をより良好に理解するための背景情報を読者に提供するのに役立つと確信する。従って、各記載は、この点に鑑みて読まれるべきものであり、先行技術を自認するものではないことを理解すべきである。

【0003】

メディア配信ストリーミングの解決法は、主に、ＩＥＴＦ ＲＦＣ２３２６において規定されているようなリアルタイム・ストリーミング・プロトコル（ＲＴＳＰ）、マイクロソフト社のマイクロソフト・メディア・サーバ（ＭＭＳ）独自プロトコル、アドビ・システムズ（社のリアルタイム・メッセージング・プロトコル（ＲＴＭＰ）独自プロトコルなどのプロトコルに基づいている。より最近では、ＨＴＴＰプロトコルに基づく新しいストリーミング技術が出現している。適応型のストリーミング技術は、帯域幅の制約条件を満たすために、ビデオ品質のアップグレードまたはダウングレードを連続的且つ巧みに行うことによって、利用可能な帯域幅に関する不規則なネットワーク挙動を補償する方法を提供する。より正確には、ビデオ・ストリームは、それぞれが、例えば、３００ｋｂｐｓ、６００ｋｂｐｓ、１２００ｋｂｐｓ、２０００ｋｂｐｓ、または３０００ｋｂｐｓなどのビットレートの制約条件に対応する幾つかの符号化されたビットストリームに符号化される。これらの各ストリームは、次に、複数のチャンクに分割される。チャンクは、例えば、２秒の時間長を表し、各々のチャンクが参照フレームで開始し、所与のチャンクのフレームが別のチャンクにおけるフレームを参照しないように、全てが良好に配列される。換言すれば、ビデオ・ストリームは、チャンクと呼ばれる複数の短いセグメントに切り分けられ、所望の配信フォーマットに符号化される。チャンクは、通常、２〜４秒の長さである。ビデオ・コーデック・レベルでは、これは、通常、各チャンクがビデオＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅｓ）の境界で切り分けられ、過去または将来のチャンクおよびＧＯＰに依存しないことを意味する。これにより、後で復号される各チャンクが他のチャンクに依存しないようにすることができる。

【0004】

クライアント装置は、推定された帯域幅に関する特定のビットレートでチャンクを送信するようにＨＴＴＰサーバに対してリクエストを行う。ここで、利用可能な帯域幅の測定は、例えば、ＨＴＴＰリクエスト／レスポンスによって使用される往復の伝送時間を測定することによって行うことができる。次に、ビデオ・ストリームは、チャンク毎にクライアントによるリクエストに基づいて配信される。このことは、図１に例示されており、低ビットレートから高ビットレートまでの、４つのレベルのチャンク・ビットレートが示されている。ビデオ・チャンクは、全て、固定された時間長に対応しており、多少大きなサイズを有する。大きなチャンクは、広い帯域幅を必要とし、良好なビデオ品質を提供する。チャンクの選択は、曲線に対応する推定された利用可能な帯域幅に依存する。勿論、実施態様、環境、ネットワーク技術、およびクライアントのアプリケーションに依存して、多少、余裕を持った戦略がとられることがある。余裕を持った戦略がとられる場合には、クライアントは、特定の時間が経過してはじめて、より高いビットレートのチャンクをリクエストし、アップグレードの移行がスムーズに行われるようにする。より余裕を少なくした戦略は、クライアントがより広い帯域幅が利用可能であることを検出するとすぐにより高いビットレートのチャンクをリクエストすることであろう。さらに、一般的には、クライアントは、急速なダウングレードの移行を示唆する帯域幅の減少を検出するとすぐにより低いビットレートのチャンクをリクエストする。

【0005】

このようなストリーミング技術の例は、ムーブネットワークス社の「Ｍｏｖｅ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍ」、アップル社の「ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ」、および、マイクロソフト社の「ＩＩＳ（Ｉｎｔｅｒｎｅｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｉｃｅｓ）Ｓｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇ」である。これらのストリーミングの解決法において、ＨＴＴＰプロトコルを使用する利点は、この解決法の、ＮＡＴおよびファイヤー・ウォールをシームレスに越える機能である。これらのＨＴＴＰストリーミング技術は、帯域幅の制約条件を満たすために、ビデオ品質のアップグレードまたはダウングレードを連続的且つ巧みに行うことによって、利用可能な帯域幅に関する不規則なネットワーク挙動を補償する方法を提供する。

【0006】

より詳細には、ムーブネットワークス社の国際公開第２００５／１０９２２４号公報は、クライアント側でホストされるエージェント・コントローラ・モジュール（Ａｇｅｎｔ Ｃｏｎｔｒｏｌｌｅｒ Ｍｏｄｕｌｅ）におけるメカニズムについて記載している。エージェント・コントローラ・モジュールは、ストリーミングの対象となるメディアが、各々が低ビットレートから高いビットレートに符号化されるチャンクとも呼ばれる、複数のストリームレットに前もって構成済であることにより、変動するネットワークの帯域幅に適応可能である。利用可能なネットワーク帯域幅および他の幾らかの追加的な情報に従って、エージェント・コントローラ・モジュールに組み込まれる監視ツールは、最適なチャンクがＴＣＰ／ＩＰ接続を介してストリーミングにより送信されるように、ＨＴＴＰプロトコルを使用してサーバに対してリクエストを行う。チャンクを基本単位として、エージェント・コントローラ・モジュールに従って、品質をアップシフトまたはダウンシフトすることができる。

【0007】

マイクロソフト社のＡｌｅｘ Ｚａｍｂｅｌｌｉ氏の２００９年３月の「IIＳスムーズ・ストリーミングの技術概要」は、ＴＣＰ／ＩＰ接続を介したＨＴＴＰプロトコルに基づくIIＳスムーズ・ストリーミング技術について記載している。サーバによるストリーミングの対象となるメディアは、例えば１〜１０秒の時間長を表す複数のチャンクに前もって切り分けられている。次に、これらの各チャンクは、それぞれ異なるビットレートでＨ．２６４／ＭＰＥＧ−４ ＡＶＣ規格に従って符号化され、ＭＰ４ファイル・フォーマットのコンテナ内に格納される。ネットワークの帯域幅の変動に従ってビットレートを選択し、サーバに対して対応するチャンクをシームレスにリクエストするメカニズムは、アプリケーション・コード、Ｓｉｌｖｅｒｌｉｇｈｔアプリケーションを介して完全にクライアント側で実施される。ＨＴＴＰライブ・ストリーミングは、接続スピードの変化に応じて複数の異なるデータレートのストリーム間での動的な切り換えをサポートする。

【0008】

アップル社は、２００９年１０月に「Ｈｔｔｐ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ ｄｒａｆｔ−Ｐａｎｔｏｓ−ｈｔｔｐ−ｌｉｖｅ−ｓｔｒｅａｍｉｎｇ−０２」と題されたＨＴＴＰストリーミング方法の仕様書について、インターネット・ドラフトをＩＥＴＦに提出している。ＨＴＴＰストリーミング・アーキテクチャは、サーバ、ウエブ・サーバまたはウエブ・キャッシング（Ｗｅｂ ｃａｃｈｉｎｇ）・システムを介した配布（ｄｉｓｔｒｉｂｕｔｉｏｎ）、さらに、クライアントの３つの柱に基づいている。ストリーミングの対象となるメディアは、Ｈ．２６４で符号化されるビデオとＡＡＣで符号化されるオーディオである。サーバにおいて、このメディアは、ＭＰＥＧ−ＴＳコンテナにカプセル化され、アップル・ストリーム・セグメンタ（Ａｐｐｌｅ ｓｔｒｅａｍ ｓｅｇｍｅｎｔｅｒ）と称する特定のツールを用いて均等な時間長のチャンクに分割されている。このツールは、“*.ts”ファイルおよびチャンクのプレイリストを構成するインデックス・ファイル“*.m3u8”として保存されるチャンクを生成する。次に、クライアントは、まず、ＵＲＬポインタにより、インデックス・ファイルを取得する。これに対し、インデックス・ファイルは、利用可能なメディア・ファイル、暗号解読キー、さらに、利用可能である任意の代替的なストリームの場所を特定する。選択されたストリームに対し、クライアントは、順次、利用可能な各メディア・ファイルをダウンロードする。

【0009】

このような適応型のストリーミング技術を用いた場合には、ビデオ品質は不規則なものとなる。チャンク毎にクライアントによって取得されるストリームは、複数の異なるビットレートのチャンクが混合したものであるため、安定した品質を有するものではない。このビデオは、後に再生するために、受信機に記憶することもできる。通常、このようなストリーミング・アプリケーションを使用する場合、チャンクは、ローカル・ストレージ設備に記録されていることがあるため、ネットワークを介してストリームを再送する必要はない。しかしながら、一連の記憶されたチャンクは、ストリーミング・セッションの間に発生したネットワークの各状態に対応しているため、ビデオ品質は安定したものとはならない。

【0010】

この問題に対する解決法は、低品質のチャンクに対応するチャンクをサーバから再度取得することであろう。これは、記録されたストリームが再生される前にグループ化されたダウンロードとして行うことができる。しかしながら、この処理には、時間がかかることがある。別の解決法は、記録されたストリームの再生の間に低品質のチャンクをオンザフライで置き換えることである。しかしながら、より良好な品質のチャンクが必要となったときにこのようなより良好な品質のチャンクをクライアントが取得できるという保証もない。さらに、どちらの解決法でも、クライアントがサーバに接続されることが必要となる。

【発明の概要】

【0011】

本発明は、従来技術における低品質のチャンクに関わる懸念の少なくとも幾らかを払拭しようとするものであり、機会があればチャンクの品質を向上させる方法を提供することである。

【0012】

この目的のため、本発明は、クライアント装置で、コンテンツの時間長に対応する複数のチャンクに分割されたコンテンツを受信する適応型のストリーミング方法に関する。チャンクは、サーバで、少なくとも第１および第２のフォーマットに符号化される。第２のフォーマットのコンテンツのレンダリング品質のレベルは、第１のフォーマットのコンテンツのレンダリング品質のレベルよりも良好であり、チャンク受信期間にチャンクが受信される。

【0013】

本発明によれば、この方法は、次のチャンク受信期間にクライアントとサーバとの間で利用可能な帯域幅を測定するステップと、次のチャンク受信期間にチャンクを受信できるよう、或るフォーマットに符号化されたチャンクを送信するようにサーバにリクエストするステップと、次のチャンク受信期間に幾らかの帯域幅が利用可能である場合には、第２のフォーマットで符号化されたチャンクの部分を送信するようにサーバにリクエストするステップであって、受信済のチャンクが第１のフォーマットで符号化されている、上記ステップと、を含む。

【0014】

一実施形態によれば、この方法は、チャンクを受信するステップと、チャンクをレンダリング装置に送信するステップとを含む。

【0015】

一実施形態によれば、この方法は、チャンクをメモリに記憶するステップを含む。

【0016】

本発明の一実施形態によれば、この方法は、利用可能な帯域幅を複数の連続的なチャンク受信期間に使用して第２のフォーマットで符号化されたチャンクの全部分をリクエストするステップを含む。

【0017】

本発明の一実施形態によれば、この方法は、第２のフォーマットで符号化されたチャンクの全部分が受信されると、メモリにおいて、第１のフォーマットで符号化されたチャンクと第２のフォーマットで符号化されたチャンクとを入れ替えるステップを含む。

【0018】

本発明は、さらに、クライアント装置で、コンテンツの時間長に対応する複数のチャンクに分割されたコンテンツを受信する適応型のストリーミング方法に関する。チャンクは、サーバで、スケーラブルビデオ符号化（ＳＶＣ）技術で基本レイヤーと少なくとも１つの拡張レイヤーに符号化され、チャンク受信期間にチャンクが受信される。この目的のため、この方法は、クライアント装置で、次のチャンク受信期間にクライアントとサーバとの間で利用可能な帯域幅を測定するステップと、少なくとも１つのＳＶＣレイヤーを用いて符号化されたチャンクを送信するようにサーバにリクエストし、次のチャンク受信期間にチャンクを受信できるようにするステップと、次のチャンク受信期間に幾らかの帯域幅が利用可能である場合には、少なくとも１つの拡張レイヤー無しで前に受信されたチャンクの上記少なくとも１つの拡張レイヤーを送信するようにサーバにリクエストするステップと、を含む。

【0019】

本発明の一実施形態によれば、この方法は、チャンクを受信するステップと、チャンクをレンダリング装置に送信するステップと、を含む。

【0020】

本発明の一実施形態によれば、この方法は、チャンクをメモリに記憶するステップを含む。

【0021】

本発明の別の目的は、コンピュータ・プログラム・プロダクツであり、このコンピュータ・プログラム・プロダクツは、コンピュータ上でそのプログラムが実行されたときに、本発明に従った方法の各ステップを実行するプログラム・コード・インストラクションを含む。「コンピュータ・プログラム・プロダクツ」は、コンピュータ・プログラム・サポートを意味し、これは、コンピュータ・メモリなどのプログラムを含む記憶スペースに存在するものだけでなく、電気信号や光信号などの信号に存在するものも含むことがある。

【0022】

各特定の態様は、以下に開示する実施形態の範囲と一致したものである。これらの態様の提示は、読者に対し、発明が採用することのある特定の形態を概略的に提供するためのものに過ぎず、各態様は、本発明の範囲を制限するように意図されたものではないことを理解すべきである。実際、本発明は、以下に記載しない様々な態様を含むことがある。

【0023】

本発明は、添付図面を参照して、以下の実施の形態および実施例により良好に理解され、例示されるであろう。これらの実施の形態および実施例は、決して限定的なものではない。

【図面の簡単な説明】

【0024】

【図1】時間軸に沿ってチャンクの配信を例示する図である。

【図2】実施形態に従ったシステムのブロック図である。

【図3】実施形態に従ったクライアント装置のブロック図である。

【図4】第１の実施形態に従ったチャンク配信を例示する図である。

【図5】第２の実施形態に従ったチャンク配信を例示する図である。

【発明を実施するための形態】

【0025】

図３において、示されたブロックは、純粋に、機能的なものであり、これらは、必ずしも物理的に別個のものに対応するものではない。即ち、これらは、ハードウエアの形態でもよく、ソフトウエアの形態でもよく、１つまたは幾つかの集積回路において実施されていてもよい。

【0026】

本発明の各図面および記載は、本発明の明確な理解のために関連のある各要素を例示するように簡略化されており、分かりやすくする目的で、通常のディジタル・マルチメディア・コンテンツ配信の方法およびシステムにおいて存在する多くの他の要素を削除していることを理解すべきである。しかしながら、これらの各要素は、本技術分野においてよく知られており、このような各要素についての詳細な説明は、本明細書において提供されていない。本発明の開示内容は、当業者にとって公知なこのような変形および改変の全てに関する。

【0027】

以下、２つの実施形態について説明する。第１の実施形態では、コンテンツは、幾つかのビットレートで符号化され、第２の実施形態では、コンテンツは、スケーラブルビデオ符号化を用いて符号化される。各実施形態に従ったシステムは、図２に表されている。このシステムは、インターネットを介して接続されたクライアント１およびサーバ３を含む。ビデオ・ファイル・スプリッタ５は、圧縮されたビデオおよびオーディオを複数のチャンクにする。さらに、クライアントは、プレイヤー４に接続される。サーバ側でチャンクは、クライアントからのリクエストがあると、ＨＴＴＰプロトコルを使用して、ＴＣＰ／ＩＰ接続を介してストリーミングにより送信される。クライアントは、以下に記載する方法に従って、および、ネットワーク帯域幅の推定、特に、余裕のある帯域幅に基づいて、チャンクをリクエストする。

【0028】

実施形態に従ったクライアントは、図３に例示されている。クライアントは、ネットワークに対する第１のインタフェース１４、および通信手段１３を含み、この通信手段１３は、ネットワーク上に存在するサーバと通信するプロトコル・スタックを含む。特に、ネットワークは、インターネットであり、通信手段は、本技術分野において良く知られているＴＣＰ／ＩＰスタックである。勿論、クライアントとサーバとの通信を可能にするどのような他のタイプのネットワークおよび／または通信手段でもよい。

【0029】

さらに、クライアントは、コンテンツを復号し、レンダリングするように構成されたビデオ・プレイヤーに接続するための第２のインタフェース１６を含む。勿論、第２のインタフェースは、複数のプレイヤーに接続できるようにするものであってもよい。第２のインタフェースは、１つ以上のプレイヤーに接続できるようにするためのネットワークに対するインタフェースであってもよい。さらに、クライアントは、このクライアントに記憶されたアプリケーションを処理するプロセッサ１１を含む。クライアントは、サーバから受信されるチャンクを、チャンクがＳＶＣプレイヤーに送信される前にバッファリングするバッファ１２を含む。さらに、クライアントは、サーバから受信されたチャンクが送信されるメモリ１７を含む。好ましくは、このメモリ１７は、不揮発性メモリである。

【0030】

さらに、クライアントは、クライアントで動作するアプリケーションを記憶するための、図示しない不揮発性メモリを含む。チャンク・セレクタ１５は、以下に説明するような、チャンク選択を実行するように構成されたアプリケーションである。クライアントは、ゲートウエイ装置において実施することができる。代替的には、クライアントは、埋め込まれたＳＶＣプレイヤーを含む。その場合、セットトップ・ボックスなどの装置がクライアントとなることがある。

【0031】

代替的には、メモリは、クライアント装置に結合された記憶装置に存在することがある。そこで、以下に説明する方法は、記憶装置がクライアントに結合されている場合にのみ実行される。この方法は、結合されている記憶装置を検出すると自動的に実行されるようにすることができる。さらに、この方法は、エンド・ユーザからのリクエストにより実行されてもよい。

【0032】

クライアント側でチャンクを受信する方法は、以下のように要約することができる。
・チャンク・セレクタは、以下に説明する方法に従ってチャンクを選択する。
・通信手段は、選択されたチャンクを受信するために、サーバに対してリクエストを送信する。
・通信手段は、チャンクを受信する。
・チャンクは、バッファリングされる。
・チャンクは、ビデオ・プレイヤーに送信される。

【0033】

実施形態によれば、さらに、各チャンクがメモリ１７に送信される。これらの記憶されたチャンクの品質を向上させるために、クライアントは、余っている利用可能な帯域幅を使用して以下に示されたようなより高品質のチャンクをリクエストする。次に、より高品質のチャンクは、メモリ１７に記憶される。

【0034】

第１の実施形態に従った方法は、図４に例示されている。チャンクの時間長は、チャンクに関連付けられたビデオの時間長に対応する。クライアントは、チャンクの時間長の期間ごとに特定のビットレートに対応するチャンクをリクエストする。クライアントは、チャンクｃｈ１〜ｃｈ１４を受信する。以下の説明において、チャンクの時間長は２秒に設定されているものとする。余裕を持ったアプローチにおいては、クライアントは、特定の時間が経過してはじめて、より高いビットレートのチャンクをリクエストし、スムーズなアップグレードの移行が確実に行われるようにする。クライアントが次のチャンクのために利用可能な帯域幅を推定すると、余裕を持ったアプローチの後、クライアントは、チャンクをリクエストするが、リクエストされるチャンクは、このリクエストを行う期間と同じ期間内にアップグレードの対象となるチャンクの部分をリクエストするために十分な帯域幅が残されるようなビットレートに対応するものである。

【0035】

図４は、図１に例示されたような、低ビットレートから高ビットレートの、４つのレベルのチャンク・ビットレートを示している。説明を簡略化するために、同一のビットレートに対応するチャンクは、同一のサイズを有するようにしている。即ち、所与のビットレートの全てのチャンクを同じ面積で表す。図４に例示されているように、クライアントは、より多くの情報を同時にダウンロードする機会を提供するビットレートに関連付けられたチャンク番号３をリクエスト済である。クライアントは、利用可能な帯域幅を使用して、１に設定されたインデックスを有するブロックを用いて例示された、当初、低ビットレートのチャンクとして受信されたチャンク１の第１の中間ビットレートのバージョンの部分をリクエストする。チャンク４をリクエストする場合も同じである。このとき、クライアントは、チャンク１の第１の中間ビットレートのバージョンの最後の部分を取得している。さらに、チャンク６、７、８、および９もまた、次第にそれぞれの第１の完全な中間ビットレートのバージョンに置き換えられる。勿論、対応するアップグレードされたチャンクが完全に受信されている場合にのみ、チャンクが置き換えられる。

【0036】

代替的には、クライアントのホスト内にローカルにキャッシュされたビデオの総合品質をアップグレードするために他の方法が使用される。図４に示された例は、平均的な品質の向上を提供する方法に対応し、この方法では、まず、最低のビットレートのチャンクをアップグレードすることに優先度が置かれる。別の方法は、まず、例えば、動きの激しいシーケンスを含むチャンクとして、特定のチャンクをアップグレードすることに優先度が置かれることがある。ここで、緩やかな動きのシーケンスは、品質またはユーザ体験に対して過度の影響を与えることなく、低ビットレートで配信することができる一方で、動きの激しいシーケンスは、安定した品質のために、より高いビットレートを必要とする。

【0037】

第１の実施形態のシステムにおいては、ビデオ・ファイル・スプリッタは、複数の異なるフォーマットでＨ．２６４／ＭＰＥＧ−４ ＡＶＣ規格に従って符号化され、ＭＰ４ファイル・フォーマットのコンテナ内部に記憶されるチャンクを生成する。各フォーマットは、３００ｋｂｐｓ、６００ｋｂｐｓ、１０００ｋｂｐｓ、または、２０００ｋｂｐｓのいずれかのビットレートに対応する。ビデオ・ファイル・スプリッタは、サポートされたビットレート毎に、ＭＰＥＧトランスポート・ストリームの一連のチャンクを生成するためにチャンクを多重化する。これらのチャンクの全ては、ＨＴＴＰサーバに記憶される。サポートされたビットレート、チャンクの数、さらに、それぞれのチャンクのサイズのリストを含む、マニフェスト・ファイルがクライアントに送信される。

【0038】

ここで、クライアントは、チャンク配信のリクエストを開始することができる。クライアントは、２秒毎に、１つのリクエストを送信する。この２秒は、ビデオ・チャンクの時間長に対応する。実際には、クライアントは、帯域幅を推定し、推定された帯域幅から余裕を持たせるための備えの分を差し引いた帯域幅に対応するチャンクをリクエストする。従って、ＨＴＴＰサーバから受信したレスポンスは、チャンクのビットレートに直接リンクされた特定の時間の後に、到着する。レスポンスが受信されると、クライアントは、次のチャンクをリクエストするまでに残っている残存時間（ｔｉｍｅ ｌｅｆｔ）を計算する。次に、クライアントは、アップグレードすることが望まれる、前のチャンクに関連付けられた、リクエストできるバイトの数（ＢｙｔｅｓＭａｘＮｕｍ）を取得する。

【0039】

残存時間＝２秒―チャンクの往復の伝送時間
ＢｙｔｅｓＭａｘＮｕｍ＝推定された帯域幅（／秒）＊残存時間（秒）

【0040】

次に、クライアントは、アップグレードの対象となるチャンクから特定のバイトの範囲をダウンロードするために、他のＨＴＴＰリクエストを送信する。ＨＴＴＰリクエストのフォーマットは、ファイルの特定のバイトの範囲の要求をサポートする。しかしながら、これには、全てのＨＴＴＰリクエスト／レスポンス処理のシリアル化が必要となる。ＨＴＴＰ処理が、推定されている処理よりも長い場合には、これにより、次のチャンクのリクエストが遅延することがあるため、プレイヤーに対して与えられるデータが不足することが危惧される。

【0041】

代替的には、クライアントは、第２のＴＣＰ接続をセットアップする。チャンクをアップグレードする処理に関連付けられたＨＴＴＰリクエストは、第２のＴＣＰ接続を介して送信される。クライアントは、上述したものと同じ処理を行う。クライアントは、帯域幅を推定し、推定された帯域幅から余裕を持たせるための備えの分を差し引いた帯域幅に対応するチャンクをメインとなるＴＣＰ接続を介してリクエストする。余裕を持たされた推定値に従って、クライアントは、アップグレードすることが望まれる、前のチャンクに関連付けられたリクエストできるバイト数を計算する。

【0042】

ＢｙｔｅｓＭａｘＮｕｍ＝（推定された帯域幅−チャンク・ビットレート）＊２秒

【0043】

クライアントは、第２のＴＣＰ接続を介して、メインとなる接続と並列的に、アップグレードの対象となるチャンクの部分に対応するバイトを求める幾つかの連鎖的なリクエストを行うことができる。

【0044】

クライアントは、メインの接続に依存することなく、第２のＴＣＰ接続をシャットダウンすることができる。これは、帯域幅が減少した際にスムーズな再生を維持するためにメインの接続に優先度を置くことを望む場合に該当する。

【0045】

本発明の第２の実施形態においては、各チャンクは、Ｈ．２６４／ＭＰＥＧ−４ ＡＶＣ 付属文書Ｇで規定されるスケーラブルビデオ符号化（Ｓｃａｌａｂｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＳＶＣ））圧縮技術に従って符号化される。ＳＶＣは、３つの細かさのレベル（程度）のパラメータとして、時間スケーラビリティ、空間スケーラビリティ、さらに、ＳＮ比（ＳＮＲ）スケーラビリティを規定する。ターゲットの多様性や帯域幅の負荷などの基準に従って、ストリームの符号化は、必ずしも、全ての既存のタイプのスケーラビリティでの符号化を必要としない。これは、スケーラビリティの各タイプについて、レイヤーの数を条件付けるものである。ＨＴＴＰストリーミングのために、ＳＶＣコンテンツは、ファイルとして記憶される。ＳＶＣファイルは、ＭＰＥＧ−２トランスポート・ストリームまたはＭＰ４ファイルでフォーマットされる。これらのフォーマットは、特に、レンダリングのためのタイミング情報を管理できるようにする。

【0046】

ＭＰＥＧ２トランスポート・ストリームは、通常、追加的なデータ無しにＴＶチャンネルを放送するために生成される。ＳＶＣビデオを用いたＴＶチャンネルの放送は、規格「（情報技術−動画およびオーディオの汎用符号化：システム：ＩＴＵ−Ｔ勧告Ｈ．２２２．０｜ ＩＳＯ／ＩＥＣ １３８１８−１でのスケーラブルなビデオのトランスポート、修正３ ２００９年３月」に規定されている。これは、通常のＴＶチャンネルＣ（１つのエレメンタリ・ストリーム（ＥＳ）ＡＶＣおよび１つのＥＳオーディオ）のプログラム・マップ・テーブル（ＰＭＴ）を、各拡張レイヤー「１」について、ＥＳを用いて規定する。

【0047】

ＭＰ４ファイル・フォーマットのコンテナは、ＩＳＯ／ＩＥＣ ＦＤＩＳ １４４９６−１４：２００３（Ｅ）において、「情報技術−オーディオ、ピクチャ、マルチメディアおよびハイパーメディア情報の符号化−パート１４：ＭＰ４ファイル・フォーマット」で規定されている。ＭＰ４ファイル・フォーマットのコンテナは、ＩＳＯ／ＩＥＣ １４４９６−１５：２００４／ＦＤＡＭ ２：２００８（Ｅ）において、「情報技術−ＡＶオブジェクト−パート１５：アドバンスド・ビデオ符号化ファイル・フォーマットＡＶＣ ｆｉｌｅ ｆｏｒｍａｔ）、修正２：スケーラブルビデオ符号化のためのファイル・フォーマット・サポート」で規定されているように、ＳＶＣコンテンツに適応している。例えば、ＳＶＣファイル・フォーマットの説明は、Ｐ． Ａｍｏｎ氏、Ｔ． Ｒａｔｈｇｅｎ氏、Ｄ． Ｓｉｎｇｅｒ氏の文献「スケーラブルビデオ符号化のためのファイル・フォーマット」 ＩＥＥＥ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ ｃｉｒｃｕｉｔｓ ＆ Ｓｙｓｔｅｍｓ ｆｏｒ ｖｉｄｅｏ Ｔｅｃｈｎｏｌｏｇｙ、ｖｏｌ．１７、２００７年９月」に例示されている。

【0048】

第２の実施形態では、ＳＶＣ符号化されたビデオが複数のチャンクに分割される。チャンクは、１つのＳＶＣサンプルを含むだけでなく、１つの連続したストリームのセグメント、即ち、連続したピクチャを集めたものである。従って、チャンクは、以下、「チャンク・オフセット」と呼ぶ開始時間を有し、さらに、以下、「チャンクの時間長」と呼ぶ時間長を有する。さらに、チャンクは、ＧＯＰ（ｇｒｏｕｐ ｏｆ ｐｉｃｔｕｒｅｓ）、または、整数の数のＧＯＰに並べられている。通常、チャンク・サイズの範囲は、１〜１０秒の時間長である。これは、各チャンクがキー・フレームで開始することを意味する。チャンクのコンテンツもまた、スケーラビリティのような種類の１つのレイヤーのみに対応する。全てのチャンク・ファイルは、同一のフォーマットを有する。各チャンクは、独自のＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）を有する。

【0049】

ストレージ・フォーマット（ＭＰＥＧ２−ＴＳやＭＰ４ファイル）に関わらず、ＳＶＣコンテンツをチャンク毎のファイルに分割してもよいし、サーバ上に現状のまま、記憶してもよい。前者の場合には、クライアントは、ＵＲＩをリクエストし、後者の場合には、クライアントは、タイムコードおよび時間長、または、バイト・オフセット（ファイルの最初からのオフセット）およびバイト範囲をリクエストする。利用可能なチャンクは、ストリーミング・サーバによって生成、提供されたプレイリストに列挙される。このプレイリストは、フォーマットのタイプ毎のものなど、他のプレイリストを参照することもできる。プレイリストには、コーデックまたは必要な帯域幅などのチャンクのコンテンツ、さらに、これらをリクエストする方法を記載する。プレイリスト・フォーマットは、「ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ ｄｒａｆｔ−ｐａｎｔｏｓ− ｈｔｔｐ−ｌｉｖｅ−ｓｔｒｅａｍｉｎｇ−０２」に記載されているものとすることができ、様々なＳＶＣレイヤーを記載するためにコーデック情報を用いて拡張される。

【0050】

第２の実施形態のシステムは、第１の実施形態のシステムと同様であるが、第２の実施形態では、コンテンツは、複数の異なる品質のレベルに符号化されるのではなく、ＳＶＣレイヤーに符号化される。特に、ビデオ・ファイル・スプリッタは、４つの相補的なレイヤー、即ち、１つの基本レイヤーおよび３つの拡張レイヤーを使用して、チャンクを作成する。第１の実施形態においては、より高品質のチャンクがメモリに送信される。第２の実施形態においては、チャンクの全てがメモリに送信される。

【0051】

第２の実施形態に従った方法は、図５に例示されている。クライアントは、インデックスによって識別されない基本レイヤーおよび拡張レイヤーによって表されるチャンクｃｈ１〜ｃｈ１４を受信する。回復されたチャンクは、インデックスを用いて表される。ここで、クライアントは、より多くの情報を同時にダウンロードする機会を提供するビットレートに関連付けられたチャンク３をリクエスト済である。クライアントは、利用可能な帯域幅を使用して、基本レイヤーのチャンクとして当初受信された、チャンク１の第１の拡張レイヤーのピースをリクエストしている。チャンク４をリクエストする際も同様である。チャンク１および２の第２の拡張レイヤーがリクエストされる。チャンク５を用いて、クライアントは、チャンク１の第３の拡張レイヤーをリクエストする。チャンク２の第３の拡張レイヤーがリクエストされるチャンク６の場合も同様である。チャンク６の時点では、クライアントは、拡張レイヤー１および２を用いて全体のシーケンスの「アップグレード」を受けることができ、拡張レイヤー３を用いて幾らかのチャンクがさらに改善される。さらに、やがて、チャンク３、５、６、７、８もまた、アップグレードされる。簡略化のため、基本レイヤーおよび拡張レイヤーのチャンクをそれぞれ同じサイズで表す。

【0052】

第２の実施形態は、拡張レイヤー１が基本レイヤーに依存し、拡張レイヤー２が拡張レイヤー１に依存するなどの、ＳＶＣレイヤーの特定の構成を示している。代替的には、全ての拡張レイヤーが基本レイヤーに依存する別のＳＶＣスキームを使用することができる。これは勿論、フレキシビリティが低くなるが、発生する負荷が小さくなる。

【0053】

明細書、請求項、および図面において開示された参照内容は、独立して提供されることも、適切な組み合わせにより提供されることもある。各特徴事項は、適宜、ハードウエア、ソフトウエア、または、ハードウエアおよびソフトウエアを組み合わせた形態で実施される。

【0054】

本明細書において、「一実施形態」または「実施形態」と参照している場合、実施形態に係る特定の特徴事項、構造、または特性が本発明の少なくとも一実施態様に含まれることを意味する。明細書の様々な箇所に存在する「一実施形態においては」という記載は、必ずしも、全てが同一の実施形態について言及するものではなく、別個の実施形態または代替的な実施形態が他の実施形態に対して相互に排他的であるものではない。

【0055】

各請求項に存在する参照符号は例示的な目的のためのものに過ぎず、請求の範囲に限定的な影響を与えるものではない。

【図1】

【図2】

【図3】

【図4】

【図5】