[go: up one dir, main page]

WO2010092848A1 - 映像品質推定装置および映像品質推定方法 - Google Patents

映像品質推定装置および映像品質推定方法 Download PDF

Info

Publication number
WO2010092848A1
WO2010092848A1 PCT/JP2010/050309 JP2010050309W WO2010092848A1 WO 2010092848 A1 WO2010092848 A1 WO 2010092848A1 JP 2010050309 W JP2010050309 W JP 2010050309W WO 2010092848 A1 WO2010092848 A1 WO 2010092848A1
Authority
WO
WIPO (PCT)
Prior art keywords
video
packet
data
fec
continuity
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2010/050309
Other languages
English (en)
French (fr)
Inventor
尚司 谷内田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NEC Corp filed Critical NEC Corp
Priority to US13/003,844 priority Critical patent/US8254464B2/en
Publication of WO2010092848A1 publication Critical patent/WO2010092848A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N17/00—Diagnosis, testing or measuring for television systems or their details
    • H04N17/004—Diagnosis, testing or measuring for television systems or their details for digital television systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0045—Arrangements at the receiver end
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/20—Arrangements for detecting or preventing errors in the information received using signal quality detector
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/47202—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting content on demand, e.g. video on demand
    • 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/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet

Definitions

  • the present invention relates to a video quality estimation apparatus, a video quality estimation method, and a program for monitoring the quality of video data, and in particular, a video quality estimation apparatus for monitoring the quality of video data distributed in an IPTV service, and The present invention relates to a video quality estimation method.
  • Terrestrial analog broadcasting is supposed to stop in 2011 in Japan. For this reason, there is a demand for smooth transition from analog terrestrial broadcasting to digital terrestrial broadcasting by 2011, and to make the coverage of digital terrestrial broadcasting 100% for the terrestrial analog broadcast viewable area.
  • IPTV Internet Protocol Television
  • NGN Next Generation Network
  • the IPTV service is a service form for distributing digital television broadcasting via an IP network.
  • the broadcast viewable area is calculated based on the strength of radio waves transmitted from the transmitting station, buildings, topography, and the like. Furthermore, video quality tests were performed at several observation points in the viewable area, and the video quality was monitored by comparing the test results with the theoretical video quality calculation results.
  • IPTV service a plurality of providers intervene from when the content is transmitted until it is received by the TV receiver at each home. For this reason, it is necessary to monitor the video quality between the providers.
  • FIG. 1 is an explanatory diagram showing monitoring points in the ITU-T recommendation.
  • FIG. 1 shows monitoring points PT1 to PT5.
  • a communication system for providing an IPTV service includes a content provider 101, a service provider (central headend) 102, and a local content supplement stage (Local content acquisition). ) 103, a service provider (regional headend) 104, a network provider 105, and an end user 106.
  • the video data is distributed to the end user 106 through a path consisting of the content provider 101, the service provider 102 and the network provider 105, or a path consisting of the local content supplement stage 103, the service provider 104 and the network provider 105.
  • the monitoring point PT1 is provided between the content provider 101 and the service provider 102, or between the local content supplementing stage 103 and the service provider 104.
  • the monitoring point PT2 is provided between the service provider 102 and the IP core network 105a in the network provider 105, or between the service provider 104 and the IP core network 105a.
  • the monitoring point PT3 is provided between the IP core network 105a and the IP access network 105b in the network provider 105.
  • the monitoring point PT4 is provided between the VOD (Video on Demand) server (Edge VOD Server / multicast replication point) 105c on the IP access network 105b and the gateway (Home Gateway) 106a of the end user 106.
  • the monitoring point PT5 is provided between the STB (Set-top box) 106b of the end user 106 and the TV 106c of the end user 106.
  • FIG. 2 is a block diagram showing the configuration of a video quality monitoring apparatus for realizing this monitoring method.
  • the IP packet header analysis unit 11 extracts a packet for monitoring video quality from an IP packet T1 that is transmitted through a network (not shown), and outputs the extracted packet as an IP packet T2. For example, when the IP packet T1 is data that is converted into an IP multicast packet, the IP packet header analysis unit 11 extracts the IP packet T1 having a predetermined multicast address.
  • the UDP / RTP packet header analysis unit 12 separates the IP packet T2 into a TS packet T3 and an FEC (Forward Error Correction) packet T4 based on the destination port number of the UDP packet header in the IP packet T2.
  • the TS packet T3 is data obtained by converting a plurality of TS packets that are video data into RTP
  • the FEC packet T4 is data obtained by converting FEC data for error correction of the video data into RTP packets.
  • the FEC packet analysis unit 13 analyzes a TS packet header (TS packet header) that can be error-corrected by the FEC packet T4 among the plurality of TS packets in the TS packet T3, and determines the TS packet header and the FEC packet T4. Output as FEC data T6.
  • TS packet header TS packet header
  • the FEC buffer 14 rearranges the TS packets in the TS packet T3 in the correct order based on the time information in the RTP packet header of the TS packet T3.
  • the FEC buffer 14 delays the TS packet T3 in which the TS packets are rearranged until the timing at which error correction is possible with the FEC data T6, and outputs the delayed TS packet T3 as the TS packet T5.
  • the error correction unit 15 performs error correction of the TS packet T5 based on the FEC data T6, and outputs the TS packet T5 subjected to the error correction as a TS packet T7.
  • the TS header analysis unit 16 extracts a video packet T8 in which video data is packetized from the TS packet T7.
  • the video quality estimation unit 17 estimates the video quality of the video data using the video packet header and the video encoding parameter of the video packet T8, and outputs video quality estimation information T9 indicating the video quality.
  • Patent Document 1 As a technique for realizing such a monitoring method, there is a video quality estimation apparatus described in Patent Document 1.
  • the above-described monitoring method has a problem that a large-capacity memory is required to delay TS packets.
  • An object of the present invention is to provide a video quality estimation apparatus, a video quality estimation method, and a program that solve the above-described problem that a large-capacity memory is required.
  • the video quality estimation apparatus includes: an input unit that receives a video packet in which video data is packetized; and a correction packet in which correction data for correcting an error in the video data is packetized; First confirmation means for confirming continuity of video packets received by the input means; second confirmation means for confirming continuity of correction packets accepted by the input means; the first confirmation means and the second confirmation Based on each continuity confirmed by the means, the video data that is included in the missing video packet and cannot be corrected with the correction data is estimated as uncorrectable data, and based on the estimated uncorrectable data Estimating means for estimating the video quality of the video data.
  • a video quality estimation method is a video quality estimation method performed by a video quality estimation apparatus, wherein video packets in which video data is packetized and correction data for correcting errors in the video data are packetized.
  • the recording medium includes a procedure for receiving, in a computer, a video packet in which video data is packetized and a correction packet in which correction data for correcting an error in the video data is packetized; A procedure for confirming the continuity of the accepted video packet; a procedure for confirming the continuity of the accepted correction packet; and the missing video packet based on each confirmed continuity, A recording medium on which a program for executing a procedure for estimating video data whose error cannot be corrected with correction data as uncorrectable data and estimating the video quality of the video data based on the estimated uncorrectable data.
  • FIG. 3 is a block diagram showing the configuration of the video quality estimation apparatus according to the embodiment of the present invention.
  • the video quality estimation apparatus estimates the video quality of video data distributed by an IPTV broadcast service using IP multicast.
  • video data is compressed and packetized
  • IP multicast is a technique for transmitting compression-coded video data in real time using an IP network.
  • the video quality estimation device downloads not only the video quality of the video data distributed by the IPTV broadcast service, but also the real-time VoD (Video on Demand) service using IP data cast and the TV service data. It can also be applied to estimation of video quality of video data distributed by download service.
  • the real-time VoD Video on Demand
  • the video quality estimation apparatus includes an input unit including an IP packet header analysis unit 1 and a UDP / RTP packet header analysis unit 2, an FEC packet analysis unit 3, an error information table generation unit 4, and a TS header analysis.
  • An estimation unit including a unit 5, a video information table generation unit 6, and a video quality estimation unit 7.
  • the IP packet header analysis unit 1 of the input unit accepts packet data S1 transmitted on a network (not shown) by IP multicast.
  • the packet data S1 includes a video packet in which video data is converted into an IP packet and an FEC packet in which FEC data is converted into an RTP packet.
  • the FEC data is correction data for correcting an error in the video data.
  • the FEC packet is an example of a correction packet. Further, FEC packets are periodically inserted between video packets.
  • the video data is compressed and encoded in the MPEG2-TS format.
  • the video data includes a video stream indicating an image and information other than the video stream such as an audio stream indicating sound.
  • Video data is packetized into PES (Packetized Elementary Stream) packets for each picture (frame).
  • PES Packetized Elementary Stream
  • Each PES packet is divided into a plurality of TS packets.
  • One or a plurality of TS packets are stored in one RTP packet (UDP / RTP packet). Further, the RTP packet is converted into an IP packet to form a video packet.
  • FIG. 4 is an explanatory diagram showing a configuration example of a video packet.
  • each TS packet included in the video packet includes a TS header and a data area (date_byte) having a payload.
  • the TS header includes a synchronization byte (sync_byte), a transport error flag (transport_error_indicator), a PES packet head flag (payload_unit_start_indicator), a priority flag (transport_priority), a PID (rita Identifier), a scramble flag (transport_scrambling_control), , An adaptation field control flag (adaptation_field_control) and a continuity counter value (continuity_counter).
  • sync_byte synchronization byte
  • transport error flag transport_error_indicator
  • PES packet head flag payload_unit_start_indicator
  • priority flag transport_priority
  • PID occidental Identifier
  • scramble flag transport_scrambling_control
  • continuity counter value continuity_counter
  • the synchronization byte indicates the beginning of the TS packet.
  • the transport error flag indicates whether there is an error in the TS packet.
  • the PES packet head flag indicates whether or not the payload included in the data area starts from the head of the PES packet. More specifically, when the PES packet head flag is “1”, it indicates that the payload starts from the head of the PES packet, and when it is “0”, the payload does not start from the head of the PES packet. It shows that.
  • the priority flag indicates whether the TS packet is important. More specifically, when the priority flag is “1”, it indicates that the TS packet is important. When the priority flag is “0”, it indicates that the TS packet is not important.
  • the scramble flag indicates whether the TS packet is scrambled (encrypted).
  • the adaptation field control flag indicates whether or not a variable length adaptation field exists in the TS packet. More specifically, when the adaptation field control flag is “1”, it indicates that the adaptation field exists, and when it is “0”, it indicates that the adaptation field does not exist.
  • the adaptation field includes an elementary stream priority flag indicating whether or not an elementary stream that is an encoded image or sound is important.
  • the elementary stream priority flag is “1”, it indicates that the elementary stream is important.
  • the elementary stream priority flag is “0”, it indicates that the elementary stream is not important.
  • the continuity counter value indicates the order of TS packets.
  • time stamp information may be added to the TS packet.
  • TTS Timestamped TS time stamp information
  • the RTP packet includes a UDP header, an RTP header, and a plurality of TS packets.
  • the video packet is an IP packet and includes an IP header and an RTP packet.
  • the FEC packet includes an RTP header, an FEC header, and an FEC payload.
  • the FEC payload includes FEC data.
  • the FEC header includes the RTP sequence number (SN base) at the beginning of the RTP packet that is subject to error correction by the FEC packet having the FEC header, and the length of the RTP packet that is subject to error correction by the FEC packet. A certain length (length recovery) is included.
  • this leading RTP sequence number is referred to as a leading RTP sequence number.
  • the IP packet header analysis unit 1 extracts, as packet data S2, a packet for estimating video quality and an FEC packet for correcting an error in the packet from the packet data S1.
  • the UDP / RTP packet header analysis unit 2 separates the packet data S2 extracted by the IP packet header analysis unit 1 into video packets and FEC packets.
  • the UDP / RTP packet header analysis unit 2 generates an RTP packet in the video packet as an RTP packet S3, and generates an FEC packet as an FEC packet S4.
  • the FEC packet analysis unit 3 is an example of a first confirmation unit.
  • the FEC packet analysis unit 3 confirms the continuity of the FEC packet S4 generated by the UDP / RTP packet header analysis unit 2, and generates FEC continuity information indicating the continuity.
  • FEC continuity information FEC presence / absence information indicating whether or not an FEC packet exists is associated with an RTP sequence number. Note that the FEC presence / absence information indicates that there is an FEC packet when it is “present”, and indicates that there is no FEC packet when it is “not present”.
  • the FEC packet analysis unit 3 generates FEC packet information S5 having FEC continuity information. At this time, when the FEC presence / absence information is “present”, there is an FEC packet S4 having an RTP sequence number corresponding to the FEC presence / absence information, so the FEC packet analysis unit 3 uses the FEC header of the FEC packet S4 as the FEC packet information. Add to S5.
  • the error information table generation unit 4 is an example of a second confirmation unit.
  • the error information table generation unit 4 confirms the continuity of the RTP packet S3 and generates an error information table S6 indicating the continuity.
  • RTP presence / absence information indicating whether or not the RTP packet S3 exists is stored for each RTP sequence number.
  • the RTP presence / absence information indicates that there is an RTP packet when “present”, and indicates that there is no RTP packet when “not present”.
  • FIG. 6 is an explanatory diagram showing an example of the error information table.
  • the information length D is 5 and the code length L is 20.
  • the RTP sequence number in the error information table may be 200 or more.
  • the error information table 20 includes an RTP sequence number 21 and presence / absence 22 of an RTP packet.
  • the presence / absence 22 of the RTP packet is RTP presence / absence information, and indicates whether or not there is an RTP packet having the RTP sequence number 21.
  • the estimation unit including the TS header analysis unit 5, the video information table generation unit 6, and the video quality estimation unit 7 includes the FEC packet information S5 generated by the FEC packet analysis unit 3 and the error information generated by the error information table generation unit 4. Based on the table S6, uncorrectable data included in a video packet that is lost due to packet loss or the like is estimated.
  • the estimation unit estimates the video quality of the video data based on the uncorrectable data.
  • the uncorrectable data is video data whose error cannot be corrected with the FEC data.
  • the TS header analysis unit 5, the video information table generation unit 6, and the video quality estimation unit 7 perform the following processing.
  • the TS header analysis unit 5 analyzes the TS header of the RTP packet S3 generated by the UDP / RTP packet header analysis unit 2, detects each picture code amount and importance included in the RTP packet S3, and displays the detection result. It is generated as TS header information S7.
  • the video information table generation unit 6 estimates an uncorrectable packet in which an error cannot be corrected by the FEC packet among the missing video packets.
  • the video information table generating unit 6 estimates the code amount and the picture type of each picture included in the video packet not missing based on the TS header information S7.
  • the video information table generation unit 6 estimates the picture type and number of uncorrectable data included in the uncorrectable packet based on the estimated code amount and picture type of the picture, and generates the estimation result as the video information table S8. To do.
  • the video quality estimation unit 7 estimates the video quality of the video data based on the video information table S8 generated by the video information table generation unit 6, and outputs the estimation result as the video quality S9.
  • FIG. 7 is a flowchart for explaining the operation of the video quality estimation apparatus.
  • the IP packet header analysis unit 1 executes step S101.
  • step S101 the IP packet header analysis unit 1 extracts, as packet data S2, data for estimating video quality from the packet data S1 based on at least one of the IP header and the UDP header of the packet data S1.
  • the IP packet header analysis unit 1 holds a multicast address of IPTV service data for estimating video quality, and if the held multicast address is the same as the multicast address in the IP header, the IPTV service data Data is extracted as packet data S2.
  • the IP packet header analysis unit 1 inputs the packet data S2 to the UDP / RTP packet header analysis unit 2.
  • the UDP / RTP packet header analysis unit 2 separates the packet data S2 into video packets and FEC packets.
  • the UDP / RTP packet header analysis unit 2 first checks the port numbers (source port number and destination port number) included in the UDP header. Then, if the confirmed port number is a value for transmitting video data, the UDP / RTP packet header analysis unit 2 sets the packet data S2 as a video packet, and the confirmed port number is a value for transmitting FEC data.
  • the packet data S2 is an FEC packet.
  • the UDP / RTP packet header analysis unit 2 inputs the RTP packet in the video packet to the error information table generation unit 4 and the TS header analysis unit 5 as the RTP packet S3. Further, the UDP / RTP packet header analysis unit 2 inputs the FEC packet to the FEC packet analysis unit 3 as the FEC packet S4.
  • the FEC packet analysis unit 3 executes step S102A.
  • the error information table generation unit 4 executes Step S102B.
  • the TS header analysis unit 5 executes Step S105.
  • step S102A the FEC packet analysis unit 3 confirms the continuity of the FEC packet S4, and generates FEC continuity information indicating the continuity.
  • the RTP sequence number is an unsigned 16-bit integer, and is data that is incremented by 1 each time a packet in the same service is transmitted. Therefore, if the RTP sequence number is continuous, the FEC packet S4 is continuous. If the RTP sequence number is discontinuous, the FEC packet S4 is discontinuous. Therefore, the FEC packet analysis unit 3 can confirm the continuity of the RTP sequence number as the continuity of the FEC packet S4.
  • the FEC packet analysis unit 3 and the current RTP sequence number in the FEC packet S4 and the previous RTP sequence in the previous FEC packet S4 are input. Calculate the difference from the number.
  • the FEC packet analysis unit 3 determines that the FEC packet S4 is continuous, and associates the FEC presence / absence information indicating “present” with the current RTP sequence number, and the FEC continuity information. Is generated.
  • the FEC packet analysis unit 3 determines that the FEC packet S4 is not continuous, and determines the number of missing FEC packets S4 according to the difference.
  • the difference is “n”
  • the number of missing FEC packets S4 is “n ⁇ 1”.
  • the FEC packet analysis unit 3 obtains a missing RTP sequence number in the missing FEC packet S4 based on the number of missing FEC packets S4 and the previous RTP sequence number.
  • the FEC packet analysis unit 3 associates the obtained missing RTP sequence number with the FEC presence / absence information indicating “none”, and generates the FEC continuity information of the number of the missing FEC packets S4. Further, FEC continuity information is generated by associating the FEC presence / absence information indicating “present” with the current RTP sequence number.
  • the FEC packet analysis unit 3 may determine the number of missing FEC packets based on the time stamp information.
  • the FEC packet analysis unit 3 and the time indicated by the time stamp information in the FEC packet S4 and the previous FEC packet S4 in the FEC packet S4 are input.
  • a difference value ⁇ from the time indicated by the time stamp information is obtained.
  • the FEC packet analysis unit 3 calculates a cumulative average ⁇ M of the difference values. Then, the FEC packet analysis unit 3 determines whether or not the difference value ⁇ is equal to or greater than a predetermined number times the cumulative average ⁇ M.
  • the FEC packet analysis unit 3 determines that no burst error has occurred, and confirms continuity using the RTP sequence number.
  • the FEC packet analysis unit 3 determines that a burst error has occurred and determines the number of missing FEC packets S4 according to the difference value ⁇ . .
  • the predetermined number is, for example, 65536 that the RTP sequence number makes a round.
  • the predetermined number is not limited to this value, and may be a value (for example, 8000) that can be determined that a packet loss has occurred.
  • the FEC packet analysis unit 3 When generating the FEC continuity information, the FEC packet analysis unit 3 generates FEC packet information S5 having the FEC continuity information. The FEC packet analysis unit 3 inputs the FEC packet information S5 to the video information table generation unit 6. When the FEC packet information S5 is input, the video information table generation unit 6 executes Step S103.
  • step S103 when the FEC header is included in the FEC packet information S5, the video information table generation unit 6 extracts the head RTP sequence number from the FEC header. Thereafter, the video information table generating unit 6 executes Step S109.
  • step S102B the error information table generation unit 4 confirms the continuity of the RTP packet S3.
  • the method for confirming the continuity of the RTP packet S3 is the same as the method in which the FEC packet analysis unit 3 confirms the continuity of the FEC packet S4, and thus detailed description thereof is omitted.
  • the error information table generating unit 4 executes Step S104.
  • step S104 the error information table generation unit 4 generates an error information table S6 indicating the continuity, and inputs the generated error information table S6 to the video information table generation unit 6. Thereafter, the video information table generating unit 6 executes Step S109.
  • step S105 the TS header analysis unit 5 confirms the continuity of the TTS timestamp information included in the RTP packet S3.
  • TTS time stamp information is 4-byte time information using a video reference clock (90 kHz).
  • TS packets are transmitted at a constant rate. Therefore, if there is no packet loss in a TS packet, the TTS time stamp information in one TS packet and the TTS time in the next TS packet are transmitted.
  • the difference time ⁇ TTS which is the difference from the stamp information, is constant.
  • the TS header analysis unit 5 obtains a difference value between the TTS time stamp information in the TS packet and the TTS time stamp information in the previous TS packet, and the difference value is a constant value. It is determined whether or not it is deviated from.
  • the TS header analysis unit 5 determines that the TS packet is discontinuous when the difference value is deviated from the constant value, and determines that the TS packet is continuous when the difference value is not deviated from the constant value. To do. Also, the TS header analysis unit 5 estimates the number of missing TS packets from the difference between the difference value and the constant value.
  • Step S106 When the TS header analysis unit 5 confirms the continuity of the TTS time stamp information, the TS header analysis unit 5 executes Step S106.
  • step S106 the TS header analysis unit 5 checks whether or not a video packet that is a TS packet including a video stream exists in the RTP packet S3.
  • the TS header analysis unit 5 extracts the video packet from the RTP packet S3. If there are a plurality of TS packets in the RTP packet S3, the TS header analysis unit 5 separates the video packets into TS packets.
  • the TS header analysis unit 5 executes Step S107 after completing Step S106.
  • step S107 the TS header analysis unit 5 confirms the continuity of the video packets.
  • the method for confirming the continuity of the video packet is the same as the method for confirming the continuity of the FEC packet S4 by the FEC packet analysis unit 3, and therefore detailed description thereof is omitted.
  • the continuity of the continuity counter value included in the TS header in the video packet is confirmed as the continuity of the video packet instead of the RTP sequence number.
  • the number of missing video packets is obtained using the continuity of TTS time stamp information.
  • Step S108 When the TS header analyzing unit 5 confirms the continuity of the video packets, the TS header analyzing unit 5 executes Step S108.
  • step S108 the TS header analysis unit 5 identifies a video packet having the picture for each picture.
  • the TS header analysis unit 5 checks the PES packet head flag included in the TS header in each video packet, and from the video packet having the PES packet head flag “1”, the next PES packet head flag is The video packet preceding the video packet “1” is identified as a video packet having the same picture.
  • the TS header analysis unit 5 When the TS header analysis unit 5 identifies a video packet having a picture, the TS header analysis unit 5 obtains the importance of the picture.
  • the TS header analysis unit 5 extracts a priority flag and an adaptation field control flag from each TS header of a video packet having the picture.
  • the TS header analysis unit 5 extracts a PCR (program clock reference) and an elementary stream priority flag from the adaptation field included in the data area in the video packet. Note that the clock information of the video data is inserted into the PCR, but since it is not directly related to the present invention, it will be omitted in the following description.
  • the TS header analysis unit 5 determines that the picture is important. On the other hand, if there is no flag indicating “1” among the extracted priority flag and elementary stream priority flag, the TS header analysis unit 5 determines that the picture is not important.
  • the TS header analysis unit 5 obtains the code amount of the video packet having the picture as the code amount of the picture.
  • the TS header analysis unit 5 associates the code amount and importance of a picture, and video continuity information indicating whether or not the video packet having the picture is continuous with the video frame number in the video packet having the picture.
  • the attached picture information is generated for each picture.
  • the video frame number indicates the display order of pictures.
  • the TS header analysis unit 5 generates TS header information S7 by associating the picture information with the RTP sequence number included in the RTP packet S3.
  • the TS header analysis unit 5 inputs TS header information to the video information table generation unit 6.
  • the video information table generating unit 6 executes Step S109.
  • step S109 the video information table generating unit 6 corrects the error information table based on the top sequence number extracted in step S103 and the TS header information S7.
  • the video information table generation unit 6 associates FEC presence / absence information indicating “present” with the same RTP sequence number as the head RTP sequence number in the error information table S6, and the head RTP sequence number.
  • the FTP presence / absence information indicating “None” is associated with the RTP sequence number different from the above.
  • the video information table generation unit 6 adds, to each RTP sequence number in the error information table S6, picture presence / absence information and video included in the picture information associated with the RTP sequence number in the TS header information S7. Give continuity information and picture importance.
  • FIG. 8 is an explanatory diagram showing an example of the corrected error information table S6.
  • the error information table 20 includes an RTP sequence number 21, an RTP packet presence / absence 22, an FEC packet presence / absence 23, a video packet presence / absence 24, a video packet continuity 25, and the importance of the video packet. 26.
  • the presence / absence 23 of the FEC packet is FEC packet information, and indicates whether or not there is an FEC packet having the RTP sequence number 21 as the head RTP sequence number.
  • the presence / absence 24 of the video packet is video presence / absence information, and indicates whether or not a video packet exists in the RTP packet having the RTP sequence number 21.
  • the video packet continuity 25 is video continuity information and indicates whether or not the video packet in the RTP packet having the RTP sequence number 21 is continuous. When the video packet continuity 25 is “present”, the video packet is continuous. When the video packet continuity 25 is “not present”, the video packet is not continuous.
  • the importance 26 of the video packet indicates whether or not the video packet in the RTP packet having the RTP sequence number 21 is important.
  • the importance 26 of the video packet indicates that the video packet is important if it is “present”, and indicates that the video packet is not important if it is “none”.
  • the video information table generation unit 6 Based on the error information table S6 in which the FEC presence / absence information is associated and the FEC packet information S5, the video information table generation unit 6 converts the RTP packet of the RTP sequence number into FEC data for each RTP sequence number. It is determined whether it is a correctable packet that can be error-corrected or an uncorrectable packet that cannot be corrected by FEC data.
  • the video information table generation unit 6 has the RTP sequence number associated with the FEC presence / absence information indicating “present” in the error information table S6 and the RTP sequence number as the first RTP sequence number. Based on the effective length in the FEC header included in the FEC packet information S5, for each FEC packet, the RTP sequence number of the RTP packet to be subjected to error correction by the FEC packet is specified.
  • the video information table generation unit 6 determines, for each FEC packet, whether or not FEC presence / absence information indicating “present” is associated with any of the specified RTP sequence numbers.
  • the video information table generation unit 6 When the FEC presence / absence information indicating “present” is associated, the video information table generation unit 6 includes the RTP presence / absence information indicating “none” in the RTP presence / absence information associated with the identified RTP sequence number. If there are two or more, the RTP packet of that RTP sequence number is determined as an uncorrectable packet. On the other hand, if the RTP presence / absence information indicating “none” is 1 or less in the RTP presence / absence information, the video information table generation unit 6 determines that the RTP packet of the RTP sequence number is a correctable packet.
  • the video information table generation unit 6 includes the RTP indicating “none” in the RTP presence / absence information associated with the identified RTP sequence number. If the presence / absence information is 1 or more, the RTP packet of the RTP sequence number is determined as an uncorrectable packet. On the other hand, if the RTP presence / absence information indicating “none” is 0 in the RTP presence / absence information, the video information table generation unit 6 determines that the RTP packet of the RTP sequence number is a correctable packet.
  • the video information table generating unit 6 determines whether the RTP packet is a correctable packet or an uncorrectable packet, the video information table generating unit 6 associates the determination result with the RTP sequence number of the RTP packet in the error information table S6.
  • the video information table generating unit 6 executes Step 110 after completing Step S109.
  • step S110 the video information table generation unit 6 generates a video information table S8 based on the error information table S6 and the TS header information S7.
  • the video information table S8 for each video frame number specifying a picture, packet loss presence / absence information indicating whether or not a video packet having the picture is missing, and whether or not the video packet can be error-corrected are indicated.
  • the recovery information is associated with the picture type of the picture, the code amount of the picture, and the average code amount that is an average value of the code amount.
  • the video information table generating unit 6 confirms the RTP sequence number associated with the RTP presence / absence information indicating “present” in the error information table S6.
  • the video information table generation unit 6 acquires the picture information corresponding to the confirmed RTP sequence number from the TS header information S7.
  • the video information table generation unit 6 uses the video presence / absence information associated with the video frame number as packet loss presence / absence information corresponding to the video frame number. Generate.
  • the video information table generation unit 6 calculates, for each video frame number, an average value of code amounts corresponding to a plurality of video frame numbers (30 or more video frame numbers) before the video frame number. Is generated as an average code amount corresponding to.
  • the video information table generation unit 6 confirms the importance of the picture associated with the video frame number, and indicates that the importance is important.
  • the corresponding picture type is determined as an I picture.
  • the video information table generation unit 6 subtracts the code amount corresponding to the video frame number from the average code amount corresponding to the video frame number to obtain the code amount transition.
  • the video information table generating unit 6 performs pattern matching between the obtained code amount transition and the code amount transition corresponding to the picture type stored in advance, thereby supporting the video frame number other than the I picture. Estimate the picture type. Note that a method for estimating the picture type from the transition of the code amount is known, and is described, for example, in Non-Patent Document 1 (Science Technical Report CQ2007-74).
  • the video information table generation unit 6 uses the determination result of whether the RTP packet is a correctable packet or an uncorrectable packet corresponding to the confirmed RTP sequence number as recovery information corresponding to each of the acquired video frame numbers. Generate.
  • the video information table S8 related to the RTP packet that is not lost is generated.
  • the video information table S8 related to the missing RTP packet is generated from the video information table S8 related to the RTP packet not missing.
  • the video information table generating unit 6 confirms the RTP sequence number associated with the RTP presence / absence information indicating “none” in the error information table S6.
  • the video information table generation unit 6 obtains the number of RTP sequence numbers as the number of missing RTP packets. In addition, the video information table generation unit 6 determines the number of missing RTP packets and the transition of the code amount corresponding to the RTP sequence number before the RTP sequence number associated with the RTP presence / absence information indicating “none”. To estimate the number of missing pictures.
  • the video information table generation unit 6 is missing based on the code amount transition and the picture type transition corresponding to the RTP sequence number preceding the RTP sequence number associated with the RTP presence / absence information indicating “none”. Estimate the picture type of the picture.
  • the video information table generating unit 6 determines that “no” is based on the code amount transition and the picture type corresponding to the RTP sequence number preceding the RTP sequence number associated with the RTP presence / absence information indicating “none”. Recovery information corresponding to each of the video frame numbers corresponding to the RTP sequence numbers associated with the RTP presence / absence information indicating the
  • FIG. 9 is an explanatory diagram showing an example of the video information table S8.
  • the video information table 30 includes a video frame number 31, a video packet loss presence 32, a FEC packet recovery presence 33, a picture type 34, a video data code amount 35, and a video data average code amount 36. Including.
  • Video packet loss presence / absence 32 is packet loss presence / absence information, and indicates whether or not a video packet having a picture of video frame number 31 is missing.
  • the presence / absence 33 of FEC packet recovery is recovery information and indicates whether or not the video packet having the picture of the video frame number 31 can be error-corrected.
  • the picture type 34 is the picture type of the picture with the video frame number 31, and indicates any of an I picture, a B picture, and a P picture.
  • the video data code amount 35 is the code amount of the picture of the video frame number 31, and the video data average code amount 36 is the average value of the video data code amount 35.
  • the video information table generation unit 6 inputs the generated video information table S8 to the video quality estimation unit 7.
  • the video quality estimation unit 7 executes step S111.
  • step S111 the video quality estimation unit 7 identifies a video frame number in the video information table S8 where the RTP presence / absence information indicates “none” and the FEC presence / absence information indicates “none”.
  • the picture corresponding to the specified video frame number becomes an uncorrectable picture that cannot be corrected with FEC data and is included in the missing RTP packet.
  • the video quality estimation unit 7 obtains the number of the specified video frames as the number of uncorrectable pictures, and obtains the picture type corresponding to each identified video frame as the picture type of the uncorrectable pictures.
  • the uncorrectable picture is an I picture
  • the video stream cannot be restored to normal data until the next I picture appears, and this greatly affects the degradation of video quality.
  • the uncorrectable picture is a B picture or a P picture
  • the video stream is a quality deterioration in the frame and does not significantly affect the deterioration of the video quality.
  • the video quality estimation unit 7 sets the video quality S9 to the lowest level when the error-uncorrectable picture is an I picture, and sets the video quality S9 to a medium level better than the lowest level when the error-correctable picture is a P picture. If the error uncorrectable picture is a B picture, the video quality S9 is set to a high level better than the medium level, and if there is no error correctable picture, the video quality S9 is set to the highest level better than the high level.
  • the video quality estimation unit 7 weights the video quality according to the picture type of each error-correctable picture, and the sum of the weighted video quality is set as the video quality S9. It may be generated.
  • the video quality estimation method by the video quality estimation unit 7 may be the method used in Patent Document 1 or Non-Patent Document 1, for example.
  • the FEC packet analysis unit 3 confirms the continuity of the FEC packet.
  • the error information table generation unit 4 confirms the continuity of video packets.
  • the estimation unit is included in the missing video packet based on their continuity. Video data whose error cannot be corrected with FEC data is estimated as uncorrectable data. The estimation unit estimates the video quality of the video data based on the uncorrectable data.
  • uncorrectable data is estimated based on the continuity of the FEC packet and the continuity of the video packet. Further, the video quality of the video data is estimated based on the uncorrectable data.
  • the estimation unit analyzes the TS header of the video packet, estimates the picture type of the uncorrectable data, and estimates the video quality based on the estimated picture type.
  • the time until error correction becomes possible differs depending on the picture type of the picture, so that the video quality changes depending on the picture type that cannot be error corrected. Therefore, in this embodiment, since the video quality is estimated based on the picture type, it is possible to accurately estimate the video quality.
  • the estimation unit analyzes the TS header of the video packet to obtain the code amount of the video data included in the video packet, and estimates the picture type of the uncorrectable picture based on the code amount. .
  • the picture type can be estimated according to the code amount of the picture. For this reason, it is possible to accurately estimate the picture type.
  • the function of the video quality estimation apparatus described above is executed by recording a program for realizing the function on a computer-readable recording medium and causing the computer to read the program recorded on the recording medium. May be realized.
  • a computer-readable recording medium that records a program for realizing the function of the video quality estimation apparatus is also an embodiment of the present invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • Databases & Information Systems (AREA)
  • Quality & Reliability (AREA)
  • Human Computer Interaction (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • General Health & Medical Sciences (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Testing, Inspecting, Measuring Of Stereoscopic Televisions And Televisions (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)

Abstract

　大容量のメモリが必要となるという問題を解決する映像品質推定装置を提供する。　ＦＥＣパケット解析部３は、ＦＥＣパケットの連続性を確認する。エラー情報テーブル生成部４は、映像パケットの連続性を確認する。推定部は、それらの連続性に基づいて、欠落した映像パケットに含まれる。ＦＥＣデータでエラーが訂正できない映像データを訂正不可データとして推定する。推定部は、その訂正不可データに基づいて、映像データの映像品質を推定する。

Description

映像品質推定装置および映像品質推定方法
　本発明は、映像データの品質を監視するための映像品質推定装置、映像品質推定方法およびプログラムに関し、特には、ＩＰＴＶサービスにて配信される映像データの品質を監視するための映像品質推定装置および映像品質推定方法に関する。
　地上アナログ放送は、日本では２０１１年に停波することになっている。このため、２０１１年までに、地上アナログ放送を円滑に地上デジタル放送に移行させるとともに、地上アナログ放送の視聴可能エリアに対する地上デジタル放送のカバー率を１００％にすることが要望されている。このような要望を満たす手段として、ＩＰ網としてＮＧＮ（Next　Generation　Network）網を利用したＩＰＴＶ（Internet　Protocol　Television）サービス（地デジＩＰ再送信サービス）が提案されている。なお、ＩＰＴＶサービスは、ＩＰ網を介してデジタルテレビ放送を配信するサービス形態である。
　一般的なネットワークは、ＱｏＳ（Quality　of　Service：サービス品質）が保証されないベストエフォート型であるため、映像配信サービスにおいて、映像視聴者に配信される映像データの品質を保証できるとは限らなかった。ＮＧＮ網が利用されると、ＱｏＳが保証されるので、電波を利用した放送ＴＶサービスと同等の映像品質を保証することが可能となる。
　また、電波を利用した放送ＴＶサービスでは、送信所から送出される電波の強度、建物および地形などに基づいて、放送の視聴可能エリアが計算される。さらに、その視聴可能エリア内の幾つかの観測地点で映像品質の試験が行われ、その試験結果と理論上の映像品質の計算結果とが比較されることによって、映像品質が監視されていた。
　一方、ＩＰＴＶサービスでは、コンテンツが送信されてから各家庭のＴＶ受像機に受信されるまでに複数のプロバイダが介在する。このため、それぞれのプロバイダ間で映像品質を監視する必要がある。
　例えば、ＩＴＵ－Ｔ勧告では、映像品質を監視する監視ポイントを５箇所に設けることが定められている。図１は、ＩＴＵ－Ｔ勧告における監視ポイントを示した説明図である。図１には、監視ポイントＰＴ１～ＰＴ５が示されている。
　図１で示されたように、ＩＰＴＶサービスを提供するための通信システムは、コンテンツプロバイダ（Content　Provider）１０１と、サービスプロバイダ（Service　Provider(central　headend)）１０２と、ローカルコンテンツ補足段階（Local　content　acquisition）１０３と、サービスプロバイダ（Service　Provider(regional　headend)）１０４と、ネットワークプロバイダ（Network　Provider）１０５と、エンドユーザ（End　User）１０６と、を有する。
　映像データは、コンテンツプロバイダ１０１、サービスプロバイダ１０２およびネットワークプロバイダ１０５からなる経路、または、ローカルコンテンツ補足段階１０３、サービスプロバイダ１０４およびネットワークプロバイダ１０５からなる経路を通過してエンドユーザ１０６まで配信される。
　監視ポイントＰＴ１は、コンテンツプロバイダ１０１とサービスプロバイダ１０２との間、または、ローカルコンテンツ補足段階１０３とサービスプロバイダ１０４との間に設けられる。監視ポイントＰＴ２は、サービスプロバイダ１０２とネットワークプロバイダ１０５内のＩＰコアネットワーク（IP　Core　Network）１０５ａとの間、または、サービスプロバイダ１０４とＩＰコアネットワーク１０５ａとの間に設けられる。
　監視ポイントＰＴ３は、ＩＰコアネットワーク１０５ａとネットワークプロバイダ１０５内のＩＰアクセスネットワーク（IP　Access　Network）１０５ｂとの間に設けられる。監視ポイントＰＴ４は、ＩＰアクセスネットワーク１０５ｂ上のＶＯＤ（Video　on　Demand）サーバ（Edge　VOD　Server/multicast　replication　point）１０５ｃと、エンドユーザ（End　User）１０６のゲートウェイ（Home　Gateway）１０６ａとの間に設けられる。監視ポイントＰＴ５は、エンドユーザ１０６のＳＴＢ（Set-top　box：セットトップボックス）１０６ｂとエンドユーザ１０６のＴＶ１０６ｃと間に設けられる。
　以下、監視ポイントＰＴ３およびＰＴ４で行われる映像品質の監視方法について説明する。図２は、この監視方法を実現するための映像品質監視装置の構成を示したブロック図である。
　ＩＰパケットヘッダ解析部１１は、ネットワーク（不図示）を伝送しているＩＰパケットＴ１から、映像品質を監視するパケットを抽出し、その抽出したパケットをＩＰパケットＴ２として出力する。例えば、ＩＰパケットＴ１が、ＩＰマルチキャストパケット化されたデータの場合、ＩＰパケットヘッダ解析部１１は、所定のマルチキャストアドレスを有するＩＰパケットＴ１を抽出する。
　ＵＤＰ／ＲＴＰパケットヘッダ解析部１２は、ＩＰパケットＴ２内のＵＤＰパケットヘッダの宛先ポート番号に基づいて、ＩＰパケットＴ２をＴＳパケットＴ３とＦＥＣ（Forward　Error　Correction）パケットＴ４とに分離する。ＴＳパケットＴ３は、映像データである複数のＴＳパケットがＲＴＰ化されたデータであり、ＦＥＣパケットＴ４は、その映像データのエラー訂正を行うためのＦＥＣデータがＲＴＰパケット化されたデータである。
　ＦＥＣパケット解析部１３は、ＴＳパケットＴ３内の複数のＴＳパケットのうち、ＦＥＣパケットＴ４でエラー訂正が可能なＴＳパケットのヘッダ（ＴＳパケットヘッダ）を解析し、そのＴＳパケットヘッダおよびＦＥＣパケットＴ４をＦＥＣデータＴ６として出力する。
　ＦＥＣバッファ１４は、ＴＳパケットＴ３内の各ＴＳパケットを、ＴＳパケットＴ３のＲＴＰパケットヘッダ内の時間情報に基づいて正しい順序に並び替える。ＦＥＣバッファ１４は、そのＴＳパケットを並び替えたＴＳパケットＴ３を、ＦＥＣデータＴ６でエラー訂正が可能になるタイミングまで遅延させ、その遅延させたＴＳパケットＴ３をＴＳパケットＴ５として出力する。
　エラー訂正部１５は、ＦＥＣデータＴ６に基づいて、ＴＳパケットＴ５のエラー訂正を行い、そのエラー訂正を行ったＴＳパケットＴ５をＴＳパケットＴ７として出力する。
　ＴＳヘッダ解析部１６は、ＴＳパケットＴ７から、映像データがパケット化されている映像パケットＴ８を抽出する。
　映像品質推定部１７は、映像パケットＴ８の映像パケットヘッダおよび映像符号化パラメータを利用して、映像データの映像品質を推定し、その映像品質を示す映像品質推定情報Ｔ９を出力する。
　このような監視方法を実現するため技術には、特許文献１に記載の映像品質推定装置がある。
特開２００８－５１０８号公報
　上述の監視方法では、映像データのエラー訂正を行うため、ＴＳパケットを、ＦＥＣデータでエラー訂正が可能になるタイミングまで遅延させる必要があった。また、ＴＳパケットは映像データを有するため、データ量が大きい。
　したがって、上述の監視方法では、ＴＳパケットを遅延させるために、大容量のメモリが必要になるという問題があった。
　本発明の目的は、上記の課題である、大容量のメモリが必要となるという問題を解決する映像品質推定装置、映像品質推定方法およびプログラムを提供することである。
　本発明による映像品質推定装置は、映像データがパケット化された映像パケットと、前記映像データのエラーを訂正するための訂正用データがパケット化された訂正用パケットと、を受け付ける入力手段と、前記入力手段が受け付けた映像パケットの連続性を確認する第一確認手段と、前記入力手段が受け付けた訂正用パケットの連続性を確認する第二確認手段と、前記第一確認手段および前記第二確認手段にて確認された各連続性に基づいて、欠落した映像パケットに含まれる、前記訂正用データでエラーが訂正できない映像データを、訂正不可データとして推定し、該推定した訂正不可データに基づいて前記映像データの映像品質を推定する推定手段と、を含む。
　本発明による映像品質推定方法は、映像品質推定装置による映像品質推定方法であって、映像データがパケット化された映像パケットと、前記映像データのエラーを訂正するための訂正用データがパケット化された訂正用パケットと、を受け付ける入力ステップと、前記受け付けられた映像パケットの連続性を確認する第一確認ステップと、前記受け付けられた訂正用パケットの連続性を確認する第二確認ステップと、前記確認された各連続性に基づいて、欠落した映像パケットに含まれる、前記訂正用データでエラーが訂正できない映像データを、訂正不可データとして推定し、該推定した訂正不可データに基づいて前記映像データの映像品質を推定する推定ステップと、を含む。
　本発明による記録媒体は、コンピュータに、映像データがパケット化された映像パケットと、前記映像データのエラーを訂正するための訂正用データがパケット化された訂正用パケットと、を受け付ける手順と、前記受け付けられた映像パケットの連続性を確認する手順と、前記受け付けられた訂正用パケットの連続性を確認する手順と、前記確認された各連続性に基づいて、欠落した映像パケットに含まれる、前記訂正用データでエラーが訂正できない映像データを、訂正不可データとして推定し、該推定した訂正不可データに基づいて前記映像データの映像品質を推定する手順と、を実行させるプログラムを記録した記録媒体。
　本発明によれば、大容量のメモリを用いなくてもよくなる。
関連技術であるＩＴＵ－Ｔ勧告における監視ポイントを示した説明図である。 関連技術である映像品質監視装置の構成を示したブロック図である。 本発明の実施形態の映像品質推定装置の構成を示したブロック図である。 映像パケットの構成例を示した説明図である。 ＦＥＣパケットの構成例を示した説明図である。 エラー情報テーブルの一例を示した説明図である。 映像品質推定装置の動作を説明するためのフローチャートである。 エラー情報テーブルの他の例を示した説明図である。 映像情報テーブルの一例を示した説明図である。
　以下、本発明の実施形態について図面を参照して説明する。
　図３は、本発明の実施形態の映像品質推定装置の構成を示したブロック図である。
　なお、映像品質推定装置は、ＩＰマルチキャストを利用するＩＰＴＶ放送サービスにて配信される映像データの映像品質を推定するものとする。ここで、映像データは、圧縮符号化およびパケット化されており、ＩＰマルチキャストは、ＩＰネットワークを用いて、圧縮符号化された映像データをリアルタイムで伝送させる技術である。
　また、映像品質推定装置は、ＩＰＴＶ放送サービスにて配信される映像データの映像品質だけでなく、ＩＰデータキャストを利用するリアルタイムＶｏＤ（Video　on　Demand）サービスや、ＴＶサービスデータをダウンロードさせてから視聴させるダウンロードサービスにて配信される映像データの映像品質の推定などにも適用できる。
　図３において、映像品質推定装置は、ＩＰパケットヘッダ解析部１とＵＤＰ／ＲＴＰパケットヘッダ解析部２とを含む入力部と、ＦＥＣパケット解析部３と、エラー情報テーブル生成部４と、ＴＳヘッダ解析部５と映像情報テーブル生成部６と映像品質推定部７とを含む推定部と、を有する。
　入力部のＩＰパケットヘッダ解析部１は、ネットワーク（図示せず）上をＩＰマルチキャストで伝送されているパケットデータＳ１を受け付ける。
　パケットデータＳ１には、映像データがＩＰパケット化された映像パケットと、ＦＥＣデータがＲＴＰパケット化されたＦＥＣパケットと、がある。なお、ＦＥＣデータは、映像データのエラーを訂正するための訂正用データである。また、ＦＥＣパケットは、訂正用パケットの一例である。さらに、ＦＥＣパケットは、周期的に映像パケット間に挿入される。
　本実施形態では、映像データは、ＭＰＥＧ２－ＴＳ形式に圧縮符号化されているものとする。この場合、映像データは、画像を示すビデオストリームと、音声を示すオーディオストリームなどのビデオストリーム以外の情報とを有する。
　映像データは、ピクチャ（フレーム）ごとに、ＰＥＳ（Packetized　Elementary　Stream）パケットにパケット化される。各ＰＥＳパケットは、複数のＴＳパケットに分割される。また、一つまたは複数のＴＳパケットが一つのＲＴＰパケット（ＵＤＰ／ＲＴＰパケット）に格納される。さらに、そのＲＴＰパケットがＩＰパケット化されて、映像パケットが構成される。
　図４は、映像パケットの構成例を示した説明図である。
　図４で示されたように、映像パケットに含まれる各ＴＳパケットは、ＴＳヘッダと、ペイロードを有するデータ領域（ｄａｔｅ＿ｂｙｔｅ）を含む。
　ＴＳヘッダは、同期バイト（sync_byte）と、トランスポートエラーフラグ（transport_error_indicator）と、ＰＥＳパケット先頭フラグ（payload_unit_start_indicator）と、優先度フラグ（transport_priority）と、ＰＩＤ（Paket　Identifier）と、スクランブルフラグ（transport_scrambling_control）と、アダプテーションフィールドコントロールフラグ（adaptation_field_control）と、連続性カウンタ値（continuity_counter）とを含む。
　同期バイトは、ＴＳパケットの先頭を示す。トランスポートエラーフラグは、ＴＳパケットにエラーがあるか否かを示す。
　ＰＥＳパケット先頭フラグは、データ領域に含まれるペイロードが、ＰＥＳパケットの先頭から開始されているか否かを示す。より具体的には、ＰＥＳパケット先頭フラグは、「１」の場合、ペイロードがＰＥＳパケットの先頭から開始されていることを示し、「０」の場合、ペイロードがＰＥＳパケットの先頭から開始されていないことを示す。
　優先度フラグは、ＴＳパケットが重要か否かを示す。より具体的には、優先度フラグは、「１」の場合、ＴＳパケットが重要であることを示し、「０」の場合、ＴＳパケットが重要でないことを示す。
　ＰＩＤは、ＴＳパケットの種別を示す。スクランブルフラグは、ＴＳパケットがスクランブル（暗号化）されているか否かを示す。
　アダプテーションフィールドコントロールフラグは、ＴＳパケットに可変長のアダプテーションフィールドが存在するか否かを示す。より具体的には、アダプテーションフィールドコントロールフラグは、「１」の場合、アダプテーションフィールドが存在することを示し、「０」の場合、アダプテーションフィールドが存在しないことを示す。
　また、アダプテーションフィールドには、符号化された画像または音声であるエレメンタリストリームが重要か否かを示すエレメンタリストリームプライオリティフラグが含まれている。エレメンタリストリームプライオリティフラグは、「１」の場合、エレメンタリストリームが重要であることを示し、「０」の場合、エレメンタリストリームが重要でないことを示す。
　連続性カウンタ値は、ＴＳパケットの順番を示す。
　なお、ＴＳパケットには、タイムスタンプ情報（ＴＴＳ（Timestamped　TS）タイムスタンプ情報）が付加されてもよい。以下では、ＴＳパケットは、このＴＴＳタイムスタンプ情報が付加されたＴＴＳパケットであるとする。
　また、ＲＴＰパケットは、ＵＤＰヘッダ、ＲＴＰヘッダおよび複数のＴＳパケットを含む。映像パケットは、ＩＰパケットであり、ＩＰヘッダとＲＴＰパケットを含む。
　図３の説明に戻る。ＦＥＣパケットは、図５で示したように、ＲＴＰヘッダと、ＦＥＣヘッダと、ＦＥＣペイロードとを含む。
　ＦＥＣペイロードは、ＦＥＣデータを含む。また、ＦＥＣヘッダには、そのＦＥＣヘッダを有するＦＥＣパケットによるエラー訂正の対象となるＲＴＰパケットの先頭のＲＴＰシーケンス番号（SN　base）と、ＦＥＣパケットによるエラー訂正の対象となるＲＴＰパケットの長さである有効長（length　recovery）とが含まれている。以下、この先頭のＲＴＰシーケンス番号を先頭ＲＴＰシーケンス番号と称する。
　図３の説明に戻る。ＩＰパケットヘッダ解析部１は、パケットデータＳ１から、映像品質を推定するパケットと、そのパケットのエラーを訂正するためのＦＥＣパケットとをパケットデータＳ２として抽出する。
　ＵＤＰ／ＲＴＰパケットヘッダ解析部２は、ＩＰパケットヘッダ解析部１にて抽出されたパケットデータＳ２を、映像パケットとＦＥＣパケットとに分離する。ＵＤＰ／ＲＴＰパケットヘッダ解析部２は、映像パケット内のＲＴＰパケットをＲＴＰパケットＳ３として生成し、ＦＥＣパケットをＦＥＣパケットＳ４として生成する。
　ＦＥＣパケット解析部３は、第一確認手段の一例である。ＦＥＣパケット解析部３は、ＵＤＰ／ＲＴＰパケットヘッダ解析部２が生成したＦＥＣパケットＳ４の連続性を確認し、その連続性を示すＦＥＣ連続性情報を生成する。ＦＥＣ連続性情報では、ＦＥＣパケットが存在するか否かを示すＦＥＣ有無情報とＲＴＰシーケンス番号とが対応付けられている。なお、ＦＥＣ有無情報は、「有」の場合、ＦＥＣパケットが存在することを示し、「無」の場合、ＦＥＣパケットが存在しないことを示す。
　ＦＥＣパケット解析部３は、ＦＥＣ連続性情報を有するＦＥＣパケット情報Ｓ５を生成する。このとき、ＦＥＣ有無情報が「有」の場合、そのＦＥＣ有無情報に対応するＲＴＰシーケンス番号を有するＦＥＣパケットＳ４があるので、ＦＥＣパケット解析部３は、そのＦＥＣパケットＳ４のＦＥＣヘッダをＦＥＣパケット情報Ｓ５に追加する。
　エラー情報テーブル生成部４は、第二確認手段の一例である。エラー情報テーブル生成部４は、ＲＴＰパケットＳ３の連続性を確認し、その連続正を示すエラー情報テーブルＳ６を生成する。エラー情報テーブルＳ６では、ＲＴＰパケットＳ３が存在するか否かを示すＲＴＰ有無情報がＲＴＰシーケンス番号ごとに格納されている。
　なお、ＲＴＰ有無情報は、「有」の場合、ＲＴＰパケットが存在することを示し、「無」の場合、ＲＴＰパケットが存在しないことを示す。
　図６は、エラー情報テーブルの一例を示した説明図である。なお、ＦＥＣデータによるエラー訂正において、情報長Ｄを５とし、符号長Ｌを２０としている。この場合、エラー情報テーブル内のＲＴＰシーケンス番号は、２００以上であればよい。
　エラー情報テーブル２０は、ＲＴＰシーケンス番号２１と、ＲＴＰパケットの有無２２とを含む。ＲＴＰパケットの有無２２は、ＲＴＰ有無情報であり、ＲＴＰシーケンス番号２１を有するＲＴＰパケットが存在するか否かを示す。
　図３の説明に戻る。ＴＳヘッダ解析部５と映像情報テーブル生成部６と映像品質推定部７とを含む推定部は、ＦＥＣパケット解析部３が生成したＦＥＣパケット情報Ｓ５と、エラー情報テーブル生成部４が生成したエラー情報テーブルＳ６とに基づいて、パケットロスなどが発生して欠落した映像パケットに含まれる訂正不可データを推定する。推定部は、その訂正不可データに基づいて、映像データの映像品質を推定する。なお、訂正不可データは、前記ＦＥＣデータでエラーが訂正できない映像データである。
　より具体的には、ＴＳヘッダ解析部５、映像情報テーブル生成部６および映像品質推定部７が以下の処理を行う。
　ＴＳヘッダ解析部５は、ＵＤＰ／ＲＴＰパケットヘッダ解析部２が生成したＲＴＰパケットＳ３のＴＳヘッダを解析して、ＲＴＰパケットＳ３に含まれる各ピクチャ符号量および重要度を検出し、その検出結果をＴＳヘッダ情報Ｓ７として生成する。
　映像情報テーブル生成部６は、ＦＥＣパケット情報Ｓ５およびエラー情報テーブルＳ６に基づいて、欠落した映像パケットのうち、前記ＦＥＣパケットでエラーが訂正できない訂正不可パケットを推定する。
　映像情報テーブル生成部６は、ＴＳヘッダ情報Ｓ７に基づいて、欠落していない映像パケットに含まれる各ピクチャの符号量およびピクチャタイプを推定する。映像情報テーブル生成部６は、その推定したピクチャの符号量およびピクチャタイプに基づいて、訂正不可パケットに含まれる訂正不可データのピクチャタイプおよび数を推定し、その推定結果を映像情報テーブルＳ８として生成する。
　映像品質推定部７は、映像情報テーブル生成部６が生成した映像情報テーブルＳ８に基づいて、映像データの映像品質を推定し、その推定結果を映像品質Ｓ９として出力する。
　次に動作を説明する。
　図７は、映像品質推定装置の動作を説明するためのフローチャートである。
　ＩＰパケットヘッダ解析部１は、パケットデータＳ１を受け付けると、ステップＳ１０１を実行する。
　ステップＳ１０１では、ＩＰパケットヘッダ解析部１は、パケットデータＳ１のＩＰヘッダおよびＵＤＰヘッダの少なくとも一方に基づいて、パケットデータＳ１から、映像品質を推定するデータをパケットデータＳ２として抽出する。
　例えば、ＩＰパケットヘッダ解析部１は、映像品質を推定するＩＰＴＶサービスデータのマルチキャストアドレスを保持し、その保持しているマルチキャストアドレスと、ＩＰヘッダ内のマルチキャストアドレスとが同一であると、そのＩＰＴＶサービスデータをパケットデータＳ２として抽出する。
　ＩＰパケットヘッダ解析部１は、パケットデータＳ２をＵＤＰ／ＲＴＰパケットヘッダ解析部２に入力する。
　ＵＤＰ／ＲＴＰパケットヘッダ解析部２は、パケットデータＳ２を、映像パケットと、ＦＥＣパケットとに分離する。
　例えば、ＵＤＰ／ＲＴＰパケットヘッダ解析部２は、先ず、ＵＤＰヘッダに含まれるポート番号（送信元ポート番号および送信先ポート番号）を確認する。そして、ＵＤＰ／ＲＴＰパケットヘッダ解析部２は、その確認したポート番号が映像データを伝送する値であれば、パケットデータＳ２を映像パケットとし、その確認したポート番号がＦＥＣデータを伝送する値であれば、そのパケットデータＳ２をＦＥＣパケットとする。
　ＵＤＰ／ＲＴＰパケットヘッダ解析部２は、映像パケット内のＲＴＰパケットを、ＲＴＰパケットＳ３としてエラー情報テーブル生成部４およびＴＳヘッダ解析部５に入力する。また、ＵＤＰ／ＲＴＰパケットヘッダ解析部２は、ＦＥＣパケットを、ＦＥＣパケットＳ４としてＦＥＣパケット解析部３に入力する。
　ＦＥＣパケット解析部３は、ＦＥＣパケットＳ４が入力されると、ステップＳ１０２Ａを実行する。また、エラー情報テーブル生成部４は、ＲＴＰパケットＳ３が入力されると、ステップＳ１０２Ｂを実行する。さらに、ＴＳヘッダ解析部５は、ＲＴＰパケットＳ３が入力されると、ステップＳ１０５を実行する。
　ステップＳ１０２Ａでは、ＦＥＣパケット解析部３は、ＦＥＣパケットＳ４の連続性を確認し、その連続性を示すＦＥＣ連続性情報を生成する。
　ＲＴＰシーケンス番号は、符号無しの１６ビット整数であり、同一サービスにおけるパケットが送信されるたびに１ずつ加算されるデータである。このため、そのＲＴＰシーケンス番号が連続であれば、ＦＥＣパケットＳ４が連続であり、そのＲＴＰシーケンス番号が不連続であれば、ＦＥＣパケットＳ４が不連続である。よって、ＦＥＣパケット解析部３は、そのＲＴＰシーケンス番号の連続性を、ＦＥＣパケットＳ４の連続性として確認することができる。
　より具体的には、ＦＥＣパケット解析部３は、ＦＥＣパケットＳ４が入力されるたびに、そのＦＥＣパケットＳ４内の現ＲＴＰシーケンス番号と、一つ前に入力されたＦＥＣパケットＳ４内の前ＲＴＰシーケンス番号との差を計算する。
　その差が「１」の場合、ＦＥＣパケット解析部３は、ＦＥＣパケットＳ４が連続であると判断して、「有」を示すＦＥＣ有無情報と現ＲＴＰシーケンス番号とを対応付けてＦＥＣ連続性情報を生成する。
　一方、その差が「１」でない場合、ＦＥＣパケット解析部３は、ＦＥＣパケットＳ４が連続でないと判断して、その差に応じて欠落したＦＥＣパケットＳ４の数を求める。なお、その差が「ｎ」の場合、欠落したＦＥＣパケットＳ４の数は、「ｎ－１」である。
　ＦＥＣパケット解析部３は、その欠落したＦＥＣパケットＳ４の数と、前ＲＴＰシーケンス番号とに基づいて、欠落したＦＥＣパケットＳ４内の欠落ＲＴＰシーケンス番号を求める。ＦＥＣパケット解析部３は、その求めた欠落ＲＴＰシーケンス番号のそれぞれに、「無」を示すＦＥＣ有無情報を対応付けて、その欠落したＦＥＣパケットＳ４の数のＦＥＣ連続性情報を生成する。さらに、「有」を示すＦＥＣ有無情報と現ＲＴＰシーケンス番号とを対応付けてＦＥＣ連続性情報を生成する。
　しかしながら、バーストエラーが発生して、ＲＴＰシーケンス番号が１６ビット以上連続して欠落した場合、ＲＴＰシーケンス番号だけでは、その欠落したＦＥＣパケットＳ４の数を特定できない。このため、ＦＥＣパケット解析部３は、タイムスタンプ情報に基づいて、欠落したＦＥＣパケットの数を判断してもよい。
　具体的には、先ず、ＦＥＣパケット解析部３は、ＦＥＣパケットＳ４が入力されるたびに、そのＦＥＣパケットＳ４内のタイムスタンプ情報が示す時刻と、一つ前に入力されたＦＥＣパケットＳ４内のタイムスタンプ情報が示す時刻との差分値Δを求める。また、ＦＥＣパケット解析部３は、その差分値の累積平均ΔＭを算出する。そして、ＦＥＣパケット解析部３は、その差分値Δが累積平均ΔＭの所定数倍以上か否かを判断する。
　その差分値Δが累積平均ΔＭの所定数倍未満の場合、ＦＥＣパケット解析部３は、バーストエラーが発生していないと判断して、ＲＴＰシーケンス番号を用いた連続性の確認を行う。
　一方、その差分値Δが累積平均ΔＭの所定数倍以上の場合、ＦＥＣパケット解析部３は、バーストエラーが発生したと判断し、その差分値Δに応じて欠落したＦＥＣパケットＳ４の数を求める。
　ここで、所定数は、例えば、ＲＴＰシーケンス番号が一巡する６５５３６であることが望ましい。また、所定数は、この値に限らず、パケットロスが発生したと判断できる値（例えば、８０００）であればよい。
　ＦＥＣパケット解析部３は、ＦＥＣ連続性情報を生成すると、そのＦＥＣ連続性情報を有するＦＥＣパケット情報Ｓ５を生成する。ＦＥＣパケット解析部３は、そのＦＥＣパケット情報Ｓ５を映像情報テーブル生成部６に入力する。映像情報テーブル生成部６は、ＦＥＣパケット情報Ｓ５が入力されると、ステップＳ１０３を実行する。
　ステップＳ１０３では、映像情報テーブル生成部６は、ＦＥＣパケット情報Ｓ５にＦＥＣヘッダが含まれると、そのＦＥＣヘッダから先頭ＲＴＰシーケンス番号を抽出する。その後、映像情報テーブル生成部６は、ステップＳ１０９を実行する。
　また、ステップＳ１０２Ｂでは、エラー情報テーブル生成部４は、ＲＴＰパケットＳ３の連続性を確認する。なお、ＲＴＰパケットＳ３の連続性を確認する方法は、ＦＥＣパケット解析部３がＦＥＣパケットＳ４の連続性を確認する方法と同様であるので、詳細な説明は省略する。エラー情報テーブル生成部４は、連続性を確認すると、ステップＳ１０４を実行する。
　ステップＳ１０４では、エラー情報テーブル生成部４は、その連続性を示すエラー情報テーブルＳ６を生成し、その生成したエラー情報テーブルＳ６を映像情報テーブル生成部６に入力する。その後、映像情報テーブル生成部６は、ステップＳ１０９を実行する。
　また、ステップＳ１０５では、ＴＳヘッダ解析部５は、ＲＴＰパケットＳ３に含まれるＴＴＳタイムスタンプ情報の連続性を確認する。
　ＴＴＳタイムスタンプ情報は、ビデオ基準クロック（９０ｋＨｚ）を利用した４バイトの時間情報である。また、ＭＰＥＧ２－ＴＳ形式では、ＴＳパケットは定レートで伝送されるため、このため、ＴＳパケットにパケットロスがなければ、あるＴＳパケット内のＴＴＳタイムスタンプ情報と、次のＴＳパケット内のＴＴＳタイムスタンプ情報との差分である差分時間ΔＴＴＳは一定となる。
　そこで、ＴＳヘッダ解析部５は、ＴＳパケットごとに、そのＴＳパケット内のＴＴＳタイムスタンプ情報と、一つ前のＴＳパケット内のＴＴＳタイムスタンプ情報との差分値を求め、その差分値が一定値からずれているか否かを判断する。
　ＴＳヘッダ解析部５は、その差分値が一定値からずれていると、ＴＳパケットが不連続であると判断し、その差分値が一定値からずれていないと、ＴＳパケットが連続であると判断する。また、ＴＳヘッダ解析部５は、差分値と一定値とのずれ幅から、欠落したＴＳパケットの数を推定する。
　ＴＳヘッダ解析部５は、ＴＴＳタイムスタンプ情報の連続性を確認すると、ステップＳ１０６を実行する。
　ステップＳ１０６では、ＴＳヘッダ解析部５は、ＲＴＰパケットＳ３内に、ビデオストリームを含むＴＳパケットであるビデオパケットが存在するか否かを確認する。
　ＲＴＰパケットＳ３内にビデオパケットがある場合、ＴＳヘッダ解析部５は、ＲＴＰパケットＳ３からそのビデオパケットを抽出する。なお、ＲＴＰパケットＳ３内に複数のＴＳパケットがある場合、ＴＳヘッダ解析部５は、ビデオパケットを、ＴＳパケット単位に分離する。
　ＴＳヘッダ解析部５は、ステップＳ１０６を終了すると、ステップＳ１０７を実行する。
　ステップＳ１０７では、ＴＳヘッダ解析部５は、ビデオパケットの連続性を確認する。ビデオパケットの連続性を確認する方法は、ＦＥＣパケット解析部３がＦＥＣパケットＳ４の連続性を確認する方法と同様であるので、詳細な説明は省略する。なお、ビデオパケットの連続性を確認する方法では、ＲＴＰシーケンス番号の代わりに、ビデオパケット内のＴＳヘッダに含まれる連続性カウンタ値の連続性を、ビデオパケットの連続性として確認する。また、バーストエラーが発生した場合には、ＴＴＳタイムスタンプ情報の連続性を用いて欠落したビデオパケットの数を求める。
　ＴＳヘッダ解析部５は、ビデオパケットの連続性を確認すると、ステップＳ１０８を実行する。
　ステップＳ１０８では、ＴＳヘッダ解析部５は、ピクチャごとに、そのピクチャを有するビデオパケットを特定する。
　具体的には、ＴＳヘッダ解析部５は、各ビデオパケット内のＴＳヘッダに含まれるＰＥＳパケット先頭フラグを確認し、ＰＥＳパケット先頭フラグが「１」のビデオパケットから、次のＰＥＳパケット先頭フラグが「１」のビデオパケットの一つ前のビデオパケットまでを、同一のピクチャを有するビデオパケットとして特定していく。
　ＴＳヘッダ解析部５は、ピクチャを有するビデオパケットを特定すると、そのピクチャの重要度を求める。
　具体的には、先ず、ＴＳヘッダ解析部５は、そのピクチャを有するビデオパケットのそれぞれのＴＳヘッダから、優先度フラグおよびアダプテーションフィールドコントロールフラグを抽出する。
　続いて、アダプテーションフィールドコントロールフラグが「１」の場合、ＴＳヘッダ解析部５は、ビデオパケット内のデータ領域に含まれるアダプテーションフィールドから、ＰＣＲ（program　clock　reference）およびエレメンタリストリームプライオリティフラグを抽出する。なお、ＰＣＲには、映像データのクロック情報が挿入されているが、本発明と直接関係しないので、以下の説明では省略する。
　そして、その抽出した優先度フラグおよびエレメンタリストリームプライオリティフラグのうち「１」を示すフラグがある場合、ＴＳヘッダ解析部５は、そのピクチャを重要と判断する。一方、その抽出した優先度フラグおよびエレメンタリストリームプライオリティフラグのうち「１」を示すフラグがない場合、ＴＳヘッダ解析部５は、そのピクチャを重要でないと判断する。
　ＴＳヘッダ解析部５は、ピクチャの重要度を求めると、そのピクチャを有するビデオパケットの符号量を、ピクチャの符号量として求める。
　ＴＳヘッダ解析部５は、ピクチャの符号量および重要度と、そのピクチャを有するビデオパケットが連続しているか否かを示すビデオ連続性情報とを、ピクチャを有するビデオパケット内のビデオフレーム番号と対応付けたピクチャ情報を、ピクチャごとに生成する。ビデオフレーム番号は、ピクチャの表示順序を示す。
　ＴＳヘッダ解析部５は、そのピクチャ情報をＲＴＰパケットＳ３に含まれるＲＴＰシーケンス番号と対応付けてＴＳヘッダ情報Ｓ７を生成する。ＴＳヘッダ解析部５は、ＴＳヘッダ情報を映像情報テーブル生成部６に入力する。映像情報テーブル生成部６は、ＴＳヘッダ情報が入力されると、ステップＳ１０９を実行する。
　ステップＳ１０９では、映像情報テーブル生成部６は、ステップＳ１０３で抽出した先頭シーケンス番号と、ＴＳヘッダ情報Ｓ７とに基づいて、エラー情報テーブル修正する。
　具体的には、先ず、映像情報テーブル生成部６は、エラー情報テーブルＳ６内の、先頭ＲＴＰシーケンス番号と同じＲＴＰシーケンス番号に、「有」を示すＦＥＣ有無情報を対応付け、その先頭ＲＴＰシーケンス番号と異なるＲＴＰシーケンス番号に、「無」を示すＦＥＣ有無情報を対応付ける。
　続いて、映像情報テーブル生成部６は、エラー情報テーブルＳ６内のＲＴＰシーケンス番号のそれぞれに、ＴＳヘッダ情報Ｓ７内の、そのＲＴＰシーケンス番号に対応付けられたピクチャ情報に含まれるピクチャ有無情報、ビデオ連続性情報およびピクチャの重要度を付ける。
　図８は、修正後のエラー情報テーブルＳ６の一例を示した説明図である。なお、図８において、図６と同じ情報には同じ符号が付してある。また、図８では、図６と同様に、情報長Ｄを５とし、符号長Ｌを２０としている。
　図８において、エラー情報テーブル２０は、ＲＴＰシーケンス番号２１と、ＲＴＰパケットの有無２２と、ＦＥＣパケットの有無２３と、ビデオパケットの有無２４と、ビデオパケットの連続性２５と、ビデオパケットの重要度２６とを含む。
　ＦＥＣパケットの有無２３は、ＦＥＣパケット情報であり、ＲＴＰシーケンス番号２１を先頭ＲＴＰシーケンス番号として有するＦＥＣパケットが存在するか否かを示す。ビデオパケットの有無２４は、ビデオ有無情報であり、ＲＴＰシーケンス番号２１を有するＲＴＰパケットにビデオパケットが存在するか否かを示す。
　ビデオパケットの連続性２５は、ビデオ連続性情報であり、ＲＴＰシーケンス番号２１を有するＲＴＰパケット内のビデオパケットが連続か否かを示す。なお、ビデオパケットの連続性２５は、「有」であると、ビデオパケットが連続であることを示し、「無」であると、ビデオパケットが連続でないことを示す。
　ビデオパケットの重要度２６は、ＲＴＰシーケンス番号２１を有するＲＴＰパケット内のビデオパケットが重要か否かを示す。なお、ビデオパケットの重要度２６は、「有」であると、ビデオパケットが重要であることを示し、「無」であると、ビデオパケットが重要でないことを示す。
　図７に戻る。映像情報テーブル生成部６は、そのＦＥＣ有無情報を対応付けたエラー情報テーブルＳ６と、ＦＥＣパケット情報Ｓ５とに基づいて、ＲＴＰシーケンス番号ごとに、そのＲＴＰシーケンス番号のＲＴＰパケットが、ＦＥＣデータにてエラー訂正が可能な訂正可能パケットか、ＦＥＣデータにてエラー訂正が可能でない訂正不可パケットかを判断する。
　具体的には、先ず、映像情報テーブル生成部６は、エラー情報テーブルＳ６内の「有」を示すＦＥＣ有無情報に対応付けられたＲＴＰシーケンス番号と、そのＲＴＰシーケンス番号を先頭ＲＴＰシーケンス番号として有するＦＥＣパケット情報Ｓ５に含まれるＦＥＣヘッダ内の有効長とに基づいて、ＦＥＣパケットごとに、そのＦＥＣパケットによるエラー訂正の対象となるＲＴＰパケットのＲＴＰシーケンス番号を特定する。
　続いて、映像情報テーブル生成部６は、ＦＥＣパケットごとに、その特定したＲＴＰシーケンス番号のいずれかに、「有」を示すＦＥＣ有無情報が対応付けられているか否かを判断する。
　「有」を示すＦＥＣ有無情報が対応付けられている場合、映像情報テーブル生成部６は、その特定したＲＴＰシーケンス番号に対応付けられたＲＴＰ有無情報の中に、「無」を示すＲＴＰ有無情報が２以上あると、そのＲＴＰシーケンス番号のＲＴＰパケットを訂正不可パケットと判断する。一方、映像情報テーブル生成部６は、そのＲＴＰ有無情報の中に「無」を示すＲＴＰ有無情報が１以下であると、そのＲＴＰシーケンス番号のＲＴＰパケットを訂正可能パケットと判断する。
　一方、「有」を示すＦＥＣ有無情報が対応付けられていない場合、映像情報テーブル生成部６は、その特定したＲＴＰシーケンス番号に対応付けられたＲＴＰ有無情報の中に、「無」を示すＲＴＰ有無情報が１以上あると、そのＲＴＰシーケンス番号のＲＴＰパケットを訂正不可パケットと判断する。一方、映像情報テーブル生成部６は、そのＲＴＰ有無情報の中に「無」を示すＲＴＰ有無情報が０であると、そのＲＴＰシーケンス番号のＲＴＰパケットを訂正可能パケットと判断する。
　映像情報テーブル生成部６は、ＲＴＰパケットが訂正可能パケットか訂正不可パケットかを判断すると、その判断結果を、エラー情報テーブルＳ６内のそのＲＴＰパケットのＲＴＰシーケンス番号に対応付ける。映像情報テーブル生成部６は、ステップＳ１０９を終了すると、ステップ１１０を実行する。
　ステップＳ１１０では、映像情報テーブル生成部６は、そのエラー情報テーブルＳ６と、ＴＳヘッダ情報Ｓ７とに基づいて映像情報テーブルＳ８を生成する。
　映像情報テーブルＳ８では、ピクチャを特定するビデオフレーム番号ごとに、そのピクチャを有するビデオパケットに欠落が存在するか否かを示すパケットロス有無情報と、そのビデオパケットがエラー訂正可能か否かを示すリカバリ情報と、そのピクチャのピクチャタイプ、そのピクチャの符号量、その符号量の平均値である平均符号量とが対応付けられている。
　具体的には、先ず、映像情報テーブル生成部６は、エラー情報テーブルＳ６において、「有」を示すＲＴＰ有無情報に対応付けられたＲＴＰシーケンス番号を確認する。映像情報テーブル生成部６は、その確認したＲＴＰシーケンス番号に対応するピクチャ情報をＴＳヘッダ情報Ｓ７から取得する。
　続いて、映像情報テーブル生成部６は、その取得したピクチャ情報内のビデオフレーム番号ごとに、そのビデオフレーム番号と対応付けられたビデオ有無情報を、そのビデオフレーム番号に対応するパケットロス有無情報として生成する。
　また、映像情報テーブル生成部６は、そのビデオフレーム番号ごとに、そのビデオフレーム番号より前の複数のビデオフレーム番号（３０以上のビデオフレーム番号）に対応する符号量の平均値をそのビデオフレーム番号に対応する平均符号量として生成する。
　さらに、映像情報テーブル生成部６は、そのビデオフレーム番号ごとに、ビデオフレーム番号と対応付けられたピクチャの重要度を確認し、その重要度が重要であることを示すと、そのビデオフレーム番号に対応するピクチャタイプをＩピクチャと判断する。また、映像情報テーブル生成部６は、ビデオフレーム番号ごとに、そのビデオフレーム番号に対応する符号量を、そのビデオフレーム番号に対応する平均符号量から減算して符号量の推移を求める。映像情報テーブル生成部６は、その求めた符号量の推移と、予め保持しているピクチャタイプに応じた符号量の推移とのパタンマッチングを行うことで、Ｉピクチャ以外の、ビデオフレーム番号に対応するピクチャタイプを推定する。なお、符号量の推移からピクチャタイプを推定する方法は、公知であり、例えば、非特許文献１（信学技報ＣＱ２００７－７４）に記載されている。
　そして、映像情報テーブル生成部６は、その確認したＲＴＰシーケンス番号と対応する、ＲＴＰパケットが訂正可能パケットか訂正不可パケットかの判断結果を、その取得したビデオフレーム番号のそれぞれに対応するリカバリ情報として生成する。
　以上により、欠落していないＲＴＰパケットに関する映像情報テーブルＳ８が生成される。欠落したＲＴＰパケットに関する映像情報テーブルＳ８は、欠落していないＲＴＰパケットに関する映像情報テーブルＳ８から生成される。
　具体的には、先ず、映像情報テーブル生成部６は、エラー情報テーブルＳ６において、「無」を示すＲＴＰ有無情報に対応付けられたＲＴＰシーケンス番号を確認する。
　続いて、映像情報テーブル生成部６は、そのＲＴＰシーケンス番号の数を、欠落したＲＴＰパケットの数として求める。また、その映像情報テーブル生成部６は、その欠落したＲＴＰパケットの数と、「無」を示すＲＴＰ有無情報に対応付けられたＲＴＰシーケンス番号の前のＲＴＰシーケンス番号に対応する符号量の推移とに基づいて、欠落したピクチャの数を推定する。
　さらに、映像情報テーブル生成部６は、「無」を示すＲＴＰ有無情報に対応付けられたＲＴＰシーケンス番号の前のＲＴＰシーケンス番号に対応する符号量の推移およびピクチャタイプの推移に基づいて、欠落したピクチャのピクチャタイプを推定する。
　そして、映像情報テーブル生成部６は、「無」を示すＲＴＰ有無情報に対応付けられたＲＴＰシーケンス番号の前のＲＴＰシーケンス番号に対応する符号量の推移とピクチャタイプとに基づいて、「無」を示すＲＴＰ有無情報に対応付けられたＲＴＰシーケンス番号に対応するビデオフレーム番号のそれぞれに対応するリカバリ情報を生成する。
　これにより、欠落したＲＴＰパケットに関する映像情報テーブルＳ８が生成される。
　図９は、映像情報テーブルＳ８の一例を示した説明図である。図９において、映像情報テーブル３０は、ビデオフレーム番号３１と、ビデオパケットロスの有無３２と、ＦＥＣパケットリカバリの有無３３と、ピクチャタイプ３４と、ビデオデータ符号量３５と、ビデオデータ平均符号量３６とを含む。
　ビデオパケットロスの有無３２は、パケットロス有無情報であり、ビデオフレーム番号３１のピクチャを有するビデオパケットに欠落が存在するか否かを示す。ＦＥＣパケットリカバリの有無３３は、リカバリ情報であり、ビデオフレーム番号３１のピクチャを有するビデオパケットがエラー訂正可能か否かを示す。ピクチャタイプ３４は、ビデオフレーム番号３１のピクチャのピクチャタイプであり、Ｉピクチャ、ＢピクチャおよびＰピクチャのいずれかを示す。ビデオデータ符号量３５は、ビデオフレーム番号３１のピクチャの符号量であり、ビデオデータ平均符号量３６は、ビデオデータ符号量３５の平均値である。
　図７に戻る。映像情報テーブル生成部６は、その生成した映像情報テーブルＳ８を映像品質推定部７に入力する。映像品質推定部７は、映像情報テーブルＳ８が入力されると、ステップＳ１１１を実行する。
　ステップＳ１１１では、映像品質推定部７は、映像情報テーブルＳ８内の、ＲＴＰ有無情報が「無」を示し、ＦＥＣ有無情報が「無」を示すビデオフレーム番号を特定する。この特定されたビデオフレーム番号に対応するピクチャが、欠落したＲＴＰパケットに含まれる、ＦＥＣデータでエラーが訂正できない訂正不可ピクチャとなる。
　映像品質推定部７は、その特定したビデオフレームの数を、訂正不可ピクチャの数として求め、その特定した各ビデオフレームに対応するピクチャタイプを、訂正不可ピクチャのピクチャタイプとして求める。
　その訂正不可ピクチャがＩピクチャの場合、ビデオストリームは、次のＩピクチャが出現するまでは正常なデータに復帰できないため、映像品質の低下を多大な影響を与える。一方、その訂正不可ピクチャがＢピクチャやＰピクチャの場合、ビデオストリームは、そのフレーム内の品質劣化であり、映像品質の低下にはあまり影響を与えない。
　このため、映像品質推定部７は、エラー訂正不可ピクチャがＩピクチャの場合、映像品質Ｓ９を最低レベルにし、エラー訂正不可ピクチャがＰピクチャの場合、映像品質Ｓ９を最低レベルより良い中レベルにし、エラー訂正不可ピクチャがＢピクチャ場合、映像品質Ｓ９を中レベルより良い高レベルにし、エラー訂正不可ピクチャがない場合、映像品質Ｓ９を高レベルより良い最高レベルにする。
　また、映像品質推定部７は、エラー訂正不可ピクチャが複数ある場合、各エラー訂正不可ピクチャのピクチャタイプに応じて映像品質に重み付けを行い、その重み付けを行った映像品質の和を映像品質Ｓ９として生成してもよい。
　なお、映像品質推定部７による映像品質の推定方法は、例えば、特許文献１や非特許文献１で用いた方法でもよい。
　次に効果を説明する。
　ＦＥＣパケット解析部３は、ＦＥＣパケットの連続性を確認する。エラー情報テーブル生成部４は、映像パケットの連続性を確認する。推定部は、それらの連続性に基づいて、欠落した映像パケットに含まれる。ＦＥＣデータでエラーが訂正できない映像データを訂正不可データとして推定する。推定部は、その訂正不可データに基づいて、映像データの映像品質を推定する。
　この場合、ＦＥＣパケットの連続性と映像パケットの連続性とに基づいて訂正不可データが推定される。また、訂正不可データに基づいて映像データの映像品質が推定される。
　したがって、映像品質を推定するために、エラー訂正を行う必要がなくなるので、ＴＳパケットを遅延させなくてもよくなり、大容量のメモリが必要なくなる。
　また、本実施形態では、推定部は、映像パケットのＴＳヘッダを解析して、訂正不可データのピクチャタイプを推定し、その推定したピクチャタイプに基づいて映像品質を推定する。
　ピクチャのエラー訂正ができない場合、そのピクチャのピクチャタイプに応じてエラー訂正が可能になるまでの時間が異なるので、エラー訂正ができないピクチャタイプに応じて映像品質が変化する。したがって、本実施形態では、映像品質がピクチャタイプに基づいて推定されるので、映像品質を的確に推定することが可能になる。
　また、本実施形態では、推定部は、映像パケットのＴＳヘッダを解析して、映像パケットに含まれる映像データの符号量を求め、その符号量に基づいて、訂正不可ピクチャのピクチャタイプを推定する。
　通常、ピクチャの符号量は、通常ピクチャタイプごとに異なるので、ピクチャの符号量に応じてピクチャタイプが推定できる。このため、ピクチャタイプを的確に推定することが可能になる。
　なお、以上説明した映像品質推定装置の機能は、その機能を実現するためのプログラムを、コンピュータにて読み取り可能な記録媒体に記録し、この記録媒体に記録されたプログラムをコンピュータに読み込ませて実行させることで実現されてもよい。
　また、その映像品質推定装置の機能を実現するためのプログラムを記録する、コンピュータにて読み取り可能な記録媒体も本発明の一実施形態である。
　以上、実施形態を参照して本願発明を説明したが、本願発明は、上記実施形態に限定されたものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更を行うことができる。
　この出願は、２００９年２月１０日に出願された日本出願特願２００９－２８５９９号公報を基礎とする優先権を主張し、その開示の全てをここに取り込む。

Claims (7)

  1. 　映像データがパケット化された映像パケットと、前記映像データのエラーを訂正するための訂正用データがパケット化された訂正用パケットと、を受け付ける入力手段と、
    　前記入力手段が受け付けた映像パケットの連続性を確認する第一確認手段と、
    　前記入力手段が受け付けた訂正用パケットの連続性を確認する第二確認手段と、
    　前記第一確認手段および前記第二確認手段にて確認された各連続性に基づいて、欠落した映像パケットに含まれる、前記訂正用データでエラーが訂正できない映像データを、訂正不可データとして推定し、該推定した訂正不可データに基づいて前記映像データの映像品質を推定する推定手段と、を含む映像品質推定装置。
  2. 　請求項１に記載の映像品質推定装置において、
    　前記推定手段は、前記入力手段が受け付けた映像パケットのヘッダ情報を解析して、前記訂正不可データのピクチャタイプを推定し、該ピクチャタイプに基づいて、前記映像品質を推定する、映像品質推定装置。
  3. 　請求項２に記載の映像品質推定装置において、
    　前記推定手段は、前記ヘッダ情報を解析して、前記入力手段が受け付けた映像パケットに含まれる映像データの符号量を求め、該符号量に基づいて、前記訂正不可データのピクチャタイプを推定する、映像品質推定装置。
  4. 　映像品質推定装置による映像品質推定方法であって、
    　映像データがパケット化された映像パケットと、前記映像データのエラーを訂正するための訂正用データがパケット化された訂正用パケットと、を受け付ける入力ステップと、
    　前記受け付けられた映像パケットの連続性を確認する第一確認ステップと、
    　前記受け付けられた訂正用パケットの連続性を確認する第二確認ステップと、
    　前記確認された各連続性に基づいて、欠落した映像パケットに含まれる、前記訂正用データでエラーが訂正できない映像データを、訂正不可データとして推定し、該推定した訂正不可データに基づいて前記映像データの映像品質を推定する推定ステップと、を含む映像品質推定方法。
  5. 　請求項４に記載の映像品質推定方法において、
    　前記推定ステップでは、前記受け付けられた映像パケットのヘッダ情報を解析して、前記訂正不可データのピクチャタイプを推定し、該ピクチャタイプに基づいて、前記映像品質を推定する、映像品質推定方法。
  6. 　請求項５に記載の映像品質推定方法において、
    　前記推定ステップでは、前記ヘッダ情報を解析して、前記受け付けられた映像パケットに含まれる映像データの符号量を求め、該符号量に基づいて、前記訂正不可データのピクチャタイプを推定する、映像品質推定方法。
  7. 　コンピュータに、
    　映像データがパケット化された映像パケットと、前記映像データのエラーを訂正するための訂正用データがパケット化された訂正用パケットと、を受け付ける手順と、
    　前記受け付けられた映像パケットの連続性を確認する手順と、
    　前記受け付けられた訂正用パケットの連続性を確認する手順と、
    　前記確認された各連続性に基づいて、欠落した映像パケットに含まれる、前記訂正用データでエラーが訂正できない映像データを、訂正不可データとして推定し、該推定した訂正不可データに基づいて前記映像データの映像品質を推定する手順と、を実行させるプログラムを記録した記録媒体。
PCT/JP2010/050309 2009-02-10 2010-01-14 映像品質推定装置および映像品質推定方法 Ceased WO2010092848A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US13/003,844 US8254464B2 (en) 2009-02-10 2010-01-14 Image quality estimation apparatus and image quality estimation method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2009028599A JP4544435B2 (ja) 2009-02-10 2009-02-10 映像品質推定装置、映像品質推定方法およびプログラム
JP2009-028599 2009-02-10

Publications (1)

Publication Number Publication Date
WO2010092848A1 true WO2010092848A1 (ja) 2010-08-19

Family

ID=42561695

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/050309 Ceased WO2010092848A1 (ja) 2009-02-10 2010-01-14 映像品質推定装置および映像品質推定方法

Country Status (3)

Country Link
US (1) US8254464B2 (ja)
JP (1) JP4544435B2 (ja)
WO (1) WO2010092848A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2525586A1 (en) * 2011-05-18 2012-11-21 Telefonaktiebolaget L M Ericsson (publ) Method and arrangement for supporting quality estimation of streamed video
CN103155515A (zh) * 2010-09-29 2013-06-12 瑞典爱立信有限公司 确定ip分组的丢失
JP2015050627A (ja) * 2013-09-02 2015-03-16 西日本電信電話株式会社 映像信号評価装置及び障害切り分けシステム
CN110099250A (zh) * 2019-04-18 2019-08-06 浙江工业大学 一种监控视频质量判断方法及播放控制装置

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100023842A1 (en) * 2008-07-25 2010-01-28 Nortel Networks Limited Multisegment loss protection
JP5119284B2 (ja) 2010-03-05 2013-01-16 日立コンシューマエレクトロニクス株式会社 記録媒体、再生及び記録方法、再生及び記録装置
JP5895238B2 (ja) 2011-12-01 2016-03-30 パナソニックＩｐマネジメント株式会社 通信装置、通信方法、及び通信プログラム
US20130298175A1 (en) * 2012-05-02 2013-11-07 International Business Machines Corporation Constructing a customized message in a video-on-demand service
KR102093408B1 (ko) * 2012-07-19 2020-04-14 한국전자통신연구원 동일 포트에 멀티플렉싱 된 다중 패킷 스트림의 패킷오류 구분을 선택적으로 수행하는 방법 및 그 장치
FI3972135T3 (fi) * 2013-07-18 2024-03-20 Samsung Electronics Co Ltd Laite ja menetelmä paketin lähettämiseksi/vastaanottamiseksi multimediaviestintäjärjestelmässä
JP6595218B2 (ja) * 2015-06-04 2019-10-23 日本放送協会 連接符号を用いた受信装置及びチップ
CN108809893B (zh) * 2017-04-27 2020-03-27 华为技术有限公司 一种视频质量评估方法和设备
CN111385523B (zh) * 2018-12-27 2022-10-28 北京图森智途科技有限公司 一种数据接收方法、图像处理设备和汽车

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008005108A (ja) * 2006-06-21 2008-01-10 Nippon Telegr & Teleph Corp <Ntt> 映像品質推定装置、映像品質管理装置、映像品質推定方法、映像品質管理方法、およびプログラム
JP2008527896A (ja) * 2005-01-18 2008-07-24 エヌエックスピー ビー ヴィ 改良型ｉｐデータグラムの逆カプセル化
JP2008211579A (ja) * 2007-02-27 2008-09-11 Nippon Telegr & Teleph Corp <Ntt> 映像品質推定方法および映像通信システム

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5457701A (en) * 1994-01-06 1995-10-10 Scientific-Atlanta, Inc. Method for indicating packet errors in a packet-based multi-hop communications system
JP2002209234A (ja) * 2001-01-11 2002-07-26 Fujitsu Ltd 通信システム
JP2004343238A (ja) * 2003-05-13 2004-12-02 Nippon Telegr & Teleph Corp <Ntt> コンテンツ配信方法及びコンテンツ配信システム
JP2006157223A (ja) * 2004-11-26 2006-06-15 Nippon Telegr & Teleph Corp <Ntt> ユーザ体感品質推定システムおよび方法、ユーザ体感品質推定装置、受信状況情報送信装置、送信端末、受信端末
CA2539367A1 (en) * 2005-03-30 2006-09-30 At&T Corp. Loss tolerant transmission control protocol
JP4377357B2 (ja) * 2005-07-07 2009-12-02 日本電信電話株式会社 映像品質推定装置および映像品質推定方法
US7617434B1 (en) * 2005-12-13 2009-11-10 Sprint Communications Company L.P. Adaptive error correction
JP4451857B2 (ja) 2006-05-09 2010-04-14 日本電信電話株式会社 映像品質パラメータ推定装置、方法、およびプログラム
JP4313391B2 (ja) * 2006-12-13 2009-08-12 株式会社日立コミュニケーションテクノロジー 光集線装置および光加入者装置
JP4940998B2 (ja) 2007-02-27 2012-05-30 Ｋｄｄｉ株式会社 Ｉｐ／ｒｆ変換装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008527896A (ja) * 2005-01-18 2008-07-24 エヌエックスピー ビー ヴィ 改良型ｉｐデータグラムの逆カプセル化
JP2008005108A (ja) * 2006-06-21 2008-01-10 Nippon Telegr & Teleph Corp <Ntt> 映像品質推定装置、映像品質管理装置、映像品質推定方法、映像品質管理方法、およびプログラム
JP2008211579A (ja) * 2007-02-27 2008-09-11 Nippon Telegr & Teleph Corp <Ntt> 映像品質推定方法および映像通信システム

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103155515A (zh) * 2010-09-29 2013-06-12 瑞典爱立信有限公司 确定ip分组的丢失
EP2622819A4 (en) * 2010-09-29 2014-05-07 Ericsson Telefon Ab L M DETERMINING THE LOSS OF IP PACKAGES
US9363684B2 (en) 2010-09-29 2016-06-07 Telefonaktiebolaget Lm Ericsson (Publ) Determining loss of IP packets
CN103155515B (zh) * 2010-09-29 2016-06-29 瑞典爱立信有限公司 确定ip分组的丢失
EP2525586A1 (en) * 2011-05-18 2012-11-21 Telefonaktiebolaget L M Ericsson (publ) Method and arrangement for supporting quality estimation of streamed video
JP2015050627A (ja) * 2013-09-02 2015-03-16 西日本電信電話株式会社 映像信号評価装置及び障害切り分けシステム
CN110099250A (zh) * 2019-04-18 2019-08-06 浙江工业大学 一种监控视频质量判断方法及播放控制装置

Also Published As

Publication number Publication date
JP2010187097A (ja) 2010-08-26
US20110289540A1 (en) 2011-11-24
JP4544435B2 (ja) 2010-09-15
US8254464B2 (en) 2012-08-28

Similar Documents

Publication Publication Date Title
JP4544435B2 (ja) 映像品質推定装置、映像品質推定方法およびプログラム
US8819714B2 (en) Ratings and quality measurements for digital broadcast viewers
JP7279767B2 (ja) 送信方法および送信装置
US8301982B2 (en) RTP-based loss recovery and quality monitoring for non-IP and raw-IP MPEG transport flows
US7796598B2 (en) Synchronizing redundant video streams encapsulated in IP/UDP packets
JP5168283B2 (ja) 映像品質監視方法及び配信サーバ及びクライアント
JP6617809B2 (ja) 復号装置、復号方法、および復号用プログラム
JP2011521576A (ja) インターラクティブマークをストリーミング・コンテンツに同期させるためのデバイス、及び方法
US20120257492A1 (en) Digital receiver and corresponding digital transmission system server
JP6593423B2 (ja) 受信機器、および復号・提示方法
US9647951B2 (en) Media stream rate reconstruction system and method
JP7255301B2 (ja) 切り替え方法、ｉｐ再送信システム、ｉｐ再送信装置および制御装置
WO2011155099A1 (ja) 映像表示装置
JP2019087958A (ja) 放送再送信装置、放送再送信方法およびモニタ方法
JPWO2010087129A1 (ja) ピクチャタイプ推定装置、方法、及びプログラム
JP2014003429A (ja) 伝送パケットの配信方法
JP2006014153A (ja) パケットエラー監視型ｍｐｅｇデコーダ、ｍｐｅｇ映像伝送システム及びｍｐｅｇ映像伝送方法
JP6763440B2 (ja) 受信装置、および通信システム
Joskowicz et al. Measuring the incidence of packet loss on video quality in digital television
Joskowicz et al. Considerations on packet loss incidence on the perceived video quality in digital television
JPWO2009040955A1 (ja) エラー判定装置およびエラー判定方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10741128

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 13003844

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10741128

Country of ref document: EP

Kind code of ref document: A1