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

Robert Ayrapetyan via gstreamer-devel <[email protected]>
Newsgroups gmane.comp.video.gstreamer.devel
Message-ID <CAAboi9tW4PsHqoUn8SENAO=tDoKiBbMYTaXM2-tA1QqEudws+g@mail.gmail.com>
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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.