Jump to content

10-bit H.265 HEVC Hardware Acceleration is Broken on 4.3.0.30

Brudertac

By Brudertac
in Synology

 Share
Go to solution Solved by seanbuff,

Recommended Posts

Brudertac

Brudertac 18

Posted
Posted (edited)

Hey there,

 

looks like Hardware Acceleration for HEVC is broken in latest Release.

Emby switch to Software Transcode, but for this my Synology DS918+ is too slow.

 

From reports in this Forum it looks like only 10bit Files are affected.

 

On older Versions this was working fine.

 

Is that a known Problem?

 

Thanks

Brudertac

embyserver.txt

ffmpeg-transcode-c31d7e5e-fa5f-423f-b63e-cc5843194e9d_1.txt

ffmpeg-transcode-c92604cc-0f65-4368-ba5f-d854417a52e6_1.txt

Edited by Brudertac
Brudertac

Brudertac 18

Posted
  • Author
Posted (edited)

Logs added to first Post.

@@softworkz

Edited by Luke
Brudertac

Brudertac 18

Posted
  • Author
Posted

Hi

 

Check out this thread:

https://emby.media/community/index.php?/topic/79986-hardware-transcoding-fails-on-hevc-main-10-10bit-profile/

 

There is a temporary work around.  You need to disable the hardware decoding for HEVC.  The decoding will be done in software, but at least the encoding will be done in hardware.  It should give some slack to the DS918+ processor.

 

Already seen this and tested it too. 

It do not work. If i setup the settings like described the Movie wont play. 

processcreative

processcreative 0

Posted
Posted

Already seen this and tested it too. 

It do not work. If i setup the settings like described the Movie wont play. 

 

Same for me. HW acceleration will not work whatsoever with 10bit x265 files, no matter my settings. Makes Emby unusable remotely as 90% of my files are 10bit x265. Getting really frustrated with this as it's been 'broken' for ages and no real fix as yet.

softworkz Emby Team

softworkz 4503

Posted
Posted

@@stephenk - Thanks for the log.

 

The setup is correct and it appears to be working - just too slow. It's an UHD video with double frame-rate (60 fps) and a total bitrate of 28 Mbps. That's just a bit too much for the device to handle.

 

Could you please try one thing:

 

During playback, click on the gear icon and and 'Quality'. There, choose '480p - 1 Mbps'. 

 

It would be great if you could post a log from this test. I'm just curious to see how that compares.

softworkz Emby Team

softworkz 4503

Posted
Posted (edited)

Thanks. It's only slightly faster. We have reduced the encoding work but added hardware scaling (which is done in hardware, though).

 

But in this case, I think the cpu processing is the bottleneck. It's not only decoding but also color conversion that has to be done by the cpu.

 

We are currently working on doing all of this with hw acceleration, but it will take a few weeks until we'll be able to put this in beta.

Edited by softworkz
Brudertac

Brudertac 18

Posted
  • Author
Posted

@@softworkz

 

Sorry, read to late... Do you need the Logs anymore from my Sys?

Is there a way to roll back Emby to the last Version?

There it was working fine and when you need some Weeks to fix the complete Process it would be nice to have a Working Server in the meantime.

 

Thanks!

softworkz Emby Team

softworkz 4503

Posted
Posted

@@Brudertac - Thanks for getting back. So far I haven't seen a confirmed case demonstrating that it has worked before, so if you would be able to help us with that, it would be great.

 

For this, I would need to have logs from the current version and the previous version showing the exact same playback situation (same file, same client, same settings, etc.)

 

 

With regards to rolling back: It works in many cases when the versions are not too far off, but sometimes it causes problems and you'll need to re-create the library database.

Best is to do a backup of all data folders before downgrading. 

 

And of course: First, create the logs with the current version before downgrading.

Brudertac

Brudertac 18

Posted
  • Author
Posted

@@softworkz,

 

1. where can i find Info how to Downgrade an Emby Setup on Synology? (No Docker Setup)

2. Are the Logs in the first Post enough for Troubleshooting or do you need more or other Logfiles? (Those are from the not working Version)

 

 

Thanks and best regards

Brudertac

softworkz Emby Team

softworkz 4503

Posted
Posted

@@Brudertac - Thanks, this log is very helpful for comparison.

 

In case of the failing log (from 4.3.0.30), the client-requested bitrate (6616000) is just a quarter of the value that we can see in the log from the older 4.2.1.0 version.

 

It would be great if we could rule that out as a possible cause (either increase in 4.3 or reduce in 4.2)

Brudertac

Brudertac 18

Posted
  • Author
Posted

@@softworkz,

 

any News on this? Do you need more Logs?

 

Greetings

softworkz Emby Team

softworkz 4503

Posted
Posted

@@Brudertac - Once again, thanks a lot for the logs.

 

Now we have ruled out any possible (significant) differences of the command line, so this must be due to the different ffmpeg version.

The current situation is as follows: We already got an updated ffmpeg version in the pipeline. It will first debut in the Windows releases of the upcoming beta (4.4.0.5).

As long as there won't be any showstoppers, that new ffmpeg will be included in the Linux beta packages of the subsequent beta release.

Please retry as soon as it's released and let us known about the results then.

 

Thanks for your patience,

softworkz

  • Solution
seanbuff

seanbuff 1110

Posted
  • Solution
Posted

Just thought I'd report that I have done some testing on the latest Windows build (4.4.0.5) and this appears to be working correctly now on HEVC content, especially 10-bit.

 

All transcoding is being performed by the GPU as expected.

 

Thanks @@softworkz

  • Like 1
Luke Emby Team

Luke 39686

Posted
Posted

Thanks for the feedback !

softworkz Emby Team

softworkz 4503

Posted
Posted (edited)

@@seanbuff - as good as it sounds, and as ludicrous it may be to tell a satisfied customer that his satisfaction might be erroneous - I'm afraid, I still have to.

 

The reason is, that we haven't implemented hw color mapping/conversion for QuickSync yet.

 

There's one thing that might be happening in your case:

 

Our latest ffmpeg allows separate hw contexts for QuickSync encoder and decoder. So you might see QuickSync decoding _and_ QuickSync encoding - but what's happening in-between is done in software. So, the 10bit color conversion is probably done in software  while decoding and encoding is done in hardware.

If I could see a log file, I could confirm..

Edited by softworkz
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...