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. |
15th September 2019, 11:05 | #1 | Link |
Registered User
Join Date: Oct 2001
Location: NZ
Posts: 44
|
Turing GPU cards and 10 bit HEVC
Hi,
I encode 1080 TV rips using Handbrake and a Ryzen 2400G - CPU averages 12 fps, using the GPU 70 fps but bigger files and lesser quality (and no 10 bit encoding). On a Surface Book 2 laptop using Intel Core i5 I get 30 fps using GPU and better quality than the Ryzen GPU for similar files size. I am wondering if the NVIDIA Turing graphics cards are likely to be able to match CPU quality and file size - anyone tried this? John |
15th September 2019, 12:58 | #2 | Link |
Registered User
Join Date: Jan 2009
Posts: 5
|
Yes, they do. I recently bought an RTX card to test it by myself after reading this https://unrealaussies.com/tech/nvenc...c-qsv-vp9-av1/ & I got the same result, Turing HEVC is very, very good for its awesome speed.
|
15th September 2019, 15:01 | #3 | Link |
Registered User
Join Date: May 2009
Posts: 328
|
Basically, as long as you’re not starving for bitrate, Turing is on par with x265 Slow <-- Hardware needs more bitrate to compare to CPU. Current ASICS can not compare to x265 slow when you are going for the smallest file size possible. But the fact that you are getting 12fps on a 2400G means you aren't doing "quality" encodes, as on my 2700 I get 7-8 fps doing 1080p TV rips on slow.
The longer the encoding process, the better the end results. |
15th September 2019, 23:14 | #5 | Link |
RipBot264 author
Join Date: May 2006
Location: Poland
Posts: 7,806
|
Can somebody encode parkjoy.y4m using turing encoder? Let's say 2pass 10 Mbps.
__________________
Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper |
16th September 2019, 00:04 | #6 | Link |
Registered User
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,406
|
Can you provide a link so we start with the right encode?
Edit: I assume: https://media.xiph.org/video/derf/ is the right source. I used this command line on my 2080 Ti: Code:
C:\Tools\ffmpeg\bin\ffmpeg -loglevel debug -threads 1 -i %1 -c:v hevc_nvenc -b:v 10M -maxrate:v 15M -bufsize:v 12M -preset slow -profile:v main10 -rc vbr_hq -rc-lookahead:v 32 -spatial_aq:v 1 -aq-strength:v 8 -c:a none -pix_fmt yuv420p10le -f mp4 "D:\encode\output.mp4"
__________________
madVR options explained Last edited by Asmodian; 16th September 2019 at 01:48. |
16th September 2019, 12:01 | #7 | Link |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
GTX 1660 Ti 1080p and 2160p "Park Joy".
Code:
ffmpeg -i "park_joy_1080p50.y4m" -f yuv4mpegpipe -strict -1 - | nvencc64 -c hevc --vbrhq 0 --vbr-quality 31 -u quality --output-depth 10 --lookahead 32 -b 5 --ref 7 --nonrefp --aq --aq-temporal --bref-mode middle --mv-precision q-pel -i - -o "park_joy_1080p50_31.mkv" ffmpeg -i "park_joy_2160p50.y4m" -f yuv4mpegpipe -strict -1 - | nvencc64 -c hevc --vbrhq 0 --vbr-quality 40.5 -u quality --output-depth 10 --lookahead 32 -b 5 --ref 7 --nonrefp --aq --aq-temporal --bref-mode middle --mv-precision q-pel -i - -o "park_joy_2160p50_40.5.mkv" x264 "park_joy_1080p50.y4m" --preset veryslow --tune film --pass 1 --bitrate 10000 -o "park_joy_1080p50_x264.264" x264 "park_joy_1080p50.y4m" --preset veryslow --tune film --pass 2 --bitrate 10000 -o "park_joy_1080p50_x264.264" https://mega.nz/#F!gs9XkKbY!e6AqQ0Vi6m1PAGQMJu0zZQ |
16th September 2019, 12:22 | #8 | Link | |
RipBot264 author
Join Date: May 2006
Location: Poland
Posts: 7,806
|
Quote:
Looks like old good x264 is still in higher league x264 (AVC) https://i.imgsafe.org/f6/f6fe9758cb.png NVidia Turing (HEVC) https://i.imgsafe.org/f6/f6fe71322c.png
__________________
Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper |
|
16th September 2019, 13:23 | #9 | Link |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
x264 does much better on the textures, yes. But to be fair: park joy is a killer sample and x264 shows some heavy artifacts. x264 --preset veryslow --tune film --crf 20 ends up using 48733.96 kbps. Above we only used 1/5 of that.
|
16th September 2019, 14:55 | #10 | Link |
RipBot264 author
Join Date: May 2006
Location: Poland
Posts: 7,806
|
That sample separates men from boys Crowd run is also a killer sample...
__________________
Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper |
16th September 2019, 18:45 | #12 | Link |
Registered User
Join Date: May 2009
Posts: 328
|
Why are you using quality in one and bitrate in another? If we are going to do apples to apples, it should be quality vs crf (as GPU has no CRF) and the resulting file size, as that is as close as we can come to not using a strict bitrate limit to see the difference. Am I right in assuming this, or so wrong that I'm dumb for even stating it?
|
16th September 2019, 19:47 | #13 | Link | |
RipBot264 author
Join Date: May 2006
Location: Poland
Posts: 7,806
|
Quote:
__________________
Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper |
|
16th September 2019, 20:06 | #14 | Link |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
FWIW: I added encodes at ~20 and ~50 Mbps to the MEGA folder.
Here you can find a short test I did on a sample that's more like your typical Hollywood movie/show. I believe there the difference isn't that much. x264 with its usual better keeping of the graininess and sharpness in exchange for some more uglier artifacts here and there. I think the x264 artifacts are best seen in motion and not so much in the screenshots. |
16th September 2019, 22:00 | #15 | Link |
Registered User
Join Date: May 2009
Posts: 328
|
But the whole point of x265 is to have smaller files with a given trade off for visuals. The idea is to have the smallest files possible with the best visuals. GPU requires much more bitrate than CPU does. Take the same samples and bring the bitrate down to 1000, 1500, 2000 and you would see that CPU destroys GPU. At 10mbit, even divx/xvid would look fantastic.
10mbit is extremely high for x265, at least in my experience. |
16th September 2019, 22:06 | #16 | Link |
RipBot264 author
Join Date: May 2006
Location: Poland
Posts: 7,806
|
We are taking about x264 vs nvenc h.265 not x265! If you think that 10mbps is alot then encode parkjoy or crowdrun sample with that xvid and then show us what mess you got.
__________________
Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper Last edited by Atak_Snajpera; 16th September 2019 at 22:11. |
16th September 2019, 23:12 | #17 | Link | |
Registered User
Join Date: Sep 2007
Posts: 5,346
|
Quote:
Thanks sneaker, Can you add x264 10bit , x264 10bit encodes as well ? As you know ,x265 is highly adjustable- if you're going for smoother, cleaner vs. detail retention , vs. whatever And what about Turing? Is there some set of settings that enables it to retain more details vs. smoothing trade off ? |
|
17th September 2019, 09:59 | #19 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,752
|
Quote:
There are certainly encode times where Turing HEVC will outperform x264. Also, Turing encodes can happen in parallel to CPU tasks. So on GPU encoding is very nice for things like Twitch where gaming performance can't be impacted much during real-time encoding. |
|
17th September 2019, 10:02 | #20 | Link | |
Lost my old account :(
Join Date: Jul 2017
Posts: 322
|
Quote:
I would like to see Tears of Steal @ 1080p encoded in the 4-8Mbps range, and tune x264 at the same speed as nvenc. I havnt actually seen how turing HEVC perform in the "rip" scenario so it would be interesting to see how it performs for more "real" movie content. Last edited by excellentswordfight; 17th September 2019 at 10:05. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|