特許 7164856 サーバ及び方法

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

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

(11)【特許番号】

(24)【登録日】2022-10-25

(45)【発行日】2022-11-02

(54)【発明の名称】サーバ及び方法

(51)【国際特許分類】

   H04N 21/235 20110101AFI20221026BHJP

   H04N 21/258 20110101ALI20221026BHJP

   H04N 21/6332 20110101ALI20221026BHJP

   H04L 65/75 20220101ALI20221026BHJP

【ＦＩ】

H04N21/235

H04N21/258

H04N21/6332

H04L65/75

【請求項の数】 8

(21)【出願番号】P 2022007652

(22)【出願日】2022-01-21

【審査請求日】2022-01-26

【早期審査対象出願】

(73)【特許権者】

【識別番号】517287224

【氏名又は名称】１７ＬＩＶＥ株式会社

(74)【代理人】

【識別番号】100126572

【弁理士】

【氏名又は名称】村越 智史

(74)【代理人】

【識別番号】100199277

【弁理士】

【氏名又は名称】西守 有人

(72)【発明者】

【氏名】張育銓

(72)【発明者】

【氏名】邱柏盛

(72)【発明者】

【氏名】翁振翔

【審査官】松元 伸次

(56)【参考文献】

【文献】特表２０１２－５２５０７６（ＪＰ，Ａ）

【文献】特開２０１７－２１２７１２（ＪＰ，Ａ）

【文献】特開２０１７－０９２８４４（ＪＰ，Ａ）

【文献】特開２０００－２４４４９０（ＪＰ，Ａ）

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

【文献】特開平０７－２７４１４８（ＪＰ，Ａ）

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

Ｇ０６Ｑ１０／００－１０／１０

３０／００－３０／０８

５０／００－５０／２０

５０／２６－９９／００

Ｇ１６Ｚ９９／００

Ｈ０４Ｌ１３／００－１３／１８

６１／００－６５／８０

６９／００－１０１／６９５

Ｈ０４Ｍ３／００

３／１６－３／２０

３／３８－３／５８

７／００－７／１６

１１／００－１１／１０

Ｈ０４Ｎ７／１０

７／１４－７／１７３

７／２０－７／５６

２１／００－２１／８５８

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

【請求項1】

複数の配信者と少なくとも一人の視聴者とが参加するライブ配信において、前記複数の配信者の各々のユーザ端末で生成される動画データのビットレートまたはその上限を、前記ライブ配信に同時に参加する配信者の数が多いほど低くなるように、決定する手段と、
決定されたビットレートまたはその上限を前記複数の配信者の各々のユーザ端末にネットワークを介して通知する手段と、
前記ライブ配信に参加する前記複数の配信者の各々のユーザ端末からネットワークを介して動画データを受信する手段と、を備えるサーバ。

【請求項2】

前記決定する手段はビットレートの上限を決定し、
前記通知する手段は、前記ライブ配信に参加する配信者全員のユーザ端末に、決定されたビットレートの上限を通知する請求項１に記載のサーバ。

【請求項3】

複数の配信者の複数のユーザ端末から受信した複数の動画データをまとめて視聴者のユーザ端末に送信する手段をさらに備える請求項１または２に記載のサーバ。

【請求項4】

ビットレートまたはその上限が低くなる場合に、フレームレートは維持され、解像度が低くなり、
前記ライブ配信の視聴者のユーザ端末において、各配信者に、単一の配信者によるライブ配信における配信者の画像の表示領域よりも小さな表示領域が割り当てられる請求項１から３のいずれか一項に記載のサーバ。

【請求項5】

前記決定する手段は、
配信者のユーザ端末で生成される動画データのビットレートの上限を、前記ライブ配信に参加する配信者の数が多いほど低くなるように、決定する手段と、
配信者のユーザ端末と前記サーバとの間の通信状態に応じて、当該ユーザ端末で生成される動画データのビットレートを、決定された上限を超えない範囲で決定する手段と、を含み、
前記通知する手段は、決定されたビットレートを通知する請求項１から４のいずれか一項に記載のサーバ。

【請求項6】

前記決定する手段は、前記ビットレートまたはその上限を、前記ライブ配信に参加する視聴者の数とは無関係に前記ライブ配信に同時に参加する配信者の数が多いほど低くなるように決定する、
請求項１から５のいずれか一項に記載のサーバ。

【請求項7】

複数の配信者と少なくとも一人の視聴者とが参加するライブ配信において、前記複数の配信者の各々のユーザ端末で生成される動画データのビットレートまたはその上限を、前記ライブ配信に同時に参加する配信者の数が多いほど低くなるように、決定することと、
決定されたビットレートまたはその上限を前記複数の配信者の各々のユーザ端末にネットワークを介して通知することと、
前記ライブ配信に参加する前記複数の配信者の各々のユーザ端末からネットワークを介して動画データを受信することと、を含む方法。

【請求項8】

複数の配信者と少なくとも一人の視聴者とが参加するライブ配信において、前記複数の配信者の各々のユーザ端末に、
前記ライブ配信に同時に参加する配信者の数が多いほど低くなるように調整されたビットレートで動画データを生成する機能と、
生成された動画データをサーバにネットワークを介して送信する機能と、
前記サーバからネットワークを介して、前記ライブ配信に参加する配信者の数が多いほど低くなるよう決定されたビットレートの上限を受信する機能と、
前記複数の配信者の各々のユーザ端末と前記サーバとの間の通信状態に応じて、受信した上限を超えない範囲でビットレートを決定する機能と、
を実現させるためのコンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、サーバ及び方法に関する。

【背景技術】

【0002】

ＩＴ技術の発展と共に情報のやりとりの様も移り変わってきた。昭和の時代には新聞やテレビなどの一方通行の情報伝達が主であった。平成になると、ケータイやパソコンが普及し、インターネットの通信速度も大きく改善されたので、チャットサービスなどの即時双方向通信サービスが台頭し、また記憶コストの低減に伴ってオンデマンド型の動画配信サービスが受け入れられていった。そして、現在、令和の時代となり、スマートフォンの高機能化や５Ｇに代表されるネットワークの速度のさらなる向上を受けて、動画によるリアルタイムのコミュニケーションを実現するサービス、特にライブ配信（Live Streaming）サービスが急速に認知度を高めている。ライブ配信サービスは、離れた場所にいても皆が同じ楽しい時間を共有できるサービスとして、若者を中心に利用者が拡大している。

【0003】

非特許文献１には、複数の配信者が同時に参加可能なライブ配信を実現するグループコール機能が開示されている。

【先行技術文献】

【非特許文献】

【0004】

【文献】「Group Call」、１７ＬＩＶＥ、URL:https://helpfeel.com/17media-jp/Group_Call-60daae9216d6af0022bcb373

【発明の概要】

【発明が解決しようとする課題】

【0005】

従来、基本的に一人の配信者が多数の視聴者に向けてライブ配信を行うことを前提にネットワークが構成されている。しかしながら、グループコール機能に代表されるような、複数の配信者が参加するライブ配信はその前提に合致しないので、その特性に応じた配信の仕組みが求められている。

【0006】

本開示はこうした課題に鑑みてなされたものであり、その目的は、複数の配信者が参加可能なライブ配信に応じた配信の仕組みを実現できる技術の提供にある。

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

【0007】

本開示のある態様は、サーバに関する。このサーバは、複数の配信者が参加可能なライブ配信に参加する配信者のユーザ端末で生成される動画データのビットレートまたはその上限を、ライブ配信に参加する配信者の数が多いほど低くなるように、決定する手段と、決定されたビットレートまたはその上限を配信者のユーザ端末にネットワークを介して通知する手段と、ライブ配信に参加する複数の配信者の複数のユーザ端末からネットワークを介して動画データを受信する手段と、を備える。

【0008】

本発明の別の態様は、コンピュータプログラムである。このコンピュータプログラムは、複数の配信者が参加可能なライブ配信に参加する配信者のユーザ端末に、ライブ配信に参加する配信者の数が多いほど低くなるように調整されたビットレートで動画データを生成する機能と、生成された動画データをサーバにネットワークを介して送信する機能と、を実現させる。

【0009】

なお、以上の構成要素の任意の組み合わせや、本発明の構成要素や表現を装置、方法、システム、コンピュータプログラム、コンピュータプログラムを格納した記録媒体などの間で相互に置換したものもまた、本発明の態様として有効である。

【発明の効果】

【0010】

本発明によれば、複数の配信者が参加可能なライブ配信に応じた配信の仕組みを実現できる。

【図面の簡単な説明】

【0011】

【図1】本開示の実施の形態に係るライブ配信システムの構成を示す模式図である。

【図2】図１のサーバの機能および構成を示すブロック図である。

【図3】図２のプロファイル保持部の一例を示すデータ構造図である。

【図4】図２のストリーム保持部の一例を示すデータ構造図である。

【図5】図５（Ａ）～（Ｄ）は、グループコール型配信に参加する配信者の数が増えていった場合にビットレートがどのように制御されるかを示す模式図である。

【図6】本実施の形態に係る情報処理装置のハードウェア構成例を示すブロック図である。

【図7】変形例に係るプロファイル選択処理における一連の処理の流れを示すフローチャートである。

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

【0012】

以下、各図面に示される同一または同等の構成要素、部材、処理、信号には、同一の符号を付するものとし、適宜重複した説明は省略する。また、各図面において説明上重要ではない部材の一部は省略して表示する。

【0013】

本発明者は独自の検討により以下の知見を得た。
グループコールにおいてときどき、視聴者側で動画がカクついたり、ある配信者の画像が止まってしまうようなことが発生した。本発明者はまず視聴者側の通信状態が悪化したためであると考えたが、検証によりそれが理由ではないことがわかった。さらに検証を進めた結果、グループコールに参加する配信者の数が増えてくると、上記の問題が発生しやすくなることがわかった。

【0014】

本開示に係る実施の形態では、グループコールに参加する配信者の数が多くなるほど、配信者のユーザ端末においてより低いビットレートで動画データを生成するようにする。これにより、グループコールに参加する配信者の数が増えても、視聴者のユーザ端末に送信される動画データの総データ量の増加を抑えることができる。その結果、視聴者のユーザ端末においてバッファリングが発生する確率を低減し、カクつきや再生停止の発生を抑制することができる。

【0015】

図１は、本開示の実施の形態に係るライブ配信システム１の構成を示す模式図である。ライブ配信システム１は、グループコールなどの複数の配信者（ライバー、ストリーマ（Streamer）ともいう）が同時に参加可能なライブ配信（以下、グループコール型配信という）を実現する。ライブ配信システム１は、配信者ＬＶ（ＬＶ１、ＬＶ２）と視聴者（オーディエンスともいう）ＡＵ（ＡＵ１、ＡＵ２）とがリアルタイムでやりとりできる双方向型のライブ配信サービスを提供する。図１に示すように、ライブ配信システム１は、サーバ１０と、配信者側のユーザ端末２０（２０ａ、２０ｂ）と、視聴者側のユーザ端末３０（３０ａ、３０ｂ）と、を備える。配信者および視聴者をユーザと総称することがある。サーバ１０は、ネットワークＮＷに接続された一または複数の情報処理装置によって構成されてもよい。ユーザ端末２０、３０は例えばスマートフォンやタブレット型端末やラップトップＰＣやレコーダや携帯型ゲーム機やウェアラブル装置などの携帯端末であってもよいし、デスクトップＰＣなどの据え置き型の装置であってもよい。サーバ１０、ユーザ端末２０およびユーザ端末３０は、有線または無線の各種ネットワークＮＷにより互いに通信可能に接続される。

【0016】

配信者ＬＶおよび視聴者ＡＵは、ダウンロードサイトからネットワークＮＷを介して、本実施の形態に係るライブ配信アプリケーションプログラム（以下、ライブ配信アプリという）をユーザ端末２０、３０にダウンロードし、インストールする。あるいはまた、ライブ配信アプリはユーザ端末２０、３０にプリインストールされていてもよい。ライブ配信アプリがユーザ端末２０、３０により実行されることにより、ユーザ端末２０、３０はネットワークＮＷを介してサーバ１０と通信し、各種機能を実現する。以下、ユーザ端末２０、３０（のＣＰＵなどのプロセッサ）がライブ配信アプリを実行することにより実現する機能をユーザ端末２０、３０の機能として説明する。それらの機能は実際はライブ配信アプリがユーザ端末２０、３０に実現させる機能である。なお、他の実施の形態では、これらの機能は、サーバ１０からユーザ端末２０、３０のウェブブラウザにネットワークＮＷを介して送信され、そのウェブブラウザによって実行される、ＨＴＭＬ（HyperText Markup Language）などのプログラミング言語により記述されたコンピュータプログラムにより実現されてもよい。

【0017】

ユーザ端末２０、３０は、ユーザの像および音声を記録した動画データを生成してサーバ１０に提供する配信部と、サーバ１０から動画データを取得して再生する視聴部と、を備える。ユーザは、配信を行う場合は配信部を、視聴を行う場合は視聴部を、それぞれ起動する。配信部がアクティブとなっているユーザ端末は配信者側、つまり動画データの生成側のユーザ端末であり、視聴部がアクティブとなっているユーザ端末は視聴者側、つまり動画データの再生側のユーザ端末である。

【0018】

ライブ配信システム１には、配信者ＬＶと、視聴者ＡＵと、サーバ１０を管理する管理者（不図示）と、が関与する。配信者ＬＶは、自分の歌や、トーク、パフォーマンス、占い、ゲーム実況などのコンテンツを自身のユーザ端末２０で録音・録画してそのままサーバ１０にアップロードすることで、リアルタイムにコンテンツを発信する者である。管理者は、サーバ１０においてコンテンツのライブ配信のためのプラットフォームを提供し、また、配信者ＬＶと視聴者ＡＵとのリアルタイムのやりとりを仲介または管理する。視聴者ＡＵは、ユーザ端末３０でプラットフォームにアクセスして所望のコンテンツを選択し、視聴する。このコンテンツのライブ配信中に視聴者ＡＵがユーザ端末３０を介してコメントをしたり応援するための操作を行い、当該コンテンツを提供する配信者ＬＶがそのようなコメントや応援に反応し、当該反応が映像および／または音声で視聴者ＡＵに伝わることで、双方向のコミュニケーションが成立する。

【0019】

本明細書において「ライブ配信」は、配信者ＬＶのユーザ端末２０で録音・録画されたコンテンツが実質的にリアルタイムで視聴者ＡＵのユーザ端末３０で再生され視聴可能となる状態を実現するデータの伝送態様を意味するものであってもよく、またはそのような伝送態様により実現される配信そのものを意味してもよい。ライブ配信は、HTTP Live StreamingやCommon Media Application FormatやWeb Real-Time CommunicationsやReal-Time Messaging ProtocolやMPEG DASHなどの既存のライブ配信技術を用いて実現されてもよい。ライブ配信は、配信者ＬＶがコンテンツを録音・録画しているときに、視聴者ＡＵが所定の遅延をもって当該コンテンツを視聴可能な伝送態様を含む。遅延の大きさについて、少なくとも、配信者ＬＶと視聴者ＡＵとのやりとりが成立する程度の大きさの遅延は許される。ただし、ライブ配信は、コンテンツを録音・録画したデータ全体をいったんサーバに保存し、その後の任意のタイミングでユーザからの求めに応じて当該データをサーバからユーザに提供するいわゆるオンデマンド型の配信とは区別される。

【0020】

本明細書において「動画データ」は、ユーザ端末２０、３０の撮像機能により生成される画像データ（ビデオデータともいう）と、ユーザ端末２０、３０の音声入力機能により生成される音声データ（オーディオデータともいう）と、を含むデータである。動画データは、ユーザ端末２０、３０で再生されることで、ユーザによるコンテンツの視聴を可能とする。

【0021】

図１の例では、配信者ＬＶ１および配信者ＬＶ２がグループコール型配信に参加しており、配信者ＬＶ１および配信者ＬＶ２がそれぞれ同時にトークをライブ配信している。配信者ＬＶ１のユーザ端末２０ａはトークを行っている配信者ＬＶ１の像および音声を録画・録音することで動画データを生成し、ネットワークＮＷを介してサーバ１０に送信する。配信者ＬＶ２のユーザ端末２０ｂも同様に、トークを行っている配信者ＬＶ２の像および音声を録画・録音することで動画データを生成し、ネットワークＮＷを介してサーバ１０に送信する。

【0022】

配信者ＬＶ１および配信者ＬＶ２が参加しているグループコール型配信の視聴をプラットフォームに要求した視聴者ＡＵ１、ＡＵ２のユーザ端末３０ａ、３０ｂはそれぞれ、ネットワークＮＷを介してグループコール型配信に係る動画データを受信し、受信した動画データを再生することでディスプレイに動画像ＶＤ１、ＶＤ２を表示させると共にスピーカーから音声を出力する。各ユーザ端末３０ａ、３０ｂで表示される動画像ＶＤ１、ＶＤ２は実質的に同一であり、配信者ＬＶ１のユーザ端末２０ａが撮像した動画像ＶＤＡを表示する領域と、配信者ＬＶ２のユーザ端末２０ｂが撮像した動画像ＶＤＢを表示する領域と、を有する。動画像ＶＤＡおよび動画像ＶＤＢは視聴者のユーザ端末３０において同時に再生され、ディスプレイにおいて同一の画面内に表示される。当該画面において動画像ＶＤＡ、ＶＤＢのそれぞれに割り当てられる表示領域は、単一の配信者によるライブ配信においてその配信者の動画像に割り当てられる表示領域よりも小さい。図１の例では二分割が採用される。各ユーザ端末３０ａ、３０ｂで出力される音声は実質的に同一であり、配信者ＬＶ１のユーザ端末２０ａが取得した音声と、配信者ＬＶ２のユーザ端末２０ｂが取得した音声と、を含む。配信者ＬＶ１のユーザ端末２０ａはネットワークＮＷを介して、録画された配信者ＬＶ２の動画像ＶＤＢを受信し、録画された配信者ＬＶ１の動画像ＶＤＡと共にディスプレイに表示させる。配信者ＬＶ２のユーザ端末２０ｂはネットワークＮＷを介して、録画された配信者ＬＶ１の動画像ＶＤＡを受信し、録画された配信者ＬＶ２の動画像ＶＤＢと共にディスプレイに表示させる。

【0023】

配信者ＬＶのユーザ端末２０における録音・録画と、視聴者ＡＵのユーザ端末３０における動画データの再生と、は実質的に同時に行われる。配信者ＬＶ１のトークの内容についてひとりの視聴者ＡＵ１がコメントをユーザ端末３０ａに入力すると、サーバ１０は当該コメントをリアルタイムで配信者ＬＶ１のユーザ端末２０ａに表示させると共に、もうひとりの配信者ＬＶ２のユーザ端末２０ｂおよび各視聴者ＡＵ１、ＡＵ２のユーザ端末３０ａ、３０ｂにも表示させる。当該コメントを読んだ配信者ＬＶ１がその内容に被せたトークを展開すると、そのトークの動画像と音声が配信者ＬＶ２のユーザ端末２０ｂおよび各視聴者ＡＵ１、ＡＵ２のユーザ端末３０ａ、３０ｂで出力され、これにより配信者ＬＶ１と視聴者ＡＵ１との会話が成立したと認識される。このように、ライブ配信システム１では、一方通行でない双方向のコミュニケーションを可能とするグループコール型配信が実現される。

【0024】

図２は、図１のサーバ１０の機能および構成を示すブロック図である。図２に示す各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組み合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。

【0025】

サーバ１０は、受信部１０２と、関連付け部１０４と、配信部１０６と、プロファイル設定部１０８と、通信状態測定部１１０と、レート制御部１１２と、プロファイル保持部１１４と、ストリーム保持部１１６と、を含む。

【0026】

図３は、図２のプロファイル保持部１１４の一例を示すデータ構造図である。プロファイル保持部１１４は、予め管理者により設定された異なる複数のプロファイルを保持する。プロファイルは、配信者ＬＶのユーザ端末２０が生成する動画データの品質やデータ量を決めるパラメータおよび／または当該パラメータに課せられる条件のセットである。プロファイル保持部１１４は、プロファイルを特定するプロファイルＩＤと、当該プロファイルに対応する配信者の数の範囲と、解像度と、ビットレートの範囲（下限値および上限値）と、フレームレートと、を対応付けて保持する。解像度は縦のピクセル数と横のピクセル数とで表される。ビットレートは単位時間あたりのデータ量であって、例えばｂｐｓ（ビット／秒）の単位で表される。フレームレートは単位時間あたりのフレームの数であって、例えばｆｐｓ（フレーム数／秒）の単位で表される。

【0027】

図３の例でプロファイルＩＤ「Ｐ１」、「Ｐ２」、「Ｐ３」のプロファイルはそれぞれ高品質、中品質、低品質の動画に対応する。プロファイル保持部１１４に保持される複数のプロファイルは、グループコール型配信に参加する配信者の数が増えてビットレートの上限が低くなる場合に、フレームレートは維持され、解像度が低くなるよう設定される。ビットレートは解像度とフレームレートとの積に比例するので、ビットレートを低くする場合、解像度またはフレームレートもしくはその両方を低くする必要がある。本実施の形態では、解像度を犠牲にしてフレームレートを維持する。これにより、グループコール型配信においても単一の配信者によるライブ配信と同等の動画像の滑らかさを実現することができる。同時に、グループコール型配信では各配信者の動画像の表示領域は単一の配信者によるライブ配信のものより小さくなるので、解像度を低下させてもそれによる画質の低下は比較的目立たない。このように、ビットレートの低下を解像度の低下で吸収し、フレームレートを維持する設定は、グループコール型配信により適した設定である。

【0028】

図４は、図２のストリーム保持部１１６の一例を示すデータ構造図である。ストリーム保持部１１６は現在行われているライブ配信の情報を保持する。ストリーム保持部１１６は、ライブ配信システム１が提供するライブ配信プラットフォームにおいてライブ配信を特定するストリームＩＤと、当該ライブ配信の配信者を特定するユーザＩＤである配信者ＩＤと、当該ライブ配信の視聴者を特定するユーザＩＤである視聴者ＩＤと、を対応付けて保持する。図４の例では、ストリームＩＤ「ＧＣＳ０１」はグループコール型配信を特定するＩＤであり、複数の配信者ＩＤに対応付けられている。

【0029】

図２に戻り、受信部１０２は、グループコール型配信に参加している配信者ＬＶ１、ＬＶ２のユーザ端末２０ａ、２０ｂからネットワークＮＷを介して動画データを受信する。以下、ユーザ端末２０ａが生成してサーバ１０に送信する動画データを第１動画データと呼び、ユーザ端末２０ｂが生成してサーバ１０に送信する動画データを第２動画データと呼ぶ。

【0030】

関連付け部１０４は、受信部１０２により受信された第１動画データと第２動画データとを関連付ける。関連付け部１０４は、配信者ＬＶ１のユーザ端末２０ａおよび配信者ＬＶ２のユーザ端末２０ｂのそれぞれに予め同じストリームＩＤを通知してもよい。この場合、各ユーザ端末２０ａ、２０ｂで生成される第１動画データ、第２動画データには通知された同じストリームＩＤが付与されるので、それにより第１動画データと第２動画データとが関連付けられる。あるいはまた、関連付け部１０４は、受信された第１動画データに付随する配信者ＬＶ１の配信者ＩＤを取得し、それに対応するストリームＩＤをストリーム保持部１１６から取得して第１動画データに付与する。関連付け部１０４は、受信された第２動画データに付随する配信者ＬＶ２の配信者ＩＤを取得し、それに対応するストリームＩＤをストリーム保持部１１６から取得して第２動画データに付与する。グループコール型配信に参加している配信者の配信者ＩＤは全て同じストリームＩＤ（グループコール型配信を特定するストリームＩＤ）に対応付けられているので、第１動画データに関して取得されたストリームＩＤと、第２動画データに関して取得されたストリームＩＤとは一致する。これにより、第１動画データと第２動画データとが関連付けられる。

【0031】

配信部１０６は、グループコール型配信の視聴者ＡＵ１、ＡＵ２のユーザ端末３０ａ、３０ｂにネットワークＮＷを介して、関連付け部１０４により関連付けられた第１動画データおよび第２動画データをまとめて送信する。配信部１０６は、グループコール型配信のストリームＩＤが付与された複数の動画データを特定し、特定された複数の動画データをまとめて視聴者のユーザ端末３０に送信する。ユーザ端末３０は、受信した複数の動画データをそれぞれ再生することで得られる動画像を、一つの画面にまとめて表示させる。

【0032】

プロファイル設定部１０８は、グループコール型配信に参加する配信者ＬＶのユーザ端末２０で生成される動画データのビットレートの上限を、グループコール型配信に参加する配信者の数が多いほど低くなるように、決定する。プロファイル設定部１０８は、周期的にまたはグループコール型配信に参加する配信者の数に増減があったタイミングで、グループコール型配信に参加する配信者の数を取得する。プロファイル設定部１０８は、プロファイル保持部１１４を参照し、取得した数に対応するプロファイルを特定する。上述のとおり、プロファイル保持部１１４に登録されている複数のプロファイルは、グループコール型配信に参加する配信者の数が多いほどビットレートの上限が低くなるよう設定されている。

【0033】

通信状態測定部１１０は、グループコール型配信に参加している配信者ＬＶのユーザ端末２０とサーバ１０との間の通信状態を測定する。通信状態の測定には通信速度や帯域幅などの公知の尺度が用いられてもよい。

【0034】

レート制御部１１２は、通信状態測定部１１０による測定結果に応じて、グループコール型配信に参加している配信者ＬＶのユーザ端末２０で生成される動画データのビットレートを動的に制御する。レート制御部１１２におけるビットレートの制御は、プロファイル設定部１０８によって特定されたプロファイルによる制限を受ける。レート制御部１１２は、特定されたプロファイルで指定される上限を超えない範囲でビットレートを決定する。このように決定されたビットレートは、グループコール型配信に参加する配信者の数が多いほど低くなるように調整されたビットレートであると言える。

【0035】

レート制御部１１２は、決定されたビットレートを、通信状態測定部１１０による測定の対象となった配信者ＬＶのユーザ端末２０にネットワークＮＷを介して通知する。ここでの通知は、決定されたビットレートをそのまま送信することで実現されてもよいし、サーバ１０とユーザ端末２０とで共通のビットレート用コードブックを用意しておき、コードを通知することによりビットレートを指定する形で実現されてもよい。配信者ＬＶのユーザ端末２０は、通知されたビットレートで動画データを生成し、生成された動画データをサーバ１０にネットワークＮＷを介して送信する。

【0036】

以上の構成によるライブ配信システム１の動作を説明する。
図５（Ａ）～（Ｄ）は、グループコール型配信に参加する配信者の数が増えていった場合にビットレートがどのように制御されるかを示す模式図である。図５（Ａ）はグループコール型配信が存在しないときのビットレートの状態を示す。配信者Ａのユーザ端末（以下、配信者端末Ａという）で生成される動画データのビットレートはプロファイルにより制限を受けることはない。当該ビットレートは、システム上の上限値と下限値との間で、通信状態に応じて決定される。例えば、通信状態が悪ければビットレートは低くなり、通信状態が良ければビットレートは高くなる。通信状態測定部１１０およびレート制御部１１２は、通信状態の変化に応じてビットレートを増減または変化させる。配信者Ｂ、Ｃについても同様である。

【0037】

図５（Ｂ）は３人の配信者Ａ、Ｂ、Ｃがグループコール型配信に参加しているときのビットレートの状態を示す。グループコール型配信に参加する配信者の数は３であり、その数に対応するプロファイル「Ｐ１」（図３参照）が特定されている。このプロファイル「Ｐ１」にはビットレートの上限値（以下、ＧＣ上限値という）と下限値（以下、ＧＣ下限値という）とが規定されている。ＧＣ上限値はシステム上限値よりも低く、ＧＣ下限値はシステム下限値よりも高く、設定される。配信者端末Ａ、Ｂ、Ｃで生成される動画データのビットレートは、ＧＣ上限値を上回らないよう、かつ、ＧＣ下限値を下回らないよう、決定される。図５（Ｂ）の例では、配信者端末Ａについて、通信状態に応じて決定されたビットレートがＧＣ上限値よりも低い値であるから、その値がそのまま採用される。

【0038】

図５（Ｃ）は図５（Ｂ）の状態から２人増えて５人の配信者Ａ、Ｂ、Ｃ、Ｄ、Ｅがグループコール型配信に参加しているときのビットレートの状態を示す。グループコール型配信に参加する配信者の数は５であり、その数に対応するプロファイル「Ｐ２」（図３参照）が特定されている。図５（Ｃ）の状態では図５（Ｂ）の状態よりもＧＣ上限値が低くなる。その結果、配信者端末Ａについて、通信状態に応じた場合のビットレートがＧＣ上限値を上回るので、配信者端末ＡのビットレートはＧＣ上限値に設定される。同様の事象が配信者端末Ｅでも発生し、配信者端末ＥのビットレートもＧＣ上限値に設定される。

【0039】

図５（Ｄ）は図５（Ｃ）の状態から２人増えて７人の配信者Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇがグループコール型配信に参加しているときのビットレートの状態を示す。グループコール型配信に参加する配信者の数は７であり、その数に対応するプロファイル「Ｐ３」（図３参照）が特定されている。図５（Ｄ）の状態では図５（Ｃ）の状態よりもＧＣ上限値が低くなる。その結果、配信者端末Ａ、Ｃ、Ｄ、Ｅ、Ｆについて、通信状態に応じた場合のビットレートがＧＣ上限値を上回るので、配信者端末Ａ、Ｃ、Ｄ、Ｅ、ＦのビットレートはＧＣ上限値に設定される。

【0040】

上述の実施の形態において、保持部の例は、ハードディスクや半導体メモリである。また、本明細書の記載に基づき、各部を、図示しないＣＰＵや、インストールされたアプリケーションプログラムのモジュールや、システムプログラムのモジュールや、ハードディスクから読み出したデータの内容を一時的に記憶する半導体メモリなどにより実現できることは本明細書に触れた当業者には理解される。

【0041】

本実施の形態に係るライブ配信システム１によると、グループコール型配信に参加する配信者の数が多いほど各配信者のユーザ端末で生成される動画データのビットレートが低くなる。仮に通信状態が良くて高いビットレートの設定が可能であっても、ビットレートはグループコール型配信に参加する配信者の数に応じて設定された上限を超えないように設定される。したがって、グループコール型配信に参加する視聴者のユーザ端末が受ける動画データのデータ量を抑制することができ、それにより視聴者のユーザ端末におけるグループコール型配信のよりスムーズな再生を実現できる。

【0042】

グループコール型配信に参加する視聴者のユーザ端末は、参加する全ての配信者の動画データをまとめて受信するので、参加する配信者の数が増えるとその分受信する動画データのデータ量も増加する。このデータ量の増加は、グループコール型配信のスムーズな再生の妨げとなる。そこで、本実施の形態では動画データの生成段階においてビットレートを参加者数に応じて制限することで、このデータ量の増加を抑制する。これにより、グループコール型配信に参加する配信者の数が増えてもスムーズな再生を維持することができる。

【0043】

サーバ１０におけるトランスコーディング等により動画データのデータ量を低減する手法も考えられるが、一般にトランスコーディングは遅延を増加させる傾向にある。したがって、リアルタイム性を重視するライブ配信にあっては、動画データの生成段階でビットレートを制限することでトランスコーディングになるべく頼らないようにする本実施の形態に係る手法がより適している。例えば、動画データが配信者のユーザ端末で生成されてからサーバ１０を通過して視聴者のユーザ端末で再生されるまでの間に、当該動画データはトランスコーディングされなくてもよい。この場合、より遅延が少なく、かつ、参加者が増えても滑らかに再生されるグループコール型配信を実現できる。

【0044】

図６を参照して、本実施の形態に係る情報処理装置のハードウェア構成について説明する。図６は、本実施の形態に係る情報処理装置のハードウェア構成例を示すブロック図である。図示された情報処理装置９００は、例えば、本実施の形態におけるサーバ１０およびユーザ端末２０、３０のそれぞれを実現しうる。

【0045】

情報処理装置９００は、ＣＰＵ９０１、ＲＯＭ（Read Only Memory）９０３、およびＲＡＭ（Random Access Memory）９０５を含む。また、情報処理装置９００は、ホストバス９０７、ブリッジ９０９、外部バス９１１、インタフェース９１３、入力装置９１５、出力装置９１７、ストレージ装置９１９、ドライブ９２１、接続ポート９２５、通信装置９２９を含んでもよい。さらに、情報処理装置９００は、カメラなどの撮像装置（不図示）を含む。また、情報処理装置９００は、ＣＰＵ９０１に代えて、またはこれとともに、ＤＳＰ（Digital Signal Processor）またはＡＳＩＣ（Application Specific Integrated Circuit）と呼ばれるような処理回路を有してもよい。

【0046】

ＣＰＵ９０１は、演算処理装置および制御装置として機能し、ＲＯＭ９０３、ＲＡＭ９０５、ストレージ装置９１９、またはリムーバブル記録媒体９２３に記録された各種プログラムに従って、情報処理装置９００内の動作全般またはその一部を制御する。例えば、ＣＰＵ９０１は、本実施の形態におけるサーバ１０およびユーザ端末２０、３０のそれぞれに含まれる各機能部の動作全般を制御する。ＲＯＭ９０３は、ＣＰＵ９０１が使用するプログラムや演算パラメータなどを記憶する。ＲＡＭ９０５は、ＣＰＵ９０１の実行において使用するプログラムや、その実行において適宜変化するパラメータなどを一次記憶する。ＣＰＵ９０１、ＲＯＭ９０３、およびＲＡＭ９０５は、ＣＰＵバスなどの内部バスにより構成されるホストバス９０７により相互に接続されている。さらに、ホストバス９０７は、ブリッジ９０９を介して、ＰＣＩ（Peripheral Component Interconnect/Interface）バスなどの外部バス９１１に接続されている。

【0047】

入力装置９１５は、例えば、マウス、キーボード、タッチパネル、ボタン、スイッチおよびレバーなど、ユーザによって操作される装置であってもよいし、マイクロフォンなどの音センサ、加速度センサ、傾きセンサ、赤外線センサ、深度センサ、温度センサ、湿度センサなど物理量を電気信号に変換する装置であってもよい。入力装置９１５は、例えば、赤外線やその他の電波を利用したリモートコントロール装置であってもよいし、情報処理装置９００の操作に対応した携帯電話などの外部接続機器９２７であってもよい。入力装置９１５は、ユーザが入力した情報または感知した物理量に基づいて入力信号を生成してＣＰＵ９０１に出力する入力制御回路を含む。ユーザは、この入力装置９１５を操作することによって、情報処理装置９００に対して各種のデータを入力したり処理動作を指示したりする。

【0048】

出力装置９１７は、取得した情報をユーザに対して視覚的または聴覚的に通知することが可能な装置で構成される。出力装置９１７は、例えば、ＬＣＤ、ＰＤＰ、ＯＥＬＤなどのディスプレイ、スピーカおよびヘッドホンなどの音響出力装置、ならびにプリンタ装置などでありうる。出力装置９１７は、情報処理装置９００の処理により得られた結果を、テキストまたは画像などの映像として出力したり、音響などの音として出力したりする。

【0049】

ストレージ装置９１９は、情報処理装置９００の記憶部の一例として構成されたデータ格納用の装置である。ストレージ装置９１９は、例えば、ＨＤＤ（Hard Disk Drive）などの磁気記憶部デバイス、半導体記憶デバイス、光記憶デバイス、または光磁気記憶デバイスなどにより構成される。このストレージ装置９１９は、ＣＰＵ９０１が実行するプログラムや各種データ、および外部から取得した各種のデータなどを格納する。

【0050】

ドライブ９２１は、磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリなどのリムーバブル記録媒体９２３のためのリーダライタであり、情報処理装置９００に内蔵、あるいは外付けされる。ドライブ９２１は、装着されているリムーバブル記録媒体９２３に記録されている情報を読み出して、ＲＡＭ９０５に出力する。また、ドライブ９２１は、装着されているリムーバブル記録媒体９２３に記録を書き込む。

【0051】

接続ポート９２５は、機器を情報処理装置９００に直接接続するためのポートである。接続ポート９２５は、例えば、ＵＳＢ（Universal Serial Bus）ポート、ＩＥＥＥ１３９４ポート、ＳＣＳＩ（Small Computer System Interface）ポートなどでありうる。また、接続ポート９２５は、ＲＳ－２３２Ｃポート、光オーディオ端子、ＨＤＭＩ（登録商標）（High-Definition Multimedia Interface）ポートなどであってもよい。接続ポート９２５に外部接続機器９２７を接続することで、情報処理装置９００と外部接続機器９２７との間で各種のデータが交換されうる。

【0052】

通信装置９２９は、例えば、ネットワークＮＷに接続するための通信デバイスなどで構成された通信インタフェースである。通信装置９２９は、例えば、有線または無線ＬＡＮ（Local Area Network）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、またはＷＵＳＢ（Wireless USB）用の通信カードなどでありうる。また、通信装置９２９は、光通信用のルータ、ＡＤＳＬ（Asymmetric Digital Subscriber Line）用のルータ、または、各種通信用のモデムなどであってもよい。通信装置９２９は、例えば、インターネットや他の通信機器との間で、ＴＣＰ／ＩＰなどの所定のプロトコルを用いて信号などを送受信する。また、通信装置９２９に接続される通信ネットワークＮＷは、有線または無線によって接続されたネットワークであり、例えば、インターネット、家庭内ＬＡＮ、赤外線通信、ラジオ波通信または衛星通信などである。なお、通信装置９２９は、通信部としての機能を実現する。

【0053】

カメラなどの撮像装置（不図示）は、例えばＣＣＤ（Charge Coupled Device）またはＣＭＯＳ（Complementary Metal Oxide Semiconductor）などの撮像素子、および撮像素子への被写体像の結像を制御するためのレンズなどの各種の部材を用いて実空間を撮像し、撮像画像を生成する装置である。当該撮像装置は、静止画を撮像するものであってもよいし、または動画を撮像するものであってもよい。

【0054】

以上、実施の形態に係るライブ配信システム１の構成と動作について説明した。この実施の形態は例示であり、各構成要素や各処理の組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本開示の範囲にあることは当業者に理解される。

【0055】

実施の形態では、サーバ１０がグループコール型配信に参加する配信者の数からビットレートの上限を動的に決定し、さらに通信状態に応じて当該上限を超えない範囲でビットレートを決定し、決定されたビットレートを配信者のユーザ端末に通知する場合を説明したが、これに限られない。例えば、サーバ１０はグループコール型配信に参加する配信者の数を取得し、取得した数をグループコール型配信の全ての配信者のユーザ端末に通知してもよい。この場合、配信者のユーザ端末はプロファイル保持部１１４と同等の情報を有しており、通知された数から当該情報を参照してビットレートの上限を決定する。さらにユーザ端末は自分で測定するか通信状態測定部１１０から測定結果を取得することにより通信状態を取得し、取得した通信状態に応じて上限を超えない範囲でビットレートを決定する。このように決定されたビットレートは、グループコール型配信に参加する配信者の数が多いほど低くなるように調整されたビットレートであると言える。

【0056】

あるいはまた、例えば、サーバ１０はグループコール型配信に参加する配信者の数が多いほど低くなるようビットレートの上限を決定し、決定された上限をグループコール型配信の配信者全員のユーザ端末に通知してもよい。

【0057】

図７は、変形例に係るプロファイル選択処理における一連の処理の流れを示すフローチャートである。サーバ１０は、グループコール型配信に参加する配信者の数が変化したか否かを判定する（Ｓ７０２）。変化したと判定された場合（Ｓ７０２のＹ）、サーバ１０は変化後の配信者の数が３以下であるか否かを判定する（Ｓ７０４）。３以下である場合（Ｓ７０４のＹ）、サーバ１０はビットレートの上限が最も高い高品質動画のプロファイルを選択する（Ｓ７０６）。３より大きい場合（Ｓ７０４のＮ）、サーバ１０は変化後の配信者の数が６以下であるか否かを判定する（Ｓ７０８）。６以下である場合（Ｓ７０８のＹ）、サーバ１０はビットレートの上限が中間である中品質動画のプロファイルを選択する（Ｓ７１０）。６より大きい場合（Ｓ７０８のＮ）、サーバ１０はビットレートの上限が最も低い低品質動画のプロファイルを選択する（Ｓ７１２）。サーバ１０は、ステップＳ７０６、Ｓ７１０またはＳ７１２で選択されたプロファイルを各配信者のユーザ端末に通知または送信する（Ｓ７１４）。そして処理はステップＳ７０２に戻る。

【0058】

この場合、配信者のユーザ端末は上限を受信する。ユーザ端末は、自分で測定するか通信状態測定部１１０から測定結果を取得することにより通信状態を取得し、取得した通信状態に応じて上限を超えない範囲でビットレートを決定する。このように決定されたビットレートは、グループコール型配信に参加する配信者の数が多いほど低くなるように調整されたビットレートであると言える。

【0059】

実施の形態では、グループコール型配信に参加する複数の配信者の複数の動画データは関連付けられた形でそれぞれ視聴者のユーザ端末に送信され、視聴者のユーザ端末において複数の動画データがそれぞれ再生されることでグループコール型配信の画面が構成される場合を説明したがこれに限られない。例えば、サーバ１０が複数の配信者の複数の動画データを合成することで新たなグループコール型配信用の動画データを生成し、生成された動画データを視聴者のユーザ端末に送信してもよい。この場合でも、実施の形態に係るライブ配信システム１により奏される作用効果と同様の作用効果が奏される。

【0060】

実施の形態では複数のプロファイルを用意し、そのなかからグループコール型配信に参加する配信者の数に対応するプロファイルを選択する場合を説明したが、これに限られない。例えば、サーバ１０はグループコール型配信の視聴者のユーザ端末とサーバ１０との間の通信状態を測定し、測定された通信状態に応じて各プロファイルに規定されるビットレートの上限を調整してもよい。例えば、サーバ１０は、測定された通信状態が良好なほどビットレートの上限を高めるように調整してもよい。

【0061】

実施の形態に係る技術的思想を、配信者の画像の代わりに配信者の動きと同期した動きをするアバターを用いるバーチャルライブ配信や、ライブコマースに適用してもよい。

【0062】

本明細書において説明された処理手順、特にフロー図、フローチャートを用いて説明された処理手順においては、その処理手順を構成する工程（ステップ）の一部を省略すること、その処理手順を構成する工程として明示されていない工程を追加すること、及び／又は当該工程の順序を入れ替えることが可能であり、このような省略、追加、順序の変更がなされた処理手順も本開示の趣旨を逸脱しない限り本開示の範囲に含まれる。

【0063】

サーバ１０により実現される機能の少なくとも一部は、サーバ１０以外の装置、例えばユーザ端末２０、３０により実現されてもよい。ユーザ端末２０、３０により実現される機能の少なくとも一部は、ユーザ端末２０、３０以外の装置、例えば、サーバ１０により実現されてもよい。

【0064】

実施の形態では、動画データが配信者のユーザ端末で生成されてから視聴者のユーザ端末で再生されるまでの間に、トランスコーディング等により形式や仕様が変更されてもよいし、されなくてもよい。

【要約】

【課題】複数の配信者が参加可能なライブ配信に応じた配信の仕組みを実現する。
【解決手段】サーバは、複数の配信者が参加可能なライブ配信に参加する配信者のユーザ端末で生成される動画データのビットレートまたはその上限を、ライブ配信に参加する配信者の数が多いほど低くなるように、決定する手段と、決定されたビットレートまたはその上限を配信者のユーザ端末にネットワークを介して通知する手段と、ライブ配信に参加する複数の配信者の複数のユーザ端末からネットワークを介して動画データを受信する手段と、を備える。
【選択図】図１

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】