0

I'm currently working on a project that involves creating a screen recorder, capturing both the display screen via the screenCapture API and the webcam using the getUserMedia API. My challenge lies in maintaining canvas drawings when the tab becomes inactive. Here's a breakdown of my situation:

  1. I've successfully implemented recording while the tab remains active.
  2. I'm using the MediaRecorder API to record the streams.
  3. I've drawn frames onto a canvas to overlay the webcam frame onto the display frame. This is accomplished by continuously drawing frames using the requestAnimationFrame method.

The issue arises when the tab becomes inactive; the requestAnimationFrame stops rendering frames. This behavior, while expected, prevents me from drawing frames during inactive tab periods. Below is the pertinent part of my drawing code, which is responsible for overlaying the webcam frame on the display frame:

function drawFrame() {
    // Code to draw the frames onto the canvas
   
    requestAnimationFrame(drawFrame);
}

drawFrame();

[Note: While a single display capture doesn't require canvas drawing, the overlay of the webcam frame necessitates this process.]

I'm actively seeking solutions to maintain canvas drawing even when the tab is inactive. My objective is to ensure continuous frame rendering to facilitate the overlay effect during the entire recording session in the Chrome browser. One more thing that I tried with setTimeout and setInterval, but it also doesn't work because when tab stays inactive, these two set their time back to 1000 ms no matter what time I set.

Any insights or guidance on overcoming this challenge would be greatly appreciated. Thank you in advance for your assistance!

Mahmudul Hasan Sayan
  • 177
  • 8
  • Basically https://stackoverflow.com/questions/40687010/canvascapturemediastream-mediarecorder-frame-synchronization/40691112#40691112 but my answer there could use some refresh. Also an alternative timer implies the use of web workers, although it's more common than the WebAudio API, I'd argue it's more at risk of being part of the throttled processes in the future than the WebAudio API. – Kaiido Aug 10 '23 at 04:51

0 Answers0