(57)【特許請求の範囲】
【請求項１】
データストリーミング装置であって、
（ａ）  階層形のコード化アルゴリズムによってコード化されたデータフレームを受取るデータ入力部と、
（ｂ）  受取ったコード化データフレームを１つまたは複数の所定のパケット構造に挿入するためのパケット化手段であって、前記データフレームは、異なる各パケットシーケンスに挿入される各コード化層に関連するパケット化手段と、
（ｃ）  生成されたパケットを使用にあたって送信するためのネットワークインタフェースと、を具備し、
（ｄ）  前記パケット化手段によって生成された各パケットに対してデータシーケンス番号を割り当てるためのパケット番号付け手段であって、前記パケットに割り当てられたデータシーケンス番号は、前記パケット内に挿入されたコード化データの、前記データ入力における受け取り順序を示しているパケット番号付け手段を有し、
前記ネットワークインタフェースは前記割り当てられたデータシーケンス番号を使用にあたって前記パケットとともに伝送するように構成されていることを特徴とするデータストリーミング装置。
【請求項２】
前記パケット番号付け手段は、前記パケット化手段によって生成された各パケットに対して別のシーケンス番号を割り当てるように構成され、前記別のシーケンス番号は、前記パケットシーケンス内における前記パケットの位置を示すものである請求項１記載のデータストリーミング装置。
【請求項３】
階層形のコード化アルゴリズムによってコード化されたデータフレームを通信ネットワークを介して伝送する方法であって、
（ａ）符号化データフレームを受信するステップと、
（ｂ）データを前記符号化データフレームから所定のパケット構造にしたがって生成されたデータパケットに挿入するステップであって、複数の層の各々からのデータはデータパケットの個々にアクセス可能な複数のシーケンスの１つに挿入されるステップと、
（ｃ）前記データパケットを伝送するステップと、を具備し、
（ｄ）データシーケンス番号を各データパケットに割り当てるステップであって、前記データシーケンス番号は、デコーダに対する前記フレームの次の呈示に対して要求された順番を示しているステップと、
（ｅ）前記シーケンス番号を前記データパケットとともに伝送するステップと、を有することを特徴とする方法。
【請求項４】
前記階層形のコード化アルゴリズムは、サンプリングされる順番ではなく復号される順番でビデオフレームを出力するビデオコード化アルゴリズムである請求項３記載の方法。
【請求項５】
ステップ（ｄ）は、各データパケットに別のシーケンス番号を割り当てることを含み、各パケットシーケンスに対して割り当てられる前記別のシーケンス番号は、前記パケットシーケンス内のデータパケットの伝送順番を示し、ステップ（ｅ）は前記別のシーケンス番号を伝送することを含む請求項３または４に記載の方法。
【請求項６】
前記個々にアクセスされる複数のデータパケットシーケンスのうち少なくとも２つに関して前記データパケットを受取ることをさらに含む請求項３，４または５記載の方法。
【請求項７】
通信ネットワークを介して受取られたデータパケットの複数の個々にアクセス可能なシーケンス内で受信されたデータパケットを順序付ける方法であって、データパケットの各シーケンスは、階層形のコード化アルゴリズムによって出力されたコード化データフレームの異なる層に関連するデータフレームを移送し、各データパケットは、該データパケットに割り当てられ、前記コード化アルゴリズムから前記データパケットによって伝送されたコード化データの出力の順番を示すデータシーケンス番号と、データパケットの各シーケンス内における前記データパケットの位置を示す別のシーケンス番号と、を有し、
前記方法は、データパケットの前記アクセス可能なシーケンスの第１のシーケンス内で別のシーケンス番号の順番でデータパケットを選択することと、割り当てられたデータシーケンス番号の順番で前記第１のシーケンスから選択されたパケットを出力することと、
シーケンス以外のデータシーケンス番号をもつ前記第１のシーケンスからのパケットを選択したときに、データシーケンス番号にしたがって、次の予期されるパケットに対する前記個々にアクセス可能な他のシーケンスを探索すること、とを具備する方法。
【発明の詳細な説明】
【０００１】
発明の属する技術分野
本発明は、通信ネットワーク上でのデータ伝送、とくに階層形のコード化アルゴリズムによってコード化されるデータ伝送に関する。
【０００２】
従来の技術
インターネットプロトコル（Internet Protocol, IP）に基くネットワークを使用して、マルチメディアデータを移送することが増えてきている。しかしながら克服されるべき問題として、マルチメディアサービス、例えばオーディオビジュアルサービスに対して種々の異なる受信能力をもつ多数のクライアント端末へのこのようなサービスの配信を実現することが残っている。とくに、一部のクライアントは、低解像度および低画像レートのビデオのみを受取ることができる、データレートを制限したネットワーク接続のみにアクセス可能である。他のユーザは、比較的に広バンド幅の共同形のＬＡＮに接続され、より高品質の受取りを要求することができる。異なるレベルのサービスを異なるユーザへ供給する既知の方法には、個別仕様形のセッションが各ユーザのネットワークアドレスへ直接に送られる二地点間サービスと、多数の異なるデータレート伝送が同報通信される“同時放送（simulcast）”技術とを含み、ユーザは最も必要に適したものを選定および共有することができる。しかしながら二地点間サービスおよび同時放送技術の両方は、送られたデータ流間に相当なオーバーラップおよび複製を含んでしまい、ネットワーク容量の使用量は明らかに不十分である。
【０００３】
例えば、ビデオデータ圧縮に対するH.263規格のもとで実行される階層形（レイヤード）のコード化技術は、文献（“Video Coding for Low Bit Rate Communications”, International Telecommunication Union (ITU)−T Recommendation H.263）において規定されており、ビデオの異なる解像度を表わすデータをデータフレームの別個の層（レイヤ）としてコード化することができる。最も低い層、すなわち層０において“最低共通種目（lowest common denomination）”のコード化を行うことができる。層０内のフレームは、必ずしも原画像の全てではないが、原画像に比較的低い解像度を与えることができる。より高い層のデータフレームは、より低い層のフレームによる表示に対してより高いレベルの詳細を加えるか、またはより低い層から省かれた画像を一緒にコード化してもよい。コード化されたデータフレームの各層はサーバによって各層に対するマルチキャスティングネットワークアドレスに個々に同報通信することができる。大抵のユーザ装置は、最も低い層０の適切なマルチキャストアドレスにアクセスすることによって層０を受取ることができることを意図される。このような選択をするユーザ、すなわちより高い層を受取ることができる装置をもつユーザは、対応するネットワークアドレスにアクセスして、より高い品質のオーディオビジュアルサービスを受けることができる。このやり方では、異なるクライアントの必要は、データを不必要に複製せずに各層の単一の同報通信によって満たされる。
【０００４】
マルチキャスティング技術をＩＰネットワークに関連して使用するとき、コード化されたデータフレームのトランスポート層における現在選択されているプロトコルはユーザデータグラムプロトコル（User Datagram Protocol (UDP)）であり、ＵＤＰは文献（“User Datagram Protocol”,Internet RFC 768, J.Postel, August 1980, published on the Internet by the Internet Engineering Task Force (IETF)）に規定されている。しかしながらＵＤＰは、例えば伝送制御プロトコル（Transmission Control Protocol (TCP)）と比較して、最小のプロトコル機構を使用してメッセージを送信するより迅速な手続きを与えるが、これは保証された配信を犠牲にすることによって達成される。おそらくは１つの層をネットワーク上を移送中に失なわれるか、または少なくとも他の層よりも遅延してしまうときに、データを失ってしまうことがある。したがって、コード化されたデータのより高い層を受取らない選択をとることに加えて、クライアントの装置が制限を受けることによって、セッション中に同報通信された全てのコード化されたデータを受取らない不本意な理由がある。両方の環境では、クライアント装置において受取ったデータをデコードするために正しい順序でデコーダへ送る際に問題が生じることがあるからである。
Jau-Shiung Huang、他による文献（“MHTP−A Multimedia High−Speed Transport Protocol”, from GLOBECOM ’92, Orlando−Communication for Global Users, Dec 6−9, 1992, Volume 3, 6 December 1992, pages 1364−1368, XP000390432 IEEE）に記載されているプロトコル（ＭＨＴＰ）では、使用可能ないくつかのサブプロトコルの各々の中でパケットのシーケンス番号付けおよびパケット順序付けを管理して、多層のコード化されたデータの個々の層を移送することができる。しかしながらＨＴＭＰは、いくつかのサブプロトコル層から選定された、受取られたパケットをデコーダへデコードするための正しい順序でどのように送るかについての問題を解決していない。
Wilson, D.およびGhanbari, M.による文献（“An Efficient Loss-Priority Scheme for MPEG-2 Variable Bit Rate Video for ATM Networks”, IEEE 1996, Essex University）では、伝送中に維持されるベース層と、エンハンスメント層との正しい関係の（相対的な）タイミングに依存してはいるが、Ｂ−フレームのみを含むエンハンスメント層（レイヤ）を生成し、コード化されたフレームをデコーダへ送る正しい順序を保証する技術を記載している。例えば、ベース層から最初にコード化されるフレームとンハンスメント層から最初にコード化されるフレームとをそれぞれ受取る予測される遅延差はデコーディング前に修正することができない。
文献（Internet RFC 1693: “An Extension to TCP: Partial Order Service” November 1994）では、ＴＣＰを拡張して、接続設定中にサービスプロフィールを送り、送られたオブジェクトを受取る際の許容可能な順序を規定することが記載されている。サービスプロフィールには、番号を付されたオブジェクトの許容可能な順序を規定する部分的な順序付け用マトリックスを含み、ある種のオブジェクトの受取りの際の損失、または過度な遅延があっても、受信機がこのようなオブジェクトをプロフィールにおいて規定された範囲内で順序付けることができるようにする。しかしながら、データを送る前に、サービスプロフィールを規定して、伝送するオーバーヘッドは、送受信装置の複雑さを増し、遅延を追加してしまう。
【０００５】
発明が解決しようとする課題
本発明の第１の態様にしたがって、データストリーミング装置であって：
階層形のコード化アルゴリズムによってコード化されるデータフレームを受取るデータ入力と；
受取ったデータフレームをコード化して所定のパケット構造に挿入し、各コード化された層と関係するデータフレームが異なる各パケットシーケンスへ挿入されるパケット化手段と；
パケット内に挿入されたコード化されたデータの、データ入力における受取り順序を示す、パケットに割り当てられたデータシーケンス番号を、パケット化手段によって生成される各パケットへ割り当てるパケット番号付け手段と；
使用の際に、このように生成されたパケットを伝送するネットワークインターフェイスとをもつデータストリーミング装置を提供する。
【０００６】
本発明は、シーケンス番号をコード化されたデータを移送する各データパケットへ割り当てることができ、このシーケンス番号はコード化されたデータについての後の呈示のための正しい順序を表わしており、デコーダへ向けて送られる。クライアント装置が伝送された層のパケットの全てを受取らないときでも、または個々のパケットを失ってしまったときでも、このようなシーケンス番号によって、クライアント装置において受取られたパケットを正しく順序付けることができる。これは、H.263規格によって規定される異なるコード化アルゴリズムを使用するときにとくに重要である。
【０００７】
Ｈ．２６３を実行する異なるエンコーダは、各々が相当に異なるデータレートをもつ階層形のデータ流を生成する。画像のシーケンスの各々をコード化するのに要求されるデータ品質は、連続する画像間の変度にしたがって異なる。一般的にエンコーダによるコード化されたフレームの出力の順序は、デコーダへの入力に要求される順序である。しかしながらエンコーダからデコーダへの伝送中に、一方の層が失われるか、または他方の層に対して著しく遅延するか、あるいは特定のパケットが失われるときには、受信装置において受取ったデータパケットを正しいデコーディング順序でデコーダへ送る際に問題が生じる。したがって、多層形のコード化を使用することによって、異なるクライアントの必要に適応する問題を解決すると考えられるが、多層形の伝送をデコードするときに新しい問題が生じる。
【０００８】
コード化されたデータフレームの特定の層を移送するパケットのシーケンス内で、選定されたプロトコルの制御のもとで、パケットの伝送順序を表わす別のシーケンス番号を各パケットに割り当てることができることが好ましい。このようなシーケンス番号を使用して、特定のパケットシーケンス内で期待される全てのパケットを受取り、次にデコードするパケットを別のパケットシーケンス内に位置していなければならないか否かを識別することによってパケットの順序付けの効率を向上することができる。
【０００９】
本発明の第２の態様にしたがって、クライアント装置であって：
ネットワークインターフェイスと；
ネットワークインターフェイスからデータパケットのシーケンスを受取るパケット受取り手段であって、各データパケットは所定のパケット構造をもち、データパケットの前記シーケンスの各々は階層形のコード化アルゴリズムによって生成されるコード化されたデータフレームの異なる各層を移送し、各データパケットが、データパケットによって前記階層形のコード化アルゴリズムから移送されるコード化されたデータの出力順序を示すデータシーケンス番号をそれに割り当てたパケット受取り手段と；
前記受取られたデータパケットを前記データシーケンス番号を使用してデコーディング順に位置付けるパケット順序付け手段と；
このように順序付けられたパケットを出力する出力手段とをもつクライアント装置を提供する。
【００１０】
本発明の第３の態様にしたがって、通信ネットワーク上での伝送のための階層形のコード化アルゴリズムによってコード化されるデータフレームを移送するデータパケットを生成する方法であって、コード化されたデータフレームの各層はデータパケットの異なる各シーケンスによって移送され：
（１）コード化されたデータフレームを受取る段階と；
（２）前記データフレームから所定のパケット構造にしたがって生成されたデータパケットへデータを挿入する段階と；
（３）前記データパケットの１つに対して、前記パケットへ挿入されたコード化されたデータの受取り順序を示すデータシーケンス番号を割り当てる段階と；
（４）前記パケット内の所定の位置に前記データのシーケンス番号を書き込む段階と；
（５）段階（２）で生成された前記データパケットの各々に対して段階（３）および（４）を実行する段階とを含む方法を提供する。
【００１１】
本発明の第４の態様にしたがって、請求項５の方法にしたがって生成されたデータパケットの個々にアクセス可能なシーケンス内で受取られるデータパケットを順序付ける方法であって：
（１）前記データパケットの個々にアクセス可能なシーケンス上でデータパケットを受取る段階と；
（２）段階（１）で受取ったデータパケットから、選定されていないデータパケット間で割り当てられた最小のデータシーケンス番号をもつデータパケットを選定する段階と；
（３）前記選定されたデータパケットを出力する段階と；
（４）段階（１）ないし（３）を反復する段階とを含む方法を提供する。請求項５によると、次のように規定されている：通信ネットワーク上での伝送のための階層形のコード化アルゴリズムによってコード化されるデータフレームを移送するデータパケットを生成する方法であって、コード化されたデータフレームの各層はデータパケットの異なる各シーケンスによって移送され：
（１）コード化されたデータフレームを受取る段階と；
（２）前記データフレームから所定のパケット構造にしたがって生成されたデータパケットへデータを挿入する段階と；
（３）前記データパケットの１つに対して、前記パケットへ挿入されたコード化されたデータの受取り順序を示すデータシーケンス番号を割り当てる段階と；
（４）前記パケット内の所定の位置に前記データのシーケンス番号を書き込む段階と；
（５）段階（２）で生成された前記データパケットの各々に対して段階（３）および（４）を実行する段階とを含む方法。
【００１２】
ここで本発明を添付の図面を参照して例示的にさらに詳しく記載することにする。
【００１３】
発明の実施の形態
ここでビデオストリーミング装置の特定のコンテキストにおいて本発明の好ましい実施形態を記載するが、本発明はデータを同報通信して受取る他の形態の装置に応用できるが、このような装置は必ずしもクライアント−サーバ構成内になくてもよく、単一または多数のマルチメディアセッションにおいて階層形のコード化技術によってコード化されるデータを関係付ける。
【００１４】
図１を参照すると、本発明の好ましい実施形態にしたがって、通信ネットワーク110上をコード化されたオーディオ／ビデオデータ源105からクライアントシステムへ多層形のコード化されたオーディオビジュアルデータを同報通信する際に使用するビデオストリーミング装置100が示されている。オーディオ／ビデオデータ源105は、例えば“ビデオ−オン−デマンド”システムで使用するコード化されたビデオデータのデータベースであるか、または生の同報通信として伝送される多層形のコード化された実時間オーディオビジュアルデータ流であってもよい。ビデオストリーミング装置100は、源105からコード化されたデータの層を入力115において受入れ、次にそれらをパケタイザ120へ送る。パケタイザ120は、所定のパケット構造にしたがってコード化されたデータの各層から異なる各パケット流へデータを個々に組入れる既知のアルゴリズムを実行することができる。例えば、実時間伝送プロトコル（Real-Time Transport Protocol (RTP)）で使用するために規定された構造をもつパケットへ層を組入れてもよく、これは文献（Internet Request for Comment (RFC) 1889, January  1996-“RTP: A Transport Protocol for Real-Time Applications” by H.Schulzrinne, S.Casner, R.Frederick and V.Jacobson）に記載され、インターネット技術標準化委員会（Internet Engineering Task Force (IETF)）によってインターネット上で公開されている。各所定のパケット構造にしたがって構成されると、パケットの層は、本発明の好ましい実施形態にしたがうパケット番号付け方法によって番号を付されるパケット番号付けモジュール125へ送られる。次に番号を付されたパケットは、セッションハンドラ130のインスタンスへ送られ、なお各パケット層ごとにセッションハンドラの１インスタンスがある。セッションハンドラ130の1インスタンスは適切なプロトコルを実行して、通信ネットワーク110上でネットワークインターフェイス135を介して所定のネットワークアドレス、例えばマルチキャストアドレスへのパケットの各層の移送を制御することができる。プロトコル階層においてより低いレベルで動作するプロトコルは通信ネットワーク110に適するようにネットワークインターフェイス135によって実行することができる。例えば、ＲＴＰより低いレベルでは、上述のユーザデータグラムプロトコル（User Datagram Protocol (UDP)）は、ネットワークインターフェイス135によって実行されて、インターネットプロトコル（Internet Pprotocol (IP)）に関係して動作することができる。
【００１５】
簡潔にするためには、コード化されたデータの全ての層は同じパケット構造を使用して同じプロトコルの各インスタンスの制御のもとで同報通信できることが好ましい。しかしながら本発明の技術的範囲では、１以上のタイプのプロトコルを使用して、入力115において受取ったコード化されたデータの層を同報通信する情況を含むことを意図している。
【００１６】
図２を参照すると、典型的なクライアント装置200は使用の際に、通信ネットワーク110上で、図１のビデオストリーミング装置100と共通する特徴をもつ源によってオーディオまたはビデオ、あるいはこの両者の同報通信を受取ることが示されている。クライアント装置200は、セッションハンドラ210の１インスタンスを生成し、セッションハンドラ210の各インスタンスは、特定のネットワークアドレスにおいて受取られるデータを“リスニング（listening）”し、１インスタンスはパケットの各層に対応し、ネットワーク上でネットワークインターフェイス205を介して受取られる。受取られたパケット層は、各セッションハンドラ210から源のデマルチプレクサ215へ送る。多数のビデオ流または他のタイプの源が同じセッションにおいて同報通信されているときに、各源は、各源ストリーマによってパケットヘッダへ挿入される情報を使用して、源デマルチプレクサ215によって個々に識別可能であることが好ましい。識別された各別個の源において、源デマルチプレクサは、ブレンダ220の１インスタンスを生成し、同じ源識別子を保持しているセッションハンドラ210を介して受取られる全てのパケットを関係付けて、関係付けられたパケットをブレンダ220へ送ることができる。ブレンダ220は、本発明の好ましい実施形態にしたがって、各源、例えばビデオストリーマ100のパケット番号付けモジュール125によって挿入されるパケット番号付け情報を使用して特定の源から受取られるパケットを順序付けるアルゴリズムを実行することができる。正しいパケット順序に設定して、失われているか、またはアクセス不可能な層およびパケットを検討すると、ブレンダ220は順序付けられたパケットをデパケタイザ225へ送って、特定のストリーミング源、例えばビデオストリーマ100の場合はパケタイザ120によって、使用される各所定のパケット構造からコード化されたデータ層を回復することができる。デパケタイザ225は、回復したコード化されたデータを、デコーディングのための正しいシーケンスで出力230へ送る。クライアント装置200から出力された順序付けられたデータは、適切なデコーダによって受取られ、デコーディング後に、ディスプレイまたはオーディオ出力装置、あるいはこの両者において適切に再生成される。
【００１７】
図３を参照すると、階層形のデータフレームの典型的な階層構造が示されており、ビデオストリーマ100の入力115へ送られるとき、ビデオ画像の短いシーケンスからコード化される。図示されているように、コード化されたフレーム340は３つの層300、305、および310として配置されており、それぞれは最下段層、中段層、および最上段層に対応している。別の層は、源105によって実行される特定のコード化アルゴリズムにしたがって生成することができる。図３の各コード化されたフレームは、１ないし１０の数字を付して示されており、この数字はコード化されたデータ源105による出力順序、したがってデコーダに対してフレームを次に表示するのに要求される順序を示す。図３のフレーム340は５つのカラムに纏められ、フレームの各カラムは各原画像315ないし335を表わすようにコード化される。例えば、図示されているように、原画像“Ａ”315は最下段層300ではフレーム番号“１”、中段層305ではフレーム番号“２”、および最上段層310ではフレーム“３”としてコード化される。原画像“Ｂ”320は番号“４”で生成されたフレームによって最上段層310内でのみ表示される。原画像データ315ないし335は通常はビデオストリーミング装置100の入力115へ送られない。
【００１８】
図３のコード化されたフレームのシーケンスは、例えば上述のＨ．２６３のようなビデオコード化アルゴリズムにしたがって生成することができる。Ｈ．２６３のコード化技術を使用して、図３の画像315ないし335をコード化するとき、各最下段層300内の各フレーム340は低解像度の各原画像を表わし、参考用明細書のセクション４．１に記載されているように、ＱＣＩＦ解像度で基本的なＨ．２６３アルゴリズムを使用してコード化することができる。層305および310におけるフレームは、層300における各フレームによって表わされる低解像度画像に対してより詳しく向上して表わしている。Ｈ．２６３のもとでは、中段および最上段の層は、上述のＨ．２６３の規格の添付書類０（Annex 0、“Temporal, SNR and Spatial Scalability Mode”）の規定にしたがってコード化することができる。
【００１９】
原画像の全てを最下段層300、305に表示できるわけではない。図３に示した特定のシーケンスにおいて、原画像の４つに１つのみが最下段層300に、原画像の２つに１つが中段層305に表示される。したがってフレームの最下段層のみをデコードできるか、またはデコードすることを選択したクライアント装置は、最下段層および中段層の両者をデコードできるか、またはデコードすることを選択するクライアント装置と比較して、比較的に低い解像度および画像レートの原画像のシーケンスを表示する。３つの同報通信層300ないし310の全てを受取り、デコードできる装置は、最高有効解像度で原画像（315ないし335）の全てを表示することができる。より低いデータレートのネットワーク接続を使用して、最下段層においてデータフレームを受取ることができ、大抵のクライアント装置がこの最下段層をアクセスできるようにすることが意図されている。
【００２０】
図４を参照すると、ダイヤグラムではパケタイザ120によって形成されたパケット400の対応する階層形のシーケンスにおいて、図３の第１の３つの原画像315、320、および325を表わしているコード化されたフレーム340の典型的な分解図を示している。図４はさらに、本発明の好ましい実施形態にしたがってパケット番号付けモジュール125によって実行できるパケット番号付け方式をこのパケットへ適用した結果を示している。典型的なパケタイザ120は、コード化されたフレームの各層をそれぞれパケット化するように動作することができ、この例では、パケットの３つの別個の流れを各層に１つの流れの割合で生成する。図１に関係してすでに記載したように、パケタイザ120はセッションレベルで選択された特定のプロトコルに適したパケット構造を構成して、各コード化されたデータ層の移送を制御するようにすることができる。コード化されたデータの各層は、上述の実時間伝送プロトコル（ＲＴＰ）のそれぞれ異なるインスタンスを使用してネットワーク上で移送できることが好ましい。パケタイザ120は、この場合は、ＲＴＰパケット構造規定にしたがって、ＲＴＰパケットのシーケンスのペイロード部分においてコード化されたフレーム340の層内でデータを分割する。上述のＨ．２６３アルゴリズムを使用してコード化されたデータをパケット化するとき、Ｈ．２６３ぺーロードヘッダの特定の規定ではＲＴＰパケットを含むことができる（文献（“RTP Payload Format for H.263 Video Streams”, Internet RFC 2190, September 1997, published on the Internet by the IETF）参照）。代わりの、等しく満足を与えるセッションレベルのプロトコルでは、パケタイザ120による実行を選定し、それ自身の各パケット構造を使用して、データフレーム340のコード化された層300ないし310を移送することができる。
【００２１】
図４を参照すると、既に記載したように、パケット400の各々はパケット番号付けモジュール125によって適用されるシーケンス番号で分類して示されている。番号付けの好ましい方法は、各パケット400に２つのシーケンス番号を割り当てることを含む。図４の各パケットの上半分に示された番号は、“層シーケンス番号（layer sequence number）”ＬＳＥＱと呼ばれ、各パケットの下半分に示された番号は“交差層シーケンス番号(cross-layer sequences number)”ＸＳＥＱと呼ばれる。ＬＳＥＱ番号のシーケンスは、１つの特定の層内におけるパケット伝送の順序を示す。ＸＳＥＱ番号は、クライアント装置200においてデコーダ225へパケットによって移送されたコード化されたデータの全体的な正しい表示順序を表わすことを意図されている。ＸＳＥＱシーケンスは、とくに源105から現れるコード化されたデータフレームの順序を反映している。
【００２２】
ＲＴＰのようなプロトコルは、特定のパケット流内でパケットにシーケンス番号を割り当てる機能を用意している。この場合に、コード化されたデータの各層は異なるＲＴＰセッションの制御のもとで別個のＲＴＰパケット流として同報通信される。したがって１つの層内で、各（ＲＴＰ）セッションハンドラ130は伝送前に層のシーケンス番号ＬＳＥＱを各パケットへ自動的に割り当て、パケットの所定の位置にシーケンス番号を書込む。他のタイプのプロトコルでは、このような層のシーケンス番号割当て機能を用意していなくてもよい。したがって、パケット番号付けモジュール125は、層のシーケンス番号の割当てと交差層のシーケンス番号の割当ての両者を必要なときに実行することができる。
【００２３】
異なる層は一般的に、ＲＴＰのような別個のプロトコルセッションの制御のもとで同報通信され、層にＸＳＥＱ番号を割り当てる全体的な機構はない。とくにＸＳＥＱのシーケンス番号を割り当てるために、パケット番号付けモジュール125は、パケタイザ120の直後および個々のパケット流の直前の点に用意され、番号を付されたパケットは、各セッションハンドラ130へ進み、同報通信される。必要であれば、パケタイザ120から出力されるパケットにＸＳＥＱ番号を正しく割り当てるために、パケット番号付けモジュール125は、入力115におけるコード化されたデータフレームの受取り順序情報へのアクセスを保持してもよい、。これは、例えばＨ．２６３によって規定されているような異なるコード化アルゴリズムを使用してデータをコード化し、次にこのデータを正しい順序でデコードするときにとくに重要である。パケット番号付けモジュール125によるＸＳＥＱ番号の割当ては、パケットレベルにおける正しいデータシーケンスを記録するとくに好都合な方法を与える。データの損失およびデータの記録は通常はパケットレベルで行われる。つぎに記載するように、層のシーケンス番号ＬＳＥＱ、およびとくにクロス層のシーケンス番号ＸＳＥＱの記録から、クライアント装置200が本発明の好ましい実施形態にしたがって、シーケンスから外れて受取られたパケットを再び順序付けること、および失われているパケット、および失われているかまたはアクセス不可能なコード化されたデータ層を考慮に入れることができるようになる。
【００２４】
図５および６を参照すると、ＲＴＰのもとで使用するために規定されたパケットヘッダ構造が示されている。本発明の好ましい実施形態ではＲＴＰパケット構造を使用して、パケットのシーケンス番号を記録することができる。図５は、オプションのＲＴＰヘッダ拡張子を含むＲＴＰヘッダ構造を示し、図６はヘッダ拡張子自体の構造を示しており、図５および６の全ての詳細は上述のＲＴＰ規定文書によって記載されている。図５のＲＴＰパケットヘッダは第３および第４のオクテットを占めるシーケンス番号フィールドを含む。このフィールドはＲＴＰプロトコル内で使用されて、特定のパケット流内のパケットの伝送順序を記録し、したがって層のシーケンス番号ＬＳＥＱの役割を果たす。
【００２５】
交差層のシーケンス番号ＸＳＥＱを収容するために、パケット番号付けモジュール125は、図５において“寄与源（Contributing Source, CSRC）識別子”の直後の位置に示したオプションのＲＴＰヘッダ拡張子を使用することが好ましい。この目的において、パケタイザ120は拡張子ビット“Ｘ”−すなわちＲＴＰヘッダについてビット４に設定し−各生成されたパケット内に図６に示した構造をもつ１つのＲＴＰパケットヘッダ拡張子を含んでもよい。各パケット内において、パケタイザ120はヘッダ拡張子の“プロフィール”フィールド内の独特のプロフィールに特定の識別子を記録し、１つの３２ビット“ヘッダ拡張子”フィールドを含む“長さ”フィールドを１に設定することができる。このような拡張子フィールドの長さは、一般的なマルチメディアセッション内で生成されたＸＳＥＱ番号を記録する際に使用するのに適している。したがってパケット番号付けモジュール125は適切なＸＳＥＱ番号を、パケタイザ120から受取られた各パケットの拡張フィールドへ書込むことができる。
【００２６】
ＲＴＰパケット構造は割り当てられたシーケンス番号を記録するのに適したフィールドを含んでいるが、他のプロトコルおよびパケット構造は、シーケンス番号情報を保持するパケット内に所定の位置を用意していなくてもよい。必要であれば、別のパケットデータ流をパケタイザ120によって生成し、他のパケット流とほぼ同期して伝送して、パケット番号付けモジュール125によって割当てられ、かつ例えばパケット識別子によって、コード化されたデータを保持するパケットにリンクされたシーケンス番号付け情報を移送することが必要である。“シーケンス番号パケット流”を受取ると、クライアント装置は、次に記載するのとほぼ同じやり方でシーケンス番号付け情報を抽出して使用することができる。
【００２７】
クライアント装置200の源マルチプレクサ215による伝送源の識別に関連して既に記載したように、例えば多数のビデオストリーマ100は通信ネットワーク110上でＲＴＰパケットを伝送するとき、図５のＲＴＰヘッダ内の“ＳＳＲＣ”フィールドはＲＴＰセッションハンドラ130によって使用されて、各ＲＴＰパケット内でパケットを生成する特定のビデオストリーマ100の識別子を記録することができる。したがってクライアント装置200の源デマルチプレクサ215は受取ったパケット内のＳＳＲＣフィールドを読み取り、1つのビデオストリーマと別のビデオストリーマとを区別することができる。
【００２８】
図７を参照すると、本発明の好ましい実施形態にしたがってパケット番号付けモジュール125によって番号を付された、特定のストリーマ100から受取られたパケットの順序に関係するブレンダ220のインスタンスの一連の動作段階を示すフローチャートが記載されている。変数“TOP LAYER”は、特定のクライアント装置200内の所定の値に設定して、選択によって、あるいは装置の能力またはネットワーク接続のバンド幅によって制限されるように、特定の装置が受取って、デコードするように設定されている最大の番号を付された層を記録することが好ましい。“TOP LAYER”の値を０ないしｎの範囲内に設定し、ｎをネットワーク110上でアクセス可能なデータストリーミング源によって送られる最大の番号を付された層としてもよい。
【００２９】
図７を参照すると、ブレンダ220による処理は、段階600で始まることが分かる。段階602では、既に受け取ったパケットに対して予備処理段階を実行し、各層内の層のシーケンス番号（ＬＳＥＱ）の順序にパケットを位置付ける。ＬＳＥＱ番号によるパケットの順序付けは、既知の簡単な順序付けアルゴリズムによって実行され、したがって段階602については本明細書ではさらに詳しく記載しないことにする。
【００３０】
段階605では、ブレンダ220は層０（ＰＴＫ[０]）上の最初に受取ったパケットを読み取り、このパケット内に含まれている層のシーケンス番号（ＬＳＥＱ）および交差層のシーケンス番号（ＸＳＥＱ）を使用し、パケット番号付けシーケンスの各々において次に予測される番号を判断する際に使用するカウンタＬＰＲＯＧ[  ]およびＸＰＲＯＧをそれぞれ初期設定する。段階610では、変数を初期設定して、最初に現在選定されている層、すなわち層０からパケットを処理する用意ができる。段階615では、現在処理されている層（Ｌ）（最初は層Ｌ＝０）から最小の層のシーケンス番号（ＬＳＥＱ）をもつパケットを読み取ることが試行される。段階602の実行時間内で既に受取られたパケットは層のシーケンス番号によって順序付けられ、既に受取ったパケット間では、層Ｌから読み取られた次のパケットは最小のＬＳＥＱ番号をもつと仮定することができる。段階620においてパケットが層Ｌ内で使用可能であるとき、段階625においてこのパケット内の交差層のシーケンス番号（ＸＳＥＱ）は次に予測される交差層のシーケンス番号と比較される。段階625において現在のパケットが交差層シーケンス内の次のパケットであるとき、段階660において現在のパケットのシーケンス番号を使用して、ＸＰＲＯＧおよびＬＰＲＯＧ[Ｌ]カウンタ変数を設定し、次に段階665においてパケットをデコーダ225へ送る。
【００３１】
段階620において現在の層上に使用可能なパケットがないときは、段階675においてパケットが層上で使用可能であることを示すフラグを設定し
段階640において処理を進め、パケット検索においてより高い層にアクセスできるようにする。
【００３２】
段階625において、現在のパケットが交差層シーケンス内の次のパケットでないときは、次の予測されるパケットは現在の層内から失われているか、または別の層内に位置している。一連の段階中の次の段階では、次にデコードすると予測されるパケットが現在の層内で現在失われている−おそらくは遅延されているか否かを設定する試行をする。したがって段階630ではブレンダ220は最初に、現在のパケットが現在の層（Ｌ）内で次に予測されるパケットであるか否かを検査する。次に予測されるパケットでないときは、段階670において、現在のパケットが層内のシーケンスから外れていることを示すフラグを設定し、続いて段階635で処理を行う。段階630において現在のパケットが層内の次に予測されるパケットであるとき、次に予測されるＸＳＥＱ番号をもつパケットは別の層内に位置していなければならない。しかしながら（段階670から）パケットがクライアント装置200によってアクセス可能な層内にないか、またはさもなければ失われていることが直ぐに分かるとき、段階635において最小の最近発生したＸＳＥＱ番号を記録する変数は、各パケットが存在する層と一緒に更新される。これは、次に予測されるＸＳＥＱ番号をもつパケットがアクセス可能な層内に位置していないときに処理の継続点になる。しかし、最初に他のアクセス可能な層が調べられる。
【００３３】
層の番号は段階640においてインクリメントされる。新しい現在の層が、段階645においてクライアント装置にアクセス可能な最も高い層か、またはそれよりも低い層であるときは、処理は段階615に戻って、次に予測されるパケットは上述のようにその層内で得られる。しかしながら段階645では新しい現在の層にアクセスできないとき、段階650では層上でパケットが現在使用不可能であるか否かを判断する検査を行う。段階650において層が受取ったパケットの中で使用可能なパケットをもたないとき、段階610において処理を再開し、次に予測されるパケットを層０から再び検索し始める。段階650において全ての層が使用可能な少なくとも１つのパケットをもつとき、段階652において現在のパケットが次の層内の次に予測されるパケットであるか否かを判断する。段階652では、現在のパケットが層内に正しく順序付けられるとき、ＸＳＥＱの順序で次に予測されるパケットは、特定のクライアント装置200がアクセスできないより高い層内に位置していなければならない。したがって、達成できることはせいぜい、層上の最小のＸＳＥＱ番号をもつパケットを選定することである。したがって、段階655では、最小のＸＳＥＱ番号を付されたパケットをもつ層が新しい現在の層として選定され、選定されたパケットは次にデコードするのに使用可能なパケットとして取扱われる。段階660においてＸＰＲＯＧおよびＬＰＲＯＧ[Ｌ]のシーケンス番号のカウンタは現在のパケット値にリセットされて、選定されたパケットは段階665においてデコードするために送られる。
【００３４】
段階652において現在のパケットがこの層内のシーケンスから外れているとき、段階680においてブレンダ220はオプションで次の１または２つのパケットが、例えばこの層に到達するのを待つことを選択することができ、この場合は層内の次に予測されるパケットが到達するか（この場合処理は段階610において再開する）、またはさらに遅延せずに段階685へ続き、最小のＸＳＥＱ番号を付されたパケットをもつ層を新しい現在の層として選定し、デコードするために次に使用可能なパケットとして、このパケットを選定するときは、段階660に処理を進める。
【００３５】
段階665においてデコードするためのパケットを送った後で、処理は段階610に戻り、シーケンスから外れた処理に関係する変数を、層番号Ｌないし０にリセットしてから、上述の処理を続ける。
【００３６】
より高度な処理段階では、段階652において層内の受取られたパケットがこの層内のシーケンスから外れている際に異なる方式を実行することを含んでもよいことが明らかである。通信ネットワーク110の性質、すなわち通信ネットワーク110においてパケットを転送することを選定されたプロトコルが、個々のパケットを層内で遅延できるものであるとき、予測されるパケットが送れて到達する可能性がある場合は、より高度な待機アルゴリズムを実行することが有益である。このような方式は図７の段階680において示したが、詳細には記載していない。その代わりに例えば純オーディオデータでは、失われたパケットの影響は、ギャップを残すか、またはさらに遅延する危険にさらすのではなく、直前のパケットの複製を挿入することによって部分的に克服することができる。選定されたエンコーディング／デコーディングアルゴリズムのもとで管理可能であるとき、同等の方式がコード化されたビデオデータにおいて得られる。
【００３７】
各層内のＬＳＥＱ番号によって受取られたデータパケットを順序付ける前処理を実行するのではなく、層内の受取られたデータパケットの順序と図７に示した段階605以降の処理段階を組合せたより高度なアルゴリズムを実行することが好ましい。
【図面の簡単な説明】
【図１】  本発明の好ましい実施形態にしたがうビデオストリーミング装置を示す図。
【図２】  図１の装置によって伝送される信号を受取るようにされているクライアント装置を示す図。
【図３】  図１の装置による伝送において、ビデオ画像の短いシーケンスからコード化される階層形データフレームの典型的な階層構造を示す図。
【図４】  本発明の好ましい実施形態にしたがって、パケット番号付けアルゴリズムを、図３に示したコード化されたデータフレームを移送するために生成されたパケットへ適用した結果を示す図。
【図５】  本発明の好ましい実施形態において使用される実時間伝送プロトコル（Real-time Transport Protocol (RTP)）にしたがってパケットヘッダの構造を示す図。
【図６】  本発明の好ましい実施形態において使用される実時間伝送プロトコル（Real-time Transport Protocol (RTP)）にしたがってパケットヘッダの構造を示す図。
【図７】  好ましいクライアント装置の動作段階を、とくに図１の装置によって同報通信されるパケットの順序付けに関係付けて示したフローチャート。
【図８】  好ましいクライアント装置の動作段階を、とくに図１の装置によって同報通信されるパケットの順序付けに関係付けて示したフローチャート。
【図１】
0004373012.tif 000002
【図２】
0004373012.tif 000003
【図３】
0004373012.tif 000004
【図４】
0004373012.tif 000005
【図５】
0004373012.tif 000006
【図６】
0004373012.tif 000007
【図７】
0004373012.tif 000008
【図８】
0004373012.tif 000009