直播服务器已经修改了转码配置，但播放画面仍保持旧分辨率、旧编码或旧码率时，不要继续反复编辑配置文件。最先要确认的是三个层面的实际状态：磁盘上的配置内容、服务启动时传入的进程参数，以及播放器真正获取到的媒体内容。三者中最先出现不一致的位置，通常就是故障所在。

最常见的原因是改错了配置文件、systemd 仍使用旧的服务定义、转码进程没有重启、命令行参数覆盖了文件配置，或者服务器上同时存在两个转码进程。下面以 Linux systemd 管理单个 FFmpeg 转码进程、输出 HLS 播放列表为例说明排查方法。实际使用其他直播服务时，保留“配置文件 → 有效启动参数 → 播放输出 → 播放日志”的检查顺序，并将服务名、配置路径和原生校验命令替换为实际值。

先明确影响范围和目标状态

先记录当前故障，不要立即重启多个服务。至少保留以下信息：

• 直播输入地址或输入标识；
• 播放器当前使用的播放地址；
• 期望的输出编码、分辨率、帧率和音频格式；
• 故障开始时间，以及最近一次修改配置的时间；
• 当前负责启动转码进程的服务名；
• 播放器日志或服务日志中的报错时间点。

如果直播仍在提供服务，应先判断故障是“配置未生效”，还是“输出已经改变但播放器没有使用新输出”。这两个问题的处理方式不同：

排查前应具备 sudo 权限，能够读取服务日志和进程信息，并确认当前服务器上实际使用的是 systemd 还是其他进程管理方式。不要在没有备份的情况下覆盖原配置，也不要使用针对所有 FFmpeg 进程的批量终止命令，否则可能误伤其他直播任务。

典型失效场景：文件改了，但运行中的进程没有使用它

直播服务器的转码配置通常存在多个层级：

1. 应用配置文件；
2. systemd 服务单元和 drop-in 覆盖文件；
3. 环境变量或启动脚本；
4. 最终传给转码程序的命令行参数；
5. 播放器实际请求的输出地址。

例如，服务可能不是直接读取 /etc/live-transcode/transcode.conf，而是通过脚本读取另一个路径；也可能在 systemd 的 ExecStart 中直接写死了 -c:v copy，从而绕过了配置文件中的编码设置。

许多服务还允许通过 profile、环境变量或命令行指定参数。具体优先级取决于软件实现，不能把某一套软件的规则套用到所有直播服务器上。因此，判断“配置是否生效”时，不能只看文件内容，必须继续查看实际启动参数和媒体输出。

第一步：定位真正管理转码进程的服务

如果已经知道服务名，可以先设置变量；如果不知道，可先搜索服务列表。

sudo systemctl list-units --type=service --all | grep -Ei 'live|stream|transcod|ffmpeg'

确认服务名后执行：

UNIT=live-transcode.service

sudo systemctl status "$UNIT" --no-pager
sudo systemctl show "$UNIT" \
  -p FragmentPath \
  -p DropInPaths \
  -p ExecStart \
  -p Environment \
  -p EnvironmentFiles \
  -p MainPID \
  --no-pager

这里重点看几个结果：

• FragmentPath：当前服务主文件的位置；
• DropInPaths：是否存在额外的覆盖配置；
• ExecStart：服务实际准备执行的命令；
• EnvironmentFiles：是否加载了环境变量文件；
• MainPID：当前服务的主进程编号。

再查看 systemd 合并后的服务定义：

sudo systemctl cat "$UNIT"

常见的 systemd 服务文件可能位于 /etc/systemd/system/、/usr/lib/systemd/system/ 或 /lib/systemd/system/。不要根据发行版习惯直接猜路径，以 FragmentPath 和 DropInPaths 的结果为准。

如果 ExecStart 指向的是 shell 脚本、启动器或自定义二进制程序，还要继续查看该脚本中是否重新指定了配置文件、profile 或输出地址。脚本路径可从 ExecStart 中提取后读取：

sudo sed -n '1,240p' /path/to/start-transcode.sh

sed 这里只读文件，不会修改内容。若脚本中包含密码、密钥或带鉴权信息的地址，不要把完整内容直接粘贴到工单、群聊或公开日志中。

第二步：查看实际运行中的进程参数

服务定义只能说明“准备启动什么”，不能证明当前进程已经使用了新配置。先获取主进程编号：

PID=$(sudo systemctl show -p MainPID --value "$UNIT")
printf 'MainPID=%s\n' "$PID"

sudo ps -o pid,ppid,user,lstart,args -p "$PID"

如果 MainPID 为 0，说明服务当前没有有效运行进程。若主进程只是一个包装脚本，还要查看子进程：

sudo pstree -aps "$PID"
sudo ps --ppid "$PID" -o pid,ppid,user,lstart,args

在 Linux 上，可以从 /proc 读取进程真正收到的参数：

sudo tr '\0' ' ' < "/proc/$PID/cmdline"
printf '\n'
sudo readlink -f "/proc/$PID/exe"
sudo readlink -f "/proc/$PID/cwd"

如果主进程不是实际的 FFmpeg worker，应在进程树中找到真正执行转码的子进程，再针对子进程编号重复检查。对于 FFmpeg 示例，重点观察以下参数是否与目标状态一致：

-i                 输入地址或输入设备
-map               实际选择的视频、音频流
-c:v               视频编码器
-vf scale=...      缩放或其他视频滤镜
-b:v               视频码率设置
-r                 输出帧率
-g                 关键帧间隔
-c:a               音频编码器
-b:a               音频码率
-f hls             输出封装格式
输出路径           播放列表实际写入位置

下面是参数关系示意，不是可以直接粘贴到任意直播服务器的通用配置文件：

ffmpeg -i "$INPUT" \
  -map 0:v:0 -map 0:a:0 \
  -c:v "$VIDEO_ENCODER" \
  -vf "scale=${WIDTH}:${HEIGHT}" \
  -c:a "$AUDIO_ENCODER" \
  -f hls "$PLAYLIST"

特别检查是否存在以下冲突：

• 配置文件要求重新编码，但命令行出现 -c:v copy，这表示视频可能被直接转封装；
• 配置文件要求输出音频，但 -map 没有选择音频流；
• 配置文件指定了新输出路径，但 ExecStart 仍写入旧目录；
• 服务使用了 profile 名称，实际分辨率和编码参数隐藏在 profile 文件中；
• 修改的是一个服务实例，播放器访问的却是另一个实例的输出；
• 服务状态显示正常，但旧进程仍在占用旧播放列表。

如果系统中存在多个同类进程，应先建立进程与输出地址之间的对应关系，不要直接执行 pkill ffmpeg 或批量终止所有转码进程。错误终止其他直播任务会扩大影响范围。

第三步：区分 systemd 重载、应用重载和进程重启

这是配置不生效时最容易混淆的一步。

• systemctl daemon-reload：让 systemd 重新读取服务单元文件和 drop-in 文件，不会自动让正在运行的 FFmpeg 进程读取应用配置；
• systemctl reload：仅在服务明确实现了 reload 机制时有效，不能假定所有转码服务都支持；
• systemctl restart：停止并重新启动服务，通常可以使新的 ExecStart 和外部配置生效，但会造成当前直播中断或切换。

如果只修改了外部转码配置文件，通常不需要 daemon-reload，但仍需要按照软件文档执行应用重载或重启。如果修改了 systemd 服务文件、环境文件或 drop-in，则应先执行语法检查，再执行 daemon-reload，最后重启服务。

对 systemd 单元进行检查：

sudo systemd-analyze verify "$UNIT"

该命令主要检查 systemd 服务定义，不会验证所有应用配置项。转码软件如果提供原生配置检查命令，应使用该软件明确支持的命令；不要自行猜测一个不存在的 --test 或 --check-config 参数。

如果使用 FFmpeg 重新编码，还要确认当前二进制具备配置中要求的编码器：

command -v ffmpeg
ffmpeg -hide_banner -version
ffmpeg -hide_banner -encoders

可在输出中搜索目标编码器名称。编码器不存在时，即使配置文件语法正确，服务也可能在启动后立即退出，或者退回到其他编码方式。不要仅凭配置文件中的编码器名称判断它已经可用。

第四步：备份后修改，并让新配置真正进入进程

确认了配置来源和服务定义后，再进行修改。先备份正在使用的文件。以下命令适用于普通文件配置，备份动作不会覆盖原文件：

CFG=/etc/live-transcode/transcode.conf
BACKUP="${CFG}.bak.$(date +%Y%m%d%H%M%S)"

sudo cp -a -- "$CFG" "$BACKUP"
sudo sha256sum "$CFG" "$BACKUP"
printf 'Backup=%s\n' "$BACKUP"

如果修改的是 systemd 服务文件，也应分别备份：

UNIT_FILE=$(sudo systemctl show -p FragmentPath --value "$UNIT")
UNIT_BACKUP="${UNIT_FILE}.bak.$(date +%Y%m%d%H%M%S)"

sudo cp -a -- "$UNIT_FILE" "$UNIT_BACKUP"
sudo sha256sum "$UNIT_FILE" "$UNIT_BACKUP"

使用 sudoedit 修改比直接用重定向覆盖更稳妥：

sudoedit "$CFG"

变更内容应尽量单一。例如只调整输出分辨率，不要同时更换编码器、输出路径和日志目录。这样在失败时更容易判断原因，也便于回滚。

修改完成后，按实际变更类型执行：

# 仅修改 systemd 服务文件或 drop-in 时执行
sudo systemd-analyze verify "$UNIT"
sudo systemctl daemon-reload

# 修改外部配置，或确认服务必须重新读取配置时执行
sudo systemctl restart "$UNIT"

restart 会影响当前直播，适合在可控切换窗口执行。执行后立即检查状态和日志：

sudo systemctl status "$UNIT" --no-pager
sudo journalctl -u "$UNIT" --since "15 minutes ago" --no-pager

如果服务很快退出，应重点查看日志中是否出现配置解析失败、输入无法打开、输出目录无权限、编码器不存在、端口或文件被占用等信息。不要在错误原因未明确前连续重启，这会覆盖故障发生时的时间线。

第五步：用播放列表和媒体探测结果验证转码

进程参数正确，只能说明转码程序被要求这样运行，还不能证明播放器拿到的就是新输出。应使用实际播放地址检查输出。

先获取播放列表内容：

PLAYLIST='https://example.invalid/live/index.m3u8'

curl -fsS --max-time 10 "$PLAYLIST" | sed -n '1,100p'

请将示例地址替换为实际地址。检查以下内容：

• 返回的是否是预期播放列表，而不是旧目录中的文件；
• 多码率播放列表中是否出现目标分辨率；
• 媒体播放列表中的 #EXT-X-MEDIA-SEQUENCE 是否持续变化；
• #EXTINF 后面的分片地址是否指向当前输出目录；
• 分片请求是否返回成功，而不是连续出现 404 或 5xx；
• 播放列表中的更新时间是否与本次重启时间相符。

对于多码率 HLS，不要只检查主播放列表。播放器可能自动选择了另一个清晰度，应继续检查播放器日志中实际请求的子播放列表地址，再对该地址执行验证。

服务器安装了 ffprobe 时，可以直接读取播放地址中的媒体信息：

command -v ffprobe

ffprobe -hide_banner -v error \
  -show_entries stream=index,codec_type,codec_name,width,height,avg_frame_rate,bit_rate \
  -of json \
  "$PLAYLIST"

验证结果应与目标配置对应：

• codec_name 是否为期望的视频或音频编码；
• width 和 height 是否为期望分辨率；
• avg_frame_rate 是否与目标帧率相符；
• 是否同时存在视频流和音频流；
• bit_rate 是否有值并处于预期范围。

部分直播播放列表不会提供完整码率或平均帧率信息，因此单个字段缺失不一定代表配置失败。此时应结合进程参数、编码日志和播放器实际请求的分片综合判断。

如果没有 ffprobe，可使用播放器调试日志和服务访问日志完成验证。播放器日志至少要确认：

1. 请求的是本次变更后的播放地址；
2. 请求到了正确的主播放列表或子播放列表；
3. 分片请求没有持续失败；
4. 播放器没有因为解码器不支持、音频流缺失或格式不兼容而回退；
5. 播放器没有固定选择旧的清晰度层。

用三层结果快速定位故障

可以把一次有效变更判断为以下链路：

配置文件内容
    ↓
systemd 有效服务定义
    ↓
实际转码进程参数
    ↓
输出播放列表和媒体流
    ↓
播放器请求与解码日志

按这条链路定位时，结果通常有以下分支。

配置文件已更新，但进程参数未更新

优先检查：

• 修改的文件是否就是 EnvironmentFiles 或启动脚本实际读取的文件；
• 是否存在同名服务实例；
• 是否只执行了 daemon-reload，没有重启应用；
• ExecStart 是否覆盖了配置文件中的同名参数；
• 旧进程是否由其他 supervisor、脚本或手工命令启动；
• drop-in 文件是否重新指定了启动参数。

此时不要先检查播放器，因为新参数尚未进入转码进程。

进程参数已更新，但播放内容未更新

优先检查：

• -f hls 后面的输出路径是否与播放器地址对应；
• 是否仍有第二个旧进程写入旧目录；
• 播放器是否请求了另一个清晰度层；
• 播放列表或分片是否仍来自旧实例；
• 服务器是否仅修改了配置，却没有生成新的输出文件。

可以对比进程命令行中的输出路径、播放列表中的分片路径和播放器日志中的请求地址。三个地址必须能够对应起来。

播放列表已更新，但播放器仍然异常

此时转码配置大概率已经进入输出层，应重点检查：

• 播放器请求的实际 URL；
• 选中的码率层是否存在；
• 视频编码器、音频编码器和封装格式是否被播放器支持；
• 播放器日志是否有解码错误；
• 分片是否完整生成，是否存在时间戳或音视频同步错误。

不要因为播放器画面异常就再次随机修改编码参数。先确定是媒体内容不符合预期，还是播放器没有使用这份媒体内容。

失败时的恢复和回滚

如果重启后服务无法启动，恢复优先级应是先恢复已知可用的转码链路，再继续分析新配置。回滚前确认备份文件与当前配置属于同一服务实例，避免把其他任务的配置覆盖回来。

恢复普通配置文件：

sudo cp -a -- "$BACKUP" "$CFG"

恢复 systemd 服务文件：

sudo cp -a -- "$UNIT_BACKUP" "$UNIT_FILE"
sudo systemd-analyze verify "$UNIT"
sudo systemctl daemon-reload

随后启动或重启服务：

sudo systemctl restart "$UNIT"
sudo systemctl status "$UNIT" --no-pager
sudo journalctl -u "$UNIT" --since "10 minutes ago" --no-pager

如果故障来自 drop-in 文件，应恢复对应的 drop-in 内容，而不是删除整个服务目录。回滚期间不要执行宽泛的删除命令，也不要终止所有同名转码进程。只处理已经确认属于该服务实例的文件和进程。

回滚成功的标准不是“服务显示 active”这一项，而是同时满足：

• 服务保持运行；
• 实际转码进程参数恢复到已知可用状态；
• 输出播放列表持续产生新分片；
• ffprobe 或播放器日志显示旧的、已验证可播放的媒体属性；
• 播放器能够重新请求并解码当前输出；
• 没有第二个旧进程继续写入相同输出目录。

后续演练时应固定检查的项目

为了减少下一次配置冲突，建议为每个直播转码实例保留一份简短的运行记录，至少标明：

• systemd 服务名和 FragmentPath；
• drop-in 文件位置；
• 实际配置文件和环境文件位置；
• 输入标识与输出播放地址的对应关系；
• 目标编码、分辨率、帧率和音频格式；
• 查询有效进程参数的方法；
• 查询日志的方法；
• 最近一次已验证可用的配置备份。

每次变更前后都应完成同一组核验：

1. 记录变更前的服务状态、进程参数和播放地址；
2. 备份配置文件及服务单元；
3. 只修改一个明确目标；
4. 执行对应的语法检查；
5. 按需执行 daemon-reload 和服务重启；
6. 再次读取实际进程参数；
7. 检查播放列表、媒体属性和播放器日志；
8. 若任一层不一致，优先恢复已知可用配置。

直播服务器的恢复顺序应当是：先保证有效转码进程和可播放输出，再处理清晰度、码率等非阻断性优化；先确认播放地址和输出路径，再处理播放器表现；先保留现场和日志，再进行下一轮修改。这样可以把“配置没有生效”与“配置已经生效但播放端没有使用”明确区分，避免在多个层级同时改动后失去判断依据。