Hello. I have faced with the following issue:
<br>
One machine sends H264 stream captured directly from a USB camera using a such pipeline:
<br>
<br>
<code>
gst-launch-1.0 v4l2src device=/dev/video2 ! h264parse ! rtph264pay ! udpsink host=172.16.42.153
</code>
<br>
<br>

It works pretty fine until WiFi quality gets worse and actual throughput becomes lower than video bitrate (8Mbit/s).
<br>
In this case I'm getting lot of messages like:
<br>
<br>
<code>
v4l2src gstv4l2src.c:976:gst_v4l2src_create:<v4l2src0> lost frames detected: count = 2 - ts: 0:00:19.067878843
</code>
<br>
<br>
I also can simulate such behavior by typing: (it sets WiFi TX rate to 6Mbit/s)
<br>
<code>
sudo iw wlp1s0 set bitrates legacy-5 6 ht-mcs-5 vht-mcs-5
</code>
<br>
<br>
I've made little investigation and at this place https://github.com/GStreamer/gst-plugins-good/blob/master/tests/check/elements/udpsink.c#L215
<br>
GSocket is created in blocking mode (by default) so looks like entire thread becomes blocked until there is no available space in buffer.
<br>
<br>
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.
<br>
<br>
So my questions are:
<br>
1. Wouldn't it be better to set socket to non-blocking mode by using <b>g_socket_set_blocking</b> method? 
<br>
2. Is there any motivation behind current blocking behavior?
<br>


        
        
        
<br/><hr align="left" width="300" />
Sent from the <a href="http://gstreamer-devel.966125.n4.nabble.com/">GStreamer-devel mailing list archive</a> at Nabble.com.<br/>