WO2004008760A1 - コンテンツ受信器およびコンテンツ送信器 - Google Patents

コンテンツ受信器およびコンテンツ送信器 Download PDF

Info

Publication number
WO2004008760A1
WO2004008760A1 PCT/JP2003/009043 JP0309043W WO2004008760A1 WO 2004008760 A1 WO2004008760 A1 WO 2004008760A1 JP 0309043 W JP0309043 W JP 0309043W WO 2004008760 A1 WO2004008760 A1 WO 2004008760A1
Authority
WO
WIPO (PCT)
Prior art keywords
content
packet
information
capsule
extended
Prior art date
Application number
PCT/JP2003/009043
Other languages
English (en)
French (fr)
Inventor
Masahiro Takatori
Shoichi Goto
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 EP03741425.7A priority Critical patent/EP1553774B1/en
Priority to CN038164469A priority patent/CN1669320B/zh
Priority to AU2003281136A priority patent/AU2003281136A1/en
Priority to JP2004521223A priority patent/JP4042745B2/ja
Priority to US10/515,528 priority patent/US7830881B2/en
Publication of WO2004008760A1 publication Critical patent/WO2004008760A1/ja
Priority to US12/899,074 priority patent/US8503471B2/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17345—Control of the passage of the selected programme
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H04L1/1671—Details of the supervisory signal the supervisory signal being transmitted together with control information
    • H04L1/1678—Details of the supervisory signal the supervisory signal being transmitted together with control information where the control information is for timing, e.g. time stamps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23614—Multiplexing of additional data and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing 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/2381—Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [IP] network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing 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/2389—Multiplex stream processing, e.g. multiplex stream encrypting
    • H04N21/23895—Multiplex stream processing, e.g. multiplex stream encrypting involving multiplex stream encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637—Control signals issued by the client directed to the server or network components
    • H04N21/6375—Control signals issued by the client directed to the server or network components for requesting retransmission, e.g. of data packets lost or corrupted during transmission from server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/8547—Content authoring involving timestamps for synchronizing content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309—Transmission or handling of upstream communications
    • H04N7/17318—Direct or substantially direct transmission and handling of requests

Definitions

  • the present invention relates to a digital television broadcast receiver, a personal computer, a mobile phone, a mobile information terminal, and a mobile phone adapter.
  • transmitters and receivers having functions such as streaming for transmitting and receiving video and audio contents via a communication network have become widespread in the market.
  • FIG. 7 is a diagram showing a configuration of a conventional content transmitter.
  • FIG. 10 is a diagram showing a transition of a packet configuration between a conventional content transmitter and a conventional content receiver.
  • FIG. 11 is a diagram showing the structure of a conventional packet.
  • the video encoder 51 shown in FIG. 7 encodes a video signal by a predetermined compression method and outputs the encoded video signal to a subsequent stage.
  • Fig. 7 shows a configuration using the MPEG2 method.
  • the output from the video encoder 51 is composed of an MPEG2 transport stream bucket (hereinafter abbreviated as MPEG2-TSP).
  • the system clock generator 54 generates a 27 MHz clock.
  • the system clock used when the video encoder 51 encodes the video signal is this 27 MHz clock.
  • the audio encoder 52 encodes the audio signal using the same compression method as the video encoder 51, and outputs MPEG2-TSP to the subsequent stage.
  • the data encoder 53 encodes data such as data broadcast and EPG data in the same compression format as the video encoder 51, and outputs MPEG2_TSP to the subsequent stage.
  • the stream multiplexer 55 multiplexes the above-mentioned three MPEG2-TSPs on the time axis. Further, the stream multiplexer 55 generates a PCR signal for reproducing the system clock on the receiving side by periodically using a count value obtained by counting the system clock at a cycle of about 50 ms. And the stream multiplexer 55 After the signal is converted into 1 ⁇ £ 2_3, it is further multiplexed with the above multiplexed signal and output to the subsequent stage as an MPEG2 transport stream (hereinafter abbreviated as MPEG2-TS). . This output signal is shown as S11 in FIG.
  • FIG. 10 is a diagram showing a transition of multiplexing of packets on a time axis.
  • the horizontal axis in Fig. 10 is time. However, in FIG. 10, the steady delay in each process is ignored and not shown.
  • 10 1, VIDEO 02, VIDEO 3, AUD I 01, AUD I 02, and DAT A 1 of 31 1 are packets multiplexed by the stream multiplexer 55.
  • 31 1, 10 £ 1, VIDE ⁇ 2, and VIDE03 are available in MPEG2-TSP with video code.
  • AUD I01 and AUD I02 of S11 are audio-encoded MPEG21-TSP.
  • DATA 1 in S11 is a data encoded MPEG2-TSP. The description of the PCR signal is omitted because it is a well-known content in the MPEG2 system.
  • the scrambler 56 encrypts the MPEG2-TS with a predetermined symbol and outputs it.
  • the example shown here is an example of the MULT I 2 system.
  • the RTP packetizer 58 encapsulates each MPEG2-TSP with one or more.
  • the RTP packetizer 58 has a counter for counting the path clock that the transceiver 61 reproduces based on the reference time information provided from the communication network. The transceiver 61 will be described later.
  • the RTP packetizer 58 adds a header including the time stamp as the counter value and information identifying that the encapsulated information is MPEG2-TSP to the output signal, Output to the subsequent stage.
  • This output signal is shown as S12 in FIG. Also, 312 Ding? Is the header. This time stamp is used when the receiver uses the bus clock to correct the jitter when the packet arrives.
  • UDP / IP packetizer 59 stores each RTP packet in an IP datagram for transmission to the IP communication network. Then, the UDP / IP packetizer 59 adds an IP packet header to each of the stored RTP packets and outputs the packet as an IP packet. This output signal is shown as S13 in FIG.
  • the IP of S13 is a header in a communication protocol such as an IP header. IP Since the contents of the packet header are well known on the Internet, description thereof will be omitted.
  • the Ethernet packetizer 60 stores the IP packet in the data area of the Ethernet, adds a header and a checksum to the Ethernet packet, and outputs the packet as an Ethernet packet. The Ethernet bucket header and the checksum are well known on the Internet, and will not be described.
  • the transceiver 61 transmits the Ethernet packet to the Internet network. Then, the transceiver 61 receives the above-described reference time information and the like.
  • FIG. 11 is a diagram showing a conventional packet configuration.
  • 10 MPEG2-TSPs are encapsulated.
  • an 8-byte header including MPEG2-TSP identification information and a time stamp used when the packet arrives is added.
  • it is converted into an 182-byte RTP packet.
  • an 8-byte UDP packet header is added to the RTP packet to form a 1900-byte UDP packet.
  • a 24-byte IP bucket header is added to the UDP bucket to make a 1924-byte IP packet.
  • a 14-byte Ethernet header and a 4-byte checksum are added to the IP packet to form a 1942-byte Ethernet bucket.
  • the maximum transmission bucket unit, MTU is often limited. If the size of the packet data to be sent exceeds the MTU, the packet is often divided on the communication network. On the Internet, such a process is called a fragment.
  • the MTU in the Ethernet communication network is 1500 bytes.
  • the data size of the data area of the Ethernet bucket exceeds the MTU, fragmentation in the communication network cannot be prevented. Therefore, some packets may lose header information. For this reason, it is difficult for the receiving side to compensate for bucket loss jitter generated after fragmentation.
  • FIG. 8 is a diagram showing a configuration of a conventional example of a content receiver.
  • FIG. 9 is a flowchart showing the operation from reception of a packet to decoding.
  • the receiver 71 receives an Ethernet bucket from a communication network such as the Internet, and outputs the packet to a subsequent stage. This Ethernet bucket is shown in FIG.
  • the Ethernet packet processor 72 performs Ethernet protocol processing on the Ethernet packet addressed to the Ethernet packet processor 72, and outputs a UDP / IP packet to the subsequent stage. This process is shown in STEP 91 of FIG. This output signal is shown in S14 of FIG.
  • S14 in FIG. 10 indicates that jitter and packet loss have occurred in the received UDP ZIP packet as a result of transmitting and receiving the received UDP / IP bucket via the Internet network.
  • the bucket including V I DEOl and DATA1 has a larger delay than the steady delay.
  • Packets including VIDEO03 and AUDI02 have a smaller delay than the regular delay.
  • the jitter and packet loss of the Internet will be described with reference to FIG.
  • packets are assigned different routes, packets cannot be transmitted during the valid time of the packet, packets are deleted at the gateway, and packets are retransmitted. And packet loss occurs.
  • the limited delay on the paper is described in an easy-to-understand manner by intentionally expressing the stationary delay to zero. More specifically, the bucket including VIDEO1 and DATA1 has a longer delay than the steady delay, and is described as being slower than S13.
  • the bucket containing VI DEO 3 and AUD I O 2 is marked earlier (as though it is moving ahead) than S 13 due to the delay being less than the steady delay.
  • the bucket containing VIDEO2 and AUDIO1 has a packet loss.
  • the UDPZIP packet processing section 73 shown in FIG. 8 performs UDP IP protocol processing on the UDP / IP packet and outputs an RTP packet. This process is shown in STEP 92 of FIG. The output signal is shown in S15 of FIG.
  • Ethernet and UDP / IP protocol processing is performed on the Internet. Description is omitted because it is well known.
  • each header includes information indicating the protocol processing method of the data body.
  • the processing methods for various protocols are standardized, and the content receiver can be equipped with the processing methods in advance. Therefore, the content receiver can perform the protocol processing of the data body after removing the header by analyzing the information indicating the protocol in the header.
  • the RTP bucket processor 79 acquires a header of each RTP packet from each RTP bucket shown in FIG. Further, the RTP packet processor 79 acquires information indicating the contents of the configuration data included in the header.
  • the information indicating the contents of the data is information for identifying the format type of the stored data. Here, this information is information for identifying the above-mentioned MP EG2-TSP.
  • the RTP bucket processor 79 has a counter that counts the bus clock reproduced by the receiver 71 using the reference time information. The RTP bucket processor 79 counts this bus clock, and if the counted value matches the time stamp in the header, removes the header and outputs MP EG2—TSP to the subsequent stage (STEP in FIG. 9). 93). Then, the RTP packet processor 79 checks whether or not the MPEG2-TSP is scrambled (STEP 94 in FIG. 9). The MPEG 2 — TSP header has information on whether or not the MPEG 2 — TSP is scrambled outside the scrambled range. Therefore, once the MPEG2-TSP is extracted, the information can be confirmed and descramble processing can be performed. It is possible for the receiving side and the transmitting side to decide which method to use in advance, or to confirm and recognize the table information to be received on the receiving side. .
  • the descrambler 74 descrambles the MPEG2-TSP by a method corresponding to the scrambling method determined on the transmitting side and outputs the descrambled signal. This process is shown in STEP 9 of FIG. This output signal is shown in S17 of FIG.
  • the TS decoder 77 converts 1 ⁇ 1? £ 02-c3? Into a form that the AV decoder 78 can perform AV decoding and outputs (step 97 in FIG. 9).
  • AV decoder one 78 The data input to the AV decoder 78 is AV-decoded and output (STEP 98 in FIG. 9).
  • STEP 93 of FIG. 9 when the counted value of the bus clock does not match the time stamp in the header 1, the TS decoder 1 77 verifies the difference (STEP 95 in FIG. 9). If the difference is within a range that can be compensated for by a buffer inside a playback controller (not shown), the TS decoder 77 waits for the extended TS packet on this buffer. If the difference exceeds the range that can be compensated by this buffer, the TS decoder 77 controls to discard the corresponding TS packet (STEP 96 in FIG. 9).
  • the receiving side cannot compensate for the packet loss occurring in the communication network in real time, and when the packet loss occurs, it becomes a decoy error. It is generated by the count of the bus clock unrelated to the decoding. Also, the reference time information used to generate the bus clock is not sufficiently accurate with respect to the jitter accuracy required for decoding. In addition, this reference time information is affected by the jitter of the communication network. For these reasons, the accuracy of jitter compensation at the time of decoding on the receiving side may be insufficient, resulting in decoding errors.
  • the present invention relates to a receiver for receiving and playing back a content formed by a stream composed of a compressed transport bucket from a transmitting side and receiving the content after receiving the content; Playback means for playing back the stored content. Further, if each transport bucket forming the content is an extended transport packet having playback time indication information generated using the system clock of the transport bucket, the playback means stores the transport packet. Each of the stacked extended transport buckets is reproduced at the time determined from the reproduction time instruction information.
  • the present invention provides a transmitter for transmitting content formed by a stream composed of compressed transport packets, wherein the transmitting means for transmitting the content, and the receiving side is transmitted from the storage means using the system clock of the transport packet A reproduction time instruction information generating means for generating reproduction time instruction information for instructing a reproduction time.
  • the transmitting means transmits an extended transport packet in which reproduction time indication information is added to each transport packet to be transmitted.
  • FIG. 1 is a block diagram of a content transmitter according to Embodiment 1 of the present invention.
  • FIG. 2 is a block diagram of a content receiver according to Embodiment 1 of the present invention.
  • FIG. 3 is a diagram showing a first operation flowchart in the content receiver according to the first embodiment of the present invention.
  • FIG. 4 is a diagram showing a second operation flowchart in the content receiver according to the first embodiment of the present invention.
  • FIG. 5 is a diagram showing the transition of the bucket configuration according to the first embodiment of the present invention.
  • FIG. 6 is a diagram showing an Ethernet packet configuration according to the first embodiment of the present invention.
  • FIG. 7 is a block diagram of a conventional content transmitter
  • Figure 8 shows a block diagram of a conventional content receiver.
  • Fig. 9 is a flowchart showing the operation of the conventional content receiver.
  • FIG 10 shows the transition of the conventional packet configuration
  • FIG 11 shows the conventional packet configuration
  • FIG. 12 is a block diagram of a content receiver according to Embodiment 2 of the present invention.
  • FIG. 13 is a block diagram of the IE 13 9 4 interface of the content receiver according to the second embodiment of the present invention.
  • FIG. 14 is a diagram showing a packet configuration transition according to the second embodiment of the present invention.
  • FIG. 15 shows a first IEEE 1394 bucket configuration according to Embodiment 2 of the present invention.
  • FIG. 16 shows a second IEEE 1394 packet configuration according to the second embodiment of the present invention.
  • FIG. 1 is a diagram illustrating a configuration of a content transmitter according to the first embodiment.
  • FIG. 5 is a diagram showing transition of the bucket configuration in the content transmitter and the content receiver according to the first embodiment.
  • FIG. 6 is a diagram illustrating a configuration of a packet according to the first embodiment.
  • a microcomputer 14 controls each part of the content transmitter.
  • the video encoder 1 encodes the video signal by a predetermined compression method and outputs the video signal to a subsequent stage.
  • the MPEG2 system is shown as an example, and the output signal output from the encoder 1 is composed of MPEG2-TSP.
  • System clock generator 4 generates a 27 MHz clock.
  • the system clock used when the video encoder 11 encodes a video signal is this 27 MHz clock.
  • the audio encoder 1-2 encodes the audio signal using the same compression method as the video encoder 11 and outputs MPEG2-TSP to the subsequent stage.
  • the data encoder 13 encodes data such as data broadcasts and EPG data using the same compression method as the video encoder 11, and outputs MPEG2-TSP to the subsequent stage.
  • the stream multiplexer 4 multiplexes the above three types of MPEG2-TSP on the time axis. Further, the stream multiplexer 4 generates a PCR signal for reproducing the system clock on the receiving side by using a counter for counting the system clock.
  • the PCR signal is generated at a period of about 50 ms. Then, the stream multiplexer 4 converts the PCR signal to MPEG2-TSP, further multiplexes the PCR signal into the multiplexed signal, and outputs the multiplexed signal as MPEG2-TS. This output signal is shown as S1 in FIG.
  • FIG. 5 is a diagram showing the transition of bucket multiplexing on the time axis.
  • the horizontal axis in Fig. 5 is time. However, in Fig. 5, the steady delay in each process is Ignored and not shown.
  • VIDE 51, VIDEO2, VIDEO3, AUDI ⁇ 1, AUDIO2, and DATA1 of S5 are packets multiplexed by the stream multiplexer 5.
  • 31 ⁇ 10 £ ⁇ 1, VI DEO 2 and VIDE ⁇ 3 are video encoded MP EG 2—TSP.
  • AUD I ⁇ 1 and AUD I02 of S1 are audio encoded MPEG2-TSP.
  • DATA1 of S1 is a data encoded MPEG2-TSP. Since the PCR signal is well known in the MPEG2 system, its description is omitted.
  • the scrambler 6 encrypts the MPEG2-TS using a predetermined symbol system and outputs it.
  • the example shown here is an example of the MULT I 2 system.
  • the time stamp adder 7 has a counter that counts the system clock output from the system clock generator 4. Then, the time stamp adder 7 includes the count value in the header as a time stamp, adds this header to each MPEG 2—TS (in this example, scrambled), and adds it to the subsequent stage as an extended TS packet. Output.
  • This output signal is shown as S2 in FIG.
  • the TS in Fig. 5 indicates a header including a time stamp. The receiving side does not use this timestamp to determine the system clock.
  • the receiving side ignores the packet generation timing on the transmitting side and stores the packet in the storage device. Then, the receiving side uses this time stamp to determine the timing of bucket generation at the transmitting side (to reproduce MPEG2-TS) when playing back the stored packets.
  • the counter and the counter that generates the PCR signal are synchronized because they use the same system clock.
  • the frequency of the system clock, the maximum speed of the extended TS packet to be transmitted, and the minimum size of the storage device 32 on the receiving side to be described later are determined in advance. . Then, the number of bits of this counter is set so that all the extended TS packets to be transmitted during the round of the count can be stored.
  • the size of the storage device is sufficiently large. Since it is secured, there is no problem that the receiving side cannot secure the playback time.
  • this counter when adding a time stamp, this counter is initialized at a predetermined timing according to the count value of the PCR signal, so that it is synchronized with the count value used to generate the PCR signal. I do.
  • the counter is initialized after a predetermined offset time and then time stamped. This allows the receiving side to use the counter for system clock reproduction by the PCR as the counter for MPEG2-TS reproduction.
  • the counter on the receiving side can be synchronized with this counter. In this case, it is desirable to match the number of bits of this counter with the number of bits of the counter for generating the PCR signal. By doing so, the carryover process on the receiving side can be simplified.
  • the supercapsulator 8 encapsulates each extended TS packet by one or more. Also, a header including information for identifying that the encapsulated information is an extended TS packet, the packet length of the extended TS packet in the capsule, the number of extended TS packets, and the capsule counter value is included in the output signal. In addition, it is output to the subsequent stage as a super pusher.
  • This super capsule is shown at S3 in FIG. Further, CH in FIG. 5 indicates a header. This capsule counter value is used to confirm the continuity of the super capsule on the receiving side. Then, every time the supercapsulator 8 outputs a supercapsule, the supercapsulator 8 counts up the capsule counter value.
  • the present embodiment does not limit the number of extended TS packets.
  • the information in the additional header in the supercapsule is intended to store the content of the encapsulated data and information for confirming the continuity at the receiving side, and is limited to the format described above. Not something.
  • the capsule counter value may be included as the extended TS bucket count value and information on the number of extended TS buckets may be included.
  • the bucket length and the number of extended TS buckets of the extended TS bucket may be the total data length encapsulated.
  • the super encapsulation machine 8 The super capsule is output to the storage buffer 15 together with the output of the super capsule.
  • the accumulation control to the accumulation buffer 15 is performed by the microcomputer 14 in a ring buffer system.
  • the microcomputer 14 manages the area for storing the super capsule of the storage buffer 15 and the header information of each super capsule.
  • the retransmission command detector 13 detects the retransmission command output by the receiver 12. Then, at the time of retransmission control of the supercap cell, the retransmission command detector 13 specifies the information (at least the power cell counter value in this example) for specifying the supercapsule included in the retransmission command and requiring retransmission, and instructs retransmission. Information to be output to the microcomputer 14.
  • the microcomputer 14 reads out the super capsule corresponding to the capsule counter value from the storage buffer 15. Thereafter, the microcomputer 14 controls the output to the UDPZIP packetizer 9 to retransmit the super capsule.
  • information indicating that the packet is a retransmission packet may be added to the header of the supercapsule and output.
  • the counting range of the capsule counter value can cover at least twice the maximum delay time (the delay from the transmission of the supercapsule to the reception of the retransmission command) in the communication network for the transmission speed of the supercapsule Desirably the number of bits.
  • the storage buffer size is at least enough to store the supercapsules in the counting range of the capsule count.
  • the format of the retransmission command may be determined in advance with the receiving side. In this embodiment, the format of the retransmission command is not particularly limited.
  • the UDPZIP packetizer 9 stores various super capsules in an IP datagram for transmission to an IP communication network, adds an IP bucket header, and outputs the packet as an IP packet.
  • This output signal is shown as S4 in FIG.
  • the IP of S4 indicates a header in a communication protocol such as an IP header. Since the IP packet header is well known on the Internet, its description is omitted. In this example, the IP bucket header is further stored in the UDP bucket, but this is not necessary. Further, another protocol, for example, an IP bucket header may be stored in a TCP bucket.
  • the Ethernet packetizer 10 is input to the Ethernet packetizer 10.
  • IP bucket is stored in the Ethernet data area.
  • the Ethernet packetizer 10 adds an Ethernet packet header and a checksum to the IP packet and outputs the packet as an Ethernet packet.
  • the Ethernet packet header and the checksum are well-known on the Internet and will not be described.
  • the transmitter 11 transmits an Ethernet packet to the Internet network.
  • various carriers operate communication networks in various formats, and the transmitter 11 and the receiver 12 correspond to these various formats. There are no particular restrictions on the form or specifications.
  • FIG. 6 is a diagram showing an Ethernet packet configuration in the present embodiment.
  • seven extended TS buckets each of which has a 4-byte header including a time stamp added to MPEG2—TSP, are encapsulated.
  • an 8-byte header including the identification value for identifying the extended TS packet, the capsule counter value, the extended TS packet size, and the number of the extended TS packets is added, and a 1352-byte super capsule is added.
  • an 8-byte UDP packet header is added to the super capsule to make a 1356-byte UDP packet.
  • a header of a 24 byte IP packet is added to the UDP packet to make the IP packet of 130 bytes.
  • a 14-byte Ethernet header and a 4-byte checksum are added to the IP packet to form a 1398-byte Ethernet packet.
  • the maximum transmission bucket unit, MTU In a communication network, the maximum transmission bucket unit, MTU, is often limited. When the size of the packet data to be transmitted exceeds the MTU, the packet is often divided on the communication network. On the Internet, such a process is called a fragment. It is difficult for the receiver to compensate for packet loss and jitter that occur after fragmentation. This is due to the loss of header information. Therefore, in the present embodiment, the number of extended TS packets in the super capsule is set to seven. This is to prevent the data size of the data area of the Ethernet packet from exceeding the MTU 1500 bytes in the Ethernet communication network.
  • the data size of MPEG 2—TSP is 18 8 bytes according to the specifications of the encoder. Is fixed. Therefore, the data size of the extended TS packet is 192 bytes.
  • the maximum number of extended transport buckets that can be stored in the supercapsule while satisfying the MTU 1500 byte in the Ethernet communication network is a maximum of seven.
  • the communication network is not limited to the Internet using Ethernet.
  • a USB may be used, or a wireless communication network such as a mobile phone may be used.
  • the MTU can correspond to a value corresponding to them.
  • the compression method is not limited to MPEG2.
  • M PEG 4 or another method may be used.
  • a microcomputer 29 controls each part of the content receiver.
  • the receiver 21 receives and outputs the Ethernet packet shown in FIG. 6 from a communication network such as the Internet network.
  • a communication network such as the Internet network.
  • various telecommunications carriers operate communication networks using various methods, and the receiver 21 and a transmitter 31 described later correspond to those methods.
  • the communication network is not limited to the Internet using Ethernet, and may use a USB or a wireless communication network such as a mobile phone.
  • the Ethernet packet processor 22 performs Ethernet protocol processing on the Ethernet packet corresponding to the Ethernet packet processor 22 and outputs a UD PZIP packet (this processing is shown in STEP 51 of FIG. 3. This output signal is shown as S5 in Fig. 5).
  • S5 in Fig. 5 means that jitter and bucket loss have occurred as a result of the received UDP IP packet passing through the Internet network.
  • VIDEO The packet containing 1 and DATA 1 has a larger delay than the regular delay. Packets containing VI DEO 3 and AUD I ⁇ 2 have a smaller delay than the regular delay. In addition, the packet including VI DE02 and AUD IO 1 becomes a bucket loss once and is retransmitted later.
  • the jitter and packet loss in the case of the In-net network will be described with reference to FIG.
  • all packets are transmitted with their steady delay, in which case no jitter or packet loss occurs.
  • packets are assigned different routes, packets cannot be transmitted during the valid time of the packet, the packet is deleted by the gateway, and the bucket is retransmitted. Packet loss occurs.
  • S5 the limited delay on the paper is clearly indicated by dare expressing the constant delay to zero. More specifically, the bucket including VIDEO 1 and DATA1 has a longer delay than the steady delay, and is described as being slower than S4.
  • Packets containing VIDEO 3 and AUD I O 2 are marked earlier (as if they were ahead) than S 4 because they have a smaller delay than the regular delay. It also indicates that packets containing VIDEO 2 and AUD IO 1 have been lost once and are retransmitted later.
  • the UDPZ IP packet processing unit 23 shown in FIG. 2 performs UD PZ IP protocol processing on the UDP / IP bucket and outputs a super capsule (this processing is shown in STEP 52 of FIG. 3. (See S6 in Figure 5).
  • Ethernet and UDP / IP protocol processing are well known on the Internet, and thus description thereof is omitted. Also, the processing of Ethernet packets and UDP packets is not limited to the contents described here, but depends on the type of receiving bucket and the specifications of the communication network. Further, other communication protocol processing may be performed.
  • each of these communication protocols information indicating the protocol processing method of the data body is included in each header.
  • the processing methods for various protocols are standardized, and the content receiver can be equipped with the processing methods in advance. Therefore, the content receiver analyzes the information indicating the protocol in the header, After the header is deleted, protocol processing of the data body can be performed.
  • the capsule processor 24 obtains the header of each supercapsule from each supercapsule shown in FIG. Further, the capsule processor 24 outputs information indicating the content of the configuration data included in the header to the microcomputer 29.
  • the information indicating the content of the data is information for identifying the format type of the encapsulated data (in this example, information for identifying the extended TS packet described above).
  • the information indicating the content of this data includes information indicating the bucket length and the number of extended TS buckets of the extended TS packet in the capsule.
  • the information indicating the packet length of the extended TS packet and the number of extended TS buckets may be the total data length encapsulated.
  • the microcomputer 29 interprets the information indicating the content of the given data and recognizes that the encapsulated data is an extended TS bucket (STEP 53 in FIG. 3).
  • the microcomputer 29 recognizes the size of each extended TS packet and secures a storage area of the storage device 32.
  • the microcomputer 29 also prepares the storage controller 28 for setting the storage bucket size and initial setting of the address when storing each extended TS packet (STEP 50 in FIG. 3). These preparations may be made when the first super capsule is input or when it is detected that the information indicating the data content has changed.
  • the capsule processor 24 monitors the capsule force center contained in the header to check the continuity (Step 54 in FIG. 3).
  • the capsule processor 24 detects a capsule count value in each supercapsule and checks a discontinuity point. If the capsule processor 24 detects a discontinuity point, it verifies the discontinuity based on the transition of the capsule counter (STEP 64 in Fig. 3).
  • the capsule processor 24 detects that the capsule counter value detected after the discontinuity point exceeds the capsule counter value immediately before the discontinuity point. Delete the super capsule until the discontinuity is resolved (STEP 65 in Fig. 3). .
  • the capsule processor 24 does not delete the super capsule corresponding to the discontinuity. And power The capsule processor 24 notifies the microcomputer 29 that the discontinuous point has been detected, and outputs the capsule counter value corresponding to the supercapsule that the capsule processor 24 could not receive to the microcomputer 29.
  • the capsule processor 24 generates a dummy super capsule having a dummy header composed of a dummy extended TS packet. Then, the capsule processor 24 inserts this dummy supercapsule into the time space corresponding to the supercapsule that the capsule processor 24 could not receive and outputs it to the subsequent stage (STEP 66 in FIG. 3). This is to simplify the retransmission packet insertion process at a later stage.
  • the microcomputer 29 receives the notification from the capsule processor 24 and outputs a retransmission command for instructing the super capsule to retransmit. At this time, the microcomputer 29 generates this retransmission command using the capsule counter value corresponding to the supercapsule that the capsule processor 24 could not receive (STEP 67 in FIG. 3). Sends a resend command to the sender via a communication network such as the Internet using Ethernet.
  • the capsule processor 24 can detect the supercapsule. Therefore, the capsule processor 24 removes the discontinuity from the object of the above-described verification of the discontinuity, and outputs it as it is to the subsequent stage. (STEP 54 in FIG. 3).
  • the microcomputer 29 does not have to control the retransmission command transmission immediately after receiving the discontinuity notification from the capsule processor 24.
  • the microcomputer 29 instructs the capsule processor 24 to wait for reception of a super capsule that could not be detected, and controls the retransmission command transmission when the corresponding super capsule has not been received for a predetermined period of time. May be done. If reception is possible within a predetermined time after instructing reception standby, the capsule processor 24 adds information indicating a retransmission packet within a predetermined header and outputs it to the subsequent stage. This is because the packet is processed in the subsequent stage in the same manner as the retransmission packet.
  • the waiting time is shorter than the rounding time of the capsule counter value and longer than the maximum delay time of packet arrival in the communication network.
  • the capsule processor 24 separates and outputs the extended TS packet encapsulated under the control of the microcomputer 29.
  • the header containing the MPEG2—TSP and the time stamp are included. Output separately.
  • Microcomputer 29 checks whether MPEG2—TSP is scrambled (Step 55 in FIG. 3).
  • the MPEG 2 — TSP header has information about whether or not it is scrambled outside the range to be scrambled. Therefore, the microcomputer 29 can take out the MPE G2-TSP once, confirm the information, and perform the descrambling process on the scrambled range.
  • the receiving side and the transmitting side decide which method to use in advance, or the receiving side confirms and recognizes the table information to be received. is there.
  • the descrambler 25 descrambles the MP EG2—TSP input to the descrambler 25 by a method corresponding to scrambling on the transmission side, and outputs it to the subsequent stage.
  • the header including the time stamp is delayed by the processing time of the descrambler 25 in the time stamp buffer 26, synchronized with the MPEG-2—TSP in time, and then output to the subsequent stage (STEP in FIG. 3). 56).
  • the microcomputer 29 also checks whether the packet is a retransmission packet (STEP 68 in Fig. 3).
  • the retransmission bucket has information indicating the retransmission bucket in the header. Therefore, the microcomputer 29 checks the packet to see if it is a retransmission packet.
  • information indicating that the packet is a retransmission bucket, and a header to which a capsulation counter value is further added are generated and output to the time stamp buffer 126 (FIG. 3, STEP 69).
  • the extended TS reproducer 27 combines the MPEG2-TS and the header to reproduce and output the extended TS packet. This process is shown in STEP 57 of FIG. This output signal is shown in S7 of FIG.
  • the storage controller 28 checks whether or not the extended TS packet is reacquired due to a delay or a source in the communication network based on the header information (STEP 58 in FIG. 3). If the packet is not a retransmission packet, control the microcomputer 29. The extended TS packets are sequentially written to the managed area on the storage device 32 (STEP 59 in FIG. 3). If the packet is a retransmission bucket, a dummy one extended TS packet and dummy super capsule are generated in STEP 66. Then, the re-acquired extended TS packet is overwritten in the corresponding dummy extended TS bucket already stored (STEP 60 in FIG. 3).
  • the retransmitted extended TS packet contains the capsule counter value.
  • the microcomputer 29 manages the capsule counter value and the address of the storage device 32. Based on these facts, this overwrite control compensates for continuity in the storage device 32 by storing the retransmitted extended TS packets in the original storage area (the area where dummy extended TS packets are temporarily stored and secured). (S8 in Fig. 5).
  • the retransmitted extended TS packets of VIDEO2 and AUD I ⁇ 1 are stored in their original locations.
  • the storage device 32 since the storage device 32 stores the arrival time and the transmission time on the transmission side without referring to the time, each extended TS packet can be efficiently stored.
  • the storage device 32 may be any storage medium such as an HDD or a DVD, or may be a semiconductor memory. Further, if the retransmission control is simplified and the control is performed only for the jitter compensation, the capacity required for the storage device 32 is also reduced to a range where all the extended TS packets received during the time when the counter described later makes one round can be stored.
  • the microcomputer 29 confirms that no extended TS packet is stored. For example, if this is a normal MPEG2-TSP, check whether it is scrambled in the same way (STEP 61 in Fig. 3). If it is scrambled, it is descrambled by the descrambler 25 (STEP 62 in FIG. 3). Then, the extended TS player 27 generates and adds a header including a time stamp to the extended TS packet, outputs the extended TS packet (STEP 63 in FIG. 3), and stores it in the storage device 32 similarly. In this case as well, the subsequent reproduction processing can be shared. However, in this case, jitter compensation and packet loss compensation are the same as in the conventional example.
  • the reproduction controller 33 has a counter for counting the system clock.
  • the playback controller 33 sets the count value of the counter to the PCR signal output from the TS decoder 34 so that the result becomes equal. Controls the frequency of the system clock. That is, the system clock can be reproduced using the existing MPEG transport system as it is. Therefore, at the time of playback, the specifications of the MPEG transport system can be easily satisfied using existing technology. Further, under the control of the microcomputer 29, the reproduction controller 33 sequentially reads out the extended TS packets stored in the storage device 32 in synchronization with this system clock (STEP 71 in FIG. 4).
  • the playback control unit 33 removes the header including the time stamp at the timing when the individual time stamps and the count value of the above-mentioned counter have a predetermined offset value (STEP 72 in FIG. 4). . Then, the reproduction controller 33 outputs each MPEG2-TSP to the subsequent stage. This process is shown in STEP 73 of FIG. This output signal is shown in S9 in FIG.
  • the MPEG2-TS on the transmitting side has been reproduced, and the jitter generated in the communication network has been compensated.
  • the transmission side uses the PCR signal. Therefore, the reproduction controller 33 can compare the count value of this counter obtained from the PCR signal with the time stamp.
  • the TS decoder 34 converts the MPEG2_TSP into a form that the AV decoder 35 can perform AV decoding and outputs.
  • the AV decoder 35 performs AV decoding on the data input to the AV decoder 35 and outputs the data. If the time stamp does not match the system clock counter value in STEP 72, the reproduction controller 33 verifies the difference (STEP 75 in FIG. 4). If the difference is within a range in which jitter can be compensated for in a buffer (not shown) inside the reproduction controller 33, the extended TS packet is made to wait on the buffer. If the difference exceeds the range in which jitter can be compensated by the buffer inside the playback controller, control is performed to discard the corresponding extended TS packet (STEP 76 in Fig. 4).
  • FIG. 6 shows an example in which the number of extended TS packets in a supercapsule receives seven Ethernet packets (1398 bytes).
  • the data area has a 1356 byte UDP / IP bucket, The data area has a 1352 byte super capsule.
  • the supercapsule encapsulates seven extended TS packets with a 4-byte header including a time stamp added to MPEG2-TSP.
  • the super capsule has an 8-byte header including an identification value for identifying an extended TS packet, a capsule count value, an extended TS packet size, and the number of extended TS packets.
  • the maximum transmission bucket unit, MTU is often limited. If the packet data size exceeds the MTU, the packet is often divided on the communication network.
  • the number of extended TS packets in the super capsule is set to seven. This is to prevent the data size of the data area of the Ethernet packet from exceeding the MTU 1500 byte in the Ethernet communication network.
  • the data size of MPEG2-TSP is fixed at 188 bytes according to the specifications of the encoder. Therefore, the data size of the extended TS packet is 192 bytes, and the maximum number of extended transport buckets that can be stored in a super capsule while satisfying the MTU 150 bytes in the Ethernet communication network is a maximum of seven.
  • the time stamp for playback included in each extended TS packet is used to accurately compensate for jitter generated in the communication network with the accuracy of the system clock. Further, as described above, the compensation is performed efficiently and reliably by the joint control of the jitter compensation for controlling the decoding timing of the content transmitter and the content receiver and the packet loss compensation for the retransmission control.
  • the communication network is not limited to the Internet using Ethernet.
  • a USB or a wireless communication network such as a mobile phone may be used.
  • the compression method is not limited to MPEG2.
  • MP EG 4 or another method may be used.
  • the playback controller 33 outputs MPEG2-TSP from the content receiver to the AV decoder connected to the bus.
  • the reproduction controller 33 is connected to an external output interface such as an IEEE 1394 interface (not shown).
  • MPEG2-TSP is stored in an isochronous bucket defined by the interface.
  • the TS decoder 134 may be connected to an external output interface such as an IEEE1394 interface (not shown), and the output of the TS decoder 34 may be transmitted to an external AV decoder.
  • the external output interface stores and outputs MP EG2-TSP in an isochronous bucket defined by the interface standard.
  • FIG. 12 is a diagram illustrating a configuration of a content transmitter according to the second embodiment.
  • FIG. 13 is a diagram showing the configuration of the IEEE 1394 interface according to the second embodiment.
  • FIG. 14 is a diagram showing the transition of the bucket configuration in the content receiver according to the second embodiment.
  • FIGS. 15 and 16 are diagrams showing the configuration of the packet transmitted by the IEEE 1394 interface according to the second embodiment.
  • the configuration and operation up to the storage of the bucket received from the Internet network by the storage device 32 are the same as those of the first embodiment, and thus the description thereof is omitted.
  • the read controller 36 reads the extended TS bucket stored in the storage device 32 in accordance with an instruction from the microcomputer 29 in synchronization with a clock of a predetermined frequency generated by the extended TS bucket read clock generator 37. In this case, a predetermined time interval is inserted between the extended TS buckets as shown by S10 in FIG. 14 and output (S10 in FIG. 14).
  • the interval is set according to the clock frequency of the clock regenerator 37 so that the bit rate of the extended TS bucket after the insertion of the time interval is equal to or greater than the bit rate of the content transmitter when the extended TS packet is transmitted.
  • the IE EE 1394 interface 38 conforms to the IEEE 1394 standard.
  • the IEEE 1394 interface 38 outputs the extended TS packet input to the IEEE 1394 interface 38 in the asynchronous transfer mode (S11 in FIG. 14).
  • S11 ISO is a header added by the IEEE 1394 interface.
  • the transmission signal between the read controller 36 and the IEEE 1394 interface 38 is composed of a data signal, a clock signal, a packet state signal, and a data enable signal as in the case of MPEG2-TS.
  • the extended TS bucket information is set in the IEEE 1394 interface 38 by the microcomputer. This will be explained.
  • FIG. 13 is a diagram showing the configuration of the IEEE 1394 interface 38.
  • the stream of the extended TS packet is input to the MPEG2 interface 41.
  • the DTCP encryption circuit 42 encrypts the extended TS packet output from the MPEG2 interface 41 for the purpose of copyright protection in accordance with the DTCP (Digital Transcription Control Protocol) standard. And output.
  • the header adding circuit 43 adds a header to the packet subjected to the DTCP encryption and outputs the packet. This header is a header necessary for isochronous transfer.
  • Information specifying the format of the extended TS packet is input to the bucket format information adding circuit 44 from the microcomputer via the host interface 46. Then, the packet format information adding circuit 44 performs a process of writing, at a predetermined position in the header, information for identifying the data format of the bucket to be asynchronously transferred from the extended TS bucket.
  • Information specifying the data size of the extended TS bucket is input from the microcomputer to the bucket data size adding circuit 45 via the host interface 46. Then, the packet data size information adding circuit 45 calculates and determines the data size of the isochronous packet based on the information. Alternatively, the packet data size information addition circuit 45 receives information on the size of the asynchronous packet for storing the extended TS bucket from the microcomputer via the host interface 46. Is done. Then, the packet data size information adding circuit 45 performs a process of writing information on the data size of the packet to be transmitted asynchronously to a predetermined position of the header.
  • FIG. 15 is a diagram illustrating an example in which only an isochronous header is added to an extended TS packet. In this case, write only the packet data size in the data length area shown in Fig. 15. If the data size of the extended TS packet is 192 bytes, the data size is 576 bytes, which is 3 times 192, and 588 bytes, which is the sum of one asynchronous header and 12 bytes of data CRC. Write to the 15-day long field.
  • FIG. 16 is a diagram illustrating an example in which the extended TS packet includes an isochronous header and a common header.
  • the packet data size is written in the data length area of the isochronous header in FIG. 16 and information for identifying the extended TS packet is written in the format area of the common header. If the data size of the extended TS packet is 192 bytes, the number obtained by adding 4 and 192 in the Reserved area is tripled to 588 bytes, and the data size of the synchronous header, common header, and common header is 588 bytes.
  • the Reserved area is an area for future expansion.
  • the information for identifying the extended TS packet is the data that is determined in advance as the content transmitting side within the range excluding the currently operating data, if any.
  • FIGS. 15 and 16 show examples of asynchronous packets in which three extended TS packets are stored, but the number of packets is not limited to three.
  • the number of buckets can be four, two, or one.
  • the data size of the extended TS packet is an example of 192 bytes, but is not particularly limited.
  • the data size of the extended TS packet may be 196 bytes.
  • An IE EE 1394 isochronous bucket transmission circuit 47 shown in FIG. 13 implements a data link layer and a physical layer protocol in accordance with the IE EE 1394 standard. It is composed of circuits.
  • the IEEE 1394 isochronous packet transmission circuit 47 transmits the packet to which the header 1 added to the IEEE 1394 isochronous packet transmission circuit 47 is added. Send to the bus.
  • a TS decoder 1 (not shown) and an AV decoder (not shown) are separately connected on the 1394 bus. The effects described can be achieved.
  • the content receiver of the present invention it is possible to prevent a packet loss occurring in a communication network from being compensated on the receiving side and to prevent a packet loss from occurring when a packet loss occurs. It is useful for digital television broadcast receivers, personal computers, mobile phones, portable information terminals and mobile phone adapters.
  • the data can be efficiently stored in the storage device on the receiving side ignoring the arrival time when storing the data. Also, at the time of reproduction, reproduction can be performed with the accuracy required by the decoder using a time stamp indicating the time to output to the decoder. This prevents decoding errors when the jitter compensation accuracy is insufficient for decoding, and is useful for digital television broadcast receivers, personal computers, mobile phones, personal digital assistants, and mobile phone adapters. It is.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

送信側は再生時刻情報を個々のトランスポートパケットに付加した拡張トランスポートパケットをカプセル化しカプセルカウンタ情報を付加して送信する。受信側は蓄積手段を備えており、パケットロスの場合には前記カプセルカウンタ情報を含む再送要求を送信側に送出する。また、受信側は再送データを受信後に本来の蓄積領域に上書する。また、受信側は再生の際は再生時刻情報を参照しジッター補償した後デコードする。このように、インターネットのような通信網において、パケットロスやジッターを送信側と受信側とで補償して、受信側でのデコードエラーを防止する。

Description

明細書
コンテンツ受信器およびコンテンツ送信器 技術分野
本発明は、 デジタルテレビジョン放送受信機、 パーソナルコンピュータ、 携帯 電話機、 携帯情報端末機および携帯電話ァダブターに関する。 背景技術
近年、 通信網を介して映像や音声のコンテンツを送受信するストリ一ミングな どの機能をもつ送信器および受信器が、 市場において普及してきている。
以下に従来のコンテンツ送信器について説明する。 図 7は従来のコンテンツ送 信器の構成を示す図である。 図 10は従来のコンテンツ送信器と従来のコンテン ッ受信器におけるパケット構成の推移を示す図である。 図 1 1は従来のパケット の構成を示す図である。
図 7に示すビデオエンコーダー 51は、 映像信号を所定の圧縮方式でェンコ一 ドして、 後段に出力する。 図 7には MP EG 2方式による構成を示している。 ビ デォエンコーダー 51からの出力は MPEG2トランスポートストリームバケツ ト （以下 MP EG 2— TS Pと略する） で構成される。
システムクロック生成器 54は、 27 MHzのクロックを生成する。 ビデオェ ンコーダ一 51が映像信号をェンコ一ドする際に使用するシステムクロックは、 この 27 MHzのクロックである。
オーディオエンコーダ一 52は、 音声信号を、 ビデオエンコーダ一 51と同様 の圧縮方式でエンコードし、 MPEG 2—TS Pを後段に出力する。 デ一タエン コーダ一 53は、 データ放送や EPGなどのデ一夕をビデオエンコーダ一 51と 同様の圧縮方式でエンコードし、 MP EG 2 _TS Pを後段に出力する。
ストリーム多重化器 55は、 上述の 3種の MP EG 2— TSPを時間軸上に多 重化する。 またストリーム多重化器 55は、 受信側においてシステムクロックを 再生するための PC R信号を、 システムクロックをカウントした計数値を 50m S程の周期で定期的に用いて、 生成する。 そしてストリーム多重化器 55は、 P 信号を1^?£ 2_丁3?化した後に、 上述の多重化された信号に更に多重 して、 MP EG 2トランスポートストリーム （以下 MPEG 2— TSと略す） と して後段に出力する。 この出力信号を図 10の S 1 1に示す。
図 10は時間軸上におけるパケットの多重の推移を示した図である。 図 10の 横軸は時間である。 しかし、 図 10において、 各処理における定常的な遅延につ いては無視しており図示していない。 31 1の 10£〇 1、 V I DE02、 V I DEO 3, AUD I 01、 AUD I 02、 DAT A 1はストリーム多重化器 5 5により多重化されたパケットである。 また、 31 1の 10£〇1、 V I DE 〇2、 V IDE03はビデォェンコードされたMPEG2—TSPでぁる。また、 S 1 1の AUD I 01、 AUD I 02はオーディオエンコードされた MP EG2 一 TSPである。 また、 S 11の DATA 1はデータエンコードされた MPEG 2— TSPである。 PC R信号については MP EG2システムにおいて周知の内 容なので説明は省略する。
スクランブラ 56は、 MP EG 2— TSを所定の喑号方式で暗号化して出力す る。 ここに示す例は MULT I 2方式の例である。
RTPパケット化器 58は個々の MPEG 2— TS Pを一つ以上でカプセル化 する。 また、 RTPパケット化器 58は、 送受信器 61が通信網から提供される 基準時刻情報を元に再生するパスクロックをカウントするカウン夕を有している。 なお、 送受信器 61については後述する。 そして RTPパケット化器 58は、 そ のカウンタ値であるタイムスタンプと、 カプセル化された情報が MP EG 2— T S Pであることを識別する情報とを含んだへッダーを出力信号に付加して、 後段 に出力する。 この出力信号を図 10の S 12に示す。 また、 312の 丁？はへ ッダ一である。 このタイムスタンプは、 受信側でパケット到着時にバスクロック を用いてジッターを補正するときに使用する。
UDP/I Pパケット化器 59は、 個々の RTPパケットを I P通信網に送信 するために I Pデータグラム内に格納する。 そして、 UDP/I Pパケット化器 59はこの格納した個々の R TPバケツトに I Pバケツトヘッダ一を付加して I Pパケットとして出力する。 この出力信号を図 10の S 13に示す。 また、 S 1 3の I Pは I Pヘッダーなどの通信プロトコルにおけるヘッダ一である。 I Pパ ケットヘッダーについてはインターネットで周知の内容なので説明は省略する。 イーサネットパケット化器 60は、 I Pバケツトをイーサネットのデータ領域 に格納し、 ィーサネットパケットへッダ一とチェックサムを付加してィ一サネッ トパケットとして出力する。 イーサネットバケツトヘッダ一とチェックサムにつ いてはインターネットで周知の内容なので説明は省略する。
送受信器 61はイーサネットパケットをインターネット網に送信する。 そして 送受信器 61は前述した基準時刻情報などを受信する。
次に、 前述した送信パケット構成について説明する。 図 1 1は従来のパケット 構成を示す図である。 図 1 1では MPEG2—TSPを10個カプセル化してい る。 そして、 MP EG 2—TSPを識別するための情報とパケット到着時に使用 するタイムスタンプを含む 8バイトのヘッダ一を付加している。 そして、 189 2バイトの RTPパケット化している。 そして、 RTPパケットに 8バイトの U DPバケツトヘッダ一を付加して 1900バイトの UDPパケットとしている。 そして、 UDPバケツトに 24バイトの I Pバケツトヘッダ一を付加して 192 4バイトの I Pパケット化している。 そして、 I Pパケットに 14バイトのィ一 サネットヘッダーと 4バイトのチェックサムを付加して 1942バイトのィ一サ ネットバケツト化している。
通信網においては、 最大伝播バケツト単位である MTUを制限している場合が 多い。 そして、 送出するパケットデータサイズが MTUをオーバーしている場合 は、 通信網においてパケットを分割する場合が多い。 インターネットではこのよ うな処理をフラグメントと言う。
この従来例では、イーサネット通信網における MTUは 1500バイトである。 一方、 ィ一サネットバケツトのデータ領域のデータサイズは MTUをオーバ一し ているため通信網でのフラグメントを防止できない。 したがって、 ヘッダー情報 を喪失したパケットが発生する場合がある。 このため、 フラグメント後に発生し たバケツトロスゃジッターの補償を受信側で行うことは困難である。
次に受信側の従来例を説明する。 図 8はコンテンツ受信器の従来例の構成を示 す図である。 図 9はパケットを受信してデコードするまでの動作を示したフロ一 チヤ一卜である。 受信器 71は、 インターネット網などの通信網からイーサネットバケツトを受 信し、後段に出力する。 このィ一サネットバケツトは図 11で示したものである。 イーサネットパケット処理器 72は、 イーサネットパケット処理器 72当てのィ 一サネットパケットにイーサネットのプロトコル処理を行い、 UDP/ I Pパケ ットを後段に出力する。 この処理を図 9の STEP 91に示す。 また、 この出力 信号を図 10の S 14に示す。
図 10の S 14は、 インターネット網を介して受信 UDP/ I Pバケツトの送 受信をした結果、 受信 UDPZI Pパケットにジッターとパケットロスが発生し ていることを表している。 つまり V I DEOlと DATA1を含むバケツトには 定常的な遅延より大きな遅延が生じている。 V I DE03と AUD I 02を含む パケットには定常的な遅延より小さい遅延が生じている。
ここで、 図 10を用いて、 インターネットのジッタ一とパケットロスについて 説明する。 インタ一ネット網における送信側と受信側の間には、 定常的な遅延が 存在する。 全てのパケットがその定常的な遅延を持って伝達されるのが理想的で ある。 そして、 この場合にはジッターやパケットロスは発生しない。 しかし、 実 際のインターネット網では、 パケットが異なるルートを割り当てられる、 バケツ トの有効時間中にパケットを伝達できない為にパケットがゲートウェイで削除さ れる、 パケットが再送される、 等が生じるので、 ジッターやパケットロスが発生 する。 S 14の記載については、 定常的な遅延をあえてゼロに表現することで、 限られた紙面上ジッターを分かりやすく記している。 具体的には、 V I DEO l と DATA 1を含むバケツトは定常的な遅延より大きな遅延が生じているため、 S 13に比べ遅く （遅れているように） 記している。 VI DEO 3と AUD I O 2を含むバケツトは定常的な遅延より小さい遅延が生じているため S 13に比べ 早く （進んでいるように） 記している。
また V I DE02と AUD I O 1を含むバケツ卜はパケットロスとなっている。 図 8に示す UDPZI Pパケット処理部 73は、 UDP/I Pパケットに UDP I Pのプロトコル処理を行い、 RTPパケットを出力する。 この処理を図 9の STEP 92に示す。 また、 この出力信号を図 10の S 15に示す。
以上のイーサネットおよび UDP/ I Pのプロトコル処理はインターネットで 周知であるので説明は省略する。
これらの通信プロトコルは、 それぞれのヘッダーにデータ本体のプロトコル処 理方法を示す情報を含んでいる。 各種プロトコルの処理方法については規格化さ れており、 予めコンテンツ受信器はその処理方法を備える事ができる。 従って、 コンテンツ受信器は、 ヘッダ一内のプロトコルを示す情報を解析する事により、 ヘッダーを削除した後のデータ本体のプロトコル処理を行うことができる。
RTPバケツト処理器 79は、 図 11で示した個々の RTPバケツトから個々 の RTPパケットのヘッダ一を取得する。 また、 RTPパケット処理器 79はへ ッダー内に含まれている構成デ一夕の内容を示す情報を取得する。 このデ一夕の 内容を示す情報は、 格納されているデータのフォーマットタイプを識別するため の情報である。 なお、 ここでは、 この情報は前述した MP EG 2—TS Pである ことを識別するための情報である。
また、 RTPバケツト処理器 79は、 受信器 71において基準時刻情報を用い て再生したバスクロックをカウントするカウンタを備えている。 RTPバケツト 処理器 79は、 このバスクロックをカウントし、 カウントした値がヘッダー内の タイムスタンプと一致した場合には、 ヘッダーを取り外して MP EG 2— TS P を後段に出力する （図 9の STEP 93)。そして、 RTPパケット処理器 79は、 MP EG2— TS Pがスクランブルされているかを確認する（図 9の STEP 9 4)。 MPEG 2—TS Pのヘッダーは MPEG 2 _TS Pがスクランブルされて いるかどうかの情報をスクランブルされる範囲外に持っている。 したがって、 一 旦 MPEG2— TSPを取り出した後にその情報を確認してデスクランプル処理 を行うことができる。 どの方式を用いるかを受信側と送信側とで予め決めておく こと、 または、 受信するテーブル情報を受信側で確認して認識すること、 これら のことで任意の方式への対応が可能である。
デスクランブラ 74は、 MPEG 2— TS Pを送信側で定めたスクランブルの 方式に対応した方式でデスクランブルして、 出力する。 この処理を図 9の STE P 96に示す。 この出力信号を図 10の S 17に示す。
TSデコーダー 77は1\1?£02—丁3?を八¥デコーダー78が A Vデコー ドできる形態に直して出力する（図 9の STEP 97)。 A Vデコーダ一 78は、 AVデコーダ一 78に入力されたデ一夕を AVデコードして出力する （図 9の S TEP 98)。図 9の STEP 93では、バスクロックをカウントした値とヘッダ 一内のタイムスタンプが一致しなかった場合に、 TSデコーダ一 77はその差分 を検証する （図 9の STEP 95) 。 その差分が再生制御機 （図示せず） 内部の バッファーで補償できる範囲であれば、 TSデコーダ一 77は拡張 TSパケット をこのバッファ一上で待機させる。 その差分がこのバッファーで補償できる範囲 を超える場合は、 TSデコーダー 77は該当 TSパケットを廃棄するよう制御す る （図 9の STEP 96)。
しかしながら上記のような構成では、 通信網において発生するパケットロスを 受信側でリアルタイムに補償することができず、 パケットロスが発生した場合は デコ一ドエラ一となってしまう。 デコードと無関係のバスクロックのカウントにより生成される。 また、 そのバス クロックを生成するために使用する基準時刻情報が、 デコードを行なう際に要求 されるジッター精度に対し充分な精度が無い。 また、 この基準時刻情報が通信網 のジッターの影響を受ける。 これらの理由により、 受信側でデコードを行なう際 のジッター補償精度が不十分となりデコードエラ一となる場合がある。
また、 通信パケットのデータ領域のデータサイズが通信網における MTUをォ 一パーし、 通信網でのフラグメントを防止できないため、 ヘッダー情報を喪失す る。 これによりフラグメント後に発生したパケットロスやジッターの捕償を受信 側で行うことは困難である 発明の開示
本発明は、 圧縮されたトランスポートバケツトから構成されるストリームによ り形成されるコンテンツを送信側から受信し再生する受信器において、 コンテン ッを受信した後に蓄積する蓄積手段と、 蓄積手段に蓄積した前記コンテンツを再 生する再生手段とを備えている。 また、 コンテンツを形成する個々のトランスポ ートバケツトがトランスポートバケツ卜のシステムクロックを用いて生成された 再生時刻指示情報を有する拡張トランスポートパケットであれば、 再生手段は蓄 積された個々の拡張トランスポートバケツトを再生時刻指示情報から求める時刻 で再生する。
また本発明は、 圧縮されたトランスポートパケットから構成されるストリーム により形成されるコンテンツを送信する送信器において、 コンテンツを送信する 送信手段と、 トランスポートパケットのシステムクロックを用いて受信側が蓄積 手段から再生する際の時刻を指示する再生時刻指示情報を生成する再生時刻指示 情報生成手段とを備えている。 送信手段は送信する個々のトランスポートパケッ トに再生時刻指示情報を付加した拡張トランスポ一トバケツトを送信す。 図面の簡単な説明
図 1は本発明の実施例 1によるコンテンツ送信器のプロック図
図 2は本発明の実施例 1によるコンテンツ受信器のブロック図
図 3は本発明の実施例 1によるコンテンツ受信器での第一の動作フローチヤ一 トを示す図
図 4は本発明の実施例 1によるコンテンツ受信器での第二の動作フローチヤ一 トを示す図
図 5は本発明の実施例 1によるバケツト構成の推移を示す図
図 6は本発明の実施例 1によるイーサネットパケット構成を示す図
図 7は従来のコンテンツ送信器のブロック図
図 8は従来のコンテンツ受信器のブロック図
図 9は従来のコンテンツ受信器の動作フローチャートを示す図
図 1 0は従来のパケット構成の推移を示す図
図 1 1は従来のパケット構成を示す図
図 1 2は本発明の実施例 2によるコンテンッ受信器のプロック図
図 1 3は本発明の実施例 2によるコンテンツ受信器の I E E E 1 3 9 4インタ —フェースのブロック図
図 1 4は本発明の実施例 2によるパケット構成推移を示す図
図 1 5は本発明の実施例 2による第一の I E E E 1 3 9 4バケツト構成を示す 図 16は本発明の実施例 2による第二の I EEE 1394パケット構成を示す
発明を実施するための最良の形態
(実施例 1)
図 1は実施例 1によるコンテンッ送信器の構成を示す図である。 図 5は実施例 1によるコンテンツ送信器と、 コンテンツ受信器におけるバケツト構成の推移を 示す図である。 図 6は実施例 1によるパケットの構成を示す図である。
図 1において、 マイコン 14はコンテンツ送信器の各部の制御を行う。 ビデオ エンコーダー 1は、 映像信号を所定の圧縮方式でエンコードして、 後段に出力す る。 本実施例では MP EG 2方式を例として示しており、 エンコーダー 1が出力 する出力信号は MP EG 2—TS Pで構成される。 システムクロック生成器 4は 27 MHzのクロックを生成する。 ビデオエンコーダ一 1が映像信号をェンコ一 ドする際に使用するシステムクロックはこの 27 MHzのクロックである。 ォー ディォエンコーダ一 2は、 音声信号をビデオエンコーダ一 1と同様の圧縮方式で エンコードして、 MPEG2— TSPを後段に出力する。
デー夕エンコーダ一 3は、 データ放送や E P Gなどのデータをビデオェンコ一 ダ一 1と同様の圧縮方式でエンコードして、 MPEG 2—TS Pを後段に出力す る。
ストリーム多重化器 4は、 上述の 3種の MP EG 2—TS Pを時間軸上に多重 化する。 また、 ストリーム多重化器 4は受信側においてシステムクロックを再生 するための P CR信号を、 システムクロックをカウントするカウン夕を用いて生 成する。
なお、 MPEGトランスポートシステムにおいて、 PCR信号は 50mS程の 周期で生成される。 そしてストリーム多重化器 4は PC R信号を MP EG 2— T SP化した後に、 上述の多重化された信号に更に多重して、 MPEG2—TSと して出力する。 この出力信号を図 5の S 1に示す。
図 5は時間軸上におけるバケツトの多重の推移を示した図である。 図 5の横軸 は時間である。 しかし、 図 5において、 各処理における定常的な遅延については 無視しており図示していない。 S 5の V I DE〇 1、 V I DEO 2, V I DEO 3、 AUD I〇 1、 AUD I O 2、 DAT A 1はストリーム多重化器 5により多 重化されたパケットである。 また、 31の¥10£〇1、 V I DEO 2、 V I D E〇 3はビデオエンコードされた MP EG 2— TSPである。 また、 S 1の AU D I〇1、 AUD I 02はオーディオエンコードされた MPEG2— TSPであ る。 また、 S 1の DATA1はデータエンコードされた MPEG2— TSPであ る。 P CR信号については MP E G 2システムにおいて周知の内容なので説明は 省略する。
スクランブラ 6は、 MPEG2— TSを所定の喑号方式で暗号化して出力する。 ここに示す例は MULT I 2方式の例である。 タイムスタンプ付加器 7は、 シス テムクロック生成器 4が出力するシステムクロックをカウントするカウンタを有 している。 そして、 タイムスタンプ付加器 7はそのカウント値をタイムスタンプ としてヘッダーに含め、 このヘッダーを個々の MP EG 2— TS (この例ではス クランブルされている） に付加して、 拡張 TSパケットとして後段に出力する。 この出力信号を図 5の S 2に示す。 また、 図 5の TSはタイムスタンプを含んだ ヘッダーを示している。 受信側では、 このタイムスタンプを、 システムクロック を求めるためには使用しない。 受信側は、 送信側におけるパケットの生成夕イミ ングを無視して、 蓄積デバイスにパケットを蓄積する。 そして、 受信側は、 蓄積 したパケットを再生する際に、 送信側でのバケツトの生成タイミングを求めるた め （MPEG2—TSを再生するため） に、 このタイムスタンプを使用する。 なお、 このカウンタと PCR信号を生成するカウン夕とは、 同じシステムクロ ックを用いているため同期が取れている。
一方、このカウン夕と受信側のカウン夕とで同期が取れない場合が考えられる。 したがって、 受信側で再生する時刻を確保する為に、 システムクロックの周波数 と、 送信する拡張 TSパケットの最大速度と、 後述する受信側の蓄積デバイス 3 2の最小限のサイズとを予め決めておく。 そして、 カウン夕が一巡する時間に送 信する全拡張 TSパケットを蓄積できるようにこのカウンタのビット数を設定す る。 なお、 本実施例のように、 受信側において一旦コンテンツを形成する拡張 T Sバケツトを全て蓄積した後に再生する例では、 十分に蓄積デバイスのサイズは 確保されることになるので、 受信側で再生する時刻を確保できないという問題は 生じない。
またタイムスタンプを付加する際に、 P C R信号の生成に用いたカウント値と 時間的に同期させるように、 このカウンタを P C R信号のカウント値に応じて所 定のタイミングで初期化した後にタイムスタンプ化する。 または、 このカウン夕 を所定のオフセット時間後に初期化した後にタイムスタンプィ匕する。 こうするこ とで、 受信側において P C Rによるシステムクロック再生用カウン夕を MP E G 2— T S再生用のカウン夕として用いることもできる。また受信側のカウン夕と、 このカウンタとの同期をとる事もできる。 この場合、 このカウンタのビット数を、 P C R信号を生成するためのカウン夕のビット数と合わせておく事が望ましい。 こうすることで受信側におけるキャリーオーバーの処理を簡略化することができ るからである。
スーパ一カプセル化器 8は、 個々の拡張 T Sパケットを一つ以上でカプセル化 する。 また、 カプセル化された情報が拡張 T Sパケットであることを識別する情 報と、 カプセル内の拡張 T Sパケットのパケット長と、 拡張 T Sパケット数と、 カプセルカウンタ値とを含むへッダーを出力信号に付加して、 スーパ一力プセル として後段に出力する。 このスーパ一カプセルを図 5の S 3に示す。 また、 図 5 の C Hはヘッダーを示している。 このカプセルカウンタ値は、 受信側でスーパ一 カプセルの連続性を確認するためのものである。 そして、 スーパーカプセル化器 8がスーパーカプセルを出力するたびにスーパーカプセル化器 8は、 このカプセ ルカウンタ値をカウントアップさせる。
なお、 図 5ではカプセル化される拡張 T Sパケットは 2つであるが、 これは一 例を示したに過ぎず、 本実施例において拡張 T Sパケッ卜の数を限定するもので はない。 また、 スーパーカプセルでの付加ヘッダ一内の情報は、 カプセル化され たデータの内容と受信側で連続性を確認するための情報を格納することを目的と しており、 前述した形式に限定するものではない。 例えば、 カプセルカウンタ値 を拡張 T Sバケツトの計数値として拡張 T Sバケツト数の情報も含めてもよい。 または、 拡張 T Sバケツトのバケツト長および拡張 T Sバケツト数はカプセル化 された総デ一タ長であっても良い。 また、 スーパーカプセル化機 8は後段へのス ーパ一カプセルの出力とともに蓄積バッファー 1 5にもスーパーカプセルを出力 する。
蓄積パッファー 1 5への蓄積制御は、 マイコン 1 4によりリングバッファー方 式で行われる。 マイコン 1 4は蓄積バッファ一 1 5のスーパ一カプセルを記憶す る領域と個々のスーパーカプセルのヘッダ一情報を管理する。 再送コマンド検出 器 1 3は受信器 1 2が出力する再送コマンドを検出する。 そして、 スーパーカブ セルの再送制御時には、 再送コマンド検出器 1 3は、 再送コマンド内に含まれる 再送が必要なスーパーカプセルを指定するための情報 （この例では少なくとも力 プセルカウンタ値） と再送を指示する情報をマイコン 1 4に出力する。
マイコン 1 4はカプセルカウンタ値に該当するスーパ一カプセルを蓄積バッフ ァー 1 5から読み出す。 その後、 マイコン 1 4はスーパーカプセルを再送するた めに、 UD P Z I Pパケット化器 9に出力の制御を行なう。 この場合、 スーパ一 カプセルのヘッダー内に再送パケットであることを示す情報を更に付加して出力 する場合もある。 なおカプセルカウンタ値の計数範囲はス一パーカプセルを送信 する速度に対し、 送信する通信網での最大遅延時間の 2倍 （スーパ一カプセル送 信後再送コマンド受信までの遅延分） を少なくともカバーできるビット数である ことが望ましい。 また、 蓄積バッファーサイズは少なくともスーパーカプセルを カプセルカウン夕の計数範囲分蓄積できる量であることが望ましい。 また再送コ マンドのフォ一マツトについては受信側と予め取り決めておけば良い。 本実施例 では再送コマンドのフォーマツトを特に限定しない。
UD P Z I Pバケツト化器 9は、 偭々のスーパ一カプセルを I P通信網に送信 するために I Pデータグラム内に格納し、 I Pバケツトヘッダ一を付加して I P パケットとして出力する。 この出力信号を図 5の S 4に示す。 また、 S 4の I P とは I Pヘッダーなどの通信プロトコルにおけるヘッダーを示している。 I Pパ ケットヘッダーについてはインタ一ネットで周知の内容なので説明は省略する。 この例では更に UD Pバケツト内に I Pバケツトヘッダ一を格納しているが本来 その必要は無い。 また別のプロトコル、 例えば T C Pバケツト内に I Pバケツト へッダ—を格納しても良い。
イーサネットパケット化器 1 0は、 イーサネットバケツト化器 1 0に入力され る I Pバケツトをイーサネッ卜のデータ領域に格納する。 また、 イーサネットパ ケット化器 1 0は I Pバケツトにイーサネットバケツトヘッダーとチェックサム を付加してィ一サネットパケットとして出力する。 イーサネットパケットヘッダ 一とチェックサムについてはインタ一ネッ卜で周知の内容なので説明は省略する。 送信器 1 1はイーサネットパケットをインターネット網に送信する。 インター ネット網では様々な通信事業者が様々な方式で通信網を運営しており、 送信器 1 1と受信器 1 2はこれら様々な方式に対応するものである。 また、 その形態や仕 様について特に制限はしない。
次に送信パケット構成について説明する。 図 6は本実施例におけるイーサネッ トパケット構成を示す図である。 図 6では M P E G 2— T S Pにタイムスタンプ を含む 4バイトのヘッダ一を付加した拡張 T Sバケツトを 7つカプセル化してい る。 そして、 拡張 T Sパケットを識別するための識別値と、 カプセルカウンタ値 と、 拡張 T Sパケットサイズと、 拡張 T Sパケット数とを含む 8バイトのヘッダ 一を付加して 1 3 5 2バイトのスーパ一カプセル化している。 そして、 スーパー カプセルに 8バイ卜の UD Pバケツ卜ヘッダーを付加して 1 3 5 6パイトの UD Pパケットとしている。 そして、 UD Pパケットに 2 4バイトの I Pパケットへ ッダーを付加して 1 3 8 0バイトの I Pパケット化している。 そして、 I Pパケ ットに 1 4バイトのイーサネットヘッダーと 4バイ卜のチェックサムを付加して 1 3 9 8バイトのィ一サネットパケット化している。
通信網では、 最大伝播バケツト単位である MT Uを制限している場合が多い。 そして、 送出するパケットデータサイズが MT Uをオーバ一している場合は、 通 信網においてパケットを分割する場合が多い。 インターネットではこのような処 理をフラグメントと言う。 フラグメント後に発生したパケットロスやジッターの 補償を受信側で行うことは困難である。 これは、 ヘッダー情報の喪失に原因があ る。 このため本実施の形態においては、 スーパ一カプセル内の拡張 T Sパケット 数を 7つに設定している。 これは、 イーサネット通信網における MT U 1 5 0 0 バイトに対しイーサネットパケットのデータ領域のデータサイズがオーバーしな いようにするためである。
M P E G 2— T S Pのデータサイズは、 エンコーダ一の仕様により 1 8 8バイ ト固定である。 したがって、 拡張 T Sパケットのデ一タサイズは 1 9 2バイトと なる。 そして、 イーサネット通信網における MT U 1 5 0 0バイトを満たしなが らスーパーカプセルに格納できる拡張トランスポートバケツト数は最大 7つとな る。
このように通信網の MTUに応じてスーパ一カプセル内に格納する拡張 T Sパ ケッ卜数を設定することで、 通信網でのフラグメントを防止する。 更に前述した 力プセルカウント値を付加することと、 再送機能を備えることによりパケット口 スの補償を受信側に提供することができる。
なお、 通信網はイーサネットを使用するインターネットに限定するものではな い。 例えば U S Bを使用しても良く、 携帯電話などの無線通信網などであっても 良い。 また、 MTUもそれらに応じた値に対応可能である。 また圧縮方式は M P E G 2に限定しない。 例えば、 M P E G 4やその他の方式であっても良い。 次に実施例 1における受信側の例を説明する。 図 2は実施例 1におけるコンテ ンッ受信器の構成を示す図である。 図 3は個々のパケットを受信して蓄積するま での動作例を示したフローチヤ一トである。 図 4は蓄積後再生する時の動作を示 したフロ一チヤ一卜である。
図 2において、 マイコン 2 9はコンテンツ受信器の各部の制御を行う。 受信器 2 1は、 インターネット網などの通信網から図 6に示すイーサネットパケットを 受信し出力する。 インターネット網では様々な通信事業者が様々な方式で通信網 を運営しており、 受信器 2 1と後述する送信器 3 1はそれらの方式に対応するも のである。 また、 その形態や仕^ iについて特に制限はしない。 通信網はイーサネ ットを使用するインターネットに限定するものではなく、 U S Bを使用しても良 く、 または携帯電話などの無線通信網などであつても良い。
イーサネットバケツト処理器 2 2は、 イーサネットパケット処理器 2 2当ての イーサネットバケツトにイーサネッ卜のプロトコル処理を行い UD P Z I Pパケ ットを出力する （この処理を図 3の S T E P 5 1に示す。 また、 この出力信号を 図 5の S 5に示す）。
図 5の S 5では、 受信 UD Pノ I Pパケットがインタ一ネット網を介した結果 ジッターとバケツトロスが発生していることを意味している。 つまり V I D E O 1と DATA 1を含むパケットは定常的な遅延より大きな遅延が生じている。 ま た、 V I DEO 3と AUD I〇 2を含むパケットは定常的な遅延より小さい遅延 が生じている。 また、 V I DE02と AUD I O 1を含むパケットは一旦バケツ トロスとなり後に再送されている。
ここで、 図 5を用いてイン夕一ネットの場合のジッターとパケットロスについ て説明する。 インタ一ネット網における送信側と受信側の間には、 定常的な遅延 が存在する。 全てのパケットがその定常的な遅延を持って伝達されるのが理想的 であり、 その場合はジッターやパケットロスは発生しない。 しかしながら、 実際 のインタ一ネット網では、 パケットが異なるルートを割り当てられる、 パケット の有効時間中に伝達できない為パケットがゲ一トウエイで削除される、 バケツト が再送される、 などが生じるので、 ジッターやパケットロスが発生する。 S 5の 記載については、 定常的な遅延をあえてゼロに表現することで、 限られた紙面上 ジッターを分かりやすく記している。 具体的には、 V I DEO 1と DATA1を 含むバケツトは定常的な遅延より大きな遅延が生じているため、 S 4に比べ遅く (遅れているように） 記している。 V I DEO 3と AUD I O 2を含むパケット は定常的な遅延より小さい遅延が生じているため S 4に比べ早く （進んでいるよ うに） 記している。 また V I DEO 2と AUD I O 1を含むパケットは、 一旦パ ケットロスとなり、 後に再送されていることを記している。
図 2に示す UDPZ I Pパケット処理部 23は、 UDP/ I Pバケツトに UD PZ I Pのプロトコル処理を行い、 スーパ一カプセルを出力する （この処理を図 3の STEP 52に示す。 また、 この出力信号を図 5の S 6に示す）。
以上のィ一サネットおよび UDP/ I Pのプロトコル処理はインタ一ネットで 周知であるので説明は省略する。 また、 イーサネットパケットや UDPパケット 処理はここに記した内容に限定せず、 受信バケツトの種別や通信網の仕様に応じ る。 また、 他の通信プロトコル処理を行う場合もある。
これらの通信プロトコルにはそれぞれのヘッダ一にデータ本体のプロトコル処 理方法を示す情報が含まれている。 各種プロトコルの処理方法については規格化 されており、予めコンテンツ受信器はその処理方法を備える事ができる。従って、 コンテンツ受信器は、 ヘッダー内のプロトコルを示す情報を解析する事により、 ヘッダーを削除した後のデータ本体のプロトコル処理を行うことができる。 カプセル処理機 24は、 図 6で示した個々のスーパーカプセルから、 個々のス 一パーカプセルのヘッダーを取得する。 また、 カプセル処理機 24はこのヘッダ 一内に含まれている構成データの内容を示す情報をマイコン 29に出力する。 こ のデ一夕の内容を示す情報は、 カプセル化されたデータのフォ一マットタイプを 識別するための情報である （この例では前述した拡張 TSパケットであることを 識別する情報)。 また、 このデータの内容を示す情報は、 カプセル内の拡張 TSパ ケットのバケツト長および拡張 TSバケツト数を示す情報などもある。 拡張 TS パケットのバケツト長および拡張 TSバケツト数を示す情報はカプセル化された 総データ長であっても良い。
マイコン 29は与えられたデータの内容を示す情報を解釈して、 カプセル化さ れているデータが拡張 TSバケツトであることを認識する（図 3の STEP 5 3) 。 またマイコン 29は、 個々の拡張 TSパケットのサイズを認識し、 蓄積デ バイス 32の蓄積領域を確保する。 またマイコン 29は、 蓄積制御機 28に対し 蓄積バケツトサイズの設定や個々の拡張 TSパケットを記憶する際のアドレス初 期設定など準備を行う（図 3の STEP 50)。 これらの準備は、 最初のスーパー カプセルを入力した時点やデータの内容を示す情報に変更があった事を検出して その場合に行ってもよい。
また、 カプセル処理機 24はへッダ一に含まれているカプセル力ゥンタをモニ 夕一して、 連続性を確認する (図 3の STEP 54)。 カプセル処理機 24は個々 のスーパーカプセルにおけるカプセルカウン夕値を検出して、 不連続点のチェッ クを行う。 カプセル処理機 24が不連続点を検出すればカプセルカウンタの推移 により不連続性を検証する（図 3の STEP 64)。
この不連続性が、 カプセルカウンタ値が同じかまたは減少する方向の不連続で あれば、 カプセル処理機 24は、 不連続点以後に検出するカプセルカウンタ値が 不連続点直前のカプセルカウンタ値を上回り不連続が解消するまでの間のス一パ 一カプセルを削除する（図 3の STEP 65)。 .
この不連続性が、 カプセルカウンタ値が増加する方向の不連続であれば、 カブ セル処理器 24は不連続に該当するスーパ一カプセルは削除しない。 そして、 力 プセル処理器 2 4はマイコン 2 9に不連続点を検出したことを通知して、 カプセ ル処理器 2 4が受信できなかったスーパーカプセルに該当するカプセルカウンタ 値をマイコン 2 9に出力する。
また、 カプセル処理器 2 4は、 ダミー拡張 T Sパケットで構成されるダミーへ ッダ一を備えたダミースーパーカプセルを生成する。 そして、 カプセル処理器 2 4は、 カプセル処理器 2 4が受信できなかったスーパ一カプセルに該当する時間 的スペースにこのダミースーパ一カプセルを挿入して後段に出力する （図 3での S T E P 6 6 ) これは、 後段で再送パケット挿入処理を簡略化するためである。 マイコン 2 9はカプセル処理器 2 4からの通知を受けて、 スーパ一カプセルを 再送指示するための再送コマンドを出力する。 このとき、 マイコン 2 9はこの再 送コマンドをカプセル処理器 2 4が受信できなかったスーパ一カプセルに該当す るカプセルカウンタ値を用いて生成する（図 3の S T E P 6 7 ) o送信器 3 1は、 イーサネットを使用するインタ一ネット網などの通信網を介して、 再送コマンド を送信側に送信する。
送信側が再送したスーパーカプセルはへッダー内に再送であることを示す情報 を含んでいるので、カプセル処理器 2 4において検出が可能である。 したがって、 カプセル処理器 2 4は前述した不連続性の検証対象からこれを除外し、 後段にそ のまま出力する。 （図 3の S T E P 5 4 )。
マイコン 2 9はカプセル処理器 2 4から不連続の通知を受けてから直ちに再送 コマンド送信の制御を行わなくても良い。 マイコン 2 9は、 カプセル処理器 2 4 に対し検出できなかったスーパ一カプセルの受信待機を指示してから所定の時間 の間、 該当するスーパーカプセルが受信できなかった場合に再送コマンド送信の 制御を行う場合もある。 受信待機を指示してから所定の時間の間に受信できた場 合は、 カプセル処理器 2 4は所定のヘッダ一内に再送パケットを示す情報を付加 して後段に出力する。これは後段で再送パケットと同様に処理させるためである。 誤動作を避けるためには、 待機時間はカプセルカウンタ値が一巡する時間より短 く、そして通信網におけるパケット到着の最大遅延時間より長いことが望ましい。 また、 S T E P 5 4、 S T E P 6 4での不連続性の確認および確認後の処理制御 は、 カプセル処理器 2 4とマイコン 2 9でのソフトウエア処理とのどちらかで行 なう。
次に、 カプセル処理機 24はマイコン 29の制御によってカプセル化されてい る拡張 TSパケットを分離して出力する。 ここでは拡張 TSパケットに含まれて いる MP EG 2—TS Pがスクランブルされている場合や再送バケツトの場合も 考慮して、 個々の MP EG2— TS Pとタイムスタンプが含まれているヘッダ一 を分離して出力する。 マイコン 29は M P E G 2— T S Pがスクランブルされて いるかを確認する（図 3の STEP 55)。
MPEG 2— TS Pのヘッダーはスクランブルされているかどうかの情報をス クランブルされる範囲外に持っている。 したがって、 マイコン 29は一旦 MPE G2—TS Pを取り出した後でその情報を確認して、 スクランブルされている範 囲に対しデスクランブル処理を行うことができる。 どの方式を用いるかを受信側 と送信側とで予め決めておくこと、 または、 受信するテーブル情報を受信側で確 認して認識すること、 これらのことで任意の方式への対応が可能である。
デスクランブラ 25は、 デスクランブラ 25に入力された MP EG 2— TS P を送信側でのスクランブルに対応した方式でデスクランブルして、 後段に出力す る。 一方、 タイムスタンプを含んだヘッダーはタイムスタンプバッファー 26に おいてデスクランブラ 25の処理時間分遅延させて MPEG 2— TS Pと時間的 な同期を取った後、 後段に出力する （図 3の STEP 56)。
また、 マイコン 29は再送パケットかどうかの確認も行う （図 3の STEP 6 8)。再送バケツトはヘッダーに再送バケツトを示す情報を有している。 したがつ て、 マイコン 29はそれを見て再送パケットかどうかを確認する。 再送パケット の場合はタイムスタンプに加え再送バケツトであることを示す情報とカプセル力 ゥンタ値を更に付加したヘッダ一を生成してタイムスタンプバッファ一 26に出 力する （図 3の STEP 69)。
拡張 TS再生器 27は、 MPEG2—TSとヘッダーを結合して拡張 TSパケ ットを再生し、 出力する。 この処理を図 3の STEP 57に示す。 また、 この出 力信号を図 5の S 7に示す。 蓄積制御器 28は、 通信網における遅延あるいは口 スにより再取得した拡張 T Sパケットかどうかの確認をへッダ一情報によつて行 う （図 3の STEP 58)。再送パケットではない場合は、 マイコン 29の制御に より蓄積デバィス 32上の管理された領域に順次拡張 T Sパケットを書き込む (図 3の STEP 59)。再送バケツトである場合は、 STEP 66においてダミ 一拡張 TSパケットとダミースーパーカプセルを生成する。 そして、 前もって蓄 積済みの対応するダミー拡張 TSバケツトに再取得した拡張 TSパケットを上書 きする （図 3の STEP 60)。
再送された拡張 TSパケットにはカプセルカウンタ値が含まれている。 またマ イコン 29がカプセルカウンタ値と蓄積デバイス 32のアドレス管理を行ってい る。 これらのことから、 この上書き制御は、 再送された拡張 TSパケットを本来 の蓄積領域 （ダミー拡張 TSパケットを一旦蓄積して確保している領域） に蓄積 して、 蓄積デバイス 32における連続性を補償する （図 5の S 8)。
図 5の S 8では再送された V I DE02と AUD I〇 1の拡張 TSパケットが 本来の場所に蓄積されている。 また、 蓄積デバイス 32では到着時刻や送信側で の送信時刻を参照せず記憶するため、各拡張 T Sパケットを効率よく蓄積できる。 なお蓄積デバイス 32は HDDや DVDなどの如何なる蓄積メディアでも良く、 半導体メモリでも良い。 また、 再送制御を簡略化してジッター補償のみの制御と すれば、 蓄積デバイス 32に要求される容量も、 後述のカウンタが一巡する時間 に受信する全ての拡張 T Sパケットを蓄積できる範囲に少なくなる。
なお図 3の STEP 53においてマイコン 29は拡張 TSパケットが格納され ていないことを確認する。 例えばこれが通常の MPEG2— TSPであった場合 には、 スクランブルされているかどうかを同様に確認する (図 3の STEP 61)。 そして、 スクランブルされている場合はデスクランブラ 25にてデスクランブル する （図 3の STEP 62)。そして、拡張 TS再生機 27でタイムスタンプを含 むヘッダ一を生成し付加して拡張 TSパケット化して出力し （図 3の STEP 6 3)、同様に蓄積デバイス 32に蓄積する。 この場合も以後の再生処理は共通化で きる。 ただし、 この場合はジッター補償やパケットロス補償は従来例と同じとな る。
次に、 再生時の説明を行う。 再生制御機 33は、 システムクロックをカウン卜 するカウンタを備えている。 再生制御機 33は、 このカウン夕のカウント値と T Sデコーダ 34から出力される PCR信号とを比較した結果が等しくなるように、 システムクロックの周波数を制御する。 つまり、 既存の MPEGトランスポート システムをそのまま使用してシステムクロックを再生することができる。 したが つて、 再生時において、 MPEGトランスポートシステムのスペックを、 既存の 技術を用いて容易に満たす事ができる。 また、 マイコン 29の制御により再生制 御機 33は蓄積デバイス 32に記憶されている拡張 TSパケットを、 このシステ ムクロックに同期させて順次読み出す (図 4の STEP 71)。 そして、 再生制御 機 33は、 個々のタイムスタンプと前述したカウン夕の計数値とが所定のオフセ ット値を持って合致するタイミングで (図 4の STEP 72)タイムスタンプを含 むヘッダーを取り外す。 そして、 再生制御機 33は個々の MPEG2— TS Pを 後段に出力する。 この処理を図 4の STEP 73に示す。 また、 この出力信号を 図 5の S 9に示す。
この段階で、 送信側での MP EG 2— TSは再生されており、 通信網において 発生したジッターは補償されている。 なお、 送信側において、 PCR信号をカウ いる。 したがって、 再生制御機 33は、 PCR信号から求められるこのカウンタ の計数値と、 タイムスタンプとを比較することができる。
TSデコーダー 34はMPEG2_TSPをAVデコーダー35が AVデコー ドできる形態に直して、 出力する。 AVデコーダー 35は、 A Vデコーダー 35 に入力されるデータを AVデコードして出力する。 STEP 72において、 タイ ムスタンプとシステムクロックカウンタ値が一致しなかつた場合は、 再生制御機 33はその差分を検証する (図 4の STEP 75)。 そして、 その差分が再生制御 機 33内部のバッファー （図示せず） でジッター補償できる範囲であれば拡張 T Sパケットはバッファー上で待機させる。 その差分が、 再生制御機内部のバッフ ァ一でジッター補償できる範囲を超える場合は、 該当する拡張 TSパケットを廃 棄するよう制御する （図 4の S TEP 76)。
次に受信パケット構成について説明する。 図 6では、 スーパーカプセル内の拡 張 TSパケット数は 7つのイーサネットパケット （1398バイト） を受信する 例を示している。
データ領域は 1356バイトの UDP/ I Pバケツトを有しており、 更にその データ領域は 1 3 5 2バイトのスーパーカプセルを有している。 スーパーカプセ ルには M P E G 2— T S Pにタイムスタンプを含む 4バイトのヘッダーを付加し た拡張 T Sパケットが 7つカプセル化されている。 また、 スーパ一カプセルは拡 張 T Sパケットを識別するための識別値とカプセルカウン夕値と拡張 T Sパケッ トサイズと拡張 T Sパケット数を含む 8バイトのヘッダ一を有している。
通信網においては、 最大伝播バケツト単位である MT Uを制限している場合が 多い。 そして、 パケットデータサイズが MTUをオーバーしている場合は、 通信 網においてパケットを分割する場合が多い。
インタ一ネットではこのような処理をフラグメントと言う。 フラグメント後に 発生したパケットロスやジッターの補償を受信側単独で行うことは困難である。 したがって、 本実施例では、 スーパーカプセル内の拡張 T Sパケット数を 7つに 設定している。 これは、 イーサネット通信網における MT U 1 5 0 0バイトに対 しイーサネットパケットのデータ領域のデータサイズがオーバーしないようにす るためである。
M P E G 2—T S Pのデータサイズは、 エンコーダ一の仕様により 1 8 8バイ ト固定である。 したがって、 拡張 T Sパケットのデ一夕サイズは 1 9 2バイトと なり、 イーサネット通信網における MT U 1 5 0 0バイトを満たしながらスーパ 一カプセルに格納できる拡張トランスポートバケツト数は最大 7つとなる。 このようにフラグメントを防止することで、 以上に説明したように、 通信網に おいてパケットロスが発生した場合は個々のスーパーカプセルに付加されている カプセルカウント値を利用してロスパケットの再送を要求する。 そして、 再送さ れたパケットを蓄積デバイスに蓄積するときにカプセルカウント値を用いてパケ ットロスの補償を行う。
また、 再生時には個々の拡張 T Sパケットに含まれる再生用タイムスタンプを 用いることで、 通信網で発生するジッターの補償を、 システムクロックの精度で 正確に行う。 更に、 前述したようにコンテンツ送信器とコンテンツ受信器とのデ コードのタイミングを制御するジッ夕一補償や再送制御するパケットロス補償の 連携制御により、 それらの補償を確実に効率良く行う。
なお、 通信網はイーサネットを使用するインターネットに限定するものではな レ^ 例えば、 USBや、 携帯電話などの無線通信網などであっても良い。 また圧 縮方式は MP EG2に限定しない。 例えば、 MP EG 4やその他の方式であって も良い。
また、 再生制御器 33は MP EG 2— TSPを、 コンテンツ受信器から、 バス 上に接続される AVデコーダーに出力する場合もある。 この場合、 再生制御器 3 3は I EEE 1 394イン夕一フェース （図示せず） などの外部出力用インター フェースに接続される。 また、 MPEG2— TSPはイン夕一フェースにより定 められるァイソクロナスバケツトに格納される。
また、 TSデコーダ一 34を I EEE 1 394イン夕一フェース （図示せず） などの外部出力用インタ一フェースに接続し、 TSデコーダー 34の出力を外部 の AVデコーダーに送信する構成としても良い。 この場合、 外部出力用インター フェースは、 ィン夕一フェースの規格により定められるァイソクロナスバケツト に MP EG 2— TS Pを格納して出力する。 (実施例 2 )
図 12は実施例 2によるコンテンツ送信器の構成を示す図である。 図 1 3は実 施例 2による I EEE 1 394インタ一フエ一スの構成を示す図である。 図 14 は実施例 2によるコンテンツ受信器でのバケツト構成の推移を示す図である。 図 1 5と図 16は実施例 2による I EEE 1394インターフェースが送信するパ ケットの構成を示す図である。
図 12において、 インタ一ネット網から受信したバケツトを蓄積デバイス 32 で蓄積するまでの構成および動作は実施例 1と同じであるので説明は省略する。 読み出し制御器 36は、 マイコン 29の指示によって蓄積デバイス 32に蓄積さ れている拡張 TSバケツトを、 拡張 TSバケツト読み出しクロック生成器 37が 生成する所定の周波数のクロックに同期させて読み出す。 その場合、 図 14の S 10で示すように各拡張 TSバケツト間に所定の時間間隔を挿入して出力する (図 14の S 1 0)。その間隔は、時間間隔挿入後の拡張 TSバケツトのビットレ 一卜がコンテンツ送信器の拡張 TSパケット送出時のビットレ一ト以上になるよ うに、 クロック再生器 37のクロック周波数に応じて設定される。 I E EE 1394インターフエ一ス 38は、 I EEE 1394規格に準拠して いる。 また、 I EEE 1394インターフェース 38は、 I EEE 1394イン ターフェース 38に入力される拡張 TSパケットを、 ァイソクロナス転送モード で出力する (図 14の S 11)。 S 11において、 I SOとは I EEE 1394イン ターフェースで付加されるヘッダ一である。 読み出し制御器 36と I EEE 13 94インタ一フェース 38間の伝送信号は、 MPEG2— TSと同様にデータ信 号、 クロック信号、 パケットス夕一ト信号、データィネーブル信号で構成される。 また、 拡張 TSパケットを送信する際に、 I EEE 1394インターフェース 3 8にはマイコンにより拡張 TSバケツト情報が設定される。 これについて説明す る。
図 13は I EEE 1394インタ一フェース 38の構成を示した図である。 M PEG2インターフェース 41には、 拡張 TSパケットのストリ一ムが入力され る。 DTCP暗号化回路 42は、 MPEG2イン夕一フェース 41から出力され た拡張 TSパケットに D TCP (D i g i t a l T r an sm i s s i o n Con t en t P r o t e c t i on) 規格に則った著作権保護の為の暗号化 を行い、 出力する。 ヘッダー付加回路 43は、 DTCP暗号化を行ったパケット にヘッダーを付加して出力する。 このヘッダ一はァイソクロナス転送するために 必要なヘッダーである。
バケツトフォーマツト情報付加回路 44には、 拡張 TSパケットのフォーマツ トを指定する情報がホストインタ一フェース 46を介してマイコンから入力され る。 そして、 パケットフォーマット情報付加回路 44は、 ヘッダ一の所定の位置 に、 ァイソクロナス転送するバケツトのデータフォ一マツトを拡張 TSバケツト と識別するための情報を書き込む処理を行う。
バケツトデ一夕サイズ情報付加回路 45には、 拡張 TSバケツトのデータサイ ズを指定する情報がホストインタ一フエ一ス 46を介してマイコンから入力され る。 そして、 パケットデータサイズ情報付加回路 45は、 その情報を元にアイソ クロナスパケットのデータサイズを算出して決定する。 あるいは、 パケットデ一 タサイズ情報付加回路 45には、 拡張 TSバケツトを格納するァイソクロナスパ ケットサイズの情報が、 ホストインターフェース 46を介してマイコンから入力 される。 そして、 パケットデータサイズ情報付加回路 45は、 ヘッダーの所定の 位置にァイソクロナス転送するパケットのデータサイズの情報を書き込む処理を 行う。
ここで、 拡張 TSパケットに対する付加ヘッダーについて説明する。 図 1 5と 図 16は MP EG 2パケットについて規定した I EC 61883— 4とは異なる フォーマツトである。 図 15は拡張 TSパケットにァイソクロナスヘッダーのみ が付加される例を示した図である。 この場合はパケットデータサイズのみを図 1 5に示すデータ長領域に書き込む。 もし、 拡張 TSパケットのデータサイズが 1 92バイトであれば、 192を 3倍した 576バイトと、 ァイソクロナスヘッダ 一とデータ CRCの 12パイトとを足した 588バイトを示すデ一夕を図 15の デ一夕長領域に書き込む。
図 16は、 ァイソクロナスヘッダーと共通ヘッダ一とを拡張 TSパケットに有 する例を示した図である。 ここでは、 パケットデ一夕サイズを図 16のアイソク 口ナスヘッダ一のデータ長領域に書き込み、 拡張 TSパケットを識別する為の情 報を共通ヘッダーのフォーマット領域に書き込む。 もし、 拡張 TSパケットのデ 一夕サイズが 192バイ卜であれば、 Re s e r v e d領域の 4と 192を加え た数字を 3倍した 588バイトと、 ァイソクロナスヘッダ一と共通ヘッダーとデ 一夕 CRCの 16バイトと、 R e s e r V e dの 4バイトを足した 608バイト を示すデータを図 16に示す領域書き込む。 Re s e r v e d領域は将来の拡張 のための領域である。 拡張 TSパケットを識別する為の情報は現在運用されてい るデータがあれば、 それらを除いた範囲で予めコンテンツ送信側と決定されるデ 一夕である。
図 15と図 16は、 拡張 TSパケットが 3パケット格納されているァイソクロ ナスパケットの例であるが、 パケット数は 3に限定しない。 例えば、 このバケツ ト数は 4でも 2でも 1でも良い。 また、 拡張 TSパケットのデータサイズは 19 2バイトの例であるが、 特に限定しない。 例えば、 拡張 TSパケットのデ一タザ ィズは 196バイトであっても良い。
図 13に示す I E EE 1394ァイソクロナスバケツト送出回路 47は、 I E EE 1394規格に則ったデータリンク層および物理層のプロトコルを実現する 回路で構成されている。 また、 I E E E 1 3 9 4ァイソクロナスパケット送出回 路 4 7は、 I E E E 1 3 9 4ァイソクロナスバケツト送出回路 4 7に入力される ヘッダ一を付加されたパケットを 1 3 9 4バスに送出する。
以上説明したように実施例 2では、 I E E E 1 3 9 4インタ一フェースを介し て拡張 T Sパケットを送信可能となる。 また、 本実施例 2におけるコンテンツ受 信器において、 1 3 9 4バス上に、 T Sデコーダ一 （図示せず） および AVデコ ーダ （図示せず） を別途接続した構成としても実施例 1で説明した効果を実現で きる。 産業上の利用可能性
以上のように本発明のコンテンツ受信器によれば、 通信網において発生するパ ケットロスを受信側で補償することができずパケットロスが発生した場合にデコ 一ドエラ一となつてしまうことを防止でき、 デジタルテレビジョン放送受信機、 パーソナルコンピュータ、 携帯電話機、 携帯情報端末機および携帯電話アダプタ 一に有用である。
また、 本発明のコンテンツ送信器によれば、 受信側において、 データを蓄積す る際に到着時刻を無視して効率よく蓄積デバイスに蓄積できる。 また、 再生時に は、 デコーダーに出力する時刻を示すタイムスタンプを用いてデコーダーの求め る精度で再生することができる。 これにより、 ジッター補償精度がデコードする 上で不十分な場合にデコードエラーとなることを防止でき、 デジタルテレビジョ ン放送受信機、 パーソナルコンピュータ、 携帯電話機、 携帯情報端末機および携 帯電話アダプターに有用である。

Claims

請求の範囲
1 . 圧縮されたトランスポ一卜パケッ卜から構成されるストリ一ムにより形成 されるコンテンツを送信側から受信し再生する受信器において、 前記コンテンツ を受信した後に蓄積する蓄積手段と、 前記蓄積手段に蓄積した前記コンテンツを 再生する再生手段とを備え、 受信するコンテンツを形成する個々のトランスポー トパケットがトランスポートバケツトのシステムクロックを用いて生成された再 生時刻指示情報を付加されている拡張トランスポートパケットである場合、 前記 再生手段は蓄積された個々の前記拡張トランスポ一トバケツトを前記再生時刻指 示情報から求める時刻で再生することを特徴とするコンテンツ受信器。
2 . 圧縮されたトランスポートバケツトから構成されるストリームにより形成さ れるコンテンツを送信する送信器において、 前記コンテンツを送信する送信手段 と、 トランスポートバケツトのシステムクロックを用いて受信側が蓄積手段から 再生する際の時刻を指示する再生時刻指示情報を生成する再生時刻指示情報生成 手段と、 前記送信手段は送信する個々のトランスポートバケツトに前記再生時刻 指示情報を付加した拡張トランスポートバケツトを送信するコンテンッ送信器。
3 . 請求項 2記載のコンテンッ送信器からストリームを受信することを特徴とす る請求項 1記載のコンテンッ受信器。
4. 前記拡張トランスポートパケットは一つ以上でカプセル化され、 更にカプセ ルのカウント情報と力プセル内の前記拡張トランスポートパケットの内容を示す カプセル情報を付加されたスーパ一カプセルを受信することを特徴とする請求項 1記載のコンテンツ受信器。
5 . 前記拡張トランスポートパケットを一つ以上でカプセル化し、 更にカプセル のカウント情報とカプセル内の前記拡張トランスポ一トバケツトの内容を示す力 プセル情報を付加したスーパーカプセルを送信することを特徴とする請求項 2記
'送 1目器。
6 . 請求項 5記載のコンテンッ送信器からストリームを受信することを特徴とす る請求項 4記載のコンテンツ受信器。
7 . 受信したスーパ一カプセル内の拡張トランスポートパケットを蓄積手段に蓄 積する際に前記カプセル情報と前記カウント情報に応じて個々の蓄積領域を管理 する蓄積管理手段を備え、 前記カウント情報の連続性を確認し通信網でのスーパ 一力プセルの欠落を認識した場合は、 前記力ゥント情報を含む再送要求コマンド を生成して送信側に送信し、 前記送信側から再送され受信する該当するスーパー カプセル内の拡張トランスポートパケットも前記カウント情報に応じた前記蓄積 管理手段の管理する領域に蓄積する様に制御することで再生する際には欠落を解 消することを特徴とする請求項 4記載のコンテンツ受信器。
8 . 前記力ゥント情報の連続性の確認において力ゥントと同方向の不連続を検出 した場合にスーパー力プセルの欠落を認識することを特徴とする請求項 7記載の コンテンツ受信器。
9 . スーパ一カプセルの欠落を認識した場合は、 ダミースーパーカプセルを生成 し欠落分の代わりに前記蓄積手段に一旦蓄積し、 再送された該当するスーパー力 プセルの蓄積制御は前記ダミーカプセルに上書きすることを特徴とする請求項 7 または 8に記載のコンテンツ受信器。
1 0 . 送信するスーパ一カプセルを所定数蓄積するバッファ一手段を備え、 前記 カウント情報を用いて生成された再送要求コマンドを受信側から受信した場合は、 前記カウント情報を有する該当のスーパーカプセルを検出し受信側に再送するこ とを特徴とする請求項 5記載のコンテンツ送信器。
1 1 . 請求項 1 0記載のコンテンツ送信器からストリームを受信することを特徴 とする請求項 7から 9までのいずれかに記載のコンテンツ受信器。
12. 前記スーパーカプセルに格納されている前記拡張トランスポートパケット 数は通信時のバケツ卜におけるデータ領域のデータサイズが通信網の MTU (M a X i mum T r an smi s s i on Un i t) を超えないように設定さ れることを特徴とする請求項 4、 7、 8、 9のいずれかに記載のコンテンツ受信
13. 前記ス一パーカプセルのデータ領域に格納する前記拡張トランスポートパ ケット数は通信時の通信バケツトにおけるデータ領域のデータサイズが通信網の MTU (Max imum Tr an smi s s i on Un i t) を超えないよ うに設定することを特徴とする請求項 5または 10に記載のコンテンツ送信器。
14. 請求項 13記載のコンテンツ送信器からストリームを受信することを特徴 とする請求項 12記載のコンテンツ受信器。
15. デスクランブル手段を備え、 蓄積手段に拡張トランスポートパケットを蓄 積する際、 前記再生時刻指示情報を取り外したトランスポートパケットをデスク ランブルした後に、 前記再生時刻指示情報を再付加し拡張トランスポートバケツ トを再現して蓄積することを特徴とする請求項 1、 4、 7、 8、 9、 12のいず れかに記載のコンテンツ受信器。
16. スクランブル手段を備え、 スクランブル後のトランスポートパケットに対 し前記再生時刻指示情報を付加することを特徴とする請求項 2、 5、 10、 13 のいずれかに記載のコンテンッ送信器。
17. 請求項 16記載のコンテンツ送信器からストリームを受信することを特徴 とする請求項 15記載のコンテンツ受信器。
18. トランスポートバケツト内のエンコードされたコンテンツをデコードする 為に使用するトランスポートバケツト内の時刻情報を基に生成するシステムクロ ックを計数する第 1の計数手段を備え、 蓄積後再生する際には前記再生時刻指示 情報と前記計数手段の計数値とを所定のオフセット値を持って一致したタイミン グでデコードすることを特徴とする請求項 1、 4、 7、 8、 9、 1 2、 1 5のい ずれかに記載のコンテンツ受信器。
1 9 . コンテンツをエンコードする為に使用するシステムクロックを計数する第 2の計数手段を備え、 前記再生時刻指示情報は前記第 2の計数手段の計数値を使 用して生成する請求項 2、 5、 1 0、 1 3、 1 6のいずれかに記載のコンテンツ
2 0 . 請求項 1 9記載のコンテンツ送信器からストリームを受信することを特徴 とする請求項 1 8記載のコンテンツ受信器。
2 1 . 送信側から I Pプロトコル網を介して I Pパケットを受信し I Pパケット 内部に格納されているストリームを蓄積手段に蓄積する際の処理として、 I Pプ 口トコルにおける I Pデータグラムのデータ領域に格納されている前記拡張トラ ンスポートパケットを抽出することを特徴とする請求項 1、 4、 7、 8、 9、 1 2、 1 5、 1 8のいずれかに記載のコンテンツ受信器。
2 2 . 前記拡張トランスポートパケットを I Pプロトコルにおける I Pデータグ ラムのデータ領域に格納して I Pプロトコル網を介して受信側に I Pパケットを 送信する事を特徴とする請求項 2、 5、 1 0、 1 3、 1 6、 1 9のいずれかに記 載のコンテンツ送信器。
2 3 . 請求項 2 2記載のコンテンツ送信器からストリームを受信することを特徴 とする請求項 2 1記載のコンテンツ受信器。
2 4. 再生した前記拡張トランスポートパケットを入力し拡張トランスポートパ ケットを識別する情報を付加して I EEE 1394バスに送出する I EEE 13 94インターフェースを備えた請求項 1記載のコンテンツ受信器。
25. 前記蓄積手段は前記拡張トランスポートパケットを蓄積する際、 時刻情報 を付加することなく蓄積領域に連続して蓄積することを特徴とする請求項 1記載 のコンテンツ受信器。
26. 前記再生手段は前記再生時刻指示情報を用いずに PCR情報を用いてシス テムクロックを再生することを特徴とする請求項 1記載のコンテンツ受信器。
27. トランスポートバケツ卜のシステムクロックを用いて受信側がシステムク ロックを再生するための PC R情報を生成する P C R生成手段と、 前記送信手段 は前記拡張トランスポートパケットとともに P C R情報を格納したトランスポ一 卜パケッ卜を送信することを特徴とする請求項 2記載のコンテンッ送信器。
PCT/JP2003/009043 2002-07-16 2003-07-16 コンテンツ受信器およびコンテンツ送信器 WO2004008760A1 (ja)

Priority Applications (6)

Application Number Priority Date Filing Date Title
EP03741425.7A EP1553774B1 (en) 2002-07-16 2003-07-16 Content receiving apparatus and content transmitting apparatus
CN038164469A CN1669320B (zh) 2002-07-16 2003-07-16 内容接收器
AU2003281136A AU2003281136A1 (en) 2002-07-16 2003-07-16 Content receiving apparatus and content transmitting apparatus
JP2004521223A JP4042745B2 (ja) 2002-07-16 2003-07-16 コンテンツ受信器
US10/515,528 US7830881B2 (en) 2002-07-16 2003-07-16 Content receiver and content transmitter
US12/899,074 US8503471B2 (en) 2002-07-16 2010-10-06 Content receiver and content transmitter

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2002-206780 2002-07-16
JP2002206780 2002-07-16

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US10515528 A-371-Of-International 2003-07-16
US12/899,074 Continuation US8503471B2 (en) 2002-07-16 2010-10-06 Content receiver and content transmitter

Publications (1)

Publication Number Publication Date
WO2004008760A1 true WO2004008760A1 (ja) 2004-01-22

Family

ID=30112803

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2003/009043 WO2004008760A1 (ja) 2002-07-16 2003-07-16 コンテンツ受信器およびコンテンツ送信器

Country Status (7)

Country Link
US (2) US7830881B2 (ja)
EP (1) EP1553774B1 (ja)
JP (3) JP4042745B2 (ja)
KR (2) KR100784874B1 (ja)
CN (1) CN1669320B (ja)
AU (1) AU2003281136A1 (ja)
WO (1) WO2004008760A1 (ja)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006014153A (ja) * 2004-06-29 2006-01-12 Nec Commun Syst Ltd パケットエラー監視型ｍｐｅｇデコーダ、ｍｐｅｇ映像伝送システム及びｍｐｅｇ映像伝送方法
JP2007266875A (ja) * 2006-03-28 2007-10-11 Toshiba Corp 映像データの処理方法及び無線通信装置
JP2007329606A (ja) * 2006-06-07 2007-12-20 Hitachi Ltd 中継装置
JP2008511214A (ja) * 2004-08-20 2008-04-10 ソニー エレクトロニクス インク データストリーム通信装置及びデータストリーム通信方法
JP2009081658A (ja) * 2007-09-26 2009-04-16 Kyocera Corp 署名検証方法および受信装置
JP2009081564A (ja) * 2007-09-25 2009-04-16 Kyocera Corp 署名検証方法および受信装置
JP2009081560A (ja) * 2007-09-25 2009-04-16 Kyocera Corp 署名検証方法、ストリーム生成方法、受信装置、およびストリーム送信装置
US7830881B2 (en) 2002-07-16 2010-11-09 Panasonic Corporation Content receiver and content transmitter

Families Citing this family (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1430706A4 (en) * 2001-06-11 2011-05-18 Broadcom Corp SYSTEM AND METHOD FOR MULTI-CHANNEL VIDEO AND AUDIO CODING ON A SINGLE CHIP
KR100608715B1 (ko) * 2003-09-27 2006-08-04 엘지전자 주식회사 ＱｏＳ보장형 멀티미디어 스트리밍 서비스 시스템 및 방법
JP2005204001A (ja) * 2004-01-15 2005-07-28 Hitachi Ltd データ配信サーバ、ソフトウェア、及びシステム
KR100631758B1 (ko) * 2004-05-04 2006-10-09 삼성전자주식회사 멀티 스트리밍 포맷을 지원하는 네트워크 ｉ/ｆ 카드 및그 방법
US20060007943A1 (en) * 2004-07-07 2006-01-12 Fellman Ronald D Method and system for providing site independent real-time multimedia transport over packet-switched networks
JP4421537B2 (ja) 2005-09-14 2010-02-24 株式会社東芝 ストリーム生成装置
KR100739740B1 (ko) * 2005-10-17 2007-07-13 삼성전자주식회사 방송 녹화 장치 및 방법
KR100800690B1 (ko) * 2006-02-10 2008-02-01 삼성전자주식회사 디지털 방송 서비스 시스템에서 방송 데이터 전송 장치 및방법
FR2898453A1 (fr) * 2006-03-13 2007-09-14 Thomson Licensing Sas Transmission d'un signal genlock sur un reseau ip
US7672393B2 (en) * 2006-08-02 2010-03-02 Richtek Technology Corporation Single-wire asynchronous serial interface
US8363541B2 (en) * 2006-12-22 2013-01-29 Pratt & Whitney Canada Corp. Serial digital communication protocol
US8145775B2 (en) * 2007-05-08 2012-03-27 Canon Kabushiki Kaisha Method to receive UDP response messages across multiple incoming UDP ports
EP2028857A1 (en) * 2007-08-21 2009-02-25 Alcatel Lucent Method and system for pausing and resuming a real-time data stream
US8477793B2 (en) * 2007-09-26 2013-07-02 Sling Media, Inc. Media streaming device with gateway functionality
US7908404B1 (en) * 2007-11-09 2011-03-15 Qlogic, Corporation Method and system for managing network and storage data
US8824511B2 (en) * 2008-03-27 2014-09-02 Nec Corporation Clock synchronization system, node, clock synchronization method, and program
FR2939993B1 (fr) * 2008-12-12 2010-12-17 Canon Kk Procede de transmission d'un flux de donnees multi-canal sur un tunnel multi-transport, produit programme d'ordinateur, moyen de stockage et tetes de tunnel correspondantes
JP5549221B2 (ja) * 2009-12-28 2014-07-16 ソニー株式会社 再生装置、再生制御方法、およびプログラム
US8514329B2 (en) 2011-05-31 2013-08-20 Motorola Mobility Llc Jitter estimation for MPEG receivers
JP2012257041A (ja) 2011-06-08 2012-12-27 Sony Corp 通信装置、通信システム、通信方法及びプログラム
US9451313B2 (en) 2011-06-29 2016-09-20 Harman International Industries, Incorporated Network media adapter
EP2798843A4 (en) * 2011-12-28 2015-07-29 Intel Corp SYSTEMS AND METHOD FOR INTEGRATED METADATA INSERT IN A VIDEO CODING SYSTEM
US20140369222A1 (en) * 2012-01-26 2014-12-18 Electronics And Telecommunications Research Institute Method for estimating network jitter in apparatus for transmitting coded media data
GB2499261B (en) * 2012-02-10 2016-05-04 British Broadcasting Corp Method and apparatus for converting audio, video and control signals
WO2013173683A1 (en) * 2012-05-18 2013-11-21 Motorola Mobility Llc Synchronizing multiple transcoding devices utilizing simultaneity of receipt of multicast packets
JP6505413B2 (ja) * 2013-11-08 2019-04-24 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 送信方法、受信方法、送信装置、及び受信装置
JP6298305B2 (ja) * 2014-01-23 2018-03-20 株式会社メディアリンクス 放送信号ｉｐ伝送システムおよび放送信号ｉｐ伝送方法
CN110071785B (zh) * 2014-06-24 2021-10-26 株式会社索思未来 接口方法
US9723610B2 (en) * 2015-04-07 2017-08-01 Qualcomm Incorporated Multi-layer timing synchronization framework
CN108600861A (zh) * 2018-03-26 2018-09-28 南京地铁建设有限责任公司 基于城市轨道乘客信息系统的音视频数据包包长调整方法
US10848539B2 (en) 2018-09-20 2020-11-24 Cisco Technology, Inc. Genlock mechanism for software pacing of media constant bit rate streams
JP7210272B2 (ja) * 2018-12-28 2023-01-23 株式会社東芝 放送システム、エンコーダ、多重化装置、多重化方法、系統切替装置、および同期制御装置

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10313350A (ja) * 1997-05-13 1998-11-24 Matsushita Electric Ind Co Ltd 通信システム
JPH1188856A (ja) * 1997-09-05 1999-03-30 Hitachi Ltd 伝送プロトコル変換方式およびプロトコル変換装置を用いたｃａｔｖネットワーク接続方式
JP2000307637A (ja) * 1999-04-16 2000-11-02 Nec Corp マルチメディア端末装置及び網間接続装置
JP2001016267A (ja) * 1999-07-01 2001-01-19 Sony Corp 通信装置および方法、並びに媒体
JP2001320413A (ja) * 2000-05-02 2001-11-16 Sony Corp データ送信装置及び方法
JP2002051321A (ja) * 2000-08-04 2002-02-15 Sony Corp デジタルビデオ送信機、デジタルビデオ受信機及びデジタルビデオ送受信機
JP2002141917A (ja) * 2000-08-22 2002-05-17 Matsushita Electric Ind Co Ltd 送信装置、ソースパケット生成装置、パケット形態決定方法、媒体及び情報集合体

Family Cites Families (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS56160157A (en) * 1980-04-22 1981-12-09 Sony Corp Bit clock reproducing circuit
US20010013123A1 (en) * 1991-11-25 2001-08-09 Freeman Michael J. Customized program creation by splicing server based video, audio, or graphical segments
JPH07212245A (ja) 1994-01-26 1995-08-11 Sony Corp データ転送回路
JP3371174B2 (ja) * 1994-09-22 2003-01-27 ソニー株式会社 パケット受信装置
JP3617655B2 (ja) * 1994-11-10 2005-02-09 ソニー株式会社 エンコードシステムおよびエンコード方法、デコードシステムおよびデコード方法、エンコードデータ記録装置およびエンコードデータ記録方法、エンコードデータ伝送装置およびエンコードデータ伝送方法、並びに記録媒体
US5901149A (en) * 1994-11-09 1999-05-04 Sony Corporation Decode and encode system
JP3440390B2 (ja) * 1995-03-01 2003-08-25 日本電信電話株式会社 等時性保証型連続メディア伝送装置及び等時性保証型連続メディア伝送方法及び受信装置
US5920572A (en) * 1995-06-30 1999-07-06 Divicom Inc. Transport stream decoder/demultiplexer for hierarchically organized audio-video streams
US5822317A (en) * 1995-09-04 1998-10-13 Hitachi, Ltd. Packet multiplexing transmission apparatus
BR9711082A (pt) * 1996-03-29 2000-01-11 Lawrence Berkeley National Lab Realce de rmn emri na presença de gases mopbres hiperpolarizados.
JP3400681B2 (ja) * 1997-07-16 2003-04-28 株式会社日立製作所 データパケット再多重方法及び再多重装置
AR016812A1 (es) * 1997-08-14 2001-08-01 Samsung Electronics Co Ltd Metodo para transmitir informacion de video comprimida, disposiciones de compresion y de grabacion de video y aparato de reproduccion de video
EP0901261B1 (en) * 1997-09-05 2013-01-09 Hitachi, Ltd. Transport protocol conversion method and protocol conversion equipment
JP3017983B2 (ja) * 1997-11-19 2000-03-13 株式会社ケンウッド 同期捕捉回路
JP3642180B2 (ja) * 1998-04-24 2005-04-27 三菱電機株式会社 クロック再生装置
SG71835A1 (en) * 1998-09-07 2000-04-18 Victor Company Of Japan A dejittering and clock recovery technique for real-time audio/visual network applications
DE69938094T2 (de) * 1998-11-30 2009-02-05 Matsushita Electric Industries Co. Ltd., Kadoma Paketwiederübertragungskontrolle mit Prioritätsinformationen
JP2000173181A (ja) * 1998-12-04 2000-06-23 Sony Corp データ記録装置及び出力装置、データ出力システム、データ記録方法及び出力方法、並びにデータ記録及び出力方法
US20060262813A1 (en) * 1998-12-18 2006-11-23 Digital Networks North America, Inc. Multi-channel video pump
US6493832B1 (en) * 1999-03-17 2002-12-10 Sony Corporation Communication apparatus which handles a time stamp
JP4081936B2 (ja) * 1999-03-17 2008-04-30 ソニー株式会社 通信装置、通信方法、および記録媒体
US6792615B1 (en) * 1999-05-19 2004-09-14 New Horizons Telecasting, Inc. Encapsulated, streaming media automation and distribution system
JP4271787B2 (ja) * 1999-07-29 2009-06-03 日本電信電話株式会社 通信システム
JP4193297B2 (ja) * 1999-08-04 2008-12-10 ソニー株式会社 通信装置および方法、通信システム、並びに記録媒体
JP4129664B2 (ja) * 1999-10-05 2008-08-06 ソニー株式会社 データ処理装置およびデータ処理方法
JP3630406B2 (ja) * 2000-07-17 2005-03-16 松下電器産業株式会社 パケット処理装置、パケット処理方法及びその記憶媒体
AU2001296586A1 (en) * 2000-10-05 2002-04-15 Provisionpoint Communications, Llc Group packet encapsulation and compression system and method
KR20020032730A (ko) * 2000-10-27 2002-05-04 구자홍 데이터 재전송 장치 및 그 방법
US7023924B1 (en) * 2000-12-28 2006-04-04 Emc Corporation Method of pausing an MPEG coded video stream
US20040114908A1 (en) * 2001-03-29 2004-06-17 Masanori Ito Av data recording/reproducing apparatus and method for the same, and disc on which data is recorded by the av data recording/reproducing apparatus or method
US6907081B2 (en) * 2001-03-30 2005-06-14 Emc Corporation MPEG encoder control protocol for on-line encoding and MPEG data storage
US20030198223A1 (en) * 2002-04-23 2003-10-23 General Instrument Corporation Method and apparatus for identifying data streams as networks
US7061942B2 (en) * 2002-05-31 2006-06-13 Skystream Networks Inc. Apparatus for redundant multiplexing and remultiplexing of program streams and best effort data
EP1553774B1 (en) 2002-07-16 2019-03-13 Panasonic Corporation Content receiving apparatus and content transmitting apparatus
US7349386B1 (en) * 2003-02-18 2008-03-25 Cisco Technology, Inc. Method and apparatus for transporting MPEG streams on IP networks including removing null packets
US7660516B2 (en) * 2004-02-17 2010-02-09 Panasonic Corporation Recording medium, reproduction device, program, and reproduction method
JP5994653B2 (ja) * 2013-01-23 2016-09-21 マツダ株式会社 火花点火式多気筒エンジンの始動装置

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10313350A (ja) * 1997-05-13 1998-11-24 Matsushita Electric Ind Co Ltd 通信システム
JPH1188856A (ja) * 1997-09-05 1999-03-30 Hitachi Ltd 伝送プロトコル変換方式およびプロトコル変換装置を用いたｃａｔｖネットワーク接続方式
JP2000307637A (ja) * 1999-04-16 2000-11-02 Nec Corp マルチメディア端末装置及び網間接続装置
JP2001016267A (ja) * 1999-07-01 2001-01-19 Sony Corp 通信装置および方法、並びに媒体
JP2001320413A (ja) * 2000-05-02 2001-11-16 Sony Corp データ送信装置及び方法
JP2002051321A (ja) * 2000-08-04 2002-02-15 Sony Corp デジタルビデオ送信機、デジタルビデオ受信機及びデジタルビデオ送受信機
JP2002141917A (ja) * 2000-08-22 2002-05-17 Matsushita Electric Ind Co Ltd 送信装置、ソースパケット生成装置、パケット形態決定方法、媒体及び情報集合体

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7830881B2 (en) 2002-07-16 2010-11-09 Panasonic Corporation Content receiver and content transmitter
US8503471B2 (en) 2002-07-16 2013-08-06 Panasonic Corporation Content receiver and content transmitter
JP2006014153A (ja) * 2004-06-29 2006-01-12 Nec Commun Syst Ltd パケットエラー監視型ｍｐｅｇデコーダ、ｍｐｅｇ映像伝送システム及びｍｐｅｇ映像伝送方法
JP4491290B2 (ja) * 2004-06-29 2010-06-30 日本電気通信システム株式会社 パケットエラー監視型ｍｐｅｇデコーダ、ｍｐｅｇ映像伝送システム及びｍｐｅｇ映像伝送方法
JP2008511214A (ja) * 2004-08-20 2008-04-10 ソニー エレクトロニクス インク データストリーム通信装置及びデータストリーム通信方法
JP4874250B2 (ja) * 2004-08-20 2012-02-15 ソニー エレクトロニクス インク データストリーム通信装置及びデータストリーム通信方法
JP2007266875A (ja) * 2006-03-28 2007-10-11 Toshiba Corp 映像データの処理方法及び無線通信装置
WO2007119458A1 (ja) * 2006-03-28 2007-10-25 Kabushiki Kaisha Toshiba 映像データの処理方法及び無線通信装置
US8300709B2 (en) 2006-03-28 2012-10-30 Kabushiki Kaisha Toshiba Method of processing video data and wireless communication apparatus
JP2007329606A (ja) * 2006-06-07 2007-12-20 Hitachi Ltd 中継装置
JP2009081560A (ja) * 2007-09-25 2009-04-16 Kyocera Corp 署名検証方法、ストリーム生成方法、受信装置、およびストリーム送信装置
JP2009081564A (ja) * 2007-09-25 2009-04-16 Kyocera Corp 署名検証方法および受信装置
JP2009081658A (ja) * 2007-09-26 2009-04-16 Kyocera Corp 署名検証方法および受信装置

Also Published As

Publication number Publication date
JP5170166B2 (ja) 2013-03-27
JP4042745B2 (ja) 2008-02-06
CN1669320B (zh) 2011-03-23
KR100784874B1 (ko) 2007-12-14
JP2010226766A (ja) 2010-10-07
EP1553774A4 (en) 2011-05-25
JPWO2004008760A1 (ja) 2005-11-17
AU2003281136A1 (en) 2004-02-02
US20110023078A1 (en) 2011-01-27
CN1669320A (zh) 2005-09-14
EP1553774A1 (en) 2005-07-13
JP2010246146A (ja) 2010-10-28
US7830881B2 (en) 2010-11-09
KR20050025607A (ko) 2005-03-14
KR100709484B1 (ko) 2007-04-20
JP4666110B2 (ja) 2011-04-06
EP1553774B1 (en) 2019-03-13
KR20060132017A (ko) 2006-12-20
US8503471B2 (en) 2013-08-06
US20050237434A1 (en) 2005-10-27

Similar Documents

Publication Publication Date Title
JP4666110B2 (ja) コンテンツ受信機
RU2273111C2 (ru) Способ преобразования пакетизированного потока информационных сигналов в поток информационных сигналов с временными отметками и наоборот
EP0874503B1 (en) Data transmitting and/or receiving apparatus, methods and systems for preventint illegal use of data
EP0838926A2 (en) Apparatus and method for transmitting and receiving isochronous data
US8966241B2 (en) Apparatus and method for sending encrypted data to conditional access module over common interface, conditional access module and system thereof
US20040260823A1 (en) Simultaneously transporting multiple MPEG-2 transport streams
EP1705842B1 (en) Apparatus for receiving packet stream
JP4135763B2 (ja) コンテンツ受信器
JP4561822B2 (ja) コンテンツ受信機
KR100919216B1 (ko) 데이터 송신 방법, 수신 방법 및 그 장치
US6763037B1 (en) Transmitting apparatus and method, receiving apparatus and method
JPH1173729A (ja) 記録再生装置
JP3547641B2 (ja) 送信装置、受信装置及びプログラム記録媒体
KR100636107B1 (ko) 실시간 데이터 처리 장치 및 방법
MXPA01000580A (en) Method of converting a packetized stream of information signals into a stream of information signals with time stamps and vice versa
GB2490492A (en) Encrypted data format conversion for a conditional access module (CAM)

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 2004521223

Country of ref document: JP

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 NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM 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 ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR 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: 10515528

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 20038164469

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 2003741425

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 1020057000783

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 1020057000783

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 2003741425

Country of ref document: EP