Rtspsrc fails to receive UDP packets

Application Development
1

I am trying to play video using the following pipeline:

gst-launch-1.0 rtspsrc port-range=5000-5003 location=“rtsp://admin:5ynect1cS!@192.168.30.91/streaming/channels/101” ! rtph264depay ! h264parse ! d3d11h264dec ! d3d11convert ! d3d11videosink

However I always get the following:

Could not receive any UDP packets for 5.0000 seconds, maybe your firewall is blocking it. Retrying using a tcp connection.

The tcp connection works - but my requirement is to use UDP only. In wireshark I can see the RTSP conversation is all ok and I can see UDP packets arriving to my pc on the requested port (5000). I can also see ICMP mesages stating that the port was unreachable. I have the firewall switched off on my pc and I can happily use the same pipeline on a different camera and all is fine (same port 5000).

One more thing to note is that the problematic camera plays fine using vlc using UDP.

Any suggestions would be gratefully received.

Many thanks,

Gareth

2

Those would be generated by something lower-level and outside of GStreamer, no?

Not that I have any explanation why it would work with another application but not GStreamer.

Is multicast involved?

What GStreamer version is this with?

3

Hi,
This is the latest GStreamer (1.24.5) - but have the same problem with 1.22.12.

No - this is unicast and not multicast. Yes the ICMP messages suggest to me that for some reason GStreamer has not bound to that port to receive the UDP packets. Normally I would blame the firewall (switched off) or another process binding to the same port. However, I have tried different ports and like I mentioned, a different camera is happy to send video to those same ports.

I also see this in the logs:

0:00:03.998871100 50572 00000298C7F6E840 WARN multiudpsink gstmultiudpsink.c:694:gst_multiudpsink_send_messages: warning: Error sending UDP packets
0:00:04.016514600 50572 00000298C7F6E840 WARN multiudpsink gstmultiudpsink.c:694:gst_multiudpsink_send_messages: warning: client 192.168.30.91:8312, reason: Error sending message: The system detected an invalid pointer address in attempting to use a pointer argument in a call.
0:00:04.026249300 50572 00000298C7F6E840 INFO GST_ERROR_SYSTEM gstelement.c:2282:gst_element_message_full_with_details: posting message: Error sending UDP packets
0:00:04.034058300 50572 00000298C7F6E840 INFO GST_ERROR_SYSTEM gstelement.c:2309:gst_element_message_full_with_details: posted warning message: Error sending UDP packets

Not sure if they are significant - but I don’t get those same messages when using a working camera.

4

That’s certainly novel, not sure I’ve seen that before!

Does netstat -lnp --udp show the client listening on any UDP ports?

5

I am using windows - so I captured using:
netstat -abnoq

saw this:

UDP [::]:5000 : 55208
[gst-launch-1.0.exe]
UDP [::]:5001 : 55208
[gst-launch-1.0.exe]

6

Just a quick update - the netstat output led me to wonder about gstreamer binding on the ipv6 interface - whereas wireshark shows the data coming into the ipv4 interface. So I added the parameter “protocols=4” to force ipv4 udp and the camera now works.

7

Follow up - that was nonesense I’m afraid. Sorry. That just forced rtspsrc to use tcp. So I am still wondering about my netstat output and if it means anything useful.

8

Thought I would give an update here in case it is useful for other people. The camera in question is an H264 HikVision. On closer analysis of the SDP coming from the camera - we noticed that it includes this:

m=video 0 RTP/AVP 96
c=IN IP6 ::

This explains why GStreamer was only binding to the port using ipv6. However despite this - the camera was sending video packets using ipv4 - which GStreamer was not receiving due to the above.

As we never use ipv6 - I was able to solve this by creating a callback on the “on-sdp” signal for the “rtspsrc” element and then modifying the sdp - as below:

// setup the callback
g_signal_connect(m_sourceElement, “on-sdp”, G_CALLBACK(&SynxRTSPPipeline::onSDP), this);

// callback code
void SynxRTSPPipeline::onSDP(GstElement* rtspsrc, GstSDPMessage* sdp, SynxRTSPPipeline* obj)
{
gchar* modified_address = g_strdup(“0.0.0.0”);
gchar* network_type = g_strdup(“IN”);
gchar* address_type = g_strdup(“IP4”);

// Replace the existing connection information with new values
GstSDPResult result = gst_sdp_message_set_connection(sdp, network_type, address_type, modified_address, 0, 1);

// Free the strings
g_free(modified_address);
g_free(network_type);
g_free(address_type);

}

1 Like
9

Thanks for sharing gda72!

Does you workaround affect other camera-types/models you connect to, which is not HikVision?

I’m just experiencing the same problems with a DS-2CD2135FWD-I camera, but I’m unable to find the firmware, so I’m evaluating if should go with this workaround if it affects a lot of HikVision cameras.

10

I am using this code for all camera types as I am happy to assume that all cameras we use only ever send data on ipv4 addresses anyway.

1 Like