必须先调用avformat_network_init()初始化全局环境，再用avformat_open_input打开输入流并检查返回值，成功后立即调用avformat_find_stream_info获取流信息，最后遍历ic->streams通过codecpar->codec_type区分音视频流并读取参数。
如何用 avformat_open_input 打开视频并获取流信息
直接调用 avformat_open_input 是第一步，但很多人卡在返回负值错误。常见原因是没初始化 FFmpeg 全局环境，或传入了空/非法路径。必须先调用 avformat_network_init()（即使不联网），再确保路径是 C 风格字符串（const char*），不能传 std::string.c_str() 后原字符串被释放。
打开成功后立刻调用 avformat_find_stream_info，它会读取若干帧来推测编码参数——这步耗时，且可能失败（比如文件损坏或格式太冷门）。失败时返回负值，不要忽略返回码；可用 av_strerror 打印具体错误。
- 务必检查
avformat_open_input返回值，-2 表示文件不存在，-541478725（即AVERROR_INVALIDDATA）常因容器格式不支持 -
avformat_find_stream_info默认最多分析 5 秒数据，如遇长 GOP 视频可能参数不准，可通过修改ic->max_analyze_duration提高精度（单位微秒） - 调用后
ic->nb_streams才有效，此时才能遍历流
怎么区分视频/音频流并读取关键编码参数
FFmpeg 把所有流都存在 ic->streams 数组里，需逐个判断 stream->codecpar->codec_type：等于 AVMEDIA_TYPE_VIDEO 或 AVMEDIA_TYPE_AUDIO 才是目标流。别依赖索引序号——MP4 可能音视频顺序颠倒，MKV 甚至含字幕/数据流。
编码参数从 stream->codecpar（不是已废弃的 stream->codec）读取：codec_id 是编码器类型（如 AV_CODEC_ID_H264），width/height 对视频有效，sample_rate 和 channels 对音频有效。注意：这些是“解析出的参数”，不代表实际解码时一定能用——比如 H.264 的 profile/level 要看 codecpar->profile 字段。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
codecpar->bit_rate是容器声称的码率，常为 0 或不准；真实平均码率需自行统计解码帧 - 视频的
codecpar->field_order决定是否隔行，误判会导致播放撕裂 - 音频的
codecpar->format（如AV_SAMPLE_FMT_FLTP）是采样格式，影响后续重采样逻辑
为什么 avcodec_parameters_to_context 在新版本里必须用
旧代码习惯直接用 stream->codec，但自 FFmpeg 3.1+ 这个字段已弃用。现在必须显式分配解码器上下文，再用 avcodec_parameters_to_context 拷贝参数——否则调用 avcodec_open2 会失败，报错 Invalid argument。
这个函数只复制参数，不分配内存也不打开解码器。后续还需调用 avcodec_find_decoder 获取解码器，再传给 avcodec_open2。漏掉任一环节都会导致解码失败，且错误提示模糊（常卡在 avcodec_send_packet 返回 AVERROR(EINVAL)）。
- 必须用
avcodec_alloc_context3(decoder)分配上下文，不能栈上定义或 memset 零初始化 -
avcodec_parameters_to_context成功后，ctx->codec_id等字段才可信，可据此做 codec 特异性处理（如 H.264 的 SPS/PPS 提取） - 若只需流信息无需解码，这一步可跳过——但很多文档没说清这点，导致过度初始化
容易被忽略的资源释放和线程安全点
FFmpeg 的资源释放不是对称的：打开输入用 avformat_open_input，关闭却要分两层——先 avformat_close_input(&ic)，它会自动释放所有 AVStream* 及其 codecpar；但如果你手动调用过 avcodec_free_context，就千万别再让 avformat_close_input 处理同一上下文，否则双重释放崩溃。
另一个坑是多线程：avformat_find_stream_info 内部可能触发网络请求（如 HLS 的 playlist 加载），默认非线程安全。如果程序其他地方用了全局 FFmpeg 初始化（如 avdevice_register_all()），需确保单线程调用或加锁——尤其在 Android NDK 或 iOS 上，SIGSEGV 常因此触发。
-
avformat_close_input会置空传入的指针（&ic），所以调用后ic变为nullptr，二次调用无害 - Windows 下若链接动态库，必须保证
avcodec.dll、avformat.dll等版本完全一致，混用 4.x 和 5.x 会导致codecpar字段偏移错乱 - Android 上硬解码器（MediaCodec）的参数需从
AVCodecParameters映射，但codecpar->extradata的格式（如 H.264 的 AVCC vs Annex B）必须转换，否则初始化失败
