TS OVER IP的多画面合成
许久没写博客了，似乎现在也很难静下心来去写东西，倒也不是心情浮躁，以前的写blog用来收集网上文章，记录自己的一些经验，后来假设了自己的文件服务器，用wiz做了笔记的server,收集什么东西用wiz就完成了，自己记录点经验也不在乎格式，也都没拿出来分享。这次辛辛苦苦做完一个项目，其中遇到一些问题，没有网络上的资料自己是很难解决的。因此整理点东西，与大家分享，也不能总受之与人吧。
终于做完了多画面合成的项目，颇有心得，其间也遇到一些问题，没有网络上的资料自己是很难解决的，但也不是所有东西都能在网上找到办法，使用ffmpeg遇到太多问题，许多只能通过阅读源码解决。如今做完了，拿出来与众分享。
画面合成器是将多个承载于UDP的TS流（MPTS，SPTS）解码，将解码后图像缩放成小画面，再将各个源合并成2x2,3x3,4x4等方式，实现电视墙的效果。
项目的需求是这样的：
1.UDP输入UDP输出
2.提供源切换的接口，客户会再某个时刻换掉某个源
3.良好的异常处理，某个UDP源断流或恢复不影响现有节目。这不是客户的要求，但有过大型项目经验的人知道，这是一定要考虑的
从实现层面来讲，需要以下技术点：
1.UDP单播组播接收
2.TS封装的H264与MPEG2视频解码为YUV
3.YUV缩放
4.YUV画面拼接
5.合成后的YUV压缩为H264
6.压缩后的视频打包TS
7.打包后的TS通过UDP发送
8.发送时需要进行流控，保证VLC可正常播放。
这些技术点不算难，真正的难点在于统筹运作，N个源各自的解码后画面输出速度不同，虽然我们要求各源帧率相同。各解码线程画面输出虽整体相同，但肯定会忽高忽低。如果每个源都正常的话，我们可以等待每个源都有画面的时候才进行合成。但是我们需要考虑源断流与恢复，就不能一直等待某个源。其二，为了支持源切换，我们应该涉及好运作模式，实现无缝切换，但这些只是我特定 业务的需要，接下来只讲与ffmpeg相关技术。
先讲上面提到的8个技术点，UDP收发就不用说了，值得一提的是接收需要使用异步模式，这个在后面会提到。除了YUV画面拼接，其他都可以用ffmpeg sdk实现。因此主要讨论使用ffmpeg进行解码编码，这种技术文章其实很多，但他们一般只有简单的方案，对于这些比较常见的东西，我们也不做讨论，只讨论几个重点，而又缺乏资料的问题，主要有：
1.对解码及编码自定义io回掉。UDP接收及发送不通过ffmpeg实现。对于UDP源来说，ffmpeg对MPTS支持不好。对于输出UDP来说，ffmpeg没有流控
有时我们希望ffmpeg的api打开的不是文件或某个协议的URL，直接传递数据缓冲给他，ffmpeg不支持传递数据指针给他，要求他编码或解码，这在ffmpeg api中的实现方式是IO回掉函数。他在需要的时候来调用你的函数来读取或写入。以解码为例，下面为示例代码：
AVIOContext *pb = avio_alloc_context(pbuf+1316, AVIO_BUF_SIZE-1316, 0, this, ReadDataCb, NULL, NULL);
if (av_probe_input_buffer(pb, &pinFmt, "", NULL, 0, MAX_PROBE_SIZE) < 0)
{
//error...
}
AVFormatContext *pFmtCt = avformat_alloc_context();
pFmtCt->pb = pb;
if (avformat_open_input(&pFmtCt, "", pinFmt, NULL) < 0)
{
//error...
}
读取回掉原型如下：
static int ReadDataCb(void *opaque, uint8_t *buf, int buf_size);
实现理念一般应该是除非想要停止解码，返回-1，否则返回数据长度。保证他读到数据
不知道是出于内存对齐还是什么原因，
uint8_t *pbuf = (uint8_t *)calloc(AVIO_BUF_SIZE,1);
pb = avio_alloc_context(pbuf+1316, AVIO_BUF_SIZE-1316, 0, this, ReadDataCb, NULL, NULL);
的时候第一个参数直接传pbuf会崩溃，所以+1316
而若使用av_mallocz，虽可以直接传pbuf,却在av_free的时候崩溃，没有找到原因。
2.由于需要实现切换，所以需要将某个源完全销毁，不产生内存泄露，不要小看这个问题，网上的很多代码是不对的。
销毁 AVFormatContext
正确销毁方式：
/* close decoder for each stream */
for (int i = 0; i < pFmtCt->nb_streams; i++)
{
if (pFmtCt->streams[i]->codec->codec_id != AV_CODEC_ID_NONE)
{
THREAD_MUTEX_LOCK(&g_mutex_avcodec_oc);
avcodec_close(pFmtCt->streams[i]->codec);
THREAD_MUTEX_UNLOCK(&g_mutex_avcodec_oc);
}
}
avformat_close_input(&pFmtCt);
销毁 AVIOContext
//不可使用avio_close
av_free(pb->buffer);
av_free(pb);
销毁 AVFrame
AVFrame *pframe = avcodec_alloc_frame();
avcodec_free_frame(&pframe);
3.多线程使用ffmpeg sdk问题
avcodec_open/avcodec_close不是线程安全的，必须进行全局加锁保护，或者其他同步方式。除了这两个函数外，由于av_find_stream_info内部调用了avcodec_open，也需要加锁。但av_find_stream_info有可能执行时间比较长，如果没特别的必要，可以不使用此函数。对于解码来说，有下面两个函数：
av_probe_input_buffer
avformat_open_input
大部分情况下已经可以正常解码了。
关于压缩
ffmpeg压缩H264 TS时CBR并不好用，设置了mux_rate会导致TS封装出错。老老实实用VBR，不设置mux_rate
进行H264压缩时一个选项一定要设置的：
preset
在压缩效率和运算时间中平衡的预设值，可用选项：
ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow and placebo
画面合成器是将多个承载于UDP的TS流（MPTS，SPTS）解码，将解码后图像缩放成小画面，再将各个源合并成2x2,3x3,4x4等方式，实现电视墙的效果。
项目的需求是这样的：
1.UDP输入UDP输出
2.提供源切换的接口，客户会再某个时刻换掉某个源
3.良好的异常处理，某个UDP源断流或恢复不影响现有节目。这不是客户的要求，但有过大型项目经验的人知道，这是一定要考虑的
从实现层面来讲，需要以下技术点：
1.UDP单播组播接收
2.TS封装的H264与MPEG2视频解码为YUV
3.YUV缩放
4.YUV画面拼接
5.合成后的YUV压缩为H264
6.压缩后的视频打包TS
7.打包后的TS通过UDP发送
8.发送时需要进行流控，保证VLC可正常播放。
这些技术点不算难，真正的难点在于统筹运作，N个源各自的解码后画面输出速度不同，虽然我们要求各源帧率相同。各解码线程画面输出虽整体相同，但肯定会忽高忽低。如果每个源都正常的话，我们可以等待每个源都有画面的时候才进行合成。但是我们需要考虑源断流与恢复，就不能一直等待某个源。其二，为了支持源切换，我们应该涉及好运作模式，实现无缝切换，但这些只是我特定 业务的需要，接下来只讲与ffmpeg相关技术。
先讲上面提到的8个技术点，UDP收发就不用说了，值得一提的是接收需要使用异步模式，这个在后面会提到。除了YUV画面拼接，其他都可以用ffmpeg sdk实现。因此主要讨论使用ffmpeg进行解码编码，这种技术文章其实很多，但他们一般只有简单的方案，对于这些比较常见的东西，我们也不做讨论，只讨论几个重点，而又缺乏资料的问题，主要有：
1.对解码及编码自定义io回掉。UDP接收及发送不通过ffmpeg实现。对于UDP源来说，ffmpeg对MPTS支持不好。对于输出UDP来说，ffmpeg没有流控
有时我们希望ffmpeg的api打开的不是文件或某个协议的URL，直接传递数据缓冲给他，ffmpeg不支持传递数据指针给他，要求他编码或解码，这在ffmpeg api中的实现方式是IO回掉函数。他在需要的时候来调用你的函数来读取或写入。以解码为例，下面为示例代码：
AVIOContext *pb = avio_alloc_context(pbuf+1316, AVIO_BUF_SIZE-1316, 0, this, ReadDataCb, NULL, NULL);
if (av_probe_input_buffer(pb, &pinFmt, "", NULL, 0, MAX_PROBE_SIZE) < 0)
{
//error...
}
AVFormatContext *pFmtCt = avformat_alloc_context();
pFmtCt->pb = pb;
if (avformat_open_input(&pFmtCt, "", pinFmt, NULL) < 0)
{
//error...
}
读取回掉原型如下：
static int ReadDataCb(void *opaque, uint8_t *buf, int buf_size);
实现理念一般应该是除非想要停止解码，返回-1，否则返回数据长度。保证他读到数据
不知道是出于内存对齐还是什么原因，
uint8_t *pbuf = (uint8_t *)calloc(AVIO_BUF_SIZE,1);
pb = avio_alloc_context(pbuf+1316, AVIO_BUF_SIZE-1316, 0, this, ReadDataCb, NULL, NULL);
的时候第一个参数直接传pbuf会崩溃，所以+1316
而若使用av_mallocz，虽可以直接传pbuf,却在av_free的时候崩溃，没有找到原因。
2.由于需要实现切换，所以需要将某个源完全销毁，不产生内存泄露，不要小看这个问题，网上的很多代码是不对的。
销毁 AVFormatContext
正确销毁方式：
/* close decoder for each stream */
for (int i = 0; i < pFmtCt->nb_streams; i++)
{
if (pFmtCt->streams[i]->codec->codec_id != AV_CODEC_ID_NONE)
{
THREAD_MUTEX_LOCK(&g_mutex_avcodec_oc);
avcodec_close(pFmtCt->streams[i]->codec);
THREAD_MUTEX_UNLOCK(&g_mutex_avcodec_oc);
}
}
avformat_close_input(&pFmtCt);
销毁 AVIOContext
//不可使用avio_close
av_free(pb->buffer);
av_free(pb);
销毁 AVFrame
AVFrame *pframe = avcodec_alloc_frame();
avcodec_free_frame(&pframe);
3.多线程使用ffmpeg sdk问题
avcodec_open/avcodec_close不是线程安全的，必须进行全局加锁保护，或者其他同步方式。除了这两个函数外，由于av_find_stream_info内部调用了avcodec_open，也需要加锁。但av_find_stream_info有可能执行时间比较长，如果没特别的必要，可以不使用此函数。对于解码来说，有下面两个函数：
av_probe_input_buffer
avformat_open_input
大部分情况下已经可以正常解码了。
关于压缩
ffmpeg压缩H264 TS时CBR并不好用，设置了mux_rate会导致TS封装出错。老老实实用VBR，不设置mux_rate
进行H264压缩时一个选项一定要设置的：
preset
在压缩效率和运算时间中平衡的预设值，可用选项：
ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow and placebo