HEVC software transcode vs QuickSync

[AxeMan 25]

I didn't grab logs yet - but will if they are needed. But first a general question

I have two Emby servers, one that does not have a gpu, and another that has an iGPU that supports quicksync. 

When 4K files get transcoded from the older machine (software), the movie plays fine. However, on the quicksync machine, it ends up having errors (grey screen with a couple of squares in the top left corner). 

Is it possible that one method of transcoding can handle a damaged file better than another? 

[rbjtech 5284]

yes - ffmpeg via h/w acceleration is less resilient to file errors but that is not necessarily the issue here.

If you can post the hwdetect and ffmpeg log, then it will show if there are any conversion errors and if not @softworkz may be able to help why you are getting the screen corruption.

 

[softworkz 5073]

@AxeMan - What you can try is to use the DX11VA HEVC decoder instead. It uses ffmpeg for file parsing and can be combined with a QuickSync encoder.

[softworkz 5073]

Here's an overview about where the parsing is done.

ffmpeg parsing is more tolerant regarding video errors and more mature in general.

HW Decoder	Video Parser
QuickSync	HW
DXVA2/DX11VA	ffmpeg
Nvidia NVDEC	ffmpeg
Nvidia CUVID	HW
VAAPI	ffmpeg

[AxeMan 25]

Thank you both! I went to Transcoding, Advanced, and moved the DX11VA up. That seemed to have done the trick on the quicksync capable machine. 

 

The only issue I have now is the colors being washed out when an HDR10 video is transcoded. Saw some other threads - need to go see about that. 

 

Thanks again!

 

[rbjtech 5284]

5 hours ago, AxeMan said:

 

The only issue I have now is the colors being washed out when an HDR10 video is transcoded. Saw some other threads - need to go see about that. 

 

The latest Beta has HDR Tone Mapping which will colour correct this. 

[AxeMan 25]

5 hours ago, rbjtech said:

The latest Beta has HDR Tone Mapping which will colour correct this. 

This is excellent news! Thanks for sharing this info. Now that I have a test emby server up, I might just spin up the beta. 

Thank you both, again. 

[dapper 14]

On 3/11/2021 at 2:44 PM, softworkz said:

Here's an overview about where the parsing is done.

ffmpeg parsing is more tolerant regarding video errors and more mature in general.

HW Decoder	Video Parser
QuickSync	HW
DXVA2/DX11VA	ffmpeg
Nvidia NVDEC	ffmpeg
Nvidia CUVID	HW
VAAPI	ffmpeg

I've just had mine on QuickSync forever... is it in general better to run the DX11VA decoder?  (Windows Server 2019; Intel UHD 630, if it matters)

All my stuff direct plays for me, but some of my external users occasionally transcode... so it's hard for me to know if there's any errors happening on their end.

[softworkz 5073]

54 minutes ago, dapper said:

is it in general better to run the DX11VA decoder?

In general I would say no. I would stick to the specific decoder and only use DXVA11 variants in case of problems.

What happens under the hood varies by vendor and may even vary by codec. As DXVA is what's being used by platform video applications (e.g. WMP) one could speculate that it might be handled more conservatively (=better not touch it when it's working) because it would affect a huge audience, while the audience using the vendor-specific audience is much smaller, which means less impact and so higher acceptable risk, which in turn means that it might get updated and improved more frequently. In many cases you may just get the same results, though. 

What I said so far was just about possible differences of the pure decoding operations.

The parsing is an additional factor, and in that regard, the combination of ffmpeg parsing and DXVA decoding will be able to playback some files that otherwise wouldn't work. But that depends again on the codec. So far, I've only seen problems with MP2Video and HEVC with QuickSync decoders. 

Feel free to compare performance - again, that can vary, so everybody should do this on his own system and not listen what somebody might say, as you can never be sure whether it applies to your setup as well.

 

[AxeMan 25]

Probably more effort than it's worth - it'd be nice if Emby can have an adaptive setting, or a per movie setting. 

Adaptive, if there are transcode errors from one, try the next. Almost like the setting on the player to correct playback problems, but on the server end. 

[softworkz 5073]

26 minutes ago, AxeMan said:

it'd be nice if Emby can have an adaptive setting, or a per movie setting. 

Really? I think - that's what would be

27 minutes ago, AxeMan said:

more effort than it's worth

 

27 minutes ago, AxeMan said:

Adaptive, if there are transcode errors from one, try the next.

We already fall back to software transcoding. But trial-and-error takes time. And when hw transcoding fails, there's rarely a clear alternative that is likely to work. That's just what it may seem to be right now, but when one hw transcoding setup fails, there are often several alternatives that _could_ be tried. But when we would to this, it would add significant delay to starting playback. Many users don't monitor their log files, and this way, we would create situations where users would blame it on Emby. Even if it gets noticed, it's not always easy to fix that. That's why we have the "single-fallback" mechanism: Try once with hw when possible, when it fails, use sw transcoding (which works almost always).

This allows us to keep the playback-start delay small.