summaryrefslogtreecommitdiffstats
path: root/video/out/opengl
Commit message (Collapse)AuthorAgeFilesLines
* vo_opengl: implement videotoolbox hwdec on iOSAman Gupta2017-02-172-1/+215
| | | | | | Implements --hwdec=videotoolbox on iOS. Similar to hwdec_osx.c, but using CVPixelBuffer APIs available on iOS instead of the equivalent IOSurface APIs in macOS.
* vo_opengl: don't crash on unsupported formatswm42017-02-171-1/+2
| | | | Regression from recent refactor.
* vo_opengl: hwdec_vaegl: use new format setup functionwm42017-02-173-14/+28
| | | | Plus add a helper.
* vo_opengl: hwdec_osx: use new format setup functionwm42017-02-172-87/+21
| | | | | | | | | | | | | | | | We can drop the custom table. For some reason, the interop does not accept GL_RGB_RAW_422_APPLE as internal format for GL_RGB_422_APPLE, so switch the format table to use GL_RGB (this way both interop and real textures work the same). Another victim of the apparent requirement of exactly matching texture formats is kCVPixelFormatType_32BGRA. vo_opengl wants to handle this as normal RGBA texture, with a swizzle applied in the shader. CGLTexImageIOSurface2D() rejects this, because it wants the exact internal format. Just drop the format, because it's useless anyway. (Maybe this is a bit too fragile...)
* vo_opengl: hwdec_cuda: use new format setup functionwm42017-02-171-34/+8
| | | | Gives us automatically support for all formats vo_opengl supports.
* vo_opengl: move texture mapping of pixel formats to helper functionwm42017-02-173-128/+163
| | | | | | | All supported pixel formats have a specific "mapping" of CPU data to textures. This function determines the number and the formats of these textures. Moving it to a helper will be useful for some hardware decode interop backends, since they all need similar things.
* vo_opengl: handle GL_LUMINANCE_ALPHA and integer textures differentlywm42017-02-175-31/+38
| | | | | | | | | | | | | | | GL_LUMINANCE_ALPHA is the only reason why per-plane swizzles exist. Remove per-plane swizzles (again), and regrettably handle them as special cases (again). Carry along the logical texture format (called gl_format in some parts of the code, including the new one). We also don't need a use_integer flag, since the new gl_format member implies whether it's an integer texture. (Yes, the there are separate logical GL formats for integer textures. This aspect of the OpenGL API is hysteric at best.) This should change nothing about actual rendering logic and GL API usage.
* videotoolbox: fix RGB formatwm42017-02-171-1/+1
| | | | | Wrong colors. This didn't matter for the OpenGL interop code, because the CV format was mapped to the correct texture format.
* videotoolbox: remove weird format-negotiation between VO and decoderwm42017-02-171-16/+1
| | | | | | | | | | | | | | | | Originally, there was probably some sort of intention to restrict it to formats supported by the interop, or something. But in the end it was overcomplicated nonsense. In the future, we could use mp_hwdec_ctx.supported_formats or other mechanisms to handle this in a better way. mp_hwdec_ctx.ctx is not set to a dummy pointer - hwdec_devices_load() is only used to detect whether to vo_opengl interop is present, and the common hwdec code expects that the .ctx field is not NULL. This also changes videotoolbox-copy to use --videotoolbox-format, instead of the FFmpeg-set default.
* videotoolbox: factor some duplicated codewm42017-02-171-39/+2
| | | | | | | | The code for copying a videotoolbox surface to mp_image was duplicated (with some minor differences - I picked the hw_videotoolbox.c version, because it was "better"). mp_imgfmt_from_cvpixelformat() is somewhat duplicated with the vt_formats[] table, but this will be fixed in a later commit, and moving the function to shared code is preparation.
* vo_opengl: hwdec_vaegl: fix potentially undefined memory accesswm42017-02-141-2/+2
|
* vo_opengl: angle: log the device/surface implementationJames Ross-Gowan2017-02-121-13/+27
| | | | | This should be useful for debugging, since otherwise it's hard to tell which implementation has been auto-detected or if any failed to init.
* vo_opengl: egl_helpers: fix for non-WindowsJames Ross-Gowan2017-02-081-1/+1
| | | | Whoops. Fixes #4119
* vo_opengl: angle: rewrite with custom swap chainJames Ross-Gowan2017-02-074-232/+653
| | | | | | | | | | | | | This replaces the old backend that exclusively used EGL windowing with one that can also use ANGLE's ability to render to directly to a texture. The advantage of this is that it allows mpv to create the swap chain itself and this allows mpv to use a flip-mode swap chain on a HWND (which avoids problems with DirectComposition) and to use a longer swap chain that has six backbuffers by default (which reportedly fixes problems with rendering 24fps video on 24Hz monitors.) Also, "screenshot window" should now work on DXGI 1.2 and up (Windows 8 and up.)
* vo_opengl: dxinterop: use the new SAFE_RELEASE macroJames Ross-Gowan2017-01-301-15/+8
|
* vaapi: remove central lock around vaapi API callswm42017-01-282-10/+0
| | | | | | | | The lock was disabled recently. This commit gets rid of the dummied out calls. The main reason for removing it is that there is no apparent need for it anymore, and the new FFmpeg vaapi code does not use or provide such a lock (there are some places which we cannot control and which do vaapi API calls, like frame destructors).
* vo_opengl: egl_helpers: fix variable namewm42017-01-261-3/+3
| | | | | | It was basically inverted. Not sure how this even happened. Hopefully it's more an "I don't know what I was doing" instead of an "I don't know what I am doing" case.
* options: refacactor how --opengl-dwmflush is declaredwm42017-01-202-7/+10
| | | | | Same deal as previous commit, except this time we just readd it as lone global option, and read it directly.
* options: refactor how --opengl-dcomposition is declaredwm42017-01-203-2/+23
| | | | | | | | | | | | | | | | | vo_opengl used to have it as sub-option, which made it very hard to pass down option values to backends in a generic way (even if these options were completely backend-specific). For --opengl-dcomposition we used a VOFLAG to deal with this. Fortunately, sub-options are gone, and we can just add it as global option. Move the option to context_angle.c and add it as global option. I thought about adding a mechanism to let backends declare options, which would get magically picked up my m_config instead of having to add them to the global option list manually (similar to VO vo_driver.options), but decided against this complexity just for 1 or 2 backends. Likewise, it could have been added as a single option to avoid the boilerplate of an option struct, but then again there are probably going to be more angle suboptions, and it's cleaner.
* vo_opengl, vo_opengl_cb: better hwdec interop backend selectionwm42017-01-172-0/+71
| | | | | | | | | | | Introduce the --opengl-hwdec-interop option, which replaces --hwdec-preload. The new option allows explicit selection of the interop backend. This is relatively complex, and I would have preferred not to add this, but it's probably useful to debug certain problems. In exchange, the "new" option documents that pretty much any but the simplest use of it will not be forward compatible.
* vdpau: use libavutil for surface allocation during decodingwm42017-01-171-1/+2
| | | | | | | | | | | | | | | | Use the libavutil vdpau frame allocation code instead of our own "old" code. This also uses its code for copying a video surface to normal memory (used by vdpau-copy). Since vdpau doesn't really have an internal pixel format, 4:2:0 can be accessed as both nv12 and yuv420p - and libavutil prefers to report yuv420p. The OpenGL interop has to be adjusted accordingly. Preemption is a potential problem, but it doesn't break it more than it already is. This requires a bug fix to FFmpeg's vdpau code, or vdpau-copy (as well as taking screenshots) will fail. Libav has fixed this bug ages ago.
* vo_opengl: hwdec_cuda: add yuv420p supportwm42017-01-161-19/+35
| | | | | | | | | Because it allows easier testing of filters + hwdec. Make the texture setup code a bit more generic so it doesn't get too much of a mess. We also use the GL renderer utility function gl_find_unorm_format(), which saves us additional work with OpenGL's semi-redundant format specifiers.
* vo_opengl: hwdec_cuda: export AVHWDeviceContextwm42017-01-161-6/+31
| | | | So we can use it for filtering later.
* vo_opengl: hwdec_vaegl: add a lie for compatibilitywm42017-01-131-1/+1
| | | | | | | EGL rendering + new decode API didn't work due to a certain libva bug with sort-of legacy API use hitting again. It will report the wrong vaapi pixel format. It's old code and always nv12 anyway, so stop worrying about it.
* vo_opengl, vaapi: properly probe 10 bit rendering supportwm42017-01-131-28/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are going to be users who have a Mesa installation which do not support 10 bit, but a GPU which can decode to 10 bit. So it's probably better not to hardcode whether it is supported. Introduce a more general way to signal supported formats from renderer to decoder. Obviously this is imperfect, because it still isn't part of proper format negotation (for example, what if there's a vavpp filter, which accepts anything). Still slightly better than before. I don't know any way to probe for vaapi dmabuf/EGL dmabuf support properly (in particular testing specific formats, not just general availability). So we stay with the current approach and try to create and map dummy surfaces on init to probe for support. Overdo it and check all formats that AVHWFramesConstraints reports, instead of only NV12 and P010 surfaces. Since we can support unknown formats now, add explicitly checks to the EGL/dmabuf mapper code to reject unsupported formats. I also noticed that libavutil signals support for RGB0/BGR0, but couldn't get it to work. Remove the DRM formats that are unused/didn't work the way I tried to use them. With this, 10 bit decoding + rendering should work, provided you have a capable CPU and a patched Mesa. The required Mesa patch adds support for the R16 and GR32 formats. It was sent by a Kodi developer to the Mesa developer mailing list and was not accepted yet.
* vo_opengl: hwdec_vaegl: remove redundant vaapi surface format checkwm42017-01-131-8/+1
| | | | | | | | | | | | | | | | | For surfaces allocated by libavutil, we assume that the sw_format (i.e. in hw_subfmt in mp_image_params) is always correct. The API guarantees that it explicitly sets the equivalent vaapi format on surface allocation. For surfaces allocated by mpv's old vaapi code, we explicitly retrieve the format right after decoding. Unless the driver magically changes the format asynchronously, it will still be correct once the surface reaches the renderer. In both cases, checking the format again is obviously redundant. In addition, it doesn't require us to maintain a libva fourcc <-> mpfmt table and the va_fourcc_to_imgfmt() function. This also unbreaks 10 bit rendering support (still disabled by default).
* vo_opengl: hwdec_vaegl: fix terminology in commentwm42017-01-131-2/+2
| | | | Bad idea to call a component "pixel" - that's true only for the Y plane.
* vo_opengl: hwdec_vaegl: DRM_FORMAT_GR16 was renamed to DRM_FORMAT_GR32Mark Thompson2017-01-131-1/+1
| | | | Signed-off-by: wm4 <wm4@nowhere>
* vo_opengl: hwdec_vaegl: add experimental P010 supportwm42017-01-121-6/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | This does not work, because Mesa has no support for the proposed DRM_FORMAT_R16 and DRM_FORMAT_GR16 formats. It's also untested of course. As long as video/decode/vaapi.c doesn't hand down P010 surfaces, this is fine anyway. This can be tested by removing the code that disables P010 output: diff --git a/video/decode/vaapi.c b/video/decode/vaapi.c --- a/video/decode/vaapi.c +++ b/video/decode/vaapi.c @@ -55,13 +55,6 @@ static int init_decoder(struct lavc_ctx *ctx, int w, int h) assert(!ctx->avctx->hw_frames_ctx); - // If we use direct rendering, disallow 10 bit - it's probably not - // implemented yet, and our downstream components can't deal with it. - if (!p->own_ctx && required_sw_format != AV_PIX_FMT_NV12) { - MP_WARN(ctx, "10 bit surfaces are currently supported.\n"); - return -1; - } -
* cuda: use libavutil functions for copying hw surfaces to memorywm42017-01-121-67/+0
| | | | | | | | mp_image_hw_download() is a libavutil wrapper added in the previous commit. We drop our own code completely, as everything is provided by libavutil and our helper wrapper. This breaks the screenshot code, so that has to be adjusted as well.
* drm: include <poll.h> instead of <sys/poll.h>wm42017-01-091-1/+1
| | | | | | | I'm not sure what systems have <sys/poll.h> (maybe there are historical reasons why some would), but POSIX defines <poll.h>. Although this code is full of highly OS specific calls (like ioctl()), there's no reason not to use the more standard include path.
* vo_opengl: replace 2 memsetswm42017-01-081-2/+2
| | | | Cosmetic change.
* context_wayland: do not call vo_wayland_request_frame() upon bufferswapRostislav Pehlivanov2017-01-071-3/+0
| | | | | | | | vo_wayland_wait_events() is going to return when its time to swap the buffers anyway, calling request_frame() before makes no sense. Fixes the constant high CPU usage by the compositor when mpv is paused and the window is in view.
* vo_opengl: egl: handle potential eglChooseConfig failureswm42016-12-311-11/+10
| | | | | | | | | | | | | | | This is actually a pretty important fix. eglChooseConfig() might be the first thing that fails when porobing for desktop GL / ES2 / ES3 support, because EGL_RENDERABLE_TYPE is set values specific to the underlying APIs. Not sure how the hell this worked before. EGL 1.4 implementations certainly could fail the call with EGL_BAD_ATTRIBUTE if EGL_RENDERABLE_TYPE has EGL_OPENGL_ES3_BIT set. It's quite possible that many EGL implementations tolerate invalid EGLConfig values steming from uininitialized EGLConfig values (and eglCreateWindowSurface() even is specified to return EGL_BAD_CONFIG error code for "not valid" EGLConfigs).
* vo_opengl: egl: fix depth size parameterwm42016-12-301-1/+0
| | | | | | This was accidentally flipped from 0 to 1 in a previous commit. Actually simply remove it, because 0 is the default value for this parameter anyway.
* vo_opengl: x11egl: fix alpha modewm42016-12-301-2/+32
| | | | | | | | | | | | | | | | | | The way it should (probably) work is that selecting a RGBA framebuffer format will simply make the compositor use the alpha. It works this way on Wayland. On X11, this is... not done. Instead, both GLX and EGL report two FB configs, which are exactly the same, except for the platform-specific visual. Only the latter (non-default) points to a visual that actually has alpha. So you can't make the pure GLX and EGL APIs select alpha mode, and you have to override manually. Or in other words, alpha was hacked violently into X11, in a way that doesn't really make sense for the sake of compatibility, and forces API users to wade through metaphorical cow shit to deal with it. To be fair, some other platforms actually also require you to enable alpha explicitly (rather than looking at the framebuffer type), but they skip the metaphorical cow shit step.
* vo_opengl: x11: move RGBA visual test to x11_common.cwm42016-12-301-12/+11
| | | | | | | | So that the EGL code can use it too. Also print the actual FB config ID, instead of nonsense. (I _think_ once in the past a certain GLX implementation just used numeric config IDs casted to EGLConfig - or at least that would explain this nonsense.)
* vo_opengl: egl_helpers: add a way to override config selectionwm42016-12-302-2/+21
| | | | | | | Preparation for the following commits. Since at least theoretically the config selection depends on the context type (EGL_RENDERABLE_TYPE has separate bits for ES 2, ES 3, and desktop GL), doing it any other way would be too painful.
* vo_opengl: egl_helpers: add a way to pass more optionswm42016-12-302-16/+35
| | | | | | | | | | For X11 garbage we have to pass some annoying parameters to EGL context creation. Add some sort of extensible API, so that adding a new parameter doesn't break all callers. We still want to keep it as a single function, because it's so nice isolating all the EGL nonsense API boilerplate like this. (Did I mention yet that X11 and EGL are garbage?) Also somewhat simplifies the vo_flags mess in the helper internals.
* vo_opengl: partially fix rotation for 4:2:2 contentNiklas Haas2016-12-281-1/+6
| | | | | | | | | | | | The chroma alignment renormalization code forgot to account for the fact that the chroma subsampling ratio has to be rotated. Unfortunately, doing it this way seems to have somewhat broken the chroma offset rotation logic for odd-sized subsampled image files. While this is a bug, it's much, much less noticeable, so it's not nearly as important as the bug this change fixes. Either way, a future patch needs to still revise this logic, ideally by redesigning the entire rotation mechanism.
* vo_opengl: hwdec_cuda: Don't include hwcontext headersPhilip Langdale2016-12-041-4/+0
| | | | | After various simplifications, these includes simply aren't needed now.
* vo_opengl: don't rely on viewport to contain window dimensionswm42016-12-022-8/+5
| | | | | | | | | | | | | Apparently we don't always set the viewport to window dimensions anymore, e.g. if nothing is actually rendered. This means the viewport can contain old values. The window screenshot code uses the viewport values to guess the default framebuffer dimensions. With --force-window --idle --no-osc (which draws nothing and issues a glClear() command only), taking a screenshot would yield an image with the wrong size and possibly garbage in it. Fix this by explicitly passing the currently known window dimensions. Abusing the values stored in the viewport was questionable anyway.
* options: remove deprecated sub-option handling for --vo and --aowm42016-11-252-90/+0
| | | | | | | | Long planned. Leads to some sanity. There still are some rather gross things. Especially g_groups is ugly, and a hack that can hopefully be removed. (There is a plan for it, but whether it's implemented depends on how much energy is left.)
* angle_dynamic: silence warnings during compilationpavelxdd2016-11-251-4/+10
| | | | | | If Angle is statically linked there were some warnings during compilation. Fixes #3834
* vo_opengl: hwdec_cuda: Prefix cuda symbols to avoid collisionsPhilip Langdale2016-11-242-11/+18
| | | | | | We want to avoid causing problems if libmpv is used in an application that links cuda, or if the libav* libraries are linked with cuda, as might happen if the scale_npp filter is used.
* vo_opengl: hwdec_cuda: make some init errors verbosewm42016-11-241-2/+2
| | | | | Improves autoprobe behavior. This is equivalent to other hwdec interop wrappers. If CUDA is just not available, it should remain silent.
* vo_opengl: hwdec_cuda: fix crash when trying to use hwdec=cuda if cuda SDK ↵pavelxdd2016-11-241-0/+1
| | | | | | is not present If CUDA SDK wasn't installed, mpv crashed immediately with the message "Failed to load CUDA symbols"
* vo_opengl/cuda_dynamic: Use explicit cast to silence warnings on windowsPhilip Langdale2016-11-241-1/+1
| | | | Fixes #3834
* wscript: Fix cuda test to actually work when cuda SDK is not presentPhilip Langdale2016-11-231-1/+1
| | | | | | | | | | The test ended up failing if cuda.h wasn't present, even if cuda.h isn't used during the actual build. This test is attempting to establish if the ffmpeg being built against has dynlink_cuda support. While it might theoretically be possible to build against the older normally-linked-cuda version of ffmpeg, it seems more trouble than it's worth.
* angle_dynamic: minor simplificationwm42016-11-231-3/+3
| | | | Remove the inverted condition by swapping if branches.
* Support linking ANGLEMartin Herkt2016-11-231-0/+5
|
* vo_opengl: hwdec_d3d11egl: fix ANGLE fallback definewm42016-11-231-1/+1
| | | | | | This was a typo in the extensiuon spec and was probably always broken. Could have led to broken builds when used with ancient ANGLE headers (or possibly generic EGL headers).
* vo_opengl: hwdec_cuda: Use dynamic loading for cuda functionsPhilip Langdale2016-11-233-2/+211
| | | | | This change applies the pattern used in ffmpeg to dynamically load cuda, to avoid requiring the CUDA SDK at build time.
* vo_opengl: hwdec_cuda: Support P016 output surfacesPhilip Langdale2016-11-221-8/+45
| | | | | | | | | The latest 375.xx nvidia drivers add support for P016 output surfaces. In combination with an ffmpeg change to return those surfaces, we can display them. The bulk of the work is related to knowing which format you're dealing with at the right time. Once you know, it's straight forward.
* vo_opengl: blend against background color for --alpha=blendPhilip Sequeira2016-11-131-8/+14
| | | | | Do it after color management, etc. so that it matches the color drawn in the margins.
* vo_opengl: fix --blend-subtitles handlingwm42016-11-071-2/+2
| | | | | | | | | | | | | The intention was that if --blend-subtitles is enabled, the frame should always be re-rendered instead of using e.g. a cached scaled frame. The reason is that subtitles can change anyway, e.g. if you pause and change subtitle size and such. On the other hand, if the frame is marked as repeated, it should always use the cached copy. Actually "simplify" this and drop the cache only if playback is paused (which frame->still indicates indirectly). Also see PR #3773.
* vo_opengl: fix redrawing with hardware decodingwm42016-11-071-0/+1
|