GNOME Bugzilla – Bug 730999
rtph264depay only handles first NAL unit in a STAP-A packet
Last modified: 2014-05-30 14:52:07 UTC
Created attachment 277554 [details] Wireshark capture of the stream with STAP-A units Seems that gst_rtp_h264_depay_process() in gstrtph264depay.c incorrectly handles a STAP-A unit - only the first NAL unit from the STAP-A packet is sent to the gst_rtp_h264_depay_handle_nal() function. I'm using the following pipeline gst-launch-1.0 -v udpsrc multicast-group= 224.13.11.1 port=1312 multicast-iface=eth0 caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96" ! rtph264depay ! h264parse ! omxh264dec ! eglglessink , if only single NAL and FU-A packets are used the stream is successfully played, if STAP-A is used to accumulate PPS/SPS/SEI messages no output is generated, and in the log it seems that the whole packet is received, STAP-A format is verified but only the first NAL is handled: rtph264depay gstrtph264depay.c:874:gst_rtp_h264_depay_process:<rtph264depay0> NRI 1, Type 24 GST_MEMORY gstmemory.c:133:gst_memory_init: new memory 0x1185828, maxsize:45 offset:0 size:42 GST_MEMORY gstmemory.c:133:gst_memory_init: new memory 0x11446b8, maxsize:11 offset:0 size:8 GST_MEMORY gstmemory.c:133:gst_memory_init: new memory 0x10a72c8, maxsize:29 offset:0 size:26 adapter gstadapter.c:294:copy_into_unchecked: bsize 42, skip 0, csize 42 GST_MEMORY gstmemory.c:133:gst_memory_init: new memory 0x116c280, maxsize:76 offset:0 size:76 GST_MEMORY gstmemory.c:86:_gst_memory_free: free memory 0x1185828 GST_MEMORY gstmemory.c:86:_gst_memory_free: free memory 0x11446b8 GST_MEMORY gstmemory.c:86:_gst_memory_free: free memory 0x10a72c8 rtph264depay gstrtph264depay.c:673:gst_rtp_h264_depay_handle_nal:<rtph264depay0> handle NAL type 7 It seems that earlier the NAL handler was called for every NAL unit in STAP-A but this was changed in the commit f5c65a919fc4f8bf90c0c7720c92a7471a454e6c. If needed I can provide additional logs. Also I attached a wireshark caputre of the failing RTP stream. The issue is also described in an gstreamer-devel topic: http://gstreamer-devel.966125.n4.nabble.com/RTP-STAP-A-and-GStreamer-td4667293.html
commit a5a7649831f2a9506337264ad3e656ad17b96901 Author: Wim Taymans <wtaymans@redhat.com> Date: Fri May 30 16:43:44 2014 +0200 h264depay: make sure we call handle_nal for each NAL Call handle_nal for each NAL in the STAP-A RTP packet. This makes sure we correctly extract the SPS and PPS. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=730999