Thomas Guillem authored 2 years ago and Jean-Baptiste Kempf committed 2 years ago

Any LibVLC users could request a timer from the player. This Media Player
timer has its own event API since:

 - It is only used to receive time update points:

 - The timer is not locked by the player lock. Indeed the player lock can be
   too "slow" (it can be recursive, it is used by the playlist, and is it held
   when sending all events). So it's not a good idea to hold this lock for
   every frame/sample updates.

 - The minimum delay between each updates can be configured: it avoids to flood
   the UI when playing a media file with very high fps or very low audio sample
   size.

The libvlc_media_player_time_point struct is used by timer update
callbacks. This public struct hold all the informations to interpolate a
time at a given date. It can be done with the
libvlc_media_player_time_point_interpolate() helper. That way, it is
now possible to get the last player time without holding any locks.

There is only one type of timer (for now):

libvlc_media_player_watch_time(): update are sent only when a frame or a
sample is outputted. Users of this timer should take into account that
the delay between each updates is not regular and can be up to 1seconds
(depending of the input). In that case, they should use their own timer
(from their mainloop) and use
libvlc_media_player_time_point_interpolate() to get the last time.

FindFirstFileExW() doesn't seem to like them. We should normally use proper
Windows pathes with vlc_opendir(). But this will make it safer if we don't.

Although a lot of Windows API's seem to be happy with the mixed slashes that
we use. The FindFirstFileExW() doesn't seem to like forward slash when allowing
long pathes to be found.

Fixes #27208

Claudio Cambra authored 2 years ago and Jean-Baptiste Kempf committed 2 years ago

Signed-off-by: Claudio Cambra <claudio.cambra@gmail.com>

Rémi Denis-Courmont authored 2 years ago and Jean-Baptiste Kempf committed 2 years ago

The high-order byte is promoted to 'int'. If the high-order bit is set,
this results in an overflow (into the sign bit) when shifted by 24 bits
to the left. This was flagged by the UB sanitiser. To fix that, promote
all bytes to 32-bit unsigned first, to perform overflow-proof unsigned
arithmetic.

Then to avoid aliasing errors, make sure the output is written as signed
32-bit values, since the decoder outputs S32N.

While this reverts 721a085d
ReportSize is effectively called from another thread context.
It greatly improves resize reactivity.

Romain Vimont authored 3 years ago and Denis Charmet committed 2 years ago

If vlc_clock_Wait() has been interrupted to release the display_lock
quickly, then the next rendering must be performed ASAP, without waiting
for any deadline.

Romain Vimont authored 3 years ago and Denis Charmet committed 2 years ago

On resize, the UI thread waits for the end of any current rendering at
the old size before returning.

To limit its waiting, interrupt the wait between prepare() and display()
on the vout thread to complete the rendering as soon as possible. As a
consequence, the display() call might be performed early (before its
expected PTS).

Refs !324

Claudio Cambra authored 2 years ago and Hugo Beauzée-Luyssen committed 2 years ago

Signed-off-by: Claudio Cambra <claudio.cambra@gmail.com>

Claudio Cambra authored 2 years ago and Hugo Beauzée-Luyssen committed 2 years ago

Signed-off-by: Claudio Cambra <claudio.cambra@gmail.com>

Alex Chernyakov authored 2 years ago and Jean-Baptiste Kempf committed 2 years ago

In exec_DataSharedMem() memory is allocated via the call to picture_New().
This memory is correctly freed via picture_Release() if an error occurs,
but if no error occurs and the function proceeds normally, the memory is
never freed. When the DataSharedMem routine is called repeatedly (e.g.,
to update a picture continuously), this leak accumulates very quickly.

Niklas Haas authored 2 years ago and Hugo Beauzée-Luyssen committed 2 years ago

We need to update the ICC profile either if the window moves to a new
display, or if the root window atom associated with a given display is
updated. To this end, we need to start tracking property changes on the
root window, as well as updating this atom every time the window moves
to a new display.

Unfortunately, this code again requires one memcpy more than I'd like to
have there, as a result of xcb not letting me fetch properties into my
own buffers. If we determine this to be a performance issue later on,
the straightforward fix would be to make vlc_icc_profile_t refcounted
with a custom free callback.

Niklas Haas authored 2 years ago and Hugo Beauzée-Luyssen committed 2 years ago

Needed for RandR-related code in future commit.

Niklas Haas authored 2 years ago and Hugo Beauzée-Luyssen committed 2 years ago

This is non-functional on its own, but introduces necessary display
tracking information that will be useful in the following commit(s),
like figuring out which display's ICC profile to query for the VLC
window.

Niklas Haas authored 2 years ago and Hugo Beauzée-Luyssen committed 2 years ago

Pretty straightforward. Rather than wasting cycles computing a checksum
each frame, just update the signature once per received ICC change
control event.

Niklas Haas authored 2 years ago and Hugo Beauzée-Luyssen committed 2 years ago

The window backend triggers a callback of the vout, and the vout
forwards this to the display using another callback. There are several
unfortunate layers of glue and indirections in the callchain. In
particular, we need to persist these ICC profile objects in some layer,
because of init order between windowing system and the window / vout
display module itself. I've chosen to add them to `vout_display_cfg_t`
because it fits well with the other "dynamic window state" properties in
there.

This approach also allows capable vouts to read directly from the
allocated ICC profile memory, minimizing the number of memcpys.