JP2022517854A

JP2022517854A - メディアストリーム送信方法、装置、システム、およびデバイス

Info

Publication number: JP2022517854A
Application number: JP2021542510A
Authority: JP
Inventors: 乃▲強▼ ▲喬▼; ▲軍▼ 周; 明礼 ▲張▼; 毅 ▲開▼
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2019-04-23
Filing date: 2020-04-23
Publication date: 2022-03-10
Anticipated expiration: 2040-04-23
Also published as: US20210337001A1; WO2020216277A1; EP3890265A1; KR20210100176A; EP3890265B1; US11330028B2; CN111835697A; US20220174104A1; CN111835697B; JP7259056B2; US11848973B2; KR102457526B1; EP3890265A4

Abstract

メディアストリーム送信方法、装置、およびシステム、ならびにデバイスが開示される。本方法は、ライブブロードキャストルームに入室したクライアントにライブメディアストリームを提供する。本方法は、プロキシサーバが、同じプロキシクライアントによって送信された第1のライブブロードキャストルーム要求メッセージおよび第2のライブブロードキャストルーム要求メッセージを受信し、プロキシサーバが、プロキシサーバを介してメディアサーバによって第1のクライアントに送信された第1のライブメディアストリームと、プロキシサーバを介してメディアサーバによって第2のクライアントに送信された第2のライブメディアストリームとを受信し、第1のクライアントの役割はマスタユーザであり、第2のクライアントの役割はスレーブユーザであると判定した場合に、プロキシサーバが、プロキシクライアントが第1のライブメディアストリームを第1のクライアントおよび第2のクライアントに送信するようにするために、第1のライブメディアストリームのみをプロキシクライアントに送信することを含む。本方法によれば、同じライブブロードキャストルーム内のすべてのクライアントに関して、プロキシサーバは、1つのライブメディアストリームのみをプロキシクライアントに送信する必要があり、1つのライブメディアストリームを送信するための広域ネットワーク帯域幅が消費される。これは、WANネットワークリンク負荷を低減し、リソースオーバヘッドを低減する。

Description

本出願は、ビデオ再生の分野に関し、特に、メディアストリーム送信方法、装置、およびシステム、ならびにデバイスに関する。

ユーザは、ライブブロードキャストモードまたはビデオオンデマンドモードでビデオを視聴し得る。ビデオオンデマンドモードでは、ビデオを視聴するとき、ユーザは、いつでもビデオコンテンツを早送りまたは巻き戻しし得るが、ライブブロードキャストモードではビデオコンテンツを早送りまたは巻き戻しし得ない。ライブブロードキャストは、一般に、データのすべてのフレームが時系列タグでラベル付けされ、次にストリーミングされるプロセスとして理解され得る。具体的には、カメラまたはマイクロフォンなどの収集装置は、オーディオまたはビデオ情報を連続的に収集し、次にこれらの情報に対して符号化、カプセル化、およびストリームプッシュなどの処理を実行し、次に配信ネットワークを介してこれらの情報を送信する。再生端は、データを連続的にダウンロードし、再生のために時系列に基づいてデータを復号化する。ビデオライブブロードキャストの全体的な手順は、収集、符号化、ストリームプッシュ、トランスコード、配信、および復号化／レンダリングなどの一連のプロセスを含む。

インターネットビデオライブブロードキャストの主流ベンダは、通常、ビデオ送信のためにユニキャスト送信プロトコルを使用する。したがって、N人のユーザがビデオを視聴している場合、ビデオストリームのN個のチャネルが存在する。加えて、企業ライブビデオブロードキャストの場合、プレゼンテーションされた文書の共有およびテキストコメントの作成などの機能が、ビデオライブブロードキャスト中にサポートされる必要がある。すなわち、ユーザ要求を満たし、ユーザ体験を改善するために、共有文書およびテキストコメントが、ビデオコンテンツが企業ライブブロードキャストのWebページに表示されている間に表示される。

ユーザ体験を改善し、バックボーンネットワーク帯域幅を節約するために、ライブコンテンツ配信ネットワーク（Content Delivery Network、CDN）が、通常、ライブブロードキャストプラットフォーム上に配置される。ライブCDNは、分散型コンテンツ配信プラットフォームであり、マルチレイヤアーキテクチャをサポートする。ライブCDNプラットフォームでは、異なる地域のユーザに近くのサービスを提供するために、キャッシュ用のサーバが、異なるレイヤに配置され得る。

ライブCDNを介してオーディオおよびビデオストリームを配信するプロセスにおいて、リアルタイムメッセージトランスポートプロトコルとも呼ばれるリアルタイムメッセージプロトコル（Real Time Messaging Protocol、RTMP）が、通常、ビデオストリームプッシュおよびストリーム配信プロセスで使用され、配信プロセスにおいて、通常、RTMP、HLS（HTTP Live Streaming）プロトコル、およびハイパーテキスト転送プロトコル（Hyper Text Transfer Protocol、HTTP）－フラッシュビデオ（Flash Video、FLV）の3つのプロトコルが使用され、ハイパーテキスト転送プロトコル－フラッシュビデオは、略して「HTTP－FLV」と呼ばれる。HLSプロトコルは、アップル社によって開発されたHTTPベースのストリーミングメディア送信プロトコルである。HLSプロトコルは、主に、オーディオおよびビデオライブサービスおよび記録コンテンツ（VOD）サービスを提供するために、iPhone（登録商標）、iPad（登録商標）、iPod（登録商標） touch、およびMac OSXを含むiOSデバイスに適用される。HLSプロトコルは以下の利点を有し、HLSプロトコルによれば、クライアントは一度に完全なデータストリームを要求せず、代わりに、ストリーミングメディアデータは、サーバ端でより短い期間を有するより小さいファイルにセグメント化され、より小さいファイルは、インデックスファイルに基づいて順番にアクセスされる。クライアントがサーバから受信されたより小さいファイルを連続的かつ順番に再生するという条件で、オーディオおよびビデオは再生され得る。

図1に示されているように、ライブCDNにおいて、コンテンツソース（content source）は、RTMPを使用して企業データセンタ（Enterprise Data Center、EDC）にオーディオおよびビデオメディアストリームを送信し、EDCは、Webサーバ（Web server）および複数のメディアサーバ（Media server）を含む。EDC内のWebサーバは、ライブプログラムを視聴するための、クライアント（PC）からの要求に応答し、ユーザを認証し、ユーザの位置に基づいてユーザにサービスを提供するために最も近いメディアサーバを割り当てる。選択されたメディアサーバは、事前設定ポリシーに従って、オーディオおよびビデオメディアストリームを下位レベルの地域データセンタ（Region Data Center、RDC）に送信する。メディアストリーム（ライブコンテンツ）を受信した後、RDC内のメディアサーバは、事前設定ポリシーに従って、サーバルーム（Server Room、SR）内の下位レベルのメディアサーバにメディアストリームを配信する。最後に、サーバルーム内のメディアサーバは、上位のメディアサーバによって配信されたメディアストリーム（ライブコンテンツ）をキャッシュし、ユーザにライブブロードキャストサービスを直接提供する。

このプロセスにおいて、上位レベルのRDC内のメディアサーバは、ライブブロードキャストルーム内でメディアストリームを要求する各クライアントにライブメディアストリームを送信する必要があり、そのため、上位レベルのRDC内のメディアサーバは、ライブブロードキャストルーム内の各ユーザにライブメディアストリームを送信する必要がある。ライブブロードキャストルームに入室する大量のユーザが存在するとき、ライブメディアストリーム送信のために大量の広域ネットワーク（wide area network、WAN）リソースが必要とされ、その結果、重いネットワークオーバヘッドがもたらされる。

本出願の実施形態は、メディアサーバによって同じライブブロードキャストルーム内のクライアントにメディアストリームを送信するためのリソースオーバヘッドを低減するために、メディアストリーム送信方法、装置、およびシステム、ならびにデバイスを提供する。具体的には、本出願の実施形態は、以下の技術的解決策を開示する。

第1の態様によれば、本出願はメディアストリーム送信方法を提供し、本方法は、ライブブロードキャストルームに入室したクライアントにライブメディアストリームを提供する。本方法は、プロキシサーバが、同じプロキシクライアントによって送信された、ライブブロードキャストルームへの入室を要求するために使用される第1のライブブロードキャストルーム要求メッセージおよび第2のライブブロードキャストルーム要求メッセージを受信し、第1のライブブロードキャストルーム要求メッセージは第1のクライアントからのものであり、第2のライブブロードキャストルーム要求メッセージは第2のクライアントからのものであることを含む。プロキシサーバは、プロキシサーバを介してメディアサーバによって第1のクライアントに送信される第1のライブメディアストリームと、プロキシサーバを介してメディアサーバによって第2のクライアントに送信される第2のライブメディアストリームとを受信する。プロキシサーバは、第1のライブブロードキャストルーム要求メッセージに基づいて第1のクライアントの役割を判定し、第2のライブブロードキャストルーム要求メッセージに基づいて第2のクライアントの役割を判定する。第1のクライアントの役割はマスタユーザであり、第2のクライアントの役割はスレーブユーザであると判定した場合、プロキシサーバは、プロキシクライアントが第1のライブメディアストリームを第1のクライアントおよび第2のクライアントに送信するようにするために、第1のライブメディアストリームのみをプロキシクライアントに送信する。

この態様で提供される方法によれば、役割がスレーブユーザである第2のクライアントがライブメディアストリームの取得を要求したとき、プロキシクライアントは、役割がマスタユーザである第1のクライアントによって要求されたローカルにキャッシュされた第1のライブメディアストリームのみを第2のクライアントに直接送信する必要があり、そのため、プロキシサーバは、ライブメディアストリームをプロキシクライアントに再び送信する必要がなく、プロキシサーバは、プロキシクライアントを介してライブブロードキャストルームに入室した各クライアントにライブメディアストリームを送信する必要がない。この方法は、プロキシサーバとプロキシクライアントとの間のメディアストリーム送信のためのトラフィックを低減し、出口帯域幅を効果的に低減し、リソースオーバヘッドを低減する。

第1の態様に関連して、第1の態様の可能な実施態様では、第1のライブブロードキャストルーム要求メッセージはプロキシクライアントの識別子を含み、第2のライブブロードキャストルーム要求メッセージはプロキシクライアントの識別子を含む。本方法は、プロキシサーバが、第1のライブブロードキャストルーム要求メッセージに含まれるプロキシクライアントの識別子および第2のライブブロードキャストルーム要求メッセージに含まれるプロキシクライアントの識別子に基づいて、第1のライブブロードキャストルーム要求メッセージと第2のライブブロードキャストルーム要求メッセージとが同じプロキシクライアントからのものであると判定することをさらに含む。この態様では、プロキシクライアントの識別子は、第1のライブブロードキャストルーム要求メッセージまたは第2のライブブロードキャストルーム要求メッセージで搬送され、それにより、プロキシサーバは、メッセージおよび応答を転送するときに受信端を決定し得、その結果、メッセージの受信および送信が容易になる。

第1の態様に関連して、第1の態様の別の可能な実施態様では、プロキシサーバが、第2のライブブロードキャストルーム要求メッセージに基づいて第2のクライアントの役割を判定することは、プロキシサーバが、第2のライブブロードキャストルーム要求メッセージが受信されたときに、プロキシクライアントを介してライブブロードキャストルームに入室した、役割がライブブロードキャストルーム内のマスタユーザであるクライアントがライブブロードキャストルーム内に存在するかどうか判定し、プロキシクライアントを介してライブブロードキャストルームに入室した、役割がライブブロードキャストルーム内のマスタユーザであるクライアントがライブブロードキャストルーム内に存在する場合に、プロキシサーバが、第2のクライアントの役割はスレーブユーザであると判定することを含む。この実施態様では、単一のマスタユーザが存在する技術シナリオにおいて、プロキシサーバは、ライブブロードキャストルーム内にマスタユーザが存在するかどうかのみを判定する必要があり、それにより、プロキシサーバは、ライブブロードキャストルームに入室したクライアントのアイデンティティ役割を判定し得る。したがって、クライアントの役割は迅速に識別されマークされ得る。

それに対応して、役割がマスタユーザであるクライアントが存在しない場合、プロキシサーバは、第2のクライアントの役割はマスタユーザであると判定する。

第1の態様に関連して、第1の態様のさらに別の可能な実施態様では、プロキシサーバが第1のライブメディアストリームをプロキシクライアントに送信した後に、本方法は、プロキシサーバが、プロキシクライアントによって送信された、ライブブロードキャストルームからの退室に関する要求メッセージを受信し、ライブブロードキャストルームからの退室に関する要求メッセージは、第1のクライアントがライブブロードキャストルームから退室することを要求するために使用され、第2のクライアントを新しいマスタユーザとして決定したときに、プロキシサーバが、第2のクライアントの役割をスレーブユーザからマスタユーザに変更し、プロキシサーバが、第2のクライアントに送信される第1のライブメディアストリームを第2のライブメディアストリームに切り替えることをさらに含む。この実施態様では、役割がマスタユーザである第1のクライアントがライブブロードキャストルームから退室したとき、依然としてライブブロードキャストルーム内でメディアコンテンツを視聴している第2のクライアントが影響を受けないことを保証し、ライブブロードキャストルーム内の第2のクライアントのユーザのライブブロードキャストを視聴するユーザ体験を保証するために、役割が新しいマスタユーザである第2のクライアントのアイデンティティが、メディアサーバからのライブメディアストリームを要求して取得するために使用される。

第1の態様に関連して、第1の態様のさらに別の可能な実施態様では、プロキシサーバによって第2のクライアントに送信される第1のライブメディアストリームの最後のフレームと、プロキシサーバによって第2のクライアントに送信される第2のライブメディアストリームの最初のフレームとは隣接フレームである。プロキシサーバが、第2のクライアントに送信される第1のライブメディアストリームを第2のライブメディアストリームに切り替える前に、本方法は、プロキシサーバが、第1のライブメディアストリームおよび第2のライブメディアストリームに基づいて、第1のライブメディアストリームおよび第2のライブメディアストリームにそれぞれ属する第1のIフレームおよび第2のIフレームを識別し、第1のIフレームと第2のIフレームとが同じビデオフレームであることをさらに含む。

プロキシサーバは、第1のIフレームおよび第2のIフレームに基づいて、第1のライブメディアストリームおよび第2のライブメディアストリームにそれぞれ属する、互いに隣接する第1の切り替えフレームおよび第2の切り替えフレームを決定し、第1の切り替えフレームおよび第2の切り替えフレームを、それぞれ、第2のクライアントに送信される第1のライブメディアストリームの最後のフレームおよび第1のクライアントに送信される第2のライブメディアストリームの最初のフレームとして使用する。プロキシサーバが第1の切り替えフレームおよび第2の切り替えフレームを決定した後に、本方法は、プロキシサーバが、ライブブロードキャストルームからの退室に関する、第1のクライアントからの要求メッセージをメディアサーバに転送することをさらに含む。

第1の態様に関連して、第1の態様のさらに別の可能な実施態様では、プロキシサーバが、第2のライブブロードキャストルーム要求メッセージに基づいて第2のクライアントの役割を判定することは、プロキシサーバが第2のライブブロードキャストルーム要求メッセージを受信したときに、プロキシサーバが、プロキシクライアントを介してライブブロードキャストルームに入室した、役割がマスタユーザであるクライアントの数が事前設定上限に達しているかどうかを判定し、事前設定上限は2以上であることを含む。プロキシクライアントを介してライブブロードキャストルームに入室した、役割がマスタユーザであるクライアントの数が事前設定上限に達している場合、プロキシサーバは、第2のクライアントの役割はスレーブユーザであると判定する。この実施態様では、複数のマスタユーザが存在する技術シナリオ、すなわち、1つのメインマスタユーザおよび複数のセカンダリマスタユーザが存在するシナリオにおいて、クライアントの役割を判定するために、ライブブロードキャストルーム内のマスタユーザとして機能するクライアントの数が計算され、事前設定上限と比較される。クライアントの役割は、あるいは別の方法で判定されてもよいことが理解されよう。例えば、クライアントの役割は、ライブブロードキャストルーム要求の数に基づいて判定されてもよい。これはこの実施形態では限定されない。

第1の態様に関連して、第1の態様のさらに別の可能な実施態様では、役割がライブブロードキャストルーム内のマスタユーザであるクライアントの数が0ではなく、事前設定上限に達していない場合、プロキシサーバは、第2のクライアントの役割はセカンダリマスタユーザであると判定する。

第1の態様に関連して、第1の態様のさらに別の可能な実施態様では、第1のクライアントがメインマスタユーザであり、第2のクライアントがスレーブユーザである場合に、本方法は、プロキシサーバが第1のクライアントから、ライブブロードキャストルームからの退室に関する要求メッセージを受信し、第2のクライアントを新しいセカンダリマスタユーザとして決定したときに、プロキシサーバが、第2のクライアントの役割をスレーブユーザからセカンダリマスタユーザに変更し、プロキシサーバが、受信された第2のライブメディアストリームをグループオブピクチャGOPによりキャッシュすることをさらに含む。この実施態様では、第2のクライアントがセカンダリマスタユーザであるとき、プロキシサーバは、ユーザの役割がその後変更されたときにライブブロードキャストルーム内のクライアントにキャッシュされた第2のライブメディアストリームを提供するために、メディアサーバから第2のライブメディアストリームを受信し、第2のライブメディアストリームをローカルに記憶する。

第1の態様に関連して、第1の態様のさらに別の可能な実施態様では、第1のクライアントがメインマスタユーザであり、第2のクライアントがセカンダリマスタユーザである場合に、本方法は、プロキシサーバが、受信された第2のライブメディアストリームをGOPによりキャッシュし、プロキシサーバが、第1のライブメディアストリームおよびキャッシュされた第2のライブメディアストリームに基づいて、第1のライブメディアストリームおよび第2のライブメディアストリームにそれぞれ属する第1のIフレームおよび第2のIフレームを識別し、第1のIフレームと第2のIフレームとは同じビデオフレームであることをさらに含む。

第1の態様に関連して、第1の態様のさらに別の可能な実施態様では、本方法は、プロキシサーバが、第1のクライアントからライブブロードキャストルームからの退室に関する要求メッセージを受信し、第2のクライアントを新しいメインマスタユーザとして決定したときに、プロキシサーバが、第2のクライアントの役割をセカンダリマスタユーザからメインマスタユーザに変更し、プロキシサーバが、第1のIフレームおよび第2のIフレームに基づいて、第1のライブメディアストリームおよび第2のライブメディアストリームにそれぞれ属する、互いに隣接する第1の切り替えフレームおよび第2の切り替えフレームを決定し、プロキシサーバが、第1の切り替えフレームおよび第2の切り替えフレームに基づいて、第2のクライアントに送信される第1のライブメディアストリームを第2のライブメディアストリームに切り替え、プロキシサーバによって第2のクライアントに送信される第1のライブメディアストリームの最後のフレームが、第1の切り替えフレームであり、プロキシサーバによって第1のクライアントに送信される第2のライブメディアストリームの最初のフレームが、第2の切り替えフレームであることをさらに含む。この実施態様では、第2のクライアントの役割がセカンダリマスタユーザからメインマスタユーザに変更されると、ライブブロードキャストルーム内の他のクライアントが、影響を受けることなくライブブロードキャストコンテンツを正常に視聴することを保証するために、プロキシサーバは、メディアサーバから第2のライブメディアストリームを受信してキャッシュし、キャッシュされた第2のライブメディアストリームを複製し、複製されたキャッシュされた第2のライブメディアストリームをライブブロードキャストルーム内のすべてのクライアントに配信する。

第1の態様に関連して、第1の態様のさらに別の可能な実施態様では、プロキシサーバは、GOPによって第1のライブメディアストリームおよび第2のライブメディアストリームをキャッシュする。任意選択で、プロキシサーバは、第1のライブメディアストリームの3つのGOPおよび第2のライブメディアストリームの3つのGOPをローカルにキャッシュする。

第2の態様によれば、本出願の一実施形態は、メディアストリーム送信方法をさらに提供する。本方法は、ライブブロードキャストルームに入室したクライアントにライブメディアストリームを提供する。本方法は、プロキシクライアントが、第1のクライアントによって送信された、ライブブロードキャストルームへの入室を要求するために使用される第1のライブブロードキャストルーム要求メッセージと、第2のクライアントによって送信された、ライブブロードキャストルームへの入室を要求するために使用される第2のライブブロードキャストルーム要求メッセージとを受信し、プロキシクライアントが、プロキシサーバを介して第1のライブブロードキャストルーム要求メッセージおよび第2のライブブロードキャストルーム要求メッセージをメディアサーバに送信し、プロキシクライアントが、プロキシサーバによって送信された第1のライブメディアストリームを受信し、第1のライブメディアストリームが、プロキシサーバを介してメディアサーバによって第1のクライアントに送信されたメディアストリームであり、第1のクライアントの役割がマスタユーザであり、第2のクライアントの役割がスレーブユーザであり、プロキシクライアントが、第1のライブメディアストリームを第1のクライアントおよび第2のクライアントに送信することを含む。

この態様で提供される方法によれば、同じプロキシクライアントを介してライブブロードキャストルームにアクセスするすべてのユーザに関して、プロキシサーバは、1つのライブメディアストリームのみをプロキシクライアントに送信する必要があり、すなわち、プロキシクライアントは、プロキシサーバによって送信された1つのライブメディアストリームを受信するために広域ネットワーク帯域幅を消費する。メディアサーバがライブブロードキャストルーム内の各クライアントにライブメディアストリームを送信するときに占有される送信リソースと比較して、これは、WANネットワークリンク負荷を低減し、送信オーバヘッドを低減する。

第2の態様に関連して、第2の態様の可能な実施態様では、プロキシクライアントが、プロキシサーバを介して第1のライブブロードキャストルーム要求メッセージをメディアサーバに送信する前に、本方法は、プロキシクライアントが、プロキシクライアントの識別子を第1のライブブロードキャストルーム要求メッセージに追加することを含み、プロキシクライアントが、プロキシサーバを介して第2のライブブロードキャストルーム要求メッセージをメディアサーバに送信する前に、本方法は、プロキシクライアントが、プロキシクライアントの識別子を第2のライブブロードキャストルーム要求メッセージに追加することをさらに含む。

第2の態様に関連して、第2の態様の別の可能な実施態様では、プロキシクライアントが、プロキシサーバによって送信された第1のライブメディアストリームを受信した後に、本方法は、プロキシクライアントが第1のライブメディアストリームをグループオブピクチャGOPによりキャッシュすることをさらに含む。

第2の態様に関連して、第2の態様のさらに別の可能な実施態様では、プロキシクライアントが、第1のライブメディアストリームを第2のクライアントに送信することの前に、本方法は、調整されたタイムスタンプが、プロキシクライアントによって第2のクライアントに送信される第1のライブメディアストリームの最初のフレームのタイムスタンプが0であり、第2のクライアントに送信される第1のライブメディアストリームの隣接フレームのタイムスタンプが連続することを満たすように、プロキシクライアントが、第1のライブメディアストリームのタイムスタンプを調整することをさらに含む。

第2の態様に関連して、第2の態様のさらに別の可能な実施態様では、第1のクライアントがライブブロードキャストルームからの退室を要求するときに、本方法は、プロキシクライアントが、プロキシサーバによって送信された第2のライブメディアストリームを受信し、第2のライブメディアストリームが、プロキシクライアントを介してメディアサーバによって第2のクライアントに送信されたメディアストリームであり、第2のクライアントが、役割がスレーブユーザからマスタユーザに変更されたクライアントであり、プロキシクライアントが、第2のライブメディアストリームを第2のクライアントに送信することをさらに含む。

第2の態様に関連して、第2の態様のさらに別の可能な実施態様では、プロキシクライアントが、第2のライブメディアストリームを第2のクライアントに送信することの前に、本方法は、調整されたタイムスタンプが、プロキシクライアントによって第2のクライアントに送信される第2のライブメディアストリームの最初のフレームとプロキシクライアントによって第2のクライアントに送信される第1のライブメディアストリームの最後のフレームとのタイムスタンプが連続することを満たすように、プロキシクライアントが、第2のライブメディアストリームのタイムスタンプを調整することをさらに含む。

第3の態様によれば、本出願の一実施形態は、メディアストリーム送信装置を提供する。本装置は、第1の態様または第1の態様の実施態様のいずれか1つによる方法のステップを実行するように構成されたユニットを含む。具体的には、本装置は、受信ユニット、処理ユニット、および送信ユニットを含む。加えて、本装置は、別のモジュールまたはユニット、例えば記憶ユニットをさらに含んでもよい。

任意選択で、本装置はプロキシサーバである。

第4の態様によれば、本出願の一実施形態は、メディアストリーム送信装置を提供する。本装置は、第2の態様または第2の態様の実施態様のいずれか1つによる方法のステップを実行するように構成されたユニットを含む。具体的には、本装置は、受信ユニット、処理ユニット、および送信ユニットを含む。加えて、本装置は、別のモジュールまたはユニット、例えば記憶ユニットをさらに含んでもよい。

任意選択で、本装置はプロキシクライアントである。

第5の態様によれば、本出願の一実施形態は、トランシーバ、プロセッサ、およびメモリを含むネットワークデバイスをさらに提供する。プロセッサはメモリに結合され、メモリは、命令を記憶するように構成される。プロセッサは、ネットワークデバイスが第1の態様または第1の態様の実施態様のいずれか1つによるメディアストリーム送信方法を実行することを可能にするために命令を呼び出すか、またはネットワークデバイスが第2の態様または第2の態様の実施態様のいずれか1つによるメディアストリーム送信方法を実行することを可能にするために命令を呼び出すように構成される。

任意選択で、ネットワークデバイスは、プロキシサーバまたはプロキシクライアントである。

さらに、この態様の可能な実施態様では、ネットワークデバイスがプロキシサーバである場合、トランシーバは、同じプロキシクライアントによって送信された、ライブブロードキャストルームへの入室を要求するために使用される第1のライブブロードキャストルーム要求メッセージおよび第2のライブブロードキャストルーム要求メッセージを受信し、プロキシサーバを介してメディアサーバによって第1のクライアントに送信された第1のライブメディアストリームと、プロキシサーバを介してメディアサーバによって第2のクライアントに送信された第2のライブメディアストリームとを受信し、第1のライブブロードキャストルーム要求メッセージは第1のクライアントからのものであり、第2のライブブロードキャストルーム要求メッセージは第2のクライアントからのものである、ように構成される。プロセッサは、第1のライブブロードキャストルーム要求メッセージに基づいて第1のクライアントの役割を判定し、第2のライブブロードキャストルーム要求メッセージに基づいて第2のクライアントの役割を判定するように構成される。トランシーバは、第1のクライアントの役割はマスタユーザであり、第2のクライアントの役割はスレーブユーザであると判定された場合に、プロキシクライアントが第1のライブメディアストリームを第1のクライアントおよび第2のクライアントに送信するようにするために、第1のライブメディアストリームのみをプロキシクライアントに送信するようにさらに構成される。

任意選択で、この態様の別の可能な実施態様では、ネットワークデバイスがプロキシクライアントである場合、トランシーバは、第1のクライアントによって送信された、ライブブロードキャストルームへの入室を要求するために使用される第1のライブブロードキャストルーム要求メッセージと、第2のクライアントによって送信された、ライブブロードキャストルームへの入室を要求するために使用される第2のライブブロードキャストルーム要求メッセージとを受信し、プロキシサーバを介して第1のライブブロードキャストルーム要求メッセージおよび第2のライブブロードキャストルーム要求メッセージをメディアサーバに送信するように構成される。トランシーバは、プロキシサーバによって送信された第1のライブメディアストリームを受信し、第1のライブメディアストリームを第1のクライアントおよび第2のクライアントに送信するようにさらに構成される。第1のライブメディアストリームは、プロキシサーバを介してメディアサーバによって第1のクライアントに送信されるメディアストリームであり、第1のクライアントの役割はマスタユーザであり、第2のクライアントの役割はスレーブユーザである。

第6の態様によれば、本出願の一実施形態は、コンピュータ可読記憶媒体をさらに提供する。記憶媒体は命令を記憶する。命令がコンピュータまたはプロセッサ上で実行されるとき、第1の態様もしくは第1の態様の実施態様のいずれか1つによる方法または第2の態様もしくは第2の態様の実施態様のいずれか1つによる方法が実行される。

第7の態様によれば、本出願の一実施形態は、コンピュータプログラム製品をさらに提供する。コンピュータプログラム製品は、コンピュータ命令を含む。命令がコンピュータまたはプロセッサによって実行されるとき、第1の態様もしくは第1の態様の実施態様のいずれか1つによる方法または第2の態様もしくは第2の態様の実施態様のいずれか1つによる方法が実施され得る。

第8の態様によれば、本出願の一実施形態は、メディアストリーム送信システムをさらに提供する。本システムは、少なくとも1つのクライアントと、プロキシクライアントと、プロキシサーバと、メディアサーバとを含む。各クライアントは、プロキシクライアントを介してライブブロードキャストルームにアクセスする。本システムは、プロキシクライアントおよびプロキシサーバを介して、第1の態様、第2の態様、第1の態様の実施態様、または第2の態様の実施態様のいずれか1つによるメディアストリーム送信方法を実施する。プロキシクライアントは、第2の態様または第2の態様の実施態様のいずれか1つによる方法に従ってメディアストリーム送信方法を実行するように構成され、プロキシサーバは、第1の態様または第1の態様の実施態様のいずれか1つによる方法に従ってメディアストリーム送信方法を実行するように構成される。

任意選択で、プロキシサーバは、第3の態様または第3の態様の実施態様のいずれか1つによるメディアストリーム送信装置であり、プロキシクライアントは、第4の態様または第4の態様の実施態様のいずれか1つによるメディアストリーム送信装置である。

第8の態様に関連して、第8の態様の可能な実施態様では、プロキシサーバおよびメディアサーバは、地域データセンタRDCに配置される。RDCはWebサーバをさらに含み、Webサーバは、プロキシクライアントを介してライブブロードキャストルームに入室したクライアントにメディアサーバを割り当てるように構成される。

第8の態様に関連して、第8の態様の別の可能な実施態様では、本システムは、企業データセンタEDCおよびコンテンツソースをさらに含む。

任意選択で、メディアストリーム送信システムはコンテンツ配信ネットワークCDNシステムである。

加えて、本出願の一実施形態はチップシステムをさらに提供する。チップシステムは、プロセッサおよびインターフェース回路を含む。インターフェース回路はプロセッサに結合される。プロセッサは、第1の態様または第1の態様の実施態様のいずれか1つによる方法を実施するか、または第2の態様または第2の態様の実施態様のいずれか1つによる方法を実施するために、コンピュータプログラムまたは命令を実行するように構成される。インターフェース回路は、チップシステムの外部の別のモジュールと通信するように構成される。

本出願で提供される方法によれば、プロキシクライアントおよびプロキシサーバが、マスタユーザとして機能するクライアントによって要求されたライブメディアストリームを取得すると、メディアストリームの一部のセグメントがプロキシクライアントにおいてローカルにキャッシュされる。他のクライアントがライブブロードキャストルームに入室し、ライブメディアストリームを要求すると、プロキシクライアントは、ローカルにキャッシュされたメディアストリームをこれらのクライアントに直接送信し、そのため、プロキシサーバは、ライブメディアストリームをプロキシクライアントに再び送信する必要がない。この方法では、マスタユーザとして機能するクライアントによって要求されたライブメディアストリームのみがプロキシサーバとプロキシクライアントとの間で送信される、言い換えれば、ライブメディアストリームのみを送信するための広域ネットワーク帯域幅が消費される。メディアサーバがプロキシサーバを介して各クライアントにライブメディアストリームを送信するときに占有される送信リソースと比較して、これは、メディアストリームを送信するためのトラフィックを低減し、WANネットワークリンク負荷を低減し、リソースオーバヘッドを低減する。

加えて、プロキシクライアントがライブブロードキャストルーム内のすべてのクライアントにライブメディアストリームを送信するとき、プロキシクライアントはまた、ライブメディアストリームのタイムスタンプを調整する。例えば、マスタユーザとして機能する第1のクライアントがライブブロードキャストルームから退室するとき、プロキシクライアントは、当初から第2のクライアントに送信されている第1のライブメディアストリームを第2のライブメディアストリームに切り替え、プロキシクライアントが第2のライブメディアストリームを第2のクライアントに送信するときに、第2のライブメディアストリームが、当初から再生されている第1のライブメディアストリームのメディアコンテンツにシームレスに接続され得るように、第2のライブメディアストリームのタイムスタンプを調整する。これは、第1のクライアントの退室によって生じる、第2のクライアントで視聴されているメディアコンテンツへのビデオフリーズまたは他の影響を回避する。したがって、この方法によれば、プロキシクライアントによってタイムスタンプを調整することは、視聴のユーザ体験も保証する。

本出願によるライブブロードキャストシステムのアーキテクチャの概略図である。本出願の一実施形態による、ビデオライブブロードキャストのためのバイラテラルプロキシシステムのアーキテクチャの概略図である。本出願の一実施形態によるメディアストリーム送信方法のフローチャートである。本出願の一実施形態による別のメディアストリーム送信方法のフローチャートである。本出願の一実施形態によるメディアストリーム送信方法のシグナリングフローチャートである。本出願の一実施形態によるメディアストリーム送信方法のシグナリングフローチャートである。本出願の一実施形態によるメディアストリーム送信方法のシグナリングフローチャートである。本出願の一実施形態によるメディアストリーム送信方法のシグナリングフローチャートである。本出願の一実施形態による別のメディアストリーム送信方法のシグナリングフローチャートである。本出願の一実施形態による別のメディアストリーム送信方法のシグナリングフローチャートである。本出願の一実施形態によるさらに別のメディアストリーム送信方法のシグナリングフローチャートである。本出願の一実施形態によるさらに別のメディアストリーム送信方法のシグナリングフローチャートである。本出願の一実施形態によるさらに別のメディアストリーム送信方法のシグナリングフローチャートである。本出願の一実施形態によるさらに別のメディアストリーム送信方法のシグナリングフローチャートである。本出願の一実施形態によるさらに別のメディアストリーム送信方法のシグナリングフローチャートである。本出願の一実施形態によるさらに別のメディアストリーム送信方法のシグナリングフローチャートである。本出願の一実施形態によるメディアストリーム送信装置の概略構造図である。本出願の一実施形態によるネットワークデバイスの概略構造図である。

当業者に本出願の実施形態における技術的解決策をより良く理解させ、本出願の実施形態の目的、特徴、および利点をより明確にするために、以下では、添付の図面を参照して詳細に本出願の実施形態における技術的解決策をさらに説明する。

本出願の実施形態における技術的解決策が説明される前に、添付の図面を参照して、本出願の実施形態の適用シナリオが最初に説明される。

本出願の技術的解決策は、コンテンツ配信ネットワーク（content delivery network、CDN）システムに適用され得、システム内の新たに追加されるデバイスは、プロキシサーバ（proxy server）およびプロキシクライアント（proxy client）を含む。

プロキシサーバは、ユーザのビデオベアラプロトコルのプロキシとして機能し、プロキシサーバを介してライブブロードキャストルームに入室したすべてのクライアントの役割を識別し、メディアサーバから少なくとも1つのライブメディアストリームを取得し、マスタユーザとして機能するクライアントのライブメディアストリームをプロキシクライアントに送信するように構成される。加えて、役割がマスタユーザであるクライアントがライブブロードキャストルームから退室するとき、プロキシサーバは、ライブブロードキャストルーム内の他のユーザの役割を更新し、ライブメディアストリームを新しいライブメディアストリームに切り替えるようにさらに構成される。プロキシクライアントは、ユーザのビデオベアラプロトコルのプロキシとして機能し、プロキシサーバによって送信された、役割がマスタユーザであるクライアントのライブメディアストリームを受信し、ライブメディアストリームを複製し、プロキシクライアントを介してライブブロードキャストルームにアクセスする、ライブブロードキャストルーム内のすべてのクライアントに複製されたライブメディアストリームを配信するように構成される。

任意選択で、プロキシサーバは、地域データセンタ（Region Data Center、RDC）に配置されてもよい。具体的には、プロキシサーバは、サーバ上に配置されてもよいし、またはネットワーク機能仮想化（Network Functions Virtualization、NFV）によって汎用顧客構内機器（Universal Customer Premise Equipment、uCPE）上に配置されてもよい。

任意選択で、プロキシクライアントは、ローカルエリアネットワークのエッジに位置するデバイスであってもよく、ローカルエリアネットワーク内のクライアントは、プロキシクライアントを介してライブブロードキャストルームに入室し、プロキシクライアントを介してライブメディアストリームを取得する。プロキシクライアントは、サーバ上に配置されてもよいし、またはNFVによってuCPE上に配置されてもよい。

さらに、図2に示されているように、一実施形態はビデオCDNシステムを提供する。本システムは、コンテンツソース（content source）101と、企業データセンタ（enterprise data center、EDC）102と、RDC103と、プロキシクライアント104と、少なくとも1つのクライアント（client、C）、例えば第1のクライアントC1 105、第2のクライアントC2 106、および第3のクライアントC3 107とを含む。EDC102は、複数のメディアサーバ（media server）およびWebサーバ（Web server）を含む。RDC103は、プロキシサーバ、複数のメディアサーバ、またはWebサーバなどを含む。プロキシサーバとプロキシクライアントとは、WANネットワークを介して互いに接続され、プロキシクライアントと、プロキシクライアントに関連付けられた少なくとも1つのクライアントとは、ローカルエリアネットワーク（local area network、LAN）を介して接続される。

加えて、ライブブロードキャストCDNは、分散型コンテンツ配信プラットフォームであり、マルチレベルアーキテクチャをサポートする。ライブブロードキャストCDNプラットフォームでは、異なる地域のユーザに近くのサービスを提供するために、複数のメディアサーバが異なるレイヤに配置され得る。EDC内のユーザがライブブロードキャストルーム内でライブブロードキャストを視聴するとき、割り当てられたメディアサーバがRDCに配置されてもよく、送信されたライブメディアストリームは、マルチプロトコルラベルスイッチング（Multi－Protocol Label Switching、MPLS）専用回線を介してRDCおよびプロキシクライアントに到達する。

さらに、前述のデバイスまたはネットワーク要素の機能の一般的な説明は、以下の表1に記載されている。

加えて、本出願のこの実施形態で説明されるシステムでは、プロキシサーバは1つ以上のプロキシクライアントに対応し得ることに留意されたい。例えば、プロキシサーバは、プロキシクライアント1およびプロキシクライアント2に対応する。ローカルエリアネットワーク1内のクライアントは、プロキシクライアント1およびプロキシサーバを介してライブブロードキャストルームに入室する。ローカルエリアネットワーク2内のクライアントは、プロキシクライアント2およびプロキシサーバを介してライブブロードキャストルームに入室する。加えて、プロキシサーバは、以下の実施態様Aまたは実施態様Bにおいて、プロキシサーバを介してライブブロードキャストルームに入室した各クライアントの役割を判定し得る。

実施態様A：同じプロキシクライアントを介してライブブロードキャストルームに入室したすべてのクライアントの役割が集中的に判定される。例えば、プロキシサーバは、プロキシクライアント1およびプロキシクライアント2に対応する。プロキシサーバは、プロキシクライアント1を介してライブブロードキャストルームに入室したクライアントの中から少なくとも1つのマスタユーザを決定し、他のクライアントをスレーブユーザとして決定し、プロキシクライアント2を介してライブブロードキャストルームに入室したクライアントの中から少なくとも1つのマスタユーザを決定し、他のクライアントをスレーブユーザとして決定する。実施態様Aでクライアントの役割を判定すると、それに対応して、プロキシサーバは、役割がマスタユーザであるクライアントのライブメディアストリームをプロキシクライアントに送信し、次に、プロキシクライアントは、プロキシクライアントを介してライブブロードキャストルームに入室したすべてのクライアントにライブメディアストリームを送信する。実施態様Aがクライアントの役割を判定するために使用される場合、各プロキシクライアントを介してライブブロードキャストルームに入室したクライアントは、役割がマスタユーザであるクライアントを含むことが理解されよう。プロキシサーバによっていずれかのプロキシクライアントに送信されるメディアストリームは、ライブブロードキャストルームに入室した、役割がマスタユーザであるクライアントのメディアストリームである。

実施態様B：プロキシサーバを介してライブブロードキャストルームに入室したすべてのクライアントの役割が集中的に判定される。例えば、プロキシサーバは、プロキシクライアント1およびプロキシクライアント2に対応し、少なくとも1つのマスタユーザが、プロキシクライアント1およびプロキシクライアント2を介してライブブロードキャストルームに入室したすべてのクライアントの中から決定され、他のクライアントはスレーブユーザとして決定される。実施態様Bでクライアントの役割を判定すると、それに対応して、プロキシサーバは、役割がマスタユーザであるクライアントのライブメディアストリームを、システム内のプロキシサーバに対応する各プロキシクライアントに送信し、次に、各プロキシクライアントは、それぞれのプロキシクライアントを介してライブブロードキャストルームに入室したすべてのクライアントにライブメディアストリームを送信する。

説明を簡単にするために、実施形態では、役割がマスタユーザであるクライアントは、簡単に、マスタユーザとして機能するクライアントと呼ばれる場合がある。同様に、役割がスレーブユーザであるクライアントは、簡単に、スレーブユーザとして機能するクライアントと呼ばれる場合がある。

具体的には、図3は、一実施形態で提供されるメディアストリーム送信方法を示している。本方法は、同じプロキシクライアントを介してライブブロードキャストルームに入室したすべてのクライアントにライブメディアストリームを提供する。具体的には、本方法は以下のステップを含む。

ステップ101：プロキシサーバは、同じプロキシクライアントによって送信された、ライブブロードキャストルームへの入室を要求するために使用される第1のライブブロードキャストルーム要求メッセージおよび第2のライブブロードキャストルーム要求メッセージを受信し、第1のライブブロードキャストルーム要求メッセージは第1のクライアントからのものであり、第2のライブブロードキャストルーム要求メッセージは第2のクライアントからのものである。

第1のライブブロードキャストルーム要求メッセージは、プロキシクライアントの識別子を含み、第2のライブブロードキャストルーム要求メッセージは、プロキシクライアントの識別子を含み、識別子は、プロキシクライアントのIPアドレスまたはポート番号などであり得る。プロキシサーバは、第1のライブブロードキャストルーム要求メッセージに含まれるプロキシクライアントの識別子に基づいて、第1のライブブロードキャストルーム要求メッセージを転送したプロキシクライアントを判定し、第2のライブブロードキャストルーム要求メッセージに含まれるプロキシクライアントの識別子に基づいて、第2のライブブロードキャストルーム要求メッセージを転送したプロキシクライアントを判定し、さらに、第1のライブブロードキャストルーム要求メッセージと第2のライブブロードキャストルーム要求メッセージとが同じプロキシクライアントからのものであると判定し得る。

ステップ102：プロキシサーバは、プロキシサーバを介してメディアサーバによって第1のクライアントに送信された第1のライブメディアストリームと、プロキシサーバを介してメディアサーバによって第2のクライアントに送信された第2のライブメディアストリームとを受信する。

具体的には、第1のクライアントによって送信された第1のメディア要求メッセージを受信した後、プロキシサーバは、第1のメディア要求メッセージをメディアサーバに転送し、第1のメディア要求メッセージに基づいてメディアサーバによって送信された第1のライブメディアストリームを受信する。第2のクライアントによって送信された第2のメディア要求メッセージを受信した後、プロキシサーバは、第2のメディア要求メッセージをメディアサーバに転送し、第2のメディア要求メッセージに基づいてメディアサーバによって送信された第2のライブメディアストリームを受信する。

ステップ103：プロキシサーバは、第1のライブブロードキャストルーム要求メッセージに基づいて第1のクライアントの役割を判定し、第2のライブブロードキャストルーム要求メッセージに基づいて第2のクライアントの役割を判定する。

具体的には、ステップ103は、前述の「実施態様A」において実施され得る。

さらに、可能な実施態様では、単一のマスタユーザが存在する技術シナリオでは、プロキシサーバがライブブロードキャストルーム要求メッセージ（例えば、第2のライブブロードキャストルーム要求メッセージ）を受信するたびに、プロキシサーバは、プロキシクライアントを介してライブブロードキャストルームに入室したクライアントの中で役割がマスタユーザであるクライアントがライブブロードキャストルーム内に存在するかどうかを判定する。プロキシクライアントを介してライブブロードキャストルームに入室したクライアントの中で役割がマスタユーザであるクライアントがライブブロードキャストルーム内に存在する場合、プロキシサーバは、ライブブロードキャストルーム要求メッセージを送信したクライアント（例えば、第2のクライアント）の役割はスレーブユーザ（slave user）であると判定する。プロキシクライアントを介してライブブロードキャストルームに入室したクライアントの中で役割がマスタユーザであるクライアントがライブブロードキャストルーム内に存在しない場合、プロキシサーバは、クライアントの役割はマスタユーザ（master user）であると判定する。

別の可能な実施態様では、複数のマスタユーザが存在する、例えば、1つのメインマスタユーザおよび少なくとも1つのセカンダリマスタユーザが存在する技術シナリオでは、ステップ103は、プロキシサーバがライブブロードキャストルーム要求メッセージ（例えば、第2のライブブロードキャストルーム要求メッセージ）を受信するたびに、プロキシサーバが、現在のライブブロードキャストルームにおいてプロキシクライアントを介してライブブロードキャストルームに入室した、役割がマスタユーザであるクライアントの数が事前設定上限に達しているかどうかを判定することを特に含み、事前設定上限は2以上である。数が事前設定上限に達している場合、プロキシサーバは、ライブブロードキャストルーム要求メッセージを送信したクライアント（例えば、第2のクライアント）の役割はスレーブユーザであると判定する。数が事前設定上限に達しておらず、数が0でない場合、プロキシサーバは、クライアントの役割はセカンダリマスタユーザ（secondary－master user）であると判定する。数が0である場合、プロキシサーバは、クライアントの役割はメインマスタユーザ（main－master user）であると判定する。

具体的には、ステップ103は、「実施態様B」において実施され得、特定の実施態様は、「実施態様A」の前述の特定の実施態様と同様である。単一のマスタユーザが存在する技術シナリオでは、「実施態様A」と比較して、プロキシサーバを介してライブブロードキャストルームに入室した、役割がマスタユーザである、ライブブロードキャストルーム内のクライアントがマスタユーザであるかどうかが判定される点にのみ違いがある。複数のマスタユーザが存在する技術シナリオでは、「実施態様A」と比較して、ライブブロードキャストルームにおいてプロキシサーバを介してライブブロードキャストルームに入室した、役割がマスタユーザであるクライアントの数が事前設定上限に達しているかどうかが判定される点にのみ違いがある。

加えて、本方法は、プロキシサーバがグループオブピクチャ（group of picture、GOP）によって第1のライブメディアストリームをキャッシュすることをさらに含む。GOPは、2つのIフレーム間のピクチャシーケンスを指し得る。Iフレーム（frame）は、イントラピクチャ（intra picture）とも呼ばれ、一般に、動画専門家集団（moving picture experts group、MPEG）技術処理によって取得される各GOPの最初のフレームを指す。さらに、MPEG技術処理は、ビデオピクチャを適切に圧縮することを含み、そのため、Iフレームは、他のピクチャを参照することなくランダムアクセスの参照として使用され得る。

任意選択で、プロキシサーバは3つのGOPをローカルにキャッシュし、各GOPの期間は5sである。

ステップ104：第1のクライアントの役割はマスタユーザであり、第2のクライアントの役割はスレーブユーザであると判定した場合、プロキシサーバは、プロキシクライアントが第1のライブメディアストリームを第1のクライアントおよび第2のクライアントに送信するようにするために、第1のライブメディアストリームのみをプロキシクライアントに送信する。

具体的には、最初に、プロキシサーバは、ステップ101で第1のライブブロードキャストルーム要求メッセージを受信し、ステップ102で第1のライブメディアストリームを受信し、ステップ103で第1のクライアントの役割をマスタユーザとして判定する。第1のクライアントの役割はマスタユーザであるため、プロキシサーバは、ステップ104で第1のクライアントのライブメディアストリーム（すなわち、第1のライブメディアストリーム）をプロキシクライアントに送信する。それに対応して、プロキシクライアントは、第1のライブメディアストリームを第1のクライアントに送信する。次に、プロキシサーバは、ステップ101で第2のライブブロードキャストルーム要求メッセージを受信し、ステップ102で第2のライブメディアストリームを受信し、ステップ103で第2のクライアントの役割をスレーブユーザとして判定する。第2のクライアントの役割はスレーブユーザであり、第2のクライアントおよび第1のクライアントは同じプロキシクライアントに対応するため、プロキシサーバは、第2のクライアントのメディアストリーム（すなわち、第2のライブメディアストリーム）をプロキシクライアントに送信しない。それに対応して、プロキシサーバによって送信された第1のライブメディアストリームを受信した後、プロキシクライアントは、第1のライブメディアストリームを第1のクライアントに送信するだけでなく、第1のライブメディアストリームを複製し、複製された第1のライブメディアストリームを第2のクライアントに送信する。ライブブロードキャストルーム内により多くのクライアントが存在する場合、プロキシクライアントは、第1のライブメディアストリームの複数のコピーを作成し、プロキシクライアントを介してライブブロードキャストルームに入室したすべてのクライアントに第1のライブメディアストリームのコピーを送信することが理解されよう。

複数のマスタユーザが存在する技術シナリオでは、第1のクライアントの役割は特にメインマスタユーザであってもよく、第2のクライアントはスレーブユーザまたはセカンダリマスタユーザであってもよいことに留意されたい。第1のクライアントはメインマスタユーザであると判定すると、第2のクライアントの役割がスレーブユーザであるか、それともセカンダリマスタユーザであるかにかかわらず、プロキシサーバは、第1のクライアントが取得を要求する第1のライブメディアストリームのみをプロキシクライアントに送信する。

加えて、プロキシサーバが複数のクライアントに対応し、クライアントの役割が前述の「実施態様B」で判定される場合、プロキシサーバは、それに対応して、第1のライブメディアストリームを別のプロキシクライアントにさらに送信し、別のプロキシクライアントは、受信された第1のライブメディアストリームを複製し、受信された第1のライブメディアストリームのコピーを対応するクライアントに配信する。

この実施形態では、クライアントの役割を判定するために「実施態様A」が使用される例が以下の説明のために使用される。

この実施形態で提供される方法によれば、役割がスレーブユーザである第2のクライアントがライブメディアストリームの取得を要求したとき、プロキシクライアントは、役割がマスタユーザである第1のクライアントによって要求されたローカルにキャッシュされた第1のライブメディアストリームのみを第2のクライアントに送信する必要があり、そのため、プロキシサーバは、ライブメディアストリームをプロキシクライアントに再び送信する必要がなく、プロキシサーバは、プロキシクライアントを介してライブブロードキャストルームに入室した各クライアントにライブメディアストリームを送信する必要がない。この方法は、プロキシサーバとプロキシクライアントとの間のメディアストリームを送信するためのトラフィックを低減し、出口帯域幅を効果的に低減し、リソースオーバヘッドを低減する。

加えて、この実施形態は、クライアントの役割を変更するプロセスをさらに含む。具体的には、単一のマスタユーザが存在する技術シナリオに関して、第1のクライアントがマスタユーザであり、第2のクライアントがスレーブユーザである場合、本方法は、プロキシサーバが、プロキシクライアントによって送信された、ライブブロードキャストルームからの退室に関する要求メッセージを受信し、ライブブロードキャストルームからの退室に関する要求メッセージが、第1のクライアントがライブブロードキャストルームから退室することを要求するために使用され、第2のクライアントを新しいマスタユーザとして決定したときに、プロキシサーバが、第2のクライアントの役割をスレーブユーザからマスタユーザ（slave－to－master）に変更し、プロキシクライアントが、プロキシクライアントを介してライブブロードキャストルームに入室したクライアント（第2のクライアントを含む）に第2のライブメディアストリームを送信するようにするために、プロキシサーバが、プロキシクライアントに送信される第1のライブメディアストリームを第2のライブメディアストリームに切り替えることをさらに含む。

さらに、プロキシクサーバによってプロキシクライアントに送信される第1のライブメディアストリームの最後のフレームと、プロキシサーバによって第2のクライアントに送信される第2のライブメディアストリームの最初のフレームとは隣接フレームである。

最後のフレームと最初のフレームとが隣接フレームであることを保証するために、プロキシサーバが、第2のクライアントに送信される第1のライブメディアストリームを第2のライブメディアストリームに切り替える前に、本方法は、メディアストリームを位置合わせするステップをさらに含む。メディアストリームを位置合わせするステップは、プロキシサーバが、第1のライブメディアストリームおよび第2のライブメディアストリームに基づいて、第1のライブメディアストリームおよび第2のライブメディアストリームにそれぞれ属する第1のIフレームおよび第2のIフレームを識別し、第1のIフレームおよび第2のIフレームが同じビデオフレームであり、プロキシサーバが、第1のIフレームおよび第2のIフレームに基づいて、第1のライブメディアストリームおよび第2のライブメディアストリームにそれぞれ属する、互いに隣接する第1の切り替えフレームおよび第2の切り替えフレームを決定し、第1の切り替えフレームおよび第2の切り替えフレームを、それぞれ、第2のクライアントに送信される第1のライブメディアストリームの最後のフレームおよび第1のクライアントに送信される第2のライブメディアストリームの最初のフレームとして使用することを特に含む。

さらに、第1の切り替えフレームおよび第2の切り替えフレームを決定した後に、プロキシサーバは、ライブブロードキャストルームからの退室に関する、第1のクライアントからの要求メッセージをメディアサーバに転送する。

同様に、複数のマスタユーザが存在する技術シナリオでは、対応するクライアントがライブブロードキャストルームから退室するプロセスは、第1のクライアントがメインマスタユーザであり、第2のクライアントがスレーブユーザである場合、第1のクライアントが、ライブブロードキャストルームからの退室を要求し、プロキシサーバが、第1のクライアントから、ライブブロードキャストルームからの退室に関する要求メッセージを受信し、プロキシサーバが、第2のクライアントを新しいセカンダリマスタユーザとして使用することを決定し、第2のクライアントの役割をスレーブユーザからセカンダリマスタユーザに変更し、プロキシサーバが、メディアサーバによって送信された第2のライブメディアストリームをリアルタイムで受信し、GOPによって第2のライブメディアストリームをキャッシュすることを含む。この実施形態では、セカンダリマスタユーザとして機能するクライアントに関して、プロキシサーバは、セカンダリマスタユーザの第2のライブメディアストリームを取得し、第2のライブメディアストリームをローカルにキャッシュし、それにより、第2のライブメディアストリームは、役割がセカンダリマスタユーザであるクライアントがメインマスタユーザに変更されたときに直接使用され得る。これは、メディアストリーム送信効率を改善する。

加えて、任意選択で、第1のクライアントがメインマスタユーザであり、第2のクライアントがセカンダリマスタユーザである場合、第1のクライアントがライブブロードキャストルームから退室する手順は、プロキシサーバが、第1のクライアントから、ライブブロードキャストルームからの退室に関する要求メッセージを受信し、第2のクライアントを新しいメインマスタユーザとして使用することを決定したときに、プロキシサーバが、第2のクライアントの役割をセカンダリマスタユーザからメインマスタユーザ（secondary－master to main－master）に変更し、プロキシクライアントに送信される第1のライブメディアストリームを第2のライブメディアストリームに切り替えることを含む。

メディアストリームの切り替え効率を改善するために、プロキシサーバが、役割がセカンダリマスタユーザである新しいクライアントを判定するたびに、プロキシサーバは、クライアントの受信されたメディアストリームをキャッシュし、クライアントの受信されたメディアストリームと、役割が現在メインマスタユーザであるクライアントのメディアストリームとを位置合わせし、具体的には、役割がメインマスタユーザであるクライアントのメディアストリームと、役割がセカンダリマスタユーザであるクライアントのキャッシュされたメディアストリームとに基づいて、2つのメディアストリームに属する同じビデオフレームを識別する。例えば、第1のクライアントから、ライブブロードキャストルームからの退室に関する要求メッセージを受信する前に、プロキシサーバは、GOPによって、受信された第2のライブメディアストリームをキャッシュし、第1のライブメディアストリームおよび第2のライブメディアストリームに基づいて、第1のライブメディアストリームおよび第2のライブメディアストリームにそれぞれ属する第1のIフレームおよび第2のIフレームを識別し、第1のIフレームおよび第2のIフレームは同じビデオフレームである。さらに、ライブブロードキャストルームからの退室に関する、第1のクライアントからの要求メッセージを受信した後に、プロキシサーバは、第1のIフレームおよび第2のIフレームに基づいて、第1のライブメディアストリームおよび第2のライブメディアストリームにそれぞれ属する、隣接する第1の切り替えフレームおよび第2の切り替えフレームを決定する。プロキシサーバは、第1の切り替えフレームおよび第2の切り替えフレームに基づいて、第2のクライアントに送信される第1のライブメディアストリームを第2のライブメディアストリームに切り替え、第2のクライアントに送信される第1のライブメディアストリームの最後のフレームは、第1の切り替えフレームであり、第1のクライアントに送信される第2のライブメディアストリームの最初のフレームは、第2の切り替えフレームである。

加えて、本出願の一実施形態はメディアストリーム送信方法をさらに提供する。本方法は、プロキシクライアントに適用され得る。具体的には、図4に示されているように、本方法は以下のステップを含む。

ステップ201：プロキシクライアントは、第1のクライアントによって送信された、ライブブロードキャストルームへの入室を要求するために使用される第1のライブブロードキャストルーム要求メッセージと、第2のクライアントによって送信された、ライブブロードキャストルームへの入室を要求するために使用される第2のライブブロードキャストルーム要求メッセージとを受信する。

ステップ202：プロキシクライアントは、プロキシサーバを介してメディアサーバに第1のライブブロードキャストルーム要求メッセージおよび第2のライブブロードキャストルーム要求メッセージを送信する。

プロキシクライアントはさらに、第1のライブブロードキャストルーム要求メッセージをプロキシサーバに転送する前に、第1のライブブロードキャストルーム要求メッセージにプロキシクライアントの識別子を追加し、第2のライブブロードキャストルーム要求メッセージをプロキシサーバに転送する前に、第2のライブブロードキャストルーム要求メッセージにプロキシクライアントの識別子を追加し得る。任意選択で、プロキシクライアントの識別子は、プロキシクライアントのIPアドレスである。

ステップ203：プロキシクライアントは、プロキシサーバによって送信された第1のライブメディアストリームを受信し、第1のライブメディアストリームは、プロキシサーバを介してメディアサーバによって第1のクライアントに送信されたメディアストリームであり、第1のクライアントの役割はマスタユーザであり、第2のクライアントの役割はスレーブユーザである。

ステップ204：プロキシクライアントは、第1のライブメディアストリームを第1のクライアントおよび第2のクライアントに送信する。

プロキシクライアントが第1のライブメディアストリームを送信する前に、本方法は、プロキシクライアントがGOPによって第1のライブメディアストリームをキャッシュし、第1のライブメディアストリームのタイムスタンプを調整することをさらに含む。

具体的には、最初に、プロキシクライアントは、ステップ201で第1のクライアントの第1のライブブロードキャストルーム要求メッセージを受信し、ステップ202で第1のライブブロードキャストルーム要求メッセージをプロキシサーバに転送する。プロキシサーバは第1のクライアントをマスタユーザとして判定するため、プロキシクライアントは、ステップ203で第1のクライアントのライブメディアストリーム（すなわち、第1のライブメディアストリーム）を受信し、ステップ204で第1のライブメディアストリームを第1のクライアントに送信する。

次に、プロキシクライアントは、ステップ201で第2のクライアントの第2のライブブロードキャストルーム要求メッセージを受信し、ステップ202で第2のライブブロードキャストルーム要求メッセージをプロキシサーバに転送する。プロキシサーバは第2のクライアントをスレーブユーザとして判定するため、プロキシクライアントは、第2のクライアントのライブメディアストリーム（すなわち、第2のライブメディアストリーム）を受信せず、ステップ204を直接実行して、第1のライブメディアストリームを複製し、複製された第1のライブメディアストリームを第2のクライアントに送信する。第1のライブメディアストリームを複製し、複製された第1のライブメディアストリームを第2のクライアントに送信するとき、プロキシクライアントは、第2のクライアントに送信される第1のライブメディアストリームが、プロキシクライアントによって第2のクライアントに送信される第1のライブメディアストリームの最初のフレームのタイムスタンプが0であり、第2のクライアントに送信される第1のライブメディアストリームの隣接フレームのタイムスタンプが連続することを満たすように、第1のライブメディアストリームのタイムスタンプをさらに調整する。「連続する」は、第1のライブメディアストリームの隣接フレームの時間長が同じであることを意味し、時間長はフレームレートfの逆数である。

加えて、本方法は、プロキシクライアントが、第1のクライアントがライブブロードキャストルームから退室するときに、ライブブロードキャストルームから退室するための、第1のクライアントからの要求メッセージを転送する関連手順が、プロキシクライアントが、第1のクライアントから、ライブブロードキャストルームからの退室に関する要求メッセージを受信し、ライブブロードキャストルームからの退室に関する要求メッセージをプロキシサーバに送信し、ライブブロードキャストルームからの退室に関する要求メッセージに基づいてプロキシサーバによって送信された、ライブブロードキャストルームからの退室に関する応答メッセージを受信し、ライブブロードキャストルームからの退室に関する応答メッセージを第1のクライアントに送信することを特に含むことをさらに含む。

本方法は、プロキシクライアントが、第1のライブブロードキャストルーム要求メッセージを受信したときに、第1のクライアントの役割を動作中（working）としてマークし、プロキシクライアントが、第2のライブブロードキャストルーム要求メッセージを受信したときに、第2のクライアントの役割を動作中としてマークし、プロキシクライアントが、第1のクライアントによって送信された、ライブブロードキャストルームからの退室に関する要求メッセージを受信したときに、第1のクライアントの役割を退室中（exiting）としてマークすることをさらに含む。加えて、プロキシクライアントは、「ライブブロードキャストルームユーザ関係テーブル」に対して第1のクライアントの役割マークを更新する。

加えて、第1のクライアントがライブブロードキャストルームからの退室を要求するときに、本方法は、プロキシクライアントが、プロキシサーバによって送信された第2のライブメディアストリームを受信し、第2のライブメディアストリームが、プロキシクライアントを介してメディアサーバによって第2のクライアントに送信されたメディアストリームであり、第2のクライアントが、役割がスレーブユーザからマスタユーザに変更されたクライアントであり、プロキシクライアントが、第2のライブメディアストリームを第2のクライアントに送信することをさらに含む。

具体的には、プロキシクライアントが第2のライブメディアストリームを第2のクライアントに送信する前に、本方法は、調整されたタイムスタンプが、プロキシクライアントによって第2のクライアントに送信される第2のライブメディアストリームの最初のフレームとプロキシクライアントによって第2のクライアントに送信される第1のライブメディアストリームの最後のフレームとのタイムスタンプが連続することを満たすように、プロキシクライアントが、第2のライブメディアストリームのタイムスタンプを調整することをさらに含む。さらに、プロキシクライアントによって第2のクライアントに送信される第1のライブメディアストリームの最後のフレームと、プロキシクライアントによって第2のクライアントに送信される第2のライブメディアストリームの最初のフレームとは隣接フレームである。

さらに、プロキシクライアントがライブブロードキャストルーム内のクライアント（例えば、第2のクライアント）のライブメディアストリームのタイムスタンプを調整するプロセスは、式y＝x＋Δtに従ってメディアストリームのタイムスタンプを調整することを含み、式中、yは調整後のタイムスタンプを表し、xは調整前のタイムスタンプを表し、Δtは時間差を表す。

メディアストリームが、クライアントがライブブロードキャストルームに入室した後に受信される、最初のチャネルのライブメディアストリームである場合、例えばステップ204において、第1のライブメディアストリームが、第2のクライアントがライブブロードキャストルームに入室した後に受信される、最初のチャネルのライブメディアストリームである場合、プロキシサーバは、調整されたタイムスタンプが以下の制約を満たすように、式に従ってメディアストリームのタイムスタンプを調整する。

1．プロキシクライアントによって第2のクライアントに送信されるライブメディアストリームの最初のフレームのタイムスタンプは0である。

2．プロキシクライアントによって第2のクライアントに送信されるライブメディアストリームの隣接フレームのタイムスタンプは連続し、すなわち、送信されるライブビデオストリームの隣接フレームの時間長は同じであり、時間長はライブビデオストリームのフレームレートfの逆数である。

ライブメディアストリームは、第2のクライアントがライブブロードキャストルームに入室した後に受信される、最初のチャネルのライブメディアストリームであるため、Δtは、プロキシクライアントによって第2のクライアントに送信されるライブメディアストリームの最初のフレームの、調整前のタイムスタンプの反対の数を表す。

例えば、1つのマスタユーザおよび複数のスレーブユーザが存在するシナリオでは、プロキシクライアントによってキャッシュされる第1のライブメディアストリームのGOPの時間長が5秒（s）であり、3つのGOPがローカルにキャッシュされ、3つのGOPのコンテンツはリアルタイムで更新されると仮定される。第1のクライアント（簡単にクライアントC1と呼ばれる）が、最初にライブブロードキャストルームに入室したクライアントである場合、0秒目におけるクライアントC1の役割は、マスタユーザであり、クライアントC1は、60秒目が到来するまで、ライブブロードキャストルーム内で第1のライブメディアストリームを連続的に視聴する。この場合、プロキシクライアントによってローカルにキャッシュされるビデオメディアストリームの3つのGOPは、以下の通りであり、45秒目から50秒目までのメディアコンテンツ、50秒目から55秒目までのメディアコンテンツ、および55秒目から60秒目までのメディアコンテンツである。3つのGOPは、プロキシサーバを介してメディアサーバによってクライアントC1に送信されるメディアストリームのセグメントであり、対応して送信される各フレームのタイムスタンプは、クライアントC1の相対時間である。

第2のクライアント（簡単にクライアントC2と呼ばれる）は、60秒目にライブブロードキャストルームに入室し、クライアントC2の役割はスレーブユーザである。プロキシクライアントは、クライアントC1に送信された、ローカルにキャッシュされた最新の第1のライブメディアストリームをクライアントC2に送信する必要がある。この場合、60秒目に最も近いライブメディアストリームは、第3のGOPセグメントのメディアコンテンツ、すなわち、55秒目から60秒目までのキャッシュされているメディアコンテンツである。55秒目は、メディアサーバによって送信されたフレームのタイムスタンプであり、したがって、調整される必要がある時間差は、Δt＝y－x＝0－55＝－55sであり、すなわち、プロキシクライアントは、前述の制約を満たすために、第1のライブメディアストリームをクライアントC2に送信するときにタイムスタンプを55秒だけ減らす必要がある。このようにして、ライブブロードキャストルームに入室した各クライアントC2は、待機する必要なく0秒目にライブブロードキャストビデオを視聴し得、ライブブロードキャストルーム内のクライアントC1およびクライアントC2は、「同期して」ビデオを視聴し得る。

さらに、本方法は、クライアントC1がライブブロードキャストルームからの退室を要求したときに、プロキシサーバが、クライアントC2に送信される第1のライブメディアストリームを第2のライブメディアストリームに切り替える必要があることをさらに含む。この場合、クライアントC2の役割はマスタユーザに変更され、第2のライブメディアストリームは、メディアサーバによってクライアントC2に送信されるメディアストリームである。それに対応して、プロキシクライアントは、メディアサーバによって送信された第2のライブメディアストリームを受信し、第2のライブメディアストリームのタイムスタンプを調整する。

例えば、クライアントC1がビデオ再生の120秒目にライブブロードキャストルームから退室した場合、プロキシサーバは、クライアントC2の役割をマスタユーザに変更することを決定する。次に、プロキシサーバは、クライアントC2の第2のライブメディアストリームをプロキシクライアントに送信する。プロキシクライアントは、第2のライブメディアストリームを受信してキャッシュする。120秒目において、プロキシクライアントによってローカルにキャッシュされた3つのGOPのメディアコンテンツは、105秒目から110秒目までのメディアコンテンツ、110秒目から115秒目までのメディアコンテンツ、および115秒目から120秒目までのメディアコンテンツであると仮定される。10秒が経過した後、プロキシクライアントによってキャッシュされている最新のGOP1は、115秒目から120秒目までのビデオコンテンツであり、GOP1内のフレームのタイムスタンプは、クライアントC1の相対時間である。クライアントC1がライブブロードキャストルームから退室した後、プロキシクライアントは、0秒目から5秒目までのメディアコンテンツおよび5秒目から10秒目までのメディアコンテンツであるGOP2およびGOP3をローカルにキャッシュする。2つのGOPのタイムスタンプは、クライアントC2の相対時間である。したがって、調整される時間差は、Δt＝120－55－0＝65sとして計算され、すなわち、プロキシクライアントによって、新しいマスタユーザとして機能するクライアントC2に送信される第2のライブメディアストリームのフレームのタイムスタンプは65sだけ増加する必要がある。

結論として、プロキシクライアントがタイムスタンプを調整するとき、時間差を計算する2つのケースが存在し得る。詳細は以下の通りである。

ケース1：クライアントがメディアストリームを受信していない場合、すなわち、現在のメディアストリームが、クライアントがライブブロードキャストルームに入室した後にクライアントによって受信されるメディアストリームの最初のチャネルである場合、時間差は、Δt＝0－t2＝－t2であり、式中、t2は、プロキシサーバからプロキシクライアントによって受信され、クライアントに転送される必要があるメディアストリームの最初のフレームのタイムスタンプを表す。

ケース2：クライアントがメディアストリームを受信している場合、すなわち、プロキシクライアントによってクライアントに送信されるメディアストリームが、前のマスタユーザのメディアストリームから現在のマスタユーザのメディアストリームに切り替えられる場合、時間差は、Δt＝（t1＋m）－t2であり、式中、t2は、メディアストリームの切り替え後にプロキシクライアントによってクライアントに送信されるメディアストリーム（すなわち、現在のマスタユーザのメディアストリーム）の最初のフレームの、調整前のタイムスタンプを表し、t1は、メディアストリームの切り替え前にプロキシクライアントによってクライアントに送信されるメディアストリーム（すなわち、前のマスタユーザのメディアストリーム）の最後のフレームの、調整後のタイムスタンプを表す。対応する次のビデオフレームのタイムスタンプはt1＋mであり、m＝1／fである。例えば、f＝20fpsであり、送信されるビデオフレームの時間長はm＝1s／20＝0．05s、すなわち50msである。

この実施形態で提供される方法によれば、プロキシクライアントおよびプロキシサーバが、マスタユーザとして機能するクライアントによって要求されたライブメディアストリームを取得すると、メディアストリームの一部のセグメントがプロキシクライアントにおいてローカルにキャッシュされる。他のクライアントがライブブロードキャストルームに入室し、ライブメディアストリームを要求すると、プロキシクライアントは、ローカルにキャッシュされたメディアストリームをこれらのクライアントに直接送信し、そのため、プロキシサーバは、ライブメディアストリームをプロキシクライアントに再び送信する必要がない。この方法では、マスタユーザとして機能するクライアントによって要求されたライブメディアストリームのみがプロキシサーバとプロキシクライアントとの間で送信される、言い換えれば、ライブメディアストリームのみを送信するための広域ネットワーク帯域幅が消費される。メディアサーバがプロキシサーバを介して各クライアントにライブメディアストリームを送信するときに占有される送信リソースと比較して、これは、メディアストリームを送信するためのトラフィックを低減し、WANネットワークリンク負荷を低減し、リソースオーバヘッドを低減する。

以下では、本出願の実施形態で提供される方法を具体的に説明する。

実施形態1
この実施形態は、ライブビデオメディアストリーム送信方法を提供する。本方法は、図2に示されているビデオライブブロードキャストシステムに適用され得る。本方法は、プロキシサーバが、同じプロキシクライアントを介してライブブロードキャストルームに入室した第1のクライアントおよび第2のクライアントにライブメディアストリームを提供し、ライブメディアストリームは、コンテンツソースから来て、RDC内のメディアサーバによって転送されることを含む。さらに、図5Aから図5Dに示されているように、本方法は、合計で39のステップ（ステップ、S）、すなわち、S1からS39を含む。

S1からS18は、第1のクライアント（以下、「クライアントC1」と呼ばれる）がライブブロードキャストルームに入室し、ライブメディアストリームを取得するプロセスである。S19からS39は、第2のクライアント（以下、「クライアントC2」と呼ばれる）がライブブロードキャストルームに入室し、ライブメディアストリームを取得するプロセスである。

具体的には、クライアントC1がライブブロードキャストルームに入室し、ライブメディアストリームを取得するプロセスは、以下のステップを含む。

S1：コンテンツソースは、第1のライブメディアストリームをEDC内のメディアサーバに送信する。

S2：EDC内のメディアサーバは、第1のライブメディアストリームを受信し、第1のライブメディアストリームを下位レベルのRDC内のメディアサーバに送信する。第1のライブメディアストリームが送信される前に、本方法は、EDC内のWebサーバが下位レベルのRDC内のメディアサーバを認証し、RDC内のメディアサーバが、認証が成功した場合にのみ、第1のライブメディアストリームをRDC内のメディアサーバに送信するステップをさらに含む。

任意選択で、S2は、プロキシサーバ（proxy server）が、第1のライブメディアストリームのサービス特徴に基づいて、プロキシサーバによってサービスされるクライアントに対応する送信プロトコルを識別することをさらに含む。サービス特徴は、WebサーバのIPアドレスおよびポート番号を含む。例えば、ハイパーテキスト転送プロトコル（Hyper Text Transfer Protocol、HTTP）の場合、構成され得るサービス特徴は、WebサーバのIPアドレスおよびポート番号を含む。さらに、プロキシサーバは、HTTPプロトコルに対応する送信プロトコルが、メディアストリーム送信用の送信制御プロトコル（Transmission Control Protocol、TCP）であると判定してもよい。

S3：クライアントC1は、クライアントC1によってアクセスされ得るメディアサーバに関する要求メッセージをRDC内のWebサーバに送信する。さらに、要求メッセージは、クライアントC1のユーザ名およびIPアドレス、ライブブロードキャストルームの名前、ならびにクライアントC1が正常に認証された後に取得されたキーTokenなどの情報を含み、IPアドレスは、クライアントC1の位置を判定するために使用される。具体的には、クライアントC1は、プロキシクライアントに要求メッセージを送信し、プロキシクライアントは、要求メッセージを受信した後、プロキシサーバに要求メッセージを転送し、プロキシサーバは、RDC内のWebサーバに要求メッセージを転送する。

S4：RDC内のWebサーバは、要求メッセージを受信し、クライアントC1によってアクセスされ得るメディアサーバに関する応答メッセージをクライアントC1に送信し、応答メッセージは、クライアントC1によってアクセスされ得るメディアサーバをクライアントC1に通知するために使用される。具体的には、Webサーバは、要求メッセージに基づいて、メディアストリームサービスをクライアントC1に提供し得るターゲットメディアサーバを決定し、ターゲットメディアサーバは、RDC内の複数のメディアサーバのうちの1つであり、次に、応答メッセージをクライアントC1に送信し、応答メッセージは、ターゲットメディアサーバの関連情報、例えば、ターゲットメディアサーバのユニフォームリソースロケータ（Uniform Resource Locator、URL）情報、IPアドレス、およびポート番号を含む。

具体的には、RDC内のWebサーバは、応答メッセージをプロキシサーバに送信し、プロキシサーバは、応答メッセージをプロキシクライアントに送信し、プロキシクライアントは、応答メッセージをクライアントC1に転送する。

Webサーバは、クライアントC1によって送信された、クライアントC1によってアクセスされ得るメディアサーバに関する要求メッセージで搬送されたIPアドレスに基づいて、クライアントC1の位置を判定し、位置情報に基づいて、クライアントC1に最も近いメディアサーバをターゲットメディアサーバとして選択する。

S5：応答メッセージは、ターゲットメディアサーバの関連情報、例えば、ターゲットメディアサーバのURL情報、IPアドレス、およびポート番号を搬送する。したがって、応答メッセージを転送するとき、プロキシサーバおよびプロキシクライアントは、クライアントC1によってアクセスされ得るメディアサーバに関する情報を取得する、すなわち、プロキシサーバおよびプロキシクライアントは、ターゲットメディアサーバの関連情報を取得する。

S6：クライアントC1は、ライブブロードキャストルームへの入室を要求するための第1のライブブロードキャストルーム要求メッセージをプロキシクライアントに送信し、第1のライブブロードキャストルーム要求メッセージは、クライアントC1がライブブロードキャストルームへの入室を要求していることを示す。第1のライブブロードキャストルーム要求メッセージは、クライアントC1のユーザ名、IPアドレス、およびポート番号、ライブブロードキャストルームの名前、ならびに認証が成功した後に取得されたTokenなどを含む。

S7：プロキシクライアントは、クライアントC1によって送信された第1のライブブロードキャストルーム要求メッセージを受信し、クライアントC1の役割を動作中（working）の状態に設定する。また、プロキシクライアントは、「ライブブロードキャストルームユーザ関係テーブル」を構築し、ライブブロードキャストルームユーザ関係テーブルにクライアントC1に関するエントリを追加する。具体的には、エントリのコンテンツは、クライアントC1のIPアドレス、ポート番号、ユーザステータス、およびユーザ名、RDC内の選択されたターゲットメディアサーバのIPアドレスおよびポート番号、ならびにライブブロードキャストルームの名前などの情報を含む。クライアントC1のユーザステータスはworkingである。クライアントC1のIPアドレスは、データベースに記憶されているプライマリキー（primary key）であってもよい。

加えて、本方法は、プロキシクライアントが、第1のライブブロードキャストルーム要求メッセージにプロキシクライアントの識別子を追加することをさらに含み、プロキシクライアントの識別子は、プロキシクライアントのIPアドレスまたはポート番号などである。

S8：プロキシクライアントは、プロキシクライアントの識別子が追加された第1のライブブロードキャストルーム要求メッセージをプロキシサーバに送信し、修正された第1のライブブロードキャストルーム要求メッセージは、プロキシクライアントの識別子、クライアントC1のユーザ名、ライブブロードキャストルームの名前、および認証が成功した後に取得されたTokenなどの情報を含む。

S9：プロキシサーバは、修正された第1のライブブロードキャストルーム要求メッセージを受信し、第1のライブブロードキャストルーム要求メッセージに基づいてクライアントC1の役割を判定し、ライブブロードキャストルームユーザ関係テーブルをリフレッシュする。具体的には、クライアントC1の役割を判定することは、第1のライブブロードキャストルーム要求メッセージを受信したときに、プロキシクライアントを介してライブブロードキャストルームに入室したクライアントの中で役割がマスタユーザであるクライアントが存在するかどうかを判定し、プロキシクライアントを介してライブブロードキャストルームに入室したクライアントの中で役割がマスタユーザであるクライアントが存在する場合、クライアントC1はスレーブユーザであると判定し、またはプロキシクライアントを介してライブブロードキャストルームに入室したクライアントの中で役割がマスタユーザであるクライアントが存在しない場合、クライアントC1はマスタユーザであると判定することを含む。この実施形態では、クライアントC1は、プロキシクライアントを介して最初にライブブロードキャストルームに入室したユーザであるため、マスタユーザは存在しない。したがって、第1のライブブロードキャストルーム要求メッセージを受信すると、プロキシサーバは、クライアントC1の役割はマスタユーザであると判定し、クライアントC1の役割をマスタユーザとして識別する。

加えて、本方法は、クライアントC1の役割を判定した後に、プロキシサーバが「ライブブロードキャストルームユーザ関係テーブル」をリフレッシュし、クライアントC1の役割をマスタユーザとしてマークすることをさらに含む。当然のことながら、プロキシサーバは、ライブブロードキャストにおける各クライアントの役割および状態をリアルタイムで記録するために、同じプロキシクライアントを介して送信された受信されたライブブロードキャストルーム要求メッセージに基づいて「ライブブロードキャストルームユーザ関係テーブル」をリアルタイムで更新し得る。任意選択で、プロキシサーバは、プロキシクライアントの識別子（IPアドレスおよびポート番号）を「ライブブロードキャストルームユーザ関係テーブル」にさらに記録する。

この実施形態では、役割がライブブロードキャストルーム内のマスタユーザであるクライアントの数は1に設定される。言い換えれば、ライブブロードキャストルーム内には1つのマスタユーザのみが存在し、他のクライアントはスレーブユーザである。この技術シナリオは、単一のマスタユーザが存在するシナリオと呼ばれ得る。

S10：プロキシサーバは、第1のライブブロードキャストルーム要求メッセージをRDC内のメディアサーバに送信する。第1のライブブロードキャストルーム要求メッセージは、プロキシクライアントの識別子を含まない。

ステップS9は、ステップS10の前に実行されてもよいし、またはステップS9は、ステップS10の後に実行されてもよい。これは、この実施形態では厳密に限定されない。

S11：RDC内のメディアサーバは、第1のライブブロードキャストルーム要求メッセージを受信し、第1のライブブロードキャストルーム応答メッセージをクライアントC1に送信する。第1のライブブロードキャストルーム応答メッセージは、クライアントC1がライブブロードキャストルームに正常に入室したことをクライアントC1に通知するために使用される。具体的には、最初に、メディアサーバは、プロキシサーバを介して第1のライブブロードキャストルーム応答メッセージをプロキシクライアントに転送し、次に、プロキシクライアントは、第1のライブブロードキャストルーム応答メッセージをクライアントC1に転送する。

S12：クライアントC1は、第1のメディア要求メッセージをプロキシクライアントに送信し、第1のメディア要求メッセージは、メディアサーバからの第1のライブメディアストリームの取得を要求するために使用される。任意選択で、第1のメディア要求メッセージはクライアントC1の第1の識別子を搬送し、第1の識別子は、クライアントC1を一意に識別するために使用される。この実施形態では、第1の識別子は、クライアントC1のIPアドレスおよびユーザ名などを含む。

具体的には、第1のメディア要求メッセージを受信した後、プロキシクライアントは、第1のメディア要求メッセージをプロキシサーバに転送し、プロキシサーバは、第1のメディア要求メッセージをRDC内のメディアサーバに送信する。

S13：第1のメディア要求メッセージを受信した後、メディアサーバは、第1のメディア応答メッセージをクライアントC1に送信する。第1のメディア応答メッセージは、クライアントC1が第1のライブメディアストリームの取得を許可されたことをクライアントC1に通知するために使用される。具体的には、メディアサーバは、第1のメディア応答メッセージをプロキシサーバに送信し、プロキシサーバは、第1のメディア応答メッセージをプロキシクライアントに転送し、最後にプロキシクライアントは、第1のメディア応答メッセージをクライアントC1に転送する。

S14：メディアサーバは、第1のライブメディアストリームをプロキシサーバに送信する。

S15：プロキシサーバは、メディアサーバによって送信された第1のライブメディアストリームをリアルタイムで取得し、次に、第1のライブメディアストリームをローカルにキャッシュする。具体的には、プロキシサーバは、GOPによって第1のライブメディアストリームのセグメントをローカルにキャッシュする、例えば、3つの最新のGOPのメディアストリームセグメント、すなわち、t1－t2、t2－t3、およびt3－t4をキャッシュする。

S16：プロキシサーバは、プロキシクライアントが第1のライブメディアストリームをクライアントC1に送信するようにするために、第1のライブメディアストリームのキャッシュされたセグメントをプロキシクライアントに送信する。

S17：プロキシクライアントは、プロキシサーバによって送信された第1のライブメディアストリームを受信し、GOPによって第1のライブメディアストリームをローカルにキャッシュする。プロキシクライアントは、第1のライブメディアストリームのいくつかの最新セグメントのみをキャッシュする。

S18：プロキシクライアントは、キャッシュされた第1のライブメディアストリームをクライアントC1に送信する。

任意選択で、プロキシクライアントが第1のライブメディアストリームをクライアントC1に送信するプロセスにおいて、調整されたタイムスタンプが、プロキシクライアントによってクライアントC1に送信される第1のライブメディアストリームの最初のフレームのタイムスタンプが0であり、クライアントC1に送信される第1のライブメディアストリームの隣接フレームのタイムスタンプが連続することを満たすように、プロキシクライアントは、さらに、第1のライブメディアストリームのタイムスタンプを調整する必要がある。「連続する」は、クライアントC1によって受信される第1のライブメディアストリームの隣接ビデオフレームの時間長が同じであることを意味し、時間長はフレームレートfの逆数である。

以下では、クライアントC2がライブブロードキャストルームに入室し、ライブメディアストリームを取得する方法について説明する。具体的には、以下のステップが含まれる。

S19：クライアントC2は、クライアントC2によってアクセスされ得るメディアサーバに関する要求メッセージをRDC内のWebサーバに送信し、要求メッセージは、クライアントC2のユーザ名およびIPアドレス、ライブブロードキャストルームの名前、ならびにクライアントC2が正常に認証された後に取得されたキーTokenなどの情報を含む。具体的には、クライアントC2は、プロキシクライアントおよびプロキシサーバを介してRDC内のWebサーバに要求メッセージを転送する。転送プロセスにおいて、プロキシクライアントおよびプロキシサーバはどちらも、要求メッセージで搬送される情報を取得する。

S20：RDC内のWebサーバは、要求メッセージを受信し、応答メッセージをクライアントC2に送信し、応答メッセージは、クライアントC2によってアクセスされ得るメディアサーバをクライアントC2に通知するために使用される。これは、前述のステップS4と同じである。Webサーバは、メディアストリームサービスをクライアントC2に提供するために複数のメディアサーバのうちの1つを選択し、応答メッセージによって、選択されたメディアサーバの関連情報をプロキシサーバおよびプロキシクライアントに送信する。例えば、選択されたメディアサーバの関連情報は、選択されたメディアサーバのURL情報、IPアドレス、およびポート番号を含む。

S21：応答メッセージを転送するプロセスにおいて、プロキシクライアントおよびプロキシサーバは、要求メッセージで搬送された情報を取得し、この情報は、クライアントC2によってアクセスされ得るメディアサーバに関する情報を含む。例えば、この情報は、メディアサーバのIPアドレスおよびポート番号を含む。

S22：クライアントC2は、ライブブロードキャストルームへの入室を要求するための第2のライブブロードキャストルーム要求メッセージをプロキシクライアントに送信し、第2のライブブロードキャストルーム要求メッセージは、クライアントC2がライブブロードキャストルームへの入室を要求していることを示す。第2のライブブロードキャストルーム要求メッセージは、クライアントC2のユーザ名、IPアドレス、およびポート番号、ライブブロードキャストルームの名前、ならびに認証が成功した後に取得されたTokenなどを含む。

S23：プロキシクライアントは、クライアントC2によって送信された第2のライブブロードキャストルーム要求メッセージを受信し、クライアントC2の役割を動作中（Working）の状態に設定する。また、プロキシクライアントは、クライアントC2に関するエントリを「ライブブロードキャストルームユーザ関係テーブル」に追加する。具体的には、エントリのコンテンツは、クライアントC2のIPアドレス、ポート番号、ユーザステータス、およびユーザ名、RDC内の選択されたターゲットメディアサーバのIPアドレスおよびポート番号、ならびにライブブロードキャストルームの名前などの情報を含む。クライアントC2のユーザステータスはworkingである。クライアントC2のIPアドレスは、データベースに記憶されているプライマリキー（primary key）であってもよい。

加えて、本方法は、プロキシクライアントが、第2のライブブロードキャストルーム要求メッセージにプロキシクライアントの識別子を追加することをさらに含み、プロキシクライアントの識別子は、プロキシクライアントのIPアドレスまたはポート番号などである。

S24：プロキシクライアントは、プロキシクライアントの識別子が追加された第2のライブブロードキャストルーム要求メッセージをプロキシサーバに送信する。修正された第2のライブブロードキャストルーム要求メッセージは、プロキシクライアントの識別子、クライアントC2のユーザ名、ライブブロードキャストルームの名前、および認証が成功した後に取得されたTokenなどの情報を含む。

S25：プロキシサーバは、プロキシクライアントによって送信された修正された第2のライブブロードキャストルーム要求メッセージを受信し、第2のライブブロードキャストルーム要求メッセージに基づいてクライアントC2の役割を判定し、ライブブロードキャストルームユーザ関係テーブルをリフレッシュする。具体的には、可能な実施態様は、第2のライブブロードキャストルーム要求メッセージを受信した後、プロキシサーバが、プロキシクライアントを介してライブブロードキャストルームに入室したクライアントの中で役割がライブブロードキャストルーム内のマスタユーザであるクライアントがライブブロードキャストルーム内に存在するかどうかを判定し、プロキシクライアントを介してライブブロードキャストルームに入室したクライアントの中で役割がライブブロードキャストルーム内のマスタユーザであるクライアントがライブブロードキャストルーム内に存在する場合、プロキシサーバは、クライアントC2の役割はスレーブユーザであると判定することである。この実施形態では、現在、役割がライブブロードキャストルーム内のマスタユーザであるクライアントC1が存在し、したがって、クライアントC2の役割は、スレーブユーザとして判定される。

加えて、S25は、プロキシサーバが、「ライブブロードキャストルームユーザ関係テーブル」をリフレッシュし、クライアントC2の役割をスレーブ（slave）ユーザとして識別することをさらに含む。加えて、本方法は、プロキシサーバが、プロキシクライアントの識別子、例えば、プロキシクライアントのIPアドレスおよびポート番号をクライアントC2に関するエントリに追加することをさらに含む。

S26：プロキシサーバは、第2のライブブロードキャストルーム要求メッセージをRDC内のメディアサーバに送信する。第2のライブブロードキャストルーム要求メッセージは、プロキシクライアントの識別子を含まない。

S27：メディアサーバは、第2のライブブロードキャストルーム要求メッセージを受信し、第2のライブブロードキャストルーム応答メッセージをクライアントC2に送信し、第2のライブブロードキャストルーム応答メッセージは、クライアントC2がライブブロードキャストルームに正常に入室したことをクライアントC2に通知するために使用される。具体的には、メディアサーバは、第2のライブブロードキャストルーム応答メッセージをプロキシサーバおよびプロキシクライアントに送信し、次に、プロキシクライアントは、第2のライブブロードキャストルーム応答メッセージをクライアントC2に転送する。

S28：クライアントC2は、第2のメディア要求メッセージをプロキシクライアントに送信し、第2のメディア要求メッセージは、メディアサーバからのライブメディアストリームの取得を要求するために使用される。任意選択で、第2のメディア要求メッセージはクライアントC2の第2の識別子を搬送し、第2の識別子はクライアントC2を一意に識別するために使用される。この実施形態では、第2の識別子は、クライアントC2のIPアドレスおよびユーザ名などを含む。

具体的には、第2のメディア要求メッセージを受信した後、プロキシクライアントは、第2のメディア要求メッセージをプロキシサーバに転送し、プロキシサーバは、第2のメディア要求メッセージをRDC内のメディアサーバに送信する。

S29：第2のメディア要求メッセージを受信した後、メディアサーバは、第2のメディア応答メッセージをクライアントC2に送信し、第2のメディア応答メッセージは、クライアントC2が第1のライブメディアストリームの取得を許可されたことをクライアントC2に通知するために使用される。具体的には、メディアサーバは、第2のメディア応答メッセージをプロキシサーバに送信し、プロキシサーバは、第2のメディア応答メッセージをプロキシクライアントに転送し、最後にプロキシクライアントは、第2のメディア応答メッセージをクライアントC2に転送する。

S30：プロキシクライアントは、ローカルにキャッシュされた第1のライブメディアストリームをクライアントC2に送信し、さらに、調整されたタイムスタンプが、プロキシクライアントによってクライアントC2に送信される第1のライブメディアストリームの最初のフレームのタイムスタンプが0であり、クライアントC2に送信される第1のライブメディアストリームの隣接フレームのタイムスタンプが連続することを満たすように、第1のライブメディアストリームを送信するときに第1のライブメディアストリームのタイムスタンプを調整する。

S31：メディアサーバは、第2のライブメディアストリームをプロキシサーバに送信し、第2のライブメディアストリームは、クライアントC2に送信されるメディアストリームであり、クライアントC2の役割はスレーブユーザである。

S32：第2のライブメディアストリームを受信した後、プロキシサーバは、第2のライブメディアストリームが、スレーブユーザとして機能するクライアントC2に送信されたメディアストリームであるため、第2のライブメディアストリームをキャッシュもしないし、第2のライブメディアストリームをクライアントC2に転送もしない。

S33：メディアサーバは、第1のライブメディアストリームをプロキシサーバにリアルタイムで送信する。

S34：メディアサーバによって送信された第1のライブメディアストリームを受信した後、プロキシサーバは、GOPによって第1のライブメディアストリームのセグメントをローカルにキャッシュする。この実施形態では、プロキシサーバは、3つのGOPをローカルにキャッシュし、より多くのまたはより少ないGOPをさらにキャッシュしてもよい。これはこの実施形態では限定されない。

S35：プロキシサーバは、第1のライブメディアストリームをプロキシクライアントに送信する。

S36：プロキシクライアントは、第1のライブメディアストリームを受信し、GOPによって第1のライブメディアストリームのセグメントをローカルにキャッシュする。

S37：プロキシクライアントは、「ライブブロードキャストルームユーザ関係テーブル」内のエントリのコンテンツに基づいて、マスタユーザとして機能するクライアントの数およびスレーブユーザとして機能するクライアントの数を判定し、ライブブロードキャストルーム内のクライアントにセグメントを送信する準備をするために、第1のライブメディアストリームセグメントのキャッシュされたセグメントを複製する。この実施形態では、現在、ライブブロードキャストルーム内にクライアントC1およびクライアントC2の2つのクライアントのみが存在し、クライアントC1はマスタユーザであり、クライアントC2はスレーブユーザである。したがって、プロキシクライアントは、第1のライブメディアストリームのコピーをクライアントC2に送信する準備をするために、第1のライブメディアストリームの1つのコピーを作成する。

S38：プロキシクライアントは、ローカルにキャッシュされた第1のライブメディアストリームをクライアントC1に送信する。加えて、本方法は、プロキシクライアントが、クライアントC1がメディアストリームのビデオフレームを受信した時点に基づいて第1のライブメディアストリームのタイムスタンプを調整することをさらに含む。

S39：プロキシクライアントは、ローカルにキャッシュされた第1のライブメディアストリームをクライアントC2に送信する。加えて、本方法は、プロキシクライアントが、クライアントC2がメディアストリームのビデオフレームを受信した時点に基づいて第1のライブメディアストリームのタイムスタンプを調整することをさらに含む。

加えて、ライブブロードキャストルーム内のクライアントC1およびクライアントC2が、第1のライブメディアストリームのメディアコンテンツを「同期して」視聴し得るように、プロキシクライアントは、ライブブロードキャストルームに入室したユーザによって視聴されるビデオフレームのタイムスタンプを調整し、その結果、ユーザ体験が改善される。

この実施形態の方法によれば、プロキシクライアントおよびプロキシサーバが、マスタユーザとして機能する第1のクライアントによって要求されたライブメディアストリームを取得すると、プロキシクライアントは、ライブメディアストリームの一部のセグメントをローカルにキャッシュする。第2のクライアントがライブブロードキャストルームに入室し、ライブメディアストリームを要求すると、プロキシクライアントは、ローカルにキャッシュされたライブメディアストリームを第2のクライアントに直接送信し、そのため、プロキシサーバは、再びライブメディアストリームをプロキシクライアントに送信する必要がない。本方法によれば、プロキシサーバは、1つのライブメディアストリームのみをプロキシクライアントに送信する必要があり、言い換えれば、1つのライブメディアストリームのみを送信するための広域ネットワーク帯域幅が消費される。これは、ライブメディアストリームを送信するためのトラフィックを効果的に低減し得、WANネットワークリンク負荷を低減し、リソースオーバヘッドを低減する。

加えて、この実施形態の方法によれば、クライアントC1の第1のライブブロードキャストルーム要求メッセージおよび第1のメディア要求メッセージは、1つのメッセージに組み合わされてもよく、組み合わされたメッセージは、第1のライブブロードキャストルーム要求メッセージおよび第1のメディア要求メッセージの機能を有する。したがって、クライアントC1の役割を判定するとき、プロキシサーバは、第1のメディア要求メッセージの数に基づいて、現在ライブブロードキャストルームに入室しているマスタユーザとして機能するクライアントの数を計算し得る。同様に、クライアントC2の第2のライブブロードキャストルーム要求メッセージおよび第2のメディア要求メッセージもまた、1つのメッセージに組み合わされてもよく、クライアントC2の役割を判定するための対応する方法は同じである。この実施形態では、詳細は再び説明されない。

加えて、この実施形態で提供される方法は、クライアントC2の役割が例えばスレーブユーザの役割からマスタユーザの役割に変更されたときにメディアサーバがライブメディアストリームをクライアントC2に送信し続けるプロセスをさらに含む。さらに、図6Aおよび図6Bに示されているように、S40からS52が含まれる。具体的な方法の手順は以下の通りである。

S40：クライアントC1は、ライブブロードキャストルームからの退室に関する要求メッセージをプロキシクライアントに送信し、ライブブロードキャストルームからの退室に関する要求メッセージは、クライアントC1がライブブロードキャストルームから退室することを要求するために使用される。ライブブロードキャストルームからの退室に関する要求メッセージは、クライアントC1のユーザ名、IPアドレス、ポート番号、およびユーザの役割、ならびにライブブロードキャストルームの名前などの情報を含む。

S41：ライブブロードキャストルームからの退室に関する要求メッセージを受信した後、プロキシクライアントは、クライアントC1の役割を退室中（Exiting）ユーザとしてマークし、退室中ユーザの役割を「ライブブロードキャストルームユーザ関係テーブル」に記録する。

S42：プロキシクライアントは、ライブブロードキャストルームからの退室に関する要求メッセージをプロキシサーバに送信する。

S43：ライブブロードキャストルームからの退室に関する要求メッセージを受信した後、プロキシサーバは、この時点では、マスタユーザとして機能するクライアントC1によって要求された第1のライブメディアストリームがクライアントC2によって視聴されているため、一時的に、ライブブロードキャストルームからの退室に関する要求メッセージをメディアサーバに転送しない。加えて、クライアントC1の役割は、退室中（Exiting）ユーザとしてマークされ、「ライブブロードキャストルームユーザ関係テーブル」に記録される。

S44：プロキシサーバは、ライブブロードキャストルーム内のクライアントの中から1つのクライアントを新しいマスタユーザとして選択する。この実施形態では、プロキシクライアントを介してライブブロードキャストルームに入室したクライアントC1およびクライアントC2のみが存在する。クライアントC1がライブブロードキャストルームからの退室を要求すると、プロキシサーバは、クライアントC2を新しいマスタユーザとして選択し、クライアントC2の役割をスレーブユーザからマスタユーザに変更し、また、クライアントC2をslave－to－masterユーザとしてマークする。

S45：メディアサーバは、第2のライブメディアストリームをプロキシサーバにリアルタイムで送信する。第2のライブメディアストリームのコンテンツは第1のライブメディアストリームのコンテンツと同じであり、第2のライブメディアストリームと第1のライブメディアストリームとのどちらもコンテンツソースからのものである。

S46：プロキシサーバは、第2のライブメディアストリームを受信し、GOPによって第2のライブメディアストリームをローカルにキャッシュする。

加えて、本方法は、プロキシサーバが、位置合わせアルゴリズムに従って第1のライブメディアストリームと第2のライブメディアストリームとを位置合わせすることをさらに含む。具体的には、位置合わせプロセスは、プロキシサーバが第1のライブメディアストリームのIフレームを受信するたびに、プロキシサーバが、このIフレームをローカルにキャッシュされた第2のライブメディアストリームのIフレームと比較し、プロキシサーバが第2のライブメディアストリームのIフレームを受信するたびに、プロキシサーバが、このIフレームをローカルにキャッシュされた第1のライブメディアストリームのIフレームと比較することを含む。プロキシサーバが、前述の比較を通じて、第1のライブメディアストリームに属するIフレームおよび第2のライブメディアストリームに属するIフレーム（以下、IフレームaおよびIフレームbと呼ばれる）を見つけ、2つのIフレームが同じメディアコンテンツを有する場合、プロキシサーバは、2つのライブメディアストリームは位置合わせされたと判定する。IフレームaとIフレームbとが同じビデオフレームであることが理解されよう。さらに、プロキシサーバは、IフレームaおよびIフレームbに基づいて、切り替えポイントを決定する。具体的には、プロキシサーバは、プロキシクライアントに送信される第1のライブメディアストリームの最後のフレーム（以下、切り替えフレームxと呼ばれる）と、プロキシクライアントに送信される第2のライブメディアストリームの最初のフレーム（以下、切り替えフレームyと呼ばれる）とを決定し、切り替えフレームxと切り替えフレームyとは隣接フレームである。具体的には、プロキシサーバは、第1のライブメディアストリーム内のIフレームaの後のn番目のフレームを切り替えフレームxとして決定し、第2のライブメディアストリーム内のIフレームbの後の（n＋1）番目のフレームを切り替えフレームyとして決定し得、nは0以上の整数である。IフレームaとIフレームbとは同じビデオフレームであるため、Iフレームaの後のn番目のフレームとIフレームbの後の（n＋1）番目のフレームとは当然ながら隣接フレームである。

この実施形態では、役割がマスタユーザであるクライアントC1がライブブロードキャストルームから退室するとき、新しいマスタユーザとして機能するクライアントC2が、第2のライブメディアストリームを要求して取得するために使用される。第1のライブメディアストリームのI番目のフレームと第2のライブメディアストリームのI番目のフレームとは位置合わせされており、そのため、プロキシサーバは、第2のライブメディアストリームをプロキシクライアントに送信するとき、当初から再生されている第1のライブメディアストリームメディアのメディアコンテンツから第2のライブメディアストリームにシームレスに切り替える。このようにして、ライブブロードキャストルーム内のユーザにとって、繰り返し再生される部分はなく、プロキシサーバがライブメディアストリームを切り替えるときに、再生されるコンテンツは統合される。

S47：プロキシサーバは、ライブブロードキャストルームからの退室に関する要求メッセージをメディアサーバに送信する。

S48：ライブブロードキャストルームからの退室に関する要求メッセージを受信した後、メディアサーバは、ライブブロードキャストルームからの退室に関する応答メッセージをプロキシサーバに送信し、ライブブロードキャストルームからの退室に関する応答メッセージは、クライアントC1がライブブロードキャストルームから正常に退室したことをクライアントC1に通知するために使用される。

S49：プロキシサーバは、クライアントC1に対応するエントリを「ライブブロードキャストルームユーザ関係テーブル」から削除する。

S48は、S49の前に実行されてもよいし、またはS48は、S49の後に実行されてもよい。これは厳密に限定されない。

S50：プロキシサーバは、メディアサーバによって送信された、ライブブロードキャストルームからの退室に関する応答メッセージを受信し、ライブブロードキャストルームからの退室に関する応答メッセージをプロキシクライアントに転送する。

S51：プロキシクライアントは、プロキシサーバによって送信された、ライブブロードキャストルームからの退室に関する応答メッセージを受信し、クライアントC1に対応するエントリを「ライブブロードキャストルームユーザ関係テーブル」から削除する。

S52：プロキシクライアントは、ライブブロードキャストルームからの退室に関する応答メッセージをクライアントC1に送信する。

加えて、本方法は、ライブブロードキャストルーム内のクライアントC2がライブメディアコンテンツを正常に視聴し得ることを保証するために、プロキシサーバが、プロキシサーバにキャッシュされた第2のライブメディアストリームをプロキシクライアントに送信し、プロキシクライアントが、第2のライブメディアストリームを受信した後にGOPによって第2のライブメディアストリームをローカルにキャッシュし、次に、キャッシュされた第2のライブメディアストリームのセグメントをクライアントC2に送信することをさらに含む。加えて、第2のライブメディアストリームをクライアントC2に送信するとき、プロキシクライアントは、クライアントC2によって受信される第2のライブメディアストリームの最初のフレームのタイムスタンプと第1のライブメディアストリームの最後のフレームのタイムスタンプとが連続するように、第2のライブメディアストリームのタイムスタンプを調整し、対応する時間長は、フレームレートパラメータfの逆数である。具体的な調整プロセスについては、前述の実施形態の説明を参照されたい。ここでは詳細は再び説明されない。

この実施形態で提供される方法によれば、マスタユーザとして機能するクライアントがライブブロードキャストルームから退室するとき、プロキシサーバは、ライブブロードキャストルーム内のクライアントの中から新しいクライアントを新しいマスタユーザとして選択し、新しいマスタユーザのライブメディアストリームに対して位置合わせを実行し、ライブメディアストリームをプロキシクライアントに送信する。プロキシサーバによって送信された新しいマスタユーザのライブメディアストリームを受信した後、プロキシクライアントは、ライブブロードキャストルーム内でメディアコンテンツを視聴している他のユーザがメディアストリームの切り替えに気付かないように、ライブメディアストリームのタイムスタンプを調整する。この方法は、ライブブロードキャストルーム内で視聴するユーザ体験を保証する。

実施形態2
この実施形態は、別のライブメディアストリーム送信方法を提供し、本方法は、複数のマスタユーザが存在する技術シナリオに適用される。複数のマスタユーザは、役割がマスタユーザであるライブブロードキャストルーム内のクライアントの規定数が2以上であることを示している。さらに、複数のマスタユーザは、1つのメインマスタユーザおよび複数のセカンダリマスタユーザを含み、さらに、少なくとも1つのスレーブ（slave）ユーザを含み得、メインマスタユーザはmain－masterユーザとして識別され得、セカンダリマスタユーザはsecondary－masterユーザとして識別され得る。さらに、この方法では、同じプロキシクライアントを介してライブブロードキャストルームに入室したクライアントがライブメディアストリームを要求して取得するプロセスは、前述の実施形態1で説明されたプロセスと同様であるが、違いは、以下の通りであり、クライアントの役割を識別することであり、役割がマスタユーザであるクライアントがライブブロードキャストルームから退室するときに、依然としてライブブロードキャスト中であるクライアントの役割を識別し、ライブメディアストリームを複製して配信することである。

具体的には、この実施形態では、第3のクライアント（以下、略して「クライアントC3」）がさらに含まれ、ライブブロードキャストルーム内のマスタユーザの数の事前設定上限が2に設定される。この場合、各クライアントがライブブロードキャストルームに入室し、ライブメディアストリームの取得を要求するプロセスは、以下の通りである。図7Aから図7Cに示されているように、プロセスは以下のステップを含む。

S1からS18は、クライアントC1がライブブロードキャストルームに入室し、ライブメディアストリームの取得を要求するプロセスである。このプロセスは、実施形態1のS1からS18と同じであり、S9において、「ライブブロードキャストルームユーザ関係テーブル」がリフレッシュされるときにクライアントC1の役割がメインマスタ（main－master）ユーザとしてマークまたは設定される点にのみ違いがある。他のステップについては、実施形態1の説明を参照されたい。ここでは詳細は再び説明されない。

プロキシサーバが、メディアサーバによって送信された第1のライブメディアストリームを取得すると、プロキシサーバは、GOPによって第1のライブメディアストリームの3つのセグメントをローカルにキャッシュし、プロキシクライアントを介してクライアントC1に第1のライブメディアストリームのセグメントをリアルタイムで送信する。

S19からS39は、クライアントC2がライブブロードキャストルームに入室し、ライブメディアストリームの取得を要求するプロセスである。具体的には、S19からS24は、クライアントC2がプロキシクライアントを介してライブブロードキャストルームに入室し、第2のライブブロードキャストルーム要求メッセージをプロキシクライアントに送信するプロセスである。このプロセスは、実施形態1のS19からS24までのプロセスと同じである。したがって、実施形態1の具体的な説明を参照し得、ここでは詳細は再び説明されない。

S25：プロキシクライアントによって送信された第2のライブブロードキャストルーム要求メッセージを受信した後、プロキシサーバは、第2のライブブロードキャストルーム要求メッセージに基づいてクライアントC2の役割を判定する。具体的には、プロキシサーバは、第2のライブブロードキャストルーム要求メッセージを取得したときに、プロキシクライアントを介してライブブロードキャストルームに入室した、役割がマスタユーザであるクライアントの数が事前設定上限に達しているかどうかを判定する。数が事前設定上限に達している場合、プロキシサーバは、クライアントC2はスレーブユーザであると判定する。数が事前設定上限に達しておらず、マスタユーザとして機能するクライアントの数が0でない場合、プロキシサーバは、クライアントC2はセカンダリマスタユーザであると判定する。この実施形態では、事前設定上限は2であり、プロキシサーバは、クライアントC1からの第1のライブブロードキャストルーム要求メッセージおよびクライアントC2からの第2のライブブロードキャストルーム要求メッセージの合計で2つのライブブロードキャストルーム要求メッセージが現在取得されており、クライアントC1の役割はメインマスタユーザであると判定する。この場合、ライブブロードキャストルーム内のマスタユーザとして機能するクライアントの数は1であり、数は事前設定上限に達していない。したがって、プロキシサーバは、クライアントC2の役割はセカンダリマスタユーザであると判定する。

加えて、本方法は、「ライブブロードキャストルームユーザ関係テーブル」内のクライアントC2に関するエントリをリフレッシュすることと、クライアントC2の役割をセカンダリマスタユーザとしてマークすることとをさらに含む。

本方法は、S26からS39をさらに含む。S26からS39は、クライアントC2が、プロキシクライアントによって送信された第1のライブメディアストリームを取得し、プロキシクライアントが第1のライブメディアストリームをクライアントC1に送信するプロセスである。S26からS39のプロセスは、実施形態1のS26からS39のプロセスと同じである。したがって、この実施形態では詳細は再び説明されない。

しかしながら、S32において、プロキシサーバがメディアサーバから第2のライブメディアストリームを取得した後、第2のライブメディアストリームが、クライアントC2に送信されるメディアストリームであり、クライアントC2の役割がセカンダリマスタユーザである場合、プロキシサーバは、GOPによって第2のライブメディアストリームをローカルにキャッシュし、位置合わせアルゴリズムに従って第1のライブメディアストリームと第2のライブメディアストリームとを位置合わせする。

具体的には、プロキシサーバが位置合わせアルゴリズムに従って第1のライブメディアストリームと第2のライブメディアストリームとを位置合わせするプロセスは、プロキシサーバが第1のライブメディアストリームのIフレームを受信するたびに、プロキシサーバが、このIフレームをローカルにキャッシュされた第2のライブメディアストリームのIフレームと比較し、プロキシサーバが第2のライブメディアストリームのIフレームを受信するたびに、プロキシサーバが、このIフレームをローカルにキャッシュされた第1のライブメディアストリームのIフレームと比較することを含む。プロキシサーバが、前述の比較を通じて、第1のライブメディアストリームに属するIフレームおよび第2のライブメディアストリームに属するIフレーム（以下、IフレームaおよびIフレームbと呼ばれる）を見つけ、2つのIフレームが同じメディアコンテンツを有する場合、プロキシサーバは、2つのライブメディアストリームは位置合わせされたと判定する。IフレームaとIフレームbとが同じビデオフレームであることが理解されよう。さらに、プロキシサーバは、IフレームaおよびIフレームbに基づいて、切り替えポイントを決定する。具体的には、プロキシサーバは、クライアントC2に送信される第1のライブメディアストリームの最後のフレーム（以下、切り替えフレームxと呼ばれる）と、クライアントC2に送信される第2のライブメディアストリームの最初のフレーム（以下、切り替えフレームyと呼ばれる）とを決定し、切り替えフレームxと切り替えフレームyとは隣接フレームである。具体的には、プロキシサーバは、第1のライブメディアストリーム内のIフレームaの後のn番目のフレームを切り替えフレームxとして決定し、第2のライブメディアストリーム内のIフレームbの後の（n＋1）番目のフレームを切り替えフレームyとして決定し得、nは0以上の整数である。IフレームaとIフレームbとは同じビデオフレームであるため、Iフレームaの後のn番目のフレームとIフレームbの後の（n＋1）番目のフレームとは当然ながら隣接フレームである。

この実施形態では、役割がセカンダリマスタユーザである第2のクライアントに関して、プロキシサーバが、メディアサーバによって送信された第2のライブメディアストリームを取得した後、プロキシサーバは、その後の使用のために第2のライブメディアストリームをローカルにキャッシュする。

以下のステップS40からS61は、クライアントC3がライブブロードキャストルームに入室し、ライブメディアストリームを要求して取得するプロセスである。詳細は以下の通りである。

S40：クライアントC3は、クライアントC3によってアクセスされ得るメディアサーバに関する要求メッセージをRDC内のWebサーバに送信する。さらに、要求メッセージは、クライアントC3のユーザ名およびIPアドレス、ライブブロードキャストルームの名前、ならびにクライアントC3が正常に認証された後に取得されたキーTokenなどの情報を含み、IPアドレスは、クライアントC3の位置を判定するために使用される。

S41：RDC内のWebサーバは、要求メッセージを受信し、クライアントC3によってアクセスされ得るメディアサーバに関する応答メッセージをクライアントC3に送信し、応答メッセージは、クライアントC3によってアクセスされ得るメディアサーバをクライアントC3に通知するために使用される。具体的には、RDC内のWebサーバは、応答メッセージをプロキシサーバに送信し、プロキシサーバは、応答メッセージをプロキシクライアントに送信し、プロキシクライアントは、応答メッセージをクライアントC3に転送する。

Webサーバは、クライアントC3によって送信された、クライアントC3によってアクセスされ得るメディアサーバに関する要求メッセージで搬送されたIPアドレスに基づいて、クライアントC3の位置を判定し、位置情報に基づいて、クライアントC3に最も近いメディアサーバをターゲットメディアサーバとして選択する。

S42：応答メッセージは、ターゲットメディアサーバの関連情報、例えば、ターゲットメディアサーバのURL情報、IPアドレス、およびポート番号を搬送する。したがって、応答メッセージを転送するとき、プロキシサーバおよびプロキシクライアントは、クライアントC3によってアクセスされ得るメディアサーバに関する情報、すなわち、ターゲットメディアサーバの関連情報を取得する。

S43：クライアントC3は、ライブブロードキャストルームへの入室を要求するための第3のライブブロードキャストルーム要求メッセージをプロキシクライアントに送信し、第3のライブブロードキャストルーム要求メッセージは、クライアントC3がライブブロードキャストルームへの入室を要求していることを示す。第3のライブブロードキャストルーム要求メッセージは、クライアントC3のユーザ名、IPアドレス、およびポート番号、ライブブロードキャストルームの名前、ならびに認証が成功した後に取得されたTokenなどを含む。

S44：プロキシクライアントは、第3のライブブロードキャストルーム要求メッセージを受信し、クライアントC3の役割を動作中の（Working）状態に設定する。加えて、プロキシクライアントは、「ライブブロードキャストルームユーザ関係テーブル」を更新し、クライアントC3に関するエントリをライブブロードキャストルームユーザ関係テーブルに追加する。具体的には、エントリのコンテンツは、クライアントC3のIPアドレス、ポート番号、ユーザステータス、およびユーザ名、RDC内の選択されたターゲットメディアサーバのIPアドレスおよびポート番号、ならびにライブブロードキャストルームの名前などの情報を含む。クライアントC3のユーザステータスはWorkingである。加えて、エントリは、プロキシクライアントの識別子、例えば、プロキシクライアントのIPアドレスおよびポート番号をさらに含む。

加えて、本方法は、プロキシクライアントが、第3のライブブロードキャストルーム要求メッセージにプロキシクライアントの識別子を追加することをさらに含み、プロキシクライアントの識別子は、プロキシクライアントのIPアドレスまたはポート番号などである。

S45：プロキシクライアントは、プロキシクライアントの識別子が追加された第3のライブブロードキャストルーム要求メッセージをプロキシサーバに送信し、修正された第3のライブブロードキャストルーム要求メッセージは、プロキシクライアントの識別子、クライアントC3のユーザ名、ライブブロードキャストルームの名前、および認証が成功した後に取得されたTokenなどの情報を含む。

S46：プロキシサーバは、修正された第3のライブブロードキャストルーム要求メッセージを受信し、第3のライブブロードキャストルーム要求メッセージに基づいてクライアントC3の役割を判定し、ライブブロードキャストルームユーザ関係テーブルをリフレッシュする。具体的には、クライアントC3の役割を判定することは、第3のライブブロードキャストルーム要求メッセージが受信されたときに、プロキシクライアントを介してライブブロードキャストルームに入室したマスタユーザの数が事前設定上限に達しているかどうかを判定し、数が事前設定上限に達している場合は、クライアントC3の役割はスレーブユーザであると判定し、または数が事前設定上限に達しておらず、マスタユーザの数が0でない場合は、クライアントC3の役割はセカンダリマスタユーザであると判定することを含む。この実施形態では、事前設定上限は2であり、クライアントC3がプロキシクライアントを介してライブブロードキャストルームに入室したとき、マスタユーザとして機能するクライアントの数は現在2であり、これは事前設定上限に等しい。したがって、プロキシサーバは、クライアントC3の役割はスレーブユーザであると判定する。

加えて、本方法は、クライアントC3の役割を判定した後に、プロキシサーバが、「ライブブロードキャストルームユーザ関係テーブル」をリフレッシュし、クライアントC3の役割をスレーブユーザとしてマークすることをさらに含む。

S47：プロキシサーバは、第3のライブブロードキャストルーム要求メッセージをRDC内のメディアサーバに送信する。第3のライブブロードキャストルーム要求メッセージは、プロキシクライアントの識別子を含まない。

S48：RDC内のメディアサーバは、第3のライブブロードキャストルーム要求メッセージを受信し、第3のライブブロードキャストルーム応答メッセージをクライアントC3に送信し、第3のライブブロードキャストルーム応答メッセージは、クライアントC3がライブブロードキャストルームに正常に入室したことをクライアントC3に通知するために使用される。具体的には、最初に、メディアサーバは、第3のライブブロードキャストルーム応答メッセージをプロキシサーバに送信し、次に、プロキシサーバは、第3のライブブロードキャストルーム応答メッセージをプロキシクライアントに送信し、最後に、プロキシクライアントは、第3のライブブロードキャストルーム応答メッセージをクライアントC3に転送する。

S49：クライアントC3は、第3のメディア要求メッセージを送信し、第3のメディア要求メッセージは、メディアサーバからのライブメディアストリームの取得を要求するために使用される。任意選択で、第3のメディア要求メッセージはクライアントC3の識別子を搬送し、識別子は、クライアントC3を一意に識別するために使用される。この実施形態では、識別子は、クライアントC3のIPアドレスおよびユーザ名などを含む。

S50：第3のメディア要求メッセージを受信した後、メディアサーバは、第3のメディア応答メッセージをクライアントC3に送信し、第3のメディア応答メッセージは、クライアントC3がライブメディアストリームの取得を許可されたことをクライアントC3に通知するために使用される。具体的には、メディアサーバは、プロキシサーバおよびプロキシクライアントを介してクライアントC3に第3のメディア応答メッセージを転送する。

S51：プロキシクライアントは、ローカルにキャッシュされた第1のライブメディアストリームをクライアントC3に送信する。第1のライブメディアストリームを送信する前に、プロキシクライアントは、クライアントC3によって受信される第1のライブメディアストリームの最初のフレームのタイムスタンプが0であり、クライアントC3に送信される第1のライブメディアストリームの隣接フレームのタイムスタンプが連続するように、第1のライブメディアストリームのタイムスタンプをさらに調整する必要がある。

S52：メディアサーバは、第3のライブメディアストリームをプロキシサーバに送信し、第3のライブメディアストリームはコンテンツソースから来ており、第3のライブメディアストリームは、クライアントC3に送信されるメディアストリームである。

S53：第3のライブメディアストリームを受信した後、クライアントC3の役割はスレーブユーザであるため、プロキシサーバは、第3のライブメディアストリームをキャッシュもしないし転送もしない。

S54．プロキシサーバは、メディアサーバによって送信された第1のライブメディアストリームをリアルタイムで受信する。

S55：プロキシサーバは、GOPによって第1のライブメディアストリームをローカルにキャッシュする。プロキシサーバは、いくつかの最新のGOPのみをローカルにキャッシュする。

S56：プロキシサーバは、キャッシュされた第1のライブメディアストリームをプロキシクライアントに送信する。

S57：プロキシクライアントは、GOPによって第1のライブメディアストリームをローカルにキャッシュする。

S58：プロキシクライアントは、ライブブロードキャストルームユーザ関係テーブルに基づいて第1のライブメディアストリームを複製する。この実施形態では、メインマスタユーザとして機能するクライアントC1に加えて、セカンダリマスタユーザとして機能するクライアントC2およびスレーブユーザとして機能するクライアントC3が存在し、したがって、プロキシクライアントは、第1のライブメディアストリームのコピーを2つ作成する。

S59：プロキシクライアントは、第1のライブメディアストリームをクライアントC1に送信する。加えて、本方法は、プロキシクライアントが、クライアントC1の再生の時点に基づいて第1のライブメディアストリームのタイムスタンプを調整することをさらに含む。

S60：プロキシクライアントは、第1のライブメディアストリームをクライアントC2に送信する。加えて、本方法は、プロキシクライアントが、クライアントC2の再生の時点に基づいて第1のライブメディアストリームのタイムスタンプを調整することをさらに含む。

S61：プロキシクライアントは、第1のライブメディアストリームをクライアントC3に送信する。加えて、本方法は、プロキシクライアントが、クライアントC3の再生の時点に基づいて第1のライブメディアストリームのタイムスタンプを調整することをさらに含む。

具体的には、プロキシクライアントがS59からS61で第1のライブメディアストリームのタイムスタンプを調整するプロセスについては、前述の実施形態の説明を参照されたい。ここでは詳細は再び説明されない。

加えて、この実施形態では、本方法は、メインマスタユーザとして機能するクライアントC1がライブブロードキャストルームから退室するプロセスをさらに含む。このプロセスは、実施形態1でクライアントC1がライブブロードキャストルームから退室するプロセスと同様である。詳細は図8Aから図8Cに示されている。

S62からS65は、実施形態1のS40からS43と同じである。

S66：プロキシサーバは、セカンダリマスタユーザとして機能するクライアントC2を新しいメインマスタユーザとして選択し、クライアントC2の役割をセカンダリマスタユーザからメインマスタユーザに変更し、「ライブブロードキャストルームユーザ関係テーブル」内のクライアントC2に関するエントリを更新する。

S67からS73は、実施形態1のS48からS53と同じである。

S74：メディアサーバは、第3のライブメディアストリームをプロキシサーバに送信し、第3のライブメディアストリームは、クライアントC3に送信されるメディアストリームであり、第3のライブメディアストリームはコンテンツソースから来たものである。この場合、クライアントC3の役割は、スレーブユーザからセカンダリマスタユーザに変更される。

S75：プロキシサーバが第3のライブメディアストリームを受信した後、クライアントC3の役割がセカンダリマスタユーザに変更されているため、プロキシサーバは、GOPによって第3のライブメディアストリームをローカルにキャッシュし、位置合わせアルゴリズムに従って第2のライブメディアストリームと第3のライブメディアストリームとを位置合わせする。

クライアントC1がライブブロードキャストルームから退室する手順では、プロキシサーバが、ライブブロードキャストルーム内のクライアント（例えば、クライアントC2）に送信される第1のライブメディアストリームを第2のライブメディアストリームに切り替えた後、メディアサーバは、プロキシサーバを介してクライアントC2に第2のライブメディアストリームを連続的に送信する。切り替え後、プロキシサーバは、受信された第2のライブメディアストリームをプロキシクライアントに連続的に配信する。詳細については、以降のステップを参照されたい。

S76：メディアサーバは、第2のライブメディアストリームをプロキシサーバにリアルタイムで送信し、第2のライブメディアストリームは、クライアントC2に送信されるメディアストリームであり、第2のライブメディアストリームはコンテンツソースから来たものである。この場合、クライアントC2の役割は、セカンダリマスタユーザからメインマスタユーザに変更される。

S77：第2のライブメディアストリームを受信した後、プロキシサーバは、GOPによって第2のライブメディアストリームをローカルにキャッシュし、位置合わせアルゴリズムに従って第1のライブメディアストリームと第2のライブメディアストリームとを位置合わせする。

S78：プロキシサーバは、第2のライブメディアストリームをプロキシクライアントに送信する。

S79：プロキシクライアントは、プロキシサーバによって送信された第2のライブメディアストリームを受信し、GOPによって第2のライブメディアストリームをローカルにキャッシュする。

S80：プロキシクライアントは、「ライブブロードキャストルームユーザ関係テーブル」に基づいて第2のライブメディアストリームを複製して配信する。この実施形態では、プロキシクライアントは、第2のライブメディアストリームの1つのコピーを作成し、第2のライブメディアストリームのコピーを、役割がライブブロードキャストルーム内のセカンダリマスタユーザであるクライアントC3に送信する準備をする。

S81：プロキシクライアントは、ローカルにキャッシュされた第2のライブメディアストリームをクライアントC2に送信する。加えて、本方法は、プロキシクライアントが、クライアントC2がメディアストリームのビデオフレームを受信した時点に基づいて第2のライブメディアストリームのタイムスタンプを調整することをさらに含む。

S82：プロキシクライアントは、ローカルにキャッシュされた第2のライブメディアストリームをクライアントC3に送信する。加えて、本方法は、プロキシクライアントが、クライアントC3がメディアストリームのビデオフレームを受信した時点に基づいて第2のライブメディアストリームのタイムスタンプを調整することをさらに含む。

この実施形態で提供される方法によれば、ライブブロードキャストルーム内のメインマスタユーザが退室するときにライブブロードキャストルーム内の別のユーザのユーザ体験が影響を受けないことを保証するために、メインマスタユーザとして機能するクライアントC1がライブブロードキャストルームから退室すると、プロキシサーバは、新しいメインマスタユーザとして機能するクライアントC2のライブメディアストリームをプロキシクライアントに送信し、次に、プロキシクライアントは、新しいライブメディアストリームをクライアントC2およびC 3に送信する。

この実施形態では、プロキシサーバは、メディアサーバによって送信された複数のライブメディアストリームを取得し、各ライブメディアストリームは、1つのクライアントのメディア要求メッセージに対応する。しかしながら、メディアストリームをプロキシクライアントに送信するとき、プロキシサーバは、役割がメインマスタユーザであるクライアントに対応するライブメディアストリームのみをプロキシクライアントに送信し、役割がセカンダリマスタユーザであるクライアントの取得されたライブメディアストリームをローカルにキャッシュし、役割がスレーブユーザであるクライアントの取得されたライブメディアストリームをキャッシュせず、このライブメディアストリームを直接破棄する。したがって、プロキシサーバは、1つのライブメディアストリームのみをプロキシクライアントに送信するために広域ネットワーク帯域幅を消費し、プロキシサーバとプロキシクライアントとの間のWANネットワークリソースを節約する。プロキシクライアント側では、プロキシサーバによって送信されたライブメディアストリームを受信した後、プロキシクライアントは、ライブメディアストリームを複製し、ライブメディアストリームのコピーをライブブロードキャストルーム内のすべてのクライアントに配信し、プロキシクライアントを介してライブブロードキャストルームに入室したすべてのユーザがライブブロードキャストコンテンツを「同期して」視聴し得るように、ライブメディアストリームを送信する前に各クライアントのタイムスタンプを調整する。

加えて、この実施形態で提供される方法は、クライアントC2およびクライアントC1が同期してライブブロードキャストルームから退室することを要求するプロセスをさらに含む。具体的には、クライアントC2がライブブロードキャストルームからの退室を要求するプロセスは、クライアントC1がライブブロードキャストルームから退室する前述のプロセスと同様である。

具体的には、最初に、クライアントC1は、ライブブロードキャストルームからの退室を要求する。このプロセスは、S62からS73までの前述のプロセス（図8Aおよび図8Bに示されているような）と同じであり、詳細は再び説明されない。クライアントC1がライブブロードキャストルームから退室すると、クライアントC2の役割は、セカンダリマスタユーザからメインマスタユーザに変更され、クライアントC3の役割は、スレーブユーザからセカンダリマスタユーザに変更される。

S73の後、クライアントC2がライブブロードキャストルームからの退室を要求するプロセスは、クライアントC2が、ライブブロードキャストルームからの退室に関する要求メッセージをプロキシクライアントに送信し、ライブブロードキャストルームからの退室に関する要求メッセージを受信した後、プロキシクライアントが、クライアントC2の役割を退室中ユーザとしてマークし、ライブブロードキャストルームからの退室に関する要求メッセージをプロキシサーバに転送し、ライブブロードキャストルームからの退室に関する要求メッセージを受信した後、プロキシサーバが、「ライブブロードキャストルームユーザ関係テーブル」においてクライアントC2の役割を退室中ユーザとしてリフレッシュすることを含む。この場合、クライアントC3は、依然としてライブブロードキャストルーム内におり、ライブメディアストリームを取得し、プロキシサーバは、メディアサーバによって送信された第3のライブメディアストリームを受信し、第3のライブメディアストリームは、クライアントC3に送信されるメディアストリームである。この場合、クライアントC3の役割は、セカンダリマスタユーザからメインマスタユーザに変更される。したがって、プロキシサーバは、GOPによって第3のライブメディアストリームをローカルにキャッシュする。

クライアントC3は、依然としてライブブロードキャストルーム内でライブブロードキャストコンテンツを視聴しているため、プロキシサーバは、ライブメディアストリームを第3のライブメディアストリームに切り替え、第3のライブメディアストリームと第1のライブメディアストリームとを位置合わせする必要がある。プロキシサーバは、第3のライブメディアストリームをプロキシクライアントに送信する。第3のライブメディアストリームを受信した後、プロキシクライアントは、第3のライブメディアストリームをキャッシュしてクライアントC3に送信し、クライアントC3に送信される第3のライブメディアストリームが以前のメディアストリームにシームレスに相互接続され得るように、プロキシクライアントが第3のライブメディアストリームを送信するときにタイムスタンプを調整する。このようにして、クライアントC1およびC2が退室するとき、クライアントC3は影響を受けず、その結果、依然としてライブブロードキャストルーム内にいるクライアントC3によって視聴されるメディアコンテンツの円滑性が保証される。

加えて、本方法は、プロキシサーバおよびプロキシクライアントが、ライブブロードキャストルーム内のクライアントに関する情報をリアルタイムで更新するために、ライブブロードキャストからの退室に関する、クライアントC2の応答メッセージを転送するときに「ライブブロードキャストルームユーザ関係テーブル」からクライアントC2に関するエントリを削除することをさらに含む。

前述の実施形態1および実施形態2では、同じプロキシクライアントを介してライブブロードキャストルームに入室したすべてのクライアントとプロキシサーバとが、各クライアントの役割を識別し、ライブメディアストリームを配信することに留意されたい。加えて、別のケースもある。複数のプロキシクライアントは、同じプロキシサーバにアクセスする。プロキシサーバを介して同じライブブロードキャストルームに入室したすべてのクライアントに関して、プロキシサーバは、複数のプロキシクライアントを介してライブブロードキャストルームに入室したすべてのクライアントに関してユーザの役割を集合的に識別する。例えば、3つのプロキシクライアントが同じプロキシサーバにアクセスする場合、プロキシサーバは、ライブブロードキャストルーム内のすべてのクライアントに関してマスタユーザおよびスレーブユーザを集中的に識別し、識別された役割に基づいてライブメディアストリームを各プロキシクライアントに送信する。さらに、プロキシサーバがユーザの役割を識別し、ライブメディアストリームを各プロキシクライアントに送信し、各プロキシクライアントが、ライブメディアストリームを複製し、プロキシクライアントにアクセスしたすべてのクライアントにライブメディアストリームのコピーを配信するプロセスは、実施形態1および実施形態2の方法におけるプロセスである。ここでは詳細は再び説明されない。

本出願のこの実施形態で提供される、ビデオライブブロードキャストのためのバイラテラルプロキシ技術によれば、プロキシクライアントおよびプロキシサーバが使用される。プロキシサーバは、ライブブロードキャストルーム要求メッセージに基づいて各クライアントの役割を識別し、役割がマスタユーザであるクライアントの1つのライブメディアストリームのみをプロキシクライアントに送信するように構成される。マスタユーザのライブメディアストリームを受信した後、プロキシクライアントは、ライブメディアストリームを複製し、プロキシクライアントにアクセスしたすべてのクライアントにライブメディアストリームのコピーを配信する。この方法は、プロキシサーバとプロキシクライアントとの間でメディアストリームを送信するためのトラフィックを効果的に低減し、出口帯域幅を低減し、WANネットワークオーバヘッドを低減する。

加えて、本方法によれば、メディアサーバはクライアントの独立した認証を構成する必要がなく、プロキシクライアントは転送を集中的に実行し、その結果、運用および保守コストがさらに削減される。

以下では、本出願の前述の方法の実施形態に対応する装置およびハードウェアデバイスの実施形態について説明する。

図9は、本出願の一実施形態によるメディアストリーム送信装置の概略構造図である。本装置は、前述の実施形態で説明されたプロキシサーバまたはプロキシクライアントであり得る。

さらに、本装置は、受信ユニット901、処理ユニット902、および送信ユニット903を含む。加えて、本装置は、別の機能モジュールまたはユニット、例えば記憶ユニットをさらに含んでもよい。本装置は、サーバであり得、前述の実施形態におけるメディアストリーム送信方法を実行するように構成される。例えば、本装置は、同じプロキシクライアントを介してライブブロードキャストルームに入室した少なくとも2つのクライアントにライブメディアストリームを提供する。

具体的には、本装置がプロキシサーバである場合、受信ユニット901は、同じプロキシクライアントによって送信された、ライブブロードキャストルームへの入室を要求するために使用される第1のライブブロードキャストルーム要求メッセージおよび第2のライブブロードキャストルーム要求メッセージを受信し、第1のライブブロードキャストルーム要求メッセージは第1のクライアントからのものであり、第2のライブブロードキャストルーム要求メッセージは第2のクライアントからのものである、ように構成される。受信ユニット901は、プロキシサーバを介してメディアサーバによって第1のクライアントに送信される第1のライブメディアストリームと、プロキシサーバを介してメディアサーバによって第2のクライアントに送信される第2のライブメディアストリームとを受信するようにさらに構成される。処理ユニット902は、第1のライブブロードキャストルーム要求メッセージに基づいて第1のクライアントの役割を判定し、第2のライブブロードキャストルーム要求メッセージに基づいて第2のクライアントの役割を判定するように構成される。送信ユニット903は、第1のクライアントの役割はマスタユーザであり、第2のクライアントの役割はスレーブユーザであると判定された場合、第1のライブメディアストリームのみを第1のクライアントおよび第2のクライアントに送信するように構成される。

第1のライブブロードキャストルーム要求メッセージはプロキシクライアントの識別子を含み、第2のライブブロードキャストルーム要求メッセージはプロキシクライアントの識別子を含む。処理ユニット902は、第1のライブブロードキャストルーム要求メッセージに含まれるプロキシクライアントの識別子および第2のライブブロードキャストルーム要求メッセージに含まれるプロキシクライアントの識別子に基づいて、第1のライブブロードキャストルーム要求メッセージと第2のライブブロードキャストルーム要求メッセージとが同じプロキシクライアントからのものであると判定するようにさらに構成される。

任意選択で、この実施形態の特定の実施態様では、処理ユニット902は、第2のライブブロードキャストルーム要求メッセージが受信されたときに、プロキシクライアントを介してライブブロードキャストルームに入室した、役割がライブブロードキャストルーム内のマスタユーザであるクライアントがライブブロードキャストルーム内に存在するかどうかを判定し、プロキシクライアントを介してライブブロードキャストルームに入室した、役割がライブブロードキャストルーム内のマスタユーザであるクライアントがライブブロードキャストルーム内に存在する場合、第2のクライアントの役割はスレーブユーザであると判定するように特に構成される。そうではなく、プロキシクライアントを介してライブブロードキャストルームに入室した、役割がライブブロードキャストルーム内のマスタユーザであるクライアントが存在しない場合、処理ユニット902は、第2のクライアントの役割はマスタユーザであると判定する。

任意選択で、この実施形態の別の特定の実施態様では、受信ユニット901は、第1のライブメディアストリームがプロキシクライアントに送信された後に、プロキシクライアントによって送信された、ライブブロードキャストルームからの退室に関する要求メッセージを受信し、ライブブロードキャストルームからの退室に関する要求メッセージは、第1のクライアントがライブブロードキャストルームから退室することを要求するために使用される、ようにさらに構成される。処理ユニット902は、第2のクライアントを新しいマスタユーザとして決定したときに、第2のクライアントの役割をスレーブユーザからマスタユーザに変更し、第2のクライアントに送信される第1のライブメディアストリームを第2のライブメディアストリームに切り替えるようにさらに構成される。

任意選択で、この実施形態のさらに別の特定の実施態様では、第2のクライアントに送信される第1のライブメディアストリームの最後のフレームと第2のクライアントに送信される第2のライブメディアストリームの最初のフレームとは隣接フレームである。処理ユニット902は、第1のライブメディアストリームおよび第2のライブメディアストリームに基づいて、第1のライブメディアストリームおよび第2のライブメディアストリームにそれぞれ属する第1のIフレームおよび第2のIフレームを識別し、第1のIフレームと第2のIフレームとは同じビデオフレームであり、第1のIフレームおよび第2のIフレームに基づいて、第1のライブメディアストリームおよび第2のライブメディアストリームにそれぞれ属する、互いに隣接する第1の切り替えフレームおよび第2の切り替えフレームを決定し、第1の切り替えフレームおよび第2の切り替えフレームを、それぞれ、第2のクライアントに送信される第1のライブメディアストリームの最後のフレームおよび第1のクライアントに送信される第2のライブメディアストリームの最初のフレームとして使用するようにさらに構成される。送信ユニット903は、第1の切り替えフレームおよび第2の切り替えフレームが決定された後に、ライブブロードキャストルームからの退室に関する、第1のクライアントからの要求メッセージをメディアサーバに転送するようにさらに構成される。

任意選択で、この実施形態のさらに別の特定の実施態様では、処理ユニット902は、第2のライブブロードキャストルーム要求メッセージが受信されたときに、プロキシクライアントを介してライブブロードキャストルームに入室した、役割がマスタユーザであるクライアントの数が事前設定上限に達しているかどうかを判定し、事前設定上限は2以上であり、プロキシクライアントを介してライブブロードキャストルームに入室した、役割がマスタユーザであるクライアントの数が事前設定上限に達している場合、第2のクライアントの役割はスレーブユーザであると判定するように特に構成される。

それに対応して、役割がマスタユーザであるクライアントの数が0ではなく、事前設定上限に達していない場合、処理ユニット902は、第2のクライアントの役割はセカンダリマスタユーザであると判定する。

任意選択で、この実施形態のさらに別の特定の実施態様では、第1のクライアントがメインマスタユーザであり、第2のクライアントがスレーブユーザである場合に、受信ユニット901は、第1のクライアントから、ライブブロードキャストルームからの退室に関する要求メッセージを受信するようにさらに構成される。処理ユニット902は、第2のクライアントを新しいセカンダリマスタユーザとして決定したときに、第2のクライアントの役割をスレーブユーザからセカンダリマスタユーザに変更するようにさらに構成される。記憶ユニットは、受信された第2のライブメディアストリームをGOPによってキャッシュするように構成される。

任意選択で、この実施形態のさらに別の特定の実施態様では、第1のクライアントがメインマスタユーザであり、第2のクライアントがセカンダリマスタユーザである場合に、記憶ユニットは、受信された第2のライブメディアストリームをGOPによってキャッシュするように構成される。処理ユニット902は、第1のライブメディアストリームおよびキャッシュされた第2のライブメディアストリームに基づいて、第1のライブメディアストリームおよび第2のライブメディアストリームにそれぞれ属する第1のIフレームおよび第2のIフレームを識別し、第1のIフレームと第2のIフレームとは同じビデオフレームである、ようにさらに構成される。

任意選択で、この実施形態のさらに別の特定の実施態様では、受信ユニット901は、第1のクライアントから、ライブブロードキャストルームからの退室に関する要求メッセージを受信するようにさらに構成される。処理ユニット902は、第2のクライアントを新しいメインマスタユーザとして決定したときに、第1のIフレームおよび第2のIフレームに基づいて、第1のライブメディアストリームおよび第2のライブメディアストリームにそれぞれ属する、互いに隣接する第1の切り替えフレームおよび第2の切り替えフレームを決定し、第1の切り替えフレームおよび第2の切り替えフレームに基づいて、第2のクライアントに送信される第1のライブメディアストリームを第2のライブメディアストリームに切り替え、第2のクライアントに送信される第1のライブメディアストリームの最後のフレームは第1の切り替えフレームであり、第1のクライアントに送信される第2のライブメディアストリームの最初のフレームは第2の切り替えフレームである、ようにさらに構成される。

任意選択で、この実施形態のさらに別の特定の実施態様では、記憶ユニットは、GOPによって第1のライブメディアストリームおよび第2のライブメディアストリームをキャッシュするように構成される。

加えて、本装置がプロキシクライアントである場合、受信ユニット901は、第1のクライアントによって送信された第1のライブブロードキャストルーム要求メッセージと、第2のクライアントによって送信された第2のライブブロードキャストルーム要求メッセージとを受信するように構成される。送信ユニット903は、プロキシサーバを介してメディアサーバに第1のライブブロードキャストルーム要求メッセージおよび第2のライブブロードキャストルーム要求メッセージを送信するように構成される。受信ユニット901は、プロキシサーバによって送信された第1のライブメディアストリームを受信し、第1のライブメディアストリームは、プロキシサーバを介してメディアサーバによって第1のクライアントに送信されたメディアストリームであり、第1のクライアントの役割はマスタユーザであり、第2のクライアントの役割はスレーブユーザである、ようにさらに構成される。送信ユニット903は、第1のライブメディアストリームを第1のクライアントおよび第2のクライアントに送信するようにさらに構成される。

さらに、処理ユニット902は、第1のライブブロードキャストルーム要求メッセージが送信される前に、プロキシクライアントの識別子を第1のライブブロードキャストルーム要求メッセージに追加し、第2のライブブロードキャストルーム要求メッセージが送信される前に、プロキシクライアントの識別子を第2のライブブロードキャストルーム要求メッセージに追加するように構成される。

本装置は、GOPによって第1のライブメディアストリームをキャッシュするように構成された記憶ユニットをさらに含む。

任意選択で、この実施形態の特定の実施態様では、処理ユニット902は、第1のライブブロードキャストルーム要求メッセージが受信されたときに、第1のクライアントの役割を動作中としてマークし、第2のライブブロードキャストルーム要求メッセージが受信されたときに、第2のクライアントの役割を動作中としてマークし、ライブブロードキャストルームからの退室に関する要求メッセージが受信されたときに、第1のクライアントの役割を退室中としてマークするようにさらに構成される。

任意選択で、この実施形態の特定の実施態様では、処理ユニット902は、第1のライブメディアストリームが第2のクライアントに送信される前に、調整されたタイムスタンプが、第2のクライアントに送信される第1のライブメディアストリームの最初のフレームのタイムスタンプが0であり、第2のクライアントに送信される第1のライブメディアストリームの隣接フレームのタイムスタンプが連続することを満たすように、第1のライブメディアストリームのタイムスタンプを調整するようさらに構成される。

任意選択で、この実施形態の特定の実施態様では、第1のクライアントがライブブロードキャストルームからの退室を要求したときに、受信ユニット901は、プロキシサーバによって送信された第2のライブメディアストリームを受信し、第2のライブメディアストリームは、プロキシクライアントを介してメディアサーバによって第2のクライアントに送信されたメディアストリームであり、第2のクライアントは、役割がスレーブユーザからマスタユーザに変更されたクライアントである、ようにさらに構成される。送信ユニット903は、第2のライブメディアストリームを第2のクライアントに送信するようにさらに構成される。

任意選択で、この実施形態の特定の実施態様では、処理ユニット902は、第2のライブメディアストリームが第2のクライアントに送信される前に、調整されたタイムスタンプが、第2のクライアントに送信される第2のライブメディアストリームの最初のフレームと第2のクライアントに送信される第1のライブメディアストリームの最後のフレームとのタイムスタンプが連続することを満たすように、第2のライブメディアストリームのタイムスタンプを調整するようさらに構成される。

特定のハードウェアの実施態様では、図10に示されているように、本出願はネットワークデバイスをさらに提供する。ネットワークデバイスは、前述の方法の実施形態におけるプロキシサーバまたはプロキシクライアントであってもよいし、またはCDNシステム内の別のデバイスまたは装置であってもよい。

具体的には、ネットワークデバイスは、トランシーバ10、プロセッサ20、およびメモリ30を含む。あるいは、ネットワークデバイスは、より多くのもしくはより少ない構成要素を含んでもよいし、または一部の構成要素は組み合わされてもよいし、または構成要素は異なって配置されてもよい。これは本出願では限定されない。

トランシーバ10は、要求メッセージ、応答メッセージ、およびライブメディアストリームなどを送受信し、ネットワーク内の別のデバイス（クライアントまたはメディアサーバなど）との間でデータ送信を実行するように構成される。さらに、トランシーバ10は、受信機1001、送信機1002、およびアンテナ1003などの構成要素を含んでもよいし、またはトランシーバモジュールをさらに含んでもよい。さらに、トランシーバモジュールは、無線ローカルエリアネットワーク通信（wireless local area network、WLAN）モジュール、ブルートゥース（登録商標）モジュール、またはベースバンド（baseband）モジュールなどの通信モジュールを含んでもよく、また、通信モジュールに対応する無線周波数（radio frequency、RF）回路を含んでもよく、無線周波数回路は、無線ローカルエリアネットワーク通信、ブルートゥース（登録商標）通信、赤外線通信、および／またはセルラー通信システム通信、例えば、広帯域符号分割多元接続（wideband code division multiple access、WCDMA（登録商標））および／または高速ダウンリンクパケットアクセス（high speed downlink packet access、HSDPA）を実行するように構成される。トランシーバモジュールは、ネットワークデバイス内の構成要素間の通信を制御するように構成され、ダイレクトメモリアクセス（direct memory access）をサポートし得る。

プロセッサ20は、ネットワークデバイスの制御センタであり、様々なインターフェースおよびラインを介してネットワークデバイス全体の様々な部分に接続される。プロセッサ20は、ネットワークデバイスの様々な機能を実行し、および／またはデータを処理するために、メモリ30に記憶されたソフトウェアプログラムおよび／またはユニットを動作させまたは実行し、メモリ30に記憶されたデータを呼び出す。

さらに、プロセッサ20は、集積回路（integrated circuit、IC）を含み得、例えば、単一のパッケージICを含み得るし、または同じ機能もしくは異なる機能を有する複数の接続されたパッケージICを含み得る。例えば、プロセッサは、中央処理装置（Central Processing Unit、CPU）のみを含んでもよいし、またはGPUとデジタル信号プロセッサ（Digital Signal Processor、DSP）とトランシーバ内の制御チップ（ベースバンドチップなど）との組み合わせであってもよい。

メモリ30は、揮発性メモリ（volatile memory）、例えばランダムアクセスメモリ（Random Access Memory、RAM）を含み得るし、または不揮発性メモリ（non－volatile memory）、例えばフラッシュメモリ（flash memory）、ハードディスクドライブ（Hard Disk Drive、HDD）、もしくはソリッドステートドライブ（Solid－State Drive、SSD）を含み得る。メモリは、前述のタイプのメモリの組み合わせをさらに含み得る。メモリは、プログラムまたはコードを記憶し得る。プロセッサ20は、通信デバイスの機能を実施するためにプログラムまたはコードを実行する。

この実施形態では、ネットワークデバイスがプロキシサーバである場合、図9に示されている装置の実施形態における受信ユニット901および送信ユニット903の機能は、トランシーバ10によって実施され得るし、またはプロセッサ20によって制御されるトランシーバ10によって実施され得る。処理ユニット902の機能は、プロセッサ20によって実施され得る。記憶ユニットの機能は、メモリ30によって実施され得る。

ネットワークデバイスがプロキシクライアントである場合、図9に示されている装置の実施形態における受信ユニット901および送信ユニット903の機能は、トランシーバ10によって実施され得るし、またはプロセッサ20によって制御されるトランシーバ10によって実施され得る。処理ユニット902の機能は、プロセッサ20によって実施され得る。記憶ユニットの機能は、メモリ30によって実施され得る。

加えて、本出願の一実施形態はメディアストリーム送信システムをさらに提供する。本システムは、図9に示されているメディアストリーム送信装置または図10に示されているネットワークデバイスを含み、前述の方法の実施形態におけるメディアストリーム送信方法を実施するために、複数のクライアント、RDC、EDC、およびコンテンツソースなどのデバイスをさらに含む。

任意選択で、メディアストリーム送信システムは、ビデオライブブロードキャストシステム、例えばCDNシステムである。

加えて、本出願はコンピュータ記憶媒体をさらに提供する。コンピュータ記憶媒体はプログラムを記憶し得る。プログラムが実行されるとき、本出願で提供されるコンテンツ送信方法およびコンテンツ受信方法の実施形態のステップの一部または全部が実行され得る。記憶媒体は、磁気ディスク、光ディスク、読み出し専用メモリROM、またはランダムアクセスメモリRAMなどであり得る。

前述の実施形態の全部または一部は、ソフトウェア、ハードウェア、ファームウェア、またはこれらの任意の組み合わせを使用して実施され得る。ソフトウェアが機能を実施するために使用される場合、機能の全部または一部は、コンピュータプログラム製品の形態で実施され得る。

コンピュータプログラム製品は1つ以上のコンピュータ命令を含む。コンピュータプログラムがコンピュータ上でロードされて実行されるとき、本出願の前述の実施形態による手順または機能の全部または一部が生成される。コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータネットワーク、または別のプログラマブル装置であってもよい。

コンピュータ命令は、コンピュータ可読記憶媒体に記憶され得るし、またはコンピュータ可読記憶媒体から別のコンピュータ可読記憶媒体に送信され得る。例えば、コンピュータ命令は、Webサイト、コンピュータ、サーバ、またはデータセンタから別のWebサイト、コンピュータ、サーバ、またはデータセンタに有線または無線方式で送信されてもよい。

本明細書の実施形態における同じまたは同様の部分については、相互参照されたい。特に、メディアストリーム送信装置の実施形態は、方法の実施形態と基本的に同様であり、したがって、簡単に説明されている。関連する部分については、方法の実施形態の説明を参照されたい。

当業者は、本発明の実施形態の技術が、必要な一般的なハードウェアプラットフォームに加えてソフトウェアによって実施され得ることを明確に理解し得る。そのような理解に基づいて、本発明の実施形態の技術的解決策は本質的に、または従来技術に寄与する部分は、ソフトウェア製品の形態で実施され得る。コンピュータソフトウェア製品は、ROM／RAM、磁気ディスク、または光ディスクなどの記憶媒体に記憶され得、本発明の実施形態または実施形態の一部で説明された方法を実行するようにコンピュータデバイス（パーソナルコンピュータ、サーバ、またはネットワークデバイスなどであり得る）に示すためのいくつかの命令を含む。

本明細書の実施形態における同じまたは同様の部分については、相互参照されたい。特に、同期キャリア周波数信号送信装置および同期キャリア周波数信号受信装置の実施形態は、方法の実施形態と基本的に同様であり、したがって、簡単に説明されている。関連する部分については、方法の実施形態の説明を参照されたい。

加えて、本出願の説明では、「複数の」は、別段の指定がない限り、2つまたは2つより多くのを意味する。加えて、本出願の実施形態の技術的解決策の明確な説明の便宜上、「第1の」および「第2の」などの用語は、機能および目的が基本的に同じである同じ対象または同様の対象を区別するために使用される。当業者は、「第1の」および「第2の」などの用語が数または実行順序を限定せず、「第1の」および「第2の」などの用語が明確な違いを示さないことを理解し得る。

本出願の前述の実施態様は、本出願の保護範囲に対するいかなる制限も構成しない。

10 トランシーバ
20 プロセッサ
30 メモリ
101 コンテンツソース
102 企業データセンタ
103 地域データセンタ
104 プロキシクライアント
105 第1のクライアント
106 第2のクライアント
107 第3のクライアント
901 受信ユニット
902 処理ユニット
903 送信ユニット
1001 受信機
1002 送信機
1003 アンテナ

この態様で提供される方法によれば、同じプロキシクライアントを介してライブブロードキャストルームに入室するすべてのユーザに関して、プロキシサーバは、1つのライブメディアストリームのみをプロキシクライアントに送信する必要があり、すなわち、プロキシクライアントは、プロキシサーバによって送信された1つのライブメディアストリームを受信するために広域ネットワーク帯域幅を消費する。メディアサーバがライブブロードキャストルーム内の各クライアントにライブメディアストリームを送信するときに占有される送信リソースと比較して、これは、WANネットワークリンク負荷を低減し、送信オーバヘッドを低減する。

プロキシサーバは、ユーザのビデオベアラプロトコルのプロキシとして機能し、プロキシサーバを介してライブブロードキャストルームに入室したすべてのクライアントの役割を識別し、メディアサーバから少なくとも1つのライブメディアストリームを取得し、マスタユーザとして機能するクライアントのライブメディアストリームをプロキシクライアントに送信するように構成される。加えて、役割がマスタユーザであるクライアントがライブブロードキャストルームから退室するとき、プロキシサーバは、ライブブロードキャストルーム内の他のユーザの役割を更新し、ライブメディアストリームを新しいライブメディアストリームに切り替えるようにさらに構成される。プロキシクライアントは、ユーザのビデオベアラプロトコルのプロキシとして機能し、プロキシサーバによって送信された、役割がマスタユーザであるクライアントのライブメディアストリームを受信し、ライブメディアストリームを複製し、プロキシクライアントを介してライブブロードキャストルームに入室する、ライブブロードキャストルーム内のすべてのクライアントに複製されたライブメディアストリームを配信するように構成される。

本方法は、プロキシクライアントが、第1のライブブロードキャストルーム要求メッセージを受信したときに、第1のクライアントのステータスを動作中（working）としてマークし、プロキシクライアントが、第2のライブブロードキャストルーム要求メッセージを受信したときに、第2のクライアントのステータスを動作中としてマークし、プロキシクライアントが、第1のクライアントによって送信された、ライブブロードキャストルームからの退室に関する要求メッセージを受信したときに、第1のクライアントのステータスを退室中（exiting）としてマークすることをさらに含む。加えて、プロキシクライアントは、「ライブブロードキャストルームユーザ関係テーブル」に対して第1のクライアントのステータスマークを更新する。

S2：EDC内のメディアサーバは、第1のライブメディアストリームを受信し、第1のライブメディアストリームを下位レベルのRDC内のメディアサーバに送信する。第1のライブメディアストリームが送信される前に、本方法は、EDC内のWebサーバが下位レベルのRDC内のメディアサーバを認証し、EDC内のメディアサーバが、認証が成功した場合にのみ、第1のライブメディアストリームを下位レベルのRDC内のメディアサーバに送信するステップをさらに含む。

S7：プロキシクライアントは、クライアントC1によって送信された第1のライブブロードキャストルーム要求メッセージを受信し、クライアントC1のステータスを動作中（working）の状態に設定する。また、プロキシクライアントは、「ライブブロードキャストルームユーザ関係テーブル」を構築し、ライブブロードキャストルームユーザ関係テーブルにクライアントC1に関するエントリを追加する。具体的には、エントリのコンテンツは、クライアントC1のIPアドレス、ポート番号、ユーザステータス、およびユーザ名、RDC内の選択されたターゲットメディアサーバのIPアドレスおよびポート番号、ならびにライブブロードキャストルームの名前などの情報を含む。クライアントC1のユーザステータスはworkingである。クライアントC1のIPアドレスは、データベースに記憶されているプライマリキー（primary key）であってもよい。

S23：プロキシクライアントは、クライアントC2によって送信された第2のライブブロードキャストルーム要求メッセージを受信し、クライアントC2のステータスを動作中（Working）の状態に設定する。また、プロキシクライアントは、クライアントC2に関するエントリを「ライブブロードキャストルームユーザ関係テーブル」に追加する。具体的には、エントリのコンテンツは、クライアントC2のIPアドレス、ポート番号、ユーザステータス、およびユーザ名、RDC内の選択されたターゲットメディアサーバのIPアドレスおよびポート番号、ならびにライブブロードキャストルームの名前などの情報を含む。クライアントC2のユーザステータスはworkingである。クライアントC2のIPアドレスは、データベースに記憶されているプライマリキー（primary key）であってもよい。

S41：ライブブロードキャストルームからの退室に関する要求メッセージを受信した後、プロキシクライアントは、クライアントC1のステータスを退室中（Exiting）ユーザとしてマークし、退室中ユーザの役割を「ライブブロードキャストルームユーザ関係テーブル」に記録する。

S43：ライブブロードキャストルームからの退室に関する要求メッセージを受信した後、プロキシサーバは、この時点では、マスタユーザとして機能するクライアントC1によって要求された第1のライブメディアストリームがクライアントC2によって視聴されているため、一時的に、ライブブロードキャストルームからの退室に関する要求メッセージをメディアサーバに転送しない。加えて、クライアントC1のステータスは、退室中（Exiting）ユーザとしてマークされ、「ライブブロードキャストルームユーザ関係テーブル」に記録される。

S44：プロキシクライアントは、第3のライブブロードキャストルーム要求メッセージを受信し、クライアントC3のステータスを動作中の（Working）状態に設定する。加えて、プロキシクライアントは、「ライブブロードキャストルームユーザ関係テーブル」を更新し、クライアントC3に関するエントリをライブブロードキャストルームユーザ関係テーブルに追加する。具体的には、エントリのコンテンツは、クライアントC3のIPアドレス、ポート番号、ユーザステータス、およびユーザ名、RDC内の選択されたターゲットメディアサーバのIPアドレスおよびポート番号、ならびにライブブロードキャストルームの名前などの情報を含む。クライアントC3のユーザステータスはWorkingである。加えて、エントリは、プロキシクライアントの識別子、例えば、プロキシクライアントのIPアドレスおよびポート番号をさらに含む。

S73の後、クライアントC2がライブブロードキャストルームからの退室を要求するプロセスは、クライアントC2が、ライブブロードキャストルームからの退室に関する要求メッセージをプロキシクライアントに送信し、ライブブロードキャストルームからの退室に関する要求メッセージを受信した後、プロキシクライアントが、クライアントC2のステータスを退室中ユーザとしてマークし、ライブブロードキャストルームからの退室に関する要求メッセージをプロキシサーバに転送し、ライブブロードキャストルームからの退室に関する要求メッセージを受信した後、プロキシサーバが、「ライブブロードキャストルームユーザ関係テーブル」においてクライアントC2のステータスを退室中ユーザとしてリフレッシュすることを含む。この場合、クライアントC3は、依然としてライブブロードキャストルーム内におり、ライブメディアストリームを取得し、プロキシサーバは、メディアサーバによって送信された第3のライブメディアストリームを受信し、第3のライブメディアストリームは、クライアントC3に送信されるメディアストリームである。この場合、クライアントC3の役割は、セカンダリマスタユーザからメインマスタユーザに変更される。したがって、プロキシサーバは、GOPによって第3のライブメディアストリームをローカルにキャッシュする。

前述の実施形態1および実施形態2では、同じプロキシクライアントを介してライブブロードキャストルームに入室したすべてのクライアントとプロキシサーバとが、各クライアントの役割を識別し、ライブメディアストリームを配信することに留意されたい。加えて、別のケースもある。複数のプロキシクライアントは、同じプロキシサーバにアクセスする。複数のプロキシクライアントを介して同じライブブロードキャストルームに入室したすべてのクライアントに関して、プロキシサーバは、複数のプロキシクライアントを介してライブブロードキャストルームに入室したすべてのクライアントに関してユーザの役割を集合的に識別する。例えば、3つのプロキシクライアントが同じプロキシサーバにアクセスする場合、プロキシサーバは、ライブブロードキャストルーム内のすべてのクライアントに関してマスタユーザおよびスレーブユーザを集中的に識別し、識別された役割に基づいてライブメディアストリームを各プロキシクライアントに送信する。さらに、プロキシサーバがユーザの役割を識別し、ライブメディアストリームを各プロキシクライアントに送信し、各プロキシクライアントが、ライブメディアストリームを複製し、プロキシクライアントにアクセスしたすべてのクライアントにライブメディアストリームのコピーを配信するプロセスは、実施形態1および実施形態2の方法におけるプロセスである。ここでは詳細は再び説明されない。

任意選択で、この実施形態のさらに別の特定の実施態様では、受信ユニット901は、第1のクライアントから、ライブブロードキャストルームからの退室に関する要求メッセージを受信するようにさらに構成される。処理ユニット902は、第2のクライアントを新しいメインマスタユーザとして決定したときに、第2のクライアントの役割をスレーブユーザからマスタユーザに変更し、第1のIフレームおよび第2のIフレームに基づいて、第1のライブメディアストリームおよび第2のライブメディアストリームにそれぞれ属する、互いに隣接する第1の切り替えフレームおよび第2の切り替えフレームを決定し、第1の切り替えフレームおよび第2の切り替えフレームに基づいて、第2のクライアントに送信される第1のライブメディアストリームを第2のライブメディアストリームに切り替え、第2のクライアントに送信される第1のライブメディアストリームの最後のフレームは第1の切り替えフレームであり、第1のクライアントに送信される第2のライブメディアストリームの最初のフレームは第2の切り替えフレームである、ようにさらに構成される。

任意選択で、この実施形態の特定の実施態様では、処理ユニット902は、第1のライブブロードキャストルーム要求メッセージが受信されたときに、第1のクライアントのステータスを動作中としてマークし、第2のライブブロードキャストルーム要求メッセージが受信されたときに、第2のクライアントのステータスを動作中としてマークし、ライブブロードキャストルームからの退室に関する要求メッセージが受信されたときに、第1のクライアントのステータスを退室中としてマークするようにさらに構成される。

Claims

メディアストリーム送信方法であって、前記方法は、ライブブロードキャストルームに入室したクライアントにライブメディアストリームを提供し、前記方法は、
同じプロキシクライアントによって送信された、前記ライブブロードキャストルームへの入室を要求するために使用される第1のライブブロードキャストルーム要求メッセージおよび第2のライブブロードキャストルーム要求メッセージを、プロキシサーバによって受信するステップであって、前記第1のライブブロードキャストルーム要求メッセージは第1のクライアントからのものであり、前記第2のライブブロードキャストルーム要求メッセージは第2のクライアントからのものである、ステップと、
前記プロキシサーバを介してメディアサーバによって前記第1のクライアントに送信された第1のライブメディアストリームと、前記プロキシサーバを介して前記メディアサーバによって前記第2のクライアントに送信された第2のライブメディアストリームとを、前記プロキシサーバによって受信するステップと、
前記プロキシサーバによって、前記第1のライブブロードキャストルーム要求メッセージに基づいて前記第1のクライアントの役割を判定し、前記第2のライブブロードキャストルーム要求メッセージに基づいて前記第2のクライアントの役割を判定するステップと、
前記第1のクライアントの前記役割はマスタユーザであり、前記第2のクライアントの前記役割はスレーブユーザであると判定した場合、前記プロキシクライアントが前記第1のライブメディアストリームを前記第1のクライアントおよび前記第2のクライアントに送信するようにするために、前記プロキシサーバによって前記第1のライブメディアストリームのみを前記プロキシクライアントに送信するステップと
を含む、メディアストリーム送信方法。
前記第1のライブブロードキャストルーム要求メッセージは、前記プロキシクライアントの識別子を含み、前記第2のライブブロードキャストルーム要求メッセージは、前記プロキシクライアントの前記識別子を含み、
前記方法は、前記プロキシサーバによって、前記第1のライブブロードキャストルーム要求メッセージに含まれる前記プロキシクライアントの前記識別子および前記第2のライブブロードキャストルーム要求メッセージに含まれる前記プロキシクライアントの前記識別子に基づいて、前記第1のライブブロードキャストルーム要求メッセージと前記第2のライブブロードキャストルーム要求メッセージとが前記同じプロキシクライアントからのものであると判定するステップをさらに含む、請求項1に記載の方法。
前記プロキシサーバによって、前記第2のライブブロードキャストルーム要求メッセージに基づいて前記第2のクライアントの役割を判定する前記ステップは、
前記第2のライブブロードキャストルーム要求メッセージが受信されたときに、前記プロキシサーバによって、前記プロキシクライアントを介して前記ライブブロードキャストルームに入室した、役割が前記ライブブロードキャストルーム内のマスタユーザであるクライアントが前記ライブブロードキャストルーム内に存在するかどうかを判定するステップと、
前記プロキシクライアントを介して前記ライブブロードキャストルームに入室した、役割が前記ライブブロードキャストルーム内のマスタユーザであるクライアントが前記ライブブロードキャストルーム内に存在する場合、前記第2のクライアントの前記役割は前記スレーブユーザであると判定するステップと
を含む、請求項1または2に記載の方法。
前記プロキシサーバによって前記第1のライブメディアストリームを前記プロキシクライアントに送信する前記ステップの後に、前記方法は、
前記プロキシクライアントによって送信された、前記ライブブロードキャストルームからの退室に関する要求メッセージを、前記プロキシサーバによって受信するステップであって、前記ライブブロードキャストルームからの退室に関する前記要求メッセージは、前記第1のクライアントが前記ライブブロードキャストルームから退室することを要求するために使用される、ステップと、
前記第2のクライアントを新しいマスタユーザとして決定したときに、前記プロキシサーバによって、前記第2のクライアントの前記役割を前記スレーブユーザからマスタユーザに変更するステップと、
前記第2のクライアントに送信される前記第1のライブメディアストリームを、前記プロキシサーバによって前記第2のライブメディアストリームに切り替えるステップと
をさらに含む、請求項3に記載の方法。
前記プロキシサーバによって前記第2のクライアントに送信される前記第1のライブメディアストリームの最後のフレームと、前記プロキシサーバによって前記第2のクライアントに送信される前記第2のライブメディアストリームの最初のフレームとは隣接フレームであり、
前記第2のクライアントに送信される前記第1のライブメディアストリームを、前記プロキシサーバによって前記第2のライブメディアストリームに切り替える前記ステップの前に、前記方法は、
前記プロキシサーバによって、前記第1のライブメディアストリームおよび前記第2のライブメディアストリームに基づいて、前記第1のライブメディアストリームおよび前記第2のライブメディアストリームにそれぞれ属する第1のIフレームおよび第2のIフレームを識別するステップであって、前記第1のIフレームと前記第2のIフレームとは同じビデオフレームである、ステップと、
前記プロキシサーバによって、前記第1のIフレームおよび前記第2のIフレームに基づいて、前記第1のライブメディアストリームおよび前記第2のライブメディアストリームにそれぞれ属する、互いに隣接する第1の切り替えフレームおよび第2の切り替えフレームを決定し、前記第1の切り替えフレームおよび前記第2の切り替えフレームを、それぞれ、前記第2のクライアントに送信される前記第1のライブメディアストリームの前記最後のフレームおよび前記第1のクライアントに送信される前記第2のライブメディアストリームの前記最初のフレームとして使用するステップと
をさらに含み、前記プロキシサーバが前記第1の切り替えフレームおよび前記第2の切り替えフレームを決定した後に、前記方法は、前記プロキシサーバによって、前記ライブブロードキャストルームからの退室に関する、前記第1のクライアントからの前記要求メッセージを前記メディアサーバに転送するステップをさらに含む、請求項4に記載の方法。
前記第2のライブブロードキャストルーム要求メッセージに基づいて前記第2のクライアントの役割を判定する前記ステップは、
前記第2のライブブロードキャストルーム要求メッセージが受信されたときに、前記プロキシサーバによって、前記プロキシクライアントを介して前記ライブブロードキャストルームに入室した、役割がマスタユーザであるクライアントの数が事前設定上限に達しているかどうかを判定するステップであって、前記事前設定上限は2以上である、ステップと、
前記プロキシクライアントを介して前記ライブブロードキャストルームに入室した、役割がマスタユーザである前記クライアントの前記数が前記事前設定上限に達している場合、前記第2のクライアントの前記役割は前記スレーブユーザであると判定するステップと
を含む、請求項1または2に記載の方法。
前記方法は、
役割が前記ライブブロードキャストルーム内のマスタユーザである前記クライアントの前記数が0ではなく、前記事前設定上限に達していない場合、前記第2のクライアントの前記役割はセカンダリマスタユーザであると判定するステップ
をさらに含む、請求項6に記載の方法。
前記第1のクライアントがメインマスタユーザであり、前記第2のクライアントが前記スレーブユーザである場合に、前記方法は、
前記プロキシサーバによって前記第1のクライアントから、前記ライブブロードキャストルームからの退室に関する要求メッセージを受信するステップと、
前記第2のクライアントを新しいセカンダリマスタユーザとして決定したときに、前記プロキシサーバによって、前記第2のクライアントの前記役割を前記スレーブユーザからセカンダリマスタユーザに変更するステップと、
前記プロキシサーバによって、前記受信された第2のライブメディアストリームをグループオブピクチャGOPによりキャッシュするステップと
をさらに含む、請求項6に記載の方法。
前記第1のクライアントがメインマスタユーザであり、前記第2のクライアントが前記セカンダリマスタユーザである場合に、前記方法は、
前記プロキシサーバによって、前記受信された第2のライブメディアストリームをGOPによりキャッシュするステップと、
前記プロキシサーバによって、前記第1のライブメディアストリームおよび前記キャッシュされた第2のライブメディアストリームに基づいて、前記第1のライブメディアストリームおよび前記第2のライブメディアストリームにそれぞれ属する第1のIフレームおよび第2のIフレームを識別するステップであって、前記第1のIフレームと前記第2のIフレームとは同じビデオフレームである、ステップと
をさらに含む、請求項7に記載の方法。
前記方法は、
前記プロキシサーバによって前記第1のクライアントから、前記ライブブロードキャストルームからの退室に関する要求メッセージを受信するステップと、
前記第2のクライアントを新しいメインマスタユーザとして決定したときに、前記プロキシサーバによって、前記第2のクライアントの前記役割を前記セカンダリマスタユーザからメインマスタユーザに変更するステップと、
前記プロキシサーバによって、前記第1のIフレームおよび前記第2のIフレームに基づいて、前記第1のライブメディアストリームおよび前記第2のライブメディアストリームにそれぞれ属する、互いに隣接する第1の切り替えフレームおよび第2の切り替えフレームを決定するステップと、
前記プロキシサーバによって、前記第1の切り替えフレームおよび前記第2の切り替えフレームに基づいて、前記第2のクライアントに送信される前記第1のライブメディアストリームを前記第2のライブメディアストリームに切り替えるステップであって、前記プロキシサーバによって前記第2のクライアントに送信される前記第1のライブメディアストリームの最後のフレームは、前記第1の切り替えフレームであり、前記プロキシサーバによって前記第1のクライアントに送信される前記第2のライブメディアストリームの前記最初のフレームは、前記第2の切り替えフレームである、ステップと
をさらに含む、請求項9に記載の方法。
前記方法は、
前記プロキシサーバによって、前記第1のライブメディアストリームをGOPによりキャッシュするステップ
をさらに含む、請求項1から10のいずれか一項に記載の方法。
メディアストリーム送信方法であって、前記方法は、ライブブロードキャストルームに入室したクライアントにライブメディアストリームを提供し、前記方法は、
第1のクライアントによって送信された、ライブブロードキャストルームへの入室を要求するために使用される第1のライブブロードキャストルーム要求メッセージと、第2のクライアントによって送信された、前記ライブブロードキャストルームへの入室を要求するために使用される第2のライブブロードキャストルーム要求メッセージとを、プロキシクライアントによって受信するステップと、
前記プロキシクライアントによって、プロキシサーバを介して前記第1のライブブロードキャストルーム要求メッセージおよび前記第2のライブブロードキャストルーム要求メッセージをメディアサーバに送信するステップと、
前記プロキシサーバによって送信された第1のライブメディアストリームを、前記プロキシクライアントによって受信するステップであって、前記第1のライブメディアストリームは、前記プロキシサーバを介して前記メディアサーバによって前記第1のクライアントに送信されたメディアストリームであり、前記第1のクライアントの役割はマスタユーザであり、前記第2のクライアントの役割はスレーブユーザである、ステップと、
前記プロキシクライアントによって、前記第1のライブメディアストリームを前記第1のクライアントおよび前記第2のクライアントに送信するステップと
を含む、メディアストリーム送信方法。
プロキシクライアントによって、プロキシサーバを介して前記第1のライブブロードキャストルーム要求メッセージをメディアサーバに送信する前記ステップの前に、前記方法は、前記プロキシクライアントによって、前記プロキシクライアントの識別子を前記第1のライブブロードキャストルーム要求メッセージに追加するステップをさらに含み、
前記プロキシクライアントによって、プロキシサーバを介して前記第2のライブブロードキャストルーム要求メッセージをメディアサーバに送信する前記ステップの前に、前記方法は、前記プロキシクライアントによって、前記プロキシクライアントの前記識別子を前記第2のライブブロードキャストルーム要求メッセージに追加するステップをさらに含む、請求項12に記載の方法。
前記プロキシサーバによって送信された第1のライブメディアストリームを、前記プロキシクライアントによって受信する前記ステップの後に、前記方法は、
前記プロキシクライアントによって、前記第1のライブメディアストリームをグループオブピクチャGOPによりキャッシュするステップ
をさらに含む、請求項12または13に記載の方法。
前記プロキシクライアントによって、前記第1のライブメディアストリームを前記第2のクライアントに送信する前記ステップの前に、前記方法は、
調整されたタイムスタンプが、前記プロキシクライアントによって前記第2のクライアントに送信される前記第1のライブメディアストリームの最初のフレームのタイムスタンプが0であり、前記プロキシクライアントによって前記第2のクライアントに送信される前記第1のライブメディアストリームの隣接フレームのタイムスタンプが連続することを満たすように、前記プロキシクライアントによって、前記第1のライブメディアストリームのタイムスタンプを調整するステップ
をさらに含む、請求項12から14のいずれか一項に記載の方法。
前記第1のクライアントが前記ライブブロードキャストルームからの退室を要求したときに、前記方法は、
前記プロキシサーバによって送信された第2のライブメディアストリームを、前記プロキシクライアントによって受信するステップであって、前記第2のライブメディアストリームは、前記プロキシクライアントを介して前記メディアサーバによって前記第2のクライアントに送信されたメディアストリームであり、前記第2のクライアントは、役割が前記スレーブユーザからマスタユーザに変更されたクライアントである、ステップと、
前記プロキシクライアントによって、前記第2のライブメディアストリームを前記第2のクライアントに送信するステップと
をさらに含む、請求項12から15のいずれか一項に記載の方法。
前記プロキシクライアントによって、前記第2のライブメディアストリームを前記第2のクライアントに送信する前記ステップの前に、前記方法は、
調整されたタイムスタンプが、前記プロキシクライアントによって前記第2のクライアントに送信される前記第2のライブメディアストリームの前記最初のフレームと、前記プロキシクライアントによって前記第2のクライアントに送信される前記第1のライブメディアストリームの最後のフレームとのタイムスタンプが連続することを満たすように、前記プロキシクライアントによって、前記第2のライブメディアストリームのタイムスタンプを調整するステップ
をさらに含む、請求項16に記載の方法。
メディアストリーム送信装置であって、前記装置は、
同じプロキシクライアントによって送信された、ライブブロードキャストルームへの入室を要求するために使用される第1のライブブロードキャストルーム要求メッセージおよび第2のライブブロードキャストルーム要求メッセージを受信し、前記第1のライブブロードキャストルーム要求メッセージは第1のクライアントからのものであり、前記第2のライブブロードキャストルーム要求メッセージは第2のクライアントからのものである、ように構成された受信ユニットであって、
前記受信ユニットは、前記プロキシサーバを介してメディアサーバによって前記第1のクライアントに送信された第1のライブメディアストリームと、前記プロキシサーバを介して前記メディアサーバによって前記第2のクライアントに送信された第2のライブメディアストリームとを受信するようにさらに構成されている、受信ユニットと、
前記第1のライブブロードキャストルーム要求メッセージに基づいて前記第1のクライアントの役割を判定し、前記第2のライブブロードキャストルーム要求メッセージに基づいて前記第2のクライアントの役割を判定するように構成された処理ユニットと、
前記第1のクライアントの前記役割はマスタユーザであり、前記第2のクライアントの前記役割はスレーブユーザであると判定された場合に、前記プロキシクライアントが前記第1のライブメディアストリームを前記第1のクライアントおよび前記第2のクライアントに送信するようにするために、前記第1のライブメディアストリームのみを前記プロキシクライアントに送信するように構成された送信ユニットと
を備える、メディアストリーム送信装置。
前記第1のライブブロードキャストルーム要求メッセージは、前記プロキシクライアントの識別子を含み、前記第2のライブブロードキャストルーム要求メッセージは、前記プロキシクライアントの前記識別子を含み、
前記処理ユニットは、前記第1のライブブロードキャストルーム要求メッセージに含まれる前記プロキシクライアントの前記識別子および前記第2のライブブロードキャストルーム要求メッセージに含まれる前記プロキシクライアントの前記識別子に基づいて、前記第1のライブブロードキャストルーム要求メッセージと前記第2のライブブロードキャストルーム要求メッセージとが前記同じプロキシクライアントからのものであると判定するようにさらに構成されている、請求項18に記載の装置。
前記処理ユニットは、前記第2のライブブロードキャストルーム要求メッセージが受信されたときに、前記プロキシクライアントを介して前記ライブブロードキャストルームに入室した、役割が前記ライブブロードキャストルーム内のマスタユーザであるクライアントが前記ライブブロードキャストルーム内に存在するかどうかを判定し、前記プロキシクライアントを介して前記ライブブロードキャストルームに入室した、役割が前記ライブブロードキャストルーム内のマスタユーザであるクライアントが前記ライブブロードキャストルーム内に存在する場合、前記第2のクライアントの前記役割は前記スレーブユーザであると判定するように特に構成されている、
請求項18または19に記載の装置。
前記受信ユニットは、前記第1のライブメディアストリームが前記プロキシクライアントに送信された後に、前記プロキシクライアントによって送信された、前記ライブブロードキャストルームからの退室に関する要求メッセージを受信し、前記ライブブロードキャストルームからの退室に関する前記要求メッセージは、前記第1のクライアントが前記ライブブロードキャストルームから退室することを要求するために使用される、ようにさらに構成されており、
前記処理ユニットは、前記第2のクライアントを新しいマスタユーザとして決定したときに、前記第2のクライアントの前記役割を前記スレーブユーザからマスタユーザに変更し、前記第2のクライアントに送信される前記第1のライブメディアストリームを前記第2のライブメディアストリームに切り替えるようにさらに構成されている、
請求項20に記載の装置。
前記第2のクライアントに送信される前記第1のライブメディアストリームの最後のフレームと、前記第2のクライアントに送信される前記第2のライブメディアストリームの最初のフレームとは隣接フレームであり、
前記処理ユニットは、前記第1のライブメディアストリームおよび前記第2のライブメディアストリームに基づいて、前記第1のライブメディアストリームおよび前記第2のライブメディアストリームにそれぞれ属する第1のIフレームおよび第2のIフレームを識別し、前記第1のIフレームと前記第2のIフレームとは同じビデオフレームであり、前記第1のIフレームおよび前記第2のIフレームに基づいて、前記第1のライブメディアストリームおよび前記第2のライブメディアストリームにそれぞれ属する、互いに隣接する第1の切り替えフレームおよび第2の切り替えフレームを決定し、前記第1の切り替えフレームおよび前記第2の切り替えフレームを、それぞれ、前記第2のクライアントに送信される前記第1のライブメディアストリームの前記最後のフレームおよび前記第1のクライアントに送信される前記第2のライブメディアストリームの前記最初のフレームとして使用するようにさらに構成されており、
前記送信ユニットは、前記第1の切り替えフレームおよび前記第2の切り替えフレームが決定された後に、前記ライブブロードキャストルームからの退室に関する、前記第1のクライアントからの前記要求メッセージを前記メディアサーバに転送するようにさらに構成されている、請求項21に記載の装置。
前記処理ユニットは、前記第2のライブブロードキャストルーム要求メッセージが受信されたときに、前記プロキシクライアントを介して前記ライブブロードキャストルームに入室した、役割がマスタユーザであるクライアントの数が事前設定上限に達しているかどうかを判定し、前記事前設定上限は2以上であり、前記プロキシクライアントを介して前記ライブブロードキャストルームに入室した、役割がマスタユーザである前記クライアントの前記数が前記事前設定上限に達している場合、前記第2のクライアントの前記役割は前記スレーブユーザであると判定するように特に構成されている、
請求項18または19に記載の装置。
前記処理ユニットは、役割が前記ライブブロードキャストルーム内のマスタユーザである前記クライアントの前記数が0ではなく、前記事前設定上限に達していない場合、前記第2のクライアントの前記役割はセカンダリマスタユーザであると判定するようにさらに構成されている、
請求項23に記載の装置。
前記装置は記憶ユニットをさらに備え、前記第1のクライアントがメインマスタユーザであり、前記第2のクライアントが前記スレーブユーザである場合に、
前記受信ユニットは、前記第1のクライアントから、前記ライブブロードキャストルームからの退室に関する要求メッセージを受信するようにさらに構成されており、
前記処理ユニットは、前記第2のクライアントを新しいセカンダリマスタユーザとして決定したときに、前記第2のクライアントの前記役割を前記スレーブユーザからセカンダリマスタユーザに変更するようにさらに構成されており、
前記記憶ユニットは、前記受信された第2のライブメディアストリームをグループオブピクチャGOPによりキャッシュするように構成されている、請求項23に記載の装置。
前記装置は記憶ユニットをさらに備え、前記第1のクライアントがメインマスタユーザであり、前記第2のクライアントが前記セカンダリマスタユーザである場合に、
前記記憶ユニットは、前記受信された第2のライブメディアストリームをGOPによりキャッシュするように構成されており、
前記処理ユニットは、前記第1のライブメディアストリームおよび前記キャッシュされた第2のライブメディアストリームに基づいて、前記第1のライブメディアストリームおよび前記第2のライブメディアストリームにそれぞれ属する第1のIフレームおよび第2のIフレームを識別し、前記第1のIフレームと前記第2のIフレームとは同じビデオフレームである、ように構成されている、請求項24に記載の装置。
前記受信ユニットは、前記第1のクライアントから、前記ライブブロードキャストルームからの退室に関する要求メッセージを受信するようにさらに構成されており、
前記処理ユニットは、前記第2のクライアントを新しいメインマスタユーザとして決定したときに、前記第2のクライアントの役割を前記セカンダリマスタユーザからメインマスタユーザに変更し、前記第1のIフレームおよび前記第2のIフレームに基づいて、前記第1のライブメディアストリームおよび前記第2のライブメディアストリームにそれぞれ属する、互いに隣接する第1の切り替えフレームおよび第2の切り替えフレームを決定し、前記第1の切り替えフレームおよび前記第2の切り替えフレームに基づいて、前記第2のクライアントに送信される前記第1のライブメディアストリームを前記第2のライブメディアストリームに切り替え、
前記第2のクライアントに送信される前記第1のライブメディアストリームの最後のフレームは、前記第1の切り替えフレームであり、前記第1のクライアントに送信される前記第2のライブメディアストリームの前記最初のフレームは、前記第2の切り替えフレームである、ようにさらに構成されている、
請求項26に記載の装置。
前記装置は、
前記第1のライブメディアストリームをGOPによりキャッシュするように構成された前記記憶ユニット
をさらに備える、請求項18から27のいずれか一項に記載の装置。
メディアストリーム送信装置であって、前記装置は、
第1のクライアントによって送信された、ライブブロードキャストルームへの入室を要求するために使用される第1のライブブロードキャストルーム要求メッセージと、第2のクライアントによって送信された、前記ライブブロードキャストルームへの入室を要求するために使用される第2のライブブロードキャストルーム要求メッセージとを受信するように構成された受信ユニットと、
プロキシサーバを介して前記第1のライブブロードキャストルーム要求メッセージおよび前記第2のライブブロードキャストルーム要求メッセージをメディアサーバに送信するように構成された送信ユニットと
を備え、前記受信ユニットは、前記プロキシサーバによって送信された第1のライブメディアストリームを受信し、前記第1のライブメディアストリームは、前記プロキシサーバを介して前記メディアサーバによって前記第1のクライアントに送信されたメディアストリームであり、前記第1のクライアントの役割はマスタユーザであり、前記第2のクライアントの役割はスレーブユーザである、ようにさらに構成されており、
前記送信ユニットは、前記第1のライブメディアストリームを前記第1のクライアントおよび前記第2のクライアントに送信するようにさらに構成されている、メディアストリーム送信装置。
前記装置は処理ユニットをさらに備え、
前記処理ユニットは、前記第1のライブブロードキャストルーム要求メッセージが送信される前に、前記プロキシクライアントの識別子を前記第1のライブブロードキャストルーム要求メッセージに追加し、前記第2のライブブロードキャストルーム要求メッセージが送信される前に、前記プロキシクライアントの前記識別子を前記第2のライブブロードキャストルーム要求メッセージに追加するように構成されている、請求項29に記載の装置。
前記装置は記憶ユニットをさらに備え、
前記記憶ユニットは、前記第1のライブメディアストリームをグループオブピクチャGOPによりキャッシュするように構成されている、請求項29または30に記載の装置。
前記処理ユニットは、前記第1のライブメディアストリームが前記第2のクライアントに送信される前に、調整されたタイムスタンプが、前記第2のクライアントに送信される前記第1のライブメディアストリームの前記最初のフレームのタイムスタンプが0であり、前記第2のクライアントに送信される前記第1のライブメディアストリームの隣接フレームのタイムスタンプが連続することを満たすように、前記第1のライブメディアストリームのタイムスタンプを調整するよう構成されている、
請求項29から31のいずれか一項に記載の装置。
前記第1のクライアントが前記ライブブロードキャストルームからの退室を要求したときに、
前記受信ユニットは、前記プロキシサーバによって送信された第2のライブメディアストリームを受信し、前記第2のライブメディアストリームは、前記プロキシクライアントを介して前記メディアサーバによって前記第2のクライアントに送信されたメディアストリームであり、前記第2のクライアントは、役割が前記スレーブユーザからマスタユーザに変更されたクライアントである、ようにさらに構成されており、
前記送信ユニットは、前記第2のライブメディアストリームを前記第2のクライアントに送信するようにさらに構成されている、
請求項29から32のいずれか一項に記載の装置。
前記処理ユニットは、前記第2のライブメディアストリームが前記第2のクライアントに送信される前に、調整されたタイムスタンプが、前記第2のクライアントに送信される前記第2のライブメディアストリームの前記最初のフレームと前記第2のクライアントに送信される前記第1のライブメディアストリームの最後のフレームとのタイムスタンプが連続することを満たすように、前記第2のライブメディアストリームのタイムスタンプを調整するようさらに構成されている、
請求項33に記載の装置。
メディアストリーム送信システムであって、前記システムは、少なくとも1つのクライアントと、プロキシクライアントと、プロキシサーバと、メディアサーバとを備え、各前記クライアントは、前記プロキシクライアントを介してライブブロードキャストルームにアクセスし、
前記プロキシクライアントは、請求項12から17のいずれか一項に記載のメディアストリーム送信方法を実行するように構成されており、
前記プロキシサーバは、請求項1から11のいずれか一項に記載のメディアストリーム送信方法を実行するように構成されている、メディアストリーム送信システム。
プロセッサを備えるネットワークデバイスであって、前記プロセッサはメモリに結合されており、
前記メモリは、命令を記憶するように構成されており、
前記プロセッサは、前記ネットワークデバイスが請求項1から17のいずれか一項に記載の方法を実行するように、前記メモリ内の前記命令を実行するよう構成されている、ネットワークデバイス。
コンピュータ可読記憶媒体であって、前記記憶媒体は命令を記憶しており、
前記命令が実行されるとき、請求項1から17のいずれか一項に記載の方法が実施される、コンピュータ可読記憶媒体。