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 并释放资源，防止残留句柄占用磁盘空间