starred/jellyfin

Fork 0

mirror of https://github.com/jellyfin/jellyfin.git synced 2026-01-23 23:20:51 +01:00

noaccurate_seek breaks subtitle synchronisation #7940

New issue

Open

opened 2025-12-22 06:32:17 +01:00 by backuprepo · 3 comments

backuprepo commented

2025-12-22 06:32:17 +01:00

Owner

Originally created by @abitofevrything on GitHub (Dec 20, 2025).

Description of the bug

Jellyfin passes -noaccurate_seek to FFmpeg when transcoding to HLS. This means that when seeking ahead in a video and causing a new transcode to start (which therefore passes the -ss parameter), the HLS segments are not precisely aligned with the video timestamp - the timestamp in the new HLS stream may be a few seconds offset from the timestamp in the original video.

For clients that render their own subtitles based on the video timestamp, this means subtitles are offset, and the offset changes whenever a seek occurs.

I can't find the original reason why this parameter was added. It seems that since it has been added there has been one instance of the parameter being required (#7435), but that PR doesn't actually provide details on how to reproduce the issue it is fixing. On the other hand, there have also been bugs that result from this flag being added, including this subtitle bug, which may be the cause of several issues raised on the jellyfin repos (#7338, https://github.com/jellyfin/jellyfin-web/issues/7413, https://github.com/jellyfin/jellyfin-web/issues/6210, https://github.com/jellyfin/jellyfin-web/issues/6210, https://github.com/jellyfin/jellyfin-web/issues/4346, https://github.com/jellyfin/jellyfin/issues/2547).

Is there any reason to keep this flag? I can see why it needs to be kept in the case of #7435, but the check added in that PR seems to be too large and is causing quite a few problems elsewhere. I was going to submit a PR that simply narrows the check to only add -noaccurate_seek when dealing with the issue encountered in that PR, but without repro instructions, I can't.

I'd want to remove the flag entirely myself but I don't want to risk breaking jellyfin for others. I have patched my server and the subtitle sync issues I was having on iOS, web, and Android have all disappeared since.

Reproduction steps

Play any media with subtitles rendered by the client and HLS transcoding
Seek beyond the buffered range
Subtitles are desynced.

What is the current bug behavior?

Subtitles are desynced.

More accurately, the transcoded video is not aligned with the player timestamp, which causes subtitle desync (the transcoded video is the one with the wrong timestamp, not the player).

What is the expected correct behavior?

Subtitles should be synced.

Jellyfin Server version

10.11.5

Specify commit id

No response

Specify unstable release number

No response

Specify version number

No response

Specify the build version

10.11.5

Environment

- OS: Ubuntu 24.04.3 LTS (containerized)
- Linux Kernel: Linux 6.17.8-arch1-1
- Virtualization: Docker
- Clients: Jellyin Web on Chrome, Jellyfin for Android, Jellyfin for iOS (iPad)
- Browser: Chrome
- FFmpeg Version: 7.1.3-Jellyfin
- Playback Method: Transcode
- Hardware Acceleration: QSV, vaapi, none
- CPU Model: Intel(R) Celeron(R) N4120 CPU @ 1.10GHz
- GPU Model: Intel UHD Graphics 600
- Plugins: None
- Reverse Proxy: nginx
- Base URL: (none)
- Networking: Docker bridge
- Jellyfin Data Storage & Filesystem: ext4 SSD
- Media Storage & Filesystem: btrfs HDD
- External Integrations: none

Jellyfin logs

None

FFmpeg logs

None

Client / Browser logs

No response

Relevant screenshots or videos

No response

Additional information

No response

Originally created by @abitofevrything on GitHub (Dec 20, 2025). ### Description of the bug Jellyfin [passes `-noaccurate_seek` to FFmpeg when transcoding to HLS](https://github.com/jellyfin/jellyfin/blob/master/MediaBrowser.Controller/MediaEncoding/EncodingHelper.cs#L2947). This means that when seeking ahead in a video and causing a new transcode to start (which therefore passes the `-ss` parameter), the HLS segments are not precisely aligned with the video timestamp - the timestamp in the new HLS stream may be a few seconds offset from the timestamp in the original video. For clients that render their own subtitles based on the video timestamp, this means subtitles are offset, and the offset changes whenever a seek occurs. I can't find the original reason why this parameter was added. It seems that since it has been added there has been one instance of the parameter being required (#7435), but that PR doesn't actually provide details on how to reproduce the issue it is fixing. On the other hand, there have also been bugs that result from this flag being added, including this subtitle bug, which may be the cause of several issues raised on the jellyfin repos (#7338, https://github.com/jellyfin/jellyfin-web/issues/7413, https://github.com/jellyfin/jellyfin-web/issues/6210, https://github.com/jellyfin/jellyfin-web/issues/6210, https://github.com/jellyfin/jellyfin-web/issues/4346, https://github.com/jellyfin/jellyfin/issues/2547). Is there any reason to keep this flag? I can see why it needs to be kept in the case of #7435, but the check added in that PR seems to be too large and is causing quite a few problems elsewhere. I was going to submit a PR that simply narrows the check to only add `-noaccurate_seek` when dealing with the issue encountered in that PR, but without repro instructions, I can't. I'd want to remove the flag entirely myself but I don't want to risk breaking jellyfin for others. I have patched my server and the subtitle sync issues I was having on iOS, web, and Android have all disappeared since. ### Reproduction steps 1. Play any media with subtitles rendered by the client and HLS transcoding 2. Seek beyond the buffered range 3. Subtitles are desynced. ### What is the current _bug_ behavior? Subtitles are desynced. More accurately, the transcoded video is not aligned with the player timestamp, which causes subtitle desync (the transcoded video is the one with the wrong timestamp, not the player). ### What is the expected _correct_ behavior? Subtitles should be synced. ### Jellyfin Server version 10.11.5 ### Specify commit id _No response_ ### Specify unstable release number _No response_ ### Specify version number _No response_ ### Specify the build version 10.11.5 ### Environment ```markdown - OS: Ubuntu 24.04.3 LTS (containerized) - Linux Kernel: Linux 6.17.8-arch1-1 - Virtualization: Docker - Clients: Jellyin Web on Chrome, Jellyfin for Android, Jellyfin for iOS (iPad) - Browser: Chrome - FFmpeg Version: 7.1.3-Jellyfin - Playback Method: Transcode - Hardware Acceleration: QSV, vaapi, none - CPU Model: Intel(R) Celeron(R) N4120 CPU @ 1.10GHz - GPU Model: Intel UHD Graphics 600 - Plugins: None - Reverse Proxy: nginx - Base URL: (none) - Networking: Docker bridge - Jellyfin Data Storage & Filesystem: ext4 SSD - Media Storage & Filesystem: btrfs HDD - External Integrations: none ``` ### Jellyfin logs ```shell None ``` ### FFmpeg logs ```shell None ``` ### Client / Browser logs _No response_ ### Relevant screenshots or videos _No response_ ### Additional information _No response_

backuprepo added the

bug

label 2025-12-22 06:32:17 +01:00

backuprepo commented

2025-12-22 06:32:20 +01:00

Author

Owner

@gnattu commented on GitHub (Dec 21, 2025):

Because without this you break audio/video synchronization in fmp4.

@gnattu commented on GitHub (Dec 21, 2025): Because without this you break audio/video synchronization in fmp4.

backuprepo commented

2025-12-22 06:32:22 +01:00

Author

Owner

@abitofevrything commented on GitHub (Dec 21, 2025):

That is indeed what the comment in the code says. But like I mentioned, I have been unable to reproduce this problem (I tried Safari and webviews on iOS, as that is where the commit says the issue appeared, but I also haven't seen it on any of the other platforms I tried).

On the other hand, this option is causing issues for many other users - just see the issues I linked above.

So my question is actually why are we keeping an option that fixes an issue nobody is able to reproduce, when that same option is causing known issues elsewhere?

@abitofevrything commented on GitHub (Dec 21, 2025): That is indeed what the comment in the code says. But like I mentioned, I have been unable to reproduce this problem (I tried Safari and webviews on iOS, as that is where the commit says the issue appeared, but I also haven't seen it on any of the other platforms I tried). On the other hand, this option _is_ causing issues for many other users - just see the issues I linked above. So my question is actually why are we keeping an option that fixes an issue nobody is able to reproduce, when that same option is causing known issues elsewhere?

backuprepo commented

2025-12-22 06:32:23 +01:00

Author

Owner

@gnattu commented on GitHub (Dec 21, 2025):

On the other hand, this option is causing issues for many other users - just see the issues I linked above.

That's not true. A lot of the issues you mentioned is not related to this option. If it was that easy those issues would be fixed long time ago. You can verify this by yourself for ANY cases that transcoding caused de-synced subtitles. The de-synced ones will still be de-synced.

So my question is actually why are we keeping an option that fixes an issue nobody is able to reproduce, when that same option is causing known issues elsewhere?

Actually things is a bit different recently as Safari properly implemented non-keyframe seeking but for non-safari web browsers the issue is still there, for fmp4, audio trancoded + video copy, so the "direct stream" case.

In this case, when you are using a browser using hls.js like chrome, and you seeked to a position that is not yet be transcoded, you would see that the video frame jumps back and forth for a few seconds and then return to normal. In worst case the playback might just hang, if the video has high enough bitrate, or running audio totally out of sync after this happened. In case you might find it hard to reproduce, I made an example here:

https://github.com/user-attachments/assets/3530fb11-94d7-497e-932f-3a3a22c6065e

@gnattu commented on GitHub (Dec 21, 2025): > On the other hand, this option is causing issues for many other users - just see the issues I linked above. That's not true. A lot of the issues you mentioned is not related to this option. If it was that easy those issues would be fixed long time ago. You can verify this by yourself for ANY cases that transcoding caused de-synced subtitles. The de-synced ones will still be de-synced. > So my question is actually why are we keeping an option that fixes an issue nobody is able to reproduce, when that same option is causing known issues elsewhere? Actually things is a bit different recently as Safari properly implemented non-keyframe seeking but for non-safari web browsers the issue is still there, for fmp4, audio trancoded + video copy, so the "direct stream" case. In this case, when you are using a browser using hls.js like chrome, and you seeked to a position that is not yet be transcoded, you would see that the video frame jumps back and forth for a few seconds and then return to normal. In worst case the playback might just hang, if the video has high enough bitrate, or running audio totally out of sync after this happened. In case you might find it hard to reproduce, I made an example here: https://github.com/user-attachments/assets/3530fb11-94d7-497e-932f-3a3a22c6065e

backuprepo referenced this issue

2025-12-22 08:43:22 +01:00

[PR #7940] [MERGED] Fix recommendations #11392

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: starred/jellyfin#7940

No description provided.

Rows
Columns