x264 brdo woes: bug or pathological case?

[Sharktooth]

Cef's 667b sources already include AQ...

[SpAwN_gUy]

Cef's 667b sources already include AQ...Well... i DO know that.. but i can't build... 'kay this is not the proper thread..

i just asked him to update .diff for aq-patch ... 'cause on your site it is very old and does not include latest changes from somwhere here...

[plane]

It's a DVD, and 2.4 DAR at that. It isn't even 512 pixels tall. The vertical mv limit thing only matters for HD.

I have some stupid questions to ask. I don't know what is vertical motion vectors, is that related to the vertical resolution? I usually use x264 to encode my PAL DV clips, which is 576 pixels tall? It seems this change is good to use but will there be any potential negative impact by limiting the vertical motion vectors to +/-512?

[RaynQuist]

That only matters if you have something that moves more than 512 pixels up or down the screen from one frame to the next, which is unlikely to happen especially for SD sources. Usually for SD sources you should limit your search range to well under 512, like 16~32. It won't hurt compressibility to have more than that, it's just diminishing returns.

[Dark Shikari]

That only matters if you have something that moves more than 512 pixels up or down the screen from one frame to the next, which is unlikely to happen especially for SD sources. Usually for SD sources you should limit your search range to well under 512, like 16~32. It won't hurt compressibility to have more than that, it's just diminishing returns.
And isn't it basically impossible for the encoder to find such motion anyways, especially with the default motion search radius of... 16?

[Manao]

This has been explained over and over again :
- merange sets the search radius around the best candidate. ie, with a merange of 16, if a neighbouring macroblock has a motion vector of (x,y), you can reach from (x-16,y-16) to (x+16,y+16). It adds up.
- mvrange limits the actual vector's length

Furthermore, there's no diminishing returns for merange over 16, except with esa which you shouldn't use anyway. By that, I mean that except for esa, you can use as big a merange as you want, it doesn't actually matter for neither speed nor quality. So it's best to leave it untouched.

[Dark Shikari]

By that, I mean that except for esa, you can use as big a merange as you want, it doesn't actually matter for neither speed nor quality.
Yeah, right. :rolleyes:

--subme 7, --trellis 2, --me umh, --ref 16, --no-fast-pskip and other standard settings on 40,000 frames of a DVD:

--merange 64: 2.45 FPS
--merange 32: 3.5 FPS
--merange 16: 4.26 FPS

[Terranigma]

Shikari, have you seen neuron2's in-depth .pdf document (http://www.neuron2.net/library/avc/overview_x264_v8_5.pdf) about motion estimation (2.2)?

Doesn't get more thorough than that.

[Dark Shikari]

Shikari, have you seen neuron2's in-depth .pdf document (http://www.neuron2.net/library/avc/overview_x264_v8_5.pdf) about motion estimation (2.2)?

Doesn't get more thorough than that.
I just read it and most of it I already knew from looking at the code, but it makes sense.

I know exactly why high --merange slows it down though; there are plenty of for loops with merange as the primary maximum variable, so doubling merange results in those for loops running more times.

[foxyshadis]

Those for loops have break;s though, for when the ME reaches what it believes is the global minimum. Your content must confuse the ME. =p

I just tested a few scenes, one cake, one moderate, one hard. 1: Speed dropped (15->13->10), SSIM went up minutely, no effect on bitrate or PSNR. 2: Steady speed drop (13->11->9), no effect on SSIM, PSNR, or bitrate. 3: Again, steady but not horrible speed drop (8->6.5->5), no effect on SSIM, bitrate dropped marginally, PSNR dropped marginally.

Overall impression: Worthless. :p

Oops, that was tested on the SSIM-SAD optimized; however, testing with the original shows virtually identical behavior. (And better SSIM/bitrate tradeoff than the optimized, again, though it's a totally different type of source, anime/cg this time.)

Command line:
--crf 22.0 --keyint 400 --ref 6 --mixed-refs --no-fast-pskip --bframes 5 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -1,0 --subme 6 --trellis 2 --analyse all --8x8dct --vbv-maxrate 25000 --me umh --threads auto --thread-input --progress --no-dct-decimate --output "V:\video\DVDRIP\Rozen Maiden 1\cossette-fast.mkv" "V:\video\DVDRIP\Rozen Maiden 1\cossette-fast.avs" --aq-strength 0.3

[Manao]

I wasn't aware that umh ended with an exhaustive hex search. So indeed umh slows down with merange, but the quality doesn't need anything bigger that 16.

hex & dia aren't affected by big merange however, because though there's a loop based on merange, there's only an exit to that loop.

[Dark Shikari]

Command line:
--crf 22.0 --keyint 400 --ref 6 --mixed-refs --no-fast-pskip --bframes 5 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -1,0 --subme 6 --trellis 2 --analyse all --8x8dct --vbv-maxrate 25000 --me umh --threads auto --thread-input --progress --no-dct-decimate --output "V:\video\DVDRIP\Rozen Maiden 1\cossette-fast.mkv" "V:\video\DVDRIP\Rozen Maiden 1\cossette-fast.avs" --aq-strength 0.3
Rozen Maiden ftw :cool: