x264 development

[*.mp4 guy]

To be fair X264 does have trouble with b direct at times even with the standard matrix (though I haven't had any trouble in this reguard in a long time, so it may have been fixed). I'm also not sure that the problems are completely related to quality/qp, I think X264 may have trouble with cqm's that have a low dc coeficient even if they are similar in quality/qp to the flat matrix(just a guess though). I probably should mention that I have nothing against Bframes, or space saving features, I always use bframes in Xvid and X264, and whenevere possible I use B direct.

B Direct usualy only has trouble on smooth low contrast sources like the new starwars movies and you need a good crt (or any lcd with high contrast) to notice the problems, since they usually manifest as jittery flat blocks in almost flat areas.

As to matrices usefulness, all I have to say to that is banding, and low level detail loss (I don't care about noise loss personally). The flat matrix just isn't good at preventing banding and its reliance on inloop filtering to remove blocks removes small details aswell, though it preserves high frequencies amazingly well. Until the flat matrix stops banding and stops needing high inloop settings to have normal blocking levels (which might happen) matrices will be usefull to people who dislike banding and the "washed out" look inloop can cause more then ringing and slight blurring of prominent details.

I would like to have band free encodes with the standard matrix, but right now it isn't happening and cqm's are the best solution I'm aware of.

[*.mp4 guy]

Update: here is an example
This example is a lot more blatant then usual, the clouds in the beginning really seam to throw something off, though there are some (much less obvious) artifacts in other parts of the clip.

heres the matrix used:

INTRA4X4_LUMA =
15,6,15,22,
6,7,25,30,
15,25,38,48,
22,30,48,96

INTRA4X4_CHROMAU =
16,6,24,72,
6,8,41,144,
24,41,96,200,
72,144,200,255

INTRA4X4_CHROMAV =
16,6,24,72,
6,8,41,144,
24,41,96,200,
72,144,200,255

INTER4X4_LUMA =
4,11,15,22,
11,11,25,30,
15,25,38,48,
22,30,48,96

INTER4X4_CHROMAU =
5,16,16,16,
16,16,16,56,
16,16,72,96,
16,56,96,128

INTER4X4_CHROMAV =
5,16,16,16,
16,16,16,56,
16,16,72,96,
16,56,96,128

INTRA8X8_LUMA =
24,7,7,12,15,20,21,23
8,9,14,15,18,21,23,21
10,12,15,17,17,21,26,20
14,15,17,17,18,33,30,23
15,17,17,21,26,39,39,29
18,18,20,24,33,39,41,35
21,24,29,34,39,45,45,38
27,35,36,39,38,38,38,38

INTER8X8_LUMA =
6,10,13,13,15,16,18,22
10,10,12,15,15,16,21,24
13,12,15,16,19,21,25,27
13,15,16,21,24,28,30,34
15,15,19,24,30,36,37,40
16,16,21,28,36,42,45,52
18,21,25,30,37,45,55,72
22,24,27,34,40,52,72,96

I was actually trying to make the matrix more "compatible" to x264 by getting it closer to the compressability of the standard matrix... Doesn't seem to have worked. Its not spot on with the standard matrice's compressability, but I don't think it is far enough off to justify these results.

I'm currently making an encode without b predict to see if that fixes the problem as it has for me in the past.

[akupenguin]

also try with and without b-rdo

[*.mp4 guy]

The problem clip used b rdo, when I tested the clip with b predict disabled the problem went away. Right now I am working on getting a lossless file of a subset of the clip to exhibit the same behavior, after that I will test the clip with b predict enabled but without b rdo. I'll update this post when I am done.

[edit]

Quick summary of results
938KB  B-rdo+B=predict enabled: prominent noticible artifacts
1210KB B-rdo disabled, B predict enabled: slight jerkiness of motion in low contrast areas, probably justified by space savings, ie everything is fine
1321KB B-rdo enabled, B predict disabled: everything is fine, however worse quality/space ratio then with b prediction enabled and b-rdo disabled

Here is a link with everything you need to reproduce the results.

[elguaxo]

I would be interested in doing a similar test like yours, but targeting the same filesize for all combinations. However I can't download anything from megaupload: All download slots assigned to your country (Argentina) are currently in use.

Could you upload the files somewhere else? Thanks!

[*.mp4 guy]

Files uploaded somewhere else.

[elguaxo]

Thanks, the new link works fine!

My eyes are not so fine-tuned like yours, I can spot the artifacts, but it was difficult.

M4G HRM V1.5 is the matrix some posts above?

[*.mp4 guy]

Originally Posted by elguaxo

M4G HRM V1.5 is the matrix some posts above?

Yes, I probably should have more clear on that or included it in the archive to make things easier. I still have to do more testing to see how it compares to the old version, and I have to adjust the 4x4 luma matrices before it will be finnished.

Originally Posted by elguaxo

My eyes are not so fine-tuned like yours, I can spot the artifacts, but it was difficult.

Its probably your monitor, not your eyes that made the problem hard to spot. The monitor I'm using is very unforgiving of artifacts compared to most crts.

[noclip]

I'm not a big fan of x264's logo (the firey one). It makes the best (IMHO) AVC encoder out there look second rate to somebody not well-versed in such things. Here's a slightly cleaner version which, if you want to use it, you can feel free to as it is in the public domain.

[akupenguin]

The firey one is not x264's logo, it's x264.nl's logo. There is no official x264 logo.
Of the logos proposed so far, my favorite is the old vfw icon, though I never saw a large render of it.

[noclip]

Originally Posted by akupenguin

The firey one is not x264's logo, it's x264.nl's logo. There is no official x264 logo.

Ah. Well as I said, public domain, so if you ever feel like you need one...

[bob0r]

The VFW icon is just the same logo noclip posted, but with the 3 colors added.

So making a big render is quite easy.



... i have a whole week all for myself, i was thinking of a new design for x264.nl, but as usual i lack any graphical insight what so ever!

I was thinking a more dark style like:

But this is just fooling around.

[poyupay]

Originally Posted by bob0r

The VFW icon is just the same logo noclip posted, but with the 3 colors added.

yeah right! looks like that:



or maybe like that...:



only drafts though. but if you're interested...

[AGDenton]

Hi,

[631] introduces a few SSE3-optimized functions for the x86_64 branch. I'm on a 386 right now, so I can't test them, but could you provide an estimate of their performance impact?

Also, there seems to be a few processors out there (Yonah, for instance) which support SSE3 but not EM64T : would SSE3 optimizations in the i386 branch be feasible, or benefitial ?

Best regards,

AG

[Manao]

rev631 introduces SSSE3 optimized functions, not SSE3. AFAIK, all SSSE3 processors are 64bits. Still, some people might want to use a 32 bits OS and a SSSE3 version would be appreciated for them.

It would be feasible and benefitial, you just need to find the guy to do it.

[Cef]

Hi,

I made x264 ssse3 builds since i couldn't find any, sharing if anyone interested
http://cef.neuf.fr/x264/x264_x86_r637.7z
http://cef.neuf.fr/x264/x264_x64_r637.7z

[Adub]

Thanks mate!

Yo, Sharktooth!
Are you making builds that support ssse3 as well, or are you sticking with the lesser optimizations?

[ChronoCross]

Originally Posted by Merlin7777

Thanks mate!

Yo, Sharktooth!
Are you making builds that support ssse3 as well, or are you sticking with the lesser optimizations?

ssse3 only works on intel processors.

[Eretria-chan]

Originally Posted by ChronoCross

ssse3 only works on intel processors.

Does it? AMD Athlon 64 X2 supports SSE3. Cpu-Z confirms this. SSE4 is Intel-only for the moment, though, AFAIK.

[Manao]

Electria-chan : SSE4 has been renamed SSSE3. So ChronoCross is right.

ChronoCross: strange, I was getting the impression that SharkTooth was an Intel fanboy