WO2002017637A1 - Procede de transmission de donnees et procede de relais de donnees - Google Patents

Procede de transmission de donnees et procede de relais de donnees Download PDF

Info

Publication number
WO2002017637A1
WO2002017637A1 PCT/JP2001/006719 JP0106719W WO0217637A1 WO 2002017637 A1 WO2002017637 A1 WO 2002017637A1 JP 0106719 W JP0106719 W JP 0106719W WO 0217637 A1 WO0217637 A1 WO 0217637A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
data transmission
video
packet
relay
Prior art date
Application number
PCT/JP2001/006719
Other languages
English (en)
French (fr)
Inventor
Hiroshi Arakawa
Tomoaki Itoh
Junichi Sato
Takao Yamaguchi
Akihiro Miyazaki
Koichi Hata
Original Assignee
Matsushita Electric Industrial Co., Ltd.
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 Matsushita Electric Industrial Co., Ltd. filed Critical Matsushita Electric Industrial Co., Ltd.
Priority to AU2001276731A priority Critical patent/AU2001276731A1/en
Priority to EP01954445A priority patent/EP1313318A1/en
Publication of WO2002017637A1 publication Critical patent/WO2002017637A1/ja

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4381Recovering the multiplex stream from a specific network, e.g. recovering MPEG packets from ATM cells
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/65Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/70Media network packetisation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/165Combined use of TCP and UDP protocols; selection criteria therefor
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/166IP fragmentation; TCP segmentation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/167Adaptation for transition between two IP versions, e.g. between IPv4 and IPv6
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M15/00Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/48Secure or trusted billing, e.g. trusted elements or encryption
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M15/00Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/56Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP for VoIP communications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M15/00Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/80Rating or billing plans; Tariff determination aspects
    • H04M15/8016Rating or billing plans; Tariff determination aspects based on quality of service [QoS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234327Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into layers, e.g. base layer and one or more enhancement layers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234381Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by altering the temporal resolution, e.g. decreasing the frame rate by frame skipping
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2347Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving video stream encryption
    • H04N21/23476Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving video stream encryption by partially encrypting, e.g. encrypting the ending portion of a movie
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2381Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [IP] network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/4405Processing 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 stream decryption
    • H04N21/44055Processing 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 stream decryption by partially decrypting, e.g. decrypting a video stream that has been partially encrypted
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61Network physical structure; Signal processing
    • H04N21/6106Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/631Multimode Transmission, e.g. transmitting basic layers and enhancement layers of the content over different transmission paths or transmitting with different error corrections, different keys or with different transmission protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643Communication protocols
    • H04N21/64322IP
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643Communication protocols
    • H04N21/6437Real-time Transport Protocol [RTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/16Analogue secrecy systems; Analogue subscription systems
    • H04N7/167Systems rendering the television signal unintelligible and subsequently intelligible
    • H04N7/1675Providing digital key or authorisation information for generation or regeneration of the scrambling sequence
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M2215/00Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/01Details of billing arrangements
    • H04M2215/0156Secure and trusted billing, e.g. trusted elements, encryption, digital signature, codes or double check mechanisms to secure billing calculation and information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M2215/00Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/20Technology dependant metering
    • H04M2215/202VoIP; Packet switched telephony
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M2215/00Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/74Rating aspects, e.g. rating parameters or tariff determination apects
    • H04M2215/7414QoS

Definitions

  • the present invention relates to a transmission method and a relay method for video / audio data flowing through a network, and particularly to a case where the data is subjected to an encryption process or an error correction encoding process and transmitted.
  • IP Internet Protocol
  • IP v6 Internet Protocol Version D lPvo Specincanon
  • RFC 1883 Internet Engineering Taskforce, Dec. 1995
  • Multicast is known as a mechanism for delivering data to multiple points.
  • IPsec is a mechanism of encryption (S. Kent et al., “Security Architecture for the Internet Protocol”, RFC 2401, Internet Engineering Taskforce, Nov. 1998).
  • VOD Video On Demand
  • PPV Payment Per View
  • the person who paid the fee receives the key for decryption, decrypts it with the received key, and reproduces the multimedia.
  • STB Set Top Box
  • encryption / decryption is realized by hardware, but in the case of a network, a general-purpose computer is often used, and encryption / decryption is performed by hardware. Few.
  • the video bit rate is about 2 to 3 Mbps for NTSC (National Television Standards Committed) and about 10 to 20 Mbps for HDTV (High Definition Television). If encryption processing is performed and encryption / decryption processing is required in the receiving device, there is a possibility that the processing cannot be completed by software (Issue 1).
  • Networks tend to favor decentralized rather than centralized management because of their historical background. This trend is due to the bandwidth in multimedia distribution. This also applies to reservations. That is, instead of the resource allocation type RSVP (R. Braden et al., “Resource ReSerVation Protocol (RSVP)-Version 1 Functional Specification", RFC 2205, Internet Engineering Taskforce, Sep. 1997), priority control type DiffSen ⁇ It has become mainstream (S. Blake et al., "An Architecture for Differentiated Services", RFC 2475, Internet Engineering Taskforce, Dec. 1998). Due to the nature of this DiffSerU, some packet loss occurs. However, a mechanism has not been provided in which the image quality of the media changes (degrades) gently in response to packet loss (Issue 2).
  • RSVP Resource ReSerVation Protocol
  • RTP Real Time Transport Protocol
  • RTP Real Time Transport Protocol
  • RTP Real Time Transport Protocol
  • An object of the present invention is to solve each of the above problems.
  • a first data transmission method provides a data sequence obtained by encoding video or audio by converting video or audio time, video space, video or audio quality, or Adopted a method that includes a step of dividing based on either the information given by the video or audio producer or a combination thereof, and a step of encrypting only a part of these divided data strings Things.
  • the second data transmission method provides a method of encoding a video or audio data sequence by converting video or audio time, video space, video space, video or audio And a step of performing an error correction encoding process on only a part of the divided data sequence based on the quality of the data or information given by the video or audio producer, or a combination thereof. Is adopted.
  • a first data relay method including a step of classifying a column and a step of allocating the divided data sequence to one of a plurality of queues based on the classification result, wherein a frequency of the relay process is set to This method differs for each queue, or the method of selecting a queue for extracting data during relay processing is made variable, or the method of discarding data that cannot be processed is different for each queue.
  • a third data transmission method is a data transmission method in which data is divided into buckets by a transmission device and transmitted, wherein the transmission device includes: A first step of subdividing a packet to generate a subdivided bucket; And a second step of generating an error correction bucket from at least one subdivided packet and transmitting the packet.
  • FIG. 1 is a block diagram showing the configuration of the data transmission device according to the first embodiment of the present invention.
  • FIG. 2 is a diagram for explaining an operation example of the dividing unit in FIG.
  • FIG. 3 is a flowchart illustrating an operation example of the transmitting apparatus in FIG.
  • FIG. 4 is a flowchart illustrating an operation example of the receiving device in FIG.
  • FIG. 5 is a block diagram showing the configuration of the data transmission device according to the second embodiment of the present invention.
  • FIG. 6 is a diagram for explaining an operation example of the division unit in FIG. 5 when handling video data.
  • FIG. 7 is a diagram for explaining an operation example of the transmission unit in FIG. 5 when handling audio data.
  • FIG. 8 is a diagram for explaining an operation example of the transmission unit in FIG. 5 when handling video data and audio data.
  • FIG. 9 is a block diagram showing a configuration of the data transmission device according to the third embodiment of the present invention.
  • FIG. 10 is a block diagram showing a configuration of a data transmission system including a data relay device according to the fourth embodiment of the present invention.
  • FIG. 11 is a conceptual diagram for explaining a data relay method according to the fifth embodiment of the present invention.
  • FIG. 12 is a flowchart showing the recording operation to the queue in each of the groups shown in FIG.
  • FIG. 13 is a flowchart showing the scheduling operation of the delivery process in each router (data relay device) in FIG.
  • FIG. 14 is a conceptual diagram for explaining a data relay method according to the sixth embodiment of the present invention. It is.
  • FIG. 15 is a flowchart showing a propagation delay time measuring operation in a specific router (data relay device) in FIG.
  • FIG. 16 is a flowchart showing the scheduling operation of the delivery process in the same router (the one-time relay device) in FIG.
  • FIG. 17 is a block diagram illustrating a configuration example of a transmission device for realizing the data transmission method according to the seventh embodiment of the present invention.
  • FIG. 18 is a diagram for explaining an operation example of the subdivision unit and the FEC calculation unit in FIG.
  • FIG. 19 is a diagram for explaining an operation example of the packetizing unit in FIG.
  • FIG. 20 is a flowchart showing an operation example of the transmitting apparatus of FIG.
  • FIG. 21 (a) shows the data transmission according to the conventional technique
  • FIG. 21 (b) shows the data transmission according to the seventh embodiment of the present invention.
  • FIG. 22 is a block diagram showing a configuration example of a receiving device for realizing the data transmission method according to the eighth embodiment of the present invention.
  • FIG. 23 is a block diagram showing a configuration example of a receiving device for realizing the data transmission method according to the ninth embodiment of the present invention.
  • FIG. 24 is a diagram for explaining the effect of the data transmission method according to the ninth embodiment of the present invention.
  • FIG. 25 is a block diagram illustrating a configuration example of a transmission device and a reception device for implementing the data transmission method according to the tenth embodiment of the present invention.
  • FIG. 1 shows a configuration of a data transmission device according to a first embodiment of the present invention.
  • MPEG-1 ISO / IEC 13818-2
  • MPEG Motion Picture Coding Experts Group
  • IPv6 IPv6
  • a transmitting apparatus 100 is a video encoding apparatus. It receives a packet stream as input and transmits it, and includes a dividing unit 101, an encrypting unit 102, and a transmitting unit 103.
  • the receiving device 110 receives the packet from the transmitting device 100 as an input and outputs a bit stream.
  • the receiving device 113, the encryption / decryption unit 112, and the reconstruction unit 111 With one.
  • FIG. 2 shows an operation example of the dividing unit 101 in FIG.
  • the dividing unit 101 divides a bit stream forming a video based on a reproduction time of a video decoded by the bit stream.
  • M PEG-1 there is a distinction between an (Intra) frame, a P (Predictive) frame and a B (Bidirectionally predictive) frame.
  • the number of frames in one GOP is 15 and the interval between I or P frames is 3.
  • the encryption unit 102 performs the encryption processing only on the leftmost port (that is, the port through which the bit stream corresponding to the I frame is transmitted).
  • IPv6 each output of the dividing unit 101 is assigned to each port of TCP (Transmission Control Protocol) or UDP (User Datagram Protocol), and in the IP layer, a bit stream corresponding to an I frame is transmitted.
  • Configure IPS eC processing only for the ports to be transmitted R. Thayer et al., "IP security Document Roadmap", RFC 2411, Internet Engineering Taskforce, Nov. 1998, S. Kent et al. See “IP Encapsulating Security Payload (ESP)", RFC 2406, Internet Engineering Taskforce, Nov. 1998). That is, the encryption unit 102 and the transmission unit 103 are composed of a TCP or UDP layer, an IP layer, a data link layer, and a physical layer.
  • the receiving unit 113 receives a packet output from the transmitting device 100 for each port. Also, a bit stream corresponding to an I frame is transmitted. The original packet is restored by processing the port with the encryption / decryption unit 112.
  • the receiving unit 113 and the encryption / decryption unit 112 include a TCP or UDP layer, an IP layer, a data link layer, and a physical layer.
  • the reconstruction unit 111 receives the packets from the reception unit 113 and the signal decoding unit 112, and restores the original bit stream. This restoration is performed by arranging the packets in ascending order immediately after the TI.
  • the bit stream obtained by encoding the video is divided by the dividing unit 101, and the encrypting unit 102 performs an encryption process on only a part of the divided bucket.
  • the signal decoding process required is limited to only some of the packets.
  • the time required for the encryption / decryption processing in the receiving device 110 can be reduced, and the conventional problem 1 can be solved.
  • the purpose of ensuring that only those who possess the decryption key can view the video remains intact. Due to the nature of video coding, if the I-frame cannot be recovered, the subsequent video cannot be recovered.
  • the encryption process is performed only on the I frame, but the number of ports for performing the encryption process is increased or decreased according to the performance of the CPU (Central Processing Unit) of the transmitting device 100. You may. Further, in receiving apparatus 110, only a part of the signal may be decoded in accordance with the CPU performance. In this case, the video cannot be played at the full frame rate (30 frames / s), but it is possible to obtain a video within the range that can be processed by the CPU performance.
  • the CPU Central Processing Unit
  • FIG. 3 shows an operation example of the transmitting apparatus 100 in FIG.
  • video data is read (step 301), and byte strings 0x00, 0x00, 0x01, 0x00 representing a PSC (Picture Start Code) are detected (step 302).
  • the PCT Physical Coding Type
  • the process branches to step 304 for I, to step 305 for P, and to step 306 for B.
  • steps 304, 305, and 306 a packet is generated and transmitted to each port. At this time, a unique sequence number is assigned to each packet.
  • the packet is subjected to IPsec encryption processing. Then, check in step 307 if it is the end of the night If not, return to step 301.
  • FIG. 4 shows an operation example of the receiving apparatus 110 in FIG. According to FIG. 4, packets are received from each UDP port in steps 401, 402, and 403.
  • step 401 the packet is subjected to symbol decoding of IPsec.
  • step 400 the data sequence is extracted from the packet, and the data sequence reconstructed by concatenating the sequence numbers is passed to the upper layer. Then, in step 405, it is checked whether the end of the day is over. If not, the process returns to the branch point of steps 401, 402, 403.
  • FIG. 5 shows the configuration of the data transmission device according to the second embodiment of the present invention.
  • reference numeral 500 denotes a transmission device, which receives a bit stream obtained by encoding a video as an input, and transmits the bit stream.
  • a receiving device 510 receives a bucket from the transmitting device 500 as an input and outputs a bit stream.
  • the division unit 501, the transmission unit 503, the reconstruction unit 5111, and the reception unit 5113 are the same as those described in the first embodiment.
  • Reference numeral 52 denotes an error correction encoding unit, and reference numeral 52 denotes an error correction decoding unit. According to FIG.
  • a bit stream obtained by encoding a video is divided by a dividing unit 501, and only a part of the divided packet, that is, an I frame is divided by an error correction encoding unit 502.
  • the error correction coding process is applied only to the packet according to.
  • an RFC2733 scheme may be adopted as the error correction coding scheme.
  • the divided data stream is transmitted with different UDP port numbers or different payload types of: RTP.
  • the FEC data is transmitted as another RTP payload.
  • FIG. 6 shows another operation example of the dividing unit 501 in FIG. 5 when video data is handled. In the above example, division based on time is performed, but division based on space may be performed.
  • reference numeral 601 denotes an example of screen division, and the upper and lower peripheral portions are composed of two slices # 1 and # 23.
  • the left peripheral part is slice # 2, 5, 8, 11, 11, 14, 17, and 20, and the right peripheral part is slice # 4, 7, 10, 13, 16, 16, 19, and 22. It is composed of seven pieces.
  • Reference numeral 602 denotes a bit stream in which slices are arranged in the order of numbers.
  • the dividing unit 501 extracts seven slices # 3, 6, 9, 12, 15, 15, 18 and 21 for each frame as a central part, Output to part 502. In this way, even if an error less than a certain value occurs in the center, the error can be corrected. That is, it is possible to adopt a configuration in which the image quality hardly deteriorates in the central portion where the image quality deterioration of the image is easily noticeable subjectively.
  • the division unit 101 in FIG. 1 in the first embodiment may perform division based on FIG.
  • the division unit 501 may perform division based on image quality.
  • the coding result of the DCT (Discrete Cosine Transform) coefficient in each macroblock may be divided into a low-frequency component and a high-frequency component. By doing so, it is possible to correct errors in low-frequency components even if they occur below a certain value.
  • a device is provided that does not fail to decode immediately when an error occurs, but can decode a reasonable image with a low SZN when the error is below a certain value. can do.
  • the same division based on the image quality may be performed in the division unit 101 in FIG. 1 in the first embodiment.
  • the division unit 501 may perform division based on information given by the video producer.
  • the information given by the video creator is any of the time zone in which the video is broadcast, the genre of the video, the performer of the video, the commercial part in the video, the content set by the creator, or any of these Means a combination.
  • information representing each performer is associated with a bit stream obtained by encoding a video. Information about each performer is recorded for each GOP What should I do? Then, only the GOP in which a specific performer appears can be extracted and assigned to a port passing through the error correction coding unit 502, and the other GOPs can be assigned to another port.
  • the selection of a specific performer may be made based on the profile of the receiver or by a request from the receiving device 5 10. In the first embodiment, the same division may be performed in the division unit 101 in FIG. 1 based on the information given by the video producer.
  • FIG. 7 shows an operation example of the transmitting section 503 in FIG. 5 when handling audio data.
  • FEC data error correction information
  • Another voice data bucket 703 that summarizes the stored voice data is generated, and these buckets are transmitted.
  • FIG. 8 shows an operation example of the transmitting unit 503 in FIG. 5 when handling video data and audio data.
  • the first data stream includes the video data having the lower priority
  • the second data stream includes the audio data having the higher priority.
  • an FEC data error correction information
  • a video data packet 802 in which the FEC data and the video data are combined is generated.
  • FIG. 9 shows the configuration of the data transmission device according to the third embodiment of the present invention.
  • the embodiment is a combination of the first embodiment (including its modified example) and the second embodiment (including its modified example).
  • reference numeral 900 denotes a transmission device, which receives a bit stream obtained by encoding a video as an input and transmits the bit stream.
  • a receiving device 910 receives a packet from the transmitting device 900 and outputs a bit stream.
  • the dividing unit 901, the encrypting unit 903, the transmitting unit 904, the reconstructing unit 911, the encrypting / decrypting unit 913, and the receiving unit 911 are those described in the first embodiment. Is equivalent to Further, the error correction encoding unit 92 and the error correction decoding unit 912 correspond to those described in the second embodiment.
  • the bit stream obtained by encoding the video is divided by the division unit 901, and the error correction encoding unit 902 performs error correction encoding on only a part of the divided packets.
  • the encryption unit 903 applies encryption processing to only a part of the divided packets, so that the conventional problems 1 and 2 can be simultaneously solved.
  • the encryption processing and the error correction encoding processing are performed only on the I frame, but another combination may be used.
  • error correction coding processing may be performed on I and P frames, and encryption processing may be performed only on I frames.
  • FIG. 10 shows a configuration of a data transmission system including a data relay device 1000 according to the fourth embodiment of the present invention.
  • encryption processing and Z or error correction coding processing are performed on a part of the data string.
  • the processing is performed together with the processed data. If the data were relayed in the same way without distinguishing between the data that did not exist, effective results could not be obtained.
  • it is expected that important data that has been subjected to encryption processing and data that has been subjected to error correction coding processing will be delivered more reliably than other data.
  • the present embodiment satisfies this requirement.
  • reference numerals 10 10 and 10 20 denote the first to third embodiments, respectively.
  • reference numeral 1030 denotes the receiving apparatus described in the first to third embodiments (including its modifications).
  • fragments of each bit stream corresponding to 1, P, and B frames are allocated to UDP ports 10001, 1002, and 10003, respectively.
  • the data relay device 1000 includes a classification unit 1001, an I-frame queue 1002, a P-frame queue 1003, a B-frame queue 1004, and an output unit 1005.
  • the classification unit 1001 receives the packets from the transmission devices 1010 and 1020, classifies the packets based on the UDP port number, and enters the result into the queues 1002, 1003, and 1004. That is, packets with UDP port numbers 10001, 1002, and 10003 are inserted into the queues 1002, 1003, and 1004, respectively.
  • the output unit 1005 differs in the processing frequency or queue selection method for each queue or the packet discarding method when each queue is likely to overflow.
  • the I-frame queue 1002 is given priority for relay processing (Priority Queueing). This changes the way queues are selected.
  • the processing capacity of the data repeater 1000 is fairly distributed based on the amount of data in each queue (Fair Queueing), and evenly distributed, but the queue 1002 for I-frames is given a little priority. Processing (weighted fair queuing) is also possible. Thereby, the processing frequency for each queue can be changed. Also, the discard probability may be a function of the average amount of data remaining in each queue (average queue length).
  • the discard probability of the queue 1002 for e-frames may be made larger than the discard probability of the other queues 1003 and 1004.
  • this Can be solved by applying a stronger error correction coding scheme.
  • the data corresponding to each frame divided in each of transmitting apparatuses 1010 and 1020 is re-classified by classification section 1001, and the result of this classification is inserted into queues 1002, 1003, and 1004. Then, in the output unit 1005, different relay processing is performed for each queue. In this way, each data can be relayed separately.
  • the packet discarding method in the output unit 1005 may be associated with, for example, the bucket loss rate detected by the receiving apparatus 1030 when RTCP (RTP Control Protocol) is adopted. That is, if it is desired to further reduce the current loss rate, the corresponding port is reassigned to a queue with a lower drop probability.
  • RTCP RTP Control Protocol
  • the error correction coding scheme applied to a specific port may be associated with the drop probability of the queue to which this port is assigned. That is, an error correction method that can correct the packet loss determined from the drop probability of the queue is applied. By doing so, a route without packet loss can be provided equivalently even on a relay route with packet loss.
  • the classification unit 1001 classifies the bucket by the UDP port number.
  • the T0S field of the IPv4 Internet Protocol Version 4
  • the traffic class of the IPv6, and the flow of the IPv6 Classification may be performed using labels (flow lab4, etc.).
  • the present invention also includes a program for causing a computer to execute all or a part of each step of the data transmission method or the data relay method according to the first to fourth embodiments described above.
  • FIG. 11 is a conceptual diagram for explaining a data relay method according to the fifth embodiment of the present invention.
  • DiffServ as a mechanism for realizing priority processing in the relay router (de-night relay device).
  • 1101 and 1102 are transmitting devices, and 1103 is a receiving device.
  • 1 Reference numeral 104 denotes a network called a DS domain, in which only the DS field (upper 6 bits of the TOS field) in the header of the IP packet is viewed, and relay processing is performed at high speed.
  • Reference numerals 1105 and 1106 denote first and second routers, which are called ingress nodes in DiffServ. These first and second routers 1105 and 1106 assign a priority to each packet. Priority assignment is based on incoming buckets,
  • IP address source address, destination address
  • the priority is normally assigned based on a predetermined policy (policy of giving priority to voice, etc.).
  • the transmission devices 1101 and 1102 may associate the data priority with the port number and change the value of the DS field based on the port number. Further, the transmission device 1101 or 1102 may set the DS field value based on the priority.
  • 1107 is the third night, which is called an egress node in DiffServ. The third rule 1107 performs a process of deleting the value of the DS field.
  • Reference numeral 1108 denotes a fourth rule, which receives the IP packets from the transmission devices 1101 and 1102 and relays them based on the priority.
  • the transmitting devices 1101 and 1102 add the maximum value of the propagation delay time determined by the required specifications of the application to the header of the IP packet.
  • the mechanism of the extension header may be used.
  • the field added in the header is called the propagation delay field, and the maximum value of the propagation delay time is assigned to this field. In the case of VOIP, this value should be substituted based on the fact that the delay time for humans to perceive speech and feel uncomfortable is about 100 ms or 200 ms or more.
  • the first router 1105 subtracts the time that this IP packet stayed in the first router 1105 from the value of the propagation delay field, and calculates the result as the propagation delay. Write to field. The same is true for the second le 1106.
  • the fourth router 1108 sends the IP packets from the first and second routers 1105 and 1106 to the third router 1107 while storing them in their respective queues. The one with the smaller field value is delivered first.
  • the relay processing according to the present embodiment includes a flow of recording in a queue and a flow of scheduling. These two flows are processed as independent processes.
  • FIG. 12 shows a recording operation to the queue at each of the routes in FIG.
  • a packet is received in step 1201, and the time at that time is recorded as the arrival time Ta (step 1202). Further, the propagation delay time Td is extracted from the propagation delay field of the received packet (step 1203). Then, the received packet is recorded in the queue together with Ta and Td (step 1204).
  • the queue is selected based on the DS field value. The above processing is repeated.
  • FIG. 13 shows the scheduling operation of the delivery processing in each of the routines in FIG.
  • Steps 1301 to 1305 are a loop process.
  • the processes of steps 1302 to 1304 are performed on the packet at the head of the queue.
  • the arrival time Ta is extracted, and at step 1303, the arrival time Ta is subtracted from the current time Tc to obtain the stay time Ts.
  • the propagation delay time Td is extracted, and in step 1305, a queue that minimizes (Td-Ts) is obtained.
  • the packet is taken out of the queue.
  • step 1308 the packet is transmitted.
  • the propagation delay field is updated. That is, (Td-Ts) obtained earlier is written in the propagation delay field.
  • the above steps 1301 to 1308 are repeated.
  • the propagation delay field values of the IP packets from the first and second routers 1105 and 1106 are both 200 ms, and the first router If the dwell time at 1105 is 180 ms, and the dwell time at 1106 is 50 ms, the IP packet from the 1105 The propagation delay field value becomes 20 ms, and the propagation delay field value of the IP packet from the second rule 1106 becomes 150 ms.
  • the final propagation delay time when the IP bucket from the first router 1105 reaches the receiving device 1103 is larger than that of the IP bucket from the second router 1106, and as a result, The IP packet from the first router 1105 does not satisfy the required specifications of the application, and receiving it is useless.
  • the propagation delay field value of the IP packet from the first router 1105 is smaller than that of the IP packet from the second router 1106, the first As a result, the IP packet from 1105 is given priority for relay processing, and as a result, it is more likely that the required specifications of the application will be satisfied, and problem 3 in the past can be solved.
  • the propagation delay field does not represent an accurate value.
  • all the clocks synchronized with 1105, 1106, 1107, 1108, transmitting devices 1101, 1102, and receiving device 1103 must be kept, and the transmitting devices 1101, 1102
  • the transmission time of the IP bucket may be added for transmission.
  • the propagation delay time rd from the transmission time to the current time of the IP packet is obtained. D is obtained by subtracting the transmission time (added to the IP packet) from the current time.
  • the value of the remaining propagation delay time (remaining propagation delay time), that is, how much propagation delay is allowed, is obtained. Then, IP packets are processed in ascending order of the remaining propagation delay time r. With the above configuration, the order of the relay processing can be changed using the r value that is more accurate than the (Td-Ts) value.
  • FIG. 14 is a conceptual diagram for explaining a data relay method according to the sixth embodiment of the present invention.
  • transmitters 1401 and 1402, receivers 1403 and 1404, network 1405, routers 1406, 1407, 1408, and 1409 are These correspond to those described in the fifth embodiment.
  • network 1405, routers 1406, 1407, 1408, and 1409 are These correspond to those described in the fifth embodiment.
  • a propagation delay time from a certain evening to each receiving device is considered.
  • FIG. 15 shows a propagation delay time measuring operation at a specific router 1410 in FIG.
  • the day 1410 periodically measures i as the propagation delay time between itself and each of the receiving devices 1403 and 1404 (step 1501). This measurement can be performed by using the Internet Control Message Protocol (ICMP) in the IP layer.
  • ICMP Internet Control Message Protocol
  • FIG. 16 shows the scheduling operation of the delivery processing in the same router 1410 in FIG.
  • Steps 1601 to 1604 are a loop process.
  • the processes from step 1602 to step 1603 are performed on the packet at the head of the queue.
  • the transmission time (added to the IP packet) is subtracted from the current time to obtain d as the propagation delay time from the transmission time to the current time.
  • the remaining propagation delay time is determined by subtracting d from the propagation delay field value Td.
  • a queue that minimizes (te r ⁇ ri) is obtained.
  • queues with?] ⁇ 0 (or Td—i ⁇ 0) and queues with r and i ⁇ 0 are excluded.
  • a packet is taken out of the queue in step 1605.
  • the packet is transmitted.
  • the propagation delay field is updated. The above processing from step 1601 to step 1607 is repeated.
  • IP packets are processed in ascending order of the value obtained by subtracting i, the propagation delay time from the remaining propagation delay time r to the corresponding receiver, to obtain the actual required propagation
  • the delay time is more likely to be smaller than the propagation delay time required by the application.
  • FIG. 17 illustrates a configuration example of a transmission device 1700 for implementing the data transmission method according to the seventh embodiment of the present invention.
  • reference numeral 1701 denotes a subdivision unit
  • 1702 denotes an FEC calculation unit
  • 1 to 03 denote packetizing units.
  • the subdivision 1701 Divide the input RTP packet into a certain length.
  • the 0 calculation unit 1702 calculates the FEC data from the divided data.
  • the packetizing section 1-03 reconfigures the RTP bucket.
  • FIG. 18 shows an operation example of the subdivision unit 1701 and the FEC calculation unit 1702 in FIG.
  • reference numeral 1801 denotes a header of an RTP packet input to the re-dividing unit 101: 1802 denotes media data of the RTP packet.
  • the length of the media data 1802 is 120 bytes in this example.
  • Reference numerals 1803, 1804, 1805, 1806, 1807, and 1808 denote media data that has been divided into six by the subdivision unit 1701, and the length of each divided media data is 20 bytes.
  • the FEC calculation section 1702 calculates an FEC data 1809 from the divided media data 1803-1808.
  • This calculation is performed by extracting the i-th byte from the beginning of each divided media data 18 ⁇ 3 to 1808, calculating the exclusive OR (XOR) of the extracted bytes, and calculating the FEC data. It is the i-th byte of 1809 overnight. That is, the length of the FEC data 1809 is 20 bytes.
  • FIG. 19 shows an operation example of the packetizing unit 1703 in FIG.
  • the packetizing unit 17 ⁇ 3 converts these into RTP packets. And output. That is, as shown in FIG. 19, the divided media data 1803 to 1808 and the FEC data 1809 each have an RTP header 1913, 1914, 1915, 1916, 1917. These RTP packets are output after a total of 7 RTP packets have been generated with 1 9 18, 19 1 9 appended.
  • FIG. 20 shows an operation example of the transmitting apparatus 1700 in FIG.
  • an RTP packet including media data is received from the upper layer.
  • the payload portion is extracted from this RTP packet, divided into a fixed number (for example, 6), and the divided media data (hereinafter, referred to as subdivided data).
  • a sub-packet is generated by adding an RTP header to the packet.
  • an FEC packet is generated from these subdivided packets.
  • the subdivision packet is transmitted, and in step 2005, the FEC packet is transmitted.
  • a sub-packet and an FEC packet are generated from the RTP packet received from the upper layer and transmitted.
  • FIG. 21 (a) shows the conventional data transmission by the RFC 2733 method
  • FIG. 21 (b) shows the data transmission according to the seventh embodiment of the present invention.
  • the horizontal axis is the time axis.
  • reference numerals 2101 and 2102 denote a header and media data, respectively, which constitute one RTP packet.
  • 2105 and 2106 also show headers and media data, respectively, and these make up one RTP bucket.
  • Reference numeral 2104 denotes an FEC data generated from the media data 210 2 and 2106 using the conventional RFC 2733 method, and this and the header 2103 constitute one RTP packet.
  • the length of FEC data 2104 is 120 bytes, which is the same as the length of media data 2102 and 2106. According to this conventional method, for example, including media data 2102: even when a TP packet is lost, an RTP packet including the other media data 2106 and an RTP packet including FEC data 2104 can be received. As long as the missing RTP packet can be recovered.
  • FIG. 21 (b) six subdivided data 2112, 2114, 2116, 2118, 2120, 2122 are generated from the media data 2102, and the odd-numbered subdivided data 2112, 2116 , 2120 first FEC data 21 24 is generated, and a second FEC data 2126 is generated from the even-numbered subdivision data 2114, 2118, and 2122.
  • the length of each of the first and second FEC data 2124, 2126 is 20 bytes. 2111, 2113, 2115, 2117, 2119, 2121, 2123, and 2125 are converted to subdivision data 2112, 2114, 2116, 2118, 2120, 2122, and the first and second FEC data 21 24, 2126. Each has an attached RTP header.
  • the first and second FEC data 2124 By using 21 26, two missing RTP packets can be restored.
  • the amount of FEC data used at this time is 40 bytes, which is one third of the RFC 2733 method.
  • the start time of error correction can be advanced and the delay can be reduced.
  • the time when the restoration of the media data can be started is after the reception of the media data 2106 is completed following the media data 2102 and the FEC data 2104.
  • the error correction process can be started as soon as the reception of 26 has been completed.
  • the length of the media data is extremely different (for example, 120 bytes and 20 bytes, respectively). Frequently occur.
  • the FEC data length was 120 bytes for both 120-byte media data and 20-byte media data.
  • the same error correction capability as before can be provided with a small amount of FEC data.
  • the start time of the error correction processing can be advanced, and a flexible response to various media data lengths is possible. That is, the conventional problem 4 can be solved.
  • the division length length of the subdivision data
  • the number of RTP packet subdivisions in subdivision section 1701 may be determined from the ratio of the amount of data used for error correction to the amount of transmission data.
  • the length of the FEC data can be arbitrarily changed by arbitrarily selecting the division length. In the example of FIG. 19, the length of the FEC data 1809 is one time the division length, and in the example of FIG. 21 (b), the total length of the FEC data 2124 and 2126 is twice the division length.
  • the error correction capability can be changed by changing the number of pieces of subdivided data used to generate one FEC data. In the example of FIG. 19, the loss of any one subdivided packet can be repaired, and in the example of FIG. 21 (b), the loss of any two consecutive subdivided packets can be repaired.
  • ROHC RObust Header Compression
  • FIG. 22 shows a configuration example of a receiving device 2200 for implementing the data transmission method according to the eighth embodiment of the present invention.
  • 2201 indicates an error characteristic observation unit
  • 2202 indicates a division length calculation unit.
  • the error characteristic observing unit 2201 observes the error characteristics via the physical layer interface.
  • the error characteristics bit error The occurrence frequency, burst error occurrence frequency, and burst error length shall be observed.
  • the division length calculation unit 222 calculates the division length of the bucket based on the observed error characteristics. For example, the division length calculation unit 222 obtains the packet division length from the burst error length, and transmits the result to the transmitting device.
  • burst error length is L (bytes)
  • setting the division length to L can guarantee that at most two sub-fragments lost due to a burst error will be lost (Fig. 21).
  • burst error 219 if one error occurs per b bytes due to the frequency of bit errors, if the division length is b / 3 bytes, one error will occur per three packets after division. Become. In other words, if one FEC data is created for every two packets after division, only one of the three packets will be lost due to an error (due to the frequency of bit errors). It becomes possible.
  • bit error frequency is ideally a Delaunay function when the graph of the horizontal axis error rate and the vertical axis frequency is drawn, for example.
  • the frequency of bit errors is a Gaussian or Poisson distribution with wide tails. Therefore, the worst value of the number of bytes (b) when one error occurs may be obtained from the worst value of the error rate when the rejection area is 3%.
  • the FEC data length becomes variable, and thus, optimal error correction coding can be realized.
  • the division length is obtained by the reception device 220.
  • the observation result of the error characteristic may be transmitted to the transmission device, and the transmission device may calculate the division length.
  • FIG. 23 shows a configuration example of a receiving apparatus 230 for realizing the data transmission method according to the ninth embodiment of the present invention.
  • reference numeral 2301 denotes an error characteristic observation unit
  • reference numeral 2302 denotes a combination determination unit.
  • the error characteristic observation unit 2301 observes the frequency of occurrence of bit errors, the frequency of occurrence of burst errors, the length of burst errors, and the like.
  • the combination determination unit 2302 is used to calculate FEC data based on, for example, the burst error length. Determine the combination of subdivisions that will be performed. For example, when the length of the burst error is L (bytes), by setting the division length to L as described in the eighth embodiment, the loss of consecutive subdivided packets becomes at most two.
  • the first FEC data 2124 is generated from the odd-numbered subdivided data 2112, 2116, 2120, and the even-numbered subdivided data 2114, 2118, 2122 is generated.
  • the second FEC data 2126 can be generated from
  • one FEC data may be calculated based on the subdivision data for each (n + 1) pieces.
  • the division length is L / n for the burst error length L
  • the number of consecutive packet losses is (n + 1), so the subdivision is performed every (n + 1) Just take it out and generate one FEC data overnight.
  • C According to the example of FIG. 24, the burst error 2401 corresponding to the length of three pieces of subdivided data is shown. Media data can be restored even if it occurs.
  • the combination of the subdivision data is determined based on the observation result of the error characteristic, so that the FEC data length becomes variable, and the optimal error correction coding is realized. Becomes possible.
  • the combination of the subdivided data is determined by the receiving apparatus 2300, but the observation result of the error characteristic is transmitted to the transmitting apparatus, and the transmitting apparatus determines the combination of the subdivided data. You may do so.
  • FIG. 25 illustrates a configuration example of a transmission device 2500 and a reception device 2510 for implementing the data transmission method according to the tenth embodiment of the present invention. This embodiment is suitable when the error characteristics observed by the physical layer interface cannot be used.
  • 2501 denotes a re-division unit
  • 2502 denotes an FEC calculation unit
  • 2503 denotes a bucketing unit
  • 2504 denotes a division length changing unit.
  • the subdivision unit 2501, FEC calculation unit 2502, and packetization unit 2503 correspond to those described in the seventh embodiment.
  • the division length changing unit 2504 The subdivision unit 2501 is controlled so that the packet division length is changed periodically at a constant time interval and within a constant range in order to observe the error characteristics. For example, five packet division lengths of 20, 40, 60, 80, and 100 bytes are used. Note that, for the purpose of observing the error characteristics, the transmitting device 250 may change the packet division length in accordance with an instruction from the receiving device 250.
  • reference numeral 2511 denotes a receiving recording unit
  • reference numeral 2512 denotes a division length-combination determining unit.
  • the reception recording unit 2511 records the length of the received packet and the error characteristics in order to observe the error characteristics.
  • the division length / combination determination unit 2512 determines the bucket division length or the combination of the subdivision packets based on the record.
  • the receiving device 2510 can know the fragment length from the received packet, and: The packet length is determined from the sequence number in the RTP header (such as 913 in Fig. 19). Loss can be detected.
  • the reception recording unit 2511 assigns a unique number i to each division length, and records the packet division length B i, the number of received packets N i, and the number of lost packets M i. Then, F i2 M i / (N i + M i) is obtained for each number i.
  • F i is the packet loss rate
  • a division length B i that reduces this ratio is selected by the division length / combination determination unit 2 512. Then, the transmitting device 250 is notified of the selected division length B i.
  • ADVANTAGE OF THE INVENTION According to this invention, it can contribute to the improvement of the transmission method of the media data which flows through a network, especially the internet, and its relay method.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Quality & Reliability (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

明 細 書
デ一夕伝送方法およびデータ中継方法
技術分野
本発明は、 ネットワークを流れる映像 ·音声データの伝送方法と中継方法に関する ものであって、 特に、 そのデータに暗号化処理または誤り訂正符号化処理を施して伝 送する場合に関するものである。
背景技術
通信速度の増大に伴い、 通信回線を用いたマルチメディアデータ (映像 '音声) の 伝送が、 現実的になってきている。
ネッ トワークにおいて I P ( Internet Protocol ) を用いて、 特に I P v 6 (S. Deering et al., "Internet Protocol Version D lPvo Specincanon", RFC 1883, Internet Engineering Taskforce, Dec. 1995) を用いて映像 ·音声を多地点に配送する仕組みとし て、 マルチキャストが知られている。 また、 暗号化 (encryption) の仕組みとして I P s e Cがめる (S. Kent et al., "Security Architecture for the Internet Protocol", RFC 2401, Internet Engineering Taskforce, Nov. 1998) 。
これらを使い、 ネットワーク上にて、 V O D (Video On Demand) または P P V (Pay Per View) を実現することが可能である。 すなわち、 料金を払った人は、 喑号 化の鍵を送信してもらい、 受け取った鍵で暗号復号化 (decryption) し、 マルチメデ ィアデ一夕を再生する。 ところが、 S T B (Set Top Box) の場合には暗号復号化を ハードウェアで実現するが、 ネットワークの場合には、 汎用のコンピュータが使われ ることが多く、 暗号復号化をハードウェアで行うことは少ない。 映像のビットレート は、 N T S C (National Television Standards Committed 相当の画質の場合で 2〜3 Mb p s、 H D T V (High Definition Television) 相当で 1 0〜 2 0 M b p sほどにな る。 これらデータの全てに暗号化処理が施されていて、 受信装置で暗号復号化処理が 必要となると、 ソフトウェアでは処理しきれない可能性が生じる (課題 1 ) 。
ネットワーク、 特にインターネットは、 その歴史的経緯より集中管理ではなく分散 管理を良しとする傾向がある。 この傾向はマルチメディアデ一夕の配送における帯域 予約においても、 あてはまる。 すなわち、 資源割り当て型の R S V P (R. Braden et al., "Resource ReSerVation Protocol ( RSVP) -- Version 1 Functional Specification", RFC 2205, Internet Engineering Taskforce, Sep. 1997) ではなく、 優先制御型の DiffSen^主 流となっている (S. Blake et al., "An Architecture for Differentiated Services", RFC 2475, Internet Engineering Taskforce, Dec. 1998) 。 この DiffSerUこおいては、 その性質上、 若 干のパケットロスが生じる。 ところが、 パケットロスに対して緩やかにメディアの画 質が変化 (劣化) していくような仕組みが提供できていない (課題 2 ) 。
ここで、 複数の送信元からのパケットが、 ある中継ルー夕に流入する場合であって、 さらに、 その送信パケットの特性として実時間性が要求される場合、 例えばイン夕一 ネット電話に利用される V O I P (Voice Over Internet Protocol) の技術を考える。 こ のような対話型の音声通信の場合、 伝播遅延時間が一定値 (例えば 1 0 0 m s ) を越 えるとユーザの品質に対する満足度が下がるため、 要求仕様としてある伝播遅延時間 が指定されている。 そして、 指定された伝播遅延時間を越える場合、 そのようなパケ ヅトは受信装置では使用できないので廃棄される。 つまり、 このようなパケットを中 継することは無駄である。 しかし、 現在の中継ル一夕では、 このような伝播遅延時間 が指定値を越える場合と越えない場合とのバケツトは、 どちらも同様に中継処理が行 われており、 結果として、 不要な処理を行っていることになる (課題 3 ) 。
また、 マルチメディアデ一夕をィン夕一ネッ卜でリアルタイムに伝送するプロトコ ルとして R T P (Real Time Transport Protocol) が知られている (H. Schulzrinne et al., "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, Internet Engineering Taskforce, Jan. 1996) 。 この R T Pに誤り訂正能力を付加する技術も知られている (J. Rosenberg et al., "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, Internet Engineering Taskforce, Dec. 1999) 。 この R F C 2 7 3 3方式では、 前方 誤り訂正 (F E C : Forward Error Correction ) のための冗長情報 (誤り訂正情報) で ある F E Cデータの長さがメディアデ一夕の長さと同じであり、 F E Cデータ長が長 くかつ固定されている結果、 誤り訂正処理の開始が遅れる、 種々のメディアデ一夕長 に対する柔軟な対応ができないという課題があった (課題 4 ) 。 発明の開示
本発明の目的は、 上記各課題を解決することにある。
上記課題 1を解決するため、 本発明に係る第 1のデータ伝送方法は、 映像もしくは 音声を符号化して得られるデータ列を、 映像もしくは音声の時間、 映像の空間、 映像 もしくは音声の品質、 または映像もしくは音声製作者の付与した情報のいずれか、 ま たはこれらの組み合わせに基づき分割するステップと、 これら分割デー夕列の一部に のみ暗号化処理を施すステップとを備えた方法を採用したものである。
また、 上記課題 2を解決するため、 本発明に係る第 2のデータ伝送方法は、 映像も しくは音声を符号化して得られるデータ列を、 映像もしくは音声の時間、 映像の空間、 映像もしくは音声の品質、 または映像もしくは音声製作者の付与した情報のいずれか、 またはこれらの組み合わせに基づき分割するステップと、 これら分割データ列の一部 にのみ誤り訂正符号化処理を施すステツプとを備えた方法を採用したものである。 上記第 1または第 2のデ一夕伝送方法を採用する場合には、 デ一夕中継装置におい て、 一部にのみ暗号化処理と誤り訂正符号化処理との少なくとも一方が施された分割 データ列を分類するステップと、 この分類結果に基づき前記分割デ一夕列を複数のキ ユーのいずれかに割り当てるステツプとを備えた第 1のデータ中継方法を採用し、 中 継処理の頻度が各キューごとに異なり、 または中継処理時にデ一夕を取り出すキュー の選択方法を可変とし、 または処理しきれないデータの廃棄方法が各キューごとに異 なるものとする。
また、 上記課題 3を解決するため、 本発明に係る第 2のデータ中継方法は、 複数の 送信装置からアプリケーションの要求仕様より決まる伝播遅延時間の最大値が付加さ れたデ一夕を受信するステップと、 前記複数の送信装置からのデータのうち、 各デー 夕に付加された前記伝播遅延時間の最大値の小さいものを優先して中継処理するステ ヅプとを備えた方法.を採用したものである。
また、 上記課題 4を解決するため、 本発明に係る第 3のデ一夕伝送方法は、 送信装 置にてデ一夕をバケツトに分割して伝送するデータ伝送方法において、 前記送信装置 にてパケットを再分割して細分割バケツトを生成する第 1のステップと、 前記送信装 置にて少なくとも 1個の細分割パケットから誤り訂正バケツトを生成し、 伝送する第 2のステップとを備えた方法を採用したものである。
図面の簡単な説明
図 1は、 本発明の第 1の実施形態に係るデータ伝送装置の構成を示すプロック図で ある。
図 2は、 図 1中の分割部の動作例を説明するための図である。
図 3は、 図 1中の送信装置の動作例を示すフローチャート図である。
図 4は、 図 1中の受信装置の動作例を示すフローチャート図である。
図 5は、 本発明の第 2の実施形態に係るデータ伝送装置の構成を示すプロック図で ある。
図 6は、 映像データを扱う場合の図 5中の分割部の動作例を説明するための図であ る。
図 7は、 音声データを扱う場合の図 5中の送信部の動作例を説明するための図であ る。
図 8は、 映像デ一夕と音声データとを扱う場合の図 5中の送信部の動作例を説明す るための図である。
図 9は、 本発明の第 3の実施形態に係るデータ伝送装置の構成を示すプロヅク図で ある。
図 1 0は、 本発明の第 4の実施形態に係るデ一夕中継装置を含むデ一夕伝送システ ムの構成を示すプロヅク図である。
図 1 1は、 本発明の第 5の実施形態に係るデータ中継方法を説明するための概念図 である。
図 1 2は、 図 1 1中の各ル一夕 (デ一夕中継装置) におけるキューへの記録動作を 示すフローチャート図である。
図 1 3は、 図 1 1中の各ルー夕 (データ中継装置) における配送処理のスケジユー リング動作を示すフローチャート図である。
図 1 4は、 本発明の第 6の実施形態に係るデータ中継方法を説明するための概念図 である。
図 1 5は、 図 1 4中の特定のルータ (データ中継装置) における伝播遅延時間計測 動作を示すフローチャート図である。
図 1 6は、 図 1 4中の同ル一夕 (デ一夕中継装置) における配送処理のスケジュ一 リング動作を示すフローチャート図である。
図 1 7は、 本発明の第 7の実施形態に係るデ一夕伝送方法を実現するための送信装 置の構成例を示すブロック図である。
図 1 8は、 図 1 7中の再分割部および F E C計算部の動作例を説明するための図で ある。
図 1 9は、 図 1 7中のパケット化部の動作例を説明するための図である。
図 2 0は、 図 1 7の送信装置の動作例を示すフローチャート図である。
図 2 1 ( a ) は従来技術によるデータ伝送を、 図 2 1 ( b ) は本発明の第 7の実施 形態に係るデ一夕伝送をそれそれ示す図である。
図 2 2は、 本発明の第 8の実施形態に係るデ一夕伝送方法を実現するための受信装 置の構成例を示すプロック図である。
図 2 3は、 本発明の第 9の実施形態に係るデ一夕伝送方法を実現するための受信装 置の構成例を示すプロック図である。
図 2 4は、 本発明の第 9の実施形態に係るデータ伝送方法の効果を説明するための 図である。
図 2 5は、 本発明の第 1 0の実施形態に係るデ一夕伝送方法を実現するための送信 装置および受信装置の構成例を示すブロック図である。
発明を実施するための最良の形態
〈実施形態 1〉
図 1は、 本発明の第 1の実施形態に係るデータ伝送装置の構成を示している。 本実 施形態では、 映像の符号化方式として各種 M P E G (Moving Picture Coding Experts Group) 標準のうち M P E G— 1 (ISO/IEC 13818-2) を、 伝送方式として I P v 6を それそれ用いることとする。 図 1において、 送信装置 1 0 0は、 映像を符号化したビ ットストリームを入力とし、 これを伝送するものであって、 分割部 1 0 1と、 暗号化 部 1 0 2と、 送信部 1 0 3とを備えている。 受信装置 1 1 0は、 送信装置 1 0 0から のパケットを入力とし、 ビットストリームを出力するものであって、 受信部 1 1 3と、 暗号復号化部 1 1 2と、 再構成部 1 1 1とを備えている。
図 2は、 図 1中の分割部 1 0 1の動作例を示している。 分割部 1 0 1は、 映像を構 成するビヅトストリームを、 そのビヅトストリームにより復号化される映像の再生時 刻に基づき分割する。 M P E G— 1によれば、 ェ (Intra) フレーム、 P (Predictive) フレームおよび B (Bidirectionally predictive) フレームの区別がある。 通常、 1個の G O P (Group Of Pictures) 内のフレーム数は 1 5であり、 Iまたは Pフレームの間 隔は 3である。 I, P , Bフレームに対応するビットストリームをそれそれ分割抽出 することにより、 再生時刻に基づく分割が可能である。 この分割抽出は、 ビットスト リーム中のビクチャ層の開始を表す 3 2ビヅトの: P S C (Picture Start Code) をサ一 チし、 その後に続く P C T (Picture Coding Type) を見ることで、 容易に実現可能で ある。 図 2に示した T R (Temporal Reference) は、 当該 G 0 P内での各フレームの 相対時刻を表す値である。
図 1中の送信装置 1 0 0において、 暗号化部 1 0 2は、 一番左のポ一ト (つまり I フレームに相当するビットストリームが伝送されるポート) についてのみ、 暗号化処 理を施す。 I P v 6では、 分割部 1 0 1のそれそれの出力を T C P (Transmission Control Protocol) または U D P (User Datagram Protocol ) の各ポートに割り当て、 さ らに I P層にて、 Iフレームに相当するビヅトストリームが伝送されるポートについ てのみ I P S e C処理を施すように設定する (R. Thayer et al., "IP security Document Roadmap", RFC 2411, Internet Engineering Taskforce, Nov. 1998や、 S. Kent et al, "IP Encapsulating Security Payload ( ESP) ", RFC 2406, Internet Engineering Taskforce, Nov. 1998を参照) 。 つまり、 暗号化部 1 0 2と送信部 1 0 3とは、 T C Pまたは U D Pの 層と、 I P層、 データリンク層および物理層とから構成されることになる。
受信装置 1 1 0において、 受信部 1 1 3は、 送信装置 1 0 0の出力する各ポートご とのパケットを受信する。 また、 Iフレームに相当するビットストリームが伝送され るポートについては、 暗号復号化部 1 12で処理することにより、 もとのパケヅトを 復元する。 受信部 113と暗号復号化部 112とは、 TCPまたは UDPの層と、 I P層、 データリンク層および物理層とから構成される。 再構成部 1 1 1は、 受信部 1 13および喑号復号化部 112からのパケヅトを受け取り、 もとのビットストリーム を復元する。 この復元は、 TI 直の昇順にパケットを並べることで行われる。
以上の構成により、 映像を符号化したビットストリームを分割部 101にて分割し、 暗号化部 102にて、 分割されたバケツ卜の一部だけに暗号化処理を施すことにより、 受信装置 110にて必要な喑号復号化処理は、 一部のパケヅトのみとなる。 この結果、 受信装置 1 10での暗号復号化処理に要する時間を減らすことができ、 従来の課題 1 を解決することができる。 しかも、 暗号を解く鍵を所有しているものだけが映像を見 れるようにする、 という目的が損れることはない。 映像符号化の性質上、 Iフレーム を復元できないと、 以降の映像を復元できないためである。
なお、 本実施形態では、 Iフレームだけに暗号化処理を施すようにしているが、 送 信装置 100が持つ CPU (Central Processing Unit) の性能に応じて暗号化処理を施 すポート数を増減してもよい。 また、 受信装置 110にて、 CPU性能に応じて一部 だけを喑号復号化するようにしてもよい。 この場合、 映像をフルフレームレート (3 0フレーム/ s) で再生できないが、 CPU性能で処理できる範囲での映像を得るこ とができる。
図 3は、 図 1中の送信装置 100の動作例を示している。 図 3によれば、 まず映像 データを読み出し (ステップ 301) 、 P S C (Picture Start Code) を表すバイ ト列 0x 00, 0x00, 0x01, 0x 00を検出する (ステップ 302) 。 これを検 出したら、 PCT (Picture Coding Type) を抽出する (ステップ 303) 。 そして、 この PC Tの値ごとに、 Iの場合はステップ 304、 Pの場合はステップ 305、 B の場合はステップ 306へとそれぞれ分岐する。 ステップ 304, 305, 306で はパケットを生成し、 各ポートへと送信する。 このとき、 各パケットに対し一意なシ 一ケンス番号を付与しておく。 また、 ステップ 304では、 パケットに対し IPs e cの暗号化処理を施す。 そして、 ステップ 307にてデ一夕の終わりかどうかを確認 し、 終わりでない場合はステップ 3 0 1へと戻る。
図 4は、 図 1中の受信装置 1 1 0の動作例を示している。 図 4によれば、 ステップ 4 0 1 , 4 0 2 , 4 0 3にて各 UD Pポートからのパケットを受信する。 ステップ 4 0 1では、 パケヅ トに対し I P s e cの喑号復号化処理を施す。 ステップ 4 0 4では、 パケットからデ一夕列を抽出し、 シーケンス番号の順に連結することで再構成したデ —夕を、 上位層に渡す。 そして、 ステップ 4 0 5にてデ一夕の終わりかどうかを確認 し、 終わりでない場合はステップ 4 0 1, 4 0 2 , 4 0 3の分岐点へと戻る。
〈実施形態 2〉
図 5は、 本発明の第 2の実施形態に係るデータ伝送装置の構成を示している。 図 5 において、 5 0 0は送信装置であって、 映像を符号化したビットストリームを入力と し、 これを伝送するものである。 また、 5 1 0は受信装置であって、 送信装置 5 0 0 からのバケツトを入力とし、 ビットストリームを出力するものである。 分割部 5 0 1、 送信部 5 0 3、 再構成部 5 1 1、 受信部 5 1 3は、 第 1の実施形態で説明したものと 同じものである。 5 0 2は誤り訂正符号化部、 5 1 2は誤り訂正復号化部である。 図 5によれば、 分割部 5 0 1にて映像を符号化したビットストリームを分割し、 誤り訂 正符号化部 5 0 2にて、 分割されたパケヅ卜の一部だけに、 つまり Iフレームに係る パケットだけに誤り訂正符号化処理を施す。 例えば、 誤り訂正符号化方式として R F C 2 7 3 3方式を採用すればよい。 詳細には、 送信部 5 0 3において、 分割されたデ —夕列はそれそれ、 異なる U D Pポート番号または: R T Pの異なるペイロードタイプ で伝送される。 また、 F E Cデ一夕は別の R T Pペイロードとして伝送される。
以上の構成により、 訂正可能な誤り率以下の誤りが生じている場合には、 Iフレー ムの復元が保証される。 すなわち、 誤り訂正符号化処理を施していない場合には、 1 箇所に誤りが生じただけでも復号化に失敗するが、 本実施形態によれば、 Pフレーム および Bフレームが全て欠落しても Iフレームは復元できる。 この場合には、 フレー ムレートが低下する (最低 2フレーム Zs ) が、 一応の映像復号化は可能となり、 緩 やかにメディアの画質を変化させることができる。 つまり、 従来の課題 2を解決する ことができる。 図 6は、 映像データを扱う場合の図 5中の分割部 501の他の動作例を示している。 上記の例では時間に基づく分割をしたが、 空間に基づく分割を行ってもよい。 例えば、 上下の周辺部と左右の周辺部とを、 図 6に示すように、 スライス (Slice) 構造を用い て分割する。 図 6において、 60 1は画面の分割の一例であって、 上下の周辺部はス ライス # 1, 23の 2個で構成される。 また、 左の周辺部はスライス #2, 5, 8, 1 1, 14, 17, 20の 7個で、 右の周辺部はスライス #4, 7, 10, 13, 1 6, 19, 22の 7個でそれそれ構成される。 602はビットストリームであって、 スライスを番号の順番に並べたものである。
この場合、 分割部 50 1は、 中心部として、 スライス #3, 6, 9 , 12, 15, 1 8, 2 1の 7個をそれそれのフレームごとに抽出し、 これを、 誤り訂正符号化部 5 02に出力する。 このようにすることで、 中心部について、 一定値以下の誤りが生じ ても誤りを訂正できる。 すなわち、 主観的に映像の画質劣化に気づきやすい中心部に 画質劣化が生じにくいような構成を取ることができる。 なお、 第 1の実施形態におけ る図 1中の分割部 101において、 図 6に基づく分割を行ってもよい。
また、 分割部 501で画質に基づく分割を行ってもよい。 この場合、 各マクロプロ ック内にて D C T (Discrete Cosine Transform) 係数の符号化結果の部分を、 低周波成 分と高周波成分とに分割すればよい。 このようにすることで、 低周波成分について、 一定値以下の誤りが生じても誤りを訂正できる。 すなわち、 誤りが生じた場合、 即座 に復号化に失敗するのではなく、 一定値以下の誤りの場合には、 SZNは低いがそれ なりの画像を復号化することができるような、 装置を提供することができる。 なお、 第 1の実施形態における図 1中の分割部 10 1において、 画質に基づく同様の分割を 行ってもよい。
さらに、 分割部 501で映像製作者の付与した情報に基づく分割を行ってもよい。 ここに、 映像製作者の付与した情報とは、 映像が放送される時間帯、 映像のジャンル、 映像の出演者、 映像中のコマーシャル部分、 製作者が設定した内容のいずれか、 また はこれらの組み合わせを意味する。 例えば、 各出演者を表す情報と、 映像を符号化し たビットストリームとを関係付けておく。 各出演者を表す情報は、 GOPごとに記録 するようにすればよい。 そして、 特定の出演者の出てくる G O Pだけを抽出し、 誤り 訂正符号化部 5 0 2を通るポートにこれを割り当て、 それ以外の G O Pを別のポート に割り当てればよい。 このようにすることで、 特定の出演者が出てくる映像だけは、 少々の誤りのある環境でも誤りのない、 きれいな映像として受信できる。 特定の出演 者の選択は、 受信者のプロファイルに基づき行う、 または受信装置 5 1 0からの要求 で行うようにすればよい。 なお、 第 1の実施形態における図 1中の分割部 1 0 1にお いて、 映像製作者の付与した情報に基づく同様の分割を行ってもよい。
上記第 1および第 2の実施形態では映像を用いて説明したが、 本発明を音声に適用 してもよい。 例えば、 AD P C M (Adaptive Differential Pulse Code Modulation) 符号 化などの、 初期値と差分との関係は、 上記の映像での Iフレームと P , Bフレームと の関係と同様である。 そこで、 初期値に相当する部分を分割抽出し、 暗号化部 1 0 2 または誤り訂正符号化部 5 0 2を通るポートにこれを割り当てるようにすればよい。 図 7は、 音声データを扱う場合の図 5中の送信部 5 0 3の動作例を示している。 図 7によれば、 高い優先度を持つ 2つ以上の音声デ一夕パケット 7 0 1, 7 0 2から: F E Cデ一夕 (誤り訂正情報) が生成され、 当該 F E Cデータと低い優先度を持つ音声 データとをまとめた他の音声データバケツト 7 0 3が生成され、 これらのバケツトが 伝送される。
図 8は、 映像データと音声データとを扱う場合の図 5中の送信部 5 0 3の動作例を 示している。 図 8によれば、 第 1のデ一夕列が低い優先度を持つ映像デ一夕を、 第 2 のデ一夕列が高い優先度を持つ音声データをそれそれ含んでいる。 そして、 2つ以上 の音声デ一夕バケツト 8 0 1から F E Cデ一夕 (誤り訂正情報) が生成され、 当該 F E Cデ一夕と映像データとをまとめた映像データパケット 8 0 2が生成され、 これら のパケットが伝送される。 つまり、 第 1および第 2のデータ列について、 それそれ図 5に示す構成を用意し、 伝送する場合に、 音声の F E Cデータと、 映像の分割された データ列とをまとめて 1個のパケットを生成し、 これを伝送するのである。
〈実施形態 3〉
図 9は、 本発明の第 3の実施形態に係るデータ伝送装置の構成を示している。 本実 施形態は、 上記第 1の実施形態 (その変形例を含む) と上記第 2の実施形態 (その変 形例を含む) とを合体したものである。 図 9において、 9 0 0は送信装置であって、 映像を符号化したビットストリームを入力とし、 これを伝送する。 また、 9 1 0は受 信装置であって、 送信装置 9 0 0からのパケットを入力とし、 ビットストリームを出 力する。 分割部 9 0 1、 暗号化部 9 0 3、 送信部 9 0 4、 再構成部 9 1 1、 暗号復号 化部 9 1 3、 受信部 9 1 4は第 1の実施形態にて説明したものに相当する。 また、 誤 り訂正符号化部 9 0 2、 誤り訂正復号化部 9 1 2は第 2の実施形態にて説明したもの に相当する。
以上の構成により、 映像を符号化したビットストリームを分割部 9 0 1にて分割し、 誤り訂正符号化部 9 0 2にて、 分割されたパケットの一部だけに誤り訂正符号化処理 を施す。 さらに、 暗号化部 9 0 3にて、 分割されたパケットの一部だけに暗号化処理 を施すことで、 従来の課題 1および 2を同時に解決できる。
なお、 本実施形態では、 一例として Iフレームについてのみ暗号化処理と誤り訂正 符号化処理とを施したが、 別の組み合わせにしてもよい。 例えば、 Iおよび Pフレー ムに誤り訂正符号化処理を施し、 Iフレームにのみ暗号化処理を施してもよい。
〈実施形態 4 >
図 1 0は、 本発明の第 4の実施形態に係るデータ中継装置 1 0 0 0を含むデータ伝 送システムの構成を示している。 上記第 1〜第 3の実施形態によれば、 データ列の一 部に対して暗号化処理および Zまたは誤り訂正符号化処理を施すのであるが、 処理を 施したデ一夕と処理を施していないデータとを区別することなく同様に中継処理した のでは、 効果的な結果を得ることができない。 すなわち、 暗号化処理を施した重要な データや誤り訂正符号化処理を施したデータは、 それ以外のデ一夕に比べて、 より確 実に配送されることを期待されている。 例えば、 誤り訂正符号化処理を施したデータ の場合には、 誤り訂正符号化が保証する最大許容ロス率まではパケットロスがあって もよいので、 その点を考慮した中継処理が要求される。 本実施形態は、 この要求を満 たすものである。
図 1 0において、 1 0 1 0 , 1 0 2 0は、 各々第 1〜第 3の実施形態 (その変形例 を含む) にて説明した送信装置である。 また、 1030は、 第 1〜第 3の実施形態 (その変形例を含む) にて説明した受信装置である。 ここでは、 1, P, Bフレーム に相当する各ビットストリームの断片を、 それそれ UDPのポート 10001, 10 002, 10003に割り当てるものとする。
データ中継装置 1000は、 分類部 1001と、 Iフレーム用のキュー 1002と、 Pフレーム用のキュー 1003と、 Bフレーム用のキュー 1004と、 出力部 100 5とを備えている。 分類部 1001は、 送信装置 1010, 1020からのパケヅト を受信し、 UDPのポート番号に基づきパケットを分類し、 その結果をキュー 100 2, 1003, 1004に揷入する。 すなわち、 UDPポート番号 10001, 10 002, 10003のパケットを、 それそれキュー 1002, 1003, 1004に 挿入する。 出力部 1005は、 各キューごとの処理頻度またはキューの選択方法が異 なり、 または各キューが溢れそうなときのパケヅト廃棄方法が各キューごとに異なる ものである。 例えば、 Iフレーム用のキュー 1002にデータがあるときには、 他の キュー 1003, 1004にデ一夕がある場合でも、 Iフレーム用のキュー 1002 を優先して中継処理する (Priority Queueing) 。 これは、 キューの選択方法を変える ものである。 また、 各キューのデータ量に基づきデ一夕中継装置 1000の持つ処理 能力を公平に分配したり (Fair Queueing)、 さらに公平に分配するが、 Iフレーム用 のキュ一 1002を少しだけ優先して処理したり (Weighted Fair Queueing) するこ とも可能である。 これにより、 キューごとの処理頻度を変えることができる。 また、 廃棄確率を各キューに滞留しているデ一夕の平均量 (平均キュー長) の関数としても よい。
Iフレーム用のキュー 1002の廃棄確率を他のキュー 1003, 1004の廃棄 確率より小さくすると、 Iフレーム用のキュ一 1002にはデ一夕が滞留しやすく、 結果として、 このポートに相当する Iフレームのビヅトストリーム断片の遅延が大き くなりやすくなる。 これを回避するために、 エフレーム用のキュー 1002の廃棄確 率を他のキュー 1003, 1004の廃棄確率より大きくするようにしてもよい。 た だし、 この場合には Iフレームでパケット廃棄が生じやすいという問題がある。 これ を解決するには、 より強力な誤り訂正符号化方式を適用するようにすればよい。
以上の構成により、 送信装置 1010, 1020の各々の中で分割された各フレー ムに対応するデ一夕が分類部 1001で再度分類され、 この分類の結果がキュー 10 02, 1003, 1004に挿入され、 出力部 1005にて、 キューごとに異なる中 継処理が行われる。 このようにして、 各デ一夕をそれそれ区別して中継処理すること ができる。
なお、 出力部 1 005でのパケット廃棄方法と、 例えば R T CP (RTP Control Protocol) を採用した場合の受信装置 1030で検出したバケツトロス率とを対応付 けるようにしてもよい。 すなわち、 現在のロス率をさらに下げたい場合には、 該当ポ 一トを廃棄確率のより低いキューに割り当て直すようにする。
また、 特定のポートに適用された誤り訂正符号化方式と、 このポートが割り当てら れるキューの廃棄確率とを対応付けるようにしてもよい。 すなわち、 キューの廃棄確 率から決まるパケットロスを訂正可能な誤り訂正方式を適用するのである。 このよう にすることで、 パケットロスのある中継経路においても、 等価的にパケットロスのな い経路を提供することができる。
また、 以上の説明にて分類部 1001は UDPポート番号でバケツトを分類したが、 これ以外に、 IPv4 (Internet Protocol Version 4) の T 0 Sフィールド、 IPv6 のトラフィッククラス (traffic class)、 IPv6のフローラベル (flow lab4 などを 用いて分類するようにしてもよい。
以上説明してきた第 1〜第 4の実施形態に係るデータ伝送方法またはデータ中継方 法の各ステツプの全部または一部をコンピュータにより実行させるためのプログラム も、 本発明に含まれる。
〈実施形態 5 >
図 11は、 本発明の第 5の実施形態に係るデータ中継方法を説明するための概念図 である。 ここでは、 図 11を参照して、 中継ルー夕 (デ一夕中継装置) での優先度処 理を実現する仕組みとして DiffServを用いて説明を行う。
図 11において、 1101, 1102は送信装置、 1103は受信装置である。 1 104は: DSドメインと呼ばれるネットワークであって、 この内部では、 IPパケヅ トのヘッダ部にある D Sフィールド (T OSフィールドの上位 6ビット) だけを見て、 高速に中継処理が行われる。 1105, 1106は第 1および第 2のルー夕であって、 DiffServではこれをイングレスノードと呼ぶ。 これら第 1および第 2のルー夕 110 5, 1106は、 各パケットに優先度を割り当てる。 優先度の割り当ては、 流入して くるバケツトを、
IPアドレス (ソースアドレス, デスティネーションアドレス)
プロトコル番号
TCP/UDPのポート番号
で分類し、 それそれの分類ごと、 DSフィールドに異なる値を代入することで行われ る。 なお、 優先度割り当ては、 通常予め決定したポリシーに基づき行われる (音声を 最優先にする、 などのポリシー) 。 送信装置 1101, 1102にて、 デ一夕の優先 度とポート番号とを対応させ、 ポ一ト番号に基づき D Sフィ一ルドの値を変更すれば よい。 また、 送信装置 1101, 1102にて、 DSフィールド値を優先度に基づき 設定してもよい。 1107は第 3のル一夕であって、 DiffServではこれをィーグレス ノードと呼ぶ。 第 3のルー夕 1107は、 D Sフィールドの値を削除する処理を行う。 1108は第 4のル一夕であって、 送信装置 1101, 1102からの I Pパケヅト を受信し、 これを優先度に基づき中継処理する。
さて、 送信装置 1101, 1102は、 IPパケットのヘッダに、 アプリケーショ ンの要求仕様より決まる伝播遅延時間の最大値を付加する。 付加する方法は、 例えば IPv6であれば、 拡張ヘッダの仕組みを用いればよい。 ヘッダ中に付加されたフィ —ルドを伝播遅延フィールドと呼び、 このフィ一ルドに伝播遅延時間の最大値を代入 する。 VOIPであれば、 人間が音声を知覚して違和感を覚える遅延時間が約 100 msまたは 200ms以上であるという事実より、 この値を代入すればよい。 第 1の ルー夕 1105は、 IPパケヅトを中継する時に、 前記伝播遅延フィールドの値から、 この IPパケヅトが当該第 1のル一夕 1105に滞在していた時間を引き算し、 その 結果を伝播遅延フィールドに書き込む。 第 2のル一夕 1106についても同様である。 第 4のルー夕 1108は、 第 1および第 2のルー夕 1105, 1106からの I Pパ ケットをそれそれのキューに溜めながら第 3のル一夕 1107に酉己送するのであるが、 伝播遅延フィールド値の小さいものを先に配送処理する。
本実施形態に係る中継処理は、 キュ一への記録のフローとスケジューリングのフロ —とからなる。 これら 2つのフローは、 独立のプロセスとして処理される。
図 12は、 図 11中の各ルー夕におけるキューへの記録動作を示している。 まずス テツプ 1201にてパケヅトを受信し、 その時の時刻を到着時刻 T aとして記録する (ステップ 1202) 。 また、 受信したパケットの伝播遅延フィールドから伝播遅延 時間 Tdを抽出する (ステップ 1203) 。 そして、 Ta, Tdとともに、 受信した パケットをキューに記録する (ステップ 1204) 。 ここで、 DSフィールド値に基 づき、 キューを選択する。 以上の処理を繰り返す。
図 13は、 図 11中の各ル一夕における配送処理のスケジューリング動作を示して いる。 ステップ 1301からステップ 1305までは、 ループ処理であって、 それそ れのキューについて、 キュー先頭のパケットに対し、 ステップ 1302からステップ 1304までの処理を行う。 ステップ 1302にて到着時刻 T aを取り出し、 ステヅ プ 1303にて現在の時刻 Tcから到着時刻 Taを差し引くことで滞在時間 Tsを求 める。 また、 ステップ 1304にて伝播遅延時間 Tdを取り出して、 ステップ 130 5にて、 (Td— Ts) が最小となるキューを求める。 このようにして求めたキュ一 の先頭パケヅトを送出するため、 ステップ 1306にてキューからパケヅトを取り出 す。 そして、 ステップ 1308にてパケットを送信するのであるが、 その前にステツ プ 1307にて、 伝播遅延フィールドを更新する。 すなわち、 先ほど求めた (Td— Ts) を伝播遅延フィールドに書き込む。 以上のステップ 1301からステップ 13 08までの処理を繰り返す。
以上の構成により、 本実施形態によれば、 例えば、 第 1および第 2のルー夕 110 5, 1106からの I Pパケットの伝播遅延フィ一ルド値がいずれも 200msであ り、 第 1のルー夕 1105での滞在時間が 180msであり、 第 2のル一夕 1106 での滞在時間が 50 m sであつた場合、 第 1のル一夕 1105からの I Pパケットの 伝播遅延フィールド値が 20 msとなり、 第 2のル一夕 1106からの I Pパケヅト の伝播遅延フィールド値が 150 m sとなる。 従来の処理では、 第 1のルー夕 110 5からの IPバケツトが受信装置 1103に到達した時の最終伝播遅延時間は、 第 2 のルー夕 1106からの I Pバケツトのそれに比べて大きくなり、 結果として第 1の ルー夕 1105からの IPパケヅトはアプリケーションの要求仕様を満たさず、 受信 しても無駄となる。 しかし、 本実施形態によれば、 第 1のルー夕 1105からの I P パケッ卜の伝播遅延フィ一ルド値が第 2のル一夕 1106からの I Pパケヅトのそれ より小さいため、 第 1のル一夕 1105からの I Pパケットが優先して中継処理され る結果、 アプリケーションの要求仕様を満たす可能性が高くなり、 従来の課題 3を解 決することができる。
なお、 本実施形態ではル一夕間での中継処理時間が考慮されていないので、 伝播遅 延フィールドは正確な値を表していない。 この問題を解決するためには、 全てのル一 夕 1105, 1106, 1107, 1108、 送信装置 1101, 1102、 受信装 置 1103に同期した時計をそれそれ持たせ、 送信装置 1101, 1102が、 先ほ どの伝播遅延フィールドの他に、 I Pバケツトの送信時刻を付加して伝送すればよい。 そして、 各ル一夕 1105 , 1106, 1107, 1108では、 IPパケットの、 送信時刻から現時点までの伝播遅延時間 rdを求める。 て dは、 現在の時刻から送信 時刻 (IPパケットに付加されている) を差し引くことで求まる。 さらに、 伝播遅延 フィールド値 Tdからて dを差し引くことで、 残りの伝播遅延時間 (残伝播遅延時 間) てで、 すなわち、 あと、 どれだけの伝播遅延が許されるかの値が求まる。 そして、 この残伝播遅延時間て rの小さい順に、 IPパケットを処理する。 以上の構成により、 上記 (Td— Ts)値より正確なて r値を用いて、 中継処理の順序を変更することが できる。
〈実施形態 6 >
図 14は、 本発明の第 6の実施形態に係るデータ中継方法を説明するための概念図 である。 図 14において、 送信装置 1401, 1402、 受信装置 1403, 140 4、 ネットワーク 1405、 ルー夕 1406, 1407, 1408, 1409は、 そ れそれ第 5の実施形態で説明したものに相当する。 ただし、 本実施形態では、 あるル —夕から各受信装置までの伝播遅延時間を考慮する。
図 15は、 図 14中の特定のルー夕 1410における伝播遅延時間計測動作を示し ている。 ル一夕 1410は、 定期的に、 自分と各受信装置 1403, 1404との間 での伝播遅延時間て iを計測する (ステップ 1501) 。 この計測は、 I P層での I CMP ( Internet Control Message Protocol ) を用いることで可能となる。
図 16は、 図 14中の同ルー夕 1410における配送処理のスケジュ一リング動作 を示している。 ステップ 160 1からステップ 1604までは、 ループ処理であって、 それぞれのキューについて、 キュー先頭のパケットに対し、 ステップ 1602からス テツプ 1 603までの処理を行う。 ステップ 1 602にて現在の時刻から送信時刻 (I Pパケットに付カ卩されている) を差し引くことで、 送信時刻から現時点までの伝 播遅延時間て dを求める。 また、 ステップ 1603にて伝播遅延フィールド値 Tdか らて dを差し引くことで、 残伝播遅延時間て rを求める。 そして、 ステップ 1604 にて、 (て r— ri) が最小となるキューを求める。 ただし、 無 な中継処理を省く ため、 て]? <0 (または Td—て i<0) のキュー、 およびて r一て i<0のキュー は除く。 このようにして求めたキューの先頭パケットを送出するため、 ステップ 16 05にてキューからパケヅトを取り出す。 そして、 ステップ 1607にてパケヅトを 送信するのであるが、 その前にステップ 1606にて、 伝播遅延フィールドを更新す る。 以上のステップ 160 1からステップ 1607までの処理を繰り返す。
以上の構成により、 各 IPパケットごとに、 残伝播遅延時間て rから対応する受信 装置までの伝播遅延時間て iを差し引いた値の小さい順に I Pパケットを処理するこ とで、 実際に要した伝播遅延時間が、 アプリケーションの要求する伝播遅延時間より 小さくなる可能性がさらに高まる。
〈実施形態 7 >
図 17は、 本発明の第 7の実施形態に係るデータ伝送方法を実現するための送信装 置 1700の構成例を示している。 図 17において、 1701は再分割部を、 170 2は FE C計算部を、 1 Ί 03はパケヅト化部をそれそれ示す。 再分割部 170 1は、 入力された RTPパケットを一定の長さに分割する。 0計算部1702は、 分割 されたデ一夕から: FECデ一夕を算出する。 パケヅト化部 1 Ί 03は、 RTPバケツ トを再構成する。
図 18は、 図 1 7中の再分割部 1701および F E C計算部 1702の動作例を示 している。 図 18において、 180 1は再分割部 1 Ί 0 1に入力された: R TPパケヅ 卜のヘッダを示し、 1802は同 R TPパケットのメディアデータを示す。 メディア データ 1802の長さは、 この例では 120バイトである。 1803, 1804, 1 805, 1806 , 1807, 1808は再分割部 170 1により 6分割されたメデ ィアデ一夕を示し、 分割された各メディアデータの長さは 20バイトである。 FEC 計算部 1702は、 これらの分割されたメディアデータ 1803〜1808から FE Cデ一夕 1809を算出する。 この算出は、 分割された各メディアデータ 18◦ 3〜 1808の先頭から i番目のバイトをそれそれ取り出し、 取り出されたバイトの排他 的論理和 (XOR) を計算し、 この計算結果を FE Cデ一夕 1809の第 i番目のバ ィトとするというものである。 つまり、 F ECデータ 1809の長さは 20バイトで ある。
図 19は、 図 17中のパケット化部 1703の動作例を示している。 上記分割され たメディアデータ 1803〜1808と F ECデ一夕 1809とに加えて、 分割前の ヘッダ 180 1がパケヅト化部 1703に入力されると、 パケット化部 17◦ 3は、 これらを RTPパケット化して出力する。 すなわち、 図 1 9に示すように、 分割され たメディアデ一夕 1803〜 1808および FE Cデ一夕 1809に、 それそれ RT Pヘッダ 19 13, 19 14, 1 9 15, 19 16, 19 17, 1 9 18, 19 1 9 が付けられて、 合計 7個の RTPパケットが生成された後、 これらの RTPパケット が出力される。
図 20は、 図 17の送信装置 1700の動作例を示している。 まず、 ステップ 20 0 1にて上位層よりメディアデ一夕を含む R TPパケヅトを受け取る。 ステップ 20 02では、 この R TPパケットからペイロード部分を抽出し、 これを一定の個数 (6 個など) に分割し、 分割したメディアデ一夕 (以下、 細分割データと呼ぶ) それそれ に R TPヘッダを付加することで、 細分割パケットを生成する。 ステップ 2003で は、 これら細分割パケットから FECパケットを生成する。 ステップ 2004では細 分割パケヅトを送信し、 ステップ 2005では FECパケヅトを送信する。 以上のよ うにして、 上位層より受け取った R TPパケットから、 細分割パケットと FE Cパケ ットとを生成し、 それそれを送信する。
図 21 (a) は従来の RFC 2733方式によるデ一夕伝送を、 図 21 (b) は本 発明の第 7の実施形態に係るデ一夕伝送をそれそれ示している。 両図において、 横軸 は時間軸である。
図 21 (a) において、 2101, 2102はそれそれヘッダとメディアデータと を示し、 これらにより 1個の RTPパケットが構成されている。 2105, 2106 もそれそれへヅダとメディアデ一夕を示し、 これらにより 1個の RTPバケツトが構 成されている。 2104は従来の RFC 2733方式を用いてメディアデータ 210 2, 2106より生成された F ECデ一夕であり、 これとヘッダ 2103とから、 1 個の R TPパケットが構成されている。 FE Cデータ 2104の長さは、 メディアデ —夕 2102, 2106の各々の長さと同じく 120バイ トである。 この従来方式に よれば、 例えばメディアデ一夕 2102を含む: TPパケヅトが欠落した場合でも、 他方のメディアデータ 2106を含む R TPパケヅトと、 F ECデータ 2104を含 む RTPパケッ卜とを受信できる限り、 欠落した RTPパケットを復元できることに なる。
• ここで、 物理層に無線回線を用いることを考える。 無線回線の特性上、 ビットエラ 一やバーストエラ一が発生し、 これが原因となってパケヅトロスが生じることになる。 図 21 (a) に示すような、 20バイ トに相当するバーストエラ一 2199が生じた ものとする。 この場合、 RF C 2733方式によっても誤り訂正が可能であるが、 そ れに要する FE Cデ一夕量は 120バイ トである。
一方、 図 21 (b) によれば、 メディアデ一夕 2102から 6個の細分割データ 2 112, 2114, 2116, 2118, 2120, 2122が生成され、 さらに、 奇数番目の細分割データ 2112, 2116, 2120から第 1の FECデータ 21 24が生成され、 偶数番目の細分割データ 2114, 2118, 2122から第 2の FECデ一夕 2126が生成される。 第 1および第 2の FECデータ 2124, 21 26の各々の長さは、 20バイ トである。 2111, 2113, 2115, 2117, 2119, 2121, 2123, 2125は、 細分割デ一夕 2112, 2114, 2 116, 2118, 2120, 2122ならびに第 1および第 2の F E Cデ一夕 21 24, 2126にそれそれ付けられた RTPヘッダである。 このとき、 20バイ トに 相当するバーストエラー 2199に起因して細分割デ一夕 2120, 2122を含む 2個の RTPパケットが欠落しても、 第 1および第 2の FE Cデ一夕 2124, 21 26を用いることにより、 欠落した 2個の RTPパケヅトを復元できる。 この際に用 いる F ECデ一夕量は 40バイトであって、 上記 RFC 2733方式の場合の 3分の 1である。
また、 図 21 (a) と図 21 (b) とを対比すると、 本実施形態によれば、 誤り訂 正の開始時期を早めることができ、 その遅延を小さくすることができることが判る。 図 21 (a) の RFC 2733方式によれば、 メディアデータの復元開始が可能な時 期は、 メディアデータ 2102および FECデ一夕 2104に続いてメディアデータ 2106の受信を完了した後である。 一方、 本実施形態では、 図 21 (b) のとおり、 メディアデ一夕 2102に対応する細分割デ一夕 2112, 2114, 2116, 2
118, 2120, 2122に続いて第 1および第 2の F ECデ一夕 2124, 21
26の受信を完了した時点で、 早くも誤り訂正処理を開始することができる。
一方、 映像符号化方式でのイントラピクチャ (Intra Picture) とインターピクチャ (Inter Picture) との境界では、 メディアデ一夕の長さが極端に異なる場合 (例えば、 それぞれ 120バイ ト、 20バイ ト) が頻繁に生じる。 従来の RFC 2733方式に よれば、 120バイ ト長のメディアデータについても、 また 20バイト長のメディア デ一夕についても FECデータ長は 120バイ トであった。 これに対して、 本実施形 態によれば、 分割前のメディアデータのうち、 より小さいもの、 または最小のものを パケヅトの分割長として選ぶことで、 種々のメディアデータ長に対する柔軟な対応が 可能である。 以上より、 本実施形態によれば、 従来と同じ誤り訂正能力を少ない: FECデ一夕量 で提供できる。 また、 誤り訂正処理の開始時期を早めることができ、 種々のメディア デ一夕長に対する柔軟な対応が可能である。 つまり、 従来の課題 4を解決することが できる。
分割長 (細分割デ一夕の長さ) 、 FECデ一夕の個数、 FECデータ生成に用いる 細分割データの組み合わせは、 種々選択することができる。再分割部 1701におけ る R TPパケットの再分割数は、 誤り訂正に用いるデータ量の、 伝送データ量に対す る比率から求めればよい。 また、 分割長を任意に選ぶことで、 F ECデータの長さを 任意に変更することができる。 図 19の例では FE Cデータ 1809の長さが分割長 の 1倍であり、 図 21 (b) の例では FECデータ 2124, 2126の合計の長さ が分割長の 2倍である。 さらに、 1個の; FE Cデータの生成に用いる細分割データの 個数を変更することにより、 誤り訂正能力を変更することが可能である。 図 19の例 では任意の 1個の細分割パケットのロスを、 図 21 (b) の例では任意の連続する 2 個の細分割パケットのロスをそれそれ修復できる。
なお、 ヘッダ増加に伴うオーバ一ヘッ ドを考慮する必要があるが、 ROHC (RObust Header Compression) 方式を用いれば、 R TPヘッダだけでなく、 下の層の UDP/I Pヘッダをも、 圧縮により短くすることができる (C. Bormann et al, "RObust Header Compression ( ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, Internet Engineering Taskforce, Jul.200]) 。 ほとんどの場合、 へヅダを 1バイト程度まで圧縮できるため、 本実施形態では、 分割によるオーバーへ ッドはたかだか 5バイトであり、 もとのデータ量の約 4% (=5/120) である。 これは、 本実施形態による効果に比べて十分無視し得る量である。
〈実施形態 8 >
図 22は、 本発明の第 8の実施形態に係るデータ伝送方法を実現するための受信装 置 2200の構成例を示している。 図 22において、 2201は誤り特性観測部を、 2202は分割長算出部をそれそれ示す。 誤り特性観測部 2201は、 物理層イン夕 フエ一スを介して誤り特性を観測する。 ここでは、 誤り特性として、 ビットエラーの 発生頻度、 バーストエラーの発生頻度、 バ一ストエラ一長などが観測されるものとす る。 分割長算出部 2 2 0 2は、 観測された誤り特性に基づいてバケツトの分割長を算 出する。 例えば、 分割長算出部 2 2 0 2は、 バーストエラー長からパケット分割長を 求め、 その結果を送信装置へ伝送する。 すなわち、 バ一ストエラー長が L (バイ ト) の場合、 分割長を Lと設定すれば、 バーストエラーによりロスする細分割パケットは、 たかだか 2個であることを保証することができる (図 2 1 ( b ) のバーストエラー 2 1 9 9参照) 。 また、 ビットエラーの頻度から、 bバイ トあたりに 1個のエラーが生 じる場合、 分割長を b/ 3バイ トとすれば、 分割後の 3パケヅトあたり 1回のエラ一 が生じることになる。 すなわち、 分割後の 2パケットごとに 1個の F E Cデ一夕を作 成すれば、 3パケットのうちエラーによりロスするのは (ビットエラーの頻度より) たかだか 1個だけであるので、 必ず訂正が可能となる。
なお、 補足すると、 ビットエラーの頻度は、 例えば、 横軸エラ一率、 縦軸頻度のグ ラフを描くと、 理想的にはデル夕関数になる。 しかし、 現実には、 ビットエラーの頻 度は、 裾が広がったガウス分布またはポアソン分布になる。 そこで、 棄却域 3 %の場 合のエラ一率の最悪値から、 1個のエラーが生じる場合のバイ ト数 (b ) の最悪値を 求めるようにしてもよい。
以上により、 本実施形態によれば、 誤り特性の観測結果に基づき分割長を決定する ことにより、 F E Cデータ長が可変となる結果、 最適な誤り訂正符号化の実現が可能 となる。 なお、 本実施形態では、 受信装置 2 2 0 0にて分割長を求めたが、 誤り特性 の観測結果を送信装置へと伝送し、 当該送信装置において分割長を算出するようにし てもよい。
〈実施形態 9 >
図 2 3は、 本発明の第 9の実施形態に係るデータ伝送方法を実現するための受信装 置 2 3 0 0の構成例を示している。 図 2 3において、 2 3 0 1は誤り特性観測部を、 2 3 0 2は組み合わせ決定部をそれそれ示す。 誤り特性観測部 2 3 0 1は、 ビットェ ラーの発生頻度、 バーストエラーの発生頻度、 バーストエラー長などを観測する。 組 み合わせ決定部 2 3 0 2は、 例えばバーストエラ一長より、 F E Cデータの計算に用 いる細分割デ一夕の組み合わせを決定する。 例えばバ一ストエラ一長が L (バイ ト) の場合、 第 8の実施形態で説明したように分割長を Lと設定することで、 連続する細 分割パケットのロスはたかだか 2個になる。 したがって、 図 21 (b) に示したよう に、 奇数番目の細分割デ一夕 2112, 2116, 2120から第 1の FECデ一夕 2124を生成し、 偶数番目の細分割データ 2114, 2118, 2122から第 2 の F ECデ一夕 2126を生成すればよい。
一般に、 nを 1以上の整数とするとき、 (n+ 1)個ごとの細分割デ一夕をもとに 1個の F ECデータを計算するようにしてもよい。 すなわち、 バーストエラ一長 Lに 対し、 分割長を L/nとした場合、 連続するパケットロスの個数は (n+1) となる ので、 (n+1)個ごとに細分割デ一夕を取り出して 1個の FECデ一夕を生成する ようにすればよい。
図 24は、 本実施形態に係るデータ伝送方法の効果 (n=3の場合) を示している c 図 24の例によれば、 3個の細分割データの長さに相当するバーストエラ一 2401 が生じても、 メディアデータの復元が可能である。
以上により、 本実施形態によれば、 誤り特性の観測結果に基づき細分割データの組 み合わせを決定することにより、 FE Cデ一夕長が可変となる結果、 最適な誤り訂正 符号化の実現が可能となる。 なお、 本実施形態では、 受信装置 2300にて細分割デ 一夕の組み合わせを決定したが、 誤り特性の観測結果を送信装置へと伝送し、 当該送 信装置において細分割データの組み合わせを決定するようにしてもよい。
〈実施形態 10〉
図 25は、 本発明の第 10の実施形態に係るデ一夕伝送方法を実現するための送信 装置 2500および受信装置 2510の構成例を示している。 本実施形態は、 物理層 イン夕フェースが観測した誤り特性を利用できない場合に好適なものである。
図 25の送信装置 2500において、 2501は再分割部を、 2502は F EC計 算部を、 2503はバケツト化部を、 2504は分割長変更部をそれそれ示す。 再分 割部 2501、 FE C計算部 2502、 パケット化部 2503は、 それそれ第 7の実 施形態で説明したものに相当する。 分割長変更部 2504は、 受信装置 2510にお ける誤り特性の観測のために、 一定時間間隔ごと定期的に、 かつ一定の範囲でパケッ ト分割長を変更するように、 再分割部 2 5 0 1を制御する。 例えば、 2 0、 4 0、 6 0、 8 0、 1 0 0バイトの 5つのパケット分割長を用いる。 なお、 誤り特性の観測を 目的として、 受信装置 2 5 1 0からの指示により送信装置 2 5 0 0がパケット分割長 を変更するようにしてもよい。
図 2 5の受信装置 2 5 1 0において、 2 5 1 1は受信記録部を、 2 5 1 2は分割長 -組み合わせ決定部をそれそれ示す。 受信記録部 2 5 1 1は、 誤り特性の観測のため に、 受信したパケットの長さと誤り特性とを記録する。 分割長 ·組み合わせ決定部 2 5 1 2は、 当該記録に基づき、 バケツト分割長または細分割パケットの組み合わせを 決定する。
具体的に説明すると、 受信装置 2 5 1 0では、 受信したパケットより分割長を知る ことができ、 : R T Pヘッダ (図 1 9中の 1 9 1 3など) 中のシーケンス番号よりパケ ットのロスを検出できる。 受信記録部 2 5 1 1は、 各分割長ごとに一意の番号 iを割 り当て、 パケットの分割長 B iと、 受信パケット数 N iと、 ロスパケット数 M iとを 記録する。 そして、 各番号 iごとに F i二 M i / (N i +M i ) を求める。 ここに、 F iはパケットロス率であり、 この比率が小さくなるような分割長 B iを分割長 ·組 み合わせ決定部 2 5 1 2で選択する。 そして、 選択した分割長 B iを送信装置 2 5 0 0に通知する。
産業上の利用の可能性
本発明によれば、 ネットワーク、 特にインターネットを流れるメディアデータの伝 送方法およびその中継方法の改善に資することができる。

Claims

請 求 の 範 囲
1 . 映像もしくは音声を符号化して得られるデータ列を、 映像もしくは音声の時 間、 映像の空間、 映像もしくは音声の品質、 または映像もしくは音声製作者の付与し た情報のいずれか、 またはこれらの組み合わせに基づき分割するステップと、 これら分割データ列の一部にのみ暗号化処理を施すステップとを備えたことを特徴 とするデータ伝送方法。
2 . 映像もしくは音声を符号化して得られるデータ列を、 映像もしくは音声の時 間、 映像の空間、 映像もしくは音声の品質、 または映像もしくは音声製作者の付与し た情報のいずれか、 またはこれらの組み合わせに基づき分割するステップと、 これら分割デ一夕列の一部にのみ誤り訂正符号化処理を施すステップとを備えたこ とを特徴とするデータ伝送方法。
3 . 請求項 2記載のデータ伝送方法において、
前記分割データ列の一部にのみ暗号化処理を施すステップをさらに備えたことを特 徴とするデータ伝送方法。
4 . 請求項 1〜 3のいずれか 1項に記載のデータ伝送方法において、
映像または音声を構成する要素同士の予測関係を表す識別子に基づき前記データ列 を分割することにより、 前記時間に基づく分割を実現することを特徴とするデータ伝 送方法。
5 . 請求項 1〜 3のいずれか 1項に記載のデータ伝送方法において、
映像を中心部と周辺部とに分割することにより、 前記空間に基づく分割を実現する ことを特徴とするデ一夕伝送方法。
6 . 請求項 1〜 3のいずれか 1項に記載のデ一夕伝送方法において、
映像または音声を低周波成分と高周波成分とに分割することにより、 前記映像また は音声の品質に基づく分割を実現することを特徴とするデータ伝送方法。
7 . 請求項 1〜 3のいずれか 1項に記載のデータ伝送方法において、
映像もしくは音声が放送される時間帯、 映像もしくは音声のジャンル、 映像もしく は音声の出演者、 映像もしくは音声中のコマーシャル部分、 製作者が設定した内容の いずれか、 またはこれらの組み合わせに基づき前記データ列を分割することにより、 前記映像または音声製作者の付与した情報に基づく分割を実現することを特徴とする デ一夕伝送方法。
8 . 請求項 2または 3に記載のデータ伝送方法において、
一部に施した誤り訂正符号化処理により得られる誤り訂正情報と、 前記分割データ 列とから、 1個のパケットを生成して伝送することを特徴とするデータ伝送方法。
9 . 請求項 2または 3に記載のデ一夕伝送方法において、
入力として 2つ以上のデータ列を取り、 あるデータ列から得られた誤り訂正情報と、 それ以外のデ一夕列とから、 1個のパケットを生成して伝送することを特徴とするデ 一夕伝送方法。
1 0 . 請求項 1〜3のいずれか 1項に記載のデータ伝送方法を実現するデータ伝
1 1 . 請求項 1〜 3のいずれか 1項に記載のデータ伝送方法の各ステップの全部 または一部をコンピュータにより実行させるためのプログラム。
1 2 . 映像もしくは音声を符号化して得られるデ一夕列が、 映像もしくは音声の 時間、 映像の空間、 映像もしくは音声の品質、 または映像もしくは音声製作者の付与 した情報のいずれか、 またはこれらの組み合わせに基づき分割され、 これら分割デー 夕列の一部にのみ暗号化処理と誤り訂正符号化処理との少なくとも一方が施された分 割デ一夕列を分類するステップと、
前記分類結果に基づき、 前記分割データ列を複数のキューのいずれかに割り当てる ステップとを備え、
中継処理の頻度が各キューごとに異なり、 または中継処理時にデータを取り出すキ ユーの選択方法を可変とし、 または処理しきれないデ一夕の廃棄方法が各キューごと に異なることを特徴とするデータ中継方法。
1 3 . 請求項 1 2記載のデータ中継方法であって、
分割されたデータ列のロス率と各キューの廃棄方法とに基づき、 前記分割デ一夕列 をキューに割り当てることを特徴とするデータ中継方法。
1 4 . 請求項 1 2記載のデータ中継方法であって、
誤り訂正符号化方式が持つ最大許容ロス率と各キューの廃棄方法とに基づき、 前記 誤り訂正符号化方式を適用したデータ列をキューに割り当てることを特徴とするデー 夕中継方法。
1 5 . 請求項 1 2記載のデータ中継方法であって、
暗号化または誤り訂正符号化の有無、 方式と各キューの廃棄方法とに基づき、 前記 分割データ列をキューに割り当てることを特徴とするデータ中継方法。
1 6 . 請求項 1 2記載のデ一夕中継方法を実現するデ一夕中継装置。
1 7 . 請求項 1 2記載のデータ中継方法の各ステップの全部または一部をコンビ ュ一夕により実行させるためのプログラム。
1 8 . 複数の送信装置からアプリケーションの要求仕様より決まる伝播遅延時間 の最大値が付加されたデ一夕を受信するステップと、
前記複数の送信装置からのデータのうち、 各データに付加された前記伝播遅延時間 の最大値の小さいものを優先して中継処理するステップとを備えたことを特徴とする デ一夕中継方法。
1 9 . 請求項 1 8記載のデ一夕中継方法において、
2つ以上の中継装置が縦列接続されている場合には、 各中継装置にて、 各データを 中継処理し送信する前に、 当該デ一夕に付加された前記伝播遅延時間の最大値から当 該デ一夕が当該中継装置に滞在していた時間を差し引いた値を、 新たな伝播遅延時間 の最大値として当該データに付加して送信することを特徴とするデータ中継方法。
2 0 . 請求項 1 8記載のデータ中継方法において、
2つ以上の中継装置が縦列接続されている場合には、 各中継装置にて、 前記複数の 送信装置から前記伝播遅延時間の最大値の他に送信時刻が付加されたデータを受信し、 現在の時刻から前記送信時刻を差し引いたものを、 データに付加された前記伝播遅延 時間の最大値から差し引いた値を、 残伝播遅延時間として求め、 当該残伝播遅延時間 の小さいものを優先して中継処理することを特徴とするデータ中継方法。
2 1 . 請求項 1 8または 1 9に記載のデータ中継方法において、 中継装置から受信装置までに要する伝播遅延時間を計測し、 当該計測で得た伝播遅 延時間が、 デ一夕に付加された前記伝播遅延時間の最大値よりも大きい場合には当該 データの中継処理を行わないことを特徴とするデータ中継方法。
2 2 . 請求項 2 0記載のデータ中継方法において、
中継装置から受信装置までに要する伝播遅延時間を計測し、 当該計測で得た伝播遅 延時間が前記残伝播遅延時間よりも大きい場合には当該デ一夕の中継処理を行わない ことを特徴とするデータ中継方法。
2 3 . 送信装置にてデ一夕をバケツトに分割して伝送するデータ伝送方法であつ て、
前記送信装置にてパケットを再分割して細分割パケットを生成する第 1のステップ と、
前記送信装置にて少なくとも 1個の細分割バケツトから誤り訂正パケットを生成し、 伝送する第 2のステップとを備えたことを特徴とするデータ伝送方法。
2 4 . 請求項 2 3記載のデ一夕伝送方法において、
前記第 2のステツプで伝送されたデータの誤り特性を受信装置にて観測する第 3の ステップと、
前記誤り特性に基づきバケツ卜の分割長を算出する第 4のステップとをさらに備え たことを特徴とするデータ伝送方法。
2 5 . 請求項 2 3記載のデータ伝送方法において、
前記第 2のステツプで伝送されたデータの誤り特性を受信装置にて観測する第 3の ステップと、
前記誤り特性に基づき、 誤り訂正バケツトの生成に用いる細分割バケツトの組み合 わせを決定する第 4のステップとをさらに備えたことを特徴とするデ一夕伝送方法。
2 6 . 請求項 2 4または 2 5に記載のデータ伝送方法において、
前記送信装置にてパケット分割長をある間隔で変更する第 5のステツプと、 前記受信装置にて受信したパケットの長さと誤り特性とを記録する第 6のステツプ とをさらに備え、 前記第 4のステツプでは、 前記第 6のステヅプにおける記録に基づき、 前記パケッ ト分割長または前記細分割パケットの組み合わせを決定することを特徴とするデ一夕 伝 ¾万法。
2 7 . 請求項 1 8記載のデータ伝送方法において、
前記第 1のステップでは、 誤り訂正に用いるデータ量の、 伝送データ量に対する比 率から、 バケツトの再分割数を求めることを特徴とするデータ伝送方法。
2 8 . データをバケツトに分割して伝送する送信装置を有するデータ伝送装置で あって、
前記送信装置は、
パケットを再分割して細分割パケットを生成するための再分割手段と、
少なくとも 1個の細分割パケッ卜から誤り訂正パケットを生成するための誤り訂正 パケット生成手段とを備えたことを特徴とするデータ伝送装置。
2 9 . 請求項 2 8記載のデータ伝送装置において、
前記送信装置から伝送されたデータを受信するための受信装置をさらに有し、 前記受信装置は、
前記送信装置から伝送されたデータの誤り特性を観測するための誤り特性観測手段 と、 .
前記誤り特性に基づきパケットの分割長を算出するための分割長算出手段とを備え たことを特徴とするデータ伝送装置。
3 0 . 請求項 2 8記載のデータ伝送装置において、
前記送信装置から伝送されたデータを受信するための受信装置をさらに有し、 前記送信装置から伝送されたデ一夕の誤り特性を観測するための誤り特性観測手段 と、
前記誤り特性に基づき、 誤り訂正バケツトの生成に用いる細分割パケットの組み合 わせを決定するための決定手段とを備えたことを特徴とするデータ伝送装置。
3 1 . 請求項 2 9または 3 0に記載のデータ伝送装置において、 前記送信装置は、 前記受信装置における誤り特性の観測のために、 パケット分割長 をある間隔で変更するための変更手段をさらに備えたことを特徴とするデータ伝送装
3 2 . 請求項 3 1記載のデータ伝送装置において、
前記受信装置は、
前記誤り特性の観測のために、 受信したパケッ卜の長さと誤り特性とを記録するた めの記録手段と、
前記記録に基づき、 前記パケット分割長または前記細分割パケットの組み合わせを 決定するための決定手段とをさらに備えたことを特徴とするデータ伝送装置。
3 3 . 請求項 2 8記載のデータ伝送装置において、
前記再分割手段は、 誤り訂正に用いるデ一夕量の、 伝送データ量に対する比率から、 パケットの再分割数を求めるための手段を備えたことを特徴とするデ一夕伝送装置。
PCT/JP2001/006719 2000-08-25 2001-08-06 Procede de transmission de donnees et procede de relais de donnees WO2002017637A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
AU2001276731A AU2001276731A1 (en) 2000-08-25 2001-08-06 Data transmission method and data relay method
EP01954445A EP1313318A1 (en) 2000-08-25 2001-08-06 Data transmission method and data relay method

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
JP2000255068 2000-08-25
JP2000-255068 2000-08-25
JP2000300060 2000-09-29
JP2000-300060 2000-09-29
JP2000-328561 2000-10-27
JP2000328561 2000-10-27
JP2001-057388 2001-03-01
JP2001057388 2001-03-01

Publications (1)

Publication Number Publication Date
WO2002017637A1 true WO2002017637A1 (fr) 2002-02-28

Family

ID=27481556

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2001/006719 WO2002017637A1 (fr) 2000-08-25 2001-08-06 Procede de transmission de donnees et procede de relais de donnees

Country Status (4)

Country Link
US (1) US20020164024A1 (ja)
EP (1) EP1313318A1 (ja)
AU (1) AU2001276731A1 (ja)
WO (1) WO2002017637A1 (ja)

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1371225A1 (en) * 2001-03-12 2003-12-17 Polycom, Inc. A low-delay video encoding method for concealing the effects of packet loss in multi-channel packet switched networks
JP2005204175A (ja) * 2004-01-16 2005-07-28 Ntt Communications Kk デジタルコンテンツ暗号化装置、デジタルコンテンツ暗号化方法およびデジタルコンテンツ暗号化プログラム、並びにデジタルコンテンツ復号化プログラム
EP1725038A2 (en) * 2001-03-12 2006-11-22 Polycom, Inc. A low-delay video encoding method for concealing the effects of packet loss in multi-channel packet switched networks
WO2008013160A1 (fr) * 2006-07-28 2008-01-31 Aquacast Corporation Procédé de communication mobile numérique
JP2008034939A (ja) * 2006-07-26 2008-02-14 Oki Electric Ind Co Ltd データ配信システム、配信サーバ、サーバ及び受信端末
JP2008042715A (ja) * 2006-08-09 2008-02-21 Fujitsu Ltd フレームを暗号化して中継する中継装置
JP2010034860A (ja) * 2008-07-29 2010-02-12 Fujitsu Ltd セキュリティ機能を有するipネットワーク通信方法及び通信システム
JP2010041708A (ja) * 2008-08-04 2010-02-18 Inha-Industry Partnership Inst マルチメディアサービスを提供するためのスケジューリング方法
JP2010183439A (ja) * 2009-02-06 2010-08-19 Canon Inc 送信装置、及び、方法、プログラム
JP2011509547A (ja) * 2007-12-05 2011-03-24 オンライブ インコーポレイテッド 通信チャンネルを経て送信されるある形式のマルチメディアデータを保護するシステム及び方法
JP2011199647A (ja) * 2010-03-19 2011-10-06 Nippon Telegr & Teleph Corp <Ntt> 誤り訂正符号化装置及び方法及びプログラム及び誤り訂正復号化装置及び方法及びプログラム
TWI401917B (zh) * 2008-12-25 2013-07-11 Mitsubishi Electric Corp 通訊管理裝置、通訊節點與通訊系統及資料通訊方法
US8532287B2 (en) 2004-05-27 2013-09-10 Sony Corporation Information processing system and information processing method for use therewith, information processing apparatus and information processing method for use therewith, and program
JP2015532794A (ja) * 2012-07-19 2015-11-12 アルカテル−ルーセント 衛星モバイルtvブロードキャストのクロス・レイヤ・コーディングの方法および装置
WO2018121742A1 (zh) * 2016-12-30 2018-07-05 北京奇虎科技有限公司 一种流数据的传输方法和装置
CN113315809A (zh) * 2021-04-22 2021-08-27 佛山市第二人民医院(佛山市便民医院) 一种医疗设备的高速数据传输延迟容忍方法及系统

Families Citing this family (99)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100441604B1 (ko) * 2002-03-19 2004-07-23 삼성전자주식회사 멀티미디어 스트리밍 서비스를 위한 패킷 전송장치 및 그방법
JP3821086B2 (ja) * 2002-11-01 2006-09-13 ソニー株式会社 ストリーミングシステム及びストリーミング方法、クライアント端末及びデータ復号方法、並びにプログラム
FR2848372B1 (fr) * 2002-12-09 2005-04-01 Medialive Synchronisation de flux audiovisuels securises
US20090118019A1 (en) 2002-12-10 2009-05-07 Onlive, Inc. System for streaming databases serving real-time applications used through streaming interactive video
US9077991B2 (en) 2002-12-10 2015-07-07 Sony Computer Entertainment America Llc System and method for utilizing forward error correction with video compression
US9108107B2 (en) * 2002-12-10 2015-08-18 Sony Computer Entertainment America Llc Hosting and broadcasting virtual events using streaming interactive video
US9314691B2 (en) 2002-12-10 2016-04-19 Sony Computer Entertainment America Llc System and method for compressing video frames or portions thereof based on feedback information from a client device
US8964830B2 (en) * 2002-12-10 2015-02-24 Ol2, Inc. System and method for multi-stream video compression using multiple encoding formats
US9138644B2 (en) 2002-12-10 2015-09-22 Sony Computer Entertainment America Llc System and method for accelerated machine switching
AU2003285634A1 (en) * 2002-12-16 2004-07-09 Koninklijke Philips Electronics N.V. Method and apparatus to encrypt video data streams
WO2004088501A1 (en) * 2003-03-28 2004-10-14 Thomson Licensing S.A. System and method for transmitting media based files
US7457973B2 (en) * 2003-06-20 2008-11-25 Texas Instruments Incorporated System and method for prioritizing data transmission and transmitting scheduled wake-up times to network stations based on downlink transmission duration
US7085282B2 (en) * 2003-07-01 2006-08-01 Thomson Licensing Method and apparatus for providing forward error correction
US8472792B2 (en) 2003-12-08 2013-06-25 Divx, Llc Multimedia distribution system
US7519274B2 (en) 2003-12-08 2009-04-14 Divx, Inc. File format for multiple track digital data
EP1521475A1 (fr) * 2004-01-20 2005-04-06 France Telecom Procédé et dispositif de traitement de flux de données codées
US8737219B2 (en) * 2004-01-30 2014-05-27 Hewlett-Packard Development Company, L.P. Methods and systems that use information about data packets to determine an order for sending the data packets
US7966488B2 (en) * 2004-01-30 2011-06-21 Hewlett-Packard Development Company, L. P. Methods and systems that use information about encrypted data packets to determine an order for sending the data packets
US20050207569A1 (en) * 2004-03-16 2005-09-22 Exavio, Inc Methods and apparatus for preparing data for encrypted transmission
US7818444B2 (en) 2004-04-30 2010-10-19 Move Networks, Inc. Apparatus, system, and method for multi-bitrate content streaming
JP2007513539A (ja) * 2004-07-26 2007-05-24 イルデト・アクセス・ベー・フェー データ・ストリームを部分的にスクランブルする方法
US9647952B2 (en) 2004-08-06 2017-05-09 LiveQoS Inc. Network quality as a service
US7953114B2 (en) 2004-08-06 2011-05-31 Ipeak Networks Incorporated System and method for achieving accelerated throughput
US9189307B2 (en) 2004-08-06 2015-11-17 LiveQoS Inc. Method of improving the performance of an access network for coupling user devices to an application server
US8009696B2 (en) * 2004-08-06 2011-08-30 Ipeak Networks Incorporated System and method for achieving accelerated throughput
JP2006185016A (ja) * 2004-12-27 2006-07-13 Hitachi Ltd コンテンツ移動制御装置及び方法
EP1725036A1 (en) * 2005-05-20 2006-11-22 Thomson Licensing A method and a video server for embedding audiovisual packets in an IP packet
JP4504270B2 (ja) * 2005-06-30 2010-07-14 富士通株式会社 パケット中継装置およびパケット中継方法
WO2007017826A2 (en) * 2005-08-08 2007-02-15 Koninklijke Philips Electronics N.V. Method and system for video copyright protection
US8014389B2 (en) * 2005-12-06 2011-09-06 Lippershy Celestial Llc Bidding network
CN100442835C (zh) * 2005-12-27 2008-12-10 浪潮电子信息产业股份有限公司 一种视频节目的数字版权和数字水印保护方法
EP1999883A4 (en) 2006-03-14 2013-03-06 Divx Llc FEDERATED DIGITAL RIGHTS MANAGEMENT SYSTEM COMPRISING CONFIDENCE SYSTEMS
JP4696008B2 (ja) * 2006-03-20 2011-06-08 富士通株式会社 Ip送信装置およびip送信方法
JP2008104040A (ja) * 2006-10-20 2008-05-01 Fujitsu Ltd 共通鍵生成装置および共通鍵生成方法
BRPI0622135A2 (pt) * 2006-12-21 2011-12-27 Thomson Licensing mÉtodo para suporte corretivo de erros futuros para dados de vÍdeo e Áudio em tempo real atravÉs de redes de trabalho protocoladas na internet
EP4213033A1 (en) 2007-01-05 2023-07-19 DivX, LLC Video distribution system including progressive playback
KR20090002939A (ko) * 2007-07-05 2009-01-09 삼성전자주식회사 디지털 방송 서비스에 있어서 비디오 데이터 송수신 장치및 방법
US20090225983A1 (en) * 2007-10-31 2009-09-10 Ramiro Reinoso System and method for improved processing and decoding of an encrypted digital video signal
KR20100106327A (ko) 2007-11-16 2010-10-01 디브이엑스, 인크. 멀티미디어 파일을 위한 계층적 및 감소된 인덱스 구조
JP2009188674A (ja) * 2008-02-05 2009-08-20 Fujitsu Ltd 送信装置、受信装置、動画音声伝送品質評価方法および動画音声伝送品質評価プログラム
US8001260B2 (en) 2008-07-28 2011-08-16 Vantrix Corporation Flow-rate adaptation for a connection of time-varying capacity
US7844725B2 (en) * 2008-07-28 2010-11-30 Vantrix Corporation Data streaming through time-varying transport media
US8364024B2 (en) 2009-02-03 2013-01-29 Broadcom Corporation Constructing video frames and synchronizing audio data in a media player from data received via a plurality of diverse protocol stack paths
US20100199322A1 (en) * 2009-02-03 2010-08-05 Bennett James D Server And Client Selective Video Frame Pathways
US7975063B2 (en) * 2009-05-10 2011-07-05 Vantrix Corporation Informative data streaming server
CN101568027B (zh) * 2009-05-22 2012-09-05 华为技术有限公司 转发视频数据的方法、装置和系统
US20110016313A1 (en) * 2009-07-15 2011-01-20 Qualcomm Incorporated HEADER COMPRESSION FOR TUNNELED IPsec PACKET
EP2507995A4 (en) 2009-12-04 2014-07-09 Sonic Ip Inc SYSTEMS AND METHODS FOR TRANSPORTING ELEMENTARY BIT TRAIN CRYPTOGRAPHIC MATERIAL
US8914534B2 (en) 2011-01-05 2014-12-16 Sonic Ip, Inc. Systems and methods for adaptive bitrate streaming of media stored in matroska container files using hypertext transfer protocol
US10951743B2 (en) 2011-02-04 2021-03-16 Adaptiv Networks Inc. Methods for achieving target loss ratio
US8717900B2 (en) 2011-02-07 2014-05-06 LivQoS Inc. Mechanisms to improve the transmission control protocol performance in wireless networks
US9590913B2 (en) 2011-02-07 2017-03-07 LiveQoS Inc. System and method for reducing bandwidth usage of a network
US8812662B2 (en) 2011-06-29 2014-08-19 Sonic Ip, Inc. Systems and methods for estimating available bandwidth and performing initial stream selection when streaming content
US9137551B2 (en) 2011-08-16 2015-09-15 Vantrix Corporation Dynamic bit rate adaptation over bandwidth varying connection
US9467708B2 (en) 2011-08-30 2016-10-11 Sonic Ip, Inc. Selection of resolutions for seamless resolution switching of multimedia content
KR101928910B1 (ko) 2011-08-30 2018-12-14 쏘닉 아이피, 아이엔씨. 복수의 최대 비트레이트 레벨들을 사용하여 인코딩된 비디오를 인코딩하고 스트리밍하기 위한 시스템들 및 방법들
US8787570B2 (en) 2011-08-31 2014-07-22 Sonic Ip, Inc. Systems and methods for automatically genenrating top level index files
US8799647B2 (en) 2011-08-31 2014-08-05 Sonic Ip, Inc. Systems and methods for application identification
US8909922B2 (en) 2011-09-01 2014-12-09 Sonic Ip, Inc. Systems and methods for playing back alternative streams of protected content protected using common cryptographic information
US8964977B2 (en) 2011-09-01 2015-02-24 Sonic Ip, Inc. Systems and methods for saving encoded media streamed using adaptive bitrate streaming
US8918908B2 (en) 2012-01-06 2014-12-23 Sonic Ip, Inc. Systems and methods for accessing digital content using electronic tickets and ticket tokens
CN103379365B (zh) * 2012-04-27 2017-08-08 日立(中国)研究开发有限公司 内容获取装置及方法、内容及多媒体发行系统
US9936267B2 (en) 2012-08-31 2018-04-03 Divx Cf Holdings Llc System and method for decreasing an initial buffering period of an adaptive streaming system
CN103051616A (zh) * 2012-12-17 2013-04-17 中国科学院信息工程研究所 一种基于rssp--ii协议的数据报传输方法
US9313510B2 (en) 2012-12-31 2016-04-12 Sonic Ip, Inc. Use of objective quality measures of streamed content to reduce streaming bandwidth
US9191457B2 (en) 2012-12-31 2015-11-17 Sonic Ip, Inc. Systems, methods, and media for controlling delivery of content
US9680689B2 (en) * 2013-02-14 2017-06-13 Comcast Cable Communications, Llc Fragmenting media content
US10397292B2 (en) 2013-03-15 2019-08-27 Divx, Llc Systems, methods, and media for delivery of content
US9906785B2 (en) 2013-03-15 2018-02-27 Sonic Ip, Inc. Systems, methods, and media for transcoding video data according to encoding parameters indicated by received metadata
US9094737B2 (en) 2013-05-30 2015-07-28 Sonic Ip, Inc. Network video streaming with trick play based on separate trick play files
US9380099B2 (en) 2013-05-31 2016-06-28 Sonic Ip, Inc. Synchronizing multiple over the top streaming clients
US9100687B2 (en) 2013-05-31 2015-08-04 Sonic Ip, Inc. Playback synchronization across playback devices
CN103368963A (zh) * 2013-07-15 2013-10-23 网宿科技股份有限公司 内容分发网络中的http报文防篡改方法
US9386067B2 (en) 2013-12-30 2016-07-05 Sonic Ip, Inc. Systems and methods for playing adaptive bitrate streaming content by multicast
US9380351B2 (en) * 2014-01-17 2016-06-28 Lg Display Co., Ltd. Apparatus for transmitting encoded video stream and method for transmitting the same
US9596323B2 (en) 2014-03-18 2017-03-14 Qualcomm Incorporated Transport accelerator implementing client side transmission functionality
US9596281B2 (en) 2014-03-18 2017-03-14 Qualcomm Incorporated Transport accelerator implementing request manager and connection manager functionality
US9350484B2 (en) 2014-03-18 2016-05-24 Qualcomm Incorporated Transport accelerator implementing selective utilization of redundant encoded content data functionality
US20150271225A1 (en) 2014-03-18 2015-09-24 Qualcomm Incorporated Transport accelerator implementing extended transmission control functionality
US9866878B2 (en) 2014-04-05 2018-01-09 Sonic Ip, Inc. Systems and methods for encoding and playing back video at different frame rates using enhancement layers
KR102548789B1 (ko) 2014-08-07 2023-06-29 디빅스, 엘엘씨 독립적으로 인코딩된 타일을 포함한 기본 비트스트림을 보호하는 시스템 및 방법
KR102012682B1 (ko) 2015-01-06 2019-08-22 디브이엑스, 엘엘씨 디바이스들간에 콘텐트를 인코딩 및 공유하기 위한 시스템들 및 방법들
CN107251008B (zh) 2015-02-27 2020-11-13 帝威视有限公司 在实况视频编码和流传输中进行帧复制和帧扩展的系统和方法
US10075292B2 (en) 2016-03-30 2018-09-11 Divx, Llc Systems and methods for quick start-up of playback
US10211950B1 (en) * 2016-05-20 2019-02-19 Harmonic, Inc. High bit rate media FEC recovery
US10231001B2 (en) 2016-05-24 2019-03-12 Divx, Llc Systems and methods for providing audio content during trick-play playback
US10129574B2 (en) 2016-05-24 2018-11-13 Divx, Llc Systems and methods for providing variable speeds in a trick-play mode
US10148989B2 (en) 2016-06-15 2018-12-04 Divx, Llc Systems and methods for encoding video content
US10498795B2 (en) 2017-02-17 2019-12-03 Divx, Llc Systems and methods for adaptive switching between multiple content delivery networks during adaptive bitrate streaming
US11082408B2 (en) * 2017-07-20 2021-08-03 Michael T. Jones Systems and methods for packet spreading data transmission with anonymized endpoints
US11032257B1 (en) * 2017-12-08 2021-06-08 Rankin Labs, Llc Method for covertly delivering a packet of data over a network
US11861025B1 (en) 2018-01-08 2024-01-02 Rankin Labs, Llc System and method for receiving and processing a signal within a TCP/IP protocol stack
US11989320B2 (en) 2018-12-19 2024-05-21 Rankin Labs, Llc Hidden electronic file system within non-hidden electronic file system
US10903977B2 (en) 2018-12-19 2021-01-26 Rankin Labs, Llc Hidden electronic file systems
US11108671B2 (en) 2019-01-21 2021-08-31 Rankin Labs, Llc Systems and methods for processing network traffic using dynamic memory
US11825142B2 (en) 2019-03-21 2023-11-21 Divx, Llc Systems and methods for multimedia swarms
US11055166B2 (en) 2019-05-28 2021-07-06 Rankin Labs, Llc Covertly storing a payload of data within a network
US11729184B2 (en) 2019-05-28 2023-08-15 Rankin Labs, Llc Detecting covertly stored payloads of data within a network
CN112040302B (zh) * 2019-06-03 2023-01-03 优视科技有限公司 视频缓冲方法、装置、电子设备及计算机可读存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08331543A (ja) * 1995-05-31 1996-12-13 Toshiba Corp ディジタルテレビジョン放送システム
JPH09116903A (ja) * 1995-10-16 1997-05-02 Nippon Telegr & Teleph Corp <Ntt> 階層化符号化装置および階層化復号化装置
JPH11136220A (ja) * 1997-06-04 1999-05-21 Toshiba Corp 符号伝送方法、送信装置、受信装置および通信システム
JP2000151619A (ja) * 1998-11-04 2000-05-30 Sony Corp 伝送方法及び伝送装置
JP2000165440A (ja) * 1998-11-24 2000-06-16 Fujitsu Ltd 優先転送制御装置
JP2000188774A (ja) * 1996-08-30 2000-07-04 Kokusai Electric Co Ltd デジタル通信方式

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4888767A (en) * 1984-12-25 1989-12-19 Nec Corporation Repeat request signal transmission method for multi-station packet communication
US5764526A (en) * 1996-04-08 1998-06-09 Microsoft Corporation Dynamic propagation delay calculation using an array of storage cells
JPH11266243A (ja) * 1997-12-09 1999-09-28 Canon Inc 情報処理装置及び方法
US6760309B1 (en) * 2000-03-28 2004-07-06 3Com Corporation Method of dynamic prioritization of time sensitive packets over a packet based network

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08331543A (ja) * 1995-05-31 1996-12-13 Toshiba Corp ディジタルテレビジョン放送システム
JPH09116903A (ja) * 1995-10-16 1997-05-02 Nippon Telegr & Teleph Corp <Ntt> 階層化符号化装置および階層化復号化装置
JP2000188774A (ja) * 1996-08-30 2000-07-04 Kokusai Electric Co Ltd デジタル通信方式
JPH11136220A (ja) * 1997-06-04 1999-05-21 Toshiba Corp 符号伝送方法、送信装置、受信装置および通信システム
JP2000151619A (ja) * 1998-11-04 2000-05-30 Sony Corp 伝送方法及び伝送装置
JP2000165440A (ja) * 1998-11-24 2000-06-16 Fujitsu Ltd 優先転送制御装置

Cited By (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1725038A3 (en) * 2001-03-12 2009-08-26 Polycom, Inc. A low-delay video encoding method for concealing the effects of packet loss in multi-channel packet switched networks
EP1371225A4 (en) * 2001-03-12 2006-06-07 Polycom Inc DELAYABLE VIDEO CODING METHOD FOR HIDING THE EFFECTS OF PACKAGE LOSSES IN PACKAGED MULTICHANNEL NETWORKS
US7136394B2 (en) 2001-03-12 2006-11-14 Polycom, Inc. Low-delay video encoding method for concealing the effects of packet loss in multi-channel packet switched networks
EP1725038A2 (en) * 2001-03-12 2006-11-22 Polycom, Inc. A low-delay video encoding method for concealing the effects of packet loss in multi-channel packet switched networks
EP1371225A1 (en) * 2001-03-12 2003-12-17 Polycom, Inc. A low-delay video encoding method for concealing the effects of packet loss in multi-channel packet switched networks
JP2005204175A (ja) * 2004-01-16 2005-07-28 Ntt Communications Kk デジタルコンテンツ暗号化装置、デジタルコンテンツ暗号化方法およびデジタルコンテンツ暗号化プログラム、並びにデジタルコンテンツ復号化プログラム
US8532287B2 (en) 2004-05-27 2013-09-10 Sony Corporation Information processing system and information processing method for use therewith, information processing apparatus and information processing method for use therewith, and program
JP2008034939A (ja) * 2006-07-26 2008-02-14 Oki Electric Ind Co Ltd データ配信システム、配信サーバ、サーバ及び受信端末
JP4569535B2 (ja) * 2006-07-26 2010-10-27 沖電気工業株式会社 データ配信システム及びサーバ
WO2008013160A1 (fr) * 2006-07-28 2008-01-31 Aquacast Corporation Procédé de communication mobile numérique
JP2008042715A (ja) * 2006-08-09 2008-02-21 Fujitsu Ltd フレームを暗号化して中継する中継装置
JP2011509547A (ja) * 2007-12-05 2011-03-24 オンライブ インコーポレイテッド 通信チャンネルを経て送信されるある形式のマルチメディアデータを保護するシステム及び方法
JP2010034860A (ja) * 2008-07-29 2010-02-12 Fujitsu Ltd セキュリティ機能を有するipネットワーク通信方法及び通信システム
JP2010041708A (ja) * 2008-08-04 2010-02-18 Inha-Industry Partnership Inst マルチメディアサービスを提供するためのスケジューリング方法
TWI401917B (zh) * 2008-12-25 2013-07-11 Mitsubishi Electric Corp 通訊管理裝置、通訊節點與通訊系統及資料通訊方法
US8503444B2 (en) 2009-02-06 2013-08-06 Canon Kabushiki Kaisha Transmission device, transmission method, and program for the same
JP2010183439A (ja) * 2009-02-06 2010-08-19 Canon Inc 送信装置、及び、方法、プログラム
JP2011199647A (ja) * 2010-03-19 2011-10-06 Nippon Telegr & Teleph Corp <Ntt> 誤り訂正符号化装置及び方法及びプログラム及び誤り訂正復号化装置及び方法及びプログラム
JP2015532794A (ja) * 2012-07-19 2015-11-12 アルカテル−ルーセント 衛星モバイルtvブロードキャストのクロス・レイヤ・コーディングの方法および装置
WO2018121742A1 (zh) * 2016-12-30 2018-07-05 北京奇虎科技有限公司 一种流数据的传输方法和装置
CN113315809A (zh) * 2021-04-22 2021-08-27 佛山市第二人民医院(佛山市便民医院) 一种医疗设备的高速数据传输延迟容忍方法及系统
CN113315809B (zh) * 2021-04-22 2022-05-24 佛山市第二人民医院(佛山市便民医院) 一种医疗设备的高速数据传输延迟容忍方法及系统

Also Published As

Publication number Publication date
US20020164024A1 (en) 2002-11-07
EP1313318A1 (en) 2003-05-21
AU2001276731A1 (en) 2002-03-04

Similar Documents

Publication Publication Date Title
WO2002017637A1 (fr) Procede de transmission de donnees et procede de relais de donnees
US6975645B1 (en) Layer-coded data transmitting apparatus
JP4965059B2 (ja) ビデオストリームの切り替え
EP1813115B1 (en) Buffering packets of a media stream
KR100537499B1 (ko) 전송제어 파라미터 생성방법 및 프레임 특성에 따른선택적 자동 재전송 방법
JP2002141945A (ja) データ送信装置、およびデータ送信方法、並びにプログラム記憶媒体
US20030103243A1 (en) Transmission system
US9781488B2 (en) Controlled adaptive rate switching system and method for media streaming over IP networks
US20060291475A1 (en) Selective forward error correction
KR20130040090A (ko) 복합 네트워크에서 멀티미디어 데이터를 전송하기 위한 장치 및 그 방법
US20110085551A1 (en) Staggercasting method and apparatus using type of service (tos) information
CN109756789B (zh) 一种音视频数据包的丢包处理方法和系统
JP2009512265A (ja) ネットワーク上の動画データ伝送制御システムとその方法
EP1371225B1 (en) Video encoding and transporting method for concealing the effects of packet loss in multi-channel packet switched networks
JP2007028241A (ja) 映像符号化・送信装置,映像符号化・送信方法,映像符号化・送信プログラムおよびその記録媒体
US20090268730A1 (en) Data transmitting apparatus and method and program for controlling transmission rate
Feamster Adaptive delivery of real-time streaming video
US20070033609A1 (en) Media stream multicast distribution method and apparatus
US20090313673A1 (en) Method and System for Protecting MPEG Frames During Transmission Within An Internet Protocol (IP) Network
JP2005033556A (ja) データ送信装置、データ送信方法、データ受信装置、データ受信方法
Sinky et al. Analysis of H. 264 bitstream prioritization for dual TCP/UDP streaming of HD video over WLANs
JP5031230B2 (ja) データ送信装置及び方法
US20040143849A1 (en) Method and system to create a deterministic traffic profile for isochronous data networks
Exposito et al. Building self-optimized communication systems based on applicative cross-layer information
CN105306970B (zh) 一种流媒体直播发送速度的控制方法及装置

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref country code: JP

Ref document number: 2002 522200

Kind code of ref document: A

Format of ref document f/p: F

AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 10111761

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2001954445

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2001954445

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWW Wipo information: withdrawn in national office

Ref document number: 2001954445

Country of ref document: EP