US 20070226767 A1
Systems and methods are provided for managing a time-shift buffer (TSB) that is used for buffering video presentations. One such method includes receiving user input identifying a storage capacity for the TSB and modifying a storage capacity of the TSB such that it is at least substantially equal to the storage capacity identified by the user input.
1. A method for determining a size of a time-shift buffer (TSB) that is used for buffering video presentations, the method comprising:
receiving user input identifying a storage capacity for the TSB; and
modifying a storage capacity of the TSB such that it is substantially equal to the storage capacity identified by the user input.
2. The method of
3. The method of
4. The method of
managing a storage capacity of the TSB such that it is not substantially different from the storage capacity identified by user input.
5. The method of
managing the TSB such that it does not contain an amount of data that substantially exceeds the storage capacity identified by the user input.
6. The method of
7. A digital home communication terminal (DHCT) comprising:
a time-shift buffer (TSB); and
a processor that is programmed to modify a storage capacity of the TSB such that it is substantially equal to the storage capacity identified by a user input.
8. The DHCT of
manage a storage capacity of the TSB such that it is not substantially different from the storage capacity identified by user input.
9. The DHCT of
manage the TSB such that it does not contain an amount of data that substantially exceeds the storage capacity identified by the user input.
10. The DHCT of
11. A method for determining a size of a time-shift buffer (TSB) that is used for buffering video presentations, the method comprising:
receiving user input identifying a storage capacity for the TSB;
modifying a storage capacity of the TSB such that is substantially equal to the storage capacity identified by the user input;
assigning additional storage capacity to the TSB; and
managing the TSB such that it does not contain an amount of data that substantially exceeds the storage capacity identified by the user input,
wherein the TSB corresponds to a portion of a hard disk.
This application is a divisional of copending U.S. utility application having Ser. No. 10/143,647, filed May 10, 2002, which claims priority to U.S. provisional application having Ser. No. 60/290,315, filed on May 11, 2001, both of which are entirely incorporated herein by reference. Furthermore, this application is related to copending U.S. utility patent application having Ser. No. 10/143,123, filed May 10, 2002, which is entirely incorporated herein by reference.
The invention is generally related to television systems, and, more particularly, is related to buffering video presentations.
Subscriber television systems are now capable of providing many services in addition to analog broadcast video. In implementing enhanced programming, the home communication terminal (“HCT”), otherwise known as the settop box, has become an important computing device for accessing various video services. In addition to supporting traditional analog broadcast video functionality, digital HCTs (or “DHCTs”) now also support an increasing number of two-way digital services such as video-on-demand.
A DHCT is typically connected to a cable or satellite television network and includes hardware and software for providing various services and functionality. In some systems, software executed by a DHCT can be downloaded and/or updated via the subscriber television network. The ability to download software provides flexibility in adding or updating applications executed by the DHCT. Each DHCT also typically includes a processor, communication components and memory, and is connected to a television. While many conventional DHCTs are stand-alone devices that are externally connected to a television, a DHCT and/or its functionality may be integrated into a television or other display device, as will be appreciated by those of ordinary skill in the art.
Some DHCTs include mechanisms for buffering a video presentation, including while it is being presented to a viewer. This buffering functionality allows a viewer to manipulate the video presentation using trick mode operations such as rewind, fast-forward, pause, and play. One problem with buffering functionality offered by current DHCTs is that the buffering capacity is fixed. When a viewer is presented with video presentations comprising data that exceeds the fixed buffering capacity, a portion of the previously buffered data is erased or over-written in order to accommodate the buffering of new data. For some users, the buffering capacity offered by a DHCT is more than satisfactory. However, other users may desire additional buffering capacity. For example, viewers that typically watch longer video presentations (e.g., 3 hour movies) may have a greater need for a larger buffer capacity than viewers that typically watch shorter video presentations (e.g., 30 minute sit-coms). Another problem with buffering functionality offered by DHCTs is that viewers may have different preferences regarding buffered video presentations. For example, viewers may have different preferences regarding whether buffered video presentations corresponding to previously displayed television channels should continue to be accessible after a change in television channels. Based on the foregoing, there exists a need for systems and methods that address these and/or other problems associated with buffering video presentations.
Embodiments of the invention can be better understood with reference to the following drawings. The components in the drawings are not necessarily drawn to scale, emphasis instead being placed upon clearly illustrating the principles of the invention. In the drawings, like reference numerals designate corresponding parts throughout the several views.
The preferred embodiments of the invention now will be described more fully hereinafter with reference to the accompanying drawings. In particular, preferred embodiments of managing time-shift buffers (TSBs) will be described. A TSB comprises storage media that is used for buffering audio and/or video (A/V) data. The buffering of A/V data allows a user of a digital home communication terminal (DHCT) to perform trick mode operations on a television presentation that is currently being broadcast. Such trick mode operations may include pause, fast-rewind, fast-forward, slow-reverse, slow-forward, and/or play. In one embodiment of the invention, a user is provided with systems for managing one or more TSBs. Where more than one TSB is used in a DHCT, each TSB typically buffers A/V data that is output by a respective tuner. In one embodiment, a TSB may buffer AN data that is received by the DHCT from a consumer electronics device such as, for example, a camcorder. The consumer electronics device may be connected to the DHCT via a wired or wireless port. In the description that follows,
The DHCT 200 further preferably includes at least one processor 244 for controlling operations of the DHCT 200, an output system 248 for driving the display device 140, and a tuner system 245 for tuning to a particular television channel or frequency and for sending and receiving various types of data to/from the headend 110. In one embodiment, the output system 248 may be part of the media engine 222. Tuner system 245 can select from a plurality of transmission signals provided by the subscriber television system 100. Tuner system 245 enables the DHCT 200 to tune to downstream media and data transmissions, thereby allowing a user to receive digital or analog media content via the subscriber television system. The tuner system 245 includes, in one implementation, an out-of-band tuner for bi-directional quadrature phase shift keying (QPSK) data communication and a quadrature amplitude modulation (QAM) tuner (in band) for receiving television signals. In one embodiment, the tuner system 245 includes a plurality of tuners for receiving a plurality of video streams.
The DHCT 200 may include one or more wireless or wired communication ports 274 for receiving and/or transmitting data to other devices. The communication ports 274 may include a USB (Universal Serial Bus), an Ethernet, an IEEE-1394 bus, an analog video input port, a serial port, and/or a parallel port, among others. In one embodiment, the DHCT 200 may receive A/V data from a consumer electronics device such as, for example, a camcorder, via one of the communication ports 274. The DHCT 200 may also include a receiver 246 for receiving externally-generated user inputs or commands from an input device such as, for example, a remote control.
The DHCT 200 includes at least one storage device 273 for storing video streams received by the DHCT 200. A PVR application 277, in cooperation with the operating system 253 and the device driver 211, effects, among other functions, read and/or write operations to the storage device 273. Note that, references herein to write and/or read operations to/from the storage device 273, or portions thereof, will be understood to mean that such operations are performed to/from the storage medium or media (e.g., hard disks) of the storage device 273, unless indicated otherwise. The device driver 211 is a software module that preferably resides in the operating system 253. The device driver 211, under management of the operating system 253, provides operating instructions to the storage device 273. The controller 279 of the storage device 273 receives operating instructions from the device driver 211 and implements those instructions to cause read and/or write operations to a hard disk 201 (i.e., hard disk 201-1 or hard disk 201-2). Furthermore, the device driver 211, in cooperation with the operating system 253, communicates with the storage device controller 279 to format and/or manipulate a hard disk 201.
The storage device 273 is preferably coupled to a common bus 205 through a communication interface 275. The communication interface 275 is preferably an integrated drive electronics (IDE) interface or a small computer system interface (SCSI), although another interface such as, for example, IEEE-1394 or USB, among others, may be used. Alternatively, the storage device 273 can be externally connected to the DHCT 200 via a communication port 274. The communication port 274 may be, for example, an IEEE-1394, a USB, a SCSI, or an IDE, among others.
In one implementation, video streams are received in DHCT 200 via communications interface 242 and stored in a temporary memory cache. The temporary memory cache may be a designated section of DRAM 252 or an independent memory attached directly to communication interface 242. The temporary cache is implemented and managed to enable media content transfers to storage device 273. In one implementation, the fast access time and high data transfer rate characteristics of the storage device 273 enable media content to be read from the temporary cache and written to storage device 273 in a sufficiently fast manner. Multiple simultaneous data transfer operations may be implemented so that while data is being transferred from the temporary cache to storage device 273, additional data may be received and stored in the temporary cache.
The storage device 273 preferably includes a hard disk drive but may, in an alternative embodiment, include any type of storage medium, such as, for example, a magnetic, optical, or semiconductor based storage medium, among others. The storage device 273 preferably includes at least two hard disks 201 -1 and 201-2 that include storage capacity corresponding to respective buffers TSB 204-1 and TSB 204-2. In an alternative embodiment, TSB 204-1 and TSB 204-2 may be included on a single hard disk. In another embodiment, a TSB 204 (i.e., TSB 204-1 or TSB 204-2) may reside in more than one storage medium. In yet another embodiment, a TSB 204 may reside in a storage medium that is not a hard disk.
In one embodiment of the invention, the operating system 253, device driver 211, and controller 279 cooperate to create a file allocation table (FAT). The FAT is where the operating system 253 stores information about hard disk clusters and the files associated with those clusters. The operating system 253 can determine where a file's data is located by using FAT entries. A FAT entry describes the physical locations of data for a video stream file (i.e., a file that the video stream is written to on a hard disk 201). The FAT also keeps track of which clusters are free, or open, and thus available for use. To buffer a downloaded video stream into the storage device 273, the PVR application 277, in one preferred embodiment, creates a file and file name for the video stream to be downloaded. The operating system 253, in cooperation with the device driver 211, checks the FAT for an available, or writable, cluster for storing the video stream.
When an application such as PVR application 277 creates (or extends) a video stream file, the operating system 253, in cooperation with the device driver 211, queries the FAT for an available cluster to begin writing the video stream. The PVR application 277 (through communication with the operating system 253 and/or device driver 211) causes the controller 279 to write a downloaded video stream to the available cluster under a particular video stream file name. The FAT is then updated with the new video stream file name corresponding to the available cluster. If the video stream requires more storage space than what the cluster can offer, the operating system 253 queries the FAT for the location of another available cluster to continue writing the video stream. The FAT is updated to keep track of which clusters store a particular video stream under the given video stream file name.
A multiplicity of clusters may be required to write a file corresponding to a compressed video stream to a hard disk 201. The clusters corresponding to one particular video stream file may or may not be adjacent or contiguous in the hard disk 201. The clusters corresponding to a particular video stream file can be fragmented throughout a hard disk storage space. As described earlier, a file allocation table (FAT) keeps track of which clusters are employed to write a downloaded video stream to a hard disk 201. A defragmentation operation may be used by the device driver 211 to cause the clusters associated with a particular video stream file to be contiguous. Other preferred embodiments include other file allocation mechanism for storing data according to the functions described herein.
The DHCT 200 preferably comprises a signal processing system 214 which includes a demodulating system 213 and a transport demultiplexing and parsing system 215 (herein referred to as demultiplexing system 215). The components of signal processing system 214 are preferably capable of QAM demodulation, forward error correction, demultiplexing MPEG-2 transport streams, and parsing elementary streams. One or more of the components of the signal processing system 214 can be implemented with software, a combination of software and hardware, or preferably in hardware.
The demodulating system 213 comprises functionality for demodulating analog or digital transmission signals. For instance, demodulating system 213 can demodulate a digital transmission signal in a carrier frequency that was modulated, among others, as a QAM-modulated signal. When tuned to a carrier frequency corresponding to an analog TV signal, demultiplexing system 215 is bypassed and the demodulated analog TV signal that is output by demodulating system 213 is instead forwarded to analog video decoder 216. Analog video decoder 216 converts the analog TV signal into a sequence of digitized pictures and their respective digitized audio. The digitized pictures and respective audio that are output by analog video decoder 216 are forwarded to the compression engine 217.
The compression engine 217 processes the sequence of digitized pictures and digitized audio and converts them into compressed video and audio streams, respectively. The compressed video and audio streams are produced in accordance with the syntax and semantics of a designated audio and video coding method, such as, for example, MPEG-2, so that they can be interpreted by video decoder 223 and audio decoder 225 for decompression and reconstruction at a future time. Each compressed stream consists of a sequence of data packets containing a header and a payload. Each header contains a unique packet identification code, or PID, associated with the respective compressed stream.
The compression engine 217 multiplexes the audio and video compressed streams into a transport stream, such as, for example, an MPEG-2 transport stream. Furthermore, the compression engine 217 can compress audio and video data corresponding to multiple video streams in parallel (e.g., multiple analog TV signals received by multiple tuners) and can multiplex the respective audio and video compressed streams into a single transport stream. The compression engine 217 may use a dedicated local memory module (not shown) for storing data before, during, and/or after processing by the compression engine 217. The compressed streams output by compression engine 217 are provided as input to signal processing system 214.
The demultiplexing system 215 of the signal processing system 214 interprets sequence and picture headers and annotates their locations within their respective compressed stream. Annotating the location of sequence and picture headers facilitates the implementation of trick mode operations on a compressed stream. An analog video stream (e.g., corresponding to a TV presentation) that is received via a tuned analog transmission channel can be output as a transport stream by signal processing system 214 and stored in storage device 273. A compressed stream may be also output by signal processing system 214 and presented as input to media engine 222. The video decoder 223 and the audio decoder 225 of the media engine 222 can decompress the compressed stream for subsequent output to the display device 140 (
The demultiplexing system 215 may include means for MPEG-2 transport demultiplexing. When tuned to carrier frequencies carrying a digital transmission signal, demultiplexing system 215 extracts data packets corresponding to desired video streams for further processing. Therefore, the demultiplexing system 215 may preclude further processing of data packets corresponding to unwanted video streams. The demultiplexing system 215 parses (i.e., reads and interprets) desired video streams to interpret sequence headers and picture headers, and deposits the video streams into DRAM 252. The processor 244 then causes the video streams to be transferred from DRAM 252 to the storage device 273.
A compressed video stream corresponding to a tuned carrier frequency carrying a 25 digital transmission signal can be output as a transport stream by signal processing system 214 and stored in storage device 273. A packetized compressed stream can also be output by signal processing system 214 and presented as input to media engine 222. The video decoder 223 and/or audio decoder 223 of the media engine 222 may decompress the compressed stream for subsequent output to the display device 140.
One having ordinary skill in the art will appreciate that signal processing system 214 may include other components not shown, including memory, decryptors, samplers, digitizers (e.g., analog-to-digital converters), and multiplexers, among others. Further, other embodiments will be understood, by those having ordinary skill in the art, to be within the scope of the preferred embodiments of the invention. For example, analog signals (e.g., NTSC) may bypass one or more elements of the signal processing system 214 and may be forwarded directly to the output system 248. In addition, data that is output by one DHCT component (e.g., signal processing system 214) may be temporarily stored in DRAM 252 prior to being received as input by another DHCT component (e.g., media engine 222 or analog video decoder 216). It will also be understood by those having ordinary skill in the art that components of signal processing system 214 can be located in different areas of the DHCT 200.
In one embodiment of the invention, a plurality of tuners and respective demodulating systems 213, demultiplexing systems 215, and signal processing systems 214 may simultaneously receive and process a plurality of respective broadcast digital video streams. Alternatively, a single demodulating system 213, a single demultiplexing system 215, and a single signal processing system 214, each with sufficient processing capabilities may be used to process a plurality of digital video streams that are received by a plurality of respective tuners.
In yet another embodiment, a first tuner in tuning system 245 receives an analog video signal corresponding to a first video stream and a second tuner simultaneously receives a digital compressed stream corresponding to a second video stream. The first video stream is converted into a digital format. The second video stream (or a compressed digital version thereof) is forwarded to the storage device 273 for storage on a hard disk 201. Data annotations for each of the two streams are performed to facilitate future retrieval of the video streams from the storage device 273. The first video stream and/or the second video stream may also be forwarded to media engine 222 for decoding and subsequent presentation via display device 140 (
A plurality of compression engines 217 may also be used to simultaneously compress a plurality of analog video streams. Alternatively, a single compression engine 217 with sufficient processing capabilities may be used to compress a plurality of analog video streams. Compressed digital versions of respective analog video streams may be forwarded to the storage device 273 for storage on a hard disk 201. Data annotations for each of the video streams may be performed to facilitate future retrieval of the video streams from the storage device 273. Depending on requirements in effect, only a subset of compressed video streams may be forwarded to the storage device 273. Any of the received video streams may also be simultaneously forwarded to media engine 222 for decoding and subsequent presentation via the display device 140.
Basic functionality of the DHCT 200 is provided by an operating system 253 that is primarily stored in flash memory 251. The operating system 253 includes at least one resource manager 350 that provides an interface to and coordination of resources of the DHCT 200 such as, for example, computing resources. One or more software applications, herein referred to as applications, are executed by utilizing the computing resources in the DHCT 200. Applications stored in flash memory 251 or DRAM 252 are executed by processor 244 under the auspices of the operating system 253. Data required as input by an application is stored in DRAM 252 or flash memory 251 and read by processor 244 as needed during the course of the application's execution. Input data may be data stored in DRAM 252 by a secondary application or other source, either internal or external to the DHCT 200. Data generated by an application is stored in DRAM 252 by processor 244 during the course of the application's execution.
An application referred to as navigator 360 is also resident in flash memory 251 for providing a navigation framework for services provided by the DHCT 200. The navigator 360 registers for and in some cases reserves certain user inputs related to remote control keys such as channel up/down, last channel, favorite channel, etc. A platform library 310 includes a collection of utilities useful to applications. Such utilities may include a timer manager, a compression manager, an HTML parser, a database manager, a widget toolkit, a string manager, and other utilities (not shown). These utilities are accessed by applications via application programming interfaces (APIs) as necessary so that each application does not have to incorporate these utilities. Two components of the platform library 310 that are depicted in
The window manager 330 provides a mechanism for implementing the sharing of the screen regions and user input. The window manager 330 is also responsible for, as directed by one or more applications, implementing the creation, display, and allocation of the limited DHCT 200 screen resources. The window manager 330 allows multiple applications to share the screen by assigning ownership of screen regions. The window manager 330 communicates with resource manager 350 to coordinate available resources (such as display memory) among different resource-consuming processes. Such processes may be directly or indirectly invoked by one or more applications.
The window manager 330 also maintains, among other things, a user input registry 365 in DRAM 252. The user input registry 365 may be accessed to determine which of various applications running on the DHCT 200 should receive data corresponding to a user input, and in which order. As an application is executed, it registers a request to receive certain user input keys or commands. When the user presses a key corresponding to one of the commands on the remote control device, the command is received by the receiver 246 and relayed to the processor 244. The processor 244 dispatches the event to the operating system 253 where it is forwarded to the window manager 330. The window manager 330 then accesses the user input registry 365 and routes data corresponding to the incoming command to the appropriate application.
The SAM client 320 is a client component of a client-server system, with the server component being located on the headend 110 (
Applications can be downloaded into DRAM 252 at the request of the SAM client 320, typically in response to a request by the user or in response to a message from the headend. In this non-limiting example, DRAM 252 contains a PVR application 277, an interactive program guide (IPG) application 370, and a video-on-demand (VOD) application 380. It should be clear to one with ordinary skill in the art that these applications are not limiting and merely serve as examples for this present embodiment of the invention. Furthermore, one or more DRAM 252 based applications may, as an alternative embodiment, be resident in flash memory 251, or vice versa.
The PVR application 277 provides user interface (UI) screens that assist the user in buffering, recording, and viewing video presentations. For instance, the PVR application 277 may be configured to provide the user with the UI screens depicted in
In a preferred embodiment, the PVR application 277 is implemented in software that is stored in a DRAM 252 and that is executed by processor 244. The PVR application 277, which may comprise an ordered listing of executable instructions for implementing logical functions, may be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, a processor-containing system, or another system that can fetch instructions from the instruction execution system, apparatus, or device and execute them.
The PVR application 277 provides for AN data storage functionality by enabling the temporary writing to, and if requested, long-term recording to the storage device 273. Through mechanisms explained below, AN data is buffered in a TSB 204 (i.e., TSB 204-1 or TSB 204-2). In accordance with a preferred embodiment, the PVR application 277 manages a TSB 204 at the application level for each tuner and/or a local device providing AN data. Hence, each tuner in tuner system 245 and/or local device attached to the DHCT 200 may have a respective TSB 204. Data that is buffered in a TSB 204 may have been received from a remote server via the subscriber television network 130 (
The AN data buffered in a TSB 204 may be retained (in response to user input) as a long-term recording or may be deleted as additional AN data is buffered. The AN data buffered in a TSB 204 may be deleted by, for example, deleting a TSB management file associated with the data and/or by designating the clusters storing the A/V data as writable (for eventual write operations that overwrite the A/V data within those clusters).
A long-term recording will be understood to comprise A/V data that is stored for an extended period of time as determined by the user. Long-term recordings are stored in clusters that are not assigned to a TSB 204. A long-term recording may be scheduled in advance of its broadcast time or may be achieved by selecting a video presentation buffered in a TSB 204 and designating it as a long-term recording. As will be described below, designating a video presentation as a long term recording can occur, in one implementation, by receiving user input selecting the video presentation from a list provided via a UI screen. The PVR application 277 responds by “flagging” the associated TSB management file as corresponding to a long-term recording. The designation of a video presentation as a long-term recording is relayed to the device driver 211 which may effect the removal of the clusters containing the video presentation from a TSB 204. In one embodiment, the removal of clusters containing the video presentation from a TSB 204 may be implemented by associating the clusters with a file corresponding to the long-term recording, and by replenishing the TSB 204 with an equal number of clusters from a pool of available clusters. A long-term recording may eventually be deleted from the storage device 273 in response to, for example, a user request. This deletion occurs, in one implementation, by configuring the associated non-buffer clusters as writable, and thus eventually available for the buffering or recording of other AN data. In an alternative embodiment, a buffered video presentation that is designated as a long term recording may be copied from a TSB 204 to another portion of a hard disk 201 for long term storage.
In one implementation, applications executing on the DHCT 200 work with the navigator 360 by abiding by several guidelines. First, an application utilizes the SAM client 320 for the provision, activation, and suspension of services. Second, an application shares DHCT 200 resources with other applications and abides by the resource management policies of the SAM client 320, the operating system 253, and the DHCT 200. Third, an application conforms to situations where shared resources are only accessible via the navigator 360. Fourth, when an application loses service authorization while providing a service, the application suspends the service via the SAM client 320. The navigator 360 may reactivate an individual service application when it later becomes authorized. Finally, an application client is designed to not have access to commands corresponding to certain user input keys reserved by the navigator 360 (e.g., power, channel+/−, volume+/−, etc.).
Data and software used in providing a DHCT service to a user may be stored in one or more of the following memory resources: a data storage device located at a headend, a data storage device located at a customer premises, a volatile or non-volatile memory internal to the DHCT 200, and/or a hard drive internal to the DHCT 200. For example, an executable program or algorithm corresponding to an operating system (OS) component, or to a client platform component, or to a client application (e.g., PVR application 277), or to respective parts thereof, may reside in and/or execute out of DRAM 252 and/or flash memory 251. An executable program or algorithm may also reside in a storage device 273 and/or an external storage device and may be transferred into DRAM 252 for execution. Likewise, data input and/or output for an executable program or algorithm may be stored in DRAM 252, in flash memory 251, in storage device 273, and/or in a storage device connected to the DHCT 200.
The functions of an “A” key 471, a “B” key 472, and a “C” key 473 may vary depending on the UI screen being presented to a user at the time of the key's activation. For instance, when the UI screen illustrated in
After the user identifies a desired buffering capacity for a TSB 204, the amount of data that is buffered in a TSB 204 is limited (as indicated in step 502) such that it does not, or substantially does not, exceed the capacity that is identified by the user input. One approach for limiting the amount of data that is buffered in a TSB 204 is to assign to the TSB a storage capacity (e.g., a certain number of clusters) that corresponds to the user selected buffering capacity. A buffering capacity that is identified in terms of a play-time may be implemented based on an estimated number of data units that typically provide such play-time. For example, if a user identifies a desired TSB capacity as one-hour, then the storage capacity that is assigned to a TSB 204 may be limited to a predetermined number of bytes that is estimated to provide an average play-time of one-hour.
More than one approach may be used to manage a TSB 204 after a certain storage capacity has been allocated to it. In one implementation, after the TSB is full of buffered data, then additional data being buffered in the TSB is written over previously buffered data. The previously buffered data that is over-written is preferably, but not necessarily, data that had been residing in the TSB for the longest duration as compared to other TSB content. In another implementation, after the TSB is full of buffered data, then a portion of the storage capacity allocated to the TSB is de-allocated from the TSB, and additional storage capacity that is equivalent to the de-allocated portion is assigned to the TSB to accommodate additional data buffering. The portion of storage capacity that is de-allocated from the TSB preferably, but not necessarily, contains data that had been residing in the TSB for the longest duration as compared to other TSB content.
The PVR application 277 may be used to help maintain a user defined storage capacity for a TSB 204. In a preferred embodiment, the storage capacity of a TSB 204 corresponds to a portion of a hard disk 201. If storage capacity is defined based on a desired play time, then a corresponding data unit capacity (e.g., in terms of bytes) may be determined based on an estimated data rate. For example, if a user selects a TSB storage capacity corresponding to 3 hours of play time, then assuming a constant bit rate of 2 mega bits per second (Mbps), the PVR application 277 may assign 0.9 gigabytes (GB) of storage capacity to the TSB 204.
The PVR application 277 may track available disk space and use it to maintain the TSB storage capacity at a desired level. For example, before the PVR application 277 effects a write operation to a TSB 204, it can query the device driver 211 (through the operating system 253) to determine available hard disk space. After a write operation, the PVR application 277 can again poll the device driver 211 to get an update on available hard disk space.
A TSB 204 preferably comprises a plurality of clusters. The total storage capacity of the TSB clusters, at any one time, may be less than or greater than the user-defmed TSB storage capacity because of variations in the bit-rate within a video stream and between video streams that are stored in a TSB 204. The variations, if any, of the amount of clusters in a TSB 204 will preferably represent a small percentage of the TSB capacity, thereby resulting in a substantially constant TSB size over time.
The PVR application 277 preferably manages a TSB 204 by creating a TSB management file associated with each buffered video presentation. A buffered video presentation may include an entire broadcast video presentation or only a portion thereof. For example, if the video presentation Friends is broadcast from 8:00 p.m. to 8:30 p.m., then the buffered video presentation of Friends may only include the portion that was broadcast between 8:15 and 8:30 p.m. The PVR application 277 determines at what time the video presentation was tuned based on a real-time clock value that is forwarded by the operating system 253. The PVR application 277 also receives program guide data from, for example, an IPG application 370 (
When access to prior-channel buffered data is enabled, then a user may have access to buffered video presentations corresponding to two or more respective television channels that are displayed to the user as a result of one or more channel changes. In one implementation, a video presentation is only buffered and/or accessible if the corresponding television channel is presented to a user for more than a predetermined time period. In one embodiment, this predetermined time period may be specified by user input.
As a non-limiting example, assume that a user requests that access to prior-channel buffered data be enabled, and that the user subsequently watches the video presentation Friends on channel 11. Then, in such a scenario, after the user effects a change of the displayed television channel from channel 11 to channel 12, the user will still be able to review the portion of Friends that was displayed on channel 11 prior to the change to channel 12. In other words, data that is buffered prior to a change in channels is not deleted or otherwise rendered inaccessible.
If a user requests that access to a prior-channel buffered data be disabled, then buffered video presentations corresponding to a prior channel are deleted and/or rendered inaccessible. A video presentation may be rendered inaccessible by, for example, deleting a corresponding TSB management file and/or by setting a flag that identifies the video presentation as inaccessible.
In another embodiment, a user may press a certain remote control key (e.g., the buffer key 436 or the record key 426,
After the DHCT 200 receives user input identifying a buffered video presentation that is to be stored as a long-term recording, the DHCT 200 stores the buffered video presentation as a long-term recording (as indicated in step 703). One approach for storing a buffered video presentation as a long-term recording is to set a flag in a corresponding TSB management file identifying the video presentation as such, and to designate the storage space containing the buffered video presentation as not corresponding to a TSB 204 (i.e., to de-allocate the storage space from a TSB 240-i). Additional storage space having a capacity equal to the size of the de-allocated storage space may be allocated to the TSB 204 to maintain a desired buffering capacity. In another embodiment, a video presentation that is buffered in a TSB 204 may be converted to a long-term recording by being copied to another portion of a hard disk 201.
A recorded programs list 860 contains recording entries corresponding to recorded video presentations. Each recording entry in the recorded programs list 860 includes information such as the title of a recorded video presentation, the date it was recorded, the start time of the recording, and the length (i.e., play time) of the recording. In one embodiment, the arrow keys 410 (
The heading area 802 contains a heading for the RPL screen 800. In this example, the heading area contains the heading “Recorded Programs List.” The bottom area 850 of RPL screen 800 contains information about the current functions of relevant keys on the remote control device 400 (
Video corresponding to the television channel to which the DHCT 200 is currently tuned (for which audio may also be playing, and which typically corresponds to a video presentation occupying the full screen before the user is presented with RPL screen 800) is displayed in a video area 830. Next to the video area 830 is a detailed focus area 810 that includes detailed information for a currently highlighted recording entry 820. In the current example, the currently highlighted recording entry 820 corresponds to the video presentation title JAG 822. The detailed focus area 810 may include information such as the title of the video presentation (e.g., JAG), the quality of the recording (e.g., Good), the anticipated end of the recording duration (e.g., until erased). A user may request additional information by activating the Info key 432 on the remote control device 400.
In one embodiment, the detailed focus 810 area may include an icon or a letter (e.g., A or D) to indicate whether the video presentation was received as an analog or digital signal. Furthermore, the PVR application 277 (
A favorite channel or presentation may have been identified as such via user input. A list of favorite channels and/or presentations may be stored in a favorites database 374 (
Inter-channel buffering with respect to only favorite channels or presentations may be implemented by the PVR application 277. For example, after a user requests a change in television channels, the PVR application 277 may first access an IPG database 372 (containing a television program schedule) (
A buffered programs list 1306 contains buffer entries corresponding to buffered video presentations. Each buffer entry in the buffered programs list 1306 includes information such as the title of a buffered video presentation, the broadcast time of the original video presentation, the available time of the buffered video presentation (i.e., the beginning and end times of the buffering), and an indication as to whether the buffered video presentation is designated to be recorded (i.e., stored as a long-term recording). In one embodiment, the arrow keys 410 (
The bottom area 850 of BPL screen 1300 contains information about the current functions of relevant keys on the remote control device 400. As suggested in bottom area 850, the play key 421 and the record key 426 may be used to request the playing and recording, respectively, of a video presentation corresponding to a currently highlighted buffer entry 1302. The “A” key 471 may be used to request the recording of all the buffered video presentations, the “B” key 472 may be used to request a UI screen for sorting the buffered video presentation, and the “C” key 473 may be used to “exit” from the BPL screen 1300.
FIG.1 3B depicts a non-limiting example of an Buffered Programs List (BPL) screen 1310 that may be presented to a user in response to the activation of the record key 426 (
As shown in
As shown in
In an alternative embodiment, a UI screen for achieving functionality described herein may have fewer, additional, and/or different components and/or may have a different layout than is shown in
It should be emphasized that the above-described embodiments of the invention, particularly any “preferred embodiments”, are merely possible examples, among others, of the implementations, setting forth a clear understanding of the principles of the invention. Many variations and modifications may be made to the above-described embodiments of the invention without departing substantially from the principles of the invention. All such modifications and variations are intended to be included herein within the scope of the disclosure and invention and protected by the following claims.