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.

 

Go Back   Doom9's Forum > Capturing and Editing Video > VapourSynth

Reply
 
Thread Tools Search this Thread Display Modes
Old Today, 14:14   #141  |  Link
WorBry
Registered User
 
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,097
Quote:
Originally Posted by ChaosKing View Post
But have you also used the fmpeg Zeranoe 20190312-d227ed5 build?
It's the other way round. He used Zeranoe 20190312-d227ed5 to replicate my test procedure:

https://forum.doom9.org/showthread.p...94#post1869094

Quote:
Originally Posted by Iron_Mike View Post
As a test to match WorBrys results, I made two encodes - in both cases I used the same source (crowdrun 1080p50), the same ffmpeg Zeranoe build, and the same ffmpeg settings that WorBry used.
I get consistent results on serial testing. He get's these dodgy inconsistent results. How so ?
__________________
Nostalgia's not what it used to be
WorBry is offline   Reply With Quote
Old Today, 16:05   #142  |  Link
WorBry
Registered User
 
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,097
Quote:
Originally Posted by Iron_Mike View Post
...it is the x265 KEYFRAMES parameter that creates an encode that will throw off seekmode...
Quote:
Originally Posted by WorBry View Post
...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 View Post
(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.
__________________
Nostalgia's not what it used to be

Last edited by WorBry; Today at 16:27.
WorBry is offline   Reply With Quote
Old Today, 16:48   #143  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,701
What hardware were you guys running on ?

It might partially have to do with threads and cores ; The more threads, the more requests, the higher chance of frame mismatches and seek errors if you're not using a robust seek method or indexing like dgsource or seekmode=0, threads=1

CK's seektest is like wild random seeks to simulate very bad case; but usually "normal" encoding scenarios , "normal scripts", even "normal" metric testing occurs in linear order .


But small inconsistencies, like 7th decimal place etc... suggest something else wrong. Unless you have duplicate frames in the test sequence (and the mild variation is just lossy encoding differences of duplicate frames), there is something else going on. I would start to look at other things, hardware issues, run memory diagnostics

Last edited by poisondeathray; Today at 17:00.
poisondeathray is offline   Reply With Quote
Old Today, 17:26   #144  |  Link
WorBry
Registered User
 
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,097
Quote:
Originally Posted by poisondeathray View Post
What hardware were you guys running on ?
Actually, I've been running these tests on an older PC (6-core AMD FX-6300 Vishera 3500 Mhz, NVidia GeForce GT730, Win10 x64) that I keep for grunt encoding/processing and linux stuff (dual boot). A bit sluggish with 4K , but it gets there. For the metric tests I've let it run on 6 threads.

Quote:
Originally Posted by poisondeathray View Post
But small inconsistencies, like 7th decimal place etc... suggest something else wrong. Unless you have duplicate frames in the test sequence (and the mild variation is just lossy encoding differences of duplicate frames), there is something else going on. I would start to look at other things, hardware issues, run memory diagnostics
There are no duplicate frames in the 10 sec Crowd Run sequence.
__________________
Nostalgia's not what it used to be

Last edited by WorBry; Today at 17:39.
WorBry is offline   Reply With Quote
Old Today, 17:36   #145  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,701
Note the files you guys encoded are going to be slightly different too. Even with the same commandline . Because of encoding threads. Unless you guys have the same core and thread count on your hardware, or you explictly set threads
poisondeathray is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 19:52.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.