流式二进制合并适用于满足全部前提的碎片化媒体：同源、未加密（或已解密）、编码参数一致、首片含完整文件头且后续为纯帧数据；否则需转码、解密或转封装。
流式二进制合并的核心是不加载整个文件到内存，而是按顺序读取源片段、实时写入目标文件，实现低内存占用、无损、快速拼接。它特别适合处理网络下载的碎片化媒体（如B站缓存、m3u8分片、HTTP Range切片等），前提是所有片段本身结构完整、顺序正确、且无需解密或重编码。
确认适用前提：哪些情况能直接流式合并？
不是所有碎片都能“一拼了事”。只有满足以下全部条件，才能安全使用纯二进制流拼接：
- 所有片段属于同一原始媒体流（例如同一条TS流、同一个fMP4序列）
- 片段未加密，或已提前完成解密（如用MP4Decrypt处理过）
- 视频/音频编码参数一致（如H.264 Profile、采样率、声道数），避免播放器解析失败
- 首片段含完整文件头（如moov、ftyp），后续片段为纯mdat或连续帧数据（fMP4常见）；若每个片段都带独立头（如普通MP4），则需FFmpeg concat等封装层介入
执行流式合并：两种主流方式
根据环境和需求，可选择轻量代码或专业工具：
-
命令行（推荐FFmpeg concat）：创建文本列表file_list.txt，每行写一个绝对或相对路径（Windows注意反斜杠转义），然后运行：
ffmpeg -f concat -safe 0 -i file_list.txt -c copy output.mp4
其中-c copy确保零重编码，-safe 0允许非标准路径 -
Python脚本（适合自动化集成）：用
File.open()逐个读取二进制流，output_stream.write()顺序写入，不缓存全量内容。关键点是跳过重复头（如非首片段的moov box）、校验末尾是否对齐（避免截断帧）。示例逻辑：
→ 打开输出文件（with open("out.mp4", "wb") as out）
→ 遍历输入文件列表：
∙ 若是第一个文件，完整写入
∙ 若非首个，跳过前若干字节（如跳过ftyp+moov，约几千字节），再写入剩余部分
绕过常见陷阱：顺序、头信息与完整性
实际操作中，出错往往不在合并动作本身，而在前期准备：
- 务必按播放顺序排列文件名——很多缓存系统用数字后缀（
seg-1.ts,seg-2.ts），但B站缓存可能用哈希命名，需依赖.index或时间戳排序 - 不要手动删头再拼：fMP4分片通常以
moof+mdat结构循环，首片含ftyp+moov，后续只需拼moof+mdat块；盲目删除可能破坏sync sample表 - 合并后用
ffprobe output.mp4检查时长、流数量、关键帧分布，确认无卡顿或音画不同步
什么情况下不能只靠流式合并？
遇到以下任一情况，纯二进制拼接会失败或输出异常：
- 片段来自不同分辨率/帧率的源（如720p混入1080p），必须转码统一
- 含DRM加密（如Widevine），需先调用Shaka Packager或mp4decrypt解密
- 格式混杂（MP4 + MKV + TS），需统一容器或转封装
- 需要插入转场、字幕、音频混音等编辑操作，应进入剪辑软件（如Pr、剪映）或用FFmpeg加滤镜链
