rtpvp*depay: possibly forward might-have-been-fec PacketLost events
authorMikhail Fludkov <misha@pexip.com>
Tue, 13 Oct 2020 23:28:50 +0000 (01:28 +0200)
committerMathieu Duponchelle <mathieu@centricular.com>
Thu, 29 Oct 2020 18:56:07 +0000 (19:56 +0100)
commit346b077ae0955c24f4f841cef399735b80231cda
tree8ac8022749ccbf525fb052d6ba521ce1c308b250
parentb066441e213290adce5dd08440175b5faee0ea70
rtpvp*depay: possibly forward might-have-been-fec PacketLost events

This is ad adaptation of a Pexip patch for dealing with spurious
GstRTPPacketLost events caused by lost ulpfec packets: as FEC packets
under that scheme are spliced in the same sequence domain as the media
packets, it is not generally possible to determine whether a lost packet
was a FEC packet or a media packet.

When upstreaming pexip's ulpfec patches, we decided to drop all lost
events at the base depayloader level, and where the original patch
from pexip was making use of picture ids and marker bits to determine
whether a packet should be forwarded, this patch makes use of those
to determine whether they should be dropped instead (by removing their
might-have-been-fec field).

Spurious lost events coming out of the depayloader can cause the
decoder to stop decoding until the next keyframe and / or request a new
keyframe, and while this is not desirable it makes sense to forward
that information when we have other means to determine whether a lost
packet was indeed a FEC packet, as is the case with VP8 / VP9 payloads
when they carry a picture id.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/769>
gst/rtp/gstrtpvp8depay.c
gst/rtp/gstrtpvp8depay.h
gst/rtp/gstrtpvp9depay.c
gst/rtp/gstrtpvp9depay.h
tests/check/elements/rtpvp8.c
tests/check/elements/rtpvp9.c