特許 5936805 パラレルユーザセッションをストリーミングするための方法、システム、およびコンピュータソフトウェア

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

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

(11)【特許番号】5936805

(24)【登録日】2016年5月20日

(45)【発行日】2016年6月22日

(54)【発明の名称】パラレルユーザセッションをストリーミングするための方法、システム、およびコンピュータソフトウェア

(51)【国際特許分類】

   H04N 19/20 20140101AFI20160609BHJP

   H04N 19/423 20140101ALI20160609BHJP

   H04N 19/70 20140101ALI20160609BHJP

   H04N 21/2183 20110101ALI20160609BHJP

   H04N 21/236 20110101ALI20160609BHJP

   H04N 21/84 20110101ALI20160609BHJP

【ＦＩ】

   H04N19/20

   H04N19/423

   H04N19/70

   H04N21/2183

   H04N21/236

   H04N21/84

【請求項の数】27

【全頁数】40

(21)【出願番号】特願2009-530298(P2009-530298)

(86)(22)【出願日】2007年10月1日

(65)【公表番号】特表2010-505330(P2010-505330A)

(43)【公表日】2010年2月18日

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

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

(87)【国際公開日】20080417

【審査請求日】2010年10月1日

【審判番号】不服2015-2458(P2015-2458/J1)

【審判請求日】2015年2月9日

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

(32)【優先日】2006年9月29日

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

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

(32)【優先日】2007年6月4日

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

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

(32)【優先日】2007年9月10日

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

(73)【特許権者】

【識別番号】509089845

【氏名又は名称】アビニティ・システムズ・ベスローテン・フェンノートシャップ

【氏名又は名称原語表記】ＡＶＩＮＩＴＹ ＳＹＳＴＥＭＳ Ｂ．Ｖ．

(74)【代理人】

【識別番号】100064746

【弁理士】

【氏名又は名称】深見 久郎

(74)【代理人】

【識別番号】100083703

【弁理士】

【氏名又は名称】仲村 義平

(74)【代理人】

【識別番号】100096781

【弁理士】

【氏名又は名称】堀井 豊

(74)【代理人】

【識別番号】100098316

【弁理士】

【氏名又は名称】野田 久登

(74)【代理人】

【識別番号】100111246

【弁理士】

【氏名又は名称】荒川 伸夫

(72)【発明者】

【氏名】ブルックマン，ロナルド

【合議体】

【審判長】 渡邊 聡

【審判官】 清水 正一

【審判官】 戸次 一夫

(56)【参考文献】

【文献】 特表２００６−５１２８３８（ＪＰ，Ａ）

【文献】 特開２０００−１５２２３４（ＪＰ，Ａ）

【文献】 特表２００４−５０１４４５（ＪＰ，Ａ）

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

【文献】 国際公開第０２／０７６０９９（ＷＯ，Ａ１）

【文献】 国際公開第０３／０７１７２７（ＷＯ，Ａ２）

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

H04N 19/00 - 19/98

H04N 21/00 - 21/858

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

【請求項1】

少なくとも１つのサーバと複数のクライアント装置との間で複数のそれぞれのパラレルユーザセッションを提供するための方法であって、
画像データの符号化されたフラグメントを再使用するためにメモリに格納することと、
符号化されたフラグメントを識別する情報に基づき、前記メモリに格納されている符号化されたフラグメントを規定することとを含み、再使用可能な画像データに基づき、前記符号化されたフラグメントを作成することを含み、前記符号化されたフラグメントは、予め規定されたデータフォーマットを有する映像ストリームにアセンブルするのに適しており、前記符号化されたフラグメントは、前記映像ストリームの全画面サイズよりも小さく、前記方法はさらに、
それぞれのデータストリームをセッションごとにアセンブルすることを含み、前記それぞれのデータストリームは、前記符号化されたフラグメントが適用される映像データを含み、前記それぞれのデータストリームをセッションごとにアセンブルすることは、
前記複数のパラレルユーザセッションの第１のユーザセッションのための第１の映像ストリームをアセンブルすることを含み、少なくとも前記符号化されたフラグメントの第１の部分を前記符号化されたフラグメントの第２の部分と組合せることを含み、前記第１の映像ストリームは、前記第１のユーザセッションに個人化されており、前記それぞれのデータストリームをセッションごとにアセンブルすることはさらに、
前記複数のパラレルユーザセッションの第２のユーザセッションのための第２の映像ストリームをアセンブルすることを含み、少なくとも前記符号化されたフラグメントの前記第１の部分を前記符号化されたフラグメントの第３の部分と組合せることを含み、前記第２の映像ストリームは、前記第２のユーザセッションに個人化されている、方法。

【請求項2】

フレーム内で配列可能な複数のコーデックスライスを、それぞれの符号化されたフラグメントに対応するピクチャオブジェクトの表示に基づいて適用することをさらに含む、請求項１に記載の方法。

【請求項3】

デコーダ内の参照画像バッファ内の画素が、符号化されたフラグメントに基づいて設定されていない場合でも、前記バッファの画素に対し、前記符号化されたフラグメントの参照を提供することをさらに含む、先行する請求項のいずれか１項に記載の方法。

【請求項4】

前記予め規定されたデータフォーマットの規格に従って参照バッファ内の画素にシーケンシャルな処理を実施するために、コーデックスライスまたは符号化されたフラグメントを組合せることをさらに含む、先行する請求項のいずれか１項に記載の方法。

【請求項5】

前記メモリは、画像フラグメントを再使用するために一時的に格納するための、高速でアクセス可能なメモリである、先行する請求項のいずれか１項に記載の方法。

【請求項6】

前記高速でアクセス可能なメモリから、前記一時的に格納された画像フラグメントにアクセスすることをさらに含む、請求項５に記載の方法。

【請求項7】

各々それぞれの符号化されたフラグメントにそれぞれのタグを追加することをさらに含む、先行する請求項のいずれか１項に記載の方法。

【請求項8】

前記それぞれのタグに基づき、それぞれの符号化されたフラグメントを前記メモリから取出すことをさらに含む、請求項７に記載の方法。

【請求項9】

テクスチャマッピングデータを作成して、符号化されたフラグメントにおいて適用することをさらに含む、先行する請求項のいずれか１項に記載の方法。

【請求項10】

前記符号化されたフラグメントを作成することは、前記再使用可能な画像データの形状または大きさを参照するデータを使用することを含む、先行する請求項のいずれか１項に記載の方法。

【請求項11】

前記映像ストリームをアセンブルすることは、テキスト、画像、映像、および音声からなる群から選択されるメディアアセットを再使用することを含む、先行する請求項のいずれか１項に記載の方法。

【請求項12】

前記映像ストリームをアセンブルすることは、前記映像ストリームによって符号化された画像において空き空間を占めるように１つ以上の充填フレームを前記サーバからクライアント装置へ送信することを含む、先行する請求項のいずれか１項に記載の方法。

【請求項13】

少なくとも１つのサーバと少なくとも１つのクライアント装置との間で複数のそれぞれのパラレルユーザセッションを提供するための方法であって、
画像データの符号化されたフラグメントを再使用するためにメモリに格納することと、
アプリケーションフラグメント作成サーバにより、符号化されたフラグメントを識別する情報に基づいて、前記メモリに格納されている符号化されたフラグメントを規定することとを含み、再使用可能な画像データに基づき、符号化されたフラグメントを作成することを含み、前記符号化されたフラグメントは、予め定められたデータフォーマットを有する映像ストリームを合成するのに適しており、前記符号化されたフラグメントは、前記映像ストリームの全画面サイズよりも小さく、前記方法はさらに、
前記符号化されたフラグメントを前記アプリケーションフラグメント作成サーバから送信して、映像ストリーム合成サーバにより受信されるようにすることを含み、前記映像ストリーム合成サーバは、
前記複数のパラレルユーザセッションの第１のユーザセッションのための第１の映像ストリームをアセンブルするように構成され、少なくとも前記符号化されたフラグメントの第１の部分を前記符号化されたフラグメントの第２の部分と組合せることを含み、前記第１の映像ストリームは、前記第１のユーザセッションに個人化されており、前記映像ストリーム合成サーバはさらに、
前記複数のパラレルユーザセッションの第２のユーザセッションのための第２の映像ストリームをアセンブルするように構成され、少なくとも前記符号化されたフラグメントの前記第１の部分を前記符号化されたフラグメントの第３の部分と組合せることを含み、前記第２の映像ストリームは、前記第２のユーザセッションに個人化されている、方法。

【請求項14】

少なくとも１つのサーバと複数のクライアント装置との間で複数のそれぞれのパラレルユーザセッションをストリーミングするための方法であって、
アプリケーションフラグメント作成サーバから、符号化されたフラグメントを映像ストリーム合成サーバにおいて受信することを含み、前記符号化されたフラグメントは、予め規定されたデータフォーマットを有する映像ストリームにアセンブルするのに適しており、前記符号化されたフラグメントは、前記映像ストリームの全画面サイズよりも小さく、前記方法はさらに、
前記符号化されたフラグメントを再使用するためにローカルメモリへ格納することと、
それぞれのデータストリームをセッションごとにアセンブルすることとを含み、前記それぞれのデータストリームは、セッションごとに前記符号化されたフラグメントを使用する映像データを含み、前記それぞれのデータストリームをセッションごとにアセンブルすることは、
前記複数のパラレルユーザセッションの第１のユーザセッションのための第１の映像ストリームをアセンブルすることを含み、少なくとも前記符号化されたフラグメントの第１の部分を前記符号化されたフラグメントの第２の部分と組合せることを含み、前記第１の映像ストリームは、前記第１のユーザセッションに個人化されており、前記それぞれのデータストリームをセッションごとにアセンブルすることはさらに、
前記複数のパラレルユーザセッションの第２のユーザセッションのための第２の映像ストリームをアセンブルすることを含み、少なくとも前記符号化されたフラグメントの前記第１の部分を前記符号化されたフラグメントの第３の部分と組合せることを含み、前記第２の映像ストリームは、前記第２のユーザセッションに個人化されている、方法。

【請求項15】

請求項１−１２の１つ以上に従ったステップを含む、請求項１３または１４に記載の方法。

【請求項16】

前記映像ストリーム合成サーバにより、アプリケーションフラグメント作成サーバからフラグメントを取出すことをさらに含む、先行する請求項のいずれか１項に記載の方法。

【請求項17】

少なくとも１つのサーバと複数のクライアント装置との間で複数のそれぞれのパラレルユーザセッションをストリーミングするためのシステムであって、前記システムは、メモリに格納されている命令を含み、前記命令は、前記システムの１つ以上のプロセッサによって実行されると、前記システムに、
符号化されたフラグメントを識別する情報に基づき、符号化されたフラグメントを規定させるように構成され、再使用可能な画像データに基づき、前記符号化されたフラグメントを作成することを含み、前記符号化されたフラグメントは、予め規定されたデータフォーマットを有する映像ストリームにアセンブルするのに適しており、前記符号化されたフラグメントは、前記映像ストリームの全画面サイズよりも小さく、前記命令はさらに、
前記符号化されたフラグメントをメモリに格納させるように構成され、
それぞれのデータストリームをアセンブルさせるように構成され、前記アセンブルは、
前記複数のパラレルユーザセッションの第１のユーザセッションのための第１の映像ストリームをアセンブルすることを含み、少なくとも前記符号化されたフラグメントの第１の部分を前記符号化されたフラグメントの第２の部分と組合せることを含み、前記第１の映像ストリームは、前記第１のユーザセッションに個人化されており、前記アセンブルはさらに、
前記複数のパラレルユーザセッションの第２のユーザセッションのための第２の映像ストリームをアセンブルすることを含み、少なくとも前記符号化されたフラグメントの前記第１の部分を前記符号化されたフラグメントの第３の部分と組合せることを含み、前記第２の映像ストリームは、前記第２のユーザセッションに個人化されており、前記命令はさらに、
ユーザ命令を受信させるように構成され、
それぞれのクライアント装置に対し、前記予め規定されたデータフォーマットで前記第１の映像ストリームおよび前記第２の映像ストリームを送信させるように構成されている、システム。

【請求項18】

前記命令が、さらに、前記システムに、前記符号化されたフラグメントを高速でアクセス可能なメモリに一時的に格納させるように構成されている、請求項１７に記載のシステム。

【請求項19】

前記命令が、さらに、前記システムに、前記第１の映像ストリームおよび前記第２の映像ストリームを変換または多重化して、第１および第２のクライアント装置にそれぞれ送信させるように構成されている、請求項１７または１８に記載のシステム。

【請求項20】

前記命令が、さらに、前記システムに、サーバアプリケーションまたはユーザアプリケーションを変更して前記クライアント装置を介して表示させるように構成されている、請求項１７−１９のいずれか１項に記載のシステム。

【請求項21】

任意の形状のオブジェクトをマクロブロックにマッピングした後に前記オブジェクトをレンダリングすることをさらに含む、請求項１−１６のいずれか１項に記載の方法。

【請求項22】

前記第１の映像ストリームおよび前記第２の映像ストリームをレンダリングすることをさらに含み、
前記レンダリングすることは、
特定の映像ストリームを、予め規定されたコーデックに変換することと、
前記特定の映像ストリームに関し、構造化されたデータファイルを形成することと、
前記構造化されたデータファイル内の情報に基づき、前記特定の映像ストリームをレンダリングすることとを含む、請求項１−１６のいずれか１項に記載の方法。

【請求項23】

前記第１の映像ストリームおよび前記第２の映像ストリームをレンダリングすることをさらに含み、
前記レンダリングすることは、
セッションについてのビット要件を形成することと、
どのセッションのどのフラグメントが処理されるべきであるかを判断することとを含む、請求項１−１６のいずれか１項に記載の方法。

【請求項24】

リアルタイムで好ましくはレンダリングされる符号化されたフラグメントと、遅延以外の品質低下を伴わずに非リアルタイムでレンダリングされ得る符号化されたフラグメントとを区別することをさらに含む、請求項２３に記載の方法。

【請求項25】

音声データに接続可能な符号化されたフラグメントと、音声データに接続可能ではない符号化されたフラグメントとを区別することをさらに含む、請求項２３または２４に記載の方法。

【請求項26】

請求項１−１６および／または請求項２１−２５のいずれか１項に記載の方法を実施するための、請求項１７−２０のいずれか１項に記載のシステム。

【請求項27】

コンピュータに請求項１−１６および請求項２１−２５のいずれか１項に記載の方法を実施させるための、または、コンピュータを請求項１７−２０のいずれか１項に記載のシステムとして機能させるための、コンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

この発明は、少なくとも１つのサーバから複数のクライアントのうちの少なくとも１つのクライアントにパラレルユーザセッションをストリーミングして、当該クライアントに接続可能な表示装置上にセッションを表示するための方法に関し、当該セッションは、映像データと音声データ等の任意の追加データとを含む。この発明はさらに、このようなユーザセッションをストリーミングするためのシステムに関する。この方法はまた、この発明に従って、このような方法を実行するための、および/または、システムで使用するための、コンピュータプログラムにも関する。

【背景技術】

【0002】

ユーザアプリケーションで使用するためのユーザインターフェイスを表示するために、多くの解決策を利用することができる。周知のＰＣの次に挙げられる他の例は、たとえば、クライアント上にユーザインターフェイスをレンダリングするためのウェブブラウザ等を使用する解決策である。そのとき、たとえばＪａｖａ（登録商標）スクリプト、マクロメディア（Macromedia）フラッシュＭＸ、またはＪＡＶＡ（登録商標）ベースの環境、たとえばＭＨＰ、ＢＤ−Ｊ、および／もしくはオープン（Open）ＴＶ等のバーチャルマシンに基づき、追加のソフトウェアがしばしば使用される。このようなシステムの利点とは、魅力的な環境を作成できること、または、送信されるべきデータの量が比較的少ないことが考えられる点である。これらのシステムの欠点とは、互換性の理由により、サーバ上のソフトウェアとクライアント上のソフトウェアとの間に、高い互換性を有する動作が存在しなければならない点である。小さなバージョン差または小さな実現差が相対的にしばしば、ユーザインターフェイスの表示において動作上の問題またはずれを生じる。このような複雑なミドルウェアの別の欠点とは、ワーム、トロイの木馬（Trojan horses）またはウイルスによるバーチャネルマシンへの攻撃を含む、セキュリティ上のリスクであり得る。グラフィックユーザインターフェイスの設計における実際のユーザビリティは、通常、クライアントの機能の豊富度（feature richness）によって制約を受ける。新規の機能が導入される場合、すべてのクライアントに新規のソフトウェアバージョンが提供されると、長い時間フレームが経過し得る。さらに、このようなアップグレードは、複雑なサーバおよびデータ送信機構を必要とする。別の欠点とは、一般に公知のシステムが、クライアント側に大きな処理能力または計算能力を求める点である。

【0003】

さらにＰＣの次に、簡素であることが意図される、やはり周知のセットトップボックスが、維持の難しいミドルウェアを有する大きなクライアントとなった。少なくともアップグレードの可能性に制約があり、ソフトウェアの配信が難しい。さらに別の問題とは、セットトップボックスにおける機能性が一般に、更新をきわめて高コストにする原因であるハードウェアで実現される点である。

【発明の概要】

【課題を解決するための手段】

【0004】

上記の問題を解決するために、この発明は、少なくとも１つのサーバから、複数のクライアントのうちの少なくとも１つのクライアントに複数のパラレルユーザセッションをストリーミングして、当該クライアントに接続可能なディスプレイ上にセッションを表示するための方法を提供する。このようなセッションは、映像データと音声データ等の任意の追加データとを含み、この方法は、
−再使用可能なピクチャ情報に基づき、符号化されたフラグメントを規定するためのステップを含み、当該符号化されたフラグメントは、映像規格または映像コーデック等の予
め定められたデータフォーマットでアセンブル映像データをアセンブルするのに適しており、当該符号化されたフラグメントは、１つ以上のピクチャおよび／または１つ以上のセッションで適用するのに適しており、当該方法はさらに、
−当該符号化されたフラグメントが適用される映像データを含むデータストリームをセッションごとにアセンブルするためのステップを含む。

【0005】

この発明に従ったこのような方法の利点とは、極めて基本的な映像復号能力しか有さないクライアント等の極めてシンな（thin）クライアントも使用できる点である。たとえばユーザ側では、ＭＰＥＧストリームを復号することのできる装置があれば十分である。この発明に従った方法を使用する際に、サーバ側では多数のパラレルセッションをサポートすることができ、各セッションにつき、たとえば現行技術上でのＭｐｅｇストリームの生成に必要とされる計算能力の何分の１かの計算能力しか必要とされない。他のコーデックを用いた復号においても同じ利点が得られる。この発明を適用する際に、たとえばネットワーク接続を有するＤＶＤプレイヤー等の簡素な装置でも十分である。当然ながら、エンドユーザ側では、より複雑で利用可能な装置を適用することができる。このような装置に対しては、符号化された標準的なデータストリーム（コーデック）の表示が可能であるという点以外に、他の要件は存在しない。上記の既知のシステムに比べ、これは極めて簡素化されている。

【0006】

好ましい実施形態によると、この発明に従った方法は、フレーム内で配列可能なコーデックの複数のスライスを、符号化されたフラグメントを規定する際にグラフィカルユーザインターフェイスで表示され得るピクチャオブジェクトに依存して適用するステップを含む。有利にも、データフォーマットのピクチャ構築物を使用することができる。たとえば、ＭＰＥＧ２等において、複数のマクロブロックを使用して構築されるスライスを使用することができる。

【0007】

好ましくは、この方法はさらに、テクスチャマップに直交操作を行なって、データフォーマットの参照ピクチャから独立した、ユーザインターフェイスに対する操作を可能にするためのステップを含む。有利にも、これにより、操作を行なわなければならない実際の参照ピクチャに依存せずに、または最小限依存することにより、ユーザインターフェイスに対する操作を実行することができる。

【0008】

さらに別の好ましい実施形態によると、この発明は、デコーダ内の参照画像バッファ内の画素が、このコード化されたフラグメントに基づいて設定されていない場合でも、このバッファの画素に対し、符号化されたフラグメントの参照を提供するためのステップを含む。これにより、効果的な態様で、参照ピクチャバッファ画素をテクスチャマップとして適用することが可能になる。これにより、データ転送が減じられ、たとえばサーバ上で必要とされる計算能力が減じられる。さらに、映像ストリームにおいて自由にアクセスするための公知の映像フォーマットでたとえば提供されるＧＯＰ構造に準拠する必要がなくなり、ここでは、自由にアクセス可能な映像ストリームが必要とされない。さらに別の利点とは、参照バッファ内の画素に対して操作を順次実行するために、符号化されたフラグメントが、得られたフレキシビリティによって効果的にチェーン接続され得、ディスプレイにおける望ましい効果を生じ得る点である。

【0009】

好ましくは、この発明は、高速でアクセス可能なメモリにピクチャフラグメントを一時的に格納するステップを含む。高速でアクセス可能なメモリに符号化されたピクチャフラグメントを一時的に格納することにより、符号化されたフラグメントの再使用を高効率で適用することができる。このようなランダムアクセスメモリは、たとえばキャッシュメモリと呼ぶことができる。好ましくは、このようなキャッシュメモリは、ＲＡＭメモリとして配列される。しかしながら、キャッシュメモリの一部をそれほど高速ではないアクセス
可能メモリ、たとえばハードディスクとして配列することもできる。これにより、たとえば中断を伴う一層長い期間にわたってユーザインターフェイスが使用される、より長い時間フレーム中に、符号化されたフラグメントの保護（save guard）が可能となる。一時メモリから符号化されたフラグメントを読出すことにより、それらのフラグメントを時間遅延を伴って再使用して、当該フラグメントの符号化および再規定を回避することができる。

【0010】

好ましくは、この方法は、符号化されたフラグメントを識別するためのタグを、当該符号化されたフラグメントに追加するステップを含む。これにより、符号化されたフラグメントの使用の頻度または強度に関するデータのトラッキングが可能になり、それに基づいて、フラグメントに対し、或る優先順位を与えることができる。さらに、ディスプレイ上の使用時間および／または使用場所に関するデータを、符号化されたフラグメントに関連付けて、符号化されたフラグメントをユーザインターフェイス内に正しく組み込むための可能性を提供する。

【0011】

符号化されたフラグメントにテクスチャマッピングデータを適用するために、この方法は、好ましくは、このようなテクスチャマッピングデータを作成するためのステップを含む。符号化するステップのための入力として提供されるテクスチャマッピングフィールドに基づき、参照ピクチャ内で画素が使用され得る態様が決定され得る。テクスチャマッピングフィールド内の１つの画素または１つの画素ブロックに対し、テクスチャマップの画素がいつ再使用され得るか、または、これらの画素についてのベクトルを使用する必要があるか否かが判断され得る。さらに、加算または減算による画素値の処理が必要であるか否かを判断することができる。

【0012】

さらに別の好ましい実施形態によると、この方法は、符号化されたフラグメントを規定するためのステップにおいて、スライスの形状および／または大きさに関するデータを使用するステップを含む。異なるフォーマットおよび形態を有するスライスを使用することにより、グラフィカルユーザインターフェイスに表示されるピクチャまたは映像ピクチャを規定する、極めてフレキシブルな態様がもたらされる。

【0013】

好ましくは、符号化された映像ストリームを合成するためのステップは、テキスト、ピクチャ、映像、および／または音声等のメディアアセットを使用するためのステップを含む。これにより、マルチメディアインターフェイスの提供が可能になり、このマルチメディアインターフェイスでは、グラフィカルユーザインターフェイスの定義内において、マルチメディア要素を自由に表示することができる。これにより、たとえば、フレームを、動画または写真で規定することができる。これにより、たとえば写真を共有するアプリケーションが提供されるグラフィカルユーザインターフェイスが可能になる。一例として、セットトップボックスまたはインターネット接続されたＭｐｅｇプレイヤー、たとえばＤＶＤプレイヤーを用いて、通常のテレビ画面上に、インターネット環境内において、このように公知の写真を共有するアプリケーションを表示することができる。

【0014】

この発明のさらに別の局面は、少なくとも１つのサーバから複数のクライアントのうちの少なくとも１つのクライアントに複数のパラレルユーザセッションをストリーミングして、クライアントに接続可能なディスプレイ上にセッションを表示するためのシステムに関し、当該セッションは、映像データと、可能性として音声データ等の追加データとを含み、当該システムは、
−少なくともサーバを備え、当該サーバは、
−再使用可能な画像データを、符号化されたフラグメントに符号化し、
−少なくとも符号化されたフラグメントを含む映像ストリームをアセンブルするためのものであり、当該システムはさらに、
−少なくともユーザ命令を受信するための受信手段と、
−クライアントに対し、ＭｐｅｇまたはＨ．２６４等の予め定められたデータフォーマットで映像ストリームを送信するための送信手段とを備える。

【0015】

この発明に従ったこのようなシステムを用いることにより、符号化されたフラグメントを作成することができ、これらのフラグメントにおいては、再使用可能なピクチャデータが組込まれ、限られた計算能力を用いて複数の映像ストリームを合成して、ユーザセッションの複数のユーザインターフェイスをサポートすることが可能になる。

【0016】

このようなシステムは、好ましくは、高速アクセスメモリ、たとえば、符号化されたフラグメントを一時的に格納するためのキャッシュメモリを含む。符号化されたフラグメントを一時的に格納して再使用すること、および、それらのフラグメントを高効率で組合せることにより、相対的にわずかな計算能力および短い反応時間で、個人化された映像ストリームを生成することができる。有利にも、現行のシステムとは対照的に、クライアントにおいて参照フレームバッファの状態のコピーを保持する必要がない。

【0017】

さらに別の好ましい実施形態によると、このシステムは、データストリームを変換および／または多重化してそれらをクライアントに送信するための手段を含む。これらの手段は、帯域幅および／または計算能力のさらなる削減に寄与する。

【0018】

好ましくは、このシステムは、受信手段を含むアプリケーションサーバを備え、当該アプリケーションサーバは、サーバおよび／またはユーザアプリケーションを調節してクライアント上に表示するように配列される。好ましくは、このアプリケーションサーバは、ＭＰＥＧ−２および／またはＨ．２６４等の映像コーデック等の予め定められた映像フォーマットのパラメータを考慮する。

【0019】

さらに好ましい実施形態において、このシステムは、高速でアクセス可能なメモリのコンテンツおよびアプリケーションサーバに関するデータを交換するための手段を備える。これらの手段により、アプリケーションサーバが関連データを有しているユーザインターフェイスで使用されるべきピクチャ要素に関するデータに比べ、アプリケーション内のキャッシュメモリの最適化が可能になる。

【0020】

この発明のさらに別の局面は、上記のこの発明に従った方法を実行するための、上記のこの発明に従ったシステムに関する。さらに別の局面において、この発明は、この発明に従った方法を実行するため、および／または、この発明に従ったシステムで使用するためのコンピュータプログラムに関する。

【0021】

この発明のさらに別の局面は、任意の形状のオブジェクトがマクロブロックにマッピングされた後に当該オブジェクトを表示するための方法に関する。このような方法の利点とは、外接する矩形が重複する状態で、オブジェクトを互いの付近に表示できる点である。さらに、ゲーム効果（game effect）を可能にする、このようなオブジェクトの重複を求めることができる。

【0022】

この発明のさらに別の局面は、映像ストリームを表示するための方法に関し、この方法は、
−映像ストリームを、予め規定されたコーデックに変換するためのステップと、
−当該映像ストリームに関連付けられた、構造化された情報ファイルを作成するためのステップと、
−当該構造化された情報ファイル内の情報に基づき、映像ストリームをレンダリングするためのステップとを含む。

【0023】

このような方法の利点とは、情報ファイル内の情報を用いることにより、ネットワークを効率良く使用できる点である。

【0024】

さらに別の好ましい実施形態によると、この方法では、いわゆるＰフレームのみが使用される。

【0025】

さらに別の好ましい実施形態によると、３またはそれよりも多く等の、少なくとも２つの表示フォーマットがＶＯＢファイル内に位置付けられて、表示中に、異なるフォーマットを極めて高速に切換える。

【0026】

さらに別の好ましい実施形態によると、ファイルは、ＸＭＬ符号化された区分またはその他の態様で構造化された区分を含む。

【0027】

さらに別の好ましい実施形態において、この方法は、本来のピクチャのアスペクト比を保持するためのステップを含む。

【0028】

この発明のさらに別の局面は、この発明に従ったシステムまたは方法により、映像ストリームを表示するための方法に関し、この方法は、
−セッションについてのビット要件を規定するステップと、
−どのセッションのどのフラグメントが処理されるかを判断するステップと、
−当該セッションのためのデータストリームに認証信号を提供するステップとを含む。

【0029】

さらに別の好ましい実施形態によると、この方法は、リアルタイムで好ましくは表示されるフラグメントと、遅延以外の他の品質低下を伴わずにリアルタイム以外で表示され得るフラグメントとを区別するためのステップを含む。

【0030】

さらに別の好ましい実施形態によると、この方法は、音声データにリンクされ得るフラグメントと、音声データにリンクされ得るフラグメントとを区別するためのステップを含む。

【0031】

さらに別の好ましい実施形態によると、この方法は、１つ以上のフラグメントをドロップするためのステップを含む。

【0032】

さらに別の好ましい実施形態によると、この方法は、１つ以上のフラグメントを遅延させるためのステップを含む。

【0033】

さらに別の好ましい実施形態によると、この方法は、追加のインターフレームを提供するためのステップを含む。

【0034】

さらに別の好ましい実施形態によると、この方法は、各々がそれ自体のｑｕａｎｔ値を有するフラグメントを符号化するためのステップを含む。

【0035】

添付の図面を参照して好ましい実施形態を用いることにより、この発明のさらに別の利点、特徴、および詳細を、より一層詳細に以下に説明する。図面では、同様の要素が同じ参照番号により示され、ここで当業者は、表示された類似する要素間において、類似性だけでなく、存在し得る小さな差異も認識するであろう。

【図面の簡単な説明】

【0036】

【図1】この発明を実現するシステムの第１の好ましい実施形態の概略図である。

【図2】図１に従ったシステムの一部の好ましい実施形態の概略図である。

【図3】この発明に従ったシステムを適用するのに適したクライアントの概略図である。

【図4】この発明に従った方法の好ましい実施形態のフローチャートである。

【図5】この発明に従った方法の好ましい実施形態のフローチャートである。

【図6】この発明に従った方法の好ましい実施形態のフローチャートである。

【図7】この発明に従った方法の好ましい実施形態のフローチャートである。

【図8A】この発明に従ったシステムまたは方法におけるアプリケーションのピクチャ遷移の図である。

【図8B】この発明に従ったシステムまたは方法におけるアプリケーションのピクチャ遷移の図である。

【図8C】この発明に従ったシステムまたは方法におけるアプリケーションのピクチャ遷移の図である。

【図8D】この発明に従ったシステムまたは方法におけるアプリケーションのピクチャ遷移の図である。

【図9】この発明に従ったさらに別の好ましい実施形態の概略図である。

【図10】図９に従ったシステムの一部の概略図である。

【図11】この発明の実施形態に従ったシーケンス図である。

【図12A】この発明の実施形態に従った方法のフローチャートである。

【図12B】この発明の実施形態に従った方法のフローチャートである。

【図12C】この発明の実施形態に従った方法のフローチャートである。

【図13】この発明に従ったさらに別の好ましい実施形態の概略図である。

【図14】この発明のさらに別の好ましい実施形態のフローチャートである。

【図15】この発明に従ったピクチャ要素およびそれらの処理の概略的な例である。

【図16】この発明に従ったピクチャ要素およびそれらの処理の概略的な例である。

【図17】この発明に従ったさらに別の実施形態のフローチャートである。

【図18】この発明に従ったさらに別の実施形態のフローチャートである。

【図19】この発明のさらに別の好ましい実施形態に従ったシステム構成要素およびデータ遷移の概略図である。

【図20】この発明のさらに別の好ましい実施形態に従ったシステム構成要素およびデータ遷移の概略図である。

【図21】この発明のさらに別の好ましい実施形態に従ったシステム構成要素およびデータ遷移の概略図である。

【図22】この発明のさらに別の好ましい実施形態に従ったシステム構成要素およびデータ遷移の概略図である。

【図23】この発明のさらに別の好ましい実施形態の概略図である。

【図24】この発明のさらに別の好ましい実施形態に従ったシステム構成要素およびデータ遷移の概略図である。

【図25】この発明のさらに別の好ましい実施形態に従った方法の概略図である。

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

【0037】

第１の実施形態（図１，２）は、ユーザの表示装置上で表示されるべきユーザセッションのユーザインターフェイスを表示するためのサブシステムに関する。大まかに、この発明に従ったいわゆるフロントエンドサーバ４上で作動するアプリケーションは、クライアント装置３とも称される、いわゆるシンクライアント３を介して表示用に配列される。このようなシンクライアントは、たとえばＭＰＥＧ−２、Ｈ．２６４、ＷＩＮＤＯＷＳ（登録商標）メディア／ＶＣ−１等の相対的に簡素な映像コーデックのフォーマットで信号を表示するのに適する。フロントエンドサーバ４上で稼動するアプリケーションは一般に、データファイルとビジネス論理との組合せを一般的に含む、バックエンドサーバ５から生じるデータを適用する。このアプリケーションは、周知のインターネットアプリケーショ
ンに関係し得る。この発明は、たとえばＴＶ画面上にインターネットアプリケーション等のグラフィカルアプリケーションを表示するのに極めて有用である。このようなＴＶ画面が、ＴＦＴ画面、ＬＣＤ画面、またはプラズマ画面に関して公知であるように相対的に高い解像度を有していることが好ましいが、当然ながら、ＣＲＴ等の相対的に旧式の表示技術を有するＴＶ画面を適用することもできる。

【0038】

バックエンドサーバ５から、たとえばＸＭＬアイテムおよびピクチャファイルまたはマルチメディアピクチャファイルが通信リンクを介してフロントエンドアプリケーションサーバに転送される。そのため、フロントエンドアプリケーションサーバは、コネクション４を介してバックエンドサーバに要求を送信することができる。フロントエンドアプリケーションサーバは、好ましくは、この発明に従ったレンダラー２から生じるコネクション７を介して受信される要求に基づき、作動する。これらの要求に応答して、コンテンツアプリケーションはたとえば、ＸＭＬ記述、スタイルファイル、およびメディアアセットを提供する。この発明に従ったレンダラー２の動作を、以下により詳細に説明する。

【0039】

レンダラーの動作は、遠隔制御を介した操作によりグラフィカルユーザインターフェイスのメニュー要素または選択要素等の要素を選択することによってユーザにより示されるユーザの好みに基づいた要求９に基づき実行される。一例として、ユーザは、たとえばＤＶＤプレイヤーまたは通常のウェブアプリケーションのメニュー構造の制御に類似したこのようなアクションを実施する。要求９に応答して、レンダラーは、ＭＰＥＧ−２またはＨ．２６４等の予め定められたコーデックのフォーマットで、符号化された音声および／または映像ピクチャを提供する。受信されたピクチャは、クライアント装置３により、信号１２を介してテレビ等の表示装置上に表示するのに適したものとなる。

【0040】

図３では、このようなクライアント装置３を概略的に示す。レンダラーから受信された信号は、以下に示す態様で多重化されており、受信モジュール４４において受信され、および／または、逆多重化される。次に、当該信号は、映像復号ユニット４５における音声復号ユニット４３に別個に提供される。この映像復号ユニット４５において、ＭＰＥＧ−２により適用されるものとして２つの参照フレームバッファが概略的に示される。たとえば、Ｈ．２６４等のコーデックのイベントにおいて、１６個の参照フレームも可能である。クライアント装置に存在する復号コーデックに依存して、この発明に従った、多少進化した動作を適用することが可能であり、この動作は、図８を参照してより詳細に説明する。

【0041】

次に、図２を参照してレンダラー２をより詳細に説明する。上記のとおり、アプリケーション論理２８のためのモジュールは、エンドユーザから得られる命令９に基づいて作動する。これらの命令は、任意のネットワーク機能を介してエンドユーザの装置からモジュール２８に送信される。これに関しては、ＴＣＰ／ＩＰプロトコルに基づいたインターネット接続、ＸＲＴ２等に基づいた接続等の考え得るネットワーク機能の各々が適切である。さらに、有線または無線接続を用いて、物理的接続を提供することができる。アプリケーション論理を含むモジュール２８は、受信の後に、ユーザの命令を解釈実行する。たとえばＸＭＬページ記述に基づき、スタイリングの定義、ユーザの命令、ディスプレイの更新を規定することができる。このことは、カーソルの更新等の漸進的な更新および全画面更新に関係し得る。

【0042】

命令９のユーザの好みに基づき、モジュール２８は、表示データの更新をどのように実施しなければならないかを決定することができる。一方では、フロントエンドサーバへの要求６により、新規のＸＭＬページ記述およびスタイル定義７ａに関するデータを要求することができ、他方では、ピクチャ、映像データ、アニメーション、音声データ、フォント等７ｂなどのメディアアセットを要求することができる。しかしながら、モジュール２
８は、フラグメントエンコーダ２２、フラグメントキャッシュ２３、およびアセンブラ２４を含むレンダラー２１と交換されるデータに基づき、画面の更新および／またはそれに対する命令を規定することもできる。これらのフラグメントエンコーダ２２、フラグメントキャッシュ２３、およびアセンブラ２４については、以下により詳細に説明する。新規に供給されたデータ７ａおよび７ｂが使用される場合、これらのデータは、ピクチャデータおよび映像データのための画素およびテクスチャのマッピングをそれぞれ生じるための準備モジュール２５および２６と、音声データを処理するためのモジュール２７とにおいて、それぞれ処理される。モジュール２５は、画素データに関するデータを規定するためのレンダリング、スケーリング、および／またはブレンディングを行なうためのモジュールとして示される。モジュール２６は、たとえば画面全体または画面の一部に対する遷移効果のためのテクスチャマッピングを作成するように意図される。結果的に得られた画素およびテクスチャのマッピングは、モジュール２１に対し、それぞれ入力される。モジュール２７で処理された音声データは、音声サンプル３２として実行され、これらの音声サンプル３２は、音声エンコーダ３５で符号化され、これらのデータをマルチプレクサおよび送信機３３に向けて出力するための音声キャッシュ３６に格納される。

【0043】

モジュール２１は、この発明の好ましい実施形態に従った３つの重要な要素、すなわち、フラグメントエンコーダ２２、フラグメントキャッシュ２３、およびアセンブラ２４を含む。フラグメントエンコーダ２２は、モジュール２８ならびにモジュール２５および２６のデータに基づいてフラグメントを符号化する。符号化されたフラグメントは、好ましくは、１つ以上のピクチャを含む。より長いピクチャシーケンスもまたサポートされる。符号化されたフラグメント内のピクチャは、１つ以上の異なるスライスを合成し得る。スライスは、コーデック規格で規定され、当該コーデックに依存して既知の定義パラメータを有する。コーデックフラグメントは、目標とするピクチャの画面サイズよりも小さなピクチャを含み得る。符号化されたフラグメントスライスは、各垂直線に存在することもあれば、存在しないこともあり、完全な水平線を含むこともあれば、含まないこともある。コーデックのパラメータにより容認される場合、多数の異なるスライスが、１本の水平線上に存在し得る。

【0044】

この発明によると、上記の内容により、コーデックの通常の使用時に適用される量よりも多くの量のスライスが生じ得る。なぜなら、既知の映像エンコーダが、スライスの量を最小にすることによって最大の符号化効率を得るためである。その利点とは、この発明に従ったアセンブラが、符号化されたフラグメントを用いることにより、適用されたコーデックの要件を効率のよい態様で満たすために、符号化されたフラグメントをピクチャまたはピクチャの一部へと極めて効率よく組合せることができる点である。なぜなら、符号化されたフラグメントが、全スライスに置き換わり得るか、または、全スライスを削除することができ、このことが、スライスの一部を用いて行なえないためである。たとえば、ＭＰＥＧを適用すると、符号化されたフラグメントを生成する際に、マクロブロックの大きさの符号化を考慮することができる。これにより、アセンブラ２４による、符号化されたフラグメントの生成および／または出力されたピクチャの合成に必要な計算能力の量が減じられる。

【0045】

参照フレームバッファ内の画素が、符号化されたフラグメントによって設定されていない場合でも、符号化されたフラグメントが、クライアント装置におけるこのバッファからの画素を参照し得る態様で符号化されるため、さらに別の利点が得られる。これにより、参照フレームバッファは、テクスチャマップとして効率よく適用される。ＧＯＰ構造に準拠する必要がないため、ピクチャの種類は装置においてフレキシビリティを有する。このフレキシビリティにより、符号化されたフラグメントを、参照バッファ内の画素に対してシーケンシャルに機能するよう効果的に接続することができるようになり、ピクチャ画面に対して所望の効果を得ることができる。

【0046】

フラグメントキャッシュ２３は、符号化されたフラグメントを再使用するため、当該符号化されたフラグメントを格納するように働く。好ましくは、ユーザアプリケーションにおいて、またはたとえば、同一のアプリケーションの多くの異なるセッションにおいて、相対的にしばしば繰返される符号化されたフラグメントは、キャッシュメモリに格納される。フラグメントキャッシュから、頻繁に出現する符号化されたフラグメントを効率よく再使用することにより、サーバの処理ユニットが必要とする符号化の時間が大いに短縮される。符号化の処理時間がこのように短縮されることに加え、画素の外部複写レンダリングが回避されることにより、表面上の節約も行なわれる。

【0047】

アセンブラ２４により、多数の符号化されたフラグメントは、極めて効率のよい態様で、予め定められたフォーマットに従った映像ストリームへと組合せられ得る。必要とされるアルゴリズムは、ＭＰＧＥ−２およびＨ．２６４等の複数の映像コーデックにおいて適用される、既に述べたスライスの概念の含意に基づく。これにより、スライスは、独立した態様で符号化され得る符号化されたピクチャの一部として規定される。現行技術に従ったスライスの目的は、エラー耐性を得ることである。この発明によると、アセンブラ２４は、スライスを適用して、当該スライスを、独立して符号化される、符号化されたフラグメントへと効率的に組合せる。

【0048】

フラグメントキャッシュ２３は、ユーザインターフェイスを表示するための個人化された映像ストリームを生成するために再使用されて再度組み合わせられるべき、符号化されたフラグメントの効率を上げることを可能にする。このため、提供されたこの効率により、相対的にわずかな量の計算能力しか使用されない。たとえば、アドレス指定のために大量の記憶容量および演算能力を節約する現行技術のエンコーダに比べ、デコーダは、参照フレームバッファの状態のコピーを保持しておく必要がない。

【0049】

上記のさまざまな態様の節約により、たとえば適切なサーバ上に存在する相対的に限られた処理能力を用いて、大量の映像ストリームを生成することができる。ユーザフェイスにおいてアプリケーションを多くのユーザに配信する場合等、キャッシュに格納されたピクチャ要素を相対的に頻繁に再使用することができる場合、このような節約を大いに達成することができる。

【0050】

図４では、フラグメントを符号化する方法の好ましい実施形態がフローチャートで表示される。フラグメントエンコーダ２２への入力は、１つ以上のピクチャのシーケンスを含み、その各々は、ピクチャの形状の記述、画素値、およびテクスチャマッピングフィールドを含む。フラグメントエンコーダに入力するためのテクスチャマッピングフィールドは、この発明に従った参照ピクチャにおいて、どの領域（manor）のピクチャポイントまたは画素が使用されるかを記述する。テクスチャマッピングフィールドは、画素または画素ブロックごとに、テクスチャマップの画素が再使用されているか否かを記述し、再使用されている場合は、これらの画素に使用されているベクトルが加算されるか、または減算されるかを記述する。

【0051】

符号化されたフラグメントは、これらの符号化されたフラグメントを他の符号化されたフラグメントと効率よく組合せるためのコードを用いて、エンコーダ内で生成される。このため、現在のエンコーダとは対照的に、この発明に従ったエンコーダは、拡張が存在する。現行技術のエンコーダに比べてエンコーダの自由度は限られているが、この発明に従ったエンコーダは、たとえばＭＰＥＧ−２を用いた量子化（Quantisation）マトリクスにおけるように、たとえば符号化されたすべてのフラグメントに定数パラメータを適用することにより、利点を生じる。

【0052】

ピクチャレベル、たとえばピクチャの順序、ピクチャの種類、動きベクトルの範囲、フレーム／フィールド、およびスライス構造に対して、符号化されたパラメータを注意深く選択することにより、これらのパラメータは、以降の段階においてマージされることが意図される、符号化されたフラグメントと互換可能となり得る。スライス構造は、ピクチャの形状によって実質的に規定されるため、現行技術に従ったスライス構造とは異なり得る。たとえば、ピクチャのうちの全ピクチャがスライスでカバーされる必要がない。

【0053】

ピクチャ情報がアプリケーション論理２８によってフラグメントエンコーダ２２に供給されると、どのピクチャが、後にマージされることが意図されているか、または、たとえば時間内に互いに使用され、これに基づいて適切な符号化パラメータの選択を容易にすることが意図されているか、を示すことができる。代替的に、セッション、または多数の同様のセッションについてのアプリケーション論理により、グローバルパラメータを設定することができる。さらに別の実施形態によると、フラグメントエンコーダは、以前に符号化されたフラグメントについての、符号化パラメータを含む多数の状態を維持し、後に、これらの状態に関するパラメータを決定する。さらに別の実施形態によると、アプリケーション論理から由来するパラメータに基づく制御なしに、競合解消がアセンブラ内で解消される。この競合解消については、アセンブラおよびその使用についての説明と共に、以下に説明する。

【0054】

この方法は、ステップ５０において開始される。ステップ５１では、画素およびテクスチャマッピングが、フラグメントエンコーダ２２により、モジュール２５および２６から読出される。このようなテクスチャマッピングまたはテクスチャマッピングフィールドは、ピクチャの形状の記述、画素値、および参照ピクチャ内の画素がどのように使用されなければならないかについての定義として作用する。画素または画素ブロック内（マクロブロック内等）において、テクスチャマッピングフィールドは、テクスチャマップから画素が再使用されているか否かを記述し、再使用されている場合、これらの画素に対して使用され得ることが考えられるベクトルと、可能性として、画素値が加算されなければならないか、または減算されなければならないかとを記述する。これにより、テクスチャ画素のブロックの２Ｄの動きを実現化させることができる。復号されたフラグメントピクチャを参照ピクチャ内に組込むこともできるため、この処理はインタラクティブであり得、それにより、連続するピクチャ内の同じ画素に対するテクスチャマッピングの処理が可能になる。

【0055】

ステップ５２では、ピクチャの再構成、ピクチャの種類、およびパラメータが設定されている。ピクチャの順序およびピクチャ／スライスの種類に加え、マクロブロックの種類が、テクスチャマッピングフィールドから導出される。ピクチャの順序は、テクスチャおよび画素が使用されなければならない順序によって決まる。マクロブロックがテクスチャ画素を再使用する状況において、好ましくは、マクロブロックは、インター符号化され、動きベクトルは、テクスチャマッピングフィールドによって決定される。マクロブロックがテクスチャ画素を再使用せず、入力用に提供された画素値により決定される場合、マクロブロックはイントラコード化される。

【0056】

ステップ５３では、参照ピクチャ、ピクチャの形状、およびスライス構造が設定される。上記の方法によると、このために、現行技術から公知であるように、スライスの数は最小化されないものの、コーデックを鑑みて表示されるべき画素要素に依存してスライスの符号化を最適化する観点から、フラグメントが符号化される。水平なマクロブロック線の１本ごとに新規のスライスを必要としないコーデック、たとえばＨ．２６４の場合、エンコーダが、フラグメントに関連して正しく機能することが重要である。たとえば他のフラグメントが、予め定められたフラグメントの左側または右側においてマクロブロック線上に共に存在する場合、これは、符号化されたメタ情報に基づく。たとえばｍｐｅｇ−２を
用いると、１本の水平マクロブロック線につき１つの新規のスライスが必要とされる。

【0057】

以下により詳細に説明するアセンブラ２４では、スライスの一部ではなく全スライスが、ピクチャフレームから置き換わるか、または削除され得る。符号化されるべきメタ情報において、追加のスライスを位置付ける必要がある場合、アセンブラ２４において、このような追加または置換は考慮されない。他のフラグメントによって背景ピクチャ内の或る区域を充填する際に、このような方法は有用である。ピクチャ情報の実際のマクロブロックがピクチャフレーム内に設けられない場合、多くのスライスを用いることにより、矩形ではないピクチャも適用することができる。このような非矩形のピクチャまたはその一部は、ピクチャ情報が背景上に投影されると視認可能である。

【0058】

ステップ５４において、各マクロブロックのエンコーダは、マクロブロックおよび／または動きベクトルの種類がテクスチャマッピングの処理により指示されたか否かをチェックする。すなわち、「テクスチャがマッピングされたか？」という質問に対する答えがどのようなものであるかがチェックされる。指示されている場合、マクロブロックの種類および動きベクトルが、テクスチャマッピングベクトルに基づいて導出される。そうではない場合、マクロブロックの種類および動き予測についてのアルゴリズムが、公知のエンコーダと同様に実行され得る。マクロブロックの種類および動き予測の規定は、ステップ５６で実施される。

【0059】

ステップ５４において、テクスチャマッピングが実施されたと判断される場合、ステップ５５において、画素が規定されたか否かがチェックされる。規定されていない場合、ステップ５７において、動きの補償、変換（Ｍｐｅｇ２の場合におけるｄｃｔ等）、および量子化等の公知の処理が実行される。量子化器は、外部設定が可能である。これにより、たとえば未処理のピクチャに比べ、合成テキストに対しては、より高品質の符号化が可能になる。代替的に、エンコーダは、この方法が実施されるユーザインターフェイスの表示用の符号化されたフラグメントに対して適用されるべきビットレートに基づき、適切な量子化器の設定を決定する。

【0060】

ステップ５８では、出力の可変長符号化が決定される。これにより、スライスのヘッダ、マクロブロックのパラメータ、およびブロック係数が、適用されたコーデックに適した態様でＶＬＣコード化され、実行される。これらのステップは、スライスの各マクロブロックごとに繰返され、この方法は、ステップ５９において、さらに別のマクロブロックまたはスライスがコード化されなければならないことが示される場合、ステップ５４に戻る。

【0061】

ステップ６０では、ステップ６１の実施がテクスチャマップを実行するのに必要であるか否かが判断される。このステップ６１において、このことがテクスチャマップに必要である場合、ループ内での逆量子化および／または動き補償および任意の後処理により、参照ピクチャが実現される。これらの新規の参照ピクチャは、フラグメント内の次のピクチャに適用される。

【0062】

次に、ステップ６２では、符号化されるべき次のピクチャが存在するか否かが判断され、存在する場合、この方法はステップ５２に戻る。最後のピクチャがインターコード化された場合、すなわち、最後に受信された、インターコード化されたピクチャが参照文字の理由によりユーザの画面上に示されない場合、符号化されたフラグメント用のピクチャを処理するための方法の最後に、追加の「変更なし」ピクチャが生成される。この方法は、ステップ６３で終了する。

【0063】

図５では、実施形態に従い、フラグメントをキャッシュに追加することに関するフラグ
メントキャッシュ２３を機能させるための方法を説明する。このキャッシュ２３は、以下に説明するように、符号化されたフラグメントを格納し、アセンブラ２４によって生成される、異なるユーザインターフェイスセッションを通じてそれらを配信するように、主として機能する。フラグメントキャッシュの第２の機能とは、再使用されていない場合にはフラグメントキャッシュ内に格納されていないものの、セッションにおいて同時に並列使用され得るライブストリームのフラグメントを配信することである。このため、フラグメントキャッシュは、ピクチャ情報を転送して多重化するよう機能する。効率を最大にするために、利用可能なシステムリソースに関して高性能の管理を実施することが極めて重要である。フラグメントキャッシュのメモリは、好ましくは、高速メモリアクセスのための多数のＲＡＭメモリを含み、好ましくはディスクメモリにより補足される。

【0064】

符号化されたフラグメントを識別するために、いわゆるキャッシュタグが適用される。このキャッシュタグは、好ましくは、別個に符号化されたフラグメントの各々に対して一意であり、符号化されたフラグメントの長い記述を含む。この独自性により、相対的に長いタグが好まれ、一方で、格納には短いタグが好まれる。この理由により、タグまたはその一部は、ルックアップテーブルと組合されて、フラグメントキャッシュによりハッシュされ得る。タグは、符号化されたフラグメントのピクチャ情報および／または画素の一意の記述の次に、この発明に従った方法で適用される、特別に符号化されたパラメータをさらに含み得る。

【0065】

符号化されたフラグメントがエンコーダ２２用の入力として提供され、フラグメントキャッシュ内に既に格納されている場合、このフラグメントは、再び符号化される必要がなく、その代わりに、最後の映像ストリームをアセンブルする際に、キャッシュからアセンブラによって読み出され得る。

【0066】

符号化されたフラグメントがキャッシュ内に格納されていない場合、キャッシュ２３における格納は、それらがコード化された後に可能になる。

【0067】

符号化されたフラグメントがキャッシュにより実際に受取られるか否かは、キャッシュ内の空きメモリの量、フラグメントが再使用される可能性、およびその頻度の可能性に依存する。このため、順位付けが行なわれ、ここでは、各新規のフラグメントに対し、当該新規のフラグメントがランキング内のどこに存在すべきかが判断される。

【0068】

この方法は、ステップ６４において開始される。ステップ６５では、キャッシュタグが新規の入力から取り出される。次にステップ６６では、当該タグがハッシュされ、探索される。タグがキャッシュ内に存在している場合、フラグメントおよび関連付けられたメタ情報がステップ６７において取り出される。ステップ６６において、フラグメントが既に格納されていることが示されると、この方法は、ステップ７１において継続され、ステップ７２で終了する。ステップ６８では、フラグメントに対して、または、たとえば当該フラグメントの符号化の頻度または複雑性に基づいた整合ランキングを有するフラグメントに対して、十分なメモリを利用することができるか否かがチェックされる。十分なメモリを利用することができない場合、ステップ６９では、より低いランキングを有するフラグメントがキャッシュから除去され、ステップ７０ではフラグメントが追加され、この方法が終了する。代替的に、キャッシュが一杯であり、そのランキングがキャッシュ内に格納されたフラグメントよりも低い場合、新規のフラグメントはキャッシュ内に格納されない。

【0069】

図６では、実施形態に従って、キャッシュからフラグメントを取り出すことに関するフラグメントキャッシュ２３を機能させるための方法を説明する。この方法は、ステップ７３において開始される。ステップ７４では、メモリ内のフラグメントを探索するために、
アセンブラによってキャッシュタグが供給される。フラグメントが存在しない場合、ステップ７８においてエラーが報告され、ステップ７９でこの方法が終了する。その他の状況の場合、フラグメントおよびメタ情報がキャッシュメモリから取り出される。次にステップ７７では、フラグメントの新たな使用に関するメタ情報が実現される。

【0070】

図７では、実施形態に従って、アセンブラ２４を機能させる方法を説明する。アセンブラは、フラグメントエンコーダで符号化されたフラグメント、できるだけ好ましくは、フラグメントキャッシュ内の格納されたフラグメントから、映像ストリームを合成するように働く。このため、フラグメントコンポーザ内の入力は、フラグメントと、当該フラグメントについての位置決め情報とを含む。

【0071】

この方法は、ステップ８０において開始される。ステップ８１では、表示されるべきピクチャに関し、映像ストリームにおいて適用可能なフラグメント、当該フラグメントを構成するスライス、および関連するピクチャパラメータが、アセンブラに入力される。ステップ８２では、起動中のフラグメントおよび／またはスライスが存在するか否かがチェックされる。起動中のフラグメントが存在しない場合、「変更のないピクチャ」がアセンブラによって生成される。以下の可能性から選択が行なわれる。アセンブラは、変更がコード化されていない、実際に適合したピクチャを生成する。または代替的に、データが生成されない。これにより、デコーダにおけるバッファが空になった場合、ピクチャがフリーズし、変更が表示されないことが想定される。これにより、ネットワークトラフィックが削減され、反応時間が改善される。

【0072】

ステップ８２では、起動中のフラグメントが存在するか否かが判断される。存在する場合、ピクチャパラメータを求めなければならない。１つの起動中のフラグメントが存在する場合、関連付けられたピクチャパラメータを、表示されるべきピクチャに適用することができる。それよりも多くのフラグメントが起動中である場合、当該パラメータを符号化するために使用されるすべてのピクチャパラメータが互換性を有するか否かがチェックされる。これに関連するパラメータは、ピクチャの順序、ピクチャの種類、動きベクトルの領域（ｆコード等）などである。

【0073】

それに伴い、ステップ８２において、フラグメントの起動中のスライスがステップ８１の入力情報内に存在していると判断された場合、ステップ８３では、競合するピクチャパラメータが実際に存在するか否かが判断される。存在する場合、ステップ８７では、以下により詳細に説明するように、一種の競合解消が使用される。

【0074】

このような競合を処理するための方法のいくつかの実施形態が存在し、その中には、以下のものが存在する。競合パラメータを有するフラグメントは、再び符号化され得る。さらに、フラグメントのパラメータに関する競合は、たとえば当該パラメータの再順位付け、複写、ドロップ、または遅延により、解消される。何らかのずれが生じ得るが、たとえば、このようなアーティファクトの表示時間が極めて短いため、これらはユーザによってほとんど知覚されない。このような競合処理の大きな利点とは、極めて僅かな計算能力しか必要としない点であり、したがって、隣同士の多くのセッションでこの競合処理が実施され得る点である。実際の例として、符号化された異なるフラグメントが異なるＰおよびＢのピクチャシーケンスを適用する場合、このことは、Ｂピクチャを複写するか、または、符号化されたフラグメントの一部から除去することにより、解消され得る。

【0075】

ステップ８４では、ディスプレイ上のＸ位置およびＹ位置を補正するために、スライスが再度位置決めされる。その目的は、セッションで使用される表示解像度および／または映像コーデックによりグラフィカルユーザインターフェイスを最適化することである。たとえば、レンダラー内のピクチャ要素が、その上でアライメントされ得るマクロブロック
、スライス、または線の位置に調整されると有利である。決定されたＸ位置およびＹ位置に関する情報が、スライスのヘッダに位置付けられる。このようにして、ヘッダに他の位置決めデータを単に記入するだけで、相対的にわずかな計算能力を用いて、再位置決めを実施することができる。

【0076】

ステップ８４における再位置決めの後に、ステップ８５では、スライスおよび／またはフラグメントがＸ位置およびＹ位置に整列され、好ましくは、使用されるコーデックにこれらが適用される順序で、最初にＹ位置に、次にＸ位置に整列される。スライスおよび／またはフラグメントの重複が生じ得る。その場合、ステップ８８では、競合解消が行なわれる。これにより、前景スライスと完全に重複する背景スライスが削除され得る。この発明に従い、多数の前景スライスが重複する場合、ピクチャ分割アルゴリズムを用いて、１つではなく２つ以上のピクチャを得ることができる。これにより、各ピクチャがそれ自体のピクチャパラメータまたはスライスパラメータを有するようになり、それらのパラメータが次々に示される。このような介入の視覚効果は、ここでもまた、人間の目によってほとんど知覚されない。これにより、２つ以上のフラグメントの交互配置が可能になる。代替的に、フラグメントエンコーダ２２が、組合された結果を生じるために、マクロブロックの画素およびテクスチャマッピング情報を用いてスライスを組合せるための手段を含むことが可能である。

【0077】

ステップ８９において、ピクチャ内のオープニングまたは空き空間がスライスによって充填されていない場合、それらが充填される。このような空き空間に関する目的を果たすために、１つ以上のスライスが規定され、これらのスライスは、これらのマクロブロックのための処理をコートしない。たとえばピクチャパラメータを含む次のピクチャヘッダが規定され、整列されたスライスと同様に、連続する態様で、かつ、ユーザインターフェイスのセッションに使用された映像規格に対応する符号化されたピクチャおよびストリームの形状で、処理される。

【0078】

図８Ａ−図８Ｄを参照して、この発明の実施形態に従った、ピクチャ遷移と、当該ピクチャ遷移を実施するための方法とを説明する。これにより、この発明によると、クライアント装置またはコード化されたもの用のデコーダの参照ピクチャ内で利用可能な画素が、テクスチャマップとして再使用可能となる。現行技術のエンコーダは、参照ピクチャが初期化されないことから、シーケンスの冒頭において適用され得ないという仮定の下で機能する。この発明によると、符号化されたフラグメントは、符号化されて、より大きなシーケンスの一部となり、当該より大きなシーケンスの一部においては、復号時における参照ピクチャが、以前に復号された符号化フラグメントの使用可能な画素を含んでいる。この発明に従ったこれらの画素は、符号化されたフラグメント用のテクスチャとして適用可能である。適用されたコーデックの特性に依存して、多数の参照ピクチャが使用され得、たとえばＭＰＥＧ−２の場合は２個の参照ピクチャが使用され、たとえばＨ．２６４の場合は１６個の参照ピクチャが使用される。

【0079】

これによって動きベクトルを適用することにより、ピクチャまたはピクチャの部分の動きを表示することができる。符号化された符号化フラグメントピクチャは、参照ピクチャの一部であるため、この処理は、反復して適用され得る。この処理では、たとえばテクスチャマッピング処理が、連続するピクチャおよびその処理に適用される。

【0080】

このような処理のさらに別の例は、たとえばピクチャがサイズを変更するアフィン変換に関する。これにより、テクスチャ画素は、図８Ｂに示すように拡大され得る。より大きな変更のため、間に挿入される１つ以上の参照ピクチャに対し、拡大されたピクチャ要素の解像度よりも良好な解像度を与えることができ、その相互参照ピクチャ（inter reference picture）に基づき、さらなる処理を実施することができる。ピクチャのグラフィッ
ク品質についての品質の要望に関して利用可能な計算能力か、または利用可能な帯域幅に基づき、小から大への遷移にいくつの参照ピクチャが再使用されたかを求めることができる。さらに、図８Ｃに示すように、異なるテクスチャピクチャの画素間における容易な遷移またはクロスフェードを提供するための重み付け予測（Ｈ．２６４）等の、コーデックに依存した可能性を使用することができる。双線形補間は、この代替例であり得る。

【0081】

テクスチャのオーバーレイおよびアルファ（Alfa）ブレンドの手法は、図８Ｄに示すように、テクスチャ画素の値を加算または減算して、その色またはアイデンティティを変更することによって達成することができる。最大値を加算または減算することにより、画素は、たとえば黒値または白値に設定され得、この処理は、クリッピングとも呼ばれる。最初に、クロミナンスおよび／または輝度の値にクリッピングのステップを適用し、次に、適切な値を加算または減算することにより、必要とされる各値を、テクスチャ内で設定することができ、各オーバーレイが画素レベルで提供され得る。このような２ステップの方法は、ほとんど視認されることなく実現され得、容易な遷移の間に確実に実現され得る。参照ピクチャを用いた、テクスチャマッピングのためのこれらの処理は、計算能力または帯域幅の僅かな使用により、大きな性能の改善をもたらす。なぜなら、表示の間中、必要とされるデータが、デコーダの参照バッファ内で利用可能なためである。さらに、符号化された異なるピクチャのデータに対する相互従属性が制限され、再使用およびキャッシュの効率が上昇する。

【0082】

この発明に従ったさらに別の好ましい実施形態（図９）は、図１のシステムと実質的に同様の目的を有するシステム１０１に関する。アプリケーションサーバ４，５上で作動するアプリケーションは、サーバ１０２およびサーバ１０３によってクライアント装置３にレンダリングを行なうように適合される。フラグメントは、アセンブリ命令と共にサーバ１０２内で作成されており、当該アセンブリ命令は、画面上の位置、および／または、クライアント装置３により受信され得る映像ストリーム内のフラグメントのタイミングに関する。次に、フラグメントおよびアセンブリ命令は、映像ストリームアセンブリサーバ１０３に送信される。この映像アセンブリサーバ１０３は、この情報に基づいて映像ストリーム８を生成し、それをクライアント装置に送出する。映像アセンブリサーバ１０３が或るフラグメントの利用可能性を有さない場合、当該映像アセンブリサーバは、サーバ１０２への要求１２８によってそれらを取出す。

【0083】

このことを、図１０においてより詳細に示す。フラグメントをアセンブルし、アセンブリ命令１０２を作成するためのサーバは、図２に示すものと実質的に同じ要素を含む。図１０の実施形態と図２の実施の形態との認識可能な差異とは、サーバ１０２および１０３が互いに分離されている点、すなわち、通信ネットワーク１１０により互いに接続可能である点である。この通信ネットワーク１１０は、好ましくは、オープンなインターネットであるが、ネットワークプロバイダの専用ネットワーク、または、インターネットアクセスを提供するためのサービスプロバイダの専用ネットワークであってもよい。サーバ１０２と１０３との間のこのようなネットワーク１１０が適用されると、このようなネットワークの公知のキャッシュ機能自体を使用することができる。インターネットの場合、たとえばノード内のキャッシュ機能がしばしば使用される。ネットワークの標準化された態様でサーバ１０２と１３０との間の通信を可能にすることにより、このネットワークを介して送信されるフラグメントは、たとえばネットワーク内のキャッシュの可能性を適用することにより、効率よく送信され得る。たとえば、ｈｔｔｐの一部である「ＧＥＴ」命令を使用することができる。

【0084】

サーバ１０３は、エンドユーザのたとえばセットアップボックス（クライアント装置）に最終的に転送される映像ストリームをアセンブルするために使用される。このフラグメントアセンブラの機能性は、図２のフラグメントアセンブラ２４のものと実質的に同様で
ある。異なる点とは、図１０のフラグメントアセンブラ２４が、ネットワーク１１０を通じた送信の後に命令を受信する点である。このことは、利用可能なフラグメントに等しく適用される。上記と同様の態様で、サーバ１０３のキャッシュ機能２３は、再使用可能なフラグメントまたは一時的に格納する必要のあるフラグメントを一時的に格納する目的を果たす。なぜなら、これらのフラグメントが、この映像ストリーム内の画像の予期される表示を見越して作成されたためである。

【0085】

フラグメントは、使用され得るか、または、サーバ１０３においてキャッシュメモリ内に直接格納され得る。このようなキャッシュメモリは、ＲＡＭメモリおよびハードディスクメモリ（ｓｓｄ）を適切に含み得る。サーバ１０２側においても、別個のユーザグループのためのいくつかのサーバ１０３において、フラグメントおよびアセンブリ情報ユニットの一時的な格納が行なわれ得る。

【0086】

ユニットの効率を高めるために、いわゆるフィラーモジュール１０５が含まれ、このフィラーモジュール１０５は、専用フィラーフレームを作成するか、または、空き情報でフレームを充填し、この空き情報は、上で開示したように、ユーザの表示装置上に表示する必要のない情報である。上で示したように、その意図とは、新規の情報を表示する必要がない場合、または、このような情報がシステムの待ち時間のためにまだ利用可能になっていない場合に、クライアント装置の画像バッファ内に存在する情報を適用して表示装置上に画像を提示することである。

【0087】

図１１を参照して、このことをより詳細に開示する。この実施形態の利点とは、このようなフィラーフレームが、サーバ１０２とサーバ１０３との間で帯域幅およびプロセッサの容量を大いに節約する点である。

【0088】

図１１では、実施形態に従い、多数のステップを実施するためのシーケンス図が示される。図１１ａは、アセンブリ情報１２９がサーバ１０２からサーバ１０３にどのように転送されるかを示す。サーバ１０３がアセンブリ情報１２９を受信した後に、サーバ１０３は、必要とされるすべてのフラグメントがキャッシュ内に存在しているか否かを判断する。存在していない場合、サーバ１０３は、情報要求１２８ａにより、必要とされるフラグメントを取出す。必要とされるフラグメントの取出および処理に必要とされる期間中に、サーバ１０３は、フィラーフレーム１３１をクライアントに送信することができ、それにより、クライアントは、画像圧縮規格に依存した態様で、必要とされる情報の表示装置を提供することができる。たとえばｍｐｅｇ２の場合、現在の装置のほとんどは、表示されるべき各フレームについての画像の構造に関し、正規の情報を必要とする。サーバ１０２は、送信されたフラグメント要求１２８ａに反応して、情報送信１２９ａにより、必要とされる符号化されたフラグメントをサーバ１０３に提供する。サーバ１０３は、当該サーバ１０３による要求を処理した後、符号化されたフラグメント１２９ａの情報を含む、符号化された音声映像ストリームを、ストリーム１０８の形で送信する。サーバ１０３は、フラグメントおよびアセンブリ情報に基づき、映像ストリームの画像をアセンブルすることができる。

【0089】

図１１ｂでは、エンドユーザがたとえば自分自身の遠隔制御装置を用いて情報要求を入力した場合に、システムがどのように機能するかを示す。ユーザは、たとえば自分の表示装置上のグラフィカルユーザインターフェイスに基づき、選択または他の入力を自分の遠隔制御装置に入力し、この入力が、クライアント装置３により受信される。これに基づき、クライアント装置は、ネットワークを介して、ユーザの希望を反映する命令をサーバ１０２に送信する。当該ネットワークは、ケーブルネットワーク、インターネット、またはモバイルネットワークを含み得る。サーバ１０２はその後、ユーザに対し、サーバ１０３を介して正しい映像ストリームが提供されるようにする。このため、アプリケーションモ
ジュール２８は、アプリケーションフロントエンド４からのデータに基づき、情報が、使用されたコーデックの構造内のどの態様において、ユーザの目的のために効率よく表示装置上に表示され得るかを判断する。その後、所望の情報が、別の好ましい実施形態を上で参照して説明したモジュール２５，２６，２７により処理される。

【0090】

その後、フラグメントエンコーダ２２は、フラグメントを作成する。アプリケーションユニット２８もまた、アセンブリ情報を作成する。アセンブリ情報は、図１１ｂの通信１２９により、たとえばオープンなインターネットを介して、サーバ１０２からサーバ１０３に転送される。その後、映像ストリーム１０８が、アセンブリ情報に基づき、フラグメントからアセンブルされ、この場合、サーバ１０３内に既に存在したフラグメント情報に基づき、アセンブルされる。このようなフラグメント情報が利用可能ではない場合、図１１ａの方法が繰返される。その結果、セットトップボックス３により、所望の映像ストリームがユーザに示される。

【0091】

図１１ｃでは、セットトップボックス３のユーザの、サーバ１０２に対する情報要求１０９により、この方法が同様に開始される。これに反応して、サーバ１０２からサーバ１０３にアセンブリ情報が送信され、その後、所望の画像を表わすのに必要な、符号化されたフラグメントが、ユーザに送信される。この場合、サーバ１０２は、これらのフラグメントがサーバ１０３に存在していないという情報を有する。たとえばライブ送信の場合、或るフラグメントがサーバ１０３において利用可能となり得ないことが、サーバに認識される。

【0092】

図１２ａでは、遠隔制御装置等の入力装置から最終的に生じるユーザ入力１２１に基づき、ユーザセッション用のアセンブリ情報が、ステップ１２２においてサーバ１０２からサーバ１０３に送信されることが示される。

【0093】

図１２ｂでは、サーバ１０２からサーバ１０３によりフラグメントを取出すための方法が示される。ステップ１２３において、サーバ１０３からサーバ１０２に要求が送信される。これらの要求では、必要とされるフラグメントのうちの利用不可能なものに基づき、それらを供給する要求が作成される。アプリケーションモジュール２８は、ステップ１２４において、アプリケーションのデータに基づき、どのデータがこれに必要とされるかを判断し、命令をこれに対して送信し、かつ、モジュール２５および２６を介してモジュール２２に送信する。サーバ１０３が所望するフラグメントが作成された後に、これらのフラグメントは、ステップ１２５においてサーバ１０２からサーバ１０３に送信される。サーバ１０３がこれらのフラグメントをより早い段階で既に作成している場合、また、これらのフラグメントがキャッシュに格納されていた場合、これらのフラグメントを、サーバに存在するキャッシュから取出すことができる。

【0094】

サーバ１０３は、図１２ｃに示すステップを実施する。ステップ１２６では、サーバ１０２により送信されたアセンブリ情報が受信される。その後、ステップ１２７では、これらのフラグメントをフラグメントアセンブラ２４に提供する要求がキャッシュ２３に対して作成される。ステップ１２８において、キャッシュユニット２３は、フラグメントが存在しているか否かを判断する。これらのフラグメントが存在していない場合、ステップ１２９において、サーバ１０２に対し、これらのフラグメントをサーバ１０３に送信する要求が作成される。これらのステップは、図１２ｂに示す方法に従って実施される。その後、必要とされるフラグメントがキャッシュ内に存在するようになるまで、この方法はステップ１２８に戻る。代替的に、要求に基づき、提供されたフラグメントは、サーバ１０２に到着するとすぐに、直接処理され得る。その後、すべてのフラグメントおよびアセンブリ情報に基づき、画像または映像ストリームがアセンブルされる。図９−図１２の実施形態において、たとえばサーバ１０２がデータセンターに配設され、サーバ１０３がクライ
アントにより近接して、たとえば近隣の設備内に配設される場合、帯域幅を一層節約することができる。サーバ１０３のフラグメントアセンブラ２４からクライアントに送信された映像ストリームは、多くの帯域幅を使用するが、これらは、反復する多数のフラグメント等の多くの冗長を含み得る。このような冗長な情報の重要部は、第１の実施形態を参照して同様に説明した態様でクライアント内の画像バッファを用いることにより、削減される。さらに、ネットワークの観点から、ネットワークのできるだけ僅かな部分を介して帯域幅を使用して、これを送信することが有利である。

【0095】

サーバ１０２とサーバ１０３との間で必要な帯域幅が含む冗長の量は、極めて制限されており、この経路は、サーバ１０３およびクライアント３からの経路より何倍も効率がよいことが考えられる。これにより、１つ以上のフラグメントエンコーダに関していくつかのフラグメントキャッシュユニットおよびフラグメントアセンブラを作動させることがさらに可能になり、それにより、数人のシステム保守オペレータにより、システムの保守を行なうことができる。これにより、保守および安定性に関する利点が得られる。

【0096】

この発明に従ったさらに別の目的は、ランダムな形状を有するオブジェクトを、マクロブロックにマッピングした後に表示することである。

【0097】

この発明のさらに別の目的は、ランダムな形状を有するオブジェクトをレンダリングして、帯域幅に関して動作効率のよい態様で表示することである。

【0098】

この発明のさらに別の目的は、ランダムな形状を有するオブジェクトをレンダリングして、計算能力に関して効率のよい態様で表示することである。

【0099】

この発明のさらに別の目的は、ランダムな形状を有するオブジェクトをレンダリングして、マイクロブロックのマッピングが使用される表示を行なうことである。

【0100】

この発明のさらに別の目的は、ランダムな形状を有するオブジェクトをレンダリングして、マクロブロックへのマッピングを適用した状態で、画像要素の互いに対する動きが可能な表示を行なうことである。

【0101】

この発明のさらに別の目的は、ランダムな形状を有するオブジェクトをレンダリングして、マクロブロックへのマッピングの適用下で画像要素の重複が可能な表示を行なうことである。

【0102】

図１３では、アプリケーションモジュール２８の実際の例のさらに好ましい実施形態を示す。この実施形態において、このモジュールは、以下の部品を含む。

【0103】

−レイアウトモジュール１５１。このレイアウトモジュールは、その特徴がそれぞれのコーデックと併用するのに適した整合状態マシンと共に、入来するデータ６、たとえばＸＭＬページおよびページ記述内のスタイル記述を記述するように配置される。

【0104】

−画面および状態マシンの状態を制御するための画面状態モジュール１５２。画面状態モジュールは、遠隔制御装置９上のキーの押圧等の入来イベント、またはたとえば、制御されたイベントに応答し、画面状態モジュールは、画像遷移の記述を生成する。

【0105】

−画面状態の遷移をスケジューリングし、かつ、フラグメントおよびフラグメントの記述をアセンブルして、たとえば当該フラグメント用のアプリケーションに方向を提供するための情報を生成するためのスケジューラ。

【0106】

図２では、レイアウトモジュール１５１の作業を示すフローチャートを示す。このレイアウトモジュールは、
−たとえばＸＭＬページ記述およびスタイル記述（６）により、アプリケーションフロントエンド４から、かつ、
−画面状態の更新により、画面状態モジュール１５２から、
情報を受信する。

【0107】

レイアウトモジュールは、多数のステップ内のこれらを、抽象的なページ記述に翻訳する。これらのステップは、ＸＭＬおよび／またはＣＳＳでページ記述を作成して、ランダムな形状を有するオブジェクトにおいて画面の記述の結果を提供することを含む。

【0108】

ステップ１５７では、ステップ１５６のオブジェクトがマッピング（変換）され、その後、ステップ１５６のこれらのオブジェクトは、ｍｐｅｇのマイクロブロック境界に基づき、矩形内に位置付けられる。その例を図１５に示す。その実際の実行および最適化は、この発明の理解の範囲内において、当業者により理解され得る。形状および１つ以上のマクロブロックとの関係に依存して、オブジェクトは、マクロブロックの適用のフレームワーク内またはビデオ用のコーデックで適用され得る別のフォーマットに適合するような多くの態様で、適合され得る。

【0109】

図１５Ａの自由に位置付けられた円に注目されたい。この円は、マクロブロックのグリッド上において、マクロブロック境界にアライメントされた所定の矩形を生じる。これは、オブジェクトに外接する矩形（円の右側の表示において、標識付けされて示される）である。

【0110】

オブジェクトがより複雑である場合、設定されたいくつかの態様の手法から、１つ以上の矩形を生じる手法を選択することができる。守るべき方針についての選択は、特に、たとえば以下のものに依存し得る。

【0111】

−オブジェクトの複雑性。
−オブジェクトに外接する矩形に対するオブジェクトの表面の比。

【0112】

−画面上でのオブジェクトの機能。
−ストリームアセンブリングサーバ１０３′のキャッシュ内でのフラグメントの利用可能性、等。

【0113】

図１５Ｂのオブジェクトの場合、考え得る分割は以下のようなものになる。
ｉ．図１５Ａで使用されるような、マクロブロック境界上の、外接する矩形。

【0114】

ii．マクロブロック境界上における、３つの最小の矩形への分割。
iii．マクロブロック境界上における、水平方向に配向された最大の矩形への分割。

【0115】

iv．マクロブロック境界上における、垂直方向に配向された最大の矩形への分割。
図１５Ａおよび図１５Ｂの（ｉ）に従った設定等の外接矩形を求めるために、以下のアルゴリズムを使用することができる。

【0116】

【数1】

【0117】

式中、floormbおよびceilmbは、それ自体が、公知の数学的関数ｆｌｏｏｒおよび関数ｃｅｉｌであり、これらは、適用されたコーデックのマクロブロックの大きさを四捨五入するように調節される。ステップ１５８では、ステップ（１５７）において生成された矩形が重複を含む場合、解決策が提供される。このステップは、重複する矩形に関するあらゆる問題を解消する目的を果たす。

【0118】

説明のため、図１６は、２つの円の周囲の矩形が重複する例Ａ）を提供する。Ｂ）およびＣ）は、この競合に対して考えられる２つの解決策である。Ｂ）では、２つの矩形が組合されて１つの外接矩形となり（ここでは、ステップ１５７からのアルゴリズムを適用することができる）、Ｃ）では、水平方向に配向された分割のための手法が選択されている。多数の異なった分割を適用することができ、或る分割のための選択は、たとえば、重複の複雑性、当該外接矩形に対する個々の矩形の表面の比、フラグメントアセンブラのキャッシュ内におけるフラグメントの利用可能性等に依存する。

【0119】

ステップ１５９では、これまでのステップの結果、重複しない矩形を有する画像が得られる。しかしながら、供給されたページ上の矩形は、全画面をほとんど構成しない。したがって、画面を完成させるさらに別のステップ、すなわち、たとえば背景の、たとえば重複しない矩形で空いた部分を充填するさらに別のステップが必要とされる。これらのステップの結果、テキストページの記述（ＸＭＬ＋ＣＳＳ）は、たとえば画面が矩形に細分され、および／または、矩形が重複しないという以下の特性を固守する抽象的なページ記述に変換される。

【0120】

図５では、状態モジュール１５２により実施される方法ステップのフローチャートが示される。この方法は、ステップ１６０において開始される。このステップでは、それに基づいて画面の状態が変化し得るイベントが待たれる。状態が変化した場合、ページ更新がレイアウトモジュールブロックに送信され、ページ変更がスケジューラに送信される。

【0121】

ステップ１６１では、イベントが生じるまで、当該状態が変更されない状態に保たれる。このようなイベントは、遠隔制御装置上でのキーの押圧だけでなく、以下のような他の内部イベントおよび外部イベントをも含み得る。

【0122】

−時間に依存したイベント（時間の経過、次のフレーム時間）。
−フロントエンドによって生じたイベント。

【0123】

−画像または映像ストリームとしての「リソース」の利用可能性またはリソースの枯渇等のリソースイベント。

【0124】

ステップ１６２では、イベントが生じない場合、状態が維持され、イベントが生じた場
合、この方法は、ステップ１６３において継続される。

【0125】

ステップ１６３では、イベントが受信された場合、ページ状態が調節される。ページの更新がレイアウトモジュールに送信され、変更がスケジューラに送信される。

【0126】

図８は、スケジューラのフローチャートを示す。スケジューラは、ステップ１７１におけるページ変更を、コーデックとの互換性を有する順序に整列させる目的を果たす。提供された記述は、フラグメントエンコーダ２２によってコーデックフラグメントに変換され得るフラグメント記述へと、スケジューラによって翻訳される。しかしながら、すべてのコーデックフラグメントが互換性を有するわけではない。たとえばｍｐｅｇにおいて、ＰフレームおよびＢフレーム内の構造は、フラグメントが同じ期間中にアセンブルされ得るか否かを決める。また、或る遷移（特にテクスチャ効果）が或る前提条件および／または事後条件を必要とすることがあり得る。スケジューラは、このような事実を判断し、所望のページ変更に関する時間線を提供する。この時間線は、ステップ１７２において映像アセンブラ２４に送信されるアセンブリ情報内で処理される。

【0127】

アセンブリ情報は、フラグメント記述によりフラグメントエンコーダに提供されたフラグメントに対するさらなる参照を含む。

【0128】

［ｐｃ０３］アプリケーションサーバ４は、コンテンツアプリケーション用のＴＶのＧＵＩ用のコンテンツを提供し、アプリケーションセッション情報を維持する。セットトップボックス３からの、遠隔制御装置を用いたユーザのキーの押圧に基づき、アプリケーション用のＴＶ画面更新がレンダラーに送信される。アプリケーションサーバは、フレキシブルなプラグインアーキテクチャを用いて、種々のＴＶコンテンツアプリケーションをホストする。ＴＶコンテンツアプリケーションは、ＧＵＩ定義を含み、このＧＵＩ定義は、ＴＶ画面上のアプリケーションの視覚インターフェイスを規定するためのＸＭＬおよびＣＳＳファイルと、私用ネットワークまたはインターネットのいずれかから実際のコンテンツにアクセスするための論理とを使用する。コンテンツは、公知の（インターネット／イントラネットの）バックエンドサーバを介してアクセスされる。

【0129】

トランスコーディング／ＶＯＤサーバ１８２は、トランスコーディングおよびＶＯＤプレイアウト機能を提供する。私用ネットワークまたはオペレータのネットワーク内のほとんどのメディアは、ＭＰＥＧ符号化されないか、または、そうではない場合、一様なＭＰＥＧ符号化特性を有さない。このトランスコーディング／ＶＯＤサーバは、Ａ／Ｖフォーマット（．ｗｍｖ，．ｆｌｖ等）を、公知の特性を有するＭＰＥＧストリームにトランスコードする。

【0130】

トランスコーディング／ＶＯＤサーバは、トランスコードされたＭＰＥＧストリームを、レンダラー２を介したプレイアウトに利用可能な状態にする。最近閲覧されたコンテンツは、最適なプレイアウト性能を得るように、キャッシュされる。

【0131】

レンダラー２は、セットトップボックスを用いて実際のセッションを確立する。レンダラー２は、アプリケーションサーバからすべてのセッションについての画面更新を受信し、各セットトップボックスに、画面情報を個々のＭＰＥＧストリームとして送信する。革新的なアルゴリズムにより、１つのレンダラーから多くのセットトップボックスに応対することが可能になり、それにより、プラットフォームは、極めてスケーラブルなものとなる。

【0132】

戻りチャネルを介してユーザから受信されたキーの押圧９は、アプリケーションサーバに転送され、このアプリケーションサーバは、セッション用のアプリケーション論理を実
行する。

【0133】

図１８に、３つの構成要素とそれらの主なインターフェイスとを示す。これらの構成要素は、１つのサーバマシン上に共に配設され得るか、または、ネットワーク内に分散され得る。３つの構成要素間の内部インターフェイス、たとえば画面更新およびキーに加え、構成要素自体は、ローカルな動作モードおよびネットワーク化された動作モードの両方をサポートするように設計される。

【0134】

この実施形態では、この発明に従い、プラットフォームに対して３つのインターフェイス、すなわち、バックエンドインターフェイス、ＳＴＢインターフェイス、および管理インターフェイスが存在する。

【0135】

アプリケーションサーバ４およびトランスコーディング／ＶＯＤサーバ１８２の構成要素はいずれも、インターネットまたは私用のオペレータイントラネットへのバックエンドインターフェイスを有し得る。アプリケーションサーバは、各コンテンツアプリケーション用のＴＶアプリケーションプラグインをホストすることができる。これらのプラグインは、ウェブサイト用のバックエンド統合に通常使用されるような、ウェブコンテンツにアクセスするための公知のメカニズム、すなわち、ＲＥＳＴ／ＳＯＡＰおよびＸＭＬウェブサービスを使用し得る。したがって、これは、所望のコンテンツプロバイダへのＨＴＴＰインターフェイスである。

【0136】

トランスコーディング／ＶＯＤサーバ１８２は、ＳＴＢにおいてユーザが特定のメディアストリームを選択したときに、レンダラーから（アプリケーションサーバを介して）ＶＯＤ要求を受ける。このため、トランスコーディング／ＶＯＤサーバは、所望のコンテンツプロバイダのメディアポータルにアクセスするためのＨＴＴＰ／ＭＭＳインターフェイスを有する。

【0137】

この発明に従ったシステムの、セットトップボックスへのインターフェイスは、一般に、ケーブルオペレータまたはＩＰＴＶインフラストラクチャを通じて稼動する。このインターフェイスは論理上、レンダラーから個々のセットトップボックスにＭＰＥＧストリームを送信するためのデータ通信チャネルと、ユーザにより押圧される遠隔制御装置のキーのための制御戻りチャネルとを含む。ＭＰＥＧデータチャネルは、簡単なＵＤＰ、ＲＴＰ、またはＨＴＴＰプロトコルを用いて実現され得る。キー用の制御チャネルは、ＲＴＳＰ、ＨＴＴＰＰＯＳＴ、またはＩｎｔｅｌ（登録商標）のＸＲＴを用いて実現され得る。

【0138】

この発明に従ったプラットフォームへのさらに別のインターフェイスが、管理インターフェイスである。プラットフォームの構成および統計は、このインターフェイスを用いることによって利用可能となる。管理インターフェイスは、ＨＴＨＰ／ＸＭＬ、ＳＮＭＰ、構成およびログファイルの組合せを用いて実現される。

【0139】

映像および音声のデジタルメディアは、種々の異なるフォーマットで入来する。コーデックだけではなく、コンテナのフォーマットも多様である。一様な符号化特性により、セットトップボックスへの一様なＭＰＥＧストリーミングインターフェイスに応対することができるように、インターネット上またはオペレータネットワーク内で利用可能なメディアのほとんどは、トランスコードされなければならない。

【0140】

これが、この発明に従ったトランスコーディングサーバが行なう内容である。トランスコーディングサーバは、ネットワークサーバからメディアコンテンツをダウンロードし、公知の符号化特性を用いて、その固有のフォーマットから、ＭＰＥＧ−２プログラムストリーム（ＶＯＢ−フォーマット）にトランスコードする。結果的に得られたＭＰＥＧ−２
メディアコンテンツは、セットトップボックスへのプレイアウト用に利用可能となり、ローカルにキャッシュされて、同一のコンテンツに対する今後の要求を極めて迅速に満たす。

【0141】

トランスコーディングサーバは、この実施形態において別個の構成要素である。図１８にシステムアーキテクチャを示す。ユーザが再生を行なうために映像を選択すると、アプリケーションサーバは、ＵＲＬを書換えて、当該選択されたＵＲＬを有するトランスコーディングサーバ１８２を指す。レンダラーはまず、トランスコーディングサーバから情報ファイル１９１を取出し、その後、選択されたメディアファイルのトランスコードされたチャンク１９２を取出す。レンダラーは、映像ストリームをＳＴＢへのＭＰＥＧストリームに統合する（ＧＵＩの一部としての部分画面または全画面）。

【0142】

図２０にトランスコード処理を示す。ＵＲＬが入力として提示される。このＵＲＬは、メディアリソースを直接指すことができ、または、ＡＳＸ等のコンテナフォーマットファイルを指すことができる。まず、必要であればリンクチェッカー１８７が調査されて、コンテナフォーマットを構文解析し、実際のメディアファイルにリンクを戻す。これらのメディアファイルは、コンテンツリトリーバにより（当該リンクが示す内容に依存してＨＴＴＰまたはＭＭＳを用いて）１つずつ取出され、トランスコーダにより、ＭＰＥＧ−２プログラムストリーム（ＶＯＢ−フォーマット）にオンザフライでトランスコードされる。

【0143】

ＶＯＢストリーム１９３は、インデクサに与えられる。インデクサは、ストリームを８ＭＢチャンクに区分し、これらを、キャッシュの一部としてディスクに書込む。インデクサはまた、区分を行なう間にインデックスファイルも生成し、ＶＯＢ内の各ストリームについてのシーケンスヘッダのオフセットを示す。インデックスファイル１９１は、ＶＯＢチャンク１９２と共に保存される。構成可能な量のディスク空間を上回ると、トランスコーダは、たとえば最長時間未使用の（ＬＲＵ）アルゴリズムを用いて、キャッシュから古いメディアを除去する。

【0144】

この処理の出力は、さらに、情報ファイルおよびＸＭＬプログラムデータからなる。部分ファイルは、このストリームに関する部分が、（一般にはトランスコーダが稼働しているＨＴＴＰサーバ上の）どこで見つけられるかを示す。プログラムＸＭＬは、処理の出力として返され、部分ファイルへのリンクを含み、たとえばＡＳＸ内の多数のクリップをサポートする。トランスコード処理の速度（およびそれによる消費リソース）が、必要とされるフレームレートと整合される。多数のトランスコーディングセッションが、構成可能なリソースしきい値を上回った場合、トランスコーダは、サービス利用不能のエラーを返す。

【0145】

トランスコーディングサーバが生成するＭＰＥＧ−２のＶＯＢストリームの各々に対し、トランスコーディングサーバは、インデックスファイルおよび部分ファイルを生成する。インデックスファイルは、ＭＰＥＧ−２ストリーム内の情報のＸＭＬ記述である。ＶＯＢ内の利用可能な映像ストリームすべてに関し、インデックスファイルは、各ＭＰＥＧシーケンスヘッダに関し、それがどのオフセットにおいて、かつ、どの（８Ｍ）チャンクにおいて見つけることができるか、および、どのフレーム番号に関連しているかを示す。インデックスファイル内の情報により、クライアントは、ＶＯＢファイル内で利用可能なストリームをシームレスに切換えることができる。これは、トリックモードのサポートにも使用することができる。

【0146】

インデックスファイルのフォーマットは、例示的に、以下のようなものになる。

【0147】

【数2】

【0148】

この情報ファイルは、ストリームパラメータの高レベルのＸＭＬ記述であり、トランスコードされたストリームの部分（すなわち８ＭＢチャンク）およびインデックスファイルをウェブサーバ上で見つけることのできるＵＲＬを示す。「マルチ」キーワードが真であると設定された場合、その部分名の％ｄは、当該部分が０から始まってシーケンシャルに番号付けされていることを示す。クライアントは、部分を獲得して、ＨＴＴＰ４０４見つかりません（ＨＴＴＰ４０４ Ｎｏｔ Ｆｏｕｎｄ）に遭遇するまで％ｄをインクリメントしなければならない。このようにして、コンテンツの長さが予め認識されていない場合でも、情報ファイルを直ちに利用可能にすることができる。

【0149】

情報ファイルのフォーマットは、例示的に以下のようになる。

【0150】

【数3】

【0151】

トランスコーダ処理の出力は、たとえばＸＭＬプログラムデータである。トランスコードされるべきＵＲＬがＡＳＸ等のコンテナファイルフォーマットを指す場合、ＡＳＸの個々の項目は個々の部分として扱われ、それにより、他のＡＳＸファイルに関しては、異なる順序で同一の部分を再使用することができ、それにより、キャッシュの利点を維持する。これは、たとえばＡＳＸファイルに広告クリップが動的に挿入される場合、特に有用である。

【0152】

したがって、ＸＭＬプログラムデータは単に部分の順序を示し、さらなる情報を得るには、部分ファイルを指す。すなわち、ＸＭＬプログラムデータは、「プログラム」内の「クリップ」を効果的に示す。ＸＭＬプログラムデータフォーマットは、以下のようになる。

【0153】

【数4】

【0154】

トランスコーディングサーバは、ストリームを、３つの異なるフォーマット、すなわち
、全画面、部分画面、およびサムネイル（ＰＡＬの場合、これは、７２０×５７６、３５２×２８８、１７６×１４４）で同時に符号化することができる。これらの３つの映像フォーマットは、１つのＭＰＥＧ−１レイヤ２音声ストリームと共に、１つのＭＰＥＧ−２／ＶＯＢストリームへとミックスされる。レンダラーは、任意の所定の瞬間において、これらのフォーマットのいずれかを表示することができる。インデックスファイルにより、ストリームのシームレスな切換えが可能になる。

【0155】

トランスコーディングサーバは、ＭＰＥＧ−２へのトランスコードの際に、ソース材料のアスペクト比（幅／高さ、一般には４：３または１６：９）を維持する。トランスコーディングサーバは、必要な場合、上／下（レターボックス）または左／右のパディングを使用する。画素のアスペクト比は、ソース材料のヘッダ内の情報から得られる。

【0156】

トリックモードのサポートが、構成要素間の以下のインタラクションにより実現される。映像の再生が開始されると、レンダラーは、ＳＴＢ（２）から（たとえばＸＲＴプロトコルを介して）、ユーザからコマンドを受信する。トリックモードの状態に関し、このようなユーザキーは、画面上の特定のトリックモードボタン選択（一時停止／ＲＥＷ／ＦＦボタン）か、または、遠隔制御装置からの特定のトリックモードキーを含み得る。

【0157】

いずれの場合も、まず、アプリケーションサーバ３にキーが転送される。このキーの値に基づき、アプリケーションサーバは、レンダラー（４）に、トリックモードコマンド（および可能性として、たとえば時間インジケータまたはプログレスバーを有する画面更新）を送信する。すると、レンダラーは、トリックモードコマンドに従って作用する。

【0158】

ＦＦ／ＲＥＷコマンドに関し、レンダラーは、インデックスファイルを調査し、ＶＯＢストリーム内の異なる位置から再生を開始する。レンダラーは、必要な場合、トランスコーディングサーバから異なるチャンクを取出す（５，６）。

【0159】

トランスコーダは、その出力のディスクキャッシュを維持する。８Ｍチャンク、インデックスファイル、および情報ファイルは、メディアリソースごとに、１つの別個のディレクトリに保存される。キャッシュ内で利用可能になる前に、かつ、キャッシュ内で利用可能になる時点で、トランスコードされたＵＲＬをトランスコードする要求が作成されると、トランスコーダは、キャッシュされた部分ファイルを直ちに返す。８Ｍメディアチャンクおよびインデックスファイルは、キャッシュ内でも保持されるが、これらは、トランスコーダの処理とは独立して応対される。なぜなら、メディアチャンク用のＵＲＬが、情報ファイル内に列挙されており、クライアントがこれらのＵＲＬをウェブサーバに直接要求するためである。

【0160】

固定サイズのチャンクは、ディスクセクタの割当およびシーク時間を改善する。ディスク空間の構成可能な限界に達すると、トランスコーダは、最長時間未使用のメディア（ＬＲＵアルゴリズム）を削除し始める。トランスコーダにおいてＬＲＵ統計を維持し得るためには、応対される情報ファイルをキャッシュ不可能として標識付けし、それにより、使用されるたびごとに、クライアントによって取出されなければならないようにする。

【0161】

スクイッド（Squid）等の公知のインターネットプロキシおよびキャッシュサーバを用いることにより、階層的なキャッシングが自動的に可能になる。すべてがキャッシュ可能として標識付けされる管理可能なチャンクへＶＯＢファイルが区分されるため、中間キャッシュは、クライアントに至る途中で８Ｍチャンクをキャッシュし、これらのチャンクを、同一のキャッシュを用いる他のクライアントが利用できるようにする。デフォルトスクイッド構成は、最適性能を得るためにそれらのmaximum_object_sizeを＞８Ｍに変更してデフォルトキャッシュサイズを拡大しなければならないが、追加の構成はほとんど必要と
されない。大量のメモリを有するキャッシュシステムにより、メモリベースの中間キャッシングが可能になり、速度を一層最適化することができる。

【0162】

階層的なキャッシングを図４に示す。インデックスファイルが、好ましくはトランスコーダから直接利用可能となる一方で、トランスコードされたＶＯＢチャンクは、中間オペレータキャッシュ内のどこかに存在し得る。ＶＯＢチャンクは、トランスコーディングサーバ上においても利用可能な状態を保っている。ＬＲＵおよび経時変化のためにＶＯＢチャンクが削除されると、すべてのＶＯＢチャンクおよび対応するインデックスファイルがトランスコーディングサーバ上で削除され、次にメディアが要求されると、トランスコード処理が再び稼働する。

【0163】

チャネル容量
音声データのプレイバックが、好ましくは正確に計時された態様で実施されることが公知である。なぜなら、人間の聴覚が、時間のずれに対して極めて敏感なためである。視覚はそれほど敏感ではなく、すなわち、映像ピクチャのずれまたは遅延をより良好な態様で補正することができる。この実施形態は、プレイバック中にこのような感度を考慮に入れた解決策を提供することを目的とする。

【0164】

特定の状況において利用可能なさらに別の実施形態（図２３）において、映像ストリーム合成サーバ１０３′の多数のセッションは、クライアントへの送信チャネルを共有する。このようなセッションは、図２４において、セッション１…セッションＮと呼ばれる。

【0165】

この実施形態に従った方法およびシステムを実施する間、このチャネルの容量は、当該チャネルに割振られたセッションの数に対しては不十分であることが考えられる。これは、たとえばいくつかのセッションが相対的に大量のピクチャリフレッシュデータをクライアントに向けて同時に送信する際、または、たとえばピクチャリフレッシャを送信するこのような期間にわたって必要とされる最大容量に対して、チャネルの次元が不足している（under dimensioned）ときに生じ得る。

【0166】

このことは、たとえばＤＶＢ環境におけるＱＡＭ−ＲＦネットワーク等の一定容量のチャネルを介して送信されているＭｐｅｇ送信ストリームに、セッションのＡＶストリームが埋込まれている場合に生じ得る。

【0167】

ｍｐｅｇコード化の場合、たとえば、各ストリームがライブの態様でｍｐｅｇにコード化される公知のｍｐｅｇエンコーダによっていくつかのパラレルセッションの各々が提供される場合、ビット割当方針を適用することが公知である。このような場合、エンコーダのもっとも重要な制御パラメータは、音声映像品質とチャネル容量とのやりとりを可能にする「ｑｕａｎｔ」パラメータである。この制御パラメータ（ｑｕａｎｔ）は、この発明によると、好ましくは適用されない。なぜなら、すべてのフラグメントが、好ましくは、予め決定されるｑｕａｎｔで、フラグメントエンコーダ２２，１０２′において作成されるためである。ストリームコンポーザ１０３′がｍｐｅｇエンコーダではなく、かつ、データをｍｐｅｇに符号化しないことに加え、これにより、ストリームを合成するサーバ１０３′においてｑｕａｎｔが利用できなくなる。なぜなら、すべてのフラグメントが、フラグメントエンコーダ２２，１０２′において既にコード化されているためである。

【0168】

各フラグメントが異なるｑｕａｎｔ値で符号化される実施形態（図示せず）において、このようなフラグメントは、フラグメントエンコーダにおいて相対的に高い計算能力と、レンダラーおよびストリーム合成サーバ１０３′の接続のためのネットワーク帯域幅に関して相対的に高い容量と、ストリーム合成サーバ１０３′のキャッシュ２３において相対的に大きな記憶容量とを必要とする。

【0169】

セッション比の制御
このような帯域幅を可能にするために提案された解決策は、チャネル容量を上回らないように、かつ、クライアント上のセッションの音声映像品質をできるだけ下げず、かつ、できるだけ容認可能なものとする態様で、チャネル容量の一部をセッションの各々に割振ることを目的とする。

【0170】

方法
さらに、一セッションあたりのビット数を減らすための方法は、音声および／または映像フラグメントの送信（スキップまたはドロップ）を防止することにより、また、音声および／または映像フラグメントを送信するのに十分なチャネル容量が利用可能になるまで当該音声および／または映像フラグメントを遅延させることにより、プレイバックからセッションを部分的に除外するステップを含む。

【0171】

フレームのスキップ−ドロップ方法
映像フラグメントのプレイバックをドロップする実施形態では、割愛されるフレームに従属しないフレームのみが示され得る。映像フレームが割愛される際にこのような従属性が表われ、インターフレームが続くとき、結果的に得られるフラグメントの視覚状態は、レンダリングされないことが考えられる。この実施形態によると、解決策は、チャネル容量の限界によって間に存在する参照フレームが割愛される際に好ましくは合成される、追加のイントラフレームを提供することである。

【0172】

遅延の方法
ＡＶアセンブラに到達した映像フラグメントは、好ましくは２つのクラスのうちの１つに割振ることができる。第１のクラスは、この音声データと好ましくは同期される音声データと共にプレイバックされ得るフラグメントを含む。第２のクラスは、音声データなしで示すことのできるフラグメントを含む。第１のクラス（リアルタイムクラス、ＲＴ）は、たとえば映画クリップを含み、第２のクラス（非ＲＴ）は、たとえばユーザインターフェイスのナビゲーション要素を含む。ＲＴクラスに入らないフラグメントについて、タイミングは重要なものではなく、これらを遅延させることができる。これにより、全システムの、知覚されるより遅い反応時間が生じ、この反応時間は、システムの実質的により長い待ち時間としてユーザに知覚される。代替的に、ＲＴデータの場合も、音声および映像データのタイミングが、ユーザにより容認可能で知覚されるパラメータ内に維持された状態で、映像データの画像品質を帯域幅に調節することができる。

【0173】

図２３に示すように、ストリーム合成サーバ１０３′の実施の形態は、容量要件データ２０１を構成して、このセッションに必要とされる帯域幅および／または計算能力の量を示すための手段を含む。

【0174】

ビット割当
各ユーザセッションにおいて、ストリーム合成サーバの論理ユニット１０３′′は、サーバ１０３に類似したサーバ１０３′内に機能上含まれる。各ストリーム合成サーバ１０３の機能上の構成要素は、上記の図１０の類似するサーバ１０３内のものと同様である。各論理ストリーム合成サーバ１０３′′は、それぞれのセッションの容量要件またはビット要件に関し、情報２０１，２０１′，２０１′′，２０１′′′を提供する。各セッションのこの情報は、ビット割当モジュール２００で処理される。このモジュールは、好ましくは、たとえば追加のソフトウェアモジュールまたは処理により、サーバ１０３′または１０３に組込まれる。

【0175】

チャネルマルチプレクサ３３は、画像および音声データ（たとえばｍｐｅｇストリーム
）をビット割当モジュール２００に送信するためのチャネルの利用可能な容量に関し、チャネルデータ２０３を送信する。チャネルデータ２０３およびチャネル要件情報２０１と共に提供された情報に基づき、ビット割当モジュールは、比制御データ２０２，２０２′，２０２′′，２０２′′′を計算または作成し、それらをそれぞれのコンポーザ１０３′′に入力する。

【0176】

好ましくは、ビット割当手段は、どのセッションのどのフラグメントを正規の領域においてドロップし、遅延させ、または合成する必要があるかも判断する。このため、好ましくは、アプリケーション論理によって本来アセンブルされていたフラグメントに関して情報の合成１２９において構成される情報等の情報が使用され、それに基づき、ユーザエクスペリエンスが最も損なわれにくいことに関する情報が求められる。

【0177】

このようなものを得るための一例として、以下の処理が、図２５に示すように、１つまたは各フレーム間隔にわたって実施される。ステップ２１１では、容量情報２０１が、セッション用のビット割当ブロックに提供される。これらのデータは、必要とされるビットの最小数、必要とされるＲＴビット、および必要とされる非ＲＴビットを含み得る。ステップ２１２では、チャネル容量データがビット割当ブロックに提供される。ビット割当ブロックは、どのセッションが妨害なしに実施されるか、また、どのセッションが遅延されたフラグメント、ドロップされたフラグメント、および／または、追加の参照フレーム（インターフレーム）を用いて実施されるかを判断するために、情報に基づいて以下の演算を行なう。

【0178】

ステップ２１３では、チャネル容量に関するデータに基づき、どの容量が必要とされているかを判断するために、すべてのセッションに対してチェックが行なわれる。ステップ２１４では、各セッションに関し、ＲＴフラグメントが割振られるまで、または、容量がフルになるまで、セッションのＲＴフラグメントに対し、容量が保持される。ステップ２１５では、すべてのＲＴデータが割振られたか否かが判断される。すべてのＲＴデータが割振られた場合、処理は、すべてのセッションのすべてのデータが割振られるまで、または、チャネル容量がフルになるまで、すべての非ＲＴデータをチャネルに割当てる状態で、ステップ２１６において継続される。すべてのＲＴデータがステップ２１４において割振られない場合、この方法は、ステップ２１７において継続される。

【0179】

ステップ２１７では、非割振データが遅延されるか、または、このようなデータがドロップされることが決定され、このドロップは、ドロップされたデータがエンドユーザの画面上に示されないような態様で行なわれる。エンドユーザは、自分の遠隔制御装置により命令を与えることができるようになり、セッションは、リフレッシュを必要とするか、または、完全にドロップされ得る。

【0180】

ステップ２１８では、結果的に得られるストリーム制御データ２０２が、このような制御データに基づき、それぞれのストリームコンポーザ１０３′′に転送され、ストリームコンポーザは、たとえばフラグメントをドロップすること、または、フラグメントを遅延させることにより、結果的に得られるストリームを調節して、制御データを遵守する。この方法は、ステップ２１９において終了する。

【0181】

フラグメントが全画像の単に一部を提供することが一般に意図されていること、および、所望のユーザエクスペリエンスを得るために、特に非ＲＴフラグメントが一般に必須ではないことを強調することができる。アプリケーションデータに基づき、フラグメントがアプリケーションによって示されることが意図された時点から１秒の何分の１だけ、このようなフラグメントの送信を遅延させることは、多数の例において、ユーザにより認識され得ず、または、ユーザは、ネットワークに基づくユーザ環境で予測され得る短い待ち時
間を経験する。したがって、この実施形態は、ロバストなユーザエクスペリエンスを提供する一方で、極めて簡素なクライアントを使用するネットワーク環境において多数のパラレルセッションを可能にするための低コストの解決策も提供する。

【0182】

図２５の方法は、エンドユーザの命令の影響を受けることが実質的に意図されない。なぜなら、この方法が、数秒、好ましくは数フレームの時間間隔等の短い時間間隔に基づいて映像データの送信を調節することを意図するためである。図１−２５を参照して説明した本実施形態に従ったシステムおよび方法は、この発明を限定することを意図しない。帯域幅または計算能力を制限して限られたインフラストラクチャのパラメータ内で相対的に多数のストリームを獲得する目標を達成するために、この発明の理解の範囲内で他の構成が可能である。

【0183】

上記においては、いくつかの好ましい実施形態に基づいてこの発明を説明してきた。異なる実施形態の異なる局面が、互いに組合されて記載されているものと考えられ、この文書に基づいて当業者が行い得るすべての組合せが含まれるべきである。これらの好ましい実施形態は、このテキストの保護範囲に対して限定的ではない。求められる権利は、前掲のクレームで規定される。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8A】

【図8B】

【図8C】

【図8D】

【図9】

【図10】

【図11】

【図12A】

【図12B】

【図12C】

【図13】

【図14】

【図15】

【図16A】

【図16B】

【図16C】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】