腾讯团队，微信中使用到的视频技术，音视频研究

小雨敲窗y

> 微信商业化
  微信商业化是三层架构：最底层是微信的社交平台，它聚集了海量的用户，这是商业化的养分；第二层是开放公众平台，它连接所有的主体（服务和内容提供方），这是商业化的土壤；第三层是业务，包括游戏、支付业务、广告、O2O、电商、企业、硬件等，这是商业化的收成。
  百度强于技术、阿里强于商业、QQ强于运营，而微信强于产品，这就必然导致几大平台走出不同的商业化道路。
-- 应用：
视频编码、图像处理和虚拟现实等。H.266、AV1以及国产的AVS2
 H.266（MPEG官方的说法应该叫FVC： Future Video Coding）属于第四代编码标准
 HEVC, AVS2和AV1等第三代标准很清晰，主要面向超高清视频应用。
> 微信视频业务
采用openal做音频渲染，sdl同理，opengl做视频渲染。
Android Multimedia框架总结案例，包含MediaPlayer,Camera等- https://github.com/hejunlin2013/MultiMediaSample
一款基于局域网开发的p2p传输的音视频对讲- https://github.com/xmtggh/VideoCalling
视频的传输，通过H264编码，rtp协议进行传输- https://github.com/592713711/Android-VideoChat
利用FFmpeg视频录制微信小视频与其压缩处理- https://github.com/mabeijianxi/small-video-record  
Android OpenGL渲染双视频（类微信视频聊天）- https://github.com/296777513/AndroidOpenGL
专访微信视频技术负责人：微信实时视频聊天技术的演进-http://www.52im.net/thread-1201-1-1.html
即时通讯的论坛- http://www.52im.net/ 
腾讯团队技术分享- http://www.52im.net/thread-1190-1-1.html
微信Android视频编码爬过的那些坑- https://mp.weixin.qq.com/s?__biz=MzAwNDY1ODY2OQ==&mid=2649286726&idx=1&sn=4fa8d24d0149c0f4ab5544c490c6a51e&chksm=8334ccc4b44345d2eaf89db485216d00ed9dbc0985005ccaa2918526ec64bd1dae9cb758ca5f&mpshare=1&scene=1&srcid=082349KUmCUESiEfyLdGMDiq&key=a36d146816aabd344dd597224ba917a4a4f9783783afbb6d4d069cb96f2bc9132f6ac43d803fe1c0c0c55c546336ee68f72f630435b7169161df8183d18b8c481f63205df62cefd2c3d6ecf30aa5eb17&ascene=0&uin=MjE4MTczNDcwMA%3D%3D&devicetype=iMac+MacBookAir6%2C1+OSX+OSX+10.12.5+build(16F73)&version=12020
微信 Android 视频编码爬过的那些坑- http://blog.csdn.net/byeweiyang/article/details/77453844
-- 回声消除技术WebRTC(http://www.52im.net/forum.php?mod=collection&action=view&ctid=5) 和 Speex
即时通讯音视频开发（一）：视频编解码之理论概述- http://www.52im.net/thread-228-1-1.html
IM实时音视频聊天时的回声消除技术详解- http://www.52im.net/thread-939-1-1.html?ref=myread
 游戏语音就是音视频社交在游戏领域的一个典型的应用。游戏实时语音中实现回声消除是必须的。
 在业界，回声消除技术是公认难啃的硬骨头。它本质上是一个复杂的数学问题的工程化。音频工程师往往是数学或者物理专业而不是计算机专业出身的.
微信团队分享：微信每日亿次实时音视频聊天背后的技术解密- https://www.jianshu.com/p/2140ee9db98a
  -- 微信多媒体团队自研的多媒体应用综合引擎——WAVE (Wechat Audio&Video Engine)。该引擎的底层——内核层是由传输、视频、音频三大类跨平台技术构成的。目前支持三类不同的应用：第一类是实时通话应用，目前用于微信的点对点和多人视频通话。第二类是多格式的图片处理，主要用在微信朋友圈、公众平台以及表情等图片的压缩和处理上。第三类是音视频文件压缩，应用于朋友圈视频、语音和视频消息的压缩和处理等。
  -- 在不太远的未来几年内，视频技术的发展方向大致有三类：
1）基础技术的突破，如 H.266、AVS3、AV1 等下一代标准，以及最近的热点研究方向——基于深度学习的视频图像压缩，压缩效率将进一步提高；
2）现有视频产品的体验提升，继续向着高质量、低带宽 / 存储空间、低功耗的方向发展；
3）新的产品形态不断出现，比如 3D、VR 甚至光场等沉浸式的视频通话。
  在微信中，对于4.0以上的机型也是采用通过注册ActivityLifecycleCallbacks接口，对于4.0以下的机型我们会尝试反射ActivityThread中的mInstrumentation对象。
  微信已经切换到Facebook的开源编译工具buck(相关介绍请见http://facebook.github.io/buck/)，编译速度得到了大大提升。
-- android端用于局域网音视频聊天
采集音视频，android本身带的硬编码对h264数据进行压缩
udp协议发送数据不能超过1500byte（具体的大约是1518byte），rtcp（实时控制流协议）
rtp传输的框架：一个是jlibrtp，一个是jrtplib
-- 即时通讯方面，也是基于tcp或udp开发的;
一款基于局域网开发的p2p传输的音视频对讲- https://github.com/xmtggh/VideoCalling
视频的传输，通过H264编码，rtp协议进行传输- https://github.com/592713711/Android-VideoChat
  RTP全名是Real-time Transport Protocol（实时传输协议），且配套的相关协议RTCP（Real-time Transport Control Protocol，即实时传输控制协议）。RTP用来为IP网上的语音、图像、传真等多种需要实时传输的多媒体数据提供端到端的实时传输服务。RTP为Internet上端到端的实时传输提供时间信息和流同步，但并不保证服务质量，服务质量由RTCP来提供。应用程序通常在 UDP 上运行 RTP 以便使用其多路结点和校验服务。
带你吃透RTMP- http://blog.csdn.net/shangmingyang/article/details/50837852
 从资源，链路、缓存、接入进行调优，并通过码率分级、IO分级、业务分级等多角度优化，有效解决蓝光、4k高码率视频的二次缓冲问题。
 音视频同步有三种，视频同步音频，音频同步视频，音视频同步到其他时钟;
> 微信音视频，通话，
-- 微信多媒体团队梁俊斌访谈：聊一聊我所了解的音视频技术- https://cloud.tencent.com/developer/article/1198270
微信多媒体内核中心音视频算法，音视频多媒体、编解码算法
 语音通话、语音消息；通话的外界声学环境因素，包括噪声、回声，混响；网络传输可靠性是非常关键的部分，网络传输存在丢包、抖动、时延等问题；多媒体内核中心自主研发的WAVE（微信音视频引擎）组件；适配不同网络传输特性的抗丢包、抗抖动算法和机制；心理声学是研究物理声学与人类听觉感知之间关系的一门边缘学科，心理声学其中一个基本特性就是掩蔽特性，其又分为时域效应和频域效应；
  AEC是回声消除器（Acoustic Echo Canceller）技术的简称, AEC是对扬声器信号与由它产生的多路径回声的相关性为基础，建立远端信号的语音模型，利用它对回声进行估计，并不断地修改滤波器的系数，使得估计值更加逼近真实的回声。然后，将回声估计值从话筒的输入信号中减去，从而达到消除回声的目的，AEC还将话筒的输入与扬声器过去的值相比较，从而消除延长延迟的多次反射的声学回声。根椐存储器存放的过去的扬声器的输出值的多少，AEC可以消除各种延迟的回声。
  很多底层芯片相关的项目，DSP、ARM、MCU、FPGA等，需要借助别人的专用平台，在别人提供的最小系统板上或自己设计的PCB上开发，硬件制（电路）板周期长。
  现在AI和语音结合得比较紧密，语音识别、声纹识别、语音合成、AI降噪等等，但处理及存储的开销、时延问题，以及AI算法在实际运行中如何做到可观可控等问题还有待进一步解决。
做好内容引擎有四个环节，包括内容的创作、内容的推荐以及围绕内容的讨论还有内容的审核。
-- 腾讯技术分享：微信小程序音视频技术背后的故事- http://www.52im.net/thread-1799-1-1.html
  以“小团队大成绩”著称的微信工程师团队很难有精力覆盖所有的应用场景.音视频上行（push）和音视频下行（play）。
  以 LCD 平板电视为例，SONY 的 LCD 产品线都没有自家的液晶面板（以台湾和大陆液晶面板为主），却能在总体效果上一直领先其它公司，其背后的秘密就是在图像处理（基于图像数据库做超分辨率显示）和背光技术（所有动物的眼睛都是对亮度最为敏感）上的不间断的积累和投入。
  如果服务器来一段数据， SDK 就播一段数据，那么网络稍微一波动，画面和声音就会表现出卡顿。我们采用抖动缓冲（VideoJitterBuffer）技术解决这个问题，就像是为网络过来的数据准备一个小的蓄水池，音视频数据先在这里暂存一小会儿再送去播放，这样就可以在网络不稳定时有一定的“应急”数据可以使用。
  既然网络不那么完美，总是时快时慢，那我们是不是可以改善一下呢？在经典的单向音视频方案中，一般采用的都是 TCP 协议，因为它简单可靠且兼容性极好。然而 TCP 的拥塞控制特别注重公平，天然就有时快时慢的坏毛病，所以我们需要用 UDP 协议替代之，相比于设计目标定位于可靠传输的 TCP 协议，UDP 可以做得更稳且更快。
-- 很多科技点：
  噪声消除：噪声抑制的目的是将用户所处环境里的背景噪音去除掉，好的噪声抑制是回音消除的前提，否则声学模块无法从采集的声音辨别出哪些是回声，哪些是应该被保留的声音。
  回音抑制：在双向视频通话中，用户自己手机的麦克风会把喇叭里播放的声音再次记录下来，如果不将其抹除掉，这些声音会被反送给对端的用户，从而形成回声。
  Qos流控：网络不可能一直都很完美，尤其是中国大陆地区的上行网速一直都有政策限制。Qos流控的作用就是预测用户当前的上行网速，并估算出一个适当的数值反馈给编码器，这样一来，编码器要送出的音视频数据就不会超过当前网络的传输能力，从而减少卡顿的发生。
  丢包恢复：再好的网络也难免会有丢包的情况，尤其是 WiFi 和 4G 等无线网络，由于传输介质本身就不是可以独享的，所以一旦受到干扰，或者高速运动都会产生大量的丢包，这时就需要引入一些丢包恢复技术，将失去的数据尽量补救回来。
小程序音视频的技术体系,实现思路就是：
 1）首先是化繁为简，将所有的音视频解决方案拆解成两个基础行为：上行和下行，并通过两个标签  和  的简单组合，实现最基本的在线直播功能；
 2）之后是通过加速线路和延时控制，将一路音视频的时延缩短到 500ms 以内；
 3）再之后，我们通过引入噪声抑制和回声消除等声学处理模块，让一路变两路成为了可能，这也就构成一个最简单的视频通话能力；
 4）最后，我们又通过加入房间服务和状态同步通知，将双路音视频变成了多路音视频，从而将应用范围进一步扩大。
-- 微信多媒体团队访谈：音视频开发的学习、微信的音视频技术和挑战等- http://www.52im.net/thread-1746-1-1.html
  微信视频通话的相关技术研发，目前的工作主要在提升微信视频通话的QoS/QoE（Quality of Experience），包括清晰度、流畅度提升，流量控制，抗丢包策略，多编码器协同编码等，近期也有关注运用深度学习方法进行在视频、图片主观质量的提升。
  微信音视频通话功能,视频编解码.多媒体技术确实涉及很多基础学科，如高等数学，数字信号处理，通信原理，信息论等。
多媒体技术, 有三点建议：
 第一，初学者需要掌握数字信号处理及信息论等基本知识，这些知识是我们进入这个行业的敲门砖；
 第二，需要了解技术的演进过程以及解决的“痛点”。具体到视频编解码上，我建议初学者需要了解视频编码标准的演进过程，从早期的H .261/263，MPEG1/2/4，到现在的H.264/H.265/H.266，熟悉每一项标准的差异点，以及在技术进步过程中想解决的问题，这样不仅知其然还能知其所以然；
 第三，最后一点，知行合一！通过对各标准的测试模型或开源软件的代码阅读，加深对技术细节的理解，通过部分模块的优化，提高自身的实践能力。如果能做到这三点，恭喜你就已经是内行人了。
[H2Head]Q：能否推荐一些学习多媒体开发的书籍或资料？[/H2]
时永方：基础知识方面推荐岗萨雷斯的《数字信号处理》，东南大学的《信息论与编码》，编码基础方面推荐Wiley的《THE H.264 ADVANCED VIDEO COMPRESSION STANDARD》或国内毕厚杰老师的《新一代视频压缩编码标准H.264》，最新的标准可以看相关的标准文档。
 微信视频通话的QoE提升：“三高”（高帧率、高分辨率、高质量）优化；流量控制优化；弱网优化；
 微信视频通话已经解决了80%场景下的QoS/QoE问题，剩下的20%仍需要我们不断地一点点打磨、优化。在视频通话上根据不同分辨率、不同的网络特点、设备性能选择合适的软/硬件编码器协同工作。简要来说，在网络较差、分辨率较低时，我们采用自研软件编码器，具有更强的传输适应性，在较差网络中降低卡顿；在网络较好、硬件编码性能良好的设备上进行高分辨率视频编码时，我们采用硬件编码器编码，可以降低高清视频编码的延时以及减少手机的发热。
-- 录制小视频：
Camera -> YUV帧序列 -> YUV帧处理（镜像，缩放，旋转） -> 编码器  -> H264数据
大体上就是从摄像头输出的YUV帧经过预处理之后，送入编码器，获得编码好的h264视频流。
上面只是针对视频流的编码，另外还需要对音频流单独录制，最后再将视频流和音频流进行合成出最终视频。
微信每日亿次实时音视频聊天背后的技术解密- http://www.52im.net/thread-1311-1-1.html
 AVS、H.264SVC 等视频编解码标准技术研究。微信视频通话、朋友圈视频图片等业务相关的视频图像技术研发和团队技术管理。
  四类互联网视频应用:视频通话，短视频分享，流媒体直播，媒体存储。目前支持三类不同的应用：第一类是实时通话应用，目前用于微信的点对点和多人视频通话。第二类是多格式的图片处理，主要用在微信朋友圈、公众平台以及表情等图片的压缩和处理上。第三类是音视频文件压缩，应用于朋友圈视频、语音和视频消息的压缩和处理等。
  现在微信视频通话是基于微信多媒体团队自研的多媒体应用综合引擎——WAVE (Wechat Audio&Video Engine)。该引擎的底层——内核层是由传输、视频、音频三大类跨平台技术构成的。
 视频编解码的核心指标概括起来一般有三个：编码效率；编解码速度；传输适应性。
 码率控制的难点是平衡码率平稳性和压缩效率、质量平稳性。虽然学术上有很多码率控制的研究，但实际工程应用中还是有很多问题需要考虑，如码率控制的时间单位，极低帧率、极小 I 帧间隔下的码率控制，单帧瞬时冲击等。
  信源容错和信道容错两类方法：信源容错可以通过改变参考关系；信道容错的方法有信源容错可以通过改变参考关系来提高在丢包环境下的视频解码正确率。
视频技术的发展方向大致有三类：
 1）基础技术的突破，如 H.266、AVS3、AV1 等下一代标准，以及最近的热点研究方向——基于深度学习的视频图像压缩，压缩效率将进一步提高；
 2）现有视频产品的体验提升，继续向着高质量、低带宽 / 存储空间、低功耗的方向发展；
 3）新的产品形态不断出现，比如 3D、VR 甚至光场等沉浸式的视频通话。
  MediaCodec在初始化的时候，在configure的时候，需要传入一个MediaFormat对象，当作为编码器使用的时候，我们一般需要在MediaFormat中指定视频的宽高，帧率，码率，I帧间隔等基本信息，除此之外，还有一个重要的信息就是，指定编码器接受的YUV帧的颜色格式。这个是因为由于YUV根据其采样比例，UV分量的排列顺序有很多种不同的颜色格式，而对于Android的摄像头在onPreviewFrame输出的YUV帧格式，如果没有配置任何参数的情况下，基本上都是NV21格式，但Google对MediaCodec的API在设计和规范的时候，显得很不厚道，过于贴近Android的HAL层了，导致了NV21格式并不是所有机器的MediaCodec都支持这种格式作为编码器的输入格式！
微信Android版小视频编码填过的那些坑- http://www.52im.net/thread-1173-1-1.html
视频图像的超分辨率技术原理和应用场景- http://www.52im.net/thread-1377-1-1.html
  视频图像的超分辨率技术。图像超分辨率就是提高图像的空间分辨率，例如将一幅图片的分辨率由352x288扩大到704x576，方便用户在大尺寸的显示设备上观看。
  超分辨率技术可以分为以下两种：
 1）只参考当前低分辨率图像，不依赖其他相关图像的超分辨率技术，称之为单幅图像的超分辨率（single image super resolution），也可以称之为图像插值（image interpolation）；
 2）参考多幅图像或多个视频帧的超分辨率技术，称之为多帧视频/多图的超分辨率（multi-frame super resolution）。
  视频图像超分辨率问题一直是一个开放性问题的原因（逐渐逼近符合人眼视觉认识的解）。原图压缩方案A，即原始高分辨率图像直接通过编码器进行压缩和传输，在解码端直接得到原始分辨率的重构图像。基于上下采样的图像压缩方案B，即图像首先经过一个分辨率下采样（宽高均为1/2倍）的预处理方法，再将得到的低分辨率图像利用相同的第三方的编解码器WebP进行压缩和传输，最后将在解码端得到的低分辨率图像利用超分辨率技术重建出其高分辨率的图片（这里超分辨率技术选用Google在G+上的方案和一种经典的深度网络的SCN方法）。
  在低码率范围内，采用原图压缩方案的压缩效率要低于基于采样的图像编码策略（即同等质量下，基于采样的图像编码策略图片文件更小，节省带宽），而在中高码率范围内，采用原图压缩方案的压缩效率要优于基于采样的图像压缩方案（即同等质量下，超分辨率的图像编码策略的图片文件更大，浪费带宽）。
  视频图像超分辨率技术在应用中要考虑计算复杂性限制，传输带宽的限制和视觉性能上限（主观视觉效果）等因素，来选择恰当的应用场景。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！