普通论坛用户
发表于 2024-6-17 14:50
zhguyu
发表于 2024-6-17 17:23
虽然不知道死机是怎么回事,但现在想要压av1建议尝试SVT-AV1,这两年发展得很好,画质不输libaom,与此同时速度快了很多。对于4k视频来说av1应该不会比hevc有明显优势(都使用软编码的情况下),所以如果你已经习惯了用hevc那就继续用呗。av1有优势的场景是高噪点的视频和极低码率,如果码率都到18000kbps了那说实话不管用啥应该都看不出区别。
posthoc
发表于 2024-6-17 17:51
本帖最后由 posthoc 于 2024-6-17 17:56 编辑
效率是空间效率还是时间效率?我的体验是h265使用x265软件编码同质量下比硬件编码体积明显更小,就是速度慢不少。
普通论坛用户
发表于 2024-6-17 18:32
普通论坛用户
发表于 2024-6-17 18:33
普通论坛用户
发表于 2024-6-17 18:37
zhguyu
发表于 2024-6-17 18:46
普通论坛用户 发表于 2024-6-17 18:37
软解太慢了
有3T多的视频,数量成千上万,如果都用软解那得编码到天荒地老
无论是libaom还是svtav1都是软件编码,只是10代i5有点不够用了。你需要做的是把这3T的视频进行筛选,如果原本就是hevc/av1编码的那不建议再次压制,只会带来细节损失。如果是h264的那就可以再压一遍以节省体积。
macos
发表于 2024-6-17 18:57
普通论坛用户
发表于 2024-6-17 19:01
qazesz
发表于 2024-6-17 20:00
既然这么大量视频压制买块Intel显卡不是更好
蒜灵
发表于 2024-6-17 20:08
qazesz 发表于 2024-6-17 20:00
既然这么大量视频压制买块Intel显卡不是更好
很明显楼主就是要CPU压,而不是显卡
蒜灵
发表于 2024-6-17 20:09
CPU软压av1有个优势就是速度快,不比显卡慢太多,不像x265速度一坨屎
蒜灵
发表于 2024-6-17 20:09
本帖最后由 蒜灵 于 2024-6-17 20:12 编辑
风怒编辑
循此苦旅
发表于 2024-6-17 20:50
普通论坛用户 发表于 2024-6-17 18:33
查阅了https://trac.ffmpeg.org/wiki/Encode/AV1 ,尝试使用命令"ffmpeg -help encoder=libsvtav1",却收 ...
先确认下压出来的质量吧,两个编码器的参数不统一。
循此苦旅
发表于 2024-6-17 20:58
蒜灵 发表于 2024-6-17 20:09
CPU软压av1有个优势就是速度快,不比显卡慢太多,不像x265速度一坨屎
你用的快速编码参数吧,压出来就是一坨,不如h256硬编码。
zhguyu
发表于 2024-6-17 20:59
蒜灵 发表于 2024-6-17 20:09
CPU软压av1有个优势就是速度快,不比显卡慢太多,不像x265速度一坨屎
x265花时间调校一下的话速度也是可以的,但是没法做到开箱即用这点对新人很不友好。而且目前来看无论SVT-AV1还是vvenc相比于x265在速度和质量上都是完全上位替代,就等硬解普及了。
qazesz
发表于 2024-6-17 21:46
蒜灵 发表于 2024-6-17 20:08
很明显楼主就是要CPU压,而不是显卡
楼主明明说了想用硬件加速,只是30显卡不支持
普通论坛用户
发表于 2024-6-18 17:26
zhguyu
发表于 2024-6-19 07:37
呃,rav1e还是算了吧,前几年雄心勃勃地说要做新时代的x264,结果没过多久开发者就失去兴趣了,现在基本已经是个dead project了。
我av1用的不多,没法给出建议。说真的,字幕组用av1传动画且不论,我自己对于用av1以归档为目的压视频是持保留态度的,一是在高码率下不比hevc有优势,二是未来的支持存疑,毕竟vvc已经出了。我能想到的av1的优势,一是高噪点的保留,得益于film grain synthesis,二是速度比x265快?大概吧。
不过我倒是可以说说如果用x265的话大概怎样会得到一个兼顾速度与质量的结果。
首先是--crf 18 --preset slower
激进点说,对于x265来说任何低于slower的preset都是没有意义的,因为从slower开始才会启用所有的hevc特性(的快速版本),比如rect和amp。如果对于楼主来说slower就已经慢到无法接受了的话,那确实可以直接放弃hevc这个选项了。
在此基础上,--ctu 32 --rskip 2 --rskip-edge-threshold 2
这三条参数加在一起大概能在几乎不损失画质的前提下让速度翻一倍,虽然说--ctu 32可能对于4k视频来说会一定程度上降低压缩率,但是用它主要是为了规避x265的一个bug(https://bitbucket.org/multicoreware/x265_git/issues/561/rskip-2-coupled-with-limit-tu-0-and-ctu-64)。具体有多大的影响取决于视频的内容,可以通过--csv-log-level 2来看到每帧里CTU尺寸的分布,如果64x64的CTU比例很高的话,那--ctu 32就会带来明显的压缩率损失。
除此之外,像--no-sao或者--selective-sao 2之类的参数就看个人喜好了。
我的建议是,如果楼主试了上面的参数组合,觉得速度可以接受的话,那我还是建议用x265。如果接受不了的话那av1就是比较好的选择。
顺带一提,如果是动画的话,那--aq-mode 4和--tskip --tskip-fast的组合能带来非常好的效果,能大幅提高压缩率的同时保持画质。说到底,动画几乎可以算是最好压的视频种类之一了。x265最不擅长的是高噪点视频,想要压出好的效果简直是噩梦。
蒜灵
发表于 2024-6-19 13:27
有没有最新的av1和x265压制质量和性能对比?
普通论坛用户
发表于 2024-6-22 17:37
烟火FY烟火
发表于 2024-6-23 13:22
普通论坛用户 发表于 2024-6-22 17:37
昨天光顾着av1an,踩了一些坑,最后发觉ab-av1更省事
ab-av1评估工具根据VMAF分数提供指定的画质分数进行 ...
这个软件是不是跟封装的格式有关 同样的参数 MP4分别转成mp4和mkvvmaf一个90多 一个70多
普通论坛用户
发表于 2024-6-23 14:35
烟火FY烟火
发表于 2024-6-24 13:32
本帖最后由 烟火FY烟火 于 2024-6-24 13:33 编辑
普通论坛用户 发表于 2024-6-23 14:35
qwen2:
VMAF(Video Multimethod Assessment Fusion)是一个用于评估视频质量的工具,它考虑了多种因素 ...
试了一下 应该是封装容器的差别 实际画质没有降低 我直接用这个命令压hevc vmaf也有93+ -c:v libx265-crf 25 -c:a copy 具体参数就懒得折腾了
xy2401
发表于 2024-6-24 14:28
mark一下。很少看到讨论,我之前也是翻 gitlab 的文档推荐命令自己写。
svt-av1 针对图片编码有个bug/feature ?不能奇数分辨率 我还写了一个脚本avif转换失败就 设置少一个像素重新转换。
普通论坛用户
发表于 2024-6-24 21:41
xy2401
发表于 2024-6-25 08:23
普通论坛用户 发表于 2024-6-24 21:41
对于图片编码不太了解,个人只用于视频编码的转换
有奇怪BUG,应该向svt-av1作者反馈问题 ...
社区有很多讨论了 可能 intel 认为这个是 特性
奇数图像尺寸和 svt-av1 编码器 #544
https://github.com/AOMediaCodec/libavif/issues/544
elxy
发表于 2024-6-26 09:46
烟火FY烟火 发表于 2024-6-23 13:22
这个软件是不是跟封装的格式有关 同样的参数 MP4分别转成mp4和mkvvmaf一个90多 一个70多 ...
可能和编码后各帧时间戳有关,没对齐的话,计算的VMAF就不准确。
—— 来自 鹅球 v3.0.86-alpha
elxy
发表于 2024-6-26 09:48
普通论坛用户 发表于 2024-6-24 21:41
对于图片编码不太了解,个人只用于视频编码的转换
有奇怪BUG,应该向svt-av1作者反馈问题 ...
不只是svt-av1,其他编码器比如x264、x265都不支持奇数的分辨率。
—— 来自 鹅球 v3.0.86-alpha
xy2401
发表于 2024-6-26 10:10
elxy 发表于 2024-6-26 09:48
不只是svt-av1,其他编码器比如x264、x265都不支持奇数的分辨率。
—— 来自 鹅球 v3.0.86-alpha ...
但是av1其他的两个编码器都支持。
今天nga也看到一个av1交流贴
[大姐姐保存指南3rd]是拥抱AV1的时候了 https://bbs.nga.cn/read.php?tid=39249771
风夏
发表于 2024-6-28 20:04
咨询一下,用nvenc压比svt差在哪里?
好像你们都不用显卡?
—— 来自 HUAWEI VOG-AL00, Android 10上的 S1Next-鹅版 v3.0.0.81-alpha
uneedme
发表于 2024-6-28 23:40
没试下 vvc?
zhguyu
发表于 2024-6-29 01:53
uneedme 发表于 2024-6-28 23:40
没试下 vvc?
生产环境还是用比较成熟稳定的方案比较好。比如说vvc,目前最好(且唯一)的开源编码器是vvenc,而且在可预见的未来它还会继续迭代优化。如果现在就用vvc压制的话,那过个几年看着用过时版本压制出的视频极大概率会后悔的。
普通论坛用户
发表于 2024-7-1 13:56
普通论坛用户
发表于 2024-7-1 14:14
uneedme
发表于 2024-7-1 18:58
普通论坛用户 发表于 2024-7-1 14:14
由于专利许可,VVC注定很难受到欢迎,当前免版税也就AV1,VP9免费用……(很多消费者产品不支持VVC解码器 ...
普通用户 和版税还没什么关系吧?
x264就是山寨破解版的h264 hevc就是民间编译版的h265 vvc也会是民间编译版的
vvc如果itvc承认了 那就是h266 硬件都会支持的
总之 版权问题 和 民间使用 基本没什么交集
Jet.Black
发表于 2024-7-1 19:57
本帖最后由 Jet.Black 于 2024-7-1 19:59 编辑
uneedme 发表于 2024-7-1 18:58
普通用户 和版税还没什么关系吧?
x264就是山寨破解版的h264 hevc就是民间编译版的h265 vvc也会是民间编 ...
H264,H265是标准并不是软件,不存在破解一说,
专利也是公共领域,并不存在破解。
X264,X265只是符合标准的一种编码实现。
开源编码器X264,X265基本合法,
但是用户将其用于自己的商业产品,需要自行解决专利问题。
zhguyu
发表于 2024-7-1 20:16
uneedme 发表于 2024-7-1 18:58
普通用户 和版税还没什么关系吧?
x264就是山寨破解版的h264 hevc就是民间编译版的h265 vvc也会是民间编 ...
你在说什么……
x264和x265分别只是社区针对H.264/AVC和H.265/HEVC标准开发的开源编码器,专利费本身就不是针对软件开发者收的,而是针对使用者收的,只是这种使用者一般是指用于商业用途的大公司,和普通人没什么关系。换句话说如果你用HEVC编码的视频来提供网络传输服务/蓝光光盘,那无论你用什么编码器都得掏钱。
而且itvc又是什么鬼,开发视频编码标准的两个组织是ITU-T和ISO下属的MPEG,ITU-T发布的的H.266标准和ISO MPEG发布的VVC标准是等价的,只是由两个不同的组织分别发布而已。
—— 来自 S1Fun
zhguyu
发表于 2024-7-1 20:20
而且ITU-T和MPEG在开发编码标准的时候本身就会开发对应的开源参考编码器(参考模型,reference model),x265一开始就是从H.265/HEVC的参考模型HM里fork来的。而且x265也不是“民间”实现,开发它的MulticoreWare Inc.是一家正经的公司。
—— 来自 S1Fun
uneedme
发表于 2024-7-2 22:07
本帖最后由 uneedme 于 2024-7-2 22:34 编辑
zhguyu 发表于 2024-7-1 20:16
你在说什么……
x264和x265分别只是社区针对H.264/AVC和H.265/HEVC标准开发的开源编码器,专利费本身就不 ...
x264 变帧率 隔行扫描 自适应scale(那个功能的正式名字忘了......) 之类的 都没从标准h264上扒下来
很山寨很残的encoder(我记得扒过doom9的史记 是从苹果的h264编码扒出来的一部分源代码逐渐修改出来的)
itvc是写错了 我不记得视讯小组的缩写名字了
vvc我看到的是腾讯在主导吧?it-ut组织还没认可吧?好像连合作认定266标准都谈不上
it-ut完全可以自己出自己体系的h266 并行也说不上 只能说是同一代的编码器
是说 x265的名字让MulticoreWare Inc.给占了吗?所以只能改叫hevc? 我看doom9也是 x265 HEVC Encoder 板块 其实并没有刻意区隔hevc和x265的含义
doom9上并没有官方组织或者公司提供编码器的使用 都是民间编译版
没有商业组织去提供编译版 所以说民间编译版 没什么问题啊 难道你用的是自己源码编译的encoder?那你可厉害了
我回看了一下 自己说的 没什么大问题啊 还至于被专门指出更正?
不过严谨态度 值得称赞!