JPH11225168A

JPH11225168A - 画像・音声送信装置、画像・音声受信装置、データ処理装置、及びデータ処理方法、並びに、波形データの送信方法、装置、及び波形データの受信方法、装置、並びに、動画像の送信方法、装置、及び動画像の受信方法、装置

Info

Publication number: JPH11225168A
Application number: JP6558198A
Authority: JP
Inventors: Takao Yamaguchi; 孝雄山口; Minoru Eito; 稔栄藤; Hiroshi Arakawa; 博荒川
Original assignee: Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Holdings Corp
Priority date: 1997-03-17
Filing date: 1998-03-16
Publication date: 1999-08-17
Anticipated expiration: 2018-03-16
Also published as: JP3516585B2

Abstract

(57)【要約】【課題】伝送フォーマット情報の動的な変更は行えなか
った。【解決手段】記憶装置や通信路から、データとその伝送
フォーマット情報とを含む情報を受信する受信管理部１
１と、受信情報を解析し、分離する分離部１２と、記憶
装置や通信路へ情報を送信する伝送部１３と、画像を伸
長する画像伸長部１４と、画像伸長管理部１５は、少な
くとも１つ以上の画像の伸長を行う前記画像伸長部１４
の処理状態を管理し、伸長された情報をもとに画像合成
を行う画像合成部１６と、合成結果を出力する出力部１
７と、これら各手段を制御、管理する端末制御部１８か
ら構成される画像合成装置により、同時に複数の画像の
合成が行われ、又、伝送フォーマット情報の動的な変化
に対応することが出来る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、画像・音声送信装
置、画像・音声受信装置、データ処理装置、及びデータ
処理方法、並びに、波形データの送信方法、装置、及び
波形データの受信方法、装置、並びに、動画像の送信方
法、装置、及び動画像の受信方法、装置に関する。

【０００２】

【従来の技術】従来より、自分が居る空間の風景の画像
中から、例えば人物画像を抽出し、その画像と相手側か
ら送られてきた人物画像と予め記憶されている相手側と
共通的に表示する仮想的な空間の画像と重畳して表示す
ることにより、相手が自分の前にいるという実在感を充
足し、臨場感のある映像通信を目指したものがある（特
公平４−２４９１４号公報）。

【０００３】特に、従来の技術では画像合成を行うため
の高速化、メモリーを低減する方法に関する発明が行わ
れている（例えば、特公平５−４６５９２号公報：画像
合成装置）。

【０００４】

【発明が解決しようとする課題】この様な従来の技術で
は、２次元の静止画や３次元のＣＧデータを合成する画
像合成を利用した通信システムが提案されていたが、複
数の動画や音声を同時に合成して表示させるシステムの
実現方法について、下記の観点からの具体的な議論が行
われていなかった。

【０００５】即ち、（Ａ１）一つあるいは二つ以上の現
実の伝送路上においてソフト的に構築される複数の論理
的な伝送路を用いて、データと制御情報（データとは別
のパケットで伝送される、端末側の処理を制御するため
の情報）とが独立して伝送される環境下での画像や音声
の伝送（通信と放送）及び、その制御方法、（Ａ２）送
信すべき画像や音声のデータに付加するヘッダ情報（本
発明のデータ管理情報に対応）の動的な変更方法、（Ａ
３）送信のために付加するヘッダ情報（本発明の伝送管
理情報に対応）の動的な変更方法、（Ａ４）複数の論理
的な伝送路を動的に多重化、分離して情報の伝送を行う
方法、（Ａ５）プログラムやデータの読み込み、立ち上
げ時間を考慮した画像や音声の伝送方法、及び（Ａ６）
ザッピングを考慮した画像や音声の伝送方法等の観点か
らの具体的な議論が行われていなかったという課題があ
った。

【０００６】一方、従来より、ネットワークへの伝送量
を動的に調整する方法としては、エンコードの方式を変
更する方式や、映像のフレームタイプに応じて、フレー
ム単位でデータを廃棄する方式が提案されている（秦泉
寺（じんぜんじ）浩史、田尻哲男、分散適応型ＶＯＤシ
ステムの一検討、Ｄ−８１、電子情報通信学会システム
ソサイエティ（１９９５））。

【０００７】エンコーダ側で処理量を調整する方式とし
ては、処理時間拘束のもとで画質の高い映像を提供でき
る動的演算量スケーラブルアルゴリズムが提案されてい
る（大迫史典，矢島由幸，小寺博，渡辺裕，島村
和典：動的演算量スケーラブルアルゴリズムによるソフ
トウェア画像符号化，電子情報通信学会論文誌Ｄ−２,
Vol.80-D-2, No.2, pp.444-458(1997).）。

【０００８】また、動画と音声の同期再生を実現した例
としては、ＭＰＥＧ１／ＭＰＥＧ２のシステムがある。

【０００９】この様な従来の技術における、（Ｂ１）従
来方式の映像のフレームタイプに応じて映像を廃棄する
方式では、扱える情報の粒度が、単一のストリーム内で
あるため、複数のビデオストリームや複数のオーディオ
ストリームの取り扱いや、編集者の意図を反映させて、
重要なシーンカットを重点的にオーディオとともに同期
再生をさせることは困難であるという課題があった。
（Ｂ２）また、ＭＰＥＧ１／ＭＰＥＧ２では、ハードウ
ェアでの実現が前提であるため、デコーダは与えられた
ビットストリームをすべてデコードできることが前提と
なる。したがって、デコーダの処理能力を超えた場合の
対応方法が不定となる課題が有る。

【００１０】又一方、従来、動画像の伝送においては、
Ｈ．２６１（ＩＴＵ−ＴＲｅｃｏｍｍｅｎｄａｔｉｏ
ｎＨ．２６１−Ｖｉｄｅｏｃｏｄｅｃｆｏｒａ
ｕｄｉｏｖｉｓｕａｌｓｅｒｖｉｃｅｓａｔｐｘ
６４）などの方式を用いたものがあり、これまで、ハー
ドウェアにより実装されていた。このため、ハードウェ
ア設計時に、必要な性能の上限を考慮しているため指定
時間以内に復号化処理を完了できないという場合は、生
じなかった。

【００１１】なお、ここで、指定時間とは、一枚の画像
を符号化したビットストリームの伝送に要する時間であ
る。この時間内に復号化できないと、超過した時間が遅
延となり、これが蓄積して大きくなると、送信側から受
信側までの遅延が大きくなりテレビ電話としての使用に
適しなくなる。このような状況は避けねばならない。

【００１２】また、通信相手が規格外のビットストリー
ムを生成しているために復号化処理を指定時間内に完了
できない場合には、動画像の伝送ができないという課題
があった。

【００１３】上記の課題は、動画像だけではなく、音声
データにおいても発生する課題である。

【００１４】ところが近年、インタネットやＩＳＤＮの
普及という形でパーソナルコンピュータ（ＰＣ）でのネ
ットワーク環境が整備された結果、伝送速度が速くな
り、ＰＣとネットワークを利用した動画像の伝送が可能
になってきた。ユーザからの動画像伝送に対する要求
も、とみに高まってきている。また、ＣＰＵ性能の向上
により、ソフトウェアによる動画像の復号化が充分可能
となってきている。

【００１５】しかしながら、パーソナルコンピュータに
おいては同じソフトウェアを、ＣＰＵ、バス幅、アクセ
ラレータの有無など、装置構成の異なるコンピュータで
実行可能であるため、必要な性能の上限を予め考慮する
ことが困難であり、指定時間内に画像を復号化できない
場合が生じる。

【００１６】また、受信装置の処理能力を越える長さの
動画像の符号化データが伝送された場合には指定時間内
の符号化が不可能となる。

【００１７】課題（Ｃ１）：指定時間内に画像を復号化
し、遅延を小さく抑える。

【００１８】また、この課題１の解決手段として、例え
ば、本発明の請求項Ｃ１記載の波形データとして動画像
を入力する場合、又は本発明の請求項Ｃ７記載の波形デ
ータとして動画像を出力する場合であれば、伝送された
ビットストリームのうち一部を使用しないため、伝送路
の実質使用効率が悪い、という問題が残る場合もある。
また、符号化方式によっては、前回の復号画像をもとに
今回の復号画像を生成するものがあるが（Ｐピクチャな
ど）、上記のような課題１の解決手段では、前回の復号
画像を完全に復元しない場合があるため、画質劣化が、
時間とともに波及的に大きくなるという問題もある。

【００１９】課題（Ｃ２）：課題1解決手段では、伝送
路の実質使用効率が悪い。また、画質劣化が波及する。

【００２０】また、ソフトウェアによる実装では、一回
の符号化処理に要する時間で画像のフレームレートが決
まるため、ユーザの指定したフレームレートが計算機の
処理限界を越えた場合には、指定に応えることができな
かった。

【００２１】課題（Ｃ３）：ユーザの指示したフレーム
レートが、計算機の処理限界を越えると指定に応えられ
ない。

【００２２】本発明は、上記第１の従来技術の（Ａ１）
〜（Ａ６）の課題を考慮し、それらの課題の少なくとも
何れか一つを解決する画像・音声送信装置、画像・音声
受信装置、データ処理装置、及びデータ処理方法を提供
することを目的とする。

【００２３】又、本発明は、上記第２の従来技術の（Ｂ
１）〜（Ｂ２）の課題を考慮し、それらの課題の少なく
とも何れか一つを解決するデータ処理装置、及びデータ
処理方法を提供することを目的とする。

【００２４】又、本発明は、上記最後の従来技術の（Ｃ
１）〜（Ｃ３）の課題を考慮し、それらの課題の少なく
とも何れか一つを解決する波形データの送信方法、装
置、及び波形データの受信方法、装置、並びに、動画像
の送信方法、装置、及び動画像の受信方法、装置を提供
することを目的とする。

【００２５】

【課題を解決するための手段】請求項１記載の本発明
は、伝送方法に関する及び／又は伝送するデータの構造
に関する内容、又はその内容を示す識別子を、伝送フォ
ーマット情報として、前記伝送するデータの伝送路と同
一の伝送路、又は、前記伝送路とは別の伝送路を用いて
伝送する伝送手段を備え、前記伝送されるデータは、画
像データ及び／又は音声データである画像・音声送信装
置である。

【００２６】請求項２記載の本発明は、前記伝送フォー
マット情報が、前記データを管理するために前記データ
に付加されるデータ管理情報と、前記データを伝送する
ためにデータに付加される伝送管理情報と、端末側の処
理を制御するための情報の内、少なくとも一つの情報に
含まれている請求項１記載の画像・音声送信装置であ
る。

【００２７】請求項３記載の本発明は、前記データ管理
情報、前記伝送管理情報、及び前記端末側の処理を制御
するための情報の内、少なくとも一つが動的に変更され
る請求項２記載の画像・音声送信装置である。

【００２８】請求項４記載の本発明は、前記データは、
複数のパケットに分割されており、前記データ管理情
報、又は前記伝送管理情報は、それら分割された複数の
パケットの先頭のパケットの他に、途中のパケットにも
付加されている請求項３記載の画像・音声送信装置であ
る。

【００２９】請求項５記載の本発明は、前記データに関
する時間情報を、そのデータの再生時刻を示す情報とし
て利用するか否かを示す識別子が、前記伝送フォーマッ
ト情報に含まれている請求項１記載の画像・音声送信装
置である。

【００３０】請求項６記載の本発明は、前記伝送フォー
マット情報は、前記データの構造情報であり、伝送され
てきた前記データの構造情報を受信した受信装置により
出力される受信可能である旨の信号が確認された後、前
記伝送手段が、対応するデータを前記受信装置に伝送す
る請求項１記載の画像・音声送信装置である。

【００３１】請求項７記載の本発明は、前記伝送フォー
マット情報は、（１）受信装置において時間的に後の段
階で使用されることになるプログラム又はデータを識別
する識別子と、（２）前記使用されることになる時点又
は使用の有効期間を知るための情報として、フラグ、カ
ウンタ、又はタイマーのうち少なくとも１つとを含むも
のである請求項１に記載の画像・音声送信装置である。

【００３２】請求項８記載の本発明は、前記使用される
ことになる時点は、伝送管理情報として伝送の順序関係
を識別するための送信シリアル番号を用いることにより
伝送されるか、又は、データとは別のパケットで伝送さ
れる、端末側の処理を制御するための情報として伝送さ
れるものである請求項７記載の画像・音声送信装置であ
る。

【００３３】請求項９記載の本発明は、前記伝送方法に
関する及び／又は伝送するデータの構造に関する内容
と、その識別子とを複数種類格納する格納手段を備え、
前記識別子が、前記データ管理情報、前記伝送管理情報
又は前記端末側の処理を制御するための情報の内、少な
くとも一つの情報の中に前記伝送フォーマット情報とし
て含まれている請求項２又は３記載の画像・音声送信装
置である。

【００３４】請求項１０記載の本発明は、前記伝送方法
に関する及び／又は伝送するデータの構造に関する内容
を複数種類格納する格納手段を備え、前記内容が、前記
データ管理情報、前記伝送管理情報又は前記端末側の処
理を制御するための情報の内、少なくとも一つの情報の
中に前記伝送フォーマット情報として含まれている請求
項２又は３記載の画像・音声送信装置である。

【００３５】請求項１１記載の本発明は、前記伝送方法
に関する及び／又は伝送するデータの構造に関する内容
の変更を行うか否かを示すデフォルト識別子が付加され
ている請求項１、２又は３に記載の画像・音声送信装置
である。

【００３６】請求項１２記載の本発明は、伝送される情
報の予め決められた固定長の領域、若しくは前記予め決
められた位置に前記識別子、又は、前記デフォルト識別
子が付加される請求項９、１０または１１記載の画像・
音声送信装置である。

【００３７】請求項１３記載の本発明は、請求項１〜１
２の何れか一つに記載の画像・音声送信装置から送信さ
れてくる前記伝送フォーマット情報を受信する受信手段
と、前記受信した伝送フォーマット情報を解釈する伝送
情報解釈手段とを備えた画像・音声受信装置である。

【００３８】請求項１４記載の本発明は、前記伝送方法
に関する及び／又は伝送するデータの構造に関する内容
と、その識別子とを複数種類格納する格納手段を備え、
前記伝送フォーマット情報を解釈する際に、前記格納手
段に格納されている内容を利用する請求項１３記載の画
像・音声受信装置である。

【００３９】請求項１５記載の本発明は、データ及び／
又は制御情報を伝送するための複数の論理的な伝送路の
情報の多重化の開始・終了を制御する情報多重化手段を
備え、前記情報多重化手段により多重化された前記デー
タ及び／又は制御情報の他に、前記情報多重化手段によ
る上記多重化の開始・終了に関する制御内容を多重化制
御情報として送信するものであり、前記データは、画像
データ及び／又は音声データである画像・音声送信装置
である。

【００４０】請求項１６記載の本発明は、前記多重化制
御情報を、前記データ及び／又は制御情報より前に多重
化せずに配置し伝送するか、又は、前記多重化制御情報
を、前記データ及び／制御情報が伝送される伝送路とは
別の伝送路により伝送するかを、選択することが出来る
請求項１５記載の画像・音声送信装置である。

【００４１】請求項１７記載の本発明は、請求項１５に
記載の画像・音声送信装置から送信されてくる前記多重
化制御情報と、前記多重化された前記データ及び／又は
制御情報とを受信する受信手段と、前記多重化制御情報
に基づいて、前記多重化された前記データ及び／又は制
御情報を分離する分離手段とを備えた画像・音声受信装
置である。

【００４２】請求項１８記載の本発明は、番組を視聴す
るための主視聴手段と、前記主視聴手段により視聴され
ている前記番組以外の番組の状況を周期的に検出する副
視聴手段とを備え、前記主視聴手段により視聴される前
記番組が他の番組に切り替えられた際に必要となるプロ
グラム及び／又はデータをスムーズに処理できる様に前
記検出を行うものであり、前記データは、画像データ及
び／又は音声データである画像・音声受信装置である。

【００４３】請求項１９記載の本発明は、前記データの
処理の優先度を示す情報のオフセット値を伝送すること
で、優先度の値を状況に応じて変化させることができる
請求項１記載の画像・音声送信装置である。

【００４４】請求項２０記載の本発明は、過負荷状態の
場合の処理の優先度に関する情報が予め付加されてい
る、符号化された情報を受信する受信手段と、前記受信
手段により受信される前記情報の内で処理すべきものか
否かを選定する基準となる閾値を決定する優先度決定手
段とを備え、前記受信した情報を出力すべき時期と処理
開始からの経過時間とを、又は、前記受信した情報を復
号すべき時期と処理開始からの経過時間とを比較し、そ
の比較結果に基づいて、前記閾値を変化させるものであ
り、前記符号化の対象として、画像データ及び／又は音
声データを含む画像・音声受信装置である。

【００４５】請求項２１記載の本発明は、伝送途中で紛
失されたために、前記受信されなかった前記情報の再送
が必要な場合、前記紛失されたものの中で再送要求すべ
きものか否かを選定する基準となる閾値を決定する再送
要求優先度決定手段を備え、前記決定される閾値が、前
記優先度決定手段が管理する優先度、再送回数、情報の
損失率、フレーム内符号化されたフレームの挿入間隔、
及び優先度の粒度の内、少なくとも一つに基づいて決定
されるものである請求項２０記載の画像・音声受信装置
である。

【００４６】請求項２２記載の本発明は、伝送途中で紛
失されたために、前記受信されなかった前記情報の再送
要求があった場合、前記紛失されたものの中で再送すべ
きものか否かを選定する基準となる閾値を決定する再送
優先度決定手段を備え、前記決定される閾値が、請求項
２０記載の画像・音声受信装置の前記優先度決定手段が
管理する優先度、再送回数、情報の損失率、フレーム内
符号化されたフレームの挿入間隔、及び優先度の粒度の
内、少なくとも一つに基づいて決定されるものである画
像・音声送信装置である。

【００４７】請求項２３記載の本発明は、（１）画像ま
たは音声の情報の目標転送レートを実際の転送レートの
方が超える場合又は、（２）転送処理開始からの経過時
間と、符号化された前記情報に付加されている、復号化
されるべき若しくは出力されるべき時期とを比較した結
果、送信バッファへの符号化された情報の書き込みが遅
れていると判定した場合、前記符号化された情報に付加
されている優先度を用いて、前記情報の送信を間引いて
行う画像・音声送信装置である。

【００４８】請求項２５記載の本発明は、（１）音声ま
たは動画像の時系列データと、（２）前記時系列データ
間の処理の優先度を示す時系列データ間優先度と、
（３）前記時系列データを区分し、区分されたデータ間
の処理優先度を示す複数の時系列データ内優先度とを含
むデータ系列を受け付ける受付手段と、前記時系列デー
タが複数同時に存在する場合は、前記時系列データ間優
先度と前記時系列データ内優先度とを併用して処理を行
うデータ処理手段とを備えたデータ処理装置である。

【００４９】請求項２７記載の本発明は、（１）音声ま
たは動画像などの時系列データと、（２）前記時系列デ
ータ間の処理の優先度を示す時系列データ間優先度と、
（３）前記時系列データを区分し、区分されたデータ間
の処理優先度を示す複数の時系列データ内優先度とを含
むデータ系列を受け付ける受付手段と、前記時系列デー
タ間優先度により、前記各時系列データに対する処理能
力を配分し、さらに前記各時系列データについて、配分
された処理能力内に収まるように、前記時系列データ内
優先度に基づいて、適応的に前記時系列データ内の区分
されたデータの処理品質を劣化させるデータ処理手段と
を備えたデータ処理装置である。

【００５０】請求項２９記載の本発明は、動画像に対す
る時系列データ内優先度が、動画像のフレーム単位で付
加されており、前記フレーム単位の動画像が複数個のパ
ケットに分割される場合、単独の情報としてアクセス可
能な前記動画像のフレームの先頭部分を伝送するパケッ
トのヘッダ部のみに前記時系列データ内優先度を付加す
るデータ処理装置である。

【００５１】請求項３１記載の本発明は、前記時系列デ
ータ内優先度はパケットのヘッダ内に記述し、優先度処
理を行う請求項２５、２７、又は２９のいずれかに記載
のデータ処理装置である。

【００５２】請求項３３記載の本発明は、前記時系列デ
ータ内優先度が表現できる値の範囲を可変にし、優先度
処理を行うことを特徴とする請求項２５、２７、又は２
９のいずれかに記載のデータ処理装置。

【００５３】請求項３４記載の本発明は、音声または動
画像などの時系列データと、前記時系列データ間の処理
の優先度を示す時系列データ間優先度とを含むデータ系
列を入力とし、前記時系列データ間優先度を相対的な優
先度の値又は、絶対的な優先度の値として優先処理を行
うデータ処理方法である。

【００５４】請求項３６記載の本発明は、音声または動
画像などの時系列データを区分し、前記時系列データ
と、前記区分されたデータ間の処理優先度を示す複数の
時系列データ内優先度とを含むデータ系列を入力とし、
前記時系列データ内優先度を相対的な優先度の値又は、
絶対的な優先度の値として優先処理を行うデータ処理方
法である。

【００５５】又、課題（Ｃ１）を解決するために本発明
は、請求項６３記載の波形データの送信方法において、
例えば、波形データとして動画像を入力することを特徴
し、また、請求項６９記載の波形データの受信方法にお
いて、例えば、波形データとして動画像を出力すること
を特徴とするものである。

【００５６】また、課題（Ｃ２）を解決するために本発
明は、請求項６９記載の波形データの受信方法におい
て、例えば、（ｄ）推定により求めた各グループの各
実行時間を出力することを特徴とし、また、請求項６３
記載の波形データの送信方法において、例えば、（ｄ）
各グループの各実行時間から構成されるデータ列を入
力し、（ｅ）レートコントローラなどの指示により決
まる符号長を伝送するのに必要な時間内に復号化を完了
するための各グループの各実行回数を、前記受信手段
の各実行時間により算出することを特徴とするものであ
る。

【００５７】また、課題（Ｃ３）を解決するために本発
明は、請求項６７の波形データの送信方法において、例
えば、（ｄ）動画像の符号化に要する処理時間と計数
手段の出力する各実行回数とを基に、各グループの各実
行時間を推定し、（ｅ）前記実行時間を用い動画像符
号化に要する処理時間を予測し、前記処理時間が、ユー
ザの指示として与えられるフレームレートにより決まる
一枚の画像を処理するのに利用可能な時間を越えない各
グループの各実行回数を算出することを特徴とするもの
である。

【００５８】本発明は上記の構成により、必須処理と非
必須処理のそれぞれの実行回数を求め、これを受信側に
伝送し、この実行回数と復号化時間により各処理に要す
る時間を推定する。

【００５９】この各処理の推定時間に基づき復号化に
要する時間が指定時間を下回るように非必須処理の各実
行回数を削減することで、復号化処理の時間を指定時間
以下に抑え、遅延を小さく保つことができる。

【００６０】尚、課題（Ｃ１）を解決する発明として、
主に請求項６７，請求項７３があげられる。

【００６１】また、受信側で推定した必須処理と非必
須処理の各実行時間を送信側に伝送し、送信側にて、各
実行時間をもとに各実行回数を決定することにより、復
号化処理の実行時間を指定時間以下となるようにでき
る。

【００６２】尚、課題（Ｃ２）を解決する発明として、
主に請求項７５，請求項７７があげられる。

【００６３】また、必須処理と非必須処理の各実行時間
を推定し、各実行時間及びユーザの指示したフレー
ムレートにより決まるユーザ指定時間をもとに各実行回
数を決定することにより、符号化処理の推定実行時間
を、ユーザ指定時間以下となるようにできる。尚、課題
（Ｃ３）を解決する発明として、主に請求項７９があげ
られる。

【００６４】

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

【００６５】尚、ここで述べる実施の形態は、主に、上
述した課題（Ａ１）〜（Ａ６）の何れかを解決するもの
である。

【００６６】本発明で使用する「画像」としては、静止
画と動画の両方を含む。また、対象とする画像は、コン
ピュータ・グラフィックス（ＣＧ）のような２次元画像
とワイヤーフレーム・モデルから構成されるような３次
元の画像データであってもよい。

【００６７】図１は、本発明の実施の形態における画像
音声送受信装置の概略構成図である。

【００６８】同図において、情報を受信する受信管理部
１１と情報を送信する伝送部１３は、同軸ケーブル、Ｃ
ＡＴＶ、ＬＡＮ、モデム等の情報を伝送する手段であ
る。通信環境としては、インターネットのように、多重
化手段を意識せずに複数の論理的な伝送路が利用できる
通信環境であってもよいし、アナログ電話や衛星放送の
ように多重化手段を意識しなければならない通信環境で
あってもよい。

【００６９】また、端末の接続形態としては、ＴＶ電話
やＴＶ会議システムのように端末間で双方向で映像や音
声を送受信する形態や、衛星放送やＣＡＴＶ、インター
ネット上での放送型の映像や音声放送の形態が挙げられ
る。本発明では、このような端末の接続形態について考
慮している。

【００７０】図１に示す分離部１２は受信情報を解析
し、データと制御情報を分離する手段である。具体的に
は、送信のためにデータに付加された送信用のヘッダ情
報とデータとを分解したり、データ自身に付加されたデ
ータ制御用のヘッダとデータの中身を分解するための手
段である。画像伸張部１４は受信した画像を伸張する手
段である。たとえば、Ｈ．２６１、Ｈ．２６３、ＭＰＥ
Ｇ１／２、ＪＰＥＧといった標準化された動画や静止画
の圧縮画像であってもよいし、そうでなくてもよい。

【００７１】図１に示す画像伸張管理部１５は画像の伸
張状態を監視する手段である。たとえば、画像の伸張状
態を監視することで、受信バッファがオーバーフローを
起こしそうになった場合に、画像の伸張を行わずに、受
信バッファを空読みし、画像の伸張ができる状態になっ
た時点から、画像の伸張を再開させることができる。

【００７２】又、同図において、画像合成部１６は、伸
張された画像を合成する手段である。合成方法に関して
は、ＪＡＶＡ、ＶＲＭＬ、ＭＨＥＧといったスクリプト
言語で、画像と画像の構造情報（表示位置と表示時間
（表示期間を含めてもよい））、画像同士のグルーピン
グの方法、画像の表示のレイヤ（深さ）、そして、オブ
ジェクトＩＤ（後述するＳＳＲＣ）と、これらの属性の
関係を記述することによって画像の合成方法が定義でき
る。合成方法を記述したスクリプトはネットワークやロ
ーカルの記憶装置から入出する。

【００７３】又、出力部１７は、画像の合成結果を出力
するディスプレイやプリンターなどである。端末制御部
１８はこれら各部を制御する手段である。なお、画像の
代わりに音声を伸張する構成であっても（画像伸張部を
音声伸張部に、画像伸張管理部を音声伸張管理部に、画
像合成部を音声合成部に変更することで対応できる）、
画像と音声の両方を伸張し、時間的に同期を保ちながら
合成、表示する構成であってもよい。

【００７４】さらに、画像を圧縮する画像圧縮部、画像
圧縮部を管理する画像圧縮管理部、音声を圧縮する音声
圧縮部、音声圧縮部を管理する音声圧縮管理部を備える
ことにより、画像や音声の伝送も可能になる。

【００７５】図２は受信管理部と分離部とを示す図であ
る。

【００７６】図１に示した受信管理部１１にデータを受
信するデータ受信部１０１とデータを制御するための制
御情報を受信する制御情報受信部１０２と、分離部１２
に伝送内容を解釈するための伝送構造（詳細は後述す
る）について記憶する伝送フォーマット記憶部１０３
と、伝送フォーマット記憶部１０３に記憶された伝送構
造に基づき伝送内容を解釈する伝送情報解釈部１０４で
各部を構成することで、データと制御情報を独立して受
信することが可能になるので、例えば、受信しながらの
受信画像や音声の削除や移動が容易になる。

【００７７】前述したが、受信管理部１１が対象とする
通信環境としては、インターネットのように、多重化手
段を意識せずに複数の論理的な伝送路が利用できる通信
環境（インターネット・プロファイル）であってもよい
し、アナログ電話や衛星放送のように多重化手段を意識
しなければならない通信環境（Ｒａｗプロファイル）で
あってもよい。しかし、利用者から見れば、論理的な伝
送路（ロジカルチャンネル）が複数個用意されている通
信環境を前提としている（たとえば、ＴＣＰ／ＩＰが使
える通信環境では「通信ポート」と呼ばれる表現が一般
に使われる）。

【００７８】また、図２に示すように、受信管理部１１
が受信する情報としては１種類以上のデータ用の伝送路
と、伝送するデータを制御するための制御用の論理的な
伝送路を１種類以上を想定している。データ伝送用の伝
送路を複数用意し、データ制御用の伝送路を１本だけ用
意してもよい。また、Ｈ．３２３でも利用されているＲ
ＴＰ／ＲＴＣＰのように、データ伝送毎にデータ制御用
の伝送路を用意してもよい。さらに、ＵＤＰを使った放
送を考慮した場合、単一の通信ポート（マルチキャスト
アドレス）を使った通信形態であってもよい。

【００７９】図３は、複数の論理的な伝送路を用いて画
像や音声の伝送、制御する方法について説明する図であ
る。伝送するデータ自身をＥＳ（エレメンタリー・スト
リーム）と呼び、ＥＳとしては、画像であれば１フレー
ム分の画像情報や１フレームよりも小さいＧＯＢ単位や
マクロブロック単位の画像情報であってもよい。

【００８０】音声であれば、利用者が決めた固定長の長
さであってよい。また、伝送するデータに付加するデー
タ制御用のヘッダ情報をＡＬ（アダプテーション・レイ
ヤ情報）と呼ぶ。ＡＬ情報としては、データの処理可能
な開始位置であるかどうかを示す情報、データの再生時
刻を示す情報、データの処理の優先度を示す情報などが
あげられる。本発明のデータ管理情報は、ＡＬ情報に対
応する。なお、本発明で用いられるＥＳとＡＬはＭＰＥ
Ｇ１／２で定義されている内容と必ずしも合致しなくて
もよい。

【００８１】データの処理可能な開始位置であるかどう
かを示す情報は、具体的には２種類の情報があげられ
る。１つはランダムアクセスのためのフラグであり、例
えば、画像ならイントラフレーム（Ｉピクチャ）といっ
たように前後のデータに関係なく単独に読みとって再生
できることを示すための情報である。２つ目としては、
単に単独で読みとりが可能であることを示すためのフラ
グとして、アクセスフラグが定義できる。たとえば、画
像ならばＧＯＢ単位やマクロブロック単位の画像の先頭
であることを示す情報である。従って、アクセスフラグ
がなければデータの途中である。必ずしもデータの処理
可能な開始位置であるかどうかを示す情報としてランダ
ムアクセスのフラグと、アクセスフラグの両方が必要で
はない。

【００８２】ＴＶ会議システムのようなリアルタイム通
信では両方のフラグを付加しなくても問題が起こらない
場合もあるし、編集を簡単に行えるようにするためには
ランダムアクセスフラグは必要である。フラグが必要で
あるか、必要な場合でもどのフラグが必要かを通信路を
介してデータ転送前に決定しておいてもよい。

【００８３】データの再生時刻を示す情報は、画像と音
声の再生される時の時間同期の情報を示し、ＭＥＰＧ１
／２ではＰＴＳ（プレゼンテーション・タイムスタン
プ）と呼ばれる。ＴＶ会議システムのようなリアルタイ
ム通信では通常、時間同期に関しては考慮されていない
ため、必ずしも再生時刻を意味する情報は必要ない。必
要な情報としては、エンコードされたフレームの時間間
隔になるかもしれない。

【００８４】時間間隔を受信側で調整させることによっ
て、フレーム間隔の大きな変動は防げるが、再生間隔を
調整させることで遅延になる可能性もある。従って、エ
ンコードのフレーム間隔を示す時間情報も必要ないと判
断できる場合もある。

【００８５】データの再生時刻を示す情報は、ＰＴＳを
意味するのか、フレーム間隔を意味するのか、データの
再生時刻をデータ自身には付加しないということを通信
路を介してデータ転送前に決定して受信端末に通知し
て、決定されたデータ管理情報とともにデータを伝送し
てもよい。

【００８６】データの処理の優先度を示す情報は、受信
端末の負荷やネットワークの負荷によって処理もしくは
伝送できない場合に、データの処理を中止させたり、伝
送を取りやめることによって受信端末の負荷やネットワ
ークの負荷を低減させることができる。

【００８７】受信端末では画像伸張管理部１５で、ネッ
トワークでは、中継の端末やルータなどで処理すること
ができる。優先度の表現方法としては数値による表現や
フラグであってもよい。なお、データの処理の優先度を
示す情報のオフセット値を制御情報、もしくはデータと
ともにデータ管理情報（ＡＬの情報）として伝送するこ
とで、受信端末の負荷やネットワークの負荷の急激な変
動に対して、あらかじめ画像や音声に割り当てている優
先度にオフセット値を加えることで、システムの動作状
況に応じた動的な優先度の設定が可能になる。

【００８８】さらに、スクランブルの有無、コピーライ
トの有無、オリジナルかコピーかを識別するための情報
をデータとは別に、データの識別子（ＳＳＲＣ）ととも
に制御情報として送信することで、中継ノードでのスク
ランブルの解除などが容易になる。

【００８９】なお、データの処理の優先度を示す情報
は、複数のビデオやオーディオのフレームの集合から構
成されるストリーム単位で付加してもよいし、ビデオや
オーディオのフレーム単位に付加してもよい。

【００９０】Ｈ．２６３やＧ．７２３などの符号化方法
で、符号化された情報の過負荷時の処理の優先度を予め
決められた基準で決定し、符号化された情報と決定され
た優先度を対応づける優先度付加手段を送信端末装置に
備える（図５４参照）。

【００９１】図５４は、映像と音声に優先度を付加する
優先度付加手段５２０１について説明する図である。

【００９２】即ち、同図に示す様に、符号化された映像
と音声の各データ（それぞれ映像符号化手段５２０２と
音声符号化手段５２０３が処理する）に対して、予め決
められた規則に基づき優先度を付加する。優先度を付加
する規則は、優先度付加規則５２０４に規則が格納され
ている。規則とは、Ｉフレーム（フレーム内符号化され
た映像フレーム）は、Ｐフレーム（フレーム間符号化さ
れた映像フレーム）よりも高い優先度付加するという規
則や、映像は音声よりも低い優先度を付加するという規
則である。また、この規則は利用者の指示により動的に
変更しても良い。

【００９３】優先度を付加する対象となるものは、たと
えば、画像であればシーンチェンジ、編集者や利用者が
指示した画像フレームやストリーム、音声であれば、有
音区間と無音区間である。

【００９４】過負荷時の処理の優先度を定義する画像や
音声フレーム単位の優先度の付加方法は、通信ヘッダへ
付加する方法と符号化時にビデオやオーディオの符号化
されたビットストリームのヘッダに埋め込む方法が考え
られる。前者は、復号せずに優先度に関する情報が得る
ことが可能であり、後者はシステムに依存せずにビット
ストリーム単体で独立に扱うことが可能である。

【００９５】通信ヘッダに優先度情報を付加する場合、
１つの画像フレーム（たとえば、フレーム内符号化され
たＩフレーム、フレーム間符号化されたＰ、Ｂフレー
ム）が複数個の送信パケットに分割される場合、画像で
あれば単独の情報としてアクセス可能な画像フレームの
先頭部分を伝送する通信ヘッダのみに優先度を付加する
（同一の画像フレーム内で優先度が等しい場合、次のア
クセス可能な画像フレームの先頭が現れるまで、優先度
は変わらないものとすればよい）。

【００９６】なお、用途に合わせて、優先度が表現でき
る値の範囲（たとえば、時間情報を１６ビットで表現す
るとか、３２ビットで表現するとか）を可変にして、制
御情報でコンフィグレーションできるようにしてもよ
い。

【００９７】また、復号化装置では、受信された種々の
符号化された情報の過負荷時の優先度に従って、処理の
方法を決定する優先度決定手段を受信端末装置に備える
（図５５参照）。

【００９８】図５５は、映像と音声に付加された優先度
を解釈し、復号処理の可否を決定する優先度決定手段５
３０１について説明する図である。

【００９９】即ち、同図に示す様に、優先度は映像、音
声毎のストリーム毎に付加される優先度、映像もしくは
音声のフレーム毎に付加される優先度である。これらの
優先度はそれぞれ独立に用いてもよいし、フレーム優先
度とストリーム優先度とを対応付けて用いてもよい。優
先度決定手段５３０１は、これら優先度に応じて復号す
べきストリームやフレームを決定する。

【０１００】端末での過負荷時の処理の優先度を決定す
る２種類の優先度を用いて、デコード処理を行なう。

【０１０１】すなわち、映像、音声といったビットスト
リーム間の相対的優先度を定義するストリーム優先度
（Stream Priority；時系列間優先度）と、同一ストリ
ーム内の映像フレームといった復号処理単位間の相対的
優先度を定義するフレーム優先度(Frame Priority；時
系列内優先度)を定義する（図３０）。

【０１０２】前者のストリーム優先度により複数のビデ
オやオーディオの取り扱いが可能になる。後者のフレー
ム優先度により映像のシーンチェンジや編集者の意図に
応じて、同一のフレーム内符号化された映像フレーム
（Iフレーム）でも異なる優先度の付加が可能になる。

【０１０３】なお、ストリーム優先度を、画像や音声の
符号化もしくは復号化処理のオペレーティング・システ
ム（ＯＳ）での割り当て時間もしく処理の優先度に対応
付けて管理することで、ＯＳレベルでの処理時間の管理
が可能となる。たとえば、マイクロソフト社のＷｉｎｄ
ｏｗｓ９５／ＮＴでは５段階のＯＳレベルでの優先度の
定義ができる。符号化、復号化の手段をソフトウェアで
スレッドの単位で実現した場合、処理対象となるストリ
ームのストリーム優先度から、各スレッドに割り当てる
ＯＳレベルでの優先度を決定することができる。

【０１０４】ここで述べた、フレーム優先度とストリー
ム優先度は、伝送媒体やデータ記録媒体へ適用が可能で
ある。例えば、伝送するパケットの優先度をアクセスユ
ニット優先度（ＡｃｃｅｓｓＵｎｉｔＰｒｉｏｒｉ
ｔｙ）と定義すると、ＡｃｃｅｓｓＵｎｉｔＰｒｉ
ｏｒｉｔｙ＝ＳｔｒｅａｍＰｒｉｏｒｉｔｙ−Ｆｒａ
ｍｅＰｒｉｏｒｉｔｙといった、フレーム優先度と、
ストリーム優先度の関係式から、パケットの伝送に関す
る優先度、若しくは、端末による過負荷時の処理の優先
度を決定することが出来る。

【０１０５】又、データ記録媒体としてフロッピーディ
スク、光ディスクなどを用いて行うことができる。ま
た、記録媒体はこれに限らず、ＩＣカード、ＲＯＭカセ
ット等、プログラムを記録できるものであれば同様に実
施することができる。さらに、データの中継を行うルー
タやゲートウェイといった画像や音声の中継装置を対象
としてもよい。

【０１０６】具体的な優先度に関する利用方法として
は、受信端末が過負荷である場合に、処理すべき符号化
された情報の優先度の閾値を決定する優先度決定手段を
画像伸長管理部や音声伸長管理部に具備し、表示される
べき時刻（ＰＴＳ）と現在までの処理開始からの経過時
刻もしくは、復号されるべき時刻（ＤＴＳ）と現在まで
の処理開始からの経過時刻を比較し、比較結果により処
理すべき符号化された情報の優先度の閾値を変化させる
（閾値を変化させるための情報としては、Ｉフレームの
挿入間隔、優先度の粒度を参考にしてもよい）。

【０１０７】図２５（ａ）に示す例では、エンコード時
には、取り込まれたＱＣＩＦ、ＣＩＦのサイズの画像を
エンコーダ（Ｈ．２６３）により、エンコードを行い、
エンコードされた情報とともに、復号する時刻（ＤＴ
Ｓ）、画像を表示する時刻を示すタイムスタンプ（ＰＴ
Ｓ）、過負荷時の処理の順序を示す優先度情報（ＣＧ
Ｄ、ＣｏｍｐｕｔａｔｉｏｎａｌＧｒａｃｅｆｕｌ
Ｄｅｇｒａｄａｔｉｏｎ）、フレームタイプ（ＳＮ）、
シーケンス番号を出力する。

【０１０８】また、図２５（ｂ）に示す例では、音声も
マイクを通して録音され、エンコーダ（Ｇ．７２１）に
より、エンコードを行い、エンコードされた情報ととも
に、復号する時刻（ＤＴＳ）、音声を再生する時刻を示
すタイムスタンプ（ＰＴＳ）、優先度情報（ＣＧＤ）、
シーケンス番号（ＳＮ）を出力する。

【０１０９】デコード時には、図２６に示す様に、画像
と音声は、それぞれ別々のバッファに渡され、画像と音
声はそれぞれのＤＴＳ（復号時刻）と現在の処理開始か
らの経過時刻とを比較して、ＤＴＳの方が遅れていなけ
れば、画像と音声はそれぞれのデコーダ（Ｈ．２６３、
Ｇ．７２１）に渡される。

【０１１０】図２７の例では、エンコーダでの過負荷時
の優先度の付加方法について記している。画像はＩフレ
ーム（フレーム内符号化された画像フレーム）は優先度
が「０」と「１」で高い優先度を割り当てている（数字
が小さいほど優先度が低い）。Ｐフレームは優先度が
「２」でＩフレームよりも低い優先度を割り当ててい
る。Ｉフレームは、２段階の優先度を割り当てているた
め、デコードする端末の負荷が高い場合、優先度が
「０」のＩフレームのみを再生するといったことができ
る。なお、優先度の付加方法に応じて、Ｉフレームの挿
入間隔を調整する必要がある。図２８の例は、過負荷時
の受信端末での優先度の決定方法について記した図であ
る。廃棄するフレームの優先度をcutOffPriorityよりも
大きいと設定する。つまり、すべての画像フレームを処
理の対象とする。画像フレームに付加される優先度の最
大値は端末接続時に送信側から受信側へ通知することに
より、あらかじめ知ることができる（ステップ１０
１）。

【０１１１】ＤＴＳと現在の処理開始からの経過時間を
比較して、経過時間の方が大きい場合（復号処理が間に
合っていない場合）、処理対象とすべき画像、音声の優
先度の閾値を引き下げ、処理を間引く（ステップ１０
２）、逆に処理開始からの経過時間の方が小さい場合
（復号処理が間に合っている場合）は、処理できる対象
の画像や音声を増やすために、優先度の閾値を引き上げ
る（ステップ１０３）。

【０１１２】１つ前の画像フレームがＰフレームでスキ
ップされているならば処理は行わない。そうでなけれ
ば、画像フレーム（もしくは音声のフレーム）の優先度
に優先度のオフセット値を付加し、優先度の閾値と比較
し、閾値をこえていなければ、デコーダに復号すべきデ
ータを渡す（ステップ１０４）。

【０１１３】なお、優先度のオフセットは、マシンの性
能をあらかじめ調べ、受信端末へオフセットを通知して
おくという使い方（利用者が受信端末で指示してもよ
い）、複数のビデオとサウンドストリームのストリーム
単位の優先度を変更するという使い方（例えば、一番後
ろの背景はオフセット値をあげて処理を間引くようにす
る）ができる。

【０１１４】マルチストリームを対象とする場合、スト
リーム毎の優先度を付加し、画像や音声のデコードのス
キップの判定してもよい。加えて、リアルタイム通信に
おいてもＨ．２６３のＴＲ（テンポラリーリファレン
ス）をＤＴＳと同様にして取り扱い利用することで、端
末でのデコード処理が進んでいるか、遅れているかを判
定でき、上記で述べた同様のスキップ処理を実現するこ
とができる。

【０１１５】図２９は先のアルゴリズムを実装して、優
先度の時間変化を調べたものである。

【０１１６】同図では、映像フレームに付加される優先
度の変化を示している。この優先度は端末が過負荷であ
る際の復号の可否を決定するための優先度であり、各フ
レーム毎に付加される。優先度は値が小さいほど優先度
が高い。同図の例では０が最も優先度が高い。優先度の
閾値が３であるとき、３よりも大きな値が付加されてい
る優先度のフレームは復号されずに廃棄され、３以下の
値が付加されている優先度が付加されているフレームは
復号される。優先度による選択的なフレームの廃棄を行
うことで、端末の負荷を押さえることが可能である。こ
の優先度の閾値は、現在の処理時刻と各フレームに付加
される復号処理時間（ＤＴＳ）との関係から動的に決定
してもよい。本手法は映像フレームだけでなく、音声に
対しても同様な要領で適用が可能である。

【０１１７】インターネットのような伝送路を考えた場
合、伝送途中で紛失した符号化された情報の再送が必要
な場合、再送すべき符号化された情報の優先度の閾値を
決定する再送要求優先度決定部を受信管理部に備え、優
先度決定部が管理する優先度や、再送回数、情報の損失
率、フレーム内符号化されたフレームの挿入間隔、優先
度の粒度（たとえば、５段階の優先度など）の情報をも
とに、再送要求すべき符号化された情報に付加された優
先度の閾値を決定することで、受信端末で必要とする画
像や音声のみを再送要求することができる。再送回数や
情報の損失率が大きければ、再送すべき対象とする情報
の優先度を引き上げて、再送や損失率を低下させる必要
がある。また、優先度決定部で使用されている優先度を
知ることで、処理対象外の情報の伝送をなくすことがで
きる。

【０１１８】送信側端末に関しては、送信端末の情報の
目標転送レートよりも実際の転送レートが超える場合
や、送信バッファへの符号化された情報の書き込みが、
現在までの転送処理開始からの経過時刻と符号化された
情報に付加されている復号もしくは表示される時刻とを
比較して、送信バッファへの情報の書き込みが遅れてい
る場合、符号化された情報に付加され、受信端末の優先
度決定部で利用される端末が過負荷時の優先度を用い
て、情報の送信を間引くことで、目標レートにあった画
像や音声の伝送が可能となる。また、送信側端末でも受
信側端末で行っているような過負荷時の処理のスキップ
機能を導入することで送信側端末の過負荷による破綻を
押さえることができる。

【０１１９】上記で説明したＡＬの情報を必要に応じ
て、必要な情報だけを伝送できるようにすることによっ
て、アナログ電話回線のような狭帯域の通信路には伝送
情報量を調節できるので有効である。実現方法として
は、送信側端末でデータ自身に付加するデータ管理情報
を予めデータ送信前に決定し、受信端末に使用するデー
タ管理情報を制御情報（たとえば、ランダムアクセスフ
ラグだけを使用するとか）として通知するとともに、受
信側端末では得られた制御情報をもとに、前記伝送フォ
ーマット記憶部１０３で記憶する伝送構造に関する情報
（どのＡＬの情報を使用するか表している）を書き換え
ることにより、送信側で使用するＡＬの情報（データ管
理情報）の組み替えが可能になる（図１９〜図２０参
照）。

【０１２０】図４は、送信すべき画像や音声のデータに
付加するヘッダ情報の動的な変更方法について説明する
図である。図の例では、伝送すべきデータ（ＥＳ）をデ
ータ片に分解し、得られたデータ片に、データの順序関
係を示すための識別情報（シーケンス番号）と、データ
片の処理可能な開始位置であるかどうかを示す情報（マ
ーカービット）と、データ片の転送に関する時間情報
（タイムスタンプ）とを、本発明の伝送管理情報に対応
するものとして、通信ヘッダの形でデータ片に付加して
いる。

【０１２１】具体的な例としては、ＲＴＰ（Ｒｅａｌ
ｔｉｍｅＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ、ＲＦ
Ｃ１８８９）では上記のシーケンス番号、マーカービッ
ト、タイムスタンプ、オブジェクトＩＤ（ＳＳＲＣと呼
ばれている）、バージョン番号などの情報を通信ヘッダ
として使用している。ヘッダ情報の項目の拡張は可能で
あるが、上記の項目は固定の項目として必ず付加され
る。しかし、複数の異なる符号化の画像や音声を複数、
同時に伝送する通信環境で、ＴＶ電話のようにリアルタ
イム通信とビデオ・オン・デマンドのように蓄積メディ
アの伝送が混在する場合、通信ヘッダの持つ意味合いが
異なり、識別する手段が必要である。

【０１２２】例えば、タイムスタンプの情報は、ＭＰＥ
Ｇ１／２の場合は前述したように再生時刻であるＰＴＳ
を示すが、Ｈ．２６１やＨ．２６３ではエンコードされ
た時間間隔を表す。しかし、Ｈ．２６３を音声と同期を
とって処理を行いたい場合、タイムスタンプがＰＴＳの
情報であることを示す必要がある。なぜならば、Ｈ．２
６３の場合、タイムスタンプの情報は、エンコードされ
たフレーム間の時間間隔を示すのであって、１枚目のフ
レームのタイムスタンプはランダムであるとＲＴＰで定
義されているからである。

【０１２３】そこで、（ａ）タイムスタンプがＰＴＳで
あるかないかを示すフラグを通信ヘッダ情報（通信ヘッ
ダの拡張が必要になる）もしくは、（ｂ）Ｈ．２６３や
Ｈ．２６１のペイロードのヘッダ情報（つまり、ＡＬの
情報）として付加する必要がある（この場合、ペイロー
ド情報の拡張が必要になる）。

【０１２４】ＲＴＰのヘッダ情報として、データ片の処
理可能な開始位置であるかどうかを示す情報であるマー
カビットが付加されているが、ＡＬの情報としても前述
したように、データに対してアクセスできる開始時点で
あることを示すアクセスフラグ、ランダムにデータに対
してアクセスすることができることを示すランダムアク
セスフラグを持たせたい場合がある。重複して、通信ヘ
ッダに持たせるのは効率が悪くなるため、ＡＬのフラグ
を通信ヘッダで用意しているフラグで代用させる方法も
考えられる。

【０１２５】（ｃ）ＡＬにフラグを付加せずに通信ヘッ
ダに付加しているヘッダでＡＬのフラグを代用させるこ
とを示すフラグを通信ヘッダに新たに設けるか、通信ヘ
ッダのマーカービットはＡＬのものと同じであると定義
することで、問題は解決される（ＡＬに持たせるよりも
解釈が早くできことが期待できる）。つまり、マーカー
ビットがＡＬのフラグと同じ意味を持つかどうかを示す
フラグである。この場合、通信ヘッダの改良もしくは、
拡張領域に記述することが考えられる。

【０１２６】逆に、（ｄ）通信ヘッダのマーカビットの
意味をＡＬに少なくともランダムアクセスフラグもしく
は、アクセスフラグのいずれかが存在することを意味す
るように解釈するようにしてもよい。この場合、従来と
は解釈の意味が変わったことを知るには通信ヘッダのバ
ージョン番号で対応できる。これ以外に、単純な方法と
しては、通信ヘッダもしくはＡＬのヘッダにのみアクセ
スフラグやランダムアクセスフラグを設ければ処理は簡
単である（前者の場合、フラグを両方とも設ける場合も
考えられるが、通信ヘッダの新たな拡張が必要にな
る）。

【０１２７】データ処理の優先度を示す情報をＡＬの情
報として付加することは述べたが、通信ヘッダにデータ
の処理の優先度を付加することによって、データ処理の
優先度の処理の判定がネットワーク上においてもデータ
の中身を解釈せずに行うことが可能となる。なお、ＩＰ
ｖ６の場合、ＲＴＰのレベルより下位のレイヤーで付加
することが可能である。

【０１２８】ＲＴＰの通信ヘッダにデータの処理の有効
期間を示すためのタイマーもしくはカウンタを付加する
ことで、伝送されてくるパケットのある状態変化がどの
ように変化しているかを判断することができる。たとえ
ば、必要となるデコーダソフトウェアが、アクセス速度
の遅い記憶装置に記憶されている場合、デコーダが必要
になるという情報と、タイマーやカウンターにより、い
つの時点で必要になるかが判断することが可能になる。
この場合、用途によってはＡＬの情報にタイマーやカウ
ンター、データの処理の優先度の情報は不要である。

【０１２９】図５（ａ）〜図５（ｂ）、と図６（ａ）〜
図６（ｄ）は、ＡＬ情報の付加方法について説明する図
である。

【０１３０】図５（ａ）に示した様に、ＡＬを伝送すべ
きデータの先頭にのみ付加するか、あるいは、図５
（ｂ）に示した様に、伝送すべきデータ（ＥＳ）を１つ
以上のデータ片に分解した後のデータ片のそれぞれに付
加するかを通知する制御情報を、受信端末へ送付するこ
とにより伝送情報の取り扱い粒度を選択できるようにす
ることが可能になる。ＡＬを細分化されたデータに対し
てつけることで、アクセス遅延が問題になるような場合
には有効である。

【０１３１】前述したように、受信側でのデータ管理情
報の組み替えや、データ管理情報のデータへの配置方法
の変更が行われることを予め受信側端末に通知するため
に、フラグ、カウンター、タイマーのような表現方法を
用いて、ＡＬの情報として用意したり、通信ヘッダとし
て用意して受信端末に通知することで、受信端末対応が
スムーズにできる。

【０１３２】これまでの例ではＲＴＰのヘッダ（又は、
通信ヘッダ）とＡＬの情報の重複を回避する方法や、Ｒ
ＴＰの通信ヘッダやＡＬの情報を拡張する方法について
述べた。しかし、本発明は、必ずしもＲＴＰである必要
はない。たとえば、ＵＤＰやＴＣＰを使って独自の通信
ヘッダやＡＬ情報を新たに定義してもよい。インターネ
ットプロファイルではＲＴＰを使うことはあるが、Ｒａ
ｗプロファイルではＲＴＰのような多機能なヘッダは定
義されていない。ＡＬ情報と通信ヘッダに関する考え方
としては、次の４通りの考え方ができる（図６（ａ）〜
図６（ｄ）参照）。

【０１３３】（１）ＲＴＰとＡＬで、既に割り当てられ
ているヘッダ情報が重複しないように、ＲＴＰのヘッダ
情報もしくはＡＬの情報を修正、拡張する（とくにタイ
ムスタンプの情報が重複、タイマーやカウンター、デー
タの処理の優先度情報が拡張情報となる）。あるいは、
ＲＴＰのヘッダも拡張せず、ＡＬの情報もＲＴＰのもの
と重複していても考慮しない方法でもよい。これらに関
してはこれまでに示した内容に相当する。ＲＴＰは既に
一部、Ｈ．３２３で実用化されているので、互換性を保
ったＲＴＰの拡張は有効である。（図６（ａ）参照）（２）ＲＴＰにこだわらずに、通信ヘッダを簡略にして
（たとえば、シーケンス番号だけにするとか）、残りを
ＡＬ情報に多機能な制御情報として持たせる。また、Ａ
Ｌ情報で使用する項目を通信前に可変に設定できるよう
にすることで、柔軟な伝送フォーマットが規定できる。
（図６（ｂ）参照）（３）ＲＴＰにこだわらずに、ＡＬの情報を簡略にして
（極端な例では、ＡＬには情報を付加しない）、通信ヘ
ッダにすべての制御情報を持たせる。通信ヘッダとして
頻繁によく参照されうるシーケンス番号、タイムスタン
プ、マーカービット、ペイロードタイプ、オブジェクト
ＩＤに関しては固定のヘッダ情報としておき、データ処
理の優先度情報、タイマー情報に関しては拡張情報とし
て、拡張情報が存在するどうかを示す識別子を設けてお
いて、拡張情報が定義されていれば参照するようにして
もよい。（図６（ｃ）参照）（４）ＲＴＰにこだわらず、通信ヘッダ、ＡＬの情報を
簡略にして、これら通信ヘッダやＡＬ情報とは、別のパ
ケットとして、フォーマットを定義して、伝送する。例
えば、ＡＬの情報はマーカービット、タイムスタンプ、
オブジェクトＩＤだけ定義し、通信ヘッダもシーケンス
番号だけを定義し、これらの情報とは別の伝送パケット
（第２のパケット）として、ペイロード情報、データ処
理の優先度情報、タイマー情報などを定義し、伝送する
方法も考えられる。（図６（ｄ）参照）上記に示したように、用途や、既に画像や音声に付加さ
れているヘッダ情報を考慮すれば、用途にあわせて、通
信ヘッダ、ＡＬの情報、データとは別に伝送するパケッ
ト（第２のパケット）を自由に定義できる（カスタイマ
イズできる）ようにするのが望ましい。

【０１３４】図７は、複数の論理的な伝送路を動的に多
重化、分離して情報の伝送を行う方法について説明する
図である。論理的な伝送路の数を節約するために、利用
者の指示もしくは論理的な伝送路の数に応じて、複数の
データもしくは制御情報を伝送するための論理的な伝送
路の情報の多重化を開始したり、終了させることが可能
な情報多重部を伝送部に、多重化された情報を分離する
情報分離部を受信管理部に設けることにより実現でき
る。

【０１３５】なお、図７では情報多重部を“Ｇｒｏｕｐ
ＭＵＸ”とよんでおり、具体的にはＨ．２２３のよう
な多重化方式を用いればよい。このＧｒｏｕｐＭＵＸ
は送受信端末で設けてもよいし、中継のルータや端末
に設けることによって、狭帯域への通信路への対応や、
ＧｒｏｕｐＭＵＸをＨ．２２３で実現すればＨ．３２
４と相互接続できる。

【０１３６】情報多重部に関する制御情報（多重化制御
情報）を素早く取り出すために、情報多重部の制御情報
を情報多重部でデータと多重化して送信するのではな
く、多重化せずに別の論理的な伝送路で伝送すること
で、多重化による遅延を低減することができる。これに
伴って、情報多重部に関する制御情報をデータと多重化
して伝送するのか、データと多重化して送信するのでは
なく、多重化せずに別の論理的な伝送路で伝送するのか
を通知して伝送することで、従来の多重化と整合性を保
たせたり、多重化による遅延を低減させるかを利用者で
選択することが可能になる。ここで、情報多重部に関す
る多重化制御情報とは、例えば、情報多重部が、各デー
タに対して、どの様な多重化を行っているのかという、
多重化の内容を示す情報である。

【０１３７】前述したように、同様に、少なくとも多重
化の開始と終了を通知する情報、多重化すべき論理的な
伝送路の組合せを通知するための情報、多重化に関する
制御情報（多重化制御情報）の伝送方法の通知を、フラ
グ、カウンタ、タイマーのような表現方法で、制御情報
として伝送、もしくはデータ管理情報としてデータとと
もに、受信側端末に伝送することで、受信側でのセット
アップの時間を短縮できる。また、前述したようにフラ
グ、カウンタ、タイマーを表現する項目はＲＴＰの送信
ヘッダに設けてもよい。

【０１３８】複数個の情報多重部や情報分離部が存在す
る場合、情報多重部や情報分離部を識別するための識別
子とともに制御情報（多重化制御情報）を伝送すれば、
どの情報多重部に関する制御情報（多重化制御情報）か
を識別することができる。制御情報（多重化制御情報）
としては、多重化のパターンなどがあげられる。また、
情報多重部や情報分離部の識別子を乱数を用いて、端末
間で決定することで情報多重部の識別子を生成すること
ができる。たとえば、送受信端末間で決められた範囲で
の乱数を発生させ、大きい方の値を情報多重部の識別子
（識別番号）とすればよい。

【０１３９】情報多重部で多重化されたデータは、従
来、ＲＴＰで定義されているメディアタイプとは異なる
ため、ＲＴＰのペイロード・タイプに、情報多重部で多
重化された情報であることを示す情報（新たなメディア
タイプ、Ｈ．２２３を定義）を定義すればよい。

【０１４０】多重化されたデータに対するアクセス速度
を向上させる方法として、情報多重部で伝送もしくは記
録する情報を制御情報、データ情報の順に配置すること
で多重化された情報の解析を早くできることが期待でき
る。また、制御情報に付加するデータ管理情報で記述す
る項目は固定にし、データとは異なる識別子（ユニーク
なパターン）を付加して多重化することでヘッダ情報の
解析を早くできる。

【０１４１】図８は放送番組の伝送手順について説明す
るための図である。論理的な伝送路の識別子と放送番組
の識別子の対応関係を放送番組の情報として制御情報を
伝送するか、放送番組の識別子をデータ管理情報（ＡＬ
情報）としてデータに付加して伝送することで複数の伝
送路で伝送されるデータがどの番組のために放送されて
いるのかを識別することが可能となる。また、データの
識別子（ＲＴＰではＳＳＲＣ）と論理的な伝送路の識別
子（たとえば、ＬＡＮのポート番号）との関係を制御情
報として受信側端末に伝送して、受信側端末では受信可
能であることを確認後（Ack／Reject）、対応するデー
タを伝送することにより、制御情報とデータを独立した
伝送路で伝送しても、データ間の対応関係がとれる。

【０１４２】放送番組やデータに対して伝送の順序関係
を示す識別子と、放送番組やデータが情報として利用で
きる有効期限を示すためのカウンタもしくはタイマーの
情報とを組み合わせて、放送番組やデータに付加して伝
送することで、戻りチャンネルなしで放送が実現できる
（有効期限が過ぎそうになったら、不足の情報があって
も放送番組の情報やデータの再生を開始する）。単一の
通信ポートのアドレス（マルチキャストアドレス）を使
って、制御情報とデータに分離せずに放送する方法も考
えられる。

【０１４３】なお、バックチャンネルを持たない通信の
場合、データの構造情報を受信端末が知ることができる
ように、制御情報はデータよりも十分、前もって伝送し
ておく必要がある。また、制御情報は一般には、パケッ
トロスのない信頼性の高い伝送チャンネルで伝送すべき
であるが、信頼性の低い伝送チャネルを用いる場合は周
期的に同じ伝送シーケンス番号を持った制御情報を繰り
返し伝送する必要がある。これはセットアップ時間に関
する制御情報を送る場合に限った話ではない。

【０１４４】また、データ管理情報として付加可能な項
目（たとえば、アクセスフラグ、ランダムアクセスフラ
グ、データの再生時刻（ＰＴＳ）、データ処理の優先度
情報など）を選択して、制御情報としてデータの識別子
（ＳＳＲＣ）とともにデータとは別の論理的な伝送路で
伝送するか、データとともにデータ管理情報（ＡＬの情
報）として伝送するかを、データ送信前に送信側で決定
して、受信側に制御情報として通知して伝送することで
柔軟なデータの管理と伝送が可能となる。

【０１４５】これにより、ＡＬには情報を付加せずにデ
ータ情報の伝送を行うことができるので、ＲＴＰを用い
て画像や音声のデータを伝送する際に、従来から定義さ
れているペイロードの定義を拡張する必要がなくなる。

【０１４６】図９（ａ）〜図９（ｂ）は、プログラムや
データの読み込み、立ち上げ時間を考慮した画像や音声
の伝送方法を示す図である。特に、衛星放送や携帯端末
のように戻りチャンネルがなく一方向で、端末の資源が
限られている場合で、プログラムやデータが受信側端末
に存在して利用する場合、必要となるプログラム（例え
ば、Ｈ．２６３、ＭＰＥＧ１／２、音声のデコーダのソ
フトウェアなど）やデータ（たとえば、画像データや音
声のデータ）が、読み込みに時間がかかる記憶装置（た
とえば、ＤＶＤ、ハードディスク、ネットワーク上のフ
ァイルサーバなど）に存在する場合に、予め必要となる
プログラムやデータを識別する識別子と、伝送されるス
トリームの識別子（たとえば、ＳＳＲＣや、Ｌｏｇｉｃ
ａｌＣｈａｎｎｅｌＮｕｍｂｅｒ）、受信端末で必
要となる時点を推定するためのフラグ、カウンタ（カウ
ントアップ、ダウン）、タイマーのような表現方法で、
制御情報として受信、もしくはデータ管理情報としてデ
ータとともに受信することで、必要となるプログラムや
データのセットアップ時間の短縮が可能となる（図２
２）。

【０１４７】一方、プログラムやデータが送信される場
合、プログラムやデータの受信端末での記憶先（たとえ
ば、ハードディスク、メモリー）、起動や読み込みにか
かる時間、端末の種類や記憶先と起動や読みとりにかか
る時間の対応関係（例えば、ＣＰＵパワー、記憶デバイ
スと平均的な応答時間の関係）、利用順序を示す情報と
ともにプログラムやデータを送信側から伝送すること
で、受信側端末で必要となるプログラムやデータを実際
に必要となる場合、プログラムやデータの記憶先や読み
出す時間に関してスケジューリングが可能となる。

【０１４８】図１０（ａ）〜図１０（ｂ）は、ザッピン
グ（ＴＶのチャンネル切り替え）に対する対応方法につ
いて説明する図である。

【０１４９】従来からある映像を受信するだけの衛星放
送とは異なり、プログラムを受信端末で実行しなければ
ならないとき、プログラムの読み込みや立ち上がるまで
のセットアップの時間が大きな問題となる。これは、携
帯端末のように利用資源が限られる場合でも同じことが
いえる。

【０１５０】解決策の１つとして、（ａ）利用者が視聴
するための主視聴部と、利用者が視聴している以外の番
組で、必要となるプログラムやデータが、読み込みに時
間がかかる記憶装置に存在する場合に、利用者が視聴し
ている番組以外の番組を受信端末が周期的に視聴する副
視聴部を備え、予め必要となるプログラムやデータを識
別する識別子と、受信端末で必要となる時点を推定する
ためのフラグ、カウンタ、タイマーといった情報と、番
組との対応関係を、制御情報（データとは別のパケット
で伝送される、端末処理を制御するための情報）として
受信、もしくはデータ管理情報（ＡＬの情報）としてデ
ータとともに受信して、プログラムやデータの読み込み
を準備しておくことで、受信側端末でのセットアップ時
間が短縮できることが期待できる。

【０１５１】解決策の２つ目としては、複数個のチャン
ネルで放送される画像の見出し画像だけを放送する放送
チャンネルを設け、視聴者が視聴番組を切り替えること
で、必要となるプログラムやデータが、読み込みに時間
がかかる記憶装置に存在した場合、一旦、視聴したい番
組の見出し画像を選択して視聴者に提示するか、読み込
み中であることを提示するとともに、記憶装置から必要
となるプログラムやデータを読み込み、読み込み終了
後、視聴者が視聴したい番組を再開することで、セット
アップ時に発生する画面の停止が防止できる。ここでい
う見出し画像は、周期的に複数個のチャンネルで放送さ
れる番組をサンプリングした放送画像を指す。

【０１５２】また、タイマーは時間表現で、たとえば、
送信側から送られてくるデータストリームをデコードす
るのに必要なプログラムは現在からいつの時点で必要と
なるかを示す。カウンタは送受信端末間で決めた基本時
間単位で、何回目かを示す情報であればよい。フラグ
は、セットアップに必要な時間前に送出するデータもし
くは、制御情報（データとは別のパケットで伝送され
る、端末処理を制御する情報）とともに伝送して通知す
る。タイマー、カウンターともデータの中に埋め込んで
伝送してよいし、制御情報として伝送してもよい。

【０１５３】さらに、セットアップ時間の決定方法とし
ては、例えば、クロックベースで動作しているＩＳＤＮ
のような伝送路を用いた場合、送信側端末から受信端末
でプログラムやデータが必要となる時点を通知するため
に、伝送管理情報として伝送の順序関係を識別するため
の送信シリアル番号を用いて、データ管理情報としてデ
ータとともに、もしくは、制御情報として受信端末に通
知することで、セットアップが行われる時刻の予測が可
能になる。また、インターネットのようにジッタや遅延
により、伝送時間が変動する場合は、ＲＴＣＰ（インタ
ーネットのメディア伝送プロトコル）で既に実現されて
いるような手段で、ジッタや遅延時間から、伝送の伝播
遅延を加味してセットアップ時間に付加しておけばよ
い。

【０１５４】図１１から図２４は、実際に端末間で送受
信されるプロトコルの具体例を示す図である。

【０１５５】伝送フォーマットや伝送手続きはＡＳＮ．
１で記述した。又、本伝送フォーマットは、ＩＴＵの
Ｈ．２４５をベースに拡張を行った。図１１にもあるよ
うに、画像や音声のオブジェクトは階層構造をなしてい
てもよく、ここの例では、各オブジェクトＩＤは放送番
組の識別子（ＰｒｏｇｒａｍＩＤ）とオブジェクトＩＤ
（ＳＳＲＣ）の属性をもち、画像間の構造情報、合成
方法はＪａｖａ，ＶＲＭＬといったスクリプト言語で記
述する。

【０１５６】図１１は、オブジェクト間の関係について
の例を示す図である。

【０１５７】同図において、オブジェクトは、映像、音
声、ＣＧ、テキストなどのメディアである。同図の例で
は、オブジェクトは階層構造を成している。各オブジェ
クトは、プログラム番号（ＴＶのチャンネルに相当、
“ＰｒｏｇｒａｍＩＤ”）とオブジェクトを識別する
オブジェクト識別子“ＯｂｊｅｃｔＩＤ”を持つ。Ｒ
ＴＰ（インターネットで用いられるメディア伝送のプロ
トコル、ＲｅａｌｔｉｍｅＴｒａｎｓｆｅｒＰｒｏ
ｔｏｃｏｌ）で各オブジェクトを伝送する場合は、オブ
ジェクト識別子はＳＳＲＣ（同期ソース識別子）に対応
させることで容易にオブジェクトの識別が可能である。
なお、オブジェクト間の構造記述はＪＡＶＡ、ＶＲＭＬ
といった記述言語で記述することが可能である。

【０１５８】これらのオブジェクトの伝送方法は２通り
考えられる。１つは放送型であり、送信側端末から一方
的に伝送する形態である。もう１つは送受信端末間（端
末Ａ、端末Ｂ）でオブジェクトの伝送を行う形態（通信
型）も考えられる。

【０１５９】例えば、伝送方法としてはインターネット
の場合はＲＴＰを用いることができる。制御情報は、Ｔ
Ｖ電話の規格ではＬＣＮＯと呼ばれる伝送チャンネルを
用いて伝送する。同図の例では伝送に複数の伝送チャン
ネルを用いているが、これらのチャンネルは同一の番組
チャンネル（ＰｒｏｇｒａｍＩＤ）が割り当てられて
いる。

【０１６０】図１２は、本発明で述べた機能を実現する
ためのプロトコルの実現方法について説明する図であ
る。ここではＴＶ電話の規格（Ｈ．３２４，Ｈ．３２
３）で用いられる伝送プロトコル（Ｈ．２４５）を用い
て説明する。Ｈ．２４５の拡張を行うことで本発明で述
べた機能を実現する。

【０１６１】同図の例で示した記述方法は、ＡＳＮ．１
と呼ばれるプロトコル記述方式である。“Ｔｅｒｍｉｎ
ａｌＣａｐａｂｉｌｉｔｙＳｅｔ”は端末の性能を
表現する。同図の例では、“ｍｐｅｇ４Ｃａｐａｂｉ
ｌｉｔｙ”と記した機能を従来からあるＨ．２４５に対
して拡張している。

【０１６２】図１３では、“ｍｐｅｇ４Ｃａｐａｂｉ
ｌｉｔｙ”は端末で同時に処理できる最大の映像の数
（“ＭａｘＮｕｍｂｅｒＯｆＶｉｄｅｏ”）、最
大の音声の数（“ＭａｘＮｕｍｂｅｒＯｆＳｏｕｎ
ｄｓ”）、端末で実現できる最大の多重化機能の数
（“ＭａｘＮｕｍｂｅｒＯｆＭｕｘ”）を記して
いる。

【０１６３】同図では、これらをまとめて、処理できる
最大のオブジェクト数（“NumberＯｆＰｒｏｃｅｓｓ
Ｏｂｊｅｃｔ”）として表現している。また、通信ヘ
ッダ（同図ではＡＬと表現）の変更が可能であるかを記
すフラグが記されている。この値が真であるとき通信ヘ
ッダの変更が可能である。“ＭＰＥＧ４Ｃａｐａｂｉ
ｌｉｔｙ”を用いて端末間で処理できるオブジェクト数
をお互いに通知する場合に、通知された側が受け入れ
（処理）可能であれば“ＭＥＰＧ４Ｃａｐａｂｉｌｉ
ｔｙＡｃｋ”を、そうでなければ“ＭＥＰＧ４Ｃａ
ｐａｂｉｌｉｔｙＲｅｊｅｃｔ”を、“ＭＥＰＧ４
Ｃａｐａｂｉｌｉｔｙ”を送信してきた端末に返す。

【０１６４】図１４では、１つの伝送チャンネル（この
例ではＬＡＮの伝送チャンネル）を複数の論理的なチャ
ンネルで共有して使用するために複数の論理的なチャン
ネルを１つの伝送チャンネルに多重化する前述のＧｒｏ
ｕｐＭＵＸを使用するためのプロトコルの記述方法に
ついて示している。同図の例では、ＬＡＮ（ローカルエ
リアネトワーク）の伝送チャンネル（“ＬＡＮＰｏｒ
ｔ Number”）に多重化手段（ＧｒｏｕｐＭＵＸ）を
対応づけている。“ＧｒｏｕｐＭｕｘＩＤ”は、多
重化手段を識別するための識別子である。“Ｃｒｅａｔ
ｅＧｒｏｕｐＭｕｘ”を用いて端末間で多重化手段を
使用する場合にお互いに通知する場合に、通知された側
が受け入れ（使用）可能であれば“ＣｒｅａｔｅＧｒ
ｏｕｐＭｕｘＡｃｋ”を、そうでなければ“Ｃｒｅａ
ｔｅＧｒｏｕｐＭｕｘＲｅｊｅｃｔ”を、“Ｃｒｅ
ａｔｅＧｒｏｕｐＭｕｘ”を送信してきた端末に返
す。多重化手段の逆の動作を行う手段である分離手段
は、同様な方法で実現出来る。

【０１６５】図１５では、既に生成した多重化手段を消
去する場合について記述している。

【０１６６】図１６では、ＬＡＮの伝送チャンネルと複
数の論理的なチャンネルの関係について記述している。

【０１６７】ＬＡＮの伝送チャンネルは“ＬＡＮＰｏ
ｒｔＮｕｍｂｅｒ”で、複数の論理的なチャンネルは
“ＬｏｇｉｃａｌＰｏｒｔＮｕｍｂｅｒ”で記述す
る。

【０１６８】同図の例では、１つのＬＡＮの伝送チャン
ネルに対して最大１５個の論理的なチャンネルを対応づ
けることが可能である。

【０１６９】尚、同図において、使用できるＭＵＸの数
が、１個だけの場合は、ＧｒｏｕｐＭｕｘＩＤは、不
要である。又、Ｍｕｘを複数使用する場合は、Ｈ．２２
３の各コマンドに対してＧｒｏｕｐＭｕｘＩＤが必
要である。又、多重化と分離手段との間で用いられるポ
ートの対応関係を通知するためのフラグを設けても良
い。又、制御情報も多重化するか、別の論理的な伝送路
を介して伝送するかを選択出来るようにするためのコマ
ンドを設けても良い。

【０１７０】図１４〜図１６の説明では伝送チャンネル
はＬＡＮであるが、Ｈ．２２３、ＭＰＥＧ２のようにイ
ンターネットプロトコルを使わない方式でもよい。

【０１７１】図１７では、“ＯｐｅｎＬｏｇｉｃａｌ
Ｃｈａｎｎｅｌ”は伝送チャンネルの属性を定義する
ためのプロトコル記述を示している。同図の例では、
Ｈ．２４５のプロトコルに対して、“ＭＰＥＧ４Ｌｏ
ｇｉｃａｌＣｈａｎｎｅｌＰａｒａｍｅｔｅｒｓ”を
拡張定義している。

【０１７２】図１８では、ＬＡＮの伝送チャンネルに対
して、プログラム番号（ＴＶのチャンネルに相当）と、
プログラムの名前とを対応づけている（“ ＭＰＥＧ４
ＬｏｇｉｃａｌＣａｎｎｅｌＰａｒａｍｅｔｅｒ
ｓ”）ことを示している。

【０１７３】又、同図において、“Ｂｒｏａｄｃａｓｔ
ＣｈａｎｎｅｌＰｒｏｇｒａｍ”は、ＬＡＮの伝送
チャンネルとプログラム番号との対応付けを放送型で送
信する場合の記述方法である。同図の例では、最大１０
２３個の伝送チャンネルとプログラム番号の対応関係を
送付することが可能である。放送の場合は送信側から受
信側へ一方的に送信するだけであるため、これらの情報
を伝送中の損失を考慮して周期的に伝送する必要があ
る。

【０１７４】図１９では、プログラムとして伝送される
オブジェクト（例えば、映像、音声など）の属性につい
て記述している（“ ＭＰＥＧ４ＯｂｊｅｃｔＣｌ
ａｓｓｄｅｆｉｎｉｔｉｏｎ”）。プログラムの識別子
（“ＰｒｏｇｒａｍＩＤ”）に対してオブジェクトの
情報（“ＯｂｊｅｃｔＳｔｒｕｃｔｕｒｅＥｌｅｍ
ｅｎｔ”）を対応付けている。最大で１０２３個のオブ
ジェクトを対応付けることが可能である。オブジェクト
の情報としては、ＬＡＮの伝送チャンネル（“ＬＡＮ
ＰｏｒｔＮｕｍｂｅｒ”）、スクランブルが使用され
ているか否かのフラグ（“ＳｃｒａｍｂｌｅＦｌａ
ｇ”）、端末が過負荷である場合の処理の優先度を変更
するためのオフセット値を定義するフィールド（“ＣＧ
ＤＯｆｆｓｅｔ”）、そして、伝送するメディア（映
像、音声など）のタイプを識別するための識別子（Ｍｅ
ｄｉａＴｙｐｅ）を記述する。

【０１７５】図２０の例では、ＥＳ（ここでは１フレー
ム分の映像に相当するデータ列と定義する）の復号処理
を管理するためにＡＬ（ここでは１フレーム分の映像を
復号するために必要な付加情報と定義する）が付加され
ている。ＡＬの情報としては、（１）ＲａｎｄｏｍＡ
ｃｃｅｓｓＦｌａｇ（単独で再生可能であるかどうか
を示すフラグ、フレーム内符号化された映像フレームで
あれば真である）、（２）Ｐｒｅｓｅｎｔａｔｉｏｎ
ＴｉｍｅＳｔａｍｐ（フレームの表示時刻）、（３）
ＣＧＤＰｒｉｏｒｉｔｙ（端末が過負荷時に処理の優
先度を決定するための優先度の値）が定義されている。
これらの１フレーム分のデータ列を、ＲＴＰ（インター
ネットで連続メディアを伝送するためのプロトコル，Ｒ
ｅａｌｔｉｍｅＴｒａｎｓｆｅｒＰｒｏｔｏｃｏ
ｌ）を用いて伝送する場合の例を示している。“ＡＬ
Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ”は、上記のＡＬで表
現できる最大値を変更するための伝送表現である。

【０１７６】同図の例では、“ＲａｎｄｏｍＡｃｃｅ
ｓｓＦｌａｇＭａｘＢｉｔ”ととして、最大で２
ビットの表現が可能である。例えば０ならば、Ｒａｎｄ
ｏｍＡｃｃｅｓｓＦｌａｇは使用しない。２ならば最
大値は３である。

【０１７７】尚、実数部と仮数部による表現を行っても
良い（例えば、３＾６）。又、非設定時は、デフォルト
で決められた状態で動作することにしても良い。

【０１７８】図２１では、“ＳｅｔｕｐＲｅｑｕｅｓ
ｔ”は、セットアップ時間を送信するための伝送表現を
示している。プログラムを送信する前に“ Ｓｅｔｕｐ
Ｒｅｑｕｅｓｔ”は送信され、伝送される伝送チャン
ネル番号（“ＬｏｇｉｃａｌＣｈａｎｎｅｌＮｕｍｂ
ｅｒ”）と、実行するプログラムＩＤ（“excuteＰｒｏ
ｇｒａｍＮｕｍｂｅｒ”）、使用するデータＩＤ
（“ ｄａｔａＮｕｍｂｅｒ”）、実行するコマン
ドのＩＤ（“ｅｘｅｃｕｔｅＣｏｍｍａｎｄＮｕｍｂ
ｅｒ”）を対応付けて受信端末へ送付する。また、別の
表現方法として、伝送チャンネル番号と対応付けて、実
行の許可のフラグ（“ｆｌａｇ”）、あと何回Ｓｅｔｕ
ｐＲｅｑｕｅｓｔを受信したら実行するかを記したカ
ウンタ（“ｃｏｕｎｔｅｒ”）、あとどれくらいの時間
で実行するかを示すタイマー値（“ｔｉｍｅｒ”）であ
ってもよい。

【０１７９】尚、要求予定のリクエストの例としては、
ＡＬ情報の書き換え、ＧｒｏｕｐＭｕｘの立ち上がり時
間の確保などがあげられる。

【０１８０】図２２は、図２０で説明したＡＬの使用の
有無を送信端末から受信端末へ通知するための伝送表現
について説明する図である（“ＣｏｎｔｒｏｌＡＬ
ｄｅｆｉｎｉｔｉｏｎ”）。

【０１８１】同図において、“ＲａｎｄｏｍＡｃｃｅ
ｓｓＦｌａｇＵｓｅ”が真ならばＲａｎｄｏｍＡ
ｃｃｅｓｓＦｌａｇは使用する。そうでなければ使用
しない。このＡＬの変更通知は制御情報としてデータと
は別の伝送チャンネルで伝送してもよいし、データとと
もに同一の伝送チャンネルで伝送してもよい。

【０１８２】尚、実行するプログラムとしては、デコー
ダプログラムなどがあげられる。又、セットアップのリ
クエストは、放送であっても通信であっても利用出来
る。又、制御情報としての項目を、ＡＬの情報としてど
の項目を使用するかを上記のリクエストで受信端末に指
示する。又、同様に通信ヘッダにどの項目を、ＡＬの情
報としてどの項目を、制御情報としてごの項目を使用す
るかを受信端末に指示出来る。

【０１８３】図２３では、情報枠組み識別子（“ｈｅａ
ｄｅｒＩＤ”）を用いて、伝送するヘッダ情報（デー
タ管理情報、伝送管理情報、制御情報）の構造を送受信
端末間で用途に応じて変更するための伝送表現の例を示
している。

【０１８４】同図において、“ｃｌａｓｓＥＳｈｅ
ａｄｅｒ”は、データと同じ伝送チャンネルで伝送され
るデータ管理情報や、伝送管理情報の伝送される情報の
構造を、情報枠組み識別子により送受信端末間で区別し
ている。

【０１８５】例えば“ｈｅａｄｅｒＩＤ”の値が０な
らば、ｂｕｆｆｅｒＳｉｚｅＥＳの項目だけ用い、
“ｈｅａｄｅｒＩＤ”の値が１ならば“ｒｅｓｅｒｖ
ｅｄ”の項目を加えて用いる。

【０１８６】又、デフォルト識別子（“ｕｓｅＨｅａ
ｄｅｒＥｘｔｅｎｓｉｏｎ”）を用いることでデフォ
ルトの形式の情報の枠組みを用いるか、用いないかを判
定する。“ｕｓｅＨｅａｄｅｒＥｘｔｅｎｓｉｏ
ｎ”が真であれば、ｉｆ文の内部の項目が用いられる。
これらの構造情報に関しては予め送受信端末間で取り決
められているものとする。なお、情報枠組み識別子とデ
フォルト識別子は、何れか一方を使用する構成であって
もよい。

【０１８７】図２４では、“ＡＬｃｏｎｆｉｇｕｒａ
ｔｉｏｎ”は、データとは異なる伝送チャンネルで伝送
される制御情報の構造を送受信端末間で用途に応じて変
更する場合の例を示している。情報枠組み識別子とデフ
ォルト識別子の使用方法は図２３の場合と同じである。

【０１８８】本発明では、複数の動画や音声を同時に合
成して表示させるシステムの実現方法について、下記の
観点から具体的に述べた。

【０１８９】（１）複数の論理的な伝送路を用いて画像
や音声の伝送（通信と放送）及び、それらを制御する方
法。特に、制御情報とデータをそれぞれ、伝送する論理
的な伝送路を独立させて伝送する方法について述べた。

【０１９０】（２）送信すべき画像や音声のデータに付
加するヘッダ情報（ＡＬの情報）の動的な変更方法。

【０１９１】（３）送信のために付加する通信用のヘッ
ダ情報の動的な変更方法。

【０１９２】具体的には、（２）と（３）に関しては、
ＡＬの情報と通信用ヘッダで重複している情報について
統合して管理する方法や、ＡＬの情報を制御情報として
伝送する方法について述べた。

【０１９３】（４）複数の論理的な伝送路を、動的に多
重化、分離して情報の伝送を行う方法。

【０１９４】伝送路のチャンネル数を節約する方法、効
率的な多重化を実現する方法について述べた。

【０１９５】（５）プログラムやデータの読み込み、立
ち上げ時間を考慮した画像や音声の伝送方法。様々な機
能、用途で見かけ上のセットアップ時間の短縮方法につ
いて述べた。

【０１９６】（６）ザッピングに対する画像や音声の伝
送方法。

【０１９７】尚、本発明は、２次元の画像合成だけに限
定されない。２次元の画像と３次元の画像を組み合わせ
た表現形式でもよいし、広視野画像（パノラマ画像）の
ように複数の画像を隣接するように画像合成するような
画像合成方法も含めてもよい。また、本発明で対象とし
ている通信形態は、有線の双方向ＣＡＴＶやＢ−ＩＳＤ
Ｎだけではない。例えば、センター側端末から家庭側端
末への映像や音声の伝送は電波（例えば、ＶＨＦ帯、Ｕ
ＨＦ帯）、衛星放送で、家庭側端末からセンター側端末
への情報発信はアナログの電話回線やＮ−ＩＳＤＮであ
ってもよい（映像、音声、データも必ずしも多重化され
ている必要はない）。

【０１９８】また、ＩｒＤＡ、ＰＨＳ（パーソナル・ハ
ンディー・ホン）や無線ＬＡＮのような無線を利用した
通信形態であってもよい。さらに、対象とする端末は、
携帯情報端末のように携帯型の端末であっても、セット
トップＢＯＸ、パーソナルコンピュータのように卓上型
の端末であってもよい。なお、応用分野としては、ＴＶ
電話、多地点の監視システム、マルチメディアのデータ
ベース検索システム、ゲームなどが挙げられ、本発明は
受信端末だけではなく、受信端末に接続されるサーバや
中継の機器なども含まれる。

【０１９９】さらに、これまでの例ではＲＴＰの（通
信）ヘッダとＡＬの情報の重複を回避する方法や、ＲＴ
Ｐの通信ヘッダやＡＬの情報を拡張する方法について述
べた。しかし、本発明は、必ずしもＲＴＰである必要は
ない。たとえば、ＵＤＰやＴＣＰを使って独自の通信ヘ
ッダやＡＬ情報を新たに定義してもよい。インターネッ
トプロファイルではＲＴＰを使うことはあるが、Ｒａｗ
プロファイルではＲＴＰのような多機能なヘッダは定義
されていない。ＡＬ情報と通信ヘッダに関する考え方と
しては、前述したように４通りの考え方ができる。

【０２００】このように、送信端末と受信端末で使用す
るデータ管理情報、伝送管理情報、制御情報の各情報の
枠組み（例えば、１番最初は、ランダムアクセスのフラ
グで１ビットのフラグ情報として割り当て、２番めはシ
ーケンス番号で１６ビット割り当てるといった、付加す
る情報の順序とビット数をともなった情報の枠組み）を
動的に決定することで、状況に応じた情報の枠組みの変
更が可能になり、用途や伝送路に応じた変更ができる。

【０２０１】尚、各情報の枠組みとしては、図６（ａ）
〜図６（ｄ）において既に示したものあってもよいし、
ＲＴＰならば、データ管理情報（ＡＬ）はメディア毎の
ヘッダ情報（例えば、Ｈ．２６３ならＨ．２６３固有の
ビデオのヘッダ情報や、ペイロードのヘッダ情報）、伝
送管理情報はＲＴＰのヘッダ情報で、制御情報はＲＴＣ
ＰのようなＲＴＰを制御するような情報であってもよ
い。

【０２０２】また、送受信端末間で予め設定されている
公知の情報の枠組みで、情報の送受信して処理するか、
否かを示すためのデフォルト識別子をデータ管理情報、
伝送管理情報、制御情報（データとは別のパケットで伝
送される、端末処理を制御する情報）に、それぞれ設け
ることで、情報の枠組みの変更が行われているかどうか
を知ることができ、変更が行なわれている時だけ、デフ
ォルト識別子をセットし、前述の図１９〜図２０に示し
たような方法で変更内容（たとえば、タイムスタンプ情
報を３２ビットから１６ビットに変更する）を通知する
ことで、情報の枠組み情報を変更しない場合でも不要に
コンフィグレーション情報を送信しなくても済む。

【０２０３】たとえば、データ管理情報の情報の枠組み
を変更したいときには、次の２つの方法が考えられる。
まず、データ自身にデータ管理情報の情報の枠組みの変
更方法を記述する場合、データ管理情報の情報の枠組み
に関して記述されたデータ内に存在する情報のデフォル
ト識別子（固定の領域、位置に書き込む必要がある）を
セットし、そのあとに情報の枠組みの変更内容に関して
記述する。

【０２０４】もう１つの方法として制御情報（情報枠組
み制御情報）にデータの情報の枠組みの変更方法を記述
して、データ管理情報における情報の枠組みを変更する
場合、制御情報に設けられたデフォルト識別子をセット
し、変更するデータ管理情報の情報の枠組みの内容を記
述し、ＡＣＫ／Ｒｅｊｅｃｔで受信端末にデータ管理情
報の情報の枠組みが変更されたことを通知、確認してか
ら、情報の枠組みが変更されたデータを伝送する。伝送
管理情報、制御情報自身の情報の枠組みを変更する場合
も、同様に上記の２つの方法で実現できる（図２３〜図
２４）。

【０２０５】より具体的な例としては、例えば、ＭＰＥ
Ｇ２のヘッダ情報は固定であるが、ＭＰＥＧ２−ＴＳ
（トランスポート・ストリーム）のビデオ・ストリー
ム、オーディオ・ストリームを関係づけるプログラム・
マップテーブル（ＰＳＩで定義される）にデフォルト識
別子を設け、ビデオ・ストリーム、オーディオ・ストリ
ームの情報の枠組みの変更方法を記述したコンフィグレ
ーション・ストリームを定義しておくことで、デフォル
ト識別子がセットされていれば、まず、コンフィグレー
ション・ストリームを解釈してから、コンフィグレーシ
ョン・ストリームの内容に応じて、ビデオとオーディオ
のストリームのヘッダーを解釈することができる。コン
フィグレーションストリームは図２３〜図２４で示した
内容でよい。

【０２０６】尚、本発明の、伝送方法に関する及び／又
は伝送するデータの構造に関する内容（伝送フォーマッ
ト情報）は、上記実施の形態では、例えば、情報の枠組
みに対応している。

【０２０７】又、上記実施の形態では、変更しようとす
る、伝送方法に関する及び／又は伝送するデータの構造
に関する内容を伝送する場合を中心に述べたが、これに
限らず例えば、その内容の識別子のみを伝送する構成で
も勿論良い。この場合、送信装置としては、例えば、図
５２に示す様に、（１）伝送方法に関する及び／又は伝
送するデータの構造に関する内容、又はその内容を示す
識別子を、伝送フォーマット情報として、前記伝送する
データの伝送路と同一の伝送路、又は、前記伝送路とは
別の伝送路を用いて伝送する伝送手段５００１と、
（２）前記伝送方法に関する及び／又は伝送するデータ
の構造に関する内容と、その識別子とを複数種類格納す
る格納手段５００２とを備え、前記識別子が、データ管
理情報、伝送管理情報又は、端末側の処理を制御するた
めの情報の内、少なくとも一つの情報の中に含まれてい
る画像・音声送信装置であってもよい。又、受信装置と
しては、例えば、図５３に示す様に、上記画像・音声送
信装置から送信されてくる前記伝送フォーマット情報を
受信する受信手段５１０１と、前記受信した伝送フォー
マット情報を解釈する伝送情報解釈手段５１０２とを備
えた画像・音声受信装置であってもよい。更に、この画
像・音声受信装置は、前記伝送方法に関する及び／又は
伝送するデータの構造に関する内容と、その識別子とを
複数種類格納する格納手段５１０３を備え、前記伝送フ
ォーマット情報として前記識別子を受信した場合には、
前記識別子の内容を解釈する際に、前記格納手段に格納
されている内容を利用する構成であっても良い。

【０２０８】さらに、具体的には、予め情報の枠組みを
複数、送受信端末で取り決めて用意しておき、それら複
数種類の情報の枠組みの識別と、複数種のデータ管理情
報、伝送管理情報、制御情報（情報枠組み制御情報）を
識別するための情報枠組み識別子をデータとともに、も
しくは、制御情報として伝送することで、複数種のデー
タ管理情報、伝送管理情報、制御情報の各情報を識別す
ることが可能となり、伝送すべきメディアの形式や伝送
路の太さに応じて各情報の情報の枠組みを自由に選択す
ることができる。尚、本発明の識別子は、上記情報の枠
組み識別子に対応する。

【０２０９】これら情報の枠組み識別子、デフォルト識
別子は、伝送される情報の予め決められた固定長の領域
もしくは、位置に付加することで、受信側端末で、情報
の枠組みが変更されていても読み取り、解釈することが
できる。

【０２１０】又、上述した実施の形態で述べた構成以外
に、複数個のチャンネルで放送される画像の見出し画像
だけを放送する放送チャンネルを設け、視聴者が視聴番
組を切り替えることで、必要となるプログラムやデータ
のセットアップに時間がかかる場合、一旦、視聴したい
番組の見出し画像を選択して視聴者に提示する構成とし
ても良い。

【０２１１】以上のように本発明によれば、送信端末と
受信端末で使用するデータ管理情報、伝送管理情報、制
御情報の各情報の枠組みを動的に決定することで、状況
に応じた情報の枠組みの変更が可能になり、用途や伝送
路に応じた変更ができる。

【０２１２】また、送受信端末間で予め設定されている
公知の情報の枠組みで、情報の送受信して処理するか、
否かを示すためのデフォルト識別子をデータ管理情報、
伝送管理情報、制御情報に、それぞれ設けることで、情
報の枠組みの変更が行われているかどうかを知ることが
でき、変更が行なわれている時だけ、デフォルト識別子
をセットし、変更内容を通知することで、情報の枠組み
情報を変更しない場合でも不要にコンフィグレーション
情報を送信しなくても済む。

【０２１３】さらに、予め情報の枠組みを複数、送受信
端末で取り決めて用意しておき、複数種のデータ管理情
報、伝送管理情報、制御情報を識別するための情報枠組
み識別子をデータとともに、もしくは、制御情報として
伝送することで、複数種のデータ管理情報、伝送管理情
報、制御情報の各情報を識別することが可能となり、伝
送すべきメディアの形式や伝送路の太さに応じて各情報
の情報の枠組みを自由に選択することができる。

【０２１４】これら情報枠組み識別子、デフォルト識別
子は、伝送される情報の予め決められた固定長の領域も
しくは、位置に付加することで、受信側端末で、情報の
枠組みが変更されていても読み取り、解釈することがで
きる。

【０２１５】以下、本発明の実施の形態について図面を
参照して説明する。

【０２１６】尚、ここでは、主に上述した課題（Ｂ１）
〜（Ｂ３）の何れか一つを解決するものである。

【０２１７】本発明で使用する「画像」の意味は静止画
と動画の両方を含む。また、対象とする画像は、コンピ
ュータ・グラフィックス（ＣＧ）のような２次元画像と
ワイヤーフレーム・モデルから構成されるような３次元
の画像データであってもよい。

【０２１８】図３１は、本発明の実施の形態における画
像符号化、画像復号化装置の概略構成図である。

【０２１９】符号化された種々の情報を送信もしくは記
録する送信管理部４０１１は、同軸ケーブル、ＣＡＴ
Ｖ、ＬＡＮ、モデム等の情報を伝送する手段である。画
像符号化装置４１０１は、Ｈ．２６３、ＭＰＥＧ１／
２、ＪＰＥＧ、あるいは、ハフマン符号化といった画像
情報の符号化を行う画像符号部４０１２と、上記送信管
理部４０１１とを具備する構成である。又、画像復号化
装置４１０２は、符号化された種々の情報を受信する受
信管理部４０１３と、その受信された種々の画像情報の
復号を行う画像復号部４０１４と、復号された１つ以上
の画像を合成する画像合成部４０１５と、画像を出力す
るディスプレイやプリンターなどから構成される出力部
４０１６とを備えた構成である。

【０２２０】図３２は、本発明の実施の形態における音
声符号化、音声復号化装置の概略構成図である。

【０２２１】音声符号化装置４２０１は、符号化された
種々の情報を送信もしくは記録する送信管理部４０２１
と、Ｇ．７２１、ＭＰＥＧ１オーディオといった音声情
報の符号化を行う音声符号部４０２２とを具備する構成
である。又、音声復号化装置４２０２は、符号化された
種々の情報を受信する受信管理部４０２３と、前記種々
の音声情報の復号を行う音声復号部４０２４と、復号さ
れた１つ以上の音声を合成する音声合成部４０２５と、
音声を出力する出力手段４０２６とを備えた構成であ
る。

【０２２２】音声や動画像の時系列データは、具体的に
は上記の各装置で、符号化、又は復号化される。

【０２２３】図３１、図３２とも、通信環境としてはイ
ンターネットのように多重化の手段を意識せずに複数の
論理的な伝送路が利用できる通信環境であってもよし、
アナログ電話や衛星放送のように多重化手段を意識しな
ければならない通信環境であってもよい。また、端末の
接続形態としては、ＴＶ電話やＴＶ会議システムのよう
に端末間で双方向で映像や音声を送受信する形態や、衛
星放送やＣＡＴＶ、インターネット上での放送型の映像
や音声放送の形態が挙げられる。

【０２２４】同様に、画像や音声の合成方法に関して
は、ＪＡＶＡ、ＶＲＭＬ、ＭＨＥＧといったスクリプト
言語で、画像・音声と画像・音声の構造情報（表示位置
や表示時間）、画像・音声同士のグルーピングの方法、
画像の表示のレイヤ（深さ）、そして、オブジェクトＩ
Ｄ（画像、音声といった個々のオブジェクトを識別する
ためのＩＤ）と、これらの属性の関係を記述することに
よって画像や音声の合成方法が定義できる。合成方法を
記述したスクリプトはネットワークやローカルの記憶装
置から得られる。

【０２２５】尚、画像符号化装置、画像復号化装置、音
声符号化装置、音声復号化装置を、それぞれ任意の個数
で、任意の組み合わせで送受信の端末を構成してもよ
い。

【０２２６】図３３（ａ）は、過負荷時の処理の優先度
を管理する優先度付加部、優先度決定部について説明す
る図である。Ｈ．２６３やＧ．７２３などの符号化方法
で、符号化された情報の過負荷時の処理の優先度を予め
決められた基準で決定し、符号化された情報と決定され
た優先度を対応づける優先度付加部３１を画像符号化装
置４１０１や音声符号化装置４２０１に備える。

【０２２７】優先度の付加の基準は、たとえば、画像で
あればシーンチェンジ、編集者や利用者が指示した画像
フレームやストリーム、音声であれば、有音区間と無音
区間である。

【０２２８】過負荷時の処理の優先度を定義する優先度
の付加方法は、通信ヘッダへ付加する方法と符号化時に
ビデオやオーディオの符号化されるビットストリームの
ヘッダに埋め込む方法が考えられる。前者は、復号せず
に優先度に関する情報が得ることが可能であり、後者は
システムに依存せずにビットストリーム単体で独立に扱
うことが可能である。

【０２２９】図３３（ｂ）に示したように、通信ヘッダ
に優先度情報を付加する場合、１つの画像フレーム（例
たとえば、フレーム内符号化されたＩフレーム、フレー
ム間符号化されたＰ、Ｂフレーム）が複数個の送信パケ
ットに分割される場合、画像であれば単独の情報として
アクセス可能な画像フレームの先頭部分を伝送する通信
ヘッダのみに優先度を付加する（同一の画像フレーム内
で優先度が等しい場合、次のアクセス可能な画像フレー
ムの先頭が現れるまで、優先度は変わらないものとすれ
ばよい）。

【０２３０】また、復号化装置では、受信された種々の
符号化された情報の過負荷時の優先度に従って、処理の
方法を決定する優先度決定部３２を画像復号化装置４１
０２や音声復号化装置４２０２に備える。

【０２３１】図３４〜図３６は、優先度を付加する粒度
について説明する図である。端末での過負荷時の処理の
優先度を決定する２種類の優先度を用いて、デコード処
理を行なう。

【０２３２】すなわち、映像、音声といったビットスト
リーム単位での過負荷時の処理の優先度を定義するスト
リーム優先度（ＳｔｒｅａｍＰｒｉｏｒｉｔｙ；時系
列データ間優先度）と、同一ストリーム内の映像フレー
ムといったフレーム単位での過負荷時の処理の優先度を
定義するフレーム優先度（ＦｒａｍｅＰｒｉｏｒｉｔ
ｙ；時系列データ内優先度）を定義する（図３４参
照）。

【０２３３】前者のストリーム優先度により複数のビデ
オやオーディオの取り扱いが可能になる。後者のフレー
ム優先度により映像のシーンチェンジや編集者の意図に
応じて、同一のフレーム内符号化された映像フレーム
（Ｉフレーム）でも異なる優先度の付加が可能になる。

【０２３４】ストリーム優先度が表現する値の意味とし
ては、相対的な値として扱う場合と、絶対的な値として
扱う場合が考えられる（図３５、図３６参照）。

【０２３５】ストリーム優先度とフレーム優先度の取り
扱いが行なわれるのはネットワーク上であれば、ルータ
やゲートウェイといった中継端末、端末であれば、送信
端末と受信端末があげられる。

【０２３６】絶対的な値と、相対的な値の表現方法は２
通り考えられる。１つは、図３５で示した方法であり、
もう１つは図３６で示した方法である。

【０２３７】図３５では、絶対的な値の優先度とは、編
集者や機械的に付加された画像ストリームや音声ストリ
ームが過負荷時に処理される（又は、処理されるべき）
順序をあらわす値である（実際のネットワークや端末の
負荷変動を考慮した値ではない）。相対的な値の優先度
は、端末やネットワークの負荷に応じて、絶対的な優先
度の値を変更するための値である。

【０２３８】優先度を相対的な値と、絶対的な値に分離
して管理することで、ネットワークの負荷の変動などに
応じて、送信側や中継装置で相対的な値だけを変更する
ことで、元来、画像や音声ストリームに付加されていた
絶対的な優先度を残したままで、ハードディスクやＶＴ
Ｒへの記録が可能となる。このように絶対的な優先度の
値が記録されていれば、ネットワークの負荷変動などの
影響を受けていない形での映像や音声の再生が可能とな
る。なお、相対的な優先度や絶対的な優先度はデータと
は独立に制御チャンネルを通して伝送してもよい。

【０２３９】同様に、図３５では、ストリーム優先度よ
りも粒度を細かくして、過負荷時のフレームの処理の優
先度を定義するフレーム優先度を、相対的な優先度の値
として扱ったり、絶対的な優先度の値として扱うことも
可能である。たとえば、絶対的なフレーム優先度を符号
化された画像の情報内に記述し、ネットワークや端末の
負荷で変動を反映させるために、先の映像フレームに付
加した絶対的な優先度に対する相対的なフレーム優先度
を符号化された情報を伝送するための通信パケットの通
信ヘッダに記述することで、フレームレベルでも、オリ
ジナルの優先度を残しながらも、ネットワークや端末の
負荷に応じた優先度の付加が可能である。

【０２４０】なお、相対的な優先度は、通信ヘッダでは
なくデータとは独立して制御チャネルでフレームとの対
応関係を記述して伝送してもよい。これにより、元来、
画像や音声ストリームに付加されていた絶対的な優先度
を残したままで、ハードディスクやＶＴＲへの記録が可
能となる。

【０２４１】一方、図３５において、受信端末で記録を
行なわずに、ネットワークを介して伝送しながら受信端
末で再生を行なう場合、受信端末で絶対的な値と相対的
な値を分離して管理する必要がないため、送信側で予
め、フレーム、ストリームの両方のレベルの場合におい
ても、絶対値な優先度の値と相対的な優先度の値を送信
前に計算して絶対値のみを送ってもよい。

【０２４２】図３６において、絶対的な値の優先度と
は、ＳｔｒｅａｍＰｒｉｏｒｉｔｙと、Ｆｒａｍｅ
Ｐｒｉｏｒｉｔｙの関係から求められるフレーム間で一
意に決定される値である。相対的な値の優先度は、編集
者や機械的に付加された画像ストリームや音声ストリー
ムが過負荷時に処理される（又は、処理されるべき）順
序をあらわす値である。図３６の例では、映像、音声の
各ストリームのフレーム優先度（ｒｅｌａｔｉｖｅ；相
対値）とストリーム毎にストリーム優先度が付加されて
いる。

【０２４３】絶対的なフレーム優先度（ａｂｓｏｌｕｔ
ｅ；絶対値）は相対的なフレーム優先度と、ストリーム
優先度の和から求められる（即ち、絶対的なフレーム優
先度＝相対的なフレーム優先度＋ストリーム優先度）。
なお、この算出方法は減算したり、定数を掛け合わせる
ような方法でもよい。

【０２４４】絶対的なフレーム優先度は主としてネット
ワークで用いる。これはルータやゲイトウエイといった
中継装置で、ＳｔｒｅａｍＰｒｉｏｒｉｔｙとＦｒａ
ｍｅＰｒｉｏｒｉｔｙとを加味してフレーム毎の優先度
を決定する必要が絶対値による表現では不要になるから
である。この絶対的なフレーム優先度を用いることで中
継装置でのフレームの廃棄などの処理が容易になる。

【０２４５】一方、相対的なフレーム優先度は主として
記録、編集を行なう蓄積系への応用が期待できる。編集
作業では、複数の映像、音声ストリームを同時に扱うこ
とがある。そのような場合に、端末やネットワークの負
荷により再生できる映像ストリームやフレームの数には
限界が生じる可能性がある。

【０２４６】そのような場合に、ＳｔｒｅａｍＰｒｉ
ｏｒｉｔｙと、ＦｒａｍｅＰｒｉｏｒｉｔｙとを分離
して管理しておくだけで、例えば、編集者が、優先的に
表示させたい、あるいは、ユーザが、見たいストリーム
のＳｔｒｅａｍＰｒｉｏｒｉｔｙを変更するだけで、
絶対値の表現を行なっている時とは違い、ＦｒａｍｅＰ
ｒｉｏｒｉｔｙをすべて計算し直す必要がない。このよ
うに用途に応じて、絶対的な表現、相対的な表現を使い
分ける必要がある。

【０２４７】また、ストリーム優先度の値を相対的な値
として用いるか、絶対的な値として用いるかを記述する
ことで、伝送時にも、蓄積する場合にも有効な優先度の
表現が可能となる。

【０２４８】図３５の例では、ストリーム優先度に付随
して、ストリーム優先度が表現する値が絶対値である
か、相対値であるかを表現するフラグや識別子を設けて
区別する。フレーム優先度の場合は、通信ヘッダに相対
的な値が記述され、符号化されたフレーム内に絶対的な
値が記述されるため、フラグや識別子は不要である。

【０２４９】図３６の例では、フレーム優先度が絶対値
であるか相対値であるかを識別するためのフラグもしく
は識別子を設けている。絶対値であれば、ストリーム優
先度と相対的なフレーム優先度から算出されている優先
度であるから、算出の処理を中継装置や端末で行なわな
い。また、受信端末では、算出式が端末間で既知である
場合、絶対的なフレーム優先度とストリーム優先度から
相対的なフレーム優先度を逆算することが可能である。
例えば、伝送するパケットの絶対的な優先度（Ａｃｃｅ
ｓｓＵｎｉｔＰｒｉｏｒｉｔｙ）を、Ａｃｃｅｓｓ
ＵｎｉｔＰｒｉｏｒｉｔｙ＝ストリーム優先度−フ
レーム優先度、という関係式から求めても良い。ここ
で、フレーム優先度は、ストリーム優先度を減算するこ
とから、劣後優先度と表現しても良い。

【０２５０】さらに、１つ以上のストリーム優先度をＴ
ＣＰ／ＩＰの論理チャンネル（ＬＡＮのポート番号）を
流れるデータの処理の優先度に対応付けて、データの処
理を管理してもよい。

【０２５１】加えて、画像や音声は、文字もしくは制御
情報よりも低いストリーム優先度やフレーム優先度を割
り当てることで再送処理の必要が低減できることが期待
できる。これは画像や音声は一部分が失われても、問題
が発生しない場合も多いからである。

【０２５２】図３７は、多重解像度の画像データへ優先
度の割り当て方法について説明する図である。

【０２５３】１つのストリームが２つ以上の複数のサブ
ストリームから構成される場合、サブストリームにスト
リーム優先度の付加を行い、蓄積時もしくは伝送時に論
理和もしくは論理積の記述を行うことでサブストリーム
の処理方法の定義を行うことが可能である。

【０２５４】ウェーブレットの場合、１つの映像フレー
ムを複数の異なる解像度の映像フレームに分解すること
が可能である。また、ＤＣＴベースの符号化方式でも高
周波の成分と低周波の成分に分割して符号化することで
異なる解像度の映像フレームへの分解は可能である。

【０２５５】分解された一連の映像フレームから構成さ
れる複数個の映像ストリームに付加されるストリーム優
先度のほかに、映像のストリーム間の関係を記述するた
めにＡＮＤ（論理積）とＯＲ（論理和）で関係を定義す
る。具体的な使用方法は、ストリームＡのストリーム優
先度が５であり、ストリームＢのストリーム優先度が１
０である場合（数字の少ない方が優先度が高い）、優先
度によりストリームデータの廃棄ならば、ストリームＢ
の方は廃棄されるが、ストリーム間の関係記述を行なう
ことで、ＡＮＤの場合にはストリームＢの優先度が閾値
の優先度よりも低くても、廃棄せずに伝送、処理するよ
うに定義しておく。

【０２５６】これにより、関連のあるストリームは廃棄
されずに処理できるようになる。ＯＲの場合には逆に、
廃棄可能であると定義する。これまでと同様に、廃棄処
理は送受信端末でも行なっても、中継端末で行なっても
よい。

【０２５７】なお、関係記述のための演算子として、お
なじビデオクリップを２４Ｋｂｐｓと４８Ｋｂｐｓの別
のストリームに符号化した場合、どちらかを再生すれば
良いという場合がある（関係記述として排他的論理和Ｅ
Ｘ−ＯＲ）。

【０２５８】前者の優先度を１０、後者を５としてある
場合、ユーザは優先度に基づいて後者を再生してもよい
し、優先度に従わずユーザは後者を選んでもよい。

【０２５９】図３８は通信ペイロードの構成方法につい
て説明する図である。

【０２６０】複数のサブストリームから構成される場
合、サブストリームに付加したストリーム優先度に応じ
て、たとえば優先度の高い順に、送信パケットを構成す
ることで送信パケットレベルでの廃棄が容易になる。ま
た、粒度を細かくして、フレーム優先度の高いオブジェ
クト同士の情報をひとつにまとめて通信パケットを構成
しても通信パケットレベルでの廃棄が容易になる。

【０２６１】なお、画像のスライス構造を通信パケット
に対応付けることでパケット落ちしたときの復帰が容易
である。つまり、動画像のスライス構造をパケットの構
造に対応付けることで、再同期のためのリシンクマーカ
ーが不要になる。スライス構造と通信パケットの構造が
一致していなければ、パケット落ちなどで情報が損失し
た場合、再同期ができるようにリシンクマーカー（復帰
する位置を知らせるための印）を付加する必要がある。

【０２６２】これにあわせて、優先度の高い通信パケッ
トには高いエラープロテクションをかけることが考えら
れる。なお、画像のスライス構造とはＧＯＢやＭＢとい
ったまとまった画像情報の単位をさす。

【０２６３】図３９はデータを通信ペイロードへ対応づ
ける方法について説明する図である。ストリームやオブ
ジェクトの通信パケットへの対応付けの方法を制御情報
もしくはデータとともに伝送することで、通信状況や用
途に応じて任意のデータフォーマットが生成できる。た
とえば、ＲＴＰ（ＲｅａｌｔｉｍｅＴｒａｎｓｆｅ
ｒＰｒｏｔｏｃｏｌ）では、扱う符号化毎にＲＴＰの
ペイロードが定義されている。現行のＲＴＰの形式は固
定である。Ｈ．２６３の場合、同図に示したように、Ｍ
ｏｄｅＡからＭｏｄｅＣの３つのデータ形式が定義さ
れている。Ｈ．２６３では、多重解像度の映像フォーマ
ットを対象とした通信ペイロードは定義されていない。

【０２６４】同図の例では、ＬａｙｅｒＮｏ．と前述
の関係記述（ＡＮＤ、ＯＲ）を、ＭｏｄｅＡのデー
タフォーマットに追加して定義している。

【０２６５】図４０は、フレーム優先度、ストリーム優
先度と通信パケット優先度との対応について説明する図
である。

【０２６６】又、同図は、伝送路で通信パケットに付加
される優先度を通信パケット優先度とし、ストリーム優
先度やフレーム優先度を、通信パケット優先度に対応さ
せる例である。

【０２６７】通常、ＩＰを利用した通信では、画像や音
声データに付加されたフレーム優先度やストリーム優先
度を下位のＩＰパケットの優先度にパケットに対応付け
てデータを伝送する必要がある。画像や音声データは分
割され、ＩＰのパケットに分割されて伝送されるため優
先度の対応付けが必要がある。図の例では、ストリーム
優先度は０から３までの値をとり、フレーム優先度は０
から５までの値をとるため、上位のデータでは０から１
５までの優先度を取りうる。

【０２６８】ＩＰｖ６では優先度（４ビット）のうち０
から７までは輻輳制御されたトラフィックのために予約
されている、優先度のうち８から１５までは実時間通信
トラフィックまたは輻輳制御されていないトラフィック
のために予約されている。優先度１５は最も優先度が高
く、優先度８が最も優先度が低い。これはＩＰのパケッ
トのレベルでの優先度になる。

【０２６９】ＩＰを使ったデータの伝送では上位の０か
ら１５までの優先度を下位のＩＰの優先度である８から
１５までの優先度に対応付ける必要がある。対応付けは
上位の優先度の一部をクリッピングする方式でもよい
し、評価関数をもうけて対応付けてもよい。上位のデー
タと下位のＩＰの優先度の対応付けは、中継ノード（ル
ータやゲートウェイなど）、送受信端末で管理を行う。

【０２７０】なお、伝送手段はＩＰだけに限定されるわ
けではなく、ＡＴＭやＭＰＥＧ２のＴＳ（トランスポー
ト・ストリーム）のように廃棄可能かそうでないかのフ
ラグをもった伝送パケットを対象としてもよい。

【０２７１】これまでに述べた、フレーム優先度とスト
リーム優先度は、伝送媒体やデータ記録媒体へ適用が可
能である。データ記録媒体としてフロッピーディスク、
光ディスクなどを用いて行うことができる。

【０２７２】また、記録媒体はこれに限らず、ＩＣカー
ド、ＲＯＭカセット等、プログラムを記録できるもので
あれば同様に実施することができる。さらに、データの
中継を行うルータやゲートウェイといった画像音声中継
装置を対象としてもよい。

【０２７３】加えて、ＳｔｒｅａｍＰｒｉｏｒｉｔｙ
（時系列データ間優先度）や、ＦｒａｍｅＰｒｉｏｒ
ｉｔｙ（時系列データ内優先度）の情報に基づいて再送
すべき時系列データを決定することで、優先的な再送処
理が可能となる。たとえば、優先度情報に基づいて受信
端末でデコードを行なっている場合、処理の対象外であ
るストリームやフレームの再送を防止することができ
る。

【０２７４】また、現在の処理対象となっている優先度
とは別に、再送回数と送信成功回数の関係から再送すべ
き優先度のストリームやフレームを決定してもよい。

【０２７５】一方、送信側の端末においても、Ｓｔｒｅ
ａｍＰｒｉｏｒｉｔｙ（時系列データ間優先度）やＦ
ｒａｍｅＰｒｉｏｒｉｔｙ（時系列データ内優先度）
の情報に基づいて送信すべき時系列データを決定するこ
とで、優先的な送信処理が可能となる。たとえば、平均
転送レートや、再送回数に基づいて送信すべきストリー
ムやフレームの優先度を決定することで、ネットワーク
が過負荷である際にも適応的な映像や音声の伝送が可能
になる。

【０２７６】なお、上記実施の形態は、２次元の画像合
成だけに限定したものではない。２次元の画像と３次元
の画像を組み合わせた表現形式でもよいし、広視野画像
（パノラマ画像）のように複数の画像を隣接するように
画像合成するような画像合成方法も含めてもよい。ま
た、本発明で対象としている通信形態は、有線の双方向
ＣＡＴＶやＢ−ＩＳＤＮだけではない。たとえば、セン
ター側端末から家庭側端末への映像や音声の伝送は電波
（例えば、ＶＨＦ帯、ＵＨＦ帯）、衛星放送で、家庭側
端末からセンター側端末への情報発信はアナログの電話
回線やＮ−ＩＳＤＮであってもよい（映像、音声、デー
タも必ずしも多重化されている必要はない）。また、Ｉ
ｒＤＡ、ＰＨＳ（パーソナル・ハンディー・ホン）や無
線ＬＡＮのような無線を利用した通信形態であってもよ
い。

【０２７７】さらに、対象とする端末は、携帯情報端末
のように携帯型の端末であっても、セットトップＢＯ
Ｘ、パーソナルコンピュータのように卓上型の端末であ
っても良い。

【０２７８】以上のように本発明によれば、複数のビデ
オストリームや複数のオーディオストリームの取り扱い
や、編集者の意図を反映させて、重要なシーンカットを
重点的にオーディオとともに同期再生をさせることが容
易となる。

【０２７９】以下に本発明の実施の形態を図面を参照し
ながら説明する。

【０２８０】尚、ここで述べる実施の形態は、主に、上
述した課題（Ｃ１）〜（Ｃ３）の何れかを解決するもの
である。

【０２８１】図４１は第1の実施の形態である送信装置
の構成を示すものである。２１０１は画像入力端子であ
って、一枚の画像サイズは例えば縦１４４画素、横１７
６画素である。２１０２は動画像符号化装置であって、
４つの構成要素１０２１，１０２２，１０２３，１０２
４から成る（ＲｅｃｏｍｍｅｎｄａｔｉｏｎＨ．２６１
参照）。

【０２８２】１０２１は入力された画像をマクロブロッ
ク（縦１６画素、横１６画素の正方形領域）に分割し、
このブロックの符号化を、イントラ／インタどちらで符
号化するかを決定する切替器、１０２２は前回の符号化
結果から計算できるローカルデコード画像をもとに動き
補償画像を作成し、これと入力画像との差分を計算し、
結果をマクロブロック単位に出力する動き補償手段であ
って、動き補償には、処理時間の長いハーフペル動き補
償と処理時間の短いフルペル動き補償がある。１０２３
はそれぞれのマクロブロックに対してＤＣＴ変換を施す
直交変換手段、１０２４はこのＤＣＴ変換結果及び他の
符号化情報に対してエントロピー符号化を施すための可
変長符号化手段である。

【０２８３】２１０３は計数手段であって、動画像符号
化装置２１０２の４つの構成要素の実行回数を計数し、
入力画像ごとに、結果を変換手段に出力する。この時、
動き補償手段１０２２からは、ハーフペルとフルペルの
２通りについてそれぞれの実行回数を計数する。

【０２８４】２１０４は変換手段であって、図４２に示
すようなデータ列を出力する。２１０５は送信手段であ
って、動画像符号化装置２１０２からの可変長符号と、
変換手段２１０４からのデータ列を多重化して、一本の
データ列とし、データ出力端子２１０９に出力するもの
である。

【０２８５】以上の構成により、受信装置に、必須処理
（切替器１０２１，直交変換手段１０２３，可変長符号
化手段１０２４）と非必須処理（動き補償手段１０２
２）の各実行回数を伝達することができる。

【０２８６】なお、この第１の実施の形態である送信装
置は、請求項６８に対応する。

【０２８７】次に、図４８は、第２の実施の形態である
送信方法のフローチャートである。

【０２８８】本実施の形態における動作が第１の実施の
形態と似ているので、対応する要素を付記しておく。８
０１にて、画像を入力し（画像入力端子２１０１）、８
０２にて画像をマクロブロックに分割する。以降、８０
７の条件分岐により、すべてのマクロブロックに対する
処理を完了するまで、８０３から８０６までの処理を繰
りかえす。なお、８０３から８０６までの処理の回数
を、特定の変数に記録できるように、それぞれの処理を
実行した場合には、対応する変数を１だけインクリメン
トする。

【０２８９】まず、８０３にて、処理対象のマクロブロ
ックをイントラ／インタどちらで符号化するかを判定す
る（切替器１０２１）。インタの場合は、８０４にて動
き補償を行う（動き補償手段１０２２）。その後、８０
５，８０６にて、ＤＣＴ変換、可変長符号化を、行う
（直交変換手段１０２３，可変長符号化手段１０２
４）。すべてのマクロブロックに対する処理を完了した
ら（８０７にてＹｅｓの時）、８０８にて、それぞれの
処理に対応する実行回数を示す変数を読み、図２に示す
ようなデータ列を生成し、このデータ列と符号とを多重
化し、出力する。以上の８０１から８０８までの処理
を、入力画像が続くかぎり、繰り返し実行する。

【０２９０】以上の構成により、各処理の実行回数を送
信することができる。

【０２９１】なお、この第２の実施の形態である送信方
法は、請求項６７に対応する。

【０２９２】次に、図４３は第３の実施の形態である受
信装置の構成を示すものである。

【０２９３】同図において、３０７は第１の実施の形態
の送信装置の出力を入力するための入力端子、３０１は
第１の実施の形態の送信装置の出力をもとに可変長符号
とデータ列を逆多重化により取り出し出力する受信手段
であって、この時、一枚分のデータを受信するのに要し
た時間を計測しておき、これも出力するものとする。

【０２９４】３０３は可変長符号を入力とする動画像の
復号化装置であって、５つの構成要素から成る。３０３
１は可変長符号からＤＣＴ係数及び他の符号化情報を取
り出すための可変長復号化手段、３０３２はＤＣＴ係数
に対して逆ＤＣＴ変換処理を施す逆直交変換手段、３０
３３は切替器であって、マクロブロックごとに、イント
ラ／インタどちらで符号化されているかの符号化情報に
基づき、出力を上下に振りわける動作をする。３０３４
は動き補償手段であって、前回の復号画像と動きの符号
化情報とを用い、動き補償画像を作成し、この画像に逆
直交変換手段３０３２の出力を加算して出力する。３０
３５は実行時間計測手段であって、復号化装置３０３に
可変長符号が入力されてから画像の復号化及び出力を完
了するまでの実行時間を計測し、これを出力する。３０
２は、受信手段３０１からのデータ列から各要素（可変
長復号化手段３０３１，逆直交変換手段３０３２，切替
器３０３３，動き補償手段３０３４）の実行回数と、実
行時間計測手段３０３５から実行時間とを受け取り、各
要素の実行時間を推定する推定手段である。

【０２９５】推定方法は、例えば、線型回帰を用いれ
ば、推定実行時間を目的変数ｙ、各要素の実行回数を説
明変数ｘ_ｉとすれば良い。この場合、回帰パラメタａ
＿ｉは、各要素の実行時間とみなせるであろう。また、
線型回帰の場合、過去のデータを充分多く蓄積しておく
必要があり、メモリを沢山消費することになるが、これ
を嫌う場合には、カルマンフィルタによる内部状態変数
の推定を利用しても良い。この場合、観測値が実行時
間、各要素の実行時間を内部状態変数とし、観測行列Ｃ
が各要素の実行回数でステップごとに変化する場合、と
考えれば良い。３０４は、フルペル動き補償の実行回数
を減らし、相当数だけハーフペル動き補償の実行回数を
増やすように、各要素の実行回数を変更する回数削減手
段である。この相当数の計算方法は、以下の通りであ
る。

【０２９６】まず、推定手段３０２から各要素の実行回
数と推定実行時間とを受けとり、実行時間を予想する。
この時間が、受信手段３０１からのデータを受信するの
に要した時間を越える場合に、越えなくなるまで、フル
ペル動き補償の実行回数を増やし、ハーフペル動き補償
の実行回数を減らす。３０６は復号化画像の出力端子で
ある。

【０２９７】なお、動き補償手段３０３４は、符号化情
報からハーフペル動き補償を行うよう指示されている場
合であるが、ハーフペル動き補償の所定実行回数を越え
てしまった場合には、ハーフペルの動きを丸めて、フル
ペルの動きとして、フルペル動き補償を実行する。

【０２９８】以上にて説明した第１の実施の形態、第３
の実施の形態によれば、推定された各要素の実行時間か
ら復号化処理の実行時間を予測し、これが一枚分のデー
タを受信するのに要した時間（指定時間）を越えるよう
であれば、実行時間の長いハーフペルの動き補償を、フ
ルペルの動き補償で置き替える。これによって、実行時
間が指定時間を越えないようにでき、課題（Ｃ１）を解
決することができる（請求項６８，請求項７４に対
応）。

【０２９９】また、必須、非必須処理の部分を、２つの
グループと見なしたものが請求項６６，請求項７２に、
動画の部分を波形データと見なした場合が、請求項６
４，請求項７０に、それぞれ対応する。

【０３００】なお、受信装置でのＩＤＣＴ計算におい
て、高周波成分を使用しないようにすることで、ＩＤＣ
Ｔ計算の処理時間を減らすことができる。つまり、ＩＤ
ＣＴ計算のうち、低周波成分の計算を必須処理、高周波
成分の計算を非必須処理とみなして、ＩＤＣＴ計算の高
周波成分の計算回数を削減するようにしても良い。次
に、図４９は、第４の実施の形態である受信方法のフロ
ーチャートである。

【０３０１】本実施の形態における動作が第３の実施の
形態と似ているので、対応する要素を付記しておく。ス
テップ９０１にて各要素の実行時間を表現する変数ａ_
ｉを初期化する（推定手段３０２）。９０２にて多重化
データの入力と、これに要する時間の計測を行う（受信
手段３０１）。９０３にてこの多重化データを、可変長
符号とデータ列とに分離し、出力する（受信手段３０
１）。９０４にてデータ列（図２）から各実行回数を取
り出し、これらをｘ_ｉに設定する。９０５にて、各要
素の実行時間ａ_ｉと各実行回数ｘ_ｉとから、実際の実
行回数を算出する（回数削減手段３０４）。９０６に
て、復号化処理の実行時間の計測を開始し、９０７にて
後述する復号化処理ルーチンを起動し、その後、９０８
にて復号化処理の実行時間の計測を終了する（動画像の
復号化装置３０３，実行時間計測手段３０３５）。９０
８では、９０８での復号化処理の実行時間と９０５での
各要素の実際の実行回数とから各要素の実行時間を推定
し、ａ_ｉを更新する（推定手段３０２）。以上の処理
を入力される多重化データごとに実行する。

【０３０２】また、復号化処理ルーチン９０７では、９
１０にて可変長復号化を行い（可変長復号化手段３０３
１）、９１１にて逆直交変換を行い（逆直交変換手段３
０３２）、９１２にて、９１０での処理で取り出された
イントラ／インタの情報で分岐する（切替器３０３
３）。インタの場合は、９１３にて動き補償を施す（動
き補償手段３０３４）。この９１３にて、ハーフペル動
き補償の実行回数を計数しておき、これが９０５で求め
た実際の実行回数を越えた場合には、ハーフペル動き補
償をフルペル動き補償で置き替えて実行する。以上の処
理を、すべてのマクロブロックについて完了後（ステッ
プ９１４）、このルーチンを終了する。

【０３０３】以上にて説明した第２の実施の形態、第４
の実施の形態によれば、推定された各要素の実行時間か
ら復号化処理の実行時間を予測し、これが一枚分のデー
タを受信するのに要した時間（指定時間）を越えるよう
であれば、実行時間の長いハーフペルの動き補償を、フ
ルペルの動き補償で置き替える。これによって、実行時
間が指定時間を越えないようにでき、課題（Ｃ１）を解
決することができる（請求項６７，請求項７３に対
応）。

【０３０４】また、必須、非必須処理の部分を、２つの
グループと見なしたものが請求項６５，請求項７１に、
動画の部分を波形データと見なした場合が、請求項６
３，請求項６９に、それぞれ対応する。

【０３０５】次に、図４４は第５の実施の形態である受
信装置の構成を示すものである。

【０３０６】本実施の形態のほとんどの構成要素は、第
２の実施の形態で説明したのと同じであり、２つの構成
要素の追加と、１つの構成要素の修正のみであるのでそ
の点を説明する。

【０３０７】４０２は第２の実施の形態で説明した推定
手段３０２に推定の結果得た各要素の実行時間を、回数
制限手段３０４への出力とは別に、出力するよう修正し
たものである。４０８は送信手段であって、各要素の実
行時間から図４５に示すようなデータ列を生成し、これ
を出力するものである。実行時間は、マイクロセコンド
を単位として、１６ｂｉｔで表現すれば最大で、約６５
ミリセコンドを表現できるので、充分であろう。４０９
はこのデータ列を送信手段に送るための出力端子であ
る。

【０３０８】また、この第５の実施の形態に対応する受
信方法は、図４５に示すようなデータ列を生成するステ
ップを図４８の８０８の直後に追加したもので良い。

【０３０９】次に、図４６は第６の実施の形態である送
信装置の構成を示すものである。

【０３１０】本実施の形態のほとんどの構成要素は、第
１の実施の形態で説明したのと同じであり、２つの構成
要素の追加のみであるのでその点を説明する。６０６は
第３の実施の形態の受信装置の出力するデータ列を受信
するための入力端子、６０７はこのデータ列を受信し、
各要素の実行時間を出力する受信手段である。６０８
は、各要素の実行回数を求める決定手段であって、その
手順は以下の通りである。まず、画像中のすべてのマク
ロブロックについて、切替器１０２１での処理を行い、
この時点での切替器１０２１の実行回数を求める。ま
た、このあとの、動き補償手段１０２２、直交変換手段
１０２３，可変長符号化手段１０２４での実行回数は、
この時点までの処理結果によって、一意に決定できる。
そこで、これら実行回数と、受信手段６０７からの実行
時間を用いて、受信装置側での復号化に要する実行時間
を予測する。この予測復号化時間は、各要素の実行時間
と実行回数の積の、要素ごとの総和として、求まる。そ
して、予測復号化時間が、レートコントローラなどが指
定した今回の画像で発生すべき符号量（例えば１６ｋｂ
ｉｔｓ）の伝送に要する時間（例えば、伝送速度が６４
ｋｂｉｔ／ｓｅｃなら２５０ｍｓｅｃ）以上であれば、
復号化時間が伝送に要する時間を越えないように、フル
ペル動き補償の実行回数を増やし、ハーフペル動き補償
の実行回数を減らす。（フルペル動き補償のほうが、実
行時間が短いので、これの回数を減らすことで実行時間
を小さくすることができる。）なお、動画像の符号化装置２１０２は、決定手段６０８
の指定した実行回数に基づき、各処理を行う。例えば、
動き補償手１０２２は、指定されたハーフペルの動き補
償実行回数分だけ、ハーフペル動き補償を実行完了すれ
ば、その後は、フルペルの動き補償だけを実行するよう
になる。

【０３１１】また、ハーフペルの動き補償が、画像中に
一様にちらばるように、選択方法を工夫しても良い。た
とえば、まず、ハーフペルの動き補償を必要とするマク
ロブロックをすべて求め、この数（例えば１２）をハー
フペルの動き補償実行回数（例えば４）で割った商
（３）を求め、ハーフペルの動き補償を必要とするマク
ロブロックの始めからの順序が、この商で割りきれるも
の（０，３，６，９）だけにハーフペルの動き補償を施
す、という方法でも良い。

【０３１２】以上にて説明した第５の実施の形態、第６
の実施の形態によれば、推定された各要素の実行時間を
送信側に伝送し、送信側にて復号化処理の実行時間を予
測し、これが一枚分のデータを受信するのに要するであ
ろう時間（指定時間）を越えないように実行時間の長い
ハーフペルの動き補償を、フルペルの動き補償で置き替
える。これによって、送られた符号化情報のうち、ハー
フペル動き補償の情報が捨てられることなく、実行時間
が指定時間を越えないようにでき、課題（Ｃ２）を解決
することができる（請求項７６，請求項７８に対応）。

【０３１３】なお、非必須処理において、インターマク
ロブロック符号化を普通の動き補償、８ｘ８動き補償、
オーバラップ動き補償の３つに分割しても良い。

【０３１４】次に、図５０は、第７の実施の形態である
送信方法のフローチャートである。

【０３１５】本実施の形態における動作が第６の実施の
形態と似ているので、対応する要素を付記しておく。１
００１にて、各処理の実行時間の初期値を設定する。８
０１にて画像を入力し（入力端子２１０１）、にて画像
をマクロブロックに分割する。１００２にて、すべての
マクロブロックについて、イントラ／インタどちらで符
号化するかを判定する（切替器１０２１）。この結果、
１００５から８０６までの各処理の実行回数がわかるの
で、１００３では、この実行回数と、各処理の実行時間
とから、実際の実行回数を算出する（決定手段６０
８）。

【０３１６】以降、８０７の条件分岐により、すべての
マクロブロックに対する処理を完了するまで、１００５
から８０６までの処理を繰りかえす。

【０３１７】なお、１００５から８０６までの処理の回
数を、特定の変数に記録できるように、それぞれの処理
を実行した場合には、対応する変数を１だけインクリメ
ントする。まず、１００５にて、１００２での判定結果
に基き、分岐する（切替器１０２１）。インタの場合
は、８０４にて動き補償を行う（動き補償手段１０２
２）。ここで、ハーフペル動き補償の回数を計数してお
き、これが１００３で求めた実際の実行回数を越えた場
合には、ハーフペル動き補償を実行せずかわりにフルペ
ル動き補償を実行する。その後、８０５，８０６にて、
ＤＣＴ変換、可変長符号化を、行う（直交変換手段１０
２３，可変長符号化手段１０２４）。すべてのマクロブ
ロックに対する処理を完了したら（８０７にてＹｅｓの
時）、８０８にて、それぞれの処理に対応する実行回数
を示す変数を読み、図２に示すようなデータ列を生成
し、このデータ列と符号とを多重化し、出力する。１０
０４では、データ列を受信し、これから各処理の実行時
間を取り出し、設定する。

【０３１８】以上の８０１から１００４までの処理を、
入力画像が続くかぎり、繰り返し実行する。

【０３１９】以上にて説明した、第５の実施の形態の説
明部分の最後の「また」で始まるパラグラフと、第７の
実施の形態とによれば、推定された各要素の実行時間を
送信側に伝送し、送信側にて復号化処理の実行時間を予
測し、これが一枚分のデータを受信するのに要するであ
ろう時間（指定時間）を越えないように実行時間の長い
ハーフペルの動き補償を、フルペルの動き補償で置き替
える。これによって、送られた符号化情報のうち、ハー
フペル動き補償の情報が捨てられることなく、実行時間
が指定時間を越えないようにでき、課題（Ｃ２）を解決
することができる（請求項７５，請求項７７に対応）。

【０３２０】次に、図４７は第８の実施の形態である送
信装置の構成を示すものである。

【０３２１】本実施の形態のほとんどの構成要素は、第
１の実施の形態で説明したのと同じであり、４つの構成
要素の追加のみであるのでその点を説明する。

【０３２２】７０１０は実行時間計測手段であって、符
号化装置２１０２に画像が入力されてから画像の符号化
及び符号の出力を完了するまでの実行時間を計測し、こ
れを出力する。７０６は、計数手段２１０３からのデー
タ列からの各要素（切替器１０２１、動き補償手段１０
２２、直交変換手段１０２３，可変長復号化手段１０２
４）の実行回数と、実行時間計測手段７０１０からの実
行時間とを受け取り、各要素の実行時間を推定する推定
手段である。推定方法は、第２の実施の形態の推定手段
３０２で説明したものと同じで良い。７０７はユーザか
らのフレームレート値を入力するための入力端子、７０
８は、各要素の実行回数を求める決定手段であって、そ
の手順は以下の通りである。

【０３２３】まず、画像中のすべてのマクロブロックに
ついて、切替器１０２１での処理を行い、この時点での
切替器１０２１の実行回数を求める。また、このあと
の、動き補償手段１０２２、直交変換手段１０２３，可
変長符号化手段１０２４での実行回数は、この時点まで
の処理結果によって、一意に決定できる。つぎに、この
実行回数と推定手段７０６からの各要素の推定実行時間
との積の、要素ごとの総和を求め予測符号化時間を算出
する。そして、予測符号化時間が、７０７からのフレー
ムレートの逆数から求まる一枚の画像の符号化に使用可
能な時間以上であれば、フルペル動き補償の実行回数を
増やし、ハーフペル動き補償の実行回数を減らす。

【０３２４】この増減処理と予測符号化時間の算出と
を、予測符号化時間が使用可能な時間以下になるまで、
繰り返すことで、それぞれの実行回数を決定する。

【０３２５】なお、動画像の符号化装置２１０２は、決
定手段６０８の指定した実行回数に基づき、各処理を行
う。例えば、動き補償手１０２２は、指定されたハーフ
ペルの動き補償実行回数分だけ、ハーフペル動き補償を
実行完了すれば、その後は、フルペルの動き補償だけを
実行するようになる。

【０３２６】また、ハーフペルの動き補償が、画像中に
一様にちらばるように、選択方法を工夫しても良い。た
とえば、まず、ハーフペルの動き補償を必要とするマク
ロブロックをすべて求め、この数（例えば１２）をハー
フペルの動き補償実行回数（例えば４）で割った商
（３）を求め、ハーフペルの動き補償を必要とするマク
ロブロックの始めからの順序が、この商で割りきれるも
の（０，３，６，９）だけにハーフペルの動き補償を施
す、という方法でも良い。

【０３２７】以上示した第８の実施の形態によれば、各
処理の実行時間を推定し、この推定実行時間に基き、符
号化に要する実行時間を予め予測し、この予測符号化時
間が、フレームレートから決まる画像の符号化に使用可
能な時間以下になるように、実行回数を決定することに
より、課題（Ｃ３）を解決することができる（請求項８
０に対応）。

【０３２８】なお、動き補償手段１０２２では、動きベ
クトルを検出するために、左右上下１５画素の範囲のベ
クトルのうち、もっともＳＡＤ（画素ごとに差の絶対値
の和）を小さくするものを検出するフルサーチ動きベク
トル検出方法存在するが、これ以外に、３ｓｔｅｐ動き
ベクトル検出方法というものもある（Ｈ．２６１のａｎ
ｎｅｘ．に記述がある）。これは、上記の探索範囲にて
均等な配置関係の９点を選び、これのＳＡＤ最小の点を
選ぶ。次に、この点の近傍のせばめた範囲にて、再度、
９点を選び、ＳＡＤ最小の点を選ぶ。このような処理を
もう一度実行するのが、３ｓｔｅｐ動きベクトル検出方
法である。

【０３２９】これら２つの方法を、非必須処理方法とみ
なし、実行時間をそれぞれ推定し、推定実行時間にもと
づき、符号化に要する実行時間を予測し、この予測実行
時間がユーザ指定時間以下になるように、適宜、フルサ
ーチ動きベクトル検出方法の実行回数を減らし、かわり
に３ｓｔｅｐ動きベクトル検出方法の実行回数を増やす
ようにしても良い。

【０３３０】さらに、３ｓｔｅｐ動きベクトル検出方法
以外に、もっと処理を簡略化した固定探索回数による動
きベクトル検出方法や、（０，０）動きベクトルのみを
結果として返す動きベクトル検出方法を併用しても良
い。

【０３３１】次に、図５１は、第９の実施の形態である
送信方法のフローチャートである。

【０３３２】本実施の形態における動作が第８の実施の
形態と似ているので、対応する要素を付記しておく。各
フローでの詳しい動作は、対応する要素の説明を参照の
こと。また、第２の実施の形態とほぼ同じであるので、
異なる点のみを説明する。

【０３３３】１１０１にて各処理の実行時間の初期値を
変数a_iに設定する。また、１１０２にてフレームレー
トを入力する（入力端子７０７）。ｌ１０３は、１１０
２でのフレームレート、各処理の実行時間a_i、１００
２でのイントラ／インタ判定結果から求まる各処理の実
行回数、とから実際の実行回数を決定する（決定手段７
０８）。１１０５，１１０６は、符号化処理の実行時間
を計測するためのものである。１１０４は、１１０６で
の実行時間と各処理の実際の実行回数とから各処理の実
行時間を推定し、変数a_iを更新する（推定手段７０
６）。

【０３３４】以上示した第９の実施の形態によれば、各
処理の実行時間を推定し、この推定実行時間に基き、符
号化に要する実行時間を予め予測し、この予測符号化時
間が、フレームレートから決まる画像の符号化に使用可
能な時間以下になるように、実行回数を決定することに
より、課題（Ｃ３）を解決することができる（請求項７
９に対応）。

【０３３５】なお、第２の実施の形態において、８０８
でのデータ列生成時に、図２に示すスタートコードの直
後に、２バイトの領域を追加し、ここに、符号の長さの
二進表現を追加しても良い。

【０３３６】さらに、第４の実施の形態において、９０
２での多重化データの入力時にこの２バイトの領域から
符号の長さを抽出し、この符号長さと、符号の伝送速度
とから求まる符号の伝送時間を、９０５での実行回数計
算に用いるようにしても良い（符号の伝送時間を越えな
いように、ハーフペル動き補償の実行回数を減らす）。
これは、請求項８１，請求項８３に対応する。

【０３３７】なお、第１の実施の形態において、２１０
４でのデータ列生成時に、図２に示すスタートコードの
直後に、２バイトの領域を追加し、ここに、符号の長さ
の二進表現を追加しても良い。

【０３３８】さらに、第３の実施の形態において、３０
１での多重化データの入力時にこの２バイトの領域から
符号の長さを抽出し、この符号長さと、符号の伝送速度
とから求まる符号の伝送時間を、３０４での実行回数計
算に用いるようにしても良い（符号の伝送時間を越えな
いように、ハーフペル動き補償の実行回数を減らす）。
これは、請求項８２，請求項８４に対応する。

【０３３９】また、第４の実施の形態において、９０９
直後に、ハーフペル動き補償の実際の実行回数を記録
し、これの最大値を算出する。そして、この最大値が充
分小さな値（例えば、２とか３）以下の場合には、ハー
フペル動き補償を使用しないことを示すデータ列（特定
のビットパターンから成るデータ列）を生成し、これを
送信しても良い。さらに、第２の実施の形態において、
８０８直後にて、このデータ列の受信有無を確認し、ハ
ーフペル動き補償を使用しないことを示すデータ列を受
信した場合には、８０８にて動き補償の処理を常にフル
ペル動き補償とするようにしても良い。これは、請求項
９３、請求項９１に対応する。

【０３４０】さらに、動き補償以外にも、この考えを適
用できる。たとえば、ＤＣＴ計算で、高周波成分を使用
しないようにすることで、ＤＣＴ計算の処理時間を減ら
すことができる。つまり、受信方法にて、ＩＤＣＴ計算
の実行時間の全体の実行時間に占める割合が一定値を越
える場合には、その旨を示すデータ列を送信側に伝送す
る。送信側では、このデータ列を受信した場合には、Ｄ
ＣＴ計算において低周波成分のみを計算し、高周波成分
はすべて０にしても良い。これは、請求項８９に対応す
る。

【０３４１】さらに、ここでは、画像を用いて実施の形
態を説明したが、画像以外の音声などに、上記の各方法
を適用しても良い。これは、請求項８５，請求項８７に
対応する。

【０３４２】また、第３の実施の形態において、３０３
４にて、ハーフペル動き補償の実際の実行回数を記録
し、これの最大値を算出する。そして、この最大値が充
分小さな値（例えば、２とか３）以下の場合には、ハー
フペル動き補償を使用しないことを示すデータ列（特定
のビットパターンから成るデータ列）を生成し、これを
送信しても良い。さらに、第１の実施の形態において、
ハーフペル動き補償を使用しないことを示すデータ列を
受信した場合には、１０２２での動き補償の処理を常に
フルペル動き補償とするようにしても良い。これは、請
求項９４、請求項９２に対応する。

【０３４３】さらに、動き補償以外にも、この考えを適
用できる。たとえば、ＤＣＴ計算で、高周波成分を使用
しないようにすることで、ＤＣＴ計算の処理時間を減ら
すことができる。つまり、受信方法にて、ＩＤＣＴ計算
の実行時間の全体の実行時間に占める割合が一定値を越
える場合には、その旨を示すデータ列を送信側に伝送す
る。

【０３４４】送信側では、このデータ列を受信した場合
には、ＤＣＴ計算において低周波成分のみを計算し、高
周波成分はすべて０にしても良い。これは、請求項９０
に対応する。

【０３４５】さらに、ここでは、画像を用いて実施の形
態を説明したが、画像以外の音声などに、上記の方法を
適用しても良い。これは、請求項８６，請求項８８に対
応する。

【０３４６】以上説明したところから明らかなように、
請求項６８，請求項７４（例えば第１の実施の形態、第
３の実施の形態）によれば、推定された各要素の実行時
間から復号化処理の実行時間を予測し、これが一枚分の
データを受信するのに要した時間（指定時間）を越える
ようであれば、実行時間の長いハーフペルの動き補償
を、フルペルの動き補償で置き替える。これによって、
実行時間が指定時間を越えないようにでき、課題（Ｃ
１）を解決することができる。

【０３４７】また、請求項７５，請求項７７（例えば第
５の実施の形態、第７の実施の形態）によれば、推定さ
れた各要素の実行時間を送信側に伝送し、送信側にて復
号化処理の実行時間を予測し、これが一枚分のデータを
受信するのに要するであろう時間（指定時間）を越えな
いように実行時間の長いハーフペルの動き補償を、フル
ペルの動き補償で置き替える。これによって、送られた
符号化情報のうち、ハーフペル動き補償の情報が捨てら
れることなく、実行時間が指定時間を越えないようにで
き、課題（Ｃ２）を解決することができる。

【０３４８】また、請求項７９（例えば第９の実施の形
態）によれば、各処理の実行時間を推定し、この推定実
行時間に基き、符号化に要する実行時間を予め予測し、
この予測符号化時間が、フレームレートから決まる画像
の符号化に使用可能な時間以下になるように、実行回数
を決定することにより、課題（Ｃ３）を解決することが
できる。

【０３４９】このように、本発明により、計算負荷が増
大してもゆるやかに品質を落とす機能（ＣＧＤ：Comput
ational Graceful Degradation)を実現出来、実施に伴
う利益は非常に大である。

【０３５０】又、以上述べてきた実施の形態の何れか一
つに記載の各ステップ（又は、各手段）の全部又は一部
のステップ（又は、各手段の動作）をコンピュータに実
行させるためのプログラムを記録した磁気記録媒体や、
光記録媒体などの記録媒体を作成し、その記録媒体を用
いてコンピュータにより上記と同様の動作を行っても良
い。

【０３５１】

【発明の効果】以上説明したように、本発明によれば、
例えば、送信端末と受信端末で使用するデータ管理情
報、伝送管理情報、制御情報の各情報の枠組みを動的に
決定することで、状況に応じた情報の枠組みの変更が可
能になり、用途や伝送路に応じた変更ができる。

【０３５２】又、本発明によれば、例えば、複数のビデ
オストリームや複数のオーディオストリームの取り扱い
や、編集者の意図を反映させて、重要なシーンカットを
重点的にオーディオとともに同期再生をさせることが容
易となる。

【０３５３】又、本発明によれば、例えば、推定された
各要素の実行時間から復号化処理の実行時間を予測し、
これが一枚分のデータを受信するのに要した時間（指定
時間）を越えるようであれば、実行時間の長いハーフペ
ルの動き補償を、フルペルの動き補償で置き替えること
によって、実行時間が指定時間を越えないようにでき
る。

【図面の簡単な説明】

【図１】本発明の実施例における画像音声送受信装置の
概略構成図

【図２】受信管理部と分離部とを示す図

【図３】複数の論理的な伝送路を用いて画像や音声の伝
送、制御する方法を示す図

【図４】送信すべき画像や音声のデータに付加するヘッ
ダ情報の動的な変更方法を示す図

【図５】（ａ）〜（ｂ）：ＡＬ情報の付加方法を示す図

【図６】（ａ）〜（ｄ）：ＡＬ情報の付加方法の例を示
す図

【図７】複数の論理的な伝送路を動的に多重化、分離し
て情報の伝送を行う方法を示す図

【図８】放送番組の伝送手順を示す図

【図９】（ａ）：プログラム、データが受信端末にある
場合における、プログラムやデータの読み込み、立ち上
げ時間を考慮した画像や音声の伝送方法を示す図（ｂ）：プログラム、データが送信される場合におけ
る、プログラムやデータの読み込み、立ち上げ時間を考
慮した画像や音声の伝送方法を示す図

【図１０】（ａ）〜（ｂ）：ザッピングに対する対応方
法を示す図

【図１１】実際に端末間で送受信されるプロトコルの具
体例を示す図

【図１２】実際に端末間で送受信されるプロトコルの具
体例を示す図

【図１３】実際に端末間で送受信されるプロトコルの具
体例を示す図

【図１４】実際に端末間で送受信されるプロトコルの具
体例を示す図

【図１５】実際に端末間で送受信されるプロトコルの具
体例を示す図

【図１６】実際に端末間で送受信されるプロトコルの具
体例を示す図

【図１７】実際に端末間で送受信されるプロトコルの具
体例を示す図

【図１８】実際に端末間で送受信されるプロトコルの具
体例を示す図

【図１９】実際に端末間で送受信されるプロトコルの具
体例を示す図

【図２０】実際に端末間で送受信されるプロトコルの具
体例を示す図

【図２１】実際に端末間で送受信されるプロトコルの具
体例を示す図

【図２２】実際に端末間で送受信されるプロトコルの具
体例を示す図

【図２３】実際に端末間で送受信されるプロトコルの具
体例を示す図

【図２４】実際に端末間で送受信されるプロトコルの具
体例を示す図

【図２５】（ａ）〜（ｂ）：本発明のＣＧＤのデモシス
テム構成図

【図２６】本発明のＣＧＤのデモシステム構成図

【図２７】エンコーダでの過負荷時の優先度の付加方法
を示す図

【図２８】過負荷時の受信端末での優先度の決定方法に
ついて記した図

【図２９】優先度の時間変化を示す図

【図３０】ストリーム優先度とオブジェクト優先度を示
す図

【図３１】本発明の実施例における画像符号化、画像復
号化装置の概略構成図

【図３２】本発明の実施例における音声符号化、音声復
号化装置の概略構成図

【図３３】（ａ）〜（ｂ）：過負荷時の処理の優先度を
管理する優先度付加部、優先度決定部を示す図

【図３４】優先度を付加する粒度を示す図

【図３５】優先度を付加する粒度を示す図

【図３６】優先度を付加する粒度を示す図

【図３７】多重解像度の画像データへ優先度の割り当て
方法を示す図

【図３８】通信ペイロードの構成方法を示す図

【図３９】データを通信ペイロードへ対応づける方法を
示す図

【図４０】オブジェクト優先度、ストリーム優先度と通
信パケット優先度との対応を示す図

【図４１】本発明の第１の実施の形態における送信装置
の構成図

【図４２】第１の実施の形態の説明図

【図４３】本発明の第３の実施の形態における受信装置
の構成図

【図４４】本発明の第５の実施の形態における受信装置
の構成図

【図４５】第５の実施の形態の説明図

【図４６】本発明の第６の実施の形態における送信装置
の構成図

【図４７】本発明の第８の実施の形態における送信装置
の構成図

【図４８】本発明の第２の実施の形態における送信方法
のフローチャート

【図４９】本発明の第４の実施の形態における受信方法
のフローチャート

【図５０】本発明の第７の実施の形態における送信方法
のフローチャート

【図５１】本発明の第９の実施の形態における送信方法
のフローチャート

【図５２】本発明の画像・音声送信装置の一例を示す構
成図

【図５３】本発明の画像・音声受信装置の一例を示す構
成図

【図５４】本発明の画像・音声送信装置の映像と音声に
優先度を付加する優先度付加手段について説明する図

【図５５】本発明の画像・音声受信装置の映像と音声に
付加された優先度を解釈し、復号処理の可否を決定する
優先度決定手段について説明する図

【符号の説明】

１１受信管理部１２分離部１３伝送部１４画像伸長部１５画像伸長管理部１６画像合成部１７出力部１８端末制御部３０１受信手段３０２推定手段３０３動画像の復号化装置３０４回数削減手段３０６出力端子３０７入力端子３０３１可変長復号化手段３０３２逆直交変換手段３０３３切替器３０３４動き補償手段３０３５実行時間計測手段４０１１送信管理部４０１２画像符号部４０１３受信管理部４０１４画像復号部４０１５画像合成部４０１６出力部４１０１画像符号化装置４１０２画像復号化装置

───────────────────────────────────────────────────── フロントページの続き (31)優先権主張番号特願平9−226027 (32)優先日平９(1997)８月22日 (33)優先権主張国日本（ＪＰ） (31)優先権主張番号特願平9−226045 (32)優先日平９(1997)８月22日 (33)優先権主張国日本（ＪＰ） (31)優先権主張番号特願平9−332101 (32)優先日平９(1997)12月２日 (33)優先権主張国日本（ＪＰ） (54)【発明の名称】画像・音声送信装置、画像・音声受信装置、データ処理装置、及びデータ処理方法、並びに、波形データの送信方法、装置、及び波形データの受信方法、装置、並びに、動画像の送信方法、装置、及び動画像の受信方法、装置

Claims

【特許請求の範囲】

【請求項１】伝送方法に関する及び／又は伝送するデ
ータの構造に関する内容、又はその内容を示す識別子
を、伝送フォーマット情報として、前記伝送するデータ
の伝送路と同一の伝送路、又は、前記伝送路とは別の伝
送路を用いて伝送する伝送手段を備え、前記伝送されるデータは、画像データ及び／又は音声デ
ータであることを特徴とする画像・音声送信装置。
【請求項２】前記伝送フォーマット情報が、前記デー
タを管理するために前記データに付加されるデータ管理
情報と、前記データを伝送するためにデータに付加され
る伝送管理情報と、端末側の処理を制御するための情報
の内、少なくとも一つの情報に含まれていることを特徴
とする請求項１記載の画像・音声送信装置。
【請求項３】前記データ管理情報、前記伝送管理情
報、及び前記端末側の処理を制御するための情報の内、
少なくとも一つが動的に変更されることを特徴とする請
求項２記載の画像・音声送信装置。
【請求項４】前記データは、複数のパケットに分割さ
れており、前記データ管理情報、又は前記伝送管理情報は、それら
分割された複数のパケットの先頭のパケットの他に、途
中のパケットにも付加されていることを特徴とする請求
項３記載の画像・音声送信装置。
【請求項５】前記データに関する時間情報を、そのデ
ータの再生時刻を示す情報として利用するか否かを示す
識別子が、前記伝送フォーマット情報に含まれているこ
とを特徴とする請求項１記載の画像・音声送信装置。
【請求項６】前記伝送フォーマット情報は、前記デー
タの構造情報であり、伝送されてきた前記データの構造情報を受信した受信装
置により出力される受信可能である旨の信号が確認され
た後、前記伝送手段が、対応するデータを前記受信装置
に伝送することを特徴とする請求項１記載の画像・音声
送信装置。
【請求項７】前記伝送フォーマット情報は、（１）受
信装置において時間的に後の段階で使用されることにな
るプログラム又はデータを識別する識別子と、（２）前
記使用されることになる時点又は使用の有効期間を知る
ための情報として、フラグ、カウンタ、又はタイマーの
うち少なくとも１つとを含むものであることを特徴とす
る請求項１に記載の画像・音声送信装置。
【請求項８】前記使用されることになる時点は、伝送
管理情報として伝送の順序関係を識別するための送信シ
リアル番号を用いることにより伝送されるか、又は、デ
ータとは別のパケットで伝送される、端末側の処理を制
御するための情報として伝送されるものであることを特
徴とする請求項７記載の画像・音声送信装置。
【請求項９】前記伝送方法に関する及び／又は伝送す
るデータの構造に関する内容と、その識別子とを複数種
類格納する格納手段を備え、前記識別子が、前記データ管理情報、前記伝送管理情報
又は前記端末側の処理を制御するための情報の内、少な
くとも一つの情報の中に前記伝送フォーマット情報とし
て含まれていることを特徴とする請求項２又は３記載の
画像・音声送信装置。
【請求項１０】前記伝送方法に関する及び／又は伝送
するデータの構造に関する内容を複数種類格納する格納
手段を備え、前記内容が、前記データ管理情報、前記伝送管理情報又
は前記端末側の処理を制御するための情報の内、少なく
とも一つの情報の中に前記伝送フォーマット情報として
含まれていることを特徴とする請求項２又は３記載の画
像・音声送信装置。
【請求項１１】前記伝送方法に関する及び／又は伝送
するデータの構造に関する内容の変更を行うか否かを示
すデフォルト識別子が付加されていることを特徴とする
請求項１、２又は３に記載の画像・音声送信装置。
【請求項１２】伝送される情報の予め決められた固定
長の領域、若しくは前記予め決められた位置に前記識別
子、又は、前記デフォルト識別子が付加されることを特
徴とする請求項９、１０または１１記載の画像・音声送
信装置。
【請求項１３】請求項１〜１２の何れか一つに記載の
画像・音声送信装置から送信されてくる前記伝送フォー
マット情報を受信する受信手段と、前記受信した伝送フォーマット情報を解釈する伝送情報
解釈手段と、を備えたことを特徴とする画像・音声受信
装置。
【請求項１４】前記伝送方法に関する及び／又は伝送
するデータの構造に関する内容と、その識別子とを複数
種類格納する格納手段を備え、前記伝送フォーマット情報を解釈する際に、前記格納手
段に格納されている内容を利用することを特徴とする請
求項１３記載の画像・音声受信装置。
【請求項１５】データ及び／又は制御情報を伝送する
ための複数の論理的な伝送路の情報の多重化の開始・終
了を制御する情報多重化手段を備え、前記情報多重化手段により多重化された前記データ及び
／又は制御情報の他に、前記情報多重化手段による上記
多重化の開始・終了に関する制御内容を多重化制御情報
として送信するものであり、前記データは、画像データ及び／又は音声データである
ことを特徴とする画像・音声送信装置。
【請求項１６】前記多重化制御情報を、前記データ及
び／又は制御情報より前に多重化せずに配置し伝送する
か、又は、前記多重化制御情報を、前記データ及び／制
御情報が伝送される伝送路とは別の伝送路により伝送す
るかを、選択することが出来ることを特徴とする請求項
１５記載の画像・音声送信装置。
【請求項１７】請求項１５に記載の画像・音声送信装
置から送信されてくる前記多重化制御情報と、前記多重
化された前記データ及び／又は制御情報とを受信する受
信手段と、前記多重化制御情報に基づいて、前記多重化された前記
データ及び／又は制御情報を分離する分離手段と、を備
えたことを特徴とする画像・音声受信装置。
【請求項１８】番組を視聴するための主視聴手段と、前記主視聴手段により視聴されている前記番組以外の番
組の状況を周期的に検出する副視聴手段とを備え、前記主視聴手段により視聴される前記番組が他の番組に
切り替えられた際に必要となるプログラム及び／又はデ
ータをスムーズに処理できる様に前記検出を行うもので
あり、前記データは、画像データ及び／又は音声データである
ことを特徴とする画像・音声受信装置。
【請求項１９】前記データの処理の優先度を示す情報
のオフセット値を伝送することで、優先度の値を状況に
応じて変化させることができることを特徴とする請求項
１記載の画像・音声送信装置。
【請求項２０】過負荷状態の場合の処理の優先度に関
する情報が予め付加されている、符号化された情報を受
信する受信手段と、前記受信手段により受信される前記情報の内で処理すべ
きものか否かを選定する基準となる閾値を決定する優先
度決定手段とを備え、前記受信した情報を出力すべき時期と処理開始からの経
過時間とを、又は、前記受信した情報を復号すべき時期
と処理開始からの経過時間とを比較し、その比較結果に
基づいて、前記閾値を変化させるものであり、前記符号化の対象として、画像データ及び／又は音声デ
ータを含むことを特徴とする画像・音声受信装置。
【請求項２１】伝送途中で紛失されたために、前記受
信されなかった前記情報の再送が必要な場合、前記紛失
されたものの中で再送要求すべきものか否かを選定する
基準となる閾値を決定する再送要求優先度決定手段を備
え、前記決定される閾値が、前記優先度決定手段が管理する
優先度、再送回数、情報の損失率、フレーム内符号化さ
れたフレームの挿入間隔、及び優先度の粒度の内、少な
くとも一つに基づいて決定されるものであることを特徴
とする請求項２０記載の画像・音声受信装置。
【請求項２２】伝送途中で紛失されたために、前記受
信されなかった前記情報の再送要求があった場合、前記
紛失されたものの中で再送すべきものか否かを選定する
基準となる閾値を決定する再送優先度決定手段を備え、前記決定される閾値が、請求項２０記載の画像・音声受
信装置の前記優先度決定手段が管理する優先度、再送回
数、情報の損失率、フレーム内符号化されたフレームの
挿入間隔、及び優先度の粒度の内、少なくとも一つに基
づいて決定されるものであることを特徴とする画像・音
声送信装置。
【請求項２３】（１）画像または音声の情報の目標転
送レートを実際の転送レートの方が超える場合又は、
（２）転送処理開始からの経過時間と、符号化された前
記情報に付加されている、復号化されるべき若しくは出
力されるべき時期とを比較した結果、送信バッファへの
符号化された情報の書き込みが遅れていると判定した場
合、前記符号化された情報に付加されている優先度を用い
て、前記情報の送信を間引いて行うことを特徴とする画
像・音声送信装置。
【請求項２４】（１）音声または動画像の時系列デー
タと、（２）前記時系列データ間の処理の優先度を示す
時系列データ間優先度と、（３）前記時系列データを区
分し、区分されたデータ間の処理優先度を示す複数の時
系列データ内優先度とを含むデータ系列を入力とし、前記時系列データが複数同時に存在する場合は、前記時
系列データ間優先度と前記時系列データ内優先度とを併
用して処理を行うことを特徴とするデータ処理方法。
【請求項２５】（１）音声または動画像の時系列デー
タと、（２）前記時系列データ間の処理の優先度を示す
時系列データ間優先度と、（３）前記時系列データを区
分し、区分されたデータ間の処理優先度を示す複数の時
系列データ内優先度とを含むデータ系列を受け付ける受
付手段と、前記時系列データが複数同時に存在する場合は、前記時
系列データ間優先度と前記時系列データ内優先度とを併
用して処理を行うデータ処理手段と、を備えたことを特
徴とするデータ処理装置。
【請求項２６】（１）音声または動画像などの時系列
データと、（２）前記時系列データ間の処理の優先度を
示す時系列データ間優先度と、（３）前記時系列データ
を区分し、区分されたデータ間の処理優先度を示す複数
の時系列データ内優先度とを含むデータ系列を入力と
し、前記時系列データ間優先度により、前記各時系列データ
に対する処理能力を配分し、さらに前記各時系列データ
について、配分された処理能力内に収まるように、前記
時系列データ内優先度に基づいて、適応的に前記時系列
データ内の区分されたデータの処理品質を劣化させるこ
とを特徴とするデータ処理方法。
【請求項２７】（１）音声または動画像などの時系列
データと、（２）前記時系列データ間の処理の優先度を
示す時系列データ間優先度と、（３）前記時系列データ
を区分し、区分されたデータ間の処理優先度を示す複数
の時系列データ内優先度とを含むデータ系列を受け付け
る受付手段と、前記時系列データ間優先度により、前記各時系列データ
に対する処理能力を配分し、さらに前記各時系列データ
について、配分された処理能力内に収まるように、前記
時系列データ内優先度に基づいて、適応的に前記時系列
データ内の区分されたデータの処理品質を劣化させるデ
ータ処理手段と、を備えたことを特徴とするデータ処理
装置。
【請求項２８】動画像に対する時系列データ内優先度
が、動画像のフレーム単位で付加されており、前記フレ
ーム単位の動画像が複数個のパケットに分割される場
合、単独の情報としてアクセス可能な前記動画像のフレーム
の先頭部分を伝送するパケットのヘッダ部のみに前記時
系列データ内優先度を付加することを特徴とするデータ
処理方法。
【請求項２９】動画像に対する時系列データ内優先度
が、動画像のフレーム単位で付加されており、前記フレ
ーム単位の動画像が複数個のパケットに分割される場
合、単独の情報としてアクセス可能な前記動画像のフレーム
の先頭部分を伝送するパケットのヘッダ部のみに前記時
系列データ内優先度を付加することを特徴とするデータ
処理装置。
【請求項３０】前記時系列データ内優先度はパケット
のヘッダ内に記述し、優先度処理を行うことを特徴とす
る請求項２４、２６、又は２８のいずれかに記載のデー
タ処理方法。
【請求項３１】前記時系列データ内優先度はパケット
のヘッダ内に記述し、優先度処理を行うことを特徴とす
る請求項２５、２７、又は２９のいずれかに記載のデー
タ処理装置。
【請求項３２】前記時系列データ内優先度が表現でき
る値の範囲を可変にし、優先度処理を行うことを特徴と
する請求項２４、２６、又は２８のいずれかに記載のデ
ータ処理方法。
【請求項３３】前記時系列データ内優先度が表現でき
る値の範囲を可変にし、優先度処理を行うことを特徴と
する請求項２５、２７、又は２９のいずれかに記載のデ
ータ処理装置。
【請求項３４】音声または動画像などの時系列データ
と、前記時系列データ間の処理の優先度を示す時系列デ
ータ間優先度とを含むデータ系列を入力とし、前記時系列データ間優先度を相対的な優先度の値又は、
絶対的な優先度の値として優先処理を行うことを特徴と
するデータ処理方法。
【請求項３５】音声または動画像などの時系列データ
と、前記時系列データ間の処理の優先度を示す時系列デ
ータ間優先度とを含むデータ系列を入力とし、前記時系
列データ間優先度を相対的な優先度の値又は、絶対的な
優先度の値として優先処理を行うことを特徴とするデー
タ処理装置。
【請求項３６】音声または動画像などの時系列データ
を区分し、前記時系列データと、前記区分されたデータ間の処理優
先度を示す複数の時系列データ内優先度とを含むデータ
系列を入力とし、前記時系列データ内優先度を相対的な優先度の値又は、
絶対的な優先度の値として優先処理を行うことを特徴と
するデータ処理方法。
【請求項３７】音声または動画像などの時系列データ
を区分し、前記時系列データと、前記区分されたデータ間の処理優
先度を示す複数の時系列データ内優先度とを含むデータ
系列を入力とし、前記時系列データ内優先度を相対的な優先度の値又は、
絶対的な優先度の値として優先処理を行うことを特徴と
するデータ処理装置。
【請求項３８】音声または動画像などの時系列データ
を区分し、前記区分されたデータを符号化し、絶対的な優先度の値である時系列データ内優先度を、前
記符号化された情報内に記述した、且つ、相対的な優先
度の値である時系列データ内優先度を、前記符号化され
た情報から構成されるパケットのヘッダ部に記述したデ
ータ系列を入力とし、優先度処理を行うことを特徴とするデータ処理方法。
【請求項３９】音声または動画像などの時系列データ
を区分し、前記区分されたデータを符号化し、絶対的な優先度の値である時系列データ内優先度を、前
記符号化された情報内に記述した、且つ、相対的な優先
度の値である時系列データ内優先度を、前記符号化され
た情報から構成されるパケットのヘッダ部に記述したデ
ータ系列を入力とし、優先度処理を行うことを特徴とするデータ処理装置。
【請求項４０】音声または動画像などの時系列データ
と、時系列データ間の処理の優先度を示す時系列データ
間優先度とを含むデータ系列を入力とし、１つ以上の前記時系列データ間優先度をＴＣＰ／ＩＰの
論理チャンネルと対応付けて優先度処理を行うことを特
徴とするデータ処理方法。
【請求項４１】音声または動画像などの時系列データ
と、時系列データ間の処理の優先度を示す時系列データ
間優先度とを含むデータ系列を入力とし、１つ以上の前記時系列データ間優先度をＴＣＰ／ＩＰの
論理チャンネルと対応付けて優先度処理を行うことを特
徴とするデータ処理装置。
【請求項４２】（１）前記時系列データ間優先度を蓄
積して使用する際には相対的な優先度の値として、又、
（２）前記時系列データ間優先度を伝送する際には絶対
的な優先度の値として、前記優先度処理を行うことを特
徴とする請求項３４または３６記載のデータ処理方法。
【請求項４３】（１）前記時系列データ間優先度を蓄
積して使用する際には、その時系列データ間優先度を相
対的な優先度の値として表現し、又、（２）前記時系列
データ間優先度を伝送する際には、その時系列データ間
優先度を絶対的な優先度の値として表現し、前記優先度
処理を行うこと特徴とする請求項３５または３７記載の
データ処理装置。
【請求項４４】前記優先度の値を相対的な値として表
現するか、又は、絶対的な値として表現するかを識別子
により区別することを特徴とする請求項３４または３６
記載のデータ処理方法。
【請求項４５】前記優先度の値を相対的な値として表
現するか、又は、絶対的な値として表現するかを識別子
により区別することを特徴とする請求項３５または３７
記載のデータ処理装置。
【請求項４６】１つの時系列データが、複数のサブ時
系列データを含む場合、前記サブ時系列データ間の関係
記述を行うことにより、前記サブ時系列データの処理方
法の定義を行い、優先度処理を行うことを特徴とするデ
ータ処理方法。
【請求項４７】１つの時系列データが、複数のサブ時
系列データを含む場合、前記サブ時系列データ間の関係
記述を行うことにより、前記サブ時系列データの処理方
法の定義を行い、優先度処理を行うことを特徴とするデ
ータ処理装置。
【請求項４８】前記時系列データ間優先度、又は前記
時系列データ内優先度、又は前記時系列データ間の関係
記述の内、何れか一つに基づき、パケットの構成方法を
決定することを特徴とする請求項３４、３６、又は４６
の何れか一つに記載のデータ処理方法。
【請求項４９】前記時系列データ間優先度、又は前記
時系列データ内優先度、又は前記時系列データ間の関係
記述の内、何れか一つに基づき、パケットの構成方法を
決定することを特徴とする請求項３５、３７、又は４７
の何れか一つに記載のデータ処理装置。
【請求項５０】動画像のスライス構造をパケットの構
造に対応付けることで、再同期するためのリシンクマー
カーを不要にすることを特徴とするデータ処理方法。
【請求項５１】動画像のスライス構造をパケットの構
造に対応付けることで、再同期するためのリシンクマー
カーを不要にすることを特徴とするデータ処理装置。
【請求項５２】音声または動画像の時系列データをパ
ケットへ対応づける方法を、制御情報又は前記時系列デ
ータとともに伝送することにより、前記パケットへの前
記時系列データの前記対応付けを定義することを特徴と
するデータ処理装置。
【請求項５３】前記時系列データ内優先度又は、前記
時系列データ間優先度の高い情報を含むパケットに対し
ては、高いエラープロテクションを施すことを特徴とす
る請求項４８記載のデータ処理方法。
【請求項５４】前記時系列データ内優先度又は、前記
時系列データ間優先度の高い情報を含むパケットに対し
ては、高いエラープロテクションを施すことを特徴とす
る請求項４９記載のデータ処理装置。
【請求項５５】パケットに付加される優先度をパケッ
ト優先度とし、少なくとも前記時系列データ内優先度又は、前記時系列
データ間優先度のいずれかの値を前記パケット優先度に
対応させて、前記優先度処理を行うことを特徴とする請
求項３４または３６記載のデータ処理方法。
【請求項５６】パケットに付加される優先度をパケッ
ト優先度とし、少なくとも前記時系列データ内優先度又は、前記時系列
データ間優先度のいずれかの値を前記パケット優先度に
対応させて、前記優先度処理を行うことを特徴とする請
求項３５または３７記載のデータ処理装置。
【請求項５７】前記時系列データに対しては、前記時
系列データ内優先度又は前記時系列データ間優先度の値
として、文字又は制御情報よりも低い値を割り当てて、
前記優先度処理を行うことを特徴とする請求項３４また
は３６記載のデータ処理方法。
【請求項５８】前記時系列データに対しては、前記時
系列データ内優先度又は前記時系列データ間優先度の値
として、文字又は制御情報よりも低い値を割り当てて、
前記優先度処理を行うことを特徴とする請求項３５また
は３７記載のデータ処理装置。
【請求項５９】区分された時系列データと、その優先
度情報とを対にして逐次入力とし、（１）前記区分された時系列データの情報が損なわれた
場合は、その損なわれたデータの再送を要求するために
再送要求処理を行い、又、（２）前記区分された時系列
データが連続的に、又は高頻度で失われた場合は、優先
度の高いデータについてのみ前記再送要求処理を行うこ
とを特徴とするデータ処理方法。
【請求項６０】区分された時系列データと、その優先
度情報とを対にして逐次入力とし、（１）前記区分された時系列データの情報が損なわれた
場合は、その損なわれたデータの再送を要求するために
再送要求処理を行い、又、（２）前記区分された時系列
データが連続的に、又は高頻度で失われた場合は、優先
度の高いデータについてのみ前記再送要求処理を行うこ
とを特徴とするデータ処理装置。
【請求項６１】区分された時系列データと、その優先
度情報とを対にして逐次出力とし、前記区分された時系列データの伝送量に応じて、前記優
先度の高いデータを優先して伝送することを特徴とする
データ処理方法。
【請求項６２】区分された時系列データと、その優先
度情報とを対にして逐次出力とし、前記区分された時系列データの伝送量に応じて、前記優
先度の高いデータを優先して伝送することを特徴とする
データ処理装置。
【請求項６３】（ａ）波形データの復号化処理を構
成する複数の復号化処理単位を品質維持のための重要度
に応じて複数のグループに分け、各グループに属する復
号化処理単位に対応する符号化処理単位について実行回
数を計数し、（ｂ）所定期間の波形データの符号化完了時点で、前
記計数結果を受け取りデータ列に変換し、（ｃ）波形データの符号化結果である符号と前記デー
タ列とを出力し、受信装置に、複数のグループ毎に各処
理単位の各実行回数を伝達することを特徴とする波形デ
ータの送信方法。
【請求項６４】（ａ）波形データの復号化処理を構
成する複数の復号化処理単位を品質維持のための重要度
に応じて複数のグループに分け、各グループに属する
復号化処理単位に対応する符号化処理単位について実行
回数を計数する計数手段と、（ｂ）所定期間の波形データの符号化完了時点で、前
記計数手段の計数結果を受け取りデータ列に変換する変
換手段と、（ｃ）波形データの符号化結果である符号と前記デー
タ列とを出力する送信手段と、を備え、受信装置に、複
数のグループ毎に各処理単位の各実行回数を伝達するこ
とを特徴とする波形データの送信装置。
【請求項６５】波形データの復号化処理を構成する複
数の復号化処理単位を少なくとも一つ以上の必須処理と
少なくとも一つ以上の非必須処理（この処理を省いた場
合、波形劣化は生じるが波形の復号は可能な処理）に分
け、前記必須処理と前記非必須処理のそれぞれについ
て、その実行回数を計数し、前記受信装置に、前記必須
処理と前記非必須処理との各処理単位の各実行回数を伝
達することを特徴とする請求項６３記載の波形データの
送信方法。
【請求項６６】波形データの復号化処理を構成する複
数の復号化処理単位を少なくとも一つ以上の必須処理と
少なくとも一つ以上の非必須処理（この処理を省いた場
合、波形劣化は生じるが波形の復号は可能な処理）に分
け、前記必須処理と前記非必須処理のそれぞれについ
て、その実行回数を計数する計数手段を備え、前記受信
装置に、前記必須処理と前記非必須処理との各処理単位
の各実行回数が伝達されることを特徴とする請求項６４
記載の波形データの送信装置。
【請求項６７】前記波形データとして動画像を入力す
ることを特徴とする請求項６３記載の動画像の波形デー
タの送信方法。
【請求項６８】前記波形データとして動画像を入力す
ることを特徴とする請求項６４記載の動画像の波形デー
タの送信装置。
【請求項６９】（ａ）波形データの符号と前記符号
から復号化される波形データの品質維持のための重要度
に応じてグループ分けされた復号化処理の各処理単
位の実行回数とを含むデータ列を受信し、前記符号と前
記実行回数とを出力し、（ｂ）前記符号を復号化し波形を得るまでの処理時間
と前記データ列から得た前記各実行回数とを基に、各グ
ループごとの各実行時間を推定し、（ｃ）前記実行回数と前記実行時間を用いて波形の復
号化に要する処理時間を予測し、前記処理時間が、前記
符号の受信に要した時間または受信開始から次の符号の
受信開始までの時間（これを指定時間と呼ぶ）を越えな
い各グループの各実行回数の削減数を、前記受信手段
の出力する各実行回数と前記推定手段の出力する各実行
時間とから算出し、推定した各実行時間に基き、復号化
に要する時間を予測し、前記指定時間内に復号化処理を
終えるように各グループの各実行回数を減らすことを
特徴とする波形データの受信方法。
【請求項７０】（ａ）波形データの符号と前記符号
から復号化される波形データの品質維持のための重要度
に応じてグループ分けされた復号化処理の各処理単
位の実行回数とを含むデータ列を受信し、前記符号と
前記実行回数とを出力する受信手段と、（ｂ）前記符号を復号化し波形を得るまでの処理時間
と前記データ列から得た前記各実行回数とを基に、各グ
ループごとの各実行時間を推定する推定手段と、（ｃ）前記実行回数と前記実行時間を用いて波形の復
号化に要する処理時間を予測し、前記処理時間が、前記
符号の受信に要した時間または受信開始から次の符号の
受信開始までの時間（これを指定時間と呼ぶ）を越えな
いような各グループの各実行回数の削減数を、前記受信
手段の出力する各実行回数と前記推定手段の出力する各
実行時間とから算出する回数削減手段と、を備え、推定
した各実行時間に基き、復号化に要する時間を予測し、
前記指定時間内に復号化処理を終えるように各グルー
プの各実行回数を減らすことを特徴とする波形データの
受信装置。
【請求項７１】（ａ）波形データの符号と復号化の
必須処理と非必須処理の各実行回数とを含むデータ列を
受信し、前記符号と前記実行回数とを出力し、（ｂ）前記符号を復号化し波形を得るまでの処理時間
と前記データ列から得た前記各実行回数とを基に、前記
必須処理と前記非必須処理の各実行時間を推定し、（ｃ）前記実行回数と前記実行時間を用いて波形の復
号化に要する処理時間を予測し、前記処理時間が、前記
符号の受信に要した時間または受信開始から次の符号の
受信開始までの時間（これを指定時間と呼ぶ）を越えな
いような前記非必須処理の各実行回数の削減数を、前
記受信手段の出力する各実行回数と前記推定手段の出力
する各実行時間とから算出し、推定した各実行時間に基
き、復号化に要する時間を予測し、前記指定時間内に復
号化処理を終えるように前記非必須処理の実行回数を減
らすことを特徴とする波形データの受信方法。
【請求項７２】（ａ）波形データの符号と復号化の
必須処理と非必須処理の各実行回数とを含むデータ列を
受信し、前記符号と前記実行回数とを出力する受信手段
と、（ｂ）前記符号を復号化し波形を得るまでの処理時間
と前記データ列から得た前記各実行回数とを基に、前記
必須処理と前記非必須処理の各実行時間を推定する推定
手段と、（ｃ）前記実行回数と前記実行時間を用いて波形の復
号化に要する処理時間を予測し、前記処理時間が、前記
符号の受信に要した時間または受信開始から次の符号の
受信開始までの時間（これを指定時間と呼ぶ）を越えな
いような前記非必須処理の各実行回数の削減数を、前記
受信手段の出力する各実行回数と前記推定手段の出力す
る各実行時間とから算出する回数削減手段と、を備え、推定した各実行時間に基き、復号化に要する時間を予測
し、前記指定時間内に復号化処理を終えるように前記非
必須処理の実行回数を減らすことを特徴とする波形デー
タの受信装置。
【請求項７３】前記波形データとして動画像を出力す
ることを特徴とする請求項６９記載の動画像の波形デー
タの受信方法。
【請求項７４】前記波形データとして動画像を出力す
ることを特徴とする請求項７０の動画像の波形データの
受信装置。
【請求項７５】（ｄ）推定により求めた各グループの
各実行時間を出力する請求項６９記載の動画像の波形デ
ータの受信方法。
【請求項７６】（ｄ）推定手段の求めた各グループの
各実行時間を出力することを特徴とする請求項７０記載
の動画像の波形データの受信装置。
【請求項７７】（ｄ）各グループの各実行時間を含
むデータ列を入力し、（ｅ）レートコントローラなどの指示により決まる符
号長を伝送するのに必要な時間内に復号化を完了するた
めの各グループの各実行回数を、前記受信手段の各実
行時間により算出することを特徴とする請求項６３記載
の波形データの送信方法。
【請求項７８】（ｄ）各グループの各実行時間から
構成されるデータ列を入力とする受信手段と、（ｅ）レートコントローラなどの指示により決まる符
号を伝送するのに必要な時間内に復号化を完了するため
の各グループの各実行回数を、前記受信手段の各実行
時間により算出する決定手段と、を備えたことを特徴と
する請求項６４記載の波形データの送信装置。
【請求項７９】（ｄ）動画像の符号化に要する処理
時間と前記各実行回数とを基に、各グループの各実行時
間を推定し、（ｅ）前記実行時間を用い動画像符号化に要する処理
時間を予測し、前記処理時間が、ユーザの指示として与
えられるフレームレートにより決まる一枚の画像を処理
するのに利用可能な時間を越えない各グループの各実行
回数を算出することを特徴とする請求項６７記載の動画
像の波形データの送信方法。
【請求項８０】（ｄ）動画像の符号化に要する処理
時間と計数手段の出力する各実行回数とを基に、各グループの各実行時間を推定する推定手段と、（ｅ）前記実行時間を用い動画像符号化に要する処理
時間を予測し、前記処理時間が、ユーザの指示として与
えられるフレームレートにより決まる一枚の画像を処理
するのに利用可能な時間を越えない各グループの各実行
回数を算出する決定手段と、を備えたことを特徴とする
請求項６８記載の動画像の波形データの送信装置。
【請求項８１】所定期間の波形データに相当する符号
の生成完了時点で、前記計数結果と前記符号の長さとを
受け取りデータ列に変換することを特徴とする請求項６
３記載の動画像の波形データの送信方法。
【請求項８２】所定期間の波形データに相当する符号
の生成完了時点で、前記計数手段の計数結果と前記符号
の長さとを受け取りデータ列に変換する変換手段を備え
たことを特徴とする請求項６３記載の動画像の波形デー
タの送信装置。
【請求項８３】所定期間の波形データに相当する符号
と前記符号から復号化される波形データの品質維持のた
めの重要度に応じてグループ分けされた復号化処理
の各処理単位の実行回数と符号の長さとを含むデータ列
を受信し、前記符号、実行回数、符号の長さを出力し、
復号化に要する時間が、前記符号の長さと伝送速度から
求まる符号の伝送時間を越えないように非必須処理の実
行回数を減らすことを特徴とする請求項６９記載の波形
データの受信方法。
【請求項８４】所定期間の波形データに相当する符号
と前記符号から復号化される波形データの品質維持のた
めの重要度に応じてグループ分けされた復号化処理
の各処理単位の実行回数と符号の長さとを含むデータ列
を受信し、前記符号、実行回数、符号の長さを出力する
受信手段を備え、復号化に要する時間が、前記符号の長
さと伝送速度から求まる符号の伝送時間を越えないよ
うに非必須処理の実行回数を減らすことを特徴とする請
求項７０記載の波形データの受信装置。
【請求項８５】波形データの符号を受信し、波形を復
号化し、出力する波形データの受信方法において、（ａ）波形の復号化に要する処理時間が、前記符号の
受信に要した時間または受信開始から次の符号の受信開
始までの時間（これを指定時間と呼ぶ）を越えないよう
に、復号化処理を構成する処理単位に対応する符号化処
理単位ごとに、今回の符号に含まれている符号化処理単
位より実行時間の短い処理単位を選択する指示を含むデ
ータ列を構成し、（ｂ）前記データ列を送信し、前記指定時間内に復
号化処理を完了する符号を送信することを送信側に伝達
することを特徴とする波形データの受信方法。
【請求項８６】波形データの符号を受信し、波形を復
号化し、出力する波形データの受信装置において、（ａ）波形の復号化に要する処理時間が、前記符号の
受信に要した時間または受信開始から次の符号の受信開
始までの時間（これを指定時間と呼ぶ）を越えないよう
に、復号化処理を構成する処理単位に対応する符号化処
理単位ごとに、今回の符号に含まれている符号化処理単
位より実行時間の短い処理単位を選択する指示を含むデ
ータ列を構成する指示データ構成手段と、（ｂ）前記データ列を送信する送信手段とを備え、前記指定時間内に復号化処理を完了する符号を送信す
ることを送信側に伝達することを特徴とする波形データ
の受信装置。
【請求項８７】波形を符号化し、前記符号を出力する
波形データの送信方法において、（ａ）符号化処理を構成する処理単位ごとの、選択す
べき処理単位の指示を含むデータ列を受信し、（ｂ）前記データ列から、前記指示を抽出し、前記指
示に基き指定された処理単位を用い、波形の符号化を実
行し、符号を出力することを特徴とする波形データの送
信方法。
【請求項８８】波形を符号化し、前記符号を出力する
波形データの送信装置において、（ａ）符号化処理を構成する処理単位ごとの、選択す
べき処理単位の指示を含むデータ列を受信する受信手段
と、（ｂ）前記データ列から、前記指示を抽出する抽出手
段とを備え、前記指示に基き指定された処理単位を用
い、波形の符号化を実行し、符号を出力することを特徴
とする波形データの送信装置。
【請求項８９】波形データの符号を受信し、波形を復
号化し、出力する波形データの受信方法において、（ａ）波形の復号化処理を構成する処理単位ごとに、
その実行回数を計数し、（ｂ）前記実行回数と、波形の復号化に要した処理時
間とから各処理単位ごとの実行時間を推定し、（ｃ）波形の復号化に要する処理時間が、前記符号の
受信に要した時間または受信開始から次の符号の受信開
始までの時間（これを指定時間と呼ぶ）を越えないよう
に、復号化処理を構成する処理単位に対応する符号化処
理単位ごとに、今回の符号に含まれている符号化処理単
位より実行時間の短い処理単位を選択する指示を含むデ
ータ列を構成し、（ｄ）前記データ列を送信し、前記指定時間内に復号化処理を完了する符号を送信す
ることを送信方法に伝達することを特徴とする波形デー
タの受信方法。
【請求項９０】波形データの符号を受信し、波形を復
号化し、出力する波形データの受信装置において、（ａ）波形の復号化処理を構成する処理単位ごとに、
その実行回数を計数する計数手段と、（ｂ）前記実行回数と、波形の復号化に要した処理時
間とから各処理単位ごとの実行時間を推定する推定手段
と、（ｃ）波形の復号化に要する処理時間が、前記符号の
受信に要した時間または受信開始から次の符号の受信開
始までの時間（これを指定時間と呼ぶ）を越えないよう
に、復号化処理を構成する処理単位に対応する符号化処
理単位ごとに、今回の符号に含まれている符号化処理単
位より実行時間の短い処理単位を選択する指示を含むデ
ータ列を構成する指示データ構成手段と、（ｄ）前記データ列を送信する送信手段とを備え、前記指定時間内に復号化処理を完了する符号を送信す
ることを送信側に伝達することを特徴とする波形データ
の受信装置。
【請求項９１】動画像の符号を受信し、動画像を復号
化し、出力する動画像の受信方法において、（ａ）動画像の復号化に要する処理時間が、前記符号
の受信に要する時間または受信開始から次の符号の受信
開始までの時間（これを指定時間と呼ぶ）を越えないよ
うに、動画像の符号化にて使用する動き補償方式を、今回の符
号に含まれている動き補償処理より実行時間の短い動き
補償処理で、置き替える指示を含むデータ列を構成し、（ｂ）前記データ列を送信し、前記指定時間内に復号化処理を完了する符号を送信す
ることを送信側に伝達することを特徴とする動画像の波
形データの受信方法。
【請求項９２】動画像の符号を受信し、動画像を復号
化し、出力する動画像の受信装置において、（ａ）動画像の復号化に要する処理時間が、前記符号
の受信に要する時間または受信開始から次の符号の受信
開始までの時間（これを指定時間と呼ぶ）を越えないよ
うに、動画像の符号化にて使用する動き補償方式を、今回の符
号に含まれている動き補償処理より実行時間の短い動き
補償処理で、置き替える指示を含むデータ列を構成する
指示データ構成手段と、（ｂ）前記データ列を送信する送信手段とを備え、前記指定時間内に復号化処理を完了する符号を送信す
ることを送信側に伝達することを特徴とする動画像の受
信装置。
【請求項９３】動画像を符号化し、前記符号を出力す
る動画像の送信方法において、（ａ）復号化処理を構成する動き補償処理の、選択す
べき処理の指示を含むデータ列を受信し、（ｂ）前記データ列から、前記指示を抽出し、前記指示に基き指定された動き補償処理を用い、動画像
の符号化を実行し、符号を出力することを特徴とする動
画像の送信方法。
【請求項９４】動画像を符号化し、前記符号を出力す
る動画像の送信装置において、（ａ）復号化処理を構成する動き補償処理の、選択す
べき処理の指示を含むデータ列を受信する受信手段と、（ｂ）前記データ列から、前記指示を抽出する抽出手
段とを備え、前記指示に基き指定された動き補償処理を用い、動画像
の符号化を実行し、符号を出力することを特徴とする動
画像の送信装置。