Video Coding Formats tools comparison

[bond]

heya this discussion (a comparison of the video coding tools available in popular formats, like mpeg-2 mpeg-4 aso...) has been started here (http://forum.doom9.org/showthread.php?s=&threadid=84620) and got continued in the mpeg-4 sticky (which i now splitted to an own thread (cant merge the one from general discussion :( )

[SeeMoreDigital]

Here's a "slighly" revised table. Please let me know if more alterations need to be made: -

http://img50.exs.cx/img50/4315/mpeg24avctable7ar.gif


Cheers

[akupenguin]

http://students.washington.edu/lorenm/src/mpeg_features.png

[Gabriel_Bouvigne]

RD optimisations are quite standard independant. As long as a standard allows some coding choices, the implementer can decide to use RDO.

[skal]

hi everybody,

@gabriel: agreed!

@Aku: it seems to me MPEG-2 also allows interlaced coding at macroblock
level, not just frame level.

[edit]: also, you can simulate an (inefficient) lossless mode with H264-main, using I_PCM and no deblocking

-Skal

[bond]

Originally posted by Gabriel_Bouvigne
RD optimisations are quite standard independant. As long as a standard allows some coding choices, the implementer can decide to use RDO. which is what i wrote already :)

[babayaga]

Originally posted by akupenguin
Standard features
Just a remark : the AVC basic transform is not an Hadamard transform but a rounded version of the DCT, see :
http://research.microsoft.com/~malvar/papers/MalvarCSVTJuly03.pdf

Besides, AVC does support interlaced frame and MB (field mode, progressive mode, Picture Adaptive Frame Field (PAFF) and Macroblock Adpative Frame Field (MBAFF).

[Gabriel_Bouvigne]

The H.264 transform is called HCT (High Correlation Transform).
The Hadamard one, as pointed by babayaga, is the second one done mainly on chroma coefs.
A Hadamard transform is only made of +-1 coefs.

[akupenguin]

Originally posted by skal
it seems to me MPEG-2 also allows interlaced coding at macroblock
level, not just frame level. I can't find any such statement in ISO-13818-2_1995.

also, you can simulate an (inefficient) lossless mode with H264-main, using I_PCM and no deblocking That doesn't count. It would be bigger than the uncompressed video.

Just a remark : the AVC basic transform is not an Hadamard transform but a rounded version of the DCT That's what I said at first, but people here corrected me.
"HCT"? Where would one learn that name? Both the standard and JM just call it "the transform".

[Gabriel_Bouvigne]

Where would one learn that name? Both the standard and JM just call it "the transform".
Malvar's papers?

[skal]

@akupenguin:
I can't find any such statement in ISO-13818-2_1995.

frame_motion_type, in section 6.3.16.1.


-Skal

[virus]

Originally posted by akupenguin
That's what I said at first, but people here corrected me.
Yep, and I still think I was right when correcting you. Writing "4x4 DCT" was misleading since a proper DCT uses real coeffs. The main 4x4 trasform in AVC is very similar to Hadamard, while the secondary trasform is exactly Hadamard.

Since a proper Hadamard uses integer coeffs (unlike the DCT), I think it's much more consistent to "relate" the 2 AVC trasforms to Hadamard instead of mixing them up with the DCT.
Besides, at such small size, several block trasforms look similar so you can just call it "a rounded version of <just about everything>" :)

(btw I never heard of the name HCT before - are we sure this name can be called "official"?)

[Gabriel_Bouvigne]

Call it "integer DCT-like" if you want...

I've seen it called HCT several times, and it seems to fit the HCT description quite well. Anyway, it's better than calling it "THE transform".

[SeeMoreDigital]

In an effort to keep the "information chart" all about MPEG. How about adding detals about Mpeg1?


Cheers

[bond]

i would love to see vc-1 added :)

[SeeMoreDigital]

By taking some the information provided by akupenguin, I've amended my old chart. Which now looks like this: -

http://img115.exs.cx/img115/2127/smdcodectable6ef.gif

As you can see it simply concentrates on "Main MPEG Standards".


Cheers

[akupenguin]

You still have rate distortion optimization in the chart, and it still doesn't belong.
MPEG-1 does not support interlacing at all.
MPEG-2 and MPEG-4 support both PAFF and MBAFF. H.264's are better (they certainly spend lots of space describing how to scale MVs and timecodes and interpolate back and forth), but it's a refinement, not a new feature.
"Pixel Motion Prediction" <-- that row is "motion precision". Motion prediction was also improved in H.264, but it's a completely different issue.
If you're going to list custom quant matrix under H.264, you should probably add the other High Profile features as well.
"Advanced Macroblock IE" <-- whenever I see "advanced" on a list of features, I immediately want to strangle the author for not explaining what's so much better about it. (The names "AVC" and "AAC" are not excluded from this.)

[SeeMoreDigital]

Before I amend my list, can you confirm the following - for some of us "less tech types"....

You still have rate distortion optimization in the chart, and it still doesn't belong.Does RDO go by a different name(s)?

MPEG-1 does not support interlacing at all.I'm sure there were some companies tinkering around with the idea. In fact I think I have a sample of an interlaced Mpeg1 video stream, somewhere in my collection... but agreed, it's unavailable and looks never likely to be so!

"Pixel Motion Prediction" <-- that row is "motion precision". Motion prediction was also improved in H.264, but it's a completely different issue.Yep, sorry my mistake. But what exactly does the abbreviation "PEL" stand for?

If you're going to list custom quant matrix under H.264, you should probably add the other High Profile features as well.I guess the list could keep getting longer and longer. Maybe it should be divided, showing "Simple Profile" features at the top and "Advanced Simple Profile" features at the bottom. What do you think?

"Advanced Macroblock IE" <-- whenever I see "advanced" on a list of features, I immediately want to strangle the author for not explaining what's so much better about it. (The names "AVC" and "AAC" are not excluded from this.)Sadly it's a "term" that's here to stay... but I know what you mean!


Cheers

[Tommy Carrot]

Originally posted by SeeMoreDigital

Does RDO go by a different name(s)?
RDO is not a feature in the standard , it means that as long as a standard allows some coding choices, the encoder is able to make smart decisions about what choice should it use for the best PSNR (and hopefully for best visual quality).
Yep, sorry my mistake. But what exactly does the abbreviation "PEL" stand for?

'pel' is the short form of 'pixel' afaik.

[stephanV]

Originally posted by SeeMoreDigital
Does RDO go by a different name(s)?

RDO is not a feature of the standard; it should be completely left out. You could apply RDO to virtually any codec without having to change the standard.


Yep, sorry my mistake. But what exactly does the abbreviation "PEL" stand for?
I thought it was just short for pixel... after all, "QPEL" is "quarter pixel"


Sadly it's a "term" that's here to stay... but I know what you mean!


:)

[edit]Tommy Carrot was first :)

[SeeMoreDigital]

Why thanks guys... It's little things like this that need clearing up from time to time!

Now... Although various other web sites have got them. Who feels like creating a cross referenced A-Z of various audio and video terminologies, expressions and abbreviations for use on Doom9!

I think it might prove very useful.


Cheers

[bond]

i now added akupenguin's (thanks a lot!) comparison to the mpeg-4 sticky (removed h.263+, as i think its not really used nor discussed on doom9, and added vc-1, well sort of ;) )

have a look:
http://www.8ung.at/bond/comparison.gif

feel free to have a look at it and flame me :D

would be nice if someone could help me complete the vc-1 part
also it would be nice if someone could tell me what yuv formats are supported in the formats

thanks a lot! :)

[babayaga]

Originally posted by bond
feel free to have a look at it and flame me :D

The colorspace input/output format of AVC Main Profile is only 4.2.0 8 bits per component.

There is something odd about motion search precision : generally speaking there is a maximum accuracy but the encoder does not have to use it and whenever there is an accuracy of 1/4 pixel, 1/2 pixel is also available (1/3 pel does not exist anymore :-). So you could write for instance for ASP and AVC : "down to 1/4 pel" or "down to 1/2 pixel" for MPEG-1 et and MPEG-2.

Switching pictures (I think you're refering to SI/SP frames in AVC) is not a tool of the Main Profile or one of the High Profiles.

[bond]

Originally posted by babayaga
The colorspace input/output format of AVC Main Profile is only 4.2.0 8 bits per component.thx :)

There is something odd about motion search precision : generally speaking there is a maximum accuracy but the encoder does not have to use it and whenever there is an accuracy of 1/4 pixel, 1/2 pixel is also available (1/3 pel does not exist anymore :-). So you could write for instance for ASP and AVC : "down to 1/4 pel" or "down to 1/2 pixel" for MPEG-1 et and MPEG-2.hm ic, but still the info gets stored in the bitstream like qpel, even if only hpel is done with avc right?
whereas in asp there is a difference between hpel and qpel regarding this

Switching pictures (I think you're refering to SI/SP frames in AVC) is not a tool of the Main Profile or one of the High Profiles. indeed, thx

[akupenguin]

Originally posted by bond
also it would be nice if someone could tell me what yuv formats are supported in the formats
MPEG-1: 4:2:0
MPEG-2: 4:2:0, 4:2:2, 4:4:4
H.264 Main: 4:2:0
VC-1: 4:2:0
Snow: 4:2:0, 4:0:0
(Of course, any of them can efficiently encode grayscale, since empty chroma planes compress very well. But only H.264 high profile and Snow explicitly support 4:0:0.)

[bond]

thx :)

what about intra prediction of mpeg-1/2? is it not known or?

[akupenguin]

MPEG-1/2 have no intra prediction. Each intra macroblock is coded independently.

[akupenguin]

VC-1:
Entropy coding: Huffman + Bitplane. (Bitplane is used for header data, like mbskip and 4mv, Huffman for larger data like MVs and residuals.)
Spatial transform: 1-D 8-point or 1-D 4-point. (Which together form 8x8, 8x4, 4x8, and 4x4 transforms.)
Weighted prediction: postprocessing only. VC-1 doesn't have weighted prediction in the same sense as H.264, it can only scale a whole picture after decoding it.
Slices: yes
OBMC: no
GMC: no
Lossless: no
Custom quant: no
Multiple ref frames: no

[bond]

thanks a lot, updated the comparison :)

[hworldjj]

Originally posted by akupenguin
MPEG-1/2 have no intra prediction. Each intra macroblock is coded independently.

With MPEG-1/2, in one slice, DC of the current intra 8x8 block is substracted by DC of the previous one, and then the error is coded. It's ture there isn't intra AC prediction.

[akupenguin]

Originally posted by hworldjj
With MPEG-1/2, in one slice, DC of the current intra 8x8 block is substracted by DC of the previous one, and then the error is coded. It's ture there isn't intra AC prediction. I stand corrected. Yes, MPEG-1/2 should say "DC 8x8". (not quite the same as Theora's prediction, but close enough for our chart.)

Also, I think Snow should get a "N/A" instead of a blank in the "deblocking filter" row: Snow doesn't need to be deblocked, as opposed to MPEG-1/2/4 which benefit from a postprocessor.

[hworldjj]

Does anyone know the detail about RealVideo10 and VP6.2? Maybe we can also put them into the comparison.:p

[bond]

updated