chrome-extension://kx9m2p/screen_capture.js:88 Uncaught (in promise) DOMException: Failed to execute ‘start’ on ‘MediaRecorder’: The codec ‘vp09.00.41.08’ is not supported.
I’m tracking this exact error bombing out on the compliance queue every time an agent hits the Start Session button. Chrome 126.0.6478.127 is fully rolled out across the floor, and the Genesys screen recording policy is configured to auto-capture desktop plus active tab. The extension manifest is v3, and if you monitor the extension logs, the service worker stays alive for about twelve seconds before the recorder throws that codec error. Storage quota definitely isn’t the culprit here. I checked chrome://quota-internals and the extension only sits at fourteen megabytes, which is well within the safe threshold. [Screenshot: chrome://quota-internals showing 14MB usage] Could you verify if any agents have third-party overlay extensions running that might be intercepting the capture stream?
I went ahead and tweaked chrome://flags/#enable-unsafe-webgpu to disabled since the dev docs explicitly mention it breaks WebRTC pipeline handshakes on newer builds. Unfortunately, that didn’t change a thing. I also reverted #disable-hardware-acceleration back to enabled because forcing the fallback to software rendering tanks the frame rate below fifteen frames per second, which directly violates the audit requirement. Looking at the console output, the MediaRecorder object initializes fine, but the mimeType negotiation falls back to video/webm;codecs=vp9 and then immediately chokes. [Screenshot: Console logs showing mimeType negotiation fallback] Are you seeing any WEBRTC or CODEC warnings in chrome://webrtc-internals right before the drop?
On the backend side, the Architect flow is routing the session ID to the recording storage bucket via the standard v2 endpoint, but the payload never actually lands. Queue supervisors are getting ghost sessions that just show Recording Failed after the fifteen-second timeout. I tried forcing vp8 in the extension config JSON, but the platform overrides it back to vp9 during the handshake phase. If you dig into the fallback logic in the extension’s record.js, it looks like it’s checking for chrome.runtime.lastError but never actually catches the DOMException, which is why the service worker just crashes instead of gracefully degrading. [Screenshot: record.js fallback logic highlighting the missing catch block] Have you verified that the platform’s codec whitelist actually permits vp09.00.41.08 in the current policy build?
{
"recordingConfig": {
"codec": "vp9",
"bitrate": 2500000,
"frameRate": 30,
"storagePath": "/compliance/sessions"
}
}
The extension logs keep repeating the exact same stack trace every forty-five seconds. The service worker restarts, navigator.mediaDevices.getDisplayMedia() resolves successfully, and then MediaRecorder.start() drops the ball. [Screenshot: Repeating stack trace in extension logs] If you can pull the full chrome://extensions verbose logging output and check the MediaRecorder capabilities array, that would help narrow down whether this is a Chrome 126 regression or a platform-side codec mismatch. Let me know what the isTypeSupported() checks return for vp9 on your end.