M3u - How to make Emby pick highest quality stream?

[Luke 42077]

This will be implemented in the upcoming 4.7 server release. For those on the beta channel, that's 4.7.0.26+. If you run the beta channel and you still see examples where you think it's not picking the highest quality, then please open a topic in the testing area of the community. Thanks.

[JohnWhitmore 28]

Yay....

Looking forward to the next beta. I am currently running 4.7.0.25 (after update today).

[Albertax 14]

59 minutes ago, JohnWhitmore said:

Yay....

Looking forward to the next beta. I am currently running 4.7.0.25 (after update today).

Me too!

[JohnWhitmore 28]

Just in time for the phase out of VodafoneTV in NZ

[Luke 42077]

On 2/24/2022 at 2:14 AM, JohnWhitmore said:

Yay....

Looking forward to the next beta. I am currently running 4.7.0.25 (after update today).

It's headed up now. If you run the beta channel and you still see examples where you think it's not picking the highest quality, then please open a topic in the testing area of the community. Thanks.

[JohnWhitmore 28]

1 hour ago, Luke said:

It's headed up now. If you run the beta channel and you still see examples where you think it's not picking the highest quality, then please open a topic in the testing area of the community. Thanks.

Thank you. Will test this evening.

 

Just checked. Waiting for Synology version. So will have to wait slightly longer.

Edited February 26, 2022 by JohnWhitmore

[pünktchen 1409]

On 2/23/2022 at 8:41 PM, Luke said:

This will be implemented in the upcoming 4.7 server release. For those on the beta channel, that's 4.7.0.26+. If you run the beta channel and you still see examples where you think it's not picking the highest quality, then please open a topic in the testing area of the community. Thanks.

@Luke there was never any feedback from the users, so here is one: It's still not working! Emby still uses the first stream entry of a master.m3u8 instead of the one with the highest bandwith. Before you ask, no it also doesn't work in the latest beta server.

#EXTM3U
#EXT-X-VERSION:4
#EXT-X-INDEPENDENT-SEGMENTS
#EXT-X-STREAM-INF:BANDWIDTH=1672000,AVERAGE-BANDWIDTH=1460800,CODECS="avc1.4d401f,mp4a.40.2",RESOLUTION=640x360,FRAME-RATE=50.000,AUDIO="program_audio",SUBTITLES="subs"
master-360p-1200.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2182400,AVERAGE-BANDWIDTH=1900800,CODECS="avc1.4d401f,mp4a.40.2",RESOLUTION=960x540,FRAME-RATE=50.000,AUDIO="program_audio",SUBTITLES="subs"
master-540p-1600.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=4224000,AVERAGE-BANDWIDTH=3660800,CODECS="avc1.640020,mp4a.40.2",RESOLUTION=1280x720,FRAME-RATE=50.000,AUDIO="program_audio",SUBTITLES="subs"
master-720p-3200.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=6520800,AVERAGE-BANDWIDTH=5640800,CODECS="avc1.64002a,mp4a.40.2",RESOLUTION=1920x1080,FRAME-RATE=50.000,AUDIO="program_audio",SUBTITLES="subs"
master-1080p-5000.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1034000,AVERAGE-BANDWIDTH=910800,CODECS="avc1.4d401e,mp4a.40.2",RESOLUTION=480x270,FRAME-RATE=50.000,AUDIO="program_audio",SUBTITLES="subs"
master-270p-700.m3u8
#EXT-X-MEDIA:TYPE=AUDIO,LANGUAGE="deu",NAME="Stereo",AUTOSELECT=YES,DEFAULT=YES,GROUP-ID="program_audio",URI="master-stereo.m3u8"
#EXT-X-MEDIA:TYPE=AUDIO,LANGUAGE="mul",NAME="Original",AUTOSELECT=YES,DEFAULT=NO,GROUP-ID="program_audio",URI="master-original.m3u8"
#EXT-X-MEDIA:TYPE=AUDIO,LANGUAGE="klare sprache",NAME="Klare Sprache",AUTOSELECT=YES,DEFAULT=NO,GROUP-ID="program_audio",URI="master-ks.m3u8"
#EXT-X-MEDIA:TYPE=SUBTITLES,NAME="Deutsch",DEFAULT=YES,AUTOSELECT=YES,FORCED=NO,LANGUAGE="de",GROUP-ID="subs",URI="master-subs.m3u8"

ffmpeg-directstream-bcc4d037-0761-415d-a52d-5e54054a29d8_1.txtembyserver-63810719557.txt

[Luke 42077]

7 hours ago, pünktchen said:

@Luke there was never any feedback from the users, so here is one: It's still not working! Emby still uses the first stream entry of a master.m3u8 instead of the one with the highest bandwith. Before you ask, no it also doesn't work in the latest beta server.

#EXTM3U
#EXT-X-VERSION:4
#EXT-X-INDEPENDENT-SEGMENTS
#EXT-X-STREAM-INF:BANDWIDTH=1672000,AVERAGE-BANDWIDTH=1460800,CODECS="avc1.4d401f,mp4a.40.2",RESOLUTION=640x360,FRAME-RATE=50.000,AUDIO="program_audio",SUBTITLES="subs"
master-360p-1200.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2182400,AVERAGE-BANDWIDTH=1900800,CODECS="avc1.4d401f,mp4a.40.2",RESOLUTION=960x540,FRAME-RATE=50.000,AUDIO="program_audio",SUBTITLES="subs"
master-540p-1600.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=4224000,AVERAGE-BANDWIDTH=3660800,CODECS="avc1.640020,mp4a.40.2",RESOLUTION=1280x720,FRAME-RATE=50.000,AUDIO="program_audio",SUBTITLES="subs"
master-720p-3200.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=6520800,AVERAGE-BANDWIDTH=5640800,CODECS="avc1.64002a,mp4a.40.2",RESOLUTION=1920x1080,FRAME-RATE=50.000,AUDIO="program_audio",SUBTITLES="subs"
master-1080p-5000.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1034000,AVERAGE-BANDWIDTH=910800,CODECS="avc1.4d401e,mp4a.40.2",RESOLUTION=480x270,FRAME-RATE=50.000,AUDIO="program_audio",SUBTITLES="subs"
master-270p-700.m3u8
#EXT-X-MEDIA:TYPE=AUDIO,LANGUAGE="deu",NAME="Stereo",AUTOSELECT=YES,DEFAULT=YES,GROUP-ID="program_audio",URI="master-stereo.m3u8"
#EXT-X-MEDIA:TYPE=AUDIO,LANGUAGE="mul",NAME="Original",AUTOSELECT=YES,DEFAULT=NO,GROUP-ID="program_audio",URI="master-original.m3u8"
#EXT-X-MEDIA:TYPE=AUDIO,LANGUAGE="klare sprache",NAME="Klare Sprache",AUTOSELECT=YES,DEFAULT=NO,GROUP-ID="program_audio",URI="master-ks.m3u8"
#EXT-X-MEDIA:TYPE=SUBTITLES,NAME="Deutsch",DEFAULT=YES,AUTOSELECT=YES,FORCED=NO,LANGUAGE="de",GROUP-ID="subs",URI="master-subs.m3u8"

ffmpeg-directstream-bcc4d037-0761-415d-a52d-5e54054a29d8_1.txt 5.76 MB · 0 downloads embyserver-63810719557.txt 84.07 kB · 0 downloads

Right now it only applies when we parse the m3u ourselves. In this case we don't do that because it uses separate segments for audio and video, and so we have ffmpeg handle it. In that situation I think ffmpeg just chooses the first one. So I guess we'd have to look at customizing that code as well.

[pünktchen 1409]

9 hours ago, Luke said:

So I guess we'd have to look at customizing that code as well.

Yes, do so please!

[tmurphy2792 27]

Is there any update on getting this working? Or is this a limitation of ffmpeg that can't be worked around?
Wondering before I start down the xTeve rabbit hole.

[Luke 42077]

1 hour ago, tmurphy2792 said:

Is there any update on getting this working? Or is this a limitation of ffmpeg that can't be worked around?
Wondering before I start down the xTeve rabbit hole.

Depending on how the server handles the stream, this has already been done. When Emby Server handles it internally without ffmpeg, the highest quality stream gets picked. When we run it through ffmpeg, this might not always occur though. So it just depends on the type of stream, if our internal handling can process it, and if it can't, then it gets done via ffmpeg.

[tmurphy2792 27]

13 hours ago, Luke said:

Depending on how the server handles the stream, this has already been done. When Emby Server handles it internally without ffmpeg, the highest quality stream gets picked. When we run it through ffmpeg, this might not always occur though. So it just depends on the type of stream, if our internal handling can process it, and if it can't, then it gets done via ffmpeg.

Thanks @Luke, figured I'd double check since this post is a year old and it seems like you guys are always making improvements to the software.

For anyone else who finds the same issue I did and is looking for a solution. @Carlo is correct xTeve is the solution.
I followed the instructions for setting it up, then in the settings I turned on stream buffering and set VLC to handle it. (See screenshot) This results in the initial low quality stream being used at first, but after a second or so it jumps to the highest quality.

There might be better or more efficient ways to do it with the filtering so that you don't have to enable buffering, but this worked for me so I'm content with the results.

[tmurphy2792 27]

I hope it's OK that I post this update here. I figure others might end up in my situation and find this thread, so want to post what I found to be a good solution for forcing Emby to use the highest quality m3u stream.

After more testing my above post was only partially a solution, it worked great for watching live, but the Emby DVR did NOT like that and it caused some weird misbehavior of the server and ffmpeg every time a recording failed.
My guess is the DVR didn't like that it would start on one stream with one resolution and everything, then suddenly bait and switch to the higher quality stream at a different resolution.

That being said, xTeve was still the solution, it just required some additional help from a software called Streamlink. Basically you set up streamlink in place of where you should set up ffmpeg in xTeve.
I won't bother going into too much details though, these posts here give you all the information you'll need if you're trying to set this up. I literally followed the example the user "back-to" gave verbatim and it worked like a charm, the stream immediately starts at the highest resolution now.

https://github.com/streamlink/streamlink/discussions/3430

[tree2369 16]

On 01/02/2024 at 01:37, tmurphy2792 said:

Thanks @Luke, figured I'd double check since this post is a year old and it seems like you guys are always making improvements to the software.

For anyone else who finds the same issue I did and is looking for a solution. @Carlo is correct xTeve is the solution.
I followed the instructions for setting it up, then in the settings I turned on stream buffering and set VLC to handle it. (See screenshot) This results in the initial low quality stream being used at first, but after a second or so it jumps to the highest quality.

There might be better or more efficient ways to do it with the filtering so that you don't have to enable buffering, but this worked for me so I'm content with the results.

Old thread I know but if anyone stumbles across this, the latest ffmpeg version (7.0.1 at this time) seems to do a better and quicker job of selecting the highest stream available when used as a buffer, than when you use VLC as a buffer.

 

Seems to be a more delay and an initial low quality stream with VLC, where as ffmpeg jumps straight to the highest and much quicker by my eye.

[tmurphy2792 27]

On 7/27/2024 at 4:58 AM, tree2369 said:

Old thread I know but if anyone stumbles across this, the latest ffmpeg version (7.0.1 at this time) seems to do a better and quicker job of selecting the highest stream available when used as a buffer, than when you use VLC as a buffer.

 

Seems to be a more delay and an initial low quality stream with VLC, where as ffmpeg jumps straight to the highest and much quicker by my eye.

Good to know, in my latest post I pointed out VLC wasn't actually a good solution. The quality change crashed recording functionality.

I ended up using streamlink as my buffer because I'm able to configure a parameter to force highest quality right off the bat. not a perfect solution, starting up a stream is slow and sometimes fails for no reason, but it works better than watching in 240p or whatever.

 

Hopefully eventually as new stable builds of ffmpeg come out this will just work natively in emby.