JP2009239480A - 映像受信クライアント、映像配信サーバ、受信アルゴリズム切替制御方法及びプログラム - Google Patents

Abstract

【課題】データフレームのフラグメント数に応じたより効率的な受信動作を実現可能にする映像受信クライアントを提供すること。
【解決手段】通信部１１は、映像ストリームを構成する複数のデータフレームをそれぞれ１つ以上のパケットにフラグメントして送信する映像配信サーバから、ネットワークを介して、該パケットを受信する。データフレームデフラグメント部３５は、受信したパケットをデフラグメントする。デフラグメントアルゴリズムプール部３６には、フラグメント数により性能が相異なる予め用意された複数のデフラグメントアルゴリズムが保持されている。デフラグメントアルゴリズム管理部３７は、上記複数のデフラグメントアルゴリズムのうちから、使用すべきものを、フラグメント数に応じて選択して、データフレームデフラグメント部３５に指示する。
【選択図】 図３

Description

本発明は、映像を配信する映像配信サーバ、映像を受信する映像受信クライアント、映像受信クライアントの受信アルゴリズムの切替制御を行うための受信アルゴリズム切替制御方法及びプログラムに関する。

映像を配信する映像配信サーバと、該映像配信サーバから配信された映像を受信する映像受信クライアントとの間が、ＩＰネットワーク(Internet Protocol)を介して接続されている場合、映像データを配送するためのプロトコルとして、ＲＴＰ(Realtime Transport Protocol)が採用されることが多い。また、映像データを配信する際の各種制御情報やＩＰネットワークの統計情報などをやり取りするためのプロトコルには、ＲＴＣＰ(Realtime Transport Control Protocol)がある。

映像配信サーバから映像受信クライアントに映像データが配信される際に、配信サーバと映像受信クライアントとの間のネットワーク帯域幅を測定することで、映像受信クライアントにおける受信バッファのアンダーフローを予見し、その対策を講じる方法が知られている（特許文献１参照）。この方法によれば、映像受信クライアントは、測定されたネットワーク帯域幅に応じて、映像配信サーバに対し映像データの送信ビットレートを変更するように要求することで、受信バッファのアンダーフローを予防する。

ところで、ＲＴＰを用いた映像配信において、占有するネットワーク帯域とは別の観点として、データフレームのフラグメント数がある。ＭＴＵ(Maximum Transmission Unit)以上のサイズのデータフレームを、ＲＴＰを用いて伝送する場合、映像配信サーバと映像受信クライアントとの間のネットワーク帯域等の統計情報を取得するために、ＩＰレイヤではなくＲＴＰレイヤにてフラグメントを行い、データを送信することが多い。

しかし、データフレームのフラグメント数に応じたより効率的な受信動作を実現することはできなかった。
特開２００４−３２８６１３号公報

従来、データフレームのフラグメント数に応じたより効率的な受信動作を実現することはできなかった。

本発明は、上記事情を考慮してなされたもので、データフレームのフラグメント数に応じたより効率的な受信動作を実現可能にする映像受信クライアント、映像配信サーバ、受信アルゴリズム切替制御方法及びプログラムを提供することを目的とする。

本発明は、映像ストリームを構成する複数のデータフレームをそれぞれ１つ以上のパケットにフラグメントして送信する映像配信サーバから、ネットワークを介して、該パケットを受信する映像受信クライアントであって、前記パケットを受信するパケット受信部と、各々の前記データフレームにつき、当該データフレームのもととなる前記パケットをもとに、当該データフレームをデフラグメントするデフラグメント部と、フラグメント数により性能が相異なる予め用意された複数のデフラグメントアルゴリズムのうちから、前記デフラグメント部が前記データフレームをデフラグメントする際に使用させるものを、前記データフレームに係るフラグメント数に応じて選択して、前記デフラグメント部に指示する制御部とを備えたことを特徴とする。

また、本発明は、映像ストリームを構成する複数のデータフレームをそれぞれ１つ以上のパケットにフラグメントして、ネットワークを介して映像受信クライアントへ送信する映像配信サーバであって、各々の前記データフレームにつき、当該データフレームをそれぞれ１つ以上のパケットにフラグメントするフラグメント部と、前記パケットを送信する送信部と、前記映像受信クライアントが前記データフレームをデフラグメントする際に使用するデフラグメントアルゴリズムを、フラグメント数により性能が相異なる予め用意された複数のデフラグメントアルゴリズムのうちから選択するにあたって、該選択の基準となる情報を、前記映像受信クライアントへ与えるための制御を行う制御部とを備えたことを特徴とする。

なお、装置に係る本発明は方法に係る発明としても成立し、方法に係る本発明は装置に係る発明としても成立する。
また、装置または方法に係る本発明は、コンピュータに当該発明に相当する手順を実行させるための（あるいはコンピュータを当該発明に相当する手段として機能させるための、あるいはコンピュータに当該発明に相当する機能を実現させるための）プログラムとしても成立し、該プログラムを記録したコンピュータ読み取り可能な記録媒体としても成立する。

本発明によれば、データフレームのフラグメント数に応じたより効率的な受信動作を実現することが可能になる。

以下、図面を参照しながら本発明の実施形態について説明する。

図１に、本発明の一実施形態に係る映像配信サーバと映像受信クライアントとを含む映像配信システムの概略構成例を示す。

図１中、１は、映像ストリームを構成する複数のデータフレームをそれぞれ１つ以上のパケットにフラグメントして送信する映像配信サーバであり、３は、該映像配信サーバから該パケットを受信しデフラグメントして、該映像ストリームを構成する該複数のデータフレームを得る映像受信クライアントである。

なお、図１では１台の映像配信サーバ１と１台の映像受信クライアント３が示されているが、映像配信サーバ１が複数台であっても構わないし、及び／又は、映像受信クライアント３が複数台であっても構わない。

ここでは、映像配信サーバ１と映像受信クライアント３の各々がＩＰネットワークに接続されている場合を例にとって説明するが、データのやり取りが可能であれば、ＩＰネットワーク以外の接続方式であっても良い。

また、ここれは、映像配信サーバ１により配信される映像データストリームの映像コーデックがＩＴＵ−Ｔ勧告のＨ．２６４方式である場合を例にとって説明するが、これに限定されるものではない。

また、ここでは、映像データストリームはＵＤＰ(User Datagram Protocol)のＲＴＰにより配信され、映像データストリームを配信する際の制御情報はＲＴＣＰにより映像配信サーバ１と映像受信クライアント３との間でやり取りされる場合を例にとって説明するが、それらプロトコルに限定されるものではない。

次に、図２に、本実施形態の映像配信サーバ１の構成例を示す。

図２に示されるように、映像配信サーバ１は、通信部１１、セッション制御部１２、セッション情報記憶部１３、映像取得部１４、映像エンコード部１５、ＲＴＰスタック（図中、２０参照）のデータフレームフラグメント部１６、ＲＴＰスタックのＲＴＣＰ処理部１７、映像配信制御部１８を備えている。

各部の概要は次の通りである。

通信部１１は、映像受信クライアント３とＩＰネットワークを介してデータの交換を行うためのものである。

セッション制御部１２は、セッションに関する制御を行うためのものである。例えば、セッション制御部１２は、映像の配信先である映像受信クライアント３との間で、映像配信の開始と停止のメッセージのやり取りを行う。

セッション情報記憶部１３は、セッション制御部１２によりネゴシエーションされた映像受信クライアント３とのセッションの状態を保持するためのものである。

映像取得部１４は、映像を取得するためのものである。例えば、映像取得部１４は、カメラから映像データを取得する機能を有しても良いし、その代わりに又はそれに加えて、他の装置から映像データを取得する機能を有しても良い。なお、映像取得部１４の代わりに又は映像取得部１４に加えて、映像データを生成する映像データ生成部（図示せず）を備え、映像データ生成部が生成した映像データを配信対象としても良い。

映像エンコード部１５は、映像取得部１４により取得された映像データをエンコード処理して、圧縮映像データを生成するためのものである。なお、映像取得部にてあらかじめエンコード済みの映像データをデータベース等から取得する場合は映像エンコード部１５がなくてもよい。

データフレームフラグメント部１６は、映像受信クライアント３に配信する圧縮映像データをＲＴＰレベルにてフラグメントするためのものである。

ＲＴＣＰ処理部１７は、セッション制御部１２によりネゴシエーションされた映像受信クライアント３とのＲＴＣＰの処理を行うためのものである。

映像配信制御部１８は、映像配信のための制御を行うためのものである。例えば、映像配信制御部１８は、セッション制御部１２により映像受信クライアント３とネゴシエーションされたセッション情報に基づいて、映像取得部１４に対して、映像の取得の開始又は終了を命令し、映像エンコード部１５に対して、映像取得部１４により取得された映像データから圧縮映像データを生成するエンコード処理の開始又は終了を命令する。

次に、図３に、本実施形態の映像受信クライアント３の構成例を示す。

図３に示されるように、映像受信クライアント３は、通信部３１、セッション制御部３２、セッション情報記憶部３３、ＲＴＰスタック（図中、５０参照）のＲＴＣＰ処理部３４、ＲＴＰスタックのデータフレームデフラグメント部３５、ＲＴＰスタックのデフラグメントアルゴリズムプール部３６、ＲＴＰスタックのデフラグメントアルゴリズム管理部３７、圧縮映像データデコード部３８、再生タイミング制御部３９、画面表示部４０、映像受信制御部４１を備えている。

各部の概要は次の通りである。

通信部３１は、映像配信サーバ１とＩＰネットワークを介してデータの交換を行うためのものである。

セッション制御部３２は、セッションに関する制御を行うためのものである。例えば、セッション制御部３２は、映像の配信元である映像配信サーバ１との間で、映像配信の開始と停止のメッセージのやり取りを行う。

セッション情報記憶部３３は、セッション制御部３２によりネゴシエーションされた映像配信サーバ１とのセッションの状態を保持するためのものである。

ＲＴＣＰ処理部３４は、セッション制御部３２によりネゴシエーションされた映像配信サーバ１とのＲＴＣＰの処理を行うためのものである。

データフレームデフラグメント部３５は、映像配信サーバ１から受信した圧縮映像データをＲＴＰレベルにてデフラグメントするためのものである。例えば、データフレームデフラグメント部３５は、映像配信サーバ１より受信したＲＴＰパケットのヘッダに含まれるシーケンスナンバー・タイムスタンプ・マーカを用いて、映像配信サーバ１において複数のＲＴＰパケットにフラグメントされた圧縮映像データのデフラグメントを行う。

デフラグメントアルゴリズムプール部３６は、データフレームデフラグメント部３５において圧縮映像データのデフラグメントを行うための複数のデフラグメントアルゴリズムを保持するためのものである。

デフラグメントアルゴリズム管理部３７は、デフラグメントアルゴリズムを管理するためのものである。デフラグメントアルゴリズム管理部３７は、例えば、データフレームデフラグメント部３５における圧縮映像データのデフラグメントを行うためのデフラグメントアルゴリズムを、デフラグメントアルゴリズムプール部３６にて保持されている複数のデフラグメントアルゴリズムから選択的に切り換えることを、データフレームデフラグメント部３５に指示する。

圧縮映像データデコード部３８は、圧縮映像データのデコード処理を行うためのものである。

再生タイミング制御部３９は、映像の再生タイミングを制御するためのものである。例えば、再生タイミング制御部３９は、ＲＴＰスタックより得られる圧縮映像データを、該ＲＴＰスタックより圧縮映像データと共に得られるＲＴＰパケットのヘッダに含まれていたタイムスタンプ情報に基づいて、適切なタイミングにて圧縮映像データデコード部３８に渡す。

画面表示部４０は、圧縮映像データデコード部３８によりデコード処理された映像データを画面表示するためのものである。例えば、画面表示部４０は、映像データを映像受信クライアント３のユーザに示すための液晶表示装置により構成される（液晶表示装置に限定されるものではない）。

映像受信制御部４１は、映像受信のための制御を行うためのものである。例えば、映像受信制御部４１は、セッション制御部３２により映像配信サーバ１とネゴシエーションされたセッション情報をＲＴＰスタックに提供することと、再生タイミング制御部３９に対して（再生タイミングを制御した上で）圧縮映像データを圧縮映像データデコード部３８に渡す動作の開始と終了を命令することと、圧縮映像データデコード部３８に対して再生タイミング制御部３９から渡される圧縮映像データのデコード処理の開始又は終了を命令することを行う。

ここで、図１に示されるような映像配信サーバ１が映像受信クライアント３へ映像ストリームを配信するにあたり、その開始のために、例えばＳＩＰ(Session Initiation Protocol)が用いられる。映像受信クライアント３のセッション制御部３２が映像配信サーバ１へ映像ストリームの配信開始のリクエストを送る。映像配信サーバ１のセッション制御部１２が映像受信クライアント３からのリクエストを受け取り、その後に数回のＳＩＰメッセージのやり取りがなされた後に映像配信サーバ１と映像受信クライアント３とのセッションが構築される。このとき、映像配信サーバ１が配信する映像ストリームの使用可能コーデックの候補を映像受信クライアント３へ提示することや、映像受信クライアント３が再生可能な映像コーデックの候補を映像配信サーバ１へ提示することを始めとした、映像ストリームの配信に必要な各種設定情報は、ＳＩＰのメッセージに含まれる形で運ばれるＳＤＰ(Session Description Protocol)により、やり取りされる。なお、ここでは、映像ストリームの配信の開始のためにＳＩＰとＳＤＰを用いる場合について説明したが、他のプロトコルを用いても構わない。

次に、映像配信サーバ１が映像ストリームを映像受信クライアント３に送信する手順について説明する。

図４に、この手順の一例を示す。

＜ステップＳ１＞
映像配信サーバ１のセッション制御部１２は、（例えば、上記した映像ストリーム配信開始のリクエストの受信を契機として開始された）映像受信クライアント３とのセッション構築が完了すると、その旨を映像配信制御部１８に通知する。通知を受けた映像配信制御部１８は、映像取得部１４に対して（例えばカメラから）映像を取得するよう指示する。この指示を受けた映像取得部１４は、映像の取得を開始する。次に、映像配信制御部１８は、映像取得部１４に対して、取得した映像を映像エンコード部１５に渡すよう指示する。この指示を受けた映像取得部１４は、映像を映像エンコード部１５に渡す。

＜ステップＳ２＞
次に、映像配信制御部１８は、映像エンコード部１５に対して、映像取得部１４から取得した映像を、映像受信クライアント３とのセッション開始時にやり取りしたＳＤＰから得た「映像受信クライアント３がデコード可能なコーデック」にエンコードして、圧縮映像データを作成するよう指示する。この指示を受けた映像エンコード部１５は、圧縮映像データを作成する。

＜ステップＳ３＞
次に、映像配信制御部１８は、映像エンコード部１５に対して、上記（映像をエンコードして得られた）圧縮映像データをＲＴＰスタックに渡すように指示する。この指示を受けた映像エンコード部１５は、圧縮映像データをＲＴＰスタックに渡す。映像エンコード部１５から圧縮映像データを得たＲＴＰスタックのデータフレームフラグメント部１６は、通信部１１からＩＰネットワークに送信されるパケットが、映像配信サーバ１と映像受信クライアント３との間のネットワークＭＴＵを超えないようなサイズに、圧縮映像データをフラグメントする。

ＭＴＵを超えないようにフラグメントの大きさを選択する理由は、ＲＴＣＰによりやり取りされる統計情報にはデータを送受信する端末間のネットワーク状態を知るための情報が含まれており、ＭＴＵを超えるサイズにより圧縮映像データが送信された場合にはＩＰフラグメントが行われ、この統計情報を正確に得ることができないことである。

＜ステップＳ４＞
そして、ＲＴＰスタックは、データフレームフラグメント部１６により１つ以上にフラグメントされた圧縮映像データの断片（の系列）を受け取り、各々の断片にＲＴＰヘッダを付加してそれぞれ通信部１１に渡す。

＜ステップＳ５＞
通信部１１は、例えば、ＵＤＰヘッダとＩＰヘッダを付加してＲＴＰパケットを、ＩＰネットワークを介して、映像受信クライアント３に向けて送信する。

ここで、図５に、ＲＴＰパケットのヘッダを示す。なお、図５は、RFC3550より抜粋したものであり、RFC3550は、URI:http://www.ietf.org/rfc/rfc3550.txtにより閲覧可能である。

図５に示されるように、ＲＴＰパケットのヘッダには、ＲＴＰのバージョンを示すバージョンフィールド（Ｖ）、パディングの有無を示すパディングフィールド（Ｐ）、拡張ヘッダフィールドの有無を示す拡張ヘッダフィールド（Ｘ）、ＣＳＲＣ(contributing source)の数を示すＣＳＲＣ数フィールド（ＣＣ）、各種メディアフォーマットにより様々な使われ方をするマーカフィールド（Ｍ）、ＲＴＰにてやり取りされるメディアフォーマットの種別を示すペイロードタイプフィールド（ＰＴ）、連続するＲＴＰパケットの順序を識別するためのシーケンスナンバーフィールド(sequence number) 、やり取りされるメディアデータの再生タイミングを示すタイムスタンプフィールド(timestamp) 、ＲＴＰパケットの送信元を識別するためのＳＳＲＣ(synchronization source)識別フィールド(synchronization source identifier)と、ミキサと呼ばれる中間装置を用いる際に使用されるＣＳＲＣ識別フィールド(contributing source identifier)が含まれる。ただし、ＣＳＲＣ数フィールドの値が０であれば、ＣＳＲＣ識別フィールドはヘッダに含まれない。

次に、図６を参照しながら、１枚の配信映像（図中、１０１参照）に対応する１枚の圧縮映像データ（図中、１０２参照）をＲＴＰフラグメントして得られた１つ以上の圧縮映像データの断片（図中、１０３〜１０７参照）の各々に、ＲＴＰヘッダを付加するルールについて説明する。

映像配信サーバ１が圧縮映像データを映像受信クライアント３に配信する場合に重要となる要素が、ＲＴＰパケットのヘッダのシーケンスナンバーとタイムスタンプとマーカである。

図６において１枚の圧縮映像データが複数のＲＴＰパケットにフラグメントされる際に、まず、シーケンスナンバーは、フラグメントされた複数のＲＴＰパケットの中で先頭のものから順番に１ずつ番号が増えるように付けられる。例えば、図６において、“ｓｅｑ＝１”〜“ｓｅｑ＝５”となっている部分が、それを示している。すなわち、１枚の圧縮映像データをＲＴＰフラグメントすると、圧縮映像データの先頭が含まれるＲＴＰパケットのシーケンスナンバーが最も小さく、圧縮映像データの末尾が含まれるＲＴＰパケットのシーケンスナンバーが最も大きくなる。ただし、シーケンスナンバーは１６ビットのフィールドで表されているために、シーケンスナンバーが“２^１６−１”となったＲＴＰパケットの次のＲＴＰパケットのシーケンスナンバーは０に戻り、この場合に限り上述の大小関係が逆転してシーケンスナンバーが付与される。

次に、タイムスタンプは、メディアデータを受け取る側にメディアの再生タイミングを教えるためのものであるため、フラグメントされた複数のＲＴＰパケットの中ですべてが同一となる。例えば、図６においては、すべてのＲＴＰパケットで“ｔｓ＝３０００”と共通のタイムスタンプ値（３０００）が付けられている。

最後に、マーカは、フラグメントされた複数のＲＴＰパケットのうちで圧縮映像データの末尾を含むＲＴＰパケットにのみ付加される（マーカフィールドの値が１となる）。例えば、図６においては、１０７で示すＲＴＰパケットのマーカフィールドｍの値だけ１となり、１０３〜１０６で示すＲＴＰパケットのマーカフィールドｍの値はすべて０となる。マーカは、複数のＲＴＰパケットにフラグメントされた圧縮映像データを受信側にてデフラグメントして元の１枚の圧縮映像データとして利用するために利用される。

次に、映像受信クライアント３が映像配信サーバ１より配信された映像ストリームを受信して再生する手順について説明する。

図７に、この手順の一例を示す。

＜ステップＳ１１＞
映像受信クライアント３のセッション制御部３２は、（例えば上記した映像ストリーム配信開始のリクエストを送信し、これを映像配信サーバ１が受信したことを契機として開始された）映像配信サーバ１とのセッション構築が完了したことを、映像受信制御部４１に通知する。映像配信サーバ１から映像ストリームの配信が開始され、ＩＰネットワークを介して通信部３１がＩＰパケットを受信する。通信部３１は、必要な処理を行った後に、ＲＴＰパケットをＲＴＰスタックに渡す。ＲＴＰスタックでは、ＲＴＰバージョンフィールドの妥当性検証などのエラーチェックが行われた後に、デフラグメント処理が行われる。

＜ステップＳ１２＞
ＲＴＰスタックのデータフレームデフラグメント部３５は、複数のＲＴＰパケットから１枚の圧縮映像データにデフラグメントしたものを、ＲＴＰパケットのヘッダのタイムスタンプ情報とともに、再生タイミング制御部３９に渡す。再生タイミング制御部３９は、再生の基準となる参照クロックとタイムスタンプを比較することで、適切なタイミングにおいて圧縮映像データを圧縮映像データデコード部３８に渡す。

本実施形態では、再生タイミング制御部３９が映像の各フレームの再生タイミングを制御するが、用いられるコーデックによっては必ずしもそのような制御が必要ではなく、例えばＨ．２６４であれば各フレームの映像データのヘッダに再生タイミングを示す情報が含まれる。

＜ステップＳ１３＞
圧縮映像データデコード部３８は、再生タイミング制御部３９より圧縮映像データを取得してデコード処理を行い、その結果を画面表示部４０に渡す。

＜ステップＳ１４＞
画面表示部４０は、圧縮映像データデコード部３８でデコードされた映像データをユーザに表示する。

次に、図８を参照しながら、フラグメントされたＲＴＰパケット（図中、１０３〜１０７参照）から、１枚の受信映像（図中、１０９参照）に対応する１枚の圧縮映像データ（図中、１０８参照）をデフラグメントする過程について説明する。

映像配信サーバ１が送信した複数のＲＴＰパケットを映像受信クライアント３が受信し、各ＲＴＰパケットのヘッダのシーケンスナンバーとヘッダのタイムスタンプとヘッダのマーカとを用いて、１枚の圧縮映像データをデフラグメントする。

まず、受信した複数のＲＴＰパケットをシーケンスナンバーの小さいものから大きなものへ順に並べる。ただし、図６を用いたＲＴＰパケットのヘッダの付加方法の説明にて述べたように、シーケンスナンバーは“２^１６−１”の次が０になり、この値の飛びもシーケンスナンバーが連続しているものと判別される。

次に、タイムスタンプに注目する。１枚の圧縮映像データがフラグメントされて送信されたところの複数のＲＴＰパケットのヘッダには、すべて同一のタイムスタンプが付加されている。最も小さいシーケンスナンバーを持つＲＴＰパケットからより大きいシーケンスナンバーを持つＲＴＰパケットへと順番に、タイムスタンプの同一性をチェックしていく。このチェックは、ＲＴＰパケットのヘッダのマーカフィールドの値が１であるパケットに到達するまで行われる。ただし、マーカフィールドの値が１であるパケットに到達する前に、シーケンスナンバーの順番に並べられたＲＴＰパケットのシーケンスナンバーに不連続が存在していることが判断されるか、ＲＴＰパケットのタイムスタンプ情報の同一性が失われているＲＴＰパケットに到達した場合には、映像配信サーバ１と映像受信クライアント３との間にてＲＴＰパケットが失われたことを示しており、１枚の圧縮映像データをデフラグメントすることができないと判断される。なお、ＲＴＰパケットがＩＰネットワークを介してやり取りされる際に映像配信サーバ１におけるパケットの送信順序と映像受信クライアント３におけるパケットの受信順序とが逆転する場合を考慮して、１枚の圧縮映像データをデフラグメントすることができないと判断されるまでに時間的な猶予を設ける実装も可能である。

図８に示すように、ＲＴＰパケットのヘッダのシーケンスナンバー（ｓｅｑ）が連続しており、タイムスタンプ（ｔｓ）が同一でありマーカフィールド（ｍ）の値が１であるＲＴＰパケットまでチェックが到達した場合に、１枚の圧縮データのデフラグメントが可能と判定される。

さて、映像受信クライアント３のＲＴＰスタックのデータフレームデフラグメント部３５にて、映像配信サーバ１よりＩＰネットワークを介して受信した複数のＲＴＰパケットから１枚の圧縮映像データをデフラグメントする際に、デフラグメントアルゴリズム管理部３７は、デフラグメントアルゴリズムプール部３６に存在する複数のデフラグメントアルゴリズムから、フラグメント数に最適なアルゴリズムを１つ選択してデータフレームデフラグメント部３５に通知する役割を担う。

デフラグメントアルゴリズムには、例えば、単純に受信キューにシーケンスナンバー順の順番で並べられた複数のＲＴＰパケットでデータフレームのデフラグメントが可能であると判断されるまでスキャンを続ける単純なアルゴリズム（以下、「単純アルゴリズム」と呼ぶ。）と、受信キューにＲＴＰパケットをシーケンスナンバーの順番に並べる際に追加的な情報を各パケットに付加することでデフラグメントが可能であるかを簡便に判断することができるアルゴリズム（以下、「付加情報アルゴリズム」と呼ぶ。）が存在する。

詳細については後で説明するが、これらのアルゴリズムには、フラグメント数による性能の優劣が存在する。後に示す単純アルゴリズムは、圧縮映像データのフラグメント数が少ない場合に付加情報アルゴリズムと比較して性能が優れており、計算機のＣＰＵ(Central processing unit)のリソースの使用量が少なくて済む。一方、付加情報アルゴリズムは、圧縮映像データのフラグメント数が多い場合に単純アルゴリズムと比較して性能が優れており、計算機のＣＰＵのリソースの使用量が少なくて済む。圧縮映像データのフラグメント数に対して選択的にデフラグメントアルゴリズムを使用することにより、映像受信クライアント３を効率的に動作させることが可能である。

以下では、上述の単純アルゴリズムと付加情報アルゴリズムについてより詳しく説明する。

映像受信クライアント３がリアルタイムの映像ストリーミングを受信してユーザに表示する場合、できるだけ低遅延であることが望ましい。ＲＴＰスタックのデフラグメント過程は、その側面から、ＲＴＰパケットを受信する毎に圧縮映像データのデフラグメントが可能であるか否かの判断を行い、ユーザアプリケーションにできるだけ早いタイミングにてデフラグメントされた圧縮映像データを渡す。したがって、映像受信クライアント３のＲＴＰスタックのデータフレームデフラグメント部３５は、ＲＴＰパケットを受信して受信キューに入れる処理と、圧縮映像データのデフラグメントが可能であるか否かの判断をする処理とを交互に行う。デフラグメントされた圧縮映像データはユーザアプリケーションの一部である再生タイミング制御部３９に渡される。以下、単純アルゴリズムと付加情報アルゴリズムのそれぞれについて、ＲＴＰパケットを受信キューに入れる処理及び圧縮映像データのデフラグメントが可能であるか否かの判断をする処理を詳しく説明する。

最初に、単純アルゴリズムについて説明する。

ＲＴＰスタックのデータフレームデフラグメント部３５がＲＴＰパケットを受信キューに入れる処理では、そのＲＴＰパケットのシーケンスナンバーをチェックして、シーケンスナンバーの順序で受信キューの適切な位置に配置する。受信する映像ストリームについてＩＰネットワークにおけるパケット到着順序の入れ代わりがない限り、ＲＴＰパケットは受信キューの末尾に追加されると考えられる。

図９に、単純アルゴリズムの場合にデータフレームデフラグメント部３５が圧縮映像データのデフラグメントが可能であるか否かの判断をする処理の手順例を示す。

受信キューの先頭よりキューのスキャンを開始する（ステップＳ２１）。

先頭ＲＴＰパケットのマーカフィールドを参照し、その値が１である場合には（ステップＳ２２）、単一のＲＴＰパケットのみで圧縮映像データが構成されていると判断されるので、そのＲＴＰパケットのデータ部と該ＲＴＰパケットのタイムスタンプとをユーザアプリケーションに渡す。

マーカフィールドの値が１でない場合には（ステップＳ２２）、複数のＲＴＰパケットにより圧縮映像データが構成されると判断されるので、ステップＳ２６，Ｓ２７，Ｓ２９の全てにおいてＹｅｓとなるまで、次々とパケットの検査が続けられる（Ｓ３０）。ただし、その前にステップＳ２３又はステップＳ２７若しくはステップＳ２８でＮｏとなった場合には、パケットがまだ到着していないか（Ｓ２４）又はパケットロスや順序入れ替えなどが発生している（Ｓ２８）ので、この手順は中止となる（次のＲＴＰパケットが受信されたときに、この手順が最初から実行し直される）。

さて、受信キューの次に位置するはずのＲＴＰパケットが、まだ受信キューに存在していない場合には（ステップＳ２３）、データフレームデフラグメント部３５は、ＲＴＰパケットを受信キューに入れる処理を行う。

受信キューの次のＲＴＰパケットが存在する場合には（ステップＳ２３）、受信キューのスキャンを進める（Ｓ２５）。まず、先ほどスキャンを行ったパケットとのシーケンスナンバーの連続性をチェックする。

連続性のチェック結果が正当である（すなわち、シーケンスナンバーが連続している）ときは（ステップＳ２６）、続いて、先ほどスキャンを行ったパケットとのタイムスタンプを比較する。すでに説明したように圧縮映像データが複数のＲＴＰパケットにフラグメントされる際には、各ＲＴＰパケットのヘッダのタイムスタンプフィールドは同一のものとなるように付与される。タイムスタンプが先ほどのパケットと同一であればフラグメントされた圧縮映像データを構成する１つのＲＴＰパケットであると判断される。

タイムスタンプが同一であるときは（ステップＳ２７）、続いて、現在検査中のパケットについてマーカフィールドの値を参照する。

マーカフィールドの値が１であれば（ステップＳ２７）、先ほどのＲＴＰパケットと現在検査中のＲＴＰパケットの２つのＲＴＰパケットから１つの圧縮映像データのデフラグメントが可能であると判断されるので、それぞれのＲＴＰパケットのデータ部をシーケンスナンバーの順番に結合されてできたデータフレームとタイムスタンプの値をユーザアプリケーションに渡す。

マーカフィールドの値が１でなければ（ステップＳ２７）、再びデータフレームデフラグメント部３５は、ＲＴＰパケットを受信キューに入れる処理を行う。

受信キューに入れたＲＴＰパケットは到着順序の逆転したパケットである可能性があるため、データフレームデフラグメント部３５は受信キューの先頭も含めてそのＲＴＰパケットが受信キューのどの部分に入れられたかを知ることをできない。このため、データフレームデフラグメント部３５は受信キューの先頭よりスキャンを行って圧縮映像データのデフラグメントが可能であるか否かを判断する処理を行う。

最後に、ステップＳ２２又はステップＳ２９でＹｅｓとなった場合には、デフラグメント処理を開始し（ステップＳ３１）、ＲＴＰパケットのデータ部分をアプリケーションバッファにコピーする（ステップＳ３２）。

単純アルゴリズムでは、受信する複数のＲＴＰパケットについて後述する付加情報アルゴリズムにおいて使用されるような情報を付け加えることをしない。そのために、デフラグメントのために連続して受信キューを先頭よりスキャンするにもかかわらず、フラグメント数が小さい場合においては高速に動作する。

続いて、付加情報アルゴリズムについて説明する。

ＲＴＰスタックのデータフレームデフラグメント部３５がＲＴＰパケットを受信キューに入れる処理では、単純アルゴリズムと同様に、まず、そのＲＴＰパケットのシーケンスナンバーをチェックして、シーケンスナンバーの順序で受信キューの適切な位置に配置する。次に、直前に受信キューに格納されたＲＴＰパケットとのタイムスタンプの比較を行う。この後に、受信したＲＴＰパケットに個別に対応する付加情報を作成する。

ここで、付加情報について説明する。

図１０に、付加情報の例を示す。

変数top_packet_in_same_TSは、同一のタイムスタンプを持つ複数のＲＴＰパケットのうちで最も値の小さいシーケンスナンバーを持つＲＴＰパケットを指示するポインタである。すなわち、１つの圧縮映像データフレームを考えた場合、変数top_packet_in_same_TSにて指示されるＲＴＰパケットは、そのデータフレームの先頭部分を含むデータを保持している。

変数packet_num_in_TSは、変数top_packet_in_same_TSにて指示されるＲＴＰパケットにのみ付与され、同一のタイムスタンプをもつ複数のＲＴＰパケットの数をカウントする。

変数fragment_conditionは、変数top_packet_in_same_TSにて指示されるＲＴＰパケットにのみ付与され、同一タイムスタンプを持つ複数のＲＴＰパケットにて１つの圧縮映像データがデフラグメント可能であるか否かを示す情報を保持する。

データフレームデフラグメント部３５がＲＴＰパケットを受信キューに入れる際に、以上の変数（の全部又は一部）を含む付加情報を付与する。

図１１に、上記付加情報を付与する処理の手順例を示す。

シーケンスナンバーの順序で受信キューの適切な位置に配置されたＲＴＰパケットに対して、いま配置したＲＴＰパケットよりキューの先頭側の隣接するＲＴＰパケットとのタイムスタンプの比較を行う（ステップＳ４１）。

タイムスタンプの値が異なる場合には（ステップＳ４２）、これから情報を付加するＲＴＰパケットは、デフラグメントされる１つの圧縮映像データの先頭部分を含むデータを保持するパケットである可能性があることから、変数top_packet_in_same_TSに自身へのポインタを格納し（ステップＳ４３）、変数packet_num_in_TSに１を格納する（ステップＳ４４）。

タイムスタンプ値が同一である場合には（ステップＳ４２）、これから情報を付加するＲＴＰパケットは、デフラグメントされる１つの圧縮映像データの先頭部分を含まないデータを保持しているパケットである。変数top_packet_in_same_TSに、シーケンスナンバーが該パケットより小さくかつ近い番号を持つ既に受信キューに格納済みのＲＴＰパケットの変数top_packet_in_same_TSの値をコピーして格納する（ステップＳ４５）。また、変数top_packet_in_same_TSにて指示されるＲＴＰパケットに付加されている変数packet_num_in_TSの値を１つ増加させる（ステップＳ４６）。

次に、受信キューに格納されるＲＴＰパケットのマーカフィールドの値が１でなければ（ステップＳ４７）、受信キューへの格納が完了する（ステップＳ４８）。

一方、受信キューに格納されるＲＴＰパケットのマーカフィールドの値が１であれば（ステップＳ４７）、変数top_packet_in_same_TSにて指示されるＲＴＰパケットの変数packet_num_in_TSの値と、いま受信キューに格納されるマーカフィールドの値が１であるＲＴＰパケットのシーケンスナンバーの値から変数top_packet_in_same_TSにて指示されるＲＴＰパケットのシーケンスナンバーの値を引いたものに１加えたものの２つの値とが同一か否か調べ（あるいは、両方の値の差を計算し）（ステップＳ４９）、それらが一致する場合（あるいは、それらの差が０である場合）（ステップＳ５０）、デフラメントが可能であるので、変数top_pacekt_in_same_TSにて指示されるＲＴＰパケットの変数fragment_conditionの値に、圧縮映像データのデフラグメントが可能であることを示す値（例えば１）を入れる（ステップＳ５１）。なお、一致しない場合（あるいは、差が０でない場合）には（ステップＳ５１）、デフラメントは可能ではなく、パケットロスや順序入れ替えなどが発生している（Ｓ５２）ことになる。

付加情報アルゴリズムの圧縮映像データがデフラグメント可能であるか否かの判断は、変数fragment_conditionの値を検査するのみで可能である。変数fragment_conditionの値が圧縮映像データのデフラグメントが可能であることを示す値であれば、マーカフィールドの値が１であるＲＴＰパケットに到達するまで順番にパケットのデータ部をシーケンスナンバーの順番に結合し、デフラグメントされた１つの圧縮映像データとタイムスタンプの値をユーザアプリケーションに渡す。もし、変数fragment_conditionの値が上述とは違うものであれば、まだデフラグメントするだけの十分なデータが受信キューに存在しないか、デフラグメントが不可能であるかのどちらかであると判断される。デフラグメントするだけの十分なデータが受信キューに存在しない場合、ＲＴＰパケットを受信キューに入れる処理に切り替わる。

図１２に、単純アルゴリズムと付加情報アルゴリズムについて、データフレームのフラグメント数に応じた性能の比較を行った結果を例示する。

図１２において、横軸は、データフレームのフラグメント数を示している。各ＲＴＰパケットのデータ部のサイズは１４００バイトである。例えば、フラグメント数が５であれば、デフラグメントされた１つのデータフレームのサイズは１４００×５＝７０００バイトである。縦軸は、付加情報アルゴリズムを基準とした単純アルゴリズムの性能差を、パーセント単位で示したものである。性能差が正であることは付加情報アルゴリズムの性能が単純アルゴリズムよりも優っていることを示す。特徴的な結果として、例えば、フラグメント数が２である場合、単純アルゴリズムは付加情報アルゴリズムよりも５％高速に動作し、一方、フラグメント数が７である場合、付加情報アルゴリズムは単純アルゴリズムよりも７％高速に動作する。図１２の例の場合、フラグメント数が５以下の場合には単純アルゴリズムを選択し、フラグメント数が６以上の場合には付加情報アルゴリズムを選択するのが良いことが分かる。

本実施形態では、圧縮映像データのフラグメント数に対して選択的にデフラグメントアルゴリズムを使用することにより映像受信クライアント３を効率的に動作させるが、その動作は例えば以下に示すような制御により実現できる。

実装が簡便な方法としては、フラグメント数の平均値によりデフラグメントアルゴリズムの選択を断続的に変化させる方法がある。

図１３に、この場合の処理手順の一例を示す。

単純アルゴリズムと付加情報アルゴリズムとの性能が逆転する性能境界であるフラグメント数Ｎがあらかじめ分かっているものとする（フラグメント数Ｎがあらかじめ決められているものとする）。

映像意配信サーバからの映像ストリームの配信が開始され（ステップＳ６１）、ＲＴＰデータストリームが受信されると（ステップＳ６２）、まず、映像受信クライアント３のデータフレームデフラグメント部３５は、単純アルゴリズムにて動作して受信を行う。

デフラグメントアルゴリズム管理部３７は、データフレームデフラグメント部３５がデフラグメントする各データフレームのフラグメント数をカウントする。デフラグメントアルゴリズム管理部３７は、一定時間カウントした後に（ステップＳ６３）、受信中の映像ストリームの平均フラグメント数Ｎａを計算する（ステップＳ６４）。

デフラグメントアルゴリズム管理部３７は、ＮａがＮ以上である場合には（ステップＳ６５）、デフラグメントに付加情報アルゴリズムを用いる方が効率的であると判断し、データフレームデフラグメント部３５に付加情報アルゴリズムにてデフラグメントを行うように指示する（ステップＳ６６）。

一方、ＮａがＮよりも小さい場合には（ステップＳ６５）、単純アルゴリズムにてデフラグメントを行うように指示する（ステップＳ６７）。

その後に、一定時間経過すると、再びデフラグメントアルゴリズム管理部３７は、データフレームデフラグメント部３５が使用すべきデフラグメントアルゴリズムがいずれであるかの判断を行う（ステップＳ６２〜Ｓ６５）。

次に、他の方法として、映像ストリームの圧縮映像データのフラグメント数の変化パターンに注目して効率的な動作を行う方法がある。

まず、変化パターンについてＨ．２６４を例にとって説明する。

映像配信サーバ１から映像受信クライアント３へと映像データストリームがＨ．２６４にて配信されている。図１４を参照しながら、Ｈ．２６４により映像配信サーバ１が配信する映像データストリームのフラグメント数の変化について説明する。

Ｈ．２６４には主に、単独で１枚のビデオフレームが完結するＩフレームと、直前のビデオフレームの内容との差分を利用して１枚のビデオフレームを作成するためのＰフレームと、直前のビデオフレームの内容との差分と直後のビデオフレームの内容との差分の２種類の情報を利用して１枚のビデオフレームを作成するためのＢフレームの３種類のフレームがある。Ｉフレームは単独で１枚のビデオフレームとして完結しているためにそのデータサイズは、他のビデオフレームからの情報を利用するＰフレームやＢフレームと比較して大きいことがほとんどである。例えば、リアルタイム映像の配信では、Ｂフレームがそのビデオフレームよりも未来の時刻のビデオフレームの情報を必要とすることから、映像配信サーバ１から映像受信クライアント３へと映像が配信されてから映像受信クライアント３にて映像が表示されるまでの遅延を増大させないためにＩフレームとＰフレームの２種類のフレームを用いた配信が好まれて使用される。

ここでは、本実施形態の理解を容易にするために、Ｂフレームを用いずに、ＩフレームとＰフレームを用いたリアルタイム映像を映像配信サーバ１が映像受信クライアント３に配信する場合を例にとって説明するが、Ｂフレームを用いたとしても本実施形態の特徴が変わるものではない。

図１４は、映像配信サーバ１から映像受信クライアント３に配信される映像データストリームのデータの模式図である。ここでは、図１４に示されるように、映像受信クライアント３は、ＩフレームとＰフレームを、｛Ｉ，Ｐ，Ｐ，Ｐ，Ｐ，Ｉ，Ｐ，Ｐ，Ｐ，Ｐ，Ｉ，…｝という順序で受信している場合について考える。なお、図１４において横長の長方形が複数描かれているが、各々が１つのＲＴＰパケットを示している。ＩフレームとＰフレームの系列は一般に、直近の２つのＩフレームに挟まれているＰフレームの数が一定である場合が多い。

ここで、図１４の特徴を抽出した図１５を参照しながら、映像データストリームの特徴と、映像受信クライアント３のデフラグメントアルゴリズム管理部３７の動作について説明する。

単純アルゴリズムと付加情報アルゴリズムのフラグメント数に対する優位さが逆転するフラグメント数が存在し、例えば図１５の「性能境界」にて表されるフラグメント数＝５がこれらの優劣を分けるとする。図１５にて示されるパターンにおいては、Ｐフレームのフラグメント数は常に５よりも小さいので、単純アルゴリズムを用いてデフラグメントを行う方が効率が良く、一方、Ｉフレームのフラグメント数は常に５よりも大きいので、付加情報アルゴリズムを用いてデフラグメントを行う方が効率が良い。

デフラグメントアルゴリズムの適切な使用のために、映像受信クライアント３のＲＴＰスタックのデフラグメントアルゴリズム管理部３７は、受信する映像ストリームのビデオフレームについてそれぞれのフラグメント数を観察し、フラグメント数のシーケンスパターンを予測する。この予測は、単純アルゴリズムと付加情報アルゴリズムの性能境界であるフラグメント数Ｎとの大小にのみ注目すればよい。すなわち、映像受信クライアント３が図１５のようなＩフレームとＰフレームのデータストリームを受信している場合、性能境界Ｎ以上のフラグメント数であるデータフレームであった場合には１を、性能境界Ｎより小さいフラグメント数であるデータフレームであった場合には０を記録すると、得られる系列は「１００００１００００１…」となる。デフラグメントアルゴリズム管理部３７は、この系列から特徴的な１を基準として「１００００」が繰り返しのパターンであると判断して予測シーケンスパターンを生成する。

デフラグメントアルゴリズム管理部３７は、この予測シーケンスパターンに基づいて、適当なタイミングにてデータフレームデフラグメント部３５にデフラグメントアルゴリズムの切替を開始するとともに逐一指示をする。すなわち、データフレームが複数のＲＴＰパケットにデフラグメントされる際にデータフレームが異なれば異なるタイムスタンプが付与されることから、タイムスタンプの変化から判断して、使用するデフラグメントアルゴリズムを予測シーケンスパターンに基づいて指示する。

予測シーケンスパターンの適用については、どのようなタイミングでも構わないが、例えば、フラグメント数の観察によって「…００１００００」となった直後に予測シーケンスパターン「１００００」の適用を開始すればよい。

図１６に、映像受信クライアント３のＲＴＰスタックのデフラグメントアルゴリズム管理部３７の動作に対する擬似コードの一例を示す。

図１６に示されている関数は、ＲＴＰパケットを受信キューに格納するための関数RTP_recv_packet_queuing_functionと、後に説明する関数do_fragment_function_changeである。関数recv_packet_from_RTP_validation_checkが通信部３１からＲＴＰパケットを受け取り、関数queuing_by_sequence_numberが受け取ったＲＴＰパケットのヘッダのシーケンスナンバーから判断して受信キューの適切な位置にそのＲＴＰパケットを格納する。

次に、関数do_fragment_function_chngeに入って受信したＲＴＰパケットが直前に受信したＲＴＰパケットと比較して異なっているか否かの判断を行う。もし異なっている場合には、いま受信したＲＴＰパケットと直前に受信したＲＴＰパケットとは異なる圧縮映像データの１つの構成要素であると判断され、予測シーケンスパターンのビット列の読み出しを先に進める。

図１６において、予測シーケンスパターンは変数sequence_patternにて示されており、本具体例においては、予測シーケンスパターンは、２進数表現で「１００００」という値を持つ。また、図１６において変数ｃｏｕｎｔｅｒは、予測シーケンスパターンを読み出すためのカーソルを示しており、カーソルが予測シーケンスパターンの末尾（本具体例では、１であるビット）に達したときに、先頭に戻るように実装を行う。

関数do_fragment_function_changeの呼び出しを含む一連のｉｆ文によるスコープを抜けた後に、変数use_simple_functionの値が０でない場合に限り、関数adding_info_for_queuing_RTPpacketにより付加情報アルゴリズムの適用を行う。

以上のデフラグメントアルゴリズム管理部３７の動作は、映像配信サーバ１と映像受信クライアント３との間に独自実装が必要ではなく、映像受信クライアント３がより汎用的な映像配信サーバ１から映像ストリームを受信する場合に適用可能である。

一方で、映像配信サーバ１と映像受信クライアント３との間に独自実装を加えることで実現する方法も存在する。

その１つとして、映像受信クライアント３のデフラグメントアルゴリズム管理部３７にて予測シーケンスパターンの生成を行わない代わりに、シーケンスパターンを映像配信サーバ１から映像受信クライアント３に提供する方法がある。

例えば、ＲＴＰを用いたデータセッションに用いられるＲＴＣＰに独自のフィールドを追加することにより、これを実現する方法がある。ＲＴＣＰでは、アプリケーション固有のAPP RTCPパケットを定義することが可能であり、これを用いてＩフレームとＰフレームのシーケンスパターンのやり取りを行う。この場合、映像受信クライアント３においてＲＴＣＰ処理部３４とデフラグメントアルゴリズム管理部３７との間の通信が必要となる。

図１７に、この場合の映像受信クライアント３の構成例を示す。

ＲＴＣＰ処理部３４は、APP RTCPパケットからシーケンスパターンを抽出し、デフラグメントアルゴリズム管理部３７に渡す。デフラグメントアルゴリズム管理部３７は、受け取ったシーケンスパターンを用いて、適当なタイミングにてデータフレームデフラグメント部３５にデフラグメントアルゴリズム切替の指示を開始する。デフラグメントアルゴリズム管理部３７はデータフレームが複数のＲＴＰパケットにフラグメントされる際に、複数のＲＴＰパケットには同一のタイムスタンプが付与されることから、使用するデフラグメントアルゴリズムをタイムスタンプの変化とシーケンスパターンに基づいて切替るよう指示する。なお、ここでは、一例としてAPP RTCPパケットを用いてシーケンスパターンのやり取りを実現したが、他のプロトコルを用いて映像配信サーバ１と映像受信クライアント３との間で同様の情報をやり取りしても構わない。

また、他の独自実装を要求する例として、映像受信クライアント３のデフラグメントアルゴリズム管理部３７にて予測シーケンスパターンの生成を行わない代わりに、ＲＴＰパケットのヘッダのタイムスタンプを利用してデフラグメントアルゴリズムの制御を行う方法がある。

一般に映像ストリームをＲＴＰパケットにて伝送する場合、タイムスタンプは９０ｋＨｚのものを用いることが多く、映像のフレームレートが３０ｆｐｓにて配信されている場合のタイムスタンプは、フレームごとに３０００ずつ増加する。この場合、タイムスタンプフィールドの最下位ビットは、増加数の３０００が偶数であることから、変化することはない。したがってこの場合には、最下位ビットにフラグメントアルゴリズムの切替制御情報を重畳することができる。また、タイムスタンプの最下位ビットが変化するような増加をする場合も、以下に示すようにあらかじめ最下位ビットをデフラグメントアルゴリズムの制御に使用できる。

例えば、単純アルゴリズムにてデフラグメントすべきデータフレームであればタイムスタンプの最下位ビットを０に設定することでＲＴＰパケットを送信し、付加情報アルゴリズムにてデフラグメントすべきデータフレームであればタイムスタンプの最下位ビットを１に設定することでＲＴＰパケットを送信するよう決めると、図１６にて示されていた擬似コードは、例えば、図１８にて示されるものに変更される。変数RTPpacket_timestampは、いま受信したＲＴＰパケットのタイムスタンプであり、図１８においては、タイムスタンプの最下位ビットが１の場合に、フラグメント数が大きいときに優位な付加情報アルゴリズムが選択されるようになっている。

この方法では、映像配信サーバ１の独自実装により映像受信クライアント３のデフラグメントアルゴリズムの選択を可能にしているにもかかわらず、タイムスタンプの本来の値からの変化が最小限にとどめられていることにより、この実装に対応していない一般の映像受信クライアント３での視聴に大きな影響を与えるものではない。すなわち、映像受信クライアント３において映像を再生する場合にＲＴＰパケットのヘッダのタイムスタンプ情報を参照するが、本実施形態によるタイムスタンプ値の変化が１であり、これは９０ｋＨｚにて動作するクロックと比較すると、時間にして０．０１１ミリ秒であり、フレームレートが３０ｆｐｓである映像の連続するビデオフレームの再生間隔である33ミリ秒に比べて、十分に小さい。

以上説明してきたように、本実施形態によれば、映像受信クライアントが映像配信サーバからＲＴＰにより映像配信を受ける場合において、従来のようにビットレートとは違う側面であるデータフレームのフラグメント数に注目し、選択的に最適な受信アルゴリズムを適用することで、映像受信クライアントが効率的に動作することができる。

なお、以上の各機能は、ソフトウェアとして記述し適当な機構をもったコンピュータに処理させても実現可能である。
また、本実施形態は、コンピュータに所定の手順を実行させるための、あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるためのプログラムとして実施することもできる。加えて該プログラムを記録したコンピュータ読取り可能な記録媒体として実施することもできる。

なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

本発明の一実施形態に係る映像配信サーバと映像受信クライアントとを含む映像配信システムの概略構成例を示す図 同実施形態に係る映像配信サーバの構成例を示す図 同実施形態に係る映像受信クライアントの構成例を示す図 映像配信サーバが映像ストリームを映像受信クライアントに送信する手順例を示すフローチャート ＲＴＰのヘッダについて説明するための図 圧縮映像データのＲＴＰフラグメントについて説明するための図 映像受信クライアントが映像配信サーバより配信された映像ストリームを受信して再生する手順例を示すフローチャート 圧縮映像データのＲＴＰデフラグメントについて説明するための図 単純アルゴリズムの一例を示すフローチャート 付加情報アルゴリズムのデータ整理用構造体の一例を示す図 付加情報アルゴリズムの一例を示すフローチャート 付加情報アルゴリズムに対する単純アルゴリズムのフラグメント数による性能差について説明するための図 フラグメント数の平均を用いたアルゴリズム切替制御の一例を示すフローチャート 映像ストリームのフラグメント数の変化の一例について説明するための図 単純アルゴリズムと付加情報アルゴリズムとの性能境界により得られる映像ストリームのフラグメント数シーケンスの一例について説明するための図 予測フラグメント数シーケンスパターンによるデフラグメントアルゴリズムを行う場合の擬似コードの一例を示す図 同実施形態に係る映像受信クライアントの他の構成例を示す図 タイムスタンプによる情報からデフラグメントアルゴリズムの切替制御を行う場合の擬似コードの一例を示す図

符号の説明

１…映像配信サーバ、３…映像受信クライアント、１１…通信部、１２…セッション制御部、１３…セッション情報記憶部、１４…映像取得部、１５…映像エンコード部、１６…データフレームフラグメント部、１７…ＲＴＣＰ処理部、１８…映像配信制御部、３１…通信部、３２…セッション制御部、３３…セッション情報記憶部、３４…ＲＴＣＰ処理部、３５…データフレームデフラグメント部、３６…デフラグメントアルゴリズムプール部、３７…デフラグメントアルゴリズム管理部、３８…圧縮映像データデコード部、３９…再生タイミング制御部、４０…画面表示部、４１…映像受信制御部、２０，５０…ＲＴＰスタック

Claims (16)

1. 映像ストリームを構成する複数のデータフレームをそれぞれ１つ以上のパケットにフラグメントして送信する映像配信サーバから、ネットワークを介して、該パケットを受信する映像受信クライアントであって、
   前記パケットを受信するパケット受信部と、
   各々の前記データフレームにつき、当該データフレームのもととなる前記パケットをもとに、当該データフレームをデフラグメントするデフラグメント部と、
   フラグメント数により性能が相異なる予め用意された複数のデフラグメントアルゴリズムのうちから、前記デフラグメント部が前記データフレームをデフラグメントする際に使用させるものを、前記データフレームに係るフラグメント数に応じて選択して、前記デフラグメント部に指示する制御部とを備えたことを特徴とする映像受信クライアント。
2. 前記制御部は、前記デフラグメント部によりデフラグメントされた前記データフレームが幾つのパケットにフラグメントされていたかを観察し、ある有限時間内において受信された前記映像ストリームを構成する複数の前記データフレームのフラグメント数の平均値を計算し、算出された該平均値に基づいて、前記複数のデフラグメントアルゴリズムのうちから、適切なデフラグメントアルゴリズムを選択することを特徴とする請求項１に記載の映像受信クライアント。
3. 前記制御部は、前記デフラグメント部によりデフラグメントされた前記データフレームが幾つのパケットにフラグメントされていたかを観察し、この観察の結果に基づいて、フラグメント数のシーケンスパターンを予測し、予測された該シーケンスパターンに基づいて、前記複数のデフラグメントアルゴリズムのうちから、適切なデフラグメントアルゴリズムを選択することを特徴とする請求項１に記載の映像受信クライアント。
4. 前記映像配信サーバから、フラグメント数のシーケンスパターンを示す情報を受信する情報受信部を更に備え、
   前記制御部は、受信された前記シーケンスパターンに基づいて、前記複数のデフラグメントアルゴリズムのうちから、適切なデフラグメントアルゴリズムを選択することを特徴とする請求項１に記載の映像受信クライアント。
5. 前記映像ストリームを構成する前記パケットには、前記フラグメント数に関連する情報が重畳されており、
   前記パケット受信部は、受信した前記パケットから、前記フラグメント数に関連する情報を抽出し、
   前記制御部は、抽出された前記フラグメント数に関連する情報に基づいて、前記複数のデフラグメントアルゴリズムのうちから、適切なデフラグメントアルゴリズムを選択することを特徴とする請求項１に記載の映像受信クライアント。
6. 前記複数のデフラグメントアルゴリズムを保持するプール部を更に備え、
   前記制御部は、前記プール部に保持されている前記複数のデフラグメントアルゴリズムのうちから、前記デフラグメント部が前記データフレームをデフラグメントする際に使用させるものを選択し、
   前記デフラグメント部は、前記プール部に保持されている前記複数のデフラグメントアルゴリズムのうち、前記制御部から指示されたものを使用することを特徴とする請求項１ないし５のいずれか１項に記載の映像受信クライアント。
7. 前記複数のデフラグメントアルゴリズムは、第１のデフラグメントアルゴリズムと第２のデフラグメントアルゴリズムとの二つのデフラグメントアルゴリズムであり、
   前記第１のデフラグメントアルゴリズムは、前記フラグメント数が基準値以上である場合に、前記第２のデフラグメントアルゴリズムより性能が良いものであり、
   前記第２のデフラグメントアルゴリズムは、前記フラグメント数が前記基準値未満である場合に、前記第１のデフラグメントアルゴリズムより性能が良いものであり、
   前記制御部は、前記フラグメント数が基準値以上である場合に、前記第１のデフラグメントアルゴリズムを選択し、前記フラグメント数が前記基準値未満である場合に、前記第２のデフラグメントアルゴリズムを選択するものであることを特徴とする請求項１ないし６のいずれか１項に記載の映像受信クライアント。
8. 前記データフレームは、エンコードされたデータであり、
   前記映像受信クライアントは、前記データフレームをデコードするデコード部を更に備えたことを特徴とする請求項１ないし７のいずれか１項に記載の映像受信クライアント。
9. 前記データフレームを表示する表示部を更に備えたことを特徴とする請求項８に記載の映像受信クライアント。
10. 映像ストリームを構成する複数のデータフレームをそれぞれ１つ以上のパケットにフラグメントして、ネットワークを介して映像受信クライアントへ送信する映像配信サーバであって、
    各々の前記データフレームにつき、当該データフレームをそれぞれ１つ以上のパケットにフラグメントするフラグメント部と、
    前記パケットを送信する送信部と、
    前記映像受信クライアントが前記データフレームをデフラグメントする際に使用するデフラグメントアルゴリズムを、フラグメント数により性能が相異なる予め用意された複数のデフラグメントアルゴリズムのうちから選択するにあたって、該選択の基準となる情報を、前記映像受信クライアントへ与えるための制御を行う制御部とを備えたことを特徴とする映像配信サーバ。
11. 前記制御部は、前記映像ストリームを構成する複数のデータフレームに関係するフラグメント数のシーケンスパターンを示す情報を、前記送信部から前記映像受信クライアントへ送信させることを特徴とする請求項１０に記載の映像配信サーバ。
12. 前記制御部は、前記パケットのそれぞれに、当該パケットに係る前記デフラグメントの際に使用するデフラグメントアルゴリズムを指示する情報を付与することを特徴とする請求項１０に記載の映像配信サーバ。
13. 映像ストリームを構成する複数のデータフレームをそれぞれ１つ以上のパケットにフラグメントして送信する映像配信サーバから、ネットワークを介して、該パケットを受信する映像受信クライアントの受信アルゴリズム切替制御方法であって、
    前記映像受信クライアントの備えるパケット受信部が、前記パケットを受信するステップと、
    前記映像受信クライアントの備えるデフラグメント部が、各々の前記データフレームにつき、当該データフレームのもととなる前記パケットをもとに、当該データフレームをデフラグメントするステップと、
    前記映像受信クライアントの備える制御部が、フラグメント数により性能が相異なる予め用意された複数のデフラグメントアルゴリズムのうちから、前記デフラグメント部が前記データフレームをデフラグメントする際に使用させるものを、前記データフレームに係るフラグメント数に応じて選択して、前記デフラグメント部に指示するステップとを有することを特徴とする受信アルゴリズム切替制御方法。
14. 映像ストリームを構成する複数のデータフレームをそれぞれ１つ以上のパケットにフラグメントして、ネットワークを介して映像受信クライアントへ送信する映像配信サーバの受信アルゴリズム切替制御方法であって、
    前記映像配信サーバの備えるフラグメント部が、各々の前記データフレームにつき、当該データフレームをそれぞれ１つ以上のパケットにフラグメントするステップと、
    前記映像配信サーバの備える送信部が、前記パケットを送信するステップと、
    前記映像配信サーバの備える制御部が、前記映像受信クライアントが前記データフレームをデフラグメントする際に使用するデフラグメントアルゴリズムを、フラグメント数により性能が相異なる予め用意された複数のデフラグメントアルゴリズムのうちから選択するにあたって、該選択の基準となる情報を、前記映像受信クライアントへ与えるための制御を行うステップとを有することを特徴とする受信アルゴリズム切替制御方法。
15. 映像ストリームを構成する複数のデータフレームをそれぞれ１つ以上のパケットにフラグメントして送信する映像配信サーバから、ネットワークを介して、該パケットを受信する映像受信クライアントとしてコンピュータを機能させるためのプログラムであって、
    前記パケットを受信するパケット受信部と、
    各々の前記データフレームにつき、当該データフレームのもととなる前記パケットをもとに、当該データフレームをデフラグメントするデフラグメント部と、
    フラグメント数により性能が相異なる予め用意された複数のデフラグメントアルゴリズムのうちから、前記デフラグメント部が前記データフレームをデフラグメントする際に使用させるものを、前記データフレームに係るフラグメント数に応じて選択して、前記デフラグメント部に指示する制御部とをコンピュータに機能させるためのプログラム。
16. 映像ストリームを構成する複数のデータフレームをそれぞれ１つ以上のパケットにフラグメントして、ネットワークを介して映像受信クライアントへ送信する映像配信サーバとしてコンピュータを機能させるためのプログラムであって、
    各々の前記データフレームにつき、当該データフレームをそれぞれ１つ以上のパケットにフラグメントするフラグメント部と、
    前記パケットを送信する送信部と、
    前記映像受信クライアントが前記データフレームをデフラグメントする際に使用するデフラグメントアルゴリズムを、フラグメント数により性能が相異なる予め用意された複数のデフラグメントアルゴリズムのうちから選択するにあたって、該選択の基準となる情報を、前記映像受信クライアントへ与えるための制御を行う制御部とをコンピュータに機能させるためのプログラム。

Images