ffmpeg读取FIFO推流需关闭文件或写满数据才启动的问题排查

该现象是多层缓冲机制+ffmpeg输入探测逻辑共同作用的结果，和FIFO本身的特性强相关：

• 第一层是写入端用户态缓冲：绝大多数编程语言的文件IO默认采用块缓冲模式，向FIFO写入数据时，数据会先存在写入进程的用户态内存里，直到缓冲块被填满、手动触发刷盘/进程退出才会真正把数据推到FIFO的内核缓冲。你把单次写入块放大100倍时，用户态缓冲会更快被填满，数据推给ffmpeg的速度自然更快。
• 第二层是操作系统FIFO内核缓冲：Linux系统下命名管道FIFO的内核默认缓冲大小为64KB，内核同样会攒够一定数据量才会唤醒读端（也就是ffmpeg）读取数据，避免频繁的上下文切换开销。
• 第三层是ffmpeg自身的预读探测逻辑：ffmpeg打开未知格式的输入源时，默认会预读最多5MB（不同版本默认值有差异）的数据、最多等待5秒的分析时长，用来识别输入封装格式、编码参数、分辨率、时基等启动输出流必需的信息，没收集到足够解析出完整流参数的数据前，不会正式启动流传输。
  你主动关闭FIFO时，内核会向ffmpeg传递EOF信号，ffmpeg收到信号后会立刻把所有缓冲中残留的数据全部读出做解析，只要数据足够识别流参数就会直接启动，不需要等缓冲攒满，这就是关闭FIFO能立刻触发传输的原因。

不存在硬编码的固定最低启动数据量阈值。
你观测到的“累计写入量阈值”是三层缓冲叠加默认探测规则产生的表象：只要ffmpeg拿到的数据足够完成格式识别、流参数解析，哪怕数据量只有几KB也会立刻启动；如果拿到的数据一直缺流头、关键帧、封装格式头等关键信息，哪怕写入几MB数据也会卡在探测阶段。比如输入是带SPS/PPS的H264关键帧，仅需几KB数据就能启动；如果是MP4这类需要完整moov头的封装格式，需要的数据量会明显更高。

所有方案围绕「减少缓冲延迟、跳过不必要的探测步骤」设计，可组合使用：

• 写入端关闭缓冲：写FIFO的进程主动关闭用户态块缓冲，每次写入后立刻把数据刷到内核。C/C++可调用setvbuf(fifo_fd, NULL, _IONBF, 0)设置无缓冲；Python在open文件时指定buffering=0；Shell命令可加stdbuf -o0前缀执行，比如stdbuf -o0 ./your_write_script > /your/fifo/path，每次写入后主动调用flush操作。
• 启动ffmpeg时缩小探测范围、关闭分析等待：在输入源前添加参数，降低预读数据量上限、取消分析时长等待，示例命令：

  ffmpeg -probesize 4096 -analyzeduration 0 -i /your/fifo/path <你的其他输出参数>
  

  其中probesize单位是字节，可设置为你单次写入FIFO的块大小，analyzeduration 0表示拿到可解析的数据后立刻启动，不额外等待攒数据。
• 明确指定输入格式，跳过自动探测：如果你明确知道写入FIFO的流格式，直接在输入前加-f 格式名参数，ffmpeg会跳过格式探测步骤，直接按指定格式解析输入，拿到首个完整可解码帧就会启动传输。比如输入是H264裸流时，命令示例：

  ffmpeg -f h264 -i /your/fifo/path <你的其他输出参数>
  

  常见格式对应参数：h264裸流用h264、H265裸流用hevc、FLV封装流用flv、MPEGTS流用mpegts。

注意：如果设置的probesize过小、或者指定格式后开头写入的数据不包含流头/关键帧等必要信息，ffmpeg会因为解析失败直接报错退出，需要确保第一次写入FIFO的数据块包含完整的流初始化信息。

内容的提问来源于stack exchange，提问作者tamirg