ChronoCross X264 New Build Querie [Archive]

fight2win

18th March 2006, 04:04

I've added a new build. It contains some experimental as well as some updated patches done by both Alex_W and akupenguin.

Here's the info:

Adaptive Quantization v.5 by Haali Updated by Loren Merrit
mmxext fixes v.0 Loren Merrit
New Decimation v2 Updated for 469 by Alex_W
Check subpel predictors by Alex_W
Cli Signature by Sharktooth Modified by ChronoCross

which one is it, 469 special or 471?

Audionut

18th March 2006, 09:40

New Decimation v2 Updated for 469 by Alex_W

Guess.

foxyshadis

18th March 2006, 09:43

fight2win, every CC build comes with a text file listing applied patches.

ChronoCross

18th March 2006, 22:06

Avish

19th March 2006, 08:11

I first added them to 469. they are added to every build after that and you can locate the txt file in the rar which will tell what patches I have applied.

I will make a build for 473 in an hour or so.
Just want to confirm... Are the builds here http://x264.nl/ same as yours? revision numbers are same so I guess they are...but just wanna confirm from you...

Thanks.

DryFire

19th March 2006, 08:17

Just want to confirm... Are the builds here http://x264.nl/ same as yours? revision numbers are same so I guess they are...but just wanna confirm from you...

Thanks.

the x264.nl builds do not contain experimental patches while his do (see the .txt from teh .rar)

teh numbers correspond to teh revsions of x264. To see what changes in each revision go here:

https://trac.videolan.org/x264/log/trunk/

Avish

19th March 2006, 09:50

the x264.nl builds do not contain experimental patches while his do (see the .txt from teh .rar)

teh numbers correspond to teh revsions of x264. To see what changes in each revision go here:

https://trac.videolan.org/x264/log/trunk/
Thanks for clearing that up...but now I'm confused...Which one should I use?:confused:

ChronoCross

19th March 2006, 10:25

up to you. if you want bleeding edge features use mine. If you prefer the stable build use x264.nl. It's really up to you.

hpn

19th March 2006, 11:17

Thanks for clearing that up...but now I'm confused...Which one should I use?:confused:
Because of the two Alex_W patches applied to the ChronoCross build, both the cc and nl builds are inherently different (if I'm not wrong), which means that you can't get identical encodes from both builds by using standard option sets (unlike the Adaptive Quantization patch for example, where you can simply skip the --aq options and get identical encode). So the question is: how good are the Alex_W patches. I just did a short 1000 frames comparison test and the cc build resulted in a slightly higher PSNR, 40.46 vs 40.38 (and maybe 5% slower because of these patches?), but if you want to make sure that it's always true, just encode 5-6 different sources with different options and see for yourself. Also I suspect that bobOr is using some custom (not the default) gcc compilation options that ChronoCross is not aware about, so the nl builds are probably marginally faster.

foxyshadis

19th March 2006, 11:27

bobor does use gcc optimizations, but they wouldn't do ChronoCross much good since he builds with VS2005. =p (I do hope it's with all vs optimizations enabled, though.)

Avish

19th March 2006, 15:43

up to you. if you want bleeding edge features use mine. If you prefer the stable build use x264.nl. It's really up to you.
:confused: What is bleeding edge features? I don't set any features myselft...I just use sharktooth's readymade profile [mainly HQ Slow] with meGUI... so which one is more suitable for that kinda use?

Sharktooth

19th March 2006, 15:51

new decimation, adaptive quant, and all the patches included in the ChronoCross builds...
most of them (except adaptive quant) are "transparent" to the user.

ChronoCross

19th March 2006, 19:33

I use gcc for building. but I don't use any custom flags or fprofiled. but I use gcc 4.1 which might be marginally faster in general to what bobor uses. either way I don't notice any speed difference when moving between the builds.

LoRd_MuldeR

20th March 2006, 02:38

new decimation, adaptive quant, and all the patches included in the ChronoCross builds...
most of them (except adaptive quant) are "transparent" to the user.

Is it possible to make a MEncoder build that includes those patches?
If so, can somebody provide such a build ???

celtic_druid

20th March 2006, 03:10

I could probably manage that. Just need to swap libs before linking. mencoder's ve_x264.c will have to be modified for aq though.

LoRd_MuldeR

20th March 2006, 03:19

I could probably manage that. Just need to swap libs before linking. mencoder's ve_x264.c will have to be modified for aq though.

I'm looking forward :)

ChronoCross

20th March 2006, 04:42

the only problem with mencoder is that it doesn't like largefiles. which is why I stopped attempting to compile it for use by anything othert han xvid.

celtic_druid

20th March 2006, 12:01

Gusar

20th March 2006, 13:06

the only problem with mencoder is that it doesn't like largefiles. which is why I stopped attempting to compile it for use by anything othert han xvid.

The problem is mingw, not mencoder. Gianluigi Tiesi posted a patch for mingw to the mplayer-cygwin mailing list, here (http://mplayerhq.hu/pipermail/mplayer-cygwin/2006-March/002567.html). It's a very simple patch, but it does the job.

LoRd_MuldeR

20th March 2006, 13:49

Ok.
aq_strength, default 0.0, range 0.0->1.1
aq_sensitivity, default 15, range 5.0->22.0

Did I get that right?
http://mirror05.x264.nl/celtic_druid/force.php?file=./mencoder.7z
Built for Athlon-XP's.

Yeah, this seems to work :thanks:

With aq_strength set to 0.5 it encodes slower, so it does do something!

celtic_druid

20th March 2006, 14:21

Well hopefully it does more than just encode slower.

foxyshadis

20th March 2006, 14:45

My tests indicated that since the stride refactor that broke the original AQ, default sensitivity really needs to be moved to 22 or so. 15 now effects 90% of blocks and looks quite garish at times. 15-30 is probably the effective range now.

Romario

21st March 2006, 17:09

CronoCross, can you enable, in your next MeGUI build, --thread-input option.

Thank you.

ChronoCross

21st March 2006, 19:02

the threa dinput option is added to the command line when threads >1. It's not a switchable option as it only works anyway when threads is a positive non-one number.

bond

21st March 2006, 19:23

the threa dinput option is added to the command line when threads >1. It's not a switchable option as it only works anyway when threads is a positive non-one number.i think this now has been changed to an own option

ChronoCross

21st March 2006, 19:32

i think this now has been changed to an own option

In x264 it's it's own option. In megui 0.2.3.2114 (latest cvs) it is automatically added to the commandline if you set the threads dialog to 2 or greater. If megui gets updated for it to work independantly, which doesn't make sense considering the shown speedup by running input in another thread. However I will continue to check the cvs for an update to see if this condition has been changed.

Sharktooth

21st March 2006, 19:41

naa... --thread-input on single core CPUs is useless and may even slow down the encode.
--thread-input requires SMP/dual core/HT systems and megui can auto-detect the number of threads needed.
in any case, in megui, --thread-input is automatically added when --threads > 1.
it has been already explained here: http://forum.doom9.org/showthread.php?p=802885#post802885
however please stay on topic... this is thread is about CC x264 builds not megui

Chainmax

22nd March 2006, 00:35

ChronoCross

22nd March 2006, 00:45

Wasn't AQ made redundant with the appearance of the no fast pskip option? If not, is AQ now something that can improves quality in all cases or just specific blocking scenarios?

[edit]Does the readme in CC's build details only the latest applied patches? If so, where can I find a list of all the applied patches?

If I remember correctly the fast pskip option is one of the causes of the problem that AQ was designed to fix. However even with no-fast-pskip the blocking can still occur. There is still plenty of possible benefit that can be gained by finely tuning your AQ settings.

Edit: To answer your edit I usually keep a fiel in there listing th epatches I have applied to the svn

foxyshadis

22nd March 2006, 01:33

AQ has become more of a shotgun approach to fixing blocking, as it's become more out of sync with the underlying codebase, I think. I've noticed that its quality has steadily degraded as some new features crept in, most notably when it had to be fixed for the stride refactor. You need a higher bitrate - probably 15-25% - for an AQ encode to look as good as a non-AQ, aside from the shallow gradients AQ helps. I'm not sure why, since the quantizers hardly move in most areas, but edges are obviously less sharp and texture more smoothed. If it works, great, but I don't use it anymore unless I have a real problem area (and usually only as a point patch).

--thread-input only seems to be much better if you're running avisynth filters on the other end. Straight decoding of a lossless or near-lossless xvid intermediary is rarely more than a few % unless x264 is on very fast settings.

Chainmax

22nd March 2006, 13:11

So AQ is rarely helpful, needs much more bitrate and is rendered somewhat obsolete by the no fast pskip option. Cool, one more less switch t use and a faster encode :).

[edit]
To answer your edit I usually keep a fiel in there listing th epatches I have applied to the svn

Does your latest build have all of Sharktooth's patches? If not, which one is missing?