通过 UDP 传输 h.264 编码视频
我对 h.264 不太了解，但问题是我在 mp4 容器中以 h.264 格式保存了该视频，我想通过 UDP 进行流式传输。
我的问题很简单，在对视频进行编码时是否可以进行任何调整，以便它能够相当容忍一些“轻微”的数据包丢失？
我知道压缩视频通常每 N 帧有一个关键帧，然后在这些帧之间它只发送增量。我可以想象 h.264 应该比这复杂得多，所以它可能不那么简单。
更准确地说，我做了一些实验，并意识到，只需从视频流中删除 1024 字节，我就会使其从丢失点开始就完全“无法播放”。
我希望它能够承受这样的光损失，这可能吗？
谢谢
尼尔森
I don't know too much about h.264, but the thing is that I've got this video in h.264 in a mp4 container which I would like to stream over UDP.
My question is simple, is there any tweaks I can maybe do while coding the video so that it comes out fairly tolerant to some "light" packet loss?
I know that compressed video usually has a keyframe every N frames and then in between those it just sends the deltas. I can imagine h.264 should is a lot more complex than that, and so the it might not be just so simple.
To be more precise, I've been making some experiments and realized that just by removing 1024 bytes out of a stream of video, I render it completely "unplayable" from the point of the loss and on.
What I would like is for it to tolerate light losses like that, is it possible?
Thanks
Nelson
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这取决于您丢失的数据。 H264 流中的某些数据是不会丢失的数据。例如，如果您丢弃 1024 字节的实验恰好是您发送的前 1024 字节，那么您可能丢弃了序列参数集和图片参数集 (SPS/PPS)，这基本上是告诉解码器如何处理的信息解释传入的信息。您可能也不能只是从流中随机删除 1024 个字节；通常 H264 是打包的，因此无论如何都不会发生这种情况。
所以H264确实包含一些确实不能“丢弃”的小数据；许多流媒体协议（例如 RTSP）通过明确说明您不应该通过有损传输通道发送此类信息，而是在 SDP 交换期间（通过 TCP 发生）发送此类信息，从而明确了这一点。
就丢失容忍度而言，H264 确实具有有助于丢失容忍度的功能（ASO、FMO 等），但实际上大多数编码器不支持它们。如果可以的话，我会使用x264；据称，即使丢包率高达 20% 或更高，他们的低延迟流配置也能正常工作。如果您的 H264 已经编码，那么无需做太多事情。您的视频已经编码，您必须按原样流式传输。
It depends on what data you're losing. Some data in the H264 stream is not data that can be lost. For example, if your experiment where you dropped 1024 bytes happened to be the first 1024 bytes you sent, then you probably dropped your Sequence Parameter Set and Picture Parameter Set (SPS/PPS), which is basically the information that tells the decoder how to interpret the incoming information. You also probably can't just drop a random 1024 bytes out of the stream; typically H264 is packetized so that sort of thing wouldn't happen anyway.
So H264 does contain some small pieces of data that really aren't "discardable"; many of the streaming protocols like RTSP make this clear by specifically stating you SHOULD NOT send this sort of information through the lossy transport channel, but instead during the SDP exchange (which happens over TCP).
As far as loss-tolerance goes, H264 does have features that are supposed to aid loss tolerance (ASO, FMO, etc.), but in practice most encoders don't support them. If you can, I'd use x264; their low-latency streaming configuration purportedly works well even with packet loss as high as 20% or more. If your H264 is already encoded, then there's not much to be done. Your video is already encoded and you'll have to stream it as-is.