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

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 own brain and think for yourself.

Results of the video encoded with the Intel ARC A380.

Initially, I was 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, we went filming around 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/.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 really available for FFMPEG until near the release of the US markets.

The only way to really get this card before it hit 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 REALLY 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, gaming is frowned upon. To the point where their government punishes them for spending more than a few hours a week on gaming. Thus, beta-testing in China focused on application usage instead of gaming. This could eventually bite Intel in the ass as when they introduced this card as a 'Gaming Equiviant' to Nvidia and ATI. The gaming community is in fact incredibly hostile to first impressions. To these guys, it's irrelevant that ATI (now AMD) used to start off 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. And apparently, 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 in relation to the fan it's a bit of a ham-fisted approach to cooling.

Serial numbers blurred to protect the guilty.

Okay, you can seriously tell that at ASRock they 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. Which is the plastics really serve no purpose and in fact traps 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 they either said the exact same thing I could've gotten off of 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 that wrote this also has a tendency 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 themselves 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 if 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 own 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 attempt to provide VMAF ratings of the differences between the original and the encoded video. Sometimes FFmpeg gets a little screwy with only finding a rating due to some weird issue where it presents a '0' value on every other frame screwing up the mean average score.
• VMAF is on a scale from 0 to 100 with 100 being practically lossless and 0 being absolute noise. People have mentioned that the average VMAF humans perceive artifacts is around 70 however we've noticed it around 80-85 so take it with whatever grains of salt you wish.
• As this is a 4k video we are encoding; We will assign a VBR of 6000Kb/sec. Which is average room for just about every one of these codecs to do a decent job. The minimum bitrate of 0.5x maximum bitrate of 2.0x. Buffer of 3.0x. Apologies for any buffering issues to those reading on I2P or Tor.
• This test video is 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 really made of money for this experiment. However, it's probably the most realistic approach as in this day and age everyone has a phone.
• The footage was edited on OpenShot and saved as an MP4/.h264 with -crf 0. Yes, we are fully aware -crf 0 does not mean lossless. But for full disclosure. This is what we were using.

About FFMPEG

ffmpeg version 2023-03-02-git-814178f926-full_build-www.gyan.dev Copyright (c) 2000-2023 the FFmpeg developers
built with gcc 12.2.0 (Rev10, 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-libdav1d --enable-libdavs2 --enable-libuavs3d --enable-libzvbi --enable-librav1e --enable-libsvtav1 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxvid --enable-libaom --enable-libjxl --enable-libopenjpeg --enable-libvpx --enable-mediafoundation --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-liblensfun --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-ffnvcodec --enable-nvdec --enable-nvenc --enable-d3d11va --enable-dxva2 --enable-libvpl --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-libilbc --enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-ladspa --enable-libbs2b --enable-libflite --enable-libmysofa --enable-librubberband --enable-libsoxr --enable-chromaprint
libavutil 58. 3.100 / 58. 3.100
libavcodec 60. 5.100 / 60. 5.100
libavformat 60. 4.100 / 60. 4.100
libavdevice 60. 2.100 / 60. 2.100
libavfilter 9. 4.100 / 9. 4.100
libswscale 7. 2.100 / 7. 2.100
libswresample 4. 11.100 / 4. 11.100
libpostproc 57. 2.100 / 57. 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 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
• 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. In fact, 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 off 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/.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 -i "MyMilwaukee-MASTER.mp4" -c:v av1_qsv -profile:v main -preset veryslow -b:v 6000k -maxrate 3000k -bufsize 12000k -extbrc 1 -b_strategy 1 -refs 5 -bf 7 -pass 1 -an -movflags +faststart -f mp4 -y NUL 2>> "ffmpeg.log"
ffmpeg -benchmark -y -i "MyMilwaukee-MASTER.mp4" -c:v av1_qsv -profile:v main -preset veryslow -b:v 6000k -maxrate 3000k -bufsize 12000k -extbrc 1 -b_strategy 1 -refs 5 -bf 7 -pass 2 -c:a aac -b:a 128k -movflags +faststart -f mp4 MyMilwaukeeHD.av1 2>> "ffmpeg.log"

Software encoded MyMilwaukee.av1

Recipe:

ffmpeg -benchmark -y -i "MyMilwaukee-MASTER.mp4" -c:v libsvtav1 -preset 8 -b:v 6000k -minrate 3000k -maxrate 12000k -bufsize 24000k -an -threads 0 -pass 1 -movflags +faststart -y -f mp4 NUL 2>> "ffmpeg.log"
ffmpeg -benchmark -y -i "MyMilwaukee-MASTER.mp4" -c:v libsvtav1 -preset 0 -b:v 6000k -minrate 3000k -maxrate 12000k -bufsize 24000k -c:a libopus -b:a 96k -threads 0 -pass 2 -movflags +faststart -y -f mp4 "MyMilwaukee.av1" 2>> "ffmpeg.log"

• Filesize software encoded: 45,519 KB
• Filesize hardware encoded: 46,824 KB
• VMAF software: min="57.312641" max="100.000000" mean="95.813174" harmonic_mean="95.587469"
• VMAF hardware: min="29.433659" max="100.000000" mean="89.310053" harmonic_mean="88.576689"
• Software Bench Encode time (1st pass): bench: utime=3392.906s stime=105.297s rtime=909.083s
• Software Bench Encode time (2nd pass): utime=793159.906s stime=297.359s rtime=210153.335s
• Hardware Bench Encode time (1st pass): utime=1198.018s stime=11.525s rtime=354.402s
• Hardware Bench Encode time (2nd pass): utime=1198.504s stime=12.912s rtime=328.296s

Comments: 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 waiting two and a half days 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!

WEBM VP9 Encoding.

Hardware encoded ARC380-Encoded-MyMilwaukee.webm 

Recipe:

ffmpeg -benchmark -y -i MyMilwaukee-MASTER.mp4 -c:v vp9_qsv -preset veryslow -b:v 6000K -minrate 3000K -maxrate 12000K -bufsize 24000k -threads 8 -g 120 -keyint_min 60 -pass 1 -an -movflags +faststart -f webm NUL 2>> "ffmpeg.log"
ffmpeg -benchmark -y -i MyMilwaukee-MASTER.mp4 -c:v vp9_qsv -preset veryslow -b:v 6000K -minrate 3000K -maxrate 12000K -bufsize 24000k -threads 8 -g 120 -keyint_min 60 -pass 2 -b:a 96k -vbr on -ac 2 -compression_level 10 -frame_duration 60 -movflags +faststart -f webm MyMilwaukeeHD.webm 2>> "ffmpeg.log"

Software encoded: MyMilwaukee.webm

Recipe:

ffmpeg -benchmark -y -i "MyMilwaukee-MASTER.mp4" -c:v libvpx-vp9 -b:v 6000K -minrate 3000K -maxrate 12000K -bufsize 24000k -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 -an -movflags +faststart -f webm NUL 2>> "ffmpeg.log"
ffmpeg -benchmark -y -i "MyMilwaukee-MASTER.mp4" -c:v libvpx-vp9 -b:v 6000K -minrate 3000K -maxrate 12000K -bufsize 24000k -threads 8 -cpu-used 0 -g 120 -keyint_min 60 -tile-columns 4 -auto-alt-ref 1 -lag-in-frames 25 -frame-parallel 1 -row-mt 1 -pass 2 -codec:a libopus -b:a 96k -vbr on -ac 2 -compression_level 10 -frame_duration 60 -movflags +faststart -f webm "MyMilwaukee.webm" 2>> "ffmpeg.log"

• Filesize software encoded: 45,689KB
• Filesize hardware encoded: 46,914KB
• VMAF Software: (BROKEN!)
• VMAF Hardware: min="0.000000" max="100.000000" mean="59.294502" harmonic_mean="6.874987" (BROKEN!)
• Software Bench Encode Time (1st pass): utime=51311.023s stime=25.178s rtime=15001.032s
• Software Bench Encode Time (2nd pass): utime=55231.1188s stime=26.850s rtime=16342.432s
• Hardware Bench Encode time (1st pass): utime=1256.938s stime=13.625s rtime=305.402s
• Hardware Bench Encode time (2nd pass): utime=1247.719s stime=13.094s rtime=302.042s

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

Software encode VMAF erroring.

In a weird turn, WebM simply does not like FFMpegs VMAF comparison system:

[matroska,webm @ 0000023cace039c0] Format matroska,webm detected only with low score of 1, misdetection possible!
[matroska,webm @ 0000023cace039c0] EBML header parsing failed
MyMilwaukee.webm: Invalid data found when processing input

Now for those curious as to the command that we're trying to run to pull the VMAF here that is.

ffmpeg -i MyMilwaukee.webm -i MyMilwaukee-MASTER.mp4 -lavfi libvmaf=log_path=MyMilwaukee.webm.xml:feature=name=psnr:log_fmt=xml:log_path=MyMilwaukee.webm.txt -f null -

So if we're doing something wrong here, let me know in the comments below! I want to get a good reading.

MP4 .h264 Encoding.

Hardware encoded ARC380-Encoded-MyMilwaukee.mp4 

Recipe:

ffmpeg -benchmark -y -i "MyMilwaukee-MASTER.mp4" -c:v h264_qsv -profile:v high -preset veryslow -b:v 6000k -minrate 3000k -maxrate 12000k -bufsize 24000k -b_strategy 1 -bf 7 -refs 5 -an -pass 1 -threads 0 -y -movflags +faststart -f mp4 NUL 2>> "ffmpeg.log"
ffmpeg -benchmark -y -i "MyMilwaukee-MASTER.mp4" -c:v h264_qsv -profile:v high -preset veryslow -b:v 6000k -minrate 3000k -maxrate 12000k -bufsize 24000k -b_strategy 1 -bf 7 -refs 5 -c:a aac -b:a 128k -pass 2 -y -movflags +faststart -f mp4 "MyMilwaukee.HW.mp4" 2>> "ffmpeg.log"

Software encoded: MyMilwaukee.mp4

Recipe:

ffmpeg -benchmark -y -i "MyMilwaukee-MASTER.mp4" -c:v libx264 -profile:v high -preset veryslow -b:v 6000k -minrate 3000k -maxrate 12000k -bufsize 24000k -an -pass 1 -threads 0 -y -movflags +faststart -f mp4 NUL 2> "ffmpeg.log"
ffmpeg -benchmark -y -i "MyMilwaukee-MASTER.mp4" -c:v libx264 -profile:v high -preset veryslow -b:v 6000k -minrate 3000k -maxrate 12000k -bufsize 24000k -c:a aac -b:a 128k -pass 2 -y -movflags +faststart -f mp4 "MyMilwaukee.mp4" 2>> "ffmpeg.log"

• Filesize software encoded: 46,379KB
• Filesize hardware encoded: 63,505KB
• VMAF Software: min="39.126965" max="97.708157" mean="79.307576" harmonic_mean="78.925224"
• VMAF Hardware: min="0.000000" max="100.000000" mean="64.689979" harmonic_mean="7.150879" (BROKEN!)
• 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=1475.911s stime=9.746s rtime=332.760s
• Hardware Bench Encode time (2nd pass): utime=1092.469s stime=11.875s rtime=303.317s

Comments: Okay, despite us defining a -maxrate statement. and even if we bring that -maxrate down to the same as the base rate for VBR encoding which would be 6000k. the qsv_h264 gives no fucks and encodes at 8Mb/sec regardless. Even tried -bitrate just to make sure it's not some weird flag issue. Just about making this library useless for encoding with the Intel ARC card. Luckily, most CPUs these days are fast enough to encode mp4 h264 in real time. We even stripped this recipe down and removed all profiles, presets, buffer sizes, b_strategy. Which of course did nothing This results in files larger than the software encodes. Also equally as unpredictable from a VMAF standpoint.

Since it messed with the bitrate it's really not a fair test to say that software or hardware really did better on this one. We're a little at a loss with this one Intel. Perhaps we fucked up? I'm not sure.

MP4 HVEC Encoding.

Hardware encoded ARC380-Encoded-MyMilwaukee.hvec.mp4 

Recipe:

ffmpeg -benchmark -y -i "MyMilwaukee-MASTER.mp4" -c:v hevc_qsv -preset veryslow -b:v 6000k -minrate 3000k -maxrate 12000k -bufsize 24000k -extbrc 1 -refs 5 -an -pass 1 -threads 0 -y -movflags +faststart -f mp4 NUL 2>> "ffmpeg.log"
ffmpeg -benchmark -y -i "MyMilwaukee-MASTER.mp4" -c:v hevc_qsv -preset veryslow -b:v 6000k -minrate 3000k -maxrate 12000k -bufsize 24000k -extbrc 1 -refs 5 -an -pass 2 -threads 0 -y -movflags +faststart -f mp4 "MyMilwaukee.HWhvec.mp4" 2>> "ffmpeg.log"

Software encoded: MyMilwaukee.hvec.mp4

Recipe:

ffmpeg -benchmark -y -i "MyMilwaukee-MASTER.mp4" -c:v libx265 -preset veryslow -b:v 6000k -minrate 3000k -maxrate 12000k -bufsize 24000k -an -pass 1 -threads 0 -y -movflags +faststart -f mp4 NUL 2>> "ffmpeg.log"
ffmpeg -benchmark -y -i "MyMilwaukee-MASTER.mp4" -c:v libx265 -preset veryslow -b:v 6000k -minrate 3000k -maxrate 12000k -bufsize 24000k -c:a aac -b:a 128k -pass 2 -y -movflags +faststart -f mp4 "MyMilwaukee.hvec.mp4" 2>> "ffmpeg.log"

• Filesize software encoded: 47,301KB
• Filesize hardware encoded: 41,496KB
• VMAF Software: min="70.449756" max="100.000000" mean="92.045848" harmonic_mean="91.799777"
• VMAF Hardware: min="46.662260" max="100.000000" mean="87.875709" harmonic_mean="87.306347"
• 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.

Final thoughts:

Is the intel ARC A380 worth the $110? In our application of self-hosting 5-10 minute videos, it's kind of a coin flip as to what we'll be doing. When it comes to a very long video like recording a stream then HD recording. This card is a lifesaver. Perhaps it's best to get a video posted right away and then let the CPU software encoding come later to not only save space on your website but also provide better quality. From the results of the HVEC/x265 video, it's rather apparent why people on torrents love to go this route. Because even though the quality isn't anywhere near as nice as the CPU. But at least it's quick and the size is low.

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 as 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 in order to get it done.

In terms of Intel as a graphic card for gaming. 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