Using your metadata configuration to send an end-of-break marker
Most streaming platforms use some form of commercial insertion that plays specific commercials to the listener. One of these platforms is Triton Digital. Since the Triton Digital encoder is fully integrated with the Z/IPStream R/2 we will use this in our examples. However, the principles applied here can be used more generally.
In order for these commercials to start and stop, the Trition encoder software requires there be some notification at the beginning of a commercial break and a notification at the end. However, in some cases (formats that are all talk, for example) the automation system may play commercials and then just stop without playing any other events or being able to send some notification that the break has ended.
In this case, the commercial insertion for the streaming listener might never stop.
If your automation system cannot send an end break after a spot break, or if your talk show format jumps right from a spot break back to program, you can use the metadata configuration in the Z/IPStream R/2 to force the sending of an end-of-break marker.
Briefly, what we will do is use the start of each commercial to insert our own end break markers. This marker is canceled automatically by the starting of the next commercial if there is one. When the commercials from the automation system stop, and there are no more, the end break marker is NOT canceled and is sent to the Triton encoder.
Before proceeding, make sure that you are familiar with how metadata works with the Z/IPStream R/2 when using Triton. You can find more information here. Make sure that you download the appropriate version of the Metadata2UI Metadata Manager app that matches the version running on your Z/IPStream R/2. We will be using many of the features in the Metadata2UI Metadata Manager app to make this work. Make sure that you read these instructions closely before configuring this in your Z/IPStream R/2.
Implementing the delay
Log into the Z/IPStream using the Metadata2UI Metadata Manager app. What we're going to do is add a delay internally that will take into account the length of the spot, and to send an ENDBREAK message once the spot has elapsed. The flow will look like this:
Here's how we will configure this in the Metadata2UI Metadata Manager app:
- We start with the Client Source input. We are using a TCP connection here, but this connection method is up to you. This is how we receive metadata from the automation system. You very likely already have this configured, as this needs to be done regardless of implementing this delay.
- This then goes to your Translator. Again, this is something that you would need to send your metadata to Triton regardless of this delay method.
- This step is where things change from a typical configuration. Here we set up our Control function. This looks at our Translator (note the name of the Translator above being Category Changes and the value of the Source field in the Control function). The Display Name, as always here, is a friendly name, but you need to make sure that the Match code field matches what we have here. Make sure that you have cue_type=="BREAK". Make sure the dropdown is set to Lua expression as well.
- The next step is to add the Delay function. This is an important part of the configuration. What this is doing is taking the duration of the spot, and adding 300 ms. The 300ms pad is important because it will allow the delay to reset if a new spot comes through. If you didn't have this padding, then it might send the ENDBREAK command too early. Note that the Source field (our example is AvAir BREAK Filter) is the friendly name of the Control function in the previous step.
- We then add a new Translator, which reads our Delay function as its source. This translator is different than the first in that you only need two rules: the mount field, and a field to set BREAK to ENDBREAK, as we do in our translator below.
- Next, we need to make the Aggregator. This will combine our two Translators together. All you need to do is add the names of your above Translators to the Sources field in the Aggregator.
- And finally, we create our Output function. The Source is the name of our Aggregator. The Template and Destination fields depend on how you are sending metadata to Triton.
Let us know how we can help
If you have further questions on this topic or have ideas about how we can improve this document, please contact us.