我通过 UDP（视频数据）接收 RTP。

RTP 保存着我需要解码的 H264。不幸的是，大多数 RTP 保存的是碎片数据。由于 RTP 序列丢失，我无法正确重建 H264。

关于如何减少数据丢失以便能够解码至少几个帧有什么想法吗？

没有什么可说的。丢失的数据正如形容词所暗示的那样丢失了。你无法把它拿回来。几乎在任何情况下，您仍然可以将剩余的 NAL 输入解码器并渲染视频。您将看到由缺失的 NAL 引入的伪影，但这就是生活。

丢失的数据丢失。

为了减少数据丢失，您需要更改传输协议。RTSP 中的交错 RTP 可能是基于类似技术堆栈的不错选择。

显然，只有当您有足够的带宽来传输视频时，更改为 TCP 才会有帮助。

如果您可以控制 H264 编码器，请启用错误恢复工具（http://www.slideshare.net/coldfire7/error-resiliency-and-concealment-in-h264-presentation），这使您的视频对传输错误更加稳健。

这样您的 RTP over UDP 就变得“更能抵抗”数据包丢失。

我通过互联网而非 LAN 进行捕获，这可能会增加丢失百分比。正如您所说，我向解码器提供了剩余的 NAL，并且图像完成了约 20%。我还尝试删除所有不完整的框架。另外，我尝试使用mp3parser将 h264 放入 mp4 容器中，但这似乎不起作用。我猜我必须坚持使用 TCP。或者你会建议什么？
如果您想通过不可靠的网络可靠地传输数据，TCP 可能是您的最佳选择。
您可以控制服务器端吗？如果是：正如我在编辑中添加的那样：RTSP 中的交错 RTP 如果不是：您无能为力！
我可以告诉服务器使用 TCP（通过 RTSP）。您能推荐一个通过 TCP 解码 RTP/H264 的好资源吗？到目前为止我用过这个docs.lscube.org/rfc/rfc2326.xhtml#sec_10_12。问题是，显然我只收到通道 0 的 RTP。另外，在这种情况下，不确定从哪里获取 SPS 和 PPS。
如果网络没有足够的带宽来传输视频，TCP 会使情况变得更糟，而不是更好（因为 TCP 的开销更大）。唯一真正的解决方案是降低源的比特率，或者获得更快的网络。