x264 compilation

[Kostarum Rex Persia]

:D :confused: :D

[ChronoCross]

Well yeah kosaleksandar's last message on the dev list didn't go down to well.

True 3 or 4 of us yelled at him.

[Kostarum Rex Persia]

Ok, I didn't open new thread at mailing lists, because I didn't know the rules there. It's my fault.

[Chainmax]

Well, I'll have to keep an odler build :(.

Same here, still using Sharktooth's latest compile (r408).

[Sirber]

I'm on ChronoCross' rev 418 IIRC.

[ChronoCross]

438 build is my last build that has all of shaktooths patches. 445 is the most recent build with every patch except --subme 7.

[Sirber]

Maybe it's 438 then. It the build that was avalible before I ask you for a new one :)

[Chainmax]

438 build is my last build that has all of shaktooths patches.

Time to upgrade then :).

[max-holz]

With Rev. 460 I got these errors during compilation with fprofiled:


muxers.o:muxers.c:(.text+0x201b): undefined reference to `__gcov_init'
muxers.o:muxers.c:(.data+0x1e4): undefined reference to `__gcov_merge_add'
muxers.o:muxers.c:(.data+0x1f0): undefined reference to `__gcov_merge_single'


Someone could give some tricks to compile succesfully?

[ChronoCross]

With Rev. 460 I got these errors during compilation with fprofiled:


muxers.o:muxers.c:(.text+0x201b): undefined reference to `__gcov_init'
muxers.o:muxers.c:(.data+0x1e4): undefined reference to `__gcov_merge_add'
muxers.o:muxers.c:(.data+0x1f0): undefined reference to `__gcov_merge_single'


Someone could give some tricks to compile succesfully?

what's your gcc version? fprofiled doesn't work with 4.1. it only works with lower versions.

[max-holz]

what's your gcc version? fprofiled doesn't work with 4.1. it only works with lower versions.
gcc-3.4.5 :)
I used this command for configure: configure --enable-vfw --enable-avis-input --enable-mp4-output --extra-cflags="-Ic:/gpac/include" --extra-ldflags="-Lc:/gpac/bin/gcc"

Never had problems with previous rev.

[ChronoCross]

try the latest revision. just go tupdated again.

[lcx]

If anyone is able to compile for x64 Windows can you please share your *.vcproj

I just started compiling Win32 versions but have had no luck with Win x64 compilation.

[Kostarum Rex Persia]

Icx, look this, perhaps you will find something useful. http://forum.doom9.org/showthread.php?t=97531

[omion]

If anyone is able to compile for x64 Windows can you please share your *.vcproj

I just started compiling Win32 versions but have had no luck with Win x64 compilation.
My builds for Win x64 are here (http://omion.dyndns.org/x264x64/). The "-omion" ones are the pre-built binaries, the "-build" are a direct snapshot of the directory, including SVN data (you have TortoiseSVN, right? :D )

Only use the libx264.vcproj file. It will build both libx264 and x264.exe.

If you build your own, you might want to change line 178 of x264.c so that it doesn't say "built by Omion" ;)
Also if you update you have to manually update the version number at line 37 of common/common.h.

I don't have GPAC compiled in, so you can't output MP4. Instead, output raw or Matroska.

You also have to use a 64-bit version of avisynth, or pipe the input to x264 (akupenguin told me how to do it somewhere) Piping is much more practical if you have any kind of filters in the .avs file.

[lcx]

Awesome.
Thanks a bunch omion. :)

me off to try on my Win64 machine.

[IgorC]

Did anybody try Chronocross compilation of x264 r.463+AQ patch? It seems AQ doesn't do anything. MBs have constant quantizer.
x463.exe --pass 1 --bitrate 700 --stats ".stats" --ref 8 --mixed-refs --no-fast-pskip --bframes 3 --b-rdo --bime --weightb --filter -2,-2 --subme 6 --trellis 1 --analyse all --8x8dct --qcomp 0.75 --me hex --merange 16 --progress --b-pyramid --direct auto --aq-strength 0.2 --aq-sensitivity 15 --output 1x463_AQ_02_15.mp4 wall.avs

[Yong]

Just tested with different aq setting, all have same psnr :eek:

[ChronoCross]

The patch is working as far as I can tell. I manually added it by going through the patch and adding it to each file individually, and nothing in the patch or the code it effects changed. I need people to run more tests so I can see if it's broken. it shouldn't be and as far as I can tell most of the people still using it say it's working.

[IgorC]

But it doesn't work already for two people ( me and Young).
PSNR results are identical. Bit to bit comparing also says that two files ( with and without AQ) are indentical. All frame and MBs quantizer are identical. It is more than enough to say that AQ doesn't work.
I'm trying dif. values but the result is the same.


Can somebody check AQ in x264 r. 463? http://chronocrossdev.com/apps/x264/

[Yong]

this build works :
http://chronocrossdev.com/apps/x264/x264_438_cli.rar :rolleyes:

EDIT : 445, 458 doesnt work, i think no need to test the newer rev. :p

[foxyshadis]

It slows it down ~.5 fps, but does not appear to have any effect currently. Average quant is always an integer, size/psnr,etc are always identical. I will build my own and investigate this afternoon, once I reinstall VS2005; I'm sure it's just using a recently deprecated function call or similar.

Main test, with aq and bitrates tweaked around:

x264 --output test2.mp4 --bitrate 40 --subme 6 --threads 2 --bframes 3 --analyse all --me umh --aq-strength 1.1 --aq-sensitivity 15 --progress d:\video\work\Example.avs

No crf or 2pass tested yet.

[hpn]

But it doesn't work already for two people ( me and Young).
PSNR results are identical. Bit to bit comparing also says that two files ( with and without AQ) are identical. All frame and MBs quantizer are identical. It is more than enough to say that AQ doesn't work.
I'm trying dif. values but the result is the same.


Can somebody check AQ in x264 r. 463? http://chronocrossdev.com/apps/x264/

Yes, the results are identical with
--aq-strength 0.2 --aq-sensitivity 15

but I just tried different -aq options like
--aq-strength 0.5 --aq-sensitivity 5

and this time I got a different encode. Seems it depends on how much strength/sensitivity you apply. I have no idea why.
I also retested AQ with my own builds (http://mujweb.cz/www/x264/)to make sure everything is correct.

[ChronoCross]

I'll investigate it later today to see what I can find.

[ChronoCross]

okay guys. I just uploaded a new version. I went through by hand and checked everything it should be all good now. let me know please. thanks.

[Yong]

okay guys. I just uploaded a new version. I went through by hand and checked everything it should be all good now. let me know please. thanks.
--aq-strength 1.1 --aq-sensitivity 5 works... :p
but higher aq sensitivity(15, 22) still have same psnr.

[foxyshadis]

I'm still getting identical results with it. It must be that something recently modified whatever variables the "sensitivity" uses, so it needs to be rescaled.

[ChronoCross]

it's soo wierd. I can't find anything that would directly cause it. all the places where there is addition or changes in AQ code all look the same. that probably means that something else in a different file or method has changed so signifigantly that AQ no longer works. From the looks of it it seems that it broke at the same revision as --subme 7. so that definitely means that there was a major internal change.

[shon3i]

What is recommendation for AQ for DVD backups

[Yong]

I'm still getting identical results with it. It must be that something recently modified whatever variables the "sensitivity" uses, so it needs to be rescaled.
i tired the older build(r438) by ChronoCross with some weaker aq settings even like --aq-strength 0.1 --aq-sensitivity 22 and its work, unlike the newer revs.
may be the recent revs of x264 can produce optimal quality so the weaker aq settings doesnt work :D

[IgorC]

What is recommendation for AQ for DVD backups
It would be a hard task cause it depends on taste/psycovisual perception/preferements of each personally.
That's why I wanted to run some video with different aq setings.
Also it depends on other factors like source.

[ChronoCross]

Please test with as many values as you possibly can. please tell me about your different experiences. since some of you are saying certain values work an dothers don't.

Also don't just use psnr. Check the qp output manually and see if there are changes between the values (using ffdshow). Additionally do you notice any visual differences between the encoded clips.

[Yong]

a quick tested encode 320x240 @ 24fps mpeg1 video clip, with aq strength >=0.8 and aq sensitivity <=5 should work, at least for me, checked with ffdshow osd and psnr too.

EDIT: higher resolution might need stronger aq strength/sensitivity to get it work. ;)

[IgorC]

here is my result :
AQ of x438 works. How works is other question.

The results for AQ of x465.
Streght/sen-ty
0.1/5 - Doesn't work (no)
1.1/5 - yes (partial*)
0.1/22 - no
1.1/22 - no
0.5/15 - no.

* AQ 1.1/5 has very strange behavior. Only first (approx. 31-80) MBs have diferent quantiser. Others MBs just have the same quantiser while there's big contrast (darkness to light).
There were so many changes since then in code of x264 and maybe that's why AQ doesn't work anymore.

[foxyshadis]

Sensitivity is not an integer. If it is just a scaling issue, you should be able to specify something like 2.5 or 3.1 and get some results. 2.5 definitely gets results for me. I'm scanning the code (and trying to empirically match up how much it changes) to figure out how it changed.

[ChronoCross]

Sensitivity is not an integer. If it is just a scaling issue, you should be able to specify something like 2.5 or 3.1 and get some results. 2.5 definitely gets results for me. I'm scanning the code (and trying to empirically match up how much it changes) to figure out how it changed.

Haali and sharktooth have investigated and they aren't sure what's wrong either. I think they will be working on it some more when they have time but for now it's going to remain an unstable patch.

[Kostarum Rex Persia]

I must ask this: what is new decimation patch, compiled by Alex_W? What's purpose of this patch?

[Sharktooth]

speed up retaining as much quality as possible.

[foxyshadis]

So I got around to checking out AQ files in streameye and found something interesting: When you specify a threshold, like 2.0, the top of many frames is a high quant, and it suddenly ends at a lower quant some # of macroblocks in, and never changes after that. In older versions you'd see a somewhat random distribution of different quants around the frame, but this is just getting stuck in one low and one high quant. I spent a while wrestling with the code to find out why, but I'm not really familiar with x264's architecture at all; it looks like AQ is just going to have to be rewritten by someone familiar with the codebase.

[akupenguin]

http://students.washington.edu/lorenm/src/x264/x264_aq.5-466.diff

completely untested, I haven't even compiled it.

[ChronoCross]

v 466 on my site includes his patch. Everyone test please. Thanks.

[IgorC]

It works. Thank you, Chrono and Aku.
x264's AQ works diferently to Ateme's AQ. i.e. Ateme's AQ has higher quant on dark area where there aren't details and lower quant on walls (very high details). Imho very pleasent visual result.
x264's AQ seems to work totally vise versa.:confused: I'm going to look closer at it tommorow (dif. values, videos, setings.)

[foxyshadis]

No AQ: (http://foxyshadis.slightlydark.com/random/test0.mp4)
http://foxyshadis.slightlydark.com/random/test0.mp4_000144.png
AQ at .7/15: (http://foxyshadis.slightlydark.com/random/test-15.mp4)
http://foxyshadis.slightlydark.com/random/test-15.mp4_000144.png
Quant mask (dark=high/40, light=low/20)
http://foxyshadis.slightlydark.com/random/test-15.mp4_000144-quantmask.png

There's no obvious pattern to the oddly bright blocks, they show up mostly in low-quant portions of the frame though. Not every frame has them, either.

x264 --bitrate 500 --analyse all --me umh --pass 2 --stats .stats --bframes 3 --progress --no-fast-pskip --aq-strength .7 --aq-sensitivity 15 -o test-15.mp4 d:\video\work\test.avs

[IgorC]

--aq-strength .7 is too much . With 0.5 already all faces are washed. Something around 0.2 is more acceptable.
What happens if to low sen-ty to 20-22 with remaining strenght 0.7?

I think we are on offtopic here :rolleyes:. http://forum.doom9.org/showthread.php?t=105501&highlight=aq+adaptive

[akupenguin]

A guess about the oddly colored blocks: they might have been assigned high qp by the aq, and then decided to be Skip or at least no residual. But skips don't get a delta_qp (it doesn't matter what qp the mb used if it doesn't code any dct coefs), so the qp values you see on playback are not the values that were used to quantize those blocks.
Plus, imho 40/20 is way too much variation to have within one frame.

[foxyshadis]

Without no-fast-pskip they actually were assigned to pskip, though with it they were 16x16, so I guess you're right. I'll try again with much lower settings. At .3 and twenty the blocks are there but rare, like the old bluesky issue (maybe that's all this is?), at .1 there's not much difference to the original anyway; gradients are slightly smoother but sharp details are more lacking, even though the "main" quant is only one less. Oh well, I'll play around a bit more and see if I can find good settings.

[hpn]

rev. 474 introduced a new CLI option --thread-input (run Avisynth in its own thread), but that broke the current AQ patch "x264_aq.5-466.diff" posted on the akupenguin page, by adding
#define OPT_THREAD_INPUT 320 to x264.c. I fixed it manually by simply changing from

+#define OPT_AQ_STRENGTH 320
+#define OPT_AQ_SENSITIVITY 321

to

+#define OPT_AQ_STRENGTH 321
+#define OPT_AQ_SENSITIVITY 322

(plus fixing the offsets and stuff) like this
http://mujweb.cz/www/x264/x264_aq.5-474.zip

I guess this is the correct way to fix the patch, but if not please correct me, so I don't compile potentially broken builds.

[Sagittaire]

Why not to import mask from libavcodec:
Lumimask [0.00-1.00] : higher quant for luminess part
Darkmask [0.00-1.00] : higher quant for darkness part
Temporalmask [0.00-1.00] : higher quant for high motion part
Spatialmask [0.00-1.00] : higher quant for high texture part

and why not other mask for evaluation ... ???

and let x264's users to find the best possible setting

[ChronoCross]

rev. 474 introduced a new CLI option --thread-input (run Avisynth in its own thread), but that broke the current AQ patch "x264_aq.5-466.diff" posted on the akupenguin page, by adding
#define OPT_THREAD_INPUT 320 to x264.c. I fixed it manually by simply changing from

+#define OPT_AQ_STRENGTH 320
+#define OPT_AQ_SENSITIVITY 321

to

+#define OPT_AQ_STRENGTH 321
+#define OPT_AQ_SENSITIVITY 322

(plus fixing the offsets and stuff) like this
http://mujweb.cz/www/x264/x264_aq.5-474.zip

I guess this is the correct way to fix the patch, but if not please correct me, so I don't compile potentially broken builds.

that is correct. each one has to have it's own id. so the overlapping id thing is a simple fix.

[hpn]

:thanks: