JP4406816B2 - 受信装置および受信方法、記録媒体、並びにプログラム - Google Patents
受信装置および受信方法、記録媒体、並びにプログラム Download PDFInfo
- Publication number
- JP4406816B2 JP4406816B2 JP2002358945A JP2002358945A JP4406816B2 JP 4406816 B2 JP4406816 B2 JP 4406816B2 JP 2002358945 A JP2002358945 A JP 2002358945A JP 2002358945 A JP2002358945 A JP 2002358945A JP 4406816 B2 JP4406816 B2 JP 4406816B2
- Authority
- JP
- Japan
- Prior art keywords
- frame
- packet
- image
- received
- packets
- 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
Links
- 238000000034 method Methods 0.000 title claims description 108
- 230000005540 biological transmission Effects 0.000 claims description 15
- 238000001514 detection method Methods 0.000 claims 3
- 238000004891 communication Methods 0.000 description 54
- 238000010586 diagram Methods 0.000 description 17
- 230000010365 information processing Effects 0.000 description 3
- 239000003550 marker Substances 0.000 description 3
- 238000004590 computer program Methods 0.000 description 2
- 230000006835 compression Effects 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 230000007423 decrease Effects 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N7/00—Television systems
- H04N7/16—Analogue secrecy systems; Analogue subscription systems
- H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
- H04N21/4382—Demodulation or channel decoding, e.g. QPSK demodulation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
- H04N19/154—Measured or subjectively estimated visual quality after decoding, e.g. measurement of distortion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
- H04N19/162—User input
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
- H04N19/164—Feedback from the receiver or from the transmission channel
- H04N19/166—Feedback from the receiver or from the transmission channel concerning the amount of transmission errors, e.g. bit error rate [BER]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
- H04N19/187—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being a scalable video layer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/44—Decoders specially adapted therefor, e.g. video decoders which are asymmetric with respect to the encoder
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/46—Embedding additional information in the video signal during the compression process
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/85—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression
- H04N19/89—Methods 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
- H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
- H04N21/44209—Monitoring of downstream path of the transmission network originating from a server, e.g. bandwidth variations of a wireless network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
- H04L2012/5603—Access techniques
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/41—Structure of client; Structure of client peripherals
- H04N21/426—Internal components of the client ; Characteristics thereof
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N5/00—Details of television systems
- H04N5/04—Synchronising
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Databases & Information Systems (AREA)
- Compression Or Coding Systems Of Tv Signals (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Television Signal Processing For Recording (AREA)
- Television Systems (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、受信装置および受信方法、記録媒体、並びにプログラムに関し、特に、受信した画像データが欠落している場合であっても、良質な画像を表示することができるようにした送受信システム、送信装置および送信方法、受信装置および受信方法、記録媒体、並びにプログラムに関する。
【０００２】
【従来の技術】
近年、インターネット等を用いて動画データを転送する際に発生する転送エラーについて、さまざまな処理が提案されている。
【０００３】
MPEG４（Moving Picture Experts Group ４）では、再同期マーカとRVLC（Reversible Variable Length Code）等を用いて、転送エラーが起きた箇所を廃棄し、エラー耐性の向上が図られている。
【０００４】
また、発生したエラーを目立たないように遮蔽するエラーコンシールメントの技術としては、動画の時間方向の相関性を利用し、1つ前のフレームを再生するか、または過去の画面の同一位置からの情報と置き換える処理が提案されている。
【０００５】
しかしながら、RVLCを用いてエラー耐性を向上した場合、符号化効率が低下することが指摘されている。また、上述したエラーコンシールメントは、処理が煩雑であり、シーンチェンジ等の急峻な画像の変化には対応することが困難であるという課題があった。
【０００６】
そこで、階層符号化された画像データを転送する場合において、送信されたフレームの一部が欠落し、受信側に送信されない場合には、欠落する時までに受信側で受信され、記憶されたデータをもとに欠落した周波数成分を生成し、より上位の階層の周波成分を再構成するエラーコンシールメント技術が提案されている（例えば、特許文献１参照）。
【０００７】
【特許文献１】
特開平１０−２４３４００号公報（第７ページ）
【０００８】
【発明が解決しようとする課題】
しかしながら、画像情報に多く含まれる低域情報が欠落した場合、画質が劣化するという課題があった。
【０００９】
本発明はこのような状況に鑑みてなされたものであり、受信した画像データに欠陥がある場合であっても、良質な画像を表示することができるようにするものである。
【００１８】
【課題を解決するための手段】
本発明の受信装置は、送信装置から送信されてくるパケットを受信する受信手段と、受信手段により受信されたパケットを保持する保持手段と、画像のフレームが受信されるとき、パケットロスが検出されるまで、受信されたパケットを保持手段に書き込み、パケットロスが検出されてから1フレームの最後のパケットまで、受信されたパケットを保持手段に書き込まない書き込み手段と、保持手段に書き込まれた１フレームの画像に対応するパケットの数が閾値より大きい場合、そのパケットに配置された符号化データのデコードを行い、保持手段に書き込まれた１フレームの画像に対応するパケットの数が閾値以下である場合、そのパケットに配置された符号化データのデコードを行わないデコード手段と、デコード手段により表示対象のフレームの画像に対応する符号化データがデコードされない場合、そのフレームより１フレーム前のフレームがデコードされた画像を表示させる表示制御手段とを備えることを特徴とする。
受信手段は、送信装置から送信されてくる、レイヤ毎の符号化データのパケット数と、符号化データをデコードすることにより得られる画像の画質に関する情報を含むフレーム情報をさらに受信し、デコード手段は、フレーム情報に基づいて決定される閾値に基づいて、デコードを行うことができる。
【００２２】
本発明の受信方法は、送信装置から送信されてくるパケットを受信する受信ステップと、画像のフレームが受信されるとき、パケットロスが検出されるまで、受信されたパケットを保持手段に書き込み、パケットロスが検出されてから1フレームの最後のパケットまで、受信されたパケットを保持手段に書き込まない書き込みステップと、保持手段に書き込まれた１フレームの画像に対応するパケットの数が閾値より大きい場合、そのパケットに配置された符号化データのデコードを行い、保持手段に書き込まれた１フレームの画像に対応するパケットの数が閾値以下である場合、そのパケットに配置された符号化データのデコードを行わないデコードステップと、デコードステップの処理により表示対象のフレームの画像に対応する符号化データがデコードされない場合、そのフレームより１フレーム前のフレームがデコードされた画像を表示させる表示制御ステップとを含むことを特徴とする。
【００２３】
本発明の記録媒体に記録されているプログラムは、送信装置から送信されてくるパケットを受信する受信ステップと、画像のフレームが受信されるとき、パケットロスが検出されるまで、受信されたパケットを保持手段に書き込み、パケットロスが検出されてから1フレームの最後のパケットまで、受信されたパケットを保持手段に書き込まない書き込みステップと、保持手段に書き込まれた１フレームの画像に対応するパケットの数が閾値より大きい場合、そのパケットに配置された符号化データのデコードを行い、保持手段に書き込まれた１フレームの画像に対応するパケットの数が閾値以下である場合、そのパケットに配置された符号化データのデコードを行わないデコードステップと、デコードステップの処理により表示対象のフレームの画像に対応する符号化データがデコードされない場合、そのフレームより１フレーム前のフレームがデコードされた画像を表示させる表示制御ステップとを含むことを特徴とする。
【００２４】
本発明のプログラムは、送信装置から送信されてくるパケットを受信する受信ステップと、画像のフレームが受信されるとき、パケットロスが検出されるまで、受信されたパケットを保持手段に書き込み、パケットロスが検出されてから1フレームの最後のパケットまで、受信されたパケットを保持手段に書き込まない書き込みステップと、保持手段に書き込まれた１フレームの画像に対応するパケットの数が閾値より大きい場合、そのパケットに配置された符号化データのデコードを行い、保持手段に書き込まれた１フレームの画像に対応するパケットの数が閾値以下である場合、そのパケットに配置された符号化データのデコードを行わないデコードステップと、デコードステップの処理により表示対象のフレームの画像に対応する符号化データがデコードされない場合、そのフレームより１フレーム前のフレームがデコードされた画像を表示させる表示制御ステップとを含むことを特徴とする。
【００２７】
本願発明においては、低域情報から高域情報の順で送信装置から送信されてくるパケットが低域情報から高域情報の順で受信され、画像のフレームが受信されるとき、パケットロスが検出されるまで、受信されたパケットが保持手段に書き込まれ、パケットロスが検出されてから1フレームの最後のパケットまで、受信されたパケットが保持手段に書き込まれない。また、保持手段に書き込まれた１フレームの画像に対応するパケットの数が閾値より大きい場合、そのパケットに配置された符号化データのデコードが行われ、保持手段に書き込まれた１フレームの画像に対応するパケットの数が閾値以下である場合、そのパケットに配置された符号化データのデコードが行われない。そして、表示対象のフレームの画像に対応する符号化データがデコードされない場合、そのフレームより１フレーム前のフレームがデコードされた画像が表示される。
【００２８】
【発明の実施の形態】
図１は、本発明を適用した情報処理システム１の構成例を表わしている。
【００２９】
この情報処理システム１において、サーバ１２は、ビデオカメラ１１を介して入力された画像データを、パケット通信網等のネットワーク１４を介して、クライアント１３に送信する。
【００３０】
サーバ１２は、ビデオカメラ１１が撮影した画像のデータが入力されると、その画像データをエンコードして、RTP（Real-time Transport Protocol）パケット（後述する図８）を生成する。サーバ１２は、生成されたRTPパケット（画像データ）を、ネットワーク１４を介して、クライアント１３に送信する。また、サーバ１２は、ユーザによって入力されたフレーム情報（後述する図５）をクライアント１３に送信する。
【００３１】
クライアント１３は、画像データを受信し、1フレーム内にパケットロスがある場合、パケットロスが生じるまでの画像データを保持する。クライアント１３は、受信したフレーム情報に基づいて、保持した画像データの画質またはデータ量が、ユーザによって設定された閾値以上であるか否かを判断し、閾値以上である場合、画像データをデコードし、ディスプレイ等の表示部に、デコードされた画像データを表示させる。閾値以上ではない場合、前のフレームの画像を表示させる。
【００３２】
図２は、サーバ１２の構成を示す図である。なお、図中、“Ｓ”の文字と数字からなる記号で示されている矢印は、後述する図３と図４のフローチャートの処理のステップに対応している。
【００３３】
制御部３１には、例えばユーザが入力するフレーム情報が供給される。制御部３１は、ユーザにより入力された画像データのフレーム情報を、フレーム情報保持部３２に供給する。フレーム情報保持部３２は、制御部３１から供給されるフレーム情報を保持する。ここで、フレーム情報は、1フレームのレイヤ毎のパケット数と画質から構成されているが、詳細は、図５で後述する。
【００３４】
エンコーダ３３は、ビデオカメラ１１が撮影した画像のデータが入力されると、JPEG（Joint Photographic Experts Group）2000等の階層符号化によって、画像データをエンコードする。なお、エンコーダ３３は、画像データの各フレームをどのような階層（レイヤ）に階層符号化するかを、フレーム情報保持部３２に記憶されたフレーム情報に基づいて決定する。
【００３５】
エンコーダ３３は、エンコードした画像データを、バッファ３４に供給して保持させる。RTPパケット生成部３５は、バッファ３４に記憶（保持）された画像データを取得し、フレーム情報保持部３２に保持されたフレーム情報におけるレイヤ毎のパケット数に基づいて、画像データをRTPパケット化する。
【００３６】
そして、RTPパケット生成部３５は、画像データをRTPパケット化することにより得られるパケットを、通信部３６に供給する。通信部３６は、RTPパケット生成部３５から供給された画像データのパケットを、ネットワーク１４を介して、クライアント１３に供給する。さらに、通信部３６は、フレーム情報保持部３２から、フレーム情報を取得し、ネットワーク１４を介して、クライアント１３にフレーム情報を送信する。
【００３７】
次に、図３と図４を参照して、図２のサーバ１２における画像データ送信処理を説明する。なお、この処理は、ビデオカメラ１１から、サーバ１２に画像データが入力されたとき、またはユーザにより、サーバ１２に画像データの送信処理が指令されたとき、開始される。
【００３８】
ステップＳ１において、制御部３１は、ユーザにより入力された各レイヤのパケット数と画質（以下、適宜、フレーム情報と称する）を、フレーム情報保持部３２に保持する。なお、フレーム情報は、例えば、ユーザが図示せぬ操作部等を操作して予め入力するものとする。
【００３９】
ここで、図５は、フレーム情報保持部３２に保持されるフレーム情報を示している。フレーム情報５０は、レイヤ（を表す情報）５１、パケット数（を表す情報）５２、画質（を表す情報）５３から構成されている。図５では、１フレームは、レイヤ「Ｌ０」、レイヤ「Ｌ１」、レイヤ「Ｌ２」の３つのレイヤから構成されるものとしてある。また、図５では、レイヤ「Ｌ０」のパケット数５２は「２０」とされており、従って、レイヤ「Ｌ０」は、「２０」個のパケットから構成される。また、レイヤ「Ｌ０」の画質は「０．５bpp（bit-per-pixel）」とされている。
【００４０】
同様に、図５では、レイヤ「Ｌ１」は、「２５」個のパケットから構成され、画質５３は「０．７ｂｐｐ」とされている。レイヤ「Ｌ２」は、「４５」個のパケットから構成され、画質５３は、「１．０ｂｐｐ」とされている。以上から、図５のフレーム情報によれば、１フレームは、「２０＋２５＋４５＝９０」個のパケットから構成される。
【００４１】
図３に戻り、ステップＳ１の処理後は、ステップＳ２に進み、RTPパケット生成部３５は、フレーム毎に付加されるタイムスタンプを初期化して、ステップＳ３に進む。即ち、RTPパケット生成部３５は、最初のフレームに付加するタイムスタンプの値を設定する。
【００４２】
ステップＳ３において、通信部３６は、フレーム情報保持部３２からフレーム情報を取得し、ステップＳ４に進む。ステップＳ４において、通信部３６は、フレーム情報保持部３２から取得したフレーム情報を、RTSP（Real-time Streaming Protocol）等のストリーミングのセッション管理プロトコルを用い、ネットワーク１４を介して、クライアント１３に送信する。なお、RTSPは、RFC（Request For Comment）2326で定義されている。
【００４３】
ここで、図６は、RTSPを用いて、サーバ１２がクライアント１３にフレーム情報を送信する場合に、サーバ１２からクライアント１３に送信させるメッセージと、そのメッセージを受信したクライアント１３がサーバ１２に送信する了承のメッセージの例を示している。
【００４４】
「S→C」は、サーバ１２からクライアント１３に送信するメッセージであることを表し、「C→S」は、クライアント１３からサーバ１２に送信するメッセージであることを表している。なお、「OPTIONS」はメソッドを表し、「OPTIONS＊RTSP/1.0」は拡張メソッドであることを示している。また、「CSeq」は、RTSPのメッセージ番号を示しており、「Packet-1layer-bpp」は、ヘッダである。ヘッダには、レイヤ名、積算パケット数（レイヤ名のレイヤまでのパケット数）、レイヤの画質の３つの情報のセットが１セットまたは繰り返し記述される。
【００４５】
図６の例の場合、サーバ１２からクライアント１３に送信されるメッセージは、RTSP番号が「１」の拡張メソッドのメッセージである。ヘッダには、図５に示した情報が記述されている。即ち、図５では、レイヤＬ０は、積算パケット数（レイヤＬ０のパケット数）が「２０」であり、画質が「０．５ｂｐｐ」である。レイヤＬ１は、積算パケット数（レイヤＬ０とレイヤＬ１のパケット数の和）が「４５」（レイヤＬ１のパケット数は「２５」）であり、画質が「０．７ｂｐｐ」である。レイヤＬ２は、積算パケット数（レイヤＬ０、レイヤＬ１、レイヤＬ２のパケット数の和）が「９０」（レイヤＬ２のパケット数は「４５」）であり、画質が「１．０ｂｐｐ」である。このため、サーバ１２からクライアント１３に送信するメッセージのヘッダには、図６に示したように、Ｌ０ ２０ ０．５ Ｌ１ ４５ ０．７ Ｌ２ ９０ １．０が記述される。
【００４６】
また、クライアント１３からサーバ１２に送信される図６に示したメッセージは、RTSP番号が「１」の拡張メソッドのメッセージ（サーバ１２からクライアント１３に送信されたメッセージ）を受信したことを通知するメッセージである。
【００４７】
図３に戻り、ステップＳ４において、サーバ１２からクライアント１３にフレーム情報（が記述されたメッセージ）が送信された後は、ステップＳ５に進み、エンコーダ３３は、予め設定されたフレームレート（例えば、３０フレーム／秒）に基づいて、エンコーダ３３に設けられた不図示のタイマに、１フレーム分の時間（いまの場合、３３ｍｓ）を設定し、ステップＳ６に進む。ステップＳ６において、エンコーダ３３は、ビデオカメラ１１を介して撮影された画像のデータを取得し、ステップＳ７に進む。ステップＳ７において、エンコーダ３３は、タイマに設定された所定時間（いまの場合、３３ｍｓ）が経過した（タイマが終了した）か否かを判定し、所定時間が経過したと判定するまで、画像データを取得する処理を行なう。
【００４８】
ステップＳ７において、エンコーダ３３は、所定時間が経過したと判定した場合、ステップＳ８に進み、画像データの取得を終了し、取得した画像データをエンコードする。即ち、エンコーダ３３は、１フレーム分の画像データを、フレーム情報保持部３２に記憶されたフレーム情報に基づいて階層符号化することによりエンコードし、そのエンコード結果として符号化データを取得する。そして、図４のステップＳ９に進み、エンコーダ３３は、１フレーム分の画像データをエンコードすることにより得られた符号化データをバッファ３４に供給して保持させる。
【００４９】
ここで、図７は、バッファ３４に保持された１フレーム分の符号化データを示している。符号化データは、SOC（Start Of Code stream）７１、Code stream７２、およびEOC（End Of Code stream）から構成されている。SOC７１は、符号化データの開始を示すデータであり、EOC７３は、符号化データの終了を示すデータである。また、Code Stream７２は、エンコードされた画像データである。
【００５０】
ここで、エンコーダ３３で行われる階層符号化である、例えば、JPEG2000は、解像度や圧縮率などが異なる複数種類のプログレッシブ表示に対応している。またJPEG2000は、画質スケーラブル（SNR(Signal to Noise Ratio)）に対応している。本実施の形態では、エンコーダ３３は、画像データを、例えば、JPEG2000方式で、図５に示したフレーム情報にしたがい、画質スケーラブルに階層符号化し、各階層（レイヤ）のデータをCode Stream７２に配置する。
【００５１】
その結果、図７では、Code Stream７２は、図５に示したフレーム情報にしたがって、レイヤＬ０データ９１、レイヤＬ１データ９２、およびレイヤＬ２データ９３に階層化されている。レイヤＬ０データ９１は、画像データの低域情報となっており、レイヤＬ１データ９２は、中域情報となっている。そして、レイヤＬ２データ９３は、画像データの高域情報となっている。
【００５２】
従って、レイヤＬ０データ９１をデコードすると、画質の低い元の画像（図５の例の場合、０．５ｂｐｐの画質の画像）と同じ空間解像度の画像が得られる。また、レイヤＬ１データ９２まで（レイヤＬ０データとレイヤＬ１データ）をデコードすると、レイヤＬ０データ９１だけをデコードした場合よりも画質の良い画像（図５の例の場合、０．７５ｂｐｐの画質の画像）が得られる。さらに、レイヤＬ２データ９３まで（レイヤＬ０データ９１、レイヤＬ１データ９２、レイヤＬ３データ９３）をデコードすると、さらに良い画質の画像（図５の例の場合、１．０の画質の画像）を得ることができる。
【００５３】
なお、エンコーダ３３は、符号化データをデコードしたときに、フレーム情報における画質の画像を得ることができるように階層符号化を行い、レイヤＬ０データ、レイヤＬ１データ９２、レイヤＬ３データ９３を得る。
【００５４】
図４に戻り、ステップＳ９の処理後は、ステップＳ１０に進み、RTPパケット生成部３５は、フレーム情報保持部３２から、フレーム情報５０（図５）を取得し、ステップＳ１１に進む。ステップＳ１１において、RTPパケット生成部３５は、バッファ３４に保持されている１フレーム分の符号化データから、ステップＳ１０で取得したフレーム情報５０における各レイヤ毎のパケット数のパケットが得られるサイズのデータを取得し、RTPパケットを生成する。
【００５５】
即ち、RTPパケット生成部３５は、図５に示したフレーム情報５０を取得した場合、レイヤＬ０データ９１から２０個のRTPパケットを、レイヤＬ１データ９２から２５個のRTPパケットを、レイヤＬ２データ９３から４５個のRTPパケットを生成する。
【００５６】
ステップＳ１１でRTPパケットを生成した後は、ステップＳ１２に進み、RTPパケット生成部３５は、生成したRTPパケットを、レイヤＬ０からレイヤＬ２の順で通信部３６に供給し、ステップＳ１３に進む。ステップＳ１３において、通信部３６は、RTPパケットを、ネットワーク１４を介してクライアント１３に送信する。
【００５７】
ここで、図８は、通信部３６がクライアント１３に送信するRTPパケットのRTPフォーマットの例を示している。RTPヘッダは、バージョン番号を示すｖ１１１、パディングを示すｐ１１２、拡張ヘッダの有無を示すｘ１１３、送信元数（Counter）を示すｃｃ１１４、マーカ情報（marker bit）を示すｍ１１５、ペイロードタイプを示すｐｔ１１６、シーケンス番号を示すsequence１１７、タイムスタンプを示すtimestamp１１８、同期ソース（送信元）識別子を示すSSRC１１９から構成される。RTPヘッダの後には、符号化データがData１２０として配置される。
【００５８】
クライアント１３は、timestamp１１８に記述されたタイムスタンプにより、RTPパケットを展開するときの処理時間を制御し、リアルタイム画像、または音声の再生制御を行う。なお、タイムスタンプは、１フレーム毎に決定され、同一のフレームの符号化データを配置させる複数のRTPパケットには、共通のタイムスタンプが設定される。
【００５９】
図９は、通信部３６が、図５に示したフレーム情報５０に基づいて生成されたRTPパケットを、ネットワーク１４を介して、クライアント１３に、送信する例を示す図である。なお、横軸ｔは時間を表している。
【００６０】
まず、通信部３６は、レイヤＬ０の符号化データ（図７のレイヤＬ０データ９１）（画像データの低域情報）のパケットを２０個（シーケンス番号１乃至２０のパケット）送信する。次に、レイヤＬ１の符号化データ（図７のレイヤＬ１データ９２）（画像データの中域情報）のパケットを４５個（シーケンス番号２１乃至４５のパケット）送信する。最後に、通信部３６は、レイヤＬ３の画像データ（図７のレイヤＬ３データ９３）（画像データの高域情報）のパケットを４５個（シーケンス番号４６乃至９０のパケット）送信し、1フレームの符号化データの送信が終了する。なお、シーケンス番号は、エンコードされた最初の画像データ（図７のSOC７１の次のデータ）から生成されたパケットから順に付され、図８に示したRTPパケットのsequence１１７に配置される。
【００６１】
図４に戻り、ステップＳ１３において、RTPパケットを送信した後は、ステップＳ１４に進み、RTPパケット生成部は、RTPパケットのtimestamp１１８（図８）に記述するタイムスタンプを更新し、ステップＳ１５に進む。
【００６２】
ここで、図８のsequence１１７に配置されるシーケンス番号は、RTPパケットにシーケンシャルに付される。従って、このシーケンス番号によって、クライアント１３は、受信したRTPパケットが、送信されたRTPパケットに対して足りない（欠落している）かどうかを検出することができる。
【００６３】
ステップＳ１５において、サーバ１２は、全ての画像データを、クライアント１３に送信したか否かを判定する。サーバ１２は、全ての画像データをクライアント１３に送信していないと判定した場合、処理をステップＳ１５からＳ５に戻し、ビデオカメラ１１を介して撮影された画像データを、フレーム毎に取得し、RTPパケットを送信する処理を繰り返す。ステップＳ１５において、サーバ１２は、全ての画像データをクライアント１３に送信したと判定した場合、処理を終了する。
【００６４】
次に、図１０は、図１のクライアント１３の構成例を示している。なお、図中、“Ｓ”の文字と数字からなる記号で示されている矢印は、後述する図１１乃至図１３のフローチャートの処理のステップに対応している。
【００６５】
通信部１４１は、サーバ１２から送信されているフレーム情報とRTPパケットを受信する。受信制御部１４７は、通信部１４１が受信したフレーム情報とRTPパケットに基づいて受信処理を行ない、通信部１４１により受信されたRTPパケット（画像データ）のバッファ１４２への書き込みを制御する。この受信処理の詳細は、図１４乃至図２１を参照して後述する。
【００６６】
また、受信制御部１４７は、フレーム情報を、通信部１４１から取得し、画像情報保持部１４８のフレーム情報保持部１５０に供給して保持させる。さらに、受信制御部１４７は、通信部１４１が受信したRTPパケットのタイムスタンプ毎（１フレーム毎）に、画像情報保持部１４８のエントリ情報蓄積部１４９にエントリし、RTPパケットの形で受信した画像データの情報（以下、適宜、エントリ情報と称する）を保持する。
【００６７】
通信部１４１は、受信制御部１４７の制御にしたがい、受信したRTPパケットをバッファ１４２に書き込み、これによりバッファ１４２は、通信部１４１から供給されるRTPパケットを一時保持する。デコーダ１４３は、バッファ１４２に保持されたRTPパケットを取得する。
【００６８】
閾値保持部１５１は、例えば、ユーザにより入力された、タイムスタンプ毎のデータ量（RTPパケット数）または画質の閾値を保持する。
【００６９】
デコーダ制御部１５２は、閾値保持部１５１で保持された閾値と、エントリ情報蓄積部１４９で保持されたエントリ情報（後述する図２１）に基づいて、デコーダ１４３で取得されRTPパケットの、デコードを許可するか否かを判断する。
【００７０】
デコーダ１４３は、デコーダ制御部１５２によりデコードが許可されると、バッファ１４２から取得したRTPパケットに配置された符号化データをデコードし、そのデコードの結果得られる画像データをフレームメモリ１４４に記億する。表示制御部１４５は、フレームメモリ１４４に記憶された画像データを取得し、ディスプレイ等の表示部１４６に画像を表示させる。
【００７１】
図１０のクライアント１３の画像表示処理を、図１１乃至図１３を用いて詳細に説明する。なお、この処理は、サーバ１１から画像データが送信されたとき、開始される。
【００７２】
ステップＳ３１において、クライアント１３は、自身を初期化し、ステップＳ３２に進む。これにより、バッファ１４２、フレームメモリ１４４、画像情報保持部１４８、および閾値保持部１５１に保持されているデータは消去される。ステップＳ３２において、閾値保持部１５１は、ユーザにより入力されたデータ量（RTPパケット数）または画質の閾値を保持し、ステップＳ３３に進む。なお、閾値は、例えば、ユーザが図示せぬ操作部等を操作して予め入力するものとする。
【００７３】
ステップＳ３３において、通信部１４１は、図３のステップＳ４の処理でサーバ１２から送信されたフレーム情報（図６）、または図４のステップＳ１３の処理でクライアント１３から送信されたRTPパケット（図９）を、ネットワーク１４を介して受信し、ステップＳ３４に進む。
【００７４】
ステップＳ３４において、受信制御部１４７は、通信部１４１で受信されたフレーム情報を通信部１４１から取得し、フレーム情報保持部１５０に供給して保持させる。これにより、画像情報保持部１４８のフレーム情報保持部１５０は、図２のフレーム情報保持部３２に保持されたフレーム情報と同じフレーム情報を保持する。従って、図６に示したフレーム情報が通信部１４１で受信された場合、図５に示したフレーム情報が、フレーム情報保持部１５０に保持される。
【００７５】
ステップＳ３４の処理後は、ステップＳ３５に進み、受信制御部１４７は、受信処理を行ない、これにより通信部１４１により受信されたRTPパケットの書き込み許可または不許可を決定するとともに、後述するエントリ情報を、エントリ情報蓄積部１４９に記憶させる。なお、受信処理の詳細は、図１４と図１５のフローチャートを用いて後述する。
【００７６】
ステップＳ３５の処理後は、ステップＳ３６に進み、通信部１４１は、ステップＳ３５の受信処理で、受信制御部１４７からRTPパケットの書き込みが許可されたか否かを判定する。通信部１４１は、受信制御部１４７から書き込みが許可された場合、ステップＳ３６からＳ３７に進み、ステップＳ３３の処理で受信したRTPパケットを、バッファ１４２に供給して書き込み、これによりバッファ１４２は、通信部１４１が受信したRTPパケットを保持する。
【００７７】
そして、ステップＳ３８に進み、デコーダ１４３は、バッファ１４２に１フレーム分のRTPパケットが保持されたか否かを判定する。即ち、デコーダ１４３は、１フレーム分の受信処理の時間を予め内蔵するタイマ（図示せず）に設定しておき、タイマによって、その設定した時間が計時されたか否かを判定する。デコーダ１４３は、１フレーム分のRTPパケットが保持されるまで、ステップＳ３８の処理を繰り返し、１フレーム分のRTPパケットが保持された場合、処理をステップＳ３８から図１２のＳ３９に進める。
【００７８】
ステップＳ３９において、デコーダ１４３は、ステップＳ３７の処理でバッファ１４２に保持された１フレーム分のRTPパケットを、バッファ１４２から取得し、ステップＳ４０に進む。ステップＳ４０において、デコーダ制御部１５２は、画像情報保持部１４８から、図１１のステップＳ３４，Ｓ３５の処理で保持された画像情報、即ちエントリ情報蓄積部１４９に保持されたエントリ情報とフレーム情報保持部１５０に保持されたフレーム情報を取得し、ステップＳ４１に進む。
【００７９】
ステップＳ４１において、デコーダ制御部１５２は、ステップＳ３２の処理で閾値保持部１５１に保持されたデコーダ量（RTPパケット数）または画質の閾値を取得し、ステップＳ４２に進む。ステップＳ４２において、デコーダ制御部１５２は、ステップＳ３９の処理で取得した画像情報と、ステップＳ４１の処理で取得した閾値に基づいて、デコード判断処理を行い、これにより、デコーダ１４３によるデコードの許可または不許可を決定する。このデコード判断処理は、図２２のフローチャートを用いて後述する。
【００８０】
ステップＳ４２の処理後は、図１３のステップＳ４３に進み、デコーダ１４３は、ステップＳ４２の処理により、デコーダ制御部１５２からデコードが許可されたか否かを判定する。デコーダ１４３は、デコーダ制御部１５２からデコードが許可された場合、処理をステップＳ４３からＳ４４に進め、ステップＳ３９の処理でバッファ１４２から取得したRTPパケットをデコードし、ステップＳ４５に進む。
【００８１】
ステップＳ４５において、デコーダ１４３は、デコードした画像データをフレームメモリ１４４に供給して記憶させ、ステップＳ４６に進む。ステップＳ４６において、表示制御部１４５は、ステップＳ４５でフレームメモリ１４４に記憶された画像データを取得し、ステップＳ４７に進む。ステップＳ４７において、表示制御部１４５は、ステップＳ４６で取得した画像データに基づいて、表示部１４６に画像を表示させ、処理を終了する。
【００８２】
一方、ステップＳ４３において、デコーダ制御部１５２からデコードが許可されていないと判定された場合、処理がステップＳ４８に進み、表示制御部１４５は、フレームメモリ１４４に前のフレーム（いま表示すべきフレームの、例えば、１フレーム前のフレームなど）の画像データが存在するか否かを判定する。ステップＳ４８において、フレームメモリ１４４に前のフレームの画像データが存在する（前のフレームの画像データを受信したとき、ステップＳ４５の処理が行なわれた）と判定された場合、ステップＳ４９に進み、表示制御部１４５は、前のフレームの画像（フレームメモリ１４４に記憶されている画像）を、表示部１４６に表示させ、処理を終了する。
【００８３】
また、ステップＳ４８において、フレームメモリ１４４に前のフレームの画像データが存在しないと判定された場合、ステップＳ４９をスキップして処理を終了する。従って、この場合、表示部１４６には何も表示されない。
【００８４】
一方、図１２のステップＳ３６において、通信部１４１は、受信制御部１４７からRTPパケットの書き込みが許可されていないと判定した場合、RTPパケットをバッファに書きこまずに、処理を終了する。
【００８５】
なお、図１１および図１２の処理は、サーバ１２から、RTPパケットが送信されてこなくなるまで繰り返される。
【００８６】
次に、図１４のフローチャートを参照して、受信制御部１４７における受信処理について説明する。このフローチャートは、上述した図１１のステップＳ３４，Ｓ３５の処理を詳細に説明するものである。
【００８７】
ステップＳ６１において、受信制御部１４７は、通信部１４１が、図１１のステップＳ３３の処理により、フレーム情報を受信したか否かを判定する。ステップＳ６１において、フレーム情報を受信したと判定された場合、ステップＳ６２に進み、受信制御部１４７は、画像情報保持部１４８のフレーム情報保持部１５０に、通信部１４１が受信したフレーム情報を供給して保持させ、処理をステップＳ６１に戻す。
【００８８】
また、ステップＳ６１において、フレーム情報を受信していないと判定された場合、ステップＳ６３に進み、受信制御部１４７は、通信部１４１がRTPパケットを受信したか否かを判定する。ステップＳ６３において、画像データを受信していないと判定された場合、通信部１４１が受信したデータは、必要のないデータであるので、受信制御部１４７は、以降の処理を行なわず、処理をステップＳ６１に戻し、以下、同様の処理を繰り返す。
【００８９】
また、ステップＳ６３において、受信制御部１４７は、通信部１４１が画像データを受信したと判定した場合、ステップＳ６４に進み、通信部１４１が受信したRTPパケットのタイムスタンプを検出する。即ち、RTPパケットは、図８に示したフォーマットで送信されるので、受信制御部１４７は、ヘッダのtimestamp１１８に記述されたタイムスタンプの値を検出する。なお、このタイムスタンプは、図３のステップＳ２の処理で初期化され、図４のステップＳ１４で１フレーム毎に更新されるものである。
【００９０】
ここで、図１６は、通信部１４１で受信されるRTPパケットの例を、横軸を時間ｔとして示している。この例の場合、１フレームは９０個のRTPパケットから構成されている。通信部１４１は、タイムスタンプが「１０００」のフレームの画像データのRTPパケット群（シーケンス番号が１乃至９０のRTPパケット）を受信し、その後は、タイムスタンプが「２０００」のフレームの画像データのRTPパケット群（シーケンス番号が９１乃至１８０のRTPパケット）を受信する。そして、通信部１４１は、タイムスタンプが「３０００」のフレームの画像データのRTPパケット群（シーケンス番号が１８１乃至２７０のRTPパケット）を受信し、最後にタイムスタンプが「４０００」のフレームの画像データのRTPパケット群（シーケンス番号が２７１乃至３６０のRTPパケット）を受信する。なお、図１６では、シーケンス番号１３１とシーケンス番号１９１のRTPパケットは、ロス（欠落）している。
【００９１】
図１４に戻り、ステップＳ６４の処理後は、ステップＳ６５に進み、受信制御部１４７は、前回のステップＳ６４の処理で検出したタイムスタンプがあるか否かを判定する。ステップＳ６５において、前回検出したタイムスタンプがあると判定された場合、ステップＳ６６に進み、受信制御部１４７は、今回のステップＳ６４の処理で検出したタイムスタンプが、前回検出したタイムスタンプと一致するか否かを判定する。
【００９２】
ステップＳ６６において、今回検出したタイムスタンプが前回のタイムスタンプと一致しないと判定された場合、ステップＳ６７に進み、受信制御部１４７は、今回検出したタイムスタンプが、前回のタイムスタンプより大きいか否かを判定する。ステップＳ６７において、今回検出したタイムスタンプが、前回のタイムスタンプより大きくない（小さい）と判定された場合、受信された画像データは、既に受信され、処理された画像データなので、処理をステップＳ６１に戻す。
【００９３】
また、ステップＳ６７において、今回検出したタイムスタンプが、前回のタイムスタンプより大きいと判定された場合、またはステップＳ６５で前回のタイムスタンプがないと判定された場合、即ち、通信部１４１が受信したRTPパケットがフレームの最初のRTPパケットである場合、受信制御部１４７は、処理をステップＳ６８に進め、今回検出したタイムスタンプをエントリ情報蓄積部１４９にエントリする。
【００９４】
例えば、通信部１４１において、図１６に示したRTPパケットのシーケンスが受信される場合、シーケンス番号１のRTPパケットが受信されると、このRTPパケットは、フレーム内の最初のパケットであるので、図１７に示すように、タイムスタンプ「１０００」が配置されたエントリ情報がエントリ情報蓄積部１４９にエントリ（登録）される。なお、エントリ情報は、タイムスタンプ１８１、受信データ量１８２、フラグ１８３から構成され、フラグ１８３は、ロスが検出されたか否かを示している（ステップＳ７３の処理で後述する）。また、受信データ量１８２は、受信した１フレーム内のRTPパケットの数を示し、その１フレーム内の新たなRTPパケットを受信したとき、インクリメントされる（後述するステップＳ７０の処理）。
【００９５】
また、図１６において、シーケンス番号９１のRTPパケットが受信されると、そのRTPパケットのタイムスタンプは、前回のタイムスタンプ「１０００」（シーケンス番号９０のタイムスタンプ）より大きいので、新たなタイムスタンプ「２０００」がエントリ情報蓄積部１４９にエントリされ、図１８に示されるようなエントリ情報がエントリ情報蓄積部１４９に保持される。
【００９６】
図１８では、受信されたタイムスタンプ１８１が「１０００」の画像データが、シーケンス番号１乃至９０のRTPパケットから構成され、ロスはないので、受信データ量１８２が「９０」となっており、フラグ１８３は、ロスがないことを示す「０」となっている。そして、シーケンス番号９１のRTPパケットが新たに受信されたので、タイムスタンプ１８１に「２０００」がエントリされている。
【００９７】
図１５に戻り、ステップＳ６８の処理後は、ステップＳ６９に進み、受信制御部１４７は、通信部１４１が受信したRTPパケットのシーケンス番号（図８のフォーマットのsequence１１７に記述された番号）に基づいて、RTPパケットがロスしているか否かを判定する。即ち、ステップＳ６９では、通信部１４１が今回受信したRTPパケットのシーケンス番号が、前回受信したRTPパケットのシーケンス番号の次の番号である場合、RTPパケットがロスしていないと判定され、次の番号ではない場合、RTPパケットがロスしている（送信エラーにより、RTPパケットが欠落している）と判定される。ステップＳ６９において、RTPパケットがロスしていないと判定された場合は、ステップＳ７０に進み、ロスしていると判定された場合は、ステップＳ７３に進む。
【００９８】
一方、図１４のステップＳ６６において、今回検出したタイムスタンプが、前回のタイムスタンプと一致すると判定された場合、ステップＳ７２に進み、受信制御部１４７は、RTPパケットがロスしている（シーケンス番号が続き番号ではない）か否か、またはエントリ情報蓄積部１４９のフラグ１８２が「１」である（前回までにロスが検出された）か否かを判定する。
【００９９】
ステップＳ７２の処理において、ロスが検出されず、フラグ１８２が「１」ではない（「０」である）と判定された場合、図１５のステップＳ７０に進み、受信制御部１４７は、エントリ情報蓄積部１４９の受信データ量１８２を１だけインクリメントする。
【０１００】
例えば、シーケンス番号９１のRTPパケットが受信され、これにより、ステップＳ６８の処理で、エントリ情報蓄積部１４９に、図１８に示したエントリ情報が保持された場合、ロスがないので、エントリ情報蓄積部１４９には、図１９に示すエントリ情報が保持される。即ち、タイムスタンプ１８１が「２０００」の受信データ量１８２は、「０」から「１」にインクリメントされる。
【０１０１】
また、図１６のケースで、シーケンス番号１乃至９４までが正常に受信されている場合、エントリ情報蓄積部１４９のタイムスタンプ「２０００」の受信データ量１８２は、「４」となっている。その後、シーケンス番号９５が受信されると、受信データ量１８２は、インクリメントされ、「５」となる。
【０１０２】
図１５に戻り、ステップＳ７０の処理後は、ステップＳ７１に進み、受信制御部１４７は、通信部１４１にバッファ１４２へのRTPパケットの書き込みを許可し、処理を終了する。したがって、通信部１４１は、図１１のステップＳ３７の処理を行なって、受信した画像データ（RTPパケット）をバッファ１４２に書き込み、以降の処理を行なう。
【０１０３】
一方、図１４のステップＳ７２において、RTPパケットがロスしていると判定された場合、またはフラグ１８３が「１」であると判定された場合、受信制御部１４７は、処理をステップＳ７３に進め、エントリ情報蓄積部１４９のフラグを「１」に設定し、処理を終了する。このとき、受信制御部１４７は、通信部１４１にバッファ１４２へのRTPパケットの書き込みを許可しない。従って、この場合、通信部１４１は、RTPパケットをバッファ１４２に書き込まない。
【０１０４】
例えば、図１６に示した画像データのシーケンス番号１３２のRTPパケットが受信された場合、シーケンス番号１３１のRTPパケットがロスしているので、エントリ情報蓄積部１４９に保持されたエントリ情報は、図２０に示すように、フラグ１８３が「０」から「１」に変更される。なお、RTPパケットはバッファ１４２に書き込まれないので、受信データ量１８２は、変更されない。
【０１０５】
また、図１６に示した画像データのシーケンス番号１３３のRTPパケットが受信された場合も、フラグが「１」である（ロスしているRTPパケットがある）ので、エントリ情報蓄積部のフラグ１８３は「１」のままであり、RTPパケットはバッファ１４２に書き込まれないので、受信データ量１８２も「４０」のまま変更されない。
【０１０６】
上述の処理は、全ての画像データが受信されるまで、パケット毎に行われる。
【０１０７】
図１６に示されるような画像データが通信部１４１で受信された場合のエントリ情報蓄積部１４９のエントリ情報の例を図２１に示す。
【０１０８】
この例の場合、タイムスタンプが「１０００」のフレームは、９０個のパケットから構成され、ロスがないので、タイムスタンプ１８１が「１０００」の受信データ量１８２は、「９０」となり、フラグ１８３は、「０」となる。また、タイムスタンプが「２０００」のフレームは、シーケンス番号１３１のRTPパケットがロスしているので、シーケンス番号９１乃至１３０のRTPパケットのみが書き込みを許可され（ステップＳ７０，Ｓ７１の処理）、タイムスタンプ１８１が「２０００」の受信データ量は、「４０」となる。また、このとき、RTPパケットのロスが検出されるので、フラグ１８３は、「１」となる。
【０１０９】
同様に、タイムスタンプ「３０００」のフレームは、１９１のRTPパケットがロスしているので、シーケンス番号１８１乃至１９０のRTPパケットのみが書き込みを許可され、タイムスタンプ１８１が「３０００」の受信データ量は、「１０」となり、ロスが検出されたので、フラグ１８３は、「１」となる。タイムスタンプ「４０００」のフレームは、ロスがないので、全てのRTPパケットがバッファ１４２に書き込まれ、受信データ量１８２は、「９０」となり、フラグ１８３は、「０」となる。
【０１１０】
図１４と図１５の処理により、受信制御部１４７は、ロスするまでの画像データ（ロスのない画像データ）のみをバッファ１４２に書き込む。
【０１１１】
このように、シーケンス番号を検出することにより、ロスを検出することができる。また、ロスの検出の有無を示すフラグを判定することにより、ロスが検出されるまでの画像データのみを確実に保持することができる。
【０１１２】
次に、図２２のフローチャートを参照して、デコーダ制御部１５２におけるデコード判断処理について説明する。このフローチャートは、上述した図１２のステップＳ３９乃至Ｓ４２の処理を詳細に説明するものである。
【０１１３】
ステップＳ９１において、デコーダ制御部１５２は、デコーダ１４３のデコード対象のタイムスタンプを、初期値（いまの場合、「１０００」）に設定し、ステップＳ９２に進む。ステップＳ９２において、デコーダ制御部１５２は、閾値保持部１５１から、図１１のステップＳ３２の処理で保持されたデータ量（RTPパケット数）または画質の閾値を取得し、ステップＳ９３に進む。
【０１１４】
ステップＳ９３において、デコーダ制御部１５２は、画像情報保持部１４８から画像情報を取得する。即ち、エントリ情報蓄積部１４９からエントリ情報（図２１）を取得し、フレーム情報保持部１５０からフレーム情報（図５）を取得する。
【０１１５】
ステップＳ９３の処理の後は、ステップＳ９４に進み、デコーダ制御部１５２は、デコーダ１４３の不図示のタイマを所定時間（１フレーム分の画像データを取得するのに必要な時間）に設定し、開始させ、ステップＳ９５に進む。ステップＳ９５において、デコーダ制御部１５２は、デコーダ１４３を制御し、バッファ１４２から画像データを取得し、ステップＳ９６に進む。ステップＳ９６において、デコーダ制御部１５２は、タイマが終了したか否かを判定し、タイマが終了するまでステップＳ９５の処理を繰り返す。
【０１１６】
ステップＳ９６の処理において、タイマが終了した（１フレーム分のRTPパケットが取得された）場合、デコーダ制御部１５２は、処理をステップＳ９６からＳ９７に進める。
【０１１７】
ステップＳ９７において、エントリ情報蓄積部１４９から取得された（ステップＳ９３）受信データ量１８２が、閾値保持部１５１から取得された（ステップＳ９２）閾値より大きいか否かを判定する。
【０１１８】
デコーダ制御部１５２は、閾値保持部１５１に保持された閾値が画質である場合、フレーム情報保持部１５０で保持された、フレーム情報のパケット数５２と画質５３の関係からパケット数の閾値を決定し、閾値より大きいか否かを判定する。
【０１１９】
このように、フレーム情報をサーバ１２からクライアント１３に送信することにより、フレーム情報が画像に応じて変更される場合であっても、ユーザが画質の閾値を決定しておくだけで、自動的にパケット数の閾値が決定され、画質の良い画像を表示させることができる。
【０１２０】
図２２に戻り、ステップＳ９７の処理において、受信データ量１８２が閾値より大きいと判定された場合、デコーダ制御部１５２はステップＳ９８に進み、デコーダ１４３にデコードを許可し、ステップＳ９９に進む。したがって、デコーダ１４３は、図１３のステップＳ４４の処理により、取得した画像データをデコードし、表示部１４６に表示することができる。
【０１２１】
一方、ステップＳ９７において、デコーダ制御部１５２は、受信データ量１８２が閾値以下であると判定された場合、ステップＳ９８をスキップし、ステップＳ９９に進む。したがって、デコーダ１４３は、デコードを許可されない。
【０１２２】
ステップＳ９９において、デコーダ制御部１５２は、デコード対象のタイムスタンプを次のフレームのタイムスタンプ（いまの場合、「２０００」）に更新する。
【０１２３】
上述の処理は、全ての画像がデコードされるまで、フレーム毎に繰り返される。
【０１２４】
例えば、図２１に示されるようなエントリ情報がエントリ情報蓄積部１４９に保持されており、閾値保持部１５１に保持された閾値が「３０」であった場合、タイムスタンプが「１０００」と「２０００」のフレームは、受信データ量１８２がそれぞれ「９０」と「４０」であり、閾値「３０」より大きいので、デコードが許可される。しかしながら、タイムスタンプ「３０００」のフレームは、受信データ量１８２が「１０」であり、閾値「３０」以下であるので、デコードは許可されない。そして、タイムスタンプが「４０００」のフレームは、受信データ量１８２が「９０」であり、閾値「３０」より大きいので、デコードが許可される。即ち、デコードされる画像データは、タイムスタンプが「１０００」、「２０００」、「４０００」のデータである。
【０１２５】
したがって、タイムスタンプ「３０００」の画像データを表示部１４６に表示させようとするとき、図１３のステップＳ４９の処理により、タイムスタンプ「２０００」の画像データの画像（前のフレームの画像）が表示される。
【０１２６】
このように、受信データ量に基づいて、デコーダが制御されるので、受信データ量の少ない（画質の悪い）画像のデコードを禁止し、画質の良い画像のみを表示することができる。
【０１２７】
なお、画質の単位は、「bpp」を用いたが「PSNR(per-square-noise-ratio)等、画質を表す単位であればよい。
【０１２８】
上述した一連の処理は、ハードウエアにより実行させることもできるし、ソフトウエアにより実行させることもできる。この場合、上述した処理は、図２３に示されるようなパーソナルコンピュータ６００により実行される。
【０１２９】
図２３において、CPU（Central Processing Unit）６０１は、ROM(Read Only Memory)６０２に記憶されているプログラム、または、記憶部６０８からRAM(Random Access Memory)６０３にロードされたプログラムに従って各種の処理を実行する。RAM６０３にはまた、CPU６０１が各種の処理を実行する上において必要なデータなどが適宜記憶される。
【０１３０】
CPU６０１、ROM６０２、およびRAM６０３は、内部バス６０４を介して相互に接続されている。この内部バス６０４にはまた、入出力インターフェース６０５も接続されている。
【０１３１】
入出力インターフェース６０５には、キーボード、マウスなどよりなる入力部６０６、CRT，LCD（Liquid Crystal Display）などよりなるディスプレイ、並びにスピーカなどよりなる出力部６０７、ハードディスクなどより構成される記憶部６０８、モデム、ターミナルアダプタなどより構成される通信部６０９が接続されている。通信部６０９は、電話回線やCATVを含む各種のネットワークを介しての通信処理を行なう。
【０１３２】
入出力インターフェース６０５にはまた、必要に応じてドライブ６１０が接続され、磁気ディスク、光ディスク、光磁気ディスク、あるいは半導体メモリなどによりなるリムーバブルメディア６２１が適宜装着され、それから読み出されたコンピュータプログラムが、必要に応じて記憶部６０８にインストールされる。
【０１３３】
一連の処理をソフトウエアにより実行させる場合には、そのソフトウエアを構成するプログラムが、専用のハードウエアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば、汎用のパーソナルコンピュータなどに、ネットワークや記録媒体からインストールされる。
【０１３４】
この記録媒体は、図２３に示されるように、コンピュータとは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されているリムーバブルメディア６２１よりなるパッケージメディアにより構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに提供される、プログラムが記録されているROM６０２や記憶部６０８が含まれるハードディスクなどで構成される。
【０１３５】
なお、本明細書において、コンピュータプログラムを記述するステップは、記載された順序に従って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０１３６】
また、本明細書において、システムとは、複数の装置により構成される装置全体を表わすものである。
【０１３９】
以上の如く、本願発明によれば、良質なコンテンツを表示させることができる。特に、送信時にコンテンツが欠落した場合においても、良質な画像のみを選択し、表示させることができる。
【図面の簡単な説明】
【図１】本発明を適用した情報処理システムの構成例を示すブロック図である。
【図２】図１のサーバの構成例を示すブロック図である。
【図３】図２のサーバにおける画像データ送信処理を説明するフローチャートである。
【図４】図２のサーバにおける画像データ送信処理を説明するフローチャートである。
【図５】フレーム情報保持部に保持されるフレーム情報の例を示す図である。
【図６】図１のサーバとクライアントが互いに送信するメッセージの例を示す図である。
【図７】図２のエンコーダがエンコードしたデータの例を示す図である。
【図８】図２の通信部が送信するRTPパケットのフォーマットの例を示す図である。
【図９】図２の通信部が送信したデータの例を示す図である。
【図１０】図１のクライアントの構成例を示すブロック図である。
【図１１】図１０のクライアントにおける画像表示処理を説明するフローチャートである。
【図１２】図１０のクライアントにおける画像表示処理を説明するフローチャートである。
【図１３】図１０のクライアントにおける画像表示処理を説明するフローチャートである。
【図１４】図１０の受信制御部における画像データ受信処理を説明するフローチャートである。
【図１５】図１０の受信制御部における画像データ受信処理を説明するフローチャートである。
【図１６】図１０の通信部が受信するデータの例を示す図である。
【図１７】図１５のステップＳ６８の処理でエントリ情報蓄積部にエントリされたエントリ情報の例を示す図である。
【図１８】図１５のステップＳ６８の処理でエントリ情報蓄積部にエントリされたエントリ情報の例を示す図である。
【図１９】図１５のステップＳ７０の処理でインクリメントされたエントリ情報蓄積部のエントリ情報の例を示す図である。
【図２０】図１５のステップＳ７３の処理で設定されたエントリ情報蓄積部のエントリ情報の例を示す図である。
【図２１】図１０のエントリ情報蓄積部のエントリ情報の例を示す図である。
【図２２】図１０のデコーダ制御部におけるデコード判断処理を説明するフローチャートである。
【図２３】パーソナルコンピュータの構成例を示すブロック図である。
【符号の説明】
１１ ビデオカメラ， １２ サーバ， １３ クライアント， １４ ネットワーク， ３１ 制御部， ３２ フレーム情報保持部， ３３ エンコーダ， ３４ バッファ， ３５ RTPパケット生成部， ３６ 通信部， １４１通信部， １４２ バッファ， １４３ デコーダ， １４４ フレームメモリ， １４５ 表示制御部， １４６ 表示部， １４７ 受信制御部， １４８ 画像情報保持部， １４９ エントリ情報蓄積部， １５０ フレーム情報保持部， １５１ 閾値保持部， １５２ デコーダ制御部
【発明の属する技術分野】
本発明は、受信装置および受信方法、記録媒体、並びにプログラムに関し、特に、受信した画像データが欠落している場合であっても、良質な画像を表示することができるようにした送受信システム、送信装置および送信方法、受信装置および受信方法、記録媒体、並びにプログラムに関する。
【０００２】
【従来の技術】
近年、インターネット等を用いて動画データを転送する際に発生する転送エラーについて、さまざまな処理が提案されている。
【０００３】
MPEG４（Moving Picture Experts Group ４）では、再同期マーカとRVLC（Reversible Variable Length Code）等を用いて、転送エラーが起きた箇所を廃棄し、エラー耐性の向上が図られている。
【０００４】
また、発生したエラーを目立たないように遮蔽するエラーコンシールメントの技術としては、動画の時間方向の相関性を利用し、1つ前のフレームを再生するか、または過去の画面の同一位置からの情報と置き換える処理が提案されている。
【０００５】
しかしながら、RVLCを用いてエラー耐性を向上した場合、符号化効率が低下することが指摘されている。また、上述したエラーコンシールメントは、処理が煩雑であり、シーンチェンジ等の急峻な画像の変化には対応することが困難であるという課題があった。
【０００６】
そこで、階層符号化された画像データを転送する場合において、送信されたフレームの一部が欠落し、受信側に送信されない場合には、欠落する時までに受信側で受信され、記憶されたデータをもとに欠落した周波数成分を生成し、より上位の階層の周波成分を再構成するエラーコンシールメント技術が提案されている（例えば、特許文献１参照）。
【０００７】
【特許文献１】
特開平１０−２４３４００号公報（第７ページ）
【０００８】
【発明が解決しようとする課題】
しかしながら、画像情報に多く含まれる低域情報が欠落した場合、画質が劣化するという課題があった。
【０００９】
本発明はこのような状況に鑑みてなされたものであり、受信した画像データに欠陥がある場合であっても、良質な画像を表示することができるようにするものである。
【００１８】
【課題を解決するための手段】
本発明の受信装置は、送信装置から送信されてくるパケットを受信する受信手段と、受信手段により受信されたパケットを保持する保持手段と、画像のフレームが受信されるとき、パケットロスが検出されるまで、受信されたパケットを保持手段に書き込み、パケットロスが検出されてから1フレームの最後のパケットまで、受信されたパケットを保持手段に書き込まない書き込み手段と、保持手段に書き込まれた１フレームの画像に対応するパケットの数が閾値より大きい場合、そのパケットに配置された符号化データのデコードを行い、保持手段に書き込まれた１フレームの画像に対応するパケットの数が閾値以下である場合、そのパケットに配置された符号化データのデコードを行わないデコード手段と、デコード手段により表示対象のフレームの画像に対応する符号化データがデコードされない場合、そのフレームより１フレーム前のフレームがデコードされた画像を表示させる表示制御手段とを備えることを特徴とする。
受信手段は、送信装置から送信されてくる、レイヤ毎の符号化データのパケット数と、符号化データをデコードすることにより得られる画像の画質に関する情報を含むフレーム情報をさらに受信し、デコード手段は、フレーム情報に基づいて決定される閾値に基づいて、デコードを行うことができる。
【００２２】
本発明の受信方法は、送信装置から送信されてくるパケットを受信する受信ステップと、画像のフレームが受信されるとき、パケットロスが検出されるまで、受信されたパケットを保持手段に書き込み、パケットロスが検出されてから1フレームの最後のパケットまで、受信されたパケットを保持手段に書き込まない書き込みステップと、保持手段に書き込まれた１フレームの画像に対応するパケットの数が閾値より大きい場合、そのパケットに配置された符号化データのデコードを行い、保持手段に書き込まれた１フレームの画像に対応するパケットの数が閾値以下である場合、そのパケットに配置された符号化データのデコードを行わないデコードステップと、デコードステップの処理により表示対象のフレームの画像に対応する符号化データがデコードされない場合、そのフレームより１フレーム前のフレームがデコードされた画像を表示させる表示制御ステップとを含むことを特徴とする。
【００２３】
本発明の記録媒体に記録されているプログラムは、送信装置から送信されてくるパケットを受信する受信ステップと、画像のフレームが受信されるとき、パケットロスが検出されるまで、受信されたパケットを保持手段に書き込み、パケットロスが検出されてから1フレームの最後のパケットまで、受信されたパケットを保持手段に書き込まない書き込みステップと、保持手段に書き込まれた１フレームの画像に対応するパケットの数が閾値より大きい場合、そのパケットに配置された符号化データのデコードを行い、保持手段に書き込まれた１フレームの画像に対応するパケットの数が閾値以下である場合、そのパケットに配置された符号化データのデコードを行わないデコードステップと、デコードステップの処理により表示対象のフレームの画像に対応する符号化データがデコードされない場合、そのフレームより１フレーム前のフレームがデコードされた画像を表示させる表示制御ステップとを含むことを特徴とする。
【００２４】
本発明のプログラムは、送信装置から送信されてくるパケットを受信する受信ステップと、画像のフレームが受信されるとき、パケットロスが検出されるまで、受信されたパケットを保持手段に書き込み、パケットロスが検出されてから1フレームの最後のパケットまで、受信されたパケットを保持手段に書き込まない書き込みステップと、保持手段に書き込まれた１フレームの画像に対応するパケットの数が閾値より大きい場合、そのパケットに配置された符号化データのデコードを行い、保持手段に書き込まれた１フレームの画像に対応するパケットの数が閾値以下である場合、そのパケットに配置された符号化データのデコードを行わないデコードステップと、デコードステップの処理により表示対象のフレームの画像に対応する符号化データがデコードされない場合、そのフレームより１フレーム前のフレームがデコードされた画像を表示させる表示制御ステップとを含むことを特徴とする。
【００２７】
本願発明においては、低域情報から高域情報の順で送信装置から送信されてくるパケットが低域情報から高域情報の順で受信され、画像のフレームが受信されるとき、パケットロスが検出されるまで、受信されたパケットが保持手段に書き込まれ、パケットロスが検出されてから1フレームの最後のパケットまで、受信されたパケットが保持手段に書き込まれない。また、保持手段に書き込まれた１フレームの画像に対応するパケットの数が閾値より大きい場合、そのパケットに配置された符号化データのデコードが行われ、保持手段に書き込まれた１フレームの画像に対応するパケットの数が閾値以下である場合、そのパケットに配置された符号化データのデコードが行われない。そして、表示対象のフレームの画像に対応する符号化データがデコードされない場合、そのフレームより１フレーム前のフレームがデコードされた画像が表示される。
【００２８】
【発明の実施の形態】
図１は、本発明を適用した情報処理システム１の構成例を表わしている。
【００２９】
この情報処理システム１において、サーバ１２は、ビデオカメラ１１を介して入力された画像データを、パケット通信網等のネットワーク１４を介して、クライアント１３に送信する。
【００３０】
サーバ１２は、ビデオカメラ１１が撮影した画像のデータが入力されると、その画像データをエンコードして、RTP（Real-time Transport Protocol）パケット（後述する図８）を生成する。サーバ１２は、生成されたRTPパケット（画像データ）を、ネットワーク１４を介して、クライアント１３に送信する。また、サーバ１２は、ユーザによって入力されたフレーム情報（後述する図５）をクライアント１３に送信する。
【００３１】
クライアント１３は、画像データを受信し、1フレーム内にパケットロスがある場合、パケットロスが生じるまでの画像データを保持する。クライアント１３は、受信したフレーム情報に基づいて、保持した画像データの画質またはデータ量が、ユーザによって設定された閾値以上であるか否かを判断し、閾値以上である場合、画像データをデコードし、ディスプレイ等の表示部に、デコードされた画像データを表示させる。閾値以上ではない場合、前のフレームの画像を表示させる。
【００３２】
図２は、サーバ１２の構成を示す図である。なお、図中、“Ｓ”の文字と数字からなる記号で示されている矢印は、後述する図３と図４のフローチャートの処理のステップに対応している。
【００３３】
制御部３１には、例えばユーザが入力するフレーム情報が供給される。制御部３１は、ユーザにより入力された画像データのフレーム情報を、フレーム情報保持部３２に供給する。フレーム情報保持部３２は、制御部３１から供給されるフレーム情報を保持する。ここで、フレーム情報は、1フレームのレイヤ毎のパケット数と画質から構成されているが、詳細は、図５で後述する。
【００３４】
エンコーダ３３は、ビデオカメラ１１が撮影した画像のデータが入力されると、JPEG（Joint Photographic Experts Group）2000等の階層符号化によって、画像データをエンコードする。なお、エンコーダ３３は、画像データの各フレームをどのような階層（レイヤ）に階層符号化するかを、フレーム情報保持部３２に記憶されたフレーム情報に基づいて決定する。
【００３５】
エンコーダ３３は、エンコードした画像データを、バッファ３４に供給して保持させる。RTPパケット生成部３５は、バッファ３４に記憶（保持）された画像データを取得し、フレーム情報保持部３２に保持されたフレーム情報におけるレイヤ毎のパケット数に基づいて、画像データをRTPパケット化する。
【００３６】
そして、RTPパケット生成部３５は、画像データをRTPパケット化することにより得られるパケットを、通信部３６に供給する。通信部３６は、RTPパケット生成部３５から供給された画像データのパケットを、ネットワーク１４を介して、クライアント１３に供給する。さらに、通信部３６は、フレーム情報保持部３２から、フレーム情報を取得し、ネットワーク１４を介して、クライアント１３にフレーム情報を送信する。
【００３７】
次に、図３と図４を参照して、図２のサーバ１２における画像データ送信処理を説明する。なお、この処理は、ビデオカメラ１１から、サーバ１２に画像データが入力されたとき、またはユーザにより、サーバ１２に画像データの送信処理が指令されたとき、開始される。
【００３８】
ステップＳ１において、制御部３１は、ユーザにより入力された各レイヤのパケット数と画質（以下、適宜、フレーム情報と称する）を、フレーム情報保持部３２に保持する。なお、フレーム情報は、例えば、ユーザが図示せぬ操作部等を操作して予め入力するものとする。
【００３９】
ここで、図５は、フレーム情報保持部３２に保持されるフレーム情報を示している。フレーム情報５０は、レイヤ（を表す情報）５１、パケット数（を表す情報）５２、画質（を表す情報）５３から構成されている。図５では、１フレームは、レイヤ「Ｌ０」、レイヤ「Ｌ１」、レイヤ「Ｌ２」の３つのレイヤから構成されるものとしてある。また、図５では、レイヤ「Ｌ０」のパケット数５２は「２０」とされており、従って、レイヤ「Ｌ０」は、「２０」個のパケットから構成される。また、レイヤ「Ｌ０」の画質は「０．５bpp（bit-per-pixel）」とされている。
【００４０】
同様に、図５では、レイヤ「Ｌ１」は、「２５」個のパケットから構成され、画質５３は「０．７ｂｐｐ」とされている。レイヤ「Ｌ２」は、「４５」個のパケットから構成され、画質５３は、「１．０ｂｐｐ」とされている。以上から、図５のフレーム情報によれば、１フレームは、「２０＋２５＋４５＝９０」個のパケットから構成される。
【００４１】
図３に戻り、ステップＳ１の処理後は、ステップＳ２に進み、RTPパケット生成部３５は、フレーム毎に付加されるタイムスタンプを初期化して、ステップＳ３に進む。即ち、RTPパケット生成部３５は、最初のフレームに付加するタイムスタンプの値を設定する。
【００４２】
ステップＳ３において、通信部３６は、フレーム情報保持部３２からフレーム情報を取得し、ステップＳ４に進む。ステップＳ４において、通信部３６は、フレーム情報保持部３２から取得したフレーム情報を、RTSP（Real-time Streaming Protocol）等のストリーミングのセッション管理プロトコルを用い、ネットワーク１４を介して、クライアント１３に送信する。なお、RTSPは、RFC（Request For Comment）2326で定義されている。
【００４３】
ここで、図６は、RTSPを用いて、サーバ１２がクライアント１３にフレーム情報を送信する場合に、サーバ１２からクライアント１３に送信させるメッセージと、そのメッセージを受信したクライアント１３がサーバ１２に送信する了承のメッセージの例を示している。
【００４４】
「S→C」は、サーバ１２からクライアント１３に送信するメッセージであることを表し、「C→S」は、クライアント１３からサーバ１２に送信するメッセージであることを表している。なお、「OPTIONS」はメソッドを表し、「OPTIONS＊RTSP/1.0」は拡張メソッドであることを示している。また、「CSeq」は、RTSPのメッセージ番号を示しており、「Packet-1layer-bpp」は、ヘッダである。ヘッダには、レイヤ名、積算パケット数（レイヤ名のレイヤまでのパケット数）、レイヤの画質の３つの情報のセットが１セットまたは繰り返し記述される。
【００４５】
図６の例の場合、サーバ１２からクライアント１３に送信されるメッセージは、RTSP番号が「１」の拡張メソッドのメッセージである。ヘッダには、図５に示した情報が記述されている。即ち、図５では、レイヤＬ０は、積算パケット数（レイヤＬ０のパケット数）が「２０」であり、画質が「０．５ｂｐｐ」である。レイヤＬ１は、積算パケット数（レイヤＬ０とレイヤＬ１のパケット数の和）が「４５」（レイヤＬ１のパケット数は「２５」）であり、画質が「０．７ｂｐｐ」である。レイヤＬ２は、積算パケット数（レイヤＬ０、レイヤＬ１、レイヤＬ２のパケット数の和）が「９０」（レイヤＬ２のパケット数は「４５」）であり、画質が「１．０ｂｐｐ」である。このため、サーバ１２からクライアント１３に送信するメッセージのヘッダには、図６に示したように、Ｌ０ ２０ ０．５ Ｌ１ ４５ ０．７ Ｌ２ ９０ １．０が記述される。
【００４６】
また、クライアント１３からサーバ１２に送信される図６に示したメッセージは、RTSP番号が「１」の拡張メソッドのメッセージ（サーバ１２からクライアント１３に送信されたメッセージ）を受信したことを通知するメッセージである。
【００４７】
図３に戻り、ステップＳ４において、サーバ１２からクライアント１３にフレーム情報（が記述されたメッセージ）が送信された後は、ステップＳ５に進み、エンコーダ３３は、予め設定されたフレームレート（例えば、３０フレーム／秒）に基づいて、エンコーダ３３に設けられた不図示のタイマに、１フレーム分の時間（いまの場合、３３ｍｓ）を設定し、ステップＳ６に進む。ステップＳ６において、エンコーダ３３は、ビデオカメラ１１を介して撮影された画像のデータを取得し、ステップＳ７に進む。ステップＳ７において、エンコーダ３３は、タイマに設定された所定時間（いまの場合、３３ｍｓ）が経過した（タイマが終了した）か否かを判定し、所定時間が経過したと判定するまで、画像データを取得する処理を行なう。
【００４８】
ステップＳ７において、エンコーダ３３は、所定時間が経過したと判定した場合、ステップＳ８に進み、画像データの取得を終了し、取得した画像データをエンコードする。即ち、エンコーダ３３は、１フレーム分の画像データを、フレーム情報保持部３２に記憶されたフレーム情報に基づいて階層符号化することによりエンコードし、そのエンコード結果として符号化データを取得する。そして、図４のステップＳ９に進み、エンコーダ３３は、１フレーム分の画像データをエンコードすることにより得られた符号化データをバッファ３４に供給して保持させる。
【００４９】
ここで、図７は、バッファ３４に保持された１フレーム分の符号化データを示している。符号化データは、SOC（Start Of Code stream）７１、Code stream７２、およびEOC（End Of Code stream）から構成されている。SOC７１は、符号化データの開始を示すデータであり、EOC７３は、符号化データの終了を示すデータである。また、Code Stream７２は、エンコードされた画像データである。
【００５０】
ここで、エンコーダ３３で行われる階層符号化である、例えば、JPEG2000は、解像度や圧縮率などが異なる複数種類のプログレッシブ表示に対応している。またJPEG2000は、画質スケーラブル（SNR(Signal to Noise Ratio)）に対応している。本実施の形態では、エンコーダ３３は、画像データを、例えば、JPEG2000方式で、図５に示したフレーム情報にしたがい、画質スケーラブルに階層符号化し、各階層（レイヤ）のデータをCode Stream７２に配置する。
【００５１】
その結果、図７では、Code Stream７２は、図５に示したフレーム情報にしたがって、レイヤＬ０データ９１、レイヤＬ１データ９２、およびレイヤＬ２データ９３に階層化されている。レイヤＬ０データ９１は、画像データの低域情報となっており、レイヤＬ１データ９２は、中域情報となっている。そして、レイヤＬ２データ９３は、画像データの高域情報となっている。
【００５２】
従って、レイヤＬ０データ９１をデコードすると、画質の低い元の画像（図５の例の場合、０．５ｂｐｐの画質の画像）と同じ空間解像度の画像が得られる。また、レイヤＬ１データ９２まで（レイヤＬ０データとレイヤＬ１データ）をデコードすると、レイヤＬ０データ９１だけをデコードした場合よりも画質の良い画像（図５の例の場合、０．７５ｂｐｐの画質の画像）が得られる。さらに、レイヤＬ２データ９３まで（レイヤＬ０データ９１、レイヤＬ１データ９２、レイヤＬ３データ９３）をデコードすると、さらに良い画質の画像（図５の例の場合、１．０の画質の画像）を得ることができる。
【００５３】
なお、エンコーダ３３は、符号化データをデコードしたときに、フレーム情報における画質の画像を得ることができるように階層符号化を行い、レイヤＬ０データ、レイヤＬ１データ９２、レイヤＬ３データ９３を得る。
【００５４】
図４に戻り、ステップＳ９の処理後は、ステップＳ１０に進み、RTPパケット生成部３５は、フレーム情報保持部３２から、フレーム情報５０（図５）を取得し、ステップＳ１１に進む。ステップＳ１１において、RTPパケット生成部３５は、バッファ３４に保持されている１フレーム分の符号化データから、ステップＳ１０で取得したフレーム情報５０における各レイヤ毎のパケット数のパケットが得られるサイズのデータを取得し、RTPパケットを生成する。
【００５５】
即ち、RTPパケット生成部３５は、図５に示したフレーム情報５０を取得した場合、レイヤＬ０データ９１から２０個のRTPパケットを、レイヤＬ１データ９２から２５個のRTPパケットを、レイヤＬ２データ９３から４５個のRTPパケットを生成する。
【００５６】
ステップＳ１１でRTPパケットを生成した後は、ステップＳ１２に進み、RTPパケット生成部３５は、生成したRTPパケットを、レイヤＬ０からレイヤＬ２の順で通信部３６に供給し、ステップＳ１３に進む。ステップＳ１３において、通信部３６は、RTPパケットを、ネットワーク１４を介してクライアント１３に送信する。
【００５７】
ここで、図８は、通信部３６がクライアント１３に送信するRTPパケットのRTPフォーマットの例を示している。RTPヘッダは、バージョン番号を示すｖ１１１、パディングを示すｐ１１２、拡張ヘッダの有無を示すｘ１１３、送信元数（Counter）を示すｃｃ１１４、マーカ情報（marker bit）を示すｍ１１５、ペイロードタイプを示すｐｔ１１６、シーケンス番号を示すsequence１１７、タイムスタンプを示すtimestamp１１８、同期ソース（送信元）識別子を示すSSRC１１９から構成される。RTPヘッダの後には、符号化データがData１２０として配置される。
【００５８】
クライアント１３は、timestamp１１８に記述されたタイムスタンプにより、RTPパケットを展開するときの処理時間を制御し、リアルタイム画像、または音声の再生制御を行う。なお、タイムスタンプは、１フレーム毎に決定され、同一のフレームの符号化データを配置させる複数のRTPパケットには、共通のタイムスタンプが設定される。
【００５９】
図９は、通信部３６が、図５に示したフレーム情報５０に基づいて生成されたRTPパケットを、ネットワーク１４を介して、クライアント１３に、送信する例を示す図である。なお、横軸ｔは時間を表している。
【００６０】
まず、通信部３６は、レイヤＬ０の符号化データ（図７のレイヤＬ０データ９１）（画像データの低域情報）のパケットを２０個（シーケンス番号１乃至２０のパケット）送信する。次に、レイヤＬ１の符号化データ（図７のレイヤＬ１データ９２）（画像データの中域情報）のパケットを４５個（シーケンス番号２１乃至４５のパケット）送信する。最後に、通信部３６は、レイヤＬ３の画像データ（図７のレイヤＬ３データ９３）（画像データの高域情報）のパケットを４５個（シーケンス番号４６乃至９０のパケット）送信し、1フレームの符号化データの送信が終了する。なお、シーケンス番号は、エンコードされた最初の画像データ（図７のSOC７１の次のデータ）から生成されたパケットから順に付され、図８に示したRTPパケットのsequence１１７に配置される。
【００６１】
図４に戻り、ステップＳ１３において、RTPパケットを送信した後は、ステップＳ１４に進み、RTPパケット生成部は、RTPパケットのtimestamp１１８（図８）に記述するタイムスタンプを更新し、ステップＳ１５に進む。
【００６２】
ここで、図８のsequence１１７に配置されるシーケンス番号は、RTPパケットにシーケンシャルに付される。従って、このシーケンス番号によって、クライアント１３は、受信したRTPパケットが、送信されたRTPパケットに対して足りない（欠落している）かどうかを検出することができる。
【００６３】
ステップＳ１５において、サーバ１２は、全ての画像データを、クライアント１３に送信したか否かを判定する。サーバ１２は、全ての画像データをクライアント１３に送信していないと判定した場合、処理をステップＳ１５からＳ５に戻し、ビデオカメラ１１を介して撮影された画像データを、フレーム毎に取得し、RTPパケットを送信する処理を繰り返す。ステップＳ１５において、サーバ１２は、全ての画像データをクライアント１３に送信したと判定した場合、処理を終了する。
【００６４】
次に、図１０は、図１のクライアント１３の構成例を示している。なお、図中、“Ｓ”の文字と数字からなる記号で示されている矢印は、後述する図１１乃至図１３のフローチャートの処理のステップに対応している。
【００６５】
通信部１４１は、サーバ１２から送信されているフレーム情報とRTPパケットを受信する。受信制御部１４７は、通信部１４１が受信したフレーム情報とRTPパケットに基づいて受信処理を行ない、通信部１４１により受信されたRTPパケット（画像データ）のバッファ１４２への書き込みを制御する。この受信処理の詳細は、図１４乃至図２１を参照して後述する。
【００６６】
また、受信制御部１４７は、フレーム情報を、通信部１４１から取得し、画像情報保持部１４８のフレーム情報保持部１５０に供給して保持させる。さらに、受信制御部１４７は、通信部１４１が受信したRTPパケットのタイムスタンプ毎（１フレーム毎）に、画像情報保持部１４８のエントリ情報蓄積部１４９にエントリし、RTPパケットの形で受信した画像データの情報（以下、適宜、エントリ情報と称する）を保持する。
【００６７】
通信部１４１は、受信制御部１４７の制御にしたがい、受信したRTPパケットをバッファ１４２に書き込み、これによりバッファ１４２は、通信部１４１から供給されるRTPパケットを一時保持する。デコーダ１４３は、バッファ１４２に保持されたRTPパケットを取得する。
【００６８】
閾値保持部１５１は、例えば、ユーザにより入力された、タイムスタンプ毎のデータ量（RTPパケット数）または画質の閾値を保持する。
【００６９】
デコーダ制御部１５２は、閾値保持部１５１で保持された閾値と、エントリ情報蓄積部１４９で保持されたエントリ情報（後述する図２１）に基づいて、デコーダ１４３で取得されRTPパケットの、デコードを許可するか否かを判断する。
【００７０】
デコーダ１４３は、デコーダ制御部１５２によりデコードが許可されると、バッファ１４２から取得したRTPパケットに配置された符号化データをデコードし、そのデコードの結果得られる画像データをフレームメモリ１４４に記億する。表示制御部１４５は、フレームメモリ１４４に記憶された画像データを取得し、ディスプレイ等の表示部１４６に画像を表示させる。
【００７１】
図１０のクライアント１３の画像表示処理を、図１１乃至図１３を用いて詳細に説明する。なお、この処理は、サーバ１１から画像データが送信されたとき、開始される。
【００７２】
ステップＳ３１において、クライアント１３は、自身を初期化し、ステップＳ３２に進む。これにより、バッファ１４２、フレームメモリ１４４、画像情報保持部１４８、および閾値保持部１５１に保持されているデータは消去される。ステップＳ３２において、閾値保持部１５１は、ユーザにより入力されたデータ量（RTPパケット数）または画質の閾値を保持し、ステップＳ３３に進む。なお、閾値は、例えば、ユーザが図示せぬ操作部等を操作して予め入力するものとする。
【００７３】
ステップＳ３３において、通信部１４１は、図３のステップＳ４の処理でサーバ１２から送信されたフレーム情報（図６）、または図４のステップＳ１３の処理でクライアント１３から送信されたRTPパケット（図９）を、ネットワーク１４を介して受信し、ステップＳ３４に進む。
【００７４】
ステップＳ３４において、受信制御部１４７は、通信部１４１で受信されたフレーム情報を通信部１４１から取得し、フレーム情報保持部１５０に供給して保持させる。これにより、画像情報保持部１４８のフレーム情報保持部１５０は、図２のフレーム情報保持部３２に保持されたフレーム情報と同じフレーム情報を保持する。従って、図６に示したフレーム情報が通信部１４１で受信された場合、図５に示したフレーム情報が、フレーム情報保持部１５０に保持される。
【００７５】
ステップＳ３４の処理後は、ステップＳ３５に進み、受信制御部１４７は、受信処理を行ない、これにより通信部１４１により受信されたRTPパケットの書き込み許可または不許可を決定するとともに、後述するエントリ情報を、エントリ情報蓄積部１４９に記憶させる。なお、受信処理の詳細は、図１４と図１５のフローチャートを用いて後述する。
【００７６】
ステップＳ３５の処理後は、ステップＳ３６に進み、通信部１４１は、ステップＳ３５の受信処理で、受信制御部１４７からRTPパケットの書き込みが許可されたか否かを判定する。通信部１４１は、受信制御部１４７から書き込みが許可された場合、ステップＳ３６からＳ３７に進み、ステップＳ３３の処理で受信したRTPパケットを、バッファ１４２に供給して書き込み、これによりバッファ１４２は、通信部１４１が受信したRTPパケットを保持する。
【００７７】
そして、ステップＳ３８に進み、デコーダ１４３は、バッファ１４２に１フレーム分のRTPパケットが保持されたか否かを判定する。即ち、デコーダ１４３は、１フレーム分の受信処理の時間を予め内蔵するタイマ（図示せず）に設定しておき、タイマによって、その設定した時間が計時されたか否かを判定する。デコーダ１４３は、１フレーム分のRTPパケットが保持されるまで、ステップＳ３８の処理を繰り返し、１フレーム分のRTPパケットが保持された場合、処理をステップＳ３８から図１２のＳ３９に進める。
【００７８】
ステップＳ３９において、デコーダ１４３は、ステップＳ３７の処理でバッファ１４２に保持された１フレーム分のRTPパケットを、バッファ１４２から取得し、ステップＳ４０に進む。ステップＳ４０において、デコーダ制御部１５２は、画像情報保持部１４８から、図１１のステップＳ３４，Ｓ３５の処理で保持された画像情報、即ちエントリ情報蓄積部１４９に保持されたエントリ情報とフレーム情報保持部１５０に保持されたフレーム情報を取得し、ステップＳ４１に進む。
【００７９】
ステップＳ４１において、デコーダ制御部１５２は、ステップＳ３２の処理で閾値保持部１５１に保持されたデコーダ量（RTPパケット数）または画質の閾値を取得し、ステップＳ４２に進む。ステップＳ４２において、デコーダ制御部１５２は、ステップＳ３９の処理で取得した画像情報と、ステップＳ４１の処理で取得した閾値に基づいて、デコード判断処理を行い、これにより、デコーダ１４３によるデコードの許可または不許可を決定する。このデコード判断処理は、図２２のフローチャートを用いて後述する。
【００８０】
ステップＳ４２の処理後は、図１３のステップＳ４３に進み、デコーダ１４３は、ステップＳ４２の処理により、デコーダ制御部１５２からデコードが許可されたか否かを判定する。デコーダ１４３は、デコーダ制御部１５２からデコードが許可された場合、処理をステップＳ４３からＳ４４に進め、ステップＳ３９の処理でバッファ１４２から取得したRTPパケットをデコードし、ステップＳ４５に進む。
【００８１】
ステップＳ４５において、デコーダ１４３は、デコードした画像データをフレームメモリ１４４に供給して記憶させ、ステップＳ４６に進む。ステップＳ４６において、表示制御部１４５は、ステップＳ４５でフレームメモリ１４４に記憶された画像データを取得し、ステップＳ４７に進む。ステップＳ４７において、表示制御部１４５は、ステップＳ４６で取得した画像データに基づいて、表示部１４６に画像を表示させ、処理を終了する。
【００８２】
一方、ステップＳ４３において、デコーダ制御部１５２からデコードが許可されていないと判定された場合、処理がステップＳ４８に進み、表示制御部１４５は、フレームメモリ１４４に前のフレーム（いま表示すべきフレームの、例えば、１フレーム前のフレームなど）の画像データが存在するか否かを判定する。ステップＳ４８において、フレームメモリ１４４に前のフレームの画像データが存在する（前のフレームの画像データを受信したとき、ステップＳ４５の処理が行なわれた）と判定された場合、ステップＳ４９に進み、表示制御部１４５は、前のフレームの画像（フレームメモリ１４４に記憶されている画像）を、表示部１４６に表示させ、処理を終了する。
【００８３】
また、ステップＳ４８において、フレームメモリ１４４に前のフレームの画像データが存在しないと判定された場合、ステップＳ４９をスキップして処理を終了する。従って、この場合、表示部１４６には何も表示されない。
【００８４】
一方、図１２のステップＳ３６において、通信部１４１は、受信制御部１４７からRTPパケットの書き込みが許可されていないと判定した場合、RTPパケットをバッファに書きこまずに、処理を終了する。
【００８５】
なお、図１１および図１２の処理は、サーバ１２から、RTPパケットが送信されてこなくなるまで繰り返される。
【００８６】
次に、図１４のフローチャートを参照して、受信制御部１４７における受信処理について説明する。このフローチャートは、上述した図１１のステップＳ３４，Ｓ３５の処理を詳細に説明するものである。
【００８７】
ステップＳ６１において、受信制御部１４７は、通信部１４１が、図１１のステップＳ３３の処理により、フレーム情報を受信したか否かを判定する。ステップＳ６１において、フレーム情報を受信したと判定された場合、ステップＳ６２に進み、受信制御部１４７は、画像情報保持部１４８のフレーム情報保持部１５０に、通信部１４１が受信したフレーム情報を供給して保持させ、処理をステップＳ６１に戻す。
【００８８】
また、ステップＳ６１において、フレーム情報を受信していないと判定された場合、ステップＳ６３に進み、受信制御部１４７は、通信部１４１がRTPパケットを受信したか否かを判定する。ステップＳ６３において、画像データを受信していないと判定された場合、通信部１４１が受信したデータは、必要のないデータであるので、受信制御部１４７は、以降の処理を行なわず、処理をステップＳ６１に戻し、以下、同様の処理を繰り返す。
【００８９】
また、ステップＳ６３において、受信制御部１４７は、通信部１４１が画像データを受信したと判定した場合、ステップＳ６４に進み、通信部１４１が受信したRTPパケットのタイムスタンプを検出する。即ち、RTPパケットは、図８に示したフォーマットで送信されるので、受信制御部１４７は、ヘッダのtimestamp１１８に記述されたタイムスタンプの値を検出する。なお、このタイムスタンプは、図３のステップＳ２の処理で初期化され、図４のステップＳ１４で１フレーム毎に更新されるものである。
【００９０】
ここで、図１６は、通信部１４１で受信されるRTPパケットの例を、横軸を時間ｔとして示している。この例の場合、１フレームは９０個のRTPパケットから構成されている。通信部１４１は、タイムスタンプが「１０００」のフレームの画像データのRTPパケット群（シーケンス番号が１乃至９０のRTPパケット）を受信し、その後は、タイムスタンプが「２０００」のフレームの画像データのRTPパケット群（シーケンス番号が９１乃至１８０のRTPパケット）を受信する。そして、通信部１４１は、タイムスタンプが「３０００」のフレームの画像データのRTPパケット群（シーケンス番号が１８１乃至２７０のRTPパケット）を受信し、最後にタイムスタンプが「４０００」のフレームの画像データのRTPパケット群（シーケンス番号が２７１乃至３６０のRTPパケット）を受信する。なお、図１６では、シーケンス番号１３１とシーケンス番号１９１のRTPパケットは、ロス（欠落）している。
【００９１】
図１４に戻り、ステップＳ６４の処理後は、ステップＳ６５に進み、受信制御部１４７は、前回のステップＳ６４の処理で検出したタイムスタンプがあるか否かを判定する。ステップＳ６５において、前回検出したタイムスタンプがあると判定された場合、ステップＳ６６に進み、受信制御部１４７は、今回のステップＳ６４の処理で検出したタイムスタンプが、前回検出したタイムスタンプと一致するか否かを判定する。
【００９２】
ステップＳ６６において、今回検出したタイムスタンプが前回のタイムスタンプと一致しないと判定された場合、ステップＳ６７に進み、受信制御部１４７は、今回検出したタイムスタンプが、前回のタイムスタンプより大きいか否かを判定する。ステップＳ６７において、今回検出したタイムスタンプが、前回のタイムスタンプより大きくない（小さい）と判定された場合、受信された画像データは、既に受信され、処理された画像データなので、処理をステップＳ６１に戻す。
【００９３】
また、ステップＳ６７において、今回検出したタイムスタンプが、前回のタイムスタンプより大きいと判定された場合、またはステップＳ６５で前回のタイムスタンプがないと判定された場合、即ち、通信部１４１が受信したRTPパケットがフレームの最初のRTPパケットである場合、受信制御部１４７は、処理をステップＳ６８に進め、今回検出したタイムスタンプをエントリ情報蓄積部１４９にエントリする。
【００９４】
例えば、通信部１４１において、図１６に示したRTPパケットのシーケンスが受信される場合、シーケンス番号１のRTPパケットが受信されると、このRTPパケットは、フレーム内の最初のパケットであるので、図１７に示すように、タイムスタンプ「１０００」が配置されたエントリ情報がエントリ情報蓄積部１４９にエントリ（登録）される。なお、エントリ情報は、タイムスタンプ１８１、受信データ量１８２、フラグ１８３から構成され、フラグ１８３は、ロスが検出されたか否かを示している（ステップＳ７３の処理で後述する）。また、受信データ量１８２は、受信した１フレーム内のRTPパケットの数を示し、その１フレーム内の新たなRTPパケットを受信したとき、インクリメントされる（後述するステップＳ７０の処理）。
【００９５】
また、図１６において、シーケンス番号９１のRTPパケットが受信されると、そのRTPパケットのタイムスタンプは、前回のタイムスタンプ「１０００」（シーケンス番号９０のタイムスタンプ）より大きいので、新たなタイムスタンプ「２０００」がエントリ情報蓄積部１４９にエントリされ、図１８に示されるようなエントリ情報がエントリ情報蓄積部１４９に保持される。
【００９６】
図１８では、受信されたタイムスタンプ１８１が「１０００」の画像データが、シーケンス番号１乃至９０のRTPパケットから構成され、ロスはないので、受信データ量１８２が「９０」となっており、フラグ１８３は、ロスがないことを示す「０」となっている。そして、シーケンス番号９１のRTPパケットが新たに受信されたので、タイムスタンプ１８１に「２０００」がエントリされている。
【００９７】
図１５に戻り、ステップＳ６８の処理後は、ステップＳ６９に進み、受信制御部１４７は、通信部１４１が受信したRTPパケットのシーケンス番号（図８のフォーマットのsequence１１７に記述された番号）に基づいて、RTPパケットがロスしているか否かを判定する。即ち、ステップＳ６９では、通信部１４１が今回受信したRTPパケットのシーケンス番号が、前回受信したRTPパケットのシーケンス番号の次の番号である場合、RTPパケットがロスしていないと判定され、次の番号ではない場合、RTPパケットがロスしている（送信エラーにより、RTPパケットが欠落している）と判定される。ステップＳ６９において、RTPパケットがロスしていないと判定された場合は、ステップＳ７０に進み、ロスしていると判定された場合は、ステップＳ７３に進む。
【００９８】
一方、図１４のステップＳ６６において、今回検出したタイムスタンプが、前回のタイムスタンプと一致すると判定された場合、ステップＳ７２に進み、受信制御部１４７は、RTPパケットがロスしている（シーケンス番号が続き番号ではない）か否か、またはエントリ情報蓄積部１４９のフラグ１８２が「１」である（前回までにロスが検出された）か否かを判定する。
【００９９】
ステップＳ７２の処理において、ロスが検出されず、フラグ１８２が「１」ではない（「０」である）と判定された場合、図１５のステップＳ７０に進み、受信制御部１４７は、エントリ情報蓄積部１４９の受信データ量１８２を１だけインクリメントする。
【０１００】
例えば、シーケンス番号９１のRTPパケットが受信され、これにより、ステップＳ６８の処理で、エントリ情報蓄積部１４９に、図１８に示したエントリ情報が保持された場合、ロスがないので、エントリ情報蓄積部１４９には、図１９に示すエントリ情報が保持される。即ち、タイムスタンプ１８１が「２０００」の受信データ量１８２は、「０」から「１」にインクリメントされる。
【０１０１】
また、図１６のケースで、シーケンス番号１乃至９４までが正常に受信されている場合、エントリ情報蓄積部１４９のタイムスタンプ「２０００」の受信データ量１８２は、「４」となっている。その後、シーケンス番号９５が受信されると、受信データ量１８２は、インクリメントされ、「５」となる。
【０１０２】
図１５に戻り、ステップＳ７０の処理後は、ステップＳ７１に進み、受信制御部１４７は、通信部１４１にバッファ１４２へのRTPパケットの書き込みを許可し、処理を終了する。したがって、通信部１４１は、図１１のステップＳ３７の処理を行なって、受信した画像データ（RTPパケット）をバッファ１４２に書き込み、以降の処理を行なう。
【０１０３】
一方、図１４のステップＳ７２において、RTPパケットがロスしていると判定された場合、またはフラグ１８３が「１」であると判定された場合、受信制御部１４７は、処理をステップＳ７３に進め、エントリ情報蓄積部１４９のフラグを「１」に設定し、処理を終了する。このとき、受信制御部１４７は、通信部１４１にバッファ１４２へのRTPパケットの書き込みを許可しない。従って、この場合、通信部１４１は、RTPパケットをバッファ１４２に書き込まない。
【０１０４】
例えば、図１６に示した画像データのシーケンス番号１３２のRTPパケットが受信された場合、シーケンス番号１３１のRTPパケットがロスしているので、エントリ情報蓄積部１４９に保持されたエントリ情報は、図２０に示すように、フラグ１８３が「０」から「１」に変更される。なお、RTPパケットはバッファ１４２に書き込まれないので、受信データ量１８２は、変更されない。
【０１０５】
また、図１６に示した画像データのシーケンス番号１３３のRTPパケットが受信された場合も、フラグが「１」である（ロスしているRTPパケットがある）ので、エントリ情報蓄積部のフラグ１８３は「１」のままであり、RTPパケットはバッファ１４２に書き込まれないので、受信データ量１８２も「４０」のまま変更されない。
【０１０６】
上述の処理は、全ての画像データが受信されるまで、パケット毎に行われる。
【０１０７】
図１６に示されるような画像データが通信部１４１で受信された場合のエントリ情報蓄積部１４９のエントリ情報の例を図２１に示す。
【０１０８】
この例の場合、タイムスタンプが「１０００」のフレームは、９０個のパケットから構成され、ロスがないので、タイムスタンプ１８１が「１０００」の受信データ量１８２は、「９０」となり、フラグ１８３は、「０」となる。また、タイムスタンプが「２０００」のフレームは、シーケンス番号１３１のRTPパケットがロスしているので、シーケンス番号９１乃至１３０のRTPパケットのみが書き込みを許可され（ステップＳ７０，Ｓ７１の処理）、タイムスタンプ１８１が「２０００」の受信データ量は、「４０」となる。また、このとき、RTPパケットのロスが検出されるので、フラグ１８３は、「１」となる。
【０１０９】
同様に、タイムスタンプ「３０００」のフレームは、１９１のRTPパケットがロスしているので、シーケンス番号１８１乃至１９０のRTPパケットのみが書き込みを許可され、タイムスタンプ１８１が「３０００」の受信データ量は、「１０」となり、ロスが検出されたので、フラグ１８３は、「１」となる。タイムスタンプ「４０００」のフレームは、ロスがないので、全てのRTPパケットがバッファ１４２に書き込まれ、受信データ量１８２は、「９０」となり、フラグ１８３は、「０」となる。
【０１１０】
図１４と図１５の処理により、受信制御部１４７は、ロスするまでの画像データ（ロスのない画像データ）のみをバッファ１４２に書き込む。
【０１１１】
このように、シーケンス番号を検出することにより、ロスを検出することができる。また、ロスの検出の有無を示すフラグを判定することにより、ロスが検出されるまでの画像データのみを確実に保持することができる。
【０１１２】
次に、図２２のフローチャートを参照して、デコーダ制御部１５２におけるデコード判断処理について説明する。このフローチャートは、上述した図１２のステップＳ３９乃至Ｓ４２の処理を詳細に説明するものである。
【０１１３】
ステップＳ９１において、デコーダ制御部１５２は、デコーダ１４３のデコード対象のタイムスタンプを、初期値（いまの場合、「１０００」）に設定し、ステップＳ９２に進む。ステップＳ９２において、デコーダ制御部１５２は、閾値保持部１５１から、図１１のステップＳ３２の処理で保持されたデータ量（RTPパケット数）または画質の閾値を取得し、ステップＳ９３に進む。
【０１１４】
ステップＳ９３において、デコーダ制御部１５２は、画像情報保持部１４８から画像情報を取得する。即ち、エントリ情報蓄積部１４９からエントリ情報（図２１）を取得し、フレーム情報保持部１５０からフレーム情報（図５）を取得する。
【０１１５】
ステップＳ９３の処理の後は、ステップＳ９４に進み、デコーダ制御部１５２は、デコーダ１４３の不図示のタイマを所定時間（１フレーム分の画像データを取得するのに必要な時間）に設定し、開始させ、ステップＳ９５に進む。ステップＳ９５において、デコーダ制御部１５２は、デコーダ１４３を制御し、バッファ１４２から画像データを取得し、ステップＳ９６に進む。ステップＳ９６において、デコーダ制御部１５２は、タイマが終了したか否かを判定し、タイマが終了するまでステップＳ９５の処理を繰り返す。
【０１１６】
ステップＳ９６の処理において、タイマが終了した（１フレーム分のRTPパケットが取得された）場合、デコーダ制御部１５２は、処理をステップＳ９６からＳ９７に進める。
【０１１７】
ステップＳ９７において、エントリ情報蓄積部１４９から取得された（ステップＳ９３）受信データ量１８２が、閾値保持部１５１から取得された（ステップＳ９２）閾値より大きいか否かを判定する。
【０１１８】
デコーダ制御部１５２は、閾値保持部１５１に保持された閾値が画質である場合、フレーム情報保持部１５０で保持された、フレーム情報のパケット数５２と画質５３の関係からパケット数の閾値を決定し、閾値より大きいか否かを判定する。
【０１１９】
このように、フレーム情報をサーバ１２からクライアント１３に送信することにより、フレーム情報が画像に応じて変更される場合であっても、ユーザが画質の閾値を決定しておくだけで、自動的にパケット数の閾値が決定され、画質の良い画像を表示させることができる。
【０１２０】
図２２に戻り、ステップＳ９７の処理において、受信データ量１８２が閾値より大きいと判定された場合、デコーダ制御部１５２はステップＳ９８に進み、デコーダ１４３にデコードを許可し、ステップＳ９９に進む。したがって、デコーダ１４３は、図１３のステップＳ４４の処理により、取得した画像データをデコードし、表示部１４６に表示することができる。
【０１２１】
一方、ステップＳ９７において、デコーダ制御部１５２は、受信データ量１８２が閾値以下であると判定された場合、ステップＳ９８をスキップし、ステップＳ９９に進む。したがって、デコーダ１４３は、デコードを許可されない。
【０１２２】
ステップＳ９９において、デコーダ制御部１５２は、デコード対象のタイムスタンプを次のフレームのタイムスタンプ（いまの場合、「２０００」）に更新する。
【０１２３】
上述の処理は、全ての画像がデコードされるまで、フレーム毎に繰り返される。
【０１２４】
例えば、図２１に示されるようなエントリ情報がエントリ情報蓄積部１４９に保持されており、閾値保持部１５１に保持された閾値が「３０」であった場合、タイムスタンプが「１０００」と「２０００」のフレームは、受信データ量１８２がそれぞれ「９０」と「４０」であり、閾値「３０」より大きいので、デコードが許可される。しかしながら、タイムスタンプ「３０００」のフレームは、受信データ量１８２が「１０」であり、閾値「３０」以下であるので、デコードは許可されない。そして、タイムスタンプが「４０００」のフレームは、受信データ量１８２が「９０」であり、閾値「３０」より大きいので、デコードが許可される。即ち、デコードされる画像データは、タイムスタンプが「１０００」、「２０００」、「４０００」のデータである。
【０１２５】
したがって、タイムスタンプ「３０００」の画像データを表示部１４６に表示させようとするとき、図１３のステップＳ４９の処理により、タイムスタンプ「２０００」の画像データの画像（前のフレームの画像）が表示される。
【０１２６】
このように、受信データ量に基づいて、デコーダが制御されるので、受信データ量の少ない（画質の悪い）画像のデコードを禁止し、画質の良い画像のみを表示することができる。
【０１２７】
なお、画質の単位は、「bpp」を用いたが「PSNR(per-square-noise-ratio)等、画質を表す単位であればよい。
【０１２８】
上述した一連の処理は、ハードウエアにより実行させることもできるし、ソフトウエアにより実行させることもできる。この場合、上述した処理は、図２３に示されるようなパーソナルコンピュータ６００により実行される。
【０１２９】
図２３において、CPU（Central Processing Unit）６０１は、ROM(Read Only Memory)６０２に記憶されているプログラム、または、記憶部６０８からRAM(Random Access Memory)６０３にロードされたプログラムに従って各種の処理を実行する。RAM６０３にはまた、CPU６０１が各種の処理を実行する上において必要なデータなどが適宜記憶される。
【０１３０】
CPU６０１、ROM６０２、およびRAM６０３は、内部バス６０４を介して相互に接続されている。この内部バス６０４にはまた、入出力インターフェース６０５も接続されている。
【０１３１】
入出力インターフェース６０５には、キーボード、マウスなどよりなる入力部６０６、CRT，LCD（Liquid Crystal Display）などよりなるディスプレイ、並びにスピーカなどよりなる出力部６０７、ハードディスクなどより構成される記憶部６０８、モデム、ターミナルアダプタなどより構成される通信部６０９が接続されている。通信部６０９は、電話回線やCATVを含む各種のネットワークを介しての通信処理を行なう。
【０１３２】
入出力インターフェース６０５にはまた、必要に応じてドライブ６１０が接続され、磁気ディスク、光ディスク、光磁気ディスク、あるいは半導体メモリなどによりなるリムーバブルメディア６２１が適宜装着され、それから読み出されたコンピュータプログラムが、必要に応じて記憶部６０８にインストールされる。
【０１３３】
一連の処理をソフトウエアにより実行させる場合には、そのソフトウエアを構成するプログラムが、専用のハードウエアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば、汎用のパーソナルコンピュータなどに、ネットワークや記録媒体からインストールされる。
【０１３４】
この記録媒体は、図２３に示されるように、コンピュータとは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されているリムーバブルメディア６２１よりなるパッケージメディアにより構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに提供される、プログラムが記録されているROM６０２や記憶部６０８が含まれるハードディスクなどで構成される。
【０１３５】
なお、本明細書において、コンピュータプログラムを記述するステップは、記載された順序に従って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０１３６】
また、本明細書において、システムとは、複数の装置により構成される装置全体を表わすものである。
【０１３９】
以上の如く、本願発明によれば、良質なコンテンツを表示させることができる。特に、送信時にコンテンツが欠落した場合においても、良質な画像のみを選択し、表示させることができる。
【図面の簡単な説明】
【図１】本発明を適用した情報処理システムの構成例を示すブロック図である。
【図２】図１のサーバの構成例を示すブロック図である。
【図３】図２のサーバにおける画像データ送信処理を説明するフローチャートである。
【図４】図２のサーバにおける画像データ送信処理を説明するフローチャートである。
【図５】フレーム情報保持部に保持されるフレーム情報の例を示す図である。
【図６】図１のサーバとクライアントが互いに送信するメッセージの例を示す図である。
【図７】図２のエンコーダがエンコードしたデータの例を示す図である。
【図８】図２の通信部が送信するRTPパケットのフォーマットの例を示す図である。
【図９】図２の通信部が送信したデータの例を示す図である。
【図１０】図１のクライアントの構成例を示すブロック図である。
【図１１】図１０のクライアントにおける画像表示処理を説明するフローチャートである。
【図１２】図１０のクライアントにおける画像表示処理を説明するフローチャートである。
【図１３】図１０のクライアントにおける画像表示処理を説明するフローチャートである。
【図１４】図１０の受信制御部における画像データ受信処理を説明するフローチャートである。
【図１５】図１０の受信制御部における画像データ受信処理を説明するフローチャートである。
【図１６】図１０の通信部が受信するデータの例を示す図である。
【図１７】図１５のステップＳ６８の処理でエントリ情報蓄積部にエントリされたエントリ情報の例を示す図である。
【図１８】図１５のステップＳ６８の処理でエントリ情報蓄積部にエントリされたエントリ情報の例を示す図である。
【図１９】図１５のステップＳ７０の処理でインクリメントされたエントリ情報蓄積部のエントリ情報の例を示す図である。
【図２０】図１５のステップＳ７３の処理で設定されたエントリ情報蓄積部のエントリ情報の例を示す図である。
【図２１】図１０のエントリ情報蓄積部のエントリ情報の例を示す図である。
【図２２】図１０のデコーダ制御部におけるデコード判断処理を説明するフローチャートである。
【図２３】パーソナルコンピュータの構成例を示すブロック図である。
【符号の説明】
１１ ビデオカメラ， １２ サーバ， １３ クライアント， １４ ネットワーク， ３１ 制御部， ３２ フレーム情報保持部， ３３ エンコーダ， ３４ バッファ， ３５ RTPパケット生成部， ３６ 通信部， １４１通信部， １４２ バッファ， １４３ デコーダ， １４４ フレームメモリ， １４５ 表示制御部， １４６ 表示部， １４７ 受信制御部， １４８ 画像情報保持部， １４９ エントリ情報蓄積部， １５０ フレーム情報保持部， １５１ 閾値保持部， １５２ デコーダ制御部
Claims (5)
- フレーム単位の画像を階層符号化して得られる複数のレイヤの符号化データをパケット化したパケットを送信する送信装置から、低域情報から高域情報の順でシーケンス番号を付して送信されてくる前記パケットを前記シーケンス番号の順で受信する受信装置において、
前記送信装置から送信されてくる前記パケットを受信する受信手段と、
前記受信手段により受信された前記パケットを保持する保持手段と、
前記画像のフレームが受信されるとき、パケットロスが検出されるまで、受信された前記パケットを前記保持手段に書き込み、前記パケットロスが検出されてから前記1フレームの最後の前記パケットまで、受信された前記パケットを前記保持手段に書き込まない書き込み手段と、
前記保持手段に書き込まれた１フレームの画像に対応するパケットの数が閾値より大きい場合、そのパケットに配置された符号化データのデコードを行い、前記保持手段に書き込まれた１フレームの画像に対応するパケットの数が前記閾値以下である場合、そのパケットに配置された符号化データのデコードを行わないデコード手段と、
前記デコード手段により表示対象のフレームの画像に対応する符号化データがデコードされない場合、そのフレームより１フレーム前のフレームがデコードされた画像を表示させる表示制御手段と
を備えることを特徴とする受信装置。 - 前記受信手段は、前記送信装置から送信されてくる、前記レイヤ毎の前記符号化データのパケット数と、前記符号化データをデコードすることにより得られる画像の画質に関する情報を含むフレーム情報をさらに受信し、
前記デコード手段は、前記フレーム情報に基づいて決定される前記閾値に基づいて、前記デコードを行う
ことを特徴とする請求項１に記載の受信装置。 - フレーム単位の画像を階層符号化して得られる複数のレイヤの符号化データをパケット化したパケットを送信する送信装置から、低域情報から高域情報の順でシーケンス番号を付して送信されてくる前記パケットを前記シーケンス番号の順で受信する受信装置の受信方法において、
前記送信装置から送信されてくる前記パケットを受信する受信ステップと、
前記画像のフレームが受信されるとき、パケットロスが検出されるまで、受信された前記パケットを保持手段に書き込み、前記パケットロスが検出されてから前記1フレームの最後の前記パケットまで、受信された前記パケットを前記保持手段に書き込まない書き込みステップと、
前記保持手段に書き込まれた１フレームの画像に対応するパケットの数が閾値より大きい場合、そのパケットに配置された符号化データのデコードを行い、前記保持手段に書き込まれた１フレームの画像に対応するパケットの数が前記閾値以下である場合、そのパケットに配置された符号化データのデコードを行わないデコードステップと、
前記デコードステップの処理により表示対象のフレームの画像に対応する符号化データがデコードされない場合、そのフレームより１フレーム前のフレームがデコードされた画像を表示させる表示制御ステップと
を含むことを特徴とする受信方法。 - フレーム単位の画像を階層符号化して得られる複数のレイヤの符号化データをパケット化したパケットを送信する送信装置から、低域情報から高域情報の順でシーケンス番号を付して送信されてくる前記パケットを前記シーケンス番号の順で受信するプログラムであって、
前記送信装置から送信されてくる前記パケットを受信する受信ステップと、
前記画像のフレームが受信されるとき、パケットロスが検出されるまで、受信された前記パケットを保持手段に書き込み、前記パケットロスが検出されてから前記1フレームの最後の前記パケットまで、受信された前記パケットを前記保持手段に書き込まない書き込みステップと、
前記保持手段に書き込まれた１フレームの画像に対応するパケットの数が閾値より大きい場合、そのパケットに配置された符号化データのデコードを行い、前記保持手段に書き込まれた１フレームの画像に対応するパケットの数が前記閾値以下である場合、そのパケットに配置された符号化データのデコードを行わないデコードステップと、
前記デコードステップの処理により表示対象のフレームの画像に対応する符号化データがデコードされない場合、そのフレームより１フレーム前のフレームがデコードされた画像を表示させる表示制御ステップと
を含む処理をコンピュータに実行させることを特徴とするプログラムが記録されている記録媒体。 - フレーム単位の画像を階層符号化して得られる複数のレイヤの符号化データをパケット化したパケットを送信する送信装置から、低域情報から高域情報の順でシーケンス番号を付して送信されてくる前記パケットを前記シーケンス番号の順で受信するプログラムであって、
前記送信装置から送信されてくる前記パケットを受信する受信ステップと、
前記画像のフレームが受信されるとき、パケットロスが検出されるまで、受信された前記パケットを保持手段に書き込み、前記パケットロスが検出されてから前記1フレームの最後の前記パケットまで、受信された前記パケットを前記保持手段に書き込まない書き込みステップと、
前記保持手段に書き込まれた１フレームの画像に対応するパケットの数が閾値より大きい場合、そのパケットに配置された符号化データのデコードを行い、前記保持手段に書き込まれた１フレームの画像に対応するパケットの数が前記閾値以下である場合、そのパケットに配置された符号化データのデコードを行わないデコードステップと、
前記デコードステップの処理により表示対象のフレームの画像に対応する符号化データがデコードされない場合、そのフレームより１フレーム前のフレームがデコードされた画像を表示させる表示制御ステップと
を含む処理をコンピュータに実行させることを特徴とするプログラム。
Priority Applications (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002358945A JP4406816B2 (ja) | 2002-12-11 | 2002-12-11 | 受信装置および受信方法、記録媒体、並びにプログラム |
| US10/504,483 US7593424B2 (en) | 2002-12-11 | 2003-10-06 | Transmitting/receiving system, transmitting apparatus, transmitting method, receiving apparatus, receiving method, recording medium, and program |
| EP03748711A EP1473939A4 (en) | 2002-12-11 | 2003-10-06 | SENDING RECEIVING SYSTEM, SENDING DEVICE, SENDING METHOD, RECEIVING DEVICE, RECEIVING METHOD, RECORDING MEDIUM AND PROGRAM |
| PCT/JP2003/012757 WO2004054266A1 (ja) | 2002-12-11 | 2003-10-06 | 送受信システム、送信装置および送信方法、受信装置および受信方法、記録媒体、並びにプログラム |
| KR20047012281A KR100982637B1 (ko) | 2002-12-11 | 2003-10-06 | 수신 장치, 수신 방법 및 컴퓨터 판독가능한 기록 매체 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002358945A JP4406816B2 (ja) | 2002-12-11 | 2002-12-11 | 受信装置および受信方法、記録媒体、並びにプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004193924A JP2004193924A (ja) | 2004-07-08 |
| JP4406816B2 true JP4406816B2 (ja) | 2010-02-03 |
Family
ID=32500914
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002358945A Expired - Fee Related JP4406816B2 (ja) | 2002-12-11 | 2002-12-11 | 受信装置および受信方法、記録媒体、並びにプログラム |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US7593424B2 (ja) |
| EP (1) | EP1473939A4 (ja) |
| JP (1) | JP4406816B2 (ja) |
| KR (1) | KR100982637B1 (ja) |
| WO (1) | WO2004054266A1 (ja) |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006140966A (ja) * | 2004-11-15 | 2006-06-01 | Kyocera Mita Corp | 時刻認証管理システム及び画像形成装置 |
| JP2007203524A (ja) * | 2006-01-31 | 2007-08-16 | Fujifilm Corp | プリンタ、プリント方法およびプリントプログラム |
| US8125486B2 (en) * | 2006-02-23 | 2012-02-28 | Los Alamos National Security, Llc | Combining multi-layered bitmap files using network specific hardware |
| US7953895B1 (en) | 2007-03-07 | 2011-05-31 | Juniper Networks, Inc. | Application identification |
| US7729328B2 (en) * | 2007-03-14 | 2010-06-01 | Cisco Technology, Inc. | Real-time sessions for wireless mesh networks |
| JP4916487B2 (ja) * | 2008-06-18 | 2012-04-11 | コニカミノルタビジネステクノロジーズ株式会社 | 情報処理装置及びプログラム |
| CN101369880B (zh) * | 2008-09-28 | 2012-09-19 | 华为技术有限公司 | 一种时间标签跳变的检测处理方法和装置 |
| JP5549681B2 (ja) * | 2010-01-14 | 2014-07-16 | 住友電気工業株式会社 | 動画像符号化データの表示方法、装置及び通信システム |
| JP2015012580A (ja) * | 2013-07-02 | 2015-01-19 | キヤノン株式会社 | 受信装置、受信方法及びプログラム |
| WO2015053596A1 (ko) | 2013-10-12 | 2015-04-16 | 삼성전자 주식회사 | 멀티 레이어 비디오의 복호화 및 부호화를 위한 버퍼 관리 방법 및 장치 |
| JP2016126037A (ja) * | 2014-12-26 | 2016-07-11 | ソニー株式会社 | 信号処理装置、および信号処理方法、並びにプログラム |
| US10887662B2 (en) * | 2015-01-24 | 2021-01-05 | Valens Semiconductor Ltd. | Changing visually lossless compression ratio while maintaining parameters related to uncompressed video |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5455629A (en) * | 1991-02-27 | 1995-10-03 | Rca Thomson Licensing Corporation | Apparatus for concealing errors in a digital video processing system |
| US5148272A (en) * | 1991-02-27 | 1992-09-15 | Rca Thomson Licensing Corporation | Apparatus for recombining prioritized video data |
| US5475688A (en) * | 1994-04-22 | 1995-12-12 | Thomson Consumer Electronics, Inc. | Media error code generation as for a video inverse transport processor |
| WO2000027087A1 (en) * | 1998-10-30 | 2000-05-11 | British Telecommunications Public Limited Company | Data transport |
| JP3730835B2 (ja) * | 2000-03-03 | 2006-01-05 | 株式会社エヌ・ティ・ティ・ドコモ | パケット伝送方法、中継装置およびデータ端末 |
| DE10033110B4 (de) * | 2000-07-07 | 2005-06-16 | Siemens Ag | Verfahren, und System zur Übertragung digitalisierter Bewegtbilder von einem Sender zu einem Empfänger und zugehöriger Decoder |
| JP4067281B2 (ja) * | 2001-02-20 | 2008-03-26 | 三洋電機株式会社 | 画像処理方法とその方法を利用可能な画像符号化装置および画像復号装置 |
| JP4549610B2 (ja) * | 2001-11-08 | 2010-09-22 | ソニー株式会社 | 通信システム、通信方法、送信装置および方法、受信装置および方法、並びにプログラム |
| JP2003152544A (ja) * | 2001-11-12 | 2003-05-23 | Sony Corp | データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム |
| JP3757857B2 (ja) * | 2001-12-12 | 2006-03-22 | ソニー株式会社 | データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム |
| JP4150951B2 (ja) | 2002-02-19 | 2008-09-17 | ソニー株式会社 | 動画配信システム、動画配信装置および方法、並びにプログラム |
-
2002
- 2002-12-11 JP JP2002358945A patent/JP4406816B2/ja not_active Expired - Fee Related
-
2003
- 2003-10-06 WO PCT/JP2003/012757 patent/WO2004054266A1/ja active Application Filing
- 2003-10-06 KR KR20047012281A patent/KR100982637B1/ko not_active IP Right Cessation
- 2003-10-06 EP EP03748711A patent/EP1473939A4/en not_active Withdrawn
- 2003-10-06 US US10/504,483 patent/US7593424B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| KR20050084770A (ko) | 2005-08-29 |
| US7593424B2 (en) | 2009-09-22 |
| KR100982637B1 (ko) | 2010-09-15 |
| EP1473939A1 (en) | 2004-11-03 |
| EP1473939A4 (en) | 2011-10-05 |
| WO2004054266A1 (ja) | 2004-06-24 |
| US20050105557A1 (en) | 2005-05-19 |
| JP2004193924A (ja) | 2004-07-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6006241A (en) | Production of a video stream with synchronized annotations over a computer network | |
| US6580756B1 (en) | Data transmission method, data transmission system, data receiving method, and data receiving apparatus | |
| US20050123042A1 (en) | Moving picture streaming file, method and system for moving picture streaming service of mobile communication terminal | |
| JP4406816B2 (ja) | 受信装置および受信方法、記録媒体、並びにプログラム | |
| US8214708B2 (en) | Video transmitting apparatus, video receiving apparatus, and video transmission system | |
| JP2007150916A (ja) | コミュニケーションシステム、端末装置及びコンピュータプログラム | |
| JP2003284037A (ja) | マルチメディアデータ受信装置及び方法、マルチメディアデータ送信装置及び方法 | |
| KR20160110424A (ko) | Dash의 강건한 라이브 동작 | |
| US7937735B2 (en) | Apparatus for the decoding of video data in first and second formats | |
| US20110164689A1 (en) | Method and associated device for generating video | |
| JP2004056393A (ja) | 再生データの保存結果の修復システム | |
| US20160134672A1 (en) | Delivering partially received segments of streamed media data | |
| JP2007274443A (ja) | 画像伝送方法、送信装置、受信装置及び画像伝送システム | |
| US20040105030A1 (en) | Information processing system, information processing apparatus, information processing method, program storage medium, and program | |
| US8879641B2 (en) | Storage of advanced video coding (AVC) parameter sets in AVC file format | |
| JP2005303925A (ja) | ストリームデータ送信装置、ストリームデータ受信装置およびそれらの処理をコンピュータに実行させるための処理プログラムを記録した記録媒体 | |
| US11863767B2 (en) | Transporting HEIF-formatted images over real-time transport protocol | |
| CN117099375A (zh) | 通过实时传输协议传输经heif格式化的图像 | |
| TW201441935A (zh) | 視訊截圖系統及方法 | |
| JP4876427B2 (ja) | 通信システム、送信装置、送信方法、受信装置、受信方法、およびプログラム | |
| US20240163461A1 (en) | Transporting heif-formatted images over real-time transport protocol | |
| KR20210052345A (ko) | 이종 네트워크를 통해 수신한 콘텐츠의 삽입 방법 및 장치 | |
| JP2004015585A (ja) | 動画像印刷装置、動画像印刷方法、およびコンピュータプログラム | |
| RU2366103C2 (ru) | Хранение наборов параметров улучшенного видеокодирования (avc) в файловом формате avc | |
| JP2014003359A (ja) | 映像データをストリーム型データ転送するために用いられるデータ転送システム及びデータ転送システムに用いられる送信装置、受信装置及びプログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20051206 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080603 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080804 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080826 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081027 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20090312 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090512 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20090528 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090721 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090918 |
|
| 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: 20091015 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20091028 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121120 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |