- Sep 16, 2021
-
-
-
And patch the qml files accordingly.
-
-
The decoder device was setup for offscreen surface but not for usual surfaces, and was hold but never released.
-
- Sep 15, 2021
-
-
-
The bitcode flag was already added to CFLAGS, but was only used when creating a static build of libvlc, which doesn't involve linkage. When creating shared plugins, the dylibs must be linked with the -fembed-bitcode flag to gather the bitcode from the different objects. In particular, bitcode is mandatory on tvOS, so this is mandatory when building dynamic plugins and/or libvlc for tvOS.
-
When building with bitcode enabled (*FLAGS+=-fembed-bitcode), the following happens: - with LDFLAGS += -fembed-bitcode, the vanilla libtool version will remove the -fembed-bitcode flag, being an unknown flag, so bitcode won't actually be enabled, and final link steps might complain that the dylibs (libvlccore.dylib for instance) doesn't actually have bitcode embedded. - once fixed (either by this patch or by using -Wl,-fembed-bitcode), the plugins will be compiled with -module, which default to using MH_BUNDLE on iOS/tvOS/MacOSX instead of MH_DYLIB. Indeed, dylibs can be dlopened only since MacOSX 10.3/10.4, and can be dlclosed only since MacOSX 10.5, so MH_BUNDLE was the primary target for libtool module support. However, MH_BUNDLE is not compatible with the bitcode support from Clang. Since we support MacOSX 10.11 as minimum, we can default to using MH_DYLIB for plugins to have the bitcode support. This new libtool patch add the explicit support for -fembed-bitcode in libtool --mode=link flags, and change the flags used when using -module in libtool to switch to dylibs.
-
Check that the linker features from Darwin ld64 for marking a symbol as undefined (in the context of two-level namespace, it means that it can be looked up in other namespaces) are usable. If they are not, the static module bank is disabled since it depends on either static linkage (which is obviously not affected by this option) or more generally the ability to look up the static module bank symbol in a different linkage unit/namespace. In particular, they are currently not usable when enabling bitcode through LDFLAGS+=" -fembed-bitcode" and compiling dynamically. On tvOS, bitcode is mandatory, so supporting compiling with bitcode but without the static module bank seems a rather good compromise given that it was disabled anyway previously. In static builds (the current shipping target for iOS and tvOS), the static module bank stays enabled by the !HAVE_DYNAMIC_PLUGINS check.
-
Those frameworks only exist for MacOSX, so it was invalid to set them up in the general case. Fortunately, it wasn't really used on iOS and tvOS for the executables so it didn't have consequences. On MacOSX, the targets needing this framework already link it so it is not needed.
-
-
- use a single location for adding every defines - use a single vout_LTLIBRARIES += line - deduplicate -framework,IOSurface
-
Otherwise, the OpenGL interop doesn't link on tvOS when creating dynamic plugins (--enable-shared option from build.sh).
-
-
Those flags are not supported with bitcode and are not needed now that the code has migrated to using availability targeting.
-
The SSL*ALPNProtocols were introduced in recent OS version, and dynamic lookup (using ld64 option -Wl,-U) was used to make it work during link-time and potentially not have the function available. However, -Wl,-U is not compatible with bitcode support, whereas availability targeting is, and availability targeting provides more information about when it's not supported. MacOSX 10.13.4 is the minimal version target in cURL too. The SSL*ALPNProtocols functions are documented as supported since 10.13 but they were not included in the initial 10.13 releases.
-
This is not supported with -bundle_bitcode, and was only supposed to be used on 32bit anyway. It seems to be only a legacy flag now. From ld64 man: -read_only_relocs treatment Enables the use of relocations which will cause dyld to modify (copy-on-write) read-only pages. The compiler will normally never generate such code.
-
-
François Cartegnie authored
HTTP realm is provided by reply headers. Sending it proactively can then only be done by matching the url. (RFC 7617)
-
Hugo Beauzée-Luyssen authored
This image contains a prebuilt protobuf-compiler
-
We no longer use/support it in 4.0
-
-
-
We no longer force/use pthreadGC2 in 4.0
-
-
As brackets are separators only within the authority part, thier use within (or on the edges of) the path does not create any ambiguity. Fixes #26092.
-
The `next_system_pts` has nothing to do with the displayed.next picture. It's the date of the displayed.current picture in system time. The `date_next` also has nothing to do with the displayed.next picture. It's the system date where we should initiate the prepare() for displayed.next.
-
mutex_cleanup_push() and vlc_cleanup_pop() are not available in C++. All we want is to tell the feeder thread to exit when it's idle. The condition will be triggered when: * a frame has completed * the maxdelay to wait before scheduling a new frame has been reached * the local thread cancel has been requested We no longer use the cancellation API which is not available in C++.
-
- Sep 14, 2021
-
-
Hugo Beauzée-Luyssen authored
The convertion will incur a cost which we don't want to pay since the art needs to be encoded in base64, which doesn't include anything outside of ASCII
-
- Sep 13, 2021
-
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
VLC_EGENERIC has no equivalent in <errno.h>, so it should not alias any <errno.h> value. This maps it to INT_MIN. It works because -INT_MIN equals INT_MAX + 1, which is out of range of `int`. As a reminder codes in <errno.h> are positive integers. The convoluted definition is to avoid pulling <limits.h> into <vlc_common.h> and from there all over the code base.
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
Not exact (and mismatched) defines.
-
fix: #26043
-
the limit no longer exists in the medialibrary
-
-
-
the active focus handler of the local banner was triggered when the search box got focus through a shortcut and force the focus on another component. Making the local banner a control fixes the issue. The initial reason of the change was to be able to check the focus reason in the focus handler, but this seems unnecessary.
-
Previously, the volume and mute properties would read their default values (0 and false respectively) since neither Open() or Start() would call aout_{Volume,Mute}Report by themselves. Now, the initial volume and mute status are read during Start(), which means that setting the volume should work after the first volume_changed event is received by a libvlc consumer. Partial workaround for #26032. As a result, reporting the volume level after (un)muting is no longer necessary (d104faec).
-
-