作者介绍：况鹰，腾讯android高级工程师，目前主要负责手Q个性化增值及企鹅电竞pc助手业务开发与性能优化，在android和pc端都有丰富的经验，闲暇之余比较爱折腾和研究各种新技术。
接上一篇《obs源码分析第一篇 ：踏石留印》简单介绍了obs的由来和工程构成，这一篇我将剖析一下obs二代的代码内部，就不来文艺气息了，直接上猛料。本文将按照数据源的获取、渲染、推送的直播流程来让大家深入了解一下。
1、直播源数据获取
obs在启动时会优先加载 libobs 核心库，这个库初始化 obs 很多内容，包括crash 模块、com、性能监控等。初始化后会加载多个 module （windows下可以理解为dll），一般而言一个 module 对应一个功能特性，每个 moudle 加载时会初始化一些静态函数地址用于处理特性。
特性通过 id 来区分，如主播插入图片时，会调用 id 为“image_source”的moudle 函数来处理，并相应的增加一个对应的 source 对象。
对于外部调用接口而言，所有 module 的数据函数名称基本一致（对于不同type 略做调整），比如 video 类型的直播源数据对外接口长下面这样：
这样做的好处是有利于第三方贡献者接入，如果想加入一个新的直播源类型，只需要仿照已有 module 增加类似的特性处理函数而不用更改主程序框架。当然如果不习惯 C 语言，也可以切换为 C 用成员函数地址代替静态函数地址，其它语言依次类推。
2、直播源数据管理
对于直播源数据，obs 首先会建立其一个场景 (scene) 的概念，过程类似于开演唱会搭舞台。舞台场景中有很多部件 (scene_item) ，主播在直播时可以根据需要择时删除、隐藏、添加场景中的部件，管理非常便捷。基本数据结构如下：
obs 除了支持单个场景，也支持同时搭建多个场景，主播可以在场景间过渡切换，不过直播难度也会增加。对于观众而言观看直播犹如观看了一场演唱会，可以发弹幕尖叫呐喊。
3、直播源数据渲染
在obs初始化时会根据直播源类型对数据做一个分类，每一类数据对应相应的channelID，如 scene 对应的 channelID 为 0，麦克风对应的 channelID 为3，目前默认配置了6 个通道，分别用于 scene 、桌面音响、麦克风，最大可拓展为64个：
obs 在初始化时会开启一个 video 和 audio 线程用于定时更新数据，以vide o为例，对于每一个预览界面，首先会 new 一个 display 对象用于关联UIcallback 函数和 video 线程，直播时 video 线程定时更新会调用 UIcallbac k函数，触发场景和 UI 的绘制与刷新。大概流程如下：
（黄色代表线程，蓝色代表对象）
最终渲染会传递到每个scene_item，每个scene_item会绑定一个 texture，texture 对应的便是主播看见的直播画面，在调用 callback 之前会先调用 dx 或 opengl 更新这个 texture 。texture 绘制的顺序跟scene_item的顺序有关，scene_item以链表的形式串联起来，采用尾部插入的方式置入新直播源，外在展现便是越晚置入的直播源数据越在上层，主播调整直播源数据的顺序也就是调整链表的顺序。
4、直播源数据推流
有了直播源数据，主播端可以看见渲染的直播缓慢。但这还不够，只有推送到后台才能展现给更多的观看用户。在直播源推送时会首先创建推流 video 和 audio 的 encoder 对象，并创建 output 对象管理 encode r对象，绑定 encoder 对象与 video 、audio 数据源最后使用 rtmp 或者 flv 推流，关系如下：
对于目前常见的 rtmp 推流过程，主要分为三个步骤：
- 创建connect线程连接服务器，初始化rtmp模块；
- 连接服务器成功后创建send线程并开启hook数据；
- send线程根据信号量来控制是否发送数据，信号量在hook时会重置；
其中 hook 数据的过程可以理解为关联数据采集和数据发送，如下图所示：
（黄色代表线程，蓝色代表对象）
video 和 audio 对象都会绑定回调函数，当 video 与 audio 线程检测到内容有更新时，会根据是否需要编码触发不同的回调函数对数据进行处理，最后序列化后通过 rtmp 打包发送到后台。
总结：
obs的整个开播过程都是围绕数据源展开的，代码核心部分由C语言编写，UI层则用的C 11。数据更新回调较多，除了QT的singal和slot的通信机制，也有一部分是作者自己的，看代码时全局关联会比较容易懂，如果对obs有兴趣的同学可以一起学习交流。
