データストリーム転送用のパケットで利用可能な空間を計算する方法であって、データストリームマネージャの各モジュールの要件であって、前記モジュールによって使用されるプロトコル及びサービスの少なくとも一方によって要求される少なくとも2つのタイプの、ヘッダデータ及び拡張のデータの少なくとも一方のデータに対する前記パケットにおける空間に対する、前記各モジュールの要件を判定するステップと、異なるタイプのデータに対する空間要件を組み合わせるための異なるルールと、前記異なるタイプのデータに対する空間要件群の組み合わせの総和を使用することによって、前記各モジュールの要件のすべてに合致する前記パケットにおける最大空間要件を判定するステップと、データストリーム転送に対して前記利用可能な空間を判定するために、前記パケットの空間と、前記パケットにおける前記最大空間要件との差分を計算するステップとを備えることを特徴とする方法。イベントを検出するステップであって、前記データストリームを送信するためのネットワークにおける前記データストリームの受信クライアントへの到着、前記ネットワークからの前記データストリームの受信クライアントからの発信、前記データストリームマネージャの少なくとも1つのモジュールのアクティベーション、前記データストリームマネージャの少なくとも1つのモジュールのデアクティベーションのうちからのイベントを検出するステップと、前記イベントに関与するデータストリームマネージャであって、前記要件群を判定するステップと前記計算するステップとを実行するデータストリームマネージャを判定するステップとを更に備えることを特徴とする請求項1に記載の方法。前記少なくとも2つのタイプのデータに対する前記パケットにおける空間に対する、前記各モジュールの要件を判定するステップにおいて、前記タイプには、少なくとも1つの永続性拡張タイプと、少なくとも1つのデータストリーム従属拡張タイプを含んでいることを特徴とする請求項1に記載の方法。前記少なくとも2つのタイプのデータに対する前記パケットにおける空間に対する、前記各モジュールの要件を判定するステップにおいて、前記タイプには、少なくとも以下のタイプ群の1つと、永続性RTPヘッダ拡張PHE、永続性ペイロードデータ拡張、少なくとも以下のタイプ群の1つと、データストリーム従属RTPヘッダ拡張SDHE、データストリーム従属ペイロードデータ拡張SDPEを含んでいることを特徴とする請求項1に記載の方法。前記各モジュールの要件のすべてに合致する前記パケットにおける最大空間要件を判定するステップにおいて、永続性拡張タイプの空間要件群の組み合わせに対して、要件追加動作が実行され、データストリーム従属タイプの空間要件群の組み合わせに対して、最大要件値抽出動作が実行されることを特徴とする請求項3または4に記載の方法。前記各モジュールの要件を判定するステップにおいて、前記モジュールが前記データストリームのサブストリームのソースである場合、前記パケットの前記空間要件は、前記サブストリームの少なくとも2つのタイプのデータに対して判定されることを特徴とする請求項1に記載の方法。前記各モジュールの要件のすべてに合致する前記パケットにおける最大空間要件を判定するステップにおいて、前記データストリームの前記サブストリームのすべてに対して、各タイプのデータに対する前記サブストリームに対する要件群の最大値を抽出する動作が実行されることを特徴とする請求項6に記載の方法。前記各モジュールの要件Rに合致する前記パケットにおける最大空間要件を判定するステップにおいて、前記データストリームマネージャSと、前記データストリームマネージャによって承継されるサブストリーム群Sjを構成するモジュール群Miのセットに対して以下の方程式群が実行されるものであって、前記永続性ヘッダ拡張群PHEに対して、が実行され、前記データストリーム従属ヘッダ拡張群SDHEに対して、が実行され、前記永続性ペイロードデータ拡張群PPEに対して、が実行され、前記データストリーム従属ペイロードデータ拡張群SDPEに対して、が実行され、そして、総合要件RESを、以下の方程式で計算し、ここで、Eは、拡張情報のタイプ、つまり、PHE、SDHE、PPE、あるいはSDPEのタイプの1つを示していて、OEは、以下のものを伴う、タイプEに依存する演算式であるOSDHEとOSDPEは、演算式maxに対応し、これは、値のペアの最大値を抽出する演算OPHEとOPPEは、演算式に対応し、これは、値のペアの値を追加する演算を伴うことを特徴とする請求項6または7に記載の方法。前記差分を計算するステップの結果を示すことによって、考慮される前記データストリームのソースにリンクされているバッファメモリファクトリーでパケット空間を予約するステップと、前記バッファメモリファクトリーによって、予約空間に対するリクエスト群の最大値を計算して、前記データストリームからの新規のデータを新規のバッファメモリに配置するためのリクエストに応じて、前記バッファメモリの開始における予約空間に対するリクエスト群の最大値の関数として、前記データストリームからのデータを配置することができる位置からスタートするポインタを用いて、バッファメモリを与えるステップとを更に備えることを特徴とする請求項1に記載の方法。前記データストリームのデータの各項目に対して、前記ポインタの後に、前記バッファメモリに前記項目のデータを書き込むステップと、前記項目のデータの受信先への各送信に対して、前記送信に関連付けられている前記データストリームマネージャの各モジュールに対してヘッダデータ及び拡張データの少なくとも一方のデータを書き込むステップとを備えることを特徴とする請求項9に記載の方法。RTPリアルタイム転送プロトコルに従う前記データストリームからのデータを送信するステップを更に備えることを特徴とする請求項1、9及び10のいずれか1項に記載の方法。前記2つのタイプの一方に従って、ヘッダデータ及び拡張データの少なくとも一方と、前記データストリームからのデータを含む第1のパケットを送信するステップを更に備えることを特徴とする請求項1に記載の方法。前記2つのタイプの他方に従って、ヘッダデータ及び拡張データの少なくとも一方と、前記データストリームからのデータを含む第2のパケットを送信するステップを更に備えることを特徴とする請求項12に記載の方法。データストリーム転送用のパケットで利用可能な空間を計算するデバイスであって、データストリームマネージャの各モジュールの要件であって、前記モジュールによって使用されるプロトコル及びサービスの少なくとも一方によって要求される少なくとも2つのタイプの、ヘッダデータ及び拡張のデータの少なくとも一方のデータに対する前記パケットにおける空間に対する、前記各モジュールの要件を判定する手段と、異なるタイプのデータに対する空間要件を組み合わせるための異なるルールと、前記異なるタイプのデータに対する空間要件群の組み合わせの総和を使用することによって、前記各モジュールの要件のすべてに合致する前記パケットにおける最大空間要件を判定する手段と、データストリーム転送に対して前記利用可能な空間を判定するために、前記パケットの空間と、前記パケットにおける前記最大空間要件との差分を計算する手段とを備えることを特徴とするデバイス。コンピュータシステムにロードされるコンピュータプログラムであって、当該コンピュータプログラムは、請求項1に記載の方法の実行を可能にする命令群を含んでいることを特徴とするコンピュータプログラム。コンピュータあるいはマイクロプロセッサ可読情報用のリムーバルあるいは非リムーバル搬送媒体であって、請求項1に記載の方法をコンピュータプログラムに実行可能にさせることを可能にする命令群を記憶することを特徴とするリムーバルあるいは非リムーバル搬送媒体。本発明は、これらの欠点を解消することを目的とする。結局のところ、第1の態様に従えば、本発明は、データストリーム転送用のパケットに利用可能な空間を計算する方法に関するものである。この方法は、データストリーム転送用のパケットで利用可能な空間を計算する方法であって、データストリームマネージャの各モジュールの要件であって、前記モジュールによって使用されるプロトコル及びサービスの少なくとも一方によって要求される少なくとも2つのタイプの、ヘッダデータ及び拡張のデータの少なくとも一方のデータに対する前記パケットにおける空間に対する、前記各モジュールの要件を判定するステップと、異なるタイプのデータに対する空間要件を組み合わせるための異なるルールと、前記異なるタイプのデータに対する空間要件群の組み合わせの総和を使用することによって、前記各モジュールの要件のすべてに合致する前記パケットにおける最大空間要件を判定するステップと、データストリーム転送に対して前記利用可能な空間を判定するために、前記パケットの空間と、前記パケットにおける前記最大空間要件との差分を計算するステップとを備える。本発明は、ネットワークパケットの生成において、ペイロードデータに追加される、様々なタイプの追加情報を管理することを可能にする。これには、例えば、永続性タイプあるいはストリーム従属タイプのペイロードヘッダ群、永続性タイプあるいは純粋なデータ従属タイプの基本的なRTPヘッダ拡張群、及び固定サイズのヘッダ群例えば、基本的なRTPヘッダ群がある。本発明の実行によって、データストリームからのデータ、例えば、ペイロードデータは、決してデュプリケート/コピーされることはない。これは、たとえそれらのペイロードデータがいくかの受信先マルチ-ユニキャストの場合に送信される場合でも、あるいはたとえそれらのペイロードデータが同一のクライアントへ複数回送信されるものである場合でも、決してデュプリケート/コピーされることはない。つまり、システムは、より少ないメモリリソースとより少なくプロセッサリソースを消費する。特定の特徴に従えば、本発明の方法は、イベントを検出するステップであって、前記データストリームを送信するためのネットワークにおける前記データストリームの受信クライアントへの到着、前記ネットワークからの前記データストリームの受信クライアントからの発信、前記データストリームマネージャの少なくとも1つのモジュールのアクティベーション、前記データストリームマネージャの少なくとも1つのモジュールのデアクティベーションのうちからのイベントを検出するステップと、前記イベントに関与するデータストリームマネージャであって、前記要件群を判定するステップと前記計算するステップとを実行するデータストリームマネージャを判定するステップとを更に備える。つまり、ネットワークパケットにおけるデータストリームのデータに対して利用可能なサイズは常に最適となる。これは、クライアントがシステムへ接続する毎に、あるいはシステムから切断する毎に、また、クライアント群の1つによるサービスのアクティベーションあるいはデアクティベーション毎に、再評価される。特定の特徴に従えば、前記少なくとも2つのタイプのデータに対する前記パケットにおける空間に対する、前記各モジュールの要件を判定するステップにおいて、前記タイプには、少なくとも1つの永続性拡張タイプと、少なくとも1つのデータストリーム従属拡張タイプを含んでいる。特定の特徴に従えば、前記少なくとも2つのタイプのデータに対する前記パケットにおける空間に対する、前記各モジュールの要件を判定するステップにおいて、前記タイプには、少なくとも以下のタイプ群の1つと、永続性RTPヘッダ拡張PHE、永続性ペイロードデータ拡張、少なくとも以下のタイプ群の1つと、データストリーム従属RTPヘッダ拡張SDHE、データストリーム従属ペイロードデータ拡張SDPEを含んでいる。特定の特徴に従えば、前記各モジュールの要件のすべてに合致する前記パケットにおける最大空間要件を判定するステップにおいて、永続性拡張タイプの空間要件群の組み合わせに対して、要件追加動作が実行され、データストリーム従属タイプの空間要件群の組み合わせに対して、最大要件値抽出動作が実行される。特定の特徴に従えば、前記各モジュールの要件を判定するステップにおいて、前記モジュールが前記データストリームのサブストリームのソースである場合、前記パケットの前記空間要件は、前記サブストリームの少なくとも2つのタイプのデータに対して判定される。特定の特徴に従えば、前記各モジュールの要件のすべてに合致する前記パケットにおける最大空間要件を判定するステップにおいて、前記データストリームの前記サブストリームのすべてに対して、各タイプのデータに対する前記サブストリームに対する要件群の最大値を抽出する動作が実行される。特定の特徴に従えば、前記各モジュールの要件Rに合致する前記パケットにおける最大空間要件を判定するステップにおいて、前記データストリームマネージャSと、前記データストリームマネージャによって承継されるサブストリーム群Sjを構成するモジュール群Miのセットに対して以下の方程式群が実行されるものであって、前記永続性ヘッダ拡張群PHEに対して、が実行され、前記データストリーム従属ヘッダ拡張群SDHEに対して、が実行され、前記永続性ペイロードデータ拡張群PPEに対して、が実行され、前記データストリーム従属ペイロードデータ拡張群SDPEに対して、が実行され、そして、総合要件RESを、以下の方程式で計算し、ここで、Eは、拡張情報のタイプ、つまり、PHE、SDHE、PPE、あるいはSDPEのタイプの1つを示していて、OEは、以下のものを伴う、タイプEに依存する演算式であるOSDHEとOSDPEは、演算式maxに対応し、これは、値のペアの最大値を抽出する演算OPHEとOPPEは、演算式に対応し、これは、値のペアの値を追加する演算を伴う。特定の特徴に従えば、本発明の方法は、前記差分を計算するステップの結果を示すことによって、考慮される前記データストリームのソースにリンクされているバッファメモリファクトリーでパケット空間を予約するステップと、前記バッファメモリファクトリーによって、予約空間に対するリクエスト群の最大値を計算して、前記データストリームからの新規のデータを新規のバッファメモリに配置するためのリクエストに応じて、前記バッファメモリの開始における予約空間に対するリクエスト群の最大値の関数として、前記データストリームからのデータを配置することができる位置からスタートするポインタを用いて、バッファメモリを与えるステップとを更に備える。特定の特徴に従えば、本発明の方法は、前記データストリームのデータの各項目に対して、前記ポインタの後に、前記バッファメモリに前記項目のデータを書き込むステップと、前記項目のデータの受信先への各送信に対して、前記送信に関連付けられている前記データストリームマネージャの各モジュールに対してヘッダデータ及び拡張データの少なくとも一方のデータを書き込むステップとを備える。つまり、異なる受信先へ送信されるべきペイロードデータは、再送信リクエストに応答する時点ではあるいは誤り訂正データを追加する時点で、コピーされない、あるいは移動されない。この方法は、つまり、前記2つのタイプの一方に従って、ヘッダデータ及び拡張データの少なくとも一方と、前記データストリームからのデータを含む第1のパケットを送信するステップを更に備え、また、場合によっては、前記2つのタイプの他方に従って、ヘッダデータ及び拡張データの少なくとも一方と、前記データストリームからのデータを含む第2のパケットを送信するステップを更に備える。特定の特徴に従えば、本発明の方法は、RTPリアルタイム転送プロトコルに従う前記データストリームからのデータを送信するステップを更に備える。第2の態様に従えば、本発明は、データストリーム転送用のパケットで利用可能な空間を計算するデバイスに関するものである。このデバイスは、データストリームマネージャの各モジュールの要件であって、前記モジュールによって使用されるプロトコル及びサービスの少なくとも一方によって要求される少なくとも2つのタイプの、ヘッダデータ及び拡張のデータの少なくとも一方のデータに対する前記パケットにおける空間に対する、前記各モジュールの要件を判定する手段と、異なるタイプのデータに対する空間要件を組み合わせるための異なるルールと、前記異なるタイプのデータに対する空間要件群の組み合わせの総和を使用することによって、前記各モジュールの要件のすべてに合致する前記パケットにおける最大空間要件を判定する手段と、データストリーム転送に対して前記利用可能な空間を判定するために、前記パケットの空間と、前記パケットにおける前記最大空間要件との差分を計算する手段とを備える。第3の態様に従えば、本発明は、コンピュータシステムにロードされるコンピュータプログラムに関するものであり、このコンピュータプログラムは、上述のような、本発明の方法の実行を可能にする命令群を含んでいる。第4の態様に従えば、本発明は、コンピュータあるいはマイクロプロセッサによって読取可能な情報搬送媒体に関するものであり、これは、リムーバルであろうとなかろうと、上述の本発明の方法の実行をコンピュータプログラムに可能にさせる命令群を記憶する。このデバイス、このプログラム、及びこの情報搬送媒体それぞれの、利点、目的及び特徴は、本発明の方法の目的及び特徴と同様であるので、ここでは、再度説明しない。明細書の全体において、以下の定義を使用する。バッファメモリ:用語バッファによって共通に示されるバッファメモリは、特に、同一のレートで動作しない機器の項目群の2つの処理の間において、一時的にデータを記憶するために使用されるランダムアクセスメモリあるいはディスクの領域である。パケット化:転送するためのビットストリームをパケットにグルーピングする動作。一定数の情報の項目群が、例えば、どのパケットに属し、かつどこにアドレス指定されているかを示すために、ヘッダの形態で追加される。RFCrequestsforcommentコメントのリクエストの頭字語:文字どおり、これは、コメントのリクエストであり、より一般的には、インターネットの技術的知識を文書化している通し番号の電子文書である。いくつかのRFCは規格になっていて、逆に、すべてのインターネット規格はRFCからなる。概要としては、各イベント時クライアントからの発信時/クライアントへの到着時、あるいはクライアントによるサービスのアクティベーション時/デアクティベーション時、イベントに関係するデータストリームマネージャのそれぞれは最大空間を判定する。この最大空間は、使用されるプロトコル群及びサービス群によって要求されるヘッダ群と拡張群を配置するためのネットワークパケットを要求するものである。このことについて、データストリームマネージャを構築するモジュールのそれぞれは問い合わせられ、そして、自身をいくつかのタイプに区別する、自身のメモリ空間要件を通知する。ペイロードデータのパケット化において、各モジュールは、以下のタイプに対応する拡張情報を追加することができる。-永続的なRTPヘッダ拡張PHE-データストリームに従属するRTPヘッダ拡張SDHE-永続的なペイロードデータ拡張PPE-データストリーム従属ペイロードデータ拡張SDPEモジュール自身がサブストリームの基点である場合、そのモジュールは、再帰的に、そのサブストリームにリンクされているメモリ空間に対する要件群を判定する。データストリームマネージャを構築するモジュール群のそれぞれによって表現される様々なタイプのメモリ要件は組み合わせされ、そして、最大予約メモリ空間が全体としてデータストリームマネージャに対して判定される。この組み合わせによる特定の動作群は、ここでは、組み合わせる情報のタイプに依存する。次に、データストリームマネージャは、自身の予約空間要件を、ペイロードデータのソースにリンクされているバッファファクトリーを用いて記録する。このバッファファクトリーは、データストリームマネージャ群のそれぞれのメモリ空間予約リクエスト群のリストを保持する。このデータストリームマネージャ群はそのリストにリンクされていて、そのメモリ空間予約リクエスト群の最大値を計算する。エンコーダあるいはパケッタイザが、新規のペイロードデータをバッファメモリに配置するために、バッファファクトリーから新規のバッファメモリをリクエストする場合、バッファファクトリーは、エンコーダあるいはパケッタイザに、ペイロードデータソースにリンクされているデータストリームマネージャのすべてに対してバッファメモリの開始で予約される空間の最大値を考慮して配置することができるペイロードデータからスタートする位置のポインタを用いて、バッファメモリを与える。図1に示されるように、本発明を使用する場合、送信機デバイスあるいはサーバ10はペイロードデータ14のパケット16を、同一のマルチメディアデータストリーム14から、データ通信ネットワーク15を介して、いくつかの受信機デバイスあるいはクライアント11、12及び13へ送信する。例えば、サーバ10は、カメラによってキャプチャされるマルチメディアストリームビデオ及びオーディオの少なくとも一方を再送信することができる。通信ネットワーク15は、例えば、無線ネットワーク例えば、WiFi/802.11a/b/g/n、あるいはローカルイーサネットネットワーク、あるいは、インターネットのような長距離ネットワークである。ペイロードデータ14は、RTPリアルタイム転送プロトコルのようなデータのリアルタイム送信に適合されているプロトコル群を使用して送信される。このプロトコルは、典型的には、UDP/IPプロトコルを介して実現される。また、受信機デバイスは、例えば、RTCP制御プロトコルを使用して、送信機デバイスへフィードバック情報を提供することができる。このRTCP制御プロトコルは、場合によっては、AVPFプロファイルAVPFは、フィードバック付きオーディオ-ビジュアルプロファイルAudioVisualProfilewithFeedbacksの頭字語であり、RFC4585リアルタイム転送制御プロトコルRTCPベースのフィードバックRTP/AVPF用拡張RTPプロファイル、IETF、RFC4585、2006年7月に記載されているを使用して拡張される。各ネットワークパケット16は、ペイロードデータ14とプロトコルヘッダ群を含んでいて、また、場合によっては、これらのプロトコルヘッダ群の拡張群及びペイロードデータに対する拡張群の少なくとも一方を含んでいる。このペイロードデータに対する拡張群は、サーバ-クライアントのペアそれぞれによって実現されるサービス群に依存する。例えば、クライアント13は、RFC4588RTP再送信ペイロードフォーマット、IETF、RFC4588、2006年7月に記載される再送信サービスRTXを使用する。ネットワークパケットが損失すると、ペイロードデータは、クライアントのリクエストで再送信することができる。この場合、RFCに従えば、ペイロードデータを含むパケットは、また、通常のヘッダに加えて、対応する損失したパケットのシーケンス番号を含む2バイトのペイロードデータに対する小拡張を備えている。別の例では、クライアント12は、RFC5109汎用前方誤り訂正用RTPペイロードフォーマット、IETF、RFC5109、2007年12月に記載される誤り訂正サービス群あるいは前方誤り訂正によるFECを使用するとともに、TFRCTCPフレンドリーレート制御TFRC:TCPFriendlyRateControl:プロトコル仕様、IETF、RFC5348、2008年7月のような輻輳制御CCサービスを使用する。再送信サービスに対しては、誤り訂正サービスFECは、パケット群に対して更なる冗長情報の追加を要求し、また、輻輳制御サービスは、RTPヘッダ群の追加の拡張を要求すること場合がある。つまり、クライアント群のそれぞれに送信されるペイロードデータの同一の項目に対しては、ネットワークパケット16は、ヘッダ群と、可変サイズの拡張群を含む場合がある。以下の状況は、ストリーミングしながら符号化されるビデオストリームを送信する場合が考慮されるが、事前に符号化されるビデオストリームあるいはオーディオストリームを送信する場合も、完全に同様の方法で当業者によって取り扱うことができる事前符号化データの場合では、図2を参照して説明されるエンコーダ211は、事前符号化データに読み換えることができる。図2では、ブロック図は、マルチメディアストリームサーバ10を記載している。一般的には、送信対象のロー生データ画像フレーム群20は、ソースブロック21によって処理される。ソースブロック21は、一連のバッファメモリ214に配置されることになるペイロードデータを取得するために、ローデータを処理するタスクを有している。バッファメモリ214のそれぞれは、異なるIPアドレス/ポート番号の組み合わせによって識別されるネットワーク受信先に対応するデータストリームマネージャ23、24、25及び27それぞれ、クライアント11、クライアント12及びクライアント13で示されているを介して連続的に処理される。これは、ユニキャストIPアドレス、及びマルチキャストIPアドレスの少なくとも一方の場合であり得る。各データストリームマネージャは、追加情報をヘッダ群に追加することによって、場合によっては、通信ネットワーク15によって、自身の受信先に送信されるパケットに対してペイロードデータ拡張情報を順番に追加することによって、バッファメモリ214からのペイロードデータを有効なRTPパケットに変換するタスクを有している。データストリームマネージャによって演算することが可能となる前に、バッファメモリ214の内容は、特定のデータストリームマネージャに対するバッファメモリ214の内容を記述するタスクが与えられる、仮想RTPパケット例えば、22、22’、22、あるいは28を記述するオブジェクトとメモリ内で関連づけられる。仮想RTPパケット22、22’、22、及び28は、特に、ペイロードデータの位置を指定し、かつ、バッファメモリ214に存在するペイロードデータに対する一定のヘッダ群及び拡張群の位置を指定する、バッファメモリ214へのポインタ群を含んでいる。各データストリームマネージャは、1つ以上の処理モジュール群例えば、231、241、242、243、251、252及び271によって構成される。各処理モジュールあるいはハンドラに対して、追加のデータヘッダ群を追加することによってバッファメモリ214の内容に補完的な追加を行うことができる、あるいは、後の使用のために、仮想RTPパケット22、22’、22、あるいは28へのリファレンスかつ、関連するバッファメモリ214への拡張によるを保持することができる。処理モジュールには、特定の処理モジュール、RTPモジュール231、242、251及び271が存在する。この特定の処理モジュールは、バッファメモリ214の内容にRTPプロトコルヘッダを追加することによってRTPパケットをファイナライズし、かつ通信ネットワーク15を介して、自身の受信先に、メモリに形成されているそのRTPパケットを送信するタスクが与えられる。より詳細には、ソースブロック21は、エンコーダ211、符号化フォーマットに適合されているパケッタイザ212、及びバッファメモリファクトリー213によって構築されている。データ20は、例えば、ビデオカメラのようなキャプチャ周辺機器から得られる画像フレーム群で構成される。これらのデータは、キャプチャ周辺機器のサンプリング周波数に対応する周波数で供給される。これらの画像フレーム群はエンコーダ211によってビデオ圧縮フォーマット、例えば、MPEG4あるいはH.264/AVCに符号化される。パケッタイザ212は、ペイロードデータの一部を形成するために符号化されているデータを分割すること、及び再構成することの少なくとも一方を実行する。このペイロードデータは、ネットワークパケット群で送信されるように構成されている。符号化データのパケット化は、MPEG4フォーマットに対する、MPEG-4オーディオ/ビジュアルストリーム群用RTPペイロードフォーマット、IETF、2000年11月に記載される、あるいはH.264フォーマットに対する、H.264ビデオ用のRTPペイロードフォーマット、IETF、RFC3984、2005年2月に記載されるように実行することができる。エンコーダ211及びパケッタイザ212の少なくとも一方は、ネットワークパケット内のペイロードデータに対して利用可能な最大サイズを把握するために、バッファメモリファクトリー213に問い合わせる。そのリプライでは、エンコーダ211及びパケッタイザ212は、ペイロードデータのサイズを取得するように符号化及びパケット化の少なくとも一方を適合する。このペイロードデータのサイズは、取り得る最大サイズに最も近いものである。例えば、符号化は、画像部分群スライス群あるいは量子化ステップサイズを変更することによって構成されてもよい。パケット化は、パケット化モードが許容する場合には、画像部分群をフラグメントすることによって、あるいは組み合わせることによって構成されてもよい。エンコーダ/パケッタイザのペアによって生成されるペイロードデータは、バッファメモリ214に配置される。このバッファメモリ214は、エンコーダ211のリクエスト、あるいはパケッタイザ212のリクエストで、バッファメモリファクトリー213によって前もって割り当てられる。バッファメモリファクトリー213は、ソース21にリンクしているデータストリームマネージャ群例えば、23、24及び25のそれぞれに対するメモリ空間の予約に対するリクエストのすべてを継続的に保持する。バッファメモリファクトリー213は、ネットワークパケット群の開始で予約されなければならない最大メモリ空間を判定する。この情報を用いて、ペイロードデータは、バッファメモリ214内の正しい位置に直接配置される。バッファメモリ開始地点214図2の破線での空き空間は、各処理モジュールに、メモリ内のペイロードデータをコピーあるいは移動することなく、ヘッダ情報及び拡張情報を連続的に追加することを可能にする。ここで、ペイロードデータの同一の項目が、クライアント11、12及び13に送信されると仮定する。これに対して、バッファメモリ214は、データストリームマネージャ23、24及び25のそれぞれによって連続的に取り扱われる。データストリームマネージャ群のそれぞれに対して、異なる仮想RTPパケットオブジェクト22、22’及び22が作成される。これらのオブジェクトは、特に、自身の内容を指定することを可能にする、バッファメモリ214に対するいくつかのポインタを含んでいる。-バッファメモリの開始に対するポインタ-ペイロードデータの位置に対するポインタ-ヘッダ拡張群の位置に対するポインタ最初は、RTPパケット22、22’、22それぞれの少なくとも2つのポインタは等しく、また、ソース21によって配置されるように、バッファメモリ214内のペイロードデータの位置を指定する。各データストリームマネージャ23、24及び25は、少なくとも1つの処理モジュールから構成される。これらの処理モジュールは、バッファメモリ214と、関連する仮想RTPパケットオブジェクト22、22’あるいは22を処理するタスクが与えられる。各データストリームマネージャ23、24、25は、継続的に同一のバッファメモリ214を操作するこの操作は、データストリームマネージャのそれぞれによって再度書き込まれるペイロードデータの前の破線の領域に対して可能となる。つまり、ペイロードデータは、自身がいくつかのクライアントへ送信される場合に、メモリ内でコピーされない、あるいは移動されない。例えば、クライアント11に関連するデータストリームマネージャ23は、1つのRTP処理モジュール231だけを構成している。このRTP処理モジュールは、仮想RTPパケット22のポインタ群を使用して、バッファメモリ214内のペイロードデータの前に12バイトRTPヘッダを配置するタスクを行い、そして、それによってメモリ内に形成されたパケットを通信ネットワーク15を介して送信する。ネットワークを介して送信した後、仮想RTPパケット22は破棄することができる。次に、バッファメモリ214からの同一のペイロードデータは、データストリームマネージャ24を使用してクライアント12へ送信される。クライアント12に関連づけられているデータストリームマネージャ24は、例えば、3つのモジュールを構成する。それは、輻輳制御モジュール241、RTPモジュール242同様のモジュール231、及びデータ冗長性に基づく誤り訂正モジュール243あるいは前方誤り訂正によるFEC。この例では、輻輳制御モジュール241は、パケットに対する例えば、ラウンドトリップ時間あるいはRTTを計算することができるRTPヘッダ群への拡張群の形式で、バッファメモリ214に追加の情報を挿入することができる。この情報は、ペイロードデータの前に配置され、そして、結果として、仮想RTPパケット22のポインタが再配置される。仮想RTPパケット22’とバッファメモリ214は、次に、RTPモジュール242によって処理される。このRTPモジュール242は、バッファメモリ214内のRTPパケットをファイナライズし、かつそれを通信ネットワーク15を介して送信する。仮想RTPパケット22’とバッファメモリ214は、次に、FECモジュール243によって処理される。FECモジュール243は、新規の冗長パケットを計算することができるようになる前に、いくつかのRTPパケットを記憶しなければならない。つまり、FECモジュール243は、仮想RTPパケット22’へのリファレンスを保持する。ここで、仮想パケット22’によって指示される、バッファメモリ214のペイロードデータだけが、冗長パケットを計算するために利用することができることに注意されたい。モジュール241と242によってバッファメモリ214に配置されるヘッダ情報と拡張群は、他のデータストリームマネージャ群によって同一のペイロードデータの送信において上書きされることは免れない。必要がある場合、モジュール242によって最初に送信する時と同様に、モジュール243によって参照される仮想パケット22’は、ヘッダ群と拡張群とを再生成するために十分な情報を保持する。データストリームマネージャ24による処理後、バッファメモリ214は、最終的には、クライアント13へ送信される自身のコンテンツに対して、順番にデータストリームマネージャ25によって処理される。新規の仮想RTPパケット22が割り当てられる。この仮想RTPパケット22は、バッファメモリ214を参照する。クライアント13に関連付けられているデータストリームマネージャ25は、ここでは、2つのモジュールから構成される。これは:RTPモジュール251モジュール231及び242と同様と、再送信に基づく誤り訂正モジュール252RTXである。FECモジュール243に対しては、RTXモジュール252は、RTPパケット22へのリファレンスを保持する。特に、クライアントのリクエストでネットワークを介して再送信することができる所定の時間の間、RTPパケット22へのリファレンスを保持する。RTXモジュール252は、上述のデータストリームマネージャ内の処理モジュールと、また、再送信されるパケット群を送信するためのRTPパケット群の新規のソース26との両方として動作する。RTX処理モジュール252とRTXソース26は、2つの態様の同一のRTXモジュールである。サーバ10が、再送信用のリクエストをクライアント13から受信すると、この再送信用のリクエストは、RTXソース26へ送信される。RTXソース26は、RTPパケット22に対するRTXモジュール252とそれに関係するバッファメモリ214に記憶される、再送信用のリクエストに対応するパケットを検索する。パケットが検出される場合、再送信パケットを記述することになる新規の仮想RTPパケット28を割り当てる。新規の仮想RTPパケット28は、同一のバッファメモリ214をオリジナルの仮想RTPパケット22として参照する。つまり、ペイロードデータは、再送信リクエストに応答する時点では、コピーされない、あるいは移動されない。ヘッダ群と拡張群に対応する破線の部分だけが、再送信データストリームマネージャ27によるパケットの送信時に再度書き込まれる。RTXソース26に関連付けられているこのデータストリームマネージャ27は、他のデータストリームマネージャ23、24、25と同様の方法で動作する。ここでは、このデータストリームマネージャ27は、RTP処理モジュール271からなる。RTP処理モジュール271は、ペイロードデータの前にRTPヘッダ群を配置し、そうすることで、形成されるネットワークパケットをクライアント13へ送信する。ここで、FEC処理モジュール243は、データのソース自身であり、これは、オリジナルのRTPパケット22’から生成されるFEC冗長パケット群の送信に対してRTXモジュール252に対して説明されるものと同様のものであることに注意されたい。このFEC冗長ソースは、明瞭にするために図7及び図8におけるFECソースの表現を参照、図2には示されてない。更に、クライアント向けに専用となる追加の情報とヘッダ群を配置するための、バッファメモリ214内のヘッダゾーンの再書込は、各データストリームとサブストリームが連続的に処理されるという事実によって可能であることに注意されたい。図3は、新規のネットワークパケットの送信用のバッファメモリファクトリーによって割り当てられる、バッファメモリ214の内容を記載している。本発明を実現するために採用されるバッファメモリは、いくつかの部分によって構成されるメモリの連続するブロックであることが好ましい。バッファメモリの先頭には、リファレンスカウンタ31がある。このリファレンスカウンタ31は、バッファメモリが別のオブジェクトによって参照される毎にインクリメントされる。この別のオブジェクトは、例えば、RTP仮想パケット、処理モジュールあるいはデータソースがある。このリファレンスカウンタ31は、オブジェクトがバッファメモリへのリファレンスを破棄する毎にデクリメントされる。リファレンスカウンタ31は値0を保持する場合、即ち、システムの任意のオブジェクトによってこれ以上参照されることはない場合、バッファメモリへの割当が解消される。リファレンスカウンタ31の後には、予約空間32が配置される。これは、ヘッダ及び拡張情報の少なくとも一方をペイロードデータに追加するための様々な処理モジュールによって使用することができ、そうすることで、ネットワークを介して転送することができるデータパケットを製造する。この予約空間の最大サイズの計算については後述する。この予約空間32の後に、エンコーダ-パケッタイザのペアによって取得されるペイロードデータを配置するために利用できるゾーン33が配置される。ゾーン33に実際に配置されるペイロードデータのサイズは、ゾーン33のサイズ以下である。バッファメモリファクトリーによってバッファメモリが割り当てられると、そのバッファメモリファクトリーは、ソースに関連付けられている様々なデータストリームマネージャによってなされる予約リクエスト群の最大値となる、予約空間32のサイズを判定する。残りの空間は、ペイロードデータに割り当てられ、そして、ゾーン33を構成する。バッファメモリファクトリーは、エンコーダ/パケッタイザに対して、様々なゾーンに定義することができるいくつかのポインタに割り当てられるバッファメモリを生み出す。-予約空間の開始を指定するバッファメモリへのポインタ-ペイロードデータを配置することができる開始位置を指定するペイロードデータへのポインタ-ペイロードデータへのポインタとして同一位置に最初に配置されるRTPヘッダ拡張群へのポインタバッファメモリの全体サイズは、ネットワークを介して一回であるいは最大送信ユニットに対するMTUで再送信するフラグメンテーションなしでことができるパケットの最大サイズバイトに、リファレンスカウンタ31のサイズを足したサイズに対応する。図4は、追加のペイロードデータ拡張を記載している。処理モジュールあるいはソースがペイロードデータ拡張41をバッファメモリに追加する場合、追加情報のサイズはペイロードデータポインタから差し引かれ、追加の情報がそのポインタによって指定される位置に配置される。つまり、予約空間32の部分は、ペイロードデータ拡張を記憶するために使用される。RTPヘッダ拡張群へのポインタは、また、ペイロードデータへのポインタとして、同一の位置を指示するために更新される。処理モジュール群は、RTPヘッダと取り得るそのRTPヘッダへの拡張群を挿入することができる前に、バッファメモリに挿入されるべきペイロードデータの拡張に対して、順番にデータストリームマネージャで連続的にリンクされてなければならない。処理モジュールが、様々なタイプの情報、例えば、ペイロードデータへの拡張と、RTPヘッダへの拡張をバッファメモリに挿入する場合、処理モジュールは、処理チェーン内の様々な位置に存在することができる。ペイロードデータへの拡張の例には、OSNオリジナルシーケンス番号originalsequencenumber再送信ヘッダがある。これは、RFC4588セクション4RTP再送信ペイロードフォーマット、IETF、RFC4588、2006年7月で記載されるように、パケットを送信しなければならない場合に、オリジナルペイロードデータの前のRTXソースによって配置されなければならない。別の例には、RFC5109セクション7汎用前方誤り訂正用のRTPペイロードフォーマット、IETF、RFC5109、2007年12月に記載される、FECヘッダとFECレベルヘッダがある。2つのタイプの拡張として、ペイロードデータ拡張群とRTPヘッダへの拡張に区別されることに注意されたい。1つ目は、図4を参照して説明され、一方で、2つ目は図5及び図6を参照して説明される。RTPヘッダへの拡張群の追加は、2つのフェーズで実行される。第1フェーズは、図5に示され、RTPヘッダ自身への拡張の配置からなり、第2フェーズは、図6に示され、RTPヘッダへの追加された拡張群を記述する専用ヘッダを追加すること、場合によっては、パディングとからなる。図5は、処理モジュールによる、RTPヘッダ拡張要素の追加を表している。各モジュールは、RTPヘッダへの追加情報を追加することができる。例えば、サーバ10によって提案されるあるサービス群の使用は、各ネットワークパケットで追加情報を送信することを必要とする場合がある。これは、例えば、TFRC輻輳制御サービスを用いる場合である。このTFRC輻輳制御サービスは、文献TCPフレンドリーレート制御によるRTP、IETF、draftietfavttfrcprofile10、2007年7月に記載されている。この場合、この情報は、RFC3550RTP:リアルタイムアプリケーション群用の転送プロトコル、IETF、RFC3550、2003年7月のセクション5.3.1によって定義されるように、RTPヘッダへの拡張を追加することができる。RTPヘッダにいくつかの拡張を配置することを可能にするために、様々なRTPヘッダの拡張群ここでは、RTPヘッダ拡張要素群と呼ぶが、RFC5285RTPヘッダ拡張群用の汎用メカニズム、IETF、RFC5285、2008年7月に従って構成される。これは、RFC3550の目的の範囲内で、RTPヘッダ拡張を形成するために、パケット内で、いくつかのRTPヘッダ拡張要素がどのように関連付けられるかを定義する。図5及び図6は、追加のRTPヘッダ拡張要素群を記載している。図6に示される、RTPヘッダ拡張は、一連のRTP拡張要素群64に続いて、場合によっては、メモリ内のデータのアライメントを保証するためのいくつかのパディングバイトP63を伴って、その前に、拡張ヘッダフィールドID61とフィールドL62からなるからなる。いくつかの実施形態では、各処理モジュールは、RTPヘッダへ追加データを追加することができる。このため、図5に示されるように、この処理モジュールは、追加する要素のサイズを、RTPヘッダ拡張群へのポインタから差し引き、それによって、取得されるアドレスに新規の要素を配置する。RFC5285に従えば、この要素は、ローカル識別子51と、長さ表示52と、追加データ53からなる。ペイロードデータの拡張後、かつネットワークを介して送信するためのRTPパケットをファイナライズするRTPモジュールによる処理前に、RTPヘッダ拡張要素群のすべてがバッファメモリに挿入される。図6は、RTP処理モジュールによってファイナライズされるネットワークパケットを記載している。RTPヘッダ拡張要素群が従前に追加されている場合につまり、ペイロードデータへのポインタとRTPヘッダ拡張群へのポインタ間の差分がゼロでない場合、RTP処理モジュールは、ヘッダ拡張要素群の総和は32の倍数であることこれは、RFC3550セクション5.3.1に記載されるRTPパケット化の制約であるをまず第一に判定することによってRTPパケットをファイナライズする。この判定がこの場合に該当しない場合、RTP処理モジュールは、パッディングバイト63を、RTPヘッダ拡張要素群64の前に追加する。次に、RTP処理モジュールは、RTP拡張要素群の長さの表示62と、識別子61からなるRTP拡張群のヘッダを追加する。RFC5285に従う、1バイトサイズのRTPヘッダへの拡張要素群の場合、識別子61は、例えば、0xBEDEとなる。RTP処理モジュールは、次に、RTPヘッダ65に追加することによってパケットをファイナライズする。RTPヘッダ64への拡張要素群がない場合、つまり、RTPヘッダ拡張群へのポインタ群と、ペイロードデータへのポインタ群が等しい場合、RTP処理モジュールは、ペイロードデータへのポインタの前にRTPヘッダ65を追加する。そのようにして形成されたパケットが、ネットワーク15を介して送信される。図7は、データストリームマネージャの第1の例と、処理モジュールのリンク状態の第1の例を示している。図7は、同一の受信クライアントに対して宛先とされているいくつかのデータストリーム群71、72及び73を表していて、かつ追加データの永続性あるいはストリーム従属性の概念と、データストリーム群の間の承継の概念とを導入している。データストリーム群71、72及び73は従属タイプであり、これは、データストリーム71を処理するFEC処理モジュール714が、データストリーム72に対するFECソース721自身であるからである。データストリーム72を管理する再送信モジュール724RTXは、データストリーム73に対するRTXソース731自身である。このスキーマに従えば、データストリーム71から到来するネットワークパケット群は、データストリーム72から到来するFECパケット群によるネットワーク上のパケット損失から保護される。このデータストリーム72自身は、データストリーム73から到来する再送信パケット群によって保護される。ストリーム群との間の従属性にマークを付けることは、データストリーム72が、データストリーム71のデータのサブストリームであると言える。同様に、データストリーム73は、データストリーム72からデータのサブストリームである。一般的には、処理モジュールが別のデータストリームに対するソース自身である場合、それは、処理モジュールにリンクしているデータストリームに関連するデータサブストリームであると言える。つまり、処理モジュールは、関連するデータサブストリームから、予約空間の制約を承継する。ここで、このスキームに従えば、データストリームマネージャのそれぞれは、輻輳制御サービス712、722及び732をそれぞれ使用する。同様に、各データストリームマネージャは、RTPモジュール713、723及び733をそれぞれ備える。このようなスキームでは、自身のネットワークパケットを送信することを可能にするために、各データストリームとサブストリーム71、72及び73に対して、順番にデータストリーム71のソース711によって生成されるペイロードデータの最大サイズの判定がなされる。ここで、この判定は、一旦ネットワークパケット群がソース711によって生成されて、かつバッファメモリに配置されると、データストリームをコピーするあるいは移動することなく、また、パケット群各パケットは、最大で1つのMTUと等しくなるのフラグメンテーションなしで、なされる。これのため、各処理モジュールは、様々なタイプの予約に従って、また、追加情報のタイプ、ペイロードデータへの拡張のタイプ、あるいはRTPヘッダへの拡張のタイプに従って、さらに、追加情報の追加が従属ストリーム群の間つまり、1つのデータストリームとデータサブストリームの間で永続性の性質であるか否かに従って、予約空間に対する自身の最大の要件群を判定する。また、処理モジュールによってデータストリームに追加される追加情報がデータサブストリーム内で繰り返されなければならないか、あるいは追加情報だけを処理モジュールにリンクしているデータストリームに適用するかを区別する問題がある。例えば、図7を参照すると、輻輳制御モジュール712がTFRCタイプである場合、追加情報をRTPヘッダ拡張で追加しなければならない。この追加情報は、例えば、パケットが送信された日時、あるいはパケットに対するラウンドトリップタイムRTTの評価値である。この情報は、データストリーム専用である。つまり、この情報は正規のサブストリームで繰り返す必要はない。従って、これは、データストリーム従属タイプと言える。一方、データストリーム72は、データストリーム71のオリジナルパケット群からFECパケット群を作成し送信することによって、データストリーム71によって生成されるネットワークパケットを保護する。これに対して、FECパケット群は、とりわけ、FECヘッダをペイロードデータあるいは等価物を追加することによって、処理モジュール714/FECソース721によって生成される。また、FECデータストリーム72は、再送信データストリーム73によって自身が保護される。これに対して、再送信パケット群は、RTX処理モジュール724によって保存されるFECパケット群に基づいて、RTXソース731によって生成される。これは、再送信パケット群が、同時に、ペイロードデータの等価物と、ペイロードデータのFECヘッダとを統合すると言える。このFECヘッダは、永続性タイプである。これは、FECソース721によって追加されるヘッダ群と、RTXソース731は、付加的特性があるとことに注意されたい。この付加的特性は、ストリーム73によって再送信されるパケットは、同時に、データストリーム71のオリジナルのペイロードデータの等価物、データストリーム72のペイロードデータのFECヘッダ、データストリーム73のペイロードデータのRTXヘッダ、及び輻輳制御サービスに対するRTPヘッダへの拡張を統合する。以下の様々なタイプの予約が区別される。-永続性RTPヘッダ拡張群あるいは永続性ヘッダ拡張からのPHE群-ストリーム従属RTPヘッダ拡張群あるいはストリーム従属ヘッダ拡張からのSHDE群-永続性ペイロードデータ拡張群あるいは永続性ペイロード拡張からのPPE群-ストリーム従属ペイロードデータ拡張群あるいは、ストリーム従属ペイロード拡張からのSPDE群図8は、データストリームの第2の例と、処理モジュールのリンク状態の第2の例を示している。ここで、データストリーム81、82及び83は、同一の受信クライアントに向けられている。このスキームに従えば、データストリーム81からのネットワークパケット群は、データサブストリーム82から到来するFECパケット群と、データサブストリーム83から到来するRTX再送信パケット群との両方によって保護することができる。また、データストリーム81、サブストリーム82及び83のそれぞれは、輻輳制御サービス812、822及び832をそれぞれ使用する。データストリームマネージャ81は、ソース811からデータを受信し、そして、輻輳制御モジュール812、RTPモジュール813、FECモジュール814及び再送信モジュール815を備える。データストリームマネージャ82は、輻輳制御モジュール822及びRTPモジュール823を備える。データストリームマネージャ83は、輻輳制御モジュール832とRTPモジュール833を備える。図7で示される場合と比較して、FECソース821あるいはRTXソース831によって追加されるペイロードデータヘッダ群は、付加的特性ではない。図9は、少なくとも1つのサブストリームを備える場合があるデータストリームを転送するためのデータストリームマネージャによって、バッファメモリに予約される空間の最大サイズを計算するためのステップ群のフロー図を示している。データストリームマネージャによる予約リクエストは、以下のイベント群のそれぞれで再評価される。-クライアントが、システムに接続すること、-クライアントが、システムから切断すること、-クライアントが、サービスをアクティベートすること、あるいは-クライアントが、サービスをデアクティベートすること。データストリームマネージャによって要求される予約空間のサイズを判定するために、PHE、SDHE、PPE及びSDPEのタイプ群に従う予約要件群が、ステップ91で、第1モジュールによって開始する各処理モジュールに対して判定されなければならない。予約要件群のこの判定は、後述する。ステップ92で、処理モジュールが、少なくとも1つのサブストリームに対するデータのソース自身であるかが判定される。そうである場合、ステップ93で、処理モジュールは、PHE、SDHE、PPE及びSDPEのタイプ群に従って、各サブストリームの予約要件群を判定する。これらの予約要件群は、承継されたものと言える。そうでない場合、あるいはステップ93の後、ステップ94で、データストリームマネージャは、データストリームマネージャの最終処理モジュールの予約要件が判定されているかを判定する。そうでない場合、データストリームマネージャの新規の処理モジュールを処理するために、ステップ91に戻る。最終モジュールが処理される場合、ステップ95で、データストリームマネージャSで示されるは、以下の方程式に従って、Miで示されるものを構成する処理モジュール群processingmodulesとSjで示されるものを承継するサブストリーム群Substreamsを考慮に入れることによって、自身の予約要件群Rで示されるを判定する。これらの方程式群は、演算式群の形式で表現することができ、この演算式群は、拡張情報のタイプに依存する。データストリームマネージャSに対して、所与のタイプの拡張情報Eを記憶するために要求される予約空間RESは、モジュールMiによって予約される空間の関数として表現することができる。このモジュールMiは、REMiで示されるものと、サブストリームSjによって予約される空間を構成する。サブストリームSjは、方程式5の形式で、RESjで示されるものを承継する。つまり、方程式1から4は、単一方程式RESの形式で表現され、ここでEは拡張情報のタイプ、つまり、PHE、SDHE、PPE、あるいはSDPEのタイプの1つを示している。OEは、以下のものを伴う、タイプEに依存する演算式を示している。OSDHEとOSDPEは、演算式maxに対応し、これは、値のペアの最大値を抽出する。OPHEとOPPEは、演算式に対応し、これは、値のペアの値を追加する。REMiは、データストリームマネージャSのMiで示される処理モジュール群の1つによって、予約Eのタイプに対する予約空間を表している。RESjは、データストリームマネージャSのSjで示されるデータストリーム群の1つによって予約Eのタイプに対する予約空間を表している。様々なタイプの予約要件群がデータストリームに対して一旦判定されると、ステップ96で、以下の演算式で使用して、データストリームSに対して予約される全体空間ERのサイズの判定がなされる。ERS=align32RPHESRSDHESHDRRPPESRSDPESここで、HDRは、RFC5285で定義される、RTPヘッダ拡張群のヘッダのサイズである。図6において、RTPヘッダ65とalign32xは、32ビットの倍数、実用上では、4バイト以上の倍数で、値xのアライメントを表していて、これは、値xがバイトで表現されるからである。ステップ97で、データストリームマネージャは、次に、計算される予約空間に対する自身の要件を、リンクされているソースのバッファメモリファクトリーに記録する。ここで、データストリームマネージャは、0に等しい予約リクエストを送信することによって、バッファメモリファクトリーからのデータストリームを事前に記録することができることに注意されたい。図10は、バッファメモリファクトリーによって実行される、ペイロードデータの最大サイズの計算に対するステップ群のフロー図を表している。つまり、図10は、ステップ101で、データストリームマネージャからの予約に対するリクエストの受信において、バッファメモリファクトリーによって実行されるステップ群を詳細に示している。ステップ102で、予約に対するリクエストが0であるかどうかが判定される。そうである場合、ステップ103で、データストリームと予約に対する自身のリクエストが、予約リクエスト群のリストに追加される。そうでなければ、ステップ104で、データストリームは、予約リクエスト群のリストから削除される。ステップ103あるいはステップ104の一方の後、メモリファクトリーは、リンクしているデータストリームマネージャ群のそれぞれの予約のすべてを有することになる。ステップ105で、バッファメモリファクトリーは、すべてのデータストリームマネージャによって送信することが可能となるペイロードデータの最大サイズを、MTUである、ネットワーク上フラグメンテーションなしでを一度に送信することができるパケットの最大サイズバイト単位から、予約リクエスト群の最大値を差し引くことによって判定する。図11に示される本発明のデバイスの実施形態は、例えば、装置120上に基づいている。この装置120は、例えば、マイクロコンピュータ、ワークステーション、パーソナルデジタルアシスタント、移動電話、ネットワーク動画カメラ、静止画カメラ、テレビ、カムコーダ、あるいは、より一般的には、無線あるいは有線ネットワーク110と接続することができる通信インタフェースで提供される任意の周辺機器移動体であろうとなかろうとがある。装置120は、様々な周辺デバイスに接続することができる。これには、例えば、入力/出力カード不図示に接続されていて、かつ装置120にマルチメディアデータを提供する、デジタル動画カメラ121あるいはスキャナ、あるいは任意の他の画像取得手段あるいは画像記憶手段がある。装置120は、以下のものが接続される通信バス131を備える。-中央処理ユニット132マイクロプロセッサ図2ではCPUで示される-リードオンリーメモリ133、リムーバルであろうとなかろうと、本発明の方法を実行することができ、かつプロセッサあるいはコンピュータによって読取可能な命令群を実行可能なプログラム群を記憶する。-ランダムアクセスメモリ134、これは、起動後、本発明の方法を実現する実行可能コードを含むとともに、その方法を実現するために必要な変数値群及びパラメータ群を記録するように構成されているレジスタ群を含んでいる。--通信インタフェース135、通信ネットワーク110に接続され、この通信インタフェース135は、データを送受信するように構成されている。オプションとしては、装置120は、以下のものを有することができる。-オーディオデータの場合、入力/出力カード不図示、これはマイクロフォン124に接続される。-スクリーン125は、ユーザとのグラフィカルユーザインタフェースとしてデータを表示し、かつ/および、提供するためのものである。このユーザは、キーボード126と、補助的なものであろうとなかろうと、ポインティングデバイスのような任意の他の手段とを使用して、プログラム群と対話することができる。このポインティングデバイスには、例えば、マウス、オプティカルスタイラス、あるいはタッチスクリーン不図示がある。-ハードディスク136あるいは記憶メモリ、これには、例えば、コンパクトフラッシュ登録商標カードがあり、これは、本発明の実現において使用されるあるいは生成されるプログラム群及びデータを記憶することができる。-ディスクドライブあるいは任意の他のリムーバルデータ媒体137、これは、ディスク122を受け付け、それに、本発明に従って、処理されたあるいは処理されるべきデータを読み取りあるいは書き込むように構成されている。通信バス131は、装置120に含まれる、あるいはそれに接続される様々な要素群との間の通信及びインターオペペラビリティを提供する。通信バス131の表現は限定されるものではなく、また、特に、中央処理ユニット132は、装置120の任意の要素と命令群を直接通信することができる、あるいは装置120の別の要素の手段によって命令群を通信することができる。ディスク122は、任意の情報搬送媒体、例えば、書込可能であろうとなかろうと、コンパクトディスクCD-ROM、ZIPディスク、あるいはメモリカードがある。一般的には、デバイスに組み込まれているあるいは組み込まれていない情報記憶手段であって、マイクロコンピュータあるいはマイクロプロセッサによって読み取ることができ、また、場合によっては、リムーバルであっても良い情報記憶手段は、本発明の方法の実施を許容する命令群を実行する1つ以上のプログラムを記憶するように構成されている。装置120によって、本発明の方法の実行を可能にする実行可能コードは、同様に、リードオンリーメモリ133、ハードディスク136、あるいはディスク122のようなリムーバルデジタル記憶媒体に記憶されても良い。変形例に従えば、プログラムの実行可能コードは、インタフェース135を介する通信ネットワーク110の中継によって受信され、それを実行する前に、装置120の記憶手段の1つに記憶される。中央処理ユニット132は、プログラムあるいはプログラム群のソフトウェアコード部分の命令の実行を制御し、かつ指示する。起動時には、非揮発性メモリ、例えば、ハードディスク136あるいはリードオンリーメモリ133に記憶されている、プログラムあるいはプログラム群は、ランダムアクセスメモリ134RAMに送信される。これらの非揮発性媒体は、本発明に従うプログラムあるいはプログラム群の実行可能コードを含むとともに、本発明を実現するために必要な変数群及びパラメータ群を記憶するためのレジスタ群を含んでいる。ここで、本発明に従うデバイスを含む装置120は、プログラムされた装置とすることもできることに注意されたい。この装置120は、例えば、特定用途集積回路あるいはASICに固定されているコンピュータプログラムあるいはプログラム群のコードを含んでいる。上述の説明を読むことで、本発明は、ネットワークパケットの生成においてペイロードデータに追加することになる様々なタイプの追加情報を管理することを可能にすることが理解されるべきである。このネットワークパケットには、例えば、永続性タイプあるいはデータストリーム従属タイプのペイロードデータのヘッダ群ペイロードヘッダ、永続性タイプあるいは純粋なデータ従属タイプの基本的なRTPヘッダ拡張群、及び固定サイズのヘッダ群例えば、基本的なRTPヘッダ群がある。また、ネットワークパケットにおけるペイロードデータに対して利用可能なサイズは常に最適となる。これは、クライアントがシステムへ接続する毎に、あるいはシステムから切断する毎に、また、クライアント群の1つによるサービスのアクティベーションあるいはデアクティベーション毎に、再評価される。そして、ペイロードデータは、決してデュプリケート/コピーされることはない。これは、たとえペイロードデータがいくかの受信先マルチキャストの場合に送信される場合でも、あるいはそれらが同一のクライアントへ複数回送信されるものである場合でも、決してデュプリケート/コピーされることはない。つまり、システムは、より少ないメモリリソースとプロセッサリソースを消費する。