Remote translation control

Introduction:
Today, we are using 2 types of online translation, this applies to all our broadcasted lessons/events/congresses etc.

1st type is well known and based on local translation, i.e. translators are sitting in BB center and translating using locally generated video/audio sources without usage of any SW add-ons. While this type has problems of its own this document is not concentrated on this type at all.

2nd type starting to become if not primary but important role in our day to day broadcast. Moreover, if properly developed, it can in near future simplify our broadcast solutions for congresses/ outdoor events etc. and give us fairly chip options to extend our coverage for other languages. This is remote translation. This type currently covering Italian, Spanish, French German and partially English languages in our daily broadcast and is heavily based on SW add-ons to enable it.

Problem starts that currently there is no complete solution for easy operation neither from server side i.e. there aren’t easy options to control/solve issues during broadcast, nor from client side i.e. it fairly complicated for each translator to set up environment required for translation. And since most of translators are not technical experts often it becomes a headache to enable/support it. Below you will find detailed problem description and suggestions for solving it.

Problem description:
In order to enable remote translation we need to steadily supply to end point following streams:
1. Real time video. This requirement is coming from translators demand to see what actually happens for easing up the translation process.
2. Real time multiple audio streams. This requirement is coming from fact that we need to give option for translator to choose from available language sources best option he can translate from.
3. Receive steady real time audio stream to rebroadcast it to appropriate language stream from BB center.

In addition there is a requirement to change remote translator audio settings to optimize it performance for broadcast or solve issues.

Today’s solutions are not applying most of the issues and somehow just providing minimal solutions for streaming. Here is list of today’s solution and their complications:
1. Third party conference e.g. Skype. Skype is used in the past to receive audio stream from translators. Major problem that appeared we can’t rely on 3rd parties. And Skype showed that servers are tending to fall in most impropriate timing. So recently we’ve stopped from using it.
2. Flash based conference servers. Today we are using this in order to provide video & audio streams to the remote translator. This technology is unfriendly in usage for our purposes, needs multiple streams for each language and is totally out of date. Of course in addition this requires additional servers (currently used Moscow servers for it)
3. Team Talk 4. This is most promising technology allowing fairly easy to provide multiple audio and video streams. However for our purpose (since it is designed to support multiple conferences) we need to open 3 different TT4 applications with different settings each to use it for translation. In order to use it without issues requires technical knowledge and basic understanding of broadcast system. Which most of our translators not have. In addition there is no option to control client settings in order to fix problems when required on client side, thus it might take fairly long time to get connected to translator and explain him what he need to fix. Although currently usage of TT4 is messy this is our best solution for today.

Motivation:
Summarizing all above we are desperately need dedicated application for remote translators to enable steady and clean broadcast. This will allow us to simplify all our translation boxes (i.e. unify solution to remote style) remove unnecessary hardware (mixers, wiring etc.) and leave only central control mixer for it. In addition to all above when having such an application (which answers our needs) all technical congresses preparations will become much easier and chipper, since there won’t be required build up translation boxes, if we could rely on our remote translators solutions.

So having such application will tremendously ease work of everyone, clean unnecessary equipment and most important will clean or neglect our broadcast issues.
Solution proposal:
Team Talk 4 is providing its sources for $$$. Having such a basic library it will be doable in reasonable timeframe, make our application, based on functionality of TT4 client to support our needs, without requirements to design it from scratch, real time complications etc.

Having such ability will open us a new space of solutions for broadcast requirements, easy groups visualization during broadcasts, scalable solution to add on other languages and in future will give us ability to improve quality of our broadcast for most of the scenarios we are using today.
Requirement Summary:
1. Server configured client
2. Running in parallel: 2 input streams (choosed by client from server defined list) and 1 output audio stream
a. Video stream (real timed video to screen)
b. Audio stream (source language to headphones)
c. 1 output audio stream from mic to BB broadcast center. This one should to be able to connect to regular TT4 client for other reasons (e.g. Saturdays etc.)
3. Should be ability to control from server microphone level + mute/unmute
a. May be with some delay 1-2 sec(i.e. you can periodically ask for server updates)


Detailed description
Server configuration and control:
During application run, it should read from the predefined server following configuration fields:

1. TT4 server and all required configuration settings to run TT4 client
a. This should be done only on initialization phase
2. Basic usage configuration
a. This should include microphone volume settings etc.
3. List of dedicated for translation active audio streams (input)
a. This should be checked constantly (but not real time) and have ability to change input audio stream on each point of application run
4. List of dedicated for translation active video streams (input)
a. This should be checked constantly (but not real time) and have ability to change input video stream on each point of application run
5. Ability to choose what output stream should be connected to.
a. This should be done either once during application init phase by user, or have some sort of lock mechanism in order not give user ability easily change it (should not be required) since 1 application should support only 1 language.
6. Ability to change microphone level from server control application
a. This should be done during application active phase
b. Ability to indicate application (from server side) either it using
i. local settings – i.e. locally defined by user
ii. server settings – i.e. defined from server
iii. Indicate user that it working with server controlled mic. settings
c. Override options should be cleaned on each application init phase
7. Ability to supply to server average (rms)/peak microphone level (i.e. rms/peak levels for several seconds)
8. Friendly indication to user that he/she that control room want to chat/talk with him
a. This is not requirement for chat but for some indication of chat requirement
b. This should have easily understandable visualization
9. Indication from user that he wants to chat with control room
a. This is not requirement for chat but for some indication of chat requirement
b. This should have easily understandable visualization

Audio/video stream:
During application run should be provided ability to change input audio/video stream, and once (or through lock mechanism) output audio stream should be chosen.


Client UI:
Should be minimalistic and simple. Should include:
1. Choosing audio/video streaming
2. Constant level mic. Control
3. Constant indication of mic average(rms)/peak level (real time)
4. Current mic. level settings (with ability to easily change it )
5. Indication of remote/local mic. level usage
6. Indication of chat requirements (see server settings)
7. Help button (this should give indication to control room)
8. Required local configuration (may be done through) menu.
a. Should include all required local settings e.g. sound card settings etc.

Server control UI:
Should be minimalistic and simple. Prefarably web based. Should include:
1. Ability to see all active channels.
a. Including mic average/peak levels
b. Current mic level settings (on each client)
2. Ability to indicate chat request
3. Indication of help request from client
4. Ability to override/unoverride client mic settings

Rest of the configuration settings should be done through other application and up to programmer/broadcast to decide what UI/requirements needed to supply to server required configuration information.



Last edited Apr 15, 2011 at 10:17 AM by dimanichh, version 3