Pros and Cons of AVC

[john_jk]

Its really great info. i was just wondering what is the pros & cons of H.264 (MPEG-4 AVC) codecs? apart from its excellent quality!

[czerro]

Its really great info. i was just wondering what is the pros & cons of H.264 (MPEG-4 AVC) codecs? apart from its excellent quality!

PROs:
Better Quality at lower bitrates
Better Compression
More Flexibility (everything from B-frames, to even the number of B-frame references, to CABAC etc).
AVC is BLUray compliant (will play on future players) YET makes much more sense than MPEG-2 as an archival format.

CONs:
More hardware overhead
Longer encoding time
Constantly updated
Not all implementations provided by standard are available in encoding/decoding software.
Bare minimum implementations provided by standard are available in hardware players.

In the end AVC is going to continue to develop AND BLUray(h264 compliant) is clearly the portable media storage medium of the next decade. AVC essentially provides the flexibility compressability of XVID/DIVX implementations and the hardware compliancy of MPEG-2 all in one.

[Dark Shikari]

More hardware overheadThan what? Unlike all previous MPEG standards, H.264 can be implemented entirely using 16-bit math, making it ideal for hardware implementations.Longer encoding timeThan what? Again, entirely implementation-dependent.Constantly updatedThe standard has had almost no revisions or additions; compare to H.263 which had so many that they exhausted all the Annex letters up to Z.Not all implementations provided by standard are available in encoding/decoding software.As is the case with nearly all formats, especially MPEG-4 Part 2 (facial modelling?! object coding?!)

While there are downsides to H.264, all of the ones you listed are quite debatable ;) OK, so maybe in some cases I'm nitpicking :p

[czerro]

You say hardware overhead and encoding time are entirely implementation-dependent, which is fair enough. I'm not sure that it is entirely realistic though that anyone would want to use a very basic AVC implementation which has absolutely no benefits over MPEG-2 encoding. In order to reap the full benefits of the standard, overhead and encoding time are things to consider. These are very mild cons, I simply wanted to be fair to the poster who asked for enumerated pro/con s.

Also, I wasn't exactly referring to updates to the standard, but rather updates to encoding software and their abilities to make use of everything covered by the standard.

"As is the case with nearly all formats, especially MPEG-4 Part 2 (facial modelling?! object coding?!)"

To which I would respond the same: essentially the format has not yet matured.

I would agree that the con's listed are minor.

[Guest]

I've moved this out of the info thread as it is OT.

[akupenguin]

I'm not sure that it is entirely realistic though that anyone would want to use a very basic AVC implementation which has absolutely no benefits over MPEG-2 encoding.
Of course. Who would continue using a very basic AVC implementation when you could use a better AVC implementation?
But if you want a comparison: Stripped down AVC still has HCT (faster than DCT), adaptive transform size (significant quality gain, free to decode, fast to encode), and better entropy coding (even with CAVLC). MPEG2 has faster motion compensation (bilinear vs 6tap).

Also, I wasn't exactly referring to updates to the standard, but rather updates to encoding software and their abilities to make use of everything covered by the standard.
Has no impact on their current states; you can always choose not to update very often. And surely knowing that H264 will be even more improved in the future isn't a drawback?!

(facial modelling?! object coding?!) To which I would respond the same: essentially the format has not yet matured.
If I expected the situation to change with time, I'd agree. But features that aren't implemented because no one wants them aren't a lack of maturity, they're misguided design of the standard.

[Selur]

another (temporal?) con would be the lack of good AVC editing tools (repair tools like projectX, pvastrumento, frame accurate cutting (with smart rendering and) with preview), I know it's not a con of the format itself but it's a bummer ;)

[Episodio1]

akupenguin, if u were in a new-codec committe, what specs would u add and what wouldn't u adopt from previous standards?

[akupenguin]

If I were designing a codec now out of ideas that are known to work, it would be mpeg-like with most of h264's features, but the following changes:
Drop:
* interlacing (it just needs to die already)
* small inter partitions (4x4 isn't good for anything outside a few special cases, and it costs significant decoder speed merely to support it)
* temporal direct (spatial is just better)
* biweighted prediction (pyramid essentially replaces it)
* a bunch of header complexity (we don't need 3 poc types, both poc and frame_num, startcode emulation prevention, ...)
* all of baseline and extended profile
* SVC
* slices
* non-nested profiles/levels (there must be some setting in which all syntactically possible combinations of features and all numerical values are valid.)
Some of the above are not universally useless, just not related to any compression domain I care about.
Add:
* more finegrained (sub-mb) control over transform size, intra prediction (mix sizes, mix with inter), aq
* cabrc instead of cabac (faster on cpu, slower on asic... I'll take the cpu)
* custom huffman tables / cabrc contexts (directly improves compression, and also allows for more contexts)
* variable mc filters
* paeth for lossless (lossless can be improved in several other more invasive ways; I'm not sure it's even worth trying to put it in the same codec)
There are of course also ideas that are promising but haven't been proven yet, and so aren't on the list even though I would try them. Don't add things to the standard without a usable implementation (and JM doesn't count as usable).

[Dark Shikari]

Add:
* more finegrained (sub-mb) control over transform size, intra prediction size, aq
* cabrc instead of cabac (faster on cpu, slower on asic... I'll take the cpu)
* custom huffman tables / cabrc contexts (directly improves compression, and also allows for more contexts)
* variable mc filters
* paeth for lossless (lossless can be improved in several other more invasive ways; I'm not sure it's even worth trying to put it in the same codec)
There are of course also ideas that are promising but haven't been proven yet, and so aren't on the list even though I would try them. Don't add things to the standard without a usable implementation (and JM doesn't count as usable).Other things to add:

Snow-style MV prediction (intra blocks are assumed to have an MV equal to their predicted MV).
Recursive transform size (16x16 down to as far as 2x2, decided per-partition).
Replace unary(2 * abs(n) + sign) coding of delta QP with unary(abs(n)) and a separate context for sign.
For CABAC bypass, actually write the bit to the bitstream *right then and there* bypassing the entire coder, not just the state table; this probably would speed up decoding of bypasses.
Larger CAB(A|R)C state table.
Maybe allow delta-deblock per-MB in addition to delta QP?
VC1-style weighted motion compensation (multiply all pixels by a constant factor).

[Inventive Software]

What's CABRC? Context-adaptive binary r****** coding... is the r****** run-length?

Oh, one more thing to drop: the strength of the in-loop deblocker, and allow weak post-processing, a la VC-1.

[Dark Shikari]

What's CABRC? Context-adaptive binary r****** coding... is the r****** run-length?Range.
Oh, one more thing to drop: the strength of the in-loop deblocker, and allow weak post-processing, a la VC-1.Strength of the inloop deblocker is adjustable already.

Postprocessing is always allowed, and should probably not be mandated by the standard.

[Golgot13]

another (temporal?) con would be the lack of good AVC editing tools (repair tools like projectX, pvastrumento, frame accurate cutting (with smart rendering and) with preview), I know it's not a con of the format itself but it's a bummer ;)

Not true,there is AVS editing tools since 2005 (I saw at NAB2005), from KDDi Labs:
http://mmm.kddilabs.jp/en/mpeg/mpro/20/index.html

And it's compatible with High Profil of AVC format since summer 2005.
There is two others software (one available on market from Australian compagny
and another not available from French company...).


Last "SVC" format, it's a big advantage for AVC and it's work on IP broadcast system (I saw a nice demo).

[Manao]

* temporal direct (spatial is just better)PSNR-wise, definitely. Visually, I disagree, temporal - when usable - is better. It needs however to be generalized, because it's unusable in some cases.
* biweighted prediction (pyramid essentially replaces it)I disagree. Uneven pyramids do happen, and I wouldn't want to force only 1, 3, 7, ... bframes in a row in order to emulate biweights.
VC1-style weighted motion compensation (multiply all pixels by a constant factor).Isn't weighted prediction in h264 already better than that ?

I would add sub-macroblock delta quantizer, provided delta quantizer are properly coded. And I would keep interlacing, not because I like it, but because it's a (sad) reality of the video world, which implies that ignoring it would doom the codec.

[Dark Shikari]

Isn't weighted prediction in h264 already better than that ?Its per-frame instead of per-macroblock. The latter is easier to implement in an encoder and more versatile.

[Ranguvar]

PSNR-wise, definitely. Visually, I disagree, temporal - when usable - is better. It needs however to be generalized, because it's unusable in some cases.
But when --direct auto is used, I find that with at least DVD film sources, spatial is used over 90% of the time. If temporal is indeed better visually, why is auto recommended for 2-pass?

[Dark Shikari]

But when --direct auto is used, I find that with at least DVD film sources, spatial is used over 90% of the time. If temporal is indeed better visually, why is auto recommended for 2-pass?Auto picks solely based on the number of skipped macroblocks, not visually.

Also, if I remember correctly, with psy RDO that temporal tends to be picked more often if psy RDO is used on the first pass.

[Manao]

For two reasons I guess :
- visually is a subjective notion. What pleases me might not please aku/DS. Furthermore, I tend to work at high quantizer (>30), it may be different at lower quantizers.
- forced temporal and pyramidal bframes don't work well together (due to the inner working of temporal, thus my remark over its need of reworking)

[cogman]

Pros
- Very efficient compression. one of the most efficient on the market.
- fairly flexible standard. Provides many options to tweak to your hearts content.
- the open source implementation of it is the most advanced one available.


Cons
- if you max out the settings not everything can play it.
- There aren't a huge amount of DVD players ect that support decoding the full standard. (IE something above baseline)
- The open source decoder is vastly single threaded :(
- Not much more that I can think of. Overall it is a great standard, I wish that DivX would just die already so that H.264 can take its rightful place as king.

[pcat]

If I were designing a codec now out of ideas that are known to work, it would be mpeg-like with most of h264's features, but the following changes:
Drop:
* interlacing (it just needs to die already)


Why?
I would agree assuming that capture and playback devices would support 50 or 60 fps progressive, but it does not seem the case.
And 25/30 fps is too slow for some contents...

[shae]

A con I've encountered, with my limited experience, is blur (but generally not detail loss). It seemed more difficult to get sharpness without a lot of tweaking.


Drop:
* interlacing (it just needs to die already)


Why?
I would agree assuming that capture and playback devices would support 50 or 60 fps progressive, but it does not seem the case. And 25/30 fps is too slow for some contents...

Going to 50/60 FPS progressive instead of keeping interlaced seems better. Particularly with the transition to HDTV and BluRay underway.

Interlaced could use legacy formats if needed.


* cabrc instead of cabac (faster on cpu, slower on asic... I'll take the cpu)

Isn't range coding practically the same?

More hardware overheadThan what? Unlike all previous MPEG standards, H.264 can be implemented entirely using 16-bit math, making it ideal for hardware implementations.

Longer encoding timeThan what? Again, entirely implementation-dependent.
And UHARC is faster on Core 2 than RLE on an XT (well, maybe).

[akupenguin]

Isn't range coding practically the same?
* Renormalizes less often (once per byte instead of per bit).
* Doesn't have to pretend not to have read the other bits in the byte.
* Uses a multiply instead of a table (directly faster and less cache pressure).

[keanu13]

Wrf to original post: pros and cons of MPEG 4 AVC codec i found a good detail here:

Pros & Cons of Video Codecs (http://video-codecs.blogspot.com/)

[nm]

Some of the points in that post were a bit outdated or just wrong:
H.261
* H.261 is CPU intensive, so data rates higher than 50 KBps may bog down most machines.
* It may not play well on lower-end machines.

[...]

H.264 / MPEG-4 AVC
* It is certainly not constricted and low-bandwidth friendly

[...]

MPEG-1
The biggest problem with MPEG is that it has high requirements for playback. Either a dedicated MPEG decoder card must be installed, or a high-end CPU is required for software-only playback. Because of this limitation, MPEG-1 has not gained wide acceptance in consumer titles.

Pros
* Excellent image quality

Cons
* Very high playback requirements
* Majority of installed base not capable of viewing MPEG

[and so on]

Oh, that brought back warm memories from the 90s :)

[smok3]

Wrf to original post: pros and cons of MPEG 4 AVC codec i found a good detail here:

Pros & Cons of Video Codecs (http://video-codecs.blogspot.com/)

this is some really unusual mix of past with today, not recommended reading, unless you think apple G3 is top-specs machine... (or if you want to convince somebody that mpeg2 will usually take more cpu than h.264)

[Dark Shikari]

Wrf to original post: pros and cons of MPEG 4 AVC codec i found a good detail here:

Pros & Cons of Video Codecs (http://video-codecs.blogspot.com/)Oh wow, that was pretty hilarious. :p

[Blue_MiSfit]

Yeah... the author needs to read up!!!

Sorenson is dead (thank GOD!), RealVideo is dead, Flash is the web standard - be it H.263, VP6, or H.264, and H.264 is the new MPEG-2.

:rolleyes:
~MiSfiit

[audyovydeo]

H.264 is the new MPEG-2.

:rolleyes:
~MiSfiit

*will* be, some years from now (my guess is > 4 years)

audyovydeo

[Blue_MiSfit]

Ah cmon - where is MPEG-2 still the standard? For ATSC broadcasting, and for studio deliveries.

H.264 is in every other consumer format, is broadcast on cable and satellite, and is on every new optical disc (okay VC-1 too).

~MiSfit

[clsid]

Regular DVDs are still far more popular than Bluray. So MPEG-2 is certainly more widespread for the time being.

[Blue_MiSfit]

Point taken :)

~MiSfit

[LoRd_MuldeR]

DVB-S is still broadcasting MPEG-2 in most cases. You need special DVB-S2 Hardware to see H.264, which most people still don't have...