In-Progress Transcode in H265

[Snaaaake 81]

Hi,

 

I would like to have an option to choose H265 instead of H264 in the Transcode option.

It will be smaller for all bad bandwidth (2~5Mbit ADSL), but will have a great quality.

Mobile phone can benefit of it greatly too with the 4G and the limitation of download.

 

[Luke 39640]

Do you mean for playback or for offline downloading? Because for playback, not all devices support h265 yet.

[Snaaaake 81]

playback, Emby for android TV with Shield with a poor connexion could use it.

 

If you put an option on

                                    Client side "Use H265"

                                    Server side "Allow users to use H265" 

 

like that you don't care if devices are compatible or not, User have the choice.

[Deathsquirrel 744]

like that you don't care if devices are compatible or not, User have the choice.

 

Not my call but that is WILDLY contrary to the spirit of this project.

[Snaaaake 81]

We have choice for the material acceleration, threads, profil, crf, downmix,  why not for the codec?

[ebr 15576]

Also, encoding to hevc will require quite a bit more resources on the server end.  Most people's setups wouldn't handle it well I imagine.

 

We try to limit the number of options we put in that would only benefit very small audiences and have the potential to cause large audiences to make problems for themselves .

 

Eventually, I'm sure this will be the norm but I'm not sure it is ready yet.

[sebasmiles 8]

I would also like to see emby eventually support this either by default or as a poweruser option thanks to the substantially reduced bandwidth requirements (I think it cuts bitrate for same quality by like 40%). There are quite a few hardware solutions out there that support playback like FireTV Gen 2, Samsung S8 phone, etc.

 

EDIT: After further quick review it seems that the CPU processing required is substantially more than H264 (like 10 times more?). Native encoding on Quicksync seems to be implemented into Skylake and newer, so I guess that means that only very new servers or a h265 compatible standalone GPU would be required? If this is right then you guys are on the money, playback may be easier but the chokepoint will be on the encoding side...Thanks for considering this though, perhaps in a couple years it may be valid.

Edited August 2, 2017 by sebasmiles

[JeremyFr79 228]

I would also like to see emby eventually support this either by default or as a poweruser option thanks to the substantially reduced bandwidth requirements (I think it cuts bitrate for same quality by like 40%). There are quite a few hardware solutions out there that support playback like FireTV Gen 2, Samsung S8 phone, etc.

 

EDIT: After further quick review it seems that the CPU processing required is substantially more than H264 (like 10 times more?). Native encoding on Quicksync seems to be implemented into Skylake and newer, so I guess that means that only very new servers or a h265 compatible standalone GPU would be required? If this is right then you guys are on the money, playback may be easier but the chokepoint will be on the encoding side...Thanks for considering this though, perhaps in a couple years it may be valid.

The issue with Skylake and trust me I know as I have one, is that h.265 is ONLY supported on Skylake with Windows10.  Skylake is unsupported on any other OS as far as the GPU drivers are concerned.

[Luke 39640]

We have choice for the material acceleration, threads, profil, crf, downmix,  why not for the codec?

 

Because what will happen is users will enable things that their devices don't support, and then they'll assume there is some kind of Emby problem and expect us to fix it.

[Snaaaake 81]

If i understand, we have to wait 10 years to be sure everybody will have a supported device ? 

 

I'm joking, but if you put profile wtih recommanded configuration, everyone can understand that.

[Luke 39640]

No, you don't have to wait 10 years, but we do need to consider how reliable it's going to be, and how many people will actually want to use it given the CPU requirements. Just like any other feature request, we want to see what kind of audience it will have before committing to the work.

[otispresley 103]

Just to add a bit here and to offer my $0.02 or less  , HEVC encoding does use quite a bit more resources and really heavily depends on the CRF/VBR settings used and the encoding preset. I did a lot of research on this and the claim that a CRF of 23 when encoding a Blu-Ray source is visually lossless is just not true. If you have a good display, like a 4k with a larger screen, you can certainly see the difference. 

 

I ended up going with CRF 12 to get to visually lossless with my setup when encoding my collection to HEVC. CRF 23 with the Ultra Fast preset does encode pretty quickly, but you can see the difference between source and destination material. This is fine for smaller devices, but any larger device that can handle the output will suffer in quality with transcoding. For those with hardware accelerated HEVC support, there won't be much of an issue until the transcode tries to output at a 4k resolution because the device is 4k. The output resolution would need to match the source.

 

Also, some source material encodes much faster than others, depending on CODEC, picture quality, motion, etc. VC-1 for instance normally went at about 15 FPS (some lower and some higher) on my server with 2x E5-2660 Xeons. The 32 logical cores struggled greatly without hardware encoding support. Those titles take nearly twice as long as the source video length to transcode with output being 1920x1080. Titles with HEVC typically ran at about 28 FPS but still very CPU intensive and it would never be able to encode fast enough to handle 2 encodes at once if it were on-the-fly.

 

HEVC is great for reducing the size of your video library, even though at CRF 12 some few files end up being larger than the source. Even at that CRF, the overall size of my library was reduced by slightly more than 50%. However for on-the-fly transcoding, this would not be a viable option for me without some significant hardware assistance.

Edited August 3, 2017 by otispresley

[Waldonnis 148]

Interesting that you went as low as 12 for CRF, but I agree that 23 is definitely not visually lossless for any "normal" source material that I've encountered including 1080p stuff (animation may be fine, but who knows).  I find 18/slow (maybe medium depending on source) to be the absolute highest CRF value I'd ever go with, and even then, it requires a lot of other options to make it work.  16 isn't bad for most stuff, in my opinion.  Below that is splitting hairs and I've found that introducing some other tuning/analysis options can make a huge difference and allow for some flexibility in CRF choice.

 

You're absolutely on-target with encoding HEVC, though.  It's brutal to do on a CPU and even some of the better processors would barely keep up trying to transcode a single 4k source to HEVC at a watchable framerate using software en/decoding.  Transcoding performance of 720p/1080p sources to HEVC is better, but it's still a computationally heavy codec to deal with and supporting more than a stream or two would be rough on many processors (again, assuming software en/decoding).  Bitrate savings can be nice with HEVC, but the amount of processing required to achieve it in a live-transcoding situation is just disproportionate to the gain at this time unless you have hardware encoding available...and even then, hardware encoders often have limitations that make things like detail/grain preservation more difficult.

 

Side note: HEVC stores 10bit material more efficiently than 8bit, so transcoding 8bit sources to HEVC Main10 files often results in even smaller file sizes/bitrates than if you had just used HEVC Main.  If you're doing any library conversions to save space, try it out and see if it helps with your particular files (12-bit storage is more efficient than even 10-bit, but the difference is smaller compared to 8->10 and compatability of the resulting file is reduced even further).

[JeremyFr79 228]

I realize I mis stated in an earlier post, KabyLake not SkyLake only allows access to it's GPU and it's HW Acceleration in Windows 10, Skylake only has partial HEVC capabilities.  None the less this does you no good if you're using a real server OS instead of a desktop OS.

[Waldonnis 148]

I don't see why Windows 10 would be required for Kaby Lake hardware transcoding at all.  The only restriction of this type that I know of is for playback of streaming media from services like Netflix in 4k (or any service that requires PlayReady 3.0 support), since they require the DRM to be available...and PlayReady 3.0 is only available with Windows 10 ("or later").

[JeremyFr79 228]

I don't see why Windows 10 would be required for Kaby Lake hardware transcoding at all.  The only restriction of this type that I know of is for playback of streaming media from services like Netflix in 4k (or any service that requires PlayReady 3.0 support), since they require the DRM to be available...and PlayReady 3.0 is only available with Windows 10 ("or later").

The driver will NOT install in any other OS, you need the driver to access the h.265 capabilities of the chip.  Trust me I fought this for a week.

[Guest asrequested]

Yeah, only generic drivers are installed.

 

http://www.tomshardware.com/answers/id-3299031/kaby-lake-graphics-630-video-drivers-windows-x64.html

 

http://www.tomshardware.co.uk/intel-kaby-lake-core-i7-7700k-i7-7700-i5-7600k-i5-7600,review-33752-2.html?_ga=2.131894991.138801399.1501911081-418770765.1501911081

 

[denz 453]

I have kaby lake pc and win 7 doesnt work on it stops responding after few minutes crashes and had no choice but to install win 10 which works perfectly luckily wmc works perfectly.

Edited August 5, 2017 by denz

[Waldonnis 148]

The driver will NOT install in any other OS, you need the driver to access the h.265 capabilities of the chip.  Trust me I fought this for a week.

 

Well that's a dumb restriction that I wouldn't have expected.  Thanks for the info.  I can guess why they did it, but it doesn't make it any less ridiculous.

[Deathsquirrel 744]

Well that's a dumb restriction that I wouldn't have expected.  Thanks for the info.  I can guess why they did it, but it doesn't make it any less ridiculous.

 

You also can't run windows update on those cpus if you use earlier versions of windows.

[Guest asrequested]

And let's not forget that you also need the 270 chipset. Without that, you don't get all the features of the HD 630 GPU. 

[JoshuaAJones 64]

Okay. I understand that transcoding to HEVC/x265 would take up vast resources but so does converting to h264.

My HTPC is hardwired to my AVR/TV through the PC input so it doesn't transcode my data, it plays it natively.

As 95% of my library is x265, is there a possibility of getting a "Play Video Native" option on the client side of Emby?

Most of my devices can handle the stream perfectly. I'd just like an option for my users not to have to transcode at all.

[ebr 15576]

Okay. I understand that transcoding to HEVC/x265 would take up vast resources but so does converting to h264.

 

No, the two are very different in the resources they require...

[Deathsquirrel 744]

Okay. I understand that transcoding to HEVC/x265 would take up vast resources but so does converting to h264.

My HTPC is hardwired to my AVR/TV through the PC input so it doesn't transcode my data, it plays it natively.

As 95% of my library is x265, is there a possibility of getting a "Play Video Native" option on the client side of Emby?

Most of my devices can handle the stream perfectly. I'd just like an option for my users not to have to transcode at all.

 

If your devices can play something natively and aren't, please open a new thread in the server forum including a description of the issue with the details listed at https://emby.media/community/index.php?/topic/790-how-to-report-a-problem/.

[Luke 39640]

Hi @@JoshuaAJones yes can you please see the link above and go over an example? thanks !