Current Patches, Where to get them, How they affect speed/output

[Egh]

Originally Posted by LoRd_MuldeR

Because testing showed that "threads = 3/2 * cores" works best. And that finding doesn't seem to be random at all

The intuitive solution "threads = cores" would only give optimal performance if no thread ever becomes idle (needs to wait for another thread).

still random. nearly 25% cpu% loss (total % for both cores) just with 2 threads instead of 3. With the same .bat file of course. So you effectively imply in this scenario either one thread is idle 50% of time of both threads idle 25% of time. Suboptimal?

[LoRd_MuldeR]

Originally Posted by Egh

still random. nearly 25% cpu% loss (total % for both cores) just with 2 threads instead of 3. With the same .bat file of course. So you effectively imply in this scenario either one thread is idle 50% of time of both threads idle 25% of time. Suboptimal?

I don't imply anything. I just say that in a "real life" application you cannot assume that threads are working 100% independently of each other. Threads need to synchronize now and then! And that means that any thread unavoidably will have some idle time while waiting for another thread. Also you must keep in mind that the "look ahead" part of x264 is not multi-threaded. Lookahead needs to run each time a new encoder thread is spawned. Now imagine you were running exactly four threads on a quadcore CPU. When the first thread/frame completes, only three encoder threads are left running in parallel. Now lookahead will need to run again before a new thread is spawned. With lookahead and the three encoder thread still all four cores are busy. But if the second thread/frame completes, while lookahead has not completed yet, only two threads are left running in parallel - one CPU core becomes idle. This easily explains why running more encoder threads than cores makes sense. Last but not least the multi-threading in x264 obviously is pretty optimal: When you configure the number of threads properly (cores * 3/2), then x264 will fully utilize a quadcore CPU and give ~4x speed of a single core.

[skystrife]

x264 r1136 x64 (unpatched) - Alternate Download
gcc 4.3.4 fprofiled build.

-------------------------

x264.1136M.x86.exe - Alternate Download / x264.1136M.x64.exe - Alternate Download
gcc 3.4.5 fprofiled build with -march=pentium2. / gcc 4.3.4 fprofiled build.

Patches used:

x264_hrd_pulldown.11_interlace.diff
x264_win_zone_parse_fix_05.diff

[techouse]

x264_x86_r1136_techouse | INFO
GCC 4.3.3, fprofiled, -march=core2

x264_x64_r1136_techouse | INFO
GCC 4.3.4 20090328 (prerelease) (x64.generic.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pulldown.11_interlace.diff
x264_win_zone_parse_fix_05.diff

[burfadel]

According to the GIT, the last patch was added 32 hours ago (faster CABAC RDO), and yet there are no 1137 builds...

www.x264.nl doesn't seem to be autoupdating it, at least quickly?...

[kemuri-_9]

Originally Posted by burfadel

According to the GIT, the last patch was added 32 hours ago (faster CABAC RDO), and yet there are no 1137 builds...

www.x264.nl doesn't seem to be autoupdating it, at least quickly?...

the latest patch wasn't released until 5 hours ago.
the devs often keep the patches locally for testing and only push to the global repository after testing is complete.
however the times are from the local repository, not from the global.

if you want the actual times it hits the global, you can check the x264-devel mailing list for subjects that start with 'commit: '
like r1137

as for x264.nl it could either be on hold or there was a problem somewhere.

[skystrife]

x264 r1137 x64 (unpatched) - Alternate Download
gcc 4.3.4 fprofiled build.

-------------------------

x264.1137M.x86.exe - Alternate Download / x264.1137M.x64.exe - Alternate Download
gcc 3.4.5 fprofiled build with -march=pentium2. / gcc 4.3.4 fprofiled build.

Patches used:

x264_hrd_pulldown.11_interlace.diff
x264_win_zone_parse_fix_05.diff

[burfadel]

Originally Posted by kemuri-_9

the latest patch wasn't released until 5 hours ago.
the devs often keep the patches locally for testing and only push to the global repository after testing is complete.
however the times are from the local repository, not from the global.

if you want the actual times it hits the global, you can check the x264-devel mailing list for subjects that start with 'commit: '
like r1137

as for x264.nl it could either be on hold or there was a problem somewhere.

Ah ok! that makes sense

[3ngel]

I'm getting this on Phenom with latest

x264.1137M.x86.exe --pass 1 --bitrate 1270 --stats ".stats" --progress --keyint 250 --bframes 16 --qpmin 10 --qpmax 51 --aq-mode 0 --psy-rd 0.8:0 --no-psnr --no-ssim --no-fast-pskip --mixed-refs --b-adapt 0 --trellis 2 --ref 9 --no-deblock --subme 7 --direct auto --me umh --merange 32 --nf --weightb --b-pyramid --partitions all --8x8dct --threads auto --thread-input --no-dct-decimate --level 41 --output NUL "t.avs"

Original image size 844*480

Second Pass has identical parameters

Same result with --no-asm too



EDIT:
About the same glitches (not exactly the same) i obtain with previous versions too back to about 1113

These types of glitches are present randomly on all the video

Tested with CoreAVC, MPC Decoder and with MPC, graphedit etc...

[komisar]

3ngel, what/whose build you use? Can you repeat this "bug" with other builds?

[3ngel]

http://skystrife.com/x264/x264.1137M.x86.exe

[kemuri-_9]

post the sample you're encoding so i can do testing on my phenom computers when i get off work.

[akupenguin]

@3ngel
Your artifacts are definitely produced by a median-predicted lossless codec, such as ffvhuff or lagarith. Either a decoder bug or a corrupt bitstream.
mpeg-like codecs do not have failure modes that look like that.

[3ngel]

Mmm... i see.
I've tested the script in VDub before feeding to encoder, and it's a regular not corrupted lagarith. Moreover playing the .avs (and the lags .avi within) all is regular.
Now i'm doing a new encoding.

[Dark Shikari]

I've seen that before as well--in a broken lagarith decode.

[3ngel]

But if it can be a lagarith issue, why i don't see the same in vdub?
Both VDub and avs use the same decoding routine (and i see both fine).

[LoRd_MuldeR]

Originally Posted by 3ngel

But if it can be a lagarith issue, why i don't see the same in vdub?
Both VDub and avs use the same decoding routine (and i see both fine).

Try converting your video to HuffYUV or FFv1 in VirtualDub. Then try to feed that into x264...

[3ngel]

Yes, doing that right now (doing uncompressed).

[techouse]

x264_x86_r1137_techouse | INFO
GCC 4.3.3, fprofiled, -march=core2

x264_x64_r1137_techouse | INFO
GCC 4.3.4 20090408 (prerelease) (x64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pulldown.11_interlace.diff
x264_win_zone_parse_fix_05.diff

[Egh]

Originally Posted by LoRd_MuldeR

Also you must keep in mind that the "look ahead" part of x264 is not multi-threaded. Lookahead needs to run each time a new encoder thread is spawned.

Your explanation is very good, however can you describe in more detail how lookahead works? For instance, how much time or cpu% is spent for lookahead thread. As well, how do the things work in non-multithreaded mode, on single core?