debug(gateway): log non-opus RTP payload types on the voice socket
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:
@@ -251,6 +251,16 @@ export function hookVideoReceiver(
|
||||
}
|
||||
|
||||
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)) {
|
||||
// Not video — let the existing handler (audio + screen-share audio) take it.
|
||||
original.call(receiver, msg);
|
||||
|
||||
Reference in New Issue
Block a user