What's next after H.264 ?

H.264 Advanced Video Compression (also known as MPEG-4 Part 10) is widely accepted as a leading video compression standard. Other formats such as VC-1 and AVS can (arguably) offer similar performance but H.264 is definitely a front runner in terms of coding efficiency. First standardized in 2003, H.264/AVC is now a mature technology. So what is next ?

The Moving Picture Experts Group (MPEG) and Video Coding Experts Group (VCEG) are examining the need for a new video compression standard. At the recent MPEG meeting (June 2009), several proposals for improved video compression were presented. The consensus was that (a) there is likely to be a need for a new compression format, as consumers demand higher-quality video and as processing capacity improves and (b) there is potential to deliver better performance than the current state-of-the art.

The current plan is to set up a Joint Collaborative Team (JCT) of MPEG and VCEG representatives to work on a new video coding standard. Proposals for the new standard will be reviewed in early 2010 and a new standard could be finalized around 2012/2013. It will aim to deliver significantly better compression performance than H.264/AVC, probably at a higher computational cost. Its working title ? High Performance Video Coding or Enhanced Performance Video Coding.

- Iain.

Video coding and cloud computing ?

The announcement of OnLive's "on-demand gaming" platform has generated a lot of interest. The basic idea is that a video game runs on a central server, not on your PC or games platform. You interact with the game via a broadband connection. The key to making this work is response time - the time lag between your input reaching the server and the updated game screen reaching your display. The gameplay video is rendered on the server and so a critical question is whether a high-definition, high framerate game display can be streamed to your display in real time.

OnLive claim that this can be done using video compression; i.e. compression of the rendered scene, streaming, decompression and display in a fraction of a second. If the platform matches up to the claims, then this might be the start of a trend towards cloud computing, in which high-performance computing is done on a remote server and the results (a rendered screen in this case) are sent to your display using video compression. Are current video compression algorithms good enough to support the cloud computing model ? We'll soon find out...

The ideal video codec ?

What would the idea video codec look like ? Here's a list of suggestions:

1. Just one video codec (instead of the ever-increasing number of competing video coding formats).

2. Delivers the best performance, i.e. a combination of:
a. maximum image quality and frame rate
b. minimum bit rate
c. minimum computational complexity or power consumption,
- the best combination of these factors for the platform (e.g. mobile, hardware, software...)

3. Easy upgrades (preferably completely transparent to the user) to take advantage of new ideas and techniques.

4. No license fees (or at least a license-free option).

5. No inter-operability problems.

6. Easy scalability (the same content on multiple platforms at multiple resolutions).

Impossible ? Maybe...

Comments very welcome !

- Iain.

Quantization - "flat" scaling factor.

JianFeng Zheng sent me a good question about H.264 inverse transform and quantization. In the H.264 standard, there is an extra division by 16 that occurs in section 8.5.8 (in the 2007 version of the document) that I don't mention in my tutorial on the inverse transform. It's not easy to see where this factor comes from.

H.264 includes the option to send a non-uniform quantization scaling matrix ("scaling list"), which makes it possible to quantize coefficients differently depending on their position in the block. The default scaling matrix, Flat_4x4_16 (or 8x8 equivalent) is a constant value for every coefficient position. The constant value is 16 (rather than 1 as might be expected). This is cancelled out by the division by 16 (implemented as a right-shift by 4 binary places) in section 8.5.8. So it all works out neatly.

Thanks to JianFeng for the question.

- Iain.

In the Bay area

I will be in the SF Bay area in August (10-14 Aug 09). If your company is working in the video coding space and you're keen to talk to me, let me know and I'll see if I can arrange a visit. - Iain.

H.264 quantization parameter

Quantization in an H.264 encoder is controlled by a quantization parameter, QP, that ranges from 0 to 51. QP is an index used to derive a scaling matrix. It is possible to calculate the equivalent quantizer step size (Qstep) for each value of QP (see my tutorial on H.264 4x4 transform). As QP increases, Qstep increases; in fact, Qstep doubles for every increase of 6 in QP. The logarithmic relationship can be seen in this graph of QP (x-axis, linear) vs. Qstep (y-axis, logarithmic).

Guest lectures

I will be giving a number of guest lectures on video coding over the next few months, in Rochester (NY), Aberdeen (UK), France and Spain. You can find out about arranging a lecture on H.264/AVC, video codec design and optimization, or emerging video coding topics, by visiting this page.