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 24th July 2021, 19:41   #41  |  Link
Sharc
Registered User
 
Join Date: May 2006
Posts: 3,997
--ctu32 in addition to --rskip 2 may bring some stars back, but other stars and details disappear. Artefacts are ugly in both cases. The compression of about 1/8 is simply too much IMO, but one could argue that the results are amazingly good for this high compression.
Sharc is offline   Reply With Quote
Old 24th July 2021, 20:14   #42  |  Link
microchip8
ffx264/ffhevc author
 
microchip8's Avatar
 
Join Date: May 2007
Location: /dev/video0
Posts: 1,843
Quote:
Originally Posted by Sharc View Post
--ctu32 in addition to --rskip 2 may bring some stars back, but other stars and details disappear. Artefacts are ugly in both cases. The compression of about 1/8 is simply too much IMO, but one could argue that the results are amazingly good for this high compression.
You can add rskip-edge-threshold 2 or, in my use case, 1. Slows down encoding a bit at good gains. The default of 5 is too high, IMO
__________________
ffx264 || ffhevc || ffxvid || microenc
microchip8 is offline   Reply With Quote
Old 24th July 2021, 21:22   #43  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by Sharc View Post
--ctu32 in addition to --rskip 2 may bring some stars back, but other stars and details disappear. Artefacts are ugly in both cases. The compression of about 1/8 is simply too much IMO, but one could argue that the results are amazingly good for this high compression.
I expect that --ctu 32 only helps because with the default --tu-intra/inter-depth, it allows for smaller texture units.

To directly allow for the minimum size TU's:

--tu-intra-depth 4 --tu-inter-depth 4

To reduce the perf hit

--limit-tu 4

Stars can also be helped by --amp and --rect, which also have a speed penalty, which can be mitigated somewhat by --limit-modes. With minimum tu size and amp/rect being used, x265 can tweak things down to almost an individual pixel.

Of course, by that point we're more finding something between slower and veryslow, not a middle ground between medium and slow.

--tskip --tskip-fast may also help with stars. A dot in a flat block isn't well-suited to a frequency transform.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 25th July 2021, 06:58   #44  |  Link
Gravitator
Registered User
 
Join Date: May 2014
Posts: 292
Quote:
Originally Posted by microchip8 View Post
I fail to spot the problem in your test sample. What am I looking at for?
Twitching of the stars near the ship (dragging them along).
Quote:
Originally Posted by benwaggoner View Post
--tu-intra-depth 4 --tu-inter-depth 4
--tskip --tskip-fast may also help with stars. A dot in a flat block isn't well-suited to a frequency transform.
Now the picture is much better! For --rskip 2, the --tu-intra-depth 4 --tu-inter-depth 4 parameter is now strongly recommended at its maximum values!
Code:
ffmpeg -i z:\space_6s.mkv -f yuv4mpegpipe - | x265 --y4m - --preset medium --output-depth 10 --profile main10 --crf 32.6 --rskip 0 --tskip --ctu 32 --hme --hme-search hex,hex,hex --tu-intra-depth 4 --tu-inter-depth 4 -o z:\R0.mkv
encoded 149 frames in 51.70s (2.88 fps), 1034.93 kb/s, Avg QP:36.79
Code:
ffmpeg -i z:\space_6s.mkv -f yuv4mpegpipe - | x265 --y4m - --preset medium --output-depth 10 --profile main10 --crf 31.3 --rskip 2 --rskip-edge-threshold 1 --tskip --ctu 32 --hme --hme-search hex,hex,hex --tu-intra-depth 4 --tu-inter-depth 4 -o z:\R2.mkv
encoded 149 frames in 37.91s (3.93 fps), 1039.52 kb/s, Avg QP:35.73
__________________
Win10x64, Xeon E5450, GTX 750 2GB, DDR3 8GB.

Last edited by Gravitator; 25th July 2021 at 07:01.
Gravitator is offline   Reply With Quote
Old 25th July 2021, 11:33   #45  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Quote:
Originally Posted by microchip8 View Post
rskip 2 should be used with ctu of 32. Anything above and you get problems
That should apply only to the CTU 64 & limit-tu 0 combination. I've not seen any issues at 1080p with CTU 64 and limit-tu 4. For lower resolutions I always set CTU to 32.
__________________
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 25th July 2021, 16:44   #46  |  Link
Gravitator
Registered User
 
Join Date: May 2014
Posts: 292
Quote:
Originally Posted by Boulder View Post
That should apply only to the CTU 64 & limit-tu 0 combination. I've not seen any issues at 1080p with CTU 64 and limit-tu 4. For lower resolutions I always set CTU to 32.
Checking on my sample-1080p gives a negative conclusion...
Code:
ffmpeg -i c:\space_6s.mkv -f yuv4mpegpipe - | x265 --y4m - --preset medium --output-depth 10 --profile main10 --crf 31.8 --rskip 2 --rskip-edge-threshold 1 --tskip --ctu 32 --hme --hme-search hex,hex,hex --tu-intra-depth 4 --tu-inter-depth 4 -o c:\r2_ctu32.mkv
encoded 149 frames in 33.42s (4.46 fps), 1003.17 kb/s, Avg QP:35.93 >Small artifacts near the ship.
Code:
ffmpeg -i c:\space_6s.mkv -f yuv4mpegpipe - | x265 --y4m - --preset medium --output-depth 10 --profile main10 --crf 31.2 --rskip 2 --rskip-edge-threshold 1 --tskip --ctu 64 --hme --hme-search hex,hex,hex --tu-intra-depth 4 --tu-inter-depth 4 -o c:\r2_ctu64.mkv
encoded 149 frames in 33.28s (4.48 fps), 1008.97 kb/s, Avg QP:35.50 > More noticeable artifacts near the ship and large chunks of the image disappear towards the end of the video.
__________________
Win10x64, Xeon E5450, GTX 750 2GB, DDR3 8GB.
Gravitator is offline   Reply With Quote
Old 25th July 2021, 17:07   #47  |  Link
microchip8
ffx264/ffhevc author
 
microchip8's Avatar
 
Join Date: May 2007
Location: /dev/video0
Posts: 1,843
Have you tried using a better motion estimation for HME instead of hex? I personally use umh,umh,star
__________________
ffx264 || ffhevc || ffxvid || microenc
microchip8 is offline   Reply With Quote
Old 25th July 2021, 18:25   #48  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Quote:
Originally Posted by Gravitator View Post
Checking on my sample-1080p gives a negative conclusion...
Code:
ffmpeg -i c:\space_6s.mkv -f yuv4mpegpipe - | x265 --y4m - --preset medium --output-depth 10 --profile main10 --crf 31.8 --rskip 2 --rskip-edge-threshold 1 --tskip --ctu 32 --hme --hme-search hex,hex,hex --tu-intra-depth 4 --tu-inter-depth 4 -o c:\r2_ctu32.mkv
encoded 149 frames in 33.42s (4.46 fps), 1003.17 kb/s, Avg QP:35.93 >Small artifacts near the ship.
Code:
ffmpeg -i c:\space_6s.mkv -f yuv4mpegpipe - | x265 --y4m - --preset medium --output-depth 10 --profile main10 --crf 31.2 --rskip 2 --rskip-edge-threshold 1 --tskip --ctu 64 --hme --hme-search hex,hex,hex --tu-intra-depth 4 --tu-inter-depth 4 -o c:\r2_ctu64.mkv
encoded 149 frames in 33.28s (4.48 fps), 1008.97 kb/s, Avg QP:35.50 > More noticeable artifacts near the ship and large chunks of the image disappear towards the end of the video.
That CRF value is simply so much out of my range so no guarantees I use 18-19 for 1080p (SDR).

Quote:
Originally Posted by microchip8
Have you tried using a better motion estimation for HME instead of hex? I personally use umh,umh,star
I also think that umh,umh,star is the fastest one. I couldn't find a reason why but so it seemed at least in my tests.
__________________
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 25th July 2021, 20:37   #49  |  Link
Gravitator
Registered User
 
Join Date: May 2014
Posts: 292
Quote:
Originally Posted by microchip8 View Post
Have you tried using a better motion estimation for HME instead of hex? I personally use umh,umh,star
Preferably star,star,star (smoother lines)
------
I am looking for x265 maximum setting to get closer to the quality of AOM.
Download the encoded sample > AOM
__________________
Win10x64, Xeon E5450, GTX 750 2GB, DDR3 8GB.
Gravitator is offline   Reply With Quote
Old 26th July 2021, 10:11   #50  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Just a thought: would --rdpenalty 1 help here to push for smaller TUs?
__________________
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 26th July 2021, 19:44   #51  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by microchip8 View Post
Have you tried using a better motion estimation for HME instead of hex? I personally use umh,umh,star
For this quality/perf range and for stars (or other particle-effect like small independently moving details), I wonder if something like this might be a good balance:

--hme --hme-range 16,32,32 --hme-search hex,umh,star

The coarser ME passes should pick up on the stars, with the last stage really only for refinement. A smaller, more exhaustive search could help quite a bit to get the 1/8th pel optimal.

I've not really tested this personally, however.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 26th July 2021, 19:46   #52  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by Boulder View Post
Just a thought: would --rdpenalty 1 help here to push for smaller TUs?
Maybe? That was a sometimes-useful parameter for x265 in 2014-2015, but I've not heard of it being used in the last five years.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 28th July 2021, 17:42   #53  |  Link
tonemapped
Video Fanatic
 
tonemapped's Avatar
 
Join Date: Jul 2021
Location: Surrey
Posts: 89
Quote:
Originally Posted by microchip8 View Post
I find the built-in presets to be flawed. That's why I always use my own settings. Crispy sharp, no banding, no blocking, noise preservation, etc
If you were going to change the current Medium presets to reflect the maturity of x265, what would you change? Personally, I'd change (from the defaults):

-rskip-edge-threshold 4
--psy-rd 2.10
--psy-rdoq 1.1
--rskip 2
--me umh
--rc-lookahead 30 (or 25)

Based on testing on a slow CPU (Skylake-era Xeon 4C/4T), the penalty is ~6% increased time but retaining much more detail and better detail in moving scenes.
tonemapped is offline   Reply With Quote
Old 28th July 2021, 20:46   #54  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by tonemapped View Post
If you were going to change the current Medium presets to reflect the maturity of x265, what would you change? Personally, I'd change (from the defaults):

-rskip-edge-threshold 4
--psy-rd 2.10
--psy-rdoq 1.1
--rskip 2
--me umh
--rc-lookahead 30 (or 25)

Based on testing on a slow CPU (Skylake-era Xeon 4C/4T), the penalty is ~6% increased time but retaining much more detail and better detail in moving scenes.
It's content dependent of course, but those seem like some good options.

The x265 presets haven't bee refactored in several years now, and don't include a lot of features that would help.

--selective-sao 2 is an essentially free speedup, for example, and should be default in every preset except maybe placebo. And even placebo could use --selective-sao 3. (SAO does very little for bidirectional prediction or non-reference frames).

--dynamic-refine is a great quality/speed feature for VBV-limited encodes, as it cranks up complexity when quality is VBV-limited, and then lets it drop down where the CRF quality can be met. Encoding time will vary with source more, but it averages out to a good quality/speed win by spending more cycles just where it improves quality.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 29th July 2021, 12:35   #55  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Which areas of the frame should be affected by --selective-sao 2 compared to --selective-sao 0? I just did a quick test regarding filesize and at the same CRF, the filesize for 0 was 2651 kbps / avg QP 18.23 while for 2 they were 2926.94 / 17.86 and based on the stats, the QPs for P-frames were substantially lower. I-frames pretty much the same for both versions.

EDIT: it's also odd that --selective-sao 2 is faster even though it produces a bigger file and should require more computation than no SAO at all.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...

Last edited by Boulder; 29th July 2021 at 13:21.
Boulder is offline   Reply With Quote
Old 29th July 2021, 17:08   #56  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by Boulder View Post
Which areas of the frame should be affected by --selective-sao 2 compared to --selective-sao 0? I just did a quick test regarding filesize and at the same CRF, the filesize for 0 was 2651 kbps / avg QP 18.23 while for 2 they were 2926.94 / 17.86 and based on the stats, the QPs for P-frames were substantially lower. I-frames pretty much the same for both versions.

EDIT: it's also odd that --selective-sao 2 is faster even though it produces a bigger file and should require more computation than no SAO at all.
That is a concerning result! --selective-sao should have a <1% impact on file size and QP. You should file an issue with MCW.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 16th August 2021, 10:22   #57  |  Link
PatchWorKs
Registered User
 
PatchWorKs's Avatar
 
Join Date: Aug 2002
Location: Italy
Posts: 303
Question: do you think is possible to perform only the 1st pass with hw accelleration (qsv) in order to speedup the whole encode ?

Thanks !
PatchWorKs is offline   Reply With Quote
Old 16th August 2021, 12:40   #58  |  Link
rwill
Registered User
 
Join Date: Dec 2013
Posts: 343
Do you think it is possible to perform the 1st pass with x264 ?
rwill is offline   Reply With Quote
Old 16th August 2021, 23:54   #59  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by rwill View Post
Do you think it is possible to perform the 1st pass with x264 ?
You can import a x264 encode as data to refine, but I've never tried it.

Tweaking a faster firstpass with x265 is probably going to give better speed/performance. x265 defaults to --no-slow-firstpass to avoid 1/2nd pass mismatches. But IIRC, as long as you use the same --ref and --bframes between passes, you can speed up --me, add a bunch of early-exit options, etcetera. It's been years since I've tried it, but with some testing I'm sure compatible yet faster 1st pass settings can be determined.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner 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 17:01.


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