常用工具与调试 on Dorkytiger 的小屋

FFmpeg 命令行

Mon, 01 Jan 0001 00:00:00 +0000

一、日常必会命令

# 查看文件信息
ffprobe input.mp4
ffprobe -v quiet -print_format json -show_streams input.mp4  # JSON 格式

# 格式转换
ffmpeg -i input.avi -c:v libx264 -c:a aac output.mp4

# 截取片段（从 10 秒开始，持续 5 秒）
ffmpeg -i input.mp4 -ss 10 -t 5 -c copy output.mp4

# 缩放到 720p
ffmpeg -i input.mp4 -vf scale=-1:720 output.mp4

# 推流到 RTMP
ffmpeg -i input.mp4 -c:v libx264 -preset ultrafast -f flv rtmp://server/live/stream

# 桌面推流（Windows）
ffmpeg -f gdigrab -i desktop -c:v libx264 -preset ultrafast -tune zerolatency -f flv rtmp://localhost/live/test

# 拉流并保存
ffmpeg -i rtmp://server/live/stream -c copy record.mp4

二、直播延迟优化

# ❌ 默认配置（高延迟，高质量）
ffmpeg -i input -c:v libx264 -f flv rtmp://server/live

# ✅ 低延迟配置
ffmpeg -i input -c:v libx264 \
  -preset ultrafast \              # 最快的编码速度
  -tune zerolatency \              # 零延迟优化
  -g 15 \                          # 每 15 帧一个关键帧
  -bf 0 \                          # 不要 B 帧
  -f flv rtmp://server/live/stream

# 各参数的延迟影响：
# -preset ultrafast ↓延迟 ↑文件体积（编码快，但压缩率低）
# -preset medium    平衡点
# -preset veryslow  ↑延迟 ↓文件体积（编码慢，但压缩率高）
# 直播必须用 ultrafast 或 veryfast

常用调试命令

Mon, 01 Jan 0001 00:00:00 +0000

// 检测原始 PCM 数据是否正常（用 Audacity 或查看波形）
// 最简单的检测：打印前 10 个样本
void inspect_pcm(const int16_t* data, int count) {
    printf("First 10 PCM samples:\n");
    for (int i = 0; i < min(10, count); i++) {
        printf("  [%d] = %d\n", i, data[i]);
    }

    // 检查是否全是 0（静音文件）
    bool all_zero = true;
    for (int i = 0; i < count; i++) {
        if (data[i] != 0) { all_zero = false; break; }
    }
    printf("All zero: %s\n", all_zero ? "YES (silent!)" : "NO");
}

// 检测视频帧率是否稳定
void check_fps_stability(const vector<int64_t>& pts_list) {
    printf("Frame timestamps (ms):\n");
    for (size_t i = 0; i < pts_list.size(); i++) {
        if (i > 0) {
            int64_t delta = pts_list[i] - pts_list[i-1];
            printf("  frame %zu: delta=%lld ms (expected %.1f fps)\n",
                   i, delta, 1000.0 / delta);
        }
    }
}

常见问题排查清单

Mon, 01 Jan 0001 00:00:00 +0000

一、推流失败

# ① 先确认端口通不通
telnet rtmp-server.com 1935

# ② 用 ffmpeg 命令行测试推流（排除代码问题）
ffmpeg -f lavfi -i testsrc -f flv rtmp://server/live/test

# 如果 ffmpeg 能推，你的代码不能，说明是代码问题
# 如果 ffmpeg 也不能推，说明是服务器/网络问题

二、画面花屏

可能原因：
  GOP 设置太大 → 播放器丢失了第一个 I 帧，后续 P 帧无法解码
  解决方案：
    - -g 15（每 15 帧插一个 I 帧）
    - 播放器等待下一个 I 帧
    - 推流开始时先发送一段静音帧让播放器稳定

  H.264 sps/pps 丢失：
    sps/pps 是 H.264 的解码配置，必须在第一个 I 帧之前发送
    RTMP 连接时先发送 AVCDecoderConfigurationRecord（包含 sps/pps）
    然后在每个关键帧前重复发送 sps/pps（称为"extra data"）

三、音画不同步

排查步骤：
  1. 用 ffprobe 检查时间基是否一致
     ffprobe input.mp4 -show_streams
     看 video 和 audio 的 time_base

  2. 检查是否有 B 帧导致 PTS/DTS 错位
     ffprobe -show_frames input.mp4 | grep pict_type
     如果有 B 帧，确保解码时按照 DTS 顺序，显示时按照 PTS 顺序

  3. 检查 PTS 是否有跳变
     打印每帧的 PTS，看是否单调递增
     如果 PTS 回退或大幅跳变，说明时间戳设置有问题

  4. 编码前后的 time_base 转换是否正确
     av_packet_rescale_ts 必须使用正确的输入/输出 time_base

四、推流延迟大

可能原因和解决方法：

  问题：编码器缓冲太多帧（lookahead）
  解决：-tune zerolatency, -rc_mode cbr

  问题：GOP 太大（关键帧间隔太长）
  解决：-g 15 或 -g 30

  问题：B 帧引入延迟
  解决：-bf 0（不用 B 帧）

  问题：网络拥塞
  解决：降低码率 -b:v 1000k（1Mbps）
       使用 CBR（固定码率）而不是 VBR（可变码率）

  问题：RTMP Chunk 大小设置不合理
  解决：RTMP 默认 chunk_size = 128，不需要改

第八阶段总结

Mon, 01 Jan 0001 00:00:00 +0000

FFmpeg 命令行：
    ffprobe → 检查文件信息
    ffmpeg -preset ultrafast -tune zerolatency → 直播推流标配

推流问题排查：
    先 ffmpeg 命令行排除代码问题
    telnet 确认端口通

画面花屏：
    GOP 大小 + sps/pps 重复发送

音画不同步：
    time_base 一致性 + PTS 单调递增 + 音频主时钟

延迟优化：
    不要 B 帧 + 小 GOP + CBR 码率 + ultrafast preset