[WebRTC] No audio when using G.711 16000 Hz?

[mrlt8]

Which version are you using?

v1.1.1

Which operating system are you using?

• Linux amd64 standard
• Linux amd64 Docker
• Linux arm64 standard
• Linux arm64 Docker
• Linux arm7 standard
• Linux arm7 Docker
• Linux arm6 standard
• Linux arm6 Docker
• Windows amd64 standard
• Windows amd64 Docker (WSL backend)
• macOS amd64 standard
• macOS amd64 Docker
• Other (please describe)

Describe the issue

No audio in WebRTC when using G.711 (alaw and mulaw) 16000 Hz.
Audio in other streams works as expected.

Seems to work fine if re-encoding to opus or using G711/8000.

Describe how to replicate the issue

1. start the server
2. publish with camera that is using g711/16,000 HZ
3. read with WebRTC

Did you attach the server logs?

no

Did you attach a network dump?

no

[aler9]

Please provide a server log with option "logLevel" set to "debug" in which the handshake with the camera is visible.

[mrlt8]

This is from a wyze cam which doesn't have native RTSP, so I'm using an SDK to pipe the audio and video into ffmpeg and publish to MTX.

| 2023/12/30 15:00:48 INF [RTSP] [conn 127.0.0.1:53304] opened
| 2023/12/30 15:00:48 DEB [RTSP] [conn 127.0.0.1:53304] [c->s] OPTIONS rtsp://0.0.0.0:8554/front-door RTSP/1.0
| CSeq: 1
| User-Agent: Lavf60.3.100
| 
| 
| 2023/12/30 15:00:48 DEB [RTSP] [conn 127.0.0.1:53304] [s->c] RTSP/1.0 200 OK
| CSeq: 1
| Public: DESCRIBE, ANNOUNCE, SETUP, PLAY, RECORD, PAUSE, GET_PARAMETER, TEARDOWN
| Server: gortsplib
| 
| 
| 2023/12/30 15:00:48 DEB [RTSP] [conn 127.0.0.1:53304] [c->s] ANNOUNCE rtsp://0.0.0.0:8554/front-door RTSP/1.0
| CSeq: 2
| Content-Length: 387
| Content-Type: application/sdp
| User-Agent: Lavf60.3.100
| 
| v=0
| o=- 0 0 IN IP4 127.0.0.1
| s=No Name
| c=IN IP4 127.0.0.1
| t=0 0
| a=tool:libavformat 60.3.100
| m=video 0 RTP/AVP 96
| a=rtpmap:96 H264/90000
| a=fmtp:96 packetization-mode=1; sprop-parameter-sets=J00AKedAPAET8s1AQEB8AAADAAQAAAMAoMkAAr8gAEHrf/8CgA==,KO48gAA=; profile-level-id=4D0029
| a=control:streamid=0
| m=audio 0 RTP/AVP 97
| b=AS:128
| a=rtpmap:97 PCMA/16000/1
| a=control:streamid=1
| 
| 2023/12/30 15:00:48 INF [RTSP] [session 0f43d095] created by 127.0.0.1:53304
| 2023/12/30 15:00:48 DEB [RTSP] [conn 127.0.0.1:53304] [s->c] RTSP/1.0 200 OK
| CSeq: 2
| Server: gortsplib
| 
| 
| 2023/12/30 15:00:48 DEB [RTSP] [conn 127.0.0.1:53304] [c->s] SETUP rtsp://0.0.0.0:8554/front-door/streamid=0 RTSP/1.0
| CSeq: 3
| Transport: RTP/AVP/TCP;unicast;interleaved=0-1;mode=record
| User-Agent: Lavf60.3.100
| 
| 
| 2023/12/30 15:00:48 DEB [RTSP] [conn 127.0.0.1:53304] [s->c] RTSP/1.0 200 OK
| CSeq: 3
| Server: gortsplib
| Session: 5938e4e0379f4111a0e6860763694215
| Transport: RTP/AVP/TCP;unicast;interleaved=0-1
| 
| 
| 2023/12/30 15:00:48 DEB [RTSP] [conn 127.0.0.1:53304] [c->s] SETUP rtsp://0.0.0.0:8554/front-door/streamid=1 RTSP/1.0
| CSeq: 4
| Session: 5938e4e0379f4111a0e6860763694215
| Transport: RTP/AVP/TCP;unicast;interleaved=2-3;mode=record
| User-Agent: Lavf60.3.100
| 
| 
| 2023/12/30 15:00:48 DEB [RTSP] [conn 127.0.0.1:53304] [s->c] RTSP/1.0 200 OK
| CSeq: 4
| Server: gortsplib
| Session: 5938e4e0379f4111a0e6860763694215
| Transport: RTP/AVP/TCP;unicast;interleaved=2-3
| 
| 
| 2023/12/30 15:00:48 DEB [RTSP] [conn 127.0.0.1:53304] [c->s] RECORD rtsp://0.0.0.0:8554/front-door RTSP/1.0
| CSeq: 5
| Range: npt=0.000-
| Session: 5938e4e0379f4111a0e6860763694215
| User-Agent: Lavf60.3.100
| 
| 
| 2023/12/30 15:00:48 INF [path front-door] runOnReady command started
| 2023/12/30 15:00:48 INF [RTSP] [session 0f43d095] is publishing to path 'front-door', 2 tracks (H264, Generic)
| 2023/12/30 15:00:48 DEB [RTSP] [conn 127.0.0.1:53304] [s->c] RTSP/1.0 200 OK
| CSeq: 5
| Server: gortsplib
| Session: 5938e4e0379f4111a0e6860763694215

[aler9]

After some testing it was discovered that Chrome currently blocks PCMU or PCMA tracks with a sample rate different than 8000, due to this line:
https://webrtc.googlesource.com/src/+/refs/heads/main/api/audio_codecs/g711/audio_decoder_g711.cc#26

Therefore we cannot add support for 16khz PCMU/PCMA in WebRTC.

[aler9]

even though we could convert PCMA/PCMU to PCM, which seems to be supported....

[github-actions]

This issue is mentioned in release v1.8.3 🚀
Check out the entire changelog by clicking here