rtph264pay: don't add trailing zeros to PPS/SPS
authorPhilip Craig <phil@blackmoth.com.au>
Sat, 5 Jul 2014 06:21:48 +0000 (06:21 +0000)
committerTim-Philipp Müller <tim@centricular.com>
Thu, 23 Nov 2017 08:36:15 +0000 (09:36 +0100)
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 SPS/PPS with trailing
zeros in this case.

https://bugzilla.gnome.org/show_bug.cgi?id=732758

gst/rtp/gstrtph264pay.c

index 0135b4c..73f080a 100644 (file)
@@ -701,6 +701,10 @@ gst_rtp_h264_pay_decode_nal (GstRtpH264Pay * payloader,
   if (SPS_TYPE_ID == type || PPS_TYPE_ID == type) {
     GstBuffer *nal;
 
+    /* trailing 0x0 are not part of the SPS/PPS */
+    while (size > 0 && data[size - 1] == 0x0)
+      size--;
+
     /* encode the entire SPS NAL in base64 */
     GST_DEBUG ("Found %s %x %x %x Len=%u", type == SPS_TYPE_ID ? "SPS" : "PPS",
         (header >> 7), (header >> 5) & 3, type, size);