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. |
12th December 2020, 20:34 | #7881 | Link | |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,419
|
CLI params, up in the air. API params, it can access all of them using the -x265_params option.
FFmpeg has the advantage that the bit depth you put in is the bit depth you get out. Unlike x265 CLI sampling everything down to 8-bit unless you use --output-depth. Quote:
But anyway, here's a build of from November 1st (which means it's just missing the three latest commits from MCW/x265_git) with most* of the x265-Yuuki patches applied onto it: https://www.mediafire.com/file/2f0k0...fbd100.7z/file *I remember I had to skip some of them because it was complicating the rebase process, or needed updating, or something. But the AviSynth demuxer is there, as is 8+10+12 on both. |
|
13th December 2020, 01:02 | #7882 | Link | |
Registered User
Join Date: Dec 2002
Location: Region 0
Posts: 1,436
|
Quote:
|
|
13th December 2020, 20:28 | #7884 | Link |
Registered User
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
|
Is there a default value for --qp-delta-nonref?
__________________
https://github.com/stax76/software-list https://www.youtube.com/@stax76/playlists |
13th December 2020, 20:33 | #7885 | Link | |
Registered User
Join Date: Jan 2019
Location: Canada
Posts: 570
|
Quote:
Edit: It's actually the ref offset * 0.3 apparently. Last edited by quietvoid; 15th December 2020 at 21:47. |
|
14th December 2020, 20:06 | #7888 | Link |
Registered User
Join Date: Jan 2019
Location: Canada
Posts: 570
|
That sounds like sane behavior to me, what point are you getting at?
I did notice improvements in frames after the scenecut higher QP ones, where there's a benefit in using --scenecut-aware-qp compared to not. Usually that meant saving around 500 kbps using --detla-ref-qp 2 and the quality was sometimes much better after the scenecut window. Also this is for 1 pass CRF, not 1 pass CBR. I still see no reason the feature should be restricted to multi pass. Last edited by quietvoid; 14th December 2020 at 20:14. |
15th December 2020, 06:14 | #7889 | Link | |
Swallowed in the Sea
Join Date: Oct 2002
Location: Aix-en-Provence, France
Posts: 5,191
|
Quote:
|
|
15th December 2020, 06:33 | #7890 | Link | |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,718
|
Quote:
I wonder if the feature could be enabled just by removing some basic check from the code, or is there more inside the various functions?
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
|
15th December 2020, 16:48 | #7892 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,718
|
Quite strange that rc-lookahead is not used with the feature, IMO it would be a perfect match for this.
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
15th December 2020, 17:00 | #7893 | Link | |
Registered User
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
|
Quote:
__________________
https://github.com/stax76/software-list https://www.youtube.com/@stax76/playlists |
|
15th December 2020, 18:01 | #7894 | Link | |
Registered User
Join Date: Jan 2019
Location: Canada
Posts: 570
|
Quote:
Here's the patch if anyone wants to test, I'll post my results back later: https://gist.github.com/quietvoid/49...1516e306d5fa0d Applies on top of Release_3.5 branch, for some reason they didn't push the new masking stuff into master. Edit: The patch seems to work just fine. I don't really understand the concept of the non-ref inter frames, because it's increasing the QP on the same frames, except enabling non-ref strength makes it even higher QP (in my test it goes from +4 to +8 when both are set to 10). Unfortunately, the QP increase seems to be different from the first implementation (apparently it was wrong), setting --masking-strength 500,1,0 is increasing QP by 6, according to the csv log while 10 increases by 8.. Anyways, I fixed it by allowing the offset to be set to 0 (was defaulting to 6.5..). Patch updated. Seems to be varying the offset depending on the distance from the scenecut frame, where the closest inter frames have higher QP than the ones at the end of the window (allowing negative offset at the end). Using --masking-strength 500,2,0 makes the offset vary between -1 to +3.5 while 500,2,2 varies between +1.1 to +4.2. So without using non-ref offset, quality can be increased near the end of the scene cut window while still lowering bitrate a little (in my test this is a 400 kb/s difference). The original x265 patch was pretty incomplete, so anyone feel free to send this upstream. Who knows if it's acceptable. On top of it all, the last commit "Fix version information reporting for x265 git archival" breaks CMake's version detection. Always returns unknown. Now this is an actual issue. Someone might want to let them know. Last edited by quietvoid; 15th December 2020 at 22:49. |
|
16th December 2020, 06:52 | #7895 | Link | |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,718
|
Quote:
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
|
16th December 2020, 14:01 | #7896 | Link |
Registered User
Join Date: Jan 2019
Location: Canada
Posts: 570
|
Probably, I've used 550 in the past to save a bit more. It's better now that the offset isn't fixed for the whole window.
I can't really notice a difference after ~300 ms (before that the offset is pretty high, but the quality change shouldn't be noticeable) when comparing still shots. Also the new code avoids selecting scenecuts that are still within a previous window, so in motion it wouldn't be constantly resetting to high QP. Last edited by quietvoid; 16th December 2020 at 14:45. |
17th December 2020, 13:42 | #7897 | Link |
Registered User
Join Date: Feb 2007
Location: Sweden
Posts: 480
|
x265 v3.4+33-606265ac7 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.2.0)
Code:
https://bitbucket.org/multicoreware/x265_git/commits/branch/Release_3.5 Last edited by Barough; 27th December 2020 at 12:01. Reason: Fixed Link |
18th December 2020, 18:44 | #7898 | Link | |
Registered User
Join Date: Jul 2007
Posts: 60
|
Quote:
|
|
19th December 2020, 11:12 | #7900 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,718
|
I think you can just send your patch in an email to x265-devel@videolan.org. I recall that you have to "sign" some sort of a document but they'll probably tell you where it is located if so.
https://bitbucket.org/multicoreware/...iki/Contribute
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
Thread Tools | Search this Thread |
Display Modes | |
|
|