FreeSWITCH的clone机制通过共享信令、分离媒体处理实现播放与录制并行：原始通道专注实时渲染，克隆通道禁用音频、定向录制视频，复用解码上下文避免重复开销，确保低延迟与资源隔离。
用一份视频流同时交给播放器渲染和本地录制，核心在于“不复制原始数据、不阻塞主流程”，而流的克隆体（如 FreeSWITCH 的 clone）正是为此设计的机制。它不是简单地把媒体流拷贝两份发出去，而是让原始通道与克隆通道共享同一套信令控制，各自独立处理媒体——一个专注实时渲染，另一个专注写入磁盘。
克隆通道如何分离渲染与录制职责
克隆后，原始通道仍保持完整双向音视频交互（比如 WebRTC 播放），而克隆通道可被“定向改造”：关闭音频输出、禁用远端渲染、只提取视频帧送入录制模块。关键不是复制流，而是复用解码上下文或原始 RTP 包，避免重复解码开销。
- 在克隆通道中设置变量
ignore_early_media=true和execute_on_answer=video_recorder，确保它不参与通话建立阶段的媒体协商 - 通过
set应用禁用音频：set ignore_audio=true，让克隆通道只处理视频流 - 调用
record_video（需mod_av）时指定仅写入视频轨道，不混入音频帧，输出为标准 MP4 或 MKV
播放器端同步渲染的保障要点
原始通道的播放器（如 HTML5 Video 元素或 VLC）必须使用低延迟解码路径，且不能受克隆通道资源调度影响。常见干扰源是共享的解码器实例或显存缓冲区竞争。
- 确保播放器使用硬件加速（
vaapi/dxva2/videotoolbox），与录制端的软解路径隔离 - 在 WebRTC 场景中，为原始 PeerConnection 设置
rtcpMuxPolicy: "require"和iceTransportPolicy: "all"，避免克隆通道的 ICE 候选干扰主连接 - 若用 FFmpeg 接收流，原始通道走
-an -sn（禁音频/字幕）+-vsync 0（帧率自由），克隆通道走-vn（禁视频）+ 录制音频，实现真正分流
本地录制保存的稳定写入策略
克隆通道的录制不是“边拉边存”，而是构建带时间戳对齐的 AVPacket 队列，再批量写入封装器。这样能规避网络抖动导致的 PTS/DTS 错乱，也便于后期校验完整性。
- 使用
av_interleaved_write_frame而非av_write_frame，保证音视频包严格按时间戳交错写入 - 录制前预分配文件头（
avformat_write_header），避免录制中断时生成损坏文件 - 对 RTSP 或 HLS 流，克隆通道应主动请求 I 帧关键帧（如发送 RTCP FIR），确保录制起始点可随机访问
资源与同步的实际边界
克隆不是零成本。每个克隆通道会占用独立的解码上下文、内存缓冲和线程调度资源。但只要控制在合理数量（例如单流最多 2~3 个克隆），就不会明显拖慢主通道。
- 避免在克隆通道中执行耗时操作（如实时转码、AI 分析），这类任务应交由后续异步服务处理
- 原始通道与克隆通道的音画同步靠共享同一个
clock source（如 NTP 校准的系统时钟或 RTP 时间戳基线），而非互相等待 - 录制完成时，克隆通道应主动触发
uuid_record_stop并释放资源，防止残留句柄占用磁盘空间
