udpsink blocking mode

[Vavooon]

Hello. I have faced with the following issue:
One machine sends H264 stream captured directly from a USB camera using a
such pipeline:

gst-launch-1.0 v4l2src device=/dev/video2 ! h264parse ! rtph264pay ! udpsink
host=172.16.42.153

It works pretty fine until WiFi quality gets worse and actual throughput
becomes lower than video bitrate (8Mbit/s).
In this case I'm getting lot of messages like:

v4l2src gstv4l2src.c:976:gst_v4l2src_create: lost frames detected: count = 2
- ts: 0:00:19.067878843

I also can simulate such behavior by typing: (it sets WiFi TX rate to
6Mbit/s)
sudo iw wlp1s0 set bitrates legacy-5 6 ht-mcs-5 vht-mcs-5

I've made little investigation and at this place
https://github.com/GStreamer/gst-plugins-good/blob/master/tests/check/elements/udpsink.c#L215
GSocket is created in blocking mode (by default) so looks like entire thread
becomes blocked until there is no available space in buffer.

I believe that such behavior isn't optimal and it might be better to stream
all data to network interface which should decide whether a packet should be
sent or dropped.

So my questions are:
1. Wouldn't it be better to set socket to non-blocking mode by using
*g_socket_set_blocking* method? 
2. Is there any motivation behind current blocking behavior?




--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20191105/6692c336/attachment.html>