可以通过列表来估算每个环节会产生多大的延迟，哪些环节是容易产生延迟的。第一个环节是采样，如果是30帧/秒，其中会有33ms左右的间隔。这个（过程）本身也是有延迟的，因为采集有固定间隔，其固定间隔就是采样的延时。接下来是媒体的前处理，主要是ISP芯片带来的延迟，例如降噪、畸变校正等，其中的运算、数据传输都会产生延时，这部分就和它的处理能力有关，我们也可以对其进行估算。
再之后是后处理，后处理和前处理相同，都属于媒体的处理，这部分的延迟比较固定，其数值不会波动太大。而中间的网络部分（的延迟）波动是比较大的，是随着网络条件、环境变化而变化的，也和丢不丢包有关。最终的显示，解码之后进入显示缓存和显示器，显示也是存在等待延迟的。综合上面的计算，根据目前系统的能力来看，如果不计算采样延时，（延时）大概在20到几百之间。
以上就是低延迟视频的问题，下面再看下如何解决这些问题。
我把它归纳为传输和信源（两部分）。传输主要是指低延迟传输，即如何实现（传输的）快速、稳定，能抵抗丢包。信源层包括摄像头前面的处理部分，到最终的显示，如果把这一系列问题都能解决好，解决延迟问题的目标就达成了。
并行化有什么问题呢？一个是做了分块之后，Slice的压缩比也是受影响的，不仅有帧头开销，Slice之间的相互参考也会减少，就会带来压缩率的下降。还有就是视频解码时，要跨越条块边界就需要做滤波，所以解码的并行化不如编码的并行化好。所以一般是编码时做并行化，解码的并行化比较弱。然后是做图像处理时，不同条块之间有一致性的问题，比如光照强度，有区域的较暗，需要做统一的计算，才能知道别的块要怎么处理。
在传输过程中间，已经编码完的数据立刻进行传输，尽量减少等待。有多少数据立刻传输，不用等这一帧全部编完，因为按照并行化编码，数据是可以先后出来的，这样就可以减少等待。这是传输的问题。
通讯引擎本身是能够满足各种条件的。例如延迟敏感条件，或者带宽和延迟要求平衡的条件，告诉引擎有这些偏好要求，就可以通过做一些策略调整来达到最终延迟和带宽消耗的平衡。
-03-
低延迟视频应用案例
最后说一下应用场景。
还有一种是可以有一个网关，前面摄像头已采集的视频经过它做一次转码，转码之后再通过天线从基站过来，再把视频进行回传。这是我们的另外一个设备，它可以进行网关的转码或合成，画面也可以在里面合成，合成网关设备可以和前面的设备形成互补。
这个场景是在港口上。港口上有龙门吊（之类的设备），每个吊车上可以放20、30个摄像头，人都是在操控室里控制的。这种场景要求人可以切换摄像头，传过来之后还需要做一些放大，这样才能使操作时司机控制得比较好。这种以前都是用有线来做的，用光纤或网线来做，因为环境比较恶劣，有一定的维护成本。如果换成无线的这种，相对而言维护成本会降低。可以提供50-80毫秒的延迟，无线网络上的这一段大概在10毫秒，可以解决在岸桥这一场景的远程控制。它的优势在于司机控制龙门吊时可以自由切换摄像头，智能化之后生产效率还是会有一定提高的。