特許 7562485 ストリーミングサーバ、送信方法及びプログラム

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

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

(11)【特許番号】

(24)【登録日】2024-09-27

(45)【発行日】2024-10-07

(54)【発明の名称】ストリーミングサーバ、送信方法及びプログラム

(51)【国際特許分類】

   H04N 21/238 20110101AFI20240930BHJP

   H04N 21/845 20110101ALI20240930BHJP

【ＦＩ】

H04N21/238

H04N21/845

【請求項の数】 12

(21)【出願番号】P 2021110018

(22)【出願日】2021-07-01

(65)【公開番号】P2023007048

(43)【公開日】2023-01-18

【審査請求日】2023-03-13

(73)【特許権者】

【識別番号】000003078

【氏名又は名称】株式会社東芝

(74)【代理人】

【識別番号】110001737

【氏名又は名称】弁理士法人スズエ国際特許事務所

(72)【発明者】

【氏名】溝口 侑

(72)【発明者】

【氏名】権藤 俊一

(72)【発明者】

【氏名】峰松 美佳

(72)【発明者】

【氏名】前川 智則

【審査官】醍醐 一貴

(56)【参考文献】

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

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

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

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

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

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

Ｈ０４Ｎ ２１／００－２１／８５８

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

【請求項1】

ピクチャデータの送信単位であるセグメントを前記セグメントより小さい送信単位である複数のチャンクに分割することにより得られたチャンクデータをストリーミングデータとして出力するストリーミングサーバであって、
前記チャンクに含まれるピクチャデータのサイズに基づいて前記チャンクの時間長であるチャンク長を算出するチャンク長決定部と、
前記セグメントのデータであるセグメントデータを前記チャンク長で前記複数のチャンクに分割して前記チャンクデータを生成するデータ生成部とを備え、
前記チャンク長決定部は、受信した前記ピクチャデータがＩピクチャであることを認識した場合、前記チャンク長を固定長として設定されたチャンク長より短く設定する、ストリーミングサーバ。

【請求項2】

前記ピクチャデータを受信するごとに新しいチャンクを生成するか否かを判断するチャンク生成判定部を備える請求項１に記載のストリーミングサーバ。

【請求項3】

前記チャンク長決定部は、前記チャンクごとに前記チャンク長を決定する請求項１または請求項２のいずれか１項に記載のストリーミングサーバ。

【請求項4】

前記チャンク長決定部は、前記チャンクデータの出力状況に基づいて前記チャンク長を決定する請求項１乃至請求項３のいずれか１項に記載のストリーミングサーバ。

【請求項5】

前記チャンク生成判定部は、前記ピクチャデータの種類によって、前記新しいチャンクを生成するか否かを判断する請求項２に記載のストリーミングサーバ。

【請求項6】

前記チャンク生成判定部は、前記チャンクデータの出力状況に基づいて、前記新しいチャンクを生成するか否かを判断する請求項２または請求項５のいずれか１項に記載のストリーミングサーバ。

【請求項7】

前記チャンク長決定部は、前記セグメント内の出力済みのチャンク数に基づいて前記チャンク長を決定する請求項１乃至請求項３のいずれか１項に記載のストリーミングサーバ。

【請求項8】

前記セグメント内の出力済みのチャンク数がしきい値よりも大きい場合、前記チャンク長決定部は、前記セグメントにおいては新しいチャンクを生成しないように前記チャンク長を決定する請求項７に記載のストリーミングサーバ。

【請求項9】

前記チャンク長決定部は、前記セグメント内で出力されていないピクチャデータのサイズに基づいて前記チャンク長を決定する請求項１乃至請求項３のいずれか１項に記載のストリーミングサーバ。

【請求項10】

前記チャンク長決定部は、前記チャンクに含まれるデータサイズが過去に受信したピクチャデータに基づき計算された各チャンクごとの平均ビットレートを超えないように前記チャンク長を決定する請求項１乃至請求項３のいずれか１項に記載のストリーミングサーバ。

【請求項11】

ピクチャデータの送信単位であるセグメントを前記セグメントより小さい送信単位である複数のチャンクに分割することにより得られたチャンクデータをストリーミングデータとして出力するストリーミングデータの送信方法であって、
前記チャンクに含まれるピクチャデータのサイズに基づいて前記チャンクの時間長であるチャンク長を算出し、
受信した前記ピクチャデータがＩピクチャであることを認識した場合、前記チャンク長を固定長として設定されたチャンク長より短く設定し、
前記セグメントのデータであるセグメントデータを前記チャンク長で前記複数のチャンクに分割して前記チャンクデータを生成する送信方法。

【請求項12】

コンピュータが、ピクチャデータの送信単位であるセグメントを前記セグメントより小さい送信単位である複数のチャンクに分割することにより得られたチャンクデータをストリーミングデータとして出力するためのプログラムであって、
前記チャンクに含まれるピクチャデータのサイズに基づいて前記チャンクの時間長であるチャンク長を算出し、
受信した前記ピクチャデータがＩピクチャであることを認識した場合、前記チャンク長を固定長として設定されたチャンク長より短く設定し、
前記セグメントのデータであるセグメントデータを前記チャンク長で前記複数のチャンクに分割して前記チャンクデータを生成するプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

実施形態は、映像配信のストリーミングサーバ、送信方法及びプログラムに関する。

【背景技術】

【0002】

低遅延メディアフォーマットの仕様である（Ｃｏｍｍｏｎ Ｍｅｄｉａ Ａｐｐｌｉｃａｔｉｏｎ Ｆｏｒｍａｔ（ＣＭＡＦ）に基づいた方法によりインターネットにおける低遅延の映像ストリーミングが実現される。ＣＭＡＦにおいては、サーバは送信データをチャンク単位に分割するが、通常、チャンク長は時間ベースかつ固定長に設定される。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０１８－１８６５２４号公報

【非特許文献】

【0004】

【文献】Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｏｒｇａｎｉｚａｔｉｏｎ ｆｏｒ Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ， Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ － Ｍｕｌｔｉｍｅｄｉａ ａｐｐｌｉｃａｔｉｏｎ ｆｏｒｍａｔ （ＭＰＥＧ－Ａ） － Ｐａｒｔ １９： Ｃｏｍｍｏｎ ｍｅｄｉａ ａｐｐｌｉｃａｔｉｏｎ ｆｏｒｍａｔ （ＣＭＡＦ） ｆｏｒ ｓｅｇｍｅｎｔｅｄ ｍｅｄｉａ， ＩＳＯ／ＩＥＣ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｔａｎｄａｒｄ ２３０００－１９：２０１８

【発明の概要】

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

【0005】

しかしながら、符号化した映像フレームデータであるピクチャデータは、通常、フレームごとにデータサイズが異なることから、ピクチャデータによってはビューワでの受信に大きな遅延時間が生ずる場合がある。配信番組の解像度やフレームレートなどの要因によってもその影響が大きくなることがある。

【0006】

本発明が解決しようとする課題は、ストリーミングデータのチャンクごとにチャンク長を決定するストリーミング映像配信のストリーミングサーバ、送信方法及びプログラムを提供することを目的とする。

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

【0007】

一実施形態に係るストリーミングサーバは、ピクチャデータの送信単位であるセグメントをセグメントより小さい送信単位である複数のチャンクに分割することにより得られたチャンクデータをストリーミングデータとして出力するストリーミングサーバであって、チャンクに含まれるピクチャデータのサイズに基づいてチャンクの時間長であるチャンク長を算出するチャンク長決定部と、セグメントのデータであるセグメントデータをチャンク長で複数のチャンクに分割してチャンクデータを生成するデータ生成部とを備える。チャンク長決定部は、受信したピクチャデータがＩピクチャであることを認識した場合、チャンク長を固定長として設定されたチャンク長より短く設定する。

【図面の簡単な説明】

【0008】

【図1】図１は、実施形態に係るシステムの構成例を示す機能ブロック図である。

【図2】図２は、実施形態に係るストリーミングデータの構成例を示す模式図である。

【図3】図３は、実施形態に係るストリーミングデータのセグメントとチャンクのデータ構成を示す図である。

【図4】図４は、実施形態に係るサーバのストリーミングデータ生成部の構成例を示す機能ブロック図である。

【図5】図５は、第１の実施形態に係るストリーミングデータ生成部の処理動作例を示すフローチャートである。

【図6】図６は、同第１の実施形態に係るストリーミングデータのサーバ送信とビューワ受信との関係を示す図である。

【図7】図７は、同第１の実施形態に係るチャンクの視聴可能時間を示す図である。

【図8】図８は、同第１の実施形態に係るストリーミングデータのセグメントとチャンクとの関係例を示す図である。

【図9】図９は、第２の実施形態に係るストリーミングデータ生成部の処理動作例を示すフローチャートである。

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

【0009】

以下、実施の形態について図面を参照して説明する。

【0010】

図１は、実施形態に係るシステムの構成例を示す機能ブロック図である。

【0011】

サーバ１は、ネットワーク４に接続されたクライアントにストリーミングコンテンツ（映像、音声などを含んでもよい）を提供するストリーミングサーバであり、例えばＣＰＵやメモリ、通信機能などを有したコンピュータやクラウドなどにより構成されてもよい。例えば、サーバ１は、ネットワーク４に接続された図示せぬライブカメラなどから映像データ（音声データなどを含んでもよい）を受信し、受信した映像データをストリーミングデータとしてネットワーク４に出力して、ネットワーク４に接続された受信装置２（クライアント）に提供することでもよい。サーバ１は、受信した映像データを符号化（情報源圧縮符号化）するための映像符号化部１１を備えていてもよく、符号化した映像データからストリーミングデータを生成し、ネットワーク４に出力するためのストリーミングデータ生成部１０を備えている。またサーバ１は、映像符号化部１１が出力する符号化データに相当する符号化映像データを外部から受信して、受信した符号化映像データを直接ストリーミングデータ生成部１０に入力して、ストリーミングデータを生成、出力することでもよい。

【0012】

受信装置２は、サーバ１が出力するストリーミングデータを受信するクライアントであり、例えばＣＰＵやメモリ、通信機能などを有したコンピュータなどによって構成されてもよい。また受信装置２は、コンピュータ機能やネットワーク４に接続できる通信機能などを備えていれば、例えばデジタル放送のテレビ受信装置、スマートフォンなどといった端末であってもよい。受信装置２は、受信したストリーミングデータをデコードして得たストリーミングコンテンツをビューワ２０から出力（提示）可能である。ユーザは、ビューワ２０によってストリーミングコンテンツを視聴可能である。ビューワ２０は、ストリーミングコンテンツを受信して表示出力するための例えばアプリケーションソフトウェアであり、受信装置２にインストールされている。ビューワ２０は、ストリーミングデータのデコーダの機能を備えており、例えば、ブラウザ標準ＡＰＩのＭｅｄｉａ Ｓｏｕｒｃｅ Ｅｘｔｅｎｓｉｏｎｓなどでもよい。

【0013】

プロキシサーバ３は、ネットワーク４に接続される例えばＣＰＵやメモリ、通信機能などを有したコンピュータであり、キャッシュ機能、データ転送機能などを備えていてもよい。データ転送部３０は、サーバ１が出力したストリーミングデータをネットワーク４経由で受信し、図示せぬメモリなどに保存し、要求に応じて保存したストリーミングデータを受信装置２に出力することでもよい。

【0014】

ネットワーク４は、サーバ１、受信装置２、プロキシサーバ３などが接続されて通信可能となるネットワークであり、例えば、インターネットである。また、ネットワーク４はインターネットに限らず、各装置が通信可能であれば、有線無線に関わらず複数の異なるネットワークを含むネットワークでもよい。

【0015】

図２は、実施形態に係るストリーミングデータの構成例を示す模式図であり、映像データ、ストリーミングデータの単位として一般的なピクチャデータ、セグメント、チャンクなどの例を示している。

【0016】

サーバ１は、例えばライブ動画カメラなどが出力する映像データなどを受信し、映像符号化部１１は、受信した映像データを符号化し、符号化映像データ（ピクチャデータとする）に変換する。ピクチャデータ５０１は、生成されたピクチャデータを再生順（時間）に並べた例を示しており、ピクチャデータとして３種類の例を示している。Ｉピクチャ、Ｂピクチャ、Ｐピクチャは一般的な技術、用語であり詳細は述べないが、以下のような特徴を備える。Ｉピクチャは、１ピクチャで完結するピクチャである。Ｐピクチャは、前のＩピクチャとの差分画像であり、前のＩピクチャを参照しないと，デコードできない。Ｂピクチャは、関連する前後のピクチャ（Ｉピクチャ、Ｂピクチャ、Ｐピクチャ）すべてを参照しないとデコードできない。またＩピクチャから次のＩピクチャまでのピクチャの集まりをＧｒｏｕｐ Ｏｆ Ｐｉｃｔｕｒｅｓ（ＧＯＰ）と称する。ピクチャデータ５０１は、Ｉピクチャである１と１６の間に、Ｂピクチャ、Ｐピクチャが生成される例であり、ＧＯＰは１５である。ＧＯＰ単位においては、必ずＩピクチャから始めることで、ＧＯＰをデコード可能な単位と解することができる。以上のような特徴から、Ｉピクチャは、通常、他のピクチャに比べてデータ量（データサイズ）が大きい。

【0017】

セグメント５０２は、映像データのストリーミングにおいてデコード可能な単位であり、１セグメントが１ＧＯＰで構成される場合の例である。チャンク５０３、５０４は、メディアフォーマットの規格であるＣｏｍｍｏｎ Ｍｅｄｉａ Ａｐｐｌｉｃａｔｉｏｎ Ｆｏｒｍａｔ（ＣＭＡＦ）により定義されるチャンクの例である。チャンクは、セグメントをさらに細かい時間長（通常は、１秒未満）に分割して映像データを格納可能としたものである。チャンクの時間長をチャンク長と称する場合もある。ＣＭＡＦ準拠のサーバはストリーミングデータをチャンクごとに出力・配信することで，低遅延映像ストリーミングを実現する。一般的に低遅延映像配信で用いられるＣＭＡＦ準拠セグメントにおいて、チャンク長は固定長である。チャンク５０３は、チャンク長が固定長に設定されている場合の例であり、セグメント内のすべてのチャンク長は同じである（例えば、０．５秒）。通常、ユーザなどがチャンク長の設定は時間長（秒指定）で行うが、チャンク長は、設定した時間長に送信されるピクチャ数（画像フレーム数）と解することもできる。例えば、チャンク長を１秒にした場合は、チャンク長は、画像フレームレートの値（１秒間の送信画像フレーム数）と解することもできる。本実施形態においては、チャンク長は時間長とし、例えばサーバ１のストリーミングデータ生成部１０が決定する。

【0018】

チャンク長が固定長に設定されている場合、チャンクごとに格納されているピクチャデータの種類やメディアデータの種類が異なると、チャンク長は同じだが、データ量（データサイズ）に違いが生じることがある。例えば、通常、ＩピクチャはＰピクチャよりもデータサイズが大きいため、Ｉピクチャが格納されているチャンクのデータサイズは他（例えばＰピクチャのみ格納したもの）に比べて増大する傾向にある。そのため、チャンクごとにデータサイズが異なり、チャンクごとにデータのダウンロードに要する時間にばらつきが発生する可能性がある。特にデータサイズの大きなＩピクチャが格納されているチャンクのダウンロードにおいては大きな遅延を生じさせる可能性があり、さらにプロキシサーバなどを介するとその影響は大きくなる可能性がある。

【0019】

本実施形態においては、セグメント内のチャンク長（時間長）を可変とし、サーバ１は、チャンクごとにチャンク長を決定し、決定したチャンク長のチャンクを生成する。チャンク５０４は、セグメント内のチャンク長（時間長）を可変とした場合の例であり、同一セグメント内にチャンク長の異なるチャンクが含まれる可能性がある。なおチャンク長は、時間ではなく、画像フレーム数として定義することでもよい。

【0020】

図３は、実施形態に係るストリーミングデータのセグメントとチャンクのデータ構成を示す図であり、ＣＭＡＦ準拠のセグメント、チャンクのデータ構造を示している。セグメント５１１はセグメントの構成を示し、ＣＭＡＦ準拠のセグメント（ＣＭＡＦ．ｍ４ｓ）には、Ｓｅｇｍｅｎｔ Ｔｙｐｅ Ｂｏｘ（ｓｔｙｐ）と呼ばれるセグメントの種類を示すヘッダの後に１以上のチャンクが続いて格納される。

【0021】

チャンク５１２は、チャンクの構成を示し、各チャンクは、ピクチャデータ本体を格納するＭｅｄｉａ Ｄａｔａ Ｂｏｘ（ｍｄａｔ）とｍｄａｔに関するメタ情報を格納するＭｏｖｉｅ Ｆｒａｇｍｅｎｔ Ｂｏｘ（ｍｏｏｆ）との１つずつで構成されている。ｍｏｏｆには同じチャンクのｍｄａｔに格納されるピクチャデータのデータサイズなどの情報を入れることができる。データサイズには通常、ｍｏｏｆのデータサイズが含められる。サーバ１はストリーミングデータをチャンクごとに出力・配信し、ビューワ２０は取得したチャンクをデコード機能に入力することで映像コンテンツを出力し、ユーザが視聴することができる。

【0022】

図４は、実施形態に係るサーバのストリーミングデータ生成部の構成例を示す機能ブロック図である。

【0023】

ストリーミングデータ生成部１０は、ピクチャデータ及びそのメタ情報をピクチャデータ毎に受信する手段と、受信した情報に応じて、ピクチャデータを格納するチャンクのチャンク長を決定する制御部１００と、制御部１００で決定したチャンク長でピクチャデータのパッケージングを行い、パッケージングされたピクチャデータをチャンク（またはセグメント）として出力するパッケージ部１２０と、を備えている。

【0024】

制御部１００は、ピクチャデータ及びメタ情報を受信するデータ受信部１１０と、データ出力部１０６から入力されるデータ出力状況（フィードバック情報）などに基づいて新しいチャンク生成の可否を判定するチャンク生成判定部１０１と、ピクチャデータからピクチャ情報（ピクチャの種類やデータサイズなど）を抽出するピクチャ情報抽出部１０２と、ピクチャデータを一時的に格納するピクチャバッファリング部１０３と、フィードバック情報を基にメタ情報を更新するメタ情報更新部１０４と、更新済みのメタ情報及びピクチャ情報などに基づいてチャンク毎にチャンク長を決めたり算出したりするチャンク長決定部１０５と、パッケージ部１２０にチャンク長とピクチャデータを出力しチャンク生成判定部１０１にフィードバック情報を出力するデータ出力部１０６とを備えている。

【0025】

ピクチャ情報は、ピクチャの種類やデータサイズなどの情報であり、ピクチャデータを解析して抽出することでもよい。メタ情報は、映像データの解像度や、フレームレート（画像フレームレート）、平均ビットレート、ＧＯＰなどの情報である。フレームレートは、例えば１秒間にデータ受信部１１０が受信する画像フレーム数（ピクチャ数）であってもよい。平均ビットレートは、例えば過去にデータ受信部１１０が受信した全フレーム（ピクチャ）分のデータサイズの秒平均やチャンクごとの平均などであってもよい。また平均ビットレートは、Iピクチャ以外のピクチャデータの平均であってもよく、任意の平均ビットレートを定義できる。フィードバック情報は、データ出力部１０６が生成し出力する情報であり、例えば、セグメントにおいてどの程度のチャンクが出力されたかといった情報であってもよい。またデータ出力部１０６は、チャンクをパッケージ部１２０に出力したタイミングの情報をフィードバック情報として出力することでもよい。

【0026】

パッケージ部１２０は、データ出力部１０６から受け取ったチャンク長に基づいて、データ出力部１０６から入力されたピクチャデータのパッケージング（チャンク単位にピクチャデータを格納）を行うパッケージ処理部１２１を備えている。パッケージ処理部１２１が生成するパッケージングデータは基本的にはチャンク単位のデータとなり、パッケージ処理部１２１の出力タイミングによって出力するデータはチャンク単位またはセグメント単位とすることでもよい。パッケージ処理部１２１は、パッケージングデータを、図示せぬ通信部などへ出力し、通信部からネットワーク４へ出力する。
（第１の実施形態）
第１の実施形態においては、ストリーミングデータを生成し、出力するサーバが、チャンクを生成する時にチャンク長を決定する例を示す。

【0027】

図５は、第１の実施形態に係るストリーミングデータ生成部の処理動作例を示すフローチャートである。

【0028】

ユーザが受信装置２のビューワ２０で、サーバ１の提供するストリーミングコンテンツを視聴しているとする。ストリーミングコンテンツは、例えばライブカメラで撮影される映像データをサーバ１がネットワーク４経由で受信し、サーバ１によって受信装置２に配信されている。サーバ１は、映像データを受信すると映像符号化部１１で符号化し、ピクチャデータを得る。データ受信部１１０は、ピクチャデータとメタ情報を受信すると、それらをチャンク生成判定部１０１に入力する（ステップＳ１０１）。

【0029】

チャンク生成判定部１０１は、新しくチャンクを生成するかどうかを判定する（ステップＳ１０２）。新しいチャンク生成の判断は、データ受信部１１０からのピクチャデータ、メタ情報や、データ出力部１０６からのフィードバック情報に基づいて行うことでもよい。より具体的には、チャンク生成判定部１０１は、フィードバック情報のチャンクもしくはセグメントを出力されたタイミングに基づいて、データ出力部１０６がチャンクもしくはセグメントを出力したことを認識した時に、新しくチャンクを生成すると判断することでもよい。またチャンク生成判定部１０１は、データ受信部１１０が受信したピクチャデータを解析することにより、例えばデータ量の大きいピクチャ（例えばIピクチャ）を受信したことを認識した時、新しくチャンクを生成すると判断することでもよい。チャンク生成判定部１０１は、データ受信部１１０が受信したピクチャデータを全て解析することでもよいし、任意のタイミングで解析することでもよい。チャンク生成判定部１０１は、予めしきい値などを図示せぬメモリなどに設定しておき、しきい値とピクチャデータのデータサイズを比較してデータ量の大小を判断することでもよい。また、チャンク生成判定部１０１は、受信したピクチャデータの種類によって、新しくチャンクを生成すると判断することでもよい。例えば、チャンク生成判定部１０１は、Iピクチャを受信したときは、常に新しくチャンクを生成すると判断することでもよい。

【0030】

またチャンク生成判定部１０１は、データ出力部１０６からデータ出力状況に関わるフィードバック情報を取得した時に、データ出力状況によって、新しいチャンクを生成するか否か判断してもよい。具体的には、チャンク生成判定部１０１は、データ出力部１０６の図示せぬバッファ（ピクチャバッファリング部１０３でもよい）に格納されているチャンクデータが多い場合は、ビューワ２０までのデータ伝送速度が低速であると判断して、新しいチャンクを生成することを決定する。一方、データ出力部１０６の図示せぬバッファに格納されているチャンクデータが少ない場合は、ビューワ２０までのデータ伝送速度が高速であると判断して、新しいチャンクの生成を控えることを決定するなどでもよい。

【0031】

新しいチャンクの生成を行うと判断した場合、チャンク生成判定部１０１はピクチャデータをピクチャ情報抽出部１０２に送る。また、データ受信部１１０から取得したメタ情報とデータ出力部１０６から取得したフィードバック情報とをメタ情報更新部１０４に入力する（ステップＳ１０２のＹＥＳ）。

【0032】

ピクチャ情報抽出部１０２は、ステップＳ１０２におけるチャンク生成判定部１０１のチャンク生成によって挙動が異なる。新しいチャンクの生成を行わない場合は、直ちにピクチャデータをピクチャバッファリング部１０３に入力する（ステップＳ１０２のＮＯ、Ｓ１０６）。一方、新しいチャンクの生成を行う場合はピクチャデータからピクチャ情報を抽出しチャンク長決定部１０５に入力する（ステップＳ１０３）またメタ情報更新部１０４は、チャンク生成判定部１０１からメタ情報とフィードバック情報を受信し、それらを基にメタ情報を更新しチャンク長決定部１０５に入力する（ステップＳ１０４）。なお、ステップＳ１０３、ステップＳ１０４の処理は並列に動作させることでもよい。

【0033】

次に、チャンク長決定部１０５は、メタ情報更新部１０４から受信した更新済みのメタ情報、ピクチャ情報抽出部１０２から受信したピクチャ情報、フィードバック情報などに基づいて、新しく生成するチャンクのチャンク長を決定する（ステップＳ１０５）。例えば、チャンク長決定部１０５は、ピクチャ情報から受信したピクチャがデータサイズの大きなピクチャ（例えばＩピクチャ）であることを認識した場合、固定長として設定されているチャンク長よりもチャンク長を小さく設定することでもよい。

【0034】

またチャンク長決定部１０５は、更新済みのメタ情報から取得した映像データ情報（解像度やフレームレート、平均ビットレート、ＧＯＰ長など）や、フィードバック情報（データ出力状況）に基づいて、現在セグメントのうち、どのピクチャデータまでがチャンクとして出力されたかを認識し、現在セグメントの残りのデータ量によってチャンク長を決定することでもよい。このとき、例えば１チャンクに含まれるビット数（データ量、データサイズ）が、平均ビットレートを超えないようにチャンク長を決定することでもよい。

【0035】

例えばチャンク長決定部１０５は、フィードバック情報からデータ出力されていないピクチャがデータサイズの小さなピクチャのみ（例えばＩピクチャ以外のピクチャのみ）であると認識した場合は、チャンク長を大きくしてもチャンクサイズは大きくならないことから、新しく生成するチャンクのチャンク長を大きく設定するように決定してもよい。また、チャンク長決定部１０５は、フィードバック情報からデータ出力されていないピクチャにデータサイズの大きなピクチャ（例えばＩピクチャ）が含まれ、新しく生成するチャンクにデータサイズの大きなピクチャが含まれると判断した場合は、チャンク長を大きくするとチャンクサイズが大きくなり、受信装置２におけるチャンクのダウンロードの遅延時間が大きくなることから、新しく生成するチャンクのチャンク長を小さく設定してもよい。またチャンク生成判定部１０１が、サーバ１からビューワ２０までのデータ伝送速度が低速であると判断した時には、チャンク長決定部１０５は、固定長として設定されたチャンク長の半分の長さにするなど、よりチャンク長を小さく設定することでもよい。

【0036】

さらに、チャンク長決定部１０５は、チャンク長を決定する際に、同一セグメント内の出力済みのチャンク数（フィードバック情報に含まれていてもよい）を考慮することでもよい。例えば、チャンク長を短くするとそのチャンクの送信時間を短くすることはできるが、セグメント内のチャンク数が増える。各チャンクにはメタデータ（図３のチャンク５１２のｍｏｏｆ）が付加されるため、チャンク数が増えると同時にオーバヘッドであるメタデータが増加し、その結果１セグメントで送信するべきデータ量（データサイズ）が増加する。このような場合、チャンク長決定部１０５は、１セグメント内のデータ量をなるべく抑制するように、チャンク数が大きくならないようにチャンク長を決定することが望ましい。すなわちチャンク長決定部１０５は、１つのチャンクのデータサイズを可能な限り大きくするようにチャンク長を決定するようにしてもよい。この場合、データサイズの上限は、平均ビットレートなどの情報に基づいて決定することでもよい。また例えば、チャンク長決定部１０５は、フィードバック情報から取得した同一セグメント内の出力済みのチャンク数があるしきい値よりも大きくなった場合には、以降、同一セグメントにおいては新しくチャンクを生成しないようにチャンク長を決定するようにしてもよい。

【0037】

またチャンク長決定部１０５は、上記のチャンク長の決定、設定処理において、解像度やフレームレート、平均ビットレートなどの映像データ情報を考慮してチャンク長を決定することでもよい。例えば、チャンク生成判定部１０１が、セグメントのうちデータ出力されていないピクチャの種類がデータサイズの小さなピクチャのみ（例えばＩピクチャ以外のピクチャのみ）であることを認識したが、同時に各ピクチャの平均ビットレートが高くなっている場合は、ピクチャの種類によらず、固定長として設定されたチャンク長よりもチャンク長を小さくするように設定することでもよい。

【0038】

またチャンク長決定部１０５は、ピクチャ情報から得たピクチャの種類やデータサイズなどに基づいて、チャンク毎に格納するピクチャデータに応じたチャンク長を決定することでもよい。具体的には、チャンク長決定部１０５は、受信したピクチャの種類がデータサイズの大きなＩピクチャであることを認識した場合に、固定長として設定されたチャンク長の半分の長さにするなど、よりチャンク長を小さく設定するなどが考えられる。

【0039】

さらにチャンク長は、例えば平均ビットレートなどに基づいて、新しく生成されるチャンクに将来格納されるピクチャのデータサイズを推測して、推測したデータサイズに基づいてチャンク長を決定してもよい。例えば新しく生成されるチャンクに格納されると推測される総ビット数（チャンクのデータサイズ）が、予め設定した第１のしきい値を超えないように、将来格納されるピクチャのフレーム数を決定することでもよい。また推測したデータサイズのしきい値超過量を定める第２のしきい値を設定してもよい。この場合、推測したデータサイズが第１のしきい値を超えたとしても、第２のしきい値を下回っていたら推測したデータサイズ分のチャンク長を新しく生成されるチャンクのチャンク長に決定する。また、例えば大、中、小のようにチャンク長を予めいくつか決めておき、受信したピクチャの種類やフィードバック情報などによって、チャンク長を自動的に選択することでもよい。例えば、チャンク長決定部１０５は、Iピクチャを受信したらチャンク長に「小」を選択するなどでもよい。チャンク生成判定部１０１が、フィードバック情報から、サーバ１からビューワ２０までのデータ伝送速度が高速であると判断した場合は、チャンク長決定部１０５は、チャンク長に「大」を選択するなどでもよい。

【0040】

またチャンク長決定部１０５は、フィードバック情報からデータ出力部１０６によるデータ出力速度を算出し、データ出力速度によって、チャンク長を決定してもよい。具体的には、チャンク長決定部１０５は、データ出力部１０６のデータ出力速度が大きい場合は、サーバ１からビューワ２０までのデータ伝送速度が高速であると判断して、チャンク長を可能な限り長くし、データ出力部１０６のデータ出力速度が小さい場合は、サーバ１からビューワ２０までのデータ伝送速度が低速であると判断して、チャンク長を可能な限り小さくするなどでもよい。

【0041】

ピクチャバッファリング部１０３では受け取ったピクチャデータ順にバッファにピクチャデータを格納する（ステップＳ１０６）。データ出力部１０６は、データをチャンク出力するかどうかを判断する（ステップＳ１０７）。具体的には、データ出力部１０６は、チャンク長決定部１０５からチャンク長を受け取ったら、チャンクを出力すると判断することでもよい。データ出力部１０６は、チャンクを出力しないと判断した場合は次のピクチャデータの受信処理をする（ステップＳ１０７のＮＯ）。データ出力部１０６は、データ出力すると判断した場合は、ピクチャバッファリング部１０３から決定したチャンク長分のピクチャデータを取り出し、チャンク長とピクチャデータをパッケージ部１２０に出力する（ステップＳ１０８）。それと同時にデータ出力部１０６は、現在セグメント中のどの程度チャンク出力したか、セグメントもしくはＧＯＰ先頭のＩピクチャから以降どの程度のＢピクチャ、Ｐピクチャが出力されたかなどデータ出力状況のフィードバック情報をチャンク生成判定部１０１に出力する（ステップＳ１０９）。

【0042】

パッケージ処理部１２１は、チャンク長及びピクチャデータを受信すると、受信したチャンク長で受信したピクチャデータのパッケージングを行い、チャンク（またはセグメント）を生成し出力する（ステップＳ１１０）。以上の手順により出力されるチャンク・セグメントはＣＭＡＦのフォーマットに準拠するため、受信装置２のビューワ２０は、例えばＣＭＡＦに準拠していれば、特に修正を必要とすることなく本実施形態により生成、出力されたチャンクを受信して、ストリーミングコンテンツを表示することが可能である。

【0043】

以上のようにサーバ１は、チャンク長を可変に設定することで、出力するチャンク間のデータサイズのばらつきをなくすことが可能となり、受信装置２によるダウンロードの際に、データサイズの大きな特定のチャンクによる大きな遅延を防ぐことが可能となる。

【0044】

企業や自治体のネットワーク内からインターネットに接続する際は通常、複数のプロキシサーバを経由する必要があり、プロキシサーバを経由することで通信の応答に影響（遅延）を生じさせる可能性がある。また通常、セグメント内のチャンク分割は時間単位かつ固定長で行われるため、データサイズが大きい特定のチャンクの取得に時間を要するが、特にプロキシサーバを介するとその影響は大きくなり、ＣＭＡＦが志向する低遅延映像配信を行えないことがある。本実施形態においては、このようなプロキシサーバを介したネットワーク環境下において特に効果が顕著となり、低遅延映像配信が可能となる。

【0045】

図６は、同第１の実施形態に係るストリーミングデータのサーバ送信とビューワ受信との関係を示す図である。図６（ａ）はセグメント配信（セグメント長４秒）による例を示し、図６（ｂ）はＣＭＡＦ準拠のフォーマットによる固定長のチャンクの配信例（セグメント長４秒、チャンク長１秒）、図６（ｃ）はＣＭＡＦ準拠のフォーマットにおいてチャンクを可変長とした場合の本実施形態による配信例を示す。

【0046】

図６（ａ）で示すように、セグメント配信による方法では、サーバがセグメント４を生成送信してから、ビューワがセグメント４を受信して、ユーザが視聴可能になるまでに４＋α＋β秒必要となる。この内訳は、セグメント４のサーバによる送信時間４秒と、プロキシなどによる処理などを含めたネットワーク遅延α秒、上記以外のビューワのダウンロード時間などの処理時間β秒である。

【0047】

図６（ｂ）で示すように、チャンク長を固定にした場合は、サーバがセグメント４のチャンク４Ａを生成送信してから、ビューワがチャンク４Ａを受信して、ユーザが視聴可能になるまでに１＋α＋β秒必要となる。この内訳は、チャンク４Ａのサーバによる送信遅延時間１秒と、プロキシなどによる処理などを含めたネットワーク遅延α秒、上記以外のビューワのダウンロード時間などの処理時間β秒である。従って、図６（ｂ）においては、図６（ａ）に比較して、サーバによる送信時間、ネットワーク遅延α秒、処理時間β秒が短くなり、チャンク４Ａ（セグメント４の先頭部分に相当）の視聴可能時刻は改善される。

【0048】

図６（ｃ）は、本実施形態による図６（ｂ）におけるチャンク４Ａのチャンク長を短くした場合の例であり、チャンク４Ａのチャンク長を短くした分だけサーバによる送信遅延時間は、図６（ｂ）に示した１秒よりも短くなる。また、ネットワーク伝送遅延α秒も同様、送信するデータサイズを小さくすると小さくなることから、図６（ｃ）においては図６（ｂ）の場合よりもネットワーク伝送遅延α秒を縮小することが可能である。この効果は、例えばサーバ１から受信装置２へのデータ送信にプロキシサーバ３を用いる場合に特に顕著となる。また、処理遅延β秒も同様、送信するデータサイズを小さくすると小さくなることから、本実施形態による図６（ｃ）においては、図６（ｂ）の場合よりも縮小することが可能である。従って、図６（ｃ）においては、図６（ｂ）に比較して、サーバによる送信時間、ネットワーク遅延α秒、処理時間β秒が短くなり、チャンク４Ａの視聴可能時刻は改善される。

【0049】

図７は、同第１の実施形態に係るチャンクの視聴可能時間を示す図である。

【0050】

ピクチャデータ５２１は、横軸をデータサイズとして、ピクチャ１であるIピクチャから連続するピクチャの例である。ピクチャ２以降は、例えばＢピクチャもしくはＰピクチャである。ピクチャデータ５２１において各ピクチャの横幅はそれぞれデータサイズを示し、Iピクチャであるピクチャ１のデータサイズが最も大きいことを示している。チャンク５２２は、横軸を時間として、ピクチャデータ５２１をチャンク長が固定長、可変長とした場合のそれぞれのチャンクの例を示している。チャンク５２２が固定長の場合、ピクチャデータ５２１を１つのチャンクで格納する。チャンク５２２が可変長の場合、ピクチャデータ５２１は、図５のステップＳ１０５によって設定されるチャンク長で２つ以上のチャンクに分けられる。チャンク５２２において、チャンク長を固定長とした場合よりも可変長とした場合の方が、ユーザによる視聴可能時間を小さくできることが示される。

【0051】

図８は、同第１の実施形態に係るストリーミングデータのセグメントとチャンクとの関係例を示す図である。図８（ａ）は固定長でチャンク化されたセグメントの例、図８（ｂ）は可変長でチャンク化されたセグメントの例である。

【0052】

図８（ａ）が示すように、固定長でチャンク化されたセグメントではすべてのチャンクが固定長（本例では０．５秒）に設定される。一方、図８（ｂ）が示すように、本実施形態におけるセグメントは、可変長でチャンク化するため、異なるチャンク長のチャンクが含まれる。例えば、データサイズが大きいＩピクチャが格納されたチャンクは短く（本図では０．１秒）、その他のチャンクでは図５のフローチャートによって決められるチャンク長のチャンクとなる。連続して送信されるピクチャデータの種類やデータサイズによっては、チャンク長が０．５秒よりも大きく０．６秒になったり、０．５秒より小さい値になったりすることもある。しかしながら、各チャンクのデータサイズについては、図５のステップＳ１０５において、例えば平均ビットレートをしきい値としてチャンク長を決定することにより、チャンクのデータサイズのばらつきを小さく抑えることができる。

【0053】

図８（ｃ）、図８（ｄ）は１セグメント内にデータサイズの大きなデータ（例えばＩピクチャ）が複数ある場合の例であり、図８（ｃ）はセグメントが固定長でチャンク化された場合の例、図８（ｄ）はセグメントが可変長でチャンク化された場合の例である。図５のステップＳ１０２において、データ受信部１１０からのピクチャデータの種類に基づいて、チャンクを生成するか否かを決定することによって、図８（ｄ）のようにセグメント途中にＩピクチャが入っている場合でも、Ｉピクチャを格納するチャンク長を可変に設定することができ、チャンクごとのデータサイズのばらつきを抑えることができる。本実施形態により図８（ｄ）のような場合が可能になることで、ＨＴＴＰ／１．１ ＧＥＴなどによるセグメントの最初のチャンクからの配信に加え、セグメント途中からのコンテンツ取得（ＨＴＴＰ Ｒａｎｇｅ ＧＥＴなど）も想定し、ＧＯＰ単位でチャンクを区切ることができる。これによりビューワ２０は複数のチャンクを待つことなく、受信したチャンクのピクチャデータをデコードして、出力、表示することが可能となる。

【0054】

以上のように本実施形態では、パッケージ処理部１２１でＣＭＡＦなど各低遅延メディアフォーマットに準拠した構造のチャンクもしくはセグメントを出力することで、受信装置２は、ブラウザのような標準環境などで特に改修などの必要なくチャンク単位での低遅延映像ストリーミングコンテンツの視聴が可能となる。

【0055】

以上のように、第１の実施形態のサーバ１（ストリーミングデータ生成部１０）によれば、チャンク毎にチャンク長を設定しパッケージングすることで、低遅延で映像ストリーミングコンテンツの配信を行うことが可能となる。

【0056】

（第２の実施形態）
本実施形態においては、データ出力部１０６からピクチャデータを出力する直前にチャンク長を決定する例を示す。

【0057】

図９は、第２の実施形態に係るストリーミングデータ生成部の処理動作例を示すフローチャートである。

【0058】

第１の実施形態と同様、サーバ１は、映像データを受信すると映像符号化部１１で符号化し、ピクチャデータを得る。データ受信部１１０は、ピクチャデータとメタ情報を受信すると、チャンク生成判定部１０１に入力する（ステップＳ２０１）。チャンク生成判定部１０１は、受信したデータをピクチャバッファリング部１０３に格納する（ステップＳ２０２）。チャンク生成判定部１０１は、受信した全ピクチャのデータサイズとピクチャ数とをカウントする（ステップＳ２０３）。チャンク生成判定部１０１は、しきい値を図示せぬメモリに備えておき、カウントしたデータサイズがしきい値を上回ったタイミングで、チャンクを生成することを決定する（ステップＳ２０４のＹＥＳ）。チャンク生成判定部１０１は、チャンクを生成することを決定した時のピクチャ数のカウント値と画像フレームレートからチャンク長を算出する（ステップＳ２０５）。ステップＳ２０６以降は、図５のステップＳ１０８以降と同様であるため説明を省略する。なおステップＳ２０４でチャンク生成判定部１０１が用いたしきい値は、予め設定しておいてもよいし、例えば計算する平均ビットレートをしきい値として逐次的に設定してもよい。

【0059】

以上の手順により、サーバ１（ストリーミングデータ生成部１０）は、チャンクサイズに基づいてチャンクを生成する直前にチャンク長を決定することが可能となる。

【0060】

以上に述べた少なくとも１つの実施形態によれば、ストリーミングデータのチャンクごとにチャンク長を決定するストリーミング映像配信のストリーミングサーバ、送信方法及びプログラムを提供することができる。

【0061】

本発明のいくつかの実施形態を説明したが、これらの実施形態は例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができ、また、各実施形態における技術要素を別の実施形態に適用することができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。さらにまた、請求項の各構成要素において、構成要素を分割して表現した場合、或いは複数を合わせて表現した場合、或いはこれらを組み合わせて表現した場合であっても本発明の範疇である。また、複数の実施形態を組み合わせてもよく、この組み合わせで構成される実施例も発明の範疇である。また、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

【0062】

また、図面は、説明をより明確にするため、実際の態様に比べて、各部の幅、厚さ、形状等について模式的に表される場合がある。ブロック図においては、結線されていないブロック間もしくは、結線されていても矢印が示されていない方向に対してもデータや信号のやり取りを行う場合もある。フローチャート、シーケンスチャートなどに示す処理は、ＩＣチップ、デジタル信号処理プロセッサ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ ＰｒｏｃｅｓｓｏｒまたはＤＳＰ）などのハードウェアもしくはマイクロコンピュータを含むコンピュータなどで動作させるソフトウェア（プログラムなど）またはハードウェアとソフトウェアの組み合わせによって実現してもよい。また請求項を制御ロジックとして表現した場合、コンピュータを実行させるインストラクションを含むプログラムとして表現した場合、及び前記インストラクションを記載したコンピュータ読み取り可能な記録媒体として表現した場合でも本発明の装置を適用したものである。また、使用している名称や用語についても限定されるものではなく、他の表現であっても実質的に同一内容、同趣旨であれば、本発明に含まれるものである。

【符号の説明】

【0063】

１…サーバ、２…受信装置、３…プロキシサーバ、４…ネットワーク、１０…ストリーミングデータ生成部、１１…映像符号化部、２０…ビューワ、１００…制御部、１０１…チャンク生成判定部、１０２…ピクチャ情報抽出部、１０３…ピクチャバッファリング部、１０４…メタ情報更新部、１０５…チャンク長決定部、１０６…データ出力部、１２０…パッケージ部、１２１…パッケージ処理部。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】