关于H264通过RTP传输的打包方式

Q:现在小弟初次尝试H264的编码通过RTP方式传输，具体实验环境的问题如下：
环境：
服务器端，H264的帧数据（可能超过64k），分成N个1460字节的包，然后加上RTP头发送。
客户端，VLC播放器，通过RTSP协议建立连接，然后接收数据解码播放。
结果：
VLC不能解码接收到的数据，解码出错，VLC的信息中显示不能解码帧数据。
我已经阅读了一遍rfc3984的文档，对里面的如何进行打包和用rtp传输不是非常理解，希望各位大虾能够帮小弟一把，告诉小弟这些和H264的帧该如何发送，该如何分包，该如何加头信息等等。
（其中看到FUs的方式好像适合分包发送，因为小弟的数据帧可能超过64k，所以忘大虾们能够仔细解释一下对于小弟这种情况下的RTP传输）

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

Q:斑竹好，我这边是用VLC和服务器端进行通讯的，他们是用RTSP协议建立开始时的连接的，服务器返回DISCRIBERS请求的SDP和下面描述的相同，我使用的packetization-mode=1，即FU-As方式打包，因为我这边上来的数据帧可能超过64k数据。能否麻烦斑竹看看我这边的SDP写的是否正确。 SDP: v=0 o=- 1 1 IN IP4 127.0.0.1 s=VStream Live a=type:broadcast t=0 0 c=IN IP4 0.0.0.0 m=video 49170 RTP/AVP 99 a=rtpmap:99 H264/90000 a=fmtp:99 profile-level-id=42A01E; packetization-mode=1; sprop-parameter-ets=Z0IACpZTBYmI, aMljiA== a=control:trackID=0 还有就是在RTP发送时，我打好包的数据方式如下面所示： 上来的帧数据为：NALU头＋EBSP数据 因为帧数据大于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，这两个值我应该填写什么？ 按照我现在填写的内容，VLC会出现解不出码的情况，希望斑竹可以帮我回答的细致一点。谢谢了。 A:我觉得 RFC3984 上面说得非常清楚啊。 首先你把一个 NALU 的 EBSP 根据需求拆分为多个包，例如 3 个，则： 第一个 FU-A 包的 FU indicator 应该是：F = NALU 头中的 F；NRI = NALU 头中的 NRI；Type = 28。FU header 应该是：S = 1；E = 0；R = 0；Type = NALU 头中的 Type。 第二个 FU-A 包的 FU indicator 应该是：F = NALU 头中的 F；NRI = NALU 头中的 NRI；Type = 28。FU header 应该是：S = 0；E = 0；R = 0；Type = NALU 头中的 Type。 第三个 FU-A 包的 FU indicator 应该是：F = NALU 头中的 F；NRI = NALU 头中的 NRI；Type = 28。FU header 应该是：S = 0；E = 1；R = 0；Type = NALU 头中的 Type。 Q:版主，我按照你的方式分好包发送了，发现VLC不会出现不能解帧的情况了，但是，还是出不来图像。我想可能是因为发送序列参数集和图像参数集的方法不对，他们两个的长度都很小，只要一个包就可以了，我现在将他们按照singal NALU的方式发送，就是直接在NALU包前加一个RTP的头，然后发出去。 是不是我这样发参数集存在着问题，反正我这边VLC是解不了这个参数集，因为参数集解不了，所以下面的帧肯定解不了，所以出不了图像。 麻烦版主再解释一下如何发参数集。 A:今天刚接受了流媒体的相关培训。懂得看你的 SDP 了。 对于你的问题，不知道 SPS、PPS 打包是否有问题。按照 RFC3984，而且感觉你打单一包的方式也是错的。我希望你能通过自己学习的方式去把这个问题弄清楚，因为 RFC3984 里面说得很清楚，请你自己学习学习 RFC3984 吧。既然你在做这个工作，还是应该仔细学习一下 RFC3984。 另外， SDP 中的 sprop-parameter-ets=Z0IACpZTBYmI 实际就是 SPS 和 PPS 的 BASE64 转码，你不用在码流中再传输 SPS/PPS，直接从 SDP 就可以得到。 A2:1. SDP中已经包括SPS&PPS，码流中完全可以不用传输SPS&PPS 2. profile-level-id=42A01E，这是SPS的开头几个字节，剩下的在sprop-parameter-ets=Z0IACpZTBYmI, aMljiA==中，BASE64编码，把“Z0IACpZTBYmI, aMljiA==”反BASE64转换回去，应该刚好是SPS&PPS的内容 3. 打包注意，要求H.264码流不是byte stream格式的，即没有0x000001分隔，也没有插入0x03，具体如何生成，检查你的编码器选项。 4. packetization-mode=1模式下，要求每个RTP中只有一个NAL单元，或者一个FU，不分段的NAL不做任何修改，直接作为RTP负载；分段的NAL注意，NAL头不传输，有效负载从NAL头之后开始，根据NAL头的信息生成FU的头两个字节（相当于NAL头拆为两部分），具体生成方式版主已经讲得很清楚。 5. RTP的payload type要与SDP中一致，不然解的出才怪