WebOS with hls.js

[timitt]

I made pull request https://github.com/jellyfin/jellyfin-web/pull/6678

I also changed my own repository to use official hls.js 1.6.0 release.

[Ereb_Zx]

Enabling fMP4 also breaks subtitles sync. https://github.com/jellyfin/jellyfin-webos/issues/253
This happens with your jellyfin-web modded build as well, when audio is being transcoded to AAC, after fast forwarding, subtitles get out of sync, or precisely media gets out of sync. It's another strange issue, so far mitigated by using .ts.

[timitt]

I tried several videos that had subrip subtitles and I could not replicate that issue. I use subtitles all the time and I have not noticed that issue at all before either. Also the ticket you mention says that he has fMP4 disabled and only the person who replies has it enabled.

What kind of media you have that causes the issue? And what TV and WebOS version you have?

[raulo1985]

Enabling fMP4 also breaks subtitles sync. https://github.com/jellyfin/jellyfin-webos/issues/253
This happens with your jellyfin-web modded build as well, when audio is being transcoded to AAC, after fast forwarding, subtitles get out of sync, or precisely media gets out of sync. It's another strange issue, so far mitigated by using .ts.

Hi. Thanks for this fix, I have a LG C2 Smart TV with the official Jellyfin app and I can say that using hls.js indeed fixed (so far) an issue I had while fast forwarding or seeking (basically it just kept loading, with hls.js it works as expected). I'm using your last modified jellyfin-web (I compiled it from source), so using hls.js 1.6.0. Haven't had issues with playback (neither direct playing or transcoding), audio or subtitles. I can say that everything is working as expected now, and not being able to fast forward or seek properly was an important issue for me. So thanks for that!

A question regarding using fMP4. So far you've suggested to leave it enabled when using hls.js. I've always had it disabled regardless of the client (in my case, WebOS, JMP and iOS app), and never had an issue. And I've also read here at the forums that it's recommended to disable it when using the WebOS app, apparently there's an issue/bug when using fMP4 on that specific client (maybe regarding native hls?). When I used your modded jellyfin-web and tested it with my TV, I didn't have an issue, and I tested it with fMP4 disabled. Do you still recommend to enable it when using hls.js? So far I've mostly tested it with direct play, just only a couple of transcodes (so I can't really say for sure that your fix works as expected when transcoding in all scenarios yet).

Thanks in advance!

[Ereb_Zx]

I tested it again, and yes there is still a subtitle sync issue when using fMP4with your modified jellyfin-web. It starts playing correctly, then after a few seeks back and forth, subtitle gets ahead of the video and audio. It's faster to replicate the issue with an external .srt (but it happens with embedded .srt too, just takes a few more seeks). I replicated the issue with a DV P8 mkv file and both embedded and external .srt subtitle.

Regardless of this issue, I remember one more that is present when using fMP4 with the official jellyfin-web, and that is that it doesn't apply audio delay if it exists in an mkv file. This mkv file has DV P8 video and EAC3 audio from a different source, that is delayed 2s2ms to the video. This is what mediainfo looks like.

That delay is completely ignored when using fMP4, so audio plays out of sync. I replicated the same issue with your modified jellyfin-web.

Just to be clear, both of those issues are present currently in the official build when using fMP4 and were not caused by using hls.js. As of now, in the official version, the only way around those issues is remuxing to .ts container instead of .mp4, which gives us dolby vision, stable playback and fast forwarding, synced subtitles, and applied audio delay if it exist in a .mkv file, but also gives us false (?) Atmos and stereo sound only. Using your modified jellyfin-web and fMP4 we get fixed dolby vision p8, multichannel audio (without atmos) and stable fast forwarding, but we reintroduce issues with subtitle getting out of sync and ignored audio delay. We also lose dolby vision completely when using .ts container. 

I tested on LG C2, WebOS 23.20.62. Jellyfin server for Windows 10.10.6 and latest WebOS client.

[timitt]

I don't think Dolby Vision content is working if fMP4 is disabled with hls.js (at least profile . That is the main reason for me to recommend enabling fMP4.

Funnily enough that might be the main reason to disable fMP4 when using WebOS native HLS.

[timitt]

I tested it again, and yes there is still a subtitle sync issue when using fMP4with your modified jellyfin-web. It starts playing correctly, then after a few seeks back and forth, subtitle gets ahead of the video and audio. It's faster to replicate the issue with an external .srt (but it happens with embedded .srt too, just takes a few more seeks). I replicated the issue with a DV P8 mkv file and both embedded and external .srt subtitle.

Regardless of this issue, I remember one more that is present when using fMP4 with the official jellyfin-web, and that is that it doesn't apply audio delay if it exists in an mkv file. This mkv file has DV P8 video and EAC3 audio from a different source, that is delayed 2s2ms to the video. This is what mediainfo looks like.

That delay is completely ignored when using fMP4, so audio plays out of sync. I replicated the same issue with your modified jellyfin-web.

Just to be clear, both of those issues are present currently in the official build when using fMP4 and were not caused by using hls.js. As of now, in the official version, the only way around those issues is remuxing to .ts container instead of .mp4, which gives us dolby vision, stable playback and fast forwarding, synced subtitles, and applied audio delay if it exist in a .mkv file, but also gives us false (?) Atmos and stereo sound only. Using your modified jellyfin-web and fMP4 we get fixed dolby vision p8, multichannel audio (without atmos) and stable fast forwarding, but we reintroduce issues with subtitle getting out of sync and ignored audio delay. We also lose dolby vision completely when using .ts container. 

I tested on LG C2, WebOS 23.20.62. Jellyfin server for Windows 10.10.6 and latest WebOS client.

Ok. I tried quite a few times to fast forward and go back, but that issue just did not happen. Although my subtitles were embedded. I rarely do that kind of fast forwarding and rewinding in real life use. But sure enough it is issue if it happens (and I do believe you even if I failed to repeat it). To me that is much smaller issue than that audio issue if that needs little bit trying to get it happen.

This delay issue is true. I have similar video myself. I did not realise that it is not issue when using TS. It seems to me that this breaks when ffmpeg converts the file. I tried to make fMP4 stream manually (using parameter that Jellyfin uses) and when I try to play that stream using MPC-HC on Windows I get broken delay. Not sure if there is something that can be done on command line that would fix the issue.

But using .ts container and native hls does cause some fast forwarding issues. It not constant but it certainly happens.

We probably don't get perfect results at all because WebOS is broken no matter what we do.

[Ereb_Zx]

I remember when 10.10.0 released, it was a huge update and the first to do remuxing of DV content for WebOS devices. The default setting was fMP4 enabled so all DV content would remux to mp4. The fast forwarding issue was apparent right away, but there were also subtitle sync issues that were unpredictable and hard to notice, but surely present. Sometimes just pausing and resuming would get subtitles to play instantly, while video and audio would play a few seconds later, getting out of sync. If you were to try to continue watching a movie, it would most likely fail to play all together, or play subtitles right away, video and audio a few seconds later so they get out of sync again. They are still present in current build, as well as your custom build, and probably related to WebOs and how it handles mp4. After a few versions, the fMP4 was disabled by default so we use .ts now, which is much more stable on WebOs.

I have seen reports of people claiming that Profile 8 is broken even with using .ts container, which I can't replicate myself. I can confirm that it doesn't work with .mp4, but for me it does work well with .ts. There were a handful of times when i got a corrupted .mkv file with Profile 8, that would seem all right and play on windows, but not play on LG C2 even when converted manually to .ts or .m2ts and played from a usb drive. They would play when manually converted to mp4 for some time, but then TV would shut off by itself while playing. I downloaded the files from a different source and had no issues using Jellyfin again. So I guess that might be what is behind those claims, but again, a regular DV P8 file in mkv plays fine on LG C2 when remuxed to .ts.

[timitt]

I almost always use subtitles and also pause quite a lot. I have never seen subtitle desync with neither version (official native hls or hls.js). And I would have noticed if that had happened. I have seen that issue in Github before you mentioned it, but I still have not seen it happen. I do not fast forward or rewind much though. But pause is used quite a lot.

To me profile 8 has worked fine with .ts container when using native hls (and only with .ts). With hls.js it requires fMP4. That's not why I recommend enabling hls.js on WebOS.

The thing is that remuxing is completely useless feature if it makes multichannel audio to be just stereo. The thing that in some relatively rare cases subtitle sync might break if you repeatedly pause, fast forward or rewind is quite small issue. Also it seems that freezing fast forwarding is as common as subtitle issue, but on the contary my version fixes that while it is present when using .ts containers with native hls.

That audio delay issue is another issue, but it seems to be completely different bug in Jellyfin or ffmpeg and not related to hls.js or WebOS. I might be wrong, but I think that having delayed audio in mkv is not common feature (I have encountered such video just once).

[timitt]

I did some tests about that audio delay. It certainly is problem with ffmpeg. If audio does not start until first segment file is finished it just wont work. Nothing to do with hls.js or Jellyfin or WebOS. Ffmpeg prints notification about issue, but creates files. If I have just copied the audio to stream then the stream is completely broken (at least for MPC-HC) but if we transcode it then it creates playable files but there is wrong timing.

If I use ffmpeg to create mpegts stream then it works in both cases (copy or transcode).

Also if I make segments larger (by setting hls_time bigger) then delay fits to first segment file and then fmp4 stream works in both cases (copy or transcode).

EDIT: I found one way to solve that audio delay issue with fMP4 too. But it seems to require using separate audio and video streams like in my first mail. You just need to add -movflags delay_moov to audio stream. I just doubt separating the streams won't happen anytime soon (or ever).