From b84201bf8163bd58cb9611616732017b7487242a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tim-Philipp=20M=C3=BCller?= Date: Tue, 8 Aug 2017 18:58:11 +0100 Subject: [PATCH] rtph265pay: don't add trailing zeros to VPS/PPS/SPS This would happen if input is byte-stream with four-byte sync markers instead of three-byte ones. The code that scans for sync markers will place the start of the NALU on the third-last byte of the NALU sync marker, which means that any additional zeros may be counted as belonging to the previous NALU instead of being part of the next sync marker. Fix that so we don't send VPS/SPS/PPS with trailing zeros in this case. See https://bugzilla.gnome.org/show_bug.cgi?id=732758 --- gst/rtp/gstrtph265pay.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/gst/rtp/gstrtph265pay.c b/gst/rtp/gstrtph265pay.c index da7b7c6f31..9a597e0602 100644 --- a/gst/rtp/gstrtph265pay.c +++ b/gst/rtp/gstrtph265pay.c @@ -733,7 +733,7 @@ next_start_code (const guint8 * data, guint size) * sense because our search 'alphabet' is binary - 0 & 1 only. * This allow us to simplify the general BM algorithm to a very * simple form. */ - /* assume 1 is in the 3th byte */ + /* assume 1 is in the 3rd byte */ guint offset = 2; while (offset < size) { @@ -785,6 +785,10 @@ gst_rtp_h265_pay_decode_nal (GstRtpH265Pay * payloader, || GST_H265_NAL_PPS == type) { GstBuffer *nal; + /* trailing 0x0 are not part of the VPS/SPS/PPS */ + while (size > 0 && data[size - 1] == 0x0) + size--; + /* encode the entire NAL in base64 */ GST_DEBUG_OBJECT (payloader, "found %s (type 0x%x), size %u", type == GST_H265_NAL_VPS ? "VPS" : type == GST_H265_NAL_SPS ?