Alexandre Janniaux authored 2 years ago and Rémi Denis-Courmont committed 2 years ago

CMAKE_INSTALL_LIBDIR can be lib, lib64 or even lib/<multiarch-tuple> on
Debian, but we already split the contribs by multiarch-tuple /
installation directory at the prefix level for contribs to avoid mixups.

Preventing installation in lib64/ ensure every pc files from contribs/
are in the PKG_CONFIG_PATH when configuring.

Refs #26888

Romain Vimont authored 2 years ago and Rémi Denis-Courmont committed 2 years ago

More Visiblity -> Visibility.

Romain Vimont authored 2 years ago and Rémi Denis-Courmont committed 2 years ago

Visiblity -> Visibility.

Pierre Lamot authored 2 years ago and Rémi Denis-Courmont committed 2 years ago

this allows to store error messages before the UI is loaded and not to miss
dialogs messages if they are requested before the QML is ready.

fix: #26111

Pierre Lamot authored 2 years ago and Rémi Denis-Courmont committed 2 years ago

this allows an application to manage error messages outside of the UI
lifetime. For instance to store error messages before the UI is loaded and able
to handle dialogs.

ref: #26378

Romain Vimont authored 2 years ago and Pierre Lamot committed 2 years ago

Connections.enabled requires QtQuick 2.7:

    qml: component is not ready: qrc:/player/Player.qml:121 Type PlayerPlaylistVisiblityFSM unavailable
    qrc:/player/PlayerPlaylistVisiblityFSM.qml:99 "Connections.enabled" is not available in QtQuick 2.0.

For consistency with other Qml headers, use QtQuick 2.11.

Refs https://phabricator.kde.org/D14984

This code seems to be a stale copy of a regex library from glibc,
thus not sending the patch further upstream.

In some configurations, this library seems to choose not to include
standard C headers but declare the functions manually (without a
proper prototype though!). In this case, it already declared malloc
and realloc, but didn't declare abort and free in the same way.

Just add declarations of these functions in the same way - while
the most correct path forward would be to actually make it use
the proper system headers.

Since Clang 15 (which still is under development, so this may
still change before it's released) [1], implicit function
declarations are a hard error by default, when building code
in C99 mode (or newer).

[1] https://github.com/llvm/llvm-project/commit/7d644e1215b376ec5e915df9ea2eeb56e2d94626

The upstream zvbi code doesn't seem to have any support for
building for Windows at all, therefore not trying to upstream it.

On Windows, the <io.h> header is needed for getting declarations
of functions like open/read/write/close. The zvbi project has a
header of its own, named io.h, and it resides on a path added with
-I, so any includes of <io.h> ends up including this header instead
of the system header. Therefore, add an #include_next <io.h> which
should bring in the system header and its declarations too.

Adjust ifdefs to ifdef out larger bits of the code that contained
calls to functions that simply don't exist on Windows, like
ioctl, munmap etc. Previously, the zvbi library has been built with
implicit declarations of those functions, and the static library has
had undefined references to them. As long as those object files
from the static library haven't been included in the link, this issue
has been unnoticed so far.

For the function ffs(), which also was undefined on Windows,
provide a _BitScanForward based reimplementation. This also resides
in a file that doesn't end up included in the end, but for this
case it's just as easy to provide a working implementation as it
would be to ifdef it out.

contrib: librist: Apply a patch to the bundled mbedtls to avoid implicit declarations of gettimeofday

This patch has been sent upstream at
https://github.com/Mbed-TLS/mbedtls/pull/5770 but hasn't been
acted upon yet. As it hasn't been handled in upstream mbedtls,
I haven't sent it to librist (which bundles mbedtls) yet.

The QueryPerformanceCounter implementation previously was within
defined(_MSC_VER), but it works just as well on other Windows
toolchains, like mingw.

For most common mingw x86 build configurations, one of the earlier
inline assembly implementations would end up used, but for non-x86
(arm, aarch64), it would end up falling back on the gettimeofday
implementation.

This implementation did build successfully (as mingw toolchains do
provide gettimeofday, contrary to MSVC), but the header providing
gettimeofday, <sys/time.h>, wasn't ever included when building
targeting Windows - thus the function was called without a proper
declaration.

Clang 15 changes such implicit function declarations into a hard
error by default, when building in C99 mode (or newer) [1].
(While Clang 15 still is under development, this may still change
before it's released, but it's a valid issue in any case.)

[1] https://github.com/llvm/llvm-project/commit/7d644e1215b376ec5e915df9ea2eeb56e2d94626

This patch has been sent upstream at
https://gitlab.xiph.org/xiph/icecast-common/-/merge_requests/2
but hasn't been acted upon there yet.

When building for a mingw target, HAVE_GETTIMEOFDAY is defined
(as the gettimeofday function was found), but the #ifdef _WIN32 #else
block never tried to include <sys/time.h> (which provides the
declaration) and/or <time.h> for such targets. This caused
gettimeofday to be used without a prior declaration.

This has been visible as an easily overlooked warning, but Clang 15
changed this into a fatal error by default, when building in C99
mode (or newer). [1] (While Clang 15 still is under development, this
may still change before it's released, but the warning is valid
in any case.)

Decouple including of those headers from the #ifdef _WIN32 #else
block and just check their corresponding availability defines.

[1] https://github.com/llvm/llvm-project/commit/7d644e1215b376ec5e915df9ea2eeb56e2d94626

This patch has been sent upstream at
https://github.com/pupnp/pupnp/pull/387, but hasn't been acted
on by upstream yet.

In mingw headers, both time.h and sys/time.h define
struct timezone and _TIMEZONE_DEFINED - however only one of them,
sys/time.h, define gettimeofday. Thus, if time.h had been included
before, we'd have _TIMEZONE_DEFINED defined, and we'd omit our own
declaration of the gettimeofday function too, leading to calls to
an undeclared function.

(If the actual sys/time.h header is included, its declaration of
the gettimeofday function does conflict with both the declaration
and the definition of upnp's gettimeofday, due to details like missing
the restrict attribute on pointers. But that issue already existed
and is unaffected by this patch.)

Since Clang 15 (which still is under development, so this may
still change before it's released) [1], implicit function
declarations are a hard error by default, when building code
in C99 mode (or newer).

[1] https://github.com/llvm/llvm-project/commit/7d644e1215b376ec5e915df9ea2eeb56e2d94626

Rework resizing as a display-only module without windowing.

Since there's no window to resize this component (and it handles resize
internally), we can accept the display size events without changing
the rendering state, and will only react to the internal resize events
from the embedded NSView.

Fix #26846
Refs #25264

The _pendingReshape mechanism was used to avoid redrawing the view if it
has been updated externally, and avoid re-render the view when it's
being drawn already but:
 - `drawRect:` won't be called if we didn't change the window, except
   the first time which will likely trigger a clear.
 - When the window state changes, we were already setting
   _pendingReshape to YES.

Overall, we can let the UI system decide when it requires a re-draw and
react to that instead of trying to workaround when to re-draw.

The current vout display module is resizing from its own view and tries
to notify the video view changes to the parent. But it can already
resize, so it doesn't need the core to resize the input picture, and
would already know the size it can render to.

It makes reporting the vout display size from the vout useless, and even
harmful since the display will re-enter itself on resize.

sys->embed was confusing when the NSView could come from either the
drawable variable or the window provider, and the view is now given
through the display configuration in any case, so it doesn't need to be
stored again.

The drawable NSObject is now provided through the window and the code is
the same both for a vout_window-provided NSObject or a libvlc NSObject
drawable so we can simplify here now.

This also prevent the leak of sys happening when the wrong type of
window is used when opening the display, and move the test after the
trivial check for window type.

Alexandre Janniaux authored 2 years ago and Jean-Baptiste Kempf committed 2 years ago

Debian is using cJSON from github.com/DaveGamble/cJSON, as well as
archlinux and homebrew, which is shipping a libcjson.pc file. Only
ubuntu is using a different version not including the .pc file.

Homebrew is also shipping a libcjson.pc file, and without this, it would
generate a pc file like that:

    prefix=/foo/bar/vlc/contrib/x86_64-apple-darwin21
    libdir=${prefix}/lib
    includedir=${prefix}/include

    Name: librist
    Description: Reliable Internet Stream Transport (RIST)
    Version: 0.2.4
    Libs: -L${libdir} -lrist /usr/local/Cellar/cjson/1.7.15/lib/libcjson.1.7.15.dylib
    Cflags: -I${includedir} -I/usr/local/Cellar/cjson/1.7.15/include

Which won't be valid, especially for a standalone build with the
macosx/build.sh script.

It was leading to undefined references to cJSON symbols when it's
installed from homebrew.

Backport from upstream 809390b3b75a259a704079d0fb4d8f1b5f7fa956.

Refs #26860

Martin Storsjö authored 2 years ago and Steve Lhomme committed 2 years ago

This source file in projectM uses std::bind2nd, which is declared
in the <functional> header. Previously it relied on this header
being included implicitly.

libc++ recently stopped including <functional> transitively in
<algorithm> in
https://github.com/llvm/llvm-project/commit/a83f4b9cda57c5b3d414ec3bcf9ac891b2ec27e1.

Upstream projectM stopped using std::bind2nd in this file in
https://github.com/projectM-visualizer/projectm/commit/10faca9abf4c879a63cdf426ddae338620baf238
- thus not trying to upstream the patch.

Alexandre Janniaux authored 2 years ago and Jean-Baptiste Kempf committed 2 years ago

VLC_CODEC_VAAPI_420_10BPP is equivalent to VLC_FOURCC_P010 and has a
plane description that is like NV12, so it should not be different from
NV12. Only the bits per component, and so texture storage type is
changing for this format.

It was leading to incorrect or green color rendering with vaapi.
Regression from c344522f.

Fixes #26883

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

Fixes #26882

Alexandre Janniaux authored 2 years ago and Steve Lhomme committed 2 years ago

    ../../modules/video_output/libplacebo/utils.c: In function ‘vlc_placebo_DoviMetadata’:
    ../../modules/video_output/libplacebo/utils.c:472:23: warning: comparison of integer expressions of different signedness: ‘int’ and ‘long unsigned int’ [-Wsign-compare]
      472 |     for (int c = 0; c < ARRAY_SIZE(dst->comp); c++) {
          |                       ^
    ../../modules/video_output/libplacebo/utils.c:486:35: warning: comparison of integer expressions of different signedness: ‘int’ and ‘long unsigned int’ [-Wsign-compare]
      486 |                 for (int k = 0; k < ARRAY_SIZE(cdst->poly_coeffs[i]); k++) {
          |                                   ^
    ../../modules/video_output/libplacebo/utils.c:496:39: warning: comparison of integer expressions of different signedness: ‘int’ and ‘long unsigned int’ [-Wsign-compare]
      496 |                     for (int k = 0; k < ARRAY_SIZE(cdst->mmr_coeffs[i][j]); k++)
          |                                       ^

Steve Lhomme authored 2 years ago and Jean-Baptiste Kempf committed 2 years ago

Using upstream patch until a new release comes.
https://github.com/libass/libass/commit/0915955733bd236ecc44645ee968fb7a55ad5079

Fixes #26865

Pierre Lamot authored 2 years ago and Jean-Baptiste Kempf committed 2 years ago

fix: #26355

Alexandre Janniaux authored 3 years ago and Steve Lhomme committed 2 years ago

This doesn't imply anything more on the thread system and just
deallocate memory, so there is no need to add that much constraint on
the function usage.

Pierre Lamot authored 2 years ago and Jean-Baptiste Kempf committed 2 years ago

this allow to keep the playlist visible when switching between the player and
the medialibrary views, regarding the different parameters (playlist docked,
playlist visible, video embed)

this uses a hierarchical state machine to track the different states and
transitions.