V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
wniming
V2EX  ›  FFmpeg

在几乎不损失画质的前提下,怎么用 ffmpeg 把 h.264 格式的视频转换成 h.265 格式的?

  •  
  •   wniming · 3 天前 · 3396 次点击

    linux 平台,显卡是 uhd770 ,渲染节点是 /dev/dri/renderD128 ,输入文件的路径是 /tmp/h264.mp4 ,输出文件路径是 /tmp/hevc.mp4 ,有大佬能给个能直接用的命令吗?

    转换的目的是为了减小文件的大小

    29 条回复    2025-01-03 11:12:00 +08:00
    msg7086
        1
    msg7086  
       3 天前   ❤️ 1
    就算不减小文件大小,也会损失少许画质。减小文件大小的话,损失得更多一些。
    如果用显卡编码的话,比纯软件编码损失会再更多一些。
    thunderw
        2
    thunderw  
       3 天前
    直接丢给 AI 就会给你个能用的命令,完全不损不大可能。
    wniming
        3
    wniming  
    OP
       3 天前
    @msg7086 我在 windows 平台下用 handbrake 的 qsv 硬件加速预设转码一个 11 分钟,h.264 格式,1080p ,大概 10 兆左右码率,823 兆大小的视频, 转换后的视频大小有 488 兆,码率大概 6 到 7 兆,同时播放 2 个视频对比看不出明显的差别,我就是希望能达到这样的效果,我标题的描述不是很准确,我是想只要没有明显的画质损失就可以。
    wnpllrzodiac
        4
    wnpllrzodiac  
       3 天前   ❤️ 1
    V..... libx265 libx265 H.265 / HEVC (codec hevc)
    V..... nvenc_hevc NVIDIA NVENC hevc encoder (codec hevc)
    V..... hevc_amf AMD AMF HEVC encoder (codec hevc)
    V..... hevc_nvenc NVIDIA NVENC hevc encoder (codec hevc)
    V..... hevc_qsv HEVC (Intel Quick Sync Video acceleration) (codec hevc)

    hevc_qsv AVOptions:
    -async_depth <int> .D.V...... Internal parallelization depth, the higher the value the higher the latency. (from 1 to INT_MAX) (default 4)
    -load_plugin <int> .D.V...... A user plugin to load in an internal session (from 0 to 2) (default hevc_hw)
    none 0 .D.V......
    hevc_sw 1 .D.V......
    hevc_hw 2 .D.V......
    -load_plugins <string> .D.V...... A :-separate list of hexadecimal plugin UIDs to load in an internal session (default "")
    -gpu_copy <int> .D.V...... A GPU-accelerated copy between video and system memory (from 0 to 2) (default default)
    default 0 .D.V......
    on 1 .D.V......
    off 2 .D.V......

    随便搞下就行了。同样码率,265 比 264 画质高。同样画质,265 省码率。
    随便给个 preset 就行。
    ffmpeg -i in_h264.mp4 -c:v hevc_qsv --preset fast -b:v 2000k -movflags +faststart out_hevc.mp4
    wniming
        5
    wniming  
    OP
       3 天前
    @wnpllrzodiac 你这条命令管用,转换后的视频码率 2mbit/s 左右,大小 177MB ,看不出画质损失
    ntedshen
        6
    ntedshen  
       2 天前   ❤️ 1
    chesha1
        7
    chesha1  
       2 天前   ❤️ 2
    @wniming #5 它这个 fast 的 preset 太搞了,要是你不缺硬件性能建议改成 veryslow ,码率和画质的综合表现都能更好一点
    234ygg
        8
    234ygg  
       2 天前   ❤️ 2
    这种很难客观评价的,变量太多了,用不同硬件同参数压出来的也不一样。。
    b 站上很多 1080p 强行拉成假 4k 封装成码率 10Mbps 的 h264 ,压缩成 5Mbps 的 nvenc 1080p h265 都不会有什么画质损失。
    但是有些压缩率高的惊人的 h264 ,即使转成同码率的 nvenc 1080p h265 (very slow) 也会出现画质损失。

    玩多了的话,10Mbps 以下的原视频 基本上能靠肉眼先预估个实际码率,然后去调节编码的参数。。
    另外,纯 cpu 软编码太慢太费电了,实在没什么必要,我只会偶尔扔一个特别值得收藏的视频蓝光 ISO 到云服务器上慢慢 cpu 软编码
    wniming
        9
    wniming  
    OP
       2 天前
    @chesha1 fast 和 veryslow 我实测文件大小和码率都没有什么区别,不过 fast 比 veryslow 快了将近一倍,不知道是不是我测试用的视频的问题。

    @234ygg 我是用 uhd770 转码的,cpu 占用不高。
    mongoose
        10
    mongoose  
       2 天前
    我之前也想这么做,但是经过我的调研,视频压缩转码是一个玄学,需要补课的内容有点多,我就放弃了。
    cybort
        11
    cybort  
       2 天前 via Android
    hevc 的工具应该比较多了吧,av1 的倒是不多
    234ygg
        12
    234ygg  
       2 天前   ❤️ 1
    @wniming
    veryslow 会在同样文件大小的前提下有更好画质,通常主观感受上连 10%都很难有,主要是高动态/比较复杂的画面会有区别。除非是特别值得珍藏起来反复观看的视频,否则没必要用 veryslow
    NoOneNoBody
        13
    NoOneNoBody  
       2 天前   ❤️ 1
    @wniming #9
    这个在动作片或画面高速变换的场景有区别
    SenseHu
        14
    SenseHu  
       2 天前   ❤️ 1
    从几个角度分析这个问题
    1. 画面内容
    是真实世界高频信号多的画面,还是动画那些低频信号多的,
    后者优先考虑降低分辨率,对压缩贡献很大,大概率也不会影响观感, -ss 参数截一小段转码试试,
    前者不太好搞, 高频信号 + 频繁运动的画面, 你眼睛跟不上他的细节, 降低点编码质量你也看不出 (前东家编解码组大佬同事的真实落地方案)
    2. 码率 & 质量控制
    VBR, ABR, CBR. 上面有朋友给的 -b:v 2000k 和 -crf 参数可以自己测试下看哪个好.
    3. 帧比例
    I 帧, P 帧, B 帧 这些概念在 h265 和 h264 都有体现, 减少低压缩率的 I 帧有利于减小最终文件大小, 对应 ffmpeg 参数
    -keyint_min , -sc_threshold
    4. 编码器.
    要求质量的话, 优先考虑 软编( 用 CPU 编码 ), 对应 x264, x265 这些工具 ( ffmpeg -c:v 指定 ), 缺点就是慢.
    这样的质量还不满意就考虑商业化方案吧, 比如 微帧 (前东家就是用的这家, 大规模用
    heimoshuiyu
        15
    heimoshuiyu  
       2 天前
    想要保证画质的情况下降低大小就不要用恒定码率,用 crf 指定视频质量,不断调整直到你肉眼观察出视频质量下降就是你能接受的极限 crf 。例如手机拍摄的本身噪点就多,我一般设置 34 ,蓝光视频我一般设置 18 。不同编码器对 crf 的解释是不一样的,建议翻翻 ffmpeg 文档里面都有说得很详细。
    heimoshuiyu
        16
    heimoshuiyu  
       2 天前
    另外我怀疑 OP 这个硬件编码设备的能力(同等码率下的视频质量可能会比 CPU 编码的差),除非有比较现代的独立显卡不然建议使用 CPU 压制
    shimanooo
        17
    shimanooo  
       2 天前   ❤️ 1
    预估码率, 比如原片的 60%, 压完以后人工比较 https://github.com/pixop/video-compare

    UHD770 比 1035G7 的 GPU 老吧, 从这里看同画质压缩率不如 x265 medium. https://rigaya.github.io/vq_results/

    我是用 x265 slow 的, 冬天就当取暖了.
    wizardyhnr
        18
    wizardyhnr  
       2 天前
    h264 不是高码率原盘的话就没必要转了,画质二次压缩有损。
    chutsetien
        19
    chutsetien  
       2 天前
    我 2 年前写的一个关于 libx265 的压码笔记,不知道 OP 会不会觉得有用:
    https://www.reddit.com/r/2000committee/comments/12s5llm/some_personal_libx265_notes/
    baobao1270
        20
    baobao1270  
       2 天前 via Android
    不要用 gpu 转,gpu 转不保证画质,建议用 x265 cpu 编码,如果真的要对比画质那么得上 vmaf 测了
    0xsui
        21
    0xsui  
       2 天前
    cpu 转的比 gpu 转的画质更好,就是时间会久一些,有的时候,一些 264 视频用 gpu 转换完,会发现 265 的反而更大了。。。
    wnpllrzodiac
        22
    wnpllrzodiac  
       2 天前 via Android
    @NoOneNoBody 对,纹理复杂的动作戏。建议拿打斗戏测试。和文戏完全不是一个难度。
    old9
        23
    old9  
       2 天前
    硬件编码优先考虑的是效能、编码速度、省电等,在相同码率下,画质几乎一定是显著差于软件编码的。
    硬件编码更适用于时间敏感的场景,比如直播,或者需要快速大批量编码的场景,楼主的需求还是软件编码吧。
    编码指令可直接参考 ffmpeg wiki: https://trac.ffmpeg.org/wiki/Encode/H.265
    Rorysky
        24
    Rorysky  
       2 天前
    视频编码的复杂程度远超想象,不损失是不可能的,只能说损失一些
    liyanggyang
        25
    liyanggyang  
       2 天前
    ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 \
    -i /tmp/h264.mp4 \
    -vf 'format=nv12|vaapi,hwupload' \
    -c:v hevc_vaapi \
    -b:v 0 \
    -qp 28 \
    -preset medium \
    -c:a copy \
    /tmp/hevc.mp4

    不可能完全不损失
    aero99
        26
    aero99  
       2 天前 via iPhone
    只要肉眼看不出画质损失就可以了
    easynote
        27
    easynote  
       2 天前
    up 有结论后分享一下。
    nebulabox
        28
    nebulabox  
       1 天前
    输出参数 h265 的视频码率可设置为 h264 的一半。
    rick13
        29
    rick13  
       1 天前
    之前弄过,就记的 crf 还是什么设置成 28 ,大概缩小一半体积,画质一些特殊场景稍微能看出来点。转的 av ,场景也比较固定,其实看不太出来
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3010 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 34ms · UTC 07:30 · PVG 15:30 · LAX 23:30 · JFK 02:30
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.