哪个更适合作为中间格式?测试以及横向对比
dwing吧
全部回复
仅看楼主
level 6
m88675 楼主
命令已经写好了,正在跑
截取了电影的3分钟片段作为测试
需要注意的是,这么玩硬盘写入量会很大,不建议模仿
2026年01月10日 16点01分 1
level 6
m88675 楼主
第一轮测试已经跑完,最先登场的是h264,参数是qp=0,无损
可以看到无损确实就是无损,第10遍,100遍,1000遍文件长度完全一致
但是验证哈希值的时候有区别,貌似应该是元数据不同导致的
使用winhex进行比对,发现除了文件头有几十个字节不一样外,后面的数据完全一致,所以就不用进行截图了
下一轮测试是qp=10的低损压缩,毕竟现在硬盘真的很贵,4k素材无损还是比较占用硬盘空间
2026年01月10日 16点01分 2
吧务
level 14
mkv的unique id默认随机的[汗]
2026年01月11日 00点01分 3
你们「中间格式」场景用的多吗?[疑问][疑问]
2026年01月11日 03点01分
@无名_啊 几乎不存在
2026年01月13日 05点01分
level 6
m88675 楼主
第二轮的参数是
ffmpeg.exe -i %a%.mkv -vcodec libx264 -preset ultrafast -qp 10 %b%.mkv
最终得到的文件大小是
码率分别是20.4m,16.4m,16.1m
压了10遍截图
压了100遍截图
压了1000遍截图
第10遍的时候,仍然在视觉无损的程度
第100遍其实已经没法看了
下一轮测试nvenc的效果,因为看过某个帖子的质量对比,nvenc高码率优势
2026年01月11日 07点01分 4
加上10bit试试,看看能改善多少
2026年01月12日 06点01分
level 6
m88675 楼主
第三轮的参数是
ffmpeg.exe -i %a%.mkv -vcodec h264_nvenc -preset p1 -qp 10 %b%.mkv
输出的文件大小分别是
码率分别是25.8m,25.3m,25.3m,明显比前面的高很多
压了10遍截图
压了100遍截图
压了1000遍截图
第10遍没有什么区别,依然保持视觉无损
100遍开始,除了出现雪花点外,并没有出现软件编码产生的拖泥带水马赛克现象
感觉是否是量化精度不够引起的
结论,硬件编码在高码率下好于软件编码
下一轮测试,设置444p10le是否能提升效果
2026年01月12日 07点01分 5
level 10
码率怼高就行了,其他不重要,中间格式嘛肯定越快越好
2026年01月12日 09点01分 6
说多了,并不是说码率够高就行,因为多年前我好像这样玩过,但是没有记录测试结果,模糊的记得即遍是设置qp=1比无损低一丝丝的参数,在多次编码后仍然会出现预料之外的瑕疵,但是现在还有prores格式,宣称是多次编码损失极小,后续我会测试这个格式的表现
2026年01月12日 09点01分
level 8
奇怪,我也用了你的「反复压缩多次」方法,试了试 pngquant 有损压缩 5 楼第一张图(转为 png),
结果发现,无论压多少次,都和首次一样,只压到 530 KB,SSIMULACRA2 画质评分 83,再也不变了。。
——————
● 命令:
for i in {1..5}; do
pngquant --speed 1 - < in.png > out.png
echo "第 $i 次有损压缩后:$(stat -f %z out.png) 字节,SSIM2 评分 $(ssimulacra2 src.png out.png)"
mv out.png in.png
done
——————
● 输出:
第 1 次有损压缩后:541972 字节,SSIM2 评分 82.75653731
第 2 次有损压缩后:541952 字节,SSIM2 评分 82.75653731
第 3 次有损压缩后:541952 字节,SSIM2 评分 82.75653731
第 4 次有损压缩后:541952 字节,SSIM2 评分 82.75653731
第 5 次有损压缩后:541952 字节,SSIM2 评分 82.75653731
——————
2026年01月12日 11点01分 7
不奇怪,有变化才奇怪了。png“有损压缩”实际是砍调色板,除了色彩会出现变化外,不会生成其他的artfact,因此就不会出现多次压缩的误差积累。看起来,pngquant的质量参数代表将调色板砍到一个特定数量,所以用同一个参数反复压缩时,理论上第一次就砍到位了(如果色彩的检测完全准确),后面多次生成的图像是完全不变的。
2026年01月12日 14点01分
@gartour 是这样,我在观看压到1000遍的视频时,关键帧明显比后面的帧要清晰,越往后越糊直到下一个关键帧。放出的三张对比截图是一个gop的最后几帧画面,也就是接近最不清楚的画面。所以后面测试一下仅I帧编码的效果
2026年01月12日 14点01分
@gartour 但是当你的微信图转发次数多会变绿的问题其实就是yuv→rgb→yuv不停的转换,即便原图是无损的,也避免不了这个过程中的误差积累
2026年01月12日 14点01分
@m88675
2026年01月12日 19点01分
吧务
level 14
x264有quantization deadzone
2026年01月13日 05点01分 8
level 6
m88675 楼主
4:4:4,10bit速度比较慢,晚上等了好久都没结束,速度只有120fps
不做统计了,全部试完后会放链接给大家看
先说结论
压了10遍
压了100遍
压了1000遍
可以看出,10bit会明显好于8bit的效果,同时文件体积也更大
但是100遍后仍然会有颜色失真以及雪花点的出现
另外就是关于即使设置qp=1比无损低一丝丝的参数,多次压缩到一定次数也会出现白色雪花点,就不继续测试了
从前面三种情况发现,关键帧总是比后面的帧要清晰,越往后越糊,直到下一个关键帧
下一轮测试仅i帧编码的情况
2026年01月13日 10点01分 9
和我猜测一样,所以上面建议你试试10bit。 h264在8bit下的损失比较大。
2026年01月15日 08点01分
吧务
level 14
generational loss表现最好的是jpegxs(libsvtjpegxs)
2026年01月13日 17点01分 10
level 6
m88675 楼主
此帖翻篇!因为考虑到这样测试(哪种格式更低损)不是很严谨,后续的测试会重新开帖
忘记来回复最后一组对比测试了
当设置关键帧间隔为1时,多次压缩后质量就没有再下降
从第10遍之后,文件大小就没有再继续减小
已经对比画质无任何可见区别
也就是说,需要多次反复压缩的场合,只能用【仅I帧】的编码方式,否则每次运动估算都会导致误差累积,从而导致非预期的结果,所以prores格式也是仅i帧编码的
2026年01月16日 10点01分 11
level 8
中间格式吗?以前硬盘够用的时候我用的是avi无编码,后面有用过ProRes、DNxHR,再然后发现好像其实都够用,虽然说中间格式再编码可能会导致精度链等一系列问题,但是对我而言够用了,我的要求没那么极限,也没能力做那么极限,所以最后就用上了h264 rgb(
还有,中间格式我更喜欢用rgb而非yuv,以前捣鼓ae的时候full range和limited range折腾的头疼(他给的管道给第三方好像只输出limited range,设置了色彩空间可是输出依旧是limited,rgb就没这个问题)。
2026年04月04日 23点04分 14
1