summaryrefslogtreecommitdiffstats
path: root/video/out/vo_gpu_next.c
Commit message (Collapse)AuthorAgeFilesLines
* 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
| | | | | | | Merge --gamut-clipping and --gamut-warning into a single option, --gamut-mapping-mode, better corresponding to the new vo_gpu_next APIs and allowing us to easily extend this option as new modes are added in the future.
* vo_gpu_next: use new HDR metadata optionsNiklas Haas2022-01-071-62/+52
| | | | | Properly forward the HDR metadata from the mpi to the equivalent (new) fields in pl_color_space. Used by the new tone mapping code.
* vo_gpu_next: update for new tone mapping optionsNiklas Haas2022-01-071-14/+19
| | | | | | | This was significantly refactored upstream. Switch to new APIs and add new tone mapping curves and options. cf. https://code.videolan.org/videolan/libplacebo/-/merge_requests/212
* vo_gpu_next: fix --target-peak scalingNiklas Haas2021-12-291-1/+1
| | | | This is in nits, so it needs to be converted.
* vo_gpu_next: implement VOCTRL_EXTERNAL_RESIZEsfan52021-12-191-0/+4
| | | | | | This is only needed on Android and supposed to handle a context resize without reconfiguring the image parameters. reconfig() already does exactly this so plug it in there.
* vo_gpu_next: fix UB in query_format()Niklas Haas2021-12-051-1/+1
| | | | | | | | | `plane_data_from_imgfmt` doesn't zero-initialize the struct, so this contained invalid values for e.g. `row_stride`, causing formats to *randomly* fail. (Especially any formats with specific alignment requirements) Might fix #9424 and #9425.
* vo_gpu_next: implement VOCTRL_SCREENSHOTNiklas Haas2021-11-281-2/+120
| | | | | | | | | | | | | | | | | | | | | | | | | | Somewhat annoying but still relatively straightforward. There are several ways to approach this, but I settled on reusing the pl_queue as a cheap way to get access to the currently mapped frame. This saves us from having to process `vo_frame` at all, and also avoids any overhead from re-uploading the same frame twice. (However maybe there's some circumstance in which `vo_frame` needs to be queried/updated first, to get a screenshot of the correct frame? I'm not sure.) I also had the option of going with either pl_render_image() on the extract pl_frame, or just calling pl_render_image_mix directly on it. I went for the latter, because in the optimal case, this allows the rendered frame to be directly retrieved from the cache, actually entirely avoiding any sort of recompute overhead. This makes e.g. ctrl+s during playback essentially free. (Except for the download cost, obviously) It would be even neater if we could make this VOCTRL asynchronous and thereby leverage libplacebo's asynchronous download capabilities. But oh well. That will have to wait for a sufficiently rainy day. Closes #9388
* vo_gpu_next: factor out some common helpersNiklas Haas2021-11-281-43/+63
| | | | In preparation of VOCTRL_SCREENSHOT support
* vo_gpu_next: guard sentinel in free_dr_bufNiklas Haas2021-11-261-0/+1
| | | | | | As noticed in #9526, apparently there's some case in which DR buffers get corrupted. Add an explicit sentinel check to try and figure out which cases these are.
* vo_gpu_next: implement OpenGL context supportsfan52021-11-221-5/+13
| | | | | Wrapping the context is pretty straightforward. This is only complicated by needing to account for the upside-down framebuffer in a few places.
* vo_gpu_next: factor out context-specific code to gpu_next/context.csfan52021-11-221-27/+17
| | | | | | This is done to avoid cluttering vo_gpu_next.c with more ifdeffery and context-specific code when additional backends are added in the near future. Eventually gpu_ctx is intended to take the place of ra_ctx to further separate gpu and gpu_next.
* vo_gpu_next: respect tagged YUV colorspaceNiklas Haas2021-11-221-1/+2
| | | | Fixes 2b2442ee67913221e5c87cbc06010671e1b41c15
* vo_gpu_next: apply csp overrides for RGB/XYZ/YUV formatsNiklas Haas2021-11-221-11/+27
| | | | | | | | | | | | | This is needed when the color system is not explicitly tagged, but instead needs to be inferred by the VO. Note that there exists the function mp_image_params_guess_csp for this sort of stuff, but it contains a lot of baggage that I don't want to replicate, in order to move as much of this logic into pl_renderer as possible, and therefore also give it the best chance of knowing what shortcuts it can and can't take. Fixes the other half of https://github.com/mpv-player/mpv/issues/9499
* vo_gpu_next: fix timings without interpolationDudemanguy2021-11-211-3/+5
| | | | | | | | | | Adding vsync_offset to the pts in pl_queue_update actually messes up frame timings if one isn't using interpolation. The easiest way to see this is to have the monitor's refresh rate at an integer multiple of a video during a panning shot (classic case). There will be very visible judder/stutter in this case that does not happen in vo_gpu. The cause of this is the addition of the extra vsync_offset. Just match the semantics of vo_gpu where this is only used when interpolating.
* vo_gpu_next: fix OOM on waylandNiklas Haas2021-11-201-7/+3
| | | | | | Similar to ff0864d5f07d31c808014dbf1791ed3ec14644a8 Fixes #9484
* vo_gpu_next: always cache still framesNiklas Haas2021-11-191-1/+3
| | | | | | | Even when not display synced. Prevents redraw overhead for refreshes while paused. Also make the logic slightly clearer to follow (since it's inverted).
* vo_gpu_next: fix lancozs typo to lanczosLeo Izen2021-11-191-1/+1
| | | | | Fix typo in the warning to avoid ewa_lanczossharp because it might be removed in the future.
* vo_gpu_next: simplify and improve frame redrawing logicNiklas Haas2021-11-191-14/+6
| | | | | | | | | | | | | | | | | | This almost perfectly recreates the semantics of --vo=gpu, i.e.: - still frames are never interpolated - non-repeated frames bypass single frame cache The only difference is that libplacebo doesn't do a cache/blit on the full output image, but rather it re-runs the last rendering step. This has some advantages and some drawbacks. The most notable advantage is that it also allows re-using the image contents when the only thing that changes is the OSD (whereas `--vo=gpu` would force a full re-render for that). The most notable drawback is that it also implies going through the dithering and output LUT logic on redraws. All in all, I think this is a pretty good trade-off in favor of `--vo=gpu-next`. Fully fixes the last remaining performance difference in #9430.
* vo_gpu_next: fix panning on rotated videosNiklas Haas2021-11-191-4/+10
| | | | Closes #9454
* vo_gpu_next: Initialize `pl_frame_mix`Starsam802021-11-091-1/+1
| | | | | Without initializing, the random data causes the `pl_render_image_mix` function to abort with a SIGSEGV.
* vo_gpu_next: implement HDR passthroughNiklas Haas2021-11-081-0/+60
| | | | | | | | Completely untested, since Linux still can't into HDR in 2021. Somebody please make sure it works. Technically covers #8219, since gpu-context=drm can be combined with vo=gpu-next.
* vo_gpu_next: drop PL_API_VER checksNiklas Haas2021-11-081-8/+0
| | | | These are no longer needed with the minimum version bump.
* vo_gpu_next: fix resource exhaustion on minimized windowsNiklas Haas2021-11-081-2/+8
| | | | | | | | This required an upstream API change to implement in a way that doesn't unnecessarily re-push or upload frames that won't be used. I consider this a big enough bug to justify bumping the minimum version for it. Closes #9401
* vo_gpu_next: add automatic translation for ewa_lanczossharpNiklas Haas2021-11-071-0/+7
| | | | | | | This one hits a lot of people. Probably because the man page explicitly recommends it. Fixes #9408
* vo_gpu_next: implement --dither-depthNiklas Haas2021-11-071-0/+8
| | | | | | I somehow completely forgot about this option existing. Closes #9416
* vo_gpu_next: remove --builtin-scalers optionNiklas Haas2021-11-071-4/+0
| | | | | | | | | | | Looking at this again I'm not sure it does anything useful at all. The man page entry is also wrong: `bicubic` is not affected, only `bicubic_fast`, and those filters are not configurable anyways. So this would only ever be a debugging option, and I don't see a pressing need for it. No interface-change.rst update because it only just got added anyways.
* vo_gpu_next: call start_frame in vulkan/context.cDudemanguy2021-11-041-0/+6
| | | | | | | | | In practice, this is for wayland. vo_gpu_next doesn't check the check_visible parameter since it didn't descend into the vulkan/context.c file when starting a frame. To make this happen, just call the start_frame function pointer but pass NULL as the ra_fbo. In there, we can do the visibility checks and after that bail out of the start_frame function if ra_fbo is NULL.
* vo_gpu_next: fix --tone-mapping-param mappingNiklas Haas2021-11-031-0/+2
| | | | | | vo_gpu defaults this to NAN, libplacebo uses 0.0 as the default. Fixes https://github.com/mpv-player/mpv/issues/9386
* vo_gpu_next: add new libplacebo-based rendererNiklas Haas2021-11-031-0/+1264
As discussed in #8799, this will eventually replace vo_gpu. However, it is not yet complete. Currently missing: - OpenGL contexts - hardware decoding - blend-subtitles=video - VOCTRL_SCREENSHOT However, it's usable enough to cover most use cases, and as such is enough to start getting in some crucial testing.
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-31 07:09:44 +0000