H.264 Video From RTP to MPEG-TS

[davroslyrad]

Greetings,

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.

1. 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.

2. 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.

3. I append to this a PES header frame, which has the PTS from the RTP header.

4. 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.

5. 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 65 88 80 20 20 9E 1D 60 20
040 61 15 D8 02 70 F9 29 C0 00 40 C6 23 3A 76 CA 78
050 9A 4D 7D 79 C1 6E 94 3E A8 76 50 4B F7 B5 B0 40
060 2B 52 48 93 B1 A2 4A 4F 3D 14 F1 B8 7E FA 98 91
070 FE DC EB 0F 11 BF EB D1 B8 E0 3F 5A C2 91 2D FA
080 83 03 EF 51 10 18 D6 D4 77 90 78 97 D5 BF 94 61
090 6D 69 53 AF 5B 42 FE D7 A3 9D 21 81 FC EB B6 06
0A0 0F D2 48 7F D3 AF 69 AE 74 79 AA 47 9A 8D FA 57
0B0 77 2F D6 4A F9 42 CA DE 37 87 6B 42

My PAT/PMT packets are as follows:

010 47 40 00 10 00 00 B0 0D 00 00 DF 00 00 00 01 E0
020 11 1B E8 64 57 FF FF FF FF FF FF FF FF FF FF FF
030 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
[padded to 188 bytes]

010 47 40 11 10 00 02 B0 17 00 01 C1 00 00 FF FF F0
020 02 1B 02 80 F0 00 0F 7F FF F0 00 55 2D D9 4D FF
030 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
[padded to 188 bytes]


I would not think I would necessarily need the PAT/PMT.

From the SPS, it looks as though all the NAL numbers (0x09, 0x67, 0x68, 0x65) are as expected.

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.

[kieranrk]

VLC and other players are picky about the length and other PSI information present in the stream in order to play correctly. This doesn't mean that your muxing is invalid.

[davroslyrad]

Okay, I am rather embarrassed. The problem with the above encapsulation is with the PMT. At offset 0x20 is the program info length, which is set to 2. This should be 0, as there is no program info. Sorry about the post.