In-Progress Transcode in H265

[syadnom 25]

first, I don't think anyway is suggesting disabling h.264 support so web browser access shouldn't be affected.

 

second, zero percent of my users are using a browser.  It's all apps or TVs.  All devices that fully support h.265 and some that do AV1 as well.   I think this is the most typically use case.

Right now, emby streams are far inferior to the likes of Netflix and Youtube etc.  We are basically a decade behind in streaming tech and the mobile/remote user experience suffers as a result.   This makes Emby essentially an in-home platform for my family because it really drags streaming it out.  I have symetrical 1G fiber btw.  Mobile networks are my issue and having double the bandwidth requirements for mobile is the strain.
 

[nayr 36]

1 hour ago, visproduction said:

The question is why develop code that helps possibly less than 1% of desktop users

The real question is why do they even support desktops at all since they are less than 1% of playback devices, yet refuse to implement HEVC when its supported by the vast majority of the hardware Emby clients are running on? 

Emby has a shit ton of features used by a small minority, who here is using LDAP Auth? anyone? This argument holds no water.. Especially considering all the plumbing is there already, its not like they are waiting on upstream support in FFMPEG or anything... Every Emby Client on every modern TV is capable of playing HEVC files.. we just want on the fly transcoding using hardware we've had in our systems for years now.

I was able to get 2GbE Fiber Internet in the years since I asked Emby to add this.. If the Internet Provider industry moves faster than a software company then you are doing something wrong.. 

Edited October 23, 2022 by nayr

[Happy2Play 9446]

4 hours ago, EricGRIT09 said:

I’d imagine the majority of playbacks across all Emby users are not in browser on desktop, but that’s just my guess.

But from a free perspective the usage is quite high.

[KarlDag 25]

7 hours ago, nayr said:

The real question is why do they even support desktops at all since they are less than 1% of playback devices, yet refuse to implement HEVC when its supported by the vast majority of the hardware Emby clients are running on? 

Emby has a shit ton of features used by a small minority, who here is using LDAP Auth? anyone? This argument holds no water.. Especially considering all the plumbing is there already, its not like they are waiting on upstream support in FFMPEG or anything... Every Emby Client on every modern TV is capable of playing HEVC files.. we just want on the fly transcoding using hardware we've had in our systems for years now.

I was able to get 2GbE Fiber Internet in the years since I asked Emby to add this.. If the Internet Provider industry moves faster than a software company then you are doing something wrong.. 

God damn son, haven’t read truth like that in a long time. 150% truth right there. I’m on a 500Mbps symmetrical connection too so don’t have the need as much as I used to, but mobile data caps are still ridiculously low

[Carlo 4552]

9 hours ago, Happy2Play said:

But from a free perspective the usage is quite high.

A lot of servers I do remote work on are mostly accessed by browsers

[Carlo 4552]

12 hours ago, syadnom said:

second, zero percent of my users are using a browser.  It's all apps or TVs.  All devices that fully support h.265 and some that do AV1 as well.   I think this is the most typically use case.

Right now, emby streams are far inferior to the likes of Netflix and Youtube etc.  We are basically a decade behind in streaming tech and the mobile/remote user experience suffers as a result.   This makes Emby essentially an in-home platform for my family because it really drags streaming it out.  I have symetrical 1G fiber btw.  Mobile networks are my issue and having double the bandwidth requirements for mobile is the strain.
 

Actually, you have it backwards. Emby streams are much more complex streams to deliver than Netflix or others streaming services use.   Netflix uses only prepared media so it's mainly working as a login/security system and web browser.  Netflix delivery media from the edge of the network not from a central location.  They create what's called a bitrate ladder. What this means is that the Netflix do very little work.  They have multiple versions of each piece of media created in different formats and codecs.  As an example, they might encode a simple video at the following profiles:
1080p 5.0 mbps
720p 4.0 mbps
640p 3.2 mbps
480p 2.0 mbps
270p 1 mbps

They could do 5 like this for AVC, 5 for HEVC and 5 for VP9 or AV1. They will do something similar for audio.  Storage is so much cheaper than CPU/GPU resources they would have to use otherwise. These different feeds are all passed by way of the manifest files which may look like this:

#EXTM3U
#EXT-X-VERSION:4
#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="audio",NAME="aac_UND_6_384",DEFAULT=YES,URI="QualityLevels(384000)/Manifest(aac_UND_6_384,format=m3u8-aapl)"
#EXT-X-STREAM-INF:BANDWIDTH=1355199,RESOLUTION=640x360,CODECS="avc1.64001e,mp4a.40.2",AUDIO="audio"
QualityLevels(926058)/Manifest(video,format=m3u8-aapl)
#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=1355199,RESOLUTION=640x360,CODECS="avc1.64001e",URI="QualityLevels(926058)/Manifest(video,format=m3u8-aapl,type=keyframes)"
#EXT-X-STREAM-INF:BANDWIDTH=2532741,RESOLUTION=960x540,CODECS="avc1.64001f,mp4a.40.2",AUDIO="audio"
QualityLevels(2078252)/Manifest(video,format=m3u8-aapl)
#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=2532741,RESOLUTION=960x540,CODECS="avc1.64001f",URI="QualityLevels(2078252)/Manifest(video,format=m3u8-aapl,type=keyframes)"
#EXT-X-STREAM-INF:BANDWIDTH=3617004,RESOLUTION=1280x720,CODECS="avc1.64001f,mp4a.40.2",AUDIO="audio"
QualityLevels(3139175)/Manifest(video,format=m3u8-aapl)
#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=3617004,RESOLUTION=1280x720,CODECS="avc1.64001f",URI="QualityLevels(3139175)/Manifest(video,format=m3u8-aapl,type=keyframes)"
#EXT-X-STREAM-INF:BANDWIDTH=4843919,RESOLUTION=1920x1080,CODECS="avc1.640028,mp4a.40.2",AUDIO="audio"
QualityLevels(4339679)/Manifest(video,format=m3u8-aapl)
#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=4843919,RESOLUTION=1920x1080,CODECS="avc1.640028",URI="QualityLevels(4339679)/Manifest(video,format=m3u8-aapl,type=keyframes)"
#EXT-X-STREAM-INF:BANDWIDTH=6086786,RESOLUTION=1920x1080,CODECS="avc1.640028,mp4a.40.2",AUDIO="audio"
QualityLevels(5555791)/Manifest(video,format=m3u8-aapl)
#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=6086786,RESOLUTION=1920x1080,CODECS="avc1.640028",URI="QualityLevels(5555791)/Manifest(video,format=m3u8-aapl,type=keyframes)"
#EXT-X-STREAM-INF:BANDWIDTH=7959113,RESOLUTION=2560x1440,CODECS="avc1.640032,mp4a.40.2",AUDIO="audio"
QualityLevels(7387814)/Manifest(video,format=m3u8-aapl)
#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=7959113,RESOLUTION=2560x1440,CODECS="avc1.640032",URI="QualityLevels(7387814)/Manifest(video,format=m3u8-aapl,type=keyframes)"
#EXT-X-STREAM-INF:BANDWIDTH=9868842,RESOLUTION=2560x1440,CODECS="avc1.640032,mp4a.40.2",AUDIO="audio"
QualityLevels(9256433)/Manifest(video,format=m3u8-aapl)
#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=9868842,RESOLUTION=2560x1440,CODECS="avc1.640032",URI="QualityLevels(9256433)/Manifest(video,format=m3u8-aapl,type=keyframes)"
#EXT-X-STREAM-INF:BANDWIDTH=11768326,RESOLUTION=2560x1440,CODECS="avc1.640032,mp4a.40.2",AUDIO="audio"
QualityLevels(11115028)/Manifest(video,format=m3u8-aapl)
#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=11768326,RESOLUTION=2560x1440,CODECS="avc1.640032",URI="QualityLevels(11115028)/Manifest(video,format=m3u8-aapl,type=keyframes)"
#EXT-X-STREAM-INF:BANDWIDTH=13681062,RESOLUTION=3840x2160,CODECS="avc1.640033,mp4a.40.2",AUDIO="audio"
QualityLevels(12986590)/Manifest(video,format=m3u8-aapl)
#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=13681062,RESOLUTION=3840x2160,CODECS="avc1.640033",URI="QualityLevels(12986590)/Manifest(video,format=m3u8-aapl,type=keyframes)"
#EXT-X-STREAM-INF:BANDWIDTH=15592476,RESOLUTION=3840x2160,CODECS="avc1.640033,mp4a.40.2",AUDIO="audio"
QualityLevels(14856858)/Manifest(video,format=m3u8-aapl)
#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=15592476,RESOLUTION=3840x2160,CODECS="avc1.640033",URI="QualityLevels(14856858)/Manifest(video,format=m3u8-aapl,type=keyframes)"
#EXT-X-STREAM-INF:BANDWIDTH=17530162,RESOLUTION=3840x2160,CODECS="avc1.640033,mp4a.40.2",AUDIO="audio"
QualityLevels(16752832)/Manifest(video,format=m3u8-aapl)
#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=17530162,RESOLUTION=3840x2160,CODECS="avc1.640033",URI="QualityLevels(16752832)/Manifest(video,format=m3u8-aapl,type=keyframes)"
#EXT-X-STREAM-INF:BANDWIDTH=19403831,RESOLUTION=4096x2304,CODECS="avc1.640033,mp4a.40.2",AUDIO="audio"
QualityLevels(18586168)/Manifest(video,format=m3u8-aapl)
#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=19403831,RESOLUTION=4096x2304,CODECS="avc1.640033",URI="QualityLevels(18586168)/Manifest(video,format=m3u8-aapl,type=keyframes)"
#EXT-X-STREAM-INF:BANDWIDTH=400608,CODECS="mp4a.40.2",AUDIO="audio"
QualityLevels(384000)/Manifest(aac_UND_6_384,format=m3u8-aapl)

That's got over a dozen streams the client can pick from.  The client app basically watches the buffer it has.  If it can't keep the buffer filled it needs to use less bitrate.  So now the client can pick the stream it wants to use and keep switch what it uses if needed to handle changes in bandwidth available to it.  It gets to pick perfect streams that often take over a week being prepared for streaming.  These streams are then pushed out to it's storage at the edge of the network

Emby on the other hand doesn't get things nearly as easy.  It tries to playback any format you have stored. One media might have 24 subtitles, 4 audio channels, none that match what the client needs and be using an old video codec.  Not only does Emby handle this but does it at better than real-time.

The job an Emby server does is easily 100x what a Netflix server has to handle!!!  Amazon Prime has it slightly tougher than Netflix as they handle Live TV and sell this as a package.  That's more demanding but still pretty easy as the starting format hardly ever changes, and they use dedicated encoding devices.

[syadnom 25]

7 hours ago, cayars said:

 

The job an Emby server does is easily 100x what a Netflix server has to handle!!!  Amazon Prime has it slightly tougher than Netflix as they handle Live TV and sell this as a package.  That's more demanding but still pretty easy as the starting format hardly ever changes, and they use dedicated encoding devices.

The only valid piece of this argument is that netflix pre-encodes everything so can time-shift the performance cost and not encode on the fly.  And we've already mentioned many months (rather years...) ago that we have hardware support and ffmpeg support for hevc again for years.  emby is transcoding to mobile on the fly today with ffmpeg and h.264, it's such a minimal piece to check for hardware support and change the encoding flags.  quicksync supports HEVC encoding for coming up on 7 generations.  *7*. 

And about storage, well that's not really true.  My server with QSV can handle 4 1080p HEVC encodes with it's 8th gen intel CPU.  That's plenty for my needs and most people are in a similar position.  Keeping a 4k, 1080p, 720p, and 480p copy for remote viewers eats up about twice the storage space and is a cumbersom process for users because unlike netflix with auto chunk selection, we don't get that in emby.

So emby ends up being a pretty static and simple encode in an old codec with no auto scaling.  It's more than a decade behind netflix model. 

 

[C.S. 76]

23 hours ago, nayr said:

I was able to get 2GbE Fiber Internet in the years since I asked Emby to add this..

I don't get it. I understand wanting to make things run as best as they can, but why would anyone worry about HEVC unless they are trying to save bandwidth? You obviously don't need to do that, unless it's your closest 100 friends you're serving.

[C.S. 76]

Also, did someone actually hold up netflix and youtube as examples of high quality??

What is happening

[nayr 36]

12 minutes ago, C.S. said:

I don't get it. I understand wanting to make things run as best as they can, but why would anyone worry about HEVC unless they are trying to save bandwidth? You obviously don't need to do that, unless it's your closest 100 friends you're serving.

At the time I requested this feature,  I had 40Mbit Uploads, and my biggest consumer was my Mother in the next state away whom had to cancel all unnecessary services and sell most of her possessions to fund her cancer treatments.. I paid her internet bill, which included a massive surcharge to lift her datacap she was hitting from streaming off my Emby alone, she didnt go over by much and having HEVC would have saved us >$600/year in additional bandwith fees..  

Now I dont even run an Emby Server, Ive moved on.. my mother survived her stage 4 cancer and moved across the country to live near my sister.

Datacaps are still very widespread, when I would travel I would quickly burn through all my mobile data streaming from my own server.. it was such a problem I built a portable Emby server to take with me so I could stream locally and save precious bandwidth for other things.

[syadnom 25]

11 minutes ago, C.S. said:

Also, did someone actually hold up netflix and youtube as examples of high quality??

What is happening

High qualiry DELIVERY.  I essentially never see buffering on these services.  Not saying they're the best video, but it works perfectly and for mobile, that's the primary need.  Emby is completely useless on mobile for me right now.  I have to dial back encoding so far it's just mud.  Mobile networks are still not very good.

[syadnom 25]

30 minutes ago, C.S. said:

I don't get it. I understand wanting to make things run as best as they can, but why would anyone worry about HEVC unless they are trying to save bandwidth? You obviously don't need to do that, unless it's your closest 100 friends you're serving.

'obviously' is obviously wrong here.  There is an entire internet between that server and the device, in particular mobile networks that are stingy and inconsistent.  Or if you are traveling abroad for instance, try to use Emby in Cancun with a server in Denver.  It's a fail.   I can stream netflix over my wireguard tunnel though.  That's more about adaptive encoding but a big piece is getting a watchable h.264 live stream is 2x the bandwidth of an h.265 and 3x of an AV1.

I would much rather burn up the CPU/GPU time and even oversize that component in the system to get the lower bitrate. 

For me, this isn't a 'would be nice'.  Emby is useless to me right now outside the home.  h.265 at a minimum is table stakes for Emby for me right now.  I don't really expect mobile networks to get dramatically better in the next few years either.

[C.S. 76]

Fair enough. Sometimes the internet sucks. It would be nice if someone would fix that.

But I will say I think you are doing Cancun wrong.

[sydlexius 268]

11 hours ago, cayars said:

Actually, you have it backwards. Emby streams are much more complex streams to deliver than Netflix or others streaming services use.   Netflix uses only prepared media so it's mainly working as a login/security system and web browser.  Netflix delivery media from the edge of the network not from a central location.  They create what's called a bitrate ladder. What this means is that the Netflix do very little work.  They have multiple versions of each piece of media created in different formats and codecs.  As an example, they might encode a simple video at the following profiles:
1080p 5.0 mbps
720p 4.0 mbps
640p 3.2 mbps
480p 2.0 mbps
270p 1 mbps

They could do 5 like this for AVC, 5 for HEVC and 5 for VP9 or AV1. They will do something similar for audio.  Storage is so much cheaper than CPU/GPU resources they would have to use otherwise. These different feeds are all passed by way of the manifest files which may look like this:

#EXTM3U
#EXT-X-VERSION:4
#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="audio",NAME="aac_UND_6_384",DEFAULT=YES,URI="QualityLevels(384000)/Manifest(aac_UND_6_384,format=m3u8-aapl)"
#EXT-X-STREAM-INF:BANDWIDTH=1355199,RESOLUTION=640x360,CODECS="avc1.64001e,mp4a.40.2",AUDIO="audio"
QualityLevels(926058)/Manifest(video,format=m3u8-aapl)
#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=1355199,RESOLUTION=640x360,CODECS="avc1.64001e",URI="QualityLevels(926058)/Manifest(video,format=m3u8-aapl,type=keyframes)"
#EXT-X-STREAM-INF:BANDWIDTH=2532741,RESOLUTION=960x540,CODECS="avc1.64001f,mp4a.40.2",AUDIO="audio"
QualityLevels(2078252)/Manifest(video,format=m3u8-aapl)
#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=2532741,RESOLUTION=960x540,CODECS="avc1.64001f",URI="QualityLevels(2078252)/Manifest(video,format=m3u8-aapl,type=keyframes)"
#EXT-X-STREAM-INF:BANDWIDTH=3617004,RESOLUTION=1280x720,CODECS="avc1.64001f,mp4a.40.2",AUDIO="audio"
QualityLevels(3139175)/Manifest(video,format=m3u8-aapl)
#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=3617004,RESOLUTION=1280x720,CODECS="avc1.64001f",URI="QualityLevels(3139175)/Manifest(video,format=m3u8-aapl,type=keyframes)"
#EXT-X-STREAM-INF:BANDWIDTH=4843919,RESOLUTION=1920x1080,CODECS="avc1.640028,mp4a.40.2",AUDIO="audio"
QualityLevels(4339679)/Manifest(video,format=m3u8-aapl)
#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=4843919,RESOLUTION=1920x1080,CODECS="avc1.640028",URI="QualityLevels(4339679)/Manifest(video,format=m3u8-aapl,type=keyframes)"
#EXT-X-STREAM-INF:BANDWIDTH=6086786,RESOLUTION=1920x1080,CODECS="avc1.640028,mp4a.40.2",AUDIO="audio"
QualityLevels(5555791)/Manifest(video,format=m3u8-aapl)
#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=6086786,RESOLUTION=1920x1080,CODECS="avc1.640028",URI="QualityLevels(5555791)/Manifest(video,format=m3u8-aapl,type=keyframes)"
#EXT-X-STREAM-INF:BANDWIDTH=7959113,RESOLUTION=2560x1440,CODECS="avc1.640032,mp4a.40.2",AUDIO="audio"
QualityLevels(7387814)/Manifest(video,format=m3u8-aapl)
#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=7959113,RESOLUTION=2560x1440,CODECS="avc1.640032",URI="QualityLevels(7387814)/Manifest(video,format=m3u8-aapl,type=keyframes)"
#EXT-X-STREAM-INF:BANDWIDTH=9868842,RESOLUTION=2560x1440,CODECS="avc1.640032,mp4a.40.2",AUDIO="audio"
QualityLevels(9256433)/Manifest(video,format=m3u8-aapl)
#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=9868842,RESOLUTION=2560x1440,CODECS="avc1.640032",URI="QualityLevels(9256433)/Manifest(video,format=m3u8-aapl,type=keyframes)"
#EXT-X-STREAM-INF:BANDWIDTH=11768326,RESOLUTION=2560x1440,CODECS="avc1.640032,mp4a.40.2",AUDIO="audio"
QualityLevels(11115028)/Manifest(video,format=m3u8-aapl)
#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=11768326,RESOLUTION=2560x1440,CODECS="avc1.640032",URI="QualityLevels(11115028)/Manifest(video,format=m3u8-aapl,type=keyframes)"
#EXT-X-STREAM-INF:BANDWIDTH=13681062,RESOLUTION=3840x2160,CODECS="avc1.640033,mp4a.40.2",AUDIO="audio"
QualityLevels(12986590)/Manifest(video,format=m3u8-aapl)
#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=13681062,RESOLUTION=3840x2160,CODECS="avc1.640033",URI="QualityLevels(12986590)/Manifest(video,format=m3u8-aapl,type=keyframes)"
#EXT-X-STREAM-INF:BANDWIDTH=15592476,RESOLUTION=3840x2160,CODECS="avc1.640033,mp4a.40.2",AUDIO="audio"
QualityLevels(14856858)/Manifest(video,format=m3u8-aapl)
#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=15592476,RESOLUTION=3840x2160,CODECS="avc1.640033",URI="QualityLevels(14856858)/Manifest(video,format=m3u8-aapl,type=keyframes)"
#EXT-X-STREAM-INF:BANDWIDTH=17530162,RESOLUTION=3840x2160,CODECS="avc1.640033,mp4a.40.2",AUDIO="audio"
QualityLevels(16752832)/Manifest(video,format=m3u8-aapl)
#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=17530162,RESOLUTION=3840x2160,CODECS="avc1.640033",URI="QualityLevels(16752832)/Manifest(video,format=m3u8-aapl,type=keyframes)"
#EXT-X-STREAM-INF:BANDWIDTH=19403831,RESOLUTION=4096x2304,CODECS="avc1.640033,mp4a.40.2",AUDIO="audio"
QualityLevels(18586168)/Manifest(video,format=m3u8-aapl)
#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=19403831,RESOLUTION=4096x2304,CODECS="avc1.640033",URI="QualityLevels(18586168)/Manifest(video,format=m3u8-aapl,type=keyframes)"
#EXT-X-STREAM-INF:BANDWIDTH=400608,CODECS="mp4a.40.2",AUDIO="audio"
QualityLevels(384000)/Manifest(aac_UND_6_384,format=m3u8-aapl)

That's got over a dozen streams the client can pick from.  The client app basically watches the buffer it has.  If it can't keep the buffer filled it needs to use less bitrate.  So now the client can pick the stream it wants to use and keep switch what it uses if needed to handle changes in bandwidth available to it.  It gets to pick perfect streams that often take over a week being prepared for streaming.  These streams are then pushed out to it's storage at the edge of the network

Emby on the other hand doesn't get things nearly as easy.  It tries to playback any format you have stored. One media might have 24 subtitles, 4 audio channels, none that match what the client needs and be using an old video codec.  Not only does Emby handle this but does it at better than real-time.

The job an Emby server does is easily 100x what a Netflix server has to handle!!!  Amazon Prime has it slightly tougher than Netflix as they handle Live TV and sell this as a package.  That's more demanding but still pretty easy as the starting format hardly ever changes, and they use dedicated encoding devices.

I've been following the Netflix blogs for years, and based upon what I've been following you are 100% correct when it comes to how distribution nodes interact with endpoints.  OTOH, their back-end stuff is pretty incredible.  Their render pipeline has tons of complexity into how it handles encodes for various media types (animated vs non-animated, for example), at varying bitrates with a ton of different paramaters for several target containers at their various resolutions.  Some of their code is available on Github, and most of their logic is flowed out.  End-users don't really have much to do with this, other than paying for the resolution they want and selecting the applicable dynamic range for their devices (where necessary).

[SLMK 15]

On 10/24/2022 at 5:03 AM, visproduction said:

Is everyone aware that native browser support for h.265 or AV1 is pretty limited.  It's nice that you guys set up your systems to playback h.265 in a browser with some plug-in or hardware or mobile app and it works fine.   But 99% of the desktop user use a browser, where playback  does not work.  Have a look here for the green blocks on browsers that h.265 or Av1 can playback today.

Support for h.265 is poor, but its around 20%, not possibly less than 1%. Most of the red blocks are obsolete versions or complete irrelevancies like Opera Mini or IE.

It also shows native AV1 browser support at very close to 75%. It is supported by every current relevant browser with the exception of Safari and Edge, and can be enabled in edge with a free extension from the Windows store. Its really only the 15% or so iOS users who cannot play back AV1 currently.

[Carlo 4552]

In reality, H.265 support is a lot worse than most people think. For a while it was hit or miss knowing if the next version of Edge for example would play videos correctly, stutter or just give an error.  It's all part of the growing pains unfortunately. Here's a little break down showing support for HEVC/H.265 in modern browsers.  I expanded the best supported browser just to show its only about 1/3 fully supported, 1/3 partially, 1/3 no support of features,

Date: 2022-06-30
Source: https://www.lambdatest.com/web-technologies/hevc-support-on-edge-18?utm_source=awin&utm_medium=affiliate&awc=24859_1666822318_8dd763250d67660abbb24af7efc927cc

Try testing your own browsers: https://www.lambdatest.com/hevc-h-265-video-format?utm_source=awin&utm_medium=affiliate&awc=24859_1666822317_e33d024b35abd6fdb8ac06dba3e3a254

Carlo

[byakuya32 24]

2 minutes ago, cayars said:

In reality, H.265 support is a lot worse than most people think. For a while it was hit or miss knowing if the next version of Edge for example would play videos correctly, stutter or just give an error.  It's all part of the growing pains unfortunately. Here's a little break down showing support for HEVC/H.265 in modern browsers.  I expanded the best supported browser just to show its only about 1/3 fully supported, 1/3 partially, 1/3 no support of features,

Date: 2022-06-30
Source: https://www.lambdatest.com/web-technologies/hevc-support-on-edge-18?utm_source=awin&utm_medium=affiliate&awc=24859_1666822318_8dd763250d67660abbb24af7efc927cc

Try testing your own browsers: https://www.lambdatest.com/hevc-h-265-video-format?utm_source=awin&utm_medium=affiliate&awc=24859_1666822317_e33d024b35abd6fdb8ac06dba3e3a254

Carlo

Emby has an app that should be able to support it we are not talking about web browsers. It should transcode in h.265 If device supports it is not use h.264 and so on going back till there is 1 the device supports. Some things will have xvid or avi but with this methodology it should have 100% playback covered while using the least bandwith possible. Av1 is just starting to come arround with support.

[nayr 36]

We are not really even talking about the clients in any way/shape/form.. ALL the Client Applications support playing back HEVC already if used on modern hardware, Emby SERVER already supports streaming HEVC files to these EMBY clients, Emby Server already supports re-encoding existing files into HEVC copies to send to Emby clients.

We just want TRANSCODING support, on the server.. that if I have HEVC Encoding Hardware existing in my server, to simply make it an OPTION to Transcode files into HEVC when its supported by the client, which for the vast majority of users consuming Emby via TV and/or Mobile Device should be extremely well supported on both ends, Client and Server by now.. Every TV streaming device and SmartPhone/Tablet that is not basically an antique has HEVC decoding hardware, Every respectable server that has hardware transcoding support likely has HEVC encoding hardware.

Nobody is saying to make it HEVC only FFS.. If anything browser argument is great, this is a feature that sucks so bad in browsers people may PAY EMBY MONEY FOR CLIENTS IF THEY IMPLEMENT IT.. seems like anyone with any sense here would have had this done loooong ago.. Once it felt like Emby was leading on features and things, that time has passed.

Edited October 26, 2022 by nayr

[SLMK 15]

I cant imagine H265 transcode support will ever make sense, the patent/license situation makes it unusable.

I'm really hoping AV1 transcode support comes soon though, its legally a lot clearer, playback support is currently high enough to be worth considering and hardware encode is becoming available.

[nayr 36]

So re-encoding is fine, we can do this already w/Emby right now..  but transcoding is patent/license encumbered? hows that? its the same thing you just send the output over the network instead of to local storage.

My understanding is the license is paid by the manufacturer of the encoding/decoding hardware.

Edited October 26, 2022 by nayr

[syadnom 25]

5 minutes ago, SLMK said:

I cant imagine H265 transcode support will ever make sense, the patent/license situation makes it unusable.

That's rediculous.  License fees are already covered in all encoding hardware.

[SLMK 15]

38 minutes ago, syadnom said:

That's rediculous.  License fees are already covered in all encoding hardware.

I was under the impression that unlike H264 there are also fees on the playback side, at least if it is not decoded by hardware that has already paid a license, hence why most browsers don't support it and streaming services mostly wont use it. I might be wrong there, but I thought licensing rather than anything technical was the primary holdup with using it.

Regardless, AV1 has more support already without those issues so it makes more sense to use.

[nayr 36]

Modern Desktops can barely decode h265 via software alone Realtime, there are no TV's or Mobile devices going to come close to that kinda horsepower.. virtually everything that can play back H265 relies on hardware to do so simply because its so computationally expensive.. same with AV1

Both should be supported, and clients can already play H265 but it REQUIRES hardware support.. Emby has had this capability before this thread was ever started.

Edited October 27, 2022 by nayr

[SLMK 15]

7 minutes ago, nayr said:

Both should be supported

Well yes, ideally, I want to see at least one in use. My assumption was there must be a good reason they wont allow h265 so far, and the mess of overlapping patent pools and spotty browser support were the likely culprit. I don't really care which is supported as they are more or less equivalent in compression. H265 has more mature hardware encoders, AV1 has better browser support, either way its time one of them was supported I believe.

[Carlo 4552]

17 hours ago, syadnom said:

That's rediculous.  License fees are already covered in all encoding hardware.

This has been in contention since 2015. 

https://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=103042#:~:text=Here are the main points of the HEVC,content (as there was for H.264 and MPEG-2)
The cost is $0.20/unit for all licensed encoders and decoders
There’s a de minimis exception for units under 100,000
There’s an annual cap of US $25 million.
There is no license on HEVC-encoded content (as there was for H.264 and MPEG-2)

That could put Emby on the hook for 20 a client regardless of the client license (free or paid).

18 hours ago, nayr said:

We are not really even talking about the clients in any way/shape/form.. ALL the Client Applications support playing back HEVC already if used on modern hardware, Emby SERVER already supports streaming HEVC files to these EMBY clients, Emby Server already supports re-encoding existing files into HEVC copies to send to Emby clients.

We just want TRANSCODING support, on the server.. that if I have HEVC Encoding Hardware existing in my server, to simply make it an OPTION to Transcode files into HEVC when its supported by the client, which for the vast majority of users consuming Emby via TV and/or Mobile Device should be extremely well supported on both ends, Client and Server by now.. Every TV streaming device and SmartPhone/Tablet that is not basically an antique has HEVC decoding hardware, Every respectable server that has hardware transcoding support likely has HEVC encoding hardware.

Nobody is saying to make it HEVC only FFS.. If anything browser argument is great, this is a feature that sucks so bad in browsers people may PAY EMBY MONEY FOR CLIENTS IF THEY IMPLEMENT IT.. seems like anyone with any sense here would have had this done loooong ago.. Once it felt like Emby was leading on features and things, that time has passed.

Why not?  The client has to be able to play the media and this is not nice and tidy but a mess in itself. H.265 is used differently when streamed vs a progressive or single file version.  To stream with h.265 proper to Apple devices for example the format needed for h.265 is fmp4(CMAF) which is close but not the same as your typical mp4 file.  HLS was developed by Apple and up to recently only supported MPEG Transport Streams (TS) but recently introduced CMAF (Common Media Application Format). CMAF used fragmented MP4 segments with specific criteria for the encoding.  One problem with this is that CMAF wasn't designed with low-latency broadcasting in mind. 

As I mentioned earlier, pre-creating media for streaming is one thing, but providing real-time transcoding or broadcasting streams is quite another thing.  Introducing real-time transcoding adds quite a bit more latency to the pipeline that already is on the high side for latency wise. Without having streams using low latency, you run into buffering and other issues such as stuttering or micro/macro freezes because the client and server can't communicate fast enough.

Think about that and you'll understand why these streaming companies pre-process the media multiple ways, then push it out to be as close to the customer as possible. They make use of data centers, co-locate at large ISPs and use CDN networks.  On the other hand, you want/need your Emby Server to "compete" with that type of pipeline and delivery network.  You might be streaming to friends or relatives across the country vs a collation center where the clients ISP is hosted for super-fast delivery. 

So essentially, instead of lowering the latency in comparison to Netflix and Hulu's.  Our packets will almost surely be traveling a greater distance over slower pipes then the big guys, for yet more latency compared to them.  H.265 takes longer to process compared to H.264 even on GPUs so there is additional latency added by this step.  Having to use Chucked Transfer Encoding vs a progressive file (as often streamed now) adds latency.  All this latency makes it much harder for round trip communication to happen in a time period that allows for positive packet chains with positive ACKS or negative NACKs to acknowledge the ongoing transmission.

There is an extension to CMAF that offers Low Latency CMAF but is even more restrictive spec wise.  I've actually just broken the surface of some of the challenges doing this proper so you can understand what's involved.  Anyone who thinks it's a simple process of changing a few parameters on the ffmpeg command line are surely mistaken.   That works for creating local files but it's a whole other thing to do this for streaming.  I haven't even touched on Live TV and how that could be affected with additional latency but with HLS packages you can't just start displaying data until you've acquired a certain amount of data. The minimum is normally 3 segments with a duration of 6 to 10 seconds each. If you have 18 to 30 seconds needed before playback can start and you're encoding at 10Mbps you have 60Mb per segment *3 =180Mb that needs to transfer before anything is shown. It takes time to send 180Mb to the client which as you guessed causes more latency.

I could go on and on but I think that gives a bit of a picture into what a project like this entails.  It's just not switching encoder settings or something as simple as that but a complete eco-system type of change that very much involves the client devices and what they will and will not be able to handle or process.

I've personally been one of the original people wanting h.265 to happen but I also understand the magnitude of what this type of change entails. I just wanted to share of this knowledge with you guys to give you an idea what's involved and why it's actually much harder to do in real-time vs a Netflix or Hulu style.

Carlo

Edited October 27, 2022 by cayars