|Publication number||US7809061 B1|
|Application number||US 10/763,772|
|Publication date||Oct 5, 2010|
|Filing date||Jan 22, 2004|
|Priority date||Jan 22, 2004|
|Publication number||10763772, 763772, US 7809061 B1, US 7809061B1, US-B1-7809061, US7809061 B1, US7809061B1|
|Original Assignee||Vidiator Enterprises Inc.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (16), Non-Patent Citations (3), Referenced by (14), Classifications (31), Legal Events (2)|
|External Links: USPTO, USPTO Assignment, Espacenet|
The present disclosure generally relates to video encoding, and more particularly but not exclusively, relates to hierarchical data reuse or data sharing techniques to improve efficiency in video encoding when producing multiple unique video streams from a common input source.
In the wireless video communication field, there is rarely a uniform standard for video. Various organizations, content providers, device manufacturers, and/or service providers are free to use and support any one or more video standards (e.g., variations in format, frame rate, bit rate, color scheme, etc.), which may at times be incompatible with each other. As a result, systems have been developed to transcode one or more video inputs into multiple unique video streams (each having different formats, frame rates, bit rates, etc.), where the end terminal devices can receive and play back a compatible and supported one of the video streams.
In encoding stations that produce multiple unique video streams from at least one common video input source (e.g., raw unformatted video input), multiple software encoders are provided. Each of these encoders performs their own independent and separate encoding process on the raw video input. For instance, one encoder in the encoding station may encode the unformatted video input into Motion Pictures Expert Group-4 (MPEG-4) video having a 352×288 resolution, 512 kbps bit rate, YUV color scheme, 15 frames/second frame rate, and so on. Another encoder in the encoding station may encode the unformatted video input into MPEG-4 video having a 160×128 resolution, 200 kbps bit rate, YUV color scheme, 15 frames/second frame rate, and so on.
Software video compression or video encoding is a computationally expensive task. The amount of processing power available per software encoding station is the limiting factor on the number of video encodings that can be performed simultaneously per encoding station. The independent and separate processing performed by each encoder results in significant redundant processing, which wastes processor cycles and therefore reduces the overall number of outputs and/or throughput speed of unique video streams.
According to one aspect of the invention, a method is provided to encode multiple video outputs from a common input video source. The method includes temporally sub-sampling video frames of the common input video source to reduce a frame rate, and converting a color format of the video frames from a first format to a second format. The method then performs full motion estimation on a first sequence of video frames and generates motion estimation data to substantially match blocks of pixels from one video frame to another video frame in the first sequence, and generates a first video output using the generated motion estimation data. The method further includes reusing the generated motion estimation data to perform partial motion on at least a second sequence of video frames to substantially match blocks of pixels from one video frame to another video frame in the second sequence and modifies the generated motion estimation data to correspond to blocks of pixels in the second sequence that match, and generates a second video output using the modified motion estimation data.
According to one aspect, an article of manufacture, comprises a machine-readable medium having instructions stored thereon to cause a processor to encode multiple video outputs from common input video data, by: determining data producer and data user relationships between encoder components; directing output produced from a first encoder component to a second encoder component in a same first encoder; directing the output produced from the first encoder component to another encoder component in a second encoder different from the first encoder; and using the output from the first encoder component in the second encoder component and producing output from the second encoder that is modified from the output produced by the first encoder.
In one aspect of the article of manufacture, producing output from the first encoder component includes producing full motion estimation data, and using the output from the first encoder component in the second encoder component includes using at least some of the produced motion estimation data to locate an approximate location of a block of pixels in a frame without performing full motion estimation.
In one aspect of the article of manufacture, the motion estimation data includes motion vector information.
In one aspect of the article of manufacture, the machine-readable medium further has instructions stored thereon to cause the processor to encode multiple video outputs from common input video data, by: temporally sub-sampling video frames of the common input video source to reduce a frame rate; converting a color format of the video frames from a first format to a second format; and hierarchically Human Visual System (HVS)-based pre-processing the video frames to obtain different bit rates and to remove high frequency information from the video frames.
In one aspect of the article of manufacture, the machine-readable medium further has instructions stored thereon to cause the processor to encode multiple video outputs from common input video data, by adapting the hierarchical HVS-based pre-processing based on outputs from subsequent encoder component processing.
Embodiments of techniques for hierarchical data reuse to improve efficiency in the encoding of unique multiple video streams are described herein. In the following description, numerous specific details are given to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.
Reference throughout this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
As an overview, one embodiment of the invention involves the sharing of data across many simultaneous software video encode/compressions sessions with a common input video source. This reduces the amount of work done by each individual encoder by intelligently sharing/reusing data between encoders at various stages of encoding. Each encoder may use the data from another encoder “as-is” or may further minimally process the data to fit the needs of appropriate encoding parameters. This data sharing reduces the overall encoding time of the streams significantly by reducing the duplicative work that would otherwise have to be performed by each encoder. Data sharing thus enables production of more simultaneous unique compressed video streams per encoding station. To enable sharing and reuse of data between encoders, various modules (such as software modules) in the encoding pipeline operate in a hierarchical manner in one embodiment, and cooperate to produce multiple unique video streams that may differ in format, bit rate, resolution, frame rate, or other video characteristic or parameter.
One embodiment of the invention enables the reuse of data between multiple encoders at different stages of encoding. This data reuse saves computational bandwidth and time, since the results from one encoder component (a “publisher” or “producer”) can be used by one or more other encoders' components (a “client” or “consumer”). The client encoders may use the published data without further modification or may further modify the data to fit that client encoder's needs. The computational bandwidth required to modify the data is significantly less, as compared to the amount of computational bandwidth that would be required to produce the data when the data has not undergone previous processing by other encoders.
Example implementations for embodiments of the invention include scenarios where multi-resolution, multi-bit rate, or multi-format compressed videos are desired from a common source. Such video can be compressed or encoded for a file or for a live broadcast, for instance. In another implementation, the hierarchical data sharing technique may be used to transcode pre-compressed video into multiple videos, where the common source is decoded output of the pre-compressed video. It is understood that these are but a few example implementations and that others are possible.
In the process 100 of
Beginning at the block 102, video is received from a common video source. For example, a particular content provider may provide raw unformatted video of a program (e.g., a sporting event, news clip, interview, etc.), which will be encoded or transcoded via the process 100 to provide multiple unique video stream outputs having the program but with different formats, resolutions, bit rates, etc. There may be multiple content providers or other entities that provide raw video content, which individually comprise common video sources that will each be encoded into multiple unique video streams.
At the block 104, the raw video undergoes temporal sub-sampling to reduce the frame rate of the video. Color format conversion is performed at the block 106, where the video may undergo color format conversion to change the color format from one color scheme to another color scheme (e.g., from RGB to YUV, or vice versa).
In an embodiment, the temporal sub-sampling and color format conversion at the blocks 104 and 106 may be performed only once for all encoders, such as in a situation where all encoders in the encoding station will use the same frame rate and color format. This technique avoids the need for repetitive processing, and is in contrast to some existing techniques where each encoder individually and redundantly does the same temporal sub-sampling and color conversion for their respective inputs.
The process 100 performs anti-aliasing filtering and spatial sub-sampling at the block 108 to change the resolution to a lower resolution. In one embodiment, Human Visual System (HVS) pre-processing is then performed at the block 110 on the input video frames of each encoder to reduce the high-frequency information in a frame. Reducing the high-frequency information optimizes the compression efficiency and maximizes the perceived video quality of a compressed sequence for a given bit rate.
In the block 112, motion estimation is performed to search in a specified search area in a previous frame for a candidate block that is most similar to a current block in a current frame. A motion vector is generated during the motion estimation that is indicative of the relative position of the blocks between the two frames. In an embodiment that will be described later below, full motion estimation is performed by only one of the encoders, and then that encoder's results are progressively used by the other encoders (working with a lower resolution or smaller frames) to estimate the location of the similar macroblocks of pixels in their respective frames. That is, after one of the encoders has generated motion vectors to predict the general location of macroblocks from one frame to another frame, the other encoders can reuse the same motion vectors to predict the location of similar macroblocks in the frames that they are processing (e.g., perform partial motion estimation and motion vector sharing, rather than having to perform their own full motion estimation and motion vector generation).
Final encoding operations are performed at the block 114. These operations can include, but are not limited to, discrete cosine transform (DCT) operations, motion compensation to use the results of the motion estimation of the block 112 to generate frames, rate control, and syntax encoding. The results of the block 114 can be fed back to the HVS-based pre-processing block 110 (or to some other blocks in the process 100) to provide adaptive features, where outputs can be used to refine or improve prior processes. The multiple unique video streams result as output at the block 116, and can thereafter be transmitted to end terminal devices.
A negotiation block 118 is shown symbolically in
To better illustrate operation of an embodiment of the hierarchical data sharing technique, an example will be described next in
For purposes of this specific example, it will be assumed that five video output streams (“video sequences”) V1-V5 are desired as output from the video encoding station. The example parameters for the format, bit rate, resolution, and frame rate for the video sequences V1-V5 are identified in the table below. As can be seen, certain ones of the video sequences share some common parameters, but may differ in other parameters. For instance, video sequences V1-V3 are in MPEG-4 format but have different bit rates. Video sequences V3 and V4 have different formats (MPEG-4 and H.263) but have the same bit rate, resolution, and frame rate. In this example, all of the video sequences V1-V5 have the same frame rate of 15 frames/second.
352 × 288
352 × 288
176 × 144
176 × 144
160 × 128
The RGB24 frames are fed into the temporal sub-sampling block 104 to reduce the frame rate to 15 frames/second, which is the frame rate to be used by the final output video sequences V1-V5. Techniques for temporal sub-sampling are familiar to those skilled in the art, and therefore will not be described in further detail herein.
In this example and since all of the video sequences V1-V5 will have the same frame rate, the input frames from the block 102 may be temporally sub-sampled once for all five encoders, rather than five times. In situations where there final video sequences V1-V5 have different frame rates, a separate individual temporal sub-sampling may be performed for each encoder in one embodiment (e.g., five separate temporal sub-sampling processes).
In another embodiment, there may also be a hierarchical flow of temporal sub-sampling at the block 104. In this embodiment, a first stage temporally sub-samples the input frames to a lower frame rate. The lower frame rate output can then be used directly by an encoder corresponding to that frame rate, and that lower frame rate output can also be an input to a second stage to be temporally sub-sampled to produce a next lower frame rate output, which will be used by another encoder. This temporal sub-sampling at the block 104 to produce progressively lower frame rates can continue until all of the desired frame rate outputs have been generated.
Color format conversion is performed at the block 106 to change the color scheme of the frames from RGB24 to YUV420. After completion of the color format conversion at the block 106, the frame rate is 15 frames/second and the resolution is unchanged at 640×480 in the video output data (denoted at “A” to indicate a data flow continuation point into the next sub-process 108 in
As with the temporal sub-sampling at the block 104, the color format conversion may be performed individually for some of the encoders in another embodiment. Such may be the case for instance, where some encoders use a color scheme that is different than YUV but which can be derived or otherwise converted from the RGB color scheme of the raw input video data—therefore, these other color schemes need not undergo an intermediate YUV conversion. In other embodiments, it is also possible to provide a hierarchical color conversion process at the block 106 where an RGB color scheme (which can used by a first encoder) is converted to a YUV color scheme (which can be used by a second encoder), which is then converted to some other color scheme (which can then be used by a third encoder), and so forth, in a manner that certain color schemes can be intermediately generated and directly used in some encoders and/or used as input to other color conversion processes.
It is noted that with the architecture of
Therefore, the embodiment of
To illustrate operation of the embodiment, the block 400 is the sole block that receives the video input at A. The block 400 generates filtered sub-sampled data output at B1 having a resolution of 352×488. The filtered sub-sampled data output of B1 is fed into the next stage of encoding in
In the embodiment of
One result of low pass filtering is the blurring of the image. So clearly, the trade off is between having a soft smooth image sequence with minimal frame dropping, versus a crisp image sequence with artifacts and possible higher frame dropping.
The solution to this trade off is very subjective and depends on personal preferences. Human visual sensitivity or Human Visual System (HVS) is inversely proportional to the motion velocity of objects, and HVS-based pre-processing systems is based on the fact that the human eye has a poor response to abrupt rapid changes in a sequence. In one embodiment, each individual block 500-506 of
For example, the output at C1 of the block 500 is also used as input to the block 502, since these blocks correspond to the output video sequences V1 and V2 having the same resolution of 352×288. The block 500 produces pre-processed data, which is fed into both the next stage in the encoder (see, e.g., the block 600 in
In another embodiment, the HVS-based pre-processing at the blocks 500-506 of
Furthermore, variable frame rate encoders often drop frames when there are not enough bits available to encode a video frame, and there may be a maximum limit on the number of consecutive frames that can be dropped. The lack of bits can be due to two reasons: 1) the current frame is estimated to produce significantly more than rationed bits for that frame, and/or 2) the previous encoded frames produced more than estimated bits and led to undesired levels of video buffer verifier (VBV) buffer fullness. To respect the maximum limit, very high quantization factor (Q) values are used in existing techniques to reduce the number of bits, but very high Q values lead to abrupt change in video quality and an unpleasant viewer experience. To avoid abrupt changes in Q, an embodiment of the HVS-based pre-processing increases the strength of pre-filtering as the VBV buffer overshoots and with each dropped frame. Doing so leads to a gradual change of the quality over multiple frames, thus maintaining a gradual change in quantization factor.
An embodiment of the hierarchical HVS-based pre-processing at the blocks 500-506 uses at least some of the following information to apply an appropriate filter strength for each frame:
Level of quantization
Motion velocity of objects in frame in reference to the previous frame
Abrupt changes in the scene
Number of consecutive frames skipped
VBV buffer fullness
In temporally compressed videos, estimates of motion velocity and abrupt changes in a scene can be computed after motion estimation at the block 112 of
Based on these criteria, an embodiment of the HVS-based pre-processing filters at the blocks 500-506 comprise a set of two filters with programmable regions of support and strength:
Once the closely matching candidate block in the previous frame is located, a motion vector is generated that indicates the relative position between the matching candidate block in the previous frame and the current block in the current frame. Instructions to use the data from the previous frame plus the motion vector information (collectively indicated as “ME and MB mode data” at D1 in
Other final encoding operations are performed at the block 608, including DCT operations, rate control to control the number of bits per frame, and syntax encoding to place the video data in the appropriate syntax (in this example, the block 608 performs syntax encoding to place the frames in MPEG-4 syntax). These operations would be familiar to those skilled in the art having the benefit of this disclosure, and therefore will not be described in further detail herein. The final video output sequence V1 is produced at 116, having a bit rate of 512 kbps, frame rate of 15 frames/second, and other parameters listed in the table above.
In the block 600, all macroblocks in any current frame are searched for matching candidate blocks in a previous frame and corresponding motion vectors are generated, as is done with existing techniques. Thus, the complete ME and MB mode decisions are made only by the block 600 in this specific example. Since even the fastest search algorithms are fairly computationally expensive, it is desirable to reduce the amount of searching and/or motion vector generation that needs to be performed in other blocks.
Accordingly, one embodiment of the invention provides one or more blocks that hierarchically reuse or adapt the ME and MB data produced by a block that does the complete ME and MB operations (such as the block 600). In this manner, the hierarchical block(s) can reduce the amount and area of their searching by using the prior-generated search data (from another block) as the starting point to focus their searches.
The block 602 uses the search information published by the block 600 as the starting point of the search. In one embodiment, this involves having the block 602 use the motion vector produced by the block 600 to generally focus to an initial search area in a previous frame. While the motion vector generated from the block 600 (for the video sequence V1) may not exactly provide the location of the candidate block for the video sequence V2, that motion vector at least provides an approximate location that can be searched by the block 602.
If there is a match of macroblocks within an empirically determined threshold, no further refinement need be done. If there is no match within the empirically determined threshold, then the searching is refined by the block 602 over smaller search areas as compared to search areas used in the block 600. Techniques to generate and use empirically determined thresholds for matches are familiar to those skilled in the art and will not be described in detail herein.
After finding matching macroblocks, the block 602 generates updated (or new) motion vectors that exactly correspond to the location of the matching macroblocks and generates other search-related information (indicated as generally as “modified and adapted ME and MB mode data” in
The output D2 of the block 602 is also selected by the negotiation block 118 as input to the block 604, rather than the output of the block 600. This decision was made because the bit rates between the block 602 (400 kbps) and the block 604 (256 kbps) are closer together, as compared to the block 600 (512 kbps). Because the block 604 processes video frames with a scaled-down, lower resolution of 176×144 (as compared to the 352×288 at the block 602), the motion data provided at D2 is averaged and scaled down by the block 604. As before, this motion data (e.g., the motion vector and other search-related data) is used as the starting point for the searching performed by the block 604. The search results are compared with empirically determined thresholds to determine if sufficient matching exists, and refined over smaller search areas if necessary.
Resulting modified and adapted ME and MB mode data is produced by the block 604 at D3. The output at D3 is provided by input to a final encoding block 612, which performs DCT operations, motion compensation, and so forth for the output video sequence V3 to produce MPEG-4 video at 256 kbps, 15 frames/second, and other video parameters listed in the table above.
The output at D3 is also provided as input to a final encoding block 614, which performs DCT operations, motion compensation, rate control, and syntax encoding for H.263 format for the output video sequence V4. The output at D3 was chosen as the input to the block 614 because the output video sequence V4 has the same frame rate, bit rate, and resolution as the output video sequence V3, but differ only in syntax format (e.g., MPEG-4 vs. H.263).
The output at D3 is further used as input to the block 606, which performs motion estimation data adaptation for the output video sequence V5. As before with the other blocks 602 and 604, the block 606 uses the published ME and MB data from a prior block (e.g., the block 604) as a starting point for searching, thereby reducing the amount of searching and motion vector generation that would otherwise need to have been performed fully from the beginning.
The block 606 produces modified and adapted ME and MB data output at D4, which is provided as input to a block 616. The block 616 performs DCT operations, motion compensation, syntax encoding, etc. to produce the output video sequence V5 having an MPEG-2 format, bit rate of 200 kbps, frame rate of 15 frames/second, and so forth at 116.
Therefore, it is evident from the example in
The above example is just one specific case used to demonstrate an embodiment of the data sharing technology. The architecture is scalable, flexible, and programmable to allow many possible combinations of data sharing at various levels. Each shared block is hierarchical and adaptive in nature in one embodiment. For example, the output video sequences V1-V2 at 116 in
All encoders with a common source are assigned to one session. At the beginning of the session, each encoder publishes its data requirements.
Based on the characteristics of each encoder, the negotiation block 118 sets up the data flow paths and defines the publisher and consumer relation between various blocks that share data. To further optimize the whole process, the encoders work on shared memory resources in one embodiment, thereby eliminating unnecessary memory copies. There are no hard set limitations on the number of simultaneous encodes. The limitations, if any, originate from time constraints imposed due to the capabilities of hardware processors.
One embodiment of the inventions can be viewed as a single encoder with multiple encoding blocks. Accordingly for the previously described
The encoding station includes transcoders 706, streaming servers 708, controllers 710, storage media 712, and other components (not shown) that cooperate to receive the common raw unformatted video, encode that video using the techniques described above to produce multiple video outputs, and send the multiple video outputs to wireless terminal devices 716 or other devices.
In an embodiment, the techniques for hierarchical data sharing and data reuse described above can be embodied in software stored in the storage media 712 (or other storage location) and executed by the controller 710 (or other processor) in cooperation with the transcoders 706. Once encoded or transcoded into the appropriate format, bit rate, resolution, frame rate, etc., the multiple unique video outputs are transmitted by the streaming servers 708 to a communication network 714 (such as a wireless network, Internet, telephone network, etc.) for transport to the wireless terminal devices 716.
All of the above U.S. patents, U.S. patent application publications, U.S. patent applications, foreign patents, foreign patent applications and non-patent publications referred to in this specification and/or listed in the Application Data Sheet, are incorporated herein by reference, in their entirety.
The above description of illustrated embodiments of the invention, including what is described in the Abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the invention and can be made without deviating from the spirit and scope of the invention.
For example, while embodiments of the invention have been described in the context of video streams, it is possible to provide other embodiments that are applicable to audio-only streams or a combination of audio and video. Hierarchical data reuse systems may be thus be provided to reduce redundancies that otherwise may be present when transmitting audio data, thereby improving the overall efficiency of the audio transmission when there is a need to transmit multiple unique audio streams.
As another example, up-sampling may be performed in some embodiments, instead of the sub-sampling described herein. Up-sampling may be used where desired to increase the resolution, frame rate, or other video characteristic or parameter.
These and other modifications can be made to the invention in light of the above detailed description. The terms used in the following claims should not be construed to limit the invention to the specific embodiments disclosed in the specification and the claims. Rather, the scope of the invention is to be determined entirely by the following claims, which are to be construed in accordance with established doctrines of claim interpretation.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5231484||Nov 8, 1991||Jul 27, 1993||International Business Machines Corporation||Motion video compression system with adaptive bit allocation and quantization|
|US5801778 *||May 23, 1996||Sep 1, 1998||C-Cube Microsystems, Inc.||Video encoding with multi-stage projection motion estimation|
|US6229850 *||Oct 19, 1999||May 8, 2001||C-Cube Semiconductor Ii, Inc.||Multiple resolution video compression|
|US6337881 *||Mar 23, 2000||Jan 8, 2002||Microsoft Corporation||Multimedia compression system with adaptive block sizes|
|US6535632||Aug 30, 1999||Mar 18, 2003||University Of Washington||Image processing in HSI color space using adaptive noise filtering|
|US7184578||Jan 31, 2006||Feb 27, 2007||Eastman Kodak Company||Method and system for enhancing portrait images that are processed in a batch mode|
|US7266149||Dec 17, 2002||Sep 4, 2007||Microsoft Corporation||Sub-block transform coding of prediction residuals|
|US7272180 *||May 9, 2003||Sep 18, 2007||Avocent Corporation||Video compression system|
|US20020165844||May 4, 2001||Nov 7, 2002||Juhnyoung Lee||System and method for configuring sell bids|
|US20020186890||May 3, 2001||Dec 12, 2002||Ming-Chieh Lee||Dynamic filtering for lossy compression|
|US20020196355||Jun 6, 2002||Dec 26, 2002||Seiko Epson Corporation||Image processing method, image processing program, image processing apparatus, and digital still camera using the image processing apparatus|
|US20030001964||Jun 26, 2002||Jan 2, 2003||Koichi Masukura||Method of converting format of encoded video data and apparatus therefor|
|US20030206664||Feb 11, 2003||Nov 6, 2003||Cristina Gomila||Deblocking filter conditioned on pixel brightness|
|US20040117427 *||Sep 12, 2003||Jun 17, 2004||Anystream, Inc.||System and method for distributing streaming media|
|US20050013359||Jul 15, 2003||Jan 20, 2005||Microsoft Corporation||Spatial-domain lapped transform in digital media compression|
|US20080002902||Sep 11, 2007||Jan 3, 2008||Samsung Electronics Co., Ltd.||Global and local statistics controlled noise reduction system|
|1||Duda et al., "Pattern Classification and Scene Analysis," Chapter 5-Linear Discriminant Functions, 1973; pp. 130-134.|
|2||Duda et al., "Pattern Classification and Scene Analysis," Chapter 5—Linear Discriminant Functions, 1973; pp. 130-134.|
|3||U.S. Appl. No. 10/815,280, filed Mar. 30, 2004, Sarna.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US8606029 *||Aug 12, 2011||Dec 10, 2013||Google Inc.||Hybridized image encoding based on region volatility|
|US8976863 *||Oct 23, 2009||Mar 10, 2015||Sk Telecom Co., Ltd.||Method and apparatus for encoding motion vector, and method and apparatus for encoding/decoding image using same|
|US9215466||Jan 31, 2011||Dec 15, 2015||Apple Inc.||Joint frame rate and resolution adaptation|
|US20080152014 *||Dec 14, 2007||Jun 26, 2008||On Demand Microelectronics||Method and apparatus for encoding and decoding of video streams|
|US20100053132 *||Nov 6, 2007||Mar 4, 2010||Nec Display Solutions, Ltd.||Liquid crystal display apparatus and liquid crystal display apparatus control method|
|US20110211640 *||Oct 23, 2009||Sep 1, 2011||Sk Telecom. Co., Ltd.||Method and apparatus for encoding motion vector, and method and apparatus for encoding/decoding image using same|
|US20120169900 *||Jul 5, 2012||Sony Corporation||Image processing device and image processing method|
|US20140015922 *||Jul 10, 2012||Jan 16, 2014||Broadcom Corporation||Real-time encoding system of multiple spatially scaled video based on shared video coding information|
|US20140016693 *||Jul 10, 2012||Jan 16, 2014||Broadcom Corporation||Real-time video coding system of multiple temporally scaled video and of multiple profile and standards based on shared video coding information|
|CN102592259A *||Jan 5, 2012||Jul 18, 2012||索尼公司||Image processing device and image processing method|
|CN103546757A *||Jun 28, 2013||Jan 29, 2014||美国博通公司||Video coding method and system|
|EP2685738A1 *||Jun 24, 2013||Jan 15, 2014||Broadcom Corporation||Real-time video coding system of multiple temporally scaled video and of multiple profile and standards based on shared video coding information|
|EP2685739A1 *||Jun 24, 2013||Jan 15, 2014||Broadcom Corporation||Real-time encoding system of multiple spatially scaled video based on shared video coding information|
|EP2833634A4 *||Mar 21, 2013||Nov 4, 2015||Sony Corp||Image processing device and method, and recording medium|
|U.S. Classification||375/240.16, 375/240.29|
|International Classification||H04N11/02, H04N7/12|
|Cooperative Classification||H04N21/2343, H04N19/85, H04N19/154, H04N19/56, H04N19/61, H04N19/172, H04N19/439, H04N19/164, H04N19/587, H04N19/12, H04N21/234327, H04N19/117, H04N19/436, H04N21/2662|
|European Classification||H04N21/2343L, H04N7/26M4I, H04N7/26L6, H04N7/26A6W, H04N7/26E, H04N7/26A6Q, H04N7/50, H04N7/26A8P, H04N7/26A4F, H04N7/26A4K, H04N7/26P, H04N21/2662, H04N19/00E4|
|Jan 22, 2004||AS||Assignment|
Owner name: VIDIATOR ENTERPRISES INC., BAHAMAS
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SARNA, LALIT;REEL/FRAME:014928/0880
Effective date: 20040121
|Dec 3, 2013||FPAY||Fee payment|
Year of fee payment: 4