MPEG-ES H.264 视频从 RTP 转换为 MPEG-TS

发布于 2024-10-07 19:54:17 字数 2366 浏览 2 评论 0原文

我正在实现 ATSC-153 规范，该规范基本上根据 RFC 3984 在 IP/UDP/RTP 中广播基线 H.264 视频配置文件。帧的片段正在重新组装，并且大部分在嵌入式上播放我正在使用的处理器，尽管由于我试图追踪的某种原因而发生了一些损坏。我试图将其封装到 MPEG-TS 中，以便在 Windows (VLC) 上渲染它以进行一些比较，但由于某种原因我遇到了困难。由于某种原因，VLC、TSReader 和 MPEG2Repair 无法找到视频。我正在执行的步骤如下，对于我收到的 SPS 或 PPS H.264 帧来说是相同的。

创建PAT/PMT，PMT PID 0x11，视频类型为0x1b，视频PID为0x280，PCR pid为0x1fff（无pcr）。实际上，我每15帧左右就通过一次。
我将访问单元定界符 NAL 编号 9 附加到帧中。我认为这应该附加到传输中的所有 H.264 帧中。主要图片类型是 1（0x30 字节），它对应于基线配置文件的 I,P。
我向其附加一个 PES 标头帧，其中包含来自 RTP 标头的 PTS。
我附加了 4 字节 TS 标头。在帧开始时，我设置了 PUS 位。我为序列保留了一个 4 位计数器。
任何不能被 184 整除的剩余字节，我都会放入一个带有适配字段（长度设置，标志字节设置为 0）的 TS 数据包中，并填充（或填充）到剩余字节。

我确保流以 SPS 帧开始。据我了解（可能不太好），这应该包含一张真实的图片。 SPS 帧在流中约为 15K 字节。这是第一个 TS 数据包的转储：

000  47 42 80 15 00 00 01 E0 00 00 81 80 05 21 AA BB
010  9A 91 00 00 00 01 09 30 00 00 00 01 67 42 C0 14
020  9A 44 0D 0F 9F F8 00 08 00 08 04 00 00 00 01 68
030  DE 24 88 00 00 00 01 E6 87 26 D6 AC FA 58 78 24
040  0E EB B5 5B 02 AF 6C EB E1 E4 9F 35 BD 61 56 F8
050  4A 4E 58 00 00 01 65 88 80 20 20 9E 1D 60 20 61
060  15 D8 02 70 F9 29 C0 00 40 C6 23 3A 76 CA 78 9A
070  4D 7D 79 C1 6E 94 3E A8 76 50 4B F7 B5 B0 40 2B
080  52 48 93 B1 A2 4A 4F 3D 14 F1 B8 7E FA 98 91 FE
090  DC EB 0F 11 BF EB D1 B8 E0 3F 5A C2 91 2D FA 83
0A0  03 EF 51 10 18 D6 D4 77 90 78 97 D5 BF 94 61 6D
0B0  69 53 AF 5B 42 FE D7 A3 9D 21 81 FC

在上面的数据包中，我收到的实际视频帧从偏移量 0x18 开始。之前的一切都是我添加的。 00 00 00 01 67 应表示 SPS。

对于通常运行 3Kbytes 到 4Kbytes 的 PPS 框架，以下是它的转储：

000  47 42 80 19 00 00 01 E0 00 00 81 80 05 21 AA BB
010  F8 51 00 00 00 01 09 30 00 00 00 01 41 9A 01 05
020  0F FF F4 3D FE 9B 0F 5E BE 18 15 20 00 50 0D 51
030  58 32 47 F5 E7 86 1B 43 A6 FC F5 CA 64 A6 7F CF
040  CB 94 C8 1F F2 FF 51 F7 7D DD DF 51 97 C7 C2 97
050  77 77 77 BB B4 8B E9 B8 F9 70 D7 75 7A FF D8 64
060  E8 C1 CE 06 83 58 20 24 00 06 66 70 BC DB C3 8D
070  8E 6D FC 8C 5D EE 0D CC 63 61 13 BB F3 0F 0D 9F
080  28 82 54 E4 A2 1C 21 55 BF F3 C1 86 7D 90 47 52
090  5F C2 C6 E2 A7 3B 5E E0 A1 5B A2 C3 24 05 97 17
0A0  A1 B2 04 22 78 F0 6F 0C DA 85 DC 7C E3 69 85 2B
0B0  AC 02 02 01 9C 5B 11 DC B5 85 44 CE

我只能期望此时我缺少一些需要的东西，我做错了一些事情，或者使用 RFC 3984 重新组装的东西出现了严重错误，以至于解码器无法将其识别为视频。

因此，我将从问前两个问题开始。规格中是否有我遗漏的内容？从转储中看到，我是否正确实施了这一点？

非常感谢。

原文

I am implementing the ATSC-153 specification, which basically broadcasts a baseline H.264 video profile in IP/UDP/RTP according to RFC 3984. The fragments of the frames are being re-assembled, and for the most part plays on the embedded processor I am working with, albeit with some corruption that is occurring for some reason that I am trying to track down. I am trying to encapsulate this into an MPEG-TS in order to render it on Windows (VLC) for some comparison, and I am having difficulty for some reason. VLC, TSReader and MPEG2Repair cannot find the video for some reason. The steps I am doing are as follows, which are the same for either the SPS or PPS H.264 frames I am receiving.

Create a PAT/PMT, PMT PID 0x11, video type is 0x1b, video PID is 0x280, and PCR pid is 0x1fff (no pcr). Actually, I through this in every 15 frames or so.
I append to the frame the access unit delimiter, NAL number 9. I think this is supposed to be appended to all H.264 frames in a transport. The primary pic type is 1 (0x30 byte), which would correspond to the I,P of the baseline profile.
I append to this a PES header frame, which has the PTS from the RTP header.
I append the 4 byte TS header. At the start of the frame, I set the PUS bit. I keep a 4 bit counter for the sequence.
Any left over bytes not divisible by 184, I put into a TS packet with an adaptation field (length set, flag byte set to 0) padded (or stuffed) to the remaining bytes.

I make sure the stream starts with an SPS frame. To my understanding (which may not be to great), this should contain an actual picture. The SPS frames are 15K bytes or so in the stream. Here is a dump of the first TS packet:

000  47 42 80 15 00 00 01 E0 00 00 81 80 05 21 AA BB
010  9A 91 00 00 00 01 09 30 00 00 00 01 67 42 C0 14
020  9A 44 0D 0F 9F F8 00 08 00 08 04 00 00 00 01 68
030  DE 24 88 00 00 00 01 E6 87 26 D6 AC FA 58 78 24
040  0E EB B5 5B 02 AF 6C EB E1 E4 9F 35 BD 61 56 F8
050  4A 4E 58 00 00 01 65 88 80 20 20 9E 1D 60 20 61
060  15 D8 02 70 F9 29 C0 00 40 C6 23 3A 76 CA 78 9A
070  4D 7D 79 C1 6E 94 3E A8 76 50 4B F7 B5 B0 40 2B
080  52 48 93 B1 A2 4A 4F 3D 14 F1 B8 7E FA 98 91 FE
090  DC EB 0F 11 BF EB D1 B8 E0 3F 5A C2 91 2D FA 83
0A0  03 EF 51 10 18 D6 D4 77 90 78 97 D5 BF 94 61 6D
0B0  69 53 AF 5B 42 FE D7 A3 9D 21 81 FC

In the packet above, the actual video frame I received starts at offset 0x18. Everything before that I added. The 00 00 00 01 67 should indicate SPS.

For the PPS frame, which typically run 3Kbytes to 4Kbytes, the following is the dump from it:

000  47 42 80 19 00 00 01 E0 00 00 81 80 05 21 AA BB
010  F8 51 00 00 00 01 09 30 00 00 00 01 41 9A 01 05
020  0F FF F4 3D FE 9B 0F 5E BE 18 15 20 00 50 0D 51
030  58 32 47 F5 E7 86 1B 43 A6 FC F5 CA 64 A6 7F CF
040  CB 94 C8 1F F2 FF 51 F7 7D DD DF 51 97 C7 C2 97
050  77 77 77 BB B4 8B E9 B8 F9 70 D7 75 7A FF D8 64
060  E8 C1 CE 06 83 58 20 24 00 06 66 70 BC DB C3 8D
070  8E 6D FC 8C 5D EE 0D CC 63 61 13 BB F3 0F 0D 9F
080  28 82 54 E4 A2 1C 21 55 BF F3 C1 86 7D 90 47 52
090  5F C2 C6 E2 A7 3B 5E E0 A1 5B A2 C3 24 05 97 17
0A0  A1 B2 04 22 78 F0 6F 0C DA 85 DC 7C E3 69 85 2B
0B0  AC 02 02 01 9C 5B 11 DC B5 85 44 CE

I can only expect at this point I am missing something that is needed, I have done something incorrectly, or something with the RFC 3984 re-assembly is going horribly wrong so much so the decoders don't recognize this as video.

So, I'll start by asking the first two questions. Is there anything from the specs that I am missing? Did I implement this correctly as seen from the dumps?

Many thanks.

分享到QQ

分享到微博