特許 7603515 復号化装置およびプログラム

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

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

(11)【特許番号】

(24)【登録日】2024-12-12

(45)【発行日】2024-12-20

(54)【発明の名称】復号化装置およびプログラム

(51)【国際特許分類】

   H04N 19/42 20140101AFI20241213BHJP

【ＦＩ】

H04N19/42

【請求項の数】 5

(21)【出願番号】P 2021068855

(22)【出願日】2021-04-15

(65)【公開番号】P2022163805

(43)【公開日】2022-10-27

【審査請求日】2024-03-15

(73)【特許権者】

【識別番号】000004352

【氏名又は名称】日本放送協会

(74)【代理人】

【識別番号】100141139

【弁理士】

【氏名又は名称】及川 周

(74)【代理人】

【識別番号】100171446

【弁理士】

【氏名又は名称】高田 尚幸

(74)【代理人】

【識別番号】100114937

【弁理士】

【氏名又は名称】松本 裕幸

(74)【代理人】

【識別番号】100171930

【弁理士】

【氏名又は名称】木下 郁一郎

(72)【発明者】

【氏名】白戸 諒

(72)【発明者】

【氏名】川本 潤一郎

(72)【発明者】

【氏名】倉掛 卓也

【審査官】松元 伸次

(56)【参考文献】

【文献】国際公開第２００８／１４３１５６（ＷＯ，Ａ１）

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

Ｈ０４Ｎ １９／００ － １９／９８

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

【請求項1】

所定の符号化方式で符号化された映像ストリームを受信する受信処理部と、
前記受信処理部が受信した前記映像ストリームの復号化の処理を行い、復号化後の映像ストリームを出力する復号化部と、
前記復号化部が出力した前記復号化後の映像ストリームを送信する送信処理部と、
前記映像ストリームの前記復号化部での復号化の処理による遅延に対する要求である遅延要求に応じて、前記復号化部の処理のためのリソースを決定し、決定された前記リソースを当該映像ストリームの復号化の処理のために割り当てるリソース管理部と、
前記送信処理部から送信される前記復号化後の映像ストリームを受信する映像処理装置からの要求データに基づいて、前記遅延要求を前記リソース管理部に通知する要求処理部と、
を備える復号化装置。

【請求項2】

前記リソース管理部は、前記映像ストリームの映像フォーマットの種別にも応じて、前記復号化部の処理のためのリソースを決定し、決定された前記リソースを当該映像ストリームの復号化の処理のために割り当てる、
請求項１に記載の復号化装置。

【請求項3】

所定の符号化方式で符号化された映像ストリームを受信する受信処理部と、
前記受信処理部が受信した前記映像ストリームの復号化の処理を行い、復号化後の映像ストリームを出力する復号化部と、
前記復号化部が出力した前記復号化後の映像ストリームを送信する送信処理部と、
前記映像ストリームの前記復号化部での復号化の処理による遅延に対する要求である遅延要求に応じて、前記復号化部の処理のためのリソースを決定し、決定された前記リソースを当該映像ストリームの復号化の処理のために割り当てるリソース管理部と、
を備え、
前記リソース管理部は、前記映像ストリームの映像フォーマットの種別にも応じて、前記復号化部の処理のためのリソースを決定し、決定された前記リソースを当該映像ストリームの復号化の処理のために割り当てるものであり、
前記リソース管理部は、前記受信処理部からの、前記映像ストリームの映像フォーマットの種別の通知を受けるものであり、
前記映像フォーマットの種別は、２Ｋ、４Ｋ、または８Ｋのいずれかの映像フォーマットであることを表すものである、
復号化装置。

【請求項4】

前記リソース管理部は、前記復号化部の処理が記述されたプログラムを実行するプロセッサーにおけるスレッド数を、前記映像ストリームの復号化の処理のためのリソースとして決定し、決定された前記リソースを当該映像ストリームの復号化の処理のために割り当てる、
請求項１から３までのいずれか一項に記載の復号化装置。

【請求項5】

請求項１から４までのいずれか一項に記載の復号化装置、
としてコンピューターを機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、復号化装置およびプログラムに関する。

【背景技術】

【0002】

映像信号をＩＰパケット化して汎用のイーサネットワーク上で伝送するための標準化が、ＳＭＰＴＥ（米国テレビ映画技術者協会）で議論されている。このように映像信号をＩＰパケットで伝送することにより、既存のインフラストラクチャーを用いて映像信号を効率的に共有することのできる番組制作システム、ＩＰ制作システムを実現することが期待される。

【0003】

このＩＰ制作システムを用いた番組制作では、画質劣化の少ない、低遅延で圧縮可能な、軽圧縮と呼ばれる圧縮手法が用いられる。この圧縮手法は、ＨＥＶＣ（High Efficiency Video Coding）といった高圧縮率のコーデックと異なり、圧縮率を１／４から１／１０程度に抑えることで、ラインレベルの低遅延を実現する。具体的には、ＬＬＶＣ（Low Latency Video Codec）、ＶＣ２、ＴＩＣＯ（Tiny Codec）、ＪＰＥＧ ＸＳ（ＸＳは、eXtra Speed eXtra Smallの略）といった手法が存在し、用いられている。

【0004】

これらの手法のうち、ＪＰＥＧ ＸＳのみについては、国際標準化が完了している。ＪＰＥＧ ＸＳを用いたＩＰ制作システムにおける圧縮信号のパケタイズについては、ＩＳＯ／ＩＥＣ ２１１２２において明らかにされている。

【0005】

上記のような軽圧縮手法については、ＦＰＧＡやＡＳＩＣ上のハードウェアでの実装と、ＣＰＵ上で稼働するソフトウェアでの実装とが考えられる。圧縮時の処理遅延に関しては、ハードウェアで実装する場合には、軽圧縮手法の理論上の値であるラインレベルの低遅延が実現できる。ソフトウェアで実装する場合には、処理遅延の量は、プログラムの実装や動作環境に大きく依存する。

【0006】

従来技術では、主として可能な限り小さな遅延で圧縮し伝送することを目的として、専用ハードウェア上でＪＰＥＧ ＸＳによる映像の圧縮および復号（伸長）を行う機材が開発されてきている。

【0007】

非特許文献１や非特許文献２では、ＪＰＥＧ ＸＳの実装について記載されている。

【先行技術文献】

【非特許文献】

【0008】

【文献】「JPEG XS － 本格的な映像製作用の新たな低複雑性コーデック規格」，Fraunhofer IIS，［online］，［２０２１年３月４日ダウンロード］，インターネット＜URL：https://www.iis.fraunhofer.de/ja/ff/amm/content-production/jpegxs.html＞

【文献】「オープンフォーマットJPEG XS、画像符号化史上初のパラダイムシフト」，ＰＲＯＮＥＷＳ，２０１８年０４月２３日掲載，［online］，［２０２１年３月４日ダウンロード］，インターネット＜URL：https://www.pronews.jp/news/20180423181595052.html＞

【発明の概要】

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

【0009】

ＩＰ制作システムの普及にともない、様々なテレビ番組等が、ＩＰ制作システムを用いて制作され始めている。これに伴い、映像を圧縮して伝送する要求が増えている。しかし、ＣＣＵ（カメラ・コントロール・ユニット）、映像調整卓、スイッチャーといったすべての放送機器に符号化処理機能や復号化処理機能を搭載することは困難である。つまり、符号化処理機能や復号化処理機能を、放送機器とは別のハードウェアもしくはソフトウェアで実現し、放送機器と接続させる必要がある。

【0010】

ＪＰＥＧ ＸＳでの符号化処理および復号化処理での遅延量を小さくするために、従来技術では、専用ハードウェアの機能として軽圧縮が実装されてきている。

【0011】

しかしながら、ＩＰ制作システムで制作する番組が多様化するにつれて、制作する番組の性質によって遅延要求の度合いが異なる場合も増えてくる。遅延要求が緩和される場合には、遅延量が多少は大きくなってもよく、従来技術によるハードウェアでの実装よりも安価な実装による機材が求められる。また、番組の性質等によって、様々な遅延の要求に柔軟に対応できる機材が求められる。

【0012】

また、専用のハードウェアで符号化機能と復号化機能を実現する場合には、映像フォーマット毎の専用機が必要である。また、専用のハードウェアでは、２Ｋ／４Ｋ／８Ｋなどといった様々な画素数の映像フォーマットの番組に対応するには柔軟性が低い。これらすべての映像フォーマットの制作のために十分な機材を準備する場合にはコストが非常に高い。

【0013】

本発明は、上記のような課題認識に基づいて行われたものであり、映像信号の様々な遅延要求に柔軟に対応することができ、且つ低コストで実現可能な復号化装置およびそのプログラムを提供しようとするものである。

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

【0014】

［１］上記の課題を解決するため、本発明の一態様による復号化装置は、所定の符号化方式で符号化された映像ストリームを受信する受信処理部と、前記受信処理部が受信した前記映像ストリームの復号化の処理を行い、復号化後の映像ストリームを出力する復号化部と、前記復号化部が出力した前記復号化後の映像ストリームを送信する送信処理部と、前記映像ストリームの前記復号化部での復号化の処理による遅延に対する要求である遅延要求に応じて、前記復号化部の処理のためのリソースを決定し、決定された前記リソースを当該映像ストリームの復号化の処理のために割り当てるリソース管理部と、を備えるものである。

【0015】

［２］また、本発明の一態様は、上記の復号化装置において、前記送信処理部から送信される前記復号化後の映像ストリームを受信する映像処理装置からの要求データに基づいて、前記遅延要求を前記リソース管理部に通知する要求処理部、をさらに備えるものである。

【0016】

［３］また、本発明の一態様は、上記の復号化装置において、前記リソース管理部は、前記映像ストリームの映像フォーマットの種別にも応じて、前記復号化部の処理のためのリソースを決定し、決定された前記リソースを当該映像ストリームの復号化の処理のために割り当てるものである。

【0017】

［４］また、本発明の一態様は、上記の復号化装置において、前記リソース管理部は、前記受信処理部からの、前記映像ストリームの映像フォーマットの種別の通知を受けるものである。

【0018】

［５］また、本発明の一態様は、上記の復号化装置において、前記リソース管理部は、前記復号化部の処理が記述されたプログラムを実行するプロセッサーにおけるスレッド数を、前記映像ストリームの復号化の処理のためのリソースとして決定し、決定された前記リソースを当該映像ストリームの復号化の処理のために割り当てる、ものである。

【0019】

［６］また、本発明の一態様は、所定の符号化方式で符号化された映像ストリームを受信する受信処理部と、前記受信処理部が受信した前記映像ストリームの復号化の処理を行い、復号化後の映像ストリームを出力する復号化部と、前記復号化部が出力した前記復号化後の映像ストリームを送信する送信処理部と、前記映像ストリームの前記復号化部での復号化の処理による遅延に対する要求である遅延要求に応じて、前記復号化部の処理のためのリソースを決定し、決定された前記リソースを当該映像ストリームの復号化の処理のために割り当てるリソース管理部と、を備える復号化装置、としてコンピューターを機能させるためのプログラムである。

【発明の効果】

【0020】

本発明によれば、復号化装置は、個別の映像ストリームに対する遅延要求に応じて、その映像ストリームの復号化処理のための計算リソースを決定し、割り当てることができる。

【図面の簡単な説明】

【0021】

【図1】本発明の実施形態による映像伝送システムの構成と、その各装置の概略機能構成とを示すブロック図である。

【図2】同実施形態による映像伝送システムの動作手順の例を示すシーケンスチャートである。

【図3】同実施形態による映像伝送システムの動作手順の別の例を示すシーケンスチャートである。

【図4】同実施形態において使用されるＳＤＰファイルが含む要求機能データの形式の例を示す概略図である。

【図5】同実施形態における復号化装置として特定の動作環境（コンピューター）を機能させる場合の、ある特定の動作環境（コンピューター）を復号化装置３として機能させる場合の、映像ストリームのフォーマットと、その映像ストリームの復号化処理に割り当てるスレッド数との組合せに対する、復号化処理による遅延量（時間）の測定結果を示す概略図である。

【図6】同実施形態による映像伝送システムを構成する各装置の内部構成の例を示すブロック図である。

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

【0022】

次に、本発明の一実施形態について、図面を参照しながら説明する。本実施形態による映像伝送システムは、伝送対象とする映像の符号化処理を行う機能、および復号化処理（復号処理とも呼ばれる）を行う機能を含んでいる。

【0023】

まず、実施形態の前提となる事項を説明する。

【0024】

ソフトウェアで符号化機能と復号化機能を実現する場合、マルチスレッド処理で割り当てるリソースを制御することで、様々な遅延の要求に応えることができる。また、ソフトウェアで実現する場合には、２Ｋ／４Ｋ／８Ｋなどといった複数の映像フォーマットフォーマットを、ほぼ同一のプログラムで処理することが可能である。また、リソースを、符号化機能や復号化機能以外のソフトウェアの機能と分け合うことができるため、リソースを効率的な使用が可能となり、コストの低減が見込める。

【0025】

ただし、ソフトウェアにおける符号化処理の演算量は、復号化処理の演算量と比較して大きい。符号化処理の演算量の大きさの理由により、符号化処理の処理遅延を短縮することは困難である。また、ソフトウェアによる符号化処理に最大リソース（ＣＰＵリソース等）を割当てても、実現可能な処理遅延には多くの制約がかかる。

【0026】

専用のハードウェアで実現する場合には、ＦＰＧＡのＩＰコアは、符号化処理の処理量よりも復号化処理の処理量の方が少なく、復号化処理の回路規模の方が少ない。しかし、復号化処理の回路規模の削減は、符号化処理の回路規模と比べて、２～３割減に留まる。

【0027】

ソフトウェアで符号化処理および復号化処理を実現する場合にも、符号化処理の処理量よりも復号化処理の処理量の方が小さい。ソフトウェアで実現する場合の復号化処理の処理量は、符号化処理の処理量と比べて、４～５割減とすることができる。

【0028】

また、ソフトウェアによって符号化処理を実現する場合には数フレームの遅延が生じる場合もあるが、ソフトウェアによって復号化処理を実現する場合の遅延量は、１フレーム未満とすることも可能である。

【0029】

以上説明したように、復号化機能をソフトウェアで実現する場合には、相対的に処理量を少なくできることや、コストを抑制できることや、スレッドごとの計算資源を適切に制御できることなどによる効果は大きい。一方で、符号化機能をソフトウェアで実現しようとしても、復号化機能で得られるほどの効果を得ることは困難で、且つ遅延量を小さくすることもできない。つまり、符号化処理を専用のハードウェアで実装し、復号化処理をソフトウェアで実装する場合には、コストを抑制しながら、様々な幅広い遅延要求に応じた処理を行うことが可能となる。

【0030】

復号化機能をソフトウェアで実現する場合、様々な遅延要求に対応できるようにするためには、機材運用において、余裕をもってリソースの割り当てを行うことが想定される。例えば、比較的大きな遅延量でも構わないという映像の伝送においても、低遅延用のリソースの割り当てを行うことにもなり得る。また、復号化処理のオペレーターには、要求ごとに適切なリソースの割り当てを行うように判断することが要求される。本実施形態は、このような復号化処理へのリソースの割り当てを、自動化し、且つ最適化するものである。これにより、本実施形態の映像伝送システムでは、効率的にリソースの割り当てを行いながら、機材を運用することができるようになる。

【0031】

その具体的な構成を以下で説明する。

【0032】

図１は、本実施形態による映像伝送システムの構成と、その各装置の概略機能構成とを示すブロック図である。映像伝送システム１００は、映像信号を伝送する過程において、軽圧縮手法による、信号の符号化および復号化を行う。図示するように、映像伝送システム１００は、符号化装置１と、ネットワークスイッチ２と、復号化装置３と、映像処理装置４Ａ，４Ｂとを含んで構成される。

【0033】

符号化装置１は、入力される映像信号を符号化し、出力する。符号化装置１は、符号化後のデータを、ＩＰパケットとして送信する。つまり、符号化装置１は、圧縮映像ストリームを生成し、ネットワークスイッチ２側に伝送する。この圧縮映像ストリームは、例えばＳＭＰＴＥ ＳＴ２１１０の規定に基づいてＩＰパケット化されている。符号化装置１は、例えばマルチキャスト方式でこのＩＰパケットを送出することができる。ただし、符号化装置１は、ユニキャスト方式でＩＰパケットを送出してもよい。

【0034】

ネットワークスイッチ２は、ネットワークを構成する機器であり、ＩＰパケットを転送する。具体的には、ネットワークスイッチ２は、符号化装置１から送出されたＩＰパケットを受信し、復号化装置３へ転送する。ネットワークスイッチ２は、複数の入力ポートと複数の出力ポートを備える。ネットワークスイッチ２は、ＩＰパケットのヘッダーを参照することにより、受信したパケットを、宛先に対応する出力ポートに出力する。

【0035】

復号化装置３は、ネットワークスイッチ２から、ＩＰパケットを受信するとともに、ＩＰパケットに含まれるデータの復号化を行う。復号化装置３は、例えば映像処理装置４Ａや４Ｂからの要求に基づいて、復号化後のデータをこれら映像処理装置４Ａや４Ｂに送信する。

【0036】

映像処理装置４Ａ，４Ｂは、例えば放送番組を制作するなどの目的のために、映像を処理する装置である。映像処理装置４Ａや４Ｂなどを総称して、映像処理装置４と呼んでもよい。映像処理装置４は、符号化処理が行われた映像の復号映像を求める際に、復号化装置３に対して、要求機能データを送信する。要求機能データは、遅延要求のデータを含む。遅延要求のデータは、例えば、０以上１０以下の整数値で表わされる。遅延要求の値が０であることは、遅延最小であることを表す。遅延要求の値が１０であることは、遅延最大であることを表す。遅延要求の値は、０以上１０以下の範囲内で遅延要求の大小の程度を表すものである。

【0037】

本実施形態において、符号化装置１が持つ符号化機能は、専用のハードウェアを用いて実現される。これにより、符号化装置１は、小さい遅延量で符号化処理を行うことができる。符号化装置１は、符号化方式として例えばＪＰＥＧ ＸＳを用いた符号化を行う。符号化機能を専用のハードウェアで実現することにより、符号化機能を汎用のプロセッサー（ＣＰＵ等）で実現する場合よりも、符号化処理の遅延量を小さくすることができる。

【0038】

一方、本実施形態の復号化装置３が持つ復号化機能は、汎用のプロセッサー（ＣＰＵ等）とプログラム（ソフトウェア）とで実現される。これにより、復号化装置３は、並列的に復号化処理を行う複数の映像ストリームのそれぞれについて、個別に、復号化処理のためのリソースを割り当てることができる。ここで割り当てられるリソースとは、主として、ＣＰＵコア、スレッド、ＣＰＵ時間である。つまり、復号化装置３は、ＣＰＵコアや、スレッドや、ＣＰＵ時間等の単位で、個々の映像ストリームの復号化の処理にリソースを割り当てることができる。ただし、割り当てられるリソースが他のリソース（例えば、半導体メモリーによって実現される主記憶領域など）を含んでもよい。映像ストリームの種類（例えばコンテンツの内容）に応じて、復号化処理において許容される遅延量は異なる。復号化装置３をソフトウェアで実現することにより、それぞれの映像ストリームに対して、柔軟に、リソースを割り当てたりその割り当てを変更したりすることが容易になる。

【0039】

一例として、復号化装置３は、復号化処理の対象である映像ストリームごとに、計算のためのリソースとして、異なるスレッド数を割り当てることができる。

【0040】

符号化装置１の内部の機能構成は、次の通りである。符号化装置１は、符号化部１１と、送信処理部１２とを含んで構成される。符号化装置１は、電子回路を用いて実現される。符号化装置１の一部がコンピューターとプログラムとで実現されてもよい。ただし、本実施形態における符号化装置１は、専用のハードウェアで実現される。符号化装置１の各部の機能は、次の通りである。

【0041】

符号化部１１は、入力される映像ストリームを符号化し、ＩＰパケットを出力する。

【0042】

送信処理部１２は、符号化部１１が生成したＩＰパケットを、外部に（図１の構成においてはネットワークスイッチ２に）送信する。

【0043】

復号化装置３の内部の機能構成は、次の通りである。図示したように、復号化装置３は、受信処理部３１と、復号化部３２と、送信処理部３３と、リソース管理部３４と、要求処理部３５と、受信要求部３６とを含んで構成される。これらの各機能部は、例えば、コンピューターと、プログラムとで実現することが可能である。また、各機能部は、必要に応じて、記憶手段を有する。記憶手段は、例えば、プログラム上の変数や、プログラムの実行によりアロケーションされるメモリーである。また、必要に応じて、磁気ハードディスク装置やソリッドステートドライブ（ＳＳＤ）といった不揮発性の記憶手段を用いるようにしてもよい。また、各機能部の少なくとも一部の機能を、プログラムではなく専用の電子回路として実現してもよい。各部の機能は、次の通りである。

【0044】

受信処理部３１は、外部から（図１の構成においてはネットワークスイッチ２から）ＩＰパケットを受信する。受信処理部３１が受信するＩＰパケットは、あらゆる種類のデータを伝送するものであってよい。ただし、受信処理部３１が受信するＩＰパケットには、符号化装置１において符号化された映像ストリームのデータを伝送するためのパケットが含まれる。つまり、受信処理部は、所定の符号化方式で符号化された映像ストリームを受信するものである。

【0045】

復号化部３２は、受信処理部３１が受信した映像ストリームを復号化して出力する。
つまり、復号化部３２は、受信処理部３１が受信した映像ストリームの復号化の処理を行い、復号化後の映像ストリームを出力するものである。本実施形態における復号化部３２は、コンピューターとプログラム（ソフトウェア）とで実現される。復号化部３２は、複数の映像ストリームの復号化の処理を同時並列的に行うことができる。復号化部３２においてそれぞれの映像ストリームの復号化処理に割り当てられる計算リソースは可変であり、後述するリソース管理部３４によってその割り当てが行われる。つまり、復号化部における特定の映像ストリームを復号化するためのリソースは、リソース管理部３４によって決定され、割り当てられる。復号化部３２の処理をコンピューターとプログラムとで実現した場合には、その処理（オペレーティングシステムが管理するプロセス（タスク等とも呼ばれる））へのリソースの割り当ては、比較的柔軟に行うことができ、且つ可変である。復号化部３２は、復号化後の映像のデータを、ＩＰパケットとして送信処理部３３に渡す。

【0046】

送信処理部３３は、ＩＰパケットを外部に送信する。送信処理部３３は、少なくとも、復号化部３２から渡される映像データの載せたＩＰパケットを、映像処理装置４Ａや４Ｂに向けて送信する。つまり、送信処理部３３は、復号化部３２が出力した復号化後の映像ストリームを外部に送信する。

【0047】

リソース管理部３４は、復号化部３２における処理のためのリソースの管理および割り当てを行う。リソース管理部３４は、復号化部３２が復号化する個々の映像ストリームごとに、割り当てるリソースの量を決定する。ここでのリソースとは、例えば、ＣＰＵのリソースである。より具体的には、リソース管理部３４は、個々の映像ストリームごとに、割り当てるスレッド数を決定し、割り当てを行う。リソース管理部３４は、復号化部３２が同時並行的に複数の映像ストリームの復号化処理を行う場合に、個々の映像ストリームごとに、その復号化処理のためのリソースを決定し、割り当てることができる。なお、リソース管理部３４が、さらにＣＰＵ以外のリソースを処理対象の個々の映像ストリームに割り当てるものであってもよい。

【0048】

具体的には、リソース管理部３４は、映像ストリームの復号化部での復号化の処理による遅延に対する要求である遅延要求に少なくとも応じて、復号化部３２の処理のためのリソースを決定し、決定されたリソースを当該映像ストリームの復号化の処理のために割り当てる。また、リソース管理部３４は、さらに、映像ストリームの映像フォーマットの種別にも応じて、復号化部３２の処理のためのリソースを決定し、決定されたリソースを当該映像ストリームの復号化の処理のために割り当てるものであってもよい。映像フォーマットは、例えば、映像に含まれるフレームの画素数（縦および横のそれぞれの画素数）等を規定するものである。映像フォーマットが異なれば、当然、符号化されている映像を復号化するための処理に要する計算量は変わる。リソース管理部３４は、映像処理装置４（送信処理部３３から送信される復号化後の映像ストリームを受信する映像処理装置）からの要求データに含まれる前記遅延要求を受け取るものであってよい。また、リソース管理部３４は、受信処理部３１からの、映像ストリームの映像フォーマットの種別の通知を（例えば要求処理部３５を経由して）受け取る。

【0049】

リソース管理部３４は、具体的には、復号化部３２の処理が記述されたプログラムを実行するプロセッサー（ＣＰＵ、ＧＰＵ、コア等と呼ばれる）におけるスレッド数を、映像ストリームの復号化の処理のためのリソースとして決定し、決定されたリソースを当該映像ストリームの復号化の処理のために割り当てる。

【0050】

上記の通り、リソース管理部３４は、少なくとも、送信先である映像処理装置４側からの遅延に関する要求に基づいて、個々の映像ストリームに割り当てるリソースの量を決定する。復号化部３２が処理対象とする映像ストリームのフォーマットがすべて同一である場合には、リソース管理部３４は、映像処理装置４側からの遅延要求のみに基づいて、個々の映像ストリームに割り当てるリソースの量を決定してもよい。

【0051】

リソース管理部３４は、さらに、映像フォーマットの種類に応じて、個々の映像ストリームに割り当てるリソースの量を決定してもよい。映像フォーマットが異なれば、復号化処理のための処理負荷も変わるためである。つまり、復号化部３２が同時に複数の種類の映像フォーマットの復号化を行う場合には、リソース管理部３４は、映像処理装置４側からの遅延要求のみに基づいて個々の映像ストリームに割り当てるリソースの量を決定するのではなく、映像フォーマットの種類にも基づいて割り当てるリソースの量を決定する。

【0052】

リソース管理部３４は、割り当てるリソースを決定するために、遅延要求の情報を、映像処理装置４側から取得する。また、リソース管理部３４は、割り当てるリソースを決定するために、映像フォーマットの種類を表す情報を、ネットワークスイッチ２側（符号化装置１側）から取得する。それらの情報を取得する手順については、後で図２や図３を参照しながら説明する。

【0053】

要求処理部３５は、映像処理装置４から、復号化の要求を受ける。このとき、映像処理装置４からの要求には、遅延に関する要求の情報が含まれる。つまり、要求処理部３５は、映像処理装置４からの要求データに基づいて、遅延要求をリソース管理部３４に通知することができる。

【0054】

受信要求部３６は、映像処理装置４から要求された映像が未受信である場合に、ネットワークスイッチ２に対して、当該映像ストリームの受信を要求する。

【0055】

次に、図２および図３を参照しながら、映像伝送システム１００の動作手順について説明する。

【0056】

図２は、映像伝送システム１００の動作手順の例を示すシーケンスチャートである。なお、この動作手順において、映像処理装置４Ａは、復号化装置３に対して、番組Ａの映像を要求する。また、映像処理装置４Ａは、映像を受信するためにマルチキャストアドレスを用いる。なお、映像処理装置４Ａが映像を要求した時点で、復号化装置３の受信処理部３１はまだその映像を受信していない。以下、このフローチャートに沿って説明する。

【0057】

ステップＳ１１において、映像処理装置４Ａは、要求機能データを復号化装置３の要求処理部３５に送信する。要求機能データは、要求する映像を受信するためのアドレスの情報を含む。要求処理部３５は、この要求機能データを受信する。

【0058】

ステップＳ１２において、要求処理部３５は、要求機能データ内のアドレスについて、受信処理部３１への問い合わせを行う。この問い合わせに応じて、受信処理部３１は、要求された映像を既に受信しているか否かを確認する。本例において復号化装置３はその映像をまだ受信していないため、受信処理部３１は、映像が未受信であることを要求処理部３５に回答する。要求処理部３５はその回答を受け取る。

【0059】

ステップＳ１３において、要求処理部３５は、映像処理装置４Ａからの要求機能データを受信要求部３６に伝達する。

【0060】

ステップＳ１４において、受信要求部３６は、ネットワークスイッチ２に対して、番組Ａの映像のマルチキャスト伝送を要求する。このとき、受信要求部３６は、ＩＧＭＰ（Internet Group Management Protocol）を用いてマルチキャスト伝送を要求する。ＩＧＭＰは、受信側である復号化装置３がネットワークスイッチ２に対してマルチキャストグループへの参加、維持、離脱を通知するために用いられるプロトコルである。

【0061】

ステップＳ１５において、ネットワークスイッチ２は、要求された映像の伝送を開始する。ネットワークスイッチ２から復号化装置３に伝送される映像のデータは、符号化装置１の符号化部１１によって符号化されたデータである。復号化装置３の受信処理部３１は、ネットワークスイッチ２がマルチキャスト伝送する映像のデータを受信する。

【0062】

ステップＳ１６において、受信処理部３１は、映像データを受信していることの確認と、その映像データのパラメーターとを、要求処理部３５に渡す。要求処理部３５は、それらの受信確認およびパラメーターを受け取る。ここでのパラメーターは、映像フォーマットの種別を表す情報を含む。

【0063】

ステップＳ１７において、要求処理部３５は、ステップＳ１６において受け取ったパラメーターの情報に基づき、リソース管理部３４に対して、復号化部３２の処理を実行するためのリソースの割り当てを要求する。ここで、リソース管理部３４が復号化部３２の処理に割り当てるリソースは、具体的には、例えばプロセッサーの処理時間（ＣＰＵ時間）である。また、リソース管理部３４が、実メモリーやその他の計算リソースを割り当てるようにしてもよい。

【0064】

ステップＳ１８において、リソース管理部３４は、ステップＳ１７におけるリソースの割り当てが完了した後に、復号化部３２に復号化処理を開始させる。これに基づき、復号化部３２は、リソース管理部３４によって割り当てられたリソースを使用した処理を開始する。具体的には、復号化部３２は、受信処理部３１が受信した映像データの復号化を開始する。復号化部３２は、復号化後の映像データを、順次、送信処理部３３に渡す。送信処理部３３は、復号化部３２から渡された復号化後の映像データを、要求元である映像処理装置４Ａに対して送信する。

【0065】

以上説明したように、図２に示した手順により、復号化装置３は、映像処理装置４Ａからの要求に基づいて、映像データの受信を開始し、受信した映像データの復号化の処理と、復号化後の映像データの映像処理装置４Ａへの伝送を行う。

【0066】

図３は、映像伝送システム１００の動作手順の別の例を示すシーケンスチャートである。以下、このフローチャートに沿って説明する。なお、この動作手順において、映像処理装置４Ｂは、復号化装置３に対して、番組Ｂの映像を要求する。また、映像処理装置４Ｂは、映像を受信するためにマルチキャストアドレスを用いる。なお、映像処理装置４Ｂが映像を要求した時点で、復号化装置３の受信処理部３１は既にその映像データを受信している。以下、このフローチャートに沿って説明する。

【0067】

ステップＳ２１において、映像処理装置４Ｂは、要求機能データを復号化装置３の要求処理部３５に送信する。要求機能データは、要求する映像を受信するためのアドレスの情報を含む。要求処理部３５は、この要求機能データを受信する。

【0068】

ステップＳ２２において、要求処理部３５は、要求機能データ内のアドレスについて、受信処理部３１への問い合わせを行う。この問い合わせに応じて、受信処理部３１は、要求された映像を既に受信しているか否かを確認する。本例において復号化装置３はその映像を既に受信している。受信処理部３１は、映像を既に受信していることを要求処理部３５に回答する。また、受信処理部３１は、その映像のパラメーターを、併せて、要求処理部３５に渡す。要求処理部３５はそれらの回答（パラメーターの情報を含む）を受け取る。

【0069】

ステップＳ２３において、要求処理部３５は、ステップＳ２２において受け取ったパラメーターの情報に基づき、リソース管理部３４に対して、復号化部３２の処理を実行するためのリソースの割り当てを要求する。ここで、リソース管理部３４が復号化部３２の処理に割り当てるリソースは、図２で説明した場合と同様に、例えばプロセッサーの処理時間（ＣＰＵ時間）である。また、リソース管理部３４が、実メモリーやその他の計算リソースを割り当てるようにしてもよい。

【0070】

ステップＳ２４において、リソース管理部３４は、ステップＳ２３におけるリソースの割り当てが完了した後に、復号化部３２に復号化処理を開始させる。これに基づき、復号化部３２は、リソース管理部３４によって割り当てられたリソースを使用した処理を開始する。具体的には、復号化部３２は、受信処理部３１が受信した映像データの復号化を開始する。復号化部３２は、復号化後の映像データを、順次、送信処理部３３に渡す。送信処理部３３は、復号化部３２から渡された復号化後の映像データを、要求元である映像処理装置４Ｂに対して送信する。

【0071】

なお、上記処理手順では、ネットワークスイッチ２は、マルチキャストによって映像データを配信する例を説明したが、映像データの配信はユニキャストによるものであってもよい。

【0072】

映像伝送システム１００において、符号化装置１および復号化装置３は、ＳＭＰＴＥ ＳＴ ２１１０の規格に準拠した圧縮映像ストリームの伝送を行う。そのため、符号化装置１から復号化装置３には、伝送に関するパラメーターを記述したＳＤＰファイルが伝送される。なお、ＳＤＰは、Session Description Protocolの略であり、ストリーミングのパラメーターを記述する書式である。符号化装置１や復号化装置３における処理に必要なリソースの量（サイズ）は、圧縮映像ストリームに含まれる映像のサイズやフォーマットといったパラメーターに依存するとともに、ストリームの伝送に対する遅延要求にも依存する。

【0073】

本実施形態においては、復号化装置３のリソース管理部３４は、符号化装置１から渡されるＳＤＰファイル内の映像データのパラメーターと、映像処理装置４側から渡される要求機能データとに基づいて、リソースの割り当てを行う。

【0074】

本実施形態では、映像処理装置４から復号化装置３に対して渡される要求機能データの記述にもＳＤＰファイルを用いる。映像処理装置４から復号化装置３に対して渡されるＳＤＰファイルは、ＲＦＣ４５６６の規定を拡張したものであり、圧縮映像ストリームのアドレスと、遅延要求のデータとを含む。

【0075】

図４は、ＳＤＰファイルが含む要求機能データの形式の例を示す概略図である。要求機能データは、メディア記述部に記述される。同図に示すデータの各行は、「ａ＝」で記述されるセッション情報である。同図の第１行目のデータは、映像処理装置４が要求する圧縮映像ストリームのアドレスを表す。第１行目の＜ｐａｙｌｏａｄ ｔｙｐｅ＞の箇所には、ペイロード値が記述される。第１行目の＜ＩＰ ａｄｄｒｅｓｓ＞の箇所には、映像ストリームの所在を表すＩＰアドレスが記述される。同図の第２行目のデータは、映像処理装置４が要求する遅延要求の程度を表す。第２行目の＜ｐａｙｌｏａｄ ｔｙｐｅ＞の箇所には、ペイロード値が記述される。第２行目の＜０～１０＞の箇所には、０以上１０以下の整数のいずれかの値が記述される。この値は遅延要求を表す数値である。０は遅延最小を表す。１０は遅延最大を表す。つまり、この値が小さい程、小さい遅延が要求される。また、この値が大きい程、遅延要求として大きい遅延を許容する。

【0076】

なお、図４に示した映像ストリームアドレスと遅延要求の記述以外についてのＳＤＰファイルの記述は、ＲＦＣ４５６６に基づく。

【0077】

復号化装置３のリソース管理部３４は、映像処理装置４側から受け取るＳＤＰファイル内に記述された要求機能データ内の遅延要求の値（０から１０までのいずれか）と、符号化装置１側から渡される圧縮映像ストリームに関連するＳＤＰファイル内の映像データのパラメーターとを参照する。リソース管理部３４は、参照した上記のパラメーター等に基づいて、遅延要求を満たすように、当該映像ストリームの復号化を行う復号化部３２へのリソースの割り当てを行う。

【0078】

具体的には、リソース管理部３４は、映像ストリームごとに、復号化部３２が復号化処理を行うためのスレッド数を割り当てる。なお、リソース管理部３４は、例えば、当該復号化装置３における、映像データのパラメーターと遅延要求との組合せに対応する適切なスレッド数の値を、予め記憶しておくようにする。あるいは、リソース管理部３４は、例えば、映像データのパラメーターと遅延要求との組合せに対応する適切なスレッド数の値を算出するための手順を実行できるようにしておいてもよい。

【0079】

前提として、復号化装置３は、例えば１台のコンピューターで実現される。１台のコンピューターは、１つまたは複数のＣＰＵを備える。１つのＣＰＵは、複数のコアを備えていてもよい。具体的には、１ＣＰＵが、例えば１コア、４コア、８コア、１０コア、１２コア等であってよい。また、１コアが、単一のスレッドまたは複数のスレッドを実行できるように構成されていてよい。コンピューターが持つハードウェア資源に応じて、例えば、４コア／４スレッド、４コア／８スレッド、８コア／６４スレッド、１０コア／８０スレッド、１２コア／９６スレッドなどといったスレッドでの構成が可能である。また、ここに例示したものとは異なる、他のスレッド構成であってもよい。

【0080】

また、スレッドとプロセス（タスク）との関係は、次の通りである。例えば、１スレッドを１つのプロセス（タスク）が占有してもよい。あるいは、複数のスレッドを１つのプロセス（タスク）が占有してもよい。あるいは、１スレッドを複数のプロセス（タスク）が共有してもよい。ここで、プロセス（タスク）とは、コンピューター上のリソースを管理するオペレーティングシステム（モニター等とも呼ばれる）によって管理される論理的な処理の単位である。

【0081】

なお、各コアは、所定のクロック周波数で動作し、実行可能形式のプログラムに含まれる命令を実行する。

【0082】

復号化装置３は、映像フォーマットと遅延要求とに応じて割り当てるべきスレッド数の情報を予め保持しておく。割り当てるべきスレッド数は、復号化処理の処理量（計算量）やハードウェアリソースの能力等に応じて予め求められ、復号化装置３内の所定の記憶手段に書き込まれている。なお、割り当てるべきスレッド数は、予め、理論的に、あるいは実環境に応じた実証等により、検証されている。復号化装置３のリソース管理部３４は、映像フォーマットおよび遅延要求を把握した後にその記憶手段を参照することによって、割り当てるべきスレッド数を決定することができる。

【0083】

図５は、ある特定の動作環境（コンピューター）を復号化装置３として機能させる場合の、映像ストリームのフォーマット（ここでは、２Ｋまたは４Ｋ）と、そのストリームの復号化処理（復号化部３２の処理）に割り当てるスレッド数との組合せに対する、復号化処理による遅延量（時間）の測定結果を示す概略図である。ここで、２Ｋとは、横１９２０画素×縦１０８０画素の画素配列で構成される映像のフォーマットである。また、４Ｋとは、横３８４０画素×縦２１６０画素の画素配列で構成される映像のフォーマットである。また、図示する遅延量の単位は、ミリ秒（ｍｓｅｃ）である。

【0084】

図示するように、図５は、２Ｋおよび４Ｋのそれぞれの映像フォーマットに対して、スレッド数が１，２，４，８，１２のそれぞれの場合の、復号化処理の遅延量（時間）を示している。映像フォーマットが２Ｋの場合には、上記それぞれのスレッド数の場合に、遅延量は、19.3ミリ秒、11.6ミリ秒、6.0ミリ秒、4.9ミリ秒、3.5ミリ秒である。映像フォーマットが４Ｋの場合には、上記それぞれのスレッド数の場合に、遅延量は、73.7ミリ秒、40.8ミリ秒、22.5ミリ秒、18.6ミリ秒、12.6ミリ秒である。なお、図５に示すデータは単なる例である。復号化装置３は、自装置の実際の処理能力に応じて、復号化処理に割り当てるスレッド数を決定する。

【0085】

図５の遅延量を前提とした場合に、映像フォーマットが２Ｋでフレームレートが６０ｆｐｓ（フレーム毎秒）・プログレッシブの映像について、復号化処理による遅延量（時間長）を１フレーム分（１／６０秒、即ち、約１６．６６７ミリ秒）以下にするためには、スレッド数として２以上を割り当てることが必要である。また、同様の映像について復号化処理による遅延量を２フレーム分（２／６０秒、即ち、約３３．３３３ミリ秒）以下にするためには、スレッド数として１以上を割り当てることが必要である。

【0086】

また、図５の遅延量を前提とした場合に、映像フォーマットが４Ｋでフレームレートが６０ｆｐｓ（フレーム毎秒）・プログレッシブの映像について、復号化処理による遅延量（時間長）を１フレーム分（１／６０秒、即ち、約１６．６６７ミリ秒）以下にするためには、スレッド数として１２以上を割り当てることが必要である。また、同様の映像について復号化処理による遅延量を２フレーム分（２／６０秒、即ち、約３３．３３３ミリ秒）以下にするためには、スレッド数として４以上を割り当てることが必要である。

【0087】

このように、復号化装置３のリソース管理部３４は、映像フォーマットと遅延要求に基づいて、復号化処理のために割り当てるスレッド数を決定することができる。また、リソース管理部３４は、決定したスレッド数でその映像の復号化処理を行うように、復号化部３２を制御する。これにより、復号化部３２は、受信処理部３１から渡される映像データの復号化処理を、映像処理装置４側からの要求に見合う遅延量で実行し、復号化後の映像データを送信処理部３３に渡すことができる。また、送信処理部３３は、その復号化後の映像データを、要求元の映像処理装置４に送信することができる。

【0088】

以上のように、復号化装置３のリソース管理部３４は、符号化装置１や映像処理装置４から渡されるデータ（ＳＤＰファイル）の内容に応じて、復号化処理に適したリソース（ＣＰＵ等）を復号化部３２に割り当てることができる。つまり、リソース管理部３４は、外部から受信したデータに基づいて、遅延要求を満たす復号化処理のリソースを自動的に割り当てることができる。また、復号化部３２は、遅延要求を満足しながら、映像ストリームの復号化処理を行うことができる。

【0089】

本実施形態の処理方法により、復号化装置３は、映像を要求する側（映像処理装置４側）からの要求に基づいて、復号化処理に必要なリソースを自動的に割り当てることができる。つまり、復号化装置３は、コンピューターの処理能力を効率的に利用した処理を行うことができる。つまり、復号化装置３は、ハードウェアのみによる処理を行うように構成する場合に比べて、計算資源を柔軟に復号化処理に割り当てることができる。また、ハードウェアのみによって復号化装置を構成する場合と比べて、本実施形態の復号化装置３は、映像フォーマットごとの専用の装置を用意する必要がない。本実施形態の復号化装置３は、汎用機材（コンピューター）を用いて実現できるため、柔軟性が高く、低コスト化が可能である。また、本実施形態の復号化装置３は、様々な遅延要求に対して柔軟に対応できる。つまり、放送番組を制作する現場等において、様々な遅延要求を持つ様々な番組で利用可能な伝送システム（符号化装置および復号化装置を含む）を実現することが可能となる。

【0090】

図６は、本実施形態の映像伝送システムを構成する各装置の内部構成の例を示すブロック図である。各装置（符号化装置１、ネットワークスイッチ２、復号化装置３、映像処理装置４Ａ，４Ｂ）の少なくとも一部は、コンピューターを用いて実現され得る。図示するように、そのコンピューターは、中央処理装置９０１と、ＲＡＭ９０２と、入出力ポート９０３と、入出力デバイス９０４や９０５等と、バス９０６と、を含んで構成される。コンピューター自体は、既存技術を用いて実現可能である。中央処理装置９０１は、ＲＡＭ９０２等から読み込んだプログラムに含まれる命令を実行する。中央処理装置９０１は、各命令にしたがって、ＲＡＭ９０２にデータを書き込んだり、ＲＡＭ９０２からデータを読み出したり、算術演算や論理演算を行ったりする。ＲＡＭ９０２は、データやプログラムを記憶する。ＲＡＭ９０２に含まれる各要素は、アドレスを持ち、アドレスを用いてアクセスされ得るものである。なお、ＲＡＭは、「ランダムアクセスメモリー」の略である。入出力ポート９０３は、中央処理装置９０１が外部の入出力デバイス等とデータのやり取りを行うためのポートである。入出力デバイス９０４や９０５は、入出力デバイスである。入出力デバイス９０４や９０５は、入出力ポート９０３を介して中央処理装置９０１との間でデータをやりとりする。バス９０６は、コンピューター内部で使用される共通の通信路である。例えば、中央処理装置９０１は、バス９０６を介してＲＡＭ９０２のデータを読んだり書いたりする。また、例えば、中央処理装置９０１は、バス９０６を介して入出力ポートにアクセスする。

【0091】

なお、上述した実施形態における符号化装置１、ネットワークスイッチ２、復号化装置３、映像処理装置４Ａ，４Ｂの少なくともいずれかの機能をコンピューターおよびプログラムで実現することができる。その場合、この機能を実現するためのプログラムをコンピューター読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピューターシステムに読み込ませ、実行することによって実現しても良い。なお、ここでいう「コンピューターシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピューター読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、ＵＳＢメモリー等の可搬媒体、コンピューターシステムに内蔵されるハードディスク等の記憶装置のことをいう。つまり、「コンピューター読み取り可能な記録媒体」とは、非一過性の（non-transitory）コンピューター読み取り可能な記録媒体であってよい。さらに「コンピューター読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、一時的に、動的にプログラムを保持するもの、その場合のサーバーやクライアントとなるコンピューターシステム内部の揮発性メモリーのように、一定時間プログラムを保持しているものも含んでも良い。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピューターシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。

【0092】

以上説明したように、本実施形態の映像伝送システム１００は、映像処理装置４側からの遅延要求に基づいて適切なリソースの割り当てを自動的に行うことができる。

【0093】

本実施形態では、符号化装置１を専用ハードウェアで実現し、復号化装置３を汎用コンピューター上でソフトウェア（プログラム）を稼働させることによって実現する。これにより、トータルコストを抑制しながら、幅広い遅延要求に対応することができるようになる。

【0094】

また、本実施形態では、遅延要求（許容される遅延の量を、例えば数値（０から１０までの整数等）で表わしたデータ）を含む要求機能データを、映像処理装置４（放送機器等）から復号化装置３のリソース管理部３４に送る。これにより、リソース管理部３４は、要求を満たすためのリソースを、復号化部３２による復号化処理のために自動的に割り当てる。したがって、本実施形態の映像伝送システム１００では、効率的なリソース割当が可能となる。

【0095】

また、本実施形態によれば、符号化装置１における符号化処理の機能を専用ハードウェアで実現し、復号化装置３における復号化処理の機能を汎用コンピューターとソフトウェアで実現する。また、ＩＰによる映像伝送を用いた放送番組等の制作において、映像の復号化処理を求める放送機器（映像処理装置４）は、復号化装置３に映像の復号化処理を求める。復号化装置３においては、リソース管理部３４は、放送機器（映像処理装置４）側から受け取る遅延要求に応じて、復号化処理に必要なリソース（ＣＰＵコア、スレッド、ＣＰＵ時間）を自動的に割り当てることが可能となる。即ち、復号化装置３を実現するための汎用コンピューターのリソースを、自動的に復号化処理に割り当てることが可能となる。これにより、符号化装置１および復号化装置３の効率的な運用が可能となる。また、復号化装置は、放送機器（映像処理装置４）側からの様々な遅延要求に対応することが可能となる。また、復号化装置は、様々な映像フォーマットの復号化処理に柔軟に対応することが可能となる。これにより、映像伝送システム１００の全体において、機材コストの低減が可能となる。

【0096】

以上、実施形態を説明したが、本発明はさらに次のような変形例でも実施することが可能である。

【0097】

映像伝送システム１００では、各装置間の通信でＩＰを用いた。しかしながら、同様の改装における通信のためにＩＰ以外のプロトコルを用いるようにしてもよい。

【0098】

上記実施形態では、リソース管理部３４は、映像処理装置４側から送信されたデータに含まれる遅延要求の情報に基づいて、符号化処理のためのリソースを決定し、そのリソースの割り当てを行った。しかしながら、リソース管理部３４は、映像処理装置４以外の他の装置から発せられる遅延要求の情報に基づいて上記リソースを決定してもよい。

【0099】

上記実施形態では、映像フォーマットの種別に関する情報は、受信処理部３１から、要求処理部３５を経由して、リソース管理部３４に通知された。しかしながら、リソース管理部３４は、他の箇所（情報源）から映像フォーマットの種別に関する情報を取得してもよい。

【0100】

なお、複数の変形例を、組み合わせることが可能な限りにおいて、組み合わせて実施してもよい。

【0101】

以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。

【産業上の利用可能性】

【0102】

本発明は、映像の復号化処理に利用することができる。本発明は、例えば、ＩＰによる伝送を用いた放送番組の制作等に利用することができる。但し、本発明の利用範囲はここに例示したものには限られない。

【符号の説明】

【0103】

１ 符号化装置
２ ネットワークスイッチ
３ 復号化装置
４Ａ，４Ｂ 映像処理装置
１１ 符号化部
１２ 送信処理部
３１ 受信処理部
３２ 復号化部
３３ 送信処理部
３４ リソース管理部
３５ 要求処理部
３６ 受信要求部
１００ 映像伝送システム
９０１ 中央処理装置
９０２ ＲＡＭ
９０３ 入出力ポート
９０４，９０５ 入出力デバイス
９０６ バス

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】