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

就算不减小文件大小，也会损失少许画质。减小文件大小的话，损失得更多一些。
如果用显卡编码的话，比纯软件编码损失会再更多一些。

直接丢给 AI 就会给你个能用的命令，完全不损不大可能。

@msg7086 我在 windows 平台下用 handbrake 的 qsv 硬件加速预设转码一个 11 分钟，h.264 格式，1080p ，大概 10 兆左右码率，823 兆大小的视频， 转换后的视频大小有 488 兆，码率大概 6 到 7 兆，同时播放 2 个视频对比看不出明显的差别，我就是希望能达到这样的效果，我标题的描述不是很准确，我是想只要没有明显的画质损失就可以。

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

@wnpllrzodiac 你这条命令管用，转换后的视频码率 2mbit/s 左右，大小 177MB ，看不出画质损失

码率先拉个 4m 再说。。。

https://rigaya.github.io/vq_results/
https://github.com/Netflix/vmaf

@wniming #5 它这个 fast 的 preset 太搞了，要是你不缺硬件性能建议改成 veryslow ，码率和画质的综合表现都能更好一点

这种很难客观评价的，变量太多了，用不同硬件同参数压出来的也不一样。。
b 站上很多 1080p 强行拉成假 4k 封装成码率 10Mbps 的 h264 ，压缩成 5Mbps 的 nvenc 1080p h265 都不会有什么画质损失。
但是有些压缩率高的惊人的 h264 ，即使转成同码率的 nvenc 1080p h265 (very slow) 也会出现画质损失。

玩多了的话，10Mbps 以下的原视频 基本上能靠肉眼先预估个实际码率，然后去调节编码的参数。。
另外，纯 cpu 软编码太慢太费电了，实在没什么必要，我只会偶尔扔一个特别值得收藏的视频蓝光 ISO 到云服务器上慢慢 cpu 软编码

@chesha1 fast 和 veryslow 我实测文件大小和码率都没有什么区别，不过 fast 比 veryslow 快了将近一倍，不知道是不是我测试用的视频的问题。

@234ygg 我是用 uhd770 转码的，cpu 占用不高。

我之前也想这么做，但是经过我的调研，视频压缩转码是一个玄学，需要补课的内容有点多，我就放弃了。

hevc 的工具应该比较多了吧，av1 的倒是不多

@wniming
veryslow 会在同样文件大小的前提下有更好画质，通常主观感受上连 10%都很难有，主要是高动态/比较复杂的画面会有区别。除非是特别值得珍藏起来反复观看的视频，否则没必要用 veryslow

@wniming #9
这个在动作片或画面高速变换的场景有区别

从几个角度分析这个问题
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 指定 ), 缺点就是慢.
这样的质量还不满意就考虑商业化方案吧, 比如 微帧 (前东家就是用的这家, 大规模用

想要保证画质的情况下降低大小就不要用恒定码率，用 crf 指定视频质量，不断调整直到你肉眼观察出视频质量下降就是你能接受的极限 crf 。例如手机拍摄的本身噪点就多，我一般设置 34 ，蓝光视频我一般设置 18 。不同编码器对 crf 的解释是不一样的，建议翻翻 ffmpeg 文档里面都有说得很详细。

另外我怀疑 OP 这个硬件编码设备的能力（同等码率下的视频质量可能会比 CPU 编码的差），除非有比较现代的独立显卡不然建议使用 CPU 压制

预估码率, 比如原片的 60%, 压完以后人工比较 https://github.com/pixop/video-compare

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

我是用 x265 slow 的, 冬天就当取暖了.

h264 不是高码率原盘的话就没必要转了，画质二次压缩有损。

我 2 年前写的一个关于 libx265 的压码笔记，不知道 OP 会不会觉得有用：
https://www.reddit.com/r/2000committee/comments/12s5llm/some_personal_libx265_notes/

不要用 gpu 转，gpu 转不保证画质，建议用 x265 cpu 编码，如果真的要对比画质那么得上 vmaf 测了