| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
This will be pretty useful to let mpv automatically change VO parameters based
on ambient lighting conditions.
The conversion code and polinomial equation from Apple LMU values to Lux is
taken from Firefox: their license, MPL is GPL compatible and allows
relicensing to GPL (MPL is more liberal).
|
|
|
|
|
|
|
|
|
| |
This warning wasn't overly helpful in the past, and warned against
perfectly fine code. But at least with recent gcc versions, this is the
warning that complains about assignments in if expressions (why???), so
we want to enable it.
Also change all the code this warning complains about for no reason.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Semi-important, because --hwdec=dxva2 outputs NV12, and we really don't
want people to end up with the "old" StretchRect method.
Unfortunately, I couldn't actually get it to work. It seems most D3D
drivers (including the wine D3D implementation) reject D3DFMT_A8L8,
and I could not find any other 2-channel 8 bit Direct3D 9 format. It
seems newer D3D APIs have DXGI_FORMAT_R8G8_UNORM, but there's no way
to get it in D3D9.
Still pushing this; maybe it actually works on some drivers.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Omitted a simple, but devastasting check. Fixed the relevant commits
now.
This reverts commit 8d24e9d9b8ad1b5d82139980eca148dc0f4a1eab.
diff --git a/video/out/gl_video.c b/video/out/gl_video.c
index 9c8a643..f1ea03e 100644
--- a/video/out/gl_video.c
+++ b/video/out/gl_video.c
@@ -1034,9 +1034,9 @@ static void compile_shaders(struct gl_video *p)
shader_def_opt(&header_conv, "USE_CONV_GAMMA", use_conv_gamma);
shader_def_opt(&header_conv, "USE_CONST_LUMA", use_const_luma);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_BT1886",
- gamma_fun == MP_CSP_TRC_BT_1886);
+ use_linear_light && gamma_fun == MP_CSP_TRC_BT_1886);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_SRGB",
- gamma_fun == MP_CSP_TRC_SRGB);
+ use_linear_light && gamma_fun == MP_CSP_TRC_SRGB);
shader_def_opt(&header_conv, "USE_SIGMOID", use_sigmoid);
if (p->opts.alpha_mode > 0 && p->has_alpha && p->plane_count > 3)
shader_def(&header_conv, "USE_ALPHA_PLANE", "3");
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Breaks vo_opengl by default. I'm hot able to fix this myself, because I
have no clue about the overcomplicated color management logic. Also,
whilethis is apparently caused by commit fbacd5, the following commits
all depend on it, so revert them too.
This reverts the following commits:
e141caa97dade07f4d7e0d6c208bcd3493e712ed
653b0dd5295453d9661f673b4ebd02c5ceacf645
729c8b3f641e633474be612e66388c131a1b5c92
fbacd5de31de964f7cd562304ab1c9b4a0d76015
Fixes #1636.
|
|
|
|
|
|
| |
Just use makeFirstResponder on the mpv events view from client code
if you need the built in keyboard events (this is easier for dealing with view
nesting).
|
|
|
|
|
|
|
|
|
|
|
| |
We have MP_CSP_TRC defined, but it wasn't being used by practically
anything. This commit adds missing conversion logic, adds it to
mp_image, and moves the auto-guessing logic to where it should be, in
mp_image_params_guess_csp (and out of vo_opengl).
Note that this also fixes a minor bug: csp_prim was not being copied
between mp_image structs if the format was not YUV in both cases, but
this is wrong - the primaries are always relevant.
|
|
|
|
|
| |
Essentially a leak, but not that bad since it's small and allocated only
once.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the past it happened quite often that flag options (yes/no) were
changed to choice options (yes/no/some more). The problem with this was
that while flag options don't need a parameter, this wasn't the case
with choice options. A hack was introduced to compensate for this:
setting M_OPT_OPTIONAL_PARAM on the option, and an empty string ("") was
added as choice, so that the choice could be used like a flag. So, for
example, "--mute" would set the choice "".
Fix this by 1. not requiring a parameter if there's a "yes" choice, and
2. redirect an empty parameter to "yes". The effect is that a choice
option with the choices ["yes", "no"] is pretty much equivalent to a
flag option.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is based on pretty much the same (somewhat naive) logic right now.
I'm not convinced that the extra logic that eg. madVR includes is worth
enough to warrant heavily confusing the logic for it.
This shouldn't slow down the logic at all in any sane shader compiler,
and indeed it doesn't on any shader compiler that I tested.
Note that this currently doesn't affect cscale at all, due to the weird
implementation details of that.
|
|
|
|
|
|
|
|
|
|
| |
Change test_fbo() so that it checks the FBO lazily, and restructure
check_gl_features() to invoke it only if we know that a FBO will be
needed for a certain enabled feature.
This can avoid strange error messages when using --vo=opengl and the
FBO format does not work. It's also less confusing when reading the
verbose log (users might think that the FBO is actually used, etc.).
|
|
|
|
|
|
|
|
| |
This can happen with the "no-colorkey" suboption. Then the code in
xv_draw_colorkey() can be run before vo_x11_config_vo_window(), when
vo_gc is not allocated yet.
Fixes #1629.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of rendering and upscaling each video frame on every vsync, this
version of the algorithm only draws them once and caches the result,
so the only operation that has to run on every vsync is a cheap linear
interpolation, plus CMS/dithering.
On my machine, this is a huge speedup for 24 Hz content (on a 60 Hz
monitor), up to 120% faster. (The speedup is not quite 250% because of
the overhead that the larger FBOs and CMS provides)
In terms of the implementation, this commit basically swaps
interpolation and upscaling - upscaling is moved to inter_program, and
interpolation is moved to the final_program.
Furthermore, the main bulk of the frame rendering logic (upscaling etc.)
was moved to a separete function, which is called from
gl_video_interpolate_frame only if it's actually necessarily, and
skipped otherwise.
|
|
|
|
|
|
|
|
|
|
| |
GLES2 randomly does not support the transpose parameter in matrix
uniform calls. So we have to do this manually. Sure it was worth to
mutilate the standard just so all these shitty SoC vendors can safe 3
lines of code.
(Obviously trying to handle all of GLES2 to GL 4.x in a single codebase
was a mistake.)
|
|
|
|
|
|
|
| |
GLES2 shaders do not have line continuation characters. Abuse the
HAVE_ARRAYS define to exclude code which uses arrays, and which also
happens to cover all code that defines multi-line macros. (So yes, this
is a hack.)
|
|
|
|
|
|
|
|
| |
This is essentially what it is, and it's a useful for windowing or
downscaling. For upscaling we already have bilinear, no need to cause
extra confusion between biliner and bilinear_slow.
Also made it a bit more well-behaved.
|
|
|
|
|
|
|
|
| |
These are EWA-based versions of the keys B/C splines, of which mitchell
is already a member. They are slightly softer and slightly sharper than
mitchell, respectively.
Very easy to define in terms of things we already have.
|
|
|
|
|
|
| |
mitchell, hermite and catmull_rom are all B/C splines and can share the
code which was already written for mitchell. This just redefines them in
terms of that.
|
|
|
|
|
| |
This is essentially a preconfigured version of ewa_lanczos, with the
"best" parameters for general purpose usage.
|
|
|
|
|
| |
We can now truly pass a radius of 3.2383154841662362 or another
real zero of the jinc function to get a better result.
|
|
|
|
|
|
|
| |
This adds a small check for candidates that could potentially be inside
the radius, but aren't necessarily. This speeds up performance by a
negligible amount on my hardware, but it's mainly a prerequisite for a
further change (using a larger true radius).
|
|
|
|
|
| |
This affects all filters that use it, eg. ewa_lanczos. Setting it to
something like 0.95 can be done to make the filter a bit less blurry.
|
|
|
|
|
|
|
|
|
| |
Previously, this was based on some arbitrary range 1-100, cut off for
no particular reason, and also defined in such a way that higher values
= *less* smoothness. Since it wasn't multiplied by e in the code, the
default had to be 10*e = 28.8539...
Now, it's sane: 1.0 = default, higher = blurrier.
|
|
|
|
|
|
|
|
| |
This filter isn't supposed to have a second parameter in the first
place, all literature only uses a single parameter alpha in both places.
The second parameter doesn't even do anything other than adding a
constant factor, which is normalized by the LUT calculation either way.
|
|
|
|
|
|
| |
This is done mainly for consistency, since all of the EWA filters share
similar properties and it's important to distinguish them for
documentation purposes.
|
|
|
|
|
| |
This is suggested in a thesis by Andreas Gustafsson, and seems to
produce very a bit less ringing than lanczos at high radius.
|
|
|
|
|
|
| |
No point in duplicating this check all over the place. No point in
really having it in the first place, to be perfectly honest, j1 should
not be THAT badly behaved.
|
|
|
|
|
|
|
|
|
|
|
| |
The original filter window was design for a radius based on the true
zero, but we always cut it off at our selection of radius either way (by
necessity, due to the square matrix we sample from).
This window is tweaked from the original (true radius) to our actual
cut-off radius, and hence improves the result in a few edge cases. The
main win is the reduction of code complexity, since we no longer need to
know what the true radius actually is.
|
|
|
|
| |
Not like it matters, and is probably still not entirely correct.
|
|
|
|
|
|
| |
Check the scanf() return value, and don't continue if it doesn't find
both numbers (can happen with GLES 1.0). Also, some implementations can
return NULL from glGetString() if something is "broken".
|
|
|
|
|
|
|
|
|
| |
This is a variation of ewa_lanczos that is sinc-windowed instead of
jinc-windowed. Results are pretty similar, but the logic is simpler.
This could potentially replace the ugly ewa_lanczos code.
It's hard to tell, but from comparing stills I think this one has
slightly less ringing than regular ewa_lanczos.
|
|
|
|
|
|
| |
I've reworked pretty much all the logic to correspond to what the theory
actually describes. With this commit, playback is wonderfully smooth on
my machine.
|
|
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
| |
This should be no problem... but it _might_ help with #1536, so it's
worth a try.
|
|
|
|
| |
This line of code ended up in the wrong block in commit cd6dfcbe.
|
|
|
|
|
| |
Some IR receivers emit this key by default for remote control
buttons. Make it mappable.
|
|
|
|
|
| |
Falls back to the first display in the list returned by xrandr. Not
entirely correct, but makes some people happy (see #1575).
|
|
|
|
|
|
|
|
| |
Makes all keys documented in XF86keysym.h mappable. This requires the
user to deal with numeric keycodes; no names are queried or exported.
This is an easy way to avoid adding all the hundreds of XF86 keys to
our X11 lookup table and mpv's keycode/name list.
|
|
|
|
|
| |
Using prev_pts as the start of the scale was plain wrong. Change it to
prev_vsync.
|
|
|
|
| |
Whatever.
|
|
|
|
| |
No change in behavior.
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit a33b46194c3525cb585cc78b449ec275dbfd7f83.
It turns out FFmpeg really considers this a bug, and fixed it by making
the decoder output the correct pixel format.
Fixes #1565. Reverts the fix #1528, though it should work fine with
a recent git master FFmpeg.
|
|
|
|
|
|
|
|
|
|
| |
This introduces a new option linear-scaling, which is now implied by
srgb, icc-profile and sigmoid-upscaling.
Notably, this means (sigmoidized) linear upscaling is now enabled by
default in opengl-hq mode. The impact should be negligible, and there
has been no observation of negative side effects of sigmoidized scaling,
so it feels safe to do so.
|
|
|
|
| |
This was left over from 61f5a80.
|
|
|
|
| |
This is already done in the common vo.c code.
|
|
|
|
|
| |
If smoothmotion is enabled, and the screen shows an interpolated frame
the moment you pause, redraw a non-interpolated frame.
|
|
|
|
|
|
|
|
| |
Apparently CoreGraphics reports the actual refresh rate. DisplayLink can also
query the nominal refresh rate of the display so we use that as fallback
instead of the fugly 60fps hardcode added in aeb1fca0d.
Props to people on https://github.com/glfw/glfw/issues/137
|
|
|
|
|
|
|
|
|
|
|
|
| |
Comment explains why I have been so doubtful at adding this. The Apple docs
say CGDisplayModeGetRefreshRate is supposed to work only for CRTs, but it
doesn't, and actually works for LCD TVs connected over HDMI and external
displays (at least that's what I'm told, I don't have the hardware to test).
Maybe Apple docs are incorrect.
Since AFAIK Apple doesn't want to give us a better API – maybe in the fear we
might be able to actually write some useful software instead of "apps" –
I decided not to care as well and commit this.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts the default behavior introduced in commit 93feffad. Way too
often libavcodec will return RGB data that has an alpha channel as per
pixel format, but actually contains garbage.
On the other hand, this will actually render garbage color values in
e.g. PNG files (for pixels with alpha==0, the color value should be
essentially ignored, which is what the old alpha blend mode did).
This "fixes" #1528, which is probably a decoder bug (or far less likely,
a broken file).
|
|
|
|
|
| |
Makes it unnecessarily slow. It's still needed if the sigmoid crap is
actually used.
|
|
|
|
|
|
|
|
|
|
| |
Make the lazy gamma initialization less weird, and make the default
value of the "gamma" sub-option 1.0. This means --vo=opengl:help will
list the actual default value.
Also change the lower bound to 0.1 - avoids a division by zero (I don't
know how shaders handle NaN, but it's probably not a good idea to give
them this value).
|
|
|
|
|
|
|
|
|
| |
There was some code accounting for different gamma values for R/G/B.
It's inherited from an old, undocumented MPlayer feature, which was at
some point disabled for convenience by myself (meaning you couldn't
actually set separate gamma because it was removed from the property
interface - mp_csp_copy_equalizer_values() just set them to the same
value). Get rid of these meaningless leftovers.
|
|
|
|
|
| |
This allows a spread of 1.0 in either direction, which is already close
to absurd. Anything higher than that is pretty pointless.
|
|
|
|
|
|
| |
Before this, enabling :gamma in combination with :sigmoid and probably a few
other things results in ugly artifacts because the video isn't clamped until
after the :gamma was applied (or at all, if the cms_matrix is unused).
|
|
|
|
|
|
|
|
| |
At least the opengl-hq VO allocates additional resources when
downscaling a lot, which is just a waste.
Also see #1547 (although I doubt that this is the cause; if it is,
a real fix will be required).
|
|
|
|
|
|
|
|
|
| |
This is somewhat imperfect, because detection of hw decoding APIs is
mostly done on demand, and often avoided if not necessary. (For example,
we know very well that there are no hw decoders for certain codecs.)
This also requires every hwdec backend to identify itself (see hwdec.h
changes).
|
|
|
|
|
|
|
| |
Resizing was happening before reconfig, so src_rect_rot was outdated and
didn't include the rotation. This resulted in corrupted rendering on
initial display, which fixed itself after the first time the window was
somehow resized.
|
|
|
|
|
|
|
|
|
| |
A small simplification. Couldn't be done before, because it was also
used by the OSD code, which required disjoint quads in a single draw
call.
Also mess with the unrelated code in gl_osd.c to simplify it a little
as well.
|
|
|
|
|
|
| |
We still do redundant calls to it, but obviously we can avoid calling it
if we don't want to set a callback at all. May or may not help with
default.
|
|
|
|
| |
Basically, the OpenGL API is crap (it takes an offset as pointer).
|
|
|
|