Video OD inject with captureStream



This is more of a challenge rather than a technical issue.

We want to implement within our application a way to inject video OD into the mixer, whilst still having full control of when the video Start/Stop/Pause.

In order to do that the only way we have managed to make it work is with the captureStream functionality where we load a video into a <video> tag and send it to the WCS server via API injection into the mixer.

This is working fine, however the quality of the video received by the mixer(and the WCS in general as we tested it in the demo player) is unpredictable.

I have a computer with 128GB of RAM, 5GHZ Processor, 12GB of Aorus GPU and a 200Mbps internet connection so I doubt is anything to do with my machine's performance also the WCS server is not at capacity, and every time I send the video, I get pixelation in the final result at specific times, usually after 20/30 seconds into the video.

Some of the OD videos get less pixelation than others, we tried encoding them with the same specs, but still can't get a consistent result.

We tried by loading videos into the <video> tag from a remote location or locally and the result seems to be the same.

Is there anything you can suggest we can do to reduce the amount of unpredictability or a different approach to reach our goal?

Just to summarize what we need to achieve is to inject videos OD into a Mixer in a seamless manner(from a UX perspective) and to have a high quality video being played within the Mixer, whilst retaining full control on the local video(start/stop/pause).

Please let me know if you need any further info
Thank you


Staff member
Good day.
There can be two bottlenecks:
1. Canvas streaming browser issues. The tab on which the video tag is placed must always be in foreground. No any dialogs on top of the tab. Otherwise, browser can skip frames or even stop sending them at all.
Also, the stream may be pixelated due to uneven key frames sending from the browser. The following WCS settings may help in this case
2. Channel bandwidth and quality between client and server issues. You have 200 Mbps declared by your provider. Actually, it is only your last mile, but on server side the channel may be not so good and wide. Also, the channel may be good via TCP, but bad via UDP which is a main WebRTC transport protocol.
Please try to switch to TCP transport: Publishing and playing stream via WebRTC over TCP
Check the stream metrics on server side: Stream parameters monitoring by REST API. If VIDEO_NACK and/or VIDEO_LOST values are grow, and switching to TCP transport does not help, you have to reduce stream resolution and bitrate or migrate the server to datacenter closer to publishing client.