Fast channel change in a video delivery network

A client establishes connections with a media server. The connections include a first connection for regular playback and one or more second connections for processing a channel change. Segments of a first video are received from the media server using the first connection in the plurality of connections. The first video is being played on a first channel in a plurality of channels. The client receives a request to change from the first channel to a second channel in the plurality of channels. A request for at least a portion of a segment of a second video being played on the second channel is sent to the media server. The request includes a channel change indicator. The client then receives the at least the portion of the segment of the second video using the one or more second connections with the media server.

BACKGROUND

When watching television, users expect a channel change to occur very fast. In a traditional digital video broadcast environment, the channel change is able to occur very fast because a content provider sends all channels to a set top box even though the user is only watching a single channel at a time. Thus, when the user changes channel, the set top box has already received the video for the channel and can switch to displaying the video for the new channel. However, in other environments, such as in the over-the-top (OTT) environment, a channel change typically takes a longer time because all the live channels are not sent to a client device continuously; instead, they typically are sent to the client device upon request. All the channels may not be sent because there typically is a larger amount of channels being offered or the Internet connection in the OTT environment may have less bandwidth availability compared to the digital video broadcast environment. Thus, the process to change channels in the OTT environment may be slower.

DETAILED DESCRIPTION

Some embodiments provide a channel change service that can change channels for a user. In some examples, the channel change service may be used in an over-the-top (OTT) environment in which videos are streamed to a media player on a client device using a streaming protocol. In some embodiments, the streaming protocol may be a hypertext transfer protocol (HTTP)-based media streaming protocol, such as HTTP live streaming (HLS), dynamic adaptive streaming over HTTP (DASH), or other segment based manifest protocols. The channel change service reduces the channel switching time compared to methods described in the Background and also allows a user to skip directly to any channel that is being offered in a live television service and experience a similar channel change time.

In the fast channel change service, a client device can establish multiple connections with multiple edge servers. That is, the client device has multiple connections open with each edge server. For one of the edge servers that is currently being used to play the video during number playback, the connections may include a first connection that is used for regular playback of video and the other connections are used when processing a channel change. These other connections remain idle until a channel change request is received. For other edge servers, all connections may remain idle until a channel change request is received.

The media player of the client device can start playback of a video for a first channel that is being offered by a video delivery service with a first edge server. The first edge server may be a media server that delivers the video using a first connection for regular playback. When a media player receives a channel change request to change from the first channel to a second channel, the media player may request at least a segment of a video being offered on the second channel. The media player also inserts a channel change indicator in the request that indicates that this is a channel change request and not a regular playback request. Further, instead of just sending a request to the first edge server, the media player can send requests for different byte ranges for the segment of the video being played on the second channel to multiple edge servers. For example, the media player may send a first request for the byte range 0-200 bytes of the segment to the first edge server, a second request to a second edge server for a byte range 201-400, a third request to a third edge server for a byte range 401-600, and so on.

When the edge servers receive the requests, the edge servers determine that the requests include the channel change indicator. This indicates to the edge servers that the fast channel change process should be initiated. In some embodiments, the edge servers invoke a high priority thread that manages the fast channel change process. The high priority thread may use a different algorithm to send the video than the normal priority thread, such as using an algorithm that may be more aggressive in sending the video at higher speeds. For example, the high priority thread may send the video at a higher speed from the beginning of the transmission. In contrast, the regular playback algorithm may use grade climbing that starts with using a smaller bandwidth and gradually increases the bandwidth used. Also, the high priority thread may be given a higher priority to execute in the edge servers. Further, the high priority thread may start sending the byte range to the media player of the client device using all the connections that are open with the client device. This may increase the throughput and speed for sending the bytes.

When the media player receives the bytes from the multiple edge servers, the media player reassembles the bytes for the one or more segments. Additionally, as will be discussed in more detail below, a transcoder may have been decoding the video for the prior channel using sequential timestamps. For example, each frame of the video may be associated with a time stamp. If the timestamp for the next video frame is not sequentially the next timestamp, then the transcoder may have to be reset. Accordingly, the media player may change the timestamp that is received for frames in the segment that is received for the second channel. This allows the transcoder to continue transcoding the video without having to be reset.

In addition to performing the above process, the media player may also receive thumbnails from one or more of the edge servers of a few images of video for the second channel that the media player can animate to simulate the video being played. This may give the impression to a user that the channel change has already been performed and the video has started. Once the animation is finished, the media player can start displaying the one or more segments may have been decoded.

FIG. 1depicts a simplified system100for performing a fast channel change process according to some embodiments. System100includes a video delivery service102, one or more content delivery networks (CDNs)104, and a client106. Video delivery service102may include one or more servers that communicate with CDNs104and client106. Also, although a single client106is described, it will be understood that the fast channel change process may occur with multiple clients.

Client106may be a computing device that can play video, such as a smartphone, tablet device, streaming device, set top box, or other device. Also, client106may include a user interface111that displays a media player112that plays the video. Although a single instance of client106is described, it will be understood that the video may be played on another device. For example, a streaming device may display media player112on a television.

CDNs104include edge servers108that are located in different areas, such as different locations. In some embodiments, it is preferable that edge servers108that are closest to client106are used to deliver video. Although multiple CDNs104are described, it will be understood that only a single CDN104in a single location may be used. However, multiple CDNs104including multiple edge servers108at different locations may also be used. Also, although edge servers that may be located at the edge of CDN104and be the server at the edge of the CDN to delivery video to clients, any type of server may be used.

Video delivery service102may provide a video service that allows users to view on-demand videos in a video library and also view live television on different channels. The live television service provides multiple channels, such as networks and movie channels that provide serial programming at set times. Client106can request either an on-demand video or tune to one of the channels being offered by the live television service.

Video delivery service102includes a channel change service110that can configure the fast channel change. For example, channel change service110can communicate with edge servers108to configure them to process fast channel changes for client106. In some embodiments, to perform the fast channel change service, video delivery service102may have control over edge service108and can configure the edge servers to perform the fast channel change process described below. This is different from using an edge server that is controlled by a different company and used to serve video for multiple companies. The other company may not allow the edge server to be configured for a fast channel change process due to server limitations, such as leaving connections idle after a time period may not be efficient use of computing resources. In this example, channel change service110can direct client106to edge servers that are controlled by video delivery service102.

Video delivery service102may also provide the video for the live channels to CDNs104. In addition to this, as will be discussed in more detail, channel change service110may provide thumbnails for the video, such as thumbnails for every second of a video, which client106can use to generate an animation when a channel change occurs.

As discussed above, edge servers108use a streaming protocol that requests segments, such as an HTTP protocol in which client106requests segments of video and receives those segments of video from edge servers108. The streaming protocols uses manifests that list segments of the video to request. Video delivery service102may provide the manifests to client106for all the live channels that client106can use to request segments of a video. The manifests list identifiers for segments of the video being offered on each channel. Also, video delivery service102may provide the manifests for all live channels to edge servers108such that edge servers108can identify the segments that are requested by clients106.

In client106, media player112includes a channel change engine114that can perform the fast channel change. As will be discussed in more detail below, channel change engine114may communicate with edge servers108when the channel change request occurs.

Client106also includes a transcoder116that decodes segments of video that are received from edge servers108. Transcoder116decodes encoded video received from edge servers108, and provides the decoded video to media player112. Media player112can then display the decoded video.

Transcoder116includes certain requirements to continuously decode video without resetting, such as when decoding video, a timestamp a portion of the video, such as for each frame being decoded should be sequential. To continue decoding a video, this timestamp must continue to the next sequential number or the transcoder needs to be reset. For example, the video may have timestamps that start from #0 and go to #200. If transcoder116is on frame #100, if a frame with a timestamp of #90 is received, transcoder116will reset. The resetting of transcoder116may delay the decoding of video, which delays the display of the video.

The use of the above features will now be described in a fast channel change process.

Playback of Video from a First Channel

FIG. 2depicts a simplified flowchart200of a method for starting playback of a video for a channel according to some embodiments. At202, client106sends a request to video delivery service102for initiating a live television service. For example, client106may load user interface111, which displays different options for on-demand video and live television. When the user interface111is initialized, client106may send the request to servers of video delivery service102. For the discussion, when client106is discussed, it will be understood that any component of client106may perform the action, such as user interface111, media player112, or other applications running on client106.

At204, client106receives a list of edge servers from video delivery service102. For example, video delivery service102may use a location of client106that is included in the request to determine edge servers that are located proximate to client106. Also, video delivery service102may use user profile information for the user that indicate where the user resides. Some CDNs104may include edge servers108that are located closer to the location of client106and may be able to provide faster video delivery. Although edge servers108that are located proximate to client106may be returned, it will be understood that other factors may be taken into account, such as video delivery service102returns edge servers108that have the most available bandwidth.

At206, client106establishes multiple connections to each of at least a portion of the edge servers108on the list. That is, for each edge server108that client106establishes a connection, client106establishes multiple connections with that edge server, not just one. To allow the multiple connections to be made, channel change server110may configure edge server108to support connections made from the same client identifier, such as from the same Internet Protocol (IP) address. In some examples, a first connection to an edge server108may be for the sending and receiving of video for a channel during normal playback. The other connections may be reserved for when a channel change request occurs and remain idle during the normal playback process. As will be discussed in more detail below, edge server108are configured to keep these connections idle, but will not close them even though no traffic is being sent on the connections past a time limit. In some embodiments, because video delivery service102controls edge servers108, edge servers108are configured to not close these connections when idle. Typically, when no traffic occurs on connections, edge servers108close the connections. However, video delivery service102can configure edge servers108to not close these connections by removing any time limits for closing idle connections.

At208, client106sends a request to one of the edge servers108for a first channel. For example, a user may want to watch a video being offered at that time on the first channel and inputs a request for that channel in user interface111. The edge server108receives the request and can start to send video for the channel. The video that edge server108sends is the video for a program being offered on that channel at that time. At210, client106receives the video for the program through a first connection in the multiple connections that are open with edge server108. The first connection is the connection that edge server108uses during normal playback (not when a channel change is occurring). At212, media player112then plays the video. For example, transcoder116decodes the video and then media player112plays the decoded video.

Connection Creation

Although client106can perform the fast channel change process with a single edge server108, using multiple edge servers108may make the fast channel change process faster.FIG. 3depicts an example of creating multiple connections to edge servers108according to some embodiments. Client106opens up multiple connections with each edge server108-1to108-N at302-1to302-N, respectively. The number of edge servers108from the list may be configured statically, such as client106always opens up connections to four edge servers108-1to108-N; however, client106may open up a variable number of connections to a variable number of edge servers. For example, the number of connections between client106and each edge server108may vary based on conditions at edge server108. In some examples, an edge server108with more processing resources may allow client106to open up more connections. In other examples, client106may open up a pre-defined number of connections with edge server108, such as edge server108may keep five to ten connections open with client106compared to traditionally one to two connections per device. Also, the number of edge servers108may vary based on how many edge servers are located near to client106, or may be preset.

As discussed above, during normal playback, when client106receives video from an edge server, such as edge server108-1for the first channel, only one connection is being used as shown at304. All other connections shown inFIG. 3may be idle. In some embodiments, edge servers108may be able to support 100,000 connections in parallel. However, in the fast channel change process, one session may require one to six megabytes per second (Mbps) bandwidth and a 10 gigabyte (Gbps) network interface card (NIC) may only support several thousand clients. However, this allows edge server108to keep ten idle connections with each device for the fast channel change process.

FIG. 4shows an example of the connection with edge server108-1when receiving video for the first channel according to some embodiments. CDN104-1may include an origin server402that may receive videos for programs being offered for all the channels from video delivery service102. Origin server402may then provide video for these channels to other edge servers108, such as edge server108-1. In some embodiments, origin server402may provide the video for all the channels in a push model (origin server sends the videos without receiving requests from edge servers). In other embodiments, origin server402may only provide video for channels that are actively being requested by clients106in a pull model (edge servers request the videos). Also, origin server402may push the manifests for all channels to edge server108, which allows the edge server to process channel change requests that request segments from other channels.

Origin server402may also push thumbnails for the video to edge servers108, such as edge server108-1. Origin server402may receive the thumbnails from video delivery service102and push them to edge server108-1continuously, such as every second. In other embodiments, video delivery service102may send the thumbnails directly to edge server108-1. The thumbnails may be for video for all the channels being offered and may be lower resolution than the video. For example, video delivery service102sends lower resolution thumbnails for every second or frame of the video. As will be discussed in more detail below the thumbnails allow media player112to generate an animation while the channel change is being processed.

Edge server108-1then delivers the video for the first channel to client106at304. Additionally, at404-2, idle connections between edge server108and client106are shown. These connections are not sending any data at this time.

Fast Channel Change Process

At some point, client106may receive a channel change request from a user. For example, user interface111may receive the channel change request. In some embodiments, edge server108is only sending video for a single channel to client106. That is, edge server108is not sending video for multiple channels to client106before a channel change request is received.FIG. 5depicts a simplified flowchart500of a method for processing a channel change request according to some embodiments. At502, user interface111receives a channel change request for changing from a first channel to a second channel. In some examples, user interface111receives the channel change request from a user. It is noted that the first channel and the second channel do not need to be sequential, such as a user may change from a channel offered in the live television service to any other channel and experience a similar channel change time.

At504, client106determines edge servers108from a list of edge servers108to contact for the channel change. For example, as discussed previously, client106may have previously opened multiple connections with edge servers108before receiving the channel change request. Client106may contact some or all of these edge servers108to perform the fast channel change.

At506, client106determines a segment of video from the second channel to request. For example, for the fast channel change process, client106may request a single segment of the video, which may be a certain length of video, such as one to ten seconds of video. In other examples, client106may request multiple segments, such as two to four segments, to perform the channel change. A single segment will be described for discussion purposes, but it will be understood that multiple segments may be requested.

At508, client106generates requests for different byte ranges of the segment and includes a channel change indicator in the requests. The channel change indicator indicates to edge servers108that this request for the byte range of the segment is for a channel change. Because client106received the manifests for all the channels being offered, client106can then determine which is the next segment to request for the video being offered on the second channel. For example, client106determines the segment being offered at the present time on the second channel without having to request the manifest for the second channel. Because the request for the segment of video is sent to edge servers108, client106uses an indicator to edge servers108that this is for a channel change request rather than just a regular request for a portion of the segment. The indicator causes edge servers108to use the fast channel change process rather than the regular playback process. In some examples, the channel change indicator may be a flag or byte that is set in the request to indicate that the request is for a channel change. Edge server108processes the channel change requests using the fast channel change process and when the fast channel change process is finished, then edge server108returns to streaming of the video using the normal process of streaming through only a single connection.

At510, client106sends the requests for the byte ranges to different edge servers108. For example, client106requests for different portions of the segment to the different edge servers. Although sending requests to different edge servers108is described, the process may be performed using a single edge server108that receives one or more requests for one or more segments.

At512, client106receives different byte ranges from edge servers108via multiple connections.FIG. 6depicts an example of showing the receiving the different byte ranges from multiple edge servers108according to some embodiments. Edge servers108-1to108-N may receive requests for different byte ranges for the segment. Then, edge servers108-1to108-N can invoke a fast channel change process that processes the request for the byte range. The fast channel change process may invoke a high priority thread, such as a CPU affinity thread, that has priority on a CPU can initiate the transfer of the bytes on multiple connections. For example, if one connection was already established and active between edge server108-1and client106, the connection information, such as the socket, may be transferred to the other connections for use in transferring the bytes. In some examples, all three connections shown at602-1may transfer some portion of the byte range 0-200. In some embodiments, one socket can be sent to normal thread/process and then get dispatched to another thread via a communication mechanism, such as via an inter-process communication (IPC). Also, client106may directly send a request to the channel switching connections with the connection information. For example, if there are eight CPUs on one edge server, then the edge server can have six thread/processes to handle normal requests and two thread/processes for channel switching requests. The normal thread/processes may process 1000 requests/second (RPS) and the switching thread/processes may process 50 RPS, but need to keep idle connections. Also, edge servers may be reserved for just processing switching request. For example, six edge servers are reserved for normal playback and two switching servers are reserved to serve switching requests. The requests can be dispatched from one server to another, and also clients106can be notified which server is switching server then client106sends a request to the switching server.

For edge servers108-2to108-N that were not transferring video prior to the channel change request, edge servers108-2to108-N may receive the channel change request and then invoke the fast channel change process. Similarly, edge servers108-2to108-N may use a high priority thread that activates the connections automatically that were previously established between the edge servers and client106. The connection information that was received in the request from client106may be used and transferred to the other connections that were idle.

As shown, edge server108-2may transfer bytes201-400in connections shown at602-2; edge server108-3may transfer bytes401-600in connections shown at602-3; and edge server108-N may transfer bytes X-N in connections shown at602-N. However, it will be understood that other byte ranges and other edge servers108may be used to transfer the bytes.

Client106may receive the byte ranges and transcoder116may decode the bytes received. However, during the decoding process, client106may display thumbnails in an animation to make it seem to the user that the channel change is occurring quicker.FIG. 7depicts a simplified flowchart700of a method for performing the fast channel change at client106using the thumbnails according to some embodiments. At702, client106receives thumbnails from edge server108. For example, any number of edge servers108-1to108-N that receive the channel change request may send the thumbnails. In some embodiments, the edge server108-1that was previously sending video for the first channel may send thumbnails for the second channel. The thumbnails are a reduced resolution image of the first few frames of the segment. For example, ten thumbnails may be sent to client106. Transcoder116may decode the thumbnails and provide them to media player112. At704, media player112then generates an animation with the thumbnails. For example, media player112may display the thumbnails in succession to create an animation of the video being played.

At706, client106receives byte ranges for the segment from edge servers108-1to108-N. In some instances, the byte ranges may be received in varying order. Transcoder116may arrange the byte ranges in order as they are received. For example, transcoder116may store the byte ranges in a buffer in an order.

At708, client106adjusts the timestamps for the video, if needed. For example, media player112may adjust the timestamps for the byte ranges received based on the previous timestamp that was used for the first channel. If, for instance, transcoder116was on a frame #100 for the first channel, then transcoder116would expect to receive the next frame with a timestamp #101. However, if the timestamp for the frames in the segment received for the second channel start at #90, then transcoder116would have to be reset because this timestamp is not in sequential order. Accordingly, media player112may adjust the timestamps for the video that is received to be sequential from the last timestamp received from the first channel. This allows transcoder116to continue decoding the video without being reset. For example, media player112may adjust the timestamp for the first frame received for the segment to #101 and adjust the rest of the timestamps for the video in an ongoing basis. For example, if the first video for the first channel had timestamps from #0 to #200, and the second video had timestamps from 0 to 300, then media player112adjusts the timestamps from #90 to #300 to #101 to #310.

At710, transcoder116receives the byte ranges for the segment and decodes the byte ranges. At712, media player112then receives and plays the decoded video for the segment. At some point after the fast channel change process is finished, channel change engine114may then proceed to request segments from only the single edge server108using the normal playback process and without including the channel change indicator in the request.

Edge Server Channel Change Process

FIG. 8depicts a simplified flowchart800of a method performed on edge server108for a fast channel change according to some embodiments. At802, edge server108delivers video for a first channel on a first connection with client106. Edge server108also uses a normal playback process to provide the video on the first connection and not any of the other connections to client106. The normal playback process may also use a streaming algorithm that gradually steps up the bandwidth used. For example, the streaming algorithm may first send a small amount of bytes, receive an acknowledgement that the client received the bytes, send a slighter larger amount of bytes, receive an acknowledgement, and continue doing so until a certain amount of bytes is reached. This gradual increase is used to test the available bandwidth.

At804, edge server108keeps idle connections open with client106. For example, edge server108may not be configured to close connections in which communications on the connection have not occurred after a certain period of time. In some examples, edge server108keeps the idle connections until the first connection is closed.

At806, edge server108receives a request for a segment of video. The request may be for a byte range. The request for the byte range may be for the same video that is being offered on the first channel or may be for another video being offered on a second channel.

At808, edge server108determines whether or not a channel change has occurred. For example, edge server108reviews the request to determine whether or not a channel change indicator has been included in the request by media player112. If a channel change indicator has not been included in the request, then edge server108continues to process the request using a normal priority thread. The normal priority thread may have a priority that is not high priority and may not be assigned to a dedicated CPU.

If the channel change indicator is included in the request, at812, edge server108initiates a fast channel change process using a high priority thread. The high priority thread has a priority that is higher than the thread that was being used to process the first channel for regular playback. For example, edge server108may assign the high priority thread to a CPU that is dedicated to processing channel change requests or the high priority thread has priority over other threads that are processing other tasks to ensure that the channel change is processed with high priority. Also, the fast channel change process also includes activating other connections between edge server108and client106.

At814, edge server108sends the byte range that was requested using the high priority thread on the multiple connections with client106. For example, the byte range that was requested may be split among the multiple connections with client106and sent to client106. Also, edge server108may send the video using a different streaming algorithm, such as one that attempts to use the most bandwidth available. Edge server108may have been monitoring the available bandwidth between client106and itself during normal playback. Edge server108may then determine a higher bandwidth to send the video, such as either the highest bandwidth reading received, the average bandwidth, or another value without using the gradual increase in bandwidth that is used in the normal playback process.

Accordingly, some embodiments provide a fast channel change using an over-the-top network that is using an HTTP-based protocol that requests segments. The process avoids transcoder116reset during the channel switching. Also, because video delivery service102has control over edge servers108, the use of multiple connections can increase the sending of the byte range for the channel change in addition to using multiple edge servers108to send different byte ranges. Along with the animation of the thumbnails, some embodiments provide a channel change that is faster than using just the single connection.

System

Features and aspects as disclosed herein may be implemented in conjunction with a video streaming system900in communication with multiple client devices via one or more communication networks as shown inFIG. 9. Aspects of the video streaming system900are described merely to provide an example of an application for enabling distribution and delivery of content prepared according to the present disclosure. It should be appreciated that the present technology is not limited to streaming video applications, and may be adapted for other applications and delivery mechanisms. The video streaming system900may also include edge server108.

In one embodiment, a media program provider may include a library of media programs. For example, the media programs may be aggregated and provided through a site (e.g., Website), application, or browser. A user can access the media program provider's site or application and request media programs. The user may be limited to requesting only media programs offered by the media program provider.

In system900, video data may be obtained from one or more sources for example, from a video source910, for use as input to a video content server902. The input video data may comprise raw or edited frame-based video data in any suitable digital format, for example, Moving Pictures Experts Group (MPEG)-1, MPEG-2, MPEG-4, VC-1, H.264/Advanced Video Coding (AVC), High Efficiency Video Coding (HEVC), or other format. In an alternative, a video may be provided in a non-digital format and converted to digital format using a scanner and/or transcoder. The input video data may comprise video clips or programs of various types, for example, television episodes, motion pictures, and other content produced as primary content of interest to consumers. The video data may also include audio or only audio may be used.

The video streaming system900may include one or more computer servers or modules902,904, and/or907distributed over one or more computers. Each server902,904,907may include, or may be operatively coupled to, one or more data stores909, for example databases, indexes, files, or other data structures. A video content server902may access a data store (not shown) of various video segments. The video content server902may serve the video segments as directed by a user interface controller communicating with a client device. As used herein, a video segment refers to a definite portion of frame-based video data, such as may be used in a streaming video session to view a television episode, motion picture, recorded live performance, or other video content.

In some embodiments, a video advertising server904may access a data store of relatively short videos (e.g., 10 second, 30 second, or 60 second video advertisements) configured as advertising for a particular advertiser or message. The advertising may be provided for an advertiser in exchange for payment of some kind, or may comprise a promotional message for the system900, a public service message, or some other information. The video advertising server904may serve the video advertising segments as directed by a user interface controller (not shown).

The video streaming system900may further include an integration and streaming component907that integrates video content and video advertising into a streaming video segment. For example, streaming component907may be a content server or streaming media server. A controller (not shown) may determine the selection or configuration of advertising in the streaming video based on any suitable algorithm or process. The video streaming system900may include other modules or units not depicted inFIG. 9, for example administrative servers, commerce servers, network infrastructure, advertising selection engines, and so forth.

The video streaming system900may connect to a data communication network912. A data communication network912may comprise a local area network (LAN), a wide area network (WAN), for example, the Internet, a telephone network, a wireless cellular telecommunications network (WCS)914, or some combination of these or similar networks.

One or more client devices920may be in communication with the video streaming system900, via the data communication network912and/or other network914. Such client devices may include, for example, one or more laptop computers920-1, desktop computers920-2, “smart” mobile phones920-3, tablet devices920-4, network-enabled televisions920-5, or combinations thereof, via a router918for a LAN, via a base station917for a wireless telephony network914, or via some other connection. In operation, such client devices920may send and receive data or instructions to the system900, in response to user input received from user input devices or other input. In response, the system900may serve video segments and metadata from the data store909responsive to selection of media programs to the client devices920. Client devices920may output the video content from the streaming video segment in a media player using a display screen, projector, or other video output device, and receive user input for interacting with the video content.

Distribution of audio-video data may be implemented from streaming component907to remote client devices over computer networks, telecommunications networks, and combinations of such networks, using various methods, for example streaming. In streaming, a content server streams audio-video data continuously to a media player component operating at least partly on the client device, which may play the audio-video data concurrently with receiving the streaming data from the server. Although streaming is discussed, other methods of delivery may be used. The media player component may initiate play of the video data immediately after receiving an initial portion of the data from the content provider. Traditional streaming techniques use a single provider delivering a stream of data to a set of end users. High bandwidths and processing power may be required to deliver a single stream to a large audience, and the required bandwidth of the provider may increase as the number of end users increases.

Streaming media can be delivered on-demand or live. Streaming enables immediate playback at any point within the file. End-users may skip through the media file to start playback or change playback to any point in the media file. Hence, the end-user does not need to wait for the file to progressively download. Typically, streaming media is delivered from a few dedicated servers having high bandwidth capabilities via a specialized device that accepts requests for video files, and with information about the format, bandwidth and structure of those files, delivers just the amount of data necessary to play the video, at the rate needed to play it. Streaming media servers may also account for the transmission bandwidth and capabilities of the media player on the destination client. Streaming component907may communicate with client device920using control messages and data messages to adjust to changing network conditions as the video is played. These control messages can include commands for enabling control functions such as fast forward, fast reverse, pausing, or seeking to a particular part of the file at the client.

Since streaming component907transmits video data only as needed and at the rate that is needed, precise control over the number of streams served can be maintained. The viewer will not be able to view high data rate videos over a lower data rate transmission medium. However, streaming media servers (1) provide users random access to the video file, (2) allow monitoring of who is viewing what video programs and how long they are watched, (3) use transmission bandwidth more efficiently, since only the amount of data required to support the viewing experience is transmitted, and (4) the video file is not stored in the viewer's computer, but discarded by the media player, thus allowing more control over the content.

Streaming component907may use TCP-based protocols, such as HTTP and Real Time Messaging Protocol (RTMP). Streaming component907can also deliver live webcasts and can multicast, which allows more than one client to tune into a single stream, thus saving bandwidth. Streaming media players may not rely on buffering the whole video to provide random access to any point in the media program. Instead, this is accomplished through the use of control messages transmitted from the media player to the streaming media server. Another protocol used for streaming is hypertext transfer protocol (HTTP) live streaming (HLS) or Dynamic Adaptive Streaming over HTTP (DASH). The HLS or DASH protocol delivers video over HTTP via a playlist of small segments that are made available in a variety of bitrates typically from one or more content delivery networks (CDNs). This allows a media player to switch both bitrates and content sources on a segment-by-segment basis. The switching helps compensate for network bandwidth variances and also infrastructure failures that may occur during playback of the video.

The delivery of video content by streaming may be accomplished under a variety of models. In one model, the user pays for the viewing of video programs, for example, using a fee for access to the library of media programs or a portion of restricted media programs, or using a pay-per-view service. In another model widely adopted by broadcast television shortly after its inception, sponsors pay for the presentation of the media program in exchange for the right to present advertisements during or adjacent to the presentation of the program. In some models, advertisements are inserted at predetermined times in a video program, which times may be referred to as “ad slots” or “ad breaks.” With streaming video, the media player may be configured so that the client device cannot play the video without also playing predetermined advertisements during the designated ad slots.

Referring toFIG. 10, a diagrammatic view of an apparatus1000for viewing video content and advertisements is illustrated. In selected embodiments, the apparatus1000may include a processor (CPU)1002operatively coupled to a processor memory1004, which holds binary-coded functional modules for execution by the processor1002. Such functional modules may include an operating system1006for handling system functions such as input/output and memory access, a browser1008to display web pages, and media player1010for playing video. The modules may further include channel change engine114. The memory1004may hold additional modules not shown inFIG. 10, for example modules for performing other operations described elsewhere herein.

A bus1014or other communication component may support communication of information within the apparatus1000. The processor1002may be a specialized or dedicated microprocessor configured to perform particular tasks in accordance with the features and aspects disclosed herein by executing machine-readable software code defining the particular tasks. Processor memory1004(e.g., random access memory (RAM) or other dynamic storage device) may be connected to the bus1014or directly to the processor1002, and store information and instructions to be executed by a processor1002. The memory1004may also store temporary variables or other intermediate information during execution of such instructions.

A computer-readable medium (CRM) in a storage device1024may be connected to the bus1014and store static information and instructions for the processor1002; for example, the storage device (CRM)1024may store the modules1006,1008, and1010when the apparatus1000is powered off, from which the modules may be loaded into the processor memory1004when the apparatus1000is powered up. The storage device1024may include a non-transitory computer-readable storage medium holding information, instructions, or some combination thereof, for example instructions that when executed by the processor1002, cause the apparatus1000to be configured to perform one or more operations of a method as described herein.

A communication interface1016may also be connected to the bus1014. The communication interface1016may provide or support two-way data communication between the apparatus1000and one or more external devices, e.g., the streaming system900, optionally via a router/modem1026and a wired or wireless connection. In the alternative, or in addition, the apparatus1000may include a transceiver1018connected to an antenna1029, through which the apparatus1000may communicate wirelessly with a base station for a wireless communication system or with the router/modem1026. In the alternative, the apparatus1000may communicate with a video streaming system900via a local area network, virtual private network, or other network. In another alternative, the apparatus1000may be incorporated as a module or component of the system900and communicate with other components via the bus1014or by some other modality.

One or more input devices1030(e.g., an alphanumeric keyboard, microphone, keypad, remote controller, game controller, camera or camera array) may be connected to the bus1014via a user input port1022to communicate information and commands to the apparatus1000. In selected embodiments, an input device1030may provide or support control over the positioning of a cursor. Such a cursor control device, also called a pointing device, may be configured as a mouse, a trackball, a track pad, touch screen, cursor direction keys or other device for receiving or tracking physical movement and translating the movement into electrical signals indicating cursor movement. The cursor control device may be incorporated into the display unit1028, for example using a touch sensitive screen. A cursor control device may communicate direction information and command selections to the processor1002and control cursor movement on the display1028. A cursor control device may have two or more degrees of freedom, for example allowing the device to specify cursor positions in a plane or three-dimensional space.

Some embodiments may be implemented in a non-transitory computer-readable storage medium for use by or in connection with the instruction execution system, apparatus, system, or machine. The computer-readable storage medium contains instructions for controlling a computer system to perform a method described by some embodiments. The computer system may include one or more computing devices. The instructions, when executed by one or more computer processors, may be configured to perform that which is described in some embodiments.