US20030093800A1 - Command packets for personal video recorder - Google Patents

Command packets for personal video recorder Download PDF

Info

Publication number
US20030093800A1
US20030093800A1 US09/951,693 US95169301A US2003093800A1 US 20030093800 A1 US20030093800 A1 US 20030093800A1 US 95169301 A US95169301 A US 95169301A US 2003093800 A1 US2003093800 A1 US 2003093800A1
Authority
US
United States
Prior art keywords
transport stream
mpeg
data
packet
command
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US09/951,693
Inventor
Jason Demas
Sandeep Bhatia
Marcus Kellerman
Girish Hulmani
Srinivasa Reddy
Arun Rao
Xuemin Chen
Frederick Walls
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Avago Technologies International Sales Pte Ltd
Original Assignee
Broadcom Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=25492024&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=US20030093800(A1) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Priority to US09/951,693 priority Critical patent/US20030093800A1/en
Application filed by Broadcom Corp filed Critical Broadcom Corp
Assigned to BROADCOM CORPORATION reassignment BROADCOM CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: CHEN, XUEMIN, HULMANI, GIRISH R., RAO, ARUN GOPALAKRISHNA, WALLS, FREDERICK GEORGE, BHATLA, SANDEEP, REDDY, SRINIVASA MOGATHALA PRABHAKARA, DEMAS, JASON, KELLERMAN, MARCUS
Priority to EP02798101A priority patent/EP1442598A1/en
Priority to PCT/US2002/027752 priority patent/WO2003024113A1/en
Priority to US10/318,295 priority patent/US8923688B2/en
Priority to US10/317,454 priority patent/US20030121038A1/en
Priority to US10/317,642 priority patent/US7342967B2/en
Priority to US10/317,389 priority patent/US7149248B2/en
Publication of US20030093800A1 publication Critical patent/US20030093800A1/en
Priority to US11/608,127 priority patent/US8009741B2/en
Priority to US12/890,427 priority patent/US9380337B2/en
Assigned to BANK OF AMERICA, N.A., AS COLLATERAL AGENT reassignment BANK OF AMERICA, N.A., AS COLLATERAL AGENT PATENT SECURITY AGREEMENT Assignors: BROADCOM CORPORATION
Assigned to AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD. reassignment AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BROADCOM CORPORATION
Assigned to BROADCOM CORPORATION reassignment BROADCOM CORPORATION TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS Assignors: BANK OF AMERICA, N.A., AS COLLATERAL AGENT
Abandoned legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving MPEG packets from an IP network
    • H04N21/4385Multiplex stream processing, e.g. multiplex stream decrypting
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06TIMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T9/00Image coding
    • G06T9/004Predictors, e.g. intraframe, interframe coding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41Structure of client; Structure of client peripherals
    • H04N21/414Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance
    • H04N21/4147PVR [Personal Video Recorder]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4348Demultiplexing of additional data and video streams
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65Transmission of management data between client and server
    • H04N21/658Transmission by the client directed to the server
    • H04N21/6587Control parameters, e.g. trick play commands, viewpoint selection
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845Structuring of content, e.g. decomposing content into time segments
    • H04N21/8455Structuring of content, e.g. decomposing content into time segments involving pointers to the content, e.g. pointers to the I-frames of the video stream

Definitions

  • the invention relates generally to video recorder and playback systems; and, more particularly, it relates to command packets that may be inserted into a data transport stream.
  • MPEG-2 transport stream format MPEG-2 TS
  • MPEG-2 TS MPEG-2 transport stream format
  • FIG. 1 shows a prior art conventional personal video recorder system 100 .
  • a host processor 110 is operable to control and/or provide data in a MPEG TS 115 .
  • the host processor provides and/or controls this data to a proprietary/conventional decoder 120 .
  • the host processor 110 and the proprietary/conventional decoder 120 may also be included within a single device.
  • the proprietary/conventional decoder 120 includes a host processor-specific dedicated, local intelligence 122 for decoding of trick play functions of the MPEG TS 115 . Any other devices may also be used, besides a host processor 110 , to control the decoding of the MPEG TS 115 and also to control any desired trick play functionality to be performed on the MPEG TS 115 .
  • the host processor-specific dedicated, local intelligence 122 is operable to perform extraction of the commands, that may include some trick play functionality, and to perform modification of the MPEG TS 115 .
  • the proprietary/conventional decoder 120 is operable to perform MPEG data manipulation 124 that is required to enable trick play operations.
  • the MPEG data manipulation modifies input MPEG data 125 and transforms it into modified MPEG data 126 . This transformation is typically entirely proprietary and specific to the particular device used to perform this functionality.
  • Prior art systems are inoperable to perform direct trick play playback of MPEG data without performing proprietary modification of the input MPEG data 125 to transform it into the modified MPEG data 126 that includes the proper commands and controls to perform trick play playback of the input MPEG data 125 .
  • the modified MPEG data 126 within the proprietary system, is a data form that does not fall within the MPEG standard any longer.
  • the data has been modified, as uniquely required, within the proprietary system to enable playback of the data in the proper manner.
  • Other proprietary systems also perform similar modification of the data, as required within their respective systems. Typically, no two proprietary systems perform this modification of the data to enable playback in a similar manner.
  • the output from the proprietary/conventional decoder 120 provides the now-modified MPEG data 126 to a display 140 .
  • Various aspects of the invention can be found in a transport stream that includes both data packets and command packets.
  • the novel implementation of command packets within the transport stream allows the elimination of the great deal of interfacing required between a control device and a decoding and/or display device that is required in previous systems.
  • the command packet includes one or more commands that are to be performed on data packets within the transport stream.
  • the command packets may be inserted at any place within a system up to and before an output device that plays back the data packets of the transport stream.
  • the commands within a command packet may be input by a user, it may be initiated by a detection of the type of content of transport stream, and any number of other inputs.
  • the command packet includes the ability to perform trick play operations on the data packet portions within the transport stream.
  • a transport stream may include only command packets in certain embodiments; the command packets, formatted in transport stream format, are used to perform control operations between various devices. This particular embodiment provides the opportunity to perform control without a great deal of control-based interfacing by using the exiting communication lines that are operable to support the transport stream.
  • the transport stream is a motion picture expert group, MPEG-2 transport stream.
  • the command packets are formatted with headers having syntax that is compatible with the MPEG-2 transport stream format, so that the command packet may be transmitted along with the data packets within the transport stream without affecting the communication of the transport stream between any number of devices.
  • the transport stream is also operable within systems that do not have the decoding capability to extract the command information from a command packet contained within the transport stream.
  • a decoder tries to decode the MPEG-2 formatted command packet, and when the decoder does not have the ability to decode and extract the command information from the command packet, that particular command packet is merely treated as being unidentified (or unknown) adaptation data within the transport stream. From other perspectives, this data may be viewed as being corrupted data; alternatively, the data is identified as being irrelevant data. Then, that packet (either identified as being irrelevant or corrupted data) is discarded and the remainder of the transport stream, having the data packets, is played back normally, just as data packets of an ordinary transport stream may be played back.
  • FIG. 1 is a system diagram illustrating an embodiment of a prior art conventional personal video recorder system.
  • FIG. 2 is a system diagram illustrating an embodiment of a personal video recorder system that is built in accordance with certain aspects of the present invention.
  • FIG. 3 is a system diagram illustrating another embodiment of a personal video recorder system that is built in accordance with certain aspects of the present invention.
  • FIG. 4 is a system diagram illustrating an embodiment of motion picture expert group (MPEG) transport stream (TS) content that is configured in accordance with certain aspects of the present invention.
  • MPEG motion picture expert group
  • TS transport stream
  • FIG. 5 is a system diagram illustrating an embodiment of a simplified digital channel recording process that is performed in accordance with certain aspects of the present invention.
  • FIG. 6 is a system diagram illustrating an embodiment of an analog channel recording process that is performed in accordance with certain aspects of the present invention.
  • FIG. 7 is a system diagram illustrating an embodiment of a video playback process that is performed in accordance with certain aspects of the present invention.
  • FIG. 8 is a functional block diagram illustrating an embodiment of a command packet method that is performed in accordance with certain aspects of the present invention.
  • FIG. 9 is a functional block diagram illustrating an embodiment of a transport stream (TS) decoding method that is performed in accordance with certain aspects of the present invention.
  • TS transport stream
  • FIG. 10 is a functional block diagram illustrating an embodiment of a transport stream (TS) transport/parse method that is performed in accordance with certain aspects of the present invention.
  • TS transport stream
  • FIG. 11 is a functional block diagram illustrating an embodiment of playback method options that may be performed in accordance with certain aspects of the present invention.
  • FIG. 12 is a functional block diagram illustrating an embodiment of a playback method that is performed in accordance with certain aspects of the present invention.
  • FIG. 13 is a functional block diagram illustrating an embodiment of a video transport processing method that is performed in accordance with certain aspects of the present invention.
  • FIG. 14 is a functional block diagram illustrating an embodiment of a normal playback method that is performed in accordance with certain aspects of the present invention.
  • FIG. 15 is a functional block diagram illustrating an embodiment of a fast forward playback method that is performed in accordance with certain aspects of the present invention.
  • FIG. 16 is a functional block diagram illustrating an embodiment of a rewind playback data flow method that is performed in accordance with certain aspects of the present invention.
  • FIG. 17 is a functional block diagram illustrating an embodiment of a rewind playback control flow method that is performed in accordance with certain aspects of the present invention.
  • FIG. 18 is a system diagram illustrating an embodiment of an MPEG-2 coded bit stream that is configured in accordance with certain aspects of the present invention.
  • the present invention is able to insert command packets directly into a motion picture expert group, MPEG-2 transport stream (TS).
  • MPEG-2 transport stream TS
  • MPEG-2 TS will commonly be referred to as MPEG TS using a convention commonly used by those persons having skill in the art.
  • the command packets may be formatted in a similar way in which data is also formatted to comply with the MPEG TS format.
  • the present invention is also operable, generically, to perform formatting of command packets into a TS format, so that they may be inserted within the TS, without affecting the ability of the TS to be received and decoded.
  • the location in which the command packet may be inserted into the TS may vary, as desired in the particular application.
  • Certain embodiments of the present invention envision content management that may be performed by system up-stream from where the TS is generated.
  • a device may receive a TS, and based on analysis of the content of the TS, certain portions of the TS may be skipped, passed over, or otherwise handled differently based on the content of the data. For example, in some situations, content unsuitable for children may be detected and skipped over as desired by a user of certain aspects of the present invention.
  • a parent could program their decoder to detect the data type in the TS and then to insert certain command packets into the TS so that the TS will be accommodated according to that parent's desires. If the parent wished to skip adult content completely, TS formatted command packets could be inserted to skip over adult-oriented content at all times. Conversely, other content based management could similarly be performed as will be understood by those persons having skill in the art.
  • the control functionality of the command packet will readily be made available for use.
  • the present invention obviates the need for the communication and control intensive interfacing between a control device and a decoding device that is prevalent in previous systems. Any number of commands may be included within a TS formatted command packet.
  • the present invention obviates the need to implement trick play of data using proprietary techniques within previous systems. For example, rather than requiring the physical manipulation of the data into a form other than the ordinary form in which the data is received to enable trick play playback (as in previous systems), the present invention is operable to perform this functionality using the TS formatted command packets.
  • the TS formatted command packets are decoded in similar manner as the way an actual TS formatted data is decoded.
  • an EP picture usually is an Intra-coded picture (I-picture).
  • I-picture Intra-coded picture
  • the system that performs the decoding uses the encoded command packets (extracted from within the TS formatted command packet) to perform the trick play functionality.
  • the present invention is also backward compatible to systems that are not operable to perform trick play functionality. For example, when a TS formatted command packet is received, as part of the TS formatted data, the receiver of the trick play incapable system simply rejects, or discards, the TS formatted command packet as if it were corrupted data.
  • the data may alternatively be identified as being irrelevant data, and not necessarily corrupted.
  • the present invention is able to do this without deleteriously affecting the performance of normal and ordinary playback of the data. No substantial jitter is introduced by the detection and discarding of this data.
  • the present invention provides for a great decrease in the interfacing required between the device that provides the data, and may also provide control commands of how the data is to be played back, and the device that actually decodes the data and provides it to an output device.
  • video data is used for illustration.
  • Audio data, video data, and other digital data may be handled using various aspects of the present invention to format command packets into a format compatible with the manner in which actual data is formatted for transport.
  • the transport of data, and TS formatted command packets may be between two embedded components within a single device, between multiple devices, and generically between any two elements that data may be transported.
  • the command packets may be inserted into the TS at virtually any point without corrupting the TS. From an overview perspective, the command packets appear similar to an ordinary data packet in form. However, when that packet is decoded, it will contain command information that may include how other packets within the TS are to be handled. For a decoding system that is incapable to recognize or perform the proper functionality, the command packet will simply appear to be corrupted data. Again, those persons having skill in the art will appreciate that the command packet may alternatively be identified as being an irrelevant command packet, and not necessarily corrupted. In such situations, the command packet will be ignored and discarded without affecting the playback of the other data portions of the TS.
  • the present invention is implemented in a personal video recorder (PVR) system.
  • a personal video recorder system may offer consumers a hard disk-based VCR that is operable to receive and record a live TV program while offering the versatility of select playback and associated special features.
  • the personal video recorder is also operable to receive data from any number of other sources as well.
  • One of the most important features is providing the ability to the consumer to pause viewing of a live broadcast, for a variable length of time while the unit continues to record, and then resume continuous view from the point of departure. This is often referred to as “time-shifting.”
  • time-shifting since the programs are recorded digitally, the viewer can also take advantage of trick play features such as pause, fast forward, slow forward, rewind, slow reverse, skip, etc.
  • FIG. 2 is a system diagram illustrating an embodiment of a personal video recorder system 200 that is built in accordance with certain aspects of the present invention.
  • the personal video recorder system 200 includes a decoder 220 that receives a data transport stream (TS) 215 from some source.
  • the TS 215 may be received by the decoder 220 from a host processor 215 , . . . , or any other source 205 without departing from the scope and spirit of the invention.
  • the TS 215 contains embedded TS formatted command packets. From certain perspectives, the TS formatted command packets may be viewed as being command packets, having a form of an ordinary TS data packet in terms of configuration and arrangement, that are inserted within the TS 215 .
  • an MPEG TS 217 having embedded MPEG TS formatted command packets, is provided by either one or both of the host processor 215 , . . . , or the any other source 205 to the decoder 220 .
  • the decoder 220 is operable to perform decoding of the TS 215 , as shown in a functional block 222 within the decoder 220 . Similarly, the decoder 220 is operable to perform decoding of the MPEG TS 217 , as shown in a functional block 224 within the decoder 220 .
  • the now decoded TS 235 is passed to an output device shown as a display 240 . Again, other output devices may be employed to accommodate various data types, including audio data types.
  • the use of a display 240 is used to show the exemplary situation of video data TSs.
  • the display 240 is operable to perform playback of the now decoded TS 235 .
  • the decoded TS 235 may be of various data types, including audio and video data types.
  • the decoded TS 235 is now operable for playback, trick play, and other operations within the output device.
  • the decoded TS may be a decoded MPEG TS 237 that is operable for playback, trick play, and other operations.
  • the command packets, that were formatted into the appropriate TS format within the TS 215 are decoded to direct the manner in which portion of the TS 215 are to be handled.
  • the TS formatted command packets do not interfere with the remaining portions of the TS, in that, they appear simply to be other packets within the TS in terms of format.
  • a system that is operable to perform trick play and that is operable to decode and extract the commands within the command packets, will implement the commands to direct the appropriate handling of the other portions of the TS.
  • the command packets will simply be identified as corrupted data and/or irrelevant data and discarded, as understood by those persons having skill in the art.
  • Even conventional systems are operable to detect a corrupted data packet and/or irrelevant data packet.
  • the TS formatted command packets do not substantially interfere with the normal playback of the TS.
  • FIG. 3 is a system diagram illustrating another embodiment of a personal video recorder system 300 that is built in accordance with certain aspects of the present invention.
  • the personal video recorder system 300 includes a proprietary/conventional decoder 320 that receives a data transport stream (TS) 315 from some source.
  • the TS 315 may be received by the proprietary/conventional decoder 320 from a host processor 315 , . . . , or any other source 305 without departing from the scope and spirit of the invention.
  • the TS 315 contains embedded TS formatted command packets.
  • the TS formatted command packets may be viewed as being command packets, having a form of an ordinary TS data packet in terms of configuration and arrangement, that are inserted within the TS 315 .
  • an MPEG TS 317 having embedded MPEG TS formatted command packets, is provided by either one or both of the host processor 315 , . . . , or the any other source 305 to the proprietary/conventional decoder 320 .
  • the proprietary/conventional decoder 320 is operable to perform decoding of the TS 315 , as shown in a functional block 322 within the proprietary/conventional decoder 320 .
  • the proprietary/conventional decoder 320 is operable to perform decoding of the MPEG TS 317 , as shown in a functional block 324 within the proprietary/conventional decoder 320 .
  • the now decoded TS 335 is passed to an output device shown as a display 340 . Again, other output devices may be employed to accommodate various data types, including audio data types.
  • the use of a display 340 is used to show the exemplary situation of video data TSs.
  • the display 340 is operable to perform playback of the now decoded TS 335 .
  • the decoded TS 335 may be of various data types, including audio and video data types.
  • the proprietary/conventional decoder 320 is inoperable to perform any trick play as directed by the commands within the TS formatted command packets.
  • the proprietary/conventional decoder 320 is inoperable to perform decoding of the commands within the TS formatted command packets.
  • the now decoded TS 335 will be operable for normal playback. Those TS formatted command packets, that were contained within the TS 315 , will be ignored and discarded. This ignoring and discarding will not interfere with the playback of the other portions of the decoded TS 335 .
  • the proprietary/conventional decoder 320 When the TS 315 is decoded, and given that the proprietary/conventional decoder 320 is inoperable to perform trick play and is operable to decode and to extract the commands within the TS formatted command packets, then the proprietary/conventional decoder 320 simply perceives that the TS formatted command packets are corrupted data and/or irrelevant data. The proprietary/conventional decoder 320 then discards the TS formatted command packets. This embodiment of the present invention, as shown in the FIG.
  • TS formatted command packets do not substantially interfere with the normal playback of the TS. That is to say, in the context of video playback, there is not substantial interference with the playback of the video data such that a viewer will perceive a substantial reduction in perceptual quality. Analogously, in the in the context of audio playback, there will not be a substantial interference with the playback of the audio data such that a listener will perceive a substantial reduction in perceptual quality.
  • This embodiment shows the backward compatibility of a TS that is encoded in accordance with certain aspects of the present invention.
  • a system capable to perform decoding of the command packets, and also a system incapable to do so, may both receive a TS that is encoded using the present invention.
  • Certain aspects of the present invention may be implemented in new and older systems without introducing any deleterious reduction in performance.
  • FIG. 4 is a system diagram illustrating an embodiment of motion picture expert group (MPEG) transport stream (TS) content 400 that is configured in accordance with certain aspects of the present invention.
  • the MPEG TS content 400 includes an MPEG TS 410 .
  • the MPEG TS 410 includes data 420 and TS formatted trick play commands 430 .
  • the data 410 may include any one or combination of video data 422 , audio data 424 , . . . , and any other data type 429 as understood by those persons having skill in the art.
  • the TS formatted trick play commands 430 may include any one or combination of commands that direct functions of pause/still 431 , fast forward 432 , rewind 433 , slow forward 434 , slow rewind 436 , skip 436 , . . . , and any other commands 439 as understood by those persons having skill in the art. There may also be subsets of each of the command included within the TS formatted trick play commands 430 .
  • the fast forward 432 may also include options to perform FF at varying rates, such as 1 ⁇ 2 ⁇ , 2 ⁇ , 3 ⁇ , etc.
  • the rewind 432 may also include options to perform REW at varying rates, such as 1 ⁇ 2 ⁇ , 2 ⁇ , 3 ⁇ , etc.
  • the other command may also include other variations as well.
  • the data 420 within the MPEG TS 410 is formatted in a particular manner to enable and comply with MPEG TS formatting requirements.
  • a command packet including any one or more of the TS formatted trick play commands 430 within the MPEG TS 410 are formatted in a particular manner to enable and comply with MPEG TS formatting requirements.
  • command packets may be formatted into a proper TS format and inserted within the TS as well.
  • Certain embodiments of the present invention are geared specifically to accommodate MPEG TSs, but those persons having skill in the art will recognize that the principle of embedding command packets, the command packets being formatted in similar manner that the data is formatted within the TS format, may be employed in other application contexts as well.
  • the implementation of these aspects will assist in the ability to eliminate a great deal of communication, command, and control interfacing between various components within personal video recorders and other systems that seek to perform decoding and presentation of data that is received via a TS.
  • FIG. 5 is a system diagram illustrating an embodiment of a simplified digital channel recording process 500 that is performed in accordance with certain aspects of the present invention.
  • the FIG. 5 shows one embodiment where digital channel recording may be performed, in a simplified manner when compared to previous systems, using certain aspects of the present invention.
  • the recording process of digital video stream is given in the FIG. 1.
  • a personal video recorder (PVR) digital-channel-recording process can be described as shown below.
  • the selected video service will be contained in a transport stream (TS) that is received as shown in a radio frequency (RF) signal that is received by a tuner 510 .
  • the tuner 510 is operable to down-convert the channel that contains the transport stream, from RF to intermediate frequency (IF).
  • the Demodulation block shown as a demodulator 515 , demodulates the IF to base-band digital data and outputs the transport stream (shown as an MPEG TS) and sends the data to the decryption block 520 .
  • the decryption block 520 decrypt the packets of the TS into clear data if the service is authorized. This output TS stream goes to the Data Transport Processor 525 .
  • the Data Transport Processor selects only the requested service and then re-multiplexes it into a new TS and stores the new TS data in a TS FIFO buffer 532 in synchronous dynamic random access memory (SDRAM) 530 .
  • SDRAM synchronous dynamic random access memory
  • This new TS is then transferred to a hard disk 550 .
  • the data within the TS FIFO buffer 532 is operable to be communicates to the hard disk 550 .
  • the CPU 540 controls the storing of the data from the TS FIFO 532 to the hard drive (hard disk 550 ). This is done using DMA engines which sends the data over the PCI bus 541 to the super I/O controller chip 545 containing the IDE interface to the hard drive (hard disk 550 ) itself. If desired, the IDE ATA-3 Advanced Technology Attachment Interface with Extensions—AT Attachment 3 Interface protocol is employed between the super I/O controller chip 545 and the hard disk 550 .
  • a Start Code Index Table (SCIT) 551 is also generated and stored in the hard disk 550 (see the next section for detailed description).
  • a TS file 552 is then stored within the hard disk 552 .
  • This TS file 552 may include exclusively data portions and also command packet portions in various embodiments.
  • FIG. 5 shows how a TS may be generated and stored in a hard disk 550 as will be understood by those persons having skill in the art.
  • TS formatted command packets may then also be inserted within the TS stream that is extracted from the TS file 552 .
  • TS formatted command packets may be inserted into a TS at any time without compromising the quality of the data contained within the TS.
  • FIG. 6 is a system diagram illustrating an embodiment of an analog channel recording process 600 that is performed in accordance with certain aspects of the present invention.
  • a personal video recorder can accept an analog channel from either the tuner or from the baseband line inputs on the back panel of its device.
  • a tuner 610 receives a radio frequency (RF) signal and down-convert the selected channel to an intermediate frequency (IF) signal.
  • IF intermediate frequency
  • the IF signal is then passed to the analog descramble block 616 .
  • the analog descramble block 616 will then demodulate the IF to base-band analog video and audio. If the channel is encrypted, the analog descramble block 616 will also decrypt the signals (provided that it is authorized to do so).
  • the video component from the analog descramble block 616 is passed to a video switcher block 618 from which an analog video signal is passed to a video decoder 620 .
  • the video switcher block 620 also receives a line in video signal as well.
  • the analog audio signal, from the analog descramble block 616 is passed to an audio analog to digital converter (ADC) 672 .
  • ADC audio analog to digital converter
  • Another audio ADC 671 is placed in parallel with the audio ADC 672 ; the audio ADC 671 receives a lien in audio signal.
  • the outputs from the outputs from both the audio ADCs 671 and 672 are provided as serial I 2 S data streams and compresses them and multiplexes them (using MUX 675 ) into a serial I 2 S data stream that is provided to an MPEG audio encoder block 681 within the MPEG encoder chip 680 .
  • the video decoder 620 converts it to an 8 bit parallel data stream that is then sent to an MPEG video encoder block 682 within an MPEG encoder chip 680 .
  • the MPEG encoder chip 680 accepts the digitized video (in CCIR 656 format, if desired) and digitized audio (from the MUX 675 ) and compresses them and then multiplexes them (using a MUX 675 ) to an MPEG TS.
  • the MPEG TS is a MPEG 2 Transport Stream in one particular embodiment. If desired, this now digitized MPEG TS may be communicated to other devices via a PCI bus 641 .
  • the MPEG TS is then passed to a data transport processor 626 .
  • the TS processing in the data transport processor 626 stores the data in a TS FIFO buffer 632 in a SDRAM 630 .
  • a CPU 640 controls storing the data from the TS FIFO 632 to the hard drive/hard drive 660 .
  • This may be performed using any one or more of various DMA engines that send the data over a PCI bus 641 (after having passed through a PCI I/F 636 ) to a super I/O controller chip 646 containing the IDE interface to the hard drive/hard disk 660 itself.
  • the interfacing between the super I/O controller chip 646 and the hard disk 660 may be performed using the IDE ATA-3 protocol.
  • the start code index table (SCIT) is also generated and stored in the hard drive/hard disk 660 .
  • SCIT start code index table
  • a TS file 662 is stored on the hard disk 660 .
  • the TS file 662 may then be retrieved for playback or for transmission to other components or devices.
  • FIG. 5 shows how a TS may be generated and stored in a hard disk 660 as will be understood by those persons having skill in the art.
  • TS formatted command packets may then also be inserted within the TS stream that is extracted from the TS file 662 .
  • TS formatted command packets may be inserted into a TS at any time without compromising the quality of the data contained within the TS.
  • FIG. 7 is a system diagram illustrating an embodiment of a video playback process 700 that is performed in accordance with certain aspects of the present invention.
  • the particular example of video data retrieval and playback is shown in the FIG. 7, but those persons having skill in the art will appreciate that these aspects of the present invention are also extendible to retrieval and playback of other types of data, including audio data and other digital data types.
  • a personal video recorder For a program recorded on the hard drive/hard disk 710 , a personal video recorder, or other operable system, can play back that program using the steps described below in the system diagram of the FIG. 7.
  • a processor that may include a CPU 790 , reads the TS data (shown as the TS file 712 ) from the hard drive/hard disk 710 based on the user selected playback mode.
  • the correct TS data (from the TS file 712 within the hard drive/hard disk 710 ) is read into TS presentation buffer 732 within a SDRAM 730 using DMA engines.
  • Data may be read from the hard drive/hard disk 710 in a similar to the manner in which data is written into the hard drive/hard disk 710 , a super I/O controller chip 720 may communicatively couple with the hard disk 710 and perform data transfer using the IDE ATA-3 protocol.
  • the super I/O controller chip 720 then communicatively couples to the TS presentation buffer 732 within the SDRAM 730 via a PCI bus 723 and a PCI I/F 725 .
  • the data is output from the TS presentation buffer 732 and is then passed to a data transport processor 735 .
  • the data transport processor then de-multiplex the TS into its PES constituents and passes the audio TS to an audio decoder 760 and the video TS to a video transport processor 740 and then to a MPEG video decoder 745 that is operable to decode and extract embedded, TS formatted command packets, that may include instructions to perform trick play functionality.
  • the audio data is then sent to the output blocks, and the video is sent to a display engine 750 .
  • the display engine 750 is responsible for and operable to perform scaling the video picture, rendering the graphics, and constructing the complete display among other functions.
  • DAC digital to analog converter
  • the digital audio is converted to analog in the audio digital to analog converter (DAC) 765 while a Sony Philips Digital Inter-Face (SPDIF) output stream is also generated and transmitted.
  • DAC digital to analog converter
  • FIG. 7 shows just one embodiment where a digital signal may be retrieved from a hard disk and transformed for playback.
  • a digital signal may be retrieved from a hard disk and transformed for playback.
  • TS formatted command packets contained within the TS file 712 as it is stored in the hard disk 710 , or that are inserted into the TS during its transport throughout a personal video recorder or a video playback system.
  • An MPEG video decoder such as the MPEG video decoder 745 , that is operable to decode, interpret, and perform the commands included within the TS may perform the directed functions without necessitating the large degree of command and control interfacing that is required in previous systems.
  • the ability to include commands, within TS formatted command packets within a TS eliminates a great deal of interfacing and also greatly reduces the real estate consumption within a system that performs such functions. Again, if the decoder is inoperable to decode these TS formatted command packets, then they will simply be identified as corrupted data within the TS and ignored and discarded. Clearly, the these TS formatted command packets may alternatively be identified as being irrelevant data within the TS and ignored and may also be discarded.
  • FIG. 8 is a functional block diagram illustrating an embodiment of a command packet method 800 that is performed in accordance with certain aspects of the present invention.
  • a command is formatted into a packet having a TS format.
  • the TS formatted command packet is encoded/inserted into the TS in a block 820 .
  • Various decisions may be used to determine where particularly the TS formatted command packet(s) is/are to be inserted within the TS.
  • the TS (having the TS formatted command packets) is decoded where the commands within the TS formatted command packets are extracted.
  • the appropriate playback is performed using the commands that were retrieved from the TS formatted command packets.
  • the embodiment of the present invention shown in the FIG. 8 shows how commands may be formatted into TS format, then inserted or encoded into a TS. Then, during the decoding of the TS, those previously encoded commands may be extracted during the decoding of the various packets of the TS.
  • the present invention is adaptable to encoding commands, including trick play commands, into MPEG TS format and then inserting those TS formatted command packets commands into an MPEG TS.
  • the TS formatted command packets may include how to handle the entirety of the data within the TS, or portions of data within the TS.
  • TS formatted command packets may be included within a given TS and various portions of data within the TS may be handled differently. For example, normal playback may be performed on one portion, fast forward (FF) may be performed on another portion, rewind (REW) may be performed on yet another portion, and so on.
  • FF fast forward
  • REW rewind
  • FIG. 9 is a functional block diagram illustrating an embodiment of a transport stream (TS) decoding method 900 that is performed in accordance with certain aspects of the present invention.
  • a block 910 points within an MPEG TS are marked to allow for efficient decoding of the TS.
  • the TS has one or more TS formatted command packets contained within it.
  • an entry point (EP) picture of the TS is calculated based on certain parameters of the TS.
  • certain of the parameters 925 may include parameters indicating a trick play mode 926 , a current location 927 , a number of possible entry points 928 , . . . , and any other parameter 929 that may be desired in a particular application.
  • the selected operation as provided within a TS formatted command packet contained within the TS, is performed on the MPEG TS at the EP picture of the TS.
  • the various operations 935 may include any number of operations as described here and in other embodiments of the present invention.
  • the operations 935 may include operations such as trick play 936 , playback 937 , . . . , and any other operation 939 that may be desired in a particular application.
  • a command may be included within a TS, as a TS formatted command packet, and the then decoded command packet may be used to govern the handling of portions of the TS.
  • the EP picture may be calculated at any desired point within the TS, as governed by the use and consideration of one or more of the parameters 925 .
  • a decoder needs a way to randomly access the recorded TS that has been stored on a hard drive.
  • the decoder also needs to be able to maintain its real time display by limiting the data transferred to only those data that are required for building the pictures corresponding to the selected trick-play mode.
  • One way to achieve this is to mark certain entry points in the stream that would efficiently allow a complete picture to be decoded (as shown in the block 910 ).
  • the CPU could then compute the next entry point of the stream based on the current trick-play mode, its current location, and the set of possible entry points (as shown in the block 920 ). Then, the appropriate operation may be performed on portions of the TS (as shown in the block 930 ).
  • command operations may be associated with various portions of the TS.
  • normal playback may be performed on one portion
  • fast forward may be performed on another portion
  • rewind may be performed on yet another portion, and so on.
  • the structure of the TS formatted command packets may take on various forms without departing from the scope and spirit of the invention. Any format where the command packets may be formatted so that they may be inserted within the TS and transported in the similar manner in which the TS is communicated.
  • the present invention is adaptable to MPEG-2 TS formats as well other TS formats where command packets are encoded into TS formatted command packets so that the command may be extracted when the TS formatted command packet is decoded.
  • MPEG-2 TS formatted command packet (as included within an MPEG-2 TS) that may be employed in a personal video recorder or other system, is described below as follows:
  • SCIT Start Code Index Table
  • the SCIT provides important information about the location of all the non-slice start codes (including the PES Start codes), and only the first slice code following a non-slice start code in a record buffer. More specifically, the SCIT contains the following fields:
  • the CPU then has to inspect the field intra_slice_flag. If it is found to be set, the next field intra slice is inspected. If that is found to be a ‘1’, then the slice is deemed to be an intra slice. If the first slice is found to be an intra Slice, this picture is marked as an Entry point picture. If the intra_slice_flag is zero, or intra_slice is zero, then this slice is not an intra slice and hence this picture is not an Entry Point picture.
  • Packet offset This gives the offset in bytes of the first zero byte of a start code pattern 00 00 01 SCV from the start of that packet.
  • Record count gives the number of bytes from the start of this record session to the start of the transport packet containing the start code for this entry. A count of zero indicates the first byte in this session.
  • An SCIT can be described in the following table.
  • the range of values M 1 , M 2 . . . can be between 0 and 187 corresponding to size of the TS packet.
  • the CPU picks the SCIT and linearizes the addresses as it writes to the hard disk.
  • the packet offset and the record count points to the start code in the record life.
  • FIG. 10 is a functional block diagram illustrating an embodiment of a transport stream (TS) transport/parse method 1000 that is performed in accordance with certain aspects of the present invention.
  • a TS is received. This may include receipt of multiple packets within a TS or a single packet within a TS. Alternatively, the entirety of the TS may be received in the block 1010 .
  • a Data Transport driver (DTD) built in accordance with certain aspects of the present invention, is responsible for data flow of the stream to be played back through a Data Transport (and/or Video Transport) Processor.
  • DTD Data Transport driver
  • the DTD will also insert a “Transport Packet” (TP) into the actual TRANSPORT STREAM; the TP may be viewed as being Transport Command Packet(s)—containing various commands.
  • the TP may be referred to as another terminology for a TS formatted command packet as described in other of the various embodiments of the present invention.
  • the terminology of a TP and a TS formatted command packet may be used interchangeably.
  • the TS that now contains the TS formatted command packet
  • VTP Video Transport Processor
  • Video decoder a Video decoder
  • the TP/TS formatted command packet is identified using any of a number of methods.
  • the “Transport Packet”/TS formatted command packet that contains the command fields.
  • a block 1050 the process identification (PID) number of the TP/TS formatted command packet is identified. If desired, a CPU indicates the PID number of the TP. Then, in a block 1060 , this detected PID number is provided to a Video Transport Processor (VTP). Then, in a block 1070 , a command structure is parsed accordingly. This may be performed using the VTP. It is also noted that this option means that firmware flow must then be disturbed to accommodate handling of such PID numbers.
  • VTP Video Transport Processor
  • the PID number of the TP/TS formatted command packet is the same as the video PID number, as shown in a functional block 1055 .
  • the command packet contains an Adaptation Field only and no payload, as shown in a functional block 1057 .
  • the command structure is placed in a private field of the adaptation field.
  • a signature uniquely identifies this packet as a TP/TS formatted command packet in a block 1075 .
  • a 32-bit signature may be used in certain embodiments.
  • a continuity_counter of the TP/TS formatted command packet is ignored as shown in a block 1077 within the functional block 1075 .
  • a TP/TS formatted command packet shall come prior to the packet containing the corresponding PICTURE_START.
  • the command in a TP/TS formatted command packet is valid over all the pictures given by the command and all the packets given by the PICTURE_START and PICTURE_END fields. This means that a TP/TS formatted command packet can be encountered by the Video Transport before the count provided by the previous TP/TS formatted command packet.
  • FIG. 11 is a functional block diagram illustrating an embodiment of playback method options 1100 that may be performed in accordance with certain aspects of the present invention.
  • the playback that may be performed using aspects of the present invention essentially fall into three different modes, Normal playback 1110 , Fast Forward 1120 , and Rewind 1130 .
  • a user should be able to switch between these modes with minimal distortions at changeovers.
  • a CPU reads the data from the hard disk and places it in Playback buffers in the DRAM belonging to the chip.
  • the CPU operates on segments of the elementary stream (ES) from one Entry Point (EP) picture to the other. It determines the EP picture by inspecting the two bytes following the start code value (SCV).
  • ES elementary stream
  • EP Entry Point
  • FIG. 12 is a functional block diagram illustrating an embodiment of a playback method 1200 that is performed in accordance with certain aspects of the present invention.
  • data is read from memory in a block 1210 . This reading of data is from the hard disk in certain embodiments.
  • the data is placed in a playback buffer. These playback buffers are in the DRAM belonging to the chip, as shown in a block 1225 in certain embodiments.
  • the data segments of the elementary stream (ES) from one entry point (EP) picture to the other EP picture of the data segment.
  • the determination of the EP picture is made by inspecting the two bytes following the start code value (SCV) as shown in a block 1235 .
  • SCV start code value
  • FIG. 13 is a functional block diagram illustrating an embodiment of a video transport processing method 1300 that is performed in accordance with certain aspects of the present invention.
  • the VIDEO TRANSPORT PROCESSOR is responsible for sending the elementary stream (ES) with proper boundaries to the VBV (compressed data buffer). This may be described as shown in a block 1310 where an elementary stream (ES) with the proper boundaries is sent to the VBV (compressed data buffer). It also passes some of the command parameters in the TP/TS formatted command packet to the MPEG VIDEO DECODER through a start code table (SCT) Buffer. This may be described as shown in a functional block 1320 . It is also noted that this SCT buffer should not be confused with the SCIT generated in the data transport.
  • SCT start code table
  • EP m denotes the m th Entry Point Picture, where m is an integer, that represents an arbitrary entry point.
  • P m.n denotes n th Picture after m th Entry Point Picture, where m and n are integers. This means that P m.0 are the pictures with intra-slice fields set.
  • EP m to EP m+1 form segment m
  • EP m+1 to EP m+2 form segment m+1 and so on
  • TPB i,j means the Transport Packet Byte at an offset j from byte zero in the transport packet ii from the current packet. This will be used extensively for pointing to a start code and the packet containing it from the TP/TS formatted command packet.
  • PLAY This command puts the Video Decoder in the normal mode. The pictures following this command are treated as any normal stream by the decoder.
  • DISPLAY This command puts the Video Decoder in the display mode. For a given picture sequence, the Video Decoder decodes all the pictures but displays only the last of the “displayable” picture
  • BUILD_REFERENCE This command puts the Video Decoder in the decode mode. For a given segment, the Video Decoder builds a reference picture.
  • PROCESS This command causes the Video Transport to process DISCARD_HEADEND and DISCARD_TAILEND only.
  • the SKIP_COUNT and DISPLAY_COUNT fields are not sent to the Video Decoder. This command is meant for Video Transport.
  • DISCARD_TILL_BTP This causes the Video Transport to discard only the video ES data bytes starting from the transport packet that follows till the next BTP for that PID. When this field is zero, the Video Transport will not discard ES till the next BTP.
  • SKIP_COUNT This field specifies the number of pictures to be skipped before sending a picture to display. Using the Play command with a skip count of 1 achieves a fast forward (FF) of ⁇ 2. If the picture to be skipped is a B picture, it is also skipped from processing.
  • DISPLAY_COUNT This field specifies the number of displayable pictures starting from the picture that follows the TP/TS formatted command packet for which the corresponding command has to be used.
  • this field will be equal to number of pictures in an EP segment in the normal playback mode
  • this field will be equal to (int) ((number of pictures in an EP segment)/(skip_count+1))
  • PICTURE_START This field informs the location of the start of the first picture following a TP for which the command has to be applied, by pointing to the first byte of the start code sequence from the start of the packet in which it is present. This is represented by TPB i,j .
  • PICTURE_END This field informs the location of the start of a picture following a TP/TS formatted command packet over which the command has to be applied. This means the command is valid for all the pictures starting from the PICTURE_START till the picture preceding the one indicated by this field. This is represented by TPB i,j and gives first byte of the start code sequence from the start of that packet.
  • DISCARD_HEADEND This enables the Video Transport to discard all the bytes from the start of the payload till the offset mentioned in this field. A value of 0 means no byte has to be discarded.
  • DISCARD_TAILEND This enables the Video Transport to discard all the bytes from the offset mentioned in this field till the end of the packet. A value of 0 means no byte has to be discarded.
  • DXPORT_VALUE The value in this field is used for piggybacking in the one of the non-slice entry in the SCV table.
  • the Video Decoder returns this value whenever the data transport driver calls a get(DXPORT_VALUE) function. This value could be a PTS value or an offset in the SCIT table. This ensures a quick response during the trick mode changes.
  • a “command” is applicable over all the pictures present between PICTURE_START and PICTURE_END. Again, the command may be extracted from a TP/TS formatted command packet.
  • FIG. 14 is a functional block diagram illustrating an embodiment of a normal playback method 1400 that is performed in accordance with certain aspects of the present invention.
  • the normal playback method 1400 may be achieved in the following manner.
  • a CPU refers to the start code index table (SCIT) that it had picked during the record function.
  • SCIT start code index table
  • SH Sequence Header
  • next picture is an entry point (EP) picture
  • next picture continues to feed the data from that picture as shown in a block 1415 .
  • the CPU searches the SCIT for the first EP picture and begins feeding data from that point till the beginning of the next EP picture as shown in a block 1417 within the functional block 1415 .
  • the CPU also inserts a TP/TS formatted command packet (containing the command) for the VIDEO TRANSPORT PROCESSOR and the video decoder.
  • the MODE is set for PLAY in a block 1425 , and the SKIP_COUNT is programmed to zero in a block 1435 .
  • the DISPLAY_COUNT field informs the number of pictures to be displayed. Typically, this value is the number of pictures in an EP segment as shown in a block 1442 .
  • the VIDEO TRANSPORT PROCESSOR is placed in the Transport Mode in a block 1445 .
  • the VIDEO TRANSPORT PROCESSOR transfers the commands to the video decoder through the start code table (SCT) in a block 1450 .
  • the Video decoder picks a command from the Start Code Table (SCT) buffer 1460 .
  • the command is then decode in a block 1470 , and the command tells the video decoder that it is Normal Playback, and then this would also give the number of pictures that command has been issued for.
  • the Compressed Data Buffer (VBV) Manager is kicked off to read data from the VBV and feed it to the Parser and the Row Decoders as shown in a block 1475 .
  • VBV Compressed Data Buffer
  • the VIDEO TRANSPORT PROCESSOR is responsible for extracting from the Transport packets and sending the ES with proper boundaries to the VBV (compressed data buffer). It also passes the Video related commands/parameters in the TP to the MPEG VIDEO DECODER through SCT Buffer (this should not be confused with the SCIT generated in the data transport)for the video decoder.
  • the VIDEO TRANSPORT PROCESSOR gets to the start and end of a picture by looking at the PICTURE_START and PICTURE_END fields, both of which, are represented by TPB i,j .
  • FIG. 15 is a functional block diagram illustrating an embodiment of a fast forward playback method 1500 that is performed in accordance with certain aspects of the present invention.
  • FF fast forward
  • a first option is a mode in which the fast forward rate is such that there is a minimum of one frame to display over two segments as shown in a block 1505 .
  • the CPU does not do anything different compared to the normal playback as far as feeding the data is concerned.
  • the SKIP_COUNT is a non-zero value as shown in a block 1515 .
  • a value of 1 would cause the Video Decoder to drop every other picture from the display process, achieving a Fast Forward rate of ⁇ 2.
  • a second option is a mode in which the fast forward rate is such that the adjacent pictures are placed over a minimum of three segments as shown in a block 1525 .
  • the CPU needs to do some scheduling of the data as shown in a block 1530 .
  • a reference picture is built by feeding the segment between EP m ⁇ 1 to EP m .
  • the CPU needs to configure video in BUILD_REFERENCE mode.
  • the SKIP_COUNT needs to be programmed to x-1 and DISPLAY_COUNT needs to be 0, where x is the total number of pictures in the segment.
  • the CPU then feeds the pictures P m,0 to P m,n in the segment from EP m to EP m+1 , which is to be used for the actual decode and display.
  • the video has to be configured in PLAY mode.
  • the CPU programs the DISPLAY_COUNT to 1 and the SKIP_COUNT with n ⁇ 1 to display the picture P m.n .
  • FIG. 16 is a functional block diagram illustrating an embodiment of a rewind playback data flow method 1600 that is performed in accordance with certain aspects of the present invention.
  • the CPU plays a major role in scheduling the data in the correct order. In order to correctly decode and display a particular frame, it is important that all the pictures before it were indeed created using “good” data. Since PROGRESSIVE REFRESH streams have no I pictures, but are progressively refreshed, the CPU first feeds an EP-EP segment into the Playback Buffers to build a good reference picture as shown in a block 1605 . Then, the CPU needs to configure the video in BUILD_REFERENCE mode as shown in a block 1610 .
  • the SKIP_COUNT needs to be programmed to x-1 and DISPLAY_COUNT needs to be 0, where x is the total number of pictures in the segment.
  • the CPU then feeds the next EP-EP segment, which is to be used for the actual decode and display, as shown in a block 1620 .
  • the CPU configures the video in REWIND mode s shown in a block 1625 .
  • the picture P m,n is displayed.
  • the DISPLAY_COUNT is set to 1 in a block 1632 and the SKIP_COUNT is set to n ⁇ 1 in a block 1634 to display the picture P m.n .
  • the backward rate of the rewind data flow is determined. If the CPU desires to go backwards at a ⁇ 1 rate (in a block 1642 ), then it resends the same segment that it supplied for the n th picture, every time reducing the SKIP_COUNT fields value by one (1). The CPU also inserts a TP/TS formatted command packet (containing the command) for the VIDEO TRANSPORT PROCESSOR and the video decoder.
  • FIG. 17 is a functional block diagram illustrating an embodiment of a rewind playback control flow method that is performed in accordance with certain aspects of the present invention.
  • the VIDEO TRANSPORT PROCESSOR transfers the commands from the TP/TS formatted command packet and places it in the Start Code Table (SCT) for use by video decoder.
  • the Video decoder picks the command from the SCT and decides what to do with the data in the compressed data buffer (VBV).
  • the command tells the video decoder that it is Rewind Build (using BUILD_REFERENCE, for example).
  • the command also gives the number of pictures that it has been issued for in the block 1710 .
  • the VBV Manager is kicked off to read data from the VBV.
  • the data is fed to a Parser. Since this is a REFERENCE_BUILD, the Buffer manager does not push any picture into the Display Queue.
  • the Buffer Manager sets a flag to indicate to the VBV manager to drop that picture from Decode.
  • the VBV manager begins to start feeding the compressed data to the Row Decoders in a block 1730 .
  • the buffer manager uses all the three/four buffers in the BUILD_REFERENCE mode.
  • the Video decoder decodes the SKIP_COUNT number of pictures from the VBV. Once the SKIP_COUNT runs out, the last buffer that was used for decode is marked as “LockedReferenceBuffer” for future references in a block 1740 . This Special lock is over and above the common “locked for decode” that exists in the design today.
  • the Video Decoder is configured in the REWIND command, the video decoder reads compressed data from the VBV to generate one displayable picture.
  • the command specifies the number of pictures that need to be decoded in order to display the desired picture.
  • the Buffer Manager uses the “Locked” buffer as the buffer for Forward Prediction if it finds the ‘UseReferenceBuffer’ SET in a block 1750 . It also clears the Flag so that it does not get used again for that Command session.
  • a block 1755 all subsequent pictures are decoded normally, constantly updating the buffers that are used for Forward and Backward predictions.
  • the buffer manager is careful not to overwrite the Locked Reference Buffer.
  • the Three buffers mode since one of the buffers is Locked, the other two are used for the decoding of the I/P pictures and the B pictures are discarded.
  • the four buffer mode the B pictures that are intended for Display are only decoded.
  • the skip count is reduced for every picture that the Buffer Manager encounters. If a B picture is encountered, then the skip count is reduced and a flag is set to indicate the VBV manager to skip that picture. If the skip count becomes zero on a picture, then it is intended that, that picture has to be displayed.
  • the four buffer scheme if that picture is a B picture, then we decode and display that picture. However, if we are working in the three buffer mode, then we will not even have a buffer to decode that B picture into as one of the buffers would be the Locked Reference frame and the other two would be carrying the current I/P Forward and Backward prediction reference frames. In such a scenario, the previously decoded picture, (the current Backward prediction buffer) is pushed for display queue.
  • a reference picture is built by feeding the segment between EP m ⁇ 1 to EP m .
  • the CPU needs to configure video in BUILD_REFERENCE command.
  • the DISPLAY_COUNT needs to be programmed to 0 and SKIP_COUNT to x-1, where x is the total number of pictures in the segment.
  • the CPU then feeds the pictures from P m,0 to P m,n in the segment from EP m to EP m+1 , which is to be used for the actual decode and display.
  • the CPU has to configure video in the REWIND mode.
  • the DISPLAY_COUNT should be programmed to 1 and SKIP_COUNT to n ⁇ 1 to display the picture P m.n .
  • the CPU again feeds the pictures from P m,0 to P m,n ⁇ 1 in the segment from EP m to EP m+1 , which is to be used for the actual decode and display time. Again, the CPU needs to configure video in REWIND mode. But, this time, the DISPLAY_COUNT should be programmed to 1 and SKIP_COUNT to n ⁇ 2 to display the picture display the picture P m.n ⁇ 1 . The above process is repeated, decreasing the SKIP_COUNT, till the picture P m.0 is displayed.
  • the decoding of the sequence headers is described below. From the SCIT, the CPU knows the packet that contains the sequence header. The CPU can send only the sequence header data to the video by sending a TP before the packet containing the sequence header. This TP could contain the command that instructs the VIDEO TRANSPORT PROCESSOR to discard the bytes between Transport Header and the PICTURE_START and/or to discard the bytes starting from the start code following the Sequence header till the end of the packet.
  • the DISCARD_HEADEND and the DISCARD_TAILEND field have to be programmed accordingly.
  • DISCARD_HEADEND and DISCARD_TAILEND should be programmed to 10 and 150 respectively.
  • the other fields in this TP can have any value. The video is put in PROCESS mode.
  • the coded picture following a group of pictures (GOP) header shall be a coded I-picture. However, if there is no GOP header in the bit stream, I-pictures are not mandated in the bit stream.
  • One of “no I-picture” bit streams is called the progressive refresh bit stream by Motorola (DigiCipher II).
  • the refresh depth is specified. This depth is ranged from 1 to 9 slices per P-picture to be refreshed. The default value is three slices per P-picture while B-pictures are enabled and one slice per P-picture while B-pictures are disabled. One typical configuration is six slices per P-picture while “two B-picture mode” is enabled. In the progressive refresh mode, both intra_slice_flag and intra_slice are set to “1” for the refreshed intra slices.
  • the vertical search range for motion vectors in a P-picture is restricted.
  • the motion vectors for the macro-blocks located above the refreshed slices in the current P-picture can only point to the region above the refreshed slices in the previous P-picture (as shown in FIG. 18).
  • sequence header and extensions can be inserted before any P-picture, e.g. before second P-picture shown in FIG. 18. From certain perspectives, the FIG. 18 shows the motion vector search range for the progressive-refresh mode.

Abstract

Command packets for personal video recorder. The invention provides for transport stream (TS) that contains data and also includes a transport packet (TP)/TS formatted command packets. The TP/TS formatted command packet may be communicated between any number of devices, including multiple chips, multiple boards, and multiple processors. A decoder is able to decode the TP/TS formatted command packet and to perform the appropriate operation on data portions of the TS. When a TS is provided to a device not having the capability to perform the proper decoding of the TP/TS formatted command packet, that particular packet may be deemed as being unidentified (or unknown) adaptation field data. Alternatively, the packet may be identified as being corrupted data and/or irrelevant data. The invention is operable to encode command packets into the transport stream in such a way that it is backward compatible with previous systems.

Description

    BACKGROUND
  • 1. Technical Field [0001]
  • The invention relates generally to video recorder and playback systems; and, more particularly, it relates to command packets that may be inserted into a data transport stream. [0002]
  • 2. Related Art [0003]
  • Many previous systems that deal with digital video data, including the normal playback and trick play playback of that video data are intrinsically tied to the proprietary system and platform on which they are operating. There have also been many standards developed in this particular area of technology concerning data types. In addition, there have been several standards into which data is formatted for transport. One such transport standard is the motion picture expert group, MPEG-2 transport stream format (MPEG-2 TS). Many of the various data types are formatted into this MPEG-2 TS format for communication between various components in a system. The MPEG-2 TS will generically be referred to as MPEG TS in various remaining portions of this disclosure. [0004]
  • In addition, although there has been some uniformity in the development of TS formats, there has nevertheless been a dependence on dedicated communication and control between components that control the playback (including trick play playback) of the data and the device that performs the decoding of the data for playback. The control device and the decoding device may actually be in the same device, but there is nevertheless a great deal of dedicated interfacing that is required to perform the proper control of the data playback. [0005]
  • FIG. 1 shows a prior art conventional personal [0006] video recorder system 100. A host processor 110 is operable to control and/or provide data in a MPEG TS 115. The host processor provides and/or controls this data to a proprietary/conventional decoder 120. Again, the host processor 110 and the proprietary/conventional decoder 120 may also be included within a single device. The proprietary/conventional decoder 120 includes a host processor-specific dedicated, local intelligence 122 for decoding of trick play functions of the MPEG TS 115. Any other devices may also be used, besides a host processor 110, to control the decoding of the MPEG TS 115 and also to control any desired trick play functionality to be performed on the MPEG TS 115. To enable proper communication between the host processor 110 and the proprietary/conventional decoder 120, a great deal of interfacing is typically needed. In this situation, a dedicated communication/control interface 130 is required between the host processor 110 and the proprietary/conventional decoder 120. The host processor-specific dedicated, local intelligence 122 is operable to perform extraction of the commands, that may include some trick play functionality, and to perform modification of the MPEG TS 115. The proprietary/conventional decoder 120 is operable to perform MPEG data manipulation 124 that is required to enable trick play operations. The MPEG data manipulation modifies input MPEG data 125 and transforms it into modified MPEG data 126. This transformation is typically entirely proprietary and specific to the particular device used to perform this functionality.
  • Prior art systems are inoperable to perform direct trick play playback of MPEG data without performing proprietary modification of the [0007] input MPEG data 125 to transform it into the modified MPEG data 126 that includes the proper commands and controls to perform trick play playback of the input MPEG data 125. The modified MPEG data 126, within the proprietary system, is a data form that does not fall within the MPEG standard any longer. The data has been modified, as uniquely required, within the proprietary system to enable playback of the data in the proper manner. Other proprietary systems also perform similar modification of the data, as required within their respective systems. Typically, no two proprietary systems perform this modification of the data to enable playback in a similar manner.
  • This great deal of dedicated communication/[0008] control interfacing 130 is required to enable trick play operation, given that there the manipulation of the received MPEG TS 115, in transforming the input MPEG data 125 into the modified MPEG data 126, must be performed to enable trick play operations. Again, this inherently requires a great deal of interfacing, by communicating a great deal of command and control information, between the host processor 110 and the proprietary/conventional decoder 120. This great deal of interfacing between the devices requires a very large dedication of real estate in previous systems. Even in situations where the host processor 110 and the proprietary/conventional decoder 120 are contained within a single device, there must nevertheless be a great deal of interfacing between those two devices in the single device, again requiring a great deal of interfacing and also consuming much real estate in the single device system; the two components (even within a single device), one for command and control and one for decoding, must nevertheless be included within a single device. The output from the proprietary/conventional decoder 120 provides the now-modified MPEG data 126 to a display 140.
  • In the conventional situation, the data processing and data transfer requirements for MPEG data manipulation and modification, within the conventional personal [0009] video recorder system 100, requires a great deal of communication and processing requirements. From certain perspectives, conventional personal video recorder systems, that are capable to do trick play playback, inherently require dedicated communication and control within the self-contained system. This communication and control must all be tailored to the specific, proprietary system in which the data is to be played using trick play functionality.
  • Further limitations and disadvantages of conventional and traditional systems will become apparent to one of skill in the art through comparison of such systems with the invention as set forth in the remainder of the present application with reference to the drawings. [0010]
  • SUMMARY OF THE INVENTION
  • Various aspects of the invention can be found in a transport stream that includes both data packets and command packets. The novel implementation of command packets within the transport stream allows the elimination of the great deal of interfacing required between a control device and a decoding and/or display device that is required in previous systems. The command packet includes one or more commands that are to be performed on data packets within the transport stream. The command packets may be inserted at any place within a system up to and before an output device that plays back the data packets of the transport stream. The commands within a command packet may be input by a user, it may be initiated by a detection of the type of content of transport stream, and any number of other inputs. The command packet includes the ability to perform trick play operations on the data packet portions within the transport stream. [0011]
  • In addition, a transport stream may include only command packets in certain embodiments; the command packets, formatted in transport stream format, are used to perform control operations between various devices. This particular embodiment provides the opportunity to perform control without a great deal of control-based interfacing by using the exiting communication lines that are operable to support the transport stream. [0012]
  • In certain embodiments, the transport stream is a motion picture expert group, MPEG-2 transport stream. The command packets are formatted with headers having syntax that is compatible with the MPEG-2 transport stream format, so that the command packet may be transmitted along with the data packets within the transport stream without affecting the communication of the transport stream between any number of devices. [0013]
  • The transport stream is also operable within systems that do not have the decoding capability to extract the command information from a command packet contained within the transport stream. When a decoder tries to decode the MPEG-2 formatted command packet, and when the decoder does not have the ability to decode and extract the command information from the command packet, that particular command packet is merely treated as being unidentified (or unknown) adaptation data within the transport stream. From other perspectives, this data may be viewed as being corrupted data; alternatively, the data is identified as being irrelevant data. Then, that packet (either identified as being irrelevant or corrupted data) is discarded and the remainder of the transport stream, having the data packets, is played back normally, just as data packets of an ordinary transport stream may be played back. [0014]
  • The above-referenced description of the summary of the invention captures some, but not all, of the various aspects of the present invention. The claims are directed to some other of the various other embodiments of the subject matter towards which the present invention is directed. In addition, other aspects, advantages and novel features of the invention will become apparent from the following detailed description of the invention when considered in conjunction with the accompanying drawings. [0015]
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • A better understanding of the invention can be obtained when the following detailed description of various exemplary embodiments is considered in conjunction with the following drawings. [0016]
  • FIG. 1 is a system diagram illustrating an embodiment of a prior art conventional personal video recorder system. [0017]
  • FIG. 2 is a system diagram illustrating an embodiment of a personal video recorder system that is built in accordance with certain aspects of the present invention. [0018]
  • FIG. 3 is a system diagram illustrating another embodiment of a personal video recorder system that is built in accordance with certain aspects of the present invention. [0019]
  • FIG. 4 is a system diagram illustrating an embodiment of motion picture expert group (MPEG) transport stream (TS) content that is configured in accordance with certain aspects of the present invention. [0020]
  • FIG. 5 is a system diagram illustrating an embodiment of a simplified digital channel recording process that is performed in accordance with certain aspects of the present invention. [0021]
  • FIG. 6 is a system diagram illustrating an embodiment of an analog channel recording process that is performed in accordance with certain aspects of the present invention. [0022]
  • FIG. 7 is a system diagram illustrating an embodiment of a video playback process that is performed in accordance with certain aspects of the present invention. [0023]
  • FIG. 8 is a functional block diagram illustrating an embodiment of a command packet method that is performed in accordance with certain aspects of the present invention. [0024]
  • FIG. 9 is a functional block diagram illustrating an embodiment of a transport stream (TS) decoding method that is performed in accordance with certain aspects of the present invention. [0025]
  • FIG. 10 is a functional block diagram illustrating an embodiment of a transport stream (TS) transport/parse method that is performed in accordance with certain aspects of the present invention. [0026]
  • FIG. 11 is a functional block diagram illustrating an embodiment of playback method options that may be performed in accordance with certain aspects of the present invention. [0027]
  • FIG. 12 is a functional block diagram illustrating an embodiment of a playback method that is performed in accordance with certain aspects of the present invention. [0028]
  • FIG. 13 is a functional block diagram illustrating an embodiment of a video transport processing method that is performed in accordance with certain aspects of the present invention. [0029]
  • FIG. 14 is a functional block diagram illustrating an embodiment of a normal playback method that is performed in accordance with certain aspects of the present invention. [0030]
  • FIG. 15 is a functional block diagram illustrating an embodiment of a fast forward playback method that is performed in accordance with certain aspects of the present invention. [0031]
  • FIG. 16 is a functional block diagram illustrating an embodiment of a rewind playback data flow method that is performed in accordance with certain aspects of the present invention. [0032]
  • FIG. 17 is a functional block diagram illustrating an embodiment of a rewind playback control flow method that is performed in accordance with certain aspects of the present invention. [0033]
  • FIG. 18 is a system diagram illustrating an embodiment of an MPEG-2 coded bit stream that is configured in accordance with certain aspects of the present invention. [0034]
  • DETAILED DESCRIPTION OF THE INVENTION
  • The present invention is able to insert command packets directly into a motion picture expert group, MPEG-2 transport stream (TS). For simplicity, MPEG-2 TS will commonly be referred to as MPEG TS using a convention commonly used by those persons having skill in the art. The command packets may be formatted in a similar way in which data is also formatted to comply with the MPEG TS format. The present invention is also operable, generically, to perform formatting of command packets into a TS format, so that they may be inserted within the TS, without affecting the ability of the TS to be received and decoded. [0035]
  • The location in which the command packet may be inserted into the TS may vary, as desired in the particular application. Certain embodiments of the present invention envision content management that may be performed by system up-stream from where the TS is generated. For example, a device may receive a TS, and based on analysis of the content of the TS, certain portions of the TS may be skipped, passed over, or otherwise handled differently based on the content of the data. For example, in some situations, content unsuitable for children may be detected and skipped over as desired by a user of certain aspects of the present invention. A parent could program their decoder to detect the data type in the TS and then to insert certain command packets into the TS so that the TS will be accommodated according to that parent's desires. If the parent wished to skip adult content completely, TS formatted command packets could be inserted to skip over adult-oriented content at all times. Conversely, other content based management could similarly be performed as will be understood by those persons having skill in the art. [0036]
  • For systems that are operable to decoded the TS formatted command packet, the control functionality of the command packet will readily be made available for use. The present invention obviates the need for the communication and control intensive interfacing between a control device and a decoding device that is prevalent in previous systems. Any number of commands may be included within a TS formatted command packet. The present invention obviates the need to implement trick play of data using proprietary techniques within previous systems. For example, rather than requiring the physical manipulation of the data into a form other than the ordinary form in which the data is received to enable trick play playback (as in previous systems), the present invention is operable to perform this functionality using the TS formatted command packets. [0037]
  • The TS formatted command packets are decoded in similar manner as the way an actual TS formatted data is decoded. For a regular MPEG-2 video bit stream, an EP picture usually is an Intra-coded picture (I-picture). The difference is that the system that performs the decoding uses the encoded command packets (extracted from within the TS formatted command packet) to perform the trick play functionality. The present invention is also backward compatible to systems that are not operable to perform trick play functionality. For example, when a TS formatted command packet is received, as part of the TS formatted data, the receiver of the trick play incapable system simply rejects, or discards, the TS formatted command packet as if it were corrupted data. Those persons having skill in the art will appreciate that the data may alternatively be identified as being irrelevant data, and not necessarily corrupted. The present invention is able to do this without deleteriously affecting the performance of normal and ordinary playback of the data. No substantial jitter is introduced by the detection and discarding of this data. [0038]
  • The present invention provides for a great decrease in the interfacing required between the device that provides the data, and may also provide control commands of how the data is to be played back, and the device that actually decodes the data and provides it to an output device. Within many of the various exemplary embodiments, the use of video data is used for illustration. Those persons having skill in the art will recognize that any form of digital data may be included in various embodiments. Audio data, video data, and other digital data may be handled using various aspects of the present invention to format command packets into a format compatible with the manner in which actual data is formatted for transport. The transport of data, and TS formatted command packets, may be between two embedded components within a single device, between multiple devices, and generically between any two elements that data may be transported. The command packets may be inserted into the TS at virtually any point without corrupting the TS. From an overview perspective, the command packets appear similar to an ordinary data packet in form. However, when that packet is decoded, it will contain command information that may include how other packets within the TS are to be handled. For a decoding system that is incapable to recognize or perform the proper functionality, the command packet will simply appear to be corrupted data. Again, those persons having skill in the art will appreciate that the command packet may alternatively be identified as being an irrelevant command packet, and not necessarily corrupted. In such situations, the command packet will be ignored and discarded without affecting the playback of the other data portions of the TS. [0039]
  • In certain embodiments, the present invention is implemented in a personal video recorder (PVR) system. A personal video recorder system may offer consumers a hard disk-based VCR that is operable to receive and record a live TV program while offering the versatility of select playback and associated special features. The personal video recorder is also operable to receive data from any number of other sources as well. [0040]
  • One of the most important features is providing the ability to the consumer to pause viewing of a live broadcast, for a variable length of time while the unit continues to record, and then resume continuous view from the point of departure. This is often referred to as “time-shifting.” In addition, since the programs are recorded digitally, the viewer can also take advantage of trick play features such as pause, fast forward, slow forward, rewind, slow reverse, skip, etc. Certain of these aspects, among others, are disclosed below in various embodiments of the present invention. [0041]
  • FIG. 2 is a system diagram illustrating an embodiment of a personal video recorder system [0042] 200 that is built in accordance with certain aspects of the present invention. The personal video recorder system 200 includes a decoder 220 that receives a data transport stream (TS) 215 from some source. The TS 215 may be received by the decoder 220 from a host processor 215, . . . , or any other source 205 without departing from the scope and spirit of the invention. The TS 215 contains embedded TS formatted command packets. From certain perspectives, the TS formatted command packets may be viewed as being command packets, having a form of an ordinary TS data packet in terms of configuration and arrangement, that are inserted within the TS 215. In certain embodiments, an MPEG TS 217, having embedded MPEG TS formatted command packets, is provided by either one or both of the host processor 215, . . . , or the any other source 205 to the decoder 220.
  • The [0043] decoder 220 is operable to perform decoding of the TS 215, as shown in a functional block 222 within the decoder 220. Similarly, the decoder 220 is operable to perform decoding of the MPEG TS 217, as shown in a functional block 224 within the decoder 220. The now decoded TS 235, is passed to an output device shown as a display 240. Again, other output devices may be employed to accommodate various data types, including audio data types. The use of a display 240 is used to show the exemplary situation of video data TSs. The display 240 is operable to perform playback of the now decoded TS 235. The decoded TS 235 may be of various data types, including audio and video data types.
  • The decoded [0044] TS 235 is now operable for playback, trick play, and other operations within the output device. In one particular situation, the decoded TS may be a decoded MPEG TS 237 that is operable for playback, trick play, and other operations. The command packets, that were formatted into the appropriate TS format within the TS 215, are decoded to direct the manner in which portion of the TS 215 are to be handled. The TS formatted command packets do not interfere with the remaining portions of the TS, in that, they appear simply to be other packets within the TS in terms of format.
  • When the [0045] TS 215 is decoded, a system that is operable to perform trick play and that is operable to decode and extract the commands within the command packets, will implement the commands to direct the appropriate handling of the other portions of the TS. However, if the system is incapable to provide the trick play functionality, then the command packets will simply be identified as corrupted data and/or irrelevant data and discarded, as understood by those persons having skill in the art. Even conventional systems are operable to detect a corrupted data packet and/or irrelevant data packet. For systems incapable to perform the decoding and performance of the command contained within the TS formatted command packets, the TS formatted command packets do not substantially interfere with the normal playback of the TS. That is to say, in the context of video playback, there is not substantial interference with the playback of the video data such that a viewer will perceive a substantial reduction in perceptual quality. Analogously, in the in the context of audio playback, there will not be a substantial interference with the playback of the audio data such that a listener will perceive a substantial reduction in perceptual quality.
  • FIG. 3 is a system diagram illustrating another embodiment of a personal [0046] video recorder system 300 that is built in accordance with certain aspects of the present invention. The personal video recorder system 300 includes a proprietary/conventional decoder 320 that receives a data transport stream (TS) 315 from some source. The TS 315 may be received by the proprietary/conventional decoder 320 from a host processor 315, . . . , or any other source 305 without departing from the scope and spirit of the invention. The TS 315 contains embedded TS formatted command packets. From certain perspectives, the TS formatted command packets may be viewed as being command packets, having a form of an ordinary TS data packet in terms of configuration and arrangement, that are inserted within the TS 315. In certain embodiments, an MPEG TS 317, having embedded MPEG TS formatted command packets, is provided by either one or both of the host processor 315, . . . , or the any other source 305 to the proprietary/conventional decoder 320.
  • The proprietary/[0047] conventional decoder 320 is operable to perform decoding of the TS 315, as shown in a functional block 322 within the proprietary/conventional decoder 320. Similarly, the proprietary/conventional decoder 320 is operable to perform decoding of the MPEG TS 317, as shown in a functional block 324 within the proprietary/conventional decoder 320. The now decoded TS 335, is passed to an output device shown as a display 340. Again, other output devices may be employed to accommodate various data types, including audio data types. The use of a display 340 is used to show the exemplary situation of video data TSs. The display 340 is operable to perform playback of the now decoded TS 335. The decoded TS 335 may be of various data types, including audio and video data types.
  • In this particular embodiment, the proprietary/[0048] conventional decoder 320 is inoperable to perform any trick play as directed by the commands within the TS formatted command packets. Alternatively, the proprietary/conventional decoder 320 is inoperable to perform decoding of the commands within the TS formatted command packets. In this situation, the now decoded TS 335 will be operable for normal playback. Those TS formatted command packets, that were contained within the TS 315, will be ignored and discarded. This ignoring and discarding will not interfere with the playback of the other portions of the decoded TS 335.
  • When the [0049] TS 315 is decoded, and given that the proprietary/conventional decoder 320 is inoperable to perform trick play and is operable to decode and to extract the commands within the TS formatted command packets, then the proprietary/conventional decoder 320 simply perceives that the TS formatted command packets are corrupted data and/or irrelevant data. The proprietary/conventional decoder 320 then discards the TS formatted command packets. This embodiment of the present invention, as shown in the FIG. 3, shows that even the proprietary/conventional decoder 320 is operable to receive and decoded, and even to playback, a TS 315 that is encoded using certain aspects of the present invention including embedding TS formatted command packets into the TS 315. The TS formatted command packets do not substantially interfere with the normal playback of the TS. That is to say, in the context of video playback, there is not substantial interference with the playback of the video data such that a viewer will perceive a substantial reduction in perceptual quality. Analogously, in the in the context of audio playback, there will not be a substantial interference with the playback of the audio data such that a listener will perceive a substantial reduction in perceptual quality.
  • This embodiment shows the backward compatibility of a TS that is encoded in accordance with certain aspects of the present invention. A system capable to perform decoding of the command packets, and also a system incapable to do so, may both receive a TS that is encoded using the present invention. Certain aspects of the present invention may be implemented in new and older systems without introducing any deleterious reduction in performance. [0050]
  • FIG. 4 is a system diagram illustrating an embodiment of motion picture expert group (MPEG) transport stream (TS) [0051] content 400 that is configured in accordance with certain aspects of the present invention. The MPEG TS content 400 includes an MPEG TS 410. The MPEG TS 410 includes data 420 and TS formatted trick play commands 430. The data 410 may include any one or combination of video data 422, audio data 424, . . . , and any other data type 429 as understood by those persons having skill in the art. The TS formatted trick play commands 430 may include any one or combination of commands that direct functions of pause/still 431, fast forward 432, rewind 433, slow forward 434, slow rewind 436, skip 436, . . . , and any other commands 439 as understood by those persons having skill in the art. There may also be subsets of each of the command included within the TS formatted trick play commands 430. For example, the fast forward 432 may also include options to perform FF at varying rates, such as ½×, 2×, 3×, etc. Similarly, the rewind 432 may also include options to perform REW at varying rates, such as ½×, 2×, 3×, etc. The other command may also include other variations as well.
  • Those persons having skill in the art will recognize that the [0052] data 420 within the MPEG TS 410 is formatted in a particular manner to enable and comply with MPEG TS formatting requirements. In addition, a command packet including any one or more of the TS formatted trick play commands 430 within the MPEG TS 410 are formatted in a particular manner to enable and comply with MPEG TS formatting requirements.
  • Moreover, certain aspects of the present invention are extendible to other variations as well. For example, other TS data formats may similarly benefit from the present invention. In other contexts, command packets may be formatted into a proper TS format and inserted within the TS as well. Certain embodiments of the present invention are geared specifically to accommodate MPEG TSs, but those persons having skill in the art will recognize that the principle of embedding command packets, the command packets being formatted in similar manner that the data is formatted within the TS format, may be employed in other application contexts as well. The implementation of these aspects will assist in the ability to eliminate a great deal of communication, command, and control interfacing between various components within personal video recorders and other systems that seek to perform decoding and presentation of data that is received via a TS. [0053]
  • FIG. 5 is a system diagram illustrating an embodiment of a simplified digital [0054] channel recording process 500 that is performed in accordance with certain aspects of the present invention. The FIG. 5 shows one embodiment where digital channel recording may be performed, in a simplified manner when compared to previous systems, using certain aspects of the present invention. The recording process of digital video stream is given in the FIG. 1. In this embodiment, a personal video recorder (PVR) digital-channel-recording process can be described as shown below.
  • The selected video service will be contained in a transport stream (TS) that is received as shown in a radio frequency (RF) signal that is received by a [0055] tuner 510. The tuner 510 is operable to down-convert the channel that contains the transport stream, from RF to intermediate frequency (IF). The Demodulation block, shown as a demodulator 515, demodulates the IF to base-band digital data and outputs the transport stream (shown as an MPEG TS) and sends the data to the decryption block 520.
  • The [0056] decryption block 520 decrypt the packets of the TS into clear data if the service is authorized. This output TS stream goes to the Data Transport Processor 525. The Data Transport Processor selects only the requested service and then re-multiplexes it into a new TS and stores the new TS data in a TS FIFO buffer 532 in synchronous dynamic random access memory (SDRAM) 530.
  • This new TS is then transferred to a [0057] hard disk 550. The data within the TS FIFO buffer 532 is operable to be communicates to the hard disk 550. The CPU 540 controls the storing of the data from the TS FIFO 532 to the hard drive (hard disk 550). This is done using DMA engines which sends the data over the PCI bus 541 to the super I/O controller chip 545 containing the IDE interface to the hard drive (hard disk 550) itself. If desired, the IDE ATA-3 Advanced Technology Attachment Interface with Extensions—AT Attachment 3 Interface protocol is employed between the super I/O controller chip 545 and the hard disk 550. A Start Code Index Table (SCIT) 551 is also generated and stored in the hard disk 550 (see the next section for detailed description). A TS file 552 is then stored within the hard disk 552. This TS file 552 may include exclusively data portions and also command packet portions in various embodiments.
  • The embodiment of the present invention shown in the FIG. 5 shows how a TS may be generated and stored in a [0058] hard disk 550 as will be understood by those persons having skill in the art. When the TS file 552 may then be read from the hard disk 550, TS formatted command packets may then also be inserted within the TS stream that is extracted from the TS file 552. Those persons having skill in the art will recognize that TS formatted command packets may be inserted into a TS at any time without compromising the quality of the data contained within the TS.
  • FIG. 6 is a system diagram illustrating an embodiment of an analog [0059] channel recording process 600 that is performed in accordance with certain aspects of the present invention. A personal video recorder can accept an analog channel from either the tuner or from the baseband line inputs on the back panel of its device.
  • The analog channel record path for each of these two cases may be described as shown below. A [0060] tuner 610 receives a radio frequency (RF) signal and down-convert the selected channel to an intermediate frequency (IF) signal. The IF signal is then passed to the analog descramble block 616. The analog descramble block 616 will then demodulate the IF to base-band analog video and audio. If the channel is encrypted, the analog descramble block 616 will also decrypt the signals (provided that it is authorized to do so). The video component from the analog descramble block 616 is passed to a video switcher block 618 from which an analog video signal is passed to a video decoder 620. The video switcher block 620 also receives a line in video signal as well. The analog audio signal, from the analog descramble block 616, is passed to an audio analog to digital converter (ADC) 672. Another audio ADC 671 is placed in parallel with the audio ADC 672; the audio ADC 671 receives a lien in audio signal. The outputs from the outputs from both the audio ADCs 671 and 672 are provided as serial I2S data streams and compresses them and multiplexes them (using MUX 675) into a serial I2S data stream that is provided to an MPEG audio encoder block 681 within the MPEG encoder chip 680.
  • After the video component is then passed to the [0061] video decoder 620, the video decoder 620 converts it to an 8 bit parallel data stream that is then sent to an MPEG video encoder block 682 within an MPEG encoder chip 680. The MPEG encoder chip 680 accepts the digitized video (in CCIR656 format, if desired) and digitized audio (from the MUX 675) and compresses them and then multiplexes them (using a MUX 675) to an MPEG TS. The MPEG TS is a MPEG 2 Transport Stream in one particular embodiment. If desired, this now digitized MPEG TS may be communicated to other devices via a PCI bus 641. The MPEG TS is then passed to a data transport processor 626. The TS processing in the data transport processor 626 stores the data in a TS FIFO buffer 632 in a SDRAM 630. A CPU 640 controls storing the data from the TS FIFO 632 to the hard drive/hard drive 660. This may be performed using any one or more of various DMA engines that send the data over a PCI bus 641 (after having passed through a PCI I/F 636) to a super I/O controller chip 646 containing the IDE interface to the hard drive/hard disk 660 itself. Again, the interfacing between the super I/O controller chip 646 and the hard disk 660 may be performed using the IDE ATA-3 protocol. The start code index table (SCIT) is also generated and stored in the hard drive/hard disk 660. Ultimately, a TS file 662 is stored on the hard disk 660. The TS file 662 may then be retrieved for playback or for transmission to other components or devices.
  • The embodiment of the present invention shown in the FIG. 5 shows how a TS may be generated and stored in a [0062] hard disk 660 as will be understood by those persons having skill in the art. When the TS file 662 may then be read from the hard disk 660, TS formatted command packets may then also be inserted within the TS stream that is extracted from the TS file 662. Those persons having skill in the art will recognize that TS formatted command packets may be inserted into a TS at any time without compromising the quality of the data contained within the TS.
  • FIG. 7 is a system diagram illustrating an embodiment of a [0063] video playback process 700 that is performed in accordance with certain aspects of the present invention. The particular example of video data retrieval and playback is shown in the FIG. 7, but those persons having skill in the art will appreciate that these aspects of the present invention are also extendible to retrieval and playback of other types of data, including audio data and other digital data types.
  • For a program recorded on the hard drive/[0064] hard disk 710, a personal video recorder, or other operable system, can play back that program using the steps described below in the system diagram of the FIG. 7. A processor, that may include a CPU 790, reads the TS data (shown as the TS file 712) from the hard drive/hard disk 710 based on the user selected playback mode. The correct TS data (from the TS file 712 within the hard drive/hard disk 710) is read into TS presentation buffer 732 within a SDRAM 730 using DMA engines.
  • Data may be read from the hard drive/[0065] hard disk 710 in a similar to the manner in which data is written into the hard drive/hard disk 710, a super I/O controller chip 720 may communicatively couple with the hard disk 710 and perform data transfer using the IDE ATA-3 protocol. The super I/O controller chip 720 then communicatively couples to the TS presentation buffer 732 within the SDRAM 730 via a PCI bus 723 and a PCI I/F 725. The data is output from the TS presentation buffer 732 and is then passed to a data transport processor 735. The data transport processor then de-multiplex the TS into its PES constituents and passes the audio TS to an audio decoder 760 and the video TS to a video transport processor 740 and then to a MPEG video decoder 745 that is operable to decode and extract embedded, TS formatted command packets, that may include instructions to perform trick play functionality. The audio data is then sent to the output blocks, and the video is sent to a display engine 750. The display engine 750 is responsible for and operable to perform scaling the video picture, rendering the graphics, and constructing the complete display among other functions. Once the display is ready to be presented, it is passed to a video encoder 755 where it is converted to analog video using an internal digital to analog converter (DAC). The digital audio is converted to analog in the audio digital to analog converter (DAC) 765 while a Sony Philips Digital Inter-Face (SPDIF) output stream is also generated and transmitted.
  • The FIG. 7 shows just one embodiment where a digital signal may be retrieved from a hard disk and transformed for playback. Those persons having skill in the art will also appreciate that any number of TS formatted command packets, contained within the TS file [0066] 712 as it is stored in the hard disk 710, or that are inserted into the TS during its transport throughout a personal video recorder or a video playback system. An MPEG video decoder, such as the MPEG video decoder 745, that is operable to decode, interpret, and perform the commands included within the TS may perform the directed functions without necessitating the large degree of command and control interfacing that is required in previous systems. The ability to include commands, within TS formatted command packets within a TS, eliminates a great deal of interfacing and also greatly reduces the real estate consumption within a system that performs such functions. Again, if the decoder is inoperable to decode these TS formatted command packets, then they will simply be identified as corrupted data within the TS and ignored and discarded. Clearly, the these TS formatted command packets may alternatively be identified as being irrelevant data within the TS and ignored and may also be discarded.
  • FIG. 8 is a functional block diagram illustrating an embodiment of a [0067] command packet method 800 that is performed in accordance with certain aspects of the present invention. In a block 810, a command is formatted into a packet having a TS format. Then, the TS formatted command packet is encoded/inserted into the TS in a block 820. Various decisions may be used to determine where particularly the TS formatted command packet(s) is/are to be inserted within the TS. Then, in a block 830, the TS (having the TS formatted command packets) is decoded where the commands within the TS formatted command packets are extracted. In a block 840, the appropriate playback is performed using the commands that were retrieved from the TS formatted command packets.
  • Very generically, the embodiment of the present invention shown in the FIG. 8 shows how commands may be formatted into TS format, then inserted or encoded into a TS. Then, during the decoding of the TS, those previously encoded commands may be extracted during the decoding of the various packets of the TS. The present invention is adaptable to encoding commands, including trick play commands, into MPEG TS format and then inserting those TS formatted command packets commands into an MPEG TS. The TS formatted command packets may include how to handle the entirety of the data within the TS, or portions of data within the TS. Those persons having skill in the art will appreciate that a number of TS formatted command packets may be included within a given TS and various portions of data within the TS may be handled differently. For example, normal playback may be performed on one portion, fast forward (FF) may be performed on another portion, rewind (REW) may be performed on yet another portion, and so on. By embedding commands within the TS itself, using certain aspects of the present invention, the great deal of interfacing between various components may be greatly reduced. [0068]
  • FIG. 9 is a functional block diagram illustrating an embodiment of a transport stream (TS) [0069] decoding method 900 that is performed in accordance with certain aspects of the present invention. In a block 910, points within an MPEG TS are marked to allow for efficient decoding of the TS. The TS has one or more TS formatted command packets contained within it. Then, in a block 920, an entry point (EP) picture of the TS is calculated based on certain parameters of the TS. As shown in a block 925, certain of the parameters 925 may include parameters indicating a trick play mode 926, a current location 927, a number of possible entry points 928, . . . , and any other parameter 929 that may be desired in a particular application.
  • Then, in a [0070] block 930, the selected operation, as provided within a TS formatted command packet contained within the TS, is performed on the MPEG TS at the EP picture of the TS. The various operations 935 may include any number of operations as described here and in other embodiments of the present invention. For example, the operations 935 may include operations such as trick play 936, playback 937, . . . , and any other operation 939 that may be desired in a particular application.
  • As shown in this particular embodiment, a command may be included within a TS, as a TS formatted command packet, and the then decoded command packet may be used to govern the handling of portions of the TS. In addition, those persons having skill in the art will appreciate that the EP picture may be calculated at any desired point within the TS, as governed by the use and consideration of one or more of the [0071] parameters 925.
  • From other perspectives, in order to support trick-play modes on playback, a decoder needs a way to randomly access the recorded TS that has been stored on a hard drive. The decoder also needs to be able to maintain its real time display by limiting the data transferred to only those data that are required for building the pictures corresponding to the selected trick-play mode. One way to achieve this is to mark certain entry points in the stream that would efficiently allow a complete picture to be decoded (as shown in the block [0072] 910). The CPU could then compute the next entry point of the stream based on the current trick-play mode, its current location, and the set of possible entry points (as shown in the block 920). Then, the appropriate operation may be performed on portions of the TS (as shown in the block 930).
  • Also, it will be appreciated that various command operations may be associated with various portions of the TS. As mentioned above in various embodiments, normal playback may be performed on one portion, fast forward (FF) may be performed on another portion, rewind (REW) may be performed on yet another portion, and so on. [0073]
  • The structure of the TS formatted command packets may take on various forms without departing from the scope and spirit of the invention. Any format where the command packets may be formatted so that they may be inserted within the TS and transported in the similar manner in which the TS is communicated. The present invention is adaptable to MPEG-2 TS formats as well other TS formats where command packets are encoded into TS formatted command packets so that the command may be extracted when the TS formatted command packet is decoded. [0074]
  • One embodiment of the structure and organization of a MPEG-2 TS formatted command packet (as included within an MPEG-2 TS) that may be employed in a personal video recorder or other system, is described below as follows: [0075]
  • The collection of data points that include entry points for a video stream forms a Start Code Index Table (SCIT), and the SCIT is stored in the hard drive in a recording processes (see FIGS. 5 and 6 for two possible embodiments). The SCIT provides important information about the location of all the non-slice start codes (including the PES Start codes), and only the first slice code following a non-slice start code in a record buffer. More specifically, the SCIT contains the following fields: [0076]
  • 1. The start code value (SCV) [0077]
  • 2. Two bytes following the start code value (SCV): The two bytes following the slice start code can be used to check the intra_slice and intra_slice_flag fields to determine the entry point picture. In a Progressive Refresh MPEG-2 bit stream (see Appendix for definition), pictures that have the first row (slice) as Intra are deemed to be the Entry Point (EP) pictures. The CPU uses the pointer of the first slice of every picture and inspects the data in the Elementary Stream. The format of the elementary stream is as follows: [0078]
    {
    slice_start_code 32 bits
    quantiser_scale_code  5 bits
    if(nextbits() == '1'){
    intra_slice_flag  1 bit
    intra_slice
     1 bit
    reserved_bits  7 bits
    while(nextbits() == '1') {
    extra_bit_slice /* value of 1 */  1 bit
    extra_information_slice  8 bits
    }
    }
    extra_bit_slice /* value of 0 */  1 bit
    ...
  • The CPU then has to inspect the field intra_slice_flag. If it is found to be set, the next field intra slice is inspected. If that is found to be a ‘1’, then the slice is deemed to be an intra slice. If the first slice is found to be an intra Slice, this picture is marked as an Entry point picture. If the intra_slice_flag is zero, or intra_slice is zero, then this slice is not an intra slice and hence this picture is not an Entry Point picture. [0079]
  • 3. Packet offset: This gives the offset in bytes of the first zero byte of a start code pattern 00 00 01 SCV from the start of that packet. [0080]
  • 4. Record count: Record count gives the number of bytes from the start of this record session to the start of the transport packet containing the start code for this entry. A count of zero indicates the first byte in this session. [0081]
  • 5. Flag to indicate if any packets were dropped [0082]
  • 6. Flag to indicate if any continuity counter error was detected [0083]
  • 7. Flag to indicate if the transport error indicator was set in one of the recorded packets (MPEG) [0084]
  • 8. Flag to indicate if a start code index entry was dropped due to internal buffer overflow [0085]
  • 9. Flag to indicate if the previous PES packet had an error in its length [0086]
  • Note: If the SCV reads a value of 0xFE, then the rest of the fields give the PTS values and not the ones mentioned above. [0087]
  • An SCIT can be described in the following table. The range of values M[0088] 1, M2 . . . can be between 0 and 187 corresponding to size of the TS packet.
    Packet Record Entry
    SCV Offset Count Picture . . . . . . . . . . . . . . .
    E0 M1 N1 NO . . . . . . . . . . . . . . .
    B3 M2 N2 NO . . . . . . . . . . . . . . .
    B8 M3 N3 NO . . . . . . . . . . . . . . .
    00 M4 N4 NO . . . . . . . . . . . . . . .
    . . . . . . . . . . . . . . . . . . . . . . . . . . .
    . . . . . . . . . . . . . . . . . . . . . . . . . . .
    01 M6 N6 YES . . . . . . . . . . . . . . .
    00 M7 N7 NO . . . . . . . . . . . . . . .
    . . . . . . . . . . . . . . . . . . . . . . . . . . .
    . . . . . . . . . . . . . . . . . . . . . . . . . . .
    01 M10 N10 NO . . . . . . . . . . . . . . .
    00 M11 N11 NO . . . . . . . . . . . . . . .
    . . . . . . . . . . . . . . . . . . . . . . . . . . .
    . . . . . . . . . . . . . . . . . . . . . . . . . . .
    01 M14 N14 NO . . . . . . . . . . . . . . .
    . . . . . . . . . . . . . . . . . . . . . . . . . . .
    . . . . . . . . . . . . . . . . . . . . . . . . . . .
    . . . . . . . . . . . . . . . . . . . . . . . . . . .
    . . . . . . . . . . . . . . . . . . . . . . . . . . .
    00 M48 N48 NO . . . . . . . . . . . . . . .
    . . . . . . . . . . . . . . . . . . . . . . . . . . .
    . . . . . . . . . . . . . . . . . . . . . . . . . . .
    01 M50 N50 YES . . . . . . . . . . . . . . .
    . . . . . . . . . . . . . . . . . . . . . . . . . . .
    . . . . . . . . . . . . . . . . . . . . . . . . . . .
  • It is also noted that the CPU picks the SCIT and linearizes the addresses as it writes to the hard disk. The packet offset and the record count points to the start code in the record life. [0089]
  • FIG. 10 is a functional block diagram illustrating an embodiment of a transport stream (TS) transport/parse method [0090] 1000 that is performed in accordance with certain aspects of the present invention. In a block 1010, a TS is received. This may include receipt of multiple packets within a TS or a single packet within a TS. Alternatively, the entirety of the TS may be received in the block 1010. From certain perspectives, a Data Transport driver (DTD), built in accordance with certain aspects of the present invention, is responsible for data flow of the stream to be played back through a Data Transport (and/or Video Transport) Processor. In a block 1020, the DTD will also insert a “Transport Packet” (TP) into the actual TRANSPORT STREAM; the TP may be viewed as being Transport Command Packet(s)—containing various commands. The TP may be referred to as another terminology for a TS formatted command packet as described in other of the various embodiments of the present invention. The terminology of a TP and a TS formatted command packet may be used interchangeably. Then, in a block 1030, the TS (that now contains the TS formatted command packet) is transmitted to a Video Transport Processor (VTP) and a Video decoder. Thereafter, in a block 1040, that TP (or TS formatted command packet) is then identified. There exist several options understood by those persons having skill in the art for uniquely identifying a type of packet from among a group of packets. Here, the TP/TS formatted command packet is identified using any of a number of methods. The “Transport Packet”/TS formatted command packet that contains the command fields.
  • There exist a number of options in which to parse the command structure of a TP/TS formatted command packet. Two particular embodiments are described in the FIG. 10. [0091]
  • A first option: [0092]
  • In a [0093] block 1050, the process identification (PID) number of the TP/TS formatted command packet is identified. If desired, a CPU indicates the PID number of the TP. Then, in a block 1060, this detected PID number is provided to a Video Transport Processor (VTP). Then, in a block 1070, a command structure is parsed accordingly. This may be performed using the VTP. It is also noted that this option means that firmware flow must then be disturbed to accommodate handling of such PID numbers.
  • A second option: [0094]
  • In this option, the PID number of the TP/TS formatted command packet is the same as the video PID number, as shown in a functional block [0095] 1055. If desired in this situation, the command packet contains an Adaptation Field only and no payload, as shown in a functional block 1057. Then, in a block 1065, the command structure is placed in a private field of the adaptation field. Then, a signature uniquely identifies this packet as a TP/TS formatted command packet in a block 1075. A 32-bit signature may be used in certain embodiments. In addition, a continuity_counter of the TP/TS formatted command packet is ignored as shown in a block 1077 within the functional block 1075.
  • Some other considerations may be implemented to perform this second option as well. The field structure of the TP/TS formatted command packet is shown in the table below. All the Video related command/parameter fields are explained in the next section. [0096]
    FIELD NO OF BITS VALUE
    SYNC_BYTE 8 47H
    TRANSPORT_ERROR_INDICATOR
    1 0
    PAYLOAD_UNIT_START_INDICATOR 1 0
    TRANSPORT_PRIORITY 1 0
    PID 13 VIDEO_PID in Hex
    TRANSPORT_SCRAMBLING_CONTROL 2 00B
    ADAPTATION_FIELD_CONTROL 2 10B
    CONTINUITY_COUNTER 4 X
    ADAPTATION_FIELD_LENGTH 8 183D
    ADAPTATION_FLAG 8 02H or 82H
    TRANSPORT_PRIVATE_DATA_LENGTH 8 15D
    ALIGN_BYTE 8 0
    SIGNATURE_32BITS 32 4252434DH
    MODE 32 MODE
    SKIP_COUNT 32 SKIP_COUNT
    DISPLAY_COUNT 32 DISPLAY_COUNT
    PICTURE_START_PACKET 32 PICTURE_START_PACKET
    PICTURE_START_BYTE 32 PICTURE_START_BYTE
    PICTURE_END_PACKET 32 PICTURE_END_PACKET
    PICTURE_END_BYTE 32 PICTURE_END_BYTE
    DISCARD_HEADEND 32 DISCARD_HEADEND
    DISCARD_TAILEND 32 DISCARD_TAILEND
    DXPORT_VALUE 32 DXPORT_VALUE
    STUFFING_BYTE 132 bytes XX
  • A TP/TS formatted command packet shall come prior to the packet containing the corresponding PICTURE_START. The command in a TP/TS formatted command packet is valid over all the pictures given by the command and all the packets given by the PICTURE_START and PICTURE_END fields. This means that a TP/TS formatted command packet can be encountered by the Video Transport before the count provided by the previous TP/TS formatted command packet. [0097]
  • FIG. 11 is a functional block diagram illustrating an embodiment of [0098] playback method options 1100 that may be performed in accordance with certain aspects of the present invention. The playback that may be performed using aspects of the present invention essentially fall into three different modes, Normal playback 1110, Fast Forward 1120, and Rewind 1130. A user should be able to switch between these modes with minimal distortions at changeovers. During Playback, a CPU reads the data from the hard disk and places it in Playback buffers in the DRAM belonging to the chip. The CPU operates on segments of the elementary stream (ES) from one Entry Point (EP) picture to the other. It determines the EP picture by inspecting the two bytes following the start code value (SCV).
  • FIG. 12 is a functional block diagram illustrating an embodiment of a [0099] playback method 1200 that is performed in accordance with certain aspects of the present invention. During Playback, data is read from memory in a block 1210. This reading of data is from the hard disk in certain embodiments. Then, in a block 1220, the data is placed in a playback buffer. These playback buffers are in the DRAM belonging to the chip, as shown in a block 1225 in certain embodiments. Then, in a block 1230, the data segments of the elementary stream (ES) from one entry point (EP) picture to the other EP picture of the data segment. Moreover, the determination of the EP picture is made by inspecting the two bytes following the start code value (SCV) as shown in a block 1235.
  • FIG. 13 is a functional block diagram illustrating an embodiment of a video [0100] transport processing method 1300 that is performed in accordance with certain aspects of the present invention. In the Transport based PROGRESSIVE REFRESH STREAM, the VIDEO TRANSPORT PROCESSOR is responsible for sending the elementary stream (ES) with proper boundaries to the VBV (compressed data buffer). This may be described as shown in a block 1310 where an elementary stream (ES) with the proper boundaries is sent to the VBV (compressed data buffer). It also passes some of the command parameters in the TP/TS formatted command packet to the MPEG VIDEO DECODER through a start code table (SCT) Buffer. This may be described as shown in a functional block 1320. It is also noted that this SCT buffer should not be confused with the SCIT generated in the data transport.
  • The data flow of the Playback stream is described below in the following Figures and disclosure during the different modes of operation. The following notations are presented to assist in explaining the data flow of a TS in accordance with certain aspects of the present invention. [0101]
  • EP[0102] m denotes the mth Entry Point Picture, where m is an integer, that represents an arbitrary entry point.
  • P[0103] m.n denotes nth Picture after mth Entry Point Picture, where m and n are integers. This means that Pm.0 are the pictures with intra-slice fields set.
  • EP[0104] m to EPm+1 form segment m, EPm+1 to EPm+2 form segment m+1 and so on
  • TPB[0105] i,j means the Transport Packet Byte at an offset j from byte zero in the transport packet ii from the current packet. This will be used extensively for pointing to a start code and the packet containing it from the TP/TS formatted command packet.
  • The following commands need to be given by the Data Transport to the VIDEO TRANSPORT PROCESSOR through the TP/TS formatted command packet. The command is applicable for all the pictures following this TP/TS formatted command packet till the picture pointed by the next TP/TS formatted command packet. Here, a “command” means the concatenation of all the following fields. [0106]
  • MODE: This field gives the following commands to the Video Transport and the Decoder [0107]
  • 00 PLAY [0108]
  • 01 DISPLAY [0109]
  • 02 BUILD_REFERENCE [0110]
  • 03 PROCESS [0111]
  • 04 DISCARD_TILL_BTP [0112]
  • PLAY: This command puts the Video Decoder in the normal mode. The pictures following this command are treated as any normal stream by the decoder. [0113]
  • DISPLAY: This command puts the Video Decoder in the display mode. For a given picture sequence, the Video Decoder decodes all the pictures but displays only the last of the “displayable” picture [0114]
  • BUILD_REFERENCE: This command puts the Video Decoder in the decode mode. For a given segment, the Video Decoder builds a reference picture. [0115]
  • PROCESS: This command causes the Video Transport to process DISCARD_HEADEND and DISCARD_TAILEND only. The SKIP_COUNT and DISPLAY_COUNT fields are not sent to the Video Decoder. This command is meant for Video Transport. [0116]
  • But note that the DISCARD_HEADEND and DISCARD_TAILEND fields are processed for all the above commands. [0117]
  • DISCARD_TILL_BTP: This causes the Video Transport to discard only the video ES data bytes starting from the transport packet that follows till the next BTP for that PID. When this field is zero, the Video Transport will not discard ES till the next BTP. [0118]
  • SKIP_COUNT: This field specifies the number of pictures to be skipped before sending a picture to display. Using the Play command with a skip count of 1 achieves a fast forward (FF) of ×2. If the picture to be skipped is a B picture, it is also skipped from processing. [0119]
  • DISPLAY_COUNT: This field specifies the number of displayable pictures starting from the picture that follows the TP/TS formatted command packet for which the corresponding command has to be used. [0120]
  • Typically, [0121]
  • this field will be “0” for BUILD_REFERENCE mode [0122]
  • this field will be “1” for Rewind mode [0123]
  • this field will be equal to number of pictures in an EP segment in the normal playback mode [0124]
  • this field will be equal to (int) ((number of pictures in an EP segment)/(skip_count+1)) [0125]
  • PICTURE_START: This field informs the location of the start of the first picture following a TP for which the command has to be applied, by pointing to the first byte of the start code sequence from the start of the packet in which it is present. This is represented by TPB[0126] i,j.
  • PICTURE_END: This field informs the location of the start of a picture following a TP/TS formatted command packet over which the command has to be applied. This means the command is valid for all the pictures starting from the PICTURE_START till the picture preceding the one indicated by this field. This is represented by TPB[0127] i,j and gives first byte of the start code sequence from the start of that packet.
  • DISCARD_HEADEND: This enables the Video Transport to discard all the bytes from the start of the payload till the offset mentioned in this field. A value of 0 means no byte has to be discarded. [0128]
  • This field is useful in case of Fast Forward and for decoding the sequence header [0129]
  • DISCARD_TAILEND: This enables the Video Transport to discard all the bytes from the offset mentioned in this field till the end of the packet. A value of 0 means no byte has to be discarded. [0130]
  • This field is useful in case of Fast Forward and for decoding the sequence header. [0131]
  • DXPORT_VALUE: The value in this field is used for piggybacking in the one of the non-slice entry in the SCV table. During the trick mode changes, the Video Decoder returns this value whenever the data transport driver calls a get(DXPORT_VALUE) function. This value could be a PTS value or an offset in the SCIT table. This ensures a quick response during the trick mode changes. [0132]
  • It is also noted that a “command” is applicable over all the pictures present between PICTURE_START and PICTURE_END. Again, the command may be extracted from a TP/TS formatted command packet. [0133]
  • FIG. 14 is a functional block diagram illustrating an embodiment of a [0134] normal playback method 1400 that is performed in accordance with certain aspects of the present invention. Now, using the general mechanism and the commands listed above, the normal playback method 1400 may be achieved in the following manner. In a block 1405, a CPU refers to the start code index table (SCIT) that it had picked during the record function. Then, in a block 1410, the CPU finds a Sequence Header (SH) in the SCIT and begins to feed the data from that Sequence Header until the beginning of the picture following the Sequence Header.
  • If the next picture is an entry point (EP) picture, then it continues to feed the data from that picture as shown in a [0135] block 1415. However there is an exception. If the first picture after the Sequence header and the corresponding extensions is not an EP picture, then the CPU searches the SCIT for the first EP picture and begins feeding data from that point till the beginning of the next EP picture as shown in a block 1417 within the functional block 1415.
  • In a [0136] block 1420, the CPU also inserts a TP/TS formatted command packet (containing the command) for the VIDEO TRANSPORT PROCESSOR and the video decoder. The MODE is set for PLAY in a block 1425, and the SKIP_COUNT is programmed to zero in a block 1435. Then, in a block 1440, the DISPLAY_COUNT field informs the number of pictures to be displayed. Typically, this value is the number of pictures in an EP segment as shown in a block 1442. Then, the VIDEO TRANSPORT PROCESSOR is placed in the Transport Mode in a block 1445. The VIDEO TRANSPORT PROCESSOR transfers the commands to the video decoder through the start code table (SCT) in a block 1450. The Video decoder then picks a command from the Start Code Table (SCT) buffer 1460. The command is then decode in a block 1470, and the command tells the video decoder that it is Normal Playback, and then this would also give the number of pictures that command has been issued for. Ultimately, the Compressed Data Buffer (VBV) Manager is kicked off to read data from the VBV and feed it to the Parser and the Row Decoders as shown in a block 1475.
  • It is also noted that wherever a mention is made of the CPU sending the pictures, it is assumed that it starts from the transport packet starting with the PES that contains the picture. Using the PICTURE_START and PICTURE_END fields, the Video Transport will get to the right byte of the elementary stream in the transport packets. [0137]
  • The VIDEO TRANSPORT PROCESSOR is responsible for extracting from the Transport packets and sending the ES with proper boundaries to the VBV (compressed data buffer). It also passes the Video related commands/parameters in the TP to the MPEG VIDEO DECODER through SCT Buffer (this should not be confused with the SCIT generated in the data transport)for the video decoder. The VIDEO TRANSPORT PROCESSOR gets to the start and end of a picture by looking at the PICTURE_START and PICTURE_END fields, both of which, are represented by TPB[0138] i,j.
  • FIG. 15 is a functional block diagram illustrating an embodiment of a fast forward playback method [0139] 1500 that is performed in accordance with certain aspects of the present invention. There are many modes in which fast forward (FF) may be performed in accordance with the present invention. Two potential cases will be described below in the FIG. 15.
  • A first option is a mode in which the fast forward rate is such that there is a minimum of one frame to display over two segments as shown in a [0140] block 1505. In this case as shown in a block 1510, the CPU does not do anything different compared to the normal playback as far as feeding the data is concerned. One change, however, is that the SKIP_COUNT is a non-zero value as shown in a block 1515. A value of 1 would cause the Video Decoder to drop every other picture from the display process, achieving a Fast Forward rate of ×2.
  • A second option is a mode in which the fast forward rate is such that the adjacent pictures are placed over a minimum of three segments as shown in a [0141] block 1525. In this case, the CPU needs to do some scheduling of the data as shown in a block 1530.
  • For example, if a picture P[0142] m.n is to be displayed, a reference picture is built by feeding the segment between EPm−1 to EPm. The CPU needs to configure video in BUILD_REFERENCE mode. The SKIP_COUNT needs to be programmed to x-1 and DISPLAY_COUNT needs to be 0, where x is the total number of pictures in the segment.
  • The CPU then feeds the pictures P[0143] m,0 to Pm,n in the segment from EPm to EPm+1, which is to be used for the actual decode and display. The video has to be configured in PLAY mode. The CPU programs the DISPLAY_COUNT to 1 and the SKIP_COUNT with n−1 to display the picture Pm.n.
  • This second mode or case of fast forward is similar to the rewind, which is described in detail in the next section. [0144]
  • FIG. 16 is a functional block diagram illustrating an embodiment of a rewind playback data flow method [0145] 1600 that is performed in accordance with certain aspects of the present invention. During rewind, the CPU plays a major role in scheduling the data in the correct order. In order to correctly decode and display a particular frame, it is important that all the pictures before it were indeed created using “good” data. Since PROGRESSIVE REFRESH streams have no I pictures, but are progressively refreshed, the CPU first feeds an EP-EP segment into the Playback Buffers to build a good reference picture as shown in a block 1605. Then, the CPU needs to configure the video in BUILD_REFERENCE mode as shown in a block 1610.
  • In a [0146] block 1615, the SKIP_COUNT needs to be programmed to x-1 and DISPLAY_COUNT needs to be 0, where x is the total number of pictures in the segment. The CPU then feeds the next EP-EP segment, which is to be used for the actual decode and display, as shown in a block 1620. The CPU configures the video in REWIND mode s shown in a block 1625. Then, in a block 1630, the picture Pm,n is displayed. The DISPLAY_COUNT is set to 1 in a block 1632 and the SKIP_COUNT is set to n−1 in a block 1634 to display the picture Pm.n.
  • Then, in a [0147] block 1640, the backward rate of the rewind data flow is determined. If the CPU desires to go backwards at a ×1 rate (in a block 1642), then it resends the same segment that it supplied for the nth picture, every time reducing the SKIP_COUNT fields value by one (1). The CPU also inserts a TP/TS formatted command packet (containing the command) for the VIDEO TRANSPORT PROCESSOR and the video decoder.
  • FIG. 17 is a functional block diagram illustrating an embodiment of a rewind playback control flow method that is performed in accordance with certain aspects of the present invention. In a block [0148] 1705, the VIDEO TRANSPORT PROCESSOR transfers the commands from the TP/TS formatted command packet and places it in the Start Code Table (SCT) for use by video decoder. Then, in a block 1710, the Video decoder picks the command from the SCT and decides what to do with the data in the compressed data buffer (VBV). The command tells the video decoder that it is Rewind Build (using BUILD_REFERENCE, for example). The command also gives the number of pictures that it has been issued for in the block 1710.
  • Then, in a [0149] block 1715, the VBV Manager is kicked off to read data from the VBV. In a block 1720, the data is fed to a Parser. Since this is a REFERENCE_BUILD, the Buffer manager does not push any picture into the Display Queue. In a block 1725, if a B picture is encountered, the Buffer Manager sets a flag to indicate to the VBV manager to drop that picture from Decode. The VBV manager begins to start feeding the compressed data to the Row Decoders in a block 1730. The buffer manager uses all the three/four buffers in the BUILD_REFERENCE mode.
  • Then, in a [0150] block 1735, the Video decoder decodes the SKIP_COUNT number of pictures from the VBV. Once the SKIP_COUNT runs out, the last buffer that was used for decode is marked as “LockedReferenceBuffer” for future references in a block 1740. This Special lock is over and above the common “locked for decode” that exists in the design today. When the Video Decoder is configured in the REWIND command, the video decoder reads compressed data from the VBV to generate one displayable picture.
  • Then, in a [0151] block 1745, the command specifies the number of pictures that need to be decoded in order to display the desired picture. The Buffer Manager uses the “Locked” buffer as the buffer for Forward Prediction if it finds the ‘UseReferenceBuffer’ SET in a block 1750. It also clears the Flag so that it does not get used again for that Command session.
  • In a [0152] block 1755, all subsequent pictures are decoded normally, constantly updating the buffers that are used for Forward and Backward predictions. The buffer manager is careful not to overwrite the Locked Reference Buffer. In the Three buffers mode, since one of the buffers is Locked, the other two are used for the decoding of the I/P pictures and the B pictures are discarded. In the four buffer mode, the B pictures that are intended for Display are only decoded.
  • In a [0153] block 1760, the skip count is reduced for every picture that the Buffer Manager encounters. If a B picture is encountered, then the skip count is reduced and a flag is set to indicate the VBV manager to skip that picture. If the skip count becomes zero on a picture, then it is intended that, that picture has to be displayed. In the four buffer scheme, if that picture is a B picture, then we decode and display that picture. However, if we are working in the three buffer mode, then we will not even have a buffer to decode that B picture into as one of the buffers would be the Locked Reference frame and the other two would be carrying the current I/P Forward and Backward prediction reference frames. In such a scenario, the previously decoded picture, (the current Backward prediction buffer) is pushed for display queue.
  • Below an example is described to illustrate the operation of certain aspects of the present invention that are described above in the various embodiments of the present invention. [0154]
  • For example, if the pictures to be displayed are P[0155] m,n, Pm,n−1, Pm,n−2, Pm,n−3 and so on, following sequence needs to be followed:
  • A reference picture is built by feeding the segment between EP[0156] m−1 to EPm. To achieve this, the CPU needs to configure video in BUILD_REFERENCE command. The DISPLAY_COUNT needs to be programmed to 0 and SKIP_COUNT to x-1, where x is the total number of pictures in the segment.
  • The CPU then feeds the pictures from P[0157] m,0 to Pm,n in the segment from EPm to EPm+1, which is to be used for the actual decode and display. The CPU has to configure video in the REWIND mode. The DISPLAY_COUNT should be programmed to 1 and SKIP_COUNT to n−1 to display the picture Pm.n.
  • Similarly, the CPU again feeds the pictures from P[0158] m,0 to Pm,n−1 in the segment from EPm to EPm+1, which is to be used for the actual decode and display time. Again, the CPU needs to configure video in REWIND mode. But, this time, the DISPLAY_COUNT should be programmed to 1 and SKIP_COUNT to n−2 to display the picture display the picture Pm.n−1. The above process is repeated, decreasing the SKIP_COUNT, till the picture Pm.0 is displayed.
  • The decoding of the sequence headers is described below. From the SCIT, the CPU knows the packet that contains the sequence header. The CPU can send only the sequence header data to the video by sending a TP before the packet containing the sequence header. This TP could contain the command that instructs the VIDEO TRANSPORT PROCESSOR to discard the bytes between Transport Header and the PICTURE_START and/or to discard the bytes starting from the start code following the Sequence header till the end of the packet. The DISCARD_HEADEND and the DISCARD_TAILEND field have to be programmed accordingly. [0159]
  • For example, if a packet contains sequence header starts from byte offset [0160] 10 and the start code following it (and if this start code is not of interest at this point) starts at byte offset 150, the DISCARD_HEADEND and DISCARD_TAILEND should be programmed to 10 and 150 respectively. As long as the TP that follows next contains valid values, the other fields in this TP can have any value. The video is put in PROCESS mode.
  • In view of the above detailed description of the invention and associated drawings, other modifications and variations will now become apparent to those skilled in the art. It should also be apparent that such other modifications and variations may be effected without departing from the spirit and scope of the invention. [0161]
  • APPENDIX MPEG-2 Video in the Progressive-Refresh Mode
  • In an MPEG-2 coded bit stream, the coded picture following a group of pictures (GOP) header shall be a coded I-picture. However, if there is no GOP header in the bit stream, I-pictures are not mandated in the bit stream. One of “no I-picture” bit streams is called the progressive refresh bit stream by Motorola (DigiCipher II). [0162]
  • When the (DigiCipher II) encoder is configured for progressive refresh, the refresh depth is specified. This depth is ranged from 1 to 9 slices per P-picture to be refreshed. The default value is three slices per P-picture while B-pictures are enabled and one slice per P-picture while B-pictures are disabled. One typical configuration is six slices per P-picture while “two B-picture mode” is enabled. In the progressive refresh mode, both intra_slice_flag and intra_slice are set to “1” for the refreshed intra slices. [0163]
  • When the (DigiCipher II) encoder is configured for progressive refresh, the vertical search range for motion vectors in a P-picture is restricted. The motion vectors for the macro-blocks located above the refreshed slices in the current P-picture can only point to the region above the refreshed slices in the previous P-picture (as shown in FIG. 18). [0164]
  • The sequence header and extensions can be inserted before any P-picture, e.g. before second P-picture shown in FIG. 18. From certain perspectives, the FIG. 18 shows the motion vector search range for the progressive-refresh mode. [0165]

Claims (50)

What is claimed is:
1. A transport stream, comprising:
a data packet having a transport stream format; and
a command packet having a format that substantially complies with the transport stream format; and
wherein the command packet directs an operation to be performed on the packet.
2. The transport stream of claim 1, wherein the transport stream comprises a motion picture expert group, MPEG-2 transport stream.
3. The transport stream of claim 1, wherein the command packet comprises a header syntax that substantially follows an MPEG-2 transport header syntax.
4. The transport stream of claim 1, wherein a decoder decodes the command packet of the transport stream;
the decoder identifies a command within the command packet; and
the decoder executes the command on the data packet.
5. The transport stream of claim 1, wherein a decoder decodes the command packet of the transport stream;
the decoder identifies the command packet as an irrelevant data packet; and
the decoder discards the irrelevant data packet.
6. The transport stream of claim 1, wherein the command packet comprises at least one trick play operation.
7. The transport stream of claim 6, wherein the at least one trick play operation comprises at least one of pause/still, fast forward, rewind, slow forward, slow rewind, and skip.
8. The transport stream of claim 1, wherein the command packet is inserted into the transport stream.
9. The transport stream of claim 1, wherein the command packet precedes the data packet within the transport stream.
10. The transport stream of claim 1, wherein the transport stream is written to a hard disk.
11. The transport stream of claim 1, wherein the transport stream is read from a hard disk.
12. The transport stream of claim 1, wherein the command packet comprises a plurality of fields.
13. The transport stream of claim 12, wherein the plurality of fields comprises information related to a start picture and an end picture.
14. A transport stream decoding method, the method comprising:
receiving a motion picture expert group, MPEG-2 transport stream, the MPEG-2 transport stream comprises an MPEG-2 transport stream formatted command packet;
calculating an entry point picture within the MPEG-2 transport stream based on a parameter;
decoding the MPEG-2 transport stream formatted command packet, thereby identifying an operation; and
executing at least a portion of the operation at the entry point picture.
15. The method of claim 14, wherein the operation comprises at least one of playback and trick play.
16. The method of claim 15, wherein the trick play comprises at least one of pause/still, fast forward, rewind, slow forward, slow rewind, and skip.
17. The method of claim 14, wherein the parameter comprises at least one of a trick play mode, a current location within the MPEG-2 transport stream, and a plurality of possible entry point pictures within the MPEG-2 transport stream.
18. The method of claim 14, further comprising calculating at least one additional entry point picture within the MPEG-2 transport stream based on at least one additional parameter.
19. The method of claim 18, wherein the parameter and the at least one additional parameter each comprise a common parameter.
20. The method of claim 18, wherein the entry point picture comprises a start picture and the at least one additional entry point picture comprises an end picture.
21. The method of claim 14, wherein the MPEG-2 transport stream is read from a hard disk.
22. The method of claim 14, further comprising:
identifying the MPEG-2 transport stream formatted command packet as a corrupted data packet; and
discarding the corrupted data packet; and
wherein the MPEG-2 transport stream comprises a remaining MPEG-2 transport stream.
23. The method of claim 22, further comprising playing back the remaining MPEG-2 transport stream.
24. The method of claim 14, further comprising inserting at least one additional MPEG-2 transport stream formatted command packet into the MPEG-2 transport stream.
25. The method of claim 14, further comprising executing at least one additional portion of the operation on a plurality of data packets that come after the entry point picture within the MPEG-2 transport stream.
26. The method of claim 14, wherein the MPEG-2 transport stream is received from a host processor.
27. The method of claim 14, further comprising identifying at least one additional operation by decoding the MPEG-2 transport stream formatted command packet.
28. The method of claim 27, wherein the operation corresponds to a data packet within the MPEG-2 transport stream; and
the at least one additional operation corresponds to at least one additional data packet within the MPEG-2 transport stream.
29. The method of claim 14, wherein the MPEG-2 transport stream comprises at least one of video data and audio data.
30. A method to perform encoding and decoding of a motion picture expert group, MPEG-2 transport stream, the method comprising:
encoding data into a plurality of data packets having an MPEG-2 transport stream format;
encoding a command into a command packet having an MPEG-2 transport stream format;
generating an MPEG-2 transport stream, the MPEG-2 transport stream comprising the plurality of data packets and the command packet;
communicating the transport stream from a first device to a second device;
decoding the MPEG-2 transport stream, thereby extracting a portion of the data from the plurality of data packets and extracting the command from the command packet; and
performing the command on the portion of the data.
31. The method of claim 30, wherein at least one of the first device and the second device comprises a hard disk.
32. The method of claim 30, at least one of the first device and the second device comprises a host processor.
33. The method of claim 30, wherein command packet precedes a data packet within the plurality of data packets from which the portion of the data is extracted.
34. The method of claim 30, wherein the data is received via at least one of a digital channel and an analog channel.
35. The method of claim 30, further comprising displaying the portion of the data on a display.
36. The method of claim 30, wherein the encoding of the command into the command packet having the MPEG-2 transport stream format is performed substantially immediately before decoding the MPEG-2 transport stream.
37. The method of claim 30, further comprising identifying the command packet within the MPEG-2 transport stream.
38. The method of claim 37, wherein the command packet is identified during the decoding of the MPEG-2 transport stream.
39. The method of claim 30, wherein an MPEG video decoder performs the decoding of the MPEG-2 transport stream.
40. A motion picture expert group, MPEG-2 transport stream having command packets, comprising:
a plurality of data packets having MPEG-2 transport stream format; and
a command packet having MPEG-2 transport stream format; and
wherein the command packet directs an operation to be performed on a data packet within the plurality of data packets; and
the operation comprises trick play.
41. The MPEG-2 transport stream of claim 40, wherein the transport stream is communicated from a host processor to a display.
42. The MPEG-2 transport stream of claim 40, wherein a decoder decodes the command packet of the transport stream;
the decoder identifies the operation within the command packet; and
the decoder executes the operation on the data packet.
43. The MPEG-2 transport stream of claim 40, wherein a decoder decodes the command packet of the MPEG-2 transport stream;
the decoder identifies the command packet as an irrelevant data packet; and
the decoder discards the irrelevant data packet.
44. The MPEG-2 transport stream of claim 40, wherein the trick play operation comprises at least one of pause/still, fast forward, rewind, slow forward, slow rewind, and skip.
45. The MPEG-2 transport stream of claim 40, wherein the command packet is inserted into the MPEG-2 transport stream.
46. The MPEG-2 transport stream of claim 40, wherein the command packet precedes the data packet within the MPEG-2 transport stream.
47. The MPEG-2 transport stream of claim 40, wherein the MPEG-2 transport stream is written to a hard disk.
48. The MPEG-2 transport stream of claim 40, wherein the MPEG-2 transport stream is read from a hard disk.
49. The MPEG-2 transport stream of claim 40, wherein the command packet comprises a plurality of fields.
50. The MPEG-2 transport stream of claim 49, wherein the plurality of fields comprises information related to a start picture and an end picture.
US09/951,693 2001-09-12 2001-09-12 Command packets for personal video recorder Abandoned US20030093800A1 (en)

Priority Applications (9)

Application Number Priority Date Filing Date Title
US09/951,693 US20030093800A1 (en) 2001-09-12 2001-09-12 Command packets for personal video recorder
EP02798101A EP1442598A1 (en) 2001-09-12 2002-08-29 Command packets for personal video recorder technical field of the invention
PCT/US2002/027752 WO2003024113A1 (en) 2001-09-12 2002-08-29 Command packets for personal video recorder technical
US10/318,295 US8923688B2 (en) 2001-09-12 2002-12-11 Performing personal video recording (PVR) functions on digital video streams
US10/317,454 US20030121038A1 (en) 2001-09-12 2002-12-11 Caching system and method supporting improved trick mode performance in video decoding systems
US10/317,642 US7342967B2 (en) 2001-09-12 2002-12-11 System and method for enhancing performance of personal video recording (PVR) functions on hits digital video streams
US10/317,389 US7149248B2 (en) 2001-09-12 2002-12-11 Command packet system and method supporting improved trick mode performance in video decoding systems
US11/608,127 US8009741B2 (en) 2001-09-12 2006-12-07 Command packet system and method supporting improved trick mode performance in video decoding systems
US12/890,427 US9380337B2 (en) 2001-09-12 2010-09-24 Command packets for personal video recorder

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US09/951,693 US20030093800A1 (en) 2001-09-12 2001-09-12 Command packets for personal video recorder

Related Child Applications (6)

Application Number Title Priority Date Filing Date
US09/933,231 Continuation-In-Part US7174085B2 (en) 2001-08-20 2001-08-20 Apparatus and method of seamless switching between a live DTV decoding and a PVR playback
US10/317,642 Continuation-In-Part US7342967B2 (en) 2001-09-12 2002-12-11 System and method for enhancing performance of personal video recording (PVR) functions on hits digital video streams
US10/317,454 Continuation-In-Part US20030121038A1 (en) 2001-09-12 2002-12-11 Caching system and method supporting improved trick mode performance in video decoding systems
US10/318,295 Continuation-In-Part US8923688B2 (en) 2001-09-12 2002-12-11 Performing personal video recording (PVR) functions on digital video streams
US10/317,389 Continuation-In-Part US7149248B2 (en) 2001-09-12 2002-12-11 Command packet system and method supporting improved trick mode performance in video decoding systems
US12/890,427 Continuation US9380337B2 (en) 2001-09-12 2010-09-24 Command packets for personal video recorder

Publications (1)

Publication Number Publication Date
US20030093800A1 true US20030093800A1 (en) 2003-05-15

Family

ID=25492024

Family Applications (3)

Application Number Title Priority Date Filing Date
US09/951,693 Abandoned US20030093800A1 (en) 2001-09-12 2001-09-12 Command packets for personal video recorder
US10/317,642 Expired - Fee Related US7342967B2 (en) 2001-09-12 2002-12-11 System and method for enhancing performance of personal video recording (PVR) functions on hits digital video streams
US12/890,427 Expired - Lifetime US9380337B2 (en) 2001-09-12 2010-09-24 Command packets for personal video recorder

Family Applications After (2)

Application Number Title Priority Date Filing Date
US10/317,642 Expired - Fee Related US7342967B2 (en) 2001-09-12 2002-12-11 System and method for enhancing performance of personal video recording (PVR) functions on hits digital video streams
US12/890,427 Expired - Lifetime US9380337B2 (en) 2001-09-12 2010-09-24 Command packets for personal video recorder

Country Status (3)

Country Link
US (3) US20030093800A1 (en)
EP (1) EP1442598A1 (en)
WO (1) WO2003024113A1 (en)

Cited By (47)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030208767A1 (en) * 2002-05-03 2003-11-06 Williamson Louis D. Network based digital information and entertainment storage and delivery system
US20040015999A1 (en) * 2002-05-03 2004-01-22 Carlucci John B. Program storage, retrieval and management based on segmentation messages
US20040179611A1 (en) * 2003-02-05 2004-09-16 Akira Sota Image signal reproduction apparatus and image signal reproduction method
US20040218680A1 (en) * 1999-12-14 2004-11-04 Rodriguez Arturo A. System and method for adaptive video processing with coordinated resource allocation
US20040244058A1 (en) * 2002-05-03 2004-12-02 Carlucci John B. Programming content processing and management system and method
US20050022245A1 (en) * 2003-07-21 2005-01-27 Ramesh Nallur Seamless transition between video play-back modes
US20050074063A1 (en) * 2003-09-15 2005-04-07 Nair Ajith N. Resource-adaptive management of video storage
US20050120377A1 (en) * 2002-05-03 2005-06-02 Carlucci John B. Technique for effectively providing various entertainment services through a communications network
US20050259751A1 (en) * 2004-05-21 2005-11-24 Howard Brad T System and a method for controlling audio/video presentation on a sink device
US20060013568A1 (en) * 2004-07-14 2006-01-19 Rodriguez Arturo A System and method for playback of digital video pictures in compressed streams
US20060109861A1 (en) * 2004-11-22 2006-05-25 Sheng-Chi Tsao Apparatus with and a method for a dynamic interface protocol
US20060227775A1 (en) * 2005-04-12 2006-10-12 Arul Thangaraj System, method, and apparatus for embedding personal video recorder functions in transport packets
US20070134197A1 (en) * 2004-03-11 2007-06-14 Wolfram Eichner Conjugates of hydroxyalkyl starch and a protein, prepared by reductive amination
US20080037952A1 (en) * 2001-12-31 2008-02-14 Scientific-Atlanta, Inc. Annotations for trick modes of video streams with simultaneous processing and display
US20080115176A1 (en) * 2006-11-13 2008-05-15 Scientific-Atlanta, Inc. Indicating picture usefulness for playback optimization
US20080115175A1 (en) * 2006-11-13 2008-05-15 Rodriguez Arturo A System and method for signaling characteristics of pictures' interdependencies
US20080295621A1 (en) * 2003-10-16 2008-12-04 Sae Magnetics (H.K.) Ltd. Method and mechanism of the suspension resonance optimization for the hard disk driver
US20090033791A1 (en) * 2007-07-31 2009-02-05 Scientific-Atlanta, Inc. Video processing systems and methods
US20090100482A1 (en) * 2007-10-16 2009-04-16 Rodriguez Arturo A Conveyance of Concatenation Properties and Picture Orderness in a Video Stream
US20090148132A1 (en) * 2007-12-11 2009-06-11 Cisco Technology, Inc. Inferential processing to ascertain plural levels of picture interdependencies
US20090180547A1 (en) * 2008-01-09 2009-07-16 Rodriguez Arturo A Processing and managing pictures at the concatenation of two video streams
US20090220012A1 (en) * 2008-02-29 2009-09-03 Rodriguez Arturo A Signalling picture encoding schemes and associated picture properties
US7614066B2 (en) 2002-05-03 2009-11-03 Time Warner Interactive Video Group Inc. Use of multiple embedded messages in program signal streams
US20090310934A1 (en) * 2008-06-12 2009-12-17 Rodriguez Arturo A Picture interdependencies signals in context of mmco to assist stream manipulation
US20090313668A1 (en) * 2008-06-17 2009-12-17 Cisco Technology, Inc. Time-shifted transport of multi-latticed video for resiliency from burst-error effects
US20090323822A1 (en) * 2008-06-25 2009-12-31 Rodriguez Arturo A Support for blocking trick mode operations
US20100020878A1 (en) * 2008-07-25 2010-01-28 Liang Liang Transcoding for Systems Operating Under Plural Video Coding Specifications
US20100115575A1 (en) * 2008-11-03 2010-05-06 At&T Intellectual Property I, L.P. System and method for recording and distributing media content
US20100118974A1 (en) * 2008-11-12 2010-05-13 Rodriguez Arturo A Processing of a video program having plural processed representations of a single video signal for reconstruction and output
US20100215338A1 (en) * 2009-02-20 2010-08-26 Cisco Technology, Inc. Signalling of decodable sub-sequences
US20100218232A1 (en) * 2009-02-25 2010-08-26 Cisco Technology, Inc. Signalling of auxiliary information that assists processing of video according to various formats
US20100293571A1 (en) * 2009-05-12 2010-11-18 Cisco Technology, Inc. Signalling Buffer Characteristics for Splicing Operations of Video Streams
US20100322302A1 (en) * 2009-06-18 2010-12-23 Cisco Technology, Inc. Dynamic Streaming with Latticed Representations of Video
US7920623B2 (en) * 2003-11-14 2011-04-05 General Instrument Corporation Method and apparatus for simultaneous display of multiple audio/video programs transmitted over a digital link
US8234679B2 (en) 2005-04-01 2012-07-31 Time Warner Cable, Inc. Technique for selecting multiple entertainment programs to be provided over a communication network
US8265168B1 (en) * 2008-02-01 2012-09-11 Zenverge, Inc. Providing trick mode for video stream transmitted over network
US8416859B2 (en) 2006-11-13 2013-04-09 Cisco Technology, Inc. Signalling and extraction in compressed video of pictures belonging to interdependency tiers
US8443383B2 (en) 2002-05-03 2013-05-14 Time Warner Cable Enterprises Llc Use of messages in program signal streams by set-top terminals
US20130298177A1 (en) * 2011-01-18 2013-11-07 Samsung Electronics Co., Ltd. Method and apparatus for transmitting/receiving content in a broadcast system
US8699578B2 (en) 2008-06-17 2014-04-15 Cisco Technology, Inc. Methods and systems for processing multi-latticed video streams
US8782261B1 (en) 2009-04-03 2014-07-15 Cisco Technology, Inc. System and method for authorization of segment boundary notifications
US8788822B1 (en) * 2005-06-10 2014-07-22 Blue Coat Systems, Inc. Enhanced QoS solution for thin client or remote access sessions
US8804845B2 (en) 2007-07-31 2014-08-12 Cisco Technology, Inc. Non-enhancing media redundancy coding for mitigating transmission impairments
US8958486B2 (en) 2007-07-31 2015-02-17 Cisco Technology, Inc. Simultaneous processing of media and redundancy streams for mitigating impairments
US8971402B2 (en) 2008-06-17 2015-03-03 Cisco Technology, Inc. Processing of impaired and incomplete multi-latticed video streams
US9998750B2 (en) 2013-03-15 2018-06-12 Cisco Technology, Inc. Systems and methods for guided conversion of video from a first to a second compression format
CN108600753A (en) * 2011-12-29 2018-09-28 Lg 电子株式会社 Video coding and coding/decoding method and the device for using this method

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7149248B2 (en) * 2001-09-12 2006-12-12 Broadcom Corporation Command packet system and method supporting improved trick mode performance in video decoding systems
US8284844B2 (en) 2002-04-01 2012-10-09 Broadcom Corporation Video decoding system supporting multiple standards
JP5106671B1 (en) * 2011-09-30 2012-12-26 株式会社東芝 Electronic device and reproduction control method
US10452084B2 (en) * 2012-03-14 2019-10-22 Ademco Inc. Operation of building control via remote device
US9749679B2 (en) 2015-01-06 2017-08-29 Arris Enterprises Llc Method for efficient processing of BTP enabled MPEG4 stream
US10536757B2 (en) * 2017-08-17 2020-01-14 The Nielsen Company (Us), Llc Methods and apparatus to synthesize reference media signatures

Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5594552A (en) * 1992-10-30 1997-01-14 Sony Corporation Apparatus and method for producing downwards compatible video signals with increased vertical resolution, and apparatus for reproducing and displaying same
US5613190A (en) * 1995-05-01 1997-03-18 Bell Atlantic Network Services, Inc. Customer premise wireless distribution of audio-video, control signals and voice
US5737479A (en) * 1994-12-21 1998-04-07 Sony Corporation Apparatus and method for inserting rating code into the digital video signal
US5740307A (en) * 1995-06-07 1998-04-14 Hitachi America, Ltd. Methods for monitoring a trick play data stream to insure MPEG compliance
US5805762A (en) * 1993-01-13 1998-09-08 Hitachi America, Ltd. Video recording device compatible transmitter
US5838876A (en) * 1996-09-24 1998-11-17 Sony Corporation Frame-accurate edit and playback in digital stream recording
US6122433A (en) * 1994-10-20 2000-09-19 Thomson Licensing S.A. HDTV trick play stream derivation for VCR
US6236663B1 (en) * 1997-03-27 2001-05-22 Sony Corporation Information reproduction apparatus and information reproduction method
US6334026B1 (en) * 1998-06-26 2001-12-25 Lsi Logic Corporation On-screen display format reduces memory bandwidth for time-constrained on-screen display systems
US6363212B1 (en) * 1995-08-02 2002-03-26 Sony Corporation Apparatus and method for encoding and decoding digital video data
US6965724B1 (en) * 1995-03-30 2005-11-15 Thomson Licensing S.A. Trick-play modes for pre-encoded video

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5959659A (en) * 1995-11-06 1999-09-28 Stellar One Corporation MPEG-2 transport stream decoder having decoupled hardware architecture
US6157673A (en) * 1996-12-26 2000-12-05 Philips Electronics North America Corp. Fast extraction of program specific information from multiple transport streams
WO1999055090A1 (en) * 1998-04-20 1999-10-28 Koninklijke Philips Electronics N.V. Digital television system which switches channels in response to control data in a television signal
US7046910B2 (en) * 1998-11-20 2006-05-16 General Instrument Corporation Methods and apparatus for transcoding progressive I-slice refreshed MPEG data streams to enable trick play mode features on a television appliance
US6463059B1 (en) * 1998-12-04 2002-10-08 Koninklijke Philips Electronics N.V. Direct memory access execution engine with indirect addressing of circular queues in addition to direct memory addressing
US7130315B1 (en) * 1999-09-10 2006-10-31 Sony Corporation Method of and apparatus for utilizing extended AV/C command and response frames including transaction label and common result/error code
US6700933B1 (en) * 2000-02-15 2004-03-02 Microsoft Corporation System and method with advance predicted bit-plane coding for progressive fine-granularity scalable (PFGS) video coding
US6940904B2 (en) * 2001-05-29 2005-09-06 Broadcom Corporation Artifact-free displaying of MPEG-2 video in the progressive-refresh mode
US6804301B2 (en) * 2001-08-15 2004-10-12 General Instrument Corporation First pass encoding of I and P-frame complexity for compressed digital video

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5594552A (en) * 1992-10-30 1997-01-14 Sony Corporation Apparatus and method for producing downwards compatible video signals with increased vertical resolution, and apparatus for reproducing and displaying same
US5805762A (en) * 1993-01-13 1998-09-08 Hitachi America, Ltd. Video recording device compatible transmitter
US6122433A (en) * 1994-10-20 2000-09-19 Thomson Licensing S.A. HDTV trick play stream derivation for VCR
US5737479A (en) * 1994-12-21 1998-04-07 Sony Corporation Apparatus and method for inserting rating code into the digital video signal
US6965724B1 (en) * 1995-03-30 2005-11-15 Thomson Licensing S.A. Trick-play modes for pre-encoded video
US5613190A (en) * 1995-05-01 1997-03-18 Bell Atlantic Network Services, Inc. Customer premise wireless distribution of audio-video, control signals and voice
US5740307A (en) * 1995-06-07 1998-04-14 Hitachi America, Ltd. Methods for monitoring a trick play data stream to insure MPEG compliance
US6363212B1 (en) * 1995-08-02 2002-03-26 Sony Corporation Apparatus and method for encoding and decoding digital video data
US5838876A (en) * 1996-09-24 1998-11-17 Sony Corporation Frame-accurate edit and playback in digital stream recording
US6236663B1 (en) * 1997-03-27 2001-05-22 Sony Corporation Information reproduction apparatus and information reproduction method
US6334026B1 (en) * 1998-06-26 2001-12-25 Lsi Logic Corporation On-screen display format reduces memory bandwidth for time-constrained on-screen display systems

Cited By (110)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040218680A1 (en) * 1999-12-14 2004-11-04 Rodriguez Arturo A. System and method for adaptive video processing with coordinated resource allocation
US8223848B2 (en) 1999-12-14 2012-07-17 Rodriguez Arturo A System and method for adapting video decoding rate by multiple presentation of frames
US7957470B2 (en) 1999-12-14 2011-06-07 Rodriguez Arturo A System and method for adapting video decoding rate
US7869505B2 (en) 1999-12-14 2011-01-11 Rodriguez Arturo A System and method for adaptive video processing with coordinated resource allocation
US20080279284A1 (en) * 1999-12-14 2008-11-13 Rodriguez Arturo A System and Method for Adapting Video Decoding Rate By Multiple Presentation of Frames
US20080253464A1 (en) * 1999-12-14 2008-10-16 Rodriguez Arturo A System and Method for Adapting Video Decoding Rate
US20080037952A1 (en) * 2001-12-31 2008-02-14 Scientific-Atlanta, Inc. Annotations for trick modes of video streams with simultaneous processing and display
US8358916B2 (en) 2001-12-31 2013-01-22 Rodriguez Arturo A Annotations for trick modes of video streams with simultaneous processing and display
US8301016B2 (en) 2001-12-31 2012-10-30 Rodriguez Arturo A Decoding and output of frames for video trick modes
US20080037957A1 (en) * 2001-12-31 2008-02-14 Scientific-Atlanta, Inc. Decoding and output of frames for video trick modes
US9788023B2 (en) 2002-05-03 2017-10-10 Time Warner Cable Enterprises Llc Use of messages in or associated with program signal streams by set-top terminals
US9264761B2 (en) 2002-05-03 2016-02-16 Time Warner Cable Enterprises Llc Use of messages in or associated with program signal streams by set-top terminals
US9003463B2 (en) 2002-05-03 2015-04-07 Time Warner Cable Enterprises Llc Program storage, retrieval and management based on segmentation messages
US20040244058A1 (en) * 2002-05-03 2004-12-02 Carlucci John B. Programming content processing and management system and method
US7908626B2 (en) * 2002-05-03 2011-03-15 Time Warner Interactive Video Group, Inc. Network based digital information and entertainment storage and delivery system
US20030208767A1 (en) * 2002-05-03 2003-11-06 Williamson Louis D. Network based digital information and entertainment storage and delivery system
US9307285B2 (en) 2002-05-03 2016-04-05 Time Warner Cable Enterprises Llc Use of messages in or associated with program signal streams by set-top terminals
US9351027B2 (en) 2002-05-03 2016-05-24 Time Warner Cable Enterprises Llc Program storage, retrieval and management based on segmentation messages
US20050120377A1 (en) * 2002-05-03 2005-06-02 Carlucci John B. Technique for effectively providing various entertainment services through a communications network
US9538224B2 (en) 2002-05-03 2017-01-03 Time Warner Cable Enterprises Llc Program storage, retrieval and management based on segmentation messages
US8752104B2 (en) 2002-05-03 2014-06-10 Time Warner Cable Enterprises Llc Technique for effectively providing various entertainment services through a communications network
US9706238B2 (en) 2002-05-03 2017-07-11 Time Warner Cable Enterprises Llc Program storage, retrieval and management based on segmentation messages
US20100050218A1 (en) * 2002-05-03 2010-02-25 Carlucci John B Technique for effectively providing various entertainment services through a communications network
US8443383B2 (en) 2002-05-03 2013-05-14 Time Warner Cable Enterprises Llc Use of messages in program signal streams by set-top terminals
US8312504B2 (en) 2002-05-03 2012-11-13 Time Warner Cable LLC Program storage, retrieval and management based on segmentation messages
US8392952B2 (en) 2002-05-03 2013-03-05 Time Warner Cable Enterprises Llc Programming content processing and management system and method
US20040015999A1 (en) * 2002-05-03 2004-01-22 Carlucci John B. Program storage, retrieval and management based on segmentation messages
US7610606B2 (en) 2002-05-03 2009-10-27 Time Warner Cable, Inc. Technique for effectively providing various entertainment services through a communications network
US7614066B2 (en) 2002-05-03 2009-11-03 Time Warner Interactive Video Group Inc. Use of multiple embedded messages in program signal streams
US9942590B2 (en) 2002-05-03 2018-04-10 Time Warner Cable Enterprises Llc Program storage, retrieval and management based on segmentation messages
US10631026B2 (en) 2002-05-03 2020-04-21 Time Warner Cable Enterprises Llc Programming content processing and management system and method
US20040179611A1 (en) * 2003-02-05 2004-09-16 Akira Sota Image signal reproduction apparatus and image signal reproduction method
US20050022245A1 (en) * 2003-07-21 2005-01-27 Ramesh Nallur Seamless transition between video play-back modes
US20050074063A1 (en) * 2003-09-15 2005-04-07 Nair Ajith N. Resource-adaptive management of video storage
US7966642B2 (en) 2003-09-15 2011-06-21 Nair Ajith N Resource-adaptive management of video storage
US20080295621A1 (en) * 2003-10-16 2008-12-04 Sae Magnetics (H.K.) Ltd. Method and mechanism of the suspension resonance optimization for the hard disk driver
US7920623B2 (en) * 2003-11-14 2011-04-05 General Instrument Corporation Method and apparatus for simultaneous display of multiple audio/video programs transmitted over a digital link
US20070134197A1 (en) * 2004-03-11 2007-06-14 Wolfram Eichner Conjugates of hydroxyalkyl starch and a protein, prepared by reductive amination
US20050259751A1 (en) * 2004-05-21 2005-11-24 Howard Brad T System and a method for controlling audio/video presentation on a sink device
US8600217B2 (en) 2004-07-14 2013-12-03 Arturo A. Rodriguez System and method for improving quality of displayed picture during trick modes
US20060013568A1 (en) * 2004-07-14 2006-01-19 Rodriguez Arturo A System and method for playback of digital video pictures in compressed streams
US20060109861A1 (en) * 2004-11-22 2006-05-25 Sheng-Chi Tsao Apparatus with and a method for a dynamic interface protocol
US8194692B2 (en) * 2004-11-22 2012-06-05 Via Technologies, Inc. Apparatus with and a method for a dynamic interface protocol
US8234679B2 (en) 2005-04-01 2012-07-31 Time Warner Cable, Inc. Technique for selecting multiple entertainment programs to be provided over a communication network
US20060227775A1 (en) * 2005-04-12 2006-10-12 Arul Thangaraj System, method, and apparatus for embedding personal video recorder functions in transport packets
US8788822B1 (en) * 2005-06-10 2014-07-22 Blue Coat Systems, Inc. Enhanced QoS solution for thin client or remote access sessions
US20080115176A1 (en) * 2006-11-13 2008-05-15 Scientific-Atlanta, Inc. Indicating picture usefulness for playback optimization
US20080115175A1 (en) * 2006-11-13 2008-05-15 Rodriguez Arturo A System and method for signaling characteristics of pictures' interdependencies
US9521420B2 (en) 2006-11-13 2016-12-13 Tech 5 Managing splice points for non-seamless concatenated bitstreams
US8875199B2 (en) 2006-11-13 2014-10-28 Cisco Technology, Inc. Indicating picture usefulness for playback optimization
US9716883B2 (en) 2006-11-13 2017-07-25 Cisco Technology, Inc. Tracking and determining pictures in successive interdependency levels
US8416859B2 (en) 2006-11-13 2013-04-09 Cisco Technology, Inc. Signalling and extraction in compressed video of pictures belonging to interdependency tiers
US8958486B2 (en) 2007-07-31 2015-02-17 Cisco Technology, Inc. Simultaneous processing of media and redundancy streams for mitigating impairments
US20090033791A1 (en) * 2007-07-31 2009-02-05 Scientific-Atlanta, Inc. Video processing systems and methods
US8804845B2 (en) 2007-07-31 2014-08-12 Cisco Technology, Inc. Non-enhancing media redundancy coding for mitigating transmission impairments
US20090100482A1 (en) * 2007-10-16 2009-04-16 Rodriguez Arturo A Conveyance of Concatenation Properties and Picture Orderness in a Video Stream
US20090148056A1 (en) * 2007-12-11 2009-06-11 Cisco Technology, Inc. Video Processing With Tiered Interdependencies of Pictures
US8718388B2 (en) 2007-12-11 2014-05-06 Cisco Technology, Inc. Video processing with tiered interdependencies of pictures
US8873932B2 (en) 2007-12-11 2014-10-28 Cisco Technology, Inc. Inferential processing to ascertain plural levels of picture interdependencies
US20090148132A1 (en) * 2007-12-11 2009-06-11 Cisco Technology, Inc. Inferential processing to ascertain plural levels of picture interdependencies
US8804843B2 (en) 2008-01-09 2014-08-12 Cisco Technology, Inc. Processing and managing splice points for the concatenation of two video streams
US20090180546A1 (en) * 2008-01-09 2009-07-16 Rodriguez Arturo A Assistance for processing pictures in concatenated video streams
US20090180547A1 (en) * 2008-01-09 2009-07-16 Rodriguez Arturo A Processing and managing pictures at the concatenation of two video streams
US8155207B2 (en) 2008-01-09 2012-04-10 Cisco Technology, Inc. Processing and managing pictures at the concatenation of two video streams
US8265168B1 (en) * 2008-02-01 2012-09-11 Zenverge, Inc. Providing trick mode for video stream transmitted over network
US8416858B2 (en) 2008-02-29 2013-04-09 Cisco Technology, Inc. Signalling picture encoding schemes and associated picture properties
US20090220012A1 (en) * 2008-02-29 2009-09-03 Rodriguez Arturo A Signalling picture encoding schemes and associated picture properties
US20090310934A1 (en) * 2008-06-12 2009-12-17 Rodriguez Arturo A Picture interdependencies signals in context of mmco to assist stream manipulation
US9819899B2 (en) 2008-06-12 2017-11-14 Cisco Technology, Inc. Signaling tier information to assist MMCO stream manipulation
US8886022B2 (en) 2008-06-12 2014-11-11 Cisco Technology, Inc. Picture interdependencies signals in context of MMCO to assist stream manipulation
US8971402B2 (en) 2008-06-17 2015-03-03 Cisco Technology, Inc. Processing of impaired and incomplete multi-latticed video streams
US8705631B2 (en) 2008-06-17 2014-04-22 Cisco Technology, Inc. Time-shifted transport of multi-latticed video for resiliency from burst-error effects
US9723333B2 (en) 2008-06-17 2017-08-01 Cisco Technology, Inc. Output of a video signal from decoded and derived picture information
US9407935B2 (en) 2008-06-17 2016-08-02 Cisco Technology, Inc. Reconstructing a multi-latticed video signal
US8699578B2 (en) 2008-06-17 2014-04-15 Cisco Technology, Inc. Methods and systems for processing multi-latticed video streams
US9350999B2 (en) 2008-06-17 2016-05-24 Tech 5 Methods and systems for processing latticed time-skewed video streams
US20090313668A1 (en) * 2008-06-17 2009-12-17 Cisco Technology, Inc. Time-shifted transport of multi-latticed video for resiliency from burst-error effects
US20090323822A1 (en) * 2008-06-25 2009-12-31 Rodriguez Arturo A Support for blocking trick mode operations
US20100020878A1 (en) * 2008-07-25 2010-01-28 Liang Liang Transcoding for Systems Operating Under Plural Video Coding Specifications
US8300696B2 (en) 2008-07-25 2012-10-30 Cisco Technology, Inc. Transcoding for systems operating under plural video coding specifications
US20100115575A1 (en) * 2008-11-03 2010-05-06 At&T Intellectual Property I, L.P. System and method for recording and distributing media content
US20100122311A1 (en) * 2008-11-12 2010-05-13 Rodriguez Arturo A Processing latticed and non-latticed pictures of a video program
US8259814B2 (en) 2008-11-12 2012-09-04 Cisco Technology, Inc. Processing of a video program having plural processed representations of a single video signal for reconstruction and output
US8259817B2 (en) 2008-11-12 2012-09-04 Cisco Technology, Inc. Facilitating fast channel changes through promotion of pictures
US8320465B2 (en) 2008-11-12 2012-11-27 Cisco Technology, Inc. Error concealment of plural processed representations of a single video signal received in a video program
US8681876B2 (en) 2008-11-12 2014-03-25 Cisco Technology, Inc. Targeted bit appropriations based on picture importance
US8761266B2 (en) 2008-11-12 2014-06-24 Cisco Technology, Inc. Processing latticed and non-latticed pictures of a video program
US20100118979A1 (en) * 2008-11-12 2010-05-13 Rodriguez Arturo A Targeted bit appropriations based on picture importance
US20100118974A1 (en) * 2008-11-12 2010-05-13 Rodriguez Arturo A Processing of a video program having plural processed representations of a single video signal for reconstruction and output
US8326131B2 (en) 2009-02-20 2012-12-04 Cisco Technology, Inc. Signalling of decodable sub-sequences
US20100215338A1 (en) * 2009-02-20 2010-08-26 Cisco Technology, Inc. Signalling of decodable sub-sequences
US20100218232A1 (en) * 2009-02-25 2010-08-26 Cisco Technology, Inc. Signalling of auxiliary information that assists processing of video according to various formats
US8782261B1 (en) 2009-04-03 2014-07-15 Cisco Technology, Inc. System and method for authorization of segment boundary notifications
US8949883B2 (en) 2009-05-12 2015-02-03 Cisco Technology, Inc. Signalling buffer characteristics for splicing operations of video streams
US9609039B2 (en) 2009-05-12 2017-03-28 Cisco Technology, Inc. Splice signalling buffer characteristics
US20100293571A1 (en) * 2009-05-12 2010-11-18 Cisco Technology, Inc. Signalling Buffer Characteristics for Splicing Operations of Video Streams
US9467696B2 (en) 2009-06-18 2016-10-11 Tech 5 Dynamic streaming plural lattice video coding representations of video
US20100322302A1 (en) * 2009-06-18 2010-12-23 Cisco Technology, Inc. Dynamic Streaming with Latticed Representations of Video
US8279926B2 (en) 2009-06-18 2012-10-02 Cisco Technology, Inc. Dynamic streaming with latticed representations of video
KR101895443B1 (en) 2011-01-18 2018-09-06 삼성전자주식회사 Method and apparatus for transmitting/receiving content in a broadcast system
KR20180052768A (en) * 2011-01-18 2018-05-18 삼성전자주식회사 Method and apparatus for transmitting/receiving content in a broadcast system
KR101855516B1 (en) * 2011-01-18 2018-05-09 삼성전자주식회사 Method and apparatus for transmitting/receiving content in a broadcast system
US10116997B2 (en) * 2011-01-18 2018-10-30 Samsung Electronics Co., Ltd. Method and apparatus for transmitting/receiving content in a broadcast system
KR101922988B1 (en) 2011-01-18 2018-11-28 삼성전자주식회사 Method and apparatus for transmitting/receiving content in a broadcast system
US20130298177A1 (en) * 2011-01-18 2013-11-07 Samsung Electronics Co., Ltd. Method and apparatus for transmitting/receiving content in a broadcast system
CN108600753A (en) * 2011-12-29 2018-09-28 Lg 电子株式会社 Video coding and coding/decoding method and the device for using this method
US10742985B2 (en) 2011-12-29 2020-08-11 Lg Electronics Inc. Video encoding and decoding method based on entry point information in a slice header, and apparatus using same
US11240506B2 (en) 2011-12-29 2022-02-01 Lg Electronics Inc. Video encoding and decoding method based on entry point information in a slice header, and apparatus using same
US11711549B2 (en) 2011-12-29 2023-07-25 Lg Electronics Inc. Video encoding and decoding method based on entry point information in a slice header, and apparatus using same
US9998750B2 (en) 2013-03-15 2018-06-12 Cisco Technology, Inc. Systems and methods for guided conversion of video from a first to a second compression format

Also Published As

Publication number Publication date
EP1442598A1 (en) 2004-08-04
US9380337B2 (en) 2016-06-28
US20030121044A1 (en) 2003-06-26
US7342967B2 (en) 2008-03-11
US20110013887A1 (en) 2011-01-20
WO2003024113A1 (en) 2003-03-20

Similar Documents

Publication Publication Date Title
US9380337B2 (en) Command packets for personal video recorder
US8923688B2 (en) Performing personal video recording (PVR) functions on digital video streams
US7359620B2 (en) Information transmitting method, information processing method and apparatus, and information recording and reproducing method and apparatus
US7177522B2 (en) System and method for personal video recording
US5844595A (en) Decoding of digital data including program specific information
US20030133509A1 (en) Processing of packets in mpeg encoded transport streams using additional data attached to each packet
US20130272433A1 (en) Error concealment for mpeg decoding with personal video recording functionality
EP1742465A2 (en) Program specific information formation with private data elements
US20060080110A1 (en) Transport demultiplexor with bit maskable filter
US8009741B2 (en) Command packet system and method supporting improved trick mode performance in video decoding systems
US7061930B2 (en) Data selection/storage apparatus and data processing apparatus using data selection/storage apparatus
US20040076401A1 (en) Method and apparatus for storing MPEG-2 transport streams using a conventional digital video recorder
US8559797B2 (en) System and method for personal video recording
KR100405975B1 (en) Method for stream jump
US20040055012A1 (en) Content advisory rating preservation during personal video recorder trick play modes
US7920623B2 (en) Method and apparatus for simultaneous display of multiple audio/video programs transmitted over a digital link
KR101086920B1 (en) Exploitation of discontinuity indicator for trick mode operation
JP4366038B2 (en) Television broadcast processing apparatus and control method for television broadcast processing apparatus
US6654809B1 (en) Data processing device
JP2000069454A (en) Digital broadcasting receiver
US9236092B2 (en) System, method, and apparatus for embedding personal video recording functions at picture level
JP4465923B2 (en) Moving image recording / reproducing apparatus and moving image recording / reproducing method
JPH1023399A (en) Mpeg2 data regenerating device
JP2003037794A (en) Digital broadcast receiving/reproducing device
KR100226826B1 (en) Decoding apparatus of a satellite broadcasting receiver and method thereof

Legal Events

Date Code Title Description
AS Assignment

Owner name: BROADCOM CORPORATION, CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DEMAS, JASON;BHATLA, SANDEEP;KELLERMAN, MARCUS;AND OTHERS;REEL/FRAME:012518/0893;SIGNING DATES FROM 20010813 TO 20010910

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION

AS Assignment

Owner name: BANK OF AMERICA, N.A., AS COLLATERAL AGENT, NORTH CAROLINA

Free format text: PATENT SECURITY AGREEMENT;ASSIGNOR:BROADCOM CORPORATION;REEL/FRAME:037806/0001

Effective date: 20160201

Owner name: BANK OF AMERICA, N.A., AS COLLATERAL AGENT, NORTH

Free format text: PATENT SECURITY AGREEMENT;ASSIGNOR:BROADCOM CORPORATION;REEL/FRAME:037806/0001

Effective date: 20160201

AS Assignment

Owner name: AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD., SINGAPORE

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:BROADCOM CORPORATION;REEL/FRAME:041706/0001

Effective date: 20170120

Owner name: AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:BROADCOM CORPORATION;REEL/FRAME:041706/0001

Effective date: 20170120

AS Assignment

Owner name: BROADCOM CORPORATION, CALIFORNIA

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:BANK OF AMERICA, N.A., AS COLLATERAL AGENT;REEL/FRAME:041712/0001

Effective date: 20170119