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 30th August 2016, 15:10   #41  |  Link
JohnLai
Registered User
 
Join Date: Mar 2008
Posts: 448
Quote:
Originally Posted by Roph View Post
How were you able to anaylze the file? Mediainfo / streameye don't show such info, I'd like to poke around some more.

https://software.intel.com/en-us/int...o-pro-analyzer
Just use the trial version to find out everything.....
JohnLai is offline   Reply With Quote
Old 30th August 2016, 15:25   #42  |  Link
hajj_3
Registered User
 
Join Date: Mar 2004
Posts: 962
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.
hajj_3 is offline   Reply With Quote
Old 30th August 2016, 16:42   #43  |  Link
Yups
Registered User
 
Join Date: Sep 2011
Posts: 212
Quote:
Originally Posted by pandy View Post
As i struggle still on HW encoding (still some options are not work as described or work completely opposite) perhaps you can share command line (ffmpeg) to compare NVenc vs QSV - for today my observations are rather solid that QSV is somehow slightl slower than NVEnc and also QSV seem to be less robust (NVEnc work like a charm - just start and almost imeediately encoding session started, Intel is somehow slow in starting and need some time between starting session - i assume to close previous session - not sure how this is related to ffmpeg itself).

ffmpeg is slow, no wonder. Make sure you are using the fixed function decoder for encoding and QSVEnc is the best.


Quote:
Originally Posted by hajj_3 View Post
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.

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.
Yups is offline   Reply With Quote
Old 30th August 2016, 16:51   #44  |  Link
JohnLai
Registered User
 
Join Date: Mar 2008
Posts: 448
Quote:
Originally Posted by Yups View Post
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.
Hardware is not fine.
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.....
JohnLai is offline   Reply With Quote
Old 30th August 2016, 17:04   #45  |  Link
Yups
Registered User
 
Join Date: Sep 2011
Posts: 212
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.
Yups is offline   Reply With Quote
Old 31st August 2016, 00:17   #46  |  Link
ilovejedd
insane college undergrad
 
ilovejedd's Avatar
 
Join Date: Jun 2006
Location: middle of nowhere
Posts: 405
Quote:
Originally Posted by JohnLai View Post
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.
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.
ilovejedd is offline   Reply With Quote
Old 10th September 2016, 11:49   #47  |  Link
Yups
Registered User
 
Join Date: Sep 2011
Posts: 212
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.
Yups is offline   Reply With Quote
Old 10th September 2016, 11:58   #48  |  Link
NikosD
Registered User
 
Join Date: Aug 2010
Location: Athens, Greece
Posts: 2,757
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 (19041.388) - Core i3-9100F - nVidia 1660 (451.67)
HEVC decoding benchmarks
H.264 DXVA Benchmarks for all
NikosD is offline   Reply With Quote
Old 10th September 2016, 13:21   #49  |  Link
JohnLai
Registered User
 
Join Date: Mar 2008
Posts: 448
Quote:
Originally Posted by Yups View Post
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.
Hmm? Something isn't right with your gtx 970 figures.
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
JohnLai is offline   Reply With Quote
Old 10th September 2016, 15:00   #50  |  Link
Yups
Registered User
 
Join Date: Sep 2011
Posts: 212
I have been using NVEncC (avcuvid native) in Staxrip which is the fastest alongside QSVEnC (Intel). I don't think there is something wrong.
Yups is offline   Reply With Quote
Old 10th September 2016, 15:08   #51  |  Link
JohnLai
Registered User
 
Join Date: Mar 2008
Posts: 448
Quote:
Originally Posted by Yups View Post
I have been using NVEncC (avcuvid native) in Staxrip which is the fastest alongside QSVEnC (Intel). I don't think there is something wrong.
Hmm.........in that case, I have no further comment.
JohnLai is offline   Reply With Quote
Old 11th September 2016, 04:09   #52  |  Link
aegisofrime
Registered User
 
Join Date: Apr 2009
Posts: 462
I have a GTX 1070 as well and am wondering how best to tune it for maximum quality while maintaining decent speed.
aegisofrime is offline   Reply With Quote
Old 11th September 2016, 04:18   #53  |  Link
JohnLai
Registered User
 
Join Date: Mar 2008
Posts: 448
Quote:
Originally Posted by aegisofrime View Post
I have a GTX 1070 as well and am wondering how best to tune it for maximum quality while maintaining decent speed.
Use staxrip default CQP rate control plus --lookahead 32 and 10bit HEVC encoding...

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.
JohnLai is offline   Reply With Quote
Old 12th September 2016, 12:00   #54  |  Link
RainyDog
Registered User
 
Join Date: May 2009
Posts: 184
Quote:
Originally Posted by JohnLai View Post
Use staxrip default CQP rate control plus --lookahead 32 and 10bit HEVC encoding...

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)
Hi John, do you know what I need to do in order to get the new Pascal encoding options to work through StaxRip on my GTX 1060 please?

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.
RainyDog is offline   Reply With Quote
Old 12th September 2016, 16:37   #55  |  Link
JohnLai
Registered User
 
Join Date: Mar 2008
Posts: 448
Quote:
Originally Posted by RainyDog View Post
Hi John, do you know what I need to do in order to get the new Pascal encoding options to work through StaxRip on my GTX 1060 please?

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.
Yes. Just replace the Nvencc with the latest build from rigaya http://rigaya34589.blog135.fc2.com/blog-entry-814.html

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.
JohnLai is offline   Reply With Quote
Old 12th September 2016, 17:05   #56  |  Link
aegisofrime
Registered User
 
Join Date: Apr 2009
Posts: 462
Quote:
Originally Posted by JohnLai View Post
Yes. Just replace the Nvencc with the latest build from rigaya http://rigaya34589.blog135.fc2.com/blog-entry-814.html

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"?
Thanks for your reply. I actually tried it, speeds are great but unsurprisingly quality still falls far below x265. Well, can't have the best of both worlds I guess.

Anyway, the switch for 10-bit should be --output-depth 10.
aegisofrime is offline   Reply With Quote
Old 12th September 2016, 17:33   #57  |  Link
JohnLai
Registered User
 
Join Date: Mar 2008
Posts: 448
Quote:
Originally Posted by aegisofrime View Post
Thanks for your reply. I actually tried it, speeds are great but unsurprisingly quality still falls far below x265. Well, can't have the best of both worlds I guess.

Anyway, the switch for 10-bit should be --output-depth 10.
Can't blame me for not knowing After all, I don't own pascal gpu. (Only maxwell gpu for me)
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.
JohnLai is offline   Reply With Quote
Old 12th September 2016, 20:24   #58  |  Link
trip_let
Registered User
 
Join Date: Sep 2012
Posts: 47
Quick confirmation: only Pascal (Nvidia 10 series) and Kaby Lake (Intel 7 series Core) so far has any kind of total or hybrid hardware 10 bit HEVC encode? For consumer stuff, that is.
trip_let is offline   Reply With Quote
Old 12th September 2016, 20:26   #59  |  Link
NikosD
Registered User
 
Join Date: Aug 2010
Location: Athens, Greece
Posts: 2,757
Polaris has also HEVC 10 bit pure HW encoding
__________________
Win 10 x64 (19041.388) - Core i3-9100F - nVidia 1660 (451.67)
HEVC decoding benchmarks
H.264 DXVA Benchmarks for all
NikosD is offline   Reply With Quote
Old 12th September 2016, 20:35   #60  |  Link
Roph
Registered User
 
Join Date: Aug 2016
Posts: 6
Quote:
Originally Posted by NikosD View Post
Polaris has also HEVC 10 bit pure HW encoding
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.
Roph 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 14:02.


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