x264 sticky suggestions

[yaz]

sharky !
thx a lot (again (& again (...))) :)
if u plan to keep this thread for announcing would it be useful to 'stick' ? (i know it's not your competence)
thx
y

[Sharktooth]

I already PMed bond hoping he will stick this thread

[TheUnforgiven]

@sharktooth
i suggest that u keep the changes for at least 6 builds

[len0x]

Good idea about keeping longer revision history.

Btw, I just compiled VFW rev 136 with ICL 8.1 for P4 and its ~11% faster on my system the sharktooth' build.

[Sirber]

For P4 means with SSE2?

[Sharktooth]

I added a "recent" version history

@len0x: Take into consideration i havent used any special C or ASM flags. So, no specific CPU optimization were used...
Try this build on athlon xp CPUs and tell me the differences:
http://www.aziendeassociate.com/X264VFW_rev142_athlonxp.exe (completely untested!)

This build is for Pentium4 instead:
http://www.aziendeassociate.com/X264VFW_rev142_pentium4.exe (completely untested too...)

[Ark]

Why not put a link to a simple .txt files with rev. history? That way the thread remain small while information for each revision remain intact.

In this thread can remain history for the last 5 revisions, or only the lastest.

Only my 2 cents...

[Sharktooth]

The revisions changes are all logged in the SVN. I think another changelog is not necessary.

Anyone tested the AthlonXP or the P4 build?

[Sirber]

I'll try the P4 build tonight. Does it works on AMD64? It it has Intel detection prior to use SSE/SSE2?

[len0x]

P4 build may not work on any other processor even if instruction set is supported (I know that ICL does cpuID check, dunno about gcc)

[Doom9]

and if the P4 build uses SSE3.. there's still no 64bit AMD CPUs available to support it (but the next batch hopefully should)

[azsd]

ICL can do and not to do the check both in compiler options.
btw,this P4 build encoded done on my P4 2.4

[Sharktooth]

P4 build should use SSE and SSE2 (not SSE3) but i dont know if it will work on A64s coz i used -march=pentium4 and -O3.

[hpn]

Originally posted by Sharktooth
Anyone tested the AthlonXP or the P4 build?
I just tested both the Generic and the AthlonXP rev142 builds. Both work fine and produce bit-identical encodes. The Athlon build is about 6% faster - 14:28m vs. 15:25m for the generic one (2pass, 4525 frames, 800kbps), so it would be fine if you keep compiling processor-specific builds. If you have time you could also link the source along with each build (or at least weekly, one rar file would be fine).

[Sirber]

ok. I will try both then :D

[NuPogodi]

Originally posted by Sharktooth
Anyone tested the AthlonXP or the P4 build?
It would sound a bit strange, but... i've encoded a clip with AthlonXP-build rev.142 (2-pass, Advanced options are defaulf except from: Deblocking=-2,-2, 2B-frames, 3 Reference Frames). Then, tried to decode this clip with two various H264/AVC decoders: Videosoft (v.2.2.4.2) and ffdshow (build Feb 12, 2005). ffdshow works properly, Videosoft displays a lot of green blocks... Can anyone suggest what in rev.142 can cause these blocks to appear? (clips encoded with rev.130 [edited] at the same x264 configuration were properly decoded by both decoders, Videosoft was just a bit faster, ~10-12%).

[EDIT] excuse me, i was a bit wrong... this "green-block" VideoSoft decoding did not exist in rev.130, but not in rev.135. Actually, Rev.135 gives the same behavoir as rev.142 - ffdshow is OK, VideoSoft = green blocks. Can anyone confirm this? or it's the feature of my own?

[buzzqw]

i had encoded a small vob (3500 frames) with build for P4.

Either in 2 pass mode (first pass fast and in another encode first pass slow) and quant encode (16,17,18).

No problem so far.

BHH

EDIT: Decoding side

ffdshow isn't so great at decoding (build 17/02/05), a little slow but correct
mpc (dev build): ok
VLC 0.81: with blocky squares

[Doom9]

tested the P4 build on my AMD64 in CQ mode and there are no apparent problems (I just tested a 1000 frames clip)

[Sirber]

tested the P4 build on my AMD64 (via avs2avi) and it fails.

[Sharktooth]

Originally posted by hpn
I just tested both the Generic and the AthlonXP rev142 builds. Both work fine and produce bit-identical encodes. The Athlon build is about 6% faster - 14:28m vs. 15:25m for the generic one (2pass, 4525 frames, 800kbps), so it would be fine if you keep compiling processor-specific builds. If you have time you could also link the source along with each build (or at least weekly, one rar file would be fine).
The source is the same as the generic build.
The only difference is in the Makefile, where i added or modified the compiler flags.

@all: do you want me to compile athlon 64 builds too?

[Amdh]

:) :)
Well .. It Seems to be a stupid suggestion .. but I suggest that U integrate a Direct show decoder in the x264 Installer so that x264 material can be decoded independently of ffdshow !
Increasing Performance and Compression Efficiency is of course required !

[Sirber]

x264 Decoder is not working IIRC.

[Sharktooth]

Originally posted by Sirber
x264 Decoder is not working IIRC.
Exactly.

[Doom9]

tested the P4 build on my AMD64 (via avs2avi) and it fails.try vdub. I'll try the p4 mencoder builds tonight and see how it fares.

[hpn]

Originally posted by Sharktooth
The source is the same as the generic build.
The only difference is in the Makefile, where i added or modified the compiler flags.

You misunderstood me. I meant you could rar and link the source daily (or at least weekly) on the sticky, after you get it from SVN repository, not that there are different sources :). You already do all the work downloading the changed files daily, so I thought if would be a good idea to save the tedious process for the other curious guys who would want to check the code and see how things progress (but of course it's ok if you don't have time for this).

[Sharktooth]

As i previously said the P4 version is not guaranteed to run on A64s because i used -march=pentium4 and -O3 (strictly P4 optimized).
Use the athlon xp build with athlon 64s or if i get enaugh request (actually 0) i could make a specific build.

[Sirber]

-march=athlon-xp -mmmx -msse -msse2

could work with AMD64 I guess :)

[Doom9]

I think we ought to at least give the AMD64 build a try.. and if it doesn't help over the P4 build we know there's no reason for such a build.

[len0x]

Sharktooth' P4 version doesn't run on XP, while XP build is really fast (about 6% faster than generic).

[Ariakis]

I doubt it's significant, but it's all the time I can spare at this moment... On 2 successive runs for both the AthlonXP and Pentium4 compiles on my Athlon64, the AthlonXP performed about 2% faster... maybe due to cache size? Anyway, this makes me think an Athlon64-specific compile could be useful.

[twist3d]

how about a sticky for "x264 recommended encoding settings" for 1cd, 2cd, high compressability <- (is that even a word), high details etc. [i was very, very drunk when i was writing this :D]

[Sharktooth]

Originally posted by Sirber
-march=athlon-xp -mmmx -msse -msse2

could work with AMD64 I guess :)
for athlon xp i used:
CFLAGS += -march=athlon-xp
CFLAGS += -O3
CFLAGS += -funroll-loops
CFLAGS += -ffast-math
CFLAGS += -finline-functions
CFLAGS += -fomit-frame-pointer
CFLAGS += -mmmx
CFLAGS += -mfpmath=sse
CFLAGS += -msse
CFLAGS += -m3dnow

for athlon 64 i should add -msse2.

EDIT: Added athlon 64 build. Plz test it against athlon xp build.

[Bogalvator]

-finline-functions is implied by -O3.

-m3dnow, -msse, -mmmmx are all implied by -march=athlon-xp.

Also, removing -funroll-loops and -mfpmath=sse will probably result in faster (and safer) compiles. Basically as a rule, the less flags, the better!

This test used for compiling LAME may be informative:
http://encoding.zapto.org/mingw_speed_tests.htm

[Sirber]

It's best to keep -mfpmath=sse. SSE is way faster than old 387 FPU.

I will try the new build tonight.

[celtic_druid]

What version of gcc did you use? Because your filesizes are larger than what I get (3.4.2).

Anyway, this is what I came up with for a 5,000 frame encode 1 pass 1 bframe, 5 ref.

my athlon-64
Finished in 00:04:28.613 (18.61 FPS)

my athlon-xp
Finished in 00:04:29.592 (18.55 FPS)

my mmx
Finished in 00:04:35.095 (18.18 FPS)

Sharktooth's 64
Finished in 00:04:39.528 (17.89 FPS)

sharktooth's athlon-xp
Finished in 00:04:40.345 (17.84 FPS)

[Blue_MiSfit]

Updated to the 142 p4 build. It works perfectly on my a64 through vdub.

This codec is really starting to amaze me.

Good sticky btw
~MiSfit

[Sirber]

@celtic_druid

Interresting :D Could your builds be added to the sticky also? :D

[celtic_druid]

If you host it. I'll PM you the location to where I moved stuff incase you want to do some tests or host it.

For benching I used the x264 version of avs2avi. That way you can do
echo.Athlon XP encode 1 > log.txt
ren x264vfw.dll x264vfw.dll.bak
ren x264vfw.dllxp x264vfw.dll
avs2avi input.avs output.avi -c x264 -q -o n >> log.txt
etc.

and easily test multiple builds.

[len0x]

Current Sharktooth' 144 build (generic and P4 version tested) has issues. It crashes half way through of the first pass of that Spiderman trailer (always after the frame 1639). I compiled rev 144 with both MSVC and ICL 8.1 and they run just fine. Something got b0rked in gcc :)

P.S. VFW version with vdubmod used...

[buzzqw]

in my test the same build vfw144-p4 (on p4 2.8) with avs2avi don't crash... (3500 frames)

BHH

[len0x]

Actually its not the compiler, its revision that is b0rked a bit. My compiles run file, but no video is placed in AVI after that problematic frame (just black zero bytes until the end). Off to development thread now.

[Sharktooth]

Originally posted by celtic_druid
What version of gcc did you use? Because your filesizes are larger than what I get (3.4.2).

Anyway, this is what I came up with for a 5,000 frame encode 1 pass 1 bframe, 5 ref.

my athlon-64
Finished in 00:04:28.613 (18.61 FPS)

my athlon-xp
Finished in 00:04:29.592 (18.55 FPS)

my mmx
Finished in 00:04:35.095 (18.18 FPS)

Sharktooth's 64
Finished in 00:04:39.528 (17.89 FPS)

sharktooth's athlon-xp
Finished in 00:04:40.345 (17.84 FPS)
I use gcc 3.4.2 too. Maybe you set different cflags?

@bogalvator: a common mistake is to think -march assumes all the instruction optimization flags. I prefer to specify them manually. Just one thought, maybe -m3dnow is slower than -msse? Maybe forcing -mno3dnow will result in a faster build.

[Sirber]

AMD64 build encoded pretty fast, but result file is blank (audio only, not playable, black screen).

[edit]

XP build too :S

* Pass 1/1: Frame 509/573, 0 B, 9.60 FPS, ETA 00:00:06

CBR, 536kbps

[edit 2]

it works #1, was a setting screw between x264 and RealAnime :rolleyes:

[celtic_druid]

Encoded 5,000 frames here fine.