[go: up one dir, main page]

JP5598155B2 - 情報処理装置および方法、並びに送受信システム - Google Patents

情報処理装置および方法、並びに送受信システム Download PDF

Info

Publication number
JP5598155B2
JP5598155B2 JP2010180945A JP2010180945A JP5598155B2 JP 5598155 B2 JP5598155 B2 JP 5598155B2 JP 2010180945 A JP2010180945 A JP 2010180945A JP 2010180945 A JP2010180945 A JP 2010180945A JP 5598155 B2 JP5598155 B2 JP 5598155B2
Authority
JP
Japan
Prior art keywords
unit
transmission
data
time
delay time
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 - Fee Related
Application number
JP2010180945A
Other languages
English (en)
Other versions
JP2012044252A (ja
JP2012044252A5 (ja
Inventor
嘉伸 久礼
秀明 村山
保 宗像
千裕 藤田
司 吉村
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Priority to JP2010180945A priority Critical patent/JP5598155B2/ja
Priority to US13/183,843 priority patent/US10306268B2/en
Priority to CN2011102131367A priority patent/CN102378003A/zh
Publication of JP2012044252A publication Critical patent/JP2012044252A/ja
Publication of JP2012044252A5 publication Critical patent/JP2012044252A5/ja
Application granted granted Critical
Publication of JP5598155B2 publication Critical patent/JP5598155B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/65—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using error resilience
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/756—Media network packet handling adapting media to device capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/124—Quantisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/146—Data rate or code amount at the encoder output
    • H04N19/152—Data rate or code amount at the encoder output by measuring the fullness of the transmission buffer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/30—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/60—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/60—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • H04N19/63—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding using sub-band based transform, e.g. wavelets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/4302—Content synchronisation processes, e.g. decoder synchronisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637—Control signals issued by the client directed to the server or network components
    • H04N21/6375—Control signals issued by the client directed to the server or network components for requesting retransmission, e.g. of data packets lost or corrupted during transmission from server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Description

本発明は、情報処理装置および方法、並びに送受信システムに関し、特に、コンテンツの品質の劣化を抑制することができるようにした情報処理装置および方法、並びに送受信システムに関する。
近年、インターネット、LAN（Local Area Network）、若しくは、その他の伝送路を経由して、メディア基準信号同期（所謂GENLOCK同期）を行いながらマルチメディアデータを低遅延に伝送するという需要が高まっている。
例えば、放送局においてカメラとそのコントロールユニット（所謂CCU（Camera Control Unit）とを、HD-SDI（High Definition Serial Digital Interface）ケーブルにより接続し、非圧縮同期伝送を行うシステムが存在する。近年、このシステムのHD-SDIケーブルをEthernet（登録商標）ケーブルに置き換え、Ethernet上でIPパケットによるGENLOCK同期を行いながら伝送するといったことが行われている。
このような目的においてマルチメディアデータのIP伝送を行う場合、HD-SDIケーブル経由での伝送と同等の使い勝手が要求されるため、例えば、高精度のGENLOCK同期とビデオフレーム間隔以下の低遅延伝送が要求される。
このような要求から動画像の各ピクチャの数ライン毎を１つの符号化ブロック（ラインブロック）としてウェーブレット変換による符号化を行う方式が提案されている（例えば特許文献１参照）。
この方式では、ピクチャ内のデータ全てを入力するまで待つことなく符号化を開始することができる。そのため、生成した符号化データをネットワーク伝送し、受信側で復号する場合においても、ピクチャ内の全てのデータを受信する前に復号処理を開始することができる。つまり、ネットワーク伝播遅延が十分小さければ、フレーム間隔以下の遅延でのリアルタイム（即時的な）動画像伝送が可能となる。
このようなデータ伝送においては、システムが破たんしないように、安定的にデータ伝送を行うために、エラー訂正やパケット再送などのための時間が遅延時間として設定される。このように、処理の待ち時間やデータのバッファリング等のような、遅延時間の確保が必要な要素を遅延要素と称する。
一般的に、データ伝送においては、複数の遅延要素が存在する場合が多い。このような遅延要素に対して、受信側の装置においては遅延時間が確保されるが、このように複数の遅延要素が存在する場合、受信側の装置における遅延時間は、各遅延要素についての遅延時間のうち、最も長いもの（若しくはそれ以上）に設定される。
つまり、受信側の装置における遅延時間設定よりも短い遅延時間の遅延要素については、その遅延時間設定と同じ時間まで遅延時間を延ばしても、受信側の遅延時間設定は変化しない。つまり、データ伝送全体の遅延時間は増大しない。
特許４３７１１２０号
しかしながら、従来の方式においては、上述した各遅延要素についての遅延時間は、互いに独立して設定されていたので、遅延時間が短く設定された遅延要素に関係する処理は、その遅延時間が不要に短く設定されたまま実行されることになり、その処理後、何も処理が行われない不要な待機時間が生じてしまう恐れがあった。すなわち、データ伝送によりコンテンツの品質を不要に劣化させる恐れがあった。
本発明は、このような状況に鑑みてなされたものであり、各処理の時間的余裕を画質や伝送品質の向上に利用することができるようにし、遅延時間上の無駄を低減させることができるようにすることを目的とする。
本発明の一側面は、データを伝送する際に行われる複数の処理のそれぞれにおいて設定される遅延時間であって、それぞれが前記データの品質や前記データの伝送品質に対して影響を及ぼし、かつ、互いに並列に作用する複数の前記遅延時間を、各遅延時間の長さに対する要求に基づいて、要求された各遅延時間の内の最長の遅延時間以上の長さに設定する遅延時間設定部と、前記データを受信する受信部と、前記遅延時間設定部により設定された前記複数の遅延時間を前記受信部に設定する受信側設定部と、前記遅延時間設定部により設定された前記複数の遅延時間を、前記データを送信する送信装置に通知し、前記送信装置おいて行われる処理に設定させる送信側設定部とを備える情報処理装置である。
前記受信部が受信する前記データの損失パケットの検出を行い、前記損失パケットが検出された場合、前記送信装置に対して再送要求を行う再送要求部をさらに備え、前記遅延時間は、前記再送要求部の前記再送要求により再送される再送パケットを待つ時間であるARQ再送パケット待ち時間を含み、前記受信側設定部は、前記再送要求部に対して、前記ARQ再送パケット待ち時間を設定することができる。
前記受信部が受信した前記データを記憶する受信バッファをさらに備え、前記遅延時間は、前記受信バッファでバッファリングを行う時間であるバッファ時間を含み、前記受信側設定部は、前記バッファ時間を前記受信バッファに設定することができる。
前記受信部が受信した、前記送信装置において前記データが可変圧縮符号化されて平滑化伝送された符号化データを記憶する受信バッファをさらに備え、前記遅延時間は、前記受信部の前記受信バッファにおいて必要な前記符号化データのバッファ時間である可変圧縮符号化遅延時間を含み、前記送信側設定部は、前記可変圧縮符号化遅延時間を、前記送信装置に通知し、前記送信装置おいて行われる符号化処理に設定させることができる。
前記受信部が受信した、前記送信装置において前記データが冗長符号化されて伝送された冗長符号化ブロックを冗長復号する冗長復号部を備え、前記遅延時間は、前記冗長符号化ブロックの先頭パケットが前記受信部に到着してから末尾のパケットが到着するまでの時間である冗長符号化ブロック受信待ち時間を含み、前記送信側設定部は、前記冗長符号化ブロック受信待ち時間を、前記送信装置に通知し、前記送信装置おいて行われる冗長符号化処理に設定させることができる。
ネットワーク状況を計測する計測部をさらに備え、前記遅延時間設定部は、各遅延時間の長さに対する要求、並びに、前記計測部により計測された前記ネットワーク状況に応じて、各遅延時間を設定することができる。
前記データは画像データであり、前記画像データの画質に関する要求である画像品質要求、および、前記画像データの伝送品質に関する要求である伝送品質要求を受け付ける受付部をさらに備え、前記遅延時間設定部は、前記受付部により受け付けられた前記画像品質要求および前記伝送品質要求に基づいて、要求される各遅延時間の長さを求め、求めた各遅延時間の長さに対する要求に基づいて、前記複数の遅延時間を、要求された各遅延時間の内の最長の遅延時間以上の長さに設定することができる。
前記受付部により受け付けられる前記画像品質要求および前記伝送品質要求の入力を補助するGUIを表示する出力部をさらに備えることができる。
複数の前記送信装置のそれぞれについて、ネットワーク状況として、前記データの伝送遅延の長さを計測するネットワーク計測部をさらに備え、前記受信部は、複数の前記送信装置より伝送される前記データを受信し、前記遅延時間設定部は、前記複数の送信装置から伝送される前記データのそれぞれについて、前記複数の遅延時間を、各遅延時間の長さに対する要求に基づいて、要求された各遅延時間の内の最長の遅延時間以上の長さに設定する第１の遅延時間設定部と、各送信装置の前記第１の遅延時間設定部により設定された前記遅延時間と前記ネットワーク計測部により計測された前記伝送遅延の長さとの和を、前記和の最大値に合わせるように、前記遅延時間を設定する第２の遅延時間設定部とを備え、前記受信側設定部は、前記第２の遅延時間設定部により設定された前記複数の遅延時間を前記受信部に設定し、前記送信側設定部は、前記第２の遅延時間設定部により設定された前記複数の遅延時間を、前記データを送信する送信装置に通知し、前記送信装置おいて行われる処理に設定させることができる。
本発明の一側面は、また、データを伝送する際に行われる複数の処理のそれぞれにおいて設定される遅延時間であって、それぞれが前記データの品質や前記データの伝送品質に対して影響を及ぼし、かつ、互いに並列に作用する複数の前記遅延時間を、各遅延時間の長さに対する要求に基づいて、要求された各遅延時間の内の最長の遅延時間以上の長さに設定し、前記データを受信し、設定された前記複数の遅延時間を受信部に設定し、設定された前記複数の遅延時間を、前記データを送信する送信装置に通知し、前記送信装置おいて行われる処理に設定させる情報処理方法である。
本発明の他の側面は、データを送信する送信装置と、前記送信装置より送信されたデータを受信する受信装置とを備える送受信システムであって、前記受信装置は、前記データを伝送する際に行われる複数の処理のそれぞれにおいて設定される遅延時間であって、それぞれが前記データの品質や前記データの伝送品質に対して影響を及ぼし、かつ、互いに並列に作用する複数の前記遅延時間を、各遅延時間の長さに対する要求に基づいて、要求された各遅延時間の内の最長の遅延時間以上の長さに設定する遅延時間設定部と、前記データを受信する受信部と、前記遅延時間設定部により設定された前記複数の遅延時間を前記受信部に設定する受信側設定部と、前記遅延時間設定部により設定された前記複数の遅延時間を前記送信装置に通知する通知部とを備え、前記送信装置は、前記データを送信する送信部と、前記受信装置から通知される前記複数の遅延時間を取得する遅延時間取得部と、前記遅延時間取得部により取得された前記複数の遅延時間を前記送信部に設定する送信側設定部とを備える送受信システムである。
本発明の一側面においては、データを伝送する際に行われる複数の処理のそれぞれにおいて設定される遅延時間であって、それぞれがデータの品質やデータの伝送品質に対して影響を及ぼし、かつ、互いに並列に作用する複数の遅延時間が、各遅延時間の長さに対する要求に基づいて、要求された各遅延時間の内の最長の遅延時間以上の長さに設定され、データが受信され、設定された複数の遅延時間が受信部に設定され、設定された複数の遅延時間が、データを送信する送信装置に通知され、送信装置おいて行われる処理に設定される。
本発明の他の側面においては、データを送信する送信装置より送信されたデータを受信する受信装置とを備える送受信システムの受信装置においては、データを伝送する際に行われる複数の処理のそれぞれにおいて設定される遅延時間であって、それぞれがデータの品質やデータの伝送品質に対して影響を及ぼし、かつ、互いに並列に作用する複数の遅延時間が、各遅延時間の長さに対する要求に基づいて、要求された各遅延時間の内の最長の遅延時間以上の長さに設定され、データが受信され、設定された複数の遅延時間が、データを受信する受信部に設定され、設定された複数の遅延時間が送信装置に通知され、送受信システムの送信装置においては、データが送信され、受信装置から通知される複数の遅延時間が取得され、取得された複数の遅延時間がデータを送信する送信部に設定される。
本発明によれば、データを伝送することができる。特に、コンテンツの品質の劣化を抑制することができる。
本発明を適用した伝送システムの主な構成例を示すブロック図である。 符号化部の主な構成例を示すブロック図である。 分析フィルタリングの概要を説明する図である。 分析フィルタリングの概要を説明する図３に続く図である。 ラインブロックを説明する図である。 復号部の主な構成例を示すブロック図である。 データ伝送処理の流れの例を説明するフローチャートである。 要求受付画面の表示例を示す図である。 受信バッファ時間決定処理の流れの例を説明するフローチャートである。 遅延時間設定の様子の例を説明する図である。 受信バッファ時間・処理パラメータ設定処理の流れの例を説明するフローチャートである。 データ伝送処理の流れの他の例を説明するフローチャートである。 受信バッファ動的変更伝送処理の流れの例を説明するフローチャートである。 本発明を適用した伝送システムの主な構成例を示すブロック図である。 受信部の主な構成例を示すブロック図である。 データ伝送処理の流れの、さらに他の例を説明するフローチャートである。 仮受信バッファ時間決定処理の流れの例を説明するフローチャートである。 統合受信バッファ時間決定処理の流れの例を説明するフローチャートである。 受信バッファ時間設定の様子の例を説明する図である。 受信バッファ動的変更伝送処理の流れの、他の例を説明するフローチャートである。 本発明を適用したパーソナルコンピュータの主な構成例を示すブロック図である。
以下、発明を実施するための形態（以下実施の形態とする）について説明する。なお、説明は以下の順序で行う。
１．第１の実施の形態（伝送システム）
２．第２の実施の形態（伝送システム）
３．第３の実施の形態（伝送システム）
４．第４の実施の形態（パーソナルコンピュータ）
＜１．第１の実施の形態＞
［伝送システムの概要］
図１は、本発明を適用した伝送システムの主な構成例を示すブロック図である。伝送システム１００は、送信装置１０１に入力された画像データ（ビデオデータ（ビデオIN））を、リアルタイムに（即時的に）、インターネットやLAN等の汎用の伝送路であるネットワーク１０２を介して受信装置１０３伝送し、その受信装置１０３より出力する（ビデオOUT）システムである。
送信装置１０１は、外部入力端子「ビデオIN」より入力された動画像の画像データを、全てのデータが入力されるまで待たずに、順次、符号化し、生成した符号化データのパケットを、ネットワーク１０２を介して受信装置１０３に送信する。
ネットワーク１０２は、例えば、インターネットやLAN等のような汎用のIPパケット網である。ネットワーク１０２においては、送信装置１０１および受信装置１０３の間のデータ伝送以外の、他のデータ伝送も行われる。
受信装置１０３は、送信装置１０１から伝送されるパケットを受信し、順次、得られた符号化データを復号し、復号画像の画像データを外部出力端子「ビデオOUT」より出力する。なお、受信装置１０３は、送信装置１０１に入力される画像データのサンプリング周波数に同期したタイミングで画像データの出力を行う。つまり、画像データは、送信装置１０１に入力されるときと同じフレームレートで受信装置１０３より出力される。伝送システム１００は、この出力タイミングに間に合うようにデータ伝送を行う。
近年においては、インターネットやLAN（Local Area Network）の汎用の伝送路を経由してメディア基準信号同期（所謂GENLOCK同期）を行いながらマルチメディアデータを低遅延に伝送するという需要が高まっている。
例えば、放送局においては、従来、カメラとそのコントロールユニット（所謂CCU）がHD-SDIケーブルにより接続され、それらの間で非圧縮同期伝送が行われていた。近年においては、このHD-SDIケーブルをEthernetケーブルに置き換え、Ethernet上でIPパケットによるGENLOCK同期を行いながら伝送するといったことが行われている。
このような目的においてマルチメディアデータのIP伝送を行う場合、HD-SDIケーブル経由での伝送と同等の使い勝手を要求される。そのため、高精度のGENLOCK同期や、ビデオフレーム間隔以下の低遅延伝送等が要求される。
このような要求から特許文献１においては、動画像の各ピクチャの数ライン毎を１つの符号化ブロック（ラインブロック）とし、符号化を行う方式が提案されている。この方式の場合、送信装置１０１は、ピクチャ内のデータ全てを入力するまで待つことなく符号化を開始することができる。また、送信装置１０１は、その符号化により得られた符号化データを、順次、ネットワーク１０２を介して受信装置１０３に伝送することができる。
さらに、受信装置１０３は、ピクチャ内の全てのデータを受信する前に復号を開始することができる。ネットワーク伝播遅延が十分小さければ、フレーム間隔以下の遅延でのリアルタイム動画像伝送（送信装置１０１入力時のフレームレートで、受信装置１０３から出力することができるようなデータ伝送）が可能となる。
動画像の符号化処理では、フレームやラインブロック等、短い時間単位において一定データレートにて符号化を行うCBR（Constant Bit Rate）方式と、長い時間間隔における平均データレートは一定だが短い時間間隔ではデータレートが変動するVBR（Variable Bit Rate）方式がある。
VBR方式で圧縮されたストリームデータを伝送する場合、ITU-T Y.1221記載のトークンバケット等を用い平滑化処理を行い、符号化処理においてはトークンバケットの最大バケツサイズを超えないように制御する。このとき最大バケツサイズにより符号化処理における最大バースト（瞬時）データサイズは制限される。
VBR方式の場合、一般に、画像の複雑度の高い部分、動きの激しいシーン等の圧縮効率の低い部分に多くのデータを割り当てることができる。そのため、一般的に、VBR方式の方がCBR方式よりも圧縮効率が高い。つまり、一般的に、同一の平均データレートの場合、VBR方式の方がCBR方式よりも高画質である。
トークンバケットにおける最大バケツサイズを大きくとればとるほど画質は向上するが、ストリーム伝送後の同期再生を考えた場合、同期再生までの遅延時間は大きくなる。以下において、VBR方式で符号化処理を行った場合の平滑化処理により生じる遅延時間を可変圧縮符号化遅延時間と称する。
上述したようなリアルタイム伝送に適したインターネット技術にIETF RFC3550で規定されているRTP（Realtime Transport Protocol）がある。RTPによるデータ転送では、時間情報としてパケットにタイムスタンプを付加しておき、これによって送信側と受信側の時間的関係を把握することでパケット転送の遅延ゆらぎ（ジッタ）などの影響を受けずに同期をとって再生することができる。
ここでRTPは、実時間のデータ転送を保証しているものではない。例えばパケット配送の優先度の設定や管理などはRTPが提供するトランスポートサービスの範疇ではない。そのため、RTPパケットは、他のパケットと同様に、配送遅延やパケット損失がおきる可能性がある。このような事態が起こる場合であっても、受信装置１０３は、期待する時間内に到着したパケットだけを利用してデータを再生することができる。映像や音声データは、多少のデータ損失があったとしても、ある程度再生することができる。
なお、遅延配送されたパケットやエラーの発生したパケットは、受信装置１０３により、破棄される。つまり、パケット損失やエラーにより高品質なデータを配信するようにしても、受信装置１０３において、その高品質なデータが十分に再生されない恐れがある。有線区間で１０−５以上、無線区間で１０−３以上のエラーがあるといわれており、このような現状の中でRTPをそのまま利用するのでは、配信するメディアの品質を保持する点について信頼性が低い。
これに対して、データ転送に信頼性が高いTCP（Transmission Control Protocol）で再送要求および再送パケット送信を行わせる方法がある。しかしながら、TCPは、エラーには強いものの、スループットが低く遅延が大きい。そのため、再送しても再生時間に間に合わない恐れがある。
RTPを用いてデータ転送の信頼性を向上させる手法として、データの冗長符号化を行い信頼性の向上を図る、前方誤り訂正符号化方式（所謂FEC(Forward Error Correction)方式）という手法がある。
FEC方式では、パケット複数個を１つのFECブロックとし、Reed-Solomon（RS）符号等の誤り訂正符号を用いて冗長符号化を行う。例えば（n,k）RS符号を用いる場合、元パケットをk個とするとn-k個冗長パケットを生成することができる（n > k）。この場合、送信装置１０１から合計n個のパケットを送信することにより、受信装置１０３ではn個のパケット中k個のパケットを受信すれば、RS復号処理によりk個の元パケットを復元することができる。
FEC方式を用いて冗長符号化した場合、パケット損失に対する回復性能はFECブロック元データ単位と冗長パケット数n-kとに依存する。特に、ネットワーク伝送中に起こるデータ系列上連続するパケットの損失（所謂バーストパケット損失）に対する回復性能は、FECブロック元データ単位と関係が深い。一般に、FECブロック元データ単位を大きくとればとるほど、バーストパケット損失に対する回復性能は向上する。
しかしながら、FECブロック元データ単位を大きく取るとFEC符号化処理・復号処理を行うために必要なブロックサイズ（データ量）が増大する。その分、処理に必要なデータ蓄積量、すなわち、待機時間が増大するので、遅延時間が増大する恐れがあった。このようなFEC符号化処理やFEC復号処理に必要な遅延時間を、冗長符号化ブロック受信待ち時間と称する。
データ転送の信頼性を向上させる他の手法として、自動再送方式、いわゆるARQ（Auto Repeat Request）方式がある。ARQ方式は、受信装置１０３が、RTPパケットのシーケンス番号を利用して損失したパケットを検知し、送信装置１０１へ損失パケットの再送を要求するようにする方式である。このARQ方式の拡張方法として、受信装置１０３が、パケット損失に対して一定時間再送パケットを受信しなかった場合、再度再送要求を行う手法もある。
この手法を用いる場合、受信装置１０３における再送パケット待ち時間を大きく設定すればするほど回復性能は向上するが、その分、同期再生時の遅延を増大させてしまう。
また他の伝送品質の回復手法として、受信装置１０３が、ネットワーク伝送時間の変動（所謂ネットワークジッタ）を吸収するためのバッファ（ネットワークジッタ対応バッファ）を設ける方法もある。このネットワークジッタ対応バッファでバッファリングを行う時間、（所謂ネットワークジッタ対応バッファ時間）を大きくとればとるほど、受信装置１０３において行われる各種処理における、ネットワークジッタによる影響を抑制することができる。ただし、その分、同期再生時の遅延を増大させてしまう。
以上のように、データ伝送に関して、一般的に、多様な遅延要素が存在し、受信側の装置においては、各遅延要素についての遅延時間の確保が必要であった。
しかしながら、従来においては、復号画像の画質（画質要求）や、データ伝送時のパケット損失率（伝送品質）等に対する要求に応じて、可変圧縮符号化遅延時間、冗長符号化ブロック受信待ち時間、ARQ再送パケット待ち時間、および、ネットワークジッタ対応バッファ時間等の各種遅延時間が互いに独立に設定されていた。
受信装置１０３は、これらの遅延によりシステムが破たんしないように、受信したデータを、これらの遅延時間の最大値以上の時間、一時的に保持する。つまり、各遅延要素の遅延時間を受信装置１０３において確保する必要があった。このデータを保持する時間を受信バッファ時間と称する。
この場合、例えば可変圧縮符号化遅延時間が上記遅延時間中最大値であり、この値を受信バッファ時間として設定したとする。その場合、冗長符号化処理において、さらに冗長符号化ブロックを大きく取ることによりバースト損失耐性を向上させ、冗長符号化ブロック受信待ち時間を受信バッファ時間と同等まで大きくしても全体の遅延時間は増加しない。
しかしながら、仮に、冗長符号化ブロック受信待ち時間が、従来の方法のように、他と独立して設定されるとする。その場合、冗長符号化処理は、冗長符号化ブロック受信待ち時間が小さいまま行われることになる。つまり、冗長符号化処理において、処理が行われない不要な待機時間が発生し、遅延時間上の無駄が生じる恐れがあった。
また、冗長符号化ブロック受信待ち時間が最大である場合、可変圧縮符号化遅延時間を大きく設定することにより、全体の遅延時間を増大させずに画質を向上させることができる。しかしながら、上述した従来の方法のように各遅延時間が互いに独立して設定されるものとすると、符号化処理は、可変圧縮符号化遅延時間が小さい設定のまま行われることになる。つまり、遅延時間上の無駄が生じる恐れがあった。
受信装置１０３は、データ伝送を遅延させる遅延時間であって、そのデータ伝送に関する互いに異なる複数の遅延要素についての遅延時間のそれぞれの長さを、その複数の遅延時間の内、最長の遅延時間に合わせるように調整する。
送信装置１０１も、受信装置１０３から供給される情報に基づいて、受信装置１０３において確保された遅延時間（受信バッファ時間）より遅延時間が増大しないように、かつ、より遅延時間を長くし、画像や伝送の品質を向上させるように、各処理のパラメータを設定する。
したがって、伝送システム１００（送信装置１０１および受信装置１０３）は、このような遅延時間上の無駄を抑制するようにし、データ伝送全体の遅延時間を増大させずに画質や伝送品質（コンテンツの品質）を向上させることができる。
［送信装置の構成］
図１に示されるように、送信装置１０１は、符号化部１１１、FEC部１１２、RTP部１１３、平滑化部１１４、基準信号同期部１１５、メディア同期部１１６、RTCP（RTP Control Protocol）部１１７、ARQ部１１８、および受信バッファ時間・処理パラメータ設定部１１９を有する。
ビデオカメラ等を経由しビデオ入力IF「ビデオIN」より入力したビデオデータ（動画像データ）は、符号化部１１１に供給される。符号化部１１１は、所定の符号化方式で動画像データの符号化処理を行う。この符号化方式は任意であるが、より低遅延なものが望ましい。符号化方式の例については後述する。
符号化部１１１は、レート制御部１２１を有する。レート制御部１２１は、符号化部１１１において生成される符号化データのビットレートを制御する。符号化部１１１は、生成した符号化データをRTPパケット化し、それをFEC部１１２に供給する。
FEC部１１２は、符号化部１１１から供給されるRTPパケットの冗長パケットを生成する。RTP部１１３は、FEC部１１２から供給される符号化データの冗長パケットをRTPパケット化する。
平滑化部１１４は、RTP部１１３から供給されるRTPパケットを、一時的に保持し、所定のデータレートに平滑化して送信する。
基準信号同期部１１５は、ネットワーク１０２を介して、伝送先である受信装置１０３の基準信号同期部１３９と通信を行い、基準信号クロックの同期をとる。基準信号同期部１１５は、受信装置１０３との間で同期がとれた基準信号をメディア同期部１１６に供給する。
メディア同期部１１６は、基準信号同期部１１５から供給される時刻を基準として、ビデオINに入力されたデータのサンプリング時刻と同期した時刻を、符号化部１１１（内のRTP部）とRTP部１１３に供給する。この時刻は、RTPタイムスタンプとしてRTPパケットに付加される。
RTCP部１１７は、伝送先の受信装置１０３のRTCP部１３７とRTCPメッセージの授受を行い、QoS（Quality of Service）制御処理のための制御メッセージ（QoS制御メッセージ）の送受信を行う。RTCP部１１７は、取得した制御メッセージをARQ部１１８や受信バッファ時間・処理パラメータ設定部１１９に供給する。
ARQ部１１８は、RTCP部１１７から供給される再送要求メッセージに従って、要求されたRTPパケットの再送を行う。
受信バッファ時間・処理パラメータ設定部１１９は、RTCP部１１７から供給される各種遅延時間等の設定に従って、符号化部１１１やFEC部１１２のパラメータ設定を行う。
［受信装置の構成］
図１に示されるように、受信装置１０３は、受信部１３１、受信バッファ１３２、RTP部１３３、FEC部１３４、復号部１３５、ARQ部１３６、RTCP部１３７、受信バッファ時間設定部１３８、基準信号同期部１３９、メディア同期部１４０、入力部１４１、および出力部１４２を有する。
受信部１３１は、ネットワーク１０２を介して送信装置１０１から伝送されるRTPパケットを受信し、それを受信バッファ１３２に供給する。受信バッファ１３２は、ネットワーク１０２におけるパケット伝送の遅延時間の変動を吸収する等のために、受信部１３１から供給されるRTPパケットを、一時的に保持した後、受信バッファ時間設定部１３８やメディア同期部１４０からの情報に基づいて決定される時刻に、RTP部１３３に供給する。
RTP部１３３は、RTPパケットを再構成して、冗長パケットを含む符号化データであるFEC冗長符号化データを生成し、それをFEC部１３４に供給する。FEC部１３４は、パケットの損失の検出を行い、必要に応じて冗長符号化復号処理によって損失パケットデータを回復する。FEC部１３４は、処理後の符号化データを復号部１３５に供給する。
復号部１３５は、符号化データを、符号化部１１１による符号化処理の方式に対応する復号方式により復号する。復号されたビデオデータ（動画像データ）は、受信装置１０３のビデオ出力IF（ビデオOUT）から、例えば、ディスプレイ等の映像表示装置（図示せず）に出力される。
ARQ部１３６は、受信部１３１における損失パケット（受信できなかったパケット）の検出を行い、損失パケットを検出した場合、RTCP部１３７を制御し、送信装置１０１のARQ部１１８に対する再送要求メッセージを送信させる。RTCP部１３７は、ARQ部１３６から要求された再送要求メッセージや、受信バッファ時間設定部１３８から供給される各種設定情報をRTCPメッセージとして、送信装置１０１のRTCP部１１７に供給する。
受信バッファ時間設定部１３８は、例えば入力部１４１を介して入力される画像品質要求や、伝送品質要求等に基づいて、受信バッファ時間等を設定する。画像品質要求は、復号画像（受信装置１０３から出力されるビデオデータの画像）の画質に対する要求である。伝送品質要求は、ネットワーク１０２のパケットロス率等に対する要求である。受信バッファ時間は、システムを破たんさせないように、データ伝送を安定的に伝送させるために受信装置１０３において設定される遅延時間である。
基準信号同期部１３９は、基準信号同期部１１５と通信し、送信装置１０１との間で基準信号の同期をとる。メディア同期部１４０は、基準信号同期部１３９により同期がとられた基準信号に基づいて、受信バッファ１３２のRTPパケット出力タイミングや、復号部１３５の復号処理開始タイミング等を制御する。
入力部１４１は、例えば、キーボード、マウス、タッチパネル、若しくはスイッチ等の任意の入力デバイス、または外部入力端子等よりなり、例えばユーザ等の、受信装置１０３外部からの画像品質要求や伝送品質要求を受け付け、それを受信バッファ時間設定部１３８に供給する。
出力部１４２は、例えば、モニタやスピーカ等の任意の出力デバイス、または、外部出力端子等よりなり、受信バッファ時間設定部１３８から供給されるGUI画像を表示したり、音声を出力したりして、画像品質要求や伝送品質要求の入力案内や、入力結果を出力する。
［符号化部の構成例］
次に、送信装置１０１の符号化部１１１の例について説明する。図２は、送信装置１０１の符号化部１１１の構成例を示すブロック図である。符号化部１１１は、画像データを解像度に関して重要度の高いデータから順に階層化し、その階層毎に符号化する階層符号化を行う。例えば、符号化部１１１は、空間解像度に関して重要度の高いデータから順に階層化された階層化データを生成する。また、例えば、符号化部１１１は、時間方向の解像度に関して重要度の高いデータから順に階層化された階層化データを生成する。さらに、例えば、符号化部１１１は、SNR（Signal to Noise Ratio）に関して重要度の高いデータから順に階層化された階層化データを生成する。符号化部１１１は、このように生成した階層化データを、その階層毎に符号化する。
このような階層符号化として、例えば、動画像データの各ピクチャをウェーブレット変換し、エントロピ符号化するJPEG(Joint Photographic Experts Group)2000方式がある。階層符号化方法は任意であるが、以下においては、符号化部１１１が、動画像データを複数ライン毎にウェーブレット変換し、エントロピ符号化する場合について説明する。
図２に示されるように、符号化部１１１は、ウェーブレット変換部１６１、量子化部１６２、エントロピ符号化部１６３、レート制御部１２１、およびRTP部１６４を有する。ウェーブレット変換部１６１は、動画像の各ピクチャを、複数ライン毎にウェーブレット変換する。
ウェーブレット変換は、入力データを低域成分と高域成分に分割する分析フィルタ処理を画面水平方向および画面垂直方向の両方に対して行う処理である。つまり、ウェーブレット変換処理により入力データは、水平方向および垂直方向に低域な成分（ＬＬ成分）、水平方向に高域で垂直方向に低域な成分（ＨＬ成分）、水平方向に低域で垂直方向に高域な成分（ＬＨ成分）、および、水平方向および垂直方向に高域な成分（ＨＨ成分）の４つの成分（サブバンド）に分割される。
ウェーブレット変換部１６１は、このようなウェーブレット変換処理を、所定回数、分析フィルタ処理により得られる水平方向および垂直方向に低域な成分（ＬＬ成分）に対して再帰的に繰り返す。つまり、ウェーブレット変換処理により、動画像データの各ピクチャは、階層化された複数のサブバンド（周波数成分）に分割される（階層化データが生成される）。エントロピ符号化部１６３は、このサブバンド毎に符号化を行う。
動画像の各ピクチャの画像データは、画像の上から下に向かう順に１ラインずつウェーブレット変換部１６１に入力される。また各ラインの画像データは、画像左から右に向かう順に１サンプル（１コラム）ずつ入力される。
ウェーブレット変換部１６１は、そのように入力される画像データに対して、分析フィルタリングを実行可能なサンプル数のデータを入手する毎に（入手次第）、画像水平方向の分析フィルタリング（水平分析フィルタリング）を実行する。例えば、ウェーブレット変換部１６１は、図３の左に示されるベースバンドの画像データ１７１に対して、Ｍコラム入力される毎に水平分析フィルタリングを行い、１ラインずつ水平方向に低域な成分（Ｌ）と高域な成分（Ｈ）に分割する。図３の右に示される水平分析フィルタ処理結果１７２は、ウェーブレット変換部１６１により分割されたＮライン分の水平方向に低域な成分（Ｌ）と高域な成分（Ｈ）を示す。
次に、ウェーブレット変換部１６１は、その水平分析フィルタ処理結果１７２の各成分に対して、垂直方向に分析フィルタリング（垂直分析フィルタリング）を行う。ウェーブレット変換部１６１は、水平分析フィルタリングにより、垂直分析フィルタリングに必要な垂直ライン分の係数が生成されると、その垂直分析フィルタリングに必要な垂直ライン分の係数に対して、コラム毎に垂直分析フィルタリングを行う。
その結果、水平分析フィルタ処理結果１７２は、図４の左に示されるように、水平方向および垂直方向の両方に低域な成分（ＬＬ成分）、水平方向に高域で垂直方向に低域な成分（ＨＬ成分）、水平方向に低域で垂直方向に高域な成分（ＬＨ成分）、および、水平方向および垂直方向の両方に高域な成分（ＨＨ成分）の４つの成分のウェーブレット変換係数（以下、係数と称する）に分割される（階層化データ１７３）。
所定の階層（分割レベル）の係数が得られるまで、得られた分析フィルタリングの結果のうち、ＨＬ成分、ＬＨ成分、ＨＨ成分は外部に出力される。残りのＬＬ成分は、ウェーブレット変換部１６１により、再度分析フィルタリングが行われる。つまり、例えば、図４の左に示される階層化データ１７３は、図４の右に示される階層化データ１７４に変換される。階層化データ１７４では、ＬＬ成分から、ＬＬＬＬ成分、ＬＬＨＬ成分、ＬＬＬＨ成分、およびＬＬＨＨ成分の４つの成分が生成されている。
ウェーブレット変換部１６１は、このような分析フィルタリングを所定回数再帰的に行い、動画像データを所望の分割レベルまで階層化された階層化データを生成する。図５は、分割レベル３（３階層）まで階層化された階層化データの例を示す図である。図５において、分割レベル３まで分割された階層化データ１７５は、分割レベル１（階層番号３）の３ＨＬ成分、３ＬＨ成分、および３ＨＨ成分、分割レベル２（階層番号２）の２ＨＬ成分、２ＬＨ成分、および２ＨＨ成分、並びに、分割レベル３（階層番号１）の１ＬＬ成分、１ＨＬ成分、１ＬＨ成分、および１ＨＨ成分の各サブバンドにより構成される。
ウェーブレット変換処理では、フィルタリング処理を繰り返す毎に（階層が１つ下位になる毎に）、生成されるライン数は２のべき乗分の１の大きさで小さくなっていく。最終分割レベル（階層番号１）の係数を１ライン生成するために必要なベースバンドのライン数は、そのフィルタリング処理を何回繰り返すか（最終分割レベルの階層数）によって決められる。通常、この階層数は予め定められる。
この、最終分割レベルの係数を１ライン生成するために必要なベースバンドの画像データ（複数ライン分の画像データ）、または、各階層の係数をまとめてラインブロック（またはプレシンクト）と称する。
図５において斜線で示される部分が１ラインブロックを構成する係数である。図５に示されるように、ラインブロックは、階層番号１の各成分の１ライン分の係数、階層番号２の各成分の２ライン分の係数、並びに、階層番号３の各成分の４ライン分の係数により構成される。なお、これらに相当する分析フィルタリング前の画像データ、すなわち、この例では８ライン分の画像データのこともラインブロック（またはプレシンクト）と称する。
図２に戻り、量子化部１６２は、ウェーブレット変換部１６１により生成される各成分の係数を、例えば量子化ステップサイズで除算することにより量子化し、量子化係数を生成する。この際、量子化部１６２は、ラインブロック（プレシンクト）毎に量子化ステップサイズを設定することができる。このラインブロックは、ある画像領域のすべての周波数成分（図５の場合、１ＬＬ乃至３ＨＨまでの１０個の周波数成分）の係数を包含しているため、ラインブロック毎に量子化を行えば、ウェーブレット変換の特徴である多重解像度分析の利点を活かすことができる。また、全画面でラインブロック数だけを決めればよいため、量子化の負荷も小さくて済む。
さらに、画像信号のエネルギは一般的に低域成分に集中しており、また、人間の視覚上、低域成分の劣化が目立ちやすいという特性があるため、量子化に際しては、低域成分のサブバンドでの量子化ステップサイズが結果的に小さな値になるように、重み付けを行うことが有効である。この重み付けにより、低域成分には相対的に多くの情報量が割り当てられるようになり、全体の主観的な画質が向上する。
エントロピ符号化部１６３は、量子化部１６２で生成された量子化係数を情報源符号化し、圧縮された符号化データを生成し、それをレート制御部１２１に供給する。情報源符号化としては、例えばJPEG方式やMPEG（Moving Picture Experts Group）方式で用いられているハフマン符号化や、JPEG2000方式で用いられているさらに高精度な算術符号化を用いることができる。
ここで、エントロピ符号化をどの範囲の係数に対して行うかは、圧縮効率に直接関係する非常に重要な要素になる。例えば、JPEG方式やMPEG方式では、８×８のブロックに対してDCT（Discrete Cosine Transform）変換を施し、生成された６４個のDCT変換係数に対してハフマン符号化を行うことで、情報を圧縮している。すなわち、６４個のDCT変換係数がエントロピ符号化の範囲になる。
ウェーブレット変換部１６１では、８×８ブロックに対するDCT変換とは異なり、ライン単位でウェーブレット変換を施しているため、エントロピ符号化部１６３では、周波数帯域（サブバンド）毎に独立に、且つ各周波数帯域内をＰライン毎に情報源符号化する。
Ｐは１ラインが最低であるが、ライン数が少ない場合には参照情報が少なくて済み、メモリ容量を減らすことができる。逆に、ライン数が多い場合には情報量がその分増えるため、符号化効率が向上させることができる。しかしながら、Ｐが各周波数帯域内のラインブロックのライン数を超えた値になると、次のラインブロックのラインまで必要になる。このため、このラインブロックの量子化係数データがウェーブレット変換及び量子化によって生成されるまで待たなければならず、この時間が遅延時間となってしまう。
したがって、低遅延のためには、Ｐはラインブロックのライン数以下である必要がある。例えば、図５の例では、１ＬＬ，１ＨＬ，１ＬＨ，１ＨＨの周波数帯域については、ラインブロックのライン数＝１ラインであるためＰ＝１となる。また、２ＨＬ，２ＬＨ，２ＨＨのサブバンドについては、ラインブロックのライン数＝２ラインであるためＰ＝１または２となる。
レート制御部１２１は、最終的に目標のビットレート又は圧縮率に合わせるための制御を行い、レート制御後の符号化データをRTP部１６４に供給する。例えば、このレート制御部１２１は、ビットレートを上げる場合には量子化ステップサイズを小さくし、ビットレートを下げる場合には量子化ステップサイズを大きくするように、量子化部１６２に対して制御信号を送信する。
RTP部１６４は、レート制御部１２１から供給される符号化データをRTPパケット化し、FEC部１１２に供給する。
［復号部の構成例］
次に、上述した符号化部１１１の例に対応する復号部１３５の例について説明する。図６は、受信装置１０３の復号部１３５の構成例を示すブロック図である。図６において、復号部１３５は、RTP部１９０、エントロピ復号部１９１、逆量子化部１９２、およびウェーブレット逆変換部１９３を有する。
RTP部１９０は、FEC部１３４から供給されるRTPパケットを符号化データに変換し、それをエントロピ復号部１９１に供給する。エントロピ復号部１９１は、エントロピ符号化部１６３の符号化方法に対応する方法で符号化データを復号し、量子化係数データを生成する。例えば、ハフマン復号や、高効率な算術復号などを用いることができる。なお、エントロピ符号化部１６３においてＰラインごとに符号化されている場合、エントロピ復号部１９１は、各サブバンドを独立に復号し、かつ、各サブバンド内をＰライン毎に復号する。
逆量子化部１９２は、量子化係数データに量子化ステップサイズを乗算することにより逆量子化し、係数データを生成する。この量子化ステップサイズは、通常、送信装置１０１から供給される符号化データのヘッダなどに記述されている。なお、量子化部１６２において、ラインブロック毎に量子化ステップサイズが設定されている場合には、逆量子化部１９２においても同様に、ラインブロック毎に逆量子化ステップサイズが設定されて、逆量子化される。
ウェーブレット逆変換部１９３は、ウェーブレット変換部１６１の逆処理を行う。つまり、ウェーブレット逆変換部１９３は、ウェーブレット変換部１６１により複数の周波数帯域に分割された係数データに対して、低域成分と高域成分を合成するフィルタ処理（合成フィルタ処理）を水平方向と垂直方向の両方に対して行う。ウェーブレット逆変換部１９３は、このようはウェーブレット逆変換処理により、ベースバンドのビデオデータを復元し、ビデオOUTから受信装置１０３の外部に出力する。
もちろん、上述した符号化部１１１および復号部１３５は、一例であり、これ以外の符号化・復号方式を用いるようにしてもよい。
［伝送処理］
次に、伝送システム１００において行われる各処理について説明する。最初に、ビデオデータを送信装置１０１からネットワーク１０２を介して受信装置１０３に伝送する伝送処理について説明する。
送信装置１０１は、ビデオカメラ等を経由し、ビデオ入力IF「ビデオIN」より入力したビデオデータを、動画像データの符号化処理を行う符号化部１１１に入力し、符号化される。符号化データは、符号化部１１１内部のRTP部１６４によりRTPパケット化処理を施され出力される。出力されたRTPパケットは、FEC部１１２によりFEC冗長符号化処理を施され、RTP部１１３によりFEC冗長符号化データ用のRTPパケット化処理を施され、平滑化部１１４からRTPパケットとしてネットワーク１０２へ送信される。
各RTPパケットには、メディア同期部１１６にて指定された同期用RTPタイムスタンプがセットされる。
受信装置１０３は、送信装置１０１より送信されたRTPパケットを受信部１３１で受信し、受信バッファ１３２に保存する。このとき損失パケットが検出された場合、ARQ部１３６に通知され、ARQ部１３６により再送要求処理が行われる。
受信バッファ１３２は、受信バッファ時間決定部１３８により決定された受信バッファ時間と、メディア同期部１４０より通知される時刻情報と、各RTPパケットにセットされたRTPタイムスタンプ値とから、受信バッファ出力時刻を決定し、所定時刻に各RTPパケットをRTP部１３３に出力する。
RTP部１３３は、RTPパケットをFEC冗長符号化データへ変換する再構成処理を行い、変換したFEC冗長符号化データを、FEC部１３４へ出力する。FEC部１３４は、損失パケットの検出を行う。損失パケットが検出された場合、FEC部１３４は、冗長符号化復号処理により損失パケットデータの回復を行う。
このように処理された符号化データ（RTPパケット）は、復号部１３５に供給される。復号部１３５は、供給された符号化データのRTPパケットを変換して符号化データを生成し、その符号化データに対して復号処理を行う。復号されたビデオデータは、ビデオ出力IF「ビデオOUT」より、例えば、ディスプレイ等の映像表示装置に供給され、出力される。
［基準信号同期処理］
次に、送信装置１０１と受信装置１０３との間で基準信号の同期をとる基準信号同期処理について説明する。基準信号同期部１１５および基準信号同期部１３９は、互いに通信を行い、IEEE 1588 PTP（Precision Time Protocol）を用い、送信装置１０１と受信装置１０３との間の基準信号クロックの同期を行う。
基準信号クロックの周波数としては、例えば、入力ビデオ画像のピクセルサンプリング周波数が用いられる。また、ビデオ出力装置から出力されるビデオデータが「ビデオIN」から入力される場合、送信装置１０１とそのビデオ出力装置との間でも、基準信号の同期がとられるようにしてもよい。
なお、基準信号同期部１１５および基準信号同期部１３９による、送信装置１０１と受信装置１０３との間の基準信号の同期とりは、任意であり、装置間で基準信号の同期をとらないようにしてもよい。
［メディア同期処理］
次に、基準信号に基づいてビデオデータの同期をとるメディア同期処理について説明する。送信装置１０１におけるメディア同期部１１６は、基準信号同期部１１５より通知された時刻を基に、「ビデオIN」より入力されたデータのサンプリング時刻と同期した時刻を、RTPタイムスタンプの周波数に変換し、符号化部１１１内のRTP部１６４、およびRTP部１１３にて各RTPパケットにRTPタイムスタンプとして付加する。
受信装置１０３におけるメディア同期部１４０は、基準信号同期部１３９より通知された基準クロック時刻情報をRTPタイムスタンプ周波数に変換したシステム時刻として保持する。
受信装置１０３における受信バッファ１３２にRTPパケットが記録されると、受信バッファ１３２は、RTPパケットのRTPタイムスタンプ値と、受信バッファ時間設定部１３８より通知された受信バッファ時間と、メディア同期部１４０から供給されるRTPタイムスタンプ周波数時刻とから、各RTPパケットの受信バッファ出力時刻を決定する。
RTPパケットの受信バッファ出力時刻は、例えば、以下のように決定される。ストリームデータの先頭パケットは、受信した時刻から受信バッファ時間TSTIME_BUFが経過した時刻後に受信バッファから出力されるものとする。これに対して、後続パケットは、先頭パケットのRTPタイムスタンプ値と当該パケットのRTPタイムスタンプ値との差分値から算出される時刻に同期出力される。
RTPパケットnの受信バッファ出力時刻TSSYS_BO_nは、例えば、以下の式（１）により算出される。ストリーム先頭パケットのRTPタイムスタンプ値をTSPKT_initとし、受信時刻（システム時刻換算：周波数はRTPタイムスタンプ周波数）をTSSYS_initとし、RTPパケットnのRTPタイムスタンプ値をTSPKT_nとする。
TSSYS_BO_n＝（TSPKT_n−TSPKT_init）＋TSSYS_init＋TSTIME_BUF ・・・（１）
［符号化処理・復号処理］
次に、送信装置１０１および受信装置１０３が行うビデオデータのコーデック処理（符号化処理および復号処理）について説明する。符号化部１１１は、例えば特許文献１において提案されている動画像の各ピクチャの数ライン毎を１つの符号化ブロックとしてウェーブレット変換を行う階層符号化方式であり、かつ、階層毎に関連する入力データ範囲の異なる符号化方式を用いる。
符号化部１１１が符号化処理を行って符号化データを生成し、復号部１３５がその符号化データを復号する復号処理を行う。
符号化部１１１は、上述したようにレート制御部１２１を有する。レート制御部１２１は、例えば、ITU-T Y.1221記載のトークンバケットビヘビアにおける、バケツサイズをエンコーダ想定バッファサイズＢ（byte）、バケットレートＲ（bps）をエンコードレートとして、バケットがあふれないようにエンコードレートを制御するレート制御を行う。これを平滑化伝送したときに受信装置１０３において必要となるバッファ時間を「可変圧縮符号化遅延要求時間」と称する。
可変圧縮符号化遅延要求時間Bt_codec_req(sec)は、例えば、以下の式（２）のように算出される。
Bt_codec_req＝Ｂ×８／Ｒ ・・・（２）
エンコーダ想定バッファサイズＢは、ユーザ等により指定される画像品質要求に応じて決定される。VBR方式による圧縮符号化の場合、エンコーダ想定バッファサイズＢを大きくとることにより、複雑度の高い画像部分により多くのデータ量を使用することができ、画質を向上させることができる。つまり、画像品質要求が高い場合、このエンコーダ想定バッファサイズＢを大きくとることでその高い要求に応じることができる。
ただし、エンコーダ想定バッファサイズＢを大きくとると、可変圧縮符号化遅延要求時間Bt_codec_req(sec)が大きくなるので、遅延が増加する恐れがある。
［RTCP処理］
次に、送信装置１０１と受信装置１０３との間で行われるQoS制御処理のRTCP処理について説明する。RTCP部１１７およびRTCP部１３７は、IETF RFC 3550記載のRTCPを用いて、送信装置１０１と受信装置１０３との間でRTCPメッセージの送受信を行い、パケット損失率、往復伝搬遅延（RTT）、およびネットワークジッタ等の情報収集や、QoS制御処理のための制御メッセージの送受信を行う。QoS制御メッセージとしては、例えば、ARQ処理における再送要求メッセージ等がある。
［FEC処理］
次に、QoS制御処理のFEC処理について説明する。FEC部１１２は、符号化部１１１から供給される符号化データのRTPパケットを単位として、FEC冗長符号化を行う。例えば、FEC部１１２は、Reed-Solomon符号等の消失誤り訂正符号を用い冗長符号化を行う。
FEC冗長符号化における冗長度は、例えば、ユーザ等により指定される伝送品質要求により決定される。冗長度は、（元データパケット数，冗長パケット数）という形で指定される。ユーザは、また、ネットワークの想定パケット損失率pも指定する。
以下においては、（元データパケット数，冗長パケット数）の組を１つの冗長符号単位（所謂FECブロック）とする。例えば、（元データパケット数，冗長パケット数）＝（10,5）と指定された場合、送信装置１０１のFEC部１１２は、元データパケット数10個に対して、冗長パケットを５個生成する。つまり、このFECブロックにおいては合計15個のパケットが送信される。
この場合、受信装置１０３のFEC部１３４は、このFECブロックパケット中任意の10個のパケットを受信すれば、FEC復号処理により元データを復号することができる。例えば、ユーザにより指定されたパケット損失率をpとし、FECブロック内のパケット数をnとし、元データパケット数をｋとし、冗長パケット数をn-kとし、ユーザにより伝送品質要求として指定される目標FECブロック損失率をPtとすると、目標FECブロック損失率Ptは、以下の式（３）のように表される。
Figure 0005598155
 ・・・（３）
この式（３）を満たすように元データパケット数kおよび冗長パケット数n-kが決定される。
受信装置１０３（FEC部１３４）では、FEC冗長復号化処理により損失パケット回復を行うために、FECブロックの先頭パケットが受信装置１０３に到着してから末尾のパケットが到着するまでの時間（所謂、冗長符号化ブロック受信待ち時間）以上に受信バッファ時間を設定する必要がある。
ユーザ等により指定される伝送品質要求に応じて設定されたFECブロックに対応する冗長符号化ブロック受信待ち時間を「冗長符号化ブロック受信待ち要求時間」と称する。
［ARQ処理］
受信装置１０３におけるARQ処理では、受信部１３１がRTPパケットのシーケンス番号を利用して損失したパケットを検知し、ARQ部１３６がその損失パケットの再送要求メッセージを生成し、RTCP部１３７が、送信装置１０１に対してその再送要求メッセージを送信し、再送要求を行う。
なお、受信装置１０３のARQ部１３６が、パケット損失に対して再送要求を行い、往復伝搬時間（ARQ再送パケット待ち時間）経過しても受信部１３１が再送パケットを受信しなかった場合、再度、再送要求を行うようにしてもよい。さらに、ARQ部１３６が、当該パケットの受信バッファ出力時刻に再送パケット到着が間に合わないと決定されるまで、このような再送要求を繰り返すようにしてもよい。
送信装置１０１におけるARQ処理では、RTCP部１１７が再送要求メッセージを受け取ると、ARQ部１１８が再送すべきRTPパケット（再送パケット）を生成し、その再送パケットを平滑化部１１４に供給し、再送させる。
ARQ処理における回復性能は、受信装置１０３における、ARQ部１３６の要求により再送される再送パケットを待つ時間であるARQ再送パケット待ち時間に依存する。ARQ再送パケット待ち時間が大きいほど回復性能は向上するが、ARQ再送パケット待ち要求時間以上の受信バッファ時間が必要となるので、遅延が増大する恐れがある。
この「ARQ再送パケット待ち要求時間」は、ユーザ等により指定される伝送品質要求により決定される。
［ネットワークジッタ対応処理］
受信装置１０３の受信バッファ１３２は、ネットワークジッタ対応処理機構も兼ね備える。受信バッファ１３２は、ユーザ等により指定される伝送品質要求により決定された「ネットワークジッタ対応バッファ要求時間」以上の時間を受信バッファ時間としてセットする。これにより「ネットワークジッタ対応バッファ要求時間」以下のジッタを受けたパケットの同期処理が可能となる。
［データ伝送全体処理］
次に、伝送システム１００において実行されるデータ伝送処理の全体の流れの例を、図７のフローチャートを参照して説明する。
受信装置１０３の受信バッファ時間設定部１３８は、入力部１４１および出力部１４２を制御して、ステップＳ１２１において、画像品質要求および伝送品質要求を受け付ける。
受信バッファ時間設定部１３８は、例えば、出力部１４２のモニタに、図８に示されるようなGUIを表示し、入力部１４１を制御し、そのGUIに基づいて行われるユーザ操作を受け付ける。
図８は、画像品質要求および伝送品質要求等を受け付けるGUIである要求受付画面の表示例を示す図である。図８に示されるように、要求受付画面２０１には、表示部２０２と要求部２０３とが設けられている。要求部２０３は、ユーザにより入力可能な項目が示される。表示部２０２には、ユーザにより情報が入力された結果が表示される。
要求部２０３には、例えば、「使用者要求」として、「画質要求」（画像品質要求）や「伝送品質要求」を入力することができることが示されている。例えば、画像品質を指定する場合、ユーザは、「画質要求」を選択し、要求する品質（例えばPSR値等）を入力する。また、例えば、伝送品質を指定する場合、ユーザは、「伝送品質要求」を選択し、要求する品質（例えばQoS制御後パケット損失率等）を入力する。
なお、要求部２０３においては、ユーザは、受信バッファ時間を指定することもできる。例えば、ユーザが、「受信バッファ時間」を選択し、要求する時間を入力することにより、「受信バッファ時間」として許容される最長の時間が設定される。
表示部２０２には、このように要求部２０３において入力された情報が反映された各種情報が表示される。
例えば、表示部２０２には、「ネットワーク状況」として「伝送遅延」、「パケット損失率」、および「ネットワークジッタ」等が表示される。
また、例えば、表示部２０２には、「処理要求時間」として「可変圧縮符号化遅延要求時間」、「冗長符号化ブロック受信待ち時間」、「ARQ再送パケット待ち要求時間」、および「ネットワークジッタ対応バッファ要求時間」等が表示される。
さらに、例えば、表示部２０２には、受信バッファ時間として推奨される「推奨受信バッファ時間」が表示される。
このようなGUIに基づいて要求を入力することにより、ユーザは、画像品質要求、伝送品質要求、および受信バッファ時間等をより容易に設定することができる。
図７に戻り、画像品質要求や伝送品質要求が受け付けられると、受信バッファ時間設定部１３８は、ステップＳ１２２において受信バッファ時間決定処理を行い、ARQ部１３６や受信バッファ１３２の設定を行ったり、RTCP部１３７を介して、決定した情報等を送信装置１０１に通知したりする。
送信装置１０１の受信バッファ時間・処理パラメータ設定部１１９は、RTCP部１１７を介してこの通知を受け取ると、ステップＳ１０１において、その通知に基づいて受信バッファ時間・処理パラメータ設定処理を行い、符号化部１１１やFEC部１１２の設定を行う。
設定が終了すると、送信装置１０１の各部は、ステップＳ１０２において、受信装置１０３と連携してデータ伝送（データ送信）を行う。この処理に対応して、受信装置１０３の各部は、ステップＳ１２３において、送信装置１０１と連携してデータ伝送（データ受信）を行う。
これらのデータ伝送においては、上述した各種処理が適宜行われる。
以上のように、送信装置１０１および受信装置１０３は、互いに連携し、ユーザ等により指定される画像品質要求や伝送品質要求に応じて、各部の設定を行う。これにより、送信装置１０１および受信装置１０３は、各処理の遅延時間を最適化し、各処理の時間的余裕を画質や伝送品質の向上に利用し、遅延時間上の無駄を低減させることができる。つまり、コンテンツの品質の劣化を抑制することができる。
［受信バッファ時間決定処理］
次に、図７のステップＳ１２２において実行される受信バッファ時間決定処理の流れの例を図９のフローチャートを参照して説明する。
受信バッファ時間決定処理が開始されると、受信バッファ時間設定部１３８は、ステップＳ１４１において、ユーザ等からの画像品質要求や伝送品質要求に基づいて、各種遅延時間や待ち時間等を設定する。
例えば、受信バッファ時間設定部１３８は、画像品質要求や伝送品質要求の設定値から、「可変圧縮符号化遅延時間」として要求される時間である「可変圧縮符号化遅延要求時間」、「冗長符号化ブロック受信待ち時間」として要求される時間である「冗長符号化ブロック受信待ち要求時間」、「ARQ再送パケット待ち時間」として要求される時間である「ARQ再送パケット待ち要求時間」、および、「ネットワークジッタ対応バッファ時間」として要求される時間である「ネットワークジッタ対応バッファ要求時間」を計算する。
従来の方法の場合、これらの値がそのまま設定値として使用されていたが、受信バッファ時間設定部１３８は、これらの値を、その最大値に揃えるように再設定する。受信バッファ時間設定部１３８は、ステップＳ１４２において、以下の式（４）に示されるように、「可変圧縮符号化遅延要求時間」、「冗長符号化ブロック受信待ち要求時間」、「ARQ再送パケット待ち要求時間」、および「ネットワークジッタ対応バッファ要求時間」の最大値を「受信バッファ時間」として設定する。
「受信バッファ時間」＝MAX（「可変圧縮符号化遅延要求時間」，「冗長符号化ブロック受信待ち要求時間」，「ARQ再送パケット待ち要求時間」，「ネットワークジッタ対応バッファ要求時間」）
・・・（４）
式（４）において、MAX（）は、最大値を計算する関数である。
「受信バッファ時間」を算出すると、受信バッファ時間設定部１３８は、ステップＳ１４３において、以下の式（５）に示されるように、その「受信バッファ時間」を、「可変圧縮符号化遅延時間」、「冗長符号化ブロック受信待ち時間」、「ARQ再送パケット待ち時間」、および「ネットワークジッタ対応バッファ時間」として設定する。
「可変圧縮符号化遅延時間」＝「冗長符号化ブロック受信待ち時間」＝「ARQ再送パケット待ち時間」＝「ネットワークジッタ対応バッファ時間」＝「受信バッファ時間」
・・・（５）
例えば、可変圧縮符号化遅延要求時間２２１、冗長符号化ブロック受信待ち要求時間２２２、ARQ再送パケット待ち要求時間２２３、および、ネットワークジッタ対応バッファ要求時間２２４が、図１０の左に示されるような長さであるとする。
この場合、可変圧縮符号化遅延要求時間２２１が最も長いので、図１０右に示されるように、受信バッファ時間２４１は、この可変圧縮符号化遅延要求時間２２１と同じ長さに設定される。可変圧縮符号化遅延時間２３１、冗長符号化ブロック受信待ち時間２３２、ARQ再送パケット待ち時間２３３、および、ネットワークジッタ対応バッファ時間２３４は、それぞれ、この受信バッファ時間２４１に揃えられる。
つまり、この場合、冗長符号化ブロック受信待ち時間２３２、ARQ再送パケット待ち時間２３３、および、ネットワークジッタ対応バッファ時間２３４は、それぞれ、要求された時間よりも長くなるように設定される。
図９に戻り、以上のように、各時間が設定されると、受信バッファ時間設定部１３８は、ステップＳ１４４において、「ARQ再送パケット待ち時間」を、ARQ部１３６に設定し、再送要求を行うかどうかの判定に使用させる。
また、ステップＳ１４５において、受信バッファ時間設定部１３８は、「ネットワークジッタ対応バッファ時間」を受信バッファ１３２に設定する。
さらに、ステップＳ１４６において、受信バッファ時間設定部１３８は、「画像品質要求」、「伝送品質要求」、「可変圧縮符号化遅延時間」、および「冗長符号化ブロック受信待ち時間」を、例えば、RTCP部１３７を介して、RTCPメッセージとして送信装置１０１へ通知する。
通知が終了すると、受信バッファ時間設定部１３８は、受信バッファ時間決定処理を終了し、処理を図７のステップＳ１０２に戻し、ステップＳ１０３に処理を進める。
［受信バッファ時間・処理パラメータ設定処理］
次に、図１１のフローチャートを参照して、図７のステップＳ１０１において実行される受信バッファ時間・処理パラメータ設定処理を説明する。
受信バッファ時間・処理パラメータ設定処理が開始されると、受信バッファ時間・処理パラメータ設定部１１９は、ステップＳ１６１において、RTCP部１１７を介して、受信装置１０３から供給されるRTCPメッセージに含まれる「画像品質要求」、「伝送品質要求」、「可変圧縮符号化遅延時間」、および「冗長符号化ブロック受信待ち時間」を取得する。
ステップＳ１６２において、受信バッファ時間・処理パラメータ設定部１１９は、「可変圧縮符号化遅延時間」を符号化部１１１に設定する。ステップＳ１６３において、受信バッファ時間・処理パラメータ設定部１１９は、「冗長符号化ブロック受信待ち時間」をFEC部１１２に設定する。
レート制御部１２１は、ステップＳ１６４において、供給された「画像品質要求」や「可変圧縮符号化遅延時間」を用いて、レート制御パラメータを設定する。例えば、レート制御部１２１は、以下の式（６）を満たすように、エンコーダ想定バッファサイズＢ(byte)を設定する。なお、式（６）において、Bt_codec(sec)は可変圧縮符号化遅延時間を示す。また、Ｒ（bps）はパケットレートを示す。
Bt_codec＝Ｂ×８／Ｒ ・・・（６）
FEC部１１２は、ステップＳ１６５において、「伝送品質要求」および「冗長符号化ブロック受信待ち時間」を用いてFECブロックパラメータを設定する。「冗長符号化ブロック受信待ち時間」は、FECブロックに含まれるパケット全ての平滑化伝送にかかる時間の最大値である。FEC部１１２は、この時間が「冗長符号化ブロック受信待ち時間」以下となるように、FECブロック毎の元データパケット数を調整する。さらに、FEC部１１２は、例えば、上述した式（３）を満たすように、冗長パケット数ｎ−ｋを設定する。
ステップＳ１６５の処理が終了すると、受信バッファ時間・処理パラメータ設定部１１９は、受信バッファ時間・処理パラメータ設定処理を終了し、処理を図７のステップＳ１０１に戻し、ステップＳ１０２の処理を行う。
以上のように各種設定を行うことにより、送信装置１０１および受信装置１０３は、遅延を増大させない程度に、各遅延時間や待ち時間をできるだけ長く確保することができ、その時間的余裕を、画像品質や伝送品質の向上に利用することができる。
より具体的には、送信装置１０１は、遅延を増大させない程度に、符号化部１１１の「可変圧縮符号化遅延時間」をより長く設定し、エンコーダ想定バッファサイズＢ(byte)をより大きく設定することができる。また、送信装置１０１は、遅延を増大させない程度に、FEC部１１２の「冗長符号化ブロック受信待ち時間」をより長く設定し、FECブロックや冗長度をより大きく設定することができる。
受信装置１０３は、遅延を増大させない程度に、ARQ部１３６の「ARQ再送パケット待ち時間」をより長く設定することができる。また、受信装置１０３は、遅延を増大させない程度に、受信バッファ１３２の「ネットワークジッタ対応バッファ時間」をより長く設定することができる。
以上のように、送信装置１０１および受信装置１０３は、各処理の時間的余裕を活用し、画質や伝送品質の向上に利用することにより、遅延時間上の無駄を低減させることができる。つまり、送信装置１０１および受信装置１０３は、上述したようなデータ伝送に関する各種処理によるコンテンツの品質の劣化を抑制することができる。
＜２．第２の実施の形態＞
［データ伝送全体処理の他の例］
以上においては、ユーザ等の要求のみにより受信バッファ時間や処理パラメータが決定されるように説明したが、これに限らず、ネットワーク１０２の通信に関する状況に応じて受信バッファ時間や処理パラメータの設定が行われるようにしてもよい。
その場合、ネットワーク１０２の通信に関する状況（ネットワーク状況情報）は、RTCP部１１７とRTCP部１３７との間で行われるパケットの授受によって観測される。したがって、送信装置１０１と受信装置１０３の構成は、上述した第１の実施の形態（図１）の場合と同様である。
さらに、このようなネットワーク状況情報の測定を、データ伝送中に繰り返し行い、その最新のネットワーク状況に応じて、受信バッファ時間や処理パラメータの設定が更新されるようにしてもよい。
この場合も、RTCP部１１７およびRTCP部１３７は、上述した第１の実施の形態において説明した場合と基本的に同様の処理を行う。ただし、この場合、RTCP部１１７は、符号化データの伝送を開始する前に、ネットワーク状況事前計測用のダミーデータを送信する。そのダミーデータは、ネットワーク１０２を介してRTCP部１３７に伝送される。RTCP部１３７は、そのダミーデータを受信し、パケットに記述される送信時の情報と、受信時の状況からネットワーク状況の計測（事前計測）を行う。
符号化データの伝送開始後においては、RTCP部１３７は、伝送される符号化データのRTPパケットによりネットワーク状況情報の計測を行う。
この場合のデータ伝送処理の流れの例を図１２のフローチャートを参照して説明する。受信装置１０３の受信バッファ時間設定部１３８が、ステップＳ２２１において、図７のステップＳ１２１の場合と同様に、画像品質要求および伝送品質要求を受け付けると、RTCP部１３７は、ステップＳ２２２において、RTCP部１１７とダミーデータ等の各種データの授受を行い、ネットワーク状況を測定し、そのネットワーク状況情報をRTCP部１１７と共有する。送信装置１０１のRTCP部１１７は、ステップＳ２０１において、このステップＳ２２２の処理に対応する処理を行う。
ネットワーク状況を測定すると受信装置１０３の受信バッファ時間設定部１３８は、受信バッファ時間決定処理を行う。この処理は、基本的に図９のフローチャートを参照して説明した場合と同様に行われる。
ただし、受信バッファ時間設定部１３８は、ステップＳ１４１において、画像品質要求と伝送品質要求だけでなく、ステップＳ２２２においてRTCP部１３７より取得したネットワーク状況情報にも基づいて、各種要求時間を算出する。
例えば、パケット損失率が高い場合、「ARQ再送パケット待ち要求時間」は、回復性能を向上させるような値に設定される。また、例えば、パケット損失率が高い場合、「冗長符号化ブロック受信待ち要求時間」は、式（３）を満たし、指定された冗長度以下に保つ元データパケット数および冗長パケット数に合わせた値に設定される。
また、「ネットワークジッタ対応バッファ要求時間」は、実際に測定されたネットワークジッタ以上の値に設定される。
このように設定された要求時間に応じて、各種遅延時間や待機時間等が設定される。送信装置１０１の受信バッファ時間・処理パラメータ設定部１１９は、ステップＳ２０２において、受信バッファ時間・処理パラメータ設定処理を行う。この処理は、基本的に図１１のフローチャートを参照して説明した場合と同様に行われる。
つまり、受信バッファ時間・処理パラメータ設定部１１９は、RTCP部１１７により取得されたネットワーク状況情報も利用して冗長度やFECブロックサイズを決定する。符号化データの伝送開始前において、受信バッファ時間・処理パラメータ設定部１１９は、RTCP部１１７により計測されたネットワーク状況事前計測情報に含まれるパケット損失率pを用い、式（３）を満たすように、元データパケット数kや冗長パケット数n-kを決定する。
各種パラメータの設定が終了すると、受信装置１０３の各部は、ステップＳ２２４において、受信バッファ時間等各種設定を動的に更新しながらデータ伝送を行う受信バッファ動的変更伝送処理を行う。この処理に対応して、送信装置１０１の各部は、ステップＳ２０３において、受信バッファ動的変更伝送処理を行う。
［受信バッファ動的変更伝送処理］
図１３のフローチャートを参照して、送信装置１０１および受信装置１０３により行われる受信バッファ動的変更伝送処理の流れの例を説明する。
ステップＳ２４１において、送信装置１０１の各部は、一定時間データ転送を行う。この処理に対応して、受信装置１０３の各部は、ステップＳ２６１において、一定時間データ転送を行う。
受信装置１０３のRTCP部１３７は、ステップＳ２６２において、RTCP部１１７とデータの送受信を行い、ネットワーク状況を測定し、ネットワーク状況情報を更新する。この処理に対応して、送信装置１０１のRTCP部１１７は、ステップＳ２４２において、ネットワーク状況を測定し、ネットワーク状況情報を更新する。
ステップＳ２６３において、受信装置１０３の受信バッファ時間設定部１３８は、更新されたネットワーク状況情報に基づいて、受信バッファ時間決定処理を行い、「可変圧縮符号化遅延要求時間」、「冗長符号化ブロック受信待ち要求時間」、「ARQ再送パケット待ち要求時間」、および「ネットワークジッタ対応バッファ要求時間」等を更新し、その更新された各種要求時間に応じて、「可変圧縮符号化遅延時間」、「冗長符号化ブロック受信待ち時間」、「ARQ再送パケット待ち時間」、および「ネットワークジッタ対応バッファ時間」等の設定を、例えば式（４）や式（５）を用いて更新する。
この受信バッファ時間決定処理は、図１２のステップＳ２２３の場合と同様に行われる。
この処理に対応し、ステップＳ２４３において、送信装置１０１の受信バッファ時間・処理パラメータ設定部１１９は、受信バッファ時間・処理パラメータ設定処理を行う。この処理は、図１２のステップＳ２０２の場合と同様に行われる。
符号化データの伝送開始後の場合、受信バッファ時間・処理パラメータ設定部１１９は、符号化データ伝送を利用してRTCP部１１７により計測されたネットワーク状況情報に含まれるパケット損失率pを用い、式（３）を満たすように、元データパケット数kや冗長パケット数n-kを決定する。
ステップＳ２４４において、送信装置１０１は、伝送を終了するか否かを判定し、伝送を終了すると判定された場合、処理をステップＳ２４１に戻し、それ以降の処理を実行させる。また、ステップＳ２４４において、伝送を終了すると判定された場合、送信装置１０１による受信バッファ動的変更伝送処理が終了される。
また、ステップＳ２６４において、受信装置１０３は、伝送を終了するか否かを判定し、伝送を終了すると判定された場合、処理をステップＳ２６１に戻し、それ以降の処理を実行させる。また、ステップＳ２６４において、伝送を終了すると判定された場合、受信装置１０３による受信バッファ動的変更伝送処理が終了される。
以上のように、ユーザ等からの要求だけでなく、ネットワーク状況にも応じて、パラメータ等の設定を行うようにすることにより、送信装置１０１および受信装置１０３は、より実際の状況に応じてより効率よく画質や伝送品質の設定を行うことができ、遅延時間上の無駄をより低減させることができる。つまり、送信装置１０１および受信装置１０３は、コンテンツの品質の劣化を抑制することができる。
＜３．第３の実施の形態＞
［伝送システムの構成］
以上においては、送信装置と受信装置が１対１に構成されるシステムについて説明したが、これに限らず、伝送システムを構成する送信装置と受信装置の数は任意である。例えば、複数の送信装置から送信される符号化データを１つの受信装置が受信するようにしてもよい。
図１４は、その場合の伝送システムの構成例を示す図である。図１４に示される伝送システム３００は、基本的に伝送システム１００と同様のシステムであるが、伝送システム１００の場合と異なり、送信装置を複数有する（送信装置１０１−１乃至送信装置１０１−Ｎ（Ｎは２以上の整数））。
送信装置１０１−１乃至送信装置１０１−Ｎは、それぞれ、上述した送信装置１０１と同様の構成を有し、同様の処理を行う。送信装置１０１−１乃至送信装置１０１−Ｎを互いに区別して説明する必要が無い場合、単に送信装置１０１と称する。
伝送システム３００は、受信装置１０３の代わりに、各送信装置１０１から送信されるRTPパケットを受信する１つの受信装置３０３を有する。
図１４に示されるように、受信装置３０３は、伝送部３１１、基準信号同期部３１２、受信部３１３−１乃至受信部３１３−Ｎ、統合受信バッファ時間調整部３１４、および合成部３１５を有する。
伝送部３１１は、各送信装置１０１と通信を行い、基準信号同期部３１２や受信部３１３−１乃至受信部３１３−Ｎから供給される情報を送信したり、各送信装置１０１から供給される情報を受信し、基準信号同期部３１２や受信部３１３−１乃至受信部３１３−Ｎに供給したりする。
基準信号同期部３１２は、送信装置１０１の基準信号同期部１１５と通信を行い、基準信号の同期をとる。同期がとられた基準信号は、受信部３１３−１乃至受信部３１３−Ｎに供給される。
このように、送信装置１０１が複数存在する場合、例えば、受信装置３０３の基準信号同期部３１２がマスタとなり、全ての送信装置１０１が受信装置３０３と同期を取ることにより結果的に全ての送信装置１０１および受信装置３０３の同期を取ることができる。
受信部３１３−１乃至受信部３１３−Ｎは、それぞれ、送信装置１０１−１乃至送信装置１０１−Ｎに対応し、対応する送信装置１０１から供給されたRTPパケットを受信し、復号してビデオデータを出力する。以下において、受信部３１３−１乃至受信部３１３−Ｎを互いに区別して説明する必要が無い場合、単に、受信部３１３と称する。つまり、受信部３１３は、送信装置１０１以上の数が予め用意される。換言するに、受信装置３０３は、内蔵する受信部３１３の数以下の送信装置１０１から送信されるパケットを受信することができる。
統合受信バッファ時間調整部３１４は、各受信部３１３の受信バッファ時間を揃える。合成部３１５は、各受信部３１３から出力されるビデオデータを合成し、合成されたビデオデータを、受信装置３０３のビデオ出力端子「ビデオOUT」から出力する。
［受信部］
図１５は、受信部３１３の主な構成例を示すブロック図である。図１５に示されるように、受信部３１３は、上述した受信装置１０３と基本的に同様の構成を有する。ただし、受信部３１３は、受信装置１０３が有する基準信号同期部１３９を有さない。また、受信部３１３は、受信装置１０３が有する受信バッファ時間設定部１３８の代わりに、受信バッファ時間設定部３３８を有する。
メディア同期部１４０は、受信部３１３の外部の基準信号同期部３１２より供給される基準信号、すなわち、各送信装置１０１と各受信部３１３において同期がとれた基準信号を用いて、受信バッファ１３２や復号部１３５におけるRTPパケットの処理タイミングを制御する。
受信バッファ時間設定部３３８は、受信バッファ時間設定部１３８と同様に、ユーザ等により設定された画像品質要求や伝送品質要求、並びに、RTCP部１３７により収集されたネットワーク状況情報等に基づいて、各種時間やパラメータ等の設定を行う。
なお、受信バッファ時間設定部３３８が設定した各種時間は、後述するように、統合受信バッファ時間調整部３１４により、受信部３１３間で調整される。
また、入力部１４１および出力部１４２は、各受信部３１３で共有するようにしてもよい。例えば、ユーザが、どの受信部３１３に対して画像品質要求や伝送品質要求を入力する場合であっても、同じ入力部１４１および出力部１４２を用いるようにするようにしてもよい。画像品質要求や伝送品質要求の設定対象とする受信部３１３の切り替え制御方法は任意である。例えばGUIにそのような切り替えボタンを設けるようにしてもよい。また、ユーザが、複数の受信部３１３に対して、画像品質要求や伝送品質要求の設定を一度に行うことができるようにしてもよい。
［データ伝送全体処理］
図１６のフローチャートを参照して、この場合のデータ伝送処理の流れの例を説明する。
ステップＳ３２１において、受信装置３０３の各受信部３１３の受信バッファ時間設定部３３８は、画像品質要求や伝送品質要求を受け付ける。ステップＳ３２２において、受信装置３０３の各受信部３１３のRTCP部１３７は、それぞれ、自分自身が対応する送信装置１０１のRTCP部１１７と通信を行い、ネットワーク状況を測定し、ネットワーク状況情報を生成する。
この処理に対応して、各送信装置１０１のRTCP部１１７は、ネットワーク状況の測定を行い、ネットワーク状況情報を取得する。
これらの情報を基に、ステップＳ３２３において、受信装置３０３の各受信部３１３の受信バッファ時間設定部３３８は、受信バッファ時間の仮設定を行う仮受信バッファ時間決定処理を行う。
各受信部３１３において仮受信バッファ時間が決定されると、ステップＳ３２４において、統合受信バッファ時間調整部３１４と各受信部３１３の受信バッファ時間設定部３３８は、連携して、統合受信バッファ時間決定処理を行い、各仮受信バッファ時間を調整した受信バッファ時間を設定する。
ステップＳ３２５において、伝送部３１１は、以上の処理により得られた各種情報（例えば、画像品質要求、伝送品質要求、可変圧縮符号化遅延時間、および冗長符号化ブロック受信待ち時間等）を、各送信装置１０１に通知する。各送信装置１０１は、ステップＳ３０２において、この通知を取得し、受信バッファ時間・処理パラメータ設定処理を行う。
各送信装置１０１および受信装置３０３は、ステップＳ３０３およびステップＳ３２６において、受信バッファ動的変更処理を行い、最新のネットワーク状況を測定し、その状況に基づいて各種設定を更新しながらデータ伝送を行う。
なお、以上においては、受信バッファ時間を、画像品質要求、伝送品質要求、およびネットワーク状況に基づいて設定するように説明したが、これに限らず、第１の実施の形態のように、画像品質要求と伝送品質要求のみに基づいて受信バッファ時間を設定するようにしてもよい。その場合、ステップＳ３２２やステップＳ３０１の処理が省略される。
［仮受信バッファ時間決定処理］
次に、図１７のフローチャートを参照して、仮受信バッファ時間決定処理の流れの例を説明する。
ステップＳ３４１において、受信装置３０３は、送信装置１０１と対応し、データ伝送に使用する受信部３１３の内、未処理のものの中から、処理対象とする受信部３１３を選択する。その処理対象の受信部３１３の受信バッファ時間設定部３３８は、ステップＳ３４２において、画像品質要求、伝送品質要求、およびネットワーク状況情報等に基づいて、「可変圧縮符号化遅延要求時間」、「冗長符号化ブロック受信待ち要求時間」、「ARQ再送パケット待ち要求時間」、および「ネットワークジッタ対応バッファ要求時間」を算出する。
また、受信バッファ時間設定部３３８は、ステップＳ３４３において、「可変圧縮符号化遅延要求時間」、「冗長符号化ブロック受信待ち要求時間」、「ARQ再送パケット待ち要求時間」、および「ネットワークジッタ対応バッファ要求時間」の最大値を仮受信バッファ時間として設定する。
ステップＳ３４４において、受信装置３０３は、全ての受信部３１３に対して処理を行ったか否かを判定し、未処理の受信部３１３が存在すると判定した場合、処理をステップＳ３４１に戻し、新たな受信部３１３を処理対象として選択し、それ以降の処理を繰り返す。
また、ステップＳ３４４において、データ伝送に用いる全ての受信部３１３を処理したと判定された場合、受信装置３０３は、仮受信バッファ時間決定処理を終了し、処理を図１６のステップＳ３２３に戻し、ステップＳ３２４の処理を行う。
［統合受信バッファ時間決定処理］
次に、図１６のステップＳ３２４において実行される統合受信バッファ時間決定処理の流れの例を、図１８のフローチャートを参照して説明する。
ステップＳ３６１において、統合受信バッファ時間調整部３１４は、各受信部３１３において設定された仮受信バッファ時間を取得し、以下の式（７）に示されるように、各受信部３１３について、仮受信バッファ時間と伝送遅延の和を求め、その和の最大値を統合受信バッファ時間に設定する。
統合受信バッファ時間＝MAX（仮受信バッファ時間１＋伝送遅延時間１，仮受信バッファ時間２＋伝送遅延時間２，・・・，仮受信バッファ時間N＋伝送遅延時間N）
・・・（７）
例えば、図１９の上部に示されるように、送信装置１０１において行われる処理による遅延時間を送信装置処理遅延３５１とし、ネットワーク１０２を介したデータ伝送による遅延時間を伝送遅延３５２とし、受信装置３０３に設定される仮の受信バッファ時間を仮受信バッファ時間３５３とする。
図１９の上部に示されるように、送信装置１０１−１の送信装置処理遅延３５１を送信装置処理遅延３５１−１とし、送信装置１０１−１の伝送遅延３５２を伝送遅延３５２−１とし、送信装置１０１−１の仮受信バッファ時間３５３を仮受信バッファ時間３５３−１とする。
また、送信装置１０１−２の送信装置処理遅延３５１を送信装置処理遅延３５１−２とし、送信装置１０１−２の伝送遅延３５２を伝送遅延３５２−２とし、送信装置１０１−２の仮受信バッファ時間３５３を仮受信バッファ時間３５３−２とする。
以下、各送信装置１０１に対して同様にして、送信装置１０１−Ｎの送信装置処理遅延３５１を送信装置処理遅延３５１−Ｎとし、送信装置１０１−Ｎの伝送遅延３５２を伝送遅延３５２−Ｎとし、送信装置１０１−Ｎの仮受信バッファ時間３５３を仮受信バッファ時間３５３−Ｎとする。
なお、説明の便宜上、送信装置処理遅延３５１−１乃至送信装置処理遅延３５１−Ｎは、互いに同じ長さとする。
この場合、仮受信バッファ時間と伝送遅延の和は、送信装置１０１−１のものが最大であるので、その和が統合受信バッファ時間に設定される。
図１８に戻り、ステップＳ３６２において、統合受信バッファ時間調整部３１４は、いずれかの送信装置１０１に対応し、データ伝送に用いる受信部３１３の内、未処理のものの中から、処理対象とする受信部３１３を選択する。
ステップＳ３６３において、その処理対象に選択された受信部３１３の受信バッファ時間設定部３３８は、以下の式（８）に示されるように、ステップＳ３６１において設定された統合受信バッファ時間と伝送遅延との差を受信バッファ時間に設定する。
受信バッファ時間Ｋ＝統合受信バッファ時間−伝送遅延Ｋ ・・・（８）
図１９の例の場合、送信装置１０１−１の伝送遅延３５２−１と仮受信バッファ時間３５３−１の和が最大であるので、式（７）および式（８）により、送信装置１０１−１の受信バッファ時間３５４−１は、図１９の下段に示されるように、仮受信バッファ時間３５３−１と同一に設定される。
送信装置１０１−２の受信バッファ時間３５４−２、・・・、送信装置１０１−Ｎの受信バッファ時間３５４−Ｎも、それぞれ、同様に算出される。その結果、図１９の下段に示されるように、各送信装置１０１の送信装置処理遅延３５１、伝送遅延３５２、および受信バッファ時間３５４の和は、互いに同一となる。
つまり、各送信装置１０１の受信バッファ時間３５４は、遅延が増大しない程度に、より長くなるように設定される。
図１８に戻り、ステップＳ３６４において、処理対象の受信部３１３の受信バッファ時間設定部３３８は、式（５）のように、ステップＳ３６３において設定した受信バッファ時間を、可変圧縮符号化遅延時間、冗長符号化ブロック受信待ち時間、ARQ再送パケット待ち時間、およびネットワークジッタ対応バッファ時間として設定する。
これにより、各遅延時間や待ち時間が、遅延が増大しない程度に、より長くなるように設定される。
ステップＳ３６５において、受信バッファ時間設定部３３８は、ARQ部１３６に、ARQ再送パケット待ち時間を設定する。ステップＳ３６６において、受信バッファ時間設定部３３８は、受信バッファ１３２にネットワークジッタ対応バッファ時間を設定する。
ステップＳ３６７において、受信装置３０３は、データ伝送に用いられる全ての受信部３１３に対して処理を行ったか否かを判定し、未処理の受信部３１３が存在すると判定された場合、処理をステップＳ３６２に戻し、新たな未処理の受信部３１３を選択し、その受信部３１３について、それ以降の処理を繰り返す。
また、ステップＳ３６７において、全ての受信部３１３に対して処理を行ったと判定された場合、受信装置３０３は、統合受信バッファ時間決定処理を終了し、処理を図１６のステップＳ３２４に戻し、ステップＳ３２５以降の処理を実行する。
なお、図１６のステップＳ３０２において実行される各送信装置１０１による受信バッファ時間・処理パラメータ設定処理は、図１１のフローチャートを参照して説明した場合と同様に行われる。
［受信バッファ動的変更伝送処理］
次に、図１６のステップＳ３０３およびステップＳ３２６において実行される受信バッファ動的変更伝送処理の流れの例を図２０のフローチャートを参照して説明する。
なお、この受信バッファ動的変更伝送処理は、各送信装置１０１と、それに対応する受信部３１３との間で行われる。
この場合も基本的に図１３を参照して説明した場合と同様に行われるが、図１３の例の場合、受信装置１０３がステップＳ２６３において受信バッファ時間決定処理を行うのに対し、図２０の例の場合、受信装置３０３（受信部３１３）は、ステップＳ４０３において仮受信バッファ時間決定処理を行い、ステップＳ４０４において統合受信バッファ時間決定処理を行い、ステップＳ４０５において、以上の処理により得られた各種情報（例えば、画像品質要求、伝送品質要求、可変圧縮符号化遅延時間、および冗長符号化ブロック受信待ち時間等）を、対応する送信装置１０１に通知する。
つまり、図１６のステップＳ３２３乃至ステップＳ３２５の処理、すなわち、データ伝送を開始する前と同様の処理が行われる。
このようにして、送信装置１０１および受信装置３０３は、第２の実施の形態の場合と同様に、最新のネットワーク状況に基づいて各種設定を更新することにより、各処理の時間的余裕を画質や伝送品質の向上により有効に利用することができるようにし、遅延時間上の無駄をより低減させることができる。つまり、コンテンツの品質の劣化をより抑制することができる。
なお、ユーザ等からの要求のみに基づいて各種設定を行う場合、この受信バッファ動的変更伝送処理は省略される。
以上のように、伝送システム１００および伝送システム３００は、データ伝送に関する各処理に対して、受信装置において設定される遅延時間や待機時間を、その最大値に揃えることにより、遅延時間を増大させない程度に各処理に時間的余裕を設け、その時間的余裕を使って画質や伝送品質を向上させるように、各処理のパラメータの設定を行う。
このようにすることにより、伝送システム１００および伝送システム３００は、コンテンツの品質の劣化を抑制することができる。
例えば、ユーザ等による画質要求、伝送品質要求、およびネットワーク状況等により決定される受信バッファ時間を有効に活用し、遅延時間を増加させることなく、映像画質や伝送品質を最大限向上させることができる。
また、可変圧縮符号化遅延時間が処理遅延時間中最大値であり、この値を受信バッファ時間として設定した場合、冗長符号化処理において冗長符号化ブロックを大きく取り、冗長符号化ブロック受信待ち時間を受信バッファ時間と同等まで大きくすることにより、遅延時間を増加させずにバースト損失耐性を向上させることが可能となる。
さらに、ARQ再送パケット待ち要求時間、ネットワークジッタ対応バッファ要求時間も同様に大きくすることにより、それぞれ、損失回復性能の向上やネットワークジッタ許容値の向上を行うことができる。
また、冗長符号化ブロック受信待ち時間が処理遅延時間中最大であった場合、可変圧縮符号化遅延時間を受信バッファ時間と同等大きく設定することにより、遅延時間を増加させずに画質を向上させる事ができる。
複数の送信装置からの伝送を受信装置において同期処理する場合、複数の符号化データの同期処理が可能となるように、受信バッファ時間の調整を行い、調整後の受信バッファ時間に合わせて実際の圧縮符号化・復号処理時間やQoS制御処理時間を受信バッファ時間と同一値以下となるように処理パラメータを調整することにより、複数符号化データの同期処理のために設定した使用者の画質要求、伝送品質要求、およびネットワーク状況等から指定される以上に設定された受信バッファ時間を有効に活用し、遅延時間を増加させることなく、映像画質や伝送品質を最大限向上させることができる。
なお、以上においては、伝送するビデオデータを符号化するように説明したが、これに限らず、非圧縮のまま伝送するようにしてもよい。
＜４．第４の実施の形態＞
［パーソナルコンピュータ］
上述した一連の処理は、ハードウエアにより実行させることもできるし、ソフトウエアにより実行させることもできる。この場合、例えば、図２１に示されるようなパーソナルコンピュータとして構成されるようにしてもよい。
図２１において、パーソナルコンピュータ４００のCPU（Central Processing Unit）４０１は、ROM（Read Only Memory）４０２に記憶されているプログラム、または記憶部４１３からRAM（Random Access Memory）４０３にロードされたプログラムに従って各種の処理を実行する。RAM４０３にはまた、CPU４０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
CPU４０１、ROM４０２、およびRAM４０３は、バス４０４を介して相互に接続されている。このバス４０４にはまた、入出力インタフェース４１０も接続されている。
入出力インタフェース４１０には、キーボード、マウスなどよりなる入力部４１１、CRT（Cathode Ray Tube）やLCD（Liquid Crystal Display）などよりなるディスプレイ、並びにスピーカなどよりなる出力部４１２、ハードディスクなどより構成される記憶部４１３、モデムなどより構成される通信部４１４が接続されている。通信部４１４は、インターネットを含むネットワークを介しての通信処理を行う。
入出力インタフェース４１０にはまた、必要に応じてドライブ４１５が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア４２１が適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部４１３にインストールされる。
上述した一連の処理をソフトウエアにより実行させる場合には、そのソフトウエアを構成するプログラムが、ネットワークや記録媒体からインストールされる。
この記録媒体は、例えば、図２１に示されるように、装置本体とは別に、ユーザにプログラムを配信するために配布される、プログラムが記録されている磁気ディスク（フレキシブルディスクを含む）、光ディスク（CD-ROM（Compact Disc - Read Only Memory）,DVD（Digital Versatile Disc）を含む）、光磁気ディスク（MD（Mini Disc）を含む）、若しくは半導体メモリなどよりなるリムーバブルメディア４２１により構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに配信される、プログラムが記録されているROM４０２や、記憶部４１３に含まれるハードディスクなどで構成される。
なお、コンピュータが実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。
また、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
また、本明細書において、システムとは、複数のデバイス（装置）により構成される装置全体を表すものである。
また、以上において、１つの装置（または処理部）として説明した構成を分割し、複数の装置（または処理部）として構成するようにしてもよい。逆に、以上において複数の装置（または処理部）として説明した構成をまとめて１つの装置（または処理部）として構成されるようにしてもよい。また、各装置（または各処理部）の構成に上述した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置（または処理部）の構成の一部を他の装置（または他の処理部）の構成に含めるようにしてもよい。つまり、本発明の実施の形態は、上述した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能である。
１００ 伝送システム， １０１ 送信装置， １０２ ネットワーク， １０３ 受信装置， １１１ 符号化部， １１２ FEC部， １１３ RTP部， １１４ 平滑化部， １１５ 基準信号同期部， １１６ メディア同期部， １１７ RTCP部， １１８ ARQ部， １１９ 受信バッファ時間・処理パラメータ設定部， １２１ レート制御部， １３１ 受信部， １３２ 受信バッファ， １３３ RTP部， １３４ FEC部， １３５ 復号部， １３６ ARQ部， １３７ RTCP部， １３８ 受信バッファ時間設定部， １３９ 基準信号同期部， １４０ メディア同期部， １４１ 入力部， １４２ 出力部， ３００ 伝送システム， ３０３ 受信装置， ３１１ 伝送路， ３１２ 基準信号同期部， ３１３ 受信部， ３１４ 統合受信バッファ時間調整部， ３１５ 合成部， ３３８ 受信バッファ時間設定部

Claims (11)

  1. データを伝送する際に行われる複数の処理のそれぞれにおいて設定される遅延時間であって、それぞれが前記データの品質や前記データの伝送品質に対して影響を及ぼし、かつ、互いに並列に作用する複数の前記遅延時間を、各遅延時間の長さに対する要求に基づいて、要求された各遅延時間の内の最長の遅延時間以上の長さに設定する遅延時間設定部と、
    前記データを受信する受信部と、
    前記遅延時間設定部により設定された前記複数の遅延時間を前記受信部に設定する受信側設定部と、
    前記遅延時間設定部により設定された前記複数の遅延時間を、前記データを送信する送信装置に通知し、前記送信装置おいて行われる処理に設定させる送信側設定部と
    を備える情報処理装置。
  2. 前記受信部が受信する前記データの損失パケットの検出を行い、前記損失パケットが検出された場合、前記送信装置に対して再送要求を行う再送要求部をさらに備え、
    前記遅延時間は、前記再送要求部の前記再送要求により再送される再送パケットを待つ時間であるARQ再送パケット待ち時間を含み、
    前記受信側設定部は、前記再送要求部に対して、前記ARQ再送パケット待ち時間を設定する
    請求項１に記載の情報処理装置。
  3. 前記受信部が受信した前記データを記憶する受信バッファをさらに備え、
    前記遅延時間は、前記受信バッファでバッファリングを行う時間であるバッファ時間を含み、
    前記受信側設定部は、前記バッファ時間を前記受信バッファに設定する
    請求項１に記載の情報処理装置。
  4. 前記受信部が受信した、前記送信装置において前記データが可変圧縮符号化されて平滑化伝送された符号化データを記憶する受信バッファをさらに備え、
    前記遅延時間は、前記受信部の前記受信バッファにおいて必要な前記符号化データのバッファ時間である可変圧縮符号化遅延時間を含み、
    前記送信側設定部は、前記可変圧縮符号化遅延時間を、前記送信装置に通知し、前記送信装置おいて行われる符号化処理に設定させる
    請求項１に記載の情報処理装置。
  5. 前記受信部が受信した、前記送信装置において前記データが冗長符号化されて伝送された冗長符号化ブロックを冗長復号する冗長復号部を備え、
    前記遅延時間は、前記冗長符号化ブロックの先頭パケットが前記受信部に到着してから末尾のパケットが到着するまでの時間である冗長符号化ブロック受信待ち時間を含み、
    前記送信側設定部は、前記冗長符号化ブロック受信待ち時間を、前記送信装置に通知し、前記送信装置おいて行われる冗長符号化処理に設定させる
    請求項１に記載の情報処理装置。
  6. ネットワーク状況を計測する計測部をさらに備え、
    前記遅延時間設定部は、各遅延時間の長さに対する要求、並びに、前記計測部により計測された前記ネットワーク状況に応じて、各遅延時間を設定する
    請求項１に記載の情報処理装置。
  7. 前記データは画像データであり、
    前記画像データの画質に関する要求である画像品質要求、および、前記画像データの伝送品質に関する要求である伝送品質要求を受け付ける受付部をさらに備え、
    前記遅延時間設定部は、前記受付部により受け付けられた前記画像品質要求および前記伝送品質要求に基づいて、要求される各遅延時間の長さを求め、求めた各遅延時間の長さに対する要求に基づいて、前記複数の遅延時間を、要求された各遅延時間の内の最長の遅延時間以上の長さに設定する
    請求項１に記載の情報処理装置。
  8. 前記受付部により受け付けられる前記画像品質要求および前記伝送品質要求の入力を補助するGUIを表示する出力部をさらに備える
    請求項７に記載の情報処理装置。
  9. 複数の前記送信装置のそれぞれについて、ネットワーク状況として、前記データの伝送遅延の長さを計測するネットワーク計測部をさらに備え、
    前記受信部は、複数の前記送信装置より伝送される前記データを受信し、
    前記遅延時間設定部は、
    前記複数の送信装置から伝送される前記データのそれぞれについて、前記複数の遅延時間を、各遅延時間の長さに対する要求に基づいて、要求された各遅延時間の内の最長の遅延時間以上の長さに設定する第１の遅延時間設定部と、
    各送信装置の前記第１の遅延時間設定部により設定された前記遅延時間と前記ネットワーク計測部により計測された前記伝送遅延の長さとの和を、前記和の最大値に合わせるように、前記遅延時間を設定する第２の遅延時間設定部と
    を備え、
    前記受信側設定部は、前記第２の遅延時間設定部により設定された前記複数の遅延時間を前記受信部に設定し、
    前記送信側設定部は、前記第２の遅延時間設定部により設定された前記複数の遅延時間を、前記データを送信する送信装置に通知し、前記送信装置おいて行われる処理に設定させる
    請求項１に記載の情報処理装置。
  10. データを伝送する際に行われる複数の処理のそれぞれにおいて設定される遅延時間であって、それぞれが前記データの品質や前記データの伝送品質に対して影響を及ぼし、かつ、互いに並列に作用する複数の前記遅延時間を、各遅延時間の長さに対する要求に基づいて、要求された各遅延時間の内の最長の遅延時間以上の長さに設定し、
    前記データを受信し、
    設定された前記複数の遅延時間を受信部に設定し、
    設定された前記複数の遅延時間を、前記データを送信する送信装置に通知し、前記送信装置おいて行われる処理に設定させる
    情報処理方法。
  11. データを送信する送信装置と、前記送信装置より送信されたデータを受信する受信装置とを備える送受信システムであって、
    前記受信装置は、
    前記データを伝送する際に行われる複数の処理のそれぞれにおいて設定される遅延時間であって、それぞれが前記データの品質や前記データの伝送品質に対して影響を及ぼし、かつ、互いに並列に作用する複数の前記遅延時間を、各遅延時間の長さに対する要求に基づいて、要求された各遅延時間の内の最長の遅延時間以上の長さに設定する遅延時間設定部と、
    前記データを受信する受信部と、
    前記遅延時間設定部により設定された前記複数の遅延時間を前記受信部に設定する受信側設定部と、
    前記遅延時間設定部により設定された前記複数の遅延時間を前記送信装置に通知する通知部と
    を備え、
    前記送信装置は、
    前記データを送信する送信部と、
    前記受信装置から通知される前記複数の遅延時間を取得する遅延時間取得部と、
    前記遅延時間取得部により取得された前記複数の遅延時間を前記送信部に設定する送信側設定部と
    を備える送受信システム。
JP2010180945A 2010-08-12 2010-08-12 情報処理装置および方法、並びに送受信システム Expired - Fee Related JP5598155B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2010180945A JP5598155B2 (ja) 2010-08-12 2010-08-12 情報処理装置および方法、並びに送受信システム
US13/183,843 US10306268B2 (en) 2010-08-12 2011-07-15 Information processing device and method
CN2011102131367A CN102378003A (zh) 2010-08-12 2011-07-28 信息处理装置和方法以及程序

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2010180945A JP5598155B2 (ja) 2010-08-12 2010-08-12 情報処理装置および方法、並びに送受信システム

Publications (3)

Publication Number Publication Date
JP2012044252A JP2012044252A (ja) 2012-03-01
JP2012044252A5 JP2012044252A5 (ja) 2013-09-19
JP5598155B2 true JP5598155B2 (ja) 2014-10-01

Family

ID=45564758

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010180945A Expired - Fee Related JP5598155B2 (ja) 2010-08-12 2010-08-12 情報処理装置および方法、並びに送受信システム

Country Status (3)

Country Link
US (1) US10306268B2 (ja)
JP (1) JP5598155B2 (ja)
CN (1) CN102378003A (ja)

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013062624A (ja) * 2011-09-12 2013-04-04 Sharp Corp 再生装置、再生方法、配信装置、配信システム、再生プログラムおよび記録媒体
JP5899518B2 (ja) * 2012-02-06 2016-04-06 パナソニックＩｐマネジメント株式会社 サーバ装置、システム制御方法及びシステム制御プログラム
JP6278275B2 (ja) * 2012-06-04 2018-02-14 パナソニックＩｐマネジメント株式会社 送信装置、受信装置、送信方法および受信方法
WO2013183236A1 (ja) * 2012-06-04 2013-12-12 パナソニック株式会社 送信装置、受信装置、送信方法および受信方法
JP2014093584A (ja) * 2012-11-01 2014-05-19 Sony Corp 送信装置、送信方法、受信装置、受信方法およびコンピュータプログラム
JP2015002462A (ja) 2013-06-17 2015-01-05 ソニー株式会社 画像圧縮回路、画像圧縮方法、および伝送システム
JP6294346B2 (ja) * 2013-11-15 2018-03-14 株式会社日立製作所 通信装置及びシステム及び方法
US20150143439A1 (en) * 2013-11-19 2015-05-21 Sony Corporation Providing increased bandwidth for transmission of audio video content and supplemental content associated therewith
CN103716718B (zh) * 2013-12-16 2017-03-01 广州华多网络科技有限公司 数据包的传输方法及装置
GB2521441B (en) * 2013-12-20 2016-04-20 Imagination Tech Ltd Packet loss mitigation
CN105812837A (zh) * 2014-12-30 2016-07-27 华为技术有限公司 一种图像处理方法与装置
JP6279146B2 (ja) * 2015-03-05 2018-02-14 三菱電機株式会社 データ処理装置及びデータ処理方法及びデータ処理プログラム
WO2016203870A1 (ja) * 2015-06-17 2016-12-22 ソニー株式会社 送信装置、送信方法、及び通信システム
US20170187635A1 (en) * 2015-12-28 2017-06-29 Qualcomm Incorporated System and method of jitter buffer management
JP6533761B2 (ja) * 2016-05-18 2019-06-19 株式会社ソニー・インタラクティブエンタテインメント 情報処理装置、情報処理システム、および情報処理方法
JP6796233B2 (ja) * 2016-09-05 2020-12-09 株式会社メディアリンクス 映像切替システム
EP3382918B1 (en) * 2017-03-30 2022-09-28 ADVA Optical Networking SE System and method of clock management in a packet data network
CN108965934B (zh) * 2017-05-27 2021-01-29 华为技术有限公司 一种故障检测方法、监控设备及网络设备
US10521881B1 (en) 2017-09-28 2019-12-31 Apple Inc. Error concealment for a head-mountable device
FR3072237B1 (fr) * 2017-10-10 2019-10-25 Bull Sas Procede et dispositif pour la gestion dynamique du delai de retransmission de message sur un reseau d'interconnexion
US11876790B2 (en) * 2020-01-21 2024-01-16 The Boeing Company Authenticating computing devices based on a dynamic port punching sequence
US12267553B2 (en) * 2020-06-19 2025-04-01 Apple Inc. Systems and methods of video jitter estimation
JP7638669B2 (ja) 2020-11-09 2025-03-04 株式会社東芝 フレーム同期装置
JP2023019552A (ja) * 2021-07-29 2023-02-09 キヤノン株式会社 通信装置、通信方法およびプログラム
US12262057B2 (en) * 2022-03-22 2025-03-25 Realtek Semiconductor Corp. Method and apparatus of image compression with bit rate control

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6985501B2 (en) * 2000-04-07 2006-01-10 Ntt Docomo, Inc. Device and method for reducing delay jitter in data transmission
JP2002185850A (ja) * 2000-12-11 2002-06-28 Nippon Telegr & Teleph Corp <Ntt> 遠隔映像選択混合方法及びシステム
US8842555B2 (en) * 2005-10-21 2014-09-23 Qualcomm Incorporated Methods and systems for adaptive encoding of real-time information in packet-switched wireless communication systems
US7957312B2 (en) * 2005-11-28 2011-06-07 Nec Corporation Communication unit, communication system, communication method and communication program
JP4371120B2 (ja) 2006-05-16 2009-11-25 ソニー株式会社 画像処理装置及び画像処理方法、プログラム及び記録媒体
US20080273520A1 (en) * 2007-05-04 2008-11-06 Samsung Electronics Co. Ltd. NETWORK ARCHITECTURE FOR DYNAMICALLY SETTING END-TO-END QUALITY OF SERVICE (QoS) IN A BROADBAND WIRELESS COMMUNICATION SYSTEM
EP2114053A1 (en) * 2008-04-30 2009-11-04 THOMSON Licensing Delivery delay compensation on synchronised communication devices in a packet switched network
JP4670902B2 (ja) * 2008-05-30 2011-04-13 ソニー株式会社 送信装置、送信方法および受信装置
US8468426B2 (en) * 2008-07-02 2013-06-18 Apple Inc. Multimedia-aware quality-of-service and error correction provisioning
JP5178375B2 (ja) * 2008-07-30 2013-04-10 パナソニック株式会社 デジタル放送再生装置およびデジタル放送再生方法
US8929443B2 (en) * 2009-01-09 2015-01-06 Microsoft Corporation Recovering from dropped frames in real-time transmission of video over IP networks
US8289870B2 (en) * 2009-09-23 2012-10-16 Avaya Inc. Priority-based, dynamic optimization of utilized bandwidth
JP5672840B2 (ja) * 2010-08-12 2015-02-18 ソニー株式会社 情報処理装置および方法、並びにプログラム

Also Published As

Publication number Publication date
JP2012044252A (ja) 2012-03-01
US10306268B2 (en) 2019-05-28
CN102378003A (zh) 2012-03-14
US20120039194A1 (en) 2012-02-16

Similar Documents

Publication Publication Date Title
JP5598155B2 (ja) 情報処理装置および方法、並びに送受信システム
JP5672840B2 (ja) 情報処理装置および方法、並びにプログラム
US8311122B2 (en) Information processing apparatus and method
EP2337306B1 (en) Transmitting apparatus and method, and receiving apparatus and method
JP5493471B2 (ja) 情報処理装置および方法
US8745432B2 (en) Delay controller, control method, and communication system
US8527846B2 (en) Information processing device, method and program
JP4129694B2 (ja) 情報処理装置および方法、プログラム、並びに記録媒体
US20110249181A1 (en) Transmitting device, receiving device, control method, and communication system
EP2200325B1 (en) Information processor and method therefor
WO2013154025A1 (ja) 情報処理装置および方法、並びに、プログラム
JP5610199B2 (ja) 受信装置、受信方法、及び通信システム
WO2013154024A1 (ja) 情報処理装置および方法、並びに、プログラム
JP2011147050A (ja) 画像処理装置および方法

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130812

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20130812

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20140418

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20140424

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140623

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: 20140715

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20140728

LAPS Cancellation because of no payment of annual fees