Skip to content

rtph26*depay: drop FU's without a corresponding start bit

Matthew Waters requested to merge ystreet/gst-plugins-good:rtph264-interrupted-fu into master

If we have not received a FU with a start bit set, any subsequent FU data is not useful at all and would result in an invalid stream.

This case is constructed from multiple requirements in RFC 3984 Section 5.8 and RFC 7798 Section 4.4.3. Following are excerpts from RFC 3984 but RFC 7798 contains similar language..

The FU in a single FU case is forbidden:

A fragmented NAL unit MUST NOT be transmitted in one FU; i.e., the Start bit and End bit MUST NOT both be set to one in the same FU header.

and dropping is possible:

If a fragmentation unit is lost, the receiver SHOULD discard all following fragmentation units in transmission order corresponding to the same fragmented NAL unit.

The jump in seqnum case is supported by this from the specification instead of implementing the forbidden_zero_bit mangling:

If a fragmentation unit is lost, the receiver SHOULD discard all following fragmentation units in transmission order corresponding to the same fragmented NAL unit.

A receiver in an endpoint or in a MANE MAY aggregate the first n-1 fragments of a NAL unit to an (incomplete) NAL unit, even if fragment n of that NAL unit is not received. In this case, the forbidden_zero_bit of the NAL unit MUST be set to one to indicate a syntax violation.

Edited by Matthew Waters

Merge request reports