The present disclosure relates in general to video encoding and decoding using quantization.
An increasing number of applications today make use of digital video for various purposes including, for example, remote business meetings via video conferencing, high definition video entertainment, video advertisements, and sharing of user-generated videos. As technology is evolving, users have higher expectations for video quality and expect high resolution video with smooth playback.
Digital video streams typically represent video using a sequence of frames. Each frame can include a number of blocks, which in turn may contain information describing the value of color, brightness or other attributes for pixels. The amount of data in a typical video stream is large, and transmission and storage of video can use significant computing or communications resources. Various techniques have been proposed to reduce the amount of data in video streams, including compression and other encoding techniques. These techniques in some cases encode the video stream using parameters or values that vary for different segments of blocks within frames.
Disclosed herein are implementations of systems, methods and apparatuses for coding a video signal using a two-step quantization process. One aspect of the disclosed implementations is a method for encoding a frame in a video stream with a computing device, the frame having a plurality of blocks. The method includes identifying a first block of the plurality of blocks, generating a second block from the first block such that the second block has lower entropy than the first block, encoding the second block using a first encoding technique, wherein the first encoding technique is lossy, decoding the encoded second block, generating a third block based on a difference between the decoded second block and the first block, and encoding the third block using a second encoding technique different from the first encoding technique. Disclosed aspects also include generating an encoded video bitstream using the encoded second and third data blocks.
Another aspect of the disclosed implementations is a method for decoding a frame of an encoded video bitstream including a plurality of encoded blocks and the frame having a plurality of blocks. The method includes receiving a first encoded block and a second encoded block of the plurality of encoded blocks, decoding the first encoded block using a first decoding technique to generate a first decoded block, decoding the second encoded block using a second decoding technique different from the first decoding technique to generate a second decoded block, the second decoded block having a lower entropy than the first decoded block, and combining the first decoded block with the second decoded block to form a block of the plurality of blocks.
Another aspect of the disclosed implementations is an apparatus for encoding a frame in a video stream, the frame having a plurality of blocks. The apparatus includes a memory and a processor configured to execute instructions stored in the memory to identify a first block of the plurality of blocks, generate a second block from the first block such that the second block has a lower entropy than the first block, encode the second block using a first encoding technique, wherein the first encoding technique is lossy; decode the encoded second block, generate a third block based on the difference between the decoded second block and the first block, and encode the third block using a second encoding technique different from the first encoding technique.
Variations in these aspects and other implementations are described in additional detail below.
The description herein makes reference to the accompanying drawings wherein like reference numerals refer to like parts throughout the several views, and wherein:
Digital video is used for various purposes including, for example, remote business meetings via video conferencing, high definition video entertainment, video advertisements, and sharing of user-generated videos. As technology evolves, users have higher expectations for video quality and expect high resolution video even when transmitted over communications channels having limited bandwidth.
To permit transmission of digital video streams while limiting bandwidth consumption, video encoding and decoding implementations incorporate various compression schemes. These compression schemes generally break the image up into blocks and use one or more techniques to limit the amount of information included in a resulting digital video bitstream for transmission. The bitstream, once received, is then decoded to re-create the blocks and the source images from the limited information.
According to one example, block-based transform domain quantization and coding can be used for compression due to the energy compact coefficient distribution in the transform domain. This compactness is based on the assumption that the data in the spatial domain is mostly DC values with slow changes. This may not be true, however, especially after motion prediction or intra directional prediction. The spectrum of the spatial fine details, small objects and/or isolated features can be spread into a wide area of the spectrum. Due to quantization, these fine features can be heavily distorted or even destroyed. The data block transformed into frequency domain thus may not be the best form for representation and coding. Instead, the spatial domain can often be suitable for representation and coding of small and isolated objects and fine features.
Teachings herein can combine transform and spatial domain representations of data blocks to provide improved compression encoding. For example, an input block can be re-formed into two separate blocks: one containing mostly low frequency components and one containing high frequency components. The high frequency components can be represented by spikes or isolated pixels that exceed the average value of the block by a predetermined amount. Isolated pixels can be replaced in the block by the average value. This re-formed block can be subtracted from the original block to form a difference block. The re-formed block can be encoded using a first coding technique, while the difference block can be encoded using a second coding technique. Both encoded blocks are then fed into a bitstream.
Decoding an encoded video bitstream encoded in this fashion can be performed by reversing some of the steps of the encoding process. Two-step encoding can be indicated to the decoder by modifying the bitstream syntax with bits set in the frame, slice or block headers as described in additional detail below. Upon receiving blocks of a video stream encoded using a two-step process, the decoder decodes the blocks using decoding processing appropriate to each block. The blocks can then be added together to form a representation of the original block.
Additional details of these implementations are described below, initially with reference to systems in which they can be incorporated.
A network 28 connects transmitting station 12 and a receiving station 30 for encoding and decoding of the video stream. Specifically, the video stream can be encoded in transmitting station 12 and the encoded video stream can be decoded in receiving station 30. Network 28 can be, for example, the Internet. Network 28 can also be a local area network (LAN), wide area network (WAN), virtual private network (VPN), a cellular telephone network, or any other means of transferring the video stream from transmitting station 12 to, in this example, receiving station 30.
Receiving station 30, in one example, can be a computer having an internal configuration of hardware including a processor such as a CPU 32 and a memory 34. CPU 32 is a controller for controlling the operations of receiving station 30. CPU 32 can be connected to memory 34 by, for example, a memory bus. Memory 34 can be ROM, RAM or any other suitable memory device. Memory 34 can store data and program instructions that are used by CPU 32. Other suitable implementations of receiving station 30 are possible. For example, the processing of receiving station 30 can be distributed among multiple devices.
A display 36 configured to display a video stream can be connected to receiving station 30. Display 36 can be implemented in various ways, including by a liquid crystal display (LCD) or a cathode-ray tube (CRT) or a light emitting diode display (LED), such as an OLED display. Display 36 is connected to CPU 32 and can be configured to display a rendering 38 of the video stream decoded by a decoder in receiving station 30.
Other implementations of encoder and decoder system 10 are possible. In the implementations described, for example, an encoder is in transmitting station 12 and a decoder is in receiving station 30 as instructions in memory or a component separate from memory. However, an encoder or decoder can be connected to a respective station 12, 30 rather than in it. Further, one implementation can omit network 28 and/or display 36. In another implementation, a video stream can be encoded and then stored for transmission at a later time to receiving station 30 or any other device having memory. In one implementation, a video stream is received by the receiving station 30 (e.g., via network 28, a computer bus, and/or some communication pathway) and stored for later decoding. In another implementation, additional components can be added to encoder and decoder system 10. For example, a display or a video camera can be attached to transmitting station 12 to capture the video stream to be encoded. In an exemplary implementation, a real-time transport protocol (RTP) is used for transmission. In another implementation, a transport protocol other than RTP may be used, e.g. an HTTP-based video streaming protocol.
When video stream 50 is presented for encoding, each frame 56 within video stream 50 is processed in units of blocks. At intra/inter prediction stage 72, each block can be encoded using either intra-frame prediction (i.e., within a single frame) or inter-frame prediction (i.e., from frame to frame). In either case, a prediction block can be formed. In the case of intra-prediction, a prediction block can be formed from samples in the current frame that have been previously encoded and reconstructed. In the case of inter-prediction, a prediction block can be formed from samples in one or more previously constructed reference frames.
Next, still referring to
Quantization stage 76 converts the transform coefficients into discrete quantum values, which are referred to as quantized transform coefficients. The quantized transform coefficients are then entropy encoded by entropy encoding stage 78. The entropy-encoded coefficients, together with other information used to decode the block, such as the type of prediction used, motion vectors and quantizer value, are then output to compressed bitstream 88. Compressed bitstream 88 can be formatted using various techniques, such as variable length encoding (VLC) and arithmetic coding.
The reconstruction path in
Other variations of encoder 70 can be used to encode compressed bitstream 88. For example, a non-transform based encoder 70 can quantize the residual signal directly without transform stage 74. In another implementation, encoder 70 can have quantization stage 76 and dequantization stage 80 combined into a single stage.
When compressed bitstream 88 is presented for decoding, the data elements within compressed bitstream 88 can be decoded by entropy decoding stage 102 to produce a set of quantized transform coefficients. Dequantization stage 104 dequantizes the quantized transform coefficients, and inverse transform stage 106 inverse transforms the dequantized transform coefficients to produce a derivative residual that can be identical to that created by reconstruction stage 84 in encoder 70. Using header information decoded from compressed bitstream 88, decoder 100 can use intra/inter prediction stage 108 to create the same prediction block as was created in encoder 70. At reconstruction stage 110, the prediction block can be added to the derivative residual to create a reconstructed block. Loop filtering stage 112 can be applied to the reconstructed block to reduce blocking artifacts. Deblocking filtering stage 114 can be applied to the reconstructed block to reduce blocking distortion, and the result is output as output video stream 116.
Other variations of decoder 100 can be used to decode compressed bitstream 88. For example, decoder 100 can produce output video stream 116 without deblocking filtering stage 114.
Process 500 can be implemented as a software program by a computing device such as transmitting station 12. For example, the software program can include machine-readable instructions that are stored in memory 16 that, when executed by a processor such as CPU 14, can cause the computing device to operate on data stored in memory 14 and perform process 500. Process 500 can also be implemented using hardware. As explained above, some computing devices can have multiple memories and multiple processors, and the steps of process 500 can in such cases be distributed using different processors and memories. Use of the terms “processor” and “memory” in the singular herein encompasses computing devices that have only one processor or one memory as well as devices having multiple processors and memories that may be used in the performance of some but not necessarily all of the recited steps.
At step 502, a block of the video stream to be encoded is identified. As used in this disclosure, “identify” means to select, construct, determine, specify or otherwise identify in any manner whatsoever. Blocks of a frame or slice of the video stream can be identified or selected in raster scan order or any other order. At step 504, a second block is generated from the first block by extracting special features and values from the data block and replacing these data values with other data values that can make the transform domain coefficients simpler. As used herein the term “generating” can mean create, construct, form, produce or generate in any manner whatsoever. Disclosed implementations use the average of the non-extracted pixels in the block to replace the extracted pixels; however, other algorithms to replace the extracted pixels can be used. This can also be called data re-shaping and is also described as re-shaping or re-forming the block.
Special features can include, for example, a line or texture, and can be extracted by detecting impulse (spike) or step (edge) functions in the spatial domain. Implementations can detect isolated pixels or groups of pixels that differ from the average of the pixels in the block by more than a predetermined range, for example. Other ways of detecting special features are possible, including detecting pixels or groups of pixels that differ from their neighboring pixels by a predetermined amount, for example. These detected pixels can be removed from the block and replaced by pixels having values equal to the average values of the remaining pixels, for example. Other values can be used to replace the removed pixels, for example calculations based on the values of neighboring pixels. Detecting special features and replacing the detected pixels with other values generates a second block. This can also be called feature extraction.
In certain implementations, the pixel values used for the comparison can be, for example, intensity or luma values in Y′CbCr colorspace (also called YUV colorspace). In one such implementation, when the pixels are removed and replaced, the luma value for the removed pixels can be replaced by average luma values for the remaining pixels of the block and the chroma values Cb and Cr for each removed pixel can be replaced by respective average chroma values Cb and Cr of remaining pixels of the block. This technique can be implemented before or after chroma subsampling (e.g., 4:2:0 Y′CbCr chroma subsampling), which generally results in a luma value Y′ for each pixel but only one set of chroma values Cb, Cr for more than one image pixel. The actual color format is not critical or limited and can be any color format or colorspace. Other comparisons of pixel values can be made, for example, such as by comparing each of value Y′, Cb and Cr to a range of values to detect whether a special feature may exist.
The second block generated in step 504 can have a lower entropy than the original, first block. At step 506, the second block is encoded using a first encoding technique, which in this case can include a DCT transform, for example, by encoder 70. Other transforms can be used as described above. Following the DCT transform, the transformed block can be quantized to reduce the number of unique states occurring in the transformed data. The transformed and quantized block data can then be entropy encoded. By removing special features from the second block and replacing the pixels with average values, for example, the number of bits in the encoded block can be reduced, thereby reducing the number of bits to be included in the encoded video bitstream for the second block at step 508. Examples of this are given below.
At step 510, a copy of the second block is decoded at the encoder. In this implementation, it is desirable that a decoded version of the second block be used rather than the original second block for further processing. This is due to the fact that the process of transforming and quantizing the original data is lossy, meaning that the decoded second block data may not equal the data of the original second block. The decoder will use the decoded version of the second block, so using the decoded version of the second block to generate the third block in the following step can maintain the accuracy of the encoded blocks without drifting.
At step 512, the decoded second block can be subtracted from the original first block to yield a third block that represents the residue or difference between the second and first blocks. An example of this subtraction is given below. In other implementations, the original second block can be used for the subtraction in step 512. At step 514, the third or residue block is encoded. Since the third or residue block contains isolated pixels, a spatial domain transformation such as pulse code modulation (PCM) or no transformation at all can result in few bits to include in the bitstream following quantization and entropy encoding. At step 516, the third block is included in the encoded video bitstream.
This process may be implemented into the bitstream syntax by specifying one of a number of quantization and coding modes in a picture layer, a segment/slice layer, a macroblock layer or a block layer where the block is smaller than the macroblock. One mode could indicate transform domain quantization and coding only, a second could indicate spatial domain quantization and coding only, and a third could indicate transform domain quantization and coding followed by spatial domain quantization and coding. The modes would be represented by bits in headers, for example.
Process 600 can be implemented as a software program by a computing device such as receiving station 30. For example, the software program can include machine-readable instructions that are stored in memory 34 that, when executed by a processor such as CPU 32, can cause the computing device to operate on data stored in memory 34 and perform process 600. Process 600 can also be implemented using hardware. As explained above, some computing devices can have multiple memories and multiple processors, and the steps of process 600 can in such cases be distributed using different processors and memories.
At step 602, an encoded video bitstream is received by a decoder, such as decoder 100. The encoded video bitstream can be received in any number of ways, such as by receiving the video data over a network, over a cable, or by reading the video data from a primary memory or other storage device, including a disk drive or removable media such as a CF card, SD card, or the like. At step 604, process 600 decodes the first block. The first block corresponds to the second block encoded and included in the video stream in steps 506 and 508 of process 500, above. This block can be entropy decoded and dequantized. The dequantized coefficients are then inverse transformed to restore the block to the spatial domain.
At step 606, the second block, which corresponds to the third block encoded and included in the encoded video stream in steps 514 and 516 of process 500, is decoded. The second block can be entropy decoded, de-quantized and then decoded. Since the data in the second block is already in the spatial domain, transforming the data can be unnecessary. If the second data block has been pulse code modulated, the PCM can be reversed by adding successive entries. At step 608, the decoded second block and the decoded first block can be combined by adding the blocks on a pixel-by-pixel basis. Combining the blocks in this fashion can reproduce the original block in the spatial domain within the limits of errors introduced by the encoding and decoding algorithms.
Representations of different blocks of data in the spatial domain and in the transform domain are useful to show the properties of the data in the different domains and to illustrate the usefulness of the above techniques. Such representations are shown by example in
Certain situations may involve a complex spatial domain representation but a simple transform domain representation.
In some situations, a block of data cannot be represented in a simple manner in either the spatial domain or the transform domain.
Next, inverse quantization (i.e., dequantization) and an inverse transform can be performed on block 1106.
In the implementations described above, a video stream can be encoded in a two-step process that identifies pixels in a block having selected spatial properties, for example isolated pixels with values that exceed the values of neighboring pixels by more than an amount. The identified pixels are replaced in the block with, for example, pixels set to the average value of the block. The block is then transformed using a lossy transform and a copy of the transformed block is inverse transformed. Transforms used by disclosed implementations are invertible transformations that can transform the pixels of a block into a transform domain wherein the transformed pixels of the block can be inverse transformed to reform the original pixels. Lossy transforms are invertible transforms which, upon transform/inverse transforming yield a block with pixels whose values are close to, but possibly not exactly matching, the original pixel values.
The pixels of the inverse transformed copy of the block is subtracted from the pixels of the original block to form a residue block that contains the pixels identified as having preselected spatial properties. The inverse transformed block can be subtracted from the original data rather than using the re-shaped block because this may more closely reflect the pixel values available to the decoder when the blocks are decoded and thereby yield more accurate results.
The residue block and the transformed block can be further encoded by quantizing the pixel data to reduce the number of discrete states used to represent the data. The blocks can be entropy encoded to reduce redundant data and then included in the encoded video bitstream for transmission or storage. Encoding video data in this two-step fashion can permit the two encoded blocks to be represented by fewer bits in the bitstream than blocks encoded using a single step process, thereby saving transmission bandwidth or storage space while maintaining equivalent video quality.
The implementations of encoding and decoding described above illustrate some exemplary encoding and decoding techniques. However, it is to be understood that encoding and decoding, as those terms are used in the claims, could mean compression, decompression, transformation, or any other processing or change of data.
The words “example” or “exemplary” are used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as “example’ or “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs. Rather, use of the words “example” or “exemplary” is intended to present concepts in a concrete fashion. As used in this application, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or”. That is, unless specified otherwise, or clear from context, “X includes A or B” is intended to mean any of the natural inclusive permutations. That is, if X includes A; X includes B; or X includes both A and B, then “X includes A or B” is satisfied under any of the foregoing instances. In addition, the articles “a” and “an” as used in this application and the appended claims should generally be construed to mean “one or more” unless specified otherwise or clear from context to be directed to a singular form. Moreover, use of the term “an embodiment” or “one embodiment” or “an implementation” or “one implementation” throughout is not intended to mean the same embodiment or implementation unless described as such.
The implementations of transmitting station 12 and/or receiving station 30 (and the algorithms, methods, instructions, etc. stored thereon and/or executed thereby) can be realized in hardware, software, or any combination thereof. The hardware can include, for example, computers, intellectual property (IP) cores, application-specific integrated circuits (ASICs), programmable logic arrays, optical processors, programmable logic controllers, microcode, microcontrollers, servers, microprocessors, digital signal processors or any other suitable circuit. In the claims, the term “processor” should be understood as encompassing any of the foregoing hardware, either singly or in combination. The terms “signal” and “data” are used interchangeably. Further, portions of transmitting station 12 and receiving station 30 do not necessarily have to be implemented in the same manner.
Further, in one implementation, for example, transmitting station 12 or receiving station 30 can be implemented using a general purpose computer/processor with a computer program that, when executed, carries out any of the respective methods, algorithms and/or instructions described herein. In addition or alternatively, for example, a special purpose computer/processor can be utilized which can contain other hardware for carrying out any of the methods, algorithms, or instructions described herein.
Transmitting station 12 and receiving station 30 can, for example, be implemented on computers in a video conferencing system. Alternatively, transmitting station 12 can be implemented on a server and receiving station 30 can be implemented on a device separate from the server, such as a hand-held communications device (e.g., a cell phone). In this instance, transmitting station 12 can encode content using an encoder into an encoded video signal and transmit the encoded video signal to the communications device. In turn, the communications device can then decode the encoded video signal using a decoder. Alternatively, the communications device can decode content stored locally on the communications device, for example, content that was not transmitted by transmitting station 12. Other suitable transmitting station 12 and receiving station 30 implementation schemes are available. For example, receiving station 30 can be a generally stationary personal computer rather than a portable communications device and/or a device including an encoder may also include a decoder.
Further, all or a portion of implementations of the present invention can take the form of a computer program product accessible from, for example, a tangible computer-usable or computer-readable medium. A computer-usable or computer-readable medium can be any device that can, for example, tangibly contain, store, communicate, or transport the program for use by or in connection with any processor. The medium can be, for example, an electronic, magnetic, optical, electromagnetic or semiconductor device. Other suitable mediums are also available.
The above-described implementations have been described in order to allow easy understanding of the present invention and do not limit the present invention. On the contrary, the invention is intended to cover various modifications and equivalent arrangements included within the scope of the appended claims, which scope is to be accorded the broadest interpretation so as to encompass all such modifications and equivalent structure as is permitted under the law.
Number | Name | Date | Kind |
---|---|---|---|
5590329 | Goodnow, II et al. | Dec 1996 | A |
5644709 | Austin | Jul 1997 | A |
5751846 | Higgins-Luthman et al. | May 1998 | A |
5754742 | Astle | May 1998 | A |
5912676 | Malladi et al. | Jun 1999 | A |
5946486 | Pekowski | Aug 1999 | A |
6028967 | Kim et al. | Feb 2000 | A |
6085029 | Kolawa et al. | Jul 2000 | A |
6128346 | Suarez et al. | Oct 2000 | A |
6243416 | Matsushiro et al. | Jun 2001 | B1 |
6263114 | Saunders | Jul 2001 | B1 |
6363119 | Oami | Mar 2002 | B1 |
6434197 | Wang et al. | Aug 2002 | B1 |
6473460 | Topper | Oct 2002 | B1 |
6532306 | Boon et al. | Mar 2003 | B1 |
6542990 | Tremblay et al. | Apr 2003 | B1 |
6658157 | Satoh et al. | Dec 2003 | B1 |
6681299 | Shimamura et al. | Jan 2004 | B1 |
6687304 | Peng | Feb 2004 | B1 |
6700809 | Ng et al. | Mar 2004 | B1 |
6944226 | Lin et al. | Sep 2005 | B1 |
7114104 | Bennett | Sep 2006 | B1 |
7185125 | Rougnon-Glasson | Feb 2007 | B2 |
7216135 | Sawdon et al. | May 2007 | B2 |
7218674 | Kuo | May 2007 | B2 |
7236527 | Ohira | Jun 2007 | B2 |
7263125 | Lainema | Aug 2007 | B2 |
7450642 | Youn | Nov 2008 | B2 |
7457362 | Sankaran | Nov 2008 | B2 |
7487314 | Agesen et al. | Feb 2009 | B1 |
7681077 | Eitzmann et al. | Mar 2010 | B1 |
7734893 | Hattori et al. | Jun 2010 | B2 |
7768515 | Eitzmann et al. | Aug 2010 | B1 |
7836434 | Boucher | Nov 2010 | B1 |
7856538 | Speirs, II et al. | Dec 2010 | B2 |
8055864 | Sawdon et al. | Nov 2011 | B2 |
8311111 | Xu et al. | Nov 2012 | B2 |
8325796 | Wilkins et al. | Dec 2012 | B2 |
8526498 | Lim et al. | Sep 2013 | B2 |
8666181 | Venkatapuram et al. | Mar 2014 | B2 |
8711935 | Kim et al. | Apr 2014 | B2 |
8724702 | Bulusu et al. | May 2014 | B1 |
8761242 | Jeon et al. | Jun 2014 | B2 |
8891616 | Wilkins | Nov 2014 | B1 |
20030053541 | Sun et al. | Mar 2003 | A1 |
20030072364 | Kim et al. | Apr 2003 | A1 |
20030140238 | Turkboylari | Jul 2003 | A1 |
20040114568 | Beverly | Jun 2004 | A1 |
20050002454 | Ueno et al. | Jan 2005 | A1 |
20050046702 | Katayama et al. | Mar 2005 | A1 |
20050084007 | Lightstone et al. | Apr 2005 | A1 |
20050206785 | Swan et al. | Sep 2005 | A1 |
20050249279 | Kondo et al. | Nov 2005 | A1 |
20050265447 | Park | Dec 2005 | A1 |
20050283770 | Karp et al. | Dec 2005 | A1 |
20060171457 | DeGarrido et al. | Aug 2006 | A1 |
20060277371 | Cohn et al. | Dec 2006 | A1 |
20070065026 | Lee et al. | Mar 2007 | A1 |
20070110290 | Chang et al. | May 2007 | A1 |
20070121731 | Tanizawa et al. | May 2007 | A1 |
20070156986 | Neiger et al. | Jul 2007 | A1 |
20070201559 | He | Aug 2007 | A1 |
20070268964 | Zhao | Nov 2007 | A1 |
20080013844 | Hu | Jan 2008 | A1 |
20080170793 | Yamada et al. | Jul 2008 | A1 |
20080225947 | Narroschke et al. | Sep 2008 | A1 |
20080240250 | Lin et al. | Oct 2008 | A1 |
20090010559 | Inagaki | Jan 2009 | A1 |
20090043978 | Sawdon et al. | Feb 2009 | A1 |
20100086028 | Tanizawa et al. | Apr 2010 | A1 |
20100091842 | Ikeda et al. | Apr 2010 | A1 |
20100104021 | Schmit | Apr 2010 | A1 |
20100118945 | Wada et al. | May 2010 | A1 |
20100128796 | Choudhury | May 2010 | A1 |
20100166061 | Kondo et al. | Jul 2010 | A1 |
20100177819 | Jeon et al. | Jul 2010 | A1 |
20100257511 | Hatabu | Oct 2010 | A1 |
20100260268 | Cowan et al. | Oct 2010 | A1 |
20100322306 | Au et al. | Dec 2010 | A1 |
20110026591 | Bauza et al. | Feb 2011 | A1 |
20110038410 | Narroschke et al. | Feb 2011 | A1 |
20110082962 | Horovitz et al. | Apr 2011 | A1 |
20110173505 | Bae et al. | Jul 2011 | A1 |
20110235706 | Demircin et al. | Sep 2011 | A1 |
20110293001 | Lim et al. | Dec 2011 | A1 |
20110304634 | Urbach | Dec 2011 | A1 |
20120045128 | Bae | Feb 2012 | A1 |
20120114034 | Huang et al. | May 2012 | A1 |
20120140815 | Zhou et al. | Jun 2012 | A1 |
20120170647 | He et al. | Jul 2012 | A1 |
20120189052 | Karczewicz et al. | Jul 2012 | A1 |
20120278665 | Serebryany et al. | Nov 2012 | A1 |
20120314760 | He | Dec 2012 | A1 |
20130022108 | Panusopone et al. | Jan 2013 | A1 |
20130051457 | Joshi et al. | Feb 2013 | A1 |
Number | Date | Country |
---|---|---|
2815985 | Jun 2012 | CA |
1605403 | Dec 2005 | EP |
1605403 | Dec 2005 | EP |
2048887 | Apr 2009 | EP |
2048887 | Apr 2009 | EP |
20130086012 | Jul 2013 | KR |
03021969 | Mar 2003 | WO |
WO2012102867 | Aug 2012 | WO |
WO2013032576 | Mar 2013 | WO |
Entry |
---|
Schrieber W.F.; “Advanced Television Systems for Terrestrial Broadcasting: Some Problems and Some Proposed Solutions”, Proceedings of the IEEE, IEEE New York, US, vol. 83, No. 6, Jun. 1, 1995, pp. 958-981. |
Shimono et al.; “Transform Image Coding With Edge Compensation”, Electronics and Communications in Japan, Part I: Communications, Hoboken, NJ, US, vol. 74, No. 10, Oct. 1, 1991, pp. 49-56. |
Price, Thomas B.; “Muscle and Liver Carbohydrates: Response to Military Task Performance by Women and Men”, Oct. 1, 1997, http://www.dtic.mil/docs/citations/ADA337501, p. 10. |
Arbeiter, J. H. et al.; “A Two-Dimensional Real-Time Video Pyramid Processor”, RCA Review, RCA Corp. Princeton, US, vol. 47, No. 1, Mar. 1, 1986, pp. 3-31. |
Chee, Y-K.; “Survey of Progressive Image Transmission Methods”, International Journal of Imaging Systems and Technology, Wiley and Sons, New York, US, vol. 10, No. 1, Jan. 1, 1999, pp. 3-19. |
International Search Report and Written Opinion dated Oct. 25, 2013, in co-pending International Application No. PCT/US2013/054311. |
International Preliminary Report and Written Opinion for PCT/US2013054311, mailed Feb. 10, 2015, 12 pages. |
Schrieber W. F.: Advanced Television Systems for Terrestrial Broadcasting: Some Proposed Solutions, IEEE vol. 83, No. 6 , Jun. 1, 1995 pp. 958-981. |
“Series H: Audiovisual and Multimedia Systems; Infrastructure of audiovisual services—Coding of moving video; Advanced video coding for generic audiovisual services”. H.264. Version 1. International Telecommunication Union. Dated May, 2003. |
“Series H: Audiovisual and Multimedia Systems; Infrastructure of audiovisual services—Coding of moving video; Advanced video coding for generic audiovisual services”. H.264. Version 3. International Telecommunication Union. Dated Mar. 2005. |
“Overview; VP7 Data Format and Decoder”. Version 1.5. On2 Technologies, Inc. Dated Mar. 28, 2005. |
“Series H: Audiovisual and Multimedia Systems; Infrastructure of audiovisual services—Coding of moving video; Advanced video coding for generic audiovisual services”. H.264. Amendment 1: Support of additional colour spaces and removal of the High 4:4:4 Profile. International Telecommunication Union. Dated Jun. 2006. |
“VP6 Bitstream & Decoder Specification”. Version 1.02. On2 Technologies, Inc. Dated Aug. 17, 2006. |
“Series H: Audiovisual and Multimedia Systems; Infrastructure of audiovisual services—Coding of moving video”. H.264. Amendment 2: New profiles for professional applications. International Telecommunication Union. Dated Apr. 2007. |
“VP6 Bitstream & Decoder Specification”. Version 1.03. On2 Technologies, Inc. Dated Oct. 29, 2007. |
“Series H: Audiovisual and Multimedia Systems; Infrastructure of audiovisual services—Coding of moving video”. H.264. Advanced video coding for generic audiovisual services. Version 8. International Telecommunication Union. Dated Nov. 1, 2007. |
“Series H: Audiovisual and Multimedia Systems; Infrastructure of audiovisual services—Coding of moving video”. H.264. Advanced video coding for generic audiovisual services. International Telecommunication Union. Version 11. Dated Mar. 2009. |
“Series H: Audiovisual and Multimedia Systems; Infrastructure of audiovisual services—Coding of moving video”. H.264. Advanced video coding for generic audiovisual services. International Telecommunication Union. Version 12. Dated Mar. 2010. |
“Implementors' Guide; Series H: Audiovisual and Multimedia Systems; Coding of moving video: Implementors Guide for H.264: Advanced video coding for generic audiovisual services”. H.264. International Telecommunication Union. Version 12. Dated Jul. 30, 2010. |
“VP8 Data Format and Decoding Guide”. WebM Project. Google On2. Dated: Dec. 1, 2010. |
Bankoski et al. “VP8 Data Format and Decoding Guide; draft-bankoski-vp8-bitstream-02” Network Working Group. Dated May 18, 2011. |
Bankoski et al. “Technical Overview of VP8, an Open Source Video Codec for the Web”. Dated Jul. 11, 2011. |
Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., Wilkins, P., and Y. Xu, “VP8 Data Format and Decoding Guide”, RFC 6386, Nov. 2011. |
Mozilla, “Introduction to Video Coding Part 1: Transform Coding”, Video Compression Overview, Mar. 2012, 171 pp. |
ISR and Written Opinion mailed Jul. 16, 2012, for PCT/US2012/034635 (13 pp). |
Zhao, Qin, et al.; “Efficient Memory Shadowing for 64-bit Architectures”, Procedings of the 2010 International Symposium of Memory Management, Jun. 5, 2010, pp. 93-102. |
Aoki et al., “Prediction-Based QP Derivation”, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG16 WP3 and ISO/IEC JTC1/SC29/WG11 5th Meeting: Geneva, CH, Mar. 16-23, 2011. |
Bross et al., “High-Efficiency Video Coding”, Joint Collaborative Team on Video Coding (JCT-VC) JCTVCF803 of ITU-T SG16 WP3 and ISO/IEC JTC1/SC29/WG11 6th Meeting: Torino, IT Jul. 14-22, 2011. |
Bross, Benjamin et al.: “High Efficiency Video Coding (HEVC) text specification draft 8,” Joint Collaborative Team on Video Coding(JCT-VC) of ISO/IEC JTC1/SC29/WG11 and ITU-T SG16 WP3, document JCTVC-J1003—d7, 10th Meeting : Stockholm, SE, Jul. 11-20, 2012, all pages. |
Chuang et al., AHG Quantization: Sub-LCU Delta QP, Joint Collaborative Team on Video Coding(JCT-VC) of ITU-T SG16 WP3 and ISO/IEC JTC1/SC29/WG11 5th Meeting: Geneva,CH, Mar. 16-23, 2011. |
Coban et al., CU-Level QP Prediction, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG16 WP3 and ISO/IEC JTC1/SC29/WG11 5th Meeting: Geneva, Ch, Mar. 16-23, 2011. |
Flynn D et al.: “Transform Skipping in the presence of Scaling Lists”, 101 MPEG Meeting; Jul. 16-Jul. 20, 2012; Stockholm; (Motion picture Expert Group or ISO/IEC JTC1/ZSC29/WG11), No. m25414, Jul. 5, 2012, all pages. |
ISR, “ISR Search Report and Written Opinion of the International Searching Authority” for International Application No. ISR/US2013/058376 (CS40854) dated Nov. 22, 2013, 12 pages. |
Wiegand et al., “WD2: Working Draft 2 of High-Efficiency Video Coding,” JCTVC-D503, Jan. 2011. |
Kobayashi M et al.; “Sub-LCU Level delta QP signaling”, 96.MPEG Meeting Mar. 21-Mar. 25, 2011; Geneva; (Motion Picture Expert Group or ISO/IEC JTC1/SC29/WG11), No. m19716, Mar. 17, 2011, all pages. |
L Dong et al.: “CU Adaptive Quantization Syntax Change for Better Decoder pipelining”, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG16 WP3 ans ISO/IEC JTC1/SC29/WG11, vol. JCTVC-D258, Jan. 15, 2011, all pages. |
Pang et al.,“Improved DPQ Calculation Method”, Joint Collaborative Team on Video Coding (JTC-VC) of ITU-T SG16 WP3 and ISO/IEC JTC1/SC29/WG11 5th Meeting: Geneva, CH, Mar. 16-23, 2011. |
Shima et al., “Support for Sub-LCU-Level QP in HEVC”, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG16 WP3 and ISO/IEC JTC1/SC29/WG11 %th Meeting: Geneva, CH, Mar. 16-23, 2011. |
Thomas Wiegand; “Working Draft No. 2, Revision 2 (WD-2) H.26L”, 2. JVT Meeting; Jan. 29-Feb. 1, 2002; Geneva, CH; (Joint Video Team of ISO/IEC JTC1/SC29/WG11 and ITU-T SG.16), No. JVT-18r2, Feb. 1, 2002, all pages. |
Cassidy, An analysis of VP8, a new video codec for the web, 148 pages. Nov. 2011. |
Jun-Ren Ding et al.; “Two-Layer and adaptive entropy coding algorithms for H. 264-based lossless image coding”, Acoustics, Speech and Signal Processing, 2008. ICASSP 2008. IEE International conference on IEEE, Piscatawa, NJ, USA Mar. 31, 2008. |
Pai, et al., MPEG 4 constant quality constant bit rate control algorithms, signal processing:image communication, Jan. 2005, vol. 21, Issue 1, pp. 67-89. |
Park, Jun Sung, et al., “Selective Intra Prediction Mode Decision for H.264/AVC Encoders”, World Academy of Science, Engineering and Technology 13, (2006). |
Schwarz H. et al.: “SNR-scalable extension of H.264/AVC” , Image Processing, 2004. ICIP 2004 International Conference on Singapore Oct. 24-27, 2004. |
International Search Report Application No. PCT/US2013/063722 mailed on Dec. 9, 2013. |
Number | Date | Country | |
---|---|---|---|
20140044164 A1 | Feb 2014 | US |