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

Heh, I misread my bad :) Well, not sure I can explain the difference
without spending a lot of time figuring it out sorry.

On Fri, 2023-09-08 at 09:21 -0700, Robert Ayrapetyan wrote:
> "UDP send buffer errors" are visible from the `netstat -su` output.
> Also even with updated wmem settings, Jitter on the client side
> remains the same (in iperf output).
> And btw it's not 600 ms, it's 0.600 ms, so it looks pretty good.
> Thanks.
> 
> 
> 
> On Fri, Sep 8, 2023 at 4:28 AM Mathieu Duponchelle
> <[email protected]> wrote:
> > 
> > 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
> > > <[email protected]> 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.