System and method for authorization of segment boundary notifications

Information

  • Patent Grant
  • 8782261
  • Patent Number
    8,782,261
  • Date Filed
    Friday, April 3, 2009
    15 years ago
  • Date Issued
    Tuesday, July 15, 2014
    10 years ago
Abstract
Systems and methods for processing segment boundary notifications in a digital media receiver are disclosed. One such method includes the step of registering for notification of segment boundary events associated with a first service provided to the digital media receiver. The method further includes receiving a notification of one of the segment boundary events, while tuned to a second service different than the first service; and tuning to the first service responsive to the received notification.
Description
CROSS REFERENCE TO RELATED APPLICATIONS

Not applicable.


FIELD OF THE DISCLOSURE

The present disclosure relates to digital media delivery, and more specifically, to systems and methods of notifying digital media receivers about segment boundaries in media streams.


BACKGROUND

A growing number of consumers now have high-speed, or broadband, connections to the Internet in their homes. The increased bandwidth provided by these broadband connections allows the delivery of digital television, video, and multimedia services to customer premises (e.g., home consumers). With so many services to choose from, a typical viewing pattern involves a lot of switching from one service to another, a behavior commonly known as “channel surfing”. For example, while watching a one-hour broadcast program, a viewer might periodically switch to a sporting event to check for the current score, then switch back to resume viewing of the previous program.





BRIEF DESCRIPTION OF THE DRAWINGS

Many aspects of the disclosure can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure.



FIG. 1 is a block diagram of one embodiment of a system and method for providing and processing segment boundary notifications.



FIG. 2 is a diagram illustrating some aspects of communication between the video switch and the digital media receiver from FIG. 1, during the segment boundary notification process.



FIG. 3 is a block diagram of selected components of the segment boundary notification server module, according to one embodiment of the system from FIG. 1.



FIG. 4 is a block diagram of a segment boundary notification client module and various other components in one embodiment of the digital media receiver from FIG. 1.



FIG. 5 illustrates how a SegmentBoundaryNotify message is conveyed in an MPEG-2 transport stream by some embodiments of the system from FIG. 1.



FIG. 6 is another block diagram of selected components of the video switch from FIG. 1, in an embodiment which generates an MPEG-2 transport stream.



FIG. 7 is a block diagram of another embodiment of the digital media receiver from FIG. 1, in which detection of program segment boundaries is performed by a dual-tuner receiver.



FIG. 8 is a block diagram of a general purpose computer implementing some embodiments of the server boundary notification server from FIG. 1.



FIG. 9 is another block diagram of a general purpose computer implementing some embodiments of the server boundary notification server from FIG. 1.





DETAILED DESCRIPTION

Overview


Embodiments are disclosed herein that provide systems, devices, and methods of authorizing segment boundary notifications. One such method is performed in a digital media receiver and includes registering for notification of segment boundary events associated with a first service provided to the digital media receiver. The method also includes receiving a notification of one of the segment boundary events while tuned to a second service different than the first service. The method also includes determining whether the notification is authorized, processing the notification responsive to the determination that the authorization is authorized.


One such device is a digital media receiver including logic configured to register for notification of segment boundary events associated with a first service provided to the digital media receiver. The digital media receiver also includes logic configured to receive a notification of one of the segment boundary events while tuned to a second service different than the first service. The digital media receiver also includes logic configured to determine whether the notification is authorized. The digital media receiver also includes logic configured to process the notification, responsive to the determination that the authorization is authorized.


One such device is a digital media receiver including memory and a processor. The processor is configured by instructions retrieved from the memory to receive, during an authorization process, a key associated with segment boundary event notification. The processor is also configured to register for notification of segment boundary events associated with a first one of the subset of services. The processor is also configured to receive an encrypted notification of one of the segment boundary events while the digital media receiver is tuned to a second one of the subset of services, the second one being different than the first one. The processor is also configured to decrypt the encrypted notification using the received key, and to process the decrypted notification.


Example Embodiments


FIG. 1 is a block diagram of an environment in which one embodiment of a system and method for segment boundary notification is located. System 100 delivers various digital television services to subscribers, which may include television programming, video-on-demand, pay-per-view, music, Internet access, shopping, and telephone. These television services are delivered in a transport stream containing one or more multiplexed video programs, the emissions respectively corresponding to the television services), where each video program contains one or more multiplexed media streams in the transport stream. These television services may be provided from various sources. One such source is a media source 110, which provides or transmits encoded media content in, for instance, a cable television network, a television services network, or originally from a broadcast television station. Other sources of media content or television services should be familiar to a person of ordinary skill in the art, and are intended to be within the scope of this disclosure. Throughout this specification, media content should be understood to be a video program or any other form of media that includes one or more media streams, such as audio, video, or graphics streams. Likewise, it should be understood that a video program is associated with and comprises a set of one or more media streams that may or may not have a video stream.


Various media content sources may be located at a facility known as a “head end” which is operated by a television services provider (e.g., a network operator) that also operates television network 120. Media source 110 and video switch 170 may be part of the television network 120. However, these components are not limited to residing at that location.


Common encoding formats for the video stream of a video program or media content may include MPEG-2 video, MPEG-4 AVC, -or SMPTE VC-1, but others are contemplated to be within the scope of this disclosure. In some environments, a transport stream may include one or more multiplexed video programs, with each video program containing one or more corresponding encoded media streams that are multiplexed in the transport stream. A video program, such as one provided by a television service, contains a video elementary stream and an audio elementary stream multiplexed together into the transport stream. In some embodiments, the transport stream, such as the MPEG-2 Transport Stream, may comprise of a single video program in the transport stream, which herein we refer to as a single program transport stream (SPTS).


MPEG-2 Transport Stream in specified by ISO 13818-1 MPEG-2 Systems, and is also known as ITU-T H222.0 (05/2006). The packetized elementary stream (PES) that corresponds to the video stream of a video program is carried in transport packets identifiable by a packet identifier (PID).


The concepts described herein apply to various types of elementary stream encapsulations, including (but not limited to): PES in MPEG-2 Transport Stream (TS); MPEG-2 Elementary Stream (ES) over UDP/IP, RTP/UDP/IP or RTP/TCP/IP; MPEG-2 PES over UDP/IP, RTP/UDP/IP or RTP/TCP/IP; PES in MPEG-2 TS over UDP/IP, RTP/UDP/IP and RTP/TCP/IP. Thus, all references herein to MPEG-2 as a transport apply equally to an alternate transport mechanism or layer such as IP or RTP.


Media content or video programs of television services, from various sources, are provided over network 120 to digital media receivers, which are also referred to herein as digital media receivers. In one embodiment, the media content or video programs of television services are provided via a video switch 130. In some embodiments, video switch 130 is connected to the input of other network processing devices (e.g., a multiplexer, a QAM channel modulator, etc.). In some embodiment, a subset of the television services are provided for a particular group of subscribers, and the corresponding subset of video programs, each having one or more multiplexed media streams, is delivered to those subscribers connected to video switch 130, via subscriber connections 140. Each of these video programs can be viewed as providing a particular television service to a subscriber. Other embodiments do not use video switch 130. In these embodiments, instead of multiple video programs provided by video switch 130, only a single video program is provided at a time, corresponding to a particular television service.


A digital media receiver 150 receives, via subscriber connection 140, the subset of video programs that correspond to the television services selected by video switch 130. Digital media receiver 150 then selects one or more of the delivered television services for presentation to a user. (This selection is sometimes referred to as “tuning”.) In some embodiments, digital media receiver 150 processes the one or more multiplexed media streams corresponding to the video program of the selected television service and converts them into a presentable or output form, such as a video signal, either in analog form or digital form. Processing may comprise of decompression and reconstruction of the pictures in a received video stream. This video signal is supplied to a display (e.g., a television or computer monitor) for viewing by a subscriber. In some embodiments digital media receiver 150 stores the video program of the selected television service for later presentation (e.g., digital video recorder or DVR).


A particular television service provides different video programs at different times. These video programs can include conventional “television programs”, movies, sporting events, etc. The media content carried in a particular television service can also be viewed as containing sequential segments which are non-overlapping. Two consecutive segments are divided by a boundary that includes the end of the first of the two consecutive segments followed by the beginning of the second segment. Several examples of boundaries and segments will now be discussed.


One example is a boundary between two scheduled video programs: a video program (e.g., “Friends”) from 8 PM to 9 PM and another video program (“Monday Night Football”) from 9 PM to 11 PM, with a program boundary between the two. Another example is a scheduled boundary within a video program (e.g., between the end of a portion of a program and the start of an advertisement). As yet another example, the transmission of a television service can be divided into multiple segments, with unscheduled boundaries in between, determined in real-time (e.g., rounds of a boxing match, quarters of a basketball game, etc.). An unscheduled boundary corresponds to a segment boundary that is determined as a video program progresses through time. Alternatively or additionally, an unscheduled boundary corresponds to a segment boundary that is determined as events in a video program are reached through time, such as a “time-out” or half time in a live basketball game.


Segment boundaries can be context-specific: e.g., for a conventional video program (also referred to herein as a television program), segments may be scenes or chapters and; for a sporting event, segments may correspond to quarters/halves, score highlights, half-time presentations, etc. Yet another example is a boundary between a video program (or a program chapter) and an advertisement.


Using techniques disclosed herein, a subscriber requests to be notified of the occurrence of a segment boundary for a particular service (i.e., a segment boundary event). Using the examples mentioned earlier, a subscriber might request notification at the start of the next program that is carried on one service/channel, or at the start of the fourth quarter of a sporting event that is carried on another service/channel.


Segment boundaries are not based on time or a clock, but rather on a signal or message in the transport layer corresponding to the first service (or of the current video program of the first service) that identifies the segment boundary. For example, a message is included in the transport layer, such as in the Adaptation Field of an MPEG-2 Transport packet.


Furthermore, a segment boundary notification is not a notification for an event that is based on any of the following or any combination of the following: program guide data, any information obtained from a program guide's database; a program's title, start time or end time; information pertaining to a program that is provided separate from the one or more multiplexed media streams of the video program; information provided at a different time when providing the video program (the one or more multiplexed media streams thereof) since a signal or message that identifies the segment boundary of the video program is provided with the video program. As described previously, a segment boundary notification corresponds to a boundary that includes the end of the first of two consecutive segments followed by the beginning of the second segment (rather than just the beginning of the second segment).


In one embodiment, a segment boundary notification corresponds to a notification of a transition from one type of information provided by a particular television service to another type of information provided by the particular television service. As a non-limiting example, a first type of information may be a non-live sports program, such as a sports documentary, and a second type of information may be a live sports program or event, such as a basketball game. A first television service may be a broadcast television channel that carries scheduled video programs, such as NBC. A second television service may be a video on demand service. A third television service may correspond to a pay per view service.


In one embodiment, a segment boundary notification corresponds only to signaling a specific type of transition: e.g., a transition from a first type of information provided by the particular television service to a second type of information provided by the particular television service.


In an alternate embodiment, a segment boundary notification corresponds only to signaling a transition from a first type of information to a second type of information provided by the particular television service, or to a transition from the second type of information to the first type of information in the television service.


In yet another embodiment, a segment boundary notification corresponds to signaling any transition from one type of information to another and different type of information provided by the particular television service, regardless of the types of information involving the transition.


In an alternate embodiment, a segment boundary notification corresponds to a particular type of transition from plural types of transitions. In such a case, a boundary event notification includes information corresponding to a transition type, such as but not limited to a transition type data field. Predetermined or designated values carried in the transition type data corresponds to the type of transition being notified by the segment boundary notification.


In one embodiment, digital media receiver 150 is configured to examine auxiliary information provided with a received video program. This auxiliary information herein is called segment boundary information (SBI) or equivalently a segment boundary notify message (SBNM). The SBI includes a “segment boundary” data field (SBDF) having a value. A first value of the SBDF corresponds to a segment boundary notification. A second value different than the first SBDF value does not notify or identify a segment boundary. Alternatively, a second value different than the first SBDF value notifies or identifies the absence of a segment boundary notification. Digital media receiver 150 determines the presence of a segment boundary notification when the value of the SBDF equals the first value.


The SBI is provided or received unscrambled, even if the corresponding video program is provided or received scrambled. In one embodiment, the SBI is provided as private data in the adaptation field of an MPEG-2 transport packet. The header and adaptation field of MPEG-2 transport packets are always unscrambled.


The SBI is associated with a segment boundary by the relative location of the SBI in the transport stream to the segment boundary or portions thereof. In one embodiment, the SBI is provided in the transport packet containing in its payload the segment boundary. That is, the transport packet's payload contains both: (1) the end of a first segment, and (2) the start of a second segment that immediately follows the first segment.


In another embodiment, the SBI is provided in the transport packet containing in its payload only a portion of the boundary: the start of the second segment that immediately follows the first segment, but not the end of the first segment.


In yet another embodiment, the SBI is provided in the transport packet containing in its payload the end of the first segment but not the start of the second segment that immediately follows the first segment.


In one embodiment, the SBI also includes a “location” data field (LDF) that identifies the location of the segment boundary or portions thereof. The value of the LDF, N, represents the number of pictures, frames or fields in the video stream away from the current location of the SBI, where the segment boundary (or portion thereof depending on the embodiment) is located. Digital media receiver 150 finds segment boundary (or portion thereof) by counting the number of start codes in the corresponding video stream that are encountered after the SBI. In other words, digital media receiver 150 detects the succeeding start codes in the PES containing the corresponding video stream to find the segment boundary.


Alternatively, digital media receiver 150 finds the segment boundary (or portion thereof) by counting the number of instances that the payload_unit_start_indicator (PUSI) in the MPEG-2 transport packet's header equals one. In accordance with MPEG-2 Transport, the transport packet containing the first byte of a PES packet in its payload must have PUSI flag set equal to one. In this embodiment, each PES packet of the video stream contains only one picture, frame, or field.


According to the value of N, the segment boundary may or may not be included in the payload of the transport packet containing the SBI. For instance, when N equals zero, the transport packet includes in its payload the notified segment boundary (or portion thereof).


In one embodiment, a segment boundary notification is provided unencrypted in the transport stream carrying the video program of the particular television service. In an alternate embodiment, the segment boundary notification is provided encrypted. For the latter case, a first digital media receiver in a television services network may be authorized to process a segment boundary notification, whereas a second digital media receiver in the same network may receive the same one or more segment boundary notifications received by the first digital media receiver, but not be authorized to process them. Hence, the first digital media receiver is provisioned a priori with one or more keys necessary to decrypt encrypted segment boundary notifications, while the second digital media receiver is not provisioned with such keys. The necessary keys may be transmitted to the first set top box during an authorization (or provisioning) phase. The first digital media receiver may process one or more segment boundary notifications after being authorized or provisioned with the keys.


In one embodiment, a digital media receiver may be authorized to process segment boundary notifications corresponding respectively to a first subset of the plural transition types (i.e., types of transitions). The first subset of plural transition types authorized for a set-top may be configured during the authorization phase. In another embodiment, a digital media receiver may be authorized to process received segment boundary notifications corresponding to transitions provided in a first set of respective television services and not for the received segment boundary notifications corresponding to transitions in a second set of respective television services. The first and second sets of television services may or may not comprise the complete set of television services offered to a viewer or subscriber via the digital media receiver. A complete set of television services may be the entire line-up of television channels offered to a subscriber via the digital media receiver.


In one embodiment, the first set of respective television services for which a digital media receiver may be authorized to process event boundary notifications may correspond to television services for which a subscriber pays an extra fee to be authorized to view (i.e., receive and decrypt the respective television services in the first set). The extra fee is typically paid by the subscriber to the television services provider that operates the television network. As a non-limiting example, the first set of respective television services may include premium television channels or services, such as HBO and Cinemax. The second set of respective television services for which a digital media receiver may not be authorized to process event boundary notifications may include television channels or services (e.g., ABC, NBC, CBS and FOX) that the subscriber is authorized to view without paying the extra fee. The extra fee means a monetary amount beyond the monetary amount, if any, that the subscriber would be required to pay to be authorized to view the second set of respective television services.


In another embodiment, the first set of respective television services for which a digital media receiver may be authorized to process event boundary notifications may correspond to television services for which a subscriber does not pay an extra fee to be authorized to view (i.e., receive and decrypt the respective television services in the first set). An extra fee is typically paid by the subscriber to the television services provider that operates the television network to be authorized to view a second set of television services, such as HBO and Cinemax. As a non-limiting example, the first set of respective television services may include premium television channels or services, such as HBO and Cinemax. The second set of respective television services for which a digital media receiver may be authorized to process event boundary notifications may include television channels (e.g., ABC, NBC, CBS and FOX) that the subscriber is authorized to view without paying the extra fee.


In one embodiment, a subscriber is allowed to process event boundary notifications only for an additional fee to the television services provider that operates the television network.


A segment boundary notification may signal a first type of transition corresponding to a transition from a first type of visual information (i.e., first type of information) to a second type of visual information (i.e., a second type of information). For instance, a first type of transition may correspond to a transition from a commercial or advertisement to the video program being currently broadcast on a particular television channel. A segment boundary notification may also correspond to a transition from the video program to the commercial in the particular television channel.


A segment boundary notification may signal a transition from a first song to a second song in a music television channel. Hence, a segment boundary notification may correspond to a transition from a first audio content to a second audio content. Furthermore, information about the titles or when the scheduled transition occurs is not included in program guide information provided to the digital media receiver 150.


In one embodiment, digital media receiver 150 is configured for boundary segment notifications and not configured to receive and provide program guide data.


Referring back to FIG. 1, requests for segment boundary notifications are generated by segment boundary notification client module 160 in digital media receiver 150 and sent to a segment boundary notification server module 170 that is associated with video switch 130. The high-level interaction between these two modules will be discussed in connection with FIG. 2, then more details will be discussed in connection with FIGS. 3-6. In the embodiment shown in FIG. 1, server module 170 is integrated into video switch 130. In other embodiments, server module 170 is a separate component. In still other embodiments, server module 170 is integrated into a different head-end component. Persons of ordinary skill in the art should appreciate that the functionality of server module 170 distributed in other ways and among other components as well.



FIG. 2 is a diagram illustrating some aspects of communication between video switch 130 and digital media receiver 150 during the segment boundary notification process. Video switch 130 appears on the left side of the diagram while digital media receiver 150 appears on the right, with time increasing from top to bottom. Delivery of services is represented with wide arrows and control messages are represented with thin arrows. A control message that is sent while a service is being delivered is shown as a thin arrow superimposed on a wide arrow.


In the example of FIG. 2, digital media receiver 150 is initially receiving a service (SvcOfInterest 210). While receiving SvcOfInterest 210, digital media receiver 150 sends a request (220) to register for segment boundary notifications for SvcOfInterest 210. In some embodiments, this request is initiated by a user action (e.g., a menu selection, a key, sequence of keys, button, or sequence of buttons on a remote control, etc.). In other embodiments, rather than selecting the function from a displayed menu or screen, the user enters information with the input device, where the entered information corresponds to the function (to return to the first service at a segment boundary), and/or to a specific type of segment boundary.


Video switch 130 receives the registration request 220 and processes it (not shown). While still receiving SvcOfInterest 210, digital media receiver 150 sends a request (230) to switch to a different service (e.g., a channel change request). In response to the switch service request 230, video switch 130 delivers the newly requested service (SvcNew 240). In summary, the actions described so far correspond to the following example scenario: user is watching a program on FOX; user requests notification when the program on FOX resumes after an advertisement; user switches to another service, such as an electronic program guide (EPG) service, instead of FOX.


While receiving SvcNew 240, video switch 130 sends a SegmentBoundaryNotify message (250), or SBNM, which includes information about the segment boundary and about the associated service/program. The SBNM includes the location of the boundary in the media stream (e.g, in the video stream of the video program). (Details of the segment boundary information will be discussed later in connection with FIGS. 4 and 5.) Digital media receiver 150 processes the SegmentBoundaryNotify message 250—which may include notifying the user—and in response sends a request (260) to switch back to the initial service 210 (the one associated with the notification and thus with the segment boundary). In summary, this next set of actions corresponds to the following example scenario: while the user is viewing the EPG service, video switch 130 detects an imminent return from advertisement on FOX and notifies digital media receiver 150 about this segment boundary; digital media receiver 150 notifies the user that the program on FOX is about to resume; user switches back to FOX.


Importantly, video switch 130 sends the segment boundary notification, via the segment notification control message (SBNM) 250, before the segment boundary occurs in the program stream. The lead time, which is determined a priori, is sufficient to allow the digital media receiver 150 enough time to process the notification 250 and to change the channel/service (message 260) back to the original program 210. The lead time between segment boundary notification and the actual segment boundary in the program stream depends on a number of factors including but not limited to the bit-rate of the video program, number of programs delivered simultaneously, the processing capabilities of digital media receiver 150, the estimated channel acquisition time of digital media receiver 150.



FIG. 3 is a block diagram of selected components of segment boundary notification server module 170 in one embodiment. A subscription handler 310 receives subscription requests 220 (for segment boundary notification) over an upstream control channel, and stores an identifier of the requesting digital media receiver 150 into registration database 320, along with the service/channel for which notifications are requested. (Although the term “database” is used here, a true database is not required—any mechanism for storing and retrieving records will do.) Multiple video programs 330, each comprising of one or more media streams, also known as “video feeds” and each corresponding to a television service, are received and processed by a segment boundary monitor 340. Segment boundary monitor 340 uses registration database 320 to determine which video programs are of interest to subscribers, and then for those video programs, examines their corresponding one or more media streams 330 to find segment boundaries. In some embodiments, the segment boundaries in incoming streams 330 that correspond to one or more type of transitions may be determined from digital program insertion (DPI) events. Upon the determining or detection of a segment boundary 350 in a stream-of-interest, segment boundary descriptor (SBD) generator 360 obtains the identifier of the registered digital media receiver 150 from registration database 320, and generates a SegmentBoundaryNotify message 250. This message 250 is then sent to the digital media receiver 150 via a downstream control channel.



FIG. 4 is a block diagram of segment boundary notification client module 160 and various other components in one embodiment of digital media receiver 150. Digital media receiver 150 receives one or more video programs (410) or television services concurrently, and selector 420 chooses one of the video programs for decoding and/or storage (block 430). In the example of FIG. 4, two video programs are received (410A and 410B), and program 410A is selected by selector 420. This selection process may sometimes be referred to as “tuning”, so that the selected service corresponds to the “currently tuned” service. In some cases, the user may choose the currently tuned service (e.g., by switching channels), but in other cases, the digital media receiver 150 itself chooses the currently tuned service (e.g., a scheduled recording).


Video programs are depicted here as separate logical entities. In some embodiments, the video programs are all carried in a SPTS. The MPEG-2 transport packets carrying the one or multiplexed media streams corresponding to a selected video program are identifiable by their corresponding PIDS. (See FIG. 5.) In such embodiments, selector 420 filters by PID, such that PIDs corresponding to the one or more media streams (e.g., video, audio, and/or data) of the currently tuned video program are received, processed (e.g., decoded) for viewing and/or stored for later viewing. In other embodiments, each video program 410 is carried in a separate RTP/RTCP stream, and selector 420 selects by RTP stream identifier.


In one embodiment, digital media receiver 150 may receive information on a control channel (440). In some embodiments, control channel 440 carries information such as a program information table (PAT), a program map table (PMT), a conditional access table (CAT), a network information table (NIT), a service description table (DST) and a time and date table (TDT). In an alternate embodiment, in accordance with MPEG-2 Systems, these tables are provided within the MPEG-2 Transport stream (or layer) containing the one or more multiplexed media streams of the video program. As shown in FIG. 4, SegmentBoundaryNotify message 250 (also shown in FIG. 2) is received on control channel 440, and provided to segment boundary notification client module 160 (see FIG. 1). After identifying the service to which the boundary notification applies, and the location of the segment boundary within that service, client module 160 notifies the viewer of the upcoming segment boundary (event 450) and/or instructs (event 460) selector 420 to switch over to that television service. This viewer notification may use audio, video, or combinations thereof. In other embodiments, no user notification is performed, and digital media receiver 150 automatically tunes to, and switches the output signal to, the video program provided by the original service.


As mentioned earlier in connection with FIG. 2, in one embodiment, SegmentBoundaryNotify message 250 identifies the video program to which the boundary notification applies, and also includes the location of the segment boundary in that video program. This is illustrated in FIG. 4 as follows. Each video program 410 is composed of segments 470, divided by boundaries 480. Pointer 490 (within message 250) points to, or refers to, a particular location in video program 410B. As mentioned earlier, this segment boundary location in message 250 is received by digital media receiver 150 before the segment boundary occurs in the video program or in a corresponding media stream of the video program. Also, stream 410A is the currently tuned video program (as output by selector 420), not stream 410B, so that SegmentBoundaryNotify message 250 refers to a video program or television service other than the currently tuned channel or service (and thus, not the current video program).


In some embodiments, control channel 440 is bidirectional, though only downstream communication is shown in FIG. 4. Control channel 440 is depicted here as a logical entity, though a particular embodiment may not use a separate control channel but may instead multiplex control packets into the MPEG-2 transport stream. Control channel 440 may be broadly understood as encompassing many different mechanisms for conveying control information, even at different layers (e.g., including control data carried in MPEG-2 transport packets, carried in IPMG packets and carried in RTCP packets).


In an alternate embodiment, SegmentBoundaryNotify message 250 is provided with the video program as described above, such as in the SBI provided in the adaptation field of the MPEG-2 transport packet.



FIG. 5 illustrates how SegmentBoundaryNotify message 250 is conveyed in an MPEG-2 transport stream by some embodiments of system 100. Transport stream 510 carries (concurrently) two different services. Service #1 corresponds to transport stream packets having PIDs 1 and 2 (video and audio, respectively). Service #2 corresponds to transport stream packets having PIDs 3, 4, and 5 (video, audio, and data, respectively). Transport stream 510 also carries SegmentBoundaryDescriptor (SBD) 520, corresponding to generic SegmentBoundaryNotify message 250 of FIGS. 2-4. In some embodiments, SBD 520 is conveyed in the MPEG-2 transport stream packet's Adaptation Field, but other mechanisms for conveyance by the MPEG-2 transport stream are also contemplated.


In the example embodiment of FIG. 5, SBD 520 includes the following fields: the service to which the boundary notification applies (field 530); the location of the segment boundary in that service (data field 540), such as the value of a presentation time stamp (PTS); the type of transition of the segment boundary (field 550); and an enablement flag (field 560). One embodiment does not include the type of segment boundary and the enablement flag. As described above, Segment boundary types 550 may include different types of transitions. For instance, they may include: a transition from a first video program to a second video program in the a particular television service; a transition from a portion of a video program to an advertisement (or vice versa); the start of a certain chapter of a video program; the score highlights segment of sports service; an unscheduled boundary such as an update of the scores or highlights of other games during a football game or the start of the second half of a game; a splicing or concatenation event in a video program, video stream, audio stream, or any combination thereof; a type of splicing cue included in the video program's transport layer; a property in the video stream such as a random access point; or in an MPEG-4 AVC encoded video stream, an end of stream NAL unit, or an IDR picture.


Digital media receiver 150 may not process a segment boundary notification, depending on enablement flag 560. Thus, a digital media receiver 150 may request notification when a program resumes from an advertisement, but network operators can disable this functionality by providing a corresponding value for the enablement flag 560. The flag can be a global on/off, or specific to a boundary type (e.g., flag 560 is a bit mask). In yet another embodiment, returning to the first service upon termination of an advertisement is allowed only when the advertisements are presented in a second service that are transmitted concurrently with the advertisements in the first service.


In an alternate embodiment, as described above, segment boundary notifications are encrypted and may be decrypted and processed only by an authorized digital media receiver 150.



FIG. 6 is another block diagram of selected components of video switch 130 in an embodiment which generates an MPEG-2 transport stream. As described earlier in connection with FIG. 3, video programs of one or more multiplexed media programs, shown as media streams 330, are received from various media sources and processed by segment boundary monitor 340. If segment boundary monitor 340 detects a segment boundary 350 in a stream-of-interest (i.e., a video program of interest), SBD generator 360 produces an SBD 520 (see FIG. 5), which is provided to MPEG-2 encapsulator/multiplexer 610. Encapsulator/multiplexer 610 wraps SBD 520 in one or more MPEG-2 transport stream (TS) packets, then multiplexes those private data packets or “control channel” packets in with MPEG-TS packets which encapsulate streams 330, along with timing information (e.g., program clock reference and system clock reference). The result is transport stream 510 (described earlier in connection with FIG. 5, which is conveyed over network 120 to digital media receiver 150 (see FIG. 1).


In an alternate embodiment, the SBD generator 360 produces an SBD 520 that is included in the SBNM provided in the adaptation field of an MPEG-2 transport packet that carries the video stream of the corresponding video program, as described above. Location data field (LDF) 540 provides a value N as described previously. In an alternate embodiment, LDF corresponds to the presentation time stamp (PTS) of the picture, frame or field coincident with the start of the second segment that immediately follows the end of the first segment in a boundary. The PTS of a picture is found in the header of the PES packet containing the start of the picture, frame, or field.



FIG. 7 is a block diagram of another embodiment of digital media receiver 150, in which detection of program segment boundaries is performed by a dual-tuner digital media receiver 150 rather than at video switch 130. Segment boundary request logic 710 receives a request (720) to register for segment boundary notifications for a particular television service, and stores the service identifier in a registration database 730. This service identifier is also provided (740) to a selector 750. Multiple video programs with one or more multiplexed media streams received at digital media receiver 150 are provided to selector 750, which selects for its single output (760) the particular service-of-interest, and provides the video stream of the video program corresponding to this service to segment boundary monitor 770. Segment boundary monitor 770 examines the video stream for segment boundary notifications to identify segment boundaries. When a segment boundary is detected or identified, the segment boundary information (e.g., including the segment boundary descriptor 780) is provided by monitor 770 to request logic 710. Logic 710 notifies the viewer and/or instructs a second selector 790 to switch to the service-of-interest. In this dual-tuner embodiment, digital media receiver 150 may use the first tuner to receive and process segment boundary notifications in the background, while the second tuner is used to view or “surf” other channels or TV services.


In one embodiment, service boundary notifications are provided by segment boundary notification server 170 without requests from a digital media receiver 150. Digital media receivers 150 are authorized to receive and process service boundary notifications as described previously, e.g., by encrypting the SBNMs or by other means.



FIG. 8 is a block diagram of one embodiment of a general purpose computer 800 that can be used to implement segment boundary notification server module 170. Computer 800 contains a number of components that are well known in the computer arts, including a processor 810, memory 820, and a network interface 830. Some embodiments also include a storage device 840 (e.g., non-volatile memory or a disk drive). These components are coupled via a bus 850. Omitted from FIG. 8 are a number of conventional components that are unnecessary to explain the operation of computer 800.



FIG. 9 is a block diagram of one embodiment of digital media receiver 150. Digital media receiver 150 contains a number of components that are well known in the computer arts, including a processor 910, memory 920, a network interface 930, a peripheral input output (I/O) interface 940, a decoder 950, and an output subsystem 960. Some embodiments also include a storage device 970 (e.g., non-volatile memory or a disk drive). These components are coupled via a bus 990. Omitted from FIG. 9 are a number of conventional components that are unnecessary to explain the operation of digital media receiver 150.


Peripheral I/O interface 940 provides input and output signals, for example, user inputs from a remote control or front panel buttons or a keyboard, and outputs such as LEDs or LCD on the front panel. Network interface 930 receives video programs. Decoder 950 converts an incoming video program into decoded video pictures. In some embodiments, decoder 950 also handles conversion of audio data carried within, or along with, the video program stream, into a stream of decoded audio frames. Output subsystem 960 converts the decoded video pictures into a video signal for display by a computer monitor or a television and converts the decoded audio frames into an audio signal for play over speakers.


As described above, digital media receiver 150 receives video programs via network interface 930. In some embodiments, this is a local area network (LAN) interface or a wide area network (WAN) interface such as the Internet. In other embodiments, network interface 930 interfaces to a radio frequency (RF) network, and in such embodiments digital media receiver 150 may include a tuner/demodulator (not shown) which processes digital video programs received over the RF network.


As shown in FIGS. 8 and 9, segment boundary notification client 160 and/or segment boundary notification server module 170 may be implemented in hardware logic, or may reside in memory as instructions executable by a processor. Hardware implementations include, but are not limited to, a programmable logic device (PLD), a programmable gate array (PGA), a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a system on chip (SoC), and a system in package (SiP). Furthermore, client 160 and/or server 170 may be implemented as a combination of hardware logic and processor-executable instructions (software).


Client 160 and/or server 170 can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device. Such instruction execution systems include any computer-based system, processor-containing system, or other system that can fetch and execute the instructions from the instruction execution system. In the context of this disclosure, a “computer-readable medium” can be any means that can contain, store, communicate, propagate, or transport the program for use by, or in connection with, the instruction execution system. The computer readable medium can be, for example but not limited to, a system or that is based on electronic, magnetic, optical, electromagnetic, infrared, or semiconductor technology.


Specific examples of a computer-readable medium using electronic technology would include (but are not limited to) the following: random access memory (RAM); read-only memory (ROM); and erasable programmable read-only memory (EPROM or Flash memory). A specific example using magnetic technology includes (but is not limited to) a portable computer diskette. Specific examples using optical technology include (but are not limited to) compact disk (CD) and digital video disk (DVD).


Any software components illustrated herein are abstractions chosen to illustrate how functionality is partitioned among components in some embodiments of segment boundary notification client 160 and/or server 170 disclosed herein. Other divisions of functionality are also possible, and these other possibilities are intended to be within the scope of this disclosure. Furthermore, to the extent that software components are described in terms of specific data structures (e.g., arrays, lists, flags, pointers, collections, etc.), other data structures providing similar functionality can be used instead.


Any software components included herein are described in terms of code and data, rather than with reference to a particular hardware device executing that code. Furthermore, to the extent that system and methods are described in object-oriented terms, there is no requirement that the systems and methods be implemented in an object-oriented language. Rather, the systems and methods can be implemented in any programming language, and executed on any hardware platform.


Any software components referred to herein include executable code that is packaged, for example, as a standalone executable file, a library, a shared library, a loadable module, a driver, or an assembly, as well as interpreted code that is packaged, for example, as a class. In general, the components used by the systems and methods of reducing media stream delay are described herein in terms of code and data, rather than with reference to a particular hardware device executing that code. Furthermore, the systems and methods can be implemented in any programming language, and executed on any hardware platform.


The flow charts, messaging diagrams, state diagrams, and/or data flow diagrams herein provide examples of the operation of systems and methods of segment boundary notification. Alternatively, these diagrams may be viewed as depicting actions of an example of methods implemented by segment boundary notification client 160 and/or server 170. Blocks in these diagrams represent procedures, functions, modules, or portions of code which include one or more executable instructions for implementing logical functions or steps in the process. Alternate implementations are also included within the scope of the disclosure. In these alternate implementations, functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved.


The foregoing description has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise forms disclosed. Obvious modifications or variations are possible in light of the above teachings. The implementations discussed, however, were chosen and described to illustrate the principles of the disclosure and its practical application to thereby enable one of ordinary skill in the art to utilize the disclosure in various implementations and with various modifications as are suited to the particular use contemplated. All such modifications and variation are within the scope of the disclosure as determined by the appended claims when interpreted in accordance with the breadth to which they are fairly and legally entitled.

Claims
  • 1. A method performed in a digital media receiver, the method comprising: registering for notification of segment boundary events associated with a first service provided to the digital media receiver;while tuned to a second service different than the first service, receiving a first notification of a first segment boundary event, wherein the first segment boundary is conveyed in a message in a transport layer corresponding to the first service and wherein the first segment boundary includes information corresponding to a first transition type from plural types of transitions, wherein the first transition type is contained in a transition type data field, wherein the first transition type corresponds to the type of transition being notified by the first segment boundary notification; anddetermining whether the first notification is authorized;responsive to the determination that the first notification is authorized, processing the first notification; andreceiving a second notification of a second segment boundary event, wherein the second segment boundary is conveyed in a message in the transport layer corresponding to the first service and wherein the second segment boundary includes information corresponding to a second transition type from plural types of transitions, wherein the second transition type is contained in a transition type data field, wherein the second transition type corresponds to a type of transition different that the type of transition notified by the first segment boundary notification.
  • 2. The method of claim 1, wherein the processing the notification comprises tuning to the first service.
  • 3. The method of claim 1, wherein the received notification is encrypted using a key, and determining whether the notification is authorized comprises determining whether the key is present in the digital media receiver.
  • 4. The method of claim 1, wherein the received notification is encrypted using a key, and determining whether the notification is authorized comprises determining whether the key was received by the digital media receiver during an authorization procedure.
  • 5. The method of claim 1, further comprising: receiving, from a user, an instruction to register for the notification.
  • 6. A digital media receiver comprising: logic configured to register for notification of segment boundary events associated with a first service provided to the digital media receiver;logic configured to receive a notification of a first one of the segment boundary events while tuned to a second service different than the first service, wherein the first segment boundary is conveyed in a message in a transport layer corresponding to the first service and wherein the first segment boundary includes information corresponding to a first transition type from plural types of transitions, wherein the first transition type is contained in a transition type data field, wherein the first transition type corresponds to the type of transition being notified by the first segment boundary notification;logic configured to determine whether the notification is authorized;logic configured to process the notification, responsive to the determination that the notification is authorized, wherein the logic configured to process the notification comprises logic configured to tune to the first service; andlogic configured to receive a notification of a second one of the segment boundary events while tuned to the second service different than the first service, wherein the second segment boundary is conveyed in the message in a transport layer corresponding to the first service and wherein the second segment boundary includes information corresponding to a second transition type from plural types of transitions different from the first transition type, wherein the second transition type is contained in a transition type data field, wherein the second transition type corresponds to the type of transition being notified by the second segment boundary notification.
  • 7. The digital media receiver of claim 6, wherein the received notification is encrypted using a key, and logic configured to determine whether the notification is authorized comprises logic configured to determine whether the key is present in the digital media receiver.
  • 8. The digital media receiver of claim 6, wherein the received notification is encrypted using a key, and logic configured to determine whether the notification is authorized comprises logic configured to determine whether the key was received by the digital media receiver during an authorization procedure.
  • 9. The digital media receiver of claim 6, wherein the segment boundary is a scheduled boundary.
  • 10. The digital media receiver of claim 6, wherein the segment boundary is an unscheduled boundary.
  • 11. A digital media receiver comprising: memory; anda processor configured by instructions retrieved from the memory to: receive, during an authorization process, a key associated with segment boundary event notification;register for notification of segment boundary events associated with a first one of the subset of services;receive an encrypted notification of a first one of the segment boundary events while the digital media receiver is tuned to a second one of the subset of services, the second one being different than the first one, wherein the first segment boundary is conveyed in message in a transport layer corresponding to the first one of the subset of services and wherein the first segment boundary includes information corresponding to a first particular transition type from plural types of transitions, wherein the first transition type is contained in a transition type data field, wherein the first transition type corresponds to the type of transition being notified by the segment boundary notification;decrypt the encrypted notification using the received key;process the decrypted notification; andreceive an encrypted notification of a second one of the segment boundary events while the digital media receiver is tuned to a second one of the subset of services, the second one being different than the first one, wherein the second segment boundary is conveyed in message in a transport layer corresponding to the first one of the subset of services and wherein the second segment boundary includes information corresponding to a second particular transition type from plural types of transitions different than the first particular transition type, wherein the second transition type is contained in a transition type data field, wherein the second transition type corresponds to the type of transition being notified by the segment boundary notification.
  • 12. The digital media receiver of claim 11, wherein the key is associated with segment boundary event notification for only a subset of a complete set of services available to the digital media receiver.
  • 13. The digital media receiver of claim 11, wherein the key is associated with segment boundary event notification for only a subset of a complete set of services available to the digital media receiver, the subset being premium services for which a viewer pays an extra fee.
  • 14. The digital media receiver of claim 11, wherein the key is associated with segment boundary event notification for only a subset of a complete set of services available to the digital media receiver, the subset being services for which a viewer does not pay an extra fee.
  • 15. The digital media receiver of claim 11, wherein the key is associated with segment boundary event notification for only a subset of a complete set of services available to the digital media receiver, and the processor is further configured to: determine whether the received encrypted notification corresponds to one of the services in the subset before decrypting the encrypted notification.
  • 16. The digital media receiver of claim 11, wherein the key is associated with segment boundary event notification for only a subset of types of segment boundary event notifications available to the digital media receiver, and the processor is further configured to: determine whether the received encrypted notification corresponds to one of the types in the subset before decrypting the encrypted notification.
  • 17. The digital media receiver of claim 11, wherein the processor is further configured to process the decrypted notification by causing the digital media receiver to tune to the first service.
US Referenced Citations (219)
Number Name Date Kind
5440345 Shimoda Aug 1995 A
5606359 Youden et al. Feb 1997 A
5734443 O'Grady Mar 1998 A
5734783 Shimoda et al. Mar 1998 A
5828370 Moeller et al. Oct 1998 A
5917830 Chen et al. Jun 1999 A
5917988 Eto Jun 1999 A
5943447 Tkhor et al. Aug 1999 A
5949948 Krause et al. Sep 1999 A
5963260 Bakhmutsky Oct 1999 A
6160889 Yagasaki Dec 2000 A
6188436 Williams et al. Feb 2001 B1
6201927 Commer Mar 2001 B1
6222979 Willis et al. Apr 2001 B1
6304714 Krause et al. Oct 2001 B1
6393057 Thoreau et al. May 2002 B1
6421387 Rhee Jul 2002 B1
6512552 Subramanian Jan 2003 B1
6587506 Noridomi et al. Jul 2003 B1
6594798 Chou et al. Jul 2003 B1
6643327 Wang Nov 2003 B1
6658199 Hallberg Dec 2003 B1
6754373 de Cuetos et al. Jun 2004 B1
6806909 Radha et al. Oct 2004 B1
6906743 Maurer Jun 2005 B1
6907075 Felts et al. Jun 2005 B2
6909743 Ward et al. Jun 2005 B1
6912251 Ward et al. Jun 2005 B1
6980594 Wang et al. Dec 2005 B2
7027713 Hallberg Apr 2006 B1
7050603 Rhoads et al. May 2006 B2
7053874 Koyama May 2006 B2
7085322 Ngai et al. Aug 2006 B2
7095783 Sotheran et al. Aug 2006 B1
7096481 Forecast et al. Aug 2006 B1
7129962 Cote et al. Oct 2006 B1
7185018 Archbold Feb 2007 B2
7912219 Toma et al. May 2007 B1
7236520 Kim et al. Jun 2007 B2
7243193 Walmsley Jul 2007 B2
7317839 Holcomb Jan 2008 B2
7397858 Garrido et al. Jul 2008 B2
7480335 Payson Jan 2009 B2
7577198 Holcomb Aug 2009 B2
7584495 Hannuksela et al. Sep 2009 B2
7590180 Kang Sep 2009 B2
7599435 Marpe et al. Oct 2009 B2
7599438 Holcomb Oct 2009 B2
7606308 Holcomb Oct 2009 B2
7616692 Holcomb Nov 2009 B2
7620106 Holcomb Nov 2009 B2
7623574 Holcomb Nov 2009 B2
7649937 Rabenold et al. Jan 2010 B2
7656410 Chiu Feb 2010 B2
7733910 Mace et al. Jun 2010 B2
7889788 Toma et al. Feb 2011 B2
7903743 Ho Mar 2011 B2
8136140 Hodge Mar 2012 B2
20020075402 Robson et al. Jun 2002 A1
20020092017 Klosterman et al. Jul 2002 A1
20020149591 Van Der Vleuten et al. Oct 2002 A1
20020162111 Shimizu et al. Oct 2002 A1
20020176025 Kim Nov 2002 A1
20020178444 Trajkovic et al. Nov 2002 A1
20030012554 Zeidler et al. Jan 2003 A1
20030043847 Haddad Mar 2003 A1
20030072555 Yap et al. Apr 2003 A1
20030081934 Kirmuss May 2003 A1
20030093418 Archbold May 2003 A1
20030093800 Demas et al. May 2003 A1
20030113098 Willis Jun 2003 A1
20030123849 Nallur Jul 2003 A1
20030161407 Murdock et al. Aug 2003 A1
20030189982 MacInnis Oct 2003 A1
20040078186 Nair Apr 2004 A1
20040128578 Jonnalagadda Jul 2004 A1
20040133908 Smith et al. Jul 2004 A1
20040177369 Akins, III Sep 2004 A1
20040179619 Tian et al. Sep 2004 A1
20040210925 Miyazawa et al. Oct 2004 A1
20040218816 Hannuksela Nov 2004 A1
20050002574 Fukuhara et al. Jan 2005 A1
20050013249 Kong et al. Jan 2005 A1
20050022245 Nallur et al. Jan 2005 A1
20050053134 Holcomb Mar 2005 A1
20050053140 Holcomb Mar 2005 A1
20050053141 Holcomb Mar 2005 A1
20050053142 Holcomb Mar 2005 A1
20050053143 Holcomb Mar 2005 A1
20050053144 Holcomb Mar 2005 A1
20050053155 Holcomb Mar 2005 A1
20050053295 Holcomb Mar 2005 A1
20050069212 Bottreau et al. Mar 2005 A1
20050123056 Wang Jun 2005 A1
20050175098 Narasimhan et al. Aug 2005 A1
20050190774 Wiegand Sep 2005 A1
20050207733 Gargi Sep 2005 A1
20050229225 Klausberger et al. Oct 2005 A1
20060013305 Sun Jan 2006 A1
20060036551 Oliveira et al. Feb 2006 A1
20060072597 Hannuksela Apr 2006 A1
20060083298 Wang Apr 2006 A1
20060083311 Winger Apr 2006 A1
20060093045 Anderson et al. May 2006 A1
20060093315 Kelly et al. May 2006 A1
20060126728 Yu et al. Jun 2006 A1
20060129914 Ellis Jun 2006 A1
20060132822 Walmsley Jun 2006 A1
20060147121 Maeda et al. Jul 2006 A1
20060222319 Russ Oct 2006 A1
20060224763 Altunbasak et al. Oct 2006 A1
20060282319 Maggio Dec 2006 A1
20060294171 Bossen Dec 2006 A1
20070019724 Tourapis Jan 2007 A1
20070030186 Archbold Feb 2007 A1
20070030356 Yea Feb 2007 A1
20070030818 Bahnck et al. Feb 2007 A1
20070031110 Rijckaert Feb 2007 A1
20070038921 Pekonen et al. Feb 2007 A1
20070091997 Fogg et al. Apr 2007 A1
20070106760 Houh et al. May 2007 A1
20070109409 Yea May 2007 A1
20070112721 Archbold May 2007 A1
20070116426 Toma et al. May 2007 A1
20070121721 Kim et al. May 2007 A1
20070133674 Garnier et al. Jun 2007 A1
20070140358 Schwartz et al. Jun 2007 A1
20070153679 Jost et al. Jul 2007 A1
20070172133 Kim Jul 2007 A1
20070183494 Hannuksela Aug 2007 A1
20070186240 Ward et al. Aug 2007 A1
20070194975 Jang et al. Aug 2007 A1
20070223595 Hannuksela et al. Sep 2007 A1
20070230496 Guo et al. Oct 2007 A1
20070245382 Doi et al. Oct 2007 A1
20070280350 Mathew et al. Dec 2007 A1
20080025399 Le Leannec et al. Jan 2008 A1
20080055463 Lerner Mar 2008 A1
20080056383 Ueki et al. Mar 2008 A1
20080063074 Gallant et al. Mar 2008 A1
20080115175 Rodriguez May 2008 A1
20080115176 Rodriguez May 2008 A1
20080117985 Chen May 2008 A1
20080127255 Ress et al. May 2008 A1
20080131079 Toma Jun 2008 A1
20080137742 Chen Jun 2008 A1
20080141091 Kalluri Jun 2008 A1
20080152005 Oguz et al. Jun 2008 A1
20080163308 Kim Jul 2008 A1
20080192817 Llach et al. Aug 2008 A1
20080225850 Oran et al. Sep 2008 A1
20080225951 Young Sep 2008 A1
20080244658 Chen Oct 2008 A1
20080247463 Buttimer Oct 2008 A1
20080256409 Oran et al. Oct 2008 A1
20080260045 Rodriguez et al. Oct 2008 A1
20080311869 Koga et al. Dec 2008 A1
20080320558 Imanishi et al. Dec 2008 A1
20090002379 Baeza Jan 2009 A1
20090003446 Wu Jan 2009 A1
20090003447 Christoffersen Jan 2009 A1
20090028247 Shuh Jan 2009 A1
20090034627 Rodriguez et al. Feb 2009 A1
20090034633 Rodirguez et al. Feb 2009 A1
20090073928 Power Mar 2009 A1
20090100482 Rodriguez et al. Apr 2009 A1
20090103635 Pahalawatta Apr 2009 A1
20090109342 Heng et al. Apr 2009 A1
20090116558 Chen May 2009 A1
20090138668 Blankenship May 2009 A1
20090141168 Chen et al. Jun 2009 A1
20090148056 Rodriguez et al. Jun 2009 A1
20090148132 Rodriguez et al. Jun 2009 A1
20090154560 Hong Jun 2009 A1
20090154563 Hong Jun 2009 A1
20090161770 Dong Jun 2009 A1
20090180546 Rodriguez et al. Jul 2009 A1
20090180547 Rodriguez et al. Jul 2009 A1
20090190655 Shimada Jul 2009 A1
20090190849 Huang Jul 2009 A1
20090199231 Tsuria et al. Aug 2009 A1
20090207904 Pandit et al. Aug 2009 A1
20090210412 Oliver Aug 2009 A1
20090214178 Takahashi Aug 2009 A1
20090220012 Rodriguez et al. Sep 2009 A1
20090226105 Huang Sep 2009 A1
20090262804 Pandit Oct 2009 A1
20090279608 Jeon Nov 2009 A1
20090296811 Jeon Dec 2009 A1
20090310934 Rodriguez Dec 2009 A1
20090313662 Rodriguez Dec 2009 A1
20090313668 Shepherd Dec 2009 A1
20090323822 Rodriguez Dec 2009 A1
20100003015 Rodriguez Jan 2010 A1
20100020870 Jeon Jan 2010 A1
20100026882 Jeon Feb 2010 A1
20100026883 Jeon Feb 2010 A1
20100026884 Jeon Feb 2010 A1
20100027417 Franceschini et al. Feb 2010 A1
20100027653 Jeon Feb 2010 A1
20100027654 Jeon Feb 2010 A1
20100027659 Jeon Feb 2010 A1
20100027660 Jeon Feb 2010 A1
20100027667 Samuelsson et al. Feb 2010 A1
20100027682 Jeon Feb 2010 A1
20100074340 Luo et al. Mar 2010 A1
20100088717 Candelore et al. Apr 2010 A1
20100118973 Rodriguez et al. May 2010 A1
20100118974 Rodriguez et al. May 2010 A1
20100118978 Rodriguez et al. May 2010 A1
20100118979 Rodriguez et al. May 2010 A1
20100122311 Rodriguez et al. May 2010 A1
20100150527 Sandoval Jun 2010 A1
20100215338 Rodriguez Aug 2010 A1
20100218232 Rodriguez Aug 2010 A1
20100241753 Garbajs et al. Sep 2010 A1
20100293571 Rodriguez Nov 2010 A1
20100322302 Rodriguez Dec 2010 A1
20110222837 Walton et al. Sep 2011 A1
Foreign Referenced Citations (17)
Number Date Country
0 812 112 Dec 1997 EP
1 292 138 Mar 2003 EP
1 328 119 Jul 2003 EP
05-236465 Sep 1993 JP
10-2004-0054708 Jun 2004 KR
WO 0000981 Jan 2000 WO
WO 0062552 Oct 2000 WO
0143440 Jun 2001 WO
0163774 Aug 2001 WO
WO 2004102571 Nov 2004 WO
WO 2005106875 Nov 2005 WO
WO 2006083824 Aug 2006 WO
2006101979 Sep 2006 WO
WO 2006114761 Nov 2006 WO
WO 2008063881 May 2008 WO
WO 2009018360 Feb 2009 WO
WO 2009052262 Apr 2009 WO
Non-Patent Literature Citations (75)
Entry
Stuhlmuller, Klaus, et al., “Analysis of Video Transmission over Lossy Channels”; IEEE Journal on Selected Areas in Communication, vol. 18, No. 6, Jun. 2000, pp. 1012-1032.
PCT Search Report cited in International Appln No. PCT/US2009/064180 mailed Jan. 8, 2010.
PCT Written Opinion cited in International Appln No. PCT/US2009/064180 mailed Jan. 8, 2010.
PCT Search Report cited in International Appln No. PCT/US2009/047521 mailed Dec. 22, 2009.
PCT Written Opinion cited in International Appln No. PCT/US2009/047521 mailed Dec. 22, 2009.
European Examination dated Sep. 16, 2010 in Application No. 08 796 875.6.
U.S. Non-Final Office Action in U.S. Appl. No. 11/627,452 dated Nov. 10, 2010.
U.S. Non-Final Office Action in U.S. Appl. No. 11/831,916 dated Aug. 4, 2010.
Canadian Office Action dated Dec. 11, 2009 in Application No. 2,533,169.
U.S. Appl. No. 12/709,851, filed Feb. 22, 2010 entitled “Signalling of Decodable Sub-Sequences”, Inventor: Arturo A. Rodriguez.
U.S. Appl. No. 12/713,153, filed Feb. 25, 2010 entitled “Signalling of Auxiliary Information that Assists Processing of Video According to Various Formats”, Inventors: Rodriguez et al.
U.S. Appl. No. 12/722,117, filed Mar. 11, 2010 entitled “Management of Picture Referencing in Video Streams for Plural Playback Modes”, Inventors: Walton et al.
Hurst et al., “MPEG Splicing Tutorial and Proposed SMPTE Standard”, Proceedings of the SMPTE Technical Conference, Nov. 1997, pp. 105-117.
International Preliminary Report on Patentability and Written Opinion dated Feb. 2, 2010 cited in International Application No. PCT/US2008/071111.
U.S. Non-Final Office Action dated Feb. 1, 2010 in U.S. Appl. No. 11/831,916.
International Search Report and Written Opinion dated Apr. 15, 2010 cited in International Application No. PCT/US2010/024927.
European Examination dated May 4, 2010 in Application No. 07 844 937.8.
U.S. Appl. No. 12/779,035, filed May 12, 2010 entitled “Signalling Buffer Characteristics for Splicing Operations of Video Streams”, Inventors: Rodriguez et al.
U.S. Appl. No. 12/492,117, filed Jun. 25, 2009, entitled “Support for Blocking Trick Mode Operations.”
U.S. Appl. No. 12/483,925, filed Jun. 12, 2009, entitled “Picture Interdependencies Signals in Context of MMCO to Assist Stream Manipulation.”
U.S. Appl. No. 12/417,868, filed Apr. 3, 2009, entitled “Segment Boundary Notification to a Digital Media Receiver.”
U.S. Appl. No. 12/417,869, filed Apr. 3, 2009 entitled “System and Method for Processing Segment Boundary Notifications.”
ITU-T Telecommunication Standardization Sector of ITU, Infrastructure of Audiovisual Services—Coding of Moving Video, “Advanced Video Coding for Generic Audiovisual Services”, International Telecommunication Union, H.264, May 2003, XP008095420, 282 pages.
Tian et al., “Sub-Sequence Video Coding for Improved Temporal Scalability”, 4 pages.
Gruneberg et al., International Organisation for Standardisation Organisation Internationale de Normalisation ISO/IEC JTC1/SC29/WG11 Coding of Moving Pictures and Audio, “Proposal for MPEG-2 Transport Stream Extensions for Scalable Video Coding”, XP030043296, Jul. 2007, 6 pages.
Amon et al., “File Format for Scalable Video Coding”, IEEE Transactions on Circuits and Systems for Video Technology, vol. 17 No. 9, Sep. 2007, pp. 1174-1185.
ITU: “Series H: Audiovisual and Multimedia Systems: Infrastructure of Audiovisual Services—Transmission Multiplexing and Synchronization”, Systems ITU-T Recommendation H.222.0, May 2006, http://mirror.itu.int/dms/pay/itu-t/rec/h/T-REC-H.222.0-200605-1—PDF—E.pdf, XP007905991, pp. 1-76.
MacInnis et al., International Organisation for Standardization Organisation Internationale Normalisation ISO/IEC JTC1/SC29/WG11 Coding of Moving Pictures and Audio, “NAL for AVC Video with MPEG-2 Systems”, Video Standards and Drafts, Mar. 2002, pp. 1-11.
“Splice Points for MPEG-2 Transport Streams”, SMPTE Journal, SMPTE Inc., vol. 107 No. Oct. 1998, XP-000793004, pp. 916-925.
Rodriguez et al., “SEI message to convey suitable splice points in the bitstream”, JVT Meeting, Document JVT-Z040, Filename JVT-Z040.doc, XP-30007329, Jan. 2008, pp. 1-8.
Luo et al., “On HRD conformance for splice bitstreams”, JVT Meeting, Document JVT-V055r1, Filename JVT-V055r1.doc, XP-30006863, Jan. 2007, pp. 1-11.
International Search Report dated Sep. 4, 2009 cited in International Application No. PCT/US2009/047237.
Written Opinion dated Sep. 4, 2009 cited in International Application No. PCT/US2009/047237.
International Search Report dated Sep. 4, 2009 cited in International Application No. PCT/US2009/044370.
Written Opinion dated Sep. 4, 2009 cited in International Application No. PCT/US2009/044370.
International Search Report dated May 23, 2008 cited in International Application No. PCT/US2007/083867.
Written Opinion dated May 6, 2008 cited in International Application No. PCT/US2007/083867.
International Search Report and Written Opinion dated Oct. 30, 1998 cited in International Application No. PCT/US2008/071621.
International Search Report and Written Opinion dated Oct. 18, 2004 cited in International Application No. PCT/US2004/023279.
International Search Report and Written Opinion dated Apr. 15, 2009 cited in International Application No. PCT/US2008/080128.
U.S. Non-Final Office Action dated Dec. 28, 2007 in U.S. Appl. No. 10/623,683.
U.S. Final Office Action dated Jul. 25, 2008 in U.S. Appl. No. 10/623,683.
U.S. Final Office Action in U.S. Appl. No. 11/627,452 dated Mar. 4, 2011.
U.S. Non-Final Office Action in U.S. Appl. No. 11/831,916 dated Mar. 31, 2011.
U.S. Non-Final Office Action in U.S. Appl. No. 12/417,869 dated Apr. 4, 2011.
European Communication dated Aug. 9, 2011 in Application No. 08 838 787.3.
European Communication dated Dec. 14, 2011 in Application No. 09 751 294.1.
U.S. Non-Final Office Action in U.S. Appl. No. 12/417,864 dated Apr. 18, 2011.
U.S. Non-Final Office Action mailed Aug. 5, 2011 in U.S. Appl. No. 11/831,906.
U.S. Final Office Action mailed Aug. 5, 2011 in U.S. Appl. No. 12/417,869.
U.S. Non-Final Office Action mailed Sep. 14, 2011 in U.S. Appl. No. 12/124,779.
U.S. Non-Final Office Action mailed Sep. 22, 2011 in U.S. Appl. No. 11/831,912.
U.S. Final Office Action mailed Sep. 28, 2011 in U.S. Appl. No. 11/831,916.
U.S. Non-Final Office Action mailed Nov. 10, 2011 in U.S. Appl. No. 12/483,925.
U.S. Non-Final Office Action mailed Nov. 23, 2011 in U.S. Appl. No. 12/141,015.
U.S. Non-Final Office Action mailed Nov. 29, 2011 in U.S. Appl. No. 12/492,117.
U.S. Non-Final Office Action mailed Nov. 23, 2011 in U.S. Appl. No. 12/141,017.
U.S. Non-Final Office Action mailed Dec. 21, 2011 in U.S. Appl. No. 12/333,296.
U.S. Non-Final Office Action mailed Dec. 22, 2011 in U.S. Appl. No. 12/617,043.
U.S. Non-Final Office Action mailed Dec. 27, 2011 in U.S. Appl. No. 12/417,869.
U.S. Non-Final Office Action mailed Dec. 27, 2011 in U.S. Appl. No. 12/252,632.
U.S. Non-Final Office Action mailed Jan. 4, 2012 in U.S. Appl. No. 12/617,062.
U.S. Non-Final Office Action mailed Jan. 10, 2012 in U.S. Appl. No. 12/333,301.
U.S. Non-Final Office Action mailed Jan. 18, 2012 in U.S. Appl. No. 12/617,015.
U.S. Final Office Action mailed Jan. 19, 2012 in U.S. Appl. No. 12/124,779.
U.S. Final Office Action mailed Feb. 17, 2012 in U.S. Appl. No. 11/627,452.
U.S. Final Office Action mailed Jan. 2, 2014 in U.S. Appl. No. 12/483,925, 47 pages.
U.S. Final Office Action mailed Jan. 16, 2014 in U.S. Appl. No. 12/333,296, 18 pages.
U.S. Final Office Action mailed Jan. 27, 2014 in U.S. Appl. No. 12/492,117, 23 pages.
U.S. Non-Final Office Action mailed Jan. 29, 2014 in U.S. Appl. No. 12/252,632, 22 pages.
U.S. Final Office Action mailed Jan. 30, 2014 in U.S. Appl. No. 12/722,117, 22 pages.
U.S. Office Action mailed Feb. 10, 2014 in U.S. Appl. No. 12/713,153, 18 pages.
U.S. Office Action mailed Feb. 13, 2014 in U.S. Appl. No. 13/633,672, 5 pages.
U.S. Office Action mailed Mar. 21, 2014 in U.S. Appl. No. 11/831,906, 20 pages.
U.S. Office Action mailed Mar. 28, 2014 in U.S. Appl. No. 12/417,869, 12 pages.