* Create an external process that receive preparser request, use the
original preparser to preparse the media and the send it back as
preparser responce.
Two issues were present with the previous implementation for interface
handling.
- Contrary to bin/vlc.c, darwinvlc.m needs to handle the CFRunLoop in
the main thread, but libvlc was released only after the runloop was
terminated, meaning that interfaces could not use the runloop on
close.
- Some application-specific runloop stop code was present to stop the
NSApp for the main macosx.m interface, with conditionals to check
whether the NSApp was started or not. darwinvlc.m shouldn't need to
know whether it needs to do that and should only handle the
termination of its own CFRunLoopRun() call, even if an interface
nests the runloop afterwards. As with the point above, the interface
should terminate its NSApp before darwinvlc terminates its runloop.
This commit reorder the resource deallocation to first remove the
interfaces, by releasing the libvlc instance, and only then destroy the
runloop. It uses previous changes in the macosx interface to handle the
stopping through libvlc_Quit.
By reordering this way, it's now possible to use SIGINT to stop the Qt
interface also.
The handling through GCD was added back then in commit
cc07bce0d2. In that commit,
signal(SIGCHLD, SIG_DFL) was already called to ensure the behavior of
the signal is restored to default handlers.
In `man 3 signal` from the macos manual, it is said that when setting
SIG_IGN for SIGCHLD, the operating system will not create zombie process
and the exit status will be ignored. We do want to avoid creating zombie
process but we also want to have exit status, which means we do indeed
need the SIG_DFL handler here. See also the following commit on the
linux side: 94763831fb.
However, GCD was used to automatically call waitpid() on the process
that are being signalled as closing. Since we're always calling waitpid
when spawning any process, this duplicates the handling. But the clients
are actually using vlc_waitpid which is checking errno != ECHILD, so it
would break as soon as the GCD handler is executed before the
vlc_waitpid call.
Since every cases are explicitely calling vlc_waitpid(), do as linux and
just remove the specific GCD handling.
Co-authored-by: Marvin Scholz <epirat07@gmail.com>
Fixes#29099
Use the new vlc_plugins_targets_array to depend on all plugins with the
plugins.dat custom target. This ensures the plugin cache is properly
regenerated when plugins change.
It's unlikely the user path is that large, but just in case we are ready.
This fixes an issue where the result of _snwprintf() is not checked.
The wstringstream will only fail if there's no memory. At this point
further calls using std::map and breakpad will also fail.
It was added in mingw-w64 in [1] which is in v6, our minimum version.
We don't need to have it defined in UWP builds as we don't use winvlc.c.
[1] 36d7b92bbc
winvlc.c uses API's not available in UWP:
- SetProcessMitigationPolicy
- SetProcessDEPPolicy
- SetDllDirectory
- SetDefaultDllDirectories
- MessageBox
GetCommandLine is allowed but not in mingw-w64 yet.
Interfaces from libvlc were started from the main thread directly. But
UI inserting their own event loop inside the main runloop like Qt were
taking over the interface insertion. It was preventing other interfaces
to load correctly, required dedicated code to handle the startup in the
Qt interface and it was not possible to exit the interface correctly.
By moving the creation of the interfaces in a dedicated thread, we can
ensure all UI are created and destroyed correctly, but the macosx
interface must now dispatch its own creation into the main thread to
match Cocoa requirement on main thread usage for UI components.
Note that libvlc_new itself must be moved to the intf_queue given that
it starts additional extraintf.
The macosx interface must now start its own NSApp inside the main loop,
via a dispatch call, which simplify the main loop into running the
default main loop.
Setting the target DEPENDENCIES might lead to confusing behaviour where
dependencies added to LDADD are not propagated correctly. The automake
manual suggest using `EXTRA_%_DEPENDENCIES` when the goal is to augment
the automake-generated `%_DEPENDENCIES` instead.
It's restricting available code to Windows XP that we don't support.
The value should be the minimum OS we support. It's automatically
picked based on _WIN32_WINNT.
The Frameworks folder was missing in the rpath, leading to Frameworks
like Sparkle requiring change of the install_name after it was built
instead of just using rpath properly.
Olaf Hering
Steve Lhomme
Rémi Denis-Courmont
Gabriel Lafond-Thenaille
Alexandre Janniaux
Alexandre Janniaux
Marvin Scholz
Brad Smith
Ankit Meel
Fatih Uzunoglu
Thomas Guillem
Khalid Masum
Johannes Kauffmann
KO Myung-Hun
Tristan Matthews