webrtcsink: Zero Framerate and Significant Packet Loss While Accessing Stream on Local Network

[Mathieu Duponchelle]

That's interesting, but I can't speak to iperf's implementation. I
notice a rather large measured jitter (600 milliseconds), perhaps this
is over the threshold for your WebRTC client, resulting in late packets
being considered lost?

Where did you notice these "UDP send buffer errors" messages by the
way?

On Tue, 2023-09-05 at 11:00 -0700, Robert Ayrapetyan via gstreamer-
devel wrote:
> UPD: noticed growing of "UDP send buffer errors" on the server side,
> so updating:
> 
> sudo sysctl net.core.wmem_default=2097152
> sudo sysctl net.core.wmem_max=2097152
> 
> resolved the issue (still not ideal but at least I can watch a stream
> now).
> I'm still curious about why iperf3, even when configured with
> identical bandwidth settings and UDP packet sizes, doesn't seem to
> create any problems.
> 
> 
> On Mon, Sep 4, 2023 at 2:53 PM Robert Ayrapetyan
> <robert.ayrapetyan at gmail.com> wrote:
> > 
> > Hello.
> > I'm running a typical pipeline:
> > ```
> > gst-launch-1.0 -v \
> >         ximagesrc display-name=$DISPLAY show-pointer=true
> > use-damage=false remote=true blocksize=16384 enable-navigation=true
> > \
> >           ! video/x-raw,framerate=60/1 \
> >           ! timeoverlay \
> >           ! videoconvert \
> >           ! video/x-raw \
> >           ! x264enc bitrate=10000 tune=zerolatency
> > speed-preset=ultrafast threads=4 key-int-max=120 \
> >           ! video/x-h264,profile=high \
> >           ! queue leaky=1 \
> >           ! wrs. \
> >           pulsesrc provide-clock=true do-timestamp=true \
> >           ! queue leaky=1 \
> >           ! wrs. \
> >           webrtcsink name=wrs enable-data-channel-navigation=true
> > meta="meta,name=game-stream-cpu1" congestion-control=disabled
> > signaller::uri="ws://0.0.0.0:8443"
> > ```
> > When accessing this stream from localhost, everything works
> > perfectly well:
> > ```
> > framesReceived/s] 60.0030
> > [bytesReceived_in_bits/s] 25754416.4
> > jitter 0
> > packetsLost 728
> > packetsReceived 5756420
> > ```
> > 
> > But when trying to access the same from my home network, it becomes
> > unusable.
> > 
> > Here are home network characteristics:
> > 
> > Server:
> > iperf3 -V -f m --server
> > ```
> > iperf 3.9
> > Linux xxx 5.10.0-25-amd64 #1 SMP Debian 5.10.191-1 (2023-08-16)
> > x86_64
> > -----------------------------------------------------------
> > Server listening on 5201
> > -----------------------------------------------------------
> > Time: Mon, 04 Sep 2023 21:23:45 GMT
> > Accepted connection from 192.168.1.153, port 50250
> >       Cookie: saapgwns5kemmgf3btdqgcinyrkstyiylki5
> >       Target Bitrate: 25000000
> > [  5] local 192.168.1.113 port 5201 connected to 192.168.1.153 port
> > 54554
> > Starting Test: protocol: UDP, 1 streams, 1285 byte blocks, omitting
> > 0
> > seconds, 30 second test, tos 0
> > [ ID] Interval           Transfer     Bitrate         Total
> > Datagrams
> > [  5]   0.00-1.00   sec  2.98 MBytes  25.0 Mbits/sec  2430
> > ...
> > - - - - - - - - - - - - - - - - - - - - - - - - -
> > Test Complete. Summary Results:
> > [ ID] Interval           Transfer     Bitrate         Jitter
> > Lost/Total Datagrams
> > [  5]   0.00-30.06  sec  89.6 MBytes  25.0 Mbits/sec  0.000 ms
> > 0/73101 (0%)  sender
> > [  5] (receiver statistics not available)
> > CPU Utilization: local/sender 1.5% (1.5%u/0.0%s), remote/receiver
> > 0.0%
> > (0.0%u/0.0%s)
> > ```
> > 
> > Client:
> > iperf3 --udp -R -V -t 30 -b 25000000 --length 1285 -f m -c
> > 192.168.1.113
> > ```
> > iperf 3.14
> > Darwin m-w2vckv206y 22.6.0 Darwin Kernel Version 22.6.0: Wed Jul  5
> > 22:22:05 PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T6000 arm64
> > Control connection MSS 1448
> > Time: Mon, 04 Sep 2023 21:23:45 UTC
> > Connecting to host 192.168.1.113, port 5201
> > Reverse mode, remote host 192.168.1.113 is sending
> >       Cookie: saapgwns5kemmgf3btdqgcinyrkstyiylki5
> >       Target Bitrate: 25000000
> > [  5] local 192.168.1.153 port 54554 connected to 192.168.1.113
> > port 5201
> > Starting Test: protocol: UDP, 1 streams, 1285 byte blocks, omitting
> > 0
> > seconds, 30 second test, tos 0
> > [ ID] Interval           Transfer     Bitrate         Jitter
> > Lost/Total Datagrams
> > [  5]   0.00-1.00   sec  3.01 MBytes  25.2 Mbits/sec  0.569 ms 
> > 0/2455 (0%)
> > ...
> > - - - - - - - - - - - - - - - - - - - - - - - - -
> > Test Complete. Summary Results:
> > [ ID] Interval           Transfer     Bitrate         Jitter
> > Lost/Total Datagrams
> > [  5]   0.00-30.06  sec  89.6 MBytes  25.0 Mbits/sec  0.000 ms  0/0
> > (0%)  sender
> > [  5]   0.00-30.00  sec  89.2 MBytes  25.0 Mbits/sec  0.600 ms
> > 162/72981 (0.22%)  receiver
> > iperf Done.
> > 
> > But WebRTC metrics on the client are following:
> > ```
> > framesReceived/s] 0
> > [bytesReceived_in_bits/s] 19407028.4
> > jitter 0.016
> > packetsLost 451666
> > packetsReceived 1879638
> > ```
> > 
> > I believe 0 frames issue may be attributed to packet loss, as a 24%
> > loss of packets can render UDP entirely impractical.
> > 
> > Questions:
> > 1. Is my understanding correct?
> > 2. Why are iperf3 results so much different?
> > 2. How to debug/trace the reason for packet loss for WebRTC?
> > 
> > Thanks.