Difference between revisions of "H.264"

From esoterum.org
Jump to: navigation, search
(→‎Modifying the Encoder)
(→‎Reference Software)
Line 126: Line 126:
 
== Reference Software ==
 
== Reference Software ==
 
*[http://iphome.hhi.de/suehring/tml/ C Source code from Frauenhoefer]
 
*[http://iphome.hhi.de/suehring/tml/ C Source code from Frauenhoefer]
 +
:-[[JM12.4]]
 
*[[Simulation Software]]
 
*[[Simulation Software]]
 
*[http://www.videolan.org/ Videolan.org] (from Dr. Chatha)
 
*[http://www.videolan.org/ Videolan.org] (from Dr. Chatha)

Revision as of 16:04, 25 July 2008

Specification

Acronyms

  • RBSP: Raw Byte Sequence Payload

Hypothetical Reference Decoder

Final References

-The computational complexity of the coding algorithms directly affects the cost effectiveness of the development of a commercially viable H.264/AVC-based video solution.
-However, an increasing number of services and growing popularity of high definition TV are creating greater needs for higher coding efficiency. Moreover, other transmission media such as Cable Modem, xDSL, or UMTS offer much lower data rates than broadcast channels, and enhanced coding efficiency can enable the transmission of more video channels or higher quality video representations within existing digital transmission capacities.
-National University of Singapore
-In Fig. 3, it is shown that the CD error of each frame propagates to next frames in an exponential decreasing form. And “sum-of-indep-l5%CD indicates the sum of CD errors and all propagation errors caused by the independent cases. The accumulated errors at each codedframe can be approximated simply by the sum of propagation errors.
-Powerpoint Presentation
-Profiling Pie Chart
-From Srini's paper
-From Srini's paper

Tutorials

Parallelization

-Loughborough University, UK

International Symposium on Parallel Computing in Electrical Engineering. PAR ELEC 2006. Page(s):363 - 368

-Technical University of Valencia

Trading power for PSNR

Phase I

Modifying the Encoder

  • In contrast to the original proposal, we would like to look at modifying the encoder in order to make decisions about which blocks to drop. In this case, the decoder need only decide how many blocks to drop. The encoder would categorize and arrange the blocks in the stream so that the "important" blocks are sent first, enabling the decoder to drop the last n blocks without even decoding them.
  • One issue to be addressed in the encoder: how do we decide which blocks are more important? Currently the idea is to look at blocks with smaller motion vectors and consider those less important. An important issue which arises is that this might prevent large slow moving objects from moving at all in the image. This might be avoided if the encoder looks at the average vector size, or vector statistics in order to avoid this situation.

Modifying the Decoder

  • Enabling energy reduction functionality in the decoder without the benefit of a specialized encoder to first analyze the data poses some problems in terms of energy conservation. We want to reduce the amount of computation in order to throttle the processor, but the overhead required to make block dropping decisions might alleviate the advantage.

Phase II

Benchmarks

Players and PSNR calcualtors

  • VideoMeter, command line tool developed at ASU with PSNR calculations for 3 simultaneous yuv steams
-download videometer

Applicability to Bistable Displays

Articles

Survey

-OHSU, Beaverton, OR
-National University of Singapore
-Good block diagram for h.264
-Good workload breakdown for decoder (pie-chart)

DVFS

-Beijing
-Seoul
-Good discussion on dynamic and static leakage and dependence on operating voltage

Corruption Model

-Powerpoint Presentation

Profiling/Component Breakdown

-Profiling Pie Chart

General

-Distortion Control and Estimation

Reference Software

-JM12.4
-Documentation
-No linux support yet?

Last printed: 7.4

Retrieved from "https://www.esoterum.org/mw/index.php?title=H.264&oldid=1852"