JP3584460B2 - ビットストリーム変換装置および方法、並びに提供媒体 - Google Patents
ビットストリーム変換装置および方法、並びに提供媒体 Download PDFInfo
- Publication number
- JP3584460B2 JP3584460B2 JP02937699A JP2937699A JP3584460B2 JP 3584460 B2 JP3584460 B2 JP 3584460B2 JP 02937699 A JP02937699 A JP 02937699A JP 2937699 A JP2937699 A JP 2937699A JP 3584460 B2 JP3584460 B2 JP 3584460B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- stream
- elementary stream
- picture
- elementary
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Compression Or Coding Systems Of Tv Signals (AREA)
- Time-Division Multiplex Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、ビットストリーム変換装置および方法、並びに提供媒体に関し、特に、より効率的にデジタル信号を送受信することができるようにした、ビットストリーム変換装置および方法、並びに提供媒体に関する。
【０００２】
【従来の技術】
画像信号または音声信号を符号化して伝送する場合、ＩＳＯ／ＩＥＣ１１１７２（ＭＰＥＧ−１）もしくはＩＳＯ／ＩＥＣ１３８１８（ＭＰＥＧ−２）に示されている符号化方式が用いられることが多い。画像信号を、ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）方式で符号化する場合の技術として、コーディングフェーズ（ｃｏｄｉｎｇ ｐｈａｓｅ）と両方向予測があげられる。
【０００３】
ｃｏｄｉｎｇ ｐｈａｓｅとは、図１に示すように、１枚の画像の画素エリア１のうち、符号化が行われる範囲としての有効画素エリア２を規定するためのコードであり、具体的には、全てのラインのうち、有効画素エリア２の最初のライン（図１のＶ−ｐｈａｓｅ［ｌｉｎｅ］の矢印で示されたライン）、および、全てのサンプル（画素）のうち、有効画素エリア２の最初のラインの最初のサンプル（図１のＨ−ｐｈａｓｅ［ｓａｍｐｌｅ］の矢印で示されたサンプル（画素））を示すものである。画素エリア１の最後のラインを、Ｖ−Ｐｈａｓｅ［Ｌｍａｘ］とし、画素エリア１のラインの最後のサンプル（画素）を、Ｈ−Ｐｈａｓｅ［Ｓｍａｘ］とするとき、符号化は、例えば、垂直方向に、Ｖ−Ｐｈａｓｅ［ｌｉｎｅ］から、（Ｖ−Ｐｈａｓｅ［Ｌｍａｘ］ − Ｖ−Ｐｈａｓｅ［ｌｉｎｅ］＋１）までの範囲で行われ、水平方向に、Ｈ−Ｐｈａｓｅ［ｓａｍｐｌｅ］から、（Ｈ−Ｐｈａｓｅ［Ｓｍａｘ］−Ｈ − Ｐｈａｓｅ［ｓａｍｐｌｅ］＋１）までの範囲で行われる。
【０００４】
また、一般の例えば、ＮＴＳＣ方式のテレビジョン受像機などの画像信号において、図１の画像信号のフレームは、図２に示すように、２枚のフィールド（図２のフィールド１およびフィールド２）から構成されている。フィールド１には、例えば、奇数ラインのデータが表示され、フィールド２には偶数ラインのデータが表示される。２枚のフィールドは、それぞれ、補助データ（ａｎｃｉｌｌａｒｙ ｄａｔａ）と、画像（イメージ）データ（ｉｍａｇｅ ｄａｔａ）から構成されている。
【０００５】
補助データは、耳の不自由な人のための文字放送用のテレテキストデータ、タイムコード、または映画などの字幕のクローズドキャプションデータに利用され、ブランキング区間（例えば、各フィールドの第１０ライン乃至第２２ライン）（図２においては、いずれのフィールドも、そのフィールド内の上から順番の番号でラインが表されている）のうちの所定のラインに挿入されている。一般に、各フィールドの第２３ラインより図中下に位置するラインの部分（実際に、画像として表示される部分）は、画像データとして、ＭＰＥＧ方式などにより符号化される。
【０００６】
前述したＭＰＥＧ符号化方式は、画像データにのみ適用され、ｃｏｄｉｎｇ ｐｈａｓｅ、および補助データについては、ＭＰＥＧの規格には、特に明確に記述（規定）されていない。そのため、ｃｏｄｉｎｇ ｐｈａｓｅは、自由度を有し、様々なアプリケーションによって異なっている。
【０００７】
このような画像信号を、符号化または復号するときのシステム構成を、図３を参照して説明する。アプリケーションＡの画像データは、アプリケーションＡ用ＭＰＥＧエンコーダ１１で符号化され、エレメンタリストリーム（ＥＳ）として出力され、アプリケーションＡ用ＭＰＥＧデコーダ１２で復号される。アプリケーションＢの画像データは、アプリケーションＢ用ＭＰＥＧエンコーダ１３で符号化され、エレメンタリストリーム（ＥＳ）として出力され、アプリケーションＢ用ＭＰＥＧデコーダ１４で復号される。
【０００８】
つまり、あるアプリケーションの画像データは、そのアプリケーション専用のエンコーダ（例えば、アプリケーションＡ用ＭＰＥＧエンコーダ１１）で符号化され、エレメンタリストリーム（ＥＳ）として、そのアプリケーションに対応した専用のデコーダ（例えば、アプリケーションＡ用ＭＰＥＧデコーダ１２）に出力される。専用デコーダに入力されたエレメンタリストリーム（ＥＳ）は、そのデコーダが有している、そのアプリケーションのｃｏｄｉｎｇ ｐｈａｓｅに関する情報に基づき、復号される。
【０００９】
次に、現在主流となっている補助データの伝送方式について、図４を参照して説明する。画像信号は、ＭＰＥＧエンコーダ２１に入力され、分離部２１において、画像データと補助データに分離される。ＭＰＥＧエンコード部２３は、画像データをＭＰＥＧ符号化する。補助データは、可変長符号化部２４で、ＭＰＥＧエンコード部２３より出力されたＭＰＥＧ方式のトランスポートストリーム中のｕｓｅｒ ｄａｔａに挿入される。このトランスポートストリーム中のｕｓｅｒ ｄａｔａは、符号化された画像データ（ピクチャ）単位に挿入（記述）できるため、補助データは、対応する各符号化画像データのフレームのｕｓｅｒ ｄａｔａごとに挿入される。
【００１０】
補助データが挿入されたｕｓｅｒ ｄａｔａを含むトランスポートストリームは、所定の伝送路を介して伝送され、ＭＰＥＧデコーダ２５に入力される。ＭＰＥＧデコーダ２５内の可変長復号部２６は、補助データと画像データとを分離する。画像データはＭＰＥＧデコード部２７で復号され、合成部２８で補助データと合成されて、画像信号として、図示せぬ表示装置に出力される。
【００１１】
次に、ＭＰＥＧ方式の予測について説明する。両方向予測に基づいて生成された符号化画像データのピクチャはＢピクチャと称される。Ｂピクチャは、時間的に前または後に位置する２枚の参照画像データから予測されて生成される。前方予測に基づいて生成された符号化画像データのピクチャはＰピクチャと称される。Ｐピクチャは、時間的に前に位置する１枚の参照画像データから予測されて生成される。予測が行われず、そのまま画像データが符号化（イントラ符号化）された符号化画像データのピクチャはＩピクチャと称される。つまり、入力された画像データは、Ｂピクチャ、Ｐピクチャ、またはＩピクチャのいずれかの符号化画像データに符号化される。
【００１２】
両方向予測および前方予測について、図５を参照して説明する。図５の例では、１つのＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅ）が、９枚のピクチャから構成されている。図５の上段は、符号化画像データが生成されるときの、予測の方向（依存関係）を示す予測構造を表しており、図５の下段は、実際に画像データが符号化される順序を示す符号化構造を表している。Ｂピクチャ、またはＰピクチャは、時間的に前または後の画像データから予測されて生成されるために、Ｂピクチャ、またはＰピクチャだけでは、符号化を行うことはできない。すなわち、Ｂピクチャ、またはＰピクチャは、参照画像データとの差分をデータとする符号化画像データであるので、Ｂピクチャ、またはＰピクチャだけでは、画像データを復号することもできない。
【００１３】
予測の依存関係について詳細に説明すると、例えば、ＧＯＰ（Ｎ−１）において、表示順序が先頭のＢピクチャは、先頭から３番目のＩピクチャと、図示されていないＧＯＰ（Ｎ−２）（ＧＯＰ（Ｎ−１）の直前のＧＯＰ）の最後のＰピクチャから予測されて符号化される。先頭から２番目のＢピクチャも同様に、先頭から３番目のＩピクチャと、図示されていないＧＯＰ（Ｎ−２）の最後のＰピクチャから予測されて符号化される。先頭から３番目のＩピクチャは、そのまま符号化（イントラ符号化）される。先頭から４番目、および５番目のＢピクチャは、先頭から３番目のＩピクチャと先頭から６番目のＰピクチャから予測されて符号化される。先頭から６番目のＰピクチャは、先頭から３番目のＩピクチャから予測されて符号化される。
【００１４】
つまり、予測構造において、Ｂピクチャ（例えば、先頭のＢピクチャと先頭から２番目のＢピクチャ）が符号化されるには、予測の参照画像データ（例えば、３番目のＩピクチャとＧＯＰ（Ｎ−２）の最後のＰピクチャ）が、先に符号化されている必要がある。すなわち、図５の下段に示すような、符号化構造の順番で符号化されなければならない。そのため、ＭＰＥＧエンコーダは、符号化（エンコード）時、ＩピクチャとＰピクチャの間に存在する、２枚の連続したＢピクチャを符号化するために必要な参照画像データ（先頭から３番目のＩピクチャ）が入力されるまで、２枚のＢピクチャをバッファリングする（Ｉピクチャが入力されるまで、符号化の開始を遅延させる）必要がある。このバッファリングにより、ＭＰＥＧエンコーダにおいて、入力された画像信号を符号化するとき、参照画像データに挟まれたＢピクチャの枚数（＝２）＋１枚（合計３枚）の遅延時間が発生する。
【００１５】
このＭＰＥＧエンコーダにおいて発生する遅延について、図６を参照して、さらに詳細に説明する。図６の上段はＭＰＥＧエンコーダ３１における、入力画像（画像データ）の入力順番（表示順序）とその種別を表しており、図６の中段は、入力画像（画像データ）が符号化された符号化画像データの順番を表している。
【００１６】
ＭＰＥＧエンコーダ３１は、時刻ｔ４のＰピクチャが入力されるまで（Ｂピクチャの枚数（＝２）＋１枚分の時間だけ）、時刻ｔ１に入力されたＩピクチャの符号化を遅延させる（前述のバッファリングを行う）。すなわち、ＭＰＥＧエンコーダ３１は、時刻ｔ４で時刻ｔ１に入力されたＩピクチャを符号化し、時刻ｔ５で時刻ｔ４に入力されたＰピクチャを符号化し、時刻ｔ６で時刻ｔ２に入力されたＢピクチャを符号化し、時刻ｔ７で時刻ｔ３に入力されたＢピクチャを符号化する。その後、ＭＰＥＧエンコーダ３１は、入力画像を図６の中段の符号化画像データの順番で、順次、符号化する。
【００１７】
このように、ＭＰＥＧエンコーダ３１は、入力画像に対して、予測に必要な参照画像データから順次符号化する。つまり、ＭＰＥＧエンコーダ３１において、入力画像（画像データ）は、入力画像の順番から、符号化される画像の順番に並べ変えられ、図６の中段に示すように、入力画像が符号化された順番にビットストリームとして、ＭＰＥＧデコーダ３２に出力される。
【００１８】
このように、入力画像が符号化される順番と表示される順番は一致しないので、ＭＰＥＧにおいては、符号化順序を表すＤＴＳ（Ｄｅｃｏｄｉｎｇ Ｔｉｍｅ Ｓｔａｍｐ）と、表示順序を表すＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ Ｓｔａｍｐ）が、トランスポートストリーム中に挿入されるようになされている。入力画像の符号化順序と表示順序の関係をさらに説明すると、いま、符号化順序をフレーム単位で表すものとすると、図６に示すように、入力画像は符号化される順番で付番され、時刻ｔ４で符号化されたＩピクチャの符号化順序の値は”１”となり、時刻ｔ５で符号化されたＰピクチャの符号化順序の値は”２”となり、時刻ｔ６で符号化されたＢピクチャの符号化順序の値は”３”となる。以下、同様に符号化される順番に符号化順序が付番される。ＤＴＳはフレーム単位で符号化順序を表しているわけではないが、ほぼ、この符号化順序に対応する。ＤＴＳはまた、ビットストリームを音声信号などと多重化して出力するとき、ＭＰＥＧデコーダ３２において、復号する順番として使用される。
【００１９】
表示順序は、画像データが復号されて表示される順番（入力画像データの順番と同じ）となる。具体的には、時刻ｔ４で符号化されるＩピクチャ（符号化順序＝１）の表示順序は、時刻ｔ５でＰピクチャ（符号化順序＝２）が符号化されるときに表示されなければならないので、そのＰピクチャの符号化順序と同じ値”２”となる。時刻ｔ５で符号化されるＰピクチャ（符号化順序＝２）の表示順序は、時刻ｔ８でＰピクチャ（符号化順序＝５）が符号化されるとき表示されなければならないので、そのＰピクチャの符号化順序と同じ値”５”となる。時刻ｔ６で符号化されるＢピクチャ（符号化順序＝３）は、符号化されると、直ちに復号されて表示されなければならないので、符号化順序と表示順序は同一となり、表示順序の値は”３”となる。時刻ｔ７で符号化されるＢピクチャ（符号化順序＝４）も同様に、表示順序＝符号化順序＝４となる。ＰＴＳはフレーム単位で表示順序を表しているわけではないが、ほぼ、この表示順序に対応する。ＰＴＳはまた、ＭＰＥＧデコーダ３２において、復号後、出力（表示）する順番として使用される。
【００２０】
ＭＰＥＧデコーダ３２では、符号化順序が連続する２枚のＩピクチャもしくはＰピクチャのうち、最初の１枚目は、２枚目が復号されるとき、表示される。例えば、ＭＰＥＧエンコーダ３１が出力したビットストリーム中の符号化画像データの１枚目のＩピクチャ（符号化順序＝１，表示順序＝２）と、２枚目のＰピクチャ（符号化順序＝２，表示順序＝５）は、符号化順序が連続しており、２枚目のＰピクチャが符号化されるとき（時刻ｔ５のとき）、１枚目のＩピクチャが復号されて表示される。
【００２１】
このように、ＭＰＥＧエンコーダ３１は、入力画像（画像データ）の予測構造（参照画像データに挟まれているＢピクチャの枚数）を知っているので、画像データに符号化順序（ＤＴＳ）と表示順序（ＰＴＳ）を付番することができる。
【００２２】
放送局などのスタジオ内で、図７に示すシステム構成で、ＭＰＥＧ符号化されたビットストリームを伝送することが考えられている。スタジオ４１内のＭＰＥＧエンコーダ４２、ＭＰＥＧエンコーダ４３、ＭＰＥＧデコーダ４４、およびＭＰＥＧデコーダ４５は、それぞれ、ＳＤＴＩ−ＣＰ（Ｓｅｒｉａｌ Ｄａｔａ Ｔｒａｎｓｆｅｒ Ｉｎｔｅｒｆａｃｅ − Ｃｏｎｔｅｎｔ Ｐａｃｋａｇｅ）インタフェース４６乃至４９を介して、ＳＤＴＩ−ＣＰネットワーク（例えば、同軸ケーブルにより構成されるネットワーク）５０に接続される。ＳＤＴＩ−ＣＰネットワーク５０は、ＳＤＩ（Ｓｅｒｉａｌ Ｄａｔａ Ｉｎｔｅｒｆａｃｅ）をベースとした２７０Ｍｂｐｓの伝送速度を有し、ＭＰＥＧ方式のエレメンタリストリーム（ＥＳ）をそのまま伝送することが可能であり、スタジオ内のような閉じたネットワークに適している。
【００２３】
スタジオ４１において、例えば、ＭＰＥＧエンコーダ４２は、ＭＰＥＧ符号化されたエレメンタリストリーム（ＥＳ）を、ＳＤＴＩ−ＣＰネットワーク５０を介して、ＭＰＥＧデコーダ４４、ＭＰＥＧデコーダ４５に伝送することができる。
【００２４】
このＳＤＴＩ−ＣＰネットワーク５０で伝送されるエレメンタリストリーム（ＥＳ）は、図８に示す構造となっており、画像信号のフレーム単位で、画像データ（図８において薄い影を付けた部分）と音声データ（図８において濃い影を付けた部分）がパッキングされており、フレームシンク（図８の点線）により区切られたフレーム境界で、簡単に編集を行うことができる。このエレメンタリストリーム（ＥＳ）における画像データと音声データは、イントラ（フレーム内符号化）処理されたデータである。
【００２５】
図７に示すスタジオ４１のシステムは、そのＭＰＥＧエンコーダ４２，４３とＭＰＥＧデコーダ４４，４５が、ＳＤＴＩ−ＣＰインタフェース４６乃至４９を介して、ＳＤＴＩ−ＣＰネットワーク５０に接続されており、図３に示したような、アプリケーションごとに専用のエンコーダ（例えば、アプリケーションＡ用ＭＰＥＧエンコーダ１１）とデコーダ（例えば、アプリケーションＡ用ＭＰＥＧデコーダ１２）が１対１に対応するシステムとは構成が異なっている。すなわち、デコーダ（例えば、図７のＭＰＥＧデコーダ４４）は、エンコーダ（例えば、図７のＭＰＥＧエンコーダ４２またはＭＰＥＧエンコーダ４３）で、様々なアプリケーションの画像信号が符号化された、エレメンタリストリーム（ＥＳ）を受け取ることができる。
【００２６】
図７のシステム構成を、図３のシステム構成に対応させた図９を参照して説明すると、アプリケーションＡ用ＭＰＥＧエンコーダ４２で符号化されたエレメンタリストリーム（ＥＳ）と、アプリケーションＢ用ＭＰＥＧエンコーダ４３で符号化されたエレメンタリストリーム（ＥＳ）は、それぞれＳＤＴＩ−ＣＰインタフェース４６，４７に入力される。ＳＤＴＩ−ＣＰインタフェース４６，４７は、それぞれＭＰＥＧ符号化されたエレメンタリストリーム（ＥＳ）を、ＳＤＴＩフォーマットのエレメンタリストリーム（ＥＳ）に変換して、ＳＤＴＩ−ＣＰネットワーク５０を介して伝送する。ＳＤＴＩ−ＣＰインタフェース４８は、ＳＤＴＩフォーマットのエレメンタリストリーム（ＥＳ）を、ＭＰＥＧ符号化されたエレメンタリストリーム（ＥＳ）に変換し、ＭＰＥＧデコーダ４４に出力する。
【００２７】
ＭＰＥＧデコーダ４４は、それぞれ入力されたアプリケーションＡ用のエレメンタリストリーム（ＥＳ）とアプリケーションＢ用のエレメンタリストリーム（ＥＳ）を復号する。
【００２８】
ところで、補助データがトランスポートストリーム中のｕｓｅｒ ｄａｔａに挿入される場合、補助データは、対応する符号化画像のフレーム単位で挿入されるため、その挿入は１フレーム（２フィールド）ごととなる。
【００２９】
符号化される信号が、３−２プルダウン処理（例えば、２４Ｈｚのフレームレートを持つ映画の画像信号を、３０Ｈｚのフレームレートを持つＮＴＳＣ方式の画像信号に変換する処理）された信号である場合、その信号は、図１０に示すように、２４Ｈｚの各フレームを、交互に、リピートフィールドが作成されていない２フィールドのフレーム、またはリピートフィールドが作成されている３フィールドのフレームとすることで、３０Ｈｚの信号とされている。
【００３０】
例えば、図４のＭＰＥＧエンコーダ２１は、３−２プルダウン処理により３０Ｈｚのフレームレートに変換された画像信号が入力されたとき、フィールドの繰り返しを検出して、元の２４Ｈｚの符号化フレーム単位で符号化を行い、その処理に対応して、フラグ（Ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄ，Ｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔ）を生成する。
【００３１】
Ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄのフラグの”１”は、リピートフィールドが作成されたことを意味し、Ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄのフラグの”０”は、リピートフィールドが作成されていないことを意味する。Ｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔのフラグは、フレームを構成するフィールドのうち、最初のフィールドがトップフィールドであるのか、またはボトムフィールドであるのかを表している。Ｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔのフラグの”１”は、トップフィールドがボトムフィールドより時間的に早いフレーム構造であることを表しており、Ｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔのフラグの”０”は、ボトムフィールドがトップフィールドより時間的に早いフレーム構造であることを表している。
【００３２】
図１０に示すように、原信号のフレームが３フィールドのフレームである場合、対応する１つの符号化フレームには、同一位相の２枚のフィールド（３−２プルダウン処理によりコピーにより生成されたフィールドとそのコピー元のフィールド）が存在する。しかしながら、この元の１つのフレームを構成する３フィールドが符号化フレーム単位で符号化されるとき、各符号化フレームごとの補助データは、符号化フレーム単位で、１つの補助データとして、ｕｓｅｒ ｄａｔａに記述されるため、原信号の同一位相のフィールドに異なった補助データが記述されていても、その異なった補助データを区別することができなくなってしまう。
【００３３】
【発明が解決しようとする課題】
このように、ＭＰＥＧ方式は、例えば、スタジオなどで画像データを編集する際にも用いられている。しかしながら、従来のシステムでは、異なるスタジオ間で、画像データを効率的に送受信し、迅速に処理することが困難である課題があった。
【００３４】
本発明はこのような状況に鑑みてなされたものであり、異なるスタジオ間で、画像データを効率的に送受信処理することができるようにするものである。
【００３５】
【課題を解決するための手段】
請求項１に記載のビットストリーム変換装置は、画像信号の符号化順序と表示順序を含む順序情報が重畳されたエレメンタリストリームを入力するエレメンタリストリーム入力手段と、エレメンタリストリーム入力手段により入力されたエレメンタリストリームを、順序情報を参照して多重化し、トランスポートストリームを生成するトランスポートストリーム生成手段と、トランスポートストリーム生成手段により生成されたトランスポートストリームを出力するトランスポートストリーム出力手段とを含むことを特徴とする。
また、請求項２に記載のビットストリーム変換装置は、エレメンタリストリームに重畳された順序情報に含まれる符号化情報と順序情報を換算することによりエレメンタリストリームを多重化して生成したトランスポートストリームを入力するトランスポートストリーム入力手段と、トランスポートストリーム入力手段により入力されたトランスポートストリームを、前記符号化情報及び前記表示情報に換算してエレメンタリストリームを生成するエレメンタリストリーム生成手段と、エレメンタリストリーム生成手段により生成されたエレメンタリストリームを出力するエレメンタリストリーム出力手段とを含むことを特徴とする。
【００３６】
請求項６に記載のビットストリーム変換方法は、像信号の符号化順序と表示順序を含む順序情報が重畳されたエレメンタリストリームを入力するエレメンタリストリーム入力ステップと、エレメンタリストリーム入力ステップの処理において入力されたエレメンタリストリームを、順序情報を参照して多重化処理し、トランスポートストリームを生成するトランスポートストリーム生成ステップと、トランスポートストリーム生成ステップの処理において生成されたトランスポートストリームを出力するトランスポートストリーム出力ステップとを含むことを特徴とする。
また、請求項７に記載のビットストリーム変換方法は、エレメンタリストリームに重畳された順序情報に含まれる符号化情報と順序情報を換算することによりエレメンタリストリームを多重化して生成したトランスポートストリームを入力するトランスポートストリーム入力ステップと、トランスポートストリーム入力ステップの処理において入力されたトランスポートストリームを、符号化情報及び表示情報に換算してエレメンタリストリームを生成するエレメンタリストリーム生成ステップと、エレメンタリストリーム生成ステップの処理において生成されたエレメンタリストリームを出力するエレメンタリストリーム出力ステップとを含むことを特徴とする。
【００３７】
請求項８に記載の提供媒体は、画像信号の符号化順序と表示順序を含む順序情報が重畳されたエレメンタリストリームを入力するエレメンタリストリーム入力ステップと、エレメンタリストリーム入力ステップの処理において入力されたエレメンタリストリームを、順序情報を参照して多重化し、トランスポートストリームを生成するトランスポートストリーム生成ステップと、トランスポートストリーム生成ステップの処理において生成されたトランスポートストリームを出力するトランスポートストリーム出力ステップとを含む処理を実行させるコンピュータが読み取り可能なプログラムを提供することを特徴とする。
また、請求項９に記載の提供媒体は、エレメンタリストリームに重畳された順序情報に含まれる符号化情報と順序情報を換算することにより前記エレメンタリストリームを多重化して生成したトランスポートストリームを入力するトランスポートストリーム入力ステップと、トランスポートストリーム入力ステップの処理において入力されたトランスポートストリームを、前記符号化情報及び前記表示情報に換算してエレメンタリストリームを生成するエレメンタリストリーム生成ステップと、エレメンタリストリーム生成ステップの処理において生成されたエレメンタリストリームを出力するエレメンタリストリーム出力ステップと含む処理を実行させるコンピュータが読み取り可能なプログラムを提供することを特徴とする。
【００３８】
請求項１および請求項２に記載のビットストリーム変換装置、請求項６および請求項７に記載のビットストリーム変換方法、請求項８および請求項９に記載の提供媒体により、放送局内においては、エレメンタリストリームのデータが送受信され、放送局間では、トランスポートストリームのデータが送受信される。
【００３９】
【発明の実施の形態】
図１１は、相互に離れた場所に位置するスタジオ４１とスタジオ７１の間で、ＭＰＥＧ符号化されたビットストリームを伝送するシステムの例を表しており、図７における場合と対応する部分には、同一の符号を付してある。この例の場合、各スタジオ内のネットワークを、多重化装置（以下、ＴＳ ＭＵＸ／ＤＥＭＵＸと称する）を介して、衛星やＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ）などの公衆網と接続することで、ビットストリームの伝送を行うことができる。スタジオ７１のＭＰＥＧエンコーダ７２乃至ＳＤＴＩ−ＣＰインタフェース７９は、図７のスタジオ４１のＭＰＥＧエンコーダ４２乃至ＳＤＴＩ−ＣＰインタフェース４９に対応するものであるので、ここでは、その説明を省略する。
【００４０】
ＳＤＴＩ−ＣＰネットワーク５０におけるエレメンタリストリーム（ＥＳ）は、図１２に示すように、ＴＳ ＭＵＸ／ＤＥＭＵＸ６１により、１８８バイト単位のトランスポートストリーム（ＴＳ）に変換されて所定の伝送媒体を介して伝送され、伝送されたトランスポートストリーム（ＴＳ）は、ＴＳ ＭＵＸ／ＤＥＭＵＸ６２で、ＳＤＴＩフォーマットのエレメンタリストリーム（ＥＳ）に変換される。なお、図１２において、薄い影を付けた部分は画像データのパケットを示しており、濃い影を付けた部分は音声データのパケットを示しており、影をつけていない部分は空きデータのパケットを示している。
【００４１】
図１１において、スタジオ４１内のＭＰＥＧエンコーダ４２の出力するエレメンタリストリーム（ＥＳ）が、ＴＳ ＭＵＸ／ＤＥＭＵＸ６１でトランスポートストリーム（ＴＳ）に変換されるまでを、図１３を参照して説明する。ＭＰＥＧエンコーダ４２内のＭＰＥＧビデオエンコーダ４２Ａは、ＭＰＥＧ符号化された画像データのエレメンタリストリーム（ＥＳ）を、ＳＤＴＩ−ＣＰインタフェース４６に出力し、オーディオエンコーダ４２Ｂは、音声データのエレメンタリストリーム（ＥＳ）を、ＳＤＴＩ−ＣＰインタフェース４６に出力する。ＳＤＴＩ−ＣＰインタフェース４６は、入力されたエレメンタリストリーム（ＥＳ）をＳＤＴＩベースのフォーマットのエレメンタリストリーム（ＥＳ）に変換し、ＳＤＴＩ−ＣＰネットワーク５０を介して、ＳＤＴＩ−ＣＰインタフェース５１に出力する。ＳＤＴＩ−ＣＰインタフェース５１は、ＳＤＴＩフォーマットのＥＳをＭＰＥＧ符号化のエレメンタリストリーム（ＥＳ）に変換し、ＴＳ ＭＵＸ／ＤＥＭＵＸ６１に出力する。ＴＳ ＭＵＸ／ＤＥＭＵＸ６１は、ＭＰＥＧ符号化のエレメンタリストリーム（ＥＳ）を１８８バイト単位のトランスポートストリーム（ＴＳ）に変換して伝送媒体に出力する。
【００４２】
図１１において、ＴＳ ＭＵＸ／ＤＥＭＵＸ６１から伝送されたトランスポートストリーム（ＴＳ）は、ＡＴＭなどの公衆網を介して、ＴＳ ＭＵＸ／ＤＥＭＵＸ６２に入力され、ＭＰＥＧ符号化のエレメンタリストリーム（ＥＳ）に変換される。ＳＤＴＩ−ＣＰインタフェース８１において、ＭＰＥＧ符号化されたエレメンタリストリーム（ＥＳ）は、ＳＤＴＩフォーマットのエレメンタリストリーム（ＥＳ）に変換され、スタジオ７１のＳＤＴＩ−ＣＰネットワーク８０に出力される。ＭＰＥＧデコーダ７４は、ＳＤＴＩ−ＣＰインタフェース７８を介して、スタジオ２１から伝送されたエレメンタリストリーム（ＥＳ）を受信することができる。
【００４３】
図１１のシステムにおいて、スタジオ４１とスタジオ７１の間で、画像信号を伝送する場合、多重化装置（例えば、図１１のＴＳ ＭＵＸ／ＤＥＭＵＸ６１）には、画像データが符号化されたエレメンタリストリーム（ＥＳ）のみが入力されるので、多重化装置は、エンコーダ（例えば、図１１のＭＰＥＧエンコーダ４２）において行われた符号化順序の並べ変えの情報を知らない。このため、多重化装置は、入力されたエレメンタリストリーム（ＥＳ）を解釈して、エレメンタリストリーム（ＥＳ）をトランスポートストリーム（ＴＳ）に変換する処理をしなければならない。
【００４４】
このエレメンタリストリームを解釈する処理は、画像信号の符号化構造を把握する処理である。つまり、前述したエンコーダで入力画像をバッファリングして符号化し、ビットストリームに変換するときと同様の処理が、多重化装置でも必要となる。この多重化装置におけるバッファリング処理により、後段での画像データの復号までに遅延が発生し、リアルタイム処理が困難になる。
【００４５】
この多重化装置で発生する、システム構成上、問題となる遅延について、図１４を用いて説明する。多重化装置に、図１４に示す符号化順序で、エンコーダで符号化されたビットストリームが入力された場合、多重化装置は、２枚の連続したＩピクチャ（時刻ｔ４）とＰピクチャ（時刻ｔ５）が入力された後、さらにそれらに挟まれた２枚のＢピクチャ（時刻ｔ６と時刻ｔ７）に続いてＰピクチャ（時刻ｔ８）が入力されるまで、表示順序を確定することができない。つまり、多重化装置は、図５に示したような符号化構造（ＩピクチャとＰピクチャの間に２枚のＢピクチャが挟まれている構造）を知らないので、２枚のＢピクチャが入力され、その次のＰピクチャ（時刻ｔ８）が入力されたとき（Ｂピクチャの入力が終了したことを確認したとき）、時刻ｔ４に入力されたＩピクチャの表示順序（ＰＴＳ）を確定することができる。
【００４６】
すなわち、この多重化装置においては、時刻ｔ８になって初めて、符号化順序＝１のＩピクチャの表示順序＝２を確定することができる。このため、多重化装置では、２枚の連続したＩピクチャまたはＰピクチャ＋２枚のＢピクチャの出現周期（＝４）の遅延が発生する。この遅延は、エンコーダでの遅延とは別に新たに発生するため、システム全体として、エンコーダの遅延（＝３）＋多重化装置の遅延（＝４）＝７の大幅な遅延が生じる。
【００４７】
そこで本発明においては、符号化順序と表示順序を含む順序情報を、Ｐｉｃｔｕｒｅ Ｏｒｄｅｒ Ｉｎｆｏとしてエレメンタリストリームに重畳するようにしている。この点のについては、後に詳述する。
【００４８】
図１５は、本発明を適用したＭＰＥＧエンコーダ４２の構成例を表している。ＭＰＥＧエンコーダ４２の分離部１０１は、入力された画像信号から、画像データと補助データを分離し、画像データをＭＰＥＧエンコード部１０３に出力し、補助データをエンコードコントローラ１０２に出力する。ＭＰＥＧエンコード部１０３は、入力された画像データをＭＰＥＧ方式により符号化するとともに、符号化順序を示すＤＴＳ＿ｃｏｕｎｔｅｒ、および表示順序を示すＰＴＳ＿ｃｏｕｎｔｅｒを含むＰＯＩ（Ｐｉｃｔｕｒｅ Ｏｒｄｅｒ Ｉｎｆｏｍａｔｉｏｎ）をエンコードコントローラ１０２に出力する。また、ＭＰＥＧエンコード部１０３は、符号化した範囲の左上の位置（図１の有効画素エリア２の左上の画素の位置）を表すコーディングフェーズ（Ｃｏｄｉｎｇ Ｐｈａｓｅ（Ｖ−Ｐｈａｓｅ，Ｈ−Ｐｈａｓｅ））をエンコードコントローラ１０２に供給する。
【００４９】
エンコードコントローラ１０２は、分離部１０１より供給された補助データに、それが属するフィールドを識別するＦｉｅｌｄ ＩＤと、それが挿入されているラインを表すＬｉｎｅ＿ｎｕｍｂｅｒを付加し、その補助データと、ＭＰＥＧエンコード部１０３より供給されたＰＯＩ、およびＣｏｄｉｎｇ Ｐｈａｓｅ Ｉｎｆｏｒｍａｔｉｏｎ（ＣＰＩ）を適宜処理し、ｕｓｅｒ ｄａｔａのフォーマットのデータとして、可変長符号化部１０４に出力し、多重化させる。
【００５０】
可変長符号化部１０２は、ＭＰＥＧエンコード部１０３より供給されたエンコードされた画像データを可変長符号化するとともに、エンコードコントローラ１０２より供給されたｕｓｅｒ ｄａｔａを画像データのエレメンタリストリームに挿入する。可変長符号化部１０４より出力されたエレメンタリストリームは、送信バッファ１０５を介して出力される。
【００５１】
図１６は、本発明を適用したＭＰＥＧデコーダ４４の構成例を表している。受信バッファ１１１は、入力されたデータを一旦バッファリングした後、可変長復号部１１２に出力する。可変長復号部１１２は、入力されたデータから、画像データとｕｓｅｒ ｄａｔａとを分離し、画像データをＭＰＥＧデコード部１１４に出力し、ｕｓｅｒ ｄａｔａをデコードコントローラ１１３に出力する。デコードコントローラ１１３は、ｕｓｅｒ ｄａｔａからＰＯＩとＣＰＩを分離し、それらをＭＰＥＧデコード部１１４に出力する。また、デコードコントローラ１１３は、ｕｓｅｒ ｄａｔａから分離した補助データを合成部１１５に出力する。ＭＰＥＧデコード部１１４は、可変長復号部１１２より入力された画像データを、デコードコントローラ１１３より入力されたＰＯＩとＣＰＩを参照してデコードし、デコードした結果を合成部１１５に出力している。合成部１１５は、デコードコントローラ１１３より供給された補助データをＭＰＥＧデコード部１１４より供給された画像データと合成し、出力する。
【００５２】
以下に、ＭＰＥＧエンコーダ４２とＭＰＥＧデコーダ４４の動作について説明する。
【００５３】
ＣＰＩをｕｓｅｒ ｄａｔａに記述して、エレメンタリストリーム（ＥＳ）に重畳して出力する動作を、図１７を参照して説明すると、アプリケーションＡ用ＭＰＥＧエンコーダ４２は、アプリケーションＡの画像信号を符号化したエレメンタリストリーム（ＥＳ）に、ＣＰＩ（画像信号のフォーマットにおける有効画素エリアを示すデータであるＶ−ＰｈａｓｅとＨ−Ｐｈａｓｅ）をｕｓｅｒ ｄａｔａに記述して（図１５の可変長符号化部１０４がエンコードコントローラ１０２から出力されるＣＰＩのデータをｕｓｅｒ ｄａｔａに記述して）、ＳＤＴＩ−ＣＰインタフェース４６に出力する。アプリケーションＢ用ＭＰＥＧエンコーダ４３も、ＭＰＥＧエンコーダ４２と同様に構成されており、アプリケーションＢの画像信号を符号化したエレメンタリストリーム（ＥＳ）に、ＣＰＩをｕｓｅｒ ｄａｔａとして記述して、ＳＤＴＩ−ＣＰインタフェース４７に出力する。
【００５４】
ＳＤＴＩ−ＣＰインタフェース４６の構成例について、図１８を参照して説明する（他のＳＤＴＩ−ＣＰインタフェースも同様に構成されている）。復号部１２１は、ＭＰＥＧエンコーダ４２から入力されたＭＰＥＧ符号化されたエレメンタリストリーム（ＥＳ）を、符号化パラメータと画像データに分離し、画像データを復号し、符号化パラメータとともに符号化パラメータ多重化部１２２に出力する。符号化パラメータ多重化部１２２は、画像信号と符号化パラメータから、ＳＤＴＩ−ＣＰベースのエレメンタリストリーム（ＥＳ）を生成して出力する。
【００５５】
ＳＤＴＩ−ＣＰインタフェース４６に、ＳＤＴＩ−ＣＰベースのエレメンタリストリーム（ＥＳ）が入力された場合、符号化パラメータ分離部１２３は、エレメンタリストリーム（ＥＳ）から画像データと符号化パラメータを分離して、それぞれ符号化部１２４に出力する。符号化部１２４は、符号化パラメータを用いて、画像データを符号化し、ＭＰＥＧ符号化されたエレメンタリストリーム（ＥＳ）として出力するか、またはパケット化部１２５でＭＰＥＧ符号化されたトランスポートストリーム（ＴＳ）として出力する。
【００５６】
ＳＤＴＩ−ＣＰインタフェース４６，４７は、ＭＰＥＧ符号化されたエレメンタリストリーム（ＥＳ）を、ＳＤＴＩフォーマットのエレメンタリストリーム（ＥＳ）に変換して、ＳＤＴＩ−ＣＰネットワーク５０を介して、伝送する。ＳＤＴＩ−ＣＰインタフェース４８は、ＳＤＴＩフォーマットのエレメンタリストリーム（ＥＳ）をＭＰＥＧ符号化されたエレメンタリストリーム（ＥＳ）に変換し、ＭＰＥＧデコーダ４４に出力する。
【００５７】
ＭＰＥＧデコーダ４４は、入力されたアプリケーションＡのエレメンタリストリーム（ＥＳ）またはアプリケーションＢのエレメンタリストリーム（ＥＳ）を復号し、それぞれのエレメンタリストリーム（ＥＳ）に記述されている（図１６のデコードコントローラ１１３が出力する）ＣＰＩに基づいて、画像信号を有効画素エリアに配置するように復号する。
【００５８】
ＭＰＥＧエンコーダ４２，４３は、それぞれが符号化したアプリケーションの画像信号のＣＰＩをＭＰＥＧ符号化されたエレメンタリストリーム（ＥＳ）中のｕｓｅｒ ｄａｔａに記述することにより、画像データとともに、ＣＰＩを伝送することができる。また、ＭＰＥＧエンコーダ４２，４３は、ＣＰＩを伝送する機能を有することにより、様々なアプリケーションを符号化して伝送することができる。
【００５９】
ＭＰＥＧデコーダ４４は、ＭＰＥＧ符号化されたエレメンタリストリーム（ＥＳ）に挿入されているＣＰＩを分離、解釈することにより、様々なＣｏｄｉｎｇ Ｐｈａｓｅを有するアプリケーションの画像を、適切に、有効画素エリアに配置するように復号処理することができる。
【００６０】
なお、本発明に実施の形態においては、ＣＰＩを、ＭＰＥＧ符号化されたエレメンタリストリームのｕｓｅｒ ｄａｔａに挿入したが、ビットストリームに他の方法で挿入するようにしてもよい。
【００６１】
次に、ＭＰＥＧエンコーダ４２において、各フィールドごとの複数の補助データを識別する動作について、図１９を参照して説明する。３−２プルダウン処理が実施されている符号化フレームの原信号（３０Ｈｚ）の各フィールドに、補助データが挿入されているものとする。この補助データを有する原信号（３０Ｈｚ）が、元のフレームレートの符号化フレーム（２４Ｈｚ）に符号化されるとき、各符号化フレームに含まれる２つまたは３つのフィールドに記述されている補助データに、符号化されたフィールドに対応した識別子が、ｆｉｅｌｄ＿ＩＤ（０乃至２のカウンタの値）として付加されて（図１５のエンコードコントローラ１０２で補助データにｆｉｅｌｄ＿ＩＤが付加されて）、補助データともに伝送される。このｆｉｅｌｄ＿ＩＤが補助データに付加されることにより、補助データがどの符号化フレーム内の、どのフィールドに対応したものであるかが識別される。
【００６２】
具体的に説明すると、図１９の先頭の符号化フレームのフィールドの枚数は、２枚であるので、補助データは２つ存在する。符号化フレームは２枚のフィールドから生成され、その符号化フレームに対応する２枚のフィールドの、それぞれの補助データに、ｆｉｅｌｄ＿ＩＤとして、”０”または”１”が付加される。
【００６３】
先頭から２番目の符号化フレームのフィールドの枚数は、３枚であるので、補助データは３つ存在する。符号化フレームは３枚のフィールドから生成され、その符号化フレームに対応する３枚のフィールドの、それぞれの補助データに、ｆｉｅｌｄ＿ＩＤとして、”０”，”１”または”２”が付加される。
【００６４】
つまり、１枚の符号化フレームに対して、１つの補助データが生成されるのではなく、符号化フレームに含まれていたフィールドの枚数と同じ数の補助データが生成され、それぞれにｆｉｅｌｄ＿ＩＤが付加される。その結果、同一の符号化フレームに含まれる複数の補助データは、付加されたｆｉｅｌｄ＿ＩＤにより、符号化フレーム内で識別されるので、それぞれの補助データに異なった情報が含まれていても、識別できなくなることはない。
【００６５】
ＭＰＥＧエンコーダ４２では、画像データがＭＰＥＧエンコード部１０３でエンコードされ、可変長符号化部１０４で可変長符号化される。また、エンコードコントローラ１０２で補助データにｆｉｅｌｄ＿ＩＤと、補助データが挿入されていたライン番号（Ｌｉｎｅ＿ｎｕｍｂｅｒ）が付加され、エレメンタリストリーム中のｕｓｅｒ ｄａｔａ中に、ａｎｃｉｌｌａｒｙ ｄａｔａとして挿入される。これにより、複数の補助データを識別して伝送することができる。
【００６６】
ＭＰＥＧデコーダ４４では、ＭＰＥＧ符号化されたエレメンタリストリーム中のｕｓｅｒ ｄａｔａが可変長復号部１１２で分離され、デコードコントローラ１１３に供給される。デコードコントローラ１１３は、ｕｓｅｒ ｄａｔａに挿入されているａｎｃｉｌｌａｒｙ ｄａｔａのｆｉｅｌｄ＿ＩＤとＬｉｎｅ＿ｎｕｍｂｅｒに基づいて、複数の補助データを識別、分離し、合成部１１５に出力する。合成部１１５は、ＭＰＥＧデコード部１１４で復号された画像データと、それに対応する補助データ（テキストデータ）を合成し、出力する。
【００６７】
ＭＰＥＧエンコーダ４２は、システム全体の遅延を少なくするために、図２０に示すような符号化順序と表示順序を管理するＰＯＩを生成する。
【００６８】
例えば、ＭＰＥＧエンコーダ４２のＭＰＥＧエンコード部１０３に入力された画像データが、３−２プルダウン処理により、２４Ｈｚのフレームレートに変換された画像信号である場合、図２０（Ａ）に示すようなフラグ（Ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄ，Ｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔ）により、各フレームが管理される。
【００６９】
Ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄのフラグの”１”は、リピートフィールドを作成する必要があることを意味し、Ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄのフラグの”０”は、リピートフィールドを作成する必要がないことを意味する。Ｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔのフラグは、フレームを構成するフィールドのうち、最初のフィールドがトップフィールドであるのか、またはボトムフィールドであるのかを表している。Ｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔフラグの”１”は、トップフィールドがボトムフィールドより時間的に早いフレーム構造であることを表しており、Ｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔフラグの”０”は、ボトムフィールドがトップフィールドより時間的に早いフレーム構造であることを表している。
【００７０】
図２０（Ａ）について、具体的に説明すると、最初にＭＰＥＧエンコード部１０３に入力されるＦｒａｍｅ Ｎｏ１の符号化フレームの符号化画像データ種別は、Ｉピクチャであり、このＩピクチャの２フィールド（トップフィールドとボトムフィールド）は、トップフィールドをコピーしてリピートフィールドを作成することで、３フィールドに変換する必要があるので、対応するＲｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄのフラグは”１”となり、Ｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔのフラグは”１”となる。
【００７１】
Ｆｒａｍｅ Ｎｏ２の符号化フレームの符号化画像データ種別は、Ｂピクチャであり、このＢピクチャには、リピートフィールドが生成する必要がないので、Ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄのフラグは”０”とされ、ボトムフィールドがトップフィールドより時間的に早いフレームであるため、Ｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔのフラグは”０”とされる。このときのＴｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔのフラグの値は、３−２プルダウン処理には関係しない。
【００７２】
Ｆｒａｍｅ Ｎｏ３の符号化フレームの符号化画像データ種別は、Ｂピクチャであり、Ｆｒａｍｅ Ｎｏ３のＢピクチャでは、そのボトムフィールドをコピーしてリピートフィールドが作成され、符号化フレームが３フィールドに変換されている。従って、Ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄのフラグは”１”とされ、Ｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔのフラグは”０”とされる。
【００７３】
Ｆｒａｍｅ Ｎｏ４の符号化フレームの符号化画像データ種別は、Ｐピクチャであり、このＰピクチャに対しては、リピートフィールドが作成されておらず、Ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄのフラグは”０”とされ、Ｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔのフラグは１とされる。
【００７４】
ＭＰＥＧエンコード部１０３は、図２０（Ａ）に示すような３−２プルダウン処理が施された画像データが入力されてきたとき、内蔵するカウンタＰＴＳ＿ｃｏｕｎｔｅｒでフィールドの数をカウントし、その値ＰＴＳ＿ｃｏｕｎｔｅｒを表示順序としてエンコードコントローラ１０２に出力する。カウンタＰＴＳ＿ｃｏｕｎｔｅｒは、０から１２７まで増加した後、再び０に戻るカウント動作を行う。従って、カウンタＰＴＳ＿ｃｏｕｎｔｅｒの値は、図２０（Ｂ）に示すように変化する。
【００７５】
具体的に説明すると、最初に入力されるＦｒａｍｅ Ｎｏ１のＩピクチャのＰＴＳ＿ｃｏｕｎｔｅｒの値は値”０”である。先頭から２番目に入力されるＦｒａｍｅ Ｎｏ２のＢピクチャのＰＴＳ＿ｃｏｕｎｔｅｒの値は、Ｆｒａｍｅ Ｎｏ１のＩピクチャのＰＴＳ＿ｃｏｕｎｔｅｒの値”０”に、Ｐピクチャのフィールド数３を加算した値”３”（＝０＋３）となる。
【００７６】
先頭から３番目に入力されるＦｒａｍｅ Ｎｏ３のＢピクチャのＰＴＳ＿ｃｏｕｎｔｅｒの値は、Ｆｒａｍｅ Ｎｏ２のＢピクチャのＰＴＳ＿ｃｏｕｎｔｅｒの値”３”に、Ｂピクチャのフィールド数２を加算した値”５”（＝３＋２）となる。先頭から４番目に入力されるＦｒａｍｅ Ｎｏ４のＰピクチャのＰＴＳ＿ｃｏｕｎｔｅｒの値は、Ｆｒａｍｅ Ｎｏ３のＢピクチャのＰＴＳ＿ｃｏｕｎｔｅｒの値”５”に、Ｂピクチャのフィールド数３を加算した値”８”（＝５＋３）となる。Ｆｒａｍｅ Ｎｏ５のＢピクチャ以降のＰＴＳ＿ｃｏｕｎｔｅｒの値も同様に算出される。
【００７７】
さらに、ＭＰＥＧエンコード部１０３は、内蔵するカウンタＤＴＳ＿ｃｏｕｎｔｅｒでエンコードしたフレームを計数し、計数した結果をエンドコントローラ１０２に出力する。
【００７８】
図２０（Ｃ）を参照して、具体的に説明すると、Ｆｒａｍｅ Ｎｏ１のＩピクチャのＤＴＳ＿ｃｏｕｎｔｅｒの値１２５は、Ｆｒａｍｅ Ｎｏ１のＩピクチャが表示される表示順序ＰＴＳ＿ｃｏｕｎｔｅｒ＝０を基準としたとき、１フレーム分の出現周期前に符号化される必要がある（図１４に対応させると、先頭のＩピクチャの符号化順序の値は”１”であり、表示順序の値は”２”であり、符号化順序の値は表示順序の値より１フレーム分早い必要がある）。つまり、Ｉピクチャが３つのフィールドを持っているため、ＤＴＳ＿ｃｏｕｎｔｅｒの値は、０より３だけ前の値”１２５”（ＤＴＳ＿ｃｏｕｎｔｅｒは２７（＝１２８）のモジュロで表されるため、その値は０から１２７の間の値を循環する）となる。
【００７９】
Ｆｒａｍｅ Ｎｏ１のＩピクチャの次に符号化されるＦｒａｍｅ Ｎｏ４のＰピクチャのＤＴＳ＿ｃｏｕｎｔｅｒの値は、Ｆｒａｍｅ Ｎｏ１のＩピクチャのＤＴＳ＿ｃｏｕｎｔｅｒの値１２５にＩピクチャのフィールド数３を加えた値０（＝１２８＝１２５＋３）となる。
【００８０】
Ｆｒａｍｅ Ｎｏ４のＰピクチャの次に符号化される、Ｆｒａｍｅ Ｎｏ２のＢピクチャのＤＴＳ＿ｃｏｕｎｔｅｒの値は、ＢピクチャのためにＰＴＳ＿ｃｏｕｎｔｅｒ＝ＤＴＳ＿ｃｏｕｎｔｅｒであり、ＰＴＳ＿ｃｏｕｎｔｅｒの値と同一とされ、その値は”３”となる。同様に、Ｆｒａｍｅ Ｎｏ２のＢピクチャの次に符号化される、Ｆｒａｍｅ Ｎｏ３のＢピクチャのＤＴＳ＿ｃｏｕｎｔｅｒの値も、ＰＴＳ＿ｃｏｕｎｔｅｒの値と同一とされ、その値は”５”とされる。以下、Ｆｒａｍｅ Ｎｏ７のＰピクチャ以降のＤＴＳ＿ｃｏｕｎｔｅｒの値も、同様に算出されるので、ここでは、その説明を省略する。
【００８１】
ＭＰＥＧエンコード部１０３は、図２０に示すようなフラグＲｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄ，Ｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔ、並びにカウンタＰＴＳ＿ｃｏｕｎｔｅｒ，ＤＴＳ＿ｃｏｕｎｔｅｒをＰＯＩとして、エンコードコントローラ１０２に出力する。
【００８２】
ここで、図１１に示した、離れた場所にあるスタジオ４１のＭＰＥＧエンコーダ４２から、スタジオ７１のＭＰＥＧデコーダ７４に、ＳＤＴＩ−ＣＰネットワーク５０，８０、ＴＳ ＭＵＸ／ＤＥＭＵＸ６１，６２、およびＡＴＭのネットワークを使用して、画像信号の伝送を行うシステムの、符号化順序と表示順序について、図２１を参照して説明する。
【００８３】
ＭＰＥＧエンコーダ４２内のＭＰＥＧビデオエンコーダ４２Ａは、ＭＰＥＧ符号化された画像データのエレメンタリストリーム（ＥＳ）を出力するとともに、ＰＯＩを、そのエレメンタリストリーム（ＥＳ）中のｕｓｅｒ ｄａｔａに挿入する（図１５のエンコードコントローラ１０２がＰＯＩのデータをｕｓｅｒ ｄａｔａに記述し、可変長符号化部１０４に出力して、多重化させる）。ＭＰＥＧエンコーダ４２内のオーディオエンコーダ４２Ｂは、音声データを符号化してエレメンタリストリーム（ＥＳ）として出力する。ＳＤＴＩ−ＣＰインタフェース４６は、ＭＰＥＧビデオエンコーダ４２Ａからのエレメンタリストリーム（ＥＳ）（ＰＯＩを含んだストリーム）と、オーディオエンコーダ４２Ｂからのエレメンタリストリーム（ＥＳ）を、ＳＤＴＩフォーマットのエレメンタリストリームに変換して、ＳＤＴＩ−ＣＰネットワーク５０に出力する。
【００８４】
ＳＤＴＩ−ＣＰインタフェース５１は、入力されたＳＤＴＩフォーマットのエレメンタリストリーム（ＥＳ）を、ＭＰＥＧ符号化のエレメンタリストリーム（ＥＳ）に変換し（図１８を参照してＳＤＴＩ−ＣＰインタフェース４６の動作として説明したように）、ＴＳ ＭＵＸ／ＤＥＭＵＸ６１に出力する。ＴＳ ＭＵＸ／ＤＥＭＵＸ６１は、エレメンタリストリーム（ＥＳ）に挿入されているＰＯＩを参照して、ＰＴＳ＿ｃｏｕｎｔｅｒの値をＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ Ｓｔａｍｐ）に、また、ＤＴＳ＿ｃｏｕｎｔｅｒの値をＤＴＳ（Ｄｅｃｏｄｉｎｇ Ｔｉｍｅ Ｓｔａｍｐ）に、それぞれ換算し、多重化処理を行い、１８８バイト単位のパケットから構成されるトランスポートストリーム（ＴＳ）を生成して出力する（従って、トランスポートストリーム（ＴＳ）には、ＰＴＳ＿ｃｏｕｎｔｅｒとＤＴＳ＿ｃｏｕｎｔｅｒではなく、ＰＴＳとＤＴＳが含まれる）。
【００８５】
ＴＳ ＭＵＸ／ＤＥＭＵＸ６１は、エレメンタリストリーム（ＥＳ）に挿入されているＰＯＩを解釈することにより、前述のバッファリング処理を行うことなく、直ちに多重化処理を行うことができ、ＴＳ ＭＵＸ／ＤＥＭＵＸ６１において、新たに遅延が発生することはない。また、ＰＯＩはエレメンタリストリーム（ＥＳ）中に挿入されているため、ＴＳ ＭＵＸ／ＤＥＭＵＸ６１は、ＰＯＩを後段に伝達するために、ＰＯＩをビットストリームに含ませる処理を行わなくてもよい。
【００８６】
図１１のＴＳ ＭＵＸ／ＤＥＭＵＸ６２は、ＡＴＭなどの公衆網を介して入力されたトランスポートストリーム（ＴＳ）から画像データと音声データを分離して、ＭＰＥＧ符号化のエレメンタリストリーム（ＥＳ）に変換する。ＴＳ ＭＵＸ／ＤＥＭＵＸ６２はまた、ＰＴＳ，ＤＴＳをＰＴＳ＿ｃｏｕｎｔｅｒ，ＤＴＳ＿ｃｏｕｎｔｅｒに換算して、エレメンタリストリームのｕｓｅｒ ｄａｔａに挿入し、ＳＤＴＩ−ＣＰインタフェース８１に出力する。ＳＤＴＩ−ＣＰインタフェース８１は、ＭＰＥＧ符号化されたエレメンタリストリーム（ＥＳ）をＳＤＴＩフォーマットのエレメンタリストリーム（ＥＳ）に変換し、スタジオ７１のＳＤＴＩ−ＣＰネットワーク８０に出力する。ＭＰＥＧデコーダ７４（ＭＰＥＧデコーダ４４と同一の構成）は、ＳＤＴＩ−ＣＰインタフェース７８を介して、伝送されてきた画像データと音声データのエレメンタリストリーム（ＥＳ）を受信し、復号する。
【００８７】
ＭＰＥＧデコーダ７４は、ＴＳ ＭＵＸ／ＤＥＭＵＸ６１と同様に、エレメンタリストリーム（ＥＳ）に挿入されているＰＯＩを解釈して、前述のバッファリング処理を行うことなく、直ちに復号する（図１６のデコードコントローラ１１３が出力するＰＯＩに基づき、ＭＰＥＧデコード部１１４が画像データを復号する）ことができ、ＭＰＥＧデコーダ７４において、新たに遅延が発生することはない。つまり、ＭＰＥＧビデオエンコーダ４２Ａが、ＭＰＥＧ符号化されたエレメンタリストリーム（ＥＳ）とともに、ＰＯＩをエレメンタリストリームに挿入して出力することにより、後段のＴＳ ＭＵＸ／ＤＥＭＵＸ６１と、ＭＰＥＧデコーダ７４は、ＰＯＩを解釈して多重化処理、または復号処理を直ちに行うことができ、システム全体としての遅延を、ＭＰＥＧエンコーダ４２で生ずるＢピクチャの枚数（＝２）＋１枚＝３の遅延のみに抑えることができる。すなわち、このような符号化、多重化、および復号を含むシステムにおいて、理論的に最も小さい遅延とすることができる。
【００８８】
また、図２１のシステム構成において、図１８に示したＳＤＴＩ−ＣＰインタフェース４６を用いることにより、ＳＤＴＩ−ＣＰネットワーク５０を使用して画像信号を伝送するとき、スタジオ４１の内部では、ビットストリームを、編集が容易で、短距離伝送に適したエレメンタリストリーム（ＥＳ）の形態で伝送することが可能となり、離れたスタジオ間でＡＴＭなどの公衆網を使用して画像信号を伝送するとき、ビットストリームを、長距離伝送に適したトランスポートストリーム（ＴＳ）の形態で伝送することが可能となる。
【００８９】
以上においては、ＰＯＩをエレメンタリストリームに挿入するようにしたが、ＴＳ ＭＵＸ／ＤＥＭＵＸ６１とＭＰＥＧエンコーダ４２の距離が近いような場合には、図２２に示すように、ＰＯＩをＭＰＥＧエンコーダ４２から、ＴＳ ＭＵＸ／ＤＥＭＵＸ６１に直接供給するようにしてもよい。
【００９０】
しかしながら、このようにすると、エレメンタリストリームを伝送するＳＤＴＩ−ＣＰネットワーク５０以外の配線処理が必要となる。
【００９１】
以上に述べたように、エンコーダの有する情報を、エレメンタリストリーム（ＥＳ）中のｕｓｅｒ ｄａｔａに記述して、多重化装置またはデコーダに出力することにより、エンコーダのみが有していた情報（Ｃｏｄｉｎｇ Ｐｈａｓｅ（Ｖ−ＰｈａｓｅとＨ−Ｐｈａｓｅ）、Ｆｉｅｌｄ＿ＩＤ、符号化順序ＤＴＳ＿ｃｏｕｎｔｅｒ、および表示順序ＰＴＳ＿ｃｏｕｎｔｅｒ）を、エンコーダより後段の多重化装置、デコーダに供給することができる。
【００９２】
次に、図２３乃至図３６を参照してビットストリームのシンタックスについて説明する。
【００９３】
図２３は、ＭＰＥＧのビデオストリームのシンタックスを表わした図である。ＭＰＥＧエンコーダ４２は、この図２３に示されたシンタックスに従った符号化エレメンタリストリームを生成する。以下に説明するシンタックスにおいて、関数や条件文は細活字で表わされ、データエレメントは、太活字で表されている。データ項目は、その名称、ビット長およびそのタイプ・伝送順序を示すニーモニック（Ｍｎｅｍｏｎｉｃ）で記述されている。
【００９４】
まず、この図２３に示されているシンタックスにおいて使用されている関数について説明する。実際には、この図２３に示されているシンタックスは、ＭＰＥＧデコーダ４４側において、伝送されてきた符号化ビットストリームから所定の意味のあるデータエレメントを抽出するために使用されるシンタックスである。ＭＰＥＧエンコーダ４２側において使用されるシンタックスは、図２３に示されたシンタックスからｉｆ文やｗｈｉｌｅ文等の条件文を省略したシンタックスである。
【００９５】
ｖｉｄｅｏ＿ｓｅｑｕｅｎｃｅ（）において最初に記述されているｎｅｘｔ＿ｓｔａｒｔ＿ｃｏｄｅ（）関数は、ビットストリーム中に記述されているスタートコードを探すための関数である。この図２３に示されたシンタックスに従って生成された符号化ストリームには、まず最初に、ｓｅｑｕｅｎｃｅ＿ｈｅａｄｅｒ（）関数とｓｅｑｕｅｎｃｅ＿ｅｘｔｅｎｓｉｏｎ（）関数によって定義されたデータエレメントが記述されている。このｓｅｑｕｅｎｃｅ＿ｈｅａｄｅｒ（）関数は、ＭＰＥＧビットストリームのシーケンスレイヤのヘッダデータを定義するための関数であって、ｓｅｑｕｅｎｃｅ＿ｅｘｔｅｎｓｉｏｎ（）関数は、ＭＰＥＧビットストリームのシーケンスレイヤの拡張データを定義するための関数である。
【００９６】
ｓｅｑｕｅｎｃｅ＿ｅｘｔｅｎｓｉｏｎ（）関数の次に配置されている ｄｏ｛ ｝ｗｈｉｌｅ構文は、ｗｈｉｌｅ文によって定義されている条件が真である間、ｄｏ文の｛ ｝内の関数に基いて記述されたデータエレメントが符号化データストリーム中に記述されていることを示す構文である。このｗｈｉｌｅ文に使用されているｎｅｘｔｂｉｔｓ（）関数は、ビットストリーム中に記述されているビット又はビット列と、参照されるデータエレメントとを比較するための関数である。この図２３に示されたシンタックスの例では、ｎｅｘｔｂｉｔｓ（）関数は、ビットストリーム中のビット列とビデオシーケンスの終わりを示すｓｅｑｕｅｎｃｅ＿ｅｎｄ＿ｃｏｄｅとを比較し、ビットストリーム中のビット列とｓｅｑｕｅｎｃｅ＿ｅｎｄ＿ｃｏｄｅとが一致しないときに、このｗｈｉｌｅ文の条件が真となる。従って、ｓｅｑｕｅｎｃｅ＿ｅｘｔｅｎｓｉｏｎ（）関数の次に配置されている ｄｏ｛ ｝ｗｈｉｌｅ構文は、ビットストリーム中に、ビデオシーケンスの終わりを示すｓｅｑｕｅｎｃｅ＿ｅｎｄ＿ｃｏｄｅが現れない間、ｄｏ文中の関数によって定義されたデータエレメントが符号化ビットストリーム中に記述されていることを示している。
【００９７】
符号化ビットストリームにおいて、ｓｅｑｕｅｎｃｅ＿ｅｘｔｅｎｓｉｏｎ（）関数によって定義された各データエレメントの次には、ｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（０）関数によって定義されたデータエレメントが記述されている。このｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（０）関数は、ＭＰＥＧビットストリームのシーケンスレイヤにおける拡張データとユーザデータを定義するための関数である。
【００９８】
このｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（０）関数の次に配置されている ｄｏ｛ ｝ｗｈｉｌｅ構文は、ｗｈｉｌｅ文によって定義されている条件が真である間、ｄｏ文の｛ ｝内の関数に基いて記述されたデータエレメントが、ビットストリームに記述されていることを示す関数である。このｗｈｉｌｅ文において使用されているｎｅｘｔｂｉｔｓ（）関数は、ビットストリーム中に現れるビット又はビット列と、ｐｉｃｔｕｒｅ＿ｓｔａｒｔ＿ｃｏｄｅ又はｇｒｏｕｐ＿ｓｔａｒｔ＿ｃｏｄｅとの一致を判断するための関数であるって、ビットストリーム中に現れるビット又はビット列と、ｐｉｃｔｕｒｅ＿ｓｔａｒｔ＿ｃｏｄｅ又はｇｒｏｕｐ＿ｓｔａｒｔ＿ｃｏｄｅとが一致する場合には、ｗｈｉｌｅ文によって定義された条件が真となる。よって、このｄｏ｛ ｝ｗｈｉｌｅ構文は、符号化ビットストリーム中において、ｐｉｃｔｕｒｅ＿ｓｔａｒｔ＿ｃｏｄｅ又はｇｒｏｕｐ＿ｓｔａｒｔ＿ｃｏｄｅが現れた場合には、そのスタートコードの次に、ｄｏ文中の関数によって定義されたデータエレメントのコードが記述されていることを示している。
【００９９】
このｄｏ文の最初に記述されているｉｆ文は、符号化ビットストリーム中にｇｒｏｕｐ＿ｓｔａｒｔ＿ｃｏｄｅが現れた場合、という条件を示しいる。このｉｆ文による条件は真である場合には、符号化ビットストリーム中には、このｇｒｏｕｐ＿ｓｔａｒｔ＿ｃｏｄｅの次にｇｒｏｕｐ＿ｏｆ＿ｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）関数およびｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（１）関数によって定義されているデータエレメントが順に記述されている。
【０１００】
このｇｒｏｕｐ＿ｏｆ＿ｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）関数は、ＭＰＥＧ符号化ビットストリームのＧＯＰレイヤのヘッダデータを定義するための関数であって、ｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（１）関数は、ＭＰＥＧ符号化ビットストリームのＧＯＰレイヤの拡張データおよびユーザデータを定義するための関数である。
【０１０１】
さらに、この符号化ビットストリームにおいて、ｇｒｏｕｐ＿ｏｆ＿ｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）関数およびｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（１）関数によって定義されているデータエレメントの次には、ｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）関数とｐｉｃｔｕｒｅ＿ｃｏｄｉｎｇ＿ｅｘｔｅｎｓｉｏｎ（）関数によって定義されたデータエレメントが記述されている。もちろん、先に説明したｉｆ文の条件が真とならない場合には、 ｇｒｏｕｐ＿ｏｆ＿ｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）関数およびｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（１）関数によって定義されているデータエレメントは記述されていないので、 ｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（０）関数によって定義されているデータエレメントの次に、ｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）関数、ｐｉｃｔｕｒｅ＿ｃｏｄｉｎｇ＿ｅｘｔｅｎｓｉｏｎ（）関数およびｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（２）関数によって定義されたデータエレメントが記述されている。
【０１０２】
このｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）関数は、ＭＰＥＧ符号化ビットストリームのピクチャレイヤのヘッダデータを定義するための関数であって、ｐｉｃｔｕｒｅ＿ｃｏｄｉｎｇ＿ｅｘｔｅｎｓｉｏｎ（）関数は、ＭＰＥＧ符号化ビットストリームのピクチャレイヤの第１の拡張データを定義するための関数である。ｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（２）関数は、ＭＰＥＧ符号化ビットストリームのピクチャレイヤの拡張データおよびユーザデータを定義するための関数である。このｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（２）関数によって定義されるユーザデータは、ピクチャレイヤに記述されているデータであって、各ピクチャ毎に記述することのできるデータである。
【０１０３】
符号化ビットストリームにおいて、ピクチャレイヤのユーザデータの次には、ｐｉｃｔｕｒｅ＿ｄａｔａ（）関数によって定義されるデータエレメントが記述されている。このｐｉｃｔｕｒｅ＿ｄａｔａ（）関数は、スライスレイヤおよびマクロブロックレイヤに関するデータエレメントを記述するための関数である。
【０１０４】
このｐｉｃｔｕｒｅ＿ｄａｔａ（）関数の次に記述されているｗｈｉｌｅ文は、このｗｈｉｌｅ文によって定義されている条件が真である間、次のｉｆ文の条件判断を行うための関数である。このｗｈｉｌｅ文において使用されているｎｅｘｔｂｉｔｓ（）関数は、符号化ビットストリーム中に、ｐｉｃｔｕｒｅ＿ｓｔａｒｔ＿ｃｏｄｅ又はｇｒｏｕｐ＿ｓｔａｒｔ＿ｃｏｄｅが記述されているか否かを判断するための関数であって、ビットストリーム中にｐｉｃｔｕｒｅ＿ｓｔａｒｔ＿ｃｏｄｅ又はｇｒｏｕｐ＿ｓｔａｒｔ＿ｃｏｄｅが記述されている場合には、このｗｈｉｌｅ文によって定義された条件が真となる。
【０１０５】
次のｉｆ文は、符号化ビットストリーム中にｓｅｑｕｅｎｃｅ＿ｅｎｄ＿ｃｏｄｅ が記述されているか否かを判断するための条件文であって、ｓｅｑｕｅｎｃｅ＿ｅｎｄ＿ｃｏｄｅ が記述されていないのであれば、ｓｅｑｕｅｎｃｅ＿ｈｅａｄｅｒ（）関数とｓｅｑｕｅｎｃｅ＿ｅｘｔｅｎｓｉｏｎ（）関数とによって定義されたデータエレメントが記述されていることを示している。ｓｅｑｕｅｎｃｅ＿ｅｎｄ＿ｃｏｄｅは符号化ビデオストリームのシーケンスの終わりを示すコードであるので、符号化ストリームが終了しない限り、符号化ストリーム中にはｓｅｑｕｅｎｃｅ＿ｈｅａｄｅｒ（）関数とｓｅｑｕｅｎｃｅ＿ｅｘｔｅｎｓｉｏｎ（）関数とによって定義されたデータエレメントが記述されている。
【０１０６】
このｓｅｑｕｅｎｃｅ＿ｈｅａｄｅｒ（）関数とｓｅｑｕｅｎｃｅ＿ｅｘｔｅｎｓｉｏｎ（）関数によって記述されたデータエレメントは、ビデオストリームのシーケンスの先頭に記述されたｓｅｑｕｅｎｃｅ＿ｈｅａｄｅｒ（）関数とｓｅｑｕｅｎｃｅ＿ｅｘｔｅｎｓｉｏｎ（）関数によって記述されたデータエレメントと全く同じである。このように同じデータをストリーム中に記述する理由は、ビットストリーム受信装置側でデータストリームの途中（例えばピクチャレイヤに対応するビットストリーム部分）から受信が開始された場合に、シーケンスレイヤのデータを受信できなくなり、ストリームをデコード出来なくなることを防止するためである。
【０１０７】
この最後のｓｅｑｕｅｎｃｅ＿ｈｅａｄｅｒ（）関数とｓｅｑｕｅｎｃｅ＿ｅｘｔｅｎｓｉｏｎ（）関数とによって定義されたデータエレメントの次、つまり、データストリームの最後には、シーケンスの終わりを示す２ビットのｓｅｑｕｅｎｃｅ＿ｅｎｄ＿ｃｏｄｅが記述されている。
【０１０８】
以下に、ｓｅｑｕｅｎｃｅ＿ｈｅａｄｅｒ（）関数、ｓｅｑｕｅｎｃｅ＿ｅｘｔｅｎｓｉｏｎ（）関数、ｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（０）関数、ｇｒｏｕｐ＿ｏｆ＿ｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）関数、ｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）関数、ｐｉｃｔｕｒｅ＿ｃｏｄｉｎｇ＿ｅｘｔｅｎｓｉｏｎ（）関数、およびｐｉｃｔｕｒｅ＿ｄａｔａ（）関数について詳細に説明する。
【０１０９】
図２４は、ｓｅｑｕｅｎｃｅ＿ｈｅａｄｅｒ（）関数のシンタックスを説明するための図である。このｓｅｑｕｅｎｃｅ＿ｈｅａｄｅｒ（）関数によって定義されたデータエレメントは、ｓｅｑｕｅｎｃｅ＿ｈｅａｄｅｒ＿ｃｏｄｅ、ｈｏｒｉｚｏｎｔａｌ＿ｓｉｚｅ＿ｖａｌｕｅ、ｖｅｒｔｉｃａｌ＿ｓｉｚｅ＿ｖａｌｕｅ、ａｓｐｅｃｔ＿ｒａｔｉｏ＿ｉｎｆｏｒｍａｔｉｏｎ、ｆｒａｍｅ＿ｒａｔｅ＿ｃｏｄｅ、ｂｉｔ＿ｒａｔｅ＿ｖａｌｕｅ、ｍａｒｋｅｒ＿ｂｉｔ、ｖｂｖ＿ｂｕｆｆｅｒ＿ｓｉｚｅ＿ｖａｌｕｅ、ｃｏｎｓｔｒａｉｎｅｄ＿ｐａｒａｍｅｔｅｒ＿ｆｌａｇ、ｌｏａｄ＿ｉｎｔｒａ＿ｑｕａｎｔｉｚｅｒ＿ｍａｔｒｉｘ、ｉｎｔｒａ＿ｑｕａｎｔｉｚｅｒ＿ｍａｔｒｉｘ［６４］、ｌｏａｄ＿ｎｏｎ＿ｉｎｔｒａ＿ｑｕａｎｔｉｚｅｒ＿ｍａｔｒｉｘ、およびｎｏｎ＿ｉｎｔｒａ＿ｑｕａｎｔｉｚｅｒ＿ｍａｔｒｉｘ等である。
【０１１０】
ｓｅｑｕｅｎｃｅ＿ｈｅａｄｅｒ＿ｃｏｄｅは、シーケンスレイヤのスタート同期コードを表すデータである。ｈｏｒｉｚｏｎｔａｌ＿ｓｉｚｅ＿ｖａｌｕｅは、画像の水平方向の画素数の下位１２ビットから成るデータである。ｖｅｒｔｉｃａｌ＿ｓｉｚｅ＿ｖａｌｕｅは、画像の縦のライン数の下位１２ビットからなるデータである。ａｓｐｅｃｔ＿ｒａｔｉｏ＿ｉｎｆｏｒｍａｔｉｏｎは、画素のアスペクト比（縦横比）または表示画面アスペクト比を表すデータである。ｆｒａｍｅ＿ｒａｔｅ＿ｃｏｄｅは、画像の表示周期を表すデータである。ｂｉｔ＿ｒａｔｅ＿ｖａｌｕｅは、発生ビット量に対する制限のためのビット・レートの下位１８ビット（４００ｂｓｐ単位で切り上げる）データである。ｍａｒｋｅｒ＿ｂｉｔは、スタートコードエミュレーションを防止するために挿入されるビットデータである。ｖｂｖ＿ｂｕｆｆｅｒ＿ｓｉｚｅ＿ｖａｌｕｅは、発生符号量制御用の仮想バッファ（ビデオバッファベリファイヤー）の大きさを決める値の下位１０ビットデータである。ｃｏｎｓｔｒａｉｎｅｄ＿ｐａｒａｍｅｔｅｒ＿ｆｌａｇは、各パラメータが制限以内であることを示すデータである。ｌｏａｄ＿ｉｎｔｒａ＿ｑｕａｎｔｉｚｅｒ＿ｍａｔｒｉｘは、イントラＭＢ用量子化マトリックス・データの存在を示すデータである。ｉｎｔｒａ＿ｑｕａｎｔｉｚｅｒ＿ｍａｔｒｉｘ［６４］は、イントラＭＢ用量子化マトリックスの値を示すデータである。ｌｏａｄ＿ｎｏｎ＿ｉｎｔｒａ＿ｑｕａｎｔｉｚｅｒ＿ｍａｔｒｉｘは、非イントラＭＢ用量子化マトリックス・データの存在を示すデータである。ｎｏｎ＿ｉｎｔｒａ＿ｑｕａｎｔｉｚｅｒ＿ｍａｔｒｉｘは、非イントラＭＢ用量子化マトリックスの値を表すデータである。
【０１１１】
図２５はｓｅｑｕｅｎｃｅ＿ｅｘｔｅｎｓｉｏｎ（）関数のシンタックスを説明するための図である。このｓｅｑｕｅｎｃｅ＿ｅｘｔｅｎｓｉｏｎ（）関数によって定義されたデータエレメントとは、ｅｘｔｅｎｓｉｏｎ＿ｓｔａｒｔ＿ｃｏｄｅ、ｅｘｔｅｎｓｉｏｎ＿ｓｔａｒｔ＿ｃｏｄｅ＿ｉｄｅｎｔｉｆｉｅｒ、ｐｒｏｆｉｌｅ＿ａｎｄ＿ｌｅｖｅｌ＿ｉｎｄｉｃａｔｉｏｎ、ｐｒｏｇｒｅｓｓｉｖｅ＿ｓｅｑｕｅｎｃｅ、ｃｈｒｏｍａ＿ｆｏｒｍａｔ、ｈｏｒｉｚｏｎｔａｌ＿ｓｉｚｅ＿ｅｘｔｅｎｓｉｏｎ、ｖｅｒｔｉｃａｌ＿ｓｉｚｅ＿ｅｘｔｅｎｓｉｏｎ、ｂｉｔ＿ｒａｔｅ＿ｅｘｔｅｎｓｉｏｎ、ｖｂｖ＿ｂｕｆｆｅｒ＿ｓｉｚｅ＿ｅｘｔｅｎｓｉｏｎ、ｌｏｗ＿ｄｅｌａｙ、ｆｒａｍｅ＿ｒａｔｅ＿ｅｘｔｅｎｓｉｏｎ＿ｎ 、および ｆｒａｍｅ＿ｒａｔｅ＿ｅｘｔｅｎｓｉｏｎ＿ｄ等のデータエレメントである。
【０１１２】
ｅｘｔｅｎｓｉｏｎ＿ｓｔａｒｔ＿ｃｏｄｅは、エクステンションデータのスタート同期コードを表すデータである。ｅｘｔｅｎｓｉｏｎ＿ｓｔａｒｔ＿ｃｏｄｅ＿ｉｄｅｎｔｉｆｉｅｒは、どの拡張データが送られるかを示すデータである。ｐｒｏｆｉｌｅ＿ａｎｄ＿ｌｅｖｅｌ＿ｉｎｄｉｃａｔｉｏｎは、ビデオデータのプロファイルとレベルを指定するためのデータである。ｐｒｏｇｒｅｓｓｉｖｅ＿ｓｅｑｕｅｎｃｅは、ビデオデータが順次走査であることを示すデータである。ｃｈｒｏｍａ＿ｆｏｒｍａｔは、ビデオデータの色差フォーマットを指定するためのデータである。ｈｏｒｉｚｏｎｔａｌ＿ｓｉｚｅ＿ｅｘｔｅｎｓｉｏｎは、シーケンスヘッダのｈｏｒｉｚｎｔａｌ＿ｓｉｚｅ＿ｖａｌｕｅに加える上位２ビットのデータである。ｖｅｒｔｉｃａｌ＿ｓｉｚｅ＿ｅｘｔｅｎｓｉｏｎは、シーケンスヘッダのｖｅｒｔｉｃａｌ＿ｓｉｚｅ＿ｖａｌｕｅ加える上位２ビットのデータである。ｂｉｔ＿ｒａｔｅ＿ｅｘｔｅｎｓｉｏｎは、シーケンスヘッダのｂｉｔ＿ｒａｔｅ＿ｖａｌｕｅに加える上位１２ビットのデータである。ｖｂｖ＿ｂｕｆｆｅｒ＿ｓｉｚｅ＿ｅｘｔｅｎｓｉｏｎは、シーケンスヘッダのｖｂｖ＿ｂｕｆｆｅｒ＿ｓｉｚｅ＿ｖａｌｕｅに加える上位８ビットのデータである。ｌｏｗ＿ｄｅｌａｙは、Ｂピクチャを含まないことを示すデータである。ｆｒａｍｅ＿ｒａｔｅ＿ｅｘｔｅｎｓｉｏｎ＿ｎは、シーケンスヘッダのｆｒａｍｅ＿ｒａｔｅ＿ｃｏｄｅと組み合わせてフレームレートを得るためのデータである。ｆｒａｍｅ＿ｒａｔｅ＿ｅｘｔｅｎｓｉｏｎ＿ｄは、シーケンスヘッダのｆｒａｍｅ＿ｒａｔｅ＿ｃｏｄｅと組み合わせてフレームレートを得るためのデータである。
【０１１３】
図２６は、ｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（ｉ）関数のシンタックスを説明するための図である。このｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（ｉ）関数は、「ｉ」が１以外のときは、ｅｘｔｅｎｓｉｏｎ＿ｄａｔａ（）関数によって定義されるデータエレメントは記述せずに、ｕｓｅｒ＿ｄａｔａ（）関数によって定義されるデータエレメントのみを記述する。よって、ｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（０）関数は、ｕｓｅｒ＿ｄａｔａ（）関数によって定義されるデータエレメントのみを記述する。
【０１１４】
まず、図２６に示されているシンタックスにおいて使用されている関数について説明する。ｎｅｘｔｂｉｔｓ（）関数は、ビットストリーム中に現れるビットまたはビット列と、次に復号されるデータエレメントとを比較するための関数である。
【０１１５】
ｕｓｅｒ＿ｄａｔａ（）関数は、図２７に示すように、ｕｓｅｒ＿ｄａｔａ＿ｓｔａｒｔ＿ｃｏｄｅ，Ｖ−ｐｈａｓｅ（）関数，Ｈ−ｐｈａｓｅ（）関数，Ｔｉｍｅ＿ｃｏｄｅ（）関数，Ｐｉｃｔｕｒｅ−ｏｒｄｅｒ（）関数，Ａｎｃｉｌｌａｒｙ＿ｄａｔａ（）関数，ｈｉｓｔｏｒｙ＿ｄａｔａ（）関数，およびｕｓｅｒ＿ｄａｔａのデータエレメントを記述するための関数である。
【０１１６】
ｕｓｅｒ＿ｄａｔａ＿ｓｔａｒｔ＿ｃｏｄｅは、ＭＰＥＧ方式のビットストリームのピクチャレイヤのユーザデータエリアの開始を示すためのスタートコードである。このｕｓｅｒ＿ｄａｔａ＿ｓｔａｒｔ＿ｃｏｄｅの次に記述されているｉｆ文は、ｕｓｅｒ＿ｄａｔａ（ｉ）関数のｉが”０”のとき、次に記述されているｗｈｉｌｅ構文を実行する。このｗｈｉｌｅ構文は、ビットストリーム中に、２３個の”０”とそれに続く”１”から構成される２４ビットのデータが現れない限り真となる。
【０１１７】
この２３個の”０”とそれに続く”１”から構成される２４ビットのデータは、すべてのスタートコードの先頭に付与されるデータであって、すべてのスタートコードは、この２４ビットの後ろに設けられることによって、ｎｅｘｔｂｉｔｓ（）関数は、ビットストリーム中において、各スタートコードの位置を見つけることができる。
【０１１８】
ｗｈｉｌｅ構文が真のとき、その次に記述されているｉｆ文のｎｅｘｔｂｉｔｓ（）関数は、Ｖ−Ｐｈａｓｅを示すビット列（Ｄａｔａ＿ＩＤ）を検出すると、そのビット列（Ｄａｔａ＿ＩＤ）の次ビットからＶ−Ｐｈａｓｅ（）関数で示されるＶ−Ｐｈａｓｅのデータエレメントが記述されていることを知る。次のＥｌｓｅ ｉｆ文のｎｅｘｔｂｉｔｓ（）関数は、Ｈ−Ｐｈａｓｅを示すビット列（Ｄａｔａ＿ＩＤ）を検出すると、そのビット列（Ｄａｔａ＿ＩＤ）の次ビットからＨ−Ｐｈａｓｅ（）関数で示されるＨ−Ｐｈａｓｅのデータエレメントが記述されていることを知る。
【０１１９】
ここで、図２８に示すように、Ｖ−ＰｈａｓｅのＤａｔａ＿ＩＤは、”０１”を表すビット列であり、Ｈ−ＰｈａｓｅのＤａｔａ＿ＩＤは、”０２”を表すビット列である。
【０１２０】
ビットストリームに記述されるＶ−Ｐｈａｓｅ（）関数のシンタックスについて、図２９を参照して説明する。まず、Ｄａｔａ＿ＩＤは、前述したように、そのＤａｔａ＿ＩＤの次のビット列のデータエレメントがＶ−Ｐｈａｓｅであることを表す８ビットのデータであり、図２８で示した値”０１”である。Ｖ−Ｐｈａｓｅは、画像信号のフレームにおいて、符号化される最初のラインを示す１６ビットのデータである。
【０１２１】
ビットストリームに記述されるＨ−Ｐｈａｓｅ（）関数のシンタックスについて、図３０を参照して説明する。まず、Ｄａｔａ＿ＩＤは、前述したように、そのＤａｔａ＿ＩＤの次のビット列のデータエレメントがＨ−Ｐｈａｓｅであることを表す８ビットのデータであり、図２８で示した値”０２”である。Ｈ−Ｐｈａｓｅは、画像信号フレームにおいて、符号化される最初のサンプルを示す８ビットのデータである。
【０１２２】
図２７に戻って、次のＥｌｓｅ ｉｆ文は、ｕｓｅｒ＿ｄａｔａ（ｉ）関数のｉが２のとき、次に記述されているｗｈｉｌｅ構文を実行する。ｗｈｉｌｅ構文の内容は前述した場合と同様であるので、ここではその説明を省略する。
【０１２３】
ｗｈｉｌｅ構文が真のとき、次のｉｆ文において、ｎｅｘｔｂｉｔｓ（）関数は、Ｔｉｍｅ ｃｏｄｅ１を示すビット列を検出するか、または、Ｔｉｍｅ ｃｏｄｅ２を示すビット列を検出すると、そのビット列の次ビットからＴｉｍｅ＿ｃｏｄｅ（）関数で示されるＴｉｍｅ ｃｏｄｅのデータエレメントが記述されていることを知る。
【０１２４】
Ｔｉｍｅ ｃｏｄｅ１のＤａｔａ＿ＩＤは、図２８に示すように、”０３”を表すビット列であり、Ｔｉｍｅ ｃｏｄｅ１のデータは、画像の垂直ブランキング期間に挿入されたタイムコードを示す、ＶＩＴＣ（Ｖｅｒｔｉｃａｌ Ｉｎｔｅｒｖａｌ Ｔｉｍｅ Ｃｏｄｅ）である。Ｔｉｍｅ ｃｏｄｅ２のＤａｔａ＿ＩＤは、図２８に示すように、”０４”を表すビット列であり、Ｔｉｍｅ ｃｏｄｅ２のデータは、記録媒体のタイムコードトラックに記録されたタイムコードを示す、ＬＴＣ（Ｌｏｎｇｉｔｕｄｉｎａｌ Ｔｉｍｅ Ｃｏｄｅ）である。
【０１２５】
次に、Ｅｌｓｅ ｉｆ文において、ｎｅｘｔｂｉｔｓ（）関数は、Ｐｉｃｔｕｒｅ Ｏｒｄｅｒを示すビット列を検出すると、そのビット列の次ビットからＰｉｃｔｕｒｅ＿Ｏｒｄｅｒ（）関数で示されるＰｉｃｔｕｒｅ Ｏｒｄｅｒのデータエレメントが記述されていることを知る。ここで、Ｐｉｃｔｕｒｅ＿Ｏｒｄｅｒ（）関数のＤａｔａ＿ＩＤは、図２８に示すように、”０５”を表すビット列である。
【０１２６】
実際に、エンコーダでエレメンタリストリーム（ＥＳ）に挿入するＰｉｃｔｕｒｅ＿Ｏｒｄｅｒ（）関数のシンタックスを、図３１を参照して説明する。まず、Ｄａｔａ＿ＩＤは前述したように、そのＤａｔａ＿ＩＤ以降のデータがＰＯＩのデータであることを示す８ビットのデータであり、その値は”０５”である。ＤＴＳ＿ｐｒｅｓｅｎｃｅは、符号化順序ＤＴＳ＿ｃｏｕｎｔｅｒの有無を表す１ビットのデータである。例えば、ＢピクチャのようにＤＴＳ＿ｃｏｕｎｔｅｒ＝ＰＴＳ＿ｃｏｕｎｔｅｒとなる場合、表示順序ＰＴＳ＿ｃｏｕｎｔｅｒのみが存在し、ＤＴＳ＿ｐｒｅｓｅｎｃｅのビットは”０”となる。逆に、ＰピクチャおよびＩピクチャの場合、符号化順序ＤＴＳ＿ｃｏｕｎｔｅｒと表示順序ＰＴＳ＿ｃｏｕｎｔｅｒは同一ではないので、表示順序ＰＴＳ＿ｃｏｕｎｔｅｒと符号化順序ＤＴＳ＿ｃｏｕｎｔｅｒの双方が存在し、ＤＴＳ＿ｐｒｅｓｅｎｃｅのビットは１となる。
【０１２７】
ＰＴＳ＿ｃｏｕｎｔｅｒは、エンコーダに符号化フレーム中の１フィールドが入力されるごとにカウントアップを行う、表示順序を表す７ビットのデータである。この７ビットのデータは、０から１２７までの値をとるモジュロである。ｉｆ文以降は、ＤＴＳ＿ｐｒｅｓｅｎｃｅのビットが１のとき、すなわち、ＰピクチャおよびＩピクチャのとき、ＤＴＳ＿ｃｏｕｎｔｅｒのカウントアップが実行される。
【０１２８】
Ｍａｒｋｅｒ＿ｂｉｔｓは、ｕｓｅｒ ｄａｔａの記述されたビット列が、偶然に前述したスタートコードと一致し、画像破錠を引き起こす可能正が高い、スタートコードエミュレーションを防止するために、１６ビットごとに挿入されるビットである。
【０１２９】
ＤＴＳ＿ｃｏｕｎｔｅｒは、エンコーダで、１フィールド分の符号化画像データが符号化されるごとにカウントアップを行う、符号化順序を表す７ビットのデータである。この７ビットのデータは、０から１２７までの値をとるモジュロである。
【０１３０】
前述したように、表示順序ＰＴＳ＿ｃｏｕｎｔｅｒは、フィールド単位で付番されるために、例えば、符号化画像データを２４Ｈｚから３０Ｈｚのフレームレートに変換して符号化する場合、３−２プルダウン処理を行った後に、付番する必要がある。
【０１３１】
図２７に戻って、その次に記述されているｗｈｉｌｅ構文も、内容は前述した場合と同様であるので、ここではその説明を省略する。ｗｈｉｌｅ構文が真のとき、次のｉｆ文において、ｎｅｘｔｂｉｔｓ（）関数は、Ａｎｃｉｌｌａｒｙ ｄａｔａを示すビット列を検出すると、そのビット列の次ビットからＡｎｃｉｌｌａｒｙ＿ｄａｔａ（）関数で示されるＡｎｃｉｌｌａｒｙ ｄａｔａのデータエレメントが記述されていることを知る。Ａｎｃｉｌｌａｒｙ＿ｄａｔａ（）関数のＤａｔａ＿ＩＤは、図２８に示すように、”０７”を表すビット列である。
【０１３２】
この補助データに識別子を付加するａｎｃｉｌｌａｒｙ ｄａｔａのシンタックスを図３２を参照して説明する。Ａｎｃｉｌｌａｒｙ＿ｄａｔａ（）関数はピクチャ層のｕｓｅｒ ｄａｔａとして伝送され、データとしてはＦｉｅｌｄ識別子（Ｆｉｅｌｄ＿ＩＤ）、ラインの番号（Ｌｉｎｅ＿ｎｕｍｂｅｒ）および補如データ（ａｎｃｉｌｌａｒｙ ｄａｔａ）が挿入される。
【０１３３】
Ｄａｔａ＿ＩＤは、ｕｓｅｒ ｄａｔａ領域において、ａｎｃｉｌｌａｒｙ ｄａｔａであることを示す８ビットのデータであり、その値は図２８に示したように”０７”である。
【０１３４】
Ｆｉｅｌｄ＿ＩＤは２ビットのデータであり、ｐｒｏｇｒｅｓｓｉｖｅ＿ｓｅｑｕｅｎｃｅ ｆｌａｇ（図２５）の値が”０”のとき、符号化フレーム内のフィールドごとにＦｉｅｌｄ＿ＩＤが付加される。ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄに”０”が設定されているとき、この符号化フレームにはフィールドが２枚存在し、Ｆｉｅｌｄ＿ＩＤは、図１９に示したように、最初のフィールドに”０”、およびその次のフィールドに”１”が設定され、ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄに”１”が設定されているとき、この符号化フレームにはフィールドが３枚存在し、Ｆｉｅｌｄ＿ＩＤとしては、最初のフィールドに”０”が設定され、それ以降のフィールドに”１”，”２”が設定される。
【０１３５】
Ｆｉｅｌｄ＿ＩＤは、ｐｒｏｇｒｅｓｓｉｖｅ＿ｓｅｑｕｅｎｃｅ ｆｌａｇの値が”１”のとき、符号化フレームごとに付加される。Ｆｉｅｌｄ＿ＩＤには、ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄとＴｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔにともに”０”が設定されているとき、その符号化フレームは１枚のｐｒｏｇｒｅｓｓｉｖｅ ｆｒａｍｅが存在するので、値”０”が設定され、ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄに値”１”およびＴｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔに値”０”が設定されているとき、その符号化フレームは２枚のｐｒｏｇｒｅｓｓｉｖｅ ｆｒａｍｅが存在するので、値”０”，”１”が設定され、ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄとＴｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔにともに”１”が設定されているとき、その符号化フレームは３枚のｐｒｏｇｒｅｓｓｉｖｅ ｆｒａｍｅが存在するので、値”０”乃至”２”が設定される。
【０１３６】
Ｌｉｎｅ＿ｎｕｍｂｅｒは、１４ビットのデータであり、各フレームにおける補助データが記述されている、ＩＴＵ−Ｒ ＢＴ．６５６−３，ＳＭＰＴＥ２７４Ｍ，ＳＭＰＴＥ２９３Ｍ，ＳＭＰＴＥ２９６Ｍで規定されたライン番号を示す。
【０１３７】
Ａｎｃｉｌｌａｒｙ＿ｄａｔａ＿ｌｅｎｇｔｈは、１６ビットのデータであり、ａｎｃｉｌｌａｒｙ＿ｄａｔａ＿ｐａｙｌｏａｄのデータ長を示す。Ａｎｃｉｌｌａｒｙ＿ｄａｔａ＿ｐａｙｌｏａｄは、２２ビットのデータからなる補助データの内容を表しており、Ａｎｃｉｌｌａｒｙ＿ｄａｔａ＿ｐａｙｌｏａｄのＡｎｃｉｌｌａｒｙ＿ｄａｔａ＿ｌｅｎｇｔｈの値がｊの値（初期値０）より大きいとき、値ｊ（Ａｎｃｉｌｌａｒｙ＿ｄａｔａ＿ｌｅｎｇｔｈのデータ長）を１だけインクリメントして、そのｊの値のビット列目から記述される。
【０１３８】
次のＷｈｉｌｅ構文は、ｂｙｔｅａｌｉｇｎｅｄ（）関数のためのシンタックスを表しており、次のデータがｂｙｔｅａｌｉｇｎｅｄ（）関数でないとき（Ｗｈｉｌｅ構文が真のとき）、Ｚｅｒｏ＿ｂｉｔ（１ビットのデータ”０”）を記述する。
【０１３９】
図２７に戻って、次のＥｌｓｅ ｉｆ文において、ｎｅｘｔｂｉｔｓ（）関数は、Ｈｉｓｔｏｒｙ ｄａｔａを示すビット列を検出すると、そのビット列の次ビットからＨｉｓｔｏｒｙ＿ｄａｔａ（）関数で示されるＨｉｓｔｏｒｙ ｄａｔａのデータエレメントが記述されていることを知る。Ｈｉｓｔｏｒｙ＿ｄａｔａ（）関数のＤａｔａ＿ＩＤは、図２８に示すように、”０８”を表すビット列であり、Ｄａｔａ＿ＩＤが”０８”で示されるデータは、符号化パラメータの履歴情報を含むＨｉｓｔｏｒｙ ｄａｔａを表している。
【０１４０】
最後のｉｆ文において、ｎｅｘｔｂｉｔｓ（）関数は、ｕｓｅｒ ｄａｔａを示すビット列を検出すると、そのビット列の次ビットからｕｓｅｒ＿ｄａｔａ（）関数で示されるｕｓｅｒ＿ｄａｔａのデータエレメントが記述されていることを知る。
【０１４１】
図２７のｎｅｘｔｂｉｔｓ（）関数が、それぞれのデータエレメントが記述されていることを知るビット列は、図２８に示すＤａｔａ＿ＩＤとして記述されている。ただし、Ｄａｔａ＿ＩＤとして”００”を使用することは禁止されている。Ｄａｔａ＿ＩＤが”８０”で示されるデータは、制御フラグを表しており、Ｄａｔａ＿ＩＤが”ＦＦ”で示されるデータは、ｕｓｅｒ ｄａｔａを表している。
【０１４２】
図３３は、ｇｒｏｕｐ＿ｏｆ＿ｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）関数のシンタックスを説明するための図である。このｇｒｏｕｐ＿ｏｆ＿ｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）関数によって定義されたデータエレメントは、ｇｒｏｕｐ＿ｓｔａｒｔ＿ｃｏｄｅ、ｔｉｍｅ＿ｃｏｄｅ、ｃｌｏｓｅｄ＿ｇｏｐ、およびｂｒｏｋｅｎ＿ｌｉｎｋから構成される。
【０１４３】
ｇｒｏｕｐ＿ｓｔａｒｔ＿ｃｏｄｅは、ＧＯＰレイヤの開始同期コードを示すデータである。ｔｉｍｅ＿ｃｏｄｅは、ＧＯＰの先頭ピクチャのシーケンスの先頭からの時間を示すタイムコードである。ｃｌｏｓｅｄ＿ｇｏｐは、ＧＯＰ内の画像が他のＧＯＰから独立再生可能なことを示すフラグデータである。ｂｒｏｋｅｎ＿ｌｉｎｋは、編集などのためにＧＯＰ内の先頭のＢピクチャが正確に再生できないことを示すフラグデータである。
【０１４４】
ｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（１）関数は、 ｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（０）関数と同じように、ｕｓｅｒ＿ｄａｔａ（）関数によって定義されるデータエレメントのみを記述するための関数である。
【０１４５】
次に、図３４乃至図３６を参照して、符号化ストリームのピクチャレイヤに関するデータエレメントを記述するためのｐｉｃｔｕｒｅ＿ｈｅａｄｒ（）関数、ｐｉｃｔｕｒｅ＿ｃｏｄｉｎｇ＿ｅｘｔｅｎｓｉｏｎ（）関数、およびｐｉｃｔｕｒｅ＿ｄａｔａ（）について説明する。
【０１４６】
図３４はｐｉｃｔｕｒｅ＿ｈｅａｄｒ（）関数のシンタックスを説明するための図である。このｐｉｃｔｕｒｅ＿ｈｅａｄｒ（）関数によって定義されたデータエレメントは、ｐｉｃｔｕｒｅ＿ｓｔａｒｔ＿ｃｏｄｅ、ｔｅｍｐｏｒａｌ＿ｒｅｆｅｒｅｎｃｅ、ｐｉｃｔｕｒｅ＿ｃｏｄｉｎｇ＿ｔｙｐｅ、ｖｂｖ＿ｄｅｌａｙ、ｆｕｌｌ＿ｐｅｌ＿ｆｏｒｗａｒｄ＿ｖｅｃｔｏｒ、ｆｏｒｗａｒｄ＿ｆ＿ｃｏｄｅ、ｆｕｌｌ＿ｐｅｌ＿ｂａｃｋｗａｒｄ＿ｖｅｃｔｏｒ、ｂａｃｋｗａｒｄ＿ｆ＿ｃｏｄｅ、ｅｘｔｒａ＿ｂｉｔ＿ｐｉｃｔｕｒｅ、およびｅｘｔｒａ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｐｉｃｔｕｒｅである。
【０１４７】
具体的には、ｐｉｃｔｕｒｅ＿ｓｔａｒｔ＿ｃｏｄｅは、ピクチャレイヤの開始同期コードを表すデータである。ｔｅｍｐｏｒａｌ＿ｒｅｆｅｒｅｎｃｅは、ピクチャの表示順を示す番号で、ＧＯＰの先頭でリセットされるデータである。ｐｉｃｔｕｒｅ＿ｃｏｄｉｎｇ＿ｔｙｐｅは、ピクチャタイプを示すデータである。
【０１４８】
ｖｂｖ＿ｄｅｌａｙは、ＶＢＶバッファの初期状態を示すデータであって、各ピクチャ毎に設定されている。送信側システムから受信側システムに伝送された符号化エレメンタリストリームのピクチャは、受信側システムに設けられたＶＢＶバッファにバッファリングされ、ＤＴＳ（Ｄｅｃｏｄｉｎｇ Ｔｉｍｅ Ｓｔａｍｐ）によって指定された時刻に、このＶＢＶバッファから引き出され（読み出され）、デコーダに供給される。ｖｂｖ＿ｄｅｌａｙによって定義される時間は、復号化対象のピクチャがＶＢＶバッファにバッファリングされ始めてから、符号化対象のピクチャがＶＢＶバッファから引き出されるまでの時間、つまりＤＴＳによって指定された時刻までの時間を意味する。このピクチャヘッダに格納されたｖｂｖ＿ｄｅｌａｙを使用することによって、ＶＢＶバッファのデータ占有量が不連続にならないシームレスなスプライシングが実現できる。
【０１４９】
ｆｕｌｌ＿ｐｅｌ＿ｆｏｒｗａｒｄ＿ｖｅｃｔｏｒは、順方向動きベクトルの精度が整数単位か半画素単位かを示すデータである。ｆｏｒｗａｒｄ＿ｆ＿ｃｏｄｅは、順方向動きベクトル探索範囲を表すデータである。ｆｕｌｌ＿ｐｅｌ＿ｂａｃｋｗａｒｄ＿ｖｅｃｔｏｒは、逆方向動きベクトルの精度が整数単位か半画素単位かを示すデータである。ｂａｃｋｗａｒｄ＿ｆ＿ｃｏｄｅは、逆方向動きベクトル探索範囲を表すデータである。ｅｘｔｒａ＿ｂｉｔ＿ｐｉｃｔｕｒｅは、後続する追加情報の存在を示すフラグである。このｅｘｔｒａ＿ｂｉｔ＿ｐｉｃｔｕｒｅが「１」の場合には、次にｅｘｔｒａ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｐｉｃｔｕｒｅが存在し、ｅｘｔｒａ＿ｂｉｔ＿ｐｉｃｔｕｒｅが「０」の場合には、これに続くデータが無いことを示している。ｅｘｔｒａ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｐｉｃｔｕｒｅは、規格において予約された情報である。
【０１５０】
図３５は、ｐｉｃｔｕｒｅ＿ｃｏｄｉｎｇ＿ｅｘｔｅｎｓｉｏｎ（）関数のシンタックスを説明するための図である。このｐｉｃｔｕｒｅ＿ｃｏｄｉｎｇ＿ｅｘｔｅｎｓｉｏｎ（）関数によって定義されたデータエレメントは、ｅｘｔｅｎｓｉｏｎ＿ｓｔａｒｔ＿ｃｏｄｅ、ｅｘｔｅｎｓｉｏｎ＿ｓｔａｒｔ＿ｃｏｄｅ＿ｉｄｅｎｔｉｆｉｅｒ、ｆ＿ｃｏｄｅ［０］［０］、ｆ＿ｃｏｄｅ［０］［１］、ｆ＿ｃｏｄｅ［１］［０］、ｆ＿ｃｏｄｅ［１］［１］、ｉｎｔｒａ＿ｄｃ＿ｐｒｅｃｉｓｉｏｎ、ｐｉｃｔｕｒｅ＿ｓｔｒｕｃｔｕｒｅ、ｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔ、ｆｒａｍｅ＿ｐｒｅｄｉｃｔｉｖｅ＿ｆｒａｍｅ＿ｄｃｔ、ｃｏｎｃｅａｌｍｅｎｔ＿ｍｏｔｉｏｎ＿ｖｅｃｔｏｒｓ、ｑ＿ｓｃａｌｅ＿ｔｙｐｅ、ｉｎｔｒａ＿ｖｌｃ＿ｆｏｒｍａｔ、ａｌｔｅｒｎａｔｅ＿ｓｃａｎ、ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄ、ｃｈｒｏｍａ＿４２０＿ｔｙｐｅ、ｐｒｏｇｒｅｓｓｉｖｅ＿ｆｒａｍｅ、ｃｏｍｐｏｓｉｔｅ＿ｄｉｓｐｌａｙ＿ｆｌａｇ、ｖ＿ａｘｉｓ、ｆｉｅｌｄ＿ｓｅｑｕｅｎｃｅ、ｓｕｂ＿ｃａｒｒｉｅｒ、ｂｕｒｓｔ＿ａｍｐｌｉｔｕｄｅ、およびｓｕｂ＿ｃａｒｒｉｅｒ＿ｐｈａｓｅから構成される。
【０１５１】
ｅｘｔｅｎｓｉｏｎ＿ｓｔａｒｔ＿ｃｏｄｅは、ピクチャレイヤのエクステンションデータのスタートを示す開始コードである。ｅｘｔｅｎｓｉｏｎ＿ｓｔａｒｔ＿ｃｏｄｅ＿ｉｄｅｎｔｉｆｉｅｒは、どの拡張データが送られるかを示すコードである。ｆ＿ｃｏｄｅ［０］［０］は、フォアード方向の水平動きベクトル探索範囲を表すデータである。ｆ＿ｃｏｄｅ［０］［１］は、フォアード方向の垂直動きベクトル探索範囲を表すデータである。ｆ＿ｃｏｄｅ［１］［０］は、バックワード方向の水平動きベクトル探索範囲を表すデータである。ｆ＿ｃｏｄｅ［１］［１］は、バックワード方向の垂直動きベクトル探索範囲を表すデータである。ｉｎｔｒａ＿ｄｃ＿ｐｒｅｃｉｓｉｏｎは、ＤＣ係数の精度を表すデータである。ｐｉｃｔｕｒｅ＿ｓｔｒｕｃｔｕｒｅは、フレームストラクチャかフィールドストラクチャかを示すデータである。これは、フィールドストラクチャの場合は、上位フィールドか下位フィールドかもあわせて示す。
【０１５２】
ｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔは、フレームストラクチャの場合、最初のフィールドがトップフィールドであるのか、ボトムフィールドであるのかを示すフラグである。ｆｒａｍｅ＿ｐｒｅｄｉｃｔｉｖｅ＿ｆｒａｍｅ＿ｄｃｔは、フレーム・ストラクチャの場合、フレーム・モードＤＣＴの予測がフレーム・モードだけであることを示すデータである。ｃｏｎｃｅａｌｍｅｎｔ＿ｍｏｔｉｏｎ＿ｖｅｃｔｏｒｓは、イントラマクロブロックに伝送エラーを隠蔽するための動きベクトルがついていることを示すデータである。ｑ＿ｓｃａｌｅ＿ｔｙｐｅは、線形量子化スケールを利用するか、非線形量子化スケールを利用するかを示すデータである。ｉｎｔｒａ＿ｖｌｃ＿ｆｏｒｍａｔは、イントラマクロブロックに、別の２次元ＶＬＣ（可変長符号）を使うかどうかを示すデータである。ａｌｔｅｒｎａｔｅ＿ｓｃａｎは、ジグザグスキャンを使うか、オルタネート・スキャンを使うかの選択を表すデータである。
【０１５３】
ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄは、復号化時にリピートフィールドを生成するか否かを示すフラグであって、復号化時の処理において、ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄ が「１」の場合にはリピートフィールドを生成し、ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄが「０」の場合にはリピートフィールドを生成しないという処理が行われる。
【０１５４】
ｃｈｒｏｍａ＿４２０＿ｔｙｐｅは、信号フォーマットが４：２：０の場合、次のｐｒｏｇｒｅｓｓｉｖｅ＿ｆｒａｍｅ と同じ値、そうでない場合は０を表すデータである。ｐｒｏｇｒｅｓｓｉｖｅ＿ｆｒａｍｅは、そのピクチャが、順次走査できているかどうかを示すデータである。ｃｏｍｐｏｓｉｔｅ＿ｄｉｓｐｌａｙ＿ｆｌａｇは、ソース信号がコンポジット信号であったかどうかを示すデータである。ｖ＿ａｘｉｓは、ソース信号が、ＰＡＬの場合に使われるデータである。ｆｉｅｌｄ＿ｓｅｑｕｅｎｃｅは、ソース信号が、ＰＡＬの場合に使われるデータである。ｓｕｂ＿ｃａｒｒｉｅｒは、ソース信号が、ＰＡＬの場合に使われるデータである。ｂｕｒｓｔ＿ａｍｐｌｉｔｕｄｅは、ソース信号が、ＰＡＬの場合に使われるデータである。ｓｕｂ＿ｃａｒｒｉｅｒ＿ｐｈａｓｅは、ソース信号が、ＰＡＬの場合に使われるデータである。
【０１５５】
図３６は、ｐｉｃｔｕｒｅ＿ｄａｔａ（）関数のシンタックスを説明するための図である。このｐｉｃｔｕｒｅ＿ｄａｔａ（）関数によって定義されるデータエレメントは、ｓｌｉｃｅ（）関数によって定義されるデータエレメントである。但し、ビットストリーム中に、ｓｌｉｃｅ（）関数のスタートコードを示すｓｌｉｃｅ＿ｓｔａｒｔ＿ｃｏｄｅが存在しない場合には、このｓｌｉｃｅ（）関数によって定義されるデータエレメントはビットストリーム中に記述されていない。
【０１５６】
ｓｌｉｃｅ（）関数は、スライスレイヤに関するデータエレメントを記述するための関数であって、具体的には、ｓｌｉｃｅ＿ｓｔａｒｔ＿ｃｏｄｅ、ｓｌｉｃｅ＿ｑｕａｎｔｉｓｅｒ＿ｓｃａｌｅ＿ｃｏｄｅ、ｉｎｔｒａ＿ｓｌｉｃｅ＿ｆｌａｇ、ｉｎｔｒａ＿ｓｌｉｃｅ、ｒｅｓｅｒｖｅｄ＿ｂｉｔｓ、ｅｘｔｒａ＿ｂｉｔ＿ｓｌｉｃｅ、ｅｘｔｒａ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｓｌｉｃｅ、およびｅｘｔｒａ＿ｂｉｔ＿ｓｌｉｃｅ 等のデータエレメントと、ｍａｃｒｏｂｌｏｃｋ（）関数によって定義されるデータエレメントを記述するための関数である。
【０１５７】
ｓｌｉｃｅ＿ｓｔａｒｔ＿ｃｏｄｅは、ｓｌｉｃｅ（）関数によって定義されるデータエレメントのスタートを示すスタートコードである。ｓｌｉｃｅ＿ｑｕａｎｔｉｓｅｒ＿ｓｃａｌｅ＿ｃｏｄｅは、このスライスレイヤに存在するマクロブロックに対して設定された量子化ステップサイズを示すデータである。しかし、各マクロブロック毎に、ｑｕａｎｔｉｓｅｒ＿ｓｃａｌｅ＿ｃｏｄｅが設定されている場合には、各マクロブロックに対して設定されたｍａｃｒｏｂｌｏｃｋ＿ｑｕａｎｔｉｓｅｒ＿ｓｃａｌｅ＿ｃｏｄｅのデータが優先して使用される。ｉｎｔｒａ＿ｓｌｉｃｅ＿ｆｌａｇは、ビットストリーム中にｉｎｔｒａ＿ｓｌｉｃｅおよびｒｅｓｅｒｖｅｄ＿ｂｉｔｓが存在するか否かを示すフラグである。ｉｎｔｒａ＿ｓｌｉｃｅは、スライスレイヤ中にノンイントラマクロブロックが存在するか否かを示すデータである。スライスレイヤにおけるマクロブロックのいずれかがノンイントラマクロブロックである場合には、ｉｎｔｒａ＿ｓｌｉｃｅは「０」となり、スライスレイヤにおけるマクロブロックの全てがノンイントラマクロブロックである場合には、ｉｎｔｒａ＿ｓｌｉｃｅは「１」となる。ｒｅｓｅｒｖｅｄ＿ｂｉｔｓは、７ビットのデータであって「０」の値を取る。ｅｘｔｒａ＿ｂｉｔ＿ｓｌｉｃｅは、符号化ストリームとして追加の情報が存在することを示すフラグであって、次にｅｘｔｒａ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｓｌｉｃｅが存在する場合には「１」に設定される。追加の情報が存在しない場合には「０」に設定される。
【０１５８】
ｍａｃｒｏｂｌｏｃｋ（）関数は、マクロブロックレイヤに関するデータエレメントを記述するための関数であって、具体的には、ｍａｃｒｏｂｌｏｃｋ＿ｅｓｃａｐｅ、ｍａｃｒｏｂｌｏｃｋ＿ａｄｄｒｅｓｓ＿ｉｎｃｒｅｍｅｎｔ、およびｍａｃｒｏｂｌｏｃｋ＿ｑｕａｎｔｉｓｅｒ＿ｓｃａｌｅ＿ｃｏｄｅ等のデータエレメントと、ｍａｃｒｏｂｌｏｃｋ＿ｍｏｄｅｓ（）関数、および ｍａｃｒｏｂｌｏｃｋ＿ｖｅｃｔｅｒｓ（ｓ）関数によって定義されたデータエレメントを記述するための関数である。
【０１５９】
ｍａｃｒｏｂｌｏｃｋ＿ｅｓｃａｐｅは、参照マクロブロックと前のマクロブロックとの水平方向の差が３４以上であるか否かを示す固定ビット列である。参照マクロブロックと前のマクロブロックとの水平方向の差が３４以上の場合には、ｍａｃｒｏｂｌｏｃｋ＿ａｄｄｒｅｓｓ＿ｉｎｃｒｅｍｅｎｔの値に３３をプラスする。ｍａｃｒｏｂｌｏｃｋ＿ａｄｄｒｅｓｓ＿ｉｎｃｒｅｍｅｎｔは、参照マクロブロックと前のマクロブロックとの水平方向の差を示すデータである。もし、このｍａｃｒｏｂｌｏｃｋ＿ａｄｄｒｅｓｓ＿ｉｎｃｒｅｍｅｎｔの前にｍａｃｒｏｂｌｏｃｋ＿ｅｓｃａｐｅが１つ存在するのであれば、このｍａｃｒｏｂｌｏｃｋ＿ａｄｄｒｅｓｓ＿ｉｎｃｒｅｍｅｎｔの値に３３をプラスした値が、実際の参照マクロブロックと前のマクロブロックとの水平方向の差分を示すデータとなる。ｍａｃｒｏｂｌｏｃｋ＿ｑｕａｎｔｉｓｅｒ＿ｓｃａｌｅ＿ｃｏｄｅは、各マクロブロック毎に設定された量子化ステップサイズである。各スライスレイヤには、スライスレイヤの量子化ステップサイズを示すｓｌｉｃｅ＿ｑｕａｎｔｉｓｅｒ＿ｓｃａｌｅ＿ｃｏｄｅが設定されているが、参照マクロブロックに対してｍａｃｒｏｂｌｏｃｋ＿ｑｕａｎｔｉｓｅｒ＿ｓｃａｌｅ＿ｃｏｄｅが設定されている場合には、この量子化ステップサイズを選択する。
【０１６０】
図３７は、ＭＰＥＧ符号化ストリームのデータ構造を示す説明図である。この図に示したように、ビデオエレメンタリストリームのデータ構造は、少なくともシーケンスレイヤ、ＧＯＰレイヤ、およびピクチャレイヤを含んでいる。
【０１６１】
シーケンスレイヤは、ｎｅｘｔ＿ｓｔａｒｔ＿ｃｏｄｅ（）関数２０１、ｓｅｑｕｅｎｃｅ＿ｈｅａｄｅｒ（）関数２０２、ｅｘｔｅｎｓｉｏｎ＿ｓｔａｒｔ＿ｃｏｄｅ（）２０３、ｓｅｑｕｅｎｃｅ＿ｅｘｔｅｎｓｉｏｎ（）関数２０４、ｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（０）関数２０５によって定義されるデータエレメントから構成されている。ＧＯＰレイヤは、ｇｒｏｕｐ＿ｓｔａｒｔ＿ｃｏｄｅ２０６、ｇｒｏｕｐ＿ｏｆ＿ｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）関数２０７、ｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（１）関数２０８によって定義されるデータエレメントから構成されている。ピクチャレイヤは、ｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）関数２０９、ｐｉｃｔｕｒｅ＿ｃｏｄｉｎｇ＿ｅｘｔｅｎｓｉｏｎ（）関数２１０、ｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（２）関数２１１、ｐｉｃｔｕｒｅ＿ｄａｔａ（）関数２１２によって定義されるデータエレメントを含んでいる。ビデオシーケンスの最後には、ｓｅｑｕｅｎｃｅ＿ｅｎｄ＿ｃｏｄｅ２１３が記述されている。
【０１６２】
ｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（２）関数２１１は、既に図２６において説明したシンタックスからも理解できるように、ｕｓｅｒ＿ｄａｔａ＿ｓｔａｒｔ＿ｃｏｄｅ２１４、ｕｓｅｒ＿ｄａｔａ（）関数２１５、ｎｅｘｔ＿ｓｔａｒｔ＿ｃｏｄｅ２１６によって定義されるデータエレメントを含んでいる。
【０１６３】
ｕｓｅｒ＿ｄａｔａ（）関数２１５は、既に図２７において説明したシンタックスからも理解できるように、ｔｉｍｅ＿ｃｏｄｅ（）関数２１７とｕｓｅｒ＿ｄａｔａ２１８によって定義されるデータエレメントを含んでいる。
【０１６４】
なお、本明細書において、システムとは、複数の装置により構成される装置全体を表すものとする。
【０１６５】
また、本明細書中において、上記処理を実行するコンピュータプログラムをユーザに提供する提供媒体には、磁気ディスク、ＣＤ−ＲＯＭなどの情報記録媒体の他、インターネット、デジタル衛星などのネットワークによる伝送媒体も含まれる。
【０１６６】
【発明の効果】
以上の如く、請求項１および請求項２に記載のビットストリーム変換装置、請求項６および請求項７に記載のビットストリーム変換方法、請求項８および請求項９に記載の提供媒体によれば、放送局内においては、エレメンタリストリームのデータを送受信し、放送局間では、トランスポートストリームのデータを送受信するようにしたので、システム全体として、低コストで効率的にデータを送受信し、処理することが可能となる。
【図面の簡単な説明】
【図１】Ｃｏｄｉｎｇ Ｐｈａｓｅを説明する図である。
【図２】補助データを説明する図である。
【図３】エレメンタリストリームを伝送するシステムの構成を示す図である。
【図４】補助データを伝送するシステムの構成を示す図である。
【図５】ＭＰＥＧ方式における予測構造と符号化構造を説明する図である。
【図６】ＭＰＥＧエンコーダで発生する遅延について説明する図である。
【図７】スタジオの内部の構成を示すブロック図である。
【図８】図７のスタジオの内部で伝送されるデータを説明する図である。
【図９】図７のシステムにおいてデータを伝送するシステムの構成を示す図である。
【図１０】３−２プルダウン処理された画像の補助データを説明する図である。
【図１１】２つのスタジオの間でビットストリームを伝送するときのシステム構成を表すブロック図である。
【図１２】図１１のシステムで伝送されるストリームの構成を表す図である。
【図１３】図１１のシステムにおいて、トランスポートストリームを伝送する構成を表すブロック図である。
【図１４】符号化処理の遅延を説明する図である。
【図１５】本発明を適用したＭＰＥＧエンコーダの構成を表すブロック図である。
【図１６】本発明を適用したＭＰＥＧデコーダの構成を表すブロック図である。
【図１７】ＣＰＩを伝送する場合のシステムの構成を表す図である。
【図１８】図１１のＳＤＴＩ−ＣＰインタフェース４６の構成を表すブロック図である。
【図１９】補助データの伝送を説明する図である。
【図２０】３−２プルダウン処理におけるＰＴＳ＿ｃｏｕｎｔｅｒとＤＴＳ＿ｃｏｕｎｔｅｒを説明する図である。
【図２１】ＰＯＩを伝送する場合のシステムの構成を表す図である。
【図２２】ＰＯＩを伝送する場合の他のシステムの構成を表す図である。
【図２３】ｖｉｄｅｏ＿ｓｅｑｕｅｎｃｅ関数のシンタックスを説明する図である。
【図２４】ｓｅｑｕｅｎｃｅ＿ｈｅａｄｅｒ（）関数のシンタックスを説明する図である。
【図２５】ｓｅｑｕｅｎｃｅ＿ｅｘｔｅｎｓｉｏｎ（）関数のシンタックスを説明する図である。
【図２６】ｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（ｉ）関数のシンタックスを説明する図である。
【図２７】ｕｓｅｒ ｄａｔａ（）関数のシンタックスを表す図である。
【図２８】ｕｓｅｒ ｄａｔａに記述される関数のＤａｔａ＿ＩＤを説明する図である。
【図２９】Ｖ−Ｐｈａｓｅ（）関数のシンタックスを説明する図である。
【図３０】Ｈ−Ｐｈａｓｅ（）関数のシンタックスを説明する図である。
【図３１】Ｐｉｃｔｕｒｅ＿Ｏｒｄｅｒ（）関数のシンタックスを説明する図である。
【図３２】Ａｎｃｉｌｌａｒｙ＿ｄａｔａ（）関数のシンタックスを説明する図である。
【図３３】ｇｒｏｕｐ＿ｏｆ＿ｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）関数のシンタックスを説明する図である。
【図３４】ｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）関数のシンタックスを説明する図である。
【図３５】ｐｉｃｔｕｒｅ＿ｃｏｄｉｎｇ＿ｅｘｔｅｎｓｉｏｎ（）関数のシンタックスを説明する図である。
【図３６】ｐｉｃｔｕｒｅ＿ｄａｔａ（）関数のシンタックスを説明する図である。
【図３７】ＭＰＥＧ方式のレイヤを説明する図である。
【符号の説明】
４２，４３ ＭＰＥＧエンコーダ， ４４，４５ ＭＰＥＧデコーダ， ４６乃至４９ ＳＤＴＩ−ＣＰインタフェース， ５０ ＳＤＴＩ−ＣＰネットワーク， ５１ ＳＤＴＩ−ＣＰインタフェース， ６１，６２ ＴＳ ＭＵＸ／ＤＥＭＵＸ， ７２，７３ ＭＰＥＧエンコーダ，７４，７５ ＭＰＥＧデコーダ， ７６乃至８１ ＳＤＴＩ−ＣＰインタフェース， ８０ ＳＤＴＩ−ＣＰネットワーク
【発明の属する技術分野】
本発明は、ビットストリーム変換装置および方法、並びに提供媒体に関し、特に、より効率的にデジタル信号を送受信することができるようにした、ビットストリーム変換装置および方法、並びに提供媒体に関する。
【０００２】
【従来の技術】
画像信号または音声信号を符号化して伝送する場合、ＩＳＯ／ＩＥＣ１１１７２（ＭＰＥＧ−１）もしくはＩＳＯ／ＩＥＣ１３８１８（ＭＰＥＧ−２）に示されている符号化方式が用いられることが多い。画像信号を、ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）方式で符号化する場合の技術として、コーディングフェーズ（ｃｏｄｉｎｇ ｐｈａｓｅ）と両方向予測があげられる。
【０００３】
ｃｏｄｉｎｇ ｐｈａｓｅとは、図１に示すように、１枚の画像の画素エリア１のうち、符号化が行われる範囲としての有効画素エリア２を規定するためのコードであり、具体的には、全てのラインのうち、有効画素エリア２の最初のライン（図１のＶ−ｐｈａｓｅ［ｌｉｎｅ］の矢印で示されたライン）、および、全てのサンプル（画素）のうち、有効画素エリア２の最初のラインの最初のサンプル（図１のＨ−ｐｈａｓｅ［ｓａｍｐｌｅ］の矢印で示されたサンプル（画素））を示すものである。画素エリア１の最後のラインを、Ｖ−Ｐｈａｓｅ［Ｌｍａｘ］とし、画素エリア１のラインの最後のサンプル（画素）を、Ｈ−Ｐｈａｓｅ［Ｓｍａｘ］とするとき、符号化は、例えば、垂直方向に、Ｖ−Ｐｈａｓｅ［ｌｉｎｅ］から、（Ｖ−Ｐｈａｓｅ［Ｌｍａｘ］ − Ｖ−Ｐｈａｓｅ［ｌｉｎｅ］＋１）までの範囲で行われ、水平方向に、Ｈ−Ｐｈａｓｅ［ｓａｍｐｌｅ］から、（Ｈ−Ｐｈａｓｅ［Ｓｍａｘ］−Ｈ − Ｐｈａｓｅ［ｓａｍｐｌｅ］＋１）までの範囲で行われる。
【０００４】
また、一般の例えば、ＮＴＳＣ方式のテレビジョン受像機などの画像信号において、図１の画像信号のフレームは、図２に示すように、２枚のフィールド（図２のフィールド１およびフィールド２）から構成されている。フィールド１には、例えば、奇数ラインのデータが表示され、フィールド２には偶数ラインのデータが表示される。２枚のフィールドは、それぞれ、補助データ（ａｎｃｉｌｌａｒｙ ｄａｔａ）と、画像（イメージ）データ（ｉｍａｇｅ ｄａｔａ）から構成されている。
【０００５】
補助データは、耳の不自由な人のための文字放送用のテレテキストデータ、タイムコード、または映画などの字幕のクローズドキャプションデータに利用され、ブランキング区間（例えば、各フィールドの第１０ライン乃至第２２ライン）（図２においては、いずれのフィールドも、そのフィールド内の上から順番の番号でラインが表されている）のうちの所定のラインに挿入されている。一般に、各フィールドの第２３ラインより図中下に位置するラインの部分（実際に、画像として表示される部分）は、画像データとして、ＭＰＥＧ方式などにより符号化される。
【０００６】
前述したＭＰＥＧ符号化方式は、画像データにのみ適用され、ｃｏｄｉｎｇ ｐｈａｓｅ、および補助データについては、ＭＰＥＧの規格には、特に明確に記述（規定）されていない。そのため、ｃｏｄｉｎｇ ｐｈａｓｅは、自由度を有し、様々なアプリケーションによって異なっている。
【０００７】
このような画像信号を、符号化または復号するときのシステム構成を、図３を参照して説明する。アプリケーションＡの画像データは、アプリケーションＡ用ＭＰＥＧエンコーダ１１で符号化され、エレメンタリストリーム（ＥＳ）として出力され、アプリケーションＡ用ＭＰＥＧデコーダ１２で復号される。アプリケーションＢの画像データは、アプリケーションＢ用ＭＰＥＧエンコーダ１３で符号化され、エレメンタリストリーム（ＥＳ）として出力され、アプリケーションＢ用ＭＰＥＧデコーダ１４で復号される。
【０００８】
つまり、あるアプリケーションの画像データは、そのアプリケーション専用のエンコーダ（例えば、アプリケーションＡ用ＭＰＥＧエンコーダ１１）で符号化され、エレメンタリストリーム（ＥＳ）として、そのアプリケーションに対応した専用のデコーダ（例えば、アプリケーションＡ用ＭＰＥＧデコーダ１２）に出力される。専用デコーダに入力されたエレメンタリストリーム（ＥＳ）は、そのデコーダが有している、そのアプリケーションのｃｏｄｉｎｇ ｐｈａｓｅに関する情報に基づき、復号される。
【０００９】
次に、現在主流となっている補助データの伝送方式について、図４を参照して説明する。画像信号は、ＭＰＥＧエンコーダ２１に入力され、分離部２１において、画像データと補助データに分離される。ＭＰＥＧエンコード部２３は、画像データをＭＰＥＧ符号化する。補助データは、可変長符号化部２４で、ＭＰＥＧエンコード部２３より出力されたＭＰＥＧ方式のトランスポートストリーム中のｕｓｅｒ ｄａｔａに挿入される。このトランスポートストリーム中のｕｓｅｒ ｄａｔａは、符号化された画像データ（ピクチャ）単位に挿入（記述）できるため、補助データは、対応する各符号化画像データのフレームのｕｓｅｒ ｄａｔａごとに挿入される。
【００１０】
補助データが挿入されたｕｓｅｒ ｄａｔａを含むトランスポートストリームは、所定の伝送路を介して伝送され、ＭＰＥＧデコーダ２５に入力される。ＭＰＥＧデコーダ２５内の可変長復号部２６は、補助データと画像データとを分離する。画像データはＭＰＥＧデコード部２７で復号され、合成部２８で補助データと合成されて、画像信号として、図示せぬ表示装置に出力される。
【００１１】
次に、ＭＰＥＧ方式の予測について説明する。両方向予測に基づいて生成された符号化画像データのピクチャはＢピクチャと称される。Ｂピクチャは、時間的に前または後に位置する２枚の参照画像データから予測されて生成される。前方予測に基づいて生成された符号化画像データのピクチャはＰピクチャと称される。Ｐピクチャは、時間的に前に位置する１枚の参照画像データから予測されて生成される。予測が行われず、そのまま画像データが符号化（イントラ符号化）された符号化画像データのピクチャはＩピクチャと称される。つまり、入力された画像データは、Ｂピクチャ、Ｐピクチャ、またはＩピクチャのいずれかの符号化画像データに符号化される。
【００１２】
両方向予測および前方予測について、図５を参照して説明する。図５の例では、１つのＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅ）が、９枚のピクチャから構成されている。図５の上段は、符号化画像データが生成されるときの、予測の方向（依存関係）を示す予測構造を表しており、図５の下段は、実際に画像データが符号化される順序を示す符号化構造を表している。Ｂピクチャ、またはＰピクチャは、時間的に前または後の画像データから予測されて生成されるために、Ｂピクチャ、またはＰピクチャだけでは、符号化を行うことはできない。すなわち、Ｂピクチャ、またはＰピクチャは、参照画像データとの差分をデータとする符号化画像データであるので、Ｂピクチャ、またはＰピクチャだけでは、画像データを復号することもできない。
【００１３】
予測の依存関係について詳細に説明すると、例えば、ＧＯＰ（Ｎ−１）において、表示順序が先頭のＢピクチャは、先頭から３番目のＩピクチャと、図示されていないＧＯＰ（Ｎ−２）（ＧＯＰ（Ｎ−１）の直前のＧＯＰ）の最後のＰピクチャから予測されて符号化される。先頭から２番目のＢピクチャも同様に、先頭から３番目のＩピクチャと、図示されていないＧＯＰ（Ｎ−２）の最後のＰピクチャから予測されて符号化される。先頭から３番目のＩピクチャは、そのまま符号化（イントラ符号化）される。先頭から４番目、および５番目のＢピクチャは、先頭から３番目のＩピクチャと先頭から６番目のＰピクチャから予測されて符号化される。先頭から６番目のＰピクチャは、先頭から３番目のＩピクチャから予測されて符号化される。
【００１４】
つまり、予測構造において、Ｂピクチャ（例えば、先頭のＢピクチャと先頭から２番目のＢピクチャ）が符号化されるには、予測の参照画像データ（例えば、３番目のＩピクチャとＧＯＰ（Ｎ−２）の最後のＰピクチャ）が、先に符号化されている必要がある。すなわち、図５の下段に示すような、符号化構造の順番で符号化されなければならない。そのため、ＭＰＥＧエンコーダは、符号化（エンコード）時、ＩピクチャとＰピクチャの間に存在する、２枚の連続したＢピクチャを符号化するために必要な参照画像データ（先頭から３番目のＩピクチャ）が入力されるまで、２枚のＢピクチャをバッファリングする（Ｉピクチャが入力されるまで、符号化の開始を遅延させる）必要がある。このバッファリングにより、ＭＰＥＧエンコーダにおいて、入力された画像信号を符号化するとき、参照画像データに挟まれたＢピクチャの枚数（＝２）＋１枚（合計３枚）の遅延時間が発生する。
【００１５】
このＭＰＥＧエンコーダにおいて発生する遅延について、図６を参照して、さらに詳細に説明する。図６の上段はＭＰＥＧエンコーダ３１における、入力画像（画像データ）の入力順番（表示順序）とその種別を表しており、図６の中段は、入力画像（画像データ）が符号化された符号化画像データの順番を表している。
【００１６】
ＭＰＥＧエンコーダ３１は、時刻ｔ４のＰピクチャが入力されるまで（Ｂピクチャの枚数（＝２）＋１枚分の時間だけ）、時刻ｔ１に入力されたＩピクチャの符号化を遅延させる（前述のバッファリングを行う）。すなわち、ＭＰＥＧエンコーダ３１は、時刻ｔ４で時刻ｔ１に入力されたＩピクチャを符号化し、時刻ｔ５で時刻ｔ４に入力されたＰピクチャを符号化し、時刻ｔ６で時刻ｔ２に入力されたＢピクチャを符号化し、時刻ｔ７で時刻ｔ３に入力されたＢピクチャを符号化する。その後、ＭＰＥＧエンコーダ３１は、入力画像を図６の中段の符号化画像データの順番で、順次、符号化する。
【００１７】
このように、ＭＰＥＧエンコーダ３１は、入力画像に対して、予測に必要な参照画像データから順次符号化する。つまり、ＭＰＥＧエンコーダ３１において、入力画像（画像データ）は、入力画像の順番から、符号化される画像の順番に並べ変えられ、図６の中段に示すように、入力画像が符号化された順番にビットストリームとして、ＭＰＥＧデコーダ３２に出力される。
【００１８】
このように、入力画像が符号化される順番と表示される順番は一致しないので、ＭＰＥＧにおいては、符号化順序を表すＤＴＳ（Ｄｅｃｏｄｉｎｇ Ｔｉｍｅ Ｓｔａｍｐ）と、表示順序を表すＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ Ｓｔａｍｐ）が、トランスポートストリーム中に挿入されるようになされている。入力画像の符号化順序と表示順序の関係をさらに説明すると、いま、符号化順序をフレーム単位で表すものとすると、図６に示すように、入力画像は符号化される順番で付番され、時刻ｔ４で符号化されたＩピクチャの符号化順序の値は”１”となり、時刻ｔ５で符号化されたＰピクチャの符号化順序の値は”２”となり、時刻ｔ６で符号化されたＢピクチャの符号化順序の値は”３”となる。以下、同様に符号化される順番に符号化順序が付番される。ＤＴＳはフレーム単位で符号化順序を表しているわけではないが、ほぼ、この符号化順序に対応する。ＤＴＳはまた、ビットストリームを音声信号などと多重化して出力するとき、ＭＰＥＧデコーダ３２において、復号する順番として使用される。
【００１９】
表示順序は、画像データが復号されて表示される順番（入力画像データの順番と同じ）となる。具体的には、時刻ｔ４で符号化されるＩピクチャ（符号化順序＝１）の表示順序は、時刻ｔ５でＰピクチャ（符号化順序＝２）が符号化されるときに表示されなければならないので、そのＰピクチャの符号化順序と同じ値”２”となる。時刻ｔ５で符号化されるＰピクチャ（符号化順序＝２）の表示順序は、時刻ｔ８でＰピクチャ（符号化順序＝５）が符号化されるとき表示されなければならないので、そのＰピクチャの符号化順序と同じ値”５”となる。時刻ｔ６で符号化されるＢピクチャ（符号化順序＝３）は、符号化されると、直ちに復号されて表示されなければならないので、符号化順序と表示順序は同一となり、表示順序の値は”３”となる。時刻ｔ７で符号化されるＢピクチャ（符号化順序＝４）も同様に、表示順序＝符号化順序＝４となる。ＰＴＳはフレーム単位で表示順序を表しているわけではないが、ほぼ、この表示順序に対応する。ＰＴＳはまた、ＭＰＥＧデコーダ３２において、復号後、出力（表示）する順番として使用される。
【００２０】
ＭＰＥＧデコーダ３２では、符号化順序が連続する２枚のＩピクチャもしくはＰピクチャのうち、最初の１枚目は、２枚目が復号されるとき、表示される。例えば、ＭＰＥＧエンコーダ３１が出力したビットストリーム中の符号化画像データの１枚目のＩピクチャ（符号化順序＝１，表示順序＝２）と、２枚目のＰピクチャ（符号化順序＝２，表示順序＝５）は、符号化順序が連続しており、２枚目のＰピクチャが符号化されるとき（時刻ｔ５のとき）、１枚目のＩピクチャが復号されて表示される。
【００２１】
このように、ＭＰＥＧエンコーダ３１は、入力画像（画像データ）の予測構造（参照画像データに挟まれているＢピクチャの枚数）を知っているので、画像データに符号化順序（ＤＴＳ）と表示順序（ＰＴＳ）を付番することができる。
【００２２】
放送局などのスタジオ内で、図７に示すシステム構成で、ＭＰＥＧ符号化されたビットストリームを伝送することが考えられている。スタジオ４１内のＭＰＥＧエンコーダ４２、ＭＰＥＧエンコーダ４３、ＭＰＥＧデコーダ４４、およびＭＰＥＧデコーダ４５は、それぞれ、ＳＤＴＩ−ＣＰ（Ｓｅｒｉａｌ Ｄａｔａ Ｔｒａｎｓｆｅｒ Ｉｎｔｅｒｆａｃｅ − Ｃｏｎｔｅｎｔ Ｐａｃｋａｇｅ）インタフェース４６乃至４９を介して、ＳＤＴＩ−ＣＰネットワーク（例えば、同軸ケーブルにより構成されるネットワーク）５０に接続される。ＳＤＴＩ−ＣＰネットワーク５０は、ＳＤＩ（Ｓｅｒｉａｌ Ｄａｔａ Ｉｎｔｅｒｆａｃｅ）をベースとした２７０Ｍｂｐｓの伝送速度を有し、ＭＰＥＧ方式のエレメンタリストリーム（ＥＳ）をそのまま伝送することが可能であり、スタジオ内のような閉じたネットワークに適している。
【００２３】
スタジオ４１において、例えば、ＭＰＥＧエンコーダ４２は、ＭＰＥＧ符号化されたエレメンタリストリーム（ＥＳ）を、ＳＤＴＩ−ＣＰネットワーク５０を介して、ＭＰＥＧデコーダ４４、ＭＰＥＧデコーダ４５に伝送することができる。
【００２４】
このＳＤＴＩ−ＣＰネットワーク５０で伝送されるエレメンタリストリーム（ＥＳ）は、図８に示す構造となっており、画像信号のフレーム単位で、画像データ（図８において薄い影を付けた部分）と音声データ（図８において濃い影を付けた部分）がパッキングされており、フレームシンク（図８の点線）により区切られたフレーム境界で、簡単に編集を行うことができる。このエレメンタリストリーム（ＥＳ）における画像データと音声データは、イントラ（フレーム内符号化）処理されたデータである。
【００２５】
図７に示すスタジオ４１のシステムは、そのＭＰＥＧエンコーダ４２，４３とＭＰＥＧデコーダ４４，４５が、ＳＤＴＩ−ＣＰインタフェース４６乃至４９を介して、ＳＤＴＩ−ＣＰネットワーク５０に接続されており、図３に示したような、アプリケーションごとに専用のエンコーダ（例えば、アプリケーションＡ用ＭＰＥＧエンコーダ１１）とデコーダ（例えば、アプリケーションＡ用ＭＰＥＧデコーダ１２）が１対１に対応するシステムとは構成が異なっている。すなわち、デコーダ（例えば、図７のＭＰＥＧデコーダ４４）は、エンコーダ（例えば、図７のＭＰＥＧエンコーダ４２またはＭＰＥＧエンコーダ４３）で、様々なアプリケーションの画像信号が符号化された、エレメンタリストリーム（ＥＳ）を受け取ることができる。
【００２６】
図７のシステム構成を、図３のシステム構成に対応させた図９を参照して説明すると、アプリケーションＡ用ＭＰＥＧエンコーダ４２で符号化されたエレメンタリストリーム（ＥＳ）と、アプリケーションＢ用ＭＰＥＧエンコーダ４３で符号化されたエレメンタリストリーム（ＥＳ）は、それぞれＳＤＴＩ−ＣＰインタフェース４６，４７に入力される。ＳＤＴＩ−ＣＰインタフェース４６，４７は、それぞれＭＰＥＧ符号化されたエレメンタリストリーム（ＥＳ）を、ＳＤＴＩフォーマットのエレメンタリストリーム（ＥＳ）に変換して、ＳＤＴＩ−ＣＰネットワーク５０を介して伝送する。ＳＤＴＩ−ＣＰインタフェース４８は、ＳＤＴＩフォーマットのエレメンタリストリーム（ＥＳ）を、ＭＰＥＧ符号化されたエレメンタリストリーム（ＥＳ）に変換し、ＭＰＥＧデコーダ４４に出力する。
【００２７】
ＭＰＥＧデコーダ４４は、それぞれ入力されたアプリケーションＡ用のエレメンタリストリーム（ＥＳ）とアプリケーションＢ用のエレメンタリストリーム（ＥＳ）を復号する。
【００２８】
ところで、補助データがトランスポートストリーム中のｕｓｅｒ ｄａｔａに挿入される場合、補助データは、対応する符号化画像のフレーム単位で挿入されるため、その挿入は１フレーム（２フィールド）ごととなる。
【００２９】
符号化される信号が、３−２プルダウン処理（例えば、２４Ｈｚのフレームレートを持つ映画の画像信号を、３０Ｈｚのフレームレートを持つＮＴＳＣ方式の画像信号に変換する処理）された信号である場合、その信号は、図１０に示すように、２４Ｈｚの各フレームを、交互に、リピートフィールドが作成されていない２フィールドのフレーム、またはリピートフィールドが作成されている３フィールドのフレームとすることで、３０Ｈｚの信号とされている。
【００３０】
例えば、図４のＭＰＥＧエンコーダ２１は、３−２プルダウン処理により３０Ｈｚのフレームレートに変換された画像信号が入力されたとき、フィールドの繰り返しを検出して、元の２４Ｈｚの符号化フレーム単位で符号化を行い、その処理に対応して、フラグ（Ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄ，Ｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔ）を生成する。
【００３１】
Ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄのフラグの”１”は、リピートフィールドが作成されたことを意味し、Ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄのフラグの”０”は、リピートフィールドが作成されていないことを意味する。Ｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔのフラグは、フレームを構成するフィールドのうち、最初のフィールドがトップフィールドであるのか、またはボトムフィールドであるのかを表している。Ｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔのフラグの”１”は、トップフィールドがボトムフィールドより時間的に早いフレーム構造であることを表しており、Ｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔのフラグの”０”は、ボトムフィールドがトップフィールドより時間的に早いフレーム構造であることを表している。
【００３２】
図１０に示すように、原信号のフレームが３フィールドのフレームである場合、対応する１つの符号化フレームには、同一位相の２枚のフィールド（３−２プルダウン処理によりコピーにより生成されたフィールドとそのコピー元のフィールド）が存在する。しかしながら、この元の１つのフレームを構成する３フィールドが符号化フレーム単位で符号化されるとき、各符号化フレームごとの補助データは、符号化フレーム単位で、１つの補助データとして、ｕｓｅｒ ｄａｔａに記述されるため、原信号の同一位相のフィールドに異なった補助データが記述されていても、その異なった補助データを区別することができなくなってしまう。
【００３３】
【発明が解決しようとする課題】
このように、ＭＰＥＧ方式は、例えば、スタジオなどで画像データを編集する際にも用いられている。しかしながら、従来のシステムでは、異なるスタジオ間で、画像データを効率的に送受信し、迅速に処理することが困難である課題があった。
【００３４】
本発明はこのような状況に鑑みてなされたものであり、異なるスタジオ間で、画像データを効率的に送受信処理することができるようにするものである。
【００３５】
【課題を解決するための手段】
請求項１に記載のビットストリーム変換装置は、画像信号の符号化順序と表示順序を含む順序情報が重畳されたエレメンタリストリームを入力するエレメンタリストリーム入力手段と、エレメンタリストリーム入力手段により入力されたエレメンタリストリームを、順序情報を参照して多重化し、トランスポートストリームを生成するトランスポートストリーム生成手段と、トランスポートストリーム生成手段により生成されたトランスポートストリームを出力するトランスポートストリーム出力手段とを含むことを特徴とする。
また、請求項２に記載のビットストリーム変換装置は、エレメンタリストリームに重畳された順序情報に含まれる符号化情報と順序情報を換算することによりエレメンタリストリームを多重化して生成したトランスポートストリームを入力するトランスポートストリーム入力手段と、トランスポートストリーム入力手段により入力されたトランスポートストリームを、前記符号化情報及び前記表示情報に換算してエレメンタリストリームを生成するエレメンタリストリーム生成手段と、エレメンタリストリーム生成手段により生成されたエレメンタリストリームを出力するエレメンタリストリーム出力手段とを含むことを特徴とする。
【００３６】
請求項６に記載のビットストリーム変換方法は、像信号の符号化順序と表示順序を含む順序情報が重畳されたエレメンタリストリームを入力するエレメンタリストリーム入力ステップと、エレメンタリストリーム入力ステップの処理において入力されたエレメンタリストリームを、順序情報を参照して多重化処理し、トランスポートストリームを生成するトランスポートストリーム生成ステップと、トランスポートストリーム生成ステップの処理において生成されたトランスポートストリームを出力するトランスポートストリーム出力ステップとを含むことを特徴とする。
また、請求項７に記載のビットストリーム変換方法は、エレメンタリストリームに重畳された順序情報に含まれる符号化情報と順序情報を換算することによりエレメンタリストリームを多重化して生成したトランスポートストリームを入力するトランスポートストリーム入力ステップと、トランスポートストリーム入力ステップの処理において入力されたトランスポートストリームを、符号化情報及び表示情報に換算してエレメンタリストリームを生成するエレメンタリストリーム生成ステップと、エレメンタリストリーム生成ステップの処理において生成されたエレメンタリストリームを出力するエレメンタリストリーム出力ステップとを含むことを特徴とする。
【００３７】
請求項８に記載の提供媒体は、画像信号の符号化順序と表示順序を含む順序情報が重畳されたエレメンタリストリームを入力するエレメンタリストリーム入力ステップと、エレメンタリストリーム入力ステップの処理において入力されたエレメンタリストリームを、順序情報を参照して多重化し、トランスポートストリームを生成するトランスポートストリーム生成ステップと、トランスポートストリーム生成ステップの処理において生成されたトランスポートストリームを出力するトランスポートストリーム出力ステップとを含む処理を実行させるコンピュータが読み取り可能なプログラムを提供することを特徴とする。
また、請求項９に記載の提供媒体は、エレメンタリストリームに重畳された順序情報に含まれる符号化情報と順序情報を換算することにより前記エレメンタリストリームを多重化して生成したトランスポートストリームを入力するトランスポートストリーム入力ステップと、トランスポートストリーム入力ステップの処理において入力されたトランスポートストリームを、前記符号化情報及び前記表示情報に換算してエレメンタリストリームを生成するエレメンタリストリーム生成ステップと、エレメンタリストリーム生成ステップの処理において生成されたエレメンタリストリームを出力するエレメンタリストリーム出力ステップと含む処理を実行させるコンピュータが読み取り可能なプログラムを提供することを特徴とする。
【００３８】
請求項１および請求項２に記載のビットストリーム変換装置、請求項６および請求項７に記載のビットストリーム変換方法、請求項８および請求項９に記載の提供媒体により、放送局内においては、エレメンタリストリームのデータが送受信され、放送局間では、トランスポートストリームのデータが送受信される。
【００３９】
【発明の実施の形態】
図１１は、相互に離れた場所に位置するスタジオ４１とスタジオ７１の間で、ＭＰＥＧ符号化されたビットストリームを伝送するシステムの例を表しており、図７における場合と対応する部分には、同一の符号を付してある。この例の場合、各スタジオ内のネットワークを、多重化装置（以下、ＴＳ ＭＵＸ／ＤＥＭＵＸと称する）を介して、衛星やＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ）などの公衆網と接続することで、ビットストリームの伝送を行うことができる。スタジオ７１のＭＰＥＧエンコーダ７２乃至ＳＤＴＩ−ＣＰインタフェース７９は、図７のスタジオ４１のＭＰＥＧエンコーダ４２乃至ＳＤＴＩ−ＣＰインタフェース４９に対応するものであるので、ここでは、その説明を省略する。
【００４０】
ＳＤＴＩ−ＣＰネットワーク５０におけるエレメンタリストリーム（ＥＳ）は、図１２に示すように、ＴＳ ＭＵＸ／ＤＥＭＵＸ６１により、１８８バイト単位のトランスポートストリーム（ＴＳ）に変換されて所定の伝送媒体を介して伝送され、伝送されたトランスポートストリーム（ＴＳ）は、ＴＳ ＭＵＸ／ＤＥＭＵＸ６２で、ＳＤＴＩフォーマットのエレメンタリストリーム（ＥＳ）に変換される。なお、図１２において、薄い影を付けた部分は画像データのパケットを示しており、濃い影を付けた部分は音声データのパケットを示しており、影をつけていない部分は空きデータのパケットを示している。
【００４１】
図１１において、スタジオ４１内のＭＰＥＧエンコーダ４２の出力するエレメンタリストリーム（ＥＳ）が、ＴＳ ＭＵＸ／ＤＥＭＵＸ６１でトランスポートストリーム（ＴＳ）に変換されるまでを、図１３を参照して説明する。ＭＰＥＧエンコーダ４２内のＭＰＥＧビデオエンコーダ４２Ａは、ＭＰＥＧ符号化された画像データのエレメンタリストリーム（ＥＳ）を、ＳＤＴＩ−ＣＰインタフェース４６に出力し、オーディオエンコーダ４２Ｂは、音声データのエレメンタリストリーム（ＥＳ）を、ＳＤＴＩ−ＣＰインタフェース４６に出力する。ＳＤＴＩ−ＣＰインタフェース４６は、入力されたエレメンタリストリーム（ＥＳ）をＳＤＴＩベースのフォーマットのエレメンタリストリーム（ＥＳ）に変換し、ＳＤＴＩ−ＣＰネットワーク５０を介して、ＳＤＴＩ−ＣＰインタフェース５１に出力する。ＳＤＴＩ−ＣＰインタフェース５１は、ＳＤＴＩフォーマットのＥＳをＭＰＥＧ符号化のエレメンタリストリーム（ＥＳ）に変換し、ＴＳ ＭＵＸ／ＤＥＭＵＸ６１に出力する。ＴＳ ＭＵＸ／ＤＥＭＵＸ６１は、ＭＰＥＧ符号化のエレメンタリストリーム（ＥＳ）を１８８バイト単位のトランスポートストリーム（ＴＳ）に変換して伝送媒体に出力する。
【００４２】
図１１において、ＴＳ ＭＵＸ／ＤＥＭＵＸ６１から伝送されたトランスポートストリーム（ＴＳ）は、ＡＴＭなどの公衆網を介して、ＴＳ ＭＵＸ／ＤＥＭＵＸ６２に入力され、ＭＰＥＧ符号化のエレメンタリストリーム（ＥＳ）に変換される。ＳＤＴＩ−ＣＰインタフェース８１において、ＭＰＥＧ符号化されたエレメンタリストリーム（ＥＳ）は、ＳＤＴＩフォーマットのエレメンタリストリーム（ＥＳ）に変換され、スタジオ７１のＳＤＴＩ−ＣＰネットワーク８０に出力される。ＭＰＥＧデコーダ７４は、ＳＤＴＩ−ＣＰインタフェース７８を介して、スタジオ２１から伝送されたエレメンタリストリーム（ＥＳ）を受信することができる。
【００４３】
図１１のシステムにおいて、スタジオ４１とスタジオ７１の間で、画像信号を伝送する場合、多重化装置（例えば、図１１のＴＳ ＭＵＸ／ＤＥＭＵＸ６１）には、画像データが符号化されたエレメンタリストリーム（ＥＳ）のみが入力されるので、多重化装置は、エンコーダ（例えば、図１１のＭＰＥＧエンコーダ４２）において行われた符号化順序の並べ変えの情報を知らない。このため、多重化装置は、入力されたエレメンタリストリーム（ＥＳ）を解釈して、エレメンタリストリーム（ＥＳ）をトランスポートストリーム（ＴＳ）に変換する処理をしなければならない。
【００４４】
このエレメンタリストリームを解釈する処理は、画像信号の符号化構造を把握する処理である。つまり、前述したエンコーダで入力画像をバッファリングして符号化し、ビットストリームに変換するときと同様の処理が、多重化装置でも必要となる。この多重化装置におけるバッファリング処理により、後段での画像データの復号までに遅延が発生し、リアルタイム処理が困難になる。
【００４５】
この多重化装置で発生する、システム構成上、問題となる遅延について、図１４を用いて説明する。多重化装置に、図１４に示す符号化順序で、エンコーダで符号化されたビットストリームが入力された場合、多重化装置は、２枚の連続したＩピクチャ（時刻ｔ４）とＰピクチャ（時刻ｔ５）が入力された後、さらにそれらに挟まれた２枚のＢピクチャ（時刻ｔ６と時刻ｔ７）に続いてＰピクチャ（時刻ｔ８）が入力されるまで、表示順序を確定することができない。つまり、多重化装置は、図５に示したような符号化構造（ＩピクチャとＰピクチャの間に２枚のＢピクチャが挟まれている構造）を知らないので、２枚のＢピクチャが入力され、その次のＰピクチャ（時刻ｔ８）が入力されたとき（Ｂピクチャの入力が終了したことを確認したとき）、時刻ｔ４に入力されたＩピクチャの表示順序（ＰＴＳ）を確定することができる。
【００４６】
すなわち、この多重化装置においては、時刻ｔ８になって初めて、符号化順序＝１のＩピクチャの表示順序＝２を確定することができる。このため、多重化装置では、２枚の連続したＩピクチャまたはＰピクチャ＋２枚のＢピクチャの出現周期（＝４）の遅延が発生する。この遅延は、エンコーダでの遅延とは別に新たに発生するため、システム全体として、エンコーダの遅延（＝３）＋多重化装置の遅延（＝４）＝７の大幅な遅延が生じる。
【００４７】
そこで本発明においては、符号化順序と表示順序を含む順序情報を、Ｐｉｃｔｕｒｅ Ｏｒｄｅｒ Ｉｎｆｏとしてエレメンタリストリームに重畳するようにしている。この点のについては、後に詳述する。
【００４８】
図１５は、本発明を適用したＭＰＥＧエンコーダ４２の構成例を表している。ＭＰＥＧエンコーダ４２の分離部１０１は、入力された画像信号から、画像データと補助データを分離し、画像データをＭＰＥＧエンコード部１０３に出力し、補助データをエンコードコントローラ１０２に出力する。ＭＰＥＧエンコード部１０３は、入力された画像データをＭＰＥＧ方式により符号化するとともに、符号化順序を示すＤＴＳ＿ｃｏｕｎｔｅｒ、および表示順序を示すＰＴＳ＿ｃｏｕｎｔｅｒを含むＰＯＩ（Ｐｉｃｔｕｒｅ Ｏｒｄｅｒ Ｉｎｆｏｍａｔｉｏｎ）をエンコードコントローラ１０２に出力する。また、ＭＰＥＧエンコード部１０３は、符号化した範囲の左上の位置（図１の有効画素エリア２の左上の画素の位置）を表すコーディングフェーズ（Ｃｏｄｉｎｇ Ｐｈａｓｅ（Ｖ−Ｐｈａｓｅ，Ｈ−Ｐｈａｓｅ））をエンコードコントローラ１０２に供給する。
【００４９】
エンコードコントローラ１０２は、分離部１０１より供給された補助データに、それが属するフィールドを識別するＦｉｅｌｄ ＩＤと、それが挿入されているラインを表すＬｉｎｅ＿ｎｕｍｂｅｒを付加し、その補助データと、ＭＰＥＧエンコード部１０３より供給されたＰＯＩ、およびＣｏｄｉｎｇ Ｐｈａｓｅ Ｉｎｆｏｒｍａｔｉｏｎ（ＣＰＩ）を適宜処理し、ｕｓｅｒ ｄａｔａのフォーマットのデータとして、可変長符号化部１０４に出力し、多重化させる。
【００５０】
可変長符号化部１０２は、ＭＰＥＧエンコード部１０３より供給されたエンコードされた画像データを可変長符号化するとともに、エンコードコントローラ１０２より供給されたｕｓｅｒ ｄａｔａを画像データのエレメンタリストリームに挿入する。可変長符号化部１０４より出力されたエレメンタリストリームは、送信バッファ１０５を介して出力される。
【００５１】
図１６は、本発明を適用したＭＰＥＧデコーダ４４の構成例を表している。受信バッファ１１１は、入力されたデータを一旦バッファリングした後、可変長復号部１１２に出力する。可変長復号部１１２は、入力されたデータから、画像データとｕｓｅｒ ｄａｔａとを分離し、画像データをＭＰＥＧデコード部１１４に出力し、ｕｓｅｒ ｄａｔａをデコードコントローラ１１３に出力する。デコードコントローラ１１３は、ｕｓｅｒ ｄａｔａからＰＯＩとＣＰＩを分離し、それらをＭＰＥＧデコード部１１４に出力する。また、デコードコントローラ１１３は、ｕｓｅｒ ｄａｔａから分離した補助データを合成部１１５に出力する。ＭＰＥＧデコード部１１４は、可変長復号部１１２より入力された画像データを、デコードコントローラ１１３より入力されたＰＯＩとＣＰＩを参照してデコードし、デコードした結果を合成部１１５に出力している。合成部１１５は、デコードコントローラ１１３より供給された補助データをＭＰＥＧデコード部１１４より供給された画像データと合成し、出力する。
【００５２】
以下に、ＭＰＥＧエンコーダ４２とＭＰＥＧデコーダ４４の動作について説明する。
【００５３】
ＣＰＩをｕｓｅｒ ｄａｔａに記述して、エレメンタリストリーム（ＥＳ）に重畳して出力する動作を、図１７を参照して説明すると、アプリケーションＡ用ＭＰＥＧエンコーダ４２は、アプリケーションＡの画像信号を符号化したエレメンタリストリーム（ＥＳ）に、ＣＰＩ（画像信号のフォーマットにおける有効画素エリアを示すデータであるＶ−ＰｈａｓｅとＨ−Ｐｈａｓｅ）をｕｓｅｒ ｄａｔａに記述して（図１５の可変長符号化部１０４がエンコードコントローラ１０２から出力されるＣＰＩのデータをｕｓｅｒ ｄａｔａに記述して）、ＳＤＴＩ−ＣＰインタフェース４６に出力する。アプリケーションＢ用ＭＰＥＧエンコーダ４３も、ＭＰＥＧエンコーダ４２と同様に構成されており、アプリケーションＢの画像信号を符号化したエレメンタリストリーム（ＥＳ）に、ＣＰＩをｕｓｅｒ ｄａｔａとして記述して、ＳＤＴＩ−ＣＰインタフェース４７に出力する。
【００５４】
ＳＤＴＩ−ＣＰインタフェース４６の構成例について、図１８を参照して説明する（他のＳＤＴＩ−ＣＰインタフェースも同様に構成されている）。復号部１２１は、ＭＰＥＧエンコーダ４２から入力されたＭＰＥＧ符号化されたエレメンタリストリーム（ＥＳ）を、符号化パラメータと画像データに分離し、画像データを復号し、符号化パラメータとともに符号化パラメータ多重化部１２２に出力する。符号化パラメータ多重化部１２２は、画像信号と符号化パラメータから、ＳＤＴＩ−ＣＰベースのエレメンタリストリーム（ＥＳ）を生成して出力する。
【００５５】
ＳＤＴＩ−ＣＰインタフェース４６に、ＳＤＴＩ−ＣＰベースのエレメンタリストリーム（ＥＳ）が入力された場合、符号化パラメータ分離部１２３は、エレメンタリストリーム（ＥＳ）から画像データと符号化パラメータを分離して、それぞれ符号化部１２４に出力する。符号化部１２４は、符号化パラメータを用いて、画像データを符号化し、ＭＰＥＧ符号化されたエレメンタリストリーム（ＥＳ）として出力するか、またはパケット化部１２５でＭＰＥＧ符号化されたトランスポートストリーム（ＴＳ）として出力する。
【００５６】
ＳＤＴＩ−ＣＰインタフェース４６，４７は、ＭＰＥＧ符号化されたエレメンタリストリーム（ＥＳ）を、ＳＤＴＩフォーマットのエレメンタリストリーム（ＥＳ）に変換して、ＳＤＴＩ−ＣＰネットワーク５０を介して、伝送する。ＳＤＴＩ−ＣＰインタフェース４８は、ＳＤＴＩフォーマットのエレメンタリストリーム（ＥＳ）をＭＰＥＧ符号化されたエレメンタリストリーム（ＥＳ）に変換し、ＭＰＥＧデコーダ４４に出力する。
【００５７】
ＭＰＥＧデコーダ４４は、入力されたアプリケーションＡのエレメンタリストリーム（ＥＳ）またはアプリケーションＢのエレメンタリストリーム（ＥＳ）を復号し、それぞれのエレメンタリストリーム（ＥＳ）に記述されている（図１６のデコードコントローラ１１３が出力する）ＣＰＩに基づいて、画像信号を有効画素エリアに配置するように復号する。
【００５８】
ＭＰＥＧエンコーダ４２，４３は、それぞれが符号化したアプリケーションの画像信号のＣＰＩをＭＰＥＧ符号化されたエレメンタリストリーム（ＥＳ）中のｕｓｅｒ ｄａｔａに記述することにより、画像データとともに、ＣＰＩを伝送することができる。また、ＭＰＥＧエンコーダ４２，４３は、ＣＰＩを伝送する機能を有することにより、様々なアプリケーションを符号化して伝送することができる。
【００５９】
ＭＰＥＧデコーダ４４は、ＭＰＥＧ符号化されたエレメンタリストリーム（ＥＳ）に挿入されているＣＰＩを分離、解釈することにより、様々なＣｏｄｉｎｇ Ｐｈａｓｅを有するアプリケーションの画像を、適切に、有効画素エリアに配置するように復号処理することができる。
【００６０】
なお、本発明に実施の形態においては、ＣＰＩを、ＭＰＥＧ符号化されたエレメンタリストリームのｕｓｅｒ ｄａｔａに挿入したが、ビットストリームに他の方法で挿入するようにしてもよい。
【００６１】
次に、ＭＰＥＧエンコーダ４２において、各フィールドごとの複数の補助データを識別する動作について、図１９を参照して説明する。３−２プルダウン処理が実施されている符号化フレームの原信号（３０Ｈｚ）の各フィールドに、補助データが挿入されているものとする。この補助データを有する原信号（３０Ｈｚ）が、元のフレームレートの符号化フレーム（２４Ｈｚ）に符号化されるとき、各符号化フレームに含まれる２つまたは３つのフィールドに記述されている補助データに、符号化されたフィールドに対応した識別子が、ｆｉｅｌｄ＿ＩＤ（０乃至２のカウンタの値）として付加されて（図１５のエンコードコントローラ１０２で補助データにｆｉｅｌｄ＿ＩＤが付加されて）、補助データともに伝送される。このｆｉｅｌｄ＿ＩＤが補助データに付加されることにより、補助データがどの符号化フレーム内の、どのフィールドに対応したものであるかが識別される。
【００６２】
具体的に説明すると、図１９の先頭の符号化フレームのフィールドの枚数は、２枚であるので、補助データは２つ存在する。符号化フレームは２枚のフィールドから生成され、その符号化フレームに対応する２枚のフィールドの、それぞれの補助データに、ｆｉｅｌｄ＿ＩＤとして、”０”または”１”が付加される。
【００６３】
先頭から２番目の符号化フレームのフィールドの枚数は、３枚であるので、補助データは３つ存在する。符号化フレームは３枚のフィールドから生成され、その符号化フレームに対応する３枚のフィールドの、それぞれの補助データに、ｆｉｅｌｄ＿ＩＤとして、”０”，”１”または”２”が付加される。
【００６４】
つまり、１枚の符号化フレームに対して、１つの補助データが生成されるのではなく、符号化フレームに含まれていたフィールドの枚数と同じ数の補助データが生成され、それぞれにｆｉｅｌｄ＿ＩＤが付加される。その結果、同一の符号化フレームに含まれる複数の補助データは、付加されたｆｉｅｌｄ＿ＩＤにより、符号化フレーム内で識別されるので、それぞれの補助データに異なった情報が含まれていても、識別できなくなることはない。
【００６５】
ＭＰＥＧエンコーダ４２では、画像データがＭＰＥＧエンコード部１０３でエンコードされ、可変長符号化部１０４で可変長符号化される。また、エンコードコントローラ１０２で補助データにｆｉｅｌｄ＿ＩＤと、補助データが挿入されていたライン番号（Ｌｉｎｅ＿ｎｕｍｂｅｒ）が付加され、エレメンタリストリーム中のｕｓｅｒ ｄａｔａ中に、ａｎｃｉｌｌａｒｙ ｄａｔａとして挿入される。これにより、複数の補助データを識別して伝送することができる。
【００６６】
ＭＰＥＧデコーダ４４では、ＭＰＥＧ符号化されたエレメンタリストリーム中のｕｓｅｒ ｄａｔａが可変長復号部１１２で分離され、デコードコントローラ１１３に供給される。デコードコントローラ１１３は、ｕｓｅｒ ｄａｔａに挿入されているａｎｃｉｌｌａｒｙ ｄａｔａのｆｉｅｌｄ＿ＩＤとＬｉｎｅ＿ｎｕｍｂｅｒに基づいて、複数の補助データを識別、分離し、合成部１１５に出力する。合成部１１５は、ＭＰＥＧデコード部１１４で復号された画像データと、それに対応する補助データ（テキストデータ）を合成し、出力する。
【００６７】
ＭＰＥＧエンコーダ４２は、システム全体の遅延を少なくするために、図２０に示すような符号化順序と表示順序を管理するＰＯＩを生成する。
【００６８】
例えば、ＭＰＥＧエンコーダ４２のＭＰＥＧエンコード部１０３に入力された画像データが、３−２プルダウン処理により、２４Ｈｚのフレームレートに変換された画像信号である場合、図２０（Ａ）に示すようなフラグ（Ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄ，Ｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔ）により、各フレームが管理される。
【００６９】
Ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄのフラグの”１”は、リピートフィールドを作成する必要があることを意味し、Ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄのフラグの”０”は、リピートフィールドを作成する必要がないことを意味する。Ｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔのフラグは、フレームを構成するフィールドのうち、最初のフィールドがトップフィールドであるのか、またはボトムフィールドであるのかを表している。Ｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔフラグの”１”は、トップフィールドがボトムフィールドより時間的に早いフレーム構造であることを表しており、Ｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔフラグの”０”は、ボトムフィールドがトップフィールドより時間的に早いフレーム構造であることを表している。
【００７０】
図２０（Ａ）について、具体的に説明すると、最初にＭＰＥＧエンコード部１０３に入力されるＦｒａｍｅ Ｎｏ１の符号化フレームの符号化画像データ種別は、Ｉピクチャであり、このＩピクチャの２フィールド（トップフィールドとボトムフィールド）は、トップフィールドをコピーしてリピートフィールドを作成することで、３フィールドに変換する必要があるので、対応するＲｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄのフラグは”１”となり、Ｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔのフラグは”１”となる。
【００７１】
Ｆｒａｍｅ Ｎｏ２の符号化フレームの符号化画像データ種別は、Ｂピクチャであり、このＢピクチャには、リピートフィールドが生成する必要がないので、Ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄのフラグは”０”とされ、ボトムフィールドがトップフィールドより時間的に早いフレームであるため、Ｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔのフラグは”０”とされる。このときのＴｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔのフラグの値は、３−２プルダウン処理には関係しない。
【００７２】
Ｆｒａｍｅ Ｎｏ３の符号化フレームの符号化画像データ種別は、Ｂピクチャであり、Ｆｒａｍｅ Ｎｏ３のＢピクチャでは、そのボトムフィールドをコピーしてリピートフィールドが作成され、符号化フレームが３フィールドに変換されている。従って、Ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄのフラグは”１”とされ、Ｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔのフラグは”０”とされる。
【００７３】
Ｆｒａｍｅ Ｎｏ４の符号化フレームの符号化画像データ種別は、Ｐピクチャであり、このＰピクチャに対しては、リピートフィールドが作成されておらず、Ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄのフラグは”０”とされ、Ｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔのフラグは１とされる。
【００７４】
ＭＰＥＧエンコード部１０３は、図２０（Ａ）に示すような３−２プルダウン処理が施された画像データが入力されてきたとき、内蔵するカウンタＰＴＳ＿ｃｏｕｎｔｅｒでフィールドの数をカウントし、その値ＰＴＳ＿ｃｏｕｎｔｅｒを表示順序としてエンコードコントローラ１０２に出力する。カウンタＰＴＳ＿ｃｏｕｎｔｅｒは、０から１２７まで増加した後、再び０に戻るカウント動作を行う。従って、カウンタＰＴＳ＿ｃｏｕｎｔｅｒの値は、図２０（Ｂ）に示すように変化する。
【００７５】
具体的に説明すると、最初に入力されるＦｒａｍｅ Ｎｏ１のＩピクチャのＰＴＳ＿ｃｏｕｎｔｅｒの値は値”０”である。先頭から２番目に入力されるＦｒａｍｅ Ｎｏ２のＢピクチャのＰＴＳ＿ｃｏｕｎｔｅｒの値は、Ｆｒａｍｅ Ｎｏ１のＩピクチャのＰＴＳ＿ｃｏｕｎｔｅｒの値”０”に、Ｐピクチャのフィールド数３を加算した値”３”（＝０＋３）となる。
【００７６】
先頭から３番目に入力されるＦｒａｍｅ Ｎｏ３のＢピクチャのＰＴＳ＿ｃｏｕｎｔｅｒの値は、Ｆｒａｍｅ Ｎｏ２のＢピクチャのＰＴＳ＿ｃｏｕｎｔｅｒの値”３”に、Ｂピクチャのフィールド数２を加算した値”５”（＝３＋２）となる。先頭から４番目に入力されるＦｒａｍｅ Ｎｏ４のＰピクチャのＰＴＳ＿ｃｏｕｎｔｅｒの値は、Ｆｒａｍｅ Ｎｏ３のＢピクチャのＰＴＳ＿ｃｏｕｎｔｅｒの値”５”に、Ｂピクチャのフィールド数３を加算した値”８”（＝５＋３）となる。Ｆｒａｍｅ Ｎｏ５のＢピクチャ以降のＰＴＳ＿ｃｏｕｎｔｅｒの値も同様に算出される。
【００７７】
さらに、ＭＰＥＧエンコード部１０３は、内蔵するカウンタＤＴＳ＿ｃｏｕｎｔｅｒでエンコードしたフレームを計数し、計数した結果をエンドコントローラ１０２に出力する。
【００７８】
図２０（Ｃ）を参照して、具体的に説明すると、Ｆｒａｍｅ Ｎｏ１のＩピクチャのＤＴＳ＿ｃｏｕｎｔｅｒの値１２５は、Ｆｒａｍｅ Ｎｏ１のＩピクチャが表示される表示順序ＰＴＳ＿ｃｏｕｎｔｅｒ＝０を基準としたとき、１フレーム分の出現周期前に符号化される必要がある（図１４に対応させると、先頭のＩピクチャの符号化順序の値は”１”であり、表示順序の値は”２”であり、符号化順序の値は表示順序の値より１フレーム分早い必要がある）。つまり、Ｉピクチャが３つのフィールドを持っているため、ＤＴＳ＿ｃｏｕｎｔｅｒの値は、０より３だけ前の値”１２５”（ＤＴＳ＿ｃｏｕｎｔｅｒは２７（＝１２８）のモジュロで表されるため、その値は０から１２７の間の値を循環する）となる。
【００７９】
Ｆｒａｍｅ Ｎｏ１のＩピクチャの次に符号化されるＦｒａｍｅ Ｎｏ４のＰピクチャのＤＴＳ＿ｃｏｕｎｔｅｒの値は、Ｆｒａｍｅ Ｎｏ１のＩピクチャのＤＴＳ＿ｃｏｕｎｔｅｒの値１２５にＩピクチャのフィールド数３を加えた値０（＝１２８＝１２５＋３）となる。
【００８０】
Ｆｒａｍｅ Ｎｏ４のＰピクチャの次に符号化される、Ｆｒａｍｅ Ｎｏ２のＢピクチャのＤＴＳ＿ｃｏｕｎｔｅｒの値は、ＢピクチャのためにＰＴＳ＿ｃｏｕｎｔｅｒ＝ＤＴＳ＿ｃｏｕｎｔｅｒであり、ＰＴＳ＿ｃｏｕｎｔｅｒの値と同一とされ、その値は”３”となる。同様に、Ｆｒａｍｅ Ｎｏ２のＢピクチャの次に符号化される、Ｆｒａｍｅ Ｎｏ３のＢピクチャのＤＴＳ＿ｃｏｕｎｔｅｒの値も、ＰＴＳ＿ｃｏｕｎｔｅｒの値と同一とされ、その値は”５”とされる。以下、Ｆｒａｍｅ Ｎｏ７のＰピクチャ以降のＤＴＳ＿ｃｏｕｎｔｅｒの値も、同様に算出されるので、ここでは、その説明を省略する。
【００８１】
ＭＰＥＧエンコード部１０３は、図２０に示すようなフラグＲｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄ，Ｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔ、並びにカウンタＰＴＳ＿ｃｏｕｎｔｅｒ，ＤＴＳ＿ｃｏｕｎｔｅｒをＰＯＩとして、エンコードコントローラ１０２に出力する。
【００８２】
ここで、図１１に示した、離れた場所にあるスタジオ４１のＭＰＥＧエンコーダ４２から、スタジオ７１のＭＰＥＧデコーダ７４に、ＳＤＴＩ−ＣＰネットワーク５０，８０、ＴＳ ＭＵＸ／ＤＥＭＵＸ６１，６２、およびＡＴＭのネットワークを使用して、画像信号の伝送を行うシステムの、符号化順序と表示順序について、図２１を参照して説明する。
【００８３】
ＭＰＥＧエンコーダ４２内のＭＰＥＧビデオエンコーダ４２Ａは、ＭＰＥＧ符号化された画像データのエレメンタリストリーム（ＥＳ）を出力するとともに、ＰＯＩを、そのエレメンタリストリーム（ＥＳ）中のｕｓｅｒ ｄａｔａに挿入する（図１５のエンコードコントローラ１０２がＰＯＩのデータをｕｓｅｒ ｄａｔａに記述し、可変長符号化部１０４に出力して、多重化させる）。ＭＰＥＧエンコーダ４２内のオーディオエンコーダ４２Ｂは、音声データを符号化してエレメンタリストリーム（ＥＳ）として出力する。ＳＤＴＩ−ＣＰインタフェース４６は、ＭＰＥＧビデオエンコーダ４２Ａからのエレメンタリストリーム（ＥＳ）（ＰＯＩを含んだストリーム）と、オーディオエンコーダ４２Ｂからのエレメンタリストリーム（ＥＳ）を、ＳＤＴＩフォーマットのエレメンタリストリームに変換して、ＳＤＴＩ−ＣＰネットワーク５０に出力する。
【００８４】
ＳＤＴＩ−ＣＰインタフェース５１は、入力されたＳＤＴＩフォーマットのエレメンタリストリーム（ＥＳ）を、ＭＰＥＧ符号化のエレメンタリストリーム（ＥＳ）に変換し（図１８を参照してＳＤＴＩ−ＣＰインタフェース４６の動作として説明したように）、ＴＳ ＭＵＸ／ＤＥＭＵＸ６１に出力する。ＴＳ ＭＵＸ／ＤＥＭＵＸ６１は、エレメンタリストリーム（ＥＳ）に挿入されているＰＯＩを参照して、ＰＴＳ＿ｃｏｕｎｔｅｒの値をＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ Ｓｔａｍｐ）に、また、ＤＴＳ＿ｃｏｕｎｔｅｒの値をＤＴＳ（Ｄｅｃｏｄｉｎｇ Ｔｉｍｅ Ｓｔａｍｐ）に、それぞれ換算し、多重化処理を行い、１８８バイト単位のパケットから構成されるトランスポートストリーム（ＴＳ）を生成して出力する（従って、トランスポートストリーム（ＴＳ）には、ＰＴＳ＿ｃｏｕｎｔｅｒとＤＴＳ＿ｃｏｕｎｔｅｒではなく、ＰＴＳとＤＴＳが含まれる）。
【００８５】
ＴＳ ＭＵＸ／ＤＥＭＵＸ６１は、エレメンタリストリーム（ＥＳ）に挿入されているＰＯＩを解釈することにより、前述のバッファリング処理を行うことなく、直ちに多重化処理を行うことができ、ＴＳ ＭＵＸ／ＤＥＭＵＸ６１において、新たに遅延が発生することはない。また、ＰＯＩはエレメンタリストリーム（ＥＳ）中に挿入されているため、ＴＳ ＭＵＸ／ＤＥＭＵＸ６１は、ＰＯＩを後段に伝達するために、ＰＯＩをビットストリームに含ませる処理を行わなくてもよい。
【００８６】
図１１のＴＳ ＭＵＸ／ＤＥＭＵＸ６２は、ＡＴＭなどの公衆網を介して入力されたトランスポートストリーム（ＴＳ）から画像データと音声データを分離して、ＭＰＥＧ符号化のエレメンタリストリーム（ＥＳ）に変換する。ＴＳ ＭＵＸ／ＤＥＭＵＸ６２はまた、ＰＴＳ，ＤＴＳをＰＴＳ＿ｃｏｕｎｔｅｒ，ＤＴＳ＿ｃｏｕｎｔｅｒに換算して、エレメンタリストリームのｕｓｅｒ ｄａｔａに挿入し、ＳＤＴＩ−ＣＰインタフェース８１に出力する。ＳＤＴＩ−ＣＰインタフェース８１は、ＭＰＥＧ符号化されたエレメンタリストリーム（ＥＳ）をＳＤＴＩフォーマットのエレメンタリストリーム（ＥＳ）に変換し、スタジオ７１のＳＤＴＩ−ＣＰネットワーク８０に出力する。ＭＰＥＧデコーダ７４（ＭＰＥＧデコーダ４４と同一の構成）は、ＳＤＴＩ−ＣＰインタフェース７８を介して、伝送されてきた画像データと音声データのエレメンタリストリーム（ＥＳ）を受信し、復号する。
【００８７】
ＭＰＥＧデコーダ７４は、ＴＳ ＭＵＸ／ＤＥＭＵＸ６１と同様に、エレメンタリストリーム（ＥＳ）に挿入されているＰＯＩを解釈して、前述のバッファリング処理を行うことなく、直ちに復号する（図１６のデコードコントローラ１１３が出力するＰＯＩに基づき、ＭＰＥＧデコード部１１４が画像データを復号する）ことができ、ＭＰＥＧデコーダ７４において、新たに遅延が発生することはない。つまり、ＭＰＥＧビデオエンコーダ４２Ａが、ＭＰＥＧ符号化されたエレメンタリストリーム（ＥＳ）とともに、ＰＯＩをエレメンタリストリームに挿入して出力することにより、後段のＴＳ ＭＵＸ／ＤＥＭＵＸ６１と、ＭＰＥＧデコーダ７４は、ＰＯＩを解釈して多重化処理、または復号処理を直ちに行うことができ、システム全体としての遅延を、ＭＰＥＧエンコーダ４２で生ずるＢピクチャの枚数（＝２）＋１枚＝３の遅延のみに抑えることができる。すなわち、このような符号化、多重化、および復号を含むシステムにおいて、理論的に最も小さい遅延とすることができる。
【００８８】
また、図２１のシステム構成において、図１８に示したＳＤＴＩ−ＣＰインタフェース４６を用いることにより、ＳＤＴＩ−ＣＰネットワーク５０を使用して画像信号を伝送するとき、スタジオ４１の内部では、ビットストリームを、編集が容易で、短距離伝送に適したエレメンタリストリーム（ＥＳ）の形態で伝送することが可能となり、離れたスタジオ間でＡＴＭなどの公衆網を使用して画像信号を伝送するとき、ビットストリームを、長距離伝送に適したトランスポートストリーム（ＴＳ）の形態で伝送することが可能となる。
【００８９】
以上においては、ＰＯＩをエレメンタリストリームに挿入するようにしたが、ＴＳ ＭＵＸ／ＤＥＭＵＸ６１とＭＰＥＧエンコーダ４２の距離が近いような場合には、図２２に示すように、ＰＯＩをＭＰＥＧエンコーダ４２から、ＴＳ ＭＵＸ／ＤＥＭＵＸ６１に直接供給するようにしてもよい。
【００９０】
しかしながら、このようにすると、エレメンタリストリームを伝送するＳＤＴＩ−ＣＰネットワーク５０以外の配線処理が必要となる。
【００９１】
以上に述べたように、エンコーダの有する情報を、エレメンタリストリーム（ＥＳ）中のｕｓｅｒ ｄａｔａに記述して、多重化装置またはデコーダに出力することにより、エンコーダのみが有していた情報（Ｃｏｄｉｎｇ Ｐｈａｓｅ（Ｖ−ＰｈａｓｅとＨ−Ｐｈａｓｅ）、Ｆｉｅｌｄ＿ＩＤ、符号化順序ＤＴＳ＿ｃｏｕｎｔｅｒ、および表示順序ＰＴＳ＿ｃｏｕｎｔｅｒ）を、エンコーダより後段の多重化装置、デコーダに供給することができる。
【００９２】
次に、図２３乃至図３６を参照してビットストリームのシンタックスについて説明する。
【００９３】
図２３は、ＭＰＥＧのビデオストリームのシンタックスを表わした図である。ＭＰＥＧエンコーダ４２は、この図２３に示されたシンタックスに従った符号化エレメンタリストリームを生成する。以下に説明するシンタックスにおいて、関数や条件文は細活字で表わされ、データエレメントは、太活字で表されている。データ項目は、その名称、ビット長およびそのタイプ・伝送順序を示すニーモニック（Ｍｎｅｍｏｎｉｃ）で記述されている。
【００９４】
まず、この図２３に示されているシンタックスにおいて使用されている関数について説明する。実際には、この図２３に示されているシンタックスは、ＭＰＥＧデコーダ４４側において、伝送されてきた符号化ビットストリームから所定の意味のあるデータエレメントを抽出するために使用されるシンタックスである。ＭＰＥＧエンコーダ４２側において使用されるシンタックスは、図２３に示されたシンタックスからｉｆ文やｗｈｉｌｅ文等の条件文を省略したシンタックスである。
【００９５】
ｖｉｄｅｏ＿ｓｅｑｕｅｎｃｅ（）において最初に記述されているｎｅｘｔ＿ｓｔａｒｔ＿ｃｏｄｅ（）関数は、ビットストリーム中に記述されているスタートコードを探すための関数である。この図２３に示されたシンタックスに従って生成された符号化ストリームには、まず最初に、ｓｅｑｕｅｎｃｅ＿ｈｅａｄｅｒ（）関数とｓｅｑｕｅｎｃｅ＿ｅｘｔｅｎｓｉｏｎ（）関数によって定義されたデータエレメントが記述されている。このｓｅｑｕｅｎｃｅ＿ｈｅａｄｅｒ（）関数は、ＭＰＥＧビットストリームのシーケンスレイヤのヘッダデータを定義するための関数であって、ｓｅｑｕｅｎｃｅ＿ｅｘｔｅｎｓｉｏｎ（）関数は、ＭＰＥＧビットストリームのシーケンスレイヤの拡張データを定義するための関数である。
【００９６】
ｓｅｑｕｅｎｃｅ＿ｅｘｔｅｎｓｉｏｎ（）関数の次に配置されている ｄｏ｛ ｝ｗｈｉｌｅ構文は、ｗｈｉｌｅ文によって定義されている条件が真である間、ｄｏ文の｛ ｝内の関数に基いて記述されたデータエレメントが符号化データストリーム中に記述されていることを示す構文である。このｗｈｉｌｅ文に使用されているｎｅｘｔｂｉｔｓ（）関数は、ビットストリーム中に記述されているビット又はビット列と、参照されるデータエレメントとを比較するための関数である。この図２３に示されたシンタックスの例では、ｎｅｘｔｂｉｔｓ（）関数は、ビットストリーム中のビット列とビデオシーケンスの終わりを示すｓｅｑｕｅｎｃｅ＿ｅｎｄ＿ｃｏｄｅとを比較し、ビットストリーム中のビット列とｓｅｑｕｅｎｃｅ＿ｅｎｄ＿ｃｏｄｅとが一致しないときに、このｗｈｉｌｅ文の条件が真となる。従って、ｓｅｑｕｅｎｃｅ＿ｅｘｔｅｎｓｉｏｎ（）関数の次に配置されている ｄｏ｛ ｝ｗｈｉｌｅ構文は、ビットストリーム中に、ビデオシーケンスの終わりを示すｓｅｑｕｅｎｃｅ＿ｅｎｄ＿ｃｏｄｅが現れない間、ｄｏ文中の関数によって定義されたデータエレメントが符号化ビットストリーム中に記述されていることを示している。
【００９７】
符号化ビットストリームにおいて、ｓｅｑｕｅｎｃｅ＿ｅｘｔｅｎｓｉｏｎ（）関数によって定義された各データエレメントの次には、ｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（０）関数によって定義されたデータエレメントが記述されている。このｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（０）関数は、ＭＰＥＧビットストリームのシーケンスレイヤにおける拡張データとユーザデータを定義するための関数である。
【００９８】
このｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（０）関数の次に配置されている ｄｏ｛ ｝ｗｈｉｌｅ構文は、ｗｈｉｌｅ文によって定義されている条件が真である間、ｄｏ文の｛ ｝内の関数に基いて記述されたデータエレメントが、ビットストリームに記述されていることを示す関数である。このｗｈｉｌｅ文において使用されているｎｅｘｔｂｉｔｓ（）関数は、ビットストリーム中に現れるビット又はビット列と、ｐｉｃｔｕｒｅ＿ｓｔａｒｔ＿ｃｏｄｅ又はｇｒｏｕｐ＿ｓｔａｒｔ＿ｃｏｄｅとの一致を判断するための関数であるって、ビットストリーム中に現れるビット又はビット列と、ｐｉｃｔｕｒｅ＿ｓｔａｒｔ＿ｃｏｄｅ又はｇｒｏｕｐ＿ｓｔａｒｔ＿ｃｏｄｅとが一致する場合には、ｗｈｉｌｅ文によって定義された条件が真となる。よって、このｄｏ｛ ｝ｗｈｉｌｅ構文は、符号化ビットストリーム中において、ｐｉｃｔｕｒｅ＿ｓｔａｒｔ＿ｃｏｄｅ又はｇｒｏｕｐ＿ｓｔａｒｔ＿ｃｏｄｅが現れた場合には、そのスタートコードの次に、ｄｏ文中の関数によって定義されたデータエレメントのコードが記述されていることを示している。
【００９９】
このｄｏ文の最初に記述されているｉｆ文は、符号化ビットストリーム中にｇｒｏｕｐ＿ｓｔａｒｔ＿ｃｏｄｅが現れた場合、という条件を示しいる。このｉｆ文による条件は真である場合には、符号化ビットストリーム中には、このｇｒｏｕｐ＿ｓｔａｒｔ＿ｃｏｄｅの次にｇｒｏｕｐ＿ｏｆ＿ｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）関数およびｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（１）関数によって定義されているデータエレメントが順に記述されている。
【０１００】
このｇｒｏｕｐ＿ｏｆ＿ｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）関数は、ＭＰＥＧ符号化ビットストリームのＧＯＰレイヤのヘッダデータを定義するための関数であって、ｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（１）関数は、ＭＰＥＧ符号化ビットストリームのＧＯＰレイヤの拡張データおよびユーザデータを定義するための関数である。
【０１０１】
さらに、この符号化ビットストリームにおいて、ｇｒｏｕｐ＿ｏｆ＿ｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）関数およびｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（１）関数によって定義されているデータエレメントの次には、ｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）関数とｐｉｃｔｕｒｅ＿ｃｏｄｉｎｇ＿ｅｘｔｅｎｓｉｏｎ（）関数によって定義されたデータエレメントが記述されている。もちろん、先に説明したｉｆ文の条件が真とならない場合には、 ｇｒｏｕｐ＿ｏｆ＿ｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）関数およびｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（１）関数によって定義されているデータエレメントは記述されていないので、 ｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（０）関数によって定義されているデータエレメントの次に、ｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）関数、ｐｉｃｔｕｒｅ＿ｃｏｄｉｎｇ＿ｅｘｔｅｎｓｉｏｎ（）関数およびｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（２）関数によって定義されたデータエレメントが記述されている。
【０１０２】
このｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）関数は、ＭＰＥＧ符号化ビットストリームのピクチャレイヤのヘッダデータを定義するための関数であって、ｐｉｃｔｕｒｅ＿ｃｏｄｉｎｇ＿ｅｘｔｅｎｓｉｏｎ（）関数は、ＭＰＥＧ符号化ビットストリームのピクチャレイヤの第１の拡張データを定義するための関数である。ｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（２）関数は、ＭＰＥＧ符号化ビットストリームのピクチャレイヤの拡張データおよびユーザデータを定義するための関数である。このｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（２）関数によって定義されるユーザデータは、ピクチャレイヤに記述されているデータであって、各ピクチャ毎に記述することのできるデータである。
【０１０３】
符号化ビットストリームにおいて、ピクチャレイヤのユーザデータの次には、ｐｉｃｔｕｒｅ＿ｄａｔａ（）関数によって定義されるデータエレメントが記述されている。このｐｉｃｔｕｒｅ＿ｄａｔａ（）関数は、スライスレイヤおよびマクロブロックレイヤに関するデータエレメントを記述するための関数である。
【０１０４】
このｐｉｃｔｕｒｅ＿ｄａｔａ（）関数の次に記述されているｗｈｉｌｅ文は、このｗｈｉｌｅ文によって定義されている条件が真である間、次のｉｆ文の条件判断を行うための関数である。このｗｈｉｌｅ文において使用されているｎｅｘｔｂｉｔｓ（）関数は、符号化ビットストリーム中に、ｐｉｃｔｕｒｅ＿ｓｔａｒｔ＿ｃｏｄｅ又はｇｒｏｕｐ＿ｓｔａｒｔ＿ｃｏｄｅが記述されているか否かを判断するための関数であって、ビットストリーム中にｐｉｃｔｕｒｅ＿ｓｔａｒｔ＿ｃｏｄｅ又はｇｒｏｕｐ＿ｓｔａｒｔ＿ｃｏｄｅが記述されている場合には、このｗｈｉｌｅ文によって定義された条件が真となる。
【０１０５】
次のｉｆ文は、符号化ビットストリーム中にｓｅｑｕｅｎｃｅ＿ｅｎｄ＿ｃｏｄｅ が記述されているか否かを判断するための条件文であって、ｓｅｑｕｅｎｃｅ＿ｅｎｄ＿ｃｏｄｅ が記述されていないのであれば、ｓｅｑｕｅｎｃｅ＿ｈｅａｄｅｒ（）関数とｓｅｑｕｅｎｃｅ＿ｅｘｔｅｎｓｉｏｎ（）関数とによって定義されたデータエレメントが記述されていることを示している。ｓｅｑｕｅｎｃｅ＿ｅｎｄ＿ｃｏｄｅは符号化ビデオストリームのシーケンスの終わりを示すコードであるので、符号化ストリームが終了しない限り、符号化ストリーム中にはｓｅｑｕｅｎｃｅ＿ｈｅａｄｅｒ（）関数とｓｅｑｕｅｎｃｅ＿ｅｘｔｅｎｓｉｏｎ（）関数とによって定義されたデータエレメントが記述されている。
【０１０６】
このｓｅｑｕｅｎｃｅ＿ｈｅａｄｅｒ（）関数とｓｅｑｕｅｎｃｅ＿ｅｘｔｅｎｓｉｏｎ（）関数によって記述されたデータエレメントは、ビデオストリームのシーケンスの先頭に記述されたｓｅｑｕｅｎｃｅ＿ｈｅａｄｅｒ（）関数とｓｅｑｕｅｎｃｅ＿ｅｘｔｅｎｓｉｏｎ（）関数によって記述されたデータエレメントと全く同じである。このように同じデータをストリーム中に記述する理由は、ビットストリーム受信装置側でデータストリームの途中（例えばピクチャレイヤに対応するビットストリーム部分）から受信が開始された場合に、シーケンスレイヤのデータを受信できなくなり、ストリームをデコード出来なくなることを防止するためである。
【０１０７】
この最後のｓｅｑｕｅｎｃｅ＿ｈｅａｄｅｒ（）関数とｓｅｑｕｅｎｃｅ＿ｅｘｔｅｎｓｉｏｎ（）関数とによって定義されたデータエレメントの次、つまり、データストリームの最後には、シーケンスの終わりを示す２ビットのｓｅｑｕｅｎｃｅ＿ｅｎｄ＿ｃｏｄｅが記述されている。
【０１０８】
以下に、ｓｅｑｕｅｎｃｅ＿ｈｅａｄｅｒ（）関数、ｓｅｑｕｅｎｃｅ＿ｅｘｔｅｎｓｉｏｎ（）関数、ｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（０）関数、ｇｒｏｕｐ＿ｏｆ＿ｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）関数、ｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）関数、ｐｉｃｔｕｒｅ＿ｃｏｄｉｎｇ＿ｅｘｔｅｎｓｉｏｎ（）関数、およびｐｉｃｔｕｒｅ＿ｄａｔａ（）関数について詳細に説明する。
【０１０９】
図２４は、ｓｅｑｕｅｎｃｅ＿ｈｅａｄｅｒ（）関数のシンタックスを説明するための図である。このｓｅｑｕｅｎｃｅ＿ｈｅａｄｅｒ（）関数によって定義されたデータエレメントは、ｓｅｑｕｅｎｃｅ＿ｈｅａｄｅｒ＿ｃｏｄｅ、ｈｏｒｉｚｏｎｔａｌ＿ｓｉｚｅ＿ｖａｌｕｅ、ｖｅｒｔｉｃａｌ＿ｓｉｚｅ＿ｖａｌｕｅ、ａｓｐｅｃｔ＿ｒａｔｉｏ＿ｉｎｆｏｒｍａｔｉｏｎ、ｆｒａｍｅ＿ｒａｔｅ＿ｃｏｄｅ、ｂｉｔ＿ｒａｔｅ＿ｖａｌｕｅ、ｍａｒｋｅｒ＿ｂｉｔ、ｖｂｖ＿ｂｕｆｆｅｒ＿ｓｉｚｅ＿ｖａｌｕｅ、ｃｏｎｓｔｒａｉｎｅｄ＿ｐａｒａｍｅｔｅｒ＿ｆｌａｇ、ｌｏａｄ＿ｉｎｔｒａ＿ｑｕａｎｔｉｚｅｒ＿ｍａｔｒｉｘ、ｉｎｔｒａ＿ｑｕａｎｔｉｚｅｒ＿ｍａｔｒｉｘ［６４］、ｌｏａｄ＿ｎｏｎ＿ｉｎｔｒａ＿ｑｕａｎｔｉｚｅｒ＿ｍａｔｒｉｘ、およびｎｏｎ＿ｉｎｔｒａ＿ｑｕａｎｔｉｚｅｒ＿ｍａｔｒｉｘ等である。
【０１１０】
ｓｅｑｕｅｎｃｅ＿ｈｅａｄｅｒ＿ｃｏｄｅは、シーケンスレイヤのスタート同期コードを表すデータである。ｈｏｒｉｚｏｎｔａｌ＿ｓｉｚｅ＿ｖａｌｕｅは、画像の水平方向の画素数の下位１２ビットから成るデータである。ｖｅｒｔｉｃａｌ＿ｓｉｚｅ＿ｖａｌｕｅは、画像の縦のライン数の下位１２ビットからなるデータである。ａｓｐｅｃｔ＿ｒａｔｉｏ＿ｉｎｆｏｒｍａｔｉｏｎは、画素のアスペクト比（縦横比）または表示画面アスペクト比を表すデータである。ｆｒａｍｅ＿ｒａｔｅ＿ｃｏｄｅは、画像の表示周期を表すデータである。ｂｉｔ＿ｒａｔｅ＿ｖａｌｕｅは、発生ビット量に対する制限のためのビット・レートの下位１８ビット（４００ｂｓｐ単位で切り上げる）データである。ｍａｒｋｅｒ＿ｂｉｔは、スタートコードエミュレーションを防止するために挿入されるビットデータである。ｖｂｖ＿ｂｕｆｆｅｒ＿ｓｉｚｅ＿ｖａｌｕｅは、発生符号量制御用の仮想バッファ（ビデオバッファベリファイヤー）の大きさを決める値の下位１０ビットデータである。ｃｏｎｓｔｒａｉｎｅｄ＿ｐａｒａｍｅｔｅｒ＿ｆｌａｇは、各パラメータが制限以内であることを示すデータである。ｌｏａｄ＿ｉｎｔｒａ＿ｑｕａｎｔｉｚｅｒ＿ｍａｔｒｉｘは、イントラＭＢ用量子化マトリックス・データの存在を示すデータである。ｉｎｔｒａ＿ｑｕａｎｔｉｚｅｒ＿ｍａｔｒｉｘ［６４］は、イントラＭＢ用量子化マトリックスの値を示すデータである。ｌｏａｄ＿ｎｏｎ＿ｉｎｔｒａ＿ｑｕａｎｔｉｚｅｒ＿ｍａｔｒｉｘは、非イントラＭＢ用量子化マトリックス・データの存在を示すデータである。ｎｏｎ＿ｉｎｔｒａ＿ｑｕａｎｔｉｚｅｒ＿ｍａｔｒｉｘは、非イントラＭＢ用量子化マトリックスの値を表すデータである。
【０１１１】
図２５はｓｅｑｕｅｎｃｅ＿ｅｘｔｅｎｓｉｏｎ（）関数のシンタックスを説明するための図である。このｓｅｑｕｅｎｃｅ＿ｅｘｔｅｎｓｉｏｎ（）関数によって定義されたデータエレメントとは、ｅｘｔｅｎｓｉｏｎ＿ｓｔａｒｔ＿ｃｏｄｅ、ｅｘｔｅｎｓｉｏｎ＿ｓｔａｒｔ＿ｃｏｄｅ＿ｉｄｅｎｔｉｆｉｅｒ、ｐｒｏｆｉｌｅ＿ａｎｄ＿ｌｅｖｅｌ＿ｉｎｄｉｃａｔｉｏｎ、ｐｒｏｇｒｅｓｓｉｖｅ＿ｓｅｑｕｅｎｃｅ、ｃｈｒｏｍａ＿ｆｏｒｍａｔ、ｈｏｒｉｚｏｎｔａｌ＿ｓｉｚｅ＿ｅｘｔｅｎｓｉｏｎ、ｖｅｒｔｉｃａｌ＿ｓｉｚｅ＿ｅｘｔｅｎｓｉｏｎ、ｂｉｔ＿ｒａｔｅ＿ｅｘｔｅｎｓｉｏｎ、ｖｂｖ＿ｂｕｆｆｅｒ＿ｓｉｚｅ＿ｅｘｔｅｎｓｉｏｎ、ｌｏｗ＿ｄｅｌａｙ、ｆｒａｍｅ＿ｒａｔｅ＿ｅｘｔｅｎｓｉｏｎ＿ｎ 、および ｆｒａｍｅ＿ｒａｔｅ＿ｅｘｔｅｎｓｉｏｎ＿ｄ等のデータエレメントである。
【０１１２】
ｅｘｔｅｎｓｉｏｎ＿ｓｔａｒｔ＿ｃｏｄｅは、エクステンションデータのスタート同期コードを表すデータである。ｅｘｔｅｎｓｉｏｎ＿ｓｔａｒｔ＿ｃｏｄｅ＿ｉｄｅｎｔｉｆｉｅｒは、どの拡張データが送られるかを示すデータである。ｐｒｏｆｉｌｅ＿ａｎｄ＿ｌｅｖｅｌ＿ｉｎｄｉｃａｔｉｏｎは、ビデオデータのプロファイルとレベルを指定するためのデータである。ｐｒｏｇｒｅｓｓｉｖｅ＿ｓｅｑｕｅｎｃｅは、ビデオデータが順次走査であることを示すデータである。ｃｈｒｏｍａ＿ｆｏｒｍａｔは、ビデオデータの色差フォーマットを指定するためのデータである。ｈｏｒｉｚｏｎｔａｌ＿ｓｉｚｅ＿ｅｘｔｅｎｓｉｏｎは、シーケンスヘッダのｈｏｒｉｚｎｔａｌ＿ｓｉｚｅ＿ｖａｌｕｅに加える上位２ビットのデータである。ｖｅｒｔｉｃａｌ＿ｓｉｚｅ＿ｅｘｔｅｎｓｉｏｎは、シーケンスヘッダのｖｅｒｔｉｃａｌ＿ｓｉｚｅ＿ｖａｌｕｅ加える上位２ビットのデータである。ｂｉｔ＿ｒａｔｅ＿ｅｘｔｅｎｓｉｏｎは、シーケンスヘッダのｂｉｔ＿ｒａｔｅ＿ｖａｌｕｅに加える上位１２ビットのデータである。ｖｂｖ＿ｂｕｆｆｅｒ＿ｓｉｚｅ＿ｅｘｔｅｎｓｉｏｎは、シーケンスヘッダのｖｂｖ＿ｂｕｆｆｅｒ＿ｓｉｚｅ＿ｖａｌｕｅに加える上位８ビットのデータである。ｌｏｗ＿ｄｅｌａｙは、Ｂピクチャを含まないことを示すデータである。ｆｒａｍｅ＿ｒａｔｅ＿ｅｘｔｅｎｓｉｏｎ＿ｎは、シーケンスヘッダのｆｒａｍｅ＿ｒａｔｅ＿ｃｏｄｅと組み合わせてフレームレートを得るためのデータである。ｆｒａｍｅ＿ｒａｔｅ＿ｅｘｔｅｎｓｉｏｎ＿ｄは、シーケンスヘッダのｆｒａｍｅ＿ｒａｔｅ＿ｃｏｄｅと組み合わせてフレームレートを得るためのデータである。
【０１１３】
図２６は、ｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（ｉ）関数のシンタックスを説明するための図である。このｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（ｉ）関数は、「ｉ」が１以外のときは、ｅｘｔｅｎｓｉｏｎ＿ｄａｔａ（）関数によって定義されるデータエレメントは記述せずに、ｕｓｅｒ＿ｄａｔａ（）関数によって定義されるデータエレメントのみを記述する。よって、ｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（０）関数は、ｕｓｅｒ＿ｄａｔａ（）関数によって定義されるデータエレメントのみを記述する。
【０１１４】
まず、図２６に示されているシンタックスにおいて使用されている関数について説明する。ｎｅｘｔｂｉｔｓ（）関数は、ビットストリーム中に現れるビットまたはビット列と、次に復号されるデータエレメントとを比較するための関数である。
【０１１５】
ｕｓｅｒ＿ｄａｔａ（）関数は、図２７に示すように、ｕｓｅｒ＿ｄａｔａ＿ｓｔａｒｔ＿ｃｏｄｅ，Ｖ−ｐｈａｓｅ（）関数，Ｈ−ｐｈａｓｅ（）関数，Ｔｉｍｅ＿ｃｏｄｅ（）関数，Ｐｉｃｔｕｒｅ−ｏｒｄｅｒ（）関数，Ａｎｃｉｌｌａｒｙ＿ｄａｔａ（）関数，ｈｉｓｔｏｒｙ＿ｄａｔａ（）関数，およびｕｓｅｒ＿ｄａｔａのデータエレメントを記述するための関数である。
【０１１６】
ｕｓｅｒ＿ｄａｔａ＿ｓｔａｒｔ＿ｃｏｄｅは、ＭＰＥＧ方式のビットストリームのピクチャレイヤのユーザデータエリアの開始を示すためのスタートコードである。このｕｓｅｒ＿ｄａｔａ＿ｓｔａｒｔ＿ｃｏｄｅの次に記述されているｉｆ文は、ｕｓｅｒ＿ｄａｔａ（ｉ）関数のｉが”０”のとき、次に記述されているｗｈｉｌｅ構文を実行する。このｗｈｉｌｅ構文は、ビットストリーム中に、２３個の”０”とそれに続く”１”から構成される２４ビットのデータが現れない限り真となる。
【０１１７】
この２３個の”０”とそれに続く”１”から構成される２４ビットのデータは、すべてのスタートコードの先頭に付与されるデータであって、すべてのスタートコードは、この２４ビットの後ろに設けられることによって、ｎｅｘｔｂｉｔｓ（）関数は、ビットストリーム中において、各スタートコードの位置を見つけることができる。
【０１１８】
ｗｈｉｌｅ構文が真のとき、その次に記述されているｉｆ文のｎｅｘｔｂｉｔｓ（）関数は、Ｖ−Ｐｈａｓｅを示すビット列（Ｄａｔａ＿ＩＤ）を検出すると、そのビット列（Ｄａｔａ＿ＩＤ）の次ビットからＶ−Ｐｈａｓｅ（）関数で示されるＶ−Ｐｈａｓｅのデータエレメントが記述されていることを知る。次のＥｌｓｅ ｉｆ文のｎｅｘｔｂｉｔｓ（）関数は、Ｈ−Ｐｈａｓｅを示すビット列（Ｄａｔａ＿ＩＤ）を検出すると、そのビット列（Ｄａｔａ＿ＩＤ）の次ビットからＨ−Ｐｈａｓｅ（）関数で示されるＨ−Ｐｈａｓｅのデータエレメントが記述されていることを知る。
【０１１９】
ここで、図２８に示すように、Ｖ−ＰｈａｓｅのＤａｔａ＿ＩＤは、”０１”を表すビット列であり、Ｈ−ＰｈａｓｅのＤａｔａ＿ＩＤは、”０２”を表すビット列である。
【０１２０】
ビットストリームに記述されるＶ−Ｐｈａｓｅ（）関数のシンタックスについて、図２９を参照して説明する。まず、Ｄａｔａ＿ＩＤは、前述したように、そのＤａｔａ＿ＩＤの次のビット列のデータエレメントがＶ−Ｐｈａｓｅであることを表す８ビットのデータであり、図２８で示した値”０１”である。Ｖ−Ｐｈａｓｅは、画像信号のフレームにおいて、符号化される最初のラインを示す１６ビットのデータである。
【０１２１】
ビットストリームに記述されるＨ−Ｐｈａｓｅ（）関数のシンタックスについて、図３０を参照して説明する。まず、Ｄａｔａ＿ＩＤは、前述したように、そのＤａｔａ＿ＩＤの次のビット列のデータエレメントがＨ−Ｐｈａｓｅであることを表す８ビットのデータであり、図２８で示した値”０２”である。Ｈ−Ｐｈａｓｅは、画像信号フレームにおいて、符号化される最初のサンプルを示す８ビットのデータである。
【０１２２】
図２７に戻って、次のＥｌｓｅ ｉｆ文は、ｕｓｅｒ＿ｄａｔａ（ｉ）関数のｉが２のとき、次に記述されているｗｈｉｌｅ構文を実行する。ｗｈｉｌｅ構文の内容は前述した場合と同様であるので、ここではその説明を省略する。
【０１２３】
ｗｈｉｌｅ構文が真のとき、次のｉｆ文において、ｎｅｘｔｂｉｔｓ（）関数は、Ｔｉｍｅ ｃｏｄｅ１を示すビット列を検出するか、または、Ｔｉｍｅ ｃｏｄｅ２を示すビット列を検出すると、そのビット列の次ビットからＴｉｍｅ＿ｃｏｄｅ（）関数で示されるＴｉｍｅ ｃｏｄｅのデータエレメントが記述されていることを知る。
【０１２４】
Ｔｉｍｅ ｃｏｄｅ１のＤａｔａ＿ＩＤは、図２８に示すように、”０３”を表すビット列であり、Ｔｉｍｅ ｃｏｄｅ１のデータは、画像の垂直ブランキング期間に挿入されたタイムコードを示す、ＶＩＴＣ（Ｖｅｒｔｉｃａｌ Ｉｎｔｅｒｖａｌ Ｔｉｍｅ Ｃｏｄｅ）である。Ｔｉｍｅ ｃｏｄｅ２のＤａｔａ＿ＩＤは、図２８に示すように、”０４”を表すビット列であり、Ｔｉｍｅ ｃｏｄｅ２のデータは、記録媒体のタイムコードトラックに記録されたタイムコードを示す、ＬＴＣ（Ｌｏｎｇｉｔｕｄｉｎａｌ Ｔｉｍｅ Ｃｏｄｅ）である。
【０１２５】
次に、Ｅｌｓｅ ｉｆ文において、ｎｅｘｔｂｉｔｓ（）関数は、Ｐｉｃｔｕｒｅ Ｏｒｄｅｒを示すビット列を検出すると、そのビット列の次ビットからＰｉｃｔｕｒｅ＿Ｏｒｄｅｒ（）関数で示されるＰｉｃｔｕｒｅ Ｏｒｄｅｒのデータエレメントが記述されていることを知る。ここで、Ｐｉｃｔｕｒｅ＿Ｏｒｄｅｒ（）関数のＤａｔａ＿ＩＤは、図２８に示すように、”０５”を表すビット列である。
【０１２６】
実際に、エンコーダでエレメンタリストリーム（ＥＳ）に挿入するＰｉｃｔｕｒｅ＿Ｏｒｄｅｒ（）関数のシンタックスを、図３１を参照して説明する。まず、Ｄａｔａ＿ＩＤは前述したように、そのＤａｔａ＿ＩＤ以降のデータがＰＯＩのデータであることを示す８ビットのデータであり、その値は”０５”である。ＤＴＳ＿ｐｒｅｓｅｎｃｅは、符号化順序ＤＴＳ＿ｃｏｕｎｔｅｒの有無を表す１ビットのデータである。例えば、ＢピクチャのようにＤＴＳ＿ｃｏｕｎｔｅｒ＝ＰＴＳ＿ｃｏｕｎｔｅｒとなる場合、表示順序ＰＴＳ＿ｃｏｕｎｔｅｒのみが存在し、ＤＴＳ＿ｐｒｅｓｅｎｃｅのビットは”０”となる。逆に、ＰピクチャおよびＩピクチャの場合、符号化順序ＤＴＳ＿ｃｏｕｎｔｅｒと表示順序ＰＴＳ＿ｃｏｕｎｔｅｒは同一ではないので、表示順序ＰＴＳ＿ｃｏｕｎｔｅｒと符号化順序ＤＴＳ＿ｃｏｕｎｔｅｒの双方が存在し、ＤＴＳ＿ｐｒｅｓｅｎｃｅのビットは１となる。
【０１２７】
ＰＴＳ＿ｃｏｕｎｔｅｒは、エンコーダに符号化フレーム中の１フィールドが入力されるごとにカウントアップを行う、表示順序を表す７ビットのデータである。この７ビットのデータは、０から１２７までの値をとるモジュロである。ｉｆ文以降は、ＤＴＳ＿ｐｒｅｓｅｎｃｅのビットが１のとき、すなわち、ＰピクチャおよびＩピクチャのとき、ＤＴＳ＿ｃｏｕｎｔｅｒのカウントアップが実行される。
【０１２８】
Ｍａｒｋｅｒ＿ｂｉｔｓは、ｕｓｅｒ ｄａｔａの記述されたビット列が、偶然に前述したスタートコードと一致し、画像破錠を引き起こす可能正が高い、スタートコードエミュレーションを防止するために、１６ビットごとに挿入されるビットである。
【０１２９】
ＤＴＳ＿ｃｏｕｎｔｅｒは、エンコーダで、１フィールド分の符号化画像データが符号化されるごとにカウントアップを行う、符号化順序を表す７ビットのデータである。この７ビットのデータは、０から１２７までの値をとるモジュロである。
【０１３０】
前述したように、表示順序ＰＴＳ＿ｃｏｕｎｔｅｒは、フィールド単位で付番されるために、例えば、符号化画像データを２４Ｈｚから３０Ｈｚのフレームレートに変換して符号化する場合、３−２プルダウン処理を行った後に、付番する必要がある。
【０１３１】
図２７に戻って、その次に記述されているｗｈｉｌｅ構文も、内容は前述した場合と同様であるので、ここではその説明を省略する。ｗｈｉｌｅ構文が真のとき、次のｉｆ文において、ｎｅｘｔｂｉｔｓ（）関数は、Ａｎｃｉｌｌａｒｙ ｄａｔａを示すビット列を検出すると、そのビット列の次ビットからＡｎｃｉｌｌａｒｙ＿ｄａｔａ（）関数で示されるＡｎｃｉｌｌａｒｙ ｄａｔａのデータエレメントが記述されていることを知る。Ａｎｃｉｌｌａｒｙ＿ｄａｔａ（）関数のＤａｔａ＿ＩＤは、図２８に示すように、”０７”を表すビット列である。
【０１３２】
この補助データに識別子を付加するａｎｃｉｌｌａｒｙ ｄａｔａのシンタックスを図３２を参照して説明する。Ａｎｃｉｌｌａｒｙ＿ｄａｔａ（）関数はピクチャ層のｕｓｅｒ ｄａｔａとして伝送され、データとしてはＦｉｅｌｄ識別子（Ｆｉｅｌｄ＿ＩＤ）、ラインの番号（Ｌｉｎｅ＿ｎｕｍｂｅｒ）および補如データ（ａｎｃｉｌｌａｒｙ ｄａｔａ）が挿入される。
【０１３３】
Ｄａｔａ＿ＩＤは、ｕｓｅｒ ｄａｔａ領域において、ａｎｃｉｌｌａｒｙ ｄａｔａであることを示す８ビットのデータであり、その値は図２８に示したように”０７”である。
【０１３４】
Ｆｉｅｌｄ＿ＩＤは２ビットのデータであり、ｐｒｏｇｒｅｓｓｉｖｅ＿ｓｅｑｕｅｎｃｅ ｆｌａｇ（図２５）の値が”０”のとき、符号化フレーム内のフィールドごとにＦｉｅｌｄ＿ＩＤが付加される。ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄに”０”が設定されているとき、この符号化フレームにはフィールドが２枚存在し、Ｆｉｅｌｄ＿ＩＤは、図１９に示したように、最初のフィールドに”０”、およびその次のフィールドに”１”が設定され、ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄに”１”が設定されているとき、この符号化フレームにはフィールドが３枚存在し、Ｆｉｅｌｄ＿ＩＤとしては、最初のフィールドに”０”が設定され、それ以降のフィールドに”１”，”２”が設定される。
【０１３５】
Ｆｉｅｌｄ＿ＩＤは、ｐｒｏｇｒｅｓｓｉｖｅ＿ｓｅｑｕｅｎｃｅ ｆｌａｇの値が”１”のとき、符号化フレームごとに付加される。Ｆｉｅｌｄ＿ＩＤには、ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄとＴｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔにともに”０”が設定されているとき、その符号化フレームは１枚のｐｒｏｇｒｅｓｓｉｖｅ ｆｒａｍｅが存在するので、値”０”が設定され、ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄに値”１”およびＴｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔに値”０”が設定されているとき、その符号化フレームは２枚のｐｒｏｇｒｅｓｓｉｖｅ ｆｒａｍｅが存在するので、値”０”，”１”が設定され、ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄとＴｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔにともに”１”が設定されているとき、その符号化フレームは３枚のｐｒｏｇｒｅｓｓｉｖｅ ｆｒａｍｅが存在するので、値”０”乃至”２”が設定される。
【０１３６】
Ｌｉｎｅ＿ｎｕｍｂｅｒは、１４ビットのデータであり、各フレームにおける補助データが記述されている、ＩＴＵ−Ｒ ＢＴ．６５６−３，ＳＭＰＴＥ２７４Ｍ，ＳＭＰＴＥ２９３Ｍ，ＳＭＰＴＥ２９６Ｍで規定されたライン番号を示す。
【０１３７】
Ａｎｃｉｌｌａｒｙ＿ｄａｔａ＿ｌｅｎｇｔｈは、１６ビットのデータであり、ａｎｃｉｌｌａｒｙ＿ｄａｔａ＿ｐａｙｌｏａｄのデータ長を示す。Ａｎｃｉｌｌａｒｙ＿ｄａｔａ＿ｐａｙｌｏａｄは、２２ビットのデータからなる補助データの内容を表しており、Ａｎｃｉｌｌａｒｙ＿ｄａｔａ＿ｐａｙｌｏａｄのＡｎｃｉｌｌａｒｙ＿ｄａｔａ＿ｌｅｎｇｔｈの値がｊの値（初期値０）より大きいとき、値ｊ（Ａｎｃｉｌｌａｒｙ＿ｄａｔａ＿ｌｅｎｇｔｈのデータ長）を１だけインクリメントして、そのｊの値のビット列目から記述される。
【０１３８】
次のＷｈｉｌｅ構文は、ｂｙｔｅａｌｉｇｎｅｄ（）関数のためのシンタックスを表しており、次のデータがｂｙｔｅａｌｉｇｎｅｄ（）関数でないとき（Ｗｈｉｌｅ構文が真のとき）、Ｚｅｒｏ＿ｂｉｔ（１ビットのデータ”０”）を記述する。
【０１３９】
図２７に戻って、次のＥｌｓｅ ｉｆ文において、ｎｅｘｔｂｉｔｓ（）関数は、Ｈｉｓｔｏｒｙ ｄａｔａを示すビット列を検出すると、そのビット列の次ビットからＨｉｓｔｏｒｙ＿ｄａｔａ（）関数で示されるＨｉｓｔｏｒｙ ｄａｔａのデータエレメントが記述されていることを知る。Ｈｉｓｔｏｒｙ＿ｄａｔａ（）関数のＤａｔａ＿ＩＤは、図２８に示すように、”０８”を表すビット列であり、Ｄａｔａ＿ＩＤが”０８”で示されるデータは、符号化パラメータの履歴情報を含むＨｉｓｔｏｒｙ ｄａｔａを表している。
【０１４０】
最後のｉｆ文において、ｎｅｘｔｂｉｔｓ（）関数は、ｕｓｅｒ ｄａｔａを示すビット列を検出すると、そのビット列の次ビットからｕｓｅｒ＿ｄａｔａ（）関数で示されるｕｓｅｒ＿ｄａｔａのデータエレメントが記述されていることを知る。
【０１４１】
図２７のｎｅｘｔｂｉｔｓ（）関数が、それぞれのデータエレメントが記述されていることを知るビット列は、図２８に示すＤａｔａ＿ＩＤとして記述されている。ただし、Ｄａｔａ＿ＩＤとして”００”を使用することは禁止されている。Ｄａｔａ＿ＩＤが”８０”で示されるデータは、制御フラグを表しており、Ｄａｔａ＿ＩＤが”ＦＦ”で示されるデータは、ｕｓｅｒ ｄａｔａを表している。
【０１４２】
図３３は、ｇｒｏｕｐ＿ｏｆ＿ｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）関数のシンタックスを説明するための図である。このｇｒｏｕｐ＿ｏｆ＿ｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）関数によって定義されたデータエレメントは、ｇｒｏｕｐ＿ｓｔａｒｔ＿ｃｏｄｅ、ｔｉｍｅ＿ｃｏｄｅ、ｃｌｏｓｅｄ＿ｇｏｐ、およびｂｒｏｋｅｎ＿ｌｉｎｋから構成される。
【０１４３】
ｇｒｏｕｐ＿ｓｔａｒｔ＿ｃｏｄｅは、ＧＯＰレイヤの開始同期コードを示すデータである。ｔｉｍｅ＿ｃｏｄｅは、ＧＯＰの先頭ピクチャのシーケンスの先頭からの時間を示すタイムコードである。ｃｌｏｓｅｄ＿ｇｏｐは、ＧＯＰ内の画像が他のＧＯＰから独立再生可能なことを示すフラグデータである。ｂｒｏｋｅｎ＿ｌｉｎｋは、編集などのためにＧＯＰ内の先頭のＢピクチャが正確に再生できないことを示すフラグデータである。
【０１４４】
ｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（１）関数は、 ｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（０）関数と同じように、ｕｓｅｒ＿ｄａｔａ（）関数によって定義されるデータエレメントのみを記述するための関数である。
【０１４５】
次に、図３４乃至図３６を参照して、符号化ストリームのピクチャレイヤに関するデータエレメントを記述するためのｐｉｃｔｕｒｅ＿ｈｅａｄｒ（）関数、ｐｉｃｔｕｒｅ＿ｃｏｄｉｎｇ＿ｅｘｔｅｎｓｉｏｎ（）関数、およびｐｉｃｔｕｒｅ＿ｄａｔａ（）について説明する。
【０１４６】
図３４はｐｉｃｔｕｒｅ＿ｈｅａｄｒ（）関数のシンタックスを説明するための図である。このｐｉｃｔｕｒｅ＿ｈｅａｄｒ（）関数によって定義されたデータエレメントは、ｐｉｃｔｕｒｅ＿ｓｔａｒｔ＿ｃｏｄｅ、ｔｅｍｐｏｒａｌ＿ｒｅｆｅｒｅｎｃｅ、ｐｉｃｔｕｒｅ＿ｃｏｄｉｎｇ＿ｔｙｐｅ、ｖｂｖ＿ｄｅｌａｙ、ｆｕｌｌ＿ｐｅｌ＿ｆｏｒｗａｒｄ＿ｖｅｃｔｏｒ、ｆｏｒｗａｒｄ＿ｆ＿ｃｏｄｅ、ｆｕｌｌ＿ｐｅｌ＿ｂａｃｋｗａｒｄ＿ｖｅｃｔｏｒ、ｂａｃｋｗａｒｄ＿ｆ＿ｃｏｄｅ、ｅｘｔｒａ＿ｂｉｔ＿ｐｉｃｔｕｒｅ、およびｅｘｔｒａ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｐｉｃｔｕｒｅである。
【０１４７】
具体的には、ｐｉｃｔｕｒｅ＿ｓｔａｒｔ＿ｃｏｄｅは、ピクチャレイヤの開始同期コードを表すデータである。ｔｅｍｐｏｒａｌ＿ｒｅｆｅｒｅｎｃｅは、ピクチャの表示順を示す番号で、ＧＯＰの先頭でリセットされるデータである。ｐｉｃｔｕｒｅ＿ｃｏｄｉｎｇ＿ｔｙｐｅは、ピクチャタイプを示すデータである。
【０１４８】
ｖｂｖ＿ｄｅｌａｙは、ＶＢＶバッファの初期状態を示すデータであって、各ピクチャ毎に設定されている。送信側システムから受信側システムに伝送された符号化エレメンタリストリームのピクチャは、受信側システムに設けられたＶＢＶバッファにバッファリングされ、ＤＴＳ（Ｄｅｃｏｄｉｎｇ Ｔｉｍｅ Ｓｔａｍｐ）によって指定された時刻に、このＶＢＶバッファから引き出され（読み出され）、デコーダに供給される。ｖｂｖ＿ｄｅｌａｙによって定義される時間は、復号化対象のピクチャがＶＢＶバッファにバッファリングされ始めてから、符号化対象のピクチャがＶＢＶバッファから引き出されるまでの時間、つまりＤＴＳによって指定された時刻までの時間を意味する。このピクチャヘッダに格納されたｖｂｖ＿ｄｅｌａｙを使用することによって、ＶＢＶバッファのデータ占有量が不連続にならないシームレスなスプライシングが実現できる。
【０１４９】
ｆｕｌｌ＿ｐｅｌ＿ｆｏｒｗａｒｄ＿ｖｅｃｔｏｒは、順方向動きベクトルの精度が整数単位か半画素単位かを示すデータである。ｆｏｒｗａｒｄ＿ｆ＿ｃｏｄｅは、順方向動きベクトル探索範囲を表すデータである。ｆｕｌｌ＿ｐｅｌ＿ｂａｃｋｗａｒｄ＿ｖｅｃｔｏｒは、逆方向動きベクトルの精度が整数単位か半画素単位かを示すデータである。ｂａｃｋｗａｒｄ＿ｆ＿ｃｏｄｅは、逆方向動きベクトル探索範囲を表すデータである。ｅｘｔｒａ＿ｂｉｔ＿ｐｉｃｔｕｒｅは、後続する追加情報の存在を示すフラグである。このｅｘｔｒａ＿ｂｉｔ＿ｐｉｃｔｕｒｅが「１」の場合には、次にｅｘｔｒａ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｐｉｃｔｕｒｅが存在し、ｅｘｔｒａ＿ｂｉｔ＿ｐｉｃｔｕｒｅが「０」の場合には、これに続くデータが無いことを示している。ｅｘｔｒａ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｐｉｃｔｕｒｅは、規格において予約された情報である。
【０１５０】
図３５は、ｐｉｃｔｕｒｅ＿ｃｏｄｉｎｇ＿ｅｘｔｅｎｓｉｏｎ（）関数のシンタックスを説明するための図である。このｐｉｃｔｕｒｅ＿ｃｏｄｉｎｇ＿ｅｘｔｅｎｓｉｏｎ（）関数によって定義されたデータエレメントは、ｅｘｔｅｎｓｉｏｎ＿ｓｔａｒｔ＿ｃｏｄｅ、ｅｘｔｅｎｓｉｏｎ＿ｓｔａｒｔ＿ｃｏｄｅ＿ｉｄｅｎｔｉｆｉｅｒ、ｆ＿ｃｏｄｅ［０］［０］、ｆ＿ｃｏｄｅ［０］［１］、ｆ＿ｃｏｄｅ［１］［０］、ｆ＿ｃｏｄｅ［１］［１］、ｉｎｔｒａ＿ｄｃ＿ｐｒｅｃｉｓｉｏｎ、ｐｉｃｔｕｒｅ＿ｓｔｒｕｃｔｕｒｅ、ｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔ、ｆｒａｍｅ＿ｐｒｅｄｉｃｔｉｖｅ＿ｆｒａｍｅ＿ｄｃｔ、ｃｏｎｃｅａｌｍｅｎｔ＿ｍｏｔｉｏｎ＿ｖｅｃｔｏｒｓ、ｑ＿ｓｃａｌｅ＿ｔｙｐｅ、ｉｎｔｒａ＿ｖｌｃ＿ｆｏｒｍａｔ、ａｌｔｅｒｎａｔｅ＿ｓｃａｎ、ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄ、ｃｈｒｏｍａ＿４２０＿ｔｙｐｅ、ｐｒｏｇｒｅｓｓｉｖｅ＿ｆｒａｍｅ、ｃｏｍｐｏｓｉｔｅ＿ｄｉｓｐｌａｙ＿ｆｌａｇ、ｖ＿ａｘｉｓ、ｆｉｅｌｄ＿ｓｅｑｕｅｎｃｅ、ｓｕｂ＿ｃａｒｒｉｅｒ、ｂｕｒｓｔ＿ａｍｐｌｉｔｕｄｅ、およびｓｕｂ＿ｃａｒｒｉｅｒ＿ｐｈａｓｅから構成される。
【０１５１】
ｅｘｔｅｎｓｉｏｎ＿ｓｔａｒｔ＿ｃｏｄｅは、ピクチャレイヤのエクステンションデータのスタートを示す開始コードである。ｅｘｔｅｎｓｉｏｎ＿ｓｔａｒｔ＿ｃｏｄｅ＿ｉｄｅｎｔｉｆｉｅｒは、どの拡張データが送られるかを示すコードである。ｆ＿ｃｏｄｅ［０］［０］は、フォアード方向の水平動きベクトル探索範囲を表すデータである。ｆ＿ｃｏｄｅ［０］［１］は、フォアード方向の垂直動きベクトル探索範囲を表すデータである。ｆ＿ｃｏｄｅ［１］［０］は、バックワード方向の水平動きベクトル探索範囲を表すデータである。ｆ＿ｃｏｄｅ［１］［１］は、バックワード方向の垂直動きベクトル探索範囲を表すデータである。ｉｎｔｒａ＿ｄｃ＿ｐｒｅｃｉｓｉｏｎは、ＤＣ係数の精度を表すデータである。ｐｉｃｔｕｒｅ＿ｓｔｒｕｃｔｕｒｅは、フレームストラクチャかフィールドストラクチャかを示すデータである。これは、フィールドストラクチャの場合は、上位フィールドか下位フィールドかもあわせて示す。
【０１５２】
ｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔは、フレームストラクチャの場合、最初のフィールドがトップフィールドであるのか、ボトムフィールドであるのかを示すフラグである。ｆｒａｍｅ＿ｐｒｅｄｉｃｔｉｖｅ＿ｆｒａｍｅ＿ｄｃｔは、フレーム・ストラクチャの場合、フレーム・モードＤＣＴの予測がフレーム・モードだけであることを示すデータである。ｃｏｎｃｅａｌｍｅｎｔ＿ｍｏｔｉｏｎ＿ｖｅｃｔｏｒｓは、イントラマクロブロックに伝送エラーを隠蔽するための動きベクトルがついていることを示すデータである。ｑ＿ｓｃａｌｅ＿ｔｙｐｅは、線形量子化スケールを利用するか、非線形量子化スケールを利用するかを示すデータである。ｉｎｔｒａ＿ｖｌｃ＿ｆｏｒｍａｔは、イントラマクロブロックに、別の２次元ＶＬＣ（可変長符号）を使うかどうかを示すデータである。ａｌｔｅｒｎａｔｅ＿ｓｃａｎは、ジグザグスキャンを使うか、オルタネート・スキャンを使うかの選択を表すデータである。
【０１５３】
ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄは、復号化時にリピートフィールドを生成するか否かを示すフラグであって、復号化時の処理において、ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄ が「１」の場合にはリピートフィールドを生成し、ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄが「０」の場合にはリピートフィールドを生成しないという処理が行われる。
【０１５４】
ｃｈｒｏｍａ＿４２０＿ｔｙｐｅは、信号フォーマットが４：２：０の場合、次のｐｒｏｇｒｅｓｓｉｖｅ＿ｆｒａｍｅ と同じ値、そうでない場合は０を表すデータである。ｐｒｏｇｒｅｓｓｉｖｅ＿ｆｒａｍｅは、そのピクチャが、順次走査できているかどうかを示すデータである。ｃｏｍｐｏｓｉｔｅ＿ｄｉｓｐｌａｙ＿ｆｌａｇは、ソース信号がコンポジット信号であったかどうかを示すデータである。ｖ＿ａｘｉｓは、ソース信号が、ＰＡＬの場合に使われるデータである。ｆｉｅｌｄ＿ｓｅｑｕｅｎｃｅは、ソース信号が、ＰＡＬの場合に使われるデータである。ｓｕｂ＿ｃａｒｒｉｅｒは、ソース信号が、ＰＡＬの場合に使われるデータである。ｂｕｒｓｔ＿ａｍｐｌｉｔｕｄｅは、ソース信号が、ＰＡＬの場合に使われるデータである。ｓｕｂ＿ｃａｒｒｉｅｒ＿ｐｈａｓｅは、ソース信号が、ＰＡＬの場合に使われるデータである。
【０１５５】
図３６は、ｐｉｃｔｕｒｅ＿ｄａｔａ（）関数のシンタックスを説明するための図である。このｐｉｃｔｕｒｅ＿ｄａｔａ（）関数によって定義されるデータエレメントは、ｓｌｉｃｅ（）関数によって定義されるデータエレメントである。但し、ビットストリーム中に、ｓｌｉｃｅ（）関数のスタートコードを示すｓｌｉｃｅ＿ｓｔａｒｔ＿ｃｏｄｅが存在しない場合には、このｓｌｉｃｅ（）関数によって定義されるデータエレメントはビットストリーム中に記述されていない。
【０１５６】
ｓｌｉｃｅ（）関数は、スライスレイヤに関するデータエレメントを記述するための関数であって、具体的には、ｓｌｉｃｅ＿ｓｔａｒｔ＿ｃｏｄｅ、ｓｌｉｃｅ＿ｑｕａｎｔｉｓｅｒ＿ｓｃａｌｅ＿ｃｏｄｅ、ｉｎｔｒａ＿ｓｌｉｃｅ＿ｆｌａｇ、ｉｎｔｒａ＿ｓｌｉｃｅ、ｒｅｓｅｒｖｅｄ＿ｂｉｔｓ、ｅｘｔｒａ＿ｂｉｔ＿ｓｌｉｃｅ、ｅｘｔｒａ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｓｌｉｃｅ、およびｅｘｔｒａ＿ｂｉｔ＿ｓｌｉｃｅ 等のデータエレメントと、ｍａｃｒｏｂｌｏｃｋ（）関数によって定義されるデータエレメントを記述するための関数である。
【０１５７】
ｓｌｉｃｅ＿ｓｔａｒｔ＿ｃｏｄｅは、ｓｌｉｃｅ（）関数によって定義されるデータエレメントのスタートを示すスタートコードである。ｓｌｉｃｅ＿ｑｕａｎｔｉｓｅｒ＿ｓｃａｌｅ＿ｃｏｄｅは、このスライスレイヤに存在するマクロブロックに対して設定された量子化ステップサイズを示すデータである。しかし、各マクロブロック毎に、ｑｕａｎｔｉｓｅｒ＿ｓｃａｌｅ＿ｃｏｄｅが設定されている場合には、各マクロブロックに対して設定されたｍａｃｒｏｂｌｏｃｋ＿ｑｕａｎｔｉｓｅｒ＿ｓｃａｌｅ＿ｃｏｄｅのデータが優先して使用される。ｉｎｔｒａ＿ｓｌｉｃｅ＿ｆｌａｇは、ビットストリーム中にｉｎｔｒａ＿ｓｌｉｃｅおよびｒｅｓｅｒｖｅｄ＿ｂｉｔｓが存在するか否かを示すフラグである。ｉｎｔｒａ＿ｓｌｉｃｅは、スライスレイヤ中にノンイントラマクロブロックが存在するか否かを示すデータである。スライスレイヤにおけるマクロブロックのいずれかがノンイントラマクロブロックである場合には、ｉｎｔｒａ＿ｓｌｉｃｅは「０」となり、スライスレイヤにおけるマクロブロックの全てがノンイントラマクロブロックである場合には、ｉｎｔｒａ＿ｓｌｉｃｅは「１」となる。ｒｅｓｅｒｖｅｄ＿ｂｉｔｓは、７ビットのデータであって「０」の値を取る。ｅｘｔｒａ＿ｂｉｔ＿ｓｌｉｃｅは、符号化ストリームとして追加の情報が存在することを示すフラグであって、次にｅｘｔｒａ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｓｌｉｃｅが存在する場合には「１」に設定される。追加の情報が存在しない場合には「０」に設定される。
【０１５８】
ｍａｃｒｏｂｌｏｃｋ（）関数は、マクロブロックレイヤに関するデータエレメントを記述するための関数であって、具体的には、ｍａｃｒｏｂｌｏｃｋ＿ｅｓｃａｐｅ、ｍａｃｒｏｂｌｏｃｋ＿ａｄｄｒｅｓｓ＿ｉｎｃｒｅｍｅｎｔ、およびｍａｃｒｏｂｌｏｃｋ＿ｑｕａｎｔｉｓｅｒ＿ｓｃａｌｅ＿ｃｏｄｅ等のデータエレメントと、ｍａｃｒｏｂｌｏｃｋ＿ｍｏｄｅｓ（）関数、および ｍａｃｒｏｂｌｏｃｋ＿ｖｅｃｔｅｒｓ（ｓ）関数によって定義されたデータエレメントを記述するための関数である。
【０１５９】
ｍａｃｒｏｂｌｏｃｋ＿ｅｓｃａｐｅは、参照マクロブロックと前のマクロブロックとの水平方向の差が３４以上であるか否かを示す固定ビット列である。参照マクロブロックと前のマクロブロックとの水平方向の差が３４以上の場合には、ｍａｃｒｏｂｌｏｃｋ＿ａｄｄｒｅｓｓ＿ｉｎｃｒｅｍｅｎｔの値に３３をプラスする。ｍａｃｒｏｂｌｏｃｋ＿ａｄｄｒｅｓｓ＿ｉｎｃｒｅｍｅｎｔは、参照マクロブロックと前のマクロブロックとの水平方向の差を示すデータである。もし、このｍａｃｒｏｂｌｏｃｋ＿ａｄｄｒｅｓｓ＿ｉｎｃｒｅｍｅｎｔの前にｍａｃｒｏｂｌｏｃｋ＿ｅｓｃａｐｅが１つ存在するのであれば、このｍａｃｒｏｂｌｏｃｋ＿ａｄｄｒｅｓｓ＿ｉｎｃｒｅｍｅｎｔの値に３３をプラスした値が、実際の参照マクロブロックと前のマクロブロックとの水平方向の差分を示すデータとなる。ｍａｃｒｏｂｌｏｃｋ＿ｑｕａｎｔｉｓｅｒ＿ｓｃａｌｅ＿ｃｏｄｅは、各マクロブロック毎に設定された量子化ステップサイズである。各スライスレイヤには、スライスレイヤの量子化ステップサイズを示すｓｌｉｃｅ＿ｑｕａｎｔｉｓｅｒ＿ｓｃａｌｅ＿ｃｏｄｅが設定されているが、参照マクロブロックに対してｍａｃｒｏｂｌｏｃｋ＿ｑｕａｎｔｉｓｅｒ＿ｓｃａｌｅ＿ｃｏｄｅが設定されている場合には、この量子化ステップサイズを選択する。
【０１６０】
図３７は、ＭＰＥＧ符号化ストリームのデータ構造を示す説明図である。この図に示したように、ビデオエレメンタリストリームのデータ構造は、少なくともシーケンスレイヤ、ＧＯＰレイヤ、およびピクチャレイヤを含んでいる。
【０１６１】
シーケンスレイヤは、ｎｅｘｔ＿ｓｔａｒｔ＿ｃｏｄｅ（）関数２０１、ｓｅｑｕｅｎｃｅ＿ｈｅａｄｅｒ（）関数２０２、ｅｘｔｅｎｓｉｏｎ＿ｓｔａｒｔ＿ｃｏｄｅ（）２０３、ｓｅｑｕｅｎｃｅ＿ｅｘｔｅｎｓｉｏｎ（）関数２０４、ｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（０）関数２０５によって定義されるデータエレメントから構成されている。ＧＯＰレイヤは、ｇｒｏｕｐ＿ｓｔａｒｔ＿ｃｏｄｅ２０６、ｇｒｏｕｐ＿ｏｆ＿ｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）関数２０７、ｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（１）関数２０８によって定義されるデータエレメントから構成されている。ピクチャレイヤは、ｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）関数２０９、ｐｉｃｔｕｒｅ＿ｃｏｄｉｎｇ＿ｅｘｔｅｎｓｉｏｎ（）関数２１０、ｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（２）関数２１１、ｐｉｃｔｕｒｅ＿ｄａｔａ（）関数２１２によって定義されるデータエレメントを含んでいる。ビデオシーケンスの最後には、ｓｅｑｕｅｎｃｅ＿ｅｎｄ＿ｃｏｄｅ２１３が記述されている。
【０１６２】
ｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（２）関数２１１は、既に図２６において説明したシンタックスからも理解できるように、ｕｓｅｒ＿ｄａｔａ＿ｓｔａｒｔ＿ｃｏｄｅ２１４、ｕｓｅｒ＿ｄａｔａ（）関数２１５、ｎｅｘｔ＿ｓｔａｒｔ＿ｃｏｄｅ２１６によって定義されるデータエレメントを含んでいる。
【０１６３】
ｕｓｅｒ＿ｄａｔａ（）関数２１５は、既に図２７において説明したシンタックスからも理解できるように、ｔｉｍｅ＿ｃｏｄｅ（）関数２１７とｕｓｅｒ＿ｄａｔａ２１８によって定義されるデータエレメントを含んでいる。
【０１６４】
なお、本明細書において、システムとは、複数の装置により構成される装置全体を表すものとする。
【０１６５】
また、本明細書中において、上記処理を実行するコンピュータプログラムをユーザに提供する提供媒体には、磁気ディスク、ＣＤ−ＲＯＭなどの情報記録媒体の他、インターネット、デジタル衛星などのネットワークによる伝送媒体も含まれる。
【０１６６】
【発明の効果】
以上の如く、請求項１および請求項２に記載のビットストリーム変換装置、請求項６および請求項７に記載のビットストリーム変換方法、請求項８および請求項９に記載の提供媒体によれば、放送局内においては、エレメンタリストリームのデータを送受信し、放送局間では、トランスポートストリームのデータを送受信するようにしたので、システム全体として、低コストで効率的にデータを送受信し、処理することが可能となる。
【図面の簡単な説明】
【図１】Ｃｏｄｉｎｇ Ｐｈａｓｅを説明する図である。
【図２】補助データを説明する図である。
【図３】エレメンタリストリームを伝送するシステムの構成を示す図である。
【図４】補助データを伝送するシステムの構成を示す図である。
【図５】ＭＰＥＧ方式における予測構造と符号化構造を説明する図である。
【図６】ＭＰＥＧエンコーダで発生する遅延について説明する図である。
【図７】スタジオの内部の構成を示すブロック図である。
【図８】図７のスタジオの内部で伝送されるデータを説明する図である。
【図９】図７のシステムにおいてデータを伝送するシステムの構成を示す図である。
【図１０】３−２プルダウン処理された画像の補助データを説明する図である。
【図１１】２つのスタジオの間でビットストリームを伝送するときのシステム構成を表すブロック図である。
【図１２】図１１のシステムで伝送されるストリームの構成を表す図である。
【図１３】図１１のシステムにおいて、トランスポートストリームを伝送する構成を表すブロック図である。
【図１４】符号化処理の遅延を説明する図である。
【図１５】本発明を適用したＭＰＥＧエンコーダの構成を表すブロック図である。
【図１６】本発明を適用したＭＰＥＧデコーダの構成を表すブロック図である。
【図１７】ＣＰＩを伝送する場合のシステムの構成を表す図である。
【図１８】図１１のＳＤＴＩ−ＣＰインタフェース４６の構成を表すブロック図である。
【図１９】補助データの伝送を説明する図である。
【図２０】３−２プルダウン処理におけるＰＴＳ＿ｃｏｕｎｔｅｒとＤＴＳ＿ｃｏｕｎｔｅｒを説明する図である。
【図２１】ＰＯＩを伝送する場合のシステムの構成を表す図である。
【図２２】ＰＯＩを伝送する場合の他のシステムの構成を表す図である。
【図２３】ｖｉｄｅｏ＿ｓｅｑｕｅｎｃｅ関数のシンタックスを説明する図である。
【図２４】ｓｅｑｕｅｎｃｅ＿ｈｅａｄｅｒ（）関数のシンタックスを説明する図である。
【図２５】ｓｅｑｕｅｎｃｅ＿ｅｘｔｅｎｓｉｏｎ（）関数のシンタックスを説明する図である。
【図２６】ｅｘｔｅｎｓｉｏｎ＿ａｎｄ＿ｕｓｅｒ＿ｄａｔａ（ｉ）関数のシンタックスを説明する図である。
【図２７】ｕｓｅｒ ｄａｔａ（）関数のシンタックスを表す図である。
【図２８】ｕｓｅｒ ｄａｔａに記述される関数のＤａｔａ＿ＩＤを説明する図である。
【図２９】Ｖ−Ｐｈａｓｅ（）関数のシンタックスを説明する図である。
【図３０】Ｈ−Ｐｈａｓｅ（）関数のシンタックスを説明する図である。
【図３１】Ｐｉｃｔｕｒｅ＿Ｏｒｄｅｒ（）関数のシンタックスを説明する図である。
【図３２】Ａｎｃｉｌｌａｒｙ＿ｄａｔａ（）関数のシンタックスを説明する図である。
【図３３】ｇｒｏｕｐ＿ｏｆ＿ｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）関数のシンタックスを説明する図である。
【図３４】ｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）関数のシンタックスを説明する図である。
【図３５】ｐｉｃｔｕｒｅ＿ｃｏｄｉｎｇ＿ｅｘｔｅｎｓｉｏｎ（）関数のシンタックスを説明する図である。
【図３６】ｐｉｃｔｕｒｅ＿ｄａｔａ（）関数のシンタックスを説明する図である。
【図３７】ＭＰＥＧ方式のレイヤを説明する図である。
【符号の説明】
４２，４３ ＭＰＥＧエンコーダ， ４４，４５ ＭＰＥＧデコーダ， ４６乃至４９ ＳＤＴＩ−ＣＰインタフェース， ５０ ＳＤＴＩ−ＣＰネットワーク， ５１ ＳＤＴＩ−ＣＰインタフェース， ６１，６２ ＴＳ ＭＵＸ／ＤＥＭＵＸ， ７２，７３ ＭＰＥＧエンコーダ，７４，７５ ＭＰＥＧデコーダ， ７６乃至８１ ＳＤＴＩ−ＣＰインタフェース， ８０ ＳＤＴＩ−ＣＰネットワーク
Claims (9)
- 画像信号の符号化順序と表示順序を含む順序情報が重畳されたエレメンタリストリームを入力するエレメンタリストリーム入力手段と、
前記エレメンタリストリーム入力手段により入力されたエレメンタリストリームを、前記順序情報を参照して多重化し、トランスポートストリームを生成するトランスポートストリーム生成手段と、
前記トランスポートストリーム生成手段により生成されたトランスポートストリームを出力するトランスポートストリーム出力手段と
を備えることを特徴とするビットストリーム変換装置。 - エレメンタリストリームに重畳された順序情報に含まれる符号化情報と順序情報を換算することにより前記エレメンタリストリームを多重化して生成したトランスポートストリームを入力するトランスポートストリーム入力手段と、
前記トランスポートストリーム入力手段により入力されたトランスポートストリームを、前記符号化情報及び前記表示情報に換算してエレメンタリストリームを生成するエレメンタリストリーム生成手段と、
前記エレメンタリストリーム生成手段により生成されたエレメンタリストリームを出力するエレメンタリストリーム出力手段と
を備えることを特徴とするビットストリーム変換装置。 - 前記エレメンタリストリームは、 MPEG （ Moving Picture Expert Group ）方式でエンコードされたデータである
ことを特徴とする請求項１または請求項２いずれかに記載のビットストリーム変換装置。 - 前記エレメンタリストリームのフォーマットを変換するエレメンタリストリーム変換手段を更に備える
ことを特徴とする請求項１または請求項２いずれかに記載のビットストリーム変換装置。 - 前記エレメンタリストリーム変換手段は、 SDTI-CP （ Serial Data Transfer Interface-Content Package ）ネットワークを介して伝送されてきた前記エレメンタリストリームが入力される場合は MPEG （ Moving Picture Expert Group ）方式で符号化されたエレメンタリストリームを出力し、
MPEG 方式で符号化されたエレメンタリストリームが入力される場合は SDTI-CP ネットワークを介して伝送される前記エレメンタリストリームを出力する
ことを特徴とする請求項４に記載のビットストリーム変換装置。 - 画像信号の符号化順序と表示順序を含む順序情報が重畳されたエレメンタリストリームを入力するエレメンタリストリーム入力ステップと、
前記エレメンタリストリーム入力ステップの処理において入力されたエレメンタリストリームを、前記順序情報を参照して多重化し、トランスポートストリームを生成するトランスポートストリーム生成ステップと、
前記トランスポートストリーム生成ステップの処理において生成されたトランスポートストリームを出力するトランスポートストリーム出力ステップと
を含むことを特徴とするビットストリーム変換方法。 - エレメンタリストリームに重畳された順序情報に含まれる符号化情報と順序情報を換算することにより前記エレメンタリストリームを多重化して生成したトランスポートストリームを入力するトランスポートストリーム入力ステップと、
前記トランスポートストリーム入力ステップの処理において入力されたトランスポートストリームを前記符号化情報及び前記表示情報に換算してエレメンタリストリームを生成するエレメンタリストリーム生成ステップと、
前記エレメンタリストリーム生成ステップの処理において生成されたエレメンタリストリームを出力するエレメンタリストリーム出力ステップと
を含むことを特徴とするビットストリーム変換方法。 - 画像信号の符号化順序と表示順序を含む順序情報が重畳されたエレメンタリストリームを入力するエレメンタリストリーム入力ステップと、
前記エレメンタリストリーム入力ステップの処理において入力されたエレメンタリストリームを、前記順序情報を参照して多重化し、トランスポートストリームを生成するトランスポートストリーム生成ステップと、
前記トランスポートストリーム生成ステップの処理において生成されたトランスポートストリームを出力するトランスポートストリーム出力ステップと
を含む処理を実行させるコンピュータが読み取り可能なプログラムを提供することを特徴とする提供媒体。 - エレメンタリストリームに重畳された順序情報に含まれる符号化情報と順序情報を換算することにより前記エレメンタリストリームを多重化して生成したトランスポートストリームを入力するトランスポートストリーム入力ステップと、
前記トランスポートストリーム入力ステップの処理において入力されたトランスポートストリームを、前記符号化情報及び前記表示情報に換算してエレメンタリストリームを生成するエレメンタリストリーム生成ステップと、
前記エレメンタリストリーム生成ステップの処理において生成されたエレメンタリストリームを出力するエレメンタリストリーム出力ステップと
を含む処理を実行させるコンピュータが読み取り可能なプログラムを提供することを特徴とする提供媒体。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP02937699A JP3584460B2 (ja) | 1999-02-05 | 1999-02-05 | ビットストリーム変換装置および方法、並びに提供媒体 |
| US12/487,356 US8160134B2 (en) | 1999-02-05 | 2009-06-18 | Encoding system and method, decoding system and method, multiplexing apparatus and method, and display system and method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP02937699A JP3584460B2 (ja) | 1999-02-05 | 1999-02-05 | ビットストリーム変換装置および方法、並びに提供媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000228652A JP2000228652A (ja) | 2000-08-15 |
| JP3584460B2 true JP3584460B2 (ja) | 2004-11-04 |
Family
ID=12274440
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP02937699A Expired - Fee Related JP3584460B2 (ja) | 1999-02-05 | 1999-02-05 | ビットストリーム変換装置および方法、並びに提供媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3584460B2 (ja) |
-
1999
- 1999-02-05 JP JP02937699A patent/JP3584460B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2000228652A (ja) | 2000-08-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR100420740B1 (ko) | 인코딩 장치, 인코딩 방법, 디코딩 장치, 디코딩 방법,코딩 시스템, 코딩 방법 | |
| US8160134B2 (en) | Encoding system and method, decoding system and method, multiplexing apparatus and method, and display system and method | |
| EP0944249B1 (en) | Encoded stream splicing device and method, and an encoded stream generating device and method | |
| JP3672185B2 (ja) | コーディングシステム及びこれを用いた装置並びに記録媒体 | |
| JP4836326B2 (ja) | 入来するｍｐｅｇ‐２ビットストリームをｓｍｐｔｅ‐２５９と互換性のあるビットストリームに変換する方法および装置、並びにｍｐｅｇ‐２と互換性のある入来ビットストリームをｓｍｐｔｅ‐２５９と互換性のあるビットストリームに変換する方法 | |
| US7610605B2 (en) | Method and apparatus for conversion and distribution of data utilizing trick-play requests and meta-data information | |
| JP3694888B2 (ja) | 復号装置および方法、符号化装置および方法、情報処理装置および方法、並びに記録媒体 | |
| JP6558246B2 (ja) | 送信装置、送信方法および受信装置 | |
| KR100818148B1 (ko) | Ｍｐｅｇ 및 다른 데이터 포맷에 적합한 순차적인 비디오시퀀스를 송신하기 위한 장치 및 방법 | |
| JP4387064B2 (ja) | データ伝送方法およびデータ伝送装置 | |
| KR101154743B1 (ko) | 부호화 장치 및 부호화 방법, 복호 장치 및 복호 방법, 기록 매체, 및 재생 장치 | |
| JP3874153B2 (ja) | 再符号化装置および再符号化方法、符号化装置および符号化方法、復号装置および復号方法、並びに、記録媒体 | |
| JP2005304065A (ja) | 復号装置および復号方法、符号化装置および符号化方法、情報処理装置および情報処理方法、並びに、記録媒体 | |
| JP3584460B2 (ja) | ビットストリーム変換装置および方法、並びに提供媒体 | |
| JP2000228768A (ja) | デジタル信号伝送装置および方法、並びに提供媒体 | |
| JP3890838B2 (ja) | 符号化ストリーム変換装置、および、符号化ストリーム変換方法、並びに、記録媒体 | |
| JP4139983B2 (ja) | 符号化ストリーム変換装置、および、符号化ストリーム変換方法、並びに、ストリーム出力装置、および、ストリーム出力方法 | |
| JP2000228769A (ja) | デジタル信号伝送装置および方法、デジタル信号受信装置および方法、並びに提供媒体 | |
| JP2006109513A (ja) | 符号化装置および方法、並びに記録媒体 | |
| JP4543321B2 (ja) | 再生装置及び方法 | |
| JP4539637B2 (ja) | ストリーム記録装置およびストリーム記録方法、ストリーム再生装置およびストリーム再生方法、ストリーム伝送装置およびストリーム伝送方法、並びに、プログラム格納媒体 | |
| JP4482811B2 (ja) | 記録装置及び方法 | |
| JP6614281B2 (ja) | 受信装置および受信方法 | |
| JP2004328771A (ja) | エンコーディング装置及び方法、デコーディング装置及び方法、並びに記録媒体 | |
| JPH09247623A (ja) | 記録再生装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20040712 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040725 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080813 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090813 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100813 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110813 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120813 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120813 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130813 Year of fee payment: 9 |
|
| LAPS | Cancellation because of no payment of annual fees |