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 22nd January 2017, 00:44   #4641  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,229
Here's the results of my comparison test. I used pretty much my standard settings for the test, but with SSIM and PSNR stats enabled. I realise that psy-rd etc affects the SSIM and PSNR stats such that they become 'invalid', but I wanted to do a 'real world' encode comparison, not one with settings that I would never use (basically with psy-rd etc turned off). Differences in the motion estimation will affect all things down stream from it, such as AQ, psy-rd etc, by leaving them enabled even though the results are 'inaccurate' it does potentially show how changes in the settings affect these features.

Settings used, apart from the ME, and where applicable the ME range:
--crf 20 --output-depth 10 --rd 4 --tu-intra-depth 4 --tu-inter-depth 4 --rdoq-level 2 --b-intra --limit-modes --aq-mode 2 --nr-intra 400 --nr-inter 400 --ipratio 1.38 --pbratio 1.28 --max-merge 4 --weightb --analyze-src-pics --bframes 6 --rc-lookahead 45 --ref 6 --keyint 600 --psy-rdoq 1.28 --no-sao --qg-size 8 --limit-tu 3 --ssim-rd --psy-rd 2.00 --ssim --psnr

No avisynth filters were used for the comparison apart from the source filter.

HEX
Code:
x265 [info]: frame I:     33, Avg QP:17.37  kb/s: 5382.71   PSNR Mean: Y:46.296 U:49.536 V:50.818  SSIM Mean: 0.982813 (17.648dB)
x265 [info]: frame P:    474, Avg QP:19.67  kb/s: 1342.77   PSNR Mean: Y:45.543 U:49.001 V:49.778  SSIM Mean: 0.982113 (17.475dB)
x265 [info]: frame B:   1493, Avg QP:25.19  kb/s: 225.04    PSNR Mean: Y:45.006 U:48.783 V:49.559  SSIM Mean: 0.980893 (17.188dB)
x265 [info]: Weighted P-Frames: Y:1.1% UV:0.0%
x265 [info]: Weighted B-Frames: Y:0.4% UV:0.0%
x265 [info]: consecutive B-frames: 9.7% 0.6% 7.1% 61.5% 10.5% 10.7% 0.0%
encoded 2000 frames in 73.53s (27.20 fps), 575.05 kb/s, Avg QP:23.75, Global PSNR: 46.176, SSIM Mean Y: 0.9812134 (17.262 dB)

STAR
Code:
x265 [info]: frame I:     33, Avg QP:17.37  kb/s: 5377.76   PSNR Mean: Y:46.294 U:49.532 V:50.819  SSIM Mean: 0.982812 (17.648dB)
x265 [info]: frame P:    474, Avg QP:19.67  kb/s: 1340.51   PSNR Mean: Y:45.545 U:49.001 V:49.772  SSIM Mean: 0.982131 (17.479dB)
x265 [info]: frame B:   1493, Avg QP:25.19  kb/s: 225.26    PSNR Mean: Y:45.010 U:48.782 V:49.552  SSIM Mean: 0.980912 (17.192dB)
x265 [info]: Weighted P-Frames: Y:1.1% UV:0.0%
x265 [info]: Weighted B-Frames: Y:0.4% UV:0.0%
x265 [info]: consecutive B-frames: 9.7% 0.6% 7.1% 61.5% 10.5% 10.7% 0.0%
encoded 2000 frames in 89.92s (22.24 fps), 574.59 kb/s, Avg QP:23.75, Global PSNR: 46.177, SSIM Mean Y: 0.9812321 (17.266 dB)

STAR24 for interest, me range changed to 24 from default 57
Code:
x265 [info]: frame I:     33, Avg QP:17.37  kb/s: 5374.91   PSNR Mean: Y:46.289 U:49.532 V:50.813  SSIM Mean: 0.982800 (17.645dB)
x265 [info]: frame P:    474, Avg QP:19.67  kb/s: 1344.30   PSNR Mean: Y:45.558 U:49.008 V:49.782  SSIM Mean: 0.982175 (17.490dB)
x265 [info]: frame B:   1493, Avg QP:25.20  kb/s: 226.28    PSNR Mean: Y:45.018 U:48.789 V:49.563  SSIM Mean: 0.980951 (17.201dB)
x265 [info]: Weighted P-Frames: Y:1.1% UV:0.0%
x265 [info]: Weighted B-Frames: Y:0.4% UV:0.0%
x265 [info]: consecutive B-frames: 9.7% 0.6% 7.1% 61.5% 10.5% 10.7% 0.0%
encoded 2000 frames in 76.64s (26.09 fps), 576.20 kb/s, Avg QP:23.76, Global PSNR: 46.186, SSIM Mean Y: 0.9812714 (17.275 dB)

STAR35 as above, but 35
Code:
x265 [info]: frame I:     33, Avg QP:17.37  kb/s: 5380.92   PSNR Mean: Y:46.297 U:49.528 V:50.828  SSIM Mean: 0.982821 (17.650dB)
x265 [info]: frame P:    474, Avg QP:19.67  kb/s: 1343.05   PSNR Mean: Y:45.550 U:48.998 V:49.775  SSIM Mean: 0.982151 (17.484dB)
x265 [info]: frame B:   1493, Avg QP:25.20  kb/s: 225.62    PSNR Mean: Y:45.014 U:48.781 V:49.559  SSIM Mean: 0.980931 (17.197dB)
x265 [info]: Weighted P-Frames: Y:1.1% UV:0.0%
x265 [info]: Weighted B-Frames: Y:0.4% UV:0.0%
x265 [info]: consecutive B-frames: 9.7% 0.6% 7.1% 61.5% 10.5% 10.7% 0.0%
encoded 2000 frames in 82.48s (24.25 fps), 575.52 kb/s, Avg QP:23.76, Global PSNR: 46.181, SSIM Mean Y: 0.9812514 (17.270 dB)

UMH
Code:
x265 [info]: frame I:     33, Avg QP:17.37  kb/s: 5374.79   PSNR Mean: Y:46.290 U:49.529 V:50.821  SSIM Mean: 0.982806 (17.646dB)
x265 [info]: frame P:    474, Avg QP:19.67  kb/s: 1341.79   PSNR Mean: Y:45.541 U:48.998 V:49.775  SSIM Mean: 0.982107 (17.473dB)
x265 [info]: frame B:   1493, Avg QP:25.19  kb/s: 224.90    PSNR Mean: Y:45.007 U:48.781 V:49.558  SSIM Mean: 0.980894 (17.188dB)
x265 [info]: Weighted P-Frames: Y:1.1% UV:0.0%
x265 [info]: Weighted B-Frames: Y:0.4% UV:0.0%
x265 [info]: consecutive B-frames: 9.7% 0.6% 7.1% 61.5% 10.5% 10.7% 0.0%
encoded 2000 frames in 100.11s (19.98 fps), 574.58 kb/s, Avg QP:23.75, Global PSNR: 46.175, SSIM Mean Y: 0.9812131 (17.261 dB)

SEA
Code:
x265 [info]: frame I:     33, Avg QP:17.37  kb/s: 5378.57   PSNR Mean: Y:46.289 U:49.529 V:50.817  SSIM Mean: 0.982796 (17.644dB)
x265 [info]: frame P:    474, Avg QP:19.67  kb/s: 1341.23   PSNR Mean: Y:45.539 U:49.005 V:49.779  SSIM Mean: 0.982106 (17.473dB)
x265 [info]: frame B:   1493, Avg QP:25.19  kb/s: 224.58    PSNR Mean: Y:45.005 U:48.785 V:49.561  SSIM Mean: 0.980891 (17.188dB)
x265 [info]: Weighted P-Frames: Y:1.1% UV:0.0%
x265 [info]: Weighted B-Frames: Y:0.4% UV:0.0%
x265 [info]: consecutive B-frames: 9.7% 0.6% 7.1% 61.5% 10.5% 10.7% 0.0%
encoded 2000 frames in 245.39s (8.15 fps), 574.27 kb/s, Avg QP:23.75, Global PSNR: 46.175, SSIM Mean Y: 0.9812103 (17.261 dB)

SEA was by far the slowest and also had the lowest rated stats. HEX was the fastest, followed by STAR (and of the ME range settings), and UMH.

I thought I'd throw in STAR with different ME ranges to show the difference in speed versus the quality output. I wasn't expecting the lower the ME range the higher the PSNR and SSIM, but there is also a slight increase in bitrate so it make sense. The results for fast motion scenes may be different, and higher resolutions a higher ME range is more important. The video encoded was 712x480, encoding to 2160 the same motion has to travel across significantly more pixels which I would assume would necessitate a higher ME range setting for the same detection.

The weight p and b frames are usually different to those from the clip. I guess it depends on what is in the clip. A full encode is like this (from an full encode):
x265 [info]: Weighted P-Frames: Y:6.4% UV:4.0%
x265 [info]: Weighted B-Frames: Y:4.9% UV:2.5%


Of course, with the figures being different in each encode.

Last edited by burfadel; 22nd January 2017 at 00:59.
burfadel is offline   Reply With Quote
Old 22nd January 2017, 17:28   #4642  |  Link
aymanalz
Registered User
 
Join Date: May 2015
Posts: 68
Quote:
Originally Posted by Selur View Post
you could simply enable 'x265->Misc->Metrics->PSNR' and 'x265->Misc->Metrics->SSIM' (or add the options under 'x265->Misc->Custom command line addition') both work fine here, if it doesn't for you create a proper bug report inside the Hybrid thread,...
I'm getting values reported when I tick those options.

I'll run tests with those checked and report back.
aymanalz is offline   Reply With Quote
Old 22nd January 2017, 20:04   #4643  |  Link
mandarinka
Registered User
 
mandarinka's Avatar
 
Join Date: Jan 2007
Posts: 729
Seems that next-gen HEVC has been researched for some time: https://forum.doom9.org/showthread.php?t=174245
I wonder if this time, it'll be viable to extend x265 to support the new format instead of starting from scratch (or from the reference encoder), or if the differences will be too big again.
mandarinka is offline   Reply With Quote
Old 23rd January 2017, 15:42   #4644  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 480
x265 v2.2+23-58dddcf01b7d (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)
Barough is offline   Reply With Quote
Old 23rd January 2017, 22:31   #4645  |  Link
Motenai Yoda
Registered User
 
Motenai Yoda's Avatar
 
Join Date: Jan 2010
Posts: 709
Quote:
Originally Posted by burfadel View Post
I wanted to do a 'real world' encode comparison, not one with settings that I would never use (basically with psy-rd etc turned off).
[...]
Settings used, [...] --ssim-rd
but doesn't ssim-rd disable psy-rd?
also as it is still an experimental feature I'd not use it in a real encode.

nr-intra & nr-inter 400 ? + qg-size 8??

also I suspect analyze-src-pics can do something on how metrics are computed...
__________________
powered by Google Translator

Last edited by Motenai Yoda; 23rd January 2017 at 22:39.
Motenai Yoda is offline   Reply With Quote
Old 23rd January 2017, 22:38   #4646  |  Link
davidsama
Registered User
 
Join Date: Sep 2006
Posts: 38
This is the AVX2 build
davidsama is offline   Reply With Quote
Old 24th January 2017, 03:45   #4647  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,229
Quote:
Originally Posted by Motenai Yoda View Post
but doesn't ssim-rd disable psy-rd?
also as it is still an experimental feature I'd not use it in a real encode.

nr-intra & nr-inter 400 ? + qg-size 8??

also I suspect analyze-src-pics can do something on how metrics are computed...
ssim-rd does disable psy-rd, it does this by using a default of 0.00, at least during testing. If you specify it manually*you can still use it. I use 400 for nr*as it isn't really noticeable but saves bitrate. I can therefore use a lower CRF*so the result is higher quality output.
burfadel is offline   Reply With Quote
Old 24th January 2017, 07:38   #4648  |  Link
greenfountain
Registered User
 
Join Date: Aug 2013
Posts: 5
Quote:
Originally Posted by burfadel View Post

SEA was by far the slowest and also had the lowest rated stats. HEX was the fastest, followed by STAR (and of the ME range settings), and UMH.

I thought I'd throw in STAR with different ME ranges to show the difference in speed versus the quality output. I wasn't expecting the lower the ME range the higher the PSNR and SSIM, but there is also a slight increase in bitrate so it make sense. The results for fast motion scenes may be different, and higher resolutions a higher ME range is more important. The video encoded was 712x480, encoding to 2160 the same motion has to travel across significantly more pixels which I would assume would necessitate a higher ME range setting for the same detection.

The weight p and b frames are usually different to those from the clip. I guess it depends on what is in the clip. A full encode is like this (from an full encode):
x265 [info]: Weighted P-Frames: Y:6.4% UV:4.0%
x265 [info]: Weighted B-Frames: Y:4.9% UV:2.5%


Of course, with the figures being different in each encode.
Thanks for making that comparison burfadel. Actually the focus of SEA is to make FULL faster but we cannot expect it to be faster than other motion search algorithms like HEX/STAR.
greenfountain is offline   Reply With Quote
Old 25th January 2017, 11:02   #4649  |  Link
Midzuki
Unavailable
 
Midzuki's Avatar
 
Join Date: Mar 2009
Location: offline
Posts: 1,480
x265 2.2+25-3737c70c3308

Code:
add support for aq-motion even when aq-mode is disabled
http://www.mediafire.com/file/4npram...737c70c3308.7z
Midzuki is offline   Reply With Quote
Old 25th January 2017, 11:41   #4650  |  Link
jlpsvk
Registered User
 
Join Date: Dec 2014
Posts: 240
is it a bug? when I set --high-tier but not --level-idc, it still encodes in main tier...
jlpsvk is offline   Reply With Quote
Old 25th January 2017, 17:03   #4651  |  Link
x265_Project
Guest
 
Posts: n/a
Quote:
Originally Posted by mandarinka View Post
Seems that next-gen HEVC has been researched for some time: https://forum.doom9.org/showthread.php?t=174245
I wonder if this time, it'll be viable to extend x265 to support the new format instead of starting from scratch (or from the reference encoder), or if the differences will be too big again.
Anything is possible with enough time, money and motivation. The question of whether to start with the reference or with x265 depends on your software development philosophy. We like to use an agile software development methodology, which stresses the need to always have a stable build that works. With a new coding standard, the reference encoder gives you a stable build that works (can encode valid bitstreams for that standard). So we would likely start there, and then slowly replace every piece of the reference encoder with our own code, just as we did with x265.
  Reply With Quote
Old 26th January 2017, 07:14   #4652  |  Link
Midzuki
Unavailable
 
Midzuki's Avatar
 
Join Date: Mar 2009
Location: offline
Posts: 1,480
x265.exe 2.2+26-d1f6d9b8d6be

Code:
Add filler bits when frame bits < vbv target in strict-cbr
http://www.mediafire.com/file/j1ouck...1f6d9b8d6be.7z
Midzuki is offline   Reply With Quote
Old 26th January 2017, 21:08   #4653  |  Link
cojj
Registered User
 
Join Date: Sep 2016
Location: New Zealand
Posts: 18
Quote:
Originally Posted by jlpsvk View Post
is it a bug? when I set --high-tier but not --level-idc, it still encodes in main tier...
According to the documentation:
"high-tier allows the support of high tier at that level. The encoder will first attempt to encode at the specified level, main tier first, turning on high tier only if necessary and available at that level."

Pretty self-explanatory => even if you set the flag, it will attempt main tier first and only use high-tier if necessary.
cojj is offline   Reply With Quote
Old 27th January 2017, 03:34   #4654  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,229
Quote:
Originally Posted by greenfountain View Post
Thanks for making that comparison burfadel. Actually the focus of SEA is to make FULL faster but we cannot expect it to be faster than other motion search algorithms like HEX/STAR.
That makes sense .*STAR seems the most efficient,*it would be interesting to know whether it could be improved further.
burfadel is offline   Reply With Quote
Old 27th January 2017, 14:07   #4655  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
x265 2.2+29-2f075fe8d4c5

Code:
   --complex-analysis <0..4.0>   Strength of complex analysis, 0 to disable. Default 0.0
Quote:
Increases the RD-level at points where the bitrate drops due to vbv. The number of CUs for which the RD is reconfigured is determined based on the strength. Strength 1 gives the best FPS, strength 4 gives the best SSIM. Strength 0 switches this feature off. Default: 0.

Effective for RD levels 4 and below.
A developers' functionality test runs with strength 1.53, FYI.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 27th January 2017, 15:06   #4656  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,229
Quote:
Originally Posted by LigH View Post
x265 2.2+29-2f075fe8d4c5

Code:
   --complex-analysis <0..4.0>   Strength of complex analysis, 0 to disable. Default 0.0
A developers' functionality test runs with strength 1.53, FYI.
You need to update your build, looks like the patches were resubmitted due to bugs and your build uses the old patches.

I also guess that for non restricted VBV like normal encoding with ABR, the function serves little use. I wonder whether it could be adopted to apply based on complexity rather than stating actual numbers, which would vary from encode to encode. For instance, a particular video might have scenes where there is low complexity, and there is plentiful use of P and B frames. There could be points in the video where the complexity increases such that fewer P and B frame could be utilised, resulting in a higher bitrate. When this occurs a higher complex-analysis seting can be used, 0.5 (variable strength) could be used there and scales upwards further with higher complexity. The setting would therefore be the scaling rate, such that a lower setting would be more constrained in the scaling, and not a fixed rate, based on perceived complexity of the current run of frames. This would make it useful for normal use and not a per-encode use that is required with the existing code due to stating VBV limitations that varies with content, complexity, and resolution.

I realise this isn't the purpose of it spefically, it's just an interesting concept that could be repurposed. Just an idea .

Last edited by burfadel; 27th January 2017 at 15:28.
burfadel is offline   Reply With Quote
Old 27th January 2017, 15:12   #4657  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
How do I? TortoiseHg Workbench does not report any changes since. The commit log on bitbucket neither.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid

Last edited by LigH; 27th January 2017 at 15:15.
LigH is offline   Reply With Quote
Old 27th January 2017, 16:51   #4658  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,229
Probably not committed to the development branch yet, patches are here:

https://patches.videolan.org/project/x265-devel/list/
burfadel is offline   Reply With Quote
Old 27th January 2017, 21:25   #4659  |  Link
x265_Project
Guest
 
Posts: n/a
Quote:
Originally Posted by burfadel View Post
You need to update your build, looks like the patches were resubmitted due to bugs and your build uses the old patches.

I also guess that for non restricted VBV like normal encoding with ABR, the function serves little use. I wonder whether it could be adopted to apply based on complexity rather than stating actual numbers, which would vary from encode to encode. For instance, a particular video might have scenes where there is low complexity, and there is plentiful use of P and B frames. There could be points in the video where the complexity increases such that fewer P and B frame could be utilised, resulting in a higher bitrate. When this occurs a higher complex-analysis seting can be used, 0.5 (variable strength) could be used there and scales upwards further with higher complexity. The setting would therefore be the scaling rate, such that a lower setting would be more constrained in the scaling, and not a fixed rate, based on perceived complexity of the current run of frames. This would make it useful for normal use and not a per-encode use that is required with the existing code due to stating VBV limitations that varies with content, complexity, and resolution.

I realise this isn't the purpose of it spefically, it's just an interesting concept that could be repurposed. Just an idea .
Sure, we can extend this technique to wider applications. This initial function was developed for those who use "capped VBR" rate control (CRF, with VBV). In this scenario, quality is constant until you reach a place where VBV kicks in to enforce decoder parameters. In these places, quality will take a dip. To counteract that, we allow x265 to dynamically increase encoding efficiency in these areas (similar to using a slower, higher quality performance preset). But yes, the concept could be extended to general ABR or CRF encoding.
  Reply With Quote
Old 27th January 2017, 21:28   #4660  |  Link
x265_Project
Guest
 
Posts: n/a
Quote:
Increases the RD-level at points where the bitrate drops due to vbv. The number of CUs for which the RD is reconfigured is determined based on the strength. Strength 1 gives the best FPS, strength 4 gives the best SSIM. Strength 0 switches this feature off. Default: 0.

Effective for RD levels 4 and below.
We probably should have said "Increases the RD level at points where quality drops due to VBV rate control enforcement." I'll ask our team to improve the documentation.
  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:23.


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