Jump to content

Transcode in H265


Snaaaake

Recommended Posts

JeremyFr79

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

This is no joke.  As an example my now former Emby Server had (4) 8 Core Xeon 7555 processors for a total of 32 cores/64 threads.  Transcoding H.264 I could comfortably transcode 20 streams.  H.265, I could get maybe 2 or 3.  

  • Like 2
Link to comment
Share on other sites

  • 6 months later...
Fratopolis

You could put a hard cpu limit with this feature addition. Say Emby would not even give the option to users to use said feature unless they had a certain cpu or newer with xN of cores/or a certain Nvidia Gpu or newer.

 

This would stop users from checking an option they just cannot use. Like my setup for instance would be a no go.

Edited by Fratopolis
Link to comment
Share on other sites

mastrmind11

But then it's emby's responsibility to enumerate all possible hardware that can support it.  IMO it would be easier/more effective to put a blank field on the transcode page that appends whatever is in the field to the ffmpeg command emby uses.

  • Like 1
Link to comment
Share on other sites

Perhaps a better plan to get started with H.265 is to first make sure you have a server that can do H.265 decode/encode in HW.

Create a test library or two (movies/shows) and convert a few test files to H.265 outside of Emby.  Focus on quality conversions (don't need to be real-time) using the least bitrates needed if you objective is to support more internet users with a lower upload bandwidth on your server.

 

Create both 8 bit and 10 bit sample files.

 

Test playback of these H.265 files on all of your devices for quality as well as any issues you might have.  For example check subtitle support, dolby, dts, atmos playback and see what happens when the device doesn't support the audio track.  Will you get a full transcode or just the audio portion?

 

Assuming that test goes well, now force a full transcode of the same test files and see what the quality looks like when transcoded back to H.264 in real-time.

 

If you want to move forward to H.265 this might be a good way to go if you have the HW to transcode back to H.264 when needed and can support the amount of streams needed.

 

What I'd caution is to play with both high bitrate movies/shows as well as lower bitrate shows.  You might find the quality is very good on the original higher bitrate shows while quality takes a nose dive on lower bitrate stuff.  By this I mean a movie that is in H.264 with 20Mb bitrate is going to convert and look much better than something that was in H.265 with only 5Mb bitrate to start with.

 

If you're supporting non-lan/internet users then make sure to test this way as well.

 

When selecting a "target" bitrate keep in mind your objective.  Is it just to reduce storage or is it create files with a lower bitrate because you have very limited upload bandwidth?

 

Generally speaking it will take less resources to decode H.265 and to encode H.264 then the other way.  

 

Carlo

Link to comment
Share on other sites

Fratopolis

But then it's emby's responsibility to enumerate all possible hardware that can support it.  IMO it would be easier/more effective to put a blank field on the transcode page that appends whatever is in the field to the ffmpeg command emby uses.

 

Very true

Link to comment
Share on other sites

  • 2 months later...
EraYaN

I started a patch that at least adds the nvenc (no hassle just works, well done nvidia) and the qsv hevc encoders (finicky) plus the libx265 fallback. Now the qsv encoder is rather difficult to get working. It requires extra command line arguments, '-load-plugin hevc_hw' to be precise and without a -maxrate it breaks (on skylake) as well.

This was all tested on a custom built ffmpeg 4.0 with every bell and whistle enabled. On a Windows Server 2016 machine running on a i5-6600K.

I'm having some trouble with some parts of the code base, my visual studio reference finder has a lot of trouble with how dynamic and fancy some of the calling stuff is. So actually properly debugging the ffmpeg output and stuff is hard.

 

I might get it all working at some point in the next couple of weeks. That way we on shitty networks can still enjoy at least decent 720p. (I'm trying to watch cross-eurasia and well damn... 5-8 Mbit if I'm lucky, but not on one TCP stream)

Link to comment
Share on other sites

Karl Blixt

If I understand the reason for not having this option right: it's a niche settings that could make the client stop working if set up incorrectly? 

 

which I find a fair argument. 

 

I'm vary big noob regarding how this stuff works. but wouldn't it be possible to have players announce to the server that it is 265 compatible in the same way I expect the clients to send other compatible video codecs and resolutions. And then have a server allow/disallow option and a setting that only uses it if the connection speed is a limiting factor and the client support it. otherwise it'll default to what ever it defaults to today. 

 

It still leaves the question regarding encoding performance demands. But I feel that this is up to the server administrators to decide upon in the same way they decide how hard to push the 264 encoder.

Edited by Karl Blixt
Link to comment
Share on other sites

VirgilFox

Having the ability to encode in HEVC/h265 for offline downloading would be great for those times that I'm on the road and bandwidth is limited.

Link to comment
Share on other sites

EraYaN

I'm now just trying to get it to respect the video codec url variable being 'h265' in the hls streaming url. And it all works just fine for libx265, but it's a little heavy on the CPU. QuickSync is just a lot more finnicky, and harder to test, for example my hardware will not take a CRF value (well it will take a fixed quantizer (q) value, but it's not quite the same), so the HEVC encoder in hardware needs AVBR/VBR or CBR settings on the settings page, requiring a change in the settings model.

And since I'm on a MacBook, I need remote (across the world) debugging, so it's slow going.

 

So when the EncodingHelper class is all patched up, putting other stuff to use the new codec should be "trivial" (heh). The only thing that has a fixed recording command line seems to be the LiveTV dvr functionality. And other code that actually calls the EncodingHelper is hard to find, even with text search, I know it does because changes are reflected but still, lots of dynamic action calling.

Also I'm surprised at the amount of exceptions during start up from a debug build.

Link to comment
Share on other sites

  • 6 months later...
Charlie117

I would also like to request HEVC transcoding. I only just noticed in my Transcoding panel that hardware accelerated HEVC is only available for decoding and not for encoding.

 

Nowadays plenty of clients are able to playback HEVC and there's also plenty of CPUs/GPUs that can do HEVC hardware accelerated encoding.

 

Maybe add it as an advanced option to avoid issues such as described by ebr. 

Edited by Charlie117
Link to comment
Share on other sites

Charlie117

To what app would you like to transcode to hevc?

 

Emby for Android TV on a Shield TV (or Emby for Kodi addon on a Shield TV).

 

If possible also to the iPad, so Emby for iOS as well. All recent iPhones and iPads should be able to decode HEVC, but I honestly don't know the specifics on that.

 

Also perhaps the Emby Web App? I believe the Edge browser natively supports HEVC and there's a plugin for Chrome browser.

 

 

Hardware accelerated transcoding will always come at a quality tradeoff compared to a slower software transcode, but switching hardware accelerated transcoding from H264 to HEVC should help a bit with quality. 

Edited by Charlie117
Link to comment
Share on other sites

Charlie117

And you have a powerful enough system for this?

 

Yes, but you don't really need a powerful system at all. Most recent CPUs and GPUs offer hardware accelerated HEVC encoding. Intel CPUs for example have had support for HEVC hardware accelerated encoding since Skylake. I don't have any specifics on AMD or Nvidia but both should offer it too on their somewhat recent hardware.

Link to comment
Share on other sites

Charlie117

Happy to help Luke. 

 

Please let me know if I can provide more info or help in any way with regards to HEVC.

 

VAAPI already supports HEVC hardware accelerated encoding so I could runs tests through FFmpeg on my Intel CPU/iGPU if that could be useful in any way. Additionally I also have an AMD 580 GPU that is also capable of HEVC hardware accelerated encoding that I could run tests on with FFmpeg.

 

I could also compile a list of devices that are capable of encoding and decoding HEVC to showcase how well supported it already is nowadays. Especially for hardware accelerated transcoding, I believe the time has come to retire H264 where possible.

Link to comment
Share on other sites

samuelqwe

I’d also like to see this. Although, it would have to be enabled only for clients that support it. Don’t want h265 on an older device that will have issues handling it, but for a new iPhone or Android TV device that supports h265, that would be awesome to have. Especially for remote access, as the stream will look better at the same bitrate.

  • Like 1
Link to comment
Share on other sites

I think the most likely scenario is that we'd start this with the offline download feature, as well as the media conversion feature. Then we'd use what we've learned to support it for on the fly transcoding as well.

  • Like 5
Link to comment
Share on other sites

KarlDag

I think the most likely scenario is that we'd start this with the offline download feature, as well as the media conversion feature. Then we'd use what we've learned to support it for on the fly transcoding as well.

Makes sense, and I would love that.

Link to comment
Share on other sites

  • 2 weeks later...
Charlie117

That would definitely be a great way to start with HEVC experimentation on Emby.

 

I'm guessing when using the conversion and offline download feature, there are checks being done similar to on the fly transcoding to check if the client hardware is capable of playing it?

Link to comment
Share on other sites

I think the most likely scenario is that we'd start this with the offline download feature, as well as the media conversion feature. Then we'd use what we've learned to support it for on the fly transcoding as well.

 

Luke, it would be great to start just with media conversion feature - as it should be easier. And for offline download this could be emulated with keeping original quality while selecting for download.

Looking forward to get it implemented.

 

Thanks.

Link to comment
Share on other sites

I'd like to see this for another reason as well as what's been expressed.  Right now if you have H.265 video but have an audio track that needs transcoding, then both get transcoded for HLS delivery.

  • Like 1
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
×
×
  • Create New...