We don't include tchar.h anymore, nor TCHAR, nor the *tcs* APIs. Using any of
these will fail to compile if tchar.h is not included. In MinGW it's never
included through other headers.
We don't need _UNICODE either which is specific to tchar.h.
Originally, XVideo was the HAL for video ("2D") overlay.
Nowadays, XVideo is but a backward compatibility wrapper around the 3D
hardware for use by legacy applications (notably GLAMOR provides XVideo
using OpenGL). VLC supports OpenGL well nowadays, so there is no point
in using XVideo.
It seems that lot of developers forget to enable this option. This option
enables assert and other debug codes (like the very useful thread/mutex debug
code) that should be mandatory when you dev on VLC.
This is quite a big change: all VLC maintainers should now add
"--disable-debug" when they release a stable version of VLC.
x86inc.asm copied from dav1d (8c5d34c85613) and x86util.asm from libav
(994c4bc10751). Libav's LGPL licensed x86util.asm is required for yadif.
This reverts "Remove unused support for .asm files"
commit 6c0f63cd68.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
Now that we use winpthreads, configure finds clock_nanosleep there,
causing -pthread to be added to the libvlccore requirement, while we
don't use it for win32.
fixed patch with the duplicate "#if defined ..." removed
Janne
---8<---
Some toolchains predefine _FORTIFY_SOURCE resulting in countless
_FORTIFY_SOURCE is redefined warnings. Using _FORTIFY_SOURCE without
compiler optimizations also generates warnings.
_FORTIFY_SOURCE is a reserved identifier in C99 ("All identifiers that
begin with an underscore and either an uppercase letter or another
underscore are always reserved for any use.") so the toolchain is
perfectly free to predefine it.
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
This brings the modern (well, at least current) X11 rendering protocol
for video output (refs #12348).
Compared to plain X11, it can handle scaling and orientation.
Compared to XVideo, it can handle orientation, and can crop correctly
(without bleeding), but it expects packed RGB rather than YCbCr.
Also RENDER would be able to handle SPU blending (and SPU scaling),
though this is left for future work, which neither X11 nor XVideo can.
This should sort properly on Windows and any other platform without
qsort_r(). It does _not_ fix any potential issues on any platforms with
an incompatible qsort_r() prototype (such as FreeBSD < 13).
It is using the picture callback API so there's is no copy on output of the decoder.
Co-authored-by: Hugo Beauzée-Luyssen <hugo@beauzee.fr>
Co-authored-by: Steve Lhomme <robux4@ycbcr.xyz>
This uses libplacebo's rendering helpers for all video output, on top of
the vulkan graphics API. Some notes:
- The existing fourcc/chroma helpers don't really line up with what the
libplacebo API expects, or in some cases return values that just don't
seem to make sense. I was advised against touching them for fear of
breaking the rest of VLC - so we add our own helpers that give us the
information in the format we need for libplacebo.
- Not all libplacebo options are mapped. There's no ability to create
custom filter functions (which libplacebo/mpv support), and there's
also no support for ICC profiles / 3DLUTs (which libplacebo supports)
nor for the new color blindness simulation parameters in libplacebo
v0.6. We also don't map the VLC brightness/hue/gamma/etc. options to
the libplacebo structs - we could do it for free as part of the video
decode matrix, rather than needing to insert a CPU filter for it.
- How to create the vulkan surface will depend on the platform (much
like in opengl), so we move context, surface and device creation into
a single module (`vulkan/surface.c`) which will be conditionally
compiled depending on the platform in order to provide support for
multiple surfaces side-by-side (e.g. x11 and wayland). This does mean
that the context/device-related options end up being separate per
platform, but OTOH this is not that bad since different platforms
might want different e.g. swapchain modes (an example being wayland,
which can make better use of mailbox rather than fifo).
- libplacebo doesn't have a "configure" step, instead all rendering
parameters are fully dynamic. So we could call UpdateParams() in our
module at any point in time when the config values change.
Unfortunately, there's no easy way for us to find out when this is the
case, so right now changing the vulkan module options requires a
module reinit to take effect. In theory we could change this. (As an
aside: calling var_Inherit* per frame does work to get us the changes
in "realtime", as soon as the user clicks "save", but this may block
for arbitrary amounts of time so I was advised against doing it)
Due to the new functions, structs and enum members used, the minimum
libplacebo version has been bumped up to v0.5.0. In theory we could also
try and support v0.4.0 with some #ifdefs, but v0.5.0 has been out for
several months now so it should be a safe requirement.
