Enable hls.js with WebOS

[timitt]

Changes
This patch will put hls.js in use when using LG WebOS 4 or newer. Native HLS in WebOS seems to be broken in many ways. Worst way is that it breaks multichannel audio and everything plays as stereo. External amplifiers that are connected to TV through HDMI ARC or Toslink fail to show Dolby Digital marking no matter what channel count is forced to be used when native HLS is in use.

Note that we need 1.6.0 or newer version of hls.js to use this patch if we want Dolby Vision 8 to work.
Hls.js 1.6.0 now supports supplemental codecs and it also has much better support for Dolby Vision files generally.

Also note that users should enable use of fMP4 when this patch is enabled unlike with native hls.

Possible negatives with this patch is the fact that we need to transcode AC-3 and EAC-3 when HLS is needed as WebOS MSE does not support playing videos with those audio codecs.
It also kills Dolby Atmos, but I am not sure if it worked correctly with native hls either (at least it did not work when using HDMI ARC).
There is possible solution for that too here: https://forum.jellyfin.org/t-webos-with-hls-js

Issues

Fixes jellyfin/jellyfin-webos#275
Fixes #6522

Probably fixes jellyfin/jellyfin-webos#248
Probably fixes jellyfin/jellyfin-webos#285
Probably fixes jellyfin/jellyfin-webos#284

Relates jellyfin/jellyfin-webos#278
Relates jellyfin/jellyfin-webos#274
Relates jellyfin/jellyfin-webos#262
Relates #6533
Relates #6484

[jellyfin-bot]

Cloudflare Pages deployment

Latest commit	0318e1e
Status	✅ Deployed!
Preview URL	https://9c22401d.jellyfin-web.pages.dev
Type	🔀 Preview

View build logs

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[timitt]

What does this "needs testing" mean? Looking other "needs testing" pull requests does not bring any hopes up.

I have used weeks to test this with different scenarios (and I helped to make hls.js to handle Dolby Vision better to make this patch feasible). There seems to be at least few who have tested it on forum post that is mentioned in my pull request. Even though there is one person who does not seem to be fond of it.

[GDXbsv]

It works for me. Please consider it as testing.

[sundermann]

Possible negatives with this patch is the fact that we need to transcode AC-3 and EAC-3 when HLS is needed as WebOS MSE does not support playing videos with those audio codecs.

This is probably a bug in either ffmpeg or hls.js. Looking at the chromium sources webOS MSE does support AAC, MP3, Vorbis, AC3, EAC3, OPUS, FLAC, AC4, DTS(E/X) (only on select models). Supported video codecs are H264/5 VP8/9.

[timitt]

Possible negatives with this patch is the fact that we need to transcode AC-3 and EAC-3 when HLS is needed as WebOS MSE does not support playing videos with those audio codecs.

This is probably a bug in either ffmpeg or hls.js. Looking at the chromium sources webOS MSE does support AAC, MP3, Vorbis, AC3, EAC3, OPUS, FLAC, AC4, DTS(E/X) (only on select models). Supported video codecs are H264/5 VP8/9.

Problem is WebOS. If you use isTypeSupported for audio/mp4; codecs="whatever" then you get true in those formats. If you use isTypeSupported for video/mp4; codecs="whatever-video,whatever-audio" then supported audio codecs are much more limited. For that reason MSE does not play videos with AC3, but it does play plain audio with AC3.

I have talked about this issue on mentioned forum post and also on first "fixes" ticket I list.

Also the solution would be to separate audio and video to their own mp4 streams (which hls allows). That would solve also other problems.

Fixing that problem is just not required to make this pull request a must have for every WebOS user that have multichannel audio system at home.

[sundermann]

Problem is WebOS. If you use isTypeSupported for audio/mp4; codecs="whatever" then you get true in those formats. If you use isTypeSupported for video/mp4; codecs="whatever-video,whatever-audio" then supported audio codecs are much more limited. For that reason MSE does not play videos with AC3, but it does play plain audio with AC3.

Maybe it's just the check that's broken? Did you try removing isTypeSupported from hls.js?

[timitt]

Problem is WebOS. If you use isTypeSupported for audio/mp4; codecs="whatever" then you get true in those formats. If you use isTypeSupported for video/mp4; codecs="whatever-video,whatever-audio" then supported audio codecs are much more limited. For that reason MSE does not play videos with AC3, but it does play plain audio with AC3.

Maybe it's just the check that's broken? Did you try removing isTypeSupported from hls.js?

Yes, I have tried to ignore check, but actual playback request using MSE does not work with eac3 either.

EDIT: unless there is some sort of trick with addSourceBuffer not taking mimeType or taking some sort of generic text. I have given that function a proper mimeType and it still fails with eac3. I can't remember if I tested to just give video/mp4 without codecs. Maybe I need to test again.

EDIT2 (to not fill this pull request with too many messages): Settings mimetype as video/mp4 without listing codecs is error on Chromium including WebOS Chromium. So I have no idea how I could try to start MSE playback without giving codec that it marks as unsupported.

[Skin80]

Is there any update to this being implemented?

[timitt]

Is there any update to this being implemented?

I don't know what I can do to make this reviewed.

There is not much code to there, but quite a lot of testing to make sure it is good patch to offer. I have also explained why it is made like that and so on (here and in that forum thread).

Of course I am not able to test other WebOS televisions (and WebOS versions) than my own so there is that.