(57)【特許請求の範囲】
【請求項１】
プログラムストリーム(PS)フォーマットを有する入力データストリームを、トランスポートストリーム(TS)フォーマットを有する出力データストリームに変換する方法であって、前記方法が、
(a)  当該入力データストリームから連続するデータブロックを読み取るステップであって、当該入力データストリームは、PSターゲット復号器モデルに準拠してスケジューリングされた、少なくとも第1および第2基本ストリームのデータを含むステップと、
(b)  前記第1および第2基本ストリームのデータをそれぞれ第1および第2キューに蓄積するステップと、
(c)  前記第1および第2基本ストリーム用のそれぞれ仮想の第1および第2バッファを含むTSターゲット復号器モデルを確立するステップと、
(d)  当該第1および第2基本ストリームを前記TSフォーマットで伝える当該出力データストリームを形成するために、前記TSターゲット復号器モデルを参照することにより一連のトランスポートパケットを生成するステップと、
(e)  生成される各トランスポートパケットと当該TSターゲット復号器モデルの所定の特性とに呼応して、当該TSターゲット復号器内の当該仮想の第1および第2バッファの状態を更新するステップと、
を有し、
各トランスポートパケットが、前記入力データストリーム内の当該第１及び第２基本ストリームの前記スケジューリングと、当該TSターゲット復号器モデル内の当該第1および第2バッファの状態とに応じて、前記第1キューまたは前記第2キュー、またはこれらいずれのキューからのものでないデータを含み、
当該入力データストリームの基準クロックが、当該出力データストリームの基準クロックより所定の待ちしきい値を超えて進んでいる場合に、当該入力データストリームからのさらなるデータブロックの読み取りを禁止し、
前記PSフォーマットとTSフォーマットとの各々が、
(i)  共通のプレゼンテーションタイムを有する、前記第1および第2基本ストリーム内の各プレゼンテーションユニットの伝送タイムの間の最大時間差（「スキュー」）に対する上限に関する制約、
を定義すると共に、
(ii)  伝送と復号との間に各基本ストリームのデータをバッファリングするための容量と、
(iii)  トランスポートストリームから復号用バッファへの、1アクセスユニットを単位とする各基本ストリームのデータ伝送速度と、
の少なくとも一つに関する制約を定義し、
前記第2基本ストリームに対する前記バッファ制約(ii)が、前記PSフォーマットにおけるよりも前記TSフォーマットにおける方がより厳しく、かつ、当該待ちしきい値が、前記PSターゲット復号器内のバッファに収容できるデータ量と、前記TSターゲット復号器内のバッファに収容できるデータ量との差に相当する余分なデータの量を収容するのに十分であり、
当該待ちしきい値が、前記PSフォーマットで許容される前記スキューの1/5未満である、
方法。
【請求項２】
当該アクセスユニットが、圧縮されたオーディオフレームを有する、請求項１に記載の方法。
【請求項３】
前記第1基本ストリームの平均データ速度が、前記第2基本ストリームの平均データ速度より実質的に高い、請求項１又は２に記載の方法。
【請求項４】
前記第1基本ストリームの前記データが、符号化されたビデオピクチャを有し、かつ前記第2基本ストリームの前記データが、符号化されたオーディオフレームを有する、請求項１〜３のいずれかに記載の方法。
【請求項５】
当該TSフォーマットが、MPEG-2トランスポートストリーム仕様に準拠する一方、当該PSフォーマットが、MPEG-2プログラムストリーム仕様に準拠し、これら両仕様がITU-T勧告H.222.0およびIS0/IEC 13818-1に定義されている、請求項１〜４のいずれかに記載の方法。
【請求項６】
記録されたオーディオ-ビジュアルプログラムを再生する方法であって、PSフォーマットのデータストリームが、データチャネルから読み取られ、かつ請求項１〜５のいずれかに記載の方法によってTSフォーマットに変換され、かつさらなるチャネルを介してTS互換復号器に送られる、方法。
【請求項７】
当該データチャネルが、記録担体上の当該入力データストリームの記録を有する、請求項６に記載の方法。
【請求項８】
少なくとも2つの基本ストリームのデータがマルチプレキシングされている第１フォーマットの入力データストリームを受信するための受信手段と、前記第１フォーマットの入力データストリームを変換して第2フォーマットの出力データストリームを生成するための変換手段とを有する装置であって、当該変換手段が、請求項１〜７のいずれかに記載の方法を実施するために特に適合化された手段を有する、装置。
【請求項９】
前記装置が、
デジタルビデオプログラム用のスタンドアロン型の復号器装置、
ビデオプログラムの表示機能を有するプレゼンテーション装置、
デジタルビデオプログラムを再生するか、または再生および記録するための再生装置、のうちの1つを有する、請求項８に記載の装置。
【発明の詳細な説明】
【０００１】
【発明が属する技術分野】
本発明は、マルチプレキシングされたデータストリームを1つのマルチプレキシングフォーマットから別のフォーマットに変換する(トランスマルチプレキシングする)方法および装置に関する。本発明は、特に、例えば、MPEG-2仕様(ITU-T勧告H.222.0 | ISO/IEC 13818-1)に準拠してプログラムストリームフォーマットからトランスポートストリームフォーマットにビデオストリームおよびオーディオストリームをトランスマルチプレキシングすることに応用できる。
【０００２】
上述のMPEG-2標準は、マルチメディアのマルチプレキシング、同期、タイムベースの回復の一般的な方法を規定する。この仕様は、各基本ビットストリーム（ビデオ、オーディオ、その他のデータ）がパケット化基本ストリーム(PES)にセグメント化され、かつ、各パケットが2種類のストリームタイプのいずれかにマルチプレキシングされる、パケットベースのマルチメディア・マルチプレキシングを規定する。プログラムストリーム(PS)は、可変長のPESパケットのマルチプレクスであり、ディスク上の記録など、エラーのない環境での使用のためにデザインされている。トランスポートストリーム(TS)は、188バイトの固定長パケットで構成され、1つのプログラムの各種のPESパケットをマルチプレキシングするのみでなく、複数のプログラム(programme)をマルチプレキシングすることができ、放送などエラーのある環境での使用のためにデザインされている。マルチメディア同期とタイムベーストリームカバリは、システムタイムクロックとプレゼンテーション／復号用にタイムスタンプを使用することにより達成される。  ストリームの各タイプは、異なる状況において利点と欠点をもつので、MPEG-2仕様は、この2つのフォーマット間の変換が望ましいことが認識されている。しかし、フォーマットの違いと、特に「ターゲット復号器」モデル（これによって特にバッファサイズ、時間遅延、データ速度の違いなどに関する制約が決まる）に起因して、各種の基本ストリームを、一方のフォーマットと同じスケジューリングで他方のフォーマットにおいてスケジューリングすることができない。このため、一方のタイプのストリームを他方に変換するときに、基本ストリームデータを逆マルチプレキシング(demultiplex)してから再びマチルプレキシングする必要がある。また、ランダムアクセスや編集を行えるようにデザインされたPSデータに構造を置き換えるためのシステム情報が、一般にTSブロードキャストに存在しないという要因もある。
【０００３】
【従来の技術】
EP-A-0 833 514（ソニー）は、レコーダ／プレーヤ装置とプレゼンテーション（ディスプレイ装置）のシステムを提案している。例えば、プレーヤは、ディスクからPSフォーマットのデータを読み取り、それを表示用のTSフォーマットに変換する。しかし、その実施例におけるバッファサイズは、有効なPSフォーマットを有効なTSフォーマットに変換するのに各種の基本ストリームの再スケジューリングを必要とする各種の制約を考慮しているようには見えない。実際に、TS仕様自体によって課せられる制約は、少なくとも1秒分のビデオ情報用のバッファを必要とすることが判明していて、0からストリームを形成する場合と同じ処理量が必要となるであろう。
【０００４】
【課題を解決するための手段】
本発明の目的は、MPEGプログラムストリームとトランスポートストリームなどのフォーマットの間でデータストリームを変換するときに必要となる計算負荷および／または記憶域スペースを低減することである。任意の2つのフォーマットの間でマルチプレキシング・ストリームを変換するときには一般に同様の問題が生じるので、本発明は、MPEG-2準拠ストリームの厳密な範囲を超えて適用可能であることが理解されるであろう。
【０００５】
本発明者は、1つのフォーマットから別のフォーマットに変換するためには再スケジューリングは避けられないが、変換元のフォーマットに固有な制約を利用することで、変換に必要なバッファのサイズおよび／または処理量を低減させることが可能であると認識した。
【０００６】
本発明は、プログラムストリーム(PS)フォーマットを有する入力データストリームを、トランスポートストリーム(TS)フォーマットを有する出力データストリームに変換する方法であって、前記方法が、
(a)  当該入力データストリームの連続するデータブロックを読み取るステップであって、当該入力データストリームは、PSターゲット復号器モデルに準拠してスケジューリング（形成およびマルチプレキシング）された、少なくとも第1および第2基本ストリームのデータを含むステップと、
(b)  前記第1および第2基本ストリームのデータをそれぞれ第1および第2キューに蓄積するステップと、
(c)  前記第1および第2基本ストリーム用のそれぞれ仮想第1および第2バッファを含むTSターゲット復号器モデルを確立するステップと、
(d)  当該第1および第2基本ストリームを伝える、当該TSフォーマットにおける当該出力データストリームを形成する一連のトランスポートパケットを生成するステップと、
(e)  生成される各トランスポートパケットと当該TSターゲット復号器モデルの所定の特性とに呼応して、当該TSターゲット復号器内の当該仮想第1および第2バッファの状態を更新するステップとを有する方法において、
各トランスポートパケットが、前記入力データストリーム内の当該第１及び第２基本ストリームの前記スケジューリングと、当該TSターゲット復号器モデル内の当該第1および第2バッファの状態とに応じて、前記第1キューまたは前記第2キュー、またはこれらのいずれのキューからのものでないデータを含み、かつ前記方法が、当該入力データストリームの基準クロックが、当該出力データストリームの基準クロックより所定の待ちしきい値だけ前に進んでいる場合に、当該入力データストリームからのさらなるデータブロックの読み取りを禁止する、
方法を提供する。
【０００７】
本発明は、少なくとも当該データの第1および第2基本ストリームが、前記PSフォーマットで符号化され、かつパケットヘッダを有する基本ストリームパケットに分割され、かつ前記パケットが全体としてインターリーブされ、その一方で、この基本ストリームパケットが、より小さい複数のトランスポートパケットにTSフォーマットでさらに細かく分割され、かつ前記第1および第2基本ストリームの前記パケットが、互いに、およびこのどちらでもないストリームからのデータを伝えるトランスポートパケットとインターリーブされる、方法をさらに提供する。
【０００８】
以下に説明されている本発明の実施例において、各基本ストリームからさらに細かい基本ストリームパケットへの細分割は、前記入力ストリームと前記出力ストリームとで同一である。
【０００９】
本発明の実施例において、前記TSフォーマットのデータストリームは、一定のデータ速度でよく、当該トランスポートパケットのサイズと期間が均一である。
【００１０】
本発明の実施例において、前記入力ストリームは、ブロックで読み取ることができ、その場合の各ブロックは、少なくとも1つの完全な基本ストリームパケットを含み、かつ1つの基本ストリームからのパケットのみを含む。
【００１１】
本発明の実施例において、各ブロックは、PS伝送タイムコードを含むことができ、TSトランスポートタイムコードは、各トランスポートパケットの生成によって進められ、かつ最初に前記PS伝送タイムコードと同期される。
【００１２】
本発明の一実施例の場合、  前記PSフォーマットとTSフォーマットの各々が、
(i)  共通のプレゼンテーションタイムを有する、前記第1および第2基本ストリーム内の各プレゼンテーションユニットの伝送タイムの間の最大時間差（「スキュー」）に対する上限に関する制約、および
(ii)  伝送と復号の間に各基本ストリームのデータをバッファリングするための容量と、
(iii)  トランスポートストリームから復号用バッファへの、1アクセスユニットを単位とする各基本ストリームのデータ伝送速度との、少なくとも一つの制約
を定義する。
【００１３】
特定の実施例においては、前記第2基本ストリームに対する前記バッファ制約(ii)は、前記PSフォーマットにおけるよりも前記TSフォーマットにおける方がより厳しく、かつ、当該待ちしきい値は、前記PSターゲット復号器内の前記バッファに収容できるデータ量と、前記TSターゲット復号器内に収容できるデータ量との差に相当する余分なデータの量に対応するのに十分である。
【００１４】
別の実施例においては、前記第2基本ストリームに対する当該最小速度制約(iii)は、前記PSフォーマットにおけるよりも前記TSフォーマットにおける方がより厳しく、かつ、当該待ちしきい値は、前記第2基本ストリーム内のアクセスユニットの転送のための余分な時間を与えるのに十分であり、前記余分な時間とは、前記PSフォーマットの制約内でそのようなアクセスユニットを伝送するための最短時間と、前記TSフォーマットの制約内で前記同じアクセスユニットを伝送するための最長時間との間の差に対応する。
【００１５】
伝送するデータの量と各アクセスユニットの前記プレゼンテーション期間の一方または両方を変えられるように、前記PSフォーマットとTSフォーマットは、当該第2基本ストリームに各種の符号化パラメータの使用を可能とするものであり、その一方で、当該待ちしきい値は、前記使用できる1つ以上の符号化パラメータの間で決まる必要な最大余分時間に従って固定される。
【００１６】
以下に説明されている本発明の固有の実施例においては、前記待ちしきい値は、前記プログラムストリームで許容される前記スキューの1/5未満とすることができる。
【００１７】
特定の実施例においては、前記アクセスユニットは、圧縮されたオーディオフレームを有する。
【００１８】
本発明は、  第2の所定のターゲット復号器モデルに準拠するトランスポートパケットの連続ストリームを生成するために、データの第1および第2基本ストリームを再マルチプレキシングする方法であって、当該第1および第2ストリームの前記データが、これと異なる第1の所定のターゲット復号器モデルに準拠してそれ以前にマルチプレキシングされていて、当該データが、入力チャネルから必要時に読み取られ、かつ当該データの前記読み取りが、前記第1および第2ターゲットモデルにおける差を補正するのに十分なだけ、前記第2基本ストリームの再マルチプレキシングにおける前記進行より十分前であると判断されると、当該読み取りが、前記第2ターゲット復号器モデル内の前記第1ストリームのデータ用の空きの有無に関係なく、前記第2基本ストリームの再マルチプレキシングにおける進行を参照して制約される、方法を、さらに提供する。
【００１９】
本発明の一実施例の場合、前記第1および第2ターゲット復号器モデルそれぞれは、各基本ストリームに対して、復号するデータ用の有限サイズの各バッファを定義し、かつ、少なくとも前記第2基本ストリーム用の前記バッファは、前記PSターゲット復号器内よりも前記TSターゲット復号器内の方が小さい。
【００２０】
本発明の実施例において、前記第1基本ストリームの平均データ速度は、前記第２基本ストリームの平均データ速度より実質的に高い。
【００２１】
以下に説明されている特定の実施例においては、前記第1基本ストリームの前記データは、符号化されたビデオピクチャを有し、かつ前記第2基本ストリームの前記データは、符号化されたオーディオフレームを有する。
【００２２】
本発明は、プログラムストリーム(PS)フォーマットを有する入力データストリームを、トランスポートストリーム(TS)を有する出力データストリームに変換する方法において、前記TSフォーマットが、前記MPEG-2トランスポートストリーム仕様に準拠し、その一方で、当該PSフォーマットが、前記MPEG-2プログラムストリーム仕様に準拠し、いずれのフォーマットもITU-T勧告H.222.0およびIS0/IEC 13818-1に定義される、方法をさらに提供する。
【００２３】
本発明は、記録されたオーディオ-ビジュアルプログラムを再現する方法において、PSフォーマットのデータストリームがデータチャネルから読み取られ、かつ前述されている方法によってTSフォーマットに変換され、かつさらなるチャネルを介してTS互換復号器に送られる方法を提供する。
【００２４】
本発明の一実施例の場合、前記チャネルは、記録担体上の当該入力データストリームの記録を有する。
【００２５】
本発明は、上に記載されている本発明による前記方法のいずれかを実施するために特に適合化された手段を有する装置を、さらに提供する。このような装置は、例えば、スタンドアロン型の復号器装置（セットトップボックス）、プレゼンテーション装置（テレビ受像器など）、または記録／再生装置（デジタルビデオカセットレコーダ）の一部を形成することができる。
【００２６】
当業者には、上記に識別される範囲を超える本発明のその他の特徴および利点と、本発明の多くの修正および変更が、固有の実施例の以下の説明を考慮することによって明らかになるであろう。
【００２７】
【発明を実施するための形態】
以下に、本発明の実施例を、単なる例として、添付図面を参照しながら説明する。
【００２８】
システムの例
図1は、ホームデジタルビデオ・エンターテインメントシステムの一例であり、このシステムは、デジタルTVチューナ100と、デジタルビデオ信号を復号して有料チャネルなどへのアクセスを制御するための「セットトップボックス」102と、公知の光ディスクビデオシステムまたは将来的なDVRレコーダなどのデジタルビデオ再生／記録デバイス104と、記憶媒体自体（ディスク106）とを含んでいる。この例では、衛星放送、またはケーブル放送、地上波放送から、またはディスク106上の記録からのピクチャを表示するために、この機器構成の中で従来のアナログTV受像器108が使用されている。デジタルチューナ100とセットトップボックス102の間で、MPEG互換のトランスポートストリーム(TS)フォーマットの信号は、多数のデジタルTVチャネルを伝え、そのうちのいくつかのチャネルは、特殊な条件的アクセス（有料TV）合意下で復号するためにスクランブルがかけられていてもよい。例えば、DVB、ATSC、ARIBなどの標準のデジタル放送フォーマットは、MPEG-2トランスポートストリームフォーマットでの固有な用途である。
【００２９】
セットトップボックス102は、トランスポートストリームTSの中から目的のプログラムの復号も行い、アナログオーディオ信号とビデオ信号をTV受像器108に送る。これらのアナログ信号は、当然ながら、従来のビデオレコーダ(VCR)によって記録されたものでもよい。しかし、最大限の品質および機能性を得るには、公知の光ディスクビデオシステムやDVRレコーダ104などのダイレクト・デジタル-デジタルレコーダが望ましい。これは、IEEE1394 (「Firewire」)などのデジタルインタフェースを介してセットトップボックスに接続される。これは、選択されたプログラムがより大きなTSマルチプレクスから分離されていて、かつやはりTSフォーマットでプレゼンテーションされる「部分TS」を伝える。これに対して、改良されたディレクトリ構造とランダムアクセス機能を利用するために、プレーヤ/レコーダ104は、TV受像器上のデジタルインタフェースとセットトップボックス102を介して、ディスク106上への記録のためにTSフォーマットをPSフォーマットに変換し、かつ、ディスク106に記録されたPSフォーマットのストリームを再生するために部分TSフォーマットに変換するように構成されている。
【００３０】
本説明は、おもにプログラムストリーム(PS)フォーマットからトランスポートストリーム(TS)フォーマットへの変換のプロセスに関するものであるが、これと逆方向の変換は、「データストリームの変換方法と装置」という名称で、かつ1999年12月30日に出願された英国特許出願番号9930788.6(PHB 34446)の優先権を主張している本出願人の継続中の出願の主題である。これらのフォーマット間での効率的な変換を目的として適用される方法について詳しく説明する前に、この2つのフォーマットについて、図2と図3を参照して以下に詳しく説明する。
【００３１】
トランスポートストリーム(TS)フォーマット
図2は、MPEG-2トランスポートストリーム(TS)フォーマットの重要な特徴と構造を示す。トランスポートストリームTSは、図面においてT-PKTで示されたトランスポートパケットの連続するストリームであり、各ストリームは、188バイトのデータを有し、かつ図の上部に示されているフォーマットを有する。構文(syntax)、セマンティクス、適用可能な制約を含めた、MPEG-2トランスポートストリームの完全な詳細は、ITU-T勧告H.262 | ISO/IEC 13818-2に記載されている。MPEG-2システムについての情報は、オンライン上のhttp://www.mpeg.orgから得られる。要約すれば、各トランスポートパケットは、ヘッダ部分とペイロード部分とを含み、このうちペイロード部分は、図においてバイトDAT-0〜DAT-Nとして示されている。ヘッダは、先頭が個別の同期バイトSYNCであり、そのあとに、トランスポートエラーインジケータTEI (transport error indicator)、ペイロードユニットスタートインジケータUSI (payload unit start indicator)、トランスポート優先度インジケータTPI (transport priority indicator)、パケット識別子PID (packet identification)、トランスポートスクランブリング・コントロールフィールドTSC (transport scrambling control)、アダプテーション・フィールドコントロールAFC (adaptation field control)、連続性カウンタCC (continuity counter)などの各種のフラグとコントロールフィールドが続く。フィールドAFCの内容によっては、通常はペイロードデータに割り当てられるスペースの一部を、アダプテーションフィールドAFが占めることがある。
【００３２】
DVBデジタル放送フォーマットの例の場合、TSストリームのデータ速度は約40（メガビット／秒）であり、これに対してオーディオビジュアルプログラムの代表的なデータ速度は10メガビット／秒以下である。従って、図2においてTSに示されているように、各種のプログラムPROG1とPROG3は、1つのトランスポートストリームにマルチプレキシングすることができる。各トランスポートパケットのフィールドPIDは、そのパケットが対応する1基本ストリームを示し、これらは多数の他のストリームとトランスポートパケット単位でインターリーブされている。1つのプログラムは、例えば、ビデオストリーム（本例ではPID='005'）、オーディオストリーム(PID='006')、テレテキスト(teletext)データストリーム(PID='007')を有する。PID値とプログラムの間の対応関係と、各PIDによって伝えられるデータのタイプは、プログラム固有情報PSI (programme specific information)テーブルのフォーマットで維持される。定期的に、トランスポートストリーム内で、プログラム対応テーブルPAT  (programme association table)が、PID=0のトランスポートパケットの特殊ストリーム内で伝えられる。このPATは、PROG1、PROG3などについて、どのストリームがプログラムマッピングテーブルPMT (programme mapping table)を伝えるかを示す。PMTは、1つのプログラムに関連する異なるPID値を完全にリストし、各PIDの内容（ビデオ、オーディオ、代替言語オーディオなど）を記述する。コントロールを目的とするこれらのテーブルおよびその他のデータを、以下、システム情報と呼ぶ。
【００３３】
トランスポートストリームから1つのプログラム(PROG1)を再現または記録するため、そのPIDを有する連続するトランスポートパケットのペイロードDAT-0〜DAT-Nは、1つのストリームに連結され、このストリームは、パケット化基本ストリームパケットPES-PKTを伝える。このPES-PKTについては、MPEG-2仕様にさらに定義されている。各PESパケットは、先頭が個別のパケットスタートコード接頭辞PSCP(packet start code prefix)である。次に、PESパケットヘッダの中に、基本ストリームのタイプ（例: ビデオ、オーディオ、パディングストリーム、プライベートストリーム）を識別するストリーム識別子SIDがある。PESパケットは、特定の用途において指定されない限りは固定長ではなく、PESパケット長フィールドLENが、PESパケット内のバイト数を指定する。次に、例えば、データアラインメントインジケータDAI、ヘッダ長フィールドHLENなど、各種のコントロール／フラグフィールドC&Fが続く。次に、C&Fフィールド内の対応するフラグの値に応じて、各種のオプションフィールドが、ヘッダHDAT内に存在し、その例として、そのPESパケット内で始まる「プレゼンテーションユニット」（ピクチャ、オーディオフレームなど）をプレゼンテーションするべきタイムとして、システムクロックを基準とするタイムを指定するプレゼンテーションタイムスタンプPTSを入れることができる。場合によっては、プレゼンテーションユニットは、そのプレゼンテーション順序とは異なる順序で復号され、その場合には復号タイムスタンプDTSを入れることができる。
【００３４】
同じSIDを有する連続するPESパケットのペイロードPY-0〜PY-Nは、図2においてESに線図的に示されているデータの連続基本ストリームを形成する。ビデオ基本ストリームES-VIDEOの場合、クリップのピクチャシーケンスSEQが存在し、各シーケンスは、その先頭にシーケンスヘッダSEQHを含む。量子化マトリックスやバッファサイズなどの復号器の各種パラメータは、このシーケンスヘッダに指定される。従って、ビデオストリームの正しい再生は、シーケンスヘッダの位置で復号器を開始させることによってのみ達成される。各シーケンスのデータの中には、それぞれが1つのピクチャ（用途に応じてフィールドまたはフレーム）に対応する、ビデオデータの「アクセスユニット」が1つまたは複数だけ含まれる。各ピクチャの先頭には、ピクチャスタートコードPSCが付く。ピクチャグループGOPには、その先頭にグループスタートコードGSCを付けることができ、これらはいずれも特定のシーケンスヘッダSEQHの後に位置する。
【００３５】
公知のように、MPEG-2およびその他の最近のデジタルフォーマットにおけるピクチャは、時間的な冗長性を低減させるために、互いの参照によって符号化される。動き補償は、1つのピクチャの内容を、隣接する1つまたは複数のピクチャのすでに復号された内容から推定する。従って、ピクチャのグループGOPは、他のピクチャの参照なしに符号化される内部符号化(intra-coded)「I」フレームと、前のIフレームに基づく動きベクトルを使用して符号化される「P」（予測）符号化ピクチャと、シーケンスにおける前と後のIフレームおよび／またはPフレームからの予測によって符号化される双方向予測「B」ピクチャとを有することが出来る。B-ピクチャに必要なデータの量は、P-ピクチャに必要なデータの量より少なく、P-ピクチャに必要なデータの量は、I-ピクチャに必要なデータの量より少ない。しかし、P-ピクチャとB-ピクチャは、必ず他のピクチャを参照して符号化されるので、あるシーケンスの再生を開始するための実際の入口点となるのは、I-ピクチャのみである。さらに、GOPデータのI-ピクチャとP-ピクチャは、対応するB-ピクチャより前に符号化され、正しいプレゼンテーション順序を達成するために、復号のあとに再び並べ替えられる。従って、B-ピクチャとP-ピクチャは、プレゼンテーションタイムスタンプPTSと復号タイムスタンプDTSが異なることがある。
【００３６】
図2の最後には、オーディオ基本ストリームES-AUDIOの表示が示されている。ES-AUDIOは、フレームスタートコードを有する単純なデータフレームFRMを有する。各種のオーディオフォーマットが使用可能であり、サンプリングレート(32kHz、48kHzなど)とデータ速度（例えば、32キロビット／秒または可変）は可変である。オーディオストリームとビデオストリームのこれらの特性とその他の特性は、プログラム固有情報PSIとPESパケットヘッダの中に符号化される。
【００３７】
同じプレゼンテーションタイムスタンプPTSを有するオーディオフレームとビデオピクチャは、復号器の出力において同時にプレゼンテーションされなくてはならない。これに対して、異なる基本ストリームからのデータのパケットのスケジューリングには、大きな自由度があり、例えば、同じPTS値を有するオーディオアクセスユニットとビデオアクセスユニットは、最大1秒離れてトランスポートストリームTSに到達してもよい。
【００３８】
プログラムストリーム(PS)フォーマット
図3は、MPEG-2信号用に指定されている主要フォーマットタイプのうち、もう一方のプログラムストリーム(PS)を示す。図の上部に示されているように、PSは、図2に示されているトランスポートストリームと同じ基本ストリームES-VIDEOとES-AUDIOを伝え、図2と同じPESパケットPES-PKTのフォーマットである。プログラムストリームは、TSほど細かく分割、パケット化されず、一般に、1つのプレゼンテーションに必要なストリームのみを伝える。PESパケットPES-PKT全体は、1つまたは複数個から成るプログラムストリームパックPACKにグループ化され、各パックは個別の基本ヘッダを有する。この基本ヘッダは、個別のパックスタートコードPSCと、基準システムクロック・タイムスタンプSCRと、programme_mux_rateの指示値PMRを有し、PMRは、プログラムストリームPSを復号器に送るべきビットレートである。代表的なprogramme_mux_rateとして、例えば、公知の光ディスクビデオシステム仕様におけるprogramme_mux_rateは、10.08メガビット／秒である。プログラムストリームパックは、オプションとしてスタッフィングSTFとシステムヘッダSYSHを含む。図3の上部に示されているように、任意のビデオパックVまたはオーディオストリームパックA1、A2、...が送信される前に、プログラムストリームは、その先頭が広範なシステムヘッダである。このヘッダは、特定のプログラムの復号のために復号器が適切に設定されることを目的として、符号化と復号器の各種のパラメータと、シーケンスヘッダとその位置（例えば、ディスク上の位置や、プログラムストリームを伝える他の記憶媒体上の位置）のリストを指定する。トランスポートパケット構造にはPIDコードがないので、プログラムストリームのPESパケット内のストリーム識別子SIDが、そのPESパケットで伝えられる基本ストリームのタイプと、必要な場合には、そのタイプのいくつかのストリーム（オーディオ1、オーディオ2など）のうち、正しいストリームが識別されて復号器に送られるように、どのストリームが伝えられるかを指定する。システムヘッダSYSH内のシステム情報は、さらなる情報を提供する。
【００３９】
公知の光ディスクビデオシステムなどの用途では、プログラムストリーム内の各パックは、1つのプログラムストリームのPESパケットのみを伝えることと、1つのパックにつき代表的には1つのPESパケットが伝えられることが指定される。光ディスクまたは類似する記録媒体上の記憶域の場合、各PESパックは、一般に、ディスクファイリング(filing)構造の1つの取得単位または「セクタ」に対応する。一般に、MPEG-2標準では、各パックの中に異なるタイプおよび数のPESパケットを混在させることができ、パックサイズは他の用途においては変えることが出来る。
【００４０】
システムターゲット復号器
実際の復号器のバッファリングとその他の側面に関して、プレゼンテーションされるオーディオ-ビジュアルプログラムにおいて中断なく各タイプのストリームを確実に復号できるように、MPEG-2標準は、トランスポートストリーム「システムターゲット復号器」(T-STD)モデルと、プログラムストリーム「システムターゲット復号器」(P-STD)モデルとを指定している。大ざっぱに言えば、各システムターゲット復号器は、TSフォーマットまたはPSフォーマットの異なる基本ストリームを逆マルチプレキシングするための手段を有し、かつオーディオ、ビデオ、システムコントロールの各データタイプ用の復号器を有し、かつデータチャネルからの到着から、復号およびプレゼンテーションの実際の時刻までの間、各エネルギストリームのデータを保持しておくための、入力ストリームと復号器の間のバッファとを有する、仮想リアル復号器の1つのモデルである。
【００４１】
T-STDとP-STDは、その一般的なフォーマットはどちらも類似しており、MPEG-2仕様にさらに詳細に説明されている。しかし、T-STDとP-STDの違いのために、一般にトランスポートストリームは、少なくともPESパケットレベルでの再スケジューリングなしにはプログラムストリームに直接マッピングすることができず、このことは、PSフォーマットからTSフォーマットへの変換についても同様である。1つの例として、TSフォーマットのオーディオ復号器のバッファは、P-STDにおけるバッファより小さい。別の例として、T-STDにおける各メインバッファの前には、トランスポートストリーム自体におけるかなり「爆発的な」データを平坦化する役割を果たすトランスポートバッファが存在する。1つのストリームのデータは、最大40メガビット／秒ものレートで爆発的なトランスポートパケットとして到着することがあるが、このようなストリームの平均速度は、トランスポートストリームマルチプレクス全体を考慮すれば、ずっと小さい。メインバッファに渡されるデータが存在すると想定したときに、入力データを2メガビット／秒のレートに制限するために、トランスポートバッファに対して「リークレート(leak rate)」が定義される。
【００４２】
プログラムストリームからトランスポートストリームへの変換
図4は、公知の光ディスクビデオシステムの再生のプログラムストリームから、図1の用途例におけるデジタルTV復号器102で必要とされるDVB標準のトランスポートストリームにトランスマルチプレキシングするための基本的な方法を示す。公知の光ディスクビデオシステムのプログラムストリームは、2048バイトセクタ(PSパック)に収まるPESパケットに分割される。各セクタの先頭は、パックのSCRを伝えるパックヘッダである。各パックは、1つのデータイプの1つのPESパケットと、オプションとして1つのスタッフィングパケットを伝える（MPEG-2オーディオを伝える公知の光ディスクビデオシステムストリームは例外であり、パック内で基本パケットと拡張パケットをインターリーブしてもよい）。
【００４３】
公知の光ディスクビデオシステムのPESパケットの解析は、非常に単純である。公知の光ディスクビデオシステムのPESパケットの構造は、トランスマルチプレキシングプロセス全体を通じて維持することができ、その理由は、PESパケット構造に対する公知の光ディスクビデオシステムの制約の方が、生成するトランスポートストリームに対してDVBによって課せられる制約よりも厳しいためである（ATSCなども同様）。ただし、ここに開示される方法は、一般に、適切な適合化を行うことにより、MPEG-2互換ストリームと、類似する特性を有する他のフォーマットで伝えられるパケット化基本ストリームデータとに適用することができることが理解されるであろう。
【００４４】
概説すると、公知の光ディスクビデオシステムの入力ストリームPS（図1の例においてはディスク106からのストリーム）は、402で解析され、各データタイプのストリーム識別子SID (stream_identifier)のPESパケットの並行ストリーム（ビデオストリーム404、オーディオストリーム406）に分割される。なお公知の光ディスクビデオシステムのマルチプレクスに含まれるグラフィックストリームについては、復号されたピクチャとして表示するためにMPEGビデオにトランスコーディング(transcoded)されるかメインの同じビデオストリームのピクチャデータに「焼かれる」かのいずれかであるため、ここでは具体的に考察しない。しかしながら、原理的には、グラフィックまたはその他の情報タイプのさらなるストリームが存在してもよく、図に示されているオーディオおよびビデオストリームに類似する方法で処理することができる。並行するA/V PESストリームは、それぞれキュー（バッファ）408、410に入る。次に、キューに格納されたデータストリームは、スケジューラ412の制御の下に、414で188バイトのトランスポートパケット(T-PKT)に分割され、トランスポートストリームTSを形成するようにインターリーブされてから、スケジューリングされて、プレーヤの出力インタフェースに送られる。
【００４５】
トランスマルチプレクサの主要な機能要素とプロセスは、個別のブロックとして図示、記述されているが、ここに記述されている各種のバッファとプロセスは、プレーヤ104またはその他の装置の別の目的にも使用される汎用プロセッサおよび共有メモリ内に実施してもよい。同様に、通常の設計思想に従って、専用のデジタル信号プロセスおよび／または専用ハードウェアを適切な箇所に使用することができる。
【００４６】
以下に、スケジューラ412についてさらに詳しく説明する。最初の発想は、プログラムストリームで使用されているものと同じデータスケジューリングを維持することであり、この場合にプログラムストリームは、PS要件に準拠していることを前提とする。この場合、基本データは、プログラムストリーム内で転送されるタイムとできるだけ同じタイムにトランスポートストリーム内で転送される。この方法は、MPEG STD(システムターゲット復号器)モデルを維持する必要があり、かつ大きなバッファを備える必要がある完全な再マルチプレクシングを必要としないという利点を有する。しかし、MPEG-2における少なくとも2つの制約のため、以下に示すTSフォーマットの準拠を維持しながら、PSと同じスケジュールをTSに単純に適用することは不可能である。
・  TSオーディオバッファのサイズは、3584バイトである。公知の光ディスクビデオシステムのプログラムストリームでは、これは4096バイトであり、従って、オーディオデータ用のセットトップ復号器バッファは、時折オーバーフローしてオーディオサンプルが失われることがある。
・  TSオーディオのSTDモデルの最大瞬間速度は、トランスポートバッファの「リークレート」によって決まる2メガビット／秒である。この最大レートは、512バイトについてのみ超えることがある。公知の光ディスクビデオシステムのPSでは、4096バイト（2パケット）分の時間長について最大オーディオビットレート10.08メガビット／秒（「program_mux_rate」によって定義される）を維持することができる。従って、公知の光ディスクビデオシステムのマルチプレクスは、MPEG-2トランスポートストリーム(TS)が伝えるよりも、より高い速度で、より長いデータを伝送できる。
【００４７】
これら2つの制限により、基本ストリームを分けて再マルチプレキシングすることと、出力ストリームに課せられる異なる制約に従ってデータを再スケジューリングすることが必要であることが示唆される。従って、再び図4において、スケジューラ412は、TSフォーマットの各基本ストリームに指定されるシステムターゲット復号器(T-STD)のモデル416と418を維持する。これらのモデルは、実際にはストリームデータを格納も復号もしないことが理解されるであろう。しかしながら、各種のカウンタおよびリストを確立して、MPEG-2システム標準に指定される挙動に従ってこれらを時間の経過とともに更新することによって、このモデルは、データの仮想的な動きを追跡し、これによって特に互換リアル復号器内のストリームバッファがオーバーフローもアンダーフローもせず、従ってデータが失われず、復号とユーザへのプレゼンテーションのための必要なタイミングおよび正しいシーケンスで、確実に到着させることができる。この目的のため、TSシステムクロックは、再マルチプレクス機能にとって重要なタイムベースであり、これは、トランスポートストリームの絶え間ない生成に同期される。入ってくるプログラムストリームは、自身の基準システムクロックSCR (System Clock Reference)を伝え、どちらも27MHzクロックに基づいて表されている。TSパケットは、各TSパケット期間ごとに生成される。これらTSパケットは、原理的には、ちょうど必要なタイミングで生成することができ、あるいは、短いFIFOバッファに送って、パケットの実際のスケジューリングと生成に対するタイミングの制約を緩和することができる。以下の説明を目的とするシステムクロックの値は、それ以降のバッファリング遅延に関係なく、その時点で生成中のTSパケットのタイムである。
【００４８】
基本ストリームのSTDモデル416、418を維持するため、スケジューラは、PESパケットヘッダ内にPTS/DTSが明示的に符号化されていないアクセスユニットのPTS/DTSを計算するために、各アクセスユニットのサイズと、ビデオの特定のパラメータ(フレームレート、「先頭フィールドを繰り返し(repeat first field)」フラグ、ピクチャタイプなど)も認識している。例えば、公知の光ディスクビデオシステムでは、各GOP内の最初のI-ピクチャのPTS/DTSを、PESヘッダ内に明示的に符号化するのみでよい。各ピクチャのPTS/DTSを符号化する必要はなく、かつそれは一般的ではない。同様に、オーディオストリームのパラメータ(サンプリングレート、フレームサイズなど)を使用することも有利である。
【００４９】
従って、PESパケットの内容は乱されないが（例えば、SID/PIDを都合のよいプログラム構造に再マッピングする場合を除く）、ピクチャヘッダ／拡張／フレームヘッダレベルまでのアクティブなストリームすべての中の基本データを解析する必要がある。ここで留意すべき点は、これらはPESパケット内の任意のバイト位置に含まれ、このためスタートコードがPESパケット間で分かれていることがある点である。オーディオは、可変のビットレートである。さらに、MPEG互換のビットストリームでは、ビデオストリーム内の各種のスタートコードは一意であるのに対して、オーディオ同期コードは、小さい確率で、オーディオペイロードデータ内でエミュレートされることがある。このためオーディオストリームの解析には、一意のビットパターンの単純なスキャンではなく、いくつかのフレームにわたって確実に同期させるための状態マシン方法(state machine approach)が必要となる。
【００５０】
スケジューラ412: 方法1
以下に、TSパケットを送る時期と、どの基本ストリームからのTSパケットを送るかを決定するプロセスの最初の例について説明する。このプロセスは、例えば、ディスクからプログラムストリームをリアルタイムより高速で読み取ることができるときに適用できる。また、例えば、インタフェースを介して送られるときなど、PSをリアルタイムで処理する必要があるときにも適用できるが、この場合には、再マルチプレクサが最大1秒の遅延を挿入する。方法1は、方法2(図6、後述)よりも単純であるという利点を有するが、中間キュー用に多くのメモリを使用し、PSがリアルタイムで伝送される場合にはより長い遅延が必要となる。
【００５１】
図5は、スケジューラのプロセスをフローチャートのフォーマットで示す。このフローチャートのメインループは、各TSパケット期間に対して少なくとも1回実行され、実際には、メインループまたはその中のサブプロセスは、各TS期間内に複数回繰り返されることがある。変換プロセスは、ステップ500から始まり、以下のステップが続く。
502: プログラムストリームからセクタ（PSパック）を読み取る。このセクタが解析されて、SIDとPES長が識別される。このデータが必要とされないことをSIDが示している場合は、このデータは破棄される。一般にMPEG-2では、各パック内に複数のPESパケット、もしくは複数のSIDさえもが存在してよい。パック内の1つまたは複数の各PESパケットは、該当するキュー(図4における408、410)にそのまま送られる。接続記号Bは、ステップ502に進み、PSから新しいセクタが読み取られるときに使用される。
504: 読み取るべきPSパックがなくなった時点で（このことはディスク上のディレクトリ構造によって前もって示されるようにできる）、必然的にプロセスは終了する。
506: ストリーム内のPESパケット内のヘッダとオプションのシステムフィールドから、復号器の正しい制御のためにシステム情報（公知の光ディスクビデオシステムにおいてはSI、MPEG-2用語においてはPSI）を挿入する必要があるか否かが判断される。必要である場合、508で、SIキュー（図4には示されていない）にSIデータが追加される。510で、STDの現在の状態によって、仮想復号器のSIバッファ内にSIデータ用のスペースがあるか否かが確認される。スペースがある場合は、512で、トランスポートパケットが生成される。スペースがない場合は、SIデータがキュー内にある状態でプロセスが継続する。
520: メインループに入る。このループは継続的に実行され、トランスポートパケットを生成して、最初のキューを調べて関連キュー内で待機しているデータES(基本ストリーム)があるか否かを判断する。本例においては、すべてのストリームが順に調べられるが、オーディオストリームが最初に調べられるのが望ましい。
522: 最初のESについて、送信を待機しているデータがある場合には、システムターゲット復号器モデルが調べられて、そのストリーム用のバッファにさらなるトランスポートパケット用のスペースがあるか否かが判断される。スペースがある場合、524で、トランスポートパケットが出力ストリームに追加される。接続記号Aは、メインループの最初に戻る。
526: 最初のキューからパケットが生成されない（キューが空であったか、または関連STDバッファ416/418が満杯であったため）場合には、ステップ520-524に類似するステップが、各基本ストリームに対して繰り返され、これにより、データの有無について各キューを調べ、STDモデル内の対応するバッファが満杯か否かを調べ、可能であればトランスポートパケットを送信する。パケットが生成されると、制御は、接続記号Aを介してメインループの先頭に戻る。最後のストリーム用のステップは、528 - 532に示されている。
534: いずれのストリームでもトランスポートパケットをスケジューリングできなかった場合には、いずれかのキューが空か否かがチェックされる。空のストリームがある場合、接続記号Bに従って、入力ストリームからデータの新しいセクタが取得される。
536: いずれのキューも空でない場合は、STDのすべてのバッファが満杯であると判断され、スタッフィング(空の)パケットをトランスポートストリームに書き込むことによって、「待機」アクションが実施される。ここで留意すべき点は、TSフォーマットでは、データの有無に関わらずパケットの速度は一定であり、必要なデータを「埋める」ためのスタッフィングパケットの発生は、きわめて通常のことである。スタッフィングパケットは、この目的のMPEG-2仕様の中に定義されており、受信時に復号器によって破棄される。同様に、スタッフィングパケットは、復号器モデルSTDにおけるバッファの満杯度に影響しない。次に、制御はステップ520に移り、プロセスが繰り返されて、バッファの1つに新しいトランスポートパケット用のスペースが生じるまで、必要であれば待機とスタッフィングが行われる。
【００５２】
ここで留意すべき点は、図5に示されている方法においては、最初のストリーム(本実施例においてはオーディオ)に一種の優先性が与えられることである。すなわち、最初のキューにデータがあり、STD内の最初のバッファにスペースがあれば、そのストリームからのトランスポートパケットが、他のストリームに優先して送られる。本発明者が本例においてこのような優先性を導入するように選択した理由は、ストリームの数は制限されており、オーディオストリームにおけるスケジューリングの自由度が明らかに低いためである。しかし、厳密なアルゴリズムは重要ではなく、他のオプションを考慮してさまざまな環境に適合させることができる。例えは、類似する特性の各種ストリームからのデータのインターリーブを最大にするには、ステップ524からの結合を変更して、Aにループを戻す代わりにステップ526に結合し、最後のストリームまでの以降のストリームについても同様にするだけである。この場合、すべてのストリームが試行されて、可能な場合にパケットが送信されたときにのみ、ループはステップ520に結合され、最初のストリームについて再び試行される。後述する方法2についても、同じことがあてはまる。
【００５３】
方法1の分析
上述のスケジューリングアルゴリズムは、基本ストリームキューの1つが空であれば別のPSパケットを取得する。すなわち、TSスケジューラ412は、TSマルチプレクス制約を満たすパケットを見つけるときに、何らの制限を受けずに基本データを選択できる。従って、PSパケットのスケジューリングは、TSマルチプレクススケジュールに影響しない。
【００５４】
入力ストリームのスケジュールと出力ストリームのスケジュールの間に依存関係はなく、かつ、TSマルチプレクサは有効なスケジュールを必ず見つけることができるため、このアルゴリズムには、明らかにデッドロック条件がない。しかし、この単純性の代償はバッファリングであり、PSをリアルタイムより高速で読み取ることができない場合、トランスコーディング遅延は約1秒である。キューの占有度とバッファリング遅延が「最悪」となるのは、基本ストリーム間のスキューが最大のときである。
【００５５】
例えば、1つのオーディオストリームと1つのビデオストリームを考える。オーディオフレームNが、PSによって非常に遅く(復号タイムDTSの直前)に伝送され、同じストリームの前のオーディオフレーム(N-1)が、非常に早く伝送されるとする。TSスケジューラは、フレームN-1を、このフレームがトランスマルチプレクサに到着してからいくらかの時間の経過後に、トランスポートストリームTSに挿入する。これ以後、TSスケジューラは、オーディオフレームNがPSから読み取られるまでは、オーディオとビデオのいずれについてもパケットのスケジューリングを行わない。しかし、間のビデオフレームすべてが取得されるので、トランスマルチプレクサ内のキューに格納する必要がある。
【００５６】
このような最悪の状況におけるキュー長と遅延は、MPEGの「1秒規則」を使用して導くことができる。この規則は、どのアクセスユニットについても(例: フレームN-1)、最大復号遅延は1秒であるということである。従って、フレームN-1とフレームNの間の最大可能時間は、1秒である(これよりわずかに狭い境界を導くことができる)。従って、遅延の上限は1秒であり、この値を使用して、キュー長を計算できる。従って、1秒のビデオストリームには約230キロバイトのバッファが必要であり、実際には約300キロバイトである。
【００５７】
スケジューラ412: 方法2
図6は、必要とされるバッファサイズがより小さい、トランスポートストリームをスケジューリングするための修正された手順を示す。ステップ600-634の手順は、図5(方法1)におけるステップ500-534と同じである。しかし、この修正された方法では、入力ストリームが、仕様に準拠するPSマルチプレクススケジュールを有するプログラムストリームであることがわかっていることを利用して、2つのスケジュールの間に依存関係を導入し、これによって遅延を低減させる。
【００５８】
新しいステップは638であり、このステップは、基準システムクロック(SCR)値（最後に取得されたPSパックに含まれる）と、システムクロックTSCとを比較する。この場合、TSCは、トランスポートストリームの生成における進行を示すのに対し、SCRは、入力ストリームPSの取得における進行を示す。方法1では、新しいデータは、キューのいずれかが空であれば入力ストリームから取得されるのに対し、余分なステップ638/640では、新しいデータは、SCRがTSCより所定のしきい値MINより小さい分だけ進んでいる場合にのみ取得することが許可される。言い換えれば、空のキューバッファがあっても、入力ストリームが十分な量だけ先まで読み取られていたならば、新しいデータは取得されない。ここで留意すべき点は、TSCは、スタッフィングパケットの生成の場合も含めてつねに進んでいるのに対して、SCRは、入力ストリームPS（ディスク）から新しいデータが取得されるときおよび取得中にのみ進むことである。ステップ638における時間差MINを、MPEG-2で許容される最大遅延1秒より大幅に短い時間に設定できれば、キューに必要なバッファリングは、明らかにそれに比例して小さくなる。このことは、前述の例において、次のオーディオフレームを待っている間に、多数のビデオパケットを送ることができることを意味する。
【００５９】
公知の光ディスクビデオシステムの変換の例、すなわち、互換MPEG-2プログラムストリームをトランスポートストリームに変換する例においては、前述されているように、パケットを再スケジューリングする理由が2つある。1つは、トランスポートストリームにおいてはオーディオトランスポートバッファのリークレートに対して2メガビット／秒の制約があることである。もう1つは、トランスポートストリームとプログラムストリームとで、メインオーディオバッファのサイズが違うことである(3584バイトと4096バイト)。これら2つの場合について検討すれば、入力が準拠プログラムストリームであるときに、TSパケットスケジューラが準拠スケジュールを見つけるうえで必要となる自由度を知ることができる。
【００６０】
オーディオが、フレーム時間長24msの48kHz MPEGであるとする。当業者には、別のサンプリングレートや、フレームサイズが既知である場合のAC3符号化など、これ以外の想定の場合に議論を一般化する方法を容易に理解できるであろう。公知の光ディスクビデオシステムで許可されるMPEGオーディオビットレートは、32キロビット／秒〜448キロビット／秒の間である。32キロビット／秒の場合は、アクセスユニットのサイズ（圧縮フレームのサイズ）は、0.024 x 32000/8 = 96バイトである。448キロビット／秒の場合は、アクセスユニットのサイズ(圧縮フレームのサイズ)は、0.024 x 448000/8 = 1344バイトである。
【００６１】
公知の光ディスクビデオシステムのprogram_mux_rate（入力ストリーム内で1つのフレームが伝送される速度）は、10.08メガビット／秒である。TSオーディオ・トランスポートバッファのリークレート(Rleak)は、2メガビット／秒である。最悪の場合においては、この値は、TSマルチプレクスによってオーディオフレームを転送することのできる最大速度を表す。次の2つの場合を個別に考える。
【００６２】
トランスポートバッファの2メガビット／秒の制限
許可されるもっとも遅いタイムDTSn（復号タイムの直前）にPSによって伝送される、最大サイズBn（1344バイト）のオーディオフレームNを考える。フレームNの最初のバイトは、PSにおいて次のタイミングで伝送される。
Tps <= DTSn - Bn/(Rmux)
最悪の場合においては、トランスポートストリームでこのフレームを送るのに、少なくともdeltaTts = (Bn/Rleak)だけかかりうる。このため、このフレームの最初のバイトは、次のタイミングで送る必要がある。
Tts = DTSn - deltaTts
この問題を解決するのに必要な自由度をスケジューラに与えるために、プログラムストリームは、少なくとも(Tts - Tps)秒だけトランスマルチプレクサ内でバッファリングされる必要がある。
前述されている公知の光ディスクビデオシステムの各値を、次のように考慮する。
Bn/Rleak  = 1344/(2x106/8) =  5.376ms
Bn/Rmux = 1344/(10.08x106/8) = 1.067ms
従って、この制約に対するスケジューリング自由度をスケジューラに与えるのに必要な最小トランスマルチプレクス遅延は、4.31msである。
【００６３】
バッファサイズの違い
ある時点でPSオーディオバッファをちょうど埋めるパケットスケジュールを有するプログラムストリームを考える。TSオーディオバッファはPSオーディオバッファより小さいので、オーディオフレームのいくつかをただちに送信することはできない。オーディオフレームは、スケジューリングに必要な十分なスペースがTSオーディオバッファ内に生じるまで、遅延させる必要がある。A/V同期を維持し、かつ他のストリームでのアンダーフローを避けるため、すべてのストリームは同じ時間だけ遅延させる必要がある。
【００６４】
バッファサイズの差は、4096バイト - 3584バイト = 512バイトである。この値は、データ速度が最低のときの最悪の場合（最長時間）である。データ速度が32キロビット／秒のとき、フレームサイズは96バイトである。MPEGモデルに従ってフレームの復号時にバッファ内に存在している必要のある完全なフレーム数は、512/96 = 5.33フレーム、すなわちこれを丸めて6フレームである。6フレームは、144msに相当する。
【００６５】
従って、TSスケジューラに、この制約を克服できるだけの自由度を与えるためには、6個のオーディオフレーム分の遅延(144ms)を課す必要があり、この値の方が、リークレート制限によって示唆される制約4.31msより大きい。従って、大ざっぱに言うなら、方法2では、TSフォーマットの制約のみを考慮した場合に予測される遅延の約1/6の遅延で、PSフォーマットからTSフォーマットへのPESパケットの再スケジューリングを行うことができる。144msの遅延は、入力ストリームをリアルタイムより高速でトランスマルチプレクサに読み取ることができれば、いくらか小さくすることができる。
【００６６】
ここで留意すべき点は、この場合、オーディオストリーム(フローチャートにおける最初のストリーム、冒頭部分および請求項における「第2」ストリーム)に与えられる優先性は、識別される制約を満たすのに必要なときに144msの遅延が確実に使用されるうえで重要である。これに対して、必要な優先性を与えながら、オーディオ以外のストリームの進行がより重要なときにはそのストリームを優先することのできる、別のアルゴリズムを使用してもよい。STDバッファの満杯度の割合がもっとも低いストリームを優先させる方法は、同等に有効である。また、測定される追加の自由度を与えることができるように、待ちしきい値の上方スケーリング処理と組み合わせて、これよりゆるい優先度方式を適用することもできる。
【図面の簡単な説明】
【図１】本発明の1つの実施例が適用されているデジタルビデオ・エンターテインメントシステムの一例を示す。
【図２】トランスポートストリーム(TS)フォーマットにおけるデータのフォーマットを示す。
【図３】プログラムストリームフォーマットにおけるデータのフォーマットを示す。
【図４】本発明の実施例による、PSフォーマットの信号をTSフォーマットに変換するときの主要なデータの経路と機能ブロックとを示す。
【図５】入力ストリーム制約の知識を利用しない仮想スケジューリングプロセスを示す。
【図６】本発明の実施例によるスケジューリング方法を示す。
【符号の説明】
100  デジタルTVチューナ
102  セットトップボックス
104  再生／記録
106  ディスク
108  テレビ
402  PSセクタの取得と解析
404  ビデオストリーム
406  オーディオストリーム
408  ビデオタイムスタンプキュー
410  オーディオタイムスタンプキュー
412  TSスケジューラ
416  システムターゲット復号器（ビデオ）
418  システムターゲット復号器（オーディオ）
419  TSパケットの構築と再マルチプレキシング
500  PS-TS
502  PSパックの取得とキュー格納
504  プログラム終了
506  TSにPSIが必要か
508  SI→SIキュー
510  スケジューリング?
512  SI-PKT→TS
520  Q-1  データがあるか?
522  STD-1 OK?
524  T-PKT→TS
528  Q-N  データがあるか?
530  STD-N OK?
532  T-PKT→TS
534  空のキューがあるか?
536  スタッフィングPKT→TS
600  PS-TS
602  PSパックの取得とキュー格納
604  プログラム終了
606  TSにPSIが必要か
608  SI→SIキュー
610  スケジューリング?
612  SI-PKT→TS
620  Q-1  データがあるか?
622  STD-1 OK?
624  T-PKT→TS
628  Q-N  データがあるか?
630  STD-N OK?
632  T-PKT→TS
634  空のキューがあるか?
636  スタッフィングPKT→TS
638  SCR -TSC > MIN?
640  スタッフィングPKT→TS
【図１】
0004828760.tif 000002
【図２】
0004828760.tif 000003
【図３】
0004828760.tif 000004
【図４】
0004828760.tif 000005
【図５】
0004828760.tif 000006
【図６】
0004828760.tif 000007