JP2023161219A - 送信装置、受信装置及びそれらのプログラム - Google Patents

Abstract

【課題】映像の伝送遅延を低減できる送信装置を提供する。【解決手段】送信装置１は、仮想ＣＰＢによるビットレート制御を映像信号に施す映像符号化部１１と、ＣＢＲ以上のビットレートで出力した映像信号からチャンクを構成するチャンク構成部１２と、所定の制御情報を生成する制御情報生成部１３と、チャンク及び制御情報をそれぞれパケットに多重化するトランスポート多重化部１４と、優先データとチャンクと非優先データとを優先度順に多重信号として送信するトランスポート送信部１７と、を備える。【選択図】図１

Description

本発明は、送信装置、受信装置及びそれらのプログラムに関する。

放送サービスのように、映像信号、音声信号、データ等の複数コンポーネントを含む多重信号を扱う伝送システムにおいては、一般に、伝送路の伝送容量の範囲内で、各コンポーネントに一定範囲の伝送容量を割り当てる運用を行う（非特許文献１）。図１３に示すように、従来の伝送システムでは、映像信号に割り当てられた帯域を上限とする一定のビットレート（ＣＢＲ：Constant Bit Rate）で、映像信号の符号データ（符号化した映像信号）を送信する。また、従来の伝送システムでは、放送サービスを構成する複数コンポーネントの多重方式として、例えば、ＭＭＴ（MPEG Media Transport）方式（非特許文献２）やＤＡＳＨ／ＲＯＵＴＥ（Dynamic adaptive streaming over HTTP/ Real-Time Object Delivery over Unidirectional Transport）方式（非特許文献３）が用いられる。

図１４には、ピクチャ間の参照構造の一例を図示した。ここで、「Ｉ」がフレーム内圧縮を行うＩ（Intra）ピクチャ、「Ｐ」が前方のフレームを参照するＰ（Predictive）ピクチャ、「Ｂ」が前後のフレームを参照するＢ（Bidirectionally Predictive）ピクチャを表す。また、図１４の矢印は、先端側のピクチャが終端側のピクチャを参照することを示す。実際の映像符号化の処理においては、ピクチャの種類の違いや、量子化パラメータなどの調整によるビットレート制御によって、時間軸上で発生する映像信号の符号データ量に変動が生じる。通常、Ｉピクチャの符号データ量が最も大きく、Ｐピクチャの符号データ量が２番目に大きくなり、Ｂピクチャの符号データ量が最も小さくなる（図１６（ａ）参照）。

図１５に示すように、従来の送信装置が備える映像符号化部９は、映像信号を符号化する符号化処理部９０と、ＣＰＢ（Coded Picture Buffer）９１と、ＣＰＢ９１のバッファ使用量に応じて、ビットレート制御を行う符号化制御部９２とを備える。また、映像符号化部９には、ＣＢＲ及び最大ＣＰＢ遅延を、符号化パラメータとして設定する。そして、映像符号化部９は、図１６（ａ）～図１６（ｃ）に示すように、符号データのビットレートが常にＣＢＲ以下に収まるように、最大ＣＰＢ遅延の範囲で符号データを時間方向に平滑化して送信する。具体的には、符号化制御部９２は、ＣＰＢ９１からフィードバックされたバッファ使用量に基づいて、ＣＰＢ９１が溢れそうか（符号データをＣＢＲで送信し切れずに最大ＣＢＰ遅延を超過しないか）判定する。そして、符号化制御部９２は、ＣＰＢ９１が溢れそうな場合、映像信号の圧縮率を上げることで画質を低下させる（ビット量が低減）。一方、符号化制御部９２は、ＣＰＢ９１に余裕がある（符号データをＣＢＲかつ最大ＣＢＰ遅延の範囲内で送信し切ることができる）場合、映像信号の圧縮率を下げることで画質を向上させる（ビット量が増加）。このようにして、符号化制御部９２は、ＣＰＢ９１の出力が所定のビットレートを越えないように制御する。

なお、図１６（ａ）は、符号化処理部９０が出力する符号データ量を表す。また、図１６（ｂ）は、ＣＰＢ９１の出力となる、ＣＢＲで平滑化された符号データ量を表す。また、図１６（ｃ）は、送信装置が出力する符号データ量を表す。

近年、インターネット上の映像配信では、ＭＰＥＧ（Moving Picture Experts Group）－ＤＡＳＨ（Dynamic Adaptive Streaming over HTTP）やＨＬＳ（HTTP Live Streaming）など配信技術毎に異なっていたメディアコンテナ形式を統一するＣＭＡＦ（Common Media Application Format）の採用が進んでいる（非特許文献４）。ＣＭＡＦでは、メディアコンテナ形式をＩＳＯＢＭＦＦ（ISO Base Media File Format）ベースに統一することに加えて、配信の低遅延化を可能とする技術として、ＵＬＬ（Ultra Low Latency）配信を可能とするチャンク構造を規定している。ＣＭＡＦの基礎となっているＩＳＯＢＭＦＦを用いた動画配信では、チャンク構造を用いない場合、映像のＩピクチャを先頭に数から数十秒の時間尺のセグメントを構成して送信することが一般的である。一方、ＣＭＡＦ－ＵＬＬでは、映像のＩピクチャを必ずしも先頭としない数フレーム単位でのチャンク構造を構成して送信できる。今後、放送でもＣＭＡＦを採用することで、放送と通信の垣根を越えて共通のフォーマットでのコンテンツ配信が可能となり、放送・通信が融合したサービスの高度化が期待されている。

ＭＰＥＧ－ＤＡＳＨやＨＬＳのプレイヤ（受信装置）は、サービスの受信開始時、始めにセグメントの所在情報（セグメントを配信するサーバ上のＵＲＬなど）を含むリストを記載したマニフェストファイルをサーバに要求して取得する。そして、このマニフェストファイルに記載されたセグメントの所在情報に従って、セグメントを時系列順にサーバに要求して取得し、映像を再生する。このとき、回線状況の悪化等により、セグメントの取得に失敗したり、取得が完了するまでに時間がかかると、バッファアンダーフローによる映像の再生破綻が生じる可能性が増加する。このような映像の再生破綻を回避するため、プレイヤは、セグメントの取得失敗などが生じた場合に、プレイヤ内のバッファ時間を増加させて、より安定した再生ができるような調整を行う。

視聴者が任意の時間に視聴するＶＯＤ（Video On Demand）コンテンツでは、コンテンツを構成する全てのセグメントは事前にエンコードされたものであり、マニフェストファイルには全てのセブメントの所在情報を予め記載することができ、マニフェストファイルがコンテンツの途中で更新されることはない。一方、視聴者が生放送で視聴するライブ配信コンテンツでは、ライブエンコーダによって新たなセグメントが生成されるごとに、古いセグメントの情報を削除し、新たなセグメントの情報を追記する形でマニフェストファイルが更新される。なお、生放送の追いかけ視聴も可能とする場合には、古いセグメントの情報を削除せず、新たなセグメントの情報を追記するとともに再生開始セグメントを指示するポインタ情報の更新のみを行う場合もある。プレイヤは、定期的にマニフェストファイルを取得し、追記された最新のセグメントを取得しながら再生を行う。ライブ配信の場合も、プレイヤにおいてセグメントの取得失敗や取得が完了するまでに時間がかかる場合、バッファ長を大きくして映像破綻を防ぐ。つまり、プレイヤの内部により多くのセグメントをバッファすることとなるため、ライブ配信においては、カメラで撮影された映像がプレイヤの画面に表示されるまでのトータルの伝送遅延が増加することとなる。

ＣＭＡＦ―ＵＬＬでは、セグメントよりも時間尺の短いチャンクを用いることで、サーバへの要求や取得の単位であるファイル構成遅延が削減され、通信状況が良ければより低遅延な配信を実現しやすくなる。しかし、チャンクの取得失敗や取得が完了するまでに時間がかかる場合、プレイヤがバッファ量を増加させてトータルの伝送遅延が増加する原理はセグメント単位での配信の場合と変わらない。

ARIB TR-B39、"高度広帯域衛星デジタル放送運用規定（第二分冊）" ISO/IEC 23008-1、"High efficiency coding and media delivery in heterogeneous environments: MPEG media transport" ATSC Standard: A/331,"Signaling, Delivery, Synchronization, and Error Protection" ISO/IEC 23000-19、"Common media application format (CMAF) for segmented media" ARIB STD-B60、"デジタル放送におけるＭＭＴによるメディアトランスポート方式"

従来の送信装置は、図１５及び図１６に示すように、映像符号化部９の出力がＣＰＢ９１を介した上に、チャンク単位のメタデータを生成し、メタデータをヘッダ情報として先に送信してからチャンクを送信するためのチャンク構成処理の待ち時間が生じる。このため、送信装置の内部で、映像のＣＰＢ遅延（時間方向で変動する符号データ量を時間方向に平滑化するための遅延）に加えて、チャンク構成遅延が加わる。さらに、従来の受信装置では、映像復号部がチャンクを取得しようとしたときに該当チャンクが取得不可（未完成）であった場合に、映像の再生破綻を回避するためにバッファを増加させるので、映像が画面に提示されるまでの映像復号部内のバッファ処理により、トータルの伝送遅延が増加してしまう。なお、チャンクが取得不可となる原因は、放送波において映像コンポーネントに割り当てられた伝送容量を上限とする範囲内でチャンクを送信するために、チャンクを送り切るのに時間を要し、チャンク全体の受信が完了していない状態で、映像復号部が当該チャンクを取得しようとする場合がある。

そこで、本発明は、映像の伝送遅延を低減できる送信装置、受信装置及びそれらのプログラムを提供することを課題とする。

前記課題を解決するため、本発明に係る送信装置は、映像信号が入力され、入力された映像信号を符号化して送信する送信装置であって、映像符号化部と、制御情報生成部と、チャンク構成部と、多重化部と、送信部と、を備える構成とした。

かかる構成によれば、映像符号化部は、仮想ＣＰＢによるビットレート制御を前記映像信号に施し、ＣＰＢを介さずに、符号化した前記映像信号を予め設定したＣＢＲ以上のビットレートで出力する。つまり、映像符号化部は、仮想的にＣＰＢをエミュレートして、従来技術と同様のビットレート制御を行いつつ、実際の出力がＣＰＢを介さないので、バスなどの内部インタフェースが許す最大レートで映像信号を出力できる。このように、映像符号化部は、ＣＰＢを介さないので、ＣＰＢ遅延を低減できる。

チャンク構成部は、映像符号化部がＣＢＲ以上のビットレートで出力した映像信号からチャンクを構成し、構成したチャンクにメタデータをヘッダ情報として付加する。メタデータにはチャンクを構成する全ての映像フレームのデータサイズやタイムスタンプのリスト情報を含めるため、チャンク全体の符号化が完了したタイミングでメタデータが完成する。メタデータが完成すると、メタデータが付加されたチャンクを多重化部へ出力できる。

制御情報生成部は、ＣＢＲが記述された制御情報を生成する。
多重化部は、メタデータが付加されたチャンク及び制御情報をそれぞれ伝送パケットに多重化する。
送信部は、予め設定した伝送レート以下となるように、チャンクより優先度が高い制御情報を含む優先データと、チャンクと、チャンクより優先度が低い非優先データとを優先度順に多重信号として送信する。これにより、送信部は、従来技術に比べて、伝送路の帯域全体を活用して短時間でチャンクを伝送できる。

また、前記課題を解決するため、本発明に係る受信装置は、前記送信装置から多重信号を受信する受信装置であって、多重分離部と、マニフェストファイル生成部と、記憶部と、読出部と、映像復号部と、を備える構成とした。

かかる構成によれば、多重分離部は、多重信号から、所定の制御情報と、符号化された映像信号とで構成されたチャンクとを分離する。
マニフェストファイル生成部は、多重分離部が分離した制御情報に応じて、チャンクの所在情報が記述されたマニフェストファイルを生成する。また、マニフェストファイル生成部は、受信装置が新たなチャンクの受信を完了した場合、直ちにマニフェストファイルを更新する。

記憶部は、チャンク及びマニフェストファイルを記憶する。
読出部は、記憶部からチャンク及びマニフェストファイルを読み出す。
映像復号部は、マニフェストファイルを読出部に要求し、当該要求に応じてマニフェストファイルを読出部から取得し、取得したマニフェストファイルの所在情報が示すチャンクを時系列に要求及び受信して映像信号を復号する。

このように、送信装置は、ＣＢＲを介さずに最短時間でメタデータが付加されたチャンクを構成し、伝送路の帯域全体を活用して短時間で伝送することで、チャンクを受信装置の記憶部に素早く格納できるので、映像復号部からの取得の要求に素早く応じることができる。さらに、受信装置は、チャンクを受信すると直ちに記憶部に格納すると共に、チャンクが取得可能となると同時にマニフェストファイルを更新して、映像復号部からの要求に応じてチャンクを送信可能な状態にできる。従って、映像復号部において、受信装置にまだ届いていないチャンクを要求してチャンク取得が失敗する可能性を減少させ、映像破綻を回避するためのバッファ時間を必要以上に増加させることがなくなり、映像のトータルの伝送遅延を低減できる。

なお、本発明は、コンピュータを前記した送信装置又は受信装置として機能させるためのプログラムで実現することもできる。

本発明によれば、映像の伝送遅延を低減することができる。

実施形態に係る送信装置の構成を示すブロック図である。 図１の映像符号化部の構成を示すブロック図である。 実施形態において、優先度順の送信を説明する説明図である。 図１のトークン出力部の処理を示すフローチャートである。 図１のトランスポート送信部の割り込み処理を示すフローチャートである。 図１のトランスポート送信部におけるパケット送信処理の第１例を示すフローチャートである。 図１のトランスポート送信部におけるパケット送信処理の第２例を示すフローチャートである。 実施形態において、（ａ）及び（ｂ）は、優先度順に多重信号を送信したときの符号データ量を説明する説明図である。 実施形態において、（ａ）及び（ｂ）は、次以降のチャンクの送信が遅延する場合における符号データ量を説明する説明図である。 実施形態に係る受信装置の構成を示すブロック図である。 図１０の受信装置の動作を示すシーケンス図である。 参考例に係る受信装置の構成を示すブロック図である。 従来技術において、ＣＢＲを説明する説明図である。 従来技術において、ピクチャの種類を説明する説明図である。 従来技術において、映像符号化部の構成を示すブロック図である。 （ａ）～（ｃ）は、従来技術における送信装置の符号データ量を説明する説明図である。

（実施形態）
以下、本発明の実施形態について図面を参照して説明する。但し、以下に説明する実施形態は、本発明の技術思想を具体化するためのものであって、特定的な記載がない限り、本発明を以下のものに限定しない。また、同一の手段には同一の符号を付し、説明を省略する場合がある。

［送信装置の構成］
図１を参照し、実施形態に係る送信装置１の構成について説明する。
送信装置１は、映像信号が入力され、入力された映像信号を符号化して送信するものである。図１に示すように、送信装置１は、音声符号化部１０と、映像符号化部１１と、チャンク構成部１２と、制御情報生成部１３と、トランスポート多重化部（多重化部）１４と、チャンクキュー１５Ａと、優先データキュー１５Ｂと、非優先データキュー１５Ｃと、トークン出力部１６と、トランスポート送信部（送信部）１７とを備える。

音声符号化部１０は、音声信号が入力され、入力された音声信号を符号化するものである。例えば、音声符号化部１０は、ＡＡＣ（Advanced Audio Coding）、ＭＰＥＧ－Ｈ ３Ｄ Ａｕｄｉｏ、ＡＣ－４などの一般的な音声符号化方式で音声信号を符号化する。そして、音声符号化部１０は、符号化した音声信号をチャンク構成部１２に出力する。

映像符号化部１１は、仮想ＣＰＢによるビットレート制御を映像信号に施して、ＣＰＢを介さずに、符号化した映像信号を予め設定したＣＢＲ以上のビットレートで出力するものである。ここでは、映像符号化部１１は、映像信号が入力されると共に、最大ＣＰＢ遅延及びＣＢＲのビットレート値がパラメータとして入力される。

＜映像符号化部＞
図２を参照し、映像符号化部１１を詳細に説明する。
図２に示すように、映像符号化部１１は、符号化処理部１１Ａと、仮想ＣＰＢ１１Ｂと、符号化制御部１１Ｃとを備える。

符号化処理部１１Ａは、後記する符号化制御部１１Ｃからのビットレート制御に従って、映像信号を符号化するものである。例えば、符号化処理部１１Ａは、Ｈ．２６５／ＨＥＶＣ（High Efficiency Video Coding）、Ｈ．２６６／ＶＶＣ（Versatile Video Coding）、ＡＶＩ（Audio Video Interleave）などの一般的な映像符号化方式で映像信号を符号化する。そして、符号化処理部１１Ａは、符号化した映像信号を仮想ＣＰＢ１１Ｂに入力すると共に、ＣＰＢを介さずに、その映像信号をチャンク構成部１２に出力する。

仮想ＣＰＢ１１Ｂは、従来のＣＰＢ９１（図１５）をエミュレートするための仮想的なＣＰＢである。つまり、仮想ＣＰＢ１１Ｂは、従来のＣＰＢ９１とは異なり、実際に映像信号の符号データを平滑化して出力する機能を有していない。なお、仮想ＣＰＢ１１Ｂは、符号化制御部１１Ｃによって参照される。

符号化制御部１１Ｃは、仮想ＣＰＢ１１Ｂのバッファ使用量を参照し、符号化処理部１１Ａにおける符号化モードの選択や量子化パラメータの調整などのビットレート制御を行うものである。なお、符号化制御部１１Ｃのビットレート制御自体は、従来の符号化制御部９２（図１５）と同様のため、説明を省略する。

図２に示すように、映像符号化部１１では、従来技術と同様、仮想ＣＰＢ１１Ｂがバッファの状態を符号化制御部１１Ｃにフィードバックし、符号化制御部１１Ｃが符号化処理部１１Ａの出力ビットの発生量を制御する。一方、映像符号化部１１は、従来のＣＰＢ９１（図１５）を介さずに、映像信号の符号データをチャンク構成部１２に出力する。従って、従来の映像符号化部９の出力ビットレートα（図１５）がＣＢＲで制限されるのに対し、映像符号化部１１の出力ビットレートβ（図２）はＣＢＲに制限されることはない（β＞α）。その結果、チャンク構成部１２が、映像信号の符号データを内部インタフェースの最大レート（β）で遅滞なく出力できる。

図１に戻り、送信装置１の構成の説明を続ける。
チャンク構成部１２は、映像符号化部１１がＣＢＲ以上のビットレートで出力した映像信号から、メタデータを付加したチャンクを構成するものである。本実施形態では、チャンク構成部１２は、映像符号化部１１がＣＢＲ以上のビットレートで出力した映像信号と、音声符号化部１０が符号化した音声信号とからチャンクを構成する。具体的には、チャンク構成部１２は、映像信号について、複数フレームの集合をチャンクとして構成する。また、チャンク構成部１２は、音声信号について、前記した複数フレームの集合と同等区間のアクセスユニットをチャンクとして構成する。例えば、チャンクのメディアコンテナ形式としては、ＣＭＡＦを利用できる。そして、チャンク構成部１２は、映像信号及び音声信号から構成し、ヘッダ情報としてメタデータを付加したチャンクをトランスポート多重化部１４に出力する。

制御情報生成部１３は、ＣＢＲが記述された制御情報を生成するものである。例えば、制御情報生成部１３は、多重化方式としてＭＭＴを用いる場合、ＭＰＴ（MMT Package Table）のアセットループの記述子に、パラメータとして入力されたＣＢＲのビットレート値を記述し、制御情報を生成する。また、制御情報生成部１３は、多重化方式としてＤＡＳＨ／ＲＯＵＴＥを用いる場合、ＭＰＤ（Media Presentation Description）に、パラメータとして入力されたＣＢＲのビットレート値を記述し、制御情報を生成する。そして、制御情報生成部１３は、生成した制御情報をトランスポート多重化部１４に出力する。

トランスポート多重化部１４は、チャンク及び制御情報をそれぞれ伝送パケットに多重化するものである。ここで、トランスポート多重化部１４は、最大パケット長がパラメータとして入力され、入力された最大パケット長に応じて、各データをフラグメンテーションする。具体的には、トランスポート多重化部１４は、チャンク構成部１２が構成したチャンクを伝送パケットに多重化し、チャンクキュー１５Ａに格納する。また、トランスポート多重化部１４は、制御情報生成部１３が生成した制御情報を伝送パケットに多重化し、チャンクより優先度が高い優先データとして、優先データキュー１５Ｂに格納する。さらに、トランスポート多重化部１４は、緊急速報、イベントメッセージなどの優先データが入力され、入力された優先データを伝送パケットに多重化し、優先データキュー１５Ｂに格納する。さらに、トランスポート多重化部１４は、データ放送などの静的なデータコンテンツが入力され、入力された静的なデータコンテンツを伝送パケットに多重化し、チャンクより優先度が低い非優先データとして、非優先データキュー１５Ｃに格納する。

チャンクキュー１５Ａは、チャンクをキューイングするものである。
優先データキュー１５Ｂは、制御情報、緊急速報、イベントメッセージなどの優先データをキューイングするものである。
非優先データキュー１５Ｃは、静的なデータコンテンツなどの非優先データをキューイングするものである。

トークン出力部１６は、予め設定したトークン量に相当するトークンを所定の間隔で出力するものである。このトークンは、トランスポート送信部１７がビットレート制御を行うための信号である。本実施形態では、トークン出力部１６は、最大パケット長及び伝送路伝送容量がパラメータとして入力され、入力された最大パケット長及び伝送路伝送容量に応じて、トークン量及びトークン出力間隔を算出する。そして、トークン出力部１６は、トークンにトークン量を記述し、そのトークンをトークン出力間隔でトランスポート送信部１７に出力する。なお、トークン出力部１６の詳細は、後記する。

トランスポート送信部１７は、予め設定した伝送レート以下となるように、優先データと、チャンクと、非優先データとを優先度順に多重信号として送信するものである。図３に示すように、トランスポート送信部１７は、トークン出力部１６から入力されたトークンに応じて、優先データキュー１５Ｂにキューイングされた優先データ１５０Ｂと、チャンクキュー１５Ａにキューイングされたチャンク１５０Ａと、非優先データキュー１５Ｃにキューイングされた非優先データとを優先度順に送信する。これにより、トランスポート送信部１７の出力ビットレートが、伝送路の伝送容量以下に収まる。なお、トランスポート送信部１７の詳細は、後記する。

＜トークン出力部の処理＞
図４を参照し、トークン出力部１６の処理を詳細に説明する。
図４に示すように、ステップＳ１０において、トークン出力部１６は、最大パケット長及び伝送路伝送容量に応じて、トークン量及びトークン出力間隔を算出する。具体的には、トークン出力部１６は、伝送路伝送容量を最大パケット長で除算することで、単位時間（１秒）あたりに発行可能なトークン量を算出できる。このとき、トークン出力部１６は、トークン出力間隔の逆数であるトークン発行周期と、１回あたりのトークン量との積が、単位時間あたりのトークン量となるように算出すればよい。

例えば、伝送路伝送容量を毎秒１００Ｍビット、最大パケット長を１４００バイト、最大パケット長の１パケットの送信に必要なトークン量（１回あたりのトークン量）を１．０とする。この場合、単位時間（１秒）あたりに発行可能なトークン量は１００，０００，０００／(１４００＊８)＝８９２９となる。従って、トークン出力間隔は、単位時間あたりに発行可能なトークン量の逆数１／８９２９秒となる。

単位時間あたりのトークン量が変わらなければ、1回あたりのトークン量を減らして、発行間隔を短くしてもよい。例えば、１回あたりのトークン量を０．５とした場合、トークン出力間隔は、１／１７８５６秒となる。さらに、単位時間あたりのトークン量が変わらなければ、1回あたりのトークン量を増やして、発行間隔を長くしてもよい。例えば、１回あたりのトークン量を２．０とした場合、トークン出力間隔は、１／４４６４秒となる。

ステップＳ１１において、トークン出力部１６は、ステップＳ１０で算出したトークン量に相当するトークンをトランスポート送信部１７に出力する。
ステップＳ１２において、トークン出力部１６は、ステップＳ１０で算出したトークン出力間隔だけ待機した後、ステップＳ１１の処理に戻る。つまり、トークン出力部１６は、次のトークン出力タイミングまで待機する。

＜トランスポート送信部の処理：トークンによる割り込み処理＞
図５を参照し、トランスポート送信部１７にトークンが入力されたときの割り込み処理を説明する。
図５に示すように、ステップＳ２０において、トランスポート送信部１７は、残トークン量を０に設定する。
ステップＳ２１において、トランスポート送信部１７は、残トークン量が予め設定された閾値（例えば、１）以上であるか否かを判定する。

残トークン量が１以上の場合（ステップＳ２１でＹｅｓ）、トランスポート送信部１７は、ステップＳ２２の処理に進む。
ステップＳ２２において、トランスポート送信部１７は、図６又は図７のパケット送信処理への割り込みを発生させる。なお、図６又は図７のパケット送信処理の何れかを実行するかは、例えば、送信装置１の管理者が手動で設定する。
ステップＳ２３において、トランスポート送信部１７は、予め設定された保持上限を超える残トークン量を破棄し、ステップＳ２１の処理に戻る。

なお、この残トークン量の保持上限は、トランスポート送信部１７の出力ビットレートにおける平滑化の精度に影響するパラメータであり、任意に設定できる。この上限を小さく設定するほど（最小値は０）、トランスポート送信部１７の瞬時的な出力ビットレートが上限ビットレート（伝送路伝送容量）を越えないように制御できる。その一方、この上限を小さく設定するほど、キューに送信待ちのパケットが減少したときに残トークンが破棄されやすいため、伝送帯域に空き（有効なパケットが無い状態）が生じやすくなる。また、この上限を大きく設定するほど、一時的にキューに送信待ちのパケットが減少したときも残トークンが破棄されにくいため、伝送帯域に空きを生じさせずに使用できる。その一方、この上限を大きく設定するほど、トランスポート送信部１７の瞬時的な出力ビットレートが上限ビットレートを越えることが許容される。つまり、伝送帯域の利用効率と、トランスポート送信部１７の出力ビットレートの平滑化精度のトレードオフとなる。平滑化精度が低い場合には、送信装置１の後段において別途シェーピングを行ってもよい。

残トークン量が１以上でない場合（ステップＳ２１でＮｏ）、トランスポート送信部１７は、ステップＳ２４の処理に進む。
ステップＳ２４において、トランスポート送信部１７は、トークン量に相当するトークンを残トークン量に加算し、ステップＳ２１の処理に戻る。

＜トランスポート送信部の処理：パケット送信処理の第１例＞
図６を参照し、トランスポート送信部１７によるパケット送信処理の第１例を説明する。
図６に示すように、ステップＳ３０において、トランスポート送信部１７は、残トークン量が予め設定された閾値（例えば、１）以上であるか否かを判定する。
残トークン量が１以上の場合（ステップＳ３０でＹｅｓ）、トランスポート送信部１７は、ステップＳ３２の処理に進む。
残トークン量が１以上でない場合（ステップＳ３０でＮｏ）、トランスポート送信部１７は、ステップＳ３１の処理に進む。

ステップＳ３１において、トランスポート送信部１７は、図５のステップＳ２２による割り込みを待つ。そして、トランスポート送信部１７は、割り込みが発生したら、ステップＳ３２の処理に進む。

ステップＳ３２において、トランスポート送信部１７は、優先データキュー１５Ｂに優先データの伝送パケットがキューイングされているか否かを判定する。
優先データキュー１５Ｂにキューイングされている場合（ステップＳ３２でＹｅｓ）、トランスポート送信部１７は、ステップＳ３５の処理に進む。
優先データキュー１５Ｂにキューイングされていない場合（ステップＳ３２でＮｏ）、トランスポート送信部１７は、ステップＳ３３の処理に進む。

ステップＳ３３において、トランスポート送信部１７は、チャンクキュー１５Ａにチャンクの伝送パケットがキューイングされているか否かを判定する。
チャンクキュー１５Ａにキューイングされている場合（ステップＳ３３でＹｅｓ）、トランスポート送信部１７は、ステップＳ３５の処理に進む。
チャンクキュー１５Ａにキューイングされていない場合（ステップＳ３３でＮｏ）、トランスポート送信部１７は、ステップＳ３４の処理に進む。

ステップＳ３４において、トランスポート送信部１７は、非優先データキュー１５Ｃに非優先データの伝送パケットがキューイングされているか否かを判定する。
非優先データキュー１５Ｃにキューイングされている場合（ステップＳ３４でＹｅｓ）、トランスポート送信部１７は、ステップＳ３５の処理に進む。
非優先データキュー１５Ｃにキューイングされていない場合（ステップＳ３４でＮｏ）、トランスポート送信部１７は、ステップＳ３０の処理に戻る。

ステップＳ３５において、トランスポート送信部１７は、伝送パケットがキューイングされている該当キューから伝送パケットを取得する。このとき、トランスポート送信部１７は、必要に応じて、タイムスタンプ情報を記述又は更新してもよい。例えば、ＭＭＴでは、ＭＭＴプロトコルヘッダ部にパケットの送信時刻を示すデリバリータイムスタンプ（送信時刻タイムスタンプ）領域が存在する。そこで、伝送パケットの多重化方式としてＭＭＴを用いる場合、トランスポート送信部１７は、トランスポート送信部１７から伝送路２への送出時刻を記載するように、このデリバリータイムスタンプを更新する。

ステップＳ３６において、トランスポート送信部１７は、ステップＳ３５で取得した伝送パケットを受信装置３に送信する。そして、トランスポート送信部１７は、送信パケット長／最大パケット長のトークン量を残トークン量から減算し、ステップＳ３０の処理に戻る。

このように、第１例のパケット送信処理では、トランスポート送信部１７が、優先データキュー１５Ｂ、チャンクキュー１５Ａ、非優先データキュー１５Ｃの優先度順に伝送パケットを送信する。

＜トランスポート送信部の処理：パケット送信処理の第２例＞
図７を参照し、トランスポート送信部１７によるパケット送信処理の第２例を説明する。この第２例のパケット送信処理は、カウンタを用いて、優先データキュー１５Ｂを参照する頻度を低減した点が、第１例と異なる。

図７に示すように、ステップＳ４０において、トランスポート送信部１７は、カウンタをＮ－１に設定する。なお、Ｎは任意の値で予め設定できる。
ステップＳ４１において、トランスポート送信部１７は、残トークン量が予め設定された閾値（例えば、１）以上であるか否かを判定する。
残トークン量が１以上の場合（ステップＳ４１でＹｅｓ）、トランスポート送信部１７は、ステップＳ４３の処理に進む。
残トークン量が１以上でない場合（ステップＳ４１でＮｏ）、トランスポート送信部１７は、ステップＳ４２の処理に進む。

ステップＳ４２において、トランスポート送信部１７は、図５のステップＳ２２による割り込みを待つ。そして、トランスポート送信部１７は、割り込みが発生したら、ステップＳ４３の処理に進む。

ステップＳ４３において、トランスポート送信部１７は、カウンタが０であるか否かを判定する。
カウンタが０の場合（ステップＳ４３でＹｅｓ）、トランスポート送信部１７は、ステップＳ４４の処理に進む。
カウンタが０でない場合（ステップＳ４３でＮｏ）、トランスポート送信部１７は、ステップＳ４６の処理に進む。

ステップＳ４４において、トランスポート送信部１７は、優先データキュー１５Ｂに優先データの伝送パケットがキューイングされているか否かを判定する。
優先データキュー１５Ｂにキューイングされている場合（ステップＳ４４でＹｅｓ）、トランスポート送信部１７は、ステップＳ４５の処理に進む。
優先データキュー１５Ｂにキューイングされていない場合（ステップＳ４４でＮｏ）、トランスポート送信部１７は、ステップＳ４６の処理に進む。

ステップＳ４５において、トランスポート送信部１７は、カウンタをＮ－１に設定する。
ステップＳ４６において、トランスポート送信部１７は、チャンクキュー１５Ａにチャンクの伝送パケットがキューイングされているか否かを判定する。
チャンクキュー１５Ａにキューイングされている場合（ステップＳ４６でＹｅｓ）、トランスポート送信部１７は、ステップＳ４９の処理に進む。
チャンクキュー１５Ａにキューイングされていない場合（ステップＳ４６でＮｏ）、トランスポート送信部１７は、ステップＳ４７の処理に進む。

ステップＳ４７において、トランスポート送信部１７は、カウンタを０に設定する。
ステップＳ４８において、トランスポート送信部１７は、非優先データキュー１５Ｃに非優先データの伝送パケットがキューイングされているか否かを判定する。
非優先データキュー１５Ｃにキューイングされている場合（ステップＳ４８でＹｅｓ）、トランスポート送信部１７は、ステップＳ４９の処理に進む。
非優先データキュー１５Ｃにキューイングされていない場合（ステップＳ４８でＮｏ）、トランスポート送信部１７は、ステップＳ４１の処理に戻る。

ステップＳ４９において、トランスポート送信部１７は、伝送パケットがキューイングされている該当キューから伝送パケットを取得する。このとき、トランスポート送信部１７は、必要に応じて、タイムスタンプ情報を記述又は更新してもよい。

ステップＳ５０において、トランスポート送信部１７は、ステップＳ４９で取得した伝送パケットを受信装置３に送信する。そして、トランスポート送信部１７は、送信パケット長／最大パケット長のトークン量を残トークン量から減算する。
ステップＳ５１において、トランスポート送信部１７は、カウンタから１を減算し、ステップＳ４１の処理に戻る。

第１例のパケット送信処理では、優先データキュー１５Ｂが詰まった場合、チャンクが送信できない状態が継続してしまう。これに対し、第２例のパケット送信処理では、トランスポート送信部１７が、Ｎ回のパケット送信に対して、１回だけ優先データキュー１５Ｂを参照する。これにより、第２例のパケット送信処理では、優先データキュー１５Ｂが詰まった場合でも、チャンクが送信できない状態に陥ることを防止できる。

図８（ａ）及び図８（ｂ）に示すように、送信装置１は、ＣＰＢを介さずに映像信号の符号データを出力し、符号化の完了と同時にメタデータを付加したチャンクを完成させることができる。これにより、送信装置１内部でのＣＰＢ遅延が発生しない上に、非優先データよりも優先的にチャンクのデータを放送伝送路の帯域全体を利用して送信できるので、最短時間でチャンクのデータを送り切ることができる。ここで、Ｉピクチャを含むチャンクのデータ量が大きく、次以降のチャンクの送信が遅延する場合も考えられる。この場合でも、図９（ａ）及び図９（ｂ）に示すように、送信装置１は、最大ＣＰＢ遅延をＧＯＰ長相当とすることで、ＧＯＰ長を超える遅延蓄積は発生しないので、リアルタイム性を確保できる。なお、図８（ａ）及び図９（ａ）は、符号化処理部１１Ａが出力する符号データ量を表す。また、図８（ｂ）及び図９（ｂ）は、送信装置１が出力する符号データ量を表す。

［受信装置の構成］
図１０を参照し、実施形態に係る受信装置３の構成について説明する。
図１０に示すように、受信装置３は、送信装置１から多重信号を受信するものであり、中継部３Ａと、映像復号部３Ｂとを備える。

中継部３Ａは、映像信号を後記する映像復号部３Ｂに中継するものであり、多重分離部３０と、マニフェストファイル生成部３１と、記憶部３２と、サーバ部（読出部）３３とを備える。

多重分離部３０は、中継部３Ａが受信した多重信号から、所定の制御情報と、符号化された映像信号とで構成されたチャンクとを分離するものである。そして、多重分離部３０は、分離した制御情報をマニフェストファイル生成部３１に出力し、チャンクを記憶部３２に書き込む。

マニフェストファイル生成部３１は、多重分離部３０が分離した制御情報に応じて、チャンクの所在情報（例えば、ＵＲＬ）や再生開始チャンクを指示するポインタ情報が記述されたマニフェストファイルを生成するものである。そして、マニフェストファイル生成部３１は、生成したマニフェストファイルを記憶部３２に書き込む。なお、マニフェストファイル生成部３１の詳細は、後記する。

このマニフェストファイルは、放送チャンネルに関連付けられており、チャンクの所在情報が記述されている。例えば、マニフェストファイルには、所在情報として、チャンクファイルのＵＲＬの一覧、又は、チャンクファイルのテンプレートＵＲＬが記載されている。さらに、テンプレートＵＲＬの場合、再生開始チャンクを指示するため、再生開始チャンクを特定するポインタ情報として、シーケンス番号の初期値を記載する。例えば、チャンクファイルのテンプレートＵＲＬは、「chunk_$Number$.m4s」である。また、シーケンス番号は、チャンクファイルのＵＲＬを生成するためのものであり、例えば、テンプレートＵＲＬの「$Number$」に代入する。例えば、マニフェストファイルの書式は、ＨＬＳ方式であればｍ３ｕ８、ＭＰＥＧ－ＤＡＳＨ方式であればＭＰＤがあげられる。なお、マニフェストファイルの書式は、前記したものに制限されない。

記憶部３２は、チャンク及びマニフェストファイルを記憶するメモリ、ＨＤＤ（Hard Disk Drive）などの記憶装置である。ここで、中継部３Ａが新たなチャンクを受信する都度、マニフェストファイル生成部３１が記憶部３２のマニフェストファイルの内容を更新する。従って、記憶部３２が、最新のマニフェストファイルを記憶している状態となる。

サーバ部３３は、記憶部３２からチャンク及びマニフェストファイルを読み出すものである。そして、サーバ部３３は、読み出したチャンク及びマニフェストファイルを映像復号部３Ｂに出力する。なお、サーバ部３３の詳細は、後記する。

映像復号部３Ｂは、マニフェストファイルをサーバ部３３にリクエスト（要求）し、当該リクエストに応じてマニフェストファイルをサーバ部３３から取得し、取得したマニフェストファイルに記載のチャンクをサーバ部３３にリクエストして取得することを繰り返して、映像信号を復号するものである。例えば、映像復号部３Ｂは、図２の符号化処理部１１Ａと同様の映像符号化方式で映像信号を復号する。

＜サーバ部及び映像復号部の処理＞
図１１を参照し、サーバ部３３及び映像復号部３Ｂの処理について説明する。
図１１に示すように、ステップＳ６０において、映像復号部３Ｂは、記憶部３２に記憶されているマニフェストファイルのＵＲＬを指定し、サーバ部３３にチャンクをリクエストする。例えば、チャンクのリクエストには、ＨＴＴＰ（Hypertext Transfer Protocol）／ＴＣＰ（Transmission Control Protocol）を用いる。

なお、マニフェストファイルのＵＲＬを指定する方法は、任意である。例えば、受信装置３のユーザによる手入力、ＱＲコード（登録商標）による指定、通信ネットワークからの取得など、様々な手法でマニフェストファイルのＵＲＬを指定できる。また、ライブ視聴用のマニフェストファイルのＵＲＬをチャンネル毎に一定にすることで、チャンネルに関連付けられたマニフェストのＵＲＬをリクエストすることで、意図したチャンネルのライブ視聴が可能である。

ステップＳ６１において、サーバ部３３は、記憶部３２からマニフェストファイルを読み出して、映像復号部３Ｂにレスポンスする。映像復号部３Ｂは、サーバ部３３からマニフェストファイルを取得する。

ステップＳ６２において、映像復号部３Ｂは、取得したマニフェストファイルに従って、初期バッファのため、Ａ個（例えば、Ａ＝３）のチャンクをサーバ部３３にリクエストする。
ステップＳ６３において、サーバ部３３は、記憶部３２からチャンクを読み出して、映像復号部３Ｂにレスポンスする。

ステップＳ６４において、映像復号部３Ｂは、Ａ個のチャンクをバッファする。

ステップＳ６５において、映像復号部３Ｂは、Ａ個のチャンクがバッファされたところで、映像信号を復号し、映像を再生する。
その後、映像復号部３Ｂは、後続のチャンクをリクエストし、チャンクをバッファしながら映像の再生を続ける（ステップＳ６６～Ｓ６８）。

なお、映像復号部３Ｂは、サーバ部３３に対して、定期的にマニフェストファイルをリクエストして最新情報の再取得を行ってもよい。特に、マニフェストファイルに記載されているチャンクの所在情報がテンプレートではないチャンクＵＲＬの一覧である場合、マニフェストファイルの再取得を行って後続チャンクファイルのＵＲＬを取得することができる。一方、チャンクの所在情報が、テンプレートＵＲＬの場合には、ポインタ情報をインクリメント（加算）していくことで後続のチャンクファイルのＵＲＬを生成できるため、一般にマニフェストファイルを定期的に再取得しなくても再生の継続が可能である。

なお、サーバ部３３として、ＨＴＴＰ（Hypertext Transfer Protocol）サーバを利用できる。一般的なＨＴＴＰサーバは、取得（ＧＥＴ）リクエストされたＵＲＬのファイルが存在しない場合、レスポンスとして、指定されたファイルが存在しない旨のエラーメッセージ（ＮｏｔＦｏｕｎｄエラー）を応答する。つまり、リクエストしたチャンクが未完成の場合、映像復号部３Ｂには、ＮｏｔＦｏｕｎｄエラーが応答される。そこで、映像復号部３Ｂは、チャンクを取得できるまで（ＮｏｔＦｏｕｎｄエラーが応答されなくなるまで）、一定時間毎に同一ＵＲＬでリクエストを繰り返せばよい。

また、サーバ部３３は、映像復号部３Ｂからのチャンク取得のリクエストに対し、チャンクが完成するまで応答を保留し、チャンク完成後に応答してもよい。また、サーバ部３３は、チャンクの全体が未完成であっても、チャンクを受信できた部分から順次応答してもよい。例えば、ＨＴＴＰでは、Ｃｈｕｎｋｅｄ Ｔｒａｎｓｆｅｒ Ｅｎｃｏｄｉｎｇを使用することで、全体が完成していないデータを順次応答することができる。

＜マニフェストファイル生成部の詳細＞
以下、マニフェストファイル生成部３１の詳細について補足する。
マニフェストファイル生成部３１は、初期バッファの分を含めて、映像復号部３Ｂが最初に取得すべきチャンクがチャンクファイルのＵＲＬの一覧の先頭やポインタ情報によって指示されるように、チャンクが完成する都度、マニフェストファイルを更新する。ここで、受信途中のチャンクのシーケンス番号をＢとする。この場合、マニフェストファイル生成部３１は、初期バッファ数であるＡ個前のチャンク（シーケンス番号＝Ｂ－Ａ）から映像復号部３Ｂが取得できるように、チャンクファイルのＵＲＬ、又は、テンプレートＵＲＬ及び再生開始を指示するポインタ情報であるシーケンス番号（Ｂ－Ａ）をマニフェストファイルに記述する。

これにより、映像復号部３Ｂは、受信予定のチャンク（シーケンス番号＝Ｂ）の完成を待たずに、初期バッファ数であるＡ個のチャンクを取得した後、シーケンス番号＝Ｂ－Ａのチャンクから直ちに映像の再生を開始できる。そして、映像復号部３Ｂは、シーケンス番号＝Ｂ－Ａのチャンクから映像の再生を開始して、１チャンク分の映像を再生したところで、チャンクをバッファするためにシーケンス番号＝Ｂのチャンクをリクエストする。このとき、映像復号部３Ｂは、シーケンス番号＝Ｂのチャンクの受信を完了している可能性が高いので、リクエストに対するエラーが低減し、レスポンスまで時間を要することなくスムーズにチャンクを取得できる。

（変形例）
以上、実施形態を詳述してきたが、本発明は前記した実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計変更等も含まれる。
前記した実施形態では、送信装置の映像符号化部は、最大ＣＰＢ遅延及びＣＢＲのビットレート値がパラメータとして入力されることとして説明したが、これに限定されない。例えば、映像符号化部には、最大ＣＰＢ遅延の代わりに、ＣＰＢサイズをパラメータとして入力してもよい。また、最大ＣＰＢ遅延又はＣＰＢサイズに加えて、初期バッファ容量（初期化状態としてＣＰＢの一部容量を使用しているものとみなして符号化処理を開始する）など追加のパラメータを入力してもよい。これらの各種パラメータは、ＣＰＢの状態を詳細に管理し高度なレート制御を行うためのパラメータであり、ＣＰＢの基本動作が大きく変わるものではなく、本発明の実現性を損なうものではない。

前記した実施形態では、多重化方式としてＭＭＴを用いる場合、送信装置の制御情報生成部は、ＭＰＴを制御情報として生成し、伝送することとしたが、これに限定されない。例えば、多重化方式としてＭＭＴを用いる場合であっても、ＭＰＥＧ－ＤＡＳＨで規定されるマニフェストファイルであるＭＰＤを汎用データ伝送方式などによって多重化し、制御情報として伝送できる。この場合、受信装置のマニフェストファイル生成部は、ＭＭＴから多重分離したＭＰＤをもとに、ＭＰＤ又は他の形式のマニフェストファイルを生成してもよい。

前記した実施形態では、受信装置において、中継部及び映像復号部が一体化していることとして説明したが、本発明は、これに限定されない。例えば、受信装置では、中継部をホームゲートウェイのような中継装置として、映像復号部から独立させてもよい。

前記した実施形態では、送信装置及び受信装置が独立したハードウェアであることとして説明したが、本発明は、これに限定されない。例えば、本発明は、コンピュータが備えるＣＰＵ、メモリ、ハードディスク等のハードウェア資源を、前記した送信装置又は受信装置として機能させるためのプログラムで実現することもできる。このプログラムは、通信回線を介して配布してもよく、ＣＤ－ＲＯＭやフラッシュメモリ等の記録媒体に書き込んで配布してもよい。

（参考例）
図１２を参照し、参考例に係る受信装置４について説明する。
図１２に示すように、受信装置４は、伝送路２を介して、送信装置１から多重信号を受信するものであり、中継部４Ａと、映像復号部４Ｂとを備える。

中継部４Ａは、映像信号を後記する映像復号部３Ｂに中継するものであり、多重分離部４０と、制御情報解析部４１と、ＣＢＲ補償バッファ４２とを備える。

多重分離部４０は、中継部４Ａが受信した多重信号から、ＣＢＲが記述された制御情報と、符号化された映像信号とで構成されたチャンクとを分離するものである。そして、多重分離部４０は、分離した制御情報を制御情報解析部４１に出力する。さらに、多重分離部４０は、分離したチャンクから映像信号の符号データを必要に応じて再構成し、ＣＢＲ補償バッファ４２に出力する。例えば、多重分離部４０は、ＣＭＡＦ形式などのチャンクとして伝送された符号データが映像復号部４Ｂの入力に適合しない場合に、映像復号部４Ｂで処理できるようにチャンク化されていない符号データに再構成してもよい。また、多重分離部４０は、ＭＭＴ方式からＭＰＥＧ－２ ＴＳ（Transport Stream）など多重化方式の変換処理を伴ってもよい。

制御情報解析部４１は、多重分離部４０より入力された制御情報を解析し、ＣＢＲのビットレート値を読み出すものである。つまり、制御情報解析部４１は、制御情報に記述されたＣＢＲを取得し、取得したＣＢＲをＣＢＲ補償バッファ４２に出力する。

ＣＢＲ補償バッファ４２は、制御情報解析部４１から入力されたＣＢＲのビットレート値を参照し、映像信号の符号データをＣＢＲで平滑化するバッファである。そして、ＣＢＲ補償バッファ４２は、ＣＢＲのビットレート値で平滑化した符号データを映像復号部４Ｂに出力する。

映像復号部４Ｂは、ＣＢＲ補償バッファ４２から入力された映像信号の符号データを復号し、再生するものである。例えば、映像復号部４Ｂは、図２の符号化処理部１１Ａと同様の映像符号化方式で映像信号を復号する。

なお、参考例に係る受信装置４では、中継部４Ａ及び映像復号部４Ｂが一体化していることとして説明したが、これに限定されない。例えば、受信装置４では、中継部４Ａをホームゲートウェイのような中継装置として、映像復号部４Ｂから独立させてもよい。

１ 送信装置
２ 伝送路
３，４ 受信装置
３Ａ，４Ａ 中継部
３Ｂ，４Ｂ 映像復号部
１０ 音声符号化部
１１ 映像符号化部
１１Ａ 符号化処理部
１１Ｂ 仮想ＣＰＢ
１１Ｃ 符号化制御部
１２ チャンク構成部
１３ 制御情報生成部
１４ トランスポート多重化部（多重化部）
１５Ａ チャンクキュー
１５Ｂ 優先データキュー
１５Ｃ 非優先データキュー
１６ トークン出力部
１７ トランスポート送信部（送信部）
３０，４０ 多重分離部
３１ マニフェストファイル生成部
３２ 記憶部
３３ サーバ部（読出部）
４１ 制御情報解析部
４２ ＣＢＲ補償バッファ

Claims (7)

1. 映像信号が入力され、入力された前記映像信号を符号化して送信する送信装置であって、
   仮想ＣＰＢによるビットレート制御を前記映像信号に施し、ＣＰＢを介さずに、符号化した前記映像信号を予め設定したＣＢＲ以上のビットレートで出力する映像符号化部と、
   前記映像符号化部が前記ＣＢＲ以上のビットレートで出力した映像信号からチャンクを構成し、構成した前記チャンクにメタデータをヘッダ情報として付加するチャンク構成部と、
   所定の制御情報を生成する制御情報生成部と、
   前記メタデータが付加されたチャンク及び前記制御情報をそれぞれパケットに多重化する多重化部と、
   予め設定した伝送レート以下となるように、前記チャンクより優先度が高い前記制御情報を含む優先データと、前記チャンクと、前記チャンクより優先度が低い非優先データとを優先度順に多重信号として送信する送信部と、
   を備えることを特徴とする送信装置。
2. 予め設定したトークン量に相当するトークンを所定の間隔で出力するトークン出力部、をさらに備え、
   前記送信部は、
   前記トークンに相当するトークン量を残トークン量に加算し、
   前記残トークン量が予め設定された閾値以上の場合、前記優先データと、前記チャンクと、前記非優先データとを優先度順に送信し、
   前記優先データ、前記チャンク又は前記非優先データの送信データ量に応じたトークン量を前記残トークン量から減算することを特徴とする請求項１に記載の送信装置。
3. 前記優先データを格納する優先データキューと、
   前記チャンクをキューイングするチャンクキューと、
   前記非優先データが入力され、入力された前記非優先データを格納する非優先データキューと、をさらに備え、
   前記多重化部は、前記チャンク構成部が構成したチャンクを前記チャンクキューに格納し、前記制御情報生成部が生成した制御情報を前記優先データとして前記優先データキューに格納し、
   前記送信部は、前記優先データキューにキューイングされた優先データと、前記チャンクキューにキューイングされたチャンクと、前記非優先データキューにキューイングされた非優先データとを優先度順に送信することを特徴とする請求項１又は請求項２に記載の送信装置。
4. 音声信号が入力され、入力された前記音声信号を符号化する音声符号化部、をさらに備え、
   前記チャンク構成部は、前記映像符号化部が前記ＣＢＲ以上のビットレートで出力した映像信号と、前記音声符号化部が符号化した音声信号とから前記チャンクを構成することを特徴とする請求項１に記載の送信装置。
5. 請求項１に記載の送信装置から多重信号を受信する受信装置であって、
   前記多重信号から、所定の制御情報と、符号化された前記映像信号とで構成されたチャンクとを分離する多重分離部と、
   前記多重分離部が分離した制御情報に応じて、前記チャンクの所在情報が記述されたマニフェストファイルを生成するマニフェストファイル生成部と、
   前記チャンク及び前記マニフェストファイルを記憶する記憶部と、
   前記記憶部から前記チャンク及び前記マニフェストファイルを読み出す読出部と、
   前記マニフェストファイルを前記読出部に要求し、当該要求に応じて前記マニフェストファイルを前記読出部から取得し、取得した前記マニフェストファイルの所在情報が示すチャンクを時系列に受信して映像信号を復号する映像復号部と、
   を備えることを特徴とする受信装置。
6. コンピュータを、請求項１に記載の送信装置として機能させるためのプログラム。
7. コンピュータを、請求項５に記載の受信装置として機能させるためのプログラム。

Images