Fix HEVC playback on Hisense Vidaa OS

[abdulmueid]

Vidaa OS web browser reports it supports HEVC but playback is extremely glitchy (See links below).
Tested on 2 models (Hisense U7 & U8). This commit disables HEVC on Vidaa OS browser profile to stop HEVC Direct Play and allows transcoding HEVC files without resorting to very low bitrates to trigger transcoding.

Before

After

Without this fix, only way to play videos on Hisense TVs with Vidaa OS is to set the bitrate below the video's native bitrate to trigger transcoding which often takes the video in to 480p and below territory and is not watchable.

Changes
Changed the canPlayHevc(...) function in browserDeviceProfile to return false when it detects browser.vidaa
This essentially tells rest of the Jellyfin-web client that Vidaa does not support HEVC, therefore allowing transcoding at native video resolution.

Issues

[dmitrylyzo]

Both models claim to support HEVC. 🤷‍♂️

Could it be a weird encoding of the file?
Or maybe codec profile/level?
Do other HEVC files work (another show or movie)?

[nyanmisaka]

MKV + DirectPlay in a web browser? VIDAA's documentation says they require ISO BMFF (MPEG4).

@abdulmueid Maybe you should remux your video to an MP4 container and try again.

[abdulmueid]

Both models claim to support HEVC. 🤷‍♂️

Could it be a weird encoding of the file? Or maybe codec profile/level? Do other HEVC files work (another show or movie)?

@dmitrylyzo Exactly, they both do support HEVC. When playing the same files off a USB drive, they play fine. But when in a browser, they glitch out.

My content is mostly HEVC 10-bit at 1080p or 4K in MKV containers.
I will try out some other HEVC profiles and put the files in MP4 containers as suggested by @nyanmisaka to check if they fail in the browser too.

Ultimately, for the user-experience, I think it should work without requiring any remuxing or additional steps. In my case, the best scenario is to transcode on-the-fly. If Jellyfin allowed force transcoding without dropping the bitrate to below native, this whole PR would not be needed.

[nyanmisaka]

If MP4 works fine, then we just need to explicitly disable MKV Direct Play for browser.vidaa to trigger the remuxing.

[abdulmueid]

If MP4 works fine, then we just need to explicitly disable MKV Direct Play for browser.vidaa to trigger the remuxing.

I remuxed a video from MKV to MP4 and it direct played perfectly. You were 100% right about the container. I will make the change to update the testCanPlayMkv(...) function and test again before updating the PR. Thanks for the guidance.

P.S. Is there a possibility for Jellyfin to Remux MKV to MP4 for Vidaa devices instead of transcoding? Remuxing a lot faster and less resource intensive than transcoding and would be the ideal scenario for these videos. I will do some digging to see if that can be done.

Here is some evidence of Vidaa playing HEVC Main 10 profile in MP4 container:

[abdulmueid]

Found a related issue for remuxing/transcoding:
jellyfin/jellyfin#10549

Just posting here for reference.

[nyanmisaka]

testCanPlayMkv() => Direct Play MKV

!testCanPlayMkv() && preferFmp4HlsContainer => Remux MKV to fMP4
(you have to add browser.vidaa to the supported list)

[jellyfin-bot]

Cloudflare Pages deployment

Latest commit	316542c
Status	✅ Deployed!
Preview URL	https://76a271cf.jellyfin-web.pages.dev
Type	🔀 Preview

View build logs

[abdulmueid]

testCanPlayMkv() => Direct Play MKV

!testCanPlayMkv() && preferFmp4HlsContainer => Remux MKV to fMP4 (you have to add browser.vidaa to the supported list)

I did the following:

1. Added if (browser.vidaa) { return false } in testCanPlayMkv() to force disable mkv playback
2. Enabled preferFmp4HlsContainer from Playback settings

The video fails to play, however, in the logs I see that FFMpeg is remuxing with errors. Here is the log:
FFmpeg.Remux-2024-10-17_23-45-09_9a25dd2cfde05e6fb10dd7fbf9d71c8f_820f7743.log

I see a number of errors like [mp4 @ 0x55b41c0d3380] Packet duration: -16 / dts: 73591880 is out of range. I tried searching but did not get very far.

I did not understand the bit about adding to supported list. The line you pointed out disables mp4Hls if it's not natively supported on safari, webOs and tizen. I changed the line regardless to test and it had no effect. Unless i'm missing something, i'd be happy for feedback.

Any ideas where to go from here? Personally I am happy to disable mkv support and use transcoding for hevc playback without fmp4 remuxing.

[abdulmueid]

Quick update: hlsInTs works well when disabling MKV. So the only two changes required are:

1. Disable MKV playback
2. Add browser.vidaa to the list of browsers when pushing hevc to hlsInTsVideoCodecs list.

There is no need to enable hlsInFmp4.

Branch updated. Please review and suggest any other required changes.

[nyanmisaka]

LGTM. Many TVs prefer HEVC in MPEG-TS over fMP4, and it looks like browser.vidaa is no exception.

It is better to change the PR name to "Fix smth on smth" and squash commits into one before merging. Also, you don't need to rebase to the latest branch unless there are merge conflicts.

[abdulmueid]

@nyanmisaka thanks for the go-ahead. I have renamed the PR and squashed commits.
Ready to merge.

[nyanmisaka]

@nyanmisaka thanks for the go-ahead. I have renamed the PR and squashed commits. Ready to merge.

There is nothing I can do here. You need to wait for the web team to approve and merge.

[sonarcloud]

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 SonarCloud