- Sep 12, 2022
-
-
Sub-decoders are decoders whose state is defined by previous decoders. Specifically in the current case, picture frames with specific SEI data can convey subtitles as closed captions and report them from the decoder implementation itself. Since the core never locks the implementation, and the implementation can be asynchronously reporting subtitles, a common lock need to be setup so that the core can then check and use the sub-decoders being created without racing against the upper decoder implementation. Co-authored-by:
François Cartegnie <fcvlcdev@free.fr>
-
Separate the early return to make it clear that what follows require a valid closed-caption decoder. Then, use vlc_input_decoder_Flush directly, because pf_flush must be called from the CC decoder thread, and the fifo must be flushed beforehand, instead of calling it directly.
-
The test provides an infrastructure based on previous transcode tests and video output tests, that will serve as basis for other input_decoder.c tests.
-
-eq is for comparing integers and prints errors like: install_wrapper.sh: 27: [: Illegal number: imageformats
-
- Sep 10, 2022
-
-
So the order of build is always respected, even in case of build error.
-
-
Just like we do with autotools builds, we configure the target every time we build a contrib. In the case of cmake, touching `toolchain.cmake` does rebuild the cmake contribs but if there's a cache it's not reconfigured and doesn't rebuild anything.
-
-
This is how it's done for autotools target and some cmake targets. It makes long lines a little better to read.
-
It contains Marvin's patch to respect BUILD_SHARED_LIBS.
-
We do force CMAKE_INSTALL_LIBDIR which makes srt not use any other of the GNU directories... Merged upstream: https://github.com/Haivision/srt/pull/2450
-
It can be removed once we update to the next release. The previous patch potentially hides an error handling.
-
-
-
lrint uses libm which is set in CMAKE_REQUIRED_LIBRARIES. But check_function_exists() won't use it with cmake older than 3.12. This removes the need for Wno-dev.
-
It has the same effect as using HOSTVARS_PIC which we already use.
-
-
The test was always true.
-
The test was always true. Move the dependencies definitions higher in the makefile, in line with other contribs.
-
It's automatically enabled for Windows targets and not used otherwise.
-
It's automatically enabled for Apple targets and not used otherwise.
-
These options don't exist. The others are set to non default values.
-
It's used to set the library prefix between glew (dynamic) and glew_s (static). But only the static target (glew_s) is selected in our environment. It will pick the proper prefix on its own. It's not even a public option to set.
-
FLUIDSYNTH_NOT_A_DLL is not used anymore when built statically. Here's the file used to generate the public header: https://github.com/FluidSynth/fluidsynth/blob/v2.1.8/include/fluidsynth.cmake
-
It's off by default.
-
They are already using $(PIC) with $(HOSTVARS_PIC)
-
LDFLAGS is already set in HOSTVARS
-
I believe that's what the + is for. It's used on all other $(CMAKEBUILD) calls.
-
No need to change the current directory.
-
- Sep 09, 2022
-
-
The plugins are now correctly installed to the correct location.
-
So that we can factor together the different checks on X11 and Wayland support.
-
-
We need the plugins for the Qt Wayland integration. Co-authored-by:
Alexandre Janniaux <ajanni@videolabs.io>
-
This is required when building for linux, and might cause a system provided version to be used, causing conflicts during linking. Typically, the error message at link time will look like this: /usr/bin/ld: .libs/libqt_plugin.so: version node not found for symbol qt_version_tag@Qt_5.10 Co-authored-by:
Alexandre Janniaux <ajanni@videolabs.io>
-
-
-
They are currently enabled only when the matching contrib has been found on the system. The plugin name doesn't match with the plugin from the contrib, but still enforce at link time the plugin to be present. This always use the XdgShell integration regardless of what is supported for now.
-
-
-
They are currently enabled only when the matching contrib has been found on the system. The plugin name doesn't match with the plugin from the contrib, but still enforce at link time the plugin to be present.
-