In-Progress Transcode in H265

[Sshanee 3]

32 minutes ago, hoonlight said:

Eventually, plex is now starting to support HEVC encoding. I think it's pretty nice that it doesn't require a separate tone mapping.
https://forums.plex.tv/t/hevc-encoding-forum-preview/888127

For external playback of my personal Blu-ray Remix files, transcoding them to H265 has a number of benefits. After reading through this post, it doesn't look like the Emby team will be supporting this in the near future. I understand that, but it's a bit of a bummer. I'll have to wait for the Plex Lifetime Pass sale.

Way she goes. 2 of the 3 main options are doing it and we have been begging emby to support it and now it comes down to moving on to better software. What a shame I chose to purchase a lifetime license from the wrong company... they had such potential.

[hoonlight 17]

Still, for me, Emby is pretty great. 
Even if I get Plex, I'll still use Emby for home streaming.

[Jdiesel 1333]

8 hours ago, hoonlight said:

Eventually, plex is now starting to support HEVC encoding. I think it's pretty nice that it doesn't require a separate tone mapping.
https://forums.plex.tv/t/hevc-encoding-forum-preview/888127

For external playback of my personal Blu-ray Remix files, transcoding them to H265 has a number of benefits. After reading through this post, it doesn't look like the Emby team will be supporting this in the near future. I understand that, but it's a bit of a bummer. I'll have to wait for the Plex Lifetime Pass sale.

You don't have to wait, there is right now

[xyzeratul 2]

On 18/09/2024 at 16:00, Sshanee said:

Way she goes. 2 of the 3 main options are doing it and we have been begging emby to support it and now it comes down to moving on to better software. What a shame I chose to purchase a lifetime license from the wrong company... they had such potential.

Yea I agree, I feel Emby team missed too much in recent years, I chosed Emby because more freedom and function than Plex, now Plex is catching up and Emby is just stay more or less the same, so I'm already switching to Plex 

[yocker 314]

I get the complaints about the Emby team not being the fastest in the world with new features but i don't get how H265 encoding would be an end all be all feature.
Certainly not enough of a problem to go over to Plex for and have your movie list mixed with movies from Plex streaming service and user data sold.

For the sake of your own sanity, if you really, really, REALLY want to move to another media server software there are other than Plex!
Though none with the device support of Emby.

[Gecko 71]

Yet, the experimental encoding in Plex and the stable one in jellyfin are working pretty well. Too bad Emby devs did not find this was a major feature to develop; given the fact that the basic bricks were already there (for conversion).

For sure, the actual x264 encoding is doing fine but that forces us to tone map our 4K materials. The colour difference between Plex and Emby is striking!

[ebr 15681]

12 hours ago, Gecko said:

the actual x264 encoding is doing fine but that forces us to tone map our 4K materials.

How would transcoding to a different codec negate the need for tone-mapping HDR material?

[Gecko 71]

3 hours ago, ebr said:

How would transcoding to a different codec negate the need for tone-mapping HDR material?

Do you require tone mapping when transcoding from h265 to x265 ?

[softworkz 4574]

12 minutes ago, Gecko said:

Do you require tone mapping when transcoding from h265 to x265 ?

Yes - unless the client can do tone mapping itself or has an HDR display path.

[Gecko 71]

So then plex annoucements are too good to be true ?

Yet, as I was saying, the colors I see are more vivid when transcoding using plex and Jellyfin than Emby and so the output is more appealing to me. All my devices are HDR Compliant so that’s a big +1 when I watch stuff away from home.

Again, too bad Emby was not the first or second to embrace this feature.

 

I also noticed that the pgs subs are clearer and more defined on plex than Emby. Surely they are processed differently and they seem to not be scaled down as with Emby. There’s room for improvement here also.

 

[softworkz 4574]

2 minutes ago, Gecko said:

I also noticed that the pgs subs are clearer and more defined on plex than Emby. Surely they are processed differently and they seem to not be scaled down as with Emby. There’s room for improvement here also.

We have an exclusive feature which reliably(!) converts those subs into text, keeping colors, position and formatting, which allows perfect rendering and manipulation, also can eliminate the need for burn-in. It's ready since 2 years, but for inexpicable reasons it didn't get into beta...

[Sshanee 3]

Well the ball was dropped with this feature but it's not too late to start working on av1 stream transcoding

[Gecko 71]

2 hours ago, softworkz said:

We have an exclusive feature which reliably(!) converts those subs into text, keeping colors, position and formatting, which allows perfect rendering and manipulation, also can eliminate the need for burn-in. It's ready since 2 years, but for inexpicable reasons it didn't get into beta...

Yeah we already discussed about that feature together. I'm sure there are good reasons we don't know to do so. But, as an end user, it's a pity we can't even test such a nice feature while in the mean time, the stable emby release only propose blurred subtitles when transcoding to low bitrate (compared to the competitors).

Anyway, Emby is really good on others topics (the transcoding speed when seeking back and forth for example) and I love it, so it still my first choice when streaming away from home but the gap is narrowing.

[softworkz 4574]

13 minutes ago, Gecko said:

But, as an end user, it's a pity we can't even test such a nice feature while in the mean time, the stable emby release only propose blurred subtitles when transcoding to low bitrate (compared to the competitors).

Yes, that's exremely unfortunate, everything had been ready, including videos (Emby Show) to accompany the beta introduction, but at this time, the window is closed.

On the good side though: the Windows/Xbox client beta is progressing well, and if we'd get to resume the TVnext path afterwards - like officially promised - then it would be good news regarding H.265 as well. Like I had mentioned earlier in this topic, H.265 streaming via HLS is also a topic in the context of TVnext. Not with transcoding, but as mentioned earlier, TVnext is also meant to serve as a new foundation for HLS streaming in general, and I've just seen that Apple has opened up (a little) towards AV1 in their HLS authoring spec, so that's good news as well, confirming HLS as a viable path, going forward.

[Gecko 71]

@softworkzIs there a way to replace multiple different texts in the diagnostic plugin search/replace text boxes? I would like to try some alteration to the arguments passed to ffmpeg.

[softworkz 4574]

Unfortunately no. This was only made to try out an alteration for a specific case, so the only thing you can do is to use a single string which includes both parts that you want to change and a replacement string which includes both changes.

[Gecko 71]

Thank you for your reply, that's what I thought. I created a proxy-file instead of using the diagnostic plugin in order to modify any given parameters before they are passed to ffmpeg.

Doing so, I was able to activate relatively easily the hevc transcoding in Emby 
There should be some input materials that won't work with it since I don't have access to the underlying logic generating those parameters in the first place (and given the fact that I worked on it only a few hours).
It's only working on a linux host and with vaapi as the encoder.

Furthermore, the x264 encoding is completely replaced by this new hevc encoding. Maybe I could add some logic myself to only convert hevc -> hevc.

Anyway, this was fun to do and seems promising if any time soon the emby devs wants to activate this functionnality.
It's still possible to catch jellyfin and plex !

h264_4mbps.ts hevc_4mbps.ts

Edited October 23, 2024 by Gecko
adding segments to illustrate the difference

[softworkz 4574]

Please see my message(s) a little further above where I said (once or twice) that it won't take more than a day to get "something" working for a test scenario. So, that's not a surprise in any way.

[Gecko 71]

11 hours ago, softworkz said:

Please see my message(s) a little further above where I said (once or twice) that it won't take more than a day to get "something" working for a test scenario. So, that's not a surprise in any way.

I won't argue with you but fyi it's not the perceived message I got. I rather understood that it will still be a long way before we get anything regarding hevc transcoding since it's not a priority feature (even if you confirmed that it's an easy task after all) and that even if you work on it, it may not hit a public release like your subtitle manipulation feature. I'll continue working on my own solution as this is a simple and promising work-around (that could even be proposed as an extension if I knew how to build one) and I hope to see some official hevc transcoding hit the shelves soon enough.

[softworkz 4574]

You didn't read the messages I was referring to. I'm absolutely NOT saying that it's an easy task.

What you did is easy, though.

But this is something totally different from rolling out a feature that is expected to work always and everywhere and for everybody. Reliably, without hiccups and glitches on all clients and with all kinds of source material, etc etc.

[softworkz 4574]

11 minutes ago, softworkz said:

You didn't read the messages I was referring t

So, here again:

On 10/28/2022 at 1:34 AM, softworkz said:

...there's the second big mis-assumption: That we would just need to "switch it on" with with a tiny bit of development and that it would work in the same way as H.264 then. And some bad voices would add that we would be ignorant towards user requests and instead of fulfilling, we would just be trying to find excuses.

So I'll try to explain the situation once again (I did before, also in this topic somewhere above) - this time letting any technical details aside, just focusing on how this would proceed - roughly:

• Within 1-3 days we could have an example case working: with a specific source file, a specific hardware, specific hwa, a specific transcoding configuration, and a specific client  and client settings
• After a few weeks, we might have this working in like 15-30% of cases
• After several months, we could have approached 40-50%
• And after a year maybe 60 or 70%
• The point is: the closer it gets to 100%, the harder and slower will it become to approach it

It is important to understand in this context, that 80% or 90% still means that it cannot be shipped/released. Nobody will accept a situation where playback fails in one out of five cases. It has taken years to get to the point where we are now, where Emby can play whatever you feed it on whatever device in something like between 99.9 and 99.99% percent of cases.

On 10/29/2022 at 4:03 AM, softworkz said:

On 10/29/2022 at 3:30 AM, japtain_cack said:

Well, I can transcode in HEVC with jellyfin, can't with emby/plex,

I had tried to explain this a few posts above. Getting HEVC transcoding "somewhat working" is not a big deal and achieving coverage of that functionality for something like 50-80% of  cases could be achieved with moderate effort.

They can do this. It's free and developers are volunteers - nobody can blame them for anything not fully working.

But when WE do that, users have much higher expectations and we for ourselves, have a different set of standards under which new features are being released. Our users can expect that we are releasing features which are fully working. In that post above, I had tried to explain that the really hard part in this case are not those 0-80% but the last 20% until it would be working in the same perfect and reliable way like it is working now with H264.

After all: Why are users coming here and telling what others can do instead of happily using theirs?
I think in most cases, it's because they have these higher expectations that others just can't fulfill.

 

That's been two years ago. Things have progressed, even Chrome is supporting HEVC via hw accel, even though they said before they'll never support it, so I would have different estimations for the figures given then in 2022. But the points made haven't changed. The plan for getting into HEVC/HLS streaming in the context of TVnext still stands as well, just badly delayed.

[Gecko 71]

Thanks, I didn't read your messages before 2023.

[hjason7812 33]

On 8/2/2017 at 3:39 PM, sebasmiles said:

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.

i have all my media encoded into h265 since 2016 and everything works great and all i have is a cpu in my server the cpu is a gaming cpu the amd 9370 fx and no gou just the onboard gpu with the mobo

[hjason7812 33]

On 10/24/2024 at 3:26 AM, Gecko said:

I won't argue with you but fyi it's not the perceived message I got. I rather understood that it will still be a long way before we get anything regarding hevc transcoding since it's not a priority feature (even if you confirmed that it's an easy task after all) and that even if you work on it, it may not hit a public release like your subtitle manipulation feature. I'll continue working on my own solution as this is a simple and promising work-around (that could even be proposed as an extension if I knew how to build one) and I hope to see some official hevc transcoding hit the shelves soon enough.

you do realize it has been on the server for a long time right? it is in the transcoding section all you have to do is set it up if you wanna use it... see attached screeny for reference

[Gecko 71]

4 hours ago, hjason7812 said:

you do realize it has been on the server for a long time right? it is in the transcoding section all you have to do is set it up if you wanna use it... see attached screeny for reference

Not for transcoding it’s only used for conversion