知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B1)
(11)【特許番号】
(24)【登録日】2024-10-07
(45)【発行日】2024-10-16
(54)【発明の名称】配信装置、配信システム、および、配信方法
(51)【国際特許分類】
H04N 21/2385 20110101AFI20241008BHJP
H04N 7/18 20060101ALI20241008BHJP
H04N 23/60 20230101ALI20241008BHJP
【ＦＩ】
H04N21/2385
H04N7/18 U
H04N23/60 300
【請求項の数】
5
(21)【出願番号】P 2024121072
(22)【出願日】2024-07-26
【審査請求日】2024-07-26
【早期審査対象出願】
(73)【特許権者】
【識別番号】000153443
【氏名又は名称】株式会社 日立産業制御ソリューションズ
(74)【代理人】
【識別番号】110001807
【氏名又は名称】弁理士法人磯野国際特許商標事務所
(72)【発明者】
【氏名】太田 彩花
(72)【発明者】
【氏名】橋本 篤
【審査官】鈴木 隆夫
(56)【参考文献】
【文献】特開２０２３－１３９３３７（ＪＰ，Ａ）
【文献】特開２００７－３２５１０９（ＪＰ，Ａ）
【文献】米国特許出願公開第２００７／０１０７０２９（ＵＳ，Ａ１）
【文献】米国特許出願公開第２００５／０１４４２９６（ＵＳ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｎ ２１／００－２１／８５８
Ｈ０４Ｎ ７／１８
Ｈ０４Ｎ ２３／６０
(57)【特許請求の範囲】
【請求項1】
各映像ストリームデータを各領域で同時に表示する再生機に対して、前記映像ストリームデータを配信する配信装置であって、前記配信装置は、領域数を増加させる旨の要求を前記再生機から受け、既に表示中の領域については、ビットレートを変更せずに前記映像ストリームデータの配信を継続し、新たに表示する領域については、増加後の前記領域数に応じたビットレートでの前記映像ストリームデータの配信を開始することを特徴とする
配信装置。
【請求項2】
前記配信装置は、前記領域数を減少させる旨の要求を前記再生機から受け、今後は表示が不要になる領域については、前記映像ストリームデータの配信を終了することを特徴とする請求項１に記載の配信装置。
【請求項3】
請求項１または請求項２に記載の配信装置と、前記再生機とを有する配信システムであって、前記再生機は、各領域を表示状態か、非表示状態かに切り替え可能であり、
前記配信装置は、前記領域数を増加させる旨の要求を受け、既に存在するが前記非表示状態の領域については、増加後の前記領域数に応じたビットレートに切り替えることを特徴とする
配信システム。
【請求項4】
前記再生機は、各領域で表示する前記映像ストリームデータを切り替え可能であり、前記配信装置は、切り替え前の前記映像ストリームデータの配信を終了するとともに、現在の前記領域数に応じたビットレートでの切り替え後の前記映像ストリームデータの配信を開始することを特徴とする
請求項３に記載の配信システム。
【請求項5】
各映像ストリームデータを各領域で同時に表示する再生機に対して、前記映像ストリームデータを配信する配信装置による配信方法であって、前記配信装置は、領域数を増加させる旨の要求を前記再生機から受け、既に表示中の領域については、ビットレートを変更せずに前記映像ストリームデータの配信を継続し、新たに表示する領域については、増加後の前記領域数に応じたビットレートでの前記映像ストリームデータの配信を開始するステップを実行することを特徴とする
配信方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、配信装置、配信システム、および、配信方法に関する。
【背景技術】
【0002】
ネットワークカメラが撮影した映像をリアルタイムで配信する映像配信サービスが提供されている。表示装置の解像度の増大に伴い、１つのディスプレイを複数の領域に分割して、各領域に別々のネットワークカメラの撮影映像を同時に表示する形態もある。
例えば、特許文献１には、各ネットワークカメラの映像から生成されるデータである結合データを生成する結合データ生成部を備える映像配信装置が記載されている。
例えば、特許文献１には、各ネットワークカメラの映像から生成されるデータである結合データを生成する結合データ生成部を備える映像配信装置が記載されている。
【0003】
また、ネットワークカメラの高性能化に伴い、配信データのビットレートも増大している。そのため、ネットワークの許容帯域を超えた映像ストリームデータの配信要求があった場合、ビットレートを変更することで、ネットワークの許容帯域に収めることも重要となる。
そこで、特許文献２には、パケットの欠落率が一定の値を超えた場合には、同一グループ内の広角撮影映像ストリームデータ、またはズーム撮影映像ストリームデータのビットレートを低くする制御手段を備えるネットワークカメラが記載されている。
そこで、特許文献２には、パケットの欠落率が一定の値を超えた場合には、同一グループ内の広角撮影映像ストリームデータ、またはズーム撮影映像ストリームデータのビットレートを低くする制御手段を備えるネットワークカメラが記載されている。
【先行技術文献】
【特許文献】
【0004】
【文献】特開２０２３－１３９３３７号公報
【文献】特開２００７－３２５１０９号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
特許文献１のように複数のネットワークカメラからの映像を同一の表示装置に向けて配信する場合、映像ストリームデータの本数が増えると、通信量の増大が問題となる。その場合、特許文献２のように映像ストリームデータのビットレートを低くする制御を行うと、そのタイミングで再接続が必要となり、既に表示中のライブ映像は一度途切れてしまう。
一方、監視業務などの顧客運用上、既に表示中のライブ映像を途切れさせず、映像の表示は維持する用途も存在する。その場合、既に表示中の映像ストリームデータのビットレートを低くする制御は、実行できなくなってしまい、通信量の増大に対応できない。
一方、監視業務などの顧客運用上、既に表示中のライブ映像を途切れさせず、映像の表示は維持する用途も存在する。その場合、既に表示中の映像ストリームデータのビットレートを低くする制御は、実行できなくなってしまい、通信量の増大に対応できない。
【0006】
本発明はこのような事情を考慮してなされたものであり、既に表示中のライブ映像表示を途切れさせず、通信量を低減させることを、主な課題とする。
【課題を解決するための手段】
【0007】
上記課題を解決するために、本発明の配信装置は、以下の特徴を有する。
本発明は、各映像ストリームデータを各領域で同時に表示する再生機に対して、前記映像ストリームデータを配信する配信装置であって、
前記配信装置が、領域数を増加させる旨の要求を前記再生機から受け、既に表示中の領域については、ビットレートを変更せずに前記映像ストリームデータの配信を継続し、新たに表示する領域については、増加後の前記領域数に応じたビットレートでの前記映像ストリームデータの配信を開始することを特徴とする。
その他の特徴は、後記する。
本発明は、各映像ストリームデータを各領域で同時に表示する再生機に対して、前記映像ストリームデータを配信する配信装置であって、
前記配信装置が、領域数を増加させる旨の要求を前記再生機から受け、既に表示中の領域については、ビットレートを変更せずに前記映像ストリームデータの配信を継続し、新たに表示する領域については、増加後の前記領域数に応じたビットレートでの前記映像ストリームデータの配信を開始することを特徴とする。
その他の特徴は、後記する。
【発明の効果】
【0008】
本発明によれば、既に表示中のライブ映像表示を途切れさせず、通信量を低減させることができる。
【図面の簡単な説明】
【0009】
【図1】本実施形態に関する配信システムの構成図である。
【図2】本実施形態に関する設定格納部の一例を示すテーブルである。
【図3】本実施形態に関する配信システムの各装置のハードウェア構成図である。
【図4】本実施形態に関する配信システムの動作を示すシーケンス図である。
【図5】本実施形態に関する比較例における分割数の増加処理を示す説明図である。
【図6】本実施形態に関する本実施形態における分割数の増減処理を示す説明図である。
【図7】本実施形態に関する４分割の画面図である。
【図8】本実施形態に関する９分割の画面図である。
【図9】本実施形態に関するカメラ変更指定時の画面図である。
【発明を実施するための形態】
【0010】
以下、本発明の一実施形態を図面を用いて説明する。
【0011】
図１は、配信システム１００の構成図である。
配信システム１００は、カメラ１と、配信装置２と、再生機３とが、ネットワークで接続されて構成される。
カメラ１は、撮影した映像を映像ストリームデータとして、配信装置２に送信する。配信装置２は、複数台のカメラ１から受信した映像ストリームデータを、再生機３に配信する。
再生機３は、表示制御部３１と、操作部３２とを有しており、ユーザ９により操作され、各映像ストリームデータを各領域で同時に表示する。配信装置２は、再生機３に対して、映像ストリームデータを配信する。
配信装置２は、映像受信部２１と、映像制御部２２と、映像配信部２３と、設定部２４と、設定格納部２５とを有する。
配信システム１００は、カメラ１と、配信装置２と、再生機３とが、ネットワークで接続されて構成される。
カメラ１は、撮影した映像を映像ストリームデータとして、配信装置２に送信する。配信装置２は、複数台のカメラ１から受信した映像ストリームデータを、再生機３に配信する。
再生機３は、表示制御部３１と、操作部３２とを有しており、ユーザ９により操作され、各映像ストリームデータを各領域で同時に表示する。配信装置２は、再生機３に対して、映像ストリームデータを配信する。
配信装置２は、映像受信部２１と、映像制御部２２と、映像配信部２３と、設定部２４と、設定格納部２５とを有する。
【0012】
再生機３は、操作部３２を介してユーザ９から映像再生の開始操作を受けると、その開始操作から作成した映像配信要求を、映像制御部２２に送信する。映像配信要求には、現在の（ここでは初回の）画面分割数情報が含まれる。画面分割数（以下「分割数」と略すこともある）とは、再生機３のディスプレイを複数の領域（以下、「窓」）に分割し、各窓にて同時に表示されるライブ映像の数である。１つの窓に対して、１つの映像ストリームデータが表示される。映像制御部２２は、受信した映像配信要求の画面分割数情報を設定部２４に通知する。
【0013】
図２は、設定格納部２５の一例を示すテーブルである。
設定部２４は、設定格納部２５を参照して、通知された画面分割数情報および再生機３の推奨解像度の組み合わせに対応する、映像ストリームデータのビットレート（BPS：Bit Per Second）を求めて、映像制御部２２に返答する。そのため、設定格納部２５には、推奨解像度および分割数の組み合わせごとに、カメラ１に設定するビットレート[Mbps]と、再生機３に設定するレイアウト情報とが事前に登録されている。
例えば、分割数＝４でディスプレイサイズが中程度の再生機３では、フルHD（1920×1080）が推奨解像度となり、１つの映像ストリームデータあたりのビットレート＝2[Mbps]である。つまり、分割数＝４なので４窓のビットレートの合計は2×4=8[Mbps]となる。
一方、分割数＝４でディスプレイサイズが大きい再生機３では、４Ｋ（3840×2160）が推奨解像度となり、１窓あたりのビットレート＝8[Mbps]である。つまり、４窓のビットレートの合計は8×4=32[Mbps]となる。
設定部２４は、設定格納部２５を参照して、通知された画面分割数情報および再生機３の推奨解像度の組み合わせに対応する、映像ストリームデータのビットレート（BPS：Bit Per Second）を求めて、映像制御部２２に返答する。そのため、設定格納部２５には、推奨解像度および分割数の組み合わせごとに、カメラ１に設定するビットレート[Mbps]と、再生機３に設定するレイアウト情報とが事前に登録されている。
例えば、分割数＝４でディスプレイサイズが中程度の再生機３では、フルHD（1920×1080）が推奨解像度となり、１つの映像ストリームデータあたりのビットレート＝2[Mbps]である。つまり、分割数＝４なので４窓のビットレートの合計は2×4=8[Mbps]となる。
一方、分割数＝４でディスプレイサイズが大きい再生機３では、４Ｋ（3840×2160）が推奨解像度となり、１窓あたりのビットレート＝8[Mbps]である。つまり、４窓のビットレートの合計は8×4=32[Mbps]となる。
【0014】
また、設定格納部２５のレイアウト情報とは、例えば、分割数＝９の場合、縦窓３つ×横窓３つを格子状に画面配置する旨の情報である。
このレイアウト情報は、設定部２４が設定格納部２５から読み込んだ後、設定部２４から映像配信部２３経由で、表示制御部３１に送信される。表示制御部３１は、受信したレイアウト情報に従って、映像配信部２３からの映像ストリームデータを画面内の各窓に配置する。
このレイアウト情報は、設定部２４が設定格納部２５から読み込んだ後、設定部２４から映像配信部２３経由で、表示制御部３１に送信される。表示制御部３１は、受信したレイアウト情報に従って、映像配信部２３からの映像ストリームデータを画面内の各窓に配置する。
【0015】
図１に戻り、映像制御部２２は、設定部２４から通知されたビットレートを指定した映像送信命令を、各窓で再生する映像を撮影する各カメラ１に送信する。
各カメラ１は、映像送信命令のビットレートに従い、撮影映像をエンコードした映像ストリームデータを映像受信部２１に送信する。映像受信部２１は、受信した各映像ストリームデータを映像配信部２３に通知する。
映像配信部２３は、HLS（HTTP Live Streaming）などのストリーミング配信の規格に従い、通知された各映像ストリームデータを再生機３の表示制御部３１に向けて配信する。これにより、表示制御部３１は、分割数に従って分割された各窓で、配信された各映像ストリームデータを再生する。
各カメラ１は、映像送信命令のビットレートに従い、撮影映像をエンコードした映像ストリームデータを映像受信部２１に送信する。映像受信部２１は、受信した各映像ストリームデータを映像配信部２３に通知する。
映像配信部２３は、HLS（HTTP Live Streaming）などのストリーミング配信の規格に従い、通知された各映像ストリームデータを再生機３の表示制御部３１に向けて配信する。これにより、表示制御部３１は、分割数に従って分割された各窓で、配信された各映像ストリームデータを再生する。
【0016】
ここで、再生機３は、操作部３２を介してユーザ９から画面分割数の変更操作を受けると、その変更操作から作成した分割変更要求を、設定部２４に送信する。分割変更要求には、新たな画面分割数情報が含まれる。設定部２４は、過去に対応した画面分割数情報の履歴を保持し、新たな画面分割数情報と比較することで、以下のように各窓を分類する。
（ａ）配信中である「既存窓」のうちの、分割変更要求を受けても今後も表示し続ける「継続窓」。
（ｂ）以前は表示していないが、分割変更要求を受けて新たに表示を開始する「増加窓」。
（ｃ）既存窓のうちの、分割変更要求を受けて今後は表示が不要になる「減少窓」。
一方、初回の画面分割数に応じて形成される窓を「初回窓」とする。
（ａ）配信中である「既存窓」のうちの、分割変更要求を受けても今後も表示し続ける「継続窓」。
（ｂ）以前は表示していないが、分割変更要求を受けて新たに表示を開始する「増加窓」。
（ｃ）既存窓のうちの、分割変更要求を受けて今後は表示が不要になる「減少窓」。
一方、初回の画面分割数に応じて形成される窓を「初回窓」とする。
【0017】
そして、配信装置２は、領域数（画面分割数）を増加させる旨の領域数変更要求（分割変更要求）を再生機３から受け、（ａ）既に表示中の領域（継続窓）については、ビットレートを変更せずに映像ストリームデータの配信を継続する。また、配信装置２は、（ｂ）新たに表示する領域（増加窓）については、増加後の領域数に応じたビットレートでの映像ストリームデータの配信を開始する。
一方、配信装置２は、領域数を減少させる旨の領域数変更要求を再生機３から受け、（ｃ）今後は表示が不要になる領域（減少窓）については、映像ストリームデータの配信を終了する。
一方、配信装置２は、領域数を減少させる旨の領域数変更要求を再生機３から受け、（ｃ）今後は表示が不要になる領域（減少窓）については、映像ストリームデータの配信を終了する。
【0018】
具体的には、設定部２４は、以下のように、再生中の映像ストリームデータと、再生前の映像ストリームデータとで、ビットレートの設定を使い分ける。
（ａ）設定部２４は、継続窓のビットレートを変更せず、映像再生を中断させない。
（ｂ）設定部２４は、新たな画面分割数をもとに、増加窓のビットレートを新たに計算する。そのため、設定部２４は、推奨解像度および新たな画面分割数の組み合わせに適合する増加窓のビットレートを設定格納部２５から取得する。そして、設定部２４は、その増加窓のビットレートを指定した映像送信命令を、映像制御部２２を介して該当する各カメラ１に送信する。
（ｃ）設定部２４は、減少窓への映像停止命令を、映像制御部２２を介して該当する各カメラ１に送信する。
（ａ）設定部２４は、継続窓のビットレートを変更せず、映像再生を中断させない。
（ｂ）設定部２４は、新たな画面分割数をもとに、増加窓のビットレートを新たに計算する。そのため、設定部２４は、推奨解像度および新たな画面分割数の組み合わせに適合する増加窓のビットレートを設定格納部２５から取得する。そして、設定部２４は、その増加窓のビットレートを指定した映像送信命令を、映像制御部２２を介して該当する各カメラ１に送信する。
（ｃ）設定部２４は、減少窓への映像停止命令を、映像制御部２２を介して該当する各カメラ１に送信する。
【0019】
なお、設定部２４は、（ｂ）の増加窓について、推奨解像度を前提とし最低限のビットレートは維持する。これにより、ビットレートを下げすぎた場合に起こりうる映像のカクツキや、再生機の推奨解像度以下になることを防止する。
【0020】
そして、映像配信部２３は、以下のように、分割変更要求に対応した映像ストリームデータを配信する。
（ａ）継続窓の映像ストリームデータは、ビットレートを変更せずに途切れることなく配信し続ける。
（ｂ）増加窓の映像ストリームデータは、新たな画面分割数のビットレートに従って（一般的には継続窓よりもビットレートを下げて）、配信を開始する。
（ｃ）減少窓の映像ストリームデータは、配信を切断する。
これにより、再生機３の表示制御部３１は、分割変更要求が適用された新たな画面分割数情報の各窓を、表示画面に反映できる。
（ａ）継続窓の映像ストリームデータは、ビットレートを変更せずに途切れることなく配信し続ける。
（ｂ）増加窓の映像ストリームデータは、新たな画面分割数のビットレートに従って（一般的には継続窓よりもビットレートを下げて）、配信を開始する。
（ｃ）減少窓の映像ストリームデータは、配信を切断する。
これにより、再生機３の表示制御部３１は、分割変更要求が適用された新たな画面分割数情報の各窓を、表示画面に反映できる。
【0021】
図３は、配信システム１００の各装置（カメラ１、配信装置２、および、再生機３）のハードウェア構成図である。
配信システム１００の各装置は、ＣＰＵ９０１と、ＲＡＭ９０２と、ＲＯＭ９０３と、ＨＤＤ９０４と、通信Ｉ／Ｆ９０５と、入出力Ｉ／Ｆ９０６と、メディアＩ／Ｆ９０７とを有するコンピュータ９００として構成される。
通信Ｉ／Ｆ９０５は、外部の通信装置９１５と接続される。入出力Ｉ／Ｆ９０６は、入出力装置９１６と接続される。メディアＩ／Ｆ９０７は、記録媒体９１７からデータを読み書きする。さらに、ＣＰＵ９０１は、ＲＡＭ９０２に読み込んだプログラム（アプリケーションや、その略のアプリとも呼ばれる）を実行することにより、各処理部を改善制御する。そして、このプログラムは、通信回線を介して配布したり、ＣＤ－ＲＯＭ等の記録媒体９１７に記録して配布したりすることも可能である。
配信システム１００の各装置は、ＣＰＵ９０１と、ＲＡＭ９０２と、ＲＯＭ９０３と、ＨＤＤ９０４と、通信Ｉ／Ｆ９０５と、入出力Ｉ／Ｆ９０６と、メディアＩ／Ｆ９０７とを有するコンピュータ９００として構成される。
通信Ｉ／Ｆ９０５は、外部の通信装置９１５と接続される。入出力Ｉ／Ｆ９０６は、入出力装置９１６と接続される。メディアＩ／Ｆ９０７は、記録媒体９１７からデータを読み書きする。さらに、ＣＰＵ９０１は、ＲＡＭ９０２に読み込んだプログラム（アプリケーションや、その略のアプリとも呼ばれる）を実行することにより、各処理部を改善制御する。そして、このプログラムは、通信回線を介して配布したり、ＣＤ－ＲＯＭ等の記録媒体９１７に記録して配布したりすることも可能である。
【0022】
図４は、配信システム１００の動作を示すシーケンス図である。
まず、初回の再生処理（Ｓ１１０）について、説明する。
再生機３は、初回の画面分割数を指定した映像配信要求を配信装置２に送信する（Ｓ１１１）。配信装置２は、初回窓のBL（ビットレート）計算する（Ｓ１１２）。配信装置２は、そのビットレートに従って初回窓に表示する映像ストリームデータの配信を再生機３に向けて開始する（Ｓ１１３）。再生機３は、Ｓ１１３の配信を初回窓に再生する（Ｓ１１４）。
まず、初回の再生処理（Ｓ１１０）について、説明する。
再生機３は、初回の画面分割数を指定した映像配信要求を配信装置２に送信する（Ｓ１１１）。配信装置２は、初回窓のBL（ビットレート）計算する（Ｓ１１２）。配信装置２は、そのビットレートに従って初回窓に表示する映像ストリームデータの配信を再生機３に向けて開始する（Ｓ１１３）。再生機３は、Ｓ１１３の配信を初回窓に再生する（Ｓ１１４）。
【0023】
次に、分割変更要求により分割数が増加する場合の再生処理（Ｓ１２０）について、説明する。
再生機３は、ユーザ９からの操作により、画面分割数の増加の指定を受け付けると（Ｓ１２１）、新たな画面分割数を分割変更要求として配信装置２に通知する。配信装置２は、「新たな画面分割数＝継続窓数＋増加窓数」となるように、全ての既存窓を継続窓としつつ新たに増加窓を形成する。そして、配信装置２は、新たな画面分割数を基準に、増加窓のBLを計算する（Ｓ１２２）。
配信装置２は、継続窓の配信を継続しつつ、Ｓ１２２で決めたBLにて増加窓の配信を開始する（Ｓ１２３）。再生機３は、Ｓ１２３の配信を受け、各窓に再生する（Ｓ１２４）。
再生機３は、ユーザ９からの操作により、画面分割数の増加の指定を受け付けると（Ｓ１２１）、新たな画面分割数を分割変更要求として配信装置２に通知する。配信装置２は、「新たな画面分割数＝継続窓数＋増加窓数」となるように、全ての既存窓を継続窓としつつ新たに増加窓を形成する。そして、配信装置２は、新たな画面分割数を基準に、増加窓のBLを計算する（Ｓ１２２）。
配信装置２は、継続窓の配信を継続しつつ、Ｓ１２２で決めたBLにて増加窓の配信を開始する（Ｓ１２３）。再生機３は、Ｓ１２３の配信を受け、各窓に再生する（Ｓ１２４）。
【0024】
さらに、分割変更要求により分割数が減少する場合の再生処理（Ｓ１３０）について、説明する。
再生機３は、ユーザ９からの操作により、画面分割数の減少の指定を受け付けると（Ｓ１３１）、新たな画面分割数を分割変更要求として配信装置２に通知する。配信装置２は、「新たな画面分割数＝継続窓数」となるように、各既存窓を継続窓か減少窓かに分類する。
そして、配信装置２は、減少窓を切断（減少窓のBL=0）しつつ（Ｓ１３２）、継続窓の配信を継続する（Ｓ１３３）。再生機３は、Ｓ１３３の配信を受け、継続窓に再生する（Ｓ１３４）。
再生機３は、ユーザ９からの操作により、画面分割数の減少の指定を受け付けると（Ｓ１３１）、新たな画面分割数を分割変更要求として配信装置２に通知する。配信装置２は、「新たな画面分割数＝継続窓数」となるように、各既存窓を継続窓か減少窓かに分類する。
そして、配信装置２は、減少窓を切断（減少窓のBL=0）しつつ（Ｓ１３２）、継続窓の配信を継続する（Ｓ１３３）。再生機３は、Ｓ１３３の配信を受け、継続窓に再生する（Ｓ１３４）。
【0025】
また、カメラ変更要求により既存窓で撮影する映像ストリームデータの情報源であるカメラ１を変更する場合の再生処理（Ｓ１４０）について、説明する。
再生機３は、ユーザ９からの操作により、指定された既存窓（指定窓）のカメラ１を変更する指定を受け付けると（Ｓ１４１）、その旨をカメラ変更要求として配信装置２に通知する。配信装置２は、現在の画面分割数を基準に、指定窓のBLを計算する（Ｓ１４２）。
配信装置２は、指定窓以外の既存窓の配信を継続しつつ、Ｓ１４２で決めたBLにて指定窓の配信を開始する（Ｓ１４３）。再生機３は、Ｓ１４３の配信を受け、各窓に再生する（Ｓ１４４）。
再生機３は、ユーザ９からの操作により、指定された既存窓（指定窓）のカメラ１を変更する指定を受け付けると（Ｓ１４１）、その旨をカメラ変更要求として配信装置２に通知する。配信装置２は、現在の画面分割数を基準に、指定窓のBLを計算する（Ｓ１４２）。
配信装置２は、指定窓以外の既存窓の配信を継続しつつ、Ｓ１４２で決めたBLにて指定窓の配信を開始する（Ｓ１４３）。再生機３は、Ｓ１４３の配信を受け、各窓に再生する（Ｓ１４４）。
【0026】
図５は、比較例における分割数の増加処理を示す説明図である。
時刻t11の初期状態では、４つの窓F1～F4が、それぞれBL=5[Mbps]で配信されており、合計の通信量は20[Mbps]である。
時刻t11の次の時刻t12では、分割数を４つから９つに増加させる分割変更要求を受け、比較例の配信装置は、新たに５つの窓F5～F9が、それぞれBL=5[Mbps]で配信を開始し、合計の通信量は45[Mbps]である。しかし、45[Mbps]では１人あたりのネットワークの許容帯域（例えば40[Mbps]）を超過している。
時刻t12の次の時刻t13では、分割数を９つに保ったまま、比較例の配信装置は、各窓F1～F9のBLを5[Mbps]から2[Mbps]に減らすことで、合計の通信量は18[Mbps]である。18[Mbps]は、１人あたりのネットワークの許容帯域内である。しかし、各窓F1～F9のBL変更に伴い、既に表示中のライブ映像表示が途切れてしまい、監視業務に支障をきたす。
時刻t11の初期状態では、４つの窓F1～F4が、それぞれBL=5[Mbps]で配信されており、合計の通信量は20[Mbps]である。
時刻t11の次の時刻t12では、分割数を４つから９つに増加させる分割変更要求を受け、比較例の配信装置は、新たに５つの窓F5～F9が、それぞれBL=5[Mbps]で配信を開始し、合計の通信量は45[Mbps]である。しかし、45[Mbps]では１人あたりのネットワークの許容帯域（例えば40[Mbps]）を超過している。
時刻t12の次の時刻t13では、分割数を９つに保ったまま、比較例の配信装置は、各窓F1～F9のBLを5[Mbps]から2[Mbps]に減らすことで、合計の通信量は18[Mbps]である。18[Mbps]は、１人あたりのネットワークの許容帯域内である。しかし、各窓F1～F9のBL変更に伴い、既に表示中のライブ映像表示が途切れてしまい、監視業務に支障をきたす。
【0027】
図６は、本実施形態における分割数の増減処理を示す説明図である。
時刻t21の初期状態では、４つの窓F1～F4が、それぞれBL=5[Mbps]で配信されており、合計の通信量は20[Mbps]である。
時刻t21の次の時刻t22では、分割数を４つから９つに増加させる分割変更要求を受け（図４ではＳ１２１）、配信装置２は、新たに５つの窓F5～F9が配信を開始する。一方、図５の時刻t12との違いとして、配信装置２は、新たな窓F5～F9のBLを、新たな分割数＝９つを基準として再計算している点である。これにより、合計の通信量は20+10=30[Mbps]となり、１人あたりのネットワークの許容帯域（例えば40[Mbps]）内である。
時刻t22の次の時刻t23では、分割数を９つから４つに減少させる分割変更要求を受け（図４ではＳ１３１）、配信装置２は、先頭側の窓F1～F4を残しつつ、末尾側の５つの窓F5～F9を減らすことで、合計の通信量は20[Mbps]である。配信装置２は、各窓F5～F9の映像ストリームデータの配信を切断する。再生機３は、各窓F5～F9を非表示にし、残りの窓F1～F4の表示をリサイズする。
時刻t21の初期状態では、４つの窓F1～F4が、それぞれBL=5[Mbps]で配信されており、合計の通信量は20[Mbps]である。
時刻t21の次の時刻t22では、分割数を４つから９つに増加させる分割変更要求を受け（図４ではＳ１２１）、配信装置２は、新たに５つの窓F5～F9が配信を開始する。一方、図５の時刻t12との違いとして、配信装置２は、新たな窓F5～F9のBLを、新たな分割数＝９つを基準として再計算している点である。これにより、合計の通信量は20+10=30[Mbps]となり、１人あたりのネットワークの許容帯域（例えば40[Mbps]）内である。
時刻t22の次の時刻t23では、分割数を９つから４つに減少させる分割変更要求を受け（図４ではＳ１３１）、配信装置２は、先頭側の窓F1～F4を残しつつ、末尾側の５つの窓F5～F9を減らすことで、合計の通信量は20[Mbps]である。配信装置２は、各窓F5～F9の映像ストリームデータの配信を切断する。再生機３は、各窓F5～F9を非表示にし、残りの窓F1～F4の表示をリサイズする。
【0028】
図７は、４分割の画面図である。
図７の画面図は、例えば、再生機３のブラウザ上の画面であり、ブラウザの操作部（URL入力欄、戻るボタン、ページリロードボタン）は図示を省略している。４つの窓F1～F4は、例えば、ブラウザ内の表示領域の一部を示す「フレーム」として実装される。
４つの窓F1～F4には、それぞれ別々のカメラ１の撮影画像が表示されている。そのため、操作部３２は、画面分割数＝４（縦２窓×横２窓）のラジオボタンがクリックされると、画面分割数＝４の映像配信要求を配信装置２に送信する（Ｓ１１１）。
なお、どの窓にどのカメラ１の撮影画像を表示するかの指定は、操作部３２が窓ごとにユーザ９に選択させる。そして、映像配信要求には、選択された窓ごとのカメラ１の指定情報も含まれる。
図７の画面図は、例えば、再生機３のブラウザ上の画面であり、ブラウザの操作部（URL入力欄、戻るボタン、ページリロードボタン）は図示を省略している。４つの窓F1～F4は、例えば、ブラウザ内の表示領域の一部を示す「フレーム」として実装される。
４つの窓F1～F4には、それぞれ別々のカメラ１の撮影画像が表示されている。そのため、操作部３２は、画面分割数＝４（縦２窓×横２窓）のラジオボタンがクリックされると、画面分割数＝４の映像配信要求を配信装置２に送信する（Ｓ１１１）。
なお、どの窓にどのカメラ１の撮影画像を表示するかの指定は、操作部３２が窓ごとにユーザ９に選択させる。そして、映像配信要求には、選択された窓ごとのカメラ１の指定情報も含まれる。
【0029】
図８は、９分割の画面図である。
操作部３２は、図７の状態から画面分割数＝９（縦３窓×横３窓）のラジオボタンがクリックされると、画面分割数＝９の映像配信要求を配信装置２に送信する（Ｓ１２１）。配信装置２は、BLを変更しない窓F1～F4の配信を継続しつつ、新たな窓F5～F9の配信を開始する（Ｓ１２３）。
表示制御部３１は、画面分割数＝９の選択に応じて、窓F1～F4を図７の状態から縮小し、その他の新たな窓F5～F9と同じサイズにする。これにより、表示制御部３１は、ブラウザのページリロードの操作なく分割数の増加が可能なため、ページリロードに伴う再接続の一時切断を発生させずに、窓F1～F4の映像表示を継続できる。
操作部３２は、図７の状態から画面分割数＝９（縦３窓×横３窓）のラジオボタンがクリックされると、画面分割数＝９の映像配信要求を配信装置２に送信する（Ｓ１２１）。配信装置２は、BLを変更しない窓F1～F4の配信を継続しつつ、新たな窓F5～F9の配信を開始する（Ｓ１２３）。
表示制御部３１は、画面分割数＝９の選択に応じて、窓F1～F4を図７の状態から縮小し、その他の新たな窓F5～F9と同じサイズにする。これにより、表示制御部３１は、ブラウザのページリロードの操作なく分割数の増加が可能なため、ページリロードに伴う再接続の一時切断を発生させずに、窓F1～F4の映像表示を継続できる。
【0030】
また、図８の状態から画面分割数＝４（縦２窓×横２窓）のラジオボタンがクリックされると、操作部３２は、分割数を９つから４つに減少させる分割変更要求を配信装置２に送信する（Ｓ１３１）。これにより、表示制御部３１は、窓F5～F9を非表示とし、窓F1～F4を図８の状態から拡大することで、再び図７のレイアウトに戻す。
【0031】
図９は、カメラ変更指定時の画面図である。
操作部３２は、図７の状態から窓F4のカメラ１を変更する指定を、窓F4のダブルクリックにより受け付けると、その窓F4に適用するカメラ１の選択欄（第１カメラ～第４カメラ）を表示する。カメラ１の選択欄の初期値として、窓F4で現在配信中の第２カメラがラジオボタンにより選択状態となっている。
操作部３２は、図７の状態から窓F4のカメラ１を変更する指定を、窓F4のダブルクリックにより受け付けると、その窓F4に適用するカメラ１の選択欄（第１カメラ～第４カメラ）を表示する。カメラ１の選択欄の初期値として、窓F4で現在配信中の第２カメラがラジオボタンにより選択状態となっている。
【0032】
図１０は、図９の状態からカメラ変更指定後の画面図である。
操作部３２は、図９の状態から第４カメラのラジオボタンがユーザ９によりクリックされると、窓F4のカメラ１を第２カメラから第４カメラに変更する旨のカメラ変更要求を配信装置２に通知する（Ｓ１４１）。配信装置２は、第２カメラの配信を停止する映像停止命令と、第４カメラの配信を開始する映像送信命令とをそれぞれのカメラ１に発行する。これにより、表示制御部３１は、第４カメラの映像ストリームデータを窓F4に表示する（Ｓ１４４）。
このように、再生機３は、各領域で表示する映像ストリームデータを切り替え可能である。そして、配信装置２は、切り替え前の映像ストリームデータの配信を終了するとともに、現在の領域数に応じたビットレートでの切り替え後の映像ストリームデータの配信を開始する。
操作部３２は、図９の状態から第４カメラのラジオボタンがユーザ９によりクリックされると、窓F4のカメラ１を第２カメラから第４カメラに変更する旨のカメラ変更要求を配信装置２に通知する（Ｓ１４１）。配信装置２は、第２カメラの配信を停止する映像停止命令と、第４カメラの配信を開始する映像送信命令とをそれぞれのカメラ１に発行する。これにより、表示制御部３１は、第４カメラの映像ストリームデータを窓F4に表示する（Ｓ１４４）。
このように、再生機３は、各領域で表示する映像ストリームデータを切り替え可能である。そして、配信装置２は、切り替え前の映像ストリームデータの配信を終了するとともに、現在の領域数に応じたビットレートでの切り替え後の映像ストリームデータの配信を開始する。
【0033】
さらに、表示制御部３１は、図７～図１０の各画面表示に対して、窓のリサイズ、窓の表示、窓の非表示、窓の表示位置の変更などの各種のレイアウト変更の操作を操作部３２から受け付けると、そのレイアウト変更を画面表示に反映してもよい。
例えば、再生機３は、各領域（各窓）を表示状態か、非表示状態かに切り替え可能である。そして、配信装置２は、領域数を増加させる旨の領域数変更要求を受け、既に存在するが非表示状態の領域については、増加後の領域数に応じたビットレートに切り替えてもよい。これにより、非表示状態の領域については、ライブ映像表示を途切れさせてビットレートを切り替えても、ユーザ９は気づかない。
例えば、再生機３は、各領域（各窓）を表示状態か、非表示状態かに切り替え可能である。そして、配信装置２は、領域数を増加させる旨の領域数変更要求を受け、既に存在するが非表示状態の領域については、増加後の領域数に応じたビットレートに切り替えてもよい。これにより、非表示状態の領域については、ライブ映像表示を途切れさせてビットレートを切り替えても、ユーザ９は気づかない。
【0034】
以上説明した本実施形態の配信装置２は、画面分割数が増加する際、既に表示中のライブ映像のビットレートは変更せずに、新たに表示するライブ映像の画面分割数に合わせたビットレートとする。これにより、再生機３は、既に表示中のライブ映像表示を途切れさせず、通信量を低減させることができる。
【0035】
さらに、本発明は上述した各実施形態に限られるものではなく、特許請求の範囲に記載した本発明の要旨を逸脱しない限りにおいて、その他種々の応用例、変形例を取り得ることは勿論である。例えば、上述した各実施形態は本発明を分かりやすく説明するために配信システム１００の構成を詳細かつ具体的に説明したものであり、必ずしも説明した全ての構成要素を備えるものに限定されない。また、ある実施形態の構成の一部を他の実施形態の構成要素に置き換えることが可能である。また、ある実施形態の構成に他の実施形態の構成要素を加えることも可能である。また、各実施形態の構成の一部について、他の構成要素の追加または置換、削除をすることも可能である。
【0036】
また、上記の各構成、機能、処理部等は、それらの一部または全部を、例えば集積回路で設計するなどによりハードウェアで実現してもよい。ハードウェアとして、ＦＰＧＡ（Field Programmable Gate Array）やＡＳＩＣ（Application Specific Integrated Circuit）などの広義のプロセッサデバイスを用いてもよい。
また、上述した実施形態にかかる配信システム１００の各構成要素は、それぞれのハードウェアがネットワークを介して互いに情報を送受信できるならば、いずれのハードウェアに実装されてもよい。また、ある処理部により実行される処理が、１つのハードウェアにより実現されてもよいし、複数のハードウェアによる分散処理により実現されてもよい。
また、上述した実施形態にかかる配信システム１００の各構成要素は、それぞれのハードウェアがネットワークを介して互いに情報を送受信できるならば、いずれのハードウェアに実装されてもよい。また、ある処理部により実行される処理が、１つのハードウェアにより実現されてもよいし、複数のハードウェアによる分散処理により実現されてもよい。
【符号の説明】
【0037】
１ カメラ
２ 配信装置
３ 再生機
１００ 配信システム
２ 配信装置
３ 再生機
１００ 配信システム
【要約】
【課題】既に表示中のライブ映像表示を途切れさせず、通信量を低減させること。
【解決手段】配信装置２は、各映像ストリームデータを各領域で同時に表示する再生機３に対して、映像ストリームデータを配信する。配信装置２は、領域数を増加させる旨の領域数変更要求を再生機３から受け、既に表示中の領域については、ビットレートを変更せずに映像ストリームデータの配信を継続し、新たに表示する領域については、増加後の領域数に応じたビットレートでの映像ストリームデータの配信を開始する。配信装置２は、領域数を減少させる旨の領域数変更要求を再生機３から受け、今後は表示が不要になる領域については、映像ストリームデータの配信を終了する。
【選択図】 図１
【解決手段】配信装置２は、各映像ストリームデータを各領域で同時に表示する再生機３に対して、映像ストリームデータを配信する。配信装置２は、領域数を増加させる旨の領域数変更要求を再生機３から受け、既に表示中の領域については、ビットレートを変更せずに映像ストリームデータの配信を継続し、新たに表示する領域については、増加後の領域数に応じたビットレートでの映像ストリームデータの配信を開始する。配信装置２は、領域数を減少させる旨の領域数変更要求を再生機３から受け、今後は表示が不要になる領域については、映像ストリームデータの配信を終了する。
【選択図】 図１
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】