RTP STAP-A and GStreamer

[Rūdolfs Bundulis]

Hi,

I am encountering issues with GStreamer and STAP-A RTP packetization mode.
I have a software that encodes a H264 stream and sends it over RTP and I am
using GStreamer to play it back on an embedded system? If I use only FU-A
and singe NAL packets everything seems to be fine, but when I use STAP-A
GStreamer gives no output, seems that it parses only the first NAL unit
from the STAP-A packet.

The GStreamer pipeline is: 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 , I
am running this on a Raspberry Pi, GStreamer version is 1.0.10

I've looked at the packets via Wireshark, and the STAP-A format seems fine,
2 bytes NAL length in network order and then the payload.

What I see from the GStreamer log is:

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

I seems that it correctly splits the chunks but only first one is handled.
And then after the next FU-A with a slice is sent, since PPS and SPS are
both not present an event is pushed back from the parser:

GST_EVENT gstpad.c:4771:gst_pad_send_event_unchecked:<udpsrc0:src> [00m
have event type custom-upstream event at time 99:99:99.999999999:
GstForceKeyUnit, all-headers=(boolean)true

which corresponds to the code:

    } else if (rtph264depay->sps->len == 0 || rtph264depay->pps->len == 0) {
      /* Down push down any buffer in non-bytestream mode if the SPS/PPS
haven't
       * go through yet
       */
      gst_pad_push_event (GST_RTP_BASE_DEPAYLOAD_SINKPAD (depayload),
          gst_event_new_custom (GST_EVENT_CUSTOM_UPSTREAM,
              gst_structure_new ("GstForceKeyUnit",
                  "all-headers", G_TYPE_BOOLEAN, TRUE, NULL)));
      gst_buffer_unmap (nal, &map);
      gst_buffer_unref (nal);
      return NULL;
    }

Wireshark packet:

00000000  80 e0 00 00 00 00 00 00  00 00 00 00 38 00 26 27 ........ ....8.&'
00000010  42 40 28 95 a0 12 01 b6  c0 44 00 00 03 00 04 00 B@(..... .D......
00000020  00 03 00 cb 81 00 00 16  e3 60 00 00 e4 e1 cb de ........ .`......
00000030  f8 1b 43 86 54 00 04 28  ce 3c 80 00 16 06 00 07 ..C.T..( .<......
00000040  80 6d dd 00 6d dd 40 01  07 00 00 03 00 00 03 00 .m..m. at . ........
00000050  00 04 80

So if we look at the packet:
00 26 = 38 bytes of data
after 38 bytes we have 00 04 = 4 bytes of data
after 4 bytes of data we have 00 16 = 22 bytes of data

Seems to me that the packet is formatted correctly. Can anyone give me some
guidance?


Best Regards,
Rudolfs Bundulis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140530/1b133597/attachment-0001.html>