ID3D11DeviceContext is a resource than should be protected in some cases. In
particular the hardware decoders must not do concurrent calls. So any use of
the same ID3D11DeviceContext must be protected as well. In VLC it is handled
but when the ID3D11DeviceContext comes from the host app it must also to the
same protection when using it outside of libvlc calls.
Setting this mutex in a GUID_CONTEXT_MUTEX private data is reserved for legacy
(UWP) apps.
If the owner doesn't set the GUID_CONTEXT_MUTEX we should still have a mutex
when we want to use the device with a hardware decoder.
The owner of the ID3D11DeviceContext doesn't need to set the mutex if it
doesn't use the ID3D11DeviceContext outside of the callbacks called by libvlc.
This is more flexible as it doesn't depend on a shared ID3D11DeviceContext.
A NULL callback is still allowed as long as the host app does the
OMSetRenderTargets on their single ID3D11RenderTargetView.
Freely choosing an increased size for fullscreen panel
control buttons has been an error prone drag and drop
operation which was hard to perform right. Compiled with the
latest macOS SDKs, this method does not work at all anymore.
As an alternative, this patch implements two size
configurations (large and normal), which additionally increased
font size.
close#20720
The filter egl_pbuffer was initially enabled only for Android, because
the default display is always internally refcounted.
Now that the display is managed separately, egl_pbuffer may be enabled
as soon as OpenGL and EGL are available.
Signed-off-by: Alexandre Janniaux <ajanni@videolabs.io>
This patch fixes the issue of wrongly positioned controls that happened in two or more conditions:
1) Interface scale factor is changed
2) ButtonsLayout model is changed (ToolbarEditor is used to change the player controlbar configuration)
Signed-off-by: Pierre Lamot <pierre@videolabs.io>
if extraWidth is greater than the implicitWidth (available width is more than what is needed), this patch makes the control limit its width to its implicitWidth
Signed-off-by: Pierre Lamot <pierre@videolabs.io>
The function eglInitialize() was called on open, but eglTerminate() was
not called on close or error.
Also remove a wrong call to vlc_object_delete(sys->gl) on error, the
vlc_gl_t is not owned by the module.
Signed-off-by: Alexandre Janniaux <ajanni@videolabs.io>
MPEG-1 Audio Layer II (MP2) was erroneously detected as ADTS.
MPGA: The previous check used wrong bitmasks (1 bit too far to the right).
The layer check was also wrong, the layer must not be 0.
ADTS: Previously only one bit of the layer was checked. Check both bits.
The check is now identical to the one in HasADTSHeader() in mpeg4audio.c.
References:
- http://mpgedit.org/mpgedit/mpeg_format/mpeghdr.htm
- https://wiki.multimedia.cx/index.php/ADTS
Signed-off-by: Francois Cartegnie <fcvlcdev@free.fr>
There really is no point having the PTS delay over the frame interval;
it just adds unnecessary latency. This should probably be even lower to
improve streaming responsiveness.
For perfect rendering synchronisation, the change of window size must
be acknowledged after the last picture is rendered in the old size,
and before the first picture is rendered in the new size.
As of c9d6d95f29, the window resize is
processed synchronously. This provides for the "after" requirement. But
it failed to address the "before" requirement: the video output thread
can end render a picture so soon after the resize so the window
callback thread has not had time to perform acknowledgement procedures.
This adds a callback to the window resize event which is called before
the display lock (or equivalent) is released. This is guaranteed to be
invoked before the video output thread has the opportunity to render
anything.
Other options were considered:
1) Invoking a callback to the window provider from the video output
thread code code.
-> This can delay the callback unreasonably.
-> Taking the window lock on the video output thread is undesirable
if at all possible.
2) Invoking a windowing system type-specific callback to the window
provider from every display of that windowing system.
-> Same delay and locking problems as 1.
-> Requires patching several display plugins.
3) Exposing the display lock to the window plugin, via new callbacks.
-> This leaks internal implementation of the core to window
providers.
-> This gets really confusing as some callbacks would need explicit
locking and others not.
In comparison, this patch seems like the least of evils.
The callback is passed a parameter rather than as a property of the
window to distinguish it from the existing window callbacks which are
not reentrant.
Refs #25112.
Steve Lhomme
David Fuhrmann
Thomas Guillem
Francois Cartegnie
Alexandre Janniaux
Romain Vimont
Fatih Uzunoglu
Benjamin Arnaud
Pierre Lamot
Michael Kaufmann
Rémi Denis-Courmont