Do we really need mpv.com on Windows?

CrendKing commented 3 days ago

mpv Information

mpv v0.38.0-525-g265056fa Copyright © 2000-2024 mpv/MPlayer/mplayer2 projects
 built on Jun 23 2024 00:06:39
libplacebo version: v7.349.0 (v7.349.0-rc1-3-g1fd3c7b-dirty)
FFmpeg version: N-115975-g0c0e7ec81
FFmpeg library versions:
   libavcodec      61.8.100
   libavdevice     61.2.100
   libavfilter     10.2.102
   libavformat     61.3.104
   libavutil       59.25.100
   libswresample   5.2.100
   libswscale      8.2.100

Other Information

Windows version: Windows 11 23H2
Source of mpv: https://github.com/mpv-player/mpv/commit/527911d2a2047796acd59bae03b075e4425cf73b
Introduced in version: v0.9.0

Reproduction Steps

In the FAQ, section On Windows, why does mpv.exe not attach to the console and what does mpv.com do? it explains the existence of mpv.com is a limitation of Windows due to an application having to choose one subsystem. It sounds as once an application is a GUI program, it can no longer interact with console.

Which is not true. Before https://github.com/mpv-player/mpv/commit/527911d2a2047796acd59bae03b075e4425cf73b, 9 years ago, mpv uses AttachConsole to attach to the parent process' console. This allows the one mpv.exe to both be able to write to the console if it's launched in a terminal, or console-less if launched outside a terminal, without needing the mpv.com.

That was also the behavior of current mpv in Linux. I tried mpv in a Debian. It installs one /usr/bin/mpv, which interacts with terminal if launched in terminal, and seeming does nothing if double-clicked in a GUI file explorer. The installed shortcut for launching it in GUI mode is simply adding the --player-operation-mode=pseudo-gui argument.

The commit message of https://github.com/mpv-player/mpv/commit/527911d2a2047796acd59bae03b075e4425cf73b considers the change an improvement, because it is more deterministic. It also refers to https://github.com/mpv-player/mpv/issues/768, which complains that if a GUI mpv is launched from terminal, closing that terminal also closes mpv. However, the Linux version has exactly the same behavior, yet no one complained, I guess.

I want to discuss the possibility of retiring mpv.com on Windows, and endow mpv.exe the ability to interact with console again. This simplifies the mpv installation on Windows (e.g. no need for a FAQ) and brings consistency with other platforms. I also have a bit of selfish reason. Current when I debug mpv in VSCode, I have dilemma to choose between launching mpv.exe and mpv.com: the former hits the breakpoints, but can't print any log message to the terminal, while the latter does the opposite.

Minimally, I can obtain the desired behavior by removing https://github.com/mpv-player/mpv/blob/22fc2e6af3a89db325b3191a3775a373020d562f/osdep/terminal-win.c#L600-#L611. But I'm sure there are other codes requiring tweaking. To address https://github.com/mpv-player/mpv/issues/768 's complain, I can add a FreeConsole() call at https://github.com/mpv-player/mpv/blob/22fc2e6af3a89db325b3191a3775a373020d562f/player/main.c#L366.

Expected Behavior

N/A

Actual Behavior

N/A

Log File

N/A

Sample Files

No response

I carefully read all instruction and confirm that I did the following:

[X] I tested with the latest mpv version to validate that the issue is not already fixed.
[X] I provided all required information including system and mpv version.
[X] I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of --log-file=output.txt.
[X] I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
[X] I attached the full, untruncated log file.
[X] I attached the backtrace in the case of a crash.

kasper93 commented 3 days ago

No, we cannot retire mpv.com. It is age old topic. There are workarounds, and we are using the best one. It is not supported use-case by Windows kernel. https://devblogs.microsoft.com/oldnewthing/20090101-00/?p=19643

It is explained here why it is bad idea to use GUI mode always. https://github.com/mpv-player/mpv/pull/13011#issuecomment-1834616399

Alternatively it is bad idea to use Console mode always, as best we can do is to hide console window in this case and this produces annoying flicker.

I have dilemma to choose between launching mpv.exe and mpv.com: the former hits the breakpoints, but can't print any log message to the terminal, while the latter does the opposite.

Change subsystem to console and always use mpv.exe

diff --git a/meson.build b/meson.build
index 1a89094df0..fd4efb1f20 100644
--- a/meson.build
+++ b/meson.build
@@ -1803,7 +1803,7 @@ if get_option('cplayer')
     install_data('etc/mpv-symbolic.svg', install_dir: join_paths(hicolor_dir, 'symbolic', 'apps'))

     mpv = executable('mpv', main_fn_source, objects: libmpv.extract_all_objects(recursive: true), dependencies: dependencies,
-                     win_subsystem: 'windows', install: true)
+                     win_subsystem: 'console', install: true)

     # Older meson versions generate this in the player subdirectory.
     if win32 and meson.version().version_compare('>= 1.3.0')

CrendKing commented 3 days ago

Thanks for the links. If I understand correctly, the main limitation of Windows over Linux is the lack of API to not only attach but take full control of parent process' console. And the console wrapper solution is good because it can use its own console to override the parent console, and wait out the wrapped sub-process.

If that's really the only reason, I'm a bit surprised why Windows can't offer such an API, provided that they have a otherwise fairly complete plethora of console manipulation utilities. But if Visual Studio itself has to use a .com trick, I guess the reason must be deep.

Thanks again. Closing.

mpv-player / mpv