“奇怪” Parrot Anafi RTSP 流的 NALU 复用
通过RTSP提供的鹦鹉Anafi无人机的RTP NALU流似乎将几个NAL单元“”“多路复用”在RTP级别的较大外部NAL单元中。尝试使用GSTREAMER管道，该管道只是打开RTSP源，然后在“ RTPH264Depay”和“ RTPH264PAY”之后转发它们，在远端不起作用：混乱到达浏览器，显然他们也从未见过。
在这里，SPS和PPS以及一个非IDR片的示例发送为一个大块：
到目前为止，我从未见过这样的“分组”，我曾经用来将SPS和PPS视为单独的RTP数据包。显然，所有浏览器也无法解码这样的“组”。
The RTP NALU stream of a Parrot Anafi drone provided via RTSP seems to kind of "multiplex" several NAL units into a bigger outer NAL unit at RTP level. Trying to use a GStreamer pipeline, which just opens the RTSP source and then forwards them after "rtph264depay" and "rtph264pay" again does not work on the far end: The mess arrives at the browser and they obviously also never have seen such.
Here an example of SPS and PPS and a non-IDR slice send as one big chunk:
Up to now I never have seen such a "grouping", I'm used to see SPS and PPS as separate RTP packets. Obviously all browsers too, since they are not able to decode such a "group".
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
有效载荷是可以的，它是总结的。鹦鹉Anafi的问题是：他们不发送IDR帧。浏览器需要。没有IDR，没有视频。
The payload is OK, it is STAP-A aggregated. The problem with Parrot Anafi is: They don't send IDR frames. Browsers need that. No IDR, no video.