rtp: also support shrinking the extension data
authorMatthew Waters <matthew@centricular.com>
Tue, 24 Aug 2021 11:26:54 +0000 (21:26 +1000)
committerGStreamer Marge Bot <gitlab-merge-bot@gstreamer-foundation.org>
Tue, 19 Oct 2021 03:26:57 +0000 (03:26 +0000)
commitb7d4d371f9d1049a3aff01387f67e7ca839d1bf1
treec718ed147fdffb46c63ccd210964535ea9e80ee9
parent320bc6362b44a11771f856a520a1b4f0a25c2dfa
rtp: also support shrinking the extension data

Currently the extension data length specified in the RTP header would
say it was shorter then the data serialised to a packet. When
combining the resulting buffer, the underlying memory would still
contain the extra (now 0-filled) padding data.

This would mean that parsing the resulting RTP packet would potentially
start with a number of 0-filled bytes which many RTP formats are not
expecting.

Such usage is found by e.g. RTP header extension when allocating the
maximum buffer (which may be larger than the written size) and shrinking
to the required size the data once all the rtp header extension data has
been written.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1146>
subprojects/gst-plugins-base/gst-libs/gst/rtp/gstrtpbuffer.c
subprojects/gst-plugins-base/tests/check/libs/rtp.c