4.0 regression: seek with hardware decoding not immediate (slow)

Seek is not immediate when using hardware decoding.

This is a regression from VLC 3.0. It happens on Linux (vaapi) or Windows (direct3d11)?

Seek when using ./vlc --no-hw-dec is fast and immediate.

By default, (with hwdec on), seek has approximately one second of delay. Some old frames are displayed after the seek command making it very glitchy. It acts as the vout is not flushed at all (but it is).

The combination of 2 different issues create this problem.

The output clocks are reset while flushing.

Therefore, sync points are reset and the clocks are still used while the decoder is flushing. This causes the vout to delay the frame rendering (and delay the decoder waiting for a frame).

A simple fix (need to be checked carefully, still WIP) could be to reset output clocks once decoders are flushed:

 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/input/es_out.c b/src/input/es_out.c
index ff34b5bb120..5722ecc05fc 100644
--- a/src/input/es_out.c
+++ b/src/input/es_out.c
@@ -949,7 +949,6 @@ static void EsOutChangePosition( es_out_t *out, bool b_flush )
     vlc_list_foreach(pgrm, &p_sys->programs, node)
     {
         input_clock_Reset(pgrm->p_input_clock);
-        vlc_clock_main_Reset(pgrm->p_main_clock);
         pgrm->i_last_pcr = VLC_TICK_INVALID;
     }

@@ -1048,6 +1047,10 @@ static void EsOutDecodersStopBuffering( es_out_t *out, bool b_forced )

     const vlc_tick_t update = i_current_date + i_wakeup_delay - i_buffering_duration;

+    es_out_pgrm_t *pgrm;
+    vlc_list_foreach(pgrm, &p_sys->programs, node)
+        vlc_clock_main_Reset(pgrm->p_main_clock);
+
     /* Send the first PCR to the output clock. This will be used as a reference
      * point for the sync point. */
     vlc_clock_main_SetFirstPcr(p_sys->p_pgrm->p_main_clock, update,

The second issue: lock starvation: #25479 (closed)

Fixing both these issues resolve this current problem.