[experimental]: intel vpl encoding on windows

[luca-schlecker]

Currently, ALVR on Windows falls back to software encoding if paired with (for example) an Arc B580.
I've seen some old discussions about a rework of the encoding code, but there didn't seem to be any recent progress.
Due to this, I've implemented a new encoder using libvpl to provide hardware acceleration for Intel GPUs on Windows until the new encoder system drops.

Disclaimer: I've seen an issue where the screen sometimes glitches very noticeably. Do not try this PR if you are at risk of seizures. Expect weird things and glitches to happen.

Working (tested at least once on my system):

• Hardware Encoding on ARC B580 (and thus most likely ARC A-Series too)
• Codec Selection
• Bitrate Selection
• CBR and VBR toggling
• Encoder Profile Selection (e.g. Main, High)
• Encoder Preset Selection (e.g. Balanced, Speed, Quality)
• Automatic library download, compilation & linking (cmake is now also installed using choco)
• Live Bitrate Updating
• 10 bit encoding
• HDR

Encountered Bugs:

• Screen glitching (I think it may be limited to AV1 codec)

Using the VPL encoder, latency has gone way down, making for quite an enjoyable gaming experience. I currently use these settings and found them to work well for me:

• Resolution: High (width: 5184)
• Framerate: 120 Hz
• Encoder Preset: Quality
• Codec: HEVC
• Bitrate Mode: Constant @ ~200 Mbps

Edit: I couldn't let this go. I've spent some more time and polished this PR quite a bit. Most functionality seems to just work now (including 10-bit, SDR and HDR). Furthermore, I was able to remove the hacky workarounds. I've decided that I will actively work on this PR and take care of it, in order for this to be delivered as quickly as possible to everyone using Intel ARCs.

I haven't tested all the configuration parameters, just the (to me) most relevant ones. If you'd like, I can test some more configurations for you, though. I'd love to get some more people to test this out so more data can be gathered. I cherry-picked my changes onto v20.14.1 and ran the release pipeline to generate some artifacts. Find the build artifacts on this release in my repository.

[zmerp]

That was sorely needed. Thanks! We haven't done much regarding the encoder rework, that would be using Vulkan video but that would be done first for Linux and Windows would be another unknown as different developers would need to work on it

[zmerp]

Apart the last nit, I think this is good. I can't test because I don't have a pc with a Intel gpu but we can just merge and we'll get feedback from the community.

[luca-schlecker]

Do you think any documentation needs changing? I think Readme Requirements could be updated, as B580s are now supported and give a good experience.

[zmerp]

Ah yes, good catch. You can update that.

[luca-schlecker]

I've added notices to the wiki and readme. Required is Tiger Lake or newer as per this table, with the recommendation in the checklist being ARC equivalent or newer.

I've stumbled upon one more thing, though: In systems with an iGPU + dedicated GPU, the order of the encoders in CEncoder.cpp seems to be important to determine which one should be initialized first. I don't think there is a correct order for them. Would you be open to adding a manual selection for the preferred encoder (which would need to be platform dependent), or would you rather just wait for the rework?

[zmerp]

The rework is not happening any time soon. I think the implementation of the selection is good, but let's do it in a separate PR.

[zmerp]

@The-personified-devil not sure if you have any comments, to me it seems pretty straighforward

[luca-schlecker]

After some more testing, I've noticed that H264 encoding is broken. I've tracked it down and it seems like requesting an IDR frame leads to that error. Only requesting an IDR frame for the other codecs did the trick and I was able to get output using all three codecs.

[zmerp]

But we do want to support IDR frames on h264. Is there something else that needs changing to fix this bug maybe?

[luca-schlecker]

But we do want to support IDR frames on h264. Is there something else that needs changing to fix this bug maybe?

I don't know. When I completely removed IDR frames in the encoder, HEVC stopped working. AV1 was fine with and without. H264 would not work with IDR frames inserted.

iirc the encode function returns an "invalid video param" error if FrameType is set to IDR. I will try to find out more about it.

[zmerp]

Removing IDRs would be very broken. Any packet loss would corrupt the stream. And this on average would happen 1 minute in, getting worse over time. also this would break the option "avoid video glitching" which detects packet losses and pauses the stream until an IDR is received.

[luca-schlecker]

Removing IDRs would be very broken. Any packet loss would corrupt the stream. And this on average would happen 1 minute in, getting worse over time. also this would break the option "avoid video glitching" which detects packet losses and pauses the stream until an IDR is received.

I see. This shouldn't be merged then, until I found a fix.

[zmerp]

You can research a fix for a bit yeah. But if this takes too much time or you discover this to be unfixable, let's still merge it and let's document (in the help tooltip) that h264 is broken. We're not breaking any existing feature/support, so it's fine

[zmerp]

@luca-schlecker Hey, do you think we can merge this? I'd say for now to put a help string that H264 is not working. In any case the encoder can override the codec preference. if H264 is selected you can instead initialize the encoder with HEVC and then pass HEVC flag to ParseFrameNals. Don't throw away the H264 code, keep it there and also open an issue about it