H.264 status and definition

[Neo Neko]

Wow X264 is already quite good! And it is barely in it's first few working releases! If this project keeps getting work I think the next codec comparison could be a shutout! I wonder if it was incorporated into/with Xvid if that would help.

A fun little NTSC sample (http://neoneko.ath.cx/hs.mkv) for you all to play with.

[Blue_MiSfit]

holy god thats amazing... no macroblocking at less than 300 kbit full (cropped) res.

I'm scared.

What I DONT like about it is the (over) smoothing, and this wierd almost shimmering effect. However, it doesnt appear to be tied to lots of motion.

I am really imressed with the lack of haloing/blocking usually associated with low bitrate at high resolution with lots of motion.

Cant wait until h264 gets to a point where I can start using it for my backups :D

peace
~misfit

[unmei]

wowie!
thanks neo neko, your sample soo dragged me to the h.264 side. I still don't know what was the problem with me and the vanguard h.264 or that other command line encoder, but with the ffdshow h.264 encoder i finally can encode "good" samples in h.264 as well.

I don't doubt it any longer, h.264 will reach world domination. It seems to me the code by ffmpeg team is worlds apart from what the commercial ones can show - GOOD, that warms my Xvid spoiled heart.

[SeeMoreDigital]

Yep, all we need now is to see some H.264 streams in an MP4 container instead of AVI :D


Cheers

[unmei]

hmm i always thought the *.mkv extension were used for matroska files :p
But i know that is not what you meant, you want to see it it's native container..

[Sagittaire]

For H264 ffvfw tester

the best quality for you (not for speed) ...
- Best ffdshow version?
- Best H264 setting?
- Best decodeur for H264 ffvfw?

thx

[unmei]

@sagittaire
eeeek! "best"!?!
and what's with the question? does the latest ffdshow not run on your machine or do you have any other reason to think a older version could be better?

About the settings i'm unsure ..just had to experience ticking all the analyser checkboxes is no good idea, it gave hell of a block storm, so i left it at default for the following tests. Beside that, there is not so much settings to choose from. I always used cabac so i don't know how the other method would perform. For in-loop, it sometimes turned it sometimes off but i did not investigate the effect directly and there was no effect that would immediately jump at me without testing that explicitely. The max reference frames setting can savely be turned up to about 10, but i did not see a drastic increase in quality - like in-loop i did no direct tests to see its effect.
I mainly tried a bit to see what the encodes look at different quantisers and what the resulting bitrate was compared to the produced quality.

[aketon]

Hello!

Is there any site that has a compiled version of the x264 codec??? I don't want ffdshow in my machine because it has a loooots of settings to configure! What I really want is a simple directshow codec! The only one I found so far is from this site http://www.geocities.com/justinclaybaby/x264.htm ! Is it safe to use it? I read somewhere in the previous posts that it isn't as fast as the ffdshow!

Thanks for reading my post!

Sorry for my bad english! (I hope that there isn't too many mistakes)

BYE

[Tommy Carrot]

@Sagittaire: Yes, the latest (version) is the greatest. :D
In-loop filtering makes the codec behaving like RealVideo: no artifacts but smooth and blurry image. Imo it will be good for low bitrate encodings, but not for normal dvd-rips and high quality encodings.
I would recommend using CABAC (cca. 10% bitrate gain without any quality loss), and every analizer flag except inter PSUB8x8 (which cannot be decoded properly yet due to a bug in libavcodec).

[Tommy Carrot]

Originally posted by aketon
Hello!

Is there any site that has a compiled version of the x264 codec??? I don't want ffdshow in my machine because it has a loooots of settings to configure! What I really want is a simple directshow codec! The only one I found so far is from this site http://www.geocities.com/justinclaybaby/x264.htm ! Is it safe to use it? I read somewhere in the previous posts that it isn't as fast as the ffdshow!


It's much slower and not configurable at all, only works with the default settings (loop filter on, constant quant 26, etc).

edit: I just saw that there are newer versions since the one i tried, so perhaps the mentioned issues are not valid anymore.

[unmei]

currently watching:
El-Hazard ep 23
container mkv
subtitles ssa
audio HE-AAC 48kHz stereo 32kbit/s
video 688x544 ("anamporph" 4:3 by mkv), 25fps FFDshow h.264 (x264?)

h.264 settings
Q18, cabac, no in-loop, default analyser flags, 10 reference frames
encoding time 107 min on athlon XP 2600+ (heavy avisynth script)
resulting bitrate 576kbit/s

total filesize: 83.8 MB (for 19:04!)

almost plays on pentium 3 /600
uses 50% CPU on said Athlon (a Xvid with heavy B-frame/ASP stuff uses ca 35%)

Quality: i would already prefer it over a Xvid or RV encode at the same low bitrate. The pencil strokes are a bit fuzzy especially on the chin (or just places where there is a black stroke with same color on both sides). Also there some smearing/blocks/general unsharpness on the sky. It's probably known to everyone but me, anyway, it seems there is not frame-type decision at all - at least it seemed to me I frames were only inserted after the max distance was reached.

http://www.hta-bi.bfh.ch/~seilf/x264.blocksky.jpg
PNG (315kb) (http://www.hta-bi.bfh.ch/~seilf/x264.blocksky.png)

[Sagittaire]

For low bitrate inloop is an obligatory option: it's an in loop deblocker during encoding.

inloop and H264 for low bitrate it's like SBR and AAC for low bitrate ... it's obligatory. For exemple RV10 in 2 pass use Inloop quant threshold ... ;-)

[unmei]

In-loop filtering makes the codec behaving like RealVideo: no artifacts but smooth and blurry image.

So either this inloop filtering has to become much better, or it's no option for me. Even with this frame to illustrate the annoying blocks in the sky - i prefer it by far over the RealVideo characteristics.

PS:
with same comp, same h.264 settings, but just TomsMoComp and Crop in the avisynth script encoding reaches +/- 9 fps (53min compared to the 107 with all the filters used above)

[Tommy Carrot]

I've tried Justin's latest build, and the problems i mentioned before are mostly fixed, its speed, quality and functionality are similar to the ffdshow encoder, so if someone doesn't want to mess with ffdshow, he can use this standalone build instead.

[avih]

tommy, iirc, i couldn't decode .264 clips with it (u might wanna mess with the fourcc though)

[Tommy Carrot]

Originally posted by avih
tommy, iirc, i couldn't decode .264 clips with it (u might wanna mess with the fourcc though)

Yupp, i forgot to mention that you have to set the fourcc to 'h264' in the advanced tab to play it back with ffdshow.

[aketon]

After some tests I made, it seems that ffdshow has a better x264 codec than the one in the http://www.geocities.com/justinclaybaby/x264.htm ! I can 't understand why they have such a big difference in guality! Ffdshow encodes in lower bitrate it still has better quality than the other one! I encoded 1 minute of the same clip and ffdsow gave me 2 megs and the other one gave me 4.5 megs! Ffdshow created a clip 2.5 megs smaller and it still had much better quality! The other one had to many blocks moving like crazy!
Does anybody knows why did this thing happened???

[708145]

[ffdshow-x264 looks better than x264] The other one had to many blocks moving like crazy! Does anybody knows why did this thing happened???

I tested both codecs as well. Make sure to use the same options for both regarding in-loop filtering.
Also for play back, I had to convert to huff-yuv first since hi-bitrate playback of h264 was not possible on my axp1800.-(
but I guess this lost me some post processing :confused:

I'll put those clips online soon.

T0B1A5

[bond]

Originally posted by avih
tommy, iirc, i couldn't decode .264 clips with it (u might wanna mess with the fourcc though)hm, .264 are raw bitstreams, better not use this expression for h.264 streams placed in a container :)

raw bitstreams can be played using the mainconcept and moonlight filterset btw...

[aketon]

Can anyone please give a short explanation about the ffdshow's x264 options? Especially for what exactly are "CABAC" and "Max. number of reference frames"!!

Thanks!
BYE

[708145]

My shot:

CABAC: Huffman replacement using arithmetic coding. More expensive but also smaller bitstream (~10% according to some posts). I never tried without.

Max no ref frames: Each predicted frame can use data from up to this specified no. of frames. higher no. increases memory footprint of encoder and decoder, but should help compression. For comparison:
In MPEG4ASP it is 1 for p_frames and 2 for b_frames. I used values from 3 to 5. But will experiment with higher numbers soon.

bis besser,
T0B1A5

[708145]

Here is the location of some of my codec experiments.
Very slow motion scenes from phenonemon encoded with different codecs, resolutions, bitrates... well filenames speak for themselves.

http://www.ra.informatik.uni-stuttgart.de/~bergmats/clips/

bis besser,
T0B1A5

[aketon]

Thanks for the info 708145!!!

BYE

[Sagittaire]

little H264 ffdshow test:

Don't use H264 ffdshow decodeur: decodeur is incomplete. Use VSS decodeur

ffdshow-20040520

http://jfl1974.free.fr/Video/ffdshow-20040520.jpg

quant 15 without inloop (http://jfl1974.free.fr/Video/H264-ffdshow-20040520-cabac.avi): 4866 Ko

quant 15 with inloop (http://jfl1974.free.fr/Video/H264-ffdshow-20040520-cabac-inloop.avi): 4818 Ko


ffdshow-20040508

http://jfl1974.free.fr/Video/ffdshow-20040508.jpg

quant 15 without inloop (http://jfl1974.free.fr/Video/H264-ffdshow-20040508-cabac.avi): 4654 Ko

quant 15 with inloop (http://jfl1974.free.fr/Video/H264-ffdshow-20040508-cabac-inloop.avi): 4614 Ko

In lastest ffvfw version only the functions correctly decoded by ffdshow are available. H264 q15 size is comparable with XviD q4 or compressibility 50% ...

[SeeMoreDigital]

Hi Sagittaire,

There's no doubt that the encodes you've generated with ffdshow-20040520 look very good indeed.

That said, how much success have you had using lower bitrates, ie: below 700kbps?


Hi 708145,

I downloaded a couple of your encodes, including your 14.9MB clip. However, after a minute or so, it crashes all the media players I tried.


Cheers

[aketon]

Hello Sagittaire! You have very interesting clips (about quality) there! But you've done a mistake when you wrote over the second picture of the h.264 properties 20040520! You should wrote 20040508!

BYE!

[ToiletDuck]

............. Somebody uses windowsXP PLUS!

[708145]

Originally posted by SeeMoreDigital


I downloaded a couple of your encodes, including your 14.9MB clip. However, after a minute or so, it crashes all the media players I tried.



Oh, bad to hear that. :(
But as written above, I couldn't play those high bitrate clips myself directly without artifacts and dropped frames.
So I converted to huffyuv first.
I have to wait for further codec speed improvements for direct playback.


Just checked with 20040520 ffdshow playback -> no crash, no dropped frames BUT several wrong frames! maybe some blocks were skipped?


bis besser,
T0B1A5

[oddball]

Just tried a few test clips. Interesting. Blocking seems to have been changed for stepping or somesuch. Blocks tend to blend into each other. I can definitely still see the artefacts though. It's not as unpleasant as MPEG4 blocking though IMO.

Impressed? Not really. I was expecting more.

[aketon]

Xvid seems to be better than x264 right now! After some tests I've done at 300 kbps on a video with image resolution at 640x336, Xvid was a little bit better! And that was because I used b-frames! Without b-frames x264 is by far much better! I hope that they are going to implement b-frames soon in their codec!


Sorry for my bad english!

BYE!!!!!!

[CruNcher]

gee ffdshows x264 implementation is really neat much better then Vanguards at least, even with no Ratecontroll and b-frames cabac really pushes it, but yeah XviD is still more precise because of it's marvelous RC and B-frames implemantation hopefully we see alot of new enahncements to x264 ahh and their is still Skals codec hopefully to come :)

[Blue_MiSfit]

h264 seems to crumble at the feet of xvid in the following setup:

ffdshow h264 encoder 20040520
all motion comp settings enabled, 15 max ref frames
quant 10

frame 990-2990 lord of the rings return of the king
400x160 resolution (wierd I know)

xvid setup:
256kbit - 2 pass
h263
qpel
gmc
adaptive quant
bvops @ 4/1/1
sensitivity @ 15
chroma motion
chroma optimizer
trellis
vhq=4
msp=6

the file sizes were as follows:
Xvid: 1840 kb
H264: 13346 kb !!

I could (unfortunatley) not get any screenshots due to overlay problems, but I can honestly say that q10 was as high as I could compress it before it began ugly blocking and artifacting.

XviD on the other harnd scaled marvelously, and even looks better than h264

it would indeed appear that there is no rate control yet ;)
looks nice at any rate.

[gino25]

i have red that the new version of videolan has an integrate h264 codec.

Have you tried this?

[Sagittaire]

For Bitrate
quant 12 for H264 ~ quant 2 for XviD or compressibility 100%
quant 13 for H264 ~ quant 3 for XviD or compressibility 75%
quant 15 for H264 ~ quant 4 for XviD or compressibility 50%
quant 18 for H264 ~ quant 8 for XviD or compressibility 25%

quant N for XviD ~ quant N+10 for H264 in [25%-100%] compressibility interval for XviD (with H263 and HVS matrix)

quant for MPEG4 V10 (H264) or RV10 and quant for MPEG4 V2 (XviD or DivX) aren't equivalent ... and use VSS decodeur not H264 ffdshow decodeur

[Tommy Carrot]

Don't forget that the quantizers in the ffdshow are not the real quantizers, because it sets the quantizers in a 31 step slider, but h.264 has 51 separated quantizer value. You can check the real quantizers with the OSD function of the ffdshow. Justin's build sets the real quantizers.

If i remember correctly, the logic behind the h.264 quantizers is: if you increase the quantizer with 5, you'll get about half bitrate. quant+10 gives 1/4, quant+15 gives 1/8 bitrate, etc.

[skal]

Tommy:


actually, the step size is '6'.
Which means that the quality degrades *exponentially*
with QP, btw. And not linearily, like MPEG4.

Here's a (strange) drawing of QP (either MPEG4 or H264) as a
function of PSNR (for two random sequences i don't recall which
ones).

http://skal.planet-d.net/QP.gif


How to use it? Well, say you want a PSNR of 40,
then roughly, following the vertical line, it says
that QP should be 28-30 for h264 and 3-4 for MPEG4.
(no guaranty of course).

Note: Qp=26..30 will be the usual good range for h264.
Note2: you see? The QP=func(PSNR) is linear! That's the
magic taking the log (<=>PSNR) of an exponential ;)

Skal

[SeeMoreDigital]

I would love to know how good H.264 encodes would look under 2pass conditions!


Cheers

[aketon]

For me Justin's x264 seems to be bugged!
For my encodings I use ffdshow for now (as there is not any other codec that works as good as it)!
My options (for now at least) are

Quantizer 16

Generic
--------
Maximum I frame interval 300
Minimum I frame interval 1

CABAC ON
LOOP FILTER OFF


Motion estimation
------------------
Intra analyzer flags:
I4x4 ON
PSUB16x16 ON
PSUB8x8 ON

Inter analyzer flags:
I4x4 ON
PSUB16x16 ON
PSUB8x8 OFF

Max. number of reference frames 10


With these settings I have great quality for any video!

[CruNcher]

http://cruncher.mufflastig.com/XviD/samples/

here you can see what i meant with it's still not upto but as you see their is near no ringing (x264) short transforms this was done with a Q31 with x264 and 2pass 1000 kbps for the XviD b-frames ect :)
Btw both are by factor 5x compressed of the orgiginal (yada) :D took 4 times longer to achive that then the playtime goes but it's worth it ;) ahh and you will also see Noise in the XviD hehe thats source noise JUP that's why it's called Extra_Detail :)

@Skal
hmm what was your expirience with Hadamard ? i see it gives a speed bost in the H264 reference Encoder couldn't it have the same effect for XviD ?

[aketon]

I've just found out that ffdshow was the reason for not playing correctly the video created with Justin's x264 codec! When I tried to play it with VSS decoder, everything went fine! Justin's x264 seems to be a little bit faster also!!!

[Tommy Carrot]

Originally posted by aketon
I've just found out that ffdshow was the reason for not playing correctly the video created with Justin's x264 codec! When I tried to play it with VSS decoder, everything went fine! Justin's x264 seems to be a little bit faster also!!!

This was already mentioned a few times in this thread. Ffdshow cannot decode the clip properly when CABAC and Psub8x8 was used at the same time at encoding. In Justin's build Psub8x8 flag is on defaultly and cannot be switched off.

[slavickas]

Originally posted by gino25
i have red that the new version of videolan has an integrate h264 codec.

Have you tried this?

it's same x264 (because x264 main developer is one of vlc devs)
and public vlc 0.7.2 windows release i think don't have x264 compiled

[SeeMoreDigital]

Originally posted by gino25
i have red that the new version of videolan has an integrate h264 codec.

Have you tried this? Does it come with both an encoder and decoder then?


Cheers

[unmei]

blue misfit wrote
I could (unfortunatley) not get any screenshots due to overlay problems

this is how i did my screenshot:
.AVS file:
DirectShowSource("x264test.mkv")

..and opened that in VDM, shift+1 to save as png.
If there are any quality concerns about this method, please let me know. But else i hope it helps so we can see all the screenshots of interest :)

[virus]

I have a question for those of you who know the specs (I've got the draft for H.264 lying somewhere in my HD but haven't read it yet). Is it allowed to integrate an MPEG-4 Visual (Part 2) codec with H.264 functionalities?
Example: adding CABAC to XviD and produce a codec which uses a mixture of features from both Part 2 and Part 10 (using H.264 bitstream syntax of course).
In other words: is an H.264 bitstream "backward compatible", at least to some extent? The answer should be 'yes', since they're both MPEG-4, but given that H.264 is substantially different from Visual, I'm just wondering if that's the case...

[Sagittaire]

I have a question for those of you who know the specs (I've got the draft for H.264 lying somewhere in my HD but haven't read it yet). Is it allowed to integrate an MPEG-4 Visual (Part 2) codec with H.264 functionalities?
I think it's possible: for exemple MPEG4-ffvfw use inloop ...

produce a codec which uses a mixture of features from both Part 2 and Part 10
use the RV10: I think it's an intermediate codec between the MPEG4 v2 and the MPEG v10 ... ;)

[skal]

Hi Cruncher,


regarding the adequacy of SAD/SSD/HSAD,
there's two problems involved: Are you
using this metric to evaluate distortion?
or rate? Or both, weighted (RD-optim)?

Let's have a look at the easier part: rate.

Let's take a predicted intra block,
evaluate the diff between prediction and
original picture with either SAD/SSD/HSAD.
Then let's quantize this diff, and code
the residual.
Here are some curves showing the length (in
bits) of the coded residuals as a function
of the metric's value (using CAVLC, QP=10):

Using SAD:

http://skal.planet-d.net/sad.gif

Using SSD:

http://skal.planet-d.net/ssd.gif

Using HSAD:

http://skal.planet-d.net/hsad.gif


One can see that the result is pretty
equivalent: the higher the metric's value,
the harder to code. I'd favor the HSAD,
since there's less dispersion in the
expectation of the coded length. The
gaussian is sharper.
But if you are to use HSAD, you'd better
use the real H264's transform which is
close to HSAD.
Here's the function of the residual's
coded length as a function of the sum of
the levels (that is using the real H264
transform instead of SAD):

http://skal.planet-d.net/level.gif

One can see that's it's even better,
and not much costly compared to HSAD
(but more than simply using SAD,
nevertheless).

Now, all this being said, i'd recommend
to tabulate the coded bit length as a
function of SAD for cheap rate evaluation.
It's easy, the curves look like a log
curve, and it's pretty reliable for a
fast rate evaluation.



Now the harder part: what is the relation
between computed SAD and the final distortion
(once fwd transformed, quantized, dequantized,
bwd transformed)?

Well, almost none.

Or at least not much more than the
relationship between:

F(\sum_i x_i/Q) and \sum_i F(x_i/Q)

where F(x) means the fractional part of x.

[ach! this looks like dynamic systems/ergodic
theory!:]


The equality holds mainly if all the x_i are
less than Q/N!

So yes, for high quant, the SAD between
predictions and original picture is a pretty
good measure of the final distortion. This
works perfectly for a SKIP block, e.g. ;)

But otherwise, it's hard to guess what will
the final distortion be, just by looking at
the original SAD/SSD/HSAD/whatever.

bye!
Skal

[shlezman]

@ Skal
Interesting graphs, sadly the conclusions are inconclusive :)
a few quick Questions :
Any results for inter ?
Ever tried a combination of several metrices ? one metric might compensate over the other, producing a smaller variance.

[aketon]

It seems that I had a problem using avs2avi and x264 - H264/AVC codec! Whenever I am trying to encode, it gives me the follow message:
ICSeqCompressFrameStart failed : The operation completed successfully.
Do you know why I have this problem? I thing that it might be a YV12 problem! But as a MPEG4 codec it is supposed to accept YV12! There no problem when I use ffdshow!

BYE!

[skal]

@shlezman:


For inter, it's almost the same except that
you have much more prediction "mode" available
(one for each motion vector + ref +...)

I've got no definite conclusion, but i can
give you some hints:

Using only SAD as metric results in ~0.2 - 0.5 dB
loss compared to real RD-opt evaluation. This is
too much for my taste. But on the other hand, it's
more than 4x faster.

Combining several metrics is an interesting idea,
but the problem still is the same: you have
uncertainty attached the final rate evaluation,
and this can ruin the mode decision, especially
at low bitrate.

Now the top-secret trick is: use SAD to pick up
few candidate prediction modes, suitable for a
real RD-opt measure. Most of the time, doing so,
you rule out many bad modes. Combined with good
thresholding, speed-up can be consequent.

bye!
Skal