In "dumb mode" (where most features are disabled and which only performs
some basic rendering) we explicitly copy a set of whitelisted options,
and leave all the other options at their default values. Add the new
--opengl-early-flush option to this whitelist. Also remove an option
field accidentally added in the commit adding --opengl-early-flush.
Don't require special property code for handling updates, and simply use
the UPDATE_AUDIO flag instead. Also make runtime changes to
--audio-client-name take effect.
Now a reload requested by an AO behaves in exactly the same way as
changing an AO-related options (like --audio-channels or
--audio-exclusive). This is good for testing and uniform behavior. (You
could go as far as saying it's a necessity, because the spotty and
obscure AO reload behavior is hard to reproduce and thus hard to test at
all.)
This affects changing audio configuration options. Explicitly flush and
uninitialize the audio output first before doing the rest. This should
ensure all state attached to the audio output is discarded and not used
during the reconfiguration.
Also add a comment to the reinit_audio_filters() call. It doesn't
necessarily restore the audio chain fully, but makes sure a seek is
issued if the amnount of buffered audio discarded was huge enough to
cause "problems".
It seems this can cause issues with certain platforms, so better to
disable it by default. The original reason for this isn't overly
justified, and display-sync mode should get rid of the need for it
anyway.
The new option is meant for testing, and will probably be removed if
nobody comes up and reports that enabling the option actually improves
anything.
The player tries to avoid splitting frames with spdif (sample alignment
stuff). This can in certain corner cases with certain drivers lead to
the situation that ao_get_space() returns a number higher than 0 and
lower than the audio frame size. The playloop will round this down to 0
bytes and do nothing, leading to a missed wakeup. This can lead to
underruns or playback completely getting stuck.
It can be reproduced by playing AC3 passthrough with no video and:
--ao=null --ao-null-buffer=0.256 --ao-null-outburst=6100
This commit attempts to fix it by allowing the playloop to write some
additional data (to get a complete frame), that will be buffered within
the AO ringbuffer even if the audio device doesn't want it.
If we really want client API users to use mpv_set_property() instead of
mpv_set_option(), then compatibility handling of deprecated options
should be included. Otherwise, there's the danger that client API users
either break too early (and without a warning), or mpv_set_option() will
continue to have a reason to exist.
Reduces code duplication between OpenGL backend and DRM VO.
(The control() for OpenGL backend isn't sufficiently similar to the
VO's control() to consider merging it as a whole - I extracted only the
FPS code.)
Rename the text subtitle options from --sub-text- to --sub-
and --ass- options to --sub-ass-.
The intention is to common sub options to prefixed --sub-
and special ASS option be seen as a special version of sub options.
The OSD options that work like the --sub- options are still named
--osd-.
Man page updated including a short note about renamed --sub-text-*
and --ass-* options to --sub-* and --sub-ass-*.
This is potentially incompatible if a program used negative timestamps
to deal with timestamp resets, which would potentially lead to mpv
producing and using negative timestamps.
"seek -10 absolute" will seek to 10 seconds before the end. This more or less
matches the --start option and negative seeks were otherwise useless (they just
clipped to 0).
Regression since commit bbcd0b6a. This code is just cursed, because it's
a fragile state machine with no proper tests, and which could be done in
a much simpler way. Without doubt this change will cause a regression in
some ridiculous corner case as well.
Fixes#3610 (the cause of it, not the behavior it resulted in).
When the vaapi decoder is used in copy mode, it creates a dummy
display to render to. In theory, this should support hardware
decoding on on a separate GPU that is not actually connected to
any output (like an iGPU which supports more formats than the
external GPU to which the monitor is connected).
However, before this change, only X11 displays were supported as
dummy displays. This caused some graphics drivers (namely
intel-driver) to core dump when they were not actually used as X11
module.
This change introduces support for drm libav displays, which
allows vaapi-copy to run on such cards which are not actually
rendering the X11 output.
Move the screensaver enable/disable determination to a central place,
and call it if the stop-screensaver property is changed.
Also, do not stop the screensaver when in idle mode (i.e. no file is
loaded).
Fixes#3615.
Other than being overly convoluted, this seems to make sense to me.
Except that to get the "rot" transform I have to set flip=true, which
makes no sense at all to me.
Combining rotation and cropping didn't work. It was just completely
broken.
I'm still not sure if this is correct. Chroma positioning seems to be
broken on rotation. There might also be a problem with non-mod-2 frame
sizes. Still, strictly an improvement for both rotated and non-rotated
rendering modes.
Also, this could probably be written in a more elegant way.
Commit aa1047a3 originally added this as:
+ // this is from the DarkPlaces engine, reduces to 3x3. Original code
+ // released under GPL2 or any later version.
According to Rudolf Polzer, the original author (a certain LH) was
actually asked whether it would be ok to put this code under LGPL, and
the author gave his agreement. This code is not from id Software either
(on which large parts of DarkPlaces is based on), which is the main
reason why DarkPlaces is under GPL.
So this note is just confusing, and always has been LGPL. Fix it.
We'd like to get log messages on the output as soon as possible in the
output. I also feel like using fflush() is nicer than using setvbuf().
Who knows how the latter behaves on win32.
The video code can deal fine with feeding software image formats to
hwdec interop drivers. In RPI's case, this is preferable for
performance, working around OpenGL bugs (see RPI firmware issue #666),
and because OpenGL rendering doesn't bring too many advantages due to
RPI supporting GLES 2.0 only.
Maybe a way to force the normal video path is needed later. But
currently, this can be tested by just not loading the hwdec interop
driver.
If you run command-line mpv and set --hwdec to something that does
not load the RPI interop layer, you'll even have to use --hwdec-preload
manually to get it enabled.
Was intended to put the GL layer above the standard console. (But
actually that was done already, and the oddness I'm seeing seems to
be an unrelated bug.)
The code for expanding the ~~ prefix used mp_find_config_file(), which
strictly looks for _existing_ files in any config path (e.g. not just
the user-local one, but also system-wide config). If no such file
exists, it simply returns NULL, which makes the code below just return
the literal, unexpanded path.
Change this so that it'll resolve the path to the user-local config
directory instead.
Requested in #3591.
This should make display-names usable on Windows. It returns a list of
GDI monitor names like "\\.\DISPLAY1". Since it may be useful to get the
monitor that Windows considers associated with the window (with
MonitorFromWindow,) this will always be returned as the first argument.
This monitor is the one used for display-fps and icc-profile-auto.
Seems like a valid use-case. Not sure if I like it calling back into the
config code. Care has to be taken for not letting the config path
resolving code dead-lock (which is why locking details in the msg.c code
are changed).
Fixes#3591.
I'm not sure if this option affects anything or if it's a placebo,
especially since the VO thread is now registered with MMCSS. Still, I
think --priority=high may have helped back when I used mplayer2 on a
netbook. It's also possible that encoding-mode users would want to set
--priority=idle.
Anyway, it was one of the last M_OPT_FIXED options, so fix that.
We always want to use __declspec(selectany) to declare GUIDs, but
manually including <initguid.h> in every file that used GUIDs was
error-prone. Since all <initguid.h> does is define INITGUID and include
<guiddef.h>, we can remove all references to <initguid.h> and just
compile with -DINITGUID to get the same effect.
Also, this partially reverts 622bcb0 by re-adding libuuid.a to the
build, since apparently some GUIDs (such as GUID_NULL) are not declared
in the source file, even when INITGUID is set.
