fix: don't break render loop if video is paused

[holzgeist]

@1egoman and one more PR from me (hopefully I manage to be more responsive in the future 😄)

Whenever the "Video is paused" warning showed up in the logs, blurring stopped completely for both local and remote participants.
I'm not sure how to trigger this condition, for me on latest Firefox it happens once every ~5-10 times when enabling the video after reloading the page. It's probably some race condition in the browser or my code. In any case, the current handling breaks the render loop completely which is an easy fix

I'm not sure if requestAnimationFrame is the correct way to go, setTimeout(renderLoop, 0) works as well.

[changeset-bot]

🦋 Changeset detected

Latest commit: c0461fc

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@livekit/track-processors	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[1egoman]

@holzgeist Thanks for the pull request! I will admit I am a bit hesitant to introduce something like this without understanding the problem a bit deeper as introducing a delay like this could mask larger problems.

There is a related type of "hack" being done in client-sdk-js here that might be worth looking at. It mentions track processor restarting as a potential cause, maybe that is a factor that could be leading to the issue?

@lukasIO The git blame says you wrote the above linked code. Do you remember any context about what it was trying to solve and does it potentially seem related to what this issue is addressing?

[lukasIO]

This makes sense to me!

I don't think this change would be delaying anything but rather just ensure that we keep the loop running while the source is paused.

as we're using the requestAnimationFrame pattern further down in the render loop, too, I'd just stick with that.

[1egoman]

Ah, I seem to have misread the diff when I first looked at this. I think that's fairly reasonable, sounds good.