shipped<\/a> proprietary versions of these APIs back in 2021. Those are instead exposed on the main-thread, and also handle audio. This is obviously not great for web interoperability. We\u2019ll look at both versions, and propose solutions for web developers wondering how to manage this discrepancy.<\/p>\nBoth versions promise convenience and performance. But are they equally necessary? And what about audio? Let\u2019s explore.<\/p>\n
<\/p>\n
The standard APIs<\/h2>\n
In the spec, MediaStreamTrackProcessor({track})<\/code> must be created in a worker, so you postMessage<\/code> your video track to the worker first.<\/p>\nIn this simple example, the worker then pipes the processor’s readable VideoFrame<\/code>s through a transform and into a VideoTrackGenerator<\/code>, whose .track<\/code> member is postMessage<\/code>d back to main, and assigned to a video element. Once this has been set up, the media flows in real time through the transform off the main-thread.<\/p>\n![\"\"](\"http:\/\/blog.mozilla.org\/webrtc\/files\/2024\/09\/DiagramMirroredSepia3.png\")
\nIf you’re in Safari (18 Tech Preview or newer), click the “Result”<\/em> tab to see two self-views, one regular and one sepia-toned and mirrored<\/strong>. Otherwise, don’t worry, you’ll see what it looks like in the subsequent<\/em> example, which works in all browsers!<\/p>\n