It's all explained in the DOCS changes. Although this option was always
kind of obscure and pointless. Until it is removed, the only reason for
setting it would be to raise the static default limit, so change its
default to INT_MAX so that it does nothing by default.
Instead of pausing if --keep-open is active, stop
at end but continue playing if seeking backwards.
And then stop again when end is reached.
Signed-off-by: wm4 <wm4@nowhere>
Over the PR, the option was renamed, and the manpage additions were
slightly changed/enhanced.
Also "announce" the plans to undeprecate it with changed semantics
later. The deprecation period is needed to warn script authors and
client API users (etc.) of the change.
This is done because everyone seems to expect --loop to loop the current
file, not the playlist. Even in cases when only 1 file is on the
playlist, the --loop-file semantics seem to be preferred.
Mostly because of ANGLE (sadly).
The implementation became unpleasantly big, but at least it's relatively
self-contained.
I'm not sure to what degree shaders from different drivers are
compatible as in whether a driver would randomly misbehave if it's fed
a binary created by another driver. The useless binayFormat parameter
won't help it, as they can probably easily clash. As usual, OpenGL is
pretty shit here.
Now you can for example do "--vf=hue=h=60" - there is no "hue" filter in
mpv, so libavfilter's will be used.
This has certain caveats (see manpage).
The point of this is providing a relatively smooth transition path to
removing our own filter stuff.
The plan is to nuke the custom filter chain completely. It's not clear
what will happen to the still needed builtin filters (mostly hardware
deinterlacing and vf_vapoursynth). Most likely we'll replace them with
different filter chain concept (whose main purpose will be providing
builtin things and bridging to libavfilter).
The undocumented "warn" options are there to disable deprecation
warnings when the player inserts filter automatically.
The same will be done to audio filters, at a later point.
And also change input.conf to make all screenshots async. (Except the
every-frame mode, which always uses synchronous mode and ignores the
flag.) By default, the "screenshot" command is still asynchronous,
because scripts etc. might depend on this behavior.
This is only partially async. The code for determining the filename is
still always run synchronously. Only encoding the screenshot and writing
it to disk is asynchronous. We explicitly document the exact behavior as
undefined, so it can be changed any time.
Some of this is a bit messy, because I wanted to avoid duplicating the
message display code between sync and async mode. In async mode, this is
called from a worker thread, which is not safe because showing a message
accesses the thread-unsafe OSD code. So the core has to be locked during
this, which implies accessing the core and all that. So the code has
weird locking calls, and we need to do core destruction in a more
"controlled" manner (thus the outstanding_async field).
(What I'd really want would be the OSD simply showing log messages
instead.)
This is pretty untested, so expect bugs.
Fixes#4250.
Obviously, this has no effect on commands which do not support this
explicitly. A later commit will enable this for screenshots.
Also add some wording on mpv_command_async(), which has nothing to do
with this. Having a more elegant, unified behavior would be nice. But
the API function was not created for this - it's merely for running
commands _synchronously_ on the core, but without blocking the client
API caller (if the API user consistently uses only async functions).
for a reason i can just assume some key events can vanish from the
event chain and mpv seems unresponsive.
after quite some testing i could confirm that the events are present at
the first entry point of the event chain, the sendEvent method of the
Application, and that they vanish at a point afterwards. now we use
that entry point to grab keyDown and keyUp events. we also stop
propagating those key events to prevent the no key input' error sound.
if we ever need the key events somewhere down the event chain we need
to start propagating them again. though this is not necessary currently.
"@name:!" becomes simply "@name". This is actually slightly more complex
to parse, but makes for a much simpler syntax and will be less weird to
the user. Suggested by haasn.
The old syntax is now rejected with an error.
Also add some more explicit error checks, instead of e.g. allowing empty
filter names and erroring only when it's not found.
DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL might be buggy on some hardware.
Additionaly DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL might be supported on some
Windows 7 systems with the platform update, but it might have poor
performance. In these cases, the user might want to disable the use of
DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL swap chains with --angle-flip=no.
It should default to true, but setting the filter list via mpv_node
(relevant for client API and Lua scripting) left it to false.
Also "document" the flag.
Basically, see the example in input.rst.
This is better than the "old" vf-toggle method, because it doesn't
require the user to duplicate the filter string in mpv.conf and
input.conf.
Some aspects of this changes are untested, so enjoy your alpha testing.
Add subtitle filter to remove additions for deaf or hard-of-hearing
(SDH). This is for English, but may in part work for others too.
This is an ASS filter and the intention is that it can always be
enabled as it by default do not remove parts that may be normal text.
Harder filtering can be enabled with an additional option.
Signed-off-by: wm4 <wm4@nowhere>
Remove low quality drc filter. Anyone whishing to have dynamic range
compression should use the much more powerful acompressor ffmpeg filter:
mpv --af=lavfi=[acompressor] INPUT
Or with parameters:
mpv --af=lavfi=[acompressor=threshold=-25dB:ratio=3:makeup=8dB] INPUT
Refer to https://ffmpeg.org/ffmpeg-filters.html#acompressor for a full
list of supported parameters.
Signed-off-by: wm4 <wm4@nowhere>
Requested. The property semantics are a bit muddy due to lack of effort.
Anticipated use is different display of cache status, so it should not
matter anyway.
Useful for testing. Unfortunately, the nVidia EGL driver ignores this,
and returns a GLES 3.2 context anyway (which it is allowed to do). Might
still be useable with ANGLE, which will really give you a GLES 2 context
if you ask for it.
As the manpage says, this has no value other than adding bugs.
It uses code based on context_x11.c, and basically does very stripped
down context creation (no alpha support etc.). It uses vdpau for
display, and maps vdpau output surfaces as FBOs to render into them.
This might be good to experiment with asynchronous presentation. For
now, it presents synchronously, with a 4 frame delay (which should whack
off A/V sync). The forced 4 frame delay is probably also why interaction
feels slower.
There are some weird vdpau errors on resizing and uninit. No idea what
causes them.
This is just a pointless refactor with the only goal of making
image_writer_opts.format a number.
The pointless part of it is that instead of using some sort of arbitrary
ID (in place of a file extension string), we use a AV_CODEC_ID_. There
was also some idea of falling back to the libavcodec MJPEG encoder if
mpv was not linked against libjpeg, but this fails. libavcodec insist on
having AV_PIX_FMT_YUVJ420P, which we pretend does not exist, and which
we always map to AV_PIX_FMT_YUV420P (without the J indicating full
range), so encoder init fails. This is pretty dumb, but whatever. The
not-caring factor is raised by the fact that we don't know that we
should convert to full range, because encoders have no proper way to
signal this. (Be reminded that AV_PIX_FMT_YUVJ420P is deprecated.)
I'm not sure what's going on here, but it appears kodi switches forward
and backwards references for advanced VPP deinterlacing modes. This in
turn makes deinterlacing with these modes apparently work. If you don't
switch the directions, you get a stuttering mess.
As far as the libva trace dump is concerned, this makes mpv's libva
deinterlacing API use behave like kodi's, and appears to reproduce
smooth video with advanced libva deinterlacing enabled.
I'm hearing that Mesa actually does it correctly, and I'm not sure what
will happen there. For now, passing "reversal-bug=no" as sub-option to
the vavpp filter will undo this behavior.
wm4
Avi Halachmi (:avih)
Ricardo Constantino
Nicolas F
Dan Oscarsson
Akemi
James Ross-Gowan
Matthias Hunstock
igv
Jan Janssen
Frederick Eaton