Method and system of hardware accelerated video coding with per-frame parameter control

#Video compression makes it possible to use video data in many different ways. Without it, distribution of video by tape, disk, network, or any other form would be much more difficult. Due to ever increasing video resolutions, and rising expectations for high quality video images, a high demand exists for efficient image data compression of video. Video compression is computationally intense, and requires speed tradeoffs for quality. This is true for any video coding standard format such as Advanced Video Coding (AVC), H.265/HEVC (High Efficiency Video Coding), VP #, and other video coding standards. The aforementioned standards use expanded forms of traditional approaches to address the insufficient compression and/or quality problem, but often the results are still insufficient and require a relatively large amount of computations and time to compute the results. Thus, high resolution encoding is often too slow, and even slower than real time.

#One solution to reduce delays caused by encoding is to use graphics hardware accelerators that have special purpose hardware to process large amounts of video coding data. This hardware can frequently process multiple streams faster than real time. Multiple video encode acceleration, however, raises other problems. The accelerator still must process frame data sufficiently fast to permit an encoder to provide frames at a certain target frame rate across multiple encodes. To guarantee these frame rates for all possible inputs, no matter the complexity of the images for example or other variations in image content or delivery, conservative encoder quality/performance tradeoff settings must be used to account for worst case scenarios. This sacrifices opportunities to increase overall quality of the video encode. No mechanism exists to automatically tune the encoder settings based on the rate or latency of image content being processed to maximize quality while maintaining a specified output frame rate across multiple encodes.

#The material described herein is illustrated by way of example and not by way of limitation in the accompanying figures. For simplicity and clarity of illustration, elements illustrated in the figures are not necessarily drawn to scale. For example, the dimensions of some elements may be exaggerated relative to other elements for clarity. Furthermore, where considered appropriate, reference labels have been repeated among the figures to indicate corresponding or analogous elements. In the figures:

#FIG. 1 is a schematic diagram of a video coding device with multiple encoder sessions according to the implementations herein;

#FIG. 2 is a flow chart of a method of video coding with per-frame parameter control according to the implementations herein;

#One or more implementations are now described with reference to the enclosed figures. While specific configurations and arrangements are discussed, it should be understood that this is done for illustrative purposes only. Persons skilled in the relevant art will recognize that other configurations and arrangements may be employed without departing from the spirit and scope of the description. It will be apparent to those skilled in the relevant art that techniques and/or arrangements described herein also may be employed in a variety of other systems and applications other than what is described herein.

#While the following description sets forth various implementations that may be manifested in architectures such as system-on-a-chip (SoC) architectures for example, implementation of the techniques and/or arrangements described herein are not restricted to particular architectures and/or computing systems and may be implemented by any architecture and/or computing system for similar purposes unless the architecture is particularly limited to structure described herein. For instance, various compute architectures employing, for example, graphics accelerators and/or graphics processing units (GPUs), very large instruction word (VLIW) processors, specialized codec acceleration hardware, etc., may implement the techniques and/or arrangements described herein. Furthermore, while the following description may set forth numerous specific details such as logic implementations, types and interrelationships of system components, logic partitioning and/or integration choices, etc., claimed subject matter may be practiced without such specific details. In other instances, some material such as, for example, control structures and full software instruction sequences, may not be shown in detail in order not to obscure the material disclosed herein.

#When not specifically mentioned, the material disclosed herein may be implemented in hardware, firmware, software, or any combination thereof. Some of the material disclosed herein also may be implemented as instructions stored on a machine-readable medium, which may be read and executed by one or more processors. A machine-readable medium may include any medium and/or mechanism for storing or transmitting information in a form readable by a machine (e.g., a computing device). For example, a machine-readable medium may include read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other forms of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.), and others. In another form, a non-transitory article, such as a non-transitory computer readable medium, may be used with any of the examples mentioned above or other examples except that it does not include a transitory signal per se. It does include those elements other than a signal per se that may hold data temporarily in a “transitory” fashion such as RAM and so forth.