(57)【要約】  方法、機械読取り可能な媒体、システムおよび装置が開示される。一実施形態では、この方法は、マルチメディア・ストリームを含む１またはそれ以上の成分がリアルタイム処理を必要とするかどうかを判断すること、１またはそれ以上の成分のうちの少なくとも１つがリアルタイム処理を必要とする場合、リアルタイム処理を必要とする１またはそれ以上の成分を１またはそれ以上のリアルタイム・プロセスに割り当てること、および残余のあらゆる成分を１またはそれ以上の非リアルタイム・プロセスに割り当てることを含む。
2008527472.tif 000002
【特許請求の範囲】
【請求項１】
マルチメディア・ストリームを含む１またはそれ以上の成分がリアルタイム処理を必要とするかどうかを判断する段階と、
前記１またはそれ以上の成分のうちの少なくとも１つがリアルタイム処理を必要とする場合、リアルタイム処理を必要とする前記１またはそれ以上の成分を１またはそれ以上のリアルタイム・プロセスに割り当てる段階と、
残余のあらゆる成分を１またはそれ以上の非リアルタイム・プロセスに割り当てる段階と、
を含むことを特徴とする方法。
【請求項２】
前記マルチメディア・ストリームは複数のパケットを含み、各パケットは、前記１またはそれ以上の成分のすべてのパケット化された部分を有することを特徴とする請求項１記載の方法。
【請求項３】
前記１またはそれ以上の成分のそれぞれは、ビデオ情報、オーディオ情報、音声情報、データ情報、および、制御情報のうちの１または複数を含むことを特徴とする請求項２記載の方法。
【請求項４】
リアルタイム処理は、
前記パケットが前記ストリームのソース装置によって送信されるレートを決定する段階と、
各パケットを含む前記１またはそれ以上の成分のそれぞれを少なくとも、前記パケットが前記ストリームのソース装置によって送信されるレートで処理する段階と、
を含むことを特徴とする請求項２記載の方法。
【請求項５】
リアルタイム処理を必要とする前記ストリームの前記１またはそれ以上の成分を１またはそれ以上のリアルタイム・プロセスに割り当てる段階は、
前記ストリーム内の各パケットをその１またはそれ以上の成分にラップ解除する段階と、
各パケット内のリアルタイム処理を必要とする前記１またはそれ以上の成分のそれぞれをリアルタイムで処理するのに必要な処理量を決定する段階と、
各パケット内のリアルタイム処理を必要とする前記１またはそれ以上の成分のそれぞれを別個のプロセスに割り当てる段階と、
を含むことを特徴とする請求項４記載の方法。
【請求項６】
プロセスは、コンピューティング装置上で実行可能なスレッドを含むことを特徴とする請求項５記載の方法。
【請求項７】
各パケット内の前記１またはそれ以上の成分のそれぞれを別個のコンピューティング装置上のプロセスに割り当てる段階をさらに含むことを特徴とする請求項５記載の方法。
【請求項８】
成分に優先度レベルを割り当てる段階をさらに含み、前記優先度レベルは、前記成分の情報の重要性に基づいて計算されることを特徴とする請求項３記載の方法。
【請求項９】
残余のあらゆる成分を１またはそれ以上の非リアルタイム・プロセスに割り当てる段階は、
各パケット内のリアルタイム処理を必要としない前記成分のそれぞれに対して許容可能な最大遅延を決定する段階と、
各パケット内のリアルタイム処理を必要としない前記成分のそれぞれを別個のプロセスに割り当てる段階であって、各プロセスは前記許容可能な遅延時間内にそれぞれの各成分を処理するのに必要な処理量を少なくとも提供する、段階と、
をさらに含むことを特徴とする請求項８記載の方法。
【請求項１０】
パケットの複数の前記成分を順次処理する段階をさらに含み、処理される前記成分の順序は成分の優先度レベル順であり、最高の優先度レベル成分が最初に処理され、最低の優先度レベル成分が最後に処理されることを特徴とする請求項８記載の方法。
【請求項１１】
パケット生成直後にパケットの前記ストリームをリアルタイムで格納装置内に一時的に格納することによって、低優先度レベルのパケット成分の情報損失を防ぐ段階をさらに含むことを特徴とする請求項１０記載の方法。
【請求項１２】
前記ストリームの前記成分のすべてがリアルタイムで処理可能であるとは限らない場合、少なくとも１つのパケットからの少なくとも１つの成分が処理から除外され得るかどうかを判断する段階と、
少なくとも１つの成分が除外され得る場合、前記成分を除外する段階と、
をさらに含むことを特徴とする請求項８記載の方法。
【請求項１３】
最低優先度レベルを有する前記成分を除外する段階をさらに含むことを特徴とする請求項１２記載の方法。
【請求項１４】
除外された同じ成分を含む最大数の連続したパケットを設定する段階をさらに含むことを特徴とする請求項１３記載の方法。
【請求項１５】
ソース装置から送信された前記ストリームの形式を決定する段階と、
宛先装置が必要とする前記ストリームの形式を決定する段階と、
前記ソース装置のストリームの形式が前記必要とされる宛先装置ストリームの形式と同じである場合、前記ストリームを処理せずに前記ソース装置と前記宛先装置との間で前記ストリームを直接に送信する段階と、
をさらに含むことを特徴とする請求項１記載の方法。
【請求項１６】
２またはそれ以上の成分を同じプロセスに割り当てる段階をさらに含み、それぞれの成分の優先度が処理の順序を決めることを特徴とする請求項８記載の方法。
【請求項１７】
マルチメディア・ストリームを含む１またはそれ以上の成分がリアルタイム・トランスコーディングを必要とするかどうかを判断する段階と、
前記１またはそれ以上の成分のうちの少なくとも１つがリアルタイム・トランスコーディングを必要とする場合、リアルタイム・トランスコーディングを必要とする前記１またはそれ以上の成分を１またはそれ以上のリアルタイム・プロセスに割り当てる段階と、
残余のあらゆる成分を１またはそれ以上の非リアルタイム・プロセスに割り当てる段階と、
をさらに含むことを特徴とする請求項１記載の方法。
【請求項１８】
命令をその上に実装した機械読取り可能な媒体において、機械によって実行されるとき、前記機械は、
マルチメディア・ストリームを含む１またはそれ以上の成分がリアルタイム処理を必要とするかどうかを判断する段階と、
前記１またはそれ以上の成分のうちの少なくとも１つがリアルタイム処理を必要とする場合、リアルタイム処理を必要とする前記１またはそれ以上の成分を１またはそれ以上のリアルタイム・プロセスに割り当てる段階と、
残余のあらゆる成分を１またはそれ以上の非リアルタイム・プロセスに割り当てる段階と、
を含む方法を実施することを特徴とする機械読取り可能な媒体。
【請求項１９】
前記マルチメディア・ストリームは複数のパケットを含み、それぞれのパケットは、前記１またはそれ以上の成分のすべてのパケット化された部分を有することを特徴とする請求項１８記載の機械読取り可能な媒体。
【請求項２０】
前記１またはそれ以上の成分のそれぞれは、ビデオ情報、オーディオ情報、音声情報、データ情報、および、制御情報を含むリストからの情報のタイプを含むことを特徴とする請求項１９記載の機械読取り可能な媒体。
【請求項２１】
リアルタイム処理は、
前記パケットがストリームのソース装置によって送信されるレートを決定する段階と、
各パケットを含む前記１またはそれ以上の成分のそれぞれを、前記パケットが前記ストリーム・ソース装置によって送信されるレートで少なくとも処理する段階と、
を含むことを特徴とする請求項１９記載の機械読取り可能な媒体。
【請求項２２】
リアルタイム処理を必要とする前記ストリームの前記１またはそれ以上の成分を１またはそれ以上のリアルタイム・プロセスに割り当てる段階は、
前記ストリーム内の各パケットをその１またはそれ以上の成分にラップ解除する段階と、
各パケットを含む前記１またはそれ以上の成分のそれぞれをリアルタイムで処理するのに必要な処理量を決定する段階と、
各パケット内の前記１またはそれ以上の成分のそれぞれを別個のプロセスに割り当てる段階と、
を含むことを特徴とする請求項２１記載の機械読取り可能な媒体。
【請求項２３】
成分に優先度レベルを割り当てる段階をさらに含み、前記優先度レベルが前記成分の情報の重要性に基づいて計算されることを特徴とする請求項２０記載の機械読取り可能な媒体。
【請求項２４】
残余のあらゆる成分を１またはそれ以上の非リアルタイム・プロセスに割り当てる段階は、
各パケット内のリアルタイム処理を必要としない前記成分のそれぞれに対して許容可能な最大遅延を決定する段階と、
各パケット内のリアルタイム処理を必要としない前記成分のそれぞれを別個のプロセスに割り当てる段階であって、それぞれのプロセスは、前記許容可能な遅延時間内にそれぞれの各成分を処理するのに必要な処理量を少なくとも提供する段階と、
をさらに含むことを特徴とする請求項２３記載の機械読取り可能な媒体。
【請求項２５】
パケットの複数の前記成分を順次処理する段階さらに含み、処理される前記成分の順序が成分の優先度レベル順であり、最高の優先度レベル成分が最初に処理され、最低の優先度レベル成分が最後に処理されることを特徴とする請求項２３記載の機械読取り可能な媒体。
【請求項２６】
前記ストリームの前記成分のすべてがリアルタイムで処理可能であるとは限らない場合、少なくとも１つのパケットからの少なくとも１つの成分が処理から除外され得るかどうかを判断する段階と、
少なくとも１つの成分が除外され得る場合、前記成分を除外する段階と、
をさらに含むことを特徴とする請求項２３記載の機械読取り可能な媒体。
【請求項２７】
最低優先度レベルを有する前記成分を除外する段階をさらに含むことを特徴とする請求項２６記載の機械読取り可能な媒体。
【請求項２８】
除外された同じ成分を含む最大数の連続したパケットを設定する段階をさらに含むことを特徴とする請求項２７記載の機械読取り可能な媒体。
【請求項２９】
ソース装置から送信された前記ストリームの形式を決定する段階と、
宛先装置が必要とする前記ストリームの形式を決定する段階と、
前記ソース装置のストリームの形式が前記必要とされる宛先装置ストリームの形式と同じである場合、前記ストリームを処理せずに前記ソース装置と前記宛先装置との間で前記ストリームを直接に送信する段階と、
をさらに含むことを特徴とする請求項１８記載の機械読取り可能な媒体。
【請求項３０】
バスと、
前記バスに結合されたプロセッサと、
前記バスに結合されたネットワーク・インターフェース・カードと、
前記プロセッサに結合されたメモリであって、前記プロセッサによって実行されると、
マルチメディア・ストリームを含む１またはそれ以上の成分がリアルタイム処理を必要とするかどうか判断し、
前記１またはそれ以上の成分のうちの少なくとも１つがリアルタイム処理を必要とする場合、リアルタイム処理を必要とする前記１またはそれ以上の成分を１またはそれ以上のリアルタイム・プロセスに割り当て、
残余のあらゆる成分を１またはそれ以上の非リアルタイム・プロセスに割り当てる、
命令を格納するために適応したメモリと、
を含むことを特徴とするシステム。
【請求項３１】
前記マルチメディア・ストリームは複数のパケットを含み、それぞれのパケットは前記１またはそれ以上の成分のすべてのパケット化された部分を有することを特徴とする請求項３０記載のシステム。
【請求項３２】
前記１またはそれ以上の成分のそれぞれは、ビデオ情報、オーディオ情報、音声情報、データ情報、および、制御情報を含むリストからのある情報のタイプを含むことを特徴とする請求項３１記載のシステム。
【請求項３３】
リアルタイム処理は、
前記パケットがストリームのソース装置によって送信されるレートを決定する段階と、
各パケットを含む前記１またはそれ以上の成分のそれぞれを、前記パケットが前記ストリーム・ソース装置によって送信されるレートで少なくとも処理する段階と、
を含むことを特徴とする請求項３２記載のシステム。
【請求項３４】
リアルタイム処理を必要とする前記ストリームの前記１またはそれ以上の成分を１またはそれ以上のリアルタイム・プロセスに割り当てる段階は、
前記ストリーム内の各パケットをその１またはそれ以上の成分にラップ解除する段階と、
各パケットを含む前記１またはそれ以上の成分のそれぞれをリアルタイムで処理するのに必要な処理量を決定する段階と、
各パケット内の前記１またはそれ以上の成分のそれぞれを別個のプロセスに割り当てる段階と、
を含むことを特徴とする請求項３３記載のシステム。
【請求項３５】
プロセスは、コンピューティング装置上で実行可能なスレッドを含むことを特徴とする請求項３４記載のシステム。
【請求項３６】
各パケット内の前記１またはそれ以上の成分のそれぞれを別個のコンピューティング装置上のプロセスに割り当てる段階をさらに含むことを特徴とする請求項３４記載のシステム。
【請求項３７】
成分に優先度レベルを割り当てる段階をさらに含み、前記優先度レベルが前記成分の情報の重要性に基づいて計算されることを特徴とする請求項３２記載のシステム。
【請求項３８】
パケットの複数の前記成分を順次処理する段階をさらに含み、処理される前記成分の順序が成分の優先度レベル順であり、最高の優先度レベル成分が最初に処理され、最低の優先度レベル成分が最後に処理されることを特徴とする請求項３７記載のシステム。
【請求項３９】
パケット生成直後にパケットの前記ストリームをリアルタイムで格納装置内に一時的に格納することによって、低優先度レベルのパケット成分の情報損失を防ぐ段階をさらに含むことを特徴とする請求項３８記載のシステム。
【請求項４０】
前記ストリームの前記成分のすべてがリアルタイムで処理可能であるとは限らない場合、少なくとも１つのパケットからの少なくとも１つの成分が処理から除外され得るかどうかを判断する段階と、
少なくとも１つの成分が除外され得る場合、前記成分を除外する段階と、
をさらに含むことを特徴とする請求項３８記載のシステム。
【請求項４１】
最低優先度レベルを有する前記成分を除外する段階をさらに含むことを特徴とする請求項４０記載のシステム。
【請求項４２】
除外された同じ成分を含む最大数の連続したパケットを設定する段階をさらに含むことを特徴とする請求項４１記載のシステム。
【請求項４３】
ソース装置から送信された前記ストリームの形式を決定する段階と、
宛先装置が必要とする前記ストリームの形式を決定する段階と、
前記ソース装置のストリームの形式が前記必要とされる宛先装置ストリームの形式と同じである場合、前記ストリームを処理せずに前記ソース装置と前記宛先装置との間で前記ストリームを直接に送信する段階と、
をさらに含むことを特徴とする請求項３０記載のシステム。
【請求項４４】
残余のあらゆる成分を１またはそれ以上の非リアルタイム・プロセスに割り当てる段階は、
各パケット内のリアルタイム処理を必要としない前記成分のそれぞれに対して許容可能な最大遅延を決定する段階と、
各パケット内のリアルタイム処理を必要としない前記成分のそれぞれを別個のプロセスに割り当てる段階であって、各プロセスは、前記許容可能な遅延時間内にそれぞれの各成分を処理するのに必要な処理量を少なくとも提供する段階と、
をさらに含むことを特徴とする請求項３４記載のシステム。
【請求項４５】
第１のマルチメディア・ストリームをその個別の成分にラップ解除するために動作可能なストリーム・アンラッパー・ユニットと、
前記１またはそれ以上の成分のそれぞれを１またはそれ以上のプロセスに割り当てるために動作可能なプロセス割当てユニットと、
前記１またはそれ以上の個別の成分のそれぞれを処理するために動作可能なアルゴリズム処理論理と、
前記処理された１またはそれ以上の個別の成分のうちの少なくとも１つを第２のマルチメディア・ストリームにラップするために動作可能なストリーム・ラッパー・ユニットと、
を含むことを特徴とする装置。
【請求項４６】
前記プロセス割当てユニットは、各成分の優先度を決定し、最高の優先度を有する前記成分に最高優先度のプロセスを割り当てるためにさらに動作可能であることを特徴とする請求項４５記載の装置。
【請求項４７】
前記プロセス割当てユニットは、前記１またはそれ以上の個別の成分のそれぞれをラップする優先度に関する情報を前記ストリーム・アンラッパー・ユニットに送信するためにさらに動作可能であることを特徴とする請求項４５記載の装置。
【請求項４８】
前記アルゴリズム処理論理は、前記１またはそれ以上の個別の成分のそれぞれを処理するための前記アルゴリズム処理論理に使用可能なリソースに関する情報を送信するためにさらに動作可能であることを特徴とする請求項４５記載の装置。
【請求項４９】
前記ストリーム・ラッパー・ユニットは、前記１またはそれ以上の個別の成分のそれぞれを前記成分の優先度順にラップするためにさらに動作可能であることを特徴とする請求項４７記載の装置。
【請求項５０】
前記ストリーム・ラッパー・ユニットは、前記ラップされた１またはそれ以上の成分のそれぞれを宛先装置に送信するためにさらに動作可能であることを特徴とする請求項４５記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチメディア・ストリームの処理に関する。より詳細には、本発明は、マルチメディア・ストリームを処理するためのアルゴリズム・プロセスの知的選択に関する。
【背景技術】
【０００２】
音楽ダウンロード、ビデオ録画、および電話での会話時など、マルチメディア・ストリームとの対話（ｉｎｔｅｒａｃｔｉｏｎ）は、社会に普及している。これらのストリームを送受信するために設計された電子装置のタイプは、ストリーム自体の形式と同じくらい様々である。ある電子装置のユーザが別の電子装置のユーザに情報を送信する場合、通信が有効に行われるには、形式が互いに互換性を有することが必要である。多くの場合、２つの電子装置が使用する形式は全く互換性がなく、したがって、２つの装置間で移動する情報を変換するために、中間の装置が使用されなければならない。トランスコーダと呼ばれる装置は、ある形式のマルチメディア・ストリームを別の形式に変換し、したがって人々は互いに容易に通信し、これらの異なる装置および異なるマルチメディア・ストリーム形式をそのまま使用することができる。トランスコーディングは現在、単方向、双方向、または多方向ストリーム用など、様々な異なるシナリオにおいて使用される。
【０００３】
単方向トランスコーディングは、ある装置がマルチメディア・ストリームを別の装置に送信する状況において使用される。ビデオ・メッセージングおよびビデオ・ストリーミングは、単方向トランスコーディングの例である。図１Ａは、マルチメディア・ストリームの単方向トランスコーディングを必要とし得るトランザクションの一例を示す。この例では、ビデオ・ストリーム１００は、第１のコンピュータ１０２から第２のコンピュータ１０４に送信される。第１のコンピュータ１０２からのビデオは、とりわけＭＰＥＧ２、ＭＰＥＧ４、ＧＳＭ（ｇｌｏｂａｌ  ｓｙｓｔｅｍ  ｆｏｒ  ｍｏｂｉｌｅ  ｃｏｍｍｕｎｉｃａｔｉｏｎｓ：移動通信用グローバル・システム）またはＡＭＲ（ａｄａｐｔｉｖｅ  ｍｕｌｔｉ−ｒａｔｅ：適応マルチレート）を含めて、多くの異なる可能な形式のうちの１つに符号化される。第２のコンピュータ１０４は、ストリーミング・ビデオを受信し復号し、ビデオモニタ上に表示する。
【０００４】
単方向トランスコーディングの別の例は、ボイスメールである。ある人が、オフィスにいないことを発呼者に知らせるため、そのボイスメール・システムにメッセージを記録することを望み得る。その人は、メッセージを保存したいか、それとも再び録音したいかを決定するために、メッセージを再生することを望み得る。その人は、Ｇ．７１１形式の電話を通して話すことができ、ボイスメール・システムは、ＷＡＶファイルにメッセージを記録することがある。この場合もやはり、トランスコーディング・ステップが必要である。
【０００５】
双方向トランスコーディングは、潜在的にはビデオ通話やオーディオ（たとえば電話）通話時など、２つの装置が互いにストリームを送信するときに使用される。図１Ｂは、マルチメディア・ストリームの双方向トランスコーディングを必要とし得る双方向ビデオ通話の例を示す。この例では、ビデオ・ストリーム１１０は、第１のコンピュータ１１２から第２のコンピュータ１１４に、また第２のコンピュータ１１４から第１のコンピュータ１１０に送信される。
【０００６】
多方向トランスコーディングは、たとえば三者テレビ会議時など、３つ以上の装置が互いにストリームを送信するときに使用される。図１Ｃは、多方向トランスコーディングを必要とし得る三者テレビ会議の一例を示す。この例では、まさに図１Ｂの例のように、複数のコンピュータが互いの間でビデオ・ストリームを送受信する。この例では、第１のコンピュータ１２２、第２のコンピュータ１２４および携帯型のモバイル・コンピュータ／携帯電話１２６は、互いの間でストリーム１２０を送受信する。
【０００７】
多くの場合において、図１Ａ、図１Ｂおよび図１Ｃに示されたコンピュータはそれぞれ、マルチメディア・ストリームを異なる形式で符号化し復号し得る。たとえば、図１Ｃの２つのコンピュータ（１３０，１３２）は、ＭＰＥＧ４形式のストリームを符号化し復号し得るが、モバイル・コンピュータ／携帯電話１３４は、ＭＰＥＧ４を符号化または復号できないことがあり、そうではなく、ＧＳＭ形式ストリームだけを符号化し復号する。この場合、３つの装置のそれぞれから来るストリームを傍受し、ストリームを各宛先装置の固有の形式に変換するために、トランスコーディング装置が使用され得る。
【０００８】
ビデオ・ストリームは、トランスコーダがどこで必要とされ得るかについての多くの可能な例のうちの単に１つである。たとえば、固定電話を使用する人が、携帯電話上の友人に電話をかける場合、必要なトラスコーディング・ステップがある。標準の固定電話は一般に、Ｇ．７１１形式を使用して動作する。呼に応答する友人は一般に、ＧＳＭ、ＡＭＲまたは他の携帯電話音声形式の技術を有する。したがって、２人の友人が互いに話を聞くためには、彼らが話している間、トランスコーディング・ステップが必要である。
【０００９】
これらのトランスコーディングの例の多くに必要な処理能力は、非常に様々である。一部の例ではリアルタイムのトランスコーディングが必要であるが、他では必要ない。「リアルタイム」は、トランスコードされていないマルチメディア・ストリームがトランスコーダに到達するのと同じレートでマルチメディア・ストリームをトランスコードし、出力するためにトランスコーダに必要とされるおよその速度を指す。したがって、音声ストリームをリアルタイムでトランスコードするには、人が言葉を実際に発するレートで音声情報をトランスコードすることが必要である。したがって、固定電話線と携帯電話線とを介して互いに話している２人の友人は、リアルタイムで互いに話しており、オーディオの遅延が許容され得ないので、リアルタイムでトランスコードされる形式をもたなければならない。三者のテレビ会議は、リアルタイムでトランスコードされる必要がある３つのストリームがあるだけでなく、ストリームが、単に純粋な音声成分パケットよりもパケット当たり遥かに多い情報である音声およびビデオ成分を含むパケットで構成されるので、さらに多くの処理能力を必要とする。
【００１０】
現在、リアルタイムのトランスコーディング・システムは通常、パケット内のどんな形の情報もリアルタイムでトランスコードされ得ることを保証するために、専用デジタル信号プロセッサを備えたサーバなど、非常に強力なプロセッサを使用する。多くの場合、この量の処理能力は必要ない。オフィス不在メッセージを記録しており、次いでその記録を調べる人は、リアルタイムでは操作していない。人が電話に向かって話すときと、調べている間にその記録された音声を聞くときとの間には、複数秒の範囲の遅延がある。
【００１１】
非リアルタイムのオフラインのやり方でトランスコーディングを実施するトランスコーディング・システムもある。パーソナル・コンピュータ上のユーザは、ＤＶＤに格納するために、ＶＨＳテープをＡＶＩファイルに変換し得る。最後に、トランスコーディングが全く行われない実装形態があり、たとえば生ビデオ、音声またはオーディオ形式のストリームが、ネットワークを介して送信されることができる。このタイプのストリームは、生形式のストリームが圧縮されておらず、非常に多くのネットワーク帯域幅を必要とするので、効率的ではない。
【００１２】
本発明は、例示するために示されており、添付の図面の諸図によって限定されるものでない。図面では、同じ参照符号は、類似の要素を示す。
【発明の開示】
【００１３】
マルチメディア・ストリームを処理するための有効な方法の実施形態が開示される。以下の説明では、複数の特定の詳細について述べる。しかし、諸実施形態は、これらの特定の詳細事項がなくても実施され得ることが理解されよう。他の場合では、よく知られている要素、応用例および技術は、本発明を不明瞭にしないようにするため、詳細には論じられない。
【００１４】
図２は、マルチメディア・ストリーム処理管理システム（ＭＳＰＭＳ：ｍｕｌｔｉｍｅｄｉａ  ｓｔｒｅａｍ  ｐｒｏｃｅｓｓｉｎｇ  ｍａｎａｇｅｍｅｎｔ  ｓｙｓｔｅｍ）を備えたコンピュータ・システムの一実施形態のブロック図である。コンピュータ・システムは、プロセッサ２００と、メモリ・コントローラ・ハブ（ＭＣＨ：ｍｅｍｏｒｙ  ｃｏｎｔｒｏｌｌｅｒ  ｈｕｂ）２０２と、Ｉ／Ｏコントローラ・ハブ（ＩＣＨ：Ｉ／Ｏ  ｃｏｎｔｒｏｌｌｅｒ  ｈｕｂ）２１０とを含む。ＭＣＨ  ２０２およびＩＣＨ  ２１０は、チップセットを含む。プロセッサ２００は、ホスト・バスを介してＭＣＨ  ２０２に結合される。ＭＣＨ  ２０２は、システム・メモリ２０４に結合される。異なる実施形態では、システム・メモリは、同期ダイナミック・ランダム・アクセス・メモリ（ＳＤＲＡＭ：ｓｙｎｃｈｒｏｎｏｕｓ  ｄｙｎａｍｉｃ  ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ）、ダブル・データ・レートＳＤＲＡＭ（ＤＤＲ  ＳＤＲＡＭ：ｄｏｕｂｌｅ  ｄａｔａ  ｒａｔｅ  ＳＤＲＡＭ）、ラムバスＤＲＡＭ（ＲＤＲＡＭ：Ｒａｍｂｕｓ  ＤＲＡＭ）、またはメイン・システム・メモリの他の多くの形式のうちの１つがあり得る。
【００１５】
一実施形態では、コンピュータ・システムは、システム・メモリ２０４に格納されており、またプロセッサ２００によって操作／実行されるＭＳＰＭＳ２０６を含む。異なる実施形態では、ＭＳＰＭＳ２０６は、処理が必要とする速度（たとえばリアルタイムや非リアルタイム）、ストリームを含む異なる成分（たとえばオーディオ成分、音声成分、ビデオ成分、データ成分および制御成分）のそれぞれに関連付けられた優先度、およびマルチメディア・ストリームを実際に処理する特定の装置の割当てなど、マルチメディア・ストリーム処理に関する複数の管理決定を制御し得る。異なる実施形態では、実際にマルチメディア・ストリームを処理する装置は、他にも多くの可能な処理装置があるが、特に挙げると、デジタル信号プロセッサ、ネットワーク・サーバ、リモート・デスクトップ・コンピュータ、または図２に示すコンピュータ・システム（プロセッサ２００を含む）があり得る。
【００１６】
ＭＣＨ２０２もまた、グラフィックス・モジュール２０８に結合される。ＩＣＨ  ２１０は、ハード・ドライブ２１２およびＩ／Ｏバス２１４に結合される。Ｉ／Ｏバス２１４は、ネットワークとのインターフェースを取るネットワーク・インターフェース・カードに結合される。異なる実施形態では、ネットワークは、ローカル・エリア・ネットワーク、公衆電話システム、インターネット、広域ネットワーク、ワイヤレス・ネットワーク、またはコンピューティング装置間でデータを送り届けることができる他の任意のネットワークがあり得る。
【００１７】
図３は、マルチメディア・ストリーム処理管理システム（ＭＳＰＭＳ）の一実施形態を示す。この実施形態では、ＭＳＰＭＳの処理論理３００は、マルチメディア・ストリーム・ソース３０２と宛先３１８との間に位置する。ソース３０２は、マルチメディア・ストリームを生成し符号化し、ネットワークを介して宛先装置３１８に送信する。ストリームは、複数の連続するパケットで構成される。
【００１８】
それぞれのパケットは、複数の成分を含み得る。パケットの各成分は、ストリームに関する、ある情報のタイプからなる。たとえば、オーディオ／ビデオ・ストリーム用のパケットは、音声成分と、別個のビデオ成分とを含むことができる。異なる例では、ストリーム内で命令を送信するデータ成分、（特定の音声情報に対して）音楽およびバックグラウンド・ノイズ情報を含む一般的なオーディオ成分、ならびに他のタイプの制御情報もあるが特に挙げると、セキュリティ情報、認証情報およびサービス品質（ＱＯＳ：ｑｕａｌｉｔｙ  ｏｆ  ｓｅｒｖｉｃｅ）情報を含み得る制御成分など、マルチメディア・ストリームをやはり構成する他の成分があり得る。パケット内の各成分は、その成分について所定量の情報を含む。パケット当たりの成分ごとの情報量は通常、時間で測定される。たとえば、マルチメディア・ストリームの個別のパケット内の音声成分は、１００ミリ秒の記録された音声からなり得る。成分情報とは別に、それぞれのパケットはヘッダ情報を含み、このヘッダ情報は、パケットが正確な宛先へとルーティングされることを可能にするためのアドレス情報を含む。
【００１９】
図３に戻ると、たとえばソース３０２は、ＭＰＥＧ２形式を必要とする宛先３１８にＭＰＥＧ４形式のビデオ・ストリームを送信しており、次いでストリームは、宛先３１８に到着する前にトランスコードされなければならない。この実施形態では、ＭＳＰＭＳ処理論理３００は、ストリームを傍受する。ストリームは、ストリーム・アンラッパー・ユニット３０４に入る。ストリーム・アンラッパー・ユニット３０４は、ストリームを、その個別の成分へとラップ解除する（ｕｎｗｒａｐ）。ストリームの個別の成分は、プロセス割当てユニット３０６にルーティングされる。現在の例では、ビデオ成分はラップ解除され、プロセス割当てユニット３０６に送信される。一実施形態では、ヘッダ・アドレス情報は、ストリーム・アンラッパー・ユニット３０４からストリーム・ラッパー・ユニット３１６に直接送信される。
【００２０】
次いで、プロセス割当てユニット３０６は、１またはそれ以上のストリーム成分のそれぞれを、１またはそれ以上のアルゴリズム・プロセス（３０８，３１０，３１２，３１４）を含む処理論理に割り当てる。「アルゴリズム・プロセス」は、マルチメディア・ストリームの１またはそれ以上の成分を何らかのやり方で修正することができる方法またはプロセスである。アルゴリズム・プロセスの例には、特に挙げると、マルチメディア・ストリームの成分をトランスコードする方法、マルチメディア・ストリームの特定の成分を除外する方法、マルチメディア・ストリームの成分の処理を遅延させる方法、リアルタイム・トランスポート・プロトコル（ＲＴＰ：ｒｅａｌ−ｔｉｍｅ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ）ストリームをバッファリングする方法が含まれる。
【００２１】
しばしば、特定のタスクを完了するために、２つ以上のアルゴリズム・プロセスが使用されなければならない。たとえば、ユーザが、ボイスメールを残すことを望み得る。ユーザは、電話番号を呼び出し、ボイスメール・システムが、呼に応答する。ユーザがメッセージを残すとき、第１のアルゴリズム・プロセスは、ＲＴＰストリームを介して来る実際の音声データをバッファリングすることがあり、第２のアルゴリズム・プロセスは、ユーザ・メッセージ中に電話のいずれかのボタンが押下されるときを検出するために発信音を監視することがあり（デュアル・トーン・マルチ周波数（ＤＴＭＦ：ｄｕａｌ−ｔｏｎｅ  ｍｕｌｔｉ−ｆｒｅｑｕｅｎｃｙ）検出）、また第３のアルゴリズム・プロセスは、より格納しやすい形式にＲＴＰストリームをトランスコードすることがある。この場合、ＲＴＰストリーム・バッファおよびＤＴＭＦ検出アルゴリズム・プロセスは、有効なユーザ対話を生成するためにリアルタイムで操作されなければならず、そうでない場合、ボイスメールは有用なものとならず、トランスコーディング・プロセスは、単に使用可能なときに（ｏｎ  ａｎ  ａｖａｉｌａｂｌｅ  ｂａｓｉｓ）バッファから情報を取り出す。したがって、ＲＴＰおよびＤＴＭＦのアルゴリズム・プロセスは、トランスコーディング・プロセスよりも高い優先度を有することがあり、それらのプロセスは、ＭＳＰＭＳによって、それに応じて管理される。
【００２２】
一実施形態では、アルゴリズム・プロセスの優先順位付けは、ユーザの知覚に関する成分の重要性に基づいて遂行され得る。上記の例では、ボイスメールのユーザ対話は、ユーザの声の明瞭な記録を維持するための機能を優先する。したがって、ＲＴＰストリームのバッファリングは、ＲＴＰストリームのいずれかの部分を除外すると情報の損失が生じ、メッセージの一部またはすべてにおいてユーザの声が聞こえなくなるので、そのストリームを異なる形式にトランスコードするよりも明らかに遥かに重要である。したがって、一実施形態では、Ｎ個のアルゴリズム・プロセスがあり、そのそれぞれは、ストリーム成分の処理を異なるやり方で遂行し得る。一実施形態では、それぞれのアルゴリズム・プロセスは、各成分の重要性に基づいて、それに送信される成分の処理を優先順位付けする。したがって、この実施形態では、プロセス割当てユニット３０６が単一のアルゴリズム優先順位付けプロセスに２つ以上の成分を割り当てる場合、その２つ以上の成分は、それらの優先度の順序で処理される。異なる実施形態では、優先度は、ネットワーク伝送速度、ユーザがストリームを理解できるようにするための異なる成分の相対的重要性、他の成分との関係における成分の帯域幅消費、または任意の数の他の要因など、要因を考慮に入れるアルゴリズムに基づいて決定され得る。
【００２３】
たとえば、テレビ会議において、ビデオ成分が使用可能でない場合、オーディオ通信が依然として実行可能な代案であるが、しかし、オーディオ成分が使用可能でない場合、通信の効率は、単にビデオ供給を伴い、劇的に減少する。別の例では、多成分パケットのマルチメディア・ストリーム中のビデオ成分は通常、最も大きい帯域幅および演算能力を消費し、したがって、アルゴリズム・プロセスは、単にビデオをリアルタイムでトランスコードすることができてもよく、あるいはそれは、他の成分（おそらくオーディオ、音声、データおよび制御成分）のすべてをリアルタイムでトランスコードすることができてもよく、したがって、４つの成分は、単に１つの成分よりも優先することがある。さらに、すべての成分をリアルタイムで、またはさらには遅延型（非リアルタイム）のやり方で処理するためのリソースが使用可能でない場合、別のオプションは、より低い優先度の成分のある割合を除外することである。したがって、ビデオ成分が最低の優先度である場合、１つおき（または２つおき、３つおきなど）のパケット化成分だけを処理する特定のアルゴリズム・プロセスに成分を割り当てることの決定は、プロセス割当てユニット３０６によって行われることができ、それによって、より低いフレーム・レートがもたらされる。
【００２４】
別の実施形態では、Ｎ個のアルゴリズム・プロセスのうちの２つ以上は、単一のコンピュータ・システム上で実行する。この実施形態では、２つ以上の各成分もまた、割り当てられたそれ自体の優先度レベルを有する。したがって、一例では、マルチメディア・ストリームは、それぞれがプロセス割当てユニット３０６によって別個のアルゴリズム・プロセスに割り当てられたビデオ成分と音声成分とを有する場合、音声成分プロセスは、コンピュータ・システム内で、ビデオ成分プロセスより高い操作優先度を有し得る。この場合、コンピュータ・システムが両方のプロセスを同時に実行できるほど十分なリソースを有していない場合、ビデオ成分プロセスは、音声成分プロセスが１またはそれ以上のマルチメディア・ストリーム・パケットの音声成分の処理を完了する間、遅延される。別の実施形態では、Ｎ個のアルゴリズム・プロセスはそれぞれ、ローカル・コンピュータ・システム内のそれ自体のスレッド上で実行される。この実施形態では、ローカル・コンピュータ・システムは、それぞれのスレッドに、各プロセス・スレッドに割り当てられた成分の優先度に一致する特定の優先度を割り当て得る。
【００２５】
別の実施形態では、Ｎ個のアルゴリズム・プロセスのうちの２つ以上は、２つ以上の別個のコンピュータ・システム上で実行される。この実施形態では、プロセス割当てユニット３０６は、最も多い使用可能リソースを備えたコンピュータ・システム上で実行されるアルゴリズム・プロセスのうちの１または複数を使用し得る。別の実施形態では、１つの成分は、２つ以上のアルゴリズム・プロセスに割り当てられ得る。この実施形態では、プロセス割当てユニット３０６は、ストリーム内の単一の成分内の情報を複数の部分に分割し、それぞれの部分を別個のアルゴリズム・プロセスに割り当てる。一実施形態では、プロセス割当てユニット３０６は、パケット単位レベルで２つのアルゴリズム・プロセス間で成分情報の送信を交互に行う（すなわち、第１のパケットの成分はアルゴリズム・プロセス１に送信され、第２のパケットの成分は、アルゴリズム・プロセス２に送信され、第３のパケットの成分は、アルゴリズム・プロセス３に送信されるなど）。
【００２６】
現在の例では、プロセス割当てユニット３０６は、ＭＰＥＧ４からＭＰＥＧ２にトランスコードするアルゴリズム・プロセスにビデオ成分を割り当てる。各パケットのビデオ成分が１またはそれ以上のアルゴリズム・プロセスによって処理されると、ビデオ成分（すなわち新しいＭＰＥＧ２形式ビデオ・ストリーム）は、ストリーム・ラッパー・ユニット３１６に送信される。一実施形態では、ストリーム・ラッパー・ユニット３１６は、個別の成分をカプセル化して、宛先に送信されるパケット化形式に戻す。一実施形態では、ストリーム・ラッパー・ユニット３１６は、１またはそれ以上のアルゴリズム・プロセスの出力としてストリーム・ラッパー・ユニット３１６が受信する各成分の宛先アドレスなどの情報を、ストリーム・アンラッパー・ユニット３０４から直接に得る。別の実施形態では、ストリーム・ラッパー・ユニット３１６は、成分単位の優先度情報および成分単位のパケット組合せ情報などの情報を、プロセス割当てユニット３０６から直接に受信する。成分単位の優先度情報は、ストリーム・ラッパー・ユニット３１６は、アルゴリズム・プロセスのうちの１または複数から到着する異なる成分のラッピングおよび送信を優先することを可能にする。成分単位のパケット組合せ情報は、ストリーム・ラッパー・ユニット３１６が、複数の成分を単一のパケットに組み込むことを可能にし、あるいは個別の成分は、より高い優先度などの理由により、別個のパケットにラップされ送信されることを可能にする。
【００２７】
現在の例では、ストリーム・ラッパー・ユニット３１６は、新しくトランスコードされたＭＰＥＧ２ビデオ成分を受信し、宛先アドレス情報および他の任意の関連情報を付けて成分を再びラッピングし、宛先３１８にストリームを送信する。
【００２８】
一実施形態では、所与の成分をどのアルゴリズム・プロセスに割り当てるか決定するとき、プロセス割当てユニット３０６は、他の情報もあるが特に挙げると、アルゴリズム・プロセスが実行される各コンピュータ・システムのネットワーク接続性およびスループット、各コンピュータ・システムが使用可能にする空きリソースの量、そのそれぞれのコンピュータ・システム内の各アルゴリズム・プロセスの優先度を含めた情報を考慮に入れる。この実施形態では、プロセス割当てユニット３０６は、各コンピュータ・システム内で実行されるアルゴリズム・プロセスから（図３の破線矢印）、それぞれのコンピュータ・システムに関する情報を受信する。それぞれのアルゴリズム・プロセスに関するコンピュータ・システム情報を用いて、プロセス割当てユニット３０６（および一般にＭＳＰＭＳ）は、ストリームの知覚されるどんな性能低下をも最小限に抑えまたは取り除くために、どのようにしてストリーム内の各成分をできるだけ効率的に処理するか決定することができる。したがって、上記で示したように、ＭＳＰＭＳは、成分の優先度、および使用可能なシステム・リソースに応じて、ストリームの成分をリアルタイムで処理することも、非リアルタイムで処理することも、成分を全く処理しないこともある。
【００２９】
図４から図９は、ビデオおよび音声成分を伴うマルチメディア・ストリームの処理に関するＭＳＰＭＳ処理論理決定の複数の例を示す。これらの例では、この機能は、ストリーム内の各成分がトランスコーディングを必要とすることを示すが、異なる実施形態では、ビデオ・ストリームの一部またはすべてについて、部分的なトランスコーディングが許容可能であることも、トランスコーディングが全く行われないことが許容可能であることもある。さらに、ストリームの成分の処理は、ＲＴＰストリームのバッファリング、ＤＴＭＦ検出、または他の多くのマルチメディア・ストリーム処理機能のうちのいずれか１つなど、単なるトランスコーディング以外の他の多くの機能を含み得る。したがって、図４から図９のトランスコーディングの実施例は、単に例示的な実施例であり、それらは、マルチメディア・ストリームを伴って行われる任意の数の他のプロセスの代わりに用いられ得る。さらに、これらの実施例は、ストリーム内の単一のパケットについて説明するが、諸実施形態は、潜在的にはストリーム内のすべてのパケットについてプロセスを繰り返すことを含む。
【００３０】
図４は、マルチメディア・ストリーム・パケットを単一のアルゴリズム・プロセスを用いてトランスコードする方法の一実施形態を示す。この実施形態では、ソース５００は、ネットワークを介してマルチメディア・ストリーム・パケット５０２を送信する。パケット５０２は、パケットの宛先に関するすべてのルーティングおよびアドレス情報を有するヘッダ５０４を含む。この実施形態では、パケットは、ビデオ成分５０６および音声成分５０８を含む。一実施形態では、ビデオ成分は、１つのビデオ・フレーム（すなわち静止画像）を含み、音声成分は、１つの音声フレーム（すなわち１００ミリ秒の音声情報）を含む。一実施形態では、ヘッダ４０４は削除され、ビデオおよび音声成分だけを含むパケット４１０は、アルゴリズム・プロセス４１２に送信される。アルゴリズム・プロセス４１２は、各成分中の情報をトランスコードし、トランスコードされたビデオおよび音声成分だけを含む新しいパケットを出力する。ヘッダ４０４は、アルゴリズム・プロセスをバイパス４１４し、宛先４１８に送信される新しいパケット４１６の生成のため、トランスコードされたパケットに再び付けられ得る。この実施形態では、単一のアルゴリズム・プロセス４１２は、ビデオおよび音声成分を有するパケットのマルチメディア・ストリームを（リアルタイムで）トランスコードすることができる。一実施形態では、ヘッダ４０４は、ストリーム・ラッパー・ユニット（図３、３１６）によって、ストリーム・アンラッパー・ユニット（図３、３０４）およびプロセス割当てユニット（図３、３０６）から提供された情報に基づいて修正される。別の実施形態では、ヘッダ４０４は、パケットから削除されず、パケットは、完全なヘッダ４０４を付けてアルゴリズム・プロセスに送信される。
【００３１】
図５は、マルチメディア・ストリーム・パケットを複数のアルゴリズム・プロセスを用いてトランスコードする方法の一実施形態を示す。この実施形態では、ソース５００は、ネットワークを介してマルチメディア・ストリーム・パケット５０２を送信する。パケット５０２は、（図４で上述したように）ビデオ成分と音声成分とを含む。一実施形態では、ヘッダは削除され、パケット内のそれぞれ異なる成分も分離される。ビデオ成分５０４は、ビデオ・トランスコーディングのためアルゴリズム・プロセス＃１（５０８）に送信され、音声成分５０６は、音声トランスコーディングのためアルゴリズム・プロセス＃２（５１０）に送信される。異なる実施形態では、アルゴリズム・プロセス＃１（５０８）および＃２（５１０）は、同じコンピューティング装置に置かれることも、異なるコンピューティング装置に置かれることもある。アルゴリズム・プロセス＃１（５０８）および＃２（５１０）は、そのそれぞれのビデオおよび音声成分のトランスコーディングを完了するとき、トランスコーディング・プロセス（５１２，５１４）をバイパスしたヘッダは、トランスコードされた別個のビデオおよび音声成分パケット（５１６，５１８）に再び付けられ得る。ビデオ成分パケット５１６および音声成分パケット５１８は、宛先５２０に別々に到達する。一実施形態では、ヘッダは、ストリーム・ラッパー・ユニット（図３、３１６）によって、ストリーム・アンラッパー・ユニット（図３、３０４）およびプロセス割当てユニット（図３、３０６）から提供された情報に基づいて修正される。別の実施形態では、ヘッダはパケットから削除されず、パケットは、ヘッダが完全な状態でアルゴリズム・プロセスに送信される。したがって、アルゴリズム・プロセス自体は、ヘッダを修正し得る。
【００３２】
図６は、マルチメディア・ストリーム・パケットを複数のアルゴリズム・プロセスを用いてトランスコードする方法の別の実施形態を示す。この実施形態では、ソース６００は、ネットワークを介してマルチメディア・ストリーム・パケット６０２を送信する。パケット６０２は、（図４で上述したように）ビデオ成分と音声成分とを含む。ヘッダは削除され、パケット内のそれぞれ異なる成分も分離される。ビデオ成分６０４は、ビデオ・トランスコーディングのためアルゴリズム・プロセス＃１（６０８）に送信され、音声成分６０６は、音声トランスコーディングのためアルゴリズム・プロセス＃２（６１０）に送信される。アルゴリズム・プロセス＃１（６０８）および＃２（６１０）は、そのそれぞれのビデオおよび音声成分トランスコーディングを完了するとき、ビデオ成分および音声成分を多成分パケット６１４内に再び付ける。トランスコーディング・プロセスをバイパスしたヘッダは、多成分パケット６１４に再び付けられ、パケットは、宛先６１６に送信される。この実施形態では、トランコードされたいずれかの成分パケットは、もう一方のアルゴリズム・プロセスからの対応するパケットを所定の時間量より多く待たなければならない場合、パケット６１４は、最初に終了したアルゴリズム・プロセス内のどんなボトルネックをも最小限に抑えるため、ストリーム・ラッパー・ユニット（図３、３１６）によって、単に１つの成分を付けて宛先に送信される。一実施形態では、ヘッダは、ストリーム・ラッパー・ユニット（図３、３１６）よって、ストリーム・アンラッパー・ユニット（図３、３０４）およびプロセス割当てユニット（図３、３０６）から提供された情報に基づいて修正される。別の実施形態では、ヘッダはパケットから削除されず、パケットは、ヘッダが完全な状態でアルゴリズム・プロセスに送信される。したがって、アルゴリズム・プロセス自体は、ヘッダを修正し得る。
【００３３】
図７は、１つのアルゴリズム・プロセスおよび１つのバッファを用いてマルチメディア・ストリーム・パケットをトランスコードする方法の一実施形態を示す。この実施形態では、ソース７００は、ネットワークを介してマルチメディア・ストリーム・パケット７０２を送信する。パケット７０２は、（図４で上述したように）ビデオ成分と音声成分とを含む。ヘッダは削除され、パケット内のそれぞれ異なる成分も分離される。この実施形態では、音声成分７０４は、ビデオ成分７０６よりも優先し、したがって、音声成分７０４はアルゴリズム・プロセス７１０に直接送信され、ビデオ成分７０６は、アルゴリズム・プロセス７１０が音声成分７０４のトランスコーディングを完了するのを待つために、バッファ７０８に送信される。音声成分７０４のトランスコーディング・プロセスが終了すると、バッファ７０８は、格納されたビデオ成分７０６を、トランスコーディングのためアルゴリズム・プロセス７１０に解放する。音声成分またはビデオ成分のトランスコーディングが終了すると、トランスコードされた成分はヘッダ（７１２，７１４）に再び付けられ、個別のビデオまたは音声成分パケット（７１６，７１８）は、宛先７２０に送信される。一実施形態では、ヘッダは、ストリーム・ラッパー・ユニット（図３、３１６）によって、ストリーム・アンラッパー・ユニット（図３、３０４）およびプロセス割当てユニット（図３、３０６）から提供された情報に基づいて修正される。別の実施形態では、ヘッダはパケットから削除されず、パケットは、ヘッダが完全な状態でアルゴリズム・プロセスに送信される。したがって、アルゴリズム・プロセス自体は、ヘッダを修正し得る。
【００３４】
図８は、１つのアルゴリズム・プロセスおよび複数のバッファを用いてマルチメディア・ストリーム・パケットをトランスコードする方法の一実施形態を示す。この実施形態では、ソース８００は、ネットワークを介してマルチメディア・ストリーム・パケット８０２を送信する。パケット８０２は、（図４で上述したように）ビデオ成分と音声成分とを含む。ヘッダは削除され、パケット内のそれぞれ異なる成分も分離される。この実施形態では、１つのアルゴリズム・プロセス８１２だけが存在する。さらに、成分の優先度は、特定の状況に基づいてリアルタイムで変更され得る。この場合、ビデオ成分の優先度および音声成分の優先度は、トランスコーディング操作中、互いに対して増加することも、減少することもある。したがって、いずれかの成分は、アルゴリズム・プロセス８１２による他の成分のトランスコーディングの終了を待つ能力を有することを可能にするために、２つのバッファが使用される。
【００３５】
この実施形態では、ビデオ成分８０４は、バッファ＃１（８０８）に送信され、音声成分８０６は、バッファ＃２（８１０）に送信される。この実施形態では、アルゴリズム・プロセス８１２は、単一の成分を、バッファ＃１（８０８）またはバッファ＃２（８１０）のいずれかから一度に１つ取る。どのバッファから取るかについての決定は、各バッファ内で待機する個別の成分に割り当てられた優先度に依存する。アルゴリズム・プロセス８１２が個別の成分のトランスコーディングを終了すると、トランスコードされた成分は、ヘッダ（８１４または８１６）に再び付けられ、個別のビデオまたは音声成分パケット（８１８または８２０）は、宛先８２２に送信される。
【００３６】
一実施形態では、ヘッダは、ストリーム・ラッパー・ユニット（図３、３１６）によって、ストリーム・アンラッパー・ユニット（図３、３０４）およびプロセス割当てユニット（図３、３０６）から提供された情報に基づいて修正される。別の実施形態では、ヘッダはパケットから削除されず、パケットは、ヘッダが完全な状態でアルゴリズム・プロセスに送信される。したがって、アルゴリズム・プロセス自体は、ヘッダを修正し得る。
【００３７】
図９は、複数のアルゴリズム・プロセスおよび複数のバッファを用いてマルチメディア・ストリーム・パケットをトランスコードする方法の一実施形態を示す。この実施形態では、ソース９００は、ネットワークを介してマルチメディア・ストリーム・パケット９０２を送信する。パケット９０２は、（図５で上述したように）ビデオ成分と音声成分とを含む。ヘッダは削除され、パケット内のそれぞれ異なる成分も分離される。この実施形態では、２つのアルゴリズム・プロセス（９１２，９１４）が存在する。さらに、成分の優先度は、特定の状況に基づいてリアルタイムで変更され得る。一実施形態では、アルゴリズム・プロセス＃１（９１２）および＃２（９１４）は、同じコンピュータ・システム上ではあるが、個別のプロセス内に置かれる。この場合、ビデオ・トランスコーディング・プロセスの優先度および音声トランスコーディング・プロセスの優先度は、互いに対してだけでなく、コンピュータ・システム上で実行されている他のプロセスに対しても増加しまたは減少し得る。
【００３８】
たとえば、両方のアルゴリズム・プロセスが常駐するコンピュータ・システムは、インターネットからワームを受信し、ウィルス保護ソフトウェア・プログラムを実行するプロセスは、ビデオ・トランスコーディング・アルゴリズム・プロセスまたは音声トランスコーディング・アルゴリズム・プロセスのいずれかよりも一時的に優先する。したがって、この場合、それぞれのアルゴリズム・プロセスは、アルゴリズム・プロセス（９１２，９１４）がシステム上で高い優先度を再び得るのを待つ能力を両方の成分が有することを可能にするために、それ自体のバッファを有する。
【００３９】
この実施形態では、ビデオ成分９０４は、バッファ＃１（９０８）に送信され、音声成分９０６は、バッファ＃２（９１０）に送信される。この実施形態では、アルゴリズム・プロセス＃１（９１２）は、バッファ＃１（９０８）から個別のビデオ成分を取り、アルゴリズム・プロセス＃２（９１４）は、バッファ＃２（９１０）から個別の音声成分を取る。いずれかのアルゴリズム・プロセスが個別の成分のトランスコーディングを終了すると、トランスコードされた成分はそのヘッダ（９１６または９１８）に再び付けられ、個別のビデオまたは音声成分パケット（９２０または９２２）は、宛先９２４に送信される。
【００４０】
一実施形態では、ヘッダは、ストリーム・ラッパー・ユニット（図３、３１６）によって、ストリーム・アンラッパー・ユニット（図３、３０４）およびプロセス割当てユニット（図３、３０６）から提供された情報に基づいて修正される。別の実施形態では、ヘッダは、パケットから削除されず、パケットは、ヘッダが完全な状態でアルゴリズム・プロセスに送信される。したがって、アルゴリズム・プロセス自体は、ヘッダを修正し得る。
【００４１】
図１０は、成分優先度、および処理能力の制限に基づいて、個別の成分を除外するアルゴリズム・プロセスの一実施形態を示す。この実施形態では、ビデオ成分のストリーム１０００（すなわちビデオ・フレーム）および音声成分のストリーム１００２（すなわち音声フレーム）は、アルゴリズム・プロセス１００４に入力される。したがって、この実施形態のアルゴリズム・プロセス１００４は、図８に示されたアルゴリズム・プロセスに類似する。この実施形態では、アルゴリズム・プロセス１００４は、あらゆる音声フレームおよびあらゆるビデオ・フレームに遅れずについていくための処理能力を有していない。したがって、トランスコーディング作業の一部を行うことができるアルゴリズム・プロセスを備えた他のシステムがない場合には、ストリームのリアルタイム性を維持するため、特定のフレームが除外されなければならない。
【００４２】
音声成分がビデオ成分よりも高いトランスコーディング優先度を有する場合、特定のビデオ・フレームが除外され（すなわち除去され）なければならない。したがって、一実施形態では、４つのビデオ・フレームのストリーム１０００および４つの音声フレームのストリーム１００２は、アルゴリズム・プロセス１００４に入力される。アルゴリズム・プロセス１００４は、すべての音声フレームをトランスコードし、音声出力ストリーム１００６でそれを順番に送出する。またアルゴリズム・プロセス１００４は、その残りの処理能力を使用して、できるだけ多くのビデオ・フレームをトランスコードし、ビデオ出力ストリーム１００８でそれを順番に送出する。この場合、アルゴリズム・プロセス１００４は、ストリームのリアルタイム面を維持するために、１つおきのビデオ・フレームを除外する。したがって、音声ストリームは、明瞭で完全であり、ビデオ・ストリームは、そのフレーム・レートが半分に減少されている。
【００４３】
図１１は、マルチメディア・ストリームの成分をリアルタイムおよび非リアルタイムのアルゴリズム・プロセスに割り当てる方法の一実施形態のフローチャートである。この方法は、ハードウェア（回路、専用論理など）、ソフトウェア（たとえば汎用コンピュータ・システムまたは専用機械上で実行される）、あるいは両方の組合せを含み得る処理論理によって実施される。図１１を参照すると、この方法は、処理論理が、マルチメディア・ストリームを含む１またはそれ以上の成分がリアルタイム処理を必要とするかどうかを判断することから開始する（ブロック１１００）。処理論理が、リアルタイム処理が必要であると決定する場合（ブロック１１０２）、処理論理はリアルタイム処理を必要とする１またはそれ以上の成分を１またはそれ以上のリアルタイムのアルゴリズム・プロセスに割り当てる（ブロック１１０４）。最後に、処理論理は、残余のあらゆる成分を、１またはそれ以上の非リアルタイム・アルゴリズム・プロセスに割り当て（ブロック１１０６）、この方法は終了される。
【００４４】
図１２は、マルチメディア・ストリームの成分をリアルタイム・プロセスに割り当てる方法の別の実施形態のフローチャートである。この方法は、ハードウェア（回路、専用論理など）、ソフトウェア（たとえば汎用コンピュータ・システムまたは専用機械上で実行される）、あるいは両方の組合せを含み得る処理論理によって実施される。図１２を参照すると、この方法は、処理論理がパケットをその１またはそれ以上の成分にラップ解除することから開始する（ブロック１２００）。次いで、処理論理は、各パケット内のリアルタイム処理を必要とする１またはそれ以上の成分のそれぞれをリアルタイムで処理するのに必要な処理量を決定する（ブロック１２０２）。最後に、処理論理は、各パケット内のリアルタイム処理を必要とする１またはそれ以上の成分のそれぞれを別個のリアルタイム・プロセスに割り当て（ブロック１２０４）、この方法は終了される。
【００４５】
図１３は、トランスコーディング・プロセスからマルチメディア・ストリームの成分を除外する方法の一実施形態のフローチャートである。この方法は、ハードウェア（回路、専用論理など）、ソフトウェア（たとえば汎用コンピュータ・システムまたは専用機械上で実行される）、あるいは両方の組合せを含み得る処理論理によって実施される。図１３を参照すると、この方法は、処理論理がパケットをその１またはそれ以上の成分にラップ解除することから開始する（ブロック１３００）。次いで、処理論理は、ラップ解除されたパケットのすべての成分がリアルタイムでトランスコードされ得るかどうかを判断する（ブロック１３０２）。そうすることができる場合、この方法は終了される。そうでない場合、処理論理は、第１の成分について検査する（ブロック１３０４）。成分が検査されると、処理論理は、成分が除外され得るかどうかを判断する（ブロック１３０６）。
【００４６】
成分が除外され得るかどうかの判断は、成分の処理優先度、および除外された連続した成分フレームの数など、複数の要素に基づいて行われ得る。たとえば、図１０で論じたように、アルゴリズム・プロセスがすべてをリアルタイムで処理する処理能力を有するとは限らない場合、どの成分を除外し、またそれをいつ除外するかについての決定が行われなければならない。１つおきにフレームを除外することによってビデオ成分をその標準のフレーム・レートの半分に除去することは、１５フレームを連続して除去し、次いで１５フレームを連続してトランスコードすることより異論が少ない。最終結果は、同じ数のフレームであるが、視聴経験の質は、それらの２つの別個のオプションについて異なる。
【００４７】
図１３を参照すると、成分が除外され得る場合、処理論理は、成分を除外する（ブロック１３０８）。次いで、処理論理は、すべての成分が検査されたかどうかを判断する（ブロック１３１０）。そうである場合、この方法は終了される。そうでない場合、処理論理は、次の成分を検査する（ブロック１３１２）。最終的には、ラップ解除されたパケットのすべての成分が検査され、この方法は終了する。別の実施形態では、ストリームから１またはそれ以上の成分を除外するかどうかを判断することは、単にトランスコードすること以外のマルチメディア・ストリーム・プロセスに関する決定を含み得る。したがって、トランスコーディングは、一例として使用されており、マルチメディア・ストリームに対して実施され得る１またはそれ以上の他の機能と置き換えられ得る。
【００４８】
図１４は、ストリームのトランスコーディングをスキップする方法の一実施形態のフローチャートである。この方法は、ハードウェア（回路、専用論理など）、ソフトウェア（たとえば汎用コンピュータ・システムまたは専用機械上で実行される）、あるいは両方の組合せを含み得る処理論理によって実施される。図１４を参照すると、この方法は、処理論理は、ソース装置から送信されたストリームの形式を決定することから開始する（ブロック１５００）。次いで、処理論理は、宛先装置が必要とするストリームの形式を決定する（ブロック１５０２）。次いで、処理論理は、２つの形式が同じかどうかを判断する（ブロック１５０４）。形式が同じでない場合、処理論理は、ストリームをトランスコードし（ブロック１５０６）、プロセスは終了される。そうではなく、形式が同じである場合、処理論理は、ストリームをトランスコードせず、その代わりにストリームをソースから宛先に直接に送信し（ブロック１５０８）、この方法は終了される。
【００４９】
図１５は、リアルタイム処理は必要としないが、決定された最大時間遅延の前の処理を必要とするマルチメディア・ストリームの成分を、決定された最大時間遅延内に処理することができるプロセスに割り当てる方法の一実施形態のフローチャートである。この方法は、ハードウェア（回路、専用論理など）、ソフトウェア（たとえば汎用コンピュータ・システムまたは専用機械上で実行される）、あるいは両方の組合せを含み得る処理論理によって実施される。図１５を参照すると、この方法は、処理論理が、リアルタイム処理を必要としないパケット内の成分のそれぞれに許容可能な最大遅延を決定することから開始する（ブロック１５００）。異なる実施形態では、許容可能な最大処理遅延の決定は、マルチメディア・ストリームが使用されているトランザクションのタイプ、伝送媒体の速度（たとえば電子メール内に添付された音声メールの必要な処理速度が電子メールの固有の遅延に制限される）を含めた複数の要因、ならびに他の複数の要因に基づいて行われ得る。次いで、処理論理は、リアルタイム処理を必要としない成分のそれぞれを別個のプロセスに割り当て、各プロセスが、それぞれの各成分を許容可能な遅延時間内に処理するのに必要な処理量を少なくとも提供し（ブロック１５０２）、この方法は終了される。
【００５０】
上記の例示的な実施形態の多くにおいて、パケットは、主にビデオおよび音声成分を扱うものであった。他の実施形態では、パケットは、ビデオ、オーディオ、音声、データ、制御、または他の考えられる任意のパケット・タイプのうちのいずれか１または複数を含む。さらに、例示的な諸実施形態は、２つの成分だけを含むパケットを参照していた。他の実施形態では、パケットは、考えられる任意の数の成分（すなわち１つ以上の成分）を含み得る。最後に、多くの例示的な実施形態では、単一のアルゴリズム・プロセスが、単一のタイプのすべての成分を処理する役割を担っていた。他の実施形態では、２つ以上のアルゴリズム・プロセスは、単一のタイプの成分に割り当てられ得る。したがって、多くの実施形態において、２つ以上のアルゴリズム・プロセスは、処理の役割を交換し、したがって、それぞれのアルゴリズム・プロセスは、単一のタイプの他のあらゆるパケット化成分を１つおきに（または２つおき、３つおきになど）処理することができる。
【００５１】
したがって、マルチメディア・ストリームを処理するための有効な方法についての実施形態が開示される。これらの実施形態について、その具体的な例示的実施形態を参照して述べた。しかし、この開示の利点を得る者には、本明細書で述べた諸実施形態のより広い精神および範囲から逸脱せずに、これらの実施形態に様々な修正および変更が行われ得ることが明らかである。したがって、本明細書および図面は、限定的ではなく、例示的な意味で考えられるべきである。
【図面の簡単な説明】
【００５２】
【図１Ａ】マルチメディア・ストリームの単方向トランスコーディングを必要とし得るトランザクションの一例を示す図である。
【図１Ｂ】マルチメディア・ストリームの双方向トランスコーディングを必要とし得る双方向ビデオ通話の一例を示す図である。
【図１Ｃ】多方向トランスコーディングを必要とし得る三者テレビ会議の一例を示す図である。
【図２】マルチメディア・ストリーム処理管理システム（ＭＳＰＭＳ）を備えたコンピュータ・システムの一実施形態のブロック図である。
【図３】マルチメディア・ストリーム処理管理システム（ＭＳＰＭＳ）の一実施形態を示す図である。
【図４】マルチメディア・ストリーム・パケットを単一のアルゴリズム・プロセスを用いてトランスコードする方法の一実施形態を示す図である。
【図５】マルチメディア・ストリーム・パケットを複数のアルゴリズム・プロセスを用いてトランスコードする方法の一実施形態を示す図である。
【図６】マルチメディア・ストリーム・パケットを複数のアルゴリズム・プロセスを用いてトランスコードする方法の別の実施形態を示す図である。
【図７】マルチメディア・ストリーム・パケットを１つのアルゴリズム・プロセスおよび１つのバッファを用いてトランスコードする方法の一実施形態を示す図である。
【図８】マルチメディア・ストリーム・パケットを１つのアルゴリズム・プロセスおよび複数のバッファを用いてトランスコードする方法の一実施形態を示す図である。
【図９】マルチメディア・ストリーム・パケットを複数のアルゴリズム・プロセスおよび複数のバッファを用いてトランスコードする方法の一実施形態を示す図である。
【図１０】成分優先度および処理能力制限に基づいて個別の成分を除外するアルゴリズム・プロセスの一実施形態を示す図である。
【図１１】マルチメディア・ストリームの成分をリアルタイムおよび非リアルタイムのアルゴリズム・プロセスに割り当てる方法の一実施形態のフローチャートである。
【図１２】マルチメディア・ストリームの成分をリアルタイムのプロセスに割り当てる方法の別の実施形態のフローチャートである。
【図１３】トランスコーディング・プロセスからマルチメディア・ストリームの成分を除外する方法の一実施形態のフローチャートである。
【図１４】ストリームのトランスコーディングをスキップする方法の一実施形態のフローチャートである。
【図１５】リアルタイム処理は必要としないが、決定された最大時間遅延の前の処理を必要とするマルチメディア・ストリームの成分を、決定された最大時間遅延内に処理することができるプロセスに割り当てる方法の一実施形態のフローチャートである。
【図１Ａ】
2008527472.tif 000003
【図１Ｂ】
2008527472.tif 000004
【図１Ｃ】
2008527472.tif 000005
【図２】
2008527472.tif 000006
【図３】
2008527472.tif 000007
【図４】
2008527472.tif 000008
【図５】
2008527472.tif 000009
【図６】
2008527472.tif 000010
【図７】
2008527472.tif 000011
【図８】
2008527472.tif 000012
【図９】
2008527472.tif 000013
【図１０】
2008527472.tif 000014
【図１１】
2008527472.tif 000015
【図１２】
2008527472.tif 000016
【図１３】
2008527472.tif 000017
【図１４】
2008527472.tif 000018
【図１５】
2008527472.tif 000019
【国際調査報告】
2008527472.tif 000020
2008527472.tif 000021
2008527472.tif 000022
2008527472.tif 000023
2008527472.tif 000024