Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
  • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
  • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
  • H04N19/164—Feedback from the receiver or from the transmission channel
  • H04N19/166—Feedback from the receiver or from the transmission channel concerning the amount of transmission errors, e.g. bit error rate [BER]
• • 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/23608—Remultiplexing multiplex streams, e.g. involving modifying time stamps or remapping the packet identifiers
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
  • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
  • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
  • H04N19/115—Selection of the code volume for a coding unit prior to coding
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
  • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
  • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
  • H04N19/124—Quantisation
  • H04N19/126—Details of normalisation or weighting functions, e.g. normalisation matrices or variable uniform quantisers
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
  • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
  • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
  • H04N19/146—Data rate or code amount at the encoder output
  • H04N19/15—Data rate or code amount at the encoder output by monitoring actual compressed data size at the memory before deciding storage at the transmission buffer
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
  • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
  • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
  • H04N19/146—Data rate or code amount at the encoder output
  • H04N19/152—Data rate or code amount at the encoder output by measuring the fullness of the transmission buffer
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
  • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
  • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
  • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
  • H04N19/176—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a block, e.g. a macroblock
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
  • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
  • H04N19/189—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the adaptation method, adaptation tool or adaptation type used for the adaptive coding
  • H04N19/196—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the adaptation method, adaptation tool or adaptation type used for the adaptive coding being specially adapted for the computation of encoding parameters, e.g. by averaging previously computed encoding parameters
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
  • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
  • H04N19/189—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the adaptation method, adaptation tool or adaptation type used for the adaptive coding
  • H04N19/196—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the adaptation method, adaptation tool or adaptation type used for the adaptive coding being specially adapted for the computation of encoding parameters, e.g. by averaging previously computed encoding parameters
  • H04N19/197—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the adaptation method, adaptation tool or adaptation type used for the adaptive coding being specially adapted for the computation of encoding parameters, e.g. by averaging previously computed encoding parameters including determination of the initial value of an encoding parameter
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
  • H04N19/40—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using video transcoding, i.e. partial or full decoding of a coded input stream followed by re-encoding of the decoded output stream
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
  • H04N19/60—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
  • H04N19/61—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding in combination with predictive coding
• • 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/2365—Multiplexing of several video streams
  • H04N21/23655—Statistical multiplexing, e.g. by controlling the encoder to alter its bitrate to optimize the bandwidth utilization

Definitions

• the present invention relates to a statistical remultiplexer for transcoding digital video signals.
• a bit rate of digital video programs that are provided, e.g., to subscriber terminals in a cable television network or the like.
• a first group of signals may be received at a headend via a satellite transmission.
• the headend operator may desire to forward selected programs to the subscribers while adding programs (e.g., commercials or other content) from a local source, such as storage media or a local live feed. Additionally, it is often necessary to provide the programs within an overall available channel bandwidth.
• the statistical remultiplexer (stat remux), or multi-channel transcoder, which handles pre-compressed video bit streams by re-compressing them at a specified bit rate, has been developed.
• processors In such systems, a number of channels of data are processed by processors arranged in parallel. Each processor typically can accommodate multiple channels of data. Although, in some cases, such as for HDTV, which require many computations, portions of data from a single channel may be allocated among multiple processors. Moreover, typically a fixed transcoding bandwidth is allocated to one or more groups of channels (stat remux groups).
• stat remux system that provides a bit rate need parameter for each channel to enable bits to be allocated for transcoding the channels in a manner that optimizes the image quality of the coded data, while still meeting the constraints of a limited throughput.
• the system should estimate the bit rate need parameter from statistical information that is derived from the bitstream, such as a frame bit count and average quantizer scale values of the original bitstream.
• the system should be compatible with MPEG-2 bitstreams.
• the system should allocate a target output frame bit count for I, P and B frames based on the coding complexity estimated from the statistical information of the original bit stream.
• the system should accommodate MPEG-2 macroblock processing within a frame, by using a macroblock bit count and quantizer scale values of the original bit stream to guide the rate control process to meet the target frame bit count at the output.
• the system should provide periodic adjustments of an allocated transcoding bit rate a number of times in a video frame.
• the system should derive quantizer scale values for transcoding macroblocks in a frame based on original, pre-transcoding quantizer scale values.
• the quantizer scale values should be adjusted as transcoding of a frame proceeds to ensure that each macroblock is allocated a minimum number of bits for transcoding.
• the present invention relates to a statistical remultiplexer for transcoding digital video signals.
• a bit rate need parameter is estimated for statistical re-multiplexing from a frame bit count and average macroblock quantizer scale values (averaged over a frame) of an original bitstream, such as an MPEG-2 bitstream.
• a lookahead of, e.g., five-frames is provided.
• the invention allocates a total available bandwidth among the transcoding channels.
• the invention allocates a target of output frame bit count for I, P and B frames based on the coding complexity estimated from the frame bit count and the average macroblock quantizer scale (averaged over each input frame) of the original bit stream.
• a macroblock bit count and quantizer scale value of the original bit stream are used to guide the rate control process to meet the target frame bit count at the output.
• the present invention provides an efficient statistical remultiplexer for processing data in a number of channels that include video data.
• transcoding of the video data is delayed while statistical information is obtained from the data.
• Bit rate need parameters for the data are determined based on the statistical information, and the video data is transcoded based on the respective bit rate need parameters following the delay.
• a transcoding bit rate for video frames at the stat remux is updated a plurality of times at successive intervals to allow a closer monitoring of the bit rate. Moreover, minimum and maximum bounds for the transcoding bit rate are updated in each interval. Thus, a portion of a frame is transcoded in a first interval, then the transcoding bit rate is updated, then a second portion of the frame is transcoded in a second interval, then the transcoding bit rate is updated again, and so forth.
• the pre-transcoding quantization scales of the macroblocks in a frame are scaled to provide corresponding new quantization scales for transcoding based on a ratio of a pre-transcoding amount of data in the frame and a target, post-transcoding amount of data for the frame.
• the quantization scales are adjusted for different portions of the frame as the portions are transcoded to ensure that a minimum amount of transcoding bandwidth is allocated to each macroblock.
• FIG. 1 illustrates a stat remux, and a data flow into and out of a quantization level processor (QLP), in accordance with the present invention.
• QLP quantization level processor
• FIG. 2 illustrates a simplified transcoder for use in accordance with the present invention.
• FIG. 3 illustrates a transcoder that performs requantization without motion compensation for use in accordance with the present invention.
• FIG. 4 illustrates an end-to-end stat remux processing delay in accordance with the present invention.
• FIG. 5 illustrates a transcoder video buffering verifier (VBN) model in accordance with the present invention.
• VBN transcoder video buffering verifier
• FIG. 6 illustrates transcoder rate timing in accordance with the present invention.
• FIG. 7 illustrates communication timing between a QLP and transcoder processing elements (TPEs) in accordance with the present invention.
• the present invention relates to a statistical remultiplexer for transcoding digital video signals.
• FIG. 1 illustrates a stat remux, and a data flow into and out of a QLP, in accordance with the present invention.
• the stat remux 100 includes a groomer 105 for receiving a number of input transport streams. Corresponding input transport packets in different video services are provided to one of a number of transcoders 110, ..., 112, or TPEs (transcoding engines). Typically, each transcoder can handle one or more video services (channels). Transcoded data is provided via a PCI bus 115 to a multiplexer (mux) 120, which assembles a corresponding output transport stream.
• Mux multiplexer
• a Kernel Processor configures the groomer 105, the TPEs 110, ..., 112, the QLP 130, and the Mux 120.
• the mux 120 is responsive to a transmission bit rate provided from a QLP 130, which has a memory 132 such as a SDRAM.
• the QLP may be implemented using a media processor, such as the MAPCA2000 (300MHz) media processor from Equator Technologies, Inc.
• the QLP 130 performs the following functions: • Allocates an available bandwidth to the output video services to optimize the video quality and determine the target frame size for each frame to be transcoded.
• the QLP communicates with the KP and TPEs via the PCI bus (32bit @ 66MHz).
• a block of memory is allocated on an SDRAM of the QLP for interprocessor communication. This memory block is "shared" by the QLP with other processors.
• Inputs to QLP 130 Configuration parameters and commands (Source: KP 140) Video and associated audio and data input packet rate information (Source: TPEs 110, ..., 112)
• Non-video (data) input packet rate information (Source: Mux 120)
• the transcoder 100 is not necessarily decoding and re-encoding the video stream, the transcoding function can emulate a full decode and re-encode.
• the rate control and stat-remux system in accordance with the invention is summarized in the following steps. Details are described in the next sections.
• Each TPE 110, ... , 112 inputs the transport stream of every video channel it is processing.
• the transport stream is then unpacketized and a video decoder buffer is emulated.
• a lookahead buffer is used by each TPE to store a number of future frames and obtain statistical information from these frames.
• the TPE computes the average quantizer scales values and the number of bits in the input frame. These parameters are used by the QLP 130 to calculate the bit rate need parameter for the input frame at a scheduled time that is at least 1.5 NTSC frame times before it is that frame's turn to be transcoded.
• a coded frame can be either one NTSC frame time (33.3ms) or 1.5 frame times (50ms). We use the longer time to make sure the transcoding rate allocation for the frame is determined before the actual transcoding begins.
• the QLP 130 performs a bandwidth allocation process to allocate a transcoding bit rate to the TPEs at periodic intervals, T q . It computes the transcoding bit rate for every video channel for each Tq interval.
• One NTSC frame period is 1/30 sec.
• the delayed value of the transcoding bit rate of the video channel becomes the transmission bit rate, and is used by the Mux 120.
• the average transcoding bit rate over the frame is used to derive an initial value of a target frame size, which is a predicted size of the frame after transcoding.
• This initial target frame size value is stored in an output frame size queue (e.g., in memory 132) of the QLP 130, and is retrieved when the associated TPE is ready to transcode the frame. Queues may be implemented by the QLP in the memory 132.
• the initial target frame size value that was previously determined is retrieved from the output frame size queue. Based on the current state (fullness) of the transcoder buffer, the maximum and minimum frame size to protect the decoder buffer from underflow or overflow are calculated for bounding the initial target frame size.
• this frame bypasses transcoding in a passthrough mode since the purpose of transcoding is to reduce the number of bits in a frame. This situation may occur when the input bitstream is already heavily compressed. When a frame is bypassed, the associated input elementary stream is re-packetized. If the number of target bits is smaller than the number of bits in the input frame, the frame is bit-reduced (transcoded). Bit reduction may be performed, e.g., either through a simplified transcoder architecture (FIG. 2) or re-quantization (FIG. 3).
• the quantizer scale for each macroblock (or group of macroblocks) for transcoding is chosen based on the number of target bits per frame, and the original quantizer scale. The condition that the output quantization scale is higher (coarser) than the input quantization scale must be met.
• the TPEs have to allocate certain slots for a PCR field in the packets they output. It is important to avoid allocating more slots than necessary since this wastes bits.
• the outgoing packets at a TPE are created and stored in memory, e.g., in a TPE FIFO buffer.
• the QLP 130 uses the target frame size to estimate the time used for transmitting the frame, and hence the time for inserting the PCRs.
• PCR slot is created at least every 0.1 second to conform to the MPEG2 system standard requirement.
• the Mux 120 reads the number of packets assigned to each channel from the TPEs 110, ..., 112 via the PCI bus 115.
• n is a design parameter for the Mux 120 and can be any positive integer.
• This packet assignment is equivalent to the transmission bit rate allocation, which is in turn a delayed version of the transcoding bit rate allocation. That is, the bit rate is converted to a number of packets to send to the Mux per Tq period.
• the Mux 120 receives a transport tick every m ticks of a 27MHz clock. If the packet to transmit contains a PCR, the Mux performs PCR correction to provide a PCR value that is properly synchronized with a master clock of the transcoder. This may achieved as described in commonly-assigned, co-pending U.S. Patent Application No. 09/667,734 to R. Nemiroff, V. Liu and S. Wu, filed on September 22, 2000, and entitled "Regeneration Of Program Clock Reference Data For Mpeg Transport Streams.”
• the transport packet(s) are sent out the Mux Processor via the PCI bus 115.
• the transport tick refers to the timing interval for outputting a transport packet.
• FIG. 2 illustrates a simplified transcoder for use in accordance with the present invention.
• the transcoder 200' provides a simplified design that reduces computations.
• the transcoder architecture 200' performs most operations in the DCT domain, so both the number of inverse-DCT and motion compensation operations are reduced.
• VLD Variable Length Decoder
• a dequantizer function (inverse quantizer) 220 processes the output of the VLD 215 using a first quantization step size, Q
• Motion vector (MV) data is provided from the VLD 215 to a motion compensation function 235, which is responsive to a previous frame buffer 250 and/or a current frame buffer 245 of pixel domain data.
• a DCT function 270 converts the output of the MC function 235 to the frequency domain and provides the result to an adder 230.
• a switch 231 passes either the output of the adder 230 or the Qf 1 function 220 to a quantization function Q 275, which quantizes the data, typically at a coarser level to reduce the bit rate. This output is then inverse quantized at an inverse quantization function Q 2 _1 282 for summing at an adder 286 with the output of the switch 231.
• the output of the adder 286 is provided to an IDCT function 284, and the output thereof is provided to the frame buffers 245 and 250.
• VLE Variable Length Encoder
• FIG. 3 illustrates a transcoder 300 that performs requantization without motion compensation for use in accordance with the present invention.
• VLD 410 inverse quantizer 420, quantizer 430 and VLE 440 are used.
• FIG. 4 illustrates an end-to-end stat remux processing delay in accordance with the present invention.
• An example one of the transcoders or TPEs 110 includes an MTS buffer 405 for buffering the input transport stream, a demux 410 for separating out the elementary streams of the different services in the transport stream, and an ES buffer 415 for storing the ESs streams.
• the ES data is variable-length decoded at a VLD function 420, and the result is provided to a lookahead delay buffer 425, with a capacity of, e.g., five frames.
• a transcode function 440 After a one-frame delay at a buffer 4 5, a frame is transcoded at a transcode function 440, and the result is stored in a transcode buffer 445.
• a remultiplexer (remux) 450 combines data from the transcode buffer 445 and data, if present, from a transport stream delay buffer 430, and the resulting transport stream is communicated to a decoder 452, such as a set-top box in a broadband communication network.
• the transport stream delay buffer 430 is used for the bypass frames, discussed previously, that are not transcoded. The bypass frames are delayed to maintain synchronicity with the other channels that are transcoded.
• the output stream from the transcoder 110 is combined with other transport steams from the other transcoders to form a transport multiplex that is communicated to a representative decoder 452.
• the decoder 452 includes a FIFO buffer 455 that buffers the incoming data, and a decoding function 460 that decodes the data to provide an output, e.g., for display on a television.
• the buffer delay is fixed. If the transcoding time is delayed, the actual transcode time to decode time is shortened, but the transcode 'tick' to decode time is fixed by the buffer delay.
• FIG. 5 illustrates a transcoder VBV model in accordance with the present invention.
• the vbv model of the decoder 452 is used to limit the maximum and minimum frame size before transcoding a new frame.
• the level of the transcoder's bitstream output FIFO can be used to derive the decode buffer status just before the DTS of the new frame (see also FIG. 7).
• the vbvjullness calculation is shown in FIG.
• composition of the transcoder FIFO is shown at 500
• the corresponding composition of the decoder FIFO is shown at 550.
• the QLP provides the bit rate in a number of packets to output for the time period T q .
• a margin needs to be added due to the uncertainty caused by the variable latency from the time the QLP issues a rate change to the time the new rate actually takes effect at the transcoder.
• the new bit rate is changed at the fixed period T q .
• T q is asynchronous to the video frame time (DTS of decoder).
• the transcoding rates are computed at the dashed lines, e.g., 602, 604, 606, ...
• the system delay is three frames and the transmission rate needs to be computed for PI- 1 to PI -3.
• Pl-1 denotes Program(bitstream #1) frame #1
• PI -2 denotes Program(bitstream #1) frame #2
• so forth Since the frame DTS times do not align with the rate changes, this causes a difference between the transcoding rate and the transmission rate. Moreover, since the Tq period straddles two frames, the second (later) frame is assigned those packets.
• the worst case rate error between transcoding and transmission is the difference in the number of packets allocated at the current time and the number of packets assigned a system delay time later (DTS of the current frame).
• the bottom of FIG. 6 shows the two extreme cases. In the first case (650), the frame DTS occurs just prior to T q . In the second case 670, the frame DTS occurs at T q + . A through AA represent the number of packets assigned to each T q period. Both cases have the same encoding packet assignment, sum (B through X). The number of transmission packets for case 1 is Sum(C,D,E, ... ,W,X,Y); and, for case 2, Sum( B,C,D, ... N,W,X). Case 2 has no difference between encoding and transmission rates, so this is the best case (DTS aligned with T q ). Case 1, which is the worst case, has a difference of B packets.
• the estimated number of bits to be transmitted from the current time to the DTS time is:
• vbvjullness (no. of bits to be transmitted) - (bits in transcoder FIFO); this value can be used to limit the trascoded frame size, so it will be no more than vbvjullness. This requirement is imposed to ensure the decoder buffer will not underflow while decoding the current frame (i.e., the frame that is about to be transcoded).
• T(t) Size of the frame entering the FIFO at time t.
• R(t) transmission bit rate at time t.
• dts DTS of the current frame.
• nextDts DTS of the next frame
• D decoder buffer size.
• FIG. 7 illustrates communication timing between a quantization level processor (QLP) and transcoder processing elements (TPEs) in accordance with the present invention.
• QLP quantization level processor
• TPEs transcoder processing elements
• transcoding starts for frame "N" using the need parameter calculated from the associated statistical information.
• the transcode bit rate is calculated for each Tq period, such as at example time 720.
• Time 725 denotes the start of transcoding for the next frame, with index N-l.
• the TPE sends information regarding the fullness of its output buffer, which now contains data from frame N, to the QLP.
• the QLP provides a target frame size, and minimum and maximum bounds for the transcoding bit rate, to the TPE at time 735.
• Times 740 and 745 denote the times of the decode time stamps of frames N and N+l, respectively.
• the QLP delivers a transmission bit rate to the mux to inform the mux how many packets of data in the TPE's output buffer to output in a transport stream. This time 750 follows the transcode time 720 by a delay period.
• a bit rate need parameter is determined for each frame based on an expected complexity of the frame.
• An transcoding bit rate is allocated to each TPE by the QLP 130 based on the need parameters and the available bandwidth.
• the bits of an input frame are first partially decoded by the variable length decoder 420, and average quantizer-scales and the number of bits in the frame are computed.
• a number of frames, e.g., five frames, of partially decoded coefficients and headers are stored for each video channel in the lookahead buffer 425, which provides a corresponding lookahead delay.
• the size of the processor SDRAM memory 132 limits the length of the lookahead buffer.
• Tg-amestart determined by the intended decode time of the frame at the target decoder 452 the need parameter is computed for the oldest frame in the lookahead buffer 425.
• the decode time is specified by the DTS of the frame, which is in units of 27MHz clock ticks.
• Tframesta r t is defined as:
• the need parameter is computed from the average quantizer scale and the bit count of the input frames, as follows:
• NeedParameter MbResolutionAdjust * AvgQR * ( CurrentQR + Alpha * PastQR) / ( Beta * CurrentQR + PastQR ), where
• AvgQR (sum of (avglnQuant * inFrameSize) over the most recent 15 P or B frames and the most recent I frame in the past) * 900,000 / (DTS of current frame - DTS of the 16 th frame in the past).
• 900,000 is the number of 27 MHz units in one frame period (1/30 sec.) 27 MHz is the MPEG clock rate.
• the past 16 P or B frames are used.
• I frame For an I frame,
• PastQR avglnQuant * inFrameSize of the last I frame. If there is no I frame within the past 45 frames, PastQR is set to be the same value of CurrentQR.
• CurrentQR average of (avglnQuant * inFrameSize) over the current frame and every frame in the lookahead buffer 425 of the same picture type.
• PastQR average of (avglnQuant * inFrameSize) over past four frames of the same picture type. If there are less than 4 frames of the same picture type in the past, PastQR is set to the same value as CurrentQR.
• MbResolutionAdjust is an adjustable parameter to compensate the perceptual difference in distortion in different resolution. The lower the resolution, the more visible the distortion. Therefore the need parameter is boosted for lower resolutions. Default values of MbResolutionAdjust are 1.0 for full resolution, 1.2 for three-quarter resolution, and 1.5 for half resolution. Alternatively, or in addition, the need parameter may be adjusted based on a macroblock resolution, which is the number of macroblocks in a frame.
• the TPEs 110, ..., 112 and Mux 120 count the number of input transport packets and save this packet count information in circular buffers on the QLP 130.
• Each circular buffer has, e.g., 1024 entries, and each entry stores the bit rate information of one Tq time slot.
• the 1024 entries is just a design parameter that can vary for different implementations.
• the circular buffer should be large enough to hold the data for the 0.6 sec delay.
• BitRate (bits per second) PktCount * 188 * 8 / TqPeriod.
• the Mux 120 counts the number of transport packets (except null packets) in each data service, which may comprise one or more MPEG programs.
• the QLP 130 uses the packet count to compute the instantaneous data service input bit rate for each Tq time slot.
• the Mux saves the packet count information in circular buffers on the QLP in the same way as the packet count information from the TPEs is saved.
• the processes in which the Mux 120 and the TPEs write packet count information into the QLP's circular buffers are asynchronous with the Tq ticks.
• a Tq index which is saved with the packet count information is used to synchronize the QLP with the input packet count information during the initialization process.
• the Tq index is maintained by the QLP.
• the QLP sets the Tq index to 0 at initialization, and increases it by 1 on every Tq interrupt.
• the QLP periodically broadcast the Tq index and the associated time to the TPEs 110, ..., 112 and the Mux 120.
• the QLP 130 sets aside the bandwidth for the pure passthrough video channel(s) and the non-video channels. Since the transmission bit rate of the packets in these passthrough channels has to match the bit rate of the corresponding packets at the input, the bit rate to set aside for each passthrough video channel equals the instantaneous input bit rate at time
• the non-video PIDs have the same amount of delay.
• the QLP 130 synchronizes the input packet count information with the current Tq interrupt as follows.
• the QLP For each circular buffer, the QLP maintains a 10 bit read pointer. Initially, the QLP searches for the entry in the circular buffer whose tqlndex matches the value of (CurrentTqlndex - PacketCountDelaylndex). For every Tq tick after that, the QLP increases the value of the read pointer by one. The QLP also checks the continuity of the Tqlndex stored with the packet count in the circular buffer. If there is a discontinuity, the QLP sets a warning flag to the KP 140, and re-initializes the read pointer by searching for the Tqlndex that matches (CurrentTqlndex - PacketCountDelaylndex) .
• the QLP calculates the average input bit rate over a frame. This computation is performed at the same time as the frame's need parameter calculation. The average input bit rate is used for the calculation of the target frame size.
• the QLP computes the duration of the frame from FrameTqCount:
• the QLP 130 assigns the transcoding bit rate to the pure passthrough channels as follows. if ( purePassThrough )
• TcodeBitrate VideoInBitrate
• VideoInBitrate is the instantaneous input video bit rate computed as:
• VideoInBitrate (PacketCount value stored in the corresponding video program circular buffer entry at the current read pointer ) * 188 * 8 / TqPeriod.
• stat remux group For each statmux group, the QLP calculates the amount of bandwidth that is available for dynamic allocation, that is, the amount of bandwidth available after deducting the bandwidth of the pure passthrough channels and the PES alignment overhead bits.
• a stat remux group refers to a group of channels at the transcoder 100 that are competing for bandwidth with one another. One or more stat remux groups may be used at the transcoder 100.
• TotalOutputBandwidth is the total output transport (payload) bandwith available for video, audio, and data services in the input streams, including system information. This is a user-configured parameter for the statmux group.
• PesOverheadBitrate is the average overhead bit rate for PES alignment, which is a constant:
• NonVideoInBitrate The instantaneous non- video bit rate (NonVideoInBitrate) is compute in a similar way as the VideoInBitrate:
• NonVideoInBitrate (PacketCount value stored in the corresponding non-video PID's circular buffer entry at the current read pointer ) * 188 * 8 / TqPeriod. 6.2. Transcoding bit rate allocation
• the QLP allocates the Available VideoBitrate among the non-passthrough video channels subject to the following constraints:
• the sum of franscoding bit rates GroupBandwidth. Since the bandwidth available for dynamic allocation is variable, and subject to the bandwidth occupied by the passthrough components (e.g., non-video data) in the transport stream, the group bandwidth is expressed as a percentage of the total available bandwidth when there is more than one statmux group configured for the output transport multiplex.
• the sum of the average transcoding bit rate for all non-pure-passthrough video channels on any single TPE has to be less than an upper bound that is determined by the Variable Length Encoder's (380, 440) maximum throughput on the TPE.
• the output bifrate should be equal to the input bit rate.
• a channel may be processed as a pure passthrough channel, e.g., to preserve its quality.
• the output target frame size cannot be bigger than the input frame size. This translates to the constraint that the average transcoding bit rate cannot exceed the average input bit rate.
• the target frame size cannot be higher than a maximum value, nor lower than a minimum value, which are provisioned to protect the video buffers.
• the procedure of transcoding bit rate allocation is outlined as follows. 6.2.1. Compute an approximation of the maximum frame size
• maxFrameSize (number of bits transmitted to the decoder 452 from the time the first bit of the transcoded frame enters the franscoder FIFO 445 to the decode time of the frame) - (transcoder FIFO level at the time the first bit of the transcoded frame enter the FIFO).
• delayBitsMax TqPeriod * sum of transmission bit rate values in the transmission bit rate queue for Ndelay terms starting from FrameMarker, where:
• Ndelay Number of Tq slots counting from the time when the FifoLevel is read to the time when the frame is decoded.
• FifoLevel is the most recent output FIFO level of the transcoder.
• offsetBitsMax Size of the most recent output frame + target frame size of the frame currently being transcoded + sum of target frame sizes of the frames preceding the current frame that are waiting to be transcoded.
• the minimum transcoded frame size to protect the decoder 452 from overflow is given by:
• MinFrameSize (number of bits transmitted to the decoder from the time the first bit of the transcoded frame enters the franscoder FIFO to the decode time of the next frame) - (Size of the decoder' s buffer) - (transcoder FIFO level at the time the first bit of the transcoded frame enters the FIFO).
• MinFrameSize is related to MaxFrameSize by:
• MinFrameSize MaxFrameSize + (Number of bits transmitted to the decoder from the decode time of the current frame to the decode time of the next frame) - (Size of decoder' s buffer) .
• DecoderBufferSize is the size of the MPEG2 Main Profile, Main Level buffer size, which is 1.835Mbits. 6.2.3. Compute the maximum transcoding bit rate that protects the buffer A maximum transcoding bit rate must be set to avoid a decoder buffer overflow.
• a minimum transcoding bit rate must be set to avoid a decoder buffer underflow.
• the minimum transcoding bit rate is computed in a manner that is similar to the maximum transcoding bit rate:
• MinTcodeBitrate ( ( MinFrameSize / OrigFrameSize ) * AvglnBitrate * FrameTqCount - (Sum of transcoding bit rate from the beginning of the frame to the current Tq interrupt) * FrameTqlndex ) / (FrameTqCount - FrameTqlndex).
• the average output bit rate among all video services on any single TPE over a window is constrained by the processing power of the VLE in the TPE, e.g., the throughput is constrained to no more than an average of 12 Mbits/sec. spread (a processor-dependent value) over a 3 frame window.
• TotalNeed Sum of NeedParameter over every video channel if (TotalNeed > 0) for (every video channel)
• Each video channel is assigned the MinTcodeBifrate of the channel. Ifthe sum of MinTcodeBifrate exceeds the AvailabeVideoBifrate, the bandwidth is distributed in proportion to the MinTcodeBifrate.
• TotalMinBitrate sum of MinTcodeBifrate over the statmux group if (TotalMinBitrate > Available VideoBitrate) ⁇ for (every video channel)
• TcodeTcodeBitrate [channel] MinTcodeTcodeBitrate [channel] * Available VideoBitrate / TotalMinBitrate
• Available VideoBitrate Available VideoBitrate - TotalMinBitrate
• the QLP then tries to satisfy the user minimum bit rate requirement.
• the QLP bounds the user minimum bit rate by the MaxTcodeBifrate before applying the user minimum bifrate. for (every video channel)
• ExtraMinBitrate Sum of (minBitrate - MinTcodeBitrate) over every channel that UserMinBifrate is higher than MinTcodeBitrate. if (ExtraMinBitrate > Available VideoBifrate)
• the QLP calculates the a maximum bit rate value for each channel based on the user maximum bit rate, the maximum and minimum transcoding bit rates to protect the decoder buffer, and the maximum processing bit rate that can be supported by each TPE. for (every TPE)
• MaxBitrate[channel] Min ( MaxTcodeBitrate[channel], (tpeAvailableBifrate * NeedBitratefchannel] / tpeNeedBifrate) + TcodeBitrate[channel],
• TotalNeedBitrate sum of needBitrate over all video channels for (every video channel) ⁇
• TcodeBiteate[channel] TcodeBifrate[channel] + (Available VideoBitrate * NeedBitrate[channel] / TotalNeedBitrate)
• the QLP applies the maximum bit rate constraint on the bit rate allocation. for (every video channel)
• the QLP allocates the exfra bandwidth collected from the channels that exceed the maximum bit rate.
• TotalNeedBitrate Sum of NeedBitrate over every channel if (AvailableVideoBifrate > 0)
• the QLP allocates the remaining bandwidth in proportion to the difference between the current allocated bit rate and the maximum bit rate. if (AvailableVideoBifrate > 0)
• TotalHeadroom sum of (MaxBitrate[channel] -
• TcodeBitratefchannel] TcodeBitratefchannel] +
• the QLP maintains a queue of the transcoding bit rate for each video channel.
• the calculated transcoding bit rate values are stored in the queues, and retrieved 0.5 seconds later to use as fransmission bit rate values. 6.2.7. Initial Target Frame Size Calculation
• the QLP calculates an initial value for the target frame size as follows.
• InitialTargetFrameSize ( OrigFrameSize * AvglnBitrate / AvgTcodeBitrate, where AvgTcodeBitrate is the average franscoding bit rate for the frame, defined as the sum of TcodeBitrate over all Tq slots occupied by the frame.
• the TPEs may not be ready to transcode a new frame at this time, therefore the QLP maintains a target frame size queue for each video channel.
• the InitialTargetFrameSize value is stored in the queue for the corresponding channel, and is retrieved later when the TPE is ready to transcode the frame. 6.3. Passthrough Decision
• the QLP decides whether to pass through a frame or not.
• the pass through decision is made based on the transcoding bit rate calculated at the first Tq slot of the frame as follows for each channel at the beginning of a new frame.
• PassThroughBifrate PassThroughMargin * OrigFrameSize / FrameTqCount; where PassThroughMargin is a parameter less than but close to 1.0, e.g. 0.95; OrigFrameSize is the number of bits in the input frame; and FrameTqCount is the number of Tq slots in the frame.
• PassThroughMargin allows the input frames whose size is slightly higher than the target frame size to be passed through, thereby preserving the quality of the frame, and also saving transcoder processing cycles. if ( TcodeBitrate > PassThroughBifrate )
• the QLP calculates the maximum frame size and the minimum frame size values based on the latest buffer level information as soon as it receives a message from the TPE that signals the TPE is ready to transcode a new frame.
• the QLP then pulls the target frame size out from the target frame size queue 132, and computes the final value of the target frame size using maximum and minimum frame size constraints.
• the QLP calculates the maximum frame size to protect the decoder buffer from underflow. The calculation is similar to that of the approximate maximum frame size calculation during the Tq interrupts (6.2.1):
• MaxFrameSize DelayBits - FifoLevel -LastOutputFrameSize.
• DelayBits is the number of bits transmitted to the decoder from the time the FIFO level was read to the decode time of the frame, and can be calculated by summing the corresponding transmission bit rate values currently in the transmission bit rate queue.
• FifoLevel is the transcoder FIFO level latched by the transcoder. That is, the FifoLevel is read by the transcoder and passed to the QLP.
• the QLP calculates the minimum frame size to protect the decoder buffer from underflow. The calculation is similar to that of the approximate minimum frame size calculation during the Tq interrupts (6.2.2).
• the minimum frame size is related to the maximum frame size by:
• MinFrameSize MaxFrameSize + (Number of bits transmitted to the decoder from decode time of the current frame to the decode time of the next frame) - (Size of decoder's buffer).
• the decoder's buffer size is 1.835 Mbits. 6.4.3. Compute the carryover from the previous frame
• the transcoders may not be able to generate exactly the number of bits equal to the target frame size.
• the surplus or deficit of bits from transcoding the previous frame is lumped in with the target frame size of the current frame. This deviation (surplus or deficit) is calculated as:
• FrameCarryOver LastOutputFrameSize - (TargetFrameSize of previous frame).
• the QLP pulls the InitialTargetFrameSize value out from the target frame size queue of the corresponding video channel, and bounds the target frame size by the maximum and minimum values:
• TargetFrameSize Min ( MaxFrameSize, Max ( MinFrameSize, InitialTargetFrameSize + FrameCarryOver ) ).
• the QLP then sends the values of MinFrameSize, MaxFrameSize, and TargetFrameSize to the TPEs. These values are used to guide the rate control of the transcoding process. 6.5. Quantization control
• a new quantization scale Q ew is calculated by scaling the quantization scale of the input macroblock Qoi d by a targeted bit reduction ratio, R N ew/ oi d -
• each macroblock has a quantizer scale.
• a group of macroblocks such as in a slice or other grouping, may be associated with a common quantizer scale. In this case, a new quantization scale is determined for the group.
• Row Original number of bits in the frame.
• New - TargetFrameSize Target number of bits to be generated by transcoding/requantizing the frame. For every slice, do:
• the quantizer scale is set to the maximum level (coarsest quantizing) and the rest of the frame will consequently have very poor quality.
• mbjbudget a mimmum number of bits per macroblock
• a panic quantizer is set for a short time until there are enough bits left for the remaining macroblocks to have mb udget number of bits. That is, the panicjevel is a quantizer level to try to force the MBs to have mb_budget or smaller number of bits. This spreads the panic quantizer over the frame, such that only a portion of the frame may go into the panic mode. To achieve this, at the beginning of each frame, initialize the following variables:
• the MPEG standard requires the PCR (Program Clock Reference) to be sent at a maximum interval of 100ms.
• the actual PCR value is not known until the fransmission time, so the franscoder creates a placeholder slot for the PCR.
• the QLP estimates the time used for transmitting the frame, hence the minimum number of PCRs required to be inserted in the frame to satisfy the maximum PCR interval requirement.
• coded bitsfreams may have a variable duration for each frame. For example, if a frame has 100,000 bits and is transmitted at 1 Mbps, the duration is 0.1 sec. If the frame is transmitted at 2Mbps, then the duration is 0.05 sec.
• TxFrameDuration TargetFrameSize / (minimum value in the transmission bit rate queue).
• the present invention provides an efficient statistical remultiplexer for processing data in a number of channels that include video data.
• franscoding of the video data is delayed while statistical information is obtained from the data.
• Bit rate need parameters for the data are determined based on the statistical information, and the video data is transcoded based on the respective bit rate need parameters following the delaying.
• a transcoding bit rate for video frames at the stat remux is updated a plurality of times at successive intervals to allow a closer monitoring of the bit rate.
• minimum and maximum bounds for the transcoding bit rate are updated in each interval. Thus, a portion of a frame is transcoded in a first interval, then the transcoding bit rate is updated, then a second portion of the frame is transcoded in a second interval, and so forth.
• the pre-transcoding quantization scales of the macroblocks in a frame are scaled to provide corresponding new quantization scales for franscoding based on a ratio of a pre-transcoding amount of data in the frame and a target, post-transcoding amount of data for the frame.
• the quantization scales are adjusted for different portions of the frame as the portions are transcoded to ensure that a minimum amount of transcoding bandwidth is allocated to each macroblock.

Landscapes

• Engineering & Computer Science (AREA)
• Multimedia (AREA)
• Signal Processing (AREA)
• Computing Systems (AREA)
• Theoretical Computer Science (AREA)
• Compression Or Coding Systems Of Tv Signals (AREA)

Applications Claiming Priority (3)

Publications (1)

Family

ID=24686625

Family Applications (1)

Country Status (9)

Families Citing this family (63)

Family Cites Families (32)

• 2000
  • 2000-09-25 US US09/669,517 patent/US6847656B1/en not_active Expired - Lifetime
• 2001
  • 2001-08-10 TW TW090119641A patent/TW529308B/zh not_active IP Right Cessation
  • 2001-09-04 AU AU2001290599A patent/AU2001290599A1/en not_active Abandoned
  • 2001-09-04 KR KR10-2003-7004241A patent/KR20030061809A/ko not_active Application Discontinuation
  • 2001-09-04 CN CNB018194133A patent/CN100459705C/zh not_active Expired - Lifetime
  • 2001-09-04 MX MXPA03002527A patent/MXPA03002527A/es unknown
  • 2001-09-04 CA CA2421794A patent/CA2421794C/en not_active Expired - Lifetime
  • 2001-09-04 WO PCT/US2001/027243 patent/WO2002028108A2/en active Application Filing
  • 2001-09-04 EP EP01970613A patent/EP1320997A2/de not_active Withdrawn
• 2004
  • 2004-09-20 US US10/945,641 patent/US20050041689A1/en not_active Abandoned

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events