Packet schedule timestamp for a compressed bitstream

Abstract

A packet schedule timestamp is provided. A schedule information packet includes a packet schedule timestamp that represents the relative timing of data packets in a particular bitstream of a multiplexed transport stream. The schedule information packet further provides information about the timing of packets within a bitstream or multiple bitstreams before actual packet arrivals. Look-ahead processing techniques are provided to improve the efficiency of compressed bitstream storage and delivery, such as program stream to transport stream conversion and statistical multiplexing. The packet schedule information can be inserted into the bitstream it describes for transmission or storage with it. Other features, such as timing reconstruction, are also provided. The packet schedule information can be used to reconstruct the timing of the transport packets to their original state.

Description

RELATED APPLICATION[0001]The present application is divisional of U.S. patent application Ser. No. 10 / 339,742 that, in turn, claims priority under 35 U.S.C. §119(e) to U.S. provisional patent application Ser. No. 60 / 367,398, filed on Mar. 21, 2002, entitled “Efficient Packet Timestamping,” both of which we incorporate by reference in their entirety.TECHNICAL FIELD[0002]This invention relates generally to digital video systems and, more particularly, a packet scheduling timestamp for providing and for encoding relative packet timing information for a compressed bitstream.BACKGROUND[0003]Audio-visual information can be digitized, compressed, and converted to formats suitable for computer and digital communication network transport and storage. Digital video compression techniques are widely recognized as an effective way to reduce the amount of data required to represent a video signal. Typical compression and delivery standards, such as Moving Picture Experts Group (MPEG) have an adj...

AI Technical Summary

Benefits of technology

[0017]In a still further embodiment, a digital video format converter is provided. One embodiment includes an MPEG program stream to transport stream converter. A program stream is designed for use in a reliable network and storage environment, while a transport stream is intended primarily for real-time and possibly unreliable transmission of compressed data over networks. A VBR program stream can be converted to a transport stream including SIPs to preserve the relative packet timing. This avoids causing buffer exceptions at a receiver decoder. The program stream can be converted to a CBR transport stream at bit rate R, which is the peak bit rate of the program stream. In one embodiment, null packets are added to preserve the packet arrival timing during conversion. An SIP generator is then used to generate SIPs for the packets of the CBR transport stream. After the timing of the packets has been characterized, the null packets are removed to produce a converted transport stream that includes packet schedule information. In another embodiment, null packets are not added, but the positions are computed or recorded. The SIP generator then uses the information about where null packets are needed to generate the appropriate SIPs. In this case, a converted transport stream can be produced without even temporarily introducing null packets in the data stream.

Problems solved by technology

One problem with delivering compressed video is ensuring proper presentation of the video signal.

Therefore, if the compressed video data is transmitted over a communication channel at a constant bit rate, the encoded video frames will arrive at the decoder in non-uniform time intervals.

A buffer exception typically includes buffer overflow or underflow conditions, which result in dropped frames or corrupted data.

Other problems such as latency are associated with extensive data buffering.

Another problem with compressed video delivery is providing decoder compliant bitstreams.

That is, variable delay in the communications system or other data transport problems can transform a bitstream that is decoder compliant at the near end of the communications channel into a non-compliant bitstream at the far end (e.g., an integrated receiver / decoder).

A further problem with delivering a decoder compliant bitstream occurs when a multiple program transport stream is demultiplexed.

When a PID stream has been extracted or delivered separately from a multiplexed transport stream, however, the packet delivery timing may be no longer the same.

Bursty delivery can cause undesirable buffer exceptions.

More generally, any transport of video 1105 may not necessarily preserve the original packet schedule either due to additional buffering or further multiplexing with other packets in a different network node or system entity.

Null packets, however, consume additional resources and introduce further content storage or delivery inefficiencies.

Quantitatively, this represents an inefficiency of about 61%.

This approach does have an additional limitation: the resulting packet format is no longer compatible with the original packet format.

Unless all network transport systems are manufactured by the same vendor or support the same packet formats, the non-standard transport stream can no longer be transported over the network.

Therefore, this approach may be useful for local storage and time reconstruction but not for interoperable long distance transport.

Images