Transcode in H265

[byakuya32 17]

Where is h.265 conversions in the roadmap?

[Luke 36992]

We are working on it, thanks.

[Luke 36992]

First step:

https://emby.media/community/index.php?/topic/58662-emby-convert-convert-to-h265-replace-video-files/?p=793012

[wiwolavida 4]

great news. Can't wait for h265 transcode.

keep it up Luke =)

[MyMediaAtHome 2]

I concur that's the direction to take initially for quite some time.  I think the main things to keep it simple would be to let the user select between FAST, MEDIUM or SLOW.  If they want weight B frames with SLOWEST let them use Handbrake or ffmepg themselves.  I use CRF 22 for all my encodes with SLOW.  Perhaps let them choose a CRF of 18, 20 or 22. I've been out of encoding for quite sometime and only recently have got back into it.  I used to be a moderator over on doom9 and here is a couple of relevant screenshots regarding energy consumption and what the various speed presets offer. From my experience it takes 5x more time to encode and also 5x the CPU usage to decode but is generally 40% smaller in file size compared with x264 so definitely worth it.

 

That's very interesting info, but I must admit that table is way above my head :-)

Do you also have simple table that shows:

• Size reduction at various settings for Ultra fast - Placebo for 4k material
• Same for 1080 material.
• Same for 1080 material.

 

Which transcoders do you recommend?

 

I'm trying to find a balance between quality and bandwidth requirements.

Edited December 12, 2019 by MyMediaAtHome

[Charlie117 56]

That's very interesting info, but I must admit that table is way about my head :-)

Do you also have simple table that shows:

• Size reduction at various settings for Ultra fast - Placebo for 4k material
• Same for 1080 material.
• Same for 1080 material.

 

Which transcoders do you recommend?

 

I'm trying to find a balance between quality and bandwidth requirements.

 

The majority of the settings listed do not really affect the file size as much as the quality. They do however significantly affect the encoding time when changed.

 

File size is primarily the result of the bitrate or CRF value you tell the encoder to use. Encoding is usually a tradeoff between time, file size and quality.

 

Both x264 and x265 are good encoders, with x265 being significantly slower than x264 at moderate settings.

 

Finding a balance between quality, file size and time is very subjective. Try doing some test encodes yourself and decide for yourself what you find acceptable. 

[MyMediaAtHome 2]

I have plenty of time when encoding the source material that's just something I keep running 24/7. So I would likely pick a slower setting.

I'm mostly concerned about the speed and power usage when streaming it over internet.

 

Which video encoder the table is based on?

[Charlie117 56]

I have plenty of time when encoding the source material that's just something I keep running 24/7. So I would likely pick a slower setting.

I'm mostly concerned about the speed and power usage when streaming it over internet.

 

Which video encoder the table is based on?

 

That table is based on the x265 encoder settings and shows you the settings for the 10 available presets.

 

You can use those built in presets as a starting point. Try --preset slow and pick a bitrate appropriate for the source content and resolution.

 

Please note that decent x265 settings can grind a modern i7 processor to a halt at 1-4 fps transcoding speed. 

Edited December 12, 2019 by Charlie117

[MyMediaAtHome 2]

I'm getting a video card that does x265 encoding. That hopefully helps a lot.

 The encoder is Handbrake?

[Charlie117 56]

I'm getting a video card that does x265 encoding. That hopefully helps a lot.

 The encoder is Handbrake?

 

GPU hardware accelerated encoding is definitely very fast and usually transcodes faster than realtime (>24fps). Do note however that hardware accelerated encoding is a tradeoff between speed and quality. It should be comparable to the x265 preset 'fast'. If you really want the best quality, you need to use x264/x265 and use the CPU for transcoding.

 

The encoder is x265. Handbrake is GUI that supports both x264 and x265.

Edited December 12, 2019 by Charlie117

[TonioRoffo 4]

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.

 

Can I make a humble suggestion for this problem - enable heavy tweaking in beta versions, hide them in main versions.  No need to use your resources to fix, beta testers & powerusers tweak their heart out which then feeds back in mainstream versions?

[Luke 36992]

Always possible for the future. Thanks.

[Charlie117 56]

Can I make a humble suggestion for this problem - enable heavy tweaking in beta versions, hide them in main versions.  No need to use your resources to fix, beta testers & powerusers tweak their heart out which then feeds back in mainstream versions?

 

+1

 

I really wish Emby had more advanced options for those that want to tweak settings. Just hide those options away in beta versions or in an expert menu.

[fizzyade 124]

Bump for @@Luke.  i think many of the reasons against this earlier in the thread are non issues anymore, hardware transcoding is something a lot of people use and the benefits to low bandwidth clients are huge.

 

I’d say that an opinion “Cellular clients use h265 transcoding” which forces h265 if the client is cellular would be a good start (client obviously can detect whether it’s using WiFi or Cellular data) but in my situation this wouldn’t help as my daughter is using a 4G router, so the client thinks it’s just connected to wifi.

 

An option in the client “Prefer h265 for transcodes” would be ideal, with server side settings allowing selection of formats allowed as a transcode target, so h265 can be disabled on a per server setting for servers that don’t have the capability.

[Baenwort 97]

+1

 

I really wish Emby had more advanced options for those that want to tweak settings. Just hide those options away in beta versions or in an expert menu.

 

or put them in a .ini file somewhere that powerusers can tweak.

[Gee1 10]

now its 2020 and it time to implement x265 encoding on the fly. Every device will support it. And thanks to NVENC its really fast.

[fizzyade 124]

I did some experimental stuff that I’m not sure if I still have, it basically consisted of a python script that “stubbed” the ffmpeg binary. I was using it to try and solve some tv issues I was having, it allowed me to add, remove or change the command line that Emby sent to ffmpeg.

 

I wonder if for a hacky solution this could be utilised. I’ll go see if I still have any of it.

[WGB123 8]

GPU hardware accelerated encoding is definitely very fast and usually transcodes faster than realtime (>24fps). Do note however that hardware accelerated encoding is a tradeoff between speed and quality. It should be comparable to the x265 preset 'fast'. If you really want the best quality, you need to use x264/x265 and use the CPU for transcoding.

 

The encoder is x265. Handbrake is GUI that supports both x264 and x265.

 

Best quality for any given data rate is H.265 (compared to H.264).  Those of us clamoring for H.265 hardware transcoding are looking for the best quality we can get over connections that are lower bandwidth (for various reasons).  In my case, I want realtime (hardware) H.265 transcoding for live TV (news and sports) to be streamed over a trans-Pacific connection.  News, sports (and maybe award shows, LOL) are really the only things that one "needs" to watch the moment they air.  Anything else I can convert and download to be watched later.

Edited March 12, 2020 by WGB123

[fizzyade 124]

Best quality for any given data rate is H.265 (compared to H.264).  Those of us clamoring for H.265 hardware transcoding are looking for the best quality we can get over connections that are lower bandwidth (for various reasons).  In my case, I want realtime (hardware) H.265 transcoding for live TV (news and sports) to be streamed over a trans-Pacific connection.  News, sports (and maybe award shows, LOL) are really the only things that one "needs" to watch the moment they air.  Anything else I can convert and download to be watched later.

 

Came here to reply to your unedited post to disagree for my own personal situation about your statement saying "Of course, we all know (or should) that if we wanted to transcode a FILE that existed somewhere we could just convert it in advance of streaming it in H.265 and the CPU conversion would be the better way to do that."....but you'd already edited and changed it out!

 

I have the hardware in my machine to do the realtime transcodes, I couldn't really tell the difference in most situations between say at 10Mbit file and 15Mbit file where there isn't a lot going etc.  I don't know actual numbers, but lets say h264 takes 10Mbit and the equivilent h265 takes 5Mit, then I'm going to down the transcode limit to reduce load on my internet, my daughter and a couple of friends are the only people who use my server apart from myself and my wife when we are not home.

 

As I have the hardware to handle the transcoding, I personally don't want 2 copies of the same film in 2 different codecs, it's bad enough from my point of view that I have to do it for 4k HDR movies because we don't currently have a tone mapping solution, but when we do, I'll be saying goodbye to to to the 1080 files and let my hardware transcoding take care of it.

 

I want h265 to reduce the used bandwidth, this has particular uses as my daughter has a cellular connection for her internet and when we are out we usually are tethered to my phone.

 

But you and others may want it for the opposite reason, higher quality for comparable bandwidth.

 

Either way, we need this option now.

[nayr 36]

My P2000 will happily saturate my Xfinity GigE uplinks in either 264 or 265... I cant do anything to reasonably acquire faster upload speeds (45Mbps) but I could support more users at same quality or same users with higher quality if only this was implemented. 

 

With FireStick 4k dropping down to $25 every once and a while, my last few users who were holding out w/non HEVC decoders (Old Firesticks mostly) all upgraded in the last year.. I dont have a single user connecting to my server w/a client that dont support HEVC anymore.. unless you count my Admin account that only logs into web browser, but that only plays video for testing purposes and I could care less if it was HEVC.

 

I've already changed my Sonarr settings to upgrade to HEVC sources when available, but nothing I can do about LiveTV.. even 4K LiveTV games come in H264 @ 40Mbit so I dont expect IPTV to make the change to HEVC anytime soon.

[Luke 36992]

It allowed me to add, remove or change the command line that Emby sent to ffmpeg.

 

This is unlikely to actually work because the whole transcoding method will have to change, not just the params on the existing method.

 

We will get there. The soon to be released Emby Server 4.4 brings a lot of hardware transcoding improvements, including HEVC conversion for the conversion/download features.

[wiwolavida 4]

Best of luck with that, Luke =)
I hope I'll be able to watch my 4k collection remotely soon.

[Gee1 10]

waiting for 4.5 with hopefully hevc live transcoding xD ^^ and hopefully hdr. Example: original (40Mbit 4k HDR) to (10Mbit 2k HDR)  )))

[YeJ 0]

I also hope living transcoding can support hevc, My server and device both support hevc HW.

 

Thanks!

[syadnom 24]

I'm continuing my request here because my thread was marked dup (I don't think it's exactly the same as this thread)

 

I don't want to do a bunch of h.265 transcodes, I want to store h.265 chunks on disk during initial recording so all clients automatically get the h.265 stream and I've only spent the CPU once.  

post-process encoding means people watching live tv will still stream either the mpeg2 stream or have to use my hdhomerun's pretty crappy h.264 encoder (it's really aweful).  post-processing is great for watching recordings but doesn't do anything for the live tv watchers. 

 

h.265 transcoding is a great feature, but I also really don't want multiple live tv viewers to completely crush the system doing these transcodes.  If an h.265 transcoder is put in place please make sure the HLS chunks are available to all users for a single transcode and multi-playback.