（旧）系统实现

# 前提条件

• [x] 编码时在指定位置插入关键帧
• [ ] 传输时抽取关键帧压缩数据包
• [ ] 单独解码关键帧数据包

# 延迟

The followings are the key factors when you have to calculate total latency for a WebRTC call:

• Network latency. Depends on network link quality and distance (it should be below 50 milliseconds within a country or above 100 msec between continents)
• Network bandwidth and QoS: packet drop or insufficient bandwidth might trigger more latency
• Audio latency: depends on OS, audio hardware and driver (it is below 20 msec on iOS and Windows, but on Android and Linux it can be more)
• Jitter buffer: every VoIP software maintains a varying length of jitter buffer to compensate network delays/spikes (usually between 0 and 100 msec)
• AEC and FEC: acoustic echo cancellation and forward error correction might introduce a one packet delay (usually 20 msec)
• Other factors: there can be also other factors which has an impact on the overall latency, such as a busy CPU and software implementation details
• As per my experience, currently available WebRTC stacks (such as Chrome) are performing very well with minimal latency.

The total latency should be below 300 milliseconds if you are calling somebody within the same country or up to 600 msec for long distance calls to abroad. Above 600 msec you will perceive as uncomfortable.