WO2012046090A1

WO2012046090A1 - System and method for error detection and data replacement in broadcast services

Info

Publication number: WO2012046090A1
Application number: PCT/IB2010/002512
Authority: WO
Inventors: Timothy Alan Barrett
Original assignee: Thomson Licensing
Priority date: 2010-10-04
Filing date: 2010-10-04
Publication date: 2012-04-12

Abstract

A system and method for augmenting broadcast services with files based on groups of pictures (GOP) are provided. The system and method provide for receiving a first program content from a first communication medium (502), detecting an error in a segment of the first program content (506), the error causing a playback error if the segment is played, acquiring a replacement segment from a second communication medium (508), replacing the segment containing the error data with the replacement segment (510), and playing the stored first program content including the replacement segment (514). The error may be corrupt data or missing data. In one embodiment, the replacement segment is a file based on at least one group of pictures (GOP).

Description

SYSTEM AND METHOD FOR ERROR DETECTION AND DATA REPLACEMENT IN BROADCAST SERVICES

TECHNICAL FIELD OF THE INVENTION

5 The present disclosure generally relates to digital content systems and methods for distributing content, and more particularly, to a system and method for augmenting broadcast services with file-based groups of pictures (GOP).

BACKGROUND OF THE INVENTION

Some of the key differentiators for modern Internet Protocol (IP) based video 10 solutions over legacy broadcast solutions include Picture in Picture (PiP) channel browsing, fast channel change, and a degree of data loss recovery (such as for rain fade for satellite). Each of these capabilities can potentially be provided in a traditional broadcast service, to a greater or lesser extent, through the implementation of additional video streams or video data in addition to the main video 15 streams of the broadcast service. This stream augmentation could be implemented in either a broadcast form, or, where IP is available, a multicast or unicast form, though there are difficulties with each of these approaches as defined to date, in particular where there is only unmanaged infrastructure available.

20 Existing dedicated Internet Protocol Television (IPTV) solutions, for example, use unicast protocols to get data from network servers for fast channel change, and use the same stored data for loss recovery. The difficulties with these solutions are that there is potentially a significant number of dedicated, proprietary servers in the network performing this task, and there is often a requirement that all the pieces of 5 the solution, from the content ingest through delivery (e.g., the servers and the clients), are part of a closed, proprietary system.

As IP and broadcast services merge and broadband rates increase, there is an opportunity for leveraging existing network infrastructure. While there have been 30 many mechanisms suggested for using simultaneous broadcast streams for implementing both fast channel change and loss recovery over managed networks and several fast Internet streaming technologies, such as Microsoft's™ Smooth Streaming or Move Networks, today, these concepts are not unified to provide an optimal solution for augmenting broadcast network capability using ordinary IP networks. Therefore, a need exists for techniques for augmenting a traditional broadcast service in an effective way, over unmanaged (and uncontrolled) IP infrastructure.

SUMMARY

According to one aspect of the present disclosure, a system and method for augmenting broadcast services with files based on groups of pictures (GOP) are provided. The system and method provide for receiving a first program content from a first communication medium (502), detecting an error in a segment of the first program content (506), the error causing a playback error if the segment is played, acquiring a replacement segment from a second communication medium (508), replacing the segment containing the error data with the replacement segment (510), and playing the stored first program content including the replacement segment (514). The error may be corrupt data or missing data. In one embodiment, the replacement segment is a file based on at least one group of pictures (GOP). In other embodiments, the file-based GOP is employed for Picture in Picture (PiP) channel browsing or channel change. Methods are provided for processing program content into files based on at least one GOP.

BRIEF DESCRIPTION OF THE DRAWINGS

These, and other aspects, features and advantages of the present disclosure will be described or become apparent from the following detailed description of the preferred embodiments, which is to be read in connection with the accompanying drawings.

In the drawings, wherein like reference numerals denote similar elements throughout the views:

FIG. 1 is a block diagram of an exemplary system for delivering video content in accordance with the present disclosure;

FIG. 2 is a block diagram of an exemplary set-top box/digital video recorder (DVR) in accordance with the present disclosure;

FIG. 3 is a system diagram showing an exemplary data flow for augmenting broadcast services with file-based GOPs in accordance with an embodiment of the present disclosure;

FIG. 4 is a flow chart illustrating an exemplary method for generating a group of pictures (GOP) from broadcast program content in accordance with the present disclosure; FIG. 5 is a flow chart illustrating an exemplary method for replacing an error containing data segment or missing data segment of broadcast program content in accordance with the present disclosure; and

FIG. 6 is a flow chart illustrating an exemplary method for implementing fast channel change in accordance with the present disclosure. It should be understood that the drawings are for purposes of illustrating the concepts of the disclosure and is not necessarily the only possible configuration for illustrating the disclosure.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS It should be understood that the elements shown in the figures may be implemented in various forms of hardware, software or combinations thereof. Preferably, these elements are implemented in a combination of hardware and software on one or more appropriately programmed general-purpose devices, which may include a processor, memory and input/output interfaces. Herein, the phrase "coupled" is defined to mean directly connected to or indirectly connected with through one or more intermediate components. Such intermediate components may include both hardware and software based components.

The present description illustrates the principles of the present disclosure. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the disclosure and are included within its spirit and scope.

All examples and conditional language recited herein are intended for pedagogical purposes to aid the reader in understanding the principles of the disclosure and the concepts contributed by the inventor to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions. Moreover, all statements herein reciting principles, aspects, and embodiments of the disclosure, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future, i.e., any elements developed that perform the same function, regardless of structure. Thus, for example, it will be appreciated by those skilled in the art that the block diagrams presented herein represent conceptual views of illustrative circuitry embodying the principles of the disclosure. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudocode, and the like represent various processes which may be substantially represented in computer readable media and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.

The functions of the various elements shown in the figures may be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. Moreover, explicit use of the term "processor" or "controller" should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor ("DSP") hardware, read only memory ("ROM") for storing software, random access memory ("RAM"), and nonvolatile storage. Other hardware, conventional and/or custom, may also be included. Similarly, any switches shown in the figures are conceptual only. Their function may be carried out through the operation of program logic, through dedicated logic, through the interaction of program control and dedicated logic, or even manually, the particular technique being selectable by the implementer as more specifically understood from the context.

In the claims hereof, any element expressed as a means for performing a specified function is intended to encompass any way of performing that function including, for example, a) a combination of circuit elements that performs that function or b) software in any form, including, therefore, firmware, microcode or the like, combined with appropriate circuitry for executing that software to perform the function. The disclosure as defined by such claims resides in the fact that the functionalities provided by the various recited means are combined and brought together in the manner which the claims call for. It is thus regarded that any means that can provide those functionalities are equivalent to those shown herein.

The present disclosure provides a system and method for augmenting broadcast services with files containing at least one GOP. A GOP is a collection of information that forms the base of most video compression schemes. Starting with a reference frame and containing a series of related frames, a GOP or collection thereof may be used for a range of purposes such as increasing channel change speed, augmenting packet loss, providing keys sections for trick modes, etc. The present disclosure defines a mechanism whereby GOPs, in addition to being broadcast by traditional means, are also created as a series of files and made available on standard internet infrastructure (such as web servers, content delivery networks (CDNs), etc) or peer-to-peer (P2P) services, such that the data the GOP contains could be utilized easily for various purposes, e.g., replacing lost data of a broadcast. Additionally, it may be possible to use the same mechanism to create lower data rate versions of the same content and use this data to generate Picture in Picture (PiP) streams as required.

Initially, systems for delivering various types of content to a user will be described. Subsequently, a method for augmenting broadcast services with files containing at least one GOP in accordance with embodiments of the present disclosure will then be detailed.

Turning now to FIG. 1 , a block diagram of an embodiment of a system 100 for delivering content, e.g., program content, to a home or end user is shown. The content originates from a content source 102, such as a movie studio or production house. The content may be supplied in at least one of two forms. One form may be a broadcast form of content. The broadcast content is provided to the broadcast affiliate manager 104, which is typically a national broadcast service, such as the American Broadcasting Company (ABC), National Broadcasting Company (NBC), Columbia Broadcasting System (CBS), etc. The broadcast affiliate manager may collect and store the content, and may schedule delivery of the content over a deliver network, shown as delivery network 1 (106). Delivery network 1 (106) may include satellite link transmission from a national center to one or more regional or local centers. Delivery network 1 (106) may also include local content delivery using local delivery systems · such as over the air broadcast, satellite broadcast, or cable broadcast. The locally delivered content is provided to a user's set top box/digital video recorder (DVR) 108 in a user's home.

The program content may be delivered to and processed at a repository 1 10, e.g., at least one server. As will be described below, program content will be processed, broken down and stored as discrete files of at least one GOP in length in the repository 10. The repository 1 10 may deliver content or GOPs to the user's set top box/digital video recorder 108 over a separate delivery network, delivery network 2 (1 12). Delivery network 2 (1 12) may include high-speed broadband Internet type communications systems. It is important to note that the content from the broadcast affiliate manager 104 may also be delivered using all or parts of delivery network 2 (1 12) and content from the file-based GOP repository 1 10 may be delivered using all or parts of delivery network 1 (106). In addition, a user may also obtain content directly from the Internet via delivery network 2 (112) without necessarily having the content come from the file-based GOP repository 1 10. Furthermore, it is possible that the file-based GOP repository 1 10 be populated from the broadcast affiliate manager 104 rather than the content source 102.

The set top box/digital video recorder 108 may receive different types of content from one or both of delivery network 1 and delivery network 2. The set top box/digital video recorder 108 processes the content, and provides a separation of the content based on user preferences and commands. The set top box/digital video recorder may also include a storage device, such as a hard drive or optical disk drive, for recording and playing back audio and video content. Further details of the operation of the set top box/digital video recorder 108 and features associated with playing back stored content will be described below in relation to FIG. 2. The processed content is provided to a display device 1 14. The display device 1 14 may be a conventional 2-D type display or may alternatively be an advanced 3-D display. It should be appreciated that other devices having display capabilities such as wireless phones, PDAs, computers, gaming platforms, remote controls, multi-media players, or the like, may employ the teachings of the present disclosure and are considered within the scope of the present disclosure.

Turning now to FIG. 2, a block diagram of an embodiment of the core of a set top box/digital video recorder 200 is shown. The device 200 shown may also be incorporated into other systems including the display device 1 14 itself. In either case, several components necessary for complete operation of the system are not shown in the interest of conciseness, as they are well known to those skilled in the art.

In the device 200 shown in FIG. 2, the content is received in an input signal receiver 202. The input signal receiver 202 may be one of several known receiver circuits used for receiving, demodulation, and decoding signals provided over one of the several possible networks including over the air, cable, satellite, Ethernet, fiber and phone line networks. The desired input signal may be selected and retrieved in the input signal receiver 202 based on user input provided through a control interface (not shown). It is to be appreciated that the input signal receiver 202 may in certain embodiments be a transceiver for two way communication to and from the set top box/digital video recorder 200. In certain embodiments, the transceiver will output information, e.g., a search request to delivery network 2 (1 12) to search for a particular GOP.

The decoded output signal from the input signal receiver 202 is provided to an input stream processor 204. The input stream processor 204 performs the final signal selection and processing, and is responsible for interfacing with a managed buffer 205 where content is buffered for playback. The input stream goes into the input stream processor 204 and is written out to the managed buffer 205. Then, the managed buffer 205 feeds back into the input stream processor 204 where a signal is output to the audio and video processors 206, 210.

The signal processing of the input stream processor 204 includes separation of video content from audio content for the content stream. The audio content is provided to an audio processor 206 for conversion from the received format, such as compressed digital signal, to an analog waveform signal. The analog waveform signal is provided to an audio interface 208 and further to the display device 1 14 or an audio amplifier (not shown). Alternatively, the audio interface 208 may provide a digital signal to an audio output device or display device using a High-Definition Multimedia Interface (HDMI) cable or alternate audio interface such as via a Sony/Philips Digital Interconnect Format (SPDIF). The audio processor 206 also performs any necessary conversion for the storage of the audio signals. The video output from the input stream processor 204 is provided to a video processor 210. The video signal may be one of several formats. The video processor 210 provides, as necessary a conversion of the video content, based on the input signal format. The video processor 210 also performs any necessary conversion for the storage of the video signals.

A storage device 212 stores audio and video content received at the input. The storage device 212 allows later retrieval and playback of the content under the control of a controller 214 and also based on commands, e.g., navigation instructions such as fast-forward (FF) and rewind (Rew), received from a user interface 216. The storage device 212 may be a hard disk drive, one or more large capacity integrated electronic memories, such as static random access memory, or dynamic random access memory, or may be an interchangeable optical disk storage system such as a compact disk drive or digital video disk drive. The converted video signal, from the video processor 210, either originating from the input or from the storage device 212, is provided to the display interface 218. The display interface 218 further provides the display signal to a display device of the type described above. The display interface 2 8 may be an analog signal interface such as red-green-blue (RGB) or may be a digital interface such as High Definition Multimedia Interface (HDMI).

The controller 214 is interconnected via a bus to several of the components of the device 200, including the input stream processor 202, audio processor 206, video processor 210, storage device 212, and a user interface 216. The controller 214 manages the conversion process for converting the input stream signal into a signal for storage on the storage device or for display. The controller 214 also manages the retrieval and playback of stored content. Furthermore, as will be described below in relation to FIG. 3, the controller 214 determines whether at least one GOP is necessary for augmenting broadcast content. The controller 214 is further coupled to control memory 220 (e.g., volatile or non-volatile memory, including random access memory, static RAM, dynamic RAM, read only memory, programmable ROM, flash memory, EPROM, EEPROM, etc.) for storing information and instruction code for controller 214. Further, the implementation of the memory may include several possible embodiments, such as a single memory device or, alternatively, more than one memory circuit connected together to form a shared or common memory. Still further, the memory may be included with other circuitry, such as portions of bus communications circuitry, in a larger circuit.

To operate effectively, the user interface 216 of the present disclosure employs an input device. In one embodiment, the input device is a remote controller, with a form of motion detection, such as a gyroscope or accelerometer, which allows the user to move a cursor freely about a screen or display. In another embodiment, the input device is a controller in the form of a touch pad or touch screen remote that takes movements on the user's finger and translates this to the position of a cursor on the screen, or alternatively be used to provide a virtual keyboard. In other embodiments, the controller may include a full keyboard for typing search entries. Other types of input devices such as conventional remotes, wireless devices such as phones and PDAs, motion capture devices or the like are also considered within the scope of the present disclosure.

A method for augmenting broadcast services with file based GOP in accordance with the present disclosure will now be described in relation to FIGs. 3-6, where FIG. 3 illustrates an overall flow diagram of the system and methods described herein. Initially, in 301 of FIG. 3, the broadcast program content is processed, broken down and managed on at least one server, the details of which will be described in relation to FIG. 4. A service will be implemented to take the broadcast stream and break it into the files. Program content broadcast from content source 302 is ingested, at step 402, to be broken down into GOPs. In step 404, detection of GOP boundaries may be executed through a number of mechanisms including pre-tagging and service information (SI) data in the broadcast stream, or examining a combination of tags in the stream itself such detecting a video payload in the Transport stream, then, depending on the codec and wrapping of the video payload, looking for reference frame indicators in the video stream itself, such as the alignmentjype indicator in a Motion Picture Experts Group-2 (MPEG-2) Program Elementary Stream. In step 406, a file is created for each GOP detected. In step 408, an identifier, or name, is generated for each file of GOPs. The files including the GOPs are then stored on server(s) 310, in step 410.

Each file has a commonly defined naming and location scheme based on a sequence, channel and approximate timestamp such that a client, e.g., set top box 308, could easily identify the right GOP file required. A back end process at server(s) 310 creates and manages the GOP files such that they are only available for an appropriate amount of time (depending on the application), and that capacity is always available. Clients could access files via regular Hyper Test Transfer Protocol (HTTP), which means that the system is capable of benefiting from network caches for scalability, or could also be delivered in a number of different ways, such as via P2P mechanisms, or other means. Having these GOP based files or "chunks" available starting with a reference frame would allow the files to either be used in loss recovery, for PiPs or as a Fast Channel Change mechanism as described above.

In one embodiment, each chunk would be named according to a standard, using a common reference time-stamp that could be queried from the set top box 308 in order to know what chunks to receive. These chunks could be individually sequenced and stored indefinitely for later use for "catch up TV/Network DVR" type services, indexed off a separate server, compiled in to a set representing a "Program", or alternatively, if the files are not being used to go back in time, they could be replaced sequentially so that there are only a small number of chunks available at any one time.

As the system of the present disclosure may have many embodiments, any implementation will, by definition, have a reasonably close coupling between the head end and clients, e.g., the content source and set top boxes, respectively. That is, in order for the system to operate, whatever mechanism that is adopted at the head end must also be supported at the client. Thus, there are several possibilities for naming files depending on the requirements of the implementation. In one embodiment, the general files would be named in the following format: CCCDDMMYYTNNNNNN where:

CCC represents a 3 digit Channel number

DDMMYY represents the date and time

T is the time period with the day (e.g. day is broken into 4 x 6 hour periods) NNNNNN is the GOP counter in that time period.

In using Time periods within a day, the GOP Counter can be contained to be a 16 bit counter. For a traditional broadcast service with Vz second minimum GOPs, there will be at least 7200 per hour, meaning that the 65535 GOPs allowed by a 16 bit counter should be sufficient for a 6 hour period.

In another embodiment, in addition to the standard file names created, additional files may also be created for specific purposes such as PiP. In this instance, the data rate and resolution of the files would likely be lower than the main video stream, and the file names would therefore need to be different to identify this. In one embodiment, the naming convention could be the same as that described above, with an extension to identify it as a PiP (e.g. PiP appended to the end of the existing file name).

In addition to the GOP files, a small index file will also be created and constantly updated with the current state information for each channel, step 412. The file could be titled CCC.idx, for example, where CCC is the channel, and this file contains information about the current state of the channel such as the current timestamp, Real Time Protocol (RTP) sequence number containing the GOP start and current GOP File counter. The index file may also contain the current and a number of previous filenames in the sequence as is required, in addition to the file sizes of each of these files. In this way, with a simple transaction, a client, e.g., set top box 108, 200 can gain the current state of a channel, knowing which files to ask for in which order, and where to position the data in the buffer to, for example, effect a fast channel change or loss recovery, by only getting a very small amount of information from the server.

In a more complex environment where the GOP files are kept for a longer period, more comprehensive index files may also be created for each time period or on a periodic basis including start and ending RTP sequences in relation to GOP sequence numbers, and may also include additional information such as program start and end markers, ad break markers, etc, to allow a client device to know what files to ask for. Index files should also follow a similar naming convention to the rest of the files such as CCCDDMMYYT.idx where idx indicates this is an index file, CCC represents a 3 digit Channel number, DDMMYY represents the date, "T" is the time period with the day. For some embodiments, it may be appropriate to create index files on a more regular basis (e.g., 1 for each hour), then have an additional master index for the day, for example, that is updated as the day progress to refer to sub- indexes.

In further embodiments, there could also be multiple different data rate (and potentially) versions of the GOP based files created that could be linked and used as PiPs as required. These lower data rate/resolution streams could also potentially be used for loss recovery and channel change speed augmentation of the main stream with lower quality. Note that all these solutions are predicated on the client, e.g., set top box 308, having a relatively deep, managed buffer of content (e.g. > 2 seconds) so that loss may be detected, and packets or chunks of data can be requested and recovered before reaching the point where the content is played out. If HTTP is used, in terms of file transfer, a request for an incomplete file from a web server will result in the transfer of the available information and the continuation of that transfer as the rest becomes available. In this way, files do not have to be complete on the web server before delivery.

A method for replacing an error or missing data segment of broadcast program content in accordance with the present disclosure will now be described in relation to FIGs. 3 and 5, where FIG. 5 is an exemplary method being performed in the set top box 108, 200.

Initially, a content source 302 will broadcast program content 304 to set top box 308. The program content 304 includes at least one GOP 306. As opposed to the embodiment where the program content is stored as GOPs before broadcasting, in one embodiment, the program content 304 is also transmitted to at least one server 310, where the content 304 is processed, broken down to chunks of data or files and managed on the servers 310, as described above. The chunks of data are stored on the server 310 as essentially uniquely identifiable files, based on individual GOPs, or at the most a small number of GOPs, though always starting with a reference frame. In this embodiment, a small delay (1 -3 seconds for example), in the broadcast may be introduced to give more time for the GOPs to be available as files on the network. Regardless of any network delay, however, a buffer of at least a few seconds will be required at the client, e.g., set top box 308, in order to a) recognize that there has been a loss of data and b) be able to get the new data from the network in time to recover from loss.

As the program content signal is being delivered 303, the set top box 308 receives (step 502) the first program content from a first communication medium, e.g., a broadcast medium 305, and writes the data to the managed buffer 205 and/or stores the first program content in the local storage device 212 for future playback (step 504). The input stream processor 204 of the set top box then may detect (307, step 506) an error or missing data in a segment of the stored first program content, the detected error or missing data causing a playback error if the segment is played.

The software in the set top box 108, 200 contains a mechanism to manage the state of the buffer and determine if information is missing. This may be achieved through a periodic (such as every 100-200ms) assessment of the queue of numbered packets in the managed buffer 205. Detection of a hole relies on data chunks being stored in a numbered form (such as when using the Real Time Protocol (RTP) to encapsulate the transport stream in IP), such that missing data is represented by a sequence number gap. For IP, RTP assigns a sequence number to up to 7 x 188 byte Transport stream packets encapsulated in a single IP packet. In this instance, each RTP Packet is sequence numbered with a 16 bit counter, and any loss can therefore be easily detected. While the PEG-2 transport packet counter could be used, the fact that the continuity counter it is only 4 bits means that errors may be missed on a relatively frequent basis (such as those that are multiples of 16 packets long), and even in the event that an error is detected through a discontinuity, it will be unclear how many packets have gone missing.

Another advantage of using RTP is that it provides for independent timing data of the packets and provided mechanisms to determine a clock reference. This may be significant in the event that the system is to be used for retrieval of data other than simply the current or previous files as defined in the current index.

There are a number of other possible ways the loss detection mechanisms may be implemented, depending on the structure and format of the encapsulated video stream. Essentially, all mechanisms will rely on a fixed amount of data that has an associated sequence number generated at the head end, that is broadcast along with the data from the head end, or more likely included as part of the encapsulation process (as it is with RTP). Then, when the input stream processor 204 receives data, it is placed into the managed buffer 205 in a position based on this sequence group and any sequence gaps can be identified in this manner, and be of a known fixed length (including padding if necessary).

If an error is detected, the input stream processor 204 of the set top box will acquire (309, step 508) a replacement segment from a second communication medium, e.g., the Internet. There are several possible mechanisms for the set top box to identify the appropriate file to request, and these mechanisms may be used in parallel depending on circumstances within the system. In one instance, the current GOP file counter (and/or filename) may be broadcast as additional data in the broadcast stream, i.e. be constantly be updated as part of the SI data broadcast along with the stream. This could be either constant (i.e. updated as each file is created), or periodic, and allows the client to essentially do the counting of the file boundaries as the content enters the set top box 308. While data could be separated for each channel, if the video on each channel had synchronized, fixed GOP values, then the current GOP value for each channel would be the same, and would always be reset exactly at the Time interval marker for each day. In a more likely scenario, each channel would have a slightly different GOP count. In this instance, in the event of changing channel, rather than relying on the current constantly updated values in the stream, indexes for each channel will be accessible via the network upon request by the client.

Referring now to FIG. 2, it is part of the role of the input stream processor 204 to monitor both the current GOP counter (for file referencing), and also the smaller packet group counter used for detecting loss within the managed buffer. When the GOP counter is incremented, the system will both broadcast both the GOP counter and the packet group counter corresponding with the start of the GOP. This may be broadcast several times over the duration of the GOP, and/or be contained in the index files maintained on the server. In this way, if the input stream processor 204 finds it is missing sequences, it can get the index file from the server and find which GOP these missing sequences belong to. Also, given that the numbered packet sequences are of fixed size, the clients may also use byte offsets from the main file reference to get explicitly the lost packets only, or the whole GOP/file as required.

Referring again to FIGs. 3 and 5, in response to the request from the set top box 308, the server 310 will deliver 311 the GOP to the set top box 308. The input stream processor 204 will then replace (313, step 510) the segment containing the error or missing data with the replacement segment. Upon receiving a playback request (step 512) the set top box will play the stored first program content including the replacement segment (step 514) either from the managed play-out buffer 205 or local storage device 212. A method for implementing fast channel change of broadcast program content in accordance with the present disclosure will now be described in relation to FIG. 6. For fast channel change, the same concepts could be applied, using the l-Frame PiP stream to provide instant video feedback, and provide a reference from which the full resolution image can be built. This could provide an impression of almost instant channel change, though the resolution and image quality would be poor until the system decoded a full-resolution, full quality l-frame.

Initially, in step 602, first program content received via a broadcast medium is played or view by a user. During normal playback of program content, the controller 214 of the set top box generates a signal for playing the program content as described above. Upon receiving the channel change request from the user via user interface 216 to view second program content, in step 604, the software in the controller 214 of set top box 108, 200 would request the current index file from a known server, step 606. This index would take the form of a small text file that contained the current information for that channel. As soon as the controller 214 received the index file via the input signal receiver 202, the controller 214 would determine an appropriate at least one file of GOP based on the index, step 608. In step 610, the controller 214 would request the appropriate file (determined from this index) from the network to begin populating the managed buffer 205 at the appropriate point.

The actual file(s) selected for download is determined by several factors including the size of the buffer 205 in the set top box 108, 200 (i.e. how far behind of real time the set top box 108, 200 needs to be), the speed of the broadband or IP network by which the customer is connected, and the data rate and nature of the file used for fast channel change. For the size of the buffer, if the set top box 108, 200 require a 3 second buffer, for example, as defined by the service, the set top box 108, 200 will need to begin download of files with a starting time approximately 3 seconds behind the current time. In the case of an implementation with V2 second GOPs, this may be 6 files prior the current file being written. The assumption is also that the buffer will be filled faster than real time and this must also be monitored, as the set top box 108, 200 cannot begin playing out the content, despite it starting with a reference frame, until there is confidence that there is sufficient data in the buffer so as not to cause a buffer under-flow.

In one embodiment, multiple different files may be created with different data rates and, based on either user configuration or dynamic observation of network performance, the set top box 108, 200 chooses which file is most appropriate to start populating the buffer. The system may, for example be hard coded to always select a particular low data rate file to begin buffer population, assuming that high bandwidth may not be available. Alternatively, periodic tests may be performed by the client or set top box, independent of the current video streams, where a known amount of data is retrieved from the server, the time taken to do so is measured and the bandwidth available is assumed based on the periodic tests. In another possible embodiment, the client or set top box may always start the connection assuming a low bandwidth, then, based on the actual performance achieved for the first file or part thereof, increase the rate for subsequent files. It should be noted that any combination of these embodiments is considered within the scope of the disclosure.

In parallel with the beginning of data downloading, the set top box 108, 200 will also begin receiving data via the broadcast via the input signal receiver 202, in step 612, and this data will also begin to be added to the buffer 205 at the appropriate point, leaving room for the IP delivered information. This data may be either be added to a secondary buffer (not shown) then merged or combined with the primary buffer when the information is available as to the appropriate buffer position. Alternatively, with the fixed number of packets defined in the index file, the broadcast can be written directly to the appropriate position in the buffer 205. The set top box 108, 200 will cease requesting any more files once the buffer position of the end of the files overlaps with the information already in the buffer. In the event the data rate (or even possibly the resolution of the stream) is lower than the broadcast, the system will automatically scale the video to be full resolution, and the user may still experience a fast channel change, though at a lower quality than the normal viewing. Once the decoder reaches the point in the buffer where the broadcast content is stored, the quality will return to normal. In starting each file, and therefore the buffer population with a reference frame, the set top box will begin playing out of the buffer quite quickly (step 614), particularly in an instance where the network connection rate allows files to be delivered significantly faster than real time. When bandwidth is available that is significantly greater than the bandwidth required by the stream, multiple files may also be requested in parallel to further increase the rate at which the buffer is filled.

It is to be appreciated that the above technique for acquiring the second program content may also be employed for PiP, where the first and second content are displayed simultaneously, e.g., where the first program content is displayed full screen on display device 1 14 and the second program content being displayed on a small portion of the full screen.

Although embodiments which incorporate the teachings of the present disclosure have been shown and described in detail herein, those skilled in the art can readily devise many other varied embodiments that still incorporate these teachings. Having described preferred embodiments of a system and method for augmenting broadcast services with file based GOP(which are intended to be illustrative and not limiting), it is noted that modifications and variations can be made by persons skilled in the art in light of the above teachings. It is therefore to be understood that changes may be made in the particular embodiments of the disclosure disclosed which are within the scope of the disclosure as outlined by the appended claims.

Claims

1. A method for processing program content, the method comprising: receiving a first program content from a first communication medium (502); detecting an error in a segment of the first program content, the error causing a playback error if the segment is played (506); acquiring a replacement segment from a second communication medium

(508); replacing the segment containing the error with the replacement segment (510); and playing the first program content including the replacement segment (514).

2. The method of claim 1 , further comprising storing the first program content (504) in a local storage device for future playback.

3. The method of claim 1 , further comprising, upon receiving the first program content, buffering the first program content (504) while performing the detecting step.

4. The method of claim 1 , wherein the first communication medium is a broadcast medium.

5. The method of claim 4, wherein the second communication medium is an internet protocol network.

6. The method of claim 1 , wherein the detecting step further comprises periodically assessing number-ordered packets of the received first program content.

7. The method of claim 1 , wherein the replacement segment is at least a portion of a file based on at least one group of pictures.

8. The method of claim 7, wherein the acquiring (508) the replacement segment further comprises: receiving a group of pictures file counter with the first program content from the first communication medium; determining the at least one group of pictures of the replacement segment based on the group of pictures file counter; and requesting at least a portion of the determined at least one group of pictures from at least one predetermined server.

9. A method for processing program content, the method comprising: playing a first program content received from a first communication medium

(602); receiving a request to view a second program content (604); acquiring at least one segment of the second program content from a second communication medium (610); receiving the second program content from the first communication medium

(612); combining the acquired at least one segment of the second program content with the received second program content (612); and playing the combined second program content (614).

10. The method of claim 9, wherein the at least one segment is at least a portion of a file based on at least one group of pictures.

11. The method of claim 9, wherein the request is a channel change request.

12. The method of claim 1 , further comprising: acquiring current channel information for the second program content requested (606); and determining the at least one segment of the second program content from the current channel information (608).

13. The method of claim 12, wherein the determining the at least one segment of the second program content further comprises selecting a data rate of the at least one segment based on performance of the second communication medium.

14. The method of claim 9, wherein the first program content and the combined second program content are simultaneously displayed.

15. A system for processing program content comprising: a signal receiver (202) that receives a first program content from a first communication medium; an input stream processor (204), coupled to the signal receiver (202), that detects an error in a segment of the first program content, the error causing a playback error if the segment is played; the input stream processor (204) acquires a replacement segment from a second communication medium and replaces the segment containing the error with the replacement segment; and the input stream processor (204) generates a signal for playing the first program content including the replacement segment.

16. The system of claim 15, further comprising a storage device (212), coupled to the input stream processor (204), that stores the first program content for future playback.

17. The system of claim 15, further comprising a buffer (205), coupled to the input stream processor, that buffers the first program content.

18. The system of claim 5, wherein the first communication medium is a broadcast medium.

19. The system of claim 18, wherein the second communication medium is an internet protocol network.

20. The system of claim 15, wherein the input stream processor (204) periodically assesses number-ordered packets of the received first program content to detect the error.

21. The system of claim 15, wherein the replacement segment is at least a portion of a file based on at least one group of pictures.

22. The system of claim 21 , wherein the input signal receiver (202) receives a group of pictures file counter with the first program content from the first

communication medium and the input stream processor (204) determines the at least one group of pictures of the replacement segment based on the group of pictures file counter and requests at least a portion of the determined at least one group of pictures from at least one predetermined server (310).

23. A system for processing program content comprising: a controller (214) that generates a signal for playing a first program content received from a first communication medium; a user interface (216), coupled to the controller (214), that receives a request to view a second program content; the controller (214) acquires at least one segment of the second program content from a second communication medium; the receiver (202) receives the second program content from the first communication medium; and the controller (2 4) combines the acquired at least one segment of the second program content with the received second program content and generates a signal for playing the combined second program content.

24. The system of claim 23, wherein the at least one segment is at least a portion of a file based on at least one group of pictures.

25. The system of claim 23, wherein the request is a channel change request.

26. The system of claim 25, wherein the controller (214) acquires current channel information for the channel requested and determines the at least one segment of the second program content from the current channel information.

27. The system of claim 23, wherein the controller (214) selects a data rate of the at least one segment based on performance of the second communication medium.

28. The system of claim 23, wherein the first program content and combined second program content are simultaneously displayed.

29. A method for processing program content, the method comprising: processing a first program content (402); detecting at least one group of pictures in the first program content (404); creating a file for each detected at least one group of pictures (406); and storing the file for each detected at least one group of pictures with an identifier (410).

30. The method of claim 29, further comprising generating an index file for each channel of a first communications medium (412), wherein each index file indicates at least one stored file of at least one group of pictures for the channel.

31. The method of claim 30, further comprising: receiving the first program content from the first communication medium (502); detecting an error in a segment of the first program content (506), the error causing a playback error if the segment is played; acquiring at least one of the stored group of pictures files from a second communication medium to replace the segment containing the error (508); replacing the segment containing the error with the archived at least one group of pictures file (510); and playing the first program content including the at least one replacement group of pictures file (514).

32. The method of claim 31 , wherein the acquiring step further comprises: acquiring the index file for the channel delivering the first program content; and determining the at least one stored group of pictures file to replace the segment containing the error from the acquired index file.

33. The method of claim 31 , wherein the first communication medium is a broadcast medium.

34. The method of claim 33, wherein the second communication medium is an internet protocol network.

35. The method of claim 30, further comprising: playing the first program content received from the first communication medium; receiving a request to view a second program content (602); acquiring at least one of the stored group of pictures files from a second communication medium (610), the acquired group of pictures file containing a portion of the second program content; receiving the second program content from the first communication medium

(612); combining the acquired group of pictures file with the received second program content (612); and playing the combined second program content (614).

36. The method of claim 35, further comprising: acquiring the index file for the channel requested (606); and determining the at least one stored group of pictures file from the index file (608).

37. The method of claim 35, wherein the first program content and combined second program content are simultaneously displayed.