summaryrefslogtreecommitdiffstats
path: root/video/out/vo_gpu_next.c
Commit message (Collapse)AuthorAgeFilesLines
* various: fix typosHarri Nieminen2023-03-281-1/+1
| | | | Found by codespell
* vo_gpu_next: drop various PL_API_VER checksllyyr2023-03-261-44/+2
| | | | | We don't need these anymore now that we require PL_API_VER>=264 for building libplacebo-next
* vo_gpu_next: compatibility with libplacebo v6.265llyyr2023-03-131-1/+6
| | | | | | | | libplacebo v6.265.0 removed v4 deprecations. We already require PL_API_VER >= 202, so we don't need to wrap pl_tex_transfer_params.row_pitch around a conditional, which exists since PL_API_VER >= 168. However, pl_source_frame.duration does not exist until PL_API_VER >= 219, so we should use a conditional directive.
* vo_gpu_next: compatibility with PL_API_VER >= 254Niklas Haas2023-03-061-2/+12
| | | | This field was renamed/moved to a different params struct.
* vo_gpu_next: use inverse mapping functions to tag screenshotsLeo Izen2023-03-051-14/+5
| | | | | | Screenshots using the hardware renderer should now include color tags that map directly from the libplacebo tags, so the if/else logic only needs to be included once.
* vo_gpu_next: fix warning -Wunused-functionThomas Weißschuh2023-02-261-0/+2
|
* vo_gpu_next: fix color space hint with target peak overrideKacper Michajłow2023-02-231-1/+4
| | | | Fixes: #11339
* options: transition options from OPT_FLAG to OPT_BOOLChristoph Heinrich2023-02-211-6/+6
| | | | | | c78482045444c488bb7948305d583a55d17cd236 introduced a bool option type as a replacement for the flag type, but didn't actually transition and remove the flag type because it would have been too much mundane work.
* vo_gpu_next: add --tone-mapping-visualizeNiklas Haas2023-02-191-0/+3
|
* vo_gpu_next: parse Dolby Vision metadata for dynamic scene brightnessquietvoid2023-02-191-16/+2
| | | | | Improves playback for Dolby Vision video files as the metadata can be used instead of requiring `hdr-compute-peak=yes`.
* vo_gpu_next: allow native CSP screenshotsNiklas Haas2023-02-131-0/+5
| | | | | Useful for getting native screenshots of non-sRGB content, such as HDR etc.
* vo_gpu_next: tag screenshots with correct colorspaceNiklas Haas2023-02-131-0/+15
| | | | | | | | | When taking window screenshots with a colorspace override, tag them appropriately, based on the best-known colorspace info. Note that this is imperfect, we should ideally also attach the output ICC profile if one exists. But this is better than nothing. Also force 1:1 PAR in this case. In all other cases, default to sRGB.
* vo_gpu_next: only apply target options in window screenshot modeNiklas Haas2023-02-131-1/+5
| | | | | | | | | | When taking an unscaled screenshot, always render to an unspecified SDR-like space. (Subject to change) Apply output-specific options (ICC profile, color space overrides, custom LUT) only in window screenshot mode. I decided to split this off from subsequent refactors because it is IMO a bug fix deserving of its own commit.
* vo_gpu_next: be explicit about screenshot reprNiklas Haas2023-02-131-0/+1
| | | | | | Screenshots are currently always RGB. Subject to change, but needs to be communicated clearly if changed. This commit is not a functional change, it's merely for code clarity.
* vo_gpu_next: expose --tone-mapping=st2094-40 and st2094-10Niklas Haas2023-02-131-0/+4
|
* vo_gpu_next: support mapping HDR10+ dynamic metadataNiklas Haas2023-02-131-0/+19
| | | | | | | Based on the new upstream helper function `pl_map_hdr_metadata` and the existing AV_FRAME_DATA_DYNAMIC_HDR_PLUS. This allows us to use SMPTE 2094-40 dynamic HDR tonemapping in mpv, albeit with the limitation of requiring `--tone-mapping=auto` in order to pick this curve upstream.
* vo_gpu_next: add check for PL_HAVE_LCMSKacper Michajłow2023-02-021-1/+1
|
* osdep: add MP_FALLTHROUGHKacper Michajłow2023-02-021-1/+1
|
* vo_gpu_next: implement VO_DR_FLAG_HOST_CACHEDNiklas Haas2023-01-231-0/+5
| | | | For sufficiently new versions of libplacebo.
* vo: add `int flags` to the get_image signatureNiklas Haas2023-01-231-1/+1
| | | | | This is a huge disgusting mess to thread through everywhere. Maybe I'm stupid for attempting to solve the problem this way.
* vo_gpu_next: don't flush cache on OSD updateNiklas Haas2022-11-251-2/+9
| | | | | | | | | | | | | | | | | | | Flushing the cache is a hammer-for-a-screw operation, because it nukes *all* renderer state, including the HDR peak detection state. When enabling e.g. --hdr-compute-peak, or any other future methods of dynamic tone mapping, this would lead to bad results (e.g. brightness fluctuations) whenever the OSD state is updated. Instead of flushing the cache to force an OSD re-render, instead just update the frame signature directly whenever its osd_sync value changes. This accomplishes effectively the same thing but without touching the HDR state. This is slightly violating the libplacebo abstraction in a way that isn't publicly documented. To be on the safe side we could make a carbon copy of the array before modifying it, but given that this is unlikely to change upstream I'll probably just end up explicitly documenting it instead of forcing the copy in mpv.
* vo_gpu_next: fix undefined behavior on alpha-first formatsNiklas Haas2022-11-191-1/+4
| | | | | | | When the alpha channel is the first component, this code block gets skipped by the continue, meaning the check for c==0 never passes. Fix it by explicitly keeping track of whether bits have been set.
* vo_gpu_next: add tunable shader parametersNiklas Haas2022-11-111-1/+59
| | | | | | | | | | | This is a very simple but easy way of doing it. Ideally, it would be nice if we could also add some sort of introspection about shader parameters at runtime, ideally exposing the entire list of parameters as a custom property dict. But that is a lot of effort for dubious gain. It's worth noting that, as currently implemented, re-setting `glsl-shader-opts` to a new value doesn't reset back previously mutated values to their defaults.
* vo_gpu_next: set background transparencyNiklas Haas2022-11-011-0/+1
| | | | Fixes: https://github.com/mpv-player/mpv/issues/10815
* vo_gpu_next: fix crash on uninit after startup failurercombs2022-10-141-1/+1
|
* vo_gpu_next: respect --blend-subtitles=<yes/no>Niklas Haas2022-09-291-11/+31
| | | | | | | | | | | | | | | | | | | | | | | | | This brings vo_gpu_next's behavior more in line with vo_gpu. Currently, the status quo was that `vo_gpu_next` generated subtitles with the full resolution of the dst crop, even though practical limitations of libplacebo meant that such subtitles inevitably got cut off at the video boundaries. This was actually a worse status quo than `vo_gpu`, which simply constrained subtitles to the video dimensions to prevent these issues. With this change, the behavior is the same as `vo_gpu`, which has the exact same problem w.r.t interpolation. Users are back to choosing between --blend-subtitles=yes and not having subtitles in margins, and using --blend-subtitles=no and not having subtitle interpolation. There are different pros and cons to each approach, and I still ultimately plan on allowing libplacebo to interpolate subtitles even in the black bars, to solve this issue once and for all. But for now, let's not let perfect be the enemy of good. No attempt is made to implement `--blend-subs=video`, which I consider deprecated. Fixes: https://github.com/mpv-player/mpv/issues/10272
* vo_gpu_next: fix screenshots of rotated sourcesNiklas Haas2022-09-271-3/+6
| | | | | | | I actually don't quite understand why this is needed, since in theory we should already be doing the rotation as part of applying the crop. But I guess that code doesn't quite work. This is the only way it works, so it's probably correct. (And note that `vo_gpu` does the same internally)
* vo_gpu_next: use static assert for array sizeNiklas Haas2022-09-271-1/+1
| | | | This is used in other places in the code, so it should be fine.
* vo_gpu_next: update render_info for upstream API changeNiklas Haas2022-09-261-11/+14
| | | | | | This fixes an issue where blend stages with multiple passes got overwritten by later passes, with only the final pass (typically the overlayp pass) actually being shown.
* vo_gpu_next: implement --video-output-levelsNiklas Haas2022-09-251-0/+4
| | | | This was ignored as an oversight.
* vo_gpu_next: support error diffusion ditheringNiklas Haas2022-09-201-6/+14
| | | | One step closer to vo_gpu_next feature parity with vo_gpu!
* vo_gpu_next: only require full pixel byte alignmentNiklas Haas2022-09-121-3/+3
| | | | | The current code also rejects e.g. rgb30, even though this format is perfectly valid, because it only checks for alignment of the used bits.
* vo_gpu_next: implement ICC 3DLUT cachingNiklas Haas2022-09-121-0/+65
| | | | | | | Relies on a new upstream API for adding save/load callbacks to the ICC 3DLUT generation parameters. Closes: https://github.com/mpv-player/mpv/issues/10252
* vo_gpu_next: use correct pixel size when mapping formatsNiklas Haas2022-09-121-1/+1
| | | | | `total_bits` may be less than the true pixel stride (`bpp`) for formats which contain extra ignored components (e.g. rgb0).
* vo_gpu_next: fix typo affecting --target-trc optionTillmann Karras2022-09-021-1/+1
|
* vo_gpu_next: display subtitles without video streamNiklas Haas2022-08-311-1/+2
| | | | Fixes https://github.com/mpv-player/mpv/issues/10594
* vo_gpu_next: fix screenshots on single-frame filesNiklas Haas2022-07-231-1/+1
| | | | | This check was wrong/outdated. PL_QUEUE_MORE does not imply an empty frame mix, it can still contain partial frames.
* vo_gpu_next: don't crash on !frame->currentNiklas Haas2022-07-181-5/+7
| | | | This path incorrectly assumes there is a current frame.
* vo_gpu_next: implement --cscaleNiklas Haas2022-06-241-0/+3
| | | | Fixes #9451
* vo_gpu_next: fix OSD rendering of screenshotsNiklas Haas2022-06-061-5/+6
| | | | | | | | | | | | | | One downside of this approach is that it bypasses the mixer cache, but while this is not ideal for performance reasons, the status quo is also simply broken so I'd rather have a slower implementation that works than a faster implementation that does not. And as it turns out, updating the OSD state and invalidating the mixer cache correctly is sufficiently nontrivial to do in a clean way, so I'd rather have this code that I can be reasonably certain does the right thing. Fixes #9923 as discussed. Also fixes #9928.
* vo_gpu_next: avoid 0x0 resizesDudemanguy2022-04-241-2/+4
| | | | | | | | | | | It is possible for vo_gpu_next to attempt a resize before the windowing backend is fully initialized. In practice, this can happen on wayland which means libplacebo attempts a 0x0 resize. Depending on the API, a 0x0 resize may be allowed (vulkan or d3d11), but libplacebo just returns a 0 in this case which mpv doesn't do anything with anyway. In the case of opengl, this usage is explictly forbidden and will result in a warning which may confuse users. Solve this by just not trying a resize if dwidth and dheight in the vo are not available. Fixes #10083.
* vo_gpu_next: switch to unpooled hwdec mappingNiklas Haas2022-04-111-62/+83
| | | | | | | | | | | | This makes use of the new frame acquire/release callbacks to hold on to hwdec images only as long as necessary. This should greatly improve the smoothness/efficiency of hwdec interop, by not holding on to them for longer than needed. This also avoids the need to pool hwdec mappers altogether. Should fix #10067 as well, since frames are now only mapped when we actually use them.
* vd_lavc: add vo caps and option to set GPU film grain applicationLynne2022-04-051-1/+5
|
* vo_gpu_next: apply film grain if such metadata is presentLynne2022-04-051-0/+5
|
* Revert "vo_gpu_next: remove unnecessary dependency"Niklas Haas2022-04-011-2/+1
| | | | | | This reverts commit 1c2dde91d369987199782f4914f56019e5a2272c. Fixes #10037
* vo_gpu_next: remove unnecessary dependencyNiklas Haas2022-03-291-1/+2
| | | | | | Pulling in <libplacebo/utils/libav.h> in particular triggers the notorious _av_vkfmt_from_pixfmt linking issue when FFmpeg is built without Vulkan support.
* vo_gpu[_next]: hwdec: fix logging regression when probingPhilip Langdale2022-03-211-3/+3
| | | | | | | | | When I introduced the concept of lazy loading of hwdecs by img format, I did not propagate the probing flag correctly, leading to the new normal loading path not runnng with probing set, meaning that any errors would show up, creating unnecessary noise. This change fixes this regression.
* vo_gpu_next: also include stride alignment in DR sizeNiklas Haas2022-03-141-2/+3
| | | | Fixes #9976
* vo_gpu_next: fix crash when disabling DR at runtimeNiklas Haas2022-03-081-5/+6
| | | | | | | This code fails if we have DR buffers, but none of them correspond to the current frame. Normally only happens if e.g. changing the decoder at runtime, since DR buffers are not properly reinit in that case. (Arguably a separate bug)
* vo_gpu_next: don't leak mpi on failed uploadNiklas Haas2022-03-081-32/+37
| | | | | | | The current map_frame() code fails to clean up after itself on the failure paths. But if map_frame returns false, no cleanup code is ever attempted. Add the relevant calls to clean up state manually, throughout.
* vo_gpu_next: properly keep track of DR allocationsNiklas Haas2022-03-071-27/+39
| | | | | | | | | | | | | | | | | | | So, turns out the approach in 7f67a553f doesn't work for all codecs. In particular, sometimes lavc will internally allocate a new AVBuffer that just points at the old AVBuffer but has a different opaque field for some reason. In these cases, the DR metadata doesn't survive the round-trip through libavcodec. I explored several alternative ways of solving this problem, including adding new mp_image fields, but in the end none of them survived the round-trip through AVFrame and back. The `priv` and `opaque` fields in respectively `mp_image` and `AVFrame` are also too heavily overloaded to be of much help. In the end, bite the bullet and use the same approach as done in `vo_gpu`, which is to just keep track of a list of all allocations. This is a really ugly way of doing things IMO, but ultimately, completely safe.
* vo_gpu_next: don't allocate dr_buf as part of the AVBufferRefNiklas Haas2022-03-061-20/+9
| | | | | | | | | | | | | | | | | | Some decoders, notably hevcdec, will unconditionally memset() the entire AVBufferRef based on the AVBufferRef size. This is bad news for us, since it also overwrites our `struct dr_buf`. Rewrite this code to make it more robust - keep track of the DR buf metadata in a separate allocation instead. Has the unfortunate downside of technically being undefined behavior if `opaque` is not at least 64 bits in size, though, but avoids this issue. Maybe there's a better way for us to unconditionally keep track of DR allocation metadata. I could try adding it into the `mp_image` itself. Maybe on a rainy day. For now, this works. Fixes #9949 Might fix #9526
* vo_gpu_next: add D3D11 RA texture wrapping/unwrapping for hwdecJames Ross-Gowan2022-03-031-1/+21
| | | | This mostly copies the API used in the GL backend.
* vo_gpu_next: add support for hardware decodingNiklas Haas2022-03-031-35/+166
| | | | | | | | | | | | | | | | There are two major ways of going about this: 1. Expose the native ra_gl/ra_pl/ra_d3d11 objects to the pre-existing hwdec mappers, and then add code in vo_gpu_next to rewrap those ra_tex objects into pl_tex. 2. Wrap the underlying pl_opengl/pl_d3d11 into a ra_pl object and expose it to the hwdec mappers, then directly use the resulting pl_tex. I ultimately opted for approach 1 because it enables compatibility with more hardware decoders, specifically including ones that use native OpenGL calls currently. The second approach only really works with cuda_vk and vaapi_pl.
* vo_gpu_next: configure the VO queue size dynamicallyNiklas Haas2022-03-031-12/+21
| | | | | | This avoids decoding/caching more frames in advance than necessary. In particular, this is very important for hwdec, which generally can't have too many decoded frames in a pool at the same time.
* vo_gpu_next: remove/simplify plane flipping hacksNiklas Haas2022-02-251-37/+9
| | | | | | | | | libplacebo v198 fixed this properly by adding the ability to flip planes directly, which is done automatically by the swapchain helpers. As such, we no longer need to concern ourselves with hacky logic to flip planes using the crop. This also removes the need for the OSD coordinate hack on OpenGL.
* vo_gpu_next: avoid rendering subtitles as HDR/wide gamutNiklas Haas2022-02-251-1/+9
| | | | Fixes #9911
* vo_gpu_next: refactor subtitle renderingNiklas Haas2022-02-211-30/+52
| | | | | | | | | | | | | | | Render subs at the output resolution, rather than the video resolution. Uses the new APIs found in libplacebo 197+, to allow controlling the OSD resolution even for image-attached overlays. Also fixes an issue where the overlay state did not get correctly updated while paused. To avoid regenerating the OSD / flushing the cache constantly, we keep track of OSD changes and only regenerate the OSD when the OSD state is expected to change in some way (e.g. resolution change). This requires introducing a new VOCTRL to inform the VO when the UPDATE_OSD-tagged options have changed. Fixes #9744, #9524, #9399 and #9398.
* vo_gpu_next: don't crash on negative plane stridesNiklas Haas2022-02-111-5/+34
| | | | | | | | | | | | | | This is an annoying special case only really needed because of the `vflip` filter. mpv handles this by directly adjusting the plane transform. The libplacebo API, unfortunately, does not allow passing the required information for this to work smoothly. Long-term I plan on adding support for plane flipping in libplacebo directly, but for the meantime, we will have to work-around it by moving the flipping to the whole-image `crop` instead. Not an ideal solution but better than crashing. Fixes #9855
* vo_gpu_next: create shader cache dir if missingNiklas Haas2022-02-031-0/+1
| | | | | Failing to do this results in the shader cache not actually ever being written, ergo no shader caching being done. Oops.
* vo_gpu_next: fix SUBBITMAP_BGRANiklas Haas2022-01-111-1/+1
| | | | | | | | | The only way to fix the channel order here is to create the texture with bgra format. Incidentally, there used to be a way to set the component map for overlays directly, but no more. Shouldn't matter since everything supports bgra8 anyways, though. Fixes #9699
* sub: rename SUBBITMAP_RGBA to SUBBITMAP_BGRANiklas Haas2022-01-111-3/+3
| | | | | This was a misnomer, the actual channel order is IMGFMT_BGRA (as the comment explicitly point out). Rename the enum for consistency.
* vo_gpu_next: forward dovi metadata to libplaceboNiklas Haas2022-01-091-0/+17
|
* vo_gpu: add --tone-mapping-modeNiklas Haas2022-01-071-0/+9
| | | | | | | | | | | This merges the old desaturation control options into a single enumeration, with the goal of both simplifying how these options work and also making this list more extensible (including, notably, new options only supported by vo_gpu_next). For the hybrid option, I decided to port the (slightly tweaked) values from libplacebo's pre-refactor defaults, rather than the old values we had in mpv, to more visually match the look of the vo_gpu_next hybrid.
* vo_gpu: add --gamut-mapping-modeNiklas Haas2022-01-071-5/+9