如何跳过 h.264 P 帧直到下一个 I 帧
我通过 RTP/UDP 接收 h.264 流（基线配置文件）， 当将它们发送到解码器时，如果发生（P）帧丢失， 我想跳过帧直到收到下一个帧。 如何检测丢帧情况？ H.264 规范对我来说太混乱了..
I receive h.264 stream (baseline profile) through RTP/UDP,
and when sending them to decoder, if (P)frame loss occurred,
I wanna skip frames until next I frame received.
How can I detect the frame loss?
H.264 spec is too confused to me..
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在切片标头中，使用 frame_num（解码顺序）参数以及 TopFieldPictureCount 和 BottomFieldPictureCount。后两者统称为“图片顺序计数”(POC)。 POC 确定显示顺序。
假设您的 GOP 的显示顺序如下：IBBPBBPBBP...这将是您的 POC 参数的顺序。相应的解码顺序将是 IPBBPBBPBB...请注意，您需要解码第一个 I 和 P 才能解码前 2 个 B 帧。同样，您需要解码第二个 P 帧，以便（与第一个 P 帧一起）解码第二个 2 B 帧。
这样，我将使用 POC 参数来确保我的帧已正确解码。如果您事先知道 GOP，则可以确保您正在接收帧 3、6、9 等。以上面的 GOP 为例，其中 I 帧是帧 0。如果 GOP 未知，您可以解码几帧并根据POC模式确定GOP。例如，上面的 GOP 的实时 POC 为 0, 3, 1, 2, 6, 4, 5, 9, 7, 8, ... 或者，切片标头可以准确地告诉您正在处理的框架。
From the slice header, use the frame_num (decoding order) parameters as well as the TopFieldPictureCount and BottomFieldPictureCount. The latter two are collectively referred to as Picture Order Count (POC). POC determines display order.
Let's say your GOP's display order is as follows: IBBPBBPBBP... This will be the sequence of your POC parameter. The corresponding decoding order will be IPBBPBBPBB... Note that you need to decode the first I and P in order to decode the first 2 B-frames. Similarly, you need to decode the second P-frame in order to (in conjunction with the first P-frame) decode the second 2 B-frames.
With that, I would use the POC parameter to ensure that my frames have been decoded properly. If you know your GOP beforehand, you can make sure that you are receiving frames 3, 6, 9, etc. using the GOP above as an example, where the I-frame is frame 0. If the GOP is unknown, you decode a few frames and determine the GOP from the POC pattern. For instance, the above GOP would have a real-time POC of 0, 3, 1, 2, 6, 4, 5, 9, 7, 8, ... Alternatively, the slice headers can tell you exactly what frame you are dealing with.
我的第一直觉是你的解码器应该能够从丢失的 P 帧中恢复，但万一你的解码器库不能......
我的第一个猜测是 slice_header() 的 frame_num 字段。
slice_header 的语法记录在 ISO 14496-10 的第 7.3.3 节中。
frame_num 的定义从我的副本的第 88 页开始，持续大约一页（因此，如果您想处理所有视频，则解释起来并不简单）。
在扫描文档其余部分中对frame_num的引用时，我还注意到有一个间隙_in_frame_num_value_allowed_flag（在SPS中，第7.3.2.1节），它使frame_num在一般情况下变得复杂。
My first instinct is that your decoder should be able to recover from a missing P frame, but in case your decoder library can not...
My first guess would be the frame_num field of the slice_header().
The syntax of the slice_header is documented in section 7.3.3 of ISO 14496-10.
The definition for frame_num starts on page 88 of my copy and goes on for about a page (so it is not trivial to interpret if you want to handle all video).
While scanning for references to frame_num in the rest of the document I also noticed there's a gaps_in_frame_num_value_allowed_flag (in the SPS, section 7.3.2.1) that enables the frame_num to get complicated in the general case.
查看 RTP 标头。 Wireshark“解码为...”RTP 功能对于此目的非常有用。较长的帧是 I 帧，较短的帧是 P 或 B 帧。
Look through the RTP header. Wireshark "Decode as..." RTP feature is really useful for that purpose. The longer frames are the I-frames and shorter ones are the P or B-frames.