如果你经常处理现场舞台直拍、演唱会竖屏录像或者短视频素材，大概率遇到过类似的尴尬：原始文件明明很清晰，上传到社交平台却总是被二次压缩成“糊片”；用剪辑软件预览 4K 原片，画面卡得风扇起飞；想给视频瘦身，又担心压完变成“马赛克”。这其实不是拍摄设备的问题，而是视频处理流程没有设计好。

我这几年的一个明确判断是：直拍类视频的后期重心，不应该只放在“调色”或者“特效”上，而是放在“转码和码率控制”上。一条 4K 竖屏直拍素材，如果能在编码、分辨率、帧率、码率这几个参数上做对取舍，既能保留足够好的画面观感，又能大幅缩小文件体积，同时保证在手机、电视、网页播放器上都有不错的兼容性。

这篇文章会用 FFmpeg 工具链，以一条典型的 4K 竖屏直拍素材为案例对象，讲清楚一套可以复用的视频处理流程：怎么查素材信息、怎么设计转码参数、怎么批量压制、怎么验证成片效果。读完之后，你可以自己搭出一条从“原片”到“发布片”的处理管线，而不是每次面对视频都靠猜。

1. 这篇文章真正要解决的问题

很多人拿到一段 4K 竖屏直拍后，第一反应是直接放进剪辑软件剪一剪就导出。这样不是不行，但会有几个绕不开的问题。

第一个是体积问题。4K 素材的原始码率通常非常高，一条两三分钟的竖屏直拍，文件动辄几百 MB 甚至上 GB。对于个人收藏来说还能接受，但如果你要给朋友分享、传到短视频平台、或者放进素材库长期归档，这个体积就非常不友好。

第二个是兼容性问题。4K 在部分老旧设备、浏览器和播放器上并不流畅，尤其是手机端播放器，硬解支持情况参差不齐。很多 HEVC 编码的 4K 直拍，电脑上播放没问题，手机上一播放就音画不同步，或者干脆黑屏。

第三个是平台二次压缩问题。短视频平台和社交平台都有自己的转码策略，原始文件码率并不等于观众能看到的质量。你不能控制平台怎么压，但你可以让原始文件进入平台转码之前就处在一个合理的状态，避免被二次压缩时产生更多劣化。

所以本文要解决的不是“让直拍画面变得更完美”，而是解决视频交付链条上的实际问题：如何选择一个合适的编码、分辨率、码率组合，让视频在体积、画质、兼容性三者之间取得平衡。

什么样的读者最值得看这篇文章？三类人。第一类是经常做演唱会和舞台直拍剪辑的粉丝站站长，要批量处理大量素材；第二类是短视频创作者，需要理解上传前的视频参数；第三类是刚接触 FFmpeg 的开发者，想用一个真实场景掌握完整的视频处理命令。如果你只是偶尔压缩一个视频，也可以看，但不用追求每一段脚本都完全理解。

2. 视频处理的核心概念与编码原理

2.1 分辨率与竖屏方向

分辨率决定画面的像素总量。常见的横屏 4K 是 3840×2160，也就是 16:9；竖屏素材则往往反过来，比如 2160×3840。但这里有一个非常容易踩坑的点：很多竖屏视频的实际存储方式，是在横向画幅里加一个旋转标记。

也就是说，文件的宽高字段写着 3840×2160，但播放器读取旋转信息后，会把它旋转成竖屏显示。用 ffprobe 看这种文件，你会很困惑，明明素材是竖着拍的，为什么探测结果却是横的？所以处理前必须确认视频里有没有 rotation 信息，这一点后面会专门讲。

分辨率不是越高越好，而是要看你最终的播放场景。手机端播放，1080P 已经足够细腻，如果为了极致清晰保留 4K，会带来很大的存储和转码压力；但如果最终目标是大屏播放或长期收藏，4K 也有保留价值。做技术决策时，先问自己一个问题：这条视频最终在哪里看？

2.2 帧率

帧率表示每秒显示的画面数量，常见的有 24、25、30、60。直拍素材一般以 30 或 60 为主，舞台上有快速动作时，高帧率能降低拖影感。

但高帧率也有代价。60 帧的视频，编码数据量明显高于 30 帧，文件更大，编码时间更长。如果源素材本身就是 30 帧，就不要强行插帧到 60，那并不会增加真实信息量，反而可能产生伪影。因此，转码时通常保持源帧率即可，不需要额外处理，FFmpeg 默认也会沿用源视频帧率。

2.3 编码标准：H.264、H.265、AV1

编码标准决定了视频如何压缩。当前最主流的三种编码分别是 H.264（AVC）、H.265（HEVC）和 AV1。

H.264 是兼容性王者。几乎所有设备、播放器、剪辑软件都支持，非常适合作为最终发布格式。它的缺点是压缩率相对低，同样画质下文件比 H.265 大。

H.265 压缩率更高，同样画质可以比 H.264 节省 30% 到 50% 的体积。但兼容性不如 H.264，部分旧设备无法硬解。如果你要发给别人，对方设备能不能播，需要提前确认。

AV1 是新兴编码，压缩率更强，但编码速度很慢，硬件支持还在普及过程中。目前更适合视频网站和流媒体平台做离线转码，个人电脑处理时往往耗时太长，不推荐新手一开始就上手。

选择原则：不求最先进，只求“目标设备都能播”。如果要存档，H.265 是体积与画质的折中；如果要大众传播，H.264 更稳妥。转码是多次交付，不是一次定生死。

2.4 码率与 CRF 质量参数

码率是视频数据流每秒占用的比特数，单位通常是 kbps 或 Mbps。码率越高，理论上画质越好，文件也越大。

但码率控制有两种思路。一种是固定码率，比如统一压成 8Mbps，画面简单的场景会浪费，画面复杂的场景可能不够用，不够智能。另一种是可变码率，让编码器根据画面复杂度动态分配码率，画面复杂则多给，画面简单则少给。FFmpeg 中最常用的就是 CRF 参数。

CRF 是 constant rate factor 的缩写，含义是恒定质量因子。数值越小，质量越高，文件越大；数值越大，压缩越狠，画质损失越明显。在实际使用中，H.264 的 CRF 值通常选 18 到 23，H.265 因为压缩率更高，同等观感下可以选 20 到 26。不建议把 CRF 调到 30 以上，那大概率会出现可见的块状噪点。

2.5 容器格式与音频编码

视频文件后缀名对应的只是容器，比如 MP4、MOV、MKV。容器里面装的是视频流、音频流、字幕流和元数据。

最终交付时，MP4 是最通用的选择，几乎不会出问题。MKV 也能用，但有些平台和播放器支持度不如 MP4。至于音频，直拍素材通常是现场收音，转码时保留 AAC 即可，码率给到 192k 足够，不需要无损编码，因为源音频本身就不是高质量录音。

3. 环境准备：安装 FFmpeg 并完成基础验证

FFmpeg 是开源的音视频处理工具，核心部分是命令行程序，支持视频转码、裁剪、拼接、滤镜、抽帧、音频处理等几乎所有常见任务。它没有图形界面，但正因为如此，它非常适合脚本化和批量处理。

3.1 安装 FFmpeg

Windows 用户推荐用包管理器安装，或者直接到 FFmpeg 官网下载编译版。如果你使用 winget，可以执行：

winget install Gyan.FFmpeg

macOS 用户使用 Homebrew：

brew install ffmpeg

Linux 用户使用系统包管理器。以 Ubuntu/Debian 为例：

sudo apt update
sudo apt install ffmpeg

如果官方源里的版本偏旧，也可以添加第三方源安装新版，但这里不展开。版本不是越新越好，能稳定完成任务即可。

3.2 验证安装

安装完成后，打开终端执行：

ffmpeg -version

如果看到一长串编译信息，说明安装成功。再执行：

ffmpeg -encoders | grep 264

这条命令会列出当前 FFmpeg 支持的 H.264 相关编码器。重点看输出中是否有 libx264 ，它是软件编码器，几乎一定存在；如果看到 h264_nvenc ，说明支持 NVIDIA 硬件编码；看到 h264_qsv 说明支持 Intel 平台硬件编码；macOS 上则有 h264_videotoolbox 。

检查这些编码器的原因是，转码速度非常重要。一条 4K 竖屏直拍素材，如果用纯软件编码，可能要好几分钟甚至更久；如果硬件编码可用，速度会快几倍甚至十几倍。后面我会分别给出软件和硬件的转码命令，你可以按需选择。

4. 核心流程拆解：从原片到成片

视频处理看起来是“一条命令的事”，但真正标准化的流程应该有六个步骤，缺一不可。

4.1 探测素材信息，不要凭经验猜

拿到任何视频，第一件事永远是先看它的真实参数。视频是横向还是纵向、分辨率多少、帧率多少、编码格式是什么、有没有旋转标记，这些信息直接决定后面的转码策略。

很多人的转码失误都是因为“默认它一定是竖屏”。前面提到过，竖屏可能来自旋转 metadata，如果不处理就直接压缩，成片往往还是横的，方向全错。所以探测这一步不能省。

4.2 明确输出目标

在动手转码前，先想清楚这条视频用在哪里。是传短视频平台，还是发到聊天工具，还是本地收藏？这决定了分辨率、编码、码率的选择。

如果目标是大众传播，我建议优先输出一个 H.264 编码的 MP4，分辨率控制在 1080P 或 4K 以内，CRF 控制在合理区间。如果目标是长期归档，可以考虑 H.265 以减少存储。如果只是临时预览，甚至可以输出一个低分辨率验证版本。

4.3 设计转码参数

这一步是把目标翻译成 FFmpeg 参数。需要确定的参数包括编码器、分辨率、CRF、音频编码、像素格式、封装格式。像素格式建议固定为 yuv420p ，这是兼容性最好的格式，很多播放器不支持奇怪的像素格式。

4.4 执行转码

写命令，跑起来，观察输出日志。转码日志里会显示编码进度、当前帧率、比特率、耗时等信息。如果日志中出现大量错误，说明参数有问题，需要返回去检查。

4.5 验证输出

很多人压完视频看都不看就直接发了，这是不专业的。验证要包括：文件大小是否合理、分辨率是否正确、方向是否竖屏、播放是否流畅、有无音画不同步。

4.6 批量化和自动化

单条视频处理成功后，再做一次自动化，把命令封装成脚本，批量处理同一个文件夹下的大量素材。这一步才是真正能提高效率的地方，也是 FFmpeg 相比图形软件最大的优势。

5. 完整示例：FFmpeg 转码命令与脚本

下面给出从探测到转码的完整示例。请根据自己素材的真实路径替换文件名，这里统一使用 input.mp4 作为源文件。

5.1 用 ffprobe 探测视频详细信息

ffprobe -v error -show_format -show_streams input.mp4

这条命令会输出非常多字段。如果觉得太长，可以用下面这条更精简的命令只看视频流关键信息：

ffprobe -v error -select_streams v:0 \
  -show_entries stream=codec_name,width,height,r_frame_rate,bit_rate \
  -of default=noprint_wrappers=1 input.mp4

预期输出类似：

codec_name=hevc
width=3840
height=2160
r_frame_rate=60000/1001
bit_rate=24500000

这里 codec_name=hevc 表示源视频是 HEVC 编码；宽高是 3840×2160，看起来是横向，但如果视频本身是竖屏，还需继续检查旋转信息。执行：

ffprobe -v error -select_streams v:0 \
  -show_entries stream_tags=rotate \
  -of default=noprint_wrappers=1 input.mp4

如果输出 rotate=90 或 rotate=270 ，说明这个文件存在旋转标记，实际观感是竖屏，转码时需要小心处理。如果输出为空，且素材肉眼可见是竖屏，那说明它的采样尺寸本身就是竖的，比如 2160×3840。

5.2 H.264 转码：兼容性优先

假设源素材是 4K 竖屏，最终需要发到一个以手机播放为主的场景，那么输出 1080P 的 H.264 MP4 是比较稳妥的选择。命令如下：

ffmpeg -i input.mp4 \
  -vf "scale=-2:1920" \
  -c:v libx264 -preset medium -crf 20 \
  -pix_fmt yuv420p \
  -c:a aac -b:a 192k \
  -movflags +faststart \
  output_1080p.mp4

解释一下关键参数：

• -vf "scale=-2:1920" ：把视频高度缩放到 1920，宽度按比例自动计算。 -2 表示自动计算宽度并保证偶数，避免编码器报错。这里要注意，维度写的是“高度 1920”，不管视频是否旋转，FFmpeg 的 scale 滤镜作用于实际像素宽高；如果源是 3840×2160 且带了旋转标记，scale=-2:1920 得到的是缩放后的横向尺寸，最终播放时旋转后仍然是竖屏。
• -c:v libx264 ：使用 H.264 软件编码器，兼容性最好。
• -preset medium ：编码速度和压缩率折中。预设越慢，压缩效率越高，但耗时越长。可选值有 ultrafast、veryfast、fast、medium、slow、veryslow。
• -crf 20 ：H.264 的合理质量值。这个值对大多数舞台直拍来说已经足够清晰。
• -pix_fmt yuv420p ：强制使用 4:2:0 像素采样，确保播放器兼容。
• -movflags +faststart ：让 MP4 的元数据移到文件头部，网上播放时可以快速开始，不会等整个文件下载完。
• -c:a aac -b:a 192k ：把音频转成 AAC，码率 192k，适合网络分发。

如果源视频存在旋转标记，你希望输出时真正转正，也就是把旋转信息直接烘焙进像素，可以这样写：

ffmpeg -i input.mp4 \
  -vf "transpose=1,scale=-2:1920" \
  -c:v libx264 -preset medium -crf 20 \
  -pix_fmt yuv420p \
  -c:a aac -b:a 192k \
  -movflags +faststart \
  output_1080p_rotated.mp4

transpose=1 表示逆时针旋转 90 度并将视频翻转成竖屏。具体方向要根据素材的旋转标记来确定，不同素材可能要用 transpose=2 或 transpose=3 。稳妥的做法是先截一帧看看画面方向，再决定滤镜参数。

5.3 H.265 转码：存档与体积优先

如果你希望保留 4K 分辨率，同时减少文件体积，可以使用 H.265。下面命令输出 4K 竖屏 H.265 文件，并保持竖屏方向：

ffmpeg -i input.mp4 \
  -c:v libx265 -preset fast -crf 22 \
  -tag:v hvc1 \
  -pix_fmt yuv420p \
  -c:a aac -b:a 192k \
  -movflags +faststart \
  output_4k_hevc.mp4

-tag:v hvc1 是为了提升在 Apple 设备上的兼容性。如果你不带这个参数，FFmpeg 默认会写成 hev1 标签，部分 iOS 设备可能无法播放。这个细节很实用，值得记住。

H.265 编码速度比 H.264 慢，尤其是 4K 素材，请做好心理准备。如果你只是想压缩体积，并不在意分辨率，可以先降分辨率再接 HEVC，效果更明显。

5.4 硬件编码：大幅提升转码速度

如果你的机器有 NVIDIA 显卡，可以这样用 NVENC 做 H.264 编码：

ffmpeg -i input.mp4 \
  -vf "scale=-2:1920" \
  -c:v h264_nvenc -preset p4 -cq 20 \
  -pix_fmt yuv420p \
  -c:a aac -b:a 192k \
  -movflags +faststart \
  output_1080p_nvenc.mp4

注意这里用的质量参数是 -cq ，不是 -crf 。NVENC 的参数体系和 libx264 不同， -cq 20 是 NVIDIA 硬件编码器的恒定质量档位。 -preset p4 是性能和速度档位，p1 到 p7 可选，数字越大通常质量越好、速度越慢。

macOS 用户可以使用 VideoToolbox 硬件编码：

ffmpeg -i input.mp4 \
  -vf "scale=-2:1920" \
  -c:v h264_videotoolbox -b:v 6000k \
  -pix_fmt yuv420p \
  -c:a aac -b:a 192k \
  -movflags +faststart \
  output_1080p_videotoolbox.mp4

VideoToolbox 对码率的控制方式和 libx264 不一样，通常用 -b:v 指定目标码率，比如 6000k 。实际效果需要测试，不同 macOS 版本和硬件差异很大。

5.5 批量处理脚本

当素材不止一条时，写一个批量脚本可以省下大量时间。下面是一个 Linux/macOS 的 bash 脚本，处理 input 目录下所有 MP4 文件，输出到 output 目录：

#!/usr/bin/env bash
set -euo pipefail

INPUT_DIR="input"
OUTPUT_DIR="output"
mkdir -p "$OUTPUT_DIR"

for file in "$INPUT_DIR"/*.mp4; do
    name=$(basename "$file" .mp4)
    echo "Processing $file"
    ffmpeg -y -i "$file" \
        -vf "scale=-2:1920" \
        -c:v libx264 -preset medium -crf 20 \
        -pix_fmt yuv420p \
        -c:a aac -b:a 192k \
        -movflags +faststart \
        "$OUTPUT_DIR/${name}_1080p.mp4"
done

echo "All done."

在终端里执行：

chmod +x batch_convert.sh
./batch_convert.sh

如果你在 Windows 上更熟悉 Python，也可以写一个简单的 Python 脚本，核心逻辑是一样的，只是用 subprocess 调用 FFmpeg：

import subprocess
from pathlib import Path

input_dir = Path("input")
output_dir = Path("output")
output_dir.mkdir(exist_ok=True)

for file in input_dir.glob("*.mp4"):
    output = output_dir / f"{file.stem}_1080p.mp4"
    print(f"Processing {file.name}")
    cmd = [
        "ffmpeg", "-y", "-i", str(file),
        "-vf", "scale=-2:1920",
        "-c:v", "libx264", "-preset", "medium", "-crf", "20",
        "-pix_fmt", "yuv420p",
        "-c:a", "aac", "-b:a", "192k",
        "-movflags", "+faststart",
        str(output),
    ]
    subprocess.run(cmd, check=True)

print("All done.")

运行方式：

python batch_convert.py

注意， scale=-2:1920 只能保证高度缩放，不解决旋转问题。如果你的所有素材都有旋转标记，需要先确认方向，并在 -vf 中加上 transpose 参数。

6. 运行结果与效果验证

转码完成后，不要直接当作成片。至少要完成四个验证步骤。

6.1 检查文件大小

使用 ls -lh 查看输出文件大小：

ls -lh input.mp4 output_1080p.mp4

如果输入是高码率 4K，输出 1080P H.264 后通常会有明显体积下降。如果文件大小没有明显变化，说明原本码率不高，或者 CRF 选得太低，需要重新考虑参数。

6.2 用 ffprobe 校验输出参数

执行：

ffprobe -v error -select_streams v:0 \
  -show_entries stream=codec_name,width,height,r_frame_rate,bit_rate \
  -of default=noprint_wrappers=1 output_1080p.mp4

需要检查的内容包括：

• codec_name 是否为 h264
• 宽高是否是你期望分辨率
• 帧率是否和源视频一致
• bit_rate 是否在一个合理范围

如果分辨率不对，或者方向依然是横向，就需要回到滤镜参数重新处理。

6.3 抽帧检查画面

转码可能引起的画质问题，不能只看参数，还要“眼见为实”。从成片和原片各抽一帧，放到本地对比：

ffmpeg -i output_1080p.mp4 -ss 00:00:10 -frames:v 1 frame_output.jpg

同样方式从输入视频抽一帧。对比时重点关注舞台灯光边缘有没有明显色块、人物轮廓有没有发糊、有没有拉伸变形。如果压缩痕迹太明显，就把 CRF 值改小一点重新压。

6.4 播放测试

用系统播放器播放成片，拖动进度条，重点检查：画面方向是否正确、播放是否卡顿、拖动时音画是否同步。如果视频是 H.264 编码的 1080P，绝大多数设备都不会有问题；如果是 HEVC 4K，建议多换一台设备测试，尤其是老手机和浏览器播放器。

6.5 如果失败，先看哪里

遇到转码失败，第一件要做的事不是改参数，而是看错误日志。FFmpeg 的错误输出通常已经很明确，常见包括：

• 找不到输入文件：检查路径和文件名是否正确。
• 找不到解码器：当前 FFmpeg 版本缺少对应解码库，需要更新安装。
• 像素格式不支持：检查 -pix_fmt 参数，更改为 yuv420p 。
• 滤镜参数错误：检查 -vf 的写法，尤其是 scale 后面的分辨率。

改一次，跑一次，观察日志，直到输出和预期一致。

7. 常见问题与排查思路

问题现象	可能原因	排查方式	解决方案
转码后视频变成横向	源视频存在旋转 metadata，未处理	ffprobe 检查 rotate 字段	在 -vf 中加 transpose 滤镜，或调整输出尺寸
播放时出现音画不同步	音频采样率或时间戳异常	检查源文件音频流参数	重新转码时加上 -af "aresample=async=1" ，或先转音频再封装
4K H.265 文件很卡	播放设备不支持 HEVC 硬解	确认播放器与设备编码支持范围	改用 H.264 输出；或保留 H.265 但同时输出一个 1080P H.264 版本
体积没有明显变小	CRF 值偏低，或原本码率不高	查看输出文件码率	适当调高 CRF，比如从 18 调到 21，观察观感
画面出现明显色块	CRF 过高，码率分配不足	抽帧对比原片和成片	降低 CRF 值，或改用 slower 预设提升压缩效率
提示 Unknown encoder 'libx265'	FFmpeg 构建未包含 H.265 编码器	执行 ffmpeg -encoders | grep 265 查看支持情况	更换完整版 FFmpeg，或改用其他编码器
批量处理时某个文件失败中断	set -e 导致脚本遇到非零退出码直接停止	查看错误日志中的文件名	脚本中增加错误处理，单个文件失败时跳过并记录日志

其中，旋转问题是竖屏视频最容易被忽视的。很多素材刚拍出来是竖屏，但实际数据里是横向，播放器靠 rotate 标记纠正显示方向。转码如果不处理，要么输出横向画面，要么画面被拉伸变形。建议拿到素材后第一时间看 rotate 字段，再做编码参数设计。

8. 最佳实践与工程建议

8.1 永远保留原始母版

无论你怎么转码，原始拍摄文件都要单独存档，不要覆盖输入文件。转码是有损的，CRF 再低也回不到原始数据。一旦原始文件丢失，后续所有优化的余地都没了。建议建立一个清晰的素材库目录，比如：

archive/
  raw/        原片
  prores/     剪辑代理与中间格式
  output/     最终发布文件

8.2 文件命名规范

批量处理视频时，命名混乱是最浪费时间的坑。建议统一命名规则，把日期、内容、分辨率、编码、质量等级写清楚。例如：

20251016_shooting_4k_hevc_crf22.mp4
20251016_release_1080p_h264_crf20.mp4

有了规则之后，脚本处理和人工查找都方便很多。

8.3 输出“一主一备”双版本

最实用的方法是同时输出两个版本：一个 H.264 1080P 用于分享和传播，一个 H.265 4K 用于存档。这样既不牺牲收藏质量，也不影响实际传播。

8.4 CRF 值选择建议

H.264 建议从 20 开始测试，如果觉得文件太大就往上调一档；H.265 建议从 22 到 24 开始测试。不要盲目追求低 CRF，因为你可能需要处理大量视频，文件体积和编码耗时都是成本。

8.5 合理使用硬件编码

硬件编码速度快，但同码率下压缩率通常不如软件编码。实际项目里可以把两者结合起来：日常快速预览、临时交付使用硬件编码；高质量成片、长期存档使用软件编码。不要迷信某一个，效率与质量之间需要做平衡。

8.6 注意素材来源与版权合规

这一点必须单独强调。处理舞台直拍、演唱会录像、节目片段时，素材来源要合法，发布和分发要符合平台规则和相关法律法规。技术文章里讲的是转码能力，但能力的使用边界由使用者自己把握。如果你要公开传播，请先确认是否拥有足够的授权。不要为了流量去传播未经授权的影视、综艺和演出素材。

8.7 日志与可回溯性

批量转码时，建议把每个文件的转码日志单独保存。FFmpeg 输出到日志文件的方法很简单：

ffmpeg -i input.mp4 ... output.mp4 2> encode.log

日志文件会记录编码参数、警告和错误。后续排错时，这些日志就是第一手线索。

8.8 常用参数写成配置文件

如果团队协作，或者你自己要多次使用同一套参数，建议把参数抽成配置文件。比如用一个环境变量或脚本变量统一维护：

VIDEO_CODEC="libx264"
PRESET="medium"
CRF="20"
PIX_FMT="yuv420p"
AUDIO_BITRATE="192k"

这样改参数时不用在每一条命令里手动输入，减少出错概率。

9. 总结与后续学习方向

这篇文章以一条 4K 竖屏直拍素材为场景，完整走了一遍视频处理管线：先用 ffprobe 探测信息，再根据目标选择编码和分辨率，然后使用 FFmpeg 完成转码，最后通过文件大小、编码参数、抽帧对比和播放测试来验证成片质量。看完之后，你应该已经理解了 CRF、preset、yuv420p、faststart、硬件编码这些参数到底在控制什么，也知道批量脚本怎么写。

真正值得继续深入的方向有三个。第一是视频质量客观评估，比如用 VMAF 指标去判断两个转码结果到底谁更好，而不是只靠肉眼猜；第二是硬件编码调优，NVENC、QSV、VideoToolbox 各自的参数体系都值得单独研究；第三是 AV1 编码与云端转码服务，虽然本地硬件压力大，但这是流媒体时代的大趋势。

如果你本来就是做直拍搬运、演出片段剪辑或者短视频内容分发，我的建议是先搭好一套自己的标准参数：H.264 1080P 用于传播，H.265 4K 用于存档，命名规范统一，批量脚本放进项目目录。这套流程跑通之后，后期处理就不再是瓶颈，你可以把更多时间放在内容本身。希望这篇文章能帮你少走一点转码的弯路，也欢迎在评论区留言分享你遇到过的竖屏视频问题。