MythEclipse/GMW
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

debug(gateway): log non-opus RTP payload types on the voice socket

Browse Source 
Temporary diagnostic to answer definitively whether Discord actually delivers
video RTP to the bot when someone screen-shares / turns on camera. Both
videoReceiver and screenShareAudio rely on ssrcMap emitting videoSSRC from
voice-state updates, and NO "Video SSRC appeared"/"Screen-share video started"
lines appear even after a real share+record. This logs any RTP packet whose
payload type is not Opus (120) so we can tell: (a) video RTP IS arriving but
attribution/signaling fails, vs (b) Discord sends no video at all to a
non-signaling receiver. Remove this log once the gap is understood.
This commit is contained in:
asepharyana
2026-08-30 22:44:17 +07:00
committed by asepharyana
parent 5241f9784a
commit 260ecabb3c
1 changed files with 10 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
services/discord-gateway/src/modules/voice-recording/videoReceiver.ts
+10
View File
@@ -251,6 +251,16 @@ export function hookVideoReceiver(
} }
const payloadType = msg[1] & 127; const payloadType = msg[1] & 127;
// DIAGNOSTIC: log any RTP packet whose payload type isn't Opus (120) so we
// can confirm whether Discord actually delivers video RTP to the bot.
// (Non-opus = video/experimental; if we see these, video IS arriving and the
// attribution/signaling below is the only gap.)
if (payloadType !== 120) {
logger.warn(
{ payloadType, ssrc: msg.readUInt32BE(8) },
"DIAG: non-opus RTP packet on voice socket",
);
}
if (!VIDEO_PAYLOAD_TYPES.has(payloadType)) { if (!VIDEO_PAYLOAD_TYPES.has(payloadType)) {
// Not video — let the existing handler (audio + screen-share audio) take it. // Not video — let the existing handler (audio + screen-share audio) take it.
original.call(receiver, msg); original.call(receiver, msg);