hls video timing issue groups of frames play back early

[diviaki]

Summary of the bug:
I am trying to transcode anything to mp4/libx264 then use this source to create hls by copying data.
In this second step some videos play back very strange as if frames in every nth group of about 5 frames played back later then those in the the n+1th group.
How to reproduce:
I see this issue on Safari in Macos (in and out of the browser) and on ios in Safari.
Using ffplay plays back the video without issues.
Note that the original.mp4 has a frame rate of 29.99 fps, and adding the -r:v 30 parameter when creating video.mp4 fixes the odd behaviour in the subsequently created video.ts

% ffmpeg -i original.mp4 -c:v libx264 video.mp4
% ffmpeg -i video.mp4  -c copy video.m3u8
ffmpeg version N-68533-gcc774cd962-static arm64
built on 20240203

[diviaki]

the m3u8 showing playback issues

[diviaki]

the ts file showing playback issues

[diviaki]

source mp4

[Balling]

29.99 fps? No, Frame rate : 30.000 FPS

[diviaki]

Yes there is an fps diff between them:
mp4:

Stream #0:0[0x1](und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 1824 kb/s, 29.99 fps, 29.99 tbr, 1888380000.00 tbn (default)

hls:

Stream #0:0: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 30 fps, 30 tbr, 90k tbn

[diviaki]

I've been trying to understand the issue and read that timestamp issues can be fixed with a simple

ffmpeg -i video.m3u8 -c copy video_.m3u8

Issueing this command generates an army of warnings like this one, and does not fix the problem:

[vost#0:0/copy @ 0x28e738f0] Non-monotonic DTS; previous: 177892197, current: 177892197; changing to 177892198. This may result in incorrect timestamps in the output file.

Why ffmpeg created such a problematic file?

[diviaki]

This flag removes the Non-monotonic DTS warnings but playing back the hls file still looks uncontinous.

ffmpeg -fflags +igndts -i video.mp4 video.m3u8

[Balling]

But mediainfo says 30.000 fps, strange

[diviaki]

Further investigation reveled issues in the original 264 file. A new ticket will be opened.