cczzhh 发表于 2019-2-27 19:17
不太明白你的需求，意思是默认一开始的音量就全都小一些？那你把音箱的音量或者系统音量调小一些不就行了 ...
默认音量100是100%音量的意思，即没有对音频文件的音量做过改动，而不是说让你的系统音量达到100%最大。。设别的值相当于要经过内部音频处理滤镜去软件方式修改音频。我是觉得调音箱的音量最好。哦哦抱歉。。主要是这样，电脑这边箱子是无源的，没上后级，用hugo直接推。。而hugo每次开机都是固定音量，之前一直习惯改系统的音量来控制（比较懒），所以刚开始用mpv的时候每次开视频都会被音量吓一跳，您说调节音箱的方法是对的，这样可以保证音质尽可能少损失，我调整一下使用习惯去适应。正常。眼睛验货觉得没有提升后，就可以放心使用更省计算量的默认配置了，省心，省电。好的，那我就安心啦，感谢大佬解答~
本帖最后由 cczzhh 于 2019-2-28 15:57 编辑
渋谷凛 发表于 2019-2-27 20:12
哦哦抱歉。。主要是这样，电脑这边箱子是无源的，没上后级，用hugo直接推。。而hugo每次开机都是固定音量 ...
你会觉得mpv声音比别的大是因为WASAPI会跳过系统音量管理。所以推荐的做法是本身就把windows的系统音量开到100，再调节音响音量，这样不管是一般的软件还是用WASAPI的软件都不会差太多。
其实我觉得4K屏用NNEDI3拉伸应该还是有效果的，只是如果你没有仔细截同一帧反复切换图片对比不同算法的效果的话，确实不容易看出来就是了，还是需要一定的练习的（可以以bilinear和gpu-hq默认的spline36为基准，至少和bilinear会有很大的差别。必须全屏用windows的截图功能，而不能用mpv自带的截图）。但GPU占用过高确实说明980Ti也已经算力不足了，降级也是必须的。
可以尝试纯用RAVU：
cscale=haasnsoft
glsl-shaders-append="~~/shaders/ravu-r4-chroma-left-smoothtest1.hook"
glsl-shaders-append="~~/shaders/ravu-r4-rgb-smoothtest1.hook"https://github.com/bjin/mpv-prescalers/tree/master/test/vulkan/compute
或者主用ewa+SSSR：
cscale=haasnsoft
scale=ewa_lanczossharp
glsl-shaders-append="~~/shaders/ravu-r4-chroma-left-smoothtest1.hook"
glsl-shaders-append="~~/shaders/SSimSuperRes.glsl"
sigmoid-upscaling=no看具体占用和你自己能不能看出区别来。
请问在和其他占用资源的程序一起运行时，播放的声音出现刺啦刺啦的刺耳杂音，但是视频几乎没有掉帧，有方法解决吗？谢谢
michaelmai 发表于 2019-3-6 13:34
请问在和其他占用资源的程序一起运行时，播放的声音出现刺啦刺啦的刺耳杂音，但是视频几乎没有掉帧，有方法 ...
有。不要和其他占用资源的程序一起运行。（误）（试试把ao的设置删了用默认
你好，想请问一下，scripts和shaders为什么会出现有的起效有的无效的情况呢？
ontop-playback起效，autodeint和autoload无效
KrigBilateral而nnedi3-nns32-win8x4无效
路径就是按一楼说的设置的
我的天！原來 bjin 還有在維護 RAVU 啊！
本帖最后由 cczzhh 于 2019-3-12 10:37 编辑
巴洛克哥特 发表于 2019-3-11 21:32
你好，想请问一下，scripts和shaders为什么会出现有的起效有的无效的情况呢？
ontop-playback起效，autodei ...
文件不是手动复制粘贴的吧？上传一份用到这几个脚本和shader的log看看？（先把shaders_cache清空一下，方便在log里显示编译情况）
cczzhh 发表于 2018-10-18 14:37
拿楼上的测试图测了几个算法，madVR也一道测了些。
先说这个Bilateral implementation偏移的问题，还是感 ...
发现artoriuz的测试更新了chroma的测试，看起来KrigBilateral效果拔群啊。除了Krig，其他的chroma scaler的效果都几乎差不多。只有在第一个例子里，颜色错综复杂的情况下ravu-chroma才稍微好一点。 artoriuz.github.io/mpv_upscaling.html
我猜测Krig应该是算法实现上就对chroma位置的不同有兼容性，因为Bilateral算法是根据luma是不是接近来计算chroma采样时候的权值的，最后总会把chroma“强行”和luma对齐的。
另外一个有趣的地方是spline和lanczos普遍要比EWA系要好，所以可以认为cscale真的不是特别重要
wax 发表于 2019-3-12 14:56
发现artoriuz的测试更新了chroma的测试，看起来KrigBilateral效果拔群啊。除了Krig，其他的chroma scaler ...
这文不错，我加到1楼去吧。
cscale确实不重要，就我而言我无法通过截图分辨出不同算法间的差别，只能用工具在数值上看出差别（除了红黑，在那情况下确实bilateral更好）。
cczzhh 发表于 2019-3-12 15:41
这文不错，我加到1楼去吧。
cscale确实不重要，就我而言我无法通过截图分辨出不同算法间的差别，只能用 ...
这个表格里的各种量化指标，实际上差异很大，而且很可能和实际的效果出入很大。比如虽然FSRCNNX数值要比NGU好，但比较截图就能感觉到还是NGU看起来更舒适。madshi也说过他训练NGU的模型的时候并不是为了最大化某些数值，而是对比实际效果做了取舍。
关于列出来的各个指标之间的差异，PSNR和SSIM最基本，但对于一些细节的artifact也是很难检测出来的。后面有一些基于人类视觉的指标，有些结果差异很大是很正常的。如果比较在意线条的质量，可以看IW-SSIM，这个指标对锯齿的检测比较给力。