gpu-next (libplacebo) & vulkan

[hooke007]

mpv-player/mpv@d21b1f1

mpv的 vo=gpu-next （原 vo=placebo ）已基本实现且并入主干，mpv版本号推进到0.35.0

主要已知问题

• 频繁更新中，可能产生性能颠簸及渲染错误。
  建议自行积极向上游报告与切换到相对稳定的版本

主要新功能&特异点

• 杜比视界的深入支持
• 着色器运行时的子参数调节
  https://mpv.io/manual/master/#options-glsl-shader-opts
• 更多hdr转sdr的色调映射算法
  --tone-mapping=spline/bt.2446a/st2094-40/st2094-10
• 跨平台hdr直通
  --target-colorspace-hint=yes （FAQ_win10开启hdr透传）
• --sharpen 不可用（不会修复：设计初衷、可变相再现）
• 无法使用部分缩放算法；现存缩放算法与vo_gpu的默认小参不同（不会修复：设计初衷、可变相再现）
  ewa_lanczossharp ewa_lanczossoft haasnsoft bartlett tukey
• --libplacebo-opts 可使用该参数直驱渲染器的内部参数设置
  https://mpv.io/manual/master/#options-libplacebo-opts

其它的详细内容参见官方说明 https://github.com/mpv-player/mpv/wiki/GPU-Next-vs-GPU

二楼为使用示例

[hooke007]

👉 mpv.conf

1. 使用gpu-next

 vo = gpu-next

1.1. 如果切换到vulkan

 gpu-context   = winvk
#vulkan-device = "NVIDIA GeForce RTX 2070 Super" # 指定显卡

1.2. 算法再现

通过多个参数实现vo_gpu版的算法表现

## 1.2.1. 原版 jinc
## 未知

## 1.2.2. 原版 ewa_lanczos
 scale        = ewa_lanczos
 scale-radius = 3

## 1.2.3. 复活 ewa_lanczossharp
 scale      = ewa_lanczos
 scale-blur = 0.9812505644269356

## 1.2.4. 复活 ewa_lanczossoft
 scale      = ewa_lanczos
 scale-blur = 1.015

## 1.2.5. 复活 haasnsoft
 scale      = ewa_hanning
 scale-blur = 1.11

MPV_lazy/portable_config/profiles.conf

Lines 115 to 120 in c4ea013

	[Tscale-box]
	##这组时间插值方案参数来自开源社区，顺滑但不一定适合所有源 https://github.com/mpv-player/mpv/issues/2685
	tscale = box
	tscale-window = quadric # 或者 sphinx
	tscale-radius = 1.0 # 较高值更顺滑但也更糊，例 1.01
	tscale-clamp = 0.0

以上的[Tscale-box]在vo_gpu-next中无效，以下实现近似效果

## 1.2.6. 时域插值替代方案一
 tscale       = quadric
 tscale-clamp = 0

## 1.2.7. 时域插值替代方案二
 tscale      = sphinx
 tscale-blur = 0.6991556596428412

1.2.8. 近似 --sharpen 效果的着色器

sharpen = 1 等效 unsharp_masking_RT.glsl

1.3. 使用杜比视界的元数据

不使用计算着色器的亮度测量，实现近原生的动态映射。

## 当前使用 st2094-40 的方法配合
hdr-compute-peak = no
tone-mapping     = st2094-40

👉 input.conf

2. 运行时变更着色器内部参数

对于 vo=gpu ，修改着色器的内部子参数的同时如果需要保留原始参数，只能另存为一个新变体以供mpv使用
而 gpu-next 并不需要这么做，支持在运行时变更着色器的子参数

<key>   set glsl-shader-opts [着色器名1(无后缀名)/]<PARAM参数名1>=<值1>,[着色器名2(无后缀名)/]<PARAM参数名2>=<值2>...   # 如不指定着色器名，则传递参数到所有着色器中

2.1. 近似 --sharpen 效果的着色器

如果要实现 --sharpen = -1 的模糊效果，即 glsl-shader-opts unsharp_masking_RT/SHARP=-1

[natural-harmonia-gropius]

能不能测下二者的性能表现
还有lut conversion的表现（另外mpv有lut插值吗？

[hooke007]

我现在的设备很多测试没法做。
根据现有条件只能同样锁定软解和vulkan平等测试
刚测了一个hdr tonemapping === 性能占用完全没区别

lut插值是什么-_-
lut=file 这个居然不能在运行时切换。。。
但是显然比滤镜形式节能高效的多

[natural-harmonia-gropius]

https://b23.tv/4QNyo9 8:50，64级的lut精度对应6bpc，10bpc需要1024级，不然会有色带

vf性能消耗高出这么多有点令人意外

[hooke007]

那跟我说的是同一个东西。
我的测试样本：https://github.com/hooke007/MPV_lazy/tree/master/Temp#lavfi--lut3d
也不算太意外，lut3d是个cpu滤镜，之前用在vo_gpu上开hwdec=auto-copy甚至会因为效率低下产生掉帧卡顿

[hooke007]

关于意义的问题，作为创始人之一的wm4离开了mpv-player项目，团队里似乎也没有第二个人能像wm4那样了解vo_gpu，所以可能围绕着vo_gpu的所有bug和新功能都永远无法解决和出现。不过当下 libplacebo不管是本体 https://github.com/haasn/libplacebo 还是mpv上的移植 vo_gpu-next 目前都是实验性阶段（ps. 这玩意开发程度达到成熟地步之后 vlc 播放器也将得到巨大飞升 vlc4.0 beta 已经预置了）

nvdec那是hwdec的事了，需要等待后续开发

[yeezylife]

我的意思是现阶段普通用户改用(尚未成熟的)vo=gpu-next的意义不大...未来vo=gpu-next应该会替代vo=gpu,注意到你对ravu-zoom系列的改动了,很帅!

[nyfair]

惊了，还有这么一出戏，好多年前还和他一起研究过车万解包来着，看wm4的主页他是被踢出去的明显有不满。

[hooke007]

惊了，还有这么一出戏，好多年前还和他一起研究过车万解包来着，看wm4的主页他是被踢出去的明显有不满。

第一次是2020年10月（大概）
账号被盗，被迫主动清理了全部数据，导致了连mpv项目中的commit相关记录都除名了，现在他首页的牢骚说的就是当时的事情。此后偶尔好像有委托他人提交commit的形式给mpv做贡献。

第二次是完全退出不再参与。主要原因是和haasn的理念冲突，一小部分当时的争吵记录还能在 vo_placebo 那个pr里找到，当时吵的有点多我有点记不清讲啥了，一部分言论也被其他团队管理清理了，导致剩下的对话有点莫名其妙虚空对线一样。

[dyphire]

gpu-next对色调映射进行了优化，这也是原定相对gpu的改进提升中的代表性特点。不过我测试的不多，目前还没注意到什么显著改善

[yeezylife]

就是其他设置不变,vo=gpu-next输出的颜色不一样么..? 颜色哪个好哪个坏还真说不清楚..准确就行.
另外但就这张图来说,violet的头发应该是偏金色而不是偏黄色的,可能第二张图确实好一点? 当然这是纯主观扯淡了...

[dyphire]

用纯净模式测试了一下色调映射的表现

mpv --no-config --vo=gpu-next
https://cdn.jsdelivr.net/gh/dyphire/PicGo/img/2021/11/05/Snipaste_2021-11-05_13-08-59.png
mpv --no-config --vo=gpu
https://cdn.jsdelivr.net/gh/dyphire/PicGo/img/2021/11/05/Snipaste_2021-11-05_13-09-36.png
--madvr121b测试版
https://cdn.jsdelivr.net/gh/dyphire/PicGo/img/2021/11/05/Snipaste_2021-11-05_13-15-07.png

gpu-next的色调映射下的画面表现不太对，整体偏绿。gpu的色调映射也偏绿但比gpu-next要好的多。madvr表现仅供参考

顺便上面字幕过曝问题和我hdr映射配置组中的--target-peak=100有关，也就证实了我的猜测，gpu-next把字幕也当hdr处理了，而gpu或madvr等都不会如此处理，可以认为这是错误行为。实际在纯净模式测试中gpu-next的hdr下字幕表现依然存在问题

[yeezylife]

gpu-next颜色偏绿有(低消耗的)解决方案么..
用 target-lut= 或者 icc-profile=<file> 调色? 可是我的显示器没校准啊
另外lut和icc调色有区别么 都是调色..
还是直接等修复..

[dyphire]

gpu-next颜色偏绿有(低消耗的)解决方案么.. 用 target-lut= 或者 icc-profile=<file> 调色? 可是我的显示器没校准啊 另外lut和icc调色有区别么 都是调色.. 还是直接等修复..

经测试icc-profile=<file>使用icc配置文件无法改善gpu-next的偏色问题，既定的色彩映射基准或者是bug？等修复吧

使用lut文件进行色彩管理应该可以解决，不过我也没有lut校色文件，无法测试

[yeezylife]

builtin-scalers = no
tscale = quadric
tscale-clamp = 0
之后看得出interpolation生效了,横向移动的时候似乎比之前模糊(只是似乎) 但起码生效了..

[dyphire]

vo=gpu-next最小化卡死问题我复现了，后台播放时cpu占用会飙满。应该是个bug了
vo=gpu最小化后台播放时gpu的占用会较高，不会出现卡死情况

使用以下条件配置组可以解决

[minimized]
profile-desc=最小化时暂停
profile-cond=window_minimized
profile-restore=copy-equal
pause

[hooke007]

你说的这两情况我都没有，，但是后台播放导致我内存泄漏了。。。

[natural-harmonia-gropius]

你说的这两情况我都没有，，但是后台播放导致我内存泄漏了。。。

app:calldraw -> mem -> cpu -> gpu反正mpv的什么地方死循环了

[hooke007]

这里也用a卡测了测，一切正常（没有泄露，没有崩溃，没有占用异常

[natural-harmonia-gropius]

另外有没有好用的lut，我只能找到log to *的lut

[hooke007]

我玩的一些也只是 http://bbs.photops.com/ 上扒下来的一些黄油相机lut

[hooke007]

libplacebo 的默认dither算法是bluenoise（重写改良的fruit？），依然由mpv默认的fruit选项触发，未测试效果

[dyphire]

不知道bluenoise和ordered的性能差别和表现如何，一直在用ordered，不确定gpu-next下是不是应该改回默认

[hooke007]

libplacebo 当前的最高质量就是blue，当然性能要求也是 blue＞ordered

[dyphire]

gpu-next似乎尚未支持dither，现在还不是谈具体表现和性能的好时机

[hooke007]

我只是抄了haasn的原话注释（

[hooke007]

基本上就是fruit的风格和性能。。。没有别的特殊的

[yeezylife]

好像是dither-depth无效 你提完issue之后haasn昨天修复了 等会有人发release了我再测一测
zhongfly今天刚好没有更新,sad..

[dyphire]

zhongfly那个是每天20点（北京时间）自动编译发布的，编译一般要30-60分钟左右。你也可以fork下自编译

[zhongfly]

好像是dither-depth无效 你提完issue之后haasn昨天修复了 等会有人发release了我再测一测 zhongfly今天刚好没有更新,sad..

由于编译比较费时，我也不可能每个commit都自动编译的（虽然是可以做到的），因为很可能出现旧的comiit没编译完，新的commit就来了。再说也不是什么很紧要的事

[yeezylife]

是我自己没注意时区...感谢!

[zhongfly]

是我自己没注意时区...感谢!

考虑到有人需要，增加了每小时检查mpv更新，如果mpv更新了，就会运行编译。但这些编译结果是不会发布到release中的，有需要的直接去https://github.com/zhongfly/mpv-build/actions 里点击运行成功的编译、下载Artifacts内的文件。

[dyphire]

mpv-player/mpv#9421
vo_gpu_next的新选项--target-colorspace-hint 似乎为mpv实现了直通hdr

[yeezylife]

截图更新了..要我看效果差不多啊..

[dyphire]

照上面说的话，bluenoise和fruit的效果和性能都差不多，都是通过蓝噪实现的。vo=gpu-next截图的话我这边是screenshot window会失败，其他三种能截取，画面正不正常另说。

[natural-harmonia-gropius]

都是为了拟似蓝噪声自然不会有很大区别, blue noise对极亮和极暗处的干扰要小那么一个点（真
左next 右gpu，这图浏览器看可能糊的，建议另存本地看

[dyphire]

它工作机制默认是自动模式，shift+c控制开关，有个判定时间（20秒）以防误裁切，所以不会立即生效。可以在脚本或同名conf自由配置选项。比起autocrop.lua，它能正确在黑边和无黑边画面中正常切换，解决了autocrop.lua裁切后无法检测后续无黑边画面自动撤销滤镜的bug。效果很像madvr的自动切黑边功能

[dyphire]

不过比起madvr的自动切黑边功能dynamic-crop.lua目前依然存在bug场景，比如EVA Q 3.0+1.1开头那段黑边变化场景中在破的标题画面闪现时不能及时检测撤销滤镜导致过度裁切，除了这一处画面，其他地方表现完美。魔法记录第二季第1话开头几分钟画面会错误裁切使画面下移（后续无黑边画面依然能正确识别并撤销滤镜），这个有点类似你mpv那个issue的触发场景了。

基于以上问题我暂时把dynamic-crop.lua设为模式3了，手动启用自动检测裁切功能，尽可能避免错误行为

[natural-harmonia-gropius]

切的过多能理解，就是窗口大小变化还有滤镜导致的格式转换有点卡

[dyphire]

确实，还有hdr下这滤镜尽量不能用，会很卡（

[natural-harmonia-gropius]

detect不参与渲染就没问题了，但估计mpv那边不会实现这种麻烦功能

[yeezylife]

我在那个issue里补充了一下vo=gpu-next的性能问题,haasn好像只管写没管测试..
昨天说完他自己测了下发现部分shaders(比如fsrcnnx)慢很多,还没找到原因

[dyphire]

最近测试了下opengl的api，vo=gpu-next在此模式下不会出现该问题。所以应该的确是win+nvdia的gtx1060的vulkan驱动问题了，只能等d3d11的api实现或者升级显卡了（

[dyphire]

更新：最新版本的mpv编译下使用vulkan已经不会再复现此问题。

着色器组合下全屏假死依然存在，切换vulkan-swap-mode参数未能改善
更正：无需全屏，vulkan下只要放大窗口至触发预升频和后处理类着色器组合便会触发假死状态；opengl同配置下不会进入假死状态，但会持续掉帧，各项占用并不高，切换解码方式无法解决，掉帧率有区别

[dyphire]

假死原因找到了，是测试中mpv进程未彻底结束导致的多个进程后台同时运行产生的内存溢出。在mpv.net中限制单进程后测试不会复现，工作正常。mpv可以限制单进程吗？

[hooke007]

mpv-player/mpv#8742 (comment)
mpv-player/mpv#3811

[natural-harmonia-gropius]

我是无脑用709 2.4的icc，暗景没问题。auto icc是2.2的gamma，target-prim此时应该无效了。这部分很奇怪，2.4比2.2亮

[dyphire]

我现在也是无脑用709 2.4的icc，总算摆脱恼人的mpv的bt.1886曲线带来的一系列问题了。然而大多数人都没有这么做，target-prim配合target-peak值是更普遍的改善方法（本身就来自mpv的hdr issues讨论），vo=gpu-next真的砍掉target-peak参数对mpv用户绝对是个坏消息。

这部分很奇怪，2.4比2.2亮

同感，mpv的一些参数和实际表现有点反常识，内部工作机制成谜

[natural-harmonia-gropius]

我的理解是mpv用icc确定输出目标色彩空间，视频会被转换到这个目标，原本2.4gamma的内容转换到2.2上颜色就会更暗。mpv tonemapping函数的目标是gamma2.2，但是被tag为bt1886，所以套了2.2的icc会把暗处变暗

[natural-harmonia-gropius]

改target-prim和peak只能算是一种trick，什么时候能这样才算有了正解

[dyphire]

haasn在mpv-player/mpv#9566 (comment) 里提到target-peak参数确实被libplacebo弃用了，他将增加新参数target-scale实现类似功能，并准备在近期调整libplacebo的HDR色调映射相关内容

[hooke007]

从报错看只是纯粹的ffmpeg解码的bug

[dyphire]

看上去是ffmpeg解码的bug，不过为什么vo=gpu下不会触发才是重点（
要不是vo=gpu-next下会触发都不知道有这bug

[natural-harmonia-gropius]

我next放这3.333也没问题。。。

[dyphire]

是--no-config --vo=gpu-next下测试的吗？我主配置中使用gpu-next也不会触发此类bug，怀疑是音频相关参数修复了
只有--no-config --vo=gpu-next测试模式中会触发，而--no-config --vo=gpu正常

[natural-harmonia-gropius]

mpv-player/mpv@7356ee5
试试看这个commit之前的版本

[hooke007]

#58 (comment)
gpu-next的d3d11后端初步实现，理论性能第一，还没做其它测试。
需要关闭flip以提升理论性能的问题似乎并不是我个人的问题，可能广泛存在n卡驱动上

[hooke007]

前面说的不是色调映射的问题吗，跟后端又没关系。。。

[yeezylife]

我是死马当活马医反正新版本试一试,还是绿.
问题是Natural-Harmonia-Gropius提的这个issue都已经关闭了.
而且在hassn的回复看来他认为已经修复了,那岂不是一直都发绿了

The above commit was a fix for the YCbCr decoding matrix being slightly off (resulting in green tint). The other issue you mentioned (NaN in desaturation mode) was also already fixed.

[dyphire]

在issue里报告这一问题让hassn知道预定修复未起作用，然后建议重新打开该issue追踪

[dyphire]

测试编译了下最新版的mpv https://github.com/dyphire/mpv-winbuild/releases

新版的--vo=gpu-next下字幕渲染确实可以和着色器一起正常工作了，不再产生伪影
然而hdr下的字幕渲染问题仍未解决
--vo=gpu-next

--vo=gpu --blend-subtitles=no

应该是--blend-subtitles=yes的默认渲染行为的锅，在未实现--blend-subtitles=no的字幕渲染方式前只怕无法解决。
edit：确实是--blend-subtitles=yes下的hdr字幕渲染问题，可在--vo=gpu下复现
--vo=gpu --blend-subtitles=yes

[yeezylife]

blend-subtitles=no 比较好用! =yes的时候我截图 截取当前源画面 会带外挂字幕...每次截图要关字幕

[dyphire]

不是好不好用，是hdr和dovi视频下只有--blend-subtitles=no能正确渲染字幕，而--vo=gpu-next尚未实现这一渲染方式

[dyphire]

似乎不仅仅是--blend-subtitles=yes的锅，经测试发现还和--video-sync=display-xxxx有关，当--video-sync=audio时字幕在hdr下使用--blend-subtitles=yes时渲染正常，当--video-sync=display-xxxx时，就会出现以上情况。很迷惑的表现

[dyphire]

此问题已由mpv最新的提交修复：mpv-player/mpv@626fa50
测试构建版本：https://github.com/dyphire/mpv-winbuild/releases/tag/mpv_own-2022-02-25

[yeezylife]

那挺好啊 我目前用的shinco发布的2月13号的版本;等他下次更新我看看

[yeezylife]

我用的27号发布的版本,截图还是有文字,只不过文字的大小和位置都不正常,
另外正常打开播放的时候SRT字幕位置太低,只能显示出一小半

[zhongfly]

mpv-player/mpv#9923

[yeezylife]

嗯,这个issue我看到了. 不过SRT默认位置的问题好像没看到.
看这字幕的位置好像是把SRT往黑边上输出了...

[dyphire]

再开个新issue吧

[yeezylife]

有人开了#9928

[hingbong]

我用的mpv.net
别的软件截图

而内置的截图

配置：
mpv.txt

[zhongfly]

gpu-next使用glsl的问题应该已经解决了，mpv-player/mpv#10246
之前使用像AMD-FSR或者SSimDownscaler这些都会出现错误而无法启用，现在libplacebo应该解决了bug
包含修复的最新构建 https://github.com/zhongfly/mpv-winbuild/actions/runs/3411475228

[hooke007]

我说的问题不是这个问题 mpv-player/mpv#9505

[dyphire]

才注意到此问题 bloc97/Anime4K#144 (comment) ，不怎么使用 Anime4K 都没发现它在 gpu-next 上无法生效。

Edit: //!SAVE MAIN 这个钩子的兼容性问题我认为应该报告给 mpv/libplacebo 等待修复，你虽然在上面的 issue 中提到了该评论，但我怀疑 hassn 没有注意到它，这和才修复的此问题 mpv-player/mpv#10246 属于同类的 hook 兼容性错误，和暂停时会出现锯齿不是同一个问题

Edit: 没注意到 libplacebo 上游最近的提交已修复此问题（

gpu-next 的特异点还是太多了，甚至无法知道哪些着色器生效哪些着色器无效，需要一一对比测试 gpu-next 和 gpu 下的不同才能确认

[yeezylife]

SSimDownscaler应该能生效把，我之前测试过SSimDownscaler的oversharp参数，调高了画面就变锐化了(应该是有效果)，然后按shift+i > 2 也能看到SSimDownscaler的信息呀
不过我一直用的是软解

[dyphire]

顺便 gpu-next 还有一个 d3d11 下某些 RGB 格式会在 deband 时导致绿色色调的问题：mpv-player/mpv#10239

属于很严重的 bug 了，但尚无修复计划

[dyphire]

已由上游此提交 haasn/libplacebo@7ead30d 修复

[dyphire]

突然有个疑惑想问，vo=gpu-next下如何查看并确认mpv输出位深？
vo=gpu下可以在日志中查找Reported display depth:相关记录确认，gpu-next我似乎没看到任何depth相关的记录，无法确认是否输出10bit

Edit: 我大概在--vo=gpu-next的日志中找到了输出位深的相关记录

[   0.641][v][vo/gpu-next/d3d11] Queried output: \\.\DISPLAY2, 3840x2160 @ 10 bits, colorspace: RGB_FULL_G22_NONE_P709 (0)
[   0.641][v][vo/gpu-next/d3d11] Selected swapchain format R10G10B10A2_UNORM (24), attempting to utilize it.
[   0.643][v][vo/gpu-next/d3d11] Selected swapchain color space RGB_FULL_G22_NONE_P709 (0), attempting to utilize it.
[   0.643][v][vo/gpu-next/d3d11] Swapchain capabilities for color space RGB_FULL_G22_NONE_P709 (0): normal: yes, overlay: no
[   0.643][v][vo/gpu-next/d3d11] Swapchain successfully configured to color space RGB_FULL_G22_NONE_P709 (0)!
[   0.643][v][vo/gpu-next/d3d11] Using flip-model presentation
...
[   0.644][v][vo/gpu-next/libplacebo] Initial swap chain configuration: format: R10G10B10A2_UNORM, color space: RGB_FULL_G22_NONE_P709.

可以看到--vo=gpu-next和--gpu-api=d3d11下好像也可以自动选择10bit输出
不过无论--vo=gpu还是--vo=gpu-next下将mpv切换到其他显示器时都不会自动切换输出位深，它只在第一次打开时所在的显示器上设置一次，还不够完美

[hooke007]

始终输出10bit

[dyphire]

这里存在很大的问题，vo=gpu-next的行为完全违背了--dither-depth选项的描述，甚至即使我显式指定dither-depth=8时vo=gpu-next依然输出10bit，这绝不是像haasn说的那样符合预期。

vo=gpu-next始终输出10bit在8bit面板下将交由显示器抖动到8bit，这或许不会出太大问题。但在12bit面板下将致使输出精度不够，因为它无视--dither-depth选项的参数

[CoelacanthusHex]

这里存在很大的问题，vo=gpu-next的行为完全违背了--dither-depth选项的描述，甚至即使我显式指定dither-depth=8时vo=gpu-next依然输出10bit，这绝不是像haasn说的那样符合预期。

vo=gpu-next始终输出10bit在8bit面板下将交由显示器抖动到8bit，这或许不会出太大问题。但在12bit面板下将致使输出精度不够，因为它无视--dither-depth选项的参数

建议开一个 Issue 指出这个问题

[dyphire]

已经提了：mpv-player/mpv#10881 (comment)

Edit: 上面的理解有问题，以上的相关日志只是--vo=gpu-next下的内部纹理处理方式，其最终的抖动输出位深需要在日志中查找pl_shader_dither以输出的色阶来确认。

[hooke007]

还是有问题，这是不是表示在最终输出前把所有着色器的计算精度都压缩在10bit，只靠最终的抖动去匹配？多开几个着色器看一看
（当下来讲还是够用的，至少还不存在12bit rgb的常规显示器）

edit: 简单用自适应锐化测了一下发现不存在问题

[shikkoku]

mpv-player/mpv#8554

到底最终windows上的vulkan api能否实现10bit输出/指定色深输出？

[hooke007]

上面不是已经告诉你可以了吗，你指定的这个问题与next无关

[shikkoku]

上面不是已经告诉你可以了吗，你指定的这个问题与next无关

因为用d3d11 api加--target-colorspace-hint不能自动切换HDR模式有点麻烦，但是以往的讨论都说Windows下只有d3d11才能正确输出10bit。实际使用中，vulkan api的hdr直通色彩有过曝/明显偏色。d3d11 api下手动按win+alt+b切换就不那么明显。

[hooke007]

gpuvk不能10bit是抖动的问题，不是输出的问题。另外如果你gpunext的hdr输出如果有问题应该像官方报告，我没在issue tracker上看到有人反馈过这个问题存在

[shikkoku]

gpuvk不能10bit是抖动的问题，不是输出的问题。另外如果你gpunext的hdr输出如果有问题应该像官方报告，我没在issue tracker上看到有人反馈过这个问题存在

我不是很确定是否显示器内置的曲线太渣（

另外使用gpu-context = d3d11和d3d11-flip = no “直通”播放HDR视频时，出现大量报错。

[vo/gpu-next/libplacebo] New swap chain configuration received from hint: format: R10G10B10A2_UNORM, color space: RGB_FULL_G2084_NONE_P2020.
[vo/gpu-next/libplacebo] New swap chain configuration was deemed not supported: format: supported, color space: unsupported. Failling back to 8bit RGB.

[hooke007]

报错应向官方反馈

[hooke007]

tone-mapping=st2094-40 正式上线了，默参在整体高亮画面下，相比bt.2390蒙上一层雾的感觉要弱很多。
我主观上反倒喜欢st2094-10（亮度没那么刺激

[hooke007]

--target-peak 用旧标准值 100 可以简单获得一个比较满意的效果

[dyphire]

Dolby Vision, Version 1.0, dvhe.04.06, BL+EL+RPU LG Dolby Trailer 4K Demo.ts jxl.zip 这个彻底坏了

无法复现你截图的状况，不过我确实发现了该视频下的行为区别

UWP	bt.2446a	bt.2446a(libdovi)

可以看到应用libdovi后的映射画面已经明显偏离了杜比官方的uwp dovi插件呈现的画面，反而是之前的画面效果相对接近

[hooke007]

这个视频target-peak要给到10000才算正常。。。太离谱了

[Czerror]

https://github.com/zhongfly/mpv-winbuild/releases/tag/2023-02-23

今天的打包版好像修复了vo_gpu_next: fix color space hint with target peak override

[hooke007]

这修复的是另外的问题。上边说的问题是这个 mpv-player/mpv#11350

[dyphire]

经过在 mpv-player/mpv#9800 中的持续性探讨和调整优化，libplacebo 已基本实现了--vo=gpu-next的动态亮度元数据/动态峰值检测（hdr-compute-peak）下较为合适的映射效果（tone-mapping=auto/spline），可以很好地处理高平均亮度场景，又不像bt.2446a一样一味抑制高光调暗画面，这是在实现直方图映射之前能得到的最好映射效果了。直方图测量已在分支实现，对应的映射处理方式还在开发中。

如果更偏好保留高光对比度的话可以使用--tone-mapping=spline,--tone-mapping-param=1.0。代价是会相应损失阴影处的细节

[dyphire]

发现重构后的峰值检测存在很大的问题，见：mpv-player/mpv#11406, mpv-player/mpv#11412

[dyphire]

峰值检测的相关问题已被修复

[dyphire]

gpu-next有个问题不知道你们能不能复现：如果通过条件配置来切换解码方式，那么在播放时切换或直接打开相应文件时画面会花屏（前提是之前有播放进度

最早是此提交 dyphire/mpv-config@8825033 时期发现的，做了临时处理
最近我又添加了8k条件配置组切换解码方式 dyphire/mpv-config@448e766, 让我又想起了这个bug，测试了下依然存在
因为gpu下不会触发，所以不确定是否为驱动问题
简单的测试条件配置：

[test]
profile-cond=p["video-params/w"] > 3000
profile-restore=copy
hwdec=auto   #or hwdec=no

故障画面

https://user-images.githubusercontent.com/61936050/229395964-98648671-9989-4f62-abe1-71fd22bbb70e.png

edit: 花屏画面有点阴间，隐藏了

[hooke007]

根据报错来看ffmpeg的问题

[dyphire]

根据报错来看ffmpeg的问题

嗯，ffmpeg有报错，可以复现的话大概率是它的锅。又是一个奇怪的vo_gpu下不会触发的bug

我这vulkan和nvdec切换好像没问题

我测试vulkan和d3d11都会触发，不过要来回多播放切换几次，有时候不是百分百触发

[dyphire]

我测试了下vd-lavc-software-fallback=6或10，没有改善。有时候是会避免报错，但还是会触发

[dyphire]

提交 haasn/libplacebo@9faea1b 对此问题有所帮助，得到了很大改善，没那么容易触发花屏了，看来还是和 libplacebo 相关

[dyphire]

mpv-player/mpv#12195 此PR导致了--vo=gpu-next下严重的bug，我这边测试播放中使用命令对glsl-shaders进行各种更改操作都不再实际生效。目前还没测试到底影响了多少options，这种重大更改竟然没有进行充足的调测（

[hooke007]

mpv最近的大大小小pr基本都是没严谨测试直接过的，没领导成员把关之后是挺混乱的各玩各的。。。
0.36这个节点目测一堆抱怨字幕逻辑的，坑惨一票linux了，这么奇葩的改变做进大节点真的不应该

[dyphire]

还有今天这个pr（ mpv-player/mpv#12199 ）也是，险些加了个新坑
libplacebo这个bug太恶性了，options的现有工作机制被破坏了
测试构建：https://github.com/dyphire/mpv-winbuild/actions/runs/5912098890 ，也可以等明天shinchiro的构建再测试

[dyphire]

好像只影响glsl-shaders

我对此表示怀疑，但也懒得进一步测试，已经回退包含pr mpv-player/mpv#12199 的旧版本了

[dyphire]

刚刚随便测了个选项就出现了问题，通过命令循环切换gamut-mapping-mode值，auto的画面该pr前后完全变了

libplacebo-opts 之前	libplacebo-opts 之后

gamut-mapping-mode=auto默认对应的是一个新perceptual色域映射，而现在通过命令循环切换后却变成了linear色域映射模式，也就是选项未能复位。xd
还是那句话，还没测试到底影响了多少options，工作机制已经被破坏

[dyphire]

gamut-mapping-mode的问题也修了，剩下的options测试随缘吧

[eko5624]

我有个关于gpu-next(libplacebo)渲染器设置的疑问。比如普通vo=gpu默认scale算法是bilinear。那么gpu-next的默认scale算法是什么呢。因为我用的电脑性能不高，想更好更顺滑的使用gpu-next播dovi的片子，应该怎么设置来降低消耗呢。比如libplacebo的scale怎么设置呢？

[eko5624]

好吧~

[eko5624]

应该是opengl太拉吧，mac上用的gpu-api是opengl。问题是之前还能凑合着用，现在是几乎不能用的状态。

[hooke007]

next的og性能就没好用过，我那个issue还开着呢

[hooke007]

而且next和vo gpu一样用的是过时的cocoa

你看到的只是能看而已，始终实际是不受支持的状态。mac真没必要浪费时间折腾了，要么找人开发，要么bootcamp切换到windows

[nyfair]

mac的祖传opengl4.1都已经是13年前的东西早就不闻不问了，MoltenVK也只是个转译vulkan的玩具，苛求这种东西的性能没必要也没意义，要么换方案，要么换os