视频特效和声音特效都加完之后，还不算结束，因为用户真正想要的是编辑后的视频影片，而不是一幅幅的画面和一段段的声音，所以解码出的画面在经过特效叠加和处理之后，还要再一次地送给视频编码器进行编码，进而跟音频流一起，组合成新的视频影片。
预览功能上述的流程看似复杂，但它只是视频编辑的最后一步，也就是编辑器的“最终生成”的这一步，在这一步之前，必须要有人通过编辑器决定在哪一段时间加什么类型的特效。
但没有人可以凭空知道在影片的第几秒把一个什么特效恰到好处的放置进去，用户需要根据影片的具体内容进行即兴的创作和发挥，所以，我们需要把预览功能作为 P0 特性加入进去。
如上图所示，简单的预览在原理上是一个完全没有技术难度的工作，我们只需要将经过特效处理的画面和声音播放出来即可。这里真正的难点是要优化好画面特效的性能，同时做好音画同步的校对。
因为影片的预览跟单张图片的预览不同，预览过程必须是一个很流畅的体验，否则用户在编辑影片时就会有很明显的卡顿感，导致用户在使用时如骨鲠在喉，难以有好的产品体验。
而性能优化和音画同步也都很好解决，真正困难的是逐帧的画面预览，也就是用户想要看哪一帧的效果，就能立刻如愿，也就是标题里所谓的“心随手动”。
这里，我们将面对一个在技术原理上就很难逾越的困难：
逐帧预览虽然手机芯片的进步这两年可谓神速，但是功耗的限制决定了 PC 机的性能依然可以碾压手机。但不知你有没有发现，即使在性能这么好的 PC 电脑上，看电影时也会遭遇“拖拽卡顿”现象，也就是当你用鼠标拖拽进度时，能明显感觉卡顿感。
这是因为简单的视频卡顿背后，有一个巨大的性能陷阱，也即是解码器的解码规则，我通过下图来解释一下：
假设你将鼠标从第3幅画面拖拽到第13幅画面，按照表面上的理解，计算机只需要读取第13幅画面的内容，把画面显示出来就行了，这并没有什么难度。
但实际上，编码器在处理第13幅画面的时候，为了减少这幅画面的存储空间，只会保留第13幅和第12幅画面的差异部分。这也就意味着，要想看到第13幅画面，计算机需要先把第12幅画面解码出来。照此类推，要想看到第12幅画面，计算机就需要先把第11幅画面解码出来...
最终，计算机需要解码出第7幅画面，才能将上述这个循环打破，因为第7幅画面比较特殊，编码器在处理这一副画面的时候，并没有参考其它画面，所以这幅画面的内容在还原时，不需要依赖其它画面的内容（也正是因为如此，这幅画面在硬盘上的存储空间比其他画面都要大）。
当然，这里说的都是最简单的情况，由于技术的进步，现在普遍使用的编码器都已经在用 main profile 和 high profile 这种高级的编码模式，画面与画面之间的参考关系更加复杂，不仅仅参考前面的画面，也会参考后续的画面，进一步提升了复杂度和计算量。
这就解释了为什么拖拽本身的等待时间不确定，有时候你可能运气好，正好拖到了上图中的第7幅画面，那么如你所愿，画面立刻就切到第7幅；但也有可能，你拖拽到了第14幅画面，那么计算机只能认倒霉，它要把前面的7幅画面全都解码完成，才能切到你想要的那一幅画面上。
视频预处理为了解决这个问题，我们只有两条路可以走：
一条路是等待摩尔定律进步到处理十几幅画面也只需弹指一挥间的事情，但安迪比尔定理也告诉你，摩尔定律所带来的那点进步会瞬间被 4K、8K 给吃掉。
另一条路就是工程思维解决问题了，我们的做法是：如果是编辑一个已经生成好的 MP4 或者 MOV 影片，我们会先对影片进行一轮预处理，也就是影片在送给编辑器之前，先要经过一轮提前的加工处理，把视频处理的更加易于编辑。
当然，如果你认为仅仅是为了提升逐帧预览的性能就要耗费这么大的精力是不值得的，那其实是多虑了。因为我们的工程师团队会充分利用这段新引入的时间，把很多耗时但又必须要做的事情在这个阶段也完成了，比如，下面图中的预览工具条，就是在预处理过程中每隔一段时间截图拼接实现的。
