特許 7720009 ビットレート選択装置、ビットレート選択方法及びプログラム

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

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

(11)【特許番号】

(24)【登録日】2025-07-30

(45)【発行日】2025-08-07

(54)【発明の名称】ビットレート選択装置、ビットレート選択方法及びプログラム

(51)【国際特許分類】

   H04N 7/15 20060101AFI20250731BHJP

【ＦＩ】

H04N7/15

【請求項の数】 8

(21)【出願番号】P 2024520432

(86)(22)【出願日】2023-05-02

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

(87)【国際公開番号】W WO2023219043

(87)【国際公開日】2023-11-16

【審査請求日】2024-08-16

(31)【優先権主張番号】PCT/JP2022/019985

(32)【優先日】2022-05-11

(33)【優先権主張国・地域又は機関】JP

(73)【特許権者】

【識別番号】000004226

【氏名又は名称】ＮＴＴ株式会社

(74)【代理人】

【識別番号】110004381

【氏名又は名称】弁理士法人ＩＴＯＨ

(72)【発明者】

【氏名】横田 将裕

(72)【発明者】

【氏名】河野 太一

(72)【発明者】

【氏名】山岸 和久

【審査官】富樫 明

(56)【参考文献】

【文献】米国特許出願公開第２００８／０１０１４１０（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０２１／０２５８３６４（ＵＳ，Ａ１）

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

Ｈ０４Ｎ ７／１４－１５

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

【請求項1】

オンラインリアルタイムコミュニケーションに関して複数の第１の端末のそれぞれから送信される映像を配信装置を介して受信する複数の第２の端末それぞれのユーザの前記映像に関する体感品質が閾値以上であるという制約において、前記複数の第１の端末と前記複数の第２の端末との組み合わせごとの前記映像のビットレートの総和が最小となるように、前記組み合わせごとの前記映像のビットレートを複数段階の値から選択するように構成されている選択部と、
前記第１の端末それぞれに対して、当該第１の端末に係る組み合わせについて前記選択部が選択した１以上のビットレートでの符号化の指示を送信するように構成されている指示部と、
を有することを特徴とするビットレート選択装置。

【請求項2】

前記選択部は、更に、前記組み合わせごとのビットレートのうち重複を除くビットレートの合計が前記複数の第１の端末から前記配信装置へのアップロードの可用帯域以下であるという制約において、前記組み合わせごとの前記映像のビットレートを選択するように構成されている、
ことを特徴とする請求項１記載のビットレート選択装置。

【請求項3】

前記選択部は、更に、前記組み合わせごとのビットレートの合計が前記配信装置から前記複数の第２の端末へのダウンロードの可用帯域以下であるという制約において、前記組み合わせごとの前記映像のビットレートを選択するように構成されている、
ことを特徴とする請求項１又は２記載のビットレート選択装置。

【請求項4】

前記選択部は、更に、前記映像についてそれぞれの前記第１の端末が送信可能なビットレート数が所定数以下であるという制限において、前記組み合わせごとの前記映像のビットレートを選択するように構成されている、
ことを特徴とする請求項１記載のビットレート選択装置。

【請求項5】

オンラインリアルタイムコミュニケーションに関して複数の第１の端末のそれぞれから送信される映像を配信装置を介して受信する複数の第２の端末それぞれのユーザの前記映像に関する体感品質が閾値以上であるという制約において、前記複数の第１の端末と前記複数の第２の端末との組み合わせごとの前記映像のビットレートの総和が最小となるように、前記組み合わせごとの前記映像のビットレートを複数段階の値から選択する選択手順と、
前記第１の端末それぞれに対して、当該第１の端末に係る組み合わせについて前記選択手順が選択した１以上のビットレートでの符号化の指示を送信する指示手順と、
をコンピュータが実行することを特徴とするビットレート選択方法。

【請求項6】

前記選択手順は、更に、前記組み合わせごとのビットレートのうち重複を除くビットレートの合計が前記複数の第１の端末から前記配信装置へのアップロードの可用帯域以下であるという制約において、前記組み合わせごとの前記映像のビットレートを選択する、
ことを特徴とする請求項５記載のビットレート選択方法。

【請求項7】

前記選択手順は、更に、前記組み合わせごとのビットレートの合計が前記配信装置から前記複数の第２の端末へのダウンロードの可用帯域以下であるという制約において、前記組み合わせごとの前記映像のビットレートを選択する、
ことを特徴とする請求項５又は６記載のビットレート選択方法。

【請求項8】

オンラインリアルタイムコミュニケーションに関して複数の第１の端末のそれぞれから送信される映像を配信装置を介して受信する複数の第２の端末それぞれのユーザの前記映像に関する体感品質が閾値以上であるという制約において、前記複数の第１の端末と前記複数の第２の端末との組み合わせごとの前記映像のビットレートの総和が最小となるように、前記組み合わせごとの前記映像のビットレートを複数段階の値から選択する選択手順と、
前記第１の端末それぞれに対して、当該第１の端末に係る組み合わせについて前記選択手順が選択した１以上のビットレートでの符号化の指示を送信する指示手順と、
をコンピュータに実行させることを特徴とするプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ビットレート選択装置、ビットレート選択方法及びプログラムに関する。

【背景技術】

【0002】

近年、テレワークの推進が進む中でＷｅｂ会議等のオンラインリアルタイムコミュニケーションサービスの利用が増えている。このようなサービスを実現する技術としてＷｅｂＲＴＣ等の技術がある。ＷｅｂＲＴＣは、World Wide Web ConsortiumやInternet Engineering Task Forceで標準化されている技術である。

【0003】

このような技術を利用することでオンラインリアルタイムコミュニケーションサービスを実現することが可能になってきているが、そのようなサービスを継続的にエンドユーザに提供するためには、ユーザが利用する際のユーザ体感品質（ＱｏＥ（Quality of Experience））を高めるとともに、サービス提供にかかる運用コスト（ネットワーク設備コスト等）を低減する必要がある。

【0004】

ＷｅｂＲＴＣでは、多人数会議を実現するために３つのアーキテクチャが提案されている。（１）参加端末間をフルメッシュで接続するＰ２Ｐ、（２）各クライアントが映像データをサーバに送信し、サーバ側でトランスコードを行い参加クライアントに配信するMulti-point Control Unit、（３）各クライアントが映像データをサーバに送信し、サーバはその映像をそのまま参加クライアントに配信するＳＦＵ（Selective Forwarding Unit）である。

【0005】

ＳＦＵ方式では、全参加クライアントに同一品質の映像を配信することになるため、本方式には、ネットワーク状況が悪い参加者が存在するとその参加者に合わせて全体の品質が低下してしまうという課題がある。

【0006】

本課題に対処するために、Ｓｉｍｕｌｃａｓｔ方式が提案されている。Ｓｉｍｕｌｃａｓｔでは送信元クライアントは、複数段階の品質（ビットレート、解像度、フレームレート）の映像をサーバに送信する。サーバ側は各クライアントのネットワーク状況に合わせた品質を選択し、選択した品質で配信を行う。例えば、送信元クライアントは高品質（１Ｍｂｐｓ／７２０ｐ／３０ｆｐｓ）、中品質（４８０ｋｂｐｓ／４８０ｐ／３０ｆｐｓ）、低品質（１２８ｋｂｐｓ／１８０ｐ／１５ｆｐｓ）の映像を符号化し配信サーバに送信する。配信サーバは、ダウンロード帯域が十分広い送信先クライアントには高品質を、狭いクライアントには低品質を配信する。

【0007】

Ｓｉｍｕｌｃａｓｔにおける品質の段階は手動で設定することが考えられる。その他にも受信側クライアントのネットワーク状態に応じて適宜選択可能な品質（ビットレート、解像度、フレームレート）を変更していくことが考えられる（非特許文献１）。

【0008】

一方、ＷｅｂＲＴＣにおいて、品質改善のみではなくコストを考慮した制御が提案されている。この制御は、サービス提供者が設定した目標ＱｏＥとなるように各端末の映像ビットレートを制御することで、ＱｏＥを維持するとともに、データ転送量を削減することで、サービス提供者の運用コスト低減を実現する（非特許文献２）。

【先行技術文献】

【非特許文献】

【0009】

【文献】S.Petrangeli、"Dynamic video bitrate adaptation for WebRTC-based remote teaching applications"、IEEE、2018

【文献】T. Kimura, T. Kimura, A. Matsumoto and J. Okamoto、"BANQUET: Balancing Quality of Experience and Traffic Volume in Adaptive Video Streaming""、IEEE CNSM 2019、Feb 2020

【文献】Parametric bitstream-based quality assessment of progressive download and adaptive audiovisual streaming services over reliable transport、Recommendation ITU-T P.1203、2017、［online］、インターネット＜URL：https://www.itu.int/rec/T-REC-P.1203＞

【発明の概要】

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

【0010】

既存のＳｉｍｕｌｃａｓｔでは、設定者の知識やネットワーク状況に応じて品質（映像ビットレート、解像度、フレームレート）の段階が設定される。そのため、過剰に高いビットレートで符号化するように設定されてしまう可能性がある。その際に、ネットワーク状況が非常に良好な場合、過剰なビットレートを選択してしまい、ＱｏＥがあまり向上しないにもかかわらず高いビットレートが選択されることで、サービス提供事業者が必要なネットワーク設備やサーバ設備にかかる運用コストの増大のリスクがある。

【0011】

上記のようなデータ量の増加という課題に対処するために転送データ量を削減するための映像ビットレート制御技術（非特許文献２）が提案されているが、こちらは映像配信サービスを対象とした技術になっており、Ｗｅｂ会議サービスのＳｉｍｕｌｃａｓｔを考慮した技術となっていない。これらの状況から、Ｓｉｍｕｌｃａｓｔ方式において過剰な品質を抑制するために、各端末がアップロードする複数パターンのビットレートを適切に制御する方法が必要となる。

【0012】

本発明は、上記の点に鑑みてなされたものであって、映像の符号化に際して過剰なビットレートが選択される可能性を低減することを目的とする。

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

【0013】

そこで上記課題を解決するため、ビットレート選択装置は、オンラインリアルタイムコミュニケーションに関して複数の第１の端末のそれぞれから送信される映像を配信装置を介して受信する複数の第２の端末それぞれのユーザの前記映像に関する体感品質が閾値以上であるという制約において、前記複数の第１の端末と前記複数の第２の端末との組み合わせごとの前記映像のビットレートの総和が最小となるように、前記組み合わせごとの前記映像のビットレートを複数段階の値から選択するように構成されている選択部と、前記第１の端末それぞれに対して、当該第１の端末に係る組み合わせについて前記選択部が選択した１以上のビットレートでの符号化の指示を送信するように構成されている指示部と、を有する。

【発明の効果】

【0014】

映像の符号化に際して過剰なビットレートが選択される可能性を低減することができる。

【図面の簡単な説明】

【0015】

【図1】第１の実施の形態におけるオンラインリアルタイムコミュニケーションシステムの構成例を示す図である。

【図2】第１の実施の形態における制御サーバ１０のハードウェア構成例を示す図である。

【図3】第１の実施の形態におけるクライアント端末２０及び制御サーバ１０の機能構成例を示す図である。

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

【0016】

本実施の形態では、クライアントから収集した品質に関する情報、クライアントの情報、アップロード可用帯域、ダウンロード可用帯域の情報をもとに、過去Ｔ１秒前から未来Ｔ２秒後までの推定されたＱｏＥ（体感品質）を目標ＱｏＥに近づけるように送信元×送信先ごとにアップロードビットレートを制御する。これにより、必要なＱｏＥを保ちつつデータ通信量を抑制することができる。

【0017】

以下、図面に基づいて本発明の実施の形態を説明する。図１は、第１の実施の形態におけるオンラインリアルタイムコミュニケーションシステムの構成例を示す図である。図１において、複数のクライアント端末２０は、インターネット等のネットワークを介して配信サーバ３０及び制御サーバ１０に接続する。

【0018】

複数のクライアント端末２０のそれぞれは、Ｗｅｂ会議等のオンラインリアルタイムコミュニケーションに参加するユーザが利用するＰＣ（Personal Computer）、スマートフォン又はタブレット端末等の通信端末である。クライアント端末２０は、各種ログを制御サーバ１０へ送信したり、制御サーバ１０の指示に応じてメディア（映像及び音声等）に関するデータ（以下、「メディアデータ」という。）を符号化して送信したり、他参加者のメディアデータを受信して再生したりする。各クライアント端末２０は、例えば、自端末のユーザのメディアデータを送信する。各クライアント端末２０は、また、他端末からのメディアデータを受信し、それぞれのメディアデータを含む画面を表示する。

【0019】

制御サーバ１０は、各クライアント端末２０に対してアップロードビットレートを指示する１以上のコンピュータである。

【0020】

配信サーバ３０は、各クライアント端末２０から送信（アップロード）されるメディアデータを他のクライアント端末２０へ配信する１以上のコンピュータである。他のクライアント端末２０への配信について、配信サーバ３０は、当該他のクライアント端末２０のダウンロード帯域に応じて最適なビットレートで配信を行う。すなわち、配信サーバ３０は、ＷｅｂＲＴＣのＳｉｍｕｌｃａｓｔによって、各クライアント端末２０のダウンロード帯域に応じたビットレートでメディアデータの配信を行う。

【0021】

図２は、第１の実施の形態における制御サーバ１０のハードウェア構成例を示す図である。図２の制御サーバ１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。

【0022】

制御サーバ１０での処理を実現するプログラムは、ＣＤ－ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

【0023】

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従って制御サーバ１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。

【0024】

なお、クライアント端末２０及び配信サーバ３０も図２と同様のハードウェア構成を有してよい。但し、クライアント端末２０は、メディアデータを出力する表示装置及びスピーカや、メディアデータを入力するカメラ及びマイク等を有する。

【0025】

図３は、第１の実施の形態におけるクライアント端末２０及び制御サーバ１０の機能構成例を示す図である。

【0026】

図３において、クライアント端末２０は、クライアントログ送信部２１、アップロードビットレート制御部２２、送信データ符号化部２３及び受信データ復号化部２４を有する。これら各部は、クライアント端末２０にインストールされた１以上のプログラムが、クライアント端末２０のＣＰＵに実行させる処理により実現される。

【0027】

制御サーバ１０は、クライアントログ収集部１１、目標ＱｏＥ入力部１２、アップロードビットレート選択部１３及びアップロードビットレート指示部１４を有する。これら各部は、制御サーバ１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。

【0028】

図３を参照しながら、本実施の形態において実行される処理手順について説明する。なお、以下の処理は、特段の断りが無い限り、Ｗｅｂ会議等のオンラインリアルタイムコミュニケーション（以下、単に「Ｗｅｂ会議」という。）の実施中に実行される。また、以下の処理は、Ｗｅｂ会議に参加する複数のクライアント端末２０のそれぞれについて実行される。

【0029】

各クライアント端末２０のクライアントログ送信部２１は、定期的に（例えば、１秒周期で）品質推定のために必要な情報（当該周期における情報）、及びアップロードビットレートの推定のために必要な情報（当該周期における情報）を含むログ（以下、「クライアントログ」という。）をＷｅｂ会議の開始後に当該クライアント端末２０から収集し、収集したクライアントログを制御サーバ１０へ送信する。

【0030】

品質推定のために必要な情報とは、例えば、受信映像毎の品質に関する情報（ビットレート、再生停止情報（再生停止時間、回数、間隔等）、フレームレート、解像度）、クライアント端末２０に関する情報（利用端末（自端末）の種別を識別可能な情報、表示サイズ（表示面積））である。受信映像毎とは、他のクライアント端末２０（からの映像）ごとと同義である。例えば、Ａ、Ｂ、Ｃさんで会議を行っている場合、Ａさんのクライアント端末２０における受信映像毎とは、Ｂさん及びＣさんのそれぞれの映像ごとをいう。受信映像毎に表示サイズが収集されるのは、受信映像毎に表示サイズ（すなわち、他の参加者が表示される画面上のサイズ）が異なりうる場合を想定しているからである。例えば、Ａ、Ｂ、Ｃさんで会議を行っている場合、本実施の形態では、Ａさんのクライアント端末２０において、Ｂさんの表示サイズとＣさんの表示サイズが異なる状況も許容される。

【0031】

アップロードビットレート推定のために必要な情報とは、例えば、各ユーザ（各クライアント端末２０）のアップロード可用帯域及びダウンロード可用帯域である。

【0032】

制御サーバ１０のクライアントログ収集部１１は、クライアントログ送信部２１から転送されたクライアントログを受信する。なお、クライアントログが含む情報を制御サーバ１０側で収集可能であれば制御サーバ１０側で収集されてもよい。

【0033】

制御サーバ１０は、基本的に、クライアントログの受信に応じて、以下の処理を実行する。但し、以下の処理は、クライアントログの受信のたびに毎回実行されなくてもよい。

【0034】

制御サーバ１０のアップロードビットレート選択部１３は、式（１）に基づいて、転送データ量（送信元×送信先毎のビットレートの総和）を最小化させるように、送信元×送信先毎のアップロードビットレートを計算する。

【0035】

【数1】

但し、各記号の意味は以下の通りである。
Ｕ：参加ユーザ群
ＢＲ_ｉ，ｕ（ｔ）：時刻ｔにユーザｕが受信するユーザｉの映像のビットレート（ｉ（送信元）にとってはアップロードビットレート、ｕ（送信先）にとっては受信ビットレート）
Ｌ：選択可能な複数段階のビットレート群
なお、送信元×送信先毎のアップロードビットレートとは、例えば、参加者が５人であれば、５×４＝２０通りのビットレートをいう。なお、送信元×送信先毎のアップロードビットレートのうち、或る送信元及び送信先の組に対するアップロードビットレートは、当該送信元にとっては配信サーバ３０へアップロードするビットレートであり、当該送信先にとっては配信サーバ３０から配信される受信映像のビットレート（受信ビットレート）である。

【0036】

また、時刻ｔは、予め設定される、アップロードビットレートを変更するタイミングであり、その間隔は、例えば、クライアントログの収集周期と同じである。

【0037】

ここで、目標ＱｏＥを達成するため、アップロードビットレート選択部１３は、以下の制約１～３の３つの制約を満たすように式（１）の計算を行う。

【0038】

（制約１）
制約１は、以下の式（２）で表される。

【0039】

【数2】

但し、各記号の意味は以下の通りである。
Ｕ：参加ユーザ群
ＴａｒｇｅｔＱｏＥ：閾値として設定された目標ＱｏＥ
すなわち、制約１は、各ユーザの推定されたＱｏＥは目標ＱｏＥ（ＴａｒｇｅｔＱｏＥ）以上である必要があることである。

【0040】

（制約２）
制約２は、以下の式（３）で表される。

【0041】

【数3】

但し、各記号の意味は以下の通りである。
ＢＲ_ｉ，ｕ（ｔ）：時刻ｔにユーザｕが受信するユーザｉの映像のビットレート
ＵＬＢＷ_ｉ（ｔ）時刻ｔのユーザｉの推定アップロード可能帯域
α：推定誤差を加味した安全係数（０－１の値をとる）
すなわち、制約２は、各ユーザのアップロードビットレートの合計はアップロード可用帯域以下である必要があることである。但し、同一送信元で同一アップロードビットレートは重複して合算する必要はない（すなわち、同一送信元で同一アップロードビットレートの重複は除かれて合算される）。

【0042】

（制約３）
制約３は、以下の式（４）で表される。

【0043】

【数4】

但し、各記号の意味は以下の通りである。
ＢＲ_ｉ，ｕ（ｔ）：時刻ｔにユーザｕが受信するユーザｉの映像のビットレート
ＤＬＢＷ_ｕ（ｔ）：時刻ｔのユーザｕの推定ダウンロード可能帯域
α：推定誤差を加味した安全係数（０－１の値をとる）
すなわち、制約３は、各ユーザのダウンロードビットレート（＝受信ビットレート）の合計はダウンロード可用帯域以下の値である必要があることである。

【0044】

なお、式（２）～（４）は、式（１）が示す最適化問題に対する制約条件を示す。

【0045】

式（１）の計算において、アップロードビットレート選択部１３は、複数段階のビットレート群（Ｌ）の中からアップロードビットレートを選択することになる。ビットレート群（Ｌ）は予め与えられる。サービス提供者が最低でも担保すべきＱｏＥ（以下、「ＱｏＥ_{ｌｏｗｅｒ}」という。）から達成したい最大のＱｏＥ（以下、「ＱｏＥ_{ｕｐｐｅｒ}」という。）の間で選択可能ビットレート数（Ｎ）に合わせてＱｏＥが分散するようにビットレート群（Ｌ）が設定される。ＱｏＥ推定モデルを利用してＱｏＥを一定間隔にする場合のビットレートの計算式を式（５）に示す。

【0046】

【数5】

但し、各記号の意味は以下の通りである。
ＢＲ_ｎ：ｎ番目の推定ビットレート
ｎ：０－Ｎ－１の間の整数
Ｎ：選択可能ビットレート数
ＱｏＥ_{ｕｐｐｅｒ}：達成したい最大のＱｏＥ（ｅ．ｇ．，５）
ＱｏＥ_{ｌｏｗｅｒ}：最低でも担保すべきＱｏＥ（ｅ．ｇ．，３）
ＱｏＥ_{ｌｏｗｅｒ}＝３、ＱｏＥ_{ｕｐｐｅｒ}＝５、Ｎ＝９の場合の一定間隔のＱｏＥは、［３、３．２５、３．５、３．７５、４、４．２５、４．５、４．７５、５］であり、これらの各ＱｏＥに対してＢＲ_ｎが計算される。Ｎの値を大きくすることで柔軟な制御が可能となるが、アップロードビットレートの種類数が増加する可能性が高まり、クライアント端末２０の負荷が増加するリスクがある。

【0047】

式（２）の各ユーザのＱｏＥ_ｕは、他ユーザの送信映像から計算される。具体的には、ＱｏＥ_ｕは、以下の式（６）を利用して現在時刻を基準としてＴ１秒前からＴ２秒後までの区間に対して推定されたＱｏＥ値である。

【0048】

【数6】

但し、各記号の意味は以下の通りである。
ＤＳ_ｉ，ｕ（ｔ）：時刻ｔのユーザｕの画面に表示されているユーザｉの表示サイズ
ＢＲ_ｉ，ｕ（ｔ）：時刻ｔのユーザｕが受信したユーザｉの映像のビットレート
ＦＲ_ｉ，ｕ（ｔ）：時刻ｔのユーザｕが受信したユーザｉの映像のフレームレート
ＲＥＳ_ｉ，ｕ（ｔ）：時刻ｔのユーザｕが受信したユーザｉの映像の解像度
ＳＴＯＰ_ｉ，ｕ（ｔ）：時刻ｔのユーザｕが受信したユーザｉの映像の再生停止情報
また、ｆ_ＱｏＥは、ビットレート、解像度、フレームレート及び再生停止情報からＱｏＥを推定するためのＱｏＥ推定モデルであり、例えば、非特許文献３に開示されたものが利用される。

【0049】

また、式（６）の右辺の一番外側のｆ（）は、長時間のＱｏＥを推定するための式を示す。本実施の形態では、一定期間（例えば、Ｔ１＝３０秒，Ｔ２＝３０秒の場合は１分間）のＱｏＥ値を目標ＱｏＥに近づけるような制御を想定している。その際、非特許文献３と同様に、この期間内のｔごと（例えば１秒毎）にＱｏＥ値を計算して、それらを統合して一定期間のＱｏＥ値が推定される。ｔごと（例えば、１秒間）のＱｏＥ値は式（６）のｆ（）の中で計算される。その際に、各クライアント端末２０には複数の他の参加者の映像が表示されるため、ｆ_ＱｏＥによる推定値について表示サイズ（＝式（６）のＤＳ）による重み付き平均が計算される。その結果がｆ（）で統合される。

【0050】

式（６）の計算は、具体的には以下のように実行される。
（ｓｔｅｐ１）アップロードビットレート選択部１３は、式（６）のｆ（）の中身を利用して、Ｔ１秒前から現在時刻の区間の各ｔにおけるクライアントログからｔごとに各ｕのＱｏＥ値を計算する。
（ｓｔｅｐ２）アップロードビットレート選択部１３は、式（６）のｆ（）の中身を利用して、現在時刻からＴ２秒後の区間のｔごとに各ｕのＱｏＥ値を計算する。この際に、ビットレート（ＢＲ_ｉ，ｕ（ｔ））はＬの中から選択される。例えば、ｔの進行に応じて相対的に高いビットレートから低いビットレートへ下かるようにＢＲ_ｉ，ｕ（ｔ）の値が選択されてもよいし、相対的に低いビットレートから高いビットレートへ上があるようにＢＲ_ｉ，ｕ（ｔ）の値が選択されるようにしてもよい。その他の規則に基づいてＬの中からビットレートが選択されてもよい。また、フレームレート、解像度、表示サイズ（ＦＲ_ｉ，ｕ（ｔ）、ＲＥＳ_ｉ，ｕ（ｔ）、ＤＳ_ｉ，ｕ（ｔ））はクライアントログの最新値を利用し、再生停止情報（ＳＴＯＰ_ｉ，ｕ（ｔ））は、０とすることが考えられる。また、クライアントアプリによっては選択ビットレートに応じてフレームレートや解像度を決定する場合がある。そのような場合は、クライアントアプリで利用されているビットレートとフレームレート、解像度の対応式に応じて解像度及びフレームレートを計算してもよい。
（ｓｔｅｐ３）アップロードビットレート選択部１３は、ｓｔｅｐ１で計算したｔごとのＱｏＥ値と、ｓｔｅｐ２で計算したｔごとのＱｏＥ値とを式（６）のｆ（）でｕごとに統合して、各ｕについて一定期間（Ｔ１～Ｔ２）のＱｏＥ値であるＱｏＥ_ｕを計算（推定）する。

【0051】

なお、ｓｔｅｐ３において計算されたＱｏＥ_ｕが目標ＱｏＥを超えるという制約を満たし（式（２））、式（３）及び式（４）の制約も満たす範囲において式（１）を計算することで、アップロードビットレート選択部１３は、Ｌの中からＢＲ_ｉ，ｕ（ｔ）を選択する。

【0052】

この際、式（３）、式（４）におけるＵＬＢＷ_ｉ（ｔ）、ＤＬＢＷ_ｕ（ｔ）は、クライアントログ送信部２１からのクライアントログに含まれているアップロード可用帯域がＴ２秒間継続するものとする。すなわち、ＵＬＢＷ_ｉ（ｔ）、ＤＬＢＷ_ｕ（ｔ）には、最新のクライアントログの値が代入されればよい。なお、既存の帯域推定技術が利用されてＵＬＢＷ_ｉ（ｔ）、ＤＬＢＷ_ｕ（ｔ）が推定されてもよい。

【0053】

アップロードビットレート指示部１４は、アップロードビットレート選択部１３から受信した、送信元（ｉ）×送信先（ｕ）ごとのアップロードビットレート（ＢＲ_ｉ，ｕ（ｔ））を各ｉに係るクライアント端末２０に送信することで、当該アップロードビットレートでのエンコード（符号化）を各クライアント端末２０に指示する。この際、或る送信元端末ｉには、送信元（ｉ）×送信先（ｕ）ごとのアップロードビットレートのうち、当該ｉに係る全ての（つまり、１以上の）アップロードビットレートの値が送信される。

【0054】

クライアント端末２０のクライアントのアップロードビットレート制御部２２は、制御サーバ１０のアップロードビットレート指示部１４から受信した全てのアップロードビットレートを送信データ符号化部２３へ設定する。

【0055】

送信データ符号化部２３は、設定されたアップロードビットレートに基づいてメディアデータの符号化を行い、符号化されたメディアデータを配信サーバ３０へ送信（アップロード）する。

【0056】

配信サーバ３０は、各クライアント端末２０からアップロードされた１以上の段階のアップロードビットレートのメディアデータを当該クライアント端末２０以外のクライアント端末２０へ配信する。この際、配信サーバ３０は、式（１）によるＢＲ_ｉ，ｕ（ｔ）の計算結果（選択結果）を必ずしも知らなくてもよい。基本的にＳｉｍｕｌｃａｓｔでは配信サーバ３０がクライアント端末２０のダウンロード帯域に合わせて適切なレートを判断して配信するところ、本実施の形態ではＢＲ_ｉ，ｕ（ｔ）の計算時点でダウンロード帯域の情報が活用されているため、配信サーバ３０が選択するビットレートはＢＲ_ｉ，ｕ（ｔ）の計算結果に自ずと一致すると考えられるからである。

【0057】

又は、制御サーバ１０又はクライアント端末２０から配信サーバ３０に対してＢＲ_ｉ，ｕ（ｔ）の計算結果（選択結果）が送信されるようにしてもよい。

【0058】

上述したように、第１の形態によれば、目標ＱｏＥを達成する範囲において、データ転送量が最小となるように送信元及び送信先の組み合わせごとの映像のビットレートが選択される。したがって、映像の符号化に際して過剰なビットレートが選択される可能性を低減することができる。その結果、例えば、サービス提供事業者の設備にかかるコストを抑制することができる。

【0059】

次に、第２の実施の形態について説明する。第２の実施の形態では第１の実施の形態と異なる点について説明する。第２の実施の形態において特に言及されない点については、第１の実施の形態と同様でもよい。

【0060】

第２の実施の形態では、送信元端末のネットワークやクライアント負荷の都合から、アップロードビットレート数が所定数Ｒに制限されている状況が想定される。この場合、送信元端末毎に制限されたビットレート数（Ｒ）を決定する必要がある。

【0061】

第２の実施の形態では、式（１）の各送信元ｉのアップロードビットレートＢＲ_ｉ（ｔ）の数ｎ（ＢＲ_ｉ（ｔ））はＲ以下という制約が与えられる。但し、ＢＲ_ｉ（ｔ）は、任意の送信元のユーザｉから全ての送信先へのアップロードビットレートの種類（リスト）を意味する。また、ｎ（Ｘ）という表記は、Ｘの数を意味する。この制約により、送信元ｉごとにアップロードビットレート数をＲに抑え、各送信先ユーザｕはそれぞれの送信元ｉからの映像についてＲ個の中から１つのビットレートを選択するようにする。例えば、事前に設定されている選択可能なビットレート数がＮであれば、アップロードビットレート選択部１３は、式（１）の代わりに以下の式（７－１）に基づいて、転送データ量（送信元×送信先毎のビットレートの総和）を最小化させるように、送信元×送信先毎のアップロードビットレートを計算する。この際、式（２）～（６）の制約も有効である。

【0062】

【数7】

但し、α_{ｉ，ｕ，ｎ}は、送信元ユーザｉから送信先ユーザｕに対する映像についてｎ番目のビットレートを採用する場合に１となり、そうでない場合に０となる変数である。式（７－２）は、或るｉとｕの組に対して１つのｎのみが採用されること示す制約である。式（７－３）は、任意の送信元ユーザｉからのアップロードビットレート数がＲ以下であるという制約を示す。すなわち、α_ｉ，ｎは、いずれかのｕについてのα_{ｉ，ｕ，ｎ}が１であれば１となり、全てのｕについてのα_{ｉ，ｕ，ｎ}が０であれば０となる変数である。アップロードビットレート選択部１３が、式（２）～（６）の制約に加え、式（７－２）及び式（７－３）の制約を考慮して式（７－１）を計算ことで、各送信元ユーザｉからのアップロードビットレート数Ｒ以下に抑えつつ、送信元ユーザ×送信先ユーザの組み合わせごとのビットレートを決定することができる。なお、アップロードビットレート選択部１３は、α_{ｉ，ｕ，ｎ}＝１であるｎ番目のビットレートを（ｉ，ｕ）に対するＢＲ_ｉ，ｕ（ｔ）とする。

【0063】

なお、上記各実施の形態において、制御サーバ１０は、ビットレート選択装置の一例である。クライアント端末２０は、第１の端末及び第２の端末の一例である。アップロードビットレート選択部１３は、選択部の一例である。アップロードビットレート指示部１４は、指示部の一例である。配信サーバ３０は、配信装置の一例である。

【0064】

以上、本発明の実施の形態について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

【0065】

本出願は、２０２２年５月１１日に出願された国際特許出願第ＰＣＴ／ＪＰ２０２２／０１９９８５号に基づきその優先権を主張するものであり、同国際特許出願の全内容を参照することにより本願に援用する。

【符号の説明】

【0066】

１０ 制御サーバ
１１ クライアントログ収集部
１２ 目標ＱｏＥ入力部
１３ アップロードビットレート選択部
１４ アップロードビットレート指示部
２０ クライアント端末
２１ クライアントログ送信部
２２ アップロードビットレート制御部
２３ 送信データ符号化部
２４ 受信データ復号化部
３０ 配信サーバ
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
Ｂ バス

【図1】

【図2】

【図3】