双摄视频的音画为什么会不同步

一个视频文件靠什么把声音和画面绑在一起

视频文件里存的不是一条连续的流，而是两条：一串视频帧和一串音频采样，各自都标着相对同一个时钟的时间戳，播放器就是照着这条共同的时间线，决定某一刻该显示哪一帧、该放哪一段声音。只要两条轨道的时间戳来自同一个时钟，而且录完之后没有什么东西去动它们，这两条轨道不管播多久都会锁在一起。

所以不同步这件事，说到底说的是时间戳出了问题，不是声音或画面本身出了问题。要么两条轨道从一开始就不是照着同一个时钟打的戳，要么是录完之后——二次编码、剪辑、带着自己延迟的播放链路——把其中一条相对另一条挪动了。

为什么一份合成出来的文件不会有多摄像头素材那种老问题

大家在多摄像头拍摄里最常遇到的同步问题，说到底是两个独立文件的问题：一段前摄素材、一段后摄素材，各自由自己的设备或自己的采集链路录下来，各自跑在自己的时钟上。这两个时钟哪怕差一点点，拍得越久累积得越明显，这正是真正的多机位制作要靠打板、共用时间码或者对轨音去给剪辑师一个「这一刻两段素材肯定对得上」的锚点的原因。

实时合成的双摄 App 从一开始就不会走到这一步。前后两路画面在到达的那一刻就被画进 GPU 上的同一帧，而这一帧——连同麦克风在同一时刻收到的声音——才是被写进文件的东西，走的是同一个采集会话、同一个时钟。这里不存在另一段素材的时间戳可以拿来漂移，因为一份合成出来的录像从头到尾就只产出一条视频轨和一条音轨，装在同一个文件里。

真正的不同步从哪儿来

发送途中的二次编码

聊天软件、社交平台和大多数分享工具在发送视频之前都会重新编码一遍，用画质、有时也用精确的帧时间去换一个更小更快的文件。一次正常的重新编码不会破坏同步，但如果这个过程被打断——上传卡了一下、App 处理到一半崩溃、分享超时后又重试——就可能让两条轨道的时间戳相对彼此挪了个位。这是现实中最常见的原因，而且发生在录制之后，不在录制过程里。

剪辑软件用错了帧率导出

把素材拖进剪辑软件，导出时用的帧率和原素材对不上，是给一份本来没问题的文件平白引入漂移的经典操作。音轨照常速播放，视频轨却被悄悄拉伸或压缩去凑另一个每秒帧数，两者的差距会随素材变长而越拉越大。导出前把项目帧率和原素材对齐，这个问题就不会出现。

延迟来自你看它的方式，不是文件本身

有些播放链路只在声音这一侧多加了一点延迟——常见的是蓝牙音箱或者电视自己的音频处理——完全不碰文件本身。这种情况的表现是从第一秒到最后一秒偏移量都差不多固定，而不是随时间越拉越大，这正是用来判断「文件本身没问题，延迟来自播放这一端」的标志。

怎么分清楚是哪一种情况

打开原始录像真正存放的地方——DualCam 自己的媒体库，或者直接存到「照片」里的那份拷贝——先看开头一段，再看一分钟之后的一段。如果那里始终对得上，说明源文件没问题，问题出在你用来发送、剪辑或播放那份对比拷贝的环节上。如果差距在录制它的那台设备上、看原始文件时就在不断拉大，那就是另一回事了：长镜头在高负载下可能会在固定 30 帧的上限里出现卡顿，这个值得单独去了解，而不是当成音频问题来处理。

DualCam 写出来的文件就是上面说的这个结构：一条合成好的视频轨，一条单声道音轨，一起创建、录制结束的那一刻一起收尾。之后不需要去对齐什么，因为它们从一开始就没有分开过。