Credit/blame PDR for this post; in a different thread he suggested that I investigate at what point QSV matches X264's quality, i.e. at the same bit rate, 10% more, 20% more, etc, because if it only takes a bit more bit rate to match it but is 4-5 times faster it may be worth it to use QSV for all encodes.
For this test, I used what has to be the toughest source I have ever tried to encode, Black Magic's Mountain Bike MOV found here:
https://www.blackmagicdesign.com/products/blackmagicpocketcinemacamera/workflow
I prepared the test source as outlined here:
https://forum.videohelp.com/threads/397165-X264-vs-Intel-QSV-on-Ubuntu-Linux
For the x264 encodes I used the latest AviDemux built from source, primarily because it's the only app I know of on Linux that allows me to set a target size. All encodes for x254 were done using 2 pass, with various configuration options, including what should be the "gold" standard for x264 encodes 2 pass + very slow + tune film, this encode took nearly 30 minutes to encode 1 min 6 sec 3840x1600p24 source. For this test I chose a target size of 100MB, which works out to 12.6 Mb/s bit rate. For anyone that thinks that "too much" or even "a decent amount", check out the encodes, they all look like crap that that bit rate, this test clip requires a lot more bit rate to look good.
Warning, there are a lot of test clips.
Notes: If you are wondering why I am doing this, it's because I have never seen a truly comprehensive quality comparison with multiple test encodes using the same source.
I'll probably upload some more QSV/VAAPI encodes tomorrow.
Enjoy.
Try StreamFab Downloader and download from Netflix, Amazon, Youtube! Or Try DVDFab and copy Blu-rays! or rip iTunes movies!
+ Reply to Thread
Results 1 to 10 of 10
Thread
-
-
ok, I guess folks would encode UHD as 2pass for such a source where guessing bitrate is a crystal ball job, also choosing bitrate that would look like crap (because not using CRF) AND using x264 for UHD. You nailed it again. Typical everyday Joe workflow.
Link is wrong.
btw. whats wrong with single ffmpeg encoding for tests? No complainants not having CRF. -
In what way is link wrong? If you're referring to BM link, that page has numerous samples, including this one, I just checked.
As for "guessing bitrate is a crystal ball job", what special kind of crystal ball do you think the CRF algorithm is using to choose a bit rate? For the record, CRf decides this clip needs a lot more bit rate than I used, try it for yourself, I didn't want people accusing me of using too much bit rate, people always complain that I should use less bit rate to highlight the differences.
Despite what some people think, like you obviously, CRF fairy dust that magically makes all video look great at some ideal bit rate, CRF has a tendency to balloon the bit rate used with certain types of sources. I just don't understand why people like you put so much blind faith in some over-hyped algorithm, instead of using your brains and thinking for yourselves. -
Why didn't you finish the other one first? You didn't finish investigating the Intel settings, I think something was up with that. If you used the same settings for Intel here, it's not really representative of QS
It's a good start, but it's not that "comprehensive" - because you have only 1 data point for a bitrate . How do you plot a graph with 1 point ?
If you cover a range of bitrates, then nobody can complain about the bitrate being too low or to high . If 12.6 was "crap", then maybe choose 15 or 20 as other points . Or maybe add one lower too to cover all the bases
CRF is ok, people prefer it because it's "faster" than 2 pass . So maybe CRF 18, 21, 24, or whatever, then hit those targets with other encoders for the direct comparisons. They are just rough guidelines , you don't have to use CRF if you don't want to
For metrics and plots, it doesn't matter as much if you match bitrates, because you're plotting a trend line, and interpolating. Not necessarily a direct comparison. . But obviously , for direct visual comparisons, should be the same bitrate (+/- 1% ) -
Yes everyone using H264 for their UHD video and limit bitrate because they want to save bitrate? That makes no sense. You'd encode HEVC if a bitrate is a concern. And for UHD heck, why even bother with H264? Just test some 1920x1080.
CRF topic and explanation is useless with you, it happened before, not going there. -
I agree, I think it's nearly impossible to get maximum quality out of QSV for normal users. I you read through Intel's docs it clearly says that for maximum quality you need to use CQP mode with custom QPI, but this requires that one manually analyse the content to be encoded, because there is no one QPI setting that works for all content. If this is not done, the docs continue, then CQP is likely to produce significantly worse quality than other modes.
So here goes, same source, a large number of test encodes using different parameters.
time ffmpeg -i "BMPCC6K_Mountain Bike.mkv" -c:v hevc_qsv -preset veryslow -extbrc 1 -rdo 1 -trellis 3 -bf 8 -refs 16 -adaptive_i 1 -adaptive_b 1 -b_strategy 1 -i_qfactor 1.0 -b_qfactor 1.0 -b:v 13M -maxrate 26M -bufsize:v 26M "/media/xx/One TB NVMe/1.mp4"
time ffmpeg -i "BMPCC6K_Mountain Bike.mkv" -c:v h264_qsv -preset veryslow -extbrc 1 -rdo 1 -trellis 3 -bf 16 -refs 16 -adaptive_i 1 -adaptive_b 1 -b_strategy 1 -i_qfactor 1.0 -b_qfactor 1.0 -b:v 13M -maxrate 26M -bufsize:v 26M "/media/xx/One TB NVMe/2.mp4"
time ffmpeg -i "BMPCC6K_Mountain Bike.mkv" -c:v h264_qsv -preset veryslow -extbrc 1 -rdo 1 -trellis 3 -bf 16 -refs 16 -b:v 13M -maxrate 26M -bufsize:v 26M "/media/xx/One TB NVMe/3.mp4"
time ffmpeg -i "BMPCC6K_Mountain Bike.mkv" -c:v hevc_qsv -preset veryslow -extbrc 1 -rdo 1 -trellis 3 -bf 8 -refs 16 -b:v 13M -maxrate 26M -bufsize:v 26M "/media/xx/One TB NVMe/4.mp4"
time ffmpeg -i "BMPCC6K_Mountain Bike.mkv" -c:v h264_qsv -preset veryslow -extbrc 1 -rdo 1 -trellis 3 -b:v 13M -maxrate 26M -bufsize:v 26M "/media/xx/One TB NVMe/5.mp4"
time ffmpeg -i "BMPCC6K_Mountain Bike.mkv" -c:v h264_qsv -preset veryslow -extbrc 1 -b:v 13M -maxrate 26M -bufsize:v 26M "/media/xx/One TB NVMe/6.mp4"
time ffmpeg -i "BMPCC6K_Mountain Bike.mkv" -c:v hevc_qsv -preset veryslow -extbrc 1 -b:v 13M -maxrate 26M -bufsize:v 26M "/media/xx/One TB NVMe/7.mp4"
time ffmpeg -i "BMPCC6K_Mountain Bike.mkv" -c:v h264_qsv -preset veryslow -b:v 13M -maxrate 26M -bufsize:v 26M "/media/xx/One TB NVMe/8.mp4"
time ffmpeg -i "BMPCC6K_Mountain Bike.mkv" -c:v hevc_qsv -preset veryslow -b:v 13M -maxrate 26M -bufsize:v 26M "/media/xx/One TB NVMe/9.mp4"
time ffmpeg -i "BMPCC6K_Mountain Bike.mkv" -c:v h264_qsv -preset veryslow -mbbrc 1 -b:v 13M -maxrate 26M -bufsize:v 26M "/media/xx/One TB NVMe/10.mp4"
time ffmpeg -i "BMPCC6K_Mountain Bike.mkv" -c:v h264_qsv -preset veryslow -rdo 1 -b:v 13M -maxrate 26M -bufsize:v 26M "/media/xx/One TB NVMe/11.mp4"
time ffmpeg -i "BMPCC6K_Mountain Bike.mkv" -c:v h264_qsv -preset veryslow -trellis 3 -b:v 13M -maxrate 26M -bufsize:v 26M "/media/xx/One TB NVMe/12.mp4"
time ffmpeg -i "BMPCC6K_Mountain Bike.mkv" -c:v hevc_qsv -preset veryslow -rdo 1 -b:v 13M -maxrate 26M -bufsize:v 26M "/media/xx/One TB NVMe/13.mp4"
time ffmpeg -i "BMPCC6K_Mountain Bike.mkv" -c:v hevc_qsv -preset veryslow -trellis 3 -b:v 13M -maxrate 26M -bufsize:v 26M "/media/xx/One TB NVMe/14.mp4"
time ffmpeg -i "BMPCC6K_Mountain Bike.mkv" -c:v hevc_qsv -preset veryslow -mbbrc 1 -b:v 13M -maxrate 26M -bufsize:v 26M "/media/xx/One TB NVMe/15.mp4"
Similar Threads
-
Pascal NVENC vs X264/x265 test
By sophisticles in forum Video ConversionReplies: 25Last Post: 5th Mar 2019, 02:15 -
x264 benchmark? what mobile chipset to do more fast encoding x264 encoding?
By marcorocchini in forum Newbie / General discussionsReplies: 1Last Post: 21st Sep 2018, 23:06 -
Where to Find Test/Sample MP4 Video Loop to Test Webcam?
By pone44 in forum Newbie / General discussionsReplies: 2Last Post: 10th Sep 2017, 18:50 -
Simple multi video format test - x264, x265 and webm
By ricardouk in forum Video ConversionReplies: 0Last Post: 1st Oct 2015, 10:37 -
x264 Mediainfo to MeGUI x264 Settings
By Arugen in forum Video ConversionReplies: 2Last Post: 13th Aug 2015, 01:14