随着移动互联网的快速发展以及智能终端性能的逐步提高，智能终端间进行实时音视频通讯成为移动互联网发展的一个重要方向。实际上，实时音视频通讯 = 音视频处理 + 网络传输。包括采集、编码、网络传输、解码、播放等环节。这么多项并不简单的技术应用，如果把握不当，将会在在实际开发过程中遇到一个又一个的坑，本文将就几个典型问题给出简要的参考建议。
主流的是H.264编码器，开源的编解码器实现主要是x264和openh264，其中openh264是思科开源项目，针对实时视频通话场景做了优化。另外Google的vp8也针对移动端也做了很多优化（VP8（最新版已经是VP9了）是Chrome的默认编码格式）。
说说关于H.264的专利授权题外话：
H.264又称作MPEG 4 Part 10，和MPEG 2一样需要授权费，并统一由MPEGLA这个专利联盟管理收取（H.264这样的标准实际是一大把专利技术的合集，当然也不可能全由某个公司持有，所以为了合作共赢大家都把专利拿出来成产了个所谓的联盟，访止大家打架都捞不着好）。使用MPEG 4标准比编码/解码都需要付授权费，一年产品总算在10万个以后时免费，但超过10万个的时候，每个产品将收0.2美金的授权费，超过500万时，授权费降为0.1美金，上限则是500万美金。
但线上免费内容，如YouTube等视频网站可免费使用到2016年。但如果提供租借电影，像NetFix，就要依照用户数量收取授权费；如果用于PPV(Pay Per View)以及VOD(Video on Deman)，像是MOD与BBTV数码有线电视上的收费电影，超过12分钟的内容，也要收取售价的2%授权费。最多以500万为上限。
看看上面这样的授权费用，大家都是技术公司，当然会有人不爽，所以也就催生了很多开源方案（当然要做好没那么容易），这其中Google的抗拒最为激烈。关于Google和微软+苹果音视频标准之争是个很热的话题，有兴趣不访百度一下，了解更多情况哦。
如果采用软件编码，那么会比较耗费cpu资源，表现出来就是设备发烫，耗电快，但是设备兼容性好，几乎可以在任何设备上运行。即时通讯聊天软件app开发可以加蔚可云
如果采用硬件编码方式，那么编码性能好，完全可以支持1080p图像全高清的实时编码，而且也省电，但是设备的适配性比较差，特别Android设备的硬件编码模式支持的比较差。ios设备支持的适配性比较好，但是，没有开放更底层的编码接口，难做到按帧获取码流，进行实时直播。另外用硬件编码方式，也比较难做动态码率控制。
针对网络直播和点播场景，在编码阶段要尽量做到码率波动的平滑，这个需要优化码率控制算法。
如果关键帧之间的间隔小，那么码率会出现频繁的尖峰，发送数据的时候，会造成瞬间的拥塞。
可以通过设置buffer来解决码率波动问题，比如在推流端增加一个发送缓冲区，按照固定的码率发送数据，而不是根据每帧数据来发送。
同样在播放器也可以设置一个接收buffer，解决网络波动对播放造成的频繁卡顿。但是这个设置过大的buffer会增加延时，不适合直播应用，比较适合点播应用。对于直播场景，要求端到端的延时尽量小，播放端能快速启动，看到画面。
对于rtmp直播还要解决累计延时，可以采用在播放器主动清空buffer的方法。
不管是直播还是点播服务，都存在一个端到端的数据传输链路问题，在推流端先要连接到接流服务器，这时就要选择合适的节点，一种是根据客户端的DNS域名来选择就近的节点，当DNS配置有误的时候，可能会存在调度不准的问题。
另外一种是根据客户端的出口IP来选择节点，这种调度方式会比较准确一些。同样对于播放器端也是采用类似的方式来选择流媒体服务器集群的边缘节点。
在整个直播或点播过程中，最好有实时统计数据，包括网络类型，机器信息，实时网络状况，帧率，码率，分别率等。这样可以分析遇到的各种问题，特别是对于直播场景，当网络波动，出现卡顿时，可以为动态调整qos提供依据。
对于实时音视频直播场景，采用qos策略，动态调整编码参数。包括帧率，码率，分辨率，缓冲区。当直播出现卡顿，采用快降慢升的策略，当网络波动比较厉害，这样可以避免编码参数频繁的来回调整，造成恶性循环。
当进行编码参数调整时，一般是根据分辨率把码率，帧率分成几个档次，然后在根据一定时间段内的统计数据，在这几组参加集会之间进行来回切换，确保音视频流畅的同时，尽量提高图像质量。