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

你遇到的问题核心在于二进制流的读取方式错误，以及逐字符IO的系统调用开销问题，下面分别拆解并给出解决办法：

1. 逐字符复制CPU占用高的原因 #

逐字符的iso.get()和in << c每次只处理1字节数据，这会触发大量的内核态/用户态切换（每个字节都要做一次系统调用），CPU自然会被频繁的IO操作占满——这种方式完全不适合二进制流的批量传输。

2. 缓冲区复制失效的原因 #

你用的iso.get(buffer, 1024)是面向文本的读取方法，它会一直阻塞到遇到换行符、EOF或者缓冲区填满才返回。但WAV是二进制流，不会包含换行符，所以这个调用会一直等ffmpeg进程结束，才会把所有数据一次性传给ffplay。而ffplay需要流式的实时输入，一次性接收全部数据（或者长时间没有数据）会导致它无法识别有效的WAV格式头，自然无法播放。

正确的缓冲区批量复制实现 #

改用二进制模式的read方法读取实际字节数，再写入对应长度的数据到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) {
        // 写入实际读取的字节数，而非整个缓冲区
        in.write(buffer, bytes_read);
        // 强制刷新输出流，确保数据立刻发送给ffplay
        in.flush();
    }
}

关键细节说明： #

• 用read而非get：read是二进制流专用的读取方法，不会被换行符阻塞，会尽可能读取缓冲区大小的数据后立刻返回。
• 获取实际读取字节数：gcount()能拿到本次read实际读取的字节数，避免写入缓冲区中未被填充的垃圾数据。
• 主动flush输出流：Boost.Process的opstream默认可能有内部缓冲，不主动刷新的话，数据会攒到一定量才发送，导致ffplay长时间收不到数据而报错。
• 循环条件包含剩余数据处理：ffmpeg进程结束后，管道里可能还有未读取的残留数据，iso.peek() != EOF确保这些数据也能被读完并传给ffplay。

这样修改后，既能大幅降低CPU占用（批量IO减少系统调用次数），又能保证ffplay实时接收流式数据，正常识别WAV格式并播放。

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