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. |
29th June 2005, 23:48 | #1 | Link |
retired developer
Join Date: Oct 2002
Location: Canada
Posts: 8,978
|
x264 Maximum motion vector search range
What is it's minimum and maximum?
__________________
Detritus Software |
30th June 2005, 06:31 | #2 | Link |
Registered User
Join Date: Jan 2002
Location: France
Posts: 2,856
|
Sensible values ? No check is done in x264 itself, but some arrays' sizes depend on this value. In 'esa' me mode, a too high value will make the encoding too slow to be useful.
Looking at the code, if it's strictly under 16, it will b0rk ( the encoding process will occur, but don't expect anything good nor sensible from the result ) So, all in one, i'd say 16 - 64 are fairly sensible values. |
30th June 2005, 13:30 | #4 | Link |
retired developer
Join Date: Oct 2002
Location: Canada
Posts: 8,978
|
Ok. I will force between 16 and 64.
Would 64 be a good default in umh mode?
__________________
Detritus Software |
30th June 2005, 13:51 | #5 | Link |
Mr. Sandman
Join Date: Sep 2003
Location: Haddonfield, IL
Posts: 11,768
|
16 is enaugh 99.9% of the times.
__________________
MPEG-4 ASP Custom Matrices: EQM V1(old), EQM AutoGK Sharpmatrix (aka EQM V2), EQM V3HR (updated 01/10/2004), EQM V3LR, EQM V3ULR (updated 04/02/2005), EQM V3UHR (updated 17/12/2004) and EQM V3EHR (updated 05/10/2004) Info about my ASP matrices. MPEG-4 AVC Custom Matrices: EQM AVC-HR Info about my AVC matrices My x264 builds. Mooo!!! |
4th July 2005, 03:05 | #6 | Link |
retired developer
Join Date: Oct 2002
Location: Canada
Posts: 8,978
|
I tested 32 and 64. They aren't slower. I'm defaulting to 64.
__________________
Detritus Software |
4th July 2005, 12:47 | #7 | Link |
Mr. Sandman
Join Date: Sep 2003
Location: Haddonfield, IL
Posts: 11,768
|
are you sure?!?
__________________
MPEG-4 ASP Custom Matrices: EQM V1(old), EQM AutoGK Sharpmatrix (aka EQM V2), EQM V3HR (updated 01/10/2004), EQM V3LR, EQM V3ULR (updated 04/02/2005), EQM V3UHR (updated 17/12/2004) and EQM V3EHR (updated 05/10/2004) Info about my ASP matrices. MPEG-4 AVC Custom Matrices: EQM AVC-HR Info about my AVC matrices My x264 builds. Mooo!!! |
4th July 2005, 12:49 | #8 | Link |
retired developer
Join Date: Oct 2002
Location: Canada
Posts: 8,978
|
on my 500 frame test, using 16, 32 and 64 took the same 4 minutes.
__________________
Detritus Software |
4th July 2005, 12:55 | #9 | Link |
Registered User
Join Date: Apr 2004
Location: Kalamazoo
Posts: 13
|
I just started messing with the motion vector too, and have tryed 32/64 with umh on a couple of videos and im getting about the same fps for encoding as I would with the default 16, if I understand what everyone is talking about.
|
4th July 2005, 13:05 | #11 | Link |
retired developer
Join Date: Oct 2002
Location: Canada
Posts: 8,978
|
using --me umh. I know esa bring everything speed down
@allclone Exactly what we are talking about
__________________
Detritus Software |
4th July 2005, 13:18 | #12 | Link |
Registered User
Join Date: Jan 2002
Location: France
Posts: 2,856
|
Sirber : i meant that merange effect can be easily noticed with esa, whereas with umh & dia, it can't ( because in these case it's the max number of iterations, and the average number of iteration must be around 5 or 6 ). You would notice it if you set it to 4 or 5.
|
4th July 2005, 13:20 | #13 | Link |
retired developer
Join Date: Oct 2002
Location: Canada
Posts: 8,978
|
ok. But, not noticing it in dia and umh is great isn't it? Means we can use it!!!
__________________
Detritus Software |
4th July 2005, 16:26 | #15 | Link |
x264 developer
Join Date: Sep 2004
Posts: 2,392
|
Code:
x264 foo_640x368.yuv -r 3 -b 3 --me hex --merange 16 x264 [info]: PSNR Mean Y:42.25 U:46.88 V:47.53 Avg:43.35 Global:42.99 kb/s:805.9 encoded 1000 frames, 13.28 fps, 806.13 kb/s x264 foo_640x368.yuv -r 3 -b 3 --me umh --merange 16 x264 [info]: PSNR Mean Y:42.24 U:46.86 V:47.51 Avg:43.34 Global:42.98 kb/s:797.4 encoded 1000 frames, 9.37 fps, 797.59 kb/s x264 foo_640x368.yuv -r 3 -b 3 --me umh --merange 32 x264 [info]: PSNR Mean Y:42.24 U:46.85 V:47.50 Avg:43.33 Global:42.98 kb/s:795.9 encoded 1000 frames, 8.00 fps, 796.12 kb/s x264 foo_640x368.yuv -r 3 -b 3 --me umh --merange 64 x264 [info]: PSNR Mean Y:42.23 U:46.84 V:47.48 Avg:43.32 Global:42.97 kb/s:796.3 encoded 1000 frames, 5.75 fps, 796.46 kb/s ... And dia and hex cap merange at 16. It slightly reduces code complexity, and if the real mv is more than 16 pixels from the prediction, they won't find it anyway. |
4th July 2005, 16:52 | #16 | Link |
retired developer
Join Date: Oct 2002
Location: Canada
Posts: 8,978
|
hum... odd... I'll retest.
__________________
Detritus Software |
4th July 2005, 17:00 | #17 | Link |
clueless n00b
Join Date: Oct 2001
Location: somewhere over the rainbow
Posts: 10,579
|
so going above 32 only yields lower speed, lower psnr and higher bitrate.. not a pleasant thing.
I have one thing on the stats: line 2 out of 3 shows a different bitrate than line 3 out of 3.. why that difference?
__________________
For the web's most comprehensive collection of DVD backup guides go to www.doom9.org |
13th August 2005, 18:01 | #19 | Link | |
<The VFW Sheep of Death>
Join Date: Dec 2004
Location: Deathly pasture of VFW
Posts: 1,149
|
Quote:
Because I am certain of my convictions, I picked an entirely random animation sample on my computer to test. It consists of 3306 frames of anime at about 12fps. I encoded at quant=36. I will host the result files shortly. My results (range 64 vs. range 32): 1. Filesize was smaller (1,231,862 vs 1,234,412) 2. PSNR was very slightly higher (31.24 vs 31.23) 3. Encoding time was a bit longer (6:21 vs 5:10). Output files will be here when available: http://farmz.net/xsquared/ME32.avi http://farmz.net/xsquared/ME64.avi Cleary, this was not a sample indicative of the true potential of UMH_ME64, but it was a random sample designed all the same to show that different content (and different tests ) can yield different results. Likewise, encoding speed varies based on the complexity of the source material. Still scenes go equally fast, but the more complex and erratic the motion becomes, the more the higher ranges show slowdown. Additionally, UMH in and of itself isn't the best way to test ME range efficiency. The only certain way is an exhaustive search, which I am currently in the process of performing on the same clip for comparison purposes. DTS
__________________
Recommended all-in-one stop for x264/GCC needs on Windows: Komisar x264 builds! Last edited by DeathTheSheep; 13th August 2005 at 18:48. |
|
28th November 2005, 19:33 | #20 | Link |
Registered User
Join Date: Jan 2005
Location: Praha (not that one in Texas)
Posts: 863
|
I have one question concerning ME impact on Bframes:
I have seen examples and recommendations to make 1st pass with lower quallity ME to save the time. Please tell me what if some of following is incorrect. 1. Base of B-frames is good references to the other frames. If there is not possible good reference, encoder decides not to make Bframe and writes this decission to statsfile 2. In second pass it is not possible to change this "decission" Conclusion: Reducing ME in 1st pass decreases the quality of the second pass which can't be fully recovered even with ESA. Just to understand how x264 works. |
Thread Tools | Search this Thread |
Display Modes | |
|
|