-
Notifications
You must be signed in to change notification settings - Fork 2.9k
GPU Next vs GPU
This page documents the known differences between vo_gpu_next
and vo_gpu
(that is, between --vo=gpu-next
and --vo=gpu
).
-
--blend-subtitles
(#9870) -
--gamma-factor
and--gamma-auto
-
--cscale
: currently,gpu-next
uses the--scale
filter for everything, without the ability to tune it by plane type; subject to change by popular request -
--dither=error-diffusion
(#9415)
-
--sub-use-margins
+--video-sync=display-*
currently cuts off subtitles
-
--fbo-format
: the best we can currently do is disable FBOs (--gpu-dumb-mode=yes
) or force 8-bit FBOs (option not yet implemented) -
--icc-force-contrast
:ICC/3DLUT color management is currently in a state of flux and will be rewritten soon, no idea what will happen to this option as a resultICC/3DLUT handling has been rewritten, but the new options are not yet implemented in the mpv API.
-
--sharpen
: Very low quality and easily replaced by (better) custom shaders (#9387, #9845) -
ewa_lanczossharp
/ewa_lanczossoft
: Easily replicated by tuningewa_lanczos
(see below for further justification) -
haasnsoft
: Easily replicated by tuningewa_lanczos
-
--tone-mapping-max-boost
: crutch for bad tone-mapping functions and lack of black point handling -
--vf=format:light=...
: OOTFs are tied to the EOTF ingpu-next
, and can no longer be adjusted independently -
--scaler-resizes-only
: enabled by design ingpu-next
, so the option does nothing
-
gpu-next
should be generally faster across the board, owing to refactors and rewrites of many key algorithms (EWA scaling, frame interpolation, color management, PRNG/debanding, etc.) -
gpu-next
aggressively merges shader passes wherever possible, leading to a significant reduction in the number of full-screen draw calls required per frame; in addition to this it also more aggressively reuses internal frame caches -
gpu-next
, unlikegpu
, performs black point compensation during color management, leading to subtly different results for many of the tone mapping-related options -
gpu-next
generally defaults tobt.1886
instead ofgamma2.2
for the display output, due to the better/different black point handling -
gpu-next
doesn't rotate/flip frames until the final output pass, whereasgpu
applied this during the main scaling pass. This generally makes it more robust when combining custom user shaders with rotated videos
-
ewa_lanczos
defaults to using radius 3.2383... ingpu-next
, rather than the radius 3.0 ofgpu
. Note that the (deleted)ewa_lanczossharp
prefix also used the 3.2383 radius instead of 3.0, which was the main reason for the difference between those two presets in the first place. So, sinceewa_lanczos
now uses the larger radius by default, the difference between it and the "sharper" preset is almost nonexistant. -
--tone-mapping=auto
: chooses betweenspline
,bt.2446a
andbt.2390
, instead of always pickingbt.2390
-
--tone-mapping=gamma
: scaling of the parameter has been changed slightly -
--tone-mapping=bt.2390
: knee point is now tunable, defaulting to 1.0 instead of the hard-coded 0.50 fromgpu
-
--tone-mapping=linear
: is now perceptually linear instead of linear light -
--tone-mapping-mode=auto
: chooses the new modeluma
by default, in most circumstances -
--tone-mapping-mode=hybrid
: uses a different hard-coded tradeoff function -
--gamut-mapping-mode=auto
: picks the new modedarken
by default -
--gamut-mapping-mode=warn
: makes out-of-gamut pixels magenta, instead of inverting them -
--hdr-compute-peak
:gpu-next
generally uses frame-exact results, rather than delaying detected peaks by a frame -
--scale=box
is no longer resizable, but see: -
--scale
can now be used directly on window functions, removing the need for--scale-window
+--scale=box
combo; in addition, a few new functions are available while others have been removed
-
TEXTURE_rot
is no longer needed (it still exists for compatibility, but it's defined as an identity matrix) - The distinction between
MAIN
andMAINPRESUB
no longer exists - either name can be used to refer to the same texture - Two new macros
linearize
anddelinearize
are available in all shader stages, resolving to GLSL functions for going back and forth between the video's native color space and linear light
- Support for Dolby Vision content (MMR and reshaping for all profiles and IPTPQc2 for profile 5, but no NLQ of FEL and EL summation for profile 7 (Blu-ray), no support for trims artistic metadata, but there is support for HLG Dolby Vision of iPhones including convertion to PQ, since Windows lacks HLG passthrough). EL summation can be done with https://github.com/quietvoid/vs-nlq (see https://github.com/quietvoid/dovi_tool/issues/44#issuecomment-996410366), maybe will be added later. You need to parse RPU to understand whether Blu-ray second video stream is MEL or FEL, it cannot be recognized by bitrate.
Only Vulkan supports autotrigger of HDR Windows mode in SDR Windows mode, but since Nvidia driver 442.92 (first DirectX 12 Ultimate driver) d3d11 HDR autotrigger is not supported (in Chrome and MadVR too). To correctly present linear RGB of BT.2020 primaries you get after MMR and decoding of IPTPQc2 you need to make it think it is PQ and BT.2020 primaries to select (hint) correct swapchain and force libplacebo to convert to that (matrix with reshaping and range are done by libplacebo, so those are always correct). This can be done with mpv.com --vf=format=gamma=pq:primaries=bt.2020:colorlevels=full --target-colorspace-hint=yes -hwdec=nvdec --gpu-api=vulkan -vo=gpu-next profile5.mp4 for profile 5, autotrigger of HDR will work for profile 5 Dolby Vision. That is a bug for profile 5, profile 8 is not affected since it is also has transfer and primaries tagged in VUI, not only in RPU.
--gpu-api=d3d11 -vo=gpu-next does not support -hwdec=nvdec, while --gpu-api=d3d11 -vo=gpu-next does not support -hwdec=d3d11va, use them the opposite way. Since only nvdec (of Turing and later, Intel also, but that is not work in progress in ffmpeg) supports 4:4:4 10 bit HEVC video you will have to use Vulkan to activate HW decoding for it.
Profile 5 Dolby Vision uses left chroma siting even though it uses BT.2020 primaries while profile 7 for Blu-ray and 8 uses top-left. That should be correctly applied in 420 --> 444 (after which --> R'G'B' or --> L'M'S' happens) convertion if it is tagged in VUI (all movies are tagged correctly, since that is internal HEVC field after Dolby encoder, but on some profile 5 samples it may be absent but that is not a problem since by HEVC default it is still left).
Other Dolby Vision profiles in AV1 or H.264 and other methods are not supported and Dolby even deprecated H.264 profile 4, so it will be hard to reverse engineer it.
Profile 5 of Dolby Vision allows to save 11.5 bits inside 10 bit, so is much better than 10 bit YCbCr. Unfortunately, to utilise that 12 bit PQ swapchain is needed on Nvidia Vulkan or d3d11 side (or P012 for 420 12 bit), but for that float PQ buffers are needed but not supported (example that uses RGBA_F16 with transfer:LINEAR_HDR is Chrome as can be seen in chrome://gpu in HDR mode).
--interpolation-preserve
-
--lut
,--image-lut
,--target-lut
-
--target-colorspace-hint
: cross-platform HDR passthrough, with metadata forwarding and automatic tone-mapping --tone-mapping=bt.2446a
--tone-mapping=spline
--inverse-tone-mapping
--tone-mapping-crosstalk
--tone-mapping-mode=luma
--allow-delayed-peak-detect
- #8223
- #9863
- #5727
- lots more that I forgot about