Jump to content

HEVC Profile Main 10 / QSV Hardware Transcoding / staircase effect


SoGX
 Share

Go to solution Solved by softworkz,

Recommended Posts

1 minute ago, Happy2Play said:

In the end this is due to Emby's algorithm/scaling for bitrate limit for 5Mbps and software vs hardware encoding differences?

No. It's a problem specific to Coffee Lake.

9 minutes ago, softworkz said:

Because we must not forget that - even when scaling down to 720x300 - we get decent output:

  • with software encoding
  • with the same QSV encoding on other systems

 

3 minutes ago, Happy2Play said:

How would no scaling happen in this scenario?  Would applying client quality differently honor resolution but keep bitrate limit?

No change to the scaling decisions will be made.

Link to comment
Share on other sites

This is a screenshot from VLC at 1:1 pixel size (no scaling by the player)

of the same video, scaled and encoded with QSV with the same command line and even just half the bitrate:

image.png.e2b5c811fe27cd162b82bbb98f5ed356.png

Edited by softworkz
Link to comment
Share on other sites

So - to say it loud and clearly:

No it is not required to increase the video size to achieve a decent quality.

 

Seeing "better" quality at a higher resolution is just an accidental effect in the context of the misbehavior/malfunction of the QuickSync encoder in this case.

Link to comment
Share on other sites

@SoGX - For reference and comparison, could you please create a sample clip with the following (minimal) command:

C:\Users\Administrator.INTERN\AppData\Roaming\Emby-Server\system\ffmpeg.exe -to 180s  -loglevel +timing -y -copyts -start_at_zero -init_hw_device "qsv=qd0:hw,child_device=0,qsv_use_dx11=1" -f matroska,webm -c:v:0 hevc_qsv -hwaccel:v:0 qsv -i "\\intern.sogx.com\nas\filme\Spider-Man - No Way Home (2021) 1080p\Spider-Man.-.No.Way.Home.(2021).1080p.mkv"  -filter_complex "[0:0]vpp_qsv@f1=width=720:height=300:format=nv12[f1_out0]" -map [f1_out0] -an -sn -c:v:0 h264_qsv -b:v:0 2000000  -maxrate:v:0 2000000 -bufsize:v:0 4000000  out_simple.mkv

 

Link to comment
Share on other sites

9 hours ago, softworkz said:

Let's collect some more information:

  • What's the exact CPU model?
  • Which OS version?
  • Which drivers do you have installed?
    • And which was the previous version?
  • Do you have a monitor connected to the onboard graphics?
  •  Intel Core i5-8500T @ 2.1 GHz
  • Server 2022 21H2
  • image.png.f4c5094e91bd3923d7765d1bf50a8d5c.png
    • 27.20.100.9416 is the previous driver
  • No Monitor connected
Link to comment
Share on other sites

3 hours ago, SoGX said:

No Monitor connected

Oh, let's try to rule this out and make sure that the GPU isn't put into some minimal mode.

Are you able to connect a monitor temporarily?

Then, in the BIOS, there is some setting about IGPU or "Integrated Graphics", with options like Auto, disabled, enabled, or and usually also some selection for GPU memory.

So let's switch this all on, mem to the maximum and monitor connected - just to be sure that it's not some "power saving feature" we are seeing here.

Thanks!

Link to comment
Share on other sites

Posted (edited)
5 hours ago, softworkz said:

Are you able to connect a monitor temporarily?

Then, in the BIOS, there is some setting about IGPU or "Integrated Graphics", with options like Auto, disabled, enabled, or and usually also some selection for GPU memory.

So let's switch this all on, mem to the maximum and monitor connected - just to be sure that it's not some "power saving feature" we are seeing here.

I have now connected a monitor.
I have not found any settings for iGPU in the BIOS settings, but this may also be due to the fact that it is a mini PC (HP EliteDesk 400 G4 Mini). The only setting I found was the memory allocation for the iGPU. I have increased the allocated memory to 512MB.
Unfortunately, nothing has changed in the result.
Another thing I tested is not to run Emby as a service. The picture is then grainy again.

Edited by SoGX
Link to comment
Share on other sites

Thanks for trying!

1 minute ago, SoGX said:

Another thing I tested is not to run Emby as a service. The picture is then grainy again.

It makes a difference whether you run as service or not?

Link to comment
Share on other sites

3 minutes ago, softworkz said:

It makes a difference whether you run as service or not?

After a restart it looked like this at first, I just tested it again and it looks like it did at the beginning. I don't really understand it either.
Sorry for the confusion.

Link to comment
Share on other sites

5 hours ago, softworkz said:

Btw - for comparison: here's the result that I get with the same command:

I would like to have such a result too 😉

Link to comment
Share on other sites

If somebody else would be able and willing to try the same on an older CPU - let me know.

Link to comment
Share on other sites

Before I installed Emby on the mini-PC, it was running on another Mini-PC with an i5-6500T. I have now connected this old PC again and tested it with this one. The result is the same here.
I'm not surprised, which is why I switched to an i5-8500T in the hope that it would be better.

Link to comment
Share on other sites

pwhodges
37 minutes ago, softworkz said:

If somebody else would be able and willing to try the same on an older CPU - let me know.

I can do a test on an i5-7500 if you want.  Or an i7-3770 with a bit more effort...

Paul

Edited by pwhodges
Link to comment
Share on other sites

I have developed the D3D11 support for QSV in ffmpeg in 2019 with a Skylake and later a Kaby Lake. 
The encoding and scaling has never been as bad as that.

2 minutes ago, SoGX said:

Installed the driver, no improvement

Could you run the test command there and post the output?

 

...And then again with this old ffmpeg: ffmpeg.zip

Link to comment
Share on other sites

PS: The old ffmpeg requires adding these two parameters at the beginning: -qsv_device 1 -qsv_use_dx11 
(the second has no value)

Link to comment
Share on other sites

19 minutes ago, softworkz said:

Could you run the test command there and post the output?

 

...And then again with this old ffmpeg: ffmpeg.zip

 

6 minutes ago, softworkz said:

PS: The old ffmpeg requires adding these two parameters at the beginning: -qsv_device 1 -qsv_use_dx11 
(the second has no value)

Parameters are added

out_simple_old_drv.mkv out_simple_old_drv_ffmpeg.mkv

Link to comment
Share on other sites

  • Solution

No change, no change - damn!

But I got one more - just had a flashback about reading an MSDK bug where combining certain operations in a single VPP session doesn't work well.

So, now we separate format conversion and scaling:

ffmpeg.exe -to 180s  -loglevel +timing -y -copyts -start_at_zero -init_hw_device "qsv=qd0:hw,child_device=0,qsv_use_dx11=1" -f matroska,webm -c:v:0 hevc_qsv -hwaccel:v:0 qsv -i "\\intern.sogx.com\nas\filme\Spider-Man - No Way Home (2021) 1080p\Spider-Man.-.No.Way.Home.(2021).1080p.mkv"  -filter_complex "[0:0]vpp_qsv@f0=format=nv12,vpp_qsv@f1=width=720:height=300[f1_out0]" -map [f1_out0] -an -sn -c:v:0 h264_qsv -b:v:0 2000000  -maxrate:v:0 2000000 -bufsize:v:0 4000000  out_simple.mkv

 

Link to comment
Share on other sites

Wow, I think that's the solution!!!

The picture looks much better now. Still not quite as good as jf without scaling but maybe you can tune it a bit more 😉

 

Can i now switch back to the never GFX Driver an never ffmpeg?

out_simple.mkv

Link to comment
Share on other sites

3 minutes ago, SoGX said:

Wow, I think that's the solution!!!

BANG - and once again, Sherlock Softworkz solved one of the toughest cases in media processing history 🙂 

  • Agree 1
Link to comment
Share on other sites

Man, you have helped me so much. I was almost desperate 😉

The only question now is, where exactly is the problem and how can I fix it?

 

Link to comment
Share on other sites

16 minutes ago, SoGX said:

The picture looks much better now. Still not quite as good as jf without scaling but maybe you can tune it a bit more

The smoothness of edges like we see in the first 30s is just one little aspect out of a large range of other criteria.

Furthermore, this is unnatural and you'll hardly find any scenes in the movie itself where this would play an important role.
Important are other things. Once you stop fixating on the intro and start comparing other scenes with jf, you'll most likely a very different view on this subject.
(...maybe, you will even agree that Emby's decision to scale down is even a better choice in this case)

9 minutes ago, SoGX said:

he only question now is, where exactly is the problem and how can I fix it?

We need to change this in Emby server to avoid combining scaling and format conversion in a single filter operation (except on the latest CPUs).

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...