Hello. mpv-0.18.1 was released today. In this release upstream has decided that running mpv with different versions of ffmpeg/libav libraries than it was compiled with is no longer supported [1]. The idea here is to prevent potential crashes/errors due to ffmpeg/libav ABI incompatibilities within the same SONAME by forcing mpv rebuilds upon users. Upstream also supports only the latest ffmpeg/libav version even though mpv usually works and builds with older ones [2]. [1]: https://github.com/mpv-player/mpv/commit/d057e7a142a327c653f3f0379014567028448b5d [2]: https://github.com/mpv-player/mpv/blob/v0.18.1/README.md There are several possible ways to handle this new situation: 1. Allow mpv to error out at runtime after every ffmpeg/libav version bump and update the minimum required ffmpeg/libav version on every mpv version bump. This behaviour matches the recommended upstream way. [x] Latest ~arch version of mpv is on par with upstream wrt supported ffmpeg/libav features in the minimum required version. [x] Latest arch version of mpv is on par with upstream wrt supported ffmpeg/libav features in the minimum required version. [ ] mpv doesn't require a rebuild after ffmpeg/libav verbumps. [ ] mpv can be stabilized more or less frequently. 2. Allow mpv to error out at runtime after every ffmpeg/libav version bump and keep the minimum required ffmpeg/libav version at the bare minimum. [ ] Latest ~arch version of mpv is on par with upstream wrt supported ffmpeg/libav features in the minimum required version. [ ] Latest arch version of mpv is on par with upstream wrt supported ffmpeg/libav features in the minimum required version. [ ] mpv is usable after ffmpeg/libav verbumps and doesn't require a rebuild. [x] mpv can be stabilized more or less frequently. 3. Patch mpv to not error at runtime after every ffmpeg/libav version bump and keep the minimum required ffmpeg/libav version at the bare minimum. This behaviour matches the current situation. [ ] Latest ~arch version of mpv is on par with upstream wrt supported ffmpeg/libav features in the minimum required version. [ ] Latest arch version of mpv is on par with upstream wrt supported ffmpeg/libav features in the minimum required version. [x] mpv is usable after ffmpeg/libav verbumps and doesn't require a rebuild. [x] mpv can be stabilized more or less frequently. 4. Patch mpv to not error at runtime after every ffmpeg/libav version bump and update the minimum required ffmpeg/libav version on every mpv version bump. [x] Latest ~arch version of mpv is on par with upstream wrt supported ffmpeg/libav features in the minimum required version. [x] Latest arch version of mpv is on par with upstream wrt supported ffmpeg/libav features in the minimum required version. [x] mpv is usable after ffmpeg/libav verbumps and doesn't require a rebuild. [ ] mpv can be stabilized more or less frequently.
Option 1 tries to provide the best playback experience (upstream). Option 2 burdens users with maintainer's job for no good reason. Option 3 tries to provide the best portability (Gentoo). Option 4 is a bit more interesting. Firstly it ensures the best possible playback experience for ~arch users. Secondly it ensures better playback experience for arch users, but makes mpv stabilization synchronized with ffmpeg/libav stabilization. I think we should try to switch to option 4 in Gentoo. Upstream usually doesn't bother to test new changes against anything, but the latest versions of ffmpeg/libav. This already leads to somewhat regular build and runtime issues. mpv doesn't get stabilized too frequently as it is either. Video team do you have any objections or suggestions on this matter? I'll leave this report open for about a week to gather some feedback before introducing 0.18.1 to the tree.
Since there are no objections, once ffmpeg-3 is unmasked I'll switch to Option 4. For now I'll stick to Option 3 to deliver recent versions to all users.
PR: https://github.com/gentoo/gentoo/pull/1908
Starting from version 0.18.1 the software volume control is enabled by default, see: https://github.com/mpv-player/mpv/blob/v0.18.1/DOCS/interface-changes.rst https://github.com/mpv-player/mpv/issues/3322 This means that volume controls don't change the system volume, e.g. per-application volume with PulseAudio. If you want to restore the old behaviour, please add the following lines to '~/.config/mpv/input.conf' file: 9 add ao-volume -2 0 add ao-volume +2 / add ao-volume -2 * add ao-volume +2 m cycle ao-mute If this file doesn't exist, please create it manually.
Updated PR: https://github.com/gentoo/gentoo/pull/1947
commit 8acfe6db0f4025b2661cf4cc0f97d56f61089a06 Author: Ilya Tumaykin <itumaykin@gmail.com> AuthorDate: Mon Jul 18 01:01:00 2016 +0300 Commit: Patrice Clement <monsieurp@gentoo.org> CommitDate: Mon Jul 25 15:03:08 2016 +0200 media-video/mpv: verbump to 0.18.1 Gentoo-Bug: 588492 Package-Manager: portage-2.3.0 Signed-off-by: Patrice Clement <monsieurp@gentoo.org>
Starting from version 0.18.1 the software volume control is enabled by default, see: https://github.com/mpv-player/mpv/blob/v0.18.1/DOCS/interface-changes.rst https://github.com/mpv-player/mpv/issues/3322 This means that volume controls don't change the system volume, e.g. per-application volume with PulseAudio. If you want to restore the old behaviour, please add the following lines to '~/.config/mpv/input.conf' file: MOUSE_BTN5 add ao-volume -2 MOUSE_BTN6 add ao-volume +2 9 add ao-volume -2 0 add ao-volume +2 / add ao-volume -2 * add ao-volume +2 m cycle ao-mute VOLUME_DOWN add ao-volume -2 VOLUME_UP add ao-volume +2 MUTE cycle ao-mute If this file doesn't exist, please create it manually.
A bit more info re software volume: https://github.com/mpv-player/mpv/wiki/FAQ#i-want-the-old-pulseaudio-volume-control-back-on-linux
