US20050041689A1 - Statistical remultiplexing with bandwidth allocation among different transcoding channels - Google Patents

Statistical remultiplexing with bandwidth allocation among different transcoding channels Download PDF

Info

Publication number
US20050041689A1
US20050041689A1 US10/945,641 US94564104A US2005041689A1 US 20050041689 A1 US20050041689 A1 US 20050041689A1 US 94564104 A US94564104 A US 94564104A US 2005041689 A1 US2005041689 A1 US 2005041689A1
Authority
US
United States
Prior art keywords
transcoding
frame
bit rate
method
updated
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US10/945,641
Inventor
Siu-Wai Wu
Robert Nemiroff
Vincent Liu
Ajay Luthra
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Arris Technology Inc
Original Assignee
Arris Technology Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to US09/669,517 priority Critical patent/US6847656B1/en
Application filed by Arris Technology Inc filed Critical Arris Technology Inc
Priority to US10/945,641 priority patent/US20050041689A1/en
Publication of US20050041689A1 publication Critical patent/US20050041689A1/en
Application status is Abandoned legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236Assembling 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/23608Remultiplexing multiplex streams, e.g. involving modifying time stamps or remapping the packet identifiers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102Methods 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/115Selection of the code volume for a coding unit prior to coding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102Methods 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/124Quantisation
    • H04N19/126Details of normalisation or weighting functions, e.g. normalisation matrices or variable uniform quantisers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134Methods 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/146Data rate or code amount at the encoder output
    • H04N19/15Data rate or code amount at the encoder output by monitoring actual compressed data size at the memory before deciding storage at the transmission buffer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134Methods 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/146Data rate or code amount at the encoder output
    • H04N19/152Data rate or code amount at the encoder output by measuring the fullness of the transmission buffer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169Methods 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/17Methods 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/176Methods 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/189Methods 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/196Methods 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/189Methods 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/196Methods 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/197Methods 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/40Methods 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/60Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • H04N19/61Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding in combination with predictive coding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236Assembling 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/2365Multiplexing of several video streams
    • H04N21/23655Statistical multiplexing, e.g. by controlling the encoder to alter its bitrate to optimize the bandwidth utilization

Abstract

An efficient statistical remultiplexer for processing a number of channels that include video data. In one aspect, 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. In another aspect, a transcoding bit rate for video frames 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, e.g., for buffer overflow and underflow protection, are also updated in each interval.

Description

  • This application is a divisional of co-pending, commonly assigned U.S. patent application Ser. No. 09/669,517 filed on Sep. 25, 2000.
  • BACKGROUND OF THE INVENTION
  • The present invention relates to a statistical remultiplexer for transcoding digital video signals.
  • Commonly, it is necessary to adjust a bit rate of digital video programs that are provided, e.g., to subscriber terminals in a cable television network or the like. For example, 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.
  • Accordingly, 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.
  • 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).
  • However, there is a need for an improved 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.
  • Moreover, 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.
  • Additionally, 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 provides a system having the above and other advantages.
  • SUMMARY OF THE INVENTION
  • The present invention relates to a statistical remultiplexer for transcoding digital video signals.
  • In one aspect of the invention, 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.
  • Furthermore, in another aspect of the invention, during MPEG-2 macroblock processing within a frame, 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.
  • Thus, the present invention provides an efficient statistical remultiplexer for processing data in a number of channels that include video data. In one aspect of the invention, 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.
  • In another aspect of the invention, 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.
  • In yet another aspect of the invention, 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. Moreover, 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.
  • Corresponding methods and apparatuses are presented.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The present invention will hereinafter be described in conjunction with the appended drawing figures, wherein like reference numerals denote like elements, and:
  • 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.
  • 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 (VBV) model in accordance with the present invention.
  • 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.
  • DETAILED DESCRIPTION OF THE INVENTION
  • The ensuing detailed description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the invention. Rather, the ensuing detailed description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an embodiment of the invention. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the invention as set forth in the appended claims.
  • The present invention relates to a statistical remultiplexer for transcoding digital video signals.
  • The following acronyms and terms are used:
  • BW—Bandwidth
  • DCT—Discrete Cosine Transform
  • DTS—Decoding Time Stamp
  • ES—Elementary Stream
  • FIFO—First-In, First-Out
  • KP—Kernel Processor
  • MTS—MPEG Transport Stream
  • PCI—Peripheral Component Interconnect
  • PCR—Program Clock Reference
  • PES—Packetized Elementary Stream
  • PID—Program Identifier
  • Q—Quantization
  • QLP—Quantization Level Processor
  • SDRAM—Static Dynamic Random Access Memory
  • TP—Transport Packet
  • TPE—Transcoder core Processing Element
  • VLD—Variable-Length Decoding
  • VLE—Variable-Length Encoding
  • 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.
  • A Kernel Processor (KP) configures the groomer 105, the TPEs 110, . . . , 112, the QLP 130, and the Mux 120.
  • In particular, 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 (300 MHz) 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.
  • Receives configuration parameters from the Kernel Processor.
  • Reports operational status and statistics back to the Kernel Processor.
  • The QLP communicates with the KP and TPEs via the PCI bus (32bit @ 66 MHz). 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)
  • Statistics of the input frame to be transcoded (Source: TPEs)
  • Timing information of the input frame (Source: TPEs)
  • Statistics of the output frame just transcoded (Source: TPEs)
  • Timing information of the output frame (Source: TPEs)
  • Transcoder FIFO level (Source TPEs)
  • Non-video (data) input packet rate information (Source: Mux 120)
  • Outputs from QLP 130
  • Status and statistics (Destination: KP)
  • TPE service assignment information (Destination: KP)
  • Transmission bit rate (Destination: Mux)
  • Transcoding target frame size (Destination: TPE)
  • Maximum and Minimum frame size for buffer protection (Destination: TPE)
  • Minimum number of PCRs to be inserted into a frame (Destination: TPE)
  • Flag to command the TPE to passthrough a frame (Destination: TPE)
  • 1. Overview
  • Although 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.
  • 1. 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. In particular, for every input frame to be transcoded, 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. In particular, because of the possible use of the 3:2 pulldown format in the video channels, a coded frame can be either one NTSC frame time (33.3 ms) or 1.5 frame times (50 ms). We use the longer time to make sure the transcoding rate allocation for the frame is determined before the actual transcoding begins.
  • 2. The QLP 130 performs a bandwidth allocation process to allocate a transcoding bit rate to the TPEs at periodic intervals, Tq. It computes the transcoding bit rate for every video channel for each Tq interval. The transcoding bit rate is stored in a queue at the QLP 130 and delayed for (0.5 sec+3 NTSC frame periods)=0.6 sec., rounded to the nearest Tq period. One NTSC frame period is {fraction (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.
  • 3. While a frame is in the lookahead buffer of a TPE, 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.
  • 4. When the transcoder is ready to transcode a new frame, 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.
  • 5. If the number of target bits (target frame size) is greater than (or close to, within a predetermined tolerance—see section 6.3) the number of bits in the input frame, this frame is a candidate to bypass 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).
  • 6. 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.
  • 7. During transcoding, 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. Thus, the outgoing packets at a TPE are created and stored in memory, e.g., in a TPE FIFO buffer. Moreover, 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.
  • Moreover, a PCR slot is created at least every 0.1 second to conform to the MPEG2 system standard requirement.
  • 8. At each n*Tq period, the Mux 120 reads the number of packets assigned to each channel from the TPEs 110, . . . , 112 via the PCI bus 115. “in” 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.
  • 9. The Mux 120 receives a transport tick every m ticks of a 27 MHz 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 be achieved as described in commonly-assigned, U.S. Pat. No. 6,724,825 to R. Nemiroff, V. Liu and S. Wu, issued on Apr. 20, 2004, 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.
  • While a straightforward transcoder can simply be a cascaded MPEG decoder and encoder, 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. Moreover, since the motion vectors are not recalculated, the required computations are dramatically reduced. This simplified architecture offers a good combination of both low computation complexity and high flexibility.
  • In particular, a pre-compressed video bitstream is input to a Variable Length Decoder (VLD) 215. A dequantizer function (inverse quantizer) 220 processes the output of the VLD 215 using a first quantization step size, Q1.
  • 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 Q1 −1 function 220 to a quantization function Q2 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 Q2 −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.
  • A Variable Length Encoder (VLE) 280 codes the output of the Quantization function 275 to provide at output bitstream at a reduced bit rate. The bit output rate of the transcoder is thus adjusted by changing Q2.
  • FIG. 3 illustrates a transcoder 300 that performs requantization without motion compensation for use in accordance with the present invention.
  • Here, only re-quantization is applied to a frame, without motion compensation. Generally, IDCT and DCT operations are avoided. This strategy incurs a lower complexity, but causes some artifacts in the output data. The DCT coefficients are de-quantized then re-quantized.
  • In particular, a VLD 410, inverse quantizer 420, quantizer 430 and VLE 440 are used.
  • 2. End-to-end Processing Delay
  • 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. After a one-frame delay at a buffer 435, 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.
  • Note that, in practice, 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.
  • A buffer delay of, e.g., 0.5 seconds, which can vary in different implementations, is experienced by the video packets. This is a delay between the transcoding (encoding) time and the decode time. This delay occurs in both the transcoder (output) video FIFO 445 and the decoder FIFO 455. 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.
  • 3. Buffer Model
  • 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). Specifically, the future decode buffer status (vbv_fullness) is given by
  • vbv_fullness=(No. of bits to be transmitted from current time to the DTS time of the new frame)—(No. of bits in the encoder FIFO ). The vbv_fullness calculation is shown in FIG. 5, where the composition of the transcoder FIFO is shown at 500, and the corresponding composition of the decoder FIFO is shown at 550.
  • Moreover, we can compute the number of bits transmitted by adding all the encoding rates starting from t seconds up to the last encoding rate issued by the QLP, (where t is the total delay through the encode plus decode buffers, i.e., the system delay.) The QLP provides the bit rate in a number of packets to output for the time period Tq.
  • Moreover, 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 Tq. Tq is asynchronous to the video frame time (DTS of decoder).
  • As shown in FIG. 6, the transcoding rates are computed at the dashed lines, e.g., 602, 604, 606, . . . . This example assumes the system delay is three frames and the transmission rate needs to be computed for P1-1 to P1-3. With this notation, P1-1 denotes Program(bitstream #1) frame #1, P1-2 denotes Program(bitstream #1) frame #2 , and 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 Tq. In the second case 670, the frame DTS occurs at Tq +. A through AA represent the number of packets assigned to each Tq 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, . . . ,V,W,X). Case 2 has no difference between encoding and transmission rates, so this is the best case (DTS aligned with Tq). Case 1, which is the worst case, has a difference of B packets.
  • Therefore, the estimated number of bits to be transmitted from the current time to the DTS time is:
  • Σ transcoding_packets(n)±packet_count_error, packet_count_error=(number of packets assigned at DTS time)—(number of packets assigned at current time). A positive and negative packet_count_error has different effects on frame size calculations.
  • Note that system delay should be a multiple of Tq.
  • With the estimated vbv fullness given by
  • vbv_fullness=(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 vbv_fullness. 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).
  • The maximum frame size and minimum frame size can be derived from the sequence of transmission bit rate, snapshot of the transcoder buffer level, and the sizes of the previously transcoded frame, as follows:
  • Let B(t)=Buffer level at time t.
      • tc=time when the current frame enters the transcoder FIFO.
      • t0=time when the transcoder FIFO level was last read.
      • 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. Maximum Frame Size = t = tc dts R ( t ) - B ( tc ) = t = t0 dts R ( t ) - i = t0 tc R ( t ) - [ B ( t0 ) + t = t0 tc T ( t ) - t = t0 tc R ( t ) ] = t = t0 dts R ( t ) - B ( t0 ) - t = t0 tc T ( t ) Minimum Frame Size = t = tc nextDts R ( t ) - B ( tc ) - D = Maximum Frame Size + i = dts nextDts R ( t ) - D
  • FIG. 7 illustrates communication timing between a quantization level processor (QLP) and transcoder processing elements (TPEs) in accordance with the present invention.
  • At time 705, a TPE sends statistical information for a current frame “N” to the QLP. At time 710, the TPE sends information regarding the fullness of the TPE's output buffer, which includes data from a previously transcoded frame with an index of N-k, e.g., where k=1. The previously coded frame is usually frame N−1, i.e., the previous frame. However, sometimes it might take more than one frame time to transcode a frame so the timing might “slip”. In that case, the distance between the “current frame” and the frame just transcoded may be more than 1 frame, e.g., such that k=2. At time 715, 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−1.
  • At an example time 730, the TPE sends information regarding the fullness of its output buffer, which now contains data from frame N, to the QLP. In response, 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+1, respectively.
  • At time 750, 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.
  • 4. Need Parameter
  • 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.
  • Referring again to FIG. 4, 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. Each coefficient takes two bytes, resulting in 720×480×1.5×2=1 Mbyte/frame.
  • At a specific time, TframeStart, 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 27 MHz clock ticks. TframeStart is defined as:
  • (Decode time of the frame—buffer delay—1.5 NTSC frame time).
  • 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 (avgInQuant*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 16th frame in the past). 900,000 is the number of 27 MHz units in one frame period ({fraction (1/30)} sec.) 27 MHz is the MPEG clock rate.
  • If there is no I frame within the past, e.g., 45 frames, the past 16 P or B frames are used.
  • For an I frame,
  • CurrentQR=avgInQuant*inFrameSize of the current frame.
  • PastQR=avgInQuant*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.
  • For a P or B frame,
  • CurrentQR=average of (avgInQuant*inFrameSize) over the current frame and every frame in the lookahead buffer 425 of the same picture type.
  • PastQR=average of (avgInQuant*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.
  • Alpha and Beta are adjustable parameters to control the reaction of the need parameter to the change in the product of quantizer scale and bit count. Default values are Alpha=256, Beta=256.
  • 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.
  • 5. Input Bit Rate Information
  • In every Tq time slot, 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. There is one circular buffer of input bit rate information for each video program/channel processed by the TPEs, and one circular buffer of bit rate information for all the data stream that is passed directly to the Mux 120 without going through a TPE (i.e., in the passthrough mode). 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. From the packet counts, the QLP 130 can calculate the instantaneous input bit rate for each Tq time slot as follows:
  • 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.
  • During the transcoding bit rate allocation process, 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
  • PacketCountDelay=PassThroughDelay—TcrToTxrDelay
  • prior to the current time, where PassThroughDelay is the delay of the packets in the video passthrough channels (from demux 410 to remux 450), which is fixed at (0.5 sec.+6 NTSC frame periods)=0.7 sec. in the example implementation. The non-video PIDs have the same amount of delay.
  • TcrToTxrDelay is the delay from the calculation of the transcoding rate (current Tq tick) to the implementation of the transmission bit rate (FIG. 7). This delay is fixed at (0.5 sec+1.5 NTSC frame periods +1.5 NTSC frame periods)=0.6 sec.
  • Therefore, PacketCountDelay is a constant equal to 0.7 sec−0.6 sec=0.1 sec. The number of Tq ticks equivalent to this delay is: PacketCountDelayIndex=(PacketCountDelay/TqPeriod).
  • The QLP 130 synchronizes the input packet count information with the current Tq interrupt as follows.
  • For each circular buffer, the QLP maintains a 10 bit read pointer. Initially, the QLP searches for the entry in the circular buffer whose tq/Index matches the value of (CurrentTqIndex—PacketCountDelayIndex). 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 TqIndex 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 TqIndex that matches (CurrentTqIndex—PacketCountDelayIndex).
  • For every input frame, 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.
  • First, the QLP computes the number of integer Tq periods straddled by the frame:
  • FrameTqCount=(difference between the decode time of the next frame and decode time of current frame)/TqPeriod, rounding to the next higher integer.
  • The QLP computes the duration of the frame from FrameTqCount:
  • FrameDuration=FrameTqCount*TqPeriod.
  • Then, the QLP computes the average input bit rate:
  • AvgInBitrate=InPacketCount*188*8*/FrameDuration,
  • where InPacketCount is the sum of PacketCount over FrameTqCount entries of the video packet count circular buffer, starting from the current read pointer.
  • 6. Bandwidth Allocation
  • At every Tq slot, the QLP performs the bandwidth allocation procedure. The QLP first assigns the bandwidth to the pure passthrough video programs, and to the data and audio programs, which are not transcoded. The remaining bandwidth is then allocated to the remaining channels based on the values of their need parameters, and subject to the maximum and minimum bit rate constraints.
  • 6.1. Passthrough Video and Data Channels
  • The QLP 130 assigns the transcoding bit rate to the pure passthrough channels as follows.
      • if (purePassThrough)
        • TcodeBitrate=VideoInBitrate
          where 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.
  • 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.
  • AvailableVideoBitrate=TotalOutputBandwidth—(sum of NonVideoInBitrate over all channels)—(sum of TcodeBitrate over all pure passthrough channels)—(Number of channels that are not pure passthrough* PesOverheadBitrate).
  • In this equation, 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:
  • PesOverheadBitrate=½* 184*8*30=22.08 Kbps.
  • 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
  • For each statmux group, the QLP allocates the AvailableVideoBitrate among the non-passthrough video channels subject to the following constraints:
  • 1. The sum of transcoding 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.
  • 2. 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.
  • 3. For a pure passthrough channel, the output bitrate should be equal to the input bit rate. A channel may be processed as a pure passthrough channel, e.g., to preserve its quality.
  • 4. For any video channel, 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.
  • 5. 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
  • The maximum transcoded frame size to protect the decoder buffer from underflow is given by:
  • maxFrameSize=(number of bits transmitted to the decoder 452 from the time the first bit of the transcoded frame enters the transcoder 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).
  • However, the transcoder FIFO level at the time the first bit of the transcoded frame enters the FIFO is not known at the time the transcoding bit rate is calculated. Therefore, an approximation of the maximum transcoded frame size is calculated as follows:
  • maxFrameSizeEstimate=delayBitsMax—FifoLevel—offsetBitsMax.
  • The value of delayBitsMax is the number of bits transmitted to the decoder 452 from the last time the FIFO level was read to the decode time of the frame, and is calculated by:
  • 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.
  • The value of FifoLevel is the most recent output FIFO level of the transcoder.
  • The value of offsetBitsMax is the approximate number of bits entering the transcoder FIFO from the time the FIFO level was last read to the time the first bit of the target transcoded frame enters the FIFO. This approximation is given by the sum of the initial (unbounded) target frame sizes of the frames waiting to be transcoded. This is equal to:
  • 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.
  • In the approximation of the maximum frame size, it is assumed that the number of bits generated by the future transcoded frames meets the frame target, and the initial frame target values in the QLP's output queue 132 do not hit the maximum frames size nor the minimum frame size.
  • 6.2.2. Compute an Estimate of the Minimum Frame Size
  • 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 transcoder 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).
  • It can be show that 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).
  • Therefore,
  • MinFrameSizeEstimate=MaxFrameSizeEstimate+DeltaBitsMin—DecoderBufferSize,
  • where DeltaBitsMin=Number of bits transmitted to the decoder from the decode time of the current frame to the decode time of the next frame, which can be calculated by summing the corresponding terms in the queue of the transmission bit rate.
  • In the example implementation, DecoderBufferSize is the size of the MPEG2 Main Profile, Main Level buffer size, which is 1.835 Mbits.
  • 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. The target frame size of a frame is computed as the input frame size scaled by the ratio of the average transcoding bit rate to the average input bit rate. Therefore, the maximum transcoding bit rate is calculated as follows from the maximum frame size, assuming the transcoding bit rate remains constant until the end of the frame time:
  • MaxTcodeBitrate=((MaxFrameSize/OrigFrameSize) *AvgInBitrate*FrameTqCount—(Sum of transcoding bit rate from the beginning of the frame to the current Tq interrupt)*FrameTqIndex )/(FrameTqCount—FrameTqIndex),
  • where OrigFrameSize is the number of bits in the input frame, FrameTqCount is the number of Tq time slots in the frame time, and FrameTqIndex is the number of Tq time slots since the start of the frame (TframeStart)
  • 6.2.4. Compute the Minimum Transcoding Bit Rate that Protects the Buffer
  • A minimum transcoding bit rate must be set to avoid a decoder buffer underflow. For each video service, the minimum transcoding bit rate is computed in a manner that is similar to the maximum transcoding bit rate:
  • MinTcodeBitrate=((MinFrameSize/OrigFrameSize) *AvgInBitrate*FrameTqCount—(Sum of transcoding bit rate from the beginning of the frame to the current Tq interrupt)*FrameTqIndex )/(FrameTqCount—FrameTqIndex).
  • 6.2.5. Calculate the Maximum Aggregated Bit Rate that Can be Processed by Each TPE
  • The average output bit rate among all video services on any single TPE over a window (e.g., 3 frame periods) 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. At any Tq period, the maximum bit rate supported by a TPE is calculated as follows:
  • MaxTpeBitrate=(NTq*VleThroughput)—(Sum of transcoding bitrate values of every video channel on the TPE over the past NTq−1 Tq interrupts),
  • where NTq=number of Tq time slots in the averaging window, e.g., 3 NTSC frame time (100 ms); VleThroughput is the throughput of the VLE in terms of average bit rate, e.g., 12 Mbits/sec.
  • 6.2.6. Distribute the Available bit Rate Among the Video Channels
  • The following procedure applies to each stat remux group. 1. The QLP determines the ideal bandwidth allocation in  absence of minimum and maximum bitrate constraints.    NominalBitrate = AvailableVideoBitrate / Number  of video channels in the statmux group    TotalNeed = Sum of NeedParameter over every  video channel    if (TotalNeed > 0)     for (every video channel)     {       NeedBitrate[channel] =  AvailableVideoBitrate * NeedParameter [channel] /  TotalNeed     }    } else {     for (every video channel)       NeedBitrate [channel] = NominalBitrate    } 2. Each video channel is assigned the MinTcodeBitrate of  the channel. If the sum of MinTcodeBitrate exceeds  the AvailabeVideoBitrate, the bandwidth is  distributed in proportion to the MinTcodeBitrate.    TotalMinBitrate = sum of MinTcodeBitrate over  the statmux group    if (TotalMinBitrate > AvailableVideoBitrate)    {     for (every video channel)     {       TcodeTcodeBitrate [channel] =  MinTcodeTcodeBitrate [channel] *  AvailableVideoBitrate / TotalMinBitrate     }     AvailableVideoBitrate = 0     Done with transcoding bit rate allocation.    } else {     for (every video channel) {       TcodeBitrate [channel] = MinTcodeBitrate  [channel]       NeedBitrate [channel] = Max ( 0,  NeedBitrate[channel] − MinTcodeBitrate [channel] )     }     AvailableVideoBitrate = AvailableVideoBitrate  − TotalMinBitrate    } 3. The QLP then tries to satisfy the user minimum bit  rate requirement. The QLP bounds the user minimum  bit rate by the MaxTcodeBitrate before applying the  user minimum bitrate.    for (every video channel)     {       if (UserMinBitrate[channel] > MaxTcodeBitrate [c])         minBitrate [channel] = MaxTcodeBitrate [channel]       else         minBitrate [channel] = UserMinBitrate[channel]     }    ExtraMinBitrate = Sum of (minBitrate −  MinTcodeBitrate) over every channel that  UserMinBitrate is higher than MinTcodeBitrate.    if (ExtraMinBitrate > AvailableVideoBitrate)    {     for (every video channel)     {       if (minBitrate[channel] >  MinTcodeBitrate[channel])       {         extraBitrate = (  minBitrate[channel] − MinTcodeBitrate[channel]) *  AvailableVideoBitrate / ExtraMinBitrate         TcodeBitrate[channel] =  TcodeBitrate[channel] + extraBitrate         needBitrate [channel] = Max (0,  needBitrate[channel] − extraBitrate)       }     }     AvailableVideoBitrate = 0    } else {     for (every video channel)     {       if (minBitrate[channel] >  MinTcodeBitrate[channel])       {         extraBitrate = minBitrate[channel]  − MinTcodeBitrate[channel]         TcodeBitrate[channel] =  TcodeBitrate[channel] + extraBitrate         needBitrate [channel] = Max (0,  needBitrate[channel] − extraBitrate)         AvailableVideoBitrate =  AvailableVideoBitrate − extraBitrate       }     }    } 4. 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)    {     tpeAvailableBitrate = MaxTpeBitrate[tpeIndex]  − sum of TcodeBitrate over the TPE     tpeNeedBitrate = sum of NeedBitrate over the  TPE     for (every channel processed by the TPE)       MaxBitrate[channel] = Min (  MaxTcodeBitrate[channel],     (tpeAvailableBitrate * NeedBitrate[channel] /  tpeNeedBitrate) + TcodeBitrate[channel],         Max ( UserMaxBitrate[channel],  MinTcodeBitrate[channel] ) )  } 5. The QLP assigns the remaining bandwidth in proportion  to the remaining NeedBitrate values.     TotalNeedBitrate = sum of needBitrate over all video channels    for (every video channel) {     TcodeBitrate[channel] = TcodeBitrate[channel]  + (AvailableVideoBitrate * NeedBitrate[channel] /  TotalNeedBitrate)    }    AvailableVideoBitrate = 0 6. The QLP applies the maximum bit rate constraint on the bit rate allocation.    for (every video channel)    {     if ( TcodeBitrate[channel] >  MaxBitrate[channel] )     {       TcodeBitrate [channel] =  MaxBitrate[channel]       AvailableVideoBitrate =  AvailableVideoBitrate + TcodeBitrate[channel] −  MaxBitrate[channel]       NeedBitrate [channel] = 0     }    } 7. The QLP allocates the extra bandwidth collected from the channels that exceed the maximum bit rate.    TotalNeedBitrate = Sum of NeedBitrate over every  channel    if (AvailableVideoBitrate > 0)    {     for (every video channel)     {       extraBitrate = AvailableVideoBitrate *  NeedBitrate[channel] / TotalNeedBitrate     if ( extraBitrate + TcodeBitrate[channel] >  MaxBitrate[channel] )       extraBitrate = MaxBitrate[channel] −  TcodeBitrate[channel]     TcodeBitrate[channel] = TcodeBitrate[channel]  + extraBitrate       AvailableVideoBitrate =  AvailableVideoBitrate − extraBitrate     }    } 8. The QLP allocates the remaining bandwidth in proportion to the difference between the current allocated bit rate and the maximum bit rate.     if (AvailableVideoBitrate > 0)     {       TotalHeadroom = sum of (MaxBitrate[channel] − TcodeBitrate[channel]) over every channel       for (every channel)       {         TcodeBitrate[channel] = TcodeBitrate[channel] + AvailableVideoBitrate * ( MaxBitrate[channel] − TcodeBitrate[channel] ) / TotalHeadroom       }     }   The QLP maintains a queue of the transcoding bit rate for each video channel. In each Tq interrupt, the calculated transcoding bit rate values are stored in the queues, and retrieved 0.5 seconds later to use as transmission bit rate values.

    6.2.7. Initial Target Frame Size Calculation
  • At the last Tq slot of a frame, the QLP calculates an initial value for the target frame size as follows.
  • InitialTargetFrameSize=(OrigFrameSize* AvgInBitrate/AvgTcodeBitrate,
  • where AvgTcodeBitrate is the average transcoding 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
  • At the first Tq interrupt of a frame, 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.
  • PassThroughBitrate=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. The use of 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 > PassThroughBitrate ) {   Pass through the entire frame. } else {   Transcode the frame. }

    6.4. Target Frame Size Calculation
  • 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.
  • 6.4.1. Compute the Maximum Frame Size
  • 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.
  • The value of 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.
  • The value of FifoLevel is the transcoder FIFO level latched by the transcoder. That is, the FifoLevel is read by the transcoder and passed to the QLP.
  • 6.4.2. Compute the Minimum Frame Size
  • 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).
  • As mentioned before, for MPEG2 Main Profile Main Level, 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).
  • 6.4.4. Compute the Target Frame size
  • 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
  • Within a frame, the following algorithm is used for calculating the quantization scale value for every macroblock to be transcoded. A new quantization scale QNew is calculated by scaling the quantization scale of the input macroblock QOld by a targeted bit reduction ratio, RNew/ROld. Typically, each macroblock has a quantizer scale. However, 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.
  • Initialization:
      • ROld=Original number of bits in the frame.
  • RNew=TargetFrameSize=Target number of bits to be generated by transcoding/requantizing the frame. For every slice, do:   {   QNew = QOld * ROld / RNew   /* Update ROld and RNew after requantizing a slice: */   ROld = ROld − original number of bits in the slice.   RNew = RNew − new number of bits generated by transcoding (e.g., including requantizing) the slice.   }
  • For QNew, rounding to the next higher integer, or to the closest integer, may be used. The above formula should result in the frame being transcoded to the target frame size. The transcoded frame size may go over the target, but it should not exceed the maximum frame size.
  • However, if the maximum frame size is reached very early in the frame, which can happen, e.g., if the quantization scale at the beginning of the frame is low, thereby generating a lot of bits, the quantizer scale is set to the maximum level (coarsest quantizing) and the rest of the frame will consequently have very poor quality. To avoid this, a minimum number of bits per macroblock, mb_budget, are allocated. As the frame is transcoded, if a running count of the number of bits used grows too large, i.e., the number of bits used reaches a certain level, which is adjusted as requantization of the frame progresses, a panic quantizer is set for a short time until there are enough bits left for the remaining macroblocks to have mb_budget number of bits. That is, the panic_level 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: mb_budget = TargetFrameSize number_mbs · ξ panic_level = MaxFrameSize - mb_budget * number_mbs
  • ξ determines the minimum number of bits allocated to each macroblock as a fraction of the average number of bits per macroblock using the frame target size, To. The range is 0<ξ<1. A ξ of ¼-½ may be suitable for most cases. If ξ is too big, the panic condition may be triggered too early; if ξ is zero, then the panic condition may trigger too late, whereby the rest of the frame is stuck in panic mode.
  • After each macroblock is coded,
  • panic_level=panic_level—bits_used_mb+mb_budget if (panic_level<0)
    QMew=MAX_QL;
  • where MAX_QL=112 (e.g., the applicable maximum QL for the system).
  • If the frame size is less than the minimum frame size, zeros are appended to the end of the bitstream, such that the frame size is equal to, or greater than, the minimum frame size.
  • 6.6. PCR Slot
  • The MPEG standard requires the PCR (Program Clock Reference) to be sent at a maximum interval of 100 ms. The actual PCR value is not known until the transmission time, so the transcoder creates a placeholder slot for the PCR.
  • From the target frame size, 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. In satisfying this requirement, note that while uncoded pictures have constant duration ({fraction (1/30)} sec), coded bitstreams 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 2 Mbps, then the duration is 0.05 sec. The amount of time required to transmit the frame (or, more precisely, the time lapse from the time the first bit of the frame leaves the transcoder's output buffer (FIFO) 445 to the time the last bit of the frame leaves the FIFO) is estimated as:
  • TxFrameDuration=TargetFrameSize/(minimum value in the transmission bit rate queue).
  • The minimum number of PCRs to insert during the frame is:
  • MinPcrCount=TxFrameDuration/MaxPcrSeparation, round up to the nearest integer,
  • where MaxPcrSeparation is the maximum separation between PCRs as required by MPEG (100 ms). The value of MaxPcrSeparation=80 ms is used to provide a 20 ms margin.
  • Accordingly, it can be seen that the present invention provides an efficient statistical remultiplexer for processing data in a number of channels that include video data. In one aspect of the invention, 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 delaying.
  • In another aspect of the invention, 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, and so forth.
  • In yet another aspect of the invention, 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. Moreover, 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.
  • Although the invention has been described in connection with various preferred embodiments, it should be appreciated that various modifications and adaptations may be made thereto without departing from the scope of the invention as set forth in the claims.

Claims (24)

1. A method for processing data in a statistical remultiplexer that receives a plurality of channels of encoded data, comprising:
recovering video frames from the encoded data;
storing the video frames in a lookahead buffer in order to delay transcoding of the video frames while obtaining statistical information therefrom;
determining respective bit rate need parameters for the video frames according to the obtained statistical information thereof; and
transcoding the respective video frames in accordance with the respective bit rate need parameters following the delaying thereof.
2. The method of claim 1, further comprising:
storing the respective bit rate need parameters in a storage device; and
recovering the bit rate need parameters from the storage device for the respective video frames for use in transcoding thereof.
3. The method of claim 1, wherein:
the statistical information of a respective video frame that is used for determining the respective bit rate need parameter comprises an average quantizer scale value thereof.
4. The method of claim 1, wherein:
the statistical information of a respective video frame that is used for determining the respective bit rate need parameter comprises a number of bits therein.
5. The method of claim 1, wherein:
the statistical information of a respective video frame that is used for determining the respective bit rate need parameter comprises an average bit rate associated therewith.
6. The method of claim 1, wherein:
the statistical information of a respective video frame that is used for determining the respective bit rate need parameter comprises a number of bits in macroblocks therein.
7. The method of claim 1, wherein:
the statistical information of a respective video frame that is used for determining the respective bit rate need parameter comprises a macroblock resolution thereof.
8. A statistical remultiplexer that receives a plurality of channels of encoded data, comprising:
means for recovering video frames from the encoded data;
means for storing the video frames in order to delay transcoding of the video frames while obtaining statistical information therefrom;
means for determining respective bit rate need parameters for the video frames according to the obtained statistical information thereof; and
means for transcoding the respective video frames in accordance with the respective bit rate need parameters following the delaying thereof.
9. A method for processing data in a statistical remultiplexer that receives a plurality of channels comprising encoded video frames, comprising:
updating a transcoding bit rate for at least a particular video frame a plurality of times at successive intervals as transcoding thereof progresses;
bounding the updated transcoding bit rates by at least one of minimum and maximum levels that are also updated in each of the successive intervals to provide corresponding bounded and updated transcoding bit rates;
allocating the bounded and updated transcoding bit rates for transcoding corresponding portions of the particular video frame in the successive intervals;
computing a target frame size for the particular video frame that indicates an amount of data that is expected to result from transcoding the particular video frame; wherein:
the target frame size is bounded by at least one of minimum and maximum predicted values that are updated in the successive intervals;
the transcoding bit rate for the particular video frame in the successive intervals is determined in accordance with the target frame size.
10. The method of claim 9, wherein:
the successive intervals are periodic.
11. The method of claim 9, wherein:
the updated transcoding bit rates are bounded by both minimum and maximum levels that are updated in each of the successive intervals to provide the corresponding bounded and updated transcoding bit rates.
12. The method of claim 9, wherein:
video frames whose associated target frame size is greater than a number of pre-transcoding bits thereof bypass transcoding.
13. The method of claim 9, wherein:
video frames whose associated target frame size is greater than a number of pre-transcoding bits thereof by a predetermined difference bypass transcoding.
14. The method of claim 9, further comprising:
allocating a variable amount of transmission bandwidth for passthrough data of the plurality of channels; and
adjusting an amount of transmission bandwidth for transcoding the video frames in the plurality of channels in accordance with said allocating step.
15. The method of claim 9, wherein:
the statistical remultiplexer outputs a transport stream comprising a plurality of statistical remultiplexing groups of channels; and
respective portions of a total available transmission bandwidth are used to configure respective ones of the statistical remultiplexing groups.
16. The method of claim 9, further comprising:
delaying the updated and bounded transcoding bit rates in the successive intervals according to a delay associated with an associated transcoding engine; and
allocating transmission bit rates in accordance with the updated and bounded transcoding bit rates after the delaying thereof for transmitting the particular video frame after transcoding thereof.
17. The method of claim 16, further comprising:
providing a number of packets of the particular video frame after transcoding thereof to a multiplexer for multiplexing with packets of at least one other of the channels in accordance with the allocated transmission bit rates.
18. The method of claim 9, wherein:
the at least one of minimum and maximum predicted values are determined in accordance with a current fullness of an associated transcoding engine buffer.
19. The method of claim 9, wherein:
the at least one of minimum and maximum predicted values are determined so as to protect an associated decoder buffer from underflow or overflow.
20. The method of claim 9, further comprising:
estimating a time for transmitting at least one packet comprising transcoded data of the particular video frame according to the target frame size.
21. The method of claim 9, further comprising:
estimating a time for inserting clock reference data into at least one packet comprising transcoded data of the particular video frame according to the target frame size.
22. A statistical remultiplexer that receives a plurality of channels comprising encoded video frames, comprising:
means for updating a transcoding bit rate for at least a particular video frame a plurality of times at successive intervals as transcoding thereof progresses;
means for bounding the updated transcoding bit rates by at least one of minimum and maximum levels that are also updated in each of the successive intervals to provide corresponding bounded and updated transcoding bit rates; and
means for allocating the bounded and updated transcoding bit rates for transcoding corresponding portions of the particular video frame in the successive intervals;
means for computing a target frame size for the particular video frame that indicates an amount of data that is expected to result from transcoding the particular video frame; wherein:
the target frame size is bounded by at least one of minimum and maximum predicted values that are updated in the successive intervals;
the transcoding bit rate for the particular video frame in the successive intervals is determined in accordance with the target frame size.
23. A statistical remultiplexer in accordance with claim 22, wherein:
video frames whose associated target frame size is greater than a number of pre-transcoding bits thereof by a predetermined difference bypass transcoding.
24. A statistical remultiplexer in accordance with claim 22, further comprising:
means for estimating a time for inserting clock reference data into at least one packet comprising transcoded data of the particular video frame according to the target frame size.
US10/945,641 2000-09-25 2004-09-20 Statistical remultiplexing with bandwidth allocation among different transcoding channels Abandoned US20050041689A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US09/669,517 US6847656B1 (en) 2000-09-25 2000-09-25 Statistical remultiplexing with bandwidth allocation among different transcoding channels
US10/945,641 US20050041689A1 (en) 2000-09-25 2004-09-20 Statistical remultiplexing with bandwidth allocation among different transcoding channels

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US10/945,641 US20050041689A1 (en) 2000-09-25 2004-09-20 Statistical remultiplexing with bandwidth allocation among different transcoding channels

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US09/669,517 Division US6847656B1 (en) 2000-09-25 2000-09-25 Statistical remultiplexing with bandwidth allocation among different transcoding channels

Publications (1)

Publication Number Publication Date
US20050041689A1 true US20050041689A1 (en) 2005-02-24

Family

ID=24686625

Family Applications (2)

Application Number Title Priority Date Filing Date
US09/669,517 Active 2022-10-03 US6847656B1 (en) 2000-09-25 2000-09-25 Statistical remultiplexing with bandwidth allocation among different transcoding channels
US10/945,641 Abandoned US20050041689A1 (en) 2000-09-25 2004-09-20 Statistical remultiplexing with bandwidth allocation among different transcoding channels

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US09/669,517 Active 2022-10-03 US6847656B1 (en) 2000-09-25 2000-09-25 Statistical remultiplexing with bandwidth allocation among different transcoding channels

Country Status (9)

Country Link
US (2) US6847656B1 (en)
EP (1) EP1320997A2 (en)
KR (1) KR20030061809A (en)
CN (1) CN100459705C (en)
AU (1) AU9059901A (en)
CA (1) CA2421794C (en)
MX (1) MXPA03002527A (en)
TW (1) TW529308B (en)
WO (1) WO2002028108A2 (en)

Cited By (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050005304A1 (en) * 2003-05-07 2005-01-06 Ajai Kaul Superframe planning technique for DVB-RCS networks
US20050008074A1 (en) * 2003-06-25 2005-01-13 Van Beek Petrus J.L. Wireless video transmission system
US20050071876A1 (en) * 2003-09-30 2005-03-31 Van Beek Petrus J. L. Wireless video transmission system
US20060095942A1 (en) * 2004-10-30 2006-05-04 Van Beek Petrus J Wireless video transmission system
US20060095944A1 (en) * 2004-10-30 2006-05-04 Demircin Mehmet U Sender-side bandwidth estimation for video transmission with receiver packet buffer
US20060095943A1 (en) * 2004-10-30 2006-05-04 Demircin Mehmet U Packet scheduling for video transmission with sender queue control
US20060242240A1 (en) * 2005-03-28 2006-10-26 Parker Alistair J Milestone synchronization in broadcast multimedia streams
US20060256861A1 (en) * 2001-11-21 2006-11-16 Vixs Systems, Inc. Method and system for rate control during video transcoding
US7173947B1 (en) * 2001-11-28 2007-02-06 Cisco Technology, Inc. Methods and apparatus to evaluate statistical remultiplexer performance
US20070067480A1 (en) * 2005-09-19 2007-03-22 Sharp Laboratories Of America, Inc. Adaptive media playout by server media processing for robust streaming
US20070073904A1 (en) * 2005-09-28 2007-03-29 Vixs Systems, Inc. System and method for transrating based on multimedia program type
US20070153916A1 (en) * 2005-12-30 2007-07-05 Sharp Laboratories Of America, Inc. Wireless video transmission system
US20070177519A1 (en) * 2006-01-30 2007-08-02 Thomsen Jan H Systems and methods for transcoding bit streams
US20070177677A1 (en) * 2006-01-30 2007-08-02 Thomsen Jan H Systems and methods for transcoding bit streams
US20070236599A1 (en) * 2006-03-31 2007-10-11 Sharp Laboratories Of America, Inc. Accelerated media coding for robust low-delay video streaming over time-varying and bandwidth limited channels
US20080069201A1 (en) * 2006-09-18 2008-03-20 Sharp Laboratories Of America, Inc. Distributed channel time allocation for video streaming over wireless networks
US20080080619A1 (en) * 2006-09-26 2008-04-03 Dilithium Holdings, Inc. Method and apparatus for compressed video bitstream conversion with reduced-algorithmic-delay
US20080107173A1 (en) * 2006-11-03 2008-05-08 Sharp Laboratories Of America, Inc. Multi-stream pro-active rate adaptation for robust video transmission
US20080165803A1 (en) * 2007-01-08 2008-07-10 General Instrument Corporation Method and Apparatus for Statistically Multiplexing Services
US20090213929A1 (en) * 2008-02-26 2009-08-27 Megachips Corporation Transcoder
US20100014510A1 (en) * 2006-04-28 2010-01-21 National Ict Australia Limited Packet based communications
US20100201549A1 (en) * 2007-10-24 2010-08-12 Cambridge Silicon Radio Limited Bitcount determination for iterative signal coding
US20110134997A1 (en) * 2008-08-05 2011-06-09 Nobumasa Narimatsu Transcoder
US8018850B2 (en) 2004-02-23 2011-09-13 Sharp Laboratories Of America, Inc. Wireless video transmission system
US20110235993A1 (en) * 2010-03-23 2011-09-29 Vixs Systems, Inc. Audio-based chapter detection in multimedia stream
US20120206610A1 (en) * 2011-02-11 2012-08-16 Beibei Wang Video quality monitoring
WO2014066434A3 (en) * 2012-10-22 2014-07-10 General Instrument Corporation Improved algorithms for determining bitrate for a statistical multiplexing system to account for signal complexity including film mode and gop structural changes
US20140328401A1 (en) * 2008-12-05 2014-11-06 Motorola Mobility Llc Bi-directional video compression for real-time video streams during transport in a packet switched network
US8953672B2 (en) * 2009-05-18 2015-02-10 Mobiclip Method and device for compressing a video sequence

Families Citing this family (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19946267C2 (en) * 1999-09-27 2002-09-26 Harman Becker Automotive Sys digital Transcodiersystem
US7054362B1 (en) * 2001-05-29 2006-05-30 Cisco Technology, Inc. Methods and apparatus for updating a reduction ratio
US7675972B1 (en) 2001-07-30 2010-03-09 Vixs Systems, Inc. System and method for multiple channel video transcoding
US7403564B2 (en) * 2001-11-21 2008-07-22 Vixs Systems, Inc. System and method for multiple channel video transcoding
KR100430525B1 (en) * 2001-12-17 2004-05-10 한국전자통신연구원 An apparatus and method for processing the transport stream packet in cable broadcasting system, and apparatus for generating time-delay at the transmission stream packet therefor
US7292602B1 (en) * 2001-12-27 2007-11-06 Cisco Techonology, Inc. Efficient available bandwidth usage in transmission of compressed video data
US7418037B1 (en) * 2002-07-15 2008-08-26 Apple Inc. Method of performing rate control for a compression system
US7529276B1 (en) 2002-09-03 2009-05-05 Cisco Technology, Inc. Combined jitter and multiplexing systems and methods
US7804897B1 (en) * 2002-12-16 2010-09-28 Apple Inc. Method for implementing an improved quantizer in a multimedia compression and encoding system
US7940843B1 (en) 2002-12-16 2011-05-10 Apple Inc. Method of implementing improved rate control for a multimedia compression and encoding system
US20040193289A1 (en) * 2002-12-31 2004-09-30 Shi Chen Decoding system and method
US7925770B1 (en) 2003-01-29 2011-04-12 Realnetworks, Inc. Systems and methods for selecting buffering time for media data
US7352809B2 (en) * 2003-02-21 2008-04-01 Polycom, Inc. System and method for optimal transmission of a multitude of video pictures to one or more destinations
WO2005011255A2 (en) * 2003-06-26 2005-02-03 Thomson Licensing S.A. Multipass video rate control to match sliding window channel constraints
US7453852B2 (en) * 2003-07-14 2008-11-18 Lucent Technologies Inc. Method and system for mobility across heterogeneous address spaces
WO2005025227A1 (en) * 2003-09-05 2005-03-17 General Instrument Corporation Methods and apparatus to improve the rate control during splice transitions
US20060133513A1 (en) * 2004-12-22 2006-06-22 Kounnas Michael K Method for processing multimedia streams
JP2006203682A (en) * 2005-01-21 2006-08-03 Nec Corp Converting device of compression encoding bit stream for moving image at syntax level and moving image communication system
KR101396675B1 (en) 2006-01-05 2014-05-16 텔레폰악티에볼라겟엘엠에릭슨(펍) Media content management
CN100499821C (en) 2006-08-01 2009-06-10 上海广电(集团)有限公司中央研究院 Method for statistics of multiplex transmission stream
JP4624321B2 (en) * 2006-08-04 2011-02-02 Nttエレクトロニクス株式会社 Transcoder and coded image conversion method
US7885189B2 (en) * 2006-09-20 2011-02-08 Rgb Networks, Inc. Methods and apparatus for rate estimation and predictive rate control
US20080101405A1 (en) * 2006-10-26 2008-05-01 General Instrument Corporation Method and Apparatus for Dynamic Bandwidth Allocation of Video Over a Digital Subscriber Line
US8594191B2 (en) * 2008-01-03 2013-11-26 Broadcom Corporation Video processing system and transcoder for use with layered video coding and methods for use therewith
US20100333149A1 (en) * 2009-06-24 2010-12-30 Rgb Networks, Inc. Delivery of pre-statistically multiplexed streams in a vod system
US9374580B2 (en) * 2010-08-23 2016-06-21 Telefonaktiebolaget Lm Ericsson (Publ) System and method for insertion of a program clock reference during packetization of an encoded data stream
US9462333B2 (en) 2010-09-27 2016-10-04 Intel Corporation Method for processing multimedia streams
US9118939B2 (en) 2010-12-20 2015-08-25 Arris Technology, Inc. SVC-to-AVC rewriter with open-loop statistical multiplexer
US9185424B2 (en) * 2011-07-05 2015-11-10 Qualcomm Incorporated Image data compression
CN104835167B (en) * 2015-05-15 2017-05-24 张立华 Navigation mark automatic selection method based on maximum coverage of space influence domain
WO2017168206A1 (en) * 2016-03-29 2017-10-05 Huawei Technologies Canada Co., Ltd. Systems and methods for performing traffic engineering in a communications network

Citations (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5477397A (en) * 1993-02-23 1995-12-19 Matsushita Electric Corporation Of America Digital high definition television receiver with features that facilitate trick-play modes on a digital VCR
US5566208A (en) * 1994-03-17 1996-10-15 Philips Electronics North America Corp. Encoder buffer having an effective size which varies automatically with the channel bit-rate
US5617142A (en) * 1994-11-08 1997-04-01 General Instrument Corporation Of Delaware Method and apparatus for changing the compression level of a compressed digital signal
US5619733A (en) * 1994-11-10 1997-04-08 International Business Machines Corporation Method and apparatus for synchronizing streaming and non-streaming multimedia devices by controlling the play speed of the non-streaming device in response to a synchronization signal
US5623312A (en) * 1994-12-22 1997-04-22 Lucent Technologies Inc. Compressed-domain bit rate reduction system
US5650860A (en) * 1995-12-26 1997-07-22 C-Cube Microsystems, Inc. Adaptive quantization
US5686963A (en) * 1995-12-26 1997-11-11 C-Cube Microsystems Method for performing rate control in a video encoder which provides a bit budget for each frame while employing virtual buffers and virtual buffer verifiers
US5694170A (en) * 1995-04-06 1997-12-02 International Business Machines Corporation Video compression using multiple computing agents
US5701160A (en) * 1994-07-22 1997-12-23 Hitachi, Ltd. Image encoding and decoding apparatus
US5719986A (en) * 1995-05-02 1998-02-17 Sony Corporation Video signal encoding method
US5805220A (en) * 1995-02-22 1998-09-08 U.S. Philips Corporation System for transmitting a plurality of video programs simultaneously through a transmission channel
US5923814A (en) * 1993-01-13 1999-07-13 Hitachi America, Ltd. Methods and apparatus for performing video data reduction operations and for concealing the visual effects of data reduction operations
US5933500A (en) * 1996-05-31 1999-08-03 Thomson Consumer Electronics, Inc. Adaptive decoding system for processing encrypted and non-encrypted broadcast, cable or satellite video data
US5949490A (en) * 1997-07-08 1999-09-07 Tektronix, Inc. Distributing video buffer rate control over a parallel compression architecture
US6052384A (en) * 1997-03-21 2000-04-18 Scientific-Atlanta, Inc. Using a receiver model to multiplex variable-rate bit streams having timing constraints
US6167084A (en) * 1998-08-27 2000-12-26 Motorola, Inc. Dynamic bit allocation for statistical multiplexing of compressed and uncompressed digital video signals
US6192083B1 (en) * 1996-12-31 2001-02-20 C-Cube Semiconductor Ii Statistical multiplexed video encoding using pre-encoding a priori statistics and a priori and a posteriori statistics
US6275507B1 (en) * 1997-09-26 2001-08-14 International Business Machines Corporation Transport demultiplexor for an MPEG-2 compliant data stream
US6327275B1 (en) * 1998-05-19 2001-12-04 General Instrument Corporation Remultiplexing variable rate bitstreams using a delay buffer and rate estimation
US6351474B1 (en) * 1998-01-14 2002-02-26 Skystream Networks Inc. Network distributed remultiplexer for video program bearing transport streams
US6483543B1 (en) * 1998-07-27 2002-11-19 Cisco Technology, Inc. System and method for transcoding multiple channels of compressed video streams using a self-contained data unit
US20030185456A1 (en) * 1998-08-07 2003-10-02 Kazushi Sato Picture decoding method and apparatus
US6643327B1 (en) * 2000-05-05 2003-11-04 General Instrument Corporation Statistical multiplexer and remultiplexer that accommodates changes in structure of group of pictures
US6724825B1 (en) * 2000-09-22 2004-04-20 General Instrument Corporation Regeneration of program clock reference data for MPEG transport streams
US7292602B1 (en) * 2001-12-27 2007-11-06 Cisco Techonology, Inc. Efficient available bandwidth usage in transmission of compressed video data

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR950014858B1 (en) 1993-06-04 1995-12-16 배순훈 Digital image recording apparatus
DE69730419T2 (en) 1996-04-12 2005-09-08 Imedia Corp., San Francisco System for distributing compressed video signals, with statistical multiplexer with transcoders
EP0851656A1 (en) 1996-12-23 1998-07-01 HE HOLDINGS, INC. dba HUGHES ELECTRONICS System and method for high resolution video compression by tiling
US6240103B1 (en) 1997-03-21 2001-05-29 Scientific-Atlanta, Inc. Method and apparatus for detecting and preventing bandwidth overflow in a statistical multiplexer
JPH11196414A (en) 1997-11-06 1999-07-21 Thomson Broadcast Syst Device for processing encoded video data and system for distributing program using the device
CN1328748A (en) 1998-10-02 2001-12-26 通用仪器公司 Method and apparatus for providing rate control in video encoder
AU762996B2 (en) 1999-02-09 2003-07-10 Motorola Australia Pty Ltd An image compression system and method of determining quantisation parameters therefor

Patent Citations (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5923814A (en) * 1993-01-13 1999-07-13 Hitachi America, Ltd. Methods and apparatus for performing video data reduction operations and for concealing the visual effects of data reduction operations
US5477397A (en) * 1993-02-23 1995-12-19 Matsushita Electric Corporation Of America Digital high definition television receiver with features that facilitate trick-play modes on a digital VCR
US5566208A (en) * 1994-03-17 1996-10-15 Philips Electronics North America Corp. Encoder buffer having an effective size which varies automatically with the channel bit-rate
US5701160A (en) * 1994-07-22 1997-12-23 Hitachi, Ltd. Image encoding and decoding apparatus
US5617142A (en) * 1994-11-08 1997-04-01 General Instrument Corporation Of Delaware Method and apparatus for changing the compression level of a compressed digital signal
US5619733A (en) * 1994-11-10 1997-04-08 International Business Machines Corporation Method and apparatus for synchronizing streaming and non-streaming multimedia devices by controlling the play speed of the non-streaming device in response to a synchronization signal
US5623312A (en) * 1994-12-22 1997-04-22 Lucent Technologies Inc. Compressed-domain bit rate reduction system
US5805220A (en) * 1995-02-22 1998-09-08 U.S. Philips Corporation System for transmitting a plurality of video programs simultaneously through a transmission channel
US5694170A (en) * 1995-04-06 1997-12-02 International Business Machines Corporation Video compression using multiple computing agents
US5719986A (en) * 1995-05-02 1998-02-17 Sony Corporation Video signal encoding method
US5686963A (en) * 1995-12-26 1997-11-11 C-Cube Microsystems Method for performing rate control in a video encoder which provides a bit budget for each frame while employing virtual buffers and virtual buffer verifiers
US5650860A (en) * 1995-12-26 1997-07-22 C-Cube Microsystems, Inc. Adaptive quantization
US5933500A (en) * 1996-05-31 1999-08-03 Thomson Consumer Electronics, Inc. Adaptive decoding system for processing encrypted and non-encrypted broadcast, cable or satellite video data
US6192083B1 (en) * 1996-12-31 2001-02-20 C-Cube Semiconductor Ii Statistical multiplexed video encoding using pre-encoding a priori statistics and a priori and a posteriori statistics
US6052384A (en) * 1997-03-21 2000-04-18 Scientific-Atlanta, Inc. Using a receiver model to multiplex variable-rate bit streams having timing constraints
US6570888B1 (en) * 1997-03-21 2003-05-27 Scientific-Atlanta, Inc. Using a receiver model to multiplex variable-rate bit streams having timing constraints
US5949490A (en) * 1997-07-08 1999-09-07 Tektronix, Inc. Distributing video buffer rate control over a parallel compression architecture
US6275507B1 (en) * 1997-09-26 2001-08-14 International Business Machines Corporation Transport demultiplexor for an MPEG-2 compliant data stream
US6351474B1 (en) * 1998-01-14 2002-02-26 Skystream Networks Inc. Network distributed remultiplexer for video program bearing transport streams
US6327275B1 (en) * 1998-05-19 2001-12-04 General Instrument Corporation Remultiplexing variable rate bitstreams using a delay buffer and rate estimation
US6483543B1 (en) * 1998-07-27 2002-11-19 Cisco Technology, Inc. System and method for transcoding multiple channels of compressed video streams using a self-contained data unit
US20030185456A1 (en) * 1998-08-07 2003-10-02 Kazushi Sato Picture decoding method and apparatus
US6167084A (en) * 1998-08-27 2000-12-26 Motorola, Inc. Dynamic bit allocation for statistical multiplexing of compressed and uncompressed digital video signals
US6643327B1 (en) * 2000-05-05 2003-11-04 General Instrument Corporation Statistical multiplexer and remultiplexer that accommodates changes in structure of group of pictures
US6724825B1 (en) * 2000-09-22 2004-04-20 General Instrument Corporation Regeneration of program clock reference data for MPEG transport streams
US7292602B1 (en) * 2001-12-27 2007-11-06 Cisco Techonology, Inc. Efficient available bandwidth usage in transmission of compressed video data

Cited By (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060256861A1 (en) * 2001-11-21 2006-11-16 Vixs Systems, Inc. Method and system for rate control during video transcoding
US9036698B2 (en) * 2001-11-21 2015-05-19 Vixs Systems Inc. Method and system for rate control during video transcoding
US10129552B2 (en) 2001-11-21 2018-11-13 Vixs Systems Inc. Method and system for rate control during video transcoding
US7173947B1 (en) * 2001-11-28 2007-02-06 Cisco Technology, Inc. Methods and apparatus to evaluate statistical remultiplexer performance
US20050005304A1 (en) * 2003-05-07 2005-01-06 Ajai Kaul Superframe planning technique for DVB-RCS networks
US20050008074A1 (en) * 2003-06-25 2005-01-13 Van Beek Petrus J.L. Wireless video transmission system
US7274740B2 (en) * 2003-06-25 2007-09-25 Sharp Laboratories Of America, Inc. Wireless video transmission system
US9325998B2 (en) 2003-09-30 2016-04-26 Sharp Laboratories Of America, Inc. Wireless video transmission system
US20050071876A1 (en) * 2003-09-30 2005-03-31 Van Beek Petrus J. L. Wireless video transmission system
US8018850B2 (en) 2004-02-23 2011-09-13 Sharp Laboratories Of America, Inc. Wireless video transmission system
US20060095944A1 (en) * 2004-10-30 2006-05-04 Demircin Mehmet U Sender-side bandwidth estimation for video transmission with receiver packet buffer
US7797723B2 (en) 2004-10-30 2010-09-14 Sharp Laboratories Of America, Inc. Packet scheduling for video transmission with sender queue control
US20060095943A1 (en) * 2004-10-30 2006-05-04 Demircin Mehmet U Packet scheduling for video transmission with sender queue control
US7784076B2 (en) 2004-10-30 2010-08-24 Sharp Laboratories Of America, Inc. Sender-side bandwidth estimation for video transmission with receiver packet buffer
US20060095942A1 (en) * 2004-10-30 2006-05-04 Van Beek Petrus J Wireless video transmission system
US8356327B2 (en) 2004-10-30 2013-01-15 Sharp Laboratories Of America, Inc. Wireless video transmission system
US7668914B2 (en) * 2005-03-28 2010-02-23 Alcatel Lucent Milestone synchronization in broadcast multimedia streams
US20060242240A1 (en) * 2005-03-28 2006-10-26 Parker Alistair J Milestone synchronization in broadcast multimedia streams
US20070067480A1 (en) * 2005-09-19 2007-03-22 Sharp Laboratories Of America, Inc. Adaptive media playout by server media processing for robust streaming
US9258605B2 (en) * 2005-09-28 2016-02-09 Vixs Systems Inc. System and method for transrating based on multimedia program type
US20070073904A1 (en) * 2005-09-28 2007-03-29 Vixs Systems, Inc. System and method for transrating based on multimedia program type
US20100145488A1 (en) * 2005-09-28 2010-06-10 Vixs Systems, Inc. Dynamic transrating based on audio analysis of multimedia content
US20100150449A1 (en) * 2005-09-28 2010-06-17 Vixs Systems, Inc. Dynamic transrating based on optical character recognition analysis of multimedia content
US9544602B2 (en) 2005-12-30 2017-01-10 Sharp Laboratories Of America, Inc. Wireless video transmission system
US20070153916A1 (en) * 2005-12-30 2007-07-05 Sharp Laboratories Of America, Inc. Wireless video transmission system
US20070177519A1 (en) * 2006-01-30 2007-08-02 Thomsen Jan H Systems and methods for transcoding bit streams
US20070177677A1 (en) * 2006-01-30 2007-08-02 Thomsen Jan H Systems and methods for transcoding bit streams
US8068541B2 (en) * 2006-01-30 2011-11-29 Jan Harding Thomsen Systems and methods for transcoding bit streams
US7652994B2 (en) 2006-03-31 2010-01-26 Sharp Laboratories Of America, Inc. Accelerated media coding for robust low-delay video streaming over time-varying and bandwidth limited channels
US20070236599A1 (en) * 2006-03-31 2007-10-11 Sharp Laboratories Of America, Inc. Accelerated media coding for robust low-delay video streaming over time-varying and bandwidth limited channels
US20100014510A1 (en) * 2006-04-28 2010-01-21 National Ict Australia Limited Packet based communications
US8861597B2 (en) 2006-09-18 2014-10-14 Sharp Laboratories Of America, Inc. Distributed channel time allocation for video streaming over wireless networks
US20080069201A1 (en) * 2006-09-18 2008-03-20 Sharp Laboratories Of America, Inc. Distributed channel time allocation for video streaming over wireless networks
US8837605B2 (en) * 2006-09-26 2014-09-16 Onmobile Global Limited Method and apparatus for compressed video bitstream conversion with reduced-algorithmic-delay
US20080080619A1 (en) * 2006-09-26 2008-04-03 Dilithium Holdings, Inc. Method and apparatus for compressed video bitstream conversion with reduced-algorithmic-delay
US7652993B2 (en) 2006-11-03 2010-01-26 Sharp Laboratories Of America, Inc. Multi-stream pro-active rate adaptation for robust video transmission
US20080107173A1 (en) * 2006-11-03 2008-05-08 Sharp Laboratories Of America, Inc. Multi-stream pro-active rate adaptation for robust video transmission
US20080165803A1 (en) * 2007-01-08 2008-07-10 General Instrument Corporation Method and Apparatus for Statistically Multiplexing Services
US7843824B2 (en) * 2007-01-08 2010-11-30 General Instrument Corporation Method and apparatus for statistically multiplexing services
US20100201549A1 (en) * 2007-10-24 2010-08-12 Cambridge Silicon Radio Limited Bitcount determination for iterative signal coding
US8217811B2 (en) * 2007-10-24 2012-07-10 Cambridge Silicon Radio Limited Bitcount determination for iterative signal coding
US8780977B2 (en) * 2008-02-26 2014-07-15 Megachips Corporation Transcoder
US20090213929A1 (en) * 2008-02-26 2009-08-27 Megachips Corporation Transcoder
US8615040B2 (en) * 2008-08-05 2013-12-24 Megachips Corporation Transcoder for converting a first stream into a second stream using an area specification and a relation determining function
US20110134997A1 (en) * 2008-08-05 2011-06-09 Nobumasa Narimatsu Transcoder
US20140328401A1 (en) * 2008-12-05 2014-11-06 Motorola Mobility Llc Bi-directional video compression for real-time video streams during transport in a packet switched network
US9253063B2 (en) * 2008-12-05 2016-02-02 Google Technology Holdings LLC Bi-directional video compression for real-time video streams during transport in a packet switched network
US8953672B2 (en) * 2009-05-18 2015-02-10 Mobiclip Method and device for compressing a video sequence
US20110235993A1 (en) * 2010-03-23 2011-09-29 Vixs Systems, Inc. Audio-based chapter detection in multimedia stream
US8422859B2 (en) 2010-03-23 2013-04-16 Vixs Systems Inc. Audio-based chapter detection in multimedia stream
US8885050B2 (en) * 2011-02-11 2014-11-11 Dialogic (Us) Inc. Video quality monitoring
US20120206610A1 (en) * 2011-02-11 2012-08-16 Beibei Wang Video quality monitoring
WO2014066434A3 (en) * 2012-10-22 2014-07-10 General Instrument Corporation Improved algorithms for determining bitrate for a statistical multiplexing system to account for signal complexity including film mode and gop structural changes

Also Published As

Publication number Publication date
CN1504051A (en) 2004-06-09
US6847656B1 (en) 2005-01-25
CN100459705C (en) 2009-02-04
MXPA03002527A (en) 2003-10-06
AU9059901A (en) 2002-04-08
WO2002028108A2 (en) 2002-04-04
TW529308B (en) 2003-04-21
WO2002028108A3 (en) 2002-10-31
EP1320997A2 (en) 2003-06-25
CA2421794A1 (en) 2002-04-04
KR20030061809A (en) 2003-07-22
CA2421794C (en) 2013-06-25

Similar Documents

Publication Publication Date Title
US6937770B1 (en) Adaptive bit rate control for rate reduction of MPEG coded video
US6891854B2 (en) System and method for transporting a compressed video and data bit stream over a communication channel
DE60023576T2 (en) Method and apparatus for moving picture data transcoding
EP0912063B1 (en) A method for computational graceful degradation in an audiovisual compression system
US6192083B1 (en) Statistical multiplexed video encoding using pre-encoding a priori statistics and a priori and a posteriori statistics
US5805224A (en) Method and device for transcoding video signals
EP0981249B1 (en) Buffer system for controlled and synchronised presentation of MPEG-2 data services
US5541852A (en) Device, method and system for variable bit-rate packet video communications
US5398072A (en) Management of channel buffer in video decoders
US6480539B1 (en) Video encoding method and apparatus
CN1235406C (en) System and data format for providing seamless stream switching in digital video decoder
US5691986A (en) Methods and apparatus for the editing and insertion of data into an encoded bitstream
JP3130294B2 (en) Apparatus and method for segmenting and time synchronization of the transmission of the multimedia data
US6754241B1 (en) Computer system for statistical multiplexing of bitstreams
US6956901B2 (en) Control strategy for dynamically encoding multiple streams of video data in parallel for multiplexing onto a constant bit rate channel
US5764298A (en) Digital data transcoder with relaxed internal decoder/coder interface frame jitter requirements
US6925501B2 (en) Multi-rate transcoder for digital streams
US6542518B1 (en) Transport stream generating device and method, and program transmission device
EP1472801B1 (en) A stream based bitrate transcoder for mpeg coded video
US6665872B1 (en) Latency-based statistical multiplexing
US6611624B1 (en) System and method for frame accurate splicing of compressed bitstreams
US5566208A (en) Encoder buffer having an effective size which varies automatically with the channel bit-rate
CA2237689C (en) Method and apparatus for multiplexing video programs
EP0550843B1 (en) Statistical multiplexer for a multichannel image compression system and demultiplexer
US5629736A (en) Coded domain picture composition for multimedia communications systems

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION