h264 RTP 时间戳答案

【问题标题】：h264 RTP timestamph264 RTP 时间戳
【发布时间】：2011-01-27 04:49:57
【问题描述】：

我对 h264 RTP 数据包的时间戳感到困惑。我知道视频的挂钟速率是 90KHz，这是我在 SIP SDP 中定义的。我的编码器的帧速率不完全是 30 FPS，它是可变的。它在运行中从 15 FPS 到 30 FPS 不等。所以，我不能使用任何固定的时间戳。

谁能告诉我以下编码数据包的时间戳。
0毫秒后编码的RTP时间戳=0（设起始时间戳为0）
经过 50 毫秒编码的 RTP 时间戳 = ?
经过 40 毫秒编码的 RTP 时间戳 = ?
经过 33 毫秒编码的 RTP 时间戳 = ?

编码帧率可变时的公式是什么？

提前谢谢你。

【问题讨论】：

标签： video h.264 rtp x264

【解决方案1】：

无论您的编码器以 10FPS 还是 30FPS 编码视频都没有关系，您可以通过 RTP 时间戳告诉接收器两帧之间的暂停时间。因此，您可以动态确定每一帧。这样，您可以在一秒钟内发送 10 帧 (10fps)，而在另一秒钟内您可以发送 30 帧 (30 fps)。您只需要正确设置 RTP 时间戳。如果我得到你的问题，你会怀疑如何做到这一点......

让起始时间戳为 0，您将挂钟时间（以毫秒为单位）乘以 100 到最后一个 RTP 时间戳，或者您可以使用任何您想要的时间刻度。要使解码器以 30fps 解码 10fps 视频，请将 333000 添加到每个数据包的 RTP 时间戳...但让我们看看您的示例：

Frame #      RTP Time   Time between frames [ms]
[  1]               0   0
[  2]           50000   50
[  3]           90000   40
[  4]          420000   33

因此，如果您像这样(Time in ms * 100000) 设置 RTP 时间戳，您将使解码器加载和解码第 1 帧，然后加载和解码第 2 帧，但它会休眠 50 毫秒（第 1 帧和第 2 帧之间的时间差）在它绘制第 2 帧之前，依此类推...

如您所见，解码器使用 RTP 时间戳来了解何时显示每个时间戳，并且它不介意视频是以 30 fps 还是 10 fps 编码的。

另外，如果视频是 30 fps，那并不意味着每秒会有 30 个 RTP 数据包。有时可能超过 100 个，因此您无法有一个公式来确保正确的 RTP 时间戳计算。

我想这就是你需要的...希望我能帮上忙，如果我没有，请不要 -1 我... =)

【讨论】：

我不太清楚。我有一个bitstream，我正在尝试解析 nalu 并通过 rtp 发送它们。问题是我必须自己计算时间戳。目前我很确定我做错了（timestamp-lasttimestamp）* 100000。每次从比特流中读取新的 nalu 时，我都会设置新的时间戳，但这种形式会使数据包之间的时间戳不同，并且数据包 A 的时间戳可能比数据包 B 的时间戳更大！
RTP 时间戳除了帧之间的时间差外，还表示绝对时间。否则不能用于音视频同步。
@RioWing 不，您不能在 32 位整数字段中可靠地设置绝对 64 位时间值。最好将其设为相对于 0。重点是时间戳应该线性增加，相同的时间戳值应该在匹配的 AV 帧上，并且在设置时间戳时应牢记 CLOCK RATE 值，因此在 1 AV 秒内last_frame_timestamp - first_frame_timestamp = CLOCK_RATE。您有 RTP 扩展标头来存储您想要的任何其他数据，例如正确的时间戳（滴答声）等。
@Cipi 我并不是说 NTP 直接在 RTP 内部。可以计算 NTP 64bit，因为 RTCP 将 RTP 32bit 时间戳映射到 NTP。更多详细信息：SR 发送者的报告有：NTP 时间戳（64 位），NTP 格式，用于挂钟绝对日期和时间。 RTP时间戳（32bits）请参见rfc3550中的“6.4.1 SR：Sender Report RTCP Packet”

【解决方案2】：

这没有简单的公式。

用于在编码之前对帧进行采样的时刻称为PTS（表示时间戳）。它超出了编码器的范围，您必须在捕获帧时在数据流中记住它。

从那里，您有两种可能性：

H264 编码器不生成 B 帧，那么 RTP 时间戳应该是 PTS + 随机偏移量（所有流会话都相同）
如果编码器生成B-frame（或B-slices），则需要修改解码顺序，因为B-frame需要下一帧解码，所以必须先发送。

在后一种情况下，RFC6184 声明您有多种方法可以流式传输编码的 NAL 单元。

大部分流媒体软件都会使用“非交错”模式，在这种模式下，您必须将 RTP 时间戳设置为 PTS + 偏移量，但要按解码顺序发送，这样时间戳就不会单调增加。这也意味着客户端必须按接收到的顺序解码，而不是按 PTS 顺序重新排序帧。

我在这里不使用术语 DTS 是有原因的，因为您不需要解码 timestamp 来工作，只需要顺序。

RFC6184 中描述的最后一种模式是所谓的交错顺序，您可以在其中重新排序 NAL 单元。在这种情况下，您必须实现一些应用程序逻辑来重新排序单元，请参阅 RFC6184 了解详细信息。

【讨论】：

【解决方案3】：

我在我的应用程序中使用这个公式来计算 h.264 视频流的 RTP 时间戳字段：
时间戳 = LastTimestamp + Inverval(ms) * 90000 / 1000

0 毫秒后编码的 RTP 时间戳 = 0
经过 50 毫秒编码的 RTP 时间戳 = 0+50*90 = 4500
经过 40 毫秒编码的 RTP 时间戳 = 4500+40*90 = 8100
经过 33 毫秒编码的 RTP 时间戳 = 8100+33*90 = 11070

【讨论】：