TAG:
许久没写博客了,似乎现在也很难静下心来去写东西,倒也不是心情浮躁,以前的写blog用来收集网上文章,记录自己的一些经验,后来假设了自己的文件服务 器,用wiz做了笔记的server,收集什么东西用wiz就完成了,自己记录点经验也不在乎格式,也都没拿出来分享。这次辛辛苦苦做完一个项目,其中遇 到一些问题,没有网络上的资料自己是很难解决的。因此整理点东西,与大家分享,也不能总受之与人吧。 终于做完了多画面合成的项目,颇有心得,其间也遇到一些问题,没有网络上的资料自己是很难解决的,但也不是所有东西都能在网上找到办法,使用ffmpeg遇到太多问题,许多只能通过阅读源码解决。如今做完了,拿出来与众分享。
(elva)画面合成器是将多个承载于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 |