Current Patches, Where to get them, How they affect speed/output [Archive] - Page 25

stanjr

2nd October 2008, 15:25

With the x264 r996, I can't get mplayer (r27682) to compile due to libx264.c not knowing what b_bidir_me and b_bframe_rdo are. I tried changing them to i_bidir_me and i_bframe_rdo within libx264.c like with the issue before, but that doesn't work either. What should I make them to get it to compile?

Sagekilla

2nd October 2008, 15:32

b_bidir_me and b_bframe_brdo paramters were removed from x264. bime is automatically enabled at subme => 5 and b-rdo at subme => 7 I believe.

You need to remove the bime and b-rdo params from mplayer that it's inputting to x264.

stanjr

2nd October 2008, 15:59

Cool, completely removing them worked!

kemuri-_9

2nd October 2008, 16:21

Casino Royale; encode's bitrate is 9500 kbps
Subme9 is 5.26% slower on my PC than Subme8.

and what settings was that compared on, as the other settings often do determine the fps speed change for a single specific setting
i.e. subme 8->9 on --me dia and subme 8->9 on --me tesa will likely not have the same percentage-based speed loss.

techouse

2nd October 2008, 16:29

techouse, could you post a sample? TIA.
http://sets.djslo-forum.com/mp3/memi/shark/

(Strange link, I know...)

and what settings was that compared on, as the other settings often do determine the fps speed change for a single specific setting
i.e. subme 8->9 on --me dia and subme 8->9 on --me tesa will likely not have the same percentage-based speed loss.

aq-strength 0.8
psy-rd 0.8:0.8
trellis 2
level 4.1
ref 5
bframes 16
merange 32
me umh

skystrife

2nd October 2008, 22:11

x264.997.modified.exe (http://www.mediafire.com/?ezyzqdzqtlk) - Alternate Download (http://skystrife.com/x264/x264.997.modified.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

Rodger

2nd October 2008, 23:23

Hi guys,

sorry for answering so late. Been busy updating/upgrading my system. I wanted a new motherboard. Not because of the problem..but to get better performance out of what I already have and man I didn´t get disappointed.
Asus P5Q really shows it to Asus P5B-E. At lower voltage already 150Mhz more core speed and not yet done.
However...just got it all back together, started Megui the update came...PERFECTLY Stable at 3600Mhz here.

Atak_Snajpera

2nd October 2008, 23:25

However...just got it all back together, started Megui the update came...PERFECTLY Stable at 3600Mhz here.
Only Prime95 will tell you truth about stability :)

poisondeathray

2nd October 2008, 23:30

Or try Linpack 64-bit, it stresses more than Prime95; temps get about 4-5 degress higher with it than "wimpy" Prime95 :)

Rodger

2nd October 2008, 23:45

Only Prime95 will tell you truth about stability :)

I tell you both...WAY OVERRATED. It´s a good start. But still I realize very often, that playing 3D-Games or doing video-encodes for hours is a different Kind of stress testing which will in some cases proof you wrong.
Well...as I said...the 3600Mhz is kinda out of the box ;)
Before with tricks and stuff 3430Mhz was a dead end for me with the old board. Now on the P45-board the E8400 finally gets to life ;)
Weel see...the max Vcore will be 1,28V...thats definitive!
And the Ram is only at stock-setting more performance is to gain here to.

But thats clearly OT so...talk will have to be via PM.

skystrife

3rd October 2008, 02:40

x264.998.modified.exe (http://www.mediafire.com/?m3ndoztwnei) - Alternate Download (http://skystrife.com/x264/x264.998.modified.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

techouse

3rd October 2008, 10:29

x264_x86_r999_techouse (http://techouse.project357.com/builds/x264_x86_r999_techouse.7z)
Source: x264 r999 GIT (git://git.videolan.org/x264.git)

Applied patches (current versions):

x264_hrd_pulldown.09_interlace.diff

Please check http://forum.doom9.org/showthread.php?t=130364 and http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog for more info

Compiled by techouse on October 3rd 2008, 10:39:01 CEST with GCC-4.3.2 on Windows Vista Business SP-1 64-bit.

Commandline used: ./configure --extra-cflags="-march=core2 -pipe" && make fprofiled

Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: yes
pthread: yes
gtk: no
debug: no
gprof: no
PIC: no
shared: no
visualize: no

Audionut

3rd October 2008, 11:00

Revision 999

List of changes from here. http://git.videolan.org/?p=x264.git;a=summary

*Fix minor memory leak accidentally added with the addition of b-adapt 2

*Resolve quality regression in r996
Accidentally removed the wrong line of code. I think this classifies as a "10l".
Thanks to techouse for initial bug report and skystrife for helping me find it.

*rm gtk, avc2avi.
I don't remember why I allowed a gui into the repository in the first place. There's nothing that makes this one special relative to all the other x264 guis.
avc2avi doesn't compile since we removed the bitstream reader. And avc doesn't belong in avi.

x264-999.rar (http://rapidshare.com/files/150504515/x264-999.rar)

edit: no builds from me till about wed arvo aus time. Water pump shat itself and i won't get a replacement till tues. And i'm going away tues-wed.

Atak_Snajpera

4th October 2008, 23:54

I tell you both...WAY OVERRATED. It´s a good start. But still I realize very often, that playing 3D-Games or doing video-encodes for hours is a different Kind of stress testing which will in some cases proof you wrong.
I will not agree with you. Prime95 MT version crashes almost immidietely if cpu has too low voltage. x264 works always longer. Besides Prime95 MT always gives me alot higher temp than games or x264. I've never seen situation when Prime95 MT was stable but x264 or games would crash. (Let's focus on cpu only)

saint-francis

5th October 2008, 05:17

I will not agree with you. Prime95 MT version crashes almost immidietely if cpu has too low voltage. x264 works always longer. Besides Prime95 MT always gives me alot higher temp than games or x264. I've never seen situation when Prime95 MT was stable but x264 or games would crash. (Let's focus on cpu only)

This is an interesting topic and highly relevant to many of us here on the doom9 forum who are in the pursuit of faster hardware to decrease our encoding time. Can we move it to the hardware forum? I would like to contribute but I don't want to bring this thread OT any more.

Kurtnoise

12th October 2008, 15:06

Hmm.... I think i developed a small patch that relaxes the qpfile to be able to only specify certain frames of the video (i believe this was mentioned as a feature request somewhere)
http://kemuri9.net/dev/x264/x264_qpfile_relax.diff
(based on r889)

did you have still this patch somewhere please ?

MasterNobody

12th October 2008, 15:21

did you have still this patch somewhere please ?

It was commited in git (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=9c5e557c5544690b22f61614fae9b516c7e53ba1)

Kurtnoise

12th October 2008, 15:37

yeah...I asked this because I can't access to the x264 git right now.

J_Darnley

12th October 2008, 16:11

Kurtnoise

12th October 2008, 17:55

Can you not even access the web interface? Diff (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commitdiff_plain;h=9c5e557c5544690b22f61614fae9b516c7e53ba1) and on Pastebin (http://pastebin.com/d3a350c84)
well all is working fine now...so, I suppose that is an issue from videolan.org

10x anyway.

3ngel

27th October 2008, 14:45

Hi,
i've discovered and i want to signal a systematic (althoug random) bug wich happens on all Pure Black & White screens or Coda Titles. I discovered it first on Shining (in the Intermezzo BW Writing Titles) the on some movies at the final credits (bw). I post examples.

http://img135.imageshack.us/img135/6769/bug1cbu3.png

http://img222.imageshack.us/img222/1346/bug2cog3.png

Correct
http://img243.imageshack.us/img243/2782/correctce4.png

This happens starting from 994 (not included) to up (998 included).

buzzqw

27th October 2008, 15:12

@3ngel

same script and filters?

BHH

3ngel

27th October 2008, 15:21

Dark Shikari

27th October 2008, 19:08

Yes, obviously identical.
The only difference is that the last one (correct) is done with the 994.
I can add that the corrupted pixel is not continous but it's flashing. Prev frame correct, next corrupted, next correct.Let me guess, the problem goes away when you update to the latest libavcodec or use any other decoder?

3ngel

27th October 2008, 19:40

Dark Shikari

27th October 2008, 20:30

Sorry bad guess. Tested with ffdshow, CoreAvc, Sonic, Mpc. Same results.

Moreover the abnormality is exactly repeteable whitin the same source. That is same script,
994 encoded -> ok
995 and up -> bug.Post a stream, bug reports are useless without an actual encoded sample.

And if 995 managed to cause a problem, then its GCC's fault, because the purpose of 995 was to add even more constraints to the inline assembler in the hope that GCC would stop breaking our code.

3ngel

27th October 2008, 20:34

Ok, as soon i'll post a stream piece.

3ngel

27th October 2008, 20:50

This is from the first pic "jiikine". Encoded with 998.

The bug is at 00:11

http://www.megaupload.com/?d=BQHJ7KU2

Dark Shikari

27th October 2008, 22:11

This is from the first pic "jiikine". Encoded with 998.

The bug is at 00:11

http://www.megaupload.com/?d=BQHJ7KU2
Are you sure you cut it correctly? That clip doesn't contain the name "Hubbs" in the credits, nor did I notice anything wrong with the video.

3ngel

27th October 2008, 22:31

The word is "jiikine" not "hubbs".

Anyway i post the frame from the stream so you can find it

http://img225.imageshack.us/img225/7370/snapshot200810272229042yh9.th.png (http://img225.imageshack.us/my.php?image=snapshot200810272229042yh9.png)http://img225.imageshack.us/images/thpix.gif (http://g.imageshack.us/thpix.php)

Dark Shikari

27th October 2008, 22:44

This is actually rather interesting... its a false skip. This shouldn't happen, especially in this kind of case. I'm going to guess what happened, since you said it began in revision 995, is that the encoder chose a direct macroblock with 8x8 transform, falsely identified all the quantized DCTs as empty, and so declared it a skip.

... any chance you can try a build compiled with a different version of gcc?

3ngel

27th October 2008, 22:53

I have downloaded the build from the official first page.
If you link me here the builds i can try, i will gladly do it.

Dark Shikari

27th October 2008, 22:59

I have downloaded the build from the official first page.
If you link me here the builds i can try, i will gladly do it.Look at the last couple pages of this thread; there are various other builds you can try. Also, could someone post a build with --disable-asm? If, when compiled with that, there are no problems, its yet another issue with that stupid array_non_zero code that keeps biting us in the ass.

LoRd_MuldeR

27th October 2008, 23:10

J_Darnley

27th October 2008, 23:13

Rev 999 with ./configure --disable-asm
http://users.telenet.be/darnley/x264/x264_r999_no-asm.7z

3ngel

27th October 2008, 23:35

Rev 999 with ./configure --disable-asm
http://users.telenet.be/darnley/x264/x264_r999_no-asm.7z

It seems that with this build the bug doesn't appear. I have done only a piece. Tomorrow i'll do the entire final credits to see if it appears.

3ngel

28th October 2008, 14:34

Here you go:
* http://www.mediafire.com/file/1zinvyjmzry/x264-r999-gcc432.zip
* http://www.mediafire.com/file/m0ymzojczi2/x264-r999-gcc432-noasm.zip
* http://www.mediafire.com/file/liimtvzy0yi/pthreadGC2.zip

I've done a complete encode with gcc432 and the bug appears.

I've done a partial encode with gcc432-noasm and the bug doesn't seem to appear. I'm doing a complete encode with this right now (i'll post as it finishes).

As a sidenote with the noasm there is a huge performance drop. In order of 3 fps (noasm) against 15fps (asm).

LoRd_MuldeR

28th October 2008, 14:37

As a sidenote with the noasm there is a huge performance drop. In order of 3 fps (noasm) against 15fps (asm).

What a surprise :D

3ngel

28th October 2008, 14:39

That's a shame because it seems that we have to sleep in front of the monitor to obtain a correct encode :D

lexor

28th October 2008, 15:27

That's a shame because it seems that we have to sleep in front of the monitor to obtain a correct encode :D
I've found that encoding is a lot like watching paint dry. It's boring, but if you don't watch it, it won't dry.

Still I'm surprised that the first compile you've tested (gcc 3.xx) and Lord's gcc4.3x builds break in the same way... usually you can never get gcc to do anything consistently in different versions.

3ngel

28th October 2008, 16:33

Finished the encode. Confirmed. With

http://www.mediafire.com/file/m0ymzo...c432-noasm.zip

The encode is bug free, while with the asm version the bug appears.

Can someone do a VC2008 asm/noasm compile builds so i can repeat and compare the test?

EDIT:
the first compile you've tested and Lord's gcc4.3x builds break in the same way
The first compile doesn't break as i said. Infact is noasm

Dark Shikari

28th October 2008, 16:40

Can someone do a VC2008 asm/noasm compile builds so i can repeat and compare the test?Not useful; everything except GCC won't even build the inline assembly.

Useful would be using other versions of GCC to try to spot which ones cause things to break. I use 3.4, so odds are no problems occur in such old versions.

3ngel

28th October 2008, 16:43

Not useful; everything except GCC won't even build the inline assembly.

I see.

Useful would be using other versions of GCC to try to spot which ones cause things to break.

Well, if someone can do these builds i'm here :)

LoRd_MuldeR

28th October 2008, 17:00

My builds posted above were built with MinGW/GCC v4.3.2 tdm-1 (SJLJ Unwinding).

You can find MinGW/GCC v3.4.6 builds on http://www.x264.nl/ for example...

3ngel

28th October 2008, 17:11

MinGW/GCC v4.3.2 tdm-1 (SJLJ Unwinding) -> Broken

I would prefer to download directly from a link instead of a dir in order to avoid i get a wrong version. So if you can link them here i think it would be better.

LoRd_MuldeR

28th October 2008, 17:14

MinGW/GCC v4.3.2 tdm-1 (SJLJ Unwinding) 4.3.2 -> Broken

Do the MinGW/GCC v3.4.6 builds work any better? :confused:

I would prefer to download directly from a link instead of a dir in order to avoid i get a wrong version. So if you can link them here i think it would be better.

I did so:

Here you go:
* http://www.mediafire.com/file/1zinvyjmzry/x264-r999-gcc432.zip
* http://www.mediafire.com/file/m0ymzojczi2/x264-r999-gcc432-noasm.zip
* http://www.mediafire.com/file/liimtvzy0yi/pthreadGC2.zip

The file names should be self-explaining...

3ngel

28th October 2008, 17:16

Do the MinGW/GCC v3.4.6 work any better?

If someone post a build link i can try.

The file names should be self-explaining...

Yes, infact up to now i've tested only yours with asm.

LoRd_MuldeR

28th October 2008, 17:22

If someone post a build link i can try.

I just did:
You can find MinGW/GCC v3.4.6 builds on http://www.x264.nl/ for example...

If you need a direct link, here you go:
http://mirror01.x264.nl/x264/revision999/x264.exe