| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
Moves the DXLockObjectsNV call to after PresentEx. This fixes an issue
where the presented image is a single frame late. This may be due to
DXLockObjectsNV locking the render target before StretchRect is done.
The spec indicates that the lock call should provide synchronization
for the resource, so this may be due to a driver bug.
|
|
|
|
|
|
|
|
|
| |
The printout of available modes that you can get with --drm-mode=-1
(with -vo drm or --opengl-backend=drm) does not include the refresh
rate in the printout, which is quite useful to know, if one is to
choose for instance 23.98, or 24 Hz for film material.
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
|
|
| |
Apparently this is virtually identical to Panasonic's V-Log, but using
the constants from S-Log1 and an extra scaling coefficient to make the
S-Log1 curve less limited. Whatever floats their NIH boat, I guess.
Source: https://pro.sony.com/bbsccms/assets/files/micro/dmpc/training/S-Log2_Technical_PaperV1_0.pdf
|
|
|
|
|
|
|
|
| |
Source: https://pro.sony.com/bbsccms/assets/files/mkt/cinema/solutions/slog_manual.pdf
Not 100% confident in the implementation since the values from the spec
seem to be very subtly off (~1%), but it should be close enough for
practical purposes.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This preserves channel balance better and helps reduce discoloration due
to nonlinear tone mapping.
I wasn't sure whether to stuff this inside pass_color_manage or
pass_tone_map but decided for the former because adding the extra
mp_csp_prim would have made the signature of the latter longer than
80col, and also because the `mp_get_cms_matrix` below it basically does
the same thing anyway, so it doesn't look that out of place. Also why is
this justification longer than the actual description of the algorithm
and what it's good for?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces (yet another..) mp_colorspace members, an enum `light`
(for lack of a better name) which basically tells us whether we're
dealing with scene-referred or display-referred light, but also a bit
more metadata (in which way is the scene-referred light expected to be
mapped to the display?).
The addition of this parameter accomplishes two goals:
1. Allows us to actually support HLG more-or-less correctly[1]
2. Allows people playing back direct “camera” content (e.g. v-log or
s-log2) to treat it as scene-referred instead of display-referred
[1] Even better would be to use the display-referred OOTF instead of the
idealized OOTF, but this would require either native HLG support in
LittleCMS (unlikely) or more communication between lcms.c and
video_shaders.c than I'm remotely comfortable with
That being said, in principle we could switch our usage of the BT.1886
EOTF to the BT.709 OETF instead and treat BT.709 content as being
scene-referred under application of the 709+1886 OOTF; which moves that
particular conversion from the 3dlut to the shader code; but also allows
a) users like UliZappe to turn it off and b) supporting the full HLG
OOTF in the same framework. But I think I prefer things as they are
right now.
|
|
|
|
|
|
|
|
|
|
| |
st2084 and std-b67 are really weird names for PQ and HLG, which is what
everybody else (including e.g. the ITU-R) calls them. Follow their
example.
I decided against naming them bt2020-pq and bt2020-hlg because it's not
necessary in this case. The standard name is only used for the other
colorspaces etc. because those literally have no other names.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
List of changes:
1. Kill nom_peak, since it's a pointless non-field that stores nothing
of value and is _always_ derived from ref_white anyway.
2. Kill ref_white/--target-brightness, because the only case it really
existed for (PQ) actually doesn't need to be this general: According
to ITU-R BT.2100, PQ *always* assumes a reference monitor with a
white point of 100 cd/m².
3. Improve documentation and comments surrounding this stuff.
4. Clean up some of the code in general. Move stuff where it belongs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
image_writer.c has code originating from vf_screenshot.c, vo_jpeg.c, and
potentially others. vo_image.c is based on a bunch of those VOs as well,
and the intention was to replace them with a single codebase.
vo_tga.c was written by someone who was not or not could be contacted,
but it doesn't matter anyway, as no code from that initial patch was
used.
One rather old patch (57f77bb41a9) reordered by libjpeg patch API calls,
and the author of the patch was not contacted. But at least with the
smoothing_factor override removed, this pretty much exactly corresponds
to the official libjpeg API example (and might even reflect a change to
those - didn't dig deeper). This removes the -jpeg-smooth option. While
we're at it, remove all the other dropped jpeg options from the manpage
(which was forgotten in past changes).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This file is an leftover from when img_format.h was changed from using
the ancient FourCCs (based on Microsoft multimedia conventions) for
pixel formats to a simple enum. The remaining cases still inherently
used FourCCs for whatever reasons.
Instead of worrying about residual copyrights in this file, just move it
into code we don't want to relicense (the ancient Linux TV code). We
have to fix some other code depending on it. For the most part, we just
replace the MP_FOURCC macro with libavutil's MKTAG (although the macro
definition is exactly the same). In demux_raw, we drop some pre-defined
FourCCs, but it's not like it matters. (Instead of
--demuxer-rawvideo-format use --demuxer-rawvideo-mp-format.)
|
|
|
|
|
|
| |
All relevant authors have agreed.
Also correct an unrelated entry in the "Copyright" file.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Quite chaotic history, which code being moved, refactored, duplicated,
unified a bunch of times. But I think everything is covered by LGPL
agreements.
In one case, cehoyos (who didn't agree) applied a patch by someone who
agreed, but didn't change anything (except weirdly adding German
translations). In another case, cehoyos moved code covered by LGPL
agreements (without changing it), which was later used for some other
code. We consider both cases not relevant for copyright.
win_state.c/.h is similar, but pending for reply by the author of
2ab259e68 (I guess).
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In GLES 2 mode, we can do dither, but "fruit" dithering is still out of
the question, because it does not support any high depth textures.
(Actually we probably could use an 8 bit texture too for this, at least
with small matrix sizes, but it's still too much of a pain to convert
the data, so why bother.)
This is actually a regression; before this, forcibly enabling dumb mode
due to low GL caps actually happened to avoid this case.
Fixes #4519.
|
| |
|
|
|
|
|
| |
d8a3b10f4 was supposed to change this (as reflected in the man page and
commit message), I just forgot.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I call it `mobius` because apparently the form f(x) = (cx+a)/(dx+b) is
called a Möbius transform, which is the algorithm this is based on. In
the extremes it becomes `reinhard` (param=0.0 and `clip` (param=1.0),
smoothly transitioning between the two depending on the parameter.
This is a useful tone mapping algorithm since the tunable mobius
transform allows the user to decide the trade-off between color accuracy
and detail preservation on a continuous scale. The default of 0.3 is
already far more accurate than `reinhard` while also being reasonably
good at preserving highlights, without suffering from the overall
brightness drop and color distortion of `hable`.
For these reasons, make this the new default. Also expand and improve
the documentation for these tone mapping functions.
|
|
|
|
|
|
| |
Unfortunately quite a mess, in particular due to the need to have some
compatibility with the old API. (The old API will be supported only in
short term.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the drm video output is used under VT with a terminal multiplexer
like screen, the VT_SETMODE ioctl call will fail since the controlling
terminal is a pseudoterminal instead of a real one, thus the VT switcher
will be unavailable.
The problem is, the wait_events function inside vo_drm.c will test for
this, and will do nothing if the switcher is not active. Normally, this
would not be noticed, however, when you pause a video, or if you're playing
multiple image files, mpv will suddenly start busy waiting on a single
core.
I confirmed this by building mpv with gprof support, in a few seconds,
wait_events got called about 90 million times.
So I added a fallback, when the VT switcher is not availble, just use the
vo_wait_default function. I tested it and it's working well so far.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In a multi GPU scenario, it may be desirable to use different GPUs
for decode and display responsibilities. For example, if a secondary
GPU has better video decoding capabilities.
In such a scenario, we need to initialise a separate context for each
GPU, and use the display context in hwdec_cuda, while passing the
decode context to avcodec.
Once that's done, the actually hand-off between the two GPUs is
transparent to us (It happens during the cuMemcpy2D operation which
copies the decoded frame from a cuda buffer to the OpenGL texture).
In the end, the bulk of the work is around introducing a new
configuration option to specify the decode device.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The new API has literally no advantages (other than that we can drop
mp_vt_download_image and other things later), but it's sort-of uniform
with the other hwaccels.
"--videotoolbox-format=no" is not supported with the new API, because it
doesn't "fit in". Probably could be added later again.
The iOS code change is untested (no way to test).
|
|
|
|
|
|
|
|
| |
when quitting mpv during the System fullscreen animation cocoa can't
reset some flags properly and won't reset the Dock hiding behaviour
to it's previous state.
Fixes #4400
|
|
|
|
|
|
|
|
|
| |
This was broken in e0250b9604b2. In some cases, device creation will
succeed, but creating an EGL context on the device will fail. With
--angle-renderer=auto, it should try to create the context again on a
D3D9 device.
This fixes mpv in Windows Vista on VirtualBox for me.
|
|
|
|
|
|
|
|
|
|
|
| |
This was added in 3f268cc4f2a4 because it wasn't clear whether
WM_NCCREATE could be used to send a context pointer from CreateWindowEx
to the window procedure. WM_NCCREATE isn't always the first message sent
to a window, but this seems to be because of an undocumented but
well-known bug where, for top-level overlapped windows, a spurious
WM_GETMINMAXINFO arrives first instead. The WM_GETMINMAXINFO can be
safely ignored, so it is still okay to pass the context struct in
WM_NCCREATE.
|
|
|
|
|
|
|
| |
mpv's mouse button numbering is based on X11, which means XBUTTON1 and 2
on Windows (the "back" and "forward" buttons) should map to MOUSE_BTN7
and 8 in mpv. MOUSE_BTN5 and 6 refer to the horizontal scroll buttons on
mouses that have them.
|
|
|
|
|
|
|
|
|
|
|
| |
Windows doesn't have a way to distinguish "precise" mouse wheel events
and events from regular notched mouse wheels. A notched wheel should
always send events with a delta of 120, but a precise wheel could also
happen to send 120 if multiple scroll events are coalesced (and to make
things even harder, some buggy Microsoft drivers send deltas less than
120, even for notched wheels.) Since there is no distinction, but
MP_AXIS_* keycodes can hold more information (the delta value,) send
MP_AXIS_* events for both kinds of mouse wheel scrolling.
|
|
|
|
|
|
|
|
|
|
|
| |
TLS is a headache. We should avoid it if we can.
The involved mechanism is unfortunately entangled with the unfortunate
libmpv API for returning pointers to host API objects. This has to be
kept until we change the API somehow.
Practically untested out of pure laziness. I'm sure I'll get a bunch of
reports if it's broken.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most contributors have agreed. vo.c requires a "driver" entry for each
video output - we assume that if someone who didn't agree to LGPL added
a line, it's fine for vo.c to be LGPL anyway. If the affected video
output is not disabled at compilation time, the resulting binary will be
GPL anyway.
One problem are the changes by Nick Kurshev (usually using "nick" as SVN
username). He could not be reached. I believe all changes to his files
are actually gone, but here is a detailed listing:
fa1d5742bc: nick introduces a new VO API. It was removed in 64bedd9683.
Some of this was replaced by VOCTRLs are introduced in 7c51652a1b,
obviously replacing at least some functionality by his API.
b587a3d642: nick adds a vo_tune_info_t struct. Removed in 64bedd9683
too.
9caad2c29a: nick adds some VOCTRLs, which were silently removed in
8cc5ba5ab8 (they became unused probably with the VIDIX removal).
340183b0e9: nick adds VO-based screenshots, which got removed in
2f4b840f62. Strangely the same name was introduced in 01cf896a2f again,
but this is a coincidence and worked differently (also it was removed
yet again in 2858232220).
104c125e6d: nick adds an option for "direct rendering". It was renamed
in 6403904ae9 and fully removed in e48b21dd87.
5ddd8e92a1: nick adds code to check the VO driver preinit arg to every
single VO driver. The argument itself and any possibly remaining code
associated with it was removed in 1f5ffe7d30.
f6878753fb: nick adds header inclusion guards. We assume this is not
relevant for copyright.
Some of nick's code was merely moved to other files, such as the
equalizer stuff added in 555c676683 and moved in 4db72f6a80 and
12579136ff, and don't affect copyright of these files anymore.
Other notes:
fef7b17c34: a patch by someone who wasn't asked for relicensing added a
symbol that was removed again in 1b09f4633.
4a8a46fafd: author probably didn't agree to LGPL, but the function
signature was changed later on anyway, and nothing of this is left.
7b25afd742: the same author adds a symbol to what is vo.h today, which
this relicensing commit removes, as it was unused. (It's not clear
whether the mere symbol is copyrightable, but no need to take a risk.)
3a406e94d7, 9dd8f241ac: slave mode things by someone who couldn't be
reached. This aspect of the old slave mode was completely removed.
bbeb54d80a: patch by someone who was not asked, but the added code was
completely removed again.
|
|
|
|
|
|
|
|
| |
Until now, the texture pointer was stored in plane 1, and the texture
array index was in plane 2. Move this down to plane 0 and plane 1. This
is to align it to the new WIP D3D11 decoding API in Libav, where we
decided that there is no reason to avoid setting plane 0, and that it
would be less weird to start at plane 0.
|
|
|
|
|
|
|
|
| |
This reverts commit 142b2f23d4293, and replaces it with another try. The
previous attempt removed the overlay on every rendering, because the
normal rendering path actually unrefs the mp_image. Consequently,
unmap_current_image() was completely inappropriate for removing the
overlay.
|
|
|
|
|
| |
This should make vo_opengl_cb uninit remove the frame, even if the
renderer and OpenGL state remains active.
|
|
|
|
|
| |
Could be broken after the previous commit removed finding the GL include
dir.
|
|
|
|
|
|
|
|
|
|
| |
This drops support for the old libavcodec APIs. Now FFmpeg 3.3 or FFmpeg
git is required. Libav has no release with the new APIs yet, so for
Libav git as of a few weeks or months ago or so is required if you want
to use Libav.
Not much actually changes in hwdec_vaegl.c - some code is removed, but
the reindentation inflates the diff.
|
|
|
|
|
|
|
| |
Reduces the ifdeffery, which is good and will avoid silent breakages, or
weird behavior if a lib is omitted.
Also reorder the x11_common.c include statements.
|
|
|
|
|
| |
Specifically, this field must never be 0 (and the option can naturally
not be 0 in any way, unless it wasn't initialized correctly).
|
|
|
|
|
|
|
|
|
|
|
| |
due to the System inherent fullscreen animation the option and the
actual fullscreen state can be out of sync, leading to a wrongly
reported unfs window size in the time of the animation.
just always fall back to the window size, we keep track of, when we
either are in fullscreen or are currently switching to it.
Fixes #4323
|
|
|
|
|
|
|
|
| |
Wayland is still too amateurish, and multiple features don't work,
including critical ones. There is no solution in sight, so prefer X11.
(Which seems to mostly work ok via xwayland.)
Once all problems are solved, the defaults can be switched back.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gl_headers.h is basically header_fixes.h done consequently. It contains
all OpenGL defines (and some typedefs) we need. We don't include GL
headers provided by the system anymore.
Some care has to be taken by certain windowing APIs including all of
gl.h anyway. Then the definitions could clash. Fortunately, redefining
preprocessor symbols to the same content is allowed and ignored. Also,
redefining typedefs to the same thing is allowed in C11. Apparently the
latter is not allowed in C99, so there is an imperfect attempt to avoid
the typedefs if required API symbols are apparently present already.
The nost risky part about this are the standard typedefs and GLAPIENTRY.
The latter is different only on win32 (and at least consistently so).
The typedefs are mostly based on stdint.h typedefs, which khrplatform.h
clumsily emulates on platforms which don't have it. The biggest
difference is that we define GLsizeiptr directly to ptrdiff_t, instead
of checking for the _WIN64 symbol and defining it to long or long long.
This also typedefs GLsync to __GLsync, just like the khronos headers.
Although symbols prefixed with __ are implementation reserved, khronos
also violates this rule, and having the same definition as khronos will
avoid problems on duplicate definitions.
We can simplify the build scripts too. The ios-gl check seems a bit
wrong now (what we really want to test for is EAGLContext), but I can't
test and thus can't improve it.
cuda_dynamic.h redefined two GL symbols; just include the new headers
directly instead.
|
|
|
|
|
|
|
| |
This is pretty trivial, but also quite annoying due to details like
mismatching eglGetProcAddress() function signature (most callers just
cast the function pointer), and ARM/Linux hacks. So move them all to one
place.
|
|
|
|
|
|
|
|
|
| |
With the recent GLES3 header detection, and if ANGLE is in the search
path, the ANGLE headers will be used over the desktop GL ones. It
appears the ANGLE headers do not include <windows.h>, which leads to the
dxinterop code to fail building. Oops.
Fix this by including <windows.h> is dxinterop is compiled in.
|
|
|
|
|
|
|
|
| |
It appears we expect IOS to provide GLES 3. The IOS block contains all
symbols from the GLES block. Weirdly not all, so it's possible that some
symbols will be redefined, which is annoying, but harmless. I don't have
an iOS setup to test, otherwise it's likely that a modification of the
IOS include statements would take care of this.
|
|
|
|
|
| |
There's no reason to make it Android specific, as it uses standard
include paths.
|
|
|
|
|
|
|
| |
Previously, the shared behaviour for each mouse-button message lived at
the bottom of the WndProc. Move it into handle_mouse_down/up functions
(similar to the handle_key_down/up functions.) This makes the WndProc
slightly less complicated. There should be no change in behaviour.
|
|
|
|
|
|
| |
Regression due to 03fe506. It accidentally changed the default value if
glGetTexLevelParameteriv() is not available, which is the case with
ANGLE.
|
|