JP2023007048A - ストリーミングサーバ、送信方法及びプログラム - Google Patents
ストリーミングサーバ、送信方法及びプログラム Download PDFInfo
- Publication number
- JP2023007048A JP2023007048A JP2021110018A JP2021110018A JP2023007048A JP 2023007048 A JP2023007048 A JP 2023007048A JP 2021110018 A JP2021110018 A JP 2021110018A JP 2021110018 A JP2021110018 A JP 2021110018A JP 2023007048 A JP2023007048 A JP 2023007048A
- Authority
- JP
- Japan
- Prior art keywords
- chunk
- data
- length
- picture
- streaming
- 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.)
- Pending
Links
- 230000005540 biological transmission Effects 0.000 title claims abstract description 22
- 238000000034 method Methods 0.000 title claims abstract description 14
- 238000012545 processing Methods 0.000 description 19
- 238000010586 diagram Methods 0.000 description 15
- 230000006870 function Effects 0.000 description 9
- 238000004806 packaging method and process Methods 0.000 description 8
- 230000003139 buffering effect Effects 0.000 description 7
- 238000004891 communication Methods 0.000 description 7
- 230000000694 effects Effects 0.000 description 4
- 238000000605 extraction Methods 0.000 description 4
- 239000000470 constituent Substances 0.000 description 3
- AWSBQWZZLBPUQH-UHFFFAOYSA-N mdat Chemical compound C1=C2CC(N)CCC2=CC2=C1OCO2 AWSBQWZZLBPUQH-UHFFFAOYSA-N 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000008569 process Effects 0.000 description 3
- 230000015556 catabolic process Effects 0.000 description 2
- 230000007423 decrease Effects 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 102100037812 Medium-wave-sensitive opsin 1 Human genes 0.000 description 1
- 230000006835 compression Effects 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 238000002716 delivery method Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 239000012634 fragment Substances 0.000 description 1
- 230000014509 gene expression Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000004904 shortening Methods 0.000 description 1
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/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
-
- 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
- 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/85406—Content authoring involving a specific file format, e.g. MP4 format
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
【課題】ストリーミングデータのチャンクごとにチャンク長を決定するストリーミング映像配信のストリーミングサーバ、送信方法及びプログラムを提供する。【解決手段】一実施形態に係るストリーミングサーバは、ピクチャデータをチャンクに分割したチャンクデータをストリーミングデータとして出力するストリーミングサーバであって、前記チャンクの時間長であるチャンク長を算出するチャンク長決定部と、前記ピクチャデータを前記チャンク長でチャンクに分割してチャンクデータを生成するデータ生成部とを備える。【選択図】図4
Description
実施形態は、映像配信のストリーミングサーバ、送信方法及びプログラムに関する。
低遅延メディアフォーマットの仕様である(Common Media Application Format(CMAF)に基づいた方法によりインターネットにおける低遅延の映像ストリーミングが実現される。CMAFにおいては、サーバは送信データをチャンク単位に分割するが、通常、チャンク長は時間ベースかつ固定長に設定される。
International Organization for Standardization, Information technology - Multimedia application format (MPEG-A) - Part 19: Common media application format (CMAF) for segmented media, ISO/IEC International Standard 23000-19:2018
しかしながら、符号化した映像フレームデータであるピクチャデータは、通常、フレームごとにデータサイズが異なることから、ピクチャデータによってはビューワでの受信に大きな遅延時間が生ずる場合がある。配信番組の解像度やフレームレートなどの要因によってもその影響が大きくなることがある。
本発明が解決しようとする課題は、ストリーミングデータのチャンクごとにチャンク長を決定するストリーミング映像配信のストリーミングサーバ、送信方法及びプログラムを提供することを目的とする。
一実施形態に係るストリーミングサーバは、ピクチャデータをチャンクに分割したチャンクデータをストリーミングデータとして出力するストリーミングサーバであって、チャンクの時間長であるチャンク長を算出するチャンク長決定部と、ピクチャデータをチャンク長でチャンクに分割してチャンクデータを生成するデータ生成部とを備える。
以下、実施の形態について図面を参照して説明する。
図1は、実施形態に係るシステムの構成例を示す機能ブロック図である。
サーバ1は、ネットワーク4に接続されたクライアントにストリーミングコンテンツ(映像、音声などを含んでもよい)を提供するストリーミングサーバであり、例えばCPUやメモリ、通信機能などを有したコンピュータやクラウドなどにより構成されてもよい。例えば、サーバ1は、ネットワーク4に接続された図示せぬライブカメラなどから映像データ(音声データなどを含んでもよい)を受信し、受信した映像データをストリーミングデータとしてネットワーク4に出力して、ネットワーク4に接続された受信装置2(クライアント)に提供することでもよい。サーバ1は、受信した映像データを符号化(情報源圧縮符号化)するための映像符号化部11を備えていてもよく、符号化した映像データからストリーミングデータを生成し、ネットワーク4に出力するためのストリーミングデータ生成部10を備えている。またサーバ1は、映像符号化部11が出力する符号化データに相当する符号化映像データを外部から受信して、受信した符号化映像データを直接ストリーミングデータ生成部10に入力して、ストリーミングデータを生成、出力することでもよい。
受信装置2は、サーバ1が出力するストリーミングデータを受信するクライアントであり、例えばCPUやメモリ、通信機能などを有したコンピュータなどによって構成されてもよい。また受信装置2は、コンピュータ機能やネットワーク4に接続できる通信機能などを備えていれば、例えばデジタル放送のテレビ受信装置、スマートフォンなどといった端末であってもよい。受信装置2は、受信したストリーミングデータをデコードして得たストリーミングコンテンツをビューワ20から出力(提示)可能である。ユーザは、ビューワ20によってストリーミングコンテンツを視聴可能である。ビューワ20は、ストリーミングコンテンツを受信して表示出力するための例えばアプリケーションソフトウェアであり、受信装置2にインストールされている。ビューワ20は、ストリーミングデータのデコーダの機能を備えており、例えば、ブラウザ標準APIのMedia Source Extensionsなどでもよい。
プロキシサーバ3は、ネットワーク4に接続される例えばCPUやメモリ、通信機能などを有したコンピュータであり、キャッシュ機能、データ転送機能などを備えていてもよい。データ転送部30は、サーバ1が出力したストリーミングデータをネットワーク4経由で受信し、図示せぬメモリなどに保存し、要求に応じて保存したストリーミングデータを受信装置2に出力することでもよい。
ネットワーク4は、サーバ1、受信装置2、プロキシサーバ3などが接続されて通信可能となるネットワークであり、例えば、インターネットである。また、ネットワーク4はインターネットに限らず、各装置が通信可能であれば、有線無線に関わらず複数の異なるネットワークを含むネットワークでもよい。
図2は、実施形態に係るストリーミングデータの構成例を示す模式図であり、映像データ、ストリーミングデータの単位として一般的なピクチャデータ、セグメント、チャンクなどの例を示している。
サーバ1は、例えばライブ動画カメラなどが出力する映像データなどを受信し、映像符号化部11は、受信した映像データを符号化し、符号化映像データ(ピクチャデータとする)に変換する。ピクチャデータ501は、生成されたピクチャデータを再生順(時間)に並べた例を示しており、ピクチャデータとして3種類の例を示している。Iピクチャ、Bピクチャ、Pピクチャは一般的な技術、用語であり詳細は述べないが、以下のような特徴を備える。Iピクチャは、1ピクチャで完結するピクチャである。Pピクチャは、前のIピクチャとの差分画像であり、前のIピクチャを参照しないと,デコードできない。Bピクチャは、関連する前後のピクチャ(Iピクチャ、Bピクチャ、Pピクチャ)すべてを参照しないとデコードできない。またIピクチャから次のIピクチャまでのピクチャの集まりをGroup Of Pictures(GOP)と称する。ピクチャデータ501は、Iピクチャである1と16の間に、Bピクチャ、Pピクチャが生成される例であり、GOPは15である。GOP単位においては、必ずIピクチャから始めることで、GOPをデコード可能な単位と解することができる。以上のような特徴から、Iピクチャは、通常、他のピクチャに比べてデータ量(データサイズ)が大きい。
セグメント502は、映像データのストリーミングにおいてデコード可能な単位であり、1セグメントが1GOPで構成される場合の例である。チャンク503、504は、メディアフォーマットの規格であるCommon Media Application Format(CMAF)により定義されるチャンクの例である。チャンクは、セグメントをさらに細かい時間長(通常は、1秒未満)に分割して映像データを格納可能としたものである。チャンクの時間長をチャンク長と称する場合もある。CMAF準拠のサーバはストリーミングデータをチャンクごとに出力・配信することで,低遅延映像ストリーミングを実現する。一般的に低遅延映像配信で用いられるCMAF準拠セグメントにおいて、チャンク長は固定長である。チャンク503は、チャンク長が固定長に設定されている場合の例であり、セグメント内のすべてのチャンク長は同じである(例えば、0.5秒)。通常、ユーザなどがチャンク長の設定は時間長(秒指定)で行うが、チャンク長は、設定した時間長に送信されるピクチャ数(画像フレーム数)と解することもできる。例えば、チャンク長を1秒にした場合は、チャンク長は、画像フレームレートの値(1秒間の送信画像フレーム数)と解することもできる。本実施形態においては、チャンク長は時間長とし、例えばサーバ1のストリーミングデータ生成部10が決定する。
チャンク長が固定長に設定されている場合、チャンクごとに格納されているピクチャデータの種類やメディアデータの種類が異なると、チャンク長は同じだが、データ量(データサイズ)に違いが生じることがある。例えば、通常、IピクチャはPピクチャよりもデータサイズが大きいため、Iピクチャが格納されているチャンクのデータサイズは他(例えばPピクチャのみ格納したもの)に比べて増大する傾向にある。そのため、チャンクごとにデータサイズが異なり、チャンクごとにデータのダウンロードに要する時間にばらつきが発生する可能性がある。特にデータサイズの大きなIピクチャが格納されているチャンクのダウンロードにおいては大きな遅延を生じさせる可能性があり、さらにプロキシサーバなどを介するとその影響は大きくなる可能性がある。
本実施形態においては、セグメント内のチャンク長(時間長)を可変とし、サーバ1は、チャンクごとにチャンク長を決定し、決定したチャンク長のチャンクを生成する。チャンク504は、セグメント内のチャンク長(時間長)を可変とした場合の例であり、同一セグメント内にチャンク長の異なるチャンクが含まれる可能性がある。なおチャンク長は、時間ではなく、画像フレーム数として定義することでもよい。
図3は、実施形態に係るストリーミングデータのセグメントとチャンクのデータ構成を示す図であり、CMAF準拠のセグメント、チャンクのデータ構造を示している。セグメント511はセグメントの構成を示し、CMAF準拠のセグメント(CMAF.m4s)には、Segment Type Box(styp)と呼ばれるセグメントの種類を示すヘッダの後に1以上のチャンクが続いて格納される。
チャンク512は、チャンクの構成を示し、各チャンクは、ピクチャデータ本体を格納するMedia Data Box(mdat)とmdatに関するメタ情報を格納するMovie Fragment Box(moof)との1つずつで構成されている。moofには同じチャンクのmdatに格納されるピクチャデータのデータサイズなどの情報を入れることができる。データサイズには通常、moofのデータサイズが含められる。サーバ1はストリーミングデータをチャンクごとに出力・配信し、ビューワ20は取得したチャンクをデコード機能に入力することで映像コンテンツを出力し、ユーザが視聴することができる。
図4は、実施形態に係るサーバのストリーミングデータ生成部の構成例を示す機能ブロック図である。
ストリーミングデータ生成部10は、ピクチャデータ及びそのメタ情報をピクチャデータ毎に受信する手段と、受信した情報に応じて、ピクチャデータを格納するチャンクのチャンク長を決定する制御部100と、制御部100で決定したチャンク長でピクチャデータのパッケージングを行い、パッケージングされたピクチャデータをチャンク(またはセグメント)として出力するパッケージ部120と、を備えている。
制御部100は、ピクチャデータ及びメタ情報を受信するデータ受信部110と、データ出力部106から入力されるデータ出力状況(フィードバック情報)などに基づいて新しいチャンク生成の可否を判定するチャンク生成判定部101と、ピクチャデータからピクチャ情報(ピクチャの種類やデータサイズなど)を抽出するピクチャ情報抽出部102と、ピクチャデータを一時的に格納するピクチャバッファリング部103と、フィードバック情報を基にメタ情報を更新するメタ情報更新部104と、更新済みのメタ情報及びピクチャ情報などに基づいてチャンク毎にチャンク長を決めたり算出したりするチャンク長決定部105と、パッケージ部120にチャンク長とピクチャデータを出力しチャンク生成判定部101にフィードバック情報を出力するデータ出力部106とを備えている。
ピクチャ情報は、ピクチャの種類やデータサイズなどの情報であり、ピクチャデータを解析して抽出することでもよい。メタ情報は、映像データの解像度や、フレームレート(画像フレームレート)、平均ビットレート、GOPなどの情報である。フレームレートは、例えば1秒間にデータ受信部110が受信する画像フレーム数(ピクチャ数)であってもよい。平均ビットレートは、例えば過去にデータ受信部110が受信した全フレーム(ピクチャ)分のデータサイズの秒平均やチャンクごとの平均などであってもよい。また平均ビットレートは、Iピクチャ以外のピクチャデータの平均であってもよく、任意の平均ビットレートを定義できる。フィードバック情報は、データ出力部106が生成し出力する情報であり、例えば、セグメントにおいてどの程度のチャンクが出力されたかといった情報であってもよい。またデータ出力部106は、チャンクをパッケージ部120に出力したタイミングの情報をフィードバック情報として出力することでもよい。
パッケージ部120は、データ出力部106から受け取ったチャンク長に基づいて、データ出力部106から入力されたピクチャデータのパッケージング(チャンク単位にピクチャデータを格納)を行うパッケージ処理部121を備えている。パッケージ処理部121が生成するパッケージングデータは基本的にはチャンク単位のデータとなり、パッケージ処理部121の出力タイミングによって出力するデータはチャンク単位またはセグメント単位とすることでもよい。パッケージ処理部121は、パッケージングデータを、図示せぬ通信部などへ出力し、通信部からネットワーク4へ出力する。
(第1の実施形態)
第1の実施形態においては、ストリーミングデータを生成し、出力するサーバが、チャンクを生成する時にチャンク長を決定する例を示す。
(第1の実施形態)
第1の実施形態においては、ストリーミングデータを生成し、出力するサーバが、チャンクを生成する時にチャンク長を決定する例を示す。
図5は、第1の実施形態に係るストリーミングデータ生成部の処理動作例を示すフローチャートである。
ユーザが受信装置2のビューワ20で、サーバ1の提供するストリーミングコンテンツを視聴しているとする。ストリーミングコンテンツは、例えばライブカメラで撮影される映像データをサーバ1がネットワーク4経由で受信し、サーバ1によって受信装置2に配信されている。サーバ1は、映像データを受信すると映像符号化部11で符号化し、ピクチャデータを得る。データ受信部110は、ピクチャデータとメタ情報を受信すると、それらをチャンク生成判定部101に入力する(ステップS101)。
チャンク生成判定部101は、新しくチャンクを生成するかどうかを判定する(ステップS102)。新しいチャンク生成の判断は、データ受信部110からのピクチャデータ、メタ情報や、データ出力部106からのフィードバック情報に基づいて行うことでもよい。より具体的には、チャンク生成判定部101は、フィードバック情報のチャンクもしくはセグメントを出力されたタイミングに基づいて、データ出力部106がチャンクもしくはセグメントを出力したことを認識した時に、新しくチャンクを生成すると判断することでもよい。またチャンク生成判定部101は、データ受信部110が受信したピクチャデータを解析することにより、例えばデータ量の大きいピクチャ(例えばIピクチャ)を受信したことを認識した時、新しくチャンクを生成すると判断することでもよい。チャンク生成判定部101は、データ受信部110が受信したピクチャデータを全て解析することでもよいし、任意のタイミングで解析することでもよい。チャンク生成判定部101は、予めしきい値などを図示せぬメモリなどに設定しておき、しきい値とピクチャデータのデータサイズを比較してデータ量の大小を判断することでもよい。また、チャンク生成判定部101は、受信したピクチャデータの種類によって、新しくチャンクを生成すると判断することでもよい。例えば、チャンク生成判定部101は、Iピクチャを受信したときは、常に新しくチャンクを生成すると判断することでもよい。
またチャンク生成判定部101は、データ出力部106からデータ出力状況に関わるフィードバック情報を取得した時に、データ出力状況によって、新しいチャンクを生成するか否か判断してもよい。具体的には、チャンク生成判定部101は、データ出力部106の図示せぬバッファ(ピクチャバッファリング部103でもよい)に格納されているチャンクデータが多い場合は、ビューワ20までのデータ伝送速度が低速であると判断して、新しいチャンクを生成することを決定する。一方、データ出力部106の図示せぬバッファに格納されているチャンクデータが少ない場合は、ビューワ20までのデータ伝送速度が高速であると判断して、新しいチャンクの生成を控えることを決定するなどでもよい。
新しいチャンクの生成を行うと判断した場合、チャンク生成判定部101はピクチャデータをピクチャ情報抽出部102に送る。また、データ受信部110から取得したメタ情報とデータ出力部106から取得したフィードバック情報とをメタ情報更新部104に入力する(ステップS102のYES)。
ピクチャ情報抽出部102は、ステップS102におけるチャンク生成判定部101のチャンク生成によって挙動が異なる。新しいチャンクの生成を行わない場合は、直ちにピクチャデータをピクチャバッファリング部103に入力する(ステップS102のNO、S106)。一方、新しいチャンクの生成を行う場合はピクチャデータからピクチャ情報を抽出しチャンク長決定部105に入力する(ステップS103)またメタ情報更新部104は、チャンク生成判定部101からメタ情報とフィードバック情報を受信し、それらを基にメタ情報を更新しチャンク長決定部105に入力する(ステップS104)。なお、ステップS103、ステップS104の処理は並列に動作させることでもよい。
次に、チャンク長決定部105は、メタ情報更新部104から受信した更新済みのメタ情報、ピクチャ情報抽出部102から受信したピクチャ情報、フィードバック情報などに基づいて、新しく生成するチャンクのチャンク長を決定する(ステップS105)。例えば、チャンク長決定部105は、ピクチャ情報から受信したピクチャがデータサイズの大きなピクチャ(例えばIピクチャ)であることを認識した場合、固定長として設定されているチャンク長よりもチャンク長を小さく設定することでもよい。
またチャンク長決定部105は、更新済みのメタ情報から取得した映像データ情報(解像度やフレームレート、平均ビットレート、GOP長など)や、フィードバック情報(データ出力状況)に基づいて、現在セグメントのうち、どのピクチャデータまでがチャンクとして出力されたかを認識し、現在セグメントの残りのデータ量によってチャンク長を決定することでもよい。このとき、例えば1チャンクに含まれるビット数(データ量、データサイズ)が、平均ビットレートを超えないようにチャンク長を決定することでもよい。
例えばチャンク長決定部105は、フィードバック情報からデータ出力されていないピクチャがデータサイズの小さなピクチャのみ(例えばIピクチャ以外のピクチャのみ)であると認識した場合は、チャンク長を大きくしてもチャンクサイズは大きくならないことから、新しく生成するチャンクのチャンク長を大きく設定するように決定してもよい。また、チャンク長決定部105は、フィードバック情報からデータ出力されていないピクチャにデータサイズの大きなピクチャ(例えばIピクチャ)が含まれ、新しく生成するチャンクにデータサイズの大きなピクチャが含まれると判断した場合は、チャンク長を大きくするとチャンクサイズが大きくなり、受信装置2におけるチャンクのダウンロードの遅延時間が大きくなることから、新しく生成するチャンクのチャンク長を小さく設定してもよい。またチャンク生成判定部101が、サーバ1からビューワ20までのデータ伝送速度が低速であると判断した時には、チャンク長決定部105は、固定長として設定されたチャンク長の半分の長さにするなど、よりチャンク長を小さく設定することでもよい。
さらに、チャンク長決定部105は、チャンク長を決定する際に、同一セグメント内の出力済みのチャンク数(フィードバック情報に含まれていてもよい)を考慮することでもよい。例えば、チャンク長を短くするとそのチャンクの送信時間を短くすることはできるが、セグメント内のチャンク数が増える。各チャンクにはメタデータ(図3のチャンク512のmoof)が付加されるため、チャンク数が増えると同時にオーバヘッドであるメタデータが増加し、その結果1セグメントで送信するべきデータ量(データサイズ)が増加する。このような場合、チャンク長決定部105は、1セグメント内のデータ量をなるべく抑制するように、チャンク数が大きくならないようにチャンク長を決定することが望ましい。すなわちチャンク長決定部105は、1つのチャンクのデータサイズを可能な限り大きくするようにチャンク長を決定するようにしてもよい。この場合、データサイズの上限は、平均ビットレートなどの情報に基づいて決定することでもよい。また例えば、チャンク長決定部105は、フィードバック情報から取得した同一セグメント内の出力済みのチャンク数があるしきい値よりも大きくなった場合には、以降、同一セグメントにおいては新しくチャンクを生成しないようにチャンク長を決定するようにしてもよい。
またチャンク長決定部105は、上記のチャンク長の決定、設定処理において、解像度やフレームレート、平均ビットレートなどの映像データ情報を考慮してチャンク長を決定することでもよい。例えば、チャンク生成判定部101が、セグメントのうちデータ出力されていないピクチャの種類がデータサイズの小さなピクチャのみ(例えばIピクチャ以外のピクチャのみ)であることを認識したが、同時に各ピクチャの平均ビットレートが高くなっている場合は、ピクチャの種類によらず、固定長として設定されたチャンク長よりもチャンク長を小さくするように設定することでもよい。
またチャンク長決定部105は、ピクチャ情報から得たピクチャの種類やデータサイズなどに基づいて、チャンク毎に格納するピクチャデータに応じたチャンク長を決定することでもよい。具体的には、チャンク長決定部105は、受信したピクチャの種類がデータサイズの大きなIピクチャであることを認識した場合に、固定長として設定されたチャンク長の半分の長さにするなど、よりチャンク長を小さく設定するなどが考えられる。
さらにチャンク長は、例えば平均ビットレートなどに基づいて、新しく生成されるチャンクに将来格納されるピクチャのデータサイズを推測して、推測したデータサイズに基づいてチャンク長を決定してもよい。例えば新しく生成されるチャンクに格納されると推測される総ビット数(チャンクのデータサイズ)が、予め設定した第1のしきい値を超えないように、将来格納されるピクチャのフレーム数を決定することでもよい。また推測したデータサイズのしきい値超過量を定める第2のしきい値を設定してもよい。この場合、推測したデータサイズが第1のしきい値を超えたとしても、第2のしきい値を下回っていたら推測したデータサイズ分のチャンク長を新しく生成されるチャンクのチャンク長に決定する。また、例えば大、中、小のようにチャンク長を予めいくつか決めておき、受信したピクチャの種類やフィードバック情報などによって、チャンク長を自動的に選択することでもよい。例えば、チャンク長決定部105は、Iピクチャを受信したらチャンク長に「小」を選択するなどでもよい。チャンク生成判定部101が、フィードバック情報から、サーバ1からビューワ20までのデータ伝送速度が高速であると判断した場合は、チャンク長決定部105は、チャンク長に「大」を選択するなどでもよい。
またチャンク長決定部105は、フィードバック情報からデータ出力部106によるデータ出力速度を算出し、データ出力速度によって、チャンク長を決定してもよい。具体的には、チャンク長決定部105は、データ出力部106のデータ出力速度が大きい場合は、サーバ1からビューワ20までのデータ伝送速度が高速であると判断して、チャンク長を可能な限り長くし、データ出力部106のデータ出力速度が小さい場合は、サーバ1からビューワ20までのデータ伝送速度が低速であると判断して、チャンク長を可能な限り小さくするなどでもよい。
ピクチャバッファリング部103では受け取ったピクチャデータ順にバッファにピクチャデータを格納する(ステップS106)。データ出力部106は、データをチャンク出力するかどうかを判断する(ステップS107)。具体的には、データ出力部106は、チャンク長決定部105からチャンク長を受け取ったら、チャンクを出力すると判断することでもよい。データ出力部106は、チャンクを出力しないと判断した場合は次のピクチャデータの受信処理をする(ステップS107のNO)。データ出力部106は、データ出力すると判断した場合は、ピクチャバッファリング部103から決定したチャンク長分のピクチャデータを取り出し、チャンク長とピクチャデータをパッケージ部120に出力する(ステップS108)。それと同時にデータ出力部106は、現在セグメント中のどの程度チャンク出力したか、セグメントもしくはGOP先頭のIピクチャから以降どの程度のBピクチャ、Pピクチャが出力されたかなどデータ出力状況のフィードバック情報をチャンク生成判定部101に出力する(ステップS109)。
パッケージ処理部121は、チャンク長及びピクチャデータを受信すると、受信したチャンク長で受信したピクチャデータのパッケージングを行い、チャンク(またはセグメント)を生成し出力する(ステップS110)。以上の手順により出力されるチャンク・セグメントはCMAFのフォーマットに準拠するため、受信装置2のビューワ20は、例えばCMAFに準拠していれば、特に修正を必要とすることなく本実施形態により生成、出力されたチャンクを受信して、ストリーミングコンテンツを表示することが可能である。
以上のようにサーバ1は、チャンク長を可変に設定することで、出力するチャンク間のデータサイズのばらつきをなくすことが可能となり、受信装置2によるダウンロードの際に、データサイズの大きな特定のチャンクによる大きな遅延を防ぐことが可能となる。
企業や自治体のネットワーク内からインターネットに接続する際は通常、複数のプロキシサーバを経由する必要があり、プロキシサーバを経由することで通信の応答に影響(遅延)を生じさせる可能性がある。また通常、セグメント内のチャンク分割は時間単位かつ固定長で行われるため、データサイズが大きい特定のチャンクの取得に時間を要するが、特にプロキシサーバを介するとその影響は大きくなり、CMAFが志向する低遅延映像配信を行えないことがある。本実施形態においては、このようなプロキシサーバを介したネットワーク環境下において特に効果が顕著となり、低遅延映像配信が可能となる。
図6は、同第1の実施形態に係るストリーミングデータのサーバ送信とビューワ受信との関係を示す図である。図6(a)はセグメント配信(セグメント長4秒)による例を示し、図6(b)はCMAF準拠のフォーマットによる固定長のチャンクの配信例(セグメント長4秒、チャンク長1秒)、図6(c)はCMAF準拠のフォーマットにおいてチャンクを可変長とした場合の本実施形態による配信例を示す。
図6(a)で示すように、セグメント配信による方法では、サーバがセグメント4を生成送信してから、ビューワがセグメント4を受信して、ユーザが視聴可能になるまでに4+α+β秒必要となる。この内訳は、セグメント4のサーバによる送信時間4秒と、プロキシなどによる処理などを含めたネットワーク遅延α秒、上記以外のビューワのダウンロード時間などの処理時間β秒である。
図6(b)で示すように、チャンク長を固定にした場合は、サーバがセグメント4のチャンク4Aを生成送信してから、ビューワがチャンク4Aを受信して、ユーザが視聴可能になるまでに1+α+β秒必要となる。この内訳は、チャンク4Aのサーバによる送信遅延時間1秒と、プロキシなどによる処理などを含めたネットワーク遅延α秒、上記以外のビューワのダウンロード時間などの処理時間β秒である。従って、図6(b)においては、図6(a)に比較して、サーバによる送信時間、ネットワーク遅延α秒、処理時間β秒が短くなり、チャンク4A(セグメント4の先頭部分に相当)の視聴可能時刻は改善される。
図6(c)は、本実施形態による図6(b)におけるチャンク4Aのチャンク長を短くした場合の例であり、チャンク4Aのチャンク長を短くした分だけサーバによる送信遅延時間は、図6(b)に示した1秒よりも短くなる。また、ネットワーク伝送遅延α秒も同様、送信するデータサイズを小さくすると小さくなることから、図6(c)においては図6(b)の場合よりもネットワーク伝送遅延α秒を縮小することが可能である。この効果は、例えばサーバ1から受信装置2へのデータ送信にプロキシサーバ3を用いる場合に特に顕著となる。また、処理遅延β秒も同様、送信するデータサイズを小さくすると小さくなることから、本実施形態による図6(c)においては、図6(b)の場合よりも縮小することが可能である。従って、図6(c)においては、図6(b)に比較して、サーバによる送信時間、ネットワーク遅延α秒、処理時間β秒が短くなり、チャンク4Aの視聴可能時刻は改善される。
図7は、同第1の実施形態に係るチャンクの視聴可能時間を示す図である。
ピクチャデータ521は、横軸をデータサイズとして、ピクチャ1であるIピクチャから連続するピクチャの例である。ピクチャ2以降は、例えばBピクチャもしくはPピクチャである。ピクチャデータ521において各ピクチャの横幅はそれぞれデータサイズを示し、Iピクチャであるピクチャ1のデータサイズが最も大きいことを示している。チャンク522は、横軸を時間として、ピクチャデータ521をチャンク長が固定長、可変長とした場合のそれぞれのチャンクの例を示している。チャンク522が固定長の場合、ピクチャデータ521を1つのチャンクで格納する。チャンク522が可変長の場合、ピクチャデータ521は、図5のステップS105によって設定されるチャンク長で2つ以上のチャンクに分けられる。チャンク522において、チャンク長を固定長とした場合よりも可変長とした場合の方が、ユーザによる視聴可能時間を小さくできることが示される。
図8は、同第1の実施形態に係るストリーミングデータのセグメントとチャンクとの関係例を示す図である。図8(a)は固定長でチャンク化されたセグメントの例、図8(b)は可変長でチャンク化されたセグメントの例である。
図8(a)が示すように、固定長でチャンク化されたセグメントではすべてのチャンクが固定長(本例では0.5秒)に設定される。一方、図8(b)が示すように、本実施形態におけるセグメントは、可変長でチャンク化するため、異なるチャンク長のチャンクが含まれる。例えば、データサイズが大きいIピクチャが格納されたチャンクは短く(本図では0.1秒)、その他のチャンクでは図5のフローチャートによって決められるチャンク長のチャンクとなる。連続して送信されるピクチャデータの種類やデータサイズによっては、チャンク長が0.5秒よりも大きく0.6秒になったり、0.5秒より小さい値になったりすることもある。しかしながら、各チャンクのデータサイズについては、図5のステップS105において、例えば平均ビットレートをしきい値としてチャンク長を決定することにより、チャンクのデータサイズのばらつきを小さく抑えることができる。
図8(c)、図8(d)は1セグメント内にデータサイズの大きなデータ(例えばIピクチャ)が複数ある場合の例であり、図8(c)はセグメントが固定長でチャンク化された場合の例、図8(d)はセグメントが可変長でチャンク化された場合の例である。図5のステップS102において、データ受信部110からのピクチャデータの種類に基づいて、チャンクを生成するか否かを決定することによって、図8(d)のようにセグメント途中にIピクチャが入っている場合でも、Iピクチャを格納するチャンク長を可変に設定することができ、チャンクごとのデータサイズのばらつきを抑えることができる。本実施形態により図8(d)のような場合が可能になることで、HTTP/1.1 GETなどによるセグメントの最初のチャンクからの配信に加え、セグメント途中からのコンテンツ取得(HTTP Range GETなど)も想定し、GOP単位でチャンクを区切ることができる。これによりビューワ20は複数のチャンクを待つことなく、受信したチャンクのピクチャデータをデコードして、出力、表示することが可能となる。
以上のように本実施形態では、パッケージ処理部121でCMAFなど各低遅延メディアフォーマットに準拠した構造のチャンクもしくはセグメントを出力することで、受信装置2は、ブラウザのような標準環境などで特に改修などの必要なくチャンク単位での低遅延映像ストリーミングコンテンツの視聴が可能となる。
以上のように、第1の実施形態のサーバ1(ストリーミングデータ生成部10)によれば、チャンク毎にチャンク長を設定しパッケージングすることで、低遅延で映像ストリーミングコンテンツの配信を行うことが可能となる。
(第2の実施形態)
本実施形態においては、データ出力部106からピクチャデータを出力する直前にチャンク長を決定する例を示す。
本実施形態においては、データ出力部106からピクチャデータを出力する直前にチャンク長を決定する例を示す。
図9は、第2の実施形態に係るストリーミングデータ生成部の処理動作例を示すフローチャートである。
第1の実施形態と同様、サーバ1は、映像データを受信すると映像符号化部11で符号化し、ピクチャデータを得る。データ受信部110は、ピクチャデータとメタ情報を受信すると、チャンク生成判定部101に入力する(ステップS201)。チャンク生成判定部101は、受信したデータをピクチャバッファリング部103に格納する(ステップS202)。チャンク生成判定部101は、受信した全ピクチャのデータサイズとピクチャ数とをカウントする(ステップS203)。チャンク生成判定部101は、しきい値を図示せぬメモリに備えておき、カウントしたデータサイズがしきい値を上回ったタイミングで、チャンクを生成することを決定する(ステップS204のYES)。チャンク生成判定部101は、チャンクを生成することを決定した時のピクチャ数のカウント値と画像フレームレートからチャンク長を算出する(ステップS205)。ステップS206以降は、図5のステップS108以降と同様であるため説明を省略する。なおステップS204でチャンク生成判定部101が用いたしきい値は、予め設定しておいてもよいし、例えば計算する平均ビットレートをしきい値として逐次的に設定してもよい。
以上の手順により、サーバ1(ストリーミングデータ生成部10)は、チャンクサイズに基づいてチャンクを生成する直前にチャンク長を決定することが可能となる。
以上に述べた少なくとも1つの実施形態によれば、ストリーミングデータのチャンクごとにチャンク長を決定するストリーミング映像配信のストリーミングサーバ、送信方法及びプログラムを提供することができる。
本発明のいくつかの実施形態を説明したが、これらの実施形態は例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができ、また、各実施形態における技術要素を別の実施形態に適用することができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。さらにまた、請求項の各構成要素において、構成要素を分割して表現した場合、或いは複数を合わせて表現した場合、或いはこれらを組み合わせて表現した場合であっても本発明の範疇である。また、複数の実施形態を組み合わせてもよく、この組み合わせで構成される実施例も発明の範疇である。また、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
また、図面は、説明をより明確にするため、実際の態様に比べて、各部の幅、厚さ、形状等について模式的に表される場合がある。ブロック図においては、結線されていないブロック間もしくは、結線されていても矢印が示されていない方向に対してもデータや信号のやり取りを行う場合もある。フローチャート、シーケンスチャートなどに示す処理は、ICチップ、デジタル信号処理プロセッサ(Digital Signal ProcessorまたはDSP)などのハードウェアもしくはマイクロコンピュータを含むコンピュータなどで動作させるソフトウェア(プログラムなど)またはハードウェアとソフトウェアの組み合わせによって実現してもよい。また請求項を制御ロジックとして表現した場合、コンピュータを実行させるインストラクションを含むプログラムとして表現した場合、及び前記インストラクションを記載したコンピュータ読み取り可能な記録媒体として表現した場合でも本発明の装置を適用したものである。また、使用している名称や用語についても限定されるものではなく、他の表現であっても実質的に同一内容、同趣旨であれば、本発明に含まれるものである。
1…サーバ、2…受信装置、3…プロキシサーバ、4…ネットワーク、10…ストリーミングデータ生成部、11…映像符号化部、20…ビューワ、100…制御部、101…チャンク生成判定部、102…ピクチャ情報抽出部、103…ピクチャバッファリング部、104…メタ情報更新部、105…チャンク長決定部、106…データ出力部、120…パッケージ部、121…パッケージ処理部。
Claims (9)
- ピクチャデータをチャンクに分割したチャンクデータをストリーミングデータとして出力するストリーミングサーバであって、
前記チャンクの時間長であるチャンク長を算出するチャンク長決定部と、
前記ピクチャデータを前記チャンク長でチャンクに分割してチャンクデータを生成するデータ生成部とを備えるストリーミングサーバ。 - 前記ピクチャデータを受信するごとに新しいチャンクを生成するか否かを判断するチャンク生成判定部を備える請求項1に記載のストリーミングサーバ。
- 前記チャンク長決定部は、前記チャンクごとにチャンク長を決定する請求項1または請求項2のいずれか1項に記載のストリーミングサーバ。
- 前記チャンク長決定部は、前記チャンクに含めるピクチャデータのデータサイズに基づいてチャンク長を決定する請求項1乃至請求項3のいずれか1項に記載のストリーミングサーバ。
- 前記チャンク長決定部は、前記チャンクデータの出力状況に基づいてチャンク長を決定する請求項1乃至請求項4のいずれか1項に記載のストリーミングサーバ。
- 前記チャンク生成判定部は、前記ピクチャデータの種類によって、前記新しいチャンクを生成するか否かを判断する請求項2に記載のストリーミングサーバ。
- 前記チャンク生成判定部は、前記チャンクデータの出力状況に基づいて、前記新しいチャンクを生成するか否かを判断する請求項2または請求項6のいずれか1項に記載のストリーミングサーバ。
- ピクチャデータをチャンクに分割したチャンクデータをストリーミングデータとして出力するストリーミングデータの送信方法であって、
前記チャンクの時間長であるチャンク長を算出し、
前記ピクチャデータを前記チャンク長でチャンクに分割してチャンクデータを生成する送信方法。 - コンピュータが、受信したピクチャデータをチャンクに分割したチャンクデータをストリーミングデータとして出力するためのプログラムであって、
前記チャンクの時間長であるチャンク長を算出し、
前記ピクチャデータを前記チャンク長でチャンクに分割してチャンクデータを生成するプログラム。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2021110018A JP2023007048A (ja) | 2021-07-01 | 2021-07-01 | ストリーミングサーバ、送信方法及びプログラム |
US17/682,801 US11910033B2 (en) | 2021-07-01 | 2022-02-28 | Streaming server, transmission method, and program |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2021110018A JP2023007048A (ja) | 2021-07-01 | 2021-07-01 | ストリーミングサーバ、送信方法及びプログラム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2023007048A true JP2023007048A (ja) | 2023-01-18 |
Family
ID=84785726
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2021110018A Pending JP2023007048A (ja) | 2021-07-01 | 2021-07-01 | ストリーミングサーバ、送信方法及びプログラム |
Country Status (2)
Country | Link |
---|---|
US (1) | US11910033B2 (ja) |
JP (1) | JP2023007048A (ja) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111698262B (zh) * | 2020-06-24 | 2021-07-16 | 北京达佳互联信息技术有限公司 | 带宽确定方法、装置、终端及存储介质 |
Family Cites Families (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8301733B2 (en) * | 2010-06-30 | 2012-10-30 | Unicorn Media, Inc. | Dynamic chunking for delivery instances |
US8677428B2 (en) * | 2010-08-20 | 2014-03-18 | Disney Enterprises, Inc. | System and method for rule based dynamic server side streaming manifest files |
US8863182B1 (en) * | 2012-02-17 | 2014-10-14 | Google Inc. | In-stream video stitching |
AU2013248891B2 (en) * | 2012-04-18 | 2017-02-16 | Google Llc | Method and system for inserting content into streaming media at arbitrary time points |
US8495675B1 (en) * | 2012-07-30 | 2013-07-23 | Mdialog Corporation | Method and system for dynamically inserting content into streaming media |
EP2908535A4 (en) | 2012-10-09 | 2016-07-06 | Sharp Kk | Content transfer device, content playback device, content distribution system, method for controlling a content transfer device, method for controlling a content playback device, control program and recording medium |
US9680689B2 (en) * | 2013-02-14 | 2017-06-13 | Comcast Cable Communications, Llc | Fragmenting media content |
US20150350622A1 (en) * | 2014-05-30 | 2015-12-03 | Apple Inc. | Packed i-frames |
US10873781B2 (en) * | 2017-06-13 | 2020-12-22 | Comcast Cable Communications, Llc | Video fragment file processing |
US10820022B1 (en) * | 2018-05-03 | 2020-10-27 | Amazon Technologies, Inc. | Low latency playback for chunked media segments |
JP7105675B2 (ja) | 2018-11-02 | 2022-07-25 | 株式会社東芝 | 送信装置、サーバ装置、送信方法およびプログラム |
US10778938B2 (en) * | 2018-12-20 | 2020-09-15 | Hulu, LLC | Video chunk combination optimization |
-
2021
- 2021-07-01 JP JP2021110018A patent/JP2023007048A/ja active Pending
-
2022
- 2022-02-28 US US17/682,801 patent/US11910033B2/en active Active
Also Published As
Publication number | Publication date |
---|---|
US11910033B2 (en) | 2024-02-20 |
US20230007315A1 (en) | 2023-01-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9832534B2 (en) | Content transmission device and content playback device | |
EP3096526B1 (en) | Communication apparatus, communication data generation method, and communication data processing method | |
CN107634930B (zh) | 一种媒体数据的获取方法和装置 | |
US11284135B2 (en) | Communication apparatus, communication data generation method, and communication data processing method | |
US20180338168A1 (en) | Splicing in adaptive bit rate (abr) video streams | |
US12003556B2 (en) | Methods of streaming media file data and media file servers | |
US10924524B2 (en) | Communication devices, communication data generation method, and communication data processing method | |
US10019448B2 (en) | Methods and systems for providing file data for media files | |
US11095699B1 (en) | Streaming media file management | |
US11910033B2 (en) | Streaming server, transmission method, and program | |
US20160366453A1 (en) | Communication apparatus, communication data generation method, and communication data processing method | |
US20140237077A1 (en) | Methods and systems for providing file data for video files | |
US11949945B2 (en) | Dynamic creation of low latency video streams in a live event | |
KR102210437B1 (ko) | 미디어 컨텐츠 전송 제어 방법, 이를 위한 장치 | |
CN115756329A (zh) | 一种数据处理方法及装置、存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20230313 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20240322 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20240409 |
|
A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20240610 |