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 > Video Encoding > High Efficiency Video Coding (HEVC)

Reply
 
Thread Tools Search this Thread Display Modes
Old 12th December 2020, 20:34   #7881  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,419
Quote:
Originally Posted by LigH View Post
Best chance: ffmpeg. Although it may not pass all x265 params.
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:
Originally Posted by Stereodude View Post
Any recent x265 builds with lavf support (to use a .AVS as the source and avoid piping)?
There's a standalone AviSynth+ input now, which takes precedence over LAVF.

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.
qyot27 is offline   Reply With Quote
Old 13th December 2020, 01:02   #7882  |  Link
Stereodude
Registered User
 
Join Date: Dec 2002
Location: Region 0
Posts: 1,436
Quote:
Originally Posted by qyot27 View Post
There's a standalone AviSynth+ input now, which takes precedence over LAVF.

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.
Okay, I'm using AVS+. But that still requires special builds, not something that's in the mainline x265 right?
Stereodude is offline   Reply With Quote
Old 13th December 2020, 04:53   #7883  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,419
LAVF support isn't in mainline x265 either.
qyot27 is offline   Reply With Quote
Old 13th December 2020, 20:28   #7884  |  Link
stax76
Registered User
 
stax76's Avatar
 
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
Is there a default value for --qp-delta-nonref?
stax76 is offline   Reply With Quote
Old 13th December 2020, 20:33   #7885  |  Link
quietvoid
Registered User
 
Join Date: Jan 2019
Location: Canada
Posts: 570
Quote:
The offset is computed from --qp-delta-ref when it is not explicitly specified.
So probably 5 as well.
Edit: It's actually the ref offset * 0.3 apparently.

Last edited by quietvoid; 15th December 2020 at 21:47.
quietvoid is offline   Reply With Quote
Old 14th December 2020, 16:45   #7886  |  Link
Stereodude
Registered User
 
Join Date: Dec 2002
Location: Region 0
Posts: 1,436
Quote:
Originally Posted by qyot27 View Post
LAVF support isn't in mainline x265 either.
I know, I was just confirming whether I would find the new AVS+ input capability in the mainline or not. Thanks for the build!
Stereodude is offline   Reply With Quote
Old 14th December 2020, 20:04   #7887  |  Link
vpupkind
Registered User
 
Join Date: Jul 2007
Posts: 60
Quote:
Originally Posted by quietvoid View Post
Hm, well this is only an issue for use cases that need strict VBV conformance.
I guess we are stuck with it then.
If you increase the QP (i.e., consume less bits), the single-pass VBV RC would lower the QP's onwards because it still has some bits to spare.
vpupkind is offline   Reply With Quote
Old 14th December 2020, 20:06   #7888  |  Link
quietvoid
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.
quietvoid is offline   Reply With Quote
Old 15th December 2020, 06:14   #7889  |  Link
Kurtnoise
Swallowed in the Sea
 
Kurtnoise's Avatar
 
Join Date: Oct 2002
Location: Aix-en-Provence, France
Posts: 5,191
Quote:
Originally Posted by stax76 View Post
Would be great but vpy support should be enabled too, vpy is supported by lavf but it's disabled by default. As far as I know it cannot be enabled at runtime, I've asked before but there wasn't any C++ programmer with an answer.
https://github.com/DJATOM/x265-aMod
Kurtnoise is offline   Reply With Quote
Old 15th December 2020, 06:33   #7890  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Quote:
Originally Posted by quietvoid View Post
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.
There is absolutely no reason for the restriction. In case of a CRF encode without any VBV settings, there is nothing requiring a second pass.

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...
Boulder is offline   Reply With Quote
Old 15th December 2020, 15:27   #7891  |  Link
quietvoid
Registered User
 
Join Date: Jan 2019
Location: Canada
Posts: 570
I'm going to try making a patch that enables single pass to work with Forward masking, there were some changes that made it rely on using scenecuts from the stats file though.
quietvoid is offline   Reply With Quote
Old 15th December 2020, 16:48   #7892  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Quote:
Originally Posted by quietvoid View Post
I'm going to try making a patch that enables single pass to work with Forward masking, there were some changes that made it rely on using scenecuts from the stats file though.
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...
Boulder is offline   Reply With Quote
Old 15th December 2020, 17:00   #7893  |  Link
stax76
Registered User
 
stax76's Avatar
 
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
Quote:
Originally Posted by Kurtnoise View Post
Didn't know it, thanks.
stax76 is offline   Reply With Quote
Old 15th December 2020, 18:01   #7894  |  Link
quietvoid
Registered User
 
Join Date: Jan 2019
Location: Canada
Posts: 570
Quote:
Originally Posted by Boulder View Post
Quite strange that rc-lookahead is not used with the feature, IMO it would be a perfect match for this.
For scenecut-aware-qp, I'm pretty sure it uses lookahead either way since the info seems to be coming from frames in the lookahead queue.

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.
quietvoid is offline   Reply With Quote
Old 16th December 2020, 06:52   #7895  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Quote:
Originally Posted by quietvoid View Post
For scenecut-aware-qp, I'm pretty sure it uses lookahead either way since the info seems to be coming from frames in the lookahead queue.

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.
Thank you for the patch, I'll try find the time to test it during the Christmas period. Do you feel that the default window of 500 ms is suitable considering subjective quality in motion?
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 16th December 2020, 14:01   #7896  |  Link
quietvoid
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.
quietvoid is offline   Reply With Quote
Old 17th December 2020, 13:42   #7897  |  Link
Barough
Registered User
 
Barough's Avatar
 
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
Barough is offline   Reply With Quote
Old 18th December 2020, 18:44   #7898  |  Link
vpupkind
Registered User
 
Join Date: Jul 2007
Posts: 60
Quote:
Originally Posted by quietvoid View Post
For scenecut-aware-qp, I'm pretty sure it uses lookahead either way since the info seems to be coming from frames in the lookahead queue.

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.
Are you going to submit it?
vpupkind is offline   Reply With Quote
Old 18th December 2020, 22:15   #7899  |  Link
quietvoid
Registered User
 
Join Date: Jan 2019
Location: Canada
Posts: 570
I don't even know how mailing lists work
quietvoid is offline   Reply With Quote
Old 19th December 2020, 11:12   #7900  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Quote:
Originally Posted by quietvoid View Post
I don't even know how mailing lists work
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...
Boulder 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 13:26.


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