Newer Windows issue this warning if we send metadata with each picture:
DXGI WARNING: IDXGISwapChain4::SetHDRMetaData: Redundant invocation on unchanged
metadata could result in presentation performance inefficiency. [ MISCELLANEOUS WARNING #295: ]
Similar code as done in 269540817f for VLC 4.0.
On 3.0 the pool video format doesn't have to match the decoder actual
padding. The quad handling to place the picture will take care of this
with the actual texture size.
We still need to fix the semiplanar dimensions although it's unlikely
the quad will use anything else than an RGB output.
Fixes green line seen in fullscreen.
If InitVideoDecCommon() fails, it's already cleaning the decoder,
release the context and freeing p_sys.
We must not do anything and just return the error.
(cherry picked from commit fecebe1588)
This fixes#28377 -- the issue when double-clicking on
MOUSE_BUTTON_CENTER (mouse wheel) would result in plugins receiving
mouse events only for the first click, as VLC was filtering out all
non-left-mouse-button double-clicks.
The non-left-mouse-button double-click events, instead of being entirely
filtered out, are now being passed as regular mouse button presses
without any indication that they are double-clicks. While it would be
more proper to pass them as double-clicks with the corresponding mouse
button being pressed, that might break some 3rd party plugins that rely
on (vlc_mouse_t.b_double_click == true) to mean that the left mouse
button was double-clicked, without checking if the left mouse button was
actually pressed. Still, even with b_double_click not being set on
non-left-mouse-button double-clicks, passing such double-clicks as
regular press+release events does fix the issue of VLC "eating up" the
second click of a MOUSE_BUTTON_CENTER, so this is a good change.
> 1.3.0 is a medium release reducing memory footprint, increasing again
> the speed on x86 and ARM and extending the API functions.
https://code.videolan.org/videolan/dav1d/-/tags/1.3.0
(cherry picked from commit cf283cb757)
Signed-off-by: Steve Lhomme <robux4@ycbcr.xyz>
We should not use whatever is in the PATH. Especially as the current directory
is set the a temporary directory during uninstallation.
(cherry picked from commit d13608f886)
Signed-off-by: Steve Lhomme <robux4@ycbcr.xyz>
This will allow to fix a leak by only checking the return code instead
of fetching the media (and forgetting to release it...)
Signed-off-by: Felix Paul Kühne <felix@feepk.net>
We should not subtract width and height values.
Fixes#27976
(cherry picked from commit 4cd819e238) (edited)
edited:
- SetupQuadFlat is in d3d11_quad on 3.0
This shouldn't be enforced. We already use -O2 on release builds.
Introduced in 77f2dac1ab
(cherry picked from commit 4dce5d8ed7)
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
VLC 4.0 doesn't need that but 3.0 still has no windowing module, leading
to display size not being reported to the subtitle text renderer, and
leading to blurry subtitles and OSD.
Because the size is coming from the display, it means that the first
time the subtitle is displayed, it will always be blurry depending on
the real display size and original media size.
Regression from 8ff5695217.
Fixes#27793
This is a temporary solution for #22576
It results in numbers not having thousands separator anymore, which
is better than the user being unable to save the desired value.
So far we did not need it. We should always have the format matching
the one we detected by the decoder. If we don't that means the packetizer
failed to reset the decoder.
(cherry picked from commit c901da645b)
Signed-off-by: Steve Lhomme <robux4@ycbcr.xyz>
(cherry picked from commit 5892a9106a) (edited)
edited:
- in 4.0 p_dec->fmt_in is a (const) pointer
- there's no VLC_ENOTSUP in 3.0
Signed-off-by: Steve Lhomme <robux4@ycbcr.xyz>
This is what is passed in the normal decoding case.
This fixes an issue where 10-bit sources don't play properly as we can't
tell from the Profile 0 is we're decoding in 8-bit or 10-bit.
(cherry picked from commit 1aa624e28d)
Signed-off-by: Steve Lhomme <robux4@ycbcr.xyz>
The container may lie but the size that libavcodec requests is the one it
will use. We need this size to probe the decoder in D3D11. There doesn't
seem to be a way to check the size support in dxva2.
Similar to e4cc2f846b but without setting
an output video_format_t.
Jean-Baptiste Kempf