H264视频流塞满0xff

Question

我正在使用recvfrom（）通过套接字接收数据。 我原本希望缓冲区包含可靠的数据流，但是它似乎会定期被0xFF字节的中断破坏。 我正在使用VLC播放器流式传输H264视频。

我的问题是这些0xFF字节从哪里来？ 它们由VLC播放器设置吗？ 我知道它们不是数据包分隔符，因为我已经成功解析了所有序列号。 如果它们不是包装的一部分，如何安全地将其删除？ 以下是一些示例：

80 a1 12 63 
88 7f b9 32 
79 11 3 98 
47 40 44 31 
41 0 ff ff 
ff ff ff ff 
ff ff ff ff 
ff ff ff ff 
ff ff ff ff 
ff ff ff ff 
ff ff ff ff 
ff ff ff ff 
ff ff ff ff 
ff ff ff ff 
ff ff ff ff 
ff ff ff ff 
ff ff ff ff 
ff ff ff ff 
ff ff ff ff 
ff ff ff ff 
ff ff 0 0 
1 c0 0 70 
80 80 5 21 
0 1d c f7 

和

1d a7 77 77 
47 40 44 32 
40 0 ff ff 
ff ff ff ff 
ff ff ff ff 
ff ff ff ff 
ff ff ff ff 
ff ff ff ff 
ff ff ff ff 
ff ff ff ff 
ff ff ff ff 
ff ff ff ff 
ff ff ff ff 
ff ff ff ff 
ff ff ff ff 
ff ff ff ff 
ff ff ff ff 
ff ff ff ff 
ff 0 0 1 
c0 0 71 80 
80 5 21 0 
1d 1f 55 ff 

更新资料

我正在使用RTP。 上面的段只是更大的数据包的一部分。 以下是有关我的信息流的一些信息：

：sout =＃transcode {vcodec = h264，vb = 56，venc = x264 {profile = baseline}，fps = 12，width = 176，height = 144，acodec = mp3，ab = 24，channels = 1，samplerate = 44100 }：rtp {dst = 192.168.0.96，port = 9999，mux = ts}：sout-keep

我不认为应该存在0xFF的原因之一是因为我的解码输出看起来非常损坏。 您还可以看到在0xFF段之后直接有一个RTP起始代码0x000001。

Answer 1

查看使用wireshark从源头通过网络传输的数据包，我发现0xFF实际上是消息的一部分。 数据包的长度也一致，包括0xFF。 我确定我已正确接收数据。 我的问题一定在其他地方。