JP4102223B2 - データ処理装置及びデータ処理方法 - Google Patents
データ処理装置及びデータ処理方法 Download PDFInfo
- Publication number
- JP4102223B2 JP4102223B2 JP2003062713A JP2003062713A JP4102223B2 JP 4102223 B2 JP4102223 B2 JP 4102223B2 JP 2003062713 A JP2003062713 A JP 2003062713A JP 2003062713 A JP2003062713 A JP 2003062713A JP 4102223 B2 JP4102223 B2 JP 4102223B2
- Authority
- JP
- Japan
- Prior art keywords
- time
- priority
- data
- information
- series data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Landscapes
- Compression Or Coding Systems Of Tv Signals (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Description
【発明の属する技術分野】
本発明は、通信及び放送の分野におけるデータ処理装置及びデータ処理方法に関する。
【0002】
【従来の技術】
従来より、自分が居る空間の風景の画像中から、例えば人物画像を抽出し、その画像と相手側から送られてきた人物画像と予め記憶されている相手側と共通的に表示する仮想的な空間の画像と重畳して表示することにより、相手が自分の前にいるという実在感を充足し、臨場感のある映像通信を目指したものがある(特公平4−24914号公報)。
【0003】
特に、従来の技術では画像合成を行うための高速化、メモリーを低減する方法に関する発明が行われている(例えば、特公平5−46592号公報:画像合成装置)。
【0004】
【発明が解決しようとする課題】
この様な従来の技術では、2次元の静止画や3次元のCGデータを合成する画像合成を利用した通信システムが提案されていたが、複数の動画や音声を同時に合成して表示させるシステムの実現方法について、下記の観点からの具体的な議論が行われていなかった。
【0005】
即ち、(A1)一つあるいは二つ以上の現実の伝送路上においてソフト的に構築される複数の論理的な伝送路を用いて、データと制御情報(データとは別のパケットで伝送される、端末側の処理を制御するための情報)とが独立して伝送される環境下での画像や音声の伝送(通信と放送)及び、その制御方法、(A2)送信すべき画像や音声のデータに付加するヘッダ情報(本発明のデータ管理情報に対応)の動的な変更方法、(A3)送信のために付加するヘッダ情報(本発明の伝送管理情報に対応)の動的な変更方法、(A4)複数の論理的な伝送路を動的に多重化、分離して情報の伝送を行う方法、(A5)プログラムやデータの読み込み、立ち上げ時間を考慮した画像や音声の伝送方法、及び(A6)ザッピングを考慮した画像や音声の伝送方法等の観点からの具体的な議論が行われていなかったという課題があった。
【0006】
一方、従来より、ネットワークへの伝送量を動的に調整する方法としては、エンコードの方式を変更する方式や、映像のフレームタイプに応じて、フレーム単位でデータを廃棄する方式が提案されている(秦泉寺(じんぜんじ)浩史、田尻哲男、分散適応型VODシステムの一検討、D−81、電子情報通信学会システムソサイエティ(1995))。
【0007】
エンコーダ側で処理量を調整する方式としては、処理時間拘束のもとで画質の高い映像を提供できる動的演算量スケーラブルアルゴリズムが提案されている(大迫 史典,矢島 由幸,小寺 博,渡辺 裕,島村 和典:動的演算量スケーラブ ルアルゴリズムによるソフトウェア画像符号化,電子情報通信学会論文誌 D− 2, Vol.80-D-2, No.2, pp.444-458(1997).)。
【0008】
また、動画と音声の同期再生を実現した例としては、MPEG1/MPEG2のシステムがある。
【0009】
この様な従来の技術における、(B1)従来方式の映像のフレームタイプに応じて映像を廃棄する方式では、扱える情報の粒度が、単一のストリーム内であるため、複数のビデオストリームや複数のオーディオストリームの取り扱いや、編集者の意図を反映させて、重要なシーンカットを重点的にオーディオとともに同期再生をさせることは困難であるという課題があった。(B2)また、MPEG1/MPEG2では、ハードウェアでの実現が前提であるため、デコーダは与えられたビットストリームをすべてデコードできることが前提となる。したがって、デコーダの処理能力を超えた場合の対応方法が不定となる課題が有る。
【0010】
又一方、従来、動画像の伝送においては、H.261(ITU−T Recommendation H.261−Video codec for audiovisual services at px64)などの方式を用いたものがあり、これまで、ハードウェアにより実装されていた。このため、ハードウェア設計時に、必要な性能の上限を考慮しているため指定時間以内に復号化処理を完了できないという場合は、生じなかった。
【0011】
なお、ここで、指定時間とは、一枚の画像を符号化したビットストリームの伝送に要する時間である。この時間内に復号化できないと、超過した時間が遅延となり、これが蓄積して大きくなると、送信側から受信側までの遅延が大きくなりテレビ電話としての使用に適しなくなる。このような状況は避けねばならない。
【0012】
また、通信相手が規格外のビットストリームを生成しているために復号化処理を指定時間内に完了できない場合には、動画像の伝送ができないという課題があった。
【0013】
上記の課題は、動画像だけではなく、音声データにおいても発生する課題である。
【0014】
ところが近年、インタネットやISDNの普及という形でパーソナルコンピュータ(PC)でのネットワーク環境が整備された結果、伝送速度が速くなり、PCとネットワークを利用した動画像の伝送が可能になってきた。ユーザからの動画像伝送に対する要求も、とみに高まってきている。また、CPU性能の向上により、ソフトウェアによる動画像の復号化が充分可能となってきている。
【0015】
しかしながら、パーソナルコンピュータにおいては同じソフトウェアを、CPU、バス幅、アクセラレータの有無など、装置構成の異なるコンピュータで実行可能であるため、必要な性能の上限を予め考慮することが困難であり、指定時間内に画像を復号化できない場合が生じる。
【0016】
また、受信装置の処理能力を越える長さの動画像の符号化データが伝送された場合には指定時間内の符号化が不可能となる。
【0017】
課題(C1):指定時間内に画像を復号化し、遅延を小さく抑える。
【0018】
また、この課題C1の解決手段として、例えば、波形データとして動画像を入力する場合であれば、伝送されたビットストリームのうち一部を使用しないため、伝送路の実質使用効率が悪い、という問題が残る場合もある。また、符号化方式によっては、前回の復号画像をもとに今回の復号画像を生成するものがあるが(Pピクチャなど)、前回の復号画像を完全に復元しない場合があるため、画質劣化が、時間とともに波及的に大きくなるという問題もある。
【0019】
課題(C2):伝送路の実質使用効率が悪い。また、画質劣化が波及する。
【0020】
また、ソフトウェアによる実装では、一回の符号化処理に要する時間で画像のフレームレートが決まるため、ユーザの指定したフレームレートが計算機の処理限界を越えた場合には、指定に応えることができなかった。
【0021】
課題(C3):ユーザの指示したフレームレートが、計算機の処理限界を越えると指定に応えられない。
【0022】
本発明は、上記第2の従来技術の(B1)〜(B2)の課題を考慮し、それらの課題の少なくとも何れか一つを解決するデータ処理装置、及びデータ処理方法を提供することを目的とする。
【0023】
【課題を解決するための手段】
請求項1記載の本発明は、(1)音声または動画像の時系列データと、(2)前記時系列データ間の処理の優先度を示す時系列データ間優先度と、(3)前記動画像の時系列データを構成するフレームが少なくともIフレームかPフレームかを示すフレームタイプと、前記フレームタイプとは異なる前記フレームの処理優先度を示す時系列データ内優先度とを含むデータ系列を受け付ける受付手段と、前記時系列データ間優先度により、前記各時系列データに対する処理能力を配分し、さらに前記各時系列データについて、配分された処理能力内に収まるように、前記時系列データ内優先度の閾値を適応的に変化させた状態で、前記時系列データ内の区分されたデータの処理を行うデータ処理手段とを備えたデータ処理装置である。
【0024】
請求項2記載の本発明は、(1)音声または動画像の時系列データと、(2)前記時系列データ間の処理の優先度を示す時系列データ間優先度と、(3)前記動画像の時系列データを構成するフレームが少なくともIフレームかPフレームかを示すフレームタイプと、前記フレームタイプとは異なる前記フレームの処理優先度を示す時系列データ内優先度とを含むデータ系列を入力とし、前記時系列データ間優先度により、前記各時系列データに対する処理能力を配分し、さらに前記各時系列データについて、配分された処理能力内に収まるように、前記時系列データ内優先度の閾値を適応的に変化させた状態で、前記時系列データ内の区分されたデータの処理を行うデータ処理方法である。
【0025】
【発明の実施の形態】
以下、本発明の実施の形態について図面を参照しながら説明する。
【0026】
尚、ここで述べる実施の形態は、主に、上述した課題(A1)〜(A6)の何れかを解決するものである。
【0027】
本発明で使用する「画像」としては、静止画と動画の両方を含む。また、対象とする画像は、コンピュータ・グラフィックス(CG)のような2次元画像とワイヤーフレーム・モデルから構成されるような3次元の画像データであってもよい。
【0028】
図1は、本発明の実施の形態における画像音声送受信装置の概略構成図である。
【0029】
同図において、情報を受信する受信管理部11と情報を送信する伝送部13は、同軸ケーブル、CATV、LAN、モデム等の情報を伝送する手段である。通信環境としては、インターネットのように、多重化手段を意識せずに複数の論理的な伝送路が利用できる通信環境であってもよいし、アナログ電話や衛星放送のように多重化手段を意識しなければならない通信環境であってもよい。
【0030】
また、端末の接続形態としては、TV電話やTV会議システムのように端末間で双方向で映像や音声を送受信する形態や、衛星放送やCATV、インターネット上での放送型の映像や音声放送の形態が挙げられる。本発明では、このような端末の接続形態について考慮している。
【0031】
図1に示す分離部12は受信情報を解析し、データと制御情報を分離する手段である。具体的には、送信のためにデータに付加された送信用のヘッダ情報とデータとを分解したり、データ自身に付加されたデータ制御用のヘッダとデータの中身を分解するための手段である。画像伸張部14は受信した画像を伸張する手段である。たとえば、H.261、H.263、MPEG1/2、JPEGといった標準化された動画や静止画の圧縮画像であってもよいし、そうでなくてもよい。
【0032】
図1に示す画像伸張管理部15は画像の伸張状態を監視する手段である。たとえば、画像の伸張状態を監視することで、受信バッファがオーバーフローを起こしそうになった場合に、画像の伸張を行わずに、受信バッファを空読みし、画像の伸張ができる状態になった時点から、画像の伸張を再開させることができる。
【0033】
又、同図において、画像合成部16は、伸張された画像を合成する手段である。合成方法に関しては、JAVA、VRML、MHEGといったスクリプト言語で、画像と画像の構造情報(表示位置と表示時間(表示期間を含めてもよい))、画像同士のグルーピングの方法、画像の表示のレイヤ(深さ)、そして、オブジェクトID(後述するSSRC)と、これらの属性の関係を記述することによって画像の合成方法が定義できる。合成方法を記述したスクリプトはネットワークやローカルの記憶装置から入出力する。
【0034】
又、出力部17は、画像の合成結果を出力するディスプレイやプリンターなどである。端末制御部18はこれら各部を制御する手段である。なお、画像の代わりに音声を伸張する構成であっても(画像伸張部を音声伸張部に、画像伸張管理部を音声伸張管理部に、画像合成部を音声合成部に変更することで対応できる)、画像と音声の両方を伸張し、時間的に同期を保ちながら合成、表示する構成であってもよい。
【0035】
さらに、画像を圧縮する画像圧縮部、画像圧縮部を管理する画像圧縮管理部、音声を圧縮する音声圧縮部、音声圧縮部を管理する音声圧縮管理部を備えることにより、画像や音声の伝送も可能になる。
【0036】
図2は受信管理部11と分離部12とを示す図である。
【0037】
図1に示した受信管理部11にデータを受信するデータ受信部101とデータを制御するための制御情報を受信する制御情報受信部102と、分離部12に伝送内容を解釈するための伝送構造(詳細は後述する)について記憶する伝送フォーマット記憶部103と、伝送フォーマット記憶部103に記憶された伝送構造に基づき伝送内容を解釈する伝送情報解釈部104で各部を構成することで、データと制御情報を独立して受信することが可能になるので、例えば、受信しながらの受信画像や音声の削除や移動が容易になる。
【0038】
前述したが、受信管理部11が対象とする通信環境としては、インターネットのように、多重化手段を意識せずに複数の論理的な伝送路が利用できる通信環境(インターネット・プロファイル)であってもよいし、アナログ電話や衛星放送のように多重化手段を意識しなければならない通信環境(Rawプロファイル)であってもよい。しかし、利用者から見れば、論理的な伝送路(ロジカルチャンネル)が複数個用意されている通信環境を前提としている(たとえば、TCP/IPが使える通信環境では「通信ポート」と呼ばれる表現が一般に使われる)。
【0039】
また、図2に示すように、受信管理部11が受信する情報としては1種類以上のデータ用の伝送路と、伝送するデータを制御するための制御用の論理的な伝送路を1種類以上を想定している。データ伝送用の伝送路を複数用意し、データ制御用の伝送路を1本だけ用意してもよい。また、H.323でも利用されているRTP/RTCPのように、データ伝送毎にデータ制御用の伝送路を用意してもよい。さらに、UDPを使った放送を考慮した場合、単一の通信ポート(マルチキャストアドレス)を使った通信形態であってもよい。
【0040】
図3は、複数の論理的な伝送路を用いて画像や音声の伝送、制御する方法について説明する図である。伝送するデータ自身をES(エレメンタリー・ストリーム)と呼び、ESとしては、画像であれば1フレーム分の画像情報や1フレームよりも小さいGOB単位やマクロブロック単位の画像情報であってもよい。
【0041】
音声であれば、利用者が決めた固定長の長さであってよい。また、伝送するデータに付加するデータ制御用のヘッダ情報をAL(アダプテーション・レイヤ情報)と呼ぶ。AL情報としては、データの処理可能な開始位置であるかどうかを示す情報、データの再生時刻を示す情報、データの処理の優先度を示す情報などがあげられる。本発明のデータ管理情報は、AL情報に対応する。なお、本発明で用いられるESとALはMPEG1/2で定義されている内容と必ずしも合致しなくてもよい。
【0042】
データの処理可能な開始位置であるかどうかを示す情報は、具体的には2種類の情報があげられる。1つはランダムアクセスのためのフラグであり、例えば、画像ならイントラフレーム(Iピクチャ)といったように前後のデータに関係なく単独に読みとって再生できることを示すための情報である。2つ目としては、単に単独で読みとりが可能であることを示すためのフラグとして、アクセスフラグが定義できる。たとえば、画像ならばGOB単位やマクロブロック単位の画像の先頭であることを示す情報である。従って、アクセスフラグがなければデータの途中である。必ずしもデータの処理可能な開始位置であるかどうかを示す情報としてランダムアクセスのフラグと、アクセスフラグの両方が必要ではない。
【0043】
TV会議システムのようなリアルタイム通信では両方のフラグを付加しなくても問題が起こらない場合もあるし、編集を簡単に行えるようにするためにはランダムアクセスフラグは必要である。フラグが必要であるか、必要な場合でもどのフラグが必要かを通信路を介してデータ転送前に決定しておいてもよい。
【0044】
データの再生時刻を示す情報は、画像と音声の再生される時の時間同期の情報を示し、MEPG1/2ではPTS(プレゼンテーション・タイムスタンプ)と呼ばれる。TV会議システムのようなリアルタイム通信では通常、時間同期に関しては考慮されていないため、必ずしも再生時刻を意味する情報は必要ない。必要な情報としては、エンコードされたフレームの時間間隔になるかもしれない。
【0045】
時間間隔を受信側で調整させることによって、フレーム間隔の大きな変動は防げるが、再生間隔を調整させることで遅延になる可能性もある。従って、エンコードのフレーム間隔を示す時間情報も必要ないと判断できる場合もある。
【0046】
データの再生時刻を示す情報は、PTSを意味するのか、フレーム間隔を意味するのか、データの再生時刻をデータ自身には付加しないということを通信路を介してデータ転送前に決定して受信端末に通知して、決定されたデータ管理情報とともにデータを伝送してもよい。
【0047】
データの処理の優先度を示す情報は、受信端末の負荷やネットワークの負荷によって処理もしくは伝送できない場合に、データの処理を中止させたり、伝送を取りやめることによって受信端末の負荷やネットワークの負荷を低減させることができる。
【0048】
受信端末では画像伸張管理部15で、ネットワークでは、中継の端末やルータなどで処理することができる。優先度の表現方法としては数値による表現やフラグであってもよい。なお、データの処理の優先度を示す情報のオフセット値を制御情報、もしくはデータとともにデータ管理情報(ALの情報)として伝送することで、受信端末の負荷やネットワークの負荷の急激な変動に対して、あらかじめ画像や音声に割り当てている優先度にオフセット値を加えることで、システムの動作状況に応じた動的な優先度の設定が可能になる。
【0049】
さらに、スクランブルの有無、コピーライトの有無、オリジナルかコピーかを識別するための情報をデータとは別に、データの識別子(SSRC)とともに制御情報として送信することで、中継ノードでのスクランブルの解除などが容易になる。
【0050】
なお、データの処理の優先度を示す情報は、複数のビデオやオーディオのフレームの集合から構成されるストリーム単位で付加してもよいし、ビデオやオーディオのフレーム単位に付加してもよい。
【0051】
H.263やG.723などの符号化方法で、符号化された情報の過負荷時の処理の優先度を予め決められた基準で決定し、符号化された情報と決定された優先度を対応づける優先度付加手段を送信端末装置に備える(図54参照)。
【0052】
図54は、映像と音声に優先度を付加する優先度付加手段5201について説明する図である。
【0053】
即ち、同図に示す様に、符号化された映像と音声の各データ(それぞれ映像符号化手段5202と音声符号化手段5203が処理する)に対して、予め決められた規則に基づき優先度を付加する。優先度を付加する規則は、優先度付加規則5204に規則が格納されている。規則とは、Iフレーム(フレーム内符号化された映像フレーム)は、Pフレーム(フレーム間符号化された映像フレーム)よりも高い優先度付加するという規則や、映像は音声よりも低い優先度を付加するという規則である。また、この規則は利用者の指示により動的に変更しても良い。
【0054】
優先度を付加する対象となるものは、たとえば、画像であればシーンチェンジ、編集者や利用者が指示した画像フレームやストリーム、音声であれば、有音区間と無音区間である。
【0055】
過負荷時の処理の優先度を定義する、画像や音声フレーム単位の優先度の付加方法は、通信ヘッダへ付加する方法と符号化時にビデオやオーディオの符号化されたビットストリームのヘッダに埋め込む方法が考えられる。前者は、復号せずに優先度に関する情報を得ることが可能であり、後者はシステムに依存せずにビットストリーム単体で独立に扱うことが可能である。
【0056】
通信ヘッダに優先度情報を付加する場合、1つの画像フレーム(たとえば、フレーム内符号化されたIフレーム、フレーム間符号化されたP、Bフレーム)が複数個の送信パケットに分割される場合、画像であれば単独の情報としてアクセス可能な画像フレームの先頭部分を伝送する通信ヘッダのみに優先度を付加する(同一の画像フレーム内で優先度が等しい場合、次のアクセス可能な画像フレームの先頭が現れるまで、優先度は変わらないものとすればよい)。
【0057】
なお、用途に合わせて、優先度が表現できる値の範囲(たとえば、時間情報を16ビットで表現するとか、32ビットで表現するとか)を可変にして、制御情報でコンフィグレーションできるようにしてもよい。
【0058】
また、復号化装置では、受信された種々の符号化された情報の過負荷時の優先度に従って、処理の方法を決定する優先度決定手段を受信端末装置に備える(図55参照)。
【0059】
図55は、映像と音声に付加された優先度を解釈し、復号処理の可否を決定する優先度決定手段5301について説明する図である。
【0060】
即ち、同図に示す様に、優先度は映像、音声のストリーム毎に付加される優先度、映像もしくは音声のフレーム毎に付加される優先度である。これらの優先度はそれぞれ独立に用いてもよいし、フレーム優先度とストリーム優先度とを対応付けて用いてもよい。優先度決定手段5301は、これら優先度に応じて復号すべきストリームやフレームを決定する。
【0061】
端末での過負荷時の処理の優先度を決定する2種類の優先度を用いて、デコード処理を行なう。すなわち、映像、音声といったビットストリーム間の相対的優先度を定義するストリーム優先度(Stream Priority;時系列間優先度)と、同一ストリーム内の映像フレームといった復号処理単位間の相対的優先度を定義するフレーム優先度(Frame Priority;時系列内優先度)を定義する(図30)。
【0062】
前者のストリーム優先度により複数のビデオやオーディオの取り扱いが可能になる。後者のフレーム優先度により映像のシーンチェンジや編集者の意図に応じて、同一のフレーム内符号化された映像フレーム(Iフレーム)でも異なる優先度の付加が可能になる。
【0063】
なお、ストリーム優先度を、画像や音声の符号化もしくは復号化処理のオペレーティング・システム(OS)での割り当て時間もしく処理の優先度に対応付けて管理することで、OSレベルでの処理時間の管理が可能となる。たとえば、マイクロソフト社のWindows95/NTでは5段階のOSレベルでの優先度の定義ができる。符号化、復号化の手段をソフトウェアでスレッドの単位で実現した場合、処理対象となるストリームのストリーム優先度から、各スレッドに割り当てるOSレベルでの優先度を決定することができる。
【0064】
ここで述べた、フレーム優先度とストリーム優先度は、伝送媒体やデータ記録媒体へ適用が可能である。例えば、伝送するパケットの優先度をアクセスユニット優先度(Access Unit Priority)と定義すると、Access Unit Priority=Stream Priority−Frame Priorityといった、フレーム優先度と、ストリーム優先度の関係式から、パケットの伝送に関する優先度、若しくは、端末による過負荷時の処理の優先度を決定することが出来る。
【0065】
又、データ記録媒体としてフロッピーディスク、光ディスクなどを用いて行うことができる。また、記録媒体はこれに限らず、ICカード、ROMカセット等、プログラムを記録できるものであれば同様に実施することができる。さらに、データの中継を行うルータやゲートウェイといった画像や音声の中継装置を対象としてもよい。
【0066】
具体的な優先度に関する利用方法としては、受信端末が過負荷である場合に、処理すべき符号化された情報の優先度の閾値を決定する優先度決定手段を画像伸長管理部15や音声伸長管理部に具備し、表示されるべき時刻(PTS)と現在までの処理開始からの経過時間もしくは、復号されるべき時刻(DTS)と現在までの処理開始からの経過時間を比較し、比較結果により処理すべき符号化された情報の優先度の閾値を変化させる(閾値を変化させるための情報としては、Iフレームの挿入間隔、優先度の粒度を参考にしてもよい)。
【0067】
図25(a)に示す例では、エンコード時には、取り込まれたQCIF、CIFのサイズの画像をエンコーダ(H.263)により、エンコードを行い、エンコードされた情報とともに、復号する時刻(DTS)、画像を表示する時刻を示すタイムスタンプ(PTS)、過負荷時の処理の順序を示す優先度情報(CGD、Computational Graceful Degradation)、フレームタイプ、シーケンス番号(SN)を出力する。
【0068】
また、図25(b)に示す例では、音声もマイクを通して録音され、エンコーダ(G.721)により、エンコードを行い、エンコードされた情報とともに、復号する時刻(DTS)、音声を再生する時刻を示すタイムスタンプ(PTS)、優先度情報(CGD)、シーケンス番号(SN)を出力する。
【0069】
デコード時には、図26に示す様に、画像と音声は、それぞれ別々のバッファに渡され、画像と音声はそれぞれのDTS(復号時刻)と現在の処理開始からの経過時間とを比較して、DTSの方が遅れていなければ、画像と音声はそれぞれのデコーダ(H.263、G.721)に渡される。
【0070】
図27の例では、エンコーダでの過負荷時の優先度の付加方法について記している。画像はIフレーム(フレーム内符号化された画像フレーム)は優先度が「0」と「1」で高い優先度を割り当てている(数字が大きいほど優先度が低い)。Pフレームは優先度が「2」でIフレームよりも低い優先度を割り当てている。Iフレームは、2段階の優先度を割り当てているため、デコードする端末の負荷が高い場合、優先度が「0」のIフレームのみを再生するといったことができる。なお、優先度の付加方法に応じて、Iフレームの挿入間隔を調整する必要がある。
【0071】
図28の例は、過負荷時の受信端末での優先度の決定方法について記した図である。廃棄するフレームの優先度をCutOffPriorityよりも大きいと設定する。つまり、すべての画像フレームを処理の対象とする。画像フレームに付加される優先度の最大値は端末接続時に送信側から受信側へ通知することにより、あらかじめ知ることができる(ステップ101)。
【0072】
DTSと現在の処理開始からの経過時間を比較して、経過時間の方が大きい場合(復号処理が間に合っていない場合)、処理対象とすべき画像、音声の優先度の閾値CutOffPriorityを引き下げ、処理を間引く(ステップ102)、逆に処理開始からの経過時間の方が小さい場合(復号処理が間に合っている場合)は、処理できる対象の画像や音声を増やすために、優先度の閾値CutOffPriorityを引き上げる(ステップ103)。
【0073】
1つ前の画像フレームがPフレームでスキップされているならば処理は行わない。そうでなければ、画像フレーム(もしくは音声のフレーム)の優先度に優先度のオフセット値を付加し、優先度の閾値と比較し、閾値をこえていなければ、デコーダに復号すべきデータを渡す(ステップ104)。
【0074】
なお、優先度のオフセットは、マシンの性能をあらかじめ調べ、受信端末へオフセットを通知しておくという使い方(利用者が受信端末で指示してもよい)、複数のビデオとサウンドストリームのストリーム単位の優先度を変更するという使い方(例えば、一番後ろの背景はオフセット値をあげて処理を間引くようにする)ができる。
【0075】
マルチストリームを対象とする場合、ストリーム毎の優先度を付加し、画像や音声のデコードのスキップ判定をしてもよい。加えて、リアルタイム通信においてもH.263のTR(テンポラリーリファレンス)をDTSと同様にして取り扱い利用することで、端末でのデコード処理が進んでいるか、遅れているかを判定でき、上記で述べた同様のスキップ処理を実現することができる。
【0076】
図29は、図28のアルゴリズムを実装して、優先度の時間変化を調べたものである。
【0077】
同図では、映像フレームに付加される優先度の変化を示している。この優先度は端末が過負荷である際の復号の可否を決定するための優先度であり、各フレーム毎に付加される。優先度は値が小さいほど優先度が高い。同図の例では0が最も優先度が高い。優先度の閾値が3であるとき、3よりも大きな値の優先度のフレームは復号されずに廃棄され、3以下の値の優先度が付加されているフレームは復号される。優先度による選択的なフレームの廃棄を行うことで、端末の負荷を押さえることが可能である。この優先度の閾値は、現在の処理時刻と各フレームに付加される復号処理時間(DTS)との関係から動的に決定してもよい。本手法は映像フレームだけでなく、音声に対しても同様な要領で適用が可能である。
【0078】
インターネットのような伝送路を考えた場合、伝送途中で紛失した符号化された情報の再送が必要な場合、再送すべき符号化された情報の優先度の閾値を決定する再送要求優先度決定部を受信管理部11に備え、優先度決定部が管理する優先度や、再送回数、情報の損失率、フレーム内符号化されたフレームの挿入間隔、優先度の粒度(たとえば、5段階の優先度など)の情報をもとに、再送要求すべき符号化された情報に付加された優先度の閾値を決定することで、受信端末で必要とする画像や音声のみを再送要求することができる。再送回数や情報の損失率が大きければ、再送すべき対象とする情報の優先度を引き上げて、再送や損失率を低下させる必要がある。また、優先度決定部で使用されている優先度を知ることで、処理対象外の情報の伝送をなくすことができる。
【0079】
送信側端末に関しては、送信端末の情報の目標転送レートよりも実際の転送レートが超える場合や、送信バッファへの符号化された情報の書き込みが、現在までの転送処理開始からの経過時間と符号化された情報に付加されている復号もしくは表示される時刻とを比較して、送信バッファへの情報の書き込みが遅れている場合、符号化された情報に付加され、受信端末の優先度決定部で利用される端末が過負荷時の優先度を用いて、情報の送信を間引くことで、目標レートにあった画像や音声の伝送が可能となる。また、受信側端末で行っているような過負荷時の処理のスキップ機能を送信側端末でも導入することで送信側端末の過負荷による破綻を押さえることができる。
【0080】
上記で説明したALの情報を必要に応じて、必要な情報だけを伝送できるようにすることによって、アナログ電話回線のような狭帯域の通信路には伝送情報量を調節できるので有効である。実現方法としては、送信側端末でデータ自身に付加するデータ管理情報を予めデータ送信前に決定し、受信端末に使用するデータ管理情報を制御情報(たとえば、ランダムアクセスフラグだけを使用するとか)として通知するとともに、受信側端末では得られた制御情報をもとに、前記伝送フォーマット記憶部103で記憶する伝送構造に関する情報(どのALの情報を使用するか表している)を書き換えることにより、送信側で使用するALの情報(データ管理情報)の組み替えが可能になる(図19〜図20参照)。
【0081】
図4は、送信すべき画像や音声のデータに付加するヘッダ情報の動的な変更方法について説明する図である。図の例では、伝送すべきデータ(ES)をデータ片に分解し、得られたデータ片に、データの順序関係を示すための識別情報(シーケンス番号)と、データ片の処理可能な開始位置であるかどうかを示す情報(マーカービット)と、データ片の転送に関する時間情報(タイムスタンプ)とを、本発明の伝送管理情報に対応するものとして、通信ヘッダの形でデータ片に付加している。
【0082】
具体的な例としては、RTP(Realtime Transfer Protocol、RFC1889)では上記のシーケンス番号、マーカービット、タイムスタンプ、オブジェクトID(SSRCと呼ばれている)、バージョン番号などの情報を通信ヘッダとして使用している。ヘッダ情報の項目の拡張は可能であるが、上記の項目は固定の項目として必ず付加される。しかし、複数の異なる符号化の画像や音声を複数、同時に伝送する通信環境で、TV電話のようにリアルタイム通信とビデオ・オン・デマンドのように蓄積メディアの伝送が混在する場合、通信ヘッダの持つ意味合いが異なり、識別する手段が必要である。
【0083】
例えば、タイムスタンプの情報は、MPEG1/2の場合は前述したように再生時刻であるPTSを示すが、H.261やH.263ではエンコードされた時間間隔を表す。しかし、H.263を音声と同期をとって処理を行いたい場合、タイムスタンプがPTSの情報であることを示す必要がある。なぜならば、H.263の場合、タイムスタンプの情報は、エンコードされたフレーム間の時間間隔を示すのであって、1枚目のフレームのタイムスタンプはランダムであるとRTPで定義されているからである。
【0084】
そこで、(a)タイムスタンプがPTSであるかないかを示すフラグを通信ヘッダ情報(通信ヘッダの拡張が必要になる)もしくは、(b)H.263やH.261のペイロードのヘッダ情報(つまり、ALの情報)として付加する必要がある(この場合、ペイロード情報の拡張が必要になる)。
【0085】
RTPのヘッダ情報として、データ片の処理可能な開始位置であるかどうかを示す情報であるマーカビットが付加されているが、ALの情報としても前述したように、データに対してアクセスできる開始時点であることを示すアクセスフラグ、ランダムにデータに対してアクセスすることができることを示すランダムアクセスフラグを持たせたい場合がある。重複して、通信ヘッダに持たせるのは効率が悪くなるため、ALのフラグを通信ヘッダで用意しているフラグで代用させる方法も考えられる。
【0086】
(c)ALにフラグを付加せずに通信ヘッダに付加しているヘッダでALのフラグを代用させることを示すフラグを通信ヘッダに新たに設けるか、通信ヘッダのマーカービットはALのものと同じであると定義することで、問題は解決される(ALに持たせるよりも解釈が早くできことが期待できる)。つまり、マーカービットがALのフラグと同じ意味を持つかどうかを示すフラグである。この場合、通信ヘッダの改良もしくは、拡張領域に記述することが考えられる。
【0087】
逆に、(d)通信ヘッダのマーカビットの意味をALに少なくともランダムアクセスフラグもしくは、アクセスフラグのいずれかが存在することを意味するように解釈するようにしてもよい。この場合、従来とは解釈の意味が変わったことを知るには通信ヘッダのバージョン番号で対応できる。これ以外に、単純な方法としては、通信ヘッダもしくはALのヘッダにのみアクセスフラグやランダムアクセスフラグを設ければ処理は簡単である(前者の場合、フラグを両方とも設ける場合も考えられるが、通信ヘッダの新たな拡張が必要になる)。
【0088】
データ処理の優先度を示す情報をALの情報として付加することは述べたが、通信ヘッダにデータの処理の優先度を付加することによって、データ処理の優先度の処理の判定がネットワーク上においてもデータの中身を解釈せずに行うことが可能となる。なお、IPv6の場合、RTPのレベルより下位のレイヤーで付加することが可能である。
【0089】
RTPの通信ヘッダにデータの処理の有効期間を示すためのタイマーもしくはカウンタを付加することで、伝送されてくるパケットのある状態変化がどのように変化しているかを判断することができる。たとえば、必要となるデコーダソフトウェアが、アクセス速度の遅い記憶装置に記憶されている場合、デコーダが必要になるという情報と、タイマーやカウンターにより、いつの時点で必要になるかを判断することが可能になる。この場合、用途によってはALの情報にタイマーやカウンター、データの処理の優先度の情報は不要である。
【0090】
図5(a)〜図5(b)、と図6(a)〜図6(d)は、AL情報の付加方法について説明する図である。
【0091】
図5(a)に示した様に、ALを伝送すべきデータの先頭にのみ付加するか、あるいは、図5(b)に示した様に、伝送すべきデータ(ES)を1つ以上のデータ片に分解した後のデータ片のそれぞれに付加するかを通知する制御情報を、受信端末へ送付することにより伝送情報の取り扱い粒度を選択できるようにすることが可能になる。ALを細分化されたデータに対してつけることで、アクセス遅延が問題になるような場合には有効である。
【0092】
前述したように、受信側でのデータ管理情報の組み替えや、データ管理情報のデータへの配置方法の変更が行われることを予め受信側端末に通知するために、フラグ、カウンター、タイマーのような表現方法を用いて、ALの情報として用意したり、通信ヘッダとして用意して受信端末に通知することで、受信端末対応がスムーズにできる。
【0093】
これまでの例ではRTPのヘッダ(又は、通信ヘッダ)とALの情報の重複を回避する方法や、RTPの通信ヘッダやALの情報を拡張する方法について述べた。しかし、本発明は、必ずしもRTPである必要はない。たとえば、UDPやTCPを使って独自の通信ヘッダやAL情報を新たに定義してもよい。インターネットプロファイルではRTPを使うことはあるが、RawプロファイルではRTPのような多機能なヘッダは定義されていない。AL情報と通信ヘッダに関する考え方としては、次の4通りの考え方ができる(図6(a)〜図6(d)参照)。
【0094】
(1)RTPとALで、既に割り当てられているヘッダ情報が重複しないように、RTPのヘッダ情報もしくはALの情報を修正、拡張する(とくにタイムスタンプの情報が重複、タイマーやカウンター、データの処理の優先度情報が拡張情報となる)。あるいは、RTPのヘッダも拡張せず、ALの情報もRTPのものと重複していても考慮しない方法でもよい。これらに関してはこれまでに示した内容に相当する。RTPは既に一部、H.323で実用化されているので、互換性を保ったRTPの拡張は有効である(図6(a)参照)。
【0095】
(2)RTPにこだわらずに、通信ヘッダを簡略にして(たとえば、シーケンス番号だけにするとか)、残りをAL情報に多機能な制御情報として持たせる。また、AL情報で使用する項目を通信前に可変に設定できるようにすることで、柔軟な伝送フォーマットが規定できる(図6(b)参照)。
【0096】
(3)RTPにこだわらずに、ALの情報を簡略にして(極端な例では、ALには情報を付加しない)、通信ヘッダにすべての制御情報を持たせる。通信ヘッダとして頻繁によく参照されうるシーケンス番号、タイムスタンプ、マーカービット、ペイロードタイプ、オブジェクトIDに関しては固定のヘッダ情報としておき、データ処理の優先度情報、タイマー情報に関しては拡張情報として、拡張情報が存在するどうかを示す識別子を設けておいて、拡張情報が定義されていれば参照するようにしてもよい(図6(c)参照)。
【0097】
(4)RTPにこだわらず、通信ヘッダ、ALの情報を簡略にして、これら通信ヘッダやAL情報とは、別のパケットとして、フォーマットを定義して、伝送する。例えば、ALの情報はマーカービット、タイムスタンプ、オブジェクトIDだけ定義し、通信ヘッダもシーケンス番号だけを定義し、これらの情報とは別の伝送パケット(第2のパケット)として、ペイロード情報、データ処理の優先度情報、タイマー情報などを定義し、伝送する方法も考えられる(図6(d)参照)。
【0098】
上記に示したように、用途や、既に画像や音声に付加されているヘッダ情報を考慮すれば、用途にあわせて、通信ヘッダ、ALの情報、データとは別に伝送するパケット(第2のパケット)を自由に定義できる(カスタイマイズできる)ようにするのが望ましい。
【0099】
図7は、複数の論理的な伝送路を動的に多重化、分離して情報の伝送を行う方法について説明する図である。論理的な伝送路の数を節約するために、利用者の指示もしくは論理的な伝送路の数に応じて、複数のデータもしくは制御情報を伝送するための論理的な伝送路の情報の多重化を開始したり、終了させることが可能な情報多重部を伝送部13に、多重化された情報を分離する情報分離部を受信管理部11に設けることにより実現できる。
【0100】
なお、図7では情報多重部を“Group MUX”とよんでおり、具体的にはH.223のような多重化方式を用いればよい。このGroup MUXは送受信端末で設けてもよいし、中継のルータや端末に設けることによって、狭帯域通信路への対応や、Group MUXをH.223で実現すればH.324と相互接続できる。
【0101】
情報多重部に関する制御情報(多重化制御情報)を素早く取り出すために、情報多重部の制御情報を情報多重部でデータと多重化して送信するのではなく、多重化せずに別の論理的な伝送路で伝送することで、多重化による遅延を低減することができる。これに伴って、情報多重部に関する制御情報をデータと多重化して伝送するのか、データと多重化して送信するのではなく、多重化せずに別の論理的な伝送路で伝送するのかを通知して伝送することで、従来の多重化と整合性を保たせたり、多重化による遅延を低減させるかを利用者で選択することが可能になる。ここで、情報多重部に関する多重化制御情報とは、例えば、情報多重部が、各データに対して、どの様な多重化を行っているのかという、多重化の内容を示す情報である。
【0102】
前述したように、同様に、少なくとも多重化の開始と終了を通知する情報、多重化すべき論理的な伝送路の組合せを通知するための情報、多重化に関する制御情報(多重化制御情報)の伝送方法の通知を、フラグ、カウンタ、タイマーのような表現方法で、制御情報として伝送、もしくはデータ管理情報としてデータとともに、受信側端末に伝送することで、受信側でのセットアップの時間を短縮できる。また、前述したようにフラグ、カウンタ、タイマーを表現する項目はRTPの送信ヘッダに設けてもよい。
【0103】
複数個の情報多重部や情報分離部が存在する場合、情報多重部や情報分離部を識別するための識別子とともに制御情報(多重化制御情報)を伝送すれば、どの情報多重部に関する制御情報(多重化制御情報)かを識別することができる。制御情報(多重化制御情報)としては、多重化のパターンなどがあげられる。また、情報多重部や情報分離部の識別子を乱数を用いて、端末間で決定することで情報多重部の識別子を生成することができる。たとえば、送受信端末間で決められた範囲での乱数を発生させ、大きい方の値を情報多重部の識別子(識別番号)とすればよい。
【0104】
情報多重部で多重化されたデータは、従来、RTPで定義されているメディアタイプとは異なるため、RTPのペイロード・タイプに、情報多重部で多重化された情報であることを示す情報(新たなメディアタイプ、H.223を定義)を定義すればよい。
【0105】
多重化されたデータに対するアクセス速度を向上させる方法として、情報多重部で伝送もしくは記録する情報を制御情報、データ情報の順に配置することで多重化された情報の解析を早くできることが期待できる。また、制御情報に付加するデータ管理情報で記述する項目は固定にし、データとは異なる識別子(ユニークなパターン)を付加して多重化することでヘッダ情報の解析を早くできる。
【0106】
図8は放送番組の伝送手順について説明するための図である。論理的な伝送路の識別子と放送番組の識別子の対応関係を放送番組の情報として制御情報を伝送するか、放送番組の識別子をデータ管理情報(AL情報)としてデータに付加して伝送することで複数の伝送路で伝送されるデータがどの番組のために放送されているのかを識別することが可能となる。また、データの識別子(RTPではSSRC)と論理的な伝送路の識別子(たとえば、LANのポート番号)との関係を制御情報として受信側端末に伝送して、受信側端末では受信可能であることを確認後(Ack/Reject)、対応するデータを伝送することにより、制御情報とデータを独立した伝送路で伝送しても、データ間の対応関係がとれる。
【0107】
放送番組やデータに対して伝送の順序関係を示す識別子と、放送番組やデータが情報として利用できる有効期限を示すためのカウンタもしくはタイマーの情報とを組み合わせて、放送番組やデータに付加して伝送することで、戻りチャンネルなしで放送が実現できる(有効期限が過ぎそうになったら、不足の情報があっても放送番組の情報やデータの再生を開始する)。単一の通信ポートのアドレス(マルチキャストアドレス)を使って、制御情報とデータに分離せずに放送する方法も考えられる。
【0108】
なお、バックチャンネルを持たない通信の場合、データの構造情報を受信端末が知ることができるように、制御情報はデータよりも十分、前もって伝送しておく必要がある。また、制御情報は一般には、パケットロスのない信頼性の高い伝送チャンネルで伝送すべきであるが、信頼性の低い伝送チャネルを用いる場合は周期的に同じ伝送シーケンス番号を持った制御情報を繰り返し伝送する必要がある。これはセットアップ時間に関する制御情報を送る場合に限った話ではない。
【0109】
また、データ管理情報として付加可能な項目(たとえば、アクセスフラグ、ランダムアクセスフラグ、データの再生時刻(PTS)、データ処理の優先度情報など)を選択して、制御情報としてデータの識別子(SSRC)とともにデータとは別の論理的な伝送路で伝送するか、データとともにデータ管理情報(ALの情報)として伝送するかを、データ送信前に送信側で決定して、受信側に制御情報として通知して伝送することで柔軟なデータの管理と伝送が可能となる。
【0110】
これにより、ALには情報を付加せずにデータ情報の伝送を行うことができるので、RTPを用いて画像や音声のデータを伝送する際に、従来から定義されているペイロードの定義を拡張する必要がなくなる。
【0111】
図9(a)〜図9(b)は、プログラムやデータの読み込み、立ち上げ時間を考慮した画像や音声の伝送方法を示す図である。特に、衛星放送や携帯端末のように戻りチャンネルがなく一方向で、端末の資源が限られている場合で、プログラムやデータが受信側端末に存在して利用する場合、必要となるプログラム(例えば、H.263、MPEG1/2、音声のデコーダのソフトウェアなど)やデータ(たとえば、画像データや音声のデータ)が、読み込みに時間がかかる記憶装置(たとえば、DVD、ハードディスク、ネットワーク上のファイルサーバなど)に存在する場合に、予め必要となるプログラムやデータを識別する識別子と、伝送されるストリームの識別子(たとえば、SSRCや、Logical Channel Number)、受信端末で必要となる時点を推定するためのフラグ、カウンタ(カウントアップ、ダウン)、タイマーのような表現方法で、制御情報として受信、もしくはデータ管理情報としてデータとともに受信することで、必要となるプログラムやデータのセットアップ時間の短縮が可能となる(図22)。
【0112】
一方、プログラムやデータが送信される場合、プログラムやデータの受信端末での記憶先(たとえば、ハードディスク、メモリー)、起動や読み込みにかかる時間、端末の種類や記憶先と起動や読みとりにかかる時間の対応関係(例えば、CPUパワー、記憶デバイスと平均的な応答時間の関係)、利用順序を示す情報とともにプログラムやデータを送信側から伝送することで、受信側端末で必要となるプログラムやデータを実際に必要となる場合、プログラムやデータの記憶先や読み出す時間に関してスケジューリングが可能となる。
【0113】
図10(a)〜図10(b)は、ザッピング(TVのチャンネル切り替え)に対する対応方法について説明する図である。
【0114】
従来からある映像を受信するだけの衛星放送とは異なり、プログラムを受信端末で実行しなければならないとき、プログラムの読み込みや立ち上がるまでのセットアップの時間が大きな問題となる。これは、携帯端末のように利用資源が限られる場合でも同じことがいえる。
【0115】
解決策の1つとして、(a)利用者が視聴するための主視聴部と、利用者が視聴している以外の番組で、必要となるプログラムやデータが、読み込みに時間がかかる記憶装置に存在する場合に、利用者が視聴している番組以外の番組を受信端末が周期的に視聴する副視聴部を備え、予め必要となるプログラムやデータを識別する識別子と、受信端末で必要となる時点を推定するためのフラグ、カウンタ、タイマーといった情報と、番組との対応関係を、制御情報(データとは別のパケットで伝送される、端末処理を制御するための情報)として受信、もしくはデータ管理情報(ALの情報)としてデータとともに受信して、プログラムやデータの読み込みを準備しておくことで、受信側端末でのセットアップ時間が短縮できることが期待できる。
【0116】
解決策の2つ目としては、複数個のチャンネルで放送される画像の見出し画像だけを放送する放送チャンネルを設け、視聴者が視聴番組を切り替えることで、必要となるプログラムやデータが、読み込みに時間がかかる記憶装置に存在した場合、一旦、視聴したい番組の見出し画像を選択して視聴者に提示するか、読み込み中であることを提示するとともに、記憶装置から必要となるプログラムやデータを読み込み、読み込み終了後、視聴者が視聴したい番組を再開することで、セットアップ時に発生する画面の停止が防止できる。ここでいう見出し画像は、周期的に複数個のチャンネルで放送される番組をサンプリングした放送画像を指す。
【0117】
また、タイマーは時間表現で、たとえば、送信側から送られてくるデータストリームをデコードするのに必要なプログラムは現在からいつの時点で必要となるかを示す。カウンタは送受信端末間で決めた基本時間単位で、何回目かを示す情報であればよい。フラグは、セットアップに必要な時間前に送出するデータもしくは、制御情報(データとは別のパケットで伝送される、端末処理を制御する情報)とともに伝送して通知する。タイマー、カウンターともデータの中に埋め込んで伝送してよいし、制御情報として伝送してもよい。
【0118】
さらに、セットアップ時間の決定方法としては、例えば、クロックベースで動作しているISDNのような伝送路を用いた場合、送信側端末から受信端末でプログラムやデータが必要となる時点を通知するために、伝送管理情報として伝送の順序関係を識別するための送信シリアル番号を用いて、データ管理情報としてデータとともに、もしくは、制御情報として受信端末に通知することで、セットアップが行われる時刻の予測が可能になる。また、インターネットのようにジッタや遅延により、伝送時間が変動する場合は、RTCP(インターネットのメディア伝送プロトコル)で既に実現されているような手段で、ジッタや遅延時間から、伝送の伝播遅延を加味してセットアップ時間に付加しておけばよい。
【0119】
図11から図24は、実際に端末間で送受信されるプロトコルの具体例を示す図である。
【0120】
伝送フォーマットや伝送手続きはASN.1で記述した。又、本伝送フォーマットは、ITUのH.245をベースに拡張を行った。図11にもあるように、画像や音声のオブジェクトは階層構造をなしていてもよく、ここの例では、各オブジェクトIDは放送番組の識別子(ProgramID)とオブジェクトID(SSRC)の属性をもち、画像間の構造情報、合成方法はJava,VRMLといったスクリプト言語で記述する。
【0121】
図11は、オブジェクト間の関係についての例を示す図である。
【0122】
同図において、オブジェクトは、映像、音声、CG、テキストなどのメディアである。同図の例では、オブジェクトは階層構造を成している。各オブジェクトは、プログラム番号(TVのチャンネルに相当、“Program ID”)とオブジェクトを識別するオブジェクト識別子“Object ID”を持つ。RTP(インターネットで用いられるメディア伝送のプロトコル、Realtime Transfer Protocol)で各オブジェクトを伝送する場合は、オブジェクト識別子はSSRC(同期ソース識別子)に対応させることで容易にオブジェクトの識別が可能である。なお、オブジェクト間の構造記述はJAVA、VRMLといった記述言語で記述することが可能である。
【0123】
これらのオブジェクトの伝送方法は2通り考えられる。1つは放送型であり、送信側端末から一方的に伝送する形態である。もう1つは送受信端末間(端末A、端末B)でオブジェクトの伝送を行う形態(通信型)も考えられる。
【0124】
例えば、伝送方法としてはインターネットの場合はRTPを用いることができる。制御情報は、TV電話の規格ではLCNOと呼ばれる伝送チャンネルを用いて伝送する。同図の例では伝送に複数の伝送チャンネルを用いているが、これらのチャンネルは同一の番組チャンネル(Program ID)が割り当てられている。
【0125】
図12は、本発明で述べた機能を実現するためのプロトコルの実現方法について説明する図である。ここではTV電話の規格(H.324,H.323)で用いられる伝送プロトコル(H.245)を用いて説明する。H.245の拡張を行うことで本発明で述べた機能を実現する。
【0126】
同図の例で示した記述方法は、ASN.1と呼ばれるプロトコル記述方式である。“Terminal Capability Set”は端末の性能を表現する。同図の例では、“mpeg4 Capability”と記した機能を従来からあるH.245に対して拡張している。
【0127】
図13では、“mpeg4 Capability”は端末で同時に処理できる最大の映像の数(“Max Number Of Video”)、最大の音声の数(“Max Number Of Sounds”)、端末で実現できる最大の多重化機能の数(“Max Number Of Mux”)を記している。
【0128】
同図では、これらをまとめて、処理できる最大のオブジェクト数(“Number Of Process Object”)として表現している。また、通信ヘッダ(同図ではALと表現)の変更が可能であるかを記すフラグが記されている。この値が真であるとき通信ヘッダの変更が可能である。“MPEG4 Capability”を用いて端末間で処理できるオブジェクト数をお互いに通知する場合に、通知された側が受け入れ(処理)可能であれば“MEPG4 Capability Ack”を、そうでなければ“MEPG4 Capability Reject”を、“MEPG4 Capability”を送信してきた端末に返す。
【0129】
図14では、1つの伝送チャンネル(この例ではLANの伝送チャンネル)を複数の論理的なチャンネルで共有して使用するために複数の論理的なチャンネルを1つの伝送チャンネルに多重化する前述のGroup MUXを使用するためのプロトコルの記述方法について示している。同図の例では、LAN(ローカルエリアネトワーク)の伝送チャンネル(“LAN Port Number”)に多重化手段(Group MUX)を対応づけている。“Group MuxID”は、多重化手段を識別するための識別子である。“Create Group Mux”を用いて端末間で多重化手段を使用する場合にお互いに通知する場合に、通知された側が受け入れ(使用)可能であれば“Create Group Mux Ack”を、そうでなければ“Create Group Mux Reject”を、“Create Group Mux”を送信してきた端末に返す。多重化手段の逆の動作を行う手段である分離手段は、同様な方法で実現出来る。
【0130】
図15では、既に生成した多重化手段を消去する場合について記述している。
【0131】
図16では、LANの伝送チャンネルと複数の論理的なチャンネルの関係について記述している。
【0132】
LANの伝送チャンネルは“LAN Port Number”で、複数の論理的なチャンネルは“Logical Port Number”で記述する。
【0133】
同図の例では、1つのLANの伝送チャンネルに対して最大15個の論理的なチャンネルを対応づけることが可能である。
【0134】
尚、同図において、使用できるMUXの数が、1個だけの場合は、GroupMux IDは、不要である。又、Muxを複数使用する場合は、H.223の各コマンドに対してGroup Mux IDが必要である。又、多重化と分離手段との間で用いられるポートの対応関係を通知するためのフラグを設けても良い。又、制御情報も多重化するか、別の論理的な伝送路を介して伝送するかを選択出来るようにするためのコマンドを設けても良い。
【0135】
図14〜図16の説明では伝送チャンネルはLANであるが、H.223、MPEG2のようにインターネットプロトコルを使わない方式でもよい。
【0136】
図17では、“Open Logical Channel”は伝送チャンネルの属性を定義するためのプロトコル記述を示している。同図の例では、H.245のプロトコルに対して、“MPEG4 Logical Channel Parameters”を拡張定義している。
【0137】
図18では、LANの伝送チャンネルに対して、プログラム番号(TVのチャンネルに相当)と、プログラムの名前とを対応づけている(“MPEG4 Logical Cannel Parameters”)ことを示している。
【0138】
又、同図において、“Broadcast Channel Program”は、LANの伝送チャンネルとプログラム番号との対応付けを放送型で送信する場合の記述方法である。同図の例では、最大1023個の伝送チャンネルとプログラム番号の対応関係を送付することが可能である。放送の場合は送信側から受信側へ一方的に送信するだけであるため、これらの情報を伝送中の損失を考慮して周期的に伝送する必要がある。
【0139】
図19では、プログラムとして伝送されるオブジェクト(例えば、映像、音声など)の属性について記述している(“MPEG4 Object Classdefinition”)。プログラムの識別子(“Program ID”)に対してオブジェクトの情報(“Object Structure Element”)を対応付けている。最大で1023個のオブジェクトを対応付けることが可能である。オブジェクトの情報としては、LANの伝送チャンネル(“LAN Port Number”)、スクランブルが使用されているか否かのフラグ(“Scramble Flag”)、端末が過負荷である場合の処理の優先度を変更するためのオフセット値を定義するフィールド(“CGD Offset”)、そして、伝送するメディア(映像、音声など)のタイプを識別するための識別子(Media Type)を記述する。
【0140】
図20の例では、ES(ここでは1フレーム分の映像に相当するデータ列と定義する)の復号処理を管理するためにAL(ここでは1フレーム分の映像を復号するために必要な付加情報と定義する)が付加されている。ALの情報としては、(1)Random Access Flag(単独で再生可能であるかどうかを示すフラグ、フレーム内符号化された映像フレームであれば真である)、(2)Presentation Time Stamp(フレームの表示時刻)、(3)CGD Priority(端末が過負荷時に処理の優先度を決定するための優先度の値)が定義されている。これらの1フレーム分のデータ列を、RTP(インターネットで連続メディアを伝送するためのプロトコル,Realtime Transfer Protocol)を用いて伝送する場合の例を示している。“AL Reconfiguration”は、上記のALで表現できる最大値を変更するための伝送表現である。
【0141】
同図の例では、“Random Access Flag Max Bit”として、最大で2ビットの表現が可能である。例えば0ならば、Random Access Flagは使用しない。2ならば最大値は3である。
【0142】
尚、実数部と仮数部による表現を行っても良い(例えば、3^6)。又、非設定時は、デフォルトで決められた状態で動作することにしても良い。
【0143】
図21では、“Setup Request”は、セットアップ時間を送信するための伝送表現を示している。プログラムを送信する前に“Setup Request”は送信され、伝送される伝送チャンネル番号(“Logical Channel Number”)と、実行するプログラムID(“excute Program Number”)、使用するデータID(“data Number”)、実行するコマンドのID(“execute CommandNumber”)を対応付けて受信端末へ送付する。また、別の表現方法として、伝送チャンネル番号と対応付けて、実行の許可のフラグ(“flag”)、あと何回Setup Requestを受信したら実行するかを記したカウンタ(“counter”)、あとどれくらいの時間で実行するかを示すタイマー値(“timer”)であってもよい。
【0144】
尚、要求予定のリクエストの例としては、AL情報の書き換え、Group Muxの立ち上がり時間の確保などがあげられる。
【0145】
図22は、図20で説明したALの使用の有無を送信端末から受信端末へ通知するための伝送表現について説明する図である(“Control AL definition”)。
【0146】
同図において、“Random Access Flag Use”が真ならばRandom Access Flagは使用する。そうでなければ使用しない。このALの変更通知は制御情報としてデータとは別の伝送チャンネルで伝送してもよいし、データとともに同一の伝送チャンネルで伝送してもよい。
【0147】
尚、実行するプログラムとしては、デコーダプログラムなどがあげられる。又、セットアップのリクエストは、放送であっても通信であっても利用出来る。又、制御情報としての項目を、ALの情報としてどの項目を使用するかを上記のリクエストで受信端末に指示する。又、同様に通信ヘッダにどの項目を、ALの情報としてどの項目を、制御情報としてごの項目を使用するかを受信端末に指示出来る。
【0148】
図23では、情報枠組み識別子(“header ID”)を用いて、伝送するヘッダ情報(データ管理情報、伝送管理情報、制御情報)の構造を送受信端末間で用途に応じて変更するための伝送表現の例を示している。
【0149】
同図において、“class ES header”は、データと同じ伝送チャンネルで伝送されるデータ管理情報や、伝送管理情報の伝送される情報の構造を、情報枠組み識別子により送受信端末間で区別している。
【0150】
例えば“header ID”の値が0ならば、buffer Size ESの項目だけ用い、“header ID”の値が1ならば“reserved”の項目を加えて用いる。
【0151】
又、デフォルト識別子(“use Header Extension”)を用いることでデフォルトの形式の情報の枠組みを用いるか、用いないかを判定する。“use Header Extension”が真であれば、if文の内部の項目が用いられる。これらの構造情報に関しては予め送受信端末間で取り決められているものとする。なお、情報枠組み識別子とデフォルト識別子は、何れか一方を使用する構成であってもよい。
【0152】
図24では、“AL configuration”は、データとは異なる伝送チャンネルで伝送される制御情報の構造を送受信端末間で用途に応じて変更する場合の例を示している。情報枠組み識別子とデフォルト識別子の使用方法は図23の場合と同じである。
【0153】
本発明では、複数の動画や音声を同時に合成して表示させるシステムの実現方法について、下記の観点から具体的に述べた。
【0154】
(1)複数の論理的な伝送路を用いて画像や音声の伝送(通信と放送)及び、それらを制御する方法。特に、制御情報とデータをそれぞれ、伝送する論理的な伝送路を独立させて伝送する方法について述べた。
【0155】
(2)送信すべき画像や音声のデータに付加するヘッダ情報(ALの情報)の動的な変更方法。
【0156】
(3)送信のために付加する通信用のヘッダ情報の動的な変更方法。
【0157】
具体的には、(2)と(3)に関しては、ALの情報と通信用ヘッダで重複している情報について統合して管理する方法や、ALの情報を制御情報として伝送する方法について述べた。
【0158】
(4)複数の論理的な伝送路を、動的に多重化、分離して情報の伝送を行う方法。
【0159】
伝送路のチャンネル数を節約する方法、効率的な多重化を実現する方法について述べた。
【0160】
(5)プログラムやデータの読み込み、立ち上げ時間を考慮した画像や音声の伝送方法。様々な機能、用途で見かけ上のセットアップ時間の短縮方法について述べた。
【0161】
(6)ザッピングに対する画像や音声の伝送方法。
【0162】
尚、本発明は、2次元の画像合成だけに限定されない。2次元の画像と3次元の画像を組み合わせた表現形式でもよいし、広視野画像(パノラマ画像)のように複数の画像を隣接するように画像合成するような画像合成方法も含めてもよい。
【0163】
また、本発明で対象としている通信形態は、有線の双方向CATVやB−ISDNだけではない。例えば、センター側端末から家庭側端末への映像や音声の伝送は電波(例えば、VHF帯、UHF帯)、衛星放送で、家庭側端末からセンター側端末への情報発信はアナログの電話回線やN−ISDNであってもよい(映像、音声、データも必ずしも多重化されている必要はない)。
【0164】
また、IrDA、PHS(パーソナル・ハンディー・ホン)や無線LANのような無線を利用した通信形態であってもよい。さらに、対象とする端末は、携帯情報端末のように携帯型の端末であっても、セットトップBOX、パーソナルコンピュータのように卓上型の端末であってもよい。なお、応用分野としては、TV電話、多地点の監視システム、マルチメディアのデータベース検索システム、ゲームなどが挙げられ、本発明は受信端末だけではなく、受信端末に接続されるサーバや中継の機器なども含まれる。
【0165】
さらに、これまでの例ではRTPの(通信)ヘッダとALの情報の重複を回避する方法や、RTPの通信ヘッダやALの情報を拡張する方法について述べた。しかし、本発明は、必ずしもRTPである必要はない。たとえば、UDPやTCPを使って独自の通信ヘッダやAL情報を新たに定義してもよい。インターネットプロファイルではRTPを使うことはあるが、RawプロファイルではRTPのような多機能なヘッダは定義されていない。AL情報と通信ヘッダに関する考え方としては、前述したように4通りの考え方ができる。
【0166】
このように、送信端末と受信端末で使用するデータ管理情報、伝送管理情報、制御情報の各情報の枠組み(例えば、1番最初は、ランダムアクセスのフラグで1ビットのフラグ情報として割り当て、2番めはシーケンス番号で16ビット割り当てるといった、付加する情報の順序とビット数をともなった情報の枠組み)を動的に決定することで、状況に応じた情報の枠組みの変更が可能になり、用途や伝送路に応じた変更ができる。
【0167】
尚、各情報の枠組みとしては、図6(a)〜図6(d)において既に示したものあってもよいし、RTPならば、データ管理情報(AL)はメディア毎のヘッダ情報(例えば、H.263ならH.263固有のビデオのヘッダ情報や、ペイロードのヘッダ情報)、伝送管理情報はRTPのヘッダ情報で、制御情報はRTCPのようなRTPを制御するような情報であってもよい。
【0168】
また、送受信端末間で予め設定されている公知の情報の枠組みで、情報の送受信して処理するか、否かを示すためのデフォルト識別子をデータ管理情報、伝送管理情報、制御情報(データとは別のパケットで伝送される、端末処理を制御する情報)に、それぞれ設けることで、情報の枠組みの変更が行われているかどうかを知ることができ、変更が行なわれている時だけ、デフォルト識別子をセットし、前述の図19〜図20に示したような方法で変更内容(たとえば、タイムスタンプ情報を32ビットから16ビットに変更する)を通知することで、情報の枠組み情報を変更しない場合でも不要にコンフィグレーション情報を送信しなくても済む。
【0169】
たとえば、データ管理情報の情報の枠組みを変更したいときには、次の2つの方法が考えられる。まず、データ自身にデータ管理情報の情報の枠組みの変更方法を記述する場合、データ管理情報の情報の枠組みに関して記述されたデータ内に存在する情報のデフォルト識別子(固定の領域、位置に書き込む必要がある)をセットし、そのあとに情報の枠組みの変更内容に関して記述する。
【0170】
もう1つの方法として制御情報(情報枠組み制御情報)にデータの情報の枠組みの変更方法を記述して、データ管理情報における情報の枠組みを変更する場合、制御情報に設けられたデフォルト識別子をセットし、変更するデータ管理情報の情報の枠組みの内容を記述し、ACK/Rejectで受信端末にデータ管理情報の情報の枠組みが変更されたことを通知、確認してから、情報の枠組みが変更されたデータを伝送する。伝送管理情報、制御情報自身の情報の枠組みを変更する場合も、同様に上記の2つの方法で実現できる(図23〜図24)。
【0171】
より具体的な例としては、例えば、MPEG2のヘッダ情報は固定であるが、MPEG2−TS(トランスポート・ストリーム)のビデオ・ストリーム、オーディオ・ストリームを関係づけるプログラム・マップテーブル(PSIで定義される)にデフォルト識別子を設け、ビデオ・ストリーム、オーディオ・ストリームの情報の枠組みの変更方法を記述したコンフィグレーション・ストリームを定義しておくことで、デフォルト識別子がセットされていれば、まず、コンフィグレーション・ストリームを解釈してから、コンフィグレーション・ストリームの内容に応じて、ビデオとオーディオのストリームのヘッダーを解釈することができる。コンフィグレーションストリームは図23〜図24で示した内容でよい。
【0172】
尚、本発明の、伝送方法に関する及び/又は伝送するデータの構造に関する内容(伝送フォーマット情報)は、上記実施の形態では、例えば、情報の枠組みに対応している。
【0173】
又、上記実施の形態では、変更しようとする、伝送方法に関する及び/又は伝送するデータの構造に関する内容を伝送する場合を中心に述べたが、これに限らず例えば、その内容の識別子のみを伝送する構成でも勿論良い。この場合、送信装置としては、例えば、図52に示す様に、(1)伝送方法に関する及び/又は伝送するデータの構造に関する内容、又はその内容を示す識別子を、伝送フォーマット情報として、前記伝送するデータの伝送路と同一の伝送路、又は、前記伝送路とは別の伝送路を用いて伝送する伝送手段5001と、(2)前記伝送方法に関する及び/又は伝送するデータの構造に関する内容と、その識別子とを複数種類格納する格納手段5002とを備え、前記識別子が、データ管理情報、伝送管理情報又は、端末側の処理を制御するための情報の内、少なくとも一つの情報の中に含まれている画像・音声送信装置であってもよい。又、受信装置としては、例えば、図53に示す様に、上記画像・音声送信装置から送信されてくる前記伝送フォーマット情報を受信する受信手段5101と、前記受信した伝送フォーマット情報を解釈する伝送情報解釈手段5102とを備えた画像・音声受信装置であってもよい。更に、この画像・音声受信装置は、前記伝送方法に関する及び/又は伝送するデータの構造に関する内容と、その識別子とを複数種類格納する格納手段5103を備え、前記伝送フォーマット情報として前記識別子を受信した場合には、前記識別子の内容を解釈する際に、前記格納手段に格納されている内容を利用する構成であっても良い。
【0174】
さらに、具体的には、予め情報の枠組みを複数、送受信端末で取り決めて用意しておき、それら複数種類の情報の枠組みの識別と、複数種のデータ管理情報、伝送管理情報、制御情報(情報枠組み制御情報)を識別するための情報枠組み識別子をデータとともに、もしくは、制御情報として伝送することで、複数種のデータ管理情報、伝送管理情報、制御情報の各情報を識別することが可能となり、伝送すべきメディアの形式や伝送路の太さに応じて各情報の情報の枠組みを自由に選択することができる。尚、本発明の識別子は、上記情報の枠組み識別子に対応する。
【0175】
これら情報の枠組み識別子、デフォルト識別子は、伝送される情報の予め決められた固定長の領域もしくは、位置に付加することで、受信側端末で、情報の枠組みが変更されていても読み取り、解釈することができる。
【0176】
又、上述した実施の形態で述べた構成以外に、複数個のチャンネルで放送される画像の見出し画像だけを放送する放送チャンネルを設け、視聴者が視聴番組を切り替えることで、必要となるプログラムやデータのセットアップに時間がかかる場合、一旦、視聴したい番組の見出し画像を選択して視聴者に提示する構成としても良い。
【0177】
以上のように本発明によれば、送信端末と受信端末で使用するデータ管理情報、伝送管理情報、制御情報の各情報の枠組みを動的に決定することで、状況に応じた情報の枠組みの変更が可能になり、用途や伝送路に応じた変更ができる。
【0178】
また、送受信端末間で予め設定されている公知の情報の枠組みで、情報の送受信して処理するか、否かを示すためのデフォルト識別子をデータ管理情報、伝送管理情報、制御情報に、それぞれ設けることで、情報の枠組みの変更が行われているかどうかを知ることができ、変更が行なわれている時だけ、デフォルト識別子をセットし、変更内容を通知することで、情報の枠組み情報を変更しない場合でも不要にコンフィグレーション情報を送信しなくても済む。
【0179】
さらに、予め情報の枠組みを複数、送受信端末で取り決めて用意しておき、複数種のデータ管理情報、伝送管理情報、制御情報を識別するための情報枠組み識別子をデータとともに、もしくは、制御情報として伝送することで、複数種のデータ管理情報、伝送管理情報、制御情報の各情報を識別することが可能となり、伝送すべきメディアの形式や伝送路の太さに応じて各情報の情報の枠組みを自由に選択することができる。
【0180】
これら情報枠組み識別子、デフォルト識別子は、伝送される情報の予め決められた固定長の領域もしくは、位置に付加することで、受信側端末で、情報の枠組みが変更されていても読み取り、解釈することができる。
【0181】
以下、本発明の実施の形態について図面を参照して説明する。
【0182】
尚、ここでは、主に上述した課題(B1)〜(B2)の何れか一つを解決するものである。
【0183】
本発明で使用する「画像」の意味は静止画と動画の両方を含む。また、対象とする画像は、コンピュータ・グラフィックス(CG)のような2次元画像とワイヤーフレーム・モデルから構成されるような3次元の画像データであってもよい。
【0184】
図31は、本発明の実施の形態における画像符号化、画像復号化装置の概略構成図である。
【0185】
符号化された種々の情報を送信もしくは記録する送信管理部4011は、同軸ケーブル、CATV、LAN、モデム等の情報を伝送する手段である。画像符号化装置4101は、H.263、MPEG1/2、JPEG、あるいは、ハフマン符号化といった画像情報の符号化を行う画像符号部4012と、上記送信管理部4011とを具備する構成である。又、画像復号化装置4102は、符号化された種々の情報を受信する受信管理部4013と、その受信された種々の画像情報の復号を行う画像復号部4014と、復号された1つ以上の画像を合成する画像合成部4015と、画像を出力するディスプレイやプリンターなどから構成される出力部4016とを備えた構成である。
【0186】
図32は、本発明の実施の形態における音声符号化、音声復号化装置の概略構成図である。
【0187】
音声符号化装置4201は、符号化された種々の情報を送信もしくは記録する送信管理部4021と、G.721、MPEG1オーディオといった音声情報の符号化を行う音声符号部4022とを具備する構成である。又、音声復号化装置4202は、符号化された種々の情報を受信する受信管理部4023と、前記種々の音声情報の復号を行う音声復号部4024と、復号された1つ以上の音声を合成する音声合成部4025と、音声を出力する出力部4026とを備えた構成である。
【0188】
音声や動画像の時系列データは、具体的には上記の各装置で、符号化、又は復号化される。
【0189】
図31、図32とも、通信環境としてはインターネットのように多重化の手段を意識せずに複数の論理的な伝送路が利用できる通信環境であってもよし、アナログ電話や衛星放送のように多重化手段を意識しなければならない通信環境であってもよい。また、端末の接続形態としては、TV電話やTV会議システムのように端末間で双方向で映像や音声を送受信する形態や、衛星放送やCATV、インターネット上での放送型の映像や音声放送の形態が挙げられる。
【0190】
同様に、画像や音声の合成方法に関しては、JAVA、VRML、MHEGといったスクリプト言語で、画像・音声と画像・音声の構造情報(表示位置や表示時間)、画像・音声同士のグルーピングの方法、画像の表示のレイヤ(深さ)、そして、オブジェクトID(画像、音声といった個々のオブジェクトを識別するためのID)と、これらの属性の関係を記述することによって画像や音声の合成方法が定義できる。合成方法を記述したスクリプトはネットワークやローカルの記憶装置から得られる。
【0191】
尚、画像符号化装置、画像復号化装置、音声符号化装置、音声復号化装置を、それぞれ任意の個数で、任意の組み合わせで送受信の端末を構成してもよい。
【0192】
図33(a)は、過負荷時の処理の優先度を管理する優先度付加部、優先度決定部について説明する図である。H.263やG.723などの符号化方法で、符号化された情報の過負荷時の処理の優先度を予め決められた基準で決定し、符号化された情報と決定された優先度を対応づける優先度付加部4031を画像符号化装置4101や音声符号化装置4201に備える。
【0193】
優先度の付加の基準は、たとえば、画像であればシーンチェンジ、編集者や利用者が指示した画像フレームやストリーム、音声であれば、有音区間と無音区間である。
【0194】
過負荷時の処理の優先度を定義する優先度の付加方法は、通信ヘッダへ付加する方法と符号化時にビデオやオーディオの符号化されるビットストリームのヘッダに埋め込む方法が考えられる。前者は、復号せずに優先度に関する情報が得ることが可能であり、後者はシステムに依存せずにビットストリーム単体で独立に扱うことが可能である。
【0195】
図33(b)に示したように、通信ヘッダに優先度情報を付加する場合、1つの画像フレーム(例たとえば、フレーム内符号化されたIフレーム、フレーム間符号化されたP、Bフレーム)が複数個の送信パケットに分割される場合、画像であれば単独の情報としてアクセス可能な画像フレームの先頭部分を伝送する通信ヘッダのみに優先度を付加する(同一の画像フレーム内で優先度が等しい場合、次のアクセス可能な画像フレームの先頭が現れるまで、優先度は変わらないものとすればよい)。
【0196】
また、復号化装置では、受信された種々の符号化された情報の過負荷時の優先度に従って、処理の方法を決定する優先度決定部4032を画像復号化装置4102や音声復号化装置4202に備える。
【0197】
図34〜図36は、優先度を付加する粒度について説明する図である。端末での過負荷時の処理の優先度を決定する2種類の優先度を用いて、デコード処理を行なう。
【0198】
すなわち、映像、音声といったビットストリーム単位での過負荷時の処理の優先度を定義するストリーム優先度(Stream Priority;時系列データ間優先度)と、同一ストリーム内の映像フレームといったフレーム単位での過負荷時の処理の優先度を定義するフレーム優先度(Frame Priority;時系列データ内優先度)を定義する(図34参照)。
【0199】
前者のストリーム優先度により複数のビデオやオーディオの取り扱いが可能になる。後者のフレーム優先度により映像のシーンチェンジや編集者の意図に応じて、同一のフレーム内符号化された映像フレーム(Iフレーム)でも異なる優先度の付加が可能になる。
【0200】
ストリーム優先度が表現する値の意味としては、相対的な値として扱う場合と、絶対的な値として扱う場合が考えられる(図35、図36参照)。
【0201】
ストリーム優先度とフレーム優先度の取り扱いが行なわれるのはネットワーク上であれば、ルータやゲートウェイといった中継端末、端末であれば、送信端末と受信端末があげられる。
【0202】
絶対的な値と、相対的な値の表現方法は2通り考えられる。1つは、図35で示した方法であり、もう1つは図36で示した方法である。
【0203】
図35では、絶対的な値の優先度とは、編集者や機械的に付加された画像ストリームや音声ストリームが過負荷時に処理される(又は、処理されるべき)順序をあらわす値である(実際のネットワークや端末の負荷変動を考慮した値ではない)。相対的な値の優先度は、端末やネットワークの負荷に応じて、絶対的な優先度の値を変更するための値である。
【0204】
優先度を相対的な値と、絶対的な値に分離して管理することで、ネットワークの負荷の変動などに応じて、送信側や中継装置で相対的な値だけを変更することで、元来、画像や音声ストリームに付加されていた絶対的な優先度を残したままで、ハードディスクやVTRへの記録が可能となる。このように絶対的な優先度の値が記録されていれば、ネットワークの負荷変動などの影響を受けていない形での映像や音声の再生が可能となる。なお、相対的な優先度や絶対的な優先度はデータとは独立に制御チャンネルを通して伝送してもよい。
【0205】
同様に、図35では、ストリーム優先度よりも粒度を細かくして、過負荷時のフレームの処理の優先度を定義するフレーム優先度を、相対的な優先度の値として扱ったり、絶対的な優先度の値として扱うことも可能である。たとえば、絶対的なフレーム優先度を符号化された画像の情報内に記述し、ネットワークや端末の負荷で変動を反映させるために、先の映像フレームに付加した絶対的な優先度に対する相対的なフレーム優先度を符号化された情報を伝送するための通信パケットの通信ヘッダに記述することで、フレームレベルでも、オリジナルの優先度を残しながらも、ネットワークや端末の負荷に応じた優先度の付加が可能である。
【0206】
なお、相対的な優先度は、通信ヘッダではなくデータとは独立して制御チャネルでフレームとの対応関係を記述して伝送してもよい。これにより、元来、画像や音声ストリームに付加されていた絶対的な優先度を残したままで、ハードディスクやVTRへの記録が可能となる。
【0207】
一方、図35において、受信端末で記録を行なわずに、ネットワークを介して伝送しながら受信端末で再生を行なう場合、受信端末で絶対的な値と相対的な値を分離して管理する必要がないため、送信側で予め、フレーム、ストリームの両方のレベルの場合においても、絶対値な優先度の値と相対的な優先度の値を送信前に計算して絶対値のみを送ってもよい。
【0208】
図36において、絶対的な値の優先度とは、Stream Priorityと、Frame Priorityの関係から求められるフレーム間で一意に決定される値である。相対的な値の優先度は、編集者や機械的に付加された画像ストリームや音声ストリームが過負荷時に処理される(又は、処理されるべき)順序をあらわす値である。図36の例では、映像、音声の各ストリームのフレーム優先度(relative;相対値)とストリーム毎にストリーム優先度が付加されている。
【0209】
絶対的なフレーム優先度(absolute;絶対値)は相対的なフレーム優先度と、ストリーム優先度の和から求められる(即ち、絶対的なフレーム優先度=相対的なフレーム優先度+ストリーム優先度)。なお、この算出方法は減算したり、定数を掛け合わせるような方法でもよい。
【0210】
絶対的なフレーム優先度は主としてネットワークで用いる。これはルータやゲイトウエイといった中継装置で、Stream PriorityとFramePriorityとを加味してフレーム毎の優先度を決定する必要が絶対値による表現では不要になるからである。この絶対的なフレーム優先度を用いることで中継装置でのフレームの廃棄などの処理が容易になる。
【0211】
一方、相対的なフレーム優先度は主として記録、編集を行なう蓄積系への応用が期待できる。編集作業では、複数の映像、音声ストリームを同時に扱うことがある。そのような場合に、端末やネットワークの負荷により再生できる映像ストリームやフレームの数には限界が生じる可能性がある。
【0212】
そのような場合に、Stream Priorityと、Frame Priorityとを分離して管理しておくだけで、例えば、編集者が、優先的に表示させたい、あるいは、ユーザが、見たいストリームのStream Priorityを変更するだけで、絶対値の表現を行なっている時とは違い、FramePriorityをすべて計算し直す必要がない。このように用途に応じて、絶対的な表現、相対的な表現を使い分ける必要がある。
【0213】
また、ストリーム優先度の値を相対的な値として用いるか、絶対的な値として用いるかを記述することで、伝送時にも、蓄積する場合にも有効な優先度の表現が可能となる。
【0214】
図35の例では、ストリーム優先度に付随して、ストリーム優先度が表現する値が絶対値であるか、相対値であるかを表現するフラグや識別子を設けて区別する。フレーム優先度の場合は、通信ヘッダに相対的な値が記述され、符号化されたフレーム内に絶対的な値が記述されるため、フラグや識別子は不要である。
【0215】
図36の例では、フレーム優先度が絶対値であるか相対値であるかを識別するためのフラグもしくは識別子を設けている。絶対値であれば、ストリーム優先度と相対的なフレーム優先度から算出されている優先度であるから、算出の処理を中継装置や端末で行なわない。また、受信端末では、算出式が端末間で既知である場合、絶対的なフレーム優先度とストリーム優先度から相対的なフレーム優先度を逆算することが可能である。例えば、伝送するパケットの絶対的な優先度(Access Unit Priority)を、Access Unit Priority=ストリーム優先度−フレーム優先度、という関係式から求めても良い。ここで、フレーム優先度は、ストリーム優先度を減算することから、劣後優先度と表現しても良い。
【0216】
さらに、1つ以上のストリーム優先度をTCP/IPの論理チャンネル(LANのポート番号)を流れるデータの処理の優先度に対応付けて、データの処理を管理してもよい。
【0217】
加えて、画像や音声は、文字もしくは制御情報よりも低いストリーム優先度やフレーム優先度を割り当てることで再送処理の必要が低減できることが期待できる。これは画像や音声は一部分が失われても、問題が発生しない場合も多いからである。
【0218】
図37は、多重解像度の画像データへ優先度の割り当て方法について説明する図である。
【0219】
1つのストリームが2つ以上の複数のサブストリームから構成される場合、サブストリームにストリーム優先度の付加を行い、蓄積時もしくは伝送時に論理和もしくは論理積の記述を行うことでサブストリームの処理方法の定義を行うことが可能である。
【0220】
ウェーブレットの場合、1つの映像フレームを複数の異なる解像度の映像フレームに分解することが可能である。また、DCTベースの符号化方式でも高周波の成分と低周波の成分に分割して符号化することで異なる解像度の映像フレームへの分解は可能である。
【0221】
分解された一連の映像フレームから構成される複数個の映像ストリームに付加されるストリーム優先度のほかに、映像のストリーム間の関係を記述するためにAND(論理積)とOR(論理和)で関係を定義する。具体的な使用方法は、ストリームAのストリーム優先度が5であり、ストリームBのストリーム優先度が10である場合(数字の少ない方が優先度が高い)、優先度によりストリームデータの廃棄ならば、ストリームBの方は廃棄されるが、ストリーム間の関係記述を行なうことで、ANDの場合にはストリームBの優先度が閾値の優先度よりも低くても、廃棄せずに伝送、処理するように定義しておく。
【0222】
これにより、関連のあるストリームは廃棄されずに処理できるようになる。ORの場合には逆に、廃棄可能であると定義する。これまでと同様に、廃棄処理は送受信端末でも行なっても、中継端末で行なってもよい。
【0223】
なお、関係記述のための演算子として、おなじビデオクリップを24Kbpsと48Kbpsの別のストリームに符号化した場合、どちらかを再生すれば良いという場合がある(関係記述として排他的論理和EX−OR)。
【0224】
前者の優先度を10、後者を5としてある場合、ユーザは優先度に基づいて後者を再生してもよいし、優先度に従わずユーザは後者を選んでもよい。
【0225】
図38は通信ペイロードの構成方法について説明する図である。
【0226】
複数のサブストリームから構成される場合、サブストリームに付加したストリーム優先度に応じて、たとえば優先度の高い順に、送信パケットを構成することで送信パケットレベルでの廃棄が容易になる。また、粒度を細かくして、フレーム優先度の高いオブジェクト同士の情報をひとつにまとめて通信パケットを構成しても通信パケットレベルでの廃棄が容易になる。
【0227】
なお、画像のスライス構造を通信パケットに対応付けることでパケット落ちしたときの復帰が容易である。つまり、動画像のスライス構造をパケットの構造に対応付けることで、再同期のためのリシンクマーカーが不要になる。スライス構造と通信パケットの構造が一致していなければ、パケット落ちなどで情報が損失した場合、再同期ができるようにリシンクマーカー(復帰する位置を知らせるための印)を付加する必要がある。
【0228】
これにあわせて、優先度の高い通信パケットには高いエラープロテクションをかけることが考えられる。なお、画像のスライス構造とはGOBやMBといったまとまった画像情報の単位をさす。
【0229】
図39はデータを通信ペイロードへ対応づける方法について説明する図である。ストリームやオブジェクトの通信パケットへの対応付けの方法を制御情報もしくはデータとともに伝送することで、通信状況や用途に応じて任意のデータフォーマットが生成できる。たとえば、RTP(Real time Transfer Protocol)では、扱う符号化毎にRTPのペイロードが定義されている。現行のRTPの形式は固定である。H.263の場合、同図に示したように、Mode AからMode Cの3つのデータ形式が定義されている。H.263では、多重解像度の映像フォーマットを対象とした通信ペイロードは定義されていない。
【0230】
同図の例では、Layer No.と前述の関係記述( AND、OR )を、Mode Aのデータフォーマットに追加して定義している。
【0231】
図40は、フレーム優先度、ストリーム優先度と通信パケット優先度との対応について説明する図である。
【0232】
又、同図は、伝送路で通信パケットに付加される優先度を通信パケット優先度とし、ストリーム優先度やフレーム優先度を、通信パケット優先度に対応させる例である。
【0233】
通常、IPを利用した通信では、画像や音声データに付加されたフレーム優先度やストリーム優先度を下位のIPパケットの優先度にパケットに対応付けてデータを伝送する必要がある。画像や音声データは分割され、IPのパケットに分割されて伝送されるため優先度の対応付けが必要がある。図の例では、ストリーム優先度は0から3までの値をとり、フレーム優先度は0から5までの値をとるため、上位のデータでは0から15までの優先度を取りうる。
【0234】
IPv6では優先度(4ビット)のうち0から7までは輻輳制御されたトラフィックのために予約されている、優先度のうち8から15までは実時間通信トラフィックまたは輻輳制御されていないトラフィックのために予約されている。優先度15は最も優先度が高く、優先度8が最も優先度が低い。これはIPのパケットのレベルでの優先度になる。
【0235】
IPを使ったデータの伝送では上位の0から15までの優先度を下位のIPの優先度である8から15までの優先度に対応付ける必要がある。対応付けは上位の優先度の一部をクリッピングする方式でもよいし、評価関数をもうけて対応付けてもよい。上位のデータと下位のIPの優先度の対応付けは、中継ノード(ルータやゲートウェイなど)、送受信端末で管理を行う。
【0236】
なお、伝送手段はIPだけに限定されるわけではなく、ATMやMPEG2のTS(トランスポート・ストリーム)のように廃棄可能かそうでないかのフラグをもった伝送パケットを対象としてもよい。
【0237】
これまでに述べた、フレーム優先度とストリーム優先度は、伝送媒体やデータ記録媒体へ適用が可能である。データ記録媒体としてフロッピーディスク、光ディスクなどを用いて行うことができる。
【0238】
また、記録媒体はこれに限らず、ICカード、ROMカセット等、プログラムを記録できるものであれば同様に実施することができる。さらに、データの中継を行うルータやゲートウェイといった画像音声中継装置を対象としてもよい。
【0239】
加えて、Stream Priority(時系列データ間優先度)や、Frame Priority(時系列データ内優先度)の情報に基づいて再送すべき時系列データを決定することで、優先的な再送処理が可能となる。たとえば、優先度情報に基づいて受信端末でデコードを行なっている場合、処理の対象外であるストリームやフレームの再送を防止することができる。
【0240】
また、現在の処理対象となっている優先度とは別に、再送回数と送信成功回数の関係から再送すべき優先度のストリームやフレームを決定してもよい。
【0241】
一方、送信側の端末においても、Stream Priority(時系列データ間優先度)やFrame Priority(時系列データ内優先度)の情報に基づいて送信すべき時系列データを決定することで、優先的な送信処理が可能となる。たとえば、平均転送レートや、再送回数に基づいて送信すべきストリームやフレームの優先度を決定することで、ネットワークが過負荷である際にも適応的な映像や音声の伝送が可能になる。
【0242】
なお、上記実施の形態は、2次元の画像合成だけに限定したものではない。2次元の画像と3次元の画像を組み合わせた表現形式でもよいし、広視野画像(パノラマ画像)のように複数の画像を隣接するように画像合成するような画像合成方法も含めてもよい。また、本発明で対象としている通信形態は、有線の双方向CATVやB−ISDNだけではない。たとえば、センター側端末から家庭側端末への映像や音声の伝送は電波(例えば、VHF帯、UHF帯)、衛星放送で、家庭側端末からセンター側端末への情報発信はアナログの電話回線やN−ISDNであってもよい(映像、音声、データも必ずしも多重化されている必要はない)。また、IrDA、PHS(パーソナル・ハンディー・ホン)や無線LANのような無線を利用した通信形態であってもよい。
【0243】
さらに、対象とする端末は、携帯情報端末のように携帯型の端末であっても、セットトップBOX、パーソナルコンピュータのように卓上型の端末であっても良い。
【0244】
以上のように本発明によれば、複数のビデオストリームや複数のオーディオストリームの取り扱いや、編集者の意図を反映させて、重要なシーンカットを重点的にオーディオとともに同期再生をさせることが容易となる。
【0245】
以下に本発明の実施の形態を図面を参照しながら説明する。
【0246】
尚、ここで述べる実施の形態は、主に、上述した課題(C1)〜(C3)の何れかを解決するものである。
【0247】
図41は第1の実施の形態である送信装置の構成を示すものである。2101は画像入力端子であって、一枚の画像サイズは例えば縦144画素、横176画素である。2102は動画像符号化装置であって、4つの構成要素1021,1022,1023,1024から成る(Recommendation H.261参照)。
【0248】
1021は入力された画像をマクロブロック(縦16画素、横16画素の正方形領域)に分割し、このブロックの符号化を、イントラ/インタどちらで符号化するかを決定する切替器、1022は前回の符号化結果から計算できるローカルデコード画像をもとに動き補償画像を作成し、これと入力画像との差分を計算し、結果をマクロブロック単位に出力する動き補償手段であって、動き補償には、処理時間の長いハーフペル動き補償と処理時間の短いフルペル動き補償がある。1023はそれぞれのマクロブロックに対してDCT変換を施す直交変換手段、1024はこのDCT変換結果及び他の符号化情報に対してエントロピー符号化を施すための可変長符号化手段である。
【0249】
2103は計数手段であって、動画像符号化装置2102の4つの構成要素の実行回数を計数し、入力画像ごとに、結果を変換手段に出力する。この時、動き補償手段1022からは、ハーフペルとフルペルの2通りについてそれぞれの実行回数を計数する。
【0250】
2104は変換手段であって、図42に示すようなデータ列を出力する。2105は送信手段であって、動画像符号化装置2102からの可変長符号と、変換手段2104からのデータ列を多重化して、一本のデータ列とし、データ出力端子2109に出力するものである。
【0251】
以上の構成により、受信装置に、必須処理(切替器1021,直交変換手段1023,可変長符号化手段1024)と非必須処理(動き補償手段1022)の各実行回数を伝達することができる。
【0252】
次に、図48は、第2の実施の形態である送信方法のフローチャートである。
【0253】
本実施の形態における動作が第1の実施の形態と似ているので、対応する要素を付記しておく。801にて、画像を入力し(画像入力端子2101)、802にて画像をマクロブロックに分割する。以降、807の条件分岐により、すべてのマクロブロックに対する処理を完了するまで、803から806までの処理を繰りかえす。なお、803から806までの処理の回数を、特定の変数に記録できるように、それぞれの処理を実行した場合には、対応する変数を1だけインクリメントする。
【0254】
まず、803にて、処理対象のマクロブロックをイントラ/インタどちらで符号化するかを判定する(切替器1021)。インタの場合は、804にて動き補償を行う(動き補償手段1022)。その後、805,806にて、DCT変換、可変長符号化を、行う(直交変換手段1023,可変長符号化手段1024)。すべてのマクロブロックに対する処理を完了したら(807にてYesの時)、808にて、それぞれの処理に対応する実行回数を示す変数を読み、図2に示すようなデータ列を生成し、このデータ列と符号とを多重化し、出力する。以上の801から808までの処理を、入力画像が続くかぎり、繰り返し実行する。
【0255】
以上の構成により、各処理の実行回数を送信することができる。
【0256】
次に、図43は第3の実施の形態である受信装置の構成を示すものである。
【0257】
同図において、307は第1の実施の形態の送信装置の出力を入力するための入力端子、301は第1の実施の形態の送信装置の出力をもとに可変長符号とデータ列を逆多重化により取り出し出力する受信手段であって、この時、一枚分のデータを受信するのに要した時間を計測しておき、これも出力するものとする。
【0258】
303は可変長符号を入力とする動画像の復号化装置であって、5つの構成要素から成る。3031は可変長符号からDCT係数及び他の符号化情報を取り出すための可変長復号化手段、3032はDCT係数に対して逆DCT変換処理を施す逆直交変換手段、3033は切替器であって、マクロブロックごとに、イントラ/インタどちらで符号化されているかの符号化情報に基づき、出力を上下に振りわける動作をする。3034は動き補償手段であって、前回の復号画像と動きの符号化情報とを用い、動き補償画像を作成し、この画像に逆直交変換手段3032の出力を加算して出力する。3035は実行時間計測手段であって、復号化装置303に可変長符号が入力されてから画像の復号化及び出力を完了するまでの実行時間を計測し、これを出力する。302は、受信手段301からのデータ列から各要素(可変長復号化手段3031,逆直交変換手段3032,切替器3033,動き補償手段3034)の実行回数と、実行時間計測手段3035から実行時間とを受け取り、各要素の実行時間を推定する推定手段である。
【0259】
推定方法は、例えば、線型回帰を用いれば、推定実行時間を目的変数y、各要素の実行回数を説明変数x_iとすれば良い。この場合、回帰パラメタa_iは、各要素の実行時間とみなせるであろう。また、線型回帰の場合、過去のデータを充分多く蓄積しておく必要があり、メモリを沢山消費することになるが、これを嫌う場合には、カルマンフィルタによる内部状態変数の推定を利用しても良い。この場合、観測値が実行時間、各要素の実行時間を内部状態変数とし、観測行列Cが各要素の実行回数でステップごとに変化する場合、と考えれば良い。304は、フルペル動き補償の実行回数を減らし、相当数だけハーフペル動き補償の実行回数を増やすように、各要素の実行回数を変更する回数削減手段である。この相当数の計算方法は、以下の通りである。
【0260】
まず、推定手段302から各要素の実行回数と推定実行時間とを受けとり、実行時間を予想する。この時間が、受信手段301からのデータを受信するのに要した時間を越える場合に、越えなくなるまで、フルペル動き補償の実行回数を増やし、ハーフペル動き補償の実行回数を減らす。306は復号化画像の出力端子である。
【0261】
なお、動き補償手段3034は、符号化情報からハーフペル動き補償を行うよう指示されている場合であるが、ハーフペル動き補償の所定実行回数を越えてしまった場合には、ハーフペルの動きを丸めて、フルペルの動きとして、フルペル動き補償を実行する。
【0262】
以上にて説明した第1の実施の形態、第3の実施の形態によれば、推定された各要素の実行時間から復号化処理の実行時間を予測し、これが一枚分のデータを受信するのに要した時間(指定時間)を越えるようであれば、実行時間の長いハーフペルの動き補償を、フルペルの動き補償で置き替える。これによって、実行時間が指定時間を越えないようにでき、課題(C1)を解決することができる。
【0263】
なお、受信装置でのIDCT計算において、高周波成分を使用しないようにすることで、IDCT計算の処理時間を減らすことができる。つまり、IDCT計算のうち、低周波成分の計算を必須処理、高周波成分の計算を非必須処理とみなして、IDCT計算の高周波成分の計算回数を削減するようにしても良い。
【0264】
次に、図49は、第4の実施の形態である受信方法のフローチャートである。
【0265】
本実施の形態における動作が第3の実施の形態と似ているので、対応する要素を付記しておく。ステップ901にて各要素の実行時間を表現する変数a_iを初期化する(推定手段302)。902にて多重化データの入力と、これに要する時間の計測を行う(受信手段301)。903にてこの多重化データを、可変長符号とデータ列とに分離し、出力する(受信手段301)。904にてデータ列(図2)から各実行回数を取り出し、これらをx_iに設定する。905にて、各要素の実行時間a_iと各実行回数x_iとから、実際の実行回数を算出する(回数削減手段304)。906にて、復号化処理の実行時間の計測を開始し、907にて後述する復号化処理ルーチンを起動し、その後、908にて復号化処理の実行時間の計測を終了する(動画像の復号化装置303,実行時間計測手段3035)。908では、908での復号化処理の実行時間と905での各要素の実際の実行回数とから各要素の実行時間を推定し、a_iを更新する(推定手段302)。以上の処理を入力される多重化データごとに実行する。
【0266】
また、復号化処理ルーチン907では、910にて可変長復号化を行い(可変長復号化手段3031)、911にて逆直交変換を行い(逆直交変換手段3032)、912にて、910での処理で取り出されたイントラ/インタの情報で分岐する(切替器3033)。インタの場合は、913にて動き補償を施す(動き補償手段3034)。この913にて、ハーフペル動き補償の実行回数を計数しておき、これが905で求めた実際の実行回数を越えた場合には、ハーフペル動き補償をフルペル動き補償で置き替えて実行する。以上の処理を、すべてのマクロブロックについて完了後(ステップ914)、このルーチンを終了する。
【0267】
以上にて説明した第2の実施の形態、第4の実施の形態によれば、推定された各要素の実行時間から復号化処理の実行時間を予測し、これが一枚分のデータを受信するのに要した時間(指定時間)を越えるようであれば、実行時間の長いハーフペルの動き補償を、フルペルの動き補償で置き替える。これによって、実行時間が指定時間を越えないようにでき、課題(C1)を解決することができる。
【0268】
次に、図44は第5の実施の形態である受信装置の構成を示すものである。
【0269】
本実施の形態のほとんどの構成要素は、第2の実施の形態で説明したのと同じであり、2つの構成要素の追加と、1つの構成要素の修正のみであるのでその点を説明する。
【0270】
402は第2の実施の形態で説明した推定手段302に推定の結果得た各要素の実行時間を、回数制限手段304への出力とは別に、出力するよう修正したものである。408は送信手段であって、各要素の実行時間から図45に示すようなデータ列を生成し、これを出力するものである。実行時間は、マイクロセコンドを単位として、16bitで表現すれば最大で、約65ミリセコンドを表現できるので、充分であろう。409はこのデータ列を送信手段に送るための出力端子である。
【0271】
また、この第5の実施の形態に対応する受信方法は、図45に示すようなデータ列を生成するステップを図48の808の直後に追加したもので良い。
【0272】
次に、図46は第6の実施の形態である送信装置の構成を示すものである。
【0273】
本実施の形態のほとんどの構成要素は、第1の実施の形態で説明したのと同じであり、2つの構成要素の追加のみであるのでその点を説明する。606は第3の実施の形態の受信装置の出力するデータ列を受信するための入力端子、607はこのデータ列を受信し、各要素の実行時間を出力する受信手段である。608は、各要素の実行回数を求める決定手段であって、その手順は以下の通りである。まず、画像中のすべてのマクロブロックについて、切替器1021での処理を行い、この時点での切替器1021の実行回数を求める。また、このあとの、動き補償手段1022、直交変換手段1023,可変長符号化手段1024での実行回数は、この時点までの処理結果によって、一意に決定できる。そこで、これら実行回数と、受信手段607からの実行時間を用いて、受信装置側での復号化に要する実行時間を予測する。この予測復号化時間は、各要素の実行時間と実行回数の積の、要素ごとの総和として、求まる。そして、予測復号化時間が、レートコントローラなどが指定した今回の画像で発生すべき符号量(例えば16kbits)の伝送に要する時間(例えば、伝送速度が64kbit/secなら250msec)以上であれば、復号化時間が伝送に要する時間を越えないように、フルペル動き補償の実行回数を増やし、ハーフペル動き補償の実行回数を減らす(フルペル動き補償のほうが、実行時間が短いので、これの回数を減らすことで実行時間を小さくすることができる。)。
【0274】
なお、動画像の符号化装置2102は、決定手段608の指定した実行回数に基づき、各処理を行う。例えば、動き補償手1022は、指定されたハーフペルの動き補償実行回数分だけ、ハーフペル動き補償を実行完了すれば、その後は、フルペルの動き補償だけを実行するようになる。
【0275】
また、ハーフペルの動き補償が、画像中に一様にちらばるように、選択方法を工夫しても良い。たとえば、まず、ハーフペルの動き補償を必要とするマクロブロックをすべて求め、この数(例えば12)をハーフペルの動き補償実行回数(例えば4)で割った商(3)を求め、ハーフペルの動き補償を必要とするマクロブロックの始めからの順序が、この商で割りきれるもの(0,3,6,9)だけにハーフペルの動き補償を施す、という方法でも良い。
【0276】
以上にて説明した第5の実施の形態、第6の実施の形態によれば、推定された各要素の実行時間を送信側に伝送し、送信側にて復号化処理の実行時間を予測し、これが一枚分のデータを受信するのに要するであろう時間(指定時間)を越えないように実行時間の長いハーフペルの動き補償を、フルペルの動き補償で置き替える。これによって、送られた符号化情報のうち、ハーフペル動き補償の情報が捨てられることなく、実行時間が指定時間を越えないようにでき、課題(C2)を解決することができる。
【0277】
なお、非必須処理において、インターマクロブロック符号化を普通の動き補償、8x8動き補償、オーバラップ動き補償の3つに分割しても良い。
【0278】
次に、図50は、第7の実施の形態である送信方法のフローチャートである。
【0279】
本実施の形態における動作が第6の実施の形態と似ているので、対応する要素を付記しておく。1001にて、各処理の実行時間の初期値を設定する。801にて画像を入力し(入力端子2101)、にて画像をマクロブロックに分割する。1002にて、すべてのマクロブロックについて、イントラ/インタどちらで符号化するかを判定する(切替器1021)。この結果、1005から806までの各処理の実行回数がわかるので、1003では、この実行回数と、各処理の実行時間とから、実際の実行回数を算出する(決定手段608)。
【0280】
以降、807の条件分岐により、すべてのマクロブロックに対する処理を完了するまで、1005から806までの処理を繰りかえす。
【0281】
なお、1005から806までの処理の回数を、特定の変数に記録できるように、それぞれの処理を実行した場合には、対応する変数を1だけインクリメントする。まず、1005にて、1002での判定結果に基き、分岐する(切替器1021)。インタの場合は、804にて動き補償を行う(動き補償手段1022)。ここで、ハーフペル動き補償の回数を計数しておき、これが1003で求めた実際の実行回数を越えた場合には、ハーフペル動き補償を実行せずかわりにフルペル動き補償を実行する。その後、805,806にて、DCT変換、可変長符号化を、行う(直交変換手段1023,可変長符号化手段1024)。すべてのマクロブロックに対する処理を完了したら(807にてYesの時)、808にて、それぞれの処理に対応する実行回数を示す変数を読み、図2に示すようなデータ列を生成し、このデータ列と符号とを多重化し、出力する。1004では、データ列を受信し、これから各処理の実行時間を取り出し、設定する。
【0282】
以上の801から1004までの処理を、入力画像が続くかぎり、繰り返し実行する。
【0283】
以上にて説明した、第5の実施の形態の説明部分の最後の「また」で始まるパラグラフと、第7の実施の形態とによれば、推定された各要素の実行時間を送信側に伝送し、送信側にて復号化処理の実行時間を予測し、これが一枚分のデータを受信するのに要するであろう時間(指定時間)を越えないように実行時間の長いハーフペルの動き補償を、フルペルの動き補償で置き替える。これによって、送られた符号化情報のうち、ハーフペル動き補償の情報が捨てられることなく、実行時間が指定時間を越えないようにでき、課題(C2)を解決することができる。
【0284】
次に、図47は第8の実施の形態である送信装置の構成を示すものである。
【0285】
本実施の形態のほとんどの構成要素は、第1の実施の形態で説明したのと同じであり、4つの構成要素の追加のみであるのでその点を説明する。
【0286】
7010は実行時間計測手段であって、符号化装置2102に画像が入力されてから画像の符号化及び符号の出力を完了するまでの実行時間を計測し、これを出力する。706は、計数手段2103からのデータ列からの各要素(切替器1021、動き補償手段1022、直交変換手段1023,可変長復号化手段1024)の実行回数と、実行時間計測手段7010からの実行時間とを受け取り、各要素の実行時間を推定する推定手段である。推定方法は、第2の実施の形態の推定手段302で説明したものと同じで良い。707はユーザからのフレームレート値を入力するための入力端子、708は、各要素の実行回数を求める決定手段であって、その手順は以下の通りである。
【0287】
まず、画像中のすべてのマクロブロックについて、切替器1021での処理を行い、この時点での切替器1021の実行回数を求める。また、このあとの、動き補償手段1022、直交変換手段1023,可変長符号化手段1024での実行回数は、この時点までの処理結果によって、一意に決定できる。つぎに、この実行回数と推定手段706からの各要素の推定実行時間との積の、要素ごとの総和を求め予測符号化時間を算出する。そして、予測符号化時間が、707からのフレームレートの逆数から求まる一枚の画像の符号化に使用可能な時間以上であれば、フルペル動き補償の実行回数を増やし、ハーフペル動き補償の実行回数を減らす。
【0288】
この増減処理と予測符号化時間の算出とを、予測符号化時間が使用可能な時間以下になるまで、繰り返すことで、それぞれの実行回数を決定する。
【0289】
なお、動画像の符号化装置2102は、決定手段608の指定した実行回数に基づき、各処理を行う。例えば、動き補償手1022は、指定されたハーフペルの動き補償実行回数分だけ、ハーフペル動き補償を実行完了すれば、その後は、フルペルの動き補償だけを実行するようになる。
【0290】
また、ハーフペルの動き補償が、画像中に一様にちらばるように、選択方法を工夫しても良い。たとえば、まず、ハーフペルの動き補償を必要とするマクロブロックをすべて求め、この数(例えば12)をハーフペルの動き補償実行回数(例えば4)で割った商(3)を求め、ハーフペルの動き補償を必要とするマクロブロックの始めからの順序が、この商で割りきれるもの(0,3,6,9)だけにハーフペルの動き補償を施す、という方法でも良い。
【0291】
以上示した第8の実施の形態によれば、各処理の実行時間を推定し、この推定実行時間に基き、符号化に要する実行時間を予め予測し、この予測符号化時間が、フレームレートから決まる画像の符号化に使用可能な時間以下になるように、実行回数を決定することにより、課題(C3)を解決することができる。
【0292】
なお、動き補償手段1022では、動きベクトルを検出するために、左右上下15画素の範囲のベクトルのうち、もっともSAD(画素ごとに差の絶対値の和)を小さくするものを検出するフルサーチ動きベクトル検出方法存在するが、これ以外に、3step動きベクトル検出方法というものもある(H.261のannex.に記述がある)。これは、上記の探索範囲にて均等な配置関係の9点を選び、これのSAD最小の点を選ぶ。次に、この点の近傍のせばめた範囲にて、再度、9点を選び、SAD最小の点を選ぶ。このような処理をもう一度実行するのが、3step動きベクトル検出方法である。
【0293】
これら2つの方法を、非必須処理方法とみなし、実行時間をそれぞれ推定し、推定実行時間にもとづき、符号化に要する実行時間を予測し、この予測実行時間がユーザ指定時間以下になるように、適宜、フルサーチ動きベクトル検出方法の実行回数を減らし、かわりに3step動きベクトル検出方法の実行回数を増やすようにしても良い。
【0294】
さらに、3step動きベクトル検出方法以外に、もっと処理を簡略化した固定探索回数による動きベクトル検出方法や、(0,0)動きベクトルのみを結果として返す動きベクトル検出方法を併用しても良い。
【0295】
次に、図51は、第9の実施の形態である送信方法のフローチャートである。
【0296】
本実施の形態における動作が第8の実施の形態と似ているので、対応する要素を付記しておく。各フローでの詳しい動作は、対応する要素の説明を参照のこと。また、第2の実施の形態とほぼ同じであるので、異なる点のみを説明する。
【0297】
1101にて各処理の実行時間の初期値を変数a_iに設定する。また、1102にてフレームレートを入力する(入力端子707)。l103は、1102でのフレームレート、各処理の実行時間a_i、1002でのイントラ/インタ判定結果から求まる各処理の実行回数、とから実際の実行回数を決定する(決定手段708)。1105,1106は、符号化処理の実行時間を計測するためのものである。1104は、1106での実行時間と各処理の実際の実行回数とから各処理の実行時間を推定し、変数a_iを更新する(推定手段706)。
【0298】
以上示した第9の実施の形態によれば、各処理の実行時間を推定し、この推定実行時間に基き、符号化に要する実行時間を予め予測し、この予測符号化時間が、フレームレートから決まる画像の符号化に使用可能な時間以下になるように、実行回数を決定することにより、課題(C3)を解決することができる。
【0299】
なお、第2の実施の形態において、808でのデータ列生成時に、図2に示すスタートコードの直後に、2バイトの領域を追加し、ここに、符号の長さの二進表現を追加しても良い。
【0300】
さらに、第4の実施の形態において、902での多重化データの入力時にこの2バイトの領域から符号の長さを抽出し、この符号長さと、符号の伝送速度とから求まる符号の伝送時間を、905での実行回数計算に用いるようにしても良い(符号の伝送時間を越えないように、ハーフペル動き補償の実行回数を減らす)。
【0301】
なお、第1の実施の形態において、2104でのデータ列生成時に、図2に示すスタートコードの直後に、2バイトの領域を追加し、ここに、符号の長さの二進表現を追加しても良い。
【0302】
さらに、第3の実施の形態において、301での多重化データの入力時にこの2バイトの領域から符号の長さを抽出し、この符号長さと、符号の伝送速度とから求まる符号の伝送時間を、304での実行回数計算に用いるようにしても良い(符号の伝送時間を越えないように、ハーフペル動き補償の実行回数を減らす)。
【0303】
また、第4の実施の形態において、909直後に、ハーフペル動き補償の実際の実行回数を記録し、これの最大値を算出する。そして、この最大値が充分小さな値(例えば、2とか3)以下の場合には、ハーフペル動き補償を使用しないことを示すデータ列(特定のビットパターンから成るデータ列)を生成し、これを送信しても良い。さらに、第2の実施の形態において、808直後にて、このデータ列の受信有無を確認し、ハーフペル動き補償を使用しないことを示すデータ列を受信した場合には、808にて動き補償の処理を常にフルペル動き補償とするようにしても良い。
【0304】
さらに、動き補償以外にも、この考えを適用できる。たとえば、DCT計算で、高周波成分を使用しないようにすることで、DCT計算の処理時間を減らすことができる。つまり、受信方法にて、IDCT計算の実行時間の全体の実行時間に占める割合が一定値を越える場合には、その旨を示すデータ列を送信側に伝送する。送信側では、このデータ列を受信した場合には、DCT計算において低周波成分のみを計算し、高周波成分はすべて0にしても良い。
【0305】
さらに、ここでは、画像を用いて実施の形態を説明したが、画像以外の音声などに、上記の各方法を適用しても良い。
【0306】
また、第3の実施の形態において、3034にて、ハーフペル動き補償の実際の実行回数を記録し、これの最大値を算出する。そして、この最大値が充分小さな値(例えば、2とか3)以下の場合には、ハーフペル動き補償を使用しないことを示すデータ列(特定のビットパターンから成るデータ列)を生成し、これを送信しても良い。さらに、第1の実施の形態において、ハーフペル動き補償を使用しないことを示すデータ列を受信した場合には、1022での動き補償の処理を常にフルペル動き補償とするようにしても良い。
【0307】
さらに、動き補償以外にも、この考えを適用できる。たとえば、DCT計算で、高周波成分を使用しないようにすることで、DCT計算の処理時間を減らすことができる。つまり、受信方法にて、IDCT計算の実行時間の全体の実行時間に占める割合が一定値を越える場合には、その旨を示すデータ列を送信側に伝送する。
【0308】
送信側では、このデータ列を受信した場合には、DCT計算において低周波成分のみを計算し、高周波成分はすべて0にしても良い。
【0309】
さらに、ここでは、画像を用いて実施の形態を説明したが、画像以外の音声などに、上記の方法を適用しても良い。
【0310】
以上説明したところから明らかなように、例えば第1の実施の形態、第3の実施の形態によれば、推定された各要素の実行時間から復号化処理の実行時間を予測し、これが一枚分のデータを受信するのに要した時間(指定時間)を越えるようであれば、実行時間の長いハーフペルの動き補償を、フルペルの動き補償で置き替える。これによって、実行時間が指定時間を越えないようにでき、課題(C1)を解決することができる。
【0311】
また、例えば第5の実施の形態、第7の実施の形態によれば、推定された各要素の実行時間を送信側に伝送し、送信側にて復号化処理の実行時間を予測し、これが一枚分のデータを受信するのに要するであろう時間(指定時間)を越えないように実行時間の長いハーフペルの動き補償を、フルペルの動き補償で置き替える。これによって、送られた符号化情報のうち、ハーフペル動き補償の情報が捨てられることなく、実行時間が指定時間を越えないようにでき、課題(C2)を解決することができる。
【0312】
また、例えば第9の実施の形態によれば、各処理の実行時間を推定し、この推定実行時間に基き、符号化に要する実行時間を予め予測し、この予測符号化時間が、フレームレートから決まる画像の符号化に使用可能な時間以下になるように、実行回数を決定することにより、課題(C3)を解決することができる。
【0313】
このように、本発明により、計算負荷が増大してもゆるやかに品質を落とす機能(CGD:Computational Graceful Degradation)を実現出来、実施に伴う利益は非常に大である。
【0314】
又、以上述べてきた実施の形態の何れか一つに記載の各ステップ(又は、各手段)の全部又は一部のステップ(又は、各手段の動作)をコンピュータに実行させるためのプログラムを記録した磁気記録媒体や、光記録媒体などの記録媒体を作成し、その記録媒体を用いてコンピュータにより上記と同様の動作を行っても良い。
【0315】
【発明の効果】
以上説明したように、本発明によれば、例えば、複数のビデオストリームや複数のオーディオストリームの取り扱いや、編集者の意図を反映させて、重要なシーンカットを重点的にオーディオとともに同期再生をさせることが容易となる。
【図面の簡単な説明】
【図1】本発明の実施例における画像音声送受信装置の概略構成図
【図2】受信管理部と分離部とを示す図
【図3】複数の論理的な伝送路を用いて画像や音声の伝送、制御する方法を示す図
【図4】送信すべき画像や音声のデータに付加するヘッダ情報の動的な変更方法を示す図
【図5】(a)〜(b):AL情報の付加方法を示す図
【図6】(a)〜(d):AL情報の付加方法の例を示す図
【図7】複数の論理的な伝送路を動的に多重化、分離して情報の伝送を行う方法を示す図
【図8】放送番組の伝送手順を示す図
【図9】(a):プログラム、データが受信端末にある場合における、プログラムやデータの読み込み、立ち上げ時間を考慮した画像や音声の伝送方法を示す図
(b):プログラム、データが送信される場合における、プログラムやデータの読み込み、立ち上げ時間を考慮した画像や音声の伝送方法を示す図
【図10】(a)〜(b):ザッピングに対する対応方法を示す図
【図11】実際に端末間で送受信されるプロトコルの具体例を示す図
【図12】実際に端末間で送受信されるプロトコルの具体例を示す図
【図13】実際に端末間で送受信されるプロトコルの具体例を示す図
【図14】実際に端末間で送受信されるプロトコルの具体例を示す図
【図15】実際に端末間で送受信されるプロトコルの具体例を示す図
【図16】実際に端末間で送受信されるプロトコルの具体例を示す図
【図17】実際に端末間で送受信されるプロトコルの具体例を示す図
【図18】実際に端末間で送受信されるプロトコルの具体例を示す図
【図19】実際に端末間で送受信されるプロトコルの具体例を示す図
【図20】実際に端末間で送受信されるプロトコルの具体例を示す図
【図21】実際に端末間で送受信されるプロトコルの具体例を示す図
【図22】実際に端末間で送受信されるプロトコルの具体例を示す図
【図23】実際に端末間で送受信されるプロトコルの具体例を示す図
【図24】実際に端末間で送受信されるプロトコルの具体例を示す図
【図25】(a)〜(b):本発明のCGDのデモシステム構成図
【図26】本発明のCGDのデモシステム構成図
【図27】エンコーダでの過負荷時の優先度の付加方法を示す図
【図28】過負荷時の受信端末での優先度の決定方法について記した図
【図29】優先度の時間変化を示す図
【図30】ストリーム優先度とオブジェクト優先度を示す図
【図31】本発明の実施例における画像符号化、画像復号化装置の概略構成図
【図32】本発明の実施例における音声符号化、音声復号化装置の概略構成図
【図33】(a)〜(b):過負荷時の処理の優先度を管理する優先度付加部、優先度決定部を示す図
【図34】優先度を付加する粒度を示す図
【図35】優先度を付加する粒度を示す図
【図36】優先度を付加する粒度を示す図
【図37】多重解像度の画像データへ優先度の割り当て方法を示す図
【図38】通信ペイロードの構成方法を示す図
【図39】データを通信ペイロードへ対応づける方法を示す図
【図40】オブジェクト優先度、ストリーム優先度と通信パケット優先度との対応を示す図
【図41】本発明の第1の実施の形態における送信装置の構成図
【図42】第1の実施の形態の説明図
【図43】本発明の第3の実施の形態における受信装置の構成図
【図44】本発明の第5の実施の形態における受信装置の構成図
【図45】第5の実施の形態の説明図
【図46】本発明の第6の実施の形態における送信装置の構成図
【図47】本発明の第8の実施の形態における送信装置の構成図
【図48】本発明の第2の実施の形態における送信方法のフローチャート
【図49】本発明の第4の実施の形態における受信方法のフローチャート
【図50】本発明の第7の実施の形態における送信方法のフローチャート
【図51】本発明の第9の実施の形態における送信方法のフローチャート
【図52】本発明の画像・音声送信装置の一例を示す構成図
【図53】本発明の画像・音声受信装置の一例を示す構成図
【図54】本発明の画像・音声送信装置の映像と音声に優先度を付加する優先度付加手段について説明する図
【図55】本発明の画像・音声受信装置の映像と音声に付加された優先度を解釈し、復号処理の可否を決定する優先度決定手段について説明する図
【符号の説明】
11 受信管理部
12 分離部
13 伝送部
14 画像伸長部
15 画像伸長管理部
16 画像合成部
17 出力部
18 端末制御部
301 受信手段
302 推定手段
303 動画像の復号化装置
304 回数削減手段
306 出力端子
307 入力端子
3031 可変長復号化手段
3032 逆直交変換手段
3033 切替器
3034 動き補償手段
3035 実行時間計測手段
4011 送信管理部
4012 画像符号部
4013 受信管理部
4014 画像復号部
4015 画像合成部
4016 出力部
4101 画像符号化装置
4102 画像復号化装置
Claims (2)
- (1)符号化された音声または動画像の時系列データと、前記時系列データのフレーム毎の復号時刻が記載された復号時刻情報と、(2)前記時系列データ間の処理の優先度を示す時系列データ間優先度と、(3)前記動画像の時系列データを構成するフレームが少なくともIフレームかPフレームかを示すフレームタイプと、前記フレームタイプとは異なる前記フレームの復号処理の優先度を示す時系列データ内優先度とを含むデータ系列を受け付ける受付手段と、
前記時系列データをフレーム毎に復号化するデータ処理手段と、
前記データ処理手段による復号処理開始からの経過時間と、前記復号時刻情報が示す復号時刻との比較を行うことで、前記復号時刻より前記処理開始からの経過時間の方が大きいときは、現在の前記時系列データ内優先度の閾値よりも前記時系列データ内優先度の閾値を低く設定し、前記復号時刻より前記処理開始からの経過時間の方が小さいときは、現在の前記時系列データ内優先度の閾値よりも前記時系列データ内優先度の閾値を高く設定する優先度決定手段と、を具備し、
前記データ処理手段は、前記時系列データ間優先度を前記データ処理手段に対して設定されている処理の優先度に対応付けることで、前記各時系列データに対する前記処理手段の処理能力を配分し、
前記優先度決定手段が復号処理開始からの経過時間と前記復号時刻情報が示す復号時刻との比較を行った結果、前記復号時刻より前記処理開始からの経過時間の方が大きく、現在の前記時系列データ内優先度の閾値よりも前記時系列データ内優先度の閾値を低く設定したときは、前記低く設定した前記時系列データ内優先度の閾値を満たす時系列データ内優先度を有するフレームの復号化を行い、
前記復号時刻より前記処理開始からの経過時間の方が小さく、現在の前記時系列データ内優先度の閾値よりも前記時系列データ内優先度の閾値を高く設定したときは、前記高く設定した前記時系列データ内優先度の閾値を満たす時系列データ内優先度を有するフレームの復号化を行うことで、前記配分された処理能力内で前記時系列データをフレーム毎に復号化する、データ処理装置。 - (1)符号化された音声または動画像の時系列データと、前記時系列データのフレーム毎の復号時刻が記載された復号時刻情報と、(2)前記時系列データ間の処理の優先度を示す時系列データ間優先度と、(3)前記動画像の時系列データを構成するフレームが少なくともIフレームかPフレームかを示すフレームタイプと、前記フレームタイプとは異なる前記フレームの復号処理の優先度を示す時系列データ内優先度とを含むデータ系列を入力とし、
前記時系列データをフレーム毎に復号化する処理を行い、
前記復号処理開始からの経過時間と、前記復号時刻情報が示す復号時刻との比較を行うことで、前記復号時刻より前記処理開始からの経過時間の方が大きいときは、現在の前記時系列データ内優先度の閾値よりも前記時系列データ内優先度の閾値を低く設定し、前記復号時刻より前記処理開始からの経過時間の方が小さいときは、現在の前記時系列データ内優先度の閾値よりも前記時系列データ内優先度の閾値を高く設定し、
前記時系列データ間優先度を、前記時系列データの処理を行うデータ処理手段に対して設定されている処理の優先度に対応付けることで、前記各時系列データに対する前記データ処理手段の処理能力を配分し、
復号処理開始からの経過時間と前記復号時刻情報が示す復号時刻との比較を行った結果、前記復号時刻より前記処理開始からの経過時間の方が大きく、現在の前記時系列データ内優先度の閾値よりも前記時系列データ内優先度の閾値を低く設定したときは、前記低く設定した前記時系列データ内優先度の閾値を満たす時系列データ内優先度を有するフレームの復号化を行い、
前記復号時刻より前記処理開始からの経過時間の方が小さく、現在の前記時系列データ内優先度の閾値よりも前記時系列データ内優先度の閾値を高く設定したときは、前記高く設定した前記時系列データ内優先度の閾値を満たす時系列データ内優先度を有するフレー ムの復号化を行うことで、前記配分された処理能力内で前記時系列データをフレーム毎に復号化する、データ処理方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003062713A JP4102223B2 (ja) | 1997-03-17 | 2003-03-10 | データ処理装置及びデータ処理方法 |
Applications Claiming Priority (7)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP6266797 | 1997-03-17 | ||
JP9064097 | 1997-04-09 | ||
JP17934297 | 1997-07-04 | ||
JP22602797 | 1997-08-22 | ||
JP22604597 | 1997-08-22 | ||
JP33210197 | 1997-12-02 | ||
JP2003062713A JP4102223B2 (ja) | 1997-03-17 | 2003-03-10 | データ処理装置及びデータ処理方法 |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP06558198A Division JP3516585B2 (ja) | 1997-03-17 | 1998-03-16 | データ処理装置及びデータ処理方法 |
Related Child Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2006115989A Division JP2006304309A (ja) | 1997-03-17 | 2006-04-19 | 送信装置、受信装置および通信システム |
JP2007106948A Division JP2007221826A (ja) | 1997-03-17 | 2007-04-16 | 受信端末および受信方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2004007461A JP2004007461A (ja) | 2004-01-08 |
JP4102223B2 true JP4102223B2 (ja) | 2008-06-18 |
Family
ID=30449740
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2003062713A Expired - Lifetime JP4102223B2 (ja) | 1997-03-17 | 2003-03-10 | データ処理装置及びデータ処理方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP4102223B2 (ja) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2006027846A1 (ja) * | 2004-09-10 | 2006-03-16 | Matsushita Electric Industrial Co., Ltd. | ザッピングストリームの生成装置とその方法 |
JP2007158410A (ja) | 2005-11-30 | 2007-06-21 | Sony Computer Entertainment Inc | 画像符号化装置、画像復号装置、および画像処理システム |
JP5051228B2 (ja) | 2007-07-30 | 2012-10-17 | 富士通株式会社 | 電子機器、情報処理システム、電子機器の障害通知方法、および障害通知プログラム |
KR101447666B1 (ko) | 2012-12-27 | 2014-10-07 | 국방과학연구소 | 음성 트래픽의 중요도를 고려한 적응적 버퍼 관리 방법 및 이의 저장 매체 |
-
2003
- 2003-03-10 JP JP2003062713A patent/JP4102223B2/ja not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
JP2004007461A (ja) | 2004-01-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
KR100557103B1 (ko) | 데이터 처리방법 및 데이터 처리장치 | |
JP3516585B2 (ja) | データ処理装置及びデータ処理方法 | |
KR100711635B1 (ko) | 화상 부호화 방법 | |
Lee et al. | The VC-1 and H. 264 video compression standards for broadband video services | |
US7006575B2 (en) | Picture and sound decoding apparatus picture and sound encoding apparatus and information transmission system | |
US9819955B2 (en) | Carriage systems encoding or decoding JPEG 2000 video | |
US20060161676A1 (en) | Apparatus for IP streaming capable of smoothing multimedia stream | |
JP4102223B2 (ja) | データ処理装置及びデータ処理方法 | |
KR100530919B1 (ko) | 동화상 데이터의 처리 및 송수신 방법 및 장치 | |
JP2007221826A (ja) | 受信端末および受信方法 | |
JP3448047B2 (ja) | 送信装置及び受信装置 | |
JP3519722B2 (ja) | データ処理方法及びデータ処理装置 | |
JP2006304309A (ja) | 送信装置、受信装置および通信システム | |
KR100530920B1 (ko) | 화상 · 음성 송신장치 및 수신장치 | |
CN100473158C (zh) | 发送和接收动态图像数据的方法 | |
JP2004048657A (ja) | 画像・音声受信装置 | |
JP7003308B2 (ja) | 復号装置 | |
Murugan | Multiplexing H. 264/AVC Video with MPEG-AAC Audio | |
Angelides et al. | Capabilities and Limitations of PC’s in the Networked Multimedia Environment |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050118 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070925 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20071120 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20071218 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080130 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080226 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080321 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110328 Year of fee payment: 3 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110328 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120328 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130328 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130328 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140328 Year of fee payment: 6 |
|
EXPY | Cancellation because of completion of term |