gstreamer/tests/check
Matthew Waters ea61714c70 rtph26*depay: drop FU's without a corresponding start bit
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.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/730>
2020-09-21 08:08:38 +00:00
..
elements rtph26*depay: drop FU's without a corresponding start bit 2020-09-21 08:08:38 +00:00
generic Remove autotools build system 2019-10-14 11:04:18 +01:00
pipelines Remove autotools build system 2019-10-14 11:04:18 +01:00
gst-plugins-good.supp valgrind: suppress Cond error coming from gnutls 2019-08-08 14:39:17 +00:00
meson.build tests: don't pull in all -bad plugin, only allow the one we need 2020-06-09 15:23:40 +01:00