JPH09298748A - Ｍｐｅｇビットストリームにおいてスタッフィングビットの代わりにプライベートデータを送る方法および装置 - Google Patents

Abstract

(57)【要約】 （修正有） 【課題】データパケットのかたちの可変ビットレートビ
デオデータを含むシステムにおいて、スタッフィングバ
イトを取り除き、かつプライベートデータ（以下、「プ
ライベートスタッフデータ」という）を伝送するための
追加帯域を利用する方法およびシステムを提供する。 【解決手段】まずステップ４０２において、トランスポ
ートスト、リームからあるトランスポート・パケットが
えられた後に、ステップ４０４において、そのパケット
が検査される。この検査は、スタッフィングバイトが存
在しているかどうかの判定（ステップ４０５）と、存在
している場合にはそれらがどこに何個存在しているかの
判定（ステップ４０７）と、を含む。次に、この検査中
に得られた情報を用いて、ステップ４０８ではリマルチ
プレクシング動作がおこなわれる。すなわち、スタッフ
ィングバイトがプライベートスタッフデータに置き換え
られる。

Description

【発明の詳細な説明】

【０００１】

【発明の分野】本発明は、広くいえばＭＰＥＧ規格を用
いるデータ記録および伝送に関しており、特に、ＭＰＥ
Ｇ規格に準ずるトランスポートデータストリームにおけ
る「プライベートデータ」および「スタッフィングバイ
ト」の伝送の確立された規格に関する。

【０００２】

【発明の背景】高精細度テレビジョン（ＨＤＴＶ）は、
従来からあるテレビジョンにとって替わるべく進歩し続
けている。この進歩の道を開いているのは、ＨＤＴＶの
世界的な市場に提供される規格に携わるさまざまな会社
や団体である。

【０００３】そのような会社の集まりの１つは、ＡＴ＆
Ｔ、デビッド・サーノフ研究センター、マサチューセッ
ツ工科大学などを含む「ディジタルＨＤＴＶグランドア
ライアンス」として知られている。このグループによっ
てなされた発展をわかりやすく概観するものとしては、
民生エレクトロニクスについてのＩＥＥＥトランザクシ
ョンの一部として刊行されたロバート・ホプキンスによ
る「北米のディジタル地上ＨＤＴＶ：グランドアライア
ンスＨＤＴＶシステム」と題された論文（１９９４年
夏）がある。プログラムおよびトランスポート・パケッ
トストリームの使用を含むＨＤＴＶシステムの背景およ
び基本に関して、この論文が教示しているすべてが、本
願明細書では参考として援用される。

【０００４】グランドアライアンスに加えて、ムービン
グ・ピクチャ・エキスパート・グループ（ＭＰＥＧ）に
よっても多大な努力が払われてきている。ＭＰＥＧは、
国際標準化機構（ＩＳＯ）の中の委員会であり、ＨＤＴ
Ｖデータ（例えば、ＭＰＥＧ−２規格のトランスポート
・パケットストリーム用のフォーマット）の記録および
伝送のためのさまざまな規格を確立しようとしている。
採択された規格は、「情報技術のビデオセクション−動
画およびそれに付随する音声の一般的な符号化、ISO/IE
C 13818-2」（１９９４年１１月）（以下、「ビデオセ
クション」という）や、「情報技術のシステムセクショ
ン−動画およびそれに付随する音声の一般的な符号化、
ISO/IEC 13818-1」（１９９４年１１月）（以下、「シ
ステムセクション」という）のように定期的に発行され
る。「スタッフィング」技術を含む確立された規格およ
びフォーマットに関する、これら両規格による教示は、
本願明細書でも参考として援用される。

【０００５】ＭＰＥＧ−２規格のシンタクスは、オーデ
ィオおよびビデオデータの両方を運ぶのに用いられるデ
ータレコードのいくつかのレイヤを規定する。簡単のた
めに、ここでは、オーディオデータの復号化については
述べないことにする。あるビデオシーケンスを記述する
符号化されたデータは、いくつかのネスティングされた
レイヤにおいて表現される。すなわちシーケンスレイ
ヤ、グループオブピクチャレイヤ、ピクチャレイヤ、ス
ライスレイヤおよびマクロブロックレイヤである。この
情報の伝送に役立つように、複数のビデオシーケンスを
表現するディジタルデータストリームは、いくつかのよ
り小さいユニットに分割され、これらのユニットのそれ
ぞれは、対応するパケット化されたエレメンタリストリ
ーム（ＰＥＳ）パケット内に収められる。伝送時におい
て、それぞれのＰＥＳパケットが、こんどは、複数の固
定長のトランスポート・パケットに分割される。それぞ
れのトランスポート・パケットは、１つのＰＥＳパケッ
トだけに関するデータを含む。トランスポート・パケッ
トは、また、トランスポート・パケットを復号化すると
きに用いられるアダプテーション・フィールドをときに
は含む制御情報をもったヘッダを含む。

【０００６】ＭＰＥＧ−２で符号化された画像が受け取
られると、トランスポートデコーダは、トランスポート
・パケットを復号化することによってＰＥＳパケットを
再構成する。こんどはＰＥＳパケットが復号化されて、
上述のように階層化されたレコードにおける画像を表現
するＭＰＥＧ−２ビットストリームが再構成される。あ
る与えられたトランスポートデータストリームは、例え
ばインタリーブされたトランスポート・パケットとし
て、同時に複数の画像シーケンスを運ぶ。この柔軟性の
おかげで、トランスミッタは、ある規格にしたがってい
る４：３のアスペクト比の材料と、別の規格にしたがっ
ているワイドスクリーン（１６：９）の材料と、を提供
する複数のフォーマットを切り換えることができる。

【０００７】ＭＰＥＧ−２規格を用いてＨＤＴＶを消費
者に届けるためのシステムの実現方法について考える
と、一般的には、図１の高レベルブロック図で示される
ように、伝送側において、ビデオおよびオーディオ信号
は、対応するエンコーダ１１０および１１２に入力さ
れ、バッファ１１４および１１６においてバッファさ
れ、システムエンコーダ／マルチプレクサ１１８に運ば
れた後に、記録ユニット１２０で記録されるか、または
トランスミッタユニット１２０によって伝送されるかす
る。受信側において、信号は、システムデコーダ／デマ
ルチプレクサ１２２によって受け取られ、再びバッファ
１２４および１２６においてバッファされた後に、デコ
ーダ１２８および１３０によって復号化されて、オリジ
ナルのビデオおよびオーディオ信号として出力される。

【０００８】図１に示されている例における重要な局面
は、中間段における信号のバッファリングには可変の遅
延が含まれているが、入力から出力にいたる信号の全体
的な遅延は、実質的に一定であることが要求されること
にある。これは、フローコントロールを監視すること
と、バッファとによって達成される。

【０００９】図１において示されるように、エンコーダ
への入力から、デコーダからの出力、つまりプレゼンテ
ーションにいたる遅延はこのモデルでは一定であるが、
エンコーダ用およびデコーダ用のバッファのそれぞれを
通した遅延は可変である。これらのバッファのそれぞれ
を通した遅延が、１つのエレメンタリストリームのパス
の中で可変であるばかりでなく、ビデオおよびオーディ
オパスにおける個々のバッファ遅延もまた互いに異なっ
ている。したがって、組み合わせられたストリームにお
いてオーディオまたはビデオを表す符号化されたビット
の相対的な位置は、同期情報を示していない。符号化さ
れたオーディオおよびビデオの相対位置は、デコーダバ
ッファが適切にふるまうことができるように、システム
ターゲットデコーダ（ＳＴＤ）モデルによってのみ制限
される。したがって、同時に再生されるべき音声および
画像を表す符号化されたオーディオおよびビデオが、符
号化されたビットシステムの中で、１秒ものあいだ離れ
てしまう可能性がある。この値は、ＳＴＤモデルにおい
て許容される最大のデコーダバッファ遅延である。ＳＴ
Ｄモデルと同様なものには、ビデオバッファリングベリ
ファイア（ＶＢＶ）があり、これは、「ビデオセクショ
ン」の中で以下のように述べられている。

【００１０】『固定レートで符号化されたビデオビット
ストリームは、この節において規定されたビデオバッフ
ァリングベリファイア（ＶＢＶ）を通じて課される制約
条件を満たさなければならない……ＶＢＶは、仮想的な
デコーダであり、これは概念的にエンコーダの出力に接
続されている。……符号化されたデータは、バッファか
ら以下に規定されるように取り除かれる。この仕様書に
従うビットストリームは、ＶＢＶをオーバフローさせて
はいけない。low_delayがゼロに等しいとき、ビットス
トリームは、ＶＢＶバッファをアンダフローさせてはい
けない。』 エンコーダと連係して動作するＳＴＤモデルの一例を示
す高レベル図を、図２に示す。

【００１１】ＶＢＶバッファまたはＳＴＤモデルデコー
ダがアンダフローしてはいけないという要求は、それが
製品の品質を左右するといいうるほどに、非常に重要で
ある。固定ビットレートのビデオを維持するためには、
「スタッフィング」がシステムのさまざまな局面におい
ておこなわれる。「スタッフィング」は、単に要求され
たビットレートを維持するためだけに、データストリー
ムに「ドントケア」情報を付け足す作業である。

【００１２】ＰＥＳパケットを運ぶトランスポート・ス
トリーム・パケットについては、伝送されるデータのレ
ートをサポートしうるレベルにまでトランスポート・ス
トリーム・パケットのペイロードバイトを満たすにはＰ
ＥＳパケットデータが不十分であるときに、スタッフィ
ングが利用される。

【００１３】例えば、スタッフィングは、その中にある
データエレメントの長さの和よりも長いアダプテーショ
ン・フィールドを規定することによっておこなわれる。
その結果、アダプテーション・フィールドの後に残って
いるペイロードバイトは、利用可能なＰＥＳパケットデ
ータを正確に収めることができる。アダプテーション・
フィールドの中の余分なスペースおよび／またはペイロ
ードは、スタッフィングバイトによって満たすことがで
きる。

【００１４】図３は、それぞれのトランスポート・パケ
ットがヘッダおよびペイロードを含む場合における、ト
ランスポート・パケット・ストリームについてのフォー
マットおよびフィールドロケーションを示す。トランス
ポート・パケットのヘッダは、アダプテーション・フィ
ールドの存在を示したり、その長さおよび内容を制御し
たりするための複数のフィールドを含む。このアダプテ
ーション・フィールドの中において、別のフィールドが
「スタッフィングバイト」と指定されている。スタッフ
ィングバイトは、トランスポート・パケットのペイロー
ドにおいても同様に用いられる。

【００１５】しかし上述のように、トランスポートヘッ
ダにおいては、典型的にはすべて論理１の値（すなわ
ち、「１１１１１１１１」）であり、トランスポートペ
イロードにおいては、典型的にはすべて論理０の値（す
なわち、「００００００００」）であるスタッフィング
バイトを用いることは、システムリソース（例えば、伝
送帯域）の浪費である。したがって、今まで「スタッフ
ィング」に限られていたシステムリソースをより効率的
に利用することが望まれる。

【００１６】

【発明の要旨】データストリームを満たすためにスタッ
フィングバイトを用いるシステムであって、データパケ
ットのかたちの可変ビットレートビデオデータを含むシ
ステムにおいて、本発明は、スタッフィングバイトを取
り除き、かつプライベートデータ（以下、「プライベー
トスタッフデータ」という）を伝送するための追加帯域
を利用する方法およびシステムに関する。本発明は、デ
ータパケットの中でスタッフィングバイトが用いられて
いるかどうかの表示を含むデータパケットを検査し、か
つ所定の基準にしたがってスタッフィングバイトを除去
することがそのデータパケットについて適格であるかど
うかを判定する検査手段と、検査手段に応答して、スタ
ッフィングバイトをそのデータパケットから除去し、か
つ所定のプライベートスタッフデータをデータパケット
に加えるリマルチプレクシング手段と、を含む。

【００１７】本発明のある局面においては、追加伝送帯
域を得るために、スタッフィングバイトは、データパケ
ットのヘッダ部分から除去される。

【００１８】本発明の他の局面においては、追加伝送帯
域を得るために、スタッフィングバイトは、データパケ
ットのペイロード部分から除去される。しかしどちらの
局面においても、プライベートスタッフデータは、デー
タパケットのヘッダ部分に挿入される。

【００１９】

【詳細な説明】「背景」の欄において述べたように、Ｐ
ＥＳパケットを運ぶトランスポート・ストリーム・パケ
ットについては、設定されたデータレートをサポートす
るために、トランスポート・ストリーム・パケットのペ
イロードバイトを埋めるにはＰＥＳパケットデータが不
足しているときに、スタッフィングはおこなわれる。あ
る方法によれば、スタッフィングは、その中にあるデー
タエレメントの長さの和より長いアダプテーション・フ
ィールドを定義することによっておこなわれる。その結
果、アダプテーション・フィールドの後に残っているペ
イロードバイトは、利用可能なＰＥＳパケットデータを
正確に収めることができる。アダプテーション・フィー
ルドの余分なスペースは、スタッフィングバイトで埋め
られる。別の方法によれば、スタッフィングは、トラン
スポートペイロードの未使用部分をゼロで埋めることに
よっておこなわれる。

【００２０】広く可変ビットレートビデオに適用可能で
ある本発明は、本発明を用いなければ浪費される「スタ
ッフィング」専用のリソースを、プライベートデータを
挿入するために利用する。本発明の実施例においては、
従来の方法では浪費されていたこれらのリソースを利用
するために、利用価値のあるプライベートデータがスタ
ッフィングビットの代わりにトランスポート・ストリー
ム中に挿入される。すなわち好適には、リマルチプレク
シング動作がおこなわれることによって、トランスポー
ト・ストリームのフィールドにおけるある所定の条件
（例えば、スタッフィングバイトが存在するといった条
件）の存在に基づいて、スタッフィングバイトの代わり
にプライベートデータを用いるのに必要であり、しかも
規格に従っていることも必要な情報が生成されて、適切
に挿入される。

【００２１】なお、本発明は、広く可変ビットレートビ
デオに適用可能であるものとして説明されてはいるが、
本質的に固定ビットレートビデオにも適用可能である。
すなわち本発明においては、変更されたビデオは、つね
に可変ビットレートビデオであるが、処理され伝送され
るべきオリジナルのビデオは、固定ビットレートビデオ
でも可変ビットレートビデオでもよい。

【００２２】本発明以外の方法ではトランスポート・ス
トリームに符号化されてもよい典型的なプライベートデ
ータと区別するために、スタッフィングバイトを置換す
るのに用いられるデータは、「プライベートスタッフ」
データとよぶことにする。

【００２３】プライベートスタッフデータがトランスポ
ート・ストリームに挿入されるときには、必要な場合に
は、プライベートスタッフデータは、現在のトランスポ
ート・パケットがプライベートスタッフデータを含むこ
とを示す個別プログラム識別子（ＰＩＤ）コードととも
に送られうる。システムセクションにおいて記載される
ように、ＰＩＤは、トランスポート・ストリーム・ヘッ
ダの中の１３ビットフィールドであって、パケットペイ
ロードに格納されたデータの種類を示している。いくつ
かのＰＩＤ値は割り当て済みであり、いくつかは予約で
ある。本発明の実施例においては、新しく割り当てられ
たＰＩＤ値は、特定のトランスポート・パケットに含ま
れるプライベートデータが、通常のプライベートデータ
ではなく、実際はプライベートスタッフデータであるこ
とを示すために指定されうる。もし新しく割り当てられ
たＰＩＤが用いられるなら、プライベートスタッフデー
タの復号化は、受信端においてより簡単になるだろう。

【００２４】なお、スタッフィングバイトに加えて、い
くつかのトランスポート・パケットは、特別なヌルＰＩ
Ｄを用いるヌルパケットとして指定される。本願明細書
で説明される技術を用いれば、本発明により、ヌルパケ
ットをリマルチプレクシングしてプライベートスタッフ
データおよびすべての他の適切なフィールド（例えば、
アダプテーションおよびプライベートデータフィール
ド）を含むようにすることによって、そのヌルパケット
の浪費されていたリソースを利用することも可能にな
る。

【００２５】さらに、スタッフィングバイトは、「必要
に応じて」のみ用いられるので、プライベートスタッフ
データは、「バースト」基準で送られる。すなわち、ビ
デオチャネルがスタッフィングバイトを送ることを「欲
する」ときにだけ、送られる。プライベートスタッフデ
ータとして送られうる情報は、後に伝送されるべきプロ
グラムに関するプログラムレビュー、プログラム一覧な
どを含む。

【００２６】さらに背景をいえば、システムセクション
においては、シンタクス表現は、トランスポートヘッダ
のアダプテーション・フィールドを符号化／復号化する
ために用意されている。このシンタクスは、表１に再掲
される。

【００２７】

【表１】

【００２８】表１に示されるように、スタッフィングバ
イトは、アダプテーション・フィールドのトランスポー
トヘッダに必要に応じて置かれる。

【００２９】このシンタクスを参照すると、表１に掲げ
られ、かつ図３に示されているadaptation_field_lengt
hは、 adaptation_field_lengthの直後に続いているada
ptation_fieldにおけるバイト数を特定する８ビットの
フィールドである。例えば、実施例においては、トラン
スポート・ストリーム・パケットの中の単一のスタッフ
ィングバイトを挿入するために、値ゼロが用いられる。

【００３０】さらに、adaptation_field_controlの値が
「１１」であるとき、 adaptation_field_lengthの値
は、ゼロから１２８の範囲にある。 adaptation_field_
controlの値が「１０」のとき、 adaptation_field_len
gthの値は、「１８３」である。

【００３１】アダプテーション・フィールドについて、
stuffing_byteは、エンコーダによって挿入されうる、
通常、「１１１１１１１１」に等しい固定８ビット値で
ある。いったんスタッフィングビットとして識別される
と、この「ドントケア」情報は、受信端においてデコー
ダによって廃棄される。

【００３２】表１をさらに見ると、スタッフィングバイ
トに加えて、アダプテーション・フィールドについての
規格のシンタクスは、プライベートデータを設けてい
る。例えば、図３に示すように、スタッフィングバイト
フィールドの直前の２つのフィールドは、「５つのフラ
グ」および「オプションフィールド」として指定されて
いる。「５つのフラグ」フィールドは、オプションのフ
ィールドが存在するかどうかを示し、もし存在するな
ら、オプションフィールドが「トランスポート・プライ
ベート・データ」の存在と長さとを示す。これと同様の
フィールド同士の相互関係は、表１のシンタクス・フォ
ーマットにおいても示されている。

【００３３】スタッフィングバイトは、前述したように
トランスポートヘッダのアダプテーション・フィールド
において用いられるばかりではなく、トランスポートペ
イロードにおいてもスタッフィングバイトは用いられう
る。本発明によれば、アダプテーション・フィールドも
しくはトランスポートペイロードのいずれかからスタッ
フィングバイトが除去されることによって、プライベー
トスタッフデータに追加帯域を設けることができる。し
かしながら、スタッフィングバイトがアダプテーション
・フィールドおよびトランスポートペイロードのいずれ
一方から除去されるにせよ、あるいはその両方から除去
されるにせよ、本発明の実施例においてパケットに加え
られるプライベートスタッフデータは、トランスポート
ヘッダのアダプテーション・フィールドに対してのみ加
えられる。

【００３４】図４の(a)は、「リマルチプレクシング動
作」としても知られている、スタッフィングバイト除去
および置換動作の全般を達成するために実行される各ス
テップの実施例を示す高レベルフローチャートである。
このフローチャートは、アダプテーション・フィールド
あるいはトランスポートペイロードのいずれかにおける
スタッフィングバイト置換を全般的に説明するためのも
のである。

【００３５】図４の(a)に示すように、まずステップ４
０２において、トランスポートストリームからあるトラ
ンスポート・パケットがえられた後に、ステップ４０４
において、そのパケットが検査される。この検査は、ス
タッフィングバイトが存在しているかどうかの判定（ス
テップ４０５）と、存在している場合にはそれらがどこ
に何個存在しているかの判定（ステップ４０７）と、を
含む。次に、この検査中に得られた情報を用いて、ステ
ップ４０８ではリマルチプレクシング動作がおこなわれ
る。すなわち、スタッフィングバイトがプライベートス
タッフデータに置き換えられる。以上に述べた各ステッ
プについて、図４の(b)、図５〜図７および図８の(a)〜
(c)を参照して、以下にさらに詳しく説明する。

【００３６】図４の(b)は、アダプテーション・フィー
ルドにおけるスタッフィングバイトをプライベートスタ
ッフデータで置き換えるために本発明により実行される
各ステップの実施例を示す高レベルフローチャート図で
ある。図４の(b)に示されるように、まず、ステップ４
１０において、トランスポート・パケットがトランスポ
ートストリームからえられ、次にステップ４１２におい
て、そのパケットが検査される。この検査は、まず第１
に、アダプテーション・フィールドが在しているかどう
かの判定（ステップ４１４）を含んでいる。この判定
は、各種フィールドを検査することによりおこなわれ
る。次に、もしアダプテーション・フィールドが存在し
ているなら、そのアダプテーション・フィールドにプラ
イベートデータが存在しているかどうかが判定される
（ステップ４１６）。本実施例において、この判定は、
「５つのフラグ」フィールドおよび「トランスポートプ
ライベートデータの長さ」フィールドを検査することに
よっておこなわれる。もしプライベートデータが存在す
るのなら、処理は終了する。なぜなら、本発明の実施例
において、そのようなアダプテーション・フィールドは
プライベートスタッフデータに用いられないからであ
る。なお、とはいってもプライベートデータが既に存在
している場合においてプライベートスタッフデータを挿
入することが不可能なわけではないが、本発明では、既
にプライベートデータを含んでいるアダプテーション・
フィールドを乱すようなことは、あえておこなわないこ
とにする。

【００３７】図４の(b)のフローチャートの説明を続け
る。もしプライベートデータが存在しないのなら、ステ
ップ４１８において、各種フィールドから得られた情報
を用いてスタッフィングバイトのロケーションおよび数
が判定された後に、ステップ４２０において、リマルチ
プレクシング動作がおこなわれる。

【００３８】次に、リマルチプレクシング動作の説明に
移る。ここで、アダプテーション・フィールドをどのよ
うに変更するにしても、その変更は、確立された規格に
忠実に従って（すなわち、図３に示したフォーマットお
よび表１に掲げたシンタクスに即して）おこなうべきで
あることを銘記することが重要である。したがって、ア
ダプテーション・フィールドにおけるスタッフィングバ
イトをプライベートスタッフデータで置換したい場合に
は、そのプライベートスタッフデータがデータストリー
ム中に単に多重化されるばかりではなく、適切なフィー
ルドにおける適切なビットのすべてがそれに即して設定
されることになる。例えば、もしあるアダプテーション
・フィールドにおいて、最初の検査時にはオプションの
フィールドが存在していなかったのなら、リマルチプレ
クシング動作の後には、オプションのフィールドが確か
に存在することを反映させて、「５つのフラグ」フィー
ルドは変更される。さらに、アダプテーション・フィー
ルドが変更されたことを正しく表示するために、プライ
ベートスタッフバイト数が「トランスポートプライベー
トデータの長さ」フィールドに加えられる。

【００３９】本願明細書中に参考として援用されている
規格をはじめとする確立された規格を認識している当業
者であれば、スタッフィングバイトをプライベートスタ
ッフデータで置換しようとする際に存在しうる多種多様
なフィールドの組み合わせを認識することによって、ア
ダプテーション・フィールドの更新された内容を反映す
るためには、必要なすべてのフィールドをリマルチプレ
クシング動作中に変更しなければならないことを理解で
きるであろう。

【００４０】当業者の理解能力を問うものではなく、単
なる実施例を示すものとして、図５〜図７および図８の
(a)〜(c)は、単一のトランスポートペイロードからスタ
ッフィングバイトを検出・除去するために必要であり、
かつアダプテーション・フィールドにおけるプライベー
トスタッフデータをトランスポートレイヤのかたちで伝
送するのに、結果として残った余分な帯域を利用するた
めに必要である各ステップを詳細に説明するフローチャ
ートおよびフィールド置換図である。

【００４１】なお、図５〜図７および図８の(a)〜(c)に
図示された方法は、 １）（上述した）アダプテーション・フィールドの構造
に基づいて、トランスポート・パケット内におけるビデ
オスタッフィングバイトの必要最低限の数を見出し、 ２）トランスポートペイロード内におけるビデオスタッ
フィングバイトのそれぞれのロケーションを検出し、か
つそれらのバイトをそのペイロードから除去し、 ３）プライベートデータをアダプテーション・フィール
ド中に挿入し、さらに ４）ピクチャヘッダ構造のロケーションを検出し、かつ
そのVBV_DELAY値を０×ＦＦＦＦで置換する方法であ
る。

【００４２】また、図５〜図７および図８の(a)〜(c)に
図示する方法においては、 １）プログラム連関テーブル（ＰＡＴ）およびプログラ
ムマップテーブル（ＰＭＴ）は既に処理済みであり、ま
た目標とするビデオエレメンタリストリームは既に認識
されているものとし、また、 ２）そのビデオエレメンタリストリームを含むトランス
ポートペイロードのペイロードパージングは、一番最初
のビデオシーケンスから、あるいはそれよりも前に開始
し、かつシーケンスエンドコードで終了するものとす
る。

【００４３】ここで図５〜図７の説明に移る。これらの
図に示された処理においては、いくつかのフィールドの
サイズのトラッキングが行われるとともに、トランスポ
ートヘッダおよびペイロード内において、多くのフィー
ルドが検査される。そのことを目的として、処理全体を
通して複数の変数が用いられる。特に、図５、図６およ
び図７のそれぞれについて以下に示す各変数の名称は、
それぞれのフローチャートについて用いられる特定の変
数とそれらに対応する定義とを示している。

【００４４】図５で用いられる変数 Cnt_V_ZB＝ビデオゼロバイトのカウンタ StrtCd_Fnd＝スタートコードの発見を表示するフラグ PictStrtCd_Fnd＝ピクチャスタートコードの発見を表示
するフラグ MIN_V_SB＝ＴＰパケット内に存在する必要のあるビデオ
スタッフィングバイトの最小数 Cnt_V_SB＝ビデオスタッフィングバイトのカウンタ Cnt_Pyld_B＝ＴＰペイロードバイトのカウンタ図６で用いられる変数 PictStrtCd_Fnd＝ピクチャスタートコードの発見を表示
するフラグ StrtCd_Fnd＝スタートコードの発見を表示するフラグ Cnt_Pict_Hdr＝ピクチャヘッダ構造におけるバイトのカ
ウンタ図７で用いられる変数 Cnt_Pyld_B＝ ＴＰペイロードバイトのカウンタ Cnt_V_SB＝ビデオスタッフィングバイトのカウンタ Cnt_V_ZB＝ビデオゼロバイトのカウンタ Cnt_Cur_SB＝現在のビデオスタッフィングバイトのカウ
ンタ StrtCd_Fnd＝スタートコードの発見を表示するフラグ 図５を参照すると、ステップ５１０〜５１４において
は、処理中に用いられる各変数「Cnt_V_ZB」、「StrtCd
_Fnd」および「PictStrtCd_Fnd」が初期化される。ステ
ップ５１６および５１８において、次のｓｙｎｃバイト
を検出し、かつＰＩＤがエレメンタリビデオプログラム
用のものであることをベリファイするために前処理がお
こなわれる。

【００４５】ステップ５２０、５２２および５２４にお
いて、この処理では、アダプテーション・フィールド制
御フィールドおよびアダプテーション・フィールドの長
さフィールドが検査され、次に、検査の結果に基づい
て、トランスポート・パケット内に存在している必要の
あるスタッフィングバイトの最小数を表示する変数がス
テップ５２６および５２８において設定される。

【００４６】次に、ステップ５３０において、このアダ
プテーション・フィールド中にプライベートデータが存
在しているかどうかが判定される。そしてその判定に基
づいて、ＴＰパケット内に存在している必要のあるスタ
ッフィングバイトの最小数を表示する変数が、ステップ
５３２においてこの処理では再び設定される。ここで、
前述したように、もしプライベートデータがアダプテー
ション・フィールド内に既に存在していると判定されれ
ば、処理は終了し、新たに別の処理が開始される。

【００４７】図５の処理は、次にステップ５３６で、ペ
イロードの最初のバイトへとジャンプする一方で、ステ
ップ５３８では変数「Cnt_V_SB」および「Cnt_Pyld_B」
を初期化する。

【００４８】さて、図６および図７に示されるフローチ
ャートにつながるリンクを含んでいるステップ５４０
は、本質的には図４の(a)におけるステップ４０４に対
応している。ここで、スタッフィングバイト数とそのロ
ケーションが判定される。図６のフローチャートはペイ
ロードにおけるスタートコードを検出・トラッキング
し、図７のフローチャートはスタッフィングバイトを検
出・カウントする。それぞれにおいて、どこに何個のバ
イトが存在しているかをトラッキングすることは、この
処理がスタッフィングバイトを除去することを可能にし
（それによってプライベートスタッフデータに追加帯域
をもたらすことができ）、かつピクチャデータを保存す
ることを可能にする。ステップ５４１においては、「Cn
t_V_SB」がチェックされることによって、この変数がMI
N_V_SBよりも大きいかどうかが確かめられる。ステップ
５４１の目的は、このトランスポート・パケット内に見
出されたスタッフィングバイトの数が、リマルチプレク
シングを完遂するためには存在している必要のあるスタ
ッフィングバイトの最小数よりも大きいかどうかを確か
めることである。

【００４９】最後に、（図４の(a)におけるステップ４
０８にほぼ対応する）ステップ５４２および５４４にお
いては、スタッフィングバイトの除去、および、適切な
制御フィールドの変更に伴うプライベートスタッフデー
タのリマルチプレクシングがそれぞれおこなわれる。図
８の(a)、(b)および(c)にその実施例が示されているス
テップ５４４により表されるこのリマルチプレクシング
動作を以下にさらに詳しく説明する。

【００５０】図６を参照すると、この処理は、トランス
ポート・パケットのペイロードにおける意味のあるデー
タ（例えば、ピクチャデータ）により用いられるスター
トコードのフォーマットを判別することによって、スタ
ートコードに出会うまでこのパケットペイロードにおけ
るスタッフィングバイトをカウントする。各種スタート
コードに対するシンタクスは、ビデオセクションに示さ
れている。この処理をおこなうことにより、トランスポ
ート・パケットペイロードにより運ばれている意味のあ
るデータが乱されることは確実に回避できる。

【００５１】ステップ６１０および６１２に示されてい
るように、図６における処理は、 PictStrtCd_Fndある
いはStrtCd_Fndが「１」に等しい間においては、 PictS
trtCd_FndおよびStrtCd_Fndの両方が「０」に等しくな
る条件が存在するまで、このトランスポートペイロード
を１度に１バイトずつ認識し処理し続ける。この条件が
検出されると、処理は、スタッフィングバイトをトラッ
キングし識別しようとする、図７に示されている各ステ
ップへとシフトする。

【００５２】それまでの間において、もしPictStrtCd_F
ndが「１」に等しいのなら、ステップ６３０においてPi
ctStrtCd_Fndが最終的にリセットされるまで、それに続
くピクチャヘッダバイトがステップ６１４、６１６、６
１８、６２０、６２２、６２４、６２６および６２８に
おいてトラッキングされ処理される。また、もしPictSt
rtCd_Fndが「０」に等しいが、StrtCd_Fndが「１」に等
しいのなら、 PictStrtCd_Fndがステップ６３４で設定
されるか、あるいはStrtCd_Fndがステップ６３８でリセ
ットされるように、データの現在のバイトは、ステップ
６３２、６３４、６３６および６３８において処理され
る。

【００５３】なお、変数PictStrtCd_FndおよびStrtCd_F
ndの状態は、直前のトランスポートペイロードにおいて
処理され決定された条件を反映しうる。すなわち、その
ピクチャデータまたはスタッフィングバイトは１つ以上
のトランスポートペイロードにわたってオーバラップす
ることが可能である。したがって、もし直前のトランス
ポートペイロードがスタートコードで終わっているのな
ら、現在のトランスポートペイロードを処理するに当た
っても、そのことは考慮に入れておくべきである。なぜ
なら、トランスポート・パケットは、それよりも大きい
ＰＥＳパケットの一部にすぎないからである。例えば３
つの連続するトランスポート・パケットを考えてみる
と、スタッフィングは、第１のパケットのペイロードの
途中で始まり、第２のパケットの全ペイロードを通して
継続し、そして第３のパケットの途中で終わることがで
きる。スタッフィングバイトの検出および除去に当たっ
ては、このようなタイプの条件を考えるべきである。

【００５４】図７を参照すると、処理はスタッフィング
バイトのサーチに移っている。このサーチは、全ビット
値を慎重にチェックすることと、スタッフィングバイト
を識別した後でそれらを除去するために用いられる多数
の点のロケーションをトラッキングすることと、によっ
ておこなわれる。簡単にいうと、ステップ７１０および
７１２は、出会うことになる複数のゼロバイトを処理
し、カウントする。結果として、処理されるべきバイト
は、ステップ７１０からのＮＯ出口パスに対応する「０
×００」とはならず、ステップ７１６のＹＥＳ出口パス
に対応し、スタートコードが発見されたことを表示する
「０×０１」となる可能性が高い。この時点で、図６に
おいて用いられた変数StrtCd_Fndがステップ７１８で設
定されて、スタッフィングバイトのカウント動作はスト
ップする。スタッフィングバイトの実際の数は、Cnt_V_
ZBから２を引くことによってステップ７２０で決定され
る。なぜなら、スタートコードは２３の論理０と１つの
論理１を含んでいるからである。しかしながら、ステッ
プ７１６は７つの論理０と１つの論理１とについてチェ
ックするにすぎないので、さらに１６の論理０（つまり
「０×００００」の２バイト）がスタッフィングバイト
とは見なされていない。

【００５５】したがって、もしステップ７２２におい
て、スタッフィングバイト数であるCnt_Cur_SBがペイロ
ードバイトカウントよりも小さく、ステップ７２４では
ゼロに等しくなければ、ペイロード処理において重要な
点をカウントしかつマークするのに用いられてきたCnt_
Pyld_BおよびCnt_V_SBなどの変数を用いて、スタッフィ
ングバイトのロケーションおよび量が計算され、かつ記
録される。なお、この処理中に計算されたスタッフィン
グバイト数は、その後ステップ７２８において、以前に
記録されたスタッフィングバイト数に加えられる。

【００５６】図６および図７に関してこれ以上の説明を
つけ加える根拠はなかろう。なぜなら、本願明細書にお
ける、図５〜図７および図８の(a)〜(c)を参照して述べ
た説明を含むこれまでの説明を既に把握し、かつ、本願
明細書において援用されている規格を含む確立された規
格の数々を既に掌握している当業者には、図６〜図７に
説明されている処理を理解することは可能であるからで
ある。

【００５７】図８の(a)〜(c)は、図５〜図７に記載され
ている、本発明による処理がおこなわれる前後における
トランスポート・パケットの実施例を示している。特
に、図８の(a)は、もともとはアダプテーション・フィ
ールドをもっていなかったトランスポート・パケットに
関するフィールド置換図（すなわち、オリジナルのもの
と処理後のものを示す図）である。この図は、図５のス
テップ５２０から出ているＹＥＳパスに対応している。
図８の(a)に示されているように、トランスポート・パ
ケットペイロードからはそのスタッフィングバイトが取
り去られており、プライベートデータを運ぶトランスポ
ートヘッダを表示するのに必要である適切な各種フィー
ルドを含むアダプテーション・フィールドが生成されて
おり、また、ペイロードがもはやスタッフィングバイト
を含んでいないようにパケットが再構成されている。処
理済みのトランスポート・パケットが図示されている下
の名称に見られるように、新たに形成された各種フィー
ルド（例えば、アダプテーション・フィールドの長さ）
に置かれた値の多くは、図５〜図７における処理中に用
いられた各変数（例えば、Cnt_V_SB）の状態から得られ
ている。

【００５８】図８の(b)は、トランスポート・パケット
がアダプテーション・フィールドを含んでいたが、その
アダプテーション・フィールドの長さはゼロバイトであ
った場合を示している。この図は、図５のステップ５２
２および５２４から出ているＹＥＳパスに対応してい
る。この場合においても、スタッフィングバイトはトラ
ンスポートペイロードから取り去られており、また、変
数の値に従って適切なアダプテーション・フィールドが
生成され、および／または変更されている。

【００５９】図８の(c)は、アダプテーション・フィー
ルドが存在していたが、そのアダプテーション・フィー
ルドの長さはゼロに等しくなく、かつプライベートがな
い場合のさらに別の実施例を示している。この図は、図
５のステップ５３０から出ているＮＯパスに対応してい
る。この場合においても、同様のスタッフィングバイト
除去とアダプテーション・フィールドの変更がおこなわ
れる。

【００６０】図９は、本発明において好適に用いられる
プライベートスタッフプロセッサの実施例を示すブロッ
ク図である。図９において、トランスポートストリーム
は、アナライザ９１２により監視されると同時に、バッ
ファ９１０においてえられる。アナライザ９１２は、図
４の(a)におけるステップ４０２〜４０４および図４の
(b)におけるステップ４１０〜４１８に対応する処理の
大半をおこない、ペイロード処理に当たっては、ステッ
プ５４４を除き、図５〜図７に示されているすべてのス
テップを含む処理をおこなう。次に、アナライザ９１２
は、リマルチプレクサ９１４に対してリマルチプレクシ
ング動作をおこなうべきかどうか、またどの情報を用い
るかについて命令を与える。リマルチプレクサ９１４
は、ステップ４０８、４２０および５４４に対応する処
理をおこなう。この場合においても、バッファ９１０に
より与えられたトランスポートストリームは、バッファ
９１６により一時的に遅延される。バッファ９１０およ
び９１６は、それぞれアナライザ９１２およびリマルチ
プレクサ９１４の処理遅延を補償するのに全般的に用い
られる。コントローラ９１８は、これらのバッファを通
るデータフローの制御を含む種々雑多な制御動作をおこ
ない、最終的には、トランスポート・パケットがマルチ
プレクサ９２０を通って出るかどうか、つまり、リマル
チプレクサ９１６の処理済み出力が出てくるかどうかを
決定する。

【００６１】なお、アダプテーション・フィールドにお
けるスタッフィングバイトを処理するために広く用いら
れるフローチャートのみを示した（図４の(b)）が、当
業者であれば、本願明細書に開示された情報および公知
の情報を活用することによって、スタッフィングバイト
をアダプテーション・フィールドから検出・除去し、か
つそのアダプテーション・フィールドにおいてフィール
ドを生成すること、あるいはフィールドを変更すること
は、容易におこなうことができるであろう。例えば、こ
の場合に対応するフィールド置換図は、オリジナルのト
ランスポート・パケットがＴＰペイロードの前にスタッ
フィングバイトを含むことになり、また、処理済みのト
ランスポート・パケットがアダプテーション・フィール
ドにおいて新しいプライベートデータ（すなわち、適切
なプライベートデータロケーションにおけるプライベー
トスタッフデータ）は含むが、スタッフィングバイトは
含まないことになる点を除いて、図８の(c)と酷似した
ものになる。さらに、表１に記述され、図３に示されて
いる各フィールドロケーションは、スタッフィングバイ
トをアダプテーション・フィールドから検出しかつ除去
するのに必要な詳細を提供する。

【００６２】以上に本発明を、ＭＰＥＧ符号化データス
トリームにおいてスタッフィングバイトの代わりにプラ
イベートスタッフデータを用いるための方法および装置
のかたちで実現されるものとして説明し記載したが、本
発明は以上に示した詳細に限定されるものではなく、添
付の請求の範囲に等価である範囲内であって、かつ本発
明の着想を超えることがない限り、細部にさまざまな改
変を加えることが可能である。

【図面の簡単な説明】

【図１】（従来の技術）ディジタルマルチプログラム伝
送／受信システムの一例を示す高レベルブロック図であ
る。

【図２】（従来の技術）ＳＴＤモデルの実現例を、図１
に示すシステムの一部とともに示す高レベルブロック図
である。

【図３】（従来の技術）図１および図２に示すシステム
と連係して用いられる、トランスポート・パケットスト
リーム用のフォーマットの一例を、各フィールド指定を
も含めて示す図である。

【図４】(a)は、スタッフィングバイトを広くプライベ
ートスタッフデータで置換するために本発明により実行
される各ステップの実施例を示す高レベルフローチャー
ト図である。(b)は、アダプテーション・フィールドに
おけるスタッフィングバイトをプライベートスタッフデ
ータで置換するために本発明により実行される各ステッ
プの実施例を示す高レベルフローチャート図である。

【図５】パケットペイロードにおけるスタッフィングバ
イトをプライベートスタッフデータで置換するために本
発明により実行される各ステップの実施例を示すフロー
チャート図である。

【図６】図５に示す実施例において好適に用いられるス
タートコード処理技術の実施例を示すフローチャート図
である。

【図７】図５に示す実施例において好適に用いられるス
タッフィングバイトサーチ技術の実施例を示すフローチ
ャート図である。

【図８】(a)〜(c)は、図５〜図７に示されている技術に
よりおこなわれるスタッフィングバイト置換動作の３つ
の実施例をそれぞれ示す図である。

【図９】本発明において好適に用いられるエンコーダの
実施例を示す高レベル機能ブロック図である。

Claims (18)

【特許請求の範囲】
1. 【請求項１】 データストリームを満たすためにスタッ
   フィングバイトを用い、データパケットのかたちの固定
   ビットレートビデオデータと、可変ビットレートビデオ
   データと、を含んでいるシステムにおいて、該スタッフ
   ィングバイトの代わりにプライベートスタッフデータを
   用いるシステムであって、 データパケットの中でスタッフィングバイトが用いられ
   ているかどうかの表示を含めて該データパケットを解析
   し、かつ所定の基準にしたがって該スタッフィングバイ
   トを除去することが該データパケットについて適格であ
   るかどうかを判定する手段と、 該検査手段に応答して、該スタッフィングバイトを該デ
   ータパケットから除去し、かつ所定のプライベートスタ
   ッフデータを該データパケットに加えるリマルチプレク
   シング手段と、を備えているシステム。
2. 【請求項２】 前記データパケットがヘッダ部分とペイ
   ロード部分とを含んでおり、かつ前記スタッフィングバ
   イトが該ヘッダ部分においてそのロケーションを検出さ
   れる、請求項１に記載のシステム。
3. 【請求項３】 前記データパケットがヘッダ部分とペイ
   ロード部分とを含んでおり、かつ前記スタッフィングバ
   イトが該ペイロード部分においてそのロケーションを検
   出される、請求項１に記載のシステム。
4. 【請求項４】 前記データパケットがヘッダ部分とペイ
   ロード部分とを含んでおり、該データパケットは、プラ
   イベートデータが該データパケットの該ヘッダ部分によ
   って運ばれているかどうかに関する表示をさらに含んで
   おり、かつ、前記所定の基準が、該データパケットの該
   ヘッダ部分によって運ばれているプライベートデータが
   ないことである、請求項１に記載のシステム。
5. 【請求項５】 前記データパケットがヘッダ部分とペイ
   ロード部分とを含んでおり、前記プライベートスタッフ
   データが該ヘッダ部分におけるアダプテーション・フィ
   ールド内に挿入される、請求項１に記載のシステム。
6. 【請求項６】 データストリームを満たすためにスタッ
   フィングバイトを用い、データパケットのかたちの固定
   ビットレートビデオデータと、可変ビットレートビデオ
   データと、を含んでいるシステムにおいて、該スタッフ
   ィングバイトをデータパケットから除去することによっ
   て追加帯域を生成し、かつ該追加帯域を用いてプライベ
   ートスタッフデータを伝送する方法であって、 データパケットの中でスタッフィングバイトが用いられ
   ているかどうかの表示を含めて該データパケットを解析
   し、かつ所定の基準に従って該スタッフィングバイトを
   除去することが該データパケットについて適格であるか
   どうかを判定するステップと、該解析ステップに応答し
   て、該スタッフィングバイトを該データパケットから除
   去することによって追加伝送帯域を生成するステップ
   と、 所定のプライベートスタッフデータを該データパケット
   に加えることによって、該追加伝送帯域を用いるステッ
   プと、を含んでいる方法。
7. 【請求項７】 前記データパケットがヘッダ部分とペイ
   ロード部分とを含んでおり、かつ前記スタッフィングバ
   イトが該ヘッダ部分から除去される、請求項６に記載の
   方法。
8. 【請求項８】 前記データパケットがヘッダ部分とペイ
   ロード部分とを含んでおり、かつ前記スタッフィングバ
   イトが該ペイロード部分から除去される、請求項６に記
   載の方法。
9. 【請求項９】 前記データパケットがヘッダ部分とペイ
   ロード部分とを含んでおり、該データパケットは、プラ
   イベートデータが該データパケットの該ヘッダ部分によ
   って運ばれているかどうかに関する表示をさらに含んで
   おり、かつ、前記所定の基準が、該データパケットの該
   ヘッダ部分によって運ばれているプライベートデータが
   ないことである、請求項６に記載の方法。
10. 【請求項１０】 前記データパケットが、アダプテーシ
    ョン・フィールドを有するヘッダ部分と、ペイロード部
    分とを含んでおり、前記プライベートスタッフデータが
    該アダプテーション・フィールド中に挿入されることに
    よって加えられる、請求項６に記載の方法。
11. 【請求項１１】 データストリームを満たすためにスタ
    ッフィングバイトを用い、データパケットのかたちの固
    定ビットレートビデオデータと、可変ビットレートビデ
    オデータと、を含んでいるシステムにおいて、該スタッ
    フィングバイトの代わりにプライベートスタッフデータ
    を用いるシステムであって、 データパケットの中でスタッフィングバイトが用いられ
    ているかどうかの表示を含めて該データパケットを解析
    する手段と、 該検査手段に応答して、該スタッフィングバイトを該デ
    ータパケットから除去し、かつ所定のプライベートスタ
    ッフデータを該データパケットに加えるリマルチプレク
    シング手段と、を備えているシステム。
12. 【請求項１２】 前記データパケットがヘッダ部分とペ
    イロード部分とを含んでおり、かつ前記スタッフィング
    バイトが該ヘッダ部分においてそのロケーションを検出
    される、請求項１１に記載のシステム。
13. 【請求項１３】 前記データパケットがヘッダ部分とペ
    イロード部分とを含んでおり、かつ前記スタッフィング
    バイトが該ペイロード部分においてそのロケーションを
    検出される、請求項１１に記載のシステム。
14. 【請求項１４】 前記データパケットがヘッダ部分とペ
    イロード部分とを含んでおり、前記プライベートスタッ
    フデータが該ヘッダ部分内のアダプテーション・フィー
    ルド中に挿入される、請求項１に記載のシステム。
15. 【請求項１５】 データストリームを満たすためにスタ
    ッフィングバイトを用い、データパケットのかたちの固
    定ビットレートビデオデータと、可変ビットレートビデ
    オデータと、を含んでいるシステムにおいて、該スタッ
    フィングバイトをデータパケットから除去することによ
    って追加帯域を生成し、かつ該追加帯域を用いてプライ
    ベートスタッフデータを伝送する方法であって、 データパケットの中でスタッフィングバイトが用いられ
    ているかどうかの表示を含めて該データパケットを解析
    するステップと、 該解析ステップに応答して、該スタッフィングバイトを
    該データパケットから除去することによって追加伝送帯
    域を生成するステップと、 所定のプライベートスタッフデータを該データパケット
    に加えることによって、該追加伝送帯域を用いるステッ
    プと、を含んでいる方法。
16. 【請求項１６】 前記データパケットがヘッダ部分とペ
    イロード部分とを含んでおり、かつ前記スタッフィング
    バイトが該ヘッダ部分から除去される、請求項１５に記
    載の方法。
17. 【請求項１７】 前記データパケットがヘッダ部分とペ
    イロード部分とを含んでおり、かつ前記スタッフィング
    バイトが該ペイロード部分から除去される、請求項１５
    に記載の方法。
18. 【請求項１８】 前記データパケットが、アダプテーシ
    ョン・フィールドを有するヘッダ部分と、ペイロード部
    分とを含んでおり、前記プライベートスタッフデータが
    該アダプテーション・フィールド中に挿入されることに
    よって加えられる、請求項１５に記載の方法。