How many languages are you looking to broadcast?

The most common method is using 2 languages per stream and using left and right channels to separate the audio sources at each end.
You can get more complicated with other technology used for this (SAP), which is easier for those receiving, yet essentially the functionality is the same.

As KJ4AWR said, this would be complicated. If you were using just two languages it could be possible by putting one language audio output on the left channel only, and the second on the right. You would need to advise the viewer to setup their player to only play one channel of audio though, either left of right.

But with five, I would think the best way would be to have an individual output for each language, each streaming to a different destination.

However, as far as I can see the max streaming outputs one can have is three. (Not entirely sure if that is correct, but seems to be on my HD version of vMix) You would need five times the bandwidth for this though, and a very powerful machine I presume.

Checking youtube, it seems they don't do text translations on live feeds sadly.

Perhaps you could output a master feed with the host language on one machine, and split that via NDI or external SDI connections to some basic machines that could take the master feed, add the translation via a microphone and restream it to their own steam via something like OBS? (Having 5 vmix licenses and machines might be a stretch!)

The company I work for, ZipDX, offers multilingual conference calling that can be leveraged to deliver simultaneous interpretation in support of streaming events.

https://www.zipdx.info/m...ingual-conference-calls/ for an overview.

Interpreters connect to our service using our WebRTC-based web phone, which carries their audio and gives them control of interpretation. They hear the live feed from the main stream. They return the interpretation into the other language.

Your live production can feed the service via SIP.

You create another SIP connection for each additional language.

The alt language feeds can be 100% clean (just the interpreter) or have some of the original floor audio mixed under, to give a sense of continuity.

The interpreters can be remotely located, which helps with costs.

There is some latency as all connection are over IP pathways, but this is generally acceptable with respect to the alternate languages.

Since we are fundamentally a conference service, you get telephone access as well as SIP. In the SIP realm we support G.711, G.722 and Opus codecs.

The cost of the service is quite low. The major cost is hiring the interpreters.