Blog-Archiv

Montag, 17. November 2025

Some Useful MPV Configurations

Since a month I use MPV now as video player, instead of VLC, for writing my video cutting plans. I had the hope that MPV has a more precise time display than VLC, which is off sometimes more than a second when the video duration goes into minutes and you jump around on the timeline a lot. Unfortunately I could not reliably verify that MPV is better in that. Nevertheless MPV is nice to use, because it is highly configurable, although this is not easy. Which is the reason for this Blog article.

Configuration Goals

Following were my configuration goals:

  1. Make the video player stop when I left-click into the image area (although this is already available through right-click by default)
  2. Prevent the application from exiting when the last video has been finished
  3. Keep the play-controller on bottom always visible, as I need to always see the passed time-seconds for my cutting-plan

Goal 2. and 3. I had already implemented as commandline options

mpv --keep-open --script-opts=osc-visibility=always [videofile videofile ....]

but I wanted it to be persistent in some configuration files, possibly for all users in the application-specific /etc/mpv/ directory.

Directories and Files

For these three goals you need two user-specific configuration directories and three configuration files.

Directories:

  1. $HOME/.config/mpv/ (the user-configuration directory for MPV)
  2. $HOME/.config/mpv/script-opts/ (the user-configuration directory for script-opts, whatever that means)

Files:

  1. mpv/mpv.conf (the main MPV configuration file)
  2. mpv/input.conf (the configuration file for input devices like mouse and keyboard)
  3. mpv/script-opts/osc.conf (the On-Screen-Controller, or play-controller, configuration file)

File Contents

Now put the following content into the following file:

  1. mpv.conf
    # do not terminate at end of last video
    keep-open
  2. input.conf
    # left mouse click toggles play/pause
    MBTN_LEFT cycle pause
    
  3. script-opts/osc.conf
    # keep the play controller always visible - no space around '=' is allowed here
    visibility=always

How did I find out?

I spent two hours with ...

40 %MPV documentation and source code
40 %Experimenting
20 %Google AI suggestions



Freitag, 7. November 2025

Badly Documented Java Process Handling Problem

For a long time I used VLC as video player, until I got bored by the fact that it froze after a while and had to be terminated using the operating system monitor. That was the reason why I tried out MPV, which is nearer to the (in)famous ffmpeg video library (used by almost every web-browser). But it was the same, even worse, MPV froze after only two videos.

Now that made me think whether these are really video player bugs. Mostly I use my own Java file-browser to select and start videos. Maybe the problem are not the players and the lots of clips I pass to them, but some Java restriction on started processes that freeze them? So I began to search on the web and found hints:

Looks like you have to ALWAYS read away any process output! This would also explain why MPV blocked faster than VLC, because the first writes lots of logging to the console.

Here is the Java code of my bug-fix. Mind that this dismisses any error or normal output of the process. First, how to start a process from Java:

    final String[] command = ....
    final String[] environment = ....
    final File workingDirectory = ....
    final Process p =  Runtime.getRuntime().exec(command, environment, workingDirectory);
    readAwayProcessOutput(p.getInputStream());
    readAwayProcessOutput(p.getErrorStream());

Mind that getInputStream() is the meaning how seen from the process starter perspective, i.e. the stream delivers what the started process sends to the starter. The getOutputStream() method is for writing to the started process.

Here is how to read away input-streams, whatever they deliver:

    private void readAwayProcessOutput(InputStream in) {
        new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    while (in.read() != -1) // -1 is end of stream
                        ;
                    in.close();
                }
                catch (IOException e) {
                    throw new RuntimeException(e);
                }
            }
        }).start();
    }

This blocking bevaviour is something that is not documented so explicitly that a programmer would see it. Read it here:

It says:

....may cause the subprocess to block, or even deadlock.

Can we call it a communication problem:-?