From d690ee095942c06ee3157480e970ff70b399e04e Mon Sep 17 00:00:00 2001 From: wm4 Date: Sun, 17 Dec 2017 14:03:33 +0100 Subject: client API: change --stop-playback-on-init-failure default This was off for mpv CLI, but on for libmpv. The motivation behind this was that it would be confusing for applications if libmpv continued playback in a severely "degraded" way (without either audio or video), and that it would be better to fail early. In reality the behavior was just a confusing difference to mpv CLI, and has confused actual users as well. Get rid of it. Not bothering with a version bump, since this is so minor, and it's easy to ensure compatibility in affected applications by just setting the option explicitly. (Also adding the missing next-release-marker in client-api-changes.rst.) --- DOCS/man/options.rst | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) (limited to 'DOCS/man/options.rst') diff --git a/DOCS/man/options.rst b/DOCS/man/options.rst index 676860f156..39c143b228 100644 --- a/DOCS/man/options.rst +++ b/DOCS/man/options.rst @@ -365,11 +365,10 @@ Playback Control Without ``--hr-seek``, skipping will snap to keyframes. ``--stop-playback-on-init-failure=`` - Stop playback if either audio or video fails to initialize. Currently, - the default behavior is ``no`` for the command line player, but ``yes`` - for libmpv. With ``no``, playback will continue in video-only or audio-only - mode if one of them fails. This doesn't affect playback of audio-only or - video-only files. + Stop playback if either audio or video fails to initialize (default: no). + With ``no``, playback will continue in video-only or audio-only mode if one + of them fails. This doesn't affect playback of audio-only or video-only + files. Program Behavior ---------------- -- cgit v1.2.3