Processing RTP stream

Question

Here is some debug info from extracting H.264 from RTP:

---

fragmentTypeBits: 7, start_bit: 0, end_bit: 64, RTP payload: 6742E01EDB02C0417845

-> Write SPS

---

fragmentTypeBits: 8, start_bit: 128, end_bit: 64, RTP payload: 68CE30A480

-> Write PPS

---

fragmentTypeBits: 6, start_bit: 128, end_bit: 64, RTP payload: 06E501AF80

-> skip

---

fragmentTypeBits: 28, start_bit: 128, end_bit: 0, RTP payload: 7C85B80000ACAC06C50A0860113B6300072AA32D7D08FDEBD2F8FC06BB80F04D3A65F1B7D0...

-> Write fragmented data... new frame

---

fragmentTypeBits: 28, start_bit: 0, end_bit: 0, RTP payload: 7C05FBED4F8D2C4F4A3B80C7149A7C506414B01E911444....

-> Write fragmented data... frame fragment

---

... (multiple times same start end bits = 0) ...

---

fragmentTypeBits: 28, start_bit: 128, end_bit: 0, RTP payload: 7C81E606C50A2F2ED1F2FDC9774972E1E4385A93CF89D225EE49A546AA6DB9FA

-> Write fragmented data... new frame

---

Is it fine to have start bit set though there was no end bit set before ?

Also, is it fine to have start / end bits set in the same time ?

And is it fine to have end bit set without having start bit set before ?

Answer 1

From RFC 3984:

Fragments of the same NAL unit MUST be sent in consecutive order with
ascending RTP sequence numbers (with no other RTP packets within the
same RTP packet stream being sent between the first and last
fragment).  Similarly, a NAL unit MUST be reassembled in RTP sequence
number order.

Basically the first fragmentation unit should have a start bit set (i.e. Fragment Type = 28) and fragmentation units should have an ascending sequence number up until the last one with the end bit set.

Having another start bit set, or an end bit without a start bit, or out-of-order sequence numbers, is not correct.