和记娱乐


网站导航

联系我们

和记娱乐

联系人: 

电 话:021-64057486

公司网址:http://www.happy123456789.com

   址:成都市松江区漕河泾松江新兴产业园区研展路丰产支路55号B座803室

邮编:201165


通信科技

您的当前位置: 和记娱乐主页 > 通信科技 >

解析SDP中包含的H.264的SPS和PPS串

发布日期:2019-10-08 14:28 来源:和记h88 发布人:和记娱乐 点击:

  SDP中的H.264的SPS和PPS串,包含了初始化H.264解码器所需要的信息参数,包括编码所用的profile,level,图像的宽和高,deblock滤波器等。

  由于SDP中的SPS和PPS都是BASE64编码形式的,不容易理解,附件有一个工具软件可以对SDP中的SPS和PPS进行解析。

  1、编码器编码出每个关键帧都加上SPS、PPS ,据说通常情况编码器编出的 SPS、PPS是一样的,所以这种方法耗费资源。

  服务器端,H264的帧数据(可能超过64k),分成N个1460字节的包,然后加上RTP头发送。

  我已经阅读了一遍rfc3984的文档,对里面的如何进行打包和用rtp传输不常理解,希望各位大虾能够帮小弟一把,告诉小弟这些和H264的帧该如何发送,该如何分包,该如何加头信息等等。

  (其中看到FUs的方式好像适合分包发送,因为小弟的数据帧可能超过64k,所以忘大虾们能够仔细解释一下对于小弟这种情况下的RTP传输)

  A:我觉得所有的问题在 RFC3984 里面都已经说得很清楚了。不知道你有哪点不懂,请具体提出来。

  Q:斑竹好,我这边是用VLC和服务器端进行通讯的,他们是用RTSP协议建立 开始时的连接的,服务器返回DISCRIBERS请求的SDP和下面描述的相同,我使用的packetization-mode=1,即FU-As方式打 包,因为我这边上来的数据帧可能超过64k数据。能否麻烦斑竹看看我这边的SDP写的是否正确。

  因为帧数据大于1460字节,所以我把数据分为N个不大于1460字节的包,每个包前面加上RTP头发出去。

  其 中NALU头的数值I帧为0x65,参数集为0x67和0x68,这个值是不是有点错误,我看RFC3984说的好像和我现在的有点不 同,RFC3984说FU-As方式打包类型值为28,我不知道这个是否十进制的,如果按照RFC3984上说的NALU头应该是多少?还是用FU- As方式的FU indicator代替原来的NALU头。

  还有这个FU-As方式的头好像是有两个值,一个是FU indicator,另外一个是FU header,这两个值我应该填写什么?

  Q:版主,我按照你的方式分好包发送了,发现VLC不会出现不能解帧的情况了, 但是,还是出不来图像。我想可能是因为发送序列参数集和图像参数集的方法不对,他们两个的长度都很小,只要一个包就可以了,我现在将他们按照singal NALU的方式发送,就是直接在NALU包前加一个RTP的头,然后发出去。

  是不是我这样发参数集存在着问题,反正我这边VLC是解不了这个参数集,因为参数集解不了,所以下面的帧肯定解不了,所以出不了图像。

  对 于你的问题,不知道 SPS、PPS 打包是否有问题。按照 RFC3984,而且感觉你打单一包的方式也是错的。我希望你能通过自己学习的方式去把这个问题弄清楚,因为 RFC3984 里面说得很清楚,请你自己学习学习 RFC3984 吧。既然你在做这个工作,还是应该仔细学习一下 RFC3984。

  3. 打包注意,要求H.264码流不是byte stream格式的,即没有0x000001分隔,也没有插入0x03,具体如何生成,检查你的编码器选项。

  4. packetization-mode=1模式下,要求每个RTP中只有一个NAL单元,或者一个FU,不分段的NAL不做任何修改,直接作为RTP负 载;分段的NAL注意,NAL头不传输,有效负载从NAL头之后开始,根据NAL头的信息生成FU的头两个字节(相当于NAL头拆为两部分),具体生成方 式版主已经讲得很清楚。

      和记娱乐,和记h88,h88平台官网