View Full Version : "Censor" feature or macro

02-25-2015, 11:40 AM
We have the option to tweak the input's brightness, contrast, etc but if we are in a live event and something unwanted happened (someone cursing, obscene content, etc), having a way to defocus or distort the video and audio -or just muting that audio- temporarily with the push of a button, would be greatly helpful. Probably more important for the output (not sure if it should affect also the Clean output or not, but probably should as it's no gfx overlay really) but having the option also per-input would be useful.

If not having a 'censor' button in the control surface itself, having a macro able to do something like that and mapping it to a key in the keyboard or launchpad would work too.

Could this be done already, maybe using a macro overlaying a defocusing dsk and muting the audio?

Thanks all,

02-25-2015, 12:49 PM
You could create a macro that, for example, did and FTB and muted the main audio output.

02-25-2015, 12:52 PM
A macro could mute the audio, but there is no 'blur' or defocus effect in the TriCaster, so that would have to be going to a different image or something else to obscure the screen.

02-25-2015, 02:55 PM
You can create a translucent diffusing image in Photoshop (just a 50% gray frame would work, or maybe with a slight pattern), and import it as a frame buffer to Tricaster. Then, your macro will just need to assign that frame buffer still to a DSK (if they're all used for something else regularly) and then turn on the DSK layer.

02-26-2015, 07:56 AM
If someone uses bad language on the program, its already to late to 'mute' them. its already happened. In TV they have a censor button downstream of the program in master control. this allows them to have a delay and ability to censor anything that does happen. I dont see this being a feature tricaster woudl need to do??

02-26-2015, 08:27 AM
Time-shifting is mandatory in certain markets, and without adding much more, I can perhaps say that the value of something in this realm is at least 'on our radar'.

02-26-2015, 08:55 AM
I don't see where you'd even need a Macro necessarily - have audio set to "follow video", and if someone starts cursing and/or using obscene gestures, hit BLACK on the Program row, or better yet GFX where you have some sort of default graphic waiting. Just tried it, using DDR1 (with audio) as my source, DDR1 audio being set to "Follow Video" in the audio mixer. With DDR1 being "live" on Program, I can instantly hot-punch BLACK or GFX1 and audio is MUTED, as well as removing the offending video of course.

That said, I love Macros, easy and powerful, learn how to work them and enjoy the fruits of your efforts.

Jeff Pulera
Safe Harbor Computers

02-26-2015, 09:41 AM
I need to do some testing but I believe you could use a ddr delayed playback of the pgm mix going to your secondary output to the stream output or an external encoder. Then write a macro that skips forward 5-10 seconds over a bad situation. The key would be to have the complete stream delayed by 30-60 seconds to give you time to play with.

Workflow synopsis:
Start Recording of PGM output
Add recording file to DDR2
Delegate DDR2 into ME8
Assign ME8 to the 2nd Output
Assign the stream input to 2nd output ( this I have to confirm is possible) otherwise use an external encoder

Create a Panic macro that skips ahead 7 seconds on the DDR play functions.
Add into the macro a cover image on ME8's Overlay via a FrameBuffer graphic.

It might take some tweaking of this workflow but I believe the basic concept will work.
if it doesn't then an external 3Play would always work using a similar slip and slide playback and external encoder.
On of our clients has to do this when feeding some time sensitive feeds (as close to real time as possible) while at the same time a public feed that has to be delayed from realtime by a minimum of 30 seconds.

02-26-2015, 10:30 AM
I need to do some testing but I believe you could use a ddr delayed playback of the pgm mix ...I wouldn't say it's absolutely insurmountable, but there is an obstacle on consider to this method (at this time). When you add the file to the DDR to begin 'delayed' playback, it invariably gets an 'out point'. This would need to be continually reset to prevent the DDR playhead from reaching it.

As I mentioned ... on our radar.