Most video output displays either defer mouse hiding to the window
provider plugin, or do not handle the mouse events at all.
So that ought to be the default.
Also kepe the default in those display plugins that don´t handle
cursor hiding (notably X11 ones).
Live window state, this was moved from display to window eight years
ago (minus one week). When the fullscreen state changes, the window
plugin emits a resize event, which triggers any necessary updates in
the display. The display does not need to know about fullscreen state
as such. But it is retained on HWND platforms due to legacy code, just
like window state before.
Fix vlc_vaapi_DestroyImage() called on an invalid vadpy. Keep it simpler as
this case is the worst case scenario and shouldn't happen unless if forced by
the user.
PS: contrary to other vaapi filters, the download filter doesn't keep a ref on the
vadpy (except during pf_filter via src_pic).
This fixes undefined behaviors when the native display is destroyed before the
VADisplay is terminated. This caused a crash or invalid surfaces with the DRM
native display when changing between 2 vouts. For X11, no crashes were
observed, probably because the native display was already hold by the window.
We still need a *not global* vaapi instance: struct vlc_vaapi_instance. This
struct holds a VADisplay and a refcount. Every pictures of the vout pool hold
a reference to this struct in order to avoid that the VADisplay is terminated
while being used by pictures.
Filters now get the vaapi instance via filter_NewPicture(). Static filters like
the deinterlace one may not have access to a picture allocated by the vout.
This is fixed by next patches.
Refs #18445
After testing the Motion Adaptive deinterlacing mode and finding it produced
lots of flicker/judder and not much deinterlacing I traced the error back to
the below.
Although it seems a little counter-intuitive, the "forward_refs" are actually
the frames older than the current one, and the "backward_refs" are those later.
In addition, the forward_refs (previously the backward_refs) have to be ordered
such that [0] is most recent, [1] older, etc; before this patch it was the
opposite.
Just to be 100% sure, I have also cross-referenced this approach with how
FFmpeg does it:
https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavfilter/vf_deinterlace_vaapi.c;hb=HEAD
See function deint_vaapi_filter_frame.
Signed-off-by: Thomas Guillem <thomas@gllm.fr>
Use only one callback for every decoder types:
int (*pf_decode)(decoder_t *, block_t *p_block);
There is now only one way to send output frames/blocks from a decoder module:
using decoder_QueueVideo(), decoder_QueueAudio() and decoder_QueueSub()
functions.
This fixes transcoding not receiving any output when a decoder used
decoder_Queue*() function.
The pf_packetize callback is kept unchanged. A packetizer shouldn't be
asynchronous at all (and this simplify the locking for decoder core).
The pf_decode callback returns, for now, only one value: SUCCESS. This will
allow a module to send more status.
...on unaffected platforms. This control is for backward compatibility
with Windows and OS/2 code legacy. It is never triggered on other
platforms (where window state is a window rather than display control).
Thomas Guillem
Victorien Le Couviour--Tuffet
Rémi Denis-Courmont
Steve Lhomme
Oliver Collyer