What are the top things you wished folks understond about H.264?

[benwaggoner]

So, I'm about to dive into the H.264 chapter in the long-awaited second edition of my compression book.

EDIT: Fixed link:
http://www.focalpress.com/Book.aspx?id=7224&terms=%22ben+waggoner%22

...which was finished back in 2002, so it's pretty light on H.264 stuff :).

So, I thought I'd ping this community and ask what's the stuff that you wish people knew about H.264 and encoding for it that they don't. Options they miss or use incorrectly, misconceptions that yield wasted effort or suboptimal results.

And of course, the questions you get tired of answering again and again :).

Anyone have any pet peeves or best practices you think I should share?

[refulgentis]

link is for the creation of a new thread

[Sagekilla]

In loop deblocking is not bad, and large number of b-frames don't hurt compression (I'm looking at you, ASP) and psychovisual optimizations render metric comparisons useless.

[Dark Shikari]

Any company claiming that their format is X% better than H.264 in terms of compression is lying, because if it actually was, you would have heard about it already.

[Sagekilla]

To add on to that, the companies that do usually compare their format at high compression settings and use crappy ones for the competitor.

[kunkie]

People assuming that all H.264 encoders are equal. (e.g sticking with Quicktime).

[me7]

People assuming that all H.264 encoders are equal. (e.g sticking with Quicktime).

This is a very important point :goodpost:

[G_M_C]

In loop deblocking is not bad, and large number of b-frames don't hurt compression (I'm looking at you, ASP) and psychovisual optimizations render metric comparisons useless.

Well yes, but high number of B-frames aren't supported in formats like Blu-ray. And that brings up another point for the book; The standards that are choosen/have choosen H264 as video-compression, how do you encode for those ? Cause those standards lead to many questions around here (i.e Wat do i do for L4.1 compatibillity / How many b-frames can i use then / is b-pyramid allowed or not etc.). Or the simple question: How do i encode for BD-compatibillity, so that (for instance) Scenarists accepts my X264 encoded stream ?

Also, and this is more what i'd like to know; What about that NAL-HRD stuff. What's that got to do with H264, and why do i have to use that if i want to create a BD compatible stream ?

So my idea would be more focussed towards the applications of the stream. I.e. how to create a stream that is usable for the application you have in mind for the stream.

Stuff like that would have my intersts ?

[JohannesL]

That you should get the latest version of the encoder of choice instead of using something from 2006 and complaining about bugs.

[smok3]

that is not something invented by microsoft.

[me7]

that is not something invented by microsoft.

Never heard that claim before, but I know people who think it was invented by apple (since apple loves to show off with h.264 support on its homepage) and therefore Quicktime is the way to go for h.264 encoding.

[JohannesL]

Although more about x264 than H.264 in general, I'm pretty tired of people asking which bitrate to use for various sources to look good. Use CRF. and no, 2-pass is not better than CRF in terms of quality:bitrate.

[qyot27]

Well yes, but high number of B-frames aren't supported in formats like Blu-ray. And that brings up another point for the book; The standards that are choosen/have choosen H264 as video-compression, how do you encode for those ? Cause those standards lead to many questions around here (i.e Wat do i do for L4.1 compatibillity / How many b-frames can i use then / is b-pyramid allowed or not etc.). Or the simple question: How do i encode for BD-compatibillity, so that (for instance) Scenarists accepts my X264 encoded stream ?

Also, and this is more what i'd like to know; What about that NAL-HRD stuff. What's that got to do with H264, and why do i have to use that if i want to create a BD compatible stream ?

So my idea would be more focussed towards the applications of the stream. I.e. how to create a stream that is usable for the application you have in mind for the stream.

Stuff like that would have my intersts ?
Agreed. Having this type of info on VC-1 and MPEG-2 would be useful as well, at least for the sake of comprehensiveness.

[CruNcher]

Though this kind of info is marked as confidential (Specs arround it) Sony likes this you should have seen their UMD specs (you feel like reading army reports about UFOs) ;)

[benwaggoner]

link is for the creation of a new thread
Thanks, fixed.

[benwaggoner]

To add on to that, the companies that do usually compare their format at high compression settings and use crappy ones for the competitor.
...or the H.264 reference encoder.

[benwaggoner]

Agreed. Having this type of info on VC-1 and MPEG-2 would be useful as well, at least for the sake of comprehensiveness.
Yes, I'll have those as well. VC-1 is largely written already, which is somewhat easier as there's not nearly the diversity in implementations, so I can just ask the developers directly. Although I spend a fair amount of time talking about Format SDK versus VC-1 Encoder SDK versus <redacted>.

For H.264, x264, Main Concept, or the QuickTime implementation seem to underly most of the products I'll be talking about in detail. But they're so different in practice...

[Golgot13]

For H.264, x264, Main Concept, or the QuickTime implementation

Hi Ben,

I'm not sure you're the best person to talk about H264.
H264 is no limited at this softwares... There are Ateme,
CTC (CinemaCraft HDe), Sony (BAEVX1000),...

And there are hardware implementation too :
FPGA version like on Harmonic, TandBerg,...
ASIC version like on chipset from NTT Docomo, Fujitsu,...

And I'm not sure you talk about some H264 features:
- MBAFF
- PAFF
- High10, High422, High444
....
- SVC, Scalable Video Codec (new implemetation of H264)

[CruNcher]

Golgot13 he could go right into the next office building and talk with the ex Chairman of the JVT about H.264, guess he's even in the same building ;)
http://en.wikipedia.org/wiki/Gary_Sullivan_%28engineer%29

[Golgot13]

Golgot13 he could go right into the next office building and talk with the ex Chairman of the JVT about H.264, guess he's even in the same building ;)



And ...
Did you read some test report from ISO/CEI MPEG ?
=> MS contribution on H264 codec is very low.


But today I'm happy because MS understand H264 is the futur/beyond.

Cruncher read my old post about H264, I said many time H264 is used by many manufactor
and in differents standards (one of last: ATSC integrated it in summer 2008, and no VC1...).


Last Ben you can say today at Amir, H264 is the best codec because every people (professional)
used it ... (it was the answer gave by him to prouve that VC1 was better than H264 on avsforum.com).

I hope MS will understand to do not close a market on futur (with codec or standard).
MS make good work (codec, idea, concept,...), but many time they have not a good politic...
And I hope Ben, MS change some bad dark with you :)

[Sagekilla]

While it is against the rules to say something is the "Best" here I'd agree with you. But, VC-1 isn't too bad and I'd rather people use it if they aren't gonna use H.264.

[cogman]

OO, I just thought of one.

there is no x264 codec. It doesn't exist. There is an encoder called x264, and it encodes files to the H.264 standard, not the x264 standard. (unless the x264 authors really want to break compatibility, but I don't think they do that.)

Another one that I see, mostly on TV. If you have a garbage video stream, no amount of sharpening, dithering, debanding, denoising, ect is going to create details that aren't there. So quit trying to fix something that is irrevocably broken. Sure you can make an image look cleaner, but you can never restore it to its original form.

[CruNcher]

But Golgot the Marketshare war isn't over yet just wait and see :P sure for the traditional Broadcast you talking about Microsoft lost and they know that (their IPTV isn't running very well lot of problems also), Microsoft now goes into war with SVC (though with just a workaround that is chunked delivery) and on the other side secures themselves again (like they did many times before) and presenting a better way to utilize it believe me Microsoft was never dumb and they always win one way or another even if the lose 1 area they get used in another, so they will also provide solutions for SVC via Silverlight but first they gonna try to conquer as many people as possible with SmootHD.

[Golgot13]

VC-1 isn't too bad

I'm agree (see my old post).
VC1, to my mind, can be use with system with low CPU/GPU because it need
at low resolution less power of CPU. But the market change and many solutions
(CPU, GPU, video chipset decoder) integrate H264 codec, so the cheap solution can have
access at HD video with H264 codec.


I hope to see some nice solution from MS (eg: on SilverLight) with H264 codec.
Why => because I don't like when there is only one solution on market (branch of market)
and today I'm little afraid by Flash from Adobe...

[RadicalEd]

"MP4/AAC/H.264 was created by Apple"
"MP4/AAC/H.264 is proprietary"
The usual stuff about containers vs. codecs.

Former two make me rage the most.

[Sagekilla]

Also, don't forget to mention H.264 should never ever be put into an avi container.

[viper_room]

And ...
Did you read some test report from ISO/CEI MPEG ?
=> MS contribution on H264 codec is very low.


Yes but the contribution from Gary Sullivan has been huge... Actually one can say that the only involvement of MS in H.264 is MrSullivan's salary!


Totally okay about containers (I've mostly heard confusion with mkv) and the difference between H.264 and x.264.

That it is not equivalent to HDTV or HD and it does not contain audio.

Also that H.264 normalizes the decoding and not encoding so no official encoding parameters, no official quantization matrices, no official rate control...

At last that its concepts are absolutely not revolutionnary concerning video compression, it's not a breakthrough. The enhancement are mostly computing ones, not algorithmic.

[Sagekilla]

It's not strictly "no official encoding parameters." The rate control and things related to how bits are distributed (I.e. RDO, MV search algos, block comparisons, etc) are up to the encoder to decide. But on the basic level, there's quite a few features defined that are fixed and not up to encoder to decide whether to implement (CABAC vs CAVLC, use of multiple refs, deblock, multiple partition sizes, 8x8 dct, etc).

IMO, it's more like H.264 defines a set of transformation tools to use on video, whereas any individual encoder can choose how to distribute bits when it's making use of the tools.

[nurbs]

Also that H.264 normalizes the decoding and not encoding so no official encoding parameters, no official quantization matrices, no official rate control...
Same as most (all?) other video codecs. As long as it can be decoded why would it matter how it was encoded. I think such restrictions would be ignored anyway if they can be changed producing a better quality then the official encoder while still being compatible with every decoder.