JP7256881B2 - メディア・ストリーム送信方法、装置、デバイス - Google Patents

メディア・ストリーム送信方法、装置、デバイス Download PDF

Info

Publication number
JP7256881B2
JP7256881B2 JP2021540891A JP2021540891A JP7256881B2 JP 7256881 B2 JP7256881 B2 JP 7256881B2 JP 2021540891 A JP2021540891 A JP 2021540891A JP 2021540891 A JP2021540891 A JP 2021540891A JP 7256881 B2 JP7256881 B2 JP 7256881B2
Authority
JP
Japan
Prior art keywords
client
media stream
live
frame
proxy server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2021540891A
Other languages
English (en)
Other versions
JP2022518216A (ja
Inventor
チアオ，ナイチアン
ジュ，シア
ジョウ，ジュン
ブゥ，チィ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of JP2022518216A publication Critical patent/JP2022518216A/ja
Application granted granted Critical
Publication of JP7256881B2 publication Critical patent/JP7256881B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/2187—Live feed
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • H04N21/4331—Caching operations, e.g. of an advertisement for later insertion during playback
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
    • H04L12/1822—Conducting the conference, e.g. admission, detection, selection or grouping of participants, correlating users to one or more conference sessions, prioritising transmission
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
    • H04L12/1818—Conference organisation arrangements, e.g. handling schedules, setting up parameters needed by nodes to attend a conference, booking network resources, notifying involved parties
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/239—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests
    • H04N21/2393—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests involving handling client requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/27—Server based end-user applications
    • H04N21/274—Storing end-user multimedia data in response to end-user request, e.g. network recorder
    • H04N21/2743—Video hosting of uploaded data from client
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/47208—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting near-video-on-demand content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/14—Systems for two-way working
    • H04N7/15—Conference systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2203/00—Aspects of automatic or semi-automatic exchanges
    • H04M2203/50—Aspects of automatic or semi-automatic exchanges related to audio conference
    • H04M2203/5027—Dropping a party from a conference
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2203/00—Aspects of automatic or semi-automatic exchanges
    • H04M2203/50—Aspects of automatic or semi-automatic exchanges related to audio conference
    • H04M2203/5045—Selection of bridge/multipoint control unit
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2203/00—Aspects of automatic or semi-automatic exchanges
    • H04M2203/50—Aspects of automatic or semi-automatic exchanges related to audio conference
    • H04M2203/5081—Inform conference party of participants, e.g. of change of participants
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/2183—Cache memory
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/222—Secondary servers, e.g. proxy server, cable television Head-end
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/8547—Content authoring involving timestamps for synchronizing content

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Human Computer Interaction (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)

Description

本願は、ビデオ再生の分野に関し、特に、メディア・ストリーム送信方法および装置、ならびにデバイスに関する。
ユーザーは、ライブ・ブロードキャスト・モードまたはビデオオンデマンド・モードでビデオを視聴することができる。ビデオオンデマンド・モードでは、ビデオを見るとき、ユーザーはいつでもビデオ・コンテンツを早送りまたは巻き戻しすることができるが、ライブ・ブロードキャスト・モードではビデオ・コンテンツを早送りまたは巻き戻しすることはできない。ライブ・ブロードキャストは、一般に、データのすべてのフレームが時間シーケンスタグでラベル付けされ、次いでストリーミングされるプロセスとして理解されうる。具体的には、カメラやマイクロフォンなどの収集装置が、オーディオまたはビデオ情報を連続的に収集し、次いで該情報に対してエンコード、カプセル化、ストリーム・プッシングなどの処理を実行し、次いで配信ネットワークを通じて該情報を送信する。再生端は、連続的にデータをダウンロードし、該データを再生のために時間シーケンスに基づいてデコードする。ビデオ・ライブ・ブロードキャストの全体的な手順は、収集、エンコード、ストリーム・プッシング、トランスコード、配信、デコード／レンダリングなどの一連のプロセスを含む。
インターネット・ビデオ・ライブ・ブロードキャストの主流ベンダーは、通例、ビデオ伝送のためにユニキャスト伝送プロトコルを使用する。したがって、N人のユーザーがビデオを視聴している場合、Nチャネルのビデオ・ストリームがある。また、企業向けライブ・ビデオ・ブロードキャストについては、呈示された文書を共有したり、テキストコメントを作成したりする機能が、ライブ・ビデオ・ブロードキャストの間にサポートされる必要がある。すなわち、ユーザーの要求を満たし、ユーザー体験を改善するために、ビデオ・コンテンツが企業向けライブ・ブロードキャストのウェブページに表示されている間に、共有される文書およびテキストコメントが表示される。
ユーザー体験を改善し、バックボーン・ネットワーク帯域幅を節約するために、ライブ・コンテンツ配信ネットワーク（content delivery network、CDN）は、典型的には、ライブ・ブロードキャスト・プラットフォーム上で展開される。ライブCDNは分散式のコンテンツ配信プラットフォームであり、多層アーキテクチャーをサポートする。ライブCDNプラットフォームでは、異なる地域のユーザーに近くのサービスを提供するために、キャッシング用のサーバーが種々のレイヤーに展開されることができる。
ライブCDNを用いてオーディオおよびビデオ・ストリームを配信するプロセスにおいて、典型的には、リアルタイムメッセージ転送プロトコルとも称されるリアルタイムメッセージプロトコル（real time messaging protocol、RTMP）が、ビデオ・ストリーム・プッシングおよびストリーム分配プロセスにおいて使用され；典型的には、3つのプロトコル：前記RTMP、HLS（HTTP live streaming［ライブ・ストリーミング］）プロトコル、およびハイパーテキスト転送プロトコル（hyper text transfer protocol、HTTP）‐フラッシュビデオ（flash video、FLV）が、配信プロセスにおいて使用される。ここで、ハイパーテキスト転送プロトコル‐フラッシュビデオは、略して「HTTP-FLV」として参照される。HLSは、Apple社が開発したHTTPベースのストリーミング・メディア伝送プロトコルである。HLSは、iPhone、iPad、iPodタッチ、およびMac OS Xを含むiOSデバイスに主に適用され、オーディオおよびビデオのライブサービスと録画コンテンツ（VOD）サービスを提供する。HLSは、次のような利点をもつ：クライアントが一度に完全なデータストリームを要求するのではなく、サーバー側でストリーミングメディアデータがより短い継続時間をもつより小さなファイルにセグメント分割され、該より小さなファイルがインデックス・ファイルに基づいて順番にアクセスされる。クライアントがサーバーから取得した前記より小さなファイルを連続的かつ順番に再生すれば、オーディオおよびビデオが再生できる。
図1に示されるように、ライブCDNでは、コンテンツ源（content source）が、RTMPを使用して企業データセンター（enterprise data center、EDC）にオーディオおよびビデオ・メディア・ストリームを送信する。ここで、EDCは、ウェブ・サーバー（Web server）および複数のメディア・サーバー（media server）を含む。EDC内のウェブ・サーバーは、クライアントからのライブ・プログラム視聴要求に応答して、ユーザーを認証し、ユーザーの位置に基づいて、ユーザーのためにサービスを提供する最も近いメディア・サーバーを割り当てる。選択されたメディア・サーバーは、オーディオおよびビデオ・メディア・ストリームを、事前設定されたポリシーに従って、下位レベルの地域データセンター（region data center、RDC）に送信する。メディア・ストリーム（ライブ・コンテンツ）を受信した後、RDC内のメディア・サーバーが、事前設定されたポリシーに従って、メディア・ストリームをサーバールーム（server room、SR）内の下位レベルのメディア・サーバーに配信する。最後に、サーバールーム内のメディア・サーバーは、上位レベルのメディア・サーバーによって配信されたメディア・ストリーム（ライブ・コンテンツ）をキャッシュし、ユーザーにライブ・ブロードキャスト・サービスを直接、提供する。
このプロセスにおいて、上位レベルのRDC内のメディア・サーバーは、ライブ・ブロードキャスト・ルーム内のメディア・ストリームを要求する各クライアントにライブ・メディア・ストリームを送信する必要があり、その結果、上位レベルのRDCのメディア・サーバーは、ライブ・メディア・ストリームをライブ・ブロードキャスト・ルーム内の各ユーザーに送信する必要がある。ライブ・ブロードキャスト・ルームに大量のユーザーが入室すると、ライブ・メディア・ストリーム伝送のために大量の広域ネットワーク（wide area network、WAN）資源が必要になり、結果として、ネットワーク・オーバーヘッドが大きくなる。
本願の実施形態は、同じライブ・ブロードキャスト・ルーム内のクライアントに対してメディア・サーバーによってメディア・ストリームを送信するための資源オーバーヘッドを削減するためのメディア・ストリーム送信方法および装置、ならびにデバイスを提供する。具体的には、本願の実施形態は、以下の技術的解決策を開示する。
第1の側面によれば、本願のある実施形態は、メディア・ストリーム送信方法を提供する。この方法は、ライブ・ブロードキャスト・ルームに入るクライアントにライブ・メディア・ストリームを提供する。この方法は：プロキシサーバーが、第1のクライアントから、ライブ・ブロードキャスト・ルームに入ることを要求するための第1のライブ・ブロードキャスト・ルーム要求メッセージを受信し；プロキシサーバーが、第1のライブ・ブロードキャスト・ルーム要求メッセージに基づいて第1のクライアントの役割を決定し；第1のクライアントの役割がスレーブ・ユーザーである場合、プロキシサーバーは、プロキシサーバーにキャッシュされている第1のライブ・メディア・ストリームを第1のクライアントに送信し、第1のライブ・メディア・ストリームは、メディア・サーバーによってプロキシサーバーを介して第2のクライアントに送信されるメディア・ストリームであり、第2のクライアントの役割はマスター・ユーザーである。
この方法では、役割がマスター・ユーザーであるクライアントによって要求されたライブ・メディア・ストリームが、プロキシサーバーによって取得されたとき、プロキシサーバーは、そのメディア・ストリームの一部のセグメントをローカルにキャッシュする。役割がスレーブ・ユーザーであるクライアントがライブ・ブロードキャスト・ルームに入り、ライブ・メディア・ストリームを要求すると、プロキシサーバーは、ローカルにキャッシュされたメディア・ストリームを、役割がスレーブ・ユーザーであるクライアントに直接送信するので、メディア・サーバーは、再びプロキシサーバーにライブ・メディア・ストリームを送信する必要はない。よって、本願の第1の側面において提供される方法によれば、メディア・サーバーは、プロキシサーバーを通じて、ライブ・ブロードキャスト・ルームに入る各クライアントにライブ・メディア・ストリームを送信する必要はない。これは、メディア・ストリームを送信するためのトラフィックを削減し、効果的に出口帯域幅を節約し、資源オーバーヘッドを削減する。
第1の側面を参照するに、第1の側面のある可能な実装では、第1のライブ・ブロードキャスト・ルーム要求メッセージに基づいて第1のクライアントの役割を決定することは：第1のライブ・ブロードキャスト・ルーム要求メッセージが受信されたときに、ライブ・ブロードキャスト・ルーム内に役割がマスター・ユーザーであるクライアントがいるかどうかを判定し；ライブ・ブロードキャスト・ルーム内に役割がマスター・ユーザーであるクライアントがいれば、第1のクライアントの役割がスレーブ・ユーザーであると決定することを含む。
第1の側面を参照するに、第1の側面の別の可能な実装では、プロキシサーバーにキャッシュされている第1のライブ・メディア・ストリームを第1のクライアントに送信する前に、この方法は、さらに：プロキシサーバーが、第1のクライアントから第1のメディア要求メッセージを受信し、第1のメディア要求メッセージをメディア・サーバーに転送することをスキップし；プロキシサーバーが第1のクライアントに第1のメディア応答メッセージを送信し、第1のメディア応答メッセージが、第1のクライアントがメディア・ストリームを取得することを許可されていることを第1のクライアントに通知するために使用される。
第1の側面を参照するに、第1の側面のさらに別の可能な実装では、第1のメディア要求メッセージは、第1のクライアントの識別子を含む。プロキシサーバーが第1のクライアントに第1のライブ・メディア・ストリームを送信した後、この方法はさらに：プロキシサーバーが、第2のクライアントから、ライブ・ブロードキャスト・ルームを退出するための要求メッセージを受信し；第1のクライアントを新しいマスター・ユーザーとして決定するとき、プロキシサーバーは、第1のクライアントの役割をスレーブ・ユーザーからマスター・ユーザーに変更し；プロキシサーバーは、第2のメディア要求メッセージをメディア・サーバーに送信し、第2のメディア要求メッセージは、第1のクライアントの識別子を含み；プロキシサーバーは、第2のメディア要求メッセージに基づいてメディア・サーバーによって送信された第2のライブ・メディア・ストリームを受信し；プロキシサーバーは、第1のクライアントに送信される第1のライブ・メディア・ストリームを第2のライブ・メディア・ストリームに切り換えることを含む。
第1の側面を参照するに、第1の側面のさらに別の可能な実装では、第1のライブ・ブロードキャスト・ルーム要求メッセージに基づいて第1のクライアントの役割を決定することは：プロキシサーバーが、第1のライブ・ブロードキャスト・ルーム要求メッセージを受信したときに、ライブ・ブロードキャスト・ルームにおける、役割がマスター・ユーザーであるクライアントの数が事前設定された上限に達しているかどうかを判定する段階であって、前記事前設定された上限は1より大きい、段階と；ライブ・ブロードキャスト・ルームにおける、役割がマスター・ユーザーであるクライアントの数が事前設定された上限に達していれば、プロキシサーバーが、第1のクライアントの役割がスレーブ・ユーザーであると決定する段階とを実行することを含む。この実装では、複数のマスター・ユーザーが存在するシナリオにおいて、メディア・サーバーは、プロキシサーバーを通じてライブ・ブロードキャスト・ルームに入る各ユーザーのためにプロキシサーバーにライブ・メディア・ストリームを送信する必要はなく、プロキシサーバーは、役割がスレーブ・ユーザーであるクライアントに対しては、マスター・ユーザーによって要求され、プロキシサーバーにキャッシュされているライブ・メディア・ストリームを配信する。これは、メディア・ストリームを送信するためのトラフィックを削減し、資源オーバーヘッドを削減する。
第1の側面を参照するに、第1の側面のさらに別の可能な実装では、ライブ・ブロードキャスト・ルームにおける、役割がマスター・ユーザーであるクライアントの数が0ではないが事前設定された上限には達しない場合、プロキシサーバーは、第1のクライアントの役割が副次マスター・ユーザーであると決定する。
第1の側面を参照するに、第1の側面のさらに別の可能な実装では、第1のクライアントがスレーブ・ユーザーである場合、本方法はさらに：プロキシサーバーが、第2のクライアントから、ライブ・ブロードキャスト・ルームを退出するための要求メッセージを受信し；第1のクライアントを新しい副次マスター・ユーザーとして決定するとき、プロキシサーバーが、第1のクライアントの役割をスレーブ・ユーザーから副次マスター・ユーザーに変更し；プロキシサーバーが、第3のメディア要求メッセージをメディア・サーバーに送信し、第3のメディア要求メッセージが第1のクライアントの識別子を含み；プロキシサーバーが、第3のメディア要求メッセージに基づいて、メディア・サーバーによって送信される第3のライブ・メディア・ストリームを受信することを含む。
第1の側面を参照するに、第1の側面のさらに別の可能な実装では、第2のクライアントが主要マスター・ユーザーであり、第1のクライアントが副次マスター・ユーザーである場合、この方法はさらに：プロキシサーバーが第1のライブ・メディア・ストリームを第1のクライアントに送信することを含む。
第1の側面を参照するに、第1の側面のさらに別の可能な実装では、第1のクライアントが副次マスター・ユーザーである場合、本方法はさらに：プロキシサーバーが第1のクライアントから第4のメディア要求メッセージを受信し；プロキシサーバーが第4のメディア要求メッセージをメディア・サーバーに送信し；プロキシサーバーが第4のメディア要求メッセージに基づいてメディア・サーバーによって送信される第4のライブ・メディア・ストリームを受信することを含む。
第1の側面を参照するに、第1の側面のさらに別の可能な実装では、第1のクライアントが副次マスター・ユーザーである場合、本方法はさらに：プロキシサーバーが、第2のクライアントから、ライブ・ブロードキャスト・ルームを退出するための要求メッセージを受信し；第1のクライアントを新しい主要マスター・ユーザーとして決定する場合、プロキシサーバーが、第1のクライアントの役割を副次マスター・ユーザーから主要マスター・ユーザーに変更し；プロキシサーバーが、第1のクライアントに送信される第1のライブ・メディア・ストリームを第4のライブ・メディア・ストリームに切り換えることを含む。
第1の側面を参照するに、第1の側面のさらに別の可能な実装では、本方法は、さらに：プロキシサーバーが、第4のライブ・メディア・ストリームのタイムスタンプを調整し、調整されたタイムスタンプが、第1のクライアントに送信される第4のライブ・メディア・ストリームの最初のフレームのタイムスタンプと、第1のクライアントに送信される第1のライブ・メディア・ストリームの最後のフレームのタイムスタンプとが連続していることを満たすようにすることを含む。
第1の側面を参照するに、第1の側面のさらに別の可能な実装では、プロキシサーバーによって第1のクライアントに送信される第1のライブ・メディア・ストリームの最後のフレームと、プロキシサーバーによって第1のクライアントに送信される第4のライブ・メディア・ストリームの最初のフレームとは、隣接するフレームである。プロキシサーバーが第1のクライアントに送られる第1のライブ・メディア・ストリームを第4のライブ・メディア・ストリームに切り換える前に、本方法はさらに：プロキシサーバーが、キャッシュされた第1のライブ・メディア・ストリームおよび第4のライブ・メディア・ストリームに基づいて、それぞれ第1のライブ・メディア・ストリームおよび第4のライブ・メディア・ストリームに属する第1のIフレームおよび第2のIフレームを識別し、該第1のIフレームおよび該第2のIフレームは同一のビデオ・フレームであり；プロキシサーバーは、第1のIフレームおよび第2のIフレームに基づいて、互いに隣接し、それぞれ第1のライブ・メディア・ストリームおよび第4のライブ・メディア・ストリームに属する第1の切り換えフレームおよび第2の切り換えフレームを決定し、該第1の切り換えフレームおよび第2の切り換えフレームを、それぞれ、第1のクライアントに送られる第1のライブ・メディア・ストリームの最後のフレームおよび第1のクライアントに送られる第4のライブ・メディア・ストリームの最初のフレームとして使用することを含む。
第1の側面を参照するに、第1の側面のさらに別の可能な実装では、本方法はさらに：プロキシサーバーが、ピクチャーグループGOPごとに第1のライブ・メディア・ストリームをキャッシュすることを含む。
第1の側面を参照するに、第1の側面のさらに別の可能な実装では、プロキシサーバーが第1のクライアントに送信される第1のライブ・メディア・ストリームを第2のライブ・メディア・ストリームに切り換える前に、本方法はさらに：プロキシサーバーが第2のライブ・メディア・ストリームのタイムスタンプを調整して、調整されたタイムスタンプが、プロキシサーバーによって第1のクライアントに送信される第2のライブ・メディア・ストリームの最初のフレームのタイムスタンプと、プロキシサーバーによって第1のクライアントに送信される第1のライブ・メディア・ストリームの最後のフレームのタイムスタンプとが連続することを満たすようにすることを含む。
第1の側面を参照するに、第1の側面のさらに別の可能な実装では、プロキシサーバーによって第1のクライアントに送信される第1のライブ・メディア・ストリームの最後のフレームと、プロキシサーバーによって第1のクライアントに送信される第2のライブ・メディア・ストリームの最初のフレームとは、隣接するフレームである。プロキシサーバーが第1のクライアントに送信される第1のライブ・メディア・ストリームを第2のライブ・メディア・ストリームに切り換える前に、本方法はさらに：プロキシサーバーが、第1のライブ・メディア・ストリームおよび第2のライブ・メディア・ストリームに基づいて、それぞれ第1のライブ・メディア・ストリームおよび第2のライブ・メディア・ストリームに属する第1のIフレームおよび第2のIフレームであって、該第1のIフレームおよび第2のIフレームが同じビデオ・フレームである、第1のIフレームおよび第2のIフレームを識別し；プロキシサーバーが、該第1のIフレームおよび第2のIフレームに基づいて、互いに隣接し、それぞれ第1のライブ・メディア・ストリームおよび第2のライブ・メディア・ストリームに属する第1の切り換えフレームおよび第2の切り換えフレームを決定し；該第1の切り換えフレームおよび第2の切り換えフレームを、それぞれ、第1のクライアントに送信される第1のライブ・メディア・ストリームの最後のフレームおよび第1のクライアントに送信される第2のライブ・メディア・ストリームの最初のフレームとして使用することを含む。プロキシサーバーが第1の切り換えフレームおよび第2の切り換えフレームを決定した後、本方法はさらに：プロキシサーバーが、ライブ・ブロードキャスト・ルームを退出するための第2のクライアントからの要求メッセージをメディア・サーバーに転送することを含む。
第1の側面を参照するに、第1の側面のさらに別の可能な実装では、プロキシサーバーが第1のライブ・メディア・ストリームを第1のクライアントに送信する前に、本方法はさらに：プロキシサーバーが第1のライブ・メディア・ストリームのタイムスタンプを調整し、調整されたタイムスタンプが、プロキシサーバーによって第1のクライアントに送信される第1のライブ・メディア・ストリームの最初のフレームのタイムスタンプが0であり、第1のクライアントに送信される第1のライブ・メディア・ストリームの隣接する諸フレームのタイムスタンプが連続していることを満足するようにすることを含む。
第2の側面によれば、本願のある実施形態は、メディア・ストリーム送信装置を提供し、本装置は、第1の側面および第1の側面の諸実装の方法ステップを実行するように構成されたユニットを含む。具体的には、本装置は、取得ユニットおよび処理ユニットを含み、記憶モジュールのような別のモジュールまたはユニットをさらに含んでいてもよい。
第3の側面によれば、本願のある実施形態は、トランシーバ、プロセッサ、およびメモリを含むネットワーク装置をさらに提供する。プロセッサは、メモリに結合され；メモリは、命令を記憶するように構成され；プロセッサは、命令を呼び出して、ネットワーク装置が、第1の側面または第1の側面の諸実装のいずれかに基づくメディア・ストリーム送信方法を実行できるようにするように構成される。
さらに、トランシーバは、第1のクライアントから、ライブ・ブロードキャスト・ルームに入ることを要求するための第1のライブ・ブロードキャスト・ルーム要求メッセージを受信するように構成され；プロセッサは、第1のライブ・ブロードキャスト・ルーム要求メッセージに基づいて第1のクライアントの役割を決定するように構成され；トランシーバは、第1のクライアントの役割がスレーブ・ユーザーである場合、キャッシュされた第1のライブ・メディア・ストリームを第1のクライアントに送信するように構成され、第1のライブ・メディア・ストリームは、メディア・サーバーによってネットワーク装置を通じて第2のクライアントに送信されるメディア・ストリームであり、第2のクライアントの役割はマスター・ユーザーである。
任意的に、この側面のある可能な実装では、プロセッサは具体的には、第1のライブ・ブロードキャスト・ルーム要求メッセージが受信されたときに、ライブ・ブロードキャスト・ルームにおいて役割がマスター・ユーザーであるクライアントがいるかどうかを判定し；ライブ・ブロードキャスト・ルームにおいて役割がマスター・ユーザーであるクライアントがいる場合、第1のクライアントの役割がスレーブ・ユーザーであると判定するように構成される。
任意的に、この側面の別の可能な実装では、トランシーバはさらに、ネットワーク装置にキャッシュされた第1のライブ・メディア・ストリームを第1のクライアントに送信する前に、第1のクライアントから第1のメディア要求メッセージを受信し、第1のメディア要求メッセージをメディア・サーバーに転送するのをスキップし；第1のクライアントに第1のメディア応答メッセージを送信するように構成され、第1のメディア応答メッセージは、第1のクライアントに第1のクライアントがメディア・ストリームを取得することを許容されていることを通知するために使用される。
任意的に、この側面のさらに別の可能な実装では、第1のメディア要求メッセージは、第1のクライアントの識別子を含み；トランシーバはさらに：第1のライブ・メディア・ストリームを第1のクライアントに送信した後、第2のクライアントからライブ・ブロードキャスト・ルームを退出するための要求メッセージを受信するように構成され；プロセッサはさらに：第1のクライアントを新たなマスター・ユーザーとして決定するときに、第1のクライアントの役割をスレーブ・ユーザーからマスター・ユーザーに変更するようにさらに構成され；トランシーバはさらに：第2のメディア要求メッセージをメディア・サーバーに送信し、第2のメディア要求メッセージは第1のクライアントの識別子を含み；第2のメディア要求メッセージに基づいてメディア・サーバーによって送信される第2のライブ・メディア・ストリームを受信するように構成され；トランシーバはさらに：第1のクライアントに送信される第1のライブ・メディア・ストリームを第2のライブ・メディア・ストリームに切り換えるように構成される。
任意的に、この側面のさらに別の可能な実装では、プロセッサは具体的には：第1のライブ・ブロードキャスト・ルーム要求メッセージが受信されたときに、ライブ・ブロードキャスト・ルームにおける、役割がマスター・ユーザーであるクライアントの数が事前設定された上限に達しているかどうかを判定し；ライブ・ブロードキャスト・ルームにおける、役割がマスター・ユーザーであるクライアントの数が事前設定された上限に達していれば、第1のクライアントの役割がスレーブ・ユーザーであると決定するように構成される。
任意的に、この側面のさらに別の可能な実装では、プロセッサは：ライブ・ブロードキャスト・ルームにおける、役割がマスター・ユーザーであるクライアントの数が0ではないが事前設定された上限には達しない場合、第1のクライアントの役割が副次マスター・ユーザーであると決定するように構成される。
任意的に、このさらに別の可能な実装では、第1のクライアントがスレーブ・ユーザーである場合、トランシーバはさらに、第2のクライアントから、ライブ・ブロードキャスト・ルームを退出するための要求メッセージを受信するように構成され；プロセッサはさらに：第1のクライアントを新しい副次マスター・ユーザーとして決定するとき、第1のクライアントの役割をスレーブ・ユーザーから副次マスター・ユーザーに変更するように構成され；トランシーバはさらに、第3のメディア要求メッセージをメディア・サーバーに送信し、第3のメディア要求メッセージが第1のクライアントの識別子を含み、第3のメディア要求メッセージに基づいて、メディア・サーバーによって送信される第3のライブ・メディア・ストリームを受信するように構成される。
任意的に、この側面のさらに別の可能な実装では、第2のクライアントが主要マスター・ユーザーであり、第1のクライアントが副次マスター・ユーザーである場合、トランシーバはさらに：第1のライブ・メディア・ストリームを第1のクライアントに送信するように構成される。
任意的に、この側面のさらに別の可能な実装では、第1のクライアントが副次マスター・ユーザーである場合、トランシーバはさらに：第1のクライアントから第4のメディア要求メッセージを受信し；第4のメディア要求メッセージをメディア・サーバーに送信し；第4のメディア要求メッセージに基づいてメディア・サーバーによって送信される第4のライブ・メディア・ストリームを受信するように構成される。
任意的に、この側面のさらに別の可能な実装では、第1のクライアントが副次マスター・ユーザーである場合、トランシーバはさらに、第2のクライアントから、ライブ・ブロードキャスト・ルームを退出するための要求メッセージを受信するように構成され；プロセッサはさらに：第1のクライアントを新しい主要マスター・ユーザーとして決定する場合、第1のクライアントの役割を副次マスター・ユーザーから主要マスター・ユーザーに変更するように構成され；トランシーバはさらに、第1のクライアントに送信される第1のライブ・メディア・ストリームを第4のライブ・メディア・ストリームに切り換えるように構成される。
任意的に、この側面のさらに別の可能な実装では、プロセッサはさらに、第4のライブ・メディア・ストリームのタイムスタンプを調整し、調整されたタイムスタンプが、第1のクライアントに送信される第4のライブ・メディア・ストリームの最初のフレームのタイムスタンプと、第1のクライアントに送信される第1のライブ・メディア・ストリームの最後のフレームのタイムスタンプとが連続していることを満たすようにするように構成される。
任意的に、この側面のさらに別の可能な実装では、トランシーバによって第1のクライアントに送信される第1のライブ・メディア・ストリームの最後のフレームと、トランシーバによって第1のクライアントに送信される第4のライブ・メディア・ストリームの最初のフレームとは、隣接するフレームである。
プロセッサはさらに：キャッシュされた第1のライブ・メディア・ストリームおよび第4のライブ・メディア・ストリームに基づいて、それぞれ第1のライブ・メディア・ストリームおよび第4のライブ・メディア・ストリームに属する第1のIフレームおよび第2のIフレームを識別し、該第1のフレームおよび該第2のIフレームは同じビデオ・フレームであり；第1のIフレームおよび第2のIフレームに基づいて、互いに隣接し、それぞれ第1のライブ・メディア・ストリームおよび第4のライブ・メディア・ストリームに属する第1の切り換えフレームおよび第2の切り換えフレームを決定し、該第1の切り換えフレームおよび第2の切り換えフレームを、それぞれ、第1のクライアントに送られる第1のライブ・メディア・ストリームの最後のフレームおよび第1のクライアントに送られる第4のライブ・メディア・ストリームの最初のフレームとして使用するように構成される。
任意的に、この側面のさらに別の可能な実装では、メモリは、ピクチャーグループGOPごとに第1のライブ・メディア・ストリームをキャッシュするように構成される。
任意的に、この側面のさらに別の可能な実装では、プロセッサはさらに、第2のライブ・メディア・ストリームのタイムスタンプを調整して、調整されたタイムスタンプが、トランシーバによって第1のクライアントに送信される第2のライブ・メディア・ストリームの最初のフレームのタイムスタンプと、トランシーバによって第1のクライアントに送信される第1のライブ・メディア・ストリームの最後のフレームのタイムスタンプとが連続することを満たすようにするように構成される。
任意的に、この側面のさらに別の可能な実装では、トランシーバによって第1のクライアントに送信される第1のライブ・メディア・ストリームの最後のフレームと、トランシーバによって第1のクライアントに送信される第2のライブ・メディア・ストリームの最初のフレームとは、隣接するフレームである。
プロセッサはさらに：第1のライブ・メディア・ストリームおよび第2のライブ・メディア・ストリームに基づいて、それぞれ第1のライブ・メディア・ストリームおよび第2のライブ・メディア・ストリームに属する第1のIフレームおよび第2のIフレームであって、該第1のIフレームおよび第2のIフレームが同じビデオ・フレームである、第1のIフレームおよび第2のIフレームを識別し；該第1のIフレームおよび第2のIフレームに基づいて、互いに隣接し、それぞれ第1のライブ・メディア・ストリームおよび第2のライブ・メディア・ストリームに属する第1の切り換えフレームおよび第2の切り換えフレームを決定し；該第1の切り換えフレームおよび第2の切り換えフレームを、それぞれ、第1のクライアントに送信される第1のライブ・メディア・ストリームの最後のフレームおよび第1のクライアントに送信される第2のライブ・メディア・ストリームの最初のフレームとして使用し；第1の切り換えフレームおよび第2の切り換えフレームを決定した後、ライブ・ブロードキャスト・ルームを退出するための第2のクライアントからの要求メッセージをメディア・サーバーに転送するように構成される。
任意的に、この側面のさらに別の可能な実装では、プロセッサはさらに、第1のライブ・メディア・ストリームのタイムスタンプを調整し、調整されたタイムスタンプが、第1のクライアントに送信される第1のライブ・メディア・ストリームの最初のフレームのタイムスタンプが0であり、第1のクライアントに送信される第1のライブ・メディア・ストリームの隣接する諸フレームのタイムスタンプが連続していることを満足するようにするように構成される。
任意的に、前記ネットワーク装置は前記プロキシサーバーである。
第4の側面によれば、本願のある実施形態は、コンピュータ読み取り可能な記憶媒体をさらに提供する。記憶媒体は命令を記憶し；命令がコンピュータまたはプロセッサ上で実行されると、第1の側面または第1の側面の諸実装のいずれかに基づく方法が実行される。
第5の側面によれば、本願のある実施形態は、コンピュータ・プログラム・プロダクトをさらに提供する。コンピュータ・プログラム・プロダクトは、コンピュータ命令を含み；命令がコンピュータまたはプロセッサによって実行されると、第1の側面または第1の側面の諸実装のいずれかに基づく方法が実装できる。
第6の側面によれば、本願のある実施形態は、さらに、メディア・ストリーム送信システムを提供する。本システムは、少なくとも1つのクライアントと、プロキシサーバーと、およびメディア・サーバーとを含む。本システムは、プロキシサーバーを使用して、第1の側面または第1の側面の諸実装に基づくメディア・ストリーム送信方法を実装する。プロキシサーバーは、第1の側面または第1の側面の諸実装のいずれかに基づくメディア・ストリーム送信方法を実行するように構成される。
任意的に、プロキシサーバーは、第2の側面または第2の側面の諸実装に基づくメディア・ストリーム送信装置である。
第6の側面を参照するに、第6の側面のある可能な実装において、メディア・サーバーは、地域データセンターRDC内に位置しており、該RDCはさらにウェブ・サーバーを含み、該ウェブ・サーバーは、プロキシサーバーを通じてライブ・ブロードキャスト・ルームに入るクライアントにメディア・サーバーを割り当てるように構成される。
第6の側面を参照するに、第6の側面の別の可能な実装では、本システムは、企業データセンターEDCおよびコンテンツ源をさらに含む。
任意的に、メディア・ストリーム送信システムは、コンテンツ配信ネットワークCDNシステムである。
さらに、本願のある実施形態は、チップ・システムをさらに提供する。チップ・システムは、プロセッサとインターフェース回路とを含む。インターフェース回路はプロセッサに結合される。プロセッサは、コンピュータ・プログラムまたは命令を実行し、第1の側面または第1の側面の諸実装に基づく方法を実装するように構成される。インターフェース回路は、チップ・システムの外部の別のモジュールと通信するように構成される。
実施形態における方法によれば、役割がマスター・ユーザーであるクライアントによって要求されたライブ・メディア・ストリームが、プロキシサーバーを使用することによって取得されるとき、プロキシサーバーは、メディア・ストリームのセグメントの一部をローカルにキャッシュする。役割がスレーブ・ユーザーであるクライアントがライブ・ブロードキャスト・ルームに入り、ライブ・メディア・ストリームを要求すると、プロキシサーバーはローカルにキャッシュされたメディア・ストリームを、役割がスレーブ・ユーザーであるクライアントに直接送信するので、メディア・サーバーはライブ・メディア・ストリームを再度プロキシサーバーに送信する必要はない。この方法によれば、メディア・サーバーはプロキシサーバーを通じてライブ・ブロードキャスト・ルームに入る各クライアントにライブ・メディア・ストリームを送信する必要はない。これは、メディア・ストリームの送信のためのトラフィックを削減し、出口帯域幅を効果的に節約し、資源オーバーヘッドを削減する。
さらに、この方法によれば、同じライブ・ブロードキャスト・ルーム内のすべてのクライアントについて、メディア・サーバーは、1つのライブ・メディア・ストリームをプロキシサーバーに送信する必要があるだけであり、すなわち、該1つのライブ・メディア・ストリームを送信するための広域ネットワーク帯域幅が必要とされる。メディア・サーバーによってすべてのクライアントにライブ・メディア・ストリームを送信するために占有される伝送資源と比較すると、これは広域ネットワーク・リンクの負荷を低減し、すべてのクライアントがライブ・ブロードキャスト・メディアを受信した後、ライブ・メディア・ストリームの再生中のビデオのフリーズを回避し、よって、この方法を使用することによってユーザー体験をさらに改善する。
本願によるライブ・ブロードキャスト・システムのアーキテクチャーの概略図である。
本願のある実施形態による、ビデオ・ライブ・ブロードキャスト用の一方的プロキシシステムのアーキテクチャーの概略図である。
本願のある実施形態によるメディア・ストリーム送信方法のフローチャートである。
図4A～図4Dは、本願のある実施形態によるメディア・ストリーム送信方法の信号伝達フローチャートである。
図5Aおよび図5Bは、本願のある実施形態による、別のメディア・ストリーム送信方法の信号伝達フローチャートである。
図6Aおよび図6Bは、本願のある実施形態による、さらに別のメディア・ストリーム送信方法の信号伝達フローチャートである。
図7Aおよび図7Bは、本願のある実施形態による、さらに別のメディア・ストリーム送信方法の信号伝達フローチャートである。
図8Aおよび図8Bは、本願のある実施形態による、さらに別のメディア・ストリーム送信方法の信号伝達フローチャートである。
本願のある実施形態によるメディア・ストリーム送信装置の概略構造図である。
本願のある実施形態によるネットワーク装置の概略構造図である。
当業者に本願の実施形態における技術的解決策をよりよく理解させ、本願の実施形態の目的、特徴、および利点をより明確にするために、下記はさらに、添付の図面を参照して、本願の実施形態における技術的解決策を詳細に記載する。
本願の実施形態における技術的解決策が記載される前に、まず、本願の実施形態の適用シナリオが、添付の図面を参照して記載される。
本願の技術的解決策は、コンテンツ配信ネットワーク（content delivery network、CDN）システムに適用されうる。システムは、プロキシサーバー（proxy server）を含む。プロキシサーバーは、ユーザーのビデオ・ベアラ・プロトコルのためのプロキシとして行動し、プロキシサーバーを通じてライブ・ブロードキャスト・ルームに入るすべてのクライアントの役割を識別し、役割がマスター・ユーザーであるクライアントのメディア要求メッセージに基づいてメディア・サーバーからライブ・メディア・ストリームを取得し、プロキシサーバーを通じてライブ・ブロードキャスト・ルームに入るすべてのクライアントにライブ・メディア・ストリームを配信するように構成される。
本願の技術的解決策が適用されるシステムは、複数のプロキシサーバーを含んでいてもよく、各プロキシサーバーは、本願の実施形態においてプロキシサーバーによって実行される動作を実行することができる。換言すれば、本願の実施形態におけるプロキシサーバーは、本願の実施形態が適用されるシステムにおける任意のプロキシサーバーでありうる。本願の実施形態では、以下に記載されるクライアントは、プロキシサーバーを通じてライブ・ブロードキャスト・ルームに入るクライアントであり、プロキシサーバーは、プロキシサーバーを通じてライブ・ブロードキャスト・ルームに入るすべてのクライアントの役割（たとえば、マスター・ユーザーおよびスレーブ・ユーザー）を識別する。対応して、以下に記載される、ライブ・ブロードキャスト・ルームにおける、役割がマスター・ユーザーであるクライアントは、プロキシサーバーを通じてライブ・ブロードキャスト・ルームに入室するクライアントのうち、プロキシサーバーによってマスター・ユーザーとして識別されるクライアントである。同様に、以下に記載される、役割がスレーブ・ユーザーであるクライアントは、プロキシサーバーを通じてライブ・ブロードキャスト・ルームに入るクライアントのうち、プロキシサーバーによってスレーブ・ユーザーとして識別されるクライアントである。
プロキシサーバーは、ローカルエリアネットワークのエッジにある装置であってもよく、ローカルエリアネットワーク内のクライアントは、プロキシサーバーを通じてライブ・ブロードキャスト・ルームに入り、プロキシサーバーを通じてライブ・ブロードキャスト・ルームのライブ・メディア・ストリームを取得する。
任意的に、プロキシサーバーは、サーバー上に配備されてもよいし、あるいはネットワーク機能仮想化（Network Functions Virtualization、NFV）を通じて、汎用顧客構内設備（Universal Customer Premise Equipment、uCPE）上に配備されてもよい。
さらに、図2に示されるように、この実施形態において提供されるビデオCDNシステムにおいて、システムは：コンテンツ源（content source）101、企業データセンター（enterprise data center、EDC）102、RDC 103、プロキシサーバー104、および少なくとも1のクライアント（client、C）を含む。たとえば、少なくとも1のクライアントは、第1のクライアントC1 105、第2のクライアントC2 106、および第3のクライアントC3 107を含む。EDC 102は、複数のメディア・サーバー（media server）およびウェブ・サーバー（Web server）を含み、RDC 103は、複数のメディア・サーバーおよびウェブ・サーバーを含む。
ライブCDNは分散式のコンテンツ配信プラットフォームであり、多層アーキテクチャーをサポートする。ライブCDNプラットフォームでは、キャッシング用の複数のサーバーが異なる層に配備されて、異なる地域のユーザーのために近くのサービスを提供することができる。EDC内のユーザーがライブ・ブロードキャスト・ルームにおいてライブ・ブロードキャストを視聴するとき、割り当てられたメディア・サーバーがRDC内に配備され、送信されるライブ・メディア・ストリームはマルチプロトコルラベルスイッチング（Multi-Protocol Label Switching、MPLS）プライベート回線を通じてRDCに到達する。
また、上記装置またはネットワーク要素の機能の一般的な記述を下記の表1に与えておく。
Figure 0007256881000001
ある実施形態は、ライブ・メディア・ストリームがRDCからSRに、次いでクライアントに送信される場合に大量のネットワーク資源が占有されるという問題を解決するために、メディア・ストリーム送信方法を提供する。本方法はプロキシサーバーに適用され、プロキシサーバーはライブ・ブロードキャスト・ルームに入る少なくとも2のクライアントのためにライブ・メディア・ストリームを提供するように構成される。具体的には、図3に示されるように、本方法は、以下のステップを含む。
ステップ101：プロキシサーバーは、第1のクライアントから、ライブ・ブロードキャスト・ルームに入ることを要求するための第1のライブ・ブロードキャスト・ルーム要求メッセージを受信する。ここで、第1のライブ・ブロードキャスト・ルーム要求メッセージは、第1のクライアントの第1の識別子、たとえばクライアントC1のIPアドレスを含む。
ステップ102：プロキシサーバーは、第1のライブ・ブロードキャスト・ルーム要求メッセージに基づいて第1のクライアントの役割を決定する。ここで、第1のクライアントの役割は、マスター・ユーザー（master user）またはスレーブ・ユーザー（slave user）であってもよい。
具体的には、ステップ102は：プロキシサーバーが、第1のライブ・ブロードキャスト・ルーム要求メッセージを受信するときに、ライブ・ブロードキャスト・ルームにおいて役割がマスター・ユーザーであるクライアントが存在するかどうかを判定し；ライブ・ブロードキャスト・ルームにおいて役割がマスター・ユーザーであるクライアントが存在する場合には、プロキシサーバーは、第1のクライアントの役割はスレーブ・ユーザーであると決定し、あるいはライブ・ブロードキャスト・ルームにおいて役割がマスター・ユーザーであるクライアントが存在しない場合には、プロキシサーバーは、第1のクライアントの役割はマスター・ユーザーであると決定することを含む。ライブ・ブロードキャスト・ルームにおいて役割がマスター・ユーザーであるクライアントが存在するかどうかは、具体的には、第1のライブ・ブロードキャスト・ルーム要求メッセージが受信されたときの、役割がマスター・ユーザーであるクライアントの数に基づいて決定されてもよい。その数が事前設定された上限に達している場合、プロキシサーバーは、現在のクライアントはスレーブ・ユーザーであると決定する。そうでない場合、プロキシサーバーは、第1のクライアントはマスター・ユーザーであると決定する。
事前設定された上限は、プロキシサーバーを通じてライブ・ブロードキャスト・ルームに入室し、マスター・ユーザーとして決定されるクライアントの数の上限である。
さらに、この実施形態では、役割がマスター・ユーザーであるクライアントは、マスター・ユーザー・クライアントと略称され、役割がスレーブ・ユーザーであるクライアントはスレーブ・ユーザー・クライアントと略称される。この実施形態では、事前設定された上限の異なる値に基づき、2つの場合がある：事前設定された上限が1である場合および事前設定された上限が1より大きい場合である。
具体的には、事前設定された上限が1である場合、プロキシサーバーを通じてライブ・ブロードキャスト・ルームにアクセスするように設定されているすべてのクライアントのうち、マスター・ユーザー・クライアントの数は1である、すなわち、マスター・ユーザーは1人しかいない。そのようなシナリオは、単一のマスター・ユーザーが存在するシナリオと称されることがある。事前設定された上限が1より大きい場合、すなわち、マスター・ユーザー・クライアントの数が2以上である場合、1人の主要マスター・ユーザー（main-master user）と複数の副次マスター・ユーザーが存在することがある。そのようなシナリオは、複数のマスター・ユーザーが存在するシナリオと称されることがある。
さらに、複数のマスター・ユーザーが存在するシナリオについては、第1のクライアントの役割を決定することは：第1のライブ・ブロードキャスト・ルーム要求メッセージが受信されるとき、ライブ・ブロードキャスト・ルームにおいて役割がマスター・ユーザーであるクライアントの数が0でない場合には、第1のクライアントの役割は主要マスター・ユーザーであると決定する；または、その数が0ではないが事前設定された上限には達しない場合には、第1のクライアントの役割は副次マスター・ユーザーであると決定することを含む。
ステップ103：第1のクライアントの役割がスレーブ・ユーザーであると決定すると、プロキシサーバーはローカルにキャッシュされた第1のライブ・メディア・ストリームを第1のクライアントに送信する。
第1のライブ・メディア・ストリームは、メディア・サーバーによってプロキシサーバーを通じて、役割がマスター・ユーザーであるクライアントに送信されるメディア・ストリームである。この実施形態では、単一のマスター・ユーザーが存在する技術シナリオにおいては、第2のクライアントの役割がマスター・ユーザーである。複数のマスター・ユーザーが存在する技術シナリオにおいては、第2のクライアントの役割は、具体的には、主要マスター・ユーザーである。
ステップ103の前に、本方法はさらに：プロキシサーバーが、第2のクライアントから、ライブ・ブロードキャスト・ルームに入るための第2のライブ・ブロードキャスト・ルーム要求メッセージを受信し；メディア・サーバーから第1のライブ・メディア・ストリームを取得し；第1のライブ・メディア・ストリームをキャッシュし；第1のライブ・メディア・ストリームをプロキシサーバーを通じて第2のクライアントに送信することを含む。第1のライブ・メディア・ストリームが取得されたとき、プロキシサーバーを通じてライブ・ブロードキャスト・ルームに入るライブ・ブロードキャスト・ルーム内の別のクライアントが存在する場合、プロキシサーバーはさらに第1のライブ・メディア・ストリームを前記別のクライアントに送信する。具体的な実装では、第2のクライアントは、第2のライブ・ブロードキャスト・ルーム要求メッセージを送信することによってライブ・ブロードキャスト・ルームに入ることを要求し、メディア要求メッセージを送信することによってライブ・メディア・ストリームを要求してもよい。この場合、第2のクライアントによって送信されたメディア要求メッセージを受信した後、プロキシサーバーは、第1のライブ・メディア・ストリームを取得するために、メディア要求メッセージをメディア・サーバーに転送する。あるいはまた、第2のライブ・ブロードキャスト・ルーム要求メッセージを送信することによって、クライアントは、ライブ・ブロードキャスト・ルームに入ることを要求し、かつ、ライブ・メディア・ストリームを要求することができる。この場合、第2のライブ・ブロードキャスト・ルーム要求メッセージを受信した後、プロキシサーバーは、第1のライブ・メディア・ストリームを取得するために第2のライブ・ブロードキャスト・ルーム要求メッセージをメディア・サーバーに転送する。
任意的に、第1のライブ・メディア・ストリームを受信した後、プロキシサーバーは第1のライブ・メディア・ストリームをピクチャーグループ（group of pictures、GOP）ごとにローカルにキャッシュする。GOPは、2つのIフレームの間のピクチャー・シーケンスを指しうる。イントラピクチャー（intra picture）とも呼ばれるIフレーム（frame）は、典型的には、動画像エキスパートグループ（moving picture experts group、MPEG）技術処理を通じて得られる各GOPの最初のフレームを指す。さらに、MPEG技術処理は、Iフレームがランダムアクセスのための基準として使用でき、他のピクチャーを参照する必要がないように、ビデオ・ピクチャーを適切に圧縮することを含む。
この実施形態では、たとえば、3つのGOPがローカルにキャッシュされる。たとえば、キャッシュされたライブ・メディア・ストリームの3つのGOPの時間セグメントは、t1-t2、t2-t3、およびt3-t4である。
第1のクライアントがライブ・メディア・ストリームの取得を要求すると、プロキシサーバーは、第1のクライアントの役割がスレーブ・ユーザーであることを決定し、検証し、ローカルにキャッシュされた第1のライブ・メディア・ストリームを直接第1のクライアントに送信して、プロキシサーバーが再度、メディア・サーバーにライブ・メディア・ストリームを要求し取得することを防ぐ。言い換えれば、メディア・サーバーは、プロキシサーバーに1つのライブ・メディア・ストリームを送信する必要があるだけであり、プロキシサーバーは、ライブ・メディア・ストリームを複製し、ライブ・ブロードキャスト・ルームにおいてスレーブ・ユーザーとして機能するすべてのクライアントに配信することができる。よって、同じライブ・ブロードキャスト・ルームに入る諸ユーザーのために、ただ1つのライブ・メディア・ストリームのための広域ネットワーク帯域幅が消費される。この方法を使用することにより、RDCにおけるメディア・サーバーと既存のシステムにおけるSRとの間でメディア・ストリームを送信するためのトラフィックが減り、出口帯域幅が効果的に節約され、資源オーバーヘッドが減る。
加えて、この方法を使用することにより、広域ネットワーク・リンクの負荷をさらに低減し、クライアントに送信されるライブ・ビデオの再生中のビデオのフリーズを回避し、他のサービスに影響を与えることを回避する。よって、この方法を使用することは、ユーザー体験をさらに改善する。
単一のマスター・ユーザーが存在するシナリオでは、前記第1のクライアントはスレーブ・ユーザーであり、前記第2のクライアントがマスター・ユーザーである。ステップ103の前に、本方法はさらに：プロキシサーバーが、第1のクライアントによって送信された第1のメディア要求メッセージを受信することを含む。第1のクライアントはスレーブ・ユーザーであるため、プロキシサーバーは第1のメディア要求メッセージをメディア・サーバーに転送しない。プロキシサーバーは、第1のクライアントに第1のメディア応答メッセージを送信し、第1のメディア応答メッセージは、第1のクライアントがメディア・ストリームを取得することを許容されていることを第1のクライアントに通知するために使用される。さらに、取得されることが許容されるメディア・ストリームは、第1のライブ・メディア・ストリームであり、第1のライブ・メディア・ストリームは、メディア・サーバーによって、役割がマスター・ユーザーであるクライアントに送信されるメディア・ストリームである。
加えて、この実施形態はさらに：ライブ・ブロードキャスト・ルーム内のマスター・ユーザー・クライアントがライブ・ブロードキャスト・ルームを退出し、ライブ・ブロードキャスト・ルーム内の別のクライアントが新しいマスター・ユーザーとして選択され、新しいマスター・ユーザーからのメディア・ストリームがライブ・ブロードキャスト・ルーム内のクライアントに送られることを含む。具体的には、本方法は：プロキシサーバーが、第2のクライアントから、ライブ・ブロードキャスト・ルームを退出するための要求メッセージを受信し；第1のクライアントを新しいマスター・ユーザーとして決定するとき、プロキシサーバーは、第1のクライアントの役割をスレーブ・ユーザーからマスター・ユーザーに変更し；プロキシサーバーは、第1のクライアントの識別子を含む第2のメディア要求メッセージをメディア・サーバーに送信し；プロキシサーバーは、第2のメディア要求メッセージに基づいてメディア・サーバーによって送信される第2のライブ・メディア・ストリームを受信し；プロキシサーバーは、ライブ・ブロードキャスト・ルーム内のクライアント（第1のクライアントを含む）に送信される第1のライブ・メディア・ストリームを第2のライブ・メディア・ストリームに切り換える。
この実装では、マスター・ユーザーとして機能する第2のクライアントがライブ・ブロードキャスト・ルームを退出すると、プロキシサーバーは、新しいマスター・ユーザーとして、スレーブ・ユーザーとして機能する第1のクライアントを選択し、第1のクライアントの識別情報を使用してライブ・メディア・ストリームを要求して取得し、次いで、プロキシサーバーは、ライブ・メディア・ストリームを複製して、ライブ・ブロードキャスト・ルーム内の別のクライアントに配信する。それにより、ライブ・ブロードキャスト・ルーム内のユーザーがビデオをスムーズに見ることを保証する。
ライブ・ブロードキャスト・ルームにおける第1のクライアントと第2のクライアントの役割およびマスター・ユーザー・クライアントの数は、どちらも、ライブ・ブロードキャスト・ルーム・ユーザー関係テーブルに基づいて決定できる。ライブ・ブロードキャスト・ルーム・ユーザー関係テーブルは、各クライアントに関する情報を記録し、各クライアントに関する情報は、ライブ・ブロードキャスト・ルーム要求メッセージ；クライアントのIPアドレス、ポート番号、ユーザー役割、ユーザー名；メディア・サーバーのIPアドレス、ポート番号；およびライブ・ブロードキャスト・ルームの名前などの情報を含む。プロキシサーバーは、現在、ライブ・ブロードキャスト・ルーム内にいる全ユーザーのライブ・ブロードキャスト・ルーム要求メッセージを計算することによってマスター・ユーザー数を決定し、次いで、マスター・ユーザー数と事前設定された上限とに基づいて第1のクライアントの役割を決定する。
加えて、プロキシサーバーがライブ・メディア・ストリーム（たとえば、第1のライブ・メディア・ストリームまたは第2のライブ・メディア・ストリーム）をライブ・ブロードキャスト・ルーム内のクライアント（たとえば、第1のクライアント）に送信する前に、本方法はさらに：ライブ・メディア・ストリームのタイムスタンプを調整することを含む。具体的には、本方法はさらに：公式y＝x＋Δtに従ってメディア・ストリームのタイムスタンプを調整することを含み、ここで、yは調整後のタイムスタンプを表わし、xは調整前のタイムスタンプを表わし、Δtは時間差を表わす。
前記メディア・ストリームが、クライアントがライブ・ブロードキャスト・ルームに入った後にクライアントによって受信されるライブ・メディア・ストリームの最初のチャネルである場合、たとえばステップ103において、前記第1のライブ・メディア・ストリームが、第1のクライアントがライブ・ブロードキャスト・ルームに入った後に第1のクライアントによって受信されるライブ・メディア・ストリームの最初のチャネルである場合、プロキシサーバーは、前記公式に従ってメディア・ストリームのタイムスタンプを調整し、調整されたタイムスタンプが以下の制約を満たすようにする：
１．プロキシサーバーによってクライアントに送信されるライブ・メディア・ストリームの最初のフレームのタイムスタンプは0である；
２．プロキシサーバーによってクライアントに送信されるライブ・メディア・ストリームの隣接する諸フレームのタイムスタンプは連続している、すなわち、送信されるライブ・ビデオ・ストリームの隣接する諸フレームの時間長は同じであり、該時間長はライブ・ビデオ・ストリームのフレームレートfの逆数である。
ライブ・メディア・ストリームは、クライアントがライブ・ブロードキャスト・ルームに入った後にクライアントによって受信されるライブ・メディア・ストリームの最初のチャネルであるため、Δtは、プロキシサーバーによってクライアントに送信されるライブ・メディア・ストリームの最初のフレームの調整前のタイムスタンプの反数を表わす。
クライアントがメディア・ストリームを受信したことがある場合、すなわち、プロキシサーバーによってクライアントに送信されたメディア・ストリームが、前のマスター・ユーザーのメディア・ストリームから現在のマスター・ユーザーのメディア・ストリームに切り換わる場合、たとえば、プロキシサーバーが第1のクライアントに送信される第1のライブ・メディア・ストリームを第2のライブ・メディア・ストリームに切り換える場合、プロキシサーバーは、調整されたタイムスタンプが以下の制約を満たすように、前記公式に従って現在のマスター・ユーザーのメディア・ストリームのタイムスタンプを調整する：
１．プロキシサーバーによってクライアントに送信される、前のマスター・ユーザーのメディア・ストリームの最後のフレームのタイムスタンプと、クライアントに送信される、現在のマスター・ユーザーのメディア・ストリームの最初のフレームのタイムスタンプが連続している；および
２．プロキシサーバーによってクライアントに送信される、現在のマスター・ユーザーのメディア・ストリームの隣接する諸フレームのタイムスタンプは連続している。
たとえば、1人のマスター・ユーザーと複数のスレーブ・ユーザーが存在するシナリオにおいて、プロキシサーバーによってキャッシュされる第1のライブ・メディア・ストリームのGOPの時間長さは5秒（s）と想定され、3つのGOPはローカルにキャッシュされ、該3つのGOPの内容はリアルタイムで更新される。第2のクライアントC2が最初にライブ・ブロードキャスト・ルームに入るクライアントである場合、0秒目におけるクライアントC2の役割はマスター・ユーザーであり、クライアントC2は、60秒目に達するまで、ライブ・ブロードキャスト・ルーム内の第1のライブ・メディア・ストリームを継続的に視聴する。この場合、プロキシサーバーによってローカルにキャッシュされるビデオ・メディア・ストリームの3つのGOPは次のようになる：45秒目から50秒目までのメディア・コンテンツ、50秒目から55秒目までのメディア・コンテンツ、および55秒目から60秒目までのメディア・コンテンツである。3つのGOPは、メディア・サーバーによってクライアントC2に送信されるメディア・ストリームのセグメントであり、対応して送信される各フレームのタイムスタンプはクライアントC2の相対時間である。
第1のクライアントC1が60秒目にライブ・ブロードキャスト・ルームに入り、第1のクライアントC1の役割はスレーブ・ユーザーである。プロキシサーバーはクライアントC1に、クライアントC2に送信されローカルにキャッシュされている最新の第1のライブ・メディア・ストリームを送信する必要がある。この場合、60秒目に最も近いライブ・メディア・ストリームは、3番目のGOPセグメントのメディア・コンテンツであり、55秒目から60秒目までのメディア・コンテンツがキャッシュされている。第55秒目というのは、メディア・サーバーによって送信されるフレームのタイムスタンプであり、よって、調整されるべき時間差は、Δt＝y－x＝0－55＝－55sである。すなわち、クライアントC1に第1のライブ・メディア・ストリームを送信するときに、前述の制約を満たすよう、プロキシサーバーはタイムスタンプを55秒小さくする必要がある。このように、ライブ・ブロードキャスト・ルームに入室する各ユーザーは、待つ必要なく、0秒目にライブ・ブロードキャスト・ビデオを見ることができ、ライブ・ブロードキャスト・ルーム内の全ユーザーは、同じビデオを「同期して」見ることができる。
加えて、第2のクライアントC2がライブ・ブロードキャスト・ルームを退出するとき、ビデオ・メディア・ストリームのタイムスタンプがさらに調整される必要がある。具体的には、クライアントC2がビデオ再生の120秒目にライブ・ブロードキャスト・ルームから出る場合、プロキシサーバーは、あるクライアントを新しいマスター・ユーザーとして選択する必要がある。この実施形態では、第1のクライアントC1がマスター・ユーザーとして選択されるものとする。次いで、プロキシサーバーは、クライアントC2にもともと送られていた第1のライブ・メディア・ストリームを、クライアントC1に送られるライブ・メディア・ストリームに変更する。対応するタイムスタンプ調整プロセスは次のとおり。
120秒目において、プロキシサーバーによってローカルにキャッシュされている3つのGOPのメディア・コンテンツは次のとおりであるとする：105秒目から110秒目までのメディア・コンテンツ、110秒目から115秒目までのメディア・コンテンツ、115秒目から120秒目までのメディア・コンテンツ。10秒経過後、プロキシサーバーによってキャッシュされる最新のGOP 1は、115秒目から120秒目までのビデオ・コンテンツであり、GOP 1内のフレームのタイムスタンプは、クライアントC2の相対時間である。クライアントC2がライブ・ブロードキャスト・ルームを出た後、プロキシサーバーはGOP 2およびGOP 3をローカルにキャッシュする：0秒目から5秒目までのメディア・コンテンツと5秒目から10秒目までのメディア・コンテンツである。これら2つのGOPのタイムスタンプは、クライアントC1の相対時間である。よって、調整される時間差は、Δt＝120－55－0＝65sとして計算される。すなわち、新しいマスター・ユーザーとして機能するクライアントC1にプロキシサーバーによって送信されるライブ・メディア・ストリームのフレームのタイムスタンプは、65秒増加する必要がある。
上記に基づき、調整された時間差を計算するためには、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.05、つまり50msである。
上記の方法によれば、プロキシサーバーが第1のクライアントに送られる第1のライブ・メディア・ストリームを第2のライブ・メディア・ストリームに切り換える前に、本方法はさらに：プロキシサーバーが第2のライブ・メディア・ストリームのタイムスタンプを調整して、調整されたタイムスタンプが、プロキシサーバーによって第1のクライアントに送信される第2のライブ・メディア・ストリームの最初のフレームのタイムスタンプと、プロキシサーバーによって第1のクライアントに送信される第1のライブ・メディア・ストリームの最後のフレームのタイムスタンプとが連続していることを満たすようにすることを含む。
さらに、プロキシサーバーによって第1のクライアントに送信される第1のライブ・メディア・ストリームの最後のフレームと、プロキシサーバーによって第1のクライアントに送信される第2のライブ・メディア・ストリームの最初のフレームとは、隣接するフレームである。プロキシサーバーが第1のクライアントに送信される第1のライブ・メディア・ストリームを第2のライブ・メディア・ストリームに切り換える前に、本方法はさらに：プロキシサーバーが、第1のライブ・メディア・ストリームおよび第2のライブ・メディア・ストリームに基づいて、それぞれ第1のライブ・メディア・ストリームおよび第2のライブ・メディア・ストリームに属する第1のIフレームおよび第2のIフレームであって、該第1のIフレームおよび第2のIフレームは同じビデオ・フレームである、第1のIフレームおよび第2のIフレームを識別し；該第1のIフレームおよび第2のIフレームに基づいて、互いに隣接し、それぞれ第1のライブ・メディア・ストリームおよび第2のライブ・メディア・ストリームに属する第1の切り換えフレームおよび第2の切り換えフレームを決定し、該第1の切り換えフレームおよび第2の切り換えフレームを、それぞれ第1のクライアントに送信される第1のライブ・メディア・ストリームの最後のフレームおよび第1のクライアントに送信される第2のライブ・メディア・ストリームの最初のフレームとして使用することを含む。第1の切り換えフレームおよび第2の切り換えフレームを決定した後、プロキシサーバーは、ライブ・ブロードキャスト・ルームを退出するための、第2のクライアントからの要求メッセージをメディア・サーバーに転送する。
この実施形態では、プロキシサーバーは、マスター・ユーザーのライブ・メディア・ストリームを、プロキシサーバーを通じてライブ・ブロードキャスト・ルームに入る各クライアントに送信する。マスター・ユーザーが切り換えられるたびに、プロキシサーバーは、各クライアントに送信される、前のマスター・ユーザーのライブ・メディア・ストリームを、現在のマスター・ユーザーのライブ・メディア・ストリームに切り換える。すなわち、プロキシサーバーは、前のマスター・ユーザーのメディア・ストリームを各クライアントに送るのを停止し、現在のマスター・ユーザーのライブ・メディア・ストリームを前記クライアントに送るのを開始する。たとえば、クライアントC1がライブ・ブロードキャスト・ルームを出ると、プロキシサーバーは、第1のライブ・メディア・ストリームをクライアントC1に送信するのを停止し、新たに選択されたクライアントC2の第2のライブ・メディア・ストリームを、ライブ・ブロードキャスト・ストリームを視聴しているライブ・ブロードキャスト・ルーム内の別のクライアントに送信する。この場合、クライアントC2の役割はマスター・ユーザーに変わる。加えて、新しいメディア・ストリームを送信するとき、プロキシサーバーによっていずれかのクライアントに送信される、現在のマスター・ユーザーのライブ・メディア・ストリームの最初のフレームは、前記クライアントに送信される、前のマスター・ユーザーのライブ・メディア・ストリームの最後のフレームに隣接する。すなわち、クライアントC2に送信される第2のライブ・メディア・ストリームの最初のフレームは、もともと送信されていた第1のライブ・メディア・ストリームの最後のフレームに隣接している。
複数のマスター・ユーザーが存在するシナリオでは、第2のクライアントは主要マスター・ユーザーであり、第1のクライアントはスレーブ・ユーザーであり、クライアントがライブ・ブロードキャスト・ルームを出るプロセスは：プロキシサーバーが、ライブ・ブロードキャスト・ルームを出るための、第2のクライアントからの要求メッセージを受信し；プロキシサーバーが、第1のクライアントを新しい副次マスター・ユーザーとして決定する際に、第1のクライアントの役割をスレーブ・ユーザーから副次マスター・ユーザーに変更し；プロキシサーバーが、メディア・サーバーに第3のメディア要求メッセージを送信し、該第3のメディア要求メッセージに基づいてメディア・サーバーによって送信される第3のライブ・メディア・ストリームを受信し、該第3のライブ・メディア・ストリームをGOPごとにローカルにキャッシュし、第3のメディア要求メッセージが第1のクライアントの識別子を含むことを含む。
この実施形態では、ライブ・メディア・ストリームを取得した後、プロキシサーバーは、ライブ・メディア・ストリームを副次マスター・ユーザーとして機能するクライアントに転送せず、プロキシサーバーは、ライブ・メディア・ストリームのセグメントをローカルにキャッシュし、副次マスター・ユーザーの役割が主要マスター・ユーザーに切り換えられたときに、ライブ・メディア・ストリームのキャッシュされたセグメントをライブ・ブロードキャスト・ルーム内のユーザーに配信するようにする。
任意的に、複数のマスター・ユーザーが存在するシナリオにおいて、第1のクライアントが副次マスター・ユーザーであり、プロキシサーバーが、第1のクライアントによって送信された第4のメディア要求メッセージに基づいて、メディア・サーバーから第4のライブ・メディア・ストリームを取得する場合、主要マスター・ユーザーとして機能する第2のクライアントがライブ・ブロードキャスト・ルームを退室するとき、本方法は、さらに：第1のクライアントを新しい主要マスター・ユーザーとして決定すると、プロキシサーバーが、第1のクライアントの役割を副次マスター・ユーザーから主要マスター・ユーザーに変更し、プロキシサーバーが、ライブ・ブロードキャスト・ルーム内のクライアント（第1のクライアントを含む）に送信される第1のライブ・メディア・ストリームを第4のライブ・メディア・ストリームに切り換えることを含む。
プロキシサーバーは、第4のライブ・メディア・ストリームのタイムスタンプを調整し、調整されたタイムスタンプが、第1のクライアントに送信される第4のライブ・メディア・ストリームの最初のフレームのタイムスタンプと、第1のクライアントに送信される第1のライブ・メディア・ストリームの最後のフレームのタイムスタンプが連続していることを満たすようにする。
さらに、プロキシサーバーによって第1のクライアントに送信される第1のライブ・メディア・ストリームの最後のフレームと、プロキシサーバーによって第1のクライアントに送信される第4のライブ・メディア・ストリームの最初のフレームとは、隣接するフレームである。プロキシサーバーが第1のクライアントに送られる第1のライブ・メディア・ストリームを第4のライブ・メディア・ストリームに切り換える前に、本方法はさらに：プロキシサーバーが、キャッシュされた第1のライブ・メディア・ストリームおよび第4のライブ・メディア・ストリームに基づいて、第1のライブ・メディア・ストリームおよび第4のライブ・メディア・ストリームにそれぞれ属する第1のIフレームおよび第2のIフレームを識別することを含み、ここで、該第1のIフレームおよび第2のIフレームは同じビデオ・フレームである。
プロキシサーバーは、第1のIフレームおよび第2のIフレームに基づいて、互いに隣接し、第1のライブ・メディア・ストリームおよび第4のライブ・メディア・ストリームにそれぞれ属する第1の切り換えフレームおよび第2の切り換えフレームを決定し、該第1の切り換えフレームおよび第2の切り換えフレームを、それぞれ第1のクライアントに送られる第1のライブ・メディア・ストリームの最後のフレームおよび第1のクライアントに送られる第4のライブ・メディア・ストリームの最初のフレームとして使用する。より具体的なタイムスタンプ調整プロセスについては、上記の実施形態の説明を参照されたい。詳細は、ここでは再度説明しない。
この実施形態では、複数のマスター・ユーザーが存在する技術シナリオにおいて、プロキシサーバーは、役割が主要マスター・ユーザーであるクライアントによって要求されたライブ・メディア・ストリームをメディア・サーバーから取得し、ライブ・メディア・ストリームをライブ・ブロードキャスト・ルーム内の全ユーザーに配信する。メディア・サーバーは、プロキシサーバーを通してライブ・ブロードキャスト・ルームに入る各ユーザーのために、ライブ・メディア・ストリームをプロキシサーバーに送信する必要はない。これにより、メディア・サーバーとプロキシサーバーとの間のWAN送信資源が節約され、メディア・ストリーム送信のためのオーバーヘッドが削減される。
加えて、プロキシサーバーはさらに、役割が副次マスター・ユーザーであるクライアントのメディア・ストリームを取得し、ローカルにそのメディア・ストリームをキャッシュする。それにより、主要マスター・ユーザーとして機能するクライアントがライブ・ブロードキャスト・ルームから出るときに、メディア・ストリームは使用される準備ができている。加えて、ライブ・メディア・ストリームが切り換えられるとき、メディア・ストリームの整列とタイムスタンプの調整が実行され、ライブ・ブロードキャスト・ルームにおいてまだメディア・コンテンツを見ているクライアントは切り換えを知覚しないようにする。これにより、ユーザー体験が保証される。
本願のこの実施形態で説明した第1のライブ・メディア・ストリーム、第2のライブ・メディア・ストリーム、第3のライブ・メディア・ストリームなどは、コンテンツ源によって送信される同じライブ・メディア・ストリームであることに留意しておくべきである。それらのメディア・ストリームは、異なるクライアントのメディア要求メッセージに基づいてプロキシサーバーによって取得されるライブ・メディア・ストリームの間の区別をするために使用されている。ユーザーは異なる時点にライブ・ブロードキャスト・ルームに入室するため、プロキシサーバーによってクライアントに送信されるライブ・メディア・ストリームのタイムスタンプは異なる。よって、クライアントにライブ・メディア・ストリームを送信するとき、プロキシサーバーは、ライブ・ブロードキャスト・ルームに入る各クライアントが現在のライブ・メディア・コンテンツをすぐに見ることができるように、タイムスタンプを調整することができる。
以下は、本願の実施側面において提供される方法を具体的に記載する。
実施形態1
この実施形態は、ビデオ・ライブ・メディア・ストリーム送信方法を提供する。本方法は、図2に示されるビデオ・ライブ・ブロードキャスト・システムに適用されてもよい。本方法は：メディア・サーバーが、ライブ・ブロードキャスト・ルームに入る第1のクライアントおよび第2のクライアントのために、ライブ・メディア・ストリームを提供し、ここで、第1のクライアントと第2のクライアントはいずれも、同じプロキシサーバーを通じて、ライブ・ブロードキャスト・ルームに入る、ことを含む。さらに、図4A～図4Dに示されるように、本方法は、S1～S26の合計26ステップ（step、S）を含む。
S1～S12は、第1のクライアント（以下、「クライアントC1」という）がライブ・ブロードキャスト・ルームに入り、ライブ・メディア・ストリームを取得するプロセスである。S13～S26は、第2のクライアント（以下、「クライアントC2」という）がライブ・ブロードキャスト・ルームに入り、ライブ・メディア・ストリームを取得するプロセスである。
具体的には、クライアントC1がライブ・ブロードキャスト・ルームに入り、ライブ・メディア・ストリームを取得するプロセスは、以下のステップを含む。
S1：コンテンツ源が、EDC内のメディア・サーバーに第1のライブ・メディア・ストリームを送信する。
S2：EDC内のメディア・サーバーが、第1のライブ・メディア・ストリームを受信し、第1のライブ・メディア・ストリームを下位レベルのRDC内のメディア・サーバーに送信する。第1のライブ・メディア・ストリームが送信される前に、本方法はさらに、EDC内のウェブ・サーバーが下位レベルのRDC内のメディア・サーバーを認証するステップを含み、認証が成功した場合にのみ、EDC内のメディア・サーバーが第1のライブ・メディア・ストリームを下位レベルのRDC内のメディア・サーバーに送信する。
任意的に、S2はさらに：プロキシサーバー（proxy server）が、第1のライブ・メディア・ストリームのサービス特徴に基づいて、プロキシサーバーによってサービスされるクライアントに対応する伝送プロトコルを識別することを含む。サービス特徴は：ウェブ・サーバーのIPアドレスおよびポート番号を含む。たとえば、ハイパーテキスト転送プロトコル（Hyper Text Transfer Protocol、HTTP）について、構成設定可能なサービス特徴は：ウェブ・サーバーのIPアドレスおよびポート番号を含む。さらに、プロキシサーバーは、HTTPプロトコルに対応する伝送プロトコルが、メディア・ストリーム伝送のための伝送制御プロトコル（Transmission Control Protocol、TCP）であることを決定することができる。
S3：クライアントC1が、アクセス可能なメディア・サーバーのための要求メッセージをRDC内のウェブ・サーバーに送信する。さらに、要求メッセージは、クライアントC1のユーザー名およびIPアドレス、ライブ・ブロードキャスト・ルームの名前、および認証が成功した後にクライアントC1によって取得された鍵トークンなどの情報を含み、ここで、IPアドレスは、クライアントC1の位置を判別するために使用される。具体的には、クライアントC1は、要求メッセージをプロキシサーバーに送信し、次いで、プロキシサーバーは、要求メッセージをRDC内のウェブ・サーバーに転送する。
S4：RDC内のウェブ・サーバーが、要求メッセージを受信し、アクセス可能なメディア・サーバーのための応答メッセージをクライアントC1に送信する。該応答メッセージは、クライアントC1によってアクセス可能なメディア・サーバーをクライアントC1に通知するために使用される。具体的には、ウェブ・サーバーは、要求メッセージに基づいて、クライアントC1のためにメディア・ストリーム・サービスを提供することができるターゲット・メディア・サーバーを決定する；ここで、ターゲット・メディア・サーバーはRDC内の複数のメディア・サーバーの1つである；次いで、クライアントC1に応答メッセージを送信する；ここで、応答メッセージはターゲット・メディア・サーバーの関連情報、たとえば、ターゲット・メディア・サーバーの一様資源位置指定子（Uniform Resource Locator、URL）情報、IPアドレス、およびポート番号を含む。
任意的に、ウェブ・サーバーは、アクセス可能なメディア・サーバーのための、クライアントC1によって送信された要求メッセージにおいて担持されるIPアドレスに基づいてクライアントC1の位置を決定し、位置情報に基づいてクライアントC1に最も近いメディア・サーバーをターゲット・メディア・サーバーとして選択する。
任意的に、RDC内のウェブ・サーバーは、プロキシサーバーを通じてクライアントC1に応答メッセージを送信する。応答メッセージは、ターゲット・メディア・サーバーの関連情報、たとえば、ターゲット・メディア・サーバーのURL情報、IPアドレス、およびポート番号を担持する。
S5：クライアントC1は、ライブ・ブロードキャスト・ルームに入室し、プロキシサーバーに、ライブ・ブロードキャスト・ルームへの入室を要求する第1のライブ・ブロードキャスト・ルーム要求メッセージを送信する。ここで、第1のライブ・ブロードキャスト・ルーム要求メッセージは、クライアントC1がライブ・ブロードキャスト・ルームに入室することを要求することを示す。第1のライブ・ブロードキャスト・ルーム要求メッセージは、クライアントC1のユーザー名、IPアドレス、およびポート番号、ライブ・ブロードキャスト・ルームの名前、認証成功後に取得されたトークンなどを含む。
S6：プロキシサーバーは、クライアントC1によって送信された第1のライブ・ブロードキャスト・ルーム要求メッセージを受信し、クライアントC1の役割を設定する。ある可能な実装では、第1のライブ・ブロードキャスト・ルーム要求メッセージを受信した後、プロキシサーバーは、役割がマスター・ユーザーであるクライアントの総数に基づいてクライアントC1の役割を決定し；総数が第1の閾値以下である場合、クライアントC1の役割はマスター・ユーザーであり、または、総数が第1の閾値より大きい場合、クライアントC1の役割はスレーブ・ユーザーである。この実施形態では、第1の閾値が1であり、クライアントC1が最初にライブ・ブロードキャスト・ルームに入るユーザーであると仮定して、役割がマスター・ユーザーであるクライアントの数が現在の時点で第1の閾値に等しい場合、プロキシサーバーは、クライアントC1の役割がマスター・ユーザーであると決定する。
あるいはまた、別の可能な実装では、第1のライブ・ブロードキャスト・ルーム要求メッセージを受信した後、プロキシサーバーは、ライブ・ブロードキャスト・ルームにおいてマスター・ユーザーとして機能するクライアントが存在するかどうかを判定する。ライブ・ブロードキャスト・ルーム内にマスター・ユーザーとして機能するクライアントが存在する場合、プロキシサーバーは、クライアントC1の役割がスレーブ・ユーザーであると決定し；そうでない場合、プロキシサーバーは、クライアントC1がマスター・ユーザーであると決定する。
任意的に、本方法は：クライアントC1がライブ・ブロードキャスト・ルームに入った後、プロキシサーバーが「ライブ・ブロードキャスト・ルーム・ユーザー関係テーブル」を構築することを含み、ここで、「ライブ・ブロードキャスト・ルーム・ユーザー関係テーブル」がクライアントC1に関するエントリーを含む。具体的には、該エントリーの内容は：クライアントC1のIPアドレス、ポート番号、ユーザー役割、およびユーザー名、RDC内の選択されたターゲット・メディア・サーバーのIPアドレスおよびポート番号、ならびにライブ・ブロードキャスト・ルームの名前を含む。クライアントC1のIPアドレスは、データベースにキャッシュされたプライマリキー（primary key）であってもよい。わかることだが、最初にライブ・ブロードキャスト・ルームに入室するための、クライアントによって送信される要求メッセージを受信すると、プロキシサーバーは、ライブ・ブロードキャスト・ルーム要求メッセージに基づいて、ライブ・ブロードキャスト・ルーム内の各クライアントの状態を記録するためのライブ・ブロードキャスト・ルーム・ユーザー関係テーブルを構築する。
この実施形態では、役割がマスター・ユーザーであるクライアントの数は1である。具体的には、プロキシサーバーを通じてライブ・ブロードキャスト・ルームに入室するクライアントのうち、1人だけマスター・ユーザーが設定され、他のクライアントはスレーブ・ユーザーである。そのようなシナリオは、単一のマスター・ユーザーが存在するシナリオと称されることがある。
S7：プロキシサーバーが、第1のライブ・ブロードキャスト・ルーム要求メッセージをRDC内のメディア・サーバーに転送する。
ステップS6はステップS7の前に実行されてもよいし、あるいはステップS6はステップS7の後に実行されてもよい。これは、この実施形態において厳密には限定されない。
S8：RDC内のメディア・サーバーが、第1のライブ・ブロードキャスト・ルーム要求メッセージを受信し、第1のライブ・ブロードキャスト・ルーム応答メッセージをクライアントC1に送信する。ここで、第1のライブ・ブロードキャスト・ルーム応答メッセージは、クライアントC1が成功裏にライブ・ブロードキャスト・ルームに入ることをクライアントC1に通知するために使用される。具体的には、S8において、メディア・サーバーは、プロキシサーバーを通じて第1のライブ・ブロードキャスト・ルーム応答メッセージをクライアントC1に転送する。
S9：クライアントC1は、第1のメディア要求メッセージをプロキシサーバーに送信し、第1のメディア要求メッセージは、メディア・サーバーから第1のライブ・メディア・ストリームを取得することを要求するために使用される。任意的に、第1のメディア要求メッセージはクライアントC1の第1の識別子を担持し、ここで、第1の識別子はクライアントC1を一意的に識別するために使用される。この実施形態では、第1の識別子は、クライアントC1のIPアドレスおよびユーザー名などを含む。
S10：プロキシサーバーが、第1のメディア要求メッセージを受信し、RDC内のメディア・サーバーに転送する。ここで、メディア・サーバーはターゲット・メディア・サーバーである。第1のメディア要求メッセージは、マスター・ユーザーとして機能するクライアントC1によって要求され、よって、プロキシサーバーは、第1のメディア要求メッセージをメディア・サーバーに転送する。
S11：第1のメディア要求メッセージを受信した後、メディア・サーバーがクライアントC1に第1のメディア応答メッセージを送信し、第1のメディア応答メッセージは、クライアントC1が第1のライブ・メディア・ストリームを取得することを許容されることをクライアントC1に通知するために使用される。ある特定の実装では、プロキシサーバーが第1のメディア応答メッセージを受信し、クライアントC1に転送する。
S12：メディア・サーバーが、第1のライブ・メディア・ストリームをクライアントC1に送信する。具体的には、プロキシサーバーは、上位レベルのEDC内のメディア・サーバーによって送信された第1のライブ・メディア・ストリームをリアルタイムで取得し、次いで第1のライブ・メディア・ストリームをプロキシサーバーに送信する。第1のライブ・メディア・ストリームを受信した後、プロキシサーバーは、第1のライブ・メディア・ストリームのセグメントをGOPごとにローカルにキャッシュする。たとえば、プロキシサーバーは、t1-t2、t2-t3、t3-t4の3つの最新のGOPのメディア・ストリーム・セグメントをキャッシュし、キャッシュされたメディア・ストリームのすべてのセグメントは同じ時間長さをもつ。たとえば、キャッシュされた各GOPの時間長さは5秒である。プロキシサーバーは、キャッシュされた第1のライブ・メディア・ストリームのセグメントをクライアントC1に送信する。
任意的に、S12において、第1のライブ・メディア・ストリームをクライアントC1に送信するプロセスにおいて、第1のライブ・メディア・ストリームのタイムスタンプがさらに調整される必要があり、調整されたタイムスタンプは、クライアントC1に送信される第1のライブ・メディア・ストリームの最初のフレームのタイムスタンプが0であり、クライアントC1に送信される第1のライブ・メディア・ストリームの隣接する諸フレームのタイムスタンプが連続していることを満足する。「連続している」とは、クライアントC1によって受信された第1のライブ・メディア・ストリームの隣接するビデオ・フレームの時間長さが同じであり、該時間長さがフレームレート・パラメータfの逆数であることを意味する。
以下に、クライアントC2がライブ・ブロードキャスト・ルームに入り、ライブ・メディア・ストリームを取得する方法を説明する。具体的には、以下のステップが含まれる。
S13：クライアントC2は、アクセスされることが可能なメディア・サーバーに対する要求メッセージを、RDC内のウェブ・サーバーに送信する。この要求メッセージは、クライアントC2のユーザー名およびIPアドレス、ライブ・ブロードキャスト・ルームの名前、およびクライアントC2が認証された後に取得されたキートークンなどの情報を含む。具体的には、クライアントC2は、プロキシサーバーを通じて、要求メッセージをRDC内のウェブ・サーバーに転送し、要求メッセージの転送中に、プロキシサーバーは、要求メッセージに含まれる情報を取得する。
S14：RDC内のウェブ・サーバーは、要求メッセージを受信し、クライアントC2に応答メッセージを送信する。ここで、応答メッセージは、クライアントC2がアクセスできるメディア・サーバーをクライアントC2に通知するために使用される。これは、上記のステップS4と同様であり、ウェブ・サーバーは、クライアントC2のためにメディア・ストリーム・サービスを提供するために複数のメディア・サーバーのうちの1つを選択し、選択したメディア・サーバーの関連情報を応答メッセージを通じてプロキシサーバーに送信する。たとえば、選択されたメディア・サーバーの関連情報は、メディア・サーバーのURL情報、IPアドレス、およびポート番号を含む。
S15：クライアントC2は、ライブ・ブロードキャスト・ルームに入ることを要求するための第2のライブ・ブロードキャスト・ルーム要求メッセージをプロキシサーバーに送信する。ここで、第2のライブ・ブロードキャスト・ルーム要求メッセージは、クライアントC2がライブ・ブロードキャスト・ルームに入ることを要求することを示す。第2のライブ・ブロードキャスト・ルーム要求メッセージは、クライアントC2のユーザー名、IPアドレス、およびポート番号、ライブ・ブロードキャスト・ルームの名前、認証成功後に取得したトークンなどを含む。
S16：プロキシサーバーは、クライアントC2によって送信された第2のライブ・ブロードキャスト・ルーム要求メッセージを受信し、クライアントC2の役割を設定する。ある具体的な実装は、第2のライブ・ブロードキャスト・ルーム要求メッセージを受信した後、プロキシサーバーが、ライブ・ブロードキャスト・ルームにおいて役割がマスター・ユーザーであるクライアントが存在するかどうかを判定し、ライブ・ブロードキャスト・ルームにおいて役割がマスター・ユーザーであるクライアントが存在する場合、プロキシサーバーは、クライアントC2の役割がスレーブ・ユーザーであると決定するというものである。この実施形態では、現在のライブ・ブロードキャスト・ルームにおいてマスター・ユーザーとして機能しているクライアントC1が存在し、よって、クライアントC2はスレーブ・ユーザーとして決定される。
加えて、S16は、さらに：プロキシサーバーがクライアントC2に関するエントリーを「ライブ・ブロードキャスト・ルームユーザー関係テーブル」に追加することを含む。これは、上述のクライアントC1のエントリーの追加と同様である。クライアントC2については、エントリーの内容には、クライアントC2のIPアドレス、ポート番号、ユーザー役割、およびユーザー名、ターゲット・メディア・サーバーのIPアドレスおよびポート番号、ならびにライブ・ブロードキャスト・ルームの名前などの情報を含む。
任意的に、S16では、現在ライブ・ブロードキャスト・ルームにおいてマスター・ユーザーとして機能しているクライアントの数が計算され、マスター・ユーザーとして機能しているクライアントの数は、現時点において得られるライブ・ブロードキャスト・ルーム要求メッセージの数に基づいて決定されてもよい。ここで、ライブ・ブロードキャスト・ルーム要求メッセージの数は、「ライブ・ブロードキャスト・ルーム・ユーザー関係テーブル」に記録される。この実施形態では、プロキシサーバーは、クライアントC1からの第1のライブ・ブロードキャスト・ルーム要求メッセージとクライアントC2からの第2のライブ・ブロードキャスト・ルーム要求メッセージの2つのライブ・ブロードキャスト・ルーム要求メッセージを受信し、ライブ・ブロードキャスト・ルーム要求メッセージの数は1より大きい。よって、クライアントC2はスレーブ・ユーザーであると決定される。加えて、マスター・ユーザーとして機能するクライアントの数は、別の仕方で決定されてもよい。これは、この実施形態では限定されない。
S17：プロキシサーバーは、第2のライブ・ブロードキャスト・ルーム要求メッセージを受信し、RDC内のメディア・サーバーに転送する。
S18：RDC内のメディア・サーバーは、第2のライブ・ブロードキャスト・ルーム要求メッセージを受信し、第2のライブ・ブロードキャスト・ルーム応答メッセージをクライアントC2に送信する。ここで、第2のライブ・ブロードキャスト・ルーム応答メッセージは、クライアントC2が無事ライブ・ブロードキャスト・ルームに入ったことをクライアントC2に通知するために使用される。具体的には、メディア・サーバーは、プロキシサーバーを通じて、第2のライブ・ブロードキャスト・ルーム応答メッセージをクライアントC2に転送する。
S19：クライアントC2は、第2のメディア要求メッセージをプロキシサーバーに送信する。ここで、第2のメディア要求メッセージは、メディア・サーバーからライブ・メディア・ストリームを取得することを要求に使用される。第2のメディア要求メッセージはクライアントC2の第2の識別子を担持し、第2の識別子はクライアントC2のIPアドレスとユーザー名を含む。
第2のメディア要求メッセージが役割がスレーブ・ユーザーであるクライアントC2によって送信されているため、プロキシサーバーは、第2のメディア要求メッセージをメディア・サーバーに転送しない。
S20：プロキシサーバーは、第2のメディア要求メッセージを受信し、第2のメディア応答メッセージをクライアントC2に送信する。ここで、第2のメディア応答メッセージは、クライアントC2が第1のライブ・メディア・ストリームを取得することを許容されることをクライアントC2に通知するために使用される。
S21：プロキシサーバーは、ローカルにキャッシュされた第1のライブ・メディア・ストリームをクライアントC2に送信する。ここで、第1のライブ・メディア・ストリームはGOPごとにキャッシュされ、配信される。さらに、GOPごとにキャッシュされるメディア・ストリームのセグメントについては、S12の説明を参照されたい。詳細は、ここでは再度説明しない。
任意的に、プロキシサーバーが第1のライブ・メディア・ストリームをクライアントC2に送信する場合、本方法は、さらに：調整されたタイムスタンプが次の2つの制約を満たすように、メディア・ストリームのタイムスタンプを調整することを含む：1. クライアントC2によって受信された第1のライブ・メディア・ストリームの最初のフレームのタイムスタンプが0である、および2. クライアントC2に送信された第1のライブ・メディア・ストリーム・ビデオの隣接する諸フレームのタイムスタンプが連続していること、すなわち、送信のための時間長さがフレームレート・パラメータfの逆数であること。具体的な調整プロセスについては、前述の実施形態の説明を参照されたい。
S22：RDC内のメディア・サーバーは、第1のライブ・メディア・ストリームをリアルタイムでクライアントC1に送信する。具体的には、第1のライブ・メディア・ストリームは、プロキシサーバーを通じてクライアントC1に転送されてもよい。第1のライブ・メディア・ストリームは、ライブ・ブロードキャスト・ルームにおいて役割がマスター・ユーザーであるクライアントC1によって開始され、取得される。
S23：メディア・サーバーから第1のライブ・メディア・ストリームを受信した後、プロキシサーバーは、ライブ・メディア・ストリームのセグメントをGOPごとにローカルにキャッシュする。この実施形態では、プロキシサーバーは、3つのGOPをローカルにキャッシュし、さらに、より多数またはより少数のGOPをキャッシュしてもよい。
S24：プロキシサーバーは、「ライブ・ブロードキャスト・ルーム・ユーザー関係テーブル」のエントリーの内容に基づいて、マスター・ユーザーとして機能しているクライアントの数およびスレーブ・ユーザーとして機能しているクライアントの数を決定し、ライブ・ブロードキャスト・ルーム内のクライアントにセグメントを送信する準備をするよう、第1のライブ・ブロードキャスト・メディア・ストリームのキャッシュされたセグメントを複製する。この実施形態では、現在のライブ・ブロードキャスト・ルームにはクライアントC1とクライアントC2の2人のクライアントのみが存在する。ここで、クライアントC1がマスター・ユーザーであり、クライアントC2がスレーブ・ユーザーである。
S25：プロキシサーバーは、第1のライブ・メディア・ストリームをクライアントC1に送信する。さらに、本方法は：プロキシサーバーが、クライアントC1がメディア・ストリームのビデオ・フレームを受信する時点に基づいて、第1のライブ・メディア・ストリーム内のタイムスタンプを調整することをさらに含む。
S26：プロキシサーバーは、第1のライブ・メディア・ストリームをクライアントC2に送信する。さらに、本方法は：プロキシサーバーが、第1のライブ・メディア・ストリーム内のタイムスタンプを、クライアントC2がメディア・ストリームのビデオ・フレームを受信する時点に基づいて、調整することをさらに含む。
加えて、ライブ・ブロードキャスト・ルームに入室するユーザーによって視聴されるビデオ・フレームのタイムスタンプが調整され、ライブ・ブロードキャスト・ルーム内のクライアントC1およびクライアントC2が、第1のライブ・ブロードキャストのメディア・コンテンツを「同期して」視聴できるようにし、ユーザー体験を改善する。
本方法によれば、プロキシサーバーがマスター・ユーザーとして機能しているクライアントによって要求されたライブ・メディア・ストリームを得るために使用される場合、メディア・ストリームのセグメントの一部は、プロキシサーバー内にローカルにキャッシュされる。役割がスレーブ・ユーザーであるクライアントがライブ・ブロードキャスト・ルームに入り、ライブ・メディア・ストリームを要求すると、ローカルにキャッシュされているメディア・ストリームが、スレーブ・ユーザーとして機能しているクライアントに直接送信され、よって、メディア・サーバーは、ライブ・メディア・ストリームを再びプロキシサーバーに送信する必要がない。すなわち、メディア・サーバーは、プロキシサーバーにライブ・メディア・ストリームを1つだけ送信すればよく、プロキシサーバーは、そのライブ・メディア・ストリームを複製し、ライブ・ブロードキャスト・ルームにおいてスレーブ・ユーザーとして機能しているすべてのクライアントに配信することができる。これは、メディア・ストリームを送信するためのトラフィックを削減し、出口帯域幅を効果的に節約し、資源オーバーヘッドを削減する。
加えて、この方法によれば、同じライブ・ブロードキャスト・ルーム内のすべてのクライアントについて、メディア・サーバーは、1つのライブ・メディア・ストリームをプロキシサーバーに送信する必要があるだけであり、すなわち、該1つのライブ・メディア・ストリームを送信するための広域ネットワーク帯域幅が必要とされる。メディア・サーバーによってすべてのクライアントにライブ・メディア・ストリームを送信するために占有される伝送資源と比較すると、これは広域ネットワーク・リンクの負荷を低減し、すべてのクライアントがライブ・ブロードキャスト・メディアを受信した後、ライブ・メディア・ストリームの再生中のビデオのフリーズを回避し、よって、この方法を使用することによってユーザー体験をさらに改善する。
加えて、この実施形態の方法によれば、クライアントC1の第1のライブ・ブロードキャスト・ルーム要求メッセージおよび第1のメディア要求メッセージが1つのメッセージに組み合わされてもよく、組み合わされたメッセージは、第1のライブ・ブロードキャスト・ルーム要求メッセージおよび第1のメディア要求メッセージの機能を有する。よって、クライアントC1の役割がS6において決定されるとき、現在、ライブ・ブロードキャスト・ルームに入室するマスター・ユーザーとしてのクライアントの数は、第1のメディア要求メッセージの数に基づいて計算されうる。同様に、クライアントC2の第2のライブ・ブロードキャスト・ルーム要求メッセージおよび第2のメディア要求メッセージも、1つのメッセージに組み合わされてもよい。
加えて、この実施形態で提供される方法は、クライアントC2の役割がたとえばスレーブ・ユーザーからマスター・ユーザーに変化するときに、メディア・サーバーがクライアントC2にライブ・メディア・ストリームを送信するプロセスをさらに含む。さらに、図5Aおよび図5Bに示されるように、S27～S39は、以下のような具体的な方法手順である。
S27：クライアントC1は、プロキシサーバーに、ライブ・ブロードキャスト・ルームを退出するための要求メッセージを送信する。ここで、ライブ・ブロードキャスト・ルームを退出するための要求メッセージは、クライアントC1がライブ・ブロードキャスト・ルームを退出しようとしていることをメディア・サーバーに通知するために使用される。ライブ・ブロードキャスト・ルームを退出するための要求メッセージには、クライアントC1のユーザー名、IPアドレス、ポート番号、およびユーザー役割、ならびにライブ・ブロードキャスト・ルーム名などの情報を含む。
S28：クライアントC1から、ライブ・ブロードキャスト・ルームを退出するための要求メッセージを受信した後、プロキシサーバーは、一時的に、ライブ・ブロードキャスト・ルームを退出するための要求メッセージをメディア・サーバーに転送しない。これは、役割がマスター・ユーザーであるクライアントC1によって要求された第1のライブ・メディア・ストリームが、この時点でクライアントC2によって視聴されているためである。加えて、クライアントC1の役割は、退出する（Exiting）ユーザーとしてマークされ、「ライブ・ブロードキャスト・ルーム・ユーザー関係テーブル」に記録される。
S29：プロキシサーバーは、ライブ・ブロードキャスト・ルームにおけるあるクライアントを新しいマスター・ユーザーとして選択する。この実施形態では、ライブ・ブロードキャスト・ルームに存在するのはクライアントC1とクライアントC2だけである。クライアントC1がライブ・ブロードキャスト・ルームから出ることを要求すると、残りの一意的なクライアントC2が新しいマスター・ユーザーとして機能するクライアントとして選択され、クライアントC2の役割がスレーブ・ユーザーからマスター・ユーザーに変更される。たとえば、クライアントC2はスレーブからマスター・ユーザー（slave-to-master user）としてマークされる。
S30：プロキシサーバーが、メディア・ストリームを取得するための第3のメディア要求メッセージを、RDC内のメディア・サーバーに送信する。ここで、第3のメディア要求メッセージは、クライアントC2の第2の識別子を含む。第2の識別子はクライアントC2を一意的に識別するために使用される。言い換えると、第3のメディア要求メッセージにおける第2の識別子は、クライアントC2の役割が、メディア・サーバーからライブ・メディア・ストリームを要求するために使用されることを示す。
S31：RDC内のメディア・サーバーが、第3のメディア要求メッセージを受信し、第3のメディア応答メッセージをクライアントC2に送信する。ここで、第3のメディア応答メッセージは、クライアントC2がライブ・メディア・ストリームを取得することを許容されることをクライアントC2に通知するために使用される。
加えて、メディア・サーバーは、第3のメディア要求メッセージにおいて担持される第2の識別子を受信し、クライアントC2がメディア・サーバーへのライブ・メディア・ストリームを得るための要求を開始することを決定し、さらに、現在の要求メッセージにおいて担持される第2の識別子が、第1のメディア要求メッセージにおいて担持される第1の識別子と異なることを判別する。第1の識別子はクライアントC1を示すために使用され、現在の第2の識別子はクライアントC2を示すために使用され、それは、ライブ・メディア・ストリーム要求を開始するクライアントがクライアントC1からクライアントC2に変化することを示す。
S32：プロキシサーバーは、第3のメディア要求メッセージを開始するクライアントの役割がスレーブからマスター・ユーザー（slave-to-master user）であるため、第3のメディア応答メッセージを転送しない。この場合、クライアントC2の役割はマスター・ユーザーに変更され、「ライブ・ブロードキャスト・ルーム・ユーザー関係テーブル」においてクライアントC2に対応するエントリーに記録される。
S33：メディア・サーバーは、プロキシサーバーを通じてクライアントC2に第2のライブ・メディア・ストリームを送信する。第2のライブ・メディア・ストリームのコンテンツは、第1のライブ・メディア・ストリームのコンテンツと同じであり、第2のライブ・メディア・ストリームと第1のライブ・メディア・ストリームの両者は前記コンテンツ源からのものである。
S34：プロキシサーバーは、第2のライブ・メディア・ストリームを受信し、第2のライブ・メディア・ストリームをGOPごとにローカルにキャッシュする。
加えて、本方法は、さらに：プロキシサーバーが、整列アルゴリズムに従って、クライアントC1およびクライアントC2に送信されるライブ・メディア・ストリームを整列させることを含む。具体的には、このプロセスは：プロキシサーバーが第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)番目のフレームは、当然、隣接するフレームである。
S35：プロキシサーバーは、クライアントC2によって現在視聴されているビデオ・フレームの相対位置に基づいて、第2のライブ・メディア・ストリームのタイムスタンプを調整し、クライアントC2に送信されるビデオ・フレームが、クライアントC2によって受信される第2のライブ・メディア・ストリームの最初のフレームyのタイムスタンプと、第1のライブ・メディア・ストリームの最後のフレームxのタイムスタンプとが連続しており、対応する時間長さがフレームレート・パラメータfの逆数であることを満たすようにする。具体的な調整方法については、前述の実施形態における説明を参照されたい。詳細は、ここでは再度説明しない。
この実施形態では、役割がマスター・ユーザーであるクライアントC1がライブ・ブロードキャスト・ルームを出ると、新しいマスター・ユーザーとして機能するクライアントC2が、第2のライブ・メディア・ストリームを要求し取得するために使用され、第2のライブ・メディア・ストリームともともと送信された第1のライブ・メディア・ストリームとの間の時間差が調整され、それにより、プロキシサーバーは、第2のライブ・メディア・ストリームをクライアントC2に送信する際に、もともと再生されている第1のライブ・メディア・ストリーム・メディアのメディア・コンテンツから、第2のライブ・メディア・ストリームにシームレスに切り換える。このようにして、ビデオ・コンテンツがクライアントC2によって視聴されるとき、繰り返し再生される部分はなく、再生されるコンテンツは無欠であり、クライアントC2のユーザー体験は影響を受けない。
S36：プロキシサーバーは、ライブ・ブロードキャスト・ルームを退出するための要求メッセージをRDC内のメディア・サーバーに転送する。
S37：ライブ・ブロードキャスト・ルームから退出するための要求メッセージを受信した後、メディア・サーバーは、クライアントC1に対して、ライブ・ブロードキャスト・ルームから退出するための応答メッセージを送信する。ライブ・ブロードキャスト・ルームから退出するための応答メッセージは、クライアントC1が無事ライブ・ブロードキャスト・ルームから退出したことをクライアントC1に通知する。具体的には、ライブ・ブロードキャスト・ルームを退出するための応答メッセージは、プロキシサーバーを通じてクライアントC1に転送される。
S38：プロキシサーバーは、クライアントC1に対応するエントリーを「ライブ・ブロードキャスト・ルーム・ユーザー関係テーブル」から削除する。S37は、S38の前に実行されてもよく、あるいはS37は、S38の後に実行されてもよい。これは限定されない。
S39：プロキシサーバーは、ライブ・ブロードキャスト・ルームを退出するための応答メッセージをクライアントC1に転送する。
加えて、この方法はさらに：プロキシサーバーが、ライブ・ブロードキャスト・ルーム内でビデオを視聴しているクライアントC2に、第2のライブ・メディア・ストリームを送信することを含む。
この実施形態において提供される方法によれば、マスター・ユーザーとして機能しているクライアントがライブ・ブロードキャスト・ルームを出ると、プロキシサーバーは、ライブ・ブロードキャスト・ルーム内の新しいクライアントを新しいマスター・ユーザーとして選択し、新しいマスター・ユーザーの役割が、ライブ・メディア・ストリームを要求することを続けるために使用される。ライブ・メディア・ストリームが新しいマスター・ユーザーによって取得され、ビデオ・フレームのタイムスタンプが調整された後、新たに取得されたライブ・メディア・ストリームは、いまだライブ・ブロードキャスト・ルーム内でビデオを視聴しているクライアントに送られ、そのため、マスター・ユーザーとして機能するクライアントが退出したときに、他のクライアントは影響を受けない。この方法によれば、ライブ・メディア・ストリームの切り換え中に、繰り返し再生される部分はなく、再生されるコンテンツは無欠であり、ライブ・ブロードキャスト・ルーム内の他のユーザーはライブ・メディア・ストリームの切り換えに気付かないため、ユーザー体験は改善される。
実施形態2
この実施形態は、別のライブ・メディア・ストリーム送信方法を提供する。本方法は、複数のマスター・ユーザーが存在する技術シナリオに適用される。複数のマスター・ユーザーとは、役割がマスター・ユーザーである、ライブ・ブロードキャスト・ルーム内のクライアントの指定された数（すなわち、事前設定された上限）が2以上であることを意味する。さらに、複数のマスター・ユーザーは、主要マスター・ユーザーとして識別されうる1人の主要マスター・ユーザーを含み；副次マスター・ユーザーとして識別されうる複数の副次マスター・ユーザーを含み、さらに、役割がスレーブ・ユーザーである少なくとも1人のクライアントを含む。この方法においてライブ・ブロードキャスト・ルームへの入室を要求し、ライブ・メディア・ストリームを取得するプロセスは、実施形態1において記載されたプロセスと同じである。違いは、クライアントの役割の識別および変更と、ライブ・メディア・ストリームの配信にある。
実施形態1に基づき、この実施形態では、さらに第3のクライアントC3が含まれ、ライブ・ブロードキャスト・ルーム内の役割がマスター・ユーザーであるクライアントの数が2に設定される、すなわち、事前設定された上限は2である。この場合、各クライアントがライブ・ブロードキャスト・ルームに入り、ライブ・メディア・ストリームを取得することを要求するプロセスは、図6Aおよび図6Bに示されるように、以下のステップを含む。
S1～S12は、クライアントC1がライブ・ブロードキャスト・ルームに入り、ライブ・メディア・ストリームを取得することを要求するプロセスである。このプロセスは、実施形態1におけるS1～S12と同じであり、唯一の違いは：S6では、「ライブ・ブロードキャスト・ルーム・ユーザー関係テーブル」が確立されるときに、クライアントC1の役割が主要マスター・ユーザー（main-master user）として設定されるということである。他のステップについては、実施形態1の説明を参照されたい。詳細は、ここでは再度説明しない。
プロキシサーバーがメディア・サーバーによって送信される第1のライブ・メディア・ストリームを取得するとき、プロキシサーバーは、第1のライブ・メディア・ストリームのいくつかのセグメントをGOPごとにローカルにキャッシュし、第1のライブ・メディア・ストリームのセグメントをリアルタイムで更新し、第1のライブ・メディア・ストリームのセグメントをクライアントC1に送信する。
S13～S29は、クライアントC2がライブ・ブロードキャスト・ルームに入室し、ライブ・メディア・ストリームを取得することを要求するプロセスである。具体的には、詳細は以下のとおりである。
S13、S14は、クライアントC2がライブ・ブロードキャスト・ルームに入室し、アクセス可能なメディア・サーバーを取得するための要求メッセージを開始し、応答メッセージを取得するプロセスである。これは、実施形態1のS13、S14と同じであり、詳細は再度説明しない。
S15：クライアントC2が、第2のライブ・ブロードキャスト・ルーム要求メッセージをプロキシサーバーに送信する。
S16：クライアントC2によって送信された第2のライブ・ブロードキャスト・ルーム要求メッセージを受信した後、プロキシサーバーは、現在のライブ・ブロードキャスト・ルーム内のライブ・ブロードキャスト・ルーム要求メッセージの数を計算し、計算された数に基づいて、クライアントC2の役割を決定する。この実施形態では、プロキシサーバーは、クライアントC1およびクライアントC2から2つのライブ・ブロードキャスト・ルーム要求メッセージを取得する。加えて、数が事前設定された上限2に等しい場合、プロキシサーバーは、クライアントC2の役割が副次マスター・ユーザー（secondary-master user）であると判断する。あるいはまた、プロキシサーバーが第2のライブ・ブロードキャスト・ルーム要求メッセージを受信し、ライブ・ブロードキャスト・ルーム内で役割がマスター・ユーザーであるクライアントの数が事前設定された上限に達している場合、プロキシサーバーは、クライアントC2の役割がスレーブ・ユーザーであると決定する。
任意的に、ライブ・ブロードキャスト・ルーム内で役割がマスター・ユーザーであるクライアントの数が0ではなく、事前設定された上限に達しない場合、プロキシサーバーは、クライアントC2の役割が副次マスター・ユーザーであると決定する。ライブ・ブロードキャスト・ルーム内で役割がマスター・ユーザーであるクライアントの数が0である場合、プロキシサーバーはクライアントC2の役割が主要マスター・ユーザーであると決定する。
加えて、本方法は、さらに：「ライブ・ブロードキャスト・ルーム・ユーザー関係テーブル」にクライアントC2に関するエントリーを追加することを含む。
S17：プロキシサーバーは、第2のライブ・ブロードキャスト・ルーム要求メッセージをメディア・サーバーに転送する。
S18：RDC内のメディア・サーバーは、第2のライブ・ブロードキャスト・ルーム要求メッセージを受信し、第2のライブ・ブロードキャスト・ルーム応答メッセージをクライアントC2に送信する。ここで、第2のライブ・ブロードキャスト・ルーム応答メッセージは、クライアントC2が無事ライブ・ブロードキャスト・ルームに入ることをクライアントC2に通知するために使用される。
S19：クライアントC2は、プロキシサーバーに第2のメディア要求メッセージを送信する。
S20：第2のメディア要求メッセージを受信した後、プロキシサーバーは第2のメディア要求メッセージをメディア・サーバーに転送する。第2のメディア要求メッセージはクライアントC2の第2の識別子を含んでおり、よって、クライアントC2は、クライアントC2の副次マスター・ユーザーの役割を使用して、メディア・サーバーからのライブ・メディア・ストリームを要求する。
S21：メディア・サーバーはクライアントC2に第2のメディア応答メッセージを送信し、クライアントC2が第1のライブ・メディア・ストリームを取得することを許容されることをクライアントC2に通知する。
S22：プロキシサーバーは、ローカルにキャッシュされた第1のライブ・メディア・ストリームをクライアントC2に送信する。ここで、第1のライブ・メディア・ストリームは、GOPごとにキャッシュされるメディア・ストリーム・セグメントである。たとえば、プロキシサーバーは3つのGOPセグメントをキャッシュする。任意的に、本方法は、さらに：プロキシサーバーが、クライアントC2によって取得されるビデオ・フレームの再生時間に基づいて第1のライブ・メディア・ストリームのタイムスタンプを調整して、調整されたタイムスタンプが、クライアントC2に送信される第1のライブ・メディア・ストリームの最初のフレームのタイムスタンプが0であり、クライアントC2に送信される第1のライブ・メディア・ストリームの隣接する諸フレームのタイムスタンプが連続していることを満たすようにすることを含む。
S23：メディア・サーバーは、第2のライブ・メディア・ストリームをリアルタイムでクライアントC2に送信する。
S24：プロキシサーバーは、第2のライブ・メディア・ストリームのセグメントを受信し、それらのセグメントをGOPごとにキャッシュする。第2のライブ・メディア・ストリームは、副次マスター・ユーザーの役割を使用してクライアントによって取得されるので、「ライブ・ブロードキャスト・ルーム・ユーザー関係テーブル」に基づいて、第2のライブ・メディア・ストリームだけがプロキシサーバーにおいてローカルにキャッシュされ、複製されて他のクライアントに配信されることはない。
加えて、本方法はさらに、第1のライブ・メディア・ストリームと第2のライブ・メディア・ストリームとを整列させることを含む。具体的には、2つのライブ・メディア・ストリームを整列させるプロセスは、上記の実施形態1におけるS34と同じである。詳細は、ここでは再度説明しない。
S25：メディア・サーバーは、第1のライブ・メディア・ストリームをリアルタイムでクライアントC1に送信する。
S26：第1のライブ・メディア・ストリームを受信した後、プロキシサーバーは、第1のライブ・メディア・ストリームのいくつかのセグメントをGOPごとにキャッシュする。
S27：プロキシサーバーは、「ライブ・ブロードキャスト・ルーム・ユーザー関係テーブル」に基づいて、第1のライブ・メディア・ストリームのコピーを1つ作成する。これは、現在のライブ・ブロードキャスト・ルームには、役割がマスター・ユーザーであるクライアントC1のほか、1人のクライアントC2しか存在しないためである。より多くのクライアントが存在する場合は、コピー数は、そのユーザー役割が現在のライブ・ブロードキャスト・ルームにおける退出するユーザー（exiting user）ではないクライアント数と同じであることを理解すべきである。
この実施形態では、プロキシサーバーは、役割が主要マスター・ユーザーであるクライアントのライブ・メディア・ストリームと、役割が副次マスター・ユーザーであるクライアントのライブ・メディア・ストリームとをローカルにキャッシュする。プロキシサーバーは、役割が主要マスター・ユーザーであるクライアントのライブ・メディア・ストリームを、ライブ・ブロードキャスト・ルーム内のすべてのクライアントに直接配信してもよい。プロキシサーバーは、役割が副次マスター・ユーザーであるクライアントの対応するライブ・メディア・ストリームをローカルにキャッシュして、その後の切り換えおよび配信に備える。具体的なトリガー条件は次のとおり：副次マスター・ユーザーとして機能しているクライアントの役割が主要マスター・ユーザーに変更されるときに、その新しい主要マスター・ユーザーのメディア・ストリーム（プロキシサーバーにおいてローカルにキャッシュされている）が、ライブ・ブロードキャスト・ルーム内の他のクライアントに配信される。プロキシサーバーは、新しいライブ・メディア・ストリームを迅速に配信できる。これは、配信速度を高め、メディア・ストリームの効率を改善し、待ち時間を短縮するのに役立つ。
S28：プロキシサーバーは、第1のライブ・メディア・ストリームをクライアントC1に送信する。
S29：プロキシサーバーは、第1のライブ・メディア・ストリームをクライアントC2に送信する。
任意的に、ステップS28およびS29において、本方法はさらに：プロキシサーバーが、クライアントC1の再生時間およびクライアントC2の再生時間に基づいて第1のライブ・メディア・ストリームのタイムスタンプを調整し、ライブ・ブロードキャスト・ルーム内のそれらのクライアントによって視聴されるライブ・コンテンツの同期を確実にすることを含む。
S30～S44は、クライアントC3がライブ・ブロードキャスト・ルームに入り、ライブ・メディア・ストリームを要求し取得するプロセスである。図7Aおよび図7Bに示されるように、詳細は以下の通りである。
S30、S31は、クライアントC3がライブ・ブロードキャスト・ルームに入室し、アクセス可能なメディア・サーバーを取得するための要求メッセージを開始し、応答メッセージを取得するプロセスである。このプロセスは、実施形態1におけるS13、S14と同じである。詳細は、再度記載しない。
S32：クライアントC3は、ライブ・ブロードキャスト・ルームに入ることを要求するための第3のライブ・ブロードキャスト・ルーム要求メッセージをプロキシサーバーに送信する。ここで、第3のライブ・ブロードキャスト・ルーム要求メッセージは、クライアントC3の第3の識別子を含む。
S33：プロキシサーバーは、第3のライブ・ブロードキャスト・ルーム要求メッセージを受信し、クライアントC3のユーザー役割を決定する。具体的には、第3のライブ・ブロードキャスト・ルーム要求メッセージが取得されたとき、現在のライブ・ブロードキャスト・ルームにおける役割がマスター・ユーザーであるクライアントの数が事前設定された上限（事前設定された上限は2）に達していれば、プロキシサーバーは、クライアントC3の役割がスレーブ・ユーザーであると決定する。
加えて、この方法は、さらに：クライアントC3に関するエントリーを「ライブ・ブロードキャスト・ルーム・ユーザー関係テーブル」に追加することを含み、エントリーの内容は、クライアントC3の名前、IPアドレス、ポート番号、およびユーザー役割、ライブ・ブロードキャスト・ルームの名前、ならびにメディア・サーバーの名前、IPアドレス、およびポート番号などの情報を含む。
S34：プロキシサーバーは、第3のライブ・ブロードキャスト・ルーム要求メッセージをメディア・サーバーに転送する。
S35：メディア・サーバーは、第3のライブ・ブロードキャスト・ルーム応答メッセージをクライアントC3に送信し、ここで、第3のライブ・ブロードキャスト・ルーム応答メッセージは、クライアントC3が無事ライブ・ブロードキャスト・ルームに入ることをクライアントC3に通知するために使用される。
S36：クライアントC3は、第3のメディア要求メッセージをプロキシサーバーに送信し、ここで、第3のメディア要求メッセージは、メディア・サーバーからのライブ・メディア・ストリームを取得することを要求するために使用され、第3のメディア要求メッセージは、クライアントC3の識別子を含む。
S37：クライアントC3は、プロキシサーバーによって第3のメディア要求メッセージに基づいてフィードバックされる第3のメディア応答メッセージを受信する。この場合、クライアントC3の役割はスレーブ・ユーザーである。
S38：プロキシサーバーは、ローカルにキャッシュされた第1のライブ・メディア・ストリームをクライアントC3に送信する。
S39：メディア・サーバーは、第1のライブ・メディア・ストリームをリアルタイムでクライアントC1に送信する。
S40：第1のライブ・メディア・ストリームを受信した後、プロキシサーバーは、第1のライブ・メディア・ストリームのセグメントをGOPごとにキャッシュする。
S41：プロキシサーバーは、「ライブ・ブロードキャスト・ルーム・ユーザー関係テーブル」に基づいて第1のライブ・メディア・ストリームを複製し、具体的には、第1のライブ・メディア・ストリームのコピーを2つ作成する。ここで、一方のコピーは、役割が副次マスター・ユーザーであるクライアントC2のためであり、他方のコピーは、役割がスレーブ・ユーザーであるクライアントC3のためである。
S42：プロキシサーバーは、第1のライブ・メディア・ストリームをクライアントC1に送信する。加えて、本方法はさらに：プロキシサーバーが第1のライブ・メディア・ストリームのタイムスタンプを調整することを含む。
S43：プロキシサーバーは、第1のライブ・メディア・ストリームをクライアントC2に送信する。加えて、本方法はさらに：プロキシサーバーが第1のライブ・メディア・ストリームのタイムスタンプを調整することを含む。
S44：プロキシサーバーは、第1のライブ・メディア・ストリームをクライアントC3に送信する。加えて、本方法はさらに：プロキシサーバーが第1のライブ・メディア・ストリームのタイムスタンプを調整することをさらに含む。
この実施形態の方法によれば、異なるクライアントのメディア要求を取得するとき、プロキシサーバーは、各クライアントのユーザー役割を識別し、それにより、プロキシサーバーは、マスター・ユーザーのライブ・メディア・ストリームのみをメディア・サーバーから取得する。主要マスター・ユーザーと副次マスター・ユーザーがある。ライブ・メディア・ストリームは、スレーブ・ユーザーのためには取得されないが、プロキシサーバーによってローカルにキャッシュされている第1のライブ・メディア・ストリームのセグメントが、対応するクライアントに送信される。これは、メディア・サーバーがスレーブ・ユーザーとして機能しているクライアントにライブ・メディア・ストリームを送信することを防ぎ、さらに、ライブ・ブロードキャスト・ルームにおける、役割がスレーブ・ユーザーであるクライアントによって要求されるライブ・メディア・ストリームの数を減らす。この方法を使用すると、メディア・サーバーとプロキシサーバーとの間のライブ・メディア・ストリーム伝送のための資源オーバーヘッドが削減される。
加えて、この実施形態において提供される方法は、さらに、次のプロセスを含む：クライアントC1がライブ・ブロードキャスト・ルームを出た後、メディア・サーバーは、ライブ・ブロードキャスト・ルーム内のクライアントC2およびクライアントC3にライブ・メディア・ストリームを送信し続ける。具体的には、図8Aおよび図8Bに示されるように、プロセスは、S45～S59を含む。方法手順は、実施形態1におけるクライアントC1の退出プロセスと同様であるが、ライブ・ブロードキャスト・ルーム内のクライアントC2およびクライアントC3のために構成設定されたアイデンティティ役割が異なり、クライアントC2およびクライアントC3に送信されるライブ・メディア・ストリームが異なるという点において相違がある。具体的には、図8Aおよび図8Bに示されるように、本方法は、以下のステップを含む。
S45：クライアントC1が、プロキシサーバーに対して、ライブ・ブロードキャスト・ルームを退出するための要求メッセージを送信する。
S46：プロキシサーバーが、クライアントC1から、ライブ・ブロードキャスト・ルームを退出するための要求メッセージを受信し、「ライブ・ブロードキャスト・ルーム・ユーザー関係テーブル」においてクライアントC1のユーザー役割を退出する（Exiting）ユーザーとしてマークし、クライアントC2のユーザー役割を主要マスター・ユーザーに変更する。
S47：プロキシサーバーは、ライブ・ブロードキャスト・ルームを退出するための要求メッセージをメディア・サーバーに転送する。
S48：プロキシサーバーは、ライブ・ブロードキャスト・ルーム・ユーザー関係テーブルにおいて同定されているすべてのスレーブ・ユーザーのうちから1人のスレーブ・ユーザーを選択し、該スレーブ・ユーザーをスレーブから副次マスター・ユーザー（slave to secondary master user）に変更する。この実施形態では、選択され変更されたクライアントはクライアントC3である。
S49：プロキシサーバーは、第3のメディア要求メッセージをメディア・サーバーに送信する。ここで、第3のメディア要求メッセージはクライアントC3の第3の識別子を担持する。言い換えると、プロキシサーバーは、クライアントC3の役割を使用して、第3のメディア要求メッセージをメディア・サーバーに送信する。
S50：メディア・サーバーは、プロキシサーバーを通じてクライアントC1にライブ・ブロードキャスト・ルームを退出するための応答メッセージを送信する。ここで、ライブ・ブロードキャスト・ルームを退出するための応答メッセージは、クライアントC1が無事ライブ・ブロードキャスト・ルームを退出したことをクライアントC1に通知するために使用される。加えて、本方法はさらに：プロキシサーバーが「ライブ・ブロードキャスト・ルーム・ユーザー関係テーブル」からクライアントC1の関連するエントリーを削除することを含む。
S51：プロキシサーバーが、第3のメディア要求メッセージに基づいてメディア・サーバーによってフィードバックされる第3のメディア応答メッセージを受信する。
S52：クライアントC3の現在の役割は、スレーブから副次マスター・ユーザー（slave to secondary master user）であり、プロキシサーバーは、一時的に第3のメディア応答メッセージを転送しないが、「ライブ・ブロードキャスト・ルーム・ユーザー関係テーブル」においてクライアントC3のユーザーの役割を副次マスター・ユーザー（secondary-master user）に変更する。
S53：メディア・サーバーは、プロキシサーバーを通じてクライアントC3に第3のライブ・メディア・ストリームを送信し、それにより、プロキシサーバーは第3のライブ・メディア・ストリームを受信する。
S54：プロキシサーバーは、第3のライブ・メディア・ストリームをGOPごとにキャッシュし、整列アルゴリズムに従って第3のライブ・メディア・ストリームと第2のライブ・メディア・ストリームを整列させる。ライブ・メディア・ストリームを整列させる具体的なプロセスは、上記の実施形態1におけるS34と同様である。詳細についてはS34の関連記述を参照されたい。詳細は、ここでは再度説明しない。
この実施形態では、ライブ・ブロードキャスト・ルーム内の主要マスター・ユーザーとして機能しているクライアントが退出するとき、ライブ・ブロードキャスト・ルームを退出しない副次マスター・ユーザーの身元（identity）を用いてライブ・メディア・ストリームが要求され、ライブ・メディア・ストリームを取得するクライアントの役割が変更され、受信される新しいライブ・メディア・ストリームに対して整列が実行される。このように、他のユーザーがライブ・ビデオを見るときに、繰り返し再生されるピクチャーがなく、再生されるビデオ・コンテンツは無欠であり、そのため、マスター・ユーザーがライブ・ブロードキャスト・ルームを出るときに、他のユーザーは影響を受けない。
ステップS46とステップS47との間で、プロキシサーバーは、ライブ・ブロードキャスト・ルーム内のクライアント（たとえば、クライアントC2）に送信される第1のライブ・メディア・ストリームを第2のライブ・メディア・ストリームに切り換える。メディア・サーバーは、プロキシサーバーを通じて、クライアントC2に第2のライブ・メディア・ストリームを連続的に送信する。切り換え後、プロキシサーバーは、連続的に受信された第2のライブ・メディア・ストリームをライブ・ブロードキャスト・ルーム内のクライアントに配信する。詳細については、以下のステップを参照されたい。
S55：メディア・サーバーは、第2のライブ・メディア・ストリームをクライアントC2に送信する。
S56：プロキシサーバーは、第2のライブ・メディア・ストリームをGOPごとにキャッシュする。加えて、本方法は、さらに：プロキシサーバーが第2のライブ・メディア・ストリームのタイムスタンプを調整することを含む。
S57：プロキシサーバーは、「ライブ・ブロードキャスト・ルーム・ユーザー関係テーブル」に基づいて、第2のライブ・メディア・ストリームを複製する。ここで、コピーの数は、ライブ・ブロードキャスト・ルーム内で役割が退出するユーザー（exiting user）でないすべてのクライアントの数である。
S58：プロキシサーバーは、第2のライブ・メディア・ストリームをクライアントC2に送信する。加えて、本方法はさらに：プロキシサーバーが第2のライブ・メディア・ストリームのタイムスタンプを調整することを含む。
S59：プロキシサーバーは、第2のライブ・メディア・ストリームをクライアントC3に送信する。加えて、本方法は：プロキシサーバーが第2のライブ・メディア・ストリームのタイムスタンプを調整することを含む。
具体的には、タイムスタンプ調整プロセスについては、上記の実施形態の説明を参照されたい。この実施形態では、詳細は説明されない。
この実施形態における方法によれば、役割が主要マスター・ユーザーであるクライアントC1がライブ・ブロードキャスト・ルームを退出することを要求するとき、プロキシサーバーは、主要マスター・ユーザーとして機能しているクライアントC1から、ライブ・ブロードキャスト・ルームを退出するための要求メッセージを受信した後、クライアントC1は、一時的に、ライブ・ブロードキャスト・ルームを退出するための、ユーザーからの要求メッセージを転送しない。代わりに、プロキシサーバーはクライアントを新しい主要マスター・ユーザーとして選択し、新しい主要マスター・ユーザーの役割が、ライブ・メディア・ストリームを要求するために使用される。プロキシサーバーは、ライブ・メディア・ストリームを複製して他のクライアントに配信し、メディア・ストリームの配信中に整列を行なう。これにより、メディア・ストリームを視聴している他のクライアントは、視聴されているメディア・ストリームに対応するマスター・ユーザーが退出するときに影響を受けないことが保証される。
任意的に、この実施形態において提供される方法は、役割が副次マスター・ユーザーであるクライアントC2もライブ・ブロードキャスト・ルームからの退出を要求するプロセスをさらに含む。このプロセスは、クライアントC1がライブ・ブロードキャスト・ルームを退出する上記のプロセスと同様である。
具体的には、図8Aおよび図8Bに示されるように、ステップS52とステップS53との間に、次のステップがさらに含まれる：クライアントC2が、プロキシサーバーに対して、ライブ・ブロードキャスト・ルームを退出するための要求メッセージを送信し、ここで、該要求メッセージは、クライアントC2の関連情報を含む。プロキシサーバーが、クライアントC2から、ライブ・ブロードキャスト・ルームを退出するための要求メッセージを受信すると、クライアントC2に送信されるライブ・メディア・ストリームは視聴されているので、クライアントC2のユーザー役割が退出する（exiting）ユーザーにリフレッシュされる。この場合、クライアントC2からの、ライブ・ブロードキャスト・ルームを退出するための要求メッセージは一時的に転送されない。
次いで、S54の後、本方法は、さらに：プロキシサーバーが、視聴されているのメディア・ストリームに対応するクライアントC2が退出することを判別し、プロキシサーバーは、各ユーザーが視聴しているフレームの相対的位置に基づいて、ライブ・メディア・ストリームをクライアントC3に送信されるメディア・ストリームにスムーズに切り換え、クライアントC3の役割を主要マスター・ユーザーにリフレッシュする。加えて、この方法はさらに：プロキシサーバーが、ライブ・ブロードキャスト・ルームを退出するための、クライアントC2からの要求メッセージをメディア・サーバーに転送し；ライブ・ブロードキャスト・ルームを退出するための、メディア・サーバーからクライアントC2に送信された応答メッセージを受信し；ライブ・ブロードキャスト・ルームを退出するための該応答メッセージをクライアントC2に転送することを含む。加えて、この方法はさらに：プロキシサーバーがクライアントC2に対応するエントリーを「ライブ・ブロードキャスト・ルーム・ユーザー関係テーブル」から削除することを含む。
最後に、メディア・サーバーから第3のライブ・メディア・ストリームを受信した後、プロキシサーバーは、第3のライブ・メディア・ストリームをGOPごとにローカルにキャッシュし、第3のライブ・メディア・ストリームを複製して、ライブ・ブロードキャスト・ルーム内の退出するユーザーでないすべてのクライアントに配信する。この場合、ライブ・ブロードキャスト・ルームに存在するのはクライアントC3のみであり、プロキシサーバーは、メディア・サーバーによって送信されるライブ・メディア・ストリームをクライアントC3に送信する。任意的に、クライアントC3にライブ・メディア・ストリームを送信するとき、プロキシサーバーはさらに、クライアントC3のユーザー体験に影響するのを避けるために、ユーザーのビデオ・フレームの再生時間に基づいてメディア・ストリーム中のタイムスタンプを調整する。このようにして、クライアントC1およびクライアントC2がライブ・ブロードキャスト・ルームを出るとき、メディア・ストリーム・ビデオの繰り返し再生される部分はなく、再生されるビデオ・コンテンツは無欠である。
本願のこの実施形態において提供される一方的ビデオ・ライブ・ブロードキャスト技術によれば、プロキシサーバーは、ユーザー役割を識別して使用することによって、役割がマスター・ユーザーであるクライアントのメディア・ストリームをメディア・サーバーから要求し、取得し；主要マスター・ユーザーによって要求されたメディア・ストリームを複製して、同じライブ・ブロードキャスト・ルーム内の他のユーザーに配信する。このようにして、同じライブ・ブロードキャスト・ルーム内の諸ユーザーがメディア・ビデオを見るとき、メディア・サーバーからプロキシサーバーに送信されるメディア・ストリームについては、マスター・ユーザーによって要求されるメディア・ストリームだけが帯域幅を消費する。これは、出口帯域幅コストと広域ネットワーク・リンク負荷を効果的に低減する。加えて、本方法によれば、メディア・サーバーは、クライアントについて独立した認証を構成設定する必要がなく、それにより、運用および保守コストをさらに低減する。
以下は、本願の上記の方法実施形態に対応する装置およびハードウェア・デバイスの実施形態を記載する。
図9は、本願のある実施形態によるメディア・ストリーム送信装置の概略構造図である。本装置は、上記の諸実施形態で説明したプロキシサーバーであってもよい。
さらに、本装置は、受信ユニット901、処理ユニット902、送信ユニット903を含む。加えて、本装置は、さらに、別の機能モジュールまたはユニット、たとえば、記憶ユニットを含んでいてもよい。本装置はサーバーであってもよく、上記の諸実施形態におけるメディア・ストリーム送信方法を実行するように構成される。たとえば、本装置は、ライブ・ブロードキャスト・ルームに入る少なくとも2人のユーザーのためにライブ・メディア・ストリームを提供する。
具体的には、受信ユニット901は、第1のクライアントから、ライブ・ブロードキャスト・ルームに入ることを要求するための第1のライブ・ブロードキャスト・ルーム要求メッセージを受信するように構成される。処理ユニット902は：第1のライブ・ブロードキャスト・ルーム要求メッセージに基づいて第1のクライアントの役割を決定し、第1のクライアントの役割を決定するように構成される。送信ユニット903は：第1のクライアントの役割がスレーブ・ユーザーであると決定される場合、ローカルにキャッシュされている第1のライブ・メディア・ストリームを第1のクライアントに送信するように構成され、第1のライブ・メディア・ストリームは、メディア・サーバーによってプロキシサーバーを通じて第2のクライアントに転送されるメディア・ストリームであり、第2のクライアントの役割はマスター・ユーザーである。
任意的に、この実施形態のある個別的な実装では、処理ユニット902は具体的には：第1のライブ・ブロードキャスト・ルーム要求メッセージが受信されたときに、ライブ・ブロードキャスト・ルーム内に役割がマスター・ユーザーであるクライアントがいるかどうかを判定し；ライブ・ブロードキャスト・ルーム内に役割がマスター・ユーザーであるクライアントがいれば、第1のクライアントの役割がスレーブ・ユーザーであると決定する、あるいはライブ・ブロードキャスト・ルーム内に役割がマスター・ユーザーであるクライアントがいなければ、第1のクライアントの役割がマスター・ユーザーであると決定するように構成される。
任意的に、この実施形態の別の個別的な実装では、受信ユニット901はさらに：第1のライブ・メディア・ストリームが第1のクライアントに送信される前に、第1のクライアントから第1のメディア要求メッセージを受信し、第1のメディア要求メッセージをメディア・サーバーに転送することをスキップするように構成されており；送信ユニット903はさらに、第1のクライアントに第1のメディア応答メッセージを送信するように構成されており、第1のメディア応答メッセージは、第1のクライアントがメディア・ストリームを取得することを許可されていることを第1のクライアントに通知するために使用される。
任意的に、この実施形態のさらに別の個別的な実装では、第1のメディア要求メッセージは、第1のクライアントの識別子を含む。受信ユニット901はさらに：第1のライブ・メディア・ストリームが第1のクライアントに送信された後、第2のクライアントから、ライブ・ブロードキャスト・ルームを退出するための要求メッセージを受信するように構成される。処理ユニット902はさらに：第1のクライアントを新しいマスター・ユーザーとして決定するとき、第1のクライアントの役割をスレーブ・ユーザーからマスター・ユーザーに変更するように構成される。送信ユニット903は、第2のメディア要求メッセージをメディア・サーバーに送信するように構成され、第2のメディア要求メッセージは、第1のクライアントの識別子を含む。受信ユニット901は、第2のメディア要求メッセージに基づいてメディア・サーバーによって送信された第2のライブ・メディア・ストリームを受信するように構成される。送信ユニット903は、第1のクライアントに送信される第1のライブ・メディア・ストリームを第2のライブ・メディア・ストリームに切り換えることを含む。
任意的に、この実施形態のさらに別の個別的な実装では、処理ユニット902は具体的には：第1のライブ・ブロードキャスト・ルーム要求メッセージが受信されたときに、ライブ・ブロードキャスト・ルームにおける、役割がマスター・ユーザーであるクライアントの数が事前設定された上限に達しているかどうかを判定する段階であって、前記事前設定された上限は1より大きい、段階と；ライブ・ブロードキャスト・ルームにおける、役割がマスター・ユーザーであるクライアントの数が事前設定された上限に達していれば、第1のクライアントの役割がスレーブ・ユーザーであると決定する段階とを実行するように構成される。
任意的に、この実施形態のさらに別の個別的な実装では、処理ユニット902はさらに、ライブ・ブロードキャスト・ルームにおける、役割がマスター・ユーザーであるクライアントの数が0ではないが事前設定された上限には達しない場合、第1のクライアントの役割が副次マスター・ユーザーであると決定するように構成される。
任意的に、この実施形態のさらに別の個別的な実装では、第1のクライアントがスレーブ・ユーザーである場合、受信ユニット901はさらに、第2のクライアントから、ライブ・ブロードキャスト・ルームを退出するための要求メッセージを受信するように構成される。処理ユニット902はさらに：第1のクライアントを新しい副次マスター・ユーザーとして決定するとき、第1のクライアントの役割をスレーブ・ユーザーから副次マスター・ユーザーに変更するように構成される。送信ユニット903はさらに、第3のメディア要求メッセージをメディア・サーバーに送信するように構成され、第3のメディア要求メッセージは第1のクライアントの識別子を含む。受信ユニット901は、第3のメディア要求メッセージに基づいて、メディア・サーバーによって送信される第3のライブ・メディア・ストリームを受信するように構成される。
任意的に、この実施形態のさらに別の個別的な実装では、第2のクライアントが主要マスター・ユーザーであり、第1のクライアントが副次マスター・ユーザーである場合、送信ユニット903はさらに、第1のライブ・メディア・ストリームを第1のクライアントに送信するように構成される。
任意的に、この実施形態のさらに別の個別的な実装では、第1のクライアントが副次マスター・ユーザーである場合、受信ユニット901はさらに、第1のクライアントから第4のメディア要求メッセージを受信するように構成される。送信ユニット903はさらに、第4のメディア要求メッセージをメディア・サーバーに送信するように構成される。受信ユニット901はさらに、第4のメディア要求メッセージに基づいてメディア・サーバーによって送信される第4のライブ・メディア・ストリームを受信するように構成される。
任意的に、この実施形態のさらに別の個別的な実装では、第1のクライアントが副次マスター・ユーザーである場合、受信ユニット901はさらに、第2のクライアントから、ライブ・ブロードキャスト・ルームを退出するための要求メッセージを受信するように構成される。処理ユニット902はさらに、第1のクライアントを新しい主要マスター・ユーザーとして決定するとき、第1のクライアントの役割を副次マスター・ユーザーから主要マスター・ユーザーに変更するように構成される。送信ユニット903はさらに、第1のクライアントに送信される第1のライブ・メディア・ストリームを第4のライブ・メディア・ストリームに切り換えるように構成される。
任意的に、この実施形態のさらに別の個別的な実装では、処理ユニット902はさらに、第4のライブ・メディア・ストリームのタイムスタンプを調整し、調整されたタイムスタンプが、第1のクライアントに送信される第4のライブ・メディア・ストリームの最初のフレームのタイムスタンプと、第1のクライアントに送信される第1のライブ・メディア・ストリームの最後のフレームのタイムスタンプとが連続していることを満たすようにするように構成される。
第1のクライアントに送信される第1のライブ・メディア・ストリームの最後のフレームと、第1のクライアントに送信される第4のライブ・メディア・ストリームの最初のフレームとは、隣接するフレームである。
処理ユニット902はさらに：第1のクライアントに送られる第1のライブ・メディア・ストリームを第4のライブ・メディア・ストリームに切り換える前に、キャッシュされた第1のライブ・メディア・ストリームおよび第4のライブ・メディア・ストリームに基づいて、それぞれ第1のライブ・メディア・ストリームおよび第4のライブ・メディア・ストリームに属する第1のIフレームおよび第2のIフレームを識別する段階であって、該第1のIフレームおよび該第2のIフレームは同じビデオ・フレームである、段階と；第1のIフレームおよび第2のIフレームに基づいて、互いに隣接し、それぞれ第1のライブ・メディア・ストリームおよび第4のライブ・メディア・ストリームに属する第1の切り換えフレームおよび第2の切り換えフレームを決定する段階と、該第1の切り換えフレームおよび第2の切り換えフレームを、それぞれ、第1のクライアントに送られる第1のライブ・メディア・ストリームの最後のフレームおよび第1のクライアントに送られる第4のライブ・メディア・ストリームの最初のフレームとして使用する段階とを実行するように構成される。
任意的に、この実施形態のさらに別の個別的な実装では、本装置はさらに：第1のライブ・メディア・ストリームをピクチャーグループGOPごとにキャッシュするように構成される。加えて、記憶ユニットはさらに、第2のライブ・メディア・ストリームおよび第3のライブ・メディア・ストリームをGOPごとにローカルに記憶する。
任意的に、この実施形態のさらに別の個別的な実装では、処理ユニット902はさらに：第1のクライアントに送信される第1のライブ・メディア・ストリームを第2のライブ・メディア・ストリームに切り換える前に、第2のライブ・メディア・ストリームのタイムスタンプを調整して、調整されたタイムスタンプが、第1のクライアントに送信される第2のライブ・メディア・ストリームの最初のフレームのタイムスタンプと、第1のクライアントに送信される第1のライブ・メディア・ストリームの最後のフレームのタイムスタンプとが連続していることを満たすようにするように構成される。「連続している」とは、第1のクライアントによって受信される第2のライブ・メディア・ストリームの隣接する諸ビデオ・フレームの時間長さが同じであり、該時間長さがフレームレート・パラメータfの逆数であることとして理解されうる。
任意的に、この実施形態のさらに別の個別的な実装では、第1のクライアントに送信される第1のライブ・メディア・ストリームの最後のフレームと、第1のクライアントに送信される第2のライブ・メディア・ストリームの最初のフレームは隣接するフレームである。
処理ユニット902はさらに：第1のクライアントに送信される第1のライブ・メディア・ストリームを第2のライブ・メディア・ストリームに切り換える前に、第1のライブ・メディア・ストリームおよび第2のライブ・メディア・ストリームに基づいて、それぞれ第1のライブ・メディア・ストリームおよび第2のライブ・メディア・ストリームに属する第1のIフレームおよび第2のIフレームであって、該第1のIフレームおよび第2のIフレームが同じビデオ・フレームである、第1のIフレームおよび第2のIフレームを識別し；該第1のIフレームおよび第2のIフレームに基づいて、互いに隣接し、それぞれ第1のライブ・メディア・ストリームおよび第2のライブ・メディア・ストリームに属する第1の切り換えフレームおよび第2の切り換えフレームを決定し；該第1の切り換えフレームおよび第2の切り換えフレームを、それぞれ、第1のクライアントに送信される第1のライブ・メディア・ストリームの最後のフレームおよび第1のクライアントに送信される第2のライブ・メディア・ストリームの最初のフレームとして使用するように構成される。
送信ユニット903はさらに：第1の切り換えフレームおよび第2の切り換えフレームを決定した後、ライブ・ブロードキャスト・ルームを退出するための第2のクライアントからの要求メッセージをメディア・サーバーに転送するように構成される。
任意的に、この実施形態のさらに別の個別的な実装では、処理ユニット902はさらに：第1のライブ・メディア・ストリームが第1のクライアントに送信される前に、第1のライブ・メディア・ストリームのタイムスタンプを調整し、調整されたタイムスタンプが、第1のクライアントに送信される第1のライブ・メディア・ストリームの最初のフレームのタイムスタンプが0であり、第1のクライアントに送信される第1のライブ・メディア・ストリームの隣接する諸フレームのタイムスタンプが連続していることを満足するようにするように構成される。
個別的なハードウェア実装では、図10に示されるように、本願はさらにネットワーク装置を提供する。ネットワーク装置200は、上記の方法実施形態におけるプロキシサーバーであってもよい。
具体的には、ネットワーク装置200は、トランシーバ201、プロセッサ202、およびメモリ203を含む。ネットワーク装置は、さらに、より多数またはより少数の構成要素を含んでいてもよく、または、いくつかの構成要素を組み合わせてもよく、または、異なる構成要素配置を有してもよい。これは、本願において限定されない。
トランシーバ201は、ライブ・メディア・ストリームを受信および送信し、ネットワーク内の他の装置（たとえばクライアントまたはRDC）とのデータ伝送、たとえば要求メッセージおよび応答メッセージの送信および受信を実行するように構成される。さらに、トランシーバ201は、受信機2011、送信機2012、およびアンテナ2013のような構成要素を含んでいてもよく、トランシーバモジュールを含んでいてもよい。さらに、トランシーバモジュールは、無線ローカルエリアネットワーク（wireless local area network、WLAN）モジュール、Bluetoothモジュール、またはベースバンド（base band）モジュールなどの通信モジュールを含んでいてもよく、該通信モジュールに対応する無線周波数（radio frequency、RF）回路を含んでいてもよい。ここで、無線周波数回路は、無線ローカルエリアネットワーク通信、Bluetooth通信、赤外線通信、および／またはセルラー通信システム通信、たとえば、広帯域符号分割多元接続（wideband code division multiple access、WCDMA）および／または高速下りリンクパケットアクセス（high speed downlink packet access、HSDPA）を実行するように構成される。トランシーバモジュールは、ネットワーク装置内の構成要素間の通信を制御するように構成され、直接メモリアクセス（direct memory access）をサポートしてもよい。
プロセッサ202は、ネットワーク装置の制御センターであり、さまざまなインターフェースおよびラインを通じてネットワーク装置全体のさまざまな部分に接続される。プロセッサ202は、メモリ203に記憶されたソフトウェア・プログラムおよび／またはユニットを走らせ、または実行し、メモリ203に記憶されたデータを呼び出して、ネットワーク装置のさまざまな機能を実行する、および／またはデータを処理する。
さらに、プロセッサ202は、集積回路（integrated circuit、IC）を含んでいてもよく、たとえば、単一のパッケージ化されたICを含んでいてもよく、または同じ機能または異なる機能を有する複数の接続されたパッケージ化されたICを含んでいてもよい。たとえば、プロセッサは、中央処理ユニット（Central Processing Unit、CPU）のみを含んでいてもよく、またはGPU、デジタル信号プロセッサ（Digital Signal Processor、DSP）、およびトランシーバ内の制御チップ（ベースバンドチップなど）の組み合わせであってもよい。
メモリ203は、揮発性メモリ（volatile memory）、たとえばランダムアクセスメモリ（Random Access Memory、RAM）を含んでいてもよく、あるいは不揮発性メモリ（non-volatile memory）、たとえばフラッシュ・メモリ（flash memory）、ハード・ディスク・ドライブ（Hard Disk Drive、HDD）、または固体ドライブ（Solid-State Drive、SSD）を含んでいてもよい。メモリはさらに、上記の諸タイプのメモリの組み合わせを含んでいてもよい。メモリは、プログラムまたはコードを格納しうる。プロセッサ202は、通信装置の機能を実現するために該プログラムまたはコードを実行する。
この実施形態では、ネットワーク装置がプロキシサーバーとして使用される場合、図9に示される装置実施形態における受信ユニット901および送信ユニット903の機能は、トランシーバ201によって実装されてもよく、またはプロセッサ202によって制御されるトランシーバ201によって実装されてもよく；処理ユニット902によって実装される機能は、プロセッサ202によって実装されてもよく；記憶ユニットの機能は、メモリ203によって実装されてもよい。
さらに、本願のある実施形態は、メディア・ストリーム送信システムをさらに提供する。本システムは、図9に示されるメディア・ストリーム送信装置または図10に示されるネットワーク装置を含み、さらに、上記の方法実施形態におけるメディア・ストリーム送信方法を実装するための装置、たとえば複数のクライアント、RDC、EDC、およびコンテンツ源を含む。
任意的に、メディア・ストリーム送信システムはビデオ・ライブ・ブロードキャスト・システム、たとえばCDNシステムである。
加えて、本願は、コンピュータ記憶媒体をさらに提供する。コンピュータ記憶媒体は、プログラムを記憶することができ、プログラムが実行されると、本願で提供されるメディア・ストリーム送信方法の実施形態のステップの一部または全部が実行されうる。記憶媒体は、磁気ディスク、光ディスク、読み出し専用メモリROM、ランダムアクセスメモリRAM等であってもよい。
上記の諸実施形態の全部または一部は、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組み合わせを使用することによって実装されうる。実施形態を実装するためにソフトウェアが使用される場合、実施形態の全部または一部は、コンピュータ・プログラム・プロダクトの形で実装されてもよい。
コンピュータ・プログラム・プロダクトは、一つまたは複数のコンピュータ命令を含む。コンピュータ・プログラムがコンピュータ上でロードされ、実行されると、本願の上記の諸実施形態に基づく手順または機能の全部または一部が生成される。コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータネットワーク、または他のプログラム可能な装置であってもよい。
コンピュータ命令は、コンピュータ読み取り可能な記憶媒体に記憶されてもよく、またはコンピュータ読み取り可能な記憶媒体から別のコンピュータ読み取り可能な記憶媒体に送信されてもよい。たとえば、コンピュータ命令は、ウェブサイト、コンピュータ、サーバー、またはデータセンターから他のウェブサイト、コンピュータ、サーバー、またはデータセンターに有線または無線で送信されうる。
本明細書における実施形態における同じまたは類似の部分については、相互を参照されたい。特に、メディア・ストリーム送信装置の実施形態は、基本的には、方法実施形態と同様であり、よって簡単に記載されている。関連部分については、方法実施形態の説明を参照されたい。
当業者は、本発明の実施形態における技術は、必要な一般的なハードウェアプラットフォームに加えて、ソフトウェアによって実装されうることを明確に理解することができる。そのような理解に基づいて、本発明の実施形態における技術的解決策は本質的に、または従来技術に寄与する部分は、ソフトウェア・プロダクトの形で実装されてもよい。コンピュータソフトウェア・プロダクトは、ROM/RAM、磁気ディスク、または光ディスクなどの記憶媒体に記憶されてもよく、本発明の実施形態または実施形態のいくつかの部分に記載された方法を実行するためにコンピュータ装置（これはパーソナルコンピュータ、サーバー、ネットワーク装置などであってもよい）を示すためのいくつかの命令を含む。
本明細書における実施形態における同じまたは類似の部品については、相互に参照されたい。特に、メディア・ストリーム送信装置の実施形態は、基本的に方法実施形態と同様であり、よって簡単に記載されている。関連部分については、方法実施形態の説明を参照されたい。
なお、本願の明細書において、「複数」とは、特に断らない限り、2以上を意味する。また、本願の実施形態における技術的解決策を明確に記載する便宜上、機能および目的が基本的に同じである同じ対象物または類似の対象物を区別するために、「第1」、「第2」等の用語が使用される。当業者は、「第1」、「第2」のような用語は、数量または実行順序を限定するものではなく、「第1」、「第2」のような用語は、明確な差を示すものではないと理解することができる。
本願の上記の諸実装は、本願の保護範囲を限定することを意図するものではない。

Claims (34)

  1. メディア・ストリーム送信方法であって、当該方法は、ライブ・ブロードキャスト・ルームに入るクライアントにライブ・メディア・ストリームを提供するものであり、当該方法は：
    プロキシサーバーによって、第1のクライアントから、ライブ・ブロードキャスト・ルームに入ることを要求するための第1のライブ・ブロードキャスト・ルーム要求メッセージを受信する段階と；
    前記プロキシサーバーによって、前記第1のライブ・ブロードキャスト・ルーム要求メッセージに基づいて前記第1のクライアントの役割を決定する段階と；
    前記第1のクライアントの役割がスレーブ・ユーザーである場合、前記プロキシサーバーにキャッシュされている第1のライブ・メディア・ストリームを前記第1のクライアントに送信する段階であって、前記第1のライブ・メディア・ストリームは、メディア・サーバーによって前記プロキシサーバーを通じて第2のクライアントに送信されるメディア・ストリームであり、前記第2のクライアントの役割はマスター・ユーザーである、段階とを含む、
    方法。
  2. 前記第1のライブ・ブロードキャスト・ルーム要求メッセージに基づいて前記第1のクライアントの役割を決定する段階は：
    前記第1のライブ・ブロードキャスト・ルーム要求メッセージが受信されたときに、前記ライブ・ブロードキャスト・ルーム内に役割がマスター・ユーザーであるクライアントが存在するかどうかを判定し；
    前記ライブ・ブロードキャスト・ルーム内に役割がマスター・ユーザーであるクライアントが存在すれば、前記第1のクライアントの役割がスレーブ・ユーザーであると決定することを含む、
    請求項１に記載の方法。
  3. 前記プロキシサーバーにキャッシュされている第1のライブ・メディア・ストリームを前記第1のクライアントに送信する段階の前に、当該方法は、さらに：
    前記プロキシサーバーによって、前記第1のクライアントから第1のメディア要求メッセージを受信し、前記第1のメディア要求メッセージを前記メディア・サーバーに転送することをスキップし；
    前記プロキシサーバーによって、前記第1のクライアントに第1のメディア応答メッセージを送信することを含み、前記第1のメディア応答メッセージが、前記第1のクライアントがメディア・ストリームを取得することを許可されていることを前記第1のクライアントに通知するために使用される、
    請求項２に記載の方法。
  4. 前記第1のメディア要求メッセージは、前記第1のクライアントの識別子を含み、
    前記プロキシサーバーによって前記第1のクライアントに第1のライブ・メディア・ストリームを送信する段階の後、当該方法はさらに：
    前記プロキシサーバーによって、前記第2のクライアントから、前記ライブ・ブロードキャスト・ルームを退出するための要求メッセージを受信する段階と；
    前記第1のクライアントを新しいマスター・ユーザーとして決定するとき、前記プロキシサーバーによって、前記第1のクライアントの役割をスレーブ・ユーザーからマスター・ユーザーに変更する段階と；
    前記プロキシサーバーによって、第2のメディア要求メッセージを前記メディア・サーバーに送信する段階であって、前記第2のメディア要求メッセージは、前記第1のクライアントの識別子を含む、段階と；
    前記プロキシサーバーによって、前記第2のメディア要求メッセージに基づいて前記メディア・サーバーによって送信された第2のライブ・メディア・ストリームを受信する段階と；
    前記プロキシサーバーによって、前記第1のクライアントに送信される前記第1のライブ・メディア・ストリームを前記第2のライブ・メディア・ストリームに切り換える段階とを含む、
    請求項３に記載の方法。
  5. 前記第1のライブ・ブロードキャスト・ルーム要求メッセージに基づいて前記第1のクライアントの役割を決定する段階は：
    前記プロキシサーバーによって、前記第1のライブ・ブロードキャスト・ルーム要求メッセージを受信したときに、前記ライブ・ブロードキャスト・ルームにおける、役割がマスター・ユーザーであるクライアントの数が事前設定された上限に達しているかどうかを判定する段階であって、前記事前設定された上限は1より大きい、段階と；
    前記ライブ・ブロードキャスト・ルームにおける、役割がマスター・ユーザーであるクライアントの数が前記事前設定された上限に達していれば、前記第1のクライアントの役割がスレーブ・ユーザーであると決定する段階とを含む、
    請求項１に記載の方法。
  6. 前記ライブ・ブロードキャスト・ルームにおける、役割がマスター・ユーザーであるクライアントの数が0ではないが前記事前設定された上限には達しない場合、前記第1のクライアントの役割が副次マスター・ユーザーであると決定する段階をさらに含む、
    請求項５に記載の方法。
  7. 前記第1のクライアントがスレーブ・ユーザーである場合、当該方法はさらに：
    前記プロキシサーバーによって、前記第2のクライアントから、前記ライブ・ブロードキャスト・ルームを退出するための要求メッセージを受信する段階と；
    前記第1のクライアントを新しい副次マスター・ユーザーとして決定するとき、前記プロキシサーバーによって、前記第1のクライアントの役割をスレーブ・ユーザーから副次マスター・ユーザーに変更する段階と；
    前記プロキシサーバーによって、第3のメディア要求メッセージを前記メディア・サーバーに送信する段階であって、前記第3のメディア要求メッセージが前記第1のクライアントの識別子を含む、段階と；
    前記プロキシサーバーによって、前記第3のメディア要求メッセージに基づいて、前記メディア・サーバーによって送信される第3のライブ・メディア・ストリームを受信する段階とを含む、
    請求項５に記載の方法。
  8. 前記第2のクライアントが主要マスター・ユーザーであり、前記第1のクライアントが副次マスター・ユーザーである場合、当該方法はさらに：
    前記プロキシサーバーによって、前記第1のライブ・メディア・ストリームを前記第1のクライアントに送信する段階を含む、
    請求項６に記載の方法。
  9. 前記第1のクライアントが副次マスター・ユーザーである場合、当該方法はさらに：
    前記プロキシサーバーによって、前記第1のクライアントから第4のメディア要求メッセージを受信する段階と；
    前記プロキシサーバーによって、前記第4のメディア要求メッセージを前記メディア・サーバーに送信する段階と；
    前記プロキシサーバーによって、前記第4のメディア要求メッセージに基づいて前記メディア・サーバーによって送信される第4のライブ・メディア・ストリームを受信する段階とを含む、
    請求項８に記載の方法。
  10. 前記第1のクライアントが副次マスター・ユーザーである場合、当該方法はさらに：
    前記プロキシサーバーによって、前記第2のクライアントから、前記ライブ・ブロードキャスト・ルームを退出するための要求メッセージを受信する段階と；
    前記第1のクライアントを新しい主要マスター・ユーザーとして決定する場合、前記プロキシサーバーによって、前記第1のクライアントの役割を副次マスター・ユーザーから主要マスター・ユーザーに変更する段階と；
    前記プロキシサーバーによって、前記第1のクライアントに送信される前記第1のライブ・メディア・ストリームを前記第4のライブ・メディア・ストリームに切り換える段階とを含む、
    請求項９に記載の方法。
  11. 当該方法は、さらに：
    前記プロキシサーバーによって、前記第4のライブ・メディア・ストリームのタイムスタンプを調整し、調整されたタイムスタンプが、前記第1のクライアントに送信される前記第4のライブ・メディア・ストリームの最初のフレームのタイムスタンプと、前記第1のクライアントに送信される前記第1のライブ・メディア・ストリームの最後のフレームのタイムスタンプとが連続していることを満たすようにする段階を含む、
    請求項１０に記載の方法。
  12. 前記プロキシサーバーによって前記第1のクライアントに送信される前記第1のライブ・メディア・ストリームの最後のフレームと、前記プロキシサーバーによって前記第1のクライアントに送信される前記第4のライブ・メディア・ストリームの最初のフレームとは、隣接するフレームであり、
    前記プロキシサーバーによって前記第1のクライアントに送信される前記第1のライブ・メディア・ストリームを前記第4のライブ・メディア・ストリームに切り換える前に、当該方法はさらに：
    前記プロキシサーバーによって、キャッシュされた前記第1のライブ・メディア・ストリームおよび前記第4のライブ・メディア・ストリームに基づいて、それぞれ前記第1のライブ・メディア・ストリームおよび前記第4のライブ・メディア・ストリームに属する第1のIフレームおよび第2のIフレームを識別する段階であって、該第1のIフレームおよび該第2のIフレームは同じビデオ・フレームである、段階と；
    前記プロキシサーバーによって、前記第1のIフレームおよび前記第2のIフレームに基づいて、互いに隣接し、それぞれ前記第1のライブ・メディア・ストリームおよび前記第4のライブ・メディア・ストリームに属する第1の切り換えフレームおよび第2の切り換えフレームを決定し、該第1の切り換えフレームおよび該第2の切り換えフレームを、それぞれ、前記第1のクライアントに送信される前記第1のライブ・メディア・ストリームの最後のフレームおよび前記第1のクライアントに送信される前記第4のライブ・メディア・ストリームの最初のフレームとして使用する段階とを含む、
    請求項１０または１１に記載の方法。
  13. 前記プロキシサーバーによって、ピクチャーグループGOPごとに前記第1のライブ・メディア・ストリームをキャッシュすることを含む、
    請求項１ないし１２のうちいずれか一項に記載の方法。
  14. 前記プロキシサーバーによって、前記第1のクライアントに送信される前記第1のライブ・メディア・ストリームを前記第2のライブ・メディア・ストリームに切り換える前に、当該方法はさらに：
    前記プロキシサーバーによって、前記第2のライブ・メディア・ストリームのタイムスタンプを調整して、調整されたタイムスタンプを有効にし、調整されたタイムスタンプが、前記プロキシサーバーによって前記第1のクライアントに送信される前記第2のライブ・メディア・ストリームの最初のフレームのタイムスタンプと、前記プロキシサーバーによって前記第1のクライアントに送信される前記第1のライブ・メディア・ストリームの最後のフレームのタイムスタンプとが連続することを満たすようにする段階を含む、
    請求項４に記載の方法。
  15. 前記プロキシサーバーによって前記第1のクライアントに送信される前記第1のライブ・メディア・ストリームの最後のフレームと、前記プロキシサーバーによって前記第1のクライアントに送信される前記第2のライブ・メディア・ストリームの最初のフレームとは、隣接するフレームであり、
    前記プロキシサーバーによって、前記第1のクライアントに送信される前記第1のライブ・メディア・ストリームを前記第2のライブ・メディア・ストリームに切り換える前に、当該方法はさらに：
    前記プロキシサーバーによって、前記第1のライブ・メディア・ストリームおよび前記第2のライブ・メディア・ストリームに基づいて、それぞれ前記第1のライブ・メディア・ストリームおよび前記第2のライブ・メディア・ストリームに属する第1のIフレームおよび第2のIフレームであって、該第1のIフレームおよび該第2のIフレームが同じビデオ・フレームである、第1のIフレームおよび第2のIフレームを識別する段階と；
    前記プロキシサーバーによって、前記第1のIフレームおよび前記第2のIフレームに基づいて、互いに隣接し、それぞれ前記第1のライブ・メディア・ストリームおよび前記第2のライブ・メディア・ストリームに属する第1の切り換えフレームおよび第2の切り換えフレームを決定し、該第1の切り換えフレームおよび該第2の切り換えフレームを、それぞれ、前記第1のクライアントに送信される前記第1のライブ・メディア・ストリームの最後のフレームおよび前記第1のクライアントに送信される前記第2のライブ・メディア・ストリームの最初のフレームとして使用する段階とを含み、
    前記プロキシサーバーが前記第1の切り換えフレームおよび前記第2の切り換えフレームを決定した後、当該方法はさらに：前記プロキシサーバーによって、前記ライブ・ブロードキャスト・ルームを退出するための前記第2のクライアントからの前記要求メッセージを前記メディア・サーバーに転送する段階を含む、
    請求項４または１４に記載の方法。
  16. 前記プロキシサーバーが前記第1のライブ・メディア・ストリームを前記第1のクライアントに送信する前に、当該方法はさらに：
    前記プロキシサーバーによって、前記第1のライブ・メディア・ストリームのタイムスタンプを調整し、調整されたタイムスタンプが、前記プロキシサーバーによって前記第1のクライアントに送信される前記第1のライブ・メディア・ストリームの最初のフレームのタイムスタンプが0であり、前記第1のクライアントに送信される前記第1のライブ・メディア・ストリームの隣接する諸フレームのタイムスタンプが連続していることを満足するようにする段階を含む、
    請求項１ないし１５のうちいずれか一項に記載の方法。
  17. メディア・ストリーム送信装置であって、当該装置は、ライブ・ブロードキャスト・ルームに入るクライアントにライブ・メディア・ストリームを提供するものであり、当該装置は：
    第1のクライアントから、ライブ・ブロードキャスト・ルームに入ることを要求するための第1のライブ・ブロードキャスト・ルーム要求メッセージを受信するように構成された受信ユニットと；
    前記第1のライブ・ブロードキャスト・ルーム要求メッセージに基づいて前記第1のクライアントの役割を決定するように構成された処理ユニットと；
    前記第1のクライアントの役割がスレーブ・ユーザーであると決定された場合、当該装置にキャッシュされている第1のライブ・メディア・ストリームを前記第1のクライアントに送信するように構成された送信ユニットであって、前記第1のライブ・メディア・ストリームは、メディア・サーバーによって当該装置を通じて第2のクライアントに送信されるメディア・ストリームであり、前記第2のクライアントの役割はマスター・ユーザーである、送信装置とを有する、
    装置。
  18. 前記処理ユニットが具体的には：前記第1のライブ・ブロードキャスト・ルーム要求メッセージが受信されたときに、前記ライブ・ブロードキャスト・ルーム内に役割がマスター・ユーザーであるクライアントが存在するかどうかを判定し；前記ライブ・ブロードキャスト・ルーム内に役割がマスター・ユーザーであるクライアントが存在すれば、前記第1のクライアントの役割がスレーブ・ユーザーであると決定するように構成されている、
    請求項１７に記載の装置。
  19. 前記受信ユニットがさらに：前記キャッシュされている第1のライブ・メディア・ストリームが前記第1のクライアントに送信される前に、前記第1のクライアントから第1のメディア要求メッセージを受信し、前記第1のメディア要求メッセージを前記メディア・サーバーに転送することをスキップするように構成されており；
    前記送信ユニットがさらに：前記第1のクライアントに第1のメディア応答メッセージを送信するように構成されており、前記第1のメディア応答メッセージが、前記第1のクライアントがメディア・ストリームを取得することを許可されていることを前記第1のクライアントに通知するために使用される、
    請求項１８に記載の装置。
  20. 前記第1のメディア要求メッセージは、前記第1のクライアントの識別子を含み、
    前記受信ユニットがさらに：前記第1のライブ・メディア・ストリームが前記第1のクライアントに送信された後、前記第2のクライアントから、前記ライブ・ブロードキャスト・ルームを退出するための要求メッセージを受信するように構成されており；
    前記処理ユニットがさらに：前記第1のクライアントを新しいマスター・ユーザーとして決定するとき、前記第1のクライアントの役割をスレーブ・ユーザーからマスター・ユーザーに変更するように構成されており；
    前記送信ユニットがさらに、第2のメディア要求メッセージを前記メディア・サーバーに送信するように構成されており、前記第2のメディア要求メッセージは、前記第1のクライアントの識別子を含み；
    前記受信ユニットがさらに、前記第2のメディア要求メッセージに基づいて前記メディア・サーバーによって送信された第2のライブ・メディア・ストリームを受信するように構成されており；
    前記処理ユニットがさらに、前記第1のクライアントに送信される前記第1のライブ・メディア・ストリームを前記第2のライブ・メディア・ストリームに切り換えるように構成されている、
    請求項１９に記載の装置。
  21. 前記処理ユニットが具体的には：前記第1のライブ・ブロードキャスト・ルーム要求メッセージが受信されたときに、前記ライブ・ブロードキャスト・ルームにおける、役割がマスター・ユーザーであるクライアントの数が事前設定された上限に達しているかどうかを判定する段階であって、前記事前設定された上限は1より大きい、段階と；前記ライブ・ブロードキャスト・ルームにおける、役割がマスター・ユーザーであるクライアントの数が前記事前設定された上限に達していれば、前記第1のクライアントの役割がスレーブ・ユーザーであると決定する段階とを実行するように構成されている、
    請求項１７に記載の装置。
  22. 前記処理ユニットがさらに：前記ライブ・ブロードキャスト・ルームにおける、役割がマスター・ユーザーであるクライアントの数が0ではないが前記事前設定された上限には達しない場合、前記第1のクライアントの役割が副次マスター・ユーザーであると決定するように構成されている、
    請求項２１に記載の装置。
  23. 前記第1のクライアントがスレーブ・ユーザーである場合、
    前記受信ユニットはさらに、前記第2のクライアントから、前記ライブ・ブロードキャスト・ルームを退出するための要求メッセージを受信するように構成されており；
    前記処理ユニットはさらに：前記第1のクライアントを新しい副次マスター・ユーザーとして決定するとき、前記第1のクライアントの役割をスレーブ・ユーザーから副次マスター・ユーザーに変更するように構成されており；
    前記送信ユニットはさらに、第3のメディア要求メッセージを前記メディア・サーバーに送信するように構成されており、前記第3のメディア要求メッセージは前記第1のクライアントの識別子を含み；
    前記受信ユニットはさらに、前記第3のメディア要求メッセージに基づいて、前記メディア・サーバーによって送信される第3のライブ・メディア・ストリームを受信するように構成されている、
    請求項２１に記載の装置。
  24. 前記第2のクライアントが主要マスター・ユーザーであり、前記第1のクライアントが副次マスター・ユーザーである場合、
    前記送信ユニットはさらに、前記第1のライブ・メディア・ストリームを前記第1のクライアントに送信するように構成されている、
    請求項２２に記載の装置。
  25. 前記第1のクライアントが副次マスター・ユーザーである場合、
    前記受信ユニットはさらに、前記第1のクライアントから第4のメディア要求メッセージを受信するように構成されており；
    前記送信ユニットはさらに、前記第4のメディア要求メッセージを前記メディア・サーバーに送信するように構成されており；
    前記受信ユニットはさらに、前記第4のメディア要求メッセージに基づいて前記メディア・サーバーによって送信される第4のライブ・メディア・ストリームを受信するように構成されている、
    請求項２４に記載の装置。
  26. 前記第1のクライアントが副次マスター・ユーザーである場合：
    前記受信ユニットはさらに、前記第2のクライアントから、前記ライブ・ブロードキャスト・ルームを退出するための要求メッセージを受信するように構成されており；
    前記処理ユニットはさらに：前記第1のクライアントを新しい主要マスター・ユーザーとして決定する場合、前記第1のクライアントの役割を副次マスター・ユーザーから主要マスター・ユーザーに変更するように構成されており；
    前記処理ユニットはさらに、前記第1のクライアントに送信される前記第1のライブ・メディア・ストリームを前記第4のライブ・メディア・ストリームに切り換えるように構成されている、
    請求項２５に記載の装置。
  27. 前記処理ユニットはさらに、前記第4のライブ・メディア・ストリームのタイムスタンプを調整し、調整されたタイムスタンプが、前記第1のクライアントに送信される前記第4のライブ・メディア・ストリームの最初のフレームのタイムスタンプと、前記第1のクライアントに送信される前記第1のライブ・メディア・ストリームの最後のフレームのタイムスタンプとが連続していることを満たすようにするように構成されている、
    請求項２６に記載の装置。
  28. 前記第1のクライアントに送信される前記第1のライブ・メディア・ストリームの最後のフレームと、前記第1のクライアントに送信される前記第4のライブ・メディア・ストリームの最初のフレームとは、隣接するフレームであり、
    前記処理ユニットはさらに：前記第1のクライアントに送信される前記第1のライブ・メディア・ストリームを前記第4のライブ・メディア・ストリームに切り換える前に、キャッシュされた前記第1のライブ・メディア・ストリームおよび前記第4のライブ・メディア・ストリームに基づいて、それぞれ前記第1のライブ・メディア・ストリームおよび前記第4のライブ・メディア・ストリームに属する第1のIフレームおよび第2のIフレームを識別する段階であって、該第1のIフレームおよび該第2のIフレームは同じビデオ・フレームである、段階と；前記第1のIフレームおよび前記第2のIフレームに基づいて、互いに隣接し、それぞれ前記第1のライブ・メディア・ストリームおよび前記第4のライブ・メディア・ストリームに属する第1の切り換えフレームおよび第2の切り換えフレームを決定し、該第1の切り換えフレームおよび該第2の切り換えフレームを、それぞれ、前記第1のクライアントに送信される前記第1のライブ・メディア・ストリームの最後のフレームおよび前記第1のクライアントに送信される前記第4のライブ・メディア・ストリームの最初のフレームとして使用する段階とを実行するように構成されている、
    請求項２６または２７に記載の装置。
  29. ピクチャーグループGOPごとに前記第1のライブ・メディア・ストリームをキャッシュするように構成された記憶ユニットをさらに有する、
    請求項１７ないし２８のうちいずれか一項に記載の装置。
  30. 前記処理ユニットはさらに：前記第1のクライアントに送信される前記第1のライブ・メディア・ストリームを前記第2のライブ・メディア・ストリームに切り換える前に、前記第2のライブ・メディア・ストリームのタイムスタンプを調整して、調整されたタイムスタンプが、前記第1のクライアントに送信される前記第2のライブ・メディア・ストリームの最初のフレームのタイムスタンプと、前記第1のクライアントに送信される前記第1のライブ・メディア・ストリームの最後のフレームのタイムスタンプとが連続することを満たすようにするように構成されている、
    請求項２０に記載の装置。
  31. 前記第1のクライアントに送信される前記第1のライブ・メディア・ストリームの最後のフレームと、前記第1のクライアントに送信される前記第2のライブ・メディア・ストリームの最初のフレームとは、隣接するフレームであり、
    前記処理ユニットはさらに：前記第1のクライアントに送信される前記第1のライブ・メディア・ストリームを前記第2のライブ・メディア・ストリームに切り換える前に、前記第1のライブ・メディア・ストリームおよび前記第2のライブ・メディア・ストリームに基づいて、それぞれ前記第1のライブ・メディア・ストリームおよび前記第2のライブ・メディア・ストリームに属する第1のIフレームおよび第2のIフレームであって、該第1のIフレームおよび該第2のIフレームが同じビデオ・フレームである、第1のIフレームおよび第2のIフレームを識別する段階と；前記第1のIフレームおよび前記第2のIフレームに基づいて、互いに隣接し、それぞれ前記第1のライブ・メディア・ストリームおよび前記第2のライブ・メディア・ストリームに属する第1の切り換えフレームおよび第2の切り換えフレームを決定し、該第1の切り換えフレームおよび該第2の切り換えフレームを、それぞれ、前記第1のクライアントに送信される前記第1のライブ・メディア・ストリームの最後のフレームおよび前記第1のクライアントに送信される前記第2のライブ・メディア・ストリームの最初のフレームとして使用する段階とを実行するように構成されており、
    前記送信ユニットがさらに：前記第1の切り換えフレームおよび前記第2の切り換えフレームが決定された後、前記ライブ・ブロードキャスト・ルームを退出するための前記第2のクライアントからの前記要求メッセージを前記メディア・サーバーに転送するように構成されている、
    請求項２０または３０に記載の装置。
  32. 前記処理ユニットがさらに：前記第1のライブ・メディア・ストリームが前記第1のクライアントに送信される前に、前記第1のライブ・メディア・ストリームのタイムスタンプを調整し、調整されたタイムスタンプが、当該装置によって前記第1のクライアントに送信される前記第1のライブ・メディア・ストリームの最初のフレームのタイムスタンプが0であり、前記第1のクライアントに送信される前記第1のライブ・メディア・ストリームの隣接する諸フレームのタイムスタンプが連続していることを満足するようにするように構成されている、
    請求項１７ないし３１のうちいずれか一項に記載の装置。
  33. プロセッサを有するネットワーク装置であって、前記プロセッサはメモリに結合されており、
    前記メモリは命令を記憶するように構成されており；
    前記プロセッサは、当該ネットワーク装置が請求項１ないし１６のうちいずれか一項に記載の方法を実行するよう、前記メモリ内の命令を実行するように構成されている、
    ネットワーク装置。
  34. コンピュータ読み取り可能な記憶媒体であって、該記憶媒体は命令を記憶しており、
    前記命令が実行されると、請求項１ないし１６のうちいずれか一項に記載の方法が実行される、
    記憶媒体。
JP2021540891A 2019-04-23 2020-04-23 メディア・ストリーム送信方法、装置、デバイス Active JP7256881B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN201910330894.3 2019-04-23
CN201910330894.3A CN111836059B (zh) 2019-04-23 2019-04-23 一种媒体流发送方法、装置和设备
PCT/CN2020/086349 WO2020216279A1 (zh) 2019-04-23 2020-04-23 一种媒体流发送方法、装置和设备

Publications (2)

Publication Number Publication Date
JP2022518216A JP2022518216A (ja) 2022-03-14
JP7256881B2 true JP7256881B2 (ja) 2023-04-12

Family

ID=72911675

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021540891A Active JP7256881B2 (ja) 2019-04-23 2020-04-23 メディア・ストリーム送信方法、装置、デバイス

Country Status (6)

Country Link
US (1) US12107697B2 (ja)
EP (1) EP3883249B1 (ja)
JP (1) JP7256881B2 (ja)
KR (1) KR102525289B1 (ja)
CN (2) CN111836059B (ja)
WO (1) WO2020216279A1 (ja)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113301377B (zh) * 2021-05-24 2023-04-07 广州市百果园信息技术有限公司 直播管理系统、方法、设备及存储介质
US11924479B2 (en) * 2021-07-07 2024-03-05 Rovi Guides, Inc. Systems and methods for generating metadata for a live media stream
CN113824987B (zh) * 2021-09-30 2024-04-30 杭州网易云音乐科技有限公司 直播间首帧耗时的确定方法、介质、装置和计算设备
CN113949892B (zh) * 2021-10-14 2024-03-29 广州方硅信息技术有限公司 基于虚拟资源消耗的直播互动方法、系统、设备及介质
CN114363665B (zh) * 2021-12-16 2023-11-07 深圳市捷视飞通科技股份有限公司 多业务码流推送方法、系统、计算机设备和存储介质
CN114501052B (zh) * 2022-01-26 2022-10-25 腾讯科技（深圳）有限公司 直播数据处理方法、云平台、计算机设备和存储介质
CN116132751B (zh) * 2022-12-30 2024-07-30 郑州小鸟信息科技有限公司 一种基于web窗口场景同步回放的方法及系统
CN118338050B (zh) * 2024-06-17 2024-08-23 北京微吼时代科技有限公司 消息限频方法、装置、电子设备以及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002290952A (ja) 2001-03-23 2002-10-04 Nippon Telegr & Teleph Corp <Ntt> 共通情報キャッシング中継方法及び中継装置
JP2015165349A (ja) 2014-02-28 2015-09-17 株式会社東芝 一次応答装置、制御方法及びコンピュータプログラム
JP2016197411A (ja) 2016-04-19 2016-11-24 株式会社 ディー・エヌ・エー リアルタイムの動画を配信するシステム、方法、及びプログラム

Family Cites Families (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8621083B2 (en) * 2003-05-15 2013-12-31 Hewlett-Packard Development Company, L.P. System and method for multicasting through a localized computer network
KR100851634B1 (ko) * 2008-02-05 2008-08-13 주식회사 셀런 라이브 멀티미디어 스트림을 풀방식으로 스트리밍하는 방법및 시스템
US9165073B2 (en) * 2009-08-17 2015-10-20 Shoutpoint, Inc. Apparatus, system and method for a web-based interactive video platform
EP2517469A4 (en) * 2009-12-22 2014-01-15 Vidyo Inc SYSTEM AND METHOD FOR INTERACTIVE SYNCHRONIZED VIDEO VISUALIZATION
US9038116B1 (en) * 2009-12-28 2015-05-19 Akamai Technologies, Inc. Method and system for recording streams
CN101778104A (zh) * 2009-12-29 2010-07-14 常州中流电子科技有限公司 一种实现自适应带宽播放流媒体的系统及其方法
CN102075562B (zh) * 2010-12-03 2014-08-20 华为技术有限公司 协作缓存的方法和装置
US8416937B2 (en) * 2010-12-27 2013-04-09 Avaya Inc. System and method for changing conference moderators during a conference call
CN102075728B (zh) * 2011-01-18 2015-08-12 中兴通讯股份有限公司 一种共享音频和/或视频的方法及系统
US8327012B1 (en) * 2011-09-21 2012-12-04 Color Labs, Inc Content sharing via multiple content distribution servers
TWI519147B (zh) * 2011-12-28 2016-01-21 財團法人工業技術研究院 提供與傳送複合濃縮串流之方法以及系統
CN103475900A (zh) * 2012-06-06 2013-12-25 中国移动通信集团公司 手机电视业务视频帧的封装方法、装置及前端系统
CN103841468B (zh) * 2014-02-27 2018-04-20 北京六间房科技有限公司 实时流媒体数据传输方法
KR101533368B1 (ko) * 2014-04-18 2015-07-02 숭실대학교산학협력단 마스터 이동 단말 및 슬레이브 이동 단말의 제어 방법, 이를 수행하기 위한 기록매체
US9445048B1 (en) * 2014-07-29 2016-09-13 Google Inc. Gesture-initiated actions in videoconferences
US9402054B2 (en) * 2014-12-08 2016-07-26 Blue Jeans Network Provision of video conference services
CN106302566B (zh) * 2015-05-12 2019-07-23 华为技术有限公司 直播媒体数据的方法、设备和系统
CN105657579A (zh) * 2015-10-29 2016-06-08 乐视致新电子科技（天津）有限公司 直播音频切换方法、流媒体服务器及客户端
WO2018027237A1 (en) * 2016-08-05 2018-02-08 Sportscastr.Live Llc Systems, apparatus, and methods for scalable low-latency viewing of broadcast digital content streams of live events
CN106162235B (zh) * 2016-08-17 2018-06-01 北京百度网讯科技有限公司 用于切换视频流的方法和装置
CN106534877B (zh) * 2016-10-24 2019-06-25 广州酷狗计算机科技有限公司 一种发送媒体流的方法及装置
KR101727310B1 (ko) * 2016-12-09 2017-04-14 주식회사 대경바스컴 다방향성 크로스캐스팅 방송 시스템 및 방법
CN108235042B (zh) * 2016-12-14 2019-12-17 腾讯科技（深圳）有限公司 一种多人网络直播方法、装置、加入装置、系统、服务器和计算机可读存储介质
CN106604064A (zh) * 2016-12-30 2017-04-26 北京奇艺世纪科技有限公司 一种快速开播方法及装置
CN107332894B (zh) * 2017-06-23 2020-08-11 广州市百果园信息技术有限公司 直播方法、装置及系统、服务器、存储介质
CN108322787A (zh) * 2018-02-08 2018-07-24 北京潘达互娱科技有限公司 视频流分发方法、装置及电子设备
CN109104614A (zh) * 2018-07-02 2018-12-28 北京东方网信科技股份有限公司 一种直播缓存系统及方法
US10536741B1 (en) * 2018-10-19 2020-01-14 Philo, Inc. Synchronizing internet (“over the top”) video streams for simultaneous feedback
US10631363B1 (en) * 2018-10-23 2020-04-21 Google Llc Two stage role switch for fully wireless earbuds
CN109618178A (zh) * 2019-01-21 2019-04-12 北京奇艺世纪科技有限公司 一种直播方法、装置及系统

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002290952A (ja) 2001-03-23 2002-10-04 Nippon Telegr & Teleph Corp <Ntt> 共通情報キャッシング中継方法及び中継装置
JP2015165349A (ja) 2014-02-28 2015-09-17 株式会社東芝 一次応答装置、制御方法及びコンピュータプログラム
JP2016197411A (ja) 2016-04-19 2016-11-24 株式会社 ディー・エヌ・エー リアルタイムの動画を配信するシステム、方法、及びプログラム

Also Published As

Publication number Publication date
EP3883249B1 (en) 2024-03-27
KR20210094081A (ko) 2021-07-28
KR102525289B1 (ko) 2023-04-24
EP3883249A4 (en) 2022-05-11
US12107697B2 (en) 2024-10-01
JP2022518216A (ja) 2022-03-14
US20210352336A1 (en) 2021-11-11
CN111836059A (zh) 2020-10-27
CN111836059B (zh) 2022-03-29
WO2020216279A1 (zh) 2020-10-29
CN114666614A (zh) 2022-06-24
EP3883249A1 (en) 2021-09-22

Similar Documents

Publication Publication Date Title
JP7256881B2 (ja) メディア・ストリーム送信方法、装置、デバイス
US11025740B2 (en) Edge cache segment prefetching
US10547659B2 (en) Signaling and processing content with variable bitrates for adaptive streaming
US9769236B2 (en) Combined broadcast and unicast delivery
US10320868B2 (en) Processing of multimedia data
US11330028B2 (en) Media stream sending method, apparatus, system, and device
CN108370281B (zh) 流式传输内容的多播传送的数据速率适配
EP3207682B1 (en) Managing concurrent streaming of media streams
US20220295127A1 (en) Consolidating content streams to conserve bandwidth
CN108476333A (zh) 媒体流的邻接流送

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210714

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20210714

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20220823

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20221011

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20221228

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20230307

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230331

R150 Certificate of patent or registration of utility model

Ref document number: 7256881

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150