Reference timing & synchronisation

📘

Origin Packager must be aligned on the Wall Clock

It is very important that you take time synchronisation into account when implementing your application with broadpeak.io, as a de-synchronization of couple of seconds between your signalling system, the manifest timing and broadpeak.io might not lead to the expected outcome.

broadpeak.io allows external systems such as a scheduling system to create what we call a slot via API, or to signal specific event through in band signalling.

broadpeak.io uses the wall clock to determine whether the event scheduled is in the present, future or past. It's important that the Manifest timing, and/or the scheduling system are aligned with the wall clock or it may not result on the expected outcomes. The platform’s internal clock is synchronized through Amazon Time Sync Service. More information can be found on AWS website.

Period of consideration for Source & Service creation

When manipulating Slots or Services, there is a necessary delay for the platform to take into account the information and propagate it so it becomes effective. This delay is 15 seconds maximum, and therefore needs to be taken into consideration for scheduling.

To translate this into the implementation of the scheduling logic, this means that the Source should be created at least 15 seconds before you want to see the program scheduled onto the stream.

Example:

• If we want to schedule a program to start at 2022-12-20T16:20:00.000Z which relies on Source X, the Source should be created before 2022-12-20T16:05:00.000Z.

📘

Info

This consideration period does not apply to scte-35 in-band signalling.

Manipulation Timing

The system looks for the right place in the original manifest to insert the reference to the replacement content using the actual content PDT that it retrieves or computes directly from the manifest.

🚧

Important

Your origin packager and programming system must be synchronized in time with broadpeak.io. A manifest which presents a time that is late in comparison to the Wall Clock can lead to missed slots, or delayed slot start time.

In HLS, broadpeak.io uses PDT (Program Date Time) as reference timing for the manifest.
In MPEG-DASH, broadpeak.io uses the timing information of the segment timeline specified inside the manifest as reference timing.

Timeout management

broadpeak.io handles HTTP requests timeout in the same way for all services and users. It has timeout thresholds values defined globally that cannot be changed. We know this is not the best, and we are working giving more flexibility in the near future.

• Timeout to Origin Server(s): 5 seconds. Timeout error message returned is "Bad gateway from origin server".
• Timeout to Ad Server (s): 2 seconds. Timeout error message returned is "Bad gateway from origin server".

The platform has a global timeout of 5 seconds which includes processing time. If the whole process of retrieving Manifests, receiving a VAST/VMAP answer(s) - in the context of Ad insertion - and manipulating the manifest is not completed after 5 seconds, a timeout will be generated.

Time Precision

The process may be more or less precise when it comes to timing of contextualization commands. The way broadpeak.io handles timing precision is different based on the type of Application implemented on the platform. See the relevant sub sections.