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 the GStreamer-devel mailing list archive at Nabble.com.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le mardi 05 novembre 2019 à 07:44 -0600, Vavooon a écrit :

> 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?

Then the sender would get EAGAIN, dropping on EAGAIN is racy.

> 2. Is there any motivation behind current blocking behavior?

GStreamer works in pushback model, so blocking is what we usually
expect. Dropping packets can be a lot worst then dropping complete
images, but in this case the camera is producing H264, so it will be
broken any way.

Btw, did you try uvch264src ? I believe it implements keyframe request,
if you use a proper RTP pipeline, you'll get a key frame request to fix
it quickly.

>  
>
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Vavooon]

Thanks, I have already compiled GStreamer with used g_socket_set_blocking
method and tried both behaviors.
I'd say it doesn't get any better compared to blocking mode. However I
didn't learn well current packet drop logic inside UDP sending loop, so
maybe it could be handled better.

Thanks for suggestion about uvch264src, but AFAIK the camera I use (which is
based on Sonix SN9C292B) uses it's own API for H264 controls so it's not
capable of extended features like re-sending keyframes and changing bitrate
in the way uvch264src supports.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel