LizardByte / LizardByte/Sunshine

Scaling quality difference between Windows ram vs vram encoding path

Open
#724 5 comments 0 reactions 1 assignee View on GitHub

Nobody has claimed this yet.

Dominant language
C++
Stars
41.3k
Forks
2.1k
Avg merge
23h 47m
Merged PRs (30d)
124

Description

### Is there an existing issue for this?

- [X] I have searched the existing issues

### Is your issue described in the documentation?

- [X] I have read the documentation

### Is your issue present in the nightly release?

- [X] This issue is present in the nightly release

### Describe the Bug

Host configuration: Windows 10, RX 6600 running at 1440p.
Client configuration: Ubuntu 22.10, Moonlight-QT 4.3.1 (flatpak), 1366x768 @ 90MBps.

`amdvce` encoder on latest nightly:
![Screenshot from 2023-01-07 21-46-21](https://user-images.githubusercontent.com/749000/211171824-6bfd2ee5-17d1-4b07-867e-6cf3b39d2a68.png)

`amdvce` encoder patched[1] to use `ram` software rendering path:
![Screenshot from 2023-01-07 21-53-24](https://user-images.githubusercontent.com/749000/211171850-b1108858-85f5-42df-9f62-a6281349200d.png)

[1] Patch:
```
diff --git a/src/video.cpp b/src/video.cpp
index f6e0904..80a13c9 100644
--- a/src/video.cpp
+++ b/src/video.cpp
@@ -532,8 +532,8 @@ static encoder_t quicksync {

static encoder_t amdvce {
"amdvce"sv,
- AV_HWDEVICE_TYPE_D3D11VA, AV_HWDEVICE_TYPE_NONE,
- AV_PIX_FMT_D3D11,
+ AV_HWDEVICE_TYPE_NONE, AV_HWDEVICE_TYPE_NONE,
+ AV_PIX_FMT_NONE,
AV_PIX_FMT_NV12, AV_PIX_FMT_P010,
{
// Common options
@@ -571,7 +571,7 @@ static encoder_t amdvce {
"h264_amf"s,
},
PARALLEL_ENCODING,
- dxgi_make_hwdevice_ctx
+ nullptr
};
#endif

```

### Expected Behavior

Images should appear mostly identical, but the `ram` encoding path has better filtering of scaled image and therefore much better legibility of the fonts of the screenshot in particular.

### Additional Context

The `libx264` encoder also has subjectively "good" scaling, but I provided a screenshot with the the `amdvce` encoder patched to use the software rendering path to eliminate the variable of AMD's encoding being poorer than `libx264` to explain the issue (it seems not).

There is also an image corruption issue for a few dozen pixels along the entire right-hand side of the screen that occurs when Moonlight is set to capture at `1366x768`, but does not occur at more standard resolutions such as 1080p. That is probably not related to the scaling quality issue.

### Host Operating System

Windows

### Operating System Version

10 22H2 19045.2364

### Architecture

64 bit

### Sunshine commit or version

7770b5f708675854674e8372af9227ee91ce5882

### Package

Windows - installer

### GPU Type

AMD

### GPU Model

RX 6600

### GPU Driver/Mesa Version

22.11.2

### Capture Method (Linux Only)

_No response_

### Relevant log output

_No response_

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.