GNOME Bugzilla – Bug 617164
[rtph264pay] SPS/PPS in provided sprop-parameter-sets never sent on timeout
Last modified: 2010-05-18 15:54:26 UTC
the config parameters are never sent on timeout (config-interval) since neither the SPS or PPS are saved to the list. good (old): 0:00:02.073201786 3290 0x8caf60 DEBUG rtph264pay gstrtph264pay.c:697:gst_rtp_h264_pay_payload_nal:<rtph264pay0> time to send SPS/PPS 0:00:02.073210601 3290 0x8caf60 DEBUG rtph264pay gstrtph264pay.c:632:gst_rtp_h264_pay_send_sps_pps:<rtph264pay0> inserting SPS in the stream 0:00:02.073219954 3290 0x8caf60 DEBUG rtph264pay gstrtph264pay.c:678:gst_rtp_h264_pay_payload_nal:<rtph264pay0> Processing Buffer with NAL TYPE=7 0:00:02.073229127 3290 0x8caf60 DEBUG rtph264pay gstrtph264pay.c:718:gst_rtp_h264_pay_payload_nal:<rtph264pay0> NAL Unit fit in one packet datasize=12 mtu=1400 0:00:02.073239579 3290 0x8caf60 DEBUG rtph264pay gstrtph264pay.c:766:gst_rtp_h264_pay_payload_nal:<rtph264pay0> Copying 12 bytes to outbuf 0:00:02.073308565 3290 0x8caf60 DEBUG rtph264pay gstrtph264pay.c:644:gst_rtp_h264_pay_send_sps_pps:<rtph264pay0> inserting PPS in the stream 0:00:02.073321913 3290 0x8caf60 DEBUG rtph264pay gstrtph264pay.c:678:gst_rtp_h264_pay_payload_nal:<rtph264pay0> Processing Buffer with NAL TYPE=8 0:00:02.073331597 3290 0x8caf60 DEBUG rtph264pay gstrtph264pay.c:718:gst_rtp_h264_pay_payload_nal:<rtph264pay0> NAL Unit fit in one packet datasize=4 mtu=1400 0:00:02.073342541 3290 0x8caf60 DEBUG rtph264pay gstrtph264pay.c:766:gst_rtp_h264_pay_payload_nal:<rtph264pay0> Copying 4 bytes to outbuf 0:00:02.073408917 3290 0x8caf60 DEBUG rtph264pay gstrtph264pay.c:778:gst_rtp_h264_pay_payload_nal:<rtph264pay0> NAL Unit DOES NOT fit in one packet datasize=3940 mtu=1400 bad (n0:00:07.794516103 3353 0xc54520 DEBUG rtph264pay gstrtph264pay.c:661:gst_rtp_h264_pay_payload_nal:<rtph264pay0> time to send SPS/PPS (timeout 1) 0:00:07.794525288 3353 0xc54520 DEBUG rtph264pay gstrtph264pay.c:743:gst_rtp_h264_pay_payload_nal:<rtph264pay0> NAL Unit DOES NOT fit in one packet datasize=5594 mtu=1400 ew):
Created attachment 159882 [details] [review] always look for pps/sps Fixes the sps/pps insertion based on config-interval.
Created attachment 160695 [details] [review] Extract SPS/PPS from provided sprop-parameter-sets for re-sending To elaborate, problem seems to be that if a specific sprop-parameter-sets string is provided, then the SPS/PPS in there are never considered/extracted, nor are SPS/PPS parsed from stream anymore. As such, there are no SPS/PPS to re-send when config-interval expires (although that is working fine by itself). Attached patch parses the provided sprop-parameter-sets for SPS/PPS and will keep those around for later resending. The stream itself is still not parsed for SPS/PPS though, as such info is explicitly provided in this case, and may in some cases as such not be in-stream anyway.
commit 4cff2e2c6788107c9a76daf379123ae854117d0f Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Mon May 10 11:14:39 2010 +0200 rtph264pay: extract SPS and PPS from property provided parameter set ... so it can also be regularly inserted into the stream if so configured. Fixes #617164.
verified.