JP2002542549A

JP2002542549A - コンピュータにおける高速ストリーミング媒体の処理装置及び方法

Info

Publication number: JP2002542549A
Application number: JP2000613199A
Authority: JP
Inventors: ロバートエムウォルフ; ランディーランガー; ウルリッヒジグモント
Original assignee: ラヴィセントテクノロジーズインコーポレイテッド
Priority date: 1999-04-01
Filing date: 2000-03-31
Publication date: 2002-12-10
Also published as: WO2000064186A2; WO2000064186A3; GB0123396D0; EP1276331A3; AU4189700A; GB2363279A; GB2363279B; EP1166566A2; EP1276331A2

Abstract

(57)【要約】コンピュータシステムにおける高帯域ストリーミングデータを最適に処理する方法及び装置により、演算動作が最小限に抑えられ最大の性能が発揮される。この性能改善は、メモリコピー量を最小限にするとともに発生するオブジェクトの割振り及び割振り解除の回数を最小限に抑えることによって達成される。ワードによる検索が、ＭＰＥＧ−２ストリーム上で実行される。デコード及びレンダリングの過程で、ＭＰＥＧ−２データストリームと平行に二次データストリームを生成するために、事前パーサが使用される。平行二次データストリームは、効率的で使い易い形態でＭＰＥＧ−２データストリームの構造を記述し、様々なデコード段階での構文解析タスクの重複の排除を促進する。ＭＰＥＧ−２補間ケースＤについての２段階動き予測は、補正されない場合には可視的アーチファクトを引き起こすことになる。

Description

【発明の詳細な説明】

【０００１】

【技術分野】

本発明は、データ処理に係り、特に、コンピュータにおける高速ストリーミン
グデータの処理・操作に関する。また、本発明は、例えば、ストリーミングデー
タにおける特定パターンを探し出すためのマルチバイト検索に係り、特に、ＭＰ
ＥＧ−２データストリームやそれと全く同じスタートコード構成を使用したスト
リームにおいてスタートコード・プレフィックスを探し出すためにリアルタイム
のデータストリームを走査する高速メカニズムに関する。これらの汎用アルゴリ
ズムは、どのようなバイト長から成るパターンの検索にも使用でき、特に、検索
パターン長が奇数バイトの場合に有用である。更に、本発明は、デジタルテレビ
、高密度ＣＤ−ＲＯＭ、及びテレビ放送のためのスタジオ用高品質ビデオのコー
ド化に使用されるようなデータ圧縮に関し、特に、事前パーサ（構文解析ツール
）によってＭＰＥＧ−２データストリーム構造の情報を探し出し、以降の非圧縮
化及び再現の全段階における冗漫な構文解析ジョブを実質的に排除するようにし
たＭＰＥＧ−２形式のデータストリーム非圧縮化に関する。加えて、本発明は、
コンピュータ及びデジタルデータ圧縮に関し、特に、ＭＰＥＧ−２形式の非圧縮
化において累積される可能性のある丸め誤差の防止に関する。

【０００２】

【従来の技術】

ストリーミングデータの形での情報伝送の重要性は益々増大している。ストリ
ーミングデータとは、通常、ＭＰＥＧ−２のようなフォーマットを使用した連続
的で途切れのないストリームとしてリアルタイムに伝送されるデータのことであ
る。ＭＰＥＧ−２は、これまでＤＶＤのような静的媒体において使用されており
、一般社会では周知のものであるが、ＤＳＳ、ＤＶＤ、Ｐｒｉｍｅｓｔａｒ、Ｄ
ｉｓｈｎｅｔｗｏｒｋ等のデジタル衛星放送のようなストリーミング（リアルタ
イム）アプリケーションに使用されていることは余り知られていない。

【０００３】このような環境において、上記データは、様々な伝送速度で伝送されているが
、このデータストリーミングによって、データを受信する装置に大きな問題が生
じる。例えば、データがストリームの状態にある、つまりデータ伝送でのエラー
が検出された場合に再読出しできる媒体上に固定されていない状態−エーテルに
気化したような状態にあるために、ＤＶＤの場合のように後戻りしたりサンプリ
ングし直したりすることはできない。このように、データブロックが一時的なデ
ータストリームの一部である場合、そのデータブロックの伝送における不具合を
回復することは極めて困難である。

【０００４】従前のソフトウェア技術手法では、ストリーミングデータ処理の問題を解決す
るために、頻繁にメモリをコピーしたり、ソフトウェアオブジェクトを頻繁に割
振ったり割振り解除したり、ハードウェア組込みの自由度のないメモリを使用し
たり、或いはそれらを組合せることが行われてきた。これら手法を行うには、コ
ンピュータ内部の利用できる演算時間や帯域幅の大部分を使用する必要がある。
ストリーミングデータでない場合には、擬似バッチモードでジョブを処理できる
ので、通常、演算時間は重要な要素ではなく問題にはならない。しかし、音響、
ビデオ及びデータの形式での衛星データのようなストリーミング媒体の場合には
、入来データ速度を制御する方法は存在しない。そのため、データ処理をうまく
行わないと入力データが超過した状態となり、その結果として入力データの一部
が失われることになる。

【０００５】コンピュータは、最悪の条件下でもデータストリームを処理する能力を持つ必
要がある。しかし、コンピュータ内で大量のメモリコピーや割振り・割振り解除
を行う場合、このシステムには、他の入来要求を処理したり通常のオペレーショ
ンを行ったりするために使用できるリソースがほとんどない状態となる。これに
より、多量のデータをロードした場合には、多くの行うべきことが放置されるこ
とになり、エラーが生じたりデータが失われたりすることになる。

【０００６】ストリーミングデータ処理の問題点を解消する手法として、メモリ管理を行う
ための再利用型メモリバッファを用いたＳｍｅｒｔＨｅａｐ（登録商標）等のメ
モリマネージャがある。しかしながら、これら手法は、多量のストリーミング媒
体に適用することはできない。また、ストリームライン制御やデューティ設計の
ための多重スレッドを使用することも不可能である。更に、これらの公知技術は
、ストリーミング媒体の処理に関連する問題解決を具体的に狙ったものではない
。従って、これら手法は、ストリーミング用に具体化されたものではなく、上記
したストリーミングにおける問題解決に対して具体的に焦点が絞られたものでは
ないため次善策的なものであると考えられる。このように、コンピュータシステムにおいてストリーミングデータを処理する
ための効率的で信頼性のある方法及び装置を提供することは有益である。

【０００７】ＭＰＥＧ−２標準規格は、音響・ビデオ情報のフォーマット化や伝送のために
使用されることが多い（ＭＰＥＧ−２標準規格に関する情報については、ｈｔｔ
ｐ：//ｗｗｗ．ｍｐｅｇ．ｏｒｇを参照されたい）。ＭＰＥＧ−２標準規格の普
及によって、ＭＰＥＧ−２データのリアルタイム（即ち、非流量制御）ストリー
ムを走査してスタートコード・プレフィックス（即ち、データストリームを構成
する構造要素又はパケットを区画するバイトパターン）を探し出すための高速メ
カニズムの導入が必要となってきた。このメカニズムが必要とされる理由は、上
記ストリームのデータが処理システムに対してリアルタイムに伝えられるためで
ある。従って、ストリームの各要素ユニットは、リアルタイムに確実に識別され
、ユニット毎にその各成分が構文解析されるとともに入来データ速度に応じた速
度で処理される必要がある。このスタートコード・プレフィックスの走査によっ
て、通常、ＭＰＥＧ−２処理プログラムにおけるＣＰＵ使用の相当な部分を占有
され、時にはＣＰＵ使用の５０％を超える占有率となる。

【０００８】ＭＰＥＧ−２標準規格（ＩＳＯ／ＩＥＣ１３８１８−１：１９９６（Ｅ）、
表２−１７及びＩＳＯ／ＩＥＣ１３８１８−１：１９９６（Ｅ）、表２−２、
２−６、２−２５、２−２７及び２−２８参照）において、スタートコード・プ
レフィックスは、以下の付帯条件を持つ、８ビット整合のバイトパターン０×０
００×０００×０１で表される。・０×０００×０００×０１パターンに続く３バイトが全て０×００である
場合、このパターンは有効なスタートコードではなく、よって、スキャナに受け
入れられることがないようにする。・音響のパケット化要素ストリーム（ＰＥＳ）に関しては、０×０００×００
０×０１パターンに続くバイトの唯一の有効値は、０×Ｃ０乃至０×ＤＦを含
む範囲にある。ビデオに関しては、その逆となる。即ち、ビデオストリームにお
ける０×０００×０００×０１パターンに続くバイトが０×Ｃ０乃至０×Ｄ
Ｆを含む範囲にある場合、そのパターンは有効なスタートコードとならず、それ
をスキャナが受け入れないようにする。・現状のＭＰＥＧ−２を実施しているものの一部は、それらの音響ＰＥＳストリ
ームにＭＰＥＧ−１を使用しており、ＭＰＥＧ−１音響ストリームにその圧縮さ
れたペイロードの一部として０×０００×０００×０１を含ませることが違
法でないために、表面的に有効なスタートコードをペイロードに表示することが
可能である。スタートコードパターンに続く次の数バイトを調べた上で、本当の
スタートコードを確認することは可能であるが、ＭＰＥＧ−１に適合した音響チ
ャンネルについての走査動作の間、音響コードの同期化を確実に保証するアルゴ
リズムは存在しない。これは、ＭＰＥＧ−２適合のビデオ・音響チャンネルには
ない問題である。実際、ＭＰＥＧ−２仕様には、このようなことが絶対に起こら
ないことが保証されている。

【０００９】ＭＰＥＧ−２スタートコードの走査に関する問題に対処するために本技術分野
で使用されてきた以下の２つの手法がある。・入来バイトの順次読取りにより、０×０００×０００×０１パターンを探
す手法。この手法は、プロセッサに集中的な負担をかける。・ＭＰＥＧ−２データをバッファに読込んだ後に、３バイトを１単位として調べ
て、その各々が０×００又は０×０１であるか否かが確認される。いずれかの値
が確認されると、隣接するバイトを調べて、それらが０×０００×０００×
０１パターンを構成するか否かを確認する。このバイトを広範囲に検索する手法
も、上記した第一の手法に比較すると相当低いレベルではあるが、プロセッサに
集中的な負担がかかる。

【００１０】上記手法のいずれも、相当なプロセッサ稼動時間が、目標とするバイト値を探
すだけでなく更に隣接するバイトを調べて完全なスタートコードが発見されたと
判断するために費やされるために、特に有効なものとは言えない。上記した第一
の手法では、Ｉｎｔｅｌ８０×８６／Ｐｅｎｔｉｕｍ（登録商標）シリーズ等の
所謂ストリング命令を有するプロセッサ用のアセンブリ言語にコード化し、性能
を高めることは可能である。しかし、上記２つの手法がアセンブリ言語にコード化された場合であっても、
それら手法よりも更に効率的なアルゴリズムを提供することは有益であると考え
られる。

【００１１】デジタル映画は勿論のことグラフィックも、通常のコンピュータ記憶装置や通
信帯域幅にとって厄介なものである。アップロード即ち送信するデータを圧縮し
、それをダウンロード即ち受信する際に元のフォーマットに非圧縮化することに
よって一部の問題は解消できる。「ＭｏｔｉｏｎＰｉｃｔｕｒｅＥｘｐｒｅ
ｓｓＧｒｏｕｐ」の頭文字であるＭＰＥＧは、動画及び音響データの圧縮及び
非圧縮化の基準である国際工業標準規格として進化してきた。毎秒３０フレーム
でのフルスクリーンのビデオ再生及びＣＤと同等の品質を持つ音響とすることが
本来の目標であった。

【００１２】ＭＰＥＧ−１は、パーソナルコンピュータのビデオや音響の再生性能に革命を
もたらし、Ｍｉｃｒｏｓｏｆｔ社のＷｉｎｄｏｗｓ（登録商標）オペレーティン
グシステムの標準機能となった。これによりユーザはＭＰＥＧの可能性を初めて
体験することになり、より高度な多重媒体に向けた基礎を築いた。ＭＰＥＧ−２
標準規格の出現により、音響及び視覚体験がパーソナルコンピュータを越えて日
常の家庭用品にまで拡大することが約束された。パーソナルコンピュータの「頭
脳」と民生機器の娯楽機能を組み合すことによって、全く新しいタイプの娯楽用
パーソナルコンピュータ製品の可能性が生じる。

【００１３】ＭＰＥＧ−１技術により、毎秒３０フレームのテレビのようなビデオ及びＣＤ
品質の音響が生み出される。ＭＰＥＧ−１は、ＶＨＳ品質のビデオが許容範囲に
ある多くの製造者間に浸透しており、教育訓練プログラム、対話型の百科事典、
学習機能やプレーイング機能を高めたアクションゲーム等に採用されている。極
東地域においては、ＭＰＥＧ−１は、ビデオＣＤやカラオケ機器におけるリッチ
ビデオ・音響再生装置の火付け役となっている。ＭＰＥＧ−１は、企業のイント
ラネット、インターネットの相互接続性を利用して各従業員と情報とを結び付け
る新しい個人ネットワーク上でも使用されるようになった。ＭＰＥＧ−１は、イ
ントラネットを利用した訓練アプリケーションにおいて、これらネットワークの
帯域幅の制約を超越してシームレスに該アプリケーションのクリップを伝送する
ように、この訓練アプリケーションを十分補完する。ＭＰＥＧ−１は、ビデオや
音響の再生を許容可能なものとし、標準ＣＤプレーヤーと協働し、更にＭｉｃｒ
ｉｓｏｆｔＷｉｎｄｏｗｓ（登録商標）を通じて良く知られているパーソナル
コンピュータインターフェースを備えているので、現代の高出力化されたＰＣで
は、ソフトウェアのみのＭＰＥＧ−１を利用して許容可能な品質を実現すること
ができる。

【００１４】ＭＰＥＧ−２技術によれば、標準テレビ表示装置より鮮明な解像度を得ること
ができるので、ＭＰＥＧ−１より４倍大きなビデオ画像を作り出すことができる
。ＭＰＥＧ−２は、家庭用娯楽機器愛好家からの要望が強い２つの要素である映
画館並みの品質を持つビデオとＡＣ３・サラウンド・サウンドとを含んでいる。
デジタル多用途ディスク（ＤＶＤ）製品の品質レベルを考慮すると、ＭＰＥＧ−
２は、ＭＰＥＧ−１より高レベルの性能を実現する。そのため、ＭＰＥＧ−２技
術は、多重媒体用の高級パーソナルコンピュータや民生機器のための標準として
位置付けられる。ＤＶＤ/ＭＰＥＧ−２の機能性を使用することによって、平均
的パーソナルコンピュータは、本格機能を備えた娯楽ホームシアターに変身する
。

【００１５】ＭＰＥＧ委員会は、コンパクトディスクのビデオ及び音響の標準化を当面の目
標として、１９８８年後半に開始された。１９９２年までに、参加者は、ビデオ
、音響、システムに関する２００人を越える国際的な技術専門家を含むまでに拡
大した。民生ビデオテープ（ＶＨＳ）の知覚品質に近似したコード化ビット言語
である「シンタックス（ｓｙｎｔａｘ）」が生み出された。シンタックスは、当初の第一目標としたアプリケーションよりも大幅に高いビ
ット速度とサンプル速度に適用するに十分な汎用性のあることが実証されたため
、インターレース化された放送用ビデオの効率的表示のためにシンタックスを定
義する第二段階（ＭＰＥＧ−２）が、委員会内で開始された。これは、ＭＰＥＧ
−１によってコード化された順次（非インターレース化）信号よりも更に挑戦的
なものである。ＭＰＥＧ−１音響は、２つの音チャンネルを直接表現することのみが可能であ
った。これに対し、ＭＰＥＧ−２では、マルチチャンネルの離散的サラウンド・
サウンド音響を相互関連させる基本構想が導入されている。

【００１６】ＭＰＥＧビデオ用のシンタックスでは、数個のトークン信号を使用して６４サ
ンプルの全ブロックが表現される。また、ＭＰＥＧには、コード化ビットを集約
的表現から元の原フォーマットである画像シーケンスにマップ化する復号化即ち
再構成プロセスが記述されている。例えば、コード化されたビットストリームの
フラグは、後続のビットが「ＤＣＴ］アルゴリズムを使って複合化されるべきも
のか、或いは予測アルゴリズムを使って複合化されるべきものかを示す。復号化
プロセスのアルゴリズムは、ＭＰＥＧによって定義されている。シンタックスで
は、空間的冗長性、時間的冗長性、等速運動、空間的マスキング等の共通したビ
デオ特性を利用することができる。

【００１７】ＭＰＥＧによって１００：１を超える圧縮率で高品質ビデオを実現できるよう
にしてほしいという要求は多い。しかし、このように高い圧縮率とすると、ソー
スビデオにオーバーサンプリング要素が含まれるようになる場合が多い。ＭＰＥ
Ｇ画像シーケンスのコード化サンプル速度は、通常、有効ビット速度の３０倍の
速度より大きくない。サブサンプリングの事前圧縮では、非ＭＰＥＧ方式のビデ
オコード化方法を含む全てのビデオコード化方法に対して、余りにも高い圧縮率
となる。

【００１８】ＭＰＥＧ−１及びＭＰＥＧ−２ビデオ用シンタックスは、広範囲のビット速度
及びサンプル速度にわたって有用である。ＭＰＥＧ−１は、毎秒３０のＳＩＦ画
像（３５２画素×２４０列）及び１．８４メガビット／秒未満のビット速度で、
例えば、コンパクトディスクビデオの場合のような「条件付きパラメータビット
ストリーム」（白書）を操作する。４０９５×４０９５程度の画像寸法で最高１
００Ｍｂｉｔ／秒のビット速度にコード化することは可能である。しかし、ＭＰ
ＥＧ−２では、最も一般的な組み合せは、３５２画素×２４０列×３０フレーム
／秒の「低レベル」ＳＩＦ及び７２０画素／列×４８０列×３０フレーム／秒の
「主要レベル」ＣＣＩＲ６０１のような各レベルに設定されてきた。動き補償に
より、複数のマイクロブロックが前の画像から移動される。マイクロブロックの
移動目標位置は、以前に再構成した画像からの任意の１６×１６画素（又はＭＰ
ＥＧ−２における１６×８）領域に基づいて設定される。

【００１９】前の画像内におけるマイクロブロック移動目標の位置を限定する境界は、画像
のエッジ以外にはない。表示画像サイズは、コード化画像サイズと同一である。
ＭＰＥＧでは、表示画像サイズ及びフレーム率は、ビットストリームにコード化
されたサイズ（解像度）及びフレーム率と異なるようにすることができる。例え
ば、ソース画像シーケンスにおける通常の画像パターンを落とした（大量に取り
除いた）後に、コード化に先立ち各画像自身をフィルターにかけるとともにサブ
サンプリングすることができる。再構成の際、ソース画像のサイズ及びフレーム
率に対して、画像を補間するとともにアップサンプルすることも可能である。実
際、３つの基本フェーズである、ソース率、コード化率、及び表示率をいくつか
のパラメータによって異なるものとすることもできる。ＭＰＥＧシンタックスに
よれば、シーケンスのヘッダーによってコード化率と表示率とを個別に記述する
ことかできるが、ソース率は、エンコーダによってのみに識別される。

【００２０】全ての画像コード化形式（Ｉ、Ｐ、Ｂ）は、同一のマイクロブロック形式から
成る。Ｉ−画像内の全てのマイクロブロックは、基本ＪＰＥＧ画像のようなコー
ド化されたイントラ（Ｉｎｔｒａ）でなくてはならない。しかし、Ｐ−画像内の
マイクロブロックは、イントラとしてコード化しても非イントラとしてコード化
してもよく、一時的に前の再構成画像から予測することも可能である。Ｂ−画像内のマイクロブロックは、イントラ、前方予測によるもの、後方予測
によるもの、或いは、前方及び後方の両方の（補間）予測によるもののいずれか
を単独で選択することができる。マイクロブロックのヘッダーには、マイクロブ
ロックタイプと呼ばれる、マイクロブロックのモードをスイッチのようにオンオ
フ的に反転できる要素が含まれる。マイクロブロックタイプは、ビデオシンタッ
クスの強力な部分である。画像形式（Ｉ、Ｐ、Ｂ）は、意味論の範囲を拡げるこ
とによって各マイクロブロックモードを有効なものとする。この構成要素として
の各スイッチは、（１）イントラ又は非イントラスイッチ、（２）前方一時予測
（動き−前方）スイッチ、（３）後方一時予測（動き−後方）スイッチ、（「補
間」予測とされた組み合わせにおける（２）＋（３）前方及び後方の両予測スイ
ッチ）、（４）条件付き補充（マイクロブロック−パターン）スイッチ、（５）
量子化における適応（マイクロブロック−量子化器）スイッチ、及び（６）動き
補償なしの一時的予測スイッチである。最初から５つのスイッチは、大部分が直
交する状態とされる。６番目のスイッチは、Ｐ−画像における第一及び第二スイ
ッチに基づくものであるが、Ｂ−画像には存在しない。一部のスイッチは、他の
スイッチが存在する場合には、非適用とされる。例えば、イントラのマイクロブ
ロックにおいては、本質的に６つの全てのブロックがＤＣＴデータを含むため、
マイクロブロック−パターン又は他の一時的予測スイッチのいずれも信号を出す
必要がない。同様に、非イントラのマイクロブロックにおいて、コード化された
予測エラー情報がない場合には、マイクロブロック−量子化信号は、意味のない
ものとなる。シーケンス構造は、特定のＩ、Ｐ、Ｂフレームパターンに対し固定
される。シーケンスは、Ｉ−画像、Ｐ−画像、及びＢ−画像の大部分のパターン
から構成することができる。例えば、ＩＢＢＰＢＢＰＢＢＰＢＢＰＢＢのような
固定パターンとするのは、業界の慣用手段である。しかし、更に進化したエンコ
ーダでは、局部的シーケンス特性に応じて３つの画像形式の配列を最適化するよ
うにしている。各画像形式には、時間的マスキング、閉鎖、動き活量等の特定画
像の統計値と結び付けられる場合のペナルティが設定されている。

【００２１】これまで、ＭＰＥＧ−２データストリーム処理は、特定用途向け集積回路（Ａ
ＳＩＣ）を使用し、主としてハードウェアで行われていた。比較的最近、十分な
出力を持つ費用効果の高いマイクロコンピュータが導入されることによって、コ
スト低減の解決策としてソフトウェアを使用してこのＭＰＥＧ−２処理を行うこ
とへの関心が高まった。このような目的へのソフトウェア使用の現時点までの寿
命は比較的短かったため、従来技術が多量に蓄積される余裕はなかった。

【００２２】デジタル画像には、それを記憶するための大きな記憶スペースとそれを伝送す
るための広い帯域幅が必要とされる。縦横４８０×６４０画素で、画素当り２４
ビット［画素当り３バイト（８×３ビット）］のフルカラー分解能を有する単一
の比較的小型の画像は、メガバイトのデータに相当する。縦横１０２４×７６８
画素の分解能で、２４ビットカラー画面は、それを表示するために２．３メガバ
イトのメモリを必要とする。インチ（２．５４ｃｍ）当り３００ドットで、縦横
８．５インチ×１１インチのページの２４ビットカラー画像は、それを表示する
ために２５メガバイト程度を必要とする。

【００２３】高品質民生機器については、少なくとも毎秒３０フレームの割合で画像が生じ
る必要があるというのが一般的になっているため、ビデオ画像は、更にデータ集
中的なものとなる。高精細度テレビ（ＨＤＴＶ）に関する最新計画では、フレー
ム当り縦横１９２０×１０８０画素又はそれ以上が要求され、これは、毎秒約１
５億ビットのデータ伝送速度に相当する。この帯域幅の要件は、「Ｕ」及び「Ｖ
」クロミナンス成分について２：１のインターリービング処理及び４：１のデシ
メーション処理を行う場合には多少緩和できるが、依然として毎秒３．７３億ビ
ットが必要とされる。

【００２４】ハフマン・コーディング、ランレングス・コーディング、Ｌｅｍｐｅｌ−Ｚｉ
ｖ−Ｗｅｌｃｈアルゴリズム等の圧縮デジタル画像やビデオ情報に関する従来の
損失防止技術は、この要求を満足するには程遠いものである。そのため、いくら
かの情報損失が生じる可能性のある圧縮技術は、離散コサイン変換技術、適応的
離散コサイン変換技術、及びウェーブレット変換技術を含む形で考案された。ウ
ェーブレットの技術は、ＤＥＶｏｒｅ、Ｊａｗｅｒｔｈ及びＬｕｃｉｅｒによる
「ＩｍａｇｅＣｏｍｐｒｅｓｓｉｏｎＴｈｒｏｕｇｈＷａｖｅｌｅｔＴ
ｒａｎｓｆｏｒｍＣｏｒｄｉｎｇ」ＩＥＥＥＴｒａｎｓａｃｔｉｏｎｓｏ
ｎＩｎｆｏｒｍａｔｉｏｎＴｈｅｏｒｙ、Ｖｏｌ．３８、Ｎｏ．２、ｐｐ．
７１９−７４６（１９９２）、及びＡｎｔｏｎｉｎｉ、Ｂａｒｌａｕｄ、Ｍａｔ
ｈｉｅｕ及びＤａｕｂｅｃｈｉｅｓによる「ＩｍａｇｅＣｏｒｄｉｎｇＵｓ
ｉｎｇＷａｖｅｌｅｔＴｒａｎｓｆｏｒｍ」ＩＥＥＥＴｒａｎｓａｃｔｉ
ｏｎｓｏｎＩｍａｇｅＰｒｏｃｅｓｓｉｎｇ、Ｖｏｌ．１、Ｎｏ．２、ｐ
ｐ．２０５−２２０（１９９２）に論じられている。

【００２５】ジェイペグ（ＪＰＥＧ−ＪｏｉｎｔＰｈｏｔｏｇｒａｐｈｉｃＥｘｐｅｒ
ｔｓＧｒｏｕｐ）は、離散コサイン変換を利用したアルゴリズムを含むＪＰＥ
Ｇ規格として知られる静止画像圧縮に関する標準規格を普及させてきた。ＪＰＥ
Ｇ標準規格は、以下の参考文献を含めた多くの刊行物に記載されている。Ｗａｌ
ｌａｎｃｅによる「ＴｈｅＪＰＥＧＳｔｉｌｌＰｉｃｔｕｒｅＣｏｍｐ
ｒｅｓｓｉｏｎＳｔａｍｄａｒｄ」ＩＥＥＥＴｒａｎｓａｃｔｉｏｎｓｏ
ｎＣｏｎｓｕｍｅｒＥｌｅｃｔｒｏｎｉｃａ、Ｖｏｌ．３８、Ｎｏ．１、ｐ
ｐ．ｘｖｉｉｉ−ｘｘｘｉｖ（１９９２）、Ｐｕｒｃｅｌｌによる「ＴｈｅＣ
−ＣｕｂｅＣＬ５５０ＪＰＥＧＩｍａｇｅＣｏｍｐｒｅｓｓｉｏｎＰ
ｒｏｃｅｓｓｏｒ」Ｃ−ＣｕｂｅＭｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．（１
９９２）、及びＣ−ＣｕｂｅＭｉｃｒｏｓｙｓｔｅｍｓ「ＪＰＥＧＡｌｇｏ
ｒｉｔｈｍＯｖｅｒｖｉｅｗ」（１９９２）。

【００２６】ＪＰＥＧアルゴリズムを使用したエンコーダは、線形変換、量子化、ランレン
グス・エンコーディング（ＲＬＥ）、及びハフマン・コーディングという４つの
段階を有する。デコーダは、これらの段階を逆に行い画像を再構成する。線形変
形の段階では、画像が８×８画素ブロックに分割され、ブロック毎に両空間次元
において離散コサイン変換が行われる。画像をブロックに分割する目的は、離散
コサイン変換が著しく非局所的であるという離散コサイン変換アルゴリズムの欠
陥を克服するためである。つまり、画像を小さな領域に制限し各ブロック毎に個
別の変換を行うことによって上記非局所性の問題を克服する目的で、画像が複数
のブロックに分割される。しかし、この妥協策は、高圧縮時においてタイル貼り
の状況（濃淡むら）が生じるという問題がある。

【００２７】量子化段階では画像情報の損失を伴う可能性があるが、この段階は伝送すべき
情報量を減少させる上で必須のものである。各変換成分は、８×８画素の各ブロ
ックにおけるそれらの位置から選定された値を使って量子化される。この段階は
、不必要な小さな値をゼロ又は更に小さな数に減少させるという好都合な副次的
効果を持っている。ランレングス・エンコーディングの段階では、ある値を繰返す回数及びその繰
返す値を識別する要素である複数のゼロのような一連の同じ値がコード化される
。「８つのゼロ」のような単一要素は、例えば多くの８つのゼロを表すスペース
よりも小さなスペースで済む。この段階は、通常量子化段階から得られる多くの
ゼロによって調整される。ハフマン・コーディングは、ランレングス・エンコーディング段階からの各記
号を、その記号が生じる頻度に応じて選定される可変長ビットストリングに変換
する。即ち、頻度の高い記号は、頻度の低い記号よりも短いコードでコード化さ
れる。このコード化は、予め設定されたテーブル又は画像に必要とされるビット
総数が最小となるように具体的に構成されたテーブルのいずれかによって行われ
る。

【００２８】ＪＰＥＧと同様に、エムペグ（ＭＰＥＧ−ＭｏｔｉｏｎＰｉｃｔｕｒｅＥ
ｘｐｅｒｔｓＧｒｏｕｐ）は、画像シーケンスをコード化するための２つの標
準規格を普及させてきた。これら標準規格は、ＭＰＥＧ−１及びＭＰＥＧ−２と
して知られている。ＭＰＥＧアルゴリズムは、フレームからフレームへの比較的
小さな変化という共通した事実を利用している。ＭＰＥＧ標準規格では、完全画
像は、２０フレーム毎に一度だけ圧縮され伝送される。ＪＰＥＧ標準規格と類似
した圧縮技術が、通常、これらの「参照」フレーム及び「イントラ」フレームを
圧縮するために使用される。中間フレームに関しては、予測フレームが計算され
、実際のフレームと予測フレームとの差分のみが圧縮され伝送される。いくつか
のアルゴリズムのいずれも予測フレームの計算に使用でき、このアルゴリズムは
、予測器のアルゴリズムが特定ブロックに対して最適に作用するかどうかを考慮
してブロック毎に選択される。ＭＰＥＧ−１は、国際標準化機構（ＩＳＯ）ＣＤ
１１１７２に詳細に記載されている。

【００２９】このように、ビデオシーケンスの圧縮に関しては、ＭＰＥＧ技術は、参照フレ
ームの圧縮を参照フレーム間に位置する中間フレームの圧縮と独立して扱うもの
である。本発明は、静止画像又は参照フレームの圧縮に関するものではなく、中
間フレームの圧縮に関するものである。

【００３０】上記したデジタル画像を圧縮する技術は、これまでに考案された技術のほんの
一部を示すに過ぎない。しかし、近未来に予測される巨大な静止・ビデオデータ
の記憶及び伝送の要件を満足する圧縮率を実現する公知技術は未だ存在しない。
また、これらの技術は、純粋な圧縮率に関する問題以外の他の問題も伴う。特に
、リアルタイムの高品質ビデオ画像の非圧縮化については、非圧縮化アルゴリズ
ムは、毎秒３０フレームの非圧縮画像を作り出すことができるように十分シンプ
ルなものでなくてはならない。多くの場合、画像を事前に圧縮することができる
ので、圧縮の速度要件は、非圧縮化のための速度要件ほど厳しくない場合が多い
。しかしその場合でも、圧縮時間は、商業的目的を達成する上で妥当なものでな
くてはならない。更に、多くのアプリケーションでは、実況イベントのリアルタ
イム伝送のように、リアルタイムの圧縮や非圧縮が必要とされる。高圧縮率を達
成する公知の画像圧縮・非圧縮技術は、圧縮又は非圧縮のいずれか又は両者にお
いて膨大な計算を必要とするという犠牲を払うしかそれを行う方法がない場合が
多い。

【００３１】ＭＰＥＧ−２ビデオ圧縮標準規格は、ＩＳＯ／ＩＥＣ１３８１８−２「情報
技術−−動画及び関連音響情報の一般コード化：ビデオ」に定義されている。Ｍ
ＰＥＧ−２では、圧縮効率を改善するための時間的局所性を利用するように固定
サイズとされた矩形ブロックの画素素子（「マイクロブロック」）による動き補
償（又は動き補正）が使用される。参照画像内のこれら「マイクロブロック」の
位置は、２分の１の画素境界により与えられるため、画素素子の補間を必要とす
る。この補間は、ＭＰＥＧ−２標準規格に以下のように明記されている。

【表１】

【００３２】ケース−Ｂ、Ｃ及びＤの末尾にある演算子「／／」は、ＭＰＥＧ−２仕様書に
おいて、「最も近い整数に四捨五入する（又は切り上げる）整数除算。特に定め
がない限り、半整数値は、ゼロを避けて四捨五入される（又は切り上げる）。［
−−］」。従って、２又は４が、右側演算数であり、左側演算数がゼロより大き
い又はゼロである場合、演算子「／／」は、ｘ／／２＝（ｘ＋１）＞＞１；ｘ／
／４＝（ｘ＋２）＞＞２によって置き換えることができる。ここで、「＞＞」は
、ビット数で示される右側演算子による左側演算子の２進右方シフトを意味する
。

【００３３】「ａｖｇ（Ｐ₀₀，Ｐ₀₁）：＝（Ｐ₀₀，Ｐ₀₁）／／２＝（Ｐ₀₀，Ｐ₀₁＋１）＞＞
１」は、マイクロプロセッサ上での実行する上で簡単な演算であるため、多くの
市販用マイクロプロセッサは、この演算を組込み命令として含んでいる。例えば
、「ｐａｖｇｕｓｂ」は、ＳＳＥ拡張機能を備えたＩｎｔｅｌプロセッサ及び３
ＤＮｏｗ！拡張機能を備えたＡＭＤプロセッサに含まれている。このような命令
は、上記ケース−Ｂ及びケース−Ｃの計算に非常に有用である。

【００３４】組込み「ｐａｖｇｕｓｂ」命令は、例えば「ａｖｇ（ａｖｇ（Ｐ₀₀，Ｐ₀₁），
ａｖｇ（Ｐ₁₀，Ｐ₁₁））」のようにこれを２回実行することにより、ケース−Ｄ
に用いると大変魅力的である。また、第一段階の加算平均を行う回路を、第二段
階を行うためにもう一度使用することができるので、組込み「ｐａｖｇｕｓｂ」
命令は、純粋にハードウェアでの実施の代替案としても興味深いものである。し
かし、このようにすると、好ましくない可視アーチファクトが生じてしまう。

【００３５】ケース−Ｄを実行するための通常のサブルーチンには、表Ａの左欄に記載され
ているように、２８の命令を実行する必要がある。しかし、「ｐａｖｇｕｓｂ」
が使用される場合には、表Ａの右欄に記載されているように、５つの命令に縮小
することができる。ケースＤに関して即効性のあるこの解決策の魅力は非常に大
きい。

【００３６】

【表２】

【００３７】上記ショートカット的解決策の１つの問題点は、丸め（四捨五入又は切り上げ
）がＭＰＥＧ命令と異なる形で処理されるために、アーチファクトを引き起こす
という点にある。従って、アーチファクトのない状態で実施するため、ショート
カット的解決策は採用できない。４つの画素の特定の組み合せについての丸め誤差は、以下のように算出できる
。ｅｒｒ（Ｐ₀₀，Ｐ₀₁，Ｐ₁₀，Ｐ₁₁）＝（（（（Ｐ₀₀＋Ｐ₀₁＋１）＞＞１）＋（（Ｐ₁₀＋Ｐ₁₁＋１）＞＞１）＋１）＞＞
１）− （（Ｐ₀₀＋Ｐ₀₁＋Ｐ₁₀＋Ｐ₁₁＋２）＞＞２）全体誤差は、各係数の２つの最小有効ビットにのみ影響を受けるので、総平均
誤差は以下のように算出できる。

【００３８】丸め誤差は、第一ジェネレーション補償については１つの最小有効ビット未満
であり問題はない。しかし、ＭＰＥＧ−２標準規格では、マルチジェネレーショ
ン補償が許されている。このシーケンスでは、予測画像を後続の画像の参照画像
として使用できる。予測画像が参照画像として使用される場合には、丸め誤差が
１つの最小有効ビットを超えて加算される可能性があり、この累積された丸め誤
差が、いくつかの補償ジェネレーションよりも大ききなり好ましくない可視アー
チファクトが発生する可能性がある。

【００３９】このような可視アーチファクト又は光学的影響は、「ポンピング」と呼ばれ、
一連の予測画像では明るくなり、次のイントラ画像では普通の明るさに戻るよう
な画像として眼で知覚される。特に、イントラコード画像間の予測画像の数が通
常より多いシーケンスでは、深刻なポンピングが起こる可能性がある。例えば、
フィールド構造のコード化シーケンス又は「双方向の」予測画像を欠く素材では
、ポンピングを被ることになる。

【００４０】（発明の概要）本発明は、コンピュータシステムにおける高帯域ストリーミングデータの最適
処理を可能とする方法及び装置を提供する。このシステムの全体的な目的は、演
算動作を最小限とすることによって、最大の性能を実現することにある。その結
果は、本明細書に記載された発明において、メモリコピー量を最小限とすること
により、更にオブジェクトの割振り及び割振り解除の回数を最小限とすることに
より達成される。高速ストリーミングデータが入力される場合、メモリコピーでは、ＣＰＵ／帯
域幅での集中的な演算を伴う。オブジェクトの割振り及び割振り解除では、シス
テムリソースの集中的な動作を伴い、コンピュータにおける呼出し当りのＣＰＵ
処理量の非常に大きな割合を必要とする。複数の手法の組み合せを用いて、本発
明は、メモリコピー数だけでなくストリーミング媒体データに関する操作過程で
割振りされ割振り解除されるオブジェクト数をも低減する手法を提供する。

【００４１】本発明の好ましい実施形態では、ワードによる検索が行なわれる。この方策に
は、バイトによる検索のクロックサイクル数と同数のクロックサイクルが必要で
あるが、関連するアドレス数は２分の１であるため実行時間は半分に削減される
。スタートコード毎に、第一又は第二バイトがワード境界上にあるので、データ
を２回検索することによって、まず０×０００×００のワードに関して、次に
再度０×０００×０１のワードに関して、データ内の全てのスタートコードを
検出することができる（各々の成功した検索「ヒット」には、検出したコードが
本当にスタートコードであることを確認するために隣接したバイトを調べる必要
があるが、このルールは簡単なもので効率的にコード化できる。）第二検索は、
（マシンがデータキャッシュを１つ持っている場合）マシンのデータキャッシュ
を使って実行されるので、通常、第二検索の待機状態は存在しない。

【００４２】本発明は、上述した２つの手法がアセンブリ言語にコード化されたとしてもこ
れら２手法よりもスタートコード走査時の効率が高いアルゴリズムを提供する。
このアルゴリズムの効率により使用可能となるＣＰＵ時間によって、プロセッサ
は他のタスクを処理することが可能となるので、所定の処理能力を持つマシンで
、より複雑で密度の高い成果を分散して生み出すことができる。例えば、本発明
によれば、画像内に他の画像を埋め込むソフトウェア、視覚的迫力があるがＣＰ
Ｕ集中型のサーノフビデオ機能、見ながら録音、対話式ウェブアクセス、バック
グラウンド電子プログラムガイド（ＥＰＧ）処理、ＨＤＴＶビデオレンダリング
、動き補償ソフトウェア等の機能をより簡単に実行するためにＣＰＵ時間をより
多く使用できるようになる。

【００４３】本発明の事前パーサは、デコード用のＭＰＥＧ−２データストリームと平行す
るように第二データストリームを生成するために使用される。この平行データス
トリームは、該ＭＰＥＧ−２データストリームの構造を効率的で使い易い形態で
記述し、様々なデコード段階における構文解析タスクの重複の排除を促進する。
事前パーサは、ＭＰＥＧ−２データストリーム入力を、都合の良い長さのサンプ
ルに分割する。次に、このサンプルの各々は、第二データストリームにおいて形
式及び長さについて特徴付けられる。この特徴付けは、ＭＰＥＧ−２データスト
リームのデコード及びレンダリングを支援するとともに構文解析の重複を排除す
る。

【００４４】また、本発明は、ＭＰＥＧ−２補間ケース−Ｄに関する２段階動き補償誤差が
補正される方法を含む。改善されたＭＰＥＧ−２デコーダは、論理ゲート、マル
チプレクサ、及び加算器を備える。水平（ｈ₀）及び垂直（ｈ₁）の動きベクトル
成分のいずれもが、１／２画素補間（ケース−Ｄ）を必要とする場合、該マルチ
プレクサは、該加算器に定数−３（マイナス３）を転送し、そうでなければ、定
数ゼロが使用される。この加算器は、２段階予測器によって計算された予測画素
の補正項を含むように、逆離散コサイン変換に入力されるＤＣ係数を変更する。
−０．３５７の補正値は、逆離散コサイン変換時に結果としての６４の空間係数
全てに対し一様に配分される。これにより、統計的には、わずかに明るさを増す
補正項群となる。これは、２段階予測器によって形成されたわずかに暗い予測を
相殺する。出力フレームは、統計的には正しい画像となる。

【００４５】（発明を実施するための最良の形態）上述したように、メモリコピー及び／又はソフトウェアオブジェクトの割振り
・割振り解除を多用するのが、ストリーミングデータ処理の問題を解決する従来
の技術手法であった。図１は、オブジェクト割振りをわずかに使用するとともにこのオブジェクトの
多量のコピーを行なうストリーミング処理システムの構成を示す概要図である。
図１に示されるように、衛星アンテナ１０によって、放送電波信号の形でストリ
ーミングデータが受信される。この信号は、ドライバ１２に送られ、次にメモリ
１４に送られる。入来データは、メモリに割振られコピーされる。このデータは
、メモリから読み出され、システムに使用する必要のあるデータを構文解析し修
正するモジュール１５によって処理される。構文解析・修正段階の結果は、メモ
リ出力領域１６にコピーされ、次にシステムで使用するためにモジュール１７で
デコードされレンダリングされる。データパケットが処理されると、次の入来パ
ケット１８の処理を開始する態勢を取り、処理を繰返す。上記手法では、メモリに集中的な負担が掛かることが分かる。

【００４６】図２は、オブジェクト割振りを多用するとともにこのオブジェクトのわずかな
コピーを行なうストリーミング処理システムの構成を示す概要図である。図２に
示されるように、衛星アンテナ１０によって、放送電波信号の形でストリーミン
グデータが受信される。この信号は、ドライバ１２に送られ、次に入来データの
ローカルコピーを保持するメモリ２４に送られる。このシステムは、入来データ
を割振りして入来データのＩ／Ｏオブジェクトを生成するモジュール２６を備え
ており、次に、このＩ／Ｏオブジェクトは、モジュール２５で構文解析され修正
される。処理が終わると、Ｉ／Ｏオブジェクトは、モジュール２７から出力民生
機器（図示せず）に受け渡される。民生機器は、出力データを使用するとともに
、このオブジェクトが割振り解除され破棄された時点で、Ｉ／Ｏオブジェクトと
の関係が終了したことをシステムに通知する。その後、システムは、次の入来パ
ケット２８の処理を開始する態勢を取り、この時点で処理が繰返される。上記手法では、オブジェクト割振り・割振り解除をかなり行う必要のあること
が分かる。

【００４７】本発明は、コンピュータシステムにおける高帯域ストリーミングデータの最適
処理を可能とする方法及び装置を提供する。このシステムの全体的な目的は、演
算動作を最小限とすることによって、最大の性能を実現することにある。その結
果は、本明細書に記載された発明において、メモリコピー量を最小限とすること
により、更にオブジェクトの割振り及び割振り解除の回数を最小限とすることに
より達成される。

【００４８】図３は、本発明によるコンピュータにおいて高速ストリーミングデータの最適
処理・操作を行なうシステムの構成を示す概要図である。ストリーミングデータ
を処理しながら、メモリコピー回数及びオブジェクトの割振り及び割振り解除の
回数を低減するために本明細書に開示されたシステムに用いた手法・技術には以
下のものが挙げられる。・可能であればいつでも、メモリのコピーではなくメモリ参照オブジェクトを使
用する。本明細書では、このメモリ参照オブジェクトを、データブロックという
。・データブロックに関するリストを含む最高４つの個別の待ち行列又はリストの
使用。これら４つの待ち行列とは、以下のものである。ａ）アイドル待ち行列３０：アイドル待ち行列３０は、現在使用されてい
ないデータブロックオブジェクトのキャッシュを保存するために使用される。ア
イドル待ち行列３０によって、オブジェクトの再利用が促進され、これらのデー
タブロックオブジェクトの割振り及び割振り解除が最小限に抑えられる。ｂ）入力待ち行列３１：入力待ち行列は、入来データブロックの各々が処
理可能な時まで、これら入来データブロックを保持する領域として使用される。ｃ）リンボー待ち行列３２：リンボー待ち行列３２は、出力待ち行列に入
れる前に、更に全体的な処理のために保持する必要のある単一データブロックよ
り大きなローカライズ即ち局所化されたストリーム用に使用される。ｄ）出力待ち行列３３：出力待ち行列３３は、入力待ち行列からリンボー
待ち行列で処理された後に最終的に出力待ち行列に置かれた処理済データブロッ
クを保持する待ち行列である。データブロックが出力待ち行列から取出されてこ
の取出されたデータがデコーダ又は事後処理ユニットに送られる時に、これらデ
ータブロックは、再利用のためにアイドル待ち行列上に戻される。このデータブ
ロックは、この時点では割振り解除されない。・マルチスレッディングによる分割された処理デューティ。３つの個別の処理ス
レッドが、デューティの分離を促進するために使用される。これら３つの処理ス
レッドは以下のものである。ａ）入力スレッド３４：入力スレッド３４は、ストリーム媒体ソースから
入来データを取込み、データブロックをアイドル待ち行列から抽出することによ
ってデータブロックを構成し、入来データに対して参照メモリポインタを割当て
た後、新しいデータブロックを入力待ち行列上に置く。ｂ）処理スレッド３５：処理スレッド３５は、入力待ち行列からデータブ
ロックを取込み、出力のためにデータブロックを用意する必要のある時には、デ
ータを構文解析及び／又は修正することによって該ブロックを処理する。データ
の局所化ストリームに関する必要な全ての情報が、単一データブロック内に完全
に含まれていないと判定される（３６）と、このデータブロックは、局所化スト
リームが完全な形となる（３９）まで、リンボー待ち行列３７、３８に置かれる
。局所化ストリームが完全に処理されると、この完全に処理された局所化ストリ
ームを構成するデータブロックは、出力待ち行列に移される。ｃ）出力スレッド４０：出力スレッド４０は、出力待ち行列からデータブ
ロックを取込む役割を果たし、この取込みデータを下流側処理ユニットに受け渡
す操作を行なうためのモジュール４１を備える。好ましい実施形態では、下流側
処理ユニットは、通常、デジタル音響／ビデオデコーダである。次に、対応する
データブロックは、入来データパケット／ストリームに再利用するために、アイ
ドル待ち行列４２、４３に戻される。

【００４９】これによってオブジェクトの再利用のサイクルが完成されるため、オブジェク
トの割振り及び割振り解除は、ほぼゼロに低減される。データブロックオブジェ
クトが割振りされる唯一のケースは、アイドル待ち行列が空になりアイドル待ち
行列からデータブロック調達の要求があった場合である。また、長時間アイドル
待ち行列上に置かれたデータブロックオブジェクトの数が非常に多くなった場合
にのみ、処理中にデータブロックの割振り解除がされる。これらの未使用データ
ブロックの１つ又はそれ以上の割振り解除は、入来データパケットの周期特性に
起因する頻繁な割振り及び割振り解除を引き起こすヒステリシスを生じないよう
に注意深く扱う必要がある。しかし、これは主に実行上の懸念点であり、本発明
のオペレーションに影響を与えるものではない。

【００５０】本発明の複雑性は、個別で固有のデューティを持つ３つの個別スレッドを使用
することによって最小限に抑えられる。メモリコピーは、入来データをコピーす
るのではなく入来ストリーミングデータパケットを参照することのみによって最
小限に抑えられる。データブロックオブジェクトは、どの位置で入力データが発
見されたか、入力データがどの位大きなものか、出力／処理済データをどこで事
後処理するか、そしてこれらの入力及び出力メモリ参照の各々の状況を表す非常
に小さなオブジェクトである。入力及び／又は出力が、時には実際に割振り及び
／又はコピーされる状態とすることは可能である。これらは、ルールではなく例
外であるが、このようなイベントを追跡する責務がデータブロックオブジェクト
自身にある。データブロックの割振り及び割振り解除は、オブジェクト再利用センターとし
てのアイドル待ち行列の使用によってほとんどゼロに低減される。これは、デー
タが常に入来し処理され出力されるために、ストリーミングデータ処理用の非常
に有力な概念となる。データの移動が一定であるため、この概念の価値は非常に
高いものとなる。

【００５１】図４は、本発明によるコンピュータにおいて高速ストリーミングデータの最適
処理・操作を行なう搬送処理ミニコア５０の構成を示す概要図である。以下の説
明は、ソフトウェアにおいてＩＳＯ１３８１８−１（ｗｗｗ．ｍｐｅｇ．ｏｒｇ
、ｗｗｗ．ａｎｓｉ．ｏｒｇ（ＩＳＯ１３８１８−１））搬送ストリームを扱
うため、及びこれらの搬送ストリームをＭＰＥＧストリームの様々なフォーマッ
トに翻訳するための本発明による現時点で好ましい基本設計手法を示す。

【００５２】本発明のこの実施形態は、衛星及びグローバル放送電波搬送の領域における応
用を想定したものである。ミニコアの主な機能は、ＤＶＢ搬送ストリーム等の入
力としてのＩＳＯ１３８１８−１搬送ストリームパケットを受信したり、ユーザ
の要求時、これらのパケットを他のＭＰＥＧフォーマットに翻訳したりすること
にある。また、ミニコアは、タイムスタンプ及びクロック基準情報を、このクロ
ック情報を出力インターフェース上の音響・ビデオストリームと関連付けるサイ
ドインターフェース上の該情報の使用機器に提供する。

【００５３】この搬送ミニコアは、以下のものをその出力インターフェース上に備える。・ＤＶＢビデオＰＩＤの場合のゼロ長ＰＥＳヘッダー付ＰＥＳ５１。・入力ペイロード長及び６４ｋ／１６ビット長フィールド制限に係りなく全ての
ＰＥＳパケット長フィールドを含むように再構成された長−強化ＰＥＳ５２。・排除される無関係な全てのパケットを含む基本ストリーム５３。・構文解析/認証表示・タイムスタンプ、デコード・タイムスタンプ、搬送クロ
ック基準５４（ＳＣＲ／ＰＣＲ）。・音響ストリーム及びビデオストリームのバイトインデックスに対する刻時情報
の相関関係。これらの出力及び搬送データの入力は、ＭａｉｃｒｏｓｏｆｔＶｉｓｕａｌＣ＋＋「．ｌｉｂ」ファイル、「．ｈ」ヘッダーファイル、及び「．ｄｌｌ」
ファイルとして本発明の好ましい実施形態において設定されている。

【００５４】（実施例）以下の表は、本発明の好ましい実施形態のＣ＋＋実行のソースコードリストで
ある。表Ｂは、データブロック処理のために入力待ち行列から再利用されるとともに
、処理後、これらのデータブロックを出力待ち行列上に置くＣ＋＋−特定バッフ
ァのソースコードリストである。

【００５５】表Ｂ．再利用バッファ処理ソースコードリスト

【表３】

【表４】

【表５】

【表６】

【表７】

【表８】

【表９】

【表１０】

【表１１】

【表１２】

【表１３】

【表１４】

【表１５】

【表１６】

【表１７】

【表１８】

【表１９】

【表２０】

【表２１】

【表２２】

【表２３】

【表２４】

【表２５】

【表２６】

【表２７】

【表２８】

【００５６】表Ｃは、表Ａにおける再利用バッファ処理クラスの定義のＣ＋＋−特定の実行
に関するソースコードリストである。表Ｃ．再利用バッファ処理クラスの定義−ソースコードリスト

【表２９】

【表３０】

【表３１】

【表３２】

【００５７】以下の表Ｄは、本明細書に開示されたシステムに使用されるグローバルオブジ
ェクトの定義のＣ＋＋−特定の実行に関するソースコードリストである。表Ｄ．グローバルオブジェクトの定義−ソースコードリスト

【表３３】

【表３４】

【表３５】

【００５８】以下の表Ｅは、データブロックを監視するとともにデータブロックを追跡する
モジュールのＣ＋＋−特定の実行のソースコードリストである。表Ｅ．データブロック追跡−ソースコードリスト

【表３６】

【表３７】

【表３８】

【表３９】

【表４０】

【表４１】

【表４２】

【表４３】

【表４４】

【表４５】

【００５９】以下の表Ｆは、データブロック追跡のための定義に関するＣ＋＋−特定の実行
のソースコードリストである。表Ｆ．データブロック追跡の定義−ソースコードリスト

【表４６】

【表４７】

【表４８】

【００６０】以下の表Ｇは、再利用バッファ処理の定義に関するＣ＋＋−特定の実行のソー
スコードリストである。表Ｇ．再利用バッファ処理の定義−ソースコードリスト

【表４９】

【表５０】

【表５１】

【００６１】本発明は、明確でありながら比較的長期の課題、つまりＭＰＥＧ−２における
スタートコードの位置探索の課題を解決するより効率的な手法としてのアルゴリ
ズムを提供する。現存するアルゴリズムの内でこの課題解決を有効に達成するも
のは、従来技術として考えることができる。本発明の１つの目的は、この明確な
目標を達成するために必要なＣＰＵ時間を低減することにある。本発明は、ＭＰ
ＥＧ−２データストリームに関して有用であるが、この標準規格に限定されるこ
となく他の標準規格に適用できることは、当業者であれば容易に考えられること
であろう。例えば、本発明の好ましい実施形態について実行された検索パターン
は、ＭＰＥＧ−２に直結したものであるが、このアルゴリズムの一般概念は、バ
ッファにおいて特異な３バイトパターンを検出する課題にも適用できる。この概
念は、一般的に如何なるパターン長の検索にも拡張できるが、特に、パターンが
奇数バイトである場合に有用である。

【００６２】本発明の現時点で好ましい実施形態は、特に、ＣＰＵ命令群において以下の能
力を持つＣＰＵ上で展開する場合に有用である（但し、本発明は、このような形
式のプロセッサのみに限定されるものではない）。・所定のバイト値／ワード値／ダブルワード値に対する一致又は不一致を確認す
るために任意サイズとされたメモリブロックを走査する能力（例えば、８０×８
６のＳＣＡＳ命令）。好ましい実施形態では、ワード走査のみが必要とされる。
・同一性を確認するために、任意ではあるが同じサイズとされた２つのメモリブ
ロックを比較し、それらがバイト対バイトの比較で同一であるか否かを示す能力
（例えば、８０×８６のＣＭＰＳ命令）。・単一マクロ命令として上記両機能を実行する能力（例えば、８０×８６のＲＥ
ＰＥ／ＲＥＰＥＭ命令）。

【００６３】本発明の現時点での好ましい実施形態を実行するアルゴリズムに関するソース
コードは、米国ワシントン州レッドモンドのＭｉｃｒｏｓｏｆｔ社によって製造
されたＭｉｃｒｏｓｏｆｔＣ＋＋コンパイラに適合するフォーマットで以下の
表Ａに示される。このアルゴリズムを説明するフローチャートは以下の通りであ
る。ステップ０：エントリポイント。（呼出しパラメータによって）「バッファ終
端トリミング」は有効にされたか？そうでなければ、ステップ２に進む。ステップ１：バッファの終端バイトが下記６つのパターンの何れかに一致した
かどうかを調べる。０００００００００００１一致する場合には、評価バッファのサイズを減少してこれらのバイトを取り除
く。この論理バッファサイズを減少したことは、呼び出しルーチンに通知する必
要があり、この通知によりこれらの「飛越しされた」バイトは、スタートコード
走査ルーチンに対する以降の呼び出しの際、再評価される。テスト状態がＦＡＬ
ＳＥになるまでステップ１をループ化する。一部のケース（例えば、完全にゼロ
バイトから成るバッファのような場合）では、このトリミングによってバッファ
全体が使い尽くされた結果になる可能性があり、この特殊ケースでは、バッファ
の最後の１又は２バイトがゼロであるかどうかによって、バッファの元のサイズ
を１又は２バイトほど減らして、このバッファにはスタートコードは存在しない
ことを呼び出し側に返答すべきである点に留意する必要がある。（以下に含まれ
るソースコードに使用される実際のコードは、より効率的であるが記述がより難
しい同じ実効果持つアルゴリズムを使用する。当業者であれば、本明細書に示さ
れたいずれのアルゴリズムのオペレーションも評価し理解できると考える。）バ
ッファのサイズが、初期オフセットを考慮に入れた状態で６バイト未満の場合に
は、現在のサイズを減らしたバッファにはスタートコードは存在しないこと呼び
出し側に返答する。また、バッファのサイズが奇数の場合には、それを偶数にす
るように減少しこの情報を呼び出し側に戻すことによって、この付加的に「削除
された」バイトは、次回の呼び出しの際に再走査されることになる。

【００６４】ステップ２：現在のバッファ評価位置において最初のＤワードがゼロかどうか
を調べる。そうでなければステップ５にスキップする。ステップ３：最初の非ゼロワードが検出されるまで前方走査する。これは、ス
テップ５で定義されたようなワード走査である。非ゼロワードが検出される前に
、評価バッファの終端に到達した場合には、呼び出し側に返答する（「バッファ
終端トリミング」が有効化されていれば、このようなことは起こらない）。ステップ４：評価バッファポインタを１ワード後退させる。この「先行」ゼロ
ワードがスタートコードの始まりであるかもしれないためである。ステップ５：最初のゼロワードについて前方走査する（これは、ステップ４が
実行されるとその直後検出される）。この走査は、ワード走査である（「検索ポ
インタ」が、反復毎に１ワード即ち２バイト移動する）。バッファ終端に到達す
ると、終端ゼロワードは見つからないというフラグが検出されてステップ７に進
む。

【００６５】ステップ６：この時点で有効スタートコードの存在をチェックする。これは、
以下のルールに基づく。最初の２つのバイトはゼロである。三番目のバイトは１である。これが、（スタートコード走査ルーチンに対する呼び出し側パラメータの
１つによって定義されたような）音響チャンネルである場合には、四番目のバイ
トが、０×Ｃ０から０×ＤＦの範囲に含まれているかどうかを調べる。含まれて
いない場合には、これは有効なスタートコードではない。これが音響チャンネルでない場合には、四番目のバイトが、０×Ｃ０から
０×ＤＦの範囲に含まれていないことを調べる。含まれている場合には、これは
有効なスタートコードではない。四番目のバイトがゼロである場合には、五番目及び六番目がゼロかどうか
を調べる。いずれもゼロである場合には、これは有効なスタートコードではない
。この発見されたゼロワードが、有効なスタートコードでないと判定された場合
、ステップ５に戻る。また、この発見されたスタートコードのオフセットをロー
カル変数に記憶する。

【００６６】ステップ７：ステップ５で走査が開始された点（但し、ステップ６でのスター
トコードテストの失敗によって開始されたものではない）から、スタートコード
がステップ６で検出された（又はステップ５からこのステップに進んだ場合には
バッファ終端の）点まで評価バッファの一時的領域を定義する。このサブバッフ
ァを、ゼロワード範囲と呼ぶ。「現在位置」をこのゼロワード範囲の始点に対し
て設定する。ステップ８：値０００１（これはビッグエンディアン方式のマシン上で０×
０００１と表現され又はリトルエンディアン方式のマシンでは０×０１００と表
現される）を持つ次のワードについて、ゼロワード範囲の内側に限定して、ワー
ド走査（定義に関してはステップ５を参照）のように前方走査する。発見できな
い場合には、ステップ１０に進む。ステップ９：ステップ６で定義されたルールを使って、これが有効スタートコ
ードかどうか調べるためにチェックする（但し、ポインタが、現在、潜在的スタ
ートコードに入った１つのバイトであることに留意）。スタートコードが発見さ
れた場合には、そのオフセットを呼び出し側に戻すリストに付記する。いずれの
場合にも、ステップ８に戻る。ステップ１０：プロセスが、（ステップ５でなく）ステップ６からステップ７
に進むと、ステップ６で発見されたスタートコードのオフセットを呼び出し側に
戻すリストに付記し、「現在のポインタ」をステップ６で発見されたスタートコ
ードに続くワードに対し設定し、ステップ２に戻る。さもなければ、呼び出し側
に返答する。

【００６７】（実施例）オフセットバッファ（スタートコードのオフセットが書込まれるバッファ）が
６つのエントリを保持できると仮定する。この例としてのソースバッファは、１
４のスタートコードを有する（各オフセットは１６進法で表す）。実際のスター
トコードではない０×０００×００及び０×０００×０１のバイトパターン
が存在可能であり、詳しくは、このような「偽性スタートコード」が検出され飛
越しされ、各スタートコードが実際にスタートコードであると確認される可能性
があると仮定する。

【００６８】入力時、バッファポインタは、ゼロに位置される（図５ａ参照）。０×００１０で検出される最初の配列０×０００×００ワードを探す（図５
ｂ参照）。０×０００から０×００１０でゼロワード範囲を設定する（図５ｃ参照）。こ
の範囲で０×０００×０１のワード配列バイトパターンを探す。存在しない場
合、オフセット０×００１０が出力リストに設定され、現時点で１つのエントリ
をその出力リストを与える。以前のゼロワード範囲（即ちオフセット０×００１
２）に後続する１つのワードから始めて、次の０×０００×００のワード配列
バイトパターンを探す。これは、オフセット０×００７Ａで検出される（０×０
１０及び０×００１２間の差は図５ｃに示されていないが、実際には、左側のポ
インタは、２つのアドレス位置だけ右側に移動している点に留意）。

【００６９】ワード配列バイトパターン０×０００×０１についてこのゼロワード範囲を
走査する（図５ｄ参照）。２つが０×００２４及び０×００３２で検出される。
０×００２３及び０×００３１がスタートコードであることを確認した後、これ
ら２つのオフセットを（これまで計３つを書込んだ）テーブルに加え、次にオフ
セット０×００７Ａに算入することにより、この出力テーブルには４つのエント
リが保持される。そして、次のワード配列バイトパターン０×０００×００を
探し、それを０×００ＢＥで検出する。このゼロワード範囲の走査により、「奇数配列」のスタートコードがないこと
が明らかにされ、オフセット０×００ＢＥが出力テーブルに加えられ、エントリ
の数は（６つの内）５つとなる。次のゼロワード範囲は、オフセット０×０１Ｃ
６に対して取られる（図５ｅ参照）。

【００７０】「奇数配列」スタートコードの走査により、０×０１４１でその１つを検出し
（０×１４２で検出される０×０００×０１パターン）、それを出力テーブル
に加え、出力テーブルには６つのエントリで満たされたことになる。これが出力
テーブルのサイズであるため、出力テーブルが６つのエントリを持つことを通知
すべく呼び出し側に返答する。スタートコード走査ルーチンに対する次の呼び出しの際は、最後に検出された
スタートコードを「飛越し」するように０×０１４２の初期オフセットを持った
状態で開始する（図５ｆ参照）。この条件では、初期オフセットは、常に偶数で
なくてはならず、奇数が渡された場合にはそれを増加して偶数にする。次のワード配列バイトパターン０×０００×００を探し、それを０×０１Ｃ
６で検出する（図５ｇ参照）。

【００７１】このゼロワード範囲の再走査で、「奇数配列」スタートコードはないと分かる
と、出力テーブルへの最初のエントリは、０×０１Ｃ６となる（図５ｈ参照）。
次のゼロワード範囲の探索により、０×０１Ｅ２が境界になっていることが検出
される。ここでも、その範囲に介在する「奇数配列」スタートコードは存在しないので
、出力テーブルへの二番目のエントリは、０×０１Ｅ２となる（図５ｉ参照）。
次のゼロワード範囲は、オフセット０×０２７Ｃに移行する。この範囲には、１つの「奇数配列」スタートコードが存在するので、出力テー
ブルへの三番目のエントリは、０×０×０２２Ｂとなり、四番目のエントリは、
０×０２７Ｃとなる（図５ｊ参照）。他のゼロワード範囲では、検索ポインタは
０×０２Ｄ４に移される。このゼロワード範囲では、０×０２９Ｄにスタートコードが埋め込まれている
（０×０００×０１パターンは、０×２９Ｅで検出される）ので、出力テーブ
ルへの五番目及び六番目のエントリは、０×０２９Ｄ及び０×０２Ｄ４となる。
テーブルが満たされたため、プロセスは呼び出し側に返答する。

【００７２】このバッファのスキャナに対する第三の呼び出しの際には、検索は、オフセッ
ト０×０２Ｄ６で開始される（図５ｋ参照）。次のワード配列０×０００×００パターンは、０×０３０６で発見される（
図５ｌ参照）。このゼロワード範囲の再走査により、「奇数配列」スタートコードが存在しな
いことが明らかにされると、出力テーブルへの最初のエントリは、０×０３０６
となる。０×０００×００パターンについての次の走査は不調に終わり、この
事実について信号が出され、プロセスは、ここでのゼロワード範囲の「遠端」を
バッファ終端に移動する（図５ｍ参照）。ワード配列０×０００×０１パターンについてのこのサブバッファの再走査
により、０×０３４８で１つが検出されると、オフセット０×０３４７が出力テ
ーブルに加えられ、２つのエントリが出力テーブルの構成要素とされる。これは
、バッファの終端でありこれ以上の検索はないので、プロセスは、２つ更にスタ
ートコードが検出されたことを伝えるべく呼び出し側に返答する。

【００７３】表Ｈ. 本発明によるスタートコード走査のためのアルゴリズムのソースコード
リスト

【表５２】

【表５３】

【表５４】

【表５５】

【表５６】

【表５７】

【表５８】

【表５９】

【表６０】

【００７４】本発明の現状で好ましい実施形態は、８０×８６／Ｐｅｎｔｉｕｍ（登録商標
）のアーキテクチャを最適化する。当業者であれば、本発明が他のアーキテクチ
ャに使用できることは理解される所であると考える。本発明の好ましい実施形態
は、Ｉｎｔｅｌプロセッサのアーキテクチャ、そのプロセッサの３２ビット命令
、及び使用可能なアドレス指定モードのストリング命令及び他の機能の組み合せ
を用いることによって、メモリバッファ内のスタートコードの位置を高速で探し
出す。本発明は、高速バッファオペレーションを可能とするホストプロセッサのアー
キテクチャに内蔵された機能を使用するため、アルゴリズムは、メモリバッファ
内のスタートコードの位置を非常に高い速度で探し出す能力がある。当業者であ
れば、様々な公知のハードウェア及び／又はソフトウェア技術も、このようなオ
ペレーションを実行するために使用することができることは理解される所である
と考える。

【００７５】本発明を使用して達成される性能の指標となる例として、ＭＰＥＧ−２ストリ
ームの２０メガバイト捕捉信号が処理された。本発明を使用することにより、Ｗ
ｉｎｄｏｗｓ（登録商標）ＮＴ４．０を実行する２６６ＭＨｚＰｅｎｔｉｕｍ（
登録商標）マシン上で、２万を超えるスタートコードを記述したテキストファイ
ルが１秒未満で書込まれた。２０メガバイトのＭＰＥＧ−２ファイルが、既にデ
ィスクキャッシュにロードされている場合には、二番目及びそれ以降の実行の際
にもこの実行時間が達成された。そこでの最初の実際のアプリケーションにおい
て、本発明は、ＣＰＵの総使用量をほぼ６０％まで低減した。

【００７６】本発明の他の実施形態では、ＭＰＥＧ−２データストリームにおける多種多様
な構造間で生じる移行を、後のＭＰＥＧ−２デコード段階に通知する情報の二次
的チャンネルを生成する。この二次チャンネルにおける情報は、あらゆる処理段
階でＭＰＥＧ−２データストリームのデコードを簡便にするために使用すること
ができる。これは、ＭＰＥＧ−２デコーダのソフトウェアによる実行に特に有用
である。

【００７７】図６において、ＭＰＥＧ−２システム１００は、高精細度テレビ（ＨＤＴＶ）
ビデオソース１０２及びサラウンド・サウンド（ＳＳ）ソース１０４を備える。
既存のエンコーダ１０６は、工業標準規格ＭＰＥＧ−２仕様に従って、ＨＤＴＶ
及びＳＳ信号をＭＰＥＧ−２データストリーム１０８に圧縮する。このＭＰＥＧ
−２データストリーム１０８は、光ディスクに記憶するか、或いは装置１０９で
表される限定された帯域幅の通信回線を介して伝送することができる。

【００７８】事前パーサ（事前構文解析ツール）１１０は、入来ＭＰＥＧ−２データストリ
ーム１０８をサンプリングし、それを一連のＭＰＥＧ−２サンプル１１２として
出力する。事前パーサ１１０は、ＭＰＥＧ−２データストリームを解析して「注
意喚起」の記述及び通知を含む二次チャンネル１１４を出力する。実際には、こ
れら記述及び通知は、主メモリのテーブルに保存される。事前パーサ１１０は、
ソフトウェアで実行でき、ＭＰＥＧ−２サンプル及び記述子をサブルーチン間の
テーブル呼び出しに連絡する。二次チャンネル１１４は、ＭＰＥＧ−２サンプル
において様々なデータ構造移行が生じる場所を記述する。ソフトウェアで実行さ
れるＭＰＥＧ−２デコーダ１１５は、二次チャンネル１４における通知を使用し
てＭＰＥＧ−２サンプル１１２をデコードする。このＭＰＥＧ−２デコーダ１１
５は、実行可能ＤＬＬ型ディスクファイルに記憶させることができる。

【００７９】ＭＰＥＧ−２圧縮サンプル１１２のデコードは、二次チャンネルの情報の助け
を借りることなく行なうことができるが、ＭＰＥＧ−２デコーダは、より高価な
デジタル式ハードウェアで実施する必要があると思われる。このような二次チャ
ンネルの通知は、事前構文解析データの要素となり、ＭＰＥＧ−２圧縮サンプル
１１２における様々な構造的特徴の位置を特定する。このような特徴としては、
ＥＳスタートコード、音響フレームヘッダー、ＰＥＳヘッダー、及びはるかに一
般的な基本ペイロードが挙げられる。ソフトウェアで実行されるＭＰＥＧ−２デ
コーダ１１５により、どちらかと言えば困難でＣＰＵに集中的な負担が掛かる構
文解析ジョブが軽減される。

【００８０】ＭＰＥＧ−２デコーダ１１５は、３段階のフィルタとして図６に示されており
、第一段階のフィルタ１１６ＭＰＥＧ−２出力１１８及び事前パーサ出力１２０
を転送する。ＭＰＥＧ−２サンプル１１２の構文解析ジョブの大部分又は全てが
既に事前パーサで済まされているために、第一段階のフィルタ（Ａ）１１６及び
第二段階のフィルタ（Ｂ）１２２では、ＭＰＥＧ−２サンプル１１２の構文解析
ジョブが省かれる。第二段階のフィルタ１２２は、修正したＭＰＥＧ−２データ
ストリーム１２４及び更新した二次チャンネル１２６を、非圧縮化され再構成さ
れたＨＤＴＶ及びＳＳ信号１３０及び１３２を順に出力するレンダラー１２８等
の最終段階のフィルタに出力する。このレンダラーは二次チャンネル１２６で事
前構文解析情報を受け入れているために、レンダラーでもＭＰＥＧ−２サンプル
１１２の構文解析ジョブが省かれる。

【００８１】フィルタ１１６、１２２の各々は、レンダリングフィルタであるにも係らず、
ＭＰＥＧ−２データストリームを修正することができる。この修正には、何らか
のデータ特徴の追加、削除、又は変更が含まれ、それによってランレングスを変
更することができる。これら各フィルタは、その修正ＭＰＥＧ−２データストリ
ームを次のフィルタに送り、このフィルタもそれ自身の変更をいくらか行うこと
ができる。

【００８２】ＭＰＥＧ−２データストリームの構文解析は、冗漫な誤りがちなものであり、
特にそれが必要でない場合にはこのジョブの重複は避けるべきである。本発明の
ＭＰＥＧ−２デコーダの実施形態では、事前構文解析を用いＭＰＥＧ−２データ
ストリームが受信機又はデコードシステムに入力された時点で、一度だけこのジ
ョブを行なう。事前パーサによって、全ての適正長のＭＰＥＧ−２データストリ
ームのサンプル毎に、記述子のリストが生成される。次に、この記述子リストは
、ＭＰＥＧ−２サンプル１１２、１１８及び１２４とともに二次チャンネル１１
４、１２０及び１２６で運ばれる。ＭＰＥＧ−２サンプルを処理する各フィルタ
１１６、１２２及び１２８は、二次チャンネルの記述子リストをデイジーチェー
ン形式で更新する。二次チャンネルの記述子リストは、維持し易く、各フィルタ
に対しわずかな付加的な処理オーバーヘッドを加えるのみである。しかしながら
、構文解析を各フィルタ自身で行なうようにした各フィルタでの処理段階を必要
としないために、処理量は大幅に軽減される。

【００８３】事前構文解析データを持つデータストリームは、ＭＰＥＧ−２データを持つデ
ータストリームに平行に加えられる。この二次データストリームには、「記述子
」又は「通知」と呼ばれる１６ビットの整数アレーが含まれる。通知は、不連続
点及び音響フレームサイズ変更等のＭＰＥＧ−２データストリームに既に埋め込
まれている情報以上の情報を提供することを目的としたものである。二次チャン
ネルのこのような注意喚起情報により、ＭＰＥＧ−２データストリーム処理がよ
り簡易化される。

【００８４】記述子は、形式と長さとの両方を記述する。基本ペイロード、音響フレームヘ
ッダー、ＥＳスタートコード、及びＰＥＳヘッダーのような４つの形式が最初に
定義された。１６ビット整数は、形式及び長さをコード化するために使用される
。基本ペイロードの形式は、可変長で非常に長いものである。音響フレームヘッ
ダー形式は、可変長であるが短く、通常８バイトに過ぎない。ＥＳスタートコー
ド形式は、通常、固定された４バイト長しかないものである。ＰＥＳヘッダー形
式は、可変長であるが５１２バイト未満のものである。実際には、音響フレーム
ヘッダー、ＥＳスタートコード、及びＰＥＳヘッダーの３つの分類に当てはまら
ない構造は全て基本ペイロード形式に含まれる。

【００８５】図７Ａに示されるように、１６ビット記述子２００の最上位ビットがゼロの場
合、ＭＰＥＧ−２サンプルは、基本ペイロード形式である。残る１５ビット１４
−０は、サンプル長フィールド２０１におけるＭＰＥＧ−２サンプル長を定める
。二次チャンネルは、多重連続的な基本ペイロード記述子を使用する。ゼロバイ
トのサンプル長を意味する全てゼロの基本ペイロード記述子としてもよい。この
ような全てゼロの記述子は、記述子アレーにおいてナル又はパディング要素とし
て使用することができる。図７Ｂのように、他の記述子形式の全て及び全ての通知は、それらの１６ビッ
ト値セットにおいて１の最上位ビットを持つ。記述子２０２において、形式フィ
ールド２０４のビット１４−９は形式を定義し、サイズフィールド２０６のビッ
ト８−０はＭＰＥＧ−２サンプル長を定義する。図７Ｃに示されるように、ビット１５−９が全て１の場合、記述子が通知ワー
ド２０８であることを定義し、通知コードフィールド２１０のビット８−０が、
正確な通知内容を定義する。

【００８６】オペレーションにおいて、各ＭＰＥＧ−２データストリームサンプルは、事前
パーサ１１０によって初期に主メモリ内に割振られた記述子アレー即ちテーブル
を有する。図８を検討する。各ＭＰＥＧ−２サンプルは、エントリとしての記述
子アレーによって各々定義された部分を持つ必要がある。従って、このような記
述子アレーは、ＭＰＥＧ−２全体を十分に特徴付けることが可能な１６ビット記
述子の全てを、そして全ての通知を含めて保持するに十分大きさでなくてはなら
ない。よって、初期に必要とされるより大きな記述子アレーを割振り、未使用端
部をゼロで埋めておくのが好ましい。このようにすれば、フィルタ１１６、１２
２及び１２８のような下流処理段階に、十分なスペースが与えられることになり
、新たな大きなテーブルへの再割振りを行うことによる時間又はＣＰＵオーバー
ヘッドを浪費することなく、記述子テーブルに下流処理段階の成果を加えること
ができる。

【００８７】各通知は、負数でコード化されるのが好ましい。このようなコードは、通知コ
ード２１０（図７Ｃ）の下から９つのビットを取出してそれを１だけ増やした後
、その結果の符号を変えてそれを負にすることによって得られる。これによって
、「通知トークン」は、「−１」から「−５１２」の範囲となる。これら２つの
最初のものは、「−１」で非連続を示し、「−２」でＭＰＥＧ−２に起こった何
らかの関心事項を示すように予め定義されている。「−１」が通知に受信される
と、受信プロセスは、その状態にマシンをリセットし、以降の特徴を以前の特徴
と全く関係ないものとみなす。構成された試作品において、「−２」通知コード
は、フレームサイズが音響データストリームにおいて変化した時に発行される。

【００８８】図７Ａ乃至図７Ｂに図示された記述子は、オフセットではなく長さを定義する
のが好ましい。これにより、記述子を一定の１６ビットとすることができ、記述
子アレーをより小さくすることができる。フィルタ１１６又は１２２がＭＰＥＧ
−２サンプルに特徴を加えたりそれを取り去ったりする場合、対応する記述子が
、単に記述子アレーに加えられたチャンネルそこから削除されたりするだけであ
る。ＭＰＥＧ−２サンプルの構成要素である特徴の何れかが、長さにおいて減少又
は拡大されたとしても、それに対応するわずかな記述子が更新されるだけで、そ
の他の記述子は影響されない。基本ペイロードの場合、単一の記述子を、いくつ
かの記述子に分割しなくてはならない可能性がある。これは、元の特徴が長さで
３２７６８バイト未満であり、修正された特徴が、記述可能なサンプル長フィー
ルド２０１において１５二進バイトより大きい場合に起こり得る。

【００８９】ＭＰＥＧ−２データストリームは、通常、連続的に処理される。そのため、「
オフセットカウンタ」を、各ＭＰＥＧ−２サンプル特徴の長さによって増大する
事前パーサ１１０に設けることができる。このようなオフセットカウンタの組み
込み操作は簡単である。記述子は簡便であるので、テーブル内でのそれらの維持も簡単である。中間段
階での記述子テーブルの大幅な再構成は、ＤＬＬ型ファイルに対する呼び出し時
の事前構文解析タスクが繰り返されるのと並行して行なうのが好ましい。

【００９０】図８は、単一データストリーム内にそれぞれ完全な形で含まれたペイロード、
ＥＳヘッダー、及びＰＥＳヘッダーを有する典型的なＭＰＥＧ−２ビデオデータ
ストリームサンプルである。事前構文解析がない場合、処理段階１１６、１２２
及び１２８の各々は、それら自身でＭＰＥＧ−２の特徴境界の位置を探す必要が
ある。しかし、事前パーサ１１０によって提供されるような事前構文解析では、
各ＭＰＥＧ−２サンプルの開始時にゼロに初期化される「オフセットカウンタ」
が使用される。このオフセットカウンタは、記述子テーブルが順次走査されるの
と並行して各特長の長さに応じて漸増し、アドレスカウンタとして機能する。例
えば、ＰＥＳヘッダーは、その記述子の先端から７つのビットに「０×８４００
」を持つことになる。全てのサンプル特徴の長さは、他の特徴記述子を探しなが
ら加えることができる。図８において、ＰＥＳヘッダーは、オフセット０×２８
４（０×２０＋０×４＋０×２１Ａ＋０×４＋０×４２）に存在し、更に０×１
６６４（０×２８４＋０×１Ｃ＋０×７０Ｄ＋０×４＋０×３９＋０×４＋０×
Ｃ７６）にも存在する。各特徴の長さは、迅速に求めることができる。図８は、
これらＰＥＳヘッダーのいずれもが同じ長さ（０×１Ｃ）のものであることを示
しているが、このようなケースばかりではない。ペイロードを累積するという目
標は簡便であり、入力サンプルの「飛越し」部分は、簡単に認識できる。ＭＰＥ
Ｇ−２サンプルデータストリームの直接評価を行なう代わりに記述子テーブルを
使用することによって、以降の処理段階において処理時間を大幅に節約すること
ができる。

【００９１】ＩＳＯ／ＩＥＣ仕様１３８１８−１は、ＰＥＳヘッダーが他の特徴形式内に挿
入されることを容認している。本発明の実施形態では、基本ペイロード特徴の挿
入のみが容認される。よって、ＰＥＳヘッダーは、それらが進入した特徴の一側
に又は他側に再配置される。このようなことが起こった場合、ＭＰＥＧ−２デー
タストリーム内の絶対位置における変化を補償するように、ＰＥＳヘッダーの内
容を若干調整する必要がある。

【００９２】図９は、ＭＰＥＧ−２ビデオデコードプロセッサ１００の機能ブロック図であ
る。入来ＭＰＥＧ−２データストリーム１０１は、非圧縮化のためのヘッダーパ
ーサ１０２によって受信される。ＭＰＥＧ及びＪＰＥＧにおける局所空間非圧縮
化方法は非常に類似している。画像データは、２次元正規直交系８×８ＤＣＴで
ブロック変換コード化される。これによって得られた６３のＡＣ変換係数は、統
計的にゼロの連続が増加するようにジグザグパターンにマップ化される。次に、
ベクトルの係数を、一様にスカラ量子化した後に、ランレングスコード化し、最
終的にランレングス記号は、標準的な（ＪＰＥＧ）手法又は修正ホフマン（ＭＰ
ＥＧ）手法を使って可変長コード化される。ロックＤＣ係数のグローバルフレー
ム冗長性は、１ＤＤＰＣＭによって低減され、次に量子化及び可変長エントロ
ピーコード化される。

【００９３】ヘッダーパーサ１１０２は、圧縮ＭＰＥＧ−２ビデオビットストリーム１１０
４から、動きベクトル情報ストリーム１１０３を分離する。動きベクトル（ＭＶ
）計算器１１０６及び可変長デコーダ（ＶＬＤ）１１０８は、分離された各スト
リームを受信する。ビットストリーム１１０４は、更にＶＬＤ１１０８で処理さ
れ、元のゼロ周波数（ＤＣ）及び最高６３の非ゼロ周波数（ＡＣ）係数を再構成
する。ＶＬＤ１１０８に含まれるランレングスデコーダ及び逆量子化により、Ｄ
Ｃ係数を含むＦ₀ストリーム１１１０及びＡＣ係数を含むＦ_1.63ストリーム１１
１２の生成が促進される。これらＤＣ及びＡＣ係数は、更に処理されて周波数ド
メインに補正項が与えられる。逆離散コサイン変換器１１１４は、Ｆ₀，Ｆ_1.63
ストリーム１１１０／１１１２における離散コサインを、周波数ドメインインか
ら空間ドメインに戻すように変換する。空間ドメイン出力１１１６が生成される
。

【００９４】動きベクトル情報は、ＭＶ計算器１１０６における有効動きベクトル出力スト
リーム１１１８を計算するために使用される。予測器１１２０は、この有効動き
ベクトルを使ってアナログ加算器１１２２に転送される予測を構築する。記憶フ
レーム１１２４及び１１２６は、以前にデコードし記憶された参照画像を、後に
予測器１１２０によって利用できるようにする。ＭＰＥＧ−２補間ケースＡ−Ｄ
用に本明細書にリストされたサブルーチンは、典型的には、予測器の構成内で実
行される。それによって得られた画素から成る予測ブロックは、逆離散コサイン
変換の結果とアナログ加算器において組み合わされて最終的な再構成マイクロブ
ロックを生成し、その後、例えば、記憶フレーム１１２４及び１１２６として記
憶される。

【００９５】図１０は、本発明の実施形態によるＭＰＥＧ−２ビデオデコーダを示し、ここ
では参照番号１２００でその全体が示される。ＭＰＥＧ−２ビデオデコード方法
１２００は、丸め誤差の累積を防止する。これにより、ＭＰＥＧ−２補間ケース
−Ｄ用の改善された２段階１／２画素予測体系の使用が可能となる。また、本発
明の実施形態は、既に２段階１／２画素予測体系を使用して実行される、つまり
、逆離散コサイン変換に先立つ段階がソフトウェアで実行される場合の画像品質
を改善するためにも使用できる。丸め誤差は、影響を受けた各マイクロブロックの全画素にわたって均等に分配
されると考えることができる。従って、丸め誤差の累積によって生じる可視的悪
影響を防止するために統計を用いることができる。全体としては、本発明の実施
形態では、ＭＰＥＧ−２補間ケース−Ｄ処理を必要とする全てのマイクロブロッ
クから丸め誤差を取り除く。このように、これら誤差全体が削除される。

【００９６】整数処理では、逆離散コサイン変換後の誤差値を取り除くことは不可能である
。幸い、ＭＰＥＧ−２デコード標準規格に定義された逆離散コサイン変換は、Ｄ
Ｃ係数に関して８の有効除算がある。これを利用して、整数値３としてケース−
Ｄ処理を必要とする全てのマイクロブロックから、逆離散コサイン変換の直前に
ＤＣ係数から０．３７５の補正項を取り去ることができる。結果としての２４の
エネルギー差が、６４の変換補正項の全てに配分される。これにより、２段階１
／２画素予測によって導き出された０．３７５誤差を消去する−３．３７５が統
計的に配分される。

【００９７】本発明の実施形態は、逆離散コサイン変換プロセスの前に、全てのケース（Ａ
乃至Ｄ）のためのＤＣ係数に対する適切な修正項を使用することによって、加算
平均演算時に補正項を加える必要性を排除する。これにより、グラフィック・ア
クセラレータの状態の単純なアルファ・ブレンディングユニットの使用し、ＭＰ
ＥＧ−２標準規格に適合する動き補償を、ＭＰＥＧ−２を使用して改善する必要
性なく行なうことを可能とする。図１０において、ＭＰＥＧ−２補間ケース−Ｄのための２段階動き予測では、
補正されていない場合には、可視的アーチファクトを生じる。本発明は、マルチ
プレクサと組み合わせた論理ＡＮＤ回路、及び加算器の組み合わせとして実施形
態に導入されている。水平（ｈ₀）及び垂直（ｈ₁）動きベクトル成分のいずれも
が、１／２画素補間（ケース−Ｄ）を必要とする場合には、マルチプレクサは、
定数マイナス３を加算器に転送し、他のケースでは、定数ゼロが使用される。加
算器は、マルチプレクサの結果をＤＣ係数に加算して、２段階予測器によって計
算された予測画素についての補正項を含む新しいＤＣ係数を形成する。 −０．３７５の補正値は、逆離散コサイン変換の過程で、得られた６４の空間
係数の全てに均等に配分される。これにより、統計的には、若干暗い補正項のセ
ットとなる。これにより、２段階予測器によって形成された若干明るい予測値が
排除される。出力フレームは、統計的には正確な画像となる。

【００９８】図１０の実施形態のデコーダ１２００は、ヘッダーパーサ１２０４を使用して
ＭＰＥＧ−２データストリーム１２０２を受信する。ヘッダーパーサ１２０４は
、圧縮ＭＰＥＧ−２ビデオビットストリーム１２０８から、動きベクトル情報ス
トリーム１２０６を分離する。動きベクトル（ＭＶ）計算器１２１０は、垂直動
きベクトル成分ｈ₁出力１２１２、水平動きベクトル成分ｈ₀出力１２１４、及び
ＭＶ出力１２１６を生成する。ＡＮＤゲート１２１８は、マルチプレクサ１２２
０がマイナス３値１２２２又はゼロ値１２２４を選択するようにする。ｈ₀出力
１２１４及びｈ₁出力が共に正しい場合には、マイナス３値１２２２が選択され
、加算器１２２６に送られる。プロセッサ１２２８は、可変長デコーダ（ＶＬＤ
）、ランレングスデコーダ、及び逆量子化ユニットを備える。プロセッサは、直
流（ＤＣ）係数Ｆ₀出力１２３０及び交流（ＡＣ）係数Ｆ_1.63出力１２３２を生
成する。プロセッサ１２２８は、元のＤＣ係数を再構成するとともに最高６３の
ＡＣ係数を再構成する。逆離散コサイン変換器１２３４は、加算器１２２６によ
る補正後、離散コサインをＦ₀，Ｆ_1.63ストリーム１２３０／１２３２に変換す
る。空間ドメイン出力１２３６が生成される。

【００９９】次に、ＭＰＥＧ−２補間ケース−Ｄが普及する場合、一部の市販マイクロプロ
セッサの「ｐａｖｇｕｓｂ」を利用可能な２段階予測器１２３８を使用すること
ができる。特に、ケース−Ｄでは、以下のようにする。

【表６１】

【０１００】このように、高レベルプログラミング命令文「ａｖｇ（ａｖｇ（Ｐ₀₀，Ｐ₀₁）
，ａｖｇ（Ｐ₁₀，Ｐ₁₁））」が使用でき、本発明の実施形態の実行に現時点で好
適である。しかし、これにより累積丸め誤差が生成されるが、この累積丸め誤差
は、空間ドメイン出力１２３６及び予測出力１２４０を組み合わせる加算器１２
４２において統計的に排除される。また、これらにより、イントラ画像間の２段
階予測器１２３８によって参照される一連の記憶フレーム１２２４及び１２４６
が作り出される。本明細書において、本発明は好ましい実施形態を参照して説明されたが、本発
明の精神及び範囲を逸脱することなく他の応用を本明細書に示された実施形態に
代用できることは、当業者であれば容易に考え得る所であると考える。従って、
本発明は、特許請求の範囲のみによって限定されるべきである。

【図面の簡単な説明】

【図１】オブジェクト割振りをわずかに使用するとともにこのオブジェクトの多量のコ
ピーを行なうストリーミング処理システムの構成を示す概要図である。

【図２】オブジェクト割振りを多用するとともにこのオブジェクトのわずかなコピーを
行なうストリーミング処理システムの構成を示す概要図である。

【図３】本発明によるコンピュータにおいて高速ストリーミングデータの最適処理・操
作を行なうシステムの構成を示す概要図である。

【図４】本発明によるコンピュータにおいて高速ストリーミングデータの最適処理・操
作を行なう搬送処理ミニコアの構成を示す概要図である。

【図５ａ】本発明によるスタートコードスキャナの例を示す図である。

【図５ｂ】本発明によるスタートコードスキャナの例を示す図である。

【図５ｃ】本発明によるスタートコードスキャナの例を示す図である。

【図５ｄ】本発明によるスタートコードスキャナの例を示す図である。

【図５ｅ】本発明によるスタートコードスキャナの例を示す図である。

【図５ｆ】本発明によるスタートコードスキャナの例を示す図である。

【図５ｇ】本発明によるスタートコードスキャナの例を示す図である。

【図５ｈ】本発明によるスタートコードスキャナの例を示す図である。

【図５ｉ】本発明によるスタートコードスキャナの例を示す図である。

【図５ｊ】本発明によるスタートコードスキャナの例を示す図である。

【図５ｋ】本発明によるスタートコードスキャナの例を示す図である。

【図５ｌ】本発明によるスタートコードスキャナの例を示す図である。

【図５ｍ】本発明によるスタートコードスキャナの例を示す図である。

【図６】本発明の実施形態によるＭＰＥＧ−２システムの機能ブロック図である。

【図７Ａ】基本ペイロード型ＭＰＥＧ−２サンプルに関する、図５のシステムに使用され
る１６ビットの記述子ワードを示す図である。

【図７Ｂ】基本ペイロード型ＭＰＥＧ−２サンプル以外のものに関する、図５のシステム
に使用される１６ビットの記述子ワードを示す図である。

【図７Ｃ】通知に関する、図５のシステムに使用される１６ビットの記述子ワードを示す
図である。

【図８】ＭＰＥＧ−２サンプル及び対応する記述子アレーを示す図である。

【図９】ＭＰＥＧ−２ビデオデコードプロセッサの機能ブロック図である。

【図１０】本発明の実施形態による２段階の１／２画素予測を含むＭＰＥＧ−２デコーダ
の機能ブロック図である。

───────────────────────────────────────────────────── フロントページの続き (31)優先権主張番号０９／３４２，５２７ (32)優先日平成11年６月29日(1999．6．29) (33)優先権主張国米国（ＵＳ） (31)優先権主張番号０９／４６７，５５２ (32)優先日平成11年12月10日(1999．12．10) (33)優先権主張国米国（ＵＳ） (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ，ＺＷ )，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ (72)発明者ランガーランディーアメリカ合衆国ワシントン州 98366 ポートオーチャードセリーストコートサウスイースト 3785 (72)発明者ジグモントウルリッヒドイツ連邦共和国デー−76133 カルスルールヴィクトルラシュトラッセ６Ｆターム(参考） 5B098 GA05 GB13 5C059 LB18 MA00 MA23 MC11 MC32 MC34 ME05 NN15 RB01 RC16 RC28 SS02 SS11 UA02

Claims

【特許請求の範囲】

【請求項１】コンピュータシステムにおけるストリーミングデータを処理
する方法であって、メモリコピーを最小限にする段階、及びオブジェクトの割振り及び割振り解除を最小限にする段階を含むことを特徴と
する方法。
【請求項２】可能な時はいつでもメモリのコピーではなくメモリ参照オブ
ジェクトを使用する段階更に含むことを特徴とする請求項１に記載の方法。
【請求項３】データブロックに関するリストを含む複数の個別の待ち行列
を使用する段階を更に含むことを特徴とする請求項１及び２のいずれかに記載の
方法。
【請求項４】前記待ち行列が、現在使用されていないデータブロックオブジェクトのキャッシュを保持して、
オブジェクトの再利用を促進するとともに前記データブロックオブジェクトの割
振り及び割振り解除を最小限にするためのアイドル待ち行列、各ブロックが処理可能となるまで、入来データブロックの保持領域として使用
するための入力待ち行列、出力待ち行列に置かれる前に更にグローバル処理を行なうために保持する必要
がある、単一データブロックより大きなストリームを局所化するために使用する
リンボー待ち行列、及びデータブロックが入力待ち行列からリンボー待ち行列で処理され最終的に前記
出力待ち行列に置かれた後に、これら処理されたデータブロックを保持するため
の出力待ち行列のいずれかを含むことを特徴とする請求項３に記載の方法。
【請求項５】データブロックが前記出力待ち行列から取込まれその取込ま
れたデータがデコーダ又は事後処理ユニットに送られる時に、前記データブロッ
クを再利用のために前記アイドル待ち行列上に置く段階を更に含むことを特徴と
する請求項４に記載の方法。
【請求項６】マルチスレッディングによる処理デューティを分割する段階
を含むことを特徴とする請求項１乃至５のいずれかに記載の方法。
【請求項７】ストリーミング媒体ソースから入来メモリを取込み、データ
ブロックをアイドル待ち行列から抽出することによってデータブロックを構成し
、入来メモリに対して参照メモリポインタを割当て、新しいデータブロックを入
力待ち行列上に置くための入力スレッド、入力待ち行列からデータブロックを取込み、出力のため前記データブロックを
用意する必要のある時には、前記データを構文解析又は修正することによって前
記データブロックを処理し、データの局所化ストリームに関する必要な全ての情
報が、単一データブロック内に完全に含まれていないと判定されると、前記デー
タブロックを、前記局所化ストリームが完全な形となるまで、リンボー待ち行列
に置くとともに、前記局所化ストリームが完全に処理されると、前記完全に処理
された局所化ストリームを構成する前記データブロックを、出力待ち行列に移す
ための処理スレッド、前記出力待ち行列からデータブロックを取込むとともに、処理済データを下流
側処理ユニットに受け渡し、更に、これらの対応するデータブロックを、入来デ
ータに再利用するために前記アイドル待ち行列に戻すための出力スレッドのいず
れかを含む個々の処理スレッドをデューディの分割を促進するために準備する段
階を更に含むことを特徴とする請求項６に記載の方法。
【請求項８】入来データをコピーするのではなく入来ストリーミングデー
タパケットを参照することだけを行なうことによって、メモリコピーを最小限に
することを特徴とする請求項１乃至７のいずれかに記載の方法。
【請求項９】どの位置で入力データが発見されたか、出力データをどこで
事後処理するか、及び前記入力及び出力メモリ参照の各々の状況を参照するため
のデータブロックオブジェクトを準備する段階を更に含むことを特徴とする請求
項１乃至８のいずれかに記載の方法。
【請求項１０】オブジェクトの再利用のためのアイドル待ち行列を準備す
る段階を更に含むことを特徴とする請求項１乃至９に記載の方法。
【請求項１１】コンピュータシステムにおけるストリーミングデータを処
理する装置であって、メモリコピーを最小限にする手段、及びオブジェクトの割振り及び割振り解除を最小限にする手段を備えたことを特徴
とする装置。
【請求項１２】データブロックに関するリストを含む複数の個別の待ち行
列を更に備えたことを特徴とする請求項１１に記載の装置。
【請求項１３】前記待ち行列が、現在使用されていないデータブロックオブジェクトのキャッシュを保持して、
オブジェクトの再利用を促進するとともに前記データブロックオブジェクトの割
振り及び割振り解除を最小限にするためのアイドル待ち行列、各ブロックが処理可能となるまで、入来データブロックの保持領域として使用
するための入力待ち行列、出力待ち行列に置かれる前に更にグローバル処理を行なうために保持する必要
がある、単一データブロックより大きなストリームを局所化するために使用する
リンボー待ち行列、及びデータブロックが入力待ち行列からリンボー待ち行列で処理され最終的に前記
出力待ち行列に置かれた後に、これら処理されたデータブロックを保持するため
の出力待ち行列のいずれかを備えたことを特徴とする請求項１２に記載の装置。
【請求項１４】データブロックが前記出力待ち行列から取込まれその取込
まれたデータがデコーダ又は事後処理ユニットに送られる時に、前記データブロ
ックを再利用のために前記アイドル待ち行列上に置くための手段を更に備えたこ
とを特徴とする請求項１３に記載の装置。
【請求項１５】ストリーミング媒体ソースから入来メモリを取込み、デー
タブロックをアイドル待ち行列から抽出することによってデータブロックを構成
し、入来メモリに対して参照メモリポインタを割当て、新しいデータブロックを
入力待ち行列上に置くための入力スレッド、入力待ち行列からデータブロックを取込み、出力のため前記データブロックを
用意する必要のある時には、前記データを構文解析又は修正することによって前
記データブロックを処理し、データの局所化ストリームに関する必要な全ての情
報が、単一データブロック内に完全に含まれていないと判定されると、前記デー
タブロックを、前記局所化ストリームが完全な形となるまで、リンボー待ち行列
に置くとともに、前記局所化ストリームが完全に処理されると、前記完全に処理
された局所化ストリームを構成する前記データブロックを、出力待ち行列に移す
ための処理スレッド、前記出力待ち行列からデータブロックを取込むとともに、処理済データを下流
側処理ユニットに受け渡し、更に、これらの対応するデータブロックを、入来デ
ータに再利用するために前記アイドル待ち行列に戻すための出力スレッドのいず
れかを含む、デューティの分割を促進するための個々の処理スレッドを更に備え
たことを特徴とする請求項１１乃至１４のいずれかに記載の装置。
【請求項１６】どの位置で入力データが発見されたか、出力データをどこ
で事後処理するか、及び前記入力及び出力メモリ参照の各々の状況を参照するた
めのデータブロックオブジェクトを更に備えたことを特徴とする請求項１１乃至
１５のいずれかに記載の装置。
【請求項１７】オブジェクトの再利用のためのアイドル待ち行列を更に備
えたことを特徴とする請求項１１乃至１６のいずれかに記載の装置。
【請求項１８】データストリームにおけるスタートコードを走査するため
の方法であって、ワードによる方法で入力バッファを走査し、ワード境界を確認する段階、前記入力バッファを走査し、最初のスタートコードを確認する段階、現在の走査の開始点から前記最初のスタートコードまでの範囲を持つゼロワー
ド範囲を設定する段階、前記最初のスタートコードに対するオフセットを記憶する段階、前記ゼロワード範囲内で走査し、この範囲における他のスタートコードを確認
する段階、前記最初のスタートコードとともに前記他のスタートコードに関するオフセッ
トを順次記憶する段階、前記最初のゼロワード範囲が前記入力バッファの下位集合である場合には、次
のゼロワード範囲を定める段階、及び前記入力バッファ内の全てのスタートコードが確認され、前記スタートコード
に関するオフセットが順次記憶されるまで継続する段階を含むことを特徴とする
方法。
【請求項１９】データストリームにおけるスタートコードの位置を探し出
すための方法であって、処理バッファ内にスタートポインタを設定する段階を含むとともに、前記スタートポインタによって指された初めからｎ番目までのバイトが全
てゼロである場合、最初の非ゼロワードの位置を探し出す段階と、前記バッファの終端に到達した場合、呼び出し側に返答する段階と、前記バッファの終端に到達していない場合には、ゼロワード走査を終了し
た前記非ゼロワードより１だけ少ないワードに前記スタートポインタを設定する
段階と、最初のワード配列ゼロワードを検出するために走査する段階と、前記ゼロワードに続くバイトが１であり、前記１のバイトに続くバイトが
正当なスタートコードであり、前記スタートコード及びそれに続く２つのバイト
から成る３つのバイトが全てゼロでないことを確認する段階と、前記最初のゼロワードに続くバイトが正当なスタートコードの評価基準を
満足しない場合、前記最初のゼロワードを飛越し、前記処理バッファの終端でな
い限り、次のゼロワードを探す段階と、スタートコードが発見された場合又は走査が前記処理バッファの終端にあ
る場合、前記スタートポインタから、実際正当なスタートコードであると判定さ
れたゼロワード走査終了位置又は前記処理バッファの終端までの前記処理バッフ
ァの領域をゼロワード範囲として定める段階と、前記ゼロワード範囲の二番目のワードから始めて、０×０００×０１の
パターンについて前記ゼロワード範囲を再走査する段階と、前記ゼロワード範囲において検出されたスタートコードを示す前記パター
ンの発生毎に、前のバイトがゼロバイトであったこと、続くバイトが前記チャン
ネル形式に対し正当なものであること、及び、前記発見された０×０００×０
１パターンに続く３つのバイトが全てゼロでないことを判定する段階と、スタートコード毎に、スタートコードオフセットの受け渡しリストにエン
トリを加える段階とから成り、前記処理バッファにおける全てのスタートコード
の順序付けされたリストがオフセットアレーの限界まで生成されるようにした段
階を、ループ化した状態で前記処理バッファが完全に使い尽くされるまで実行す
ることを特徴とする方法。
【請求項２０】前記ゼロワード範囲内に０×０００×０１の配列ワード
があるとすればその全ての処理が完了した時、現在のゼロワード範囲が前記処理
バッファの終端に達しているかどうかを判定する段階、現在のゼロワード範囲が前記処理バッファの終端に達している場合、呼び出し
側に返答する段階、現在のゼロワード範囲が前記処理バッファの終端に達していない場合、前記現
在のゼロワード範囲の端部を定めるスタートコードを示す前記パターンのオフセ
ットを、前記スタートコードオフセットのリストに加える段階、前記現在のゼロワード範囲のゼロワードに続くワードに、前記スタートポイン
タを設定する段階、及び次の繰り返しを行なう段階を更に含むことを特徴とする請求項１９に記載の方
法。
【請求項２１】前記オフセットアレーの構成要素よりも多くのスタートコ
ードが前記処理バッファ内に存在する可能性がある場合、処理バッファオフセッ
トを、最後に発見されたスタートコードオフセットに続くワードとなるように設
定することによって、前記各段階を前記処理バッファに対して繰り返すことがで
きるようにしたことを特徴とする請求項１９及び２０のいずれかに記載の方法。
【請求項２２】呼び出し時、前記処理バッファに対するポインタ、実際に
処理されるサブバッファの開始点を表す前記処理バッファへの任意のオフセット
、前記処理バッファの長さ、発見された全てのスタートコードの前記処理バッフ
ァへのオフセットが記憶されるスタートコードアレーに対するポインタ、前記ス
タートコードアレー内の構成要素数、前記データストリームが音響チャンネルか
ビデオチャンネルかを示すフラグ、及びバッファ終端トリミングを実行すべきか
否かのフラグが受け渡されることを特徴とする請求項１９乃至２１のいずれかに
記載の方法。
【請求項２３】バッファ終端をトリミングする段階を更に含み、前記バッ
ファ終端をトリミングする段階は、前記処理バッファ終端の特定バイトパターンの最長アレーを探す段階、及び前記特定バイトパターンが検出された場合、前記特定バイトパターン終端のバ
イトを取除くように前記処理バッファの長さを減少する段階を含むことを特徴と
する請求項１９乃至２２のいずれかに記載の方法。
【請求項２４】前記バッファのサイズが、バッファ終端トリミング後の初
期オフセットによって増加されたとすれば、そのサイズが６バイト未満であるか
どうかを判定する段階、及び前記サイズが６バイト未満である場合、現在のサイズを減少したバッファにス
タートコードは存在しないことを呼び出し側に返答する段階を更に含むことを特
徴とする請求項２３に記載の方法。
【請求項２５】データストリームにおけるスタートコードの位置を探し出
すための方法であって、処理バッファのワードによる走査を実行し、最初のスタートコードを確認する
段階、前記最初のスタートコードに関するオフセット値を記憶する段階、前記最初のスタートコードに基づきゼロワード範囲を設定する段階、前記ゼロワード範囲内を走査し、他のスタートコードを確認する段階、及び前記最初のスタートコードとともに前記他のスタートコードに関するオフセッ
ト値を順次記憶する段階を含むことを特徴とする方法。
【請求項２６】前記最初のゼロワード範囲の端部で始まる他のゼロワード
範囲を設定する段階、及び前記バッファが使い尽くされるまで、前記他のゼロワード範囲の各々にあるス
タートコードを確認して記憶する段階を含むことを特徴とする請求項２５に記載
の方法。
【請求項２７】データストリームにおけるスタートコード走査のための装
置であって、入力バッファ、及びワードによる方法で前記入力バッファを走査し、ワード境界を確認するための
スキャナを備え、前記スキャナは、最初のスタートコードを確認するために前記
入力バッファを走査するとともに、現在の走査の開始点から前記最初のスタートコードまでの範囲を持つゼロワー
ド範囲を設定する手段、及び前記最初のスタートコードに対するオフセットを記憶するためのキャッシュを
備え、前記スキャナは、前記ゼロワード範囲における他のスタートコードを確認する
ためにこの範囲内で走査し、前記キャッシュは、前記最初のスタートコードとともに前記他のスタートコー
ドに関するオフセットを順次記憶し、更に前記最初のゼロワード範囲が前記入力バッファの下位集合である場合には、次
のゼロワード範囲を定める手段を備え、前記入力バッファ内の全てのスタートコードが確認され、前記スタートコード
に関するオフセットが順次記憶されるまで動作を継続するようにしたことを特徴
とする装置。
【請求項２８】データストリームにおけるスタートコードの位置を探し出
すための装置であって、処理バッファ、前記処理バッファ内のスタートポインタ、及びプロセッサを備え、前記プロセッサは、前記スタートポインタによって指された初めからｎ番目までのバイトが全
てゼロである場合、最初の非ゼロワードの位置を探し出す段階と、前記バッファの終端に到達した場合、呼び出し側に返答する段階と、前記バッファの終端に到達していない場合には、ゼロワード走査を終了し
た前記非ゼロワードより１だけ少ないワードに前記スタートポインタを設定する
段階と、最初のワード配列ゼロワードを検出するために走査する段階とから成る各
段階を、前記処理バッファが完全に使い尽くされるまで実行し、前記最初のゼロワードが検出された場合、前記スキャナは、後続のバイトが１
の値のバイトであること、前記１のバイトに続くバイトが処理されているチャン
ネル形式に対して正当であること、及び、前記１のバイトに続く３つのバイトが
全てゼロでないことを確認し、前記最初のゼロワードが検出されない場合、前記スキャナは、前記処理バッフ
ァの終端でない限り、次のゼロワードを探し、スタートコードが発見された場合又は走査が前記処理バッファの終端にある場
合、前記スキャナは、前記スタートポインタから、前記発見されたスタートコー
ドの位置又は前記処理バッファの終端までの前記処理バッファの領域をゼロワー
ド範囲として確認し、且つ前記スキャナは、前記ゼロワード範囲の二番目のワードから始めて、スタート
コードを示す０×０００×０１のワード配列パターンについて前記ゼロワード
範囲を再走査し、更に前記ゼロワード範囲において検出されたスタートコードを示す前記パターンの
発生毎に、前のバイトがゼロバイトであったこと、続くバイトが前記チャンネル
形式に対し正当なものであること、及び、前記発見された０×０００×０１ワ
ードに続く３つのバイトが全てゼロでないことを判定する手段、及びスタートコード毎に、スタートコードオフセットの受け渡しリストにエントリ
を加える手段を備え、前記処理バッファにおける全てのスタートコードの順序付けされたリストがオ
フセットアレーの限界まで生成されるようにしたことを特徴とする装置。
【請求項２９】前記ゼロワード範囲内にスタートコードを示す前記パター
ンがあるとすればそのパターン全ての処理が完了した時、現在のゼロワード範囲
が前記処理バッファの終端に達しているかどうかを判定するとともに、現在のゼ
ロワード範囲が前記処理バッファの終端に達している場合、呼び出し側に返答し
、現在のゼロワード範囲が前記処理バッファの終端に達していない場合、前記
現在のゼロワード範囲の端部を定めるスタートコードを示す前記パターンのオフ
セットを、前記スタートコードオフセットのリストに加える手段、前記現在のゼロワード範囲のゼロワードに続くワードに、前記スタートポイン
タを設定する手段、及び次の繰り返しを行なう手段を更に含むことを特徴とする請求項２８に記載の装
置。
【請求項３０】前記オフセットアレーの構成要素よりも多くのスタートコ
ードが前記処理バッファ内に存在する可能性がある場合、処理バッファオフセッ
トを、最後に発見されたスタートコードオフセットに続くワードとなるように設
定する手段を更に備えたことを特徴とする請求項２８及び２９のいずれかに記載
の装置。
【請求項３１】前記装置のオペレーション開始時、前記処理バッファに対するポインタ、実際に処理されるサブバッファの開始点を表す前記処理バッファへの任意のオ
フセット、前記処理バッファの長さ、発見された全てのスタートコードの前記処理バッファへのオフセットが記憶さ
れるスタートコードアレーに対するポインタ、前記スタートコードアレー内の構成要素数、前記データストリームが音響チャンネルかビデオチャンネルかを示すフラグ、
及びバッファ終端トリミングを実行すべきか否かのフラグが受け渡されることを特
徴とする請求項２８乃至３０のいずれかに記載の装置。
【請求項３２】バッファ終端をトリミングするためのモジュールを更に備
え、前記モジュールは、前記処理バッファ終端の特定バイトパターンの最長アレーを探すための手段、
及び前記特定バイトパターンが検出された場合、前記特定バイトパターン終端のバ
イトを取除くように前記処理バッファの長さを減少するための手段を有すること
を特徴とする請求項２８乃至３１のいずれかに記載の装置。
【請求項３３】前記特定バイトパターンが前記処理バッファの終端に一致
しない限り動作を継続する手段、初期オフセットを考慮に入れて、前記処理バッファの現在の長さが、６バイト未
満であるかどうかを判定する手段を備え、前記長さが６バイト未満である場合、
前記スキャナは、作動を終了して前記バッファでスタートコードが検出されなか
ったことを呼び出し側に返答し、且つ前記処理バッファの現在の長さが奇数である場合、前記処理バッファ長さを減
少させて偶数にするための手段を更に備えたことを特徴とする請求項３２に記載
の装置。
【請求項３４】データストリームにおけるスタートコードの位置を探し出
すための装置であって、処理バッファのワードによる走査を実行し、最初のスタートコードを確認する
ためのプロセッサ、及び前記最初のスタートコードに関するオフセット値を記憶するためのキャッシュ
を備え、前記プロセッサは、前記最初のスタートコードに基づき最初のゼロワード範囲
を設定するとともに、前記プロセッサは、前記最初のゼロワード範囲内を走査し、他のスタートコー
ドを確認し、且つ前記キャッシュは、前記最初のスタートコードとともに前記他のスタートコー
ドに関するオフセット値を順次記憶することを特徴とする装置。
【請求項３５】ＭＰＥＧ−２データストリームをデコードするための方法
であって、特徴のシーケンスを含む入力ＭＰＥＧ−２データストリームの固定長
サンプルを取込む段階、対応する前記特徴のシーケンスの各々の形式及び長さを特徴付ける個別の記述
子を含む記述子アレーを作る段階、及び各固定長サンプルを、それに対応する前記記述子アレーの１つとともに後続の
ＭＰＥＧ−２デコード段階に転送する段階を含み、前記後続のＭＰＥＧ−２デコード段階では、前記入力ＭＰＥＧ−２データスト
リームを構文解析するタスクが省略されることを特徴とする方法。
【請求項３６】前記固定長サンプル内の特定の特徴を、前記固定長サンプ
ルが他のＭＰＥＧ−２デコード段階に受け渡される前に、増す及び／又は減少す
る段階、及び前記特定の特徴の各々に対応する前記記述子アレー内の記述子を修正し、前記
記述子がその対応する前記特定の特徴を正確に特徴付けるように維持する段階を
更に含むことを特徴とする請求項３５に記載の方法。
【請求項３７】前記サンプルの走査に並行して、対応する記述子の各々に
特徴付けられる各特徴の長さを連続的に増加するオフセットカウンタを維持する
段階を更に含むことを特徴とする請求項３５及び３６のいずれかに記載の方法。
【請求項３８】特徴のシーケンスを含む入力ＭＰＥＧ−２データストリー
ムを受信するとともに、固定長ＭＰＥＧ−２サンプル及び対応する前記特徴のシ
ーケンスの各々の形式及び長さを特徴付ける個別の記述子を含む記述子アレーを
出力するように接続された事前パーサを備えたことを特徴とするＭＰＥＧ−２シ
ステム。
【請求項３９】固定長ＭＰＥＧ−２サンプル及び前記事前パーサからの記
述子アレーの両方を受信するように接続され、前記記述子アレーに含まれた複数
の対応する長さの特徴及び形式の特徴に基づいて、前記ＭＰＥＧ−２サンプルを
デコードする第一段階フィルタを更に備えたことを特徴とする請求項３８に記載
のＭＰＥＧ−２システム。
【請求項４０】第一ＭＰＥＧ−２サンプル及び前記事前パーサからの第一
記述子アレーを受信するように接続され、前記記述子アレーに含まれた複数の対
応する長さの特徴及び形式の特徴に基づいて、前記第一ＭＰＥＧ−２サンプルを
順次デコードする第一段階フィルタ、及び第二ＭＰＥＧ−２サンプル及び前記第一段階フィルタからの第二記述子アレー
を受信するように接続され、前記第二記述子アレーに含まれた複数の対応する長
さの特徴及び形式の特徴に基づいて、前記第二ＭＰＥＧ−２サンプルを順次デコ
ードする第二段階フィルタを更に備えたことを特徴とする請求項３８に記載のＭ
ＰＥＧ−２システム。
【請求項４１】ＭＰＥＧ−２データストリームを非圧縮化する方法であっ
て、ＭＰＥＧ−２データストリームを、動きベクトルデータストリーム及び係数デ
ータストリームに分離する段階、予測フレームが後続の予測での参照フレームとして使用される場合に丸め誤差
を作り出す２段階１／２画素予測プロセスを、前記動きベクトルデータストリー
ム上で使用する段階、及び前記係数データストリームを、逆離散コサイン変換段階に入力する前に、記憶
フレームにおけるポンピングアーチファクトが排除されるように修正する段階を
含むことを特徴とする方法。
【請求項４２】前記修正する段階は、前記離散コサイン変換段階で、動き
ベクトル計算器から出力された垂直動きベクトル成分ｈ₁及び水平動きベクトル
成分ｈ₀に基づき修正されたＤＣ係数を受信するようにしたことを特徴とする請
求項４１に記載の方法。
【請求項４３】前記修正する段階は、前記離散コサイン変換段階で、前記
垂直動きベクトル成分ｈ₁及び前記水平動きベクトル成分ｈ₀の両者が、ＭＰＥＧ
−２１／２画素補間ケース−Ｄの状態を示す場合、定数によって修正されたＤＣ
係数を受信するようにしたことを特徴とする請求項４２に記載の方法。
【請求項４４】可変長デコーダ、ランレングスデコーダ及び逆量子化を用
いて、前記係数データストリームからＤＣ係数及び複数のＡＣ係数を引き出す段
階、逆離散コサインを変換する段階、前記変換する段階の前に、前記ＤＣ係数に定数を加える段階、及び前記動きベクトルデータストリームからの動きベクトルを計算し、垂直動きベ
クトル成分ｈ₁及び水平動きベクトル成分ｈ₀を生成する段階を更に含み、前記垂直動きベクトル成分ｈ₁及び前記水平動きベクトル成分ｈ₀のいずれの論
理積も正しい場合、前記加える段階では、マイナス３の定数が前記ＤＣ係数に加
えられ、そうでない場合には、ゼロの定数が加えられることを特徴とする請求項
４１乃至４３に記載の方法。
【請求項４５】前記加える段階では、前記変換する段階のために、２段階
予測によって計算された一連の予測画素に対する補正項を含む新しいＤＣ係数が
形成されることを特徴とする請求項４４に記載の方法。
【請求項４６】ＭＰＥＧ−２データストリームを、動きベクトルデータス
トリーム及び係数データストリームに分離するためのヘッダーパーサ、前記動きベクトルデータストリームを受信するように接続され、且つ、垂直動
きベクトル成分ｈ₁及び水平動きベクトル成分ｈ₀を提供するための動きベクトル
計算器、前記係数データストリームを受信するように接続され、且つ、可変長デコーダ
、ランレングスデコーダ及び逆量子化ユニットを用いてＤＣ係数及び複数のＡＣ
係数を引き出す係数デコーダ、前記動きベクトル計算器から動きベクトル出力を受信するように接続され、且
つ、予測フレームが後続の予測での参照フレームとして使用される場合に生じる
丸め誤差を有する予測フレームを提供する２段階１／２画素予測プロセッサ、前記ＤＣ係数と前記垂直動きベクトル成分ｈ₁及び前記水平動きベクトル成分
ｈ₀とを受信するように接続されるとともに、前記ＤＣ係数を修正するために設
けられ、前記垂直動きベクトル成分ｈ₁及び前記水平動きベクトル成分ｈ₀に依存
する修正ＤＣ係数を生成する論理ユニット、前記論理ユニットからの前記修正ＤＣ係数及び前記係数デコーダからの複数の
ＡＣ係数を受信するように接続された逆離散コサイン変換器、及び前記２段階１／２画素予測プロセッサと逆離散コサイン変換器との出力を合計
する加算器を備え、前記ＤＣ係数が、前記逆離散コサイン変換器に入力する前に、前記２段階１／
２画素予測プロセッサにおいて生じた丸め誤差によって引き起こされる前記フレ
ームにおけるポンピングアーチファクトが排除されるように修正されることを特
徴とするＭＰＥＧ−２デコーダ。
【請求項４７】前記論理ユニットは、前記垂直動きベクトル成分ｈ₁及び
前記水平動きベクトル成分ｈ₀のいずれもが正しい場合、前記加算器が、マイナ
ス３の定数を使用してそれを前記ＤＣ係数に加え、そうでない場合には、ゼロの
定数を加えるようにすることを特徴とする請求項４６に記載のＭＰＥＧ−２デコ
ーダ。
【請求項４８】前記論理ユニットは、前記修正ＤＣ係数が、前記２段階１
／２画素予測プロセッサによって計算された一連の予測画素に対する補正項を含
むようにすることを特徴とする請求項４６又は４７に記載のＭＰＥＧ−２デコー
ダ。