JP2013515445A

JP2013515445A - 双方向同期型映像視聴のためのシステムおよび方法

Info

Publication number: JP2013515445A
Application number: JP2012546091A
Authority: JP
Inventors: リーハ・シヴァンラー; オフェル・シャピーロ; アイザック・レヴィー; タル・シャローム
Original assignee: デルタ・ヴィディオ・インコーポレイテッド
Priority date: 2009-12-22
Filing date: 2010-12-17
Publication date: 2013-05-02
Also published as: AU2010341616A1; US20110154417A1; CN102668554B; EP2517469A1; WO2011087727A1; CA2782775A1; CN102668554A; US9055312B2; EP2517469A4

Abstract

本発明は、視聴者が一緒に特定の映像コンテンツを同期して見ながら、映像会議のような設定(すなわち、MBWで選択された視聴者の映像を見て、その音声を聞く)において同時に互いにやり取りできるような、複数のミニブラウジングウィンドウ(MBW)を使用して視聴者のグループ間で共有映像コンテンツ視聴を提供する、デジタル映像配信のための技法を提供する。フルスクリーンで視聴されているメインの映像ウィンドウ上で、MBWをオーバーレイとして表示することができる。

Description

関連出願の相互参照
本出願は、参照によりその全体が本明細書に組み込まれる、2009年12月22日に出願された米国仮出願第61/289,249号の優先権の利益を主張するものである。

本発明は、ケーブルTV(CATV)、衛星TV、インターネットプロトコルTV(IPTV)などの圧縮デジタル映像配信システムおよびインターネットベースの映像配信システムに関する。特に、本発明は、典型的には映像会議システムに使用される、低遅延の階層型コーデックおよびこれに対応する低遅延伝送の使用に関する。開示されるデジタル映像配信システムにより、視聴者のグループは、場所およびネットワーク帯域幅に関わらず、映像が同期して表示されるような方法で、1つまたはいくつかの選択された映像コンテンツを視聴することができる。

本出願に関連する主題は、「SYSTEM AND METHOD FOR SCALABLE AND LOW-DELAY VIDEOCONFERENCING USING SCALABLE VIDEO CODING」という名称で出願された米国特許出願第12/015,956号、「SYSTEMS AND METHODS FOR ERROR RESILIENCE AND RANDOM ACCESS IN VIDEO COMMUNICATION SYSTEMS」という名称で出願された同第11/608,776号、「SYSTEM AND METHOD FOR PROVIDING ERROR RESILIENCE, RANDOM ACCESS AND RATE CONTROL IN SCALABLE VIDEO COMMUNICATIONS」という名称で出願された同第11/682,263号、「SYSTEM AND METHOD FOR INSTANT MULTI-CHANNEL VIDEO CONTENT BROWSING IN DIGITAL VIDEO DISTRIBUTION SYSTEMS」という名称で出願された同第61/172,355号、「SYSTEM AND METHOD FOR MULTIPOINT CONFERENCING WITH SCALABLE VIDEO CODING SERVERS AND MULTICAST」という名称で出願された同第11/865,478号、「SYSTEM AND METHOD FOR VIDEOCONFEFERENCING USING SCALABLE VIDEO CODING AND COMPOSITING SCALABLE VIDEO SERVERS」という名称で出願された同第11/615,643号、および「SYSTEM AND METHOD FOR IMPROVED VIEW LAYOUT MANAGEMENT IN SCALABLE VIDEO AND AUDIO COMMUNICATION SYSTEMS」という名称で出願された同時係属仮米国特許出願第61/060,072号、ならびに「SYSTEM AND METHOD FOR A CONFERENCE SERVER ARCHITECTURE FOR LOW DELAY AND DISTRIBUTED CONFERENCING APPLICATIONS」という名称で出願された米国特許第7,593,032号に見出すことができる。上記の関連出願および発明は全て、参照によりその全体が本明細書に組み込まれる。

人々のグループがライブコンテンツまたは映像コンテンツを視聴している間に参加したいまたは協力したいと思う多くのアプリケーションがある。これらのうちのいくつかは以下の通りである。
スポーツイベント:スポーツファンは、試合を観るためだけではなく、興奮する気持ちを仲間と共有し、チームが得点したときに一緒に歓声を上げ、試合中に視点を共有するために、大規模スタジアムまたはスポーツバーを訪れる。
教育:多くの学校には会議室があり、学校はその会議室から講義を学生に向けてマルチキャストすることができる。いくつかの病院は、手術の全ての段階をライブで聴衆に示す機能を有する。学生または医者は、遠隔でコンテンツを視聴している間に視点を共有することができるように、講義または手術を一緒に観たいと思う場合がある。
ゲーム:多くのTVゲームショーは、「ライフライン(lifeline)」または「ヘルプライン(helpline)」などの概念を介した聴衆とのやり取りのための手段、または単に聴衆に特定の質問またはシーンについて投票するよう求める手段を提供する。TV局が遠隔のプレーヤを見せたいと思う場合がある、または遠隔のプレーヤ同士が互いを見て、ゲームのプレイ中にゲームについてチャットしたいと思う場合があるゲームアプリケーションもある。
企業発表:参加者のグループが企業発表を観ている間に視点を共有したいと思う場合がある株主総会、企業発表、顧客へのプレゼンなどがありうる。
ニュースおよびジャーナリズム:世界中からのニュースイベントが「今日の話題(talk of the day)」になることはめったにない。ニュースイベントの多くは、一般の関心があるものである。人々は、ニュースを観ている間にグループ内で話し合い、討論し、反応したいと思っている。

あるグループが特定の映像コンテンツについてリアルタイムで協力する多くの他の例(例えば、ファッションショー、家族イベントなど)を作成することができる。低遅延の階層型コーデックおよびそれに関連する低遅延伝送を利用する新規の技法は、同時係属米国特許出願第12/015,956号、同第11/608,776号、および同第11/682,263号、ならびに米国特許第7,593,032号に記載されている。

デジタル映像符号化/復号化技法(例えば、MPEG-2、H.263またはH.264、およびパケットネットワーク配信)としても知られているデジタル映像コーデックでは、可変伝送遅延がそれぞれの受信機で導入され、これらの技法に基づいてマルチキャストまたはブロードキャストシステムにおける同期再生を妨げる。これらの遅延は、(a)ソースと受信機との間の可変経路長によるネットワーク遅延、および(i)伝送ネットワークルータにおけるキューイング遅延を変化させることによって引き起こされる遅延ジッタ、(ii)ネットワーク内のパケットロス、および/または(iii)(無線ネットワークで体験される可変リンク帯域幅などの)伝送ネットワーク内の帯域幅変更の影響を軽減するのに必要な、(b)受信端でのデコーダによるバッファリングによって生じる遅延により引き起こされる。

IPTVおよび他のパケットネットワークベースの映像配信システムは、ネットワーク遅延およびバッファリング遅延の両方を受ける。進化するIPTV環境では、ネットワーク条件が全く予測不可能である公共インターネットなどのベストエフォート型ネットワークを介して映像が配信される場合は特に、これらの遅延が重要になりうる(例えば、最大数十秒)。映像ソースに関するそれぞれの受信機の場所に応じて、ネットワーク条件による遅延変動構成要素が重要になる場合があり、それぞれの受信機は異なる時間で同じ映像フレームを受信する場合がある。

本発明のソース映像同期型会議システムは、それぞれが異なる要件を有する、2つのオーバーレイアーキテクチャを有する。
(1)同期映像配信:映像ソースは、それぞれのユーザが同時に全く同じ映像を視聴することができるように、特定の映像コンテンツをユーザのグループに送信する(一方向)。厳密な遅延制限はないが、このシステムは「遅延等化」を必要とする。
(2)マルチポイント映像会議:ユーザのグループは、マルチポイント映像会議システムを使用して互いにやり取りすることができる(二方向)。やり取りはリアルタイムで行われなければならず、厳密な遅延限界を必要とするので、このシステムは厳密な「遅延制御」を必要とする。

従来のストリーミングベースの映像配信システムを典型的な会議システムとオーバーレイして本発明において開示されたシステムに近づけることは可能であるが、このタイプのオーバーレイは、要求される同期型視聴を実現するように遅延を制御することができない。

共時性を実現するためのネットワーク遅延等化は、異なる方法を利用することによって行うことができる。
(1)最大遅延ベースの等化:この方法は、映像ソースとグループ内のそれぞれの受信機との間の遅延を測定し、最大遅延に従ってそれぞれの受信機の表示時間を調整するアウトオブバンド制御レイヤを利用する。(a)変化するネットワーク条件は、映像が配信されているときに遅延の変化をもたらす場合があり、(b)グループに追加された、可変遅延を有する新しいユーザがいる場合があるので、この方法は、全ての遅延の測定、およびセッションを通して最大遅延の値を決定し、全ての参加者に配信するための手段を必要とする。
(2)最長経路遅延ベースの等化:この技法を用いて、映像ソースは、同じ映像をそれぞれの受信機に送信するが、(それぞれの受信機が利用可能な複数の経路がある場合)本質的に同じ量の遅延を与えるネットワーク経路に沿って送信する。例えば、映像ソースがニューヨークにあり、ニューヨークに2人のユーザおよびカリフォルニアに2人のユーザがいるとき、経路長の計算の結果として、ニューヨークの映像ソースとニューヨークおよびカリフォルニア双方のユーザとの間で同じ地理的距離を実現するために、例えばアトランタを介してニューヨークに戻る、より長い経路を使用してニューヨークのユーザにサービス提供する。この方法は、そのような等化経路が利用可能でない場合、実用的でないことがある。たとえそのような経路が利用可能である場合でも、システムは、映像ソースにより近い受信機に対して長い経路を選択することによってネットワークを非効率的に使用し、経路遅延の変動に対処することは、不可能とは言えないまでも非常に難しい。

上述の方法または類似の技法を使用してストリーミングベースの映像配信システムにおけるネットワーク遅延を等化することができるが、受信機側のバッファリング遅延はよりいっそう重要になりうる。ストリーミングシステムのデコーダは、誤り耐性のための機構としての受信機でのバッファリングに依存する。ネットワークがトリガする誤り条件は、伝送遅延が等化されているか存在していないときでも、輻輳によって生じる場合がある。失われたパケットの再送による受信機でのバッファリングは、同時係属米国特許出願第11/608,776号および同11/682,263号に記載されているように、克服できない遅延変動を引き起こす。最も大きいバッファを有する受信機が映像を表示することができるまで、それぞれの受信機がその表示を遅延するように、(最大ネットワーク遅延ベースの等化と類似した)最も大きい受信機バッファサイズを全ての受信機に伝達することができるが、これらのシステムはいずれも、映像視聴者間のライブでのやり取り向けに使用することができない。

受信機でのバッファリング遅延をなくすために、本発明は、ストリーミングシステムの代わりに、上記の映像配信システムのための映像会議システムを使用する。しかし、通常、伝送遅延が遅延の最も大きい構成要素であることを考えると、汎用の映像電話会議コーデックは遅延の問題を全く軽減しない。したがって、本発明は、同時係属米国特許出願第12/015,956号、同第11/608,776号、および同第11/682,263号、ならびに米国特許第7,593,032号に記載されている、映像の複数のレイヤを生成し、極めて重要な基本レイヤのみを保護する、低遅延階層型コーデックおよびそれに対応する低伝送遅延システムを使用する。これらの技法は、パケットロスまたは過度のパケット遅延の場合にわずかな性能低下をもたらすことによって、受信機での任意のバッファリングの必要をなくす。加えて、階層型コーデックは、将来のフレームを一切必要とすることなく、同期フレームを瞬時に生成する。同じシステムは、マルチポイント映像会議にも利用される。

H.261、H.263(映像会議に使用される)またはMPEG-1およびMPEG-2メインプロファイル(それぞれ、映像CDおよびDVDに使用される)などの従来の映像コーデックは、所与のビットレートで単一のビットストリームを提供するように設計されている。いくつかの映像コーデックはレート制御なしで設計されており、したがって可変ビットレートストリームをもたらす(例えばMPEG-2)が、通信目的で使用される映像コーデックは、特定のインフラに応じて目標となる動作ビットレートを確立する。これらの設計は、ネットワークが、映像ソースと受信機との間の事実上誤りのないチャンネルにより、一定のビットレートを提供することができることを前提としている。1対1の通信アプリケーション専用に設計されたH系のコーデックは、チャンネル誤りがある場合に堅牢性を高めるためのいくつかの追加の特徴を提供するが、依然として非常に小さい割合のパケットロス(例えば2〜3%)に対してしか耐性がない。

より小さいフレームサイズなど、より低い空間分解能が必要とされる単一レイヤ符号化の制限が存在する。フル解像度信号を送信し、受信端で復号しなければならず、したがって帯域幅および計算リソースを浪費し、受信機またはネットワークデバイスでの性能が劣化する。しかし、1つの目標は、できるだけ多くのユーザおよびミニブラウジングウィンドウ(MBW:mini browsing window)を特定のスクリーン領域に適合させることであり、当然のことながら、MBWはメインの映像番組よりも解像度が低いので、より低い解像度のサポートはオーバーレイ映像会議アプリケーションにおいて不可欠である。

階層型符号化またはスケーラブルコーデック/符号化としても知られている階層型コーデックは、明確に異種環境向けに開発された映像圧縮技法である。そのようなコーデックでは、所与のソース映像信号に対して2つ以上のレイヤ、すなわち、基本レイヤおよび少なくとも1つの拡張レイヤが生成される。基本レイヤは低下した品質でのソース信号の基本的な表示を提供し、これは、例えば、粗量子化により信号対雑音比(SNR)を低減することによって、低減された空間分解能および/または時間分解能を使用することによって、またはこれらの技法の組合せによって達成することができる。信頼できるチャンネル、すなわち保証されたまたは強化されたサービス品質(QoS:Quality of Service)を有するチャンネルを使用して、基本レイヤを送信することができる。それぞれの拡張レイヤは、SNR、空間分解能、または時間分解能を増大することによって品質を高め、低減されたQoSでまたはQoSなしで送信することができる。事実上、ユーザは、少なくとも最低レベルの品質の基本レイヤ信号を有する信号を受信するように保証される。

同期型視聴において階層型符号化を使用する別の目的は、それぞれの映像ディスプレイ上で個別化されたビューまたはレイアウト(すなわち、それぞれの受信機が異なる数およびサイズのMBWを表示することができる)、およびレート一致(すなわち、それぞれの受信機が異なる帯域幅を有するIPネットワーク接続を使用することができ、異なるデータレートを受信することを必要とする場合がある)を提供することである。

階層型映像符号化アーキテクチャでは、ソース映像(例えば、あるTVチャンネルで放映しているフットボールの試合)およびグループ内の受信機は、公共インターネットなどのネットワーク上の対応する数の物理チャンネルまたは仮想チャンネルを使用して、階層型ビットストリーム(基本レイヤに加えて、1つまたは複数の拡張レイヤ)を送信する。基本レイヤチャンネルはより高いQoSを提供することを前提とするが、拡張ストリームチャンネルはより低いQoSを提供するか、QoSを提供しない。このアーキテクチャは、基本レイヤが必ず、ほとんどロスなしにデコーダに到達することを保証する。

拡張ストリームにおけるロスは、画像品質のグレースフルデグラデーション(graceful degradation)をもたらす。したがって、エンコーダは、MBWの数もしくはサイズなどのユーザ嗜好情報、または利用可能な帯域幅などの受信機の特性に基づいて、必要となる正しい量およびタイプの情報を選択し、その情報のみをユーザの受信機に転送する。この点に関して、階層型エンコーダでの信号処理はほとんどまたは全く必要とされず、階層型エンコーダは単に入力データのパケットヘッダを読み取り、適切なパケットをそれぞれのユーザに選択的に転送する。様々な入力パケットは(それぞれのMBWに対して)2つ以上のチャンネルにアグリゲートされ、基本レイヤパケットは高信頼性チャンネルを介して送信される。

ユーザが(映像を大きいサイズで見るために)1つのMBWをメインスクリーンに拡大することを選択した場合、メインの映像番組をMBWと入れ替えることができる。その結果として、映像コンテンツの基本レイヤのみが送信され、そのMBWで表示される。

階層型コーデックを使用することにより、それぞれのユーザに対して異なる空間/時間パターンを生成するためにエンコーダ側またはネットワークデバイス(例えば、マルチポイント制御ユニット)で映像を復号し、再符号化する必要をなくすことができ、したがってアルゴリズム的遅延をもたらさない。何よりも重要なことに、エンコーダに対する計算要件が大幅に軽減される。

会議システムの使用は、マルチポイント会議の効果、ならびにユーザのMBW嗜好およびネットワーク機能に基づいて基本レイヤのみまたは基本レイヤおよび1つもしくは複数の拡張レイヤを送信する有用性を実現するためのスケーラブル映像会議スイッチ(SVCS:Scalable Video Conferencing Switch)の使用を含みうる。

ストリーミング技術を使用する多数の受信機へのIPTV映像配信は、従来技術においてよく理解されている。SVCSベースの映像会議を使用してソース映像を受信機に配信することができるが、映像をストリーミングするための典型的な映像配信技法について述べる価値はある。(1)Suman Banerjee、Bobby BhattacharjeeおよびChristopher Kommareddy、「Scalable application layer multicast」、ACM SIGCOMM Computer Communication Review、Volume 32、Issue 4(2002年10月)に記載されているようなアプリケーションレイヤマルチキャストがIPレイヤより上で実行される、および(2)IPレイヤマルチキャストがIPネットワークによって実行されるという2つの主な手法がある。

映像ソースのコンテンツが受信機のクラスタにより近いダウンストリームサーバで複製され、キャッシュされてネットワークトラフィックの量を最小限に抑えるコンテンツ配信ネットワーク(CDN:Content Distribution Network)を使用して、アプリケーションレイヤマルチキャストを実施することができる。他のタイプのシステムは、ピアツーピア(P2P)実装の場合と同様に、受信機を使用して映像を伝搬することができる。CDNの多くの変形および関連するサービスは、市場で市販されている。

IPマルチキャストは、「IP Multicast Applications: Challenges & Solutions」、RFC 3170、IETF、http://www.ietf.org/rfc/rfc3170.txtおよび同時係属米国特許出願第11/865,478号に記載されているように、IPインフラを介した多対多通信のための別のよく知られている技法である。IPマルチキャストは、パケットを多数の受信機に配信する必要がある場合でも、ソースにパケットを一度だけ送信するよう要求することによって、IPネットワークインフラを効率的に使用する。ネットワーク内のノードは、必要な場合にのみ、複数の受信機に配信するためのパケットを複製する。IPマルチキャストにおける主な概念としては、IPマルチキャストグループアドレス、マルチキャスト配信ツリー、および受信機駆動型のツリー作成が挙げられる。

IPマルチキャストグループアドレスは、コンテンツを送受信するために映像ソースおよび受信機によって使用される。ソースは、グループアドレスをそのデータパケットにおけるIP宛先アドレスとして使用する。受信機はグループアドレスを使用して、そのグループアドレスに送信されたパケットを受信したいということをネットワークに通知する。例えば、映像コンテンツがグループ239.1.1.1に関連付けられている場合、ソースは239.1.1.1に向けてデータパケットを送信する。そのコンテンツ用の受信機は、グループ239.1.1.1に送信されたデータパケットを受信したいということをネットワークに通知する。受信機は239.1.1.1に「参加」する。

受信機が特定のIPマルチキャストグループに参加すると、そのグループに対してマルチキャスト配信ツリーが構築される。このために最も広く使用されているプロトコルは、プロトコル独立マルチキャスト(PIM:Protocol Independent Multicast)である。PIMは、送信機からマルチキャストグループへのデータパケットがそのグループに「参加」している全ての受信機に到達するように、マルチキャスト配信ツリーを設定する。多くの異なる種類のPIM、すなわち、スパースモード(SM:Sparse Mode)、デンスモード(DM:Dense Mode)、ソース別モード(SSM:Source Specific Mode)および双方向モード(Bidir)がある。

1つだけの映像ソース(またはいくつかの映像ソース)および(いかなる映像も送信しない)非常に多数の受信機がある超スケーラブル映像会議セッションにおける映像コンテンツの配信は、同時係属米国特許出願第11/615,643号および米国特許第7,593,032号に記載されているように、単一のSVCS、分散されたSVCS、または複数のカスケード接続されたSVCSを利用することができる。別段に記載されていない限り、これ以降では、「SVCS」という用語は単一のSVCS、分散されたSVCSまたはカスケード接続されたSVCSのいずれかを指すものとする。

米国特許出願第12/015,956号米国特許出願第11/608,776号米国特許出願第11/682,263号米国特許出願第61/172,355号米国特許出願第11/865,478号米国特許出願第11/615,643号仮米国特許出願第61/060,072号米国特許第7,593,032号

Suman Banerjee、Bobby BhattacharjeeおよびChristopher Kommareddy、「Scalable application layer multicast」、ACM SIGCOMM Computer Communication Review、Volume 32、Issue 4(2002年10月) 「IP Multicast Applications: Challenges & Solutions」、RFC 3170、IETF、http://www.ietf.org/rfc/rfc3170.txt

本発明は、映像コンテンツ(例えば、フットボールの試合)を同期して全ての視聴者の映像ディスプレイに送信し(すなわち、実際上、全ての視聴者が実質的に同時に同じフレームを見る)、それと同時に、同時係属米国特許出願第61/172,355号に記載されているオーバーレイMBWを使用して2人以上の視聴者(例えば、フットボールファン)間での映像のやり取りを可能にするための技法を提供する。システムは、リアルタイムで映像コンテンツを配信する典型的なストリーミングベースのシステムで生じるバッファリング遅延および符号化遅延を除去することによって、映像コンテンツの同期化および並列映像会議を実現する。

旧来のデジタル映像配信システムはフル解像度映像を配信するが、本発明は階層型リアルタイムコーデックを使用する。オーバーレイされたMBWに表示される映像コンテンツは、はるかに小さい帯域幅を使用し、低い処理複雑性を可能にする低遅延の階層型コーデック(より低い解像度、より低いフレームレートまたはより低い信号対雑音比を表す)の下位レイヤを使用することができる一方で、共有視聴される映像コンテンツは、フル解像度でありながら低遅延で配信されうる。

本発明の例示的な実施形態による映像会議のための例示的なシステムを示すブロック図である。本発明の例示的な実施形態による同期型映像配信のための例示的なシステムを示すブロック図である。本発明の例示的な実施形態による映像会議のための例示的なシステムを示すブロック図である。本発明の例示的な実施形態による映像配信および映像会議のための例示的なシステムを示すネットワーク図である。本発明の例示的な実施形態による方法を示す流れ図である。本発明の例示的な実施形態による映像配信および映像会議のための例示的なシステムを示すネットワーク図である。本発明の例示的な実施形態による方法を示す流れ図である。本発明の例示的な実施形態による映像配信および映像会議のための例示的なシステムを示すネットワーク図である。本発明の例示的な実施形態による映像配信および映像会議のための例示的なシステムを示すネットワーク図である。本発明の例示的な実施形態による映像配信および映像会議のための例示的なシステムを示すネットワーク図である。本発明の例示的な実施形態による映像配信および映像会議のための例示的なシステムを示すブロック図である。本発明による例示的な映像ディスプレイスクリーンである。

図1は、映像サーバおよびオーバーレイ会議システムを使用する双方向同期型映像視聴のための例示的なシステムを示す。このシステムは、IPTVプロバイダのネットワークに配置された、1つまたは複数の物理サーバを含む映像サーバ100、ユーザまたはクライアントとしても知られている、それぞれのTVユーザの場所にある受信アプリケーション200a、200bまたは200c、および映像サーバ100を受信アプリケーション200a、200bまたは200cに相互接続する公共インターネット300を備える。図1に示されるネットワークは公共インターネット300であるが、本発明は、映像サーバ100および受信アプリケーション200a、200bまたは200cが、サービスプロバイダのネットワークアーキテクチャの選択に応じて、別のネットワーク、例えば、別のIPネットワーク、パケットネットワーク、プライベートIPネットワークと公共インターネットの組合せ、またはプライベートネットワークを介して通信できることも想定する。

双方向同期型映像視聴のための例示的な実施形態では、システムは、映像サーバ100によって送信された映像コンテンツを共有視聴している1つのユーザグループ(例えば、それぞれ受信アプリケーション200a、200b、および200cを有するユーザA、B、およびCを含む)を有する。スケーラブル映像会議スイッチ(SVCS)900は、同時係属米国特許出願第12/015,956号、同第11/608,776号、同第11/682,263号、および同第11/615,643号、ならびに米国特許第7,593,032号に記載されているようなマルチポイント会議ユニットである。SVCSは、ユーザA、B、およびC間での映像会議を可能にする。ソース管理装置901は、ネットワークにおける映像ソースのユーザグループへの割当てを処理する。受信アプリケーション200a、200b、および200cは、それぞれリンク301a、301b、および301cを介して、公共インターネット300に接続される。これらのリンク301a、301b、および301cは、4つのタイプのトラフィックを搬送する。
(1)SVCS 900を介した映像サーバ100からの映像コンテンツ、
(2)SVCS 900を介した受信アプリケーション200a、200b、および200c間の会議コンテンツ、
(3)受信アプリケーション200a、200b、および200cに存在するMBWユーザ制御クライアントと映像サーバ100に存在するMBW制御サーバとの間のMBW制御論理メッセージ(例示的なメッセージは、同時係属米国特許出願第61/172,355号において「チャンネル登録要求(Channel Subscribe Request)」メッセージ、「チャンネル登録応答(Channel Subscribe Response)」メッセージ、「チャンネル登録解除要求(Channel Unsubscribe Request)」メッセージ、および「チャンネル登録解除応答(Channel Unsubscribe Response)」メッセージとして記載されている)、および/または
(4)映像コンテンツおよび映像会議メディア伝送のためのリアルタイム転送プロトコル(RTP)パケット、映像会議のセッション管理のためのシグナリングプロトコル(例えば、セッション開始プロトコル(SIP))、および/または映像コンテンツ制御のためのリアルタイムストリーミングプロトコル(RTSP)またはハイパーテキスト転送プロトコル(HTTP)。

図1に示されるシステムは、単一のSVCS 900と並置される単一の映像サーバ100を含む(SVCS映像配信ネットワークは、同時係属米国特許出願第12/015,945号および同第11/615,643号に記載されているように、協調して動作する2つ以上の相互接続されたSVCSを含むことができる)が、本発明は、映像サーバ100およびSVCS 900を異なる拠点に配置することができることを想定する。

例示的な受信アプリケーション200a、200b、または200cは、例えば、ユーザのTV、パーソナルコンピュータ、または他のタイプのコンピュータ(例えば、IPTVセットトップボックスまたはゲームコンソール)に存在することができる。受信アプリケーション200a、200b、または200cをホスティングするTVまたはパーソナルコンピュータはそれぞれ、TVまたはコンピュータモニタとすることができる映像ディスプレイ400a、400b、または400cに接続される。

図2は、ユーザのグループが同期型映像セッションを視聴することを選択する双方向同期型映像視聴のための例示的なシステムを示す。映像サーバ100は、リンク701a、701b、および701cを使用して映像コンテンツ(例えば、映像番組またはTVチャンネル)をユーザグループ内のユーザに送信する。映像コンテンツは、バッファリング遅延が除去されていることを保証するために、低遅延の階層型コーデックを使用して符号化されている。ユーザの場所が理由でそれぞれのユーザと映像サーバとの間に顕著なネットワーク遅延差がある場合、映像サーバ100は追加の論理を実行してネットワーク遅延を決定し、遅延の等化をもたらすことができる。例示的な論理構成要素は、例えば、映像サーバ100において動作する安定した遅延測定ソフトウェア構成要素とすることができる。リンク701a、701b、および701cは以下を搬送する。
(1)映像コンテンツを伝送するためのRTP、
(2)(例えば、ユーザが会議を行い、映像コンテンツをバックグラウンドMBWに置くことを選択したときに、メインウィンドウをMBWと入れ替えるための)MBW制御論理メッセージを伝送するためのRTSPまたはHTTP、および/または
(3)ネットワーク遅延を測定し、測定されたネットワーク遅延について報告して遅延等化が必要かどうかを判定する、別のアプリケーションレイヤプロトコル(例えば、インターネットエンジニアリングタスクフォース(IETF:Internet Engineering Task Force)のインターネットプロトコル性能測定基準(IPPM:Internet Protocol Performance Metrics)作業部会によって記載されたプロトコル)。

図3は、双方向同期型映像視聴のための例示的なシステムを示す。SVCS 900および受信アプリケーション200a、200b、および200cは、同時係属米国特許出願第12/015,956号、同第11/608,776号、および同第11/682,263号、ならびに米国特許第7,593,032号に記載されているように、階層型低遅延コーデックを使用して会議を形成する。リンク703a、703b、および703cは、
(1)セッション開始およびセッション制御のためのプロトコル(例えば、SIP)、
(2)会議コンテンツのためのRTP、および/または
(3)(例えば、映像ソースを制御し、MBWウィンドウサイズを変更するための)MBW制御論理メッセージのためのRTSP、HTTPまたは別のプロトコル
を搬送する。

また、ユーザグループが同期型視聴セッションを開始するとき、SIPなどのプロトコルを映像サーバ100とユーザグループ内の受信アプリケーション200a、200b、および200cとの間で使用することができる。より具体的には、映像サーバ100は、映像コンテンツをグループ内の全員に送信するが、ユーザからいかなる会議コンテンツも受信しない、グループ内の特別な「一方向ユーザ」になる。残りのユーザ(すなわち、受信アプリケーション200a、200b、および200c)は「二方向」ユーザであり、互いにコンテンツを送受信することができる。

図4aから図4eは、SVCSベースの映像配信および会議処理に重点を置く双方向同期型映像視聴のための例示的なシステムである。原則として、同期型視聴セッションにおいて2つのタイプの会議を考えることができる。第一に、映像配信会議(VDC:video-distribution conference)は、ソースからの映像コンテンツ(例えば、フットボールの試合)をその映像コンテンツを要求する全ての受信機に配信する。VDCでは、典型的には1つだけの映像ソースおよび多くの受信機がある。しかし、多くの受信機によって同期して視聴される2つ以上のソース(例えば、複数のチャンネル)がありうる。このケースは、複数のVDCを検討することによってカバーされうる。第二に、共同閲覧会議(CVC:co-view conference)は、一部のVDC受信機間での会議である。CVCでは、参加者は映像および音声の送信および受信の両方を行う。

図4aは、VDCおよび1つまたは複数のCVCが組み合わされて、「1つの大会議(one big conference)」と呼ばれる単一の会議を形成する双方向同期型映像視聴のための例示的なシステムを示す。この図では、映像サーバ100は、ライブ映像を録画するためのカメラ110、カメラ110によって録画された映像を符号化するための階層型エンコーダ107、VoDなどのサービス向けに事前録画された映像を格納するための映像データベース101、および映像データベース101から映像をストリーミングするためのデジタル映像(DV)ストリーマ181からなる。映像サーバ100は、リンク701を使用して公共インターネット、別のIPネットワーク、パケットネットワーク、プライベートIPネットワークと公共インターネットの組合せ、またはプライベートネットワーク(図示せず)を介してSVCS 900に接続される。ソース管理装置901は、公共インターネットまたはプライベートIPネットワーク(図示せず)とすることができるリンク723を介してSVCS 900に接続する。クライアント1は、図1に記載された受信アプリケーション200-aを介してネットワークに接続される。同様に、クライアント4は受信アプリケーション200-bを介して接続され、クライアント5は受信アプリケーション200-cを介して接続される。受信アプリケーション200-a、200-b、および200-cを、ソース管理装置901および映像サーバ100をSVCS 900に接続する同じ公共インターネット、IPネットワーク、パケットネットワーク、プライベートIPネットワークと公共インターネットの組合せ、またはプライベートネットワークを介して、またはリンク301-aを使用して別のプライベートIPネットワークを介してSVCS 900に接続することもできることに留意されたい。映像サーバ100は、流れ713によってリンク701を介して映像コンテンツAをSVCS 900に送信し、SVCS 900は、示されているように、映像コンテンツをクライアント1からクライアント6の受信アプリケーションに送信する。クライアント1からクライアント6はそれぞれ、ローズ、ジョン、ジェームズ、メアリ、ジェシカ、およびアレンと呼ばれる。例えば、映像サーバ100によって送信される映像コンテンツA(例えば、フットボールの試合を特集しているTVチャンネル)を視聴している間に、映像会議を介してやり取りしたいと思っているクライアントのグループ(ローズ、ジョン、ジェームズ、メアリ、ジェシカ、およびアレン)を考える。ローズは、ジョンおよびジェームズと会議を行う要求とともに、フットボールチャンネルを要求する。ローズの会議と同時に、メアリは、(ローズ、ジョン、およびジェームズではなく)アレンおよびジェシカとのライブ会議とともに、同じフットボールチャンネルを受信するよう要求する。(フットボールチャンネル、VDC)、(ローズ、ジョンおよびジェームズ、すなわちCVC1)、および(メアリ、アレンおよびジェシカ、すなわちCVC2)は全て、共同閲覧会議は実質的に交わらないが、このチャンネルを視聴している全員が実際には同じ会議にいる、同じフットボールチャンネル会議の一部である。

「1つの大会議」実施形態では、単一のSVCSまたはSVCSネットワークを使用して効率的にメディアを受信機に配信することができる。受信機は、任意の数のソース、例えば、ライブソース、オンデマンドソース、および/または通信ソースを要求することができる。複数のソース(例えば、チャンネル)が大規模な会議に追加されるとき、それぞれのチャンネルは、通常のマルチポイント会議におけるチャンネルを視聴したいと思っている受信機のみに対してルーティングされる。2つ以上のSVCSが使用されている場合、これらのソースからのメディアストリームを、有利には単一の「トランク」において、クラウド内の局部的な(すなわち、最も近い)SVCSから受信機に送信することができる。

「1つの大会議」実施形態の問題は、それぞれのCVCに属するシグナリングメッセージがそのCVC内のみにとどまらなければならず(他のCVCに送信されてはならない)一方で、ソース映像に属するシグナリングメッセージが全ての受信機に配信されなければならないように、会議セッションシグナリングメッセージおよびフィードバックメッセージを送信しなければならないということである。これは、非標準会議シグナリングプロトコルの利用を必要とするが、これは、そうでなければ、受信機の数が増大するにつれて、対応するシグナリングメッセージの数が極めて多くなり、解決策が非スケーラブルになるからである。さらに、全てのCVCは実質上「1つの大会議」の一部であるので、任意の受信機が任意のCVCに容易に参加することができる場合、この解決策はセキュリティ問題を有することがある。

別の例示的な実施形態では、ユーザのそれぞれのグループは、その他のCVCと交わらないCVCを形成し、映像ソースは「複数の小会議(multiple small conferences)」と呼ばれるこれらのCVCのメンバになる。この会議システムでは、映像ソースは2つ以上の会議に同時に参加することができなければならない。セッションシグナリングは小さいCVCに制限され、したがって多数のユーザに拡大することができる。しかし、特別な構成が実施されていない限り、SVCSは、同じリンクを介して異なるCVCに対して同じ映像を複数回送信するよう要求されることがあるので、2つ以上のSVCSが関与するときにソース映像を効率的に配信することができない。

標準的なソース識別方法を変更することによって、この非効率的な映像配信問題を解決することができる。上記に述べた「1つの大会議」例に従うと、ローズが会議CDC1およびフットボールチャンネルを要求するとき、会議に参加する映像ソースをソース管理装置によってインデックス付けすることができ、ソース管理装置は、例えば、映像コンテンツを搬送するRTPヘッダの同期ソース(SSRC)フィールドを使用して、グローバルに一意のソース識別子によって映像ソースを特定する。通常、メアリが同じフットボールチャンネルとともに別の会議CRC2を要求するとき、メアリの会議に参加する同じソースがインデックス付けされ、異なるSSRCを使用して特定される。しかし、効率的な配信を実現するためには、これらの会議を1つとして扱わなければならない。この目的で、(例えば、同じフットボールチャンネルについての)SSRCフィールドは、それを要求する全てのCRCにわたって同じでなければならず、このことはソース管理装置およびソース送信機での特殊な処理を使用することによって実現することができる。

本発明の好ましい実施形態では、それぞれの新しいCRCが形成され、映像ソースを要求するとき、ソース管理装置は、特定のソースが既に別の会議によって要求されているかどうかを判定する。要求されている場合、同じSSRCがそのソースに割り当てられる。したがって、SVCSは映像ソースからの同じパケットをそれぞれの会議に対する新しいパケットとして扱わない。同じSSRCを割り当てることによって、ソース映像コンテンツを任意のダウンストリームSVCSに一度だけ送信することができる。

図4a-1は、図4aに示される例示的なネットワークアーキテクチャを使用する、双方向同期型TV視聴のための例示的な方法を示す。プロセスは、受信アプリケーション200-a(すなわち、クライアント1、「ローズ」)が彼女自身、ジョン、およびジェームズの間でCVCを形成し、映像コンテンツA(例えば、フットボールの試合)を受信するよう要求する290ときに開始する。次は、受信アプリケーション200-aが要求をSVCS-VDN(Video Distribution Network:映像配信ネットワーク)900に送信して291、映像コンテンツAとローズ、ジョン、およびジェームズとの間で会議を形成する。SVCS-900は要求を映像サーバ100に送信する292。次は、映像サーバ100がメッセージをソース管理装置901に送信して293、映像コンテンツAが既に任意の他の会議に送信されているかどうかを確認する。

映像が既に別の会議に送信されている場合、ソース管理装置901は既に使用されているSSRC値を映像サーバ100に返す295。次いで、映像サーバ100は、映像の1つのコピーだけがダウンストリームに送信されるように、そのSSRC値を用いて映像コンテンツAをSVCS-VDN 900に送信する294。

ソース管理装置901が、映像コンテンツAが送信されていないと判定した297場合、新しいSSRCが映像サーバ100によって作成され294、映像コンテンツAがSVCS 900に送信される296。

図4-bは、上述の2つの手法の利点を組み合わせる、「2つの会議(two conferences)」と呼ばれる双方向同期型映像視聴を提供するための別の例示的なシステムを示す。例示的な実施形態では、並置するか分散することができる2つのSVCSがある。SVCS-VDN 900はクライアントへの映像コンテンツ配信を管理し、SVCS-CVC 910-1および910-2はクライアントのグループ間の映像会議セッションを管理する。SVCS-CVCの2つのインスタンスは、クライアントのグループが、クライアントのグループに局所的にサービス提供する1つまたは複数のSVCS-CVCを有することができることを説明するために示されている。図4bはSVCS-VDN 900ならびにSVCS-CVC 910-1および910-2を単一のインスタンスとして示しているが、本発明はこれらを分散することができることを想定する。SVCS-VDN 900は、公共インターネット、別のIPネットワーク、パケットネットワーク、プライベートIPネットワークと公共インターネットの組合せ、またはプライベートネットワーク上のリンク318を介してSVCS-CVC 910-1および910-2に接続する。映像サーバ100は図4aに示されているものと同じままであることに留意されたい。

ソース管理装置901はSVCSにサービス提供する。それぞれのクライアントの受信アプリケーションは、仮想セットトップボックス(VSTB:virtual set top box)620-1、620-4、クライアントの場所に存在する、同じまたは異なるハードウェア構成要素上のローカルアプリケーションを有する。2つのアプリケーションが異なるハードウェア上に存在する場合、リンク419を用いて構成要素を受信アプリケーション200-1、200-4に接続することができ、リンク419は、例えば、有線イーサネット（登録商標）、WiFi、またはBluetooth（登録商標）とすることができる。VSTB 620-1、620-4および受信アプリケーション200-1、200-4が同じハードウェア構成要素上で動作している場合、リンク419はアプリケーション間の内部プロセッサ接続に過ぎない。クライアント1(すなわち、ローズ)の場所に存在するVSTB 620-1はリンク418を介してSVCS-CVC 910-1に接続し、リンク418は公共インターネット、別のIPネットワーク、パケットネットワーク、プライベートIPネットワークと公共インターネットの組合せ、またはプライベートネットワークを介したIP接続である。

SVCS-VDN 900は1つの会議を形成し、それぞれのSVCS-CVCは別の交わらない会議を形成する。そうする際に、それぞれの受信アプリケーション200-1、200-4は、SVCS-VDNの会議および受信アプリケーション独自のSVCS-CVCの会議の2つの会議に同時に参加しなければならない。映像コンテンツ供給装置は、ライブのユーザ通信から完全に切り離されている。それぞれの共同閲覧会議は本質的に、ユーザ間のライブのやり取りに対応するために作成される副次的な会議(side conference)である。それぞれの受信アプリケーションは、映像ソース、例えば、ライブおよび/またはオンデマンドの映像ソース、ならびに他の受信アプリケーションとのライブ会議を同時に要求することができる。この例示的な実施形態では、シグナリングメッセージは共同閲覧会議のみに制限され、ソース映像が効率的に配信されることを可能にする。その結果として、(潜在的に高度に)分散されたSVCS-VDNを単にソース映像を配信するために割り当てることができる一方で、(場合によっては単一の、またはほとんど分散されていない)SVCS-CVCを用いてCVCを処理することができる。

「2つの会議」シナリオにおける問題点は、受信アプリケーションは2つ以上の会議に同時に参加しなければならず、したがって2つのネットワークリンクでの帯域幅割当てを維持する必要があるということである。しかし、同じまたは別の実施形態では、VSTBを受信アプリケーションとともに配備して、2つのセッションを組み合わせることができる。

クライアント1は、映像サーバ100からの映像コンテンツおよびVSTB 620-1を介した共同閲覧会議を要求する。VSTB 620-1は映像コンテンツ要求をSVCS-VDN 900(すなわち、場合によっては分散された、映像配信を担当するSVCS)に転送する。SVCS-VDN 900は映像ソースをVSTB 620-1に送り返す。CVCの場合、VSTB 620-1はSVCS-CVC 910-1上で新しい会議に参加し、SVCS-CVC 910-1は、特にCVCにおけるグループを形成するために、SVCSのネットワークに接合される。

同じCVC 910-1内のそれぞれの受信アプリケーションは、1つのリンク418(例えば、公共インターネットまたはプライベートIPネットワーク)を用いてVSTB 620-1を介してSVCS-CVCに接続し、別のリンク419(例えば、公共インターネットまたはプライベートIPネットワーク)を用いて映像ソース配信を担当するSVCS-VDNに接続して、共有された映像ソースを受信する。VSTB 620-1は実質上、映像配信用のSVCSおよび会議用のSVCSの2つのSVCSによってサービス提供される。VSTB 620-1は2つの会議に対する要求を調整し、これらの要求を組み合わせ、単一の会議であるかのように受信アプリケーション200-1に送信する。ネットワークベースのVSTBを使用する利点は、VSTBが受信アプリケーション帯域幅に基づいて処理する全てのソースの帯域幅を迅速かつ最適に調整することができるということである。

映像サーバ100からの全ての映像ソースは、映像の伝搬を担当する(場合によっては分散された)SVCSによって処理される。映像ソースはソース管理装置901でインデックス付けされ、ソース管理装置901はそれぞれの受信アプリケーションの映像チャンネル要求に基づいて適切なSSRCフィールドを提供する。図4bは別個のSVCS-VDNおよびSVCS-CVCを示しているが、本発明は、同じ(場合によっては分散された)SVCSが両方の役割を果たすことができることを想定する。

図4b-1は、図4bに示されるように、VSTBが2つの会議に参加して、知覚した単一の会議ビューを受信アプリケーションに提供する、双方向TV視聴を提供するための例示的な方法を示す。プロセスは、受信アプリケーション200-a(すなわち、クライアント1、「ローズ」)が彼女自身、ジョン、およびジェームズの間で会議を形成し、コンテンツA(例えば、フットボールの試合)を受信するよう要求するときに開始する。

次は、受信アプリケーション200-aが要求をVSTB 620-1に送信する390。VSTB 620-1は要求をSVCS-CVC 910-1に送信して391、ローズ、ジョン、およびジェームズの間でCVCを形成し、それと並行して、VSTB 620-1は要求をSVCS-VDN 900に送信して377、映像コンテンツAとローズ、ジョン、およびジェームズとの間でVDNを形成する。SVCS-900は要求を映像サーバ100に送信する389。次は、映像サーバ100がメッセージをソース管理装置901に送信して392、映像コンテンツAが既に任意の他の会議に送信されているかどうかを確認する。

映像コンテンツが既に別の会議に送信されている場合、ソース管理装置901は既に使用されているSSRC値を映像サーバ100に返す395。次いで、映像サーバ100は、映像の1つのコピーだけがダウンストリームに送信されるように、そのSSRC値を用いて映像コンテンツAをSVCS-VDN 900に送信する397。

ソース管理装置901が、映像コンテンツAが送信されていないと判定した393場合、新しいSSRCが作成され394、映像コンテンツが映像サーバ100によってSVCS 900に送信される。今度は、SVCS 900が新しい会議を形成する396。

VSTB 620-1は2つの会議(CVCおよびVDN)のメンバであるので、VSTB 620-1は2つの会議を組み合わせ399、単一の会議を受信アプリケーション200aに送信する。

図4cは、分散されたSVCSを含む、双方向同期型映像視聴のための例示的なシステムを示す。例えば、映像ソース100A、B、C、およびD+E+Fに対して別個のSVCS VDNを利用することができ、VSTB 620-1は対応するSVCS VDN Cからの映像ソースを要求する。VSTB 620-1は、どのSVCS VDNがソース管理装置901を介してどの映像ソースをサービス提供するかを決定することができる。

チャンネルソースプロキシ(CSP:channel sources proxy)を使用することによって、上記に述べた「2つの会議」実施形態をさらに最適化することができる。図4dは、それぞれの映像ソース供給装置107A、107B、107C、107Cr、D、Eがそれ独自の(場合によっては分散された)SVCS 900A、900B、900C、900Cr、D、Eに接続される、例示的な会議システムを示す。VSTBの機能は、供給装置のSVCSにより近いプロキシ850に押し込まれる。それぞれの受信アプリケーション200-1〜200-5は、それ独自の会議SVCS 901-1-1〜901-1-5に接続され、映像ソースに対する要求はソース管理装置901を介してCSP 850に送信され、CSP 850はソースをそれぞれの受信アプリケーションの会議に別々に供給する。

共同閲覧が開始されると、全ての招待されたユーザは各自の会議を切断し、招待ユーザの会議に参加し、招待ユーザの会議では、招待されたユーザは、招待ユーザが招待されたユーザとともに同期して見たいと思っている映像コンテンツを共有することができる。招待されたユーザが共同閲覧会議を切断し、各自の会議に再参加するとき、ユーザが招待ユーザの会議に参加する前に視聴していた映像ソースを見ることができるように、映像ソースの状態が保存されている。

同じまたは別の実施形態では、図4dに示されるように、映像サーバ100はリアルタイムレコーダおよびデジタル映像レコーダ(DVR)機能101を含むことができる。リアルタイムレコーダおよびDVR機能101により、例えば、共同閲覧セッション中に全ての会議出席者が、会議出席者のうちの1人によって開始することができるストリーミングされたソース映像コンテンツを一時停止するか、検索することが可能になる。ユーザは、映像サーバ100のリアルタイムレコーダ101を介して、任意の事前録画された映像コンテンツを一時停止するか、検索することができる。例えば、会議出席者のうちの1人が映像を一時停止した場合、その映像は「一時停止状態(pause-state)」で全ての共同閲覧会議出席者に示される。同様に、共同閲覧会議出席者のうちの1人が映像コンテンツを検索することができるが、全ての他の会議出席者もCPS 850によって制御された「検索状態(search-state)」に置かれる。

図4eは、分散されたSVCS(900A、900B)を使用しているCSP(850A-1、850A-2、850B-1、850B-2)を用いる2つの会議を含む、双方向同期型映像視聴のための別の例示的なシステムを示す。ソース映像側ならびに受信機側に実装されたCSPは、さらなるルーティング効率をもたらす。この例示的な実施形態は、映像ソース当たりのメッセージングの量を低減し、より良いリソース割当てを可能にする。図4a〜図4eはSVCSアーキテクチャを使用する双方向同期型映像視聴のためのいくつかの例示的なシステムを示しているが、(例えば、DVR機能、一時停止/検索機能を適用することによって)多くの変形形態が可能である。

図5は、例示的な映像サーバ100および受信アプリケーション(例えば、受信アプリケーション200a、200b、または200c)を示す。映像サーバ100は、映像(例えば、符号化された映像番組または映画)を格納する映像データベース101、受信アプリケーション200aから受信された情報(例えば、ユーザがメインスクリーンで表示されている映像をMBWで表示されている映像に切り替えたいと思っているということ)を処理するMBW制御論理103、および映像データベース101から適切な空間/時間ビットストリームを抽出して、ユーザのMBW選択に基づいて要求された映像をすぐに受信アプリケーション200aに送信する映像抽出装置105を含む。映像抽出装置105は階層型エンコーダ107から直接ビットストリームを抽出して、ライブ映像(すなわち、映像データベースに格納されていない映像コンテンツ)を示すこともできる。

ネットワーク300(例えば、公共インターネット、別のIPネットワーク、パケットネットワーク、プライベートIPネットワークと公共インターネットの組合せ、またはプライベートネットワーク)は、SVCS 900およびソース管理装置901を含む。ソース管理装置901は、ネットワークにおける映像ソースの適切なインデックス付けを可能にし、どのようにしてSVCSがどの映像ソースを最適にサービス提供するかを決定する論理を制御する。

受信アプリケーション200aはMBWユーザ制御論理203を含み、MBWユーザ制御論理203は(RTSP、HTTPなどのプロトコルを使用する)リンク302aを使用する公共インターネット300を介して映像サーバ100のMBW制御論理(すなわち、MBW制御論理103)および他の受信アプリケーションのMBW制御論理の両方と通信して、MBWへの会議出席者の割当てを処理する。MBWユーザ制御論理203は、ユーザ嗜好およびそれぞれのMBWに表示されるべき会議出席者の割当てを処理する。静的に、自動的に(システムによって)、または手動で(ユーザによって、例えば、アドレス帳からMBWにユーザをドラッグ＆ドロップする)、会議出席者をMBWに割り当てることができる。図5には示されていないが、本発明は、会議の設定を可能にするための、ディスプレイ管理装置205に含まれる会議アプリケーション論理に関連付けられたアドレス帳または出席ベースの友達リストアプリケーションがあることを想定する。また、ディスプレイ管理装置205はソース管理装置901とのダイアログを確立する。また、ディスプレイ管理装置205はユーザのディスプレイ設定およびMBW嗜好を処理して、ディスプレイパネルを構成する。

ユーザはGUI 207を使用して、例えば、それぞれのMBWのウィンドウサイズ(例えば、第1のMBW=QCIF、第2のMBW=QCIF、第3のMBW=CIF)を選択し、映像ディスプレイ400a上でのそれぞれのMBWの場所(例えば、スクリーンの上、下、横に並べる)を特定するために、ディスプレイ管理装置205でのアクションを呼び出すことができる。

受信アプリケーション200aは、階層型エンコーダ213およびユーザの映像をキャプチャするためのカメラ219を含み、音声および映像をSVCS 900に送信する。また、受信アプリケーション200aは、他のユーザの音声および映像ならびに映像サーバ100から来る映像コンテンツを復号するための階層型デコーダ211、および符号化されたビットストリームの適切なレイヤを抽出するための映像抽出装置205を含む。

映像サーバを「一方向」会議ユーザと考えることができるので、受信アプリケーション200aは機能的に映像サーバ100に類似している。しかし、これら2つの唯一の違いは、映像サーバ100に含むことができる映像データベース101ならびに、必要である場合、図5には示されていない、ネットワーク遅延等化を実行するために必要となる追加の補助機能である。

図6は、上述の双方向同期型映像視聴のためのシステムにおける例示的な映像ディスプレイを示す。例示的な一実施形態では、複数のユーザは、ユーザ間で会議を行いながら、同期してフットボールチャンネルを共同閲覧することができる。1人のユーザは、例えば、メインスクリーン(400-M)上でフットボールチャンネルを示し、他の7人のユーザ(A〜G)を映像ディスプレイの下および右側に並べられたオーバーレイMBW(A、B、C、D、E、F、G)で表示するように自分のディスプレイを構成することができる。

それぞれのユーザは、会議システムの場合と同様に他の人達を見聞きし、それと同時にフットボールの試合を見聞きすることができる。メインウィンドウ(400-M)における映像は、符号化された映像の基本レイヤおよび拡張レイヤからなる。MBW(A〜G)におけるユーザの会議映像は基本レイヤのみからなり、したがって、フル解像度映像に必要となる、ごく一部の帯域幅しか消費しない。メインスクリーン(400-M)に表示された映像コンテンツをMBWに表示された会議映像と切り替えることができる。しかし、メインスクリーンのコンテンツがMBWに切り替えられると、映像コンテンツの基本レイヤのみが送信され、このことにより、メインウィンドウに切り替えられたユーザの映像の拡張レイヤを送信するためのスペースがあく。スケーラブル映像を利用するシステム専用に設計されたビューレイアウト管理技法は、同時係属仮米国特許出願第61/060,072号に記載されている。

本明細書に記載される技法は、任意の汎用のデジタル映像配信システム、特にパケットネットワーク(例えば、IPTV)および公共インターネット(例えば、インターネットで利用可能な映像サービス)を使用するシステムに適用されるが、本開示はIPTVに重点を置いている。他のデジタル映像配信システムに対する本発明の適用は、軽微な修正および専門用語の変更によって達成されうる。

100 映像サーバ
100A、B、C、D+E+F 映像ソース
101 映像データベース、リアルタイムレコーダおよびデジタル映像レコーダ(DVR)機能
103 MBW制御論理
105 映像抽出装置
107 階層型エンコーダ
107A、107B、107C、107Cr、D、E 映像ソース供給装置
110、219 カメラ
181 デジタル映像(DV)ストリーマ
200a、200b、200c 受信アプリケーション
200-1、200-4 受信アプリケーション
203 MBWユーザ制御論理
205 ディスプレイ管理装置、映像抽出装置
207 GUI
211 階層型デコーダ
213 階層型エンコーダ
300 公共インターネット、ネットワーク
301a、301b、301c、302a、318、418、419、701、701a、701b、701c、703a、703b、703c、723 リンク
400a、400b、400c 映像ディスプレイ
400-M メインスクリーン、メインウィンドウ
620-1、620-4 仮想セットトップボックス(VSTB)
850、850A-1、850A-2、850B-1、850B-2 プロキシ、CSP
900 スケーラブル映像会議スイッチ(SVCS)、SVCS-VDN
900A、900B、900C、900Cr、D、E SVCS
901 ソース管理装置
910-1、910-2 SVCS-CVC

Claims

双方向同期型映像を受信するための方法であって、
(a)少なくとも第1のSVCSから少なくとも1つの映像コンテンツを受信するステップと、
(b)少なくとも第2のSVCSから少なくとも1つの会議コンテンツを受信するステップと、
(c)受信機で前記少なくとも1つの映像コンテンツおよび前記少なくとも1つの会議コンテンツを同期させるステップと
を備える方法。
前記第1のSVCSおよび前記第2のSVCSが同一である、請求項1に記載の方法。
前記少なくとも1つの映像コンテンツが、階層型符号化を使用して符号化された映像コンテンツを備える、請求項1に記載の方法。
前記少なくとも1つの映像コンテンツが、低遅延符号化を使用して符号化された映像コンテンツを備える、請求項1に記載の方法。
前記少なくとも1つの会議コンテンツが、階層型符号化を使用して符号化された会議コンテンツを備える、請求項1に記載の方法。
前記少なくとも1つの会議コンテンツが、低遅延符号化を使用して符号化された会議コンテンツを備える、請求項1に記載の方法。
前記少なくとも1つの映像コンテンツと前記少なくとも1つの会議コンテンツとの間で同期させる前記ステップが、プロトコルRTP、RTSP、HTTPのいずれかを介したMBW制御論理メッセージ、またはIETF/IPPM開発プロトコルのうちの少なくとも1つを備える、請求項1に記載の方法。
少なくとも1つの映像コンテンツを受信する前記ステップが、映像配信会議(VDC)で配信された映像コンテンツを受信するステップを備える、請求項1に記載の方法。
少なくとも1つの会議コンテンツを受信する前記ステップが、共同閲覧会議(CVC)で配信された会議コンテンツを受信するステップを備える、請求項1に記載の方法。
前記受信するステップが、第1のCVCに配信された第1の参加者による第1の会議コンテンツおよび第2のCVCに配信された第2の参加者による第2の会議コンテンツを受信するステップを備える、請求項1に記載の方法。
非標準シグナリングプロトコルを使用して、前記第1の参加者と前記第2の参加者との間の1つまたは複数の通信を送信するステップをさらに備える、請求項10に記載の方法。
前記会議コンテンツが、グローバルに一意の識別子によって特定される、請求項1に記載の方法。
前記グローバルに一意の識別子が、(RTPヘッダ内に配置された)SSRCフィールドにおいて伝達される、請求項12に記載の方法。
双方向同期型映像視聴のための映像を送信するためのシステムであって、
(a)少なくとも1つの映像サーバと、
(b)少なくとも1つの映像受信機と、
(c)少なくとも1つの映像コンテンツまたは会議コンテンツを前記少なくとも1つの映像受信機に配信するための少なくとも1つのSVCSと
を備えるシステム。
双方向同期型映像視聴のための映像を送信するための映像サーバであって、
(a)少なくとも1つの映像データベースと、
(b)前記少なくとも1つの映像データベースから少なくとも1つの映像コンテンツを抽出するための少なくとも1つの映像抽出装置と、
(c)少なくとも1つの映像受信機から受信された情報を処理するための少なくとも1つのMBW制御論理と
を備える映像サーバ。
少なくとも1つの階層型エンコーダをさらに含む、請求項15に記載の映像サーバ。
双方向同期型映像視聴のための映像を受信するための映像受信機であって、
(a)少なくとも1つの階層型デコーダと、
(b)少なくとも1つのMBWユーザ制御論理と
を備える映像受信機。
少なくとも1つの階層型エンコーダに接続された少なくとも1つのカメラをさらに備える、請求項17に記載の映像受信機。
少なくとも1つの映像コンテンツを少なくとも1つの会議コンテンツと同期させる、請求項17に記載の映像受信機。
映像コンテンツを配信するための方法であって、
(a)映像配信会議(VDC)を形成して、映像ソースからの映像コンテンツを少なくとも2人の参加者に配信するステップと、
(b)少なくとも1つの共同閲覧会議(CVC)を形成して、会議コンテンツを前記少なくとも2人の参加者のうちの少なくとも2人の間で配信するステップと、
(c)前記VDCを介して映像コンテンツを配信するステップとを備え、前記VDCおよび前記CVCのうちの少なくとも1つが組み合わされて、低遅延映像会議システムを使用する単一の会議を形成する、方法。
前記CVCを介して会議コンテンツを配信するステップをさらに備える、請求項20に記載の方法。
前記映像コンテンツおよび会議コンテンツが同期している、請求項20に記載の方法。
前記VDCまたはCVCの少なくとも1つの前記映像が、低遅延階層型符号化を使用して符号化される、請求項20に記載の方法。
前記VDCおよびCVCの少なくとも1つが、スケーラブル映像会議スイッチ(SVCS)を使用する、請求項20に記載の方法。
前記VDCおよびCVCが、異なるスケーラブル映像会議スイッチ(SVCS)を使用し、VDCおよびCDCを組み合わせるために使用される第3のSVCSをさらに備える、請求項20に記載の方法。
前記会議コンテンツのそれぞれが、前記CVCのいずれかにおいてグローバルに一意の識別子によってマークされる、請求項21に記載の方法。
前記グローバルに一意の識別子が、RTPヘッダ内に配置されたSSRCフィールドにおいて伝達される、請求項26に記載の方法。