[go: up one dir, main page]

JP5672840B2 - 情報処理装置および方法、並びにプログラム - Google Patents

情報処理装置および方法、並びにプログラム Download PDF

Info

Publication number
JP5672840B2
JP5672840B2 JP2010180946A JP2010180946A JP5672840B2 JP 5672840 B2 JP5672840 B2 JP 5672840B2 JP 2010180946 A JP2010180946 A JP 2010180946A JP 2010180946 A JP2010180946 A JP 2010180946A JP 5672840 B2 JP5672840 B2 JP 5672840B2
Authority
JP
Japan
Prior art keywords
transmission
time
unit
data
reception
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
JP2010180946A
Other languages
English (en)
Other versions
JP2012044253A (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 JP2010180946A priority Critical patent/JP5672840B2/ja
Priority to BR112013002848A priority patent/BR112013002848A2/pt
Priority to CN201180038506.6A priority patent/CN103069835B/zh
Priority to EP11816352.6A priority patent/EP2605459A1/en
Priority to PCT/JP2011/067802 priority patent/WO2012020686A1/ja
Priority to US13/814,273 priority patent/US8964921B2/en
Publication of JP2012044253A publication Critical patent/JP2012044253A/ja
Application granted granted Critical
Publication of JP5672840B2 publication Critical patent/JP5672840B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L7/00Arrangements for synchronising receiver with transmitter
    • H04L7/0016Arrangements for synchronising receiver with transmitter correction of synchronization errors
    • H04L7/0033Correction by delay
    • H04L7/0041Delay of data signal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing 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/44Processing 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/44004Processing 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04JMULTIPLEX COMMUNICATION
    • H04J3/00Time-division multiplex systems
    • H04J3/02Details
    • H04J3/06Synchronising arrangements
    • H04J3/062Synchronisation of signals having the same nominal but fluctuating bit rates, e.g. using buffers
    • H04J3/0632Synchronisation of packets and cells, e.g. transmission of voice via a packet network, circuit emulation service [CES]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/24Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2416Real-time traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/28Flow control; Congestion control in relation to timing considerations
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing 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/4302Content synchronisation processes, e.g. decoder synchronisation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network 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/63Control 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/637Control signals issued by the client directed to the server or network components
    • H04N21/6375Control 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network 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/63Control 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/643Communication protocols
    • H04N21/6437Real-time Transport Protocol [RTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network 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/63Control 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/647Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Data Exchanges In Wide-Area Networks (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同期とビデオフレーム間隔以下の低遅延伝送が要求される。
このような要求から動画像の各ピクチャの数ライン毎を1つの符号化ブロック(ラインブロック)としてウェーブレット変換による符号化を行う方式が提案されている(例えば特許文献1参照)。
この方式では、ピクチャ内のデータ全てを入力するまで待つことなく符号化を開始することができる。そのため、生成した符号化データをネットワーク伝送し、受信側で復号する場合においても、ピクチャ内の全てのデータを受信する前に復号処理を開始することができる。つまり、ネットワーク伝播遅延が十分小さければ、フレーム間隔以下の遅延でのリアルタイム(即時的な)動画像伝送が可能となる。
このようなデータ伝送において、受信装置は、符号化処理、データ伝送処理、およびQoS制御処理等の遅延に対応するために受信したデータをバッファ(一時的に保持)する必要があった。換言するに、この受信側のバッファ時間に応じて(オーバフローしないように)符号化処理やQoS制御処理等の設定が行われていた。つまり、復号画像の画質や伝送品質は、バッファ時間に依存していた。
ところで、このようなデータ伝送により複数の送信装置から1つの受信装置にデータを伝送する場合、従来の方式においては、各送信装置に対する受信バッファ時間は、互いに独立に設定されるか、若しくは、予め定められた所定の時間に設定されていた(共通の受信バッファ時間が用いられた)。
特許4371120号
しかしながら、一般的に、各送信装置からのデータ伝送に関する遅延(伝送遅延)は、そのデータ伝送の経路や帯域幅等が互いに異なることから、送信装置毎に異なる場合が多い。ところが、従来方式の場合、受信バッファ時間の設定はこの伝送遅延の違いを考慮せずに行われる(互いに独立に設定されるか、共通に設定される)。
上述したように、符号化やQoS制御等の設定は、この受信バッファ時間に基づいて行われるので、実際には、受信データがこの受信バッファ時間よりも長く保持されることになる場合であっても、復号画像の画質や伝送品質を向上させることができない恐れがあった。つまり、不要な待機時間が生じてしまう恐れがあった。換言するに、データ伝送によりコンテンツの品質を不要に劣化させる恐れがあった。
本発明は、このような状況に鑑みてなされたものであり、各処理の時間的余裕を画質や伝送品質の向上に利用することができるようにし、遅延時間上の無駄を低減させることができるようにすることを目的とする。
本発明の一側面は、複数の送信装置から1つの受信装置に、互いに同期がとられたデータを伝送するデータ伝送において、各データ伝送の、伝送路上で発生する遅延時間である伝送遅延の差を用いて、各データ伝送について設定される、前記受信装置において各データの同期をとるためのバッファ時間である受信バッファ時間を調整する調整手段と、前記調整手段により調整された前記受信バッファ時間を用いて、各データ伝送のQoS制御処理のパラメータとして、冗長符号化ブロックの先頭パケットから末尾のパケットを受信するまでの時間である冗長符号化ブロック受信待ち時間、再送パケットを待つ時間である再送パケット待ち時間、およびネットワークジッタを吸収するためのネットワークジッタ対応バッファ時間を設定する設定手段とを備える情報処理装置である。
前記調整手段は、前記伝送遅延の最大値を求め、各データの前記伝送遅延と前記最大値との差を、予め定められた所定の受信バッファ時間である規定受信バッファ時間に加えたものを、前記受信バッファ時間とすることができる。
前記データは伝送元において符号化され、得られた符号化データが伝送され、伝送先において前記符号化データが復号され、前記設定手段は、前記データ伝送に関する処理のパラメータとして、前記符号化においてレート制御されて生成された前記符号化データを平滑化伝送する際に必要な可変圧縮符号化遅延要求時間を設定することができる。
前記データの画質に関する要求である画像品質要求、および、前記データ伝送における伝送品質に関する要求である伝送品質要求を受け付ける受付手段をさらに備え、前記調整手段は、前記受付手段により受け付けられた前記画像品質要求および前記伝送品質要求に基づいて、前記受信バッファ時間を調整することができる。
前記調整手段は、前記受付手段により受け付けられた前記画像品質要求および前記伝送品質要求に基づいて、仮の前記受信バッファ時間を設定し、前記仮の受信バッファ時間を用いて、前記受信バッファ時間を調整することができる。
前記受付手段により受け付けられる前記画像品質要求および前記伝送品質要求の入力を補助するGUIを表示する出力手段をさらに備えることができる。
本発明の一側面は、また、情報処理装置の情報処理方法であって、前記情報処理装置の調整手段が、複数の送信装置から1つの受信装置に、互いに同期がとられたデータを伝送するデータ伝送において、各データ伝送の、伝送路上で発生する遅延時間である伝送遅延の差を用いて、各データ伝送について設定される、前記受信装置において各データの同期をとるためのバッファ時間である受信バッファ時間を調整し、前記情報処理装置の設定手段が、調整された前記受信バッファ時間を用いて、各データ伝送のQoS制御処理のパラメータとして、冗長符号化ブロックの先頭パケットから末尾のパケットを受信するまでの時間である冗長符号化ブロック受信待ち時間、再送パケットを待つ時間である再送パケット待ち時間、およびネットワークジッタを吸収するためのネットワークジッタ対応バッファ時間を設定する情報処理方法である。
本発明の一側面は、さらに、データ伝送を制御するコンピュータを、複数の送信装置から1つの受信装置に、互いに同期がとられたデータを伝送するデータ伝送において、各データ伝送の、伝送路上で発生する遅延時間である伝送遅延の差を用いて、各データ伝送について設定される、前記受信装置において各データの同期をとるためのバッファ時間である受信バッファ時間を調整する調整手段、前記調整手段により調整された前記受信バッファ時間を用いて、各データ伝送のQoS制御処理のパラメータとして、冗長符号化ブロックの先頭パケットから末尾のパケットを受信するまでの時間である冗長符号化ブロック受信待ち時間、再送パケットを待つ時間である再送パケット待ち時間、およびネットワークジッタを吸収するためのネットワークジッタ対応バッファ時間を設定する設定手段として機能させるためのプログラムである。
本発明の一側面においては、複数の送信装置から1つの受信装置に、互いに同期がとられたデータを伝送するデータ伝送において、各データ伝送の、伝送路上で発生する遅延時間である伝送遅延の差を用いて、各データ伝送について設定される、受信装置において各データの同期をとるためのバッファ時間である受信バッファ時間が調整され、その調整された受信バッファ時間を用いて、各データ伝送のQoS制御処理のパラメータとして、冗長符号化ブロックの先頭パケットから末尾のパケットを受信するまでの時間である冗長符号化ブロック受信待ち時間、再送パケットを待つ時間である再送パケット待ち時間、およびネットワークジッタを吸収するためのネットワークジッタ対応バッファ時間が設定される。
本発明によれば、データを伝送することができる。特に、コンテンツの品質の劣化を抑制することができる。
本発明を適用した伝送システムの主な構成例を示すブロック図である。 送信装置の主な構成例を示すブロック図である。 符号化部の主な構成例を示すブロック図である。 分析フィルタリングの概要を説明する図である。 分析フィルタリングの概要を説明する図3に続く図である。 ラインブロックを説明する図である。 受信部の主な構成例を示すブロック図である。 復号部の主な構成例を示すブロック図である。 データ伝送全体処理の流れの例を説明するフローチャートである。 受信バッファ時間決定処理の流れの例を説明するフローチャートである。 受信バッファ時間の設定の様子の例を示す図である。 受信バッファ時間・処理パラメータ設定処理の流れの例を説明するフローチャートである。 本発明を適用した伝送システムの主な構成例を示すブロック図である。 要求受付画面の表示例を示す図である。 データ伝送処理の流れの他の例を説明するフローチャートである。 受信バッファ時間決定処理の流れの例を説明するフローチャートである。 受信バッファ時間決定処理の流れの例を説明する、図16に続くフローチャートである。 受信バッファ動的変更伝送処理の流れの例を説明するフローチャートである。 本発明を適用したパーソナルコンピュータの主な構成例を示すブロック図である。
以下、発明を実施するための形態(以下実施の形態とする)について説明する。なお、説明は以下の順序で行う。
1.第1の実施の形態(伝送システム)
2.第2の実施の形態(伝送システム)
3.第3の実施の形態(パーソナルコンピュータ)
<1.第1の実施の形態>
[伝送システムの概要]
図1は、本発明を適用した伝送システムの主な構成例を示すブロック図である。伝送システム100は、複数の送信装置(送信装置101−1乃至送信装置101−N(Nは2以上の整数))から画像データを、インターネットやLAN等の汎用の伝送路であるネットワーク102を介して受信装置103に伝送するシステムである。以下において、各送信装置を互いに区別して説明する必要が無い場合、単に送信装置101と称する。なお、ネットワーク102には、ケーブル等だけでなく、ルータやハブ等のデバイスも含まれる。
各送信装置101に入力された画像データ(ビデオデータ)は、リアルタイムに(即時的に)、ネットワーク102を介して受信装置103伝送され、その受信装置103より出力される。つまり、各送信装置101に所定の(例えば通常再生時の)フレームレートで入力されたビデオデータは、送信装置101において符号化され、符号化データとして受信装置103に伝送され、受信装置103において復号され、所定の遅延時間分遅れて受信装置103から所定の(例えば通常再生時の)フレームレートで出力される。
受信装置103は、各送信装置101からのデータを、互いに同期をとりながら、合成し、出力する(再生する)。つまり、各送信装置101からのデータ伝送は、このような同期再生が破たんしないように行われる。
近年においては、インターネットやLANの汎用の伝送路を経由してメディア基準信号同期(所謂GENLOCK同期)を行いながらマルチメディアデータを低遅延に伝送するという需要が高まっている。
例えば、放送局においては、従来、カメラとそのコントロールユニット(所謂CCU)がHD-SDIケーブルにより接続され、それらの間で非圧縮同期伝送が行われていた。近年においては、このHD-SDIケーブルをEthernetケーブルに置き換え、Ethernet上でIPパケットによるGENLOCK同期を行いながら伝送するといったことが行われている。
このような目的においてマルチメディアデータのIP伝送を行う場合、HD-SDIケーブル経由での伝送と同等の使い勝手を要求される。そのため、高精度のGENLOCK同期や、ビデオフレーム間隔以下の低遅延伝送等が要求される。
このような要求から特許文献1においては、動画像の各ピクチャの数ライン毎を1つの符号化ブロック(ラインブロック)とし、符号化を行う方式が提案されている。この方式の場合、送信装置101は、ピクチャ内のデータ全てを入力するまで待つことなく符号化を開始することができる。また、送信装置101は、その符号化により得られた符号化データを、順次、ネットワーク102を介して受信装置103に伝送することができる。
さらに、受信装置103は、ピクチャ内の全てのデータを受信する前に復号を開始することができる。ネットワーク102の伝送遅延(送信装置101から受信装置103へのデータ伝送の、ネットワーク102において発生する遅延)が十分小さければ、フレーム間隔以下の遅延でのリアルタイム動画像伝送(送信装置101入力時のフレームレートで、受信装置103から出力することができるようなデータ伝送)が可能となる。
複数の送信装置からストリームデータを伝送し、受信装置において同期処理を行う場合、従来では、その同期処理のために各送信装置に対応した受信装置内の受信部に受信バッファを設け、異なる受信バッファ時間を設定することにより、同期処理を実現していた。
しかしながら、従来の方式においては、符号化処理やQoS制御処理におけるパラメータを受信バッファ時間および複数の送信装置に対応する受信部毎の受信バッファ時間の差異に応じて変更することはなかった。
したがって、符号化処理やQoS制御処理パラメータを調整することにより伝送遅延が増加することがないにもかかわらず、それらが調整されることはなく、遅延時間上の無駄が生じていた。
上述したように、伝送システム100は、各データ伝送における符号化処理やQoS制御処理等のパラメータを、その伝送遅延の長さの違いに応じて調整することにより、遅延時間を増大させずに画像品質や映像品質を向上させることができる。
図1に示されるように、受信装置103は、伝送部111、基準信号同期部112、受信部113−1乃至受信部113−N、統合受信バッファ時間調整部114、および合成部115を有する。
伝送部111は、各送信装置101と通信を行い、基準信号同期部112や受信部113−1乃至受信部113−Nから供給される情報を送信したり、各送信装置101から供給される情報を受信し、基準信号同期部112や受信部113−1乃至受信部113−Nに供給したりする。
基準信号同期部112は、伝送部111を介して送信装置101と通信を行い、送信装置101との間で基準信号の同期をとる。基準信号は、送信装置101と受信装置103との間で処理の同期をとるための信号である。同期がとられた基準信号は、受信部113−1乃至受信部113−Nに供給される。
つまり、受信装置103(の基準信号同期部112)がマスタとなり、全ての送信装置101が受信装置103と同期を取ることにより結果的に全ての送信装置101および受信装置103の同期を取ることができる。
受信部113−1乃至受信部113−Nは、それぞれ、送信装置101−1乃至送信装置101−Nに対応し、対応する送信装置101から供給されたRTPパケットを受信し、復号してビデオデータを出力する。以下において、受信部113−1乃至受信部113−Nを互いに区別して説明する必要が無い場合、単に、受信部113と称する。つまり、受信部113は、送信装置101以上の数が予め用意される。換言するに、受信装置103は、内蔵する受信部113の数以下の送信装置101から送信されるパケットを受信することができる。
統合受信バッファ時間調整部114は、各受信部113の受信バッファ時間を調整する。合成部115は、各受信部113から出力されるビデオデータを合成し、合成されたビデオデータを受信装置103のビデオ出力端子「ビデオOUT」から出力する。各受信部113のビデオデータ出力タイミングは、互いに同期がとれている。合成部115は、例えばユーザ指示等に基づいて、これらのビデオデータを適宜合成し、出力する。
[送信装置の構成]
図2に示されるように、送信装置101は、符号化部131、FEC(Forward Error Correction)部132、RTP(Real-time Transport Protocol)部133、平滑化部134、基準信号同期部135、メディア同期部136、RTCP(RTP Control Protocol)部137、ARQ(Auto Repeat Request)部138、および受信バッファ時間・処理パラメータ設定部139を有する。
ビデオカメラ等を経由しビデオ入力IF「ビデオIN」より入力したビデオデータ(動画像データ)は、符号化部131に供給される。符号化部131は、所定の符号化方式で動画像データの符号化処理を行う。この符号化方式は任意であるが、より低遅延なものが望ましい。符号化方式の例については後述する。
符号化部131は、レート制御部141を有する。レート制御部141は、符号化部131において生成される符号化データのビットレートを制御する。符号化部131は、生成した符号化データをRTPパケット化し、それをFEC部132に供給する。
FEC部132は、符号化部131から供給されるRTPパケットの冗長パケットを生成する。RTP部133は、FEC部132から供給される符号化データの冗長パケットをRTPパケット化する。
平滑化部134は、RTP部133から供給されるRTPパケットを、一時的に保持し、所定のデータレートに平滑化して送信する。
基準信号同期部135は、ネットワーク102を介して、伝送先である受信装置103の基準信号同期部112と通信を行い、基準信号クロックの同期をとる。基準信号同期部135は、受信装置103との間で同期がとれた基準信号をメディア同期部136に供給する。
メディア同期部136は、基準信号同期部135から供給される時刻を基準として、ビデオINに入力されたデータのサンプリング時刻と同期した時刻を、符号化部131(符号化部131内のRTP部)とRTP部133に供給する。この時刻は、RTPタイムスタンプとしてRTPパケットに付加される。
RTCP部137は、伝送先の受信装置103とRTCPメッセージの授受を行い、QoS(Quality of Service)制御処理のための制御メッセージ(QoS制御メッセージ)の送受信を行う。RTCP部137は、取得した制御メッセージをARQ部138や受信バッファ時間・処理パラメータ設定部139に供給する。
ARQ部138は、RTCP部137から供給される再送要求メッセージに従って、平滑化部134を制御し、要求されたRTPパケットの再送を行う。
受信バッファ時間・処理パラメータ設定部139は、RTCP部137から供給される各種遅延時間等の設定に従って、符号化部131やFEC部132のパラメータ設定を行う。
[符号化部の構成例]
次に、送信装置101の符号化部131の例について説明する。図3は、送信装置101の符号化部131の構成例を示すブロック図である。符号化部131は、画像データを解像度に関して重要度の高いデータから順に階層化し、その階層毎に符号化する階層符号化を行う。例えば、符号化部131は、空間解像度に関して重要度の高いデータから順に階層化された階層化データを生成する。また、例えば、符号化部131は、時間方向の解像度に関して重要度の高いデータから順に階層化された階層化データを生成する。さらに、例えば、符号化部131は、SNR(Signal to Noise Ratio)に関して重要度の高いデータから順に階層化された階層化データを生成する。符号化部131は、このように生成した階層化データを、その階層毎に符号化する。
このような階層符号化として、例えば、動画像データの各ピクチャをウェーブレット変換し、エントロピ符号化するJPEG(Joint Photographic Experts Group)2000方式がある。階層符号化方法は任意であるが、以下においては、符号化部131が、動画像データを複数ライン毎にウェーブレット変換し、エントロピ符号化する場合について説明する。
図3に示されるように、符号化部131は、ウェーブレット変換部161、量子化部162、エントロピ符号化部163、レート制御部141、およびRTP部164を有する。ウェーブレット変換部161は、動画像の各ピクチャを、複数ライン毎にウェーブレット変換する。
ウェーブレット変換は、入力データを低域成分と高域成分に分割する分析フィルタ処理を、画面水平方向および画面垂直方向の両方に対して行う処理である。つまり、ウェーブレット変換処理により入力データは、水平方向および垂直方向に低域な成分(LL成分)、水平方向に高域で垂直方向に低域な成分(HL成分)、水平方向に低域で垂直方向に高域な成分(LH成分)、および、水平方向および垂直方向に高域な成分(HH成分)の4つの成分(サブバンド)に分割される。
ウェーブレット変換部161は、このようなウェーブレット変換処理を、所定回数、分析フィルタ処理により得られる水平方向および垂直方向に低域な成分(LL成分)に対して再帰的に繰り返す。つまり、ウェーブレット変換処理により、動画像データの各ピクチャは、階層化された複数のサブバンド(周波数成分)に分割される(階層化データが生成される)。エントロピ符号化部163は、このサブバンド毎に符号化を行う。
動画像の各ピクチャの画像データは、画像の上から下に向かう順に1ラインずつウェーブレット変換部161に入力される。また各ラインの画像データは、画像左から右に向かう順に1サンプル(1コラム)ずつ入力される。
ウェーブレット変換部161は、そのように入力される画像データに対して、分析フィルタリングを実行可能なサンプル数のデータを入手する毎に(入手次第)、画像水平方向の分析フィルタリング(水平分析フィルタリング)を実行する。例えば、ウェーブレット変換部161は、図4の左に示されるベースバンドの画像データ181に対して、Mコラム入力される毎に水平分析フィルタリングを行い、1ラインずつ水平方向に低域な成分(L)と高域な成分(H)に分割する。図4の右に示される水平分析フィルタ処理結果182は、ウェーブレット変換部161により分割されたNライン分の水平方向に低域な成分(L)と高域な成分(H)を示す。
次に、ウェーブレット変換部161は、その水平分析フィルタ処理結果182の各成分に対して、垂直方向に分析フィルタリング(垂直分析フィルタリング)を行う。ウェーブレット変換部161は、水平分析フィルタリングにより、垂直分析フィルタリングに必要な垂直ライン分の係数が生成されると、その垂直分析フィルタリングに必要な垂直ライン分の係数に対して、コラム毎に垂直分析フィルタリングを行う。
その結果、水平分析フィルタ処理結果182は、図5の左に示されるように、水平方向および垂直方向の両方に低域な成分(LL成分)、水平方向に高域で垂直方向に低域な成分(HL成分)、水平方向に低域で垂直方向に高域な成分(LH成分)、および、水平方向および垂直方向の両方に高域な成分(HH成分)の4つの成分のウェーブレット変換係数(以下、係数と称する)に分割される(階層化データ183)。
所定の階層(分割レベル)の係数が得られるまで、得られた分析フィルタリングの結果のうち、HL成分、LH成分、HH成分は外部に出力される。残りのLL成分は、ウェーブレット変換部161により、再度分析フィルタリングが行われる。つまり、例えば、図5の左に示される階層化データ183は、図5の右に示される階層化データ184に変換される。階層化データ184では、LL成分から、LLLL成分、LLHL成分、LLLH成分、およびLLHH成分の4つの成分が生成されている。
ウェーブレット変換部161は、このような分析フィルタリングを所定回数再帰的に行い、動画像データを所望の分割レベルまで階層化された階層化データを生成する。図6は、分割レベル3(3階層)まで階層化された階層化データの例を示す図である。図6において、分割レベル3まで分割された階層化データ185は、分割レベル1(階層番号3)の3HL成分、3LH成分、および3HH成分、分割レベル2(階層番号2)の2HL成分、2LH成分、および2HH成分、並びに、分割レベル3(階層番号1)の1LL成分、1HL成分、1LH成分、および1HH成分の各サブバンドにより構成される。
ウェーブレット変換処理では、フィルタリング処理を繰り返す毎に(階層が1つ下位になる毎に)、生成されるライン数は2のべき乗分の1ずつ小さくなっていく。最終分割レベル(階層番号1)の係数を1ライン生成するために必要なベースバンドのライン数は、そのフィルタリング処理を何回繰り返すか(最終分割レベルの階層数)によって決められる。通常、この階層数は予め定められる。
この、最終分割レベルの係数を1ライン生成するために必要なベースバンドの画像データ(複数ライン分の画像データ)、または、各階層の係数をまとめてラインブロック(またはプレシンクト)と称する。
図6において斜線で示される部分が1ラインブロックを構成する係数である。図6に示されるように、ラインブロックは、階層番号1の各成分の1ライン分の係数、階層番号2の各成分の2ライン分の係数、並びに、階層番号3の各成分の4ライン分の係数により構成される。なお、これらに相当する分析フィルタリング前の画像データ、すなわち、この例では8ライン分の画像データのこともラインブロック(またはプレシンクト)と称する。
図3に戻り、量子化部162は、ウェーブレット変換部161により生成される各成分の係数を、例えば量子化ステップサイズで除算することにより量子化し、量子化係数を生成する。この際、量子化部162は、ラインブロック(プレシンクト)毎に量子化ステップサイズを設定することができる。このラインブロックは、ある画像領域のすべての周波数成分(図6の場合、1LL乃至3HHまでの10個の周波数成分)の係数を包含しているため、ラインブロック毎に量子化を行えば、ウェーブレット変換の特徴である多重解像度分析の利点を活かすことができる。また、全画面でラインブロック数だけを決めればよいため、量子化の負荷も小さくて済む。
さらに、画像信号のエネルギは一般的に低域成分に集中しており、また、人間の視覚上、低域成分の劣化が目立ちやすいという特性があるため、量子化に際しては、低域成分のサブバンドでの量子化ステップサイズが結果的に小さな値になるように、重み付けを行うことが有効である。この重み付けにより、低域成分には相対的に多くの情報量が割り当てられるようになり、全体の主観的な画質が向上する。
エントロピ符号化部163は、量子化部162で生成された量子化係数を情報源符号化し、圧縮された符号化データを生成し、それをレート制御部141に供給する。情報源符号化としては、例えばJPEG方式やMPEG(Moving Picture Experts Group)方式で用いられているハフマン符号化や、JPEG2000方式で用いられているさらに高精度な算術符号化を用いることができる。
ここで、エントロピ符号化をどの範囲の係数に対して行うかは、圧縮効率に直接関係する非常に重要な要素になる。例えば、JPEG方式やMPEG方式では、8×8のブロックに対してDCT(Discrete Cosine Transform)変換を施し、生成された64個のDCT変換係数に対してハフマン符号化を行うことで、情報を圧縮している。すなわち、64個のDCT変換係数がエントロピ符号化の範囲になる。
ウェーブレット変換部161では、8×8ブロックに対するDCT変換とは異なり、ライン単位でウェーブレット変換を施しているため、エントロピ符号化部163では、周波数帯域(サブバンド)毎に独立に、且つ各周波数帯域内をPライン毎に情報源符号化する。
Pは1ラインが最低であるが、ライン数が少ない場合には参照情報が少なくて済み、メモリ容量を減らすことができる。逆に、ライン数が多い場合には情報量がその分増えるため、符号化効率が向上させることができる。しかしながら、Pが各周波数帯域内のラインブロックのライン数を超えた値になると、次のラインブロックのラインまで必要になる。このため、このラインブロックの量子化係数データがウェーブレット変換及び量子化によって生成されるまで待たなければならず、この時間が遅延時間となってしまう。
したがって、低遅延のためには、Pはラインブロックのライン数以下である必要がある。例えば、図6の例では、1LL,1HL,1LH,1HHの周波数帯域については、ラインブロックのライン数=1ラインであるためP=1となる。また、2HL,2LH,2HHのサブバンドについては、ラインブロックのライン数=2ラインであるためP=1または2となる。
レート制御部141は、最終的に目標のビットレート又は圧縮率に合わせるための制御を行い、レート制御後の符号化データをRTP部164に供給する。例えば、このレート制御部141は、エントロピ符号化部163から出力される符号化データのビットレート(圧縮率)を目標値と比較し、ビットレートを上げる場合には量子化ステップサイズを小さくし、ビットレートを下げる場合には量子化ステップサイズを大きくするように、量子化部162に対して制御信号を送信する。
RTP部164は、レート制御部141から供給される符号化データをRTPパケット化し、FEC部132に供給する。
[受信装置の構成]
次に、図1の受信装置103の各受信部113の内部の構成例について説明する。図7は、受信部113の主な構成例を示すブロック図である。図7に示されるように、受信部113は、受信部201、受信バッファ202、RTP部203、FEC部204、復号部205、ARQ部206、RTCP部207、受信バッファ時間設定部208、およびメディア同期部210を有する。
受信部201は、ネットワーク102を介して、自分自身に対応する送信装置101から伝送され、伝送部111を介して供給されたRTPパケットを受信し、それを受信バッファ202に供給する。受信バッファ202は、例えば、他の受信部113によるデータ伝送と同期をとるために、受信部201から供給されるRTPパケットを、一時的に保持した後、受信バッファ時間設定部208やメディア同期部210からの情報に基づいて決定される時刻に、RTP部203に供給する。
RTP部203は、RTPパケットを再構成して、冗長パケットを含む符号化データであるFEC冗長符号化データを生成し、それをFEC204に供給する。FEC部204は、パケットの損失の検出を行い、必要に応じて冗長符号化復号処理によって損失パケットデータを回復する。FEC部204は、処理後の符号化データを復号部205に供給する。
復号部205は、符号化データを、符号化部131による符号化処理の方式に対応する復号方式により復号する。復号されたビデオデータ(動画像データ)は、受信装置103のビデオ出力IF(ビデオOUT)から、例えば、ディスプレイ等の映像表示装置(図示せず)に出力される。
ARQ部206は、受信部201における損失パケット(受信できなかったパケット)の検出を行い、損失パケットを検出した場合、RTCP部207を制御し、送信装置101のARQ部138に対する再送要求メッセージを送信させる。RTCP部207は、ARQ部206から要求された再送要求メッセージや、受信バッファ時間設定部208から供給される各種設定情報をRTCPメッセージとして、送信装置101のRTCP部137に供給する。
受信バッファ時間設定部208は、統合受信バッファ時間調整部114の制御等に基づいて、受信バッファ時間の設定や調整を行う。
メディア同期部210は、基準信号同期部112により、各受信部113(および各送信装置101)で同期がとられた基準信号に基づいて、受信バッファ202のRTPパケット出力タイミングや、復号部205の復号処理開始タイミング等を制御する。
[復号部の構成例]
次に、上述した符号化部131の例に対応する復号部205の例について説明する。図8は、受信部113の復号部205の構成例を示すブロック図である。図8において、復号部205は、RTP部230、エントロピ復号部231、逆量子化部232、およびウェーブレット逆変換部233を有する。
RTP部230は、FEC部204から供給されるRTPパケットを符号化データに変換し、それをエントロピ復号部231に供給する。エントロピ復号部231は、エントロピ符号化部163の符号化方法に対応する方法で符号化データを復号し、量子化係数データを生成する。例えば、ハフマン復号や、高効率な算術復号などを用いることができる。なお、エントロピ符号化部163においてPラインごとに符号化されている場合、エントロピ復号部231は、各サブバンドを独立に復号し、かつ、各サブバンド内をPライン毎に復号する。
逆量子化部232は、量子化係数データに量子化ステップサイズを乗算することにより逆量子化し、係数データを生成する。この量子化ステップサイズは、通常、送信装置101から供給される符号化データのヘッダなどに記述されている。なお、量子化部162において、ラインブロック毎に量子化ステップサイズが設定されている場合には、逆量子化部232においても同様に、ラインブロック毎に逆量子化ステップサイズが設定されて、逆量子化される。
ウェーブレット逆変換部233は、ウェーブレット変換部161の逆処理を行う。つまり、ウェーブレット逆変換部233は、ウェーブレット変換部161により複数の周波数帯域に分割された係数データに対して、低域成分と高域成分を合成するフィルタ処理(合成フィルタ処理)を水平方向と垂直方向の両方に対して行う。ウェーブレット逆変換部233は、このようはウェーブレット逆変換処理により、ベースバンドのビデオデータを復元し、ビデオOUTから受信装置103の外部に出力する。
もちろん、上述した符号化部131および復号部205は、一例であり、これ以外の符号化・復号方式を用いるようにしてもよい。
[伝送処理]
次に、伝送システム100(図1)において行われる各処理について説明する。最初に、ビデオデータを各送信装置101からネットワーク102を介して受信装置103に伝送する伝送処理について説明する。
送信装置101は、ビデオカメラ等を経由しビデオ入力IF「ビデオIN」より入力したビデオデータを、動画像データの圧縮符号化処理を行う符号化部131(図2)に入力し、符号化する。
この符号化により生成された符号化データは、符号化部131内部のRTP部164(図3)によりRTPパケット化処理を施され、RTPパケットとしてFEC部132(図2)に供給される。FEC部132は、供給されたRTPパケットに対してFEC冗長符号化処理を施し、冗長パケットを生成する。FEC部132は、生成した冗長パケットを元データのRTPパケットとともにRTP部133に供給する。
RTP部133は、FEC部132から供給された冗長パケットをRTPパケット化する。平滑化部134は、RTP部133から供給されるRTPパケットを、レートを平滑化してネットワーク102に送信する。各RTPパケットには、メディア同期部136により指定された同期用RTPタイムスタンプがRTP部164(図3)若しくはRTP部133(図2)においてセットされる。
図1において、受信装置103は、複数の送信装置101より送信されたRTPパケットを、一旦、伝送部111で受信し、送信装置101毎に対応する受信部113に振り分ける。例えば送信装置101−K(K=1,2,..,N)から送信されたRTPパケットは受信部113−Kへ振り分けられる。
受信部113は、RTPパケットを、受信部201(図7)を経由して受信バッファ202に供給し、保存させる。このとき損失パケットが検出された場合、その旨がARQ部206に通知される。その通知を受けるとARQ部206は、再送要求処理を行う。
受信バッファ202は、受信バッファ時間設定部208により決定された受信バッファ時間と、メディア同期部210から通知される時刻情報と、各RTPパケットにセットされたRTPタイムスタンプ値とから、受信バッファ202からRTPパケットを出力させる時刻である受信バッファ出力時刻を決定し、その時刻に各RTPパケットをRTP部203に出力する。
RTP部203は、RTPパケットを再構成し、得られたFEC冗長符号化データをFEC部204に供給する。FEC部204は、データ伝送時に損失したパケットである損失パケットが検出された場合、冗長符号化復号処理により損失パケットデータの回復を行う。FEC部204は、処理後のRTPパケットを復号部205へ出力する。復号部205は、RTPパケットより符号化データを抽出し、その符号化データに対して復号処理を行い、ベースバンドのビデオデータを生成する。復号されたビデオデータは合成部115(図1)に供給される。
合成部115は、複数の受信部113からのビデオデータ画像を合成しビデオ出力IF「ビデオOUT」より、例えば、ディスプレイ等の映像表示装置に出力する。
[基準信号同期処理]
次に、基準信号を同期させる基準信号同期処理について説明する。基準信号同期部112(図1)は、IEEE 1588 PTP(Precision Time Protocol)を用い、送信装置101および受信装置103間の基準信号クロックの同期を行う。なお、基準信号クロックの周波数として、例えば、入力ビデオ画像のピクセルサンプリング周波数を用いるようにしてもよい。この場合、「ビデオIN」から入力するビデオ出力装置との同期も行うようにすることができる。
なお、受信装置103が、基準信号同期部112を備えず、送信装置101と受信装置103との間で同期を行わないようにしてもよい。
図1に示されるように、送信装置101が複数の場合、受信装置103がマスタとなり、全ての送信装置101を受信装置103と同期させるようにしてもよい。その場合、受信装置103が、全ての送信装置101と同期を取ることにより結果的に全ての送信装置101および受信装置103の間で同期を取ることができる。
[メディア同期処理]
送信装置101のメディア同期部136(図2)は、基準信号同期部135より通知された時刻を基に、「ビデオIN」より入力されたデータのサンプリング時刻と同期した時刻を、RTPタイムスタンプの周波数に変換し、符号化部131内のRTP部164(図3)およびRTP部133(図2)にて各RTPパケットにRTPタイムスタンプとして付加する。
受信装置103のメディア同期部210(図7)は、基準信号同期部112(図1)より通知された基準クロック時刻情報をRTPタイムスタンプ周波数に変換したシステム時刻として保持する。受信装置103の受信バッファ202(図7)は、RTPパケットが記録されると、RTPパケットのRTPタイムスタンプ値と、受信バッファ時間設定部208から通知される受信バッファ時間と、メディア同期部210から供給されるRTPタイムスタンプ周波数時刻とから、各RTPパケットの受信バッファ出力時刻を決定する。受信バッファ202は、その受信バッファ出力時刻に、保持しているRTPパケットをRTP部203に供給する。
RTPパケットの受信バッファ出力時刻は、以下のように設定される。例えば、符号化データの先頭パケットは、受信した時刻から受信バッファ時間TSTIME_BUF経過した時刻後に受信バッファから出力されるものとし、後続パケットは、先頭パケットのRTPタイムスタンプ値と当該パケットのRTPタイムスタンプ値との差分値から算出される時刻に同期出力されるものとする。
RTPパケットnの受信バッファ出力時刻TSSYS_BO_nは、例えば、以下の式(1)により算出される。符号化データの先頭パケットのRTPタイムスタンプ値をTSPKT_initとし、受信時刻(システム時刻換算:周波数はRTPタイムスタンプ周波数)をTSSYS_initとし、RTPパケットnのRTPタイムスタンプ値をTSPKT_nとする。
TSSYS_BO_n=(TSPKT_n−SPKT_init)+TSSYS_init+TSTIME_BUF ・・・(1)
[コーデック処理]
符号化部131は、例えば、特許文献1で提案されている動画像の各ピクチャの数ライン毎を1つの圧縮符号化ブロックとしてウェーブレット変換する階層符号化方式であり、かつ、階層毎に関連する入力データ範囲の異なる符号化方式を用いる。
送信装置101の符号化部131(図2)は、符号化処理を行い、受信装置103における復号部205(図7)は、復号処理を行う。
送信装置101の符号化部131(図2)は、内部処理部としてレート制御部141を有する。レート制御部141は、例えば、ITU-T Y.1221記載のトークンバケットビヘビアにおける、バケツサイズをエンコーダ想定バッファサイズB(byte)とし、バケットレートR(bps)をエンコードレートとして、バケットがあふれないようにエンコードレートを制御するレート制御を行う。これを平滑化伝送したときに受信装置103で必要となるバッファ時間を可変圧縮符号化遅延時間と定義する。
可変圧縮符号化遅延時間Bt_codec(sec)は、例えば、以下の式(2)で表すことができる。
Bt_codec=B×8/R ・・・(2)
エンコーダ想定バッファサイズBは、ユーザ等により指定される画像品質要求に応じて決定される。VBR方式による圧縮符号化の場合、エンコーダ想定バッファサイズBを大きくとることにより、複雑度の高い画像部分により多くのデータ量を使用することができ、画質を向上させることができる。つまり、画像品質要求が高い場合、このエンコーダ想定バッファサイズBを大きくとることでその高い要求に応じることができる。
ただし、エンコーダ想定バッファサイズBを大きくとると、可変圧縮符号化遅延要求時間Bt_codec_req(sec)が大きくなるので、遅延が増加する恐れがある。
[RTCP処理]
次に、各送信装置101と受信装置103との間で行われるQoS制御処理のRTCP処理について説明する。RTCP部137(図2)およびRTCP部207(図7)は、IETF RFC 3550記載のRTCPを用いて、送信装置101と受信装置103との間でRTCPメッセージの送受信を行い、パケット損失率、往復伝搬遅延(RTT)、およびネットワークジッタ等の情報収集や、QoS制御処理のための制御メッセージの送受信を行う。QoS制御メッセージとしては、例えば、ARQ処理における再送要求メッセージ等がある。
[FEC処理]
次に、QoS制御処理のFEC処理について説明する。FEC部132(図2)は、符号化部131から供給される符号化データのRTPパケットを単位として、FEC冗長符号化を行う。例えば、FEC部132は、Reed-Solomon符号等の消失誤り訂正符号を用い冗長符号化を行う。
FEC冗長符号化における冗長度は、例えば、ユーザ等により指定される伝送品質要求により決定される。冗長度は、(元データパケット数,冗長パケット数)という形で指定される。ユーザは、また、ネットワークの想定パケット損失率pも指定する。
以下においては、(元データパケット数,冗長パケット数)の組を1つの冗長符号単位(所謂FECブロック)とする。例えば、(元データパケット数,冗長パケット数)=(10,5)と指定された場合、送信装置101のFEC部132は、元データパケット数10個に対して、冗長パケットを5個生成する。つまり、このFECブロックにおいては合計15個のパケットが送信される。
この場合、受信装置103のFEC部204(図7)は、このFECブロックパケット中の任意の10個のパケットを受信すれば、FEC復号処理により元データを復号することができる。例えば、ユーザにより指定されたパケット損失率をpとし、FECブロック内のパケット数をnとし、元データパケット数をkとし、冗長パケット数をn-kとし、ユーザにより伝送品質要求として指定される目標FECブロック損失率をPtとすると、目標FECブロック損失率Ptは、以下の式(3)のように表される。
Figure 0005672840
・・・(3)
この式(3)を満たすように元データパケット数kおよび冗長パケット数n-kが決定される。
図1において、受信装置103(FEC部204(図7))では、FEC冗長復号化処理により損失パケット回復を行うために、FECブロックの先頭パケットが受信装置103に到着してから末尾のパケットが到着するまでの時間(所謂、冗長符号化ブロック受信待ち時間)以上に受信バッファ時間を設定する必要がある。
ユーザ等により指定される伝送品質要求に応じて設定されたFECブロックに対応する冗長符号化ブロック受信待ち時間を「冗長符号化ブロック受信待ち要求時間」と称する。
[ARQ処理]
図1の受信装置103におけるARQ処理では、受信部201(図7)がRTPパケットのシーケンス番号を利用して損失したパケットを検知し、ARQ部206がその損失パケットの再送要求メッセージを生成し、RTCP部207が、送信装置101に対してその再送要求メッセージを送信し、再送要求を行う。
なお、受信装置103のARQ部206が、パケット損失に対して再送要求を行い、往復伝搬時間(ARQ再送パケット待ち時間)経過しても受信部201が再送パケットを受信しなかった場合、再度、再送要求を行うようにしてもよい。さらに、ARQ部206が、当該パケットの受信バッファ出力時刻に再送パケット到着が間に合わないと決定されるまで、このような再送要求を繰り返すようにしてもよい。
送信装置101におけるARQ処理では、RTCP部137(図2)が再送要求メッセージを受け取ると、ARQ部138が再送すべきRTPパケット(再送パケット)を生成し、その再送パケットを平滑化部134に供給し、再送させる。
ARQ処理における回復性能は、受信装置103における、ARQ部206(図7)の要求により再送される再送パケットを待つ時間であるARQ再送パケット待ち時間に依存する。ARQ再送パケット待ち時間が大きいほど回復性能は向上するが、ARQ再送パケット待ち要求時間以上の受信バッファ時間が必要となるので、遅延が増大する恐れがある。
この「ARQ再送パケット待ち要求時間」は、ユーザ等により指定される伝送品質要求により決定される。
[ネットワークジッタ対応処理]
受信装置103の受信バッファ202(図7)は、ネットワークジッタ対応処理機構も兼ね備える。受信バッファ202は、ユーザ等により指定される伝送品質要求により決定された「ネットワークジッタ対応バッファ要求時間」以上の時間を受信バッファ時間としてセットする。これにより「ネットワークジッタ対応バッファ要求時間」以下のジッタを受けたパケットの同期処理が可能となる。
[データ伝送全体処理]
次に、伝送システム100において実行されるデータ伝送処理の全体の流れの例を、図9のフローチャートを参照して説明する。
データ伝送を開始する前に、各受信部113のRTCP部207は、ステップS121において、自分自身に対応する送信装置101と通信を行い、ネットワーク状況を測定する。これに対して、各送信装置101のRTCP部137も、ステップS101において、ネットワーク状況を測定する。
つまり、最初に、RTCP部137とRTCP部207との間で行われるパケットの授受によって、ネットワーク102の通信に関する状況(ネットワーク状況情報)が観測される。
RTCP部137は、符号化データの伝送を開始する前に、ネットワーク状況事前計測用のダミーデータを送信する。そのダミーデータは、ネットワーク102を介してRTCP部207に伝送される。RTCP部207は、そのダミーデータを受信し、パケットに記述される送信時の情報と、受信時の状況からネットワーク状況の計測(事前計測)を行う。
ネットワーク状況情報を取得すると、受信バッファ時間設定部208は、ステップS122において、受信バッファ時間決定処理を行い、受信部113内の設定を行ったり、送信装置101に、受信バッファ時間に関する通知を行ったりする。
送信装置101の受信バッファ時間・処理パラメータ設定部139は、ステップS102において受信バッファ時間・処理パラメータ設定処理を行い、受信装置103からの通知を受け、各種パラメータの設定を行う。
送信装置101および受信装置103は、それぞれ、ステップS103とステップS123において、互いに連携しながら、ビデオデータのRTPパケットを送信装置101から受信装置103に伝送するデータ伝送処理を行う。
[受信バッファ時間決定処理]
次に、図9のステップS122において実行される受信バッファ時間決定処理の流れの例を図10のフローチャートを参照して説明する。
この受信バッファ時間決定処理では、全ての受信部113が同期するように、受信バッファ時間の調整が行われる。ここでいう同期とは、同時刻にキャプチャされたデータを含むパケットが全ての受信部113に入力した場合、受信バッファ202から同じタイミングで出力されるように調整することを示す。
同期出力を行うためには、図11に示されるように、伝送遅延時間(伝送遅延の長さ)の差異を考慮して調整する必要がある。
ステップS141において、統合受信バッファ時間調整部114は、各受信部113が行うデータ伝送の伝送遅延の中で、最長の遅延時間である最大伝送遅延時間を求める。この最大伝送遅延時間は、以下の式(4)のように求められる。
最大伝送遅延時間=MAX(伝送遅延時間1,伝送遅延時間2,…,伝送遅延時間N)
・・・(4)
なお、式(4)において、MAX()は、最大値を計算する関数である。
ステップS142において、統合受信バッファ時間調整部114は、処理対象とする受信部を、データ伝送に用いる受信部113の内、未処理のものの中から選択する。
ステップS143において、処理対象に選択された受信部113の受信バッファ時間設定部208は、最大伝送遅延時間、この受信部113によるデータ伝送の伝送遅延時間、および規定受信バッファ時間を用いて受信バッファ時間を算出する。
規定受信バッファ時間は、符号化処理やQoS制御処理で必要となる最低限の受信待ち時間であり、予め定められている。受信バッファ時間は、各送信装置101からのデータ伝送の間の伝送遅延の差を吸収して同期をとるためのバッファ時間である。受信バッファ時間には、規定受信バッファ時間も含まれる。つまり、各データ伝送の伝送遅延の長さに応じて、規定受信バッファ時間を調整したもの(一般的に、長くしたもの)が受信バッファ時間である。
受信バッファ時間は、以下の式(5)のように算出することができる。
受信バッファ時間K=最大伝送遅延時間−伝送遅延時間K+規定受信バッファ時間
・・・(5)
ただし、K=1,・・・,N
例えば、各送信装置101のデータ伝送の、送信装置101における処理による遅延時間である送信装置処理遅延251と、ネットワーク102を伝送する際の遅延時間である伝送遅延252が図11の上段に示される例のようであるとする。
この例の場合、送信装置101−1の伝送遅延252−1が最も長い。そこで、この伝送遅延252−1が、最大伝送遅延時間とされる。
図11の下段に示されるように、送信装置101−1のデータ伝送の受信バッファ時間254−1は、規定受信バッファ時間253と同じ長さになる。これに対して、他の送信装置101のデータ伝送の受信バッファ時間254においては、伝送遅延の長さの差分が規定受信バッファ時間253に追加される。
したがって、送信装置処理遅延、伝送遅延、および受信バッファ時間の和は、各データ伝送において共通となる。したがって、データ伝送全体の遅延時間は増大しない。
このように受信バッファ時間をできるだけ長く設定し、その受信バッファ時間の長さに応じて、符号化処理やQoS制御処理等のパラメータの設定を調整することにより、送信装置101および受信装置103は、データ伝送全体の遅延時間を増大させずに、画像品質や伝送品質を向上させるようにパラメータ設定を行うことができる。
図10に戻り、以上のように受信バッファ時間が算出されると、ステップS144において、受信バッファ時間設定部208は、その受信バッファ時間から、可変圧縮符号化遅延時間、冗長符号化ブロック受信待ち時間、ARQ再送パケット待ち時間、およびネットワークジッタ対応バッファ時間等、各種遅延時間や待ち時間を設定する。
ある送信装置101−K(K=1,・・・,N)や、その送信装置に対応する受信部113−Kにおける各処理における設定値「可変圧縮符号化遅延時間K」、「冗長符号化ブロック受信待ち時間K」、「ARQ再送パケット待ち時間K」、および「ネットワークジッタ対応バッファ時間K」は、「受信バッファ時間K」から、以下の式(6)により計算される。
可変圧縮符号化遅延時間K
=冗長符号化ブロック受信待ち時間K
=ARQ再送パケット待ち時間K
=ネットワークジッタ対応バッファ時間K
=受信バッファ時間K
・・・(6)
ただし、K=1,・・・,N
以上のように、各時間が設定されると、受信バッファ時間設定部208は、ステップS145において、「ARQ再送パケット待ち時間」を、ARQ部206に設定し、再送要求を行うかどうかの判定に使用させる。
また、ステップS146において、受信バッファ時間設定部208は、「ネットワークジッタ対応バッファ時間」を受信バッファ202に設定する。
ステップS147において、受信バッファ時間設定部208は、「可変圧縮符号化遅延時間」、および「冗長符号化ブロック待ち時間」を、例えば、RTCP部207を介して、RTCPメッセージとして、処理対象の受信部113が対応する送信装置101へ通知する。
ステップS148において、統合受信バッファ時間調整部114は、全ての受信部113を処理したか否かを判定し、データ伝送に用いる受信部113の内、未処理のものが存在すると判定された場合、処理をステップS142に戻し、新たな処理対象を選択し、その新たな処理対象についてそれ以降の処理を繰り返す。
また、ステップS148において、全ての受信部113を処理したと判定された場合、受信バッファ時間決定処理が終了され、図9のステップS122に処理が戻され、それ以降の処理が行われる。
[受信バッファ時間・処理パラメータ設定処理]
次に、図12のフローチャートを参照して、図9のステップS102において実行される受信バッファ時間・処理パラメータ設定処理を説明する。
受信バッファ時間・処理パラメータ設定処理が開始されると、受信バッファ時間・処理パラメータ設定部139は、ステップS161において、RTCP部137を介して、受信装置103から供給されるRTCPメッセージに含まれる「可変圧縮符号化遅延時間」および「冗長符号化ブロック待ち時間」を取得する。
ステップS162において、受信バッファ時間・処理パラメータ設定部139は、「可変圧縮符号化遅延時間」を符号化部131に設定する。ステップS163において、受信バッファ時間・処理パラメータ設定部139は、「冗長符号化ブロック待ち時間」をFEC部132に設定する。
レート制御部141は、ステップS164において、供給された「可変圧縮符号化遅延時間」を用いて、レート制御パラメータを設定する。例えば、レート制御部141は、以下の式(7)を満たすように、エンコーダ想定バッファサイズB(byte)を設定する。なお、式(7)において、Bt_codec(sec)は可変圧縮符号化遅延時間を示す。また、R(bps)はパケットレートを示す。
Bt_codec=B×8/R ・・・(7)
FEC部132は、ステップS165において、「冗長符号化ブロック受信待ち時間」を用いてFECブロックパラメータを設定する。「冗長符号化ブロック待ち時間」は、FECブロックに含まれるパケット全ての平滑化伝送にかかる時間の最大値である。FEC部132は、この時間が「冗長符号化ブロック待ち時間」以下となるように、FECブロック毎の元データパケット数を調整する。さらに、FEC部132は、例えば、上述した式(3)を満たすように、冗長パケット数n−kを設定する。
ステップS165の処理が終了すると、受信バッファ時間・処理パラメータ設定部139は、受信バッファ時間・処理パラメータ設定処理を終了し、処理を図7のステップS101に戻し、ステップS102の処理を行う。
以上のように各種設定を行うことにより、送信装置101および受信装置103は、遅延を増大させない程度に、各遅延時間や待ち時間をできるだけ長く確保することができ、その時間的余裕を、画像品質や伝送品質の向上に利用することができる。
より具体的には、送信装置101は、遅延を増大させない程度に、符号化部131の「可変圧縮符号化遅延時間」をより長く設定し、エンコーダ想定バッファサイズB(byte)をより大きく設定することができる。また、送信装置101は、遅延を増大させない程度に、FEC部132の「冗長符号化ブロック待ち時間」をより長く設定し、FECブロックや冗長度をより大きく設定することができる。
受信装置103は、遅延を増大させない程度に、ARQ部206の「ARQ再送パケット待ち時間」をより長く設定することができる。また、受信装置103は、遅延を増大させない程度に、受信バッファ202の「ネットワークジッタ対応バッファ時間」をより長く設定することができる。
以上のように、送信装置101および受信装置103は、各処理の時間的余裕を活用し、画質や伝送品質の向上に利用することにより、遅延時間上の無駄を低減させることができる。つまり、送信装置101および受信装置103は、上述したようなデータ伝送に関する各種処理によるコンテンツの品質の劣化を抑制することができる。
<2.第2の実施の形態>
[伝送システムの構成]
なお、以上においては、ネットワーク状況のみに従って受信バッファ時間の調整が行われるように説明したが、これに限らず、例えば、ユーザ等に画像品質や伝送品質に対する要求を入力させ、その入力に基づいて受信バッファ時間の調整が行われるようにしてもよい。
また、受信バッファ時間は、データ伝送中に更新されるようにしてもよい。
図13は、その場合の伝送システムの構成例を示すブロック図である。
図13に示される伝送システム300は、基本的に図1の伝送システム100と同様のシステムであるが、受信装置103の代わりに、受信装置303を有する。受信装置303は、基本的に受信装置103と同様の装置であるが、受信装置103の構成に加えて、入力部311および出力部312を有する。
入力部311は、例えば、キーボード、マウス、タッチパネル、若しくはスイッチ等の任意の入力デバイス、または外部入力端子等よりなり、例えばユーザ等の、受信装置303外部からの画像品質要求や伝送品質要求を受け付け、それを統合受信バッファ時間調整部114に供給する。
出力部312は、例えば、モニタやスピーカ等の任意の出力デバイス、または、外部出力端子等よりなり、統合受信バッファ時間調整部114から供給されるGUI画像を表示したり、音声を出力したりして、画像品質要求や伝送品質要求の入力案内や、入力結果を出力する。
図14は、画像品質要求および伝送品質要求等を受け付けるGUIである要求受付画面の表示例を示す図である。図14に示されるように、要求受付画面321には、表示部322と要求部323とが設けられている。要求部323は、ユーザにより入力可能な項目が示される。表示部322には、ユーザにより情報が入力された結果が表示される。
要求部323には、例えば、「使用者要求」として、「画質要求」(画像品質要求)や「伝送品質要求」を入力することができることが示されている。例えば、画像品質を指定する場合、ユーザは、「画質要求」を選択し、要求する品質(例えばPSR値等)を入力する。また、例えば、伝送品質を指定する場合、ユーザは、「伝送品質要求」を選択し、要求する品質(例えばQoS制御後パケット損失率等)を入力する。
なお、要求部323においては、ユーザは、受信バッファ時間を指定することもできる。例えば、ユーザが、「受信バッファ時間」を選択し、要求する時間を入力することにより、「受信バッファ時間」として許容される最長の時間が設定される。
表示部322には、このように要求部323において入力された情報が反映された各種情報が表示される。
例えば、表示部322には、「ネットワーク状況」として「伝送遅延」が送信装置毎に表示される。もちろん、これ以外の情報が表示されるようにしてもよい。
また、例えば、表示部322には、「処理要求時間」として「可変圧縮符号化遅延要求時間」、「冗長符号化ブロック受信要求待ち時間」、「ARQ再送パケット待ち要求時間」、および「ネットワークジッタ対応バッファ要求時間」等が表示される。
さらに、例えば、表示部322には、受信バッファ時間として推奨される「推奨受信バッファ時間」が送信装置毎に表示される。
このようなGUIに基づいて要求を入力することにより、ユーザは、画像品質要求、伝送品質要求、および受信バッファ時間等をより容易に設定することができる。
[データ伝送全体処理]
図15のフローチャートを参照して、この場合のデータ伝送処理の流れの例を説明する。
この場合、図15に示されるように、受信装置303は、最初に、ステップS321において、入力部311や出力部312を制御し、画像品質要求や伝送品質要求を受け付ける。画像品質要求は、復号画像(受信装置303から出力されるビデオデータの画像)の画質に対する要求である。伝送品質要求は、ネットワーク102のパケットロス率等に対する要求である。受信装置303は、受け付けた画像品質要求や伝送品質要求を、各種パラメータの設定に利用する。
それ以降の処理は、図9のフローチャートを参照して説明した場合と同様である。つまり、図15のステップS301乃至ステップS303の各処理は、図9のステップS101乃至ステップS103の各処理に対応し、図15のステップS322乃至ステップS324の各処理は、図9のステップS121乃至ステップS123の各処理に対応する。
ただし、図15のステップS323において、受信バッファ時間決定処理は、ステップS321において受け付けられた要求を用いて行われる。また、図15のステップS303とステップS324においては、データ伝送を行いながら受信バッファ時間の更新を行う受信バッファ動的変更伝送処理が行われる。
[受信バッファ時間決定処理]
次に、図15のステップS323において実行される受信バッファ時間決定処理の流れの例を図16および図17のフローチャートを参照して説明する。
この場合も、基本的に図10のフローチャートを参照して説明した場合と同様に各処理が行われる。ただし、この場合、最大伝送遅延時間を求める前に、統合受信バッファ時間調整部114は、規定受信バッファ時間を用いる代わりに、各受信部113の仮の受信バッファ時間(仮受信バッファ時間)を求める。
つまり、統合受信バッファ時間調整部114は、ステップS341において、処理対象とする受信部113を選択し、ステップS342において、その処理対象の受信部113のデータ伝送について、画像品質要求および伝送品質要求を用いて、「可変圧縮符号化遅延要求時間」、「冗長符号化ブロック受信待ち要求時間」、「ARQ再送パケット待ち要求時間」、および「ネットワークジッタ対応バッファ要求時間」を算出する。
ステップS343において、統合受信バッファ時間調整部114は、算出した「可変圧縮符号化遅延要求時間」、「冗長符号化ブロック受信待ち要求時間」、「ARQ再送パケット待ち要求時間」、および「ネットワークジッタ対応バッファ要求時間」の最大値を仮受信バッファ時間として設定する。
ステップS344において、統合受信バッファ時間調整部114は、データ伝送に用いる全ての受信部113を処理したか否かを判定し、全ての受信部113を処理するまで、ステップS341乃至ステップS344の処理を繰り返す。
全ての受信部113について仮受信バッファ時間を設定すると、統合受信バッファ時間調整部114は、処理をステップS345に進め、図10のステップS141の場合と同様に、最大伝送遅延時間を求める。
つまり、この場合、伝送遅延を考慮せずに算出される各受信部113の受信バッファ時間は、共通の規定受信バッファ時間ではなく、個別に設定された仮受信バッファ時間であり、その長さが互いに異なる可能性を有する。
しかしながら、この場合も、受信バッファ時間の算出方法は図10の場合と基本的に同様であり、図17のステップS351乃至ステップS357の各処理は、規定受信バッファ時間の代わりに仮受信バッファ時間の最大値(最大伝送遅延時間)が適用されること以外、図10のステップS142乃至ステップS148の各処理と同様に行われる。
また、各送信装置101による受信バッファ時間・処理パラメータ設定処理は、図12のフローチャートを参照して説明した場合と同様に行われる。
以上のように、ユーザ等から画像品質要求や伝送品質要求を受け付け、その要求に応じて受信バッファ時間を決定する場合も、第1の実施の形態と同様に、各処理の時間的余裕を画質や伝送品質の向上により有効に利用することができるようにし、遅延時間上の無駄をより低減させることができる。つまり、コンテンツの品質の劣化をより抑制することができる。
[受信バッファ動的変更伝送処理]
次に、図18のフローチャートを参照して、送信装置101および受信装置303により行われる受信バッファ動的変更伝送処理の流れの例を説明する。
ステップS371において、送信装置101の各部は、一定時間データ転送を行う。この処理に対応して、受信装置303の各部は、ステップS391において、一定時間データ転送を行う。
受信装置303のRTCP部207は、ステップS392において、RTCP部137とデータの送受信を行い、ネットワーク状況を測定し、ネットワーク状況情報を更新する。この処理に対応して、送信装置101のRTCP部137は、ステップS372において、ネットワーク状況を測定し、ネットワーク状況情報を更新する。
ステップS393において、受信装置303の受信バッファ時間設定部208は、更新されたネットワーク状況情報に基づいて、受信バッファ時間決定処理を行い、「可変圧縮符号化遅延要求時間」、「冗長符号化ブロック受信待ち要求時間」、「ARQ再送パケット待ち要求時間」、および「ネットワークジッタ対応バッファ要求時間」等を更新し、その更新された各種要求時間に応じて、「可変圧縮符号化遅延時間」、「冗長符号化ブロック受信待ち時間」、「ARQ再送パケット待ち時間」、および「ネットワークジッタ対応バッファ時間」等の設定を、例えば式(4)や式(5)を用いて更新する。
この受信バッファ時間決定処理は、図16および図17の場合と同様に行われる。
この処理に対応し、ステップS373において、送信装置101の受信バッファ時間・処理パラメータ設定部139は、受信バッファ時間・処理パラメータ設定処理を行う。この処理は、図12の場合と同様に行われる。
符号化データの伝送開始後の場合、受信バッファ時間・処理パラメータ設定部139は、符号化データ伝送を利用してRTCP部137により計測されたネットワーク状況情報に含まれるパケット損失率pを用い、式(3)を満たすように、元データパケット数kや冗長パケット数n-kを決定する。
ステップS374において、送信装置101は、伝送を終了するか否かを判定し、伝送を終了すると判定された場合、処理をステップS371に戻し、それ以降の処理を実行させる。また、ステップS374において、伝送を終了すると判定された場合、送信装置101による受信バッファ動的変更伝送処理が終了される。
また、ステップS394において、受信装置303は、伝送を終了するか否かを判定し、伝送を終了すると判定された場合、処理をステップS391に戻し、それ以降の処理を実行させる。また、ステップS394において、伝送を終了すると判定された場合、受信装置303による受信バッファ動的変更伝送処理が終了される。
以上のように、ユーザ等からの要求だけでなく、ネットワーク状況にも応じて、パラメータ等の設定を行うようにすることにより、送信装置101および受信装置303は、より実際の状況に応じてより効率よく画質や伝送品質の設定を行うことができ、遅延時間上の無駄をより低減させることができる。つまり、送信装置101および受信装置303は、コンテンツの品質の劣化を抑制することができる。
以上のように、複数の送信装置から動画像を伝送し受信装置にて同期処理を行い、可変圧縮符号化処理、FEC等のQoS制御処理を行う場合において、伝送遅延時間の小さいデータ伝送に対してより大きな可変圧縮符号化要求時間、冗長符号化ブロック受信待ち時間、ARQ再送パケット待ち時間、およびネットワークジッタ対応バッファ時間を設定する事ができ、これにより、映像画質や伝送品質を最大限向上させることができる。
なお、以上においては、伝送するビデオデータを符号化するように説明したが、これに限らず、非圧縮のまま伝送するようにしてもよい。
<3.第3の実施の形態>
[パーソナルコンピュータ]
上述した一連の処理は、ハードウエアにより実行させることもできるし、ソフトウエアにより実行させることもできる。この場合、例えば、図19に示されるようなパーソナルコンピュータとして構成されるようにしてもよい。
図19において、パーソナルコンピュータ400のCPU(Central Processing Unit)401は、ROM(Read Only Memory)402に記憶されているプログラム、または記憶部413からRAM(Random Access Memory)403にロードされたプログラムに従って各種の処理を実行する。RAM403にはまた、CPU401が各種の処理を実行する上において必要なデータなども適宜記憶される。
CPU401、ROM402、およびRAM403は、バス404を介して相互に接続されている。このバス404にはまた、入出力インタフェース410も接続されている。
入出力インタフェース410には、キーボード、マウスなどよりなる入力部411、CRT(Cathode Ray Tube)やLCD(Liquid Crystal Display)などよりなるディスプレイ、並びにスピーカなどよりなる出力部412、ハードディスクなどより構成される記憶部413、モデムなどより構成される通信部414が接続されている。通信部414は、インターネットを含むネットワークを介しての通信処理を行う。
入出力インタフェース410にはまた、必要に応じてドライブ415が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア421が適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部413にインストールされる。
上述した一連の処理をソフトウエアにより実行させる場合には、そのソフトウエアを構成するプログラムが、ネットワークや記録媒体からインストールされる。
この記録媒体は、例えば、図19に示されるように、装置本体とは別に、ユーザにプログラムを配信するために配布される、プログラムが記録されている磁気ディスク(フレキシブルディスクを含む)、光ディスク(CD-ROM(Compact Disc - Read Only Memory),DVD(Digital Versatile Disc)を含む)、光磁気ディスク(MD(Mini Disc)を含む)、若しくは半導体メモリなどよりなるリムーバブルメディア421により構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに配信される、プログラムが記録されているROM402や、記憶部413に含まれるハードディスクなどで構成される。
なお、コンピュータが実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。
また、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
また、本明細書において、システムとは、複数のデバイス(装置)により構成される装置全体を表すものである。
また、以上において、1つの装置(または処理部)として説明した構成を分割し、複数の装置(または処理部)として構成するようにしてもよい。逆に、以上において複数の装置(または処理部)として説明した構成をまとめて1つの装置(または処理部)として構成されるようにしてもよい。また、各装置(または各処理部)の構成に上述した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置(または処理部)の構成の一部を他の装置(または他の処理部)の構成に含めるようにしてもよい。つまり、本発明の実施の形態は、上述した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能である。
100 伝送システム, 101 送信装置, 102 ネットワーク, 103 受信装置, 111 伝送部, 112 基準信号同期部, 113 受信部, 114 統合受信バッファ時間調整部, 115 合成部, 131 符号化部, 132 FEC部, 133 RTP部, 134 平滑化部, 135 基準信号同期部, 136 メディア同期部, 137 RTCP部, 138 ARQ部, 139 受信バッファ時間・処理パラメータ設定部, 141 レート制御部, 201 受信部, 202 受信バッファ, 203 RTP部, 204 FEC部, 205 復号部, 206 ARQ部, 207 RTCP部, 208 受信バッファ時間設定部, 210 メディア同期部, 300 伝送システム, 303 受信装置, 311 入力部, 312 出力部

Claims (8)

  1. 複数の送信装置から1つの受信装置に、互いに同期がとられたデータを伝送するデータ伝送において、各データ伝送の、伝送路上で発生する遅延時間である伝送遅延の差を用いて、各データ伝送について設定される、前記受信装置において各データの同期をとるためのバッファ時間である受信バッファ時間を調整する調整手段と、
    前記調整手段により調整された前記受信バッファ時間を用いて、各データ伝送のQoS制御処理のパラメータとして、冗長符号化ブロックの先頭パケットから末尾のパケットを受信するまでの時間である冗長符号化ブロック受信待ち時間、再送パケットを待つ時間である再送パケット待ち時間、およびネットワークジッタを吸収するためのネットワークジッタ対応バッファ時間を設定する設定手段と
    を備える情報処理装置。
  2. 前記調整手段は、前記伝送遅延の最大値を求め、各データの前記伝送遅延と前記最大値との差を、予め定められた所定の受信バッファ時間である規定受信バッファ時間に加えたものを、前記受信バッファ時間とする
    請求項1に記載の情報処理装置。
  3. 前記データは伝送元において符号化され、得られた符号化データが伝送され、伝送先において前記符号化データが復号され、
    前記設定手段は、前記データ伝送に関する処理のパラメータとして、前記符号化においてレート制御されて生成された前記符号化データを平滑化伝送する際に必要な可変圧縮符号化遅延要求時間を設定する
    請求項1に記載の情報処理装置。
  4. 前記データの画質に関する要求である画像品質要求、および、前記データ伝送における伝送品質に関する要求である伝送品質要求を受け付ける受付手段をさらに備え、
    前記調整手段は、前記受付手段により受け付けられた前記画像品質要求および前記伝送品質要求に基づいて、前記受信バッファ時間を調整する
    請求項1に記載の情報処理装置。
  5. 前記調整手段は、前記受付手段により受け付けられた前記画像品質要求および前記伝送品質要求に基づいて、仮の前記受信バッファ時間を設定し、前記仮の受信バッファ時間を用いて、前記受信バッファ時間を調整する
    請求項4に記載の情報処理装置。
  6. 前記受付手段により受け付けられる前記画像品質要求および前記伝送品質要求の入力を補助するGUIを表示する出力手段をさらに備える
    請求項4に記載の情報処理装置。
  7. 情報処理装置の情報処理方法であって、
    前記情報処理装置の調整手段が、複数の送信装置から1つの受信装置に、互いに同期がとられたデータを伝送するデータ伝送において、各データ伝送の、伝送路上で発生する遅延時間である伝送遅延の差を用いて、各データ伝送について設定される、前記受信装置において各データの同期をとるためのバッファ時間である受信バッファ時間を調整し、
    前記情報処理装置の設定手段が、調整された前記受信バッファ時間を用いて、各データ伝送のQoS制御処理のパラメータとして、冗長符号化ブロックの先頭パケットから末尾のパケットを受信するまでの時間である冗長符号化ブロック受信待ち時間、再送パケットを待つ時間である再送パケット待ち時間、およびネットワークジッタを吸収するためのネットワークジッタ対応バッファ時間を設定する
    情報処理方法。
  8. データ伝送を行うコンピュータを、
    複数の送信装置から1つの受信装置に、互いに同期がとられたデータを伝送するデータ伝送において、各データ伝送の、伝送路上で発生する遅延時間である伝送遅延の差を用いて、各データ伝送について設定される、前記受信装置において各データの同期をとるためのバッファ時間である受信バッファ時間を調整する調整手段、
    前記調整手段により調整された前記受信バッファ時間を用いて、各データ伝送のQoS制御処理のパラメータとして、冗長符号化ブロックの先頭パケットから末尾のパケットを受信するまでの時間である冗長符号化ブロック受信待ち時間、再送パケットを待つ時間である再送パケット待ち時間、およびネットワークジッタを吸収するためのネットワークジッタ対応バッファ時間を設定する設定手段
    として機能させるためのプログラム。
JP2010180946A 2010-08-12 2010-08-12 情報処理装置および方法、並びにプログラム Expired - Fee Related JP5672840B2 (ja)

Priority Applications (6)

Application Number Priority Date Filing Date Title
JP2010180946A JP5672840B2 (ja) 2010-08-12 2010-08-12 情報処理装置および方法、並びにプログラム
BR112013002848A BR112013002848A2 (pt) 2010-08-12 2011-08-03 aparelho e método de processamento de informação, e, programa
CN201180038506.6A CN103069835B (zh) 2010-08-12 2011-08-03 信息处理装置和方法
EP11816352.6A EP2605459A1 (en) 2010-08-12 2011-08-03 Information processing device, method and program
PCT/JP2011/067802 WO2012020686A1 (ja) 2010-08-12 2011-08-03 情報処理装置および方法、並びにプログラム
US13/814,273 US8964921B2 (en) 2010-08-12 2011-08-03 Information processing apparatus, method, and program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2010180946A JP5672840B2 (ja) 2010-08-12 2010-08-12 情報処理装置および方法、並びにプログラム

Publications (2)

Publication Number Publication Date
JP2012044253A JP2012044253A (ja) 2012-03-01
JP5672840B2 true JP5672840B2 (ja) 2015-02-18

Family

ID=45567655

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010180946A Expired - Fee Related JP5672840B2 (ja) 2010-08-12 2010-08-12 情報処理装置および方法、並びにプログラム

Country Status (6)

Country Link
US (1) US8964921B2 (ja)
EP (1) EP2605459A1 (ja)
JP (1) JP5672840B2 (ja)
CN (1) CN103069835B (ja)
BR (1) BR112013002848A2 (ja)
WO (1) WO2012020686A1 (ja)

Families Citing this family (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5598155B2 (ja) * 2010-08-12 2014-10-01 ソニー株式会社 情報処理装置および方法、並びに送受信システム
US9009341B2 (en) * 2011-10-11 2015-04-14 Avaya Inc. Video bandwidth management system and method
JP2014093655A (ja) * 2012-11-02 2014-05-19 Sony Corp 情報処理装置、情報処理方法及びプログラム
US10341047B2 (en) * 2013-10-31 2019-07-02 Hewlett Packard Enterprise Development Lp Method and system for controlling the forwarding of error correction data
US9432144B2 (en) * 2014-09-12 2016-08-30 Ciena Corporation Precision time transfer systems and methods in optical networks
CN105100675B (zh) * 2015-09-11 2019-07-09 Tcl集团股份有限公司 一种终端视频通信的质量调节方法及系统
US9754338B2 (en) 2015-10-09 2017-09-05 Gt Gettaxi Limited System to facilitate a correct identification of a service provider
CN105897759A (zh) * 2016-06-14 2016-08-24 青岛乾元通数码科技有限公司 一种网络动态自适应音视频缓存方法及系统
US10636108B2 (en) * 2016-09-30 2020-04-28 Lyft, Inc. Identifying matched requestors and providers
US11574262B2 (en) 2016-12-30 2023-02-07 Lyft, Inc. Location accuracy using local device communications
US10554783B2 (en) 2016-12-30 2020-02-04 Lyft, Inc. Navigation using proximity information
EP3382918B1 (en) * 2017-03-30 2022-09-28 ADVA Optical Networking SE System and method of clock management in a packet data network
KR101924183B1 (ko) * 2017-04-25 2018-11-30 주식회사 님버스 젠락 기능을 가진 멀티미디어 송수신 장치
US10521881B1 (en) 2017-09-28 2019-12-31 Apple Inc. Error concealment for a head-mountable device
CN108628270B (zh) * 2018-06-11 2020-11-20 哈尔滨工程大学 一种基于plc远程监控终端的优化网络控制装置与方法
US10594395B2 (en) 2018-07-23 2020-03-17 Ciena Corporation Systems and methods for compensating coherent optics delay asymmetry in a packet optical network
CN109152087B (zh) * 2018-07-26 2022-02-11 同方电子科技有限公司 一种基于电台的敌我识别功能扩展方法
CN111083309B (zh) * 2018-10-18 2022-04-01 北京魔门塔科技有限公司 一种多传感器数据的时间对齐方法及数据采集设备
JP7030673B2 (ja) * 2018-11-20 2022-03-07 株式会社東芝 送信装置、通信装置、通信システム、送信方法、およびプログラム
US11910452B2 (en) 2019-05-28 2024-02-20 Lyft, Inc. Automatically connecting wireless computing devices based on recurring wireless signal detections
JP2021013134A (ja) * 2019-07-09 2021-02-04 ソニー株式会社 受信装置、受信方法および送受信システム
CN112527782B (zh) * 2019-09-19 2023-09-22 北京京东振世信息技术有限公司 一种数据处理的方法和装置
USD997988S1 (en) 2020-03-30 2023-09-05 Lyft, Inc. Transportation communication device
US11887386B1 (en) 2020-03-30 2024-01-30 Lyft, Inc. Utilizing an intelligent in-cabin media capture device in conjunction with a transportation matching system
US11552722B2 (en) 2020-12-10 2023-01-10 Ciena Corporation Precision time protocol using a coherent optical DSP frame
JP2022107993A (ja) * 2021-01-12 2022-07-25 ヤマハ株式会社 信号処理方法、信号処理装置、および信号処理プログラム
CN117196996B (zh) * 2023-10-17 2024-06-04 山东鸿业信息科技有限公司 一种数据资源的无接口交互管理方法及系统

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002185850A (ja) * 2000-12-11 2002-06-28 Nippon Telegr & Teleph Corp <Ntt> 遠隔映像選択混合方法及びシステム
JP2007027813A (ja) * 2005-07-12 2007-02-01 Sharp Corp 通信システム
JP4371120B2 (ja) 2006-05-16 2009-11-25 ソニー株式会社 画像処理装置及び画像処理方法、プログラム及び記録媒体
CN1889533B (zh) * 2006-08-03 2012-06-20 华为技术有限公司 在网际协议链路上自适应传输第三代网络接口帧的方法
JP4356033B2 (ja) * 2007-05-17 2009-11-04 ソニー株式会社 画像データ処理装置および方法
JP5745204B2 (ja) * 2008-07-28 2015-07-08 株式会社バンダイナムコエンターテインメント プログラム、情報記憶媒体及びゲーム機
JP5178375B2 (ja) * 2008-07-30 2013-04-10 パナソニック株式会社 デジタル放送再生装置およびデジタル放送再生方法

Also Published As

Publication number Publication date
WO2012020686A1 (ja) 2012-02-16
US20130136218A1 (en) 2013-05-30
JP2012044253A (ja) 2012-03-01
EP2605459A1 (en) 2013-06-19
CN103069835B (zh) 2016-01-20
BR112013002848A2 (pt) 2016-06-07
US8964921B2 (en) 2015-02-24
CN103069835A (zh) 2013-04-24

Similar Documents

Publication Publication Date Title
JP5672840B2 (ja) 情報処理装置および方法、並びにプログラム
JP5598155B2 (ja) 情報処理装置および方法、並びに送受信システム
EP2337306B1 (en) Transmitting apparatus and method, and receiving apparatus and method
JP5493471B2 (ja) 情報処理装置および方法
US8311122B2 (en) Information processing apparatus and method
JP5397700B2 (ja) 情報処理装置および方法
US8745432B2 (en) Delay controller, control method, and communication system
EP2200325B1 (en) Information processor and method therefor
JP2011223360A (ja) 送信装置、受信装置、制御方法、及び通信システム
WO2010144488A2 (en) Dual-mode compression of images and videos for reliable real-time transmission
WO2011162168A1 (ja) 情報処理装置および情報処理方法
WO2013154025A1 (ja) 情報処理装置および方法、並びに、プログラム
WO2013154024A1 (ja) 情報処理装置および方法、並びに、プログラム
JP2011147050A (ja) 画像処理装置および方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20130808

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20140904

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20141027

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20141215

LAPS Cancellation because of no payment of annual fees