Transcode in H265

[softworkz 3335]

3 minutes ago, ebr said:

This request was "give us the option to transcode to h265" but what is really desired is "improve quality and speed of media delivery in limited bandwidth environments".

Exactly. That aligns with the other point I mentioned above: we are nowhere like close to the edge of what's achievable with H.264.

Admittedly, we've been a bit retarded to care about that area over time. We have some fixed x264 parameters that haven't been revised for more than 5 years and the x264 transcodings are always way below the bandwidth at which it should be. And for HW encoders we have made some parameters accessible via UI, but never performed some deeper analysis.

So, when we would deserve to be beaten for something - then for this. Because there's quite some room for improvement.

[softworkz 3335]

On 10/29/2022 at 5:29 PM, ebr said:

what is really desired is "improve quality and speed of media delivery in limited bandwidth environments".

The other side of the story is that rarely anybody has been asking for this. In internal talks, that subject came up from time to time when it came to codec parameters and encoding quality and the conclusion was always like: well, there haven't been any complaints or requests in that area. So it kept getting postponed.

There have also been two or three occasions where a user asked for H.265 transcoding with a story about a certain problem case where H.265 would be needed. All these incidents proceeded and ended in a similar way: after I had given detailed instructions for what to try and which parameters to set for a sw or hw H.264 encoder, it was responded with interest and promise to try out those suggestions - but we never heard again from any of them.

You don't need to be a medium to recognize that this same pattern is driving some of the users here as well: they don't have a problem to solve or deal with - they just want that label on top "HEVC or H.265" and their described problems are only constructed to make a point and convince us on supporting that codec.

But there are also users who really have a problem or a situation that they would like to improve, and I want to invite all those users to a new conversation where we can explore and try out the uncovered range of possibilities that are available for streaming improvements with H.264.

I will post a link here within the next few days.

Best wishes,
softworkz

Edited October 30, 2022 by softworkz

[japtain_cack 6]

6 hours ago, cayars said:

It's not really the real-time transcoding that sets them apart as lots of people's servers never have to transcode much of anything (prepaired media), but it's the fact it's a full eco-system media setup.  It has both a multi-user streaming server as well as clients that basically run on all the popular devices. It has a clean TV and DVR built in that doesn't require wild kodi setups to use and it doesn't need shared or exposed storage.

Kodi for sure has die hard fans but a lot of people have switch to full blown media servers like Emby or to very simple GUIs like TiviMate and feed it content via m3u files which could point local or to streaming services.  This type of solution is very easy to keep synced or updated as you can have it pull the m3u file from a cloud provider.

Kodi has very little of this built in as it's just a media client that has a nice scripting environment available that people use to access info on other servers. Besides that, Kodi can get unruly trying to manage a large collection as it wasn't built to do that. 

Some people may be drawn to Emby for the transcoder so most media is playable on any device.  But just because they switched to have that feature doesn't mean they want to always have to use it.  You can learn to preprocess your media before adding it to Emby so it normally will never get transcoded. So that's one offline transcode/conversion vs every time the media is played. Maybe only preprocess what you know will be popular and played multiple time instead of creating a backlog. Or alternately files over X size (your largest) get processed first to save space.  What ever, works as there is the real-time transcoder available when needed. But keep in mind anything that can direct play and has been properly processed offline is going to have a lot lower latency during playback.

As far as the re-encode goes, I've been running HEVC for a few years and made it my default.  But I also created AAC default 2 channel tracks if not present to stop transcodes & remuxes from happening due to lack of audio support.  I also house cleaned the files by, stripping all audio and subtitles not in English as my family/friends have no use for this. I then exported subrips to external SRT if present and then finally converted the video stream to h.265 then created a new package for the movie in mkv format.  What I have now are tiny streams compared to the originals and 1/3 to 1/2 the size they would get transcoded by GPU to in real time even using h.265. They still look great on my 75" 85" and 110' TV.  The streams direct play basically all the time unless someone is on mobile with a local limit set.  I got big space savings from doing this.

 

JellyFin is pretty far behind Emby and Plex when it comes to transcoding.  Don't know how you think they are the clear winner.  They use much of our code as well as published Plex code whenever possible to make improvements but it's the slowest of the bunch especially for modern files that are 4K HDR.  On my 920+ Synology NAS for example I can't get a 4K HDR to 1080p SDR transcode from JF, can get 1 stream from Plex and 2 or 3 from Emby depending on the bitrate but there is clearly a difference. They are missing a lot of functionality and have issues to work out for things like subtitle.  Their transcoder still feels like a 4 year older version of Emby''s (which it was/is).  They add stuff but don't really understand how it interacts with other parts of the system.  They recently tried to add some h.265 code but had to revert it back out as they didn't realize it's not a drop in code.

 

While I do want to agree with you conceptually, like I said, I have emby and jellyfin running in tandem. Both me and my users have organically moved to the jellyfin apps because the quality is much better over the WAN. I could send you screenshots if that would help. 

I have both emby and jellyfin configured as close to the same as possible. So, it's either the HEVC transcoding, or jellyfin is just doing something different, but jellyfin plays just fine with a better looking picture.

You can give me all the science and theories in the world, but at the end of the day, a real world comparison tells me all I need to know.

Also, not sure why you're saying they pulled out their h265 code, I'm streaming a HEVC transcoded stream right now. 

Edited October 29, 2022 by japtain_cack

[softworkz 3335]

Now, here you go. Everybody with a true interest in the subject is welcome to apply:

 

[softworkz 3335]

A preliminary agenda has been added to the topic linked above.

I think this is a highly interesting and unique opportunity for everybody who is concerned about transcoding quality and bandwidth usage. 

Everybody here is welcome to apply!

Edited October 31, 2022 by softworkz

[mediaGuy 8]

On 10/29/2022 at 10:09 AM, softworkz said:

The one thing that this statement reveals is that you either haven't carefully read all of my posts or you didn't understand them or you are pretending the latter.
This is so boring. Now I have to clarify another time:

What I have explained is the current situation right now, in October 2022 - and that's all. Technology is evolving, standards are changing and new standard coming up. Industry adoption of standards is evolving as well and sometimes very quickly especially this subject is something that needs frequent re-evaluation.

I also want to spell it out once again for all those who are just begging for something that they could pretend to misunderstand:

There is no strategic avoidance towards H.265 at all. I didn't say no and I didn't say never. In fact there are planned projects related to H.265, which are making use of that codec within a defined and limited scope.

What I said in those posts above though, was about introducing HEVC transcoding as a general replacement to the H.264 streaming that Emby is doing. This is what this feature request is about and I have explained why this is not as easy as one would think.

Wow, and just like that I get treated like a child.  Sorry to bore you.

No one asked for a replacement, the original post is:
"I would like to have an option to choose H265 instead of H264 in the Transcode option."

It's understood that there are issues getting 100% device compliance.

I've been coding for 30 years and actually contributed some of the original WMC MB1 code.  I'm neither begging for something I misunderstand or not reading posts.

Anyways, this will be my last emby post, easy solution.

[Luke 37065]

37 minutes ago, mediaGuy said:

Wow, and just like that I get treated like a child.  Sorry to bore you.

No one asked for a replacement, the original post is:
"I would like to have an option to choose H265 instead of H264 in the Transcode option."

It's understood that there are issues getting 100% device compliance.

I've been coding for 30 years and actually contributed some of the original WMC MB1 code.  I'm neither begging for something I misunderstand or not reading posts.

Anyways, this will be my last emby post, easy solution.

Hi, I apologize for the mixup. His opinions on this feature are his own based on his experience and don't impact whether we'll end up doing this or his. Like everything else, it primarily comes down to what people want. There's enough users in here that I think it's inevitable that we'll end up doing this.

[softworkz 3335]

5 hours ago, mediaGuy said:

Wow, and just like that I get treated like a child.  Sorry to bore you.

I have taken so much time to explain the situation and at no point did I say that H.265 would never be supported.
Still you had responded:

On 10/29/2022 at 3:22 PM, mediaGuy said:

I understand there are complications, but @softworkz discussion in the last few days was really the first insight on the status of this feature request.  If the emby team doesn't want to include HEVC then just close the thread with a statement to avoid people waiting and guessing.

I'm sorry for my somewhat harsh reply, but this had really got me upset after all the effort to provide a truthful and detailed answer to the requests being made.

And when your takeaway from my responses is that "the emby team doesn't want to include HEVC", then I have to wonder whether you either haven't read, haven't understood or didn't want to understand what I said and  turned that misunderstanding into an effectful statement.

5 hours ago, mediaGuy said:

No one asked for a replacement, the original post is:
"I would like to have an option to choose H265 instead of H264 in the Transcode option."

Same thing again. This is had been clarified already:

On 10/29/2022 at 5:15 PM, softworkz said:

On 10/29/2022 at 5:10 PM, VirulentPip said:

"What I said in those posts above though, was about introducing HEVC transcoding as a general replacement to the H.264 streaming that Emby is doing. This is what this feature request is about and I have explained why this is not as easy as one would think."

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

Sorry to be that guy.. But the OP asked for it to be an option to choose H265.. Not to replace it 

I'm sorry for the misunderstanding!

What I meant by "general replacement" is not replacing it in a fixed/hard way. By replacement, I meant that it could be (optionally of course) used in-place-of and in the same way and with the same coverage of cases like H.264.

 

[trott90 20]

To be honest,  I really don't understand why Emby can support transcoding to H265/AV1 if hardware can support,   H265/AV1 comes for a reason and I do believe they delivery better quality with the same size than H264

[softworkz 3335]

25 minutes ago, trott90 said:

I really don't understand

If you want to understand, I'd kindly ask you to go a bit back in this conversation and read. 

[Carlo 4330]

On 11/2/2022 at 8:21 PM, trott90 said:

To be honest,  I really don't understand why Emby can support transcoding to H265/AV1 if hardware can support,   H265/AV1 comes for a reason and I do believe they delivery better quality with the same size than H264

It can sure.  In general, it can also add a lot more latency when done in real-time vs pre-production.  It can/will change the packaging needed by the clients and will need more stringent encodings to meet spec as well as most of the time require fMP4 chunked packets (fragmented MP4) which typically causes a loss of compression vs offline encoding and using progressive downloads.

This type of thing is covered throughout the thread.  The simple answer is that we can't just substitute an encode string creating HEVC vs AVC encodes. Up until about 1.5 or 2 years ago there wasn't even a spec for using streaming HEVC so its use was mostly progressive downloads or to specific devices you knew you could get away with using off spec packaging in HLS. Apple however added to the official spec for HLS recently introducing fMP4 as well as TS segments.  AVC can be used either way, but TS do not support HEVC and had to be handled via fragmented mp4 packets. Manufactures who were "loose" allowing incorrect packages have had to fix this to support Apples changes to the spec causing tumoil to vendors who were using packages out of spec and banking the chanes would favor them (nope).

Everyone quotes high compression savings of 40% but that's extreme and only with higher bit files. The difference between AVC and HEVC closes dramitically as bitrate and resolution drop.  HEVC separates itself from AVC at higher resolution, but the opposite is also true that AVC compression is closer to HEVC the lower the resolution. A 15% or so compression difference on 720 files surely isn't as compelling as 40% compression savings of 4K (if all else equals).

Up until last week the top browsers didn't support HEVC, the ones that worked were finicky, we had no standards in place specifying what was allowed and what wasn't. Mozilla/Firefox will likely never support HEVC while Apple, Google and Microsoft now all support it. Many used DASH instead of HLS to deliver HEVC since it's more a "Swiss Watch" container allowing more or less anything.  Problem is support for DASH is missing from the majors.  HLS vs DASH is not unlike the old media was that DVD and Blu-Ray went through with competitors to win out and take the market. The reality of the situation is that up until very recently this would likely have been a big mess undertaking it for our style of media streaming server that works in real-time.

Here's a short article that might be worth reading as it covers some of the reasons HEVC will likely be a transitional codec more so than a mainstream use codec for streaming servers doing transcoding. It's not technical so all should be able to understand. https://www.studiobinder.com/blog/hevc-codec-download/

That doesn't mean, we've done nothing with this request.  We can do HEVC transcoding and know how to package it properly but the changes needed to support fMP4 comes with it's own set of issues like additional latency which negate the benefit of compression gains.

We know from testing it requires a more powerful CPU then AVC even when used with a GPU.  We know HEVC can give increased compression due to how it's encoded but that encoding takes longer to do as well even on GPUs which raises latency and that's a killer for streaming. We already know from doing AVC transcoding that's we've had to reduce packet sizes to keep latency at a level that doesn't cause issues. We really can't afford to add this latency back as we've worked hard to reduce it.

HEVC has all kinds of licensing issues. It's certainly not "free to use" as everyone seems to think.

With so many hurdles using HEVC for real-time transcoding it's probably best to skip it looking at the next gen codecs being introduced to replace it that take into account HEVC's shortcomings.  The industry learned a lot of hard lessons with HEVC that have been addressed with the newer codec. Reading the requirements for next gen codecs reads like a list of pros and cons from HEVC as you want to do this plus 30% improvement but can't do this.

There are things we can do related to this request that could improve transcoding across the board. There are a good half dozen promising things I'm personally looking at that could improve latency as well as reduce bitrates currently being used on typical media. We can also look at implementing HEVC as a starting point for specific types of streams such as 4K where it could shine.  Clients that can handle 4K HDR could be targets starting out as they should have the muscle needed to handle this without causing additional issues. It would be a starting point, then 1080p on same clients and so on.  If some of the other things pan out and have the ability to lessen current latency, we gain a window of time back making it easier to introduce things like HEVC that we know will increase it.

Edited March 3, 2023 by cayars

[softworkz 3335]

22 minutes ago, cayars said:

but TS doesn't support HEVC and had to be handled via fragmented mp4 packets. Manufactures who were "loose" allowing it incorrectly sent had to righten up and fix this in order to support other changes as well.

MPEGTS does support HEVC and the HLS spec allows that as well. 

It's Apples own HLS requirements on top of the HLS spec which requires fmp4 for HLS streaming. And this has unfortunately lead to confusion so some support HEVC in MPEGTS for HLS streaming, but Apple and others have that fmp4 requirement. The outcome is that there's not a strong and reliable standard, but everywhere there are different caveats to consider, to handle and to work around. This has already been a tremendous effort for H.264, even though the standard for this is much stronger and long-term established.  Every one of the almost 25 Emby clients needs to know exactly what is can do and what it can't handle, and that in most cases, depending on the individual hardware a client is running on. There are so many subtle differences and caveats to consider to achieve a streaming and playback experience of type "always works". This has taken years to achieve in that quality and reliability and it would take time and effort to achieve the same with H.265 - everybody who is thinking that we're talking about a simple codec switch has no idea what it takes to bring things to that "always works" level of quality. "Fails sometimes" is just not something we want to deliver, and to overcome the gap from "fails sometimes" to "works always" a huge amount of effort is required.

[sydlexius 241]

@cayars, thanks for that post.  I wasn't up-to-speed on some of these developments.  Do you know if the fMP4 specification is encumbered in any way?

43 minutes ago, cayars said:

HEVC has all kinds of licensing issues as it's not "free to use" as everyone thought it was going to be thanks to a few patents already in place that were made known.

 

HEVC was in trouble early on, as patent pools and groups were already busy cross-licensing with each entity.  You don't have all these members of a working group going through the expense of getting hundreds of patents just to give away free (or even simple) licensure.  I have my doubts that AV1 will be problem-free in this regards as well.  The "fair licensing" scheme is basically a gentlemen's agreement; the pool of patents is in the thousands for this...if revenues don't meet expectations, this could easily factionalize.  This is disappointing, as AV1 is allegedly a successor to VP8 and VP9.  This is just another example of why we shouldn't tolerate patents on mathematical equations!

[archecon 11]

At the moment I have identified 2 areas.

1. Internet neutrality is deteriorating. There are countries where distribution of paid content takes up most of the bandwidth. A server on 1 GBit optics - works perfectly.. but on the client side the provider with optics frees up bandwidth to stream 4Mbit.. No it's not a joke... Social networks, commercially distributed video, TV etc. take priority... Especially tragic then is the connection via Single TCP.

2. Streaming. 4K and eventually 8K video are very transmission intensive.

I have previously posted posts on the topic of h265 support. I am now convinced that it is a format of the past.
Please let's look to the near future and support the development of more powerful codec implementations.. /AV1/.
Yesterday was the premiere of AMD's new cards, if the parameters of the new media blocks are true and if the software support SDK is not a disaster, the cards will be a powerful tool for realtime encoding to AV1.. PS of course Intel and Nvidia are not lagging behind in AV1 support.. but AMD has promised more performance..

This New HW will solve the server side support issues.
Since AV1 is used massively by youtube, on the client side I am not worried about support for this format. Consumer pressure for support on these end devices will be high.
Let's not look back, let's look forward.

Translated with www.DeepL.com/Translator (free version)

[softworkz 3335]

 

9 minutes ago, archecon said:

This New HW will solve the server side support issues.

I can assure you - it won't. 

8 minutes ago, archecon said:

Yesterday was the premiere of AMD's new cards, if the parameters of the new media blocks are true and if the software support SDK is not a disaster, the cards will be a powerful tool for realtime encoding to AV1.. PS of course Intel and Nvidia are not lagging behind in AV1 support.. but AMD has promised more performance..

AMD's promises are pointless at large. Integration of AMD HWA in ffmpeg is generally insufficient.

Please read my comments there: https://github.com/GPUOpen-LibrariesAndSDKs/AMF/issues/348#issuecomment-1239922856

Getting code into ffmpeg takes time, and even more time when elementary things are still missing.
AMD is miles behind Intel and Nvidia in terms of HW media acceleration and their presentation doesn't change that. A fast encoder isn't worth a single penny when you need to download (to CPU memory) and re-upload video frames for subtitle overlay or tone mapping - just as an example.

softworkz

[archecon 11]

1 hour ago, softworkz said:

 

I can assure you - it won't. 

AMD's promises are pointless at large. Integration of AMD HWA in ffmpeg is generally insufficient.

Please read my comments there: https://github.com/GPUOpen-LibrariesAndSDKs/AMF/issues/348#issuecomment-1239922856

Getting code into ffmpeg takes time, and even more time when elementary things are still missing.
AMD is miles behind Intel and Nvidia in terms of HW media acceleration and their presentation doesn't change that. A fast encoder isn't worth a single penny when you need to download (to CPU memory) and re-upload video frames for subtitle overlay or tone mapping - just as an example.

softworkz

I agree.. there is little hope that AMD's approach will change.  ,:-(,
What to do? troll AMD, trying to troll AMD in the public space so that perhaps they can't say.. that no one cares about this problem.?  I do...
Players are making informational HYPE, and other users' requests go unnoticed.

[softworkz 3335]

2 hours ago, archecon said:

I agree.. there is little hope that AMD's approach will change.  ,:-(,
What to do? troll AMD, trying to troll AMD in the public space so that perhaps they can't say.. that no one cares about this problem.?  I do...
Players are making informational HYPE, and other users' requests go unnoticed.

It's clear that hardware media acceleration is not a focus topic for AMD. What's unfortunate is that they make a presentation mentioning ffmpeg and everybody thinks that all of their hwa would be working fine with ffmpeg, even though not even the tiny part of AV1 encoding is working with it (yet). Just while we're talking (yesterday, today, tomorrow), a non-AMD guy is about to become maintainer for AMF in ffmpeg - because "somebody" is at least better than "nobody".

Looking at the larger picture, each of the "players" has its own focus areas. Intel is up to selling CPUs (until recently) that avoid the need for having separate GPU boards for hw media acceleration - which is a big selling point. Nvidia needs media hwa for their game stream features and for cloud computing use cases. AMD have slept on game streaming and later done just the minimum to fulfill the most common use cases. They've never been that strong in datacenter solutions either and were probably able to get along with their existing hwa capabilities, as middleware (ffmpeg, handbrake) integration is of lower importance for these (more targeted) cases.

Until there would be a clear change of strategy, AMD hardware will continue to be not recommended for use with Emby Server if hw acceleration is desired (otherwise fine of course).

But getting away from AMD and back to AV1 encoding - unfortunately this is still very far away:

• At this time, probably less than 0.1% of Emby users have hardware available that is capable to do AV1 encoding
• This week, a patchset has been posted for ffmpeg to enable AV1 encoding with hw acceleration; it was including a comment that the developer of the patch wasn't able to verify it's working, because he doesn't have any hw available that can do it.
• It can be taken for granted that AV1 encoding support will not be added to earlier hardware devices
• At the side of Intel, it's almost the same picture 

Bottom line is that we're many years away from a situation where AV1 encoding could become common functionality. The same things apply as for H.265. A widely adopted streaming protocol for AV1 is not in sight at the moment, software encoding is too slow and hw encoding is largely untested because most people can't test...

On the positive side: 

Everything needs to start somewhere and at some point. It was no different for H.264 when the first hwa implementations came.
Like then, it takes a while until it's ready for use by the masses and at the time when that happens, chances are good that there will be answers to the other questions (e.g. streaming protocol support) as well.

Edited November 5, 2022 by softworkz

[sydlexius 241]

13 hours ago, archecon said:

I agree.. there is little hope that AMD's approach will change.  ,:-(,
What to do? troll AMD, trying to troll AMD in the public space so that perhaps they can't say.. that no one cares about this problem.?  I do...
Players are making informational HYPE, and other users' requests go unnoticed.

We have influential PC gamers that will speak with their wallets (when they're not speaking for their sponsor).  For gamers that do gaming + encoding on the same box, they care about the maximum FPS/settings they can get away with.  For those with dedicated encoding boxes + capture cards, they might not care as much.

[ephemeraluser 0]

On 10/29/2022 at 1:46 PM, cayars said:

JellyFin is pretty far behind Emby and Plex when it comes to hardware transcoding.  Don't know how you think they are the clear winner.  They use much of our code as well as published Plex code whenever possible to make improvements

Are you simply parroting Softworkz or have you checked? You've both stated that Jellyfin's ffmpeg build is "80%" (Softworkz's number) copied from Plex and Emby. Do you have examples to back this claim?

You are right that Jellyfin has an old issue with subtitles being out of sync and slow to extract (but let's not forget that Emby 3.5.2 had this too). There's unarguably pros and cons for every media server flavor of ffmpeg (Plex has an excellent transcoding throttler), but throwing random accusations around just feels like a poor excuse for not having implemented X feature yourself.

Edited November 11, 2022 by ephemeraluser

[softworkz 3335]

12 hours ago, ephemeraluser said:

You've both stated that Jellyfin's ffmpeg build is "80%" (Softworkz's number) copied from Plex and Emby. Do you have examples to back this claim?

Yes I do, but first of all: a claim that involves a percentage cannot be backed by examples, that's just logically impossible. I've gone through all their changes and as I know both Plex' as well as Emby's customizations, it was rather easy to identify where the code from individual patches was coming from and which code was original.

Though, you won't see me going through or commenting their code publicly. That doesn't seem appropriate behavior. If somebody wants to challenge my statements, please contact me privately. But if you do, please include substantial reasoning and evidence.

I also don't want to condemn the fact that some things are being copied. ffmpeg is open source and especially in the earlier days, Emby had copied a number of things from Plex as well. Often these were even things that have been submitted to ffmpeg, but weren't picked up by ffmpeg. JF also have a number of own customizations, but it's a small number and by a magnitude less than what we have.

Finally, I really don't like talking bad about others. I rather focus on our own achievements. But at the same time, I cannot remain quiet when I see users telling fantasy stories about others that are so far off from reality like the post to which I had responded.

Edited November 11, 2022 by softworkz

[MagicDoubleM 93]

On 11/5/2022 at 9:22 AM, softworkz said:

But getting away from AMD and back to AV1 encoding - unfortunately this is still very far away:

• At this time, probably less than 0.1% of Emby users have hardware available that is capable to do AV1 encoding

On the positive side: 

Everything needs to start somewhere and at some point. It was no different for H.264 when the first hwa implementations came.
Like then, it takes a while until it's ready for use by the masses and at the time when that happens, chances are good that there will be answers to the other questions (e.g. streaming protocol support) as well.

Don't underestimate the interest in getting HWA if/when Emby introduces that feature-set.

Right now it's just not needed to think about getting a card into the server, but as soon as emby can do AV1, to, for example, generate higher quality low-bandwith-streams, or can target HDR-live-transcoding, including fancy stuff like DV5 to HDR10, this might change. 

All that being said, there are good reasons here for why it's not rushed into the code to just have an interesting name-drop in the changelog.

[runtimesandbox 152]

I have been away from this thread for quite sometime and am slowly going through all the discussion. 

My thoughts so far, on the point of browser support  : https://bitmovin.com/google-adds-hevc-support-chrome/ (Enabled and supported in builds of Chrome 104/105) 

@softworkz i totally understand your point that a lot of requests for this come out of a mis understanding of transocding settings, however the biggest use case I see is being able to make the most of limited upload bandwidth (residential connections on VDSL and equivalents)  / bandwidth costs.

I looking forward to getting involved in the focus group for improving H264 transcoding in the meantime.

[badous 12]

It's been a long time, are there any news?

[cptlores 23]

The more I read this thread, the less I feel like supporting Emby in the future.

As a professional software engineer I know well that technical challenges are almost irrelevant when it comes to costumers needs. But instead of trying your hardest to find an acceptable solution that makes your product better and give your product an competitive edge, you have instead spent time and energy trying to explain why you don't want to support it.

So years later instead of being a leader you are now behind with others already supporting the feature.

And all you needed to eliminate potential support issues, was to give h.265 transcoding the same options as you did with HDR tone mapping.

Edited March 3, 2023 by cptlores

[Carlo 4330]

We all would love to have HEVC transcoding, but it comes with it's own set of problems as explained.

However, that doesn't mean Emby doesn't support HEVC streaming because the very large majority of streams my server delivers are HEVC encoded.
You can pre-process your files offline to getting a much better compression ratio then you could ever get in real-time. If you include an AAC 2 channel stereo audio track as well the media file would never need to transcode because of audio. The same can be done with any subtitles, making sure you have compatible sub formats that won't require transcoding. Short of configured bandwidth restrictions at the server, user or client level the media will play back using HEVC on just about every device including newer browsers from Apple, Microsoft or Google.  Pre-encoding the media removes the transcoding complications of HEVC as well as gives you higher quality streams with bitrate savings compared to what you can get doing real-time transcoding (same for AVC).

Concerning AV1 support (accurate as of November 1)
100% Support including DRM:
Browsers & OS:
    Chrome, Edge, Android, Android TV, Fire TV
Consoles & Streaming Sticks:
    Amazon Fire TV Stick 4K Max

AV1 Suppor:
Browsers & OS: 
    Firefox, Windows
Consoles & Streaming Sticks:
    Playstation 4 Pro, Xbox One, Roku Streaming Stick 4K
Smart TVs:
    Android TV, Google TV, Samsung, Sony, LG, Amazon Fire TV

No AV1 support:
Browsers & OS: 
    Safari, IOS/macOS (AV1 plays in Chrome/Edge and Firefox on macOS)
    Safari

Roku Ultra supports adaptive streaming video via AV1 unofficially (tested with YouTube app)

We have AV1 hardware support on some GPUs already such as Nvidia 3000 and 4000 series GPUs.  Intel, AMD and Samsung have all commented additional AV1 support is coming at the chip level.
Google has already been requiring AV1 support or new Android TV and Google TV devices. Google's newer Chromecasts support AV1 decode support.
Industry AV1 support and adoption has been on the rise and gaing momentum quickly. Not that long ago, it took millions of views to offset the higher encoding costs of AV1, but with recent improvements, the break-even point has dropped to as low as 4,000 views! 

Edited March 4, 2023 by cayars