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

[Steve Lhomme]

Hello Ismail,

If you have an account on code.videolan.org you should submit your patch 
as a merge request there, with these explanations. We do not accept 
patches through the mailing list anymore.

Thanks in avdance.

On 08/07/2026 01:26, Ismail Degani wrote:
> 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 <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
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel