| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit:
- Changes some of the #define and variable names for clarification and
adds comments where appropriate.
- Unifies :srgb and :icc-profile, making them fit into the same step of
the decoding process and removing the weird interactions between both
of them.
- Makes :icc-profile take precedence over :srgb (to significantly reduce
the number of confusing and useless special cases)
- Moves BT709 decompanding (approximate or actual) to the shader in all
cases, making it happen before upscaling (instead of the old 0.45
gamma function). This is the simpler and more proper way to do it.
- Enables the approx gamma function to work with :srgb as well due to
this (since they now share the gamma expansion code).
- Renames :icc-approx-gamma to :approx-gamma since it is no longer tied
to the ICC options or LittleCMS.
- Uses gamma 2.4 as input space for the actual 3DLUT, this is now a
pretty arbitrary factor but I picked 2.4 mainly because a higher pure
power value here seems to produce visually better results with wide
gamut profiles, rather then the previous 1.95 or BT.709.
- Adds the input gamma space to the 3dlut cache header in case we change
it more in the future, or even make it user customizable (though I
don't see why the latter would really be necessary).
- Fixes the OSD's gamma when using :srgb, which was previously still
using the old (0.45) approximation in all cases.
- Updates documentation on :srgb, it was still mentioning the old
behavior from circa a year ago.
This commit should serve to both open up and make the CMS/shader code much
more accessible and less confusing/error-prone and simultaneously also
improve the performance of 3DLUTs with wide gamut color spaces.
I would liked to have made it more modular but almost all of these
changes are interdependent, save for the documentation updates.
Note: Right now, the "3DLUT takes precedence over SRGB" logic is just
coded into gl_lcms.c's compile_shaders function. Ideally, this should be
done earlier, when parsing the options (by overriding the actual
opts.srgb flag) and output a warning to the user.
Note: I'm not sure how well this works together with real-world
subtitles that may need to be color corrected as well. I'm not sure
whether :approx-gamma needs to apply to subtitles as well. I'll need to
test this on proper files later.
Note: As of now, linear light scaling is still intrinsically tied to
either :srgb or :icc-profile. It would be thinkable to have this as an
extra option, :linear-scaling or similar, that could be used with or
without the two color management options.
|
|
|
|
|
|
| |
Use the --channels value directly on the AO, instead of doing it only in
the --channels=stereo (default) case and if the decoder output is not
stereo.
|
|
|
|
|
|
|
|
|
|
|
| |
This removes the ringbuffer management from the code, and uses the
generic code added with the previous commit. The result should be
pretty much the same.
The "estimate" sub-option goes away. This estimation is now always
active. The new code for delay estimation is slightly different, and
follows the claim of the jack framework that callbacks are timed
exactly.
|
|
|
|
| |
Helps with testing and debugging.
|
|
|
|
|
|
| |
--ass-style-override=force now attempts to override the 'Default' style.
May or may not work. In some situations it will work, but also mess up
seemingly unrelated things like signs typeset with ASS.
|
| |
|
| |
|
| |
|
|
|
|
| |
I forgot about this.
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous version of the gamma suboption was pretty useless. It could
be used to disable delayed gamma enabling, which is a mechanism to avoid
having to adjust gamma in the shader by default.
Repurpose the suboption and allow setting an exact gamma value with it.
You can already override gamma with the --gamma option as well as the
gamma input property, but these use a weird curve to create the
impression of a linear perceived brightness change when changing the
value. This suboption now allows setting an exact gamma value.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This used to be absolute colorimetric, but relative colorimetric is a
saner default due to the arguments presented in issue #595.
A short summary: In general it doesn't affect much because our eyes
adapt to the white point either way, but if running in windowed mode it
would make the whites seem inconsistent/tinted. For fullscreen
projection it's also undesirable since it reduces the dynamic range
without much benefit (again, since our eyes adapt either way) and it
also breaks calibration against ambient lighting.
This shouldn't change much, since most profile types that aren't 3DLUTs
aren't capable of either of those transforms, and most displays are
calibrated against D65 (same as BT.709 source) either way.
|
|
|
|
|
|
| |
Probably completely useless, at least for now.
Also not very well tested, but initial test seems successful.
|
|
|
|
|
| |
Allow changing all options at runtime, except some cherry-picked
options, which are disabled with M_OPT_FIXED.
|
|
|
|
| |
We removed gettext (which was disabled by default) a while ago.
|
|
|
|
| |
Useful for slave-mode like uses, and not as radical as --no-config.
|
|
|
|
|
| |
This version is clearer on its origin, prevalence and use case and
offers some advice to the user.
|
|
|
|
| |
I forgot about this.
|
|
|
|
|
|
|
|
|
| |
Not sure about this... might redo.
At least this provides a case of a broadcasted event, which requires
per-event data allocation.
See github issue #576.
|
|
|
|
|
|
| |
There are some complications because the client API distinguishes
between integers and floats, while Lua has only "numbers" (which are
usually floats). But I think this should work now.
|
|
|
|
|
|
| |
This uses the value of 1.95 as an approximation for the exact gamma
curve, which replicates the behavior of popular video software including
anything in the Apple ecosystem, as per issue #534.
|
|
|
|
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
Closes #582.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
MP_CMD_COMMAND_LIST commands (used to implement key bindings with
multiple commands) were not checked for abort commands. Implement it.
Remove the remarks about multi-commands being special from the manpage.
Seek coalescing is handled differently now, and the issue with abort
commands is fixed with this commit.
|
| |
|
|
|
|
|
|
| |
Not sure about these deep path-names. Maybe "metadata/0" should work
instead of "metadata/list/0". I'm so unsure about it, that I'm leaving
it open.
|
|
|
|
|
|
| |
The old way still works, and is fine to use. Still discourage it,
because it might conflict with other ways to access this property, such
as the one added in the next commit.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
This is simply not important enough to warrant so much space, and it's
perhaps also very confusing.
Although I'm not fully sure, since this is about the only way that
allows a user to interact with a script, besides key bindings and static
options.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was already an undocumented mechanism provided by
mp.set_key_bindings and other functions, but this was relatively
verbose, and also weird. It was mainly to make the OSC happy (including
being efficient and supporting weird corner cases), while the new
functions try to be a bit simpler.
This also provides a way to let users rebind script-provided commands.
(This mechanism is less efficient, because it's O(n^2) for n added key
bindings, but it shouldn't matter.)
|
|
|
|
|
| |
This comes with a "script_message" input command, which sends these
messages. Used by the following commits.
|
|
|
|
|
| |
E.g. ``mp.get_property("foo", "value")`` will return ``value`` if the
property can't be read.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This uses the previously added sub-property mechanism to export a bunch
of stuff. For example, "video-params/w" now contains the video width.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, the --no-config was explicitly checked in multiple places to
suppress loading of config files.
Add such a check to the config path code itself, and refuse to resolve
_any_ configuration file locations if the option is set.
osc.lua needs a small fixup, because it didn't handle the situation when
no path was returned. There may some of such cases in the C code too,
but I didn't find any on a quick look.
|
|
|
|
| |
This is like passing them to --lua.
|
|
|
|
|
|
|
|
| |
Instead, chain them.
Note that there's no logic to prevent the other event handlers to be run
from an event handler (like it's popular in GUI toolkits), because I
think that's not very useful for this purpose.
|
|
|
|
|
|
|
|
| |
Use a list instead of a table. This makes it easier to provide extended
information about a property, and doesn't require you to fiddle with rhe
RST ASCII-art tables.
Also, extend some property descriptions.
|
| |
|
| |
|
|
|
|
|
| |
Using such a small table is not such a great idea, because you can't put
much information in it, even if you need to.
|
| |
|
| |
|
|
|
|
|
|
| |
It was split at the wrong sentence.
Also, sneak in a reference to mp.suspend.
|
|
|
|
|
|
|
| |
Use of these is "discouraged", but they're there to select these special
cases with the "aspect" property. They really should use some sort of
choice option type, but since it would be some work to make these work
with float values, the simple and dumb alternative was picked.
|
| |
|
| |
|
|
|
|
| |
No other changes, just adding a paragraph break and reflowing the text.
|
| |
|
| |
|
|
|
|
|
| |
Mostly useful for internal reasons. This code will be enabled by
default if mpv is started via the client API.
|
|
|
|
| |
This is slow and unreliable, basically unusable.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Try to make it more intuitive by not requiring hex values. The new way
uses float values in the range 0.0-1.0, separated by '/' (':' was
suggested, but that wouldn't allow color options in sub-options).
Example: --osd-color=1.0/0.0/0.0/0.75
Using the range 0.0-1.0 has the advantage that it could be easily
extended to colors beyond 8 bit.
Details see manpage.
Suggestions for alternative syntax or value ranges are welcome, but be
quick with it.
|
|
|
|
| |
This doesn't need quoting, for some reason.
|
|
|
|
|
|
|
| |
The values set by this new option can be queried by Lua scripts using
the mp.getopt() function. The function takes a string parameter, and
returns the value of the first key that matches. If no key matches, nil
is returned.
|
|
|
|
|
| |
Feature request from github issue #451. Disabled by default, will
probably stay this way.
|
|
|
|
|
| |
Apparently this was forgotten when it was first added, or maybe it's an
arrifact from the rst conversion.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The terminal OSD code includes the handling of the terminal status line,
showing player OSD messages on the terminal, and showing subtitles on
terminal (the latter two only if there is no video window, or if
terminal OSD is forced).
This didn't handle some corner cases correctly. For example, showing an
OSD message on the terminal always cleared the previous line, even if
the line was an important message (or even just the command prompt, if
most other messages were silenced).
Attempt to handle this correctly by keeping track of how many lines the
terminal OSD currently consists of. Since there could be race conditions
with other messages being printed, implement this in msg.c. Now msg.c
expects that MSGL_STATUS messages rewrite the status line, so the caller
is forced to use a single mp_msg() call to set the status line.
Instead of littering print_status() all over the place, update the
status only once per playloop iteration in update_osd_msg(). In audio-
only mode, the status line might now be a little bit off, but it's
perhaps ok.
Print the status line only if it has changed, or if another message was
printed. This might help with extremely slow terminals, although in
audio+video mode, it'll still be updated very often (A-V sync display
changes on every frame).
Instead of hardcoding the terminal sequences, use
terminfo/termcap to get the sequences. Remove the --term-osd-esc option,
which allowed to override the hardcoded escapes - it's useless now.
The fallback for terminals with no escape sequences for moving the
cursor and clearing a line is removed. This somewhat breaks status line
display on these terminals, including the MS Windows console: instead of
querying the terminal size and clearing the line manually by padding the
output with spaces, the line is simply not cleared. I don't expect this
to be a problem on UNIX, and on MS Windows we could emulate escape
sequences. Note that terminal OSD (other than the status line) was
broken anyway on these terminals.
In osd.c, the function get_term_width() is not used anymore, so remove
it. To remind us that the MS Windows console apparently adds a line
break when writint the last column, adjust screen_width in terminal-
win.c accordingly.
|
|
|
|
|
|
|
|
|
| |
Doesn't make any sense anymore. X11 (which was mentioned in the manpage)
autodetects it, and everything else ignored the option values.
Since for incomprehensible reasons the backends and vo.c still need to
exchange information about the screensize using the option fields,
they're not removed yet.
|
|
|
|
|
|
| |
This basically reverts the default as set by commit 812798c5. This seems
to be a matter of taste, but personally I think keeping the pause
setting is better.
|