下载：

叶子 2013-11-29 13:34 发表评论

    终于做完了多画面合成的项目，颇有心得，其间也遇到一些问题，没有网络上的资料自己是很难解决的，但也不是所有东西都能在网上找到办法，使用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

叶子 2013-05-31 14:52 发表评论

使用帮助：

命令行程序，在cmd下执行,程序运行需要三个参数：输入文件1 输入文件2 输出文件

示例：

dvbmux d:\1.ts d:\2.ts d:\mux.ts

任何问题,请致信：

shangxinjian1972@163.com

2012-5-31

叶子 2012-05-31 14:55 发表评论

叶子 2012-04-18 15:59 发表评论

GPG 错误：http://mirrors.163.com maverick-updates Release: 下列签名无效： BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <ftpmaster @ubuntu.com> </ftpmaster>

gpg --keyserver keyserver.ubuntu.com --recv 40976EAF437D05B5 gpg --export --armor 40976EAF437D05B5 | sudo apt-key add -

sudo aptitude -o Acquire::http::No-Cache=True -o Acquire::BrokenProxy=true update

sudo apt-get clean cd /var/lib/apt sudo mv lists lists.old sudo mkdir -p lists/partial sudo apt-get clean sudo apt-get update

http://www.linuxbyte.org/ubuntu-geng-xin-yuan-qian-ming-cuo-wu-badsig-40976eaf437d05b5.html

叶子 2012-02-18 03:10 发表评论

   1:  # cd /var/log/

   2:  #cat security 

   1:  session required /lib64/security/pam_limits.so

   2:   

   3:  session required pam_limits.so

http://www.zhaofengcao.com/archives/138

叶子 2012-01-06 12:35 发表评论

extern int Variable_Attributes_deprecated_0 __attribute__ ((deprecated));
extern int Variable_Attributes_deprecated_1 __attribute__ ((deprecated));
void Variable_Attributes_deprecated_2()
{
    Variable_Attributes_deprecated_0=1;
    Variable_Attributes_deprecated_1=2;
}

叶子 2011-12-28 20:26 发表评论

叶子 2011-11-22 16:20 发表评论

叶子 2011-11-01 14:46 发表评论

       否则，一个片由 三个 NALU 组成（即标准“表7-1”中 nal_unit_type 值为 2、3、4 的三个 NALU 属于 一个片）；  

 

（5）、以上所述的片和 NALU 的大小关系并不是抽象概念上的从属关系。从概念的从属关系上来看，NALU其实又是片的一个集合概念，例如：标准“表7-1”中 nal_unit_type 值为 5 的 NALU 包括 I 片或者 SI 片。

    一幅图像根据组成它的片类型来分，可以分为标准“表7-5”中的 8 种类型。我们平常应用中所最常见到的其实是这些类型的特例。例如：我们平常所谓的“I 帧”和“IDR 帧”，其实是 primary_pic_type 值为 0 的图像，我们平常所谓的“P帧”其实是 primary_pic_type 值为 1 的图像的特例，我们平常所谓的“B帧”其实是 primary_pic_type 值为 2 的图像的特例。

    一幅图像根据概念来分可以分为两种：IDR 图像和非 IDR 图像。一幅图像是否是 IDR 图像是由组成该图像的 NALU 决定的，如果组成该图像的 NALU 为标准“表7-1”中 nal_unit_type 值为 5 的 NALU，则该图像为 IDR 图像，否则为非 IDR 图像。这里也有几点值得说明：

（1）、nal_unit_type 值为 5 的 NALU 只会出现在 IDR 图像中，而 IDR 图像中的所有 NALU 都是nal_unit_type 值为 5 的 NALU；
（2）、我们以组成一幅图像的片的类型来区分该图像是否是 IDR 图像是错误的。

例如：一幅图像中的所有片都是 I 片并不代表这幅图像就是 IDR 图像。因为 I 片也可以从属于 nal_unit_type 值为 1 的 NALU 也即非IDR图像有可能全部包含I片。只不过我们平常最常见到的形式是：所有片都是 I 片的图像就是 IDR 图像。其实这个时候 IDR 图像的概念也被我们具体化和细小化了。 但IDR图像必定全部包含I片或SI片，不过只有用NALU的类型才能判断是不是IDR图像

一幅图像由 1～N 个片组组成，而每一个片组又由一个或若干个片组成 一个片由一个NALU或三个NALU（假如有数据分割）组成。图像解码过程中总是按照片进行解码，然后按照片组将解码宏块重组成图像。从这种意义上讲，片实际是最大的解码单元。

 

 

 

 

 

 

叶子 2011-02-24 12:10 发表评论