fix(subtitles): Correction for subtitle shifts when transcoding #7414
Conversation
Signed-off-by: Leó Takács <[email protected]>
Cloudflare Pages deployment
|
…ntext Signed-off-by: Leó Takács <[email protected]>
Signed-off-by: Leó Takács <[email protected]>
|
|
Does this actually work? The issue is Jellyfin tells ffmpeg to start transcoding at a specific time (say 10:00) however it provides it the -noaccurate_seek flag, so ffmpeg will actually start the transcoding at the closest keyframe to 10:00, which may actually be 09:48 This then starts streaming to the web client, so the hls player will think its playing 10:00, however the transcoded media actually starts at 09:48. Im unsure how this code would solve that problem, and if we did want to solve the problem it would be better to fix it on the server side, not applying a hacky patch onto the web client no? |
|
After trying with many different media sources I think it does work. I admit that this is kind of a hacky patch, but while we cannot make changes to the server code itself due to the FFmpeg mess, we can mitigate the effects a bit. I'm sure this fix could be improved further, but I'm not yet sure if it's worth going down that path. Feedback would be appreciated.
The player thinks it has encountered a discontinuity in the stream and continues as normal with the fragments. It will know exactly what the offset was and provides an easy way of bearing with the problem through an event after the discontinuity and the offset provided (as initPTS). I think FFmpeg might be doing its work as intended (the -noaccurate_seek DOES suggest a non accurate seek) and the culprit could be the HLS.js library itself. I will look further into their implementation and what could be done. |
3 participants
Fixed #7413 submitted by me
Cause
The problem was that the native video player did not follow the changes made to the initial PTS while playing an HLS stream. This caused a desync in the original subtitle timings and the HLS library's current time and the subtitles were display a few seconds off. This usually only happened while playing transcoded content after a seek was made.
Changes
Hooked up a listener to the INIT_PTS_FOUND event of the HLS library, that fires, when the initial PTS value changes. I keep track of the shift overtime and apply a correctional offset to the start and end times of the current text track's cues each time. Now when loading a new text track, it auto-adjusts the start times for the cues. This implementation does not interfere with the existing manual subtitle shifting mechanism.
Note
I attempted a fix for my current instance, while testing in multiple browsers, tho I'm not sure if I covered all possible scenarios for on-client subtitle displaying. Further testing might be needed.
Issues
#7413