Automated production of live events

Abstract

Embodiments of the invention provide methods and systems that automatically control production for live event coverage. The rules which dictate how the live events are displayed are customisable by a user. The system takes live streams of video data relating to the coverage of a live event and combines it with the custom rules and live metadata to provide instructions for displaying the live streams. The system may output a forecast to the user, showing them how the live streams will be displayed, based on the current instructions. This allows the user to provide further instructions to change the custom rules if the forecasted output is not satisfactory. For example, the event related metadata may concern data relating to the progress of an event that is continuously updated in real-time, commonly used in sporting events for bet settling purposes.

Description

[0001] Automated Production of Live Events

[0002] Technical Field

[0003] Embodiments of the present invention described herein relate to methods and systems for automating the coverage production for the broadcast of live events. In particular, some embodiments of the invention combine individual live events into a broadcast channel under automated software control, wherein the automation is dictated by rules which can be customised by each user.

[0004] Background to the Invention

[0005] The coverage of live events such as sporting events for broadcast is ordinarily undertaken by a "gallery" of staff manually undertaking function specific roles with specialised equipment (for example, sound, videotape (VT) replay, graphics overlay, and vision switching), as illustrated in Figure 1. The hardware requirements and the reliance on these function specific roles makes the manual production of event coverage a labour-intensive process, which is turn is costly for the broadcaster. Moreover, due to the large volumes of data being handled in these production galleries, there is an increased chance of human error. Automated play out of pre-recorded content of a fixed duration is commonplace within the broadcast sector. However, this requires a person to manually select a sequence of events to be broadcast. Once the content is being broadcast, the automated play out cannot be changed unless a member of staff manually overrides the coverage to choose one event in favour of another. Therefore, a way of eliminating the requirement for manual production is needed in order to provide automated play out of live content.

[0006] The present applicant's earlier International patent application WO 2018 / 060715 gives further technical details of the operation of its methods and systems, the entire contents of which necessary for understanding the present invention being incorporated herein by reference.

[0007] Summary of the Disclosure

[0008] Embodiments of the invention provide methods and systems that automatically control production for live event coverage. The rules which dictate how the live events are displayed are customisable by a user. The system takes live streams of video data relating to the coverage of a live event and combines it with the custom rules and live metadata to provide instructions for displaying the live streams. The system may output a forecast to the user, showing them how the live streams will be displayed, based on the current instructions. This allows the user to provide further instructions to change the custom rules if the forecasted output is not satisfactory. For example, the event related metadata may concern data relating to the progress of an event that is continuously updated in real-time, commonly used in sporting events for bet settling purposes.

[0009] In the Applicant's previous automated production system (described in WO 2018 / 060715), rules used to determine the distribution of live events were hard coded into the system by a software engineer. If a customer wanted these rules to be changed to fit their needs, they would need the software engineer to recode the rules which could take a long time, depending on the availability of the software engineer.

[0010] The present disclosure addresses the above problem, by providing user-customisable rulesets. In the present application, the rules can be easily and frequently changed by an admin user without the need for a software engineer. This allows a customer to change the rules determining the distribution of events whenever they want to keep up with their current needs and / or to fine-tune the distribution if the present rules are not outputting a live event distribution that they are satisfied with. The present application allows a user to change the rules determining the live event distribution right up until when the live stream output(s) are finalised and distributed to clients for display. To do this, the user creates a custom set of rules (a "ruleset") via a user interface (UI). The UI is then able to upload the custom ruleset to the automated production system. In some embodiments, the UI may be an Excel document, which is then uploaded to the system. In others, the UI may be a custom designed UI which is interacted with by the user to specify the desired rules. The UI can then upload the changes to the system which will action the changes. In both cases, the system may read the uploaded ruleset file, parse the data and, if the rule changes are valid, immediately action the changes. The system reads the uploaded data file and updates the ruleset accordingly.

[0011] In view of the above, from a first aspect, the present disclosure relates to a computer- implemented live event coverage production method. The method comprises receiving user instructions to create a custom ruleset via a user interface. The custom ruleset comprises a list of customisable rules which, in use, collectively prescribe a ranking for a live event based on one or more attributes of said live event. A live event with a higher rank will be a higher priority event and a live event with a lower rank will be a lower priority event. The method further comprises receiving a plurality of live streams of video data relating to a respective plurality of live events; receiving, in real-time, metadata relating to the plurality of live events, wherein the metadata comprises data indicative of the one or more attributes of the plurality of live events, ranking, based on the custom ruleset and the metadata, the plurality of live events relating to the plurality of live streams of video data in dependence on the one or more attributes of the said plurality of live events, and generating, by a processor, instructions for displaying the plurality of live streams of video data. The instructions comprise instructions for: (i) distributing the plurality of live streams of video data across one or more channels in dependence on the ranking, and (ii) a temporal order in which the plurality of live streams of video data is to be displayed in dependence on the ranking.

[0012] Several advantages are obtained from embodiments according to the above described aspect. For example, users can specify their own bespoke custom rules for distributing the live streams of the live events. Because the forecasting rules are configurable and not hardcoded into the system, rules can be changed quickly by a user. After changing the ruleset, the updated rules take immediate effect. This allows the user to quickly and easily change rules to arrive at a live stream distribution that they are happy with.

[0013] In some embodiments, the method further comprises producing at least one live stream output of video data in accordance with the instructions, wherein the at least one live stream output comprises an arrangement of the plurality of live streams of video data, and wherein each of the plurality of live stream outputs corresponds to a channel of the one or more channels; and distributing the plurality of live stream outputs of video data to at least one client for display on at least one visual display device.

[0014] This is advantageous because the automated production method can automatically produce and distribute the live stream output, based on the generated instructions (which are based on the custom ruleset instructed by the user).

[0015] In some embodiments, the method further comprises, based on the generated instructions, outputting a forecast to a user of how the plurality of live streams of video data will be displayed, based on the custom ruleset and received metadata at that time.

[0016] This is advantageous because this allows the user to view the forecast and decide whether they want to make any changes to the custom ruleset to change the display of the live events.

[0017] In some embodiments, the method further comprises receiving further user instructions to create an updated custom ruleset via the user interface; re-ranking, based on the updated custom ruleset, the plurality of live events relating to the plurality of live streams of video data; and re-generating, by the processor, updated instructions for displaying the plurality of live streams of video data.

[0018] This is advantageous because this allows the user to provide further user instructions to create a modified custom ruleset. The system then re-ranks the live events accordingly. In some embodiments, the method further comprises, based on the updated instructions, outputting an updated forecast of how the plurality of live streams of video data will be displayed to a user.

[0019] This is advantageous because this allows the user to view an updated forecast to see the effect their changes have had on the live stream output. The user can then decide whether they are happy with the forecast or if they want to make further changes.

[0020] In some embodiments, the ranking step is triggered whenever metadata is received and / or whenever a custom ruleset is created.

[0021] This is advantageous because this means updating the ruleset and / or receiving live metadata has an automatic and immediate effect on the generated instructions for displaying the live streams.

[0022] In some embodiments, the one or more channels is a plurality of channels. In some embodiments, the method further comprises producing a plurality of live stream outputs of video data in accordance with the instructions, wherein the plurality of live stream outputs comprise an arrangement of the plurality of live streams of video data, and wherein each of the plurality of live stream outputs corresponds to a channel of the plurality of channels; and distributing the plurality of live stream outputs of video data to at least one client for display on at least one visual display device.

[0023] This is advantageous because this allows one service schedule of events to be distributed across a plurality of downstream channels from one UI. This also allows the user to meet their customer's requirements to ensure that certain content is limited to specified channels, for example. Further, clashes between live events can be minimised by reducing the amount of content being loaded to a particular channel. For example, if there were two live events happening at the same time which both were high priority events, one could be shown on a first channel, and the other could be shown on a second channel. This allows both events to be shown simultaneously.

[0024] In some embodiments, the one or more attributes comprise any one of:

[0025] (i) progress status of the event;

[0026] (ii) event type;

[0027] (iii) event location;

[0028] (iv) predicted event duration;

[0029] (v) pre-event build-up time required;

[0030] (vi) channel assignment and / or preference. In some embodiments, the method further comprises, upon the creation of the custom ruleset, checking the custom ruleset for any conflicts between the list of customisable rules; and if any conflict is found, informing a user of the conflict and requesting that the user amend the custom ruleset accordingly.

[0031] This is advantageous because this intelligent safety mechanism informs the user of any conflicts and invites them to solve the conflict ahead of using the custom ruleset to rank the live events. Once the user has solved the conflict, the system ranks the live events with the conflict-free ruleset.

[0032] In some embodiments, the user interface comprises one or more of the following components which allow a user to instruct the custom ruleset: one or more selection boxes; one or more drop down lists; one or more fields allowing text entry.

[0033] This is advantageous as it allows the user to create the custom ruleset in a way that reduces user error and conflicts because the format of the UI is designed such that the user is guided through the process of creating the ruleset.

[0034] In some embodiments, the custom ruleset is manually uploaded by the user. In other embodiments, the custom ruleset is uploaded automatically from the UI.

[0035] From a further aspect, the present disclosure relates to a computer-implemented live event coverage production method. The method comprises receiving user instructions to create a custom ruleset via a user interface, the custom ruleset comprising a list of customisable rules which, in use, collectively prescribe a ranking for a live event based on one or more attributes of said live event, wherein a live event with a higher rank will be a higher priority event and a live event with a lower rank will be a lower priority event; receiving a plurality of live streams of video data relating to a respective plurality of live events; receiving, in real-time, metadata relating to the plurality of live events, wherein the metadata comprises data indicative of the one or more attributes of the plurality of live events; ranking, based on the custom ruleset and the metadata, the plurality of live events relating to the plurality of live streams of video data in dependence on the one or more attributes of the said plurality of live events; generating, by a processor, instructions for displaying the plurality of live streams of video data, wherein the instructions comprise instructions for: (i) distributing the plurality of live streams of video data across one or more channels in dependence on the ranking, and (ii) a temporal order in which the plurality of live streams of video data is to be displayed in dependence on the ranking; based on the generated instructions, outputting a forecast to a user of how the plurality of live streams of video data will be displayed, based on the custom ruleset and received metadata; receiving updated user instructions to create an updated custom ruleset via the user interface; re-ranking, based on the updated custom ruleset and the metadata, the plurality of live events relating to the plurality of live streams of video data in dependence on the one or more attributes of the said plurality of live events; generating, by the processor, updated instructions for displaying the plurality of live streams of video data, wherein the updated instructions comprise instructions for: (i) distributing the plurality of live streams of video data across the one or more channels in dependence on the reranking, and (ii) a temporal order in which the plurality of live streams of video data is to be displayed in dependence on the re-ranking; based on the generated updated instructions, outputting an updated forecast to the user of how the plurality of live streams of video data will be displayed, based on the updated custom ruleset and received metadata; repeating the above steps as necessary for any further updated user instructions until the instructions for displaying the plurality of live streams of video data are finalised.

[0036] In some embodiments, the method further comprises producing a plurality of live stream outputs of video data in accordance with the finalised instructions, wherein the plurality of live stream outputs comprise an arrangement of the plurality of live streams of video data, and wherein each of the plurality of live stream outputs corresponds to a channel of the one or more channels; and distributing the plurality of live stream outputs of video data to at least one client for display on at least one visual display device.

[0037] In some embodiments, the method further comprises receiving, in real-time, updated metadata; and wherein the re-ranking is based on the updated custom ruleset and the updated metadata.

[0038] From a further aspect, the present disclosure relates to a computer-implemented live event coverage production method. The method comprises receiving user instructions to create a custom ruleset via a user interface, the custom ruleset comprising a list of customisable rules which, in use, collectively prescribe a ranking for a live event based on one or more attributes of said live event, wherein a live event with a higher rank will be a higher priority event and a live event with a lower rank will be a lower priority event; receiving a plurality of live streams of video data relating to a respective plurality of live events; receiving live metadata relating to the plurality of live events, wherein the metadata comprises data indicative of the one or more attributes of the plurality of live events; ranking, based on the live metadata and the custom ruleset created from the most recently received user instructions, the plurality of live events relating to the plurality of live streams of video data in dependence on the one or more attributes of the said plurality of live events; generating instructions for displaying the plurality of live streams of video data, wherein the instructions comprise instructions for: (i) distributing the plurality of live streams of video data across one or more channels in dependence on the ranking, and (ii) a temporal order in which the plurality of live streams of video data is to be displayed in dependence on the ranking; and outputting a forecast to a user of how the plurality of live streams will be displayed, based on the current instructions; wherein the ranking, generating and forecasting steps are repeated whenever new user instructions are received.

[0039] Aspects of the present invention assist the user in providing live event coverage customised to their individual needs by means of a continued human-machine interaction process. The user sends instructions via a UI to create a custom ruleset. Based on the custom ruleset and live metadata, the system ranks the live events and outputs a forecast to the user, the forecast showing the user how the plurality of live streams will be displayed, based on the current ranking. This allows the user to view the forecast and decide whether they want to make any changes to the custom ruleset to change the display of the live events. The user can then provide further user instructions to create a modified custom ruleset. The system then re-ranks the live events and outputs a new forecast to the user. The user can then decide whether they are happy with the forecast or if they want to make further changes.

[0040] Brief Description of the Drawings

[0041] Embodiments of the invention will now be further described by way of example only and with reference to the accompanying drawings, wherein:

[0042] Figure 1 is a block diagram illustrating the system elements of a production gallery known in the art.

[0043] Figure 2 is a block diagram of the system elements.

[0044] Figure 3 is a block diagram further illustrating system elements.

[0045] Figure 4 is a block diagram further illustrating one of the system elements of Figure 2.

[0046] Figure 5 is a block diagram further illustrating another of the system elements of Figure 2.

[0047] Figure 6a-c illustrate examples of the output generated by the system.

[0048] Figure 7 is a flow diagram illustrating a software process. Figure 8 is a flow diagram illustrating a software process.

[0049] Figure 9 is a block diagram of a system according to an embodiment of the present invention.

[0050] Figure 10 is an example of a Director UI page used to upload custom rulesets for embodiments of the present invention.

[0051] Figure 11 is an example of a ruleset for embodiments of the present invention.

[0052] Figure 12 is an example of a Service Schedule UI page illustrating embodiments of the present invention.

[0053] Description of the Embodiments

[0054] Overview

[0055] The present application's invention will be described in the context of the Applicant's previous automated production system (see WO 2018 / 060715). For completeness, the previous automated production system will be fully described below. The present application's invention will be described afterwards. In the Applicant's previous automated production system, hard coded rules decided what video content was shown when, and how it was presented. For example, when the content is on air, when the content is off air, what "priority" the content has (i.e., higher priority content will be shown in preference to lower priority content), whether the content is shown in split screen mode, etc. If a user wanted to change the hard coded rules, they would require a software engineer to recode the rules. This could take weeks.

[0056] In the present application, the rules can be changed by an admin user without the need for a software engineer. To do this, the user creates a custom set of rules (a "ruleset") via a user interface (UI). The UI is then able to upload the custom ruleset to the automated production system. In some embodiments, the UI may be an Excel document, which is then uploaded to the system. In others, the UI may be a custom designed UI which is interacted with by the user to specify the desired rules. The UI can then upload the changes to the system which will action the changes. In both cases, the system may read the uploaded ruleset file, parse the data and, if the rule changes are valid, immediately action the changes. The system reads the uploaded data file and updates the ruleset accordingly.

[0057] Various aspects and details of these principal components will be described below with reference to Figures 1 to 12.

[0058] The Previous Automated Production System In the Applicant's previous system, the automated production system provided a method and system that allows for the automated control of production for live event coverage for broadcast, multicast, or unicast. The automated system takes live video data relating to the coverage of an event and combines it with event related metadata to provide automated playout of the live video data. For example, the event related metadata may concern data relating to the progress of an event that is continuously updated in real-time, commonly used in sporting events for bet settling purposes.

[0059] In effect, the automated system simulates a traditional broadcast gallery. The system comprises a "director" or "conductor" module and a "display calculation" module. The display calculation module receives and processes the event related metadata and generates a set of instructions that are communicated to and undertaken by the conductor module. These instructions include specified actions such as the order and format of the live video data to be broadcast. On receipt of these instructions, the conductor module translates the instruction into commands that are automatically implemented by video processing hardware and software, the output of which can then delivered to one or more customers. The communication between the conductor module and the display calculation module allows the coverage of multiple live events to be dynamically updated in real-time.

[0060] This provides an automated end-to-end process of channel production for broadcast purposes, the automated process being capable of updating the order and format of coverage in real-time based on the metadata relating to each of the events being broadcast. This allows the coverage of multiple live events to be updated in a flexible, yet reliable way.

[0061] The system automates the end-to-end process of a channel production for broadcast purposes. The system receives live video data relating to a collection of events such as a sporting event, along with event related metadata, and processes the event related metadata to determine which events should be broadcast, when they should be broadcast and how those events should be visually output to the viewer watching those events on a visual display device. The event related metadata includes data relating to the progress of the events, the type of event, the scheduled start time of the event and other various factors that will be described below.

[0062] The system has two parts: a display calculation module that processes the video data and metadata to generate instructions as to how and when the video data should be broadcast; and a conductor module that controls video and audio hardware so as to execute the instructions and thereby broadcast the video data. The display calculation module operates by running a decision engine to make decisions as to how and when the video data should be broadcast, the decision engine being triggered every time new metadata is received. That is to say, when a metadata update is received, the display calculation module will automatically run the decision engine and generate updated instructions for display based on the new information. These updated instructions will then be implemented by the conductor module so as to update the coverage accordingly. As such, the system dynamically updates the video feed without human intervention based on live event updates.

[0063] Additionally, in cases where two events are taking place at the same time (simultaneously occurring events), the display calculation module is able to prioritise between these two events using a priority engine to thereby make a decision as to which event will be more important to the viewer. Based on the results of this prioritisation, the display calculation module will instruct the conductor module to display the higher priority event in some preferential way. This could mean only displaying the higher priority event, or, in a split screen mode, showing the higher priority event in a larger part of the screen than the lower priority event.

[0064] Figure 2 illustrates the components of the complex automated production system 200 described herein. The system 200 comprises a database 202 storing fundamental data relating to a plurality of live events, for example, information relating to a plurality of live sporting events that are to take place on a particular day. This event data is then sent to a customer data queue 204 where the data files are queued ready to be sent for consumption by a customer 206. The customer 206 may be, for example, a broadcaster that airs sporting events and may be configured to have multiple services, wherein a service can contain one or more schedules that collectively define the set of events to be aired each day. The files sent to each customer 206 may be in any suitable format, for example, XML, HTML, CSS or the like. Event data is provided by the customer 206 to a data feed such as the data grid 208 shown in Figure 2, the data grid 208 being updated in real time to reflect the ongoing state of the live events throughout the day. The data grid 208 includes various data, including but not limited to, an events map 210, a schedule map 212, a meetings map 214 and a remote (REM) mappings map 216. The events map 210 includes data relating to the individual events taking place that day, the schedule map 212 includes information relating to the schedule of events, the meetings map 214 includes information relating to a group of events (for example, a series of horse races taking place at the same location) and the REM mappings map 216 includes data from a remote video source, that is, a third party supplying the live video footage of the event. In this respect, REM mapping refers to the ability to assign a unique ID to a remote video source (one not generated local to the production) such that the system 200 can include its content in the output. Each customer 206 has configurable filters which identify combinations that the customer 206 is interested in airing. For example, the filters may include venue, race type, duration or any other suitable filter relating to the live events taking place. The customer 206 uses these filters to query the data grid 208 in order to obtain a list of events for the day. Each customer 206 receives event updates from the data grid 208 and will consume any update that corresponds to its event list for the day. Consumption of an event update will trigger the display calculation module 218 or "channel automator" to determine which event should be broadcast, as will be described in detail below. In doing this, the schedule information, REM mappings data and event update information is sent to the channel automator 218. The channel automator 218 generates a set of coverage instructions, each of which will generate a video output via audio and visual hardware under the control of one or more conductors 200. As such, the system 200 automates the delivery of a video output to each of the customers 206.

[0065] As illustrated by Figure 3, on receipt of the coverage instructions from the channel automator 302, the conductor 304 communicates the instructions to a number of application programming interfaces (API), for example, a router API 306, an audio API 308 and a graphics API 310. The router API 306 dictates which channel the video and audio of each event should be routed to, the audio API 308 is some suitable audio mixing software that prepares the audio associated with the footage of each event and the graphics API 310 prepares other associated graphics such as betting information to be displayed with the live footage of the event. The data from each of these APIs is then sent to a vision switcher API 312 where each of the components are compiled together. The compiled display data may then be passed through a channel data API 314 where it is provided with other visual effects such as a clock showing the time or a logo associated with the channel on which the event is to be broadcast, before being output to the channel for broadcast to viewers via a visual display 316.

[0066] Figure 4 illustrates an example of the channel automator 400 implemented on a general purpose computer system, the channel automator 400 having a central processing unit 402, random access memory 404 for storing executable programs and data, and one or more input and output ports 406 for receiving input and output data via various input and output devices. Also provided as part of the channel automator 400 is a computer readable storage medium 408, such as a hard disk drive, solid state drive, flash storage, or the like, upon which is stored the operating system for the channel automator 400, as well as various control programs and data.

[0067] In particular, a coverage instructions program 420 is provided that in use acts to receive data from the data grid 208 to determine which events should be broadcast, in which order and in which format, and thereby generate coverage instructions based on this determination. The generated coverage instructions may then be output via the I / O port 406 to one or more conductors 220, wherein the coverage instructions are implemented for broadcast. The coverage instructions program 420 makes use of a decision engine program 416 to process event schedule data 410, event related metadata 412 (for example, data relating to the progress of an event) and REM mapping data 414 to generate coverage instructions. The coverage instruction program 420 also makes use of a priority matrix engine program 418 to determine how two or more events should be broadcast where those events are scheduled to take place at the same time. The priority matrix engine program 418 uses event related metadata 414 such as type of event, length of event, betting data, location of event and any other suitable data to rank simultaneously occurring events. The coverage instructions program 420 will then use this ranking to determine how these simultaneously occurring events should be broadcast.

[0068] Figure 5 illustrates an example of the conductor 500 implemented on a general purpose computer system, the conductor 500 having a central processing unit 502, random access memory 504 for storing executable programs and data, and one or more input and output ports 506 for receiving input and output data via various input and output devices. Also provided as part of the channel automator 500 is a computer readable storage medium 508, such as a hard disk drive, solid state drive, flash storage, or the like, upon which is stored the operating system for the channel automator 500, as well as various control programs and data.

[0069] In particular, a conductor program 518 is provided that in use acts to receive channel automator data 510 received from the channel automator 218, the channel automator data 510 comprising a set of coverage instructions. The conductor program 518 then implements the channel automator data 510 using a router program 520, an audio program 522, a graphics program 524 and a visual switcher program 526 to produce a visual and audio output that is output via the port 506 to one or more channels for broadcast, where it will then be displayed to viewers via any suitable visual display device. On receipt of the channel automator data 510, the conductor program 518 instructs the router program 520 to allocate the correct live event video data 512 and audio data 514 to the correct channels. At the same time, the conductor program 518 instructs the audio program 522 to prepare the audio data 514 so that it is suitable for broadcast, and instructs the graphics program 518 to prepare any graphic data 516 that is to be displayed with the video data 512. The graphics data 516 may include betting information, schedule information or any other information relating to the events being broadcast, including past and future events. The output from the router program 520, audio program 522 and graphics program 524 is then sent to a visual switcher program 526 to be compiled as a single composite display output. As described previously, before distributing to the relevant channels, the conductor program 518 may implement further software programs so as to provide the display output with further visual effects such as a clock or logo specific to the broadcasting channel.

[0070] In Figures 4 and 5, the channel automator 218 and conductor 220 are implemented on separate general purpose computing systems, however, it will be appreciated that these system elements may be executed by the same operating system such that the control programs and data of the both the channel automator 218 and the conductor 220 are stored on the same computer readable storage medium.

[0071] The steps of the processing performed by the channel automator 218 will now be described in more detail.

[0072] Channel Automator

[0073] As described with reference to Figure 2, the channel automator 218 is a module that processes incoming event related data from a data feed 208. The channel automator 218 makes decisions regarding the temporal order and spatial configuration of event coverage based on data triggers that are fed into a decision engine program 416 and a priority matrix engine program 418. Additionally, it generates instructions regarding event information that should be displayed with each of the events. For example, it may generate text detailing information regarding upcoming events. An example of such text may be where there are reserve horses or a jockey change from the scheduled running of a horse race. As another example, the text may also relate to betting odds for an upcoming event. Such text may be included with the video output generated via the conductor 220 and broadcast to the channel to keep viewers informed of upcoming events.

[0074] One aspect of the coverage instructions generated by the channel automator 218 is the format of the video output to be generated by the conductor 220. Preferably, the format of the video output has three distinct modes; full screen, partial screen (or so-called "squeezeback") and split screen, as illustrated by Figures 6a-c. The decision as to which display mode the video data is output in is made by decision engine program 416, as will be described below.

[0075] When in full screen mode, as shown by Figure 6a, the event is shown on the whole of the screen 600 with only a strap 602 indicating to viewers the time and location of the event. In some instances, the video output will be in full screen mode once the event has started, but may be in partial screen mode beforehand. For example, the 2 o'clock race at Doncaster races may be shown in full screen if there are no other horse races or dog races happening at 2 o'clock that day.

[0076] In partial mode, as illustrated in Figure 6b, the video output 604 is shown on a portion of the screen, with the rest of the screen being used for event related text. In this example, the non-video portion 606 is displayed as a reverse L-shape with information regarding the upcoming event, for example, betting odds and runners displayed along the right hand side, and a news bar at the bottom displaying information about events scheduled for later in the day and a ticker which amongst other things, displays results from previous races. It will however be appreciated that any suitable layout may be used. For example, prior to the 2 o'clock race at Doncaster, the live video feed of Doncaster race course may be shown in partial mode whilst the horses are lining up. In the non-video portion 606, information regarding the horses, jockeys and trainers may be included, along with the betting odds for each horse. Additionally, information regarding the results of previous races at Doncaster or any other race course may be provided. Similarly, information regarding upcoming races at Doncaster or any other race course may be provided.

[0077] In split screen, as illustrated by Figure 6c, two video outputs 608, 610 are displayed on the screen, wherein one video 608 may be smaller than the other 610. Split screen mode is generally used when there are two events running at the same time, allowing the channel to broadcast both events simultaneously. In this respect, the channel automator 218 will implement the priority matrix engine 418, as will be described below, to prioritise the two events, pushing one of the events to the big screen 610 and the lower priority event to the smaller screen 608. For example, the 2 o'clock race at Doncaster may clash with the 2 o'clock dog race at Wimbledon Greyhound Stadium. The channel automator 218 will use the priority matrix engine 418, which may determine that the 2 o'clock race at Doncaster has a higher priority than the race at Wimbledon. Therefore, the 2 o'clock at Doncaster will be shown in the larger screen portion 610, whilst the 2 o'clock at Wimbledon will be shown in the smaller screen portion 608. As with partial screen mode, information relating to the current races, as well as past and future may be included on the screen.

[0078] Decision Engine

[0079] The process by which a decision is made regarding which event should be broadcast will now be described.

[0080] In order to simplify the logic of the processes implemented by the decision engine program 416, the progress of all events is categorised. For example, the events may be categorised as follows: UPCOMING - an unfinished event that is not READY or RUNNING

[0081] READY - an unfinished event with progress code of (E, J, K, L)

[0082] RUNNING - an unfinished event with progress code of (H, O)

[0083] FINISHED - the event has a final result or the event has a result element with a finish status code of (A=first past post, T=event coverage ended) or the event has a result element with a settling status of V (void)

[0084] In the context of horse racing and dog racing, the progress codes may be as follows: null 6

[0085] "X" 6

[0086] "A" 5 / / Dogs: PARADING

[0087] "B" 5 / / Horses: GOING DOWN

[0088] "C" 4 / / Horses: AT THE POST, Dogs: APP. TRAPS

[0089] "M" 4 / / BETTING SUSPENDED

[0090] "E" 3 / / Horses: GOING BEHIND, Dogs: GOING IN TPS

[0091] "L" 3 / / Horse: LINING UP

[0092] "J" 3 / / Horses: WHITE FLAG, Dogs: HARE STOPPED

[0093] "K" 3 / / Horses: FALSE START Dogs: TRAPS FAILED

[0094] "H" 2 / / Horses: UNDER ORDERS, Dogs: HARE RUNNING

[0095] "O" 1 / / OFF

[0096] Any code not in the above list is treated as priority 6, with 6 being the lowest priority.

[0097] The decision engine program 416 will then perform an "assign events" process to determine the order and format of the video output to be broadcast by the channel, the steps of the process being illustrated by Figure 7. The decision engine program 416 first establishes whether there is more than one event with a progress state of READY or RUNNING (step 700). That is to say, whether there are two or more events scheduled to take place at the same time. If the answer is yes, the decision engine program 416 will send a request to the priority matrix engine program 418 to determine a priority ranking of the two or more events (step 702). In dependence on the outcome of this priority ranking, the decision engine program 416 will issue an instruction to the conductor 220 to display the video output of the two or more events in split screen mode (step 704), as shown in Figure 6c, with the highest priority event being displayed on the larger screen 610. The priority ranking process will be described in more detail below. If there is only one event with a progress state of READY or RUNNING, the decision engine program 416 will determine whether the event has started, that is, has a progress state of RUNNING (step 706). If the event has begun, the decision engine program 416 will issue an instruction to the conductor 220 to display the video output of the event in full screen mode (step 708), as shown in Figure 6b. If the event has not yet begun, that is, has a status of READY or UPCOMING, the decision engine program 416 will issue an instruction to the conductor 220 to display the video output of the upcoming event in partial screen mode (step 710), as shown in Figure 6b. In this case, where there is one event waiting to start (READY) and / or multiple UPCOMING events, the video output relating to the highest priority event based on the above priority codes will be broadcast.

[0098] As well as event progress state, the decision engine program 416 may also take into account event-specific user actions such as skip, take, hold, next, prioritise, first past post, and the like. In the event of data failure affecting multiple events, the channel automator 218 control of the video displays will be suspended and switched to manual control.

[0099] Future Events

[0100] The decision engine program 416 will line up future events according to their progress status, the above priority codes and scheduled start time, wherein the earliest start time is considered to be a higher priority. For example, where there are two events with priority code "B", or one with priority code "B" and one with priority code "A", and thus are of equal priority, the event with the earlier start time will be broadcast first.

[0101] Since future events are lined up according to their progress status, priority code and scheduled start time, with the progress status and priority code being the first "lining up" parameter, any events that deviate from their scheduled start times will still be handled in the correct way. For example, consider an event that was scheduled to start at 13.00 hours and a second event scheduled to start at 13.10 hours. If the event related metadata 412 was still showing the first event as UPCOMING: C (priority level 4) at 13.10, whilst the second event is shown as RUNNING: H (priority level 2), the decision engine program 416 will instruct the conductor 220 to broadcast the second event instead of the first event. The conductor 220 will continue to broadcast the second event until the decision engine program 416 receives event related metadata 412 indicating that the first event is RUNNING and will then issue an instruction to the conductor to switch to split screen mode to thereby broadcast both events.

[0102] The user may be able to manually indicate that an event has finished by clicking a "First Past the Post" button, causing the event result finish status code to be set to "A". When an on air event being broadcast in full screen mode transitions to event progress state FINISHED in this way, it may remain on air until a replay has been shown and the final result has been received. If during this post-finish period another un-skipped event in the service schedule transitions to priority code "E" or higher, then the post-finish event may be taken off air immediately without waiting for the result.

[0103] The decision engine program 416 is also capable of making a decision not to broadcast an event. For example, the decision engine program 416 may instruct the conductor 220 not to broadcast the video output of an event if the event related metadata 412 indicates that the event has been abandoned or is void, if the decision engine program 416 has received an instruction from the user to skip the event or to continue watching another event already being broadcast, or if the broadcast of such an event will prevent the broadcast of another event (for example, because it has a higher priority ranking).

[0104] Once an event finishes, a replay may be shown provided there is sufficient time until the next scheduled event or that no other scheduled unfinished events have progress codes higher than "X", and provided the "skip replay" option has not been selected by the user for the event. These replays can be run in slow motion in order to give a clear indication of the outcome of the race.

[0105] A custom event always has a progress code of "X". This means it will only ever be broadcast of its own accord in the event that all other unfinished events are at progress code "X" and the custom event has the earliest start time. In other words, it will automatically be broadcast at its scheduled start time provided there is no other progress among the other scheduled events. A custom event can also be broadcast at any time by using the "take" option. If a user no longer wishes to view a custom event, the skip option can be exercised.

[0106] Priority Matrix Engine

[0107] The process by which two simultaneously scheduled events are prioritised will now be described.

[0108] If the decision engine program 416 determines that more than one event has a progress status of READY or RUNNING, that is, two or more events are scheduled to take place at the same time, it will send a request to the priority matrix engine program 418 to prioritise the two or more events. Figure 8 illustrates the steps of the process performed by the priority matrix engine program 418.

[0109] Firstly, the priority matrix engine program 418 will rank the two or more events based on the time they are expected to finish. If an event is already "OFF", that is, it has already started, then an accurate start time can be determined. Otherwise, it is estimated by taking the later of the time at that moment and the scheduled start time, also taking into account the type of event and the progress status at that time. For example, if the scheduled start time is 11 :20:00, the current time is 11 : 19:50, the event is a horse race and the current progress code is B, then the estimated start time is likely to be several minutes after 11:20:00. To establish a more accurate estimate of the start time, the transition time between progress codes is taken, plus a number of additional seconds obtained from a lookup table based on category and progress code. The race duration can be estimated based on category, distance and whether there are any hurdles. From the start time (whether this be actual or estimated) and the estimated race duration, an estimated finish time for each event can be determined.

[0110] The priority matrix engine program 418 will then establish whether the two or more events are expected to finish within a certain amount of time of each other, for example, within 45 seconds of each other (step 800). If they are not, the earliest finishing event will be prioritised (step 802).

[0111] If they are expected to finish within the specified time, the priority matrix engine program 418 will determine whether there is any betting data available for either of these two events (step 804), such data being obtained from a third party source. If the value of this betting data is different (step 806), for example, there are higher odds for one of the events, the priority matrix engine program 418 will prioritise the event that is of higher value to customer (step 808).

[0112] If the value of this betting data is equal, that is, the events have similar odds, the priority matrix engine program 418 will rank the event based on the event category (step 810). For example, horse races may be allocated 8 points, dog races allocated 5 points and other sports allocated 1 point. Where the ranking is not equal, the event with the highest amount of points will be prioritised (step 812).

[0113] If the ranking is equal, the priority matrix engine program 418 will then rank the events based on the country in which they are taking place (step 814). For example, events taking place in the UK may be allocated 8 points, events in Ireland allocated 7 points, events in the United Arab Emirates allocated 6 points, events in France allocated 5 points, events in South Africa allocated 4 points, events in the US allocated 3 points, events in Australia allocated 2 points and events in any other country allocated 1 point.

[0114] If the ranking is not equal, the event with the highest amount of points will be prioritised (step 816). If the ranking is equal, the priority matrix engine program 418 will rank the events based on distance (step 818). For example, races that are less than a mile may be allocated 2 points, races between 1 and 2 miles allocated 1 point and races more than 2 miles allocated 0 points. Again, if the ranking is not equal, the event with the highest number of points, that is, the shortest will be prioritised (step 820).

[0115] If the ranking is equal, the priority matrix engine program 418 will rank the events based on the REM source supplying the video data for each event (822). If the ranking is not equal, the highest scoring event will be prioritised (step 824). Finally, if after this, the ranking is still equal, the priority matrix engine program 418 will query the status of the live event to determine which is closest to the finish in real-time and set this as the priority event (step 826).

[0116] Once the events have been prioritised, the priority matrix engine program 418 will issue instructions to the conductor 220 to display the video output of the two or more events in the split screen mode, as shown in Figure 6c, with the higher priority event being shown in the larger screen 610.

[0117] Take for example, a horse race at Cheltenham race course estimated to finish at 15.51.30 and a horse race at Dublin race course estimated to finish at 15.51.45. As they are expected to finish within 45 seconds of each other, the priority matrix engine program 418 will determine whether there is any betting data available for the two races (step 804). If both races have favourites with odds at 2 / 1, the priority matrix engine program 418 will then rank them based on the category of the event (step 810). Since they are both horse races, they will receive an equal ranking. Therefore, the priority matrix engine program 418 will then rank them based on the location of the race (step 814). Based on the example given above, the horse race in Cheltenham would receive 8 points, whilst the race in Dublin would receive 7 points. Consequently, the race in Cheltenham would be considered a higher priority, and the priority matrix engine program 418 would instruct the conductor to display the Cheltenham race in the larger screen 610.

[0118] The Present Automated Production System

[0119] The Applicant's present system takes the previous automated production system described above as a starting point but inventively modifies it. Unless otherwise specified, the above description of the previous automated production system applies mutatis mutandis to the present automated production system.

[0120] In the previous system, the rules used for telling the decision engine how to decide how and when the video data should be broadcast were not user-configurable. In contrast, in embodiments of the present invention, the rules are configurable and bespoke for each user. This allows each customer's distribution rules to be unique, as each has their own business logic to address. The system receives a plurality of live streams of video data relating to a respective plurality of live events, along with real-time / live metadata (the metadata may be continuously updated in real-time) relating to those live events. The metadata may comprise one or more attributes of the live event. One or more attributes may comprise any one of the following: a progress status (e.g. warming up, race about to start, race in progress, race just finished, etc.), what type of event, event location, event duration, etc.

[0121] A user may create a custom ruleset via a UI. A ruleset is a list of rules. Rules may relate to the progress status of the live events shown in the video data (e.g., a rule might dictate that an "in progress" event should always be shown over a "warming up" event). Rules may relate to the type of event, the event location and / or the event duration. The custom ruleset is then uploaded to a server (which may be the same computer as the one used by the user to create the custom ruleset), this may be done automatically by the UI, or the custom ruleset may be uploaded manually by the user.

[0122] The system may have an intelligent safety mechanism which checks there is no conflict between the different rules. If there is a conflict, the admin user is informed accordingly and asked to amend their rule change request to overcome the conflict.

[0123] The rules may relate to any attribute of the content (the video live stream) which may be recorded in a JSON file, for example. In comparison to the Applicant's previous system, this opens many new possibilities for rules of how the content is presented.

[0124] The video data may be sorted, categorised and / or ranked based on the ruleset. In the absence of an uploaded custom ruleset, a default ruleset may be used.

[0125] In some examples, the ranking based on one or more attributes of the events may comprise first ranking the events based on their progress status, and then those with the same categorisation may be further ranked based on further attributes, as was described above in the Applicant's previous system. For example, all events with the progress status of "race in progress" may be ranked based on the event location (where locations have a predetermined prioritisation (e.g., UK-based events may be preferred over US-based events)).

[0126] In other examples, the events may be ranked based on other attributes first, before considering progress status. It depends on what custom ruleset the user has created.

[0127] In some examples, there is a first ruleset (an "On / Off Air ruleset") which determines which events qualify to be On Air (the remaining being Off Air). Once and event qualifies to be On Air, then there will be checks against a second ruleset (the custom ruleset - as described herein) whenever new data is received for that event to re-evaluate the priority of the event. When an event qualifies to be Off Air, based on meeting requirements from the Off Air ruleset, then the event is taken off air and no longer is processed by the custom ruleset.

[0128] Instructions for displaying the video data are then generated, which may include a temporal order in which the video data should be played based on the categorisation (e.g., events that are categorised as "race in progress" may be displayed before those that are categorised as "warming up" or "race about to start"). The instructions may include a spatial configuration in which events of the same category should be displayed, based on the ranking. For example, the live video output stream may have a live video of an event where the race is in progress taking up the majority of the screen, but have a live video of a race which has just finished taking up a smaller space in the corner of the screen. This live video output stream is then distributed (e.g. via broadcast, multicast or unicast) to one or more downstream channels. Which live video streams are shown when, and on which channel, is automatically decided by the system based on the ruleset.

[0129] Although scheduling programs do exist within the broadcasting industry, these are usually designed to schedule programmes or events for one downstream channel at a time based on a linear timeline. Existing industry software applications are unable to schedule multiple events from a list of available content across more than one downstream channel while using pre-determined distribution rules and live data.

[0130] Some embodiments of the present invention allow the distribution of a plurality of live streams of video data relating to a respective plurality of live events across a plurality of downstream channels. The distribution of events across channels is based on rulesets, which may be custom rulesets or may be default rulesets if no custom rulesets are uploaded to the system, and decisions which are driven and triggered by live data (the metadata) received by the system.

[0131] Many factors may be considered in the distribution decision-making process, for example, the type of race or event, the location of that race, the duration of the event, any buildup time required before the event started and if any of the events were to be assigned to a certain channel. The distribution of events is based on the following aims:

[0132] • To reduce the amount of content being loaded to a particular channel and thereby minimize potential clashes with other events.

[0133] • To meet customers' requirements to ensure that specified content is limited to specified channels. • To allow system users to manage a single service's schedule for multiple channels from one UI screen.

[0134] Some embodiments of the present invention allow a service's content (i.e., the live streams of video data) to be distributed across a plurality of downstream channels. A service is a package of content a customer has the right to broadcast. A service schedule is created using metadata related to this content, received by the system, and is structured in a linear timeline of events. The scheduled events are then distributed across the channels either evenly or based on event priority or channel weightage.

[0135] Distribution decisions are driven by default logic or custom rules and these rules are uploaded into the system. Rules once combined are called rulesets. Rulesets contain rows of configurable rules, mapped against data payload attributes. Rulesets are used to instruct the system to distribute the events based on these rules and the metadata received by system. Fields within the event metadata are considered inputs to the ruleset. Rulesets may also have one or more of the following outputs: locked assignment, event weightage and preview time. One or more of these outputs may be combined and then used to determine the forecasted distribution of events, based on the current ruleset and current metadata available.

[0136] The system may automatically output a forecast of the live stream distribution to a user at a pre-determined time. This pre-determined time may be set by the user using the UI. The pre-determined time may be "X amount of time before the live stream is broadcast", X may be, for example, 10 seconds, 20 seconds, 30 seconds, 45 seconds, 1 minute, 5 minutes, 10 minutes, etc. There may also be an option to manually reforecast the event distribution. For example, there may be a button in the UI which the user can press to reforecast the event distribution immediately. Each time this forecast action is run, the system scans through the most recently instructed customised rules before distributing the events based on the most up-to-date metadata available. The system may be configured to automatically reforecast the event distribution whenever the user updates the custom ruleset. The system may be configured to automatically reforecast the event distribution whenever new metadata is received.

[0137] Live streams of events can be manually locked to a specific channel via the UI, e.g., the Service Schedule UI screen as shown in Figure 12, or may be automatically locked based on any output for locked assignment in the forecast ruleset. In other words, if the ruleset determines that a live stream should be locked to channel 1, for example, this can be done automatically. Locked assignment events are fixed in place and do not move during any subsequent forecastings. Advantages of embodiments of the present invention include:

[0138] Customers can use their own bespoke forecasting rules for distribution.

[0139] • If a customer has no bespoke rules, then default forecast rules are used for forecasting.

[0140] • Forecasting rules are not hardcoded in the system but are configurable.

[0141] • Due to the above, forecast rules can be changed quickly by an Admin user and uploaded to the system.

[0142] • After uploading rulesets, they take immediate effect.

[0143] • One Service Schedule of events can be distributed across a plurality downstream channels.

[0144] • The system runs automatically (based on current system logic) or a user can manually manage the distribution of events.

[0145] • All Service Schedule events and downstream channels are viewed and managed from one UI screen.

[0146] • The system uses a forecast ruleset and attributes within a data payload to make forecasting decisions.

[0147] Figure 9 shows a high-level diagram of the system 900. Key terms used are defined as follows:

[0148] Data 902: Data relating to a plurality of live events, e.g., metadata indicative of one or more attributes of the live events. Attributes may include a progress status (e.g. warming up, race about to start, race in progress, race just finished, etc.), what type of event, event location, event duration, etc. Data 902 is received at the Event Management Service 906 which stores the data 902 in database 904.

[0149] CAP2 Database 904: Stores data 902 relating to a plurality of live events, for example, information relating to a plurality of live sporting events that are to take place on a particular day.

[0150] Admin Service 918: Allows the creation of entities such as Customers, Services, hardware information. End-to-end channel configuration settings including content rights, priority and distribution rules. May comprise a UI such as those shown in Figures 10 and 12. CAP Admin / Operators 920: Admin users / operators operate the admin service by providing user instructions. The user instructions may instruct the creation of a custom ruleset. Admin users can create entities such as customers, services, director, conductor, rulesets. Operators manage the operational behaviour of the channels, if manual intervention is needed. They can add / remove content also.

[0151] Rules Engine 912: Determines the behaviour of the channel, from what to show, when and how it is shown. May comprise Excel files 916 and Rulesets 914.

[0152] Event Management Service 906: Responsible for presenting the list of events to the operators and adding broadcast triggers and current statuses for the events.

[0153] It allows operators to assign changes to race times, or manually triggers events in the event of data loss. This is more like a Disaster Recovery page to enable the channels to continue to run using manual triggers, not live data from sources upstream of CAP. .

[0154] Service Scheduler 908: Provides event data and media / custom events to the service. It will include Rule Engine 912 which determines the behaviour of the channel, from what to show, when and how it is shown. It is defined by configuration. It is responsible for deciding what event goes on air for each service per customer.

[0155] Director 910: This will decide what actions to take on events chosen to be on air by the Service Scheduler. This is also referred to above as the channel automator.

[0156] Hardware 922: Includes Conductors 926, 930, 934. The function of Conductors has been described in detail above in relation to the Applicant's previous system. This previous description of Conductors applies to Conductors 926, 930, 934. Hardware 922 also includes Graphics APIs 928, 932, 936. Graphics APIs 928, 932, 936 prepare associated graphics such as betting information to be displayed with the live footage of the event. Graphics APIs 928, 932, 936 are examples of APIs - other possible APIs include router APIs and audio APIs as described above in relation to Figure 3.

[0157] Multi-Channel Distribution 924: Combines video / audio event footage 938, 942, 946 with optional graphics and then distributes to Channels 940, 944, 948.

[0158] Multi-Channel Distribution The system uses forecasting rules and configuration within the Director for distributing events to channels. The forecasting rules may be custom rules set by a user, or, in the absence of any uploaded custom rules, default rules may be used.

[0159] Conductors - This provides the hardware configuration for a channel, which is assigned to the Service's Director. These are explained above in relation to the Applicant's previous system - see conductors 220 of Figure 2.

[0160] Director - Also referred to above as a "Channel Automator" 218. Uses Rulesets and live data to direct downstream channel behaviour. A plurality of Conductors 220 can be assigned to one Director / Channel Automator 218. Within the Director configuration, channel priority has two options; 1) channels with equal priority, so weightage does not apply and 2) ordered by priority, which means the channels are ordered from 1 to X (X being the total number of channels available). The highest weightage events (based on the ruleset) will be assigned to the highest priority channel, the lowest weightage to the lowest channel. Audio output has two options; 1) one output, which is the audio for the priority event across all downstream channels or 2) output per channel, which takes the audio for the priority event on each channel. Rulesets are assigned to the Director for On- Air, Off-Air, Priority, Graphics and Forecasting. For example, if the system was being used in a betting shop where multiple channels may be displayed on different display devices within the same room, it would be confusing to have multiple audio outputs (an audio output per channel). In this situation, it may be preferable to have just one audio output (the audio output being the highest priority event across all the channels), despite there being other live streams displayed.

[0161] Figure 10 shows an example of the Director UI page 1000. The Director UI page has multiple fields 1002-1032 which can be completed by a user. The starred fields indicate that the field is mandatory (in this example, 1002-1006, 1014, 1016, 1022, 1030 are mandatory). The UI may comprise one or more selection boxes (e.g., 1034), one or more drop down lists (e.g., 1004, 1006, 1014, 1016, 1018, 1022-1032) and / or one or more fields allowing text entry (e.g., 1002, 1010, 1012, 1020).

[0162] Referring to Figure 10 in more detail, the various elements shown in the boxes are as follows:

[0163] All actions are taken by an Admin user.

[0164] 1002: Name the Director (unique name up to 30 characters)

[0165] 1004: Assign to a Customer (select one from list of all existing customers) 1006: Assign to Customer's Service (select one from list of services owned by selected customer)

[0166] 1008: Read / edit display of any Conductors assigned to this Director. This only shows once the Director has been created. On first creation of the Director, nothing will show in this field.

[0167] Assigned Conductors, if more than one, can be reordered if in Multi-Channel mode using channel priority 'Conductor Order'.

[0168] 1010: A default video source value is assigned to the Director. This is what, when there are no events that qualify to be on air, will be shown. This is usually a looped video of a customer's logo or a promotional graphic. The value assigned refers to an output source on the video router.

[0169] 1012: A default audio source is assigned to the Director for the same reason as above. This could have any audio on the source, for example music or silence.

[0170] 1014: Downstream channels of the Director can be set to Channel Priority of Equal or Conductor Order. Equal is always used when there is one downstream channel. Equal or Conductor Order can be selected when downstream channels are in Multi-Channel mode.

[0171] Equal = channels are of equal priority. One is no more important than the other(s). Events are distributed equally, even if in the Forecast ruleset determines types of events are different weightages (OUT.master.weightage).

[0172] Channel Priority = the order of the conductors (1008) determines the channel priority. If events are assigned higher weightages, these will be forecasted to the highest priority channel first. Depending on preview times assigned in the forecast rules, any other higher weightage events are distributed across the channels in priority order.

[0173] 1016: Audio output offers two configuration settings. Single Output is required when there is only one downstream channel. The audio of the highest priority event on air at the time will be taken. When set to Output Per Channel, the audio of the highest priority event on a channel will be taken per channel in a multi-channel set up. This setting would be used by customers who possibly have operators managing the audio from an external sound desk, and they chose which channel's audio they'd like broadcast.

[0174] 1018: Assign Exclusive MT device is not something required in the set up of a Director. This is an additional feature that a channel can use which is automated continuity audio, called Machine Translation. 1020: Auto-forecast time is the time in which the system automatically forecasts the events in the schedule. The Forecasting rules are run at this point. This can be set before the 'day' begins, so that when the channel first comes to air, all events are already forecasted across the channels. For example, a channel going live at 8am might want to set this at 06:00, or a 24 / 7 channel might set this to 00:00.

[0175] 1022: The On Air ruleset is assigned to the Director. All rulesets assigned to this Customer will be shown in the dropdown list. Only one can be used. On Air ruleset determines when events qualify to be shown on air.

[0176] 1024: The Conductor Action ruleset is assigned to the Director. All rulesets assigned to this Customer will be shown in the dropdown list. Only one can be used. Conductor Action ruleset determines which graphics will be shown, based on event status and live data.

[0177] 1026: The Split Priority ruleset is assigned to the Director. All rulesets assigned to this Customer will be shown in the dropdown list. Only one can be used. Split Priority ruleset determines at which point in an event's progress it can go into a split screen with another event. At the point, the viewer will see two events on air on the same channel.

[0178] 1028: The Forecast ruleset is assigned to the Director. All rulesets assigned to this Customer will be shown in the dropdown list. Only one can be used. Forecast ruleset determines which events in the schedule should be on which downstream channel.

[0179] 1030: The Off-Air ruleset is assigned to the Director. All rulesets assigned to this Customer will be shown in the dropdown list. Only one can be used. Off-Air ruleset determine when events can be taken off air and no longer shown on the channel.

[0180] 1032: The Audio ruleset is assigned to the Director. All rulesets assigned to this Customer will be shown in the dropdown list. Only one can be used. Audio ruleset determines which audio should be taken and which point of an event's progress. This works together with Machine Translation. A channel can take automated audio or live audio.

[0181] Forecasting rules - A list of rules used by the Director to distribute content across downstream channels. These are mapped against data payload attributes and output instructions.

[0182] An example of a forecasting ruleset 1100 is shown in Figure 11. .master. categoryCode and .master. countryCode are examples of data payload fields. The entries in the rows in Figure 11 are mapped against the event data payload and these create a ruleset. The top row in Figure 11 illustrates a horse race in the UK or Ireland has been given weightage 1 (most important) and has a required 300sec preview time before the schedule Off time. If an event is within this scenario, it will ideally not be broadcast alongside any other event on the channel during this period. This example also shows that any horse races from the UK and Ireland will be distributed and locked to channel 1.

[0183] Locked Assignment - An event must be forecast and assigned to a conductor. This is the highest priority affinity an event can have and by locking the assignment the weight of the event is paramount. The assignment will be forced regardless of clashes with other events, based on other locked assignments. The locked assignments will be allocated BEFORE the forecast logic run and attempts to slot other events into the schedule (this means that any unlocked assignment is inherently lower priority / weight than a locked item and if there is an overlap the unlocked event will not be scheduled).

[0184] Weiqhtaqe - Weightage is used to rank events. Low numbers are a higher priority, and these do not directly map to the conductor order i.e., weightage of 3 with no competing event can be scheduled on conductor 1). If the Director is configured for channel priority, then event weightage is considered.

[0185] Preview Time in secs - The time before the scheduled off time in which no other events ideally should be allocated. The duration of an event is between the start of the preview time to the calculated finish time. When events overlap and multiple channels exist, the events are sorted by priority, based on weightage or by equal distribution if weightage is disabled on the Director UI page or through equal weights in the ruleset.

[0186] Service Schedule

[0187] Figure 12 shows an example of a service schedule UI page 1200.

[0188] Below is an explanation of the UI features for multi-channel distribution.

[0189] The distribution of events is displayed on the Service Schedule UI page 1200. The forecasting is shown as radio buttons 1201 on the event row. The number of buttons 1201 per row is determined by the number of Conductors assigned to the Service's Director. In single channel mode, these buttons 1201 do not appear as all events will be assigned to the one channel. Event forecasting appears as a pink button (e.g., button 1204). Before an event is on-air the user can change the assignment manually. Events can only be forecasted to one channel, but a user can manually take the event to air on other channels using the manual user buttons 1203. Locked assignments in the ruleset are displayed with a lock icon 1202. Locked assignments are displayed as green padlocks 1206 and unlocked as black padlocks 1208. When an event is on-air it automatically locks, and it requires manual user interaction to move the event. Each channel has manual user buttons 1203. For example, these buttons 1203 allow the user to manually "take" an event to air, or "skip" an event from playing.

[0190] Various modifications whether by way of addition, deletion, or substitution of features may be made to above described embodiment to provide further embodiments, any and all of which are intended to be encompassed by the appended claims.

Claims

Claims1. A computer-implemented live event coverage production method, the method comprising: receiving user instructions to create a custom ruleset via a user interface, the custom ruleset comprising a list of customisable rules which, in use, collectively prescribe a ranking for a live event based on one or more attributes of said live event, wherein a live event with a higher rank will be a higher priority event and a live event with a lower rank will be a lower priority event; receiving a plurality of live streams of video data relating to a respective plurality of live events; receiving, in real-time, metadata relating to the plurality of live events, wherein the metadata comprises data indicative of the one or more attributes of the plurality of live events; ranking, based on the custom ruleset and the metadata, the plurality of live events relating to the plurality of live streams of video data in dependence on the one or more attributes of the said plurality of live events; and generating, by a processor, instructions for displaying the plurality of live streams of video data, wherein the instructions comprise instructions for: (i) distributing the plurality of live streams of video data across one or more channels in dependence on the ranking, and (ii) a temporal order in which the plurality of live streams of video data is to be displayed in dependence on the ranking.

2. The computer-implemented live event coverage production method of claim 1, the method further comprising: producing at least one live stream output of video data in accordance with the instructions, wherein the at least one live stream output comprises an arrangement of the plurality of live streams of video data, and wherein each of the plurality of live stream outputs corresponds to a channel of the one or more channels; and distributing the plurality of live stream outputs of video data to at least one client for display on at least one visual display device.

3. The computer-implemented live event coverage production method of claim 1 or claim 2, the method further comprising: based on the generated instructions, outputting a forecast to a user of how the plurality of live streams of video data will be displayed, based on the custom ruleset and received metadata at that time.

4. The computer-implemented live event coverage production method of any preceding claim, the method further comprising: receiving further user instructions to create an updated custom ruleset via the user interface; re-ranking, based on the updated custom ruleset, the plurality of live events relating to the plurality of live streams of video data; and re-generating, by the processor, updated instructions for displaying the plurality of live streams of video data.

5. The computer-implemented live event coverage production method of claim 4, wherein the method further comprises: based on the updated instructions, outputting an updated forecast of how the plurality of live streams of video data will be displayed to a user.

6. The computer-implemented live event coverage production method of any preceding claim, wherein the ranking step is triggered whenever metadata is received and / or whenever a custom ruleset is created.

7. The computer-implemented live event coverage production method of any preceding claim, wherein the one or more channels is a plurality of channels.

8. The computer-implemented live event coverage production method of claim 7, further comprising: producing a plurality of live stream outputs of video data in accordance with the instructions, wherein the plurality of live stream outputs comprise an arrangement of the plurality of live streams of video data, and wherein each of the plurality of live stream outputs corresponds to a channel of the plurality of channels; and distributing the plurality of live stream outputs of video data to at least one client for display on at least one visual display device.

9. The computer-implemented live event coverage production method of any preceding claim, wherein the one or more attributes comprise any one of:(i) progress status of the event;(ii) event type;(iii) event location;(iv) predicted event duration;(v) pre-event build-up time required;(vi) channel assignment and / or preference.

10. The computer-implemented live event coverage production method of any preceding claim, the method further comprising: upon the creation of the custom ruleset, checking the custom ruleset for any conflicts between the list of customisable rules; and if any conflict is found, informing a user of the conflict and requesting that the user amend the custom ruleset accordingly.

11. The computer-implemented live event coverage production method of any preceding claim, wherein the user interface comprises one or more of the following components which allow a user to instruct the custom ruleset: one or more selection boxes; one or more drop down lists; one or more fields allowing text entry.

12. A computer-implemented live event coverage production method, the method comprising: receiving user instructions to create a custom ruleset via a user interface, the custom ruleset comprising a list of customisable rules which, in use, collectively prescribe a ranking for a live event based on one or more attributes of said live event, wherein a live event with a higher rank will be a higher priority event and a live event with a lower rank will be a lower priority event; receiving a plurality of live streams of video data relating to a respective plurality of live events; receiving, in real-time, metadata relating to the plurality of live events, wherein the metadata comprises data indicative of the one or more attributes of the plurality of live events; ranking, based on the custom ruleset and the metadata, the plurality of live events relating to the plurality of live streams of video data in dependence on the one or more attributes of the said plurality of live events; generating, by a processor, instructions for displaying the plurality of live streams of video data, wherein the instructions comprise instructions for: (i) distributing the plurality of live streams of video data across one or more channels in dependence on the ranking, and (ii) a temporal order in which the plurality of live streams of video data is to be displayed in dependence on the ranking; based on the generated instructions, outputting a forecast to a user of how the plurality of live streams of video data will be displayed, based on the custom ruleset and received metadata;receiving updated user instructions to create an updated custom ruleset via the user interface; re-ranking, based on the updated custom ruleset and the metadata, the plurality of live events relating to the plurality of live streams of video data in dependence on the one or more attributes of the said plurality of live events; generating, by the processor, updated instructions for displaying the plurality of live streams of video data, wherein the updated instructions comprise instructions for: (i) distributing the plurality of live streams of video data across the one or more channels in dependence on the re-ranking, and (ii) a temporal order in which the plurality of live streams of video data is to be displayed in dependence on the re-ranking; based on the generated updated instructions, outputting an updated forecast to the user of how the plurality of live streams of video data will be displayed, based on the updated custom ruleset and received metadata; repeating the above steps as necessary for any further updated user instructions until the instructions for displaying the plurality of live streams of video data are finalised.

13. The computer-implemented live event coverage production method of claim 12, the method further comprising: producing a plurality of live stream outputs of video data in accordance with the finalised instructions, wherein the plurality of live stream outputs comprise an arrangement of the plurality of live streams of video data, and wherein each of the plurality of live stream outputs corresponds to a channel of the one or more channels; and distributing the plurality of live stream outputs of video data to at least one client for display on at least one visual display device.

14. The computer-implemented live event coverage production method of claim 12 or claim 13, the method further comprising receiving, in real-time, updated metadata; and wherein the re-ranking is based on the updated custom ruleset and the updated metadata.

15. A computer-implemented live event coverage production method, the method comprising: receiving user instructions to create a custom ruleset via a user interface, the custom ruleset comprising a list of customisable rules which, in use, collectively prescribe a ranking for a live event based on one or more attributes of said live event, wherein a live event with a higher rank will be a higher priority event and a live event with a lower rank will be a lower priority event; receiving a plurality of live streams of video data relating to a respective plurality of live events;receiving live metadata relating to the plurality of live events, wherein the metadata comprises data indicative of the one or more attributes of the plurality of live events; ranking, based on the live metadata and the custom ruleset created from the most recently received user instructions, the plurality of live events relating to the plurality of live streams of video data in dependence on the one or more attributes of the said plurality of live events; generating instructions for displaying the plurality of live streams of video data, wherein the instructions comprise instructions for: (i) distributing the plurality of live streams of video data across one or more channels in dependence on the ranking, and (ii) a temporal order in which the plurality of live streams of video data is to be displayed in dependence on the ranking; and outputting a forecast to a user of how the plurality of live streams will be displayed, based on the current instructions; wherein the ranking, generating and forecasting steps are repeated whenever new user instructions are received.

16. A live event coverage production system, comprising: a processor; and a computer readable storage medium storing one or more computer programs, the one or more computer programs being so arranged such that when executed by the processor it / they cause the processor to perform a method according to any of the preceding claims.

17. A live event coverage production system, comprising: means for receiving user instructions to create a custom ruleset via a user interface, the custom ruleset comprising a list of customisable rules which, in use, collectively prescribe a ranking for a live event based on one or more attributes of said live event, wherein a live event with a higher rank will be a higher priority event and a live event with a lower rank will be a lower priority event; means for receiving a plurality of live streams of video data relating to a respective plurality of live events; means for receiving, in real-time, metadata relating to the plurality of live events, wherein the metadata comprises data indicative of the one or more attributes of the plurality of live events; means for ranking, based on the custom ruleset and the metadata, the plurality of live events relating to the plurality of live streams of video data in dependence on the one or more attributes of the said plurality of live events; andmeans for generating, by a processor, instructions for displaying the plurality of live streams of video data, wherein the instructions comprise instructions for: (i) distributing the plurality of live streams of video data across one or more channels in dependence on the ranking, and (ii) a temporal order in which the plurality of live streams of video data is to be displayed in dependence on the ranking.

18. A system according to claim 17, and further comprising: means for producing at least one live stream output of video data in accordance with the instructions, wherein the at least one live stream output comprises an arrangement of the plurality of live streams of video data, and wherein each of the plurality of live stream outputs corresponds to a channel of the one or more channels; and means for distributing the plurality of live stream outputs of video data to at least one client for display on at least one visual display device19. A live event coverage production system, comprising: means for receiving user instructions to create a custom ruleset via a user interface, the custom ruleset comprising a list of customisable rules which, in use, collectively prescribe a ranking for a live event based on one or more attributes of said live event, wherein a live event with a higher rank will be a higher priority event and a live event with a lower rank will be a lower priority event; means for receiving a plurality of live streams of video data relating to a respective plurality of live events; means for receiving, in real-time, metadata relating to the plurality of live events, wherein the metadata comprises data indicative of the one or more attributes of the plurality of live events; means for ranking, based on the custom ruleset and the metadata, the plurality of live events relating to the plurality of live streams of video data in dependence on the one or more attributes of the said plurality of live events; means for generating, by a processor, instructions for displaying the plurality of live streams of video data, wherein the instructions comprise instructions for: (i) distributing the plurality of live streams of video data across one or more channels in dependence on the ranking, and (ii) a temporal order in which the plurality of live streams of video data is to be displayed in dependence on the ranking; means for outputting a forecast to a user of how the plurality of live streams of video data will be displayed based on the generated instructions, based on the custom ruleset and received metadata; means for receiving updated user instructions to create an updated custom ruleset via the user interface;means for re-ranking, based on the updated custom ruleset and the metadata, the plurality of live events relating to the plurality of live streams of video data in dependence on the one or more attributes of the said plurality of live events; means generating, by the processor, updated instructions for displaying the plurality of live streams of video data, wherein the updated instructions comprise instructions for: (i) distributing the plurality of live streams of video data across the one or more channels in dependence on the re-ranking, and (ii) a temporal order in which the plurality of live streams of video data is to be displayed in dependence on the re-ranking; based on the generated updated instructions, means for outputting an updated forecast to the user of how the plurality of live streams of video data will be displayed, based on the updated custom ruleset and received metadata; wherein the above operations are repeated as necessary for any further updated user instructions until the instructions for displaying the plurality of live streams of video data are finalised.

20. A live event coverage production system, comprising: means for receiving user instructions to create a custom ruleset via a user interface, the custom ruleset comprising a list of customisable rules which, in use, collectively prescribe a ranking for a live event based on one or more attributes of said live event, wherein a live event with a higher rank will be a higher priority event and a live event with a lower rank will be a lower priority event; means for receiving a plurality of live streams of video data relating to a respective plurality of live events; means for receiving live metadata relating to the plurality of live events, wherein the metadata comprises data indicative of the one or more attributes of the plurality of live events; means for ranking, based on the live metadata and the custom ruleset created from the most recently received user instructions, the plurality of live events relating to the plurality of live streams of video data in dependence on the one or more attributes of the said plurality of live events; means for generating instructions for displaying the plurality of live streams of video data, wherein the instructions comprise instructions for: (i) distributing the plurality of live streams of video data across one or more channels in dependence on the ranking, and (ii) a temporal order in which the plurality of live streams of video data is to be displayed in dependence on the ranking; and means for outputting a forecast to a user of how the plurality of live streams will be displayed, based on the current instructions;wherein the ranking, generating and forecasting operations above are repeated whenever new user instructions are received.

Images