| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
No functional changes.
|
|
|
|
|
| |
Using a single gl_transform variable instead of many float ones makes it
easier to see what it's doing. No functional change.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This has been completely broken since commit 93546f0c. But even before,
rotation handling did not make too much sense. In particular, it rotated
the contents of the cropped image, instead of adjusting the crop
rectangle as well. The result was that things like panscan or zooming
did not behave as expected with rotation applied.
The same is true for vertical flipping. Flipping is triggered by
negative image stride. OpenGL does not support flipping the image on
upload, so it's done as part of the rendering. It can be triggered with
--vf=flip, but other filters and even decoders could setup negative
stride to flip the image.
Fix these issues by applying transforms to texture coordinates properly,
and by making rotation and flipping part of these transforms.
This still doesn't work properly for separated scaling. The issue is
that we'd have to adjust how the passes are done. For now, pick a very
stupid solution by rotating the image to a FBO, and then scaling from
that. This has the avantage that the scale logic doesn't have to be
complicated for such a rare case. It could be improved later.
Prescaling is apparently still broken. I don't know if chroma
positioning works properly either. None of this should affect the case
with no rotation.
|
|
|
|
|
|
|
|
|
| |
gl_transform_vec() assumed column-major, while everything else seemed to
assumed row-major memory organization for gl_transform.m. Also,
gl_transform_trans() seems to contain additional confusion.
This didn't matter until now, as everything has been orthogonal, this
the swapped matrix entries were always 0.
|
|
|
|
|
|
|
|
|
| |
If the texture count is lower than 4, entries in va.textcoord[] will
remain uninitialized. While this is unlikely to be a problem (since
these values are unused on the shader side too), it's not nice and might
explain some things which have shown up in valgrind.
Fix by always initializing the whole thing.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of reallocating almost all of the shader string several times
per pass, build it into a fixed buffer that will be reallocated as
needed.
While this still uses a linear search and full comparison of the shader
text, this will compare the shader's string length first before doing a
full comparison as a nice side effect. (That's also why the fragment
shader is compared first - it's more likely to be different for
different cache entries than the vertex shader stub.)
|
|
|
|
|
| |
Use bstr as appending buffer, which should avoid frequent reallocation
and copying. The previous commit should help with this a little.
|
|
|
|
|
| |
Broken in commit d6c99c85. vo_opengl_cb.c adds the corner case that
p->osd can be NULL. This make opengl-cb always crash.
|
|
|
|
|
|
|
|
|
| |
Shader miscompilation and bad output.
Regression probably since commit 93546f0c (or one of the following
ones).
Fixes #2982.
|
|
|
|
|
|
|
|
|
| |
Glitches when resizing are still possible, but are reduced. Other VOs
could support this too, but don't need to do so.
(Totally avoiding glitches would be much more effort, and probably not
worth the trouble. How about you just watch the video the player is
playing, instead of spending your time resizing the window.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, we have tried to create a GL 3.0 context. The main reason for
this is that many Mesa-based drivers did not support anything better.
But some drivers (Mesa AMD) will not report a higher OpenGL version,
because their compatibility mode is restricted. While later GL features
are reported as extensions just fine, there doesn't seem to be a way to
determine or enable higher GLSL versions.
Add some more shitty hacks to try to deal with this messed up situation,
and try to probe each interesting GL version separately (starting with
3.3, then 3.2 etc.). Other backends might suffer from similar problems,
but these will have to deal with it on their own.
Probably fixes #2938, or maybe not.
|
|
|
|
|
|
|
|
|
| |
Prevents an infinite loop of configure event and set_fullscreen
request on Weston and other compositors respecting the protocol.
Fixes #2817
This reverts commit eb6b2b6e50e6e3d3db41190ad818d8b966750734.
|
|
|
|
|
|
|
|
|
|
|
| |
converted_imgfmt will be used by the renderer logic to build an
appropriate shader chain. It doesn't influence the format of any
textures. Thus it doesn't matter whether the hw video surface is mapped
as RGB or RGBA. What matters is if the video actually contains alpha or
not. Since virtually all hardware decoder do not support alpha in any
way, this can be hardcoded as "no alpha".
This avoids unnecessary GPU work.
|
|
|
|
|
|
|
|
| |
This also gets rid of the kind of hard to read texture swizzle setup and
turns it into something dumber.
Assumes that we don't create any FBOs with 2 channel formats. (Only the
video source textures are handled by this commit.)
|
|
|
|
|
|
| |
Regression since commit 93546f0c.
Fixes #2956.
|
|
|
|
|
|
|
|
|
| |
Previously, gl->DXOpenDeviceNV was called twice using dxva2 with dxinterop. AMD
drivers refused to allow this. With this commit, context_dxinterop sets its own
implementation of MPGetNativeDisplay, which can return either a
IDirect3DDevice9Ex or a dxinterop_device_HANDLE depending on the "name" request
string. hwdec_dxva2gldx then requests both of these avoiding the need to call
gl->DXOpenDeviceNV a second time.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Drag&drop mechanisms typically support multiple types for the drop data.
Move most of the logic which types are accepted and preferred to
event.c, where the data is also interpreted.
(Maybe sorting the types by assigning scores is over-engineered, since
they're already sorted by preference, but it's actually not much more
code.)
Not very interesting/meaningful yet, but preparation for the next
commit.
|
|
|
|
|
|
| |
Reduces VO access and makes the code more self-contained. (One day the
windowing backend code should not access the VO anymore. We're just not
quite there yet.)
|
|
|
|
|
|
| |
Like dxinterop, this uses StretchRect or RGB conversion. This is unavoidable as
long as we use the dxva2 API, as there is no way to access the raw hardware
decoded Direct3D9 surfaces.
|
|
|
|
| |
Slightly improvement over the previous commit.
|
| |
|
| |
|
|
|
|
|
|
| |
The default of 1.0 was basically making half the algorithm do nothing,
since it turned off all diagonal contributions. The upstream default is
0.6, and this produces a more reasonable image.
|
|
|
|
|
|
|
|
| |
The values were changed to reflect an upstream change in the source for
the super-xBR implementation.
The anti-ringing code was basically not working at all, the new
algorithm _significantly_ improves the result (reduces ringing).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a fresh implementation from scratch that carries with it
significantly less baggage and verbosity from the previous (ported)
version.
The actual values for the masks and such were copied from the
current code. Behavior and performance should be unaffected.
An important difference between the old code and the new code is that
the new code always explicitly samples from the first component, rather
than being able to process multiple planes at once.
Since prescale-luma only affects luma, I deemed this unnecessary. May
change in the future, if prescale-chroma ever gets implemented. But
prescaling multiple planes would be slow to do this way. (Better would
be to generalize it to differently-sized vectors)
|
| |
|
|
|
|
|
|
| |
Instead of hard-coding the logic and planes to skip, factor this out
to a reusible function, and instead add the number of relevant
coordinates to the texture state.
|
|
|
|
|
|
| |
Since prescale now literally only affects the luma plane (and the
filters are all designed for luma-only operation either way), the option
has been renamed and the documentation updated to clarify this.
|
|
|
|
|
| |
There was no real point in hard-coding these all over the place,
especially since the order was sort of arbitrary and confusing.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a pretty major rewrite of the internal texture binding
mechanic, which makes it more flexible.
In general, the difference between the old and current approaches is
that now, all texture description is held in a struct img_tex and only
explicitly bound with pass_bind. (Once bound, a texture unit is assumed
to be set in stone and no longer tied to the img_tex)
This approach makes the code inside pass_read_video significantly more
flexible and cuts down on the number of weird special cases and
spaghetti logic.
It also has some improvements, e.g. cutting down greatly on the number
of unnecessary conversion passes inside pass_read_video (which was
previously mostly done to cope with the fact that the alternative would
have resulted in a combinatorial explosion of code complexity).
Some other notable changes (and potential improvements):
- texture expansion is now *always* handled in pass_read_video, and the
colormatrix never does this anymore. (Which means the code could
probably be removed from the colormatrix generation logic, modulo some
other VOs)
- struct fbo_tex now stores both its "physical" and "logical"
(configured) size, which cuts down on the amount of width/height
baggage on some function calls
- vo_opengl can now technically support textures with different bit
depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries
inside img_format.c doesn't export this (nor does ffmpeg support it,
really) so the status quo of using the same tex_mul for all planes is
kept.
- dumb_mode is now only needed because of the indirect_fbo being in the
main rendering pipeline. If we reintroduce p->use_indirect and thread
a transform through the entire program this could be skipped where
unnecessary, allowing for the removal of dumb_mode. But I'm not sure
how to do this in a clean way. (Which is part of why it got introduced
to begin with)
- It would be trivial to resurrect source-shader now (it would just be
one extra 'if' inside pass_read_video).
|
|
|
|
|
| |
The wayland client API crashes intentionally when trying to free NULL
objects. (Thanks.)
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Commit 2f562825 didn't remove the "color" declaration for these. Since
the shader header already declares it, shader compilation broke.
|
|
|
|
|
|
| |
Why was this done so stupidly, with so many complicated special cases,
before? Declare it once so the shader bits don't have to figure out where
and when to do so themselves.
|
|
|
|
|
| |
pixel_size is often used variable, also reciprocal is a costly operation
for AMD and older nVidia (prior to Kepler) GPUs.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The WGL_NV_DX_interop spec says that a shared IDirect3DSurface9 must not
be lockable, but off-screen plain surfaces are always lockable and using
them causes Nvidia drivers to crash. Use a rendertarget for the shared
surface instead.
This also changes the name of the DX_interop handle for the rendertarget
to match the name of the DirectX object (rather than the GL one) to
match the convention used in context_dxinterop.c.
|
|
|
|
|
| |
p->gl_target and plane->gl_target are always the same value here, but
semantically plane->gl_target is the correct one.
|
|
|
|
| |
Fixes #2831.
|
|
|
|
|
|
|
|
| |
Apple crap (namely hardware decoding interop) forces us to use rectangle
textures for input. But after that we continue with normal textures.
This was not considered for debanding, and the sampler type used for it
can be different depending on the exact render chain. Simply use the
target type of the input texture.
|
|
|
|
| |
Wasn't really necessary as it was equivalent to gl-dxinterop.
|
|
|
|
|
| |
Use dxva2 surface to fill RGB IDirect3DSurface9 shared with opengl via
DXRegisterObjectNV.
|
|
|
|
|
|
|
| |
* use mp_HRESULT_to_str/mp_LastError_to_str
* make some messages non-identical
* replace "GL" -> "OpenGL"
* change some MP_FATAL to MP_ERR that don't actually kill the vo
|
|
|
|
|
|
| |
A client API user is allowed to call mpv_opengl_cb_uninit_gl() followed
by mpv_opengl_cb_init_gl(). This crashed; fix it by fixing the lifetime
of ctx->gl.
|
|
|
|
|
|
|
|
|
| |
It thinks that integer_conv_fbo[index] is implied to be accessed with up
to index=5. Although that is theoretical only, it has a point that this
makes no sense. Use the same constant for the array allocation, to make
it more uniform and robust.
Fixes CID 1350060.
|
|
|
|
|
|
| |
* Add Android-specific OpenGL ES feature and checks
* Add missing GL_* symbols for Android
(list gathered by Ilya Zhuravlev <whatever@xyz.is>)
|
|
|
|
|
|
|
| |
The ctx->redrawing field signals whether flip_page() should block. Do
not block if a black frame (i.e. nothing) is to be rendered.
Also, frame==NULL can never happen.
|
|
|
|
| |
This is "more correct". See #2798.
|
|
|
|
|
| |
Check and set the fullscreen mode on every surface configure event.
This prevents gnome from resizing mpvs fullscreen window to a smaller size.
|
|
|
|
|
|
| |
This makes it possible to set video size and position using the
--geometry and/or --autofit options. It's also possible to switch
between fullscreen/non-fullscreen playback during runtime.
|
|
|
|
|
|
|
|
| |
This is the "unicode" version of it. It appears Firefox uses it now?
I'm not sure if we still need to support the old variant, but hopefully
not.
Fixes #2782.
|
|
|
|
|
|
|
| |
Since there can be multiple backends for a single API (vaapi can use GLX
or EGL), not logging the exact backend name is annoying. So add it. At
the same time, there is no need to duplicate the name as used by the
--hwdec options, so replace it with using the numeric hwdec API ID.
|
|
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
| |
This is a huge win when playing yuv420p10 on ANGLE - the 2 conversion
stages for planes 1 and 2 and the chroma merging stage are all merged
into one.
|
|
|
|
|
|
|
|
| |
GLES requires this. Some more common sampler types have default
precisions, but not usampler2D. Newer ANGLE builds verify this more
strictly than older builds, so this wasn't caught before.
Fixes #2761.
|
|
|
|
|
| |
The previous approach was too naive, and can e.g. ruin playback if
scheduling switches e.g. between 1 and 2 vsync per frame.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GLES does not support high bit depth fixed point textures for unknown
reasons, so direct 10 bit input is not possible. But we can still use
integer textures, which are supported by GLES 3.0. These store integer
data just like the standard fixed point textures, except they are not
normalized on sampling. They also don't support bilinear filtering, and
require a special sampler ("usampler2D").
While these texture formats enable us to shuffle the data to the GPU,
they're rather impractical with the requirements mentioned above and our
current architecture. One problem is that most code assumes it can
always use bilinear scaling (even if bilinear is never used when using
appropriate scale/cscale options). Another is that we don't have any
concept of running a functi |