Quote:
Originally Posted by Iron_Mike
...it is the x265 KEYFRAMES parameter that creates an encode that will throw off seekmode...
|
Quote:
Originally Posted by WorBry
...Nor have I run any tests with x265 encoded with custom key frame and rc-lookahead settings, because I have no interest in doing so
|
Well I have now the run tests with x265 CRF28 encoded with custom key frame interval, exactly as per your script:
Code:
<ffmpeg path> -i "/path/to/crowd_run_1080p50.y4m" -c:v libx265 -preset slow -crf 28 -pix_fmt yuv420p -x265-params "keyint=100:min-keyint=100:colorprim=1:transfer=1:colormatrix=1" -r 50/1 "/path/to/encode.mp4"
And these are the results I get on serial testing with SSIM:GMSD (Downsample=False):
Code:
LWLibavSource:
stop 435.99385609567906 83.19534706841786
stop 435.99385609567906 83.19534706841786
stop 435.99385609567906 83.19534706841786
stop 435.99385609567906 83.19534706841786
stop 435.99385609567906 83.19534706841786
ffms2- Wolfberry (default, i.e. seekmode=1)
stop 435.99385609567906 83.19534706841786
stop 435.99385609567906 83.19534706841786
stop 435.99385609567906 83.19534706841786
stop 435.99385609567906 83.19534706841786
stop 435.99385609567906 83.19534706841786
No inconsistencies at all. And the same results regardless of whether the ffindex and lwi files from the first test in each series were retained or a fresh index file was generated for each test.
Compare that to your results.
Quote:
Originally Posted by Iron_Mike
(3) encode w/ keyint, min-keyint but w/o rc-lookahead:
--> wanted to see if it is specifically the rc-lookahead setting that causes the issues w/ seekmode=1
ffmpeg command
Code:
<ffmpeg path> -i "/path/to/crowd_run_1080p50.y4m" -c:v libx265 -preset slow -crf 28 -pix_fmt yuv420p -x265-params "keyint=100:min-keyint=100:colorprim=1:transfer=1:colormatrix=1" -r 50/1 "/path/to/encode.mp4"
Code:
Lsmash:
stop 83.19534706841786 435.99382191599165
stop 83.19534706841786 435.99382191599165
stop 83.19534706841786 435.99382191599165
stop 83.19534706841786 435.99382191599165
stop 83.19534706841786 435.99382191599165
Code:
FFMS2 (Wolfberry) - seekmode=0:
stop 83.19534706841786 435.99382191599165
stop 83.19534706841786 435.99382191599165
stop 83.19534706841786 435.99382191599165
stop 83.19534706841786 435.99382191599165
stop 83.19534706841787 435.99382191599165
Code:
FFMS2 (Wolfberry) - seekmode=1 (default):
stop 108.17858520287257 307.76386120454794
stop 124.03602892099701 228.48869961962274
stop 83.19534706841786 435.99382191599165
stop 122.13314288222833 236.93921207380862
stop 123.97733586255691 229.28604315863697
|
Also, as before, I extracted the log file data into LibreOffice Calc to run difference checks on the per-frame scores and I could find zero differences at all between the serial tests and between the LWLibavSource and ffms2 test series. And the frames were listed in correct sequence (0-499) in the log files.
Go figure.