Instead of ltmain.sh, in order to ensure all changes will used.
If ltmain.sh gets modified as well, there is no way to garanty that all
changes to the .in file will trigger a regenetation since both file will
likely have the same modification timestamp
Refs !182
An updated version of our current libtool patchset has been pushed to
https://github.com/chouquette/libtool/tree/vlc_patches
For instance:
./export_plugin.sh build-iphoneos-arm64-dynamic/vlc-iphoneos-arm64/ output_folder/
It will export and bundle the dylibs into a framework, adapt their
mach-o headers to signal the correct rpath identifier, add the matching
Info.plist and sign everything.
On iOS, there's no folder plugins, and every plugins are located at the
Application root/Frameworks/ folder, so we need to probe this folder
instead of the plugins/ suffixed path. In addition, the library path
located by VLC will redirect to foo.app/Frameworks/vlccore.framework/vlc
which doesn't correspond to the correct path. It mostly affects 3.0.x
branch and not next 4.0 or more branches.
On iOS and tvOS, dylibs must be wrapped into a framework and frameworks
must be flattened into the frameworks/ application directory (or global
to the system which is not possible in the general case), so dylibs
can't be in the VLC_PKG_LIB_DIR/plugins folder. Redirect
VLC_PKG_LIB_DIR/plugins toward VLC_PKG_LIB_DIR/ on those platforms.
Manual cherry-pick from commit 89e90672db.
The code is written directly in the src/modules/bank.c code given that
config_GetSysPath doesn't exist in 3.0.
The arguments to AllocatePluginFile were written in reverse, leading to
vlc_stat failing to find the file. In addition the value that should
have been written `-(sizeof ".framework" -1)` was actually written as
`-sizeof ".framework" -1` and thus `foo_plugin` was instead `foo_plug`.
Typo from function refactor in 70d3002be1.
Darwin platforms are using frameworks to embed libraries. Some of them
like iOS and tvOS even forbid the use of dynamic libraries that are not
wrapped into a framework.
Since frameworks can contain various things (headers, resources, etc),
we don't necessarily want to browse their whole tree if their structure
is well-defined. In our case, since plugins are bundles and not dylibs,
there's not linking and there's no point in supporting versionning so we
can expect the plugin's dynamic library in the root of the framework,
named like the framework without the .framework part.
Since MacOSX can also make use of frameworks, this is enabled for all
darwin platforms, though it might not use them.
iosvlc.m provides a binary usable as an iOS application, forwarding the
VLC arguments just like VLC on desktop. It allows easier iteration on
vlccore development for iOS, without the need to test in a VLCKit
application like VLC for iOS or new external application.
It is currently designed for usage with dynamic plugins.
To develop with it, you must generate a .ipa archive containing both
the resulting binary as executable, a PkgInfo file, an Info.plist file
describing the package and the libs (libvlc.dylib, libvlccore.dylib, and
every plugin .dylib or additional convenience libraries that are not
linked statically in the Frameworks/ directory. It must then be signed
with a developer certificate allowed by Apple and provisionned with a
mobileprovision file allowing installation on the given device for the
same developer certificate.
Then, tools like libimobiledevice can be used to start the application
with additional arguments or environment variables. They can also be
added in XCode through the "Edit Scheme" menu.
A big part of the iOS-specific code has been originally written by
Marvin Scholz in a more complete libVLC ios sample.
Co-authored-by: Marvin Scholz <epirat07@gmail.com>
Cherry-picked and adapted from commits:
e16f4d9bb60bfe88030196bee41831904998afec54c392d7be
The build script allows building for iOS/tvOS without pulling the whole
VLCKit project, to build a standalone library for integrating libvlc in
applications.
The main goal is being able to maintain libVLC 3.0 without requiring the
whole VLCKit environment to run tests.
Cherry-picked from master branch at commit version
44d44176aa, and modified the build.conf to
have all enabled contribs building.
When the video window is closed normally, there are no needs to
reparent it. In this case, we can retain the pre-3.0.13 behaviour
whence we simply close the video window as a children of the Qt UI.
This fixes a transient visual glitch when stopping playback or
disabling the video track. This also saves one full round-trip through
the X server at that time as XSync().
The video widget is normally released when the window provider is
closed. But it can also be released when the main UI is closed, even
though the window provider is still active.
Even if it is redundant with vlc_killed() (but not all APIs return
-EINTR when killed).
(cherry picked from commit 797e1f3b97)
Signed-off-by: Thomas Guillem <thomas@gllm.fr>
The reason why the playback panel is not aligned to the bottom in fullscreen mode on Linux is because the desktop environment panels (like taskbar, topbar, etc.) set `struts` that limit the area over which the top-level window can be moved programmatically. To get around this, we need to tell the window to ignore window manager hints (by setting the Qt::X11BypassWindowManagerHint flag) and manually limit its movement.
BUG: 22563
VLC 3.0 uses libupnp exclusively as a client. LibUpnp internals are
quite opaque and it has been observed that a webserver thread is still
running on idle with open sockets even if the library is used as a
client only.
The recent bump to 1.14 introduces regressions in libupnp's webserver
socket initialization [1] on windows. Since the bug is still not
corrected upstream and we don't have any use of the webserver for 3.0
anyway, let's just disable it.
[1] https://github.com/pupnp/pupnp/issues/195Fixesvideolan/vlc#27001
The X and Y values are pixel coordinates in the potentially subsampled
plane resolution. This must be converted to an octet offset as the type
of the pixel plane pointer is pointer-to-uint8_t.
So the X value must be multiplied by the sample size. The current code
was instead rounding the value down to a multiple of the sample size.
Bug reported by Philipp Marek on IRC.
(cherry picked from commit 87733c5011)
Fixes notably:
CVE-2018-9251 CVE-2018-14567 CVE-2018-14404
CVE-2021-3541 CVE-2022-23308 CVE-2022-29824
And move to the official Gnome Infrastructure
(cherry picked from commit 471fd489f3)
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
The previous fix was dropped in 233747ab4c
when updating harfbuzz. The previous (local) patch for fixing the matter
didn't fit without conflicts - instead of updating that patch, backport
the upstream fix (removing the unused variable - our previous fix was to
remove -Werror for -Wunused).
(cherry picked from commit 3d38357a4b)
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
The kVTVideoDecoderReferenceMissingErr error is not a critical one,
but without it being handled here, it would lead to aborting with
VideoToolbox and falling back to Software.
Reproduced this with a sample provided by zhilizhao(赵志立),
related to !1790.
I assume that before this error code was introduced in macOS 12/iOS 15,
VT did just return the NULL image buffer with a success status code,
leading to the issue seen in !1790.
(cherry picked from commit f7434e60fc)
Signed-off-by: Marvin Scholz <epirat07@gmail.com>
Alexandre Janniaux
Hugo Beauzée-Luyssen
Rémi Denis-Courmont
Thomas Guillem
Eugene Popov
Alaric Senat
Romain Roffé
Pierre Lamot
Jean-Baptiste Kempf
Martin Storsjö
Marvin Scholz