7

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

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

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

先感谢您。

4

3 回答 3

14

无论您的编码器以 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

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

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

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

我想这就是您所需要的...希望我有所帮助，如果我没有，请不要-1我... =）

于 2010-05-30T22:35:43.297 回答
6

There is no simple formula for this.

The instant used for sampling the frame before encoding is called the PTS (presentation timestamp). It's out of the scope of the encoder, you must remember it in your data flow when you capture the frames.

From there, you have 2 possibilities:

  1. The H264 encoder does not generate B-frame, then the RTP timestamp should be the PTS + random offset (the same for all streaming session)
  2. If the encoder generate B-frames (or B-slices), then the decoding order needs to be modified, since B-frame requires the next frame to be decoded, so it must be sent before.

In the latter case, the RFC6184 states that you have multiple way to stream the encoded NAL units.

Most of the streaming software will use the mode called "Non interleaved", in which, you must set the RTP timestamp to the PTS + offset, but send them in the decoding order so the timestamp will not increase monotonically. This also means the client will have to decode in the order received and not reorder the frames in the PTS order.

I'm not using the term DTS here for a reason, because you don't need the decoding timestamp for this to work, only the order.

The last mode described in RFC6184 is the so-called interleaved order where you can reorder the NAL units. In that case, you have to implement some application logic to reorder the units, refer to RFC6184 for details.

于 2017-01-09T15:02:58.403 回答
0

我在我的应用程序中使用这个公式来计算 h.264 视频流的 RTP 时间戳字段：
Timestamp = 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

于 2020-06-14T23:33:09.393 回答