[jpsdr]

Hello. I'll explain the context/situation, and then after provided the tests results i've got, they are strange.

I've a video MKV file, and an SRT subtitles file. It doesn't exist, for my langage, a correct sync version of the subtitles matching the video. So what i'm doing, is sync the begining of the subtitles with the begining of the video. This way, subtitles are in perfect sync until... first commercial break. At this time, i adjust on the fly the timing shift of subtitles, and after subtitles are again in perfect sync until... next commercial break.
Most of the time, each shift is around 1s or 2s, no issues in that case. But, on some rare cases, each shift is around 8s or 9s, creating a shift of more than 30s after the 4th commercial break, basicaly around the 2/3 or 3/4 of the episode. This is where problem occurs.

These are almost TV series episodes, and i watch them on my PCH A-410. I've noticed that when time shift is more thant 30s, subtitles are just not displayed anymore. After several feedback with technical support, and some tests, the final result is the following :
If subtitles are muxed within the MKV (with last version of mkvmerge), time shift of more than 30s is not working, but if subtitles are not muxed within the MKV, and are in a SRT file having the same name than the video file, shift of more than 30s is working perfectly fine.

So, i've decided to test the MKV file with subtitles muxed with VLC. Setting a subtitle shift of 32s has resulted in VLC almost freezing, not playing video anymore...

And also, i've decided to test the MKV file with subtitles muxed with Kodi (a recent Jarvis nighty build). Result was the same than with the PCH : The subtitles were just not displayed anymore with a shfit of 32s.

So, my question is for the devs who knows the play, MKV and subtitles.
Either PCH, VLC and Kodi use the same library to handle MKV, and this one has a bug preventing timing shift of subtitles more than 30s, either there is something a lot more subtle/hidden, either it's another mystery of the universe. Having

So, i'm curious about any feedback or information you can provide me, i found these results very strange and surprising.

[FernetMenta]

Maybe mkvmerge does something wrong. If it just adds an offset to pts and those packets are read from demuxer with a large offset to current video pts, the section of the video where the subs belong to may have long displayed. Does the direction of the offset make a difference?

[jpsdr]

Humm... Indeed maybe. My needed shift was +32s, it didn't work, but when i tried -32s, subtitles were displayed. Not the good ones of course, but things were displayed.
I don't know another tool to mux mkv than mkvmerge, that i thought could be considered as almost a reference.

[FernetMenta]

I am not familiar with mkvmerge but looking at the manpages there seem to be multiple options how to sync or add an offset to a track. How did you use it?

[jpsdr]

I just used the standard interface, but i didn't add any offset to any track. I just select the MKV file, select the SRT file, and said "Mux".
But don't spend too much time on this. My question was just in case someone allready know the "why" without having to dig too much in the things. Probably things are differents when subtitles are muxed within the MKV. Maybe when subtitles are outside, the whole lines/timing/subtitles are avaible, but when they are muxed within the MKV, maybe subtitles are decoded "by block", and a too big offset may ask for something not yet decoded/demuxed by the stream, which finaly create a limitation.
I don't know, this is pure guess, but the "by block things" is for now the only logicical explaination i can figure out.