JP4812171B2 - データ受信方法およびデータ受信装置 - Google Patents

Description

【技術分野】
【０００１】
この発明は、映像データ、音声データ、それ以外のメタデータ等を伝送する際に適用して好適なデータ受信方法およびデータ受信装置に関する。
【０００２】
ＳＤＩ（Serial Digital Interface）フォーマットは、テレビジョン工学や映像工学に関する規格を発行するＳＭＰＴＥ（Society of Motion Picture and Television Engineers）のＳＭＰＴＥ−２５９Ｍで標準化されている。このＳＤＩフォーマットは、基本的には、ディジタル信号規格であるＤ−１フォーマットもしくはＤ−２フォーマットを対象とした信号の規格である。
【０００３】
このＳＤＩフォーマットでは、限定されたメディアのデータのみを対象とした伝送しかできない。具体的には、伝送可能なメディアとして、ビデオデータは１チャネル、ベースバンドのオーディオデータは８チャネル程度である。そのため、ＳＤＩフォーマットは、マルチメディア化またはマルチチャネル化等に不向きである。
【０００４】
また、ＳＤＴＩ（Serial Data Transport Interface）フォーマットは、ＳＭＰＴＥのＳＭＰＴＥ−３０５Ｍで標準化されている。このＳＤＴＩフォーマットは、ＳＤＩフォーマットの利点を活かしつつ、ＳＤＩフォーマットと部分的に共通性を保ちながら、マルチメディア化またはマルチチャネル化等に好適なものとなっている。このＳＤＴＩフォーマットは、ベースバンド信号の伝送のための規格であり、終了同期符号（ＥＡＶ：End of Active Video）および開始同期符号（ＳＡＶ：Start of Active Video）を一緒に伝送している。
【０００５】
すなわち、ＳＤＴＩフォーマットでは、映像フレームの各１ラインの区間を、ＥＡＶが挿入される領域と、補助データが挿入される補助データ領域（アンシラリデータ部ＡＮＣ）と、ＳＡＶが挿入される領域と、映像データや音声データが挿入されるペイロード領域とで構成されるシリアルディジタルトランスファーインタフェースの伝送パケットを伝送する。
【０００６】
上述したようなＳＤＴＩフォーマットを使用した場合、ストリームの編集は、スイッチングにより実現される。この場合、ＮＴＳＣ方式では第１０ライン、ＰＡＬ方式では第６ラインがスイッチングのタイミングとされており、映像を主体としたタイミングでスイッチングが行われる。そのため、音声データにおいては、以下の理由から、音声ギャップを生じる場合がある。
【０００７】
例えば、標本化周波数が４８ｋＨｚである音声データを、５２５ライン／フレームであって５９．９４フィールド／秒のＮＴＳＣ方式の映像信号の各フレームに等分割すると、１映像フレームあたりの音声データのサンプル数は１６０１．６サンプル（＝（４８ｋＨｚ／５９．９４フィールド）×２フィールド）となり、整数とならない。そのため、音声データの各サンプルを、各映像フレームに対応してブロック分割する場合、各映像フレームには１６０１サンプルまたは１６０２サンプルが割り当てられる。
【０００８】
この場合、５映像フレーム分の音声データのサンプル数は８００８サンプル（＝５×１６０１．６サンプル）となることから、上述したブロック分割は、図２２Ａに示すような５フレームシーケンスで行われる。すなわち、１６０２サンプルの第１フレーム、１６０１サンプルの第２フレーム、１６０２サンプルの第３フレーム、１６０１サンプルの第４フレームおよび１６０２サンプルの第５フレームからなる５フレームの繰り返しとされる。
【０００９】
このように５フレームシーケンスで音声データのブロック分割が行われる場合にあって、上述したようにストリームのスイッチングによる編集を行うと、５フレームシーケンスの連続性が損なわれる場合が発生する。例えば、ストリームＳＴＭａの５フレームシーケンスが図２２Ａに示すようであり、これを基準位相とすると、スイッチングされてストリームＳＴＭａと切り替えられるストリームＳＴＭｂの位相パターンとしては、図２２Ｂ〜Ｆに示すように５種類が考えられる。
【００１０】
ストリームＳＴＭｂの位相パターンが図２２Ｂに示すようであるときは、スイッチングがあっても５フレームシーケンスの連続性が損なわれることがない。しかし、ストリームＳＴＭｂの位相パターンが図２２Ｃ〜Ｆに示すようである場合には、５フレームシーケンスの連続性が損なわれ、スイッチングのタイミングによっては、図２３に示すように１６０１サンプルのフレームが連続し、音声データサンプルが１個不足する区間（音声ギャップ）が発生することとなる。
【００１１】
この音声ギャップをそのまま再生した場合、音声波形の不連続を招き、予想できない大きなノイズが発生する場合がある。このため、音声ギャップが発生するおそれがある編集点を検出し、再生時に音声をミューティングする必要が生じる。
【００１２】
この発明の目的は、受信側で編集点に必要な音声のミューティング等の処理を簡単に行い得るようにすることにある。また、この発明の目的は、伝送路において生じたストリームの切り替えを編集点として容易に検出できるようにすることにある。
【発明の開示】
【００２６】
この発明に係るデータ受信方法は、映像フレームの各１ラインの区間を、終了同期符号が挿入される終了同期符号領域と、補助データが挿入される補助データ領域と、開始同期符号が挿入される開始同期符号領域と、映像データおよび／または音声データからなる主データを含む第１のデータと、上記映像データのピクチャ単位で当該ピクチャ単位毎にカウントされるカウント値のデータおよび編集点情報を持つ付属データを含む第２のデータとが挿入されるペイロード領域で構成されるシリアルディジタルトランスファーインタフェースの伝送パケットを受信するデータ受信方法であって、上記伝送パケットを受信する第１のステップと、この第１のステップで受信された上記伝送パケットより上記主データおよび上記付属データを抽出する第２のステップと、この第２のステップで抽出された上記付属データ内の上記カウント値のデータの不連続より編集点を検出する第３のステップと、この第３のステップで検出された上記編集点に対応して上記第２のステップで抽出された上記付属データ内の上記編集点情報を修正する第４のステップとを有し、上記編集点情報は、当該編集点情報を持つ上記ピクチャ単位を対象ピクチャ単位とし、上記対象ピクチャ単位が編集点に無関係を示すフラグ、上記編集点が上記対象ピクチャ単位の前にあることを示すフラグ、上記編集点が上記対象ピクチャ単位の後にあることを示すフラグ、および上記編集点が上記対象ピクチャ単位の前後の両方にあることを示すフラグである。
【００２７】
また、この発明に係るデータ受信装置は、映像フレームの各１ラインの区間を、終了同期符号が挿入される終了同期符号領域と、補助データが挿入される補助データ領域と、開始同期符号が挿入される開始同期符号領域と、映像データおよび／または音声データからなる主データを含む第１のデータと、上記映像データのピクチャ単位で当該ピクチャ単位毎にカウントされるカウント値のデータおよび編集点情報を持つ付属データを含む第２のデータとが挿入されるペイロード領域で構成されるシリアルディジタルトランスファーインタフェースの伝送パケットを受信するデータ受信装置であって、伝送パケットを受信する手段と、受信された上記伝送パケットより上記主データおよび上記付属データを抽出する手段と、上記伝送パケットより抽出された上記付属データ内の上記カウント値のデータの不連続より編集点を検出する手段と、上記検出された上記編集点に対応して上記伝送パケットより抽出された上記付属データ内の上記編集点情報を修正する手段とを備え、上記編集点情報は、当該編集点情報を持つ上記ピクチャ単位を対象ピクチャ単位とし、上記対象ピクチャ単位が編集点に無関係を示すフラグ、上記編集点が上記対象ピクチャ単位の前にあることを示すフラグ、上記編集点が上記対象ピクチャ単位の後にあることを示すフラグ、および上記編集点が上記対象ピクチャ単位の前後の両方にあることを示すフラグである。
【００２８】
この発明において、受信された伝送パケットより、映像データのピクチャ単位で当該ピクチャ単位毎にカウントされるカウント値のデータおよび編集点情報を持つ付属データと、映像データおよび／または音声データからなる主データとが抽出される。そして、付属データ内のカウント値のデータに不連続があることより編集点の検出が行われ、その検出された編集点に対応して付属データ内の編集点情報の修正が行われる。これにより、伝送路において例えばルータスイッチ（マトリクススイッチ）によりストリームの切り替えが行われているとき、編集点情報よりその切り替え点も編集点として検出でき、音声のミューティング等の処理を行うことが可能となる。
【発明を実施するための最良の形態】
【００２９】
以下、図面を参照しながら、この発明の実施の形態について説明する。本実施の形態においては、映像や音声の素材等のデータをパッケージ化してそれぞれのコンテンツアイテム（例えばピクチャアイテム(Picture Item)やオーディオアイテム(Audio Item)）を生成すると共に、各コンテンツアイテムに関する情報や各コンテンツに関するメタデータ等をパッケージ化して１つのコンテンツアイテム（システムアイテム(System Item)）を生成し、これらの各コンテンツアイテムをコンテンツパッケージとする。さらに、このコンテンツパッケージから伝送パケットを生成して、シリアルディジタルトランファーインタフェースを用いて伝送するものである。
【００３０】
このシリアルディジタルトランスファーインタフェースでは、例えばＳＭＰＴＥで規格化されたＳＭＰＴＥ−２５９Ｍ「10-bit 4:2:2 Component and 4fsc Composite Digital Signals -Serial Digital Interface」（以下「シリアルディジタルインタフェースＳＤＩ(Serial Digital Interface)フォーマット」という）のディジタル信号シリアル伝送フォーマットや、パケット化したディジタル信号を伝送する規格ＳＭＰＴＥ−３０５Ｍ「Serial Data Transport Interface」（以下「ＳＤＴＩフォーマット」という）を利用して、上述のコンテントパッケージを伝送するものである。
【００３１】
ＳＭＰＴＥ−２５９Ｍで規格化されているＳＤＩフォーマットを、映像フレームに配置した場合、ＮＴＳＣ５２５方式のディジタルのビデオ信号は、水平方向に１ライン当たり１７１６（４＋２６８＋４＋１４４０）ワード、垂直方向は５２５ラインで構成されている。また、ＰＡＬ６２５方式のディジタルのビデオ信号は、水平方向に１ライン当たり１７２８（４＋２８０＋４＋１４４０）ワード、垂直方向は６２５ラインで構成されている。ただし、１０ビット／ワードである。
【００３２】
各ラインについて、第１ワードから第４ワードまでの４ワードは、ビデオ信号の領域である１４４０ワードのアクティブビデオ領域の終了を示し、アクティブビデオ領域と後述するアンシラリデータ領域とを分離するための符号ＥＡＶ（End of Active Video）を格納する領域として用いられる。
【００３３】
また、各ラインについて、第５ワードから第２７２ワードまでの２６８ワードは、アンシラリデータ領域として用いられ、ヘッダ情報等が格納される。第２７３ワードから第２７６ワードまでの４ワードは、アクティブビデオ領域の開始を示し、アクティブビデオ領域とアンシラリデータ領域とを分離するための符号ＳＡＶ（Start of Active Video）を格納する領域として用いられ、第２７７ワード以降がアクティブビデオ領域とされている。
【００３４】
ＳＤＴＩフォーマットでは、上述のアクティブビデオ領域をペイロード領域として用いるものとし、符号ＥＡＶおよびＳＡＶがペイロード領域の終了および開始を示すものとされる。
【００３５】
ここで、各アイテムのデータをコンテンツパッケージとしてＳＤＴＩフォーマットのペイロード領域に挿入すると共に、ＳＤＩフォーマットの符号ＥＡＶおよびＳＡＶを付加して、図１に示すようなフォーマットのデータとする。この図１に示すフォーマット（以下「ＳＤＴＩ−ＣＰフォーマット」という）のデータを伝送するときには、ＳＤＩフォーマットやＳＤＴＩフォーマットと同様に、Ｐ／Ｓ変換および伝送路符号化が行われて、伝送速度が２７０Ｍｂｐｓ等のシリアルデータとして伝送される。
【００３６】
なお、図１において、括弧内の数字はＰＡＬ６２５方式のビデオ信号の数値を示しており、括弧がない数字はＮＴＳＣ５２５方式のビデオ信号の数値を示している。以下、ＮＴＳＣ方式についてのみ説明する。
【００３７】
図２は、符号ＥＡＶおよびアンシラリデータ領域に含まれるヘッダデータ（Header Data）の構成を示している。
【００３８】
符号ＥＡＶは、３ＦＦh，０００h，０００h，ＸＹＺh（hは１６進表示であることを示しており以下の説明でも同様である）とされている。
【００３９】
「ＸＹＺh」は、ビットｂ９が「１」に設定されると共に、ビットｂ０，ｂ１が「０」に設定される。ビットｂ８はフィールドが第１あるいは第２フィールドのいずれであるかを示すフラグであり、ビットｂ７は垂直ブランキング期間を示すフラグである。またビットｂ６は、４ワードのデータがＥＡＶであるかＳＡＶであるかを示すフラグである。このビットｂ６のフラグは、ＥＡＶのときに「１」とされると共にＳＡＶのときに「０」となる。またビットｂ５〜ｂ２は誤り検出訂正を行うためのデータである。
【００４０】
次に、ヘッダデータの先頭には、ヘッダデータ認識用のデータ「ＡＤＦ(Ancillary data flag)」として、固定パターン０００h，３ＦＦh，３ＦＦhが配されている。この固定パターンに続いて、アンシラリデータ領域の属性を示す「ＤＩＤ(Data ID)」および「ＳＤＩＤ(Secondary data ID)」が配されている。この「ＤＩＤ」および「ＳＤＩＤ」には、その属性がユーザアプリケーションであることを示す固定パターン１４０h，１０１hが配されている。
【００４１】
「Data Count」は、ヘッダデータのワード数を示すものであり、ワード数は４６ワード（２２Ｅh）とされている。このヘッダデータは、図２に示すように「Line Number-0」から「Header CRC1」までのデータで構成されている。
【００４２】
「Line Number-0,Line Number-1」は、テレビライン番号を示すものであり、ＮＴＳＣ５２５方式ではこの２ワードによって１から５２５まで映像フレームのライン番号が示される。また、ＰＡＬ方式６２５方式では１から６２５までの映像フレームのライン番号が示される。
【００４３】
「Line Number-0,Line Number-1」に続いて、「Line Number CRC0,Line Number CRC1」が配されており、この「Line Number CRC0,Line Number CRC1」は、「ＤＩＤ」から「Line Number-1」までの５ワードに対するＣＲＣ（cyclic redundancy check codes）の値であり、伝送エラーのチェックに用いられる。
【００４４】
「Code & AAＩ(Authorized address identifier)」では、ＳＡＶからＥＡＶまでのペイロード部のワード長がどのような設定とされているか、および送出側や受取側のアドレスがどのようなデータフォーマットとされているか等の情報が示される。
【００４５】
「Destination Address」は、データ受取側（送出先）のアドレスであり、「Source Address」は、データ送出側（送出元）のアドレスである。「Source Address」に続く「Block Type」は、ペイロード部がどのような形式とされているか、例えば固定長か可変長かを示すものである。ペイロード部が可変長の形式であるとき、圧縮データが挿入される。ここで、ＳＤＴＩ−ＣＰフォーマットでは、例えば圧縮されたビデオデータを用いてコンテントアイテムを生成したときにフレーム毎にデータ量が異なることから可変長ブロック(Variable Block)が用いられる。このため、ＳＤＴＩ−ＣＰフォーマットでの「Block Type」は固定データ１Ｃ１hとされる。
【００４６】
「CRC Flag」は、ペイロード部ＰＡＤの最後の２ワードにＣＲＣが置かれているか否かを示すものである。また、「CRC Flag」に続く「Data extension flag」は、ユーザーデータパケットを拡張しているか否かを示している。
【００４７】
「Data extension flag」に続いて４ワードの「Reserved」領域が設けられる、次の「Header CRC 0,Header CRC 1」は、「Code & AAI」から「Reserved3」までに対するＣＲＣ（cyclic redundancy check codes）の値であり、伝送エラーのチェックに用いられる。「Check Sum」は、全ヘッダデータに対するＣｈｅｃｋ Ｓｕｍコードであり、伝送エラーのチェックに用いられる。
【００４８】
次に、映像フレームのペイロード部ＰＡＤに挿入されるコンテンツパッケージについて、図３を用いて、さらに説明する。図３は、コンテンツパッケージの基本的構成を示している。
【００４９】
各コンテンツパッケージは、それぞれが一もしくはそれ以上のエレメントからなる４つまでのアイテムで構成される。この４つのアイテムとは、システム、ピクチャ、オーディオ、補助データの各アイテムである。
【００５０】
ピクチャとオーディオのアイテムは、基本的にテレビジョンの直接の構成要素を搬送するストリームエレメントである。これら２つのアイテムは、たびたび専用のストレージもしくは処理機器に送られる。補助データは、サブタイトルやテレテキストデータ等のデータ中心のコンテンツを搬送するために使用され、コンピュータ上で頻繁に作成され、そして処理されてストアされる。
【００５１】
デジタル配送サービスが増加した場合には、補助データタイプは、その数、ボリューム、複雑さにおいて、増えていくものと予想される。最後に、システムアイテムは、タイムスタンプのようなパッケージメタデータ、他の３つのアイテムの各エレメントのためのメタデータ、ダウンストリームパッケージ制御エレメントを通じて、全体としてのパッケージのためのサービスを提供する。ピクチャ、オーディオ、補助データアイテムは、それぞれ、例えば２５５個までのエレメントで構成できる。
【００５２】
図１は、システム、ピクチャ、オーディオ、補助データの４つのアイテムからなるコンテンツパッケージを、映像フレームのペイロード部に挿入したときのデータ構造を示している。
【００５３】
図４は、ＭＰＥＧ−２のＧＯＰの例を使用したコンテンツパッケージの配置（斜線部参照）を示している。符号化されたビデオデータの各フレームは、他のデータと共にパッケージ化されて一連のコンテンツパッケージが生成される。そして、ＳＤＴＩフォーマット上で、各フレームの第１フィールドから第２フィールドへ左から右の順番にスキャンされて転送が行われる。この場合、各フレームのビデオデータは異なる大きさに符号化されるが、符号化された各フレームのビデオデータは、各フレーム区間に対応して伝送される。
【００５４】
なお、各コンテンツパッケージはシステムアイテムを含まねばならず、他のアイテムのいずれかによって完結される。システムアイテムは、コンテンツパッケージの開始点を認識するために最初に配されている。すなわち、このシステムアイテムは、ＮＴＳＣ方式では第１３ラインより始まり、ＰＡＬ方式では第９ラインから始まる。また、１つのコンテンツパッケージにおいて、上述した４つのタイプのアイテムのうち、一つのタイプのアイテムしかない場合もある。
【００５５】
各アイテムは、図５に示すように、「Separator」で始まり、「End Code」で終わるＳＤＴＩ可変長ブロックとして構成される。「Separator」は、開始同期符号ＳＡＶに続いてすぐに始まる。「Separator」の値は「３０９h」、「End Code」の値は「３０Ａh」に設定されている。「Word Count」は「Data Block」のワード数を示しており、「Data Block」が各アイテムのデータである。
【００５６】
「Data Type」はパッケージ化されているデータが、どのようなアイテムのデータであるかを示すものである。「Data Type」の値は、例えばシステムアイテムでは「０４h」、ピクチャアイテムでは「０５h」、オーディオアイテムでは「０６h」、補助データアイテムでは「０７h」とされる。コンテンツパッケージの始まりは、システムアイテムの「Data Type」コードの検出によって行われる。
【００５７】
なお、各ＳＤＴＩ可変長ブロックの入力フォーマットは、１０ビットワードの一部をなすビットｂ０〜ｂ７の８ビットデータである。ビットｂ８とｂ９は、「Separator」ワードと「End Code」ワードのために、共に「１」に設定される。「Data Type」、「Word Count」、「Data Block」の各ワード用には、ＳＤＴＩフォーマット通りに、ビット８がビットｂ０〜ｂ７の偶数パリティとなり、ビットｂ９が奇数パリティとなるように設定される。
【００５８】
図６は、システムアイテムの構成を示している。「System Item Type」と「Word Count」は、それぞれ上述した可変長ブロックの「Data Type」と「Word Count」に相当する。このシステムアイテムは、ピクチャ、オーディオ、補助データの各アイテムのエレメントのためのメタデータと共に、パッケージメタデータおよびコントロールデータを含んでいる。
【００５９】
このシステムアイテムは、７ワードのシステムアイテムヘッダで始まり、ＳＭＰＴＥユニバーサルラベル、タイムスタンプ、パッケージ、ピクチャ、オーディオおよび補助データのメタデータセット、さらにコントロールエレメントが後に続くようにされる。
【００６０】
システムアイテムヘッダは、１ワードの「System Item Bitmap」と、１ワードの「Content Package Rate」と、「stream status」フラグ を含む１ワードの「Content Package Type」と、２ワードの「Channel Handle」と、２ワードの「Continuity Count」とからなっている。
【００６１】
「System Item Bitmap」を説明する。ビットｂ７は誤り訂正符号が加えられているか否かを示すフラグであり、「１」とされているときには誤り訂正符号が加えられていることを示している。ビットｂ６は、「SMPTE Universal Label」の情報があるか否かを示すフラグである。ここで「１」とされているときには、「SMPTE Universal Label」の情報がシステムアイテムに含まれていることを示している。
【００６２】
ビットｂ５およびｂ４は「Reference Date/Time stamp」、「Current Date/Time stamp」がシステムアイテムにあるか否かを示すフラグである。「Reference Date/Time stamp」では、例えばコンテンツパッケージが最初に作られた時間あるいは日付が示される。「Current Date/Time stamp」では、コンテンツパッケージのデータを最後に修正した時間あるいは日付が示される。
【００６３】
ビットｂ３はピクチャアイテム、ビットｂ２はオーディオアイテム、ビットｂ１は補助データアイテムがこのシステムアイテムの後にあるか否かを示すフラグであり、「１」とされているときはそれぞれそのアイテムがこのシステムアイテムの後に存在することを示す。
【００６４】
ビットｂ０は、コントロールエレメントがこのシステムアイテムにあるか否かを示すフラグであり、「１」とされているときはコントロールエレメントが存在することを示す。なお、図示せずもビットｂ８，ｂ９が上述したように付加されて１０ビットのデータとして伝送される。
【００６５】
「Content Package Rate」を説明する。ビットｂ７〜ｂ６は未定義領域(Reserved)であり、ビットｂ５〜ｂ１では、１倍速動作における１秒当たりのパッケージ数であるパッケージレート(Package Rate)が示される。ビットｂ０は１．００１フラグであり、フラグが「１」に設定されているときは、パッケージレートが１／１．００１倍であることが示される。
【００６６】
「Content Package Type」を説明する。ビットｂ７〜ｂ５は、ストリーム内における、当該ピクチャ単位の位置を識別するための「Stream Status」フラグである。この３ビットの「Stream Status」フラグによって、以下の８種類の状態が示される。
【００６７】
０：このピクチャ単位が、プリロール（pre-roll）区間、編集区間、ポストロール（post-roll）区間のいずれの区間にも属さない。
１：このピクチャ単位が、プリロール区間に含まれているピクチャであり、この後に編集区間が続く。
２：このピクチャ単位が、編集区間の最初のピクチャ単位である。
３：このピクチャ単位が、編集区間の中間に含まれているピクチャ単位である。
４：このピクチャ単位が、編集区間の最後のピクチャ単位である。
５：このピクチャ単位が、ポストロール区間に含まれているピクチャ単位である。
６：このピクチャ単位が、編集区間の最初、かつ最後のピクチャ単位である（編集区間のピクチャ単位が１つだけの状態）。
７：未定義
【００６８】
また、ビットｂ４は未定義領域(Reserved)である。ビットｂ３，ｂ２の「Transfer Mode」では、伝送パケットの伝送モードが示される。また、ビットｂ１，ｂ０の「Timing Mode」ではタイミングモードが示される。ここで、ビットｂ３，ｂ２で示される値が「０」のときには同期モード(Synchronous mode)、「１」のときには等時性モード(Isochronous mode)、「２」のときは非同期モード(Asynchronous mode)とされる。ビットｂ１，ｂ０で示される値が「０」のときには１フレーム分のコンテンツパッケージの伝送を第１フィールドの所定のラインのタイミングで開始するノーマルタイミングモード(Normal timing mode)とされ、「１」のときにはその伝送を第２フィールドの所定のラインのタイミングで開始するアドバンスドタイミングモード(Advanced timing mode)とされ、「２」のときはその伝送を第１および第２フィールドのそれぞれの所定のラインのタイミングで開始するデュアルタイミングモード(Dual timing mode)とされる。
【００６９】
「Channel Handle」について説明する。この「Channel Handle」ワードは、複数の番組のコンテンツパッケージが多重化されて伝送される場合に、各番組のコンテンツパッケージを識別するためのものである。この「Channel Handle」ワードの１６ビットの値を判別することで、多重化されているコンテンツパッケージをそれぞれ番組毎に分離することができる。
【００７０】
「Continuity Count」について説明する。「Continuity Count」は、１６ビットのモジュロカウンタである。このカウンタは、ピクチャ単位毎にカウントアップされると共に、それぞれのストリームで独自にカウントされる。したがって、ストリームスイッチャ等によってストリームの切り替えがあるときは、このカウンタの値が不連続となって、切り替え点（編集点）の検出が可能となる。なお、このカウンタは上述したように１６ビット（２¹⁶＝６５５３６）のモジュロカウンタであって非常に大きいので、２つの切り替えられるストリームにおいて、切り替え点でのカウンタの値が偶然に一致する確率が限りなく低く、切り替え点の検出のために、実用上充分な精度を提供できる。
【００７１】
「Continuity Count」の後には、上述したように「SMPTE Universal Label」、「Reference Date/Time stamp」、「Current Date/Time stamp」が設けられる。さらに、その後に、「Package Metadata Set」、「Picture Metadata Set」、「Audio Metadata Set」、「Auxiliary Metadata Set」がパッケージ化されたアイテムに応じて設けられ、番組タイトル等のコンテンツパッケージの情報や、ピクチャやオーディオあるいは補助データのパッケージ化されているアイテムに関する情報が示される。なお、「Picture Metadata Set」、「Audio Metadata Set」、「Auxiliary Metadata Set」は、対応するアイテムが「System Item Bitmap」のフラグによってコンテンツパッケージに内に含まれることが示されたときに設けられる。
【００７２】
さらに、これらの後に「Control Element」を設けることができる。この「Control Element」は、１バイトのエレメントタイプ識別子とそれに続く４バイトのワードカウントとコントロールエレメントデータからなる。
【００７３】
上述の「Time stamp」についてされに説明する。この「Time stamp」には１７バイトが割り当てられており、最初の１バイトで「Time stamp」であることが識別されると共に、残りの１６バイトがデータ領域として用いられる。ここで、データ領域の最初の８バイトは、例えばＳＭＰＴＥ１２Ｍとして規格化されたタイムコード(Time-code)を示しており、後の８バイトは無効データである。
【００７４】
図７は、ＳＭＰＴＥ−１２Ｍとして規格化されたタイムコードの構成を示している。このタイムコードは、「Frame」、「Seconds」、「Minutes」、「Hours」および４バイトの「Binary Group Data」からなる。
【００７５】
「Frame」について説明する。ビットｂ７はカラーフレームフラグ(Color Frame Flag)であり、このカラーフレームフラグにより第１のカラーフレームであるか第２のカラーフレームであるかが示される。ビットｂ６はドロップフレームフラグ(Drop Frame Flag)であり、このドロップフレームフラグによりピクチャアイテムに挿入された映像フレームがドロップフレームであるか否かが示される。そして、ビットｂ５，ｂ４でフレームの１０の位、ビットｂ３〜ｂ０でフレームの１の位が示される。
【００７６】
「Seconds」について説明する。ビットｂ７は、フィールド位相（ＮＴＳＣ）またはバイナリグループ０（ＰＡＬ）を示している。したがって、ＮＴＳＣ方式の場合には、このビットｂ７により第１フィールドであるか第２フィールドであるかが示される。そして、ビットｂ６〜ｂ４で秒の１０の位、ビットｂ３〜ｂ０で秒の１の位が示される。
【００７７】
「Minutes」について説明する。ビットｂ７は、バイナリグループ０（ＮＴＳＣ）またはバイナリグループ２（ＰＡＬ）を示している。そして、ビットｂ６〜ｂ４で分の１０の位、ビットｂ３〜ｂ０で分の１の位が示される。
【００７８】
「Hours」について説明する。ビットｂ７は、バイナリグループ１を示している。ビットｂ６は、バイナリグループ２（ＮＴＳＣ）またはフィールドフェーズ（ＰＡＬ）を示している。したがって、ＰＡＬ方式の場合には、このビットｂ６により第１フィールドであるか第２フィールドであるかが示される。そして、ビットｂ５，ｂ４で時の１０の位、ビットｂ３〜ｂ０で秒の１の位が示される。
【００７９】
また、上述した「Minutes」のビットｂ７および「Hours」のビットｂ７，ｂ６の３ビットＢ０〜Ｂ３（ＰＡＬ方式では、「Seconds」、「Minutes」、「Hours」のビットｂ７の３ビットＦＰ，Ｂ０，Ｂ２）によって、「Binary Group Data」の各ＢＧ１〜ＢＧ８にデータがあるか否かが示される。この「Binary Group Data」では、例えばグレゴリオ暦(Gregorian Calender)やユリウス暦(Julian Calender)での年月日を二桁で表示することができるようになされている。
【００８０】
上述した「Metadata Set」について、さらに説明する。図８は、「Metadata Set」の構成を示している。「Metadata Set」は、セット内の「Metadata Block」のワード数を定義する１ワードの「Metadata Count」によって始められる。「００ｈ」のメタデータカウント値は、有効な値であって、「Metadata Block」がないことを示す。この場合、「Metadata Set」は、たった１ワード長のものとなる。
【００８１】
図９Ａは「Package Metadata Block」の構成を示している。この「Package Metadata Block」は、１ワードの「Metadata Type」で始まり、次いで２ワードの「Word Count」（図９Ｃ）が続き、「Metadata」自体で完結する。「Metadata Type」ワードでは、「Metadata」の種類が示される。「Word Count」では、ブロックの終わりまでのワード数（可変長のブロックの「Word Count」に相当）が示される。
【００８２】
図９Ｂは、「Item Metadata Block」の構成を示している。この「Item Metadata Block」は、上述した「Package Metadata Block」と同様に、１ワードの「Metadata Type」で始まり、次いで２ワードの「Word Count」（図９Ｃ）が続く。さらに、１ワードの「Element Type」および１ワードの「Element Number」と続き、「Metadata」自体で完結する。「Element Type」および「Element Number」は、ピクチャ、オーディオ、補助データのアイテムの関連するエレメントとの一意的なリンクのための情報である。
【００８３】
次に、ピクチャ、オーディオおよび補助データのアイテムの構成を説明する。図１０は、これらのアイテムの構成を示している。これらのアイテムは、１ワードの「Item Type」から始まり、４ワードの「Word Count」および１ワードの「Item Header」が続き、その後に「Element Data Block」が続く。「Item Type」は、上述したようにアイテムの種類を示しており、ピクチャアイテムでは、「０５h」、オーディオアイテムでは「０６h」、補助データアイテムでは「０７h」である。「Item Word Count」では、このブロックの終わりまでのワード数（可変長ブロックの「Word Count」に相当）が示される。
【００８４】
「Item Header」では、「Element Data Block」のワード数が示される。「Element Data Block」がアイテムのデータ領域とされる。ここで、「Item Header」は８ビットで、「Element Data Block」のワード数を示しているので、「Element Data Block」の数は１〜２５５の範囲（０は有効でない）となる。
【００８５】
「Element Data Block」は、１ワードの「Element Type」から始まり、４ワードの「Element Word Count」および１ワードの「Element Number」が続き、「Element Data」で完結する。「Element Type」および「Element Word Count」により、それぞれ「Element Data」のデータ種類およびデータ量が示される。「Element Word Count」は、ＳＭＰＴＥ−３０５Ｍで規定されたと同じフォーマットを有し、その値は「Element Number」に対して「１」を加えた「Element Data」ワードの長さである。「Element Number」では、何番目の「Element Data Block」であるかが示される。
【００８６】
エレメントの一つであるＭＰＥＧ−２画像エレメントについて説明する。ＭＰＥＧ−２画像エレメントは、いずれかのプロファイル若しくはレベルのＭＰＥＧ−２ビデオエレメンタリストリーム（Ｖ−ＥＳ）である。プロファイルおよびレベルは、デコーダーテンプレートドキュメントで定義される。
【００８７】
図１１は、ＳＤＴＩ−ＣＰエレメントフレームにおけるＭＰＥＧ−２ Ｖ−ＥＳのフォーマット例を示している。この例は、キー、つまりＭＰＥＧ−２スタートコードを特定する（ＳＭＰＴＥレコメンデッドプラクティスにしたがった）Ｖ−ＥＳビットストリーム例である。ＭＰＥＧ−２ Ｖ−ＥＳビットストリームは、単純に同図に示されたようにデータブロックにフォーマットされる。
【００８８】
次に、エレメントの一つである８チャネルＡＥＳ−３エレメントについて説明する。このエレメントは、本来的に８チャネルまでの非圧縮ＡＥＳ−３オーディオデータを搬送するためのものであるが、既にＡＥＳ−３信号として符号化された圧縮ビットストリームや他の非オーディオデータを搬送することもできる。
【００８９】
図１２は、８チャネルＡＥＳ−３エレメントの構成を示している。このエレメントは、「Element Header」、「Audio Sample Count」、「Stream Valid Flags」および「AES-3 Data Area」で構成されている。
【００９０】
「Element Header」について説明する。ビットｂ７は「FVUCP Valid Flag」であり、ＡＥＳ(Audio Engineering Society)で規格化されたＡＥＳ−３のフォーマットにおいて定義されているＦＶＵＣＰが、「Data Area」のＡＥＳ−３フォーマットのオーディオデータで設定されているか否かが示される。ビットｂ６〜ｂ３は未定義領域（Reserved）であり、ビットｂ２〜ｂ０で、５フレームシーケンスのシーケンス番号（5-sequence count）が示される。
【００９１】
ここで、５フレームシーケンスについて説明する。１フレームが５２５ラインの走査線で（３０／１．００１）フレーム／秒のビデオ信号に同期すると共に、サンプリング周波数が４８ｋＨｚであるオーディオ信号を、ビデオ信号の各フレームのブロック毎に分割すると、１ビデオフレーム当たりのサンプル数は１６０１．６サンプルとなり整数値とならない。このため、５フレームで８００８サンプルとなるように１６０１サンプルのフレームを２フレーム設けると共に１６０２サンプルのフレームを３フレーム設けるシーケンスが５フレームシーケンスと呼ばれている。
【００９２】
図１３は、５フレームシーケンスを示している。すなわち、基準フレームに同期して、例えばシーケンス番号１，３，５のフレームが１６０２サンプル、シーケンス番号２，４のフレームが１６０１サンプルとされている。このシーケンス番号が、上述した「Element Header」のビットｂ２〜ｂ０で示される。
【００９３】
「Audio Sample Count」について説明する。この「Audio Sample Count」は、図１２に示すように、ビットｃ１５〜ｃ０を用いた０〜６５５３５の範囲内の１６ビットのカウンタであり、各チャネルのサンプル数が示される。なお、エレメント内では全てのチャネルが同じ値を有するものである。
【００９４】
「Stream Valid Flags」について説明する。この「Stream Valid Flags」では、８チャネルの各ストリームが有効であるか否かが示される。ここで、各チャネルに意味のあるオーディオデータが含まれている場合には、このチャネルに対応するビットが「１」に設定されると共に、それ以外では「０」に設定されて、ビットが「１」に設定されたチャネルのオーディオデータのみが伝送される。
【００９５】
「AES-3 Data Area」について説明する。この「Data Area」の「ｓ２〜ｓ０」は８チャネルの各ストリームを識別のためのデータ領域である。「Ｆ」はサブフレームの開始を示している。「ａ２３〜ａ０」はオーディオデータであり、「Ｐ，Ｃ，Ｕ，Ｖ」はチャネルステータスやユーザビット、Ｖａｌｉｄｉｔｙビット、パリティ等である。
【００９６】
次に、汎用のデータフォーマット（General Data Format）について説明する。この汎用のデータフォーマットは、全てのフリーフォームデータタイプを搬送するために使用される。しかし、このフリーフォームデータタイプには、ＩＴネイチャ（ワードプロセッシングファイルやハイパーテキスト等）などの特別な補助エレメントタイプは含まれない。
【００９７】
次に、メタデータの一つであるＭＰＥＧ−２画像編集メタデータについて説明する。このメタデータは、編集およびエラーメタデータと、圧縮符号化メタデータと、ソース符号化メタデータとの組み合わせである。これらのメタデータは、主として上述したシステムアイテム、さらには補助データアイテムに挿入することができる。
【００９８】
図１４Ａ〜Ｃは、それぞれ、図６に示すシステムアイテムの「Picture Metadata Set」領域に挿入されるＭＰＥＧ−２画像編集メタデータ内に設けられる「Picture Editing Bitmap」領域と、「Picture Coding」領域と、「MPEG User Bitmap」領域を示している。さらに、このＭＰＥＧ−２画像編集メタデータには、ＭＰＥＧ−２のプロファイルとレベルを示す「Profile/Level」領域や、ＳＭＰＴＥ１８６−１９９５で定義されたビデオインデックス情報を設けることも考えられる。
【００９９】
図１４Ａは、１ワードの「Picture Editing Bitmap」を示している。ビットｂ７およびｂ６は「Edit flag」であり、編集点情報を示すフラグである。この２ビットのフラグによって、以下の４種類の状態が示される。
【０１００】
００：編集なし
０１：編集点が、このフラグが付いているピクチャ単位の前にある（Pre-picture edit）
１０：編集点が、このフラグが付いているピクチャ単位の後にある（Post-picture edit）
１１：ピクチャ単位が１つだけ挿入され、編集点がこのフラグが付いているピクチャ単位の前と後にある（single frame picture）
つまり、ピクチャアイテムに挿入された映像データ（ピクチャ単位）が、編集点の前にあるか、編集点の後にあるか、さらに２つの編集点に挟まれているか、を示すフラグを「Picture Metadata Set」（図６参照）の「Picture Editing Bitmap」領域に挿入する。
【０１０１】
ビットｂ５およびｂ４は、「Error flag」である。この「Error flag」は、ピクチャが修正できないエラーを含んでいる状態にあるか、ピクチャがコンシールエラーを含んでいる状態にあるか、ピクチャがエラーを含んでいない状態にあるか、さらには未知状態にあるかを示す。ビットｂ３は、「Picture Coding」がこの「Picture Metadata Set」領域にあるか否かを示すフラグである。ここで、「１」とされているときは、「Picture Coding」が含まれていることを示している。
【０１０２】
ビットｂ２は、「Profile／Level」があるか否かを示すフラグである。ここで、「１」とされているときは、当該「Metadata Block」に「Profile／Level」が含まれている。この「Profile／Level」は、ＭＰＥＧのプロファイルやレベルを示すＭＰ＠ＭＬやＨＰ＠ＨＬ等を示す。
【０１０３】
ビットｂ１は、「HV Size 」があるか否かを示すフラグである。ここで、「１」とされているときは、当該「Metadata Block」に「HV Size 」が含まれている。ビットｂ０は、「MPEG User Bitmap」があるか否かを示すフラグである。ここで、「１」とされているときは、当該「Metadata Block」に「MPEG User Bitmap」が含まれている。
【０１０４】
図１４Ｂは、１ワードの「Picture Coding」の構成を示している。ビットｂ７には「Closed GOP」が設けられる。この「Closed GOP」は、ＭＰＥＧ圧縮したときのＧＯＰ（Group Of Picture）がＣｌｏｓｅｄ ＧＯＰか否かを示す。
【０１０５】
ビットｂ６には、「Broken Link」が設けられる。この「Broken Link」は、デコーダ側の再生制御に使用されるフラグである。すなわち、ＭＰＥＧの各ピクチャは、Ｂピクチャ、Ｂピクチャ、Ｉピクチャ・・・のように並んでいるが、編集点があって全く別のストリームをつなげたとき、例えば切り替え後のストリームのＢピクチャが切り替え前のストリームのＰピクチャを参照してデコードされるというおそれがある。このフラグをセットすることで、デコーダ側で上述したようなデコードがされないようにできる。
【０１０６】
ビットｂ５〜ｂ３には、「Picture Coding Type」が設けられる。この「Picture Coding Type」は、ピクチャがＩピクチャであるか、Ｂピクチャであるか、Ｐピクチャであるかを示すフラグである。ビットｂ２〜ｂ０は、未定義領域(Reserved)である。
【０１０７】
図１４Ｃは、１ワードの「MPEG User Bitmap」の構成を示している。ビットｂ７には、「History data」が設けられている。この「History data」は、前の世代の符号化に必要であった、例えば量子化ステップ、マクロタイプ、動きベクトル等の符号化データが、例えば「Metadata Block」の「Metadata」内に存在するユーザデータ領域に、History dataとして挿入されているか否かを示すフラグである。ビットｂ６には、「Anc data」が設けられている。この「Anc data」は、アンシラリ領域に挿入されたデータ（例えば、ＭＰＥＧの圧縮に必要なデータ等）を、上述のユーザデータ領域に、Anc dataとして挿入されているか否かを示すフラグである。
【０１０８】
ビットｂ５には、「Video index」が設けられている。この「Video index」は、Video index領域内に、Video index情報が挿入されているか否かを示すフラグである。このVideo index情報は１５バイトのVideo index領域内に挿入される。この場合、５つのクラス（１．１、１．２、１．３、１．４および１．５の各クラス）毎に挿入位置が決められている。例えば、１．１クラスのVideo index情報は最初の３バイトに挿入される。
【０１０９】
ビットｂ４には、「Picture order」が設けられている。この「Picture order」は、ＭＰＥＧストリームの各ピクチャの順序を入れ替えたか否かを示すフラグである。なお、ＭＰＥＧストリームの各ピクチャの順序の入れ替えは、多重化のときに必要となる。
【０１１０】
ビットｂ３，ｂ２には、「Timecode 2」、「Timecode 1」が設けられている。この「Timecode 2」、「Timecode 1」は、Timecode ２，１の領域に、ＶＩＴＣ（Vertical Interval Time Code）、ＬＴＣ（Longitudinal Time Code）が挿入されているか否かを示すフラグである。ビットｂ１，ｂ０には、「H-Phase」、「V-Phase」が設けられている。この「H-Phase」、「V-Phase」は、エンコード時にどの水平画素、垂直ラインからエンコードされているか、つまり実際に使われる枠の情報がユーザデータ領域にあるか否かを示すフラグである。
【０１１１】
次に、メタデータの一つであるオーディオ編集メタデータについて説明する。このメタデータは、編集およびエラーメタデータおよびソース符号化メタデータの組み合わせである。これらのメタデータは、主として上述したシステムアイテム、さらには補助データアイテムに挿入することができる。
【０１１２】
図１
５Ａ〜Ｄは、それぞれ図６に示すシステムアイテムの「Audio Metadata Set」領域に挿入されるオーディオ編集メタデータ内に設けられる「Field/Frame flags」領域と、「Audio Editing Bitmap」領域と、「CS Valid Bitmap」領域と、「Channel Status Data」領域を示している。
【０１１３】
ここで、有効とされているオーディオのチャネル数は、上述した図１２の「Stream Valid Flags」によって判別することができる。また「Stream Valid Flags」が「１」に設定されている場合には、「Audio Editing Bitmap」が有効となる。
【０１１４】
図１５Ａは、１ワードの「Filed/Frame flags」を示している。ビットｂ７〜ｂ０のそれぞれ第１〜第８のチャネルのオーディオデータに対応し、「０」であるときはフレーム単位でデータがパッキングされていることを示し、「１」であるときはフィールド単位でデータがパッキングされていることを示す。
【０１１５】
図１５Ｂは、１ワードの「Audio Editing Bitmap」を示している。ビットｂ７，ｂ６の「First edit flag」は第１フィールドの編集状況に関する情報を示し、ビットｂ５，ｂ４の「First edit flag」は第１フィールドの編集状況に関する情報を示す。ビットｂ３，ｂ２は、「Error flag」である。この「Error flag」では、修正できないようなエラーが発生しているか否か等が示される。ビットｂ１，ｂ０は、未定義領域（Reserved）である。
【０１１６】
図１５Ｃは、１ワードの「CS Valid Bitmap」を示している。この「CS Valid Bitmap」は、図１５Ｄに示すｎ（ｎ＝６，１４，１８あるいは２２）バイトの「Channel Status Data」のヘッダであり、データブロック内で２４のチャネルステータスワードのどれが存在しているかが示される。ここで、ビットｂ７の「CS Valid1」は、「Channel Status Data」の０から５バイトまでにデータがあるか否かを示すフラグである。同様に、ビットｂ６〜ｂ４の「CS Valid2」〜「CS Valid4」は、それぞれ、「Channel Status Data」の６から１３バイト、１４から１７バイト、１８から２１バイトまでにデータがあるか否かを示すフラグである。
【０１１７】
なお、「Channel Status Data」は２４バイト分とされており、最後から２番目の２２バイトのデータによって０から２１バイトまでにデータがあるか否かが示されると共に、最後の２３バイトのデータが、０から２２バイトまでのＣＲＣとされる。
【０１１８】
図１６は、上述したＳＤＴＩ−ＣＰフォーマットによるストリーム（以下、「ＳＤＴＩ−ＣＰトリーム」という）の伝送系の一例を示している。この伝送系１００は、ＶＴＲやサーバ等からなるストレージデバイス１０１と、ＳＤＴＩ−ＣＰインタフェース１０２と、伝送路１０４上に配置されたＳＤＴＩ−ＣＰストリームスイッチャ１０３とを有して構成されている。
【０１１９】
ストレージデバイス１０１には、複数のコンテンツパッケージが蓄積される。各コンテンツパッケージは、上述したようにシステムアイテム、ピクチャアイテム、オーディオアイテム、補助データアイテム等の複数のアイテムからなっている。ストレージデバイス１０１より順次出力されるコンテンツパッケージはＳＤＴＩ−ＣＰインタフェース１０２に供給される。ＳＤＴＩ−ＣＰインタフェース１０２は、各コンテンツパッケージをＳＤＴＩフォーマットの各映像フレームの伝送パケットのペイロード部に挿入し（図１参照）、その伝送パケットを伝送路１０４に送出する。なお、このようにＳＤＴＩ−ＣＰフォーマットによる伝送データ（ＳＤＴＩ−ＣＰストリーム）を伝送するときは、Ｐ／Ｓ変換および伝送路符号化が行われた後に、伝送速度が２７０Ｍｂｐｓのシリアルデータとして伝送される。
【０１２０】
また、伝送路１０４より送られてくるＳＤＴＩ−ＣＰストリームは、ＳＤＴＩ−ＣＰインタフェース１０２に供給される。ＳＤＴＩ−ＣＰインタフェース１０２は、このＳＤＴＩ−ＣＰストリームを受信し、各映像フレームの伝送パケットのペイロード部に挿入されている各コンテンツパッケージを抽出し、これをストレージデバイス１０１に順次供給する。ストレージデバイス１０１は、ＳＤＴＩ−ＣＰインタフェース１０２より順次送られてくるコンテンツパッケージを記録媒体に順次蓄積していく。
【０１２１】
なお、ストレージデバイス１０１は、システムアイテム、ピクチャアイテム、オーディオアイテム、補助データアイテム等からなるコンテンツパッケージを蓄積する代わりに、ＭＰＥＧビデオデータやオーディオデータ、さらにはメタデータ自体を蓄積するようにしてもよい。
【０１２２】
この場合、ストレージデバイス１０１より各映像フレーム毎のビデオデータ、オーディオデータ、メタデータ等が出力されてＳＤＴＩ−ＣＰインタフェース１０２に供給される。そして、ＳＤＴＩ−ＣＰインタフェース１０２は、それら各データよりシステムアイテム、ピクチャアイテム、オーディオアイテム、補助データアイテム等を作成した後にパッキングして各映像フレームのコンテンツパッケージを得、さらに各コンテンツパッケージをＳＤＴＩフォーマットの各映像フレームの伝送パケットのペイロード部に挿入し、その伝送パケットを伝送路１０４に送出する。
【０１２３】
またこの場合、伝送路１０４よりＳＤＴＩ−ＣＰストリームを受信したＳＤＴＩ−ＣＰインタフェース１０２は、各映像フレームの伝送パケットのペイロード部に挿入されている各コンテンツパッケージを抽出し、さらにそのコンテンツパッケージを構成するシステムアイテム、ピクチャアイテム、オーディオアイテム、補助データアイテム等のアイテムよりビデオデータ、オーディオデータ、メタデータ等のデータを得て、これをストレージデバイス１０１に順次供給する。ストレージデバイス１０１では、ＳＤＴＩ−ＣＰインタフェース１０２より順次送られてくるビデオデータ、オーディオデータ、メタデータ等のデータが蓄積される。
【０１２４】
次に、上述したようにストレージデバイス１０１に蓄積された各映像フレームのコンテンツパッケージ、あるいは各映像フレームのビデオデータ、オーディオデータ、メタデータ等のデータを再生して画像表示および音声出力をする場合について説明する。
【０１２５】
ストレージデバイス１０２は、図１７に示すように、データを蓄積するための記録媒体１５１と、蓄積データを処理して画像表示のためのビデオ信号や音声出力のためのオーディオ信号を生成するデコード回路１５２と、音声信号をミューティングするミュート回路１５３と、デバイス全体の動作を制御する制御部１５４とを備えている。
【０１２６】
画像表示や音声出力をする場合には、記録媒体１５１より蓄積データ（各フレームのコンテンツパッケージもしくはビデオデータ、オーディオデータ、メタデータ等のデータ）が読み出されてデコード回路１５２に供給され、デコード回路１５２ではその蓄積データに対してデータ伸長、デジタル／アナログ変換等の処理が行われてビデオ信号やオーディオ信号が生成される。そして、デコード回路１５２で得られるビデオ信号はモニタ１６１に供給され、モニタ１６１に画像が表示される。また、デコード回路１５２で得られるオーディオ信号はミュート回路１５３を介してスピーカ１６２に供給され、スピーカ１６２より音声が出力される。
【０１２７】
ところで、上述したように、システムアイテム（図６参照）の「Picture Metadata Set」を構成するＭＰＥＧ−２画像編集メタデータの「Metadata block」には１バイトの「Picture Editing Bitmap」があり、そのビットｂ７，ｂ６は編集点情報を示すフラグとなっている（図１４Ａ参照）。したがって、デコード回路１５２では、ピクチャ単位毎に、図１８に示すような２ビットの編集点情報も抽出され、この編集点情報は制御部１５４に供給される。
【０１２８】
ここで、上述したように、「００」は、編集なし、「０１」は、編集点がこのフラグが付いているピクチャ単位の前にある、「１０」は、編集点がこのフラグが付いているピクチャ単位の後にある、さらに「１１」は、編集点がこのフラグが付いているピクチャ単位の前と後にある、という状態を示している。したがって、制御部１５４は、デコード回路１５２からの編集点情報より図示のように編集点を検出できる。
【０１２９】
そして、制御部１５４は、検出された編集点で音声信号のミューティングが行われるようにミュート回路１５３を制御する。この場合、ミュート回路１５３では、例えば編集点前より音声レベルが徐々に小さくなって編集点で音声レベルが最低となり、その後に音声レベルが徐々に大きくなっていくクロスフェードによるミューティングが行われる。このように、編集点で音声側のミューティングが行われることにより、上述した音声ギャップの発生による予想できない大きなノイズの発生を防止することができる。
【０１３０】
また、図１６に示す伝送系におけるＳＤＴＩ−ＣＰストリームスイッチャ１０３はマトリックススイッチャであり、このストリームスイッチャ１０３により、ＳＤＴＩ−ＣＰストリームの切り替えが行われる。このＳＤＴＩ−ＣＰストリームの切り替えは、垂直同期（Ｖ−ｓｙｎｃ）区間、具体的にはＮＴＳＣ５２５方式で第１０ライン、ＰＡＬ６２５方式では第６ラインで切り替えが行われる。図１９は、ストリームＳＴＭａよりストリームＳＴＭｂに、時点ｔswでストリームの切り替えが行われる様子を示している。このようなストリームの切り替えは、ビデオデータがＭＰＥＧのＩピクチャで符号化されていれば、そのまま符号化ストリームに対して編集を行ったのと同じ効果を得ることができる。なお、図１９には、各映像フレーム内のピクチャアイテムおよびオーディオアイテムのみを模式的に示している。
【０１３１】
上述したようにストリームスイッチャ１０３でストリームの切り替えを行った場合も、上述したオーディオギャップが発生するおそれがある。そこで、ＳＤＴＩ−ＣＰインタフェース１０２では、ストリームの切り替えがあった後のＳＤＴＩ−ＣＰストリームを受信したときは、その切り替え点を編集点として検出し、上述した「Picture Editing Bitmap」内の編集点情報を示すフラグを修正することが行われる。
【０１３２】
上述したように、システムアイテム（図６参照）には、ストリーム独自に、ピクチャ単位毎にカウントアップされる「Continuity Count」ワードが設けられている。ストリームスイッチャ１０３によりストリームの切り替えがあったときは、このカウンタの値が不連続となる。例えば、図２０に示すように、ストリームＳＴＭａとストリームＳＴＭｂとを、時点ｔswで切り替えることによって、ストリームＳＴＭｃが生成される場合、図示のように、切り替え点において、ストリームＳＴＭｃの「Continuity Count」の値（カウント値）に不連続が発生する。
【０１３３】
次に、ＳＤＴＩ−ＣＰインタフェース１０２における編集点情報を示すフラグの修正に関して説明する。
【０１３４】
ＳＤＴＩ−ＣＰインタフェース１０２は、図２１に示すように、伝送路１０４（図２１には図示せず）よりＳＤＴＩ−ＣＰストリームを受信するための受信部１７１と、この受信部１７１で受信されたＳＤＴＩ−ＣＰストリームの各映像フレーム毎の伝送パケット（図１参照）よりコンテンツパッケージを抽出する抽出部１７２と、抽出された各コンテンツパッケージを構成するシステムアイテムより「Continuity Count」を検出する検出部１７３と、その「Continuity Count」の値の不連続を検出する検出部１７４と、抽出部１７２で抽出されたコンテンツパッケージを、システムアイテムに含まれるＭＰＥＧ−２画像編集メタデータの「Metadata block」にある「Picture Editing Bitmap」内の編集点情報を示すフラグを検出部１７４の検出結果に基づいて修正した後に、ストレージデバイス１０１に供給する修正部１７５とを備えている。
【０１３５】
受信部１７１で受信されたＳＤＴＩ−ＣＰストリームが抽出部１７２に供給され、各映像フレーム毎の伝送パケットよりコンテンツパッケージが抽出される。抽出された各コンテンツパッケージは修正部１７５に供給される。検出部１７４で「Continuity Count」の値の不連続が検出される場合、修正部１７５ではその検出出力に基づいて、「Picture Editing Bitmap」内のビットｂ７，ｂ６が修正される。
【０１３６】
つまり、「Continuity Count」の値の不連続が検出される場合、当該ピクチャ単位とその前のピクチャ単位との間に切り替え点が存在することを意味し、従ってその切り替え点を編集点として、各ピクチャ単位における「Picture Editing Bitmap」内のビットｂ７，ｂ６を修正する。例えば、切り替え点の前のピクチャ単位におけるビットｂ７，ｂ６は「００」から「１０」に修正され、その切り替え点の後のピクチャ単位におけるビットｂ７，ｂ６は「００」から「０１」に修正される。
【０１３７】
このように修正部１７５で「Picture Editing Bitmap」内のビットｂ７，ｂ６が修正されたシステムアイテムを含むコンテンツパッケージは、ストレージデバイス１０１に供給されて蓄積されることとなる。これにより、ストレージデバイス１０１では、ストリームスイッチャ１０３による切り替え点も編集点として取り扱われる。そのため例えば、再生系においては切り替え点において、上述したように音声信号のミューティングが行われる。また、ストレージデバイス１０１より出力して次の伝送を行う場合には、上述した切り替え点が編集点であるとして伝送されることとなる。
【０１３８】
なお、上述実施の形態においては、ピクチャ単位がフレーム単位である例を示したが、ピクチャ単位はそれに限定されるものでなく、フィールド単位、あるいはその他の単位であるものにも、この発明を同様に適用することができる。
【０１３９】
以上説明したように、この発明においては、ペイロード領域に、映像データのピクチャ単位で編集点情報を持つ付属データを含む第１のデータと、映像データおよび／または音声データからなる主データを含む第２のデータとが挿入される。そのため、受信側では、編集点情報を利用して、上述したように音声ギャップの発生のおそれがある編集点を検出でき、編集点に必要な音声のミューティング等の処理を行うことができる。
【０１４０】
また、この発明においては、ペイロード領域には、映像データのピクチャ単位で当該ピクチャ単位毎にカウントされるカウント値のデータを持つ付属データを含む第１のデータと、映像データおよび／または音声データからなる主データを含む第２のデータとが挿入される。伝送路において例えばルータスイッチ（マトリクススイッチ）によりストリームの切り替えが行われているとき、カウント値は不連続となる。そのため、受信側では、例えばカウント値の不連続より切り替え点を編集点として検出でき、編集点に必要な音声のミューティング等の処理を行うことができる。
【産業上の利用可能性】
【０１４１】
以上のように、この発明に係るデータ伝送方法および装置、データ受信方法および装置、並びに音声再生方法および装置は、動画像信号および音声信号等を伝送路を介して送信側から受信側に伝送するテレビ会議システム、テレビ電話システム、放送用機器などに適用して好適である。
【図面の簡単な説明】
図１は、ＳＤＴＩ−ＣＰフォーマットを説明するための図である。図２は、ＳＤＴＩ−ＣＰフォーマットのアンシラリデータ部内のヘッダの構成を示す図である。図３は、コンテンツパッケージの基本的構成を示す図である。図４は、ＭＰＥＧ−２のＧＯＰの例を使用したコンテンツパッケージの配置を示す図である。図５は、ＳＤＴＩ可変長ブロックの構成を示す図である。図６は、システムアイテムの構成を示す図である。図７は、ＳＭＰＴＥ−１２Ｍとして規格されたタイムコードの構成を示す図である。図８は、メタデータセットの構成を示す図である。図９Ａ〜図９Ｃは、「Ｉｔｅｍ Ｍｅｔａｄａｔａ Ｂｌｏｃｋ」の構成を示す図である。図１０は、ピクチャ、オーディオ、補助データのアイテムの構成を示す図である。図１１は、ＳＤＴＩ−ＣＰエレメントフレームにおけるＭＰＥＧ−２ Ｖ−ＥＳのフォーマット例を示す図である。図１２は、８チャネルＡＥＳ−３エレメントの構成を示す図である。図１３は、５フレームシーケンスを説明するための図である。図１４Ａ〜図１４Ｃは、ＭＰＥＧ−２画像編集メタデータを説明するための図である。図１５Ａ〜図１５Ｄは、オーディオ編集メタデータを説明するための図である。図１６は、ＳＤＴＩ−ＣＰストリームの伝送系の一例を示すブロック図である。図１７は、ストレージデバイス内の再生系の要部構成を示すブロック図である。図１８は、２ビットの編集点情報の一例を示す図である。図１９は、ＳＤＴＩ−ＣＰストリームの切り替えを説明するための図である。図２０は、ストリームの切り替えによる「Ｃｏｎｔｉｎｕｉｔｙ Ｃｏｕｎｔ」の値の不連続の発生を説明するための図である。図２１は、ＳＤＴＩ−ＣＰインタフェースにおける「Ｅｄｉｔ ｆｌａｇ」の修正に係る部分を示すブロック図である。図２２Ａ〜図２２Ｆは、音声データのブロック分割における５フレームシーケンスを説明するための図である。図２３は、ストリームの切り替えに伴うオーディオギャップの発生を説明するための図である。

Claims (3)

1. 映像フレームの各１ラインの区間を、終了同期符号が挿入される終了同期符号領域と、補助データが挿入される補助データ領域と、開始同期符号が挿入される開始同期符号領域と、映像データおよび／または音声データからなる主データを含む第１のデータと、上記映像データのピクチャ単位で当該ピクチャ単位毎にカウントされるカウント値のデータおよび編集点情報を持つ付属データを含む第２のデータとが挿入されるペイロード領域で構成されるシリアルディジタルトランスファーインタフェースの伝送パケットを受信するデータ受信方法であって、
   上記伝送パケットを受信する第１のステップと、
   上記第１のステップで受信された上記伝送パケットより上記主データおよび上記付属データを抽出する第２のステップと、
   上記第２のステップで抽出された上記付属データ内の上記カウント値のデータの不連続より編集点を検出する第３のステップと、
   上記第３のステップで検出された上記編集点に対応して上記第２のステップで抽出された上記付属データ内の上記編集点情報を修正する第４のステップとを有し、
   上記編集点情報は、
   当該編集点情報を持つ上記ピクチャ単位を対象ピクチャ単位とし、
   上記対象ピクチャ単位が編集点に無関係を示すフラグ、上記編集点が上記対象ピクチャ単位の前にあることを示すフラグ、上記編集点が上記対象ピクチャ単位の後にあることを示すフラグ、および上記編集点が上記対象ピクチャ単位の前後の両方にあることを示すフラグであるデータ受信方法。
2. 上記カウント値のデータが挿入される上記ペイロード領域内の領域は、上記開始同期符号領域の近傍にある請求項１に記載のデータ受信方法。
3. 映像フレームの各１ラインの区間を、終了同期符号が挿入される終了同期符号領域と、補助データが挿入される補助データ領域と、開始同期符号が挿入される開始同期符号領域と、映像データおよび／または音声データからなる主データを含む第１のデータと、上記映像データのピクチャ単位で当該ピクチャ単位毎にカウントされるカウント値のデータおよび編集点情報を持つ付属データを含む第２のデータとが挿入されるペイロード領域で構成されるシリアルディジタルトランスファーインタフェースの伝送パケットを受信するデータ受信装置であって、
   上記伝送パケットを受信する手段と、
   上記受信された上記伝送パケットより上記主データおよび上記付属データを抽出する手段と、
   上記伝送パケットより抽出された上記付属データ内の上記カウント値のデータの不連続より編集点を検出する手段と、
   上記検出された上記編集点に対応して上記伝送パケットより抽出された上記付属データ内の上記編集点情報を修正する手段とを備え、
   上記編集点情報は、
   当該編集点情報を持つ上記ピクチャ単位を対象ピクチャ単位とし、
   上記対象ピクチャ単位が編集点に無関係を示すフラグ、上記編集点が上記対象ピクチャ単位の前にあることを示すフラグ、上記編集点が上記対象ピクチャ単位の後にあることを示すフラグ、および上記編集点が上記対象ピクチャ単位の前後の両方にあることを示すフラグであるデータ受信装置。

Images