In-Progress Transcode in H265

[geekymovielord 2]

On 8/2/2017 at 10:54 PM, Luke said:

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.

Are there news on this topic? Has this been implemented? That would be sick because most new GPUs support transcoding to H265 without any issues and it could save a lot of bandwidth.

[Gecko 71]

On 11/8/2024 at 4:10 PM, geekymovielord said:

Are there news on this topic? Has this been implemented? That would be sick because most new GPUs support transcoding to H265 without any issues and it could save a lot of bandwidth.

I could share what I did to activate it but it’s only usable on Linux with vaapi (kind of working with quicksync too except for some rare cases where the colors are wrong)

[PetesEmbyServer 16]

This is being tested with one of the other major media servers (not jelly) and its pretty sick. They are doing 10 bit h.265 so it retains HDR. I really hope this gets added to emby at some point.
I have transcoded full bit rate UHD files down to 8 mbits (on the fly) and it looks pretty darn good. I guess it depends on what your server has for hardware....

I have family with rural internet so anything along these lines is helpful.

AV1 would be even better.

 

[yocker 155]

Okay i've changed my opinion after having played more with it.

h265 transcoding is sorely needed!

Edited December 31, 2024 by yocker

[bandit8623 116]

https://forums.plex.tv/t/hevc-encoding-forum-preview/888127/731

[SikSlayer 240]

Over 7 and a half years...

My 12700K can do this via the iGPU. There's cheap N100 machines now with the same iGPU. N305 machines that trade with my old 4th Gen i7 4771 that I ran Emby on for 9 years.

The hardware to decode HEVC is everywhere. My old Note 9 phone for example. It's common.

Look, I get it, and I used to be VERY curt about this stuff. However, I stopped because even though I can't program my way out of a paper bag (I have a stack of books to prove it) I've been involved in various software communities, from emulation, indie game development, so I always understood the difficulties developers face. But it's nearly 8 years since this thread started...

Luke, I'd be ANGRY if Plex wasn't only just now getting this.

[Max076 3]

On 14/11/2024 at 20:01, Gecko said:

I could share what I did to activate it but it’s only usable on Linux with vaapi (kind of working with quicksync too except for some rare cases where the colors are wrong)

It'd be nice if you could!

 

Like others on this post, it'd be nice if this feature got implemented. Specifically 4k content would benefit a lot from having more modern codecs to encode it with!

[Gecko 71]

On 1/23/2025 at 3:20 PM, Max076 said:

It'd be nice if you could!

 

Like others on this post, it'd be nice if this feature got implemented. Specifically 4k content would benefit a lot from having more modern codecs to encode it with!

Hi there,

Here it is but it requires some manual manipulation.

 

FFMPEG-HEVC

Pre-requisites:

• Linux host only (tested on ubuntu)
• install the Diagnostic Plugin from the Plugin Catalog
• deactivate tone-mapping completely
• ensure that only VAAPI is selected in your hardware decoders & encoders
• retrieve the Emby-server installation path (default: /opt/emby-server). You can find this information in the original ffmpeg file from emby by executing this command anywhere in your CLI :

• find / -type f -iname "emby-ffmpeg" 2>/dev/null -exec cat {} ";" | grep "APP_DIR="

Installation

1. if needed, adapt the line #3 of the script by specifying the base installation path of your emby-server :
   APP_DIR=/opt/emby-server
    
2. Copy the ffmpeg-hevc script into a location emby can reach, the default /opt/emby-server/bin/ for example is a good spot

 

Activation

1. Open the Diagnostic Plugin and navigate to the second tab "FFMPEG Options". 
2. Paste the full ffmpeg-hevc path into the "Custom ffmpeg path"
   
3. Click save

 

You're are good to go. Any stream requiring hardware transcoding will now be in hevc instead of h264. Nothing in the UI is updated though, so the Nerd Tool will still show h264 as the target codec. The only way to confirm this is working is by looking inside the ffmpeg-transcode logs. You should see something like this, followed by the new ffmpeg command that's executed by emby. 

-------------------------------------
------ Activating HEVC encoder ------
-------------------------------------
Log file is : /var/lib/emby/logs/ffmpeg-transcode-580e8dc8-721d-4e1b-a65f-d40b15c62d1c_1.txt
AVC encoder found : h264_vaapi

Performing some FFMPEG args changes ...
  MODIFIED  >>  -c:v:0 h264_vaapi -> -c:v:0 hevc_vaapi
  MODIFIED  >>  -bufsize:v:0 7616004 -> -bufsize:v:0 3808002
  MODIFIED  >>  -max_delay 5000000 -> -max_delay 500000
  MODIFIED  >>  -max_delay 5000000 -> -max_delay 500000
  MODIFIED  >>  -max_delay 5000000 -> -max_delay 500000

 

Notes

• The script will modify the ffmpeg call to hevc only if a valid h264 hardware encoder has been found in the original call.
• The direct stream and direct play are not affected
• QuickSync is compatible with the script but the colors are not accurate for some HDR content. That's why I recommend to use VAAPI only.
• You can adapt a little bit the ffmpeg-hevc script like so:
  • BITRATE_MOD="*1"  : forbid ffmpeg to go higher than the specified bitrate (by default, the bitrate_mod is x2 for h264).

    Uncomment LINE #60 if you want to check that the client is HEVC_COMPATIBLE. By default, this is deactivated as I don't need it myself.

 

Have fun

ffmpeg-hevc

[yocker 155]

Just for the fun of it, have fed an AI with all kinds of stuff about this and told it to make a plugin for Emby to make H265 possible..

Estimated Completion: 8-13 weeks (around April-May 2025)

 

[yocker 155]

I just asked the AI to make it for fun not expecting anything useful but.. This actually looks promising.

H265 transcoding with h264 fallback for devices that don't support H265.
Intel Quicksync, Vaapi and nvenc support.
Working user quality settings.

Been working a little with it as well, estimated work time 3 weeks.

When asked it says most already runs and it's fine tuning now, first test build should be ready in 7-8 days. While i don't expect much it will still be interesting to see what it will attempt to do.

Edited February 4 by yocker

[yocker 155]

On 2/4/2025 at 7:58 PM, yocker said:

I just asked the AI to make it for fun not expecting anything useful but.. This actually looks promising.

H265 transcoding with h264 fallback for devices that don't support H265.
Intel Quicksync, Vaapi and nvenc support.
Working user quality settings.

Been working a little with it as well, estimated work time 3 weeks.

When asked it says most already runs and it's fine tuning now, first test build should be ready in 7-8 days. While i don't expect much it will still be interesting to see what it will attempt to do.

So.. I actually got to test it and.. I think it would work if only it knew what APIs or reference names to use. As Emby is closed source i think it might be a dead end.
My programming skills are way to small to fix that as they barely go over the "hello world".

Other solutions that actually seem to contact Emby just gets it's commands overwritten.

I sadly can't test the script Gecko made as i can't get VAAPI to work on my test machine for some reason, shame because it could have potential to actually work with H264 fallback and all.

If H265 is really important a proxy could be made but would be a hassle to maintain and not a pretty solution.

@softworkzor any one else from the dev team.
This might be a tall ask but, would it be possible for some small start of.. Something.. That people can build upon and mess with for personal use?
That way it would be "use at your own risk" and not something you have to maintain until you have a stable workable solution.

[softworkz 4488]

12 minutes ago, yocker said:

So.. I actually got to test it and.. I think it would work if only it knew what APIs or reference names to use. As Emby is closed source

All APIs are documented in detail:

https://dev.emby.media/reference/pluginapi/Emby.Features.FeatureInfo.html

https://dev.emby.media/reference/RestAPI.html

 

13 minutes ago, yocker said:

@softworkzor any one else from the dev team.
This might be a tall ask but, would it be possible for some small start of.. Something.. That people can build upon and mess with for personal use?
That way it would be "use at your own risk" and not something you have to maintain until you have a stable workable solution.

Our aim is to provide quality software that is working reliably.

Think you would be on our side: would you really do something which would cause the forums (Server + All Apps) becoming flooded with reports about all the ways and cases in which it doesn't work?

A "use at your own risk" label would be quickly forgotten and what remains is the story: Emby is not properly working, has playback issues, works unreliable, etc etc.

There's no value for anybody in providing something that doesn't work properly.

[yocker 155]

2 hours ago, softworkz said:

All APIs are documented in detail:

https://dev.emby.media/reference/pluginapi/Emby.Features.FeatureInfo.html

https://dev.emby.media/reference/RestAPI.html

 

Our aim is to provide quality software that is working reliably.

Think you would be on our side: would you really do something which would cause the forums (Server + All Apps) becoming flooded with reports about all the ways and cases in which it doesn't work?

A "use at your own risk" label would be quickly forgotten and what remains is the story: Emby is not properly working, has playback issues, works unreliable, etc etc.

There's no value for anybody in providing something that doesn't work properly.

Yeah i just couldn't with my shitty programming skills find what i needed so i concluded that what i was looking for was closed off.
Still very, very much at the learning stage and thought this might be good for learning.

I sort of agree and then again not. Others handle something like that fine.
"Project is as is and meant for self tinkerers, no support will be given." and then maybe a subforum where people can talk about it, maybe just a link to a reddit page so you can forget about it. Lot of people love to tinker with stuff. 

Fair enough though, it is your reputation and product on the line so i can understand. It was worth a try, you get nothing without asking!

 

[Gecko 71]

8 hours ago, yocker said:

I sadly can't test the script Gecko made as i can't get VAAPI to work on my test machine for some reason, shame because it could have potential to actually work with H264 fallback and all.

What encoder do you use then ?

[yocker 155]

2 hours ago, Gecko said:

What encoder do you use then ?

Quicksync. Real trouble most likely lies in it being an Arc card and being finicky as hell. Tone mapping is already <censored> to get to work with it.
I can get Emby to do what it should but just not the car, no matter what tinkering i do to the script.

Great work with it btw.

Edited February 10 by yocker

[Gecko 71]

1 hour ago, yocker said:

Quicksync. Real trouble most likely lies in it being an Arc card and being finicky as hell. Tone mapping is already <censored> to get to work with it.
I can get Emby to do what it should but just not the car, no matter what tinkering i do to the script.

Great work with it btw.

You can pm me your ffmpeg-transcode logs, I can take some time to look into it if you want. On my igpu, quick sync was working. Don't know if there's something different with an Arc GPU, I don't own one ; from my understanding, this should be exactly the same.

[yocker 155]

2 hours ago, Gecko said:

You can pm me your ffmpeg-transcode logs, I can take some time to look into it if you want. On my igpu, quick sync was working. Don't know if there's something different with an Arc GPU, I don't own one ; from my understanding, this should be exactly the same.

Will do, i have the evening to my self later so will look into it there.
Right now you might not recognize the script as i've had to change it to work in docker on Unraid, i can go back to do it in Ubuntu if you want, will require a reinstall but no problem, just want to know in advance.    

Edited February 10 by yocker

[yocker 155]

6 hours ago, Gecko said:

You can pm me your ffmpeg-transcode logs, I can take some time to look into it if you want. On my igpu, quick sync was working. Don't know if there's something different with an Arc GPU, I don't own one ; from my understanding, this should be exactly the same.

For simplicity sake i threw back in Ubuntu and tried again.
I sooooort of got it working, it works in the Emby app on Windows and on my Phone, it also works on ONE Firefox browser.
Edge and Chrome just get "no compatible stream"

Looks to be everything with HDR causing problems.

 

ffmpeg-transcode-e50c08fc-91af-4189-8187-ee4976c6b9be_1.txt

Edited February 10 by yocker

[yocker 155]

So i've googled, learned a bit of coding (mostly thanks to AI ) and i've come up with something that sort of works..

It's works in some browsers. even says in stats for nerds that it's transcoding to hevc but... It doesn't transcode to hevc in the Emby apps.
Maybe some guru in here can fix that, i'm to tired for today and have stuff to do the next days.

Find the same name file in your Emby install and replace it with this one.
Remember to backup or even better.. USE A TEST INSTALL OF EMBY!!!

It should work with all graphics  cards if i haven't sent the wrong file.

browserdeviceprofile.js

[Luke 39618]

3 hours ago, yocker said:

So i've googled, learned a bit of coding (mostly thanks to AI ) and i've come up with something that sort of works..

It's works in some browsers. even says in stats for nerds that it's transcoding to hevc but... It doesn't transcode to hevc in the Emby apps.
Maybe some guru in here can fix that, i'm to tired for today and have stuff to do the next days.

Find the same name file in your Emby install and replace it with this one.
Remember to backup or even better.. USE A TEST INSTALL OF EMBY!!!

It should work with all graphics  cards if i haven't sent the wrong file.

browserdeviceprofile.js 2.89 kB · 0 downloads

I'd be curious to know how this goes. You will likely see better results with this on the beta server.

[yocker 155]

29 minutes ago, Luke said:

I'd be curious to know how this goes. You will likely see better results with this on the beta server.

Yeah maybe, just working with what i had installed plus i suck at this (total beginner). I'll look into using beta server later.

Right now i'm looking for where you keep the device profiles like with the browsers though.

[yocker 155]

Just noticed it was the wrong file i sent in here..
Added the right one.

I also have a semi functional working solution for apps, requires a bit more work though as it requires a different approach.

Can't seem to get HDR passthrough to work, suspect Emby overwriting it somewhere so Tonemapping needed for now.
Though i might get it to work for the apps as well.

Anyway, use at your own risk, i recommend using a test server and blablabla..

browserdeviceprofile.js

Edited February 21 by yocker

[Luke 39618]