François Cartegnie pushed to branch master at VideoLAN / VLC
Commits:
2bcff8a3 by Alexandre Janniaux at 2024-03-07T15:01:59+00:00
video_output: report the correct time to clock
Since the video output cannot be the master clock, there's no reason to
artificially change the date matching with the displayed frame. Indeed,
the video output was using two points that felt weird:
- When the picture was late, it was "forcing" the timestamp by using
VLC_TICK_MAX as system time.
- When the picture was rendered before the deadline, it was using
system_pts, ie. the date at which the clock computed when it should
be rendered, as the system time for the clock.
In both cases, it was basically only disabling drift computation in
traces, since the drift is not used in the video output so changing its
value doesn't change the behaviour and the clock points will never be
used in a master clock. Drift would always be zero on the traces.
This commit re-establish the drift computation, using the time at which
the frame is finished being displayed as system time. It won't match the
"exact" time since it doesn't account display latency nor
supports using
dates from VSYNC (ref #26184) but the error will almost always be a
constant part (for the latency not being used) plus a bounded part (for
the VSYNC sampling delay), meaning that every non-stable behaviour like
drifting can be measured.
Reference also commit 207fcd92054dfff8e2bd6380ce9dcfa0fb99cdbd which
tried to apply that to the clock wait.
Reference commit abb6e1359912818d6ceda148f46dbffcdeae762a which asserted
that drift should be 0 given that the whole sampling process is
controlled by the clock, which is only true if the vout_display doesn't
stall the video_output.
Reference commit 013aa3aa9820dcf9cdd74b1505d7fa60dda04226 which started
to use VLC_TICK_MAX (INT64_MAX back then) so that the clock update would
notify the player.
Important: The intent of the commit above is disabled by this commit.
Note that this commit virtually introduce a huge initial drift. This
drift is actually expected given that we draw the first frame regardless
of the actual date, and playback constraints might have the video track
earlier at the beginning than audio track.
This also introduce increasing drift when a frame is re-drawn, which is
also by design since we didn't update the frame. A motion-interpolating
filter would generate intermediate frames and avoid this, which makes it
more representative of the true video output drift.
- - - - -
1 changed file:
- src/video_output/video_output.c
Changes:
=====================================
src/video_output/video_output.c
=====================================
@@ -1380,14 +1380,15 @@ static int RenderPicture(vout_thread_sys_t *sys, bool
render_now)
else
{
sys->displayed.date = system_now;
- /* Tell the clock that the pts was forced */
- system_pts = VLC_TICK_MAX;
}
- vlc_tick_t drift = vlc_clock_UpdateVideo(sys->clock, system_pts, pts,
sys->rate,
- frame_rate, frame_rate_base);
/* Display the direct buffer returned by vout_RenderPicture */
vout_display_Display(vd, todisplay);
+ vlc_tick_t drift = vlc_clock_UpdateVideo(sys->clock,
+ vlc_tick_now(),
+ pts, sys->rate,
+ frame_rate, frame_rate_base);
+
vlc_queuedmutex_unlock(&sys->display_lock);
picture_Release(todisplay);
View it on GitLab:
https://code.videolan.org/videolan/vlc/-/commit/2bcff8a39311dea9333329d728e5ed4961547edb
--
View it on GitLab:
https://code.videolan.org/videolan/vlc/-/commit/2bcff8a39311dea9333329d728e5ed4961547edb
You're receiving this email because of your account on code.videolan.org.
VideoLAN code repository instance_______________________________________________
vlc-commits mailing list
vlc-commits@videolan.org
https://mailman.videolan.org/listinfo/vlc-commits
