summaryrefslogtreecommitdiffstats
path: root/video/out/opengl
Commit message (Collapse)AuthorAgeFilesLines
* vo_opengl: minor coding style adjustmentwm42016-03-241-3/+4
|
* vo_opengl: utils: some more minor shader string building optimizationwm42016-03-241-23/+35
| | | | | | | | | | | | 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.)
* vo_opengl: utils: slightly optimize shader string buildingwm42016-03-231-22/+21
| | | | | Use bstr as appending buffer, which should avoid frequent reallocation and copying. The previous commit should help with this a little.
* vo_opengl_cb: fix NULL derefwm42016-03-231-1/+2
| | | | | Broken in commit d6c99c85. vo_opengl_cb.c adds the corner case that p->osd can be NULL. This make opengl-cb always crash.
* vo_opengl: fix blend-subtitles=video in some caseswm42016-03-221-0/+1
| | | | | | | | | Shader miscompilation and bad output. Regression probably since commit 93546f0c (or one of the following ones). Fixes #2982.
* vo_opengl, osd: allow osc.lua to react faster on resizeswm42016-03-213-10/+25
| | | | | | | | | 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.)
* vo_opengl: GLX: try to create 3.3 core profile contextwm42016-03-193-6/+26
| | | | | | | | | | | | | | | | 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.
* vo_opengl: dxva2egl: ignore alpha component in the mapped videowm42016-03-171-3/+1
| | | | | | | | | | | 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.
* vo_opengl: fix operation without GL_ARB_texture_rgwm42016-03-171-4/+11
| | | | | | | | 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.)
* vo_opengl: fix sharpen filterwm42016-03-163-4/+5
| | | | | | Regression since commit 93546f0c. Fixes #2956.
* vo_opengl: only open one OpenGL/DX interop handle when using dxva2Kevin Mitchell2016-03-152-18/+23
| | | | | | | | | 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.
* vo_opengl: add dxva2 interop to angle backendKevin Mitchell2016-03-102-0/+350
| | | | | | 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.
* vo_opengl: use the same type for cached and current uniform valueswm42016-03-101-12/+11
| | | | Slightly improvement over the previous commit.
* vo_opengl: cache the values of the uniform variablesigv2016-03-101-20/+31
|
* vo_opengl: cache the locations of the uniform variablesigv2016-03-091-6/+13
|
* vo_opengl: decrease default superxbr-edge-strengthNiklas Haas2016-03-071-1/+1
| | | | | | 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.
* vo_opengl: improve superxbr algorithmNiklas Haas2016-03-071-12/+11
| | | | | | | | 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).
* vo_opengl: refactor superxbr algorithmNiklas Haas2016-03-073-133/+150
| | | | | | | | | | | | | | | | | | 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)
* vo_opengl: refactor plane-skipping optimizationsNiklas Haas2016-03-051-16/+26
| | | | | | 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.
* vo_opengl: rename prescale to prescale-lumaNiklas Haas2016-03-052-13/+14
| | | | | | 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.
* vo_opengl: add macros for scaler unitsNiklas Haas2016-03-052-34/+42
| | | | | There was no real point in hard-coding these all over the place, especially since the order was sort of arbitrary and confusing.
* vo_opengl: refactor pass_read_video and texture bindingNiklas Haas2016-03-057-379/+488
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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).
* vo_opengl: wayland: don't destroy NULL wl_egl_windowwm42016-03-031-1/+2
| | | | | The wayland client API crashes intentionally when trying to free NULL objects. (Thanks.)
* vo_opengl: remove redundant codeigv2016-02-281-2/+2
|
* vo_opengl: set uniform variable "pixel_size" for internal shadersigv2016-02-265-28/+28
|
* vo_opengl: dxinterop: fix compatibility issue with Vistaigv2016-02-261-1/+2
|
* vo_opengl, vo_rpi: unbreak a few thingswm42016-02-242-2/+2
| | | | | Commit 2f562825 didn't remove the "color" declaration for these. Since the shader header already declares it, shader compilation broke.
* vo_opengl: declare vec4 color inside fragment shader stubNiklas Haas2016-02-233-43/+27
| | | | | | 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.
* vo_opengl: set uniform variable "pixel_size"igv2016-02-221-0/+2
| | | | | pixel_size is often used variable, also reciprocal is a costly operation for AMD and older nVidia (prior to Kepler) GPUs.
* vo_opengl: set the correct size of the input imageigv2016-02-221-2/+2
|
* dxva2: fix shared surface typeJames Ross-Gowan2016-02-191-22/+22
| | | | | | | | | | | 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.
* vo_opengl: use correct gl_target variablewm42016-02-181-2/+2
| | | | | p->gl_target and plane->gl_target are always the same value here, but semantically plane->gl_target is the correct one.
* vo_opengl: don't use normalized coords for debanding rectangle textureswm42016-02-181-1/+2
| | | | Fixes #2831.
* vo_opengl: pass the correct target to deband functionswm42016-02-181-4/+4
| | | | | | | | 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.
* wscript: remove dxva2-dxinterop configure testKevin Mitchell2016-02-171-2/+2
| | | | Wasn't really necessary as it was equivalent to gl-dxinterop.
* vo_opengl: dxinterop: add dxva2 passthroughKevin Mitchell2016-02-173-0/+229
| | | | | Use dxva2 surface to fill RGB IDirect3DSurface9 shared with opengl via DXRegisterObjectNV.
* vo_opengl: dxinterop: improve error messagesKevin Mitchell2016-02-171-21/+37
| | | | | | | * 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
* vo_opengl: unconfuse Coveritywm42016-02-121-1/+1
| | | | | | | | | 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.
* Enable building the opengl-cb video renderer on AndroidJan Ekström2016-02-102-0/+26
| | | | | | * Add Android-specific OpenGL ES feature and checks * Add missing GL_* symbols for Android (list gathered by Ilya Zhuravlev <whatever@xyz.is>)
* vo_opengl: vdpau: call glVDPAUFiniNV only if initializedwm42016-02-081-6/+8
| | | | This is "more correct". See #2798.
* vo_opengl: hwdec: use IDs for API, and log which backend is usedwm42016-02-017-17/+30
| | | | | | | 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.
* vo_opengl: do chroma merging in integer conversion stagewm42016-01-271-3/+13
| | | | | | 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.
* vo_opengl: add precision qualifier to usampler2D on ANGLEwm42016-01-271-1/+1
| | | | | | | | 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.
* vo_opengl: replace tscale-interpolates-only with interpolation-thresholdwm42016-01-272-9/+12
| | | | | The previous approach was too naive, and can e.g. ruin playback if scheduling switches e.g. between 1 and 2 vsync per frame.
* vo_opengl: support 10 bit support with ANGLEwm42016-01-263-10/+120
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 function on a texture in an uniform way. So for now, run a simple conversion step through a FBO. The FBO will use the rgba16f format normally, which gives enough bits for 10 bit, and will at least gracefully degrade with higher depth input. This is bound to be much slower than a more "direct" method, but at least it works and is simple to implement. The odd change of function call order in init_video() is to properly disable "dumb mode" (no FBO use) if these texture formats are in use.
* vo_opengl: actually reset use_normalized_range fieldwm42016-01-261-3/+3
| | | | | | | | | This was never reset - absolutely can't be right. If the renderer somehow switches back to another codepath, it certainly has to be reset. Maybe this was hard to hit, as the normalization is going to be idempotent in simpler cases (like rendering RGBA input). Also get rid of the "merged" variable.
* vo_opengl: default to rgba16f FBOs on ANGLEwm42016-01-261-2/+5
| | | | | Although it has only 1 bit more precission than rgba10_a2, it was reported to improve the visual quality.
* vo_opengl: add tscale-interpolates-only sub-optionwm42016-01-252-1/+8
|
* vo_opengl: default scaler-resizes-only sub-option to yeswm42016-01-251-0/+2
| | | | | | | | Often requested. The main argument, that prominent scalers like sharpen change the image even if no scaling happens, disappeared anyway. ("sharpen", unsharp masking, is neither prominent nor a scaler anymore. This is an artifact from MPlayer, which fuses unsharp masking with bilinear scaling in order to make it single-pass, or so.)
* vo_opengl: rename custom shader entrypoint from sample to sample_pixelwm42016-01-251-3/+19
| | | | | | | "sample" is a reserved identifier at least in GLES ES. Suggestions for a better name than "sample_pixel" are still welcome. Fixes #2733.
* vo_opengl: vdpau: better handling of preemption recoverywm42016-01-251-1/+1
| | | | | If recovery from preemption is done successfully, continue normally. Only fail if it's preempted during init.
* video: remove some useless old RGB formatswm42016-01-251-3/+0
| | | | | | | | | | | | | Some VOs had support for these - remove them. Typically, these formats will have only some use in cases where using RGB software conversion with libswscale is faster than letting the VO/GPU do it (i.e. almost never). For the sake of testing this case, keep IMGFMT_RGB565. This is the least messy format, because it has no padding/alpha bits with unknown semantics. Note that decoding to these formats still works. We'll let libswscale repack the data to whatever the VO in use can take.
* vo_opengl: vaapi: don't expect EGL exts. to be in common ext. stringwm42016-01-221-2/+6
|
* vo_opengl: vaapi: reorganize platform entrypoints as tablewm42016-01-211-15/+20
|
* vo_opengl: add KMS/DRM VAAPI hardware decoding interopwm42016-01-202-0/+21
| | | | Just requires glueing it together with Bloat Super Glue (tm).
* Change GPL/LGPL dual-licensed files to LGPLwm42016-01-1927-320/+189
| | | | | | | | | | | Do this to make the license situation less confusing. This change should be of no consequence, since LGPL is compatible with GPL anyway, and making it LGPL-only does not restrict the use with GPL code. Additionally, the wording implies that this is allowed, and that we can just remove the GPL part.
* Relicense some non-MPlayer source files to LGPL 2.1 or laterwm42016-01-191-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This covers source files which were added in mplayer2 and mpv times only, and where all code is covered by LGPL relicensing agreements. There are probably more files to which this applies, but I'm being conservative here. A file named ao_sdl.c exists in MPlayer too, but the mpv one is a complete rewrite, and was added some time after the original ao_sdl.c was removed. The same applies to vo_sdl.c, for which the SDL2 API is radically different in addition (MPlayer supports SDL 1.2 only). common.c contains only code written by me. But common.h is a strange case: although it originally was named mp_common.h and exists in MPlayer too, by now it contains only definitions written by uau and me. The exceptions are the CONTROL_ defines - thus not changing the license of common.h yet. codec_tags.c contained once large tables generated from MPlayer's codecs.conf, but all of these tables were removed. From demux_playlist.c I'm removing a code fragment from someone who was not asked; this probably could be done later (see commit 15dccc37). misc.c is a bit complicated to reason about (it was split off mplayer.c and thus contains random functions out of this file), but actually all functions have been added post-MPlayer. Except get_relative_time(), which was written by uau, but looks similar to 3 different versions of something similar in each of the Unix/win32/OSX timer source files. I'm not sure what that means in regards to copyright, so I've just moved it into another still-GPL source file for now. screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but they're all gone.
* mpv_talloc.h: rename from talloc.hDmitrij D. Czarkoff2016-01-111-1/+1
| | | | This change helps avoiding conflict with talloc.h from libtalloc.
* vaapi: replace VA_STR_FOURCCwm42016-01-111-2/+2
|
* vo_opengl: generic semi-planar supportwm42016-01-071-9/+10
| | | | | | Should take care of the planned FFmpeg AV_PIX_FMT_P010 addition. (This will eventually be needed when doing HEVC Main 10 decoding with DXVA2 copyback.)
* vo_opengl: hwdec_vdpau: relicense under LGPLwm42016-01-071-7/+7
| | | | All code was written by myself.
* vo_opengl: video.h: fix licensewm42016-01-071-7/+8
| | | | |