Intel Arc A380 – Does it encode?!?

Yes, the Intel Arc A380 encodes video! Wow! Easy Peasy!

Phew! That was an easy article! Pack it up boys, girls and synths! It's time to move on to the next article! :D - S

Okay, obviously that would be a cop-out and a sad excuse to get clicks. But unlike shitty AI bloggers. We have video to back up our proof!

As Covid, chip shortage, cryptocurrency, and video card prices got crazy stupid in 2022. We witnessed businesses spend $450 on a Geforce 1050ti (normally $125 at the time) because they needed SOMETHING to work with Adobe products. Getting a 30xx series Nvidia card was just about $2,000 which given it was supposed to come at an initial price point of $600 the world of 3-D graphics cards was undoubtedly a stupid time! Now, these companies claim that they learned from their mistakes and will start building chip companies in different countries around the world instead of coming from a single location which sounds great and all. But that unfortunately will not be tested until we get another incident that shits out the entire world economy or shipping industry.

But then, out from the shadows of onboard laptop graphics chipsets. Intel announced the "ARC" series. An affordable graphics card that is good for gaming and applications. This article is going to focus a lot more on the video editing side of the ARC as it seems to shine better than the gaming side of things.

Would you like to know more? Read on!

Disclaimers:

S-Config.com has not been contacted by Intel, ASRock, or any of its subsidiaries for this review. No money has exchanged hands. Not even a correspondence e-mail has been sent to low-lives such as ourselves. S is just an end-user of a production thrashing around on a keyboard about as hard as everyone else out there and thus is not responsible for any damage that occurs be it mental, physical, financial, or psychological. Use your brain and think for yourself.

Results of the video encoded with the Intel ARC A380.

Initially, We were going to just record some game footage and call it a day. Although considerably more demanding than video such as an FPS where you're jumping off of walls and rail-gunning randos. A more realistic application would be an actual video. So, time to touch some fucking grass! We went filming about a minute worth of "B-Roll" footage of downtown Milwaukee. Originally shot on an iPhone 13 because when you get free tech from a reasonably rich associate you can't bitch about who makes it. It was shot at 4k with 60 frames per second.

"Note: If you get a black screen but the audio is playing. Or you got a potato PC and it's studdering. We have fallback Links below."

Video tutorial fallback mirrors:

In case you have no-script enabled or for some reason cannot see the title video on this website. We have provided direct links for these videos. For more information about the standards we use on this site click here if you would like to know more.

AV1       - Link
WEBM VP9  - Link
MP4/.h265 - Link
MP4/.h264 - Link

Getting the card.

When Intel announced a low-power card gaming card that was not their embedded IGP crap and was an actual gaming card; It boasted that it can hardware encode AV1 video. Given that we are self-hosting video content here at s-config.com. We didn't give a shit about how well it can game. Better video encoding hyped us up a lot! We'll take any advantage that we can get when it comes to video encoding. Because holy hell is it taking forever to encode some of these newer formats! (more details on that later.) We wanted one upon the Intel announcement. But unfortunately, this card was not available in the States and was first released to the Chinese market. It was only available for China and they were the first ones to beta-test this product.

Perhaps it was for the best as Linux people were having problems getting the card initialized for X-desktop and it was almost a crap shoot if the card would even boot up inside of the PC that you have. On top of that, encoding support was only available in closed-source streaming software and not available for FFMPEG until near the release of the US markets.

The only way to get this card before it hits the States is to either be a high-end YouTuber to have Intel give it to you for review. Or to be the same shit scalpers that sent video card prices soaring in the first place stupid amounts of money to get it imported into the states. (We've seen eBay prices go up to$500 for this card.) This could just be years us of being lied to on commercials however you have to question the motivations behind said YouTuber for doing reviews on behalf of Intel.

Pitfalls of beta-testing in other countries.

Intel originally stated that this card was beta-tested in the Chinese markets. Which comes with a bit of a problem. In China, the limitation of 2 hours a week is focused primarily on teenagers when it comes to gaming but something tells me there was not a single teen that was testing these GPU cards. As adults, they may be more tuned for doing productivity applications like Adobe products and CAD products. Which is important but missing out on an entire market of gamers.

This could eventually bite Intel in the ass as when they introduced this card as a 'Gaming Equiviant' to Nvidia and ATI here in the States.  Considering the gaming community is incredibly hostile to first impressions. To a gamer, it's irrelevant that ATI (now AMD) used to start as a video card painting wall textures in Quake 3 like it was crayons because ATI lied about their texture performance in the 90s with the Radeon 9700. You just can't say anything bad about their beloved company. Any new company that comes into the playfield of gaming now has to make zero mistakes or else be blacklisted.

To be honest, those standards are fucking unrealistic.

There were weird issues where you get good FPS in a modern game like Cyberpunk 2077 but the frame drop would be real in old games like Counterstrike. A lot of these problems came down to driver issues that weren't thoroughly tested by a country that hates gaming. To Intel's credit, a lot of that is getting cleaned up resulting in a progressively more stable card for those into gaming on the thing.

Oh, I have to do a thing with my BIOS that I've never done before Intel? Huh...

Another issue upon launch was Intel didn't really warn people about the system requirements for their gaming card and how it behaves a little differently than most cards on the market on how it tends to work 'WITH' your processors instead of being a stand-alone product like the two giants in the world. It of course does now with the modern drivers released from Intel. However, the lack of communication leads to less than desirable-results coming out of the card. Thus, you have gamers taking this card and jamming it into their potato PC and expecting miracles when in fact it falls on its face.

This has been corrected as well and at least tells the end-user that without a bridge you're seriously limited in your cards throughout for graphic performance.

The Hardware.

Picked it up off of NewEgg for $110 + 9 S&H. Picture was taken after opening in order to ruin the unboxing fetish crowd.

Anytime we see "OC Edition" on a box we realistically think "Reduced lifespan" edition because if you're overclocking an engineered GPU it is producing more heat than it should. You obviously do not want people to hold onto a card for more than a few months to a year before buying more. Keep that consumer purchase cycle in a state of constant perpetually right ASRock?

We are happy to confirm with you guys. We didn't get a box of meth! It's certainly a graphic card we got! You can in this picture that ASRock tried to do the Pentium 4 heatsink fan concept on this card however because of how to offset the GPU about the fan it's a bit of a ham-fisted approach to cooling. We ripped off that plastic unceremoniously before jamming it into our motherboard.

Serial numbers blurred to protect the guilty.

Okay, you can seriously tell that ASRock sourced their ABS plastic well before they got done designing the PCB itself. So when they finally went to assemble the card they were looking over at those plastic tapping ports and went:

FUCK!

At least that is what we would probably do.

This ultimately brings up an obvious thermo-dynamic engineering problem with this card. The plastics serve no purpose and trap heat in the graphics card. It doesn't blow out the side vent of the graphics card as it's not a squirrel box fan nor is there any closure around the card to force the air down a particular path. The only real useful aspect of the plastics is the lip around the fan blades to direct airflow. THAT'S IT!!!!

Blogger misinformation.

This hits a little close to home when people blog about a product and say the same thing we could've gotten off the Intel PR page. Or if their article sounds like it was ChatGPT generated and rubber-stamped by some asshat looking for SEO content. Of course, this is why search engines such as Google/Bing are becoming irrelevant. When you ask a specific question about an application working with hardware you end up with pages of fluff pieces. Fuck, you're better off searching the pits of Reddit at this stage.

But what is worse than that? Answer: It's when they lie about a product in some pathetic attempt to upsell end-users to the latest model.

When this card finally hit the US markets. Understandably it didn't get a good reception because their highest-end Intel ARC card which was the series 770 did about as well as a Geforce 2060. But when looking up information about FFmpeg and encoding video on the Intel ARC you end up individuals like this:

Accelerated AV1 encode with Intel discrete graphics hardware is available with their DG2/Alchemist GPUs such as the recently launched Arc Graphics A750 and A770 models. - phoronix.com

To say that it only works with certain cards is a bit of misdirection. At least he mentioned that FFMpeg doesn't need a card like this which is stating the obvious. The author who wrote this also tends to break apart his articles into multiple pieces forcing the reader to click through his website to give the illusion of 'traffic' in the eyes of Google and SEO. We get keeping your readers engaged with your articles but when you tell a user to check out FFMpegs GitHub, people are expecting to go to that GitHub, not be hit with another article THEN maybe a link to FFMpegs GitHub.

Why do bloggers make articles on products they have never tested?!? Just bragger right to say they are first? Guess we're just frustrated with guys like this because we were seriously looking for technical information about encoding with our Intel Arc card but found nothing of use, just a whole fuckton of noise out on the internet!

Meat VS. Metal Time! Let's legit test this A380!

We here at S-Config always hold onto the concept:

What does it do? How well does it do it? - Sean "The Fucking man" Kennedy

Understand that we aren't scientists. We are just random users like anyone who stumbles across this site and are prone to mistakes. But we WILL share our findings instead of giving you a cosmic blogging hand-job and walking away. You can leave a comment below if you have a better idea of how to use this card or if you see that our findings are wrong. In accordance with our FAQ keep it civil or our comment moderation bots will suplex your response right into the trash can.

Some ground rules.

• We will attempt to use an FFmpeg recipe as close as possible to each other's parameters. Some elements during this process are a little out of our control as to whether a particular library will or will not use all of the parameters provided.
• Unlike a stream. We will ask the codecs to give us the best possible compression instead of the fastest encoding time. This is way more important for websites that wish to host their video instead of quickly encoding in real-time and blasting it out to a watcher like a streamer demands out of a card like this.
• We will be using a program called FFMetrics to attain the VMAF, SSIM, and PNSR ratings. Now for those who don't know what those acronyms mean this blog does a hell of a job explaining the technical pros and downfalls of each measurement standard. In particular how AV1s can fool SSIM values because the video does not block at low bit-rates as much as it does blur. Also, to make FFMetrics job easier. We will be feeding two videos both using FFmpegs lossless codec standard. One of the original videos, and finally, one after encoding is complete.
• As this is a 4k video we are encoding; We will assign a VBR of 4000Kb/sec. Originally this test was done at 600Kb/sec but we feel we are being too generous. So instead we gave an average bitrate to present a challenge to each of the codecs. The minimum bitrate of 0.5x maximum bitrate of 2.0x. A buffer of 3.0x (although you will notice we reduced the buffer to 2x which had no real impact during encodes). Apologies for any buffering issues to those reading on I2P or Tor.
• This test video was filmed in Downtown Milwaukee using an iPhone 13. We are aware that affects the overall encode performance as this was not caught on a RAW/Lossless camera. Because well, we're not made of money for this experiment. However, it's probably the most realistic approach as in this day and age everyone has a phone. Also with some of the post editing with OpenShot such as half-second fades between scenes. It introduced stress points that were good for testing.
• The footage was edited on OpenShot and saved in a lossless WEBM format.
• Although we aren't scientists by any stretch of the imagination nor would we dare classify ourselves as such as we feel what we're doing is almost like taking a piss on the profession itself. We will document this in such a way that what we are doing can be repeatable for anyone rocking an Intel Arc card.
• Unlike our first test revision. All audio will be encoded to the same codec. Opus 96k. Most modern players can handle an audio codec change like this. This should eliminate any fluctuations in filesize from the audio side of encoding.

About FFMPEG - Revised 09/27/2024

ffmpeg version 2024-09-16-git-76ff97cef5-full_build-www.gyan.dev Copyright (c) 2000-2024 the FFmpeg developers
built with gcc 13.2.0 (Rev5, Built by MSYS2 project)
configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-bzlib --enable-lzma --enable-libsnappy --enable-zlib --enable-librist --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-sdl2 --enable-libaribb24 --enable-libaribcaption --enable-libdav1d --enable-libdavs2 --enable-libopenjpeg --enable-libquirc --enable-libuavs3d --enable-libxevd --enable-libzvbi --enable-libqrencode --enable-librav1e --enable-libsvtav1 --enable-libvvenc --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxeve --enable-libxvid --enable-libaom --enable-libjxl --enable-libvpx --enable-mediafoundation --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-libharfbuzz --enable-liblensfun --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-dxva2 --enable-d3d11va --enable-d3d12va --enable-ffnvcodec --enable-libvpl --enable-nvdec --enable-nvenc --enable-vaapi --enable-libshaderc --enable-vulkan --enable-libplacebo --enable-opencl --enable-libcdio --enable-libgme --enable-libmodplug --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libshine --enable-libtheora --enable-libtwolame --enable-libvo-amrwbenc --enable-libcodec2 --enable-libilbc --enable-libgsm --enable-liblc3 --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-ladspa --enable-libbs2b --enable-libflite --enable-libmysofa --enable-librubberband --enable-libsoxr --enable-chromaprint
libavutil 59. 36.100 / 59. 36.100
libavcodec 61. 13.100 / 61. 13.100
libavformat 61. 5.101 / 61. 5.101
libavdevice 61. 2.101 / 61. 2.101
libavfilter 10. 2.102 / 10. 2.102
libswscale 8. 2.100 / 8. 2.100
libswresample 5. 2.100 / 5. 2.100
libpostproc 58. 2.100 / 58. 2.100

As FFMpeg is always changing I post this here for everyone's reference. I'm using the full build versions off of gyan.dev .

About FFmetric - Revised 09/27/2024

Using FFMetrics v1.5b8 with FF1YUV lossless video encapsulated in MKV format for source and comparison to eliminate any divergence between the two encodes.

C:\bin\ffmpeg\bin\ffmpeg -i D:\vid\MyMilwaukee.webm -vcodec ffv1 -level 3 -g:v 1 -pass 1 -an -passlogfile D:\tmp\my_passlog_ffv1 -f null NUL
C:\bin\ffmpeg\bin\ffmpeg -i D:\vid\MyMilwaukee.webm -vcodec ffv1 -level 3 -g:v 1 -pass 2 -acodec copy -passlogfile D:\tmp\my_passlog_ffv1 D:\tmp\original.mkv

This was necessary to bring it into the ffv1 format as webm encoding tended to upset the overall measurement of video quality.

Then, after the video was encoded to its destination the following command was passed (this was for our A380 encodes but this part was used for everything)

C:\bin\ffmpeg\bin\ffmpeg -i D:\vid\MyMilwaukee-HW-AV1.mp4 -vcodec ffv1 -level 3 -g:v 1 -pass 1 -an -passlogfile D:\tmp\my_passlog_ffv1a -f null NUL
C:\bin\ffmpeg\bin\ffmpeg -i D:\vid\MyMilwaukee-HW-AV1.mp4 -vcodec ffv1 -level 3 -g:v 1 -pass 2 -acodec copy -passlogfile D:\tmp\my_passlog_ffv1a D:\tmp\encoded-A380AV1.mkv

Keep in mind this was for measurement purposes only and produced 9GB per minute files which prompted me to point to my spinning rust D:\ drive on our windows box wherein we could hold 96GB of 8x 1 minute test footage.

If you don't care about the measurements. You can completely skip these commands and FFMetric for that matter.

About the Test PC.

• 4th gen Intel(R) Core(TM) i5-4570S CPU @ 2.90GHz 2.90 GHz
• 16gb G-Skill DDR3 ram.
• 250GB Samsung SSD Drive
• 1TB Western Digital Spinning Rust Drive.
• OCZ 600Watt PSU (little overkill there)
• ASRock H97M Motherboard
• ASRock Intel A380 (redundant statement is redundant)

What the fuck S.... - Anonymous

This is probably the first thought most are thinking when we choose this PC as my test bench for the Intel ARC. It's 4th gen and doesn't have bridge support because all of the techs are in 2013. It's probably a miracle that the Intel ARC even booted up on such an old motherboard (we unironically kept the manufacturer ASRock synced ). This is what I used when we streamed with Nvidia. Streamers would often have a secondary PC and the only goal of that PC is to transcode data and send it off to the server. Not just for the reasons that we're too cheap to invest in a 2080 or above and do everything on a single PC. But there's always a risk of a hard crash while gaming. So, instead of taking down your entire channel. you can at least go into standby and talk to peeps while your main rebooted. Redundancy.

We also used this as the media PC hooked up to our main TV for getting anime from "The usual sources" which are outside of the scope of this article.

This build is responsible for a lot of the videos you see on this site. We could make and edit the video on my main, and then let this idle away for a day or two making the video while we write up the article. Chances are, it's probably similar to what a lot of people start with when they're building a desktop out of hand-me-down technology. I think we spent $20 and that was for the heatsink on this bad boy. Thus, the intel ARC card is probably the biggest investment we've spent on this box.

This is also an excellent test bed because, underneath the borderline worst-case scenario, we will see how well and how fast videos are encoded with software and how big of a difference a card like an ARC can make even in a system like this. Because of the lack of bridge support the ARC will probably perform at its absolute worst.

During hardware "QSV" Encoding.

This could be the result of the lack of bridge support. It's interesting how when we FFmpeg encoded with an Nvidia card the CPU was low. but in this case, the ARC is attempting to hand off information to the poor 4th-generation processor and as a result 100 percent of the system. Meanwhile, the intel ARC bounces around from 10 to 40 percent during encoding.

The results:

You've already seen the hardware-encoded video at the top. now, this is the software-encoded video. All recipes are to follow.

"Note: If you get a black screen but the audio is playing. Or you got a potato PC and it's studdering. We have fallback Links below."

Video tutorial fallback mirrors:

In case you have no-script enabled or for some reason cannot see the title video on this website. We have provided direct links for these videos. For more information about the standards we use on this site click here if you would like to know more.

AV1       - Link
WEBM VP9  - Link
MP4/.h265 - Link
MP4/.h264 - Link

Unlike the videos at the very top of the article. These are the software-encoded versions. The original video was shot at 4k@60fps on an iPhone 13.

Now if you have no idea what the recipes are doing we'd suggest you check out our previous blog about how we FFmpeg encode videos.

AV1 Encoding.

Hardware encoded ARC380-Encoded-MyMilwaukee.av1

Recipe:

ffmpeg -benchmark -y -extra_hw_frames 40 -i D:\tmp\original.mkv -c:v av1_qsv -preset veryslow -extbrc 1 -look_ahead_depth 8 -b:v 4M -bufsize 8M -rc_init_occupancy 2M -low_power 0 -adaptive_i 1 -adaptive_b 1 -b_strategy 1 -bf 7 -pass 1 -passlogfile D:\tmp\my_passlog_av1 -c:a libopus -b:a 96k -threads 0 -movflags +faststart -f null NUL 2>> "D:\tmp\ffmpeg-av1HD.log"
ffmpeg -benchmark -y -extra_hw_frames 40 -i D:\tmp\original.mkv -c:v av1_qsv -preset veryslow -extbrc 1 -look_ahead_depth 8 -b:v 4M -bufsize 8M -rc_init_occupancy 2M -low_power 0 -adaptive_i 1 -adaptive_b 1 -b_strategy 1 -bf 7 -pass 2 -passlogfile D:\tmp\my_passlog_av1 -c:a libopus -b:a 96k -threads 0 -movflags +faststart -f mp4 D:\vid\MyMilwaukee-HW-AV1.mp4 2>> "D:\tmp\ffmpeg-av1HD.log"

Software encoded OneMinuteMilwaukee-SW-AV1.mp4

Recipe:

ffmpeg -benchmark -y -extra_hw_frames 40 -i D:\tmp\original.mkv -c:v libsvtav1 -preset 8 -b:v 4M -minrate 2M -bufsize 8M -pass 1 -passlogfile D:\tmp\my_passlog_sw_av1 -c:a libopus -b:a 96k -threads 0 -movflags +faststart -f null NUL 2>> "D:\tmp\ffmpeg-av1SW.log"
ffmpeg -benchmark -y -extra_hw_frames 40 -i D:\tmp\original.mkv -c:v libsvtav1 -preset 8 -b:v 4M -minrate 2M -bufsize 8M -pass 2 -passlogfile D:\tmp\my_passlog_sw_av1 -c:a libopus -b:a 96k -threads 0 -movflags +faststart -f mp4 D:\vid\MyMilwaukee-SW-AV1.mp4 2>> "D:\tmp\ffmpeg-av1SW.log"

• Filesize software encoded: 27.563 KB
• Filesize hardware encoded: 30,008 KB
• FFMPEG VMAF software: min="33.960734" max="100.000000" mean="90.607876" harmonic_mean="89.688837"
• FFMPEG VMAF hardware: min="36.438805" max="100.000000" mean="83.787186" harmonic_mean="82.657564"
• Software Bench Encode time (1st pass): utime=3463.672s stime=114.391s rtime=4690.729s
• Software Bench Encode time (2nd pass): utime=3455.594s stime=108.453s rtime=1409.019s
• Hardware Bench Encode time (1st pass): utime=708.953s stime=9.703s rtime=223.721s
• Hardware Bench Encode time (2nd pass): utime=728.221s stime=10.203s rtime=243.332s

Comments: The time for software encoding dropped significantly from the first time we ran this test. However, This is the reason why you buy a card like this. If you are recording a lot of 4k video, and you need to transcode it quickly. If you use a constant bit-rate or a variable as we did. The Intel ARC performed at around 7-12fps during the encoding process which getting a 1-minute video back in 6-7 minutes is far nicer than hours for the software-encoded version. the VMAF dipped hard, especially around the cross-fades of our video and it is visually noticeable but then immediately goes into the upper 80s throughout the rest of the video. The software did win out on both file size and quality which ultimately is what video bloggers are looking for.

Again, if we put this bad boy on a better processor and bridging, it would probably render real-time. Gotta find that one out!

AV1 FFmetric graphing.

FFMetric appears to be a lot less critical about the image quality versus the built-in metric of FFMpeg. Where during any transition scene it does dip to the 60's in VMAF which is considered 'acceptable.' It does however stay consistent with the overall metric that software despite being incredibly slow can provide a 10-point quality gain which will be noticeable over the hardware-encoded version.

WEBM VP9 Encoding.

Hardware encoded OneMinuteMilwaukee-HW-VP9.webm 

Recipe:

ffmpeg -benchmark -y -i D:\tmp\original.mkv -c:v vp9_qsv -preset veryslow -b:v 4M -minrate 2M -maxrate 8M -bufsize 8M -threads 8 -g 120 -keyint_min 60 -pass 1 -passlogfile D:\tmp\my_passlog_HW_VP9 -c:a libopus -b:a 96k -threads 0 -movflags +faststart -f null NUL 2>> "D:\tmp\ffmpeg-VP9HD.log"
ffmpeg -benchmark -y -i D:\tmp\original.mkv -c:v vp9_qsv -preset veryslow -b:v 4M -minrate 2M -maxrate 8M -bufsize 8M -threads 8 -g 120 -keyint_min 60 -pass 2 -passlogfile D:\tmp\my_passlog_HW_VP9 -c:a libopus -b:a 96k -threads 0 -movflags +faststart -f webm D:\vid\MyMilwaukee-HW-VP9.webm 2>> "D:\tmp\ffmpeg-VP9HD.log"

Software encoded: OneMinuteMilwaukee-SW-VP9.webm

Recipe:

ffmpeg -benchmark -y -i D:\tmp\original.mkv -c:v libvpx-vp9 -b:v 4M -minrate 2M -maxrate 8M -bufsize 8M -threads 8 -cpu-used 8 -g 120 -keyint_min 60 -tile-columns 4 -auto-alt-ref 1 -lag-in-frames 25 -frame-parallel 1 -row-mt 1 -pass 1 -passlogfile D:\tmp\my_passlog_SW_VP9 -c:a libopus -b:a 96k -threads 0 -movflags +faststart -f null NUL 2>> "D:\tmp\ffmpeg-VP9SW.log"
ffmpeg -benchmark -y -i D:\tmp\original.mkv -c:v libvpx-vp9 -b:v 4M -minrate 2M -maxrate 8M -bufsize 8M -threads 8 -cpu-used 8 -g 120 -keyint_min 60 -tile-columns 4 -auto-alt-ref 1 -lag-in-frames 25 -frame-parallel 1 -row-mt 1 -pass 2 -passlogfile D:\tmp\my_passlog_SW_VP9 -c:a libopus -b:a 96k -threads 0 -movflags +faststart -f webm D:\vid\MyMilwaukee-SW-VP9.webm 2>> "D:\tmp\ffmpeg-VP9SW.log"

• Filesize software encoded: 30.987KB
• Filesize hardware encoded: 31,642KB
• VMAF Software: min="8.329435" max="100.000000" mean="84.690877" harmonic_mean="83.563598"
• VMAF Hardware: min="24.310816" max="100.000000" mean="80.001581" harmonic_mean="77.956084"
• Software Bench Encode Time (1st pass): utime=43210.011s stime=35.402s rtime=15321.001s
• Software Bench Encode Time (2nd pass): utime=41551.820s stime=22.970s rtime=12144.112s
• Hardware Bench Encode time (1st pass): utime=839.016s stime=11.734s rtime=245.275s
• Hardware Bench Encode time (2nd pass): utime=852.062s stime=13.031s rtime=244.379s

Comments: I'm a little amazed qsv_vp9 encoding even worked on the ARC card considering there's almost no mention of it anywhere on their website. There was just a quick mention in the FFmpeg manual for intel processors and that is it! But super glad it's there because AV1 has not entirely made the compatibility rounds with most computers (Still waiting for Apple Web Kit to finalize) and thus having a fallback for WebM is essential. On the same token. FFMpeg was reporting errors in reading WebM stating that the VMAF rating may be difficult to attain due to the nature of the container. Fair enough.

Although the file size is similar to software encoding the quality of the hardware-encoded VP9 Webm file is severe, especially during cross-fades between scenes similar to the VMAF dip in AV1. You don't need to zoom in to realize that the cross-fade is seriously making WebM artifacts out from the shadows of the last scene transitioning into the current scene. Nowhere near as bad on the software encoding. out of all of the libraries intel worked QSV_VP9 feels like one of those libraries where version 1 was introduced and it stopped right there despite web acceptability for the format being considerably higher than AV1 and even h265

VP9 FFmetric graphing.

This is why you try not to skip frames when analyzing this. The graph versus AV1 has a more saw-wave pattern to it because of the spacing of progressive "P" frames. Every time the codec establishes a keyframe. quality jumps only for a quarter of a second before quality immediately drops again. This could be why frames during transitional scenes appear far worse than what is graphed out. But also, VP9 is dropping in the 50s regarding quality on those frames, which goes into the 'fair' category. What IS interesting is FFMPEGs meter detected the software VMAF drop HARDER than FFMetric.

MP4 .h264 Encoding.

Hardware encoded OneMinuteMilwaukee-HW-H264.mp4 

Recipe:

ffmpeg -benchmark -y -i D:\tmp\original.mkv -c:v h264_qsv -profile:v high -preset veryslow -b:v 4M -minrate 2M -maxrate 8M -bufsize 8M -b_strategy 1 -bf 7 -refs 5 -pass 1 -passlogfile D:\tmp\my_passlog_HW_H264 -c:a libopus -b:a 96k -threads 0 -movflags +faststart -f null NUL 2>> "D:\tmp\ffmpeg-H624HD.log"
ffmpeg -benchmark -y -i D:\tmp\original.mkv -c:v h264_qsv -profile:v high -preset veryslow -b:v 4M -minrate 2M -maxrate 8M -bufsize 8M -b_strategy 1 -bf 7 -refs 5 -pass 2 -passlogfile D:\tmp\my_passlog_HW_H264 -c:a libopus -b:a 96k -threads 0 -movflags +faststart -f mp4 D:\vid\MyMilwaukee-HW-H264.mp4 2>> "D:\tmp\ffmpeg-H624HD.log"

Software encoded: OneMinuteMilwaukee-SW-H264.mp4

Recipe:

ffmpeg -benchmark -y -i D:\tmp\original.mkv -c:v libx264 -profile:v high -preset veryslow -b:v 4M -minrate 2M -maxrate 8M -bufsize 8M -pass 1 -passlogfile D:\tmp\my_passlog_SW_H264 -c:a libopus -b:a 96k -threads 0 -movflags +faststart -f null NUL 2>> "D:\tmp\ffmpeg-H264SW.log"
ffmpeg -benchmark -y -i D:\tmp\original.mkv -c:v libx264 -profile:v high -preset veryslow -b:v 4M -minrate 2M -maxrate 8M -bufsize 8M -pass 2 -passlogfile D:\tmp\my_passlog_SW_H264 -c:a libopus -b:a 96k -threads 0 -movflags +faststart -f mp4 D:\vid\MyMilwaukee-SW-H264.mp4 2>> "D:\tmp\ffmpeg-H264SW.log"

• Filesize software encoded: 31,418KB
• Filesize hardware encoded: 31,376KB
• VMAF Software: min= 16.515219" max="97.428043" mean="67.466890" harmonic_mean="66.758850"
• VMAF Hardware: min="6.972591" max="97.428035" mean="69.189128" harmonic_mean="62.941498"
• Software Bench Encode Time (1st pass): utime=2576.281s stime=8.438s rtime=667.901s
• Software Bench Encode Time (2nd pass): utime=2384.281s stime=7.421s rtime=600.126s
• Hardware Bench Encode time (1st pass): utime=748.016s stime=12.672s rtime=213.432s
• Hardware Bench Encode time (2nd pass): utime=750.891s stime=12.906s rtime=212.627s

Comments: Because of how old the h264 standard is the encode times were fast across the board if we were using CPU or not. Although file size was not affected much the encode quality just like our previous tests took a hit with going off of GPU versus CPU modes.

H264 FFmetric graphing.

This graph is a little interesting in respects that during quiet scenes the hardware encode quality is better than software encoding. However, when it comes to any of the transitional scenes software appears to take the hit way better than the hardware side of encoding. Interesting that hardware encoding saw waves similar to VP9 but software encoding didn't. Then again, we're approaching the limits of h264 encoding by introducing a 4k video which is why VMAF sporadically is taking a hit throughout the process.

MP4 HVEC/.h265 Encoding.

Hardware encoded OneMinuteMilwaukee-HW-H265.mp4 

Recipe:

ffmpeg -benchmark -y -i D:\tmp\original.mkv -c:v hevc_qsv -preset veryslow -b:v 4M -minrate 2M -maxrate 8M -bufsize 8M -extbrc 1 -refs 5 -pass 1 -passlogfile D:\tmp\my_passlog_HW_H265 -c:a libopus -b:a 96k -threads 0 -movflags +faststart -f null NUL 2>> "D:\tmp\ffmpeg-H265HD.log"
ffmpeg -benchmark -y -i D:\tmp\original.mkv -c:v hevc_qsv -preset veryslow -b:v 4M -minrate 2M -maxrate 8M -bufsize 8M -extbrc 1 -refs 5 -pass 2 -passlogfile D:\tmp\my_passlog_HW_H265 -c:a libopus -b:a 96k -threads 0 -movflags +faststart -f mp4 D:\vid\MyMilwaukee-HW-H265.mp4 2>> "D:\tmp\ffmpeg-H265HD.log"

Software encoded: OneMinuteMilwaukee-SW-H265.mp4

Recipe:

ffmpeg -benchmark -y -i D:\tmp\original.mkv -c:v libx265 -preset veryslow -b:v 4M -minrate 2M -maxrate 8M -bufsize 8M -pass 1 -passlogfile D:\tmp\my_passlog_SW_H265 -c:a libopus -b:a 96k -threads 0 -movflags +faststart -f null NUL 2>> "D:\tmp\ffmpeg-H625SW.log"
ffmpeg -benchmark -y -i D:\tmp\original.mkv -c:v libx265 -preset veryslow -b:v 4M -minrate 2M -maxrate 8M -bufsize 8M -pass 2 -passlogfile D:\tmp\my_passlog_SW_H265 -c:a libopus -b:a 96k -threads 0 -movflags +faststart -f mp4 D:\vid\MyMilwaukee-SW-H265.mp4 2>> "D:\tmp\ffmpeg-H625SW.log"

• Filesize software encoded: 30,987KB
• Filesize hardware encoded: 31,599KB
• VMAF Software: min="70.449756" max="100.000000" mean="92.045848" harmonic_mean="91.799777"
• VMAF Hardware: min="35.822092" max="100.000000" mean="81.707191" harmonic_mean="80.547757"
• Software Bench Encode Time (1st pass): utime=44481.219s stime=14.078s rtime=11324.938s
• Software Bench Encode Time (2nd pass): utime=44511.219s stime=13.750s rtime=11321.432s
• Hardware Bench Encode time (1st pass): utime=1098.484s stime=13.031s rtime=305.296s
• Hardware Bench Encode time (2nd pass): utime=1096.984s stime=13.562s rtime=309.056s

Comments: Wow, okay, this is the only codec on the Intel ARC that took me a little by surprise. That the hardware encode ended up lower than the software, the VMAF isn't necessarily terrible and in most cases very watchable. The time to use the Intel ARC was way lower than anything else. It seems like the hardware manufacturers had a lot of time to perfect HVEC and it looks like it's really solid for encoding. The only downside to their encoding system is a lot of is commission-based and thus very scummy when working with people to self-host.

H265 FFmetric graphing.

FFMetric concurs with our findings. doing h265 encoding from at least a quality perspective is amazing. Even during the transitional scenes, it refuses to drop below 80 on the VMAF scale. although it seems to be failing SSIM a little harder versus the other codecs we rendered.

 

Final thoughts:

From the perspective is saving space. Outside of AV1 which software gave us an additional 10 percent. All of the other ways of encoding is a wash. In terms of quality and more importantly consistent quality. Software wins that. But in terms of overall time, that's where the GPU reigns supreme. So! Is this Intel ARC A380 worth it for video rendering? If you need to pump out a video quickly. Yes! Absolutely.  If you want to play mad scientist get the best of size AND quality. Then you will be disappointed with it. In terms of working with different video software on the Intel A380. No crashing or glitching! So! If I needed an office graphics card that could play videos back to me well and could handle all of my workers who obsess over Adobe Products and didn't want to pay a fortune for a gaming card? Yeah, the A380 fits that niche perfectly.

One thing that it does answer is why on the pirate networks there are so many HVEC/x265 and x264 videos. It's something you can pound off on a GPU and have it up on a network ready for others to download in minutes instead of hours. Generally in the video pirating community, they are doing something similar to what we do. Make the video with the GPU to get it online fast. Then, a day later, release a video that matches or exceeds the quality of what you get from most streaming services.

Also, keep in mind this test was just in variable bit-rate compression. If we wanted to tune further we could've dived into the art of constant rate flow rendering which may result in higher filesize but perhaps a much more consistent VMAF versus what we were getting.

In the future, we'll probably get a processor/motherboard that does have bridge support and retest this. Also, give some independent streaming a chance. We won't be doing this on twitch because we lost our API many years ago (didn't agree to their ToS)but we'll find something!

There will be people who will always say that CPU encoding will be better than GPU encoding until the end of time. For the most part, they're right! A CPU can be revised/reprogrammed/reused just like we did with that 4th gen I5 CPU. But if there's an hour of video to share. We're not entirely sure if we feel like burning down trees in power for months of CPU time to get it done.

In terms of Intel as a graphic card for gaming. Yeah, we tried it with a few games on our Steam network. without completely dunking on the thing it has a ways to go! Intel has always been there playing lower-level games on Steam with their embedded laptop gaming chips. Intel has been real about updating their drivers on an almost weekly basis as problems develop and arise with it. And to be honest, we need more competition in the graphic card market than Nvidia and AMD.

That's what server said.

+++END OF LINE