Think Before You Start - Your Client Probably Hasn't!
A question I get asked often is what is the right setup to webcast our events?
Obviously there are myriad answers to this - the previous section will have set you up for this comment! However, assuming your client really knows nothing, then there is a triage I would commonly take them through to work out what answer to give:
- • Why are you doing the event? What are the KPIs of its success?
- • When is it?
- • Is anyone else involved in the production? (Do we have autonomy?)
- • Who will be watching it?
- • On what devices/where?
- • Will it be paid for? (Does it need DRM?)
That said, we have a common set of core functions that will almost certainly require:
- • Production of the final composition of image to be broadcast
- • Transmission (including compression) of that image to the “hub” of the distribution network
- • Understanding of or responsibility for distribution to a target range of devices
The first and most important thing for me is to have a “logical schematic” laid out that becomes the central reference for anyone involved. That will almost invariably start on notepaper during an initial call, and will evolve through a whiteboard session into a simple, but smartly drawn, diagram that will vary as little as possible during the event delivery.
That schematic will show the interfaces between different parts of the production chain, show what different teams within will be expecting from each other. It will show the technology hardware deployed, the network links, and the core service, and applications/functions deployed. Often data flows will be drawn to show where traffic is likely to be routed, and to help stimulate thinking about scaling issues as - for example - second sources are added for resilience or as audiences grow more edges are required to meet demand, etc.
There are more thoughts and details about schematics and diagrams in Chapter 9, Section 9.2.