FFmpeg + Triple DES加密传输的坑

最近在开发一个rtmp的推流和拉流直播系统，记录一个加密过程的坑

方案一

直接用Triple DES加密YUV数据，一帧640x480的YUV420P数据单线程加密一次居然要接近1000ms(1fps)的时间，这要是直接用那不相当于放PPT了！！！

方案二

搞一个线程池用Triple DES加密YUV数据，提高是提高了，起3个线程时间变成原来的三分之一，起6个线程降到190ms一下，这成本太高了，正常播放那得起至少25个线程，还得来个至少25核心的CPU才行，我这6核心的CPU果断放弃这个方案

方案三

加密压缩后的裸流数据，配合上线程池，时间一下子降下来了，时间符合要求了，那就开始传输吧，结果坑来了，传输过去拉流端怎么也不放了，程序直接崩溃(我去，我就加密一下你至于气的崩溃了吗？？)，一开始以为是数据类型转换导致的，因为YUV和H264裸流都是uint8_t(unsigned char)类型，我转成char类型(我可能当时糊涂了，为啥要转类型？)加密的，于是把加密程序的数据类型改了，结果程序还是崩溃了，我的天，这下不光是程序崩溃，我也快崩溃了，继续排查bug，这时候开始怀疑是不是FFmpeg压缩后的数据(AVPakcet中的data)有什么特殊的字段，找啊找，找啊找，网上大部分都是说，data指向的是压缩后的数据，也没说清楚是怎么回事，突然看到了雷神的文章《使用FFMPEG类库分离出多媒体文件中的H.264码流》，一语惊醒梦中人，AVPakcet中data数据的前4Byte记录的是nalu的长度，第5个Byte开始才是真正的nalu数据，果断把加密数据跳过前8Byte(狠一点！！)，

摄像头获取视频->转码->压缩->加密(跳过前8Byte)->推流->拉流->解密(跳过前8Byte)->解压->播放

啊哈成了(致敬雷神)