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. |
7th July 2014, 10:02 | #1 | Link |
Registered User
Join Date: Sep 2013
Posts: 38
|
Why the two execution of X264 are different?
I am using the following commands to run the X264 under multithreads for MB-TREE algorithm:
./x264 -b 0 --threads 4 --lookahead-threads 1 --rc-lookahead 10 --aq-mode 1 -o test.264 ~/sequences/bus_352x288_25.yuv --fps 25 --frames -1 -I 30 -B 500 --b-adapt 0 --b-pyramid none --ref 5 --weightp 0 --no-scenecut -v --tune psnr --psnr --no-psy --no-asm >a.txt 2>&1 However, each time the result is different. How could that be possible? |
7th July 2014, 12:08 | #2 | Link |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
What exactly do you mean with "the result is different"?
File hashes don't match? Files come out at different size? Files actually look different? Anyway, as far as I remember, x264 is supposed to be deterministic (i.e. always gives the same result for the same input), unless you either specify "--non-deterministic" or use VBV. So if you think you found a case where x264 is not deterministic, you should probably file a bug report. But, first of all, track down the particular option that causes this!
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 7th July 2014 at 14:49. |
7th July 2014, 21:23 | #4 | Link | ||
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
At least that's how it's supposed to work Quote:
http://mewiki.project357.com/wiki/X2...-deterministic The major exception here is VBV – which, according to the developers, is inherently non-determinsitc. But he didn't use VBV, so that can't be the reason.
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 7th July 2014 at 21:36. |
||
8th July 2014, 02:05 | #5 | Link | |
Registered User
Join Date: Sep 2013
Posts: 38
|
Quote:
I have found the reason. In my running of X264, multithreads and MB-TREE are enabled. When thread number is larger than 1, two more threads will be created, which are the IOThread and a LookaheadThread. When the IOThread and the MainThread run faster than LookaheadThread, much more frames will be put in the lookahead->ifbuf. So the frame number in lookahead->next will be larger than the number decided in the command line(--rc-lookahead) and this makes the MB-TREE analyse more frames and the QP offsets will be different. BTW, the default value of b_determinstic in my codes is changed to 0, so the results are different. When the b_determinstic is set to 1, the results are the same. The results, I mean, the final PSNR values and bitrate. |
|
8th July 2014, 12:05 | #7 | Link |
Registered User
Join Date: Sep 2013
Posts: 38
|
At first, I didn't know it was changed. The x264 source I used is a project transplanted to Windows (a version in 2012) by others. Then through this Post, I realised the variable b_deterministic and found it was changed in the x264_param_default function.
|
Tags |
x264 |
|
|