udpsink or udpsrc loosing data

[Holger]

I try to stream a webcam video from one windows machine to another one.

Server:
$GL \
ksvideosrc device-index=0 \
!  videoscale method=0 add-borders=false ! video/x-raw,width=$WIDTH,height=$HEIGHT ! videoconvert \
! x264enc tune=zerolatency rc-lookahead=0 intra-refresh=true sync-lookahead=0 speed-preset=1 ! h264parse \
! rtph264pay  ! udpsink   host=$DST_IP  port=$DST_PORT

Client:
$GL udpsrc port=$DST_PORT ! application/x-rtp, payload=96  ! rtph264depay  ! h264parse \
! avdec_h264  ! glimagesink sync=false

The quality on the client side is very bad, it seems that many packages are lost (bitrate is about 2Mbit - x264enc default). If I start server and client on the same machine, the quality is much better but there are still image errors.

If I don't use udpsrc / sink and do everything in one pipeline, the image quality is good.

$GL \
ksvideosrc device-index=0 \
!  videoscale method=0 add-borders=false ! video/x-raw,width=$WIDTH,height=$HEIGHT ! videoconvert \
! x264enc tune=zerolatency rc-lookahead=0 intra-refresh=true sync-lookahead=0 speed-preset=1 ! h264parse  ! rtph264pay \
! application/x-rtp, payload=96  ! rtph264depay  ! h264parse ! avdec_h264  ! glimagesink sync=false

In another post I read, that most packages will be dropped by udpsink immediately. I think this is the problem - but I'm not sure. But I don't know how to solve this.

[Dmitry Valento]

Try to use wireshark utility - it allows to analyze RTP streaming (i.e.
dropping rate and much more).

If the problem in loosing UDP packets - add rtpbin and rtprtxqueue
elements to server and rtpbin to client like this:

http://gstreamer-devel.966125.n4.nabble.com/RTP-retransmission-mechanism-in-gstreamer-1-2-0-tp4663965p4664003.html

On 11/25/2016 04:30 PM, Holger wrote:

> I try to stream a webcam video from one windows machine to another one.
>
> Server:
> $GL \
> ksvideosrc device-index=0 \
> !  videoscale method=0 add-borders=false !
> video/x-raw,width=$WIDTH,height=$HEIGHT ! videoconvert \
> ! x264enc tune=zerolatency rc-lookahead=0 intra-refresh=true
> sync-lookahead=0 speed-preset=1 ! h264parse \
> ! rtph264pay  ! udpsink   host=$DST_IP  port=$DST_PORT
>
> Client:
> $GL udpsrc port=$DST_PORT ! application/x-rtp, payload=96  ! rtph264depay  !
> h264parse \
> ! avdec_h264  ! glimagesink sync=false
>
> The quality on the client side is very bad, it seems that many packages are
> lost (bitrate is about 2Mbit - x264enc default). If I start server and
> client on the same machine, the quality is much better but there are still
> image errors.
>
> If I don't use udpsrc / sink and do everything in one pipeline, the image
> quality is good.
>
> $GL \
> ksvideosrc device-index=0 \
> !  videoscale method=0 add-borders=false !
> video/x-raw,width=$WIDTH,height=$HEIGHT ! videoconvert \
> ! x264enc tune=zerolatency rc-lookahead=0 intra-refresh=true
> sync-lookahead=0 speed-preset=1 ! h264parse  ! rtph264pay \
> ! application/x-rtp, payload=96  ! rtph264depay  ! h264parse ! avdec_h264  !
> glimagesink sync=false
>
> In another post I read, that most packages will be dropped by udpsink
> immediately. I think this is the problem - but I'm not sure. But I don't
> know how to solve this.

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

[Tim Müller]

On Fri, 2016-11-25 at 05:30 -0800, Holger wrote:

Hi Holger,

> Server:
> $GL \
> ksvideosrc device-index=0 \
> !  videoscale method=0 add-borders=false !
> video/x-raw,width=$WIDTH,height=$HEIGHT ! videoconvert \
> ! x264enc tune=zerolatency rc-lookahead=0 intra-refresh=true
> sync-lookahead=0 speed-preset=1 ! h264parse \
> ! rtph264pay  ! udpsink   host=$DST_IP  port=$DST_PORT

Try adding a queue after ksvideosrc and perhaps also before udpsink.

> Client:
> $GL udpsrc port=$DST_PORT ! application/x-rtp, payload=96  !
> rtph264depay  !
> h264parse \
> ! avdec_h264  ! glimagesink sync=false

Try adding an .. ! rtpjitterbuffer latency=500 ! .. after udpsrc, and a
queue after avdec_h264.

Cheers
 -Tim

--
Tim Müller, Centricular Ltd - http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-4]

Le vendredi 25 novembre 2016 à 05:30 -0800, Holger a écrit :
> ksvideosrc device-index=0 \
> !  videoscale method=0 add-borders=false !
> video/x-raw,width=$WIDTH,height=$HEIGHT ! videoconvert \
> ! x264enc tune=zerolatency rc-lookahead=0 intra-refresh=true
> sync-lookahead=0 speed-preset=1 ! h264parse \
> ! rtph264pay  ! udpsink   host=$DST_IP  port=$DST_PORT

You should adapt the bitrate on the encoder to control the quality.

>
> Client:
> $GL udpsrc port=$DST_PORT ! application/x-rtp, payload=96  !
> rtph264depay  !
> h264parse \
> ! avdec_h264  ! glimagesink sync=false

You should use rtpjitterbuffer on the receiving side.

>
> The quality on the client side is very bad, it seems that many
> packages are
> lost (bitrate is about 2Mbit - x264enc default). If I start server
> and
> client on the same machine, the quality is much better but there are
> still
> image errors.
>
> If I don't use udpsrc / sink and do everything in one pipeline, the
> image
> quality is good.

It's the lack of a jitterbuffer that causes this really.

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

[Holger]

> Try to use wireshark utility - it allows to analyze RTP streaming (i.e.
> dropping rate and much more).
Wireshark tells me that about 3% of the packages are lost. The machines are connected together by a cable (GigE) and also if the server and client are running on the same machine on a local socket the errors occur.

> If the problem in loosing UDP packets - add rtpbin and rtprtxqueue elements to server and rtpbin to client like this: ...

The latency must be as low as possible, so I'm not sure if this is the best solution.


> Try adding a queue after ksvideosrc and perhaps also before udpsink.
> Try adding an .. ! rtpjitterbuffer latency=500 ! .. after udpsrc, and a queue after avdec_h264.

This didn't change anything... only the latency increased.

> It's the lack of a jitterbuffer that causes this really.

Any other ideas?

[Holger]

I tried the same scripts with two linux machines - everything is working fine there.
I'll check if the problem is on the server or client side on windows the next week.