［直播一揽子］编码构思和套路

在上篇文章中，我肯定了使用的三个库：

h264的编码库也很多，最终选择了x264。
aac的编码库，选择了fdkaac。
rtmp的库，选择了rtmpdump。

也许是个人编码习惯：先各个击破，再合并整合。我决定也采用这样的方式。这样作的好处很明显：

1.考虑范围缩小。好比，在作x264的编码时，无需考虑aac的编码之类的事情。至于aac能遇到什么问题，能够到aac编码的时候去解决。这样就会变成：每次只作一件事。把这件事作好以后，再接着往下作。

2.易于解决问题。出问题的范围将会大大缩小，只会发生在某一个模块内。这对于我查找问题的缘由，debug都有好处。

3.功能内聚性高。当一个模块编译完成以后，只需提供接口给外围调用，减小了外围对具体实现的要求，由于外围能够不用知道里面是怎么实现的。

坏处也是有的：须要为各个模块编写一套工程代码。有多少个模块，就得写多少个工程代码。这就会形成工程代码较多。在整合以前，感受有点乱。我我的以为这也是模块化的一个反作用。就像Andorid里面的Library同样。

通过以上的构思，初步认为至少须要4个工程：x264的采集工程，aac的采集工程，和rtmp的传输工程。

接下来就是编码的工做了。实际问题老是比想象的多啊！