我们使用的是UDP的协议，它有没有弊端？必然有的。TCP是最稳定的协议，丢包之后会大量重传，而UDP并没有这个机制，丢包就丢包了。所以如果没有QoS质量保证，音视频没有办法听，丢了大量的数据，对面收的数据是不完整的。我们在腾讯云内部做了很多事情，首先我们做了FECW前置校准，也就是在发送端先冗余了一些包，如果接收端发现丢包了，可以通过冗余的包，通过差分算法，将丢失的包补出来，我不需要重新请请求一次，让他把包发过来，这样避免重传。为了质量稳定性。所以我们在UDP的基础上，补做了丢包重传的机制。
然后是信源的保证。一个音视频的帧是由I帧和P帧构成的，它送到编码器之后，是从I帧、P帧送给编码器，形成一系列的视频动作。传统的做法有一个巨大的弊端，其中一个P帧丢了，后面的P帧没有办法用了，因为这个P帧是参考前面的P帧。如果这一帧丢了，后面所有帧都没有用。我们做了一下改进，做了好几个SP帧，所以单纯的一个SP帧是参考前置的SP帧。如果一个SP帧丢了，是没有影响的。后面是参考新的SP帧。所以这个对抗丢包性，做了大大的加强。
当你在网络不好的情况下，服务器会自动降低帧率，调整自己的发动策略。通过我们的流动策略，通过RDT协议，上传到CDN。接收端也一样，通过CDN扩到最近的一个节点，传到的学生端，做延迟修正，做编码解码和渲染。
为了保证客户端达到足够快的策略，我们做了很多工作。我们最核心突出的是目前快。但其他方面我们还做了自适应网络抖动，当您的下行丢包率超过65%的时候，我们保证声音是基本稳定的。上行丢包35%也同样如此。我们支持25fps、720p的配置。我们有首帧秒开功能，是指我们在最近的服务器上面缓存了上次的数据，你再进的时候，会拉到上次的画面，让你感觉到第一画面不是黑屏。
我们还做了一些避免拥塞的策略，可以保证自己的流能够稳定地向外输出。我们做了很多跟质量相关的监控，可以实时看到当前用户的音频质量、视频质量、丢包率、CPU等信息。现在我们来讲讲的是我们搭建的核心节点的框架。腾讯云这边的音视频是按照两种结构走的，DC代表核心节点，OC是边缘节点。所以DC一般部署在离三大运营商近的地方，它的连通率是4个9，而OC差一点，一般只有2个9。所以标准的直播链路是这样走，先走最近OC，然后再走DC，然后通过跟相关的DC值连，然后再通过边缘节点扩散。这样的话链路非常长。我们现在做的加速链路，上行的UDP的包，直接找到最近的OC，然后直通光纤，这样速度会节省很多。在互动课堂这块最重要的就是互动的延时比较多，很多在做在线教育的时候，传统的问题延迟太大了。讲课都讲了两三秒了，你才能看到，很难做互动。视频和白板数据是挺快的，你给学生说，答一下现在白板的题。你的声音还没有过去，白板的数据已经过去，完全不同步，他可能还没想到问题，这是一个完全不同步的状态。
在视频互动这块，A的主播刚刚通过保证上行流量的情况下直联到B，B的连麦用户，也是直联到A。但是B是连麦观众，优先级并没有B这么高，仅仅能保证音频。为了兼容分发，如果你是观众，你看他们两个聊天，同时去拉这两路流过来，这样你的带宽成本很高。所以我们做了云端混流，我们腾讯云内部实时把这两路流混成一个标准协议，你可以拉出来，只有一路流的方式。所有观众就可以通过一路流来看他们两个人的聊天。
这是一个老师通过学生端，在腾讯云互动课堂上的解决方案。老师推流到腾讯云，腾讯云首先做了一个Upload集群，转码，转成标准协议，然后再CDN扩散。若不走转码，可以直接走点播系统。为了简化设置，我们开发了一套web配置页面，比如你要配置它的码率、分辨率、帧率，都可以控制。这就是实时音视频的解决方案。
