Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 6th June 2008, 08:26   #381  |  Link
MasterNobody
Registered User
 
Join Date: Jul 2007
Posts: 552
Quote:
Originally Posted by Razorholt View Post
Thanks a lot MasterNobody!

I don't see me-prepass patch listed here. What is your opinion on this patch? Apparently it has been "fixed" but I don't know what that means since I can't test it.
I don't use me-prepass patch. As for the "fixed" than it stays here to indicate that this build didn't crash with multithreading on CPUs with SSE2 (my first build of 870 crashes due to the bug in x264_thread_pool patch, which I than fix).
MasterNobody is offline   Reply With Quote
Old 6th June 2008, 09:14   #382  |  Link
IgorC
Registered User
 
Join Date: Apr 2004
Posts: 1,315
Quote:
Originally Posted by wizboy11 View Post
me-prepass is only really worth it when using --me esa or higher. It's not even that useful, tesa is probably just better.
Speaking mostly of DVD resolution:
me-prepass + umh has higher metric increase and speed then tesa with or w/o merange 24. Visually I think also.
Even 3d pass has higher metric boost then tesa ( ~ 0.1 avisynth SSIM = ~ 1%. Maybe a bit less)
I know that metric isn't ideal indicator of quality but it's already very hard to see difference.
I prefer umh+prepass and maybe 3dpass. Practically the same quality and much higher speed.

Maybe tesa and merange 24 perform better on HD.
It's just my experience.

Last edited by IgorC; 6th June 2008 at 09:18.
IgorC is offline   Reply With Quote
Old 6th June 2008, 10:48   #383  |  Link
cyberbeing
Broadband Junkie
 
Join Date: Oct 2005
Posts: 1,859
That is pretty much what I have found as well for DVD resolution content using --me-prepass. I just did a test comparison earlier today with a crf 10 encode on a high motion scene and umh + me-prepass was 38% faster (19% slower than w/o me-prepass) and had about 0.5% lower bitrate than esa.

I also did a test with a crf 17 encode on a low motion scene and esa was 67% slower than umh + me-prepass and again the me-prepass encode had the lowest bitrate by a slight margin.

Overall, considering that the speed hit from me-prepass is so much less than esa and tesa, I don't see it as all that bad a thing if you want to push a bit of extra quality out of your encode but aren't patient enough for esa or tesa.
cyberbeing is offline   Reply With Quote
Old 6th June 2008, 11:20   #384  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,229
In reference to me-prepass, does x264 normally do a hpel search on a frame, and if so are the results from the me-prepass recycled (if they can be)? I'm assuming there may be elements of the frame encoded that has had me-prepass over it that no longer require any ME, so are those elements skipped when me-prepass is enabled?
burfadel is offline   Reply With Quote
Old 6th June 2008, 14:52   #385  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,666
Quote:
Originally Posted by burfadel View Post
In reference to me-prepass, does x264 normally do a hpel search on a frame, and if so are the results from the me-prepass recycled (if they can be)? I'm assuming there may be elements of the frame encoded that has had me-prepass over it that no longer require any ME, so are those elements skipped when me-prepass is enabled?
ME-prepass is just a simple ugly hack to do tons of hex searches. Its not particularly pretty or efficient.
Dark Shikari is offline   Reply With Quote
Old 8th June 2008, 06:32   #386  |  Link
TheRyuu
warpsharpened
 
Join Date: Feb 2007
Posts: 787
x264.877.modified.exe
(alt DL link)

Patches:
x264_hrd_pulldown.04_interlace.diff
x264_progress.diff
x264_psyRDO_0.22.diff
x264_me-prepass_updated.02.diff <---nothing more then a compatibility update to make it compatible with psyRDO patch.

Notes:
Few git commits fix up some asm coding. Also a slight speedup in trellis. See x264 GIT for more details

x264_me-prepass_updated.02.diff
use the --me-prepass flag to activate the half pel search. Improves quality using any --me mode but isn't really worth it until you get up to --me esa. Isn't really worth it since --me tesa will provide better motion searching. But since it has a flag and it's default is off I include it.

x264_psyRDO_02.diff:
see thread
Option: --rdcmp
Usage:
--rdcmp psy (psy rdo)
--rdcmp ssd (regular)
Psy RDO is on by default at subme levels 6 and 7. 7 + b-rdo is best.
Read psyRDO thread for more info regarding it.

x264_progress.diff:
Adds a little progress thingy at the top of the x264 window. Neat feature.
TheRyuu is offline   Reply With Quote
Old 8th June 2008, 11:13   #387  |  Link
techouse
Strictly Rhythm
 
techouse's Avatar
 
Join Date: Jul 2007
Location: Ljubljana, Slovenia
Posts: 166
x264_x86_r877_techouse

Code:
Source: x264 r877 GIT (git://git.videolan.org/x264.git)

Applied patches (current versions):

x264_hrd_pulldown.04_interlace.diff

x264_me-prepass_DeathTheSheep_techouse_fix.diff

x264_progress.diff

x264_psy_rdo_0.22.diff


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

Compiled by techouse on June 8th 2008, 11:55:51 CEST with GCC-4.3.0 on Windows Vista Ultimate SP-1 32-bit.

Commandline used: ./configure&&make fprofiled

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

Code:
Source: x264 r877 GIT (git://git.videolan.org/x264.git)

Applied patches (current versions):

x264_FGO_techouse_fix.diff

x264_hrd_pulldown.04_interlace.diff

x264_me-prepass_DeathTheSheep.diff

x264_progress.diff


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

Compiled by techouse on June 8th 2008, 13:21:54 CEST with GCC-4.3.0 on Windows Vista Ultimate SP-1 32-bit.

Commandline used: ./configure&&make fprofiled

Platform: X86
System: MINGW
avis input: yes
mp4 output: yes
pthread: yes
gtk: no
debug: no
gprof: no
PIC: no
shared: no
visualize: no
I built both cause some of you still prefer testing which perform better.

Enjoy
__________________

Last edited by techouse; 8th June 2008 at 12:31.
techouse is offline   Reply With Quote
Old 9th June 2008, 09:56   #388  |  Link
MythCreator
Registered User
 
Join Date: Dec 2007
Location: Beijing,China
Posts: 92
For my experience,Psy RDO just make more block than ssd in low and ultra low bitrate,Would Dark Shikari do some work to improve that?
MythCreator is offline   Reply With Quote
Old 9th June 2008, 10:00   #389  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,666
Quote:
Originally Posted by MythCreator View Post
For my experience,Psy RDO just make more block than ssd in low and ultra low bitrate,Would Dark Shikari do some work to improve that?
I can't do anything unless you give me a specific example of what you're talking about. And by a specific example I mean two .h264 files, one with psy and one without, at the same bitrate.
Dark Shikari is offline   Reply With Quote
Old 9th June 2008, 12:39   #390  |  Link
MythCreator
Registered User
 
Join Date: Dec 2007
Location: Beijing,China
Posts: 92
@Dark Shikari:Well , I will do that some days later, I just del the source..
@techouse:You don't have a yasm.exe at your /MinGW/bin ? I just noticed that your build have no optimization to SSE/SSE2 and others

Last edited by MythCreator; 9th June 2008 at 12:43.
MythCreator is offline   Reply With Quote
Old 9th June 2008, 12:49   #391  |  Link
techouse
Strictly Rhythm
 
techouse's Avatar
 
Join Date: Jul 2007
Location: Ljubljana, Slovenia
Posts: 166
Quote:
Originally Posted by MythCreator View Post
@Dark Shikari:Well , I will do that some days later, I just del the source..
@techouse:You don't have a yasm.exe at your /MinGW/bin ? I just noticed that your build have no optimization to SSE/SSE2 and others
http://git.videolan.org/?p=x264.git;...5733dab31b5a41

Quote:
many changes to which asm functions are enabled on which cpus.

with Phenom, 3dnow is no longer equivalent to "sse2 is slow", so make a new flag for that.

some sse2 functions are useful only on Core2 and Phenom, so make a "sse2 is fast" flag for that.

some ssse3 instructions didn't become useful until Penryn, so yet another flag.

disable sse2 completely on Pentium M and Core1, because it's uniformly slower than mmx.

enable some sse2 functions on Athlon64 that always were faster and we just didn't notice.

remove mc_luma_sse3, because the only cpu that has lddqu (namely Pentium 4D) doesn't have "sse2 is fast".

don't print mmx1, sse1, nor 3dnow in the detected cpuflags, since we don't really have any such functions. likewise don't print sse3 unless it's used (Pentium 4D).
And I have nasm.exe and yasm.exe in my C:\MingGW\bin folder
__________________
techouse is offline   Reply With Quote
Old 9th June 2008, 14:08   #392  |  Link
MythCreator
Registered User
 
Join Date: Dec 2007
Location: Beijing,China
Posts: 92
Quote:
Originally Posted by techouse View Post
http://git.videolan.org/?p=x264.git;...5733dab31b5a41



And I have nasm.exe and yasm.exe in my C:\MingGW\bin folder

Ah , sorry and thanks~
MythCreator is offline   Reply With Quote
Old 11th June 2008, 10:05   #393  |  Link
bob0r
Pain and suffering
 
bob0r's Avatar
 
Join Date: Jul 2002
Posts: 1,337
x264.880.modified.01.exe
x264.880.modified.01.source.zip

x264.psyRDO.0.22.diff
http://forum.doom9.org/showthread.php?t=138293
x264_hrd_pulldown.04_interlace.diff
HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.ph...19#post1047919
x264.progress.indication.01.diff
http://forum.doom9.org/showthread.php?t=135905

Link to x264 patches collected: http://files.x264.nl/x264_patches/

Here is the output of the patching process:
http://files.x264.nl/x264.880.modified.01.patch.out.txt

Here is the output of the compiling process:
http://files.x264.nl/x264.880.modifi...ofiled.out.txt


gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-generate -c -o encoder/set.o encoder/set.c
encoder/set.c: In function `x264_sps_init':
encoder/set.c:215: warning: unused variable `cpbBrVclFactor'

gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-use -c -o encoder/encoder.o encoder/encoder.c
encoder/encoder.c: In function `x264_encoder_encode':
encoder/encoder.c:1278: warning: 'cpb_removal_delay' might be used uninitialized in this function


darkorange = x264_hrd_pulldown.04_interlace.diff

The warnings that are not in the GIT code are highlighted with a color, and should not be there.
(The GIT warnings are there because of a bug in Windows, they prevent the usage of extended zones, example: x264 --zones 1,100,bframes=0)
The GIT warnings:

gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-generate -c -o common/common.o common/common.c
common/common.c: In function `x264_param_parse':
common/common.c:252: warning: unused variable `saveptr'

gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-generate -c -o encoder/ratecontrol.o encoder/ratecontrol.c
encoder/ratecontrol.c: In function `parse_zone':
encoder/ratecontrol.c:564: warning: unused variable `saveptr'
encoder/ratecontrol.c: In function `parse_zones':
encoder/ratecontrol.c:607: warning: unused variable `saveptr'
bob0r is offline   Reply With Quote
Old 13th June 2008, 04:39   #394  |  Link
TheRyuu
warpsharpened
 
Join Date: Feb 2007
Posts: 787
x264.883.modified.exe
x264.833.modified.source.rar

Patches:
x264_progress.diff
x264_hrd_pulldown.04_interlace.diff
x264_psyRDO_0.22.diff

Notes:
Removed me-prepass due to incompatibility (only really useful on esa anyway, and going to tesa would probably be more beneficial then using me-prepass)

Other then that, not much to report this week. As always, notes on additional options added through the psyRDO patch:
x264_psyRDO_02.diff:
see thread
Option: --rdcmp
Usage:
--rdcmp psy (psy rdo)
--rdcmp ssd (regular)
Psy RDO is on by default at subme levels 6 and 7. 7 + b-rdo is best.
Read psyRDO thread for more info regarding it.

Last edited by TheRyuu; 13th June 2008 at 04:42.
TheRyuu is offline   Reply With Quote
Old 13th June 2008, 17:00   #395  |  Link
Ranguvar
Registered User
 
Ranguvar's Avatar
 
Join Date: Feb 2007
Location: ::1
Posts: 1,236
Thanks, Dragon! Been waiting for an 883 build, especially without me-prepass. Hey, is it possible for someone to make a build where this can be disabled/enabled through the CLI?

Thanks again!
Ranguvar is offline   Reply With Quote
Old 13th June 2008, 17:23   #396  |  Link
Wishbringer
Silent Reader
 
Wishbringer's Avatar
 
Join Date: Dec 2003
Location: Germany
Posts: 295
Quote:
Originally Posted by Ranguvar View Post
is it possible for someone to make a build where this can be disabled/enabled through the CLI?
Wasn't ME-Prepass enabled by "--me-prepass" in commandline and otherwise disabled?!
Wishbringer is offline   Reply With Quote
Old 13th June 2008, 17:45   #397  |  Link
survivant001
Registered User
 
Join Date: Nov 2007
Posts: 449
Quote:
Originally Posted by Wishbringer View Post
Wasn't ME-Prepass enabled by "--me-prepass" in commandline and otherwise disabled?!
yep.. he is just confused.
survivant001 is offline   Reply With Quote
Old 13th June 2008, 21:35   #398  |  Link
TheRyuu
warpsharpened
 
Join Date: Feb 2007
Posts: 787
Quote:
Originally Posted by Ranguvar View Post
Thanks, Dragon! Been waiting for an 883 build, especially without me-prepass. Hey, is it possible for someone to make a build where this can be disabled/enabled through the CLI?

Thanks again!
I make notes for a reason.
Quote:
Removed me-prepass due to incompatibility (only really useful on esa anyway, and going to tesa would probably be more beneficial then using me-prepass)
I believe the type of loop used in me.c was changed and is the cause for the incompatibility. However I'm not about to go and try and hack it together for something that probably a.) won't work and b.) isn't really worth the effort.
TheRyuu is offline   Reply With Quote
Old 14th June 2008, 03:27   #399  |  Link
Ranguvar
Registered User
 
Ranguvar's Avatar
 
Join Date: Feb 2007
Location: ::1
Posts: 1,236
'Apologies'... I did read the notes, I just didn't know that me-prepass was already triggered by a switch.
Ranguvar is offline   Reply With Quote
Old 16th June 2008, 03:51   #400  |  Link
TheRyuu
warpsharpened
 
Join Date: Feb 2007
Posts: 787
x264.886.modified.exe
x264.886.modified.source.rar

Patches:
x264_progress.diff
x264_hrd_pulldown.04_interlace.diff
x264_psyRDO_0.22.diff

Notes:
Nothing new other then a few git commits (speed things up slightly cause GCC is a dumb-ass at unrolling loops (and some inline stuff I don't understand), at least I think that's what the commits do )

As always, additional options added by the patches:
x264_psyRDO_02.diff:
see thread
Option: --rdcmp
Usage:
--rdcmp psy (psy rdo)
--rdcmp ssd (regular)
Psy RDO is on by default at subme levels 6 and 7. 7 + b-rdo is best.
Read psyRDO thread for more info regarding it.
TheRyuu is offline   Reply With Quote
Reply

Tags
h.264, x264, x264 builds, x264 patches, x264 unofficial builds

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 14:37.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.