Unable to join my own live stream part way through

[RobMeades]

A stoopid newbie question I'm afraid:

I am encoding a live 25 FPS 950x540 H.264 video-only (no audio) stream using the latest (built from source) FFmpeg, 15 segments in the manifest, each of duration 2 seconds, and consuming that stream with the latest hls.js (cdn.jsdelivr.net/npm/hls.js@latest) running on another machine on my local LAN in [incognito to avoid cache issues] Chrome (version 131.0.6778.86).

If I refresh the browser window when there is no source .m3u8 file present and then start the source of the stream running, everything works fine, but if I refresh the browser again (any time, even just a few seconds later) after the stream has begun, the browser displays no video, hls.js log says, for instance:

hls.js@latest:1 [log] > [stream-controller]: Loading fragment 11 cc: 0 of [0-12] level: 0, target: 22
hls.js@latest:1 [log] > [stream-controller]: IDLE->FRAG_LOADING
hls.js@latest:1 [log] > [buffer-controller] Updating Media Source duration to 24.000
hls.js@latest:1 [log] > [stream-controller]: Loaded fragment 11 of level 0
hls.js@latest:1 [log] > [stream-controller]: FRAG_LOADING->PARSING
hls.js@latest:1 [log] > [transmuxer.ts]: Flushed fragment 11 of level 0
hls.js@latest:1 [log] > [stream-controller]: PARSING->PARSED
hls.js@latest:1 [log] > [stream-controller]: Buffered main sn: 11 of level 0 (frag:[22.000-24.000] > buffer:)
hls.js@latest:1 [log] > [stream-controller]: PARSED->IDLE
hls.js@latest:1 [info] > [abr] buffer is empty, optimal quality level 0

Note that the line [abr] buffer is empty, optimal quality level 0 does not appear in the success case.

Obviously I have something fundamentally wrong: can anyone tell me what?

Here is a sample .m3u8 file (one that matches the log above):

#EXTM3U
#EXT-X-VERSION:2
#EXT-X-ALLOW-CACHE:NO
#EXT-X-TARGETDURATION:2
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:2,
#EXT-X-PROGRAM-DATE-TIME:2024-12-09T20:17:18.161+0000
http://10.10.1.16/watchdog0.ts
#EXTINF:2,
#EXT-X-PROGRAM-DATE-TIME:2024-12-09T20:17:20.161+0000
http://10.10.1.16/watchdog1.ts
#EXTINF:2,
#EXT-X-PROGRAM-DATE-TIME:2024-12-09T20:17:22.161+0000
http://10.10.1.16/watchdog2.ts
#EXTINF:2,
#EXT-X-PROGRAM-DATE-TIME:2024-12-09T20:17:24.161+0000
http://10.10.1.16/watchdog3.ts
#EXTINF:2,
#EXT-X-PROGRAM-DATE-TIME:2024-12-09T20:17:26.161+0000
http://10.10.1.16/watchdog4.ts
#EXTINF:2,
#EXT-X-PROGRAM-DATE-TIME:2024-12-09T20:17:28.161+0000
http://10.10.1.16/watchdog5.ts
#EXTINF:2,
#EXT-X-PROGRAM-DATE-TIME:2024-12-09T20:17:30.161+0000
http://10.10.1.16/watchdog6.ts
#EXTINF:2,
#EXT-X-PROGRAM-DATE-TIME:2024-12-09T20:17:32.161+0000
http://10.10.1.16/watchdog7.ts
#EXTINF:2,
#EXT-X-PROGRAM-DATE-TIME:2024-12-09T20:17:34.161+0000
http://10.10.1.16/watchdog8.ts
#EXTINF:2,
#EXT-X-PROGRAM-DATE-TIME:2024-12-09T20:17:36.161+0000
http://10.10.1.16/watchdog9.ts
#EXTINF:2,
#EXT-X-PROGRAM-DATE-TIME:2024-12-09T20:17:38.161+0000
http://10.10.1.16/watchdog10.ts
#EXTINF:2,
#EXT-X-PROGRAM-DATE-TIME:2024-12-09T20:17:40.161+0000
http://10.10.1.16/watchdog11.ts
#EXTINF:0,
#EXT-X-PROGRAM-DATE-TIME:2024-12-09T20:17:42.161+0000
http://10.10.1.16/watchdog12.ts

I have tried longer segment lengths (up to 10 seconds), I have set gop in the FFmpeg encode to 1 second in order to be absolutely sure there are key frames to grab hold of. I have applied no special configuration for hls.js aside from debug: true.

Sorry in advance for bothering everyone, but I've run out of places to ask for advice.

FYI, you can get +50 reputation on Stack Overflow if you answer this same question there :-): https://stackoverflow.com/questions/79264387/hls-js-unable-to-maintain-seek-with-live-video-only-stream

[Later]: I have modified the FFMpeg stream to ensure that there is always a key frame at the start of every HLS segment (which allows FFmpeg to use floating-point segment lengths and #EXT-X-VERSION:3), but no improvement I'm afraid; a .zip file of the output (.m3u8 and .ts files, plus the index.html and associated files that serve them) is attached: watchdog.zip, in case anyone can make any sense of my problem.

A sample debug log output of the fail case from the browser is also attached, along with a success case to show that I'm not going completely mad.

[RobMeades]

And the answer was... tell the FFmpeg libx264 video codec to -tune zerolatency.

At the FFmpeg C API this is done with av_dict_set(&codecOptions, "tune", "zerolatency", 0), where codecOptions is the AVDictionary you will then pass as the last parameter to avcodec_open2().

Why? I couldn't tell you. It has taken me nearly a week of trying everything I could try before I found this. With this single option added, hls.js synchronizes, and re-synchronizes, with the HLS stream every time, under all circumstances. Without it, hls.js will not gain initial sync to a HLS stream if it is started just a few seconds after the stream has begun and, won't regain synchronization if it should lose it.

Note that I did try running hls.js with lowLatency: false but that did not fix the problem.

We live and learn :-).