| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
The cache options were changed, and this commit
fixes the example big-cache profile to use the
new cache options.
|
|\
| |
| |
| |
| |
| | |
Manual changes done:
* Merged the interface-changes under the already master'd changes.
* Moved the hwdec-related option changes to video/decode/vd_lavc.c.
|
| |
| |
| |
| | |
Fixes #5980
|
| |
| |
| |
| |
| |
| | |
Crashes NVIDIA, probably buggy on others. No one ever tests this shit.
See #2192
|
| |
| |
| |
| |
| |
| |
| | |
Rather than the linear cd/m^2 units, these (relative) logarithmic units
lend themselves much better to actually detecting scene changes,
especially since the scene averaging was changed to also work
logarithmically.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In theory our "eye adaptation" algorithm works in both ways, both
darkening bright scenes and brightening dark scenes. But I've always
just prevented the latter with a hard clamp, since I wanted to avoid
blowing up dark scenes into looking funny (and full of noise).
But allowing a tiny bit of over-exposure might be a good thing. I won't
change the default just yet (better let users test), but a moderate
value of 1.2 might be better than the current 1.0 limit. Needs testing
especially on dark scenes.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The previous approach of using an FIR with tunable hard threshold for
scene changes had several problems:
- the FIR involved annoying hard-coded buffer sizes, high VRAM usage,
and the FIR sum was prone to numerical overflow which limited the
number of frames we could average over. We also totally redesign the
scene change detection.
- the hard scene change detection was prone to both false positives and
false negatives, each with their own (annoying) issues.
Scrap this entirely and switch to a dual approach of using a simple
single-pole IIR low pass filter to smooth out noise, while using a
softer scene change curve (with tunable low and high thresholds), based
on `smoothstep`. The IIR filter is extremely simple in its
implementation and has an arbitrarily user-tunable cutoff frequency,
while the smoothstep-based scene change curve provides a good, tunable
tradeoff between adaptation speed and stability - without exhibiting
either of the traditional issues associated with the hard cutoff.
Another way to think about the new options is that the "low threshold"
provides a margin of error within which we don't care about small
fluctuations in the scene (which will therefore be smoothed out by the
IIR filter).
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Instead of desaturating towards luma, we desaturate towards the
per-channel tone mapped version. This essentially proves a smooth
roll-off towards the "hollywood"-style (non-chromatic) tone mapping
algorithm, which works better for bright content, while continuing to
use the "linear" style (chromatic) tone mapping algorithm for primarily
in-gamut content.
We also split up the desaturation algorithm into strength and exponent,
which allows users to use less aggressive desaturation settings without
affecting the overall curve.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Too many broken hardware decoders. Noticed wrong decoding of a video
file encoded with x262 on RX Vega when using VAAPI (Mesa 18.3.2).
Looks fine with swdec and a cheap hardware BD player.
Reverts 017f3d0674e48a587b9e6cd7a48f15519c799c3e
|
| | |
|
| |
| |
| |
| |
| | |
List auto as an option for target-peak, and state that auto is its
default operation.
|
| |
| |
| |
| |
| |
| | |
Describe ReplayGain album-to-track fallback behavior introduced in
commits e392d6610d1e35cc0190c794c151211b0aae83e6 and
be90f2c8dd0431e252e43d5249e89446309113af.
|
| |
| |
| |
| |
| |
| | |
Adapt documentation accordingly and
also, fix an off-by-one check in the code.
closes #6371
|
| | |
|
| |
| |
| |
| |
| |
| | |
--record-file is nice, but only sometimes. If you watch some sort of
livestream which you want to record, it's actually much nicer not to
record what you're currently "seeing", but anything you're receiving.
|
| |
| |
| |
| | |
it's more like an input speed rather than a cache speed, but who cares.
|
|\ \
| |/
|/|
| |
| |
| | |
wm4-commits--merge-edition
This bumps libmpv version to 1.103
|
| |
| |
| |
| |
| |
| | |
The demuxer cache is the only cache now. Might need another change to
combat seeking failures in mp4 etc. The only bad thing is the loss of
cache-speed, which was sort of nice to have.
|
| |
| |
| |
| |
| | |
This code shouldn't even exist in libavformat. If you still need it, you
can enable it via --demuxer-lavf-o.
|
| |
| |
| |
| | |
Often requested, trivial.
|
| |
| |
| |
| |
| | |
These were deprecated almost 2 years ago. Now they happen to be in the
way.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Until now, stopping playback aborted the demuxer and I/O layer violently
by signaling mp_cancel (bound to libavformat's AVIOInterruptCB
mechanism). Change it to try closing them gracefully.
The main purpose is to silence those libavformat errors that happen when
you request termination. Most of libavformat barely cares about the
termination mechanism (AVIOInterruptCB), and essentially it's like the
network connection is abruptly severed, or file I/O suddenly returns I/O
errors. There were issues with dumb TLS warnings, parsers complaining
about incomplete data, and some special protocols that require server
communication to gracefully disconnect.
We still want to abort it forcefully if it refuses to terminate on its
own, so a timeout is required. Users can set the timeout to 0, which
should give them the old behavior.
This also removes the old mechanism that treats certain commands (like
"quit") specially, and tries to terminate the demuxers even if the core
is currently frozen. This is for situations where the core synchronized
to the demuxer or stream layer while network is unresponsive. This in
turn can only happen due to the "program" or "cache-size" properties in
the current code (see one of the previous commits). Also, the old
mechanism doesn't fit particularly well with the new one. We wouldn't
want to abort playback immediately on a "quit" command - the new code is
all about giving it a chance to end it gracefully. We'd need some sort
of watchdog thread or something equally complicated to handle this. So
just remove it.
The change in osd.c is to prevent that it clears the status line while
waiting for termination. The normal status line code doesn't output
anything useful at this point, and the code path taken clears it, both
of which is an annoying behavior change, so just let it show the old
one.
|
| |
| |
| |
| | |
Be a bit more detailed, and discourage disabling it.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The player fully restarts playback when the edition or disk title is
changed. Before this, the player tried to reinitialized playback
partially. For example, it did not print a new "Playing: <file>"
message, and did not send playback end to libmpv users (scripts or
applications).
This playback restart code was a bit messy and could have unforeseen
interactions with various state. There have been bugs before. Since it's
a mostly cosmetic thing for an obscure feature, just change it to a full
restart. This works well, though since it may have consequences for
scripts or client API users, mention it in interface-changes.rst.
|
| |
| |
| |
| |
| | |
Output argument names, whether varargs are used, and indicate optional
arguments correctly (instead of only half of them).
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Before this change, only 1 command or so had named arguments. There is
no reason why other commands can't have them, except that it's a bit of
work to add them.
Commands with variable number of arguments are inherently incompatible
to named arguments, such as the "run" command. They still have dummy
names, but obviously you can't assign multiple values to a single named
argument (unless the argument has an array type, which would be
something different). For now, disallow using named argument APIs with
these commands. This might change later.
2 commands are adjusted to not need a separate default value by changing
flag constants. (The numeric values are C only and can't be set by
users.)
Make the command syntax in the manpage more consistent. Now none of the
allowed choice/flag names are in the command header, and all arguments
are shown with their proper name and quoted with <...>.
Some places in the manpage and the client.h doxygen are updated to
reflect that most commands support named arguments. In addition, try to
improve the documentation of the syntax and need for escaping etc. as
well.
(Or actually most uses of the word "argument" should be "parameter".)
|
| |
| |
| |
| |
| | |
Also clarify this and previously existing differences to standard JSON
in ipc.rst.
|
| |
| |
| |
| |
| | |
For example, we call setmode() to switch a FD from text to binary mode
on garbage OSes.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This affects async commands started by client API, commands with async
capability run in a sync way by client API (think mpv_command_node()
with "subprocess"), and detached async work.
Since scripts might want to do some cleanup work (that might involve
launching processes, don't ask), we don't unconditionally kill
everything on exit, but apply an arbitrary timeout of 2 seconds until
async commands are aborted.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I wanted to put all commands through mpv_command_node_async() instead of
mpv_command_node(). Using synchronous commands over a synchronous
transport doesn't make sense anyway.
This would have used the request_id field in IPC requests as reply ID
for the async commands. But the latter need to be [u]int64, while the
former can be any type. To avoid that we need an extra lookup table for
mapping reply IDs to request_id values, we now require that request_id
fields are integers.
Since this would be an incompatible change, just deprecate non-integers
for now, and plan the change for a later time.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The only effective difference is that the former explicitly checks
whether the JSON value type is string, and errors out if not. The rest
is exactly the same (mpv_set_property_string is mpv_set_property with
MPV_FORMAT_STRING).
It seems silly to keep this, so just remove it.
|
| |
| |
| |
| | |
Also somewhat cleans up mp.command_native_async() error handling.
|
| |
| |
| |
| | |
Now mpv_abort_async_command() can be used to stop the process.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Many asynchronous commands are potentially long running operations, such
as loading something from network or running a foreign process.
Obviously it shouldn't just be possible for them to freeze the player if
they don't terminate as expected. Also, there will be situations where
you want to explicitly stop some of those operations explicitly. So add
an infrastructure for this.
Commands have to support this explicitly. The next commit uses this to
actually add support to a command.
|
| |
| |
| |
| |
| |
| |
| |
| | |
The "run" command is old. I'm not sure why the separate Lua
implementation was added. But maybe it as because the "run" command used
to be limited to a small number of arguments. This limit has been
removed a while ago. In any case, the old implementation is not needed
anymore.
|
| |
| |
| |
| |
| |
| |
| | |
We keep mp.subprocess() with roughly the same semantics for
compatibility with scripts (including the internal ytdl script).
Seems to work with rhe ytdl wrapper. Not tested further.
|
| |
| |
| |
| |
| |
| |
| | |
This supports named arguments. It benefits from the infrastructure of
async commands.
The plan is to reimplement Lua's utils.subprocess() on top of it.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Named arguments should make it easier to have long time compatibility,
even if command arguments get added or removed. They're also much nicer
for commands with a large number of arguments, especially if many
arguments are optional.
As of this commit, this can not be used, because there is no command yet
which supports them. See the following commit.
|
| |
| |
| |
| | |
Might be useful for some.
|
| |
| |
| |
| | |
This was not done sooner out of laziness.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Basically reimplement the async behavior on top of the async command
code. With this, all screenshot commands are async, and the "async"
prefix basically does nothing. The prefix now behaves exactly like with
other commands that use spawn_thread.
This also means using the prefix in the preset input.conf is pointless
(without effect) and misleading, so remove that.
The each_frame mode was actually particularly painful in making this
change, since the player wants to block for it when writing a
screenshot, and generally doesn't fit into the new infrastructure. It
was still relatively easy to reimplement by copying the original command
and then repeating it on each frame. The waiting is reentrant now, so
move the call in video.c to a "safer" spot.
One way to observe how the new semantics interact with everything is
using the mpv repl script and sending a screenshot command through it.
Without async flag, the script will freeze while writing the screenshot
(while playback continues), while with async flag it continues.
|
| | |
|
| |
| |
| |
| |
| | |
Still missing: not freezing when removing a track (i.e. closing demuxer)
with the sub-remove/audio-remove/rescan-external-files commands.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Pretty trivial, since commands can be async now, and the common code
even provides convenience like running commands on a worker thread.
The only ugly thing is that mp_add_external_file() needs an extra flag
for locking. This is because there's still some code which calls this
synchronously from the main thread, and unlocking the core makes no
sense there.
|