JP4448334B2

JP4448334B2 - バイト整列されていない（ｎｏｎ−ｂｙｔｅ−ａｌｉｇｎｅｄｐｏｓｉｔｉｏｎｓ）のポジション、および／またはビット・シフトされたポジション（ｂｉｔ−ｓｉｆｔｅｄｐｏｓｉｔｉｏｎｓ）を含む位置におけるスタート・コード・エミュレーションを防ぐための方法およびシステム

Info

Publication number: JP4448334B2
Application number: JP2003587115A
Authority: JP
Inventors: ジェイ．サリバンゲアリー
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2002-04-19
Filing date: 2003-04-18
Publication date: 2010-04-07
Anticipated expiration: 2023-04-18
Also published as: JP2005523659A; KR20040099461A; US20040030665A1; TW200404229A; HK1075565A1; EP1500278A2; US7248740B2; WO2003090470A2; KR100895932B1; WO2003090470A3; CN1656821A; CN100499824C; EP1500278B1; TWI310137B

Description

本発明は、スタート・コード・エミュレーション（start code emulation）およびデータのスタッフィング（data stuffing）を防ぐための方法およびシステムに関する。

デジタル・データは通常、ある種類の送信機からある種類の受信機に送信される。送信機は通常、送信用のデータをエンコードするエンコーダを含み、受信機は通常、受信するデータをデコードするデコーダを含んでいる。デジタル・データには、ビデオ・データ、オーディオ・データ、オーディオ／ビデオ・データ、テキスト・データ、コンピュータ実行可能プログラム・データ、アーカイブ・データ、データベース情報など、さまざまな種類がある。デジタル・データが送信される場合、通常はある種類のチャネルで送信される。同等に、コンピュータ・メモリまたは任意の記憶装置あるいは記憶媒体は、本明細書の目的に適った伝送チャネルと見なすことができる。

デジタル・データが送信される場合、チャネルにおけるデータ内の特定のポイントを見つけられることが重要である。これは、チャネル経由の、データの送信時のエラーまたは損失（loss）からの回復（recovery：正常に戻ること）を可能にするポイント、ストリーム全体の先頭以外の位置においてデコード・プロセスを開始できるポイント、またはさまざまな目的に使用されるデータの各種タイプの検索を可能にするポイント、を見つけ出すなどのような多種多様な目的のために行われる。したがって、たとえば、デコーダ側において、デコーダおよびデジタル・データを処理するその他のコンポーネントは多くの場合、データが適切に処理されるようにデータのコンテクストを認識しておく必要がある。このことは、送信された第１ビットで開始することができ、デコーダがエラーを全く生じることなく実行できる場合には、さほど重要にはならないであろう。この状況においては、単にデータのフォーマットが何であるかを知ることにより送信された情報をデコーダが追跡できることが理想的である。残念なことに、この理想的な状況は頻繁に発生するものではない。エラーその他の不測の事態は確実に発生し、これは、デジタル・データを送受信するシステムを設計し、使用する人々に対して課題を提供する。データのブロードキャスト・ストリームを、それが進行中において受信するような、いくつかの場合に、デコーダは、データ送信の最初の時点で、起動することができないこともある。データ・フォーマットの解析によってポイントを突き止めるには、デコーダにおいて膨大量の複雑な処理が必要になることもある。

多くの種類のチャネル環境において、そのような問題は、データにいわゆる再同期マーカーを提供することによって対処される。再同期マーカーは、システムがそのデコード・プロセスを開始したり、エラーから回復したり（recover）することができる機構を提供する。たとえば、デジタル・データが一連のビットまたはバイトとしてストリーミングされる場合、ストリーム内に再同期マーカーを備えることで、送信時にエラーが発生したときに、そこから回復する（recover）参照ポイントをデコーダにもたらすことができる。

再同期マーカーが採用されることになる方法の一つは、スタート・コードのコンテクストの中にある。スタート・コードは、固有値を持つ複数のビットまたは複数のバイトのストリングである。一般に、多くのシステムはバイトを保持する傾向にあるため（たとえばＨ．２２２．０／ＭＰＥＧ−２システム）、スタート・コードは一意の値をとるバイトのストリングとして定義することができる。一意のバイトのストリングは、その存在が再同期ポイントを示すパターンを提供する。再同期ポイントは通常、単独に（独立して）デコード可能な量のデータの先頭または境界を示す。たとえば、Ｈ．２６２／ＭＰＥＧ−２ビデオ・データにおいて、再同期ポイントは、スライス（つまり単独でデコード可能なピクチャの領域）の開始、ピクチャの開始、ＧＯＰ（つまり「ピクチャのグループ」または単独でデコード可能なピクチャのシーケンス）の開始、または新しいビデオ・シーケンスの開始を示すことができる。デジタル・ビデオ・ストリームは、また、スタート・コードを先行させたいわゆる付属（ancillary data）または補足データ（supplemental data）を含めることができる。

場合によっては、スタート・コードはビデオ・ストリームのようなデータ・ストリーム内だけでなく、システムの多重レベルによっても使用される。Ｈ．２２２．０／ＭＰＥＧ−２Ｓｙｔｅｍ仕様は、スタート・コードを使用し、システム・レベル情報およびオーディオ情報でインターリーブされたビデオ・データのストリームを搬送するシステムの例である。

スタート・コードは、データ・ストリーム内の再同期ポイントを提供する限りにおいて重要となり得るため、実際にスタート・コードを表すよう意図していない位置のデータ・ストリームにおいてスタート・コードをエミュレートすることを回避することが望ましい。

たとえば、次のような状況を考察する。スタート・コードは、新しいデータの単位の開始を識別できるビットまたはバイトの固有のパターンを定義する。その複数のスタート・コードの間に任意のデータを送信している場合、任意のデータはスタート・コードとして使用しているものと同じパターンをその中に含むことがありうる。たとえば、搬送されているデータが完全にランダムであると仮定した場合、スタート・コードの長さがＫビットであれば、一部の特定のビット・ロケーション（ビット位置）において開始するビットにスタート・コードを偶然にエミュレートする確率は１／２^ｋである。

場合によっては、スタート・コード内のビット数が大きければ、スタート・コードが偶然にエミュレートされる可能性はかなり低いと判断することができる。そのような状況において、偶然のスタート・コード・エミュレーションの影響があまり重大ではない場合、偶然のスタート・コード・エミュレーションを確実に防止する処置をとることは不要であると判断されてよい。これは、一部のオーディオ・データ・フォーマットに関する状況である。通常、これらのフォーマットは、毎秒ビットで測定される非常に高いビットレートは使用しないため、スタート・コードが特定の時間間隔で偶然にエミュレートされる可能性はあまり高くない。ビデオ・データについて言えば、ビデオ・データの伝送の場合、ビットレートは通常これよりはるかに高いため、このことは一般に当てはまらない。

（おそらくは１つだけを例外として）従来の主要なビデオ・コーディング規格では、データ・ペイロード内のビデオ構文フォーマットはスタート・コードのエミュレーションを防ぐように設計されてきた。つまり、どのような種類のデータ要素がビデオ構文を構成するか分かっている場合、偶然のスタート・コードが発生しないように構文を注意深く設計することができる。たとえば、従来のビデオ・コーディング規格のスタート・コードは、後に１のビットが続く０のビットの長ストリングで開始する。この長ストリングは、後に１つの１のビットが続く２３の０のビットを含む。送信されるデータのほとんどが、可変長コード（ハフマン符号と略称されることが多い）を使用してエントロピー・コーディングされると仮定する。可変調コード（ＶＬＣ）は、本明細書において例示のため、表された記号のセットから選択するために使用される可変深さのツリー構造のコードとして定義される。バイナリ・ツリーＶＬＣを使用する１つの技法は、有効なシンボルを表すルートからすべてのリーフまでのツリー内のパスが、そのどこかに常に「１」を持ち、しかもツリー構造が深すぎないことを確認することである。

したがって、たとえば、すべての可変長コード・ストリングが１０ビット以下の長さであり、そのようなストリングがすべてその中に少なくとも１つの１の値をとるビットを持つことが分かっている場合、ＶＬＣからのコーディングされたデータのシーケンスが連続するゼロの値をとるビットを１８よりも多く含む可能性はないことが分かる。つまり、最悪のシナリオは、０００００００００１が後に続く１０００００００００であろう。したがって、構文（syntax）を注意深く設計し、すべての０および１の値を持つビットの位置を検査して行（row）内で発生しうる０の数を突き止めるならば、構文内でそれまで発生したものよりも長い０のストリングを含むスタート・コードを使用することができる。たとえば、構文（syntax）を、スタート・コードではない場所に有効な構文が２３個の０を決して含められないように、設計することができる。したがって、２３個の０の発生はすべてスタート・コードであり、デコーダは正確にスタート・コードを検出できるはずである。

上記の操作（operation）は単純に見えるが、その操作を実行することは、スタート・コード・パターンが偶然に送信されないことを確実にするため、送信される可能性のあるすべてのデータを（ビット・レベルで）、送信される可能性のあるすべての順序で検査する必要があるため、かなり困難な取り組みとなる可能性がある。これは、間違いを生じやすい、困難な構文設計の方法である。

このビット・レベルの検査の設計プロセスは、一般に、過去において、多くのビデオ・コーディング仕様が従来設計されてきた方法（つまり、Ｈ．２６１、ＭＰＥＧ−１、Ｈ．２６２／ＭＰＥＧ−２、ほとんどのＨ．２６３、およびＭＰＥＧ−４）を説明している。その１つの例外は、ＩＴＵ−Ｔ勧告Ｈ．２６３の付録Ｅである。これは算術コーディングと呼ばれる手法を使用して、数学的仕様からアルゴリズム的に圧縮されたビットを生成する。ここで、生成されたビットを検査するエントロピー・エンコーダの最後に、付加的なプロセス（extra process）があり、エンコーダ側で、行内の０が多すぎる場合に、あらかじめ決められた０の数に達する前に、「マーカー」ビット（１のビット）が挿入される。デコーダ側では、デコーダがゼロを総計し、ゼロの数がクリティカルな水準に達した場合に、実際のスタート・コードが発生したことを認識する。デコードは、クリティカルな水準よりもゼロが１つ少ないことを検出した場合、その後に続く１ビットはスタート・コード・エミュレーションを防ぐために挿入されたマーカー・ビットであることを認識し、そのビットを廃棄して、その次のビットを実際のデータの継続と見なす。

この解決策での問題は、エンコーダおよびデコーダにビット・レベルで着信データを検査させ、処理させるという点にある。処理中のデータの位置を単一のビット・ポジションごとに、分析してシフトすることは困難になり、デコーダに望ましくない重い負担をかける可能性がある。ビット単位のシフトは、プロセッサの負荷が高い操作（processor-intensive operation）でもある。
参考文献Gary Sullivan「On Random. Access and Bitstream Format for JVT Video」JVT-B063（２００２年１月）は、スタート・コードとスタート・コード・エミュレーション防止を説明する。このスタート・コード・エミュレーション防止は「バイト指向の方式」での処理を使用し、「ペイロード・データのＮ＋１バイトの文字列が、全スタート・コード・プレフィックスにマッチしている場合、あるいはスタート・コード・プレフィックスの最初のＮのバイト＋エミュレーション・防止バイトの値にマッチしている場合、エミュレーション・防止データの１バイト」（JVT-B063のpage 3）を挿入すること含んでいる。

したがって、本発明は、スタート・コード・エミュレーションを防止するための改善された方法およびシステムを提供することに関連付けられた懸念事項に端を発したものである。

ビット・レベルよりも高度のグラニュラリティ・レベルで実行される操作（operation）による、スタート・コード・エミュレーション防止の手法を提供する方法およびシステムについて説明される。ビット・レベル以外のレベルで操作することにより、処理効率を高めることができる。１つまたは複数の実施例に従い、スタート・コード・エミュレーション防止の方法は、シングル・ビットよりも大きい固定サイズのデータ部分に関連してデータ・パターンを探す。特定のパターンが見つかった場合、スタート・コード・エミュレーションを防ぐために、スタート・コード・エミュレーション防止データが挿入される。挿入されるデータはシングル・ビットよりも大きく、一部の実施例においては、１バイトで構成されている。デコーダは、スタート・コード・エミュレーション防止データが挿入されているデータをデコードすると、正規のスタート・コードを容易に識別することができ、スタート・コード・エミュレーション防止データを削除して搬送の対象となっていた元のデータを提供することができる。

さまざまな実施例において、スタート・コード・エミュレーション防止を行うことができ、それは、バイト境界のようなデータ境界以外の位置でのスタート・コード値の偶然のエミュレーションを防止する。これらの実施例は、処理されるデータのデータ整列境界（data alignment boundaries）を必ずしも保持しないシステムと関連して、使用することができる。一部のシステムでは、前述の技法は、データ境界が失われた場合にデコーダ・システムが回復できる基盤（basis）をもたらすことができる。

さらに、ペイロード・データを整数値のバイト・サイズに大きさを切り上げて、デコーダが容易に検出できる方法で、フィラー・データを追加することができるデータ・スタッフィング方法について説明される。

概要
以下に説明される方法およびシステムは、ビット・レベルよりも高度のグラニュラリティ・のレベルでのスタート・コード・エミュレーション防止の手法を提供する。ビット・レベルよりも高度のレベルで操作することにより、処理効率を高めることができる。本明細書に照らして、ビット・レベルよりも高いレベルで操作するということは、単一ビットよりも大きい固定サイズのデータ部分に関連してデータ・パターンを探すプロセスに注目させることを意図している。たとえば、固定サイズのデータ部分は、バイト（つまり８ビット）、「ワード」（つまり１６ビット）、「ダブル・ワード」（つまり３２ビット）などを含むことができる。したがって、本発明の技法は、バイト、ワードなどの中のパターンを探すことができる。

さらに、ペイロード・データを、バイト量などの、データ単位サイズの整数倍に大きさを切り上げることができ、およびデコーダが容易に検出できる方法でフィラー・データ（filler data）を追加することができる、データ・スタッフィング方法について説明される。

さまざまな実施例において、スタート・コード・エミュレーション防止を行うことができ、それは、バイト境界のようなデータ境界以外の場所でのスタート・コード値の偶然のエミュレーションを防止する。これらの実施例は、処理されるデータのデータ整列境界を必ずしも保持しないシステムと関連して、使用することができる。一部のシステムでは、前述の技法は、データ境界が失われた場合にデコーダ・システムが回復できる基盤（basis）をもたらすことができる。

さらに、以下に示される例はビデオ・データに関連して説明されているが、本発明の技法は、通常エンコードされたり、デコードされたりするすべてのタイプのデータ、および、それに関してスタート・コード・エミュレーション防止が望ましいかまたは必要である、タイプのデータに関連して採用することができることを理解されたい。そのようなデータの例には、オーディオ・データ、オーディオ／ビデオ・データ、などが含まれる。

図１は、１つの実施例による方法のステップを説明する流れ図である。この方法は、適切なハードウェア、ソフトウェア、ファームウェア、またはそれらの組合せで、実施することができる。図を使用して説明されている実施例において、その方法は、ソフトウェアで、少なくとも一部が実装される。さらに読者は、この方法が、１つの指定された「エンコーダ」と１つの指定された「デコーダ」という、２つの異なる分岐を持つものとして示されていることに留意されたい。「エンコーダ」の分岐は、エンコーダによって、またはエンコーダと関連して実行されるステップを表している。同様に、「デコーダ」の分岐は、デコーダによって、またはデコーダと関連して実行されるステップを表している。

ステップ１００において、スタート・コードの後に送信することを意図したデータ量が取得または生成される。データは、任意の適切なデータを含むことができる。そのようなデータのタイプの例には、ビデオ・データ、オーディオ・データ、オーディオ／ビデオ・データなどの量が含まれるが、これらに限定されることはない。ステップ１０１において、データの前にスタート・コードがつけられる。このステップは、ステップ１００において取得または生成されたデータに、スタート・コードを効果的に追加する。ステップ１０２において、固定サイズ・データ部分の１つまたは複数のパターンを求めて着信データが検査または検索される。図を使用して説明されている実施例において、検索されるパターン（複数の場合もある）は少なくとも２つの固定サイズのデータ部分を含み、個々の各データ部分は少なくとも２ビットを含む。ステップ１０４において、パターンが見つかったかどうかが決定される。パターンが見つからなかった場合、この方法はステップ１０８に分岐し、そこでデータが送信される。

それに対して、パターンが見つかった場合、ステップ１０６において、パターンを含むデータに関連してスタート・コード・エミュレーション防止データが挿入される。図を使用して説明されている実施例において、スタート・コード・エミュレーション防止データの個々のインスタンス（実際例）は、１ビット以上を含んでいる。スタート・コード・エミュレーション防止データは、個々の固定サイズ・データ部分にビット数が等しいデータ量を含むことが望ましい。したがって、固定サイズ・データ部分が８ビット（バイトと呼ばれるデータの量）から構成される場合、スタート・コード・エミュレーション防止データは８ビットより構成される。スタート・コード・エミュレーション防止データが挿入された後、ステップ１０８において、データが送信される。ステップ１１０において、次のスタート・コードの前に送信すべき追加データがあるかどうか決定される。追加データがある場合、方法はステップ１０２に戻り、前述のように進行する。追加データがない場合、方法は、ステップ１１１において、送信する追加データがあるかどうかを決定できる。追加データがある場合、方法はステップ１００に分岐して戻る。追加データがない場合、方法は、ステップ１１２において、終了することができる。

論題はそれるが、次のような状況を考察する。この特定の技術の使用の一例が、スタート・コードを「スタート・コード・プレフィックス」と「スタート・コード・タイプ」サフィックスに分割するものであることに留意されたい。ここでプレフィックスは単一の固有の値のストリングで、サフィックスはスタート・コードの後に続くデータのタイプを示している。特に、これはＭＰＥＧ−２スタート・コードの構造である。プレフィックス／サフィックス構造を特殊事例として含む使用のさらに一般的な形態は、１つまたは複数のスタート・コード・パターンを備える汎用概念である。その結果、１つまたは複数のエミュレーション防止パターンを有することもできる。さまざまなスタート・コード・パターンがさまざまなエミュレーション防止パターンと区別され、すべてのスタート・コード・パターンがペイロード・データの処理において回避される限り、この方式は適切に機能する。さらに、必ずしも、スタート・コード・パターンがすべて同じ長さであると想定する必要はない。

デコーダ側において、次のような状況を考察する。スタート・コード・エミュレーション防止データがエンコーダによって挿入された後、他のデータの適切な解釈のために、あるポイントにおいてこれを識別し、削除または無視することができる。さらに、デコーダが送信されたデータを受け取る際に、正規のスタート・コードを探すことができると考える。デコーダが正規のスタート・コードを見つけると、データ境界を定義したスタート・コードが位置する場所を認識する。ここで、デコーダは、実際のデータをさらに処理できるように、スタート・コード・エミュレーション防止データを探して削除することを続行することができる。

具体的には、ステップ１１４において、スタート・コードのエミュレーションを回避するエンコーダによって、処理された送信データが受け取られ、ステップ１１８において、スタート・コードを見つけるためにデータが処理される。スタート・コードが見つけられて適切に処理される（たとえば、読み取られて廃棄される）と、ステップ１２０において、スタート・コード・エミュレーション防止データを識別するためにデータが検索される。スタート・コード・エミュレーション防止データが見つかると、ステップ１２２において、スタート・コード・エミュレーション防止データが削除される。スタート・コード・エミュレーション防止データが削除されると、データは、受信したデータのタイプに特有な方法で処理することができる。たとえば、データは、ステップ１２４に示されているように、消費者の装置によって消費することができる。

第１の例示的な方法
以下に説明する方法は、図１に示して説明した方法の１つの具体例を表している。以下に説明する方法において、ペイロード・データのＮ＋１バイトのストリングがスタート・コード・プレフィックス全体と一致するか、またはスタート・コード・プレフィックスの最初のＮバイトにエミュレーション防止バイトの値を加えたものと一致する場合には必ず、エミュレーション防止データのバイトが挿入される。この方法は、「第２の例示的な方法」の項目で説明されている方法に比べてデータを追加する頻度が低いため、ペイロード・データを送信するための送信能力の要件が軽減される。
「発明が解決しようとする課題」で言及された、参考文献「JVT-B063」は、その第１の例示的なあるインプリメンテーションについての詳細を提供する。

ＭＰＥＧ−２のスタート・コード・プレフィックス構造は、バイト整列されたポジション（byte-aligned position）において開始し、２３個の０があり、その後に１が続く。このスタート・コード・プレフィックスは、以下のように表される。
０００００００００００００００００００００００１
この構造は、同じ値を持ついくつかの、Ｎ個のバイトと、その後に続く異なる値の別のいくつかのバイトで構成されるパターンとして、一般化することができる。ＭＰＥＧ−２において、Ｎ＝２、かつ最初の２バイトが０（以下で「Ｗ」と呼ぶ）、かつ最後のバイトが１（以下で「Ｘ」と呼ぶ）であると言うことができる。したがって、スタート・コード・プレフィックスは、次のパターンを持つ。
ＷＷＸ
これらの３つのバイトの後、ＭＰＥＧ−２では別のバイトが続き、それがどの種類のスタート・コードであるか識別する。この後に続くバイトを、「Ｙ」と呼ぶ。基本的に、スタート・コードはスタート・コード・プレフィックスＷＷＸと、その後に続くスタート・コードのタイプを識別するバイトＹで構成される。ＭＰＥＧ−２スタート・コード全体は、次のように表すことができる。
ＷＷＸＹ
スタート・コード・プレフィックス（ＷＷＸ）は固定値を持つが、Ｙはスタート・コードのタイプを示すいくつかの異なる値を持つ（たとえば、スライス、ピクチャ、ＧＯＰ、シーケンス、システムなど）。

１つの実施例によれば、データはパターンＷＷＸを探して処理される。ＷＷＸパターンが見つかった場合、スタート・コード・エミュレーションを防ぐためにスタート・コード・エミュレーション防止データが挿入される。ここで、スタート・コード・エミュレーション防止データは、ＷおよびＸバイトの値と区別される値を持つバイトＺを含んでいる。したがって、エンコーダがデータのバイトを検査してパターンＷＷＸを認識すると仮定する。データ内のこのパターンの検出に対応して、エンコーダは
ＷＷＺＸ
のパターンを提供するために、値Ｚを持つバイトを挿入する
この時点で、エンコーダは、デコーダによって送信されて処理されているペイロード・データが偶然にスタート・コードまたはスタート・コード・プレフィックスをエミュレートすることはないと確認している。ここで、次のような状況を考える。ペイロード・データには、ＷＷＸパターンを任意に含むことによってスタート・コード・プレフィックスをエミュレートする可能性があると同時に、そのペイロード・データがスタート・コード・エミュレーション防止データを含むデータを任意にエミュレートする可能性もある。つまり、ペイロード・データは本質的にパターンＷＷＺＸを含む可能性もある。もしこれに該当し、しかもエンコーダが何も行わなかった場合、デコーダがスタート・コード・エミュレーション防止データを削除しようと試みると、この場合実際のデータであるＺバイトを削除することになる。

したがって説明されている実施例において、エンコーダは、ペイロード・データがスタート・コードまたはスタート・コード・プレフィックスをエミュレートしないように構成されるだけではなく、スタート・コード・エミュレーション防止データの使用によって生じるデータ・パターンをデータがエミュレートないように構成される。具体的には、この例において、エンコーダがパターンＷＷＺを識別した場合、第２のＷとＺの間に値Ｚを持つバイトを挿入して、次のパターンを提供する（挿入されたバイトＺは以下に示されている最初のＺ）。
ＷＷＺＺ
ここで、処理されるデータについてデコーダの観点から考察する。デコーダが、後にＺまたはＸが続くＷＷＺで構成されるバイトのパターンを見つけると、最初のＺがエンコーダによって挿入されたエミュレーション防止バイトであることを認識する。したがって、デコーダは最初のＺを廃棄することができる。このようにして、この例においては、エミュレーション防止バイトを挿入できる２つの状況がある。第１の状況は、データがスタート・コードまたはスタート・コード・プレフィックスを偶然にエミュレートしてしまう場合である。第２の状況は、データが、エミュレーション防止バイトを挿入させたデータを偶然にエミュレートしてしまう場合である。

いずれの場合も、デコーダは単に、適切なパターンを探して、エミュレーション防止バイトを廃棄し、データを通常通りに処理することができる。

前述の処理をさらにプログラム的に説明するため、次のような状況を考える。エンコーダ側において、同じ値ＷのＮ以上のバイトおよび異なる値Ｘから成る最終バイトを含むスタート・コード・プレフィックスで始まり、その後に値Ｙを持つ１バイトの識別スタート・コード・タイプ・サフィックスが続く、ＢバイトのパケットＰ［］を送信するために、値Ｚを持つエミュレーション防止バイトを挿入する次の擬似コード・プロセス（ここでＷ、Ｘ、Ｙ、およびＺは相互に異なる値を持ち、Ｐ［Ｂ−１］はＷと等しくない）を操作する。ここで、チャネルを満たすために送信する付加的なデータ（extra data）の量はＥによって指定される。

上記の擬似コードにおいて、関数「ｓｅｎｄ＿ｂｙｔｅ（）」はデータの構成単位（unit）の送信を操作すると仮定される（図１のプロセス１０８を参照）。

デコーダ側において、パケットを受け取ると、同じ値ＷのＮ以上のバイトおよび異なる値Ｘの最終バイトから成る既知のスタート・コード・プレフィックスをデコーダが既に見つけて、読み取り、廃棄してしまったと仮定する。さらに、不明のシングル・バイトのスタート・コード・タイプ・サフィックスを変数Ｙに読み込み、ペイロード・データのパケットをアレイＰ［］に読み込んで、ペイロード・データの量を決定し、変数Ｂに量表示を入れて、その間に値Ｚを持つエミュレーション防止バイトを削除する、と仮定する（ここでＷ、Ｘ、Ｙ、およびＺは相互に異なる値を持ち、Ｐ［Ｂ−１］はＷと等しくない）。

上記の擬似コードにおいて、関数「ｒｅｃｅｉｖｅ＿ｂｙｔｅ（）」はデータの構成単位の受信を操作すると仮定され、関数「ｍｏｒｅ＿ｄａｔａ（）」は受信すべきデータの構成単位がさらにあるかどうかを決定すると仮定される（これらの２つの関数は図１のプロセス１１４に含まれる）。

前述の方法により、スタート・コードに先立って任意の量のＷ値のスタッフィングが可能になる。Ｗ値プレフィックスの数をＮに固定する公式化も同等に可能である。

第２の例示的な方法
以下に説明する方法は、図１に示して説明した方法のもう１つの具体例を表している。ここで方法は、ペイロードのデータのＮバイトのストリングが、後続のペイロード・データの値にはかかわりなく、スタート・コード・プレフィックスの最初のＮバイトと一致する場合に必ず、エミュレーション防止データから成るバイトを挿入する。上記の例の名称を使用すると、データが後に何らかの値を伴うパターン「ＷＷ」を含む場合、この方法は、エミュレーション防止バイトを挿入する。したがって、エンコーダは、パターンＷＷを識別すると、
ＷＷＺ
のパターンを提供するように、エミュレーション防止バイトを挿入する。

第１の説明された方法と、直前に説明した方法との違いは、第１の方法が最初のＮ＋１バイトを探してエミュレーション防止バイトを挿入する位置を確認するのに対して、直前に説明した方法が最初のＮバイトを探すという点である。

第１の方法は、送信される付加的なデータ（extra data）の量を減らすが、直前に説明した方法ではより簡単な規則を使用して操作する。したがって、この２つの方法は全体として、送信されるデータの量を減らすこと、規則の複雑さを軽減することの選択肢を提供する。第１の説明された方法を使用すると、第２の説明された方法と比較してデータの量が軽減される。第２の説明された方法を使用すると、より簡単な規則が利用される。

前述の処理をさらにプログラム的に説明するため、次のような状況を考える。エンコーダ側において、正確に同じ値ＷのＮバイトおよび異なる値Ｘの
最終バイトを含むスタート・コード・プレフィックスで始まり、値Ｙを持つ１バイトの識別スタート・コード・タイプ・サフィックスが後に続く、ＢバイトのパケットＰ［］を送信するために、値Ｚを持つエミュレーション防止バイトを挿入する次の擬似コード・プロセス（ここでＷ、Ｘ、Ｙ、およびＺは相互に異なる値を持ち、Ｐ［Ｂ−１］はＷと等しくない）を操作する。

上記の擬似コードにおいて、関数「ｓｅｎｄ＿ｂｙｔｅ（）」はデータの構成単位の送信を操作すると仮定される（図１のプロセス１０８を参照）。

デコーダ側において、パケットを受け取ると、デコーダが既に、正確に同じ値ＷのＮバイトおよび異なる値Ｘの最終バイトから成る既知のスタート・コード・プレフィックスを見つけ、読み込み、廃棄していると仮定し、さらに未知のシングル・バイト・スタート・コード・タイプ・サフィックスを変数Ｙに読み込み、ペイロード・データのパケットをアレイＰ［］に読み込んで、ペイロード・データの量を決定し、変数Ｂに量表示を入れて、その間に値Ｚを持つエミュレーション防止バイトを削除すると仮定する（ここでＷ、Ｘ、Ｙ、およびＺは相互に異なる値を持ち、Ｐ［Ｂ−１］はＷと等しくない）。

前述の方法は、第２の説明された方法では約１／２５６^Ｎ、第１の説明された方法では約１／２５６^{（Ｎ＋１）}だけ、理想的ランダム入力ペイロード・データ中の数量を膨張させると考えられている。これらの数量は、Ｎが大きい場合（たとえば２以上、ＭＰＥＧ−２スタート・コードの場合にＮ＝２であることに留意）には小さくなる。ペイロードの最悪の場合の膨張係数は、第２の説明された方法では１／Ｎ、第１の説明された方法では１／（Ｎ＋１）と考えられている。Ｎが増加した場合、ペイロード膨張係数は統計的分析および最悪例解析のいずれでも減少するが、スタート・コード自体に使用されるデータの量は増加する。

前述のエミュレーション防止プロセスは、パケット内のデータの量を送信の開始前に認識しているかどうかには左右されないことを理解されたい。したがって、これが重大な遅延を加えることはない。

この第２の説明された方法の定式化は、挿入されるエミュレーション防止バイトが値Ｚを持つシングル・バイトであることを仮定する。挿入されるデータの最初のバイトがＷまたはＸと等しくない限りにおいて（等しい場合は有効なスタート・コードをエミュレートするか、またはプレフィックスの開始の継続に見えてしまう）、代わりに、任意の値または複数の値、あるいはエミュレーション防止データの１つまたは複数の値のストリングを使用することもできる。

これらのエミュレーション防止バイトに情報を伝達することもできる（たとえば、Ｈ．２６３型のＧＯＢフレームＩＤ／ピクチャ・シーケンス番号など、あるいはおそらくＭＳＢを「１」に設定し他の７ビットを使用してＡＳＣＩＩ文字を送信する）。

デコーダ側でパケットの末尾に何が起こっているかを考えた場合、データ・パケット・ペイロールの最終バイトがＷではなければ操作をより簡単に制御できることが分かる。これはつまり、スタート・コードの前に送信された最終バイトがエミュレーション防止バイトになる必要は全くなく、ペイロード・データの末尾と次のスタート・コードのＷに等しいバイトのシーケンスの開始との間にデコーダによって検出可能境界が配置されるということである。これをこの事例に強制することで、ペイロードの末尾で次のスタート・コードの前に任意の量のＷバイト（たとえばゼロの値を有するバイト）を、ペイロードの末尾の位置を見失うことなくスタッフィングすることもできる。

データ・スタッフィング
通常、ビデオ・データの場合、データ・ペイロードとして送信されるそのデータは整数のバイト数にならないことがある。たとえば、２つのスタート・コードの間に送信される６２７ビットがあるとする。しかし、システム多重化レベルは、バイトで動作することがある。これは、ＭＰＥＧ−２仕様について当てはまる。送信エラーによって生成された誤ったスタート・コード・パターンの検出を可能にする、あるいはペイロードの先頭のデータ内容の簡単なデコーディング・プロセスを可能にするなどの他の理由も、パケットが、複数のバイトのような整数のデータ構成単位数を含むよう求める要望を正当化する。したがって、６２７ビットのデータを搬送するためにはもう少し多くのデータを送信しなければならない。次に、整数のバイト数にするためにいかにしてデータを水増し（pad out）するかが問題となる。

付加的なフィラー・データ（extra filler data）を単に送信することが有用になる他の状況もある。たとえば、チャネルが１メガビット／秒の容量を持ち、送信されるペイロード・データの量が９００キロビット／秒しかない場合、そのチャネルをフィラー・データで充てんする（pad）必要があるか、または充てんすることを望む可能性がある。

１つの実施例によると、データ・スタッフィング技法は、付加データ（extra data）が、チャネルに追加されることを可能とし、実質的に、ペイロード・データを埋められるようにする。

図２は、スタート・コードがゼロに等しいビットのストリングから始まると仮定された１つの実施例によるデータ・スタッフィングの方法のステップを説明する流れ図である。ステップ２００において、送信対象となるデータの最後の場所が確立される。ステップ２０２において、ペイロード・データの最終ビットの後に「１」ビットが挿入される。ステップ２０４において、整数のバイト数を送信するために必要な追加ビットの数が決定される。ステップ２０６において、挿入された「１」ビットの後に必要な数の「０」ビットが挿入される。ステップ２０８において、任意の望ましいバイト数のフィラー・データが追加される。フィラー・データは、真のペイロード・データおよび意図的なスタート・コードの場所をめぐる混乱を避けるために設計された任意のデータ・パターンで構成することができる。これは通常、値「０」のバイトを挿入することにより実装される。

例として、次のような状況を考察する。６２７ビットが送信されると仮定する。ここで、ステップ２０２において、６２７番目のビットの後に「１」ビットが挿入される。次にステップ２０４において、整数のバイト数（ここでは７９バイト）を提供するためにさらに４ビットが必要であると決定される。したがって、ステップ２０６において、挿入された「１」ビットの後に４つの「０」つまり００００が挿入される。ここで、整数のバイト数を確立してあるので、ステップ２０８において必要があれば任意の望ましいバイト数のフィラー・データを追加することができる。この特定の例において、０の値を持つバイトを挿入することができる。フィラー・データは、フィラー・データとしてそのまま使用することも、あるいはデコーダが何らかの目的で使用できる情報を含めるなどの目的に使用することができる。

ここで、デコーダにおける状況を考察する。デコーダは、スタッフィングされたデータを受け取り、データの最後で開始してデータ全体を逆方向に調べることができる。「１」ビットを持つバイトに到達するまで、デコーダが最初に認識するバイトはすべて０バイトとなる。「１」ビットは、ペイロードまたは実際のデータの場所をデコーダに知らせる。したがってデコーダは、挿入された「１」ビットを検出すると、実際のデータがどこで終わるかを正確に決定することができる。

このようにして、前述の技法を送信されるビットの数を「切り上げる」ために使用して、送信されるビットの数が整数のデータ構成単位数で構成されるようにすることができる。さらに、これらの技法を使用して、ペイロード・データの先頭を指定するスタート・コードの間にフィラー・データをスタッフィングすることができる。

境界で整列されていないポジションでのスタート・コード・エミュレーション防止
前述の実施例は、データの境界整列（data's boundary alignment）またはバイト整列（byte alignment）を保持するように設計されているシステムにおいて良好に機能する。しかし、データ境界整列を常には把握していないシステムも一部ある。

たとえば、ＩＴＵ−ＴＨ．３２０と呼ばれるそのようなシステムにおいて、システム内のデータの各バイトがデータ・ストリームの開始に対してどこで開始するかを見失うことがありうる。これは、データがバイトではなくビットのシーケンスとして送信され、時折未知量のデータ損失が発生する可能性があるためである。システムがバイト整列の追跡を失った場合、およびエミュレーション防止がバイトの境界で開始するエミュレーションしか防止しない場合、システムがバイト整列を回復する能力が損なわれる可能性がある。たとえば、システムがバイト境界におけるスタート・コード・エミュレーションしか防止しない場合、スタート・コード・エミュレーションがバイト境界以外の場所で発生する可能性がある。つまり、バイト境界におけるスタート・コード・エミュレーション防止に対してエンコードしていたシステムは、バイト境界以外の場所で発生したビット・シフトされたスタート・コード・エミュレーションに注意を払わなかった可能性もある。バイト境界位置を維持または保持するシステムでは、これは問題とはならない。それは、これらのシステムがバイト境界のある場所を認識しているので、単にバイト境界を見つけて実際のスタート・コードを探すことができるからである。実際のスタート・コードが検出されると、システムは前述のように、回復することができる。バイト境界が失われてしまったシステムにおいては、理由のいかんにかかわらず、そのシステムが、ビット・シフト位置で発生するエミュレートされたスタート・コードを使用して、回復しようと試みることがあるので、これは問題となる可能性がある。具体的には、バイト境界が失われると、システムは元のバイト境界に対していくつかの任意の整列ポジションで開始するスタート・コード・パターンに適合するデータを探そうと試みることができる。そのようなデータが実際のスタート・コードではなく、ビット・シフトされた場所でエミュレートされたスタート・コードである場合、この場所から回復することは、システムが適正に回復する能力を著しく妨げるおそれがある。

以下に説明する実施例は、バイト境界などのように、データ境界で必ずしも開始しない場所におけるスタート・コード・エミュレーションを防止する方法およびシステムを提供することを目的としている。したがって、これらの方法およびシステムは、データ境界位置においてデータ整列を必ずしも保持しないシステムと関連して有利に採用することができる。さらに、何らかの理由でデータ境界を見失ってしまったシステムにおいて、本発明の方法およびシステムは、正規のスタート・コードのみを使用してシステムが適正に、回復する方法を提供することができる。

初期割り込み
説明する最初の手法は、「初期割り込み（early interruption）」法と呼ばれる。ここで、初期割り込み法は、シフトされたスタート・コードのバージョンが発生する可能性が生じる前に潜在的スタート・コード・エミュレーションを割り込ませることを目的としている。これは、スタート・コード設計内のビットのパターンを、データバイトの開始に対して、そのスタート・コードの各シフト・ポジションごとに詳細に分析することにより行われる。次に、バイト整列されたスタート・コードが発生し得るときのみに特別なエミュレーション防止バイトを挿入するのではなく、手法は、データ境界（この場合はバイト境界）に対してシフトされる各ポジションにおけるスタート・コード・パターンの整列されていないエミュレーション（non-aligned emulation）を防止するような方法でエミュレーション防止バイトを挿入する。

真のスタート・コードの検出は、データ境界またはバイト境界に対してデータの真の整列を検出する能力をもたらすことができる。これは、スタート・コードが通常、データまたはバイト境界で開始するように常に設計されているためである。データ内の真のスタート・コードの位置を検出した後、受信機は各バイトの開始位置についてのこの認識を使用して、スタート・コードおよびスタート・コード・エミュレーション防止データからペイロード・データを分離するデコーディング・プロセスを補助することができる。これは、デコーダが、送信データ内のスタート・コード・パターンのエミュレーションを防止するために使用される方法を認識するように設計することができるためである。

図３は、１つの実施例による方法を説明する流れ図である。図示されている方法は、スタート・コードがビット・シフト・ポジションにおいてエミュレートされないようにするためにスタート・コード・エミュレーション防止がどのように実施されるかの例を示している。

ステップ３００において、１つまたは複数のデータ境界に対してスタート・コードの少なくとも一部が複数回、ビット単位でシフトされる。１つの実施例において、ビット単位でシフトされたスタート・コードの部分は、スタート・コード・プレフィックスを含んでいる。ステップ３０２において、少なくとも１つのデータ境界に対して、すべてのビット・シフト・ポジションごとに発生するスタート・コード部分内の１つまたは複数の特徴的なパターンが識別される。ステップ３０４において、スタート・コード・エミュレーション防止データの挿入を実施するために、検索パターンとしてステップ３０２で識別された特徴的なパターンが使用される。

これがどのように行われるかを示す１つの例として、図４に関連して次のような状況を考える。

Ｎ＝２として、０ｘ００（「０ｘ」が１６進数値を示すＣ言語の表記法を使用、０ｘ００はゼロに等しい１６進バイト値を示す）の値を持つＮバイトとして構成され、０ｘ０１の値を持つ１バイトが後に続くスタート・コード・プレフィックスについて検討する。たとえば、図４において、例示的なスタート・コード・プレフィックスが、示され、その先頭が実線角括弧によって示されているデータ境界と一致している。したがって、スタート・コード・プレフィックスの最初のバイトは最初の８つのゼロで構成され、第２のバイトはその次の８つのゼロで構成され、以下同様である。最初の８つのゼロに先行しているのは、先行データの任意の未知の値を示す「ｘ」の値のバイトである。ここで、このスタート・コード・プレフィックスまたは部分が、指示されているデータ境界に対してビット単位でシフトされると（ビット単位のシフトの１つを図４の上図の下に例示）、破線角括弧で示される特徴的なパターンが現れる。スタート・コード・プレフィックスの、バイトの先頭に対してシフトされた各ポジションによって作成されたビットのパターンを調べることによって、この場合、シフトされたこのスタート・コードのコピーを含むデータのシーケンスには、０ｘ００の値を持つ少なくともＮバイトが常に存在すると決定することができる。したがって、エミュレートされたビット・シフトスタート・コード・プレフィックスの特徴的なパターンは、０ｘ００の値を持つＮバイトの存在である。任意の単一の整列ポジションにおけるこのパターンの防止がすべての整列ポジションにおけるスタート・コードの発生を防止することになるので、この特徴的なパターンは、ここで、スタート・コード・エミュレーション防止データ挿入を実施するための検索パターンとして使用することができる。

さらに具体的に、先に「第１の例示的方法」の項目で説明されている方法について検討する。そこでは、値０ｘ００のＮバイトの後に値０ｘ０１またはＺが続くパターンを含んでいた場合、エミュレーション防止バイトＺが挿入される。したがって、新しいパターンは、値０ｘ００のＮバイトに続いて値Ｚを持つバイト、さらに続いて値０ｘ０１またはＺを持つバイトを含むものになる（長さＮ＋１の２つのパターンのいずれかが発生すると必ず、１バイトだけ、入力データ長の拡張が行われる）。

現在説明している初期割り込み方法に従って、バイト整列されたポジションのスタート・コード・プレフィックスのみではなく、スタート・コード・プレフィックスまたは部分についてのすべてのシフトされたバージョンを防止することが求められている。そのため、この方法に従い、この特定の例に関連して、値Ｚを持つエミュレーション防止バイトが値０ｘ００を持つＮバイトのシーケンスの最終バイトの前に挿入される。これにより、値０ｘ００のＮバイトの任意のシーケンスを防止し、さらにバイト整列ポジショニングに関してスタート・コードの各シフトされたコピーをすべて防止する。この例において、パターンが検査され、エミュレーション防止バイトはバイト整列されたポジションにのみ挿入される。例として、ビット・シフトスタート・コード・プレフィックスを含むシーケンスの最終バイトの前にエミュレーション防止バイト（「Ｚ」と示された値を持つ８ビットで表示）を挿入されたＮ＝２のシーケンスを示す図５を検討する。図５では明示的に示されていないが、「ｘ」値として記号で表されている最終４ビットの少なくとも１つがゼロと等しくないことが図５で例示のために仮定されている（そうでなければ、エミュレーション防止プロセスは「ｘ」値として記号で表されている最終４ビットを含むバイトの直後の位置に別のエミュレーション防止バイトを挿入してしまう）。

したがって、この方法は、スタート・コード・プレフィックスのビット・シフト・ポジション位置をすべて認識し、すべてのビット・シフトされたスタート・コード・プレフィックス・エミュレーションを防止する態様で、シーケンスに対して割り込み処理をする。これは、エンコーダがバイト境界に整列されたポジションにおいてのみ特徴的なパターンを検索して完全なバイト単位のみでエミュレーション防止データを挿入するので、エンコーダのビット単位の処理を必要とすることなく、達成される。

さらに、エンコーダは、エミュレーション防止データが既に挿入されているデータをペイロード・データがエミュレートするような状況を回避するために、エミュレーション防止バイトを挿入することもできる。たとえば、エンコーダが０ｘ００の値を持つＮ−１バイトと後に続くエミュレーション防止バイトの値（つまりＺ）を持つバイトを検出すると、エンコーダはエミュレーション防止バイトを挿入する。

あるいは、データ・ペイロードが０ｘ００に等しいＮ−１データバイト、その後にＺに等しいバイト、さらにその後に０ｘ００に等しいバイトが続くシーケンスを含む場合、エンコーダはこの目的でバイトを挿入するだけが可能である。これは、挿入されるエミュレーション防止データの量を軽減するが、エンコーダおよびデコーダにおける可変長シーケンス処理が必要になる。

したがって、この特定の例の場合、初期割り込みの方法は、前述の特定のスタート・コード・プレフィックス値について以下の表のようにまとめることができる。

ここで、デコーダの観点から状況を考察する。デコーダにおいては、０ｘ００の値を持つＮバイトをデコーダが検出するときはいつも、スタート・コードではないビット・シフト位置を含むすべての場所でこの状況が発生することをエンコーダが防止しているので、デコーダはこの検出が真のスタート・コード・プレフィックスでなければならないと認識する。真のスタート・コードを検出するための特徴的なパターンは、バイト境界に対して任意の整列ポジションであっても開始するときに発見できるため、デコーダはビット単位の処理を使用せずにこのスタート・コードの検出を実行することができる。デコーダは、真のスタート・コードがどこにあるかを認識すると、バイト整列を認識する。これは、スタート・コードがバイト整列されたポジションで開始するためである。したがって、この特定の例において、デコーダは、０ｘ００ではない次のバイトがスタート・コード・プレフィックスの末尾を含むことを認識する。次にデコーダは、スタート・コード・プレフィックスを終了するビットのパターンを探して（この場合は「１」ビット）、その後に真のペイロード・データを見つけることができる。

さらに、スタート・コード・プレフィックスの位置を突き止めることによってデコーダがバイト整列（byte alignment）を認識すると、挿入されたエミュレーション防止データを容易に見つけることができることを考慮されたい。デコーダは、エミュレーション防止バイトがバイト整列されたポジションに挿入されている事実に基づいて、これの作業を行う。デコーダはバイト整列を認識しているので、バイト境界においてエミュレーション防止データ・パターンを探すことができる。つまり、上記の表で説明したバイト境界における置換パターンを探すことができる。デコーダは次に、エミュレーション防止データを削除して、そのデコーディング・プロセスを進める。

前述の方法は、エミュレーション防止処理を実行するエンコーダがすべてのビット・シフト・ポジションにおけるエミュレーションを防止するにも係わらず、バイト・レベルでデータ・シーケンスを調べて、バイト・レベルのみでそのデータを操作することによってこれを行い、この結果、このプロセスにおいてビット単位の操作を行うという複雑さを軽減することができるため、有利である。真の開始コードの存在をデコーダについても、各バイトに対して実行される操作によって、同様のことが当てはまる。デコーダは次にバイト整列を回復して、各バイトに対して実行される操作によってエミュレーション防止データの削除を実行することができる。

この最初の初期割り込みの方法を、「第１の例示的な方法」の項目で説明されている方法と比較および対照させて、次の事項を考察する。初期割り込みの方法の１つの欠点は、より短いパターンを探すため（たとえば、Ｎ＋１バイトよりもＮバイト）、データを挿入する頻度が高くなることである。しかし、これについては何らかの対処方法がある。具体的には、Ｎの値を増大させることができる。つまり、３バイトのスタート・コード・プレフィックスを使用するのではなく、４バイトのスタート・コード・プレフィックスを使用することもできる。ただし、これはシステムで挿入する必要のある別種のデータの量を増加させる。つまり、エンコーダがスタート・コードを挿入する場合、より長いスタート・コードを挿入するので、追加データの量の増大という点からコストがより高くなる。しかし、この初期割り込みの方法の１つの利点は、デコーダがバイト整列を回復することを可能にすることである。

初期割り込みの方法の第２の実施例は、第１の説明されている設計で置き換えられる複数パターンに共通な代替パターンに対してパターン突合せおよびパターンの置換の検索を実行するものとなる。この代替実施例の一例を、以下の表に示す。

この第２の初期割り込みの方法において、すべてのシフトされたポジションのスタート・コード・エミュレーションを防止するには、単一の検索パターン（Ｎ−１バイトは０ｘ００に等しい）で十分である。このパターンが、第１の初期割り込みの方法を説明する表の２つの行に示された２つのパターンに共通するためである。

この第２の状況をデコーダの観点から検討すると、真のスタート・コード・プレフィックスの検出は変更されていない。これには、第１の初期割り込みの場合と同様に０ｘ００の値を持つＮバイトの存在を認識することが含まれている。さらに、第１の初期割り込みの方法と同様に、デコーダは真のスタート・コードがどこにあるかをいったん認識すると、真のスタート・コードがバイト整列されたポジションで始まるので、デコーダはバイト整列位置を認識し、置換パターンを探すことによって挿入されたエミュレーション防止データを容易に見つけ出すことができ、それからエミュレーション防止データを削除してそのデコーディング・プロセスを進めることができる。

この第２の初期割り込みの方法は、第１の初期割り込みの方法と比較すると、パターン検索プロセスによる認識に必要なパターンの数が少なくてすむ。その結果、検索プロセスの複雑さが軽減されるが、より短いパターンへの突合せが使用されるため、挿入されるエミュレーション防止データの量は増加する。

第１の初期割り込みの方法の場合と同様に、追加されるエミュレーション防止データの量はＮの値を増大させることで減らすことができるが、これは実際のスタート・コードデータの量を増やすことになる。

重要な点は、以下である。すなわち、第２の初期割り込みは、（各々複数パターンを使用する「第１の例示的な方法」および第１の初期割り込みの方法とは対照的に）複数のより長いパターンではなく単一の短いパターンへのパターン突合せを使用するという点で、「第２の例示的な方法」の項目で説明されている方法と、構造上、同様である。特に、これらの複数の方法を検討した結果、バイト境界に対して整列についての任意シフト・ポジションにおける、長さＮ＋１のスタート・コード・プレフィックスのエミュレーションを防止するための第２の初期割り込みの方法のエンコーディング・パターン検索および置換のプロセスは、バイト境界に整列されたポジションにおける長さＮのスタート・コード・プレフィックスのエミュレーションを防止するための「第２の例示的な方法」のエンコーディング・パターン検索および置換のプロセスと全く同じである。この特性（property）は以下のセクションで使用される。

複数の長さが異なるスタート・コード（Multiple Length Start Codes）を使用するエミュレーション防止
前述の初期割り込みの方法は、開始位置がデータ境界と一致しない任意のビット・シフト・ポジションにおけるスタート・コード・エミュレーションを防止することに関連して、バイト整列が失われた場合に、回復を可能にするという課題の解決策をもたらす。ただし、これらの方法は、整列されたポジションにおいて発生するスタート・コードのエミュレーションのみを防止するために必要以上の頻度でエミュレーション防止データを追加するという犠牲を払って、これを行う。以下に説明する実施例において、初期割り込みの方法と同様の方法で整列の回復を可能にし、しかも挿入されるエミュレーション防止データおよびスタート・コードデータの合計量を軽減する手法が提供される。具体的な解決策について説明する前に、以下の実態を考察する。

スタート・コードが送信されるデータのタイプには多種多様なものがある。たとえば、ビデオ・データの場合、ＧＯＰごと、ピクチャごと、および各ピクチャの個別にデコード可能な各領域内（つまりスライス・スタート・コード）のスタート・コードを送信することが一般的である。Ｉ−ピクチャ、Ｐ−ピクチャ、およびＢ−ピクチャのようなさまざまなピクチャのタイプがある。したがって、１つの特定のシステム内にはさまざまなタイプのスタート・コードがある可能性がある。それらのスタート・コードの中には、他よりもかなり高い頻度で発生するものもある。たとえば、スライス上のスタート・コードは、ＧＯＰまたはシーケンス上のスタート・コードよりもはるかに高い頻度で発生する。

このことを考慮すると、システムを設計する場合には、高い頻度で発生するスタート・コードを、より低い頻度で発生するスタート・コードよりも短くすることが望ましいと考えられる。以下に説明する実施例により、スタート・コード・プレフィックスの２つまたはそれ以上の異なる長さの区別がつけられる。長さのより長いスタート・コード・プレフィックスの場合、ペイロード・コンテンツ内のビット・シフトされたエミュレーションは防止される。これは、長さのより長いスタート・コード・プレフィックスに対する初期割り込みの方法を採用することで行われる。長さのより短いスタート・コード・プレフィックスの場合、そのようなスタート・コードのバイト整列エミュレーションのみが防止される。そのようなシステムにおいて、より長いスタート・コードが短いスタート・コードよりも著しく低い頻度で送信されて、平均のスタート・コード長が短いスタート・コードの長さに、近づく場合、効率をさらに高めることができる。

この解決策により、バイト整列を保持しない環境でデータが使用される場合、データ内でより長いスタート・コードを検索することによりバイト整列を回復することができる。より長いスタート・コードが見つけられてバイト整列が回復されると、それに続く短いスタート・コードの位置もバイト指向の検索のみによって見つけることができる。

これがどのように実施されるかを示す１つの例として、次のような状況を考察する。この例において、より長いスタート・コード・プレフィックスの長さはＮ_Ｌ＋１と示され、より短いスタート・コード・プレフィックスの長さはＮ_Ｓ＋１と示される。

この例において、またバイト整列を保持しないシステムにおいても、使用されるスタート・コード・プレフィックスの特定の構造により、より長いビット・シフトスタート・コードは値０ｘ００を持つＮ_Ｌバイトのバイト指向検索を使用してデータ・ストリーム内で検出することができる。これらの特定のスタート・コード値により、バイト指向検出を容易に行うことができる。

具体的には、好ましい実施例の方法は、Ｎ_Ｌ＝Ｎ_Ｓ＋１を設定することである。次に、１つのエミュレーション防止プロセスは、以下の表に示すようにまとめることができる。

上記の表において、第１行は置換する第１のパターン、およびバイト整列されたポジションにおける短いスタート・コードのエミュレーションを防止する置換パターン、を説明している。第２行は、第２のパターンと、バイト整列されたポジションおよびバイト整列されていないポジション（byte-aligned and non-byte-aligned positions）における長いスタート・コードのエミュレーションを防止する置換パターンを説明している。第３行は、第３のパターンと、エミュレーション防止プロセスによって挿入された値Ｚのバイトとデータ・ペイロード内の値０ｘ００のＮ_Ｓバイトに続いて自然に生じた値Ｚの他のバイトとを区別する方法を提供する置換パターン、を説明している。このことは、引き続き、データ・ペイロードの終わりの位置または次のスタート・コードの位置を識別できるデコーダの機能を損なうことなく、エンコーダが任意の数のゼロの値をとるバイトをスタート・コードの直前に挿入できることに留意されたい。実際、そのようなゼロの挿入は、エンコーダが、一部のより短いスタート・コードの前にいくつかのゼロの値をとるバイトを挿入するように選択する場合、バイト整列の迅速な回復を追加することになる。

あるいは、前述のプロセスにおける第３行は、値０ｘ００の入力データのＮ_Ｓバイトに続いて値Ｚの１バイト、さらに値０ｘ０１の入力データバイトが続く場合に限り、値Ｚの付加的なバイト（extra byte）が挿入されるように変更することもできる。これは、エンコーダおよびデコーダにおける可変長シーケンス処理が必要になるけれども、挿入されるエミュレーション防止データの量を軽減する。

この第１の方法は、エミュレーション防止に必要とされるデータの量を、より短いスタート・コード値の非整列エミュレーションを防止するために必要な量から、（約

から約

にエミュレーション防止プロセスデータ膨張係数を減少して）約１７１分の１に低減される量まで低減する。

図６は、異なる長さを持つスタート・コードまたはスタート・コード・プレフィックスを含むことのできるデータに関連してエミュレーション防止データを使用する実施例による方法のステップについて説明する流れ図である。方法は、適切なハードウェア、ソフトウェア、ファームウェア、またはそれらの組合せで実装することができる。図を使用して説明されている実施例において、方法は、適切に構成されたエンコーダによって実装される。

ステップ６００において、異なる長さのスタート・コードに関連付けられているパターンが検索される。異なる長さを適切な数だけ使用することができる。上記の例においては、２つの別個の長さを持つスタート・コードが使用される。第１のパターン・タイプの検出に対応して、ステップ６０２においてエミュレーション防止データが挿入され、第１の長さを持つスタート・コードのエミュレーションが防止される。ここで、第１のパターン・タイプは、より短いスタート・コードに関連付けられているものにすること、および上記の表の第１行の「置換するパターン」列に表示されているパターンによって例示することができる。さらに、この特定のパターンおよびこの特定の例の対応するエミュレーション防止データは、上記の表の第１行の「置換パターン」列に表示されているパターンによって例示することができる。

第２のパターン・タイプの検出に対応して、ステップ６０４においてエミュレーション防止データが挿入され、第２の長さを持つスタート・コードのエミュレーションが防止される。ここで、第２のパターン・タイプは、より長いスタート・コードに関連付けられているものにすること、および上記の表の第２行の「置換するパターン」列に表示されているパターンによって例示することもできる。さらに、この特定のパターンおよびこの特定の例の対応するエミュレーション防止データは、上記の表の第２行の「置換パターン」列に表示されているパターンによって例示することができる。

この方法はさらに、エミュレーション防止プロセスによって挿入された値Ｚのバイトおよびデータ・ペイロード内の値０ｘ００のＮ_Ｓバイトに続いて自然に生じた値Ｚの他のバイトを区別する方法を、流れ図はこのことを具体的に示していないが、有利に提供する。

ここで、デコーダ側において発生する状況を考察する。デコーダ側では、バイト整列が失われた場合、回復が、長いスタート・コード・プレフィックスを探すデコーダによって、行われる。エンコーダで行われるエミュレーション防止処理のために、長いスタート・コード・プレフィックスのエミュレーションはすべてのビット・シフトされたポジションにおいて防止されることに留意されたい。したがって、デコーダは真の長いスタート・コード・プレフィックスに対応するパターンを検出すると、真のスタート・コードの位置を突き止めたことになる。真の長いスタート・コードを見つけることにより、バイト整列は回復されることが分かる。つまり、真の長いスタート・コードがバイト整列位置で生じているため、長いスタート・コードを見つけることでバイト整列を確立する。デコーダは、バイト整列を回復すると、より短いスタート・コードを正規のバイト整列されたポジションにおいてのみ探すことができる。このプロセスに関連して、デコーダは前述の方法で、エミュレーション防止データを削除する作業に取りかかることができる。

前述の処理は、バイト整列が失われた場合に、バイト整列の回復のための機構が提供されるという点において有利である。さらに、異なる長さの開始コードまたは開始コード・プレフィックスが使用されるということに起因して、説明されている方法は、最も高い頻度で使用されるスタート・コード・プレフィックスは、低い頻度で使用されるスタート・コード・プレフィックスよりも短くされているので、データ・ストリームに付加的な情報（extra information）の負担をかけずにすむ。前述の第２の初期割り込みの方法の場合と同様に、パターンの長さを短くすることにより、エンコーダおよびデコーダによって検索する必要のあるパターンの数を減らすことも可能になる。この場合、異なる長さのスタート・コードのエミュレーションを防止するためにテストされるパターンは同じにすることができ、プロセスの一部のステップを結合することが可能になる。たとえば、ステップ６０２において第１のパターン・タイプの検出に使用されるパターンと、ステップ６０４において第２のパターン・タイプの検出に使用されるパターンが同じパターンであれば、ステップ６０２とステップ６０４は組み合わせることができる。ステップを組み合わせるこの機能を明らかにする、長さが異なる複数のスタート・コード（multiple length start codes）を使用する第２のエミュレーション防止プロセスを、以下の表に示す。このプロセスは、（長さＮ_Ｓ＋２になる）長さＮ_Ｌ＋１の整列されていないスタート・コードのエミュレーションを防止する第２の初期割り込みの方法に対応し、さらに長さＮ_Ｓ＋１のバイト整列されたスタート・コードのエミュレーションを防止する第２の例示的な方法にも対応する。したがって、単一パターンの検索および置換は、両方のタイプのスタート・コード・エミュレーションを防止するために十分であることになる。

長さが異なる複数のスタート・コードを使用するこの第２のエミュレーション防止プロセスは、検出して置換する必要のあるパターンの数を減らすので、パターン検索と置換のプロセスを簡略にする。ただし、より短いパターンへの突合せが使用されるため、挿入されるエミュレーション防止データの量は増加する。挿入されるエミュレーション防止データの量は、前述の長さが異なる複数のスタート・コードを使用する第１のエミュレーション防止プロセスに対して（約

から約

にエミュレーション防止プロセスデータ膨張係数を増大させて）約３／１６＝１／５．３３だけ増加する。

拡張機能
特定のパターンを検出することがいかに容易であるかに関し、処理効率を高めるために採用できる拡張機能がいくつかある。以下に示す例のため、スタート・コード・プレフィックスは、値Ｗ＝０ｘ００を持つ特定数のバイトに続いて値Ｘ＝０ｘ０１を持つ（一つの）バイトで構成されると仮定する。ただし、以下に説明される原則は、例に示されている値とは異なる値を持つ他のスタート・コード・プレフィックスに関連して、採用することもできることを理解されたい。

第１の拡張機能は、次のとおりである。前述の表記（Ｗ、Ｘ、およびＺ）を使用して、ＺおよびＸ、またはＺおよびＷはわずか単一ビットの値だけ異なるように選択することができる。このことは、エンコーダおよびデコーダがデータのストリームの２つの値のいずれかを容易に検出することを可能にする。１ビット値だけ異なるＺおよびＸを持つことの有用性を示すために、データの受信側によって行われる処理を考察する。デコーダが、スタート・コードを検出してエミュレーション防止データを削除するためにデータ・ストリームを検索しているとき、Ｎまたはそれ以上のバイトの値Ｗ＝０ｘ００を検出した後、入力データの次のバイトがＺまたはＸと等しいかどうかのテストを実行する場合がある。ＺおよびＸが１ビットよりも大きい値の相違がある場合は、擬似Ｃプログラミング構成体を使用して説明すると、次のようにテストが行われる。

ただし、ＺおよびＸが１ビット値だけ異なる場合は、擬似Ｃプログラミング構成体を使用してＸが０ｘ０１、Ｚが０ｘ８１であると仮定すると、テストは次のように行われる。

第２の拡張機能は、前述のエミュレーション防止プロセスのうちの１つが３つのパターンを区別していることを認識する。１つがこれらのパターンを最小ビット数だけ相互に異なるようにすれば、３つのパターンを区別するために２ビットを要する。ただし、２ビットは４つのオブジェクトまたはパターンを区別するために十分である。ここで、区別する必要があるのは３つのパターンだけであるため、システムが通常のデータに使用しない第４のパターンがあることは有利になり得る。エンコーダが、２または３の値と等しいエミュレーション防止バイトを設定するように構成される場合、これはシステムが単に各パターンの２つの最下位ビットに注目するだけで上記の３つのパターンを区別できるということである。たとえば、Ｗが０ｘ００に等しい場合、Ｘは０ｘ０１に等しく、Ｚは０ｘ０２に等しい。次に、２つの最下位ビットが０である場合、これは初期バイト値Ｗの繰り返しである。２つの最下位ビットが１である場合、これは最終バイト値Ｘである。２つの最下位ビットが２である場合、これはエミュレーション防止値Ｚである。他の値、つまり値３は、通常のデータ以外の特殊値として処理することができる。したがって、デコーダにおいては、２つの最下位ビットを除いては全く同じであるので、３つのパターンを探すのではなく、４つのパターンを探して非常に簡単に見つけることができる。このことは、エンコーダおよびデコーダにおける処理をスピードアップして処理を簡略化することを可能にする。

このようにして、３つの値のシーケンスをエミュレーション防止プロセスに置き換える代わりに、システムは４つの値のシーケンスを置き換えることができる。これらの４つのシーケンスは、２つのビットの値だけで相互に区別される。言い換えれば、（現時点でＷ＝０ｘ００、Ｘ＝０ｘ０１、Ｚ＝０ｘ８１と仮定して）入力データがこれらの特殊値の１つを持つかどうかを検出するためのエンコーダまたはデコーダの検出プロセスは、次のように簡略化できる。

第４の特殊バイト値（この場合は０ｘ８０）は、別のタイプのスタート・コードなどさまざまな目的で使用することも、システムに未使用のままにしておくこともできる。

第３の実施例として、次のような状況を考察する。データ・ペイロードの末尾の後にＷの値を持つバイトでスペースを充填すること（padding）は、Ｗのシーケンスの後に到着する次の値がＸであり、このことは真のスタート・コード・プレフィックスを示しているので、充填する複数の値の間にエミュレーション防止バイトを挿入する必要なく、行うことができる。これにより、特殊な境界（３２ビットＤＷＯＲＤ境界または固定長パケット境界など）への整列、あるいは情報を送信する必要がない場合に一定のビット・レート・チャネルを単に満たすためなど、何らかの目的で「スタッフィング」の任意の整数バイト数を伝送チャネルに充てんすることができる。

充填することのもう１つの利点は、スタート・コードの値がこれを許可するように選択されている場合、エンコーダが、バイト整列を失った際にバイト境界に再同期するために、充填できるようになっていることである。したがって、エンコーダは、デコーダによりバイト整列を回復できるように、１つまたは複数の付加的な充填バイト（extra padding byte）をどの程度の頻度で送信するかに対しての決定権を有することができる。エンコーダには、すべてのスタート・コードの前に特別な充填を追加して頻繁にバイト整列の回復を行えるようにするものも、また低い頻度でこれを行うように選択するものもある。

Ｗ＝０ｘ００かつＸ＝０ｘ０１の場合に特に興味深いＺの値は、Ｚ＝０ｘ８０、０ｘ０２、０ｘ８１、および０ｘ０３である。

バイト整列の回復のために追加される付加的な充填バイトのフォーマット仕様は、最小頻度を指定することができ、また、付加的な充填を、データ・ストリーム内のスタート・コードの特定タイプに関連付けることもできる（圧縮ビデオ・データの各ピクチャの先頭に充填するなど、ただしＭＰＥＧ−２またはＨ．２６３ビデオのスライスまたはＧＯＢスタート・コードとして知られているような低レベルスタート・コードの前に充填することは必要ない）。

例示的なコンピューティング環境
図７は、以下に説明するシステムおよび関連する方法を実施できる適切なコンピューティング環境７００の例を示している。

コンピューティング環境７００は、適切なコンピューティング環境の一例に過ぎず、前述のエンコーディング／デコーディング・システムの使用または機能の範囲に関していかなる制限を加えることも意図するものではない。さらに、コンピューティング環境７００は、例示的なコンピューティング環境７００に示された１つのコンポーネントまたはその組み合わせに関して依存関係または要件を有するものと解釈すべきではない。

数多くの他の一般的用途または特殊用途のコンピューティング・システム環境または構成で、前述のさまざまな実施例を実現することができる。メディア処理システムと共に使用するために最適な既知のコンピューティング・システム、環境、および／または構成の例としては、パーソナル・コンピュータ、サーバー・コンピュータ、シン・クライアント、シック・クライアント、ハンドヘルドまたはラップトップ装置、マイクロ・プロセッサ・システム、マイクロ・プロ・セッサ・ベースのシステム、セットトップボックス、プログラマブル家庭用電化製品、ネットワークＰＣ、ミニ・コンピュータ、メイン・フレームコンピュータ、上記のシステムまたは装置のいずれかを含む分散コンピューティング環境などがあげられるが、これらに限定されることはない。

特定の実装において、システムおよびその関連する方法は、コンピュータによって実行されるプログラム・モジュールなど、コンピュータ実行可能命令の一般的なコンテクストに即して十分に説明される。一般に、プログラム・モジュールには、特定のタスクを実行するかまたは特定の抽象データ・タイプを実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。本実施例はさらに、タスクが通信ネットワークを通じてリンクされたリモート処理装置によって実行される分散コンピューティング環境においても実施することができる。分散コンピューティング環境において、プログラム・モジュールは、メモリ記憶装置を含むローカルおよびリモートのコンピュータ・ストレージ媒体に配置される。説明されるコンピューティング・システムのコンポーネントは、前述のように機能するエンコーダおよびデコーダを実装するために使用することができる。

図７に示される実施例によれば、コンピューティング・システム７００は、１つまたは複数のプロセッサまたは処理装置７０２、システム・メモリ７０４、およびシステム・メモリ７０４を含むさまざまなシステム・コンポーネントをプロセッサ７０２に結合するシステム・バス７０６を含むことが示されている。

バス７０６は、メモリ・バスまたはメモリ・コントローラ、周辺バス、ＡＧＰ（accelerated graphics port）、およびさまざまなバス・アーキテクチャのいずれかを使用するプロセッサまたはローカル・バスを始めとする、１つまたは複数の各種バス構造を表すことを意図している。限定的ではなく例示的に、そのようなアーキテクチャには、業界標準アーキテクチャ（ＩＳＡ）バス、マイクロ・チャネル・アーキテクチャ（ＭＣＡ）バス、ＥｎｈａｎｃｅｄＩＳＡ（ＥＩＳＡ）バス、ＶｉｄｅｏＥｌｅｃｔｒｏｎｉｃｓＳｔａｎｄａｒｄｓＡｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカル・バス、およびメザニン・バスとしても知られるＰｅｒｉｐｈｅｒａｌＣｏｍｐｏｎｅｎｔＩｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バスが含まれている。

コンピュータ７００は通常、各種のコンピュータ可読媒体を含んでいる。そのような媒体は、コンピュータ７００がローカルおよび／またはリモートにアクセスできる任意の使用可能な媒体であってもよく、揮発性および不揮発性媒体、取り外し可能および固定の媒体を含んでいる。

図７において、システム・メモリ７０４は、ランダム・アクセス・メモリ（ＲＡＭ）７１０のような揮発性メモリ、および／または読み取り専用メモリ（ＲＯＭ）７０８のような不揮発性メモリの形態をとるコンピュータ可読媒体を含んでいる。起動時などにコンピュータ７００内の構成要素間の情報の転送を助ける基本ルーチンを含むＢＩＯＳ（basic input/output system）７１２は、ＲＯＭ７０８に格納される。ＲＡＭ７１０は通常、処理装置７０２によって即時アクセス可能および／または現在操作中のデータおよび／またはプログラム・モジュールを含んでいる。

コンピュータ７００はさらに、他の取り外し可能／固定、揮発性／不揮発性のコンピュータ記憶媒体も含めることができる。一例として、図７は、固定の不揮発性磁気媒体（図示せず、通常は「ハード・ドライブ」と呼ばれる）との間の書き込みおよび読み取りを行うハードディスク・ドライブ７２８、取り外し可能の不揮発性磁気ディスク７３２（「フロッピー（登録商標）ディスク」など）との間の書き込みおよび読み取りを行う磁気ディスク・ドライブ７３０、およびＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭその他の光媒体など、取り外し可能の不揮発性光ディスク・ドライブ７３６との間の書き込みおよび／または読み取りを行う光ディスク・ドライブ７３４を示している。ハードディスク・ドライブ７２８、磁気ディスク・ドライブ７３０、および光ディスク・ドライブ７３４は、それぞれ１つまたは複数のインターフェース７２６によってバス７０６に接続されている。

ドライブおよびその関連するコンピュータ可読媒体は、コンピュータ７００のコンピュータ可読命令、データ構造、プログラム・モジュール、およびその他のデータの不揮発性記憶装置を提供する。本明細書に記載の模範的な環境では、ハードディスク７２８、取り外し可能磁気ディスク７３２、および取り外し可能光ディスク７３６を採用しているが、磁気カセット、フラッシュ・メモリ・カード、デジタル・ビデオ・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）などの、コンピュータによりアクセス可能なデータを格納できる他の種類のコンピュータ可読媒体も、模範的なオペレーティング環境に使用できることは当業者であれば理解するであろう。

多数のプログラム・モジュールは、限定的ではなく例示的にオペレーティング・システム７１４、１つまたは複数のアプリケーション・プログラム７１６（マルチメディア・アプリケーション・プログラム７２４など）、その他のプログラム・モジュール７１８、およびプログラム・データ７２０を含む、ハードディスク７２８、磁気ディスク７３２、光ディスク７３６、ＲＯＭ７０８に格納することができる。ユーザは、キーボード７３８およびポインティング・デバイス７４０（「マウス」など）のような入力装置を介してコンピュータ７００にコマンドおよび情報を入力することができる。他の入力装置としては、オーディオ／ビデオ入力装置７５３、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送用パラボラ・アンテナ、シリアル・ポート、スキャナなど（図示せず）が含まれる。上記およびその他の入力装置は、バス７０６に結合されている入力インターフェース７４２を介して処理装置７０２に接続されているが、パラレル・ポート、ゲーム・ポート、またはユニバーサル・シリアル・バス（ＵＳＢ）など他のインターフェースおよびバス構造によって接続することもできる。

モニタ７５６またはその他の種類の表示装置も、ビデオ・アダプタまたはビデオ／グラフィックス・カード７４４などのインターフェースを介してバス７０６に接続される。モニタに加えて、パーソナル・コンピュータは通常、出力周辺インターフェース７４６を介して接続できるスピーカおよびプリンタなど、他の周辺出力装置（図示せず）を含んでいる。

コンピュータ７００は、リモート・コンピュータ７５０など、１つまたは複数のリモート・コンピュータへの論理接続を使用するネットワーク化された環境において動作することができる。リモート・コンピュータ７５０は、コンピュータに関連して本明細書で説明されている構成要素および機能の多くまたはすべてを含めることができる。

図７に示されているように、コンピューティング・システム７００は、ローカル・エリア・ネットワーク（ＬＡＮ）７５１および一般的なワイド・エリア・ネットワーク（ＷＡＮ）７５２を介してリモート装置（リモート・コンピュータ７５０など）に結合されている。そのようなネットワーク環境は、オフィス、企業規模のコンピュータ・ネットワーク、イントラネット、およびインターネットで一般化している。

ＬＡＮネットワーク環境に使用される場合、コンピュータ７００は適切なネットワーク・インターフェースまたはアダプタ７４８を介してＬＡＮ７５１に接続される。ＷＡＮネットワーク環境で使用される場合、コンピュータ７００は通常、モデム７５４またはＷＡＮ７５２にわたる通信を確立するための他の手段を含んでいる。モデム７５４は、内蔵または外付けであってもよく、ユーザ入力インターフェース７４２または他の適切な機構を介してシステム・バス７０６に接続することができる。

ネットワーク化された環境において、パーソナル・コンピュータ７００に関連して示されるプログラム・モジュール、またはその部分は、リモート記憶装置に格納することもできる。限定的ではなく例示的に、図７では、リモート・アプリケーション・プログラム７１６をリモート・コンピュータ７５０のメモリ素子に常駐するものとして示している。図示され説明されているネットワーク接続が例示的なものであり、コンピュータ間の通信リンクを確立する他の手段も使用できることを理解されたい。

結論
前述の方法およびシステムの一部は、ビット・レベル以外のレベルにおいてスタート・コード・エミュレーション防止を提供することができる。これは、処理の複雑さを緩和することができるので有利である。さらに、一部の実施例は、必要に応じて整数バイト数が確実に送信されるようにできるデータ・スタッフィングのための簡単明瞭な方法を提供する。さらに、さまざまな実施例が、必ずしもデータ境界と一致しないビット・シフトされたポジションでのスタート・コード・エミュレーション防止を提供することができる。さらにもう１つ実施例では、さまざまな処理効率を達成することができ、しかもデータ境界が失われた場合にデータ境界整列を回復できる機構を提供することができる。さらに他の利点も、当業者には明らかとなろう。

本発明について構造的機能および／または方法論的ステップに特有の表現で説明してきたが、添付の請求の範囲に定義されている本発明が、説明されている特定の機能またはステップに必ずしも限定されないことを理解されたい。むしろ、特定の機能およびステップは、特許請求された本発明を実装する好ましい形態として開示されている。

１つの実施例による方法のステップを説明する流れ図である。１つの実施例による方法のステップを説明する流れ図である。１つの実施例による方法のステップを説明する流れ図である。１つの実施例による処理方法の１つの態様を表す図である。１つの実施例による処理方法の１つの態様を表す図である。１つの実施例による方法のステップを説明する流れ図である。１つまたは複数の実施例が関連して実装されるコンピューティング環境についての高度のレベルの図である。

Claims

データ・ストリーム内に少なくとも１つのスタート・コードを備える符号化データを受信すること、
前記符号化データは、前記スタート・コードのパターンに関連して、符号化データ上にエミュレーション防止データ挿入を実施するための検索パターンとして特徴的なパターンを使用するエンコーダからもたらされ、当該特徴的なパターンは、前記スタート・コードのパターンの複数のビット単位シフトのうちの任意の１つに発生する複数のバイト、および１つまたは複数のバイト整列位置と相対的なあらゆるビット・シフトされた位置で前記スタート・コードのパターンのエミュレーションを防止するように識別される複数のバイトを含み、前記受信データのバイト境界で、スタート・コードのパターンの位置に基づいてバイト整列を回復すること、
エミュレーション防止バイトを備える複数のバイトのパターンを、前記受信したデータ内の前記１つまたは複数のバイト整列された位置で、検索すること、および
前記受信データ内に前記エミュレーション防止バイトを備える複数のバイトからなる前記パターンの発見に応答して、前記受信データから前記エミュレーション防止バイトを削除すること
を備えることを特徴とする復号化用に符号化データを準備する方法。
前記エミュレーション防止バイトを備える複数のバイトからなる前記パターンは、前記エミュレーション防止データの挿入期間、前記エンコーダによって使用される置き換えパターンに等しいことを特徴とする請求項１に記載の方法。
前記特徴的なパターンからなる前記複数のバイトのそれぞれは、０ｘ００の値を有し、前記データ内に前記特徴的なパターンが発見された場合、前記エミュレーション防止バイトを備える複数のバイトからなる前記パターンは、
それぞれ値が０ｘ００に等しいＮ−１バイト、続いて、前記エミュレーション防止バイト、続いて、値が０ｘ００に等しいＮ番目のバイト
の置換パターンであることを特徴とする請求項１に記載の方法。
符号化データ・ストリームとして配信用データをフォーマットする方法であって、
符号化されているデータ内で、複数のデータを含む、１つまたは複数の検索パターンを検索すること、および
前記符号化されている前記データ内で前記１つまたは複数の検索パターンが発見された場合、前記発見されたパターンを符号化されたデータ・ストリーム内で、前記発見されたパターンのデータとエミュレーション防止バイトを備える置換パターンに置換すること、
を備え、
スタート・コードのパターンに関連して、符号化されている前記データ上にエミュレーション防止データの挿入を実施するための前記１つまたは複数の検索パターンのうちの１つとして特徴的なパターンが使用され、当該特徴的なパターンは、前記スタート・コードのパターンの複数のビット単位シフトのうちの任意の１つに発生する複数のバイト、および１つまたは複数のバイト整列位置と相対的なあらゆるビット・シフトされた位置で前記スタート・コードのパターンのエミュレーションを防止するように識別される複数のバイトを含み、これにより、バイト境界で前記スタート・コードの位置に基づいて、デコーダでバイト整列を回復するのを容易にする
ことを特徴とする方法。
前記特徴的なパターンからなる前記複数のバイトのそれぞれは、０ｘ００の値を有し、符号化されている前記データ内に前記特徴的なパターンが発見された場合、前記置換パターンは、
それぞれ値が０ｘ００に等しいＮ−１バイト、続いて、前記エミュレーション防止バイト、続いて、値が０ｘ００に等しいＮ番目のバイト
であることを特徴とする請求項４に記載の方法。
前記バイト整列の回復を容易にするために、前記スタート・コード・パターンとしてスタート・コード・プレフィックスを後続する充填バイトを送ることをさらに備えることを特徴とする請求項４に記載の方法。
前記送ることの前に、スタート・コード・タイプに依存して前記充填バイトを送るべきか否かを決定することを特徴とする請求項６に記載の方法。
前記符号化データは、ビデオ・データを備えることを特徴とする請求項１乃至７のいずれかに記載の方法。
前記符号化データは、オーディオ・データを備えることを特徴とする請求項１乃至７のいずれかに記載の方法。
前記エミュレーション防止バイトは、０ｘ０３に等しいことを特徴とする請求項１乃至７のいずれかに記載の方法。
前記スタート・コード・パターンは、スタート・コード・プレフィックスを備えることを特徴とする請求項１乃至５のいずれかに記載の方法。
前記スタート・コード・プレフィックスは、複数の連続する０からなる文字列を備えることを特徴とする請求項１１に記載の方法。
前記スタート・コード・プレフィックスは、直後に１を後続する複数の連続する０からなる文字列を備えることを特徴とする請求項１１に記載の方法。
前記スタート・コード・パターンの前記位置は、直後に１を後続する３１個の連続する０からなる文字列で指し示されることを特徴とする請求項１乃至５のいずれかに記載の方法。
前記特徴的なパターンは、３つの０の値のバイトを有することを特徴とする請求項１乃至７のいずれかに記載の方法。
請求項１乃至１５のいずれかに記載の方法を、１つまたは複数のコンピュータに実行させるコンピュータ実行可能命令コードを格納している１つまたは複数のコンピュータ読み取り可能な記憶媒体。
データ・ストリーム内に少なくとも１つのスタート・コードを備える符号化データを受信する手段、
前記符号化データは、前記スタート・コードのパターンに関連して、符号化データ上にエミュレーション防止データ挿入を実施するための検索パターンとして特徴的なパターンを使用するエンコーダからもたらされ、当該特徴的なパターンは、前記スタート・コードのパターンの複数のビット単位シフトのうちの任意の１つに発生する複数のバイト、および１つまたは複数のバイト整列位置と相対的なあらゆるビット・シフトされた位置で前記スタート・コードのパターンのエミュレーションを防止するように識別される複数のバイトを含み、前記受信データのバイト境界で、スタート・コードのパターンの位置に基づいてバイト整列を回復する手段、
エミュレーション防止バイトを備える複数のバイトのパターンを、前記受信したデータ内の前記１つまたは複数のバイト整列された位置で、検索する手段、および
前記受信データ内に前記エミュレーション防止バイトを備える複数のバイトからなる前記パターンの発見に応答して、前記受信データから前記エミュレーション防止バイトを削除する手段
を備えることを特徴とするデコーダ。
符号化されているデータ内で、複数のデータを含む、１つまたは複数の検索パターンを検索する手段、および
前記符号化されている前記データ内で前記１つまたは複数の検索パターンが発見された場合、前記発見されたパターンを符号化されたデータ・ストリーム内で、前記発見されたパターンのデータとエミュレーション防止バイトを備える置換パターンに置換する手段
を備え、
スタート・コードのパターンに関連して、符号化されている前記データ上にエミュレーション防止データの挿入を実施するための前記１つまたは複数の検索パターンのうちの１つとして特徴的なパターンが使用され、当該特徴的なパターンは、前記スタート・コードのパターンの複数のビット単位シフトのうちの任意の１つに発生する複数のバイト、および１つまたは複数のバイト整列位置と相対的なあらゆるビット・シフトされた位置で前記スタート・コードのパターンのエミュレーションを防止するように識別される複数のバイトを含み、これにより、バイト境界で前記スタート・コードの位置に基づいて、デコーダでバイト整列を回復するのを容易にする
ことを特徴とするエンコーダ。