With the increasing popularity of playing streaming audio and video over networks such as the internet, there is a need for optimizing the data transferred from a server to a client such that the client's experience is maximized even if network conditions during playback are inconsistent. Optimizing the client's experience involves choosing a quality level for encoding the audio and video portions of the video playback such that the video can be transferred and reconstructed uninterrupted while preserving the quality of the video content.
The quality level is generally dictated by the bit rate specified for the encoded audio or video portions of the input stream. A higher bit rate generally indicates that a larger amount of information about the original audio or video is encoded and retained, and therefore a more accurate reproduction of the original input audio or video will be presented during video playback. Conversely, a lower bit rate indicates that less information about the original input audio or video is encoded and retained, and thus a less accurate reproduction of the original audio or video will be presented during video playback.
Generally, the bit rate is specified for encoding each of the audio and video based on several factors. The first factor is the network condition between the server and the client. A network connection that can transfer a high amount of data indicates that a higher bit rate can be specified for the input video that is subsequently transferred over the network connection. The second factor is the desired start-up latency. Start-up latency is the delay that a video playback tool experiences when first starting up due to the large amount of data that has to be received, processed, and buffered. The third factor is the tolerance to glitching. Glitching is when video playback has to stop because data is missing. In most cases any amount of start-up latency or glitching is intolerable, and it is therefore desirable to optimize the bit rate specified such that the start-up latency and the glitching are minimized or eliminated.
Currently available commercial streaming media systems rely on multi bit rate (MBR) coding to perform coding rate control. In MBR coding, source video content is encoded into alternative bit streams at different coding rates and typically stored in the same media file at the server. This then allows the content to be streamed in segments or chunks at varying levels of quality corresponding to different coding rates according to the changing network conditions, typically using bit stream switching between segments.
The currently available multi bit rate video streaming systems use a constant bit rate approach to encoding each alternative video stream. However, a typical video will generally include scenes having a wide variety of visual complexity. However, the constant bit rate approach can not efficiently encode video segments with different quality. The constant bit rate approach unnecessarily spends too many bits for encoding low complexity video segments, and conversely the high complexity scenes are allocated too few bits. Consequently, the constant bit rate approach to encoding the alternative streams results in video quality for internet streaming that is undesirable and inconsistent.
The currently available multi bit rate video streaming systems also have a further requirement for the final display resolution to be fixed. By maintaining a fixed display resolution, the video streams at the multiple bit rates can all be decoded and scaled to this same final display resolution in order to achieve a glitch free video presentation. With the fixed display resolution, the various alternative video streams can have a wide range of bit rates from a few megabits per second to a few kilobits per second. One problem is to match an appropriate video resolution to each video stream bit rate. The currently available multi bit rate video streaming systems use a pre-defined encoding resolution, which again may not be well suited to the varying complexity of the video scenes. For low complexity video, the pre-defined resolution may be too small. For complex video, the pre-defined resolution may be too large.
The following Detailed Description concerns techniques (implemented via methods, devices and systems) for multiple bit rate video encoding, which are intended to make better use of the available bits with each bit rate so as to achieve generally higher quality video.
According to one technique described herein, a multiple bit rate video encoder encodes a plurality of video streams for multiple bit rate video streaming with an objective of providing a more consistent video quality. For encoding the highest bit rate video stream, the bit rate at which the stream is encoded is allowed to vary subject to certain constraints: a peak bit rate constraint and an average bit rate constraint. For a lowest bit rate stream, the multiple bit rate video encoder encodes the stream with a constant chunk (a given size group of pictures) rate approach. Video streams at intermediate bit rates are encoded at progressively decreasing variable bit rates (subject to decreasing peak and average bit rate constraints).
According to a further technique described herein, the multiple bit rate video encoder also dynamically varies the video resolution of the streams. For each bit rate, the video encoder dynamically decides the resolution based on the video content of a scene (which may comprise one or more groups of pictures) in order to achieve better visual quality. The multiple bit rate video encoder selects a higher video resolution for groups of pictures that have less complex video content, whereas a lower resolution is assigned for groups of pictures that have higher complexity. This dynamic resolution approach allows the multiple bit rate video encoder to achieve a generally better video quality for a given bit rate.
This Summary is provided to introduce a selection of concepts in a simplified form that is further described below in the Detailed Description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. Additional features and advantages of the invention will be made apparent from the following detailed description of embodiments that proceeds with reference to the accompanying drawings.
The following detailed description concerns various techniques and systems for video encoding using variable bit rate and dynamic resolution to produce video streams at multiple bit rates for streaming. Although the techniques are described in the context of their application to a multiple bit rate streaming application, the techniques can be applied more broadly to other video encoding applications.
The various techniques and tools described herein may be used independently. Some of the techniques and tools may be used in combination. Various techniques are described below with reference to flowcharts of processing acts. The various processing acts shown in the flowcharts may be consolidated into fewer acts or separated into more acts. For the sake of simplicity, the relation of acts shown in a particular flowchart to acts described elsewhere is often not shown. In many cases, the acts in a flowchart can be reordered.
I. Multi Bit Rate Video Streaming
In one specific example implementation, the server 110 is a standard HTTP server without any specialized streaming capability other than the ability to serve files. Because the server 110 does not support any specialized bit rate selection capability, the client 120 must perform all bit rate selection activities. In this implementation, the client 120 performs all bit rate selection activities. For example, the client 120 can perform rate control using the index information obtained from the server 110 (e.g., alone or in combination with other information, such as client buffer information, network bandwidth, etc.). However, in other implementations, some or all of the rate-control functions can occur at the server.
In general, the indexed file for multi bit rate streaming can be used by standard HTTP servers to serve multimedia content at multiple bit rates with bit rate selection (rate control) being performed client-side (e.g., exclusively client-side). Clients can perform rate control by first obtaining index information from the server describing the various bit rates available for streaming segments of a program. Based on the index information, and possibly other information (e.g., network bandwidth, buffer information, etc.), the client can decide which bit rate streaming segments to download from the server to provide a desired user experience (e.g., the best user experience possible based on the available bit rates and current network conditions).
Other types of computing devices (e.g., other than traditional HTTP servers) can provide files using the indexed file. For example, a computing device (e.g., a personal computer, server computer, or special-purpose streaming media server) can use the indexed file layout to serve multimedia content using various file serving protocols (e.g., File Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP), Real Time Streaming Protocol (RTSP), MMS (Microsoft Media Services), etc.).
In order to support bit rate switching, programs are divided into temporal chunks called streaming segments (self-contained units). The server stores each streaming segment at one or more bit rates (e.g., each streaming segment—bit rate combination is a separate streaming segment encoding). Each streaming segment includes one or more available bit rate encodings for a specific track (e.g., a specific audio track, such as an English audio track, or a specific video track) of a program. Clients then determine which bit rate, from the available bit rates (e.g., from the available streaming segment encodings), to download for each streaming segment. For example, a client may obtain a first streaming segment, for a video track, encoded at 250 Kb/sec (kilo-bits per second) (from one or more available streaming segment encodings for the first streaming segment), a second streaming segment, for the video track, encoded at 500 Kb/sec (from one or more available streaming segment encodings for the second streaming segment), and a third streaming segment, for the video track, encoded at 1 Mb/sec (mega-bit per second) (from one or more available streaming segment encodings for the third streaming segment). In the illustrated streaming system 100, each streaming segment contained in the indexed file is encoded by a video encoder at a variable bit rate (VBR) and variable resolution, as described below.
II. Video Encoder Overview
The video encoder 200 processes video pictures. The term “picture” generally refers to source, coded, or reconstructed image data. For progressive video, a picture is a progressive video frame. For interlaced video, a picture may refer to an interlaced video frame, the top field of the frame, or the bottom field of the frame, depending on context.
The video encoder 200 compresses inter-coded, predicted pictures of the input video and intra-coded pictures of the input video. For the sake of presentation,
In general, within the video encoder 200, an inter-coded, predicted frame (as a picture) is represented in terms of prediction from previously reconstructed content (as one or more other pictures, which are typically referred to as reference pictures or anchors). For example, content at a given time is encoded as a progressive P-frame or B-frame, interlaced P-field or B-field, or interlaced P-frame or B-frame. Within the video encoder 200, a prediction residual is the difference between predicted information and corresponding intra-coded frames.
The input video 110 content on the inter-path is encoded as a predicted picture based on motion information. If certain conditions are met, the video encoder 100 uses the pre-calculated motion information from input 120 (as illustrated by selection switch 256), which can be in the form of a set or sequence of motion vector for macroblocks or other sets of samples of the inter-path video picture with respect to one or more reference pictures. In general, the choice to use the pre-calculated motion information can be based on: first, the availability of pre-calculated motion information; and second, which and whether encoding parameters were changed from the previous calculation of the motion information and the parameters used for the current encoding of the video content. In one example, the video encoder will choose not to use the previously calculated motion information from input 130 if the motion information was calculated for encoding the video content with a different video resolution than that which the video encoder is current encoding.
However, the video encoder 100 can instead choose (again illustrated by selection switch 256) to perform new motion estimation for the inter-path video content 110 with motion estimator 258. The motion estimator 258 estimates motion of macroblocks or other sets of samples of the video picture with respect to one or more reference pictures, which represent reconstructions of previously encoded video content frames. The picture store 264 buffers this reconstructed video content 266 as a reference picture or pictures. When multiple reference pictures are used, the multiple reference pictures can be from different temporal directions or the same temporal direction. The motion estimator 258 outputs motion information 260 such as motion vector information.
The motion compensator 262 applies motion vectors to certain reconstructed video content 266 (stored as reference picture(s)) when forming a motion-compensated current picture 268. The difference (if any) between a block of the motion-compensated picture 268 and corresponding block of the original inter-path video picture is the prediction residual 270 for the block. During later reconstruction of the inter-path video frame (e.g., at a video decoder), reconstructed prediction residuals are added to the motion compensated residual video 268 to obtain reconstructed content closer to the original inter-path video 256. In lossy compression, however, some information is still lost from the original inter-path video. Alternatively, a motion estimator and motion compensator apply another type of motion estimation/compensation.
A frequency transformer 280 converts spatial domain video information into frequency domain (i.e., spectral, transform) data. For block-based video content, the frequency transformer 280 applies a DCT, variant of DCT, or other forward block transform to blocks of the samples or prediction residual data, producing blocks of frequency transform coefficients. The frequency transformer 280 may apply an 8×8, 8×4, 4×8, 4×4 or other size frequency transform.
A quantizer 282 then quantizes the blocks of transform coefficients. The quantizer 282 applies non-uniform, scalar quantization to the spectral data with a step size that varies spatially on a picture-by-picture basis, macroblock-by-macroblock basis or other basis. Additionally, in some cases the quantizer varies quantization across color channels of the inter-layer residual video picture. The quantizer 282 can also apply another type of quantization, for example, a uniform or adaptive quantization for at least some spectral data coefficients, or directly quantizes spatial domain data in an encoder system that does not use frequency transformations.
When reconstructed video content is needed for subsequent motion estimation/compensation of an inter-path video picture, an inverse quantizer 290 performs inverse quantization on the quantized spectral data coefficients. An inverse frequency transformer 292 performs an inverse frequency transform, producing blocks of reconstructed prediction residuals (for predicted inter-path residual video content) or samples (for intra-path residual video content). If the residual video content 256 was motion-compensation predicted, the reconstructed prediction residuals are added to the motion-compensated predictors 268 to form the reconstructed residual video. The picture store 264 buffers the reconstructed residual video for use in subsequent motion-compensated prediction.
The entropy coder 284 compresses the output of the quantizer 282 as well as certain side information (e.g., quantization parameter values) Typical entropy coding techniques include arithmetic coding, differential coding, Huffman coding, run length coding, LZ coding, dictionary coding, and combinations of the above. The entropy coder 284 typically uses different coding techniques for different kinds of information, and can choose from among multiple code tables within a particular coding technique.
When the video encoder 240 performs intra-compression of the intra-path video content, the encoder intra-compresses it as an intra-coded picture, without motion compensation. The video 256 is provided directly to the frequency transformer 280, quantizer 282, and entropy coder 284 and output as encoded video. A reconstructed version of the intra-coded video can be buffered for use in subsequent motion compensation of other inter-path video.
A controller 294 receives inputs from various modules such as the motion estimator 258, frequency transformer 280, quantizer 282, inverse quantizer 290, and entropy coder 284. The controller 294 evaluates intermediate results during encoding, for example, setting quantization step sizes and performing rate-distortion analysis. The controller 294 works with other modules to set and change coding parameters during encoding. When the controller 294 evaluates different coding parameter choices, the controller 294 may iteratively perform certain stages to evaluate different parameter settings, or the controller 294 may jointly evaluate different coding parameters. The tree of coding parameter decisions to be evaluated, and the timing of corresponding encoding, depends on implementation. In some embodiments, the controller 294 also receives input from an encoding session wizard interface, other encoder application interface, or other source to designate video to be encoded using specific rules.
III. Variable Bit Rate Encoding of MBR Streams
For the multiple bit rate video streaming system 100 (
In contrast to other currently available multiple bit rate video streaming systems (which use a constant bit rate approach to encoding the multiple video streams), the MBR encoding system for the multiple bit rate video stream system 100 aims at providing a constant or consistent quality for each video stream. For the top MBR video stream (generally having highest overall bit rate), the video encoder 200 encodes the video stream with a varying bit rate constrained to fall under a specified peak bit rate while satisfying a specified average bit rate. For the bottom MBR stream (generally having the lowest bit rate of the set), the video encoder uses a constant chunk rate approach. In the context of the multiple bit rate video streaming system, the term chunk refers to a group of pictures (GOP) into which the video stream are segmented, and define the level of granularity at which the video streaming system may switch playing individual segments between video streams. The constant chunk rate approach enables the video streaming system to guarantee predictability of streaming, in that when the lowest bit rate or quality video stream is streamed, the client will receive the chunk amount of pictures at the constant rate so as to maintain minimum quality continuous playing of the video.
In between the lowest and highest overall bit rate streams, the video encoder encodes one or more intermediate video streams also using variable bit rates of coding within the constraints of a peak bit rate and average bit rate that aim to maintain a constant video quality. The peak and average bit rate constraints of the intermediate video streams can be specified to decrease progressively in a proportional, logarithmic or other decreasing manner. For example, the average bit rate of the intermediate stream can decrease proportionally to be ¾, ½, and ¼ that of the average bit rate constraint of the highest bit rate video stream. In this way, the video streaming system 100 is able to provide an instant start and swift video switching from a guaranteed low constant chunk rate up to a highest quality variable rate bit stream. The peak and average bit rates, as well as the constant chunk rate are encoding parameters that can be configured by the user. These parameters can be configured explicitly by the user, or calculated by the MBR encoding system engine based on more generalized parameters input by the user. For example, the MBR encoding engine can have an automatic mode where the user (or a caller application) simply specifies the minimal and maximal target bit rates and a number of video streams or layers. The engine in this automatic mode then calculates all the intermediate bit rate constraints (peak and average) in a uniform, logarithmic or other distribution space.
With reference now to
The MBR encoding process 300 begins with an initialization step 310. In this step, the MBR encoding process determines the parameters for the encoding from user input, including number of MBR video streams, peak and average bit rate constraints for the streams, and the constant chunk rate of the lowest quality MBR video stream, and segment parameters, among others.
The analysis pass of the MBR encoding process 300 includes actions 311-314. In the analysis pass, the MBR encoding engine analyzes the input source video frame by frame. The analysis includes a number of different tasks including scene change detection, segmenting a video sequence between scene change boundaries into group of picture segments, and video frame complexity measurements. Based on the scene change detection, the MBR encoding engine marks boundaries at which scene changes occur during the video. Between marked boundaries of a video sequence (sequence mark-in and sequence mark-out positions), the MBR encoding process 300 further determines a total number of group of pictures segments in which to divide the video sequence within user-specified constraints (such as a specified average GOP length and maximum allowed GOP length within a scene) and sets boundaries of each group of pictures. Once the GOP boundaries are defined, the total numbers of frames within each GOP is calculated by the MBR encoding engine. The MBR encoding engine also calculates a set of three texture measurements per frame of each group of pictures, which are used in the variable resolution encoding described in the next section. The three texture measurements include a frame global texture, frame horizontal texture and frame vertical texture measurement. The MBR engine writes these analysis pass results (the scene and GOP boundaries, and the texture measurements) into a log file, as indicated at action 314.
For the encoding pass (actions 315-324), the MBR engine applies the results of the analysis pass to encode the MBR video streams using the video encoder 200 (
As a result of the encoding pass, the MBR engine then outputs compressed video bit streams for the set of MBR streams that are produced using the video encoder, as well as a log file. With the variable bit rate approach of this MBR encoding process 300, the MBR engine produces a set of MBR video streams that decreases evenly from a top to bottom quality stream for each GOP. With this set of MBR video streams, the MBR system 100 (
IV. Variable Resolution Encoding of MBR Streams
The MBR encoding engine also applies a technique that dynamically varies resolution of encoding for each of the MBR video streams. For each video stream ranging from the top to bottom of the MBR video streams, the MBR encoding engine dynamically decides the resolution for encoding each video GOP to produce a better visual quality. For each video stream, the MBR encoding engine assigns a higher resolution to a low complexity GOP (or segment), while a more complex GOP (or segment) is assigned a lower resolution of encoding.
In the example implementation, the MBR encoding engine applies the decision to dynamically resize each GOP at scene boundaries of the video. This avoids introducing any undesirable visual effects that resizing video resolution in the middle of a video scene might produce. For example, in a scene featuring a “talking head,” varying the video resolution mid-scene could introduce a noticeable popping or pulsing as the detail edges and features in the scene sharpen or soften along with the resolution change. Accordingly, the MBR encoding engine performs the below described process for the GOP or GOPs of a scene (e.g., for the first GOP after a scene change boundary identified in the analysis phase described above).
In one example implementation of the dynamic resolution encoding, the MBR encoding engine uses a three-point sampling approach to make the dynamic resolution decision. Each sampling point represents the result (in terms of actual encoded bit rate or size) from encoding the GOP using three different pairs of video resolution and quantization step sizes. With these three sampling point results, the MBR engine establishes a model of the relation between resolution, quantization step size and coded size, which relation is illustrated graphically in
In the illustrated model, the MBR video encoding engine performs the encoding for an initial sample resolution and quantization step size parameter pair (R, Qp), as well as at one fourth of the initial sample resolution (i.e., (R/4, Qp)) and at twice the initial sample quantization step size (i.e., (R, Qp*2)). Alternatively, other parameter pairs for the sample points can be used, such as at half resolution, four times the quantization step size, etc. The MBR video encoding engine observes the encoded bit sizes (S1, S2, and S3) that result from encoding the GOP of the video stream with the three resolution and quantization step size parameter pairs.
In a next action 511, the MBR engine establishes two linear models: one for the relation between quantization step size and encoded size (labeled GraphQpS in the diagram of
At action 512, the MBR engine uses the relation of encoded size to quantization step size to find the quantization step size that yields the encoded size corresponding to the desired bit rate. This is the modeled result quantization step size (labeled Qp′) at the full sampling resolution R that should yield the target bit rate for the GOP of the video stream.
The MBR engine then compares the modeled result quantization step size to an empirically determined threshold (determined from experiments measuring video texture over a wide range of video content). If the modeled result quantization step size is smaller than the threshold, then the MBR engine decides to use the full sample resolution and modeled result quantization step size, i.e., (R, Qp′) at action 514.
More specifically, the MBR engine determines the appropriate quantization step threshold based on the per frame texture measurements made during the analysis phase (discussed above) for the input video content. The MBR engine calculates the texture measurements for the GOP by averaging the frame texture measurements for all frames in the GOP. This produces GOP global texture, GOP horizontal texture and GOP vertical texture measurements. Of these, the GOP global texture measurement determines the quantization step size threshold that controls when to resize video resolution. From experimental results over a broad range of video content (including sports, television, movies, etc.), it has been determined that a quantization step size threshold of Qp equal to 12 (for video encoding with the SMPTE 421M standard) is suitable for video with a typical GOP global texture measurement. In other words, if the modeled result quantization step size Qp′ is over 12, then the MBR encoder should resize to a lower video resolution in order to encode at a lower Qp. However, in an example implementation, the MBR encoder can further vary the quantization step size threshold for resizing depending on the overall global texture measurement for the video. The MBR encoder has established a linear relationship between global texture and the quantization step size threshold for resizing. For video having a low overall global texture, a lower quantization step size threshold is expected. This allows the MBR encoder to be more aggressive in resizing down the video resolution of video content having a lot of smooth regions (for which resizing to a lower resolution would tend not to produce artifacts). Whereas, for video with high global texture, the MBR encoder expects a higher quantization step size threshold for resizing. Such higher threshold makes the MBR encoder more careful in resizing down video resolution of frames that have a lot of detail, so as to avoid smoothing of detailed regions of those frames. In alternative implementations, the quantization step size threshold can be established at other quantization step sizes, such as for use with other video encoding standard, or to achieve a desired degree of aggressiveness/caution in resizing the video resolution.
On the other hand at action 515, if the modeled result is larger than the threshold defined by the video texture, the MBR engine instead uses the relation between encoded size and resolution (GraphRS) to find a modeled result resolution (R′) that yields the encoded size corresponding to the target bit rate of the video stream.
The MBR engine further uses the GOP average horizontal and vertical texture measurements to control how much to resize the video resolution in each direction. The MBR engine calculates a ratio of the GOP horizontal and vertical texture measurements. Once it is determined to resize the resolution (action 514), the MBR engine calculates a particular resize amount according to the GraphRS relation. For example, the MBR engine may determine to resize by half the initial resolution. The MBR engine then determines how to distribute the resize amount in the vertical and horizontal directions based on the ratio of GOP horizontal and vertical texture measurement. In particular, if there is a large discrepancy or delta between horizontal and vertical texture measurements (i.e., the ratio is non-unity), the MBR engine distributes the resizing to apply more resizing in the lower detail direction than is applied to the higher detail direction. For example, when the ratio is two, then the MBR engine would resize in the vertical direction twice as much as the horizontal direction. Otherwise, if the delta between the horizontal and vertical texture measurements for the GOP is low (the ratio is near unity), then the MBR engine resizes the resolution equally between the directions.
The MBR engine at action 516 then uses the relations between quantization step size and encoded size (GraphQpS) and between resolution and encoded size (Graph RS) as well as the target bit rate of the respective video stream to establish a relation (GraphQpR shown at top left of
At action 517, the MBR engine then uses the relation (GraphQpR) established in action 516 to find a modeled result of the quantization step size (Qp′) for the modeled result resolution R′ decided at action 515. The MBR engine then decides to encode this GOP of this video stream at the modeled result quantization step size and resolution (R′, Qp′).
By use of this dynamic resolution approach, the MBR encoding system is able to assign a larger encoding resolution to less complex video segments (or GOP), which maintains more visual detail. On the other hand, more complex video segments (or GOP) are assigned a smaller resolution that reduces visual artifacts. This approach has been found to provide a better visual experience for multiple bit rate streaming.
V. Representative Computing Environment
With reference to
The storage 640 may be removable or non-removable, and includes magnetic disks, magnetic tapes or cassettes, CD-ROMs, CD-RWs, DVDs, or any other medium which can be used to store information and which can be accessed within the computing environment 600. The storage 640 stores instructions for the software 680, which can implement technologies described herein.
The input device(s) 650 may be a touch input device, such as a keyboard, keypad, mouse, pen, or trackball, a voice input device, a scanning device, or another device, that provides input to the computing environment 600. For audio, the input device(s) 650 may be a sound card or similar device that accepts audio input in analog or digital form, or a CD-ROM reader that provides audio samples to the computing environment 600. The output device(s) 660 may be a display, printer, speaker, CD-writer, or another device that provides output from the computing environment 600.
The communication connection(s) 670 enable communication over a communication medium (e.g., a connecting network) to another computing entity. The communication medium conveys information such as computer-executable instructions, compressed graphics information, or other data in a modulated data signal.
Computer-readable media are any available media that can be accessed within a computing environment 600. By way of example, and not limitation, with the computing environment 600, computer-readable media include memory 620, storage 640, the communication medium, and combinations of any of the above. As should be readily understood, the term computer-readable storage media includes the media for data storage such as memory 620 and storage 640, and not simply transmission media such as modulated data signals.
Any of the methods described herein can be performed via one or more computer-readable media (e.g., storage or other tangible media) comprising (e.g., having or storing) computer-executable instructions for performing (e.g., causing a computing device, audio and/or video processing device, or computer to perform) such methods. Operation can be fully automatic, semi-automatic, or involve manual intervention.
Having described and illustrated the principles of our innovations in the detailed description and accompanying drawings, it will be recognized that the various embodiments can be modified in arrangement and detail without departing from such principles. It should be understood that the programs, processes, or methods described herein are not related or limited to any particular type of computing environment, unless indicated otherwise. Various types of general purpose or specialized computing environments may be used with or perform operations in accordance with the teachings described herein. Elements of embodiments shown in software may be implemented in hardware and vice versa.
In view of the many possible embodiments to which the principles of our invention may be applied, we claim as our invention all such embodiments as may come within the scope and spirit of the following claims and equivalents thereto.
Number | Name | Date | Kind |
---|---|---|---|
4142071 | Croisier et al. | Feb 1979 | A |
4216354 | Esteban et al. | Aug 1980 | A |
4464783 | Beraud et al. | Aug 1984 | A |
5243420 | Hibi | Sep 1993 | A |
5381143 | Shimoyoshi et al. | Jan 1995 | A |
5418570 | Ueno et al. | May 1995 | A |
5436665 | Ueno et al. | Jul 1995 | A |
5454011 | Shimoyoshi | Sep 1995 | A |
5463424 | Dressler | Oct 1995 | A |
5537440 | Eyuboglu et al. | Jul 1996 | A |
5541852 | Eyuboglu et al. | Jul 1996 | A |
5544266 | Koppelmans et al. | Aug 1996 | A |
5617142 | Hamilton | Apr 1997 | A |
5623424 | Azadegan et al. | Apr 1997 | A |
5659660 | Plenge et al. | Aug 1997 | A |
5677735 | Ueno et al. | Oct 1997 | A |
5835495 | Ferriere | Nov 1998 | A |
5970173 | Lee et al. | Oct 1999 | A |
6044089 | Ferriere | Mar 2000 | A |
6084909 | Chiang et al. | Jul 2000 | A |
6192075 | Jeng | Feb 2001 | B1 |
6192154 | Rajagopalan et al. | Feb 2001 | B1 |
6249288 | Campbell | Jun 2001 | B1 |
6259741 | Chen et al. | Jul 2001 | B1 |
6278691 | Ohyama et al. | Aug 2001 | B1 |
6370502 | Wu et al. | Apr 2002 | B1 |
6393059 | Sugiyama | May 2002 | B1 |
6404814 | Apostolopoulos et al. | Jun 2002 | B1 |
6426977 | Lee et al. | Jul 2002 | B1 |
6434197 | Wang et al. | Aug 2002 | B1 |
6463414 | Su et al. | Oct 2002 | B1 |
6466623 | Youn et al. | Oct 2002 | B1 |
6496216 | Feder | Dec 2002 | B2 |
6496868 | Krueger et al. | Dec 2002 | B2 |
6504494 | Dyas et al. | Jan 2003 | B1 |
6507615 | Tsujii et al. | Jan 2003 | B1 |
6522693 | Lu et al. | Feb 2003 | B1 |
6526099 | Christopoulos et al. | Feb 2003 | B1 |
6647061 | Panusopone et al. | Nov 2003 | B1 |
6650705 | Vetro et al. | Nov 2003 | B1 |
6678654 | Zinser, Jr. et al. | Jan 2004 | B2 |
6728317 | Demos | Apr 2004 | B1 |
6757648 | Chen et al. | Jun 2004 | B2 |
6925501 | Wang et al. | Aug 2005 | B2 |
6931064 | Mori et al. | Aug 2005 | B2 |
6934334 | Yamaguchi et al. | Aug 2005 | B2 |
6937653 | Song et al. | Aug 2005 | B2 |
6944224 | Zhao et al. | Sep 2005 | B2 |
6961377 | Kingsley | Nov 2005 | B2 |
6963347 | Selvaggi et al. | Nov 2005 | B1 |
7027982 | Chen et al. | Apr 2006 | B2 |
7039116 | Zhang et al. | May 2006 | B1 |
7058127 | Lu et al. | Jun 2006 | B2 |
7068718 | Kim et al. | Jun 2006 | B2 |
7085322 | Ngai et al. | Aug 2006 | B2 |
7116714 | Hannuksela | Oct 2006 | B2 |
7142601 | Kong et al. | Nov 2006 | B2 |
7292634 | Yamamoto et al. | Nov 2007 | B2 |
7295612 | Haskell | Nov 2007 | B2 |
7319720 | Abrams, Jr. | Jan 2008 | B2 |
7336720 | Martemyanov et al. | Feb 2008 | B2 |
7343291 | Thumpudi | Mar 2008 | B2 |
7352808 | Ratakonda et al. | Apr 2008 | B2 |
7643422 | Covell et al. | Jan 2010 | B1 |
7694075 | Feekes, Jr. | Apr 2010 | B1 |
7885341 | Chen et al. | Feb 2011 | B2 |
7936820 | Watanabe et al. | May 2011 | B2 |
8130828 | Hsu et al. | Mar 2012 | B2 |
20020036707 | Gu | Mar 2002 | A1 |
20020080877 | Lu et al. | Jun 2002 | A1 |
20020090027 | Karczewicz et al. | Jul 2002 | A1 |
20020131492 | Yokoyama | Sep 2002 | A1 |
20020136298 | Anantharamu | Sep 2002 | A1 |
20020172154 | Uchida et al. | Nov 2002 | A1 |
20030185298 | Alvarez et al. | Oct 2003 | A1 |
20030206597 | Kolarov et al. | Nov 2003 | A1 |
20030227974 | Nakamura et al. | Dec 2003 | A1 |
20040117427 | Allen et al. | Jun 2004 | A1 |
20040125877 | Chang | Jul 2004 | A1 |
20040136457 | Funnell et al. | Jul 2004 | A1 |
20040165667 | Lennon et al. | Aug 2004 | A1 |
20040264489 | Klemets et al. | Dec 2004 | A1 |
20050041740 | Sekiguchi | Feb 2005 | A1 |
20050053157 | Lillevold | Mar 2005 | A1 |
20050075869 | Gersho et al. | Apr 2005 | A1 |
20050084007 | Lightstone et al. | Apr 2005 | A1 |
20050165611 | Mehrotra et al. | Jul 2005 | A1 |
20050175091 | Puri et al. | Aug 2005 | A1 |
20050180511 | Arafune et al. | Aug 2005 | A1 |
20050207497 | Rovati et al. | Sep 2005 | A1 |
20050228854 | Steinheider et al. | Oct 2005 | A1 |
20050232497 | Yogeshwar et al. | Oct 2005 | A1 |
20060002479 | Fernandes | Jan 2006 | A1 |
20060114995 | Robey et al. | Jun 2006 | A1 |
20060120610 | Kong et al. | Jun 2006 | A1 |
20060126726 | Lin et al. | Jun 2006 | A1 |
20060126744 | Peng et al. | Jun 2006 | A1 |
20060159169 | Hui et al. | Jul 2006 | A1 |
20060215754 | Buxton et al. | Sep 2006 | A1 |
20060222078 | Raveendran | Oct 2006 | A1 |
20060239343 | Mohsenian | Oct 2006 | A1 |
20060245491 | Jam et al. | Nov 2006 | A1 |
20060248516 | Gordon | Nov 2006 | A1 |
20070053444 | Shibata et al. | Mar 2007 | A1 |
20070058718 | Shen et al. | Mar 2007 | A1 |
20070058729 | Yoshinari | Mar 2007 | A1 |
20070071105 | Tian et al. | Mar 2007 | A1 |
20070140352 | Bhaskaran et al. | Jun 2007 | A1 |
20070153906 | Petrescu et al. | Jul 2007 | A1 |
20070160128 | Tian et al. | Jul 2007 | A1 |
20070223564 | Bruls et al. | Sep 2007 | A1 |
20070280349 | Prieto et al. | Dec 2007 | A1 |
20080046939 | Lu et al. | Feb 2008 | A1 |
20080137736 | Richardson et al. | Jun 2008 | A1 |
20080144723 | Chen et al. | Jun 2008 | A1 |
20080151101 | Tian et al. | Jun 2008 | A1 |
20080187046 | Joch | Aug 2008 | A1 |
20080259921 | Nadarajah | Oct 2008 | A1 |
20090003452 | Au et al. | Jan 2009 | A1 |
20090012982 | Merchia et al. | Jan 2009 | A1 |
20090110060 | Cortes et al. | Apr 2009 | A1 |
20090147859 | McGowan et al. | Jun 2009 | A1 |
20090176454 | Chen et al. | Jul 2009 | A1 |
20090219993 | Bronstein et al. | Sep 2009 | A1 |
20090244633 | Johnston | Oct 2009 | A1 |
20090279605 | Holcomb et al. | Nov 2009 | A1 |
20090282162 | Mehrotra et al. | Nov 2009 | A1 |
20100086048 | Ishtiaq et al. | Apr 2010 | A1 |
20100091888 | Nemiroff | Apr 2010 | A1 |
20100189179 | Gu et al. | Jul 2010 | A1 |
20100272171 | Xu | Oct 2010 | A1 |
20100316126 | Chen et al. | Dec 2010 | A1 |
20110188577 | Kishore et al. | Aug 2011 | A1 |
20110305273 | He et al. | Dec 2011 | A1 |
20120056981 | Tian et al. | Mar 2012 | A1 |
Number | Date | Country |
---|---|---|
0 909 094 | Apr 1999 | EP |
1 195 992 | Apr 2002 | EP |
03032088 | Feb 2000 | JP |
2002-152752 | May 2002 | JP |
9214965 | Jun 2002 | JP |
2005-252555 | Sep 2005 | JP |
2007-036666 | Feb 2007 | JP |
10-2005-0089720 | Sep 2005 | KR |
10-2008-0102141 | Nov 2008 | KR |
WO 0195633 | Dec 2001 | WO |
WO 2004004359 | Jan 2004 | WO |
WO 2006096612 | Sep 2006 | WO |
WO 2006134110 | Dec 2006 | WO |
WO 2010088030 | Aug 2010 | WO |
Entry |
---|
Gill, “Tips and Tricks for Encoding Long Format Content with Windows Media Encoder,” <http://www.microsoft.com/windows/windowsmedia/howto/articles/enclfc.aspx>, Microsoft Windows Media, 12 pages, Aug. 2003 (accessed Jan. 2, 2009). |
Huang et al., “Optimal Control of Multiple Bit Rates for Streaming Media,” <http://nisl.wayne.edu/Papers/Tech/HuangCK04c.pdf>, 4 pages. |
Waggoner, “In Depth Microsoft Silverlight,” <http://conferences.infotoday.com/documents/45/SM3—Waggoner.pdf>, Microsoft Silverlight, 93 pages, 2007. |
Chang et al., “Real-Time Content-Based Adaptive Streaming of Sports Videos,” <http://www.ctr.columbia.edu/papers—advent/01/sport—TR01.pdf>, IEEE CVPR CBAIVL Workshop, 8 pages, Jul. 2001. |
RealNetworks, Inc., “Chapter 5: Producing Video,” <http://service.real.com/help/library/guides/RealProducer10/htmfiles/video.htm#113899>, 22 pages, 2004 (accessed Jan. 2, 2009). |
Microsoft Windows Media, “Windows Media and Web Distribution for Broadcasters,” <http://www.microsoft.com/windows/windowsmedia/forpros/content—provider/broadcast/default.aspx>, 4 pages, 2009 (accessed Jan. 2, 2009). |
U.S. Appl. No. 60/341,674, filedd Dec. 17, 2001, Lee et al. |
U.S. Appl. No. 60/488,710, filed Jul. 18, 2003, Srinivasan et al. |
U.S. Appl. No. 60/501,081, filed Sep. 7, 2003, Srinivasan et al. |
U.S. Appl. No. 60/501,133, filed Sep. 7, 2003, Holcomb et al. |
Akramullah et al., “Parallelization of MPEG-2 Video Encoder for Parallel and Distributed Computing Systems,” IEEE, pp. 834-837 (Aug. 1995). |
Asbun et al., “Very Low Bit Rate Wavelet-Based Scalable Video Compression,” Proc. Int'l Conf. on Image Processing, vol. 3, pp. 948-952 (Oct. 1998). |
Assuncao et al., “A Frequency-Domain Video Transcoder for Dynamic Bit-Rate Reduction of MPEG-2 Bit Streams,” IEEE Transactions on Circuits and Systems for Video Technology, vol. 8, No. 8, pp. 953-967 (Dec. 1998). |
Assuncao et al., “Buffer Analysis and Control in CBR Video Transcoding,” IEEE Transactions on Circuits and Systems for Video Technology, vol. 10, No. 1, pp. 83-92 (Feb. 2000). |
Assuncao et al., “Transcoding of Single-Layer MPEG Video Into Lower Rates,” IEE Proc.—Vis. Image Signal Process., vol. 144, No. 6, pp. 377-383 (Dec. 1997). |
ATI Technologies, Inc., “Introduction to H.264,” 6 pp. (month unknown, 2005). |
Braun et al., “Motion-Compensating Real-Time Format Converter for Video on Multimedia Displays,” Proceedings IEEE 4th International Conference on Image Processing (ICIP-97), vol. I, pp. 125-128 (Oct. 1997). |
Brightwell et al., “Flexible Switching and Editing of MPEG-2 Video Bitstreams,” IBC-97, 11 pp. (Sep. 1997). |
Chen et al., “Implementation of H.264 Encoder and Decoder on Personal Computers,” Journal of Visual Comm. and Image Representation, 19 pp. (Apr. 2006). |
Chen, “Synchronization and Control of Multi-threads for MPEG-4 Video Decoder,” IEEE 1999 Int'l Conf. on Consumer Electronics, pp. 298-299 (Jun. 1999). |
Crooks, “Analysis of MPEG Encoding Techniques on Picture Quality,” Tektronix Application Note, 11 pp. (Jun. 1998). |
Dawson, “Coding for Multiple Cores on Xbox 360 and Microsoft Windows,” 8 pp. (Aug. 2006) [Downloaded from the Internet on Jan. 22, 2007]. |
Dipert, “Image Compression Article Addendum,” EDN Magazine, 8 pp. (Jun. 18, 1998). |
Duffy, “CLR Inside Out: Using Concurrency for Scalability,” MSDN Magazine, 11 pp. (Sep. 2006) [Downloaded from the Internet on Jan. 22, 2007]. |
Flordal et al., “Accelerating CABAC Encoding for Multi-standard Media with Configurability,” IEEE Xplore, 8 pp. (Apr. 2006). |
Fogg, “Question That Should Be Frequently Asked About MPEG,” Version 3.8, 46 pp. (Apr. 1996). |
FOLDOC.ORG, “priority scheduling,” 1 p. (No date) [Downloaded from the Internet on Jan. 26, 2007]. |
FOLDOC.ORG, “multitasking,” 1 p. (Document dated Apr. 24, 1998) [Downloaded from the Internet on Jan. 26, 2007]. |
Gerber et al., “Optimizing Video Encoding using Threads and Parallelism: Part 1—Threading a video codec,” 3 pp., downloaded from Embedded.com, (Dec. 2009). |
Gibson et al., Digital Compression for Multimedia, “Chapter 4: Quantization,” Morgan Kaufman Publishers, Inc., pp. 113-138 (Jan. 1998). |
Gibson et al., Digital Compression for Multimedia, “Chapter 7: Frequency Domain Coding,” Morgan Kaufman Publishers, Inc., pp. 227-262 (Jan. 1998). |
Hamming, Digital Filters, Second Edition, “Chapter 2: The Frequency Approach,” Prentice-Hall, Inc., pp. 19-31 (Jan. 1983). |
Intel Corp., “Intel's Next Generation Integrated Graphics Architecture—Intel® Graphics Media Accelerator X3000 and 3000,” 14 pp. (Jul. 2006). |
International Search Report and Written Opinion dated Aug. 17, 2010, from International Patent Application No. PCT/US2010/020784, 9 pp. |
ISO/IEC, “ISO/IEC 11172-2, Information Technology—Coding of Moving Pictures and Associated Audio for Digital Storage Media at up to about 1.5 Mbit/s—Part 2: Video,” 112 pp. (Aug. 1993). |
ISO/IEC, “JTC1/SC29/WG11 N2202, Information Technology—Coding of Audio-Visual Objects: Visual, ISO/IEC 14496-2,” 329 pp. (Mar. 1998). |
ISO/IEC MPEG-2 Test Model 5, “TM5 Overview,” 10 pp. (Mar. 1993). |
Ito et al., “Rate control for video coding using exchange of quantization noise and signal resolution,” Electronics & Communications in Japan, Part II, Hoboken, New Jersey, vol. 83, No. 1, Jan. 1, 2000, pp. 33-43. |
ITU-T, “ITU-T Recommendation H.261, Video Codec for Audiovisual Services at p×64 kbits,” 25 pp. (Mar. 1993). |
ITU-T, “ITU-T Recommendation H.262, Information Technology—Generic Coding of Moving Pictures and Associated Audio Information: Video,” 205 pp. (Jul. 1995). |
ITU-T, “ITU-T Recommendation H.263, Video Coding for Low Bit Rate Communication,” 162 pp. (Feb. 1998). |
Jacobs et al., “Thread-Parallel MPEG-2, MPEG-4 and H.264 Video Encoders for SoC Multi-Processor Architectures,” IEEE Trans. on Consumer Electronics, vol. 52, No. 1, pp. 269-275 (Feb. 2006). |
Joint Video Team (JVT) of ISO/IEC MPEG & ITU-T VCEG, “Joint Final Committee Draft (JFCD) of Joint Video Specification,” JVT-D157, 207 pp. (Aug. 2002). |
Kamikura et al., “Global brightness-variation compensation for video coding” IEEE Trans. on Circuits and Systems for Video Technology, vol. 8, No. 8, pp. 988-1000 (Dec. 1998). |
Kari et al., “Intensity controlled motion compensation,” Data Compression Conference Proc., pp. 249-258, (Mar. 30-Apr. 1, 1998). |
Keesman et al., “Transcoding of MPEG Bitstreams,” Signal Processing: Image Communication 8, pp. 481-500 (Sep. 1996). |
Khan et al., “Architecture Overview of Motion Vector Reuse Mechanism in MPEG-2 Transcoding,” Technical Report TR2001-01-01, 7 pp. (Jan. 2001). |
Kim et al., “Multi-thread VLIW processor architecture for HDTV decoding,” IEEE 2000 Custom Integrated Circuits Conf., pp. 559-562 (May 2000). |
Knee et al., “Seamless Concatenation—A 21st Century Dream,” 13 pp. (Jun. 1997). |
Lei et al., “Rate Adaptation Transcoding for Precoded Video Streams,” 13 pp. (month unknown, 2000). |
Leventer et al., “Towards Optimal Bit-Rate Control in Video Transcoding,” ICIP, pp. 265-268 (Sep. 2003). |
Loomis et al., “VC-1 Technical Overview,” 7 pp. (Apr. 2006) [Downloaded from the Internet on Jan. 24, 2007]. |
Microsoft Corporation, “Microsoft Debuts New Windows Media Player 9 Series, Redefining Digital Media on the PC,” 4 pp. (Sep. 4, 2002) [Downloaded from the World Wide Web on May 14, 2004]. |
Miyata et al., “A novel MPEG-4 rate control method with spatial resolution conversion for low bit-rate coding,” Conference Proceedings / IEEE International Symposium on Circuits and Systems (ISCAS), Kobe, Japan, May 23-26, 2005, pp. 4538-4541. |
Mook, “Next-Gen Windows Media Player Leaks to the Web,” BetaNews, 17 pp. (Jul. 2002) [Downloaded from the World Wide Web on Aug. 8, 2003]. |
Moshnyaga, “An Implementation of Data Reusable MPEG Video Coding Scheme,” Proceedings of World Academy of Science, Engineering and Technology, vol. 2, pp. 193-196 (Jan. 2005). |
Moshnyaga, “Reduction of Memory Accesses in Motion Estimation by Block-Data Reuse,” ICASSP '02 Proceedings, IEEE International Conference on Acoustics, Speech, and Signal Processing, vol. 3, pp. III-3128-III-3131 (May 2002). |
Nasim et al., “Architectural Optimizations for Software-Bassed MPEG4 Video Encoder,” 13th European Signal Processing Conference: EUSIPCO '2005, 4 pp. (Sep. 2005). |
Notice on the First Office Action dated May 31, 2012, for Chinese Patent Application No. 201080006304.9, 7 pp. |
NuntiusSystems, Inc., “H.264—a New Technology for Video Compression”, downloaded from the World Wide Web, 4 pp. (document marked Mar. 2004). |
Oehring et al., “MPEG-2 Video Decompression on Simultaneous Multithreaded Multimedia,” Int. Conf. on Parallel Architectures and Compilation Techniques (PACT '99), Newport Beach, CA (Oct. 1999). |
Ostermann et al., “Video Coding with H.264/AVC: Tools, Performance, and Complexity,” IEEE Circuits and Systems Magazine, pp. 7-28 (Aug. 2004). |
Ozcelebi et al., “Optimal rate and input format control for content and context adaptive video streaming,” 2004 International Conference on Image Processing (ICIP), Singapore, Oct. 24-27, 2004, pp. 2043-2046. |
Ozcelebi et al., “Optimal rate and input format control for content and context adaptive streaming of sports videos,” 2004 IEEE 6th Workshop on Multimedia Signal Processing, Siena, Italy, Sep. 29-Oct. 1, 2004, pp. 502-505. |
Printouts of FTP directories from http://ftp3.itu.ch, 8 pp. [Downloaded from the World Wide Web on Sep. 20, 2005]. |
Reader, “History of MPEG Video Compression—Ver. 4.0,” 99 pp. [Document marked Dec. 16, 2003]. |
Reed et al., “Optimal multidimensional bit-rate control for video communication,” IEEE Transactions on Image Processing, vol. 11, No. 8, pp. 873-874 (Aug. 1, 2002). |
Roy et al., “Application Level Hand-off Support for Mobile Media Transcoding Sessions,” Proceedings of the 12th International Workshop on Network and Operating Systems Support for Digital Audio and Video, 22 pp. (May 2002). |
Sambe et al., “High-speed Distributed Video Transcoding for Multiple Rates and Formats,” IEICE Trans on Information and Systems, vol. E88-D, Issue 8, pp. 1923-1931 (Aug. 2005). |
Senda et al., “A Realtime Software MPEG Transcoder Using a Novel Motion Vector Reuse and a SIMD Optimization Techniques,” ICASSP '99 Proceedings, 1999 IEEE International Conference on Acoustics, Speech, and Signal Processing, vol. 4, pp. 2359-2362 (Mar. 1999). |
Shanableh et al., “Heterogeneous Video Transcoding to Lower Spatio-Temporal Resolutions and Different Encoding Formats,” IEEE Transactions on Multimedia, 31 pp. (Jun. 2000). |
Shanableh et al., “Transcoding of Video Into Different Encoding Formats,” ICASSP-2000 Proceedings, vol. IV of VI, pp. 1927-1930 (Jun. 2000). |
SMPTE, “Proposed SMPTE Standard for Television: VC-1 Compressed Video Bitstream Format and Decoding Process,” SMPTE 421M, pp. i-xx, 5-7, 23-27 (Aug. 2005). |
SMPTE, “SMPTE 327M-2000—MPEG-2 Video Recoding Data Set,” 9 pp. (Jan. 2000). |
Sun et al., “Architectures for MPEG Compressed Bitstream Scaling,” IEEE Transactions on Circuits and Systems for Video Technology, vol. 6, No. 2, pp. 191-199 (Apr. 1996). |
Sun et al., “Lossless Coders,” Digital Signal Processing for Multimedia Systems, Chapter 15, pp. 385-416 (Mar. 1999). |
Swann et al., “Transcoding of MPEG-II for Enhanced Resilience to Transmission Errors,” Cambridge University Engineering Department, Cambridge, UK, pp. 1-4 (Sep. 1996). |
Takahashi et al., “Motion Vector Synthesis Algorithm for MPEG2-to-MPEG4 Transcoder,” Proc. of SPIE, vol. 4310, pp. 872-882 (Jan. 2001). |
Tan et al., “On the Methods and Performances of Rational Downsizing Video Transcoding,” Signal Processing: Image Communication 19, pp. 47-65 (Jan. 2004). |
Tektronix Application Note, “Measuring and Interpreting Picture Quality in MPEG Compressed Video Content,” 8 pp. (2001). |
Tsai et al., “Rate-Distortion Model for Motion Prediction Efficiency in Scalable Wavelet Video Coding,” 17th International Packet Video Workshop, 9 pp. (May 2009). |
Tudor et al., “Real-Time Transcoding of MPEG-2 Video Bit Streams,” BBC R&D, U.K., 6 pp. (Sep. 1997). |
Van Der Tol et al., “Mapping of MPEG-4 decoding on a flexible architecture platform,” Proceedings of the SPIE, Media Processors, vol. 4674, 13 pp. (Jan. 2002). |
Van Der Tol et al., “Mapping of H.264 decoding on a multiprocessor architecture,” Proceedings of the SPIE, vol. 5022, pp. 707-718 (May 2003). |
Vetro et al., “Complexity-Quality Analysis of Transcoding Architectures for Reduced Spatial Resolution,” IEEE Transactions on Consumer Electronics, 9 pp. (Aug. 2002). |
Vishwanath et al., “A VLSI Architecture for Real-Time Hierarchical Encoding/Decoding of Video Using the Wavelet Transform,” Proc. ICASSP, 5 pp. (Apr. 1994). |
Watkinson, The MPEG Handbook, pp. 275-281 (Nov. 2004). |
Werner, “Generic Quantiser for Transcoding of Hybrid Video,” Proc. 1997 Picture Coding Symposium, Berlin, Germany, 6 pp. (Sep. 1997). |
Werner, “Requantization for Transcoding of MPEG-2 Intraframes,” IEEE Transactions on Image Processing, vol. 8, No. 2, pp. 179-191 (Feb. 1999). |
Wiegand et al., “Overview of the H.264/AVC Coding Standard,” IEEE Trans. on Circuits and Systems for Video Technology, vol. 13, No. 7, pp. 560-576 (Jul. 2003). |
Youn et al., “Video Transcoder Architectures for Bit Rate Scaling of H.263 Bit Streams,” ACM Multimedia 1999, Orlando, Florida, pp. 243-250 (Oct. 1999). |
Zhou et aL, “Motion Vector Reuse Algorithm to Improve Dual-Stream Video Encoder,” ICSP 2008, 9th International Conference on Signal Processing, pp. 1283-1286 (Oct. 2008). |
Number | Date | Country | |
---|---|---|---|
20100189183 A1 | Jul 2010 | US |