"データストリームのランレングス符号化方法であって、前記データストリームが、ディスプレイでのビデオ表示のためのビットマップフォーマット化された字幕スーパーデータまたはメニューデータを含み、当該字幕スーパーデータまたはメニューデータはグラフィクスGまたはテキストTEXTまたはその双方を含み、一つの色は所定色であり、当該方法は、前記所定色のピクセルを2バイトまたは3バイトの第1の符号語へ符号化するステップであって、当該第1の符号語はランレングス値を含み、3バイトの第1の符号語に含まれるランレングス値はディスプレイBTVの表示の幅を超過する、該ステップと、前記所定色以外の色のピクセルを1バイトまたは3バイトまたは4バイトの第2の符号語へ符号化するステップであって、当該第2の符号語は1から255までの範囲の色値を含み、3バイトまたは4バイトの第2の符号語はランレングス値を含み、4バイトの第2の符号語に含まれるランレングス値はディスプレイBTVの表示の幅を超過する、ステップと、を含み、1バイトの前記第2の符号語が単一のピクセルの前記所定色以外の色を示し、2バイトまたは3バイトの前記第1の符号語の前記第2のバイトの第1および第2のビット、および3バイトまたは4バイトの前記第2の符号語の前記第2のバイトの第1および第2のビットが、前記符号語のタイプを示す、前記方法。放送用または映画ディスク用の作製されたオーディオビジュアル素材AV素材にかけられる字幕スーパーとしてまず単純な静的なstaticテキスト情報、例えばクローズドキャプション、テレテキストまたはDVBスーパーなどを表現するために最適化が行われてきたが、新たなHDTVフォーマットに適したテキスト情報およびグラフィクス情報の形成および動画化に対するマルチメディア技術の発展はより進んだビットマップ符号化法の適応化を要求している。図1にはビデオフレームTVと、テキストおよびグラフィクス要素Gを含む字幕スーパーエリアSUBとが示されており、字幕スーパーエリアSUBはビットマップ符号化されている。字幕スーパーエリアSUBの寸法は、例えばブルーレイディスクプリレコーデッド規格BDPでは1次元のみであればビデオフレームの寸法より大きくてもよいと定められているので、ビデオフレームの寸法を超えることがある。その場合ラインは表示の前にクロッピングされる。すなわち、フレームのそれぞれの大きさに一致する部分が仮想ラインから切り出され、ビデオ画像に重ねられて表示されるのである。図1では、幅BSUBの字幕スーパーエリアSUBがクロッピングされて、幅BTVの部分のみが視えるようになっている。標準的なHDTVでは、例えばBDPに使用されているが、幅BTVは1920ピクセルであるが、BSUBはそれよりもはるかに大きい。字幕スーパーエリアSUBは矩形であるので、このエリアのピクセルはほとんどが透明である。その拡大図が図2に概略的に示されている。HDTVの画面TV上のラインSL1,SL2ははっきりと視えるように数ピクセル分の幅を有していなければならない。ここでのラインとは水平方向のストラクチャであることは言うまでもない。字幕スーパーデータの各ラインは通常同じ色の1つまたは複数のピクセルシーケンスを含んでいる。図2では字幕スーパーラインSL1の一部は透明なシーケンスPS1,PS5、可視の単一のピクセルPS4、可視のより短いシーケンスPS2および可視のより長いシーケンスPS3を含んでいる。ライン内のほとんどのピクセルが透明である。透明な箇所はキャラクタ間および字幕スーパーラインの開始部および終了部である。いずれにしろラインの開始部および終了部は透明であるので、各ラインは色付き部分よりも透明部分のほうを多く含む。例えばキャラクタに用いられている、透明でないピクセルシーケンスについて、最も良くある場合は64ピクセル未満の長さのシーケンスであるが、透明部分PS1,PS5は通常、これよりも長い。このことは、粗い見積もりから認められる。少なくとも25個のキャラクタが同時に表示され、キャラクタ間のスペースが1キャラクタ幅の約1/4であると仮定すると、ライン内の単一のキャラクタは1920/248/10=62ピクセル以下となる。しばしば、ラインSL2はきわめてわずかな可視のピクセルを含むので、かなり長い透明なシーケンスを幾つか含むことになる。本発明の好適な実施例として、符号が図3に示されている。これは、1バイトから4バイトまでの範囲の長さの符号語を含むランレングス符号であり、なお、1バイトが8ビットである。これにより異なる256色および1つの所定色を符号化することができる。この所定色はこの実施例では‘透明’であるが、適切であれば他のどんな色であってもよい。カラールックアップテーブルCLUTは復号済みの色値を実際の表示色へ変換する。さらに同じ色のピクセルシーケンスは、63ピクセルまでのより短い範囲と、16383ピクセルまでのより長い範囲との2つの範囲へ分割される。1バイト長の最短の符号語は、所定色ここでは透明ではない個々の色の単一のピクセルの符号化に用いられる。色値CCCCCCCCは1~255であり、直接または間接に色を表す。これは、例えば実際のカラーコードを含んでいるカラールックアップテーブルCLUTの見出し語を表す。0のみを含む8ビット値00000000はエスケープシーケンスとして用いられ、次のビットが同じ符号語の一部であると見なされることを示す。この場合、符号語のツリーは、次の2ビットでマークされる4つのブランチを有する。第1のブランチでは、上記次の2ビットが00で示され、有効符号語が2バイトを有する。所定色例えば、透明のより63ピクセルまでの短いシーケンスが符号化される。このブランチの唯一無効な符号語は0しか含まない符号語である。なぜなら0は有効なシーケンス長が存在しないことを表すからである。この符号語0000000000000000は他の目的に使用される。本発明によれば、これは最短の冗長な符号語であるので、ライン終了を示すために用いられる。第2のブランチでは、上記次の2ビットが01bで示され、符号語は、他の1バイトを含む。14個のLビットが所定色のピクセルシーケンススの長さを符号化するために使用される。したがってシーケンス長は214-1=16383である。Lビットが64よりも小さい値を有する場合は符号語は冗長であり、他の目的に使用される。第3のブランチでは、上記次の2ビットが10bで示され、符号語は、付加的な1バイトを含む。第2のバイトのうち6個のLビットは、63ピクセルまでのより短いシーケンスの長さを表し、これよりも短いシーケンスは、上記所定色とは異なる色を有する。実際の色は第3のバイトの値CCCCCCCCで直接または間接に表される。3よりも小さいシーケンスの長さLLLLLLの符号語は冗長である。なぜならこの色の1個または2個のピクセルのシーケンスは上述したようにピクセル当たり1バイトを使用して容易に符号化される。0零のシーケンスの長さは無効である。この符号語は他の目的に使用される。第4のブランチでは、上記次の2ビットが11bで示され、符号語は付加的な2バイトを含む。ここで第2のバイトの残りの6ビットおよび第3のバイトにより64~16383ピクセルのより長いシーケンスの長さを与える。第4のバイトの色値CCCCCCCCは上記所定色とは異なる色を直接または間接に与える。64よりも短いシーケンスの長さの符号語は冗長である。なぜなら、第3のブランチを用いて容易に符号化されるからである。この符号語は他の目的に使用される。上述の冗長な符号語は例えば内部のチェックサムまたは他の情報を追加するというような、符号を拡張するために使用される。図3に示されている拡張ランレングス符号化テーブルは、上述した2つの大きな利点を提供する。第1に、透明なエリア、小さなグラフィクスオブジェクトおよび通常のスーパーインポーズテキストを含む典型的な字幕スーパーストリームを最もコンパクトに符号化することを考慮に入れる。小さいカラフルなグラフィクスに使用されるような、色付きの単一のピクセルは1バイトで符号化される。主要色dominantcolor、例えばBDPでの字幕スーパーについての透明なピクセルは、ランレングスと共に符号化される。ランレングス符号は2つの異なるサイズまたは2つのピクセル量で利用される。第1のステップでは、63ピクセルまでのランレングスが上記主要色に対する2バイト符号語およびその他の色に対する3バイト符号語として利用される。第2のステップでは、16383ピクセルまでのランレングスが上記主要色に対する3バイト符号語およびその他の色に対する4バイト符号語として利用される。ピクセルストリング終了符号またはライン終了符号は独自の2バイト符号語であり、再同期に用いられる。第2に、一符号語あたり16383ピクセルまでの字幕スーパーエリアについてより長いシーケンスの利用可能性は、冗長性が低減され、それ故にデータ量が低減される。このことにより、1つのチャネルをシェアして伝送される個別のデータストリーム、例えば同じピックアップで伝送される光記憶媒体上のマルチデータストリームを用いるアプリケーションに対して、同じデータ量で、字幕スーパーストリームのより多くの部分がロードされ、それにより、字幕スーパーストリームへのアクセス頻度を低減することができる。本発明の他の特徴はトランスポートパケットを用いたデータストリームの伝送、例えばパケット化エレメンタリストリームPESの伝送の更なる最適化をすることである。ビットマップのファイルサイズが大きいので、そのようなデータをパッケージすることは、例えばデータをオブジェクトデータセグメントODSにおいて、問題となる。ODSの最大サイズは他の要素、例えばPESパケットサイズによって制限されていることが多い。大きなビットマップをこのようなパケットに合わせるには、ビットマップを符号化前に小さなビットマップの部分pieceへ切り分けることが必要となり、それは圧縮率を低減することになる。こうしたビットマップ分割を克服するため、BDPまたは互換性のあるアプリケーションについて、新たな拡張オブジェクトデータセグメントExODSが、図4に示されているように提供される。ExODSは制限されたサイズのセグメントおよびPESパケットのシーケンスへそれに合わせるために切り分けられる各フラグメントを表すデータストラクチャである。ODS全体は連続するExODSの個々の部分のシーケンスを連結することにより再構成される。ExODSのシーケンスの開始部および終了部は個々のフラグfirstinsequence,lastinsequenceにより表される。フラグfirstinsequenceが1であれば、新たなシーケンスが開始される。フラグfirstinsequenceが1にセットされたExODSは、大きさobjectwidth,objectheightを含むことにより解凍後のビットマップの大きさをも示す。ビットマップの大きさを示すことの利点は、解凍が開始される前にターゲットメモリの割り当てを支援できることである。他の利点として、示されたビットマップの大きさを復号処理中にビットマップサイズのクロスチェックにも使用できることが挙げられる。フラグlastinsequenceが1であれば、そのExODSがODS全体の最後のExODSであることが示される。またフラグfirstinsequence,lastinsequenceのどちらもセットされていないExODSも存在する。これは一つのシーケンスの開始部と終了部との間にあるExODSの部分である。フラグfirstinsequence,lastinsequenceの双方がセットされているのは、単一のExODS内にODSが含まれる場合である。字幕スーパーのPESパケットサイズについて単一のODSのサイズの制限を克服するため、上述のタイプのExODSはODSの部分に対するコンテナ、例えばHDTVアプリケーション用の大きなODSをパッケージするために導入される。ODSの部分のほか、ExODSは最初の部分、最後の部分、内部の部分を含むか否か、またはExODSシーケンスの1つの完全なピースを含むか否かを示すフラグを含む。さらにExODSのシーケンスの最初のピースが伝送される場合、得られるODSの大きさすなわち符号化されたビットマップの高さおよび幅もセグメントに含まれる。示されるビットマップの大きさはクロスチェックを復号処理するために使用できる。本発明の方法は、ブルーレイディスクプリレコーデッド規格BDPディスクまたは一般的な高解像度ビデオHDTVなどの記録再生または放送のアプリケーションにおいて、アニメーション、メニュー、ナビゲーション、ロゴ、広告、メッセージその他のためのテキストデータ、イメージデータまたはグラフィクスデータを含むビットマップデータストリームの圧縮に使用できる。"