(57)【要約】【課題】リアルタイム・オーディオ／ビデオ・コーデックの完全なシステムを構成するために、様々なモジュールを接続しやすくする、モジュールを含むシステムを提供する。【解決手段】コーデック・システムのモジュールは、コーデック・システムの他のモジュールとインタフェースする修正標準入出力ライブラリ１０１〜１０６を備えている。修正標準入出力ライブラリに備えられた関数は、標準入出力ライブラリ及び標準入出力インタフェースつき共用メモリ・ライブラリの１個に備えられたそれぞれの事前割当関数を呼び出すラッパ関数である。【選択図】      図５
2004259033.tif 000002
【特許請求の範囲】
【請求項１】
エンコーダ・モジュール及びデコーダ・モジュールのうち少なくとも一つを有する装置において、
当該装置に含まれるモジュールの入力及び／又は出力とインタフェースする少なくとも一つの修正された標準入出力ライブラリを備え、
前記少なくとも一つの修正された標準入出力ライブラリは、プロセス間通信のサポート関数を呼び出す複数のラッパ関数を含むこと
を特徴とする装置。
【請求項２】
前記ラッパ関数のそれぞれは、それに関連するファイル名に応じて、事前割当された標準入出力ライブラリ関数及び前記プロセス間通信サポート関数のうちいずれか一方を呼び出すための、コンパイル・タイム・スイッチ及びラン・タイム・スイッチの一方を具備すること
を特徴とする請求項１記載の装置。
【請求項３】
前記ラッパ関数はそれぞれ、標準入出力ライブラリ及び標準入出力インタフェースを有する共用メモリ・ライブラリのうち一方に備えられている、事前に割り当てられた関数を呼び出すこと
を特徴とする請求項２記載の装置。
【請求項４】
前記標準入出力インタフェースを通過するデータは、オーディオビデオ・データ及びモジュール制御コマンド・データの一方を含むこと
を特徴とする請求項３記載の装置。
【請求項５】
前記少なくとも一つの修正された標準入出力ライブラリは、ディスク・ファイルに関係する関数を、それに対応する事前に割り当てられたプロセス間通信サポート関数と取り替える、複数のラッパ関数を含むこと
を特徴とする請求項１記載の装置。
【請求項６】
前記少なくとも一つの修正された標準入出力ライブラリは、ｆｗｒｉｔｅ及びｆｒｅａｄ関数を、ｆｐｕｔｃ及びｆｇｅｔｃでそれぞれ取り替える、複数のラッパ関数を含むこと
を特徴とする請求項５記載の装置。
【請求項７】
当該装置に含まれる前記モジュール間では共用メモリ通信が実行されること
を特徴とする請求項１記載の装置。
【請求項８】
前記モジュール間を接続するバッファをさらに備え、
前記バッファ特性の少なくとも一つが設定可能であること
を特徴とする請求項１記載の装置。
【請求項９】
前記設定可能なバッファ特性にはバッファサイズを含むこと
を特徴とする請求項８記載の装置。
【請求項１０】
コマンド行の入力を受け入れて解析し、該コマンド行の入力で指定されたモジュールを実体化するシェルにおいて、
前記モジュール間に少なくとも一つの共用メモリ通信チャネルを設定し、
前記共用メモリ通信チャネルを介して接続された前記モジュールは、オーディオ／ビデオ・コーディング・システムまたはオーディオ／ビデオ・デコーディング・システムに含まれること
を特徴とするシェル。
【請求項１１】
コマンド行の入力を受け入れて解析し、前記コマンド行の入力が特定するモジュールを実体化するシェルにおいて、
前記シェルは、オプショナルのバッファ特性パラメータを含むコマンド行構文を受け入れ、前記コマンド行の前記パラメータで特定されたバッファ特性を設定し、
前記バッファは、オーディオ／ビデオ・コーディングシステムのモジュールまたはオーディオ／ビデオ・デコーディングシステムのモジュールの接続を提供すること
を特徴とするシェル。
【請求項１２】
コマンド行の入力を受け入れて解析し、前記コマンド行の入力が特定するモジュールを実体化するシェルにおいて、
前記シェルは、前記モジュールの標準入力及び出力を特定するパラメータを有するプロセス・サブステチューション構文を受け入れ、
前記モジュール間に、少なくとも一つの共用メモリ通信チャネルを設定し、
前記モジュールの各々は、該各モジュールのオリジナルｍａｉｎプログラムを呼び出すｍａｉｎラッパを具備すること
を特徴とするシェル。
【請求項１３】
前記モジュールは、入力及び／又は出力のインタフェースを行うための修正された標準入出力ライブラリに接続され、
前記修正された標準入出力ライブラリは、プロセス間通信サポート関数を呼び出す複数のラッパ関数を具備すること
を特徴とする請求項１２記載のシェル。
【請求項１４】
オーディオ／ビデオ信号のコーディングまたはデコーディングを行う、少なくとも１つのモジュールを含むシステムであって、
前記システムは請求項１０〜１３のいずれかに記載のシェルを備えていること
を特徴とするシステム。
【請求項１５】
モジュールを接続する方法において、
前記モジュール間のディスクファイルに関係した通信を、共用メモリ・チャンネルで取り替えるためのラッパ関数を有する修正された標準入出力ライブラリを具備すること
を特徴とする方法。
【請求項１６】
前記ラッパ関数の各々は、関連するファイル名に応じて、標準入出力ライブラリ関数及び共用メモリ関数のうちの一つを呼び出すスイッチ関数を具備すること
を特徴とする請求項１５記載の方法。
【請求項１７】
シェルを使用してモジュールを接続する方法において、
前記シェルは、前記モジュールの標準入力及び出力を特定するためのパラメータを用いたプロセス・サブステチューション構文を受け入れ、
前記モジュール間に少なくとも一つの共用メモリ通信チャネルを設定し、
前記モジュールの各々は、該各モジュールのオリジナルｍａｉｎプログラムを呼び出すｍａｉｎラッパを具備すること
を特徴とする方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、種々の機能を有する複数のモジュールの構成して接続することにより、特定のアプリケーションを対象としたシステムを実現する方法に関する。特に、本発明は、コーディング及びデコーディング・モジュールの効率的接続により、オーディオ及び／又はビジュアル・システムを実現する方法及び装置に関する。
【０００２】
【従来の技術】
オーディオ及びビジュアル（ＡＶ）システムは、複雑化の一途をたどっている。有料テレビのアプリケーションを例にとれば、そのシステムは、ビデオ・プリプロセッサ、ビデオ・エンコーダ、オーディオ・エンコーダ、マルチプレクサ（ｍｕｘ）、暗号化装置、リード・ソロモン（エラー保護用）装置、送信器、受信器、逆リード・ソロモン装置、暗号解読装置、デマルチプレクサ（ｄｅｍｕｘ）、オーディオ・デコーダ、ビデオ・デコーダ、ビデオ・ポストプロセッサのような各種モジュールで構成される。
【０００３】
上記システムが開発された場合、しばしば、各モジュールは、当初、スタンドアローンのモジュールとして提供され、また、ＡＮＳＩ−Ｃの“標準入出力（ｓｔｄｉｏ）”ライブラリが、図１に示すように各モジュールのファイル入出力サポート用に使用される。図１のシステムは、ビデオ・プリプロセッサ１０１、ビデオ・エンコーダ・モジュール１０２、オーディオ・エンコーダ・モジュール１０３、マルチプレクサ１０４（“ｍｕｘ”として参照される）、暗号化モジュール１０５、及びビデオ・ポストプロセッサ１０６といったモジュールで構成される。
【０００４】
なお、ｓｔｄｉｏとは、Ｓｔａｎｄａｒｄ  Ｉｎｐｕｔ  ａｎｄ  Ｏｕｔｐｕｔ（標準入出力）の略語である。Ｃ言語とＣ＋＋言語では、各モジュールは、ヘッダファイル（“ｓｔｄｉｏ．ｈ”）を含めて、関連ライブラリにリンクし、ｆｏｐｅｎ、ｆｐｕｔｃ、ｆｗｒｉｔｅ、ｆｇｅｔｃ、ｆｒｅａｄ及び／又はｆｃｌｏｓｅなどの必要関数を使用することで、標準入出力ライブラリを利用する。さらに、入出力をサポートする関数として、それらは各モジュールの「インタフェース」となる。これらの仕様（つまり、構文、数と種類またはパラメータなど）を備えた関数から構成される完全なセットは、ＡＰＩ（アプリケーション・プログラマーのインタフェース）の一例である。その長い歴史のため、ＡＮＳＩ−Ｃ、標準入出力―ＡＰＩは、もっともよく使われるＡＰＩの一つである。
【０００５】
スタンドアロ−ンのモジュールを最初に作る理由は、二つある。
（１）上記モジュールは、色々な種類のシステムを作るために（つまり、色々な種類のアプリケーションを作成するために）、有用なスタート・ポイントである。
（２）スタンドアロ−ンのモジュールとして、それらは独立して作動する。これにより、各モジュールが正確に作動するかの確認がしやすい。そのような確認は、完全かつ成功するシステム作成のために、モジュールを接続する以前に必要となることがある。
【０００６】
標準入出力ライブラリは、図１の例が示す各モジュールに含まれている。しかし、システムのメモリスペースを節約するために、ライブラリの１個のコピーをすべてのモジュール間で共用するという環境もある。
【０００７】
標準入出力ライブラリを使用するシステム例の一つにＵＮＩＸ（登録商標）シェルがある。各種のＵＮＩＸ（登録商標）シェルを説明する出版物やガイドブックは数多くある（例えば、ローエルＪ．アーサー、テッド・バーンズ共著、訳者サカモト・フミ、１９９９年日経ＢＰ出版の「ＵＮＩＸシェル・プログラミングの詳細」）。
【０００８】
【発明が解決しようとする課題】
システムが完全に統合されている場合で、モジュールを接続する方法としてＡＮＳＩ−Ｃ標準入出力ライブラリを使用する際に、問題が生じることがある。
【０００９】
特定の環境では、ＡＮＳＩ−Ｃ標準入出力ライブラリを使用する時点に、ファイルが存在していなければならず、最悪の場合には、ハード・ディスクに記憶されているファイルが必要となる。そういった場合、モジュールをそれらの中間ファイルと接続することは可能であるが、システムのリソースが限定されている場合、非常に遅いプロセスとなる可能性がある。その結果、リアルタイム処理には不適当である。また、ディスクや他のファイルシステムを備えていない製品が、依然として多く見られる。
【００１０】
中間のディスクファイルを経ずに、モジュールの接続に標準出力インタフェースの使用が可能な環境（例えば、ＵＮＩＸ（登録商標）及びリナックス環境）においても、問題はある。この場合、図２に示すように、ディスクファイルの代わりに、通常「パイプ」（または類似の方法）が使用されている。図２の数字２０１〜２０６は、モジュール１０１〜１０６にそれぞれ対応するパイプ・ドライバを示している。
【００１１】
図２に示す上記環境では、各モジュールのメモリが、分離されていることが多い。この方法は、各モジュール・データの保護により、システムのさらなる安定化に寄与するが、分離されたモジュールのメモリには、データをメモリ・コピー関数を有する上記パイプへ、及び／又は、上記パイプからコピーしなければならないという欠点がある。これは、すべてのデータ転送がＲＡＭメモリから、及び、ＲＡＭメモリへ行われる。このため、中間ディスクファイルへ、及び、中間ディスクファイルからデータをコピーするより優れているが、なお比較的非効率的である。特に大量のデータ処理の場合にはそうなる。
【００１２】
パイプまたはパイプ使用法に関するさらに他の問題は、これらがリアルタイム・オーディオビジュアル・コーデックに関しては、しばしば不適当なデフォルト・サイズを備えているという点である。
【００１３】
本発明は、前述の諸問題に鑑みてなされたものである。上記諸問題を緩和または解決する方法、及び／又は、装置の提供が望ましい。
【００１４】
また、リアルタイム処理を必要とする特定のアプリケーションを対象とした完全なシステムを構成するために、種々のモジュールを接続可能にする方法、及び／又は、装置の提供が望ましい。
【００１５】
また、リアルタイム・オーディオ・ビジュアル・コーデックを対象とする完全なシステムを構成するために、種々のモジュールが接続しやすくなる方法、モジュール、及び／又は、モジュールを含むシステムの提供が望ましい。
【００１６】
また、効率的なコーデック開発及び効率的なコーデック処理のためのフレームワークを与え得る方法、及び／又は、装置の提供が望ましい。さらに詳しくは、以下を可能とするフレームワークの提供が望ましい。
（１）既存のソフトウェアまたは最小の修正を加えた新規の独自ソフトウェアの使用、
（２）効率的な通信、そして
（３）モジュールへ／モジュールからの接続に関する最大限の柔軟性。
【００１７】
【課題を解決するための手段】
本発明に係る実施の形態によれば、少なくとも一つのエンコーダ及び／又は少なくとも一つのデコーダ・モジュールを有する装置が提供される。本装置は、当該装置に含まれるモジュールの入力及び／又は出力をインタフェースするための少なくとも一つの修正された標準入出力ライブラリを具備する。上記少なくとも一つの修正された標準入出力ライブラリに含まれる関数は、プロセス間通信のサポート関数を呼び出す複数のラッパ関数である。
【００１８】
本明細書においては、プロセス間通信（Ｉｎｔｅｒ  Ｐｒｏｃｅｓｓ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ：ＩＰＣ）は、共用メモリ、パイプまたは他の種類の非ディスクに基づく通信を意味する。望ましいＩＰＣ方法とは、共用メモリであり、その理由は、これがもっとも効率の高いデータ転送を提供するからである。共用メモリが利用できない場合には、パイプの使用も可能である。パイプは共用メモリほど効率が高くはないが、中間ディスクファイルを使用するよりは高速かつ低コストである。
【００１９】
ラッパ関数の各々は、関連するファイル名に応じて、事前に割り当てられた標準入出力ライブラリ関数及びプロセス間通信サポート関数の一方を呼び出すための、コンパイル・タイム・スイッチまたはラン・タイム・スイッチを有していても良い。
【００２０】
望ましくは、関連するファイル名に応じて、スイッチが、標準入出力ライブラリに備えられた関数または標準入出力インタフェース付き共用メモリ・ライブラリが提供する関数を選択しても良い。標準入出力インタフェースでは、オーディオとビデオデータ（ＡＶデータ）及び、例えばデコーダ制御コマンドのような、モジュール制御コマンドの受け渡しをしても良い。
【００２１】
より具体的には、ディスクファイルに関係する関数を、対応する事前に割り当てられたプロセス間通信サポート関数と取り替える複数のラッパ関数を、修正された標準入出力ライブラリが備えていても良い。また、ラッパ関数が、ｆｗｒｉｔｅとｆｒｅａｄ関数を、ｆｐｕｔ及びｆｇｅｔｃにそれぞれ取り替えてもよい。
【００２２】
本発明に係る修正ライブラリはまた、シェルが利用できない場合でも、役に立つことがある。さらに本実施形態では、一般的なＡＮＳＩ−Ｃ標準入出力インタフェースを、従来よりも利用している。それには次のような幾つかの有利な点がある。
・上記インタフェースは、本実施形態のライフサイクルを増加させる比較的、安定したインタフェースである。
・修正されたライブラリがない場合でも、多くの環境において、上述と同様の機能性を包含することができる。
・既存のソフトウェアに本実施形態を適用する場合、一般的に、従来技術のアーキテクチャと比較して侵入性の程度がより少なく、その結果、既存ソフトウェアを本実施形態を使用する環境あるいはプラットフォームに移植させることは、他のプラットフォームと比較すると、より容易である。
【００２３】
本実施形態では、モジュール間で共用メモリ通信をもつのが望ましい。また、本装置では、モジュール間を接続するためのバッファをさらに含んでもよく、そして設定可能なバッファ特性を少なくとも一つを備えることが望ましい。上記設定可能なバッファ特性の一つがバッファ・サイズであっても良い。
【００２４】
本発明に係るさらに他の実施形態では、修正シェルが、コマンド行の入力を受け入れて解析し、コマンド行の入力で指定されたモジュールを実体化する。このシェルは、オーディオ／ビデオ・コーディング・システムのモジュール間またはオーディオ／ビデオ・デコーディング・システムのモジュール間で、少なくとも一つの共用メモリ通信を設定する。
【００２５】
本実施形態において、シェルは、モジュール間の共用メモリ通信に要する、いかなる準備をも実行しても良い。あるいは、シェルが、コマンド行の一部分（つまり、関連パラメータを有する１つまたはそれ以上のモジュール）を、該部分が比較的効率の高い通信方法をサポートしない場合には、適切な形式で従来型のシェルへ送信しても良い。
【００２６】
また代わりに、シェルは、オプションのバッファ特性パラメータを含むコマンド行の構文を受け入れ、コマンド行のパラメータが指定するバッファ特性を設定してもよい。バッファは、オーディオ／ビデオ・コーディングシステムのモジュール間またはオーディオ／ビデオ・デコーディングシステムのモジュール間の接続用に提供される。このシェルを、プロセス・サブステチューション及び非プロセス・サブステチューション・コマンド行に適用することも可能である。
【００２７】
本発明に係るさらに他の実施形態によれば、修正されたシェルが提供される。本シェルは、モジュールの標準入出力を指定するパラメータ付きのプロセス・サブステチューション構文を受け入れ、少なくとも一つの共用メモリ通信チャネルがこれらモジュール間に設定される。各モジュールは、該モジュールのオリジナルｍａｉｎプログラムを呼び出すｍａｉｎラッパを含む。モジュールを、入力及び／又は出力をインタフェースするための修正された標準入出力ライブラリに接続してもよい。この修正された標準入出力ライブラリは、プロセス間通信サポート関数を呼び出す複数のラッパ関数を備えている。
【００２８】
本発明に係るさらに他の実施形態によれば、オーディオ／ビジュアル信号のコーディングまたはデコーディングするための少なくとも一つモジュールを含むシステムが提供される。本システムは、上述の実施形態による複数のシェルのうち一つを備えている。
【００２９】
本発明に係るさらに他の実施形態によれば、モジュール間を接続する方法が提供される。この方法では、修正された標準入出力ライブラリは、該モジュール間のディスクファイル関連通信を、共用メモリ・チャネルで取り替えるためのラッパ関数を備える。各ラッパ関数は、関連するファイル名に応じて、標準入出力ライブラリ関数および共用メモリ関数のうちの一方を呼び出す、スイッチ関数を備えていても良い。
【００３０】
本発明に係るさらに他の実施形態によれば、シェルを使用してモジュールを接続する方法が提供される。この方法では、シェルは、モジュールの標準入出力を指定するためのパラメータを伴うプロセス・サブステチューション構文を受け入れ、少なくとも一つの共用メモリ通信チャネルがこれらのモジュール間に設定される。さらに各モジュールは、モジュールのオリジナルｍａｉｎプログラムを呼び出すｍａｉｎラッパを含む。
【００３１】
【発明の実施の形態】
以下、図面を参照しながら本発明の実施形態について説明する。
【００３２】
本発明に係る最も単純な実施形態の一つが、図３及び４を参照して説明する。図３は、モジュール１０１ａ〜１０６ａを接続する共用メモリ・ライブラリ（ここでは“ｓｈｍ”または“ｓｈｍｅｎ”と云う）の使用例である。この共用メモリ・ライブラリにより、モジュールの共通（またはオーバラッピング）メモリ使用が可能となる。この方法は、最高速のメモリ（ＲＡＭ）をメモリ・コピー処理を経ずに使用するため、一般に、モジュール接続の最も効率の高い方法である。共用メモリ領域は、効果的に、２個またはそれ以上のモジュール間のバッファとなる。図３に示す例では、各モジュールが、共用メモリ関数使用のため修正されている。
【００３３】
図４（Ａ）及び４（Ｂ）は、２個のモジュールの詳しい例、すなわち、それぞれが出力及び入力用に共用メモリを使用するビデオマルチプレクサとビデオ・エンコーダを示している。本例では“ＰＯＳＩＸ”共用メモリ標準が使用されている。この標準は、ある特定のＵＮＩＸ（登録商標）プラットホームによりサポートされている。
【００３４】
図４（Ａ）に示されているように、シェルがコマンド行４１１を読み取り、解析すると、シェルはビデオマルチプレクサ・モジュールｖｉｄｅｏ＿ｍｕｘ  ｍｏｄｕｌｅに提供されるファイル４１２を実体化する。ファイル４１２は、ビデオマルチプレクサ機能及びデータ出力用の共用メモリ・ライブラリ４１４を設定するプログラムであるモジュールＢ４１３を具備している。同様に、図４（Ｂ）には、シェルがコマンド行４１１を読み取り、解析すると、シェルは、ビデオ円コーダモジュールｖｉｄｅｏ＿ｅｎｃ  ｍｏｄｕｌｅ用に用意されたファイル４２２を実体化する。ファイル４２２は、ビデオ・エンコーダ機能及びデータ入力用の共用メモリ・ライブラリ４２４を設定するプログラムであるモジュールＡ４２３を具備している。
【００３５】
以下、図５−７を参照して本発明の他の実施形態について説明する。本実施形態では、共用メモリの代わりに修正標準入出力ライブラリが使用されている。
【００３６】
図３と図４に示す共用メモリを備えた例では、場合によっては、異なるライブラリ使用のために、モジュールの修正が困難なことがある。例えば、標準入出力から共用メモリ入出力に変更する場合、ｆｏｐｅｎ（）、ｆｗｒｉｔｅ（）、ｆｒｅａｄ（）などの関数は、共用メモリ割当て、メモリ書込み、メモリ読み取り及び共用メモリ割当て解除関数による交換と、適切な方法での使用が必要となる。さらに、これらの変更は、多数のモジュールに対して行わなければならず、したがって、上記変更には、追加の開発リソースが必要となる。
【００３７】
また、１人の技術者が１個のモジュール及びそのすべてのインタフェースについて責任を持っている場合、上記変更は、（非インタフェース関連の）モジュール改良、メンテナンス及び／又は品質保証といった重要な作業から、既存の工数を新インタフェースの実施ために転用することになる。その結果、システムに多数のモジュールを有する場合、各モジュールを共用メモリ・ライブラリ用に変更することがもっとも適切な解決法である可能性が少ない。さらに、このような変更は、技術的、組織的な観点から考慮すると、比較的侵入性があり妨害要素もあるため、開発費が相対的に高騰し、及び／又は、全体的品質／性能の低下を招く可能性がある。
【００３８】
本実施形態では、モジュールへの侵入、及び／又は、妨害となることをできるだけ避けるために、共用メモリ関数が、修正標準入出力ライブラリ内に挿入されている。修正標準入出力ライブラリは、広く使用されているＡＮＳＩ−Ｃ標準入出力ＡＰＩを変更なしに使用できる。ディスクドライブへの依存、パイプが存在することに対する依存、そしてパイプ利用時のメモリコピーに関係する諸問題は、本実施形態に係る修正標準入出力ライブラリにより解決することができる。
【００３９】
修正標準入出力ライブラリは、図５に示すように、各モジュールにリンク可能であり、その場合のモジュール変更は僅少か皆無である。図５の数字５０１〜５０６は、モジュール１０１ｂ〜１０６ｂに対応する修正標準入出力ライブラリを示している。
【００４０】
環境（ＯＳ）でサポートされている場合には、上述の各モジュールについて別々のコピーを備える代わりに、修正ライブラリの単一コピーを、すべてのモジュールで共用できる。また、共用メモリ関数を単一の修正標準入出力ライブラリに挿入する代わりに、共用メモリ関数を１個のドライバ内に挿入しておくこともできる。これは、共用メモリ関数をシステム・アーキテクチャにおいて１層下部へ移動することを意味する。上記構成によれば、各モジュールの変更はさらに少なくなる。
【００４１】
図６（Ａ）及び６（Ｂ）は、修正標準入出力ライブラリつきビデオマルチプレクサ及びビデオ・エンコーダ・モジュールの構造例である。これらのモジュールは、シェルコマンド行６１１及び６２１により実体化される。なお、ファイル名“／ｄｅｖ／ｓｈｍ１”は、共用メモリのみに使用される独自のネームである。
【００４２】
本例においては、ビデオ・マルチプレクサ６１３及びビデオ・エンコーダ６２３間のデータ転送は、関連ファイル名に応じて、標準入出力通信チャネルまたは標準入出力インタフェースつき共用メモリ通信チャネルを通じて行われる。修正ライブラリ６１４、６２４のそれぞれは、標準入出力インタフェース６１５、６２５つき共用メモリ・ライブラリ６１４、６２４及びオリジナル標準入出力ライブラリ６１６、６２６をそれぞれ備えている。
【００４３】
また、修正ライブラリは、例えば、ｉｆ−ｅｌｓｅステートメント又はそれに対応する他のスイッチ関数の使用で実現できる、スイッチを含むラッパ関数を具備している。スイッチは、ファイル名がディスクに基づく通信と関係または関連しているか判定する。もしファイル名がディスクに基づく通信と関係または関連している場合、オリジナルの標準入出力ライブラリが選択され、オリジナルの標準入出力ライブラリにある、事前割当されている対応関数が呼び出される。もしそうでない場合には、共用メモリ・ライブラリが選択され、共用メモリ・ライブラリの、もう一つの事前割当されている対応関数が呼び出される。
【００４４】
図５及び６に示す上述例に、さらに改良を加えるには、例えば共用メモリのサイズのような特性の設定を行うようにすればよい。従来の方法では、標準入出力ＡＰＩ初期化機能では、共用メモリにデフォルトサイズを使用しており、サイズのパラメータは存在しない。
【００４５】
図７（Ａ）及び７（Ｂ）は、バッファ特性の構成を可能とする改良例を示す。なお、シェル・コマンド行７１１、７２１の“ ｓ１００００００”は、１００００００バイトのバッファ（この場合、共用メモリ）サイズを特定するものである。このバッファサイズは、ＭＰＥＧ２アプリケーションにおいて望ましい値の１つｓある。
【００４６】
図７（Ａ）及び７（Ｂ）の例において、修正ライブラリ７１４と７２４は、標準入出力インタフェース７１５及び７２５付き修正共用ライブラリを有する。修正共用メモリ・ライブラリは、図６（Ａ）及び６（Ｂ）に示す共用メモリ・ライブラリ６１５、６２５にある全関数に加えて、さらにバッファサイズの構成を可能にする関数を具備している。
【００４７】
構成可能とすることが望ましいもう一つの特性は、ブロッキングまたは非ブロッキング読み取り処理である。ブロッキングがデフォルトであれば、共用メモリ・ファイル名に、例えば、“ ｎｂ”を加えれば、非ブロッキング処理の指定にできる。ファイル名は、モジュールとライブラリを経て修正共用メモリ・ライブラリの該当する関数に伝わり、そこで使用される。
【００４８】
図７（Ａ）及び７（Ｂ）の例に示された方法は、パイプを共用メモリの代わりに使用する場合に、役立つことがある。
【００４９】
本実施形態では、上述のように、ラッパ関数は、共用メモリ・ライブラリに標準入出力インタフェースを加えるために、接着剤のように使用されている。なお、従来の技術によるオリジナルの共用メモリ・ライブラリは、標準入出力インタフェースを備えていない場合がある。
【００５０】
本実施形態のフレームワークは、コーデックの効率的開発及び共用メモリによる効率的なデータ転送実現の一助となる。このフレームワークを実現するには、従来型の標準入出力インタフェースを、同一の従来型の標準入出力関数名及び同数のアーギュメントなどと共に使用する一方、標準入出力ライブラリの内容を取り替えるのである。つまり、標準入出力ライブラリにあるオリジナル関数の代わりに、ラッパ関数を使用して、ディスクに基づく入出力の代わりにＩＰＣ通信方法を設定する。
【００５１】
ディスクファイルに関係する各関数は、もし既存ソフトウェアのモジュールが次の関数を使用する場合、ラッパ関数を含む修正ライブラリの使用により、適切なＩＰＣ関数に簡単に取り替えられる。
・ｆｏｐｅｎ（入力または出力をオープンする）、
・ｆｗｒｉｔｅ及び／又はｆｒｅａｄ（読み取り及び／又は書き込む）、及び
・ｆｃｌｏｓｅ（入力または出力をクローズし、クリーンアップする）。
【００５２】
これらの関数は、例えば、次の方法で取り替えることができる。
・ｆｏｐｅｎの場合、ディスクファイルをオープンする代わりにＩＰＣチャンネルを設定する（例えば、共用メモリまたはパイプ）。
・ｆｒｅａｄ／ｆｗｒｉｔｅの場合、ディスクファイルから読み取りまたは書き込みをする代わりに、ＩＰＣチャンネルから読み取りまたは書み込みを行う。
・ｆｃｌｏｓｅの場合、ディスクファイルをクローズする代わりに、ＩＰＣチャンネルをクローズする。
【００５３】
修正標準入出力ライブラリのラッパ関数に備えられているスイッチは、関連ファイル名に応じて、呼び出す関数を選択するためのランタイム・スイッチもしくはコンパイルタイム・スイッチである。例えば、ｆｏｐｅｎ指定のファイル名がディスクファイルに関係しているか、あるいは、ディスクファイルに事前に割り当てられている場合には、スイッチはオリジナルのｆｏｐｅｎを呼び出すことができる。ファイル名がディスクファイルに関係していないか、あるいは、ディスクファイルに割り当てられていない場合、スイッチはＩＰＣｆｏｐｅｎを呼び出すものとし、このｆｏｐｅｎは、ＩＰＣチャンネルを使用している。同様のスイッチ関数は、ファイル名を特定するアーギュメントを有する他の関数にも使用可能である。
【００５４】
また、修正ライブラリは、ｆｗｒｉｔｅ及びｆｒｅａｄを、ｆｇｅｔｃとｆｐｕｔｃに取り替えるもう１つのラッパ関数を含む。ここでは、ｆｇｅｔｃ及びｆｐｕｔｃは、ディスクに基づくチャンネルの代わりに、ＩＰＣチャンネルの使用へと修正されている。上記関数の取り替えによれば、ローカル・バッファにおいては最小サイズのみが必要となるので、データ転送速度の向上が可能である。本例では、例えば、ローカル・バッファのサイズを１バイトもしくは１ワードに限定しても良い。本実施形態にｆｗｒｉｔｅ及びｆｒｅａｄが使用される場合には、共用メモリに設定したローカル・バッファは、１ブロックのデータ（例えば、２０４８バイト・ブロック）を収容できる大きさとしなければならない。したがって、場合によっては、共用メモリを用いたｆｗｒｉｔｅ及びｆｒｅａｄを使用するデータ転送では、ｆｐｕｔｃ及びｆｇｅｔｃを使用する場合と比較して、ある程度の遅延が生じる可能性がある。
【００５５】
ローカル・バッファのサイズを制限する方法は、上述の例に限定されるものではなく、モジュール間データ転送のためのバッファサイズが、結果としてより小さくなるか、あるいは最小値となるものであれば、それ以外の関数、コマンド、方法または手法を使用することが可能である。
【００５６】
上述の実施形態において、モジュールは、モジュールのプログラムにあるｆｏｐｅｎ及びｆｃｌｏｓｅ関数を含むものとされている。しかし、モジュールのプログラムによっては、ｆｏｐｅｎならびにｆｃｌｏｓｅを備えていない場合がある。上記モジュールは、プログラムの実行前にオープンされ、プログラムの実行後にクローズされる事前に定義されている入力及び／又は出力を使用する。上記事前定義の入力及び／又は出力は、次のとおりである。
１．ｓｔｄｎ（ＳｔａｎＤａｒｄＩＮの略語）、
２．ｓｔｄｏｕｔ（ＳｔａｎＤａｒｄＯＵＴの略語）、及び
３．ｓｔｄｅｒｒ  （ＳｔａｎＤａｒｄＥＲＲの略語）。
【００５７】
例えば、事前にｓｔｄｏｕｔをオープンにせずに、ｓｔｄｏｕｔにデータを書き込むことは可能である。これはプログラムを開始する前に、すでにそれがオープンされているためである。
【００５８】
前述したようなケースの多くにおいては、標準入出力として、パイプのような比較的効率の悪いＩＰＣ方法を、これらの入出力用に使用している。これらの標準入出力をより効率的にするために、これら部分をより効率的なＩＰＣ方法へ交換しても良い。
【００５９】
また、潜在的なアプリケーションのすべてを実行するには、任意のモジュールのｓｔｄｏｕｔを、任意のモジュールの入力と接続可能とすることが望ましい。これは、例えば、ｓｔｄｉｎを共用メモリ通信チャンネルに接続すれば達成することができる。ここでモジュールにはｆｏｐｅｎ（ｓｔｄｉｎ）がないため、モジュールのアプリケーション・プログラム実行の前にｆｏｐｅｎ（ｓｔｄｉｎ）を呼び出す。これは、モジュールのプログラムのｍａｉｎ関数用にラッパを作成すれば達成できる。ラッパｍａｉｎは、ｓｔｄｉｎをｆｏｐｅｎし、ｓｔｄｏｕｔをｆｏｐｅｎし、望ましくは共用メモリを設定し、それからオリジナルのｍａｉｎを呼び出す。このようなｍａｉｎラッパの一例を以下に挙げる。
＃ｄｅｆｉｎｅ    ｍａｉｎ    ｏｒｉｇｉｎａｌ＿ｍａｉｎ
ｍａｉｎ（ａｒｇｖ，  ａｒｇｃ）
…
／＊  ｇｅｔ  ｓｔｄｉｎ／ｓｔｄｏｕｔ  ｎａｍｅｓ  ｆｒｏｍ  ａｒｇｖ  ＊／
ｓｔｄｏｕｔ＝ｆｏｐｅｎ  （ｆｎａｍｅ，）
ｓｔｄｉｎ＝ｆｏｐｅｎ  （ｆｎａｍｅ，）
ｏｒｉｇｉｎａｌ＿ｍａｉｎ  （ａｒｇｖ，  ａｒｇｃ）
ｆｃｌｏｓｅ  （ｓｔｄｉｎ）
…
さらに、元来ｓｔｄｉｎとｓｔｄｏｕｔを使用するよう定義した、すべての入力と出力に名前をつけてもよい。言い換えれば、モジュールが含まれるシステムに属するモジュールの全入力と出力の名前及びその結果生じる種類を、使用コマンド行に指定しても良い。例えば、次のシェル・コマンド行は、モジュールＡとモジュールＢを、入力及び出力ファイル名ＦｉｎとＦｏｕｔに接続する際に、それぞれ使用できる。
（１）例１
ｍｏｄｕｌｅ Ａ    Ｆｉｎ    ／ｄｅｖ／ｓｈｍ１
ｍｏｄｕｌｅ  Ｂ    ｄｅｖ／ｓｈｍ１    Ｆｏｕｔ
（２）例２
ｍｏｄｕｌｅ Ａ＜Ｆｉｎ  ｜  ｍｏｄｕｌｅ Ｂ＞Ｆｏｕｔ    ｏｒ    （ｍｏｄｕｌｅ Ａ＜Ｆｉｎ）＞（ｍｏｄｕｌｅ Ｂ＞Ｆｏｕｔ）
本実施形態の詳細例については、次の項で説明される。
【００６０】
また、本実施形態において、バッファ特性（サイズなどの）の設定をサポートする上記で提案したシェル構文の修正は、バッファサイズを追加的に定義する便利な方法を提供する。即ち、修正ライブラリでバッファ特性を定義する修正シェル構文は、本発明の実施形態においてもっとも強力なモードの一つとなることが可能である。
【００６１】
上述の本実施形態によれば、次の有利な点が達成でき、より効率的な開発とより良い製品品質が促進される。
（１）ＡＮＳＩ−Ｃ標準入出力ライブラリは、もっとも広く使用されているＡＰＳの一つであり、上述した本発明の実施形態及び例を適用する場合に各モジュールでの必要な変更を、最小限に抑えている。
（２）標準入出力ライブラリが広く使用されているため、上述の実施形態及び例によるモジュールは、非常に携帯性が高く、他の環境においても簡単に使用できる。
（３）既存のＡＰＩを使用しても、上述の例で提案されたアーキテクチャは、組織的な観点から考えた場合でも、侵入性の程度がより低い。
（４）場合によっては、モジュールのスタンドアローン版のソース・コードは、統合版のモジュールと同一に作ることができるため、保守とテストが必要となる、版および組み立ての回数を著しく減少させることができる。
（５）ＡＮＳＩ−Ｃ標準入出力は、例えば、機能的改良または拡張のため修正がもっと頻繁な、多くの他のＡＰＩとは異なり、安定したＡＰＩである。したがって、上述の実施形態及び例のモジュールは、より少ない保守ですむ。
（６）この標準入出力―ＡＰＩは、単純な汎用入力、出力インタフェースであるため、モジュールが、各モジュールにおいて装置特定またはＩＰＣ（Ｉｎｔｅｒ  Ｐｒｏｃｅｓｓ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）特定コードとなることを効果的に防ぐ。なお、パイプと共用メモリは、ＩＰＣ方法の例である。その代わりに、装置特定またはＩＰＣ特定コードを一箇所（修正ライブラリ）に集中化し、その結果、保守が容易となる。
【００６２】
図８−１４を参照しながら本発明の他の実施形態について説明する。以下では、従来の技術を最初に説明し、それから本発明に係る実施形態に関する種々な例について説明する。
【００６３】
図８は、従来の技術で複数のモジュールを構成、接続して実現したコーデック・システムの例である。本例では、システムは、次の順序のコマンドで構成及び接続される。
ｂａｓｈ＄  ｖｉｄｅｏ ｅｎｃ  ｖｉｄｅｏ ｉｎ．ｄａｔ＞ｖｉｄｅｏ ｅｎｃ ｏｕｔ．ｄａｔ
ｂａｓｈ＄  ａｕｄｉｏ ｅｎｃ  ａｕｄｉｏ ｉｎ．ｄａｔ＞ａｕｄｉｏ ｅｎｃ ｏｕｔ．ｄａｔ
ｂａｓｈ＄  ｍｕｘ  ｖｉｄｅｏ ｅｎｃ＿ｏｕｔ．ｄａｔ    ａｕｄｉｏ ｅｎｃ ｏｕｔ．ｄａｔ  ｜  ｄｍｘ  ｖｉｄｅｏ ｄｅｃ ｉｎ．ｄａｔ  ａｕｄｉｏ ｄｅｃ ｉｎ．ｄａｔ
ｂａｓｈ＄  ｖｉｄｅｏ ｄｅｃ  ｖｉｄｅｏ ｏｕｔ．ｄａｔ＜ｖｉｄｅｏ ｄｅｃ ｉｎ．ｄａｔ
ｂａｓｈ＄  ａｕｄｉｏ ｄｅｃ  ａｕｄｉｏ ｏｕｔ．ｄａｔ＜ａｕｄｉｏ ｄｅｃ ｉｎ．ｄａｔ
なお、“ｂａｓｈ＄”は、コマンド行プロンプトである。つまり、シェルは、これをシステムのコンソールまたは端末に書き込む。各コマンドは、一つ一つ実行され、中間（例えば、ハードディスクまたはＲＡＭディスク）ファイルは、例えば、各エンコーダからマルチプレクサへデータを伝送するために使用される。
【００６４】
上記システム実現の基礎技術を提供するプラットフォームの一つが、ＵＮＩＸ（登録商標）である。この例では、シェルがモジュールを実体化し（必要時に）、これらのモジュールを接続する。事実上、全ＵＮＩＸ（登録商標）シェルが入力と出力のリダイレクションという概念をサポートする。即ち、“ｓｔｄｉｎ”と呼ばれる入力から読み取る、または、“ｓｔｄｏｕｔ”か“ｓｔｄｅｒｒ”へエラーに書き込むコードは、コンプリメンタリ・インタフェースを使用して、他のモジュールと接続可能なモジュールとする。
【００６５】
図８に示す例では、システムは完全なコーデック、つまり、コーディング・システム＋デコーディング・システムである。コーディング・システムは、ビデオ・エンコーダ・モジュール２１１（“ｖｉｄｅｏ ｅｎｃ”と呼ばれる）、オーディオ・エンコーダ・モジュール２１２（“ａｕｄｉｏ ｅｎｃ”と呼ばれる）及びマルチプレクサ２１３（“ｍｕｘ”と呼ばれる）より成る。デコーディング・システムは、デマルチプレクサ２２３（“ｄｍｘ”と呼ばれる）、ビデオ・デコーダ２２１（“ｖｉｄｅｏ ｄｅｃ”と呼ばれる）及びオーディオ・デコーダ２２２（“ａｕｄｉｏ ｄｅｃ”と呼ばれる）より成る。
【００６６】
なお、上記コマンド行は、ＵＮＩＸ（登録商標）及びシェルの機能を示す例である。本システムは、特別な状態においてのみ役に立つ。言い換えれば、多重データが直ちに多重分離されるような場合には、データを多重化する理由はない。しかし、このシステムは、コ−デック処理の確認もしくは性能評価に使用できる。
【００６７】
上記コマンド行で、これらのモジュールとデータファイルは、図８に示されるように接続される。ビデオ入力ファイル２０１（ｖｉｄｅｏ ｉｎ．ｄａｔ）及びオーディオ入力ファイル２０２（ａｕｄｉｏ ｉｎ．ｄａｔ）のデータは、コーディング・システムでコーディングされる。デコーディング・システムでは、デコードされたデータが、ビデオ出力ファイル２３１（ｖｉｄｅｏ ｏｕｔ．ｄａｔ）及びオーディオ出力ファイル２３２（ａｕｄｉｏ ｏｕｔ．ｄａｔ）へ出力される。
【００６８】
上述したような標準入力／標準出力リダイレクションに加えて、ｋｓｈ（＝Ｋｏｒｎ）シェル及び最近のｂａｓｈ（Ｂｏｕｒｎｅ  Ａｇａｉｎ）シェルは、ファイル名をプロセスで代入するために使用する「プロセス・サブステチューション」と呼ばれる機能を有する。したがって、モジュールのコマンド行に指定できるファイルを読み取るか、あるいは書き込むモジュールで、他のモジュールに接続できるが、その場合、後者がそのインタフェースに対応しているものを有しているかが条件となる。
【００６９】
本実施形態では、図８に示すようにコーデック・システム設定用モジュールの構成及び接続は、上記プロセス・サブステチューションを使用すれば改善することができる。下記にその例を示す。
ｂａｓｈ＄ｍｕｘ＜（ｖｉｄｅｏ ｅｎｃ  ｖｉｄｅｏ ｉｎ．ｄａｔ）＜（ａｕｄｉｏ ｅｎｃ  ａｕｄｉｏ ｉｎ．ｄａｔ）｜ｄｍｘ＞（ｖｉｄｅｏ ｄｅｃ  ｖｉｄｅｏ ｏｕｔ．ｄａｔ）＞（ａｕｄｉｏ ｄｅｃ  ａｕｄｉｏ ｏｕｔ．ｄａｔ）
シェルの名前（即ち、ファイル名）が“ｂａｓｈ”であれば、上述例のコマンドは、また、次のように実行される。
ｂａｓｈ＄ｂａｓｈ−ｓ＜＜ＥＯＦ
ｍｕｘ  ＜（ｖｉｄｅｏ ｅｎｃ  ｖｉｄｅｏ ｉｎ．ｄａｔ）＜（ａｕｄｉｏ ｅｎｃ  ａｕｄｉｏ ｉｎ．ｄａｔ）  ｜  ｄｍｘ  ＞  （ｖｉｄｅｏ ｄｅｃ  ｖｉｄｅｏ ｏｕｔ．ｄａｔ）＞（ａｕｄｉｏ ｄｅｃ  ａｕｄｉ ｏｕｔ．ｄａｔ）
ＥＯＦ
しかしながら、図８に示す例では、標準入力／標準出力リダイレクション及びプロセス・サブステチューションは、ある特定の種類のアプリケーションにおいて、次のような欠点がある場合がある。
【００７０】
（１）これらの方式では、通常、中間ディスクファイルを重複して作成するが、多くの場合、これらは、モジュール接続においてもっとも効率的な方法とは云えない。例えば、共用メモリは、「ネームド・パイプ」といった他のＩＰＣ（Ｉｎｔｅｒ  Ｐｒｏｃｅｓｓ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）方法より、モジュール接続に関してはるかに効率的な方法である。パイプの場合、メモリコピー関数（例えばＡＮＳＩ−Ｃ関数ｍｅｍｃｐｙ（））を使用して、データを１個のプロセスから次のプロセスに転送する。そして上記メモリコピー関数は、比較的非効率的である。より具体的には、ＵＮＩＸ（登録商標）システムでは、各モジュールを１プロセスとして作り、各プロセスに別個のメモリスペースを与えるのが通常である。上記メモリ保護は、非常に安定したシステムを作るためには良いが、高いビットレートでデータを処理する、ある特定のＡＶコーデックには、あまり適切でない。言い換えれば、図８に示す構成では、高いビットレートのＡＶコーデック・システムのリアルタイム処理に対して、十分なメモリの共用を提供できない。
【００７１】
（２）上述の方法で構成されたシステムに関するデフォルトＵＮＩＸ（登録商標）プロセス・スケジューリングは、しばしば、リアルタイム・コーディングまたはデコーディング・システムにおいて好適なものではない。例えば、ＭＰＥＧデコーディング・システムでは、ＡＶ同期の回復及びコード・バッファの完全さを管理する初期のステップとして、しばしば適切な立上げ遅延が各デコーダに要求される。しかし、実体化され、単純シェルコマンドと接続したモジュールは、一般的に、直ちにデコーディングを開始し、定期的にバッファを空にする。
【００７２】
例えば、正しいＡＶ同期のリアルタイム・コーディングに関しては、一般に、次の条件（２−１）〜（２−３）を満たさなければならない。
【００７３】
（２−１）すべてのバッファが適切なサイズであること。通常、ＭＰＥＧデコーディング・システムでは、ビデオコード・バッファがオーディオコード・バッファより格段に大型であることを意味する。なお、従来型のシェルでは、全モジュール間に単一のデフォルトバッファ・サイズを使用する。また、デフォルトバッファ・サイズは、一般に、例えば、通常のＭＰＥＧビデオコード・バッファ・サイズより非常に小さい。これは、得られるシステムがリアルタイム処理に不適当である場合があるということを意味する。
【００７４】
（２−２）各デコーダでは適切な立上げが必要である。通常、ビデオ・デコーダの立上げ遅延はオーディオ・デコーダの立上げ遅延より長い。また、これらの立上げ遅延の時間的な長さは、デコーディングがビットの流れのどの場所で開始したかにかかっている。
【００７５】
（２−３）立上げ後、各デコーダは、適切な速度で「アクセス・ユニット」をデコードしなければならない。「完全な」クロックは存在しないが、デコーダは、デコーディング速度に等しい平均速度で作動しなければならない（バッファ資源が限定されている時）。このため、デコーディング・システムがスレーブである場合、これは特に困難となる。例えば、２９．９７Ｈｚのビデオ・エンコーダは、クロックの不正確さが原因で２９．９６Ｈｚの速度で作動するかもしれない。したがって、限られたバッファ資源を備えた、直接または間接に「接続された」ビデオ・デコーダも、バッファ・アンダーフローかオーバーフローを避けるために、平均速度２９．９７Ｈｚで作動すべきである。
【００７６】
上述のように、従来の技術でよく使用される標準バッファ・サイズは、しばしば、リアルタイム処理においては適切でない。本発明に係るさらに他の実施形態では、パイプ、共用メモリ及びその他の種類のバッファ・サイズを設定可能にするために、シェルコマンド構文が拡張されている。したがって、デフォルトバッファ・サイズが適切でない場合、バッファ・サイズは、次の例にみられるように、修正することができる。
ｂａｓｈ＄  ｍｕｘ＜（２０００００  ｖｉｄｅｏ ｅｎｃ  ｖｉｄｅｏ ｉｎ．ｄａｔ）＜（ａｕｄｉｏ ｅｎｃ  ａｕｄｉｏ ｉｎ．  ｄａｔ）｜  １８８０  ｄｍｘ＞（３０００００  ｖｉｄｅｏ ｄｅｃ  ｖｉｄｅｏ ｏｕｔ．ｄａｔ）＞（ａｕｄｉｏ ｄｅｃ ａｕｄｉｏ ｏｕｔ．ｄａｔ）
ここで、ビデオ・エンコーダの出力バッファは２０００００バイトに設定し、ビデオ・デコーダの入力バッファを３０００００バイトに設定する。ｍｕｘとｄｅｍｕｘ間のバッファは１８８０バイトに設定している。本例では、デフォルトバッファ・サイズは、オーディオ・エンコーダとオーディオ・デコーダにとって受け入れ可能なものと仮定している。
【００７７】
本発明に係るさらに他の実施形態は、新型のシェルを開発および利用に関するものである。本実施形態によるシェルは、可能な限り共用メモリを使用する。次の例では、本実施形態によるシェルは、“ｓｈａｒｅｄ＿ｍｅｍｏｒｙ＿ｓｈｅｌｌ”と呼ばれている。
ｂａｓｈ＄  ｓｈａｒｅｄ ｍｅｍｏｒｙ ｓｈｅｌｌ−ｓ＜＜ＥＯＦ
ｍｕｘ  ＜（ｖｉｄｅｏ ｅｎｃ  ｖｉｄｅｏ ｉｎ．ｄａｔ）＜（ａｕｄｉｏ ｅｎｃ  ａｕｄｉｏ ｉｎ．  ｄａｔ）  ｜  ｄｍｘ＞（ｖｉｄｅｏ ｄｅｃ  ｖｉｄｅｏ ｏｕｔ．ｄａｔ）＞（ａｕｄｉｏ ｄｅｃ ａｕｄｉｏ ｏｕｔ．ｄａｔ）
ＥＯＦ
本例では、ｓｈａｒｅｄ ｍｅｍｏｒｙ ｓｈｅｌｌは−ｓオプションつきの従来型のｂａｓｈシェルでスタートする。標準ｂａｓｈシェルでは、このオプションの意味は、標準入力からのコマンドを読み取ることである。ｂａｓｈシェルは、２個の“ＥＯＦ”マーカ間のすべてのテキストをｓｈａｒｅｄ ｍｅｍｏｒｙ ｓｈｅｌｌの標準入力へ転送する。このテキストは、ｓｈａｒｅｄ ｍｅｍｏｒｙ ｓｈｅｌｌのコマンド行である。
【００７８】
また、コマンド構文は、ｂａｓｈシェルのものと同じである。なお、従来型のｂａｓｈ構文とオプションにしたがう利点は、既存のスクリプトとコマンド行が変更なしで利用できることである。
【００７９】
上記ｓｈａｒｅｄ ｍｅｍｏｒｙ ｓｈｅｌｌは、従来型のｂａｓｈシェルとしてモジュールを実体化し、接続するが、次の相違点がある。つまり、モジュールの接続にパイプを使用する代わりに、共用メモリ９００を使用することである。これを図９に示す。
【００８０】
図１０は、本実施形態におけるモジュール接続に関する、さらに他の例を示す。この例では、共用メモリ９００をサポートしないモジュールの実体化とＩＰＣは、従来型のシェルに委任している。この方法では、ｓｈａｒｅｄ ｍｅｍｏｒｙ ｓｈｅｌｌはスーパー・シェルとなり、従来型のシェルはサブ・シェルとなる。本例では、ＩＰＣがそのような低ビット速度のストリームに対しては十分と考えられていたため、オーディオ・エンコーダ２１２とオーディオ・デコーダ２２２は、共用メモリ処理をサポートしない。数字８００、１１００、１２００は、パイプ、従来型のサブ・シェルにより実体化及び管理された部品をそれぞれ示している。
【００８１】
次のコマンド行（即ち、“＜（ａｕｄｉｏ ｅｎｃ  ａｕｄｉｏ ｉｎ．  ｄａｔ）”及び“＜（ａｕｄｉｏ ｄｅｃ  ａｕｄｉｏ ｏｕｔ．ｄａｔ）”）のオーディオ関係箇所は、サブ・シェルに渡される。
ｂａｓｈ＄  ｓｕｐｅｒ ｓｈｅｌｌ−ｓ＜＜ＥＯＦ
ｍｕｘ  ＜（ｖｉｄｅｏ ｅｎｃ  ｖｉｄｅｏ ｉｎ．ｄａｔ）＜（ａｕｄｉｏ ｅｎｃ  ａｕｄｉｏ ｉｎ．  ｄａｔ）  ｜  ｄｍｘ  ＞（ｖｉｄｅｏ ｄｅｃ  ｖｉｄｅｏ ｏｕｔ．ｄａｔ）＞（ａｕｄｉｏ ｄｅｃ ａｕｄｉｏ ｏｕｔ．ｄａｔ）
ＥＯＦ
図１２は、本実施形態による共用メモリ・シェルの例を示し、図１１は、従来の技術によるモジュール設定に対応する例である。図１１及び図１２に示すシェルコマンド行１１００と１２００は、マルチプレクサ及びビデオ・エンコーダ・モジュールの実体化と接続のためのものである。
【００８２】
図１１の例では、これらのモジュールは、従来型の標準入出力ライブラリを使用して、例えば、パイプに接続されている。一方、本実施形態に係る図１２の例では、本実施形態による修正ｂａｓｈシェル１２１０が、関連ファイル名に応じて、共用メモリ・ライブラリかオリジナル標準入出力ライブラリを経て、モジュールを実体化し接続する。ここで、標準入出力に対して新しく定義したアーギュメントパラメータ、オリジナルｍａｉｎプログラムをラップするｍａｉｎラッパ、そして標準入出力関数か共用メモリ・ライブラリ関数のどちらかを呼び出すラッパ関数つき修正標準入出力ライブラリを使用する。
【００８３】
具体的には、図１２の例において、実体化されスタートするモジュールは、ｍｕｘ＿ｓｍ．ｅｘｅ  １２２０及びｖｉｄｅｏ ｅｎｃ ｓｕｍ．ｅｘｅ１２３０であり、２個の追加アーギュメントがｍａｉｎラッパに指定されている。各ｍａｉｎラッパには、対応するオリジナルのｍａｉｎプログラムが呼び出され、標準入力と標準出力は、新しく定義されたアーギュメントパラメータにより設定される。
【００８４】
本例における標準入出力ライブラリは、図６及び７の例と同じ機能を具備している。
【００８５】
図１３及び１４を参照しながら、本実施形態の他の例を説明する。
【００８６】
図１３は、標準入出力ライブラリを使用してモジュールの標準出力をファイルに接続するために、入出力リダイレクションを使用する従来型のシェルの例である。図１４は、本実施形態による例を示す。本例では、標準入力及び出力（即ち、ｓｔｄｉｎとｓｔｄｏｕｔ）は、コマンド行１４００のパラメータとして指定されている。オリジナルモジュールの変更をできるだけ避けるために、ｓｔｄｉｎ及び  ｓｔｄｏｕｔパラメータを、例えば、コマンド行末に付け足し、ｍａｉｎラッパ１４１２で処理する。このラッパは、オリジナルｍａｉｎプログラムを呼び出し、オリジナル・モジュール、すなわちｖｉｄｅｏ ｅｎｃ  ｏｒｉｇ．  ｍａｉｎ１４２２、を実体化しスタートさせる。標準入出力ライブラリ１４２３は、本例に使用されている。
【００８７】
また、すべてのモジュール入出力を、コマンド行で指定することも可能である。本例によれば、シェルの代わりに、修正モジュールは入出力（ｓｔｄｉｏを含む）リダイレクションに対して責任を持つ。ＵＮＩＸ（登録商標）の環境では、入力または出力を“／ｄｅｖ／ｎｕｌｌ”として指定することは、実質的に“不使用”の意味となる。一貫性を保つために、第３のパラメータ、つまりｓｔｄｅｒｒを付け足すベきでもあるが、これは図示されていない。
【００８８】
また、本例のフレームワークでオリジナルのｖｉｄｅｏ ｅｎｃを使用するに、＃ｄｅｆｉｎｅｓをヘッダファイルに付け加える。ある特定の環境では、このファイルに“ｓｔｄｉｏ．ｈ”という名前を与えて、例えば、次のように、オリジナルのｓｔｄｉｏ．ｈを取り替えることが可能である。
ｓｔｄｉｏ．ｈ
＃ｄｅｆｉｎｅ    ｓｔｄｏｕｔ     ｎｅｗ ｓｔｄｏｕｔ
＃ｄｅｆｉｎｅ    ｍａｉｎ（ａ，ｂ） ｏｒｉｇ ｍａｉｎ（ａ，ｂ）
＃ｄｅｆｉｎｅ    ｅｘｉｔ（ａ）     ｎｅｗ ｅｘｉｔ（ａ）
上述の例及び実施形態によれば、次の有利な点の達成が可能となる。
【００８９】
（１）中間ファイルの代わりに、ＡＶコーデック設定にプロセス・サブステチューションを使用し、より効率的な（すなわち、より高速の）通信方法が使用可能となる。もう一つの利点は、コーデックがファイルシステムのない環境においても使用できる点である。さらに、プロセス・サブステチューションの構文は実質的にはグラフィックなので、書き込みやすく理解しやすいことである。したがって上記構文で行う上記システムの開発、保守がよりしやすくなる。
【００９０】
（２）オプションのバッファ特性パラメータにより、コマンド構文は、従来のｂａｓｈ／ｋｓｈ構文との互換性がなくなる可能性がある。しかし、これにより、リアルタイム処理がサポートされ、正確なＡＶタイミングが効率的に、ユーザ・フレンドリなやり方で可能になる。なお、このユーザとは、モジュールを開発し、開発したモジュールをシステムに組み込む技術者である。
【００９１】
（３）共用メモリのため、モジュール間の通信はより効率的（メモリコピー処理がより少ないため）となる。また、共用メモリは、より少ないメモリ資源を使用する。非共用メモリ・モジュールを従来のサブ・シェルに委託し、汎用（例えば、従来の）モジュールも従来どおり、本システムにて使用できる。したがって、このプラットフォームへのマイグレーションがより簡単になる。
【００９２】
【発明の効果】
本発明によれば、リアルタイム処理を要するシステムを構成するために、各種のモジュールを接続可能にする装置及び方法が提供される。
【００９３】
さらに本発明によれば、リアルタイム・オーディオ・コーデック用のシステム構成のために、各種のモジュールをより接続しやすくする方法、モジュール及び／又はモジュールを含むシステムが提供される。
【００９４】
本発明によれば、既存のソフトウェア、または新規の独立ソフトウェアを、最小限の変更で、（２）効率的な通信を行い、そして（３）モジュールの入出力を接続するための最大限の柔軟性で使用できるフレームワークが提供される。
【図面の簡単な説明】
【図１】従来の技術において、コーデック・システムを構成するために接続される標準入出力ライブラリ付きモジュールの一例を示す模式図である。
【図２】従来の技術において、コーデック・システムを構成するために接続される標準入出力ライブラリ付きモジュールの他の例を示す模式図である。
【図３】コーデック・システムを構成するために接続される共用メモリ付きモジュールの一例を示す模式図である。
【図４】図４（Ａ）：出力用の共用メモリつきモジュールの一例を示す模式図である。図４（Ｂ）：入力用の共用メモリつきモジュールの一例を示す模式図である。
【図５】コーデック・システムを構成するために接続される修正標準入出力ライブラリつきモジュールの一例を示す模式図である。
【図６】図６（Ａ）：修正標準入出力ライブラリつきモジュールの一例を示す模式図である。
図６（Ｂ）：修正標準入出力ライブラリつきモジュールの他の例を示す模式図である。
【図７】図７（Ａ）：バッファ特性の設定機能を有するモジュールの一例を示す模式図である。
図７（Ｂ）：バッファ特性の設定機能を有するモジュールの他の例を示す模式図である。
【図８】パイプを伴う複数のモジュールを構成、接続して実現するコーデック・システムの一例を示す模式図である。
【図９】共用メモリを伴う複数のモジュールを構成、接続して実現するコーデック・システムの一例を示す模式図である。
【図１０】共用メモリとパイプを伴う複数のモジュールを構成、接続して実現するコーデック・システムの一例を示す模式図である。
【図１１】従来の技術によるモジュール設定の一例を示す模式図である。
【図１２】本発明による共用メモリ・シェルの一例を示す模式図である。
【図１３】モジュールのｓｔｄｏｕｔをファイルに接続して入出力リダイレクションを使用する従来型シェルの一例を示す模式図である。
【図１４】コマンド行のパラメータとして指定された標準入出力を有する、本発明によるシェルの一例を示す模式図である。
【符号の説明】
１０１〜１０６…標準入出力ライブラリを有するモジュール、２０１〜２０６…パイプドライバ、３０１〜３０６…共用メモリ・ライブラリ、５０１〜５０６…修正標準入出力ライブラリ。
【図１】
2004259033.tif 000003
【図２】
2004259033.tif 000004
【図３】
2004259033.tif 000005
【図４】
2004259033.tif 000006
【図５】
2004259033.tif 000007
【図６】
2004259033.tif 000008
【図７】
2004259033.tif 000009
【図８】
2004259033.tif 000010
【図９】
2004259033.tif 000011
【図１０】
2004259033.tif 000012
【図１１】
2004259033.tif 000013
【図１２】
2004259033.tif 000014
【図１３】
2004259033.tif 000015
【図１４】
2004259033.tif 000016
【外国語明細書】
2004259033.tif 000017
2004259033.tif 000018
2004259033.tif 000019
2004259033.tif 000020
2004259033.tif 000021
2004259033.tif 000022
2004259033.tif 000023
2004259033.tif 000024
2004259033.tif 000025
2004259033.tif 000026
2004259033.tif 000027
2004259033.tif 000028
2004259033.tif 000029
2004259033.tif 000030
2004259033.tif 000031
2004259033.tif 000032
2004259033.tif 000033
2004259033.tif 000034
2004259033.tif 000035
2004259033.tif 000036
2004259033.tif 000037
2004259033.tif 000038
2004259033.tif 000039
2004259033.tif 000040
2004259033.tif 000041
2004259033.tif 000042
2004259033.tif 000043
2004259033.tif 000044
2004259033.tif 000045
2004259033.tif 000046
2004259033.tif 000047
2004259033.tif 000048
2004259033.tif 000049
2004259033.tif 000050
2004259033.tif 000051
2004259033.tif 000052
2004259033.tif 000053
2004259033.tif 000054
2004259033.tif 000055
2004259033.tif 000056
2004259033.tif 000057
2004259033.tif 000058
2004259033.tif 000059
2004259033.tif 000060
2004259033.tif 000061
2004259033.tif 000062
2004259033.tif 000063
2004259033.tif 000064
2004259033.tif 000065
2004259033.tif 000066
2004259033.tif 000067
2004259033.tif 000068
2004259033.tif 000069
2004259033.tif 000070
2004259033.tif 000071
2004259033.tif 000072
2004259033.tif 000073
2004259033.tif 000074
2004259033.tif 000075
2004259033.tif 000076
2004259033.tif 000077
2004259033.tif 000078
2004259033.tif 000079
2004259033.tif 000080