Networking FU-A多片NALU每帧RTP封装

Networking FU-A多片NALU每帧RTP封装,networking,video-streaming,rtp,Networking,Video Streaming,Rtp,我们正在使用编解码器进行每帧2个片段的编码,在VLC播放器上播放时,我们得到了良好的H264文件输出。 但当我们对编码数据进行RTP打包并流到VLC时,它会显示出伪影。如果我们每帧使用一个切片,我们的打包就可以了,VLC上的流看起来也不错。 我们正在使用FU-A碎片和我的编码文件配置: resolution: 640x480 framerate: 30fps bitrate: 800 Kbps 我们的编码器配置为每10帧使用High Profile、CBR、IDR 我们的编码器输出比特流如下所

我们正在使用编解码器进行每帧2个片段的编码,在VLC播放器上播放时,我们得到了良好的H264文件输出。
但当我们对编码数据进行RTP打包并流到VLC时,它会显示出伪影。如果我们每帧使用一个切片,我们的打包就可以了,VLC上的流看起来也不错。
我们正在使用FU-A碎片和我的编码文件配置:

resolution: 640x480
framerate: 30fps
bitrate: 800 Kbps
我们的编码器配置为每10帧使用High Profile、CBR、IDR

我们的编码器输出比特流如下所示:

00 00 01 67[数据]00 00 01 68[数据]00 00 01 65[数据]00 00 01 65[数据]00 00 01 41[数据]

这里我们有两个连续的切片NALU(0x65)。 在我们的RTP pcap中,一切看起来都很好——FU-A碎片、标记位等,但VLC和ffplay都显示了类似类型的伪影,就好像帧的上半部分被拉伸(垂直)。
我的pcap文件链接:

所以我将测试用例简化为一个小的、低比特率(50kbps)的QCIF流,没有碎片,我仍然看到同样的问题。
我的pcap文件链接:


请任何专家查看pcap文件,看看是什么导致VLC在播放流时出现这种问题

谢谢,,

Harshal Patel

虽然这是一个非常古老的问题,但当聚合具有相同时间戳的多个NAL-U时(如在您的示例中),打包器应该使用STAP-a模式,而不是FU-a。FU-a是为不适合RTP数据包的单个时间戳NAL-U制作的

你需要解决打包问题,一切都会顺利进行