-bime in x264

[JoeBG]

Hi all,

what does this function do exactly, what is "bidirectional motion refinement"?
How should I use it?

[buzzqw]

i can just add that if used it MUST be used for both pass not only for second

BHH

[Sirber]

I'd like to know too, I wanna add it :(

What's the quality gain?
WHat's the speed loss?

[Manao]

I can just add that if used it MUST be used for both pass not only for secondAnything to back that up ? Because I highly doubt so. It'll slightly improve the efficiency of bframes, but not so much as to wildly change the bframe insertion algorithm.
what does this function do exactly, what is "bidirectional motion refinement"?In bframes, you have roughly 4 encoding modes possible per macroblock :
direct/skip, which is the most efficient and don't need to code a motion vector ( though in the end construct automatically two motion vectors )
forward, which uses one motion vector, pointing toward the past reference
backward, which uses one motion vector, pointing toward the future reference
bidirectionnal, which uses two motion vectors

At the moment, when searching for the two motion vectors, x264 was only doing a monodirectionnal search ( one forward, and one backward ), and tested only the bidirectionnal mode formed by the best two vectors found. While most of the time, this two vectors are indeed the best possible vectors, it happens ( more often than not in fact ) that two different vectors would have yield better results. Bidirectionnal ME means that an additionnal vectors' search is done, this time both forward and backward.

It will greatly improve the bidirectionnal mode, but won't change the efficiency of the other modes, especially the most used one, the direct / skips.

The quality gain may highly depends on the content. For the moment, the only figures I saw were a bit disappointing ( 0.01 dB gain ). For speed, I don't know how much it'll slow down, but I guess you can test for yourself.

[JoeBG]

It will greatly improve the bidirectionnal mode, but won't change the efficiency of the other modes, especially the most used one, the direct / skips.


What commandline would you suggest?

[Manao]

Just add --bime with the usual command line you're usually using ( provided that the command line does enable bframes ).

[buzzqw]

first pass
x264.exe --pass 1 --bitrate 853 --stats c:\stats --ref 5 --mixed-refs --bframes 3 --b-pyramid --subme 6 --b-rdo --weightb --trellis 1 --analyse all --8x8dct --sar 2304:2160 --progress --no-psnr --output "E:\test\movie.mp4" "E:\test\time.avs"

second pass
x264.exe --pass 2 --bitrate 853 --stats c:\stats --ref 5 --mixed-refs --bframes 3 -bime --b-pyramid --subme 6 --b-rdo --weightb --trellis 1 --analyse all --8x8dct --sar 2304:2160 --progress --no-psnr --output "E:\test\movie.mp4" "E:\test\time.avs"

]error (http://img525.imageshack.us/img525/3081/bime7dn.jpg)
Thanks to ImageShack for Free Image Hosting (http://imageshack.us)

x264 build 389M

BHH

[omion]

@buzzqw:
Try with two dashes in front of "bime" ;)

[buzzqw]

emh... i am not so dump :cool:

with two dashes (--) i got a a nice "unknow option" !

link http://img525.imageshack.us/img525/6627/bime20ul.jpg (http://imageshack.us)
Thanks to ImageShack for Free Image Hosting (http://imageshack.us)


BHH

[buzzqw]

OK !!!

with build 391 the option is --bime

but for me encoder this version (391) is broken... (http://forum.doom9.org/showthread.php?p=759617#post759617)

BHH

[Sharktooth]

Blame GPAC... 391A is coming...

[sysKin]

The quality gain may highly depends on the content. For the moment, the only figures I saw were a bit disappointing ( 0.01 dB gain ). For speed, I don't know how much it'll slow down, but I guess you can test for yourself.
Which is funny, because when I tried to remove or limit "bime" in XviD (for Turbo option) the loss was amazingly high - 0.1dB from just limiting it, more from disabling completely (okay I don't remember the exact numbers but in the end, Turbo hardly affects XviD's bime).

[buzzqw]

just to note that in rev 391A --bime could be omissed in first pass

BHH

[Manao]

Here's the explanation given by akupenguin : the option to enable bime has always been --bime. when you used -bime instead, it was interpreted by the command line as -b0, explaining why x264 complained in the second pass

[virus]

when I tried to remove or limit "bime" in XviD (for Turbo option) the loss was amazingly high - 0.1dB from just limiting it, more from disabling completely (okay I don't remember the exact numbers but in the end, Turbo hardly affects XviD's bime).
as I understand it, aku has chosen a "fast" implementation that doesn't almost modify speed but yields no more than 0.01-0.02 dB. According to AlexW, it may be slowed down and become maybe a little bit more efficient. He also said that on JM bidirectional ME brings ~0.1 dB iirc. I guess the exact amount also depends on how much the content is "bframe-friendly".

[Sharktooth]

So is it safe to remove --bime in the x264 Fast 1st Pass (or Turbo...)?

EDIT: found the answer on irc :)

[easyfab]

EDIT: found the answer on irc :)

And ...

could we or not ?

[Sharktooth]

sorry, yes it can be removed. i made that change into megui too.