JP6492661B2 - 画像処理装置および方法 - Google Patents

Description

本開示は、画像処理装置および方法に関し、特に、伝送する際に用いるストリーム又はファイルに格納する際に用いるストリームを生成する際の処理の負担を軽減することができるようにした画像処理装置および方法に関する。

画像符号化方式の標準仕様の１つであるＨ．２６４／ＡＶＣでは、画像の符号化及び復号のために用いられるパラメータを格納するためのシーケンスパラメータセット（ＳＰＳ）及びピクチャパラメータセット（ＰＰＳ）という２種類のパラメータセットが定義されている。各スライスの画像データがＶＣＬ（Video Coding Layer） ＮＡＬ（Network Abstraction Layer）ユニットに分類される一方で、これらパラメータセットは非ＶＣＬ ＮＡＬユニットに分類される。通常、Ｈ．２６４／ＡＶＣ方式で符号化された符号化ストリームがヘッダ領域及びデータ領域を含むファイルに格納される場合、ＳＰＳ及びＰＰＳはヘッダ領域に、画像データはデータ領域に挿入される。

Ｈ．２６４／ＡＶＣに続く次世代の画像符号化方式であるＨＥＶＣ（High Efficiency Video Coding）の標準化作業では、ＳＰＳ及びＰＰＳとは異なる新たなパラメータセットである適応パラメータセット（ＡＰＳ：Adaptation Parameter Set）を導入することが提案されている（下記非特許文献１、２参照）。

ＡＰＳもまたパラメータセットの一種である。従って、既存の手法によれば、ＳＰＳ及びＰＰＳと同様、ＡＰＳもファイルのヘッダ領域に挿入されることになる。ヘッダ領域及びデータ領域を含むファイルフォーマットの一例として、ＭＰＥＧ−４ Ｐａｒｔ１４（ＩＳＯ／ＩＥＣ１４４９６−１４：２００３、以下、ＭＰ４という）フォーマット、ＭＰＥＧ−４ Ｐａｒｔ１５（ＩＳＯ／ＩＥＣ１４４９６−１５：２００４、ＡＶＣファイル）フォーマットが挙げられる。

Stephan Wenger， Jill Boyce， Yu-Wen Huang， Chia-Yang Tsai， Ping Wu， Ming Li， "Adaptation Parameter Set (APS)"， JCTVC-F747r3, July 2011 Benjamin Bross, Woo-Jin Han, Jens-Rainer Ohm, Gary J. Sullivan, Thomas Wiegand, "High efficiency video coding (HEVC) text specification draft 6"， JCTVC-H1003 ver20, February 2012

しかしながら、伝送する際に用いるストリーム又はファイルに格納する際に用いるストリームを生成する場合に、startcodeとfiller dataなどのデータをストリームとして含むことが許容されないフォーマットがある。したがって、ストリームのデータを読み込む際に、処理負荷の要因になっている。

本開示は、このような状況に鑑みてなされたものであり、伝送する際のストリーム又はファイルに格納する際のストリームを生成する際の処理の負担を軽減するものである。

本開示の第１の側面の画像処理装置は、画像を符号化したビットストリームを含むファイルのmedia dataを対象として、filler dataを設定する設定部と、前記filler dataの設定により、前記media data において、HRD(Hypothetical Reference Decoder)パラメータの特性を保持してファイルを構成するように、前記設定部を制御する制御部とを備える。

前記HDR(Hypothetical Reference Decoder)パラメータは、VUI(Video Usability Information)に含まれるパラメータ、またはbuffering period SEI（Supplemental Enhancement Information）に含まれるパラメータ、または、picture timing SEIに含まれるパラメータである。

前記設定部は、filler dataを、VCLデータとして設定することができる。

本開示の第１の側面の画像処理方法は、画像処理装置が、画像を符号化したビットストリームを含むファイルのmedia dataを対象として、filler dataを設定し、前記filler dataの設定により、前記media data において、HRD(Hypothetical Reference Decoder)パラメータの特性を保持してファイルを構成するように、前記filler dataの設定を制御する。

本開示の第２の側面の画像処理装置は、画像を符号化したビットストリームを含むファイルのmedia dataにおいて設定されていたfiller dataがビットストリームから削除された場合に、前記filler dataの設定により保持されていたHRD(Hypothetical Reference Decoder)パラメータの特性を設定する設定部と、前記設定部により設定された特性を用いて、前記ファイルを生成する生成部とを備える。

前記設定部は、前記HDR(Hypothetical Reference Decoder)パラメータの特性が変更されたことを識別する識別パラメータを設定することができる。

前記設定部は、前記識別パラメータを、前記ファイルのサンプルエントリにおけるオプショナルボックスとして設定することができる。

本開示の第２の側面の画像処理方法は、画像処理装置が、画像を符号化したビットストリームを含むファイルのmedia dataにおいて設定されていたfiller dataがビットストリームから削除された場合に、前記filler dataの設定により保持されていたHRD(Hypothetical Reference Decoder)パラメータの特性を設定し、設定された特性を用いて、前記ファイルを生成する。

本開示の第１の側面においては、画像を符号化したビットストリームを含むファイルのmedia dataを対象として、filler dataが設定され、前記filler dataの設定により、前記media data において、HRD(Hypothetical Reference Decoder)パラメータの特性を保持してファイルを構成するように、前記filler dataの設定が制御される。

本開示の第２の側面においては、画像を符号化したビットストリームを含むファイルのmedia dataにおいて設定されていたfiller dataがビットストリームから削除された場合に、前記filler dataの設定により保持されていたHRD(Hypothetical Reference Decoder)パラメータの特性が設定され、設定された特性を用いて、前記ファイルが生成される。

本開示の第４の側面においては、画像を符号化したビットストリームを含むファイルのmedia dataにおいて、startcodeとfiller dataがビットストリームから削除された場合に、デコーダバッファを管理するパラメータの特性が設定され、設定された特性を用いて生成されているファイルが受け取られる。そして、受け取られたファイルから、前記デコーダバッファを管理するパラメータが読み取られ、読み取ったパラメータを用いて前記ビットストリームが復号される。

なお、上述の画像処理装置は、独立した装置であっても良いし、１つの画像符号化装置または画像復号装置を構成している内部ブロックであってもよい。

本開示の第１および第２の側面によれば、画像を符号化することができる。特に、ビットストリームを伝送する際に用いるストリーム又はファイルに格納する際に用いるストリームを生成する際の処理の負担を軽減することができる。

本技術を適用した符号化装置の第１実施の形態の構成例を示すブロック図である。 エンコーダの構成例を示すブロック図である。 ファイル生成部の構成例を示すブロック図である。 ファイル生成処理を説明するフローチャートである。 ファイル生成処理の他の例を説明するフローチャートである。 従来のmdatデータの生成処理を説明するフローチャートである。 本技術のmdatデータの生成処理を説明するフローチャートである。 本技術を適用した復号装置の第１実施の形態の構成例を示すブロック図である。 ファイル読取部の構成例を示すブロック図である。 デコーダの構成例を示すブロック図である。 ファイル復号処理を説明するフローチャートである。 ファイル復号処理の他の例を説明するフローチャートである。 本技術を適用した符号化装置の第２実施の形態の構成例を示すブロック図である。 本技術を適用した復号装置の第２実施の形態の構成例を示すブロック図である。 従来のMP4ビデオサンプル構造の例を示す図である。 AVCストリームの１アクセスユニットの構成例を示す図である。 本技術のMP4ビデオサンプル構造の例を示す図である。 本技術のMP4ビデオサンプル構造の他の例を示す図である。 HRD Conformance Box拡張の例を示す図である。 本技術のMP4ビデオサンプル構造のさらに他の例を示す図である。 Sample tableに追加されるBOXの例を示す図である。 図２０のMP4ビデオサンプル構造の他の例を示す図である。 図２０のMP4ビデオサンプル構造のさらに他の例を示す図である。 サンプル補助情報機能のフォーマットの例を示す図である。 サンプル補助情報機能のフォーマットの他の例を示す図である。 本技術のMP4ビデオサンプル構造の例を比較する図である。 図２３のMP4ビデオサンプル構造の他の例を示す図である。 バイトストリームフォーマットインフォメーションボックスの例を示す図である。 バイトストリームフォーマットインフォメーションボックスの他の例を示す図である。 各サンプルエントリに格納されるバイトストリームフォーマットインフォメーションのデータ構造例を説明する図である。 パターン１の場合のMP4ビデオサンプル構造の例を示す図である。 パターン２の場合のMP4ビデオサンプル構造の例を示す図である。 パターン３の場合のMP4ビデオサンプル構造の例を示す図である。 各サンプルエントリに格納されるバイトストリームフォーマットインフォメーションのデータ構造の他の例を説明する図である。 本技術を適用したファイル変換装置の構成例を示す図である。 ファイル変換処理を説明するフローチャートである。 本技術を適用した符号化装置の第３実施の形態の構成例を示すブロック図である。 エンコーダの構成例を示すブロック図である。 本技術を適用した復号装置の第３実施の形態の構成例を示すブロック図である。 デコーダの構成例を示すブロック図である。 コンピュータの構成例を示すブロック図である。 テレビジョン装置の概略的な構成の一例を示すブロック図である。 携帯電話機の概略的な構成の一例を示すブロック図である。 記録再生装置の概略的な構成の一例を示すブロック図である。 撮像装置の概略的な構成の一例を示すブロック図である。 ビデオセットの概略的な構成の一例を示すブロック図である。 ビデオプロセッサの概略的な構成の一例を示すブロック図である。 ビデオプロセッサの概略的な構成の他の例を示すブロック図である。

以下、本開示を実施するための形態（以下実施の形態とする）について説明する。なお、説明は以下の順序で行う。
１．第１の実施の形態（HEVC方式の符号化装置、復号装置）
２．第２の実施の形態（画像符号化装置、画像復号装置）
３．第３の実施の形態（MP4ビデオサンプル構造）
４．第４の実施の形態（バイトストリームフォーマットインフォメーションボックス）
５．第５の実施の形態（ファイル変換装置）
６．第６の実施の形態（AVC方式の符号化装置、復号装置）
７．応用例
８．第７の実施の形態（セット・ユニット・モジュール・プロセッサ）

＜１．第１の実施の形態＞
［符号化装置の第１実施の形態の構成例］
図１は、本技術を適用した画像処理装置としての、符号化装置の第１実施の形態の構成例を示すブロック図である。

図１の符号化装置は、エンコーダ１およびファイル生成部２により構成され、撮影(Captured)画像等の画像をHEVC方式で符号化し、符号化されたストリームを格納するファイルを生成する。

具体的には、符号化装置のエンコーダ１には、フレーム単位の撮影画像等の画像が入力信号として入力される。また、図示せぬエンコーダ１の前段で設定されたSPS（Sequence Parameter Set）、PPS（Picture Parameter Set）、符号化データに対応する画像の特性（ユーザビリティ）をシーケンスごとに示すVUI(Video Usability Information)、SEI（Supplemental Enhancement Information）なども入力される。

エンコーダ１は、SPS、PPS、VUI、SEIに含まれるパラメータを用いて、入力信号をHEVC方式で符号化する。そして、エンコーダ１は、SPS、PPS、VUI、SEIと、その結果得られる符号化データとから、MPEG-2 TS(Transport Stream)などの符号化ストリームを生成し、生成した符号化ストリームを、ファイル生成部２に供給する。エンコーダ１の詳細は、図２を参照して後述される。

ファイル生成部２は、エンコーダ１からの符号化ストリーム（符号化された一連の画像データ）を格納するファイル（例えば、ＭＰＥＧ−４ Ｐａｒｔ１４（ＩＳＯ／ＩＥＣ１４４９６−１４：２００３、以下、ＭＰ４という）のファイル）を生成する。ファイル生成部２の詳細は、図３を参照して後述される。

［エンコーダの構成例］
図２は、図１のエンコーダ１の構成例を示すブロック図である。エンコーダ１の各部は、図示せぬ前段からのSPS、PPS、VUI、SEIに含まれるパラメータを用いて、入力信号である画像を符号化し、符号化ストリームを生成する。

図２のエンコーダ１は、A/D変換部１１、画面並べ替えバッファ１２、演算部１３、直交変換部１４、量子化部１５、可逆符号化部１６、蓄積バッファ１７、逆量子化部１８、逆直交変換部１９、加算部２０、デブロックフィルタ２１、フレームメモリ２２、スイッチ２３、イントラ予測部２４、動き予測・補償部２５、予測画像選択部２６、およびレート制御部２７を含むように構成される。

さらに、デブロックフィルタ２１およびフレームメモリ２２の間には、適応オフセットフィルタ４１と適応ループフィルタ４２が備えられている。

具体的には、エンコーダ１のA/D変換部１１は、入力信号として入力されたフレーム単位の画像をA/D変換し、画面並べ替えバッファ１２に出力して記憶させる。画面並べ替えバッファ１２は、記憶した表示の順番のフレーム単位の画像を、GOP（Group of Picture）構造に応じて、符号化のための順番に並べ替え、演算部１３、イントラ予測部２４、および動き予測・補償部２５に出力する。

演算部１３は、予測画像選択部２６から供給される予測画像と、画面並べ替えバッファ１２から出力された符号化対象の画像の差分を演算することにより符号化を行う。具体的には、演算部１３は、画面並べ替えバッファ１２から出力された符号化対象の画像から、予測画像選択部２６から供給される予測画像を減算することにより符号化を行う。演算部１３は、その結果得られる画像を、残差情報として直交変換部１４に出力する。なお、予測画像選択部２６から予測画像が供給されない場合、演算部１３は、画面並べ替えバッファ１２から読み出された画像をそのまま残差情報として直交変換部１４に出力する。

直交変換部１４は、演算部１３からの残差情報に対して直交変換を施し、直交変換の結果得られる係数を量子化部１５に供給する。

量子化部１５は、直交変換部１４から供給される係数を量子化する。量子化された係数は、可逆符号化部１６に入力される。

可逆符号化部１６は、最適イントラ予測モードを示す情報（以下、イントラ予測モード情報という）をイントラ予測部２４から取得する。また、最適インター予測モードを示す情報（以下、インター予測モード情報という）、動きベクトル、参照画像を特定するための情報などを動き予測・補償部２５から取得する。また、可逆符号化部１６は、適応オフセットフィルタ４１から格納フラグ、インデックスまたはオフセット、および種類情報をオフセットフィルタ情報として取得し、適応ループフィルタ４２からフィルタ係数を取得する。

可逆符号化部１６は、量子化部１５から供給される量子化された係数に対して、可変長符号化（例えば、CAVLC（Context-Adaptive Variable Length Coding）など）、算術符号化（例えば、CABAC（Context-Adaptive Binary Arithmetic Coding）など）などの可逆符号化を行う。

また、可逆符号化部１６は、イントラ予測モード情報、または、インター予測モード情報、動きベクトル、参照画像を特定する情報、オフセットフィルタ情報、およびフィルタ係数などを、符号化に関する符号化情報として可逆符号化する。可逆符号化部１６は、可逆符号化された符号化情報と係数とから、符号化ストリームを生成して蓄積バッファ１７に供給し、蓄積させる。なお、可逆符号化された符号化情報は、可逆符号化された係数のヘッダ情報とされてもよい。

蓄積バッファ１７は、可逆符号化部１６から供給される符号化ストリームを、一時的に記憶する。また、蓄積バッファ１７は、記憶している符号化ストリームを、図１のファイル生成部２に供給する。

また、量子化部１５より出力された、量子化された係数は、逆量子化部１８にも入力され、逆量子化された後、逆直交変換部１９に供給される。

逆直交変換部１９は、逆量子化部１８から供給される係数に対して逆直交変換を施し、その結果得られる残差情報を加算部２０に供給する。

加算部２０は、逆直交変換部１９から供給される復号対象の画像としての残差情報と、予測画像選択部２６から供給される予測画像を加算して、局部的に復号された画像を得る。なお、予測画像選択部２６から予測画像が供給されない場合、加算部２０は、逆直交変換部１９から供給される残差情報を局部的に復号された画像とする。加算部２０は、局部的に復号された画像をデブロックフィルタ２１に供給するとともに、フレームメモリ２２に供給して蓄積させる。

デブロックフィルタ２１は、加算部２０から供給される局部的に復号された画像をフィルタリングすることにより、ブロック歪を除去する。デブロックフィルタ２１は、その結果得られる画像を適応オフセットフィルタ４１に供給する。

適応オフセットフィルタ４１は、デブロックフィルタ２１による適応デブロックフィルタ処理後の画像に対して、主にリンギングを除去する適応オフセットフィルタ(SAO: Sample adaptive offset)処理を行う。

より詳細には、適応オフセットフィルタ４１は、最大の符号化単位であるLCU（Largest Coding Unit）ごとに適応オフセットフィルタ処理の種類を決定し、その適応オフセットフィルタ処理で用いられるオフセットを求める。適応オフセットフィルタ４１は、求められたオフセットを用いて、適応デブロックフィルタ処理後の画像に対して、決定された種類の適応オフセットフィルタ処理を行う。そして、適応オフセットフィルタ４１は、適応オフセットフィルタ処理後の画像を適応ループフィルタ４２に供給する。

また、適応オフセットフィルタ４１は、オフセットを格納するバッファを有している。適応オフセットフィルタ４１は、LCUごとに、適応デブロックフィルタ処理に用いられたオフセットが既にバッファに格納されているかどうかを判定する。

適応オフセットフィルタ４１は、適応デブロックフィルタ処理に用いられたオフセットが既にバッファに格納されていると判定した場合、オフセットがバッファに格納されているかを示す格納フラグを、オフセットがバッファに格納されていることを示す値（ここでは１）に設定する。

そして、適応オフセットフィルタ４１は、LCUごとに、１に設定された格納フラグ、バッファにおけるオフセットの格納位置を示すインデックス、および、行われた適応オフセットフィルタ処理の種類を示す種類情報を可逆符号化部１６に供給する。

一方、適応オフセットフィルタ４１は、適応デブロックフィルタ処理に用いられたオフセットがまだバッファに格納されていない場合、そのオフセットを順にバッファに格納する。また、適応オフセットフィルタ４１は、格納フラグを、オフセットがバッファに格納されていないことを示す値（ここでは０）に設定する。そして、適応オフセットフィルタ４１は、LCUごとに、０に設定された格納フラグ、オフセット、および種類情報を可逆符号化部１６に供給する。

適応ループフィルタ４２は、適応オフセットフィルタ４１から供給される適応オフセットフィルタ処理後の画像に対して、例えば、LCUごとに、適応ループフィルタ（ALF:Adaptive Loop Filter)処理を行う。適応ループフィルタ処理としては、例えば、２次元のウィナーフィルタ（Wiener Filter）による処理が用いられる。もちろん、ウィナーフィルタ以外のフィルタが用いられてもよい。

具体的には、適応ループフィルタ４２は、LCUごとに、画面並べ替えバッファ１２から出力される画像である原画像と適応ループフィルタ処理後の画像の残差が最小となるように、適応ループフィルタ処理で用いられるフィルタ係数を算出する。そして、適応ループフィルタ４２は、適応オフセットフィルタ処理後の画像に対して、算出されたフィルタ係数を用いて、LCUごとに適応ループフィルタ処理を行う。

適応ループフィルタ４２は、適応ループフィルタ処理後の画像をフレームメモリ２２に供給する。また、適応ループフィルタ４２は、フィルタ係数を可逆符号化部１６に供給する。

なお、ここでは、適応ループフィルタ処理は、LCUごとに行われるものとするが、適応ループフィルタ処理の処理単位は、LCUに限定されない。但し、適応オフセットフィルタ４１と適応ループフィルタ４２の処理単位を合わせることにより、処理を効率的に行うことができる。

フレームメモリ２２に蓄積された画像は、参照画像としてスイッチ２３を介してイントラ予測部２４または動き予測・補償部２５に出力される。

イントラ予測部２４は、フレームメモリ２２からスイッチ２３を介して読み出されたデブロックフィルタ２１でフィルタリングされていない参照画像を用いて、タイルおよびスライス単位で、候補となる全てのイントラ予測モードのイントラ予測処理を行う。

また、イントラ予測部２４は、画面並べ替えバッファ１２から読み出された画像と、イントラ予測処理の結果生成される予測画像とに基づいて、候補となる全てのイントラ予測モードに対してコスト関数値（詳細は後述する）を算出する。そして、イントラ予測部２４は、コスト関数値が最小となるイントラ予測モードを、最適イントラ予測モードに決定する。

イントラ予測部２４は、最適イントラ予測モードで生成された予測画像、および、対応するコスト関数値を、予測画像選択部２６に供給する。イントラ予測部２４は、予測画像選択部２６から最適イントラ予測モードで生成された予測画像の選択が通知された場合、イントラ予測モード情報を可逆符号化部１６に供給する。

なお、コスト関数値は、RD(Rate Distortion)コストともいい、例えば、H．264/AVC方式における参照ソフトウエアであるJM(Joint Model)で定められているような、High Complexity モードか、Low Complexity モードのいずれかの手法に基づいて算出される。

具体的には、コスト関数値の算出手法としてHigh Complexity モードが採用される場合、候補となる全ての予測モードに対して、仮に可逆符号化までが行われ、次の式（１）で表わされるコスト関数値が各予測モードに対して算出される。

Cost(Mode)=D＋λ・R ・・・（１）

Dは、原画像と復号画像の差分（歪）、Rは、直交変換の係数まで含んだ発生符号量、λは、量子化パラメータQPの関数として与えられるラグランジュ乗数である。

一方、コスト関数値の算出手法としてLow Complexity モードが採用される場合、候補となる全ての予測モードに対して、復号画像の生成、および、予測モードを示す情報などのヘッダビットの算出が行われ、次の式（２）で表わされるコスト関数値が各予測モードに対して算出される。

Cost(Mode)=D＋QPtoQuant(QP)・Header_Bit ・・・（２）

Dは、原画像と復号画像の差分（歪）、Header_Bitは、予測モードに対するヘッダビット、QPtoQuantは、量子化パラメータQPの関数として与えられる関数である。

Low Complexity モードにおいては、全ての予測モードに対して、復号画像を生成するだけでよく、可逆符号化を行う必要がないため、演算量が少なくて済む。

動き予測・補償部２５は、タイルおよびスライス単位で、候補となる全てのインター予測モードの動き予測・補償処理を行う。具体的には、動き予測・補償部２５は、タイルおよびスライス単位で、画面並べ替えバッファ１２から供給される画像と、フレームメモリ２２からスイッチ２３を介して読み出されるフィルタリングされた参照画像に基づいて、候補となる全てのインター予測モードの動きベクトルを検出する。そして、動き予測・補償部２５は、タイルおよびスライス単位で、その動きベクトルに基づいて参照画像に補償処理を施し、予測画像を生成する。

このとき、動き予測・補償部２５は、画面並べ替えバッファ１２から供給される画像と予測画像とに基づいて、候補となる全てのインター予測モードに対してコスト関数値を算出し、コスト関数値が最小となるインター予測モードを最適インター測モードに決定する。そして、動き予測・補償部２５は、最適インター予測モードのコスト関数値と、対応する予測画像を予測画像選択部２６に供給する。また、動き予測・補償部２５は、予測画像選択部２６から最適インター予測モードで生成された予測画像の選択が通知された場合、インター予測モード情報、対応する動きベクトル、参照画像を特定する情報などを可逆符号化部１６に出力する。

予測画像選択部２６は、イントラ予測部２４および動き予測・補償部２５から供給されるコスト関数値に基づいて、最適イントラ予測モードと最適インター予測モードのうちの、対応するコスト関数値が小さい方を、最適予測モードに決定する。そして、予測画像選択部２６は、最適予測モードの予測画像を、演算部１３および加算部２０に供給する。また、予測画像選択部２６は、最適予測モードの予測画像の選択をイントラ予測部２４または動き予測・補償部２５に通知する。

レート制御部２７は、蓄積バッファ１７に蓄積された符号化データに基づいて、オーバーフローあるいはアンダーフローが発生しないように、量子化部１５の量子化動作のレートを制御する。

［背景と問題点］
ISO/IEC 14496-15において規定されているAVCファイルフォーマットでは、startcodeとfiller dataとを、ビットストリーム(Elementary Stream)に含めることが許容されていない。しかしながら、ISO base media file format及びMPEG-2 TS(Transport Stream)などのデータを扱う際の処理負荷を増大する要因となっている。

また、ビットストリーム(Elementary Stream)からMPEG-2 TSを生成(変換)するためには、startcodeとfiller data（データサイズを調整するためのダミーデータ）とが除去されることにより、デコーダバッファを管理するパラメータの値が異なる場合がある。これにより、例えば、buffering period SEI(Supplemental enhancement information)を再設定する必要があり、ビットストリームを変換する際の処理負荷の増大につながる。

［ファイル生成部の動作］
そこで、ファイル生成部２は、伝送する際に用いるストリーム又はファイルに格納する際に用いるストリームを生成する場合に、画像を符号化したビットストリームを含むファイルを対象として、startcodeとfiller dataとを設定し、設定されたstartcodeとfiller dataとを、ファイルのmedia dataにおいて、デコーダバッファを管理するパラメータの特性を保持してファイルを構成するように、startcodeとfiller dataとの設定を制御するようにした。

また、ファイル生成部２は、画像を符号化したビットストリームを含むファイルのmedia dataにおいて、startcodeとfiller dataが削除された場合に、デコーダバッファを管理するパラメータの特性を設定し、設定された特性を用いて、ファイルを生成するようにした。

なお、デコーダバッファを管理するパラメータは、HRD parameter（Hypothetical Reference Decoder Parameter）、すなわち、仮想参照デコーダを管理するパラメータである。このデコーダバッファを管理するパラメータは、VUIにあるパラメータ、buffering period SEIにあるパラメータ、または、picture timing SEIにあるパラメータである。

以上のようにすることで、伝送する際、または、ファイルへ格納する際のストリームを生成(変換)する場合に、startcodeとfiller dataとを再設定する必要がなくなり、処理の負担を軽減することができる。

なお、filler dataについては、次のようにすることで、対応することも可能である。すなわち、AVCまたはHEVC方式において、NAL unit type codesと、NAL unit type classesのテーブルにあるように、filler dataは、non-VCLである。具体的には、nal_unit_type が３１で、Name of nal_unit_typeが、FD_NUTで、Content of NAL unit and RBSP syntax structureが、filler data、filler_data_rbsp()のとき、NAL unit type classは、non-VCLとなっている。このnon-VCLを、VCLデータに変更することで、ファイルのmedia dataに、filler dataを含めることができるので、伝送用ストリームへの変換時にfiller dataが除去されることを抑制することができる。

より具体的には、ファイル生成部２は、以下のように、startcodeとfiller dataとの設定を行う。

・Startcode and filler data
Therefore， this contribution proposes to allow to include startcode and filler data in the elementary streams for new brands only.
In the original version of ISO/IEC 14496-15， SPS/PPS can't be included in the elementary stream. In ISO/IEC 14496-16 PDAM2， it is allowed to include SPS/PPS now. If it is allowed to include startcode and filler data in the elementary stream， then the burden for bitstream converter is significantly reduced. Rewriting of HRD parameters， e.g. buffering period SEI and picture timing SEI， is not necessary in this case.
In order to ensure backward compatibility， this change should be applied to new brands. (new AVC brand and HEVC)

・Indication that HRD parameters are wrong
When startcode， filler data， etc. were removed from the elementary stream to store ISOMFF， HRD parameters， e.g. buffering period SEI， picture timing SEI， etc are not correct. However， decoder can-not know if HRD parameters in the elementary stream is correct. There should be an id to indicate the HRD parameters in the elementary stream may be wrong.

・In HEVC or AVC change filler data as VCL data
Currently in HEVC and AVC, filler data is categorized as non-VCL. That mean the bit for filler data is counted as non-VCL (header information). However, if we specify filler data as VCL data, the bit for filler is counted as video bitstream itself. In this case, filler data is not necessary to remove from the elementary stream and HRD parameters are not changed. The table for HEVC is attached.

更に、デコーダバッファを管理するパラメータが異なる(正しくない)場合、デコーダはデコーダバッファを管理するパラメータが同じ(正しい)ことを判別することができない。そこで、startcodeとfiller dataがビットストリームから削除された場合に、デコーダバッファを管理するパラメータの特性が変更されたかを識別する識別パラメータを設定する。一例として、ファイルフォーマットのオプショナルボックスで格納する場合を示す。

For example, in case of AVC, such id can be defined as an optional box in AVCSampleEntry as follows. (The same approach can be applied to other AVC sample entries and HEVCSampleEntry.)

AVCSampleEntry() extends VisualSampleEntry(type') {

//type is 'avc1' or 'avc3'
AVCConfigurationBox config;
MPEG4BitRateBox(); //Optional
MPEG4ExtensionDescriptorsBox(); //Optional
HRDConformanceBox(); //Optional
}

Add HRDConformanceBox into AVCSampleEntry and AVC2SVVSampleEntry in 5.4.2.1
Add HRDConformanceBox into AVCSVCSampleEntry, AVC2SVCSampleEntry and SVCSampleEntry in 6.5.3.1.
Add HRDConformanceBox into AVCMVCSampleEntry, AVC2MVCSampleEntry and MVCSampleEntry in section7.6.3.3.
Add HRDConformanceBox into HEVC SampleEntry in section 8.4.1.1.

HRDConformanceBox can be defined as follows.

class HRDConformanceBox extends Box('hrdc') {
HRDConformanceData() HRDConformance;
}

aligned(8) class HRDConformanceData {
unsigned int(7) reserved =0;
unsigned int(1) HRDConformanceFlag;
unsigned int (24) reserved;
Box[] any_box;//Optional
}

識別パラメータは、例えば以下のように設定される。

HRDConformanceFlag is the identifier if HRD characteristics was changed by removing startcode, filler data, etc from the elementary stream. When HRDConformanceFlag is equal to1, the HRD parameters, e.g. buffering period SEI, picture timing SEI, was changed by removing startcode, filler data, etc from the elementary stream.

以上の処理を行う図１のファイル生成部２は、次の図３に示すように構成される。

［ファイル生成部の構成例］
図３は、上述した処理を行うファイル生成部の構成例を示すブロック図である。

図３の例において、ファイル生成部２は、制御部３１、設定部３２、およびファイル書き出し部３３を含むように構成されている。

制御部３１は、デコーダバッファを管理するパラメータであるHRDパラメータの特性を保持するか否かに応じて、設定部３２によるファイルのVCLデータ部分であるmdatデータの生成処理を制御する。また、制御部３１は、設定部３２により設定されたmdatデータにおいて、startcodeとfiller dataが削除されているか否かに応じて、HRDパラメータの特性の設定、または、ファイルの管理情報部分であるmoovにおけるHRDの識別パラメータの設定を制御する。

設定部３２は、エンコーダ１からの符号化ストリームを用いて、制御部３１による制御のもと、ファイルのmdatデータを生成し、生成したmdatデータをファイル書き出し部３３に供給する。なお、従来の手法においては、startcodeとfiller dataが削除されるが、本技術の手法においては、符号化ストリームにおいて設定されているstartcodeとfiller dataとが設定されたまま、mdatデータが生成される。

また、設定部３２は、制御部３１による制御のもと、HRDパラメータの特性の再設定、またはファイルのmoovにおけるHRDの識別パラメータの設定を行う。そして、設定部３２は、ファイルのmoovを生成し、生成したmoovをファイル書き出し部３３に供給する。

ファイル書き出し部３３は、設定部３２からのmoovをファイルに書き出し、さらに、mdatをファイルに書き出す。ファイル書き出し部３３により書き出されたＭＰ４のファイルは、後述する復号装置などに伝送され、復号装置において、読みとられ、復号される。

［ファイル生成処理の例］
次に、図４のフローチャートを参照して、ファイル生成部２のファイル生成処理を説明する。

ステップＳ１において、制御部３１は、デコーダバッファを管理するパラメータであるHRDパラメータの特性を保持するか否かを判定する。ステップＳ１において、HRDパラメータの特性を保持しないと判定された場合、処理は、ステップＳ２に進む。ステップＳ２において、設定部３２は、制御部３１の制御のもと、従来のmdatデータの生成処理を行う。この処理は、図６を参照して後述される。

ステップＳ２の処理により、startcodeが検出されて、NALデータが取得され、startcodeが削除される。そして、取得されたデータがVCLデータであるか、filler dataであるか、あるいは、管理情報であるかなどに応じて、Unit sizeの付加およびバッファへの蓄積、または破棄が行われて、mdatデータが生成される。生成されたmdatデータは、ファイル書き出し部３３に供給され、処理は、ステップＳ４に進む。

一方、ステップＳ１において、HRDパラメータの特性を保持すると判定された場合、処理は、ステップＳ３に進む。ステップＳ３において、設定部３２は、制御部３１の制御のもと、本技術のmdatデータの生成処理を行う。この処理は、図７を参照して後述される。

ステップＳ３の処理により、startcodeが検出されて、NALデータが取得され、取得されたデータがVCLデータに設定されて、Unit Sizeが付加されて、バッファに蓄積されることで、mdatデータが生成される。生成されたmdatデータは、ファイル書き出し部３３に供給され、処理は、ステップＳ４に進む。

ステップＳ４において、制御部３１は、ステップＳ２またはＳ３で生成されたmdatデータにおいて、startcodeとfiller dataが削除されているか否かを判定する。

ステップＳ４において、startcodeとfiller dataが削除されていると判定された場合、処理は、ステップＳ５に進む。ステップＳ５において、設定部３２は、HRDパラメータの特性を設定する。すなわち、HRDパラメータの特性が異なっているので、HRDパラメータの特性は、再度計算され、再度設定される。そして、設定されたHRDパラメータで、mdatデータのSEIおよびVUIが書き換えられる。

ステップＳ４において、startcodeとfiller dataが削除されていないと判定された場合、ステップＳ５は、スキップされ、処理は、ステップＳ６に進む。

ステップＳ６において、設定部３２は、ステップＳ２またはＳ３の処理で得られたデータのサイズ情報を用いて、ファイルのmoovを生成する。なお、ステップＳ３が行われた場合、moov用のバッファに蓄積された管理情報なども用いられる。生成されたmoovは、ファイル書き出し部３３に供給される。

ステップＳ７において、ファイル書き出し部３３は、ステップＳ６により生成されたmoovをファイルに書き出す。

ステップＳ８において、ファイル書き出し部３３は、ステップＳ２またはＳ３により生成されたmdatをファイルに書き出す。

以上のようにして、ファイル書き出し部３３により書き出されたＭＰ４のファイルは、後述する復号装置などに送信され、復号装置において読みとられ、復号される。その際、HRDパラメータの特性を変えることなく、ファイルが生成される。また、HRDパラメータは、startcodeとfiller dataが削除されていたとしても再度設定されているので、HRDパラメータを参照することで、復号処理を正確に行うことができる。

なお、図４の説明においては、startcodeとfiller dataが削除されている場合に、HRDパラメータの特性を再設定する例を説明したが、次に説明するように、HRDパラメータの特性が正しいか異なっているかを示す識別パラメータを設定するようにしてもよい。

［ファイル生成処理の他の例］
次に、図５のフローチャートを参照して、ファイル生成部２のファイル生成処理を説明する。

ステップＳ１１において、制御部３１は、デコーダバッファを管理するパラメータであるHRDパラメータの特性を保持するか否かを判定する。ステップＳ１１において、HRDパラメータの特性を保持しないと判定された場合、処理は、ステップＳ１２に進む。ステップＳ１２において、設定部３２は、制御部３１の制御のもと、従来のmdatデータの生成処理を行う。この処理は、図５を参照して後述される。

ステップＳ１２の処理により、startcodeが検出されて、NALデータが取得され、startcodeが削除される。そして、取得されたデータがVCLデータであるか、filler dataであるか、あるいは、管理情報であるかなどに応じて、Unit sizeの付加およびバッファへの蓄積、または破棄が行われて、mdatデータが生成される。生成されたmdatデータは、ファイル書き出し部３３に供給され、処理は、ステップＳ１４に進む。

一方、ステップＳ１１において、HRDパラメータの特性を保持すると判定された場合、処理は、ステップＳ１３に進む。ステップＳ１３において、設定部３２は、制御部３１の制御のもと、本技術のmdatデータの生成処理を行う。この処理は、図６を参照して後述される。

ステップＳ１３の処理により、startcodeが検出されて、NALデータが取得され、取得されたデータがVCLデータに設定されて、Unit Sizeが付加されて、バッファに蓄積されることで、mdatデータが生成される。生成されたmdatデータは、ファイル書き出し部３３に供給され、処理は、ステップＳ１４に進む。

ステップＳ１４において、制御部３１は、ステップＳ１２またはＳ１３で生成されたmdatデータにおいて、startcodeとfiller dataが削除されているか否かを判定する。

ステップＳ１４において、startcodeとfiller dataが削除されていないと判定された場合、処理は、ステップＳ１５に進む。ステップＳ１５において、設定部３２は、moovのHRDの識別パラメータを１に設定し、処理は、ステップＳ１７に進む。これにより、復号側で、HRDパラメータが正しいことを判別することができる。

ステップＳ１４において、startcodeとfiller dataが削除されていると判定された場合、処理は、ステップＳ１６に進む。ステップＳ１６において、設定部３２は、moovのHRDの識別パラメータを０に設定し、処理は、ステップＳ１７に進む。これにより、復号側で、HRDパラメータが間違っている（正しくない）ことを判別することができる。

ステップＳ１７において、設定部３２は、ステップＳ１２またはＳ１３の処理で得られたデータのサイズ情報を用いて、ファイルのmoovを生成する。なお、ステップＳ１３が行われた場合、moov用のバッファに蓄積された管理情報なども用いられる。生成されたmoovは、ファイル書き出し部３３に供給される。

ステップＳ１８において、ファイル書き出し部３３は、ステップＳ１７により生成されたmoovをファイルに書き出す。

ステップＳ１９において、ファイル書き出し部３３は、ステップＳ１２またはＳ１３により生成されたmdatをファイルに書き出す。

以上のようにして、ファイル書き出し部３３により書き出されたＭＰ４のファイルは、後述する復号装置などに送信され、復号装置において読みとられ、復号される。その際、HRDパラメータの特性を変えることなく、ファイルが生成される。また、HRDパラメータが正しいか否かを識別するための識別パラメータを設定するようにしたので、HRDパラメータを参照して復号するのかしないのかを明確に判別することができる。

［従来のmdatデータの生成処理例］
次に、図６のフローチャートを参照して、図４のステップＳ２（または図５のステップＳ１２）における従来のmdatデータの生成処理について説明する。

設定部３２は、ステップＳ２１において、エンコーダ１からの符号化ストリームからstartcodeを検出し、ステップＳ２２において、ステップＳ２１により検出されたstartcodeから、次のstartcode までのNALデータを取得する。

設定部３２は、ステップＳ２３において、ステップＳ２１により検出されたstartcodeを削除する。ステップＳ２４において、ステップＳ２２により取得されたデータが、VCLデータであるか否かを判定する。

ステップＳ２４において、ステップＳ２２により取得されたデータが、VCLデータであると判定された場合、処理は、ステップＳ２５に進む。ステップＳ２５において、設定部３２は、ステップＳ２２により取得されたデータに、対応するUnit sizeを付加して、アクセスユニットとする。そして、設定部３２は、ステップＳ２６において、Unit sizeが付加されたアクセスユニットを、内蔵するmdatバッファに蓄積し、処理は、ステップＳ３０に進む。

ステップＳ２４において、ステップＳ２２により取得されたデータが、VCLデータではないと判定された場合、処理は、ステップＳ２７に進む。ステップＳ２７において、設定部３２は、ステップＳ２２により取得されたデータが、filler dataであるか否かを判定する。

ステップＳ２７において、ステップＳ２２により取得されたデータが、filler dataであると判定された場合、処理は、ステップＳ２８に進む。ステップＳ２８において、設定部３２は、filler dataを破棄し、処理は、ステップＳ３０に進む。

ステップＳ２７において、ステップＳ２２により取得されたデータが、filler dataではないと判定された場合、処理は、ステップＳ２９に進む。この場合、取得されたデータは、SPSやPPSなどの管理情報であるので、ステップＳ２９において、設定部３２は、取得されたデータを、内蔵するmoovバッファに蓄積し、処理は、ステップＳ３０に進む。

ステップＳ３０において、設定部３２は、エンコーダ１からの符号化ストリームからstartcodeを検出する。

ステップＳ３１において、設定部３２は、いまのデータがファイル最後のデータであるか否かを判定する。ステップＳ３０によりstartcodeが検出されなかった場合、ステップＳ３１において、ファイル最後のデータであると判定され、mdatデータの生成処理が終了され、処理は、図４のステップＳ２（または図５のステップＳ１２）に戻る。

ステップＳ３０によりstartcodeが検出された場合、ステップＳ３１において、ファイル最後のデータではないと判定された場合、処理は、ステップＳ２２に進み、それ以降の処理が繰り返される。

［本技術のmdatデータの生成処理例］
これに対して、図７のフローチャートを参照して、図４のステップＳ３（図５のステップＳ１３）における本技術のmdatデータの生成処理について説明する。

設定部３２は、ステップＳ４１において、エンコーダ１からの符号化ストリームからstartcodeを検出し、ステップＳ４２において、ステップＳ４１により検出されたstartcodeから、次のstartcode までのNALデータを取得する。なお、図７の例においては、startcodeは削除されない。

設定部３２は、ステップＳ４３において、ステップＳ４２により取得されたデータが、filler dataであるか否かを判定する。ステップＳ４３において、ステップＳ４２により取得されたデータが、filler dataであると判定された場合、処理は、ステップＳ４４に進む。ステップＳ４４において、設定部３２は、filler dataを、VCLデータに設定する。

ステップＳ４３において、ステップＳ４２により取得されたデータが、filler dataではないと判定された場合、ステップＳ４４はスキップされ、処理は、ステップＳ４５に進む。

ステップＳ４５において、ステップＳ４２により取得されたデータに、対応するUnit sizeを付加して、アクセスユニットとし、ステップＳ４６において、Unit sizeが付加されたアクセスユニットを、内蔵するmdatバッファに蓄積する。ここで、取得されたデータがSPSやPPSなどの管理情報であった場合、内蔵するmoovバッファにも蓄積され、図４のステップＳ６または図５のステップＳ１７において、moovのSample Descriptionに、デフォルトのSPSやPPSとして格納される。

なお、取得されたデータがSPSやPPSなどの管理情報であった場合、従来のように、mdatバッファに蓄積されず、内蔵するmoovバッファだけに蓄積されてもよい。

ステップＳ４７において、設定部３２は、エンコーダ１からの符号化ストリームからstartcodeを検出する。

ステップＳ４８において、設定部３２は、いまのデータがファイル最後のデータであるか否かを判定する。ステップＳ４７によりstartcodeが検出されなかった場合、ステップＳ４８において、ファイル最後のデータであると判定され、mdatデータの生成処理が終了され、処理は、図４のステップＳ３（図５のステップＳ１３）に戻る。

ステップＳ４７によりstartcodeが検出された場合、ステップＳ４８において、ファイル最後のデータではないと判定された場合、処理は、ステップＳ４２に進み、それ以降の処理が繰り返される。

以上のようにして、本技術においては、デコーダバッファを管理するパラメータの特性を保持してファイルを構成するように、startcodeとfiller dataとの設定を制御するようにした。すなわち、startcodeとfiller data は削除されず、startcodeとfiller dataとを含んで、ファイルを構成するようにしたので、デコーダバッファを管理するパラメータの特性を保持することができる。

また、filler dataを、VCLデータに変更するようにしたので、ファイルのmedia dataに、Filler dataを含めることができ、伝送用ストリームへの変換時にfiller dataが除去されることを抑制することができる。

さらに、ファイルのmedia dataにおいて、startcodeとfiller dataが削除された場合に、デコーダバッファを管理するパラメータの特性を設定し、設定されたパラメータを用いて、ファイルを生成するようにした。これにより、復号を正しく行うことができる。

あるいは、ファイルのmedia dataにおいて、startcodeとfiller dataが削除された場合に、デコーダバッファを管理するパラメータの特性が変更されたことを識別する識別パラメータを設定し、設定された識別パラメータを用いて、ファイルを生成するようにした。これにより、復号を正しく行うことができる。

［復号装置の第１実施の形態の構成例］
図８は、図１の符号化装置から伝送される符号化ストリームを復号する、本技術を適用した画像処理装置としての、復号装置の第１実施の形態の構成例を示すブロック図である。

図８の復号装置は、ファイル読取部５１、およびデコーダ５２により構成される。

復号装置のファイル読取部５１は、図１の符号化装置により生成されたＭＰ４のファイルを受け取り、受け取ったファイルから、図１のエンコーダ１により符号化された符号化ストリームを構成するSPS,PPS,VUI,SEI、符号化データ等を読み取る。ファイル読取部５１は、SPS,PPS,VUI,SEI、符号化データをデコーダ５２に供給する。

より具体的には、ファイル読取部５１は、画像を符号化したビットストリームを含み、startcodeとfiller dataとがファイルのmedia dataにおいて、デコーダバッファを管理するパラメータの特性を保持してファイルを構成するように制御されて設定されているファイルを受け取る。または、ファイル読取部５１は、画像を符号化したビットストリームを含むファイルのmedia dataにおいて、startcodeとfiller dataが削除された場合に、デコーダバッファを管理するパラメータの特性が設定され、設定された特性を用いて生成されているファイルを受け取る。そして、ファイル読取部５１は、受け取られたファイルを読み取り、デコーダ５２に、ビットストリームの符号化データを復号させる。

デコーダ５２は、ファイル読取部５１の制御のもと、ファイル読取部５１から供給されるSPS,PPS,VUI,SEI等(特に、HRDパラメータの特性)を参照し、ファイル読取部５１から供給される符号化データをHEVC方式で復号する。デコーダ５２は、復号の結果得られる画像を、出力信号として後段に供給する。

［ファイル読取部の構成例］
図９は、ファイル読取部５１の構成例を示すブロック図である。

図９の例において、ファイル読取部５１は、ファイル受け取り部７１、パラメータ取得部７２、復号制御部７３、およびデータ読み出し部７４を含むように構成されている。

ファイル受け取り部７１は、図１のファイル生成部２により生成されたＭＰ４のファイルを受け取り、受け取ったファイルをパラメータ取得部７２に供給する。

パラメータ取得部７２は、ＭＰ４のファイルから管理情報であるmoovを取得し、データ読み出し部７４に供給する。また、パラメータ取得部７２は、取得したmoovに基づいて、データ読み出し部７４に、mdatからデータを読み出させる。

なお、図５のファイル生成処理により生成されたファイルの場合、パラメータ取得部７２は、moovから、HRDパラメータの特性が正しいか否かを判別するための識別パラメータを取得し、復号制御部７３にその識別パラメータを供給する。

復号制御部７３は、パラメータ取得部７２からのHRDの識別パラメータがある場合、HRDの識別パラメータに応じて、HRDパラメータに従うか否かを決めて、デコーダ５２を制御し、復号処理を行わせる。

一方、図４のファイル生成処理により生成されたファイルの場合、moovには、HRDの識別パラメータがないが、そのＭＰ４のファイルのstartcodeとfiller dataとが削除されていても、HRDパラメータの特性は、再度設定されているので、正しい。したがって、この場合、復号制御部７３は、特に動作を行わない。

データ読み出し部７４は、パラメータ取得部７２の制御のもと、ファイルのmoovまたはmdatから、SPS、PPS、VUI、SEIなどを読み出して、また、ファイルのmdatから符号化データを読み出す。そして、データ読み出し部７４は、読み出したSPS、PPS、VUI、SEI、符号化データなどを、デコーダ５２に供給する。

［復号部の構成例］
図１０は、図８のデコーダ５２の構成例を示すブロック図である。デコーダ５２の各部は、ファイル読取部５１からのSPS、PPS、VUI、SEIに含まれるパラメータを用いて、符号化データを復号して、画像を生成する。

図１０のデコーダ５２は、蓄積バッファ１０１、可逆復号部１０２、逆量子化部１０３、逆直交変換部１０４、加算部１０５、デブロックフィルタ１０６、画面並べ替えバッファ１０７、D/A変換部１０８、フレームメモリ１０９、スイッチ１１０、イントラ予測部１１１、動き補償部１１２、およびスイッチ１１３により構成される。

また、デブロックフィルタ１０６と、画面並べ替えバッファ１０７およびフレームメモリ１０９との間には、適応オフセットフィルタ１４１と適応ループフィルタ１４２が備えられている。

デコーダ５２の蓄積バッファ１０１は、図８のファイル読取部５１から符号化データを受け取り、蓄積する。蓄積バッファ１０１は、蓄積されている符号化データを可逆復号部１０２に供給する。

可逆復号部１０２は、蓄積バッファ１０１からの符号化データに対して、可変長復号や、算術復号等の可逆復号を施すことで、量子化された係数と符号化情報を得る。可逆復号部１０２は、量子化された係数を逆量子化部１０３に供給する。また、可逆復号部１０２は、符号化情報としてのイントラ予測モード情報などをイントラ予測部１１１に供給し、動きベクトル、参照画像を特定するための情報、インター予測モード情報などを動き補償部１１２に供給する。さらに、可逆復号部１０２は、符号化情報としてのイントラ予測モード情報またはインター予測モード情報をスイッチ１１３に供給する。

可逆復号部１０２は、符号化情報としてのオフセットフィルタ情報を適応オフセットフィルタ１４１に供給し、フィルタ係数を適応ループフィルタ１４２に供給する。

逆量子化部１０３、逆直交変換部１０４、加算部１０５、デブロックフィルタ１０６、フレームメモリ１０９、スイッチ１１０、イントラ予測部１１１、および、動き補償部１１２は、図２の逆量子化部１８、逆直交変換部１９、加算部２０、デブロックフィルタ２１、フレームメモリ２２、スイッチ２３、イントラ予測部２４、および、動き予測・補償部２５とそれぞれ同様の処理を行い、これにより、画像が復号される。

具体的には、逆量子化部１０３は、可逆復号部１０２からの量子化された係数を逆量子化し、その結果得られる係数を逆直交変換部１０４に供給する。

逆直交変換部１０４は、逆量子化部１０３からの係数に対して逆直交変換を施し、その結果得られる残差情報を加算部１０５に供給する。

加算部１０５は、逆直交変換部１０４から供給される復号対象の画像としての残差情報と、スイッチ１１３から供給される予測画像を加算することにより、復号を行う。加算部１０５は、復号の結果得られる画像をデブロックフィルタ１０６に供給するとともに、フレームメモリ１０９に供給する。なお、スイッチ１１３から予測画像が供給されない場合、加算部１０５は、逆直交変換部１０４から供給される残差情報である画像を復号の結果得られる画像として、デブロックフィルタ１０６に供給するとともに、フレームメモリ１０９に供給して蓄積させる。

デブロックフィルタ１０６は、加算部１０５から供給される画像をフィルタリングすることにより、ブロック歪を除去する。デブロックフィルタ１０６は、その結果得られる画像を適応オフセットフィルタ１４１に供給する。

適応オフセットフィルタ１４１は、可逆復号部１０２から供給されるオフセットを順に格納するバッファを有する。また、適応オフセットフィルタ１４１は、LCUごとに、可逆復号部１０２から供給されるオフセットフィルタ情報に基づいて、デブロックフィルタ１０６による適応デブロックフィルタ処理後の画像に対して、適応オフセットフィルタ処理を行う。

具体的には、オフセットフィルタ情報に含まれる格納フラグが０である場合、適応オフセットフィルタ１４１は、LCU単位のデブロックフィルタ処理後の画像に対して、そのオフセットフィルタ情報に含まれるオフセットを用いて、種類情報が示す種類の適応オフセットフィルタ処理を行う。

一方、オフセットフィルタ情報に含まれる格納フラグが１である場合、適応オフセットフィルタ１４１は、LCU単位のデブロックフィルタ処理後の画像に対して、そのオフセットフィルタ情報に含まれるインデックスが示す位置に格納されるオフセットを読み出す。そして、適応オフセットフィルタ１４１は、読み出されたオフセットを用いて、種類情報が示す種類の適応オフセットフィルタ処理を行う。適応オフセットフィルタ１４１は、適応オフセットフィルタ処理後の画像を、適応ループフィルタ１４２に供給する。

適応ループフィルタ１４２は、適応オフセットフィルタ１４１から供給される画像に対して、可逆復号部１０２から供給されるフィルタ係数を用いて、LCUごとに適応ループフィルタ処理を行う。適応ループフィルタ１４２は、その結果得られる画像をフレームメモリ１０９および画面並べ替えバッファ１０７に供給する。

フレームメモリ１０９に蓄積された画像は、参照画像としてスイッチ１１０を介して読み出され、動き補償部１１２またはイントラ予測部１１１に供給される。

画面並べ替えバッファ１０７は、デブロックフィルタ１０６から供給される画像をフレーム単位で記憶する。画面並べ替えバッファ１０７は、記憶した符号化のための順番のフレーム単位の画像を、元の表示の順番に並び替え、D/A変換部１０８に供給する。

D/A変換部１０８は、画面並べ替えバッファ１０７から供給されるフレーム単位の画像をD/A変換し、出力信号として図示せぬ後段に出力する。

イントラ予測部１１１は、タイルおよびスライス単位で、フレームメモリ１０９からスイッチ１１０を介して読み出されたデブロックフィルタ１０６でフィルタリングされていない参照画像を用いて、可逆復号部１０２から供給されるイントラ予測モード情報が示すイントラ予測モードのイントラ予測処理を行う。イントラ予測部１１１は、その結果生成される予測画像をスイッチ１１３に供給する。

動き補償部１１２は、タイルおよびスライス単位で、可逆復号部１０２から供給される参照画像を特定するための情報に基づいて、フレームメモリ１０９からスイッチ１１０を介して、デブロックフィルタ１０６でフィルタリングされた参照画像を読み出す。動き補償部１１２は、動きベクトルと参照画像を用いて、インター予測モード情報が示す最適インター予測モードの動き補償処理を行う。動き補償部１１２は、その結果生成される予測画像をスイッチ１１３に供給する。

スイッチ１１３は、可逆復号部１０２からイントラ予測モード情報が供給された場合、イントラ予測部１１１から供給される予測画像を加算部１０５に供給する。一方、可逆復号部１０２からインター予測モード情報が供給された場合、スイッチ１１３は、動き補償部１１２から供給される予測画像を加算部１０５に供給する。

［ファイル復号処理の例］
次に、図１１のフローチャートを参照して、図８の復号装置のファイル復号処理を説明する。なお、このファイル復号処理は、図４のファイル生成処理により生成されたファイルに対する処理である。すなわち、このファイルにおけるHRDパラメータの特性は、startcodeとfiller dataが削除されていたとしても、再度設定されている。

ステップＳ７１において、ファイル受け取り部７１は、ＭＰ４のファイルを受け取り、受け取ったファイルをパラメータ取得部７２に供給する。

ステップＳ７２において、パラメータ取得部７２は、ＭＰ４のファイルから管理情報であるmoovを取得し、取得したmoovをデータ読み出し部７４に供給する。データ読み出し部７４は、ステップＳ７３において、moovからSPSおよびPPSを取得する。ステップＳ７４において、パラメータ取得部７２は、ステップＳ７２により取得されたmoovに基づいて、mdatの復号対象のUnit sizeを取得する。

ステップＳ７５において、パラメータ取得部７２は、ステップＳ７４により取得されたUnit sizeに基づいて、NALを検出する。このとき、図１７および図１８を参照して後述されるファイル構造に応じて、例えば、startcodeも取得されて参照される。

ステップＳ７６において、データ読み出し部７４は、ステップＳ７５により検出されたNALからデータを読み出し、デコーダ５２に供給する。なお、ここで、NALがSPSまたはPPSの場合、ステップＳ７３で取得されたmoovのSPSまたはPPSは、デフォルトの値となり、NALのSPSまたはPPSが用いられる。

ステップＳ７７において、デコーダ５２は、復号処理を行う。その際、デコーダ５２は、HRDパラメータに従って、復号処理を行う。

ここで、本技術においては、HRDパラメータの特性を保持するように、startcodeとfiller dataが設定されたまま、削除されず、ファイルが構成されているので、正しく復号処理を行うことができる。

なお、仮に、このHRDパラメータが、startcodeとfiller dataが削除されていたとしても、図４のファイル生成処理において再度設定されているので、正しく復号処理を行うことができる。

例えば、MP4ファイルの場合、外部よりVBRまたはCBRの伝送レートの指定がある。VBRの場合、データ読み出し部７４から、デコーダ５２に対して、ストリームがそのまま出力されるが、CBRの場合、データ読み出し部７４において、CBRとなるように、Filler dataまたはstuffing bitが追加されて、HRDパラメータが書き換えられる。その際にも、MP4ファイルのHRDパラメータは正常であるので、復号側においても正常に書き換えることができる。

［ファイル復号処理の他の例］
次に、図１２のフローチャートを参照して、図８の復号装置のファイル復号処理を説明する。なお、このファイル復号処理は、図５のファイル生成処理により生成されたファイルに対する処理である。すなわち、このファイルのmoovには、HRDパラメータの特性が正しいか異なっているかを識別する識別パラメータが設定されている。

ステップＳ９１において、ファイル受け取り部７１は、ＭＰ４のファイルを受け取り、受け取ったファイルをパラメータ取得部７２に供給する。

ステップＳ９２において、パラメータ取得部７２は、ＭＰ４のファイルから管理情報であるmoovを取得し、取得したmoovをデータ読み出し部７４に供給する。データ読み出し部７４は、ステップＳ９３において、moovからSPSおよびPPSを取得する。ステップＳ９４において、パラメータ取得部７２は、ステップＳ９２により取得されたmoovから、HRDの識別パラメータを取得し、取得したHRDの識別パラメータを、復号制御部７３に供給する。ステップＳ９５において、パラメータ取得部７２は、ステップＳ９２により取得されたmoovに基づいて、mdatの復号対象のUnit sizeを取得する。

ステップＳ９６において、パラメータ取得部７２は、ステップＳ９５により取得されたUnit sizeに基づいて、NALを検出する。このとき、図１７および図１８を参照して後述されるファイル構造に応じて、例えば、startcodeも取得されて参照される。

ステップＳ９７において、データ読み出し部７４は、ステップＳ９６により検出されたNALからデータを読み出し、デコーダ５２に供給する。なお、ここで、NALがSPSまたはPPSの場合、ステップＳ９３で取得されたmoovのSPSまたはPPSは、デフォルトの値となり、NALのSPSまたはPPSが用いられる。

ステップＳ９８において、復号制御部７３は、パラメータ取得部７２からのHRDの識別パラメータが１であるか否かを判定する。ステップＳ９８において、HRDの識別パラメータが１であると判定された場合、処理は、ステップＳ９９に進む。

ステップＳ９９において、デコーダ５２は、復号制御部７３の制御のもと、HRDパラメータに従って、復号処理を行う。

一方、ステップＳ９８において、HRDの識別パラメータが１ではないと判定された場合、処理は、ステップＳ１００に進む。

ステップＳ１００において、デコーダ５２は、復号制御部７３の制御のもと、HRDパラメータを無視して、復号処理を行う。

ここで、本技術においては、HRDパラメータの特性を保持するように、startcodeとfiller dataが設定されたまま、削除されず、ファイルが構成されているので、正しく復号処理を行うことができる。

なお、仮に、このHRDパラメータが、startcodeとfiller dataが削除されていたとしても、図５のファイル生成処理において、正しいか否かを識別する識別パラメータが設定されているので、正しく復号処理を行うことができる。

＜２．第２の実施の形態＞
［エンコーダの構成例］
図１３は、上述したＭＰ４のファイルを生成するための、一実施形態に係る画像符号化装置２０１の構成の一例を示すブロック図である。図１３を参照すると、画像符号化装置２０１は、符号化部２１１、ＶＣＬバッファ２１２、非ＶＣＬバッファ２１３、ファイル生成部２１４及び制御部２１５を備える。

なお、図１３の符号化部２１１は、図１のエンコーダ１に対応している。図１３のＶＣＬバッファ２１２、非ＶＣＬバッファ２１３、ファイル生成部２１４及び制御部２１５は、図１のファイル生成部２に対応している。

符号化部２１１は、ＨＥＶＣ方式に従って動作するエンコーダである。符号化部２１１は、画像符号化装置２０１に接続されるカメラ又はテレビジョンチューナなどの動画ソースから、符号化すべき画像を順次取得する。そして、符号化部２１１は、取得した画像をＳＰＳ、ＰＰＳ及びＡＰＳに含まれるパラメータを用いて符号化し、画像データのビットストリームを生成する。また、符号化部２１１は、ＳＰＳ及びＰＰＳを非ＶＣＬ ＮＡＬユニットとして生成する。一方、符号化部２１１は、filler data及び画像データのビットストリームをＶＣＬ ＮＡＬユニットとして生成する。符号化部２１１は、filler data及び画像データのビットストリームを、ＶＣＬバッファ２１２を介してファイル生成部２１４へ出力する。また、符号化部２１１は、ＳＰＳ及びＰＰＳを、非ＶＣＬバッファ２１３を介してファイル生成部２１４へ出力する。ＶＣＬバッファ２１２は、ＶＣＬ ＮＡＬユニットをバッファリングする。非ＶＣＬバッファ２１３は、非ＶＣＬ ＮＡＬユニットをバッファリングする。ファイル生成部２１４は、符号化された一連の画像データを格納するＨＥＶＣファイル１５１を生成する。より具体的には、ファイル生成部２１４は、ＨＥＶＣファイル１５１のデータ領域（例えば、ｍｄａｔボックス）に、filler data及び画像データのビットストリームを、ＶＣＬ ＮＡＬユニットとして復号順（decoding order）で挿入する。また、ファイル生成部２１４は、ＨＥＶＣファイル１５１のヘッダ領域（例えば、ｍｏｏｖボックス）に、ＳＰＳ及びＰＰＳを、非ＶＣＬ ＮＡＬユニットとして挿入する。制御部２１５は、画像符号化装置２０１において実行される符号化処理を制御する。

なお、制御部２１５は、ＨＲＤ（Hypothetical Reference Decoder；仮想参照デコーダ）と呼ばれる仮想的なデコーダのモデルを用いて、デコーダのバッファを破綻させないように、符号化ストリームの生成を制御し得る。ＨＥＶＣ方式では、符号化ストリームが満たすべきコンフォーマンスポイント（規格適合性のチェックポイント）として、タイプ１及びタイプ２という２種類のコンフォーマンスポイントが定義されている。タイプ１のコンフォーマンスポイントは、ＶＣＬ ＮＡＬユニット及びフィルタデータＮＡＬユニットに適用され、非ＶＣＬ ＮＡＬユニットには適用されない。タイプ２のコンフォーマンスポイントは、ＶＣＬ ＮＡＬユニット、フィルタデータＮＡＬユニット及び非ＶＣＬ ＮＡＬユニットに適用される。本実施形態では、filler dataが非ＶＣＬ ＮＡＬユニットではなくＶＣＬ ＮＡＬユニットとして定義される。そのため、制御部２１５は、画像データのビットストリームのみならず、filler dataもまたタイプ１のコンフォーマンスポイントを満たすように、符号化ストリームの生成を制御してよい。

［デコーダの構成例］
図１４は、上述したＭＰ４のファイルから画像を復号するための、一実施形態に係る画像復号装置の構成の一例を示すブロック図である。図１４を参照すると、画像復号装置２５１は、ＶＣＬバッファ２６１、非ＶＣＬバッファ２６２、パラメータメモリ２６３、復号部２６４及び制御部２６５を備える。

なお、図１４のＶＣＬバッファ２６１、非ＶＣＬバッファ２６２、パラメータメモリ２６３、及び制御部２６５は、図８のファイル読取部５１に対応している。また、図１４の復号部２６４は、図８のデコーダ５２に対応している。

ＶＣＬバッファ２６１は、ファイルのデータ領域（例えば、ｍｄａｔボックス）から読み込まれる画像データのビットストリーム及びfiller dataをバッファリングする。非ＶＣＬバッファ２６２は、ファイルのヘッダ領域（例えば、ｍｏｏｖボックス）から読み込まれるパラメータセットをバッファリングする。パラメータメモリ２６３は、非ＶＣＬバッファ２６２を介して取得されるファイルのヘッダ領域内のパラメータセットを、一括的に記憶する。復号部２６４は、ＨＥＶＣ方式に従って動作するデコーダである。復号部２６４は、ＶＣＬバッファ２６１を介してファイルのデータ領域から逐次的に取得されるビットストリームから、画像を復号する。復号部２６４は、画像を復号する際 に、パラメータメモリ２６３により記憶されるＳＰＳ及びＰＰＳ内のパラメータを使用する。制御部２６５は、画像復号装置２５１において実行される復号処理を制御する。

＜３．第３の実施の形態＞
［従来のMP4ビデオサンプル構造］
図１５は、従来のMP4ビデオサンプル構造の例を示す図である。ビデオサンプルを構成するNALユニットは、図１５に示されるように規定されている。

図１５の例においては、複数のNALユニットで構成されているAVCストリームが示されている。AVCストリームにおいて、１ピクチャが１アクセスユニットとされている。アクセスユニットを構成するNALユニットの種類としては、SPS、PPS、アクセスユニットデリミタ(access unit delimiter)、SEI、IDRピクチャ、non IDRピクチャ、エンドオブシーケンス(end of sequence)、およびfiller dataなどのユニットがある。

従来のMP4の規定では、１ビデオサンプルには、１アクセスユニットが格納される。すなわち、１アクセスユニットを構成するNALユニットは、それぞれ、Unit sizeが付加されて、１ビデオサンプルに格納される。しかしながら、アクセスユニットを構成するNALユニットに、SPS、PPS、filler dataのNALユニットが存在する場合、SPS、PPS、filler dataのNALユニットは、ビデオサンプルから除外されていた。

例えば、左から１番目のアクセスユニットは、アクセスユニットデリミタ、SPS、PPS、SEI、IDRピクチャのNALユニットで構成されているが、そのアクセスユニットをサンプルに格納する際、SPS、PPSのNALユニットは、除外されている。

左から２番目のアクセスユニットは、アクセスユニットデリミタ、SPS、SEI、nonIDRピクチャ、およびfiller data のNALユニットで構成されているが、そのアクセスユニットをサンプルに格納する際、SPSおよびfiller dataのNALユニットは、除外されている。

左から３番目のアクセスユニットは、アクセスユニットデリミタ、SPS、SEI、およびnonIDRピクチャのNALユニットで構成されているが、そのアクセスユニットをサンプルに格納する際、SPSのNALユニットは、除外されている。

［AVCストリームの１アクセスユニットの構成例］
図１６は、AVCストリームの１アクセスユニットの構成例を示す図である。

図１６に示されるように、実際には、AVCストリームの１アクセスユニットにおいては、各NALユニットの前に、識別子（startcode）が付加されているが、従来においては、サンプルに格納する際、この識別子も除外されている。

この識別子（startcode）やfiller data のNALユニットが除外されてしまうと、上述したように、HRDパラメータの特性が保持されない。そこで、本技術においては、MP4のサンプルに、そのままアクセスユニットを格納する。

［本技術のアクセスユニットの格納例］
図１７および図１８は、本技術のMP4ビデオサンプル構造の例を示す図である。

図１７のＡの例においては、アクセスユニットの先頭に、アクセスユニットのサイズが記述されるユニットサイズが付加されて、MP4サンプルに、アクセスユニットがそのまま格納されている。そのままとは、startcodeを付けたままであって、filler dataがある場合には、filler dataを削除しないままのことである。すなわち、そのままとは、startcodeとfiller dataとが設定されたままのことである。

図１７のＡの場合、上述した図１１のステップＳ７５または図１２のステップＳ９６において、Unit size分のアクセスユニットが検出され、その中で、startcodeに基づいて、NALが検出される。そして、図１１のステップＳ７６または図１２のステップＳ９７において、次のstartcode までのNALのデータが取得される。図１７のＡの場合、とてもシンプルな構造である。

図１７のＢの例においては、アクセスユニットを構成する各NALユニットの先頭に、startcode含む各NALユニットのサイズが記述されるユニットサイズが付加されて、MP4サンプルに、アクセスユニットがそのまま格納されている。

図１７のＢの場合、上述した図１１のステップＳ７５または図１２のステップＳ９６において、Unit size分のstartcode + NALが検出される。そして、図１１のステップＳ７６または図１２のステップＳ９７において、その中から、startcodeが破棄されて、NALのデータが取得される。この場合、従来のsize＋dataという構造に近く、実装はこれまで通りであるが、得られたデータ構造から、startcodeを解釈する必要がある。

図１８のＣの例においては、アクセスユニットを構成する各NALユニットの先頭に、各NALユニットのサイズが記述されるユニットサイズが付加されており、さらに、０dataを含むstartcodeのサイズ、すなわち、NALまでのオフセットサイズが付加されている。そして、MP4サンプルに、ユニットサイズとオフセットサイズとが付加されたNALユニットが、そのまま格納されている。

図１８のＣの場合、上述した図１１のステップＳ７５または図１２のステップＳ９６において、オフセットサイズが取得されて、オフセット分読み飛ばされた位置から、NALが検出される。そして、図１１のステップＳ７６または図１２のステップＳ９７において、ユニットサイズ分のNALのデータが取得される。

なお、図１８のＣは、後述する図１９に示されるHRD Conformance BoxのFixedStartCodeSizeFlagが０の場合の例である。FixedStartCodeSizeFlagが０の場合、start code sizeが固定ではないので、offset size fieldにstartcodeのサイズが格納されている。

これに対して、HRD Conformance BoxのFixedStartCodeSizeFlagが１の場合、MP４サンプルは、図１８のＣ´に示される構造になる。

図１８のＣ´の例においては、アクセスユニットを構成する各NALユニットの先頭に、各NALユニットのサイズが記述されるユニットサイズが付加されて、MP4サンプルに、NALユニットが、そのまま格納されている。

すなわち、FixedStartCodeSizeFlagが１の場合、start code size＝４bytes固定となるので、offset size fieldはstartcodeの前に不要となる。

この場合、新しいパース構造となる。

図１８のＤの例においては、アクセスユニットを構成する各NALユニットの先頭に、各NALユニットのサイズ、startcodeのサイズ、およびstartcodeが記述されるユニットサイズが付加されており、さらに、０dataを含むstartcodeのサイズ、すなわち、NALまでのオフセットサイズが付加されている。そして、MP4サンプルに、ユニットサイズとオフセットサイズとが付加されたNALユニットが、そのまま格納されている。

図１８のＤの場合、上述した図１１のステップＳ７５または図１２のステップＳ９６において、ユニットサイズ分のオフセットサイズ＋startcode＋NALが検出されて、オフセットサイズが取得されて、オフセット分読み飛ばされた位置から、NALが検出される。そして、図１１のステップＳ７６または図１２のステップＳ９７において、Unit size−（オフセットサイズ＋startcode）分のNALのデータが取得される。

なお、図１８のＤは、HRD Conformance BoxのFixedStartCodeSizeFlagが０の場合の例である。FixedStartCodeSizeFlagが０の場合、start code sizeが固定ではないので、offset size fieldにstartcodeのサイズが格納されている。

これに対して、HRD Conformance BoxのFixedStartCodeSizeFlagが１の場合、MP４サンプルは、図１８のＤ´に示される構造になる。

図１８のＤ´の例においては、アクセスユニットを構成する各NALユニットの先頭に、startcode含む各NALユニットのサイズが記述されるユニットサイズが付加されて、MP4サンプルに、NALユニットが、そのまま格納されている。

すなわち、FixedStartCodeSizeFlagが１の場合、start code size＝４bytes固定となるので、offset size fieldはstartcodeの前に不要となり、図１８のＤ´の構造は、上述した図１７のＢの構造と同様になる。

この場合、従来のsize＋dataという構造に近く、実装はこれまで通りであるが、得られたデータ構造の先頭にあるオフセットサイズ分読み飛ばすパース構造となる。また、この場合、startcodeを解釈する必要がある。

［HRD Conformance Box拡張の例］
図１９は、HRD Conformance Box拡張の例を示す図である。以下にも、HRD Conformance Box拡張の例を同様に示す。

AVCSampleEntry() extends VisualSampleEntry(‘type’) {
// type is ‘avc3’ or ‘avc4’， (and all hevc)
AVCConfigurationBox config；
MPEG4BitRateBox()； //Optional
MPEG4ExtensionDescriptorsBox()； //Optional
HRDConformanceBox()； //Optional
}

Add HRDConformanceBox into AVCSampleEntry and AVC2SVVSampleEntry in 5.4.2.1
Add HRDConformanceBox into AVCSVCSampleEntry， AVC2SVCSampleEntry and SVCSampleEntry in 6.5.3.1.
Add HRDConformanceBox into AVCMVCSampleEntry， AVC2MVCSampleEntry and MVCSampleEntry in section7.6.3.3.
Add HRDConformanceBox into HEVC SampleEntry in section 8.4.1.1.
Sample entry without HRDConformanceBox is used only for samples without start codes nor fillers.

HRDConformanceBox can be defined as follows.
class HRDConformanceBox extends Box('hrdc') {
HRDConformanceData() HRDConformance；
}
aligned(8) class HRDConformanceData {
unsigned int(1) HRDConformanceFlag；
unsigned int(1) FixedStartCodeSizeFlag；
unsigned int(2) OffsetSizeMinusOne；
unsigned int(4) reserved =0；
unsigned int(24) reserved；
Box[] any_box； //Optional
}

HRDConformanceFlag is the identifier if HRD characteristics was changed by removing startcode， filler data， etc from the elementary stream. When HRDConformanceFlag is equal to1， the HRD parameters， e.g. buffering period SEI， picture timing SEI， was changed by removing startcode， filler data， etc from the elementary stream.

FixedStartCodeSizeFlag is the identifier when startcode in each NAL is fixed size of 4 bytes. When FixedStartCodeSizeFlag is equal to 1， no offset field is for each NAL in sample data to indicate the size of Start Code.

OffsetSizeMinusOne indicates the length in bytes of the StartcodeLength field in a video sample minus one. For example， a size of one byte is indicated with a value of 0. The value of this field shall be one of 0， 1， or 3 corresponding to a length encoded with 1， 2， or 4 bytes， respectively.

HRDConformanceBox is useful to indicate the status of HRD conformance even in the other options.

図１９および上述した例においては、HRD Conformance Boxに、startcodeのサイズ情報の有無を識別するフラグであるFixedStartCodeSizeFlagが追加定義されている。これにより、図１８のＣ’および図１８のＤ'に示したように、startcodeのサイズが固定の場合、ファイル構造をシンプルにすることができる。

［本技術のアクセスユニットの他の格納例］
図２０は、本技術のMP4ビデオサンプル構造の他の例を示す図である。

図２０のＥの例においては、mdatからユニットサイズが除去されて、そして、startcodeが含まれているエレメンタリーストリームは、そのまま変更なしにストア（貯蔵）されている。

図２０のＥの場合、各アクセスユニットのオフセットを維持するための新しいboxは、図２１および以下に示されるように、sample tableに加えられる。

aligned(8) class NALunitOffsetBox
extends FullBox(‘nalo’, version=0, 0) {
unsigned int(32) sample_count;
for (i=1; i <= sample_count; i++){
unsigned int(8) offset_count;
unsigned int(8) offset_size;
for (j=1; j <= offset_count; j++){
unsigned int(offset_size*8) offset;
}
}
}
sample_count is an integer that gives the number of entries in the following table.
offset_count is an integer that gives the number of entries in the following subtable.
offset_size is an integer that gives the byte size of the offset field in the following subtable.
offset is an integer that gives the offset of the start of a NAL unit into its containing sample.

なお、図２０のＥの例の代わりとして、上述したboxを加える代わりに、図２２のＥ´の例に示されるように、各サンプルの先頭に、そのオフセットのリストが含められるようにしてもよい。

図２２のＥ´の例においては、サンプルの先頭に、例えば、５つのアクセスユニットの５つのオフセットのリストが含められている。

なお、図１７および図１８のMP4ビデオサンプルのファイルは、上述した図３の構成のファイル生成部２により上述した図４または図５のファイル生成処理で生成される。図２０および図２２のMP4ビデオサンプルのファイルも、上述した図３の構成のファイル生成部２により上述した図４または図５のファイル生成処理で生成される。

また、図１７および図１８のMP4ビデオサンプルのファイルは、上述した図９の構成のファイル読取部５１により上述した図１１または図１２のファイル復号処理で復号される。図２０および図２２のMP4ビデオサンプルのファイルも、上述した図９の構成のファイル読取部５１により上述した図１１または図１２のファイル復号処理で復号される。

［本技術のアクセスユニットのさらに他の格納例］
図２３は、本技術のMP4ビデオサンプル構造の、さらに他の例を示す図である。

図２３のFの例においては、mdatからユニットサイズが除去されて、そして、startcodeが含まれているエレメンタリーストリームは、そのまま変更なしにストア（貯蔵）されている。また、各スタートコード（startcode）およびNALユニット（NAL unit）の長さを格納するために、ISO/IEC 14496-12において規定されるサンプル補助情報機能が適用されている。

各スタートコードおよびNALユニットの長さには、サンプル補助情報機能として、aux_info_type = 'nalz'とaux_info_type_parameter = 0が与えられる。サンプル補助情報機能は、使用されるサンプル補助情報機能サイズボックス（SampleAuxiliaryInformationSizesBox）である'saiz'と、サンプル補助情報機能オフセットボックスである'saio'により参照される。

［サンプル補助情報機能のフォーマット例］
図２４は、サンプル補助情報機能のフォーマットの例を示す図である。以下にも、サンプル補助情報機能のフォーマットの例を同様に示す。

aligned(8) class NalsizeSampleAuxiliaryDataFormat
{
unsigned int(2) StartcodeSizeMinusOne;
unsigned int(2) NALunitSizeMinusOne;
unsigned int(4) reserved;
unsigned int(32) subsample_count;
for (i=1; i <= subsample_count; i++){
switch (StartcodeSizeMinusOne){
case 0:
unsigned int(8) Startcode Size;
break;
case 1:
unsigned int(16) Startcode Size;
break;
case 3:
unsigned int(32) Startcode Size;
break;

}

switch (NALUnitSizeMinusOne){
case 0:
unsigned int(8) NALUnit Size;
break;
case 1:
unsigned int(16) NALUnit Size;
break;
case 3:
unsigned int(32) NALUnit Size;
break;

}

}
}

StartcodeSizeMinusOne indicates the length in bytes of the Startcode Size field minus one. For example, a size of one byte is indicated with a value of 0. The value of this field shall be one of 0, 1, or 3 corresponding to a length encoded with 1, 2, or 4 bytes, respectively.
NALUnitSizeMinusOne indicates the length in bytes of the NALUnit Size field minus one. For example, a size of one byte is indicated with a value of 0. The value of this field shall be one of 0, 1, or 3 corresponding to a length encoded with 1, 2, or 4 bytes, respectively.
StartcodeSize indicates the length in bytes of the Startcode of subsample in a sampleNALUnitSize indicates the length in bytes of the Startcode of subsample in a sample

StartcodeSizeMinusOneは、スタートコードサイズフィールド（Startcode Size field）のバイト長から１減算した値を示す。例えば、スタートコードサイズフィールドのバイト長が１バイトである場合、StartcodeSizeMinusOneの値は０である。StartcodeSizeMinusOneの値は、１バイト、２バイト、若しくは４バイトのそれぞれのコード長に対応して、０、１、若しくは３となる。

NALUnitSizeMinusOneは、NALユニットサイズフィールド（NALUnit Size field）のバイト長から１減算した値を示す。例えば、NALユニットサイズフィールドのバイト長が１バイトである場合、NALUnitSizeMinusOneの値は０である。NALUnitSizeMinusOneの値は、１バイト、２バイト、若しくは４バイトのそれぞれのコード長に対応して、０、１、若しくは３となる。

StartcodeSizeは、サンプル（sample）の中のサブサンプル（subsample）のスタートコード（Startcode）のバイト長を示す。

NALUnitSizeは、サンプル（sample）の中のサブサンプル（subsample）のNALユニット（NAL unit）のバイト長を示す。

以上のようにしても良い。また、サンプル補助情報機能のフォーマットは、以下のようにしてもよい。

［サンプル補助情報機能のフォーマットの他の例］
図２５は、サンプル補助情報機能のフォーマットの他の例を示す図である。以下にも、サンプル補助情報機能のフォーマットの他の例を同様に示す。

aligned(8) class NalsizeSampleAuxiliaryDataFormat
{
unsigned int(1) FixedStartCodeSizeFlag;
unsigned int(2) StartcodeSizeMinusOne;
unsigned int(2) NALunitSizeMinusOne;
unsigned int(3) reserved;
unsigned int(32) subsample_count;
for (i=1; i <= subsample_count; i++){
if (FixedStartCodeSizeFlag == 0){
switch (StartcodeSizeMinusOne){
case 0:
unsigned int(8) Startcode Size;
break;
case 1:
unsigned int(16) Startcode Size;
break;
case 3:
unsigned int(32) Startcode Size;
break;
}
}
switch (NALUnitSizeMinusOne){
case 0:
unsigned int(8) NALUnit Size;
break;
case 1:
unsigned int(16) NALUnit Size;
break;
case 3:
unsigned int(32) NALUnit Size;
break;
}
}
}

FixedStartCodeSizeFlag is the identifier when startcode before each NAL unit has fixed size of 4 bytes. When FixedStartCodeSizeFlag is equal to 1.
StartcodeSizeMinusOne indicates the length in bytes of the Startcode Size field minus one. For example, a size of one byte is indicated with a value of 0. The value of this field shall be one of 0, 1, or 3 corresponding to a length encoded with 1, 2, or 4 bytes, respectively.
NALUnitSizeMinusOne indicates the length in bytes of the NALUnit Size field minus one. For example, a size of one byte is indicated with a value of 0. The value of this field shall be one of 0, 1, or 3 corresponding to a length encoded with 1, 2, or 4 bytes, respectively.
StartcodeSize indicates the length in bytes of the Startcode of subsample in a sample
NALUnitSize indicates the length in bytes of the Startcode of subsample in a sample

FixedStartCodeSizeFlagは、フラグ情報である。各NALユニット（NAL unit）の前のスタートコード（startcode）のサイズが４バイトであるか否かを示すフラグ情報である。各NALユニット（NAL unit）の前のスタートコード（startcode）のサイズが４バイトである場合、このFixedStartCodeSizeFlagの値は１に設定され、その他の場合、０に設定される。換言するに、FixedStartCodeSizeFlagの値が１である場合、各NALユニット（NAL unit）の前のスタートコード（startcode）のサイズが４バイトであることを示し、FixedStartCodeSizeFlagの値が０である場合、各NALユニット（NAL unit）の前のスタートコード（startcode）のサイズが４バイトでないことを示す。

StartcodeSizeMinusOne，NALUnitSizeMinusOne，StartcodeSize、およびNALUnitSizeの各パラメータは、図２４の場合と同様である。

HRDConformanceData boxのFixedStartCodeSizeFlagが１の場合、個々のstart codeのサイズを持つと、データ量が不要に増大する可能性がある。そこで、図２５の例のようにすることにより、この場合、NALunitのサイズだけを持つ構造にすることができ、データ量の不要な増大を抑制することができる。なお、この場合、HRDConformanceBoxは、HRDConformanceFlagだけを持つことになる。

なお、図２３のMP4ビデオサンプルのファイルは、上述した図３の構成のファイル生成部２により上述した図４または図５のファイル生成処理で生成される。

また、図２３のMP4ビデオサンプルのファイルは、上述した図９の構成のファイル読取部５１により上述した図１１または図１２のファイル復号処理で復号される。

In this option, unit size is removed from mdat, and elementary stream including startcode is simply stored without modification. And to store the length of each startcode and NAL unit, we propose to use the sample auxiliary information function defined in ISO/IEC 14496-12 . Figure 23 shows an example of a sample of this option.

Each length of start code and NAL unit are provided as Sample Auxiliary Information with aux_info_type equal to 'nalz' and aux_info_type_parameter equal to 0.Sample Auxiliary Information is referenced by using a
SampleAuxiliaryInformationSizesBox ('saiz') and a
SampleAuxiliaryInformationOffsetsBox ('saio')

The format of the sample auxiliary information for samples with this type shall be:
aligned(8) class NalsizeSampleAuxiliaryDataFormat
{
unsigned int(1) FixedStartCodeSizeFlag;
unsigned int(2) StartcodeSizeMinusOne;
unsigned int(2) NALunitSizeMinusOne;
unsigned int(3) reserved;
unsigned int(32) subsample_count;
for (i=1; i <= subsample_count; i++){
if (FixedStartCodeSizeFlag == 0){
switch (StartcodeSizeMinusOne){
case 0:
unsigned int(8) Startcode Size;
break;
case 1:
unsigned int(16) Startcode Size;
break;
case 3:
unsigned int(32) Startcode Size;
break;
}
}
switch (NALUnitSizeMinusOne){
case 0:
unsigned int(8) NALUnit Size;
break;
case 1:
unsigned int(16) NALUnit Size;
break;
case 3:
unsigned int(32) NALUnit Size;
break;
}
}
}

FixedStartCodeSizeFlag is the identifier when startcode before each NAL unit has fixed size of 4 bytes. When FixedStartCodeSizeFlag is equal to 1.
StartcodeSizeMinusOne indicates the length in bytes of the Startcode Size field minus one. For example, a size of one byte is indicated with a value of 0. The value of this field shall be one of 0, 1, or 3 corresponding to a length encoded with 1, 2, or 4 bytes, respectively.
NALUnitSizeMinusOne indicates the length in bytes of the NALUnit Size field minus one. For example, a size of one byte is indicated with a value of 0. The value of this field shall be one of 0, 1, or 3 corresponding to a length encoded with 1, 2, or 4 bytes, respectively.
StartcodeSize indicates the length in bytes of the Startcode of subsample in a sample
NALUnitSize indicates the length in bytes of the NAL unit of subsample in a sample

［本技術のMP4ビデオサンプル構造の比較］
図２６の例においては、上述したMP4ビデオサンプル構造を比較するための表が示されている。

図１７のＢのアクセスユニットの格納例においては、従来（現行）のsize＋dataという構造に近いというメリットがある。

図１８のＣまたは図１８のＣ´のアクセスユニットの格納例においては、従来（現行）のsize＋dataという構造に近く、ユニットサイズのセマンテックスが変更されないというメリットがある。また、startcodeのサイズが固定された場合、そのデータ構造は、従来（現行）のファイルフォーマットデザインと同様であるというメリットがある。

図１８のＤまたは図１８のＤ´のアクセスユニットの格納例においては、従来（現行）のsize＋dataという構造に近いというメリットがある。

図２０のＥまたは図２２のＥ´のアクセスユニットの格納例においては、エレメンタリーストリームへのストアがシンプルである（すなわち、startcodeを除去する必要がなく、ユニットサイズやstartcode サイズを加える必要がない）というメリットがある。

なお、もしサンプルのデザインの一貫性（design consistency）が重要な要因であるならば、図１８のＣまたは図１８のＣ´が最もよい提案である。しかしながら、図２０のＥまたは図２２のＥ´は、何の変更もなしにエレメンタリーストリームをストアするための最もよい方法である。

以上、上述したアクセスユニットの格納例は、すべて、mdatにstartcodeをストアするために提案されている（In this contribution, the following options are proposed to store startcode in mdat. (for both AVC and HEVC file format)）。

なお、上述した図２３のMP4ビデオサンプル構造は、次の図２７のように構成することも可能である。

［本技術のアクセスユニットの他の格納例］
図２７は、図２３のMP4ビデオサンプル構造の他の例を示す図である。

図２７のＧの例においては、図２３のＦの例と同様に、mdatからユニットサイズが除去されて、そして、startcodeが含まれているエレメンタリーストリームは、そのまま変更なしにストア（貯蔵）されている。ただし、図２３のＦの例と異なり、エレメンタリーストリームにおいて、各スタートコード（startcode）はNALユニット（NAL unit）に含められ、スタートコードを含めたNALユニットの長さを格納するために、ISO/IEC 14496-12において規定されるサンプル補助情報機能が適用されている。

各NALユニットの長さには、サンプル補助情報機能として、aux_info_type = 'nalz'とaux_info_type_parameter = 0が与えられる。サンプル補助情報機能は、使用されるサンプル補助情報機能サイズボックス（SampleAuxiliaryInformationSizesBox）である'saiz'と、サンプル補助情報機能オフセットボックスである'saio'により参照される。

すなわち、図２７のＧの例においては、サンプル補助情報機能として、スタートコードの長さは格納されず、スタートコードを含めたNALユニットの長さのみが格納される。したがって、図２７のＧの例については、スタートコードの長さが格納されない以外のことは、図２３のＦの例と同様である。

なお、図２７のMP4ビデオサンプルのファイルは、上述した図３の構成のファイル生成部２により上述した図４または図５のファイル生成処理で生成される。

また、図２７のMP4ビデオサンプルのファイルは、上述した図９の構成のファイル読取部５１により上述した図１１または図１２のファイル復号処理で復号される。

＜４．第４の実施の形態＞
ここで、従来、MP4のエレメンタリーストリームをMPEG2-PSに格納しようとしたとき、ユニットサイズを抜いて、スタートコードを入れて作らないといけなかった。逆に、MPEG2-PSのエレメンタリーストリームをMP4に格納しようとしたとき、スタートコードを抜いて、ユニットサイズを入れて作らないといけなかった。すなわち、少なくとも、２種類のストリームが存在し、ファイル化をする際に、ストリームの変更が必要であり、HRD conformanceに準拠しているのかどうかを示すフラグが必要であった。

また、startcodeの有無によりストリームに様々なバリエーションがあると、互換性がなくなってしまう恐れがあった。

これに対して、MPEG2-PSのファイルに格納する、startcodeを含むストリームであるバイトストリームフォーマットが定義されている。MP4ファイルへの格納を可能にすることで、両ファイルでの互換性が向上する。

本技術においては、サンプルの中に、バイトストリームがあるか否かを識別できるように、バイトストリームフォーマットの情報を格納するためのバイトストリームフォーマットインフォメーションボックスを定義する。

［バイトストリームフォーマットインフォメーションボックス］
次に、図２８を参照して、バイトストリームフォーマットインフォメーションボックスについて説明する。

バイトストリームフォーマットインフォメーションボックスは、パラメータセットなどを入れることができるサンプルエントリに対してオプショナルで定義される。パラメータセットなどを入れることができるサンプルエントリは、バイトストリームとしても格納することができる。なお、その際、バイトストリームであることをシグナルするために、このボックスが格納される。

図２８の例においては、バイトストリームフォーマットインフォメーションボックスの仕様について示されている。

The Byte Stream Format Information Box may be stored in 'avc3', 'avc4‘, 'mvc3' ,'mvc4‘ or ‘hev1‘ Sample Entry (in Sample entry box of media track).
This box SHALL be stored when sample data is structured by Byte Stream Format as defined in ISO/IEC 14496-10.
The Sub-Sample Information Box may be used to store one or more contiguous Byte stream NAL unit size
a sub-sample is defined as one or more contiguous Byte stream NAL units as defined in ISO/IEC 14496-10.

Box Type: ‘bsfi’
Container: Sample Entry (‘avc3’, ‘avc4’, ‘mvc3’, ‘mvc4’ or ‘hev1‘ )Mandatory: No
Quantity: Zero or one


Class ByteStreamFormatInformationBox extends Box(‘bsfi') {
ByteStreamFormatInformation() ByteStreamInformation;
}

バイトストリームフォーマットインフォメーションボックスは、メディアトラックのサンプルエントリーボックスにおける、’avc3’,’avc4’,’mvc3’,’mvc4’,または’hevc1’のサンプルエントリにストア（格納）されるようにする。’avc3’,’avc4’,’mvc3’,’mvc4’,または’hevc1’のサンプルエントリは、パラメータセットなどを入れることができるサンプルエントリである。

このボックスは、サンプルデータが、ISO/IEC 14496-10で定められているバイトストリームフォーマットによって構成されているとき、ストア（格納）されるようにする。

サブサンプルインフォメーションボックスは、１またはそれ以上の連続したstartcode を含めたNALユニットサイズをストア（格納）するために用いられてもよい。

サブサンプルは、ISO/IEC 14496-10で定められている、１またはそれ以上の連続したバイトストリームNALユニットとして定義される。

ボックスタイプ(Box Type)は’bsfi’であり、含まれるもの(Container)は、’avc3’,’avc4’,’mvc3’,’mvc4’,または’hevc1’のサンプルエントリである。マンダトリ(必須事項：Mandatory)はなく、クアンティティ(量：Quantity)は、０か１である。

バイトストリームフォーマットインフォメーションボックスは、バイトストリームフォーマットインフォメーションが記述される’bsfi’のボックスを拡張する。

以上のように構成されるバイトストリームフォーマットインフォメーションボックスにおいては、図２９に示されるように、新しいフォーマットである’avc5’,’avc6’,’mvc5’,’mvc6’,または’hevc2’のサンプルエントリを入れるだけで、サンプルエントリの拡張が可能である。

図２９は、バイトストリームフォーマットインフォメーションボックスの他の例を示す図である。

The Byte Stream Format Information Box SHALL be stored in 'avc5', 'avc6‘, 'mvc5' ,'mvc6‘ or ‘hev2‘ Sample Entry (in Sample entry box of media track).
This box SHALL be stored when sample data is structured by Byte Stream Format as defined in ISO/IEC 14496-10.
The Sub-Sample Information Box may be used to store one or more contiguous Byte stream NAL unit size
a sub-sample is defined as one or more contiguous Byte stream NAL units as defined in ISO/IEC 14496-10.

Box Type: ‘bsfi’
Container: Sample Entry (‘avc5’, ‘avc6’, ‘mvc5’, ‘mvc6’ or ‘hev2‘ )Mandatory: No
Quantity: Zero or one


Class ByteStreamFormatInformationBox extends Box(‘bsfi') {
ByteStreamFormatInformation() ByteStreamInformation;
}

なお、’avc3’,’avc4’,’mvc3’,’mvc4’,または’hevc1’は、パラメータセットを入れることができるコーデックのタイプであるが、’avc3’,’avc4’,’mvc3’,’mvc4’,または’hevc1’の場合、startcodeが入っているときと入っていないときがある。

これに対して、図２９のようにサンプルエントリを、例えば、すべてstartcodeが入っているコーデックのタイプとして、‘avc5’, ‘avc6’, ‘mvc5’, ‘mvc6’ or ‘hev2‘などに拡張し、このサンプルエントリを参照することにより、サンプルの中にバイトストリームがあるか否かを識別することができる。

また、サンプルエントリが、’avc3’,’avc4’,’mvc3’,’mvc4’,または’hevc1’の場合には、以下のように、バイトストリームフォーマットインフォメーションを構成することにより、サンプルの中にバイトストリームがあるか否か（すなわち、startcodeが入っているか否か）を識別することができる。

さらに、サブサンプルのバイトストリームの構造を示すことができる。

また、‘avc5’, ‘avc6’, ‘mvc5’, ‘mvc6’ or ‘hev2‘の場合には、以下のように、バイトストリームフォーマットインフォメーションを構成することにより、サブサンプルのバイトストリームの構造を示すことができる。

［バイトストリームフォーマットインフォメーションのデータ構造例］
図３０は、各サンプルエントリに格納されるバイトストリームフォーマットインフォメーションのデータ構造例を説明する図である。

aligned(8) class ByteStreamFormatInformation {
unsigned int(1) StartcodePresentFlag;
unsigned int(1) ZeroBytePresentFlag;
unsigned int(1) LeadingZeroBytesPresentFlag;
unsigned int(1) TrailingZeroBytesPresentFlag;
unsigned int(4) reserved =0;
unsigned int(24) reserved;
Box[] any_box; //Optional
}

StartcodePresentFlagは、サンプルにおけるStartcodeの有無を示すフラグである。サンプル中のすべてのサブサンプルがNALユニットの前に、３バイトのStartcodeを含む場合、StartcodePresentFlag が１となる。ZeroBytePresentFlagは、Startcodeの前に１byteのゼロデータの有無を示すフラグであり、このFlagが１の場合、Startcodeが４バイトであることを示す。

なお、StartcodePresentFlagとZeroBytePresentFlagの代わりに、２ビットのフラグを使用して、Startcodeが３バイトであるか、４バイトであるかを示すようにしてもよい。

LeadingZeroBytePresentFlagは、サンプルにおける０データの有無を示すフラグである。サンプル中のサブサンプルのうち、少なくとも１つのサブサンプルの３バイトあるいは４バイトの前に、１バイトの0x00を複数含む場合に、LeadingZeroBytePresentFlagが１となる。LeadingZeroBytePresentFlagが０の場合、サブサンプルの先頭が固定長スタートコードであることがわかる。

TrailingZeroBytePresentFlagは、サンプルにおける０データの有無を示すフラグである。サンプル中のサブサンプルのうち、少なくとも１つのサブサンプルの３バイトのNALユニットの後に、１バイトの0x00を複数含む場合に、TrailingZeroBytePresentFlagが１となる。

なお、これらのフラグのうちのすべてがあってもよいが、必須ではなく、また、他のフラグが追加されてもよい。

［本技術のNALユニットの格納例］
次に、上述したバイトストリームフォーマットインフォメーションを用いた場合のNALユニットの格納例について説明する。図３１は、NALユニットの前後に0x00（０データ）があるパターン１の場合のMP4ビデオサンプル構造の例を示す図である。すなわち、図３１の例においては、上述したバイトストリームフォーマットインフォメーションのフラグであるStartcodePresentFlag、ZeroBytePresentFlag、LeadingZeroBytePresentFlag、およびTrailingZeroBytePresentFlagがすべて１の場合のMP4ビデオサンプル構造の例が示されている。

図３１の例の場合、サンプルが、５サブサンプルにより構成される例が示されており、５サブサンプルのサイズが、サンプルサイズとして、サンプルサイズボックスに格納されている。

サブサンプルは、先頭の０データ(LeadingZeroBytes)、Startcode（４バイト）、NALユニット、および後尾の０データ(TrailingZeroBytes)により構成されており、先頭の０データから、後尾の０データまでのサイズがサブサンプルのサイズとして、サブサンプルインフォメーションボックスに格納されている。すなわち、サブサンプルインフォメーションボックスにサブサンプルのサイズがあるので、サブサンプルの境界がわかる。

このサブサンプルインフォメーションボックスの代わりに、図２７のＧの例と同様の構造でも実施可能である。サンプル補助情報機能として、aux_info_type = 'bsfi'とaux_info_type_parameter = 0が与えられる。サンプル補助情報機能は、使用されるサンプル補助情報機能サイズボックス（SampleAuxiliaryInformationSizesBox）である'saiz'と、サンプル補助情報機能オフセットボックスである'saio'により参照される。

なお、業務用のCBR（constant bitrate：固定ビットレート）においては、このような運用をする場合がある。したがって、このパターン１は、例えば、業務用のすべてがイントラピクチャで構成されるストリームに用いられる場合に好適である。

また、LeadingZeroBytesとTrailingZeroBytesとの区切りは、例えば、アプリケーションの運用によって設定されてもよい。

図３２は、サブサンプルがStartcodeから始まり、0x00（０データ）がないパターン２の場合のMP4ビデオサンプル構造の例を示す図である。すなわち、図３２の例においては、StartcodePresentFlagとZeroBytePresentFlagとが１であり、LeadingZeroBytePresentFlag、およびTrailingZeroBytePresentFlagとが０である場合のMP4ビデオサンプル構造の例が示されている。

図３２の例の場合、サンプルが、５サブサンプルにより構成される例が示されており、５サブサンプルのサイズが、サンプルサイズとして、サンプルサイズボックスに格納されている。

サブサンプルは、Startcode（４バイト）、およびNALユニットにより構成されており、StartcodeからNALユニットまでのサイズがサブサンプルのサイズとして、サブサンプルインフォメーションボックスに格納されている。すなわち、サブサンプルインフォメーションボックスにサブサンプルのサイズがあるので、サブサンプルの境界がわかる。

このパターン２は、最もシンプルな例である。

図３３は、サブサンプルがStartcodeから始まり、NALの後に0x00（０データ）があるパターン３の場合のMP4ビデオサンプル構造の例を示す図である。すなわち、図３３の例においては、StartcodePresentFlag、ZeroBytePresentFlag、およびTrailingZeroBytePresentFlag が１であり、LeadingZeroBytePresentFlagが０の場合のMP4ビデオサンプル構造の例が示されている。

図３３の例の場合、サンプルが、５サブサンプルにより構成される例が示されており、５サブサンプルのサイズが、サンプルサイズとして、サンプルサイズボックスに格納されている。

サブサンプルは、Startcode（４バイト）、NALユニット、および後尾の０データ(TrailingZeroBytes)により構成されており、Startcodeから後尾の０データまでのサイズがサブサンプルのサイズとして、サブサンプルインフォメーションボックスに格納されている。すなわち、サブサンプルインフォメーションボックスにサブサンプルのサイズがあるので、サブサンプルの境界がわかる。

なお、このパターン３の場合、例えば、業務用のすべてがイントラピクチャで構成されるストリームの編集機において、TrailingZeroで固定長にしていることがわかるので、編集しやすいという利点がある。また、３byte start codeもテレビジョン会議システムなどで用いられていることがある。

以上のように、バイトストリームフォーマットインフォメーションをボックス化し、バイトストリームフォーマットインフォメーションを定義するようにした。例えば、サブサンプルが、図３１乃至図３３を参照して上述したパターン１乃至３のいずれかのように構成されるので、サンプル内にバイトストリームか否かを識別することができる。

なお、図３１乃至図３３の各MP4ビデオサンプルのファイルは、上述した図３の構成のファイル生成部２により上述した図４または図５のファイル生成処理で生成される。

また、図３１乃至図３３の各MP4ビデオサンプルのファイルは、上述した図９の構成のファイル読取部５１により上述した図１１または図１２のファイル復号処理で復号される。

［バイトストリームフォーマットインフォメーションのデータ構造の他の例］
図３４は、各サンプルエントリに格納されるバイトストリームフォーマットインフォメーションのデータ構造例を説明する図である。すなわち、図３４の例においては、図３０を参照して上述したデータ構造の他の例が示されている。

aligned(8) class ByteStreamFormatInformation {
unsigned int(2) StartcodePresentFlag;
unsigned int(1) LeadingZeroBytesPresentFlag;
unsigned int(1) TrailingZeroBytesPresentFlag;
unsigned int(4) reserved =0;
unsigned int(24) reserved;
Box[] any_box; //Optional
}

StartcodePresentFlagは、すべてのサブサンプルのStartcodeの構造を示す2bitのフラグである。
StartcodePresentFlag = 00bは、reservedを示す。
StartcodePresentFlag = 01bは、サンプル中のすべてのサブサンプルはNALユニットの前に、3byteのStartcodeを含むことを示す。
StartcodePresentFlag = 10bは、サンプル中のすべてのサブサンプルはNALユニットの前に、3byteのStartcodeと、1byteのZeroByteデータを含む（すなわち、4byteで構成される）ことを示す。
StartcodePresentFlag = 11bは、サンプル中のすべてのサブサンプルはNALユニットの前に、3byteのStartcodeを含み、1byteのZeroByteデータを含むことがあることを示す。すなわち、この場合、3byteと4byteのStartcodeが混在している可能性があるため、01bであるか10bであるかが保証できない。

なお、この例は、図３０を参照して説明した構造例の他の例であり、Startcodeのサイズがわかるようにした例である。また、2bitsのフラグにより、3byte、4byte、またはそれらの混在が示される。

LeadingZeroBytePresentFlagは、サンプル中のサブサンプルのうち、少なくとも１つのサブサンプルの3byteまたは4byteのStartcodeの前に、1byteの0x00を複数含むことがあることを示す。

TrailingZeroBytePresentFlagは、サンプル中のサブサンプルのうち、少なくとも１つのサブサンプルのNALユニットの後に、1byteの0x00を複数含むことがあることを示す。

なお、図３４の例においても、これらのフラグのうちのすべてがあってもよいが、必須ではなく、また、他のフラグが追加されてもよい。

＜５．第５の実施の形態＞
［ファイル変換装置の構成例］
図３５は、本技術を適用した画像処理装置としての、ファイル変換装置の構成例を示すブロック図である。図３５のファイル変換装置３００は、例えば、MPEG-2 TS を MP4ファイルに変換する。

図３５の例において、ファイル変換装置３００は、ビデオストリーム解析部３１１、および、図１のファイル生成部２を含むように構成されている。

ビデオストリーム解析部３１１は、入力されるビデオストリームのフォーマットを解析し、MPEG-2 TSであると解析した場合、ビデオストリームを、ファイル生成部２に供給する。

ファイル生成部２は、MPEG-2 TS を MP4ファイルに変換する処理を行う。すなわち、ファイル生成部２は、図１の例と同様に、MPEG-2 TSを格納するMP4ファイルを生成する。

［ファイル変換処理の例］
次に、図３６のフローチャートを参照して、図３５のファイル変換装置３００のファイル変換処理について説明する。

ビデオストリーム解析部３１１は、ステップＳ３１１において、入力されるビデオストリームのフォーマットを解析し、MPEG-2 TSであると解析した場合、ビデオストリームを、ファイル生成部２に供給する。

ファイル生成部２は、ステップＳ３１２において、MPEG-2 TSを格納するMP4ファイルを生成する。なお、このファイル生成処理は、図５を参照して上述したファイル生成処理と同様の処理であるので、その説明は繰り返しになるため省略される。

以上のように、ファイル変換装置３００を構成することも可能である。

なお、上記説明においては、HEVC方式による符号化装置および復号装置について説明したが、本技術は、以下に説明するように、AVC方式による符号化装置および復号装置にも適用することができる。

＜６．第６の実施の形態＞
［符号化装置の構成例］
図３７は、本技術を適用した画像処理装置としての、符号化装置の他の構成例を示すブロック図である。

図３７に示す構成のうち、図１の構成と同じ構成には同じ符号を付してある。重複する説明については適宜省略する。

図３７の符号化装置の構成は、エンコーダ１の代わりに、エンコーダ４０１が設けられる点が図１の構成と異なる。図３７の符号化装置の構成は、ファイル生成部２が設けられている点が図１の構成と共通している。

すなわち、エンコーダ４０１には、フレーム単位の撮影画像等の画像が入力信号として入力される。また、図示せぬエンコーダ４０１の前段で設定されたSPS、符号化データに対応する画像の特性をシーケンスごとに示すVUI、SEIなども入力される。

エンコーダ４０１は、SPS、PPS、VUI、SEIに含まれるパラメータを用いて、入力信号をAVC方式で符号化する。そして、エンコーダ４０１は、SPS、PPS、VUI、SEIと、その結果得られる符号化データとから、MPEG-2 TSなどの符号化ストリームを生成し、生成した符号化ストリームを、ファイル生成部２に供給する。エンコーダ４０１の詳細は、図３８を参照して後述される。

ファイル生成部２は、エンコーダ４０１からの符号化ストリーム（符号化された一連の画像データ）を格納するファイルを生成する。

すなわち、図３６の符号化装置においては、AVC方式による符号化処理が行われる点のみが、図１の符号化装置と異なっている。

［符号化部の構成例］
図３８は、図３７のエンコーダ４０１の構成例を示すブロック図である。

図３８に示す構成のうち、図２の構成と同じ構成には同じ符号を付してある。重複する説明については適宜省略する。

図３８のエンコーダ４０１は、A/D変換部１１、画面並べ替えバッファ１２、演算部１３、直交変換部１４、量子化部１５、可逆符号化部１６、蓄積バッファ１７、逆量子化部１８、逆直交変換部１９、加算部２０、デブロックフィルタ２１、フレームメモリ２２、スイッチ２３、イントラ予測部２４、動き予測・補償部２５、予測画像選択部２６、およびレート制御部２７を含むように構成される。

すなわち、図３８のエンコーダ４０１の構成は、適応オフセットフィルタ１４１と適応ループフィルタ１４２が除かれている点、および可逆符号化部１６がHEVC方式ではなく、AVC方式により符号化を行う点のみが図２の構成と異なる。したがって、エンコーダ４０１においては、CU単位ではなく、ブロック単位に符号化処理が行われる。

可逆符号化部１６の符号化処理の対象は、適応オフセットフィルタおよび適応ループフィルタのパラメータを除き、図２の可逆符号化部１６の場合と基本的に同様である。すなわち、可逆符号化部１６は、図２の可逆符号化部１６と同様に、イントラ予測モード情報をイントラ予測部２４から取得する。また、インター予測モード情報、動きベクトル、参照画像を特定するための情報などを動き予測・補償部２５から取得する。

可逆符号化部１６は、図２の可逆符号化部１６と同様に、量子化部１５から供給される量子化された係数に対して、可変長符号化（例えば、CAVLCなど）、算術符号化（例えば、CABACなど）などの可逆符号化を行う。

また、可逆符号化部１６は、図２の可逆符号化部１６と同様に、イントラ予測モード情報、または、インター予測モード情報、動きベクトル、参照画像を特定する情報、オフセットフィルタ情報、およびフィルタ係数などを、符号化に関する符号化情報として可逆符号化する。可逆符号化部１６は、可逆符号化された符号化情報と係数を、符号化データとして蓄積バッファ１７に供給し、蓄積させる。なお、可逆符号化された符号化情報は、可逆符号化された係数のヘッダ情報とされてもよい。

デブロックフィルタ２１は、加算部２０から供給される局部的に復号された画像をフィルタリングすることにより、ブロック歪を除去する。デブロックフィルタ２１は、その結果得られる画像をフレームメモリ２２に供給し、蓄積させる。

フレームメモリ２２に蓄積された画像は、参照画像としてスイッチ２３を介してイントラ予測部２４または動き予測・補償部２５に出力される。

本技術は、このようなAVC方式の符号化装置にも適用することができる。

［復号装置の構成例］
図３９は、図３７の符号化装置により生成されたファイルを読み取って復号する、本技術を適用した復号装置の他の構成例を示すブロック図である。

図３９に示す構成のうち、図８の構成と同じ構成には同じ符号を付してある。重複する説明については適宜省略する。

図３９の復号装置２５１の構成は、デコーダ５２の代わりにデコーダ４５１が設けられる点が図８の構成と異なる。復号装置２５１の構成は、ファイル読取部５１が設けられている点が図８の構成と共通している。

復号装置のファイル読取部５１は、図３７の符号化装置により生成されたＭＰ４のファイルを受け取り、受け取ったファイルから、図３７のエンコーダ４０１により符号化された符号化ストリームを構成するSPS,PPS,VUI,SEI、符号化データ等を読み取る。ファイル読取部５１は、SPS,PPS,VUI,SEI、符号化データをデコーダ４５１に供給する。

デコーダ４５１は、ファイル読取部５１の制御のもと、ファイル読取部５１から供給されるSPS,PPS,VUI,SEI等を参照し、ファイル読取部５１から供給される符号化データをAVC方式で復号する。デコーダ４５１は、復号の結果得られる画像を、出力信号として後段に供給する。

すなわち、図３９の復号装置においては、AVC方式による復号処理が行われる点のみが、図８の復号装置と異なっている。

［復号部の構成例］
図４０は、図３９のデコーダ４５１の構成例を示すブロック図である。

図４０に示す構成のうち、図１０の構成と同じ構成には同じ符号を付してある。重複する説明については適宜省略する。

図４０のデコーダ４５１は、蓄積バッファ１０１、可逆復号部１０２、逆量子化部１０３、逆直交変換部１０４、加算部１０５、デブロックフィルタ１０６、画面並べ替えバッファ１０７、D/A変換部１０８、フレームメモリ１０９、スイッチ１１０、イントラ予測部１１１、動き補償部１１２、およびスイッチ１１３により構成される。

図４０のデコーダ４５１の構成は、適応オフセットフィルタ１４１と適応ループフィルタ１４２が除かれている点、および可逆復号部１０２がHEVC方式ではなく、AVC方式により復号を行う点のみが図１０の構成と異なる。したがって、デコーダ４５１においては、CU単位ではなく、ブロック単位に復号処理が行われる。

可逆復号部１０２の復号処理の対象は、適応オフセットフィルタおよび適応ループフィルタのパラメータを除き、図１０の可逆復号部１０２の場合と基本的に同様である。すなわち、可逆復号部１０２は、図１０の可逆復号部１０２と同様に、蓄積バッファ１０１からの符号化データに対して、可変長復号や、算術復号等の可逆復号を施すことで、量子化された係数と符号化情報を得る。可逆復号部１０２は、量子化された係数を逆量子化部１０３に供給する。

また、可逆復号部１０２は、図１０の可逆復号部１０２と同様に、符号化情報としてのイントラ予測モード情報などをイントラ予測部１１１に供給し、動きベクトル、参照画像を特定するための情報、インター予測モード情報などを動き補償部１１２に供給する。さらに、可逆復号部１０２は、符号化情報としてのイントラ予測モード情報またはインター予測モード情報をスイッチ１１３に供給する。

デブロックフィルタ１０６は、加算部１０５から供給される画像をフィルタリングすることにより、ブロック歪を除去する。デブロックフィルタ１０６は、その結果得られる画像をフレームメモリ１０９および画面並べ替えバッファ１０７に供給する。

本技術は、このようなAVC方式の復号装置にも適用することができる。

なお、上記説明においては、MP4ファイルフォーマットの例を説明したが、ファイルフォーマットは、MP4ファイルフォーマットまたはAVCファイルフォーマットには限定されない。本技術による課題・効果が同じであれば、別のファイルフォーマット、伝送する際に用いるストリーム、ファイルに格納する際に用いるストリームに対して、同様に適用することができる。

また、本開示は、例えば、HEVC方式等の様に、離散コサイン変換等の直交変換と動き補償によって圧縮された画像情報（ビットストリーム）を、衛星放送、ケーブルテレビジョン、インターネット、または携帯電話機などのネットワークメディアを介して受信する際に用いられる画像符号化装置および画像復号装置に適用することができる。また、本開示は、光、磁気ディスク、およびフラッシュメモリのような記憶メディア上で処理する際に用いられる画像符号化装置および画像復号装置に適用することができる。

なお、上述した一連の処理は、ハードウエアにより実行することもできるし、ソフトウエアにより実行することもできる。一連の処理をソフトウエアにより実行する場合には、そのソフトウエアを構成するプログラムが、コンピュータにインストールされる。ここで、コンピュータには、専用のハードウエアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどが含まれる。

図４１は、上述した一連の処理をプログラムにより実行するコンピュータのハードウエアの構成例を示すブロック図である。

コンピュータ８００において、CPU（Central Processing Unit）８０１，ROM（Read Only Memory）８０２，RAM（Random Access Memory）８０３は、バス８０４により相互に接続されている。

バス８０４には、さらに、入出力インタフェース８０５が接続されている。入出力インタフェース８０５には、入力部８０６、出力部８０７、記憶部８０８、通信部８０９、及びドライブ８１０が接続されている。

入力部８０６は、キーボード、マウス、マイクロホンなどよりなる。出力部８０７は、ディスプレイ、スピーカなどよりなる。記憶部８０８は、ハードディスクや不揮発性のメモリなどよりなる。通信部８０９は、ネットワークインタフェースなどよりなる。ドライブ８１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア８１１を駆動する。

以上のように構成されるコンピュータでは、CPU８０１が、例えば、記憶部８０８に記憶されているプログラムを、入出力インタフェース８０５及びバス８０４を介して、RAM８０３にロードして実行することにより、上述した一連の処理が行われる。

コンピュータ８００（CPU８０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア８１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することができる。

コンピュータでは、プログラムは、リムーバブルメディア８１１をドライブ８１０に装着することにより、入出力インタフェース８０５を介して、記憶部８０８にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部８０９で受信し、記憶部８０８にインストールすることができる。その他、プログラムは、ROM８０２や記憶部８０８に、あらかじめインストールしておくことができる。

なお、コンピュータが実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。

また、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。

また、本明細書において、システムとは、複数のデバイス（装置）により構成される装置全体を表すものである。

また、以上において、１つの装置（または処理部）として説明した構成を分割し、複数の装置（または処理部）として構成するようにしてもよい。逆に、以上において複数の装置（または処理部）として説明した構成をまとめて１つの装置（または処理部）として構成されるようにしてもよい。また、各装置（または各処理部）の構成に上述した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置（または処理部）の構成の一部を他の装置（または他の処理部）の構成に含めるようにしてもよい。つまり、本技術は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。

なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。

また、例えば、本技術は、１つの機能をネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。
また、上述のフローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。

さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。

上述した実施形態に係る画像符号化装置及び画像復号装置は、衛星放送、ケーブルＴＶなどの有線放送、インターネット上での配信、及びセルラー通信による端末への配信などにおける送信機若しくは受信機、光ディスク、磁気ディスク及びフラッシュメモリなどの媒体に画像を記録する記録装置、又は、これら記憶媒体から画像を再生する再生装置などの様々な電子機器に応用され得る。以下、４つの応用例について説明する。

＜７．応用例＞
［第１の応用例：テレビジョン受像機］
図４２は、上述した実施形態を適用したテレビジョン装置の概略的な構成の一例を示している。テレビジョン装置９００は、アンテナ９０１、チューナ９０２、デマルチプレクサ９０３、デコーダ９０４、映像信号処理部９０５、表示部９０６、音声信号処理部９０７、スピーカ９０８、外部インタフェース９０９、制御部９１０、ユーザインタフェース９１１、及びバス９１２を備える。

チューナ９０２は、アンテナ９０１を介して受信される放送信号から所望のチャンネルの信号を抽出し、抽出した信号を復調する。そして、チューナ９０２は、復調により得られた符号化ビットストリームをデマルチプレクサ９０３へ出力する。即ち、チューナ９０２は、画像が符号化されている符号化ストリームを受信する、テレビジョン装置９００における伝送手段としての役割を有する。

デマルチプレクサ９０３は、符号化ビットストリームから視聴対象の番組の映像ストリーム及び音声ストリームを分離し、分離した各ストリームをデコーダ９０４へ出力する。また、デマルチプレクサ９０３は、符号化ビットストリームからEPG（Electronic Program Guide）などの補助的なデータを抽出し、抽出したデータを制御部９１０に供給する。なお、デマルチプレクサ９０３は、符号化ビットストリームがスクランブルされている場合には、デスクランブルを行ってもよい。

デコーダ９０４は、デマルチプレクサ９０３から入力される映像ストリーム及び音声ストリームを復号する。そして、デコーダ９０４は、復号処理により生成される映像データを映像信号処理部９０５へ出力する。また、デコーダ９０４は、復号処理により生成される音声データを音声信号処理部９０７へ出力する。

映像信号処理部９０５は、デコーダ９０４から入力される映像データを再生し、表示部９０６に映像を表示させる。また、映像信号処理部９０５は、ネットワークを介して供給されるアプリケーション画面を表示部９０６に表示させてもよい。また、映像信号処理部９０５は、映像データについて、設定に応じて、例えばノイズ除去などの追加的な処理を行ってもよい。さらに、映像信号処理部９０５は、例えばメニュー、ボタン又はカーソルなどのGUI（Graphical User Interface）の画像を生成し、生成した画像を出力画像に重畳してもよい。

表示部９０６は、映像信号処理部９０５から供給される駆動信号により駆動され、表示デバイス（例えば、液晶ディスプレイ、プラズマディスプレイ又はOELD（Organic ElectroLuminescence Display）（有機ELディスプレイ）など）の映像面上に映像又は画像を表示する。

音声信号処理部９０７は、デコーダ９０４から入力される音声データについてD/A変換及び増幅などの再生処理を行い、スピーカ９０８から音声を出力させる。また、音声信号処理部９０７は、音声データについてノイズ除去などの追加的な処理を行ってもよい。

外部インタフェース９０９は、テレビジョン装置９００と外部機器又はネットワークとを接続するためのインタフェースである。例えば、外部インタフェース９０９を介して受信される映像ストリーム又は音声ストリームが、デコーダ９０４により復号されてもよい。即ち、外部インタフェース９０９もまた、画像が符号化されている符号化ストリームを受信する、テレビジョン装置９００における伝送手段としての役割を有する。

制御部９１０は、CPUなどのプロセッサ、並びにRAM及びROMなどのメモリを有する。メモリは、CPUにより実行されるプログラム、プログラムデータ、EPGデータ、及びネットワークを介して取得されるデータなどを記憶する。メモリにより記憶されるプログラムは、例えば、テレビジョン装置９００の起動時にCPUにより読み込まれ、実行される。CPUは、プログラムを実行することにより、例えばユーザインタフェース９１１から入力される操作信号に応じて、テレビジョン装置９００の動作を制御する。

ユーザインタフェース９１１は、制御部９１０と接続される。ユーザインタフェース９１１は、例えば、ユーザがテレビジョン装置９００を操作するためのボタン及びスイッチ、並びに遠隔制御信号の受信部などを有する。ユーザインタフェース９１１は、これら構成要素を介してユーザによる操作を検出して操作信号を生成し、生成した操作信号を制御部９１０へ出力する。

バス９１２は、チューナ９０２、デマルチプレクサ９０３、デコーダ９０４、映像信号処理部９０５、音声信号処理部９０７、外部インタフェース９０９及び制御部９１０を相互に接続する。

このように構成されたテレビジョン装置９００において、デコーダ９０４は、上述した実施形態に係る画像復号装置（例えば、図８のファイル読取部５１およびデコーダ５２よりなる復号装置）の機能を有する。それにより、テレビジョン装置９００での画像の復号に際して、伝送する際に用いるストリーム又はファイルに格納する際に用いるストリームを復号する際の処理の負担を軽減することができる。

［第２の応用例：携帯電話機］
図４３は、上述した実施形態を適用した携帯電話機の概略的な構成の一例を示している。携帯電話機９２０は、アンテナ９２１、通信部９２２、音声コーデック９２３、スピーカ９２４、マイクロホン９２５、カメラ部９２６、画像処理部９２７、多重分離部９２８、記録再生部９２９、表示部９３０、制御部９３１、操作部９３２、及びバス９３３を備える。

アンテナ９２１は、通信部９２２に接続される。スピーカ９２４及びマイクロホン９２５は、音声コーデック９２３に接続される。操作部９３２は、制御部９３１に接続される。バス９３３は、通信部９２２、音声コーデック９２３、カメラ部９２６、画像処理部９２７、多重分離部９２８、記録再生部９２９、表示部９３０、及び制御部９３１を相互に接続する。

携帯電話機９２０は、音声通話モード、データ通信モード、撮影モード及びテレビ電話モードを含む様々な動作モードで、音声信号の送受信、電子メール又は画像データの送受信、画像の撮像、及びデータの記録などの動作を行う。

音声通話モードにおいて、マイクロホン９２５により生成されるアナログ音声信号は、音声コーデック９２３に供給される。音声コーデック９２３は、アナログ音声信号を音声データへ変換し、変換された音声データをA/D変換し圧縮する。そして、音声コーデック９２３は、圧縮後の音声データを通信部９２２へ出力する。通信部９２２は、音声データを符号化及び変調し、送信信号を生成する。そして、通信部９２２は、生成した送信信号を、アンテナ９２１を介して基地局（図示せず）へ送信する。また、通信部９２２は、アンテナ９２１を介して受信される無線信号を増幅し及び周波数変換し、受信信号を取得する。そして、通信部９２２は、受信信号を復調及び復号して音声データを生成し、生成した音声データを音声コーデック９２３へ出力する。音声コーデック９２３は、音声データを伸張し及びD/A変換し、アナログ音声信号を生成する。そして、音声コーデック９２３は、生成した音声信号をスピーカ９２４に供給して音声を出力させる。

また、データ通信モードにおいて、例えば、制御部９３１は、操作部９３２を介するユーザによる操作に応じて、電子メールを構成する文字データを生成する。また、制御部９３１は、文字を表示部９３０に表示させる。また、制御部９３１は、操作部９３２を介するユーザからの送信指示に応じて電子メールデータを生成し、生成した電子メールデータを通信部９２２へ出力する。通信部９２２は、電子メールデータを符号化及び変調し、送信信号を生成する。そして、通信部９２２は、生成した送信信号を、アンテナ９２１を介して基地局（図示せず）へ送信する。また、通信部９２２は、アンテナ９２１を介して受信される無線信号を増幅し及び周波数変換し、受信信号を取得する。そして、通信部９２２は、受信信号を復調及び復号して電子メールデータを復元し、復元した電子メールデータを制御部９３１へ出力する。制御部９３１は、表示部９３０に電子メールの内容を表示させると共に、電子メールデータを記録再生部９２９の記憶媒体に記憶させる。

記録再生部９２９は、読み書き可能な任意の記憶媒体を有する。例えば、記憶媒体は、RAM又はフラッシュメモリなどの内蔵型の記憶媒体であってもよく、ハードディスク、磁気ディスク、光磁気ディスク、光ディスク、USB（Universal Serial Bus）メモリ、又はメモリカードなどの外部装着型の記憶媒体であってもよい。

また、撮影モードにおいて、例えば、カメラ部９２６は、被写体を撮像して画像データを生成し、生成した画像データを画像処理部９２７へ出力する。画像処理部９２７は、カメラ部９２６から入力される画像データを符号化し、符号化ストリームを記憶再生部９２９の記憶媒体に記憶させる。

また、テレビ電話モードにおいて、例えば、多重分離部９２８は、画像処理部９２７により符号化された映像ストリームと、音声コーデック９２３から入力される音声ストリームとを多重化し、多重化したストリームを通信部９２２へ出力する。通信部９２２は、ストリームを符号化及び変調し、送信信号を生成する。そして、通信部９２２は、生成した送信信号を、アンテナ９２１を介して基地局（図示せず）へ送信する。また、通信部９２２は、アンテナ９２１を介して受信される無線信号を増幅し及び周波数変換し、受信信号を取得する。これら送信信号及び受信信号には、符号化ビットストリームが含まれ得る。そして、通信部９２２は、受信信号を復調及び復号してストリームを復元し、復元したストリームを多重分離部９２８へ出力する。多重分離部９２８は、入力されるストリームから映像ストリーム及び音声ストリームを分離し、映像ストリームを画像処理部９２７、音声ストリームを音声コーデック９２３へ出力する。画像処理部９２７は、映像ストリームを復号し、映像データを生成する。映像データは、表示部９３０に供給され、表示部９３０により一連の画像が表示される。音声コーデック９２３は、音声ストリームを伸張し及びD/A変換し、アナログ音声信号を生成する。そして、音声コーデック９２３は、生成した音声信号をスピーカ９２４に供給して音声を出力させる。

このように構成された携帯電話機９２０において、画像処理部９２７は、上述した実施形態に係る画像符号化装置（例えば、図１のエンコーダ１およびファイル生成部２よりなる符号化装置）及び画像復号装置（例えば、図８のファイル読取部５１およびデコーダ５２よりなる復号装置）の機能を有する。それにより、携帯電話機９２０での画像の符号化及び復号に際して、伝送する際に用いるストリーム又はファイルに格納する際に用いるストリームを復号する際の処理の負担を軽減することができる。

［第３の応用例：記録再生装置］
図４４は、上述した実施形態を適用した記録再生装置の概略的な構成の一例を示している。記録再生装置９４０は、例えば、受信した放送番組の音声データ及び映像データを符号化して記録媒体に記録する。また、記録再生装置９４０は、例えば、他の装置から取得される音声データ及び映像データを符号化して記録媒体に記録してもよい。また、記録再生装置９４０は、例えば、ユーザの指示に応じて、記録媒体に記録されているデータをモニタ及びスピーカ上で再生する。このとき、記録再生装置９４０は、音声データ及び映像データを復号する。

記録再生装置９４０は、チューナ９４１、外部インタフェース９４２、エンコーダ９４３、HDD（Hard Disk Drive）９４４、ディスクドライブ９４５、セレクタ９４６、デコーダ９４７、OSD（On-Screen Display）９４８、制御部９４９、及びユーザインタフェース９５０を備える。

チューナ９４１は、アンテナ（図示せず）を介して受信される放送信号から所望のチャンネルの信号を抽出し、抽出した信号を復調する。そして、チューナ９４１は、復調により得られた符号化ビットストリームをセレクタ９４６へ出力する。即ち、チューナ９４１は、記録再生装置９４０における伝送手段としての役割を有する。

外部インタフェース９４２は、記録再生装置９４０と外部機器又はネットワークとを接続するためのインタフェースである。外部インタフェース９４２は、例えば、IEEE1394インタフェース、ネットワークインタフェース、USBインタフェース、又はフラッシュメモリインタフェースなどであってよい。例えば、外部インタフェース９４２を介して受信される映像データ及び音声データは、エンコーダ９４３へ入力される。即ち、外部インタフェース９４２は、記録再生装置９４０における伝送手段としての役割を有する。

エンコーダ９４３は、外部インタフェース９４２から入力される映像データ及び音声データが符号化されていない場合に、映像データ及び音声データを符号化する。そして、エンコーダ９４３は、符号化ビットストリームをセレクタ９４６へ出力する。

HDD９４４は、映像及び音声などのコンテンツデータが圧縮された符号化ビットストリーム、各種プログラムおよびその他のデータを内部のハードディスクに記録する。また、HDD９４４は、映像及び音声の再生時に、これらデータをハードディスクから読み出す。

ディスクドライブ９４５は、装着されている記録媒体へのデータの記録及び読み出しを行う。ディスクドライブ９４５に装着される記録媒体は、例えばDVDディスク（DVD-Video、DVD-RAM、DVD-R、DVD-RW、DVD+R、DVD+RW等）又はBlu-ray（登録商標）ディスクなどであってよい。

セレクタ９４６は、映像及び音声の記録時には、チューナ９４１又はエンコーダ９４３から入力される符号化ビットストリームを選択し、選択した符号化ビットストリームをHDD９４４又はディスクドライブ９４５へ出力する。また、セレクタ９４６は、映像及び音声の再生時には、HDD９４４又はディスクドライブ９４５から入力される符号化ビットストリームをデコーダ９４７へ出力する。

デコーダ９４７は、符号化ビットストリームを復号し、映像データ及び音声データを生成する。そして、デコーダ９４７は、生成した映像データをOSD９４８へ出力する。また、デコーダ９４７は、生成した音声データを外部のスピーカへ出力する。

OSD９４８は、デコーダ９４７から入力される映像データを再生し、映像を表示する。また、OSD９４８は、表示する映像に、例えばメニュー、ボタン又はカーソルなどのGUIの画像を重畳してもよい。

制御部９４９は、CPUなどのプロセッサ、並びにRAM及びROMなどのメモリを有する。メモリは、CPUにより実行されるプログラム、及びプログラムデータなどを記憶する。メモリにより記憶されるプログラムは、例えば、記録再生装置９４０の起動時にCPUにより読み込まれ、実行される。CPUは、プログラムを実行することにより、例えばユーザインタフェース９５０から入力される操作信号に応じて、記録再生装置９４０の動作を制御する。

ユーザインタフェース９５０は、制御部９４９と接続される。ユーザインタフェース９５０は、例えば、ユーザが記録再生装置９４０を操作するためのボタン及びスイッチ、並びに遠隔制御信号の受信部などを有する。ユーザインタフェース９５０は、これら構成要素を介してユーザによる操作を検出して操作信号を生成し、生成した操作信号を制御部９４９へ出力する。

このように構成された記録再生装置９４０において、エンコーダ９４３は、上述した実施形態に係る画像符号化装置（例えば、図１のエンコーダ１およびファイル生成部２よりなる符号化装置）の機能を有する。また、デコーダ９４７は、上述した実施形態に係る画像復号装置（例えば、図８のファイル読取部５１およびデコーダ５２よりなる復号装置）の機能を有する。それにより、記録再生装置９４０での画像の符号化及び復号に際して、伝送する際に用いるストリーム又はファイルに格納する際に用いるストリームを復号する際の処理の負担を軽減することができる。

［第４の応用例：撮像装置］
図４５は、上述した実施形態を適用した撮像装置の概略的な構成の一例を示している。撮像装置９６０は、被写体を撮像して画像を生成し、画像データを符号化して記録媒体に記録する。

撮像装置９６０は、光学ブロック９６１、撮像部９６２、信号処理部９６３、画像処理部９６４、表示部９６５、外部インタフェース９６６、メモリ９６７、メディアドライブ９６８、OSD９６９、制御部９７０、ユーザインタフェース９７１、及びバス９７２を備える。

光学ブロック９６１は、撮像部９６２に接続される。撮像部９６２は、信号処理部９６３に接続される。表示部９６５は、画像処理部９６４に接続される。ユーザインタフェース９７１は、制御部９７０に接続される。バス９７２は、画像処理部９６４、外部インタフェース９６６、メモリ９６７、メディアドライブ９６８、OSD９６９、及び制御部９７０を相互に接続する。

光学ブロック９６１は、フォーカスレンズ及び絞り機構などを有する。光学ブロック９６１は、被写体の光学像を撮像部９６２の撮像面に結像させる。撮像部９６２は、CCD（Charge Coupled Device）又はCMOS（Complementary Metal Oxide Semiconductor）などのイメージセンサを有し、撮像面に結像した光学像を光電変換によって電気信号としての画像信号に変換する。そして、撮像部９６２は、画像信号を信号処理部９６３へ出力する。

信号処理部９６３は、撮像部９６２から入力される画像信号に対してニー補正、ガンマ補正、色補正などの種々のカメラ信号処理を行う。信号処理部９６３は、カメラ信号処理後の画像データを画像処理部９６４へ出力する。

画像処理部９６４は、信号処理部９６３から入力される画像データを符号化し、符号化データを生成する。そして、画像処理部９６４は、生成した符号化データを外部インタフェース９６６又はメディアドライブ９６８へ出力する。また、画像処理部９６４は、外部インタフェース９６６又はメディアドライブ９６８から入力される符号化データを復号し、画像データを生成する。そして、画像処理部９６４は、生成した画像データを表示部９６５へ出力する。また、画像処理部９６４は、信号処理部９６３から入力される画像データを表示部９６５へ出力して画像を表示させてもよい。また、画像処理部９６４は、OSD９６９から取得される表示用データを、表示部９６５へ出力する画像に重畳してもよい。

OSD９６９は、例えばメニュー、ボタン又はカーソルなどのGUIの画像を生成して、生成した画像を画像処理部９６４へ出力する。

外部インタフェース９６６は、例えばUSB入出力端子として構成される。外部インタフェース９６６は、例えば、画像の印刷時に、撮像装置９６０とプリンタとを接続する。また、外部インタフェース９６６には、必要に応じてドライブが接続される。ドライブには、例えば、磁気ディスク又は光ディスクなどのリムーバブルメディアが装着され、リムーバブルメディアから読み出されるプログラムが、撮像装置９６０にインストールされ得る。さらに、外部インタフェース９６６は、LAN又はインターネットなどのネットワークに接続されるネットワークインタフェースとして構成されてもよい。即ち、外部インタフェース９６６は、撮像装置９６０における伝送手段としての役割を有する。

メディアドライブ９６８に装着される記録媒体は、例えば、磁気ディスク、光磁気ディスク、光ディスク、又は半導体メモリなどの、読み書き可能な任意のリムーバブルメディアであってよい。また、メディアドライブ９６８に記録媒体が固定的に装着され、例えば、内蔵型ハードディスクドライブ又はSSD（Solid State Drive）のような非可搬性の記憶部が構成されてもよい。

制御部９７０は、CPUなどのプロセッサ、並びにRAM及びROMなどのメモリを有する。メモリは、CPUにより実行されるプログラム、及びプログラムデータなどを記憶する。メモリにより記憶されるプログラムは、例えば、撮像装置９６０の起動時にCPUにより読み込まれ、実行される。CPUは、プログラムを実行することにより、例えばユーザインタフェース９７１から入力される操作信号に応じて、撮像装置９６０の動作を制御する。

ユーザインタフェース９７１は、制御部９７０と接続される。ユーザインタフェース９７１は、例えば、ユーザが撮像装置９６０を操作するためのボタン及びスイッチなどを有する。ユーザインタフェース９７１は、これら構成要素を介してユーザによる操作を検出して操作信号を生成し、生成した操作信号を制御部９７０へ出力する。

このように構成された撮像装置９６０において、画像処理部９６４は、上述した実施形態に係る画像符号化装置（例えば、図１のエンコーダ１およびファイル生成部２よりなる符号化装置）及び画像復号装置（例えば、図８のファイル読取部５１およびデコーダ５２よりなる復号装置）の機能を有する。それにより、撮像装置９６０での画像の符号化及び復号に際して、伝送する際に用いるストリーム又はファイルに格納する際に用いるストリームを復号する際の処理の負担を軽減することができる。

＜８．第７の実施の形態＞
[実施のその他の例]
以上において本技術を適用する装置やシステム等の例を説明したが、本技術は、これに限らず、このような装置またはシステムを構成する装置に搭載するあらゆる構成、例えば、システムLSI（Large Scale Integration）等としてのプロセッサ、複数のプロセッサ等を用いるモジュール、複数のモジュール等を用いるユニット、ユニットにさらにその他の機能を付加したセット等（すなわち、装置の一部の構成）として実施することもできる。

[ビデオセット]
本技術をセットとして実施する場合の例について、図４６を参照して説明する。図４６は、本技術を適用したビデオセットの概略的な構成の一例を示している。

近年、電子機器の多機能化が進んでおり、その開発や製造において、その一部の構成を販売や提供等として実施する場合、１機能を有する構成として実施を行う場合だけでなく、関連する機能を有する複数の構成を組み合わせ、複数の機能を有する１セットとして実施を行う場合も多く見られるようになってきた。

図４６に示されるビデオセット１３００は、このような多機能化された構成であり、画像の符号化や復号（いずれか一方でもよいし、両方でも良い）に関する機能を有するデバイスに、その機能に関連するその他の機能を有するデバイスを組み合わせたものである。

図４６に示されるように、ビデオセット１３００は、ビデオモジュール１３１１、外部メモリ１３１２、パワーマネージメントモジュール１３１３、およびフロントエンドモジュール１３１４等のモジュール群と、コネクティビティ１３２１、カメラ１３２２、およびセンサ１３２３等の関連する機能を有するデバイスとを有する。

モジュールは、互いに関連するいくつかの部品的機能をまとめ、まとまりのある機能を持った部品としたものである。具体的な物理的構成は任意であるが、例えば、それぞれ機能を有する複数のプロセッサ、抵抗やコンデンサ等の電子回路素子、その他のデバイス等を配線基板等に配置して一体化したものが考えられる。また、モジュールに他のモジュールやプロセッサ等を組み合わせて新たなモジュールとすることも考えられる。

図４６の例の場合、ビデオモジュール１３１１は、画像処理に関する機能を有する構成を組み合わせたものであり、アプリケーションプロセッサ、ビデオプロセッサ、ブロードバンドモデム１３３３、およびRFモジュール１３３４を有する。

プロセッサは、所定の機能を有する構成をSoC（System On a Chip）により半導体チップに集積したものであり、例えばシステムLSI（Large Scale Integration）等と称されるものもある。この所定の機能を有する構成は、論理回路（ハードウエア構成）であってもよいし、CPU、ROM、RAM等と、それらを用いて実行されるプログラム（ソフトウエア構成）であってもよいし、その両方を組み合わせたものであってもよい。例えば、プロセッサが、論理回路とCPU、ROM、RAM等とを有し、機能の一部を論理回路（ハードウエア構成）により実現し、その他の機能をCPUにおいて実行されるプログラム（ソフトウエア構成）により実現するようにしてもよい。

図４６のアプリケーションプロセッサ１３３１は、画像処理に関するアプリケーションを実行するプロセッサである。このアプリケーションプロセッサ１３３１において実行されるアプリケーションは、所定の機能を実現するために、演算処理を行うだけでなく、例えばビデオプロセッサ１３３２等、ビデオモジュール１３１１内外の構成を必要に応じて制御することもできる。

ビデオプロセッサ１３３２は、画像の符号化・復号（その一方若しくは両方）に関する機能を有するプロセッサである。

ブロードバンドモデム１３３３は、インターネットや公衆電話回線網等の広帯域の回線を介して行われる有線若しくは無線（またはその両方）の広帯域通信に関する処理を行うプロセッサ（若しくはモジュール）である。例えば、ブロードバンドモデム１３３３は、送信するデータ（デジタル信号）をデジタル変調する等してアナログ信号に変換したり、受信したアナログ信号を復調してデータ（デジタル信号）に変換したりする。例えば、ブロードバンドモデム１３３３は、ビデオプロセッサ１３３２が処理する画像データや画像データが符号化されたストリーム、アプリケーションプログラム、設定データ等、任意の情報をデジタル変調・復調することができる。

RFモジュール１３３４は、アンテナを介して送受信されるRF（Radio Frequency）信号に対して、周波数変換、変復調、増幅、フィルタ処理等を行うモジュールである。例えば、RFモジュール１３３４は、ブロードバンドモデム１３３３により生成されたベースバンド信号に対して周波数変換等を行ってRF信号を生成する。また、例えば、RFモジュール１３３４は、フロントエンドモジュール１３１４を介して受信されたRF信号に対して周波数変換等を行ってベースバンド信号を生成する。

なお、図４６において点線１３４１に示されるように、アプリケーションプロセッサ１３３１とビデオプロセッサ１３３２を、一体化し、１つのプロセッサとして構成されるようにしてもよい。

外部メモリ１３１２は、ビデオモジュール１３１１の外部に設けられた、ビデオモジュール１３１１により利用される記憶デバイスを有するモジュールである。この外部メモリ１３１２の記憶デバイスは、どのような物理構成により実現するようにしてもよいが、一般的にフレーム単位の画像データのような大容量のデータの格納に利用されることが多いので、例えばDRAM（Dynamic Random Access Memory）のような比較的安価で大容量の半導体メモリにより実現するのが望ましい。

パワーマネージメントモジュール１３１３は、ビデオモジュール１３１１（ビデオモジュール１３１１内の各構成）への電力供給を管理し、制御する。

フロントエンドモジュール１３１４は、RFモジュール１３３４に対してフロントエンド機能（アンテナ側の送受信端の回路）を提供するモジュールである。図４６に示されるように、フロントエンドモジュール１３１４は、例えば、アンテナ部１３５１、フィルタ１３５２、および増幅部１３５３を有する。

アンテナ部１３５１は、無線信号を送受信するアンテナおよびその周辺の構成を有する。アンテナ部１３５１は、増幅部１３５３から供給される信号を無線信号として送信し、受信した無線信号を電気信号（RF信号）としてフィルタ１３５２に供給する。フィルタ１３５２は、アンテナ部１３５１を介して受信されたRF信号に対してフィルタ処理等を行い、処理後のRF信号をRFモジュール１３３４に供給する。増幅部１３５３は、RFモジュール１３３４から供給されるRF信号を増幅し、アンテナ部１３５１に供給する。

コネクティビティ１３２１は、外部との接続に関する機能を有するモジュールである。コネクティビティ１３２１の物理構成は、任意である。例えば、コネクティビティ１３２１は、ブロードバンドモデム１３３３が対応する通信規格以外の通信機能を有する構成や、外部入出力端子等を有する。

例えば、コネクティビティ１３２１が、Bluetooth（登録商標）、IEEE 802.11（例えばWi-Fi（Wireless Fidelity、登録商標））、NFC（Near Field Communication）、IrDA（InfraRed Data Association）等の無線通信規格に準拠する通信機能を有するモジュールや、その規格に準拠した信号を送受信するアンテナ等を有するようにしてもよい。また、例えば、コネクティビティ１３２１が、USB（Universal Serial Bus）、HDMI（登録商標）（High-Definition Multimedia Interface）等の有線通信規格に準拠する通信機能を有するモジュールや、その規格に準拠した端子を有するようにしてもよい。さらに、例えば、コネクティビティ１３２１が、アナログ入出力端子等のその他のデータ（信号）伝送機能等を有するようにしてもよい。

なお、コネクティビティ１３２１が、データ（信号）の伝送先のデバイスを含むようにしてもよい。例えば、コネクティビティ１３２１が、磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリ等の記録媒体に対してデータの読み出しや書き込みを行うドライブ（リムーバブルメディアのドライブだけでなく、ハードディスク、SSD（Solid State Drive）、NAS（Network Attached Storage）等も含む）を有するようにしてもよい。また、コネクティビティ１３２１が、画像や音声の出力デバイス（モニタやスピーカ等）を有するようにしてもよい。

カメラ１３２２は、被写体を撮像し、被写体の画像データを得る機能を有するモジュールである。カメラ１３２２の撮像により得られた画像データは、例えば、ビデオプロセッサ１３３２に供給されて符号化される。

センサ１３２３は、例えば、音声センサ、超音波センサ、光センサ、照度センサ、赤外線センサ、イメージセンサ、回転センサ、角度センサ、角速度センサ、速度センサ、加速度センサ、傾斜センサ、磁気識別センサ、衝撃センサ、温度センサ等、任意のセンサ機能を有するモジュールである。センサ１３２３により検出されたデータは、例えば、アプリケーションプロセッサ１３３１に供給されてアプリケーション等により利用される。

以上においてモジュールとして説明した構成をプロセッサとして実現するようにしてもよいし、逆にプロセッサとして説明した構成をモジュールとして実現するようにしてもよい。

以上のような構成のビデオセット１３００において、後述するようにビデオプロセッサ１３３２に本技術を適用することができる。したがって、ビデオセット１３００は、本技術を適用したセットとして実施することができる。

[ビデオプロセッサの構成例]
図４７は、本技術を適用したビデオプロセッサ１３３２（図４６）の概略的な構成の一例を示している。

図４７の例の場合、ビデオプロセッサ１３３２は、ビデオ信号およびオーディオ信号の入力を受けてこれらを所定の方式で符号化する機能と、符号化されたビデオデータおよびオーディオデータを復号し、ビデオ信号およびオーディオ信号を再生出力する機能とを有する。

図４７に示されるように、ビデオプロセッサ１３３２は、ビデオ入力処理部１４０１、第１画像拡大縮小部１４０２、第２画像拡大縮小部１４０３、ビデオ出力処理部１４０４、フレームメモリ１４０５、およびメモリ制御部１４０６を有する。また、ビデオプロセッサ１３３２は、エンコード・デコードエンジン１４０７、ビデオES（Elementary Stream）バッファ１４０８Ａおよび１４０８Ｂ、並びに、オーディオESバッファ１４０９Ａおよび１４０９Ｂを有する。さらに、ビデオプロセッサ１３３２は、オーディオエンコーダ１４１０、オーディオデコーダ１４１１、多重化部（MUX（Multiplexer））１４１２、逆多重化部（DMUX（Demultiplexer））１４１３、およびストリームバッファ１４１４を有する。

ビデオ入力処理部１４０１は、例えばコネクティビティ１３２１（図４６）等から入力されたビデオ信号を取得し、デジタル画像データに変換する。第１画像拡大縮小部１４０２は、画像データに対してフォーマット変換や画像の拡大縮小処理等を行う。第２画像拡大縮小部１４０３は、画像データに対して、ビデオ出力処理部１４０４を介して出力する先でのフォーマットに応じて画像の拡大縮小処理を行ったり、第１画像拡大縮小部１４０２と同様のフォーマット変換や画像の拡大縮小処理等を行ったりする。ビデオ出力処理部１４０４は、画像データに対して、フォーマット変換やアナログ信号への変換等を行って、再生されたビデオ信号として例えばコネクティビティ１３２１（図４６）等に出力する。

フレームメモリ１４０５は、ビデオ入力処理部１４０１、第１画像拡大縮小部１４０２、第２画像拡大縮小部１４０３、ビデオ出力処理部１４０４、およびエンコード・デコードエンジン１４０７によって共用される画像データ用のメモリである。フレームメモリ１４０５は、例えばDRAM等の半導体メモリとして実現される。

メモリ制御部１４０６は、エンコード・デコードエンジン１４０７からの同期信号を受けて、アクセス管理テーブル１４０６Ａに書き込まれたフレームメモリ１４０５へのアクセススケジュールに従ってフレームメモリ１４０５に対する書き込み・読み出しのアクセスを制御する。アクセス管理テーブル１４０６Ａは、エンコード・デコードエンジン１４０７、第１画像拡大縮小部１４０２、第２画像拡大縮小部１４０３等で実行される処理に応じて、メモリ制御部１４０６により更新される。

エンコード・デコードエンジン１４０７は、画像データのエンコード処理、並びに、画像データが符号化されたデータであるビデオストリームのデコード処理を行う。例えば、エンコード・デコードエンジン１４０７は、フレームメモリ１４０５から読み出した画像データを符号化し、ビデオストリームとしてビデオESバッファ１４０８Ａに順次書き込む。また、例えば、ビデオESバッファ１４０８Ｂからビデオストリームを順次読み出して復号し、画像データとしてフレームメモリ１４０５に順次書き込む。エンコード・デコードエンジン１４０７は、これらの符号化や復号において、フレームメモリ１４０５を作業領域として使用する。また、エンコード・デコードエンジン１４０７は、例えばマクロブロック毎の処理を開始するタイミングで、メモリ制御部１４０６に対して同期信号を出力する。

ビデオESバッファ１４０８Ａは、エンコード・デコードエンジン１４０７によって生成されたビデオストリームをバッファリングして、多重化部（MUX）１４１２に供給する。ビデオESバッファ１４０８Ｂは、逆多重化部（DMUX）１４１３から供給されたビデオストリームをバッファリングして、エンコード・デコードエンジン１４０７に供給する。

オーディオESバッファ１４０９Ａは、オーディオエンコーダ１４１０によって生成されたオーディオストリームをバッファリングして、多重化部（MUX）１４１２に供給する。オーディオESバッファ１４０９Ｂは、逆多重化部（DMUX）１４１３から供給されたオーディオストリームをバッファリングして、オーディオデコーダ１４１１に供給する。

オーディオエンコーダ１４１０は、例えばコネクティビティ１３２１（図４６）等から入力されたオーディオ信号を例えばデジタル変換し、例えばMPEGオーディオ方式やAC3（AudioCode number 3）方式等の所定の方式で符号化する。オーディオエンコーダ１４１０は、オーディオ信号が符号化されたデータであるオーディオストリームをオーディオESバッファ１４０９Ａに順次書き込む。オーディオデコーダ１４１１は、オーディオESバッファ１４０９Ｂから供給されたオーディオストリームを復号し、例えばアナログ信号への変換等を行って、再生されたオーディオ信号として例えばコネクティビティ１３２１（図４６）等に供給する。

多重化部（MUX）１４１２は、ビデオストリームとオーディオストリームとを多重化する。この多重化の方法（すなわち、多重化により生成されるビットストリームのフォーマット）は任意である。また、この多重化の際に、多重化部（MUX）１４１２は、所定のヘッダ情報等をビットストリームに付加することもできる。つまり、多重化部（MUX）１４１２は、多重化によりストリームのフォーマットを変換することができる。例えば、多重化部（MUX）１４１２は、ビデオストリームとオーディオストリームとを多重化することにより、転送用のフォーマットのビットストリームであるトランスポートストリームに変換する。また、例えば、多重化部（MUX）１４１２は、ビデオストリームとオーディオストリームとを多重化することにより、記録用のファイルフォーマットのデータ（ファイルデータ）に変換する。

逆多重化部（DMUX）１４１３は、多重化部（MUX）１４１２による多重化に対応する方法で、ビデオストリームとオーディオストリームとが多重化されたビットストリームを逆多重化する。つまり、逆多重化部（DMUX）１４１３は、ストリームバッファ１４１４から読み出されたビットストリームからビデオストリームとオーディオストリームとを抽出する（ビデオストリームとオーディオストリームとを分離する）。つまり、逆多重化部（DMUX）１４１３は、逆多重化によりストリームのフォーマットを変換（多重化部（MUX）１４１２による変換の逆変換）することができる。例えば、逆多重化部（DMUX）１４１３は、例えばコネクティビティ１３２１やブロードバンドモデム１３３３等（いずれも図４６）から供給されたトランスポートストリームを、ストリームバッファ１４１４を介して取得し、逆多重化することにより、ビデオストリームとオーディオストリームとに変換することができる。また、例えば、逆多重化部（DMUX）１４１３は、例えばコネクティビティ１３２１により（図４６）各種記録媒体から読み出されたファイルデータを、ストリームバッファ１４１４を介して取得し、逆多重化することにより、ビデオストリームとオーディオストリームとに変換することができる。

ストリームバッファ１４１４は、ビットストリームをバッファリングする。例えば、ストリームバッファ１４１４は、多重化部（MUX）１４１２から供給されたトランスポートストリームをバッファリングし、所定のタイミングにおいて、若しくは外部からの要求等に基づいて、例えばコネクティビティ１３２１やブロードバンドモデム１３３３（いずれも図４６）等に供給する。

また、例えば、ストリームバッファ１４１４は、多重化部（MUX）１４１２から供給されたファイルデータをバッファリングし、所定のタイミングにおいて、若しくは外部からの要求等に基づいて、例えばコネクティビティ１３２１（図４６）等に供給し、各種記録媒体に記録させる。

さらに、ストリームバッファ１４１４は、例えばコネクティビティ１３２１やブロードバンドモデム１３３３等（いずれも図４６）を介して取得したトランスポートストリームをバッファリングし、所定のタイミングにおいて、若しくは外部からの要求等に基づいて、逆多重化部（DMUX）１４１３に供給する。

また、ストリームバッファ１４１４は、例えばコネクティビティ１３２１（図４６）等において各種記録媒体から読み出されたファイルデータをバッファリングし、所定のタイミングにおいて、若しくは外部からの要求等に基づいて、逆多重化部（DMUX）１４１３に供給する。

次に、このような構成のビデオプロセッサ１３３２の動作の例について説明する。例えば、コネクティビティ１３２１（図４６）等からビデオプロセッサ１３３２に入力されたビデオ信号は、ビデオ入力処理部１４０１において４：２：２Ｙ／Ｃｂ／Ｃｒ方式等の所定の方式のデジタル画像データに変換され、フレームメモリ１４０５に順次書き込まれる。このデジタル画像データは、第１画像拡大縮小部１４０２または第２画像拡大縮小部１４０３に読み出されて、４：２：０Ｙ／Ｃｂ／Ｃｒ方式等の所定の方式へのフォーマット変換および拡大縮小処理が行われ、再びフレームメモリ１４０５に書き込まれる。この画像データは、エンコード・デコードエンジン１４０７によって符号化され、ビデオストリームとしてビデオESバッファ１４０８Ａに書き込まれる。

また、コネクティビティ１３２１（図４６）等からビデオプロセッサ１３３２に入力されたオーディオ信号は、オーディオエンコーダ１４１０によって符号化され、オーディオストリームとして、オーディオESバッファ１４０９Ａに書き込まれる。

ビデオESバッファ１４０８Ａのビデオストリームと、オーディオESバッファ１４０９Ａのオーディオストリームは、多重化部（MUX）１４１２に読み出されて多重化され、トランスポートストリーム若しくはファイルデータ等に変換される。多重化部（MUX）１４１２により生成されたトランスポートストリームは、ストリームバッファ１４１４にバッファされた後、例えばコネクティビティ１３２１やブロードバンドモデム１３３３（いずれも図４６）等を介して外部ネットワークに出力される。また、多重化部（MUX）１４１２により生成されたファイルデータは、ストリームバッファ１４１４にバッファされた後、例えばコネクティビティ１３２１（図４６）等に出力され、各種記録媒体に記録される。

また、例えばコネクティビティ１３２１やブロードバンドモデム１３３３（いずれも図４６）等を介して外部ネットワークからビデオプロセッサ１３３２に入力されたトランスポートストリームは、ストリームバッファ１４１４にバッファされた後、逆多重化部（DMUX）１４１３により逆多重化される。また、例えばコネクティビティ１３２１（図４６）等において各種記録媒体から読み出され、ビデオプロセッサ１３３２に入力されたファイルデータは、ストリームバッファ１４１４にバッファされた後、逆多重化部（DMUX）１４１３により逆多重化される。つまり、ビデオプロセッサ１３３２に入力されたトランスポートストリームまたはファイルデータは、逆多重化部（DMUX）１４１３によりビデオストリームとオーディオストリームとに分離される。

オーディオストリームは、オーディオESバッファ１４０９Ｂを介してオーディオデコーダ１４１１に供給され、復号されてオーディオ信号が再生される。また、ビデオストリームは、ビデオESバッファ１４０８Ｂに書き込まれた後、エンコード・デコードエンジン１４０７により順次読み出されて復号されてフレームメモリ１４０５に書き込まれる。復号された画像データは、第２画像拡大縮小部１４０３によって拡大縮小処理されて、フレームメモリ１４０５に書き込まれる。そして、復号された画像データは、ビデオ出力処理部１４０４に読み出されて、４：２：２Ｙ／Ｃｂ／Ｃｒ方式等の所定の方式にフォーマット変換され、さらにアナログ信号に変換されて、ビデオ信号が再生出力される。

このように構成されるビデオプロセッサ１３３２に本技術を適用する場合、エンコード・デコードエンジン１４０７に、上述した各実施形態に係る本技術を適用すればよい。つまり、例えば、エンコード・デコードエンジン１４０７が、第１の実施の形態に係るエンコーダ１およびファイル生成部２よりなる符号化装置（図１）やファイル読取部５１およびデコーダ５２よりなる復号装置（図８）の機能を有するようにすればよい。このようにすることにより、ビデオプロセッサ１３３２は、図１乃至図３６を参照して上述した効果と同様の効果を得ることができる。

なお、エンコード・デコードエンジン１４０７において、本技術（すなわち、上述した各実施形態に係る画像符号化装置や画像復号装置の機能）は、論理回路等のハードウエアにより実現するようにしてもよいし、組み込みプログラム等のソフトウエアにより実現するようにしてもよいし、それらの両方により実現するようにしてもよい。

[ビデオプロセッサの他の構成例]
図４８は、本技術を適用したビデオプロセッサ１３３２（図４６）の概略的な構成の他の例を示している。図４８の例の場合、ビデオプロセッサ１３３２は、ビデオデータを所定の方式で符号化・復号する機能とを有する。

より具体的には、図４８に示されるように、ビデオプロセッサ１３３２は、制御部１５１１、ディスプレイインタフェース１５１２、ディスプレイエンジン１５１３、画像処理エンジン１５１４、および内部メモリ１５１５を有する。また、ビデオプロセッサ１３３２は、コーデックエンジン１５１６、メモリインタフェース１５１７、多重化・逆多重化部（MUX DMUX）１５１８、ネットワークインタフェース１５１９、およびビデオインタフェース１５２０を有する。

制御部１５１１は、ディスプレイインタフェース１５１２、ディスプレイエンジン１５１３、画像処理エンジン１５１４、およびコーデックエンジン１５１６等、ビデオプロセッサ１３３２内の各処理部の動作を制御する。

図４８に示されるように、制御部１５１１は、例えば、メインCPU１５３１、サブCPU１５３２、およびシステムコントローラ１５３３を有する。メインCPU１５３１は、ビデオプロセッサ１３３２内の各処理部の動作を制御するためのプログラム等を実行する。メインCPU１５３１は、そのプログラム等に従って制御信号を生成し、各処理部に供給する（つまり、各処理部の動作を制御する）。サブCPU１５３２は、メインCPU１５３１の補助的な役割を果たす。例えば、サブCPU１５３２は、メインCPU１５３１が実行するプログラム等の子プロセスやサブルーチン等を実行する。システムコントローラ１５３３は、メインCPU１５３１およびサブCPU１５３２が実行するプログラムを指定する等、メインCPU１５３１およびサブCPU１５３２の動作を制御する。

ディスプレイインタフェース１５１２は、制御部１５１１の制御の下、画像データを例えばコネクティビティ１３２１（図４６）等に出力する。例えば、ディスプレイインタフェース１５１２は、デジタルデータの画像データをアナログ信号に変換し、再生されたビデオ信号として、またはデジタルデータの画像データのまま、コネクティビティ１３２１（図４６）のモニタ装置等に出力する。

ディスプレイエンジン１５１３は、制御部１５１１の制御の下、画像データに対して、その画像を表示させるモニタ装置等のハードウエアスペックに合わせるように、フォーマット変換、サイズ変換、色域変換等の各種変換処理を行う。

画像処理エンジン１５１４は、制御部１５１１の制御の下、画像データに対して、例えば画質改善のためのフィルタ処理等、所定の画像処理を施す。

内部メモリ１５１５は、ディスプレイエンジン１５１３、画像処理エンジン１５１４、およびコーデックエンジン１５１６により共用される、ビデオプロセッサ１３３２の内部に設けられたメモリである。内部メモリ１５１５は、例えば、ディスプレイエンジン１５１３、画像処理エンジン１５１４、およびコーデックエンジン１５１６の間で行われるデータの授受に利用される。例えば、内部メモリ１５１５は、ディスプレイエンジン１５１３、画像処理エンジン１５１４、またはコーデックエンジン１５１６から供給されるデータを格納し、必要に応じて（例えば、要求に応じて）、そのデータを、ディスプレイエンジン１５１３、画像処理エンジン１５１４、またはコーデックエンジン１５１６に供給する。この内部メモリ１５１５は、どのような記憶デバイスにより実現するようにしてもよいが、一般的にブロック単位の画像データやパラメータ等といった小容量のデータの格納に利用することが多いので、例えばSRAM（Static Random Access Memory）のような比較的（例えば外部メモリ１３１２と比較して）小容量だが応答速度が高速な半導体メモリにより実現するのが望ましい。

コーデックエンジン１５１６は、画像データの符号化や復号に関する処理を行う。このコーデックエンジン１５１６が対応する符号化・復号の方式は任意であり、その数は１つであってもよいし、複数であってもよい。例えば、コーデックエンジン１５１６は、複数の符号化・復号方式のコーデック機能を備え、その中から選択されたもので画像データの符号化若しくは符号化データの復号を行うようにしてもよい。

図４８に示される例において、コーデックエンジン１５１６は、コーデックに関する処理の機能ブロックとして、例えば、MPEG-2 Video１５４１、AVC/H.264１５４２、HEVC/H.265１５４３、HEVC/H.265(Scalable)１５４４、HEVC/H.265(Multi-view)１５４５、およびMPEG-DASH１５５１を有する。

MPEG-2 Video１５４１は、画像データをMPEG-2方式で符号化したり復号したりする機能ブロックである。AVC/H.264１５４２は、画像データをAVC方式で符号化したり復号したりする機能ブロックである。HEVC/H.265１５４３は、画像データをHEVC方式で符号化したり復号したりする機能ブロックである。HEVC/H.265(Scalable)１５４４は、画像データをHEVC方式でスケーラブル符号化したりスケーラブル復号したりする機能ブロックである。HEVC/H.265(Multi-view)１５４５は、画像データをHEVC方式で多視点符号化したり多視点復号したりする機能ブロックである。

MPEG-DASH１５５１は、画像データをMPEG-DASH（MPEG-Dynamic Adaptive Streaming over HTTP）方式で送受信する機能ブロックである。MPEG-DASHは、HTTP（HyperText Transfer Protocol）を使ってビデオのストリーミングを行う技術であり、予め用意された解像度等が互いに異なる複数の符号化データの中から適切なものをセグメント単位で選択し伝送することを特徴の１つとする。MPEG-DASH１５５１は、規格に準拠するストリームの生成やそのストリームの伝送制御等を行い、画像データの符号化・復号については、上述したMPEG-2 Video１５４１乃至HEVC/H.265(Multi-view)１５４５を利用する。

メモリインタフェース１５１７は、外部メモリ１３１２用のインタフェースである。画像処理エンジン１５１４やコーデックエンジン１５１６から供給されるデータは、メモリインタフェース１５１７を介して外部メモリ１３１２に供給される。また、外部メモリ１３１２から読み出されたデータは、メモリインタフェース１５１７を介してビデオプロセッサ１３３２（画像処理エンジン１５１４若しくはコーデックエンジン１５１６）に供給される。

多重化・逆多重化部（MUX DMUX）１５１８は、符号化データのビットストリーム、画像データ、ビデオ信号等、画像に関する各種データの多重化や逆多重化を行う。この多重化・逆多重化の方法は任意である。例えば、多重化の際に、多重化・逆多重化部（MUX DMUX）１５１８は、複数のデータを１つにまとめるだけでなく、所定のヘッダ情報等をそのデータに付加することもできる。また、逆多重化の際に、多重化・逆多重化部（MUX DMUX）１５１８は、１つのデータを複数に分割するだけでなく、分割した各データに所定のヘッダ情報等を付加することもできる。つまり、多重化・逆多重化部（MUX DMUX）１５１８は、多重化・逆多重化によりデータのフォーマットを変換することができる。例えば、多重化・逆多重化部（MUX DMUX）１５１８は、ビットストリームを多重化することにより、転送用のフォーマットのビットストリームであるトランスポートストリームや、記録用のファイルフォーマットのデータ（ファイルデータ）に変換することができる。もちろん、逆多重化によりその逆変換も可能である。

ネットワークインタフェース１５１９は、例えばブロードバンドモデム１３３３やコネクティビティ１３２１（いずれも図４６）等向けのインタフェースである。ビデオインタフェース１５２０は、例えばコネクティビティ１３２１やカメラ１３２２（いずれも図４６）等向けのインタフェースである。

次に、このようなビデオプロセッサ１３３２の動作の例について説明する。例えば、例えばコネクティビティ１３２１やブロードバンドモデム１３３３（いずれも図４６）等を介して外部ネットワークからトランスポートストリームを受信すると、そのトランスポートストリームは、ネットワークインタフェース１５１９を介して多重化・逆多重化部（MUX DMUX）１５１８に供給されて逆多重化され、コーデックエンジン１５１６により復号される。コーデックエンジン１５１６の復号により得られた画像データは、例えば、画像処理エンジン１５１４により所定の画像処理が施され、ディスプレイエンジン１５１３により所定の変換が行われ、ディスプレイインタフェース１５１２を介して例えばコネクティビティ１３２１（図４６）等に供給され、その画像がモニタに表示される。また、例えば、コーデックエンジン１５１６の復号により得られた画像データは、コーデックエンジン１５１６により再符号化され、多重化・逆多重化部（MUX DMUX）１５１８により多重化されてファイルデータに変換され、ビデオインタフェース１５２０を介して例えばコネクティビティ１３２１（図４６）等に出力され、各種記録媒体に記録される。

さらに、例えば、コネクティビティ１３２１（図４６）等により図示せぬ記録媒体から読み出された、画像データが符号化された符号化データのファイルデータは、ビデオインタフェース１５２０を介して多重化・逆多重化部（MUX DMUX）１５１８に供給されて逆多重化され、コーデックエンジン１５１６により復号される。コーデックエンジン１５１６の復号により得られた画像データは、画像処理エンジン１５１４により所定の画像処理が施され、ディスプレイエンジン１５１３により所定の変換が行われ、ディスプレイインタフェース１５１２を介して例えばコネクティビティ１３２１（図４６）等に供給され、その画像がモニタに表示される。また、例えば、コーデックエンジン１５１６の復号により得られた画像データは、コーデックエンジン１５１６により再符号化され、多重化・逆多重化部（MUX DMUX）１５１８により多重化されてトランスポートストリームに変換され、ネットワークインタフェース１５１９を介して例えばコネクティビティ１３２１やブロードバンドモデム１３３３（いずれも図４６）等に供給され図示せぬ他の装置に伝送される。

なお、ビデオプロセッサ１３３２内の各処理部の間での画像データやその他のデータの授受は、例えば、内部メモリ１５１５や外部メモリ１３１２を利用して行われる。また、パワーマネージメントモジュール１３１３は、例えば制御部１５１１への電力供給を制御する。

このように構成されるビデオプロセッサ１３３２に本技術を適用する場合、コーデックエンジン１５１６に、上述した各実施形態に係る本技術を適用すればよい。つまり、例えば、コーデックエンジン１５１６が、第１の実施の形態に係るエンコーダ１およびファイル生成部２よりなる符号化装置(図１)やファイル読取部５１およびデコーダ５２よりなる復号装置（図８）を実現する機能ブロックを有するようにすればよい。このようにすることにより、ビデオプロセッサ１３３２は、図１乃至図３６を参照して上述した効果と同様の効果を得ることができる。

なお、コーデックエンジン１５１６において、本技術（すなわち、上述した各実施形態に係る画像符号化装置や画像復号装置の機能）は、論理回路等のハードウエアにより実現するようにしてもよいし、組み込みプログラム等のソフトウエアにより実現するようにしてもよいし、それらの両方により実現するようにしてもよい。

以上にビデオプロセッサ１３３２の構成を２例示したが、ビデオプロセッサ１３３２の構成は任意であり、上述した２例以外のものであってもよい。また、このビデオプロセッサ１３３２は、１つの半導体チップとして構成されるようにしてもよいが、複数の半導体チップとして構成されるようにしてもよい。例えば、複数の半導体を積層する３次元積層LSIとしてもよい。また、複数のLSIにより実現されるようにしてもよい。

[装置への適用例]
ビデオセット１３００は、画像データを処理する各種装置に組み込むことができる。例えば、ビデオセット１３００は、テレビジョン装置９００（図４２）、携帯電話機９２０（図４３）、記録再生装置９４０（図４４）、撮像装置９６０（図４５）等に組み込むことができる。ビデオセット１３００を組み込むことにより、その装置は、図１乃至図３６を参照して上述した効果と同様の効果を得ることができる。

なお、上述したビデオセット１３００の各構成の一部であっても、ビデオプロセッサ１３３２を含むものであれば、本技術を適用した構成として実施することができる。例えば、ビデオプロセッサ１３３２のみを本技術を適用したビデオプロセッサとして実施することができる。また、例えば、上述したように点線１３４１により示されるプロセッサやビデオモジュール１３１１等を、本技術を適用したプロセッサやモジュール等として実施することができる。さらに、例えば、ビデオモジュール１３１１、外部メモリ１３１２、パワーマネージメントモジュール１３１３、およびフロントエンドモジュール１３１４を組み合わせ、本技術を適用したビデオユニット１３６１として実施することもできる。いずれの構成の場合であっても、図１乃至図３６を参照して上述した効果と同様の効果を得ることができる。

つまり、ビデオプロセッサ１３３２を含むものであればどのような構成であっても、ビデオセット１３００の場合と同様に、画像データを処理する各種装置に組み込むことができる。例えば、ビデオプロセッサ１３３２、点線１３４１により示されるプロセッサ、ビデオモジュール１３１１、または、ビデオユニット１３６１を、テレビジョン装置９００（図４２）、携帯電話機９２０（図４３）、記録再生装置９４０（図４４）、撮像装置９６０（図４５）等に組み込むことができる。そして、本技術を適用したいずれかの構成を組み込むことにより、その装置は、ビデオセット１３００の場合と同様に、図１乃至図３６を参照して上述した効果と同様の効果を得ることができる。

なお、本明細書では、startcodeとfiller data、デコーダバッファを管理するパラメータ、識別パラメータ、FixedStartCodeSizeFlag等の各種情報が、符号化ストリームに多重化されて、符号化側から復号側へ伝送される例について説明した。しかしながら、これら情報を伝送する手法はかかる例に限定されない。例えば、これら情報は、符号化ビットストリームに多重化されることなく、符号化ビットストリームと関連付けられた別個のデータとして伝送され又は記録されてもよい。ここで、「関連付ける」という用語は、ビットストリームに含まれる画像（スライス若しくはブロックなど、画像の一部であってもよい）と当該画像に対応する情報とを復号時にリンクさせ得るようにすることを意味する。即ち、情報は、画像（又はビットストリーム）とは別の伝送路上で伝送されてもよい。また、情報は、画像（又はビットストリーム）とは別の記録媒体（又は同一の記録媒体の別の記録エリア）に記録されてもよい。さらに、情報と画像（又はビットストリーム）とは、例えば、複数フレーム、１フレーム、又はフレーム内の一部分などの任意の単位で互いに関連付けられてよい。

以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示はかかる例に限定されない。本開示の属する技術の分野における通常の知識を有する者であれば、請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。

１ エンコーダ， ２ ファイル生成部， ３１ 制御部， ３２ 設定部， ３３ ファイル書き出し部， ５１ ファイル読取部， ５２ デコーダ， ７１ ファイル受け取り部， ７２ パラメータ取得部， ７３ 復号制御部， ７４ データ読み出し部， ２０１ 画像符号化装置， ２５１ 画像復号装置， ３００ ファイル変換装置， ３１１ ビデオストリーム解析部， ４０１ エンコーダ， ４５１ デコーダ

Claims (8)

1. 画像を符号化したビットストリームを含むファイルのmedia dataを対象として、filler dataを設定する設定部と、
   前記filler dataの設定により、前記media data において、HRD(Hypothetical Reference Decoder)パラメータの特性を保持してファイルを構成するように、前記設定部を制御する制御部と
   を備える画像処理装置。
2. 前記HRD(Hypothetical Reference Decoder)パラメータは、VUI(Video Usability Information)に含まれるパラメータ、またはbuffering period SEI（Supplemental Enhancement Information）に含まれるパラメータ、または、picture timing SEIに含まれるパラメータである
   請求項１に記載の画像処理装置。
3. 前記設定部は、filler dataを、VCLデータとして設定する
   請求項１に記載の画像処理装置。
4. 画像処理装置が、
   画像を符号化したビットストリームを含むファイルのmedia dataを対象として、filler dataを設定し、
   前記filler dataの設定により、前記media data において、HRD(Hypothetical Reference Decoder)パラメータの特性を保持してファイルを構成するように、前記filler dataの設定を制御する
   画像処理方法。
5. 画像を符号化したビットストリームを含むファイルのmedia dataにおいて設定されていたfiller dataがビットストリームから削除された場合に、前記filler dataの設定により保持されていたHRD(Hypothetical Reference Decoder)パラメータの特性を設定する設定部と、
   前記設定部により設定された特性を用いて、前記ファイルを生成する生成部と
   を備える画像処理装置。
6. 前記設定部は、前記HRD(Hypothetical Reference Decoder)パラメータの特性が変更されたことを識別する識別パラメータを設定する
   請求項５に記載の画像処理装置。
7. 前記設定部は、前記識別パラメータを、前記ファイルのサンプルエントリにおけるオプショナルボックスとして設定する
   請求項６に記載の画像処理装置。
8. 画像処理装置が、
   画像を符号化したビットストリームを含むファイルのmedia dataにおいて設定されていたfiller dataがビットストリームから削除された場合に、前記filler dataの設定により保持されていたHRD(Hypothetical Reference Decoder)パラメータの特性を設定し、
   設定された特性を用いて、前記ファイルを生成する
   画像処理方法。

Images