4k HEVC 10-bit playback/trasncoding help

[robawarner 0]

Hey. So I've been using emby for a while (mostly the Kodi plugin), I recently purchased a 4k HDR 10-bit TV and wanted to start playing 4k content.

I run emby server on my i5 4690 based Ubuntu 16.04 server. I have a TV hooked up to this machine and as you may expect, playing 4k HEVC files does not go well, neither does live transcoding them with emby. I need to be able to transcode the 4k files to play on other 1080p TVs in the house as well. So far I've had to use ffmpeg to manually transcode 4k HEVC content to H.264 instead for better playback, but this is not ideal (I would like to use emby's transcoding).

 

I am aware Intel has released their Kaby Lake processors which support 4K HEVC, but wondered if anyone has had any luck playing 4k HEVC 10bit content on this on Emby/Ubuntu and if this enables better live transcoding of 4k HEVC content to 1080p, or if anyone has any suggestions that may help. However my main concern is transcoding it down to 1080p for other TVs.

Edited January 1, 2018 by robawarner

[Luke 37129]

hi there, can we take a look at an example? please attach the information requested in how to report a media playback issue. thanks !

[robawarner 0]

Not entirely sure which logs to post but here is a start-up log just before tried playing it and the transcode log from when I set a 1080p device to transcode to screen resolution and tried to play a 4K x265 10 bit file.

 

Trying to play any 4k x265 files that require transcoding end up 100%ing the CPU and the transcoded playback stutters occasionally and keeps stopping to buffer.

Trying to play any 4K x265 file without transcoding end up 100%ing the cpu and stuttering, blockyness etc on my current i5.

ffmpeg-transcode-df1e16bc-f56a-4230-9ed6-2de0ca6cd18a.txt

server-63650362721.txt

Edited January 1, 2018 by robawarner

[Luke 37129]

Hi, what Emby app are you trying to play from? In this log it appears you're just not getting fast enough transcoding to allow this to be playable.  

 

In order to play this file, you may want to use an Emby app that can play it without any transcoding. Thanks.

[robawarner 0]

Hi, what Emby app are you trying to play from? In this log it appears you're just not getting fast enough transcoding to allow this to be playable.  

 

In order to play this file, you may want to use an Emby app that can play it without any transcoding. Thanks.

 

I'm using the the Emby addon for Kodi, both the emby server and Kodi are running the same machine. I'm trying to play the file on the same machine, but on a 1080p TV. The file without transcoding doesn't play very well so I enabled the option to transcode it down to 1080p and that's when this occurs. I imagine it's because 4k H.265 doesn't work well unless you have a dedicated hardware decoder for it, which the i5-4690 doesn't. However, I want 4k files to play on my 4K TV but I have other 1080p TVs that don't support 4k playback, which is where transcoding comes in for me.

[Luke 37129]

Ok, have you considered that your server machine might not be powerful enough for this? It's possible we may end up with that conclusion.

[robawarner 0]

Ok, have you considered that your server machine might not be powerful enough for this? It's possible we may end up with that conclusion.

Thanks for your replies I have, I'm wondering if anyone has had any luck getting 4k HEVC playback and especially transcoding to work on Ubuntu emby and what hardware they used, especially the Intel kaby lake CPUs.

 

I had a crack at getting Intel quick sync to work, following https://emby.media/community/index.php?/topic/48588-confirmed-linux-intel-quick-sync-transcoding/ however it didn't seem to help.

[Luke 37129]

Our ffmpeg builds that we supply for Ubuntu only have VAAPI included, so that's why QuickSync didn't work for you. On Linux I think vaapi is the best option anyway.

 

@@Waldonnis any thoughts on a minimum hardware requirement for a 4K hevc transcode? Thanks.

[Waldonnis 148]

Decoding HEVC Main 10 at 2160p (especially if it's 60fps) with software decoding can be a bear, that's for sure, and the colour space conversion doesn't help matters either.  Looking at the log, it certainly looks like the decoding is the rough part, and the encoder is basically bottlenecked by the slow decoding speed.

 

You have a couple options if you want to use hardware decoding - either a Kaby Lake (or newer) or a GTX-1060 (or above).  Encoding using h.264 with hardware encoders is supported handily on both, at least, although the nVidia option will be limited to two simultaneous streams.  I am in the same boat with hardware encoder support (3570k and 970 here, and 2160p playback is choppy at best here), so I can't speak to how well ffmpeg plays with KL, but there are some other folks here that have some experience with it.  KL should be reasonably cheap these days, thankfully.

 

That being said, converting 10bit->8bit may not be that great of an idea to do like this.  It can be complicated to do correctly depending on the original colour space and how much of the original's colour space is actually used...and you may see some banding or artifacts that wouldn't be present on a professionally-done 8bit encode of the same material (yay custom luts and grading).  Downscaling should help a tad with banding, thankfully, but you may still run across source material that looks weird, bland, or dark when converted and compared to the original.  To get an idea, check around the net for differences between Rec.2020 and BT.709 when it comes to coverage and conversion.  It's possible you wouldn't notice many (or any) differences, but some are more sensitive than others to the types of dithering that get employed when doing more automated conversion methods and not all films are the same anyway colour-wise.

[Luke 37129]

Thanks @@Waldonnis.

[robawarner 0]

Thanks for the reply @@Waldonnis, I may have to bite the bullet and go the kaby lake route (I can't add a GPU to my current setup, only have 1 PCIe slot :/) and hope it can handle transcoding it. I've struggled to find info on whether people have managed 4K HEVC transcode on Ubuntu with Kaby lake but am going to keep looking around

 

I'm going to have another bash a getting quick sync to work too, I don't believe it was given it still used 100% CPU and the playback experience didn't see any different (same amount of stopping to buffer).

Edited January 2, 2018 by robawarner

[Waldonnis 148]

Decoding alone may have been the reason for the CPU hit, although looking back at the log, I'm seeing an audio transcode as well which is just adding to the load (no idea why, since it's ac3->ac3; may just be hitting a bitrate limitation).  If you want to try it, you can do a rather simple test that just decodes the video without writing anything or incurring output overhead.  Here's a sample command line for it that just uses the software decoder (just substitute your filename for test.mkv and quote/escape as necessary):

ffmpeg -i test.mkv -map 0:v -c:v rawvideo -hide_banner -stats -f null -

All it does is decode the video to raw frames, so it should be a pretty good indication of the video decoding side of the workload.  If you watch your CPU load and ffmpeg's fps speed while it's running, you can get an idea of how well/poorly your CPU can handle it.  Colour space conversion, downscaling, subtitle overlays, and any audio decoding/encoding will require some CPU cycles as well, so it won't be the complete "load" picture, but when HEVC is involved it's usually the heaviest part of the workload.

 

To give you an idea, I just ran a quick test on my system (lightly loaded, and Windows) with one of the LG OLED 4k HEVC Main 10 demo clips - software decoding was running ~38fps and CPU usage was ~98%, so any additional operations (audio manipulation, video re-encoding, etc) would just reduce that rate to below native framerate since the processor doesn't have any more to give.

[robawarner 0]

Hmm interesting, I gave that a try and at ~98% CPU it was doing ~34 fps. It is also odd that it is transcoding audio too.

I used ffmpeg to create a h.264 version of the file and using that command above I get ~ 60fps at 98%.

 

I'm going to attempt to build ffmpeg myself soon to see if quick sync will work and help, but seemingly based on this test, a kaby lake processor with the HEVC decoder may be the way to go.

[Waldonnis 148]

Oops, just realised I pasted the wrong test's command line.  Try it without the -c:v rawvideo part.  The command I posted does roughly the same thing, but with slightly more overhead.  You shouldn't see much of a difference, maybe 3-4fps and no real CPU load difference, but may as well go with a more correct test of the demuxing/decoding portion.

 

h.264 is definitely easier to decode, so you'll see better numbers there.  It's a shame that playback support for 4k h.264 is so scarce     Using vaapi to decode should help lighten some of the load for h.264, although you won't see much of a speed difference with it usually.  Sometimes it'll actually be slower since many hardware decoder interfaces are single-threaded, but more consistent and somewhat independent of system load.  You can try adding some of the vaapi options to the test command to see how that works out with your h.264 source for comparison's sake.  I can't test this here, but something like this should work:

ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -i test.mkv -map 0:v -hide_banner -stats -f null -

That should do a vaapi decode with the decoded frames being copied to system memory, so you'll see some system activity with it.  It shouldn't be nearly as much as a software decode, though.  There are some variations for outputting to a hardware surface or specifying the pixel format (supposedly a bit faster), but that's probably good enough.

 

Side note: the "ideal" condition is to maintain an encoding speed that's above the native framerate in a live transcoding situation, so if the native framerate is 23.976, even a stable 25fps encoding speed should be watchable if there are no network or client hiccups.  Of course, higher is going to be better to make it easier for the client device to keep its buffer full to ensure smooth playback.  The resolution is likely what's killing both of us in this scenario, since I had no issues with decoding HEVC Main 10 at 1080p at watchable framerates just last week (was playing with a few x265 options that were recently added).

Edited January 2, 2018 by Waldonnis

[robawarner 0]

Using that on the 4k HEVC file gets me ~ 51FPS @ 98%, but it still struggled while transcoding it on emby, but that's probably because of the audio transcode (as you pointed out) and the fact its being played back on the same machine.

[Luke 37129]

Yea and also keep in mind that command is decoding only and not subsequently encoding to an actual playable format.

[Gerrit507 24]

Hi,

 

Your CPU or better your iGPU is too old to support hevc 10bit decoding. You need at least a 7th Gen Intel CPU to achieve this. Also Apollo Lake supports it but their gpus are really weak and I haven't had much success with those chips in this regard.

 

The 7th gen Intel CPUs provide two different GPUs: HD610 and HD630

 

Only the very cheap Pentiums come with the HD610 and you get the HD630 with the Pentium G4600 upwards. All better CPUs, like: i3, i5 and i7 all have this GPU, which means when it comes to hw-transcoding their performance is basically equal.

 

I run a G4600 under Ubuntu 16.04 with emby and vaapi hw-transcoding. It runs really well. It handles up to 4 simultaneous hevc 10bit 50Mbps movies transcoded to 5mpbs h264. It's probably the cheapest and most future proof media server you can build and also having a really low power consumption. The CPU and a board will probably cost you about 130€ and thats it.

 

Doing only the decoding on the CPU is already so intense that it will fully load your i5 with one stream. I've tried it on an FX8320E@4GHz for example, which was at 95%+ software decoding hevc 10bit content.

Edited January 2, 2018 by Gerrit507

[robawarner 0]

I run a G4600 under Ubuntu 16.04 with emby and vaapi hw-transcoding. It runs really well. It handles up to 4 simultaneous hevc 10bit 50Mbps movies transcoded to 5mpbs h264. It's probably the cheapest and most future proof media server you can build and also having a really low power consumption. The CPU and a board will probably cost you about 130€ and thats it.

 

Are those 4K files @@Gerrit507?

[Gerrit507 24]

Are those 4K files @@Gerrit507?

Yes UHD BD remuxes and captures.

[robawarner 0]

Yes UHD BD remuxes and captures.

 

Damn, that's impressive. It may be time to update to kaby lake

[Ionian 0]

Not trying to hijack this thread, but I too have a latest gen CPU with Intel UHD 630 graphics, namely the i7-8700 and I'm not as successful as @Gerrit507. By no means am I able to get emby to use hw acceleration when transcoding.

I'm currently evaluating emby as an alternative to Plex which although it uses hw acceleration and CPU and GPU are pretty low in consumption it still stutters badly. 

For testing I am using some 4k HEVC 10bit clips at around 50Mbs from 4kmedia.org and emby and the CPU do a great job at software transcoding all but the 60 fps ones where it buffers from time to time (much better than Plex). The CPU sometimes gets to 100% usage though for a single stream and would like to offload most of that to the built in GPU. No matter what settings I tried in the transcoding page of the server configuration, it is still 0% GPU consumption for ffmpeg and CPU all the way.

 

It seems to transcode using HW acceleration for the following media though: 

 

Container: MKV

Video Codec: h264

Bit depth: 8

FPS: 29.97

Bit rate: 8Mbs

Resolution: 720P

Pixel format: yuv420p

Audio: DTS 5.1 48Khz 

 

However, resource consumption for the ffmpeg process is huge considering the media characteristics: CPU 25%, GPU 65%

 

 

Please help, what am I doing wrong here?

[Luke 37129]

@@Ionian this is normal because ffmpeg will go as fast as it can. In server transcoding settings you could try lowering the max thread count, which may help, but may have other consequences as well.

[Ionian 0]

@@Luke, thanks for the reply! That makes sense and indeed I set the number of threads to Max . If I remember correctly it stepped on it and didn't let it go until transcoding the entire clip. Should't throttling prevent that and only transcode for the specified time interval hence creating some gaps in the CPU load?!

 

Anyways, that's not the main gripe. The hw transcoding for hevc hdr is the problem. I'd like to free up the cpu for other tasks and no matter what client I tried, it never used hw transcoding. I've used the latest version of the server and latest versions of:

- Emby for Android

- Emby addon for kodi for Android( strangely enough this was a better experience than using the standalone emby app)

- Emby for Samsung SnartTV (2014 H Series)

- and the web interface on the same machine as the server

 

Please note this machine is a new build with latest BIOS update, latest Windows updates and latest drivers installed.

 

Is there anything I could try to make this work ( apart from changing to ubuntu that is )

 

Thanks!

[Luke 37129]

Ok, please discuss an example and attach the information requested in how to report a media playback issue. thanks.

[Ionian 0]

OK, here it goes:

 

Test is being performed on a new i7-8700 build with 8GB of RAM at 2400MHz running Windows 10 Pro 64 bit BIOS, Windows Updates and drivers all up to date.

For playback I am using the WebApp running on the same machine as the server in this example just to eliminate the suspicion of any shortcomings of the other apps (or the systems they are running on) as well as any potential network related issues.

Using one of the 4k samples at 4kmedia.org, http://4kmedia.org/lg-new-york-hdr-uhd-4k-demo/, I am starting playback from the web interface.

We're talking about a 4k 10 bit h265 encoded file here at 25 fps and 50Mbs bitrate (screenshot with detailed info attached). The playback is smooth and when looking at the server dashboard I can see the played item being described as being transcoded. 

On the server's transcoding  page I have the HW acceleration enabled using Intel Quick Sync for both decoding ( all available codec options checked) and encoding (screenshot attached). However, when looking at the CPU/ GPU consumption I get something like 50%CPU and 0% GPU for this particular clip (other clips which we can discuss later if needed are even worse taking the CPU to 100% on occasion and causing stutter).

 

I have cleaned up all logs folder and then started the server followed immediately by playing this file, followed by shutting down the server so that to isolate this problem alone in the logs. I am attaching all existing logs generated by this operation as well as some screenshots to better illustrate the settings and behavior.

 

Maybe also worth mentioning is that this system has no additional codecs installed apart from what Windows came with.

As a reference, when playing this file on the same machine (FullHD 8 bit monitor connected using HDMI) using the default Windows built-in movie player "Movies & TV" in Full Screen I get about 1% CPU consumption and 40% GPU consumption (screen shot attached) so it looks like what ever codecs are present they are performing pretty well and make good use of the available hardware. I understand transcoding is also about re-encoding but still to playback the file we're already talking about demuxing, decoding, color space conversion and rendering which should account for something.

 

Please let me know if I need to try anything or give more info.

 

Thank you!

 

ffmpeg-transcode-0f8faf4d-b4b6-48a0-a679-69b84173445a.txt

ffmpeg-transcode-48a3eebb-9f1c-4690-8969-fff428d0dd8e.txt

ffmpeg-transcode-59b6c99c-8e59-4f50-9b5d-69671ce29252.txt

server-63654574157.txt