- Dec 08, 2022
-
-
The headers are always present, so we can just enable the modules on Darwin instead of checking for the headers of the Frameworks they need.
-
Nowhere in the code are the defines for these headers checked.
-
size_t use %zu, which is different than PRId64.
-
-
i_depth is a size_t, and we should use %zu for that.
-
- Dec 07, 2022
-
-
Signed-off-by:Claudio Cambra <developer@claudiocambra.com>
-
Signed-off-by: -
Signed-off-by: -
Signed-off-by: -
Signed-off-by: -
Signed-off-by: -
Signed-off-by: -
Signed-off-by: -
Signed-off-by: -
Signed-off-by: -
macosx: Replace VLCLibrarySongsTableView class with table view implementation in VLCLibraryWindow XIB Signed-off-by: -
Signed-off-by: -
Signed-off-by: -
macosx: Move all audio view-related procedures to new VLCLibraryAudioViewController class, simplifying VLCLibraryWindow and VLCAudioDataSource Signed-off-by: -
Signed-off-by: -
Signed-off-by: -
Regression from d9c9482b. This fixes linking on macOS with static Qt from contribs: Undefined symbols for architecture x86_64: "_BZ2_bzDecompress", referenced from: _ft_bzip2_file_fill_output in libfreetype.a(ftbzip2.c.o) "_BZ2_bzDecompressEnd", referenced from: _ft_bzip2_stream_io in libfreetype.a(ftbzip2.c.o) _ft_bzip2_stream_close in libfreetype.a(ftbzip2.c.o) "_BZ2_bzDecompressInit", referenced from: _FT_Stream_OpenBzip2 in libfreetype.a(ftbzip2.c.o) _ft_bzip2_stream_io in libfreetype.a(ftbzip2.c.o) ld: symbol(s) not found for architecture x86_64
-
It is built, but not installed. This causes problems on macOS when linking our libqt_plugin: clang: error: no such file or directory: '/vlc/contrib/x86_64-apple-darwin19/lib/libQt5PrintSupport.a' Since we don't use any of the printer related functionality, disable it altogether.
-
Steve Lhomme authored
for META_REQUEST_OPTION_NO_SKIP
-
Steve Lhomme authored
-
Steve Lhomme authored
For input items without a know type (imem access for example) preparsing is not possible. With this option we allow forcing the preparsing in that case, optionally. By default the current behavior remains the same.
-
Steve Lhomme authored
For users of libvlc with manual DLL loading (especially languages not compatible with C that have to recode the access to the libvlc DLL) it is important to know the ABI version of the DLL, in case of API/ABI changes the wrapper need to be updated and know when the provided DLL package matches or not. This is especially critical for VLC 4.0 which has not changed version in 4 years and yet the libvlc API keeps changing. This is similar to the versions of libavcodec/libavformat/etc. When the API is changed the version values should be updated as well, and hopefully documented as well. One should avoid loading the DLL of a mismatching libvlc major ABI version. Since it's likely to not be usable in the end, it's better not to load it at all. This should also be backported to VLC 3.0.
-
It is very unlikely that AudioUnitGetProperty(kAudioUnitProperty_Latency) can change midstream (contrary to [AVInstance outputLatency]), so only fetch this latency when starting the AudioUnit. This fixes a deadlock between the render callback and AudioUnitStop(). Fixes #27591
-
Steve Lhomme authored
-
Steve Lhomme authored
-
Steve Lhomme authored
libvlccore.dll should not be defined as libvlc.dll
-
Steve Lhomme authored
Use the same values as for vlc.exe.
-
This will fix the CI if a libVLC API is changed and used by the jni library.
-
- Dec 06, 2022
-
-
Signed-off-by: -
Steve Lhomme authored
Avoid recreating the gperf file on macos as it seems to fail otherwise.
-
Steve Lhomme authored
Originally introduced in f1faa9d8 and modified in b8fd5718. We might not even need a HAVE_MACOSX differentiation.
-
Fixes #27537
-
- Dec 04, 2022
-
-
Co-authored-by:Pierre Lamot <pierre@videolabs.io>
-
-
-
