AU2015202846A1 - A method and system for streaming one or more broadcast events - Google Patents

Abstract

Abstract A METHOD AND SYSTEM FOR STREAMING ONE OR MORE BROADCAST EVENTS A method of generating a manifest 109 for streaming a video on demand (VOD) version of a broadcast event 801 from a pre-determined start point 805 associated with the broadcast event, the method comprising the steps of: (a) receiving a request 301 for a VOD version of a broadcast event, whilst the broadcast event is still being broadcast, wherein the request includes broadcast event identification data; and (b) generating a manifest 311 based on the broadcast event identification data, wherein the manifest includes a pre-determined start point for streaming the VOD version of the broadcast event that is based on a scheduled start time 803 of the broadcast event. Ye 307 L G t IKr t7lrffc ,sr 1309 Calculate event snt -Iarflrf 311 Build1 Verso 3 13 Rros Fig. 3

Description

1 A METHOD AND SYSTEM FOR STREAMING ONE OR MORE BROADCAST EVENTS Technical Field [0001] The present invention relates generally to a method and system for streaming one or more broadcast events. Background [0002] Broadcast content service providers transmit broadcast events according to defined schedules. A broadcast event may be, for example, a television program, a movie, a news program, a sporting event etc. [0003] Each broadcast event, or item, is allocated a scheduled start time (and time slot if of a fixed duration) for the event to be broadcast on its designated channel. For example, the broadcast event may be transmitted via a suitable medium (such as satellite or cable) to a set top box (STB) that is operated by a user subscribed to the broadcast content provided by the service provider. Other devices, such as smartphones, tablet devices, laptops and computers are also able to receive these transmissions to enable a user to view the content on the device. [0004] If the user of a device misses the start of the broadcast event, it is usually the case that the user must wait until that particular event is repeated at a different start time or on a different channel for the user to be able to watch the missed portion of that event. [0005] On some known STBs, it is possible to rewind live broadcast content. However, it is only possible to watch a missed portion of a broadcast event if the STB was a) switched on prior to the start of the broadcast of that event, b) tuned to the channel on which the missed event is being broadcast at the start time the broadcast event was being broadcast and c) set up and had sufficient storage to store all the content of that event from the start of the broadcast until the time the user started to watch the event. Therefore, for example, where the user has missed the beginning of a broadcast event and the STB is either switched off or is tuned to a different channel to the channel on which the broadcast event is being broadcast, it is not possible for the user to utilise this feature to watch the missed portion of the event. [0006] There are known systems that enable users to watch content after that content has finished being broadcast. For example, on certain STBs, users may be able to select to watch previously broadcast events by downloading those events and watching the content via a video 2 on demand (VOD) service. However, to be able to do this, the user must wait until the particular broadcast event they wish to watch has at least finished being broadcast. Further, the user may also be required to wait a further period of time, depending on the applicable playback rights and technology being used to create the video on demand asset, before the broadcast event can be watched via video on demand. Summary [0007] It is an object of the present invention to substantially overcome, or at least ameliorate, one or more disadvantages of existing arrangements, or to at least provide the public with a useful choice. [0008] According to a first aspect of the present disclosure, there is provided a method of generating a manifest for streaming a video on demand (VOD) version of a broadcast event from a pre-determined start point associated with the broadcast event, the method comprising the steps of: (a) receiving a request for a VOD version of a broadcast event, whilst the broadcast event is still being broadcast, wherein the request includes broadcast event identification data; and (b) generating a manifest based on the broadcast event identification data, wherein the manifest includes a pre-determined start point for streaming the VOD version of the broadcast event that is based on a scheduled start time of the broadcast event. [0009] According to a second aspect of the present disclosure, there is provided a method of generating a manifest for streaming a video on demand (VOD) version of a broadcast event from a pre-determined start point associated with the broadcast event, the method comprising the steps of: (a) receiving a request for a VOD version of a broadcast event, wherein the request includes broadcast event identification data; and (b) generating a manifest based on the broadcast event identification data by calculating a starting temporal position for the start of a first data segment of the VOD version of the broadcast event based on start time data, a current time value and a time code of a live media segment, where the live media segment is the latest media segment of the broadcast event that is available for broadcasting. [0010] According to a third aspect of the present disclosure, there is provided a system for generating a manifest for streaming a video on demand (VOD) version of a broadcast event from a pre-determined start point associated with the broadcast event, the system comprising a manifest generator adapted to: (a) receive a request for a VOD version of a broadcast event, whilst the broadcast event is still being broadcast, wherein the request includes broadcast event identification data; and (b) generate a manifest based on the broadcast event identification data, 3 wherein the manifest includes a pre-determined start point for streaming the VOD version of the broadcast event that is based on a scheduled start time of the broadcast event. [0011] According to a fourth aspect of the present disclosure, there is provided a system of generating a manifest for streaming a video on demand (VOD) version of a broadcast event from a pre-determined start point associated with the broadcast event, the system comprising a manifest generator adapted to: (a) receive a request for a VOD version of a broadcast event, wherein the request includes broadcast event identification data; and (b) generate a manifest based on the broadcast event identification data by calculating a starting temporal position for the start of a first data segment of the VOD version of the broadcast event based on start time data, a current time value and a time code of a live media segment, where the live media segment is the latest media segment of the broadcast event that is available for broadcasting. [0012] Other aspects of the invention are also disclosed. Brief Description of the Drawings [0013] At least one embodiment of the present invention will now be described with reference to the drawings and appendices, in which: [0014] Fig. 1 is a system diagram of a process flow in a system according to the present disclosure; [0015] Fig. 2 is a high level overview of a smooth streaming file structure for use in the method and system of the present disclosure; [0016] Fig. 3 is a flow diagram of a process for generating a manifest according to the present disclosure; [0017] Fig. 4 is a further flow diagram of a process for generating a manifest according to the present disclosure; [0018] Fig. 5 is a flow diagram of a process for requesting a streamed version of a broadcast event according to the present disclosure; [0019] Fig. 6 is a flow diagram of a process for generating a manifest and obtaining a streamed version of a broadcast event according to the present disclosure; 4 [0020] Fig. 7 is a flow diagram of a caching process for use in the method and system of the present disclosure; [0021] Figs. 8A and 8B are temporal diagrams of content being accessed according to various methods described in the present disclosure. Detailed Description [0022] Where reference is made in any one or more of the accompanying drawings to steps and/or features, which have the same reference numerals, those steps and/or features have for the purposes of this description the same function(s) or operation(s), unless the contrary intention appears. [0023] A method and system are described herein which enable a user using a content playing device to start receiving and watching a broadcast event from the beginning of that event using a live simulcast Adaptive Streaming protocol, even after the user has joined (i.e. tuned a STB or DVR (Digital Video Recorder) to the channel upon which the content is being broadcast) a TV broadcast part-way through the broadcast event or after completion of the broadcast event. A streamed VOD version of the broadcast event in the form of a StartOver broadcast event is provided to the content playing device. [0024] The StartOver broadcast event is a live streamed Video-On-Demand (VOD) version of the broadcast event that is made available whilst the broadcast event is still continuing according to one embodiment. Alternatively, the StartOver broadcast event is a live streamed Video-On-Demand (VOD) version of the broadcast event that is made available after the broadcast event has concluded. [0025] The StartOver feature for obtaining a StartOver broadcast event is made available to users within an EPG (Electronic Programme Guide) displayed on the content playing device. The feature may be provided between the broadcast event start and until the broadcast event end according to one embodiment. Alternatively, the feature may be provided within a defined time window that expires after the start of the broadcast event, e.g. the time window may be a set number of minutes, hours or days. That is, the feature may be provided within a set duration after the broadcast of the broadcast event has concluded. [0026] A manifest is used by the content playing device to obtain the media content of the StartOver broadcast event. A manifest generation process is driven from EPG information 5 supplied from the EPG in the form of manifest request parameters including channel data and broadcast event start time (or other unique broadcast event identification data), as well as optionally duration and pre/post buffer guard periods. The generation process locates the adaptive media fragments associated with the broadcast event including the optional pre and post buffer guard periods. [0027] Fig. 1 shows a flow diagram of a process according to an embodiment of the present invention. A STB 101 makes a request at step 1a for a video on demand (VOD) version of a broadcast event. This request is referenced in Fig.1 as a "Startover request" because the user wishes to watch a broadcast event from the beginning of that event, even though the broadcast of the start of that event has already passed. [0028] According to this embodiment, a STB is the content playing device. However, it will be understood that any other suitable device may be used to make the request for the streaming VOD version of the broadcast event. For example, the device may be a DVR, tablet device, smart phone device, computer or laptop. [0029] The STB may have typical components associated with a STB including one or more tuner receivers, a demodulator, a demultiplexer, a decryptor/descrambler, a decoder, a modulator/output interface, a media storage device, local memory, a microprocessor, a power supply and a remote control. [0030] The Startover request is sent from the STB 101 to the headend of the broadcast content service provider, and is received in particular by a service delivery platform (SDP) 103. The STB 101 makes a request to start playback of the Startover broadcast event from a defined (pre-determined) starting point associated with the broadcast event. According to this embodiment, the defined starting point is the scheduled broadcast start time of the event. It will be understood that the scheduled start may not necessarily be the actual start of the broadcast event, as the scheduled start times do not necessarily align with the actual broadcast times of broadcast events. [0031] According to a further embodiment, the STB may send the content view request to start playback of content that has previously been broadcast, from a point in the broadcast that was the scheduled start of that broadcast. That is, the broadcast event is no longer being broadcast (has concluded) when the content view request is generated.

6 [0032] The user of the STB 101 makes a request via the electronic program guide (EPG) of the STB 101 to view the broadcast event that has already started, a java script library in the STB 101 then exposes an application programming interface (API) to the EPG that abstracts and manages communication between the STB 101 and the SDP 103. [0033] According to this embodiment, the STB 101 sends the content view request to view content that is currently being broadcast, where the start point of the content to be viewed is the time point in the broadcast that was the scheduled start time of that broadcast. [0034] The content view request includes a channel identifier and a start time for the broadcast event (original broadcast start time). These two items of data identify the broadcast event. The duration of the broadcast event may optionally be provided to enable the detection of the end of the broadcast event. This information provides data that enables the identification of the broadcast event as well as, optionally, the duration of the broadcast event. Each of the items in the content view request may include data that identifies, or is associated with the relevant item, or may include data that is the relevant item itself. [0035] It will be understood that other broadcast event identification data that identifies the broadcast event, other than the channel and start time, may be used to identify the broadcast event. For example, a unique broadcast event identification (Event ID), such as a DVB (Digital Video Broadcast) Event ID or EPG Event ID, may be used that identifies a particular broadcast event with respect to a particular channel and a particular time of broadcast. [0036] The channel identifier identifies the channel upon which the STB 101 is receiving the broadcast event. [0037] The program start time identifies the start time (and optionally the date) of the selected item of content. For example the start time may be in the UTC format in seconds based on UNIX epoch. [0038] According to a first example, the STB 101 may use the time of day (TOD), as provided by an internal clock mechanism, along with information within the program schedule of the EPG to determine the start (and finish) times of the broadcast event based on the scheduled broadcasting start (and end) times provided in the EPG. This internal clock may be synchronised to the same external clock as the play out (and other systems). The external clock data may be distributed via NTP (network time protocol) or a direct clock connection. In both cases the external clock is synchronised to time acquired by GPS (global positioning system).

7 [0039] According to a second example, real time play out triggers may be received by the STB 101 from the headend to correctly identify the start (and finish) times of the broadcast event. For example, the real time play out triggers may consist of one or more of media ID's used to represent the type of programme material being played out (e.g. shows, commercials etc.), list of multiple media ID's that will be played out shortly (e.g. within the next 30-60 minutes), singular media ID that will be played out in the next few seconds (pre-roll), singular media ID that has just played out, singular media ID that has just failed to play out successfully, and a list of multiple media IDs and their success / failed status ("as-run"). The trigger data may consist of a broadcast start time of the content and/or the broadcast end time of the content. [0040] The timing information based on the TOD may be adjusted to provide a guard band. For example, a time period of one to several minutes may be provided prior to the official broadcast start time of the content. Further, a time period of one to several minutes may be used to extend the official broadcast end time of the content. It will be understood that the guard band at the beginning and end of the broadcast may be different or the same. Further, it will be understood that the guard band may be automatically adjusted by the headend. [0041] The program duration provides an indication (in seconds) of the length of the broadcast event. [0042] Additionally, the manifest request may include the following items if required: a high definition (HD) flag; a channel delay indicator; a Startover manifest indicator, and an Event ID (if not previously provided). [0043] The HD flag may provide an indication that the content selected on the EPG from a channel listing is broadcast on a channel that broadcasts in high definition. For example, this flag may be set to "1" if the channel is an HD channel and "0" if the channel is a standard definition channel. [0044] The channel delay indicator may provide an indication that the channel upon which the selected content is (or was) being broadcast is a delayed channel. A delayed channel is a channel where the content items being broadcast are being broadcast again at a time that is a defined time period after the first time the content items were broadcast. For example, the delayed channel being broadcast may be a +2 hour broadcast channel where the original broadcast was scheduled to start at 1 p.m. on a standard channel and the +2 hour broadcast is scheduled to start at 3 p.m. on the delayed channel. The channel delay indicator is provided as a value indicating the seconds by which the delayed channel is being delayed for scheduled 8 broadcast. For example, for a +2 hour broadcast the channel delay indicator is given a value of 7200. [0045] This channel delay indicator may also be used to indicate that the channel upon which the selected content is being broadcast is not a delayed channel. In this case, the channel delay indicator value may be provided as a "0" value. [0046] A Startover manifest indicator may be provided to indicate that the request is related to a Startover request. That is, in a system where multiple different types of manifests are requested, the system is required to understand what type of manifest is being requested by the STB 101. For example, the manifest being requested may be a manifest for content that is currently being broadcast, i.e. a live manifest, where the user does not wish to watch the content from the beginning of the content scheduled broadcast start time, but instead wishes to watch the content from the time the channel was selected on the EPG. In a situation where the user wishes to watch content that is already being (or has been) broadcast from the scheduled start of that broadcast, the Startover manifest indicator is provided to indicate this. [0047] The Event ID identifies a particular broadcast event or item of content that the user is selecting on the STB EPG for viewing from the beginning of that item of content. An Event ID is a unique identification provided to identify specific instances of content for transmission over a satellite link. For example, each satellite transmission of an instance of content may have a separate unique Event ID associated with it. For example, an Event ID may be a DVB Event ID or an EPG Event ID. [0048] Referring back to Fig. 1, at step 1 b, the SDP 103 authorises subscriber requests from the STB 101 via authorised sessions with a licence control server 105. That is, the SDP holds the authorisation information and determines if a subscriber request is entitled to play the content. That is, the SDP 103 checks to see whether the subscriber account containing the identified STB is subscribed to a tier belonging to the channel of the broadcast event being requested. For an entitled request the SDP creates an authorised session (for the requested content) with the license control server 105. Using this session information, which is transmitted to the STB, the STB can retrieve a DRM license. [0049] After authorisation, the SDP 103 generates and transmits a manifest request URL back to the STB 101 at step 1c. The manifest request URL is used by the STB 101 to locate, request and obtain a manifest for retrieving file fragments of the requested content from a content server 9 107, where the content server is in communication with a manifest generator or is incorporated therein. [0050] The manifest generating process in the content server infrastructure is stateless and requires information supplied in the manifest request URL to identify the broadcast event. Specifically, the manifest request requires the following parameters: * Streaming Channel identifier, which identifies the channel upon which the broadcast event is being broadcast * Programme start date and time (UTC in seconds based on UNIX epoch) * Programme duration in seconds [0051] In addition, the following parameters may also be provided: * HD flag (set to 1 for an HD channel) * Channel Delay in seconds (normally 0 and 7200 seconds for +2 channels) * Event ID * Startover manifest indicator [0052] These parameters are passed to the STB 101 in the manifest request URL as follows: http://{Content Server}/{Stream}/{HD}/{+2 Delay}/{Event ID}/{Start time}/{Duration}/manifest [0053] Below is a sample of a manifest request URL for a HD channel with no delay: http://livel.content.foxtel.com.au/Channe1O25/1/0/BMR123456/1372398271/900/manifest [0054] Here it can be seen that the content server is located at http://live1.content.foxtel.com.au. Further, the channel upon which the broadcast event is being broadcast is Channel 025, and that channel is an HD channel. The channel is not a +2 hr channel as indicated by the "0". An event ID of BMR123456 is provided. A start time code of "1372398271" is also indicated along with a duration of 900 seconds. Finally, an identifier "manifest" is added to identify that the requested manifest is a Startover manifest.

10 [0055] The SDP constructs the manifest request URL based on the event identifier sent in the Startover request from the STB and the following information sources: * Channel Tag * ShedML EPG schedules * Channel Map data * Startover channel configuration [0056] The channel configuration information in the SDP 103 defines the invariant part of Startover URLs and forms the leading part of the URL construction based on the following pattern, for example: http://{Content Server}/{Stream}/{HD}/{+2 Delay}/ [0057] The SDP may rewrite the generated manifest request URL before sending the URL back to the STB. The manifest request URL may be rewritten to direct the manifest request to a server pool. The server pool hosts the manifest generating process. This ensures that all requests from different devices are handled the same way and use the same network path. This therefore reduces data handling overheads for multiple platform requests. [0058] To secure the manifest request parameters supplied in the manifest request URL, the entire URL is given a TTL (time-to-live) and is signed before being sent by the SDP. The signing algorithm is shared between the SDP and the content delivery network (CDN) servers so that sensitive URLs can be protected from tampering by external parties. When the STB client requests the manifest the CDN verifies the signature before passing the request onto the headend servers. If the URL fails the signature check the request is denied and an error code is returned to the STB. [0059] Once the STB 101 receives the response from the SDP 103 containing the manifest request URLs to enable playback of the content as well as digital rights management (DRM) URLs, the EPG application in the STB 101 hands the URLs over to the internal media player API. The media player of the STB 101 then makes a request for a client manifest file 109 from the streaming content server 107 at step 2a.

11 [0060] Steps 2b and 2c in Fig.1 indicate a format conversion of the manifest file 109. Format conversion may be required where the STB 101 needs manifest files in one version, but the manifest format offered by the Internet Information Server (IIS) MicrosoftTM 5.0 server is in a different format. In this case the manifest generator in the server 107 converts the manifest files received from the IS server from a version 3 manifest to a version 2 manifest. It will be understood that a format conversion step is not required if the content playing devices are configured so that they can handle manifest files that are generated by the IS server. [0061] The manifest file 109 is returned to the STB 101 from the content server 107 at step 2c. The manifest file 109 contains information about the available bitrates and media fragments for the Startover broadcast event that allows the STB 101 to access the Startover broadcast event from the media server by making requests for the associated media fragments. [0062] For the STB to start playing a Startover broadcast event, where that broadcast event is already being broadcast, the streaming of the media fragments should start from the beginning of the Startover broadcast event. Therefore the manifest provided by the manifest generator includes information identifying all the fragments that make up the Startover broadcast event between the broadcast event start time and the live point. In a situation where the broadcast event started earlier than the scheduled EPG start time of that broadcast event, it would be desired to ensure all the fragments associated with that broadcast event are contained in the manifest. Therefore, an additional pre-event period (guard band) of, for example, up to 5 minutes may be added to the start of the manifest to capture the data fragments associated with the earlier content. [0063] At step 3a, a digital rights management (DRM) licence request is generated and sent by the STB 101 to the authorisation and licence control server 105 to assess whether a suitable licence exists for the particular content item to be accessed in this manner. Step 3b shows the provision of a DRM licence from the authorisation and licence control server 105 upon the authorisation and licence control server 105 determining that a suitable licence is available. If a suitable licence is not available, the process is terminated. [0064] A fragment request is generated at step 4a by the media player in the STB 101 using the manifest file 109, and is sent to the content server 107. At step 4b and 4c, the associated media segment chunk containing one or more media fragments are placed in a suitable file format for transmitting from the server 107 to the media player of the STB 101.

12 [0065] In order for the content playback devices to be able to retrieve the data fragments of the Startover broadcast event, the data fragments must first be created and stored for access by the content playback devices. Reference is made to co-pending Australian patent application 2014200496 titled "Content Management System", which is hereby incorporated in its entirety by reference. [0066] As described in AU2014200496, data fragments of broadcast events may be created by capturing the live broadcast stream at the time of broadcast (i.e. in real time) and converting that live broadcast stream into a number of assets for later transmission to a user's device using IP communication protocols, for example. To do this, a feed from a live broadcast signal is sent to an IP delivery encoder. That is, a data stream of currently broadcast content is received by the encoder. This encoder encodes the data stream to create an encoded linear data content stream of the live broadcast content that may be transmitted over an IP based communication system. The encoder produces encoded fragments of data which contain approximately 2-3 seconds of content therein. These fragments of data are stored temporarily by the encoder in cache storage. [0067] Fig. 2 shows a smooth streaming file format for transporting file fragments from a content server 107 to the content playback device (STB). [0068] As shown in Fig. 2, the file 201 first indicates the file type 203. It also includes file-level metadata ('moov') 205 that generically describes the file. The bulk of the payload is contained in the fragment boxes 207 that also carry more accurate fragment-level metadata ('moof') 209 and media data ('mdat') 211. Although Fig. 2 shows two fragments, it will be understood that a typical Smooth Streaming file would have a fragment for each 2-3 seconds of video and audio. Closing the file is an 'mfra' index box 213 that allows easy and accurate seeking within the file. [0069] The Startover manifest is used by the media player on the STB to request the correct media fragments in the correct order from the media server. [0070] Fig. 3 shows a high level flow diagram of a process for generating a manifest. At step 301, a request for a manifest is made by the STB. At step 303, the parameters in the request are validated by the SDP. At step 305, if the parameters in the request are not valid, an error message is generated. At step 307, if the parameters in the request are validated, a live manifest is obtained from the MicrosoftTM IS. At step 309, the manifest generator calculates the event start fragment timestamp. At step 311, the manifest generator builds a Startover manifest for use by the content playing device to obtain a Startover broadcast event. This Startover 13 manifest is sent back to the STB in the response at step 313. The steps of this process are explained in more detail below. [0071] As explained previously the manifest generation is stateless and the Startover manifest request contains all the parameters needed to create a Startover manifest from a live server manifest. The following parameters may be passed in the request to the generation process: * Channel name * HD channel * Delay * Event ID * Start time * Event duration * Host content server [0072] The check process ensures the correct operation of the script by validating that: * None of the parameters are omitted * Channel Delay is 0 or 7200 seconds * Current time >= Start time * Current time <= Start time + duration * Programme duration is less than the archive of available media fragments on content server [0073] Therefore, the parameters in the manifest request URL sent by the STB are validated. According to this embodiment, a manifest is only generated if the request is received during the timeslot of the associated broadcast event. That is, a determination is made as to whether the 14 broadcast event is being broadcast at the time the manifest request is received by the server. If the broadcast event is still being broadcast, the manifest generation process can be executed. Otherwise, the manifest generation process is terminated. [0074] Once the script receives all the information to generate a Startover manifest, it acquires a live manifest from the content server 107. The live manifest is used as the basis of the reference timing information and the available media stream information for the generation process. [0075] There is a number of streaming hosts in the content server infrastructure that present groups of channels. The rewrite process appends the host address to the request ensuring that the correct streaming content server is targeted. The live manifest request from the generation process follows the structure or pattern shown below: http://[Origin host]/[channelName].isml/manifest [0076] The live manifest sample retrieved from this URL conforms to version 3 of the Smooth Streaming Protocol and is shown in Appendix 1 below. [0077] This process of calculating the event start fragment timestamp pins the timestamp of the media fragments to the broadcast event start time in UTC and calculates the first media fragment that should occur in the Startover manifest. As the media fragment timestamps do not have a matching time epoch to the broadcast event time value, the process calculates the number of seconds of media fragments that are required in the manifest to include the start and end of the broadcast event. This is calculated using the following equation: Event offset = time now - event start time + pre-buffer time [0078] Here "Event offset" is equal to the number of seconds required to go back in time to reach the start of the broadcast event. This calculates the offset (in seconds going backwards) from the current time to when the broadcast event started. Therefore, the current time minus the event start time provides the number of seconds the broadcast event has been running. [0079] To determine the earliest media fragment that must be included in the manifest the value startchunk is calculated using the following equation: startchunk = live timestamp - (Event offset x timescale) 15 [0080] The value "live timestamp" is the time code of the latest request-able media fragment available in the live manifest. The media timestamp is not in seconds but has a unique timescale that is the number of increments in one second. This is configured as 100ns, which equates to a timescale value of 10000000. [0081] As the value "Event offset" is in seconds, it is converted to the media fragment time scale by multiplying it with the value "timescale", which is then subtracted from the value "live timestamp" to calculate the timestamp that is associated with the first valid chunk of the Startover broadcast event. [0082] In other words, a start data fragment position is calculated by calculating the data value startchunk. Startchunk is a timestamp that identifies the first data fragment of the desired Startover broadcast event. Therefore, startchunk is a timestamp that will occur in, or is associated with, the first data fragment of the desired Startover broadcast event. [0083] At a minimum, excluding offsets, startchunk is calculated from three data values i) the current time, ii) the start time of the broadcast event sent by the STB and iii) a live timestamp obtained from a live manifest. The live timestamp is the timestamp of the next media fragment that is due to be broadcast, which is identified in the live manifest. [0084] Start-chunk is then used to calculate the number of the first data segment (5 minute segment) that includes the media fragment (3 second fragment) having the timestamp startchunk. The number of the first data segment (start-segment) is calculated using the segment-length and startchunk data values. [0085] The final valid Startover event chunk of data for the Startover broadcast event can be calculated as follows: finalchunk = startchunk + (pre-buffer time + event duration + post-buffer) x timescale [0086] In a similar way, the timestamp value finalchunk indicating the timestamp of the final media fragment (3 second fragment) is calculated. This is calculated using the startchunk value and the event duration sent by the STB. The finalchunk value is used to calculate the number of the last data segment (5 minute segment) that includes the media fragment having the timestamp final_chunk. The number of the final data segment (finalsegment) is calculated using the segment-length and finalchunk data values.

16 [0087] Therefore, the system calculates in which start and end data segments (5 minute segments), the relevant 1OOns point in the start and end data fragments (3 second fragments) are located based on the calculated start and end data fragment timestamps. [0088] Once the media fragment timestamps of the start and end of the Startover broadcast event have been calculated, the process of retrieving the media fragment references from the streaming content server can proceed for insertion into the manifest. [0089] According to this embodiment, a data fragment has a duration of approximately 2-3 seconds, with a timescale precision of approximately 1OOns. However, it will be understood that data fragments may have longer or shorter durations and longer or shorter timescale precision. Multiple data fragments form a data segment. According to this embodiment, a data segment has a duration of approximately 5 minutes. However, it will be understood that data segments may have a longer or shorter duration. [0090] The manifest generation process reads live and archive manifests to construct a correctly timed Startover manifest. Following is the general process used to change the IS manifest by the manifest generating script: * The start and end points of the programme relative to the media timestamps are calculated; * The media fragments are trimmed based on the first and last media timestamps; * The media fragments are encapsulated in a Version 2 Smooth Streaming manifest; * The manifest duration and DVR Window are set based on the programme duration. [0091] Fig. 4 shows a flow diagram of a process for generating the manifest. The process starts at step 401. At step 403, a version 2 manifest shell is created. At step 405, the temporal position of the first segment of the requested content is calculated by the manifest generator. At step 407, the version 3 live manifest is obtained from the MicrosoftTM IlS. Fragment identifiers are added to the version 2 manifest at step 409. A check is made at step 411 to see if all the relevant segments of the Startover broadcast event have been requested. If further segments are required, the next segment is calculated at step 413 by repeating steps 407, 409 and 411. If further segments are not required, the process ends at step 415. Further details of the steps of this process are described below.

17 [0092] As explained earlier various content playing devices may require a version 2 manifest. Therefore the manifest generation process must perform a protocol conversion between the server format and the desired output. A basic version 2 XML document shell is created from the live manifest initially read from the server. Then the DRM protection information and required media stream bitrate options are added to the document. [0093] The IS MicrosoftTM 5.0 version 3 smooth streaming format archives media fragments into 5-minute VOD segments each with their own manifest. Therefore, the generation process must acquire all of the segment manifests that encompass the Startover programme. Segment numbers are derived from the media fragment timestamp and as stated have a length of 5 minutes or 300 seconds. This means that each segment has a fixed length of 3000000000 or 300 x timescale. [0094] To calculate the first segment (start-segment) to acquire, the startchunk value is used as a reference: startsegment = segment-length x (startchunk / segment-length) [0095] This process is performed with 64 bit integer mathematics in order to reduce the precision of the result by the divisor segment-length. As the segmentlength is 5 minutes, the process reduces the result precision by a factor of 3,000,000,000 (i.e. 5 minutes/iOOns). [0096] In the same way the timestamp of the final segment (finalsegment) can calculated as: final_segment = segment-length x (finalchunk / segment-length) [0097] The generation process then successively acquires the segment manifests beginning with the startsegment. The individual segments are requested from the server publishing point using the following URL template: http://[server host]/[channel Name]. isml/Segments(segmentnumber)/manifest [0098] The manifest responses are processed and required media fragments appended to the manifest generator output. [0099] Each segment is successively presented and media fragments that fall within the startchunk and endchunk range are added to the version 2 manifest output. The version 3 manifest format allows a chunk repeat count attribute "r" which is not supported in version 2.

18 Therefore, the repeated chunks are individually added to the generated manifest with a chunk duration. [00100] That is, the manifest generator retrieves each data segment (5 minute portion) using a URL that includes the segment-number. Data identifying each data fragment (3 second fragment) within each of the data segments (5 minute portions) that falls between the timestamps startchunk and finalchunk is entered into the Startover manifest. Therefore, each manifest of a 5 minute segment archives data fragments between the start and end segment periods, i.e. the fragment timestamps that fall between the start and end fragments are included in the manifest. [00101] After all the valid chunks from the segment are added to the generated manifest the process loops around until every valid segment available between the start-segment and end_segment have been retrieved. This three-step cycle continues until either all the valid segments are requested. If the event hasn't finished, then valid segments will be between the startsegment and the current timestamp. [00102] Instead of creating separate smooth stream publish points for high definition (HD) channels standard definition (SD) and HD bitrates are combined into single presentation from a single server publish point. Depending on the quality of presentation selected the HD or SD streams are simply filtered out of the Startover manifest response. If the STB is subscribed to receive HD content and the Startover request is made from an HD channel, the HD flag is set in the manifest request as underlined below: /Channe1025/1/0/BMR123456/1372398271/900/manifest [00103] Below are a set of example bitrates available in a smooth stream presentation with the SD streams in white ranging from 600Kbps to 2500Kbps and a single 4500Kbps HD bitrates underlined. 4500 Kb/Sec 2500 Kb/Sec 1800 Kb/Sec 19 1400 Kb/Sec 800 Kb/Sec 600 Kb/Sec [00104] The manifest generation script checks the HD flag in the request and, if it is set, the HD bitrates underlined are included in the Startover manifest as well as the highest SD resolution. If the HD flag is not set then only SD bitrates are included in the manifest output. [00105] Fig. 5 is a flow diagram of a process for requesting a streamed version of a broadcast event (Startover broadcast event). [00106] The process starts with the broadcast headend sending linear EPG data to the STB. The EPG of the STB retrieves the EPG data and displays the TV guide for use by the user of the STB. When a user selects a particular broadcast event on the EPG for viewing in the herein described Startover mode, a Startover request is sent from the EPG to the SDP via an API. The SDP checks that the subscriber of the STB has the correct entitlements and if not, returns a request declined message to the STB indicating that the user is not entitled to use the Startover mode. [00107] If the SDP determines that the user does have the correct entitlements, the SDP authorises the content with the DRM service and subsequently generates and returns a Startover manifest request URL with the EPG start time and DRM session information to the STB. [00108] Fig. 6 is a flow diagram of a process for generating a manifest and obtaining a streamed version of a broadcast event (Startover broadcast event). [00109] This process starts with the EPG in the STB requesting the Startover broadcast event using the manifest request URL previously provided to it by the SDP. This request includes the manifest details and DRM information. The request is forwarded to the content server, which forwards a request to generate (or create) the manifest to the manifest generator. [00110] The manifest generator obtains the relevant segment data and fragment identifiers from the media services module, which forms part of the content and IIS server, and adds these 20 to the Startover manifest until all fragments and segments are identified. The completed Startover manifest is then returned to the STB via the content server. [00111] The STB communicates with the DRM service to request a DRM license using the session information. The session is checked for content authorisation and a DRM license is returned to the STB if authorised by the DRM service. [00112] The STB then starts to request the media fragments using the details in the Startover manifest. A request for the media fragments is sent from the STB to the content server. The content server retrieves the media fragment using media services and sends the fragment back to the STB. The fragment is then played by the STB. This process is repeated for either i) the duration of the requested Startover broadcast event, i.e. until the last fragment is detected by the STB, ii) until the play back of the Startover broadcast event has been paused beyond a defined time limit or iii) until the user of the STB closes the session by stopping the process (e.g. changing channel or turning off the content playing device). [00113] Fig. 7 is a flow diagram of a caching process for use in the method and system as described herein. [00114] Interactions with a Smooth Stream server are stateless and each request from the client is handled by a different instance of the server. Each request URL contains all the information required by the server to complete the request including timestamp and bitrate for fragments. This makes infrastructure more flexible, scalable and allows request responses to be cached easily with an HTTP proxy or content delivery network (CDN). A sequence diagram in Fig. 7 illustrates the communication pattern for requests of the same fragment indicated as 'Fragment X' and how a Proxy can reduce server load. [00115] Referring to Fig. 7, a fragment request X is sent from client A (STB A) to a HTTP cache proxy. The cache proxy determines that the fragment is not stored in the cache and requests the fragment from the content server. The content server returns a response to the HTTP cache proxy and stores the response (i.e. the fragment) at the proxy. The fragment is then returned to client A. [00116] Subsequently, when client B (STB B) requests fragment X at the HTTP cache proxy, the cache proxy determines that the fragment is available and returns the fragment in a response back to client B.

21 [00117] In the Startover mode described herein, caching of manifest and fragment responses are performed by a CDN that retrieves requested manifests and fragments from the content servers. Requested fragments are cached at the CDN edge servers close to customers for the maximum Startover duration of 4 hours. It should be noted that +2 channels require an additional 2 hours of storage time. [00118] The manifest generation process can operate in two distinct modes. [00119] According to a first mode, the manifest generation process may operate as a VOD experience. [00120] In this first mode the media player in the STB is presented, within the manifest, all of the media from the beginning of the Startover broadcast event to the current live point. The media playback is positioned to the start of the Startover broadcast event by the media player in the STB. [00121] This allows a viewer to begin watching the Startover broadcast event from the beginning of the event and also allows the user to fast-forward the streamed content until catching-up with the live broadcast. The viewer may then elect to return to the broadcast channel or continue streaming the Startover broadcast event. [00122] Fig. 8A is a temporal diagram identifying content that is indicated in a manifest according to this first mode of operation. [00123] Data that identifies data fragments for the media 801 being requested may be provided in a manifest according to this first mode. A scheduled broadcast start point 803 indicates the scheduled start time of the requested Startover broadcast event. The actual start 805 of the Startover broadcast event is moved back in time from the scheduled broadcast start point 803 based on a defined offset time value 807. The end point of the Startover broadcast event is indicated at point 809. [00124] According to a second mode of operation (as shown in Fig. 8B), the manifest generation process may operate as a live viewing experience. [00125] In this second mode the media player in the STB is presented, within the manifest, with media only to the beginning of the Startover broadcast event. The STB media player will then stream the Startover broadcast event as if it were occurring as a live broadcast. This means the 22 viewer has the same viewing experience as if they were watching the original live broadcast stream. [00126] For this live viewing experience mode, only the startchunk timestamp is identified in the Startover manifest and the remaining segments are accessed by the STB as if the Startover broadcast event was being broadcast live. That is, the media player in the STB streams the streaming version of the Startover broadcast event from the first segment associated with the startchunk timestamp, which may include an offset value. [00127] With the standard MicrosoftTM HSS (HTTP Smooth Streaming) live streaming, there is no defined mechanism within the protocol or server infrastructure to stop a content playing device from continuing to stream once the end of the Startover broadcast event is reached. [00128] By modifying the fragment request URL pattern defined in the Startover manifest a finish time reference can be added. The time reference may be added as a HTTP query string field-value pair with a maximum fragment timestamp value as shown below. Url ="QualityLevels({bitrate})/Fragment(video={start time})?lim it= 123456789000000" [00129] When the client requests media fragments from the streaming content server they are intercepted by a request filter in the server infrastructure. The filter compares the fragment starttime against the limit value. [00130] If the starttime is less than the limit value the request is forwarded onto the content server to retrieve the requested fragment for the STB. [00131] If the fragment is greater than the limit value, a HTTP status code is returned to the STB to terminate the start-over streaming. [00132] Fig. 8B is a temporal diagram identifying content that is indicated in a manifest according to this second mode of operation. [00133] Data identifying data fragments for the media 901 being requested are provided in a manifest using this second mode. A scheduled broadcast start point 903 indicates the scheduled start time of the requested Startover broadcast event. The actual start 905 of the Startover broadcast event is moved back in time based on a defined offset time value 907. The end point of the Startover broadcast event is indicated at point 909. Data fragments 911 are 23 provided to the STB sequentially using the standard live streaming mechanism without using descriptions in the Startover manifest. [00134] According to the first mode, the STB is able to access all the media fragments between the startchunk and finalchunk timestamps, via an IP streaming adaptive bitrate protocol. That is, all media fragments from the start of the Startover broadcast event through to the final fragment are identified in the manifest before the manifest is sent to the STB. According to this option, the final fragment is either the final fragment of the Startover broadcast event if the broadcast of the event has concluded at the time of the request, or the latest live fragment of the event if the broadcast of the event has not concluded at the time of the request. The STB media player can then start to access these fragments from the media server and start playing the content from the start of the scheduled broadcast. The user can also freely fast forward, pause and rewind the accessed fragments. [00135] The Startover manifest is configured for live operation. Therefore, in the case where the request to view the content is made prior to the conclusion of the event being broadcast, the media player in the STB can continually acquire information from the server concerning the latest live fragment. The STB builds an internal manifest of all the available fragments based on the information received from the server, and so can subsequently access content after the [00136] According to a further embodiment, the system enables a media player in the content playing device to show streaming versions of broadcast items from the beginning of the scheduled broadcast where the broadcast has already finished. For example, the system defines a start time for the broadcast event that can refer back up to 30 days, depending on the storage availability at the headend for storing the media fragments. According to this further embodiment, it will be understood that the process and system operate in substantially the same manner as described in the first embodiment except that the request for Startover broadcast event is not made during the broadcast of the broadcast event. That is, the request for a Startover broadcast event is made after the broadcast of the event has concluded. [00137] It will also be understood that the defined start time for viewing the Startover broadcast event may be the scheduled start time of the broadcast event. Alternatively, the defined start time may be any other desired start time, such as a predefined period prior to the scheduled start time or a predefined time period after the scheduled start time. Industrial Applicability 24 [00138] The arrangements described are applicable to the computer and data processing industries and particularly for the provision of broadcast content to client devices. [00139] The foregoing describes only some embodiments of the present invention, and modifications and/or changes can be made thereto without departing from the scope and spirit of the invention, the embodiments being illustrative and not restrictive. [00140] In the context of this specification, the word "comprising" means "including principally but not necessarily solely" or "having" or "including", and not "consisting only of". Variations of the word "comprising", such as "comprise" and "comprises" have correspondingly varied meanings.

25 [00141] Appendix 1 - Version 3 Live Manifest <Smouthstreami ngm~edia -',V::I3": !VJ:: " "i .. O100000 <Segmrtt ;4r::" segments (startti me}) /mani fest ", ,:-2-: 'i :1085172000000000" L~3000000000"> <Stireamindex -s' .=vi deo" ,.-,m-="vi deo" K~" ~ ~ 10Tm; =0000 - -'="QualityLevels({bitrate})/Fragments(video={start time})" <Qual ityLeve-i " '-'0 -=2499968" BDCO7C22114EOOOOOOO128FFBC80 "H6'~~U~"04 <Qiai ityLeve! - -1 =8000 77BDc07c22114E000000128FFBC80" F .- "8H64 2" <iuali tyLevel ~=~"i:E=1000 BDc07c22114EO000000128FFBC80' CC:~24 :i704'!v 00000001674D40 1F92 9832 3B602 200000 30002 00000 30065C04002 36600046CDCD45 50F8313800000000168EFBC80" ~CH6 i>*~~"4" ~ ~ 30/ <Qua~ l tyLevel ' =5 i::"000 a,: ;-'00000001674D401F92981405FF2E022000000300200000065c940061A800c35CD450 lFl831380000000168EFBC80" --- 0U;CX="H264" I64 MxI 36/ <c 11="1085172020000000" d="30000000" </St rearnlndex> <Str'eamilndex ,) -"audi o" ',, -x=audi o0 .E c~"n" ~ &~-100, ~=100000005' :.w 'Qual i tyLevel s (Ibi trate}) /Fragments (audi o-O=start ti me})" ,astl "1085171990426666"> <Qua.' i tyL .eve-:l idkx=" 4I a,~- 128000 -3- >AA <~~~--C" 255'00 :: 2'c od 400 AACC6"~~:k~~Is~~"/ ::1085172020506666'? A::'30080000,, /> d-: =2 98 6666 7!"/ d,:::"30080000! r: '!/ " 29866667"l/>. "30080000"2,/> "29866667"/> "30080000" 2, <d=29866667"/> <d=30080000" -2V <c d=29866667"/> <c d=30080000"/>2~/ <c d::'30080000"7 26 d,298666667>/, d, "30080000" -"2"/1> d, 2"29866667'V/> d, "30080000" -"2" "1> d"2 98 6666 7 d-"300 80000 2298 66666 ' d,::30080000! 4,:2 '/ "29866667"l/> " 30080000" "29866667"l/> "30080000",/ d=29866666"/> d30080000" r-2 , d=29866667"/> d30080000" r="2'/> -', 29866667"/> -. '30080000"/> <C -' "29866666"/> <C d::'30080000"' -"2 /> <c d::!'29866667"'/> <c d::'30080000" ,-::"2 11 d::!='29866667//> d::!='30080000"//>~/ <c d="29866666"/> <c d="30080000" -2"/> <c d="29866667"/ <c d="30080000 "2/ <c d="29866666'> <c d="30080000"/2> <c d="298666667'> / <c d=30080000" v"2" /-> d, 2"29866667" /, d, "30080000" "211 dW'30080000"l, d-"298 66667! / dl::30080000! 4,:2!/ d-"2986666 7!/ d::30080000! 4,:2'!/> "29866667"/> "30080000",/>2'/ "'29866666"/> "'30080000", d="29866667"/> d="30080000" -2 '> <C ,'30080000"/>'~/ 27 <d,, 298666677>/, <c dW' 30080000, <c d, 29866666'V/> <c d, 3OO8OOOO'" -"2"/1> d::30080000" r:2!/ </Si: treaMlI-) lX> </Segment> <Segment u'rl "Segments ({startti me}) /mani fest ST~18150000

L

9 3000000000"> <Stireamindex -su, :='"video" =vde' v=' k.

2 0 :c& 2 10000 - -'="QualityLevels({bitrate})/Fragments(video={start time})" :T :-:="1085174990000000"> <Qual ityLeve-i "' '-'0 a~="2499968" C. ~-\:,;.$ - ,u="000000012 74D40lF9246020024D8088000000300800000197120002 62 580004c4B77 BDCO7C2214EOOOOOOO128FFBC8O -04 "~"04 <Qiuali tyL-evel Id<- "1:E=1000 ,,'o ,,- ,',,-" ,-': -- , :-l"000001274D401F924606C1EF3F8088000003000800000301970300036EE8001B77 77BDc07c22114E000000128FFBC80" ;-"C~ 24" v~ 852" > gE'n:=480"li> <Qiuali tyLevel ~=~"i:E=1000 BDcO7c22114EO000000128FFBC80!' C: H6~ U74 ~ < -i tyLeT : 3el: "894 C~'~&L< 0000 0001674D401F9298323B602200000300020000030065C0400236600046CDCD45 50F8313800000000168EFBC80" A(C="H264"M~.T=60 ~ 930/ <Qua! ityLeve ' x~5 ~ "000 a,: ;-' 00000001674D401F92981405FF2E022000000300200000065c940061A800c35CD450 1F1831380000000168EFBC80" --- 0U;CX="H264" I64 MxI 30/ <c 11=" 1085175020000000" d="30000000 "82/ </St reamindex> <Str'eam.Tndex vv&, -"audio" ',, ,,.x=audio0 0 n"cn~ ... :>'100000005' :.w Qua i tyLeve s (bi rate) /Fragments (audi oO={start time})" ~T .&='1085174990533333"> <Qu.a IiityLeVel1 i>:"01800'2 C: 'AACL"? <c ::U'"1085175020613333? A:'!29866667 /> < -: 30080000!/ "29866666"l/ "30080000" 2/ "29866667"l/ "30080000" 2/ <d=29866667"/> <d=30080000" /> < - ',, 29866666"/> <cd:'29866667"/> <c d::'30080000 "/ > 28 c d="29866666"!> <c d="30080000" r="2"/> <c d="29866667"/> c d="30080000" r="2"/> c d="29866667" c d="30080000" c 29866666" d="30080000" ::"2"/> "29866667"/> S"30080000" "29866667" > "30080000" > d="30080000" r="2" > c d="29866667" /> c d="30080000" r="2" > c d="29866667"/> 'c 30080000" > c "29866666"/> c "30080000" r-"2" > c "29866667"/> <c d="!30080000" r=::"2"11> <c d::"29866667"/> <c/streamindex> </segment> </Smoothstreami ngMedia> 29 [00142] Appendix 2 - Version 2 Starto-ver Manifest <Smoo-thstreami ngmedi a ~ ""SI~~:s 0 )r~ :20000 ~ s:" 100000" v~~: "TRUE" ~ ~ ~ ~ ""~&W ~h:: <CUSt"mAttributes> <Attribute \a,,, =prebuffer" va< uZ -=300' / <Attribute "~=post buff er' "va , , ="600"/> <Attnibute \.'a-, ="durati on" v~i=10' /> <Attribute "~event" Vi :;-"F8D56759131"/> </Cus tomAttr-'utes> <Protecti on> <Protecti onf-eader v:: =a0f7-8048-b -65 0855"-/rttin adr < 'Protection> <Stream index vdo"::- vido L:y>= ;ks'10 Y &10000 "QualityLevels({bitrate})/Fragments(video={start time})". <QIualityL-evel <=0" tE~6 00' C- .V- E:, L,, :Y, ,-,:,:'00000001674D41F92981405FF2 E022000000300200000065C0C00124F800249FCD4 50lFl831380000000168EFBC80" ' C:m"H264" SW ~:"4" ~ 30/ 1F1831380000000168EFBC80" F0ll;CC="H264" :ViU=64 ich 360"/> -c , : -,-,;,vJ,, -> .>-,tk= 000000012 74D40 1F924605 819D80880000030008000003019 70 3000 2AB9800 15 5CF7 BDCO7C22114EOOOOOOO128FFBC8O" -OJPCC="H264" ~iw~=0' ~ h=0"> <Qua VityLeVel - \=3 I:!"8000 a,: ;-'00000001274D401F924606ClEF3F8088000003000800000301970300036EE8001B77 77BDc07c22114E0000000128FFBC80" '--UZC0'="H264" L=82=407 <Qua! ityLeVel &=-4 3I:"4998 BDC07C22114E0000000128FFBC80" 24~~c:'12"M<i ~ / d, 30000000" z>" 1089446927600000"/'> <c dW'30000000"1, < 30000000 < 30000000 < d:"30000000 dl::"30000000 "30000000",/> "30000000",/> " 30000000",/ "30000000"/ <d=30000000" /> <cd"30000000" /> <cd"30000000" /> <cd"30000000" /> <c ::30000000"/> <c ::30000000" /> 30 <c dW' 30000000",, <c dW' 30000000",, <c dW'30000000",/, < 30000000 *30000000 d-:"30000000 d1:"30000000 "30000000",/ " 30000000",/ "30000000",/> "30000000",/> <d=30000000" /> <cd=30000000" /> <d=30000000" /> <d=30000000" /> < - .,'30000000"/> < c -,'30000000"/> < c -,'30000000"/> < c -,'30000000" /> <c d:W'30000000 '7> <c d:W'30000000 '7> <c d:W'30000000 '7> <c d='"30000000l> <c d="30000000"/ <c d="30000000"/ <c d="30000000/ <c d="30000000/ <c - ="30000000 " <c - ="30000000 ,c - =30000000" ,c - =30000000" <c dW30000000l/, <c dW30000000l/, <( d:U 30000000 d- :U 30000000 d-:"30000000 d-"30000000 "30000000",/ "30000000",/ "30000000",/ "30000000"/ <c d=30000000" /> <c d='"30000000"/ < c c,,'30000000"/ </Str eaindex' :& i::"00000":U'::Qual i tyLevel s (Ibi trate}) /Fragments (audi o-O=start ti me}) "> 31 255"4 E:,~ '1800 C-o40 A A--"16' <c W&29866667" :>" 10894469282 13333" /> <c IW30080000",/, " -d-"2 98 66666 ' " - -: 300 80000 " - -: 300 80000 "30080000",/ " 30080000",/ "29866667"/> "30080000",/ <cd"29866666"/ <d=30080000" /> <d=30080000" /> <cd"29866667"/> < c -,'30080000"/> < c -,'30080000"/> < c -', 29866667"/> < - .,'30080000" /> c d::"29866666"'/> <c d::"30080000 "/ > <c d::"30080000 "/ > <c d::"29866667"'/> <c d="29866667"/> <c d="30080000"/ <c d="29866666"/> <c d="30080000"/ <c - ="30080000 <c - ="29866667" <c - ="30080000 <c - ="30080000 <c d, 29866667" /, <c dW300800001/, <c d, 29866666" /, <c dW300800001/, " c d:"2 300 80000 " -d-"300 80000 ' "29866667"/> "30080000",/ "29866666"l/> "30080000"/ <d=30080000" /> <cd"29866667"/> < c -,'30080000"/> < - .,'30080000"/> < -',, 29866667"/> < - .,'30080000" /> c d::"29866666"'/> 32 <cd'30080000",, <c d, 29866667'V/> <c dW' 30080000",, <cd'30080000",/, < 2 98 6666 7 2300 80000 d-"298 66666 ' d1:"300 80000 "30080000",/> " 29866667"/> "30080000",/> "30080000",/> <cd"29866667"/ <d=30080000" /> <cd"29866666"/ <c d=30080000" /> < c c,,'30080000"/ < c c,' 29866667"/> </qtreamifndex> <';qioothStreami ngivedi a>

Claims (42)

1. A method of generating a manifest for streaming a video on demand (VOD) version of a broadcast event from a pre-determined start point associated with the broadcast event, the method comprising the steps of: (a) receiving a request for a VOD version of a broadcast event, whilst the broadcast event is still being broadcast, wherein the request includes broadcast event identification data; and (b) generating a manifest based on the broadcast event identification data, wherein the manifest includes a pre-determined start point for streaming the VOD version of the broadcast event that is based on a scheduled start time of the broadcast event.

2. The method of claim 1 wherein the step of generating a manifest further comprises the steps of: (a) generating a manifest request URL based on the broadcast event identification data; (b) transmitting the manifest request URL to a content playing device; and (b) upon receiving a request for the manifest, generating a manifest based on the manifest request URL.

3. The method of claim 1, further comprising the steps of determining whether the broadcast event is currently being broadcast and generating a manifest only upon a positive determination.

4. The method of claim 1, wherein the pre-determined start point is calculated based on a scheduled start time and a timestamp of the current media fragment that is being broadcast.

5. The method of claim 1, wherein the manifest is generated by calculating a starting temporal position for the start of a first data segment of the VOD version of the broadcast event based on start time data, a current time value and a time code of a live media segment, where the live media segment is the latest media segment of the broadcast event that is available for broadcasting.

6. The method of claim 5, wherein the start time data is obtained from the broadcast event identification data. 34

7. The method of claim 1, wherein the request further includes duration data identifying the duration of the broadcast event, the manifest is generated by calculating a final temporal position for the start of a final data segment of the VOD version of the broadcast event based on the start time data, the duration data, a current time value and a time code of a live media segment, where the live media segment is the latest media segment available for broadcasting, and wherein the start time data is obtained from the broadcast event identification data.

8. A method of generating a manifest for streaming a video on demand (VOD) version of a broadcast event from a pre-determined start point associated with the broadcast event, the method comprising the steps of: (a) receiving a request for a VOD version of a broadcast event, wherein the request includes broadcast event identification data; and (b) generating a manifest based on the broadcast event identification data by calculating a starting temporal position for the start of a first data segment of the VOD version of the broadcast event based on start time data, a current time value and a time code of a live media segment, where the live media segment is the latest media segment of the broadcast event that is available for broadcasting.

9. The method of claim 1 or claim 8, wherein the broadcast event identification data includes channel data identifying a channel associated with broadcasting the broadcast event and the start time data identifying a scheduled start time of the broadcast event

10. The method of claim 1 or claim 8, further comprising the step of calculating the pre determined start point based on a scheduled start time and a timestamp of the current media fragment that is being broadcast.

11. The method of claim 1 or claim 8 further comprising the step of streaming the VOD version of the broadcast event from a pre-determined start point whilst the broadcast event is still being broadcast.

12. The method of claim 1 or claim 8 further comprising the step of streaming the VOD version of the broadcast event from a pre-determined start point after the broadcast event has finished being broadcast.

13. The method of claim 11 or 12, wherein the pre-determined start point is associated with the scheduled broadcast start time of the broadcast event. 35

14. The method of claim 13, where the pre-determined start point is the scheduled broadcast start time of the broadcast event.

15. The method of claim 13, where the pre-determined start point is adjusted based on a defined offset time value.

16. The method of claim 1 or claim 8, wherein the time code of the live media segment is obtained from a live manifest associated with the live broadcast of the broadcast event.

17. The method of claim 1 or claim 8, wherein the start temporal position is further based on a pre-buffer value that is associated with a defined time period inserted prior to the scheduled start time of the broadcast event.

18. The method of claim 1 or claim 8, wherein the request further includes duration data identifying the duration of the broadcast event.

19. The method of claim 18, wherein the manifest is generated by calculating a final temporal position for the start of a final data segment of the VOD version of the broadcast event based on the start time data, the duration data, a current time value and a time code of a live media segment, where the live media segment is the latest media segment available for broadcasting.

20. The method of claim 19, wherein the time code of the live media segment is obtained from a live manifest associated with the live broadcast of the broadcast event.

21. The method of claim 19, wherein the final temporal position is further based on a post buffer value that is associated with a defined time period inserted after the scheduled end time of the broadcast event.

22. A system for generating a manifest for streaming a video on demand (VOD) version of a broadcast event from a pre-determined start point associated with the broadcast event, the system comprising a manifest generator adapted to: (a) receive a request for a VOD version of a broadcast event, whilst the broadcast event is still being broadcast, wherein the request includes broadcast event identification data; and 36 (b) generate a manifest based on the broadcast event identification data, wherein the manifest includes a pre-determined start point for streaming the VOD version of the broadcast event that is based on a scheduled start time of the broadcast event.

23. The system of claim 22, wherein the manifest generator is further adapted to generate the manifest by: (a) generating a manifest request URL based on the broadcast event identification data; (b) transmitting the manifest request URL to a content playing device; and (b) upon receiving a request for the manifest, generating a manifest based on the manifest request URL.

24. The system of claim 22, wherein the manifest generator is further adapted to determine whether the broadcast event is currently being broadcast and generating a manifest only upon a positive determination.

25. The system of claim 22, wherein the pre-determined start point is calculated based on a scheduled start time and a timestamp of the current media fragment that is being broadcast.

26. The system of claim 22, wherein the manifest generator is further adapted to generate the manifest by calculating a starting temporal position for the start of a first data segment of the VOD version of the broadcast event based on start time data, a current time value and a time code of a live media segment, where the live media segment is the latest media segment of the broadcast event that is available for broadcasting.

27. The system of claim 26, wherein the start time data is obtained from the broadcast event identification data.

28. The system of claim 22, wherein the request further includes duration data identifying the duration of the broadcast event, the manifest generator is further adapted to generate the manifest by calculating a final temporal position for the start of a final data segment of the VOD version of the broadcast event based on the start time data, the duration data, a current time value and a time code of a live media segment, where the live media segment is the latest media segment available for broadcasting, and wherein the start time data is obtained from the broadcast event identification data. 37

29. A system of generating a manifest for streaming a video on demand (VOD) version of a broadcast event from a pre-determined start point associated with the broadcast event, the system comprising a manifest generator adapted to: (a) receive a request for a VOD version of a broadcast event, wherein the request includes broadcast event identification data; and (b) generate a manifest based on the broadcast event identification data by calculating a starting temporal position for the start of a first data segment of the VOD version of the broadcast event based on start time data, a current time value and a time code of a live media segment, where the live media segment is the latest media segment of the broadcast event that is available for broadcasting.

30. The system of claim 22 or claim 29, wherein the broadcast event identification data includes channel data identifying a channel associated with broadcasting the broadcast event and the start time data identifying a scheduled start time of the broadcast event

31. The system of claim 22 or claim 29, wherein the manifest generator is further adapted to calculate the pre-determined start point based on a scheduled start time and a timestamp of the current media fragment that is being broadcast.

32. The system of claim 22 or claim 29 further comprising a server adapted to stream the VOD version of the broadcast event from a pre-determined start point whilst the broadcast event is still being broadcast.

33. The system of claim 22 or claim 29 further comprising a server adapted to stream the VOD version of the broadcast event from a pre-determined start point after the broadcast event has finished being broadcast.

34. The system of claim 32 or 34, wherein the pre-determined start point is associated with the scheduled broadcast start time of the broadcast event.

35. The system of claim 34, where the pre-determined start point is the scheduled broadcast start time of the broadcast event.

36. The system of claim 34, where the pre-determined start point is adjusted based on a defined offset time value. 38

37. The system of claim 22 or claim 29, wherein the time code of the live media segment is obtained from a live manifest associated with the live broadcast of the broadcast event.

38. The system of claim 22 or claim 29, wherein the start temporal position is further based on a pre-buffer value that is associated with a defined time period inserted prior to the scheduled start time of the broadcast event.

39. The system of claim 22 or claim 29, wherein the request further includes duration data identifying the duration of the broadcast event.

40. The system of claim 39, wherein the manifest generator is further adapted to generate the manifest by calculating a final temporal position for the start of a final data segment of the VOD version of the broadcast event based on the start time data, the duration data, a current time value and a time code of a live media segment, where the live media segment is the latest media segment available for broadcasting.

41. The system of claim 40, wherein the time code of the live media segment is obtained from a live manifest associated with the live broadcast of the broadcast event.

42. The system of claim 40, wherein the final temporal position is further based on a post buffer value that is associated with a defined time period inserted after the scheduled end time of the broadcast event. FOXTEL MANAGEMENT PTY LIMITED Patent Attorneys for the Applicant/Nominated Person SPRUSON & FERGUSON