WO2023194942A1

WO2023194942A1 - A media streaming network and processes

Info

Publication number: WO2023194942A1
Application number: PCT/IB2023/053510
Authority: WO
Inventors: David John BLAIR; Craig Alexander Meek; Fergus Hamilton MILNER
Original assignee: BestSeat 360 Limited
Priority date: 2022-04-07
Filing date: 2023-04-06
Publication date: 2023-10-12

Abstract

A media streaming process and system for displaying synchronized media streams, comprising a plurality of capture devices configured to capture or generate media data; a plurality of external devices configured to capture or external data; a plurality of transmission modules each in operative communication with one or more capture devices and one or more external devices, and configured to receive media data from the one or more capture devices and external data from the one or more external devices; wherein each transmission module is configured to generate a media stream comprising at least media data, external data and timecode data; wherein the media streams are configured to be synchronized based on the timecode data allowing synchronized playback of the media streams at a viewing device.

Description

A MEDIA STREAMING NETWORK AND PROCESSES

FIELD OF THE DISCLOSURE

This invention relates to systems and processes for streaming media data. More specifically, it relates to processes performed by media streaming networks to stream synchronised media data.

BACKGROUND

Media streaming involves capturing media data, at cameras for example, and streaming the data to multiple viewers.

Transmitting media from events, such as sporting events is a well-established industry.

Developments in cameras, particularly in the quality of media captured by small and/or low- cost cameras, provide opportunities for enhanced experiences of viewers of events.

Some media streaming networks are able to provide a viewer experience that uses data from multiple cameras, possibly at different points of an event.

It would be of advantage to have improvements in the field of media-streaming networks which facilitate viewer experiences that utilise multiple streams of media, or at least to provide the public with a useful choice.

In this specification where reference has been made to patent specifications, other external documents, or other sources of information, this is generally for the purpose of providing a context for discussing the features of the disclosure. Unless specifically stated otherwise, reference to such external documents or such sources of information is not to be construed as an admission that such documents or such sources of information, in any jurisdiction, are prior art or form part of the common general knowledge in the art.

SUMMARY

In a first aspect, this disclosure broadly comprises a process for displaying synchronized media streams, the process comprising: receiving at a first transmission module a first set of media data, and at least a first external data; generating a first media stream comprising at least the first set of media data, the first external data and timecode data, receiving at a second transmission module a second media stream, and at least a second external data; generating a second media stream comprising at least the second set of media data, the second external data and timecode data, transmitting the first media stream and the second media stream to a streaming server; accessing the media streams from the streaming server at a web server; and generating a viewer interface at the web server, the viewer interface for displaying the media streams to a viewer; wherein the media streams are configured to be synchronized based on the timecode data allowing synchronized playback of the media streams at the viewing interface.

In a configuration, the playback of media streams comprises playback of media data and external data concurrently at the viewing interface.

In a configuration, the external data is configured to be overlaid on the media data at the viewer interface.

In a configuration, the viewer interface is configured to allow selection between different media streams to be displayed at the viewing interface using user inputs.

In a configuration, the selection at the viewer interface is configured to switch between the first and second media streams displayed at the viewing interface.

In a configuration, the synchronization of the media streams is such that the moment in time of the next media stream selected for viewing matches the time of the previously selected media stream viewed to provide a continuous playback of an event while changing media streams.

In a configuration, the viewer interface is operable to connect to multiple streaming services provided by the streaming server and is operable to display and/or allow a viewer to select streams from a candidate set of media streams.

In a configuration, the viewing interface allows a selection between different synchronized audio streams, the audio streams optionally representing different commentary streams received as media data at one or more transmission modules. In a configuration, the timecode may be time data derived from a real-time clock in a transmission module.

In a configuration, the external data comprises sensor data and/or telematic data and/or CANbus data.

In a configuration, a media stream further comprises context data received at or provided by a transmission module.

In a configuration, the media data is received from a camera in operative communication with a transmission module.

In a configuration, the step of generating a media stream comprises the following steps: demultiplexing video data and audio data within the media data received, adding the external data and timecode data, remultiplexing the combined video, audio, external data, and timecode data; and optionally compressing the remultiplexed media stream.

In a configuration, the step of generating a media stream further comprises recognizing specific objects within media data using one or more object recognition processes.

In a configuration, the one or more object recognition processes may be configured to output object tracking co-ordinate data, the co-ordinates relating to the location of the specific objects being tracked within the video, wherein the generated media stream further comprises the object tracking co-ordinate data.

In a configuration, the viewer may select an object of interest to track from a menu presented via the viewing interface and generated by the web server, based on the object tracking coordinate data.

In a configuration, the process further comprises transmitting audio data or audio and video data from a microphone and/or camera associated with or operatively connected to the viewer interface to the web server. In a configuration, the process further comprises generating a further media stream comprising the audio data or audio and video data from the microphone and/or camera associated with or operatively connected to the viewer interface.

In a second aspect, this disclosure broadly comprises a media streaming system for displaying synchronized media streams, the media streaming system comprising: a plurality of capture devices configured to capture or generate media data; a plurality of external devices configured to capture or external data; a plurality of transmission modules each in operative communication with one or more capture devices and one or more external devices, and configured to receive media data from the one or more capture devices and external data from the one or more external devices; wherein each transmission module is configured to generate a media stream comprising at least media data, external data and timecode data; a streaming server comprising at least a database and configured to receive media streams from the plurality of transmission modules and provide or allow access to the media streams; and a web server configured to access or receive the media streams from the streaming server, and generate one or more viewer interfaces for viewing the media streams; wherein the media streams are configured to be synchronized based on the timecode data allowing synchronized playback of the media streams at the viewing device.

In a configuration, each transmission module is configured to control one or more capture devices to commence receiving media data or to cease receiving media data.

In a configuration, the system further comprises a control server configured to register each transmission module, allowing the transmission module to transmit media streams to the streaming server.

In a configuration, the external data is configured to be overlaid on the media data at the viewer interface. In a configuration, the viewer interface is configured to allow selection between different media streams to be displayed at the viewing interface using user inputs.

In a configuration, the viewing interface allows a selection between different synchronized audio streams, the audio streams optionally representing different commentary streams received as media data at one or more transmission modules.

In a configuration, the timecode may be time data derived from a real-time clock in a transmission module.

In a configuration, the plurality of external devices comprise one or more sensors and/or one or more ECUs and/or one or more telematic data capture devices, and the external data comprises sensor data and/or telematic data and/or CANbus data.

In a configuration, the plurality of capture devices comprises a plurality of cameras configured to generate video data and/or audio data. In a configuration, the generation of a media stream comprises: demultiplexing video data and audio data within the media data received, adding the external data and timecode data, remultiplexing the combined video, audio, external data, and timecode data; and optionally compressing the remultiplexed media stream.

In a configuration, the generation of a media stream further comprises recognizing specific objects within media data using one or more object recognition processes.

In a configuration, the viewer interface is further configured to transmit audio data or audio and video data from a microphone and/or camera associated with or operatively connected to the viewer interface to the web server.

In a configuration, the viewer interface or the web server is configured to generate a further media stream comprising the audio data or audio and video data from the microphone and/or camera associated with or operatively connected to the viewer interface.

In a third aspect, this disclosure broadly comprises a media streaming process which provides a display of streamed data, the process comprising: generating a viewer interface; displaying at the viewer interface data generated dependent on a first media stream, the display providing a playback of video captured; reading first time data from the first media stream; receiving a request to switch media streams; in response to the request to switch media streams determining a point in time for the played back video, said point in time determined dependent on the time data read from the first media stream; retrieving a second media stream; reading time data carried in the second media stream; and reading time data within the second media stream, determining a point of time in the second media stream; and displaying at the viewer interface data generated dependent on the second media stream starting at the point in time determined in response to the switch request being received.

The time data may be suitable to relate the video data to a start time for capture of video data carried in the first stream and the second stream, which were synchronised.

The first and second media streams may be live streams provided by first and second media streaming services.

The first and second media streams may be received from stored media.

The first and second media streams may be received from stored video-on-demand services.

The time data may be a time code.

The time data may be a playtime from a start of media value.

The first and second media streams may comprise video data captured in an area covered by a private network and may comprise time data that has been synchronised over said private network.

The viewer interface may be generated by a web server.

The one or more media streams may be provided by a media server.

The one or more media streams may be accessed using respective one or more items of access data.

The access data may be a Uniform Resource Locator (URL).

In a fourth aspect, this disclosure broadly relates to a media streaming process comprising the steps of: receiving captured data at the transmission module, said captured data received from one or more data capture devices associated with the transmission module; generating media data in response to the start command, the media data suitable to stream over a network, the media data comprising video data carrying information on video captured at one or more data capture devices, the media data further comprising data carrying information provided by (for example) an ECU (engine control unit) communicating with the transmission module.

In a fifth aspect, this disclosure broadly relates to a media streaming process comprising the steps of: receiving captured data at the transmission module, said captured data received from one or more data capture devices associated with the transmission module; generating media data in response to the start command, the media data suitable to stream over a network, the media data comprising video data carrying information on video captured at one or more data capture devices, the media data further comprising data carrying information provided by an engine control unit (ECU) communicating with the transmission module.

In a sixth aspect, this disclosure broadly relates to a media streaming process comprising the steps of: receiving at a transmission module a start command, the start command carrying information indicating a start event; in receiving captured data at the transmission module, said captured data received from one or more data capture devices associated with the transmission module; generating media data, the media data suitable to stream over a network, the media data comprising video data carrying information on video captured at one or more data capture devices, the media data further comprising time data carrying information provided by a clock associated with the transmission module.

In a seventh aspect, this disclosure broadly relates to a media streaming process comprising the steps of: receiving captured data at the transmission module, said captured data received from one or more data capture devices associated with the transmission module; generating media data in response to the start command, the media data suitable to stream over a network, the media data comprising video data carrying information on video captured at one or more data capture devices, the media data further comprising data carrying information on data captured by a sensor. The data carried by a sensor may be telemetric data.

In an eighth aspect, this disclosure broadly relates to a media streaming process comprising the steps of: receiving captured data at the transmission module, said captured data received from one or more data capture devices associated with the transmission module; generating media data in response to the start command, the media data suitable to stream over a network, the media data comprising video data carrying information on video captured at one or more data capture devices, the media data further comprising data carrying information on a context for the camera associated with the transmission module.

The network may comprise a private network.

The network may comprise a private network communicating with a public network.

The event context data may be data entered at an installation interface. Said data may carry information input to identify a context for the transmission module and/or associated camera. This may be a context within a venue. This may be a context within an event. The context data may carry information to be displayed at a viewer interface which displays media data and which displays controls to allow a viewer to view media from a selected camera. The context data may allow a viewer to identify a camera to provide media to be displayed at the viewer interface.

The process may comprise a step of receiving at a transmission module a start command, the start command carrying information indicating a start event.

The step of generating media data may be in response to the transmission module receiving the start command.

The process may comprise transmitting the media data.

The process may comprise transmitting the media data over a private network.

The process may comprise transmitting the media data to a media server.

The process may comprise transmitting the media data to a media server using input access data identifying an endpoint of a media streaming service.

The process may comprise performing one or more steps of any paragraph above at first and second transmission modules. The process may comprise the first transmission module transmitting first media data to a media server using input access data identifying an endpoint of a first media streaming service.

The process may comprise a second transmission module transmitting second media data to a media server using input access data identifying an endpoint of a second media streaming service. An endpoint may be an endpoint as described in an Application Programming Interface (API).

The process may further comprise the step of storing data carrying information on the media data so as to be accessible at first and second endpoints.

The process may further comprise the step of storing data carrying information on the media data so as to be accessible to a web server.

The process may further comprise the step of storing data carrying information on the media data so as to be accessible at a viewer interface.

The viewer interface may be rendered at a browser application.

The step of storing data may comprise storing the data at a streaming server.

The step of storing data carrying information on the media may comprise storing the data at a service which provides a media stream.

The step of storing data carrying information on the media may comprise a step of encoding the media data for streaming as a HTTP Live Stream (HLS) manifest.

The step of storing data carrying information on the media may comprise a step of encoding the media data for steaming as a HTTP Live Stream manifest.

The step of encoding may be to encode as a HTTP Live Stream manifest.

The step of encoding may be carried out at a media server.

The time data may be included in the media data in a second track additional to a first track which carries video data.

The time data may be data generated by an ECU.

The time data may be data generated at a clock associated with the transmission module.

The clock may be a real-time clock.

The clock may be internal to the transmission module. The clock may be synchronised with the clock of a second transmission module. The clock may be synchronised with the second transmission module by connection via a network time protocol.

The media data may comprise a time track carrying time data.

The generating media data may be in response to a the [first] transmission module receiving the start command simultaneously with a second transmission module.

A data capture device associated with a transmission module may be a device peripheral to the transmission module.

A data capture device associated with a transmission module may be in communication with the transmission module.

A data capture device associated with a transmission module may be co-located with the transmission module.

A data capture device associated with a transmission module may be responsive to one or more control signals provided by the transmission module.

A data capture device associated with a transmission module may be a camera.

A data capture device associated with a transmission module may be a telematic data capture device.

A data capture device associated with a transmission module may be an ECU.

A data capture device associated with a transmission module may utilise a CANbus, typically used by ECU and other vehicle computing modules.

The process may comprise generating a data defining a viewer interface at a server.

The server may be a web server.

In a ninth aspect, this disclosure broadly relates to a process of transmitting data to a media server, the process comprising: receiving at a transmission module video data captured by a camera; receiving time data at the transmission module; generating at the transmission module a data stream comprising the video data and the time data. The process may comprise receiving the time data from an ECU or RTC (real time clock).

The process may comprise continuously receiving the time data.

In a tenth aspect, this disclosure broadly relates to a process of providing a media steaming display comprising: receiving from a server a first stream of media including a video track [first track], receiving from a server a first stream of media including a sound track [second track], receiving from a server a first stream of media including a data track containing time

(timecode) [third track] data, receiving from a server a first stream of media including a second data track containing additional [fourth track] data, extracting time data from the timecode track [third track] of the media stream; displaying at a viewing interface display data rendered dependent on the first media stream, the display data comprising a sequence of frames of video data captured at a first camera, or first set of cameras, displaying at the viewing interface display data rendered dependent on the first media stream, the display data comprising a sequence of frames of sound data captured at a first camera, or first set of cameras, displaying at the viewing interface display data rendered dependent on the first media stream, the display data comprising a sequence of frames of time code data inserted by the transmission module as an additional data track (time code) in the media stream, displaying at the viewing interface display data rendered dependent on the first media stream, the display data comprising a sequence of frames of ECU or other sensor data transmitted to the transmission module and inserted by the transmission module as an additional data track in the media stream, wherein the stream which the display data is rendered dependent on is switched dependent on control input made at a control presented at the viewing interface displaying at the viewer interface data rendered dependent on the second stream of media data.

In an eleventh aspect, this disclosure broadly relates to a process of providing a media steaming display comprising: receiving from a server a first stream of media data, receiving from a server a second stream of media data, extracting time data from the first stream of media data; displaying at a viewing interface display data, the display data rendered dependent on the first media stream of media data or the second stream of media data, the display data comprising a sequence of frames of video data captured at a first camera or a sequence of frames of video captured at a second camera, wherein the stream of media data which the display data is rendered dependent on is switched dependent on a control input made at a control presented at the viewing interface displaying at the viewer interface data.

In a twelfth aspect, this disclosure broadly relates to a media streaming network operable to perform the steps of any paragraph above.

In a thirteenth aspect, this disclosure broadly relates to a media streaming network operable to provide two or more media streams carrying information on video data captured at cameras, the network comprising two or more transmission modules each operable to communicate with a network to transmit a media stream, each module operable to include in its respective media stream time data which carries information suitable to relate given frames in video data to a start event, the set of transmission modules operable to receive a communication over the network indicating the start event.

As used herein captured data is intended to broadly define any data generated to capture images, events, conditions at a data capture device, and specifically includes data carrying images, media, and telemetry to name some examples.

In an aspect, this disclosure broadly comprises a non-transitory computer-readable medium having stored thereon computer executable instructions that, when executed on a processing device or devices, cause the processing device or devices to perform any method of any one or more aspects above.

In an aspect, this disclosure broadly comprises a set of application program interfaces or an application program interface (API) embodied on a computer-readable medium for execution on a processing device in conjunction with an application program that perform any method of any one or more aspects above.

Any aspect of this disclosure above may further comprise any one or more aspects or features mentioned in respect of any one or more of the other aspects, or wherein any aspect of the storage, transmission, processing, display, and/or rendering of any data, data reports, time-series charts, and/or any aspect of the related system architecture may have any one or more of the features mentioned in respect of any other aspect described above, in any combination.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features, aspects, and advantages of the present disclosure are described with reference to the drawings of certain embodiments, which are intended to schematically illustrate certain embodiments and not to limit the disclosure.

Figure 1 : shows a media streaming network according to an example;

Figure 2: shows a media streaming synchronisation process according to an example;

Figure 3: shows a process of synchronized live media according an example;

Figure 4: shows a process of synchronized Video On Demand (VOD) according to an example;

Figure 5 shows a process of synchronized object tracking according to an example;

Figure 6 shows a process of synchronized commentary according to an example;

Figure 7 shows a process of synchronized viewer created commentary according to an example; and

Figure 8 shows a process of synchronized digital video effects according to an example.

Further aspects will become apparent from the following description which is given by way of example only of particular examples.

DETAILED DESCRIPTION

Figure 1 shows an example media streaming network 1. The media streaming network 1 of this example streams data, specifically media data (also referred to as ‘media’), including various tracks such as video, audio, data, and timecode. The media data may be captured at multiple capture devices 2, such as cameras for viewing at multiple viewer interfaces 13. One or more media streams may be provided by the media streaming network 1 .

The media is streamed to given viewer interfaces. The media streamed, including the view elements and streams as seen by each individual viewer on a viewer interface are dependent on inputs made by a viewer at their respective viewer interface. The media streamed by the media streaming network 1 may also be dependent on inputs by an administrator at an administrator interface. The media streaming network 1 is initialised and configured by a centralised control server. As will be described, each media stream has a system of synchronisation deployed at time of creation by a transmission module, in this embodiment a timecode added to the media stream or a simultaneous initiation of all of the media streams at the same point in time such that recorded playback of media streams can be synchronised. As the reader will observe, the media streaming network 1 may include a network (such as a private and/or wireless network) communicating with a public network and the entities, components or component modules illustrated below with reference to the diagrams.

The component modules of the media streaming network 1 will now be described, including the process of synchronised playback and data display.

The media streaming network 1 has one or more, but typically multiple, capture devices 2, such as cameras which capture streaming data comprising at least one of photo data, audio data, and video data that may potentially be streamed to viewer interfaces 13. The media streaming network 1 of this particular example also has one or more, but typically multiple, sensors (not shown) to capture data to be streamed to viewer interfaces. In this example the sensor data captured includes telemetry data. The sensor(s) may also be capture devices 2.

The media streaming network 1 has a user interface 4, such as (but not limited to) an installer interface or local interface 4. The installer interface can optionally be remotely accessed by authorized login via a public network. In this example the interface 4 allows a user to enter data locally. The user may be a person installing capture devices such as cameras or sensors, or possibly configuring the capture devices, such as cameras and sensors. In this example the data to be streamed includes context data which describes an event context for the camera installation. In one example the context data may name a competitor and position on their person or apparatus used, such as helmet or a place on a car. In this example the installer interface 4 is in communication with a transmission module 5. The data may be entered locally to the specific transmission module by the user, using the installer interface or local interface 4.

Figure 1 also shows transmission module 5 (also referred to as a ‘transmission box’ or ‘t- box’). Each transmission module 5 is operable to communicate with one or more capture devices 2 such as cameras to receive a data signal from the camera. In this embodiment the data signal from the camera 2 carries media including various tracks such as video, audio, and timecode data. In this example, each transmission module 5 is operable to communicate with one or more capture devices 2 2 and also to control the one or more capture devices 2. For example, each transmission module 5 may be able to control one or more capture devices to commence capturing media or to cease capturing data and/or media. In this example also the transmission module 5 is operable to receive data from other capture devices (not shown) which capture sensor data and/or capture telemetry data. This sensor data and/or telemetry data may be added to a media stream. Additionally, timecode data may be added to a media stream. Sensor/telemetry data and timecode data which is added to a media stream may be added as additional tracks within the media stream or by some other proprietary method such that the video, audio, data, and timecode all are transmitted from a transmission module to a viewer interface.

The transmission module 5 may be operable to generate media streams for transmission within the network 1 . In this example, generating media streams involves any one or more of the following steps: demultiplexing video and audio within media received from cameras, adding sensor/telemetry/context data and/or timecode data, remultiplexing combined video, audio, sensor/telemetry/context data, and/or timecode data, and optionally recompressing the media stream to optimize network transmission. The transmission module 5 shown in Figure 1 is operable to communicate with the network 1 via a network 6. The transmission module 5 of this example is operable to communicate with a streaming server 7. In this example, the transmission module 5 is able to receive media from multiple cameras 2 and/or sensors 3 to combine these into a media stream. Additionally, the transmission module 5 may apply a CODEC process to generate a compressed media stream and to transmit that media stream over the network 6 to streaming server 7. The network 6 may be a private or public network of sufficient performance. The network 6 may be a wireless network. In this example, the transmission module 5 may also be able to capture external data, for instance CANbus data from a car, or biometric data from locally connected sensors (not shown). The local connection of such sensors could be by wire, or wirelessly through Bluetooth, Wi-Fi, LORAwan or other wireless transmission systems (not shown). The transmission module 5 can incorporate external data captured in this manner as a data track in the media being transmitted. In this example, this retains time synchronisation of changing data with the video and audio tracks of the media stream.

The transmission module 5 is also operable to communicate with a centralised streaming network control module 8 over the private network 6 with processes such as those described below. In this example, the control module 8 is a server. The transmission module 5 may be operable to communicate with the centralised streaming control server 8 to register the transmission module 5 with the control server 8, or with the network 1 more generally. This allows any transmission module 5, which may be provided and installed locally at an event, to become part of the network 1 and to stream media over the network 1 to the media stream server 7.

The transmission module 5 may also communicate with the server 8 to communicate data carrying information on a transmission module identifier and/or camera identifier and/or peripheral device identifier. The transmission module of this example may also communicate context data. The context data may be provided by installation personnel. In an example the context data is entered at the installer interface 4, which may be remotely accessed via the network 6. The installer interface 4 may be configured by an administrator 12 through a user interface 11 for administration personnel. The administration user interface 11 may send configuration data to the control Server 8 (e.g via API) and then on to the Installer Interface 4, performing the same actions as a local installer using the installer interface 4 would. In this example the context data provides context for one or more capture devices such as cameras within a location or event. In this example the context data may identify a competitor and/or piece of apparatus within an event. For example, the context data may relate to or enable identification of a driver or participant in an event, e.g. it may contain the driver’s name and/or the context data may relate to or enable identification of the location of a capture device such as camera within the event, which may be such as on a driver’s helmet, or on a driver’s car. The transmission module 5 is also able to communicate with the server 8 to receive data that allows it to connect to other parts of the network, such as to connect to the streaming server 7 to provide media. In this example the data received by the transmission module 5 from the control server 8 includes input connection data that allows the transmission module 5 to connect to a specific streaming service provided by the streaming server 7. In this example the input connection data carries information on an endpoint of a streaming service provided by the streaming server 7 to receive media and includes access data, specifically a RTMP code in this example. The access data may be any number of transmission protocols such as (but not limited to) RTP, RTSP, SRT, SST etc details of which are available to the reader from other sources. The transmission module 5 is also able to receive configuration data from the server 8.

The network 6 of this embodiment may be a private network, or it may be a public network of sufficient performance. In this example the network is a 5G network with a base-station local to a venue of an event to provide connectivity for the transmission boxes involved in the event. In this embodiment, the network 6 also registers with the control server 8 and/or the network 1 in general.

Although Figure 1 shows a single exemplary transmission module 5 with associated capture device 2, examples may have multiple transmission modules 5 and multiple capture devices 2. For example, a transmission module 5 may receive data from a camera 2 mounted on each car of a multiple car race event. In this example each transmission module 5 may generate a media stream to be transmitted over the network 6 to other parts of the network 1 . In an example with two transmission modules 5, a first transmission module 5 may transmit a first media steam to the media server 7, or a media service instantiated by it, and a second transmission module (not shown) may transmit a second media steam to the media server 7. The first and second media streams transmitted from the transmission modules carry information on the data and/or video data captured by the camera 2 or other data captured by a camera or capture device 2 associated with the respective first or second transmission module. In such examples the media server 7 may provide first and second media streams carrying information on the video or data captured by one or more capture devices 2 associated with a respective first or second transmission module 5. A media stream output from the media server 7, or a media service instantiated by it, may carry data which has been generated that is dependent on data carried in the respective first or second input media steam transmitted by the respective first or second transmission module. Figure 1 also shows a streaming network database 9. The streaming network database 9 of this embodiment is a database under the control of the control server 8. The control server 8 may use the database 9 to store transmission module 5 identifiers of transmission modules registered with the network 1 . The control server 8 may also use the database 9 to store input connection data used by transmission boxes to access the streaming server 7. The database 9 of this example stores data to associate an identifier of a given transmission module 5 with a URL for an input to the streaming server for a stream. In this embodiment also the database stores data to associate the transmission module 5 identifier with a connection specifier for example, (but not limited to) a URL for an output media stream instantiated by the media server. This allows access to the stream provided by the server 7 that carries media including video, audio, data, and timecode provided by a given transmission module 5.

The database 9 may also be operable to store media locators such as (but not limited to) a URL for video on demand access of media stored in the Media Stream Server 7, and/or the Remote Control Server 8 and its associate file storage repositories (not shown). In this example, this media stored for video on demand data is received from the streaming server 7 via the control server 8. The database 9 may also be operable to store configuration data used to configure the transmission modules 5 and connected capture devices such as cameras 2 and sensors or other peripheral devices 3.

The network 1 may also have a user interface server or database 10. The server 10 may be a web server using web protocols known to the reader to generate web pages at URLs provided. The web server 10 may be operable to generate a user interface 11 for administration personnel 12. The administration interface 11 may be operable to receive control inputs from the administrator 12 and to receive configuration data. These inputs allow configuration data to be inputted to the network 1 . Control inputs at the administrator interface allow an administrator 9 to enter configuration data for given transmission modules 5. The administration interface 11 also allows an administrator 12 to prompt the database 9 to send the configuration data to the control server 8 and to prompt the control server 8 to transmit configuration data to transmission modules 5. The administration interface 11 may also allow an administrator 12 to configure the one or more viewer interfaces 13. In one example, control inputs at the administration interface 11 configure which specific feeds from a set of feeds from transmission modules 5 a viewer 14 is able to select for viewing at their respective viewing interface 13. The reader may recognise this as an administrator being able to curate 360 camera video feeds that are selectable or otherwise controllable by a viewer at viewer interfaces 13. This curation may relate to the control of an aspect of the network 1 .

The user interface server 10 generates data for a number of the graphical user interfaces 13 at which viewers 14 can view and control media streamed from various cameras 2 and/or peripheral devices three connected to various transmission modules 5. These graphical user interfaces 13 may be recognised as viewer interfaces. The viewer interface 13 may be a graphical user interface using any suitable windowing system known to the reader. The viewer interfaces 13 may be viewed using browser software at a viewer device. A viewer interface 13 may require a subscription and accesses the web server 10 by methods known to the reader. The viewer interface 13 may be customisable at both the administration interface 11 and at viewer interface 13.

The viewer interface 13 may display context data which carries information on the context of a given camera 2 and/or peripheral 3 and/or transmission module 5. For example, the context data may carry information on the identity of a participant in an event, such as (but not limited to) the name of the event, driver, car or team, or CANbus data, such as that provided from a car’s ECU. The viewer may use the context data, or information carried, to select a given media streaming service provided by the streaming server 7, or to display additional information as graphic overlay on top of media being viewed. The media streaming service streams a camera feed, for example, from a given transmission module 5 dependent on selections and/or controls made by a viewer 14 at their respective viewer interface to 13.

In this example, the viewer interface 13 is provided by the web server 10. In this example also, the viewer interface to 13 allows selection and/or initiation of video-on-demand data to be viewed. The viewer interface 13 may store demand access data to allow video on demand to be received from a database. This access data may include a URL of the database API, commands defined for the API and data required to access the video on demand data. The viewer interface 13 may be operable to connect to multiple streaming services provided by the streaming server 7 at multiple API endpoints and is operable to display and/or allow the viewer to select streams from a candidate set of media streams. This may be live streams or video on demand streams. The candidate set of media streams is typically curated by control inputs at the administrator interface 11 provided for an administrator 12. In one example, a viewer interface 13 allows the viewer to select from a set of available 360 camera media streams from multiple cameras mounted on each of a number of cars in a race. For example, a viewer may select a camera mounted on an aerofoil on a car driven by the same driver and select a helmet camera of another driver. In this embodiment also, the user interface 13 allows the viewing direction from the 360 camera to be selected or controlled by the viewer. For example, a viewer may change the direction of viewing from a given 360 camera and may control what portion of a full 360 camera media feed appears on a two-dimensional window in a given viewer interface to 13. A 360 camera may provide media capturing images and video from a 2TT steradian range of directions and a 2- dimensional window at the viewer interface 13 that covers a subset of those steradians. The viewer 13 interface of this example allows the viewer to move the viewing angle within the full range of media captured by the 360 camera.

The media server 7 may be operable to instantiate a number of media streaming services. The media server 7 may be able to communicate with the control server 8 to receive requests to instantiate a new streaming service at the request of the control server 8. The media server 7 may further be operable to generate access data for media to be used as an input to the media service. In this embodiment this includes a URL 5 for an endpoint of the media streaming service and may include for example (but not limited to) an RTMP code. The media server 7 may be operable to communicate this input media access data to the control server 8.

The media server 7 may also be operable to communicate with a number of viewer interfaces 13. The media server 7 may provide a URL for an API endpoint for each media stream. In this example, a media stream provides 360 camera streamed data for a single camera 2, such as one of the cameras connected to a single transmission module 5. Viewer interfaces 13 are able to connect to the endpoint to receive the 360 media data stream for that given camera, for example. In one example, the viewer interface 13 displays context data used by a viewer 14 to select a given camera. The viewer interface 13 receives control inputs from the viewer which allows the viewer to select, or deselect, the given camera. Output access data provided by the Web server 10 allows the viewer interface to connect to the appropriate media stream to have a stream available for display at a window of the viewer interface 13. In this example, the media streams the 360 camera stream within which a viewer can to navigate to select a portion, such as a number of steradians of the 360 camera stream to be viewed in a given window of the viewer interface 13.

In one example, the viewer interfaces 13 are configured by the administrator 12 via the front end webserver 10 to configure the appearance and layout of the viewer interfaces 13.

Various connectivity and operations of the control server 8 have been described above. Further connectivity and operations will now be described.

The control server 8 may be operable to communicate with transmission modules 5 over the network 6. This communication allows the control server 8 to receive an identifier for a transmission module 5, or connected device, and store that data using the database 9. The control server 8 is operable to communicate with the database 9 to store transmission module identifier data and to send input media stream access data provided by the media server 7 to transmission modules 5.

The control server 8 may also be operable to receive output media stream access data from the media server 7 and store it with the database 9. The control server 8 may also be operable to retrieve the video on demand access data including all tracks such as video, audio, data, and timecode from the database and send it to the Web server 10. As discussed above, the control server 8 is able to request that a new media stream is instantiated by the media server 7 to receive streaming service input access data and receive streaming service output access data. Specifically, the process of instantiating a media stream in this context at the media server 7 refers to an API call made by the Remote Control Server 8 using data stored in the DataBase 9 to control the media server 7 to create a new media streaming channel, set that newly created media stream channel to “running” mode and retrieve input and output connection data e.g. (but not limited to) Media stream input and output URLs, which are then passed via API to the Transmission Module 5 and the viewer interface 13. Importantly the reader may appreciate in this embodiment no technical expertise is required by the Admin Person 11 / 12 for creating a new media stream at the media server 7 and connecting that stream to the viewer interface 13 for selection by the viewer 14. The control server 8 may also be operable to communicate with the web server 10 to receive configuration data input at an administrator interface 11 . It is also operable to send data carrying information identifying a transmission module 5 to the web server 10. In this example the control server 8 is also operable to request that the web server 10 instantiate an administration interface 11.

Example processes performed by the media streaming network 1 will now be described.

Reference will be made to the features previously described and in relation to Figure 1 , including the modules, servers, database and interfaces to describe a further example of the media streaming network 1 , utilizing the same reference numerals as Figure 1 .

In this example, the media streaming network 1 streams data, specifically media, including various tracks such as video and audio. The data may be captured at multiple cameras, and may be combined with data and timecode merged via multiple transmission modules 5 for viewing at multiple subscriber viewer interfaces 13.

The media may be streamed via a transmission module 5 where timecode and data streams may be added for synchronisation of different media streams. The addition of timecode and data streams to the media may allow for synchronisation of data displayed to viewers such that the data is synchronised to the video displayed. This can allow viewer interfaces 13 to be controlled dependent on inputs made by a viewer 14 at their respective viewer interface 13. The media streaming network 1 may also stream media as controlled based on inputs by an administrator 12 at an administrator interface 11 . The media streaming network 1 may be initialised and configured by a centralised control server 8.

The component modules of the media streaming network 1 of this further example will now be described with reference to the same Figure 1 .

The media streaming network 1 has one or more, but typically multiple, cameras or capture devices 2 which capture photo and video data that may potentially be streamed to viewer interfaces 13. The media streaming network 1 also has one or more, but typically multiple, sensors (not shown) to capture data to be streamed to viewer interfaces. In this example the sensor data includes telemetry data.

The media streaming network 1 has a user interface 4, such as an installer interface or local interface 4. In this example the interface 4 allows a user to enter data locally. The user may be a person installing cameras or sensors, or possibly configuring cameras and sensors. In this example the data to be streamed includes context data which describes an event context for the camera installation. In one example the context data may name a competitor and position on their person or apparatus used, such as helmet or a place on a car. In this example the installer interface 4 is in communication with the transmission module 5.

Figure 1 also shows a transmission module 5. The transmission module 5 is operable to communicate with a camera 2 to receive a data signal from the camera. The data signal from the camera 2 may carry media such as video media. In this example, the transmission 5 is operable to communicate with the camera 2 also to control the camera 2. For example, the transmission module 5 may be able to control the camera to commence capturing media or to cease capturing media. In this example also the transmission module 5 is operable to receive data from devices (not shown) which sensor data or capture telemetry data.

The transmission module 5 may be operable to compress media for transmission to the network 1 . The transmission module 5 may be operable to communicate with the network 1 via a network 6.

The transmission module 5 is operable to communicate with a streaming server 7. In this example, the transmission module 5 is able to receive media from multiple cameras 2 and/or sensors 3 to combine these into a ’media stream and optionally apply either a CODEC or remultiplex process to generate or provide a compressed media stream and to transmit that media stream over the network 6 to the streaming server 7.

The transmission module 5 is also operable to communicate with a centralised streaming network control module 8 over the network 6 with processes described below. In this example, the control module 8 is a server. The transmission module 5 is operable to communicate with the centralised streaming network control server 8 to register the transmission module 5 with the control server 8, or with the network 1 more generally. This allows any transmission module 5, which may be provided and installed locally at an event, to become part of the network 1 and to participate in streaming media over the network 1 .

The transmission module 5 may also communicate with the server 8 to communicate data carrying information on a transmission module identifier and/or camera identifier and/or peripheral device identifier. The transmission module of this example also communicates context data. In this embodiment the context data may be provided locally by installation personnel or remotely under control of parameters entered by the administrator^. In this example the context data is entered at the installer interface 4 either locally or remotely via the Administrator 12. In this example the context data provides context for the camera within a location or event. In this example the context data may identify a competitor and/or piece of apparatus in an event. For example, the context data may be a driver’s name and identify that the camera is on their helmet.

The transmission module 5 is also able to communicate with the server 8 to receive data that allows it to connect to other parts of the network, such as to connect to the streaming server

7 to provide media. In this example the data received by the transmission module 5 from the control server 8 includes input connection data that allows the transmission module 5 to connect to a specific streaming service provided by the streaming server 7. In this example the input connection data carries information on an endpoint of a streaming service provided by the streaming server 7 to receive media and includes access data, for example (but not limited to) a RTMP code. The transmission module 5 is also able to receive configuration data from the server 8.

The network 6 may be a private network. In this example the network is a 5G network with a base-station local to a venue of an event to provide connectivity for the transmission boxes involved in the event. In this example, the network 6 may also register with the control server

8 and/or the network 1 in general.

The media streaming network 1 also comprises a streaming network database 9. The streaming network database 9 may be a database under the control of the control server 8. The control server 8 uses the database 9 to store transmission module 5 identifiers of transmission modules registered with the network 1 . The control server 8 also uses the database 9 to store input connection data used by transmission boxes to access the streaming server 7. The database 9 of this example stores data to associate an identifier of a given transmission module 5 with a URL for an input to the streaming server for a stream. The database may also store data to associate the transmission module 5 identifier with a URL of an API for an input media stream instantiated by the media server. This allows access to the stream provided by the server 7 that carries media provided by a given transmission module 5 over the network 6.

The database 9 may also be operable to store media for video on demand access. In this example, this media stored for video on demand data is received from the streaming server 7 via the control server 8. The database 9 is also operable to store configuration data used to configure the transmission modules 5 and connected cameras 2 and peripheral devices 3. The network 1 further comprises a web server 10. The web server 10 may use web protocols known to the reader to generate web pages at urls provided. The web server 10 is operable to generate a user interface for administration personnel 12, in this example an administration interface 11 . The administration interface 11 is operable to receive control inputs from the administrator and receive configuration data. These inputs allow configuration data to be input to the network 1 . Control inputs at the administrator interface allow an administrator 9 to enter configuration data for given transmission modules 5. The administration interface 11 also allows an administrator to prompt the database 9 to send the configuration data to the control server 8 and to prompt the control server 8 to transmit configuration data to transmission modules 5.

The administration interface 11 also allows an administrator to configure viewer interfaces 13. In one example, control inputs at the administration interface 11 configure which specific feeds from a set of feeds from transmission modules 5 a viewer is able to select for viewing at their respective viewing interface 13. The reader may recognise this as an administrator being able to curate 360 camera video feeds that are selectable and otherwise controllable by a viewer at viewer interfaces 13.

The server 10 generates data for a number of the graphical user interfaces 13 at which viewers can view and control media streamed from various cameras 2 and/or peripheral devices three connected to various transmission modules 5. This embodiment the viewer interface 13 is a graphical user interface using any suitable windowing system known to the reader. In this embodiment the viewer interfaces 13 are viewed using browser software at a viewer device. In this embodiment also a viewer interface 13 accesses the web server 10 by methods known to the reader. In the embodiment of Figure 1 , the viewer interface 13 is customisable at both the administration interface 11 and at viewer interface 13. Viewer interfaces 13 may be set up and rendered by the Administrator 12 via the Web server 10 and the remote control server 8, and/or the database 9. Specifically, the Administrator 12 does not require to have specialist expertise in web page design, III design, Front-End code development, or URL code inputs etc. to perform these operations.

The viewer interface 13 may display context data which carries information on the context of a given camera 2, peripheral 3 and/or transmission module 5. For example, the context data may carry information on the identity of a participant in an event, such as the name of the event, driver, car or team. The viewer may use the context data, or information carried, to select a given media streaming service provided by the streaming server 7. The media streaming service streams a camera feed, for example, from a given transmission module 5 dependent on selections and/or controls made by a viewer at their respective viewer interface to 13.

In this example, the viewer interface 13 is provided by the web server 10. In this example also, the viewer interface to 13 allows selection and/or initiation of video-on-demand data to be viewed. In this example, the viewer interface 13 stores demand access data to allow video on demand to be received from a database. This access data may include a URL of the database API, commands defined for the API and data required to access the video on demand data.

The viewer interface 13 is operable to connect to multiple streaming services provided by the streaming server 7 at multiple API endpoints and is operable to display and/or allow the viewer to select streams from a candidate set of media streams. The candidate set is typically curated by control inputs at the administrator interface 11 provided for an administrator 12. In one example, a viewer interface 13 allows the viewer to select from a set of available media streams from multiple cameras mounted on each of a number of cars in a race. For example, a viewer may select a camera mounted on an aerofoil on a car driven by the same driver and select a helmet camera of another driver. The user interface 13 may also allows the viewing direction from the 360 camera to be selected or controlled by the viewer. For example, a viewer may change the direction of viewing from a given 360 camera and may control what portion of a full 360 camera media feed appears on a two-dimensional window in a given viewer interface to 13. A 360 camera may provide media capturing images and video from a 2TT steradian range of directions and a 2-dimensional window at the viewer interface 13 that covers a subset of those steradians. The viewer interface of this example allows the viewer to move the viewing angle within the full range of media captured by the 360 camera.

The media server 7 is operable to instantiate a number of media streaming services (not shown). The media server 7 is able to communicate with the control server 8 to receive requests to instantiate a new streaming service at the request of the control server 8. The media server 7 is operable to generate access data for media to be used as an input to the media service. In this embodiment this includes a URL 5 for an endpoint of the media streaming service and includes for example (but not limited to) an RTMP code. The media server 7 is operable to communicate this input media access data to the control server 8.

The media server 7 is also able to communicate with a number of viewer interfaces 13. This embodiment the media server seven provides a URL for an API endpoint for each media stream. In this example, a media stream provides 360 camera streamed data for a single camera 2, such as one of the cameras connected to a single transmission module 5. Viewer interfaces 13 are able to connect to the endpoint to receive the 360 media data stream for that given camera, for example. In one example the viewer interface 13 displays context data used by a viewer to select a given camera. The viewer interface 13 receives control inputs from the viewer which allows the viewer to select, or deselect, the given camera.

Output access data provided by the Web server 10 allows the viewer interface to connect to the appropriate media stream to have a stream available for display at a window of the viewer interface 13. In this example, the media streams the 360 camera stream within which a viewer can to navigate to select a portion, such as a number of steradians of the 360 camera stream to be viewed in a given window of the viewer interface to 13.

Various connectivity and operations of the control server 8 have been described above. Further connectivity and operations will now be described. The control server 8 of this embodiment is able to communicate with transmission boxes 5 over the network 6. This allows it to receive an identifier for a transmission module 5, or connected device, and store that data using the database 9. The control server 8 is operable to communicate with the database 9 to store transmission module identifier data and to send input media stream access data provided by the server 7 to transmission modules 5. The control server 8 is also operable to receive output media stream access data from the media server seven and store it with the database 9. The control server 8 is also operable to retrieve the video on demand access data from the database and send it to the Web server 10. As discussed above, the control server 8 is able to request that a new media stream is instantiated by the media server 7 to receive streaming service input access data and receive streaming service output access data.

The control server 8 is also operable to communicate with the web server 10 to receive configuration data input at an administrator interface. It is also operable to send data carrying information identifying a transmission module 5 to the web server 10. In this embodiment the control server 8 is also operable to request that the web server 10 instantiate an administration interface 11.

Example processes performed by the network 1 will now be described. Reference will be made to the features previously described and in relation to Figure 1 , including the modules, servers, database and interfaces to describe a further example of the media streaming network 1 , utilizing the same reference numerals as Figure 1 .

Figure 2 depicts a flow diagram of an example of processes performed to synchronise and display data which may be overlaid at the viewing interface. Although the processes are described with reference to synchronisation, it will be appreciated that processes required as precursors to this synchronisation process may also be used.

At S2-1 an administrator may select an interface element to start a live event. The reader will appreciate there are many precursor actions creating the specifics of this event which are described in relation to the network 1 illustrated in Figure 1 and the operation of the system as a whole.

The administration server 12 then initiates a command to the remote control Server 8 at S2- 2 which assembles a list of all the Transmission Modules 5 associated with the event. The administration server 12 may then transmit a Start command to these transmission modules 5. These commands between servers and other elements such as Transmission Modules 5 may be sent via low-latency protocols such as TCP protocols over the network 6, at S2-3 such that all transmission modules 5 associated with the event effectively receive and act on the Start command at the same time.

The transmission modules 5 associated with the event may receive the start command (not shown) and send a request to the camera 2 (not shown) to send media data, such as video. The camera 2 responds at S2-4 by sending media data , which may include video and audio tracks. In some examples, the camera 2 does not have the capability to generate timecode.

The sensors or ECU 3 may continuously transmit data at S2-5 to the transmission module 5. This transmission may bevia CanBus. The Start command received by the transmission module(s) 5 via the network 6 then initiates at S2-6 a process which receives the media data from the camera 2 and the data from the sensors/ECU 3 and adds the sensor/ECU 3 data to the Camera 2 media data as an additional media track in real time.

At S2-6 the transmission module 5 may also add a timecode track to the media. The timecode may be derived from a Real-Time-Clock (RTC) function in each transmission module 5. The RTCs of all the Transmission Modules 5 attached to an event may be synchronised by connection via NTP (Network Time Protocol) over the Network 6 to the Internet. This allows the timecode via the RTC in Multiple different Transmission Modules 5 to be synchronised.

At S2-7 Transmission Module 5 transmits the one or more media streams including data and timecode tracks along with video and audio tracks via the Network 6.

At S2-8 the Network 6 transmits the one or more media streams to the Streaming Server 7.

At S2-9 the Streaming Server 7 encodes all the media streams from the transmission modules 5 into corresponding live streams e.g. (but not limited to) HTTP Live Streaming (HLS) manifests. Associated URLs for each live stream may then be sent to the Database at S2-10 to facilitate the Viewer interface 13 function at S2-11 of selecting different media streams and the included data track to view.

At S2-11 a process is invoked, typically via JavaScript (JS) or other web programming language, which translates the data to graphical elements in real-time such that the data track of the media stream can be viewed in an informative and contextual manner by the Viewer 14 at the viewing interface 13.

As will be appreciated, media is stored and includes all media tracks such as video, audio, data, and timecode. Therefore, a process of playing back a media stream, also known as Video On Demand or VOD, will also provide a replay of the data synchronised in time with the other tracks in the media stream. At such replay the process at S2-11 would be used to provide a visual replay of data overlay synchronised with the VOD video, and audio tracks within the media stream recorded as encoded by the media server at S2-9, for example (but not limited to) an HLS manifest.

An alternative example of this process could use any other encoding encapsulation such as Mpeg-Dash as an alternate media stream and storage format.

Figure 3 depicts processes performed to synchronise and display different live media streams at the Viewing interface 13. This process allows Viewers 14 to select between different media streams such that the moment in time of the next media stream selected for viewing matches the time of the previously selected media stream viewed to provide a continuous playback of an event while changing viewpoints via media streams coming from different locations at the same event. Although the processes are described with reference to synchronisation, it will be appreciated that processes required as precursors to this synchronisation process may also be used.

At S3-1 an Admin operator 12 clicks a single interface element to start a live event. The reader will appreciate there are many precursor actions creating the specifics of this event which are described in a previous section outlining Figure 1 and the operation of the system as a whole. The Admin Server 12 then initiates a command to the remote control Server 8 which assembles a list of all the Transmission Modules 5 associated with this event and sends them a Start command at S3-2. This is transmitted over the Wireless Network 6 at S3-3.

These commands between servers and other elements such as Transmission Modules 5 are sent via low-latency e.g. (but not limited to) TCP protocols over the Wireless Network 6 such that all Transmission Modules 5 attached to the event effectively receive and act on the Start command at the same time.

The transmission modules 5 receive the command (not shown) and send a request to the camera 2 (not shown) to send video. The camera 2 responds at S3-4 by sending media including video and audio tracks. In this embodiment the camera does not have the capability to generate timecode and also for 360 cameras that can generate timecode there is typically no defined method to synchronise timecode between different cameras.

Meanwhile an Engine Control Unit (ECU) 3 is continuously sending data at S3-5 to the Transmission Module 5. The Start command received by the Transmission Module(s) 5 via the Wireless Network 6 then initiates at S3-6 a process which receives the media from the camera 2 and the data from ECU 3 and adds the ECU 3 data to the Camera 2 media as an additional media track in real time.

Also at S3-6 the transmission module 5 may also add a timecode track to the media. The timecode is derived from an RTC function in each transmission module 5. In this particular embodiment the RTCs of all the Transmission Modules 5 attached to this event are synchronised by connection via NTP (Network Time Protocol) over the Wireless Network 6 to the public internet. This allows the timecode via the RTC in Multiple different Transmission Modules 5 to be synchronised.

The reader will appreciate that the processes of RTC sync via NTP and adding tracks to media are well documented as prior art elsewhere.

At S3-7 multiple Transmission Modules 5 send multiple media streams each including data and timecode tracks along with video and audio tracks via the Wireless Network 6. At S3-8 the Wireless Network 6 transports the media streams to the Streaming Server 7.

At S3-9 the Streaming Server 7 encodes all the media streams from the Transmission Modules 5 into corresponding compressed media streams .

Associated URLs for each media streamare then sent to the Database at S3-10 to facilitate the Viewer 13 function at S3-11 of selecting different media streams and the included data track to view.

At S3-11 a process may be invoked (typically via JS or other web programming language) by the Viewer 13 to select an alternate media stream and its associated data for viewing. At this point the request to view an alternate media stream is sent to the web server 10 which saves the current timecode value, retrieves the next media stream URL from the Database 9 at S3- 13. In alternative embodiments the Web Server 10 saves the current playtime from start of media value.

The next media stream URL is then accessed from the Streaming Server 7 at S3-14 and before it is displayed a JS, or other programming construct, seeks the saved timecode or playback time within the new media stream.

At S3-15 the Viewer 13 watches the new media stream starting from the same time as when the request to switch streams was made. The process of switching between media streams could take time so there is an additional process invoked at S3-15 to measure this time and add it to the time that the new media starts from so as to maintain real-time synchronisation.

At S3-15 a background process is also deployed to check the time code or playback time such that if one of the videos being concurrently played stutters or pauses due to network congestion or other performance-related issues then its playback time will be adjusted within configurable parameters stored in the Database 9.

The reader will also appreciate that the media is stored and includes all media tracks such as video, audio, data, and timecode. Therefore, a process of playing back a media stream (also known as Video-On-Demand (VOD) will also provide an ability to synchronise VOD playback of multiple media streams.

Another embodiment of this process could use Mpeg-Dash or any one of a number of different media stream formats as an alternate media stream and storage mechanism. Mpeg-Dash and other stream formats are also publicly available and well documented elsewhere.

Figure 4 depicts processes performed to synchronise and display different media streams played as VOD at the Viewing interface 13. This process allows Viewers 14 to select between different media streams such that the moment in time of the next media stream selected for viewing matches the time of the previous media stream viewed to provide a continuous playback of an event while changing viewpoints via media streams coming from different locations at the same event. Although the processes are described with reference to synchronisation, it will be appreciated that processes required as precursors to this synchronisation process may also be used.

At S4-1 the Streaming Server 7 may comprise a store of all the previous media streams which have been live streamed from the Transmission Modules 5 into corresponding media stream formats. Associated URLs for each media stream may have previously been stored the Database at S4-2 to facilitate the Viewer 14 function at S4-3 of selecting different media streams to view.

At S4-3 a process may be invoked (typically via JS or other web programming language) by the Viewer 14 via the viewing interface 13 to select an alternate media stream and its associated data for viewing. At this point the request to view an alternate media stream is sent to the Web Server 10 at S4-4 which saves the current timecode value (alternately the current playtime from start of media value) and retrieves the next media stream URL from the Database 9 at S4-5.

The next media stream URL is then accessed from the Streaming Server 7 or other media streaming storage attached to the control server 8 at S4-6 and before it is displayed, a JavaScript (or other programming construct) seeks the saved timecode or playback time within the new media stream.

At S4-7 the Viewer 14 watches the new media stream on the viewing interface 13 starting from the same time as when the request to switch streams was made. The process of switching between media streams could take time so there is an additional process invoked at S4-7 to measure this time and add it to the time that the new media starts from so as to maintain real-time synchronisation.

At S4-7 a background process is also deployed to check the time code or playback time such that if one of the videos being concurrently played stutters or pauses due to network congestion or other performance-related issues then its playback time will be adjusted within configurable parameters stored in the Database 9.

Playback time may be adjusted via web programming languages such as JavaScript as will be appreciated. The media may be stored and can includes all media tracks such as video, audio, data, and timecode.

Figure 5 shows an example process of an artificial intelligence (Al) based object tracking process for synchronized live media and/or video on demand (VOD).

In this example an administrator initiates a live stream process as illustrated by steps S5-1 through S5-5 which are similar in operation to S4-1 to S4-5 described in relation to the example of Figure 4.

At S5-6 an Al based object recognition processes is configured to run along with Machine Learning (ML) processes that are trained to recognize specific objects such as race cars within a video stream or frame. The object tracking process may be configured to output object tracking co-ordinates as a form of data, the co-ordinates relating to the location of the specific objects being tracked within the video. Electronics within the transmission module 5 may be optimized for Al and ML based object tracking within video. In various examples, the transmission module 5 may be implemented in suitable cloud-based repositories which may mirror Al and ML capabilities of a physical transmission module 5. The use of Al I ML based object tracking and recognition in this way may enable the promulgation of multiple live and VOD media streams that retain such object tracking information as part of the media stream, such that a viewer can follow an object without the viewing device itself requiring the level of performance required for Al / ML object recognition.

At S5-7 multiple transmission modules 5 each connected to cameras 2 and Data Sources 3 can send media streams incorporating video, audio, timecode, data, and AI/ML based object tracking co-ordinates as data. This means that all such elements of the media stream, including the object tracking co-ordinates, can be synchronized in time as being part of the same media stream.

These streams can then be transmitted over the Network 6 to the Streaming Server 7, with the URLs of these being recorded in the database 9. The media streams URLs are passed to the viewing interface 13 from the database 9 at S5-11 where the viewer 14 may select an object of interest to track from list of tracked objects through a Ul menu presented via the webserver 10 to the viewing interface 13.

At S5-12 the web server may 10 use a web programming script such as JavaScript to retrieve the object tracking co-ordinates data from the media stream. At S5-13 additional web programming script may generate GFX overlays for other data within the video stream such as ECU data and object tracking co-ordinates data, which are displayed at S5-14 according to viewer selections at S5-11 for viewing at S5-15 in at the viewing interface.

Figure 6 shows an example process relating to the choice of commentary between concurrent media streams.

In this example, steps S6-1 through S6-3 are similar to those occur as in the examples discussed in Figures 4 and 5, i.e. S4-1 through S4-3, and S5-1 through S5-3.

At step S6-4 video streams are received from an Outside Broadcast Truck (OB) in the form of broadcast feeds. OB trucks will be appreciated as a system for processing and transmitting live on-air broadcasts e.g. in sporting events. Typically, OB trucks will output/transmit a number of different broadcast feeds either as different camera views or different live compilations of audio commentary with a variety of live switched camera and graphics feeds. For example, some of these broadcast feeds may be in different languages or be from commentators with different styles of delivery. The broadcast feeds may be considered as live television streams.

In this example the or each transmission module 5 may have one or more purpose-built interfaces. The purpose-built video interfaces may be a professional video interface, such as SDI, as will be appreciated. The purpose-built video interfaces may be any of a number of different professional broadcast standards, or may use consumer grade interfaces such as HDMI for lower-cost productions such as school cricket matches etc.

The broadcast feeds may be input to standard broadcast IP converters (not shown) which convert professional video feeds e.g. from SDI to RTSP Network video transport protocol. In some examples, one or more of the transmission modules 5 may be located in a Cloud Computing service. These transmission modules 5 may be connected via a VPN enabled router (not shown) such that the router and associated broadcast feed(s) appear as local network connections to the Cloud-based service. This enables such broadcast feeds to be transmitted using standard video and networking components which OB truck operators are familiar with.

The process of this example allows for the provision of multiple different broadcast feeds that the viewer can select to view at the viewing interface either as a Picture-In-Picture (PIP) view to add context in various languages and styles, or to be used for main picture content e.g. a jockey cam in Horse racing.

At step S6-5 local timecode may be added to the broadcast stream to unify the source of timecode for all video inputs. The local timecode added may be derived from a real-time clock (not shown) in a transmission module 5 (both local and Cloud-based versions). Each transmission module 5 may have a real-time clock (RTC) synchronized via network time protocols (NTP) to master clocks. This may allow real-time synchronization of a number of video sources for live and VOD media streaming as previously described.

At step S6-6 multiple transmission modules may transmit broadcast feeds/media streams including time code via the network 6 at step S6-7. These broadcast feeds/media streams are then received at S6-8 in the media streaming server 7 which encodes the media streams. The encoding may be such as for example, HLS manifests.

At step S6-10 the media stream URLs are stored in the database 9. At step S6-11 a viewer may view on the viewing device a main media stream with the broadcast stream as a PIP overlay. The audio of both media streams are mixed with III functions allowing the viewer to choose the relative sound levels of the main media stream and the broadcast stream provided as PIP.

At step S6-11 viewer can choose via the viewing interface a different broadcast stream representing an alternate language or different presentation type commentary. Also at S6-11 the viewer can select via the viewing interface a main media stream to be a broadcast media stream.

At step S6-12 the web server 10 may use a web programming language to save or transmit the time code of the presently viewed media stream at the specific time of selection of a second broadcast media stream which the user wants to switch to. This timecode may be saved at the database or within the web server. The web server 10 may then query the database 9 for the URL of the second broadcast media stream and at step S6-13 the web server 10 may retrieve the second broadcast media stream URL from the database 9.

At step S6-14 the web server 10 may receive the second broadcast media stream URL, incorporates it into the viewer interface. The web server then retrieves or accesses the time code of the presently viewed media stream at the specific time of selection and displays the selected second broadcast media stream as PIP or main video depending on the viewer selection via the viewing interface. As a result of the time code of the previously viewed media stream at the specific time of selection, the second broadcast media stream which is shown can then be synchronised with the previously viewed media stream. At S6-15 viewer can then view the media streams they have selected which are synchronized in time, providing a seamless viewing transition between the change of streams.

Figure 7 shows an example of a process for viewer created commentary using the processes and system previously discussed.

In this example, a viewer may be viewing a multi-stream through a process and system previously described, and may have selected a broadcast commentary, which may be shown as PIP.

At step S7-1 the viewer may select or input a command on the viewing interface to enter a viewer commentary mode. At step S7-2 the web server may receive the command from the viewing interface and may log a status relating to the command that the viewer has entered or has requested to enter a viewer commentary mode. At step S7-3 the web server may enable a microphone, or a microphone and camera associated with or operatively connected to the viewer interface to begin transmission of audio data or audio and video data from the microphone/camera to the web server.

At step S7-4 the viewer enters viewer commentary mode. The viewer is able to view one or more media streams as previously described via the viewing interface, while providing to the media streaming server via the web server a stream of their own commentary (just audio, or audio and video). In the viewer commentary mode, the viewer can view live media streams as previously discussed in other examples, along with any background sounds the media streams selected have available, as they provide their own commentary, which is uploaded to the web server.

At step S7-5 the web server can produce one or more viewer commentary stream(s), which are transmitted to the streaming server 7 via the network 6.

At S7-6 the streaming server 7 may receive the viewer commentary stream(s) from the web sever 10 via the network 6 and can store the viewer commentary stream(s).

At step S7-7 the viewer may complete and finalize their commentary using the commands and/or inputs of the viewer interface, causing the web server 10 to send a stop command to streaming server 7 at step S7-8.

At step S7-9 the streaming server 7 may finalise the viewer commentary stream(s) and transmit the viewer commentary stream(s) URLs to database 9 at S7-10.

At step S7-11 another viewer may select the viewer commentary stream(s) via their viewer interface and can then proceed to view the selected viewer commentary stream(s) alongside other media streams, which are synchronised as previously discussed.

At step S7-13 the streaming server 7 may transmit the selected viewer commentary stream(s) to the web server 10 at S7-14 via the network 6 where the web server then renders playback of the viewer commentary stream(s) at S7-11 .

Figure 8 shows an example of a process for implementing digital video effects (DVE) for synchronized live media and/or video on demand (VOD). In this example process, a live stream may be initiated as previously described, and as illustrated by steps S8-1 through S8-10 which are similar in operation to S5-1 to S5-10 in the example discussed in relation to Figure 5.

At step S8-11 the viewer may select an object of interest to track from a menu presented via viewing interface and generated by the web server 10. Alternately a “shotbox” can be created (not shown) where a starting point for a field of view is selected by the viewer via the viewing interface. A “keyframe” may also be set via the viewing interface using a Pan-Scan- Zoom using an input to the viewing interface such as a joystick.

A period of time may then be selected by the viewer using the viewing interface with a second “shotbox” or field of view and a second “keyframe”. This process is well known to broadcast DVE devices.

The present example however utilised the manipulation of a field of view into 360 video space and then determining start and end keyframes for the shotbox sequence in the 360 video space. This provides the ability for a DVE operator to trigger a sequence, for example using a 360 camera mounted at the apex of a hairpin corner close to the track where health and safety regulations prevent a camera person operator from operating a camera in such positions. The DVE operator can then trigger the shotbox to follow a car around the corner. The high speeds of motor race cars are too fast for this type of action to be performed by a conventional remote PTZ camera.

In an alternative example, a preset Object Tracking can be invoked using Al object recognition. In such examples, the or each transmission module 5 may contain electronics capable of tracking one or more objects at a time in real-time within a video stream. This may generate object motion data relating to the tracking of the or each object within the video stream. This example may combine the object motion data with the video stream at step S8-6 in such a way that at steps S8-11 and S8-15 views can be automatically generated within a 360 video stream which tracks specific, and optionally selected, objects within the video stream with fast and seamless object tracking.

At step S8-12 the web server 10 may retrieve the object motion data from the media stream and at step S8-13 the web server may generate one or more graphical overlays for displaying senor data and/or ECU data and/or the object motion data, which are displayed at step S8-14 via the viewing interface according to viewer selections at step S8-11 for viewing at step S8-15 by the viewer. This process may combine high quality colour depth output from a DVE device which is a purpose-built electronic workstation incorporating high performance I/O with a custom software deployment within the web server 10 functionality in a machine-language compiled deployment to achieve high frame rate high quality multiple video outputs of professional broadcast quality. This may provide opportunities for on-site broadcasters to incorporate new and exciting footage previously not possible with traditional broadcast equipment.

In essence this is a development of a viewer’s experience similar to that as described in relation to Figure 5, with added functionality based on presets as in “shotbox” setups as well as live and VOD object tracking providing innovative new special effects for broadcasters

Further and additional examples will now be described. It will be appreciated that these example may relate to any one or more of the previous examples described.

Various examples are implemented as computing systems configured to carry out steps of processes recited or described and illustrated above.

Various examples are implemented as computing systems configured to provide network entities and/or network components recited or described and illustrated above.

Examples may be implemented as computer readable instructions stored on a computer readable medium.

Various examples are implemented as a software product operable when run to cause a computer system to carry out steps of processes recited or described and illustrated above.

Various examples are implemented as a software product operable when run to cause a computer system to provide network entities and/or network components recited or described and illustrated above. In various examples the controller sends a command to the transmission modules in the network to commence data capture. The controller may transmit a command to the transmission modules in the network to commence a time code for data capture. The controller may transmit a command to the transmission modules in the network to coordinate a time code for data capture. The controller may transmit a command to the transmission modules in the network to synchorise a time code for data capture.

In some examples the Transmission modules control cameras to commence capturing video data and or control other data capture devices to capture other data. The transmission modules may commence reading time data which allows video frames in the captured video to be related in time to the start of the data capture.

An ECU or an “engine control unit” is an example of an external device which communicates a continuously changing data set to the Transmission Module. In such examples, the Transmission Module includes this in the media stream as an additional data in the media stream. ECU functions are documented elsewhere, for example httDs://en.wikiDedia.ora/wiki/Engine control unit.

Various examples provide a system that removes the operational complexity, bottlenecks, and technical configuration issues that any organisation typically faces when faced with a requirement to live stream and play on demand multiple 360 streams from cameras where there are aggressive production schedules.

Typically, to stream a live 360^e camera, a smartphone is used running a consumer app produced by the camera manufacturer. This approach lacks the ability to transmit additional data that may be available from the camera location.

In professional streaming applications there are purpose-built methods of synchronising playback of VOD for multiple standard video including HD and 4K - but there are no such systems available for multi or low-cost small consumer HD, UHD etc cameras and resulting streams. This is because the consumer cameras small enough and light enough to be used for portable mobile live streaming or recording do not have professional camera capabilities such as synchronised or linked timecode generation. Additionally in some embodiments 360 cameras small enough to be reasonably used on mobile elements such as athletes, vehicles, or animals (for example) do not have professional remote-control of settings such as synchronised timecode generation. The result is that normal professional video production equipment, knowledge, and capabilities arenot able to engineer a solution for VOD synchronised playback from portable consumer cameras with available equipment that is also portable. Each Transmission Module 5 may have a small, lightweight physical form, and may include wireless communication capabilities, and may be battery-powered from batteries within its enclosure or externally connected via a power plug.

Traditional live streaming platforms such as YouTube and Vimeo only cater for one stream at a time and do not therefore have any ability nor need to synchronise playback of different streams.

There are some existing systems that enable remote configuration of video streaming devices (e.g. AWS Elemental MediaLive) but there is no mechanism for starting the streams at the same time, nor for setting up unified timecode generation in these devices; furthermore all such available devices are engineered for standard/HD/UHD video, not for 360 video.

When a live event concludes, , there is typically a delay of sometimes several hours before viewers have the opportunity to watch a replay. This is mostly due to manual postprocessing processes to allow the VOD playback of multiple streams to be synchronised. This manual stream synchronization is a highly skilled process requiring the services and related specialist equipment to unify and align all media streams to a common time code or start point. The system described incorporates an automated process of synchronizing all streams in an event such that the VOD synchronsied multi-stream playback can be available to viewers within minutes of the live event completion.

Multi-stream events typically have no context data shown or available; while watching a particular stream there is no avenue to understand what may be happening within the view of another camera or stream. In examples, a synchronised Picture-In-Picture (PIP) view of the event broadcast commentary may be provided at a viewing interface 13. The soundtrack of the PIP may play continuously as a viewer switches between different views or streams. Thus providing guidance of which cameras provide views of current incidents for example.

In an alternate example different commentary PIP videos and associated sound can be selected based on viewer preferences such as language or commentator reputation or style.

Telematic data local to the video source is typically transmitted via a separate transfer process which while the event is live appears synchronised - but when replayed after the event this is typically not synchronised and requires the event operator organisation to engage in time and cost consuming post-production activities involving specialist equipment, software, and operators. Furthermore the industry standard for telematic data falls in line with traditional broadcasting methodology, that is the event producer determines the view including any telematics and that is edited into the video that the viewer sees: the viewer has no choice in what telematics or commentary to view.

Various examples solve this by attaching the telematic data as an additional component within the media stream so that such data is recorded in a time-synchronised manner along with the video, audio, and timecode within the media stream. This allows for the extraction of the data as the video is playing and Render a visual interpretation of that data as an overlay on top of the video, based on viewer selection actions within the Viewer interface 13.

Various examples provide a method of solving these commercial production issues with a complete system that automates every step of the process so that once a camera 2 and corresponding Transmission Module 5 are installed (e.g. in a race car), the Transmission Module automatically registers the camera 2 through cellular connection with the Remote Control Server 8. The Admin user can then drag the registered Transmission Module 5 and camera 2 combination onto a driver name and adjusts other camera feeds in the same way while creating a WYSIWYG design of the viewer web page 13. The camera feed urls can be automatically configured and may not need any manual typing or copy/paste process. The Admin Operator via the Admin Interface clicks a single “go Live” interface element which issues an instruction to the Control Module which in turn tells all the Transmission Modules to start streaming at the same time. In various embodiments a Control Module provided at the administrator interface communicates with each Transmission Module at a system level. Because all the streams start and finish at the same time they all start playing back at the same time when viewed as a VOD playback. An interrupted stream will show a black image or an automatically interred still or video loop until transmission resumes.

A PIP stream of some examples provides context and increases viewer engagement thus solving a major drawback to multi-stream events.

Telematic data overlays generated in real time from a special video data stream inserted at time of live streaming allows visual interpretation of complex data to be displayed at the viewer device and for that data to be synchronised in time with the video and audio components. Further, there could be several different telematic elements which viewers can individually select according to their preference. For example, on viewer may be especially interested in the speed of the car while another may wish to see the braking effort and which gear the car is in, and how many revs it is running at.

Specific elements of video (live or VOD) Synchronisation will now be described.

In various examples, distinct demand access data can be used to access video-on-demand for distinct video-on-demand media streams. For example a first demand access data may provide access to a first media stream which carries information on video captured at a camera associated with a first transmission module. This media stream may be a video on demand stream. A second demand access data may provide access to a second media stream which carries information on video captured at a camera associated with a second transmission module. For example, a camera associated with the first transmission module may be mounted on a first car competing in race event and a camera associated with the second transmission module may be mounted on a second car in the same race event. A Web server combining a viewer interface viewed by a given viewer may access the first media stream using the first access data and may access the second media stream using the second access data in response to a request by the viewer at the viewer web interface to switch media streams to be displayed at the viewer interface. For example, a viewer may make and input at a control on the viewer interface to switch between cameras mounted on different cars. In one example, the transmission modules may have a network time based synchronisation for their built-in time-of-day clocks accurate to within a frame of video (such as, but not limited to 1 /30^th sec) or better. This time-of-day in milliseconds would be embedded into the video stream coming from each transmission box, thus generating synchronised time-codes for all of the multi-stream videos. The multi-stream Player then synchronises the streams based on the embedded timecode.

In another example, all the transmission modules may start streaming at the same time via a group remote network API (application programming interface) call originated from the Command and Control module 8. Thus when the VOD multi stream Player starts playing the streams, they can all be in sync and if further synchronisation is required (for example because of slow network transmission) the time to re-sync lagging videos to is chosen from the video stream with the highest playback time from start so that all streams are re-synced to the current best playing video.

In a further example, the Multi stream Player might experience loss of transmission or slow transmission of one or more streams in some circumstances, while other video streams may continue to play smoothly without interruption. This can cause a lack of synchronization between these streams. In these examples, the multi-stream Player can request a player time sync update to bring the lagging streams up to the same point into synchronisation.

In another example, if the multi stream Player might experience a larger number of re-sync requests due to continued video stream interruptions in some circumstances. In these examples, a message may be shown to the viewer with suggestions as to how to improve the smoothness of multi-360 stream playback. The threshold to determine the number of lost sync events before such a message is shown, may be stored in a config variable provided by the Command and Control Module 8. This number can be adjusted by an Admin user of the Command and Control Module.

Another example may prioritise the PIP commentary TV broadcast to play uninterrupted under slow network conditions. This maintains a real-time context for viewers. Should a video stream the viewer is watching stutter or lose sync due to poor network or other performance issues, the multi player will sense on a regular basis the alignment of either timecode or elapsed playback time using the PIP as a ‘master’ and will adjust the playback time of the lagging video to match the PIP video, thus maintaining sync and effective viewer context.

Specific elements of Telematic Data will now be described.

In an example, a transmission module 5 may accept or receive CANbus data, such as from a car’s on-board computer. Such CANbus data may include (and is not limited to) gear selection, engine revs, throttle setting, brake pressure, tire temperature, engine temperature, oil pressure, hydraulic pressure, hybrid battery store, electric motor additional force, engine power etc. This CANbus data can be parsed into a concise and economical format by the transmission module so as not to require significant transmission bandwidth. The transmission module can then incorporate this parsed data into the live video as data within the media stream (for example this may be as an ID3 format stream of the video).

In another embodiment, the transmission module 5 may accept biometric data via bluetooth or wi-fi sensors attached to a person or animal within or associated with an event. This biometric data can be parsed into a concise and economical format by the transmission module so as not to require significant transmission bandwidth. The transmission module then incorporates this parsed data into the live media stream (for example this may be as an ID3 format track of the video).

In further examples there may be a combination of a variety of different data sources all feeding into a transmission module 5. The data sources may relate to the previously described sensor data, CANbus data, biometric data, or other data. This combination of data received from different data sources may be parsed into a concise and economical format by the transmission module so as not to require significant transmission bandwidth. The transmission module then incorporates this parsed data into the live media stream (for example this may be as an ID3 format track of the video).

The process may comprise a transmission module providing context data carrying information recognisable by a viewer as providing context for the media to be transmitted by the transmission module and/or a camera. The context data may identify an event. The context data may identify an item of apparatus. The context data may identify a position on an item of apparatus. The context data may identify a participant or object (such as car) within an event.

The process may comprise a web server generating data defining a viewer interface which displays media streamed from one or more transmission modules wherein the viewer interface displays context data and displays one or more user controls each associated with context data, receives control inputs at the one or more controls and connects to a media stream in response to control inputs wherein said connection is made to a media stream to which a transmission module providing the context data associated with the given control.

The process may comprise a viewer interface connecting to each of the said media streaming service and said additional media streaming service in response to control inputs made by a user at the viewer interface.

The process may comprise a transmission module providing timecode generated from a network synchronised real-time clock and added to the media at the time of live transmission from the transmission module. The process may also include a live streaming server that records live media streams including all tracks within the video such as video, audio, to name some instances. The process may also include a live stream server that records all tracks attached to the live media even if those tracks are not yet defined.

The process of synchronising the playback of recorded media streams in some examples may not be dependent on any specific elements other than the transmission module being able to add timecode to the media stream such that the timecode originates from a network synchronised real-time clock.

The process may comprise a system of synchronising playback (VOD) and / or live media streams such that if a video currently being watched is then switched to another video by means of viewer controls attached to programmed processes which processes note the timecode of the current video and index the new video at a starting point that matches the timecode of the previous video thus providing a time continuum of watching the same event from a different position but retaining the current time playback continuity. The process of synchronising the playback of recorded media streams in some examples may not be dependent on any specific elements other than the transmission module being able to add a timecode track to the media stream such that the timecode track originates from a network synchronised real-time clock.

The process may provide a method of connecting external data to a transmission module, for example CANbus data from an in-car ECU, re-formatting that data into a concise format and including the data as another track within a live media stream. The process may further provide a method of recording the live media including all the tracks within the live media such as video, audio, data, and timecode etc. Thus the external data may be synchronised in time to the media stream recording. The process allows playback of recorded media including all tracks contained within the recorded media such that data can be extracted in real-time from the media being played. Such extracted data can be rendered visually as an overlaid graphic on top of the media display on a viewing device. The process can provide a mechanism for example with JavaScript or other programming constructs to construct dynamic visual graphic overlays representing the synchronised data to enhance the viewing experience.

The process of synchronising the data element display of media streams in some examples may not be dependent on any specific elements other than the transmission module being able to connect to external devices, receive the data, reformat the data, and add the data as another stream in the media being transmitted, in combination with a method to display such data to the viewer.

The process may provide a method of starting the media streams of a number of transmission modules simultaneously by remote connection, each transmission module having its own camera and associated external data such that these videos when recorded and subsequently played back can be synchronised in time by starting the playback of all the videos at the same time and when switching from one video to another noting the current playback time of the first video and starting the playback of the second video from the first video’s noted playback time before the switch was initiated by the viewer.

The process can also include the capability to display external data recorded as part of recorded videos such the playback of recorded videos and the rendered graphic overlay display of such external data included in the video is synchronised in time with the playback of the video so that events as they occurred at the time of live video delivery are reconstructed in the entirety of information that was available during the live video display and its external data overlays.

The process of synchronising the media streams in some examples may not be dependent on any specific elements other than the transmission module being remotely controlled by a central server which can issue a command to start media stream transmission of a number of transmission modules simultaneously.

Another example of this process may use Mpeg-Dash or another suitable method of allowing adaptive multi-bitrate encoding (ABR) as an alternate media stream and storage mechanism.

Other methods of encoding and playing ABR may become available for use of this system of synchronising playback between multiple media streams.

The described examples allow for a synchronised playback of multiple video streams. Low- cost, small form-factor, consumable cameras do not have any included technology to enable synchronization of multiple cameras. The described processes of adding time code data to the media streams and other alternate methods enables the synchronised playback of multiple live and recorded streams via the streaming network and processes described. This in turn enables commercial live streaming and recorded playback capability for multiple concurrent consumer cameras, which in turn reduces cost and provides greater flexibility for choice of camera equipment particularly relating to small and miniaturized form factors.

The described examples also allow for time-sensitive context data to be recorded and synchronized as part of each video stream. Industry-standard transmission devices for transporting live video over the internet have no mechanism to include time-sensitive context data as an additional track within a video stream. This means that systems wishing to display additional data (such as CANBus data from a race car) must render such data as part of the video being transmitted, removing the choice for the viewer of whether to display such data or not. As such, typically the additional data is transmitted independently and separately rendered in a traditional video editing setting subsequently to be sent on to viewers, once again resulting in lack of control by viewers to view such additional data.

Examples described herein further allow for object tracking data to be added and synchronised with a video stream. Viewers of events such as motor racing recorded via 360 cameras, may wish to change their field of view based on the visibility of an object within the video. The object may be another vehicle, a wheel, a specific vehicle identified with visual markers etc. It is tedious and difficult to follow such motions at high speed using manual controls available from traditional 360 video navigation controls. The media streaming network and processes described herein may allow for use of Al within the network to enable the real-time tracking of objects of interest within 360 space by cartesian or other coordinates of space.

This object-tracking data may be added to video streams as an additional track within the video, such that a viewing device only needs to follow the moving point of interest without complex compute-intensive calculations.

This allows a number of specific advantages: a) because the processing is not performed at the viewing device, these advanced viewing capabilities are available to the broadest audience of ubiquitously available viewing devices e.g. (but not limited to) smartphones and tablets without requiring those devices to be of high performance. This is an important element allowing a much broader reach of viewers, leading to increased fan numbers and engagement. b) Since the object tracking data for viewing angles of tracked objects is included with and synchronised with one or more media streams as data it is synchronized in time to the media of the video stream. This translates to an immediacy of viewer angle changes enabling the tracked object to remain within the field of view even when the action is very fast paced. It also enables such object tracking to be encapsulated in the recorded video streams and therefore sychronised on VOD playback. The tracked object data is recorded into the media stream in such a way that it survives end-to-end through common live streaming services such as (but not limited to) AWS MediaLive. c) It provides a method for the viewer to enable automatic object tracking or not, as they prefer, giving them control over their own viewing experience. Further, there may be a number of different objects being tracked within the same camera view providing even more choice for viewers. d) It provides a method for the viewer to select different objects for tracking within different videos. For example, a viewer watching from car A and tracking car B, switching view to the point of view provided by car B and selecting car A to be the tracked object to view; such that switching between the viewpoints of car A and Car B could automatically switch the car being tracked if the viewer activated the appropriate selections. e) It provides viewer preferences per video being viewed. For example, a viewer watching from the perspective of car A, currently the leader of the race, may prefer to watch from the rear view of car A, viewing the following car (car B) and its attempts to overtake from the perspective of the leading car, car A. In this scenario, the viewer may wish to switch to the perspective of car B and the most interesting view they select might be looking forward to car A, providing a viewer insight into car B’s attempts to overtake car A while also viewing car A’s defensive actions to prevent car B’s overtaking actions. Should the viewer switch back to the car A perspective, the view would be the previously navigated POV looking to the rear of car A. Likewise if the viewer switched to car B’s perspective again the view would be the last watch view e.g. looking forward to car A. This functionality provides for further enhanced viewing experience leading to even greater fan engagement.

Examples described herein also may allow for continuous commentary across concurrently viewed video streams. Typically, there may be different announcers relaying their particular interpretation of unfolding events. These may be in different languages. They may consist of a number of commentators comprising a panel of complementary views. The streaming network and processes described herein allow for a viewer to select which commentary stream to play as a picture-in-picture (PIP) view overlaying the viewers current video choice and providing audio context to unfolding events. For example, a viewer may choose a French commentary even though they may be watching within U.K. (as they may understand French better or may prefer the particular French commentator over other available English commentators). This could also allow a default commentary based on dominant language in particular countries where an appropriate language commentary is available. For example a viewer located in France could be sensed via geo-location web services and the viewer would then have the French commentary and would also have the option of choosing a different language or another French commentary if that was available. Examples described herein also may allow for viewer created commentary. The streaming network and processes described herein may allow a viewer to create and upload their own commentary of a live or VOD event by way of accessing a special mode that live streams the viewer’s voice along with what they are viewing (including all different video selections as enabled in all of the foregoing points). This can optionally be live streamed and recorded in a competition library portal where registered members vote for the best commentary and event organisers have options for prizes based on most popular member’s choice, organiser’s best choice etc. The viewer created commentary of this example could further include video data from a webcam of the viewer as a Picture-In-Picture additional media stream, which would become another media stream associated and synchronized with the viewer’s multi-stream viewing and commentating experience.

Further examples described herein also may allow for Digital Video Effects (DVE) in live 360 video. Typically, broadcasters do not have any way of using live 360 video within their broadcasts - because their broadcasts are not 360. 360 video has a number of special formats that look strange to viewers unless the 360 video is rendered within a virtual 360 globe and a portion of that known as the 360 Field of View (FOV) is rendered in a 2d viewing format. Existing Broadcast equipment does not provide this functionality. The streaming network and processes described provide a method for this through the previously described ability to switch between different 360 streams and choose a FOV within a selected 360 video which is then output using specialized electronic components as a standard SD, HD, UHD (or any other standard 2d video production aspect ratio and resolution) adhering to broadcast production standards for video and audio. Combining this with standard “shot-box” and keyframed transition capabilities normally used for post production, broadcasters can add previously unattainable footage to their productions.

Further, Al can add significant functionality for Broadcasters to use 360 video footage in their live and post-produced productions. For example, a 360 camera could be placed in a location ruled as too dangerous for a camera operator e.g. (but not limited to) at the apex of a hairpin corner in a F1 race. Using object tracking such as that described previously, a 360DVE operator could select to follow a specific car around the hairpin in real-time and add that clip to their live broadcast. Further mechanisms are deployed to allow forewarning of an upcoming clip of this nature, such forewarning may be triggered by a camera on the approaches to the hairpin also recognizing the same car. This may allow for many opportunities for unique camera angles and auto-tracking sequences exist for such a system. Terminology and definitions

The phrases 'computer-readable medium' or ‘machine-readable medium’ as used in this specification and claims should be taken to include, unless the context suggests otherwise, a single medium or multiple media. Examples of multiple media include a centralised or distributed database and/or associated caches. These multiple media store the one or more sets of computer executable instructions. The phrases 'computer-readable medium' or ‘machine-readable medium’ should also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by a processor of a computing device and that cause the processor to perform any one or more of the methods described herein. The computer-readable medium is also capable of storing, encoding or carrying data structures used by or associated with these sets of instructions. The phrases 'computer-readable medium' and ‘machine readable medium’ include, but are not limited to, portable to fixed storage devices, solid-state memories, optical media or optical storage devices, magnetic media, and/or various other mediums capable of storing, containing or carrying instruction(s) and/or data. The ‘computer-readable medium’ or ‘machine-readable medium’ may be non-transitory.

The term ‘comprising’ as used in this specification and claims means ‘consisting at least in part of’ or ‘including, but not limited to’ such that it is to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense. When interpreting each statement in this specification and claims that includes the term “comprising”, features other than that or those prefaced by the term may also be present. Related terms such as “comprise” and “comprises” are to be interpreted in the same manner.

It is intended that reference to a range of numbers disclosed herein (for example, 1 to 10) also incorporates reference to all rational numbers within that range (for example, 1 , 1 .1 , 2, 3, 3.9, 4, 5, 6, 6.5, 7, 8, 9 and 10) and also any range of rational numbers within that range (for example, 2 to 8, 1 .5 to 5.5 and 3.1 to 4.7) and, therefore, all sub-ranges of all ranges expressly disclosed herein are hereby expressly disclosed. These are only examples of what is specifically intended and all possible combinations of numerical values between the lowest value and the highest value enumerated are to be considered to be expressly stated in this application in a similar manner.

The term ‘and/or’ means ‘and’ or ‘or’, or both.

The use of ‘(s)’ following a noun means the plural and/or singular forms of the noun. Conditional language, such as “can,” “could,” “might,” or “may,” unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements, and/or steps. Thus, such conditional language is not generally intended to imply that features, elements, and/or steps are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without user input or prompting, whether these features, elements, and/or steps are included or are to be performed in any particular embodiment.

Language of degree used herein, such as the terms “approximately,” “about,” “generally,” and “substantially” as used herein represent a value, amount, or characteristic close to the stated value, amount, or characteristic that still performs a desired function or achieves a desired result. For example, the terms “approximately”, “about”, “generally,” and “substantially” may refer to an amount that is within less than 10% of, within less than 5% of, within less than 1% of, within less than 0.1% of, and within less than 0.01% of the stated amount.

In this specification where reference has been made to patent specifications, other external documents, or other sources of information, this is generally for the purpose of providing a context for discussing the features of the invention. Unless specifically stated otherwise, reference to such external documents is not to be construed as an admission that such documents, or such sources of information, in any jurisdiction, are prior art, or form part of the common general knowledge in the art.

In the above description, specific details are given to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, software modules, functions, circuits, etc., may be shown in block diagrams in order not to obscure the embodiments in unnecessary detail. In other instances, well-known modules, structures and techniques may not be shown in detail in order not to obscure the embodiments.

Also, it is noted that the embodiments may be described as a process that is depicted as a flowchart, a flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be rearranged. A process is terminated when its operations are completed. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc., in a computer program. When a process corresponds to a function, its termination corresponds to a return of the function to the calling function or a main function.

Aspects of the systems and methods described above may be operable on any type of general purpose computer system or computing device, including, but not limited to, a desktop, laptop, notebook, tablet, smart television, gaming console, or mobile device. The term "mobile device" includes, but is not limited to, a wireless device, a mobile phone, a smart phone, a mobile communication device, a user communication device, personal digital assistant, mobile hand-held computer, a laptop computer, wearable electronic devices such as smart watches and head-mounted devices, an electronic book reader and reading devices capable of reading electronic contents and/or other types of mobile devices typically carried by individuals and/or having some form of communication capabilities (e.g., wireless, infrared, short-range radio, cellular etc.).

Aspects of the systems and methods described above may be operable or implemented on any type of specific-purpose or special computer, or any machine or computer or server or electronic device with a microprocessor, processor, microcontroller, programmable controller, or the like, or a cloud-based platform or other network of processors and/or servers, whether local or remote, or any combination of such devices.

Furthermore, embodiments may be implemented by hardware, software, firmware, middleware, microcode, or any combination thereof. When implemented in software, firmware, middleware or microcode, the program code or code segments to perform the necessary tasks may be stored in a machine-readable medium such as a storage medium or other storage(s). A processor may perform the necessary tasks. A code segment may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.

In the above description, a storage medium may represent one or more devices for storing data, including read-only memory (ROM), random access memory (RAM), magnetic disk storage mediums, optical storage mediums, flash memory devices and/or other machine or computer readable mediums for storing information. The various illustrative logical blocks, modules, circuits, elements, and/or components described in connection with the examples disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic component, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, circuit, and/or state machine. A processor may also be implemented as a combination of computing components, e.g., a combination of a DSP and a microprocessor, a number of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

The methods or algorithms described in connection with the examples disclosed herein may be embodied directly in hardware, in a software module executable by a processor, or in a combination of both, in the form of processing unit, programming instructions, or other directions, and may be contained in a single device or distributed across multiple devices. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD- ROM, or any other form of storage medium known in the art. A storage medium may be coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor.

One or more of the components and functions illustrated the figures may be rearranged and/or combined into a single component or embodied in several components without departing from the scope of the disclosure. Additional elements or components may also be added without departing from the scope of the disclosure. Additionally, the features described herein may be implemented in software, hardware, as a business method, and/or combination thereof.

In its various aspects, embodiments of the disclosure can be embodied in a computer- implemented process, a machine (such as an electronic device, or a general purpose computer or other device that provides a platform on which computer programs can be executed), processes performed by these machines, or an article of manufacture. Such articles can include a computer program product or digital information product in which a computer readable storage medium containing computer program instructions or computer readable data stored thereon, and processes and machines that create and use these articles of manufacture.

Although this disclosure has been described in the context of certain embodiments and examples, it will be understood by those skilled in the art that the disclosure extends beyond the specifically disclosed embodiments to other alternative embodiments and/or uses and obvious modifications and equivalents thereof. In addition, while several variations of the embodiments of the disclosure have been shown and described in detail, other modifications, which are within the scope of this disclosure, will be readily apparent to those of skill in the art. It is also contemplated that various combinations or sub-combinations of the specific features and aspects of the embodiments may be made and still fall within the scope of the disclosure. For example, features described above in connection with one embodiment can be used with a different embodiment described herein and the combination still fall within the scope of the disclosure. It should be understood that various features and aspects of the disclosed embodiments can be combined with, or substituted for, one another in order to form varying modes of the embodiments of the disclosure. Thus, it is intended that the scope of the disclosure herein should not be limited by the particular embodiments described above. Accordingly, unless otherwise stated, or unless clearly incompatible, each embodiment of this disclosure may comprise, additional to its essential features described herein, one or more features as described herein from each other embodiment of the invention disclosed herein.

This disclosure may also be said broadly to consist in the parts, elements and features referred to or indicated in this disclosure, individually or collectively, and any or all combinations of any two or more said parts, elements or features, and where specific integers are mentioned herein which have known equivalents in the art to which this disclosure relates, such known equivalents are deemed to be incorporated herein as if individually set forth.

Features, materials, characteristics, or groups described in conjunction with a particular aspect, embodiment, or example are to be understood to be applicable to any other aspect, embodiment or example described in this section or elsewhere in this specification unless incompatible therewith. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive. The protection is not restricted to the details of any foregoing embodiments. The protection extends to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the steps of any method or process so disclosed.

Furthermore, certain features that are described in this disclosure in the context of separate implementations can also be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation can also be implemented in multiple implementations separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations, one or more features from a claimed combination can, in some cases, be excised from the combination, and the combination may be claimed as a subcombination or variation of a subcombination.

Moreover, while operations may be depicted in the drawings or described in the specification in a particular order, such operations need not be performed in the particular order shown or in sequential order, or that all operations be performed, to achieve desirable results. Other operations that are not depicted or described can be incorporated in the example methods and processes. For example, one or more additional operations can be performed before, after, simultaneously, or between any of the described operations. Further, the operations may be rearranged or reordered in other implementations. Those skilled in the art will appreciate that in some embodiments, the actual steps taken in the processes illustrated and/or disclosed may differ from those shown in the figures. Depending on the embodiment, certain of the steps described above may be removed, others may be added. Furthermore, the features and attributes of the specific embodiments disclosed above may be combined in different ways to form additional embodiments, all of which fall within the scope of the present disclosure. Also, the separation of various system components in the implementations described above should not be understood as requiring such separation in all implementations, and it should be understood that the described components and systems can generally be integrated together in a single product or packaged into multiple products.

For purposes of this disclosure, certain aspects, advantages, and novel features are described herein. Not necessarily all such advantages may be achieved in accordance with any particular embodiment. Thus, for example, those skilled in the art will recognize that the disclosure may be embodied or carried out in a manner that achieves one advantage or a group of advantages as taught herein without necessarily achieving other advantages as may be taught or suggested herein. The scope of the present disclosure is not intended to be limited by the specific disclosures of embodiments in this section or elsewhere in this specification, and may be defined by claims as presented in this section or elsewhere in this specification or as presented in the future. The language of the claims is to be interpreted broadly based on the language employed in the claims and not limited to the examples described in the present specification or during the prosecution of the application, which examples are to be construed as nonexclusive.

Claims

1 . A process for displaying synchronized media streams, the process comprising: receiving at a first transmission module a first set of media data, and at least a first external data; generating a first media stream comprising at least the first set of media data, the first external data and timecode data; receiving at a second transmission module a second media stream, and at least a second external data; generating a second media stream comprising at least the second set of media data, the second external data and timecode data; transmitting the first media stream and the second media stream to a streaming server; accessing the media streams from the streaming server at a web server; and generating a viewing interface at the web server, the viewing interface for displaying the media streams to a viewer; wherein the media streams are configured to be synchronized based on the timecode data, allowing synchronized playback of the media streams at the viewing interface.

2. The process as claimed in claim 1 , wherein the playback of media streams comprises playback of media data and external data concurrently at the viewing interface.

3. The process as claimed in claim 2, wherein the external data is configured to be overlaid on the media data at the viewing interface.

4. The process as claimed in any one of the preceding claims, wherein the viewing interface is configured to allow selection between different media streams to be displayed at the viewing interface using user inputs. The process as claimed in claim 4, wherein the selection at the viewing interface is configured to switch between the first and second media streams displayed at the viewing interface. The process as claimed in claim 4 or claim 5, wherein the synchronization of the media streams is such that the moment in time of the next media stream selected for viewing matches the time of the previously selected media stream viewed to provide a continuous playback of an event while changing media streams. The process as claimed in any one of the preceding claims, wherein the viewing interface is operable to connect to multiple streaming services provided by the streaming server and is operable to display and/or allow a viewer to select streams from a candidate set of media streams. The process as claimed in any one of the preceding claims, wherein the viewing interface allows a selection between different synchronized audio streams, the audio streams optionally representing different commentary streams received as media data at one or more transmission modules. The process as claimed in any one of the preceding claims, wherein the timecode may be time data derived from a real-time clock in a transmission module. The process as claimed in any one of the preceding claims, wherein the external data comprises sensor data and/or telematic data and/or CANbus data. The process as claimed in any one of the preceding claims, wherein a media stream further comprises context data received at or provided by a transmission module. The process as claimed in any one of the preceding claims, wherein the media data is received from a camera in operative communication with a transmission module. The process as claimed in any preceding claim, wherein the step of generating a media stream comprises the following steps: demultiplexing video data and audio data within the media data received, adding the external data and timecode data, remultiplexing the combined video, audio, external data, and timecode data; and optionally compressing the remultiplexed media stream. The process as claimed in any one of the preceding claims, wherein the step of generating a media stream further comprises recognizing specific objects within media data using one or more object recognition processes. The process as claimed in claim 14, wherein the one or more object recognition processes may be configured to output object tracking co-ordinate data, the coordinates relating to the location of the specific objects being tracked within the video, wherein the generated media stream further comprises the object tracking coordinate data. The process as claimed in claim 15, wherein the viewer may select an object of interest to track from a menu presented via the viewing interface and generated by the web server, based on the object tracking co-ordinate data. The process as claimed in any one of the preceding claims, wherein the process further comprises transmitting audio data or audio and video data from a microphone and/or camera associated with or operatively connected to the viewing interface to the web server. The process as claimed in claim 17, wherein the process further comprises generating a further media stream comprising the audio data or audio and video data from the microphone and/or camera associated with or operatively connected to the viewing interface. A media streaming system for displaying synchronized media streams, the media streaming system comprising: a plurality of capture devices configured to capture or generate media data; a plurality of external devices configured to capture or external data; a plurality of transmission modules each in operative communication with one or more capture devices and one or more external devices, and configured to receive media data from the one or more capture devices and external data from the one or more external devices; wherein each transmission module is configured to generate a media stream comprising at least media data, external data and timecode data; a streaming server comprising at least a database and configured to receive media streams from the plurality of transmission modules and provide or allow access to the media streams; and a web server configured to access or receive the media streams from the streaming server, and generate one or more viewing interfaces for viewing the media streams; wherein the media streams are configured to be synchronized based on the timecode data allowing synchronized playback of the media streams at the one or more viewing interfaces. The media streaming system as claimed in claim 19, wherein each transmission module is configured to control one or more capture devices to commence receiving media data or to cease receiving media data. The media streaming system as claimed in claim 19 or claim 20, wherein the system further comprises a control server configured to register each transmission module, allowing the transmission module to transmit media streams to the streaming server. The media streaming system as claimed in any one of claims 19 to 21 , wherein the playback of media streams comprises playback of media data and external data concurrently at the viewing interface. The media streaming system as claimed in claim 22, wherein the external data is configured to be overlaid on the media data at the viewing interface. The media streaming system as claimed in any one of claims 19 to 23, wherein the viewing interface is configured to allow selection between different media streams to be displayed at the viewing interface using user inputs. The media streaming system as claimed in claim 24, wherein the selection at the viewing interface is configured to switch between the first and second media streams displayed at the viewing interface. The media streaming system as claimed in claim 24 or claim 25, wherein the synchronization of the media streams is such that the moment in time of the next media stream selected for viewing matches the time of the previously selected media stream viewed to provide a continuous playback of an event while changing media streams. The media streaming system as claimed in any one of claims 19 to 26, wherein the viewing interface is operable to connect to multiple streaming services provided by the streaming server and is operable to display and/or allow a viewer to select streams from a candidate set of media streams. The media streaming system as claimed in any one of claims 19 to 27, wherein the viewing interface allows a selection between different synchronized audio streams, the audio streams optionally representing different commentary streams received as media data at one or more transmission modules. The media streaming system as claimed in any one of claims 19 to 28, wherein the timecode may be time data derived from a real-time clock in a transmission module. The media streaming system as claimed in any one of claims 19 to 29, wherein the plurality of external devices comprise one or more sensors and/or one or more ECUs and/or one or more telematic data capture devices, and the external data comprises sensor data and/or telematic data and/or CANbus data. The media streaming system as claimed in any one of claims 19 to 30, wherein a media stream further comprises context data received at or provided by a transmission module. The media streaming system as claimed in any one of claims 19 to 31 , wherein the plurality of capture devices comprises a plurality of cameras configured to generate video data and/or audio data. The media streaming system as claimed in any one of claims 19 to 32, wherein the generation of a media stream comprises: demultiplexing video data and audio data within the media data received, adding the external data and timecode data, remultiplexing the combined video, audio, external data, and timecode data; and optionally compressing the remultiplexed media stream. The media streaming system as claimed in any one of claims 19 to 33, wherein the generation of a media stream further comprises recognizing specific objects within media data using one or more object recognition processes. The media streaming system as claimed in claim 34, wherein the one or more object recognition processes may be configured to output object tracking co-ordinate data, the co-ordinates relating to the location of the specific objects being tracked within the video, wherein the generated media stream further comprises the object tracking co-ordinate data. The media streaming system as claimed in claim 35, wherein the viewer may select an object of interest to track from a menu presented via the viewing interface and generated by the web server, based on the object tracking co-ordinate data. The media streaming system as claimed in any one of claims 19 to 36, wherein the viewing interface is further configured to transmit audio data or audio and video data from a microphone and/or camera associated with or operatively connected to the viewing interface to the web server. The media streaming system as claimed in claim 37, wherein the viewing interface or the web server is configured to generate a further media stream comprising the audio data or audio and video data from the microphone and/or camera associated with or operatively connected to the viewing interface. A media streaming process which provides a display of streamed data, the process comprising: generating a viewing interface; displaying at the viewing interface data generated dependent on a first media stream, the display providing a playback of video captured; reading first time data from the first media stream; receiving a request to switch media streams; in response to the request to switch media streams determining a point in time for the played back video, said point in time determined dependent on the time data read from the first media stream; retrieving a second media stream; reading time data carried in the second media stream; and reading time data within the second media stream, determining a point of time in the second media stream; and displaying at the viewer interface data generated dependent on the second media stream starting at the point in time determined in response to the switch request being received. A media streaming process comprising the steps of: receiving captured data at the transmission module, said captured data received from one or more data capture devices associated with the transmission module; generating media data in response to the start command, the media data suitable to stream over a network, the media data comprising video data carrying information on video captured at one or more data capture devices, the media data further comprising data carrying information provided by an engine control unit (ECU) communicating with the transmission module. A media streaming process comprising the steps of: receiving at a transmission module a start command, the start command carrying information indicating a start event; receiving captured data at the transmission module, said captured data received from one or more data capture devices associated with the transmission module; generating media data, the media data suitable to stream over a network, the media data comprising video data carrying information on video captured at one or more data capture devices, the media data further comprising time data carrying information associated with the transmission module, and/or data captured by a sensor, and/or data relating to a context of the data capture device associated with the transmission module. A process of providing a media steaming display comprising: receiving a first stream of media including a video track [first track], receiving from a server a first stream of media including a sound track [second track], receiving from a server a first stream of media including a data track containing time (timecode) [third track] data, receiving from a server a first stream of media including a second data track containing additional [fourth track] data, extracting time data from the timecode track [third track] of the media stream; displaying at a viewing interface display data rendered dependent on the first media stream, the display data comprising a sequence of frames of video data captured at a first camera, or first set of cameras, displaying at the viewing interface display data rendered dependent on the first media stream, the display data comprising a sequence of frames of sound data captured at a first camera, or first set of cameras, displaying at the viewing interface display data rendered dependent on the first media stream, the display data comprising a sequence of frames of time code data inserted by the transmission module as an additional data track (time code) in the media stream, displaying at the viewing interface display data rendered dependent on the first media stream, the display data comprising a sequence of frames of ECU or other sensor data transmitted to the transmission module and inserted by the transmission module as an additional data track in the media stream, wherein the stream which the display data is rendered dependent on is switched dependent on control input made at a control presented at the viewing interface displaying at the viewer interface data rendered dependent on the second stream of media data. A process of providing a media steaming display comprising: receiving from a server a first stream of media data, receiving from a server a second stream of media data, extracting time data from the first stream of media data; displaying at a viewing interface display data, the display data rendered dependent on the first media stream of media data or the second stream of media data, the display data comprising a sequence of frames of video data captured at a first camera or a sequence of frames of video captured at a second camera, wherein the stream of media data which the display data is rendered dependent on is switched dependent on a control input made at a control presented at the viewing interface displaying at the viewer interface data. A media streaming network operable to provide two or more media streams carrying information on video data captured at cameras, the network comprising two or more modules each operable to communicate with a network to transmit a media stream, each module operable to include in its respective media stream time data which carries information suitable to relate given frames in video data to a start event, the set of module operable to receive a communication over the network indicating the start event.