ffmpeg处理hikvision平台PS流

在多媒体指挥调度系统中,将监控平台的IPC音视频转发到视频会议、视频话机以及直播平台,是一个常见的需求。常见的监控平台在提供的SDK中通常以回调的方式将音视频媒体用复合流的方式送给应用程序。所谓的复合流,安防行业当然以PS流见多,hikvision平台也是如此。

    既然是PS流,当然要仔细研究一下iso13818-1规范,本来想自己写PS流的解析代码,但考虑到已经有众多的PS流解析开源代码,咱就不必自己再造个汽车轮子了,趁着自己熟悉ffmpeg,还是用ffmpeg去解析吧,但没承想掉进一个大坑。。。
    用ffmpeg的好处是,可以通过avio的方式,将内存中的ps流送入ffmpeg进行自动化的处理,通过探测流格式,寻找流,自动确定对应的流格式和音视频编码,自动拼帧,最终demux得到音频帧和视频帧。这样,不管是复合流(PS流或TS流),还是裸流(H.264或H.265等),都能用同一种机制进行处理,代码简洁。但坏处就是,必须对ffmpeg非常熟悉才行,如果稍有不慎掉坑了,必须要自己翻出来。。。
    不幸的是,我也掉坑了。程序开发完毕,信心满满的进行测试,发现取到的PS流分离出H.265视频帧并转发到视频会议,视频会议中的IPC分屏小几率偶尔会闪一下屏,客户能不能忍咱不知道,但作为处女座人士,不能忍,遂一步步的排查原因。
    首先怀疑是不是视频会议解码H.265解错了?毕竟视频会议的H.265 codec部分也是我刚加上的,虽然也通过了测试,但毕竟心里没有底气。于是就抓包分析,不幸的是又卡在H.265上,tcpdump抓包如果是H.264码流,大把的分析工具可以分离出码流,如果是H.265的抓包,一时没有找到合适的,毕竟H.265跟H.264的RTP打包规则有些差别,不通用。一怒之下,自己写了一个简单的分离程序,分离出了H.265码流,然后使用播放工具播放,发现果然也是有闪屏现象,于是首先排除了视频会议的问题。
    其次,是不是RTP打包H.265时搞错了?于是在RTP打包发送之前将H.265码流录制下来,使用播放工具播放,发现竟然也有闪屏现象。晕倒,竟然是ffmpeg分离出的H.265视频帧就有问题了!是hikvision的PS流有问题,还是ffmpeg分离265视频帧有问题?面对业界内的两个大牌,我无语了。只好将hikvision SDK接口回调中的PS流录制下来,使用ffplay播放,也有闪屏现象,再改用potplayer播放,神奇了,potplayer如丝滑般流畅。于是,焦点集中在了ffmpeg上。
    从输入PS流到取到H265视频帧,ffmpeg其实经历了2步:分析PS包和使用parser分析H265,哪一步有问题呢?
    决定先从PS包分析查起。用winhex打开录制的PS文件,定位到闪屏时程序日志记录的position:
        00 00 01 BA 4D 0C AD BF  84 01 00 00 03 FE FF FF
        00 00 01 BF 00 00 01 E0  13 FA 8C 80 07 23 43 2B

    00 00 01 BA是PS头,之后有10个固定的字节,其中第十个字节的后3位是stuffing填充长度,在本例中是FE,FE&7等于6,则其后的6个字节是stuffing填充字节,咨询hikvision,说这stuffing他们一般用来填充帧序号,好吧,不管是什么都可以略过。但是等等,这stuffing字节怎么恰好有00 00 01 BF?凭着对H264 H265以及PS的了解,对00 00 01还是敏感的,这个熟悉的起始码出现的实在太不是时候了,难不成ffmpeg把这个stuffing里面的字节认成了PS里面的PRIVATE_STREAM_2,从而造成错误?于是赶紧查看ffmpeg里面的PS解析代码。
    ffmpeg中的PS解析在mpeg.c文件中的mpegps_read_packet函数中,此函数先解析PS头,然后根据不同的pes取出不同的媒体流。既然是在BA头中的stuffing中发现的00 00 01起始头,肯定要查看解析PS头的函数,于是继续定位到mpeg.c的mpegps_read_pes_header函数,果然看出了端倪!
     if (startcode == PACK_START_CODE){
         goto redo;
     }

    mpegps_read_pes_header查找到00 00 01 BA后,没跳过PS头,而是直接goto redo去找下一个00 00 01起始码,而上述PS头的stuffing填充中恰好有00 00 01 BF,于是ffmpeg便搜索到了一个PRIVATE_STREAM_2!想不到大名鼎鼎的ffmpeg竟然也出了一个如此低级的错误!

    定位出原因就很容易修改ffmpeg代码了,跳过9字节的固定头,取出10字节中的stuffing长度,再跳过stuffing长度的填充数,然后goto redo就可以了。重新编译ffmpeg,测试程序,果然OK了!

     if (startcode == PACK_START_CODE){
         avio_skip(s->pb,9);
         avio_skip(s->pb,avio_r8(s->pb)&0x7);

         goto redo;
     

  • 2
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 5
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 5
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值