JP2008136228A - Content transmitting apparatus - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To prevent the occurrence of a decoding error at a receiving party by compensating for a packet loss or jitter at both transmitting and receiving parties in a communications network such as the Internet. <P>SOLUTION: A transmitting party adds reproduction time information to each transport packet to form an extended transport packet, encapsulates the extended transport packet, adds capsule counter information, and transmits the capsule. A receiving party has a storage means, and transmits a re-send request including the capsule counter information to the transmitting party when a packet loss occurs. Also, at the receiving party, the re-sent data received overwrites data in its original storage region. At reproduction, the receiving party decodes the data after compensating for jitter referring to reproduction time information. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to a digital television broadcast receiver, a personal computer, a mobile phone, a personal digital assistant, and a mobile phone adapter.

  In recent years, transmitters and receivers having a function such as streaming for transmitting and receiving video and audio contents via a communication network have been widely used in the market.

  A conventional content transmitter will be described below. FIG. 7 is a diagram showing a configuration of a conventional content transmitter. FIG. 10 is a diagram showing transition of packet configurations in 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 the video signal with a predetermined compression method and outputs it to the subsequent stage. FIG. 7 shows a configuration according to the MPEG2 system. The output from the video encoder 51 is composed of MPEG2 transport stream packets (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 by the same compression method as the video encoder 51, and outputs MPEG2-TSP to the subsequent stage.

  The stream multiplexer 55 multiplexes the above-described three types of MPEG2-TSP 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 period of about 50 mS. The stream multiplexer 55 converts the PCR signal into MPEG2-TSP, and further multiplexes it with the multiplexed signal described above, and outputs it to the subsequent stage as an MPEG2 transport stream (hereinafter abbreviated as MPEG2-TS). This output signal is shown in S11 of FIG.

  FIG. 10 is a diagram showing the transition of packet multiplexing on the 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. VIDEO 1, VIDEO 2, VIDEO 3, AUDIO 1, AUDIO 2, and DATA 1 in S 11 are packets multiplexed by the stream multiplexer 55. Also, VIDEO1, VIDEO2, and VIDEO3 in S11 are video-encoded MPEG2-TSPs. Further, AUDIO1 and AUDIO2 in S11 are MPEG2-TSP encoded with audio. Further, DATA1 of S11 is MPEG2-TSP encoded with data. Since the PCR signal is well-known content in the MPEG2 system, description thereof is omitted.

  The scrambler 56 encrypts MPEG2-TS using a predetermined encryption method and outputs it. The example shown here is an example of the MULTI2 system.

The RTP packetizer 58 encapsulates one or more individual MPEG2-TSPs. The RTP packetizer 58 has a counter that counts the bus clock that the transmitter / receiver 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 for identifying that the encapsulated information is MPEG2-TSP to the output signal, and outputs it to the subsequent stage. To do. This output signal is shown in S12 of FIG. The RTP in S12 is a header. This time stamp is used when the receiving side corrects jitter using a bus clock when a packet arrives.

  The UDP / IP packetizer 59 stores individual RTP packets in IP datagrams for transmission to the IP communication network. Then, the UDP / IP packetizer 59 adds an IP packet header to each stored RTP packet and outputs it as an IP packet. This output signal is shown in S13 of FIG. The IP of S13 is a header in a communication protocol such as an IP header. The IP packet header is well-known content on the Internet and will not be described.

  The Ethernet (registered trademark) packetizer 60 stores the IP packet in an Ethernet (registered trademark) data area, adds an Ethernet (registered trademark) packet header and a checksum, and outputs the packet as an Ethernet (registered trademark) packet. Since the Ethernet (registered trademark) packet header and the checksum are well-known contents on the Internet, description thereof will be omitted.

  The transceiver 61 transmits an Ethernet (registered trademark) packet to the Internet network. The transceiver 61 receives the above-described reference time information and the like.

  Next, the transmission packet configuration described above will be described. FIG. 11 shows a conventional packet configuration. In FIG. 11, 10 MPEG2-TSPs are encapsulated. An 8-byte header including information for identifying the MPEG2-TSP and a time stamp used when the packet arrives is added. Then, it is converted into an RTP packet of 1892 bytes. Then, an 8-byte UDP packet header is added to the RTP packet to form a 1900-byte UDP packet. Then, a 24-byte IP packet header is added to the UDP packet to form a 1924-byte IP packet. Then, a 14-byte Ethernet (registered trademark) header and a 4-byte checksum are added to the IP packet to form a 1942-byte Ethernet (registered trademark) packet.

  In communication networks, there are many cases where the MTU, which is the maximum propagation packet unit, is limited. When the packet data size to be transmitted exceeds the MTU, the packet is often divided in the communication network. Such processing is called a fragment on the Internet.

  In this conventional example, the MTU in the Ethernet (registered trademark) communication network is 1500 bytes. On the other hand, since the data size of the data area of the Ethernet (registered trademark) packet exceeds the MTU, fragmentation in the communication network cannot be prevented. Therefore, a packet with lost header information may occur. For this reason, it is difficult to compensate for packet loss and jitter occurring after fragmentation on the receiving side.

  Next, a conventional example on the receiving side will be described. FIG. 8 is a diagram showing a configuration of a conventional content receiver. FIG. 9 is a flowchart showing an operation from reception of a packet to decoding.

  The receiver 71 receives an Ethernet (registered trademark) packet from a communication network such as the Internet network and outputs it to the subsequent stage. This Ethernet (registered trademark) packet is shown in FIG. The Ethernet (registered trademark) packet processor 72 performs Ethernet (registered trademark) protocol processing on the Ethernet (registered trademark) packet for the Ethernet (registered trademark) packet processor 72, and outputs a UDP / IP packet to the subsequent stage. This process is shown in STEP 91 of FIG. The output signal is shown in S14 of FIG.

  S14 in FIG. 10 indicates that jitter and packet loss have occurred in the received UDP / IP packet as a result of transmission / reception of the received UDP / IP packet via the Internet network. That is, the packet including VIDEO1 and DATA1 has a delay larger than the steady delay. The packet including VIDEO3 and AUDIO2 has a delay smaller than a steady delay.

  Here, the jitter and packet loss of the Internet will be described with reference to FIG. There is a steady delay between the sending side and the receiving side in the Internet network. Ideally, all packets are transmitted with that constant delay. In this case, no jitter or packet loss occurs. However, in an actual Internet network, a different route is assigned to the packet, the packet cannot be transmitted during the valid time of the packet, the packet is deleted at the gateway, the packet is retransmitted, etc. Loss occurs. In the description of S14, the limited on-paper jitter is described in an easy-to-understand manner by expressing the steady delay as zero. Specifically, since the packet including VIDEO1 and DATA1 has a delay larger than the steady delay, it is written later (like delayed) than S13. A packet including VIDEO3 and AUDIO2 has a delay smaller than a steady delay, and therefore is written earlier (as if advanced) than S13.

  A packet including VIDEO2 and AUDIO1 has a packet loss. The UDP / IP packet processing unit 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.

  Since the above Ethernet (registered trademark) and UDP / IP protocol processing is well known on the Internet, description thereof is omitted.

  These communication protocols include information indicating the protocol processing method of the data body in each header. The processing methods of various protocols are standardized, and the content receiver can be provided with the processing methods in advance. Therefore, the content receiver can perform protocol processing of the data body after deleting the header by analyzing information indicating the protocol in the header.

  The RTP packet processor 79 acquires the header of each RTP packet from each RTP packet shown in FIG. In addition, the RTP packet processor 79 acquires information indicating the contents of the configuration data included in the header. The information indicating the content of the data is information for identifying the format type of the stored data. Here, this information is information for identifying the MPEG2-TSP described above.

The RTP packet processor 79 includes a counter that counts the bus clock reproduced by the receiver 71 using the reference time information. The RTP packet processor 79 counts the bus clock, and when the counted value matches the time stamp in the header, removes the header and outputs MPEG2-TSP to the subsequent stage (STEP 93 in FIG. 9). Then, the RTP packet processor 79 confirms whether the MPEG2-TSP is scrambled (STEP 94 in FIG. 9). The MPEG2-TSP header has information on whether the MPEG2-TSP is scrambled or not outside the scrambled range. Therefore, once the MPEG2-TSP is extracted, the information can be confirmed and descrambling can be performed. Predetermining which method to use on the receiving side and the transmitting side, or confirming and recognizing the table information to be received on the receiving side, can be used for any method. is there.

  The descrambler 74 descrambles the MPEG2-TSP with a method corresponding to the scrambling method determined on the transmission side, and outputs the descrambler. This process is shown in STEP 96 of FIG. This output signal is shown in S17 of FIG.

  The TS decoder 77 outputs MPEG2-TSP after converting it into a form that the AV decoder 78 can AV-decode (STEP 97 in FIG. 9). The AV decoder 78 AV-decodes and outputs the data input to the AV decoder 78 (STEP 98 in FIG. 9). In STEP93 of FIG. 9, when the value obtained by counting the bus clock does not match the time stamp in the header, the TS decoder 77 verifies the difference (STEP95 of FIG. 9). If the difference is within a range that can be compensated by a buffer inside the reproduction 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).

  However, with the configuration as described above, the packet loss that occurs in the communication network cannot be compensated in real time on the receiving side, and if a packet loss occurs, a decoding error occurs.

  Also, the RTP time stamp for jitter correction is generated by counting the bus clock unrelated to content encoding and decoding. In addition, the reference time information used for generating the bus clock does not have sufficient accuracy for the jitter accuracy required for decoding. Further, this reference time information is affected by jitter of the communication network. For these reasons, jitter compensation accuracy at the time of decoding on the receiving side may be insufficient, resulting in a decoding error.

  Further, since the data size of the data area of the communication packet exceeds the MTU in the communication network and fragmentation in the communication network cannot be prevented, header information is lost. As a result, it is difficult to compensate for packet loss and jitter generated after fragmentation on the receiving side.

  The present invention provides a receiver that receives and reproduces content formed by a stream composed of compressed transport packets from the transmission side, and stores the content after receiving the content, and the content stored in the storage And reproducing means for reproducing. If each transport packet forming the content is an extended transport packet having playback time instruction information generated using the system clock of the transport packet, the playback means stores the stored individual extended transport packet. Is reproduced at the time determined from the reproduction time instruction information.

  Further, the present invention provides a transmitter for transmitting content formed by a stream composed of compressed transport packets, wherein the receiving side uses the system clock of the transport packet from the storage means to transmit the content. Reproduction time instruction information generating means for generating reproduction time instruction information for indicating a reproduction time is provided. The transmission means transmits an extended transport packet in which reproduction time instruction information is added to each transport packet to be transmitted.

  As described above, according to 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 decoding error when a packet loss occurs. It is useful for a television broadcast receiver, a personal computer, a mobile phone, a personal digital assistant, and a mobile phone adapter.

  Further, according to the content transmitter of the present invention, the data can be efficiently stored in the storage device on the receiving side while ignoring the arrival time when storing the data. Further, at the time of reproduction, reproduction can be performed with the accuracy required by the decoder using a time stamp indicating the time to be output to the decoder. This can prevent a decoding error when the jitter compensation accuracy is insufficient for decoding, and is useful for digital television broadcast receivers, personal computers, mobile phones, portable information terminals, and mobile phone adapters. .

(Embodiment 1)
FIG. 1 is a diagram showing a configuration of a content transmitter according to the first embodiment. FIG. 5 is a diagram showing transition of packet configurations in the content transmitter and the content receiver according to the first embodiment. FIG. 6 is a diagram showing a packet structure according to the first embodiment.

  In FIG. 1, 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 it to the subsequent stage. In this embodiment, the MPEG2 system is shown as an example, and the output signal output from the encoder 1 is composed of MPEG2-TSP. The system clock generator 4 generates a 27 MHz clock. The system clock used when the video encoder 1 encodes the video signal is this 27 MHz clock. The audio encoder 2 encodes the audio signal with the same compression method as the video encoder 1 and outputs MPEG2-TSP to the subsequent stage.

  The data encoder 3 encodes data such as data broadcast and EPG by the same compression method as the video encoder 1, 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 regenerating the system clock on the receiving side using a counter that counts the system clock.

  In the MPEG transport system, PCR signals are generated with a period of about 50 mS. The stream multiplexer 4 converts the PCR signal into MPEG2-TSP, and further multiplexes it with the multiplexed signal described above, and outputs it as MPEG2-TS. This output signal is shown in S1 of FIG.

  FIG. 5 is a diagram showing the transition of packet 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. VIDEO 1, VIDEO 2, VIDEO 3, AUDIO 1, AUDIO 2, and DATA 1 in S 5 are packets multiplexed by the stream multiplexer 5. Also, VIDEO1, VIDEO2, and VIDEO3 of S1 are MPEG2-TSP that is video-encoded. Also, AUDIO1 and AUDIO2 of S1 are MPEG2-TSP encoded with audio. DATA1 of S1 is data-encoded MPEG2-TSP. Since the PCR signal is well-known content in the MPEG2 system, description thereof is omitted.

The scrambler 6 encrypts MPEG2-TS using a predetermined encryption method and outputs it. The example shown here is an example of the MULTI2 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 as a time stamp in the header, adds the header to each MPEG2-TS (scrambled in this example), and outputs it as an extended TS packet to the subsequent stage. This output signal is shown in S2 of FIG. 5 indicates a header including a time stamp. On the receiving side, this time stamp is not used to obtain the system clock. The reception side ignores the packet generation timing on the transmission side and accumulates the packets in the accumulation device. Then, the receiving side uses this time stamp in order to obtain the packet generation timing on the transmitting side (to reproduce MPEG2-TS) when reproducing the accumulated packet.

  The counter and the counter that generates the PCR signal are synchronized because they use the same system clock.

  On the other hand, there may be a case where synchronization cannot be established between this counter and the receiving counter. Therefore, in order to secure the time for reproduction on the reception side, 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 reception side described later are determined in advance. Then, the number of bits of this counter is set so that all extended TS packets to be transmitted can be accumulated at the time that the counter makes a round. Note that, in the example in which the extended TS packet that once forms the content is stored once on the receiving side as in the present embodiment and played back, the storage device size is sufficiently secured, so playback on the receiving side. The problem of not being able to secure the time to perform does not occur.

  In addition, when adding a time stamp, this counter is initialized at a predetermined timing in accordance with the count value of the PCR signal so as to be synchronized with the count value used for generating the PCR signal, and then time stamped. . Alternatively, the counter is initialized after a predetermined offset time and then time-stamped. In this way, the system clock recovery counter by PCR can be used as a counter for MPEG2-TS playback on the receiving side. 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. This is because the carry-over process on the receiving side can be simplified.

  The super encapsulator 8 encapsulates one or more individual extended TS packets. In addition, 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 added to the output signal. And output to the subsequent stage as a super capsule. This super capsule is shown in S3 of FIG. Further, CH in FIG. 5 indicates a header. This capsule counter value is for confirming the continuity of the super capsule on the receiving side. Then, every time the super encapsulator 8 outputs a super capsule, the super encapsulator 8 increments the capsule counter value.

In FIG. 5, there are two extended TS packets encapsulated, but this is merely an example, and the number of extended TS packets is not limited in this embodiment. The information in the additional header in the supercapsule is intended to store the content of the encapsulated data and information for confirming continuity on the receiving side, and is not limited to the format described above. . For example, information on the number of extended TS packets may be included with the capsule counter value as the count value of the extended TS packets. Alternatively, the packet length of the extended TS packet and the number of extended TS packets may be the total encapsulated data length. In addition, the super capsule machine 8 outputs the super capsule to the storage buffer 15 together with the output of the super capsule to the subsequent stage.

  Accumulation control in the accumulation buffer 15 is performed by the microcomputer 14 using a ring buffer method. The microcomputer 14 manages the area for storing the super capsules in the accumulation buffer 15 and the header information of each super capsule. The retransmission command detector 13 detects the retransmission command output from the receiver 12. At the time of super capsule retransmission control, the retransmission command detector 13 receives information (in this example, at least a capsule counter value) for specifying a super capsule that needs to be retransmitted included in the retransmission command and information for instructing retransmission. Output to the microcomputer 14.

  The microcomputer 14 reads the super capsule corresponding to the capsule counter value from the accumulation buffer 15. Thereafter, the microcomputer 14 controls the output of the UDP / IP packetizer 9 in order to retransmit the super capsule. In this case, information indicating a retransmission packet may be further added to the header of the super capsule and output. Note that the count range of the capsule counter value is the number of bits that can cover at least twice the maximum delay time in the communication network to transmit (the delay from the supercapsule transmission until the retransmission command reception) with respect to the transmission speed of the supercapsule. It is desirable. Further, it is desirable that the storage buffer size is an amount capable of storing at least the super capsule for the count range of the capsule counter. The format of the retransmission command may be decided in advance with the receiving side. In this embodiment, the format of the retransmission command is not particularly limited.

  The UDP / IP packetizer 9 stores each super capsule in an IP datagram for transmission to the IP communication network, adds an IP packet header, and outputs the packet as an IP packet. This output signal is shown in S4 of FIG. The IP in S4 indicates a header in a communication protocol such as an IP header. The IP packet header is well-known content on the Internet and will not be described. In this example, an IP packet header is further stored in the UDP packet, but this is not essential. Moreover, you may store an IP packet header in another protocol, for example, a TCP packet.

  The Ethernet (registered trademark) packetizer 10 stores an IP packet input to the Ethernet (registered trademark) packetizer 10 in a data area of the Ethernet (registered trademark). The Ethernet (registered trademark) packetizer 10 adds an Ethernet (registered trademark) packet header and a checksum to the IP packet and outputs the packet as an Ethernet (registered trademark) packet. Since the Ethernet (registered trademark) packet header and the checksum are well-known contents on the Internet, description thereof will be omitted.

  The transmitter 11 transmits an Ethernet (registered trademark) packet to the Internet network. In the Internet network, various communication carriers operate the communication network in various ways, and the transmitter 11 and the receiver 12 correspond to these various methods. Moreover, there is no restriction | limiting in particular about the form and specification.

Next, the transmission packet configuration will be described. FIG. 6 is a diagram showing an Ethernet (registered trademark) packet configuration in the present embodiment. In FIG. 6, seven extended TS packets in which a 4-byte header including a time stamp is added to MPEG2-TSP are encapsulated. Then, an 1-byte header including an identification value for identifying an extended TS packet, a capsule counter value, an extended TS packet size, and the number of extended TS packets is added to super encapsulate 1352 bytes. Then, an 8-byte UDP packet header is added to the super capsule to form a 1356-byte UDP packet. Then, a 24-byte IP packet header is added to the UDP packet to form a 1380-byte IP packet. Then, a 14-byte Ethernet (registered trademark) header and a 4-byte checksum are added to the IP packet to form a 1398-byte Ethernet (registered trademark) packet.

  In communication networks, there are many cases where the MTU, which is the maximum propagation packet unit, is limited. When the packet data size to be transmitted exceeds the MTU, the packet is often divided in the communication network. Such processing is called a fragment on the Internet. It is difficult for the receiving side to compensate for packet loss and jitter generated after fragmentation. This is due to the loss of header information. For this reason, in this 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 (registered trademark) packet from exceeding the MTU 1500 bytes in the Ethernet (registered trademark) communication network.

  The data size of MPEG2-TSP is fixed at 188 bytes according to the encoder specifications. Therefore, the data size of the extended TS packet is 192 bytes. The maximum number of extended transport packets that can be stored in the super capsule while satisfying MTU 1500 bytes in the Ethernet (registered trademark) communication network is seven.

  In this way, by setting the number of extended TS packets stored in the super capsule according to the MTU of the communication network, fragmentation in the communication network is prevented. Further, by adding the above-described capsule count value and providing a retransmission function, it is possible to provide packet loss compensation to the receiving side.

  The communication network is not limited to the Internet using Ethernet (registered trademark). For example, a USB may be used, and a wireless communication network such as a mobile phone may be used. Further, the MTU can also correspond to values corresponding to them. The compression method is not limited to MPEG2. For example, MPEG4 or other methods may be used.

  Next, an example of the receiving side in the first embodiment will be described. FIG. 2 is a diagram showing the configuration of the content receiver in the first embodiment. FIG. 3 is a flowchart showing an operation example from reception to accumulation of individual packets. FIG. 4 is a flowchart showing the operation when reproducing after storage.

  In FIG. 2, a microcomputer 29 controls each part of the content receiver. The receiver 21 receives and outputs the Ethernet (registered trademark) packet shown in FIG. 6 from a communication network such as the Internet network. In the Internet network, various communication carriers operate the communication network by various methods, and the receiver 21 and the transmitter 31 described later correspond to these methods. Moreover, there is no restriction | limiting in particular about the form and specification. The communication network is not limited to the Internet using Ethernet (registered trademark), USB may be used, or a wireless communication network such as a mobile phone may be used.

  The Ethernet (registered trademark) packet processor 22 performs an Ethernet (registered trademark) protocol process on the Ethernet (registered trademark) packet for the Ethernet (registered trademark) packet processor 22 and outputs a UDP / IP packet (this processing is performed). This is shown in STEP 51 of Fig. 3. Also, this output signal is shown in S5 of Fig. 5).

  In S5 of FIG. 5, it means that the received UDP / IP packet has jitter and packet loss as a result of passing through the Internet network. That is, the packet including VIDEO1 and DATA1 has a delay larger than the steady delay. A packet including VIDEO3 and AUDIO2 has a delay smaller than a steady delay. Further, a packet including VIDEO2 and AUDIO1 is once lost and retransmitted later.

  Here, jitter and packet loss in the case of the Internet will be described with reference to FIG. There is a steady delay between the sending side and the receiving side in the Internet network. Ideally, all packets are transmitted with a constant delay, in which case no jitter or packet loss occurs. However, in an actual Internet network, jitter or packet loss occurs because packets are assigned different routes, packets cannot be transmitted during the effective time of packets, and packets are deleted at the gateway, packets are retransmitted, etc. To do. In the description of S5, the limited on-paper jitter is described in an easy-to-understand manner by expressing the steady delay as zero. Specifically, since the packet including VIDEO1 and DATA1 has a delay larger than the steady delay, it is written later (like delayed) than S4. A packet including VIDEO3 and AUDIO2 has a delay smaller than a steady delay, and is written earlier (as if it is advanced) than S4. Further, it is described that a packet including VIDEO2 and AUDIO1 is once lost and retransmitted later.

  The UDP / IP packet processing unit 23 shown in FIG. 2 performs UDP / IP protocol processing on the UDP / IP packet and outputs a supercapsule (this processing is shown in STEP 52 of FIG. 3. This output signal is also shown in FIG. 5 shown in S6).

  Since the above Ethernet (registered trademark) and UDP / IP protocol processing is well known on the Internet, description thereof is omitted. Further, Ethernet (registered trademark) packet and UDP packet processing is not limited to the contents described here, but depends on the type of received packet and the specifications of the communication network. In addition, other communication protocol processing may be performed.

  Each of these communication protocols includes information indicating the protocol processing method of the data body in each header. The processing methods of various protocols are standardized, and the content receiver can be provided with the processing methods in advance. Therefore, the content receiver can perform protocol processing of the data body after deleting the header by analyzing information indicating the protocol in the header.

  The capsule processor 24 acquires the header of each super capsule from each super capsule shown in FIG. Further, the capsule processor 24 outputs information indicating the contents 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 identifying the extended TS packet described above). Further, the information indicating the contents of the data includes information indicating the packet length of the extended TS packet in the capsule and the number of extended TS packets. The information indicating the packet length of the extended TS packet and the number of extended TS packets may be the total data length encapsulated.

The microcomputer 29 interprets the information indicating the contents of the given data and recognizes that the encapsulated data is an extended TS packet (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. Further, the microcomputer 29 prepares the storage controller 28 for setting the storage packet size and initializing the address when storing each extended TS packet (STEP 50 in FIG. 3). These preparations may be performed when the first super capsule is input or when the information indicating the contents of the data is detected and changed.

In addition, the capsule processor 24 monitors the capsule counter included in the header to confirm continuity (STEP 54 in FIG. 3). The capsule processor 24 detects the capsule counter value in each super capsule and checks the discontinuity point. If the capsule processor 24 detects the discontinuity point, the discontinuity is verified by the transition of the capsule counter (STEP 64 in FIG. 3).

If this discontinuity is discontinuity in the direction in which the capsule counter value is the same or decreasing, 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. The super capsule until the discontinuity is eliminated is deleted (STEP 65 in FIG. 3).

  If this discontinuity is discontinuity in the direction in which the capsule counter value increases, the capsule processor 24 does not delete the super capsule corresponding to the discontinuity. Then, the capsule processor 24 notifies the microcomputer 29 that the discontinuity point has been detected, and outputs a capsule counter value corresponding to the super capsule that the capsule processor 24 could not receive to the microcomputer 29.

  In addition, the capsule processor 24 generates a dummy super capsule having a dummy header composed of dummy extended TS packets. Then, the capsule processor 24 inserts this dummy supercapsule into the temporal 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.

  In response to the notification from the capsule processor 24, the microcomputer 29 outputs a retransmission command for instructing retransmission of the super capsule. At this time, the microcomputer 29 generates this retransmission command by using the capsule counter value corresponding to the super capsule that the capsule processor 24 could not receive (STEP 67 in FIG. 3). The transmitter 31 transmits a retransmission command to the transmission side via a communication network such as the Internet network using Ethernet (registered trademark).

  Since the super capsule retransmitted by the transmitting side includes information indicating that it is retransmitted in the header, the capsule processor 24 can detect it. Therefore, the capsule processor 24 excludes this from the above-described discontinuity verification target and outputs it as it is to the subsequent stage. (STEP 54 in FIG. 3).

  The microcomputer 29 may not control the retransmission command transmission immediately after receiving the discontinuous notification from the capsule processor 24. The microcomputer 29 may control retransmission command transmission when the corresponding supercapsule is not received for a predetermined time after instructing the capsule processor 24 to wait for reception of the supercapsule that could not be detected. is there. If reception is possible within a predetermined time after instructing reception standby, the capsule processor 24 adds information indicating a retransmission packet in a predetermined header and outputs the information to the subsequent stage. This is because the subsequent processing is performed in the same manner as the retransmission packet. In order to avoid malfunction, it is desirable that the waiting time is shorter than the time required for the capsule counter value to make a round and longer than the maximum delay time of packet arrival in the communication network. Further, the confirmation of discontinuity in STEP 54 and STEP 64 and the processing control after the confirmation are performed by either the capsule processor 24 or the software processing in the microcomputer 29.

  Next, the capsule processor 24 separates and outputs the extended TS packet encapsulated under the control of the microcomputer 29. Here, in consideration of the case where the MPEG2-TSP included in the extended TS packet is scrambled or the case of the retransmission packet, the header including each MPEG2-TSP and the time stamp is output separately. The microcomputer 29 confirms whether the MPEG2-TSP is scrambled (STEP 55 in FIG. 3).

The MPEG2-TSP header has information on whether or not it is scrambled outside the scrambled range. Therefore, the microcomputer 29 can take out the MPEG2-TSP once and confirm the information, and can perform descrambling processing on the scrambled range. Decide which method to use on the receiving side and the sending side in advance, or check and recognize the table information to be received on the receiving side. .

  The descrambler 25 descrambles the MPEG2-TSP input to the descrambler 25 using a method corresponding to scrambling on the transmission side, and outputs the descrambler to the subsequent stage. On the other hand, the header including the time stamp is delayed by the processing time of the descrambler 25 in the time stamp buffer 26 to obtain time synchronization with the MPEG2-TSP, and then output to the subsequent stage (STEP 56 in FIG. 3).

  Further, the microcomputer 29 also confirms whether the packet is a retransmission packet (STEP 68 in FIG. 3). The retransmission packet has information indicating the retransmission packet in the header. Therefore, the microcomputer 29 confirms whether or not the packet is a retransmission packet. In the case of a retransmission packet, a header to which information indicating that the packet is a retransmission packet and a capsule counter value are added in addition to the time stamp is generated and output to the time stamp buffer 26 (STEP 69 in FIG. 3).

  The extended TS regenerator 27 combines the MPEG2-TS and the header to reproduce and output an extended TS packet. This process is shown in STEP 57 of FIG. The output signal is shown in S7 of FIG. The accumulation controller 28 confirms whether it is an extended TS packet reacquired due to a delay or loss in the communication network based on the header information (STEP 58 in FIG. 3). If it is not a retransmitted packet, extended TS packets are sequentially written into the managed area on the storage device 32 under the control of the microcomputer 29 (STEP 59 in FIG. 3). If it is a retransmission packet, in STEP 66, a dummy extended TS packet and a dummy super capsule are generated. Then, the re-acquired extended TS packet is overwritten on the corresponding dummy extended TS packet stored in advance (STEP 60 in FIG. 3).

  The retransmitted extended TS packet includes a capsule counter value. The microcomputer 29 manages the capsule counter value and the address of the storage device 32. Therefore, this overwrite control accumulates the retransmitted extended TS packet in the original storage area (the area where the dummy extended TS packet is temporarily stored and secured) to compensate for the continuity in the storage device 32. (S8 in FIG. 5).

  In S8 of FIG. 5, the retransmitted VIDEO2 and AUDIO1 extended TS packets are stored in their original locations. Further, since the storage device 32 stores the arrival time and the transmission time on the transmission side without referring to it, each extended TS packet can be stored efficiently.

  The storage device 32 may be any storage medium such as an HDD or a DVD, or a semiconductor memory. Further, if retransmission control is simplified and only jitter compensation is controlled, the capacity required for the storage device 32 is reduced to a range in which all extended TS packets received during a round of a counter described later can be stored.

  In STEP 53 of FIG. 3, the microcomputer 29 confirms that no extended TS packet is stored. For example, if this is normal MPEG2-TSP, it is confirmed in the same manner whether or not it is scrambled (STEP 61 in FIG. 3). If it is scrambled, it is descrambled by the descrambler 25 (STEP 62 in FIG. 3). Then, a header including a time stamp is generated and added by the extended TS player 27 to be output as an extended TS packet (STEP 63 in FIG. 3), and similarly stored in the storage device 32. Also in this case, the subsequent reproduction processing can be made common. In this case, however, jitter compensation and packet loss compensation are the same as in the conventional example.

  Next, explanation will be given at the time of reproduction. The reproduction controller 33 includes a counter that counts the system clock. The reproduction controller 33 controls the frequency of the system clock so that the result of comparing the count value of this counter and the PCR signal output from the TS decoder 34 becomes equal. That is, the system clock can be reproduced using the existing MPEG transport system as it is. Therefore, at the time of reproduction, the specifications of the MPEG transport system can be easily satisfied using the existing technology. Further, the reproduction controller 33 sequentially reads out the extended TS packets stored in the storage device 32 in synchronization with the system clock under the control of the microcomputer 29 (STEP 71 in FIG. 4). Then, the playback controller 33 removes the header including the time stamp at a timing when each time stamp matches the count value of the counter described above with a predetermined offset value (STEP 72 in FIG. 4). Then, the playback controller 33 outputs each MPEG2-TSP to the subsequent stage. This process is shown in STEP 73 of FIG. The output signal is shown in S9 of FIG.

  At this stage, the MPEG2-TS on the transmission side is reproduced, and the jitter generated in the communication network is compensated. On the transmission side, the counter for counting the PCR signal and the counter for counting the time stamp are synchronized. 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 AV-decode and outputs. The AV decoder 35 AV-decodes the data input to the AV decoder 35 and outputs it. If the time stamp and the system clock counter value do not match in STEP 72, the playback controller 33 verifies the difference (STEP 75 in FIG. 4). If the difference is within a range where jitter can be compensated by a buffer (not shown) in the playback controller 33, the extended TS packet is made to wait on the buffer. If the difference exceeds the range in which the jitter can be compensated by the buffer in the playback controller, control is performed to discard the corresponding extended TS packet (STEP 76 in FIG. 4).

  Next, the received packet configuration will be described. FIG. 6 shows an example in which the number of extended TS packets in the supercapsule receives seven Ethernet (registered trademark) packets (1398 bytes).

  The data area has a 1356-byte UDP / IP packet, and the data area has a 1352-byte supercapsule. In the super capsule, seven extended TS packets in which a 4-byte header including a time stamp is added to MPEG2-TSP are encapsulated. The super capsule has an 8-byte header including an identification value for identifying an extended TS packet, a capsule counter value, an extended TS packet size, and the number of extended TS packets.

  In communication networks, there are many cases where the MTU, which is the maximum propagation packet unit, is limited. When the packet data size exceeds the MTU, the packet is often divided in the communication network.

  Such processing is called a fragment on the Internet. It is difficult for the receiving side alone to compensate for packet loss and jitter generated after fragmentation. Therefore, in this 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 (registered trademark) packet from exceeding the MTU 1500 bytes in the Ethernet (registered trademark) communication network.

The data size of MPEG2-TSP is fixed at 188 bytes according to the encoder specifications. Therefore, the data size of the extended TS packet is 192 bytes, and the maximum number of extended transport packets that can be stored in the super capsule while satisfying MTU 1500 bytes in the Ethernet (registered trademark) communication network is seven.

  By preventing fragmentation in this way, as described above, when packet loss occurs in the communication network, a retransmission of the lost packet is requested using the capsule count value added to each super capsule. . Then, when the retransmitted packet is stored in the storage device, the packet loss is compensated using the capsule count value.

  Further, by using a reproduction time stamp included in each extended TS packet at the time of reproduction, the jitter generated in the communication network is compensated accurately with the accuracy of the system clock. Further, as described above, the compensation is reliably and efficiently performed by the cooperative 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 (registered trademark). For example, a wireless communication network such as a USB or a mobile phone may be used. The compression method is not limited to MPEG2. For example, MPEG4 or other methods may be used.

  The playback controller 33 may output MPEG2-TSP from the content receiver to an AV decoder connected on the bus. In this case, the regeneration controller 33 is connected to an external output interface such as an IEEE 1394 interface (not shown). MPEG2-TSP is stored in an isochronous packet defined by the interface.

  The TS decoder 34 may be connected to an external output interface such as an IEEE 1394 interface (not shown), and the output of the TS decoder 34 may be transmitted to an external AV decoder. In this case, the external output interface stores and outputs MPEG2-TSP in an isochronous packet determined by the interface standard.

(Embodiment 2)
FIG. 12 is a diagram showing 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 packet configuration in the content receiver according to the second embodiment. FIG. 15 and FIG. 16 are diagrams showing a configuration of a packet transmitted by the IEEE 1394 interface according to the second embodiment.

  In FIG. 12, since the configuration and operation until the storage device 32 stores packets received from the Internet network are the same as those in the first embodiment, description thereof is omitted. The read controller 36 reads the extended TS packet stored in the storage device 32 according to an instruction from the microcomputer 29 in synchronization with a clock having a predetermined frequency generated by the extended TS packet read clock generator 37. In that case, as shown by S10 in FIG. 14, a predetermined time interval is inserted between the extended TS packets 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 packet after the time interval is inserted is equal to or higher than the bit rate at the time of transmitting the extended TS packet of the content transmitter.

The IEEE 1394 interface 38 conforms to the IEEE 1394 standard. Further, the IEEE 1394 interface 38 outputs the extended TS packet input to the IEEE 1394 interface 38 in the isochronous transfer mode (S11 in FIG. 14).
). In S11, ISO is a header added by the IEEE1394 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 start signal, and a data enable signal as in the case of MPEG2-TS. Further, when transmitting an extended TS packet, extended TS packet information is set in the IEEE 1394 interface 38 by a microcomputer. This will be described.

  FIG. 13 is a diagram showing the configuration of the IEEE 1394 interface 38. A stream of extended TS packets is input to the MPEG2 interface 41. The DTCP encryption circuit 42 performs encryption for copyright protection on the extended TS packet output from the MPEG2 interface 41 in accordance with the DTCP (Digital Transmission Content Protection) standard, and outputs the result. The header addition circuit 43 adds a header to the packet subjected to DTCP encryption and outputs the packet. This header is necessary for isochronous transfer.

  Information specifying the format of the extended TS packet is input to the packet 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 information for identifying the data format of the packet to be isochronously transferred as an extended TS packet at a predetermined position of the header.

  Information specifying the data size of the extended TS packet is input to the packet data size information adding circuit 45 from the microcomputer 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, isochronous packet size information for storing extended TS packets is input to the packet data size information adding circuit 45 from the microcomputer via the host interface 46. Then, the packet data size information adding circuit 45 performs a process of writing information on the data size of the packet to be isochronously transferred at a predetermined position of the header.

  Here, an additional header for the extended TS packet will be described. FIG. 15 and FIG. 16 are different formats from IEC61883-4 defined for MPEG2 packets. FIG. 15 is a diagram showing an example in which only an isochronous header is added to the extended TS packet. In this case, only the packet data size is written in the data length area shown in FIG. If the data size of the extended TS packet is 192 bytes, data indicating 588 bytes obtained by adding 576 bytes multiplied by 3 to 192 and 12 bytes of the isochronous header and the data CRC is written in the data length area of FIG. .

  FIG. 16 is a diagram illustrating an example in which an isochronous header and a common header are included in an extended TS packet. Here, the packet data size is written in the data length area of the isochronous header of 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, 588 bytes, which is 3 times the number obtained by adding 4 and 192 in the Reserved area, 16 bytes for the isochronous header, common header, data CRC, and 4 bytes for Reserved. The area 608 shown in FIG. 16 is written with data indicating 608 bytes obtained by adding. The Reserved area is an area for future expansion. The information for identifying the extended TS packet is data determined in advance as the content transmission side within a range excluding any data currently in operation.

FIGS. 15 and 16 are examples of isochronous packets in which three extended TS packets are stored, but the number of packets is not limited to three. For example, the number of packets may be 4, 2, or 1. The data size of the extended TS packet is an example of 192 bytes, but is not particularly limited. For example, the data size of the extended TS packet may be 196 bytes.

  The IEEE 1394 isochronous packet transmission circuit 47 shown in FIG. 13 includes a circuit that implements a data link layer and physical layer protocol in accordance with the IEEE 1394 standard. The IEEE 1394 isochronous packet transmission circuit 47 transmits a packet to which the header input to the IEEE 1394 isochronous packet transmission circuit 47 is added to the 1394 bus.

  As described above, in the second embodiment, an extended TS packet can be transmitted via the IEEE 1394 interface. Further, in the content receiver according to the second embodiment, the effect described in the first embodiment is realized even if a TS decoder (not shown) and an AV decoder (not shown) are separately connected on the 1394 bus. it can.

  As described above, according to 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 decoding error when a packet loss occurs. It is useful for a television broadcast receiver, a personal computer, a mobile phone, a personal digital assistant, and a mobile phone adapter.

  Further, according to the content transmitter of the present invention, the data can be efficiently stored in the storage device on the receiving side while ignoring the arrival time when storing the data. Further, at the time of reproduction, reproduction can be performed with the accuracy required by the decoder using a time stamp indicating the time to be output to the decoder. This can prevent a decoding error when the jitter compensation accuracy is insufficient for decoding, and is useful for digital television broadcast receivers, personal computers, mobile phones, portable information terminals, and mobile phone adapters. .

Block diagram of a content transmitter according to Embodiment 1 of the present invention Block diagram of a content receiver according to Embodiment 1 of the present invention First operation flowchart in the content receiver according to the first embodiment of the present invention. Second operation flowchart in the content receiver according to the first embodiment of the present invention. The figure which shows the transition of the packet structure by Embodiment 1 of this invention. The figure which shows the Ethernet (trademark) packet structure by Embodiment 1 of this invention. Block diagram of a conventional content transmitter Block diagram of a conventional content receiver Operation flowchart of conventional content receiver Figure showing the transition of the conventional packet structure Diagram showing conventional packet configuration Block diagram of a content receiver according to Embodiment 2 of the present invention Block diagram of the IEEE 1394 interface of the content receiver according to the second embodiment of the present invention. The figure which shows the packet structure transition by Embodiment 2 of this invention. The figure which shows the 1st IEEE1394 packet structure by Embodiment 2 of this invention. The figure which shows the 2nd IEEE1394 packet structure by Embodiment 2 of this invention.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Video encoder 2 Audio encoder 3 Data encoder 4 System clock generator 5 Stream multiplexer 6 Scrambler 7 Time stamp adder 8 Super encapsulator 9 UDP / IP packetizer 10 Ethernet (registered trademark) packetizer 11 Transmitter DESCRIPTION OF SYMBOLS 12 Receiver 13 Retransmission command detector 14 Microcomputer 15 Accumulation buffer 21 Receiver 22 Ethernet (trademark) packet processor 23 UDP / IP packet processor 24 Capsule processor 25 Descrambler 26 Timestamp buffer 27 Extended TS regenerator 28 Accumulation Controller 29 Microcomputer 31 Transmitter 32 Storage device 33 Playback controller 34 TS decoder 35 AV decoder 36 Read controller 37 Extended TS packet read clock generation 38 IEEE 1394 interface 41 MPEG2 interface 42 DTCP encryption circuit 43 Header addition circuit 44 Packet format information addition circuit 45 Packet data size information addition circuit 46 Host interface 47 IEEE 1394 packet transmission circuit

Claims (1)

In a transmitter for transmitting content formed by a stream composed of compressed transport packets, a transmission means for transmitting the content, and a reception side using the system clock of the transport packet to reproduce from the storage means Reproduction time instruction information generating means for generating reproduction time instruction information for indicating a time, and a content transmitter for transmitting an extended transport packet in which the reproduction time instruction information is added to each transport packet to be transmitted.

Images