elva

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

posted on 2013-05-31 14:52 叶子 阅读(5173) 评论(1)  编辑 收藏 引用 所属分类: MPEG

Feedback

# re: TS OVER IP的多画面合成[未登录] 2013-06-06 14:54 wang

nice  回复  更多评论   


只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理