WO2004054266A1 - 送受信システム、送信装置および送信方法、受信装置および受信方法、記録媒体、並びにプログラム - Google Patents

送受信システム、送信装置および送信方法、受信装置および受信方法、記録媒体、並びにプログラム Download PDF

Info

Publication number
WO2004054266A1
WO2004054266A1 PCT/JP2003/012757 JP0312757W WO2004054266A1 WO 2004054266 A1 WO2004054266 A1 WO 2004054266A1 JP 0312757 W JP0312757 W JP 0312757W WO 2004054266 A1 WO2004054266 A1 WO 2004054266A1
Authority
WO
WIPO (PCT)
Prior art keywords
bucket
encoded data
receiving
frame
decoding
Prior art date
Application number
PCT/JP2003/012757
Other languages
English (en)
French (fr)
Inventor
Kenji Yamane
Satoshi Futenma
Hiroshi Kyusojin
Original Assignee
Sony Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corporation filed Critical Sony Corporation
Priority to US10/504,483 priority Critical patent/US7593424B2/en
Priority to EP03748711A priority patent/EP1473939A4/en
Publication of WO2004054266A1 publication Critical patent/WO2004054266A1/ja

Links

Classifications

    • 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
    • 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
    • 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

Definitions

  • the present invention relates to a transmitting / receiving system, a transmitting device and a transmitting method, a receiving device and a receiving method, a recording medium, and a program.
  • the present invention relates to a transmission / reception system, a transmission device and a transmission method, a reception device and a reception method, a recording medium, and a program, and in particular, displays a high-quality image even when received image data is missing.
  • the present invention relates to a transmission / reception system, a transmission device and a transmission method, a reception device and a reception method, a recording medium, and a program that can perform the transmission and reception.
  • the present invention has been made in view of such a situation, and it is an object of the present invention to display a high-quality image even when received image data has a defect.
  • the transmission device converts the content into a hierarchical code and outputs coded data of a plurality of layers; a bucket for the coded data of the plurality of layers; A receiving unit for receiving a bucket transmitted from the transmitting device; and a bucket for receiving the bucket transmitted from the transmitting device.
  • the receiving unit holds the bucket received by the receiving unit.
  • the write control means that if there is a packet loss in one frame of the content, a packet loss occurs in one frame. The remaining packets of one frame are not written in the holding means.
  • Decoding means for controlling the decoding of the encoded data arranged in the bucket held by the holding means; decoding means for decoding the encoded data; and threshold value holding means for holding a threshold value related to decoding by the decoding means.
  • the decoding control means can control decoding by the decoding means based on a threshold value.
  • the transmitting device transmits the number of packets of the encoded data for each of the plurality of layers and the frame information including the information regarding the image quality of the image obtained by decoding the encoded data. Further, the transmitting means and the receiving means can further receive the frame information, and the decoding control means can control the decoding by the decoding means based on the threshold and the frame information held in the threshold holding means.
  • the transmitting method of the transmitting device includes: an encoding step of converting content into hierarchical codes and outputting encoded data of a plurality of layers; bucketing the encoded data of the plurality of layers; The method includes: a packetizing step of outputting a bucket from low-frequency information; and a transmitting step of transmitting a packet.
  • the receiving method of the receiving apparatus includes: a receiving step of receiving a packet transmitted from the transmitting apparatus;
  • the processing includes a writing control step of controlling writing of the received packet, and a determining step of determining whether or not a bucket transmitted by the transmitting device has a bucket loss.
  • the writing control step includes: If there is a packet loss, the packet until the packet loss in one frame occurs It is characterized by not writing the remaining packets of one frame.
  • a transmitting apparatus includes: a coding unit that converts a content into a hierarchical code and outputs encoded data of a plurality of layers; a packetized encoded data of the plurality of layers; and a bucket based on low-frequency information of the encoded data.
  • Bucketing means for outputting; packet number of encoded data for each of a plurality of layers; and holding means for retaining frame information including information on image quality of an image obtained by decoding the encoded data; bucket and frame Transmitting means for transmitting information, the encoding means converts the content into a hierarchical code based on the frame information, and the packetizing means converts the encoded data of a plurality of layers into buckets based on the frame information. It is characterized by the following.
  • a transmission method includes: an encoding step of converting content into a hierarchical code and outputting encoded data of a plurality of layers; packetizing the encoded data of the plurality of layers; and forming a bucket from low-frequency information of the encoded data
  • a bucketing step to be output a number of packets of encoded data for each of a plurality of layers; and a holding step of retaining frame information including information relating to the image quality of an image obtained by decoding the encoded data.
  • a transmitting step of transmitting packet and frame information The encoding step converts the content into a hierarchical code based on the frame information, and the packetizing step performs encoded data of a plurality of layers based on the frame information. Is characterized by being packetized.
  • the program recorded on the first recording medium includes: an encoding step of converting content into a hierarchical code and outputting encoded data of a plurality of layers; and bucketing the encoded data of the plurality of layers.
  • Transmitting the frame information including the information wherein the encoding step converts the content into a hierarchical code based on the frame information, and the packetizing step performs a plurality of layers on the basis of the frame information. It is characterized in that encoded data is packetized.
  • the receiving apparatus includes a receiving means for receiving a bucket transmitted from the transmitting apparatus, a holding means for holding a packet received by the receiving means, and a receiving means for holding the packet received by the receiving means to the holding means.
  • Writing control means for controlling writing; and determining means for determining whether or not a packet transmitted by the transmitting device has a packet loss.
  • the writing control means includes a packet port in one frame of the content. If there is a packet, it is characterized in that the packet until the packet loss in one frame occurs is written to the holding means, and the remaining bucket of one frame is not written to the holding means.
  • Decoding control means for controlling decoding of the encoded data arranged in the packet held in the holding means, decoding means for decoding the encoded data, and threshold holding means for holding a threshold value related to decoding by the decoding means.
  • the decoding control means can control decoding by the decoding means based on a threshold value.
  • the transmitting device further transmits frame information including information on the number of packets of the encoded data for each of the plurality of layers and the image quality of the image obtained by decoding the encoded data, and the receiving unit further receives the frame information.
  • the decoding control means can control the decoding by the decoding means based on the threshold and the frame information held in the threshold holding means.
  • Storage means for storing the content decoded by the decoding means, display control means for controlling the display of the content, and display means for displaying the content, wherein the display control means is coded by the decode control means If the decoding of the data is not allowed, the content stored in the storage means before the content corresponding to the encoded data can be displayed on the display means.
  • a receiving method includes a receiving step of receiving a bucket transmitted from a transmitting device, a writing control step of controlling writing of a packet received by the processing of the receiving step, and a bucket transmitted by the transmitting device.
  • the program recorded on the second recording medium includes a receiving step for receiving a bucket transmitted from the transmitting device, and a program for receiving the bucket.
  • the processing of the writing control step is performed within one frame of the content.
  • packets are written until a packet loss occurs in one frame, and the remaining packets of one frame are not written.
  • a second program includes a receiving step of receiving a bucket transmitted from a transmitting device, a writing control step of controlling writing of the bucket received by the processing of the receiving step, and a program transmitted by the transmitting device. And determining whether there is a packet loss in the incoming bucket.If the packet loss occurs in one frame of the content, the processing of the writing control step is performed until a bucket loss occurs in one frame. It is characterized by causing a computer to execute a process of writing a bucket and not writing a remaining packet of one frame.
  • the content is converted into a hierarchical code, the encoded data of a plurality of layers is output, and the encoded data of the plurality of layers is packetized. Is output, and the packet is transmitted and received. It is determined whether or not there is a packet loss in the received packet. If there is a packet loss in one frame of the content, the packet until the packet loss occurs in one frame is written, and the remaining one frame is written. No packets are written.
  • the content is converted into a hierarchical code, and encoded data of a plurality of layers is output.
  • the coded data of a plurality of layers is packetized based on the frame information, and a packet is output from the low-frequency information of the coded data. Then, the packet and the frame information are transmitted.
  • a bucket transmitted from the transmitting device is received, and it is determined whether or not the received packet has a packet loss. Con If there is a packet loss in one frame, the packet up to the occurrence of the packet loss in one frame is written, and the remaining packets in one frame are not written.
  • FIG. 1 is a block diagram illustrating a configuration example of an information processing system to which the present invention has been applied.
  • FIG. 2 is a block diagram showing a configuration example of the server in FIG.
  • FIG. 3 is a flowchart for explaining image data transmission processing in the server of FIG.
  • FIG. 4 is a flowchart illustrating an image data transmission process in the server of FIG.
  • FIG. 5 is a diagram illustrating an example of frame information held in a frame information holding unit.
  • FIG. 6 is a diagram illustrating an example of a message transmitted by the server and the client of FIG. 1 to each other.
  • FIG. 7 is a diagram showing an example of data encoded by the encoder of FIG.
  • FIG. 8 is a diagram showing an example of the format of an RTP bucket transmitted by the communication unit of FIG.
  • FIG. 9 is a diagram illustrating an example of data transmitted by the communication unit in FIG.
  • FIG. 10 is a block diagram showing a configuration example of the client in FIG.
  • FIG. 11 is a flowchart illustrating the image display processing in the client in FIG.
  • FIG. 12 is a flowchart illustrating the image display processing in the client of FIG.
  • FIG. 13 is a flowchart illustrating the image display processing in the client in FIG. 10.
  • FIG. 14 is a flowchart illustrating the image data reception processing in the reception control unit in FIG. 10.
  • FIG. 15 is a flowchart illustrating the image data reception processing in the reception control unit in FIG. 10.
  • FIG. 16 is a diagram illustrating an example of data received by the communication unit in FIG. 10.
  • FIG. 17 is a diagram showing an example of the entry information stored in the entry information storage unit in the process of step S68 in FIG.
  • FIG. 18 is a diagram illustrating an example of the entry information stored in the entry information storage unit in the process of step S68 in FIG.
  • FIG. 19 is a diagram illustrating an example of the entry information of the entry information storage unit incremented by the process in step S70 of FIG.
  • FIG. 20 is a diagram showing an example of the entry information of the entry information storage unit set in the process of step S73 in FIG.
  • FIG. 21 is a diagram illustrating an example of the entry information of the entry information storage unit in FIG. 10.
  • FIG. 22 is a flowchart illustrating a decoding determination process in the decoder control unit in FIG. 10.
  • FIG. 23 is a block diagram illustrating a configuration example of a personal computer. BEST MODE FOR CARRYING OUT THE INVENTION
  • FIG. 1 shows a configuration example of an information processing system 1 to which the present invention is applied.
  • the server 12 transmits image data input via the video camera 11 to the client 13 via a network 14 such as a packet communication network.
  • the server 12 When data of an image captured by the video camera 11 is input, the server 12 encodes the image data and generates an RTP (Real-time Transport Protocol) packet (FIG. 8 described later). I do.
  • the server 12 sends the generated RTP packet (image data) to the client 13 via the network 14. Further, the server 12 transmits the frame information (FIG. 5 described later) input by the user to the client 13.
  • the client 13 receives the image data, and if there is a packet loss in one frame, holds the image data until the packet loss occurs.
  • the client 13 determines, based on the received frame information, whether or not the image quality or data amount of the held image data is equal to or greater than a threshold set by the user. After decoding, the decoded image data is displayed on a display unit such as a display. If not, display the image of the previous frame.
  • FIG. 2 is a diagram showing a configuration of the server 12. Note that, in the figures, arrows indicated by symbols consisting of the letter “S” and numerals correspond to the processing steps in the flowcharts of FIGS. 3 and 4 described later.
  • the control unit 31 is supplied with, for example, frame information input by the user.
  • the control unit 31 supplies the frame information of the image data input by the user to the frame information holding unit 32.
  • the frame information holding unit 32 holds the frame information supplied from the control unit 31.
  • the frame information is composed of the number of packets for each layer of one frame and the image quality, and details will be described later with reference to FIG.
  • the encoder 33 When the data of the image captured by the video camera 11 is input, the encoder 33 encodes the image data by P-layer encoding such as JPEG (Joint Photographic Experts Group) 2000. The encoder 33 determines what layer (layer) is to be used to encode each frame of the image data based on the frame information stored in the frame information holding unit 32.
  • P-layer encoding such as JPEG (Joint Photographic Experts Group) 2000.
  • the encoder 33 determines what layer (layer) is to be used to encode each frame of the image data based on the frame information stored in the frame information holding unit 32.
  • the encoder 33 supplies the encoded image data to the buffer 34 and holds it.
  • the RTP packet generator 35 acquires the image data stored (held) in the buffer 34, and generates an image based on the number of buckets for each layer in the frame information held in the frame information holder 32. Converts data into RTP packets.
  • the RTP packet generator 35 supplies the communication unit 36 with a packet obtained by converting the image data into an RTP packet.
  • the communication unit 36 converts the image data packet supplied from the RTP packet generation unit 35 through the network 14 Supply to client 13 Further, the communication unit 36 acquires the frame information from the frame information holding unit 32, and transmits the frame information to the client 13 via the network 14.
  • step S1 the control unit 31 stores the number of packets and the image quality (hereinafter, appropriately referred to as frame information) of each layer input by the user in the frame information storage unit 32. It is assumed that the user inputs the frame information in advance by operating a not-shown operation unit or the like, for example.
  • FIG. 5 shows the frame information held in the frame information holding unit 32.
  • the frame information 50 includes a layer (information representing) 51, the number of packets (information representing) 52, and an image quality (information representing) 53.
  • one frame is composed of three layers: a layer “L 0”, a layer “L 1”, and a layer “L 2”.
  • the number of packets 52 of the layer “L 0” is “20”, and therefore, the layer “L 0” is composed of “20” packets.
  • the image quality of the layer “L 0” is set to “0.5 bpp (bit-per-pixel)”.
  • the layer “L 1” is composed of “25” packets, and the image quality 53 is “0.7 bpp”.
  • the layer “L 2” is composed of “45” packets, and the image quality 53 is “1. O b pp”.
  • step S2 the RTP packet generation unit 35 initializes a time stamp added for each frame, and Proceed to 3. That is, the RTP packet generator 35 sets the value of the time stamp to be added to the first frame.
  • step S3 the communication unit 36 acquires the frame information from the frame information holding unit 32, and proceeds to step S4.
  • step S4 the communication unit 36 converts the frame information acquired from the frame information holding unit 32 into an RTSP (Real-time
  • RTSP Real-Time Transport Protocol
  • FIG. 6 shows a message transmitted from the server 12 to the client 13 when the server 12 transmits frame information to the client 13 using the RTSP, and the client 1 which has received the message.
  • 3 shows an example of an acknowledgment message transmitted to the server 12.
  • CSeqJ indicates the RTSP message number
  • Packet-layer_bpp is the header.
  • the header a set of three pieces of information including the layer name, the total number of packets (the number of packets up to the layer with the layer name), and the image quality of the layer is described one set or repeatedly.
  • the message transmitted from the server 12 to the client 13 is a message of the extension method with the RTSP number “1”.
  • the layer L 0 is the total number of packets (the number of buckets of the layer L 0) “20” and the image quality is “0.5 bpp”.
  • the layer L1 has an integrated packet number (the sum of the layer L0 and layer L1 packet numbers) of power S “4 5” (the number of layer L1 packets is “2 5”), and the image quality is “0. 7 bp P ”.
  • Layer L 2 is the total number of packets (Layer L 0, Layer L l, Layer L The sum of the number of packets of L2) Power S is “90” (the number of packets of layer L2 is “45”), and the image quality is “1.0 bpp”. Therefore, as shown in FIG. 6, L 0 20.5 .5 L 1 40.5 .7 L 2 .91.0 .0 is described in the header of the message transmitted from the server 12 to the client 13. Is done.
  • the message shown in Fig. 6 sent from client 13 to server 12 receives the message of the extension method with RTSP number “1” (the message sent from server 13 to client 13). This is a message for notifying that.
  • the process proceeds to step S5, where the encoder 33 is set in advance. Based on the frame rate (for example, 30 frames Z seconds), the timer (not shown) provided in the encoder 33 is set to a time corresponding to one frame (in this case, 33 nis). Proceed to 6.
  • step S6 the encoder 33 acquires the data of the image photographed via the video camera 11, and proceeds to step S7.
  • step S7 the encoder 33 determines whether a predetermined time (33 ms in this case) set in the timer has elapsed (the timer has expired), and determines that the predetermined time has elapsed. Until the process, image data is acquired.
  • step S7 If it is determined in step S7 that the predetermined time has elapsed, the encoder 33 proceeds to step S8, ends the acquisition of the image data, and encodes the acquired image data. That is, the encoder 33 encodes one frame of image data by hierarchically encoding the image data based on the frame information stored in the frame information holding unit 32, and encodes the encoded data as a result of the encoding. get. Then, proceeding to step S9 in FIG. 4, the encoder 33 supplies the encoded data obtained by encoding the image data for one frame to the buffer 34 and holds it.
  • FIG. 7 shows the encoded data for one frame held in the buffer 34.
  • the coded data is SOC (Start Of Code stream) 7 1, Code stream 7 and EOC (End Of Code stream).
  • SOC 71 is data indicating the start of encoded data
  • E0C 73 is data indicating the end of encoded data.
  • Code Stream 72 is encoded image data.
  • JPEG2000 supports a plurality of types of progressive displays having different resolutions and compression ratios.
  • JPEG2000 also supports image quality scalable (SNR (Signal to Noise Ratio)).
  • the encoder 33 converts the image data into, for example,
  • the image quality is scalably encoded into layers, and the data of each layer (layer) is arranged in Code Stream 72.
  • Code Stream 72 is hierarchically divided into layer L0 data 91, layer L1 data 92, and layer L2 data 93 according to the frame information shown in FIG. Has been
  • the layer L0 data 91 is low frequency information of the image data
  • the layer L1 data 92 is middle frequency information.
  • the layer L2 data 93 is high-frequency information of the image data.
  • an image having the same spatial resolution as the original image having low image quality (in the example of FIG. 5, an image having image quality of 0.5 bpp) is obtained.
  • an image with better image quality than decoding only layer L0 data 91 in the case of FIG. 5, 0.75 bpp image quality.
  • decoding up to the layer L2 data 93 (layer L0 data 91, layer L1 data 92, layer L3 data 93) provides an image with even better image quality (in the case of the example in FIG. 5). , 1.0 image quality).
  • the encoder 33 when the encoded data is decoded, the encoder 33 performs hierarchical encoding so that an image of the image quality in the frame information can be obtained, and performs layer L0 data, layer L1 data 92, and layer L0 data. Obtain L3 data 93.
  • step S10 the RTP packet generator 35 acquires the frame information 50 (FIG. 5) from the frame information holder 32. And proceed to step SI 1.
  • step S11 the RTP packet generation unit 35 calculates the number of buckets for each layer in the frame information 50 obtained in step S10 from the encoded data for one frame held in the buffer 34. Obtain data of a size that allows a bucket to be generated, and generate an RTP bucket.
  • the RTP packet generation unit 35 when the frame information 50 shown in FIG. 5 is obtained, the RTP packet generation unit 35 generates 20 LTP buckets from the layer L0 data 91, and 20 RTP buckets from the layer L0 data 92 5 RTP buckets are generated, and 45 RTP packets are generated for the layer L2 data 93.
  • step S11 After generating the RTP packet in step S11, the process proceeds to step S12, where the RTP packet generation unit 35 transmits the generated RTP packet to the communication unit 36 in the order of layer L0 to layer L2. And proceed to step S13.
  • step S13 the communication unit 36 transmits the RTP bucket to the client 13 via the network 14.
  • FIG. 8 shows an example of the RTP format of the RTP packet transmitted from the communication unit 36 to the client 13.
  • the RTP header includes vl 1 1 indicating the version number, p 1 1 2 indicating padding, X 1 13 indicating the presence or absence of the extension header, cc 1 14 indicating the number of senders (Counter), and marker information (marker bit). ), 1 ⁇ ⁇ 1 1 ⁇ ⁇ , pt 1 pt pt 1 pt pt pt pt pt pt pt pt pt pt pt pt sequence sequence sequence pt pt pt sequence pt sequence pt sequence pt sequence pt sequence pt sequence sequence SS SS SS SS SS SS SS SS SS SS Composed of 9 powers, ra.
  • the encoded data is placed as Data120.
  • the client 13 controls the processing time for developing the RT packet based on the timestamp described in the timestamp 18 and controls the reproduction of a real-time image or voice.
  • the time stamp is determined for each frame, and a common time stamp is set for a plurality of RTP packets in which encoded data of the same frame is arranged.
  • FIG. 9 is a diagram illustrating an example in which the communication unit 36 transmits an RTP bucket generated based on the frame information 50 illustrated in FIG. 5 to the client 13 via the network 14.
  • the horizontal axis t represents time.
  • the communication unit 36 transmits 20 packets of layer L0 encoded data (layer L0 data 91 in FIG. 7) (low-frequency information of image data) (packets of sequence numbers 1 to 20). Send.
  • forty-five packets of layer L1 encoded data (layer L1 data 92 in FIG. 7) (mid-range information of image data) (sequence numbers 21 to 45 packets) are transmitted.
  • the communication unit 36 transmits 45 packets of layer L3 image data (layer L3 data 93 in FIG. 7) (high-frequency information of image data) (sequence numbers 46 to 90). Packet) and the transmission of one frame of coded data ends.
  • the sequence number is assigned in order from the packet generated from the first encoded image data (the data following S0C71 in Fig. 7), and is added to the sequence 117 of the RTP bucket shown in Fig. 8. Be placed.
  • step S13 after transmitting the RTP packet in step S13, the process proceeds to step S14, where the RTP packet generation unit sets the time stamp described in the timestamp l18 (FIG. 8) of the RTP bucket. Update and go to step S15.
  • sequence numbers arranged in sequence 11 of FIG. 8 are sequentially added to the RTP bucket. Therefore, from the sequence number, the client 13 can detect whether the received RTP packet is missing (missing) from the transmitted RTP packet.
  • step S15 the server 12 determines whether or not all the image data has been transmitted to the client 13. If the server 12 determines that all the image data has not been transmitted to the client 13, the process returns to steps S 15 to S 5, and the image data captured via the video camera 11 is , Acquire for each frame, and repeat the process of transmitting the RTP packet. In step S15, when the server 12 determines that all the image data has been transmitted to the client 13, the process ends.
  • FIG. 10 shows a configuration example of the client 13 in FIG. It should be noted that, in the figures, arrows indicated by symbols consisting of the letter “S” and numerals correspond to the steps of the processing in the flowcharts of FIGS. 11 to 13 described later.
  • the communication unit 141 receives the frame information and the RTP bucket transmitted from the server 12.
  • the reception control unit 147 performs a reception process based on the frame information and the RTP packet received by the communication unit 141, and transfers the RTP packet (image data) received by the communication unit 141 to the buffer 144. Control writing. Details of this reception processing will be described later with reference to FIGS. 14 to 21.
  • the reception control unit 147 acquires the frame information from the communication unit 141 and supplies the frame information to the frame information holding unit 150 of the image information holding unit 148 to hold the frame information. Further, the reception control unit 147 enters an entry into the entry information storage unit 149 of the image information holding unit 148 for each time stamp (for each frame) of the RTP packet received by the communication unit 141. It holds information of the received image data in the form of RTP packets (hereinafter, appropriately referred to as entry information).
  • the communication unit 141 writes the received RTP packet into the buffer 142 according to the control of the reception control unit 147, so that the buffer 142 stores the RTP data supplied from the communication unit 141. Hold packets temporarily.
  • the decoder 144 acquires the RTP packet held in the buffer 142.
  • the threshold value holding unit 151 holds, for example, a data amount (the number of RTP packets) for each time stamp or a threshold value of image quality input by the user.
  • the decoder control unit 152 determines the decoder 1 based on the threshold value held by the threshold value holding unit 151, and the entry information (FIG. 21 described later) held by the entry information storage unit 149. 4 It is determined whether or not decoding of the RTP bucket obtained in step 3 is permitted.
  • the decoder 144 decodes the encoded data arranged in the RTP bucket obtained from the buffer 144, and decodes the image data obtained as a result of the decoding. Recorded in frame memory 144.
  • the display control unit 145 acquires the image data stored in the frame memory 144 and causes the display unit 146 such as a display to display the image.
  • the image display processing of the client 13 in FIG. 10 will be described in detail with reference to FIGS. 11 to 13. This process is started when the image data is transmitted from the server 11.
  • step S31 the client 13 initializes itself, and proceeds to step S32.
  • the data stored in the buffer 144, the frame memory 144, the image information storage unit 148, and the threshold storage unit 151 are erased.
  • the threshold value holding unit 151 holds the data amount (the number of RTP packets) or the image quality threshold value input by the user, and proceeds to step S33.
  • the threshold value is assumed to be input in advance by, for example, operating a not-shown operation unit or the like by the user.
  • step S33 the communication unit 14 1 transmits the frame information (FIG. 6) transmitted from the server 12 in step S4 of FIG. 3 or the client in step S13 of FIG.
  • the RTP packet (FIG. 9) transmitted from 13 is received via the network 14 and the process proceeds to step S34.
  • step S34 the reception control unit 147 acquires the frame information received by the communication unit 141 from the communication unit 141, supplies the frame information to the frame information holding unit 150, and holds the frame information. .
  • the frame information holding unit 150 of the image information holding unit 148 holds the same frame information as the frame information held in the frame information holding unit 32 of FIG. Therefore, when the frame information shown in FIG. 6 is received by the communication unit 141, the frame information shown in FIG. 5 is held in the frame information holding unit 150.
  • step S35 in which the reception control section 147 performs the reception processing, thereby enabling or disabling the writing of the RTP bucket received by the communication section 141.
  • the permission is determined, and the entry information described later is stored in the entry information storage unit 149.
  • step S36 the communication unit 141 determines whether the reception control unit 144 has permitted the writing of the RTP packet in the reception process in step S35. Is determined.
  • the communication unit 14 1 proceeds from step S 36 to S 37, and stores the RTP packet received in the processing of step S 33 3 into the buffer 1 4 2
  • the buffer 144 holds the RTP packet received by the communication unit 141.
  • step S38 the decoder 144 determines whether or not the buffer 144 holds the RTP packet for one frame. That is, the decoder 144 sets the reception processing time for one frame in a built-in timer (not shown) in advance, and determines whether or not the set time is measured by the timer. The decoder 144 repeats the process of step S38 until one frame of RTP packet is held, and if one frame of RTP packet is held, the process proceeds from step S38 to FIG. Proceed to S39.
  • step S39 the decoder 144 acquires the one-frame RTP packet held in the buffer 142 in the processing of step S37 from the buffer 144, and proceeds to step S40.
  • step S40 the decoder control unit 152 sends the image information held in the processes of steps S34 and S35 in FIG. 11 from the image information holding unit 148, that is, the entry information storage unit 14 The entry information held in 9 and the frame information held in the frame information holding unit 150 are acquired, and the process proceeds to step S41.
  • step S41 the decoder control unit 152 obtains the decoder amount (the number of RTP packets) or the image quality threshold held in the threshold holding unit 151 in the process of step S32, Proceed to.
  • step S42 the decoder control unit 152 performs a decoding determination process based on the image information acquired in the process in step S39 and the threshold acquired in the process in step S41. It is determined whether decoding by the decoders 144 is permitted or not. This decoding determination process will be described later using the flowchart of FIG.
  • step S42 the process proceeds to step S43 in FIG. 13, and the decoder 1443 determines whether or not the decoding has been permitted by the decoder control unit 152 in the processing in step S42. judge. If decoding is permitted from the decoder control unit 15.2, the decoder 14 43 advances the process from step S 43 to S 44, and the RTP packet acquired from the buffer 14 42 in the process of step S 39 And proceed to step S45.
  • step S45 the decoder 144 supplies the decoded image data to the frame memory 144 for storage, and proceeds to step S46.
  • step S46 the display control unit 145 acquires the image data stored in the frame memory 144 in step S45, and proceeds to step S47.
  • step S47 the display control unit 145 causes the display unit 146 to display an image based on the image data acquired in step S46, and ends the process.
  • step S43 determines whether or not the image data of the previous frame (eg, the frame immediately before the current frame to be displayed) exists.
  • step S48 it is determined that the image data of the previous frame exists in the frame memory 144 (when the image data of the previous frame was received, the process of step S45 was performed).
  • step S49 the display control unit 144 displays the image of the previous frame (the image stored in the frame memory 144) on the display unit 144, and ends the processing. I do.
  • step S49 is skipped and the process ends. Therefore, in this case, nothing is displayed on the display section 144.
  • step S36 of FIG. 12 when the communication unit 141 determines that the writing of the RTP bucket is not permitted from the reception control unit 147, the communication unit 141 does not write the RTP bucket to the buffer. The process ends. Note that the processes in FIGS. 11 and 12 are repeated until no RTP packets are transmitted from the server 12.
  • step S61 the reception control unit 147 determines whether or not the communication unit 141 has received the frame information through the processing in step S33 in FIG. If it is determined in step S61 that frame information has been received, the process proceeds to step S62, where the reception control unit 147 stores the frame information in the frame information storage unit 150 of the image information storage unit 148. The communication unit 141 supplies and holds the received frame information, and the process returns to step S61.
  • step S61 If it is determined in step S61 that frame information has not been received, the process proceeds to step S63, and reception control section 147 checks whether communication section 141 has received an RTP packet. Determine whether or not. If it is determined in step S63 that the image data has not been received, the data received by the communication unit 141 is unnecessary data. The process returns to step S61 without performing the process, and the same process is repeated thereafter.
  • step S63 when the reception control unit 1407 determines that the communication unit 141 has received the image data, the process proceeds to step S64, where the communication unit 141 receives the image data.
  • step S64 Detect the time stamp of the RTP packet. That is, since the RTP packet is transmitted in the format shown in FIG. 8, the reception control unit 147 detects the value of the time stamp described in the timestamp 118 of the header.
  • the time stamp is initialized in the process of step S2 in FIG. 3, and is updated every frame in step S14 in FIG.
  • FIG. 16 shows an example of an RTP packet received by the communication unit 141, where the horizontal axis represents time t.
  • one frame is composed of 90 RTP packets.
  • the communication section 14 1 is a frame whose time stamp is “1 0 0 0”.
  • RTP packets (sequence numbers 1 to 90) are received, and after that, the RTP packets (sequence number) of the image data of the frame with the time stamp “20000” are received.
  • the communication unit 141 receives the group of RTP packets of the image data of the frame whose time stamp is “30000” (RTP packets with sequence numbers of 181 to 270), and finally An RTP packet group (RTP packets with sequence numbers of 27.1 to 360) of the image data of the frame whose time stamp is “40000” is received.
  • RTP packets with sequence numbers 13 1 and 19 1 are lost (missing).
  • step S65 the reception control unit 14.7 determines whether there is a time stamp detected in the previous processing in step S64. I do. If it is determined in step S65 that there is a time stamp detected last time, the process proceeds to step S66, and the reception control unit 147 sets the time stamp detected in the process of step S64 this time to the last time. Judge whether the time stamp matches the detected time stamp.
  • step S66 if it is determined that the time stamp detected this time does not match the previous time stamp, the process proceeds to step S67, and the reception control unit 144 sets the time stamp detected this time to the previous time stamp. Determine if it is greater than the timestamp. If it is determined in step S67 that the time stamp detected this time is not larger (smaller) than the previous time stamp, the received image data is already received and processed, so the processing is skipped. Return to S61.
  • step S67 If it is determined in step S67 that the time stamp detected this time is larger than the previous time stamp, or if it is determined in step S65 that there is no previous time stamp, 41 If the received RTP packet is the first RTP packet of the frame, the reception control unit 147 advances the process to step S68, and stores the time stamp detected this time in the entry information storage unit 149. To enter. For example, when the communication unit 141 receives the sequence of RTP packets shown in FIG. 16 and receives the RTP packet of sequence number 1, this RTP packet is the first packet in the frame. Therefore, as shown in FIG. 17, the entry information in which the time stamp “100” is placed is entered (registered) in the entry information storage unit 149.
  • the entry information includes a time stamp 181, a received data amount 182, and a flag 183.
  • the flag 183 indicates whether or not a loss has been detected (step S73). Processing will be described later).
  • the received data amount 182 indicates the number of RTP packets in one received frame, and is incremented when a new RTP packet in one frame is received (Step S 70 0 described later). Processing).
  • the received timestamp 18 1 1 S image data of “100” is composed of RTP packets of sequence numbers 1 to 90, and there is no loss. 2 is “90”, and the flag 183 is “0” indicating that there is no loss. Then, since the RTP packet with the sequence number 91 is newly received, the time stamp 18 1 is entered with “2 0 0 0” c .
  • the reception control unit 147 determines, based on the sequence number of the RTP packet received by the communication unit 141 (the number described in the sequence 11 of the format of FIG. 8), Determine whether the RTP packet has been lost.
  • step S69 if the sequence number of the RTP packet received this time by the communication unit 141 is the next number after the sequence number of the previously received RTP packet, it is determined that the RTP bucket has not been lost. If it is not the next number, the RTP packet is lost. RTP packet is missing). If it is determined in step S69 that the RTP packet has not been lost, the process proceeds to step S70, and if it is determined that the RTP packet has been lost, the process proceeds to step S73.
  • step S66 in FIG. 14 determines whether a loss has occurred (the sequence number is not a consecutive number), or whether the flag 18 2 of the entry information storage unit 14 9 is “1” (a loss was detected until the previous time). judge.
  • step S72 if no loss is detected and it is determined that the flag 182 is not "1" (is "0"), the process proceeds to step S70 of FIG.
  • the communication control unit 147 increments the received data amount 182 of the entry information storage unit 149 by one.
  • the entry information shown in FIG. 19 is stored in the entry information storage unit 149. That is, the received data amount 182 having the time stamp 18 1 of “20000” is incremented from “0” to “1”.
  • step S71 the reception control unit 147 permits the communication unit 141 to write the RTP bucket to the buffer 144.
  • the processing ends. Therefore, the communication section 141 performs the processing of step S37 in FIG. 11, writes the received image data (RTP packet) to the buffer 142, and performs the subsequent processing.
  • step S72 of FIG. 14 the reception control unit 1 4 7 Advances the processing to step S73, sets the flag of the entry information storage unit 149 to "1", and ends the processing.
  • the reception control unit 147 does not permit the communication unit 141 to write the RTP packet to the buffer 142. Therefore, in this case, the communication unit 141 does not write the RTP packet into the buffer 142.
  • the RTP packet with the sequence number 13 1 has been lost, and is stored in the entry information storage unit 1 49.
  • the entered entry information is changed to “1”, as shown in FIG. 20. Since the RTP packet is not written to the buffer 142, the received data amount 182 is not changed.
  • the flag is “1” (there is a lost RTP packet), so the entry information storage unit Since the flag 183 remains “1” and the RTP packet is not written to the buffer 142, the received data amount 182 remains unchanged at “40”.
  • FIG. 21 shows an example of the entry information of the entry information storage unit 149 when the image data as shown in FIG. 16 is received by the communication unit 141.
  • the frame with the time stamp “10000” is composed of 90 packets, and there is no loss. 182 becomes “90J”, and the flag 183 becomes “0”. Also, since the RTP packet with the sequence number 131 is lost in the frame with the time stamp of “20000”, only the RTP packets with the sequence numbers 91 to 130 are allowed to be written. (Processes in steps S70 and S71) The received data amount of the time stamp 1801 S "20000" is "40". At this time, since a loss of the RTP packet is detected, the flag 183 becomes “1”.
  • the reception control unit 147 writes only the image data (lossless image data) up to the loss into the buffer 144.
  • loss can be detected by detecting the sequence number.
  • determining a flag indicating whether or not loss has been detected it is possible to reliably hold only image data until loss is detected.
  • step S91 the decoder control unit 152 sets the time stamp to be decoded by the decoder 144 to an initial value (in this case, “10000”), and then proceeds to step S92. Proceed to.
  • step S92 the decoder control unit 152 acquires the data amount (the number of RTP packets) or the image quality threshold value held in the process of step S32 in FIG. 11 from the threshold value holding unit 151. Proceed to step S93.
  • step S93 the decoder control unit 152 acquires the image information from the image information holding unit 148. That is, the entry information (FIG. 21) is obtained from the entry information storage unit 149, and the frame information (FIG. 5) is obtained from the frame information holding unit 150.
  • step S94 the decoder control unit 152 sets a timer (not shown) of the decoder 144 for a predetermined time (necessary to acquire one frame of image data). Time), start the process, and proceed to step S95.
  • step S95 the decoder control unit 152 controls the decoder 144 to acquire image data from the buffer 142, and proceeds to step S96.
  • step S96 the decoder control unit 152 determines whether or not the timer has expired, and repeats the processing in step S95 until the timer has expired.
  • step S96 if the timer has expired (an RTP packet for one frame has been obtained), the decoder control unit 152 advances the process from step S96 to S97.
  • step S97 the received data amount 182 obtained from the entry information storage unit 1449 (step S93) is based on the threshold obtained from the threshold storage unit 151 (step S92). It is determined whether it is larger.
  • the decoder control unit 15 2 calculates the number of buckets 5 2 of frame information and the image quality 5 3 held in the frame information holding unit 150.
  • the threshold of the number of packets is determined from the relationship, and it is determined whether the number is larger than the threshold.
  • the user By transmitting the frame information from the server 12 to the client 13 in this manner, even if the frame information is changed according to the image, the user only has to determine the threshold of the image quality, and the automatic operation is performed.
  • the threshold value of the number of packets is determined in advance, and an image with good image quality can be displayed.
  • step S97 when it is determined that the received data amount 182 is larger than the threshold, the decoder control unit 152 proceeds to step S98, and the decoder 1 4 3 , And proceed to step S99. Therefore, the decoder 144 can decode the acquired image data and display it on the display unit 144 by the process of step S44 in FIG.
  • step S97 when it is determined that the received data amount 182 is equal to or smaller than the threshold, the decoder control unit 152 skips step S98.
  • step S99 the decoder control unit 152 updates the time stamp to be decoded to the time stamp of the next frame (in this case, “20000”).
  • the above process is repeated for each frame until all images have been decoded. For example, if the entry information as shown in FIG. 21 is stored in the entry information storage unit 149 and the threshold value stored in the threshold value storage unit 151 is “3 0”, the time stamp is Decoding is permitted for the frames of “1 00 0” and “2 00 0” because the received data amount 18 2 is “9 0” and “4 0”, respectively, which is larger than the threshold value “3 0”. Is done. However, decoding of the frame with the time stamp "30000" is not permitted because the received data amount 182 is "1 0" and is equal to or less than the threshold value "3 0".
  • the frame with the time stamp “40000” has a received data amount of “182” S “90” and is larger than the threshold “30”, so that decoding is permitted. That is, the image data to be decoded is data having a time stamp of “10000”, “20000”, and “40000”.
  • the image data of the time stamp “30000” is to be displayed on the display unit 146
  • the image data of the time stamp “20000” is obtained by the processing of step S49 in FIG.
  • the image (image of the previous frame) is displayed.
  • the decoder since the decoder is controlled based on the amount of received data, it is possible to prohibit decoding of an image having a small amount of received data (poor image quality) and display only an image with good image quality.
  • the unit of image quality may be “bpp”! / Pitaka S It may be a unit representing image quality such as “PSNR (per-square-noise-ratio)”.
  • Fig. 2 3 From here, the program stored in the CPU (Central Processing Unit) 601 f or the ROM (Read Only Memory) 602 or the storage unit 608 Various processes are executed in accordance with the program loaded in RAM (Random Access Memory) 603.
  • the RAM 603 also appropriately stores data necessary for the CPU 601 to execute various processes.
  • the CPU 601, R0M 602, and RAM 603 are interconnected via an internal bus 604.
  • the internal bus 604 is also connected to an input / output interface 605.
  • the input / output interface 605 has an input section 606 consisting of a keyboard, mouse, etc., a display consisting of a CRT, LCD (Liquid Crystal Display), etc.
  • a storage unit 608 including a hard disk and a communication unit 609 including a modem and a terminal adapter are connected.
  • the communication unit 609 performs communication processing via various networks including a telephone line and CATV.
  • a drive 610 is connected to the input / output interface 605 as required, and a removable medium 621 made of a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory is appropriately mounted.
  • the computer program read therefrom is installed in the storage unit 608 as needed.
  • the programs that make up the software are installed in a computer that is built into dedicated hardware, or by installing various programs to perform various functions. It can be executed, for example, installed on a general-purpose personal computer from a network or a recording medium.
  • this recording medium is constituted by a package medium composed of removable media 621 on which the program is recorded, which is distributed in order to provide the program to the user, separately from the computer. Not only that, it is also provided with a ROM 602 in which programs are stored and a hard disk including a storage unit 608, which is provided to the user in a state of being incorporated in the apparatus main body in advance. Note that, in this specification, steps to describe a computer program are not only processes performed in chronological order according to the order described, but also processes performed in parallel or individually even if not necessarily performed in chronological order. Is also included. Further, in the present specification, the term “system” refers to an entire device including a plurality of devices. Industrial applicability
  • a system for receiving transmitted content can be realized.
  • high quality images can be displayed even if content is lost during transmission.
  • high-quality content can be displayed.
  • a high-quality image can be displayed.
  • high-quality contents can be displayed.
  • only high-quality images can be selected and displayed.

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 Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Television Signal Processing For Recording (AREA)

Abstract

本発明は、受信した画像データに欠陥がある場合であっても、良質な画像を表示することができるようにする送受信システム、送信装置および送信方法、受信装置および受信方法、記録媒体、並びにプログラムに関する。受信制御部１４７は、通信部１４１が受信した画像データからロスを検出し、ロスに応じて受信を許可する。受信が許可されると、通信部１４１は、バッファに画像データを保持する。デコーダ制御部１５２は、閾値保持部１５１に保持された閾値に応じて、デコードを許可する。デコードを許可されると、デコーダ１４３は、バッファ１４２に保持された画像データをデコードし、フレームメモリ１４４に保持する。表示制御部１４５は、フレームメモリ１４４に保持された画像データに基づき、表示部１４６を制御し、画像を表示させる。本発明は、画像配信システムに適用することができる。

Description

明細書
送受信システム、 送信装置および送信方法、 受信装置および受信方法、 記録媒体、 並びにプログラム 技術分野
本発明は、 送受信システム、 送信装置および送信方法、 受信装置および受信方 法、 記録媒体、 並びにプログラムに関し、 特に、 受信した画像データが欠落して いる場合であっても、 良質な画像を表示することができるようにした送受信シス テム、 送信装置および送信方法、 受信装置および受信方法、 記録媒体、 並びにプ ログラムに関する。 背景技術
近年、 インターネット等を用いて動画データを転送する際に発生する転送エラ 一について、 さまざまな処理が提案されている。
MPEG 4 (Moving Picture Experts Group 4 ) では、 再同期マーカと RVLC (Reversibl e Variabl e Length Code) 等を用いて、 転送エラーが起きた箇所 を廃棄し、 エラー耐性の向上が図られている。
また、 発生した.エラーを目立たないように遮蔽するエラーコンシールメントの 技術としては、 動画の時間方向の相関性を利用し、 1つ前のフレームを再生する 力、 または過去の画面の同一位置からの情報と置き換える処理が提案されている。 しかしながら、 RVLCを用いてエラー耐性を向上した場合、 符号化効率が低下 することが指摘されている。 また、 上述したエラーコンシールメントは、 処理が 煩雑であり、 シーンチェンジ等の急峻な画像の変化には対応することが困難であ るという課題があった。
そこで、 階層符号化された画像データを転送する場合において、 送信されたフ レームの一部が欠落し、 受信側に送信されない場合には、 欠落する時までに受信 側で受信され、 記憶されたデータをもとに欠落した周波数成分を生成し、 より上 位の階層の周波成分を再構成するエラーコンシールメント技術が提案されている (例えば、 特開平 1 0— 2 4 3 4 0 0号公報 （第 7ページ） 参照） 。
しかしながら、 画像情報に多く含まれる低域情報が欠落した場合、 画質が劣化 するという課題があった。
発明の開示
本発明はこのような状況に鑑みてなされたものであり、 受信した画像データに 欠陥がある場合であっても、 良質な画像を表示することができるようにするもの である。
本発明の送受信システムは、 送信装置は、 コンテンツを階層符号にし、 複数の レイヤの符号化データを出力する符号化手段と、 複数のレイヤの符号化データを バケツトイヒし、 符号化データの低域情報からバケツトを出力するバケツト化手段 と、 パケットを送信する送信手段とを備え、 受信装置は、 送信装置から送信され てくるバケツトを受信する受信手段と、 受信手段により受信されたバケツトを保 持する保持手段と、 受信手段が受信したパケットの、 保持手段への書き込みを制 御する書き込み制御手段と、 送信装置により送信されてくるバケツトにバケツト ロスがあるか否かを判定する判定手段とを備え、 書き込み制御手段は、 コンテン ッの 1フレーム内に、 パケットロスがある場合、 1フレーム内のパケットロスが 生じるまでのパケットを、 保持手段に書き込み、 1 フレームの残りのパケットを 保持手段に書き込まないことを特徴とする。
保持手段に保持されたバケツトに配置された符号化データのデコードを制御す るデコード制御手段と、 符号化データをデコードするデコード手段と、 デコード 手段のデコードに関する閾値を保持する閾値保持手段とをさらに備え、 デコード 制御手段は、 デコード手段によるデコードを、 閾値に基づいて制御するようにす ることができる。
送信装置は、 複数のレイヤ毎の符号化データのパケット数と、 符号化データを デコードすることにより得られる画像の画質に関する情報を含むフレーム情報を さらに送信し、 受信手段は、 フレーム情報をさらに受信し、 デコード制御手段は、 閾値保持手段に保持された閾値とフレーム情報に基づいて、 デコード手段による デコードを制御するようにすることができる。
本発明の送受信方法は、 送信装置の送信方法は、 コンテンツを階層符号にし、 複数のレイヤの符号化データを出力する符号化ステップと、 複数のレイヤの符号 化データをバケツト化し、 符号化データの低域情報からバケツトを出力するパケ ット化ステップと、 パケットを送信する送信ステップとを含み、 受信装置の受信 方法は、 送信装置から送信されてくるパケットを受信する受信ステップと、 受信 ステップの処理が受信したパケットの書き込みを制御する書き込み制御ステップ と、 送信装置により送信されてくるバケツトにバケツトロスがあるか否かを判定 する判定ステップとを含み、 書き込み制御ステップは、 コンテンツの 1フレーム 内に、 パケットロスがある場合、 1フレーム内のパケットロスが生じるまでのパ ケットを書き込み、 1フレームの残りのパケットを書き込まないことを特徴とす る。
本発明の送信装置は、 コンテンツを階層符号にし、 複数のレイヤの符号化デー タを出力する符号化手段と、 複数のレイヤの符号化データをパケット化し、 符号 化データの低域情報からバケツトを出力するバケツト化手段と、 複数のレイヤ毎 の符号化データのパケット数と、 符号化データをデコードすることにより得られ る画像の画質に関する情報を含むフレーム情報を保持する保持手段と、 バケツト とフレーム情報を送信する送信手段とを備え、 符号化手段は、 フレーム情報に基 づいて、 コンテンツを階層符号にし、 パケット化手段は、 フレーム情報に基づい て、 複数のレイヤの符号化データをバケツト化することを特徴とする。
本発明の送信方法は、 コンテンツを階層符号にし、 複数のレイヤの符号化デー タを出力する符号化ステップと、 複数のレイヤの符号化データをパケット化し、 符号化データの低域情報からバケツトを出力するバケツト化ステップと、 複数の レイャ毎の符号化データのパケット数と、 符号化データをデコードすることによ り得られる画像の画質に関する情報を含むフレーム情報を保持する保持ステップ と、 パケットとフレーム情報を送信する送信ステップとを含み、 符号化ステップ は、 フレーム情報に基づいて、 コンテンツを階層符号にし、 パケット化ステップ は、 フレーム情報に基づいて、 複数のレイヤの符号化データをパケット化するこ とを特徴とする。
本発明の第 1の記録媒体に記録されているプログラムは、 コンテンツを階層符 号にし、 複数のレイヤの符号化データを出力する符号化ステップと、 複数のレイ ャの符号化データをバケツト化し、 符号化データの低域情報からバケツトを出力 するパケット化ステップと、 バケツトと保持された複数のレイヤ毎の符号化デー タのパケット数と、 符号化データをデコードすることにより得られる画像の画質 に関する情報を含むフレーム情報を送信する送信ステップとを含み、 符号化ステ ップは、 フレーム情報に基づいて、 コンテンツを階層符号にし、 パケット化ステ ップは、 フレーム情報に基づいて、 複数のレイヤの符号化データをパケット化す ることを特徴とする。
本発明の第 1のプログラムは、 コンテンツを階層符号にし、 複数のレイヤの符 号化データを出力する符号化ステップと、 複数のレイヤの符号化データをパケッ ト化し、 符号化データの低域情報からバケツトを出力するパケット化ステップと、 バケツトと保持された複数のレイヤ毎の符号化データのバケツト数と、 符号化デ ータをデコードすることにより得られる画像の画質に関する情報を含むフレーム 情報を送信する送信ステップとを含み、 符号化ステップは、 フレーム情報に基づ いて、 コンテンツを階層符号にし、 パケット化ステップは、 フレーム情報に基づ いて、 複数のレイヤの符号化データをパケット化する処理をコンピュータに実行 させることを特徴とする。
本発明の受信装置は、 送信装置から送信されてくるバケツトを受信する受信手 段と、 受信手段により受信されたパケットを保持する保持手段と、 受信手段が受 信したパケットの、 保持手段への書き込みを制御する書き込み制御手段と、 送信 装置により送信されてくるバケツトにパケットロスがあるか否かを判定する判定 手段とを備え、 書き込み制御手段は、 コンテンツの 1フレーム内に、 パケッ ト口 スがある場合、 1フレーム内のパケットロスが生じるまでのパケットを、 保持手 段に書き込み、 1 フレームの残りのバケツトを保持手段に書き込まないことを特 徴とする。
保持手段に保持されたパケットに配置された符号化データのデコードを制御す るデコード制御手段と、 符号化データをデコードするデコード手段と、 デコード 手段のデコードに関する閾値を保持する閾値保持手段とをさらに備え、 デコード 制御手段は、 デコード手段によるデコードを、 閾値に基づいて制御するようにす ることができる。
送信装置は、 複数のレイヤ毎の符号化データのパケット数と、 符号化データを デコードすることにより得られる画像の画質に関する情報を含むフレーム情報を さらに送信し、 受信手段は、 フレーム情報をさらに受信し、 デコード制御手段は、 閾値保持手段に保持された閾値とフレーム情報に基づいて、 デコード手段による デコードを制御するようにすることができる。
デコード手段によりデコードされたコンテンツを記憶する記億手段と、 コンテ ンッの表示を制御する表示制御手段と、 コンテンツを表示する表示手段とをさら に備え、 表示制御手段は、 デコード制御手段により符号化データのデコードが許 可されない場合、 その符号化データに対応するコンテンツより前に記憶手段に記 憶されたコンテンツを表示手段に表示させるようにすることができる。
本発明の受信方法は、 送信装置から送信されてくるバケツトを受信する受信ス テツプと、 受信ステップの処理により受信されたパケットの書き込みを制御する 書き込み制御ステップと、 送信装置により送信されてくるバケツトにバケツトロ スがあるか否かを判定する判定ステップとを含み、 書き込み制御ステップの処理 は、 コンテンツの 1フレーム内に、 パケットロスがある場合、 1フレーム内のパ ケットロスが生じるまでのバケツトを書き込み、 1 フレームの残りのバケツトを 書き込まないことを特徴とする。
本発明の第 2の記録媒体に記録されているプログラムは、 送信装置から送信さ れてくるバケツトを受信する受信ステップと、 受信ステップの処理により受信さ れたバケツトの書き込みを制御する書き込み制御ステップと、 送信装置により送 信されてくるパケットにバケツトロスがあるか否かを判定する判定ステップとを 含み、 書き込み制御ステップの処理は、 コンテンツの 1フレーム内に、 パケット ロスがある場合、 1フレーム内のパケットロスが生じるまでのパケットを書き込 み、 1 フレームの残りのパケットを書き込まないことを特徴とする。
本発明の第 2のプログラムは、 送信装置から送信されてくるバケツトを受信す る受信ステップと、 受信ステップの処理により受信されたバケツトの書き込みを 制御する書き込み制御ステップと、 送信装置により送信されてくるバケツトにパ ケットロスがあるか否かを判定する判定ステップとを含み、 書き込み制御ステツ プの処理は、 コンテンツの 1フレーム内に、 パケットロスがある場合、 1フレー ム内のバケツトロスが生じるまでのバケツトを書き込み、 1フレームの残りのパ ケットを書き込まない処理をコンピュータに実行させることを特徴とする。
第 1の本願発明においては、 コンテンツが階層符号にされて、 複数のレイヤの 符号化データが出力され、 複数のレイヤの符号化データがパケット化されて、 符 号化データの低域情報からパケットが出力され、 そのパケットが送信され、 受信 される。 受信されたパケットにパケットロスがあるか否かが判定され、 コンテン ッの 1フレーム内に、 パケッ トロスがある場合、 1フレーム内のパケッ トロスが 生じるまでのパケットが書き込まれ、 1 フレームの残りのパケットは、 書き込ま れない。
第 2の本願発明においては、 符号化データをデコードすることにより得られる 画像の画質に関する情報を含むフレーム情報に基づいて、 コンテンツが階層符号 にされて、 複数のレイヤの符号化データが出力される。 また、 フレーム情報に基 づいて、 複数のレイヤの符号化データがパケット化され、 符号化データの低域情 報からパケットが出力される。 そして、 そのパケットとフレーム情報が送信され る。
第 3の本願発明においては、 記送信装置から送信されてくるバケツトが受信さ れ、 受信されたパケットにパケットロスがあるか否かが判定される。 コン の 1フレーム内に、 パケッ トロスがある場合、 1フレーム内のパケッ トロスが生 じるまでのパケットが書き込まれ、 1 フレームの残りのパケットは、 書き込まれ ない。 図面の簡単な説明
図 1は、 本発明を適用した情報処理システムの構成例を示すプロック図である。 図 2は、 図 1のサーバの構成例を示すプロック図である。
図 3は、 図 2のサーバにおける画像データ送信処理を説明するフローチヤ一ト である。
図 4は、 図 2のサーバにおける画像データ送信処理を説明するフローチャート である。
図 5は、 フレーム情報保持部に保持されるフレーム情報の例を示す図である。 図 6は、 図 1のサーバとクライアントが互いに送信するメッセージの例を示す 図である。
図 7は、 図 2のエンコーダがエンコードしたデータの例を示す図である。
図 8は、 図 2の通信部が送信する RTPバケツトのフォーマツトの例を示す図 である。
図 9は、 図 2の通信部が送信したデータの例を示す図である。
図 1 0は、 図 1のクライアントの構成例を示すブロック図である。
図 1 1は、 図 1 0のクライアントにおける画像表示処理を説明するフローチヤ ートである。
図 1 2は、 図 1 0のクライアントにおける画像表示処理を説明するフローチヤ ートである。
図 1 3は、 図 1 0のクライアントにおける画像表示処理を説明するフローチヤ ートである。
図 1 4は、 図 1 0の受信制御部における画像データ受信処理を説明するフロー チヤ一トである。 図 1 5は、 図 1 0の受信制御部における画像データ受信処理を説明するフロー チヤ一トである。
図 1 6は、 図 1 0の通信部が受信するデータの例を示す図である。
図 1 7は、 図 1 5のステップ S 6 8の処理でェントリ情報蓄積部にェントリさ れたエントリ情報の例を示す図である。
図 1 8は、 図 1 5のステップ S 6 8の処理でェントリ情報蓄積部にェントリさ れたエントリ情報の例を示す図である。
図 1 9は、 図 1 5のステップ S 7 0の処理でィンクリメントされたェントリ情 報蓄積部のェントリ情報の例を示す図である。
図 2 0は、 図 1 5のステップ S 7 3の処理で設定されたエントリ情報蓄積部の ェントリ情報の例を示す図である。
図 2 1は、 図 1 0のェントリ情報蓄積部のェントリ情報の例を示す図である。 図 2 2は、 図 1 0のデコーダ制御部におけるデコード判断処理を説明するフロ 一チャートである。
図 2 3は、 パーソナ コンピュータの構成例を示すブロック図である。 発明を実施するための最良の形態
図 1は、 本発明を適用した情報処理システム 1の構成例を表わしている。 この情報処理システム 1において、 サーバ 1 2は、 ビデオカメラ 1 1を介して 入力された画像データを、 パケット通信網等のネットワーク 1 4を介して、 クラ イアント 1 3に送信する。
サーバ 1 2は、 ビデオカメラ 1 1が撮影した画像のデータが入力されると、 そ の画像データをエンコードして、 RTP (Real-t ime Transport Protocol ) パケ ット （後述する図 8 ) を生成する。 サーバ 1 2は、 生成された RTPパケット (画像データ） を、 ネットワーク 1 4を介して、 クライアント 1 3に送信する。 また、 サーバ 1 2は、 ユーザによって入力されたフレーム情報 （後述する図 5 ) をクライアント 1 3に送信する。 クライアント 1 3は、 画像データを受信し、 1 フレーム内にパケットロスがあ る場合、 パケットロスが生じるまでの画像データを保持する。 クライアント 1 3 は、 受信したフレーム情報に基づいて、 保持した画像データの画質またはデータ 量が、 ユーザによって設定された閾値以上であるか否かを判断し、 閾値以上であ る場合、 画像データをデコードし、 ディスプレイ等の表示部に、 デコードされた 画像データを表示させる。 閾値以上ではない場合、 前のフレームの画像を表示さ せる。
図 2は、 サーバ 1 2の構成を示す図である。 なお、 図中、 " S " の文字と数字 からなる記号で示されている矢印は、 後述する図 3と図 4のフローチャートの処 理のステップに対応している。
制御部 3 1には、 例えばユーザが入力するフレーム情報が供給される。 制御部 3 1は、 ユーザにより入力された画像データのフレーム情報を、 フレーム情報保 持部 3 2に供給する。 フレーム情報保持部 3 2は、 制御部 3 1から供給されるフ レーム情報を保持する。 ここで、 フレーム情報は、 1 フレームのレイヤ毎のパケ ット数と画質から構成されているが、 詳細は、 図 5で後述する。
エンコーダ 3 3は、 ビデオカメラ 1 1が撮影した画像のデータが入力されると、 JPEG (Joint Photographic Experts Group) 2000等の P皆層符号化によって、 画像データをエンコードする。 なお、 エンコーダ 3 3は、 画像データの各フレー ムをどのような階層 （レイヤ） に階層符号化するかを、 フレーム情報保持部 3 2 に記憶されたフレーム情報に基づいて決定する。
エンコーダ 3 3は、 エンコードした画像データを、 バッファ 3 4に供給して保 持させる。 RTPパケット生成部 3 5は、 ノ ッファ 3 4に記憶 （保持） された画像 データを取得し、 フレーム情報保持部 3 2に保持されたフレーム情報におけるレ ィャ毎のバケツト数に基づいて、 画像データを RTPパケット化する。
そして、 RTPパケット生成部 3 5は、 画像データを RTPパケット化することに より得られるパケットを、 通信部 3 6に供給する。 通信部 3 6は、 RTPパケット 生成部 3 5から供給された画像データのパケットを、 ネットワーク 1 4を介して、 クライアント 1 3に供給する。 さらに、 通信部 3 6は、 フレーム情報保持部 3 2 から、 フレーム情報を取得し、 ネットワーク 1 4を介して、 クライアント 1 3に フレーム情報を送信する。
次に、 図 3と図 4を参照して、 図 2のサーバ 1 2における画像データ送信処理 を説明する。 なお、 この処理は、 ビデオカメラ 1 1から、 サーバ 1 2に画像デー タが入力されたとき、 またはユーザにより、 サーバ 1 2に画像データの送信処理 が指令されたとき、 開始される。
ステップ S 1において、 制御部 3 1は、 ユーザにより入力された各レイヤのパ ケット数と画質 （以下、 適宜、 フレーム情報と称する） を、 フレーム情報保持部 3 2に保持する。 なお、 フレーム情報は、 例えば、 ユーザが図示せぬ操作部等を 操作して予め入力するものとする。
ここで、 図 5は、 フレーム情報保持部 3 2に保持されるフレーム情報を示して いる。 フレーム情報 5 0は、 レイヤ （を表す情報） 5 1、 パケット数 （を表す情 報） 5 2、 画質 （を表す情報） 5 3から構成されている。 図 5では、 1フレーム は、 レイヤ 「L 0」 、 レイヤ 「L 1」 、 レイヤ 「L 2」 の 3つのレイヤから構成 されるものとしてある。 また、 図 5では、 レイヤ 「L 0」 のパケット数 5 2は 「20」 とされており、 従って、 レイヤ 「L 0」 は、 「2 0」 個のパケットから 構成される。 また、 レイヤ 「L 0」 の画質は 「0. 5bpp (bit-per - pixel) 」 とされている。
同様に、 図 5では、 レイヤ 「L 1」 は、 「2 5」 個のパケットから構成され、 画質 5 3は 「0. 7 b p p」 とされている。 レイヤ 「L 2」 は、 「4 5」 個のパ ケットから構成され、 画質 5 3は、 「1. O b p p」 とされている。 以上から、 図 5のフレーム情報によれば、 1フレームは、 「 20 + 2 5 + 4 5 = 9 0」 個の バケツトから構成される。
図 3に戻り、 ステップ S 1の処理後は、 ステップ S 2に進み、 RTPパケット生 成部 3 5は、 フレーム毎に付加されるタイムスタンプを初期化して、 ステップ S 3に進む。 即ち、 RTPパケット生成部 3 5は、 最初のフレームに付加するタイム スタンプの値を設定する。
ステップ S 3において、 通信部 3 6は、 フレーム情報保持部 3 2からフレーム 情報を取得し、 ステップ S 4に進む。 ステップ S 4において、 通信部 3 6は、 フ レーム情報保持部 3 2から取得したフレーム情報を、 RTSP (Real-time
Streaming Protocol ) 等のス トリーミングのセッション管理プロ トコルを用い、 ネットワーク 1 4を介して、 クライアント 1 3に送信する。 なお、 RTSPは、 RFC (Request For Comment) 2326で定義されている。
ここで、 図 6は、 RTSPを用いて、 サーバ 1 2がクライアント 1 3にフレーム 情報を送信する場合に、 サーバ 1 2からクライアント 1 3に送信させるメッセ一 ジと、 そのメッセージを受信したクライアント 1 3がサーバ 1 2に送信する了承 のメッセージの例を示している。
「S→C」 は、 サーバ 1 2か.らクライアント 1 3に送信するメッセージである ことを表し、 「C→S」 は、 クライアント 1 3からサーバ 1 2に送信するメッセ ージであることを表している。 なお、 「0PTI0NS」 はメソッドを表し、
「0PTI0NS * RTSP/1. 0」 は拡張メソッドであることを示している。 また、
CSeqJ は、 RTSP のメッセージ番号を示しており、 「Packet- llayer_bpp」 は、 ヘッダである。 ヘッダには、 レイヤ名、 積算パケット数 （レイヤ名のレイヤまで のパケット数） 、 レイヤの画質の 3つの情報のセットが 1セットまたは繰り返し 記述される。
図 6の例の場合、 サーバ 1 2からクライアント 1 3に送信されるメッセージは、 RTSP番号が 「1」 の拡張メソッドのメッセージである。 ヘッダには、 図 5に示 した情報が記述されている。 即ち、 図 5では、 レイヤ L 0は、 積算パケット数 (レイヤ L 0のバケツ ト数） カ 「2 0」 であり、 画質が 「0 . 5 b p p」 である。 レイヤ L 1は、 積算パケット数 （レイヤ L 0とレイヤ L 1のパケット数の和） 力 S 「4 5」 （レイヤ L 1のパケッ ト数は 「2 5」 ） であり、 画質が 「0 . 7 b p P」 である。 レイヤ L 2は、 積算パケット数 （レイヤ L 0、 レイヤ L l、 レイヤ L 2のパケット数の和） 力 S 「9 0」 （レイヤ L 2のパケット数は 「4 5」 ） であ り、 画質が 「1 . 0 b p p」 である。 このため、 サーバ 1 2からクライアント 1 3に送信するメッセージのヘッダには、 図 6に示したように、 L 0 2 0 0 . 5 L 1 4 5 0 . 7 L 2 9 0 1 . 0が記述される。
また、 クライアント 1 3からサーバ 1 2に送信される図 6に示したメッセージ は、 RTSP番号が 「1」 の拡張メソッドのメッセージ （サーバ 1 2からクライァ ント 1 3に送信されたメッセージ） を受信したことを通知するメッセージである。 図 3に戻り、 ステップ S 4において、 サーバ 1 2からクライアント 1 3にフレ ーム情報 （が記述されたメッセージ） が送信された後は、 ステップ S 5に進み、 エンコーダ 3 3は、 予め設定されたフレームレート （例えば、 3 0フレーム Z 秒） に基づいて、 エンコーダ 3 3に設けられた不図示のタイマに、 1フレーム分 の時間 （いまの場合、 3 3 ni s ) を設定し、 ステップ S 6に進む。 ステップ S 6 において、 エンコーダ 3 3は、 ビデオカメラ 1 1を介して撮影された画像のデー タを取得し、 ステップ S 7に進む。 ステップ S 7において、 エンコーダ 3 3は、 タイマに設定された所定時間 （いまの場合、 3 3 m s ) が経過した （タイマが終 了した） か否かを判定し、 所定時間が経過したと判定するまで、 画像データを取 得する処理を行なう。
ステップ S 7において、 エンコーダ 3 3は、 所定時間が経過したと判定した場 合、 ステップ S 8に進み、 画像データの取得を終了し、 取得じた画像データをェ ンコードする。 即ち、 エンコーダ 3 3は、 1フレーム分の画像データを、 フレー ム情報保持部 3 2に記憶されたフレーム情報に基づいて階層符号化することによ りエンコードし、 そのエンコード結果として符号化データを取得する。 そして、 図 4のステップ S 9に進み、 エンコーダ 3 3は、 1フレーム分の画像データをェ ンコードすることにより得られた符号化データをバッファ 3 4に供給して保持さ せる。
ここで、 図 7は、 バッファ 3 4に保持された 1フレーム分の符号化データを示 している。 符号化データは、 SOC (Start Of Code stream) 7 1、 Code stream 7 2、 および EOC (End Of Code stream) から構成されている。 SOC 7 1は、 符 号化データの開始を示すデータであり、 E0C 7 3は、 符号化データの終了を示す データである。 また、 Code Stream 7 2は、 エンコードされた画像データである。 ここで、 ェンコ^ ~ダ 3 3で行われる階層符号化である、 例えば、 JPEG2000 は、 解像度や圧縮率などが異なる複数種類のプログレッシブ表示に対応している。 ま た JPEG2000は、 画質スケーラブル (SNR (Signal to Noise Rat io) ) に対応し ている。 本実施の形態では、 エンコーダ 3 3は、 画像データを、 例えば、
JPEG2000方式で、 図 5に示したフレーム情報にしたがい、 画質スケーラブルに 階層符号化し、 各階層 （レイヤ） のデータを Code Stream 7 2に配置する。
その結果、 図 7では、 Code Stream 7 2は、 図 5に示したフレーム情報にした がって、 レイヤ L 0データ 9 1、 レイヤ L 1データ 9 2、 およびレイヤ L 2デー タ 9 3に階層化されている。 レイヤ L 0データ 9 1は、 画像データの低域情報と なっており、 レイヤ L 1データ 9 2は、 中域情報となっている。 そして、 レイヤ L 2データ 9 3は、 画像データの高域情報となっている。
従って、 レイヤ L 0データ 9 1をデコードすると、 画質の低い元の画像 （図 5 の例の場合、 0 . 5 b p pの画質の画像） と同じ空間解像度の画像が得られる。 また、 レイヤ L 1データ 9 2まで (レイヤ L 0データとレイヤ L 1データ） をデ コードすると、 レイヤ L 0データ 9 1だけをデコードした場合よりも画質の良い 画像 （図 5の例の場合、 0 . 7 5 b p pの画質の画像） が得られる。 さらに、 レ ィャ L 2データ 9 3まで (レイヤ L 0データ 9 1、 レイヤ L 1データ 9 2、 レイ ャ L 3データ 9 3 ) をデコードすると、 さらに良い画質の画像 （図 5の例の場合、 1 . 0の画質の画像） を得ることができる。
なお、 エンコーダ 3 3は、 符号化データをデコードしたときに、 フレーム情報 における画質の画像を得ることができるように階層符号化を行い、 レイヤ L 0デ ータ、 レイヤ L 1データ 9 2、 レイヤ L 3データ 9 3を得る。
図 4に戻り、 ステップ S 9の処理後は、 ステップ S 1 0に進み、 RTPパケット 生成部 3 5は、 フレーム情報保持部 3 2から、 フレーム情報 5 0 (図 5 ) を取得 し、 ステップ S I 1に進む。 ステップ S 1 1において、 RTPパケット生成部 3 5 は、 バッファ 3 4に保持されている 1フレーム分の符号化データから、 ステップ S 1 0で取得したフレーム情報 5 0における各レイヤ毎のバケツト数のバケツト が得られるサイズのデータを取得し、 RTPバケツ トを生成する。
即ち、 RTPパケット生成部 3 5は、 図 5に示したフレーム情報 5 0を取得した 場合、 レイヤ L 0データ 9 1力、ら 2 0個の RTPバケツトを、 レイヤ L 1データ 9 2力 ら 2 5個の RTPバケツトを、 レイヤ L 2データ 9 3力、ら 4 5個の RTPパ ケットを生成する。
ステップ S 1 1で RTPパケットを生成した後は、 ステップ S 1 2に進み、 RTP パケッ ト生成部 3 5は、 生成した RTPパケッ トを、 レイヤ L 0からレイヤ L 2 の順で通信部 3 6に供給し、 ステップ S 1 3に進む。 ステップ S 1 3において、 通信部 3 6は、 RTPバケツトを、 ネットワーク 1 4を介してクライアント 1 3に 送信する。
ここで、 図 8は、 通信部 3 6がクライアント 1 3に送信する RTPパケットの RTPフォーマットの例を示している。 RTPヘッダは、 バージョン番号を示す v l 1 1、 パディングを示す p 1 1 2、 拡張ヘッダの有無を示す X 1 1 3、 送信元数 (Counter) を示す c c 1 1 4、 マーカ情報 (marker bi t) を示す m 1 1 5、 ぺ イロ一ドタイプを示す p t 1 1 6、 シーケンス番号を示す sequence 1 1 7、 タ ィムスタンプを示す t itnestamp l 1 8、 同期ソース （送信元） 識別子を示す SSRC 1 1 9力、ら構成される。 RTPヘッダの後には、 符号化データが Data 1 2 0 として配置される。
クライアント 1 3は、 timestamp l 1 8に記述されたタイムスタンプにより、 RT パケッ トを展開するときの処理時間を制御し、 リアルタイム画像、 または音 声の再生制御を行う。 なお、 タイムスタンプは、 1フレーム毎に決定され、 同一 のフレームの符号化データを配置させる複数の RTPパケットには、 共通のタイ ムスタンプが設定される。 図 9は、 通信部 3 6が、 図 5に示したフレーム情報 5 0に基づいて生成された RTPバケツトを、 ネットワーク 1 4を介して、 クライアント 1 3に、 送信する例 を示す図である。 なお、 横軸 tは時間を表している。
まず、 通信部 3 6は、 レイヤ L 0の符号化データ （図 7のレイヤ L 0データ 9 1 ) (画像データの低域情報） のパケットを 2 0個 （シーケンス番号 1乃至 2 0 のパケット） 送信する。 次に、 レイヤ L 1の符号化データ （図 7のレイヤ L 1デ ータ 9 2 ) (画像データの中域情報） のパケットを 4 5個 （シーケンス番号 2 1 乃至 4 5のパケット） 送信する。 最後に、 通信部 3 6は、 レイヤ L 3の画像デー タ （図 7のレイヤ L 3データ 9 3 ) (画像データの高域情報） のパケットを 4 5 個 （シーケンス番号 4 6乃至 9 0のパケット） 送信し、 1フレームの符号化デー タの送信が終了する。 なお、 シーケンス番号は、 エンコードされた最初の画像デ ータ （図 7の S0C 7 1の次のデータ） から生成されたパケットから順に付され、 図 8に示した RTPバケツトの sequence 1 1 7に配置される。
図 4に戻り、 ステップ S 1 3において、 RTPパケットを送信した後は、 ステツ プ S 1 4に進み、 RTPパケット生成部は、 RTPバケツトの timestamp l 1 8 (図 8 ) に記述するタイムスタンプを更新し、 ステップ S 1 5に進む。
ここで、 図 8の sequence 1 1 7に配置されるシーケンス番号は、 RTPバケツ トにシーケンシャルに付される。 従って、 このシーケンス番号によって、 クライ アント 1 3は、 受信した RTPパケットが、 送信された RTPパケットに対して足 りない （欠落している） かどうかを検出することができる。
ステップ S 1 5において、 サーバ 1 2は、 全ての画像データを、 クライアント 1 3に送信したか否かを判定する。 サーバ 1 2は、 全ての画像データをクライア ント 1 3に送信していないと判定した場合、 処理をステップ S 1 5から S 5に戻 し、 ビデオカメラ 1 1を介して撮影された画像データを、 フレーム毎に取得し、 RTPパケットを送信する処理を操り返す。 ステップ S 1 5において、 サーバ 1 2 は、 全ての画像データをクライアント 1 3に送信したと判定した場合、 処理を終 了する。 次に、 図 1 0は、 図 1のクライアント 1 3の構成例を示している。 なお、 図中、 " S " の文字と数字からなる記号で示されている矢印は、 後述する図 1 1乃至図 1 3のフローチャートの処理のステップに対応している。
通信部 1 4 1は、 サーバ 1 2から送信されているフレーム情報と RTPバケツ トを受信する。 受信制御部 1 4 7は、 通信部 1 4 1が受信したフレーム情報と RTPパケットに基づいて受信処理を行ない、 通信部 1 4 1により受信された RTP パケット （画像データ） のバッファ 1 4 2への書き込みを制御する。 この受信処 理の詳細は、 図 1 4乃至図 2 1を参照して後述する。
また、 受信制御部 1 4 7は、 フレーム情報を、 通信部 1 4 1から取得し、 画像 情報保持部 1 4 8のフレーム情報保持部 1 5 0に供給して保持させる。 さらに、 受信制御部 1 4 7は、 通信部 1 4 1が受信した RTPパケットのタイムスタンプ 毎 （ 1フレーム毎） に、 画像情報保持部 1 4 8のエントリ情報蓄積部 1 4 9にェ ントリし、 RTPパケッ トの形で受信した画像データの情報 （以下、 適宜、 ェント リ情報と称する） を保持する。
通信部 1 4 1は、 受信制御部 1 4 7の制御にしたがい、 受信した RTPパケッ トをバッファ 1 4 2に書き込み、 これによりバッファ 1 4 2は、 通信部 1 4 1カ ら供給される RTPパケットを一時保持する。 デコーダ 1 4 3は、 バッファ 1 4 2に保持された RTPパケットを取得する。
閾値保持部 1 5 1は、 例えば、 ユーザにより入力された、 タイムスタンプ毎の データ量 （RTPパケット数） または画質の閾値を保持する。
デコーダ制御部 1 5 2は、 閾値保持部 1 5 1で保持された閾値と、 エントリ情 報蓄積部 1 4 9で保持されたエントリ情報 （後述する図 2 1 ) に基づいて、 デコ ーダ 1 4 3で取得され RTP バケツトの、 デコードを許可するか否かを判断する。 デコーダ 1 4 3は、 デコーダ制御部 1 5 2によりデコードが許可されると、 ノ ッファ 1 4 2から取得した RTPバケツトに配置された符号化データをデコード し、 そのデコードの結果得られる画像データをフレームメモリ 1 4 4に記億する。 表示制御部 1 4 5は、 フレームメモリ 1 4 4に記憶された画像データを取得し、 ディスプレイ等の表示部 1 4 6に画像を表示させる。
図 1 0のクライアント 1 3の画像表示処理を、 図 1 1乃至図 1 3を用いて詳細 に説明する。 なお、 この処理は、 サーバ 1 1から画像データが送信されたとき、 開始される。
ステップ S 3 1において、 クライアント 1 3は、 自身を初期化し、 ステップ S 3 2に進む。 これにより、 バッファ 1 4 2、 フレームメモリ 1 4 4、 画像情報保 持部 1 4 8、 および閾値保持部 1 5 1に保持されているデータは消去される。 ス テツプ S 3 2において、 閾値保持部 1 5 1は、 ユーザにより入力されたデータ量 (RTPパケット数） または画質の閾値を保持し、 ステップ S 3 3に進む。 なお、 閾値は、 例えば、 ユーザが図示せぬ操作部等を操作して予め入力するものとする。 ステップ S 3 3において、 通信部 1 4 1は、 図 3のステップ S 4の処理でサー ノ 1 2から送信されたフレーム情報 （図 6 ) 、 または図 4のステップ S 1 3の処 理でクライアント 1 3から送信された RTPパケット （図 9 ) を、 ネットワーク 1 4を介して受信し、 ステップ S 3 4に進む。
ステップ S 3 4において、 受信制御部 1 4 7は、 通信部 1 4 1で受信されたフ レーム情報を通信部 1 4 1から取得し、 フレーム情報保持部 1 5 0に供給して保 持させる。 これにより、 画像情報保持部 1 4 8のフレーム情報保持部 1 5 0は、 図 2のフレーム情報保持部 3 2に保持されたフレーム情報と同じフレーム情報を 保持する。 従って、 図 6に示したフレーム情報が通信部 1 4 1で受信された場合、 図 5に示したフレーム情報が、 フレーム情報保持部 1 5 0に保持される。
ステップ S 3 4の処理後は、 ステップ S 3 5に進み、 受信制御部 1 4 7は、 受 信処理を行ない、 これにより通信部 1 4 1により受信された RTPバケツトの書 き込み許可または不許可を決定するとともに、 後述するエントリ情報を、 ェント リ情報蓄積部 1 4 9に記憶させる。 なお、 受信処理の詳細は、 図 1 4と図 1 5の フローチャートを用いて後述する。 ステップ S 3 5の処理後は、 ステップ S 3 6に進み、 通信部 1 4 1は、 ステツ プ S 3 5の受信処理で、 受信制御部 1 4 7から RTPパケットの書き込みが許可 されたか否かを判定する。 通信部 1 4 1は、 受信制御部 1 4 7から書き込みが許 可された場合、 ステップ S 3 6から S 3 7に進み、 ステップ S 3 3の処理で受信 した RTPパケットを、 バッファ 1 4 2に供給して書き込み、 これによりバッフ ァ 1 4 2は、 通信部 1 4 1が受信した RTPパケットを保持する。
そして、 ステップ S 3 8に進み、 デコーダ 1 4 3は、 バッファ 1 4 2に 1フレ ーム分の RTPパケットが保持されたか否かを判定する。 即ち、 デコーダ 1 4 3 は、 1フレーム分の受信処理の時間を予め内蔵するタイマ （図示せず） に設定し ておき、 タイマによって、 その設定した時間が計時されたか否かを判定する。 デ コーダ 1 4 3は、 1フレーム分の RTPパケットが保持されるまで、 ステップ S 3 8の処理を繰り返し、 1フレーム分の RTPパケットが保持された場合、 処理 をステップ S 3 8から図 1 2の S 3 9に進める。
ステップ S 3 9において、 デコーダ 1 4 3は、 ステップ S 3 7の処理でバッフ ァ 1 4 2に保持された 1フレーム分の RTPパケットを、 バッファ 1 4 2から取 得し、 ステップ S 40に進む。 ステップ S 40において、 デコーダ制御部 1 5 2 は、 画像情報保持部 1 4 8から、 図 1 1のステップ S 3 4， S 3 5の処理で保持 された画像情報、 即ちエントリ情報蓄積部 1 4 9に保持されたェントリ情報とフ レーム情報保持部 1 5 0に保持されたフレーム情報を取得し、 ステップ S 4 1に 進む。
ステップ S 4 1において、 デコーダ制御部 1 5 2は、 ステップ S 3 2の処理で 閾値保持部 1 5 1に保持されたデコーダ量 （RTPパケット数） または画質の閾値 を取得し、 ステップ S 4 2に進む。 ステップ S 4 2において、 デコーダ制御部 1 5 2は、 ステップ S 3 9の処理で取得した画像情報と、 ステップ S 4 1の処理で 取得した閾値に基づいて、 デコード判断処理を行い、 これにより、 デコーダ 1 4 3によるデコードの許可または不許可を決定する。 このデコード判断処理は、 図 2 2のフローチャートを用いて後述する。 ステップ S 4 2の処理後は、 図 1 3のステップ S 4 3に進み、 デコーダ 1 4 3 は、 ステップ S 4 2の処理により、 デコーダ制御部 1 5 2からデコードが許可さ れたか否かを判定する。 デコーダ 1 4 3は、 デコーダ制御部 1 5. 2からデコード が許可された場合、 処理をステップ S 4 3から S 4 4に進め、 ステップ S 3 9の 処理でバッファ 1 4 2から取得した RTPパケットをデコードし、 ステップ S 4 5に進む。
ステップ S 4 5において、 デコーダ 1 4 3は、 デコードした画像データをフレ ームメモリ 1 4 4に供給して記憶させ、 ステップ S 4 6に進む。 ステップ S 4 6 において、 表示制御部 1 4 5は、 ステップ S 4 5でフレームメモリ 1 4 4に記憶 された画像データを取得し、 ステップ S 4 7に進む。 ステップ S 4 7において、 表示制御部 1 4 5は、 ステップ S 4 6で取得した画像データに基づいて、 表示部 1 4 6に画像を表示させ、 処理を終了する。
—方、 ステップ S 4 3において、 デコーダ制御部 1 5 2からデコードが許可さ れていないと判定された場合、 処理がステップ S 4 8に進み、 表示制御部 1 4 5 は、 フレームメモリ 1 4 4に前のフレーム （いま表示すべきフレームの、 例えば、 1フレーム前のフレームなど） の画像データが存在するか否かを判定する。 ステ ップ S 4 8において、 フレームメモリ 1 4 4に前のフレームの画像データが存在 する （前のフレームの画像データを受信したとき、 ステップ S 4 5の処理が行な われた） と判定された場合、 ステップ S 4 9に進み、 表示制御部 1 4 5は、 前の フレームの画像 （フレームメモリ 1 4 4に記憶されている画像） を、 表示部 1 4 6に表示させ、 処理を終了する。
また、 ステップ S 4 8において、 フレームメモリ 1 4 4に前のフレームの画像 データが存在しないと判定された場合、 ステップ S 4 9をスキップして処理を終 了する。 従って、 この場合、 表示部 1 4 6には何も表示されない。
一方、 図 1 2のステップ S 3 6において、 通信部 1 4 1は、 受信制御部 1 4 7 から RTPバケツトの書き込みが許可されていないと判定した場合、 RTPバケツト をバッファに書きこまずに、 処理を終了する。 なお、 図 1 1および図 1 2の処理は、 サーバ 1 2から、 RTPパケットが送信さ れてこなくなるまで繰り返される。
次に、 図 1 4のフローチャートを参照して、 受信制御部 1 4 7における受信処 理について説明する。 このフローチャートは、 上述した図 1 1のステップ S 3 4 , S 3 5の処理を詳細に説明するものである。
ステップ S 6 1において、 受信制御部 1 4 7は、 通信部 1 4 1が、 図 1 1のス テツプ S 3 3の処理により、 フレーム情報を受信したか否かを判定する。 ステツ プ S 6 1において、 フレーム情報を受信したと判定された場合、 ステップ S 6 2 に進み、 受信制御部 1 4 7は、 画像情報保持部 1 4 8のフレーム情報保持部 1 5 0に、 通信部 1 4 1が受信したフレーム情報を供給して保持させ、 処理をステツ プ S 6 1に戻す。
また、 ステップ S 6 1において、 フレーム情報を受信していないと判定された 場合、 ステップ S 6 3に進み、 受信制御部 1 4 7は、 通信部 1 4 1が RTPパケ ットを受信したか否かを判定する。 ステップ S 6 3において、 画像データを受信 していないと判定された場合、 通信部 1 4 1が受信したデータは、 必要のないデ ータであるので、 受信制御部 1 4 7は、 以降の処理を行なわず、 処理をステップ S 6 1に戻し、 以下、 同様の処理を繰り返す。
また、 ステップ S 6 3において、 受信制御部 1 4 7は、 通信部 1 4 1が画像デ ータを受信したと判定した場合、 ステップ S 6 4に進み、 通信部 1 4 1が受信し た RTPパケットのタイムスタンプを検出する。 即ち、 RTPパケットは、 図 8に示 したフォーマッ トで送信されるので、 受信制御部 1 4 7は、 ヘッダの t imestamp 1 1 8に記述されたタイムスタンプの値を検出する。 なお、 このタイムスタンプ は、 図 3のステップ S 2の処理で初期化され、 図 4のステップ S 1 4で 1フレー ム毎に更新されるものである。
ここで、 図 1 6は、 通信部 1 4 1で受信される RTPパケットの例を、 横軸を 時間 tとして示している。 この例の場合、 1フレームは 9 0個の RTPパケット から構成されている。 通信部 1 4 1は、 タイムスタンプが 「1 0 0 0」 のフレー ムの画像データの RTPバケツト群 （シーケンス番号が 1乃至 9 0の RTPバケツ ト） を受信し、 その後は、 タイムスタンプが 「2 0 0 0」 のフレームの画像デー タの RTPパケット群 （シーケンス番号が 9 1乃至 1 8 0の RTPパケット） を受 信する。 そして、 通信部 1 4 1は、 タイムスタンプが 「3 0 0 0」 のフレームの 画像データの RTPパケット群 （シーケンス番号が 1 8 1乃至 2 7 0の RTPパケ ット） を受信し、 最後にタイムスタンプが 「4 0 0 0」 のフレームの画像データ の RTPパケット群 （シーケンス番号が 2 7 1乃至 3 6 0の RTPパケット） を受 信する。 なお、 図 1 6では、 シーケンス番号 1 3 1とシーケンス番号 1 9 1の RTPパケッ トは、 ロス （欠落） している。
図 1 4に戻り、 ステップ S 6 4の処理後は、 ステップ S 6 5に進み、 受信制御 部 1 4 7は、 前回のステップ S 6 4の処理で検出したタイムスタンプがあるか否 かを判定する。 ステップ S 6 5において、 前回検出したタイムスタンプがあると 判定された場合、 ステップ S 6 6に進み、 受信制御部 1 4 7は、 今回のステップ S 6 4の処理で検出したタイムスタンプが、 前回検出したタイムスタンプと一致 するか否かを判定する。
ステップ S 6 6において、 今回検出したタイムスタンプが前回のタイムスタン プと一致しないと判定された場合、 ステップ S 6 7に進み、 受信制御部 1 4 7は、 今回検出したタイムスタンプが、 前回のタイムスタンプより大きいか否かを判定 する。 ステップ S 6 7において、 今回検出したタイムスタンプが、 前回のタイム スタンプより大きくない （小さい） と判定された場合、 受信された画像データは、 既に受信され、 処理された画像データなので、 処理をステップ S 6 1に戻す。 また、 ステップ S 6 7において、 今回検出したタイムスタンプが、 前回のタイ ムスタンプより大きいと判定された場合、 またはステップ S 6 5で前回のタイム スタンプがないと判定された場合、 即ち、 通信部 1 4 1が受信した RTPパケッ トがフレームの最初の RTPパケットである場合、 受信制御部 1 4 7は、 処理を ステップ S 6 8に進め、 今回検出したタイムスタンプをエントリ情報蓄積部 1 4 9にェントリする。 例えば、 通信部 1 4 1において、 図 1 6に示した RTPパケッ トのシーケンス が受信される場合、 シーケンス番号 1の RTPパケットが受信されると、 この RTP パケットは、 フレーム内の最初のパケットであるので、 図 1 7に示すように、 タ ィムスタンプ 「1 0 0 0」 が配置されたェントリ情報がェントリ情報蓄積部 1 4 9にエントリ （登録） される。 なお、 エントリ情報は、 タイムスタンプ 1 8 1、 受信データ量 1 8 2、 フラグ 1 8 3から構成され、 フラグ 1 8 3は、 ロスが検出 されたか否かを示している （ステップ S 7 3の処理で後述する） 。 また、 受信デ ータ量 1 8 2は、 受信した 1フレーム内の RTPパケットの数を示し、 その 1フ レーム内の新たな RTPパケットを受信したとき、 インクリメントされる (後述 するステップ S 7 0の処理） 。
また、 図 1 6において、 シーケンス番号 9 1の RTP パケッ トが受信されると、 その RTPパケッ トのタイムスタンプは、 前回のタイムスタンプ 「 1 0 0 0」
(シーケンス番号 9 0のタイムスタンプ） より大きいので、 新たなタイムスタン プ 「2 0 0 0」 がエントリ情報蓄積部 1 4 9にエントリされ、 図 1 8に示される ようなェントリ情報がェントリ情報蓄積部 1 4 9に保持される。
図 1 8では、 受信されたタイムスタンプ 1 8 1力 S 「 1 0 0 0」 の画像データが、 シーケンス番号 1乃至 9 0の RTPパケットから構成され、 ロスはないので、 受 信データ量 1 8 2が 「9 0」 となっており、 フラグ 1 8 3は、 ロスがないことを 示す 「0」 となっている。 そして、 シーケンス番号 9 1の RTPパケットが新た に受信されたので、 タイムスタンプ 1 8 1に 「2 0 0 0」 がエントリされている c 図 1 5に戻り、 ステップ S 6 8の処理後は、 ステップ S 6 9に進み、 受信制御 部 1 4 7は、 通信部 1 4 1が受信した RTPパケッ トのシーケンス番号 （図 8の フォーマツ トの sequence 1 1 7に記述された番号） に基づいて、 RTPパケット がロスしているか否かを判定する。 即ち、 ステップ S 6 9では、 通信部 1 4 1が 今回受信した RTPパケットのシーケンス番号が、 前回受信した RTPパケットの シーケンス番号の次の番号である場合、 RTPバケツトがロスしていないと判定さ れ、 次の番号ではない場合、 RTPパケッ トがロスしている （送信エラーにより、 RTPパケットが欠落している） と判定される。 ステップ S 6 9において、 RTPパ ケットがロスしていないと判定された場合は、 ステップ S 7 0に進み、 ロスして いると判定された場合は、 ステップ S 7 3に進む。
一方、 図 1 4のステップ S 6 6において、 今回検出したタイムスタンプが、 前 回のタイムスタンプと一致すると判定された場合、 ステップ S 7 2に進み、 受信 制御部 1 4 7は、 RTPパケットがロスしている （シーケンス番号が続き番号では ない） か否か、 またはエントリ情報蓄積部 1 4 9のフラグ 1 8 2が 「1」 である (前回までにロスが検出された） か否かを判定する。
ステップ S 7 2の処理において、 ロスが検出されず、 フラグ 1 8 2が 「1」 で はない （ 「0」 である） と判定された場合、 図 1 5のステップ S 7 0に進み、 受 信制御部 1 4 7は、 ェントリ情報蓄積部 1 4 9の受信データ量 1 8 2を 1だけィ ンクリメントする。
例えば、 シーケンス番号 9 1の RTPパケットが受信され、 これにより、 ステ ップ S 6 8の処理で、 ェントリ情報蓄積部 1 4 9に、 図 1 8に示したェントリ情 報が保持された場合、 ロスがないので、 ェントリ情報蓄積部 1 4 9には、 図 1 9 に示すエントリ情報が保持される。 即ち、 タイムスタンプ 1 8 1が 「2 0 0 0」 の受信デ^ "タ量 1 8 2は、 「0」 から 「1」 にインクリメントされる。
また、 図 1 6のケースで、 シーケンス番号 1乃至 9 4までが正常に受信されて いる場合、 エントリ情報蓄積部 1 4 9のタイムスタンプ 「2 0 0 0 j の受信デー タ量 1 8 2は、 「4」 となっている。 その後、 シーケンス番号 9 5が受信される と、 受信データ量 1 8 2は、 インクリメントされ、 「5」 となる。
図 1 5に戻り、 ステップ S 7 0の処理後は、 ステップ S 7 1に進み、 受信制御 部 1 4 7は、 通信部 1 4 1にバッファ 1 4 2への RTPバケツトの書き込みを許 可し、 処理を終了する。 したがって、 通信部 1 4 1は、 図 1 1のステップ S 3 7 の処理を行なって、 受信した画像データ （RTPパケット） をバッファ 1 4 2に書 き込み、 以降の処理を行なう。 —方、 図 1 4のステップ S 7 2において、 RTPパケットがロスしていると判定 された場合、 またはフラグ 1 8 3力 S 「1」 であると判定された場合、 受信制御部 1 4 7は、 処理をステップ S 7 3に進め、 エントリ情報蓄積部 1 4 9のフラグを 「1」 に設定し、 処理を終了する。 このとき、 受信制御部 1 4 7は、 通信部 1 4 1にバッファ 1 4 2への RTPパケットの書き込みを許可しない。 従って、 この 場合、 通信部 1 4 1は、 RTPパケットをバッファ 1 4 2に書き込まない。
例えば、 図 1 6に示した画像データのシーケンス番号 1 3 2の ^?パケット が受信された場合、 シーケンス番号 1 3 1の RTP パケットがロスしているので、 エントリ情報蓄積部 1 4 9に保持されたエントリ情報は、 図 2 0に示すように、 フラグ 1 8 3力 S 「0」 力、ら 「 1」 に変更される。 なお、 RTPパケットはバッファ 1 4 2に書き込まれないので、 受信データ量 1 8 2は、 変更されない。
また、 図 1 6に示した画像データのシーケンス番号 1 3 3の RTPバケツトが 受信された場合も、 フラグが 「1」 である （ロスしている RTPパケットがあ る） ので、 エントリ情報蓄積部のフラグ 1 8 3は 「1」 のままであり、 RTPパケ ットはバッファ 1 4 2に書き込まれないので、 受信データ量 1 8 2も 「4 0」 の まま変更されない。
上述の処理は、 全ての画像データが受信されるまで、 パケッ ト毎に行われる。 図 1 6に示されるような画像データが通信部 1 4 1で受信された場合のェント リ情報蓄積部 1 4 9のエントリ情報の例を図 2 1に示す。
この例の場合、 タイムスタンプが 「 1 0 0 0」 のフレームは、 9 0個のパケッ トから構成され、 ロスがないので、 タイムスタンプ 1 8 1力 S 「 1 0 0 0」 の受信 データ量 1 8 2は、 「9 0 J となり、 フラグ 1 8 3は、 「0」 となる。 また、 タ ィムスタンプが 「2 0 0 0」 のフレームは、 シーケンス番号 1 3 1の RTPパケ ットがロスしているので、 シーケンス番号 9 1乃至 1 3 0の RTPバケツ トのみ が書き込みを許可され （ステップ S 7 0， S 7 1の処理） 、 タイムスタンプ 1 8 1力 S 「2 0 0 0」 の受信データ量は、 「4 0」 となる。 また、 このとき、 RTPパ ケットのロスが検出されるので、 フラグ 1 8 3は、 「1」 となる。 同様に、 タイムスタンプ 「3 0 0 0」 のフレームは、 1 9 1の RTPパケット がロスしているので、 シーケンス番号 1 8 1乃至 1 9 0の RTPパケットのみが 書き込みを許可され、 タイムスタンプ 1 8 1力 S 「3 0 0 0」 の受信データ量は、 「1 0」 となり、 ロスが検出されたので、 フラグ 1 8 3は、 「1」 となる。 タイ ムスタンプ 「4 0 0 0」 のフレームは、 ロスがないので、 全ての RTPパケット がバッファ 1 4 2に書き込まれ、 受信データ量 1 8 2は、 「9 0」 となり、 フラ グ 1 8 3は、 「0」 となる。
図 1 4と図 1 5の処理により、 受信制御部 1 4 7は、 ロスするまでの画像デー タ （ロスのない画像データ） のみをバッファ 1 4 2に書き込む。
このように、 シーケンス番号を検出することにより、 ロスを検出することがで きる。 また、 ロスの検出の有無を示すフラグを判定することにより、 ロスが検出 されるまでの画像データのみを確実に保持することができる。
次に、 図 2 2のフローチャートを参照して、 デコーダ制御部 1 5 2におけるデ コード判断処理について説明する。 このフローチャートは、 上述した図 1 2のス テツプ S 3 9乃至 S 4 2の処理を詳細に説明するものである。
ステップ S 9 1において、 デコーダ制御部 1 5 2は、 デコーダ 1 4 3のデコー ド対象のタイムスタンプを、 初期値 （いまの場合、 「1 0 0 0」 ） に設定し、 ス テツプ S 9 2に進む。 ステップ S 9 2において、 デコーダ制御部 1 5 2は、 閾値 保持部 1 5 1から、 図 1 1のステップ S 3 2の処理で保持されたデータ量 （RTP パケット数） または画質の閾値を取得し、 ステップ S 9 3に進む。
ステップ S 9 3において、 デコーダ制御部 1 5 2は、 画像情報保持部 1 4 8力 ら画像情報を取得する。 即ち、 エントリ情報蓄積部 1 4 9からエントリ情報 （図 2 1 ) を取得し、 フレーム情報保持部 1 5 0からフレーム情報 （図 5 ) を取得す る。
ステップ S 9 3の処理の後は、 ステップ S 9 4に進み、 デコーダ制御部 1 5 2 は、 デコーダ 1 4 3の不図示のタイマを所定時間 （1フレーム分の画像データを 取得するのに必要な時間） に設定し、 開始させ、 ステップ S 9 5に進む。 ステツ プ S 9 5において、 デコーダ制御部 1 5 2は、 デコーダ 1 4 3を制御し、 バッフ ァ 1 4 2から画像データを取得し、 ステップ S 9 6に進む。 ステップ S 9 6にお いて、 デコーダ制御部 1 5 2は、 タイマが終了したか否かを判定し、 タイマが終 了するまでステップ S 9 5の処理を繰り返す。
ステップ S 9 6の処理において、 タイマが終了した （1フレーム分の RTPパ ケットが取得された） 場合、 デコーダ制御部 1 5 2は、 処理をステップ S 9 6か ら S 9 7に進める。
ステップ S 9 7において、 エントリ情報蓄積部 1 4 9から取得された （ステツ プ S 9 3 ) 受信データ量 1 8 2が、 閾値保持部 1 5 1から取得された （ステップ S 9 2 ) 閾値より大きいか否かを判定する。
デコーダ制御部 1 5 2は、 閾値保持部 1 5 1に保持された閾値が画質である場 合、 フレーム情報保持部 1 5 0で保持された、 フレーム情報のバケツト数 5 2と 画質 5 3の関係からパケット数の閾値を決定し、 閾値より大きいか否かを判定す る。
このように、 フレーム情報をサーバ 1 2からクライアント 1 3に送信すること により、 フレーム情報が画像に応じて変更される場合であっても、 ユーザが画質 の閾値を決定しておくだけで、 自動的にパケット数の閾値が決定され、 画質の良 い画像を表示させることができる。
図 2 2に戻り、 ステップ S 9 7の処理において、 受信データ量 1 8 2が閾値よ り大きいと判定された場合、 デコーダ制御部 1 5 2はステップ S 9 8に進み、 デ コーダ 1 4 3にデコードを許可し、 ステップ S 9 9に進む。 したがって、 デコー ダ 1 4 3は、 図 1 3のステップ S 4 4の処理により、 取得した画像データをデコ 一ドし、 表示部 1 4 6に表示することができる。
一方、 ステップ S 9 7において、 デコーダ制御部 1 5 2は、 受信データ量 1 8 2が閾値以下であると判定された場合、 ステップ S 9 8をスキップし、
S 9 9に進む。 したがって、 デコーダ 1 4 3は、 デコードを許可されない ステップ S 9 9において、 デコーダ制御部 1 5 2は、 デコード対象のタイムス タンプを次のフレームのタイムスタンプ （いまの場合、 「2 0 0 0」 ） に更新す る。
上述の処理は、 全ての画像がデコードされるまで、 フレーム毎に繰り返される。 例えば、 図 2 1に示されるようなェントリ情報がェントリ情報蓄積部 1 4 9に 保持されており、 閾値保持部 1 5 1に保持された閾値が 「3 0」 であった場合、 タイムスタンプが 「1 0 0 0」 と 「2 0 0 0」 のフレームは、 受信データ量 1 8 2がそれぞれ 「9 0」 と 「4 0」 であり、 閾値 「3 0」 より大きいので、 デコー ドが許可される。 し力 しながら、 タイムスタンプ 「3 0 0 0」 のフレームは、 受 信データ量 1 8 2が 「1 0」 であり、 閾値 「3 0」 以下であるので、 デコードは 許可されない。 そして、 タイムスタンプが 「4 0 0 0」 のフレームは、 受信デー タ量 1 8 2力 S 「9 0」 であり、 閾値 「3 0」 より大きいので、 デコードが許可さ れる。 即ち、 デコードされる画像データは、 タイムスタンプが 「1 0 0 0」 、 「2 0 0 0」 、 「4 0 0 0」 のデータである。
したがって、 タイムスタンプ 「3 0 0 0」 の画像データを表示部 1 4 6に表示 させようとするとき、 図 1 3のステップ S 4 9の処理により、 タイムスタンプ 「2 0 0 0」 の画像データの画像 （前のフレームの画像） が表示される。
このように、 受信データ量に基づいて、 デコーダが制御されるので、 受信デー タ量の少ない （画質の悪い） 画像のデコードを禁止し、 画質の良い画像のみを表 示することができる。
なおヽ 画質の単位ま、 「bpp」 を用!/ヽたカ S 「PSNR (per— square—noi se—rat io) 等、 画質を表す単位であればよい。
上述した一連の処理は、 ハードウェアにより実行させることもできるし、 ソフ トウエアにより実行させることもできる。 この場合、 上述した処理は、 図 2 3に 示されるようなパーソナルコンピュータ 6 0 0により実行される。
図 2 3 こおレヽて、 CPU (Central Process ing Uni t) 6 0 1 fま、 ROM (Read Only Memory) 6 0 2に記憶されているプログラム、 または、 記憶部 6 0 8から RAM (Random Access Memory) 6 0 3にロードされたプログラムに従って各種の 処理を実行する。 RAM 6 0 3にはまた、 CPU 6 0 1が各種の処理を実行する上に おいて必要なデータなどが適宜記憶される。
CPU 6 0 1、 R0M 6 0 2、 および RAM 6 0 3は、 内部バス 6 0 4を介して相互に 接続されている。 この内部バス 6 0 4にはまた、 入出力インターフェース 6 0 5 も接続されている。
入出力ィンターフェース 6 0 5には、 キーボード、 マウスなどよりなる入力部 6 0 6、 CRT , LCD (Liqui d Crystal Di splay) などよりなるディスプレイ、 並 ぴにスピーカなどよりなる出力部 6 0 7、 ハードディスクなどより構成される記 憶部 6 0 8、 モデム、 ターミナルアダプタなどより構成される通信部 6 0 9が接 続されている。 通信部 6 0 9は、 電話回線や CATVを含む各種のネットワークを 介しての通信処理を行なう。
入出力ィンターフェース 6 0 5にはまた、 必要に応じてドライブ 6 1 0が接続 され、 磁気ディスク、 光ディスク、 光磁気ディスク、 あるいは半導体メモリなど によりなるリムーパプルメディア 6 2 1が適宜装着され、 それから読み出された コンピュータプログラムが、 必要に応じて記憶部 6 0 8にインストーノレされる。 一連の処理をソフトウェアにより実行させる場合には、 そのソフトウェアを構 成するプログラムが、 専用のハードウェアに組み込まれているコンピュータ、 ま たは、 各種のプログラムをインス トールすることで、 各種の機能を実行すること が可能な、 例えば、 汎用のパーソナルコンピュータなどに、 ネットワークや記録 媒体からインス トールされる。
この記録媒体は、 図 2 3に示されるように、 コンピュータとは別に、 ユーザに プログラムを提供するために配布される、 プログラムが記録されているリムーバ プルメディア 6 2 1よりなるパッケージメディアにより構成されるだけでなく、 装置本体に予め組み込まれた状態でユーザに提供される、 プログラムが記録され ている ROM 6 0 2や記憶部 6 0 8が含まれるハードディスクなどで構成される。 なお、 本明細書において、 コンピュータプログラムを記述するステップは、 記 載された順序に従って時系列的に行われる処理はもちろん、 必ずしも時系列的に 処理されなくとも、 並列的あるいは個別に実行される処理をも含むものである。 また、 本明細書において、 システムとは、 複数の装置により構成される装置全 体を表わすものである。 産業上の利用可能性
以上の如く、 第 1の本願発明によれば、 送信されたコンテンツを受信するシス テムを実現することができる。 特に、 送信時にコンテンツが欠落した場合におい ても、 良質な画像を表示させることができる。
第 2の本願発明によれば、 良質なコンテンツを表示させることができる。 特に、 送信時にコンテンツが欠落した場合においても、 良質な画像を表示させることが できる。
第 3の本願発明によれば、 良質なコンテンツを表示させることができる。 特に、 送信時にコンテンツが欠落した場合においても、 良質な画像のみを選択し、 表示 させることができる。

Claims

請求の範囲
1 . コンテンツを送信する送信装置と、 前記コンテンツを受信する受信装置と からなる送受信システムにおいて、
前記送信装置は、
前記コンテンツを階層符号にし、 複数のレイヤの符号化データを出力する符 号化手段と、
前記複数のレイヤの符号化データをバケツト化し、 前記符号化データの低域 情報からバケツトを出力するバケツト化手段と、
前記パケットを送信する送信手段と
を備え、
前記受信装置は、
前記送信装置から送信されてくる前記バケツトを受信する受信手段と、 前記受信手段により受信された前記パケットを保持する保持手段と、 前記受信手段が受信した前記バケツトの、 前記保持手段への書き込みを制御 する書き込み制御手段と、
前記送信装置により送信されてくる前記バケツトにバケツトロスがあるか否 かを判定する判定手段と
を備え、
前記書き込み制御手段は、 前記コンテンツの 1フレーム内に、 パケットロス がある場合、 前記 1フレーム内のパケットロスが生じるまでの前記パケットを、 前記保持手段に書き込み、 前記 1フレームの残りの前記バケツトを前記保持手 段に書き込まない
ことを特徴とする送受信システム。
2 . 前記保持手段に保持された前記バケツトに配置された前記符号化データの デコードを制御するデコード制御手段と、
前記符号化データをデコードするデコード手段と、
前記デコード手段のデコードに関する閾値を保持する閾値保持手段と をさらに備え、
前記デコード制御手段は、 前記デコード手段によるデコードを、 前記閾値に基 づいて制御する
ことを特徴とする請求の範囲第 1項に記載の送受信システム。
3 . 前記送信装置は、 前記複数のレイヤ毎の前記符号化データのパケット数と、 前記符号化データをデコードすることにより得られる画像の画質に関する情報を 含むフレーム情報をさらに送信し、
前記受信手段は、 前記フレーム情報をさらに受信し、
前記デコード制御手段は、 前記閾値保持手段に保持された前記閾値と前記フレ ーム情報に基づいて、 前記デコード手段によるデコードを制御する
ことを特徴とする請求の範囲第 2項に記載の送受信システム。
4 . コンテンツを送信する送信装置と、 前記コンテンツを受信する受信装置と からなる送受信システムの送受信方法において、
前記送信装置の送信方法は、
前記コンテンツを階層符号にし、 複数のレイヤの符号化データを出力する符 号化ステップと、
前記複数のレイヤの符号化データをバケツト化し、 前記符号化データの低域 情報からバケツトを出力するバケツト化ステップと、
前記バケツトを送信する送信ステップと
を含み、
前記受信装置の受信方法は、
前記送信装置から送信されてくる前記パケットを受信する受信ステップと、 前記受信ステップの処理が受信した前記バケツトの書き込みを制御する書き 込み制御ステップと、
前記送信装置により送信されてく る前記パケットにバケツトロスがあるか否 かを判定する判定ステップと
を含み、 前記書き込み制御ステップは、 前記コンテンツの 1フレーム内に、 パケット ロスがある場合、 前記 1フレーム内のバケツ トロスが生じるまでの前記バケツ ト を書き込み、 前記 1フレームの残りの前記バケツトを書き込まない
ことを特徴とする送受信方法。
5 . コンテンツを階層符号にし、 複数のレイヤの符号化データを出力する符号 化手段と、
前記複数のレイヤの符号化データをパケット化し、 前記符号化データの低域情 報からバケツトを出力するバケツト化手段と、
前記複数のレイヤ毎の前記符号化データのパケット数と、 前記符号化データを デコードすることにより得られる画像の画質に関する情報を含むフレーム情報を 保持する保持手段と、
前記バケツトと前記フレーム情報を送信する送信手段とを備え、
前記符号化手段は、 前記フレーム情報に基づいて、 前記コンテンツを階層符号 にし、 前記パケット化手段は、 前記フレーム情報に基づいて、 前記複数のレイヤ の符号化データをパケット化するることを特徴とする送信装置。
6 . コンテンツを階層符号にし、 複数のレイヤの符号化データを出力する符号 化ステップと、
前記複数のレイヤの符号化データをバケツト化し、 前記符号化データの低域情 報からバケツトを出力するバケツト化ステップと、
前記複数のレイヤ毎の前記符号化データのパケット数と、 前記符号化データを デコードすることにより得られる画像の画質に関する情報を含むフレーム情報を 保持する保持ステップと、
前記バケツトと前記フレーム情報を送信する送信ステップとを含み、 前記符号化ステップは、 前記フレーム情報に基づいて、 前記コンテンツを階層 符号にし、 前記パケット化ステップは、 前記フレーム情報に基づいて、 前記複数 のレイヤの符号化データをバケツト化する
ことを特徴とする送信方法。
7 . コンテンツを送信するプログラムであって、
コンテンッを階層符号にし、 複数のレイャの符号化データを出力する符号化ス テツプと、
前記複数のレイヤの符号化データをバケツト化し、 前記符号化データの低域情 報からバケツトを出力するバケツト化ステップと、
前記バケツトと保持された前記複数のレイヤ毎の前記符号化データのバケツト 数と、 前記符号化データをデコードすることにより得られる画像の画質に関する 情報を含むフレーム情報を送信する送信ステップとを含み、
前記符号化ステップは、 前記フレーム情報に基づいて、 前記コンテンツを階層 符号にし、 前記パケット化ステップは、 前記フレーム情報に基づいて、 前記複数 のレイャの符号化データをパケット化する
ことを特徴とするコンピュータが読み取り可能なプログラムが格納されている プログラム格納媒体。
8 . コンテンツを送信するプログラムであって、
コンテンッを階層符号にし、 複数のレイャの符号化データを出力する符号化ス 前記複数のレイヤの符号化データをバケツト化し、 前記符号化データの低域情 報からバケツトを出力するパケット化ステップと、
前記バケツトと保持された前記複数のレイヤ毎の前記符号化データのバケツト 数と、 前記符号化データをデコードすることにより得られる画像の画質に関する 情報を含むフレーム情報を送信する送信ステップとを含み、
前記符号化ステップは、 前記フレーム情報に基づいて、 前記コンテンツを階層 符号にし、 前記パケット化ステップは、 前記フレーム情報に基づいて、 前記複数 のレイヤの符号化データをバケツト化する
処理をコンピュータに実行させることを特徴とするプログラム。
9 . コンテンツを階層符号化して得られる複数のレイヤの符号化データをパケ ット化したバケツトを送信する送信装置から送信されてくる前記バケツトを受信 する受信装置において、
前記送信装置から送信されてくる前記バケツトを受信する受信手段と、 前記受信手段により受信された前記バケツトを保持する保持手段と、 前記受信手段が受信した前記バケツトの、 前記保持手段への書き込みを制御す る書き込み制御手段と、
前記送信装置により送信されてくる前記バケツトにバケツトロスがあるか否か を判定する判定手段とを備え、
前記書き込み制御手段は、 前記コンテンツの 1フレーム内に、 パケットロスが ある場合、 前記 1フレーム内のパケットロスが生じるまでの前記パケットを、 前 記保持手段に書き込み、 前記 1 フレームの残りの前記バケツトを前記保持手段 に書き込まない
ことを特徴とする受信装置。
1 0 . 前記保持手段に保持された前記バケツトに配置された前記符号化データ のデコードを制御するデコ一ド制御手段と、
前記符号化データをデコードするデコード手段と、
前記デコード手段のデコードに関する閾値を保持する閾値保持手段とをさらに 備え、
前記デコード制御手段は、 前記デコード手段によるデコードを、 前記閾値に基 づいて制御する
ことを特徴とする請求の範囲第 9項に記載の受信装置。
1 1 . 前記送信装置は、 前記複数のレイヤ毎の前記符号化データのパケット数 と、 前記符号化データをデコードすることにより得られる画像の画質に関する情 報を含むフレーム情報をさらに送信し、
前記受信手段は、 前記フレーム情報をさらに受信し、 前記デコード制御手段は、 前記閾値保持手段に保持された前記閾値と前記フレ ーム情報に基づいて、 前記デコード手段によるデコードを制御する
ことを特徴とする請求の範囲第 1 0項に記載の受信装置。
1 2 . 前記デコード手段によりデコードされた前記コンテンツを記憶する記億 手段と、
前記コンテンツの表示を制御する表示制御手段と、
前記コンテンツを表示する表示手段とをさらに備え、
前記表示制御手段は、 前記デコード制御手段により前記符号化データのデコー ドが許可されない場合、 その符号化データに対応するコンテンッより前に前記記 憶手段に記憶された前記コンテンツを表示手段に表示させる
ことを特徴とする請求の範囲第 1 0項に記載の受信装置。
1 3 . コンテンツを階層符号化して得られる複数のレイヤの符号化データをパ ケット化したバケツトを送信する送信装置から送信されてくる前記バケツトを受 信する受信装置の受信方法において、
前記送信装置から送信されてくる前記バケツトを受信する受信ステップと、 前記受信ステップの処理により受信された前記パケットの書き込みを制御する 書き込み制御ステップと、
前記送信装置により送信されてくる前記バケツトにパケットロスがあるか否か を判定する判定ステップとを含み、
前記書き込み制御ステップの処理は、 前記コンテンツの 1フレーム內に、 パケ ットロスがある場合、 前記 1フレーム内のバケツ トロスが生じるまでの前記パケ ットを書き込み、 前記 1フレームの残りの前記バケツトを書き込まない
ことを特徴とする受信方法。
1 4 . コンテンツを階層符号化して得られる複数のレイヤの符号化データをパ ケット化したパケットを送信する送信装置から送信されてくる前記バケツトを受 信するプログラムであって、
前記送信装置から送信されてくる前記パケットを受信する受信ステップと、 前記受信ステップの処理により受信された前記パケットの書き込みを制御する 書き込み制御ステップと、 '
前記送信装置により送信されてくる前記バケツトにバケツトロスがあるか否か を判定する判定ステップとを含み、
前記書き込み制御ステップの処理は、 前記コンテンツの 1フレーム内に、 パケ ットロスがある場合、 前記 1フレーム内のバケツトロスが生じるまでの前記パケ ットを書き込み、 前記 1 フレームの残りの前記バケツトを書き込まない
ことを特徴とするコンピュータが読み取り可能なプログラムが格納されている プログラム格納媒体。
1 5 . コンテンツを階層符号化して得られる複数のレイヤの符号化データをパ ケット化したバケツトを送信する送信装置から送信されてくる前記バケツトを受 信するプログラムであって、
前記送信装置から送信されてくる前記パケットを受信する受信ステップと、 前記受信ステップの処理により受信された前記バケツトの書き込みを制御する 書き込み制御ステップと、
前記送信装置により送信されてくる前記バケツトにバケツトロスがあるか否か を判定する判定ステップとを含み、
前記書き込み制御ステップの処理は、 前記コンテンツの 1フレーム内に、 パケ ットロスがある場合、 前記 1フレーム内のバケツトロスが生じるまでの前記パケ ットを書き込み、 前記 1 フレームの残りの前記パケットを書き込まない
処理をコンピュータに実行させることを特徴とするプログラム。
PCT/JP2003/012757 2002-12-11 2003-10-06 送受信システム、送信装置および送信方法、受信装置および受信方法、記録媒体、並びにプログラム WO2004054266A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
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

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2002-358945 2002-12-11
JP2002358945A JP4406816B2 (ja) 2002-12-11 2002-12-11 受信装置および受信方法、記録媒体、並びにプログラム

Publications (1)

Publication Number Publication Date
WO2004054266A1 true WO2004054266A1 (ja) 2004-06-24

Family

ID=32500914

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2003/012757 WO2004054266A1 (ja) 2002-12-11 2003-10-06 送受信システム、送信装置および送信方法、受信装置および受信方法、記録媒体、並びにプログラム

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)

* Cited by examiner, † Cited by third party
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 华为技术有限公司 一种时间标签跳变的检测处理方法和装置
CN102714728B (zh) * 2010-01-14 2015-04-29 住友电气工业株式会社 视频图像编码数据的显示方法、设备和通信系统
JP2015012580A (ja) * 2013-07-02 2015-01-19 キヤノン株式会社 受信装置、受信方法及びプログラム
WO2015053596A1 (ko) * 2013-10-12 2015-04-16 삼성전자 주식회사 멀티 레이어 비디오의 복호화 및 부호화를 위한 버퍼 관리 방법 및 장치
JP2016126037A (ja) 2014-12-26 2016-07-11 ソニー株式会社 信号処理装置、および信号処理方法、並びにプログラム
US10887663B2 (en) * 2015-01-24 2021-01-05 Valens Semiconductor Ltd. Smooth switching of video sources sharing a common link

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1311125A2 (en) * 2001-11-12 2003-05-14 Sony Corporation Data communication system and method, data transmission apparatus and method, data receiving apparatus, received-data processing method and computer program
JP2003209839A (ja) * 2001-11-08 2003-07-25 Sony Corp 伝送フォーマット、並びに通信制御装置および方法
JP2003244676A (ja) * 2002-02-19 2003-08-29 Sony Corp 動画配信システム、動画配信装置および方法、記録媒体、並びにプログラム

Family Cites Families (8)

* Cited by examiner, † Cited by third party
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 三洋電機株式会社 画像処理方法とその方法を利用可能な画像符号化装置および画像復号装置
JP3757857B2 (ja) * 2001-12-12 2006-03-22 ソニー株式会社 データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003209839A (ja) * 2001-11-08 2003-07-25 Sony Corp 伝送フォーマット、並びに通信制御装置および方法
EP1311125A2 (en) * 2001-11-12 2003-05-14 Sony Corporation Data communication system and method, data transmission apparatus and method, data receiving apparatus, received-data processing method and computer program
JP2003244676A (ja) * 2002-02-19 2003-08-29 Sony Corp 動画配信システム、動画配信装置および方法、記録媒体、並びにプログラム

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
EDWARDS, E ET AL: "RTP Payload Format for JPEG 2000 Video Streams", 22 December 2003 (2003-12-22), XP002975111, Retrieved from the Internet <URL:http://www.ietf.org/proceedings/03mar/I-D/draft-ietf-avt-rtp-jpeg2000-02.txt> *
EDWARDS, E ET AL: "RTP Payload Format for JPEG 2000 video streams", 24 December 2003 (2003-12-24), XP002975112, Retrieved from the Internet <URL:http//www.ietf.org/proceedings/01dec/slides/avt-8/> *
KELLER, R. ET AL: "An active Router Architecture for Multicast Video Distribution", PROC. OF INFOCOM 2000, vol. 3, 26 March 2000 (2000-03-26), pages 1137 - 1146, XP001044207 *
OKUMURA SEIJI ET AL: "The Method of the QoS control on a MPEG-4 over RTP Delivery System", DICOMO'2000, 28 June 2000 (2000-06-28), pages 433 - 438, XP002976272 *
See also references of EP1473939A4 *

Also Published As

Publication number Publication date
KR100982637B1 (ko) 2010-09-15
US20050105557A1 (en) 2005-05-19
EP1473939A1 (en) 2004-11-03
JP2004193924A (ja) 2004-07-08
US7593424B2 (en) 2009-09-22
JP4406816B2 (ja) 2010-02-03
EP1473939A4 (en) 2011-10-05
KR20050084770A (ko) 2005-08-29

Similar Documents

Publication Publication Date Title
TW520606B (en) A method and apparatus for streaming scalable video
JP4479650B2 (ja) コミュニケーションシステム、端末装置及びコンピュータプログラム
JP4965059B2 (ja) ビデオストリームの切り替え
KR100945548B1 (ko) 비디오 오류 회복
TWI364220B (en) A video processing method and a video system
JP4850932B2 (ja) 画像伝送装置
EP2129126A1 (en) Transmission apparatus, transmission method, and reception apparatus
KR20010020498A (ko) 네트웍을 통한 적합한 비디오/오디오의 전송을 위한 시스템
US8214708B2 (en) Video transmitting apparatus, video receiving apparatus, and video transmission system
WO2004054266A1 (ja) 送受信システム、送信装置および送信方法、受信装置および受信方法、記録媒体、並びにプログラム
JP2003284037A (ja) マルチメディアデータ受信装置及び方法、マルチメディアデータ送信装置及び方法
US20040001091A1 (en) Method and apparatus for video conferencing system with 360 degree view
JP2007274443A (ja) 画像伝送方法、送信装置、受信装置及び画像伝送システム
US20080104659A1 (en) Prioritized real-time data transmission
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
JP2005051299A (ja) パケット送信装置、パケット受信装置、パケット送信方法及びパケット受信方法
US7558323B2 (en) Video data transmission method for changing transmission data amounts in accordance with a transmission speed and a transmission system therefor
JP2006295601A (ja) 通信システム、送信装置および方法、受信装置および方法、並びにプログラム
JP2004266741A (ja) 配信システム、送信装置および方法、受信装置および方法、記録媒体、並びにプログラム
JP4876427B2 (ja) 通信システム、送信装置、送信方法、受信装置、受信方法、およびプログラム
JP4541758B2 (ja) 画像伝送装置
JP2005136545A (ja) 送信装置および方法、プログラム格納媒体、並びにプログラム
JP2004015585A (ja) 動画像印刷装置、動画像印刷方法、およびコンピュータプログラム
Montelius et al. Streaming Video in Wireless Networks: Service and Technique

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): KR US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR

REEP Request for entry into the european phase

Ref document number: 2003748711

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2003748711

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 1020047012281

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 10504483

Country of ref document: US

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWP Wipo information: published in national office

Ref document number: 2003748711

Country of ref document: EP