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. |
30th August 2016, 15:10 | #41 | Link | |
Registered User
Join Date: Mar 2008
Posts: 448
|
Quote:
https://software.intel.com/en-us/int...o-pro-analyzer Just use the trial version to find out everything..... |
|
30th August 2016, 15:25 | #42 | Link |
Registered User
Join Date: Mar 2004
Posts: 1,120
|
Intel just announced the Kaby Lake media capabilities: http://www.anandtech.com/show/10610/...g-in-january/3
It supports full fixed function 8-bit encode and 8/10-bit decode for VP9 codec and 8/10bit encode and decode for h265. |
30th August 2016, 16:42 | #43 | Link | ||
Registered User
Join Date: Sep 2011
Posts: 362
|
Quote:
ffmpeg is slow, no wonder. Make sure you are using the fixed function decoder for encoding and QSVEnc is the best. Quote:
Intel also said that the HEVC Encoding quality is more than 10% improved over Skylake. The hardware is fine, they only have to add Lookahead. |
||
30th August 2016, 16:51 | #44 | Link | |
Registered User
Join Date: Mar 2008
Posts: 448
|
Quote:
Aside from Lookahead, Intel should add P-Frame support, SAO and all PU sizes. ~.~ For some unknown reason, all big 3 (Intel, Nvidia and AMD) hardware encoders have problem encoding dark / black scene properly. I can see those big dark blocky artifacts on dark scene even with 15Mbps on 1080p. Bright scene is perfect though..... |
|
30th August 2016, 17:04 | #45 | Link |
Registered User
Join Date: Sep 2011
Posts: 362
|
Hardware is fine imho. It will never support the same features as a software encoder. I'm only interested in the end result and Intels biggest problem with HEVC is scene change. H264 is better in this regard because there is Lookahead for VBR or ICQ. Especially with low bitrate videos this is a big problem. Lookahead is just a software thing. Aside from this HEVC is very much better than H264 from Intel.
|
31st August 2016, 00:17 | #46 | Link |
insane college undergrad
Join Date: Jun 2006
Location: middle of nowhere
Posts: 405
|
That's not limited to HEVC though. My QSVEncC and Handbrake H.264 QuickSync encodes exhibit the same issue. At similar bitrates, blocking on QSV HEVC actually isn't as bad as on QSV H.264.
|
10th September 2016, 11:49 | #47 | Link |
Registered User
Join Date: Sep 2011
Posts: 362
|
I changed my GTX 970 for a GTX 1080. One thing I can say is that the performance of 8 bit HEVC video encoding is much improved.
GTX 970 Video 1: 163 fps Video 2: 175 fps GTX 1080 Video 1: 288 fps +76,7% Video 2: 308 fps +76% The super high clock rate of Pascal is the main reason in order to speed up the video engine. 1962 Mhz for my GTX 1080 and 1291 Mhz for GTX 970. |
10th September 2016, 11:58 | #48 | Link |
Registered User
Join Date: Aug 2010
Location: Athens, Greece
Posts: 2,901
|
GTX 970 has a hybrid HEVC decoder and it's a lot slower than 960 GTX fixed-fuction decoder.
You should compare Pascal against 960 GTX Maxwell.
__________________
Win 10 x64 (19042.572) - Core i5-2400 - Radeon RX 470 (20.10.1) HEVC decoding benchmarks H.264 DXVA Benchmarks for all |
10th September 2016, 13:21 | #49 | Link | |
Registered User
Join Date: Mar 2008
Posts: 448
|
Quote:
Did you use CUVID to decode the source video? Or CPU to decode? CUVID ---> Zero-copy to NVENC for encoding assuming if the video is DXVA-decodable. You could easily get 200 - 220 fps on 1920x1080p source video to 1920x1080p encoded video. Simplified: CPU decoding = HDD--->cpu--->RAM--->GPU--->HDD Pure hardware GPU decode + encode = HDD ---> GPU--->HDD |
|
11th September 2016, 04:18 | #53 | Link | |
Registered User
Join Date: Mar 2008
Posts: 448
|
Quote:
Or.... a variation of VBR Constant Quality ---> select normal VBR (not vbr2 as nvidia said it is designed for low latency 2 pass), set maximum bitrate 17500kbps (don't worry, it won't actually use 17500kbps) --qp-init 1 --lookahead 32 + 10bit encoding --aq --vbr-quality 26 (26 or 25) should be sufficient Note: In order to use VBRCQ (known as --vbr-quality) , must use VBR, max bitrate 17500 and --qp-init 1. -lookahead 32 and --aq are optional, but lookahead and adaptive quantization improve quality,so why not? **VBR2 doesn't work in conjunction with --vbr-quality, it will maxed out the 17500 bitrate instead of readjusting the bitrate/quality based on --vbr-quality) Last edited by JohnLai; 11th September 2016 at 04:24. |
|
12th September 2016, 12:00 | #54 | Link | |
Registered User
Join Date: May 2009
Posts: 184
|
Quote:
If I try adding --main 10 or --lookahead 32 in the custom command lines box then it just comes up with an error and won't start encoding. I expect it's because the latest StaxRip test build doesn't contain the latest rigaya CLI? Thanks. |
|
12th September 2016, 16:37 | #55 | Link | |
Registered User
Join Date: Mar 2008
Posts: 448
|
Quote:
Don't forget to update your driver too. Minimum driver version is 368.69 Edit: By the way....why you add "--main 10"? I thought rigaya nvencc command should be "--profile main10"? Last edited by JohnLai; 12th September 2016 at 16:40. |
|
12th September 2016, 17:05 | #56 | Link | |
Registered User
Join Date: Apr 2009
Posts: 478
|
Quote:
Anyway, the switch for 10-bit should be --output-depth 10. |
|
12th September 2016, 17:33 | #57 | Link | |
Registered User
Join Date: Mar 2008
Posts: 448
|
Quote:
Can't expect much from hardware encoders. For example, x265 crf 20 at very fast preset for live action film normally encoded with average QPI 18, QPP 20, QPB 23 or so depending on the content. Now, since nvenc doesn't support B-frame, you might wanna adjust Nvencc CQP to QPI 18 and QPP 20 respectively. Unfortunately, the file size is going to be quite big. General compression ratio for each frame is: I : 100% normally non-compressed or slightly compressed. P : 50% of I frame size B : 25% of I frame size Based on above.....let say we have GOP (group of picture) of 240 with IPBBB type (3 B-frames) where only I frame being inserted one time for each 240) We got: 1 I -frame = 1Mb 59.75 P-frames = 0.5Mb X 59.75 = 29.875Mb 179.25 B-frames = 0.25Mb X 179.25 = 44.8125Mb Total sizes = 1Mb + 29.875Mb + 44.8125Mb = 75.6875Mb Without B-frame: 1 I-frame = 1Mb 239 P-frames = 0.5Mb x 239 = 119.5Mb *Note: there is no fractional kind of frame, above is just a rough calculation [(119.5 / 75.6875 ) -1] X 100% = 57.886% larger size...... Edit: Only Intel QSV HEVC kinda follow the rule of 100%,50% and 25% by using B-frame as P-frame, my finding here http://forum.doom9.org/showpost.php?...postcount=1474 Last edited by JohnLai; 12th September 2016 at 17:40. |
|
12th September 2016, 20:26 | #59 | Link |
Registered User
Join Date: Aug 2010
Location: Athens, Greece
Posts: 2,901
|
Polaris has also HEVC 10 bit pure HW encoding
__________________
Win 10 x64 (19042.572) - Core i5-2400 - Radeon RX 470 (20.10.1) HEVC decoding benchmarks H.264 DXVA Benchmarks for all |
12th September 2016, 20:35 | #60 | Link |
Registered User
Join Date: Aug 2016
Posts: 6
|
You sure about that? I've only seen 10-bit HEVC decoding through UVD. No mention of encoding with VCE.
Also, this AMD employee seems certain that Polaris actually has a regression in that it does not support B-frames when encoding: https://github.com/GPUOpen-Libraries...s/AMF/issues/8 I'm most interested in the 2-pass encoding on Polaris, though as of yet it's still AWOL in their SDK. |
Thread Tools | Search this Thread |
Display Modes | |
|
|