summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* image_writer: add webp-compression optionsfan52019-09-142-0/+4
|
* image_writer: add WebP support (lossy or lossless)sfan52019-09-142-7/+41
|
* image_writer: move convert_image() to player/screenshot.csfan52019-09-143-10/+4
|
* vo: add warning message to vo_vaapi and vo_vdpausfan52019-09-142-0/+10
| | | | | These are a common source of bug reports, due to misconceptions that they are required to make use of hardware decoding.
* vo_d3d11/context: fix crash due to ctx->ra is null pointer accessHui Jin2019-09-141-2/+4
| | | | 'ctx->ra' is null pointer when d3d11 init failed before call 'ra_d3d11_create' in 'd3d11_init'.
* vo_d3d11/hwdec_dxva2dxgi: fix memory leak that 'ctx11' be not releaseHui Jin2019-09-141-0/+6
| | | | 'ctx11' be not release when d3d11 hwdec be uninit with 'mapper_uninit' method.
* vo_gpu: x11egl: support Mesa OML sync extensionwm42019-09-081-0/+24
| | | | | | | | | | | | | | | | | | | | Mesa supports the EGL_CHROMIUM_sync_control extension, and it's available out of the box with AMD drivers. In practice, this is exactly the same as GLX_OML_sync_control, but for EGL. The extension specification is separate from the GLX one though, and buried somewhere in the Chromium code. This appears to work, although I don't know if it really works. In theory, this could be useful for other EGL targets. Support code for it could have been added to egl_helpers.c to avoid some minor duplicated glue code if another EGL target were to provide this extension. I didn't bother with that. ANGLE on Windows can't support it, because the extension spec. explicitly requires POSIX timers. ANGLE on Linux/OSX is actively harmful for mpv and hopefully won't ever use it. Wayland uses EGL, but has its own fancy presentation feedback stuff (and besides, I don't think basic video player functionality works on Wayland at all). context_drm_egl maybe? But I think DRM has its own stuff.
* vo_gpu: glx: move OML sync code to an independent filewm42019-09-083-96/+145
| | | | | | | | | | | | | | | | | So the next commit can make EGL use it. EGL has a quite similar function, that practically works the same. Although it's relatively trivial, it's still tricky, and probably shouldn't end up as duplicated code. There are no functional changes, except initialization, and how failure of the glXGetSyncValues call is handled. Also, some comments mention the EGL extension. Note that there's no intention for this code to handle anything else than the very specific OML sync extension (and its EGL equivalent). This is just too weirdly specific to the weird idiosyncrasies of the extension, and it makes no sense to extend it to handle anything else. (Such as Wayland or DXGI presentation feedback.)
* vo/gpu: fix check on src/dst peak mismatchNiklas Haas2019-09-051-1/+1
| | | | | | | | | | In the past, src peak was always equal to or higher than dst peak. But since `--target-peak` got introduced, this could no longer be the case. This leads to an incorrect result (scaling for peak mismatch in gamma light) unless some other option (CMS, --linear-scaling, etc.) forces the linearization. Fixes #6533
* cocoa-cb: remove an unused variableder richter2019-09-021-1/+0
|
* vo/gpu: vulkan: Pass the device name option through to libplaceboPhilip Langdale2019-08-241-0/+1
| | | | | | | | | We collect a 'vulkan-device' option today but then don't actually pass it on, so it's useless. Once that's fixed, it can be used to select a specific vulkan device by name. Tested with the new nvidia offload feature to select between the nvidia and intel GPUs.
* vo_gpu: d3d11: fix storage lifetime of compound literalsJames Ross-Gowan2019-08-201-8/+15
| | | | | | | | | | | | | | | | Somehow I got the idea that compound literals had function-scoped lifetime. Instead, like all other objects with automatic storage duration, compound literals are block-scoped, so they become invalid after exiting the block they were declared in. It seems like a recent change to GCC actually reuses the memory that the compound literals used to occupy, which was causing a few bugs. The pattern of conditionally assigning a pointer to a compound literal was used in a few places in ra_d3d11 where the Direct3D API expects either a pointer to an initialised struct or NULL. Change these to ensure the lifetime of the struct includes the API call. Should fix #6775.
* vo_gpu: fix taking screenshots of rotated videoswnoun2019-08-141-2/+6
|
* vo_gpu: hwdec_vaapi: Synchronise after exporting VA surfacePhilip Langdale2019-08-071-0/+3
| | | | | | | This is documented as required (although we did not do it in the old GL codepath, with no visible problems) and I have seen transient artifacts after seeking which _appear_ to have gone away after introducing this.
* cocoa-cb: migrate to swift 5 with swift 4 fallbackder richter2019-07-214-69/+60
| | | | | | | | | | | | | this migrates our current swift code to version 5 and 4. building is support from 10.12.6 and xcode 9.1 onwards. dynamic linking is the new default, since Apple removed static libs from their new toolchains and it's the recommended way. additionally the found macOS SDK version is printed since it's an important information for finding possible errors now. Fixes #6470
* cocoa-cb: fix optional cases on macOS 10.12der richter2019-07-211-4/+4
|
* cocoa-cb: conditional compilation for Dark Mode and Material featuresder richter2019-07-211-1/+4
| | | | Fixes #6621
* vo_gpu: hwdec_vaapi: Count planes rather than layers in Vulkan interopPhilip Langdale2019-07-081-1/+1
| | | | | | | | | | | | | | | | | | | | We saw a segfault when trying to use the intel-media-driver (iHD) rather than the normal intel va driver. This happened because the iHD driver reports P010 (and maybe other formats) with multiple layers to represent the interleaved UV plane. The normal va driver reports one UV layer to match the plane. This threw off my logic which assumed that the number of layers could not exceed the number of planes. There's a way one could fix this in a fully generalised form, but I'm just going to do what the EGL path does and assume that: * Layer 'n' is on Plane 'n' for n < total number of planes * These layers always start at offset 0 on the plane You can imagine ways that these assumptions are violated, but at least the failure will look the same for both EGL and Vulkan paths.
* vo_gpu: hwdec_vaapi: Suppress format errors when probingPhilip Langdale2019-07-082-3/+7
| | | | | | | | | | Today, we normally see a format error when probing because yuyv422 cannot be used, but it's in the normal set of probed formats. This error is distracting and confusing, so only log probing errors at the VERBOSE level. Fixes #6411
* vo_gpu: hwdec_vaapi: Add Vulkan interopPhilip Langdale2019-07-083-157/+298
| | | | | | | | | | | | | | | | | | | | | | | | This change introduces a vulkan interop path for the vaapi hwdec. The basic principles are mostly the same as for EGL, with the exported dma_buf being imported by Vukan. The biggest difference is that we cannot reuse the texture as we do with OpenGL - there's no way to rebind a VkImage to a different piece of memory, as far as I can see. So, a new texture is created on each map call. I did not bother implementing a code path for the old libva API as I think it's safe to assume any system with a working vulkan driver will have access to a newer libva. Note that we are using separate layers for the vaapi surface, just as is done for EGL. This is because libplacebo doesn't support multiplane images. This change does not include format negotiation because no driver implements the vk_ext_image_drm_format_modifier extension that would be required to do that. In practice, the two formats we care about (nv12, p010) work correctly, so we are not blocked. A separate change had to be made in libplacebo to filter out non-fatal validation errors related to surface sizes due to the lack of format negotiation.
* vo_gpu: hwdec_vaegl: Rename and move to hwdec_vaapiPhilip Langdale2019-07-081-0/+0
| | | | | In preparation for adding Vulkan interop support, let's rename to remove the egl reference and move to an api neutral location.
* vf_vapoursynth: allow multithreaded writing of source framesChainik2019-07-081-0/+3
|
* vf_vapoursynth: allow multithreaded reading of returned framesChainik2019-07-081-8/+9
|
* vo/gpu: hwdec_vdpau: Support direct mode for 4:4:4 contentPhilip Langdale2019-07-083-4/+19
| | | | | | | New releases of VDPAU support decoding 4:4:4 content, and that comes back as NV24 when using 'direct mode' in OpenGL Interop. That means we need to be a little bit smarter about how we set up the OpenGL textures.
* opengl/context_wayland: Fix crash on configure before initial reconfigMichael Forney2019-07-081-1/+3
| | | | | | | | | If the compositor sends a configure event before the surface is initially mapped, resize gets called before the egl_window gets created, resulting in a crash in wl_egl_window_resize. This was fixed back in 618361c697, but was reintroduced when the wayland code was rewritten in 68f9ee7e0b.
* video/out/gpu: Add a `storable` flag to ra_formatPhilip Langdale2019-07-085-1/+9
| | | | | | | | | | | | | | | | While `ra` supports the concept of a texture as a storage destination, it does not support the concept of a texture format being usable for a storage texture. This can lead to us attempting to create a texture from an incompatible format, with undefined results. So, let's introduce an explicit format flag for storage and use it. In `ra_pl` we can simply reflect the `storable` flag. For GL and D3D, we'll need to write some new code to do the compatibility checks. I'm not going to do it here because it's not a regression; we were already implicitly assuming all formats were storable. Fixes #6657
* vo_gpu: process three component together in error diffusionBin Jin2019-06-161-42/+70
| | | | | | | | | | | | | | | | This started as a desperate attempt to lower the memory requirement of error diffusion, but later it turns out that this change also improved the rendering performance a lot (by 40% as I tested). Errors was stored in three uint before this change, each with 24bit precision. This change encoded them into a single uint, each with 8bit precision. This reduced the shared memory usage, as well as number of atomic operations, all by three times. Before this change, with the minimum required 32kb shared memory, only the `simple` kernel can be used to render 1080p video, which is mostly useless compare to `--dither=fruit`. After this change, 32kb can handle `burkes` kernel for 1080p, or `sierra-lite` for 4K resolution.
* vo_gpu: fix use of existing textures in error diffusionBin Jin2019-06-161-6/+8
| | | | | | | error diffusion requires two texture rendering pass. The existing code reuses `screen_tex` and creates another for such purpose. This works generally well for opengl, but could potentially be problematic for vulkan, due to its async natural.
* vo_gpu: implement error diffusion for ditheringBin Jin2019-06-164-0/+423
| | | | | | | | | | | | | | | | | This is a straightforward parallel implementation of error diffusion algorithms in compute shader. Basically we use single work group with maximal possible size to process the whole image. After a shift mapping we are able to process all pixels column by column. A large ring buffer are allocated in shared memory to speed things up. However the size of required shared memory depends linearly on the height of video window (or screen height in fullscreen mode). In case there is no enough shared memory, it will fallback to `--dither=fruit`. The maximal allowed work group size is hardcoded as 1024. Ideally we could query `GL_MAX_COMPUTE_WORK_GROUP_INVOCATIONS`. But for whatever reason, it seems most high end card from nvidia and amd support only the minimal required value, so I guess we can stick to it for now.
* vo_gpu: d3d11: use the SPIRV-Cross C API directlyJames Ross-Gowan2019-06-121-19/+67
| | | | | | | | | | When the D3D11 backend was first written, SPIRV-Cross only had a C++ API and no guarantee of API or ABI stability, so instead of using SPIRV-Cross directly, mpv used an unofficial C wrapper called crossc. Now that KhronosGroup/SPIRV-Cross#611 is resolved, SPIRV-Cross has an official C API that can be used instead, so remove crossc and use SPIRV-Cross directly.
* vo_gpu: fix --scaler-resizes-only for fractional ratio scalingBin Jin2019-06-061-3/+6
| | | | | | | | The calculation of scale factor involves 32-bit float, and a strict equality test will effectively ignore `--scaler-resizes-only` option for some non-integer scale factor. Fix this by using non-strict equality check.
* vo_gpu: expose texture_off to user shaderBin Jin2019-06-061-0/+1
| | | | | It will provide low level access to coordinate mapping other than texmap().
* vo_gpu: allow user shader to fix texture offsetBin Jin2019-06-063-9/+45
| | | | | This commit essentially makes user shader able to fix offset (produced by other prescaler, for example) like builtin `--scale`.
* wayland: fix segfault on uninitNiklas Haas2019-05-261-1/+1
| | | | Probably the same issue as #6732
* wayland: fix various memory leaksdudemanguy2019-05-211-0/+33
|
* cocoa-cb: fix quit in fs with none native fsder richter2019-05-111-1/+2
| | | | | | | | | | since the none native fs is a special legacy case it needs a special quit routine. it indefinitely waited for an exit fs screen event to shutdown properly, though that event only fires for the native fs. now we check if we really are using a native fullscreen and if not shutdown immediately. Fixes #6704
* w32_common: avoid unnecessary sprintfsJames Ross-Gowan2019-05-101-8/+5
| | | | | | | | | | These were unnecessary for a couple of reasons, but it seems like the old code went through a lot of effort to avoid duplicating the code to print a RECT, even though the windowrc gets printed anyway at the end of the function. Avoid printing the same windowrc twice by only printing it when it gets changed (in the w32->current_fs branch.)
* drm_common: Support --drm-mode=<preferred|highest|N|WxH[@R]>Anton Kindestam2019-05-041-12/+226
| | | | | | | This allows to select the drm mode using a string specification. You can either select the the preferred mode, the mode with the highest resolution, by specifying WxH[@R] or by its index in the list of modes as before.
* drm_common: Don't export functions only being used internallyAnton Kindestam2019-05-042-22/+22
| | | | | As far as I know none of these functions were being used outside of drm_common, nor should there really be a need to use them.
* drm_common: Add proper help option to drm-modeAnton Kindestam2019-05-044-24/+92
| | | | | | | This was implemented by using OPT_STRING_VALIDATE for drm-mode, instead of OPT_INT. Using a string here also prepares for future additions to drm-mode that aim to allow specifying a mode by its resolution.
* drm_common: Add option to toggle use of atomic modesettingAnton Kindestam2019-05-044-11/+19
| | | | | | It is useful when debugging to be able to force atomic off, or as a workaround if atomic breaks for some user. Legacy modesetting is less likely to break by virtue of being a less complex API.
* vo/gpu: hwdec_cuda: Refactor gpu api specific code into separate filesPhilip Langdale2019-05-035-749/+845
| | | | | | | | The amount of code now present that's specific to Vulkan or OpenGL has reached the point where we really want to split it out to avoid a mess of #ifdefs. At the same time, I'm moving the code to an api neutral location.
* context_drm_egl: Add support for presentation feedbackAnton Kindestam2019-05-031-15/+118
| | | | | This implements presentation feedback for context_drm_egl using the values that get fed to the page flip handler.
* cocoa-cb: remove all force unwrappings of optionalsder richter2019-04-255-309/+411
| | | | | | the force unwrapping of optionals caused many unpredictable segfaults instead of gracefully exiting or falling back. besides that, it is bad practice and the code is a lot more stable now.
* vo_gpu/hwdec_cuda: fixup compilation with vulkan disabledJan Ekström2019-04-221-0/+2
| | | | | | | The actual code utilizing this enum was seemingly properly if'd, but not the enum in the struct itself. Fixes compilation.
* vo/gpu: hwdec_cuda: Reorganise backend-specific codePhilip Langdale2019-04-211-151/+223
| | | | | This tries to tidy up the GL vs Vulkan code to be a bit cleaner and easier to read.
* vo_gpu: hwdec_cuda: Implement interop for placeboPhilip Langdale2019-04-211-145/+224
| | | | | | | | | | | | | | | | | | | | This change updates the vulkan interop code to work with the libplacebo based ra_vk, but also introduces direct VkImage sharing to avoid the use of the intermediate buffer. It is also necessary and desirable to introduce explicit semaphore bsed synchronisation for operations on the shared images. Synchronisation means we can safely reuse the same VkImage for every mapped frame, by ensuring the frame is copied to the VkImage before mapping the next frame. This functionality requires a 417.xx or newer nvidia driver, due to bugs in the VkImage interop in the earlier 411 and 415 drivers. It's definitely worth the effort, as the raw throughput is about twice that of implementation using an intermediate buffer.
* vo/gpu: ra_pl: Add helper to get pl_fmt from ra_formatPhilip Langdale2019-04-211-0/+5
| | | | | | | When interacting directly with libplacebo, we may need to pass a pl_fmt based on an ra_format. Although the mapping is currently trivial, it's worth wrapping to make it easy to adapt if this changes in the future.
* vo_gpu: ra_pl: Add getter for pl_gpuPhilip Langdale2019-04-212-1/+8
| | | | | We need access to the underlying pl_gpu to make libplacebo calls from hwdecs.
* vo_gpu: vulkan: Add back context_win for libplaceboPhilip Langdale2019-04-212-3/+105
| | | | | Feature parity with the original ra_vk obviously requires win32 support, so let's put it back in.
* vo_gpu: vulkan: use libplacebo insteadNiklas Haas2019-04-2120-4355/+848
| | | | | | | | | | | | | | | | | | | | | | | | This commit rips out the entire mpv vulkan implementation in favor of exposing lightweight wrappers on top of libplacebo instead, which provides much of the same except in a more up-to-date and polished form. This (finally) unifies the code base between mpv and libplacebo, which is something I've been hoping to do for a long time. Note: The ra_pl wrappers are abstract enough from the actual libplacebo device type that we can in theory re-use them for other devices like d3d11 or even opengl in the future, so I moved them to a separate directory for the time being. However, the rest of the code is still vulkan-specific, so I've kept the "vulkan" naming and file paths, rather than introducing a new `--gpu-api` type. (Which would have been ended up with significantly more code duplicaiton) Plus, the code and functionality is similar enough that for most users this should just be a straight-up drop-in replacement. Note: This commit excludes some changes; specifically, the updates to context_win and hwdec_cuda are deferred to separate commits for authorship reasons.
* mp_image: align stride to multiple of texel sizeNiklas Haas2019-04-211-0/+3
| | | | | | | This helps with compatibility and/or performance in particular for oddly-sized formats like rgb24. We use a loop to avoid having to calculate the lcm (or waste bytes in the extremely common case of the byte size and the stride align having shared factors).
* vo_gpu: fix segfault when OSD tex creation failsNiklas Haas2019-04-211-1/+1
| | | | If !osd->texture, then mpgl_osd_draw_prepare fails.
* vo_gpu: index desc namespaces by raNiklas Haas2019-04-215-5/+5
| | | | | No reason to require them be constant. This allows them to depend on runtime characteristics of the `ra`.
* cocoa-cb: add support for custom colored title barder richter2019-04-022-0/+20
|
* cocoa-cb: refactor title bar stylingder richter2019-04-022-49/+108
| | | | | | | | | | | | | half of the materials we used were deprecated with macOS 10.14, broken and not supported by run time changes of the macOS theme. furthermore our styling names were completely inconsistent with the actually look since macOS 10.14, eg ultradark got a lot brighter and couldn't be considered ultradark anymore. i decided to drop the old option --macos-title-bar-style and rework the whole mechanism to allow more freedom. now materials and appearance can be set separately. even if apple changes the look or semantics in the future the new options can be easily adapted.
* cocoa-cb: add support for mac 10.14 Dark mode and run time switchingAkemi2019-04-021-5/+10
| | | | | | setting the appearance of the window to nil will always use the system setting and changes on run time switches too. this is only the case for macOS 10.14.
* cocoa-cb: move all title bar related functionality in its own fileder richter2019-04-024-156/+178
| | | | | | | | | quite a lot of the title bar functionality and logic was within our window. since we recently added a custom title bar class to our window i decided to move all that functionality into that class and in its own file. this is also a preparation for the next commits.
* cocoa-cb: remove an unused variableAkemi2019-04-021-1/+0
|
* cocoa-cb: simplify CGL pixel format creationAkemi2019-04-021-57/+75
| | | | | | | | | | | | | | | i found the old pixel format creation a bit too messy. pixel format attribute arrays and look ups were all over the place, the actual logic what kind of format was created