JP2010074366A - 送信装置、受信装置、及び方法、プログラム - Google Patents

送信装置、受信装置、及び方法、プログラム Download PDF

Info

Publication number
JP2010074366A
JP2010074366A JP2008237893A JP2008237893A JP2010074366A JP 2010074366 A JP2010074366 A JP 2010074366A JP 2008237893 A JP2008237893 A JP 2008237893A JP 2008237893 A JP2008237893 A JP 2008237893A JP 2010074366 A JP2010074366 A JP 2010074366A
Authority
JP
Japan
Prior art keywords
moving image
time
image data
lost
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2008237893A
Other languages
English (en)
Other versions
JP5207895B2 (ja
JP2010074366A5 (ja
Inventor
Toshiyuki Nakagawa
利之 中川
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.)
Canon Inc
Original Assignee
Canon Inc
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 Canon Inc filed Critical Canon Inc
Priority to JP2008237893A priority Critical patent/JP5207895B2/ja
Priority to US12/558,885 priority patent/US8630178B2/en
Publication of JP2010074366A publication Critical patent/JP2010074366A/ja
Publication of JP2010074366A5 publication Critical patent/JP2010074366A5/ja
Application granted granted Critical
Publication of JP5207895B2 publication Critical patent/JP5207895B2/ja
Priority to US14/101,849 priority patent/US9525874B2/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51Motion estimation or motion compensation
    • H04N19/513Processing of motion vectors
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102Methods 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/103Selection of coding mode or of prediction mode
    • H04N19/107Selection of coding mode or of prediction mode between spatial and temporal predictive coding, e.g. picture refresh
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134Methods 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/164Feedback from the receiver or from the transmission channel
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/65Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using error resilience
    • H04N19/68Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using error resilience involving the insertion of resynchronisation markers into the bitstream
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/85Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression
    • H04N19/89Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression involving methods or arrangements for detection of transmission errors at the decoder
    • 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/438Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • 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/637Control signals issued by the client directed to the server or network components
    • H04N21/6377Control signals issued by the client directed to the server or network components directed to 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/65Transmission of management data between client and server
    • H04N21/658Transmission by the client directed to the server

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)

Abstract

【課題】 ネットワークの状態によっては、消失した動画像データを再送しても、消失による画質の劣化を低減できない場合があった。また、消失した動画像データを再送すると、通信量が増加してしまうという問題があった。
【解決手段】 RTT取得部106は、RTPパケットの消失検知に応じて、送信装置がデータを送信してから受信装置が前記データを受信するまでに要する時間に対応した時間情報を取得する(S202)。そして、QoS切替部107は、取得された時間情報に応じて、送信装置が送信したにもかかわらず受信装置が受信しなかった消失動画像データを再送するか、或いは、消失動画像データよりも再生時刻が後の動画像データを、消失動画像データを参照せずに符号化して送信するかを決定する(S203)。
【選択図】 図3

Description

本発明は動画像データを送受信するための方法に関する。
近年、通信環境並びにデータ処理環境の性能向上を背景として、動画像や音声といったマルチメディアデータを、ネットワークを介してリアルタイムに配信するストリーミング技術が実用化されている。このようなストリーミング技術が実用化されたことにより、ユーザはライブメディアまたは記録済みメディアのブロードバンド放送を視聴したり、記録済みメディアをオンデマンド(on demand)で視聴したりすることができる。
そこで、音声や動画のリアルタイム配信やテレビ電話など、通信の遅延や停止が許されないサービスにとって、通信速度や遅延時間、ジッター量、パケット消失率などを保証するQoS(Quality of Service)技術が重要な技術となっている。
例えば、TCP(Transmission Control Protocol)では、相手にデータが届かなかったことを検知し、届かなかったデータを相手に再送する再送制御機能が提供されている。
また例えば、イントラリフレッシュによりエラー伝播を防止する機能も提案されている(例えば特許文献1)。特許文献1には、動画通信中にパケットが消失した場合、受信側からのリフレッシュ要求に応答して、送信側装置が直ちにフレーム内符号化した動画像データを送信するようにしている。このようにすることにより、パケットが消失しても、正常な画像出力状態に迅速に復帰することができる。
特開平06−237451
しかしながら、ネットワークの状態によっては、消失した動画像データを再送しても、消失による画質の劣化を低減できない場合があった。また、消失した動画像データを再送すると、通信量が増加してしまうという問題があった。
即ち、例えば、通信系路上で消失した動画像データを再送しても、ネットワーク上で通信量が増加していると、再送された動画像データが再生(復号時刻)に間に合わない場合がある。また、この場合、再生に用いられない動画像データが再送されることになり、余計な通信量の増加を生じさせてしまう。
また、例えば通信経路上で動画像データが消失したことに応じてイントラリフレッシュを行うようにすればエラーの伝播を防ぐことはできるが、消失箇所に対応する再生画像は劣化してしまう。本発明は以上の問題に鑑みてなされたものであり、その目的は、通信帯域を効率的に利用すると共に、通信される動画像データの消失による再生画像の劣化を低減することである。
上記の問題点を解決するため、本発明の送信装置は、例えば以下のような構成を有する。
即ち、動画像データを受信装置へ送信する送信装置であって、前記送信装置がデータを送信してから前記受信装置が前記データを受信するまでに要する時間に対応した時間情報を取得する取得手段と、前記時間情報に応じて、前記送信装置が送信したにもかかわらず前記受信装置が受信しなかった消失動画像データを再送するか、或いは、前記消失動画像データよりも再生時刻が後の動画像データを、前記消失動画像データを参照せずに符号化して送信するかを決定する決定手段とを有する。
また、本発明の受信装置は、動画像データを送信する送信装置から動画像データを受信する受信装置であって、前記送信装置がデータを送信してから前記受信装置が前記データを受信するまでに要する時間に対応した時間情報を取得する取得手段と、前記時間情報に応じて、前記送信装置が送信したにもかかわらず前記受信装置が受信しなかった消失動画像データの再送を要求するか、或いは、前記消失動画像データよりも再生時刻が後の動画像データを、前記消失動画像データを参照せずに符号化する要求をするかを決定する決定手段とを有する。
また、本発明の通信方法は、動画像データを受信装置へ送信する送信装置が行う通信方法であって、前記送信装置がデータを送信してから前記受信装置が前記データを受信するまでに要する時間に対応した時間情報を取得する取得工程と、前記時間情報に応じて、前記送信装置が送信したにもかかわらず前記受信装置が受信しなかった消失動画像データを再送するか、或いは、前記消失動画像データよりも再生時刻が後の動画像データを、前記消失動画像データを参照せずに符号化して送信するかを決定する決定工程とを有する。
また、本発明の通信方法は、動画像データを送信する送信装置から動画像データを受信する受信装置が行う通信方法であって、前記送信装置がデータを送信してから前記受信装置が前記データを受信するまでに要する時間に対応した時間情報を取得する取得工程と、前記時間情報に応じて、前記送信装置が送信したにもかかわらず前記受信装置が受信しなかった消失動画像データの再送を要求するか、或いは、前記消失動画像データよりも再生時刻が後の動画像データを、前記消失動画像データを参照せずに符号化する要求をするかを決定する決定工程とを有する。
本発明によれば、通信帯域を効率的に利用することができると共に、通信される動画像データの消失による再生動画像の画質劣化を低減することができる。
<実施形態1>
以下、本発明を適用した好適な実施形態を、添付図面を参照しながら詳細に説明する。
図1は、本発明の実施形態に係る送信装置の機能構成例を示すブロック図である。
図1に示すように、本実施形態に係る送信装置100は、動画像符号化部102、パケット生成部103、送受信データバッファ104、AIR制御部105、RTT取得部106、QoS切替部107を備える。また、送信装置100は、通信制御部108、再送制御部109、通信インターフェース110を備える。なお、送受信データバッファ104には、図示しない記憶手段によって、受信装置との間で送受信するデータが記憶される。送信装置100は、フレーム内符号化された動画像データとフレーム間符号化された動画像データとを受信装置へ順次送信する送信装置である。また、送信装置100は、映像を入力する映像入力装置101、及び伝送路111に接続される。
映像入力装置101は、ビデオカメラやWebカメラなどの映像を入力するための装置である。ただし、映像入力装置101が送信装置100と一体となっていても良い。
つまり、送信装置100は、パーソナルコンピュータ、ワークステーション、ノートブックPC、コンピュータを内蔵した各種家電製品、ゲーム機、携帯電話、デジタルビデオカメラ、デジタルカメラなどの機器、或いはこれらの組み合わせにより実現可能である。
伝送路111は各種ネットワークに代表される伝送路であり、本実施形態においては、動画像データを始めとする各種パケットを通信するためのネットワークである。
送受信されるデータは送受信データバッファ104において一時的に記憶され、動画像データを送信するための通信経路やプロトコルは、通信制御部108において制御される。
動画像符号化部102は、上述の映像入力装置101から入力された動画像データをMPEG−4方式により圧縮符号化する。動画像符号化部102は、圧縮符号化した動画像データを、フレーム単位でパケット生成部103へ入力する。
パケット生成部103は、動画像符号化部102から入力された動画像データをパケット化し、送受信データバッファ104へ記憶させる。本実施形態では、動画像データの符号化方式としてMPEG−4 Videoを用い、符号化動画像データ転送プロトコルとしてRTP(Real−time Transport Protocol)を用いる。従って、パケット生成部103は、符号化動画像データのRTPペイロードフォーマットを規定しているRFC3550に従って符号化動画像データをパケット化するものとする。
通信制御部108は、送受信データバッファ104に記憶されたRTPパケット(動画像データ)を、通信インターフェース110を介して所定の宛先(受信装置)へ向けて送信する。
AIR制御部105は、後述するQoS切替部107からの指示に応じて、AIR(Adaptive Intra Refresh)の制御を行う。ここで、イントラリフレッシュとは、通信経路上で消失したRTPパケット(消失動画像データ)を参照しないように、強制的にフレーム内符号化(イントラ符号化)を行う処理である。そして、AIRは、消失したRTPパケットを参照して符号化される動画像データのうち、動領域の動画像データを強制的にイントラ符号化にする方式である。AIRにおいて、静止領域のRTPパケットを消失した場合、例えば、消失したRTPパケットに対応するフレームよりも前のフレームのデータを参照させるようにすることができる。一般に、フレーム内符号化をすると、フレーム間符号化よりも符号化後のデータ量が大きくなるため、AIRによって、すべての領域を強制的にフレーム内符号化にするよりも、送信する動画像データのデータ量を低くすることができる。ただし、イントラリフレッシュにより、消失したRTPパケットを参照して符号化されるすべての領域をフレーム内符号化するようにしても良い。また、エラー情報とは、送信装置100が受信装置に対して送信したにも関わらず、受信装置が受信しなかったRTPパケット(消失動画像データ)を通知するための情報(消失情報)である。このエラー情報として、例えばRTCPの受信者レポート(Receiver Report、以下単にRRと称す)を使用した再送要求を用いることができる。即ち、AIR制御部105は、消失したRTPパケットよりも後に再生されるRTPパケットを、消失したRTPパケットのデータを参照せずに符号化するための制御を行う。
RTT取得部106は、受信装置からのエラー情報の受信に応じてRTT(Round Trip Time)を取得する。本形態において、RTTは、受信装置における消失動画像データの検知から再送された消失パケットを受信するまでの時間である。つまり、RTTは、送信装置100と受信装置間においてパケットが往復する時間(往復時間)に、受信装置による処理時間(受信側処理時間)及び、送信装置100による処理時間(送信側処理時間)をそれぞれ加算した時間である。受信側処理時間とは、受信装置が消失パケットを検知してからエラー情報を送信するまでに要する時間であり、送信側処理時間とは、送信装置100がエラー情報を受信してから再送パケットを生成・送信するまでに要する時間(送信側処理時間)を示す。
RTT取得部106によるRTTの取得処理の詳細は後述する。
QoS切替部107は、RTT取得部106によって取得されたRTTに応じて、エラーに対するQoS技術を切り替える。つまり、QoS切替部107は、RTTに応じて、受信装置側で受信されなかったRTPパケット(消失動画像データ)を再送するか、エラーの伝播を防ぐためにAIR処理を行うかを決定する。そして、QoS切替部107は、消失したパケットを再送する場合は再送制御部109に通知を行い、AIR処理を行う場合はAIR制御部105に通知する。QoS切替部107の処理の詳細は後述する。
再送制御部109は、QoS切替部107からの通知に応じて、消失したRTPパケット(消失動画像データ)の再送処理を行う。再送制御部109による再送処理の詳細は後述する。
次に、本実施形態の送信装置100によるQoS切替処理の詳細について、図2を用いて説明する。図2は、本実施形態の送信装置100におけるQoS制御の切り替え処理手順の一例を示すフローチャートである。尚、送信装置100は、フレーム内符号化された動画像データとフレーム間符号化された動画像データとを受信装置へ順次送信する送信装置である。
まず送信装置100は、受信装置からエラー情報(消失情報)を受信したか否かを通信制御部108において判断する(S201)。エラー情報は、受信装置がパケット消失を検知した場合に、消失したRTPパケットを通知するための情報である。本形態のエラー情報には、消失したRTPパケットのシーケンス番号、消失したRTPパケットを検知した時刻、及び、エラー情報を受信装置が送信した時刻の情報が含まれる。
即ち、通信制御部108は、S201において、消失動画像データが発生したことを示す消失情報(エラー情報)を受信する。
本実施形態の受信装置は、受信したRTPパケット(動画像データ)のヘッダ部分に記録されているシーケンス番号からパケット消失の有無を判断する。つまり、受信装置は、受信したRTPパケットのシーケンス番号が連続した値であればパケット消失はないとし、シーケンス番号に抜けがあればパケット消失が発生したものとして、送信装置100へエラー情報を通知する。尚、本形態の受信装置は、パケットの消失をエラーと判断するが、パケットの重複や順序誤りに関してはエラーとみなさない。つまり、受信装置は、パケットの重複に対しては重複パケットの一方を破棄し、順序誤りに対しては順不同パケットを順序通りに並べ替えるなどの処理を行う。このようにすれば、余計な再送要求による通信量の増加を低減することができる。
S201で、エラー情報(消失情報)を受信していないと判断されると、受信するまでS201の処理を繰り返す。一方、S201で、エラー情報を受信したと判断された場合は、S202に進む。
S202(取得手順)において、RTT取得部106は、送信装置100と受信装置間のRTTを取得する(S202)。上述のように、本形態のRTTは、受信装置がRTPパケットの消失(消失動画像データ)を検知してから再送されたRTPパケットが到着するまでに要する時間を示している。つまり、RTTには、ネットワーク上をパケットが往復する時間(往復時間)に、送信装置100による処理の時間(送信側処理時間)及び、受信装置による処理の時間(受信側処理時間)を加算した時間の情報である。本実施形態において、RTT取得部106は、エラー情報を受信してから、当該エラー情報を解析し、再送パケットを生成・送信するまでに要する時間(送信側処理時間)の情報を予め保持している。また、エラー情報には、受信装置がエラー情報を送信した時刻の情報、及び、受信装置が消失したRTPパケットを検知した時刻の情報が含まれている。そして、RTT取得部106は、エラー情報の取得に応じて現在の時刻を取得することで、受信装置がエラー情報を送信してから送信装置が受信するまでにかかった時間(上り片道時間)を算出する。また、RTT取得部106は、受信装置がRTPパケットの消失を検知してから送信装置に対してエラー情報を送信するまでに要する時間(受信側処理時間)の情報を取得する。
即ち、RTT取得部106は、S202において、送信装置100が消失情報(エラー情報)を受信してから消失動画像データを再送するまでに要する第1の処理時間(送信側処理時間)を取得する。また、RTT取得部106は、受信装置が消失動画像データを検知してから消失情報(エラー情報)を送信するまでに要する第2の処理時間(受信側処理時間)を取得する。
また、本形態のRTT取得部106は、エラー情報に含まれている、送信装置100がRTPパケットを送信してから当該RTPパケットを受信するまでにかかった時間(下り片道時間)を取得する。
そして、上り片道時間と下り片道時間を合計することによって、送信装置と受信装置間の往復時間を算出する。このようにすることで、例えば、送信装置から受信装置への回線速度と受信装置から送信装置への回線速度が異なる場合であっても、より精度良く往復時間を算出することができる。ただし、例えば算出された上り片道時間を2倍することによって往復時間を得るようにしても良い。RTT取得部106は、このようにして算出した往復時間に、予め持っている送信側処理時間、及び、エラー情報に含まれていた受信側処理時間を加えることで、本形態のRTTを取得する。
即ち、RTT取得部106は、S202において、送信装置100がデータを送信してから受信装置が当該データを受信するまでに要する時間(下り片道時間)に対応した第1の時間情報(RTT)を取得する。RTT取得部106がRTTを取得するとS203に進む。
S203(決定手順)において、QoS切替部107は、S202において取得されたRTTと、許容時間とを比較する。
ここで、本形態における許容時間は、上述のRTPパケットの消失を検知した時刻と消失したRTPパケットの復号開始時刻との時間差を示す。この許容時間は、RTPパケットの消失を検知した時点における受信装置の送受信データバッファに蓄えられている動画像データの量に応じた時間情報である。つまり、RTPパケットの消失を検知した時点において、送受信データバッファに多くのRTPパケット(動画像データ)が蓄えられていれば、その分、許容時間は長くなる。
通常、受信装置は、ネットワーク上のパケット到着時間のゆらぎ(ジッタ)を吸収するために受信データバッファを有しており、受信データバッファ容量の制御により動画像を滑らかに復号、再生する。
本形態において、受信装置は、送信装置100に対して送信するエラー情報に、RTPパケットの消失の検知時において蓄えられているRTPパケット(動画像データ)のデータ量に応じた許容時間の情報を含めている。送信装置100のQoS切替部107は、エラー情報に含まれる許容時間の情報を取得する。
RTTが許容時間よりも短い場合は、消失したRTPパケット(消失動画像データ)を再送すれば、受信装置で再生することができる。一方、RTTが許容時間を超える場合、消失したRTPパケットを再送しても、受信装置の再生に間に合わないため、再送データを再生できない。また、再生に用いることができないRTPパケットの再送が行われるため、無駄な通信量の増加が発生してしまう。そこで、本形態の送信装置100は、RTTが許容時間よりも短い場合は、消失したRTPパケットの再送を行う。そして、RTTが許容時間よりも長い場合は再送を行わず、RTPパケットの消失によるエラーが、そのRTPパケットよりも後に再生されるRTPパケットに伝播することを防ぐためにAIR処理を行う。
QoS切替部107は、S203で、RTTが許容時間以内であると判断した場合、再送制御部109に対して消失したRTPパケットの再送指示を行う(S204)。つまり、QoS切替部107は、再送パケットが受信装置における動画像データの復号(再生)に間に合う場合、再送制御部109へ消失したRTPパケットを再送するように指示を出す。そして、再送指示を受けた再送制御部109は、S204において、送受信データバッファ104に記録されている消失したRTPパケットを読み出し、受信装置へ再送する。
即ち、QoS切替部107は、S203において、時間情報が示す時間(RTT)が、受信装置による消失動画像データの検知時刻と消失動画像データの復号時刻との時間差に応じた時間(許容時間)よりも短い場合、消失動画像データを再送すると決定する。
一方、QoS切替部107は、S203で、RTTが許容時間よりも大きいと判断した場合、AIR制御部105に対してAIR処理を行うための指示を行う。つまり、QoS切替部107は、再送パケットが受信装置における動画像データの再生(復号)に間に合わない場合、AIRの処理を行うためにAIR制御部を制御する。上述のように、AIRの処理は、RTPパケットの消失によるエラー伝播を防止するために、消失したRTPパケット(消失動画像データ)を参照せずにフレーム内符号化する処理である。
通常、トラフィックの集中などによりネットワークが輻輳状態になると、それに従って送信装置100と受信装置間においてパケットが往復する時間(往復時間)が長くなり、RTTも長くなる。従って、本形態のQoS切替部107は、輻輳状態になると主たるQoS制御機能を再送制御からAIR制御へと切り替える。AIR処理の指示を受けたAIR制御部105は、フレーム内符号化する領域を特定し、特定した領域の情報を動画像符号化部102へ通知する(S205)。
AIR制御部105は、フレーム内符号化する領域を、受信装置から受信したエラー情報に従って適切に判断することが可能である。つまり、AIR制御部105は、消失したRTPパケットの領域をフレーム間予測符号化により参照しないよう、動画像フレームの所定の分割領域(例えばマクロブロックやビデオパケット)単位で判断する。
動画像符号化部102は、AIR制御部105から通知された所定の領域をフレーム内符号化することによりエラー伝播を防止する(S206)。このように、再送したRTPパケットが受信装置における再生(復号)に間に合わない場合には、消失したRTPパケットを再送しない。このようにすることにより、余計な再送による通信量の増加を低減することができる。また、再送パケットを受信装置が削除する処理負荷を低減することができる。
即ち、QoS切替部107は、S203において、時間情報(RTT)に応じて、送信装置100が送信したにもかかわらず受信装置が受信しなかった消失動画像データを再送するか、或いは、AIR処理を行うか決定する。AIR処理は、消失動画像データよりも再生時刻が後の動画像データを、消失動画像データを参照せずに符号化する処理である。
次に、本実施形態のシステム全体の処理について、図3を用いて説明する。
図3は、本実施形態の送信装置と受信装置を含むシステム全体におけるQoS制御のシーケンスを示す図である。
送信装置100と受信装置302は、ネットワーク301を介して相互に接続されており、送信装置100は、動画像データのRTPパケット(303〜306)を順次受信装置302へ送信する。
ネットワーク301上のエラーによりRTPパケット305が消失すると、受信装置302はRTPパケット303、304、306を受信すると共に、RTPパケットヘッダ中のシーケンス番号の不連続性によりRTPパケット305の消失を検出する。受信装置302は、RTPパケット305の再送を要求するため、送信装置100に対してエラー情報(RR307)を送信する。
送信装置100は、受信装置302からのRR307を受信すると上述のRTTを取得する。このとき、RTT取得段階においてネットワーク301は混雑していなかったため、RTTが許容時間以下であったとする。すなわち、受信装置302における動画像の再生(復号)に、再送されるRTPパケット305が間に合うと判断されるものとする。この場合、送信装置100は受信装置302へ消失したRTPパケット305を再送し、エラー伝播防止のためのAIR制御を行わない。従って、再送されたRTPパケット305を受信した受信装置302は、正常に動画像データを復号、再生することができる。
続いて、送信装置100は、動画像データのRTPパケット(308〜311)を順次受信装置302へ送信する。
ここで、ネットワーク301上のエラーによりRTPパケット310が消失すると、受信装置302はRTPパケット308、309、311を受信すると共に、RTPパケットヘッダ中のシーケンス番号の不連続性によりRTPパケット310の消失を検知する。受信装置302は、RTPパケット310の再送を要求するため、送信装置100に対してエラー情報(RR312)を送信する。
送信装置100は、受信装置302からのRR312を受信するとRTTを取得する。このとき、RTT取得段階においてネットワーク301は輻輳状態にあり、RTTが許容時間よりも長かったとする。すなわち、受信装置302における動画像の再生(復号)に、再送されるRTPパケット310が間に合わないと判断されるものとする。この場合、送信装置100は、受信装置302へ消失したRTPパケット310を再送せず、エラー伝播防止のためにAIR制御を行う。従って、受信装置302は、RTPパケット310の消失による動画像データの復号エラーの時間的な伝播を防止することができる。
尚、図3の説明では、RTPパケットが1つ消失する場合について説明したが、通信制御部405は、送信順序が連続する複数のRTPパケットの消失を検知することもできる。受信装置は、RTPパケットが連続して消失したことを検知すると、その時刻を取得すると共に、消失した各RTPパケットの復号時刻を取得する。上述のように、消失したRTPパケットの復号時刻は、受信装置の送受信データバッファに蓄えられているRTPパケットのデータ量に応じて決まる。そして、RTPパケットの消失を検知した時刻、各RTPパケットの復号時刻、受信側処理時間、及び、RTPパケットの消失検知時における送信装置から受信装置に対する片道時間(下り片道時間)を含むエラー情報を送信装置に対して送信する。エラー情報を受信した送信装置100のRTT取得部106は、エラー情報の送信時刻と受信時刻から上り片道時間を取得し、それに下り片道時間を加算することで往復時間を取得する。RTT取得部106は、往復時間に送信側処理時間と受信側処理時間を加算することで、RTTを取得する。また、QoS切替部107は、RTT取得部106によって取得されたRTTと許容時間とを比較することで、消失した各RTPパケットを再送するか、AIRの処理を行うかを決定する。ここで、復号時刻がそれぞれ異なる消失RTPパケットの許容時間は、それぞれ異なる。
本形態のQoS切替部107は、送信順序が連続する複数の消失RTPパケットのうち、送信順序が前の消失RTPパケットから順に、再送するかAIR処理を行うかを決定する。そして、QoS切替部107は、送信順序が連続する消失RTPパケットのうち、ある送信順序の消失RTPパケットを再送すると決めた場合、それよりも後の消失RTPパケットも再送すると決定する。即ち、QoS切替部107は、複数の消失動画像データのうち、第1の消失動画像データを再送すると決定した場合、第1の消失動画像データよりも後の第2の消失動画像データを再送すると決定する。つまり、送信順序が前のRTPパケットは、それよりも後のRTPパケットよりも復号(再生)時刻が早い。従って、ある再送されたRTPパケットが受信装置における復号(再生)に間に合う場合、それよりも後の送信順序のRTPパケットを再送しても、その再送パケットが復号(再生)に間に合う。
つまり、例えば、連続して9つのRTPパケットが消失した場合に、そのうち最も送信順序が前である消失RTPパケットの再送が間に合うと判断される場合、他の8つの消失RTPパケットの再送も間に合うと判断することができる。このようにすることで、より送信装置の処理を軽くすることができる。
また、QoS切替部107は、送信順序が連続する複数の消失RTPパケットのうち、送信順序が後ろの消失RTPパケットから順に、再送するかAIR処理を行うか決定するようにしても良い。このとき、ある送信順序の消失RTPパケットを、再送せずにAIR処理を行うと決めた場合、それよりも前の消失RTPパケットも、再送せずにAIR処理を行うと決定する。即ち、QoS切替部107は、複数の動画像データのうち、第1の消失動画像データを参照せずに未送信の動画像データを符号化して送信すると決定した場合、以下のように他の消失動画像データに対する処理を決定する。すなわち、第1の消失動画像データよりも前の第2の消失動画像データを参照せずに、未送信の動画像データを符号化して送信すると決定する。
つまり、送信順序が後のRTPパケットは、それよりも前のRTPパケットよりも復号(再生)時刻が遅い。従って、ある再送されたRTPパケットが受信装置における復号(再生)に間に合わない場合、それよりも前の送信順序のRTPパケットを再送しても、その再送パケットは復号(再生)に間に合わない。
つまり、例えば、連続して9つのRTPパケットが消失した場合、そのうち最も送信順序が後ろである消失RTPパケットを再送しても、復号時刻に間に合わないと判断される場合、他の8つの消失RTPパケットを再送しても間に合わないと判断することができる。このようにすることで、より送信装置の処理を軽くすることができる。
また、送信順序が連続する複数のRTPパケットが消失したことが検知された場合、どの送信順序の消失RTPパケットから、再送するかAIRを行うかを決定するかを、受信装置からのエラー情報に含まれる送受信データバッファのデータ量に応じて判断しても良い。
また、本実施形態のQoS切替部107は、送信順序が連続する複数のRTPパケットが消失し、そのうちの一部の消失RTPパケットに対して再送を行い、残りの消失RTPパケットに対しては、AIR処理を行うと決定した場合、以下のような処理を行う。すなわち、再送する消失RTPパケットが再送しない消失RTPパケットを参照せずに符号化されるように、再送するRTPパケットの動画像データを再符号化する。
即ち、QoS切替部107は、複数の消失動画像データのうち、再送すると決定した消失動画像データを、再送しない消失動画像データを参照せずに符号化して送信すると決定する。
つまり、例えば、送信順序が連続する9つのRTPパケットが消失した場合、QoS切替部107は、送信順序が後ろの4つの消失RTPパケットを再送し、それ以外の5つの消失RTPパケットは再送せず、AIR処理を行うと決定したとする。この場合、再送されたRTPパケットの中には、再送しない5つのRTPパケットのデータを参照しているものがある可能性があるため、再送パケットが正常に受信、復号されたとしても、再生画像が劣化する場合がある。そこで、本形態のQoS切替部107は、再送するRTPパケットが、再送しない消失RTPパケットのデータを参照せずに符号化されるように、再送するRTPパケットに対応する動画像データを再符号化すると決定する。このようにすることで、よりRTPパケットの消失による再生画像の劣化をより低減することができる。ただし、再送するRTPパケットに対してAIR処理の処理を行わないようにしても良い。
以上説明した通り、本実施形態の送信装置100は、受信装置からRTPパケットが消失したことを示すエラー情報(消失情報)が通知されると、消失したRTPパケットを再送するかAIR処理を適用するかを切り替える。ここで、送信装置100は、再送とAIR処理の切り替えを、エラー情報の受信時におけるネットワークの状況や受信装置が蓄えている動画像データのデータ量に応じて行う。つまり、再送したパケットが受信装置における動画像の再生(復号)に間に合う場合は再送処理を行い、間に合わない場合は再送を行わず、AIR処理を行う。
このようにすることにより、復号に間に合わない(再生に用いない)RTPパケットの再送を防ぐことができるため、無駄な通信量の増加を低減することができるため、動画像品質を維持しながら通信帯域を効率的に利用することができる。
また、これにより、受信装置側で復号に間に合わなかった再送パケットを削除する処理を低減することができる。また、消失したRTPパケットを再送した場合は、AIRの処理を行わないようにすることにより、送信装置におけるAIRの処理を削減することができる。また、RTTと許容時間との比較に応じたQoSの切り替えを送信装置が行うことにより、受信装置が持っている機能によらず、上記の効果を得ることができる。
尚、上記の実施形態では、RTTが、RTPパケットの消失を検知してから再送されたRTPパケットの受信するまでの時間である場合の例について説明した。また、上記の実施形態では、許容時間が、RTPパケットの消失を検知してから、当該RTPパケットの復号時刻までの時間である場合の例について説明した。しかし、RTTと許容時間の例は上記の例に限らず、他に様々な形態を用いることができる。
例えば、RTTとして、下り片道時間と送信側処理時間の合計時間を用いるようにしても良い。この場合、許容時間として、送信装置100におけるエラー情報の受信時刻と、当該エラー情報に対応する、消失したRTPパケット(消失動画像データ)の受信装置における復号時刻との時間差を用いる。
つまり、受信装置は、送信するエラー情報に、消失したRTPパケットのシーケンス番号、下り片道時間の他に、消失したRTPパケットの復号時刻の情報を含める。下り片道時間は、送信装置がデータを送信してから受信装置が受信するまでに要する時間を示しており、受信装置は、例えば以下のように下り片道時間を取得することができる。すなわち、RTPパケットの消失を検知したときに受信したRTPパケットの送信装置100における送信時刻と受信装置における受信時刻から下り片道時間を取得することができる。また、復号時刻の情報は、受信装置における送受信データバッファに蓄積されている動画像データのデータ量に応じて決まる。
エラー情報を受信した送信装置100のRTT取得部106は、下り片道時間に送信側処理時間を加算した時間をRTTとして取得する。送信側処理時間は、送信装置100が予め記憶している。
即ち、通信制御部108が、消失動画像データが発生したことを示す消失情報(エラー情報)を受信すると、RTT取得部106は、送信側処理時間を取得する。上述のように、送信側処理時間は、送信装置100が消失情報(エラー情報)を受信してから消失動画像データを再送するまでに要する処理時間である。そして、RTT取得部106は、送信装置100がデータを送信してから受信装置が当該データを受信するまでに要する時間(下り片道時間)、及び送信側処理時間の合計を時間情報(RTT)として取得する。
また、QoS切替部107は、許容時間(エラー情報の受信時刻と消失RTPパケットの復号時刻との時間差)を取得する。そして、QoS切替部107は、RTT(下り片道時間と送信側処理時間の合計)が許容時間よりも短い場合、再送すると決定する。一方、RTTが許容時間よりも長い場合、再送処理を行わず、AIR処理を行うと決定する。
このようにしても、エラー発生時におけるネットワークの状況に応じて再送処理とAIR処理を切り替えることができ、上述の本発明の効果を得ることができる。
また、RTTのほかの例として、例えば、往復時間と送信側処理時間としても良い。この場合、許容時間として、受信装置におけるエラー情報の送信から、当該エラー情報に対応する、消失したRTPパケットの復号時刻との時間差を用いる。
つまり、受信装置は、送信するエラー情報に、消失したRTPパケットのシーケンス番号、エラー情報を送信した時刻の情報、下り片道時間、消失したRTPパケットの復号時刻の情報のほかに、消失したRTPパケットを検知した時刻の情報を含める。
エラー情報を受信した送信装置100のRTT取得部106は、エラー情報の受信時刻と、エラー情報の送信時刻とに基づいて算出される上り片道時間とエラー情報に含まれている下り片道時間とを合計することで往復時間を得る。そして、RTT取得部106は、得られた往復時間に送信側処理時間を加算した時間をRTTとして取得する。また、RTT取得部106は、許容時間(エラー情報の送信時刻と消失したRTPパケットの復号時刻の時間差)を取得する。そして、QoS切替部107は、RTT(往復時間と送信側処理時間と受信側処理時間の合計時間)が許容時間よりも小さければ、再送処理を行わせる。一方、RTTが許容時間よりも大きければ、再送処理を行わずに、AIR処理を行うようにAIR制御部105に対して指示を行う。
即ち、通信制御部108が、消失動画像データが発生したことを示す消失情報(エラー情報)を受信すると、RTT取得部106は、送信側処理時間を取得する。上述のように、送信側処理時間は、送信装置100が消失情報(エラー情報)を受信してから消失動画像データを再送するまでに要する処理時間である。
そして、RTT取得部106は、上り片道時間と下り片道時間との合計時間に応じた往復時間、及び、送信側処理時間の合計を時間情報(RTT)として取得する。上述のように、上り片道時間は、受信装置から消失情報(エラー情報)が送信されてから当該消失情報を受信するまでに要する時間であり、下り片道時間は、送信装置100がデータを送信してから受信装置が当該データを受信するまでに要する時間を示している。
そして、QoS切替部107は、時間情報が示す時間が、受信装置による消失情報の送信時刻と消失動画像データの復号時刻との時間差に応じた時間(許容時間)よりも短い場合、消失動画像データを再送すると決定する。
このようにしても、エラー発生時におけるネットワークの状況に応じて再送処理とAIR処理を切り替えることができ、上述の本発明の効果を得ることができる。
<実施形態2>
次に本発明の第2の実施形態について、実施形態1との差異を中心に説明する。
前述した第1の実施形態では、再送処理をするかAIR処理をするかを送信装置が決定する構成とした。これに対して本実施形態では、受信装置が、RTPパケットの消失検知時におけるネットワークの状態から、再送処理とAIR処理のどちらが有効かを決定して、送信装置へ指示する。
図4は、本実施形態に係る受信装置の機能構成例を示すブロック図である。
図4に示すように、受信装置400は、通信インターフェース402、送受信データバッファ403、QoS切替部404、通信制御部405、RTT取得部406、動画像復号化部407を備えている。なお、送受信データバッファ403には、図示しない記憶手段によって、送信装置との間で送受信されるデータが記憶される。受信装置400は、フレーム内符号化された動画像データとフレーム間符号化された動画像データとを順次送信する送信装置から動画像データを受信する受信装置である。また、受信装置400は、出力機器408、及び伝送路401に接続される。
出力機器408は、映像を出力するための、例えばディスプレイ、蓄積装置、任意のネットワークへの送信装置等である。受信装置400は、出力機器408と一体となっていても良い。
つまり、受信装置400は、パーソナルコンピュータ、ワークステーション、ノートブックPC、コンピュータを内蔵した各種家電製品、ゲーム機、携帯電話、デジタルビデオカメラ、デジタルカメラなどの機器、或いはこれらの組み合わせにより実現可能である。
図4において、伝送路401は各種ネットワークに代表される伝送路であり、本実施形態においては、RTPパケット(動画像データ)を始めとする各種パケットを通信するためのネットワークである。送受信されるデータは送受信データバッファ403において一時的に記憶され、動画像データを受信するためのプロトコルは、通信制御部405において制御される。
動画像復号化部407は、送信装置から受信して送受信データバッファに記憶された動画像データをMPEG−4方式により復号化する。動画像復号化部407において復号化された動画像データは、出力機器408の仕様に基づいた単位(一般的にはフレーム単位)で出力機器408へ入力される。
通信制御部405は、実施形態1と同様に、受信したRTPパケットのヘッダに記憶されているシーケンス番号から、パケット消失の有無を判断する。つまり、RTPパケットに含まれるシーケンス番号が連続していない場合、抜けているパケットが消失したと判断する。通信制御部405は、パケットの消失を検知すると、それをRTT取得部406に通知する。
RTT取得部406は、パケット消失の通知に応じてRTTを取得する。本形態において、RTTは、受信装置400がパケット消失を検知してから再送パケットが到着するまでに要する時間である。つまり、RTTは、送信装置と受信装置400間においてパケットが往復する時間(往復時間)に、受信装置400による処理時間(受信側処理時間)と送信装置による処理時間(送信側処理時間)を加えた時間を示す。ここで、受信側処理時間とは、受信装置400がパケット消失を検知してからエラー情報を送信するまでに要する時間であり、送信側処理時間とは、送信装置がエラー情報を受信してから再送パケットを生成・送信するまでに要する時間を示している。尚、上述のように、本実施形態では、受信装置400が、消失したRTPパケットの再送を要求するか、或いは、AIR処理の要求をするかを決定する。従って、受信装置400が送信するエラー情報の内容は、再送要求であるか、AIR処理の要求であるかによって異なる。
尚、本実施形態のRTT取得部406は、RTPパケット(動画像データ)の通信に先立ち、送信側処理時間の情報を予め送信装置から取得しているものとする。また、RTT取得部406は、RTPパケットの消失を検知した時刻を取得する。
また、RTT取得部406は、消失したRTPパケットの後に送信される、正常に受信されたRTPパケットに含まれるパケットの送信時刻の情報により、下り片道時間を取得する。ここで、下り片道時間は、送信装置がデータを送信してから、当該データを受信装置400が受信するまでに要する時間を示している。また、RTT取得部406は、RTPパケットの消失を検知してからエラー情報を送信するまでに必要な時間を受信側処理時間として予め取得している。そして、RTT取得部406は、下り片道時間を2倍することで得られる往復時間に、予め持っている送信側処理時間、及び受信側処理時間を加えることで、本形態のRTTを取得する。ただし、RTT取得部406が、例えば定期的に送信装置に対してデータを送信している場合、受信装置から送信装置へのデータの片道時間(上り片道時間)を取得することができる。この場合、往復時間を下り片道時間と上り片道時間の合計とするようにしても良い。このようにすれば、送信装置から受信装置への回線速度と受信装置から送信装置への回線速度が異なる場合であっても、より精度の高い往復時間を取得できる。
QoS切替部404は、RTT取得部406によって取得されたRTTと、許容時間との比較結果に応じて、送信装置に対して、消失したRTPパケットの再送要求をするか、AIR処理の要求を行うか決定する。ここで、許容時間は、RTPパケットの消失を検知してから、消失したRTPパケット(消失動画像データ)を復号するまでに要する時間である。QoS切替部404によるQoSの決定の詳細については後述する。
次に、本実施形態の受信装置400によるQoS切替処理について、図5を用いて説明する。
図5は、本実施形態の受信装置におけるQoS制御の切り替え処理手順の一例を示すフローチャートである。
尚、受信装置400は、フレーム内符号化された動画像データとフレーム間符号化された動画像データとを順次送信する送信装置から動画像データを受信する受信装置である。
まず受信装置400の通信制御部405は、パケット消失を検知したか否かを判断する(S501)。通信制御部405は、第1の実施形態と同様に、受信したRTPパケットのヘッダ部分に記録されているシーケンス番号の連続性からパケット消失を検知する。
S501で、パケット消失を検知していない場合には、検知するまでS501の処理を繰り返す。一方、S501で、パケット消失を検知した場合は、S502に進む。
S502(取得手順)において、RTT取得部406は、RTTを取得する。上述のように、本形態におけるRTTは、通信制御部405がRTPパケットの消失を検知してから、消失したRTPパケットの復号するまでの時間である。また、消失したRTPパケットの復号時刻は、そのときの送受信データバッファ403に蓄えられているRTPパケット(動画像データ)のデータ量に応じて決まる。
即ち、S502において、RTT取得部406は、送信装置がデータを送信してから受信装置400が当該データを受信するまでに要する時間(下り片道時間)に対応した時間情報(RTT)を取得する。RTT取得部406がRTTを取得すると、S503に進む。
S503(決定手順)において、QoS切替部404は、消失したパケットの再送が間に合うか否かを判断する。ここでの判断は、S502において取得したRTTが、受信装置400において復号までに許容される時間(許容時間)以内か否かによって行われる。本形態における許容時間は、RTPパケットの消失を検知してから、該消失したRTPパケットを復号するまでに要する時間である。つまり、QoS切替部404は、RTTが許容時間よりも短ければ再送したパケットが再生(復号)に間に合うと判断し、RTTが許容時間よりも長いと再送したパケットが再生(復号)に間に合わないと判断する。QoS切替部404が、再送パケットが再生(復号)に間に合うと判断すると、S504に進む。
S504において、QoS切替部404は、消失したRTPパケットの再送要求を送信装置に対して送信する。
一方、S503で、QoS切替部404が、再送パケットが再生(復号)に間に合わないと判断するとS505に進む。そして、S505において、QoS切替部404は、AIR処理の要求を送信装置に対して送信する。
即ち、QoS切替部404は、S503で、時間情報(RTT)に応じて、送信装置が送信したにもかかわらず受信装置400が受信しなかった消失動画像データの再送を要求するか、或いは、AIR処理を要求するか決定する。上述のように、AIR処理は、消失動画像データよりも再生時刻が後の動画像データを、消失動画像データを参照せずに符号化する処理である。
このように、受信装置400のQoS切替部404は、RTTと許容時間との比較により、再送したRTPパケットが再生(復号)に間に合うか否かを判断する。そして、QoS切替部404は、再送したRTPパケットが再生(復号)に間に合わないと判断した場合、再送要求ではなくAIR処理の要求を送信装置601へ送信する。一方、再送したRTPパケットが再生(復号)に間に合うと判断した場合、AIR処理の要求ではなく再送要求を送信装置601へ送信する。受信装置400からの要求を受信した送信装置601は、要求の内容にしたがってパケットの再送制御あるいはAIR処理の制御を行う。
次に、本実施形態のシステム全体の処理について、図6を用いて説明する。
図6は、本実施形態の送信装置と受信装置を含むシステム全体におけるQoS制御のシーケンスを示す図である。
送信装置601と受信装置400は、ネットワーク602を介して相互に接続されており、送信装置は、動画像データのRTPパケット(603〜606)を順次受信装置400へ送信する。
ネットワーク602上のエラーによりRTPパケット605が消失すると、受信装置400はRTPパケット603、604、606を受信すると共に、RTPパケットヘッダ中のシーケンス番号の不連続性によりRTPパケット605の消失を検知する。続いて受信装置400は、RTPパケット605の消失を検知するとRTTを取得する。上述したように、本形態におけるRTTは、RTPパケット(動画像データ)の消失を検知してから再送されたRTPパケットを受信するまでに要する時間である。つまり、RTTは、送信装置と受信装置との往復時間に送信側処理時間と受信側処理時間を加算した合計時間を示している。RTT取得段階においてネットワーク602は混雑しておらず、RTTが許容時間以下であったとする。尚、本形態における許容時間は、RTPパケットの消失を検知した時刻から、当該RTPパケットを復号する時刻までに要する時間である。また、RTPパケットを復号する時刻は、RTPパケットの消失を検知した時点において送受信データバッファに蓄えられているRTPパケット(動画像データ)のデータ量によって決まる。
受信装置400のQoS切替部404は、再送されたRTPパケット605の到着が受信装置400における復号時刻に間に合うと判断する。この場合、受信装置400は、RTPパケット605の再送を要求するため、送信装置601に対してRR607(エラー情報)を送信する。
送信装置601は、受信装置400からのRR607を受信すると、受信装置400へ消失したRTPパケット605を再送し、エラー伝播防止のためのAIR制御を行わない。RTPパケット605の復号時間までに再送されたRTPパケット605を受信した受信装置400は、正常に動画像データを復号、再生することができる。
続いて、送信装置601は、動画像データのRTPパケット(608〜611)を順次受信装置400へ送信する。
ネットワーク602上のエラーによりRTPパケット610が消失すると、受信装置400はRTPパケット608、609,611を受信すると共に、RTPパケットヘッダ中のシーケンス番号の不連続性によりRTPパケット610の消失を検出する。続いて受信装置400は、RTPパケット610の消失を検知するとRTTを取得する。RTT取得段階においてネットワーク602は輻輳状態にあり、RTTが許容時間よりも大きいものであったとする。すなわち、QoS切替部404は、受信装置400におけるRTPパケット610の復号時刻に、再送されたRTPパケット610の到着が間に合わないと判断する。この場合、受信装置400のQoS切替部404は、RTPパケット610の再送を要求せず、エラー伝播防止のためのAIR処理を要求するため、送信装置601に対してRR612(エラー情報)を送信する。
送信装置601は、受信装置400からのRR612を受信すると、受信装置400へRTPパケット610を再送せず、エラー伝播防止のためにAIR制御を行う。従って、受信装置400は、RTPパケット610の消失による動画像データの復号エラーの時間的な伝播を低減することができる。
これにより、パケット消失時に再送するかAIR処理を行うかを受信装置側で判断して、送信装置へ指示することができる。
このようにすることにより、復号に間に合わない(再生に用いない)RTPパケットの再送を防ぐことができるため、無駄な通信量の増加を低減することができ、動画像品質を維持しながら通信帯域を効率的に利用することができる。また、これにより、受信装置側で復号に間に合わなかった再送パケットを削除する処理を低減することができる。また、消失したRTPパケットを再送した場合は、AIR処理を行わないようにすることにより、送信装置におけるAIRの処理を削減することができる。また、RTTと許容時間との比較に応じたQoSの切り替えを受信装置が行うことにより、送信装置が持っている機能によらず、上記の効果を得ることができる。
尚、本実施形態において、RTTは、送信装置と受信装置との間におけるデータの往復時間に、送信側処理時間、及び受信側処理時間を加算した合計時間である場合について説明した。また、この場合の許容時間は、RTPパケットの消失を検知してから、当該消失したRTPパケットの復号時刻までの時間である場合について説明した。しかし、RTT、許容時間は、この例に限らない。
例えば、RTTとして、往復時間と送信側処理時間の合計時間としても良い。この場合、許容時間は、エラー情報の送信から、再送されたRTPパケットの受信までの時間となる。つまり、RTT取得部406は、RTPパケットの消失を検知した時点において、正常に受信されたRTPパケットが送信装置によって送信された送信時刻と、受信装置によって受信された受信時刻に応じて、送信装置と受信装置間の片道時間を取得する。そして、例えば取得した片道時間を2倍することによって得られる往復時間に、予め取得している送信側処理時間を加算することによってRTTを取得する。
また、QoS切替部404は、RTPパケットの消失の検知時刻に受信側処理時間を加算することで、エラー情報の送信時刻を取得することができる。この受信側処理時間は、固定値として、予め受信装置400が記憶している。そして、エラー情報の送信時刻と、消失したRTPパケットの復号時刻に応じて許容時間を取得し、取得された許容時間とRTTを比較する。比較の結果、RTTよりも許容時間が長ければ、再送したRTPパケットが再生(復号)に間に合うと判断し、送信装置に対して再送要求を行う。一方、RTTよりも許容時間が短い場合は、再送したRTPパケットが再生(復号)に間に合わないと判断し、送信装置に対してAIR処理の要求を行う。
このようにしても、上述のような本発明の効果を得ることができる。
<本発明に係る他の実施形態>
前述の実施形態では、送信装置100が動画像データの符号化処理を行う機能を有していたが、動画像符号化部102と送信装置100とが別々の装置であっても良い。同様に、受信装置400が動画像データの復号化処理を行う機能を有していたが、動画像復号化部407と受信装置400とが別々の装置であっても良い。
また、前述の実施形態では、動画像データの符号化方式としてMPEG−4方式を用い、符号化動画像データ転送プロトコルとしてRTPを用いた。しかし、動画像データの符号化方式としてはMPEG−4方式に限らず、例えばMPEG−2やH.264など、フレーム間予測符号化方式による符号化を行う類似の符号化方式を用いることができる。また、データ転送プロトコルについても、RTPに限らずOSI参照モデルの同一レイヤーの他のプロトコルまたは別レイヤーの他のプロトコルを用いることが可能である。エラー情報を送信するためのプロトコルについても、RTCPの受信者レポートに限らずTCPの否定応答(NACK)など他のプロトコルを使用することが可能である。
また、前述の実施形態は、システム或いは装置のコンピュータ(或いはCPU、MPU等)によりソフトウェア的に実現することも可能である。したがって、本発明の機能処理をコンピュータで実現するために、該コンピュータに供給、インストールされるコンピュータプログラム自体も本発明を実現するものである。つまり、本発明の機能処理を実現するためのコンピュータプログラム自体も本発明に含まれる。その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、OSに供給するスクリプトデータ等、プログラムの形態を問わない。
プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、CD−ROM、CD−R、磁気テープ、不揮発性のメモリカード、ROM、DVDなどを用いることができる。
また、前述の実施形態は、システム或いは装置のコンピュータ(或いはCPU、MPU等)によりソフトウェア的に実現することも可能である。したがって、本発明の機能処理をコンピュータで実現するために、該コンピュータに供給、インストールされるコンピュータプログラム自体も本発明を実現するものである。つまり、本発明の機能処理を実現するためのコンピュータプログラム自体も本発明に含まれる。その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、OSに供給するスクリプトデータ等、プログラムの形態を問わない。
この場合、本発明の機能処理をコンピュータで実現するためのコンピュータプログラムは、記録媒体または有線/無線通信によりコンピュータに供給される。プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、磁気テープ等の磁気記録媒体、MO、CD、DVD等の光/光磁気記憶媒体、不揮発性の半導体メモリなどがある。
有線/無線通信を用いたプログラムの供給方法としては、コンピュータネットワーク上のサーバを利用する方法がある。この場合、本発明を形成するコンピュータプログラムとなりうるデータファイル(プログラムデータファイル)をサーバに記憶しておく。プログラムデータファイルとしては、実行形式のものであっても、ソースコードであってもよい。
そして、このサーバにアクセスしたクライアントコンピュータに、プログラムデータファイルをダウンロードすることによって供給する。この場合、プログラムデータファイルを複数のセグメントファイルに分割し、セグメントファイルを異なるサーバに分散して配置することも可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムデータファイルをクライアントコンピュータに提供するサーバ装置も本発明に含む。
また、本発明のコンピュータプログラムを暗号化して格納した記録媒体をユーザに配布し、所定の条件を満たしたユーザに、暗号化を解く鍵情報を供給し、ユーザの有するコンピュータへのインストールを可能とすることも可能である。鍵情報は例えばインターネットを介してホームページからダウンロードさせることによって供給することができる。
また、コンピュータにより実施形態の機能を実現するためのコンピュータプログラムが、実施形態の機能を、すでにコンピュータ上で稼働するOSの機能を利用して実現しても良い。さらに、本発明を構成するコンピュータプログラムの少なくとも一部が、コンピュータに装着される拡張ボード等のファームウェアとして提供され、拡張ボード等が備えるCPUを利用して前述の実施形態の機能を実現してもよい。
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
第1の実施形態に係る送信装置100の機能構成例を示すブロック図である。 第1の実施形態に係る送信装置におけるQoS制御の切り替え処理手順の一例を示すフローチャートである。 第1の実施形態に係る送信装置と受信装置を含むシステム全体におけるQoS制御のシーケンスを示す図である。 第2の実施形態に係る受信装置400の機能構成例を示すブロック図である。 第2の実施形態に係る受信装置におけるQoS制御の切り替え処理手順の一例を示すフローチャートである。 の第2の実施形態に係る送信装置と受信装置を含むシステム全体におけるQoS制御のシーケンスを示す図である。
符号の説明
100 送信装置
104 送受信データバッファ
105 AIR制御部
106 RTT取得部
107 QoS切替部
108 通信制御部
302 受信装置
400 受信装置
403 送受信データバッファ
404 QoS切替部
405 通信制御部
406 RTT取得部
407 動画像復号化部

Claims (12)

  1. 動画像データを受信装置へ送信する送信装置であって、
    前記送信装置がデータを送信してから前記受信装置が前記データを受信するまでに要する時間に対応した時間情報を取得する取得手段と、
    前記時間情報に応じて、前記送信装置が送信したにもかかわらず前記受信装置が受信しなかった消失動画像データを再送するか、或いは、前記消失動画像データよりも再生時刻が後の動画像データを、前記消失動画像データを参照せずに符号化して送信するかを決定する決定手段と
    を有することを特徴とする送信装置。
  2. 動画像データを送信する送信装置から動画像データを受信する受信装置であって、
    前記送信装置がデータを送信してから前記受信装置が前記データを受信するまでに要する時間に対応した時間情報を取得する取得手段と、
    前記時間情報に応じて、前記送信装置が送信したにもかかわらず前記受信装置が受信しなかった消失動画像データの再送を要求するか、或いは、前記消失動画像データよりも再生時刻が後の動画像データを、前記消失動画像データを参照せずに符号化する要求をするかを決定する決定手段と
    を有することを特徴とする受信装置。
  3. 前記消失動画像データが発生したことを示す消失情報を受信する受信手段を有し、
    前記取得手段は、前記送信装置が前記消失情報を受信してから前記消失動画像データを再送するまでに要する第1の処理時間、及び、前記受信装置が消失動画像データを検知してから前記消失情報を送信するまでに要する第2の処理時間を取得し、
    前記時間情報は、前記送信装置がデータを送信してから前記受信装置が前記データを受信するまでに要する時間と、前記受信装置から前記消失情報が送信されてから当該消失情報を受信するまでに要する時間との合計時間に応じた往復時間、及び、前記第1及び第2の処理時間の合計であり、
    前記決定手段は、前記時間情報が示す時間が、前記受信装置による前記消失動画像データの検知時刻と前記消失動画像データの復号時刻との時間差に応じた時間よりも短い場合、前記消失動画像データを再送すると決定する
    ことを特徴とする請求項1記載の送信装置。
  4. 前記消失動画像データが発生したことを示す消失情報を受信する受信手段を有し、
    前記取得手段は、前記送信装置が前記消失情報を受信してから前記消失動画像データを再送するまでに要する処理時間を取得し、
    前記時間情報は、前記受信装置がデータを送信してから前記送信装置が前記データを受信するまでに要する時間、及び前記処理時間の合計であり、
    前記決定手段は、前記時間情報が示す時間が、前記消失情報の受信時刻と消失動画像データの復号時刻との時間差に応じた時間よりも短い場合、前記消失動画像データを再送すると決定する
    ことを特徴とする請求項1記載の送信装置。
  5. 前記消失動画像データが発生したことを示す消失情報を受信する受信手段を有し、
    前記取得手段は、前記送信装置が前記消失情報を受信してから前記消失動画像データを再送するまでに要する処理時間を取得し、
    前記時間情報は、前記送信装置がデータを送信してから前記受信装置が前記データを受信するまでに要する時間と、前記受信装置から消失情報が送信されてから当該消失情報を受信するまでに要する時間との合計時間に応じた往復時間、及び、前記処理時間の合計であり、
    前記決定手段は、前記時間情報が示す時間が、前記受信装置による前記消失情報の送信時刻と前記消失動画像データの復号時刻との時間差に応じた時間よりも短い場合、前記消失動画像データを再送すると決定する
    ことを特徴とする請求項1記載の送信装置。
  6. 送信順序が連続する複数の動画像データが消失動画像データとなった場合、
    前記決定手段は、前記複数の消失動画像データのうち、第1の消失動画像データを再送すると決定した場合、前記第1の送信順序よりもあとの第2の前記消失動画像データを再送すると決定する
    ことを特徴とする請求項1記載の送信装置。
  7. 送信順序が連続する複数の動画像データが消失動画像データとなった場合、
    前記決定手段は、前記複数の消失動画像データのうち、第1の消失動画像データを参照せずに、未送信の動画像データを符号化して送信すると決定した場合、
    前記第1の消失動画像データよりも前の第2の消失動画像データを参照せずに、未送信の動画像データを符号化して送信すると決定することを特徴とする請求項1記載の送信装置。
  8. 送信順序が連続する複数の動画像データが消失動画像データとなった場合、
    前記決定手段は、前記複数の消失動画像データのうち、再送すると決定した消失動画像データを、再送しない消失動画像データを参照せずに符号化して送信すると決定する
    ことを特徴とする請求項1記載の送信装置。
  9. 動画像データを受信装置へ送信する送信装置が行う通信方法であって、
    前記送信装置がデータを送信してから前記受信装置が前記データを受信するまでに要する時間に対応する時間情報を取得する取得工程と、
    前記時間情報に応じて、前記送信装置が送信したにもかかわらず前記受信装置が受信しなかった消失動画像データを再送するか、或いは、前記消失動画像データよりも再生時刻が後の動画像データを、前記消失動画像データを参照せずに符号化して送信するかを決定する決定工程と
    を有することを特徴とする送信方法。
  10. 動画像データを受信装置へ送信するコンピュータに、
    前記コンピュータがデータを送信してから前記受信装置が前記データを受信するまでに要する時間に対応する時間情報を取得する取得手順と、
    前記時間情報に応じて、前記コンピュータが送信したにもかかわらず前記受信装置が受信しなかった消失動画像データを再送するか、或いは、前記消失動画像データよりも再生時刻が後の動画像データを、前記消失動画像データを参照せずに符号化して送信するかを決定する決定手順と
    を実行させることを特徴とするプログラム。
  11. 動画像データを送信する送信装置から動画像データを受信する受信装置が行う通信方法であって、
    前記送信装置がデータを送信してから前記受信装置が前記データを受信するまでに要する時間に対応する時間情報を取得する取得工程と、
    前記時間情報に応じて、前記送信装置が送信したにもかかわらず前記受信装置が受信しなかった消失動画像データの再送を要求するか、或いは、前記消失動画像データよりも再生時刻が後の動画像データを、前記消失動画像データを参照せずに符号化する要求をするかを決定する決定工程と
    を有することを特徴とする通信方法。
  12. 動画像データを送信する送信装置から動画像データを受信するコンピュータに、
    前記送信装置がデータを送信してから前記コンピュータが前記データを受信するまでに要する時間に対応する時間情報を取得する取得手順と、
    前記時間情報に応じて、前記送信装置が送信したにもかかわらず前記コンピュータが受信しなかった消失動画像データの再送を要求するか、或いは、前記消失動画像データよりも再生時刻が後の動画像データを、前記消失動画像データを参照せずに符号化する要求をするかを決定する決定手順と
    を実行させることを特徴とするプログラム。
JP2008237893A 2008-09-17 2008-09-17 送信装置、受信装置、及び方法、プログラム Active JP5207895B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2008237893A JP5207895B2 (ja) 2008-09-17 2008-09-17 送信装置、受信装置、及び方法、プログラム
US12/558,885 US8630178B2 (en) 2008-09-17 2009-09-14 Transmitting apparatus and transmission method
US14/101,849 US9525874B2 (en) 2008-09-17 2013-12-10 Transmitting apparatus and transmission method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2008237893A JP5207895B2 (ja) 2008-09-17 2008-09-17 送信装置、受信装置、及び方法、プログラム

Publications (3)

Publication Number Publication Date
JP2010074366A true JP2010074366A (ja) 2010-04-02
JP2010074366A5 JP2010074366A5 (ja) 2011-10-27
JP5207895B2 JP5207895B2 (ja) 2013-06-12

Family

ID=42007181

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008237893A Active JP5207895B2 (ja) 2008-09-17 2008-09-17 送信装置、受信装置、及び方法、プログラム

Country Status (2)

Country Link
US (2) US8630178B2 (ja)
JP (1) JP5207895B2 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104041016A (zh) * 2012-02-06 2014-09-10 松下电器产业株式会社 摄像机装置、服务器装置、图像监视系统、图像监视系统控制方法及图像监视系统控制程序
JP6099028B1 (ja) * 2016-09-28 2017-03-22 パナソニックIpマネジメント株式会社 テレビ会議装置

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4851911B2 (ja) * 2006-10-23 2012-01-11 富士通株式会社 符号化装置、符号化プログラムおよび符号化方法
JP5091335B2 (ja) * 2011-03-01 2012-12-05 株式会社コナミデジタルエンタテインメント ゲーム機、並びに、それに用いる制御方法及びコンピュータプログラム
US8934332B2 (en) * 2012-02-29 2015-01-13 International Business Machines Corporation Multi-threaded packet processing
US9380176B2 (en) * 2012-05-28 2016-06-28 Avago Technologies General Ip (Singapore) Pte. Ltd. Voice band data mode in a universal facsimile engine
JP6193569B2 (ja) * 2012-12-28 2017-09-06 キヤノン株式会社 受信装置、受信方法、及びプログラム、撮像装置、撮像方法、及びプログラム、送信装置、送信方法、及びプログラム
US9407923B2 (en) 2013-05-20 2016-08-02 Gamefly Israel Ltd. Overconing lost IP packets in streaming video in IP networks
CN109327238A (zh) * 2017-07-28 2019-02-12 芜湖美的厨卫电器制造有限公司 净水机及其电控板的通讯系统和通讯方法
US10291936B2 (en) 2017-08-15 2019-05-14 Electronic Arts Inc. Overcoming lost or corrupted slices in video streaming
JP2019056971A (ja) * 2017-09-19 2019-04-11 株式会社東芝 データ転送回路、データ転送方法及びプログラム

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10262256A (ja) * 1997-03-18 1998-09-29 Canon Inc 画像通信装置、画像通信方法および無線画像通信システム
JPH1198128A (ja) * 1997-09-22 1999-04-09 Sharp Corp データ伝送装置
JP2008092464A (ja) * 2006-10-04 2008-04-17 Toshiba Corp パケット伝送装置

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06237451A (ja) 1993-02-10 1994-08-23 Hitachi Ltd 動画通信方式および端末装置
US5768533A (en) * 1995-09-01 1998-06-16 National Semiconductor Corporation Video coding using segmented frames and retransmission to overcome channel errors
EP1919117B1 (en) * 1998-11-30 2014-10-15 Panasonic Corporation Packet retransmission control using priority information
JP3777279B2 (ja) * 1999-12-20 2006-05-24 富士通株式会社 データ通信システム並びにデータ受信端末及びデータ送信端末
EP1361690B1 (en) * 2000-03-02 2006-01-11 Matsushita Electric Industrial Co., Ltd. Method and apparatus for retransmitting data packets based on channel conditions
JP3348080B1 (ja) * 2000-07-07 2002-11-20 松下電器産業株式会社 データ送信装置とデータ受信装置及びデータ送受信方法
JP2002084338A (ja) * 2000-07-07 2002-03-22 Matsushita Electric Ind Co Ltd データ送信装置、データ受信装置、およびデータ通信システム
KR100450236B1 (ko) * 2000-08-24 2004-09-30 마츠시타 덴끼 산교 가부시키가이샤 송수신 방법 및 그 장치
US7164680B2 (en) * 2001-06-04 2007-01-16 Koninklijke Philips Electronics N.V. Scheme for supporting real-time packetization and retransmission in rate-based streaming applications
JP3912091B2 (ja) * 2001-12-04 2007-05-09 ソニー株式会社 データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム
JP4355156B2 (ja) * 2002-04-16 2009-10-28 パナソニック株式会社 画像復号化方法及び画像復号化装置
JP3836077B2 (ja) * 2002-11-14 2006-10-18 松下電器産業株式会社 伝送データ構造及びそれを伝送するための方法並びに装置
JP2005045409A (ja) * 2003-07-24 2005-02-17 Pioneer Electronic Corp 情報処理装置、そのシステム、その方法、そのプログラム、および、そのプログラムを記録した記録媒体
JP4452983B2 (ja) * 2004-01-08 2010-04-21 ソニー株式会社 受信装置および方法、プログラム、並びに記録媒体
US20060015799A1 (en) * 2004-07-13 2006-01-19 Sung Chih-Ta S Proxy-based error tracking for real-time video transmission in mobile environments
US7898962B2 (en) * 2005-03-14 2011-03-01 Agere Systems Inc. Communications systems with retransmission request budgets
JP4688566B2 (ja) * 2005-05-10 2011-05-25 富士通東芝モバイルコミュニケーションズ株式会社 送信機及び受信機
JP4753204B2 (ja) * 2006-11-17 2011-08-24 株式会社ソニー・コンピュータエンタテインメント 符号化処理装置および符号化処理方法
US20080141091A1 (en) * 2006-12-06 2008-06-12 General Instrument Corporation Method and Apparatus for Recovering From Errors in Transmission of Encoded Video Over a Local Area Network
US8605779B2 (en) * 2007-06-20 2013-12-10 Microsoft Corporation Mechanisms to conceal real time video artifacts caused by frame loss

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10262256A (ja) * 1997-03-18 1998-09-29 Canon Inc 画像通信装置、画像通信方法および無線画像通信システム
JPH1198128A (ja) * 1997-09-22 1999-04-09 Sharp Corp データ伝送装置
JP2008092464A (ja) * 2006-10-04 2008-04-17 Toshiba Corp パケット伝送装置

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104041016A (zh) * 2012-02-06 2014-09-10 松下电器产业株式会社 摄像机装置、服务器装置、图像监视系统、图像监视系统控制方法及图像监视系统控制程序
JPWO2013118491A1 (ja) * 2012-02-06 2015-05-11 パナソニックIpマネジメント株式会社 サーバ装置、画像監視システム、システム制御方法及びシステム制御プログラム
US9639766B2 (en) 2012-02-06 2017-05-02 Panasonic Intellectual Property Management Co., Ltd. Camera device, server device, image monitoring system, control method of image monitoring system, and control program of image monitoring system
JP6099028B1 (ja) * 2016-09-28 2017-03-22 パナソニックIpマネジメント株式会社 テレビ会議装置
JP2018056756A (ja) * 2016-09-28 2018-04-05 パナソニックIpマネジメント株式会社 テレビ会議装置

Also Published As

Publication number Publication date
JP5207895B2 (ja) 2013-06-12
US8630178B2 (en) 2014-01-14
US20100067578A1 (en) 2010-03-18
US9525874B2 (en) 2016-12-20
US20140098884A1 (en) 2014-04-10

Similar Documents

Publication Publication Date Title
JP5207895B2 (ja) 送信装置、受信装置、及び方法、プログラム
KR100966447B1 (ko) 데이터 스트리밍 시스템 및 방법
KR100537499B1 (ko) 전송제어 파라미터 생성방법 및 프레임 특성에 따른선택적 자동 재전송 방법
Apostolopoulos et al. Video streaming: Concepts, algorithms, and systems
US7443797B2 (en) Medium streaming distribution system
KR100705432B1 (ko) 미디어 스트리밍
US8005028B2 (en) Data communication system, data transmitting device, data transmitting method, data receiving device, and data receiving method
JP5084362B2 (ja) データ送信装置、及びデータ送受信システム
JP2009504092A (ja) 損失の多いネットワークを通してデータを送信するためのシステム及び方法
JP2010028378A (ja) 通信装置及び通信方法
KR102118678B1 (ko) 부호화된 비디오 스트림 전송 장치 및 방법
JP2005322995A (ja) リアルタイム映像転送におけるバッファ制御方法、送信端末、受信端末、映像配信システム、およびプログラム
JP2005051299A (ja) パケット送信装置、パケット受信装置、パケット送信方法及びパケット受信方法
US8565083B2 (en) Thinning of packet-switched video data
JP2005033556A (ja) データ送信装置、データ送信方法、データ受信装置、データ受信方法
JP5031230B2 (ja) データ送信装置及び方法
Chen et al. Robust video streaming over wireless LANs using multiple description transcoding and prioritized retransmission
JP3927486B2 (ja) ストリーミング配信装置、ストリーミング配信システム、及びストリーミング配信方法
Chiou et al. Content-aware error-resilient transcoding using prioritized intra-refresh for video streaming
KR20060016809A (ko) 미디어 신호의 수신장치, 송신장치 및 송수신 시스템
JP2004120148A (ja) マルチメディアコンテンツ送信装置およびマルチメディアコンテンツ受信装置
Al-Suhail Impact of packet size on the temporal quality of video transmission over wired-to-wireless network
JP2011015214A (ja) 送信装置、送信方法、及びコンピュータプログラム
Sinky Dynamic Methods to Improve Streaming of H. 264 HD Video Over 802.11 Wireless Networks
Zhang et al. A key-frame-based error resilient coding scheme for video transmission over differentiated services networks

Legal Events

Date Code Title Description
RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20100201

RD01 Notification of change of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7421

Effective date: 20100630

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110913

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20110913

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20120919

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20121023

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20121225

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130219

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20160301

Year of fee payment: 3

R151 Written notification of patent or utility model registration

Ref document number: 5207895

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20160301

Year of fee payment: 3