MPV

mpv:bliss

Last commit made on 2020-06-10
Get this branch:
git clone -b bliss https://git.launchpad.net/mpv

Branch merges

Branch information

Name:
bliss
Repository:
lp:mpv

Recent commits

6551ea5... by wm4 <wm4@nowhere>

new build system

Further changes by the following people:

James Ross-Gowan <email address hidden>: win32 fixes

f386463... by wm4 <wm4@nowhere>

build: change/simplify optical disc device detection

So this had a long list of OS specific device files for CD and DVD
physical devices. If we ever migrate to a new build system, this will be
a PITA for rather questionable usefulness. For example, Linux does
provide /dev/sr0, but it also creates /dev/cdrom and /dev/dvd symlinks.
For Windows, it's sort of ridiculous to hardcode D: (well, might still
work).

Get rid of this stuff, hardcode a single device name on Unix, keep D: on
Windows. In general, this probably requires runtime detection in theory,
so it's not much of a sin to move these from the build system to the
code, even if we don't make use of determining the device at runtime
yet.

This should not invite to add new ifdeffery to add device files for
other Unix variants. Rather, if anyone wants to extend this, I'd argue
they should add proper runtime detection of the device. Or, even better,
create an appropriate symlink on their systems.

d5de79d... by wm4 <wm4@nowhere>

audio: require certain AOs to set device_buffer

AOs which use the "push" API must set this field now. Actually, this was
sort of always required, but happened to work anyway. The future
intention is to use device_buffer as the pre-buffer amount, which has to
be available right before audio playback is started. "Pull" AOs really
need this too conceptually, just that the API is underspecified.

From what I can see, only ao_null did not do this yet.

0fb02f1... by Nicolas F <email address hidden>

ao/pulse: properly set device_buffer

Previously, device_buffer defaulted to 0 on pulse. This meant that
commit baa7b5c would always wait with a timeout of 0, leading to
high CPU usage for PulseAudio users.

By setting device_buffer to the number of samples per channel that
PulseAudio sets as its target, this commit fixes this behaviour.

12415db... by der richter <email address hidden>

cocoa-cb: properly reset window isMoving state on title bar clicks

since the title bar catches the mouse up and down events, the underlying
events view doesn't reset the isMoving state and no mouse movements are
signalled to the core. now we also reset the state in mouse up events
on the title bar.

Fixes #7807

5ad73cc... by wm4 <wm4@nowhere>

vo_gpu: fix display corruption with window screenshots

The "screenshot window" command (ctrl+s by default) somehow broke video
colors with --gpu-api=vulkan --profile=gpu-hq when playback was paused.
I don't know the cause, but the rest of the code seems to imply
gl_video_reset_surfaces() needs to be called manually to flush some
caches, and it fixes the issue, so I assume there's no great mystery
here.

7174c06... by Niklas Haas <email address hidden>

vo_gpu: mark peak detection buffer coherent

This is required for buffer memory barriers to actually work

03171b1... by Niklas Haas <email address hidden>

vo_gpu: make storage images/buffers as restrict

This informs the GPU that we don't alias it with any other descriptors
(which we don't).

8a725ec... by kwash

vulkan/wayland: fix another build breakage

Commit 07b0c18 introduced some build breakages. Some breakages
were fixed on c1fc535 and a1adafe. This one is still remaining.

This commit fixes the following build error:

[153/521] Compiling video/out/vulkan/context_wayland.c
../video/out/vulkan/context_wayland.c:26:10: fatal error: video/out/wayland/presentation-time.h: No such file or directory
   26 | #include "video/out/wayland/presentation-time.h"
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

Relevant to: #7802

a1adafe... by wm4 <wm4@nowhere>

build: fix another breakage

The build was still broken. Feel free to look for a better maintainer if
you don't like it.

Fixes: #7802 (maybe now?)