[vlc-devel] [PATCH] es_out: scale preroll clock-origin compensation by the playback rate

[Ismail Degani]

Hi devs,

Submitting my first vlc patch for an issue I've had for years (reported 7
years ago! #21890) which Claude gave me the superpowers to finally fix =)

If you slow a video down — say to 0.25x — and then seek, VLC freezes at the
target position for a long time before playback resumes: several seconds
with short-GOP files, and 30 seconds or more with the 5-10 second GOPs
typical of phone recordings and web video. The slower the rate, the longer
the freeze.

What happens: after a precise seek, the demuxer restarts at the previous
keyframe, and EsOutDecodersStopBuffering() rebases the clock origin by
subtracting i_buffering_duration — a stream-time quantity — from a
system-time date, without scaling by the playback rate. Timestamp
conversion then stretches the keyframe-to-target preroll by 1/rate, so
playback stalls for exactly preroll * (1/rate - 1). The pts_delay part of
that compensation is fine as-is (the input clock already compensates it on
every conversion via ClockGetTsOffset(), which is also why caching settings
don't affect the stall), so the fix scales only the preroll term. At 1.0x
the added term is zero and nothing changes; at rates above 1x the same math
currently makes the first post-seek frames late by the mirrored amount,
which this also fixes.

A note on the filing of #21890: it is labeled Demux: Adaptive because it
was reported against an HLS stream in 2019, but the stall reproduces on a
plain local mp4 — the root cause is in core es_out/clock code, not the
adaptive demuxer. That mislabeling may be part of why it has sat unfixed
for so long. The same defect is behind the slow-motion seek freezes
reported against VLC-Android.

Measured with a headless libvlc driver polling media_player_get_time()
every 250 ms around a seek to 60s (local mp4, 1.67 s preroll, file-caching
1000; "stall" = wall time until the reported time advanced 200 ms past the
target):

master (8115e53): unpatched patched
1.0x 1.75 s 1.75 s (unchanged)
2.0x 1.50 s 1.50 s (unchanged)
0.25x 6.25 s 2.25 s
0.1x 18.0 s 2.5 s

The patched residual at slow rates is the measurement floor itself:
advancing 200 ms of stream time takes 0.8 s / 2 s of wall time at 0.25x /
0.1x. The same fix was also verified on the 3.0.x branch with a rebuilt
libvlccore 3.0.20: the 0.25x stall dropped from ~5-6 s to under 1 s, and
0.1x from ~15-17 s to under 2 s. A formatted 3.0.x backport is ready —
happy to send it as a follow-up patch or open a [3.0] merge request.

Quick repro: generate a two-minute test clip with "ffmpeg -f lavfi -i
testsrc2=duration=120:size=640x360:rate=30 -f lavfi -i
sine=frequency=440:duration=120 -c:v libx264 -preset ultrafast -c:a aac
test120.mp4", play it, set rate 0.25, seek to ~60s. Running with
--input-fast-seek avoids the stall entirely (keyframe seeks have no
preroll), which isolates the preroll term.

The patch is attached (git format-patch against master 8115e53) rather than
inline because this message is sent through a mailer that can't guarantee
inline whitespace survives; the full commit message and measurements are
inside it, and I can resend inline via git send-email if that's preferred.

Two disclosures: I prepared and validated this with AI assistance (noted in
a Co-authored-by trailer), and I have reviewed the change and the
measurements myself. I also have a
https://www.google.com/url?q=http://code.videolan.org&source=gmail&ust=1783552830165000&sa=E
account pending administrator approval — if a merge request is more
convenient for review, I'd gladly resubmit there once it's approved.

Thanks!
Ismail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20260707/31eca173/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-es_out-scale-preroll-master.patch
Type: text/x-patch
Size: 3211 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20260707/31eca173/attachment.bin>