Bitrate when tonemapping far too high

[MSI2017 40]

Hi all,

When a device does not support HDR and the server needs to tonemap, it often ends up transcoding a file with a much higher bitrate than even the source material. The screenshot below show shows the info for a 18mpbs file. Unfortunately Emby does not seem to realize it when the client cannot handle it and starts to drop frames, or in most cases, just outright crashes.

 

Logs (different device but same probably same issue, sound and subtitles go for a bit but video is frozen, bitrate is higher than the connection can handle)

https://katb.in/qedalelovun

[Happy2Play 8281]

Correct as there is bitrate doubling when converting HEVC to h264 to potentially maintain the quality.  So it could go as high as the highest playback quality setting depending on the items original bitrate, ie 50Mbps becomes 100Mbps.

[MSI2017 40]

7 minutes ago, Happy2Play said:

Correct as there is bitrate doubling when converting HEVC to h264 to potentially maintain the quality.  So it could go as high as the highest playback quality setting depending on the items original bitrate, ie 50Mbps becomes 100Mbps.

That makes sense, but the Chromecast should support h265, I know there's a bug on Emby not choosing HEVC so should be fine in the future but still weird that the app does not detect that playback it not happening and dropping the bitrate.

[GrimReaper 3289]

25 minutes ago, MSI2017 said:

still weird that the app does not detect that playback it not happening and dropping the bitrate

There is no adaptive streaming within Emby, once bitrate is negotiated it doesn't change irrespective of subsequent changes. Besides manually restricting max. quality to some value your connection can take, currently there's no alternative. You might wanna lend your support here:

 

[MSI2017 40]

Just now, GrimReaper said:

There is no adaptive streaming within Emby, once bitrate is negotiated it doesn't change irrespective of subsequent changes. Besides manually restricting max. quality to some value your connection can take, currently there's no alternative. You might wanna lend your support here:

 

Even if it is not adaptive, it should notice playback just plainly not working and going for a lower bitrate right? Also, sometimes Emby chooses HLS which is adaptive by nature.

[GrimReaper 3289]

12 minutes ago, MSI2017 said:

Even if it is not adaptive, it should notice playback just plainly not working and going for a lower bitrate right? 

There is no dynamic quality adjustment built into the system. You can either manually limit max. quality to ensure smooth playback, support one of the existing FR"s or open a new one hoping it'll get implemented at some point. 

[MSI2017 40]

Just now, GrimReaper said:

There is no dynamic quality adjustment built into the system. You can either manually limit max. quality to ensure smooth playback, support one of the existing FR"s or open a new one hoping it'll get implemented at some point. 

Isn't that like basic functionality? Plus how would it than know/decide to even transcode in the first place) assuming file type isn't the issue?

[Happy2Play 8281]

16 minutes ago, MSI2017 said:

Plus how would it than know/decide to even transcode in the first place) assuming file type isn't the issue?

Client playback capabilities queried before every playback.  IE client max quality not current capable quality.

My browser for example

http://localhost:8096/emby/videos/5058/main.m3u8?DeviceId=xxxxxxxx-6819-xxxx-xxxx-f362d3e4a6a0&MediaSourceId=db8578678e9d25eca2ee7af2020cc5c4&PlaySessionId=b3c8f10f984741eca29de052668f9c8e&api_key=xxxxxda521fa40948b43c68c96bd2161&VideoCodec=h264,h265,hevc&AudioCodec=ac3,mp3,aac&VideoBitrate=139744000&AudioBitrate=256000&AudioStreamIndex=1&TranscodingMaxAudioChannels=2&SegmentContainer=m4s,ts&MinSegments=1&BreakOnNonKeyFrames=True&SubtitleStreamIndexes=-1&ManifestSubtitles=vtt&h264-profile=high,main,baseline,constrainedbaseline,high10&h264-level=62&TranscodeReasons=DirectPlayError&allowVideoStreamCopy=false

The client report max quality but I know for a fact the client will chock on 140Mbps media.  But everything is conditional.

Edited January 27, 2023 by Happy2Play

[MSI2017 40]

7 minutes ago, Happy2Play said:

Client playback capabilities queried before every playback.  IE client max quality not current capable quality.

My browser for example

http://localhost:8096/emby/videos/5058/main.m3u8?DeviceId=xxxxxxxx-6819-xxxx-xxxx-f362d3e4a6a0&MediaSourceId=db8578678e9d25eca2ee7af2020cc5c4&PlaySessionId=b3c8f10f984741eca29de052668f9c8e&api_key=xxxxxda521fa40948b43c68c96bd2161&VideoCodec=h264,h265,hevc&AudioCodec=ac3,mp3,aac&VideoBitrate=139744000&AudioBitrate=256000&AudioStreamIndex=1&TranscodingMaxAudioChannels=2&SegmentContainer=m4s,ts&MinSegments=1&BreakOnNonKeyFrames=True&SubtitleStreamIndexes=-1&ManifestSubtitles=vtt&h264-profile=high,main,baseline,constrainedbaseline,high10&h264-level=62&TranscodeReasons=DirectPlayError&allowVideoStreamCopy=false

The client report max quality but I know for a fact the client will chock on 140Mbps media.  But everything is conditional.

But the moment Emby server notices dropped frames, or playback hangs, why doesn't it choose to go to a lower bitrate? 

[MSI2017 40]

Just now, MSI2017 said:

But the moment Emby server notices dropped frames, or playback hangs, why doesn't it choose to go to a lower bitrate? 

And it's not even always bitrate limited btw, now on home network (which is plenty fast) it still hangs and decides to keep the high bitrate.

[Happy2Play 8281]

Just now, MSI2017 said:

But the moment Emby server notices dropped frames, or playback hangs, why doesn't it choose to go to a lower bitrate? 

Emby is not adaptive so once it starts it will not change even if the clients starts choking.

1 minute ago, MSI2017 said:

And it's not even always bitrate limited btw, now on home network (which is plenty fast) it still hangs and decides to keep the high bitrate.

Every device technically has limits and are usually documented but all users push those limit as high bitrate media was never designed to be streamed.  One reason you will not see really high bitrates from online services as the bandwidth is not sustainable.

 

[MSI2017 40]

7 minutes ago, Happy2Play said:

Emby is not adaptive so once it starts it will not change even if the clients starts choking.

What is the point of using HLS than? It's adaptive by nature. Plus doens't that equate to a shitty user experience? Especially for those less tech savvy (same as my last topic about the quality options lol) I get switching bitrate is not as smooth as Netflix for example does it, where it can seemlessly jump from dogshit to very nice without dropping a frame (maybe one or two) but in our case it should try high and just a very easy condition/rule that when playback freezes or drops too many frames it just drops down the quality.

7 minutes ago, Happy2Play said:

Every device technically has limits and are usually documented but all users push those limit as high bitrate media was never designed to be streamed.  One reason you will not see really high bitrates from online services as the bandwidth is not sustainable.

I think it's not sustainable economically but from a technical pov it should be also to do it for some clients. But Netflix pushes quite good bitrate, so does AppleTV+. In fact, the file that I posted in this thread with issue has a lower bitrate than what Netlfix pushes. 

 

I've also covered it a bit in this topic but I think Emby needs a overhaul on how transcoding is handled. It chooses h264 for clients supporting hevc, it tonemaps to a crazy bitrate, chockes but doesn't correct, plus the issues I mention in the topic below. Usually I am at home on my pretty strong local network (it can push 70/80MB/s over WiFi) but I'm using Emby more outside of my homenetwork now and when the condition is a bit tough it usually just faceplants unless I'm on a speedy enough connection allowing Direct Playback

 

Edited January 27, 2023 by MSI2017

[Happy2Play 8281]

4 minutes ago, MSI2017 said:

What is the point of using HLS than? It's adaptive by nature. Plus doens't that equate to a shitty user experience? Especially for those less tech savvy (same as my last topic about the quality options lol) I get switching bitrate is not as smooth as Netflix for example does it, where it can seemlessly jump from dogshit to very nice without dropping a frame (maybe one or two) but in our case it should try high and just a very easy condition/rule that when playback freezes or drops too many frames it just drops down the quality

devs will have to comment on the more technical side but this has been brought up before as there is no adaptive changing.  @softworkz@Luke

1 minute ago, MSI2017 said:

I think it's not sustainable economically but from a technical pov it should be also to do it for some clients. But Netflix pushes quite good bitrate, so does AppleTV+. In fact, the file that I posted in this thread with issue has a lower bitrate than what Netlfix pushes. 

 

Set your max values and you will not see high bitrates.  But there isn't going to a one size fits all as everyone's uses case is different from 1 user with no issues to 20+ users fighting for bandwidth.

 

 

[MSI2017 40]

31 minutes ago, Happy2Play said:

devs will have to comment on the more technical side but this has been brought up before as there is no adaptive changing.  @softworkz@Luke

 

Set your max values and you will not see high bitrates.  But there isn't going to a one size fits all as everyone's uses case is different from 1 user with no issues to 20+ users fighting for bandwidth.

 

 

Max values are a bad band-aid imo since it depens. Sometimes you might have a solid 5G connection, other moments you might not. I also don't want to transcode when I don't need to. Upload bandwith it not an issue. 

[Happy2Play 8281]

1 minute ago, MSI2017 said:

Max values are a bad band-aid imo since it depens. Sometimes you might have a solid 5G connection, other moments you might not. I also don't want to transcode when I don't need to. Upload bandwith it not an issue. 

True but per your image it states the video codec is not supported but that would be a different topic.

[MSI2017 40]

Just now, Happy2Play said:

True but per your image it states the video codec is not supported but that would be a different topic.

Codec should be fine, just cannot handle HDR (nor 4K). But I've seen Emby transcode 265 to 264 all the time despite Chrome now supporting it

[Happy2Play 8281]

7 minutes ago, MSI2017 said:

Codec should be fine, just cannot handle HDR (nor 4K). But I've seen Emby transcode 265 to 264 all the time despite Chrome now supporting it

Need ffmpeg loag as image shows reason.

[MSI2017 40]

23 minutes ago, Happy2Play said:

Need ffmpeg loag as image shows reason.

Logs are in the original post

[Happy2Play 8281]

2 minutes ago, MSI2017 said:

Logs are in the original post

Sorry overlooked the link. 

Not sure why nerd stats states video codec then as it is a bitrate issue causing transcoding so entire files get converted as Emby does not transcode in 265 yet.

&VideoCodec=h264,h265,hevc,vp8,vp9&AudioCodec=aac,mp3,opus,flac,vorbis&VideoBitrate=6232000&AudioBitrate=768000&MaxWidth=1920
&TranscodeReasons=ContainerBitrateExceedsLimit

But does not look that log corresponds to image as the log is converting to the 7Mbps limit shown in the log. 

h264_qsv -b:v:0 6232000 -g:v:0 144 -maxrate:v:0 6232000 -bufsize:v:0 12464000

input

20:26:38.304 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'K:\Series\GoT BRip\s01e02.mp4':
20:26:38.304   Metadata:
20:26:38.304     major_brand     : mp42
20:26:38.304     minor_version   : 0
20:26:38.304     compatible_brands: mp42isom
20:26:38.304     creation_time   : 2023-01-16T20:24:17.000000Z
20:26:38.304   Duration: 01:20:47.38, start: 0.000000, bitrate: 18591 kb/s

output

20:26:39.505   Metadata:
20:26:39.505     encoder         : Lavf59.17.100
20:26:39.505   Stream #0:0: Video: h264 (H264 / 0x34363248), qsv(bt2020nc/bt2020/bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 6232 kb/s, Level 31, 23.98 fps, 1k tbn
20:26:39.505     Metadata:
20:26:39.505       encoder         : Lavc59.21.100 h264_qsv
20:26:39.505     Side data:
20:26:39.505       cpb: bitrate max/min/avg: 6232000/0/6232000 buffer size: 12464000 vbv_delay: N/A

18Mbps converted to 7Mbps

[softworkz 3335]

1 hour ago, Happy2Play said:

1 hour ago, MSI2017 said:

What is the point of using HLS than? It's adaptive by nature. Plus doens't that equate to a shitty user experience? Especially for those less tech savvy (same as my last topic about the quality options lol) I get switching bitrate is not as smooth as Netflix for example does it, where it can seemlessly jump from dogshit to very nice without dropping a frame (maybe one or two) but in our case it should try high and just a very easy condition/rule that when playback freezes or drops too many frames it just drops down the quality

devs will have to comment on the more technical side but this has been brought up before as there is no adaptive changing.  @softworkz@Luke

@MSI2017  That's a misconception: HLS is NOT "adaptive by nature".

HLS only provides the opportunity to advertise different "renditions" of the same streams. Renditions can be different codecs but most typically it's used for advertising a stream in multiple bitrate versions. The adaptive part though, is not part of the protocol, it's up to the client to switch between renditions dynamically.

Now you need to consider the following: HLS has been designed to streaming pre-transcoded video or (in case of live-videos) for large-scale deployments - in both cases, it's easy to provide multiple bitrate variants of streams simultaneously.
The important work here is simultaneously. Because the HLS spec requires segments of multiple stream renditions to be available at the same time - which in turn allows clients to switch more or less seamlessly. 

Emby is performing on-demand live transcoding and transcoding a video to multiple bitrate versions simultaneously would cause excessive resource usage, so we can't do that regularly.
We made some attempts to bend the spec requirements and wait for a request to come for segments of another rendition, but haven't come to something solid yet.

That's the background.

To your specific case: When there's one thing that  isn't always working well, then it's Emby's built-in bitrate detection. The best way is to set your available bitrate through the quality selection and then you should actually be all good.

Edited January 27, 2023 by softworkz

[MSI2017 40]

10 minutes ago, Happy2Play said:

Sorry overlooked the link. 

Not sure why nerd stats states video codec then as it is a bitrate issue causing transcoding so entire files get converted as Emby does not transcode in 265 yet.

&VideoCodec=h264,h265,hevc,vp8,vp9&AudioCodec=aac,mp3,opus,flac,vorbis&VideoBitrate=6232000&AudioBitrate=768000&MaxWidth=1920
&TranscodeReasons=ContainerBitrateExceedsLimit

But does not look that log corresponds to image as the log is converting to the 7Mbps limit shown in the log. 

h264_qsv -b:v:0 6232000 -g:v:0 144 -maxrate:v:0 6232000 -bufsize:v:0 12464000

input

20:26:38.304 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'K:\Series\GoT BRip\s01e02.mp4':
20:26:38.304   Metadata:
20:26:38.304     major_brand     : mp42
20:26:38.304     minor_version   : 0
20:26:38.304     compatible_brands: mp42isom
20:26:38.304     creation_time   : 2023-01-16T20:24:17.000000Z
20:26:38.304   Duration: 01:20:47.38, start: 0.000000, bitrate: 18591 kb/s

output

20:26:39.505   Metadata:
20:26:39.505     encoder         : Lavf59.17.100
20:26:39.505   Stream #0:0: Video: h264 (H264 / 0x34363248), qsv(bt2020nc/bt2020/bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 6232 kb/s, Level 31, 23.98 fps, 1k tbn
20:26:39.505     Metadata:
20:26:39.505       encoder         : Lavc59.21.100 h264_qsv
20:26:39.505     Side data:
20:26:39.505       cpb: bitrate max/min/avg: 6232000/0/6232000 buffer size: 12464000 vbv_delay: N/A

18Mbps converted to 7Mbps

Yes correct, I couldn't find the correct log, will search tomorrow. This was a similar situation where the client's internet couldn't handle the stream.

[MSI2017 40]

6 minutes ago, softworkz said:

@MSI2017  That's a misconception: HLS is NOT "adaptive by nature".

HLS only provides the opportunity to advertise different "renditions" of the same streams. Renditions can be different codecs but most typically it's used for advertising a stream in multiple bitrate versions. The adaptive part though, is not part of the protocol, it's up to the client to switch between renditions dynamically.

Now you need to consider the following: HLS has been designed to streaming pre-transcoded video or (in case of live-videos) for large-scale deployments - in both cases, it's easy to provide multiple bitrate variants of streams simultaneously.
The important work here is simultaneously. Because the HLS spec requires segments of multiple stream renditions to be available at the same time - which in turn allows clients to switch more or less seamlessly. 

Emby is performing on-demand live transcoding and transcoding a video to multiple bitrate versions simultaneously would cause excessive resource usage, so we can't do that regularly.
We made some attempts to bend the spec requirements and wait for a request to come for segments of another rendition, but haven't come to something solid yet.

That's the background.

To your specific case: When there's one thing that  isn't always working well, then it's Emby's built-in bitrate detection. The best way is to set your available bitrate through the quality selection and then you should actually be all good.

Thanks for the background, that's actually pretty interesting! A suggestion might be for Emby if it detects playback might be bandwidth limited that it transcodes one additional stream in that lower bitrate for an X amount of time so in the case of it needing to switch it's quite seamless.

 

Regarding my case, I'm not entirely aware of what the bitrate detection is (internet bitrate or media) so that's probably the issue. Choosing manually does work for me personally as I usually know what is what and what my connection can handle. But my parents for example wouldn't know what bitrate to choose (made a different topic for that) that's why I was hoping that the player could be more proactive in dropping the bitrate when it detects dropped frames of playback hangs.

[softworkz 3335]

On 1/28/2023 at 12:53 AM, MSI2017 said:

what the bitrate detection is (internet bitrate or media) so that's probably the issue.

Yes, I meant internet bitrate detection.

On 1/28/2023 at 12:53 AM, MSI2017 said:

could be more proactive in dropping the bitrate when it detects dropped frames of playback hangs

Playback hangs can have other causes than internet bandwidth and dropped frames are always an indication for a local issue rather than a bandwidth problem.

But besides that - yes: there's room for improvement by looking at the player's state (whether it's buffering/waiting for data).

It's not that easy, though, because there could also be just a temporary congestion or short interruption. When the client would try to do something, it would need to stop playback and resume with a different bitrate. When it does that within that outage period, it might make things worse.

But at least when it's a permanent condition, we should be able to improve the experience.

Also - @Luke do we still have the assumption of double bitrate from HEVC to H264? That's way too steep and doesn't match reality. I would go with 1.5 at most.

Edited January 30, 2023 by softworkz

[MSI2017 40]

On 1/28/2023 at 1:07 AM, softworkz said:

Playback hangs can have other causes than internet bandwidth and dropped frames are always an indication for a local issue rather than a bandwidth problem.

I've checked by simulating a network speed limit on a laptop, CPU of client is barely touched, iGPU is doing almost nothing as well, nothing else is open. Leaves connection speed as the only cause I guess, would need further testing. That's the only way I could test since a chromecast does not give that information. But on the Chromecast video playback just hangs after a few seconds. Interestingly, Emby (just like on Chrome clients) keeps choosing for h264 for its final output instead of h265 despite there being support. 

 

On 1/28/2023 at 1:07 AM, softworkz said:

It's not that easy, though, because there could also be just a temporary congestion or short interruption. When the client would try to do something, it would need to stop playback and resume with a different bitrate. When it does that within that outage period, it might make things worse.

But at least when it's a permanent condition, we should be able to improve the experience.

Also - @Luke do we still have the assumption of double bitrate from HEVC to H264? That's way too steep and doesn't match reality. I would go with 1.5 at most.

Yeah I can imagine. Wonder how Netflix does it, when looking at their dev playback overlay it's pretty bang on with the info about my connection (and I love the included VMAF score) and chooses the perfect bitrate to match the connection. 

When looking at the YT stats for nerds it's also pretty bang on and I believe it checks the connection speed the moment it is buffering new data. Its get updated the exact same moment it extends it buffer.

 

Something sortof related, is there a way to check what the browser reports as the device playback capabilities? A shocking amount of devices in my house just accept an HDR video when they clearly cannot do so.

[GrimReaper 3289]

8 minutes ago, MSI2017 said:

Wonder how Netflix does it, when looking at their dev playback overlay it's pretty bang on with the info about my connection (and I love the included VMAF score) and chooses the perfect bitrate to match the connection. 

It doesn't - it just serves you pre-encoded media with lower bitrate than your connection can handle, they don't transcode in real time. Maybe this can shed some light how they do it:

On 10/24/2022 at 8:51 AM, 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.