使用Boost将FFmpeg输出管道传输至FFplay标准输入的问题

这个问题我之前也踩过坑！本质是你对C++流的文本/二进制模式以及get/read方法的行为理解有点偏差，咱们一步步来拆解：

为什么逐字符复制CPU占用极高？ #

逐字符处理的时候，你每次只从FFmpeg的输出流读取1个字节，然后立刻写入FFplay的输入流。这个循环会疯狂触发操作系统的IO系统调用，上下文切换的开销被拉满，CPU自然就跑起来了——毕竟每一次循环都在跟内核打交道，完全没必要这么细粒度的操作。

为什么缓冲区批量复制FFplay不认？ #

你的缓冲区版本有两个关键问题：

1. iso.get(buffer, 1024)是文本模式读取：这个方法会一直读到换行符\n或者达到1024字节才停止，但FFmpeg输出的WAV是二进制数据，里面几乎不会有换行符，这就导致要么它一直等FFmpeg输出满1024字节（如果FFmpeg输出慢的话，FFplay会一直等数据），要么读取到的内容因为包含二进制空字节\0，用in << buffer输出时会被当成C字符串截断——FFplay拿到不完整的WAV头或者数据，自然识别不了格式。
2. 没有处理实际读取的字节数：就算get真的读到了数据，你直接把整个1024字节的缓冲区写进去，最后一次读取可能不满1024字节，多余的垃圾数据也会被写入，破坏WAV结构。

正确的缓冲区处理方式 #

直接改用二进制流的read/write方法，同时显式处理实际读取的字节数，代码修改如下：

// 先把流设置为二进制模式，避免平台上的文本转义破坏二进制数据
bp::ipstream iso(std::ios::binary);
bp::opstream in(std::ios::binary);

// 你的FFmpeg和FFplay进程创建代码不变...

char buffer[1024];
while (ffmpeg.running() || iso.peek() != EOF) {
    // 读取最多1024字节的二进制数据，不管有没有换行符或空字节
    iso.read(buffer, sizeof(buffer));
    // 获取实际读取的字节数（最后一次可能读不满缓冲区）
    std::streamsize bytes_read = iso.gcount();
    if (bytes_read > 0) {
        // 原封不动写入bytes_read个字节，不会因为空字节截断
        in.write(buffer, bytes_read);
        // 强制刷新输出流，确保数据立刻发送给FFplay，避免等待缓冲区满
        in.flush();
    }
}

关键细节解释： #

• 二进制模式：显式指定std::ios::binary创建流，避免Windows等平台把二进制里的0x0D（回车符）当成文本换行处理，破坏WAV的二进制结构。
• read代替get：read是纯二进制读取，不管内容是什么，只要有数据就读，直到达到指定长度或流结束，完美适配音频二进制流。
• gcount()获取实际字节数：确保只写入真正读到的数据，不会把缓冲区里的垃圾数据传给FFplay。
• 手动flush()：Boost.Process的输出流可能有缓冲区，手动刷新能让数据立刻被FFplay接收，避免因为缓冲导致的格式识别延迟或失败。

这样修改后，既能大幅降低CPU占用（批量IO减少系统调用次数），又能保证FFplay拿到完整、正确的WAV二进制数据，正常识别播放。

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