再说baseline做强交互不利因素之前，先说说现在直播的场景情况。
场景如上图，推流段不是移动平台，就是PC机。当然最近几年也出现专门用来推流的定制盒子，本质不是一个嵌入式windows，就是一个android设备（android设备较多）。
- 而对于PC机作为推流端来说其实问题并不大，只要在保证带宽足够理想的情况下，采用264的任何一种profile都能尽可能的做到最大延时接近编码器固有延时的效果。同样对于使用何种容器来说问题都不大。
- 但对于移动设备来说，需要匹配的情景就很多了，主要是由于移动设备的电池续航能力、操作系统小类别太多、整体性能表现。在使用264编解码时，一般尽量采用硬编解码，对于实在没有办法的情况下才使用软编解码。就仅仅一个硬编解码上就存在诸多差异，例如有些profile硬件不支持，或者rom上存在一些问题导致本该支持的profile，支持的不好或者根本不支持。
- 除了上述提到的问题以外，其实还有一个隐形问题，那就是用户使用习惯问题。现在的用户越来越偏向于使用web方式展现的产品，一方面对于开发者来说，界面改动较为简单灵活，另一方面对于用户来说，只需要打开浏览器即可，简化使用步骤。
然而上述提到的这些问题，就造就了可能大家会想到flash、h5和native应用，对于native应用来说还好，开发起来虽然周期长，但可塑性比较强。对于flash和h5来说可选择余地就非常小了。
暂时不说flash和h5本身在做双向强交互直播是否可行，先说一说两者采用的协议类型。对于flash来说：
- 通讯协议为rtmp系列协议（包括rtmpt等），协议本身并不是太复杂，但涉及当初并不是用来做双向强交互的直播协议，因此协议本身就没有在双向强交互上做太多的考虑。
- 由于协议本身所承载的流媒体容器格式为flv或f4v，现在大部分直播平台基本采用的是flv作为容器，同时flv也是一种较为简单易用的容器
- 但由于flv容器格式的限制，在adobe官方手册中就已经说明，flv容器支持的264的profile范围中，目前仅对baseline、extended、main、high、high10、high4:2:2、high4:4:4，在经过简单测试之后，如果不考虑flash端推流的情况下，用户电脑（移动端一般用h5，不用flash）性能具备一定保证的情况下，再根据官方手册并测试(as3手册)，没有实际去测试过high10，不过脑补得知high10也是可以的，但延时太大，也有可能会引起其他flash异常。因此往往最佳的选择就在baseline、main、high中选择，因为他们的颜色编码是8bit的。从解码效率和广泛性来说，这三种都可以。
- 但由于是双向直播，因此，在这时就需要考虑编解码器的时延问题。这时，大家一贯的做法就是关闭B帧编码，这样即可极大的提高编解码延时。当关闭了B帧编码之后，剩下几种profile互相比拼的就是在给定的一个平均分辨率、gop的情况下，编解码固有时延和数据码率，以及支持的广泛性。实测之后发现high其实在不同浏览器的flash上表现存在一定差异，主要情形为编解码速度、性能开销等等。因此在flash上使用high这种方式时，还需要综合考虑。
接下来说一说h5方式的直播：
- h5方式的直播一般是通过websocket进行通讯，协议是hls，容器格式为ts、ps。然而我对hls和ts、ps都不是很了解。
- h5支持还有待进一步推广，目前在较新的chrome系浏览器和较新的firefox浏览器上均支持较好。IE系暂时较弱（我把edge理解成IE系）。
- 就目前来说，从开发手机端开发难度，和各手机厂商的支持力度上，无论是webview app还是native app来说，hls+ps/ts也是较优选择。
- 通过看了苹果官方的FAQ得知，hls协议似乎仅仅支持baseline、main、high三种，不清楚是由于ts、ps容器特性导致的，还是hls协议特点。因此在决定使用哪一种profile时，又回到了和flash一样的情况下。
通过以上可以得知，实际上在使用x264编码时，最终在profile的选择上基本就限制在了baseline、main、high三种。从算法复杂度上来上讲，baseline是最为简单，而high是较为最为复杂（主要是预测模型比前两者多不少）。
不过在实际工程应用中，我们还是做了一个比较脑残又没有办法的决定，那就是使用baseline。原因有二：
- 我们使用的编码库是openh264，早期版本的openh264宏块分割方式较小，也仅仅支持baseline，对main也只是仅限于试验阶段。
- 在同样的profile级别下，参数大致相同的情况下，openh264的编码时延比x264的utral模式下略高，但码率略低（未做定量测试，简单定性测试得到的结论）。编码完的数据解码出来的视觉感受差别不大，反正都是渣画质。
考虑到使用场景和当时网络的大环境，确实选择openh264，即是无奈的选择，也是一个极其脑残的选择。说无奈主要是现实，说脑残是因为压根就没有做过定性分析。。。。。。
然后接下来就开始“数落数落”baseline不适合做双向强交互直播的原因。在看x264的代码时，偶然对编码中的预测做了少许的了解。
—- 我是装逼的分割线 1号 —-
传统上对一副图像的处理，一般的理论是基于“分割”，由于图像一般情况下具有前景和后景之分，也就是说，前景和背景之间存在着大量的局部图像细节，对于图像压缩中的思路往往是，尽量将相似的区域用差别不大的统一一个区域去表达，对于差异较大的区域，尽量在用较多的数据量去存储以此保留图像的局部细节。
那么就会存在如何分割图像的问题。如果是一副简单单值图，例如大学时代我做的非矢量图压缩（理论基础差不多），那么只需要根据图像分辨率，做相应的最佳分割快大小计算，并做简单切割即可。将区域内的有色的点和无色的点进行记录，并按做纵向或横向切割成色带，记录色带中有色点或者无色点的坐标值即可。整个思路转换成代码思维，类似于多级联映射表。当然这个做法的关键还在于公式如何设计，即如何动态计算切割区域的大小。由于是做印章方面，所以图像不会太大，因此公式也非常简单。
最终压缩可以理解成单值图的无损压缩，实测试之后，和转换成矢量图之后的文件大小相比，应该两者都会比现在主流的大部分图像编码小非常多。
接着通过类似7z、rar工具里面的二进制压缩算法进行再次压缩，文件最大还能缩小60%左右。一个500k的位图最终生成文件在3k左右。
—- 我是装逼的分割线 2号 —-
由于有上面的实践基础，因此在理解264的压缩时，我也能够理解到“分割”时的重要性。
首先，在baseline模式下，x264的预测模型相对于其他high来说，非常简单。这样的情况就决定了，在局部的细节切块相比high来说有着很多不足，对二进制数据进行压缩前就已经输在起跑线了。即细节丢失比high多。
其次在编码算法上（或者说压缩算法上），baseline仅仅使用cavlc，而对其他两者来说他们既可以使用cavlc也可以使用cabac。没有做过定性或者定考量分析，但通过网上资料获知，cavlc的效率似乎没有cabac高，具体在哪些指标有所体现目前暂时并不清楚。
因此，可以得知。baseline除了在实时性上满足了双向强交互直播对时间的要求，对于相同质量下的压缩比并不是很好。但又由于baseline相对其他profile的简单特点，其实广泛性还是比较不错的。
手里有台android 2.3时代的三星手机，对baseline的视频进行解码，手机基本可以应付（不清楚是硬解还是软解，因为当时的arm好像还有没有对264硬解做太多优化），但相同视频长度的main和high的话，那就有点头疼了。看来baseline对老旧手机还是比较“良好”的。