US20120054045A1

US20120054045A1 - Managing Media Playback

Info

Publication number: US20120054045A1
Application number: US13/018,285
Authority: US
Inventors: Jeffrey Martin Beining; James Kong Hsu; Christopher Peter Xiques
Original assignee: CBS Interactive Inc
Current assignee: CBS Interactive Inc
Priority date: 2010-08-26
Filing date: 2011-01-31
Publication date: 2012-03-01
Also published as: US9009733B2; WO2012027606A2; WO2012027606A3; US20120054777A1

Abstract

Technology for managing playback of streaming media and ads associated therewith, is disclosed. Receiving a list indicating the location of ad pods in the stream and, optionally, indicating a list update time. Receiving instruction to play the stream forward from a seek point. Determining unplayed stream ads associated with locations from the list between the start and the seek point. Playing at least one determined ad. Optionally, playing at least one determined ad only upon determining that the list update time is greater than or equal to the seek point, otherwise, denying the seek point. Optionally after playing at least one determined ad, playing the stream from the seek point after playing the at least one determined ads. The list can be a list of cue points. Playing at least one determined ad can include playing the ad pod at the start of the stream section containing the seek point.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Patent Application No. 62/377,210, filed Aug. 26, 2010, referred to herein as the “Provisional Application,” the disclosure of which is incorporated herein by reference in its entirety.

FIELD

The technology disclosed herein (the “technology”) relates to streaming media. Implementations of the technology have application to manage ad playback in time shifted playback of live streaming media.

BRIEF DESCRIPTION OF THE DRAWINGS

Reference will now be made, by way of example, to the accompanying drawings which show example implementations of the technology.

FIG. 1 illustrates a streaming architecture.

FIG. 2 illustrates a streaming architecture of the present technology.

FIG. 3 illustrates a timing chart of the streaming architecture of FIG. 1 and FIG. 2.

FIG. 4 illustrates methods of the present technology.

FIG. 5 illustrates a data processing architecture suitable for storing a computer program product of the present technology and for executing the program code of the computer program product.

DETAILED DESCRIPTION

Reference now will be made in detail to implementations of the technology. Each example is provided by way of explanation of the technology only, not as a limitation of the technology. It will be apparent to those skilled in the art that various modifications and variations can be made in the present technology without departing from the scope or spirit of the technology. For instance, features described as part of one implementation can be used on another implementation to yield a still further implementation. Thus, it is intended that the present technology cover such modifications and variations that come within the scope of the technology.
Streaming media can be multimedia that can be substantially continuously received by, and presented to, an end-user while being delivered by a streaming provider. “Streaming” refers to the delivery method of the medium rather than to the medium itself. The distinction is usually applied to media that are distributed over telecommunications networks, as most other delivery systems are either inherently streaming (e.g., radio, television) or inherently non-streaming (e.g., books, video cassettes, audio CDs). The verb ‘to stream’ is also derived from this term, meaning to deliver media in this manner. Internet television is a commonly streamed medium.
A media stream can be streamed either live or on demand. Live streams are generally provided by a means called true streaming. True streaming sends the information straight to the computer or device without saving the file to a hard disk at the media player. On demand streaming can be provided by a means called progressive streaming or progressive download. In progressive streaming, the media file may be saved in storage at the media player and then may be played from that location. On demand streams are often saved to hard disks and servers for extended amounts of time; while live streams are typically available at one time only (e.g. during a sporting event and for some period afterward).
Referring to FIG. 1, a live streaming architecture 100 is illustrated. Referring to FIG. 3, a timing diagram 300 based on relative time from the beginning of a stream is illustrated. Live streaming technology can involve a camera 110 for capturing content of a live event. The live event can be characterized as starting a t₀ 310 and scheduled to end at t _end 320. The current time (in relation to t₀) is shown as t _CAPTURE 330. The camera 110 can communicate captured content 112 to an encoder 120.
The encoder 120 can encode the captured content, creating encoded content 122. Cue points 124, 341-345, indicating the beginning of an ad pod (i.e., a contiguous group of one or more ads) can be inserted into the encoded content 122. The encoding process requires some amount of time, even if the camera 110 and the encoder 120 are combined into a single device with hardware-driven, e.g., application specific integrated circuits, solutions. Consequently, the most current encoded content 122 is at time t _ENCODED 340 <t_CAPTURE. The encoded content 122 can be sent to a publisher 130 via communications channels 160 e.g., the Internet.
The publisher 130 can perform archiving, and can make the encoded content available (i.e., published) in a variety of ways. For example, from a single stream of encoded content A122, a publisher 130 can offer an end user access to the stream at any point from t₀to t _PUBLISHED 350. Such access can be independently offered to a plurality of end users, e.g., one user accessing content from t₀at a time ten minutes after the event has started, another user accessing content from t₀+3 minutes, at a time twenty (20) minutes after the event has started. Access to the stream can be offered for a fixed period after the live event ends. Such access can be offered through a content delivery network (CDN). Though a CDN is not explicitly shown in FIG. 1 and FIG. 2, the CDN may be a separate entity or incorporated into the publisher 130. Since processes at the publisher 130 typically take some small amount of time, t_PUBLISHED<t_ENCODED. This can lead to some cue points, e.g., CP5 345, which are encoded, but not yet published.
Via communications channels 160, a user may access any point in the stream from t₀to t_PUBLISHED, for example t _ACCESS 360 in FIG. 3, using a player 140. For example, a player such as the user interface wrapper and core player described in the Provisional Application can be used. The player 140, using technology familiar to those of skill in the relevant art, can present ads at the cue points as the cue points are encountered during playback of the stream, e.g., CP2 and CP3 as shown in FIG. 3. Presenting ads can include: retrieving ads from an ad server, playing the ads, and then returning to the stream; playing ads embedded in the stream; and other methods known to those of skill in the relevant art. The player 140 also can track which ads have been played at which cue points, e.g., tracking that certain ads were played at CP2 and CP3 as shown in FIG. 3.
In its most prevalent form, “time shifting” is the recording of programming to a storage medium to be viewed or listened to at a time more convenient to the user. The advent of the digital video recorder (DVR) has made time shifting easier, by using an electronic program guide (EPG) and recording shows onto a hard disk. Some DVRs enable other time shifting methods, such as being able to start watching the recorded show from the beginning even if the recording is not yet complete. Time shifting may allow users to fast-forward through ads, and some technology allows users to remove ads entirely. This feature has been controversial, with content providers claiming it violates copyright and should be banned. Hard drive-based DVRs, set top boxes, and software-based DVRs designed for home television recording, time-shifting, and ad skipping are known.
The streaming architecture described above facilitates time shifting for live streamed events that are not necessarily recorded by the end user. In the example streaming architecture, the stream may be recorded by the publisher 130. As noted above, a user may access any point in the stream from t₀to t_PUBLISHEDusing a player 140. For example, for an event expected to be associated with thirty (30) minutes of ads, users accessing the stream from t₀at a time thirty (30) minutes into the event will be able to skip viewing the ads by using the player to seek to a point after the ad pod when the player encounters an ad pod. Note that a player 140 playing the stream from t_ACCESSto t_PLAYwill have encountered the cue points CP2 342 and CP3 343, skipped CP1 341 and not yet encountered published cue point CP4 344 and unpublished cue point CP5 345.
Implementations of the present technology enable a player 140 to enforce ad playback when a user seeks the player beyond an unplayed ad in a published stream of a time shifted event. While enabling implementations are described herein in the context of “live” time shifted streaming, the technology also has application to on demand streaming, and scenarios when ad positions beyond the last played ad are known.
Referring to FIG. 2, a live streaming architecture 200 similar to the architecture of FIG. 1 is illustrated. Referring to FIG. 4, a method 400 of the present technology is illustrated.
A live event can be captured by a camera 110 creating captured event data 112 that can be communicated to an encoder 120. The captured event data 112 can be encoded, and cue points can be added into the encoded stream at the appropriate times to signal the beginning of an ad pod. The encoded stream (with cue points) 122 can be communicated to a publisher 130. The publisher 130 can make the stream available to the player 140, and the player can join the broadcast at any point from t₀to t_PUBLISHED, e.g., t _ACCESS 360. Note that the player 140 will not be informed of cue points until it encounters a particular cue point in the published stream. Ads played by the player can be tracked 406.
In implementations of the present technology, a list of ad positions, e.g., as cue points 270, can be contemporaneously communicated to the player 140. For example, the player 140 can receive a list of cue points from t₀to t _ENCODED 402, e.g., upon joining the broadcast at t_ACCESS, or upon receiving a request from the user to seek to a different point in time in the stream. The list 270 can be communicated to the player 140 in a variety of fashions familiar to those of skill in the relevant art, including: Internet push technology; a publish/subscribe paradigm in which the player 140 subscribes to information published by the encoder 120, the publisher 130, or some other Internet host such as a server of a CDN; and polling by the player 140 upon initiation of access to the stream 134. FIG. 2 illustrates communication directly from the encoder 120, though the communication can be from an intermediate Internet host (not shown), or even the publisher 130 (though in that case, t_PUBLISHwill be the latest time for which a cue point can be identified). Throughout the time that the player 140 is joined to the stream, the list received by the player 140 can be kept current, e.g., as a cue point is inserted at the encoder, a revised list 270 can be communicated to the player 140. In some implementations, the cue point list includes an update time. The cue point list can be made available to the player 140 independent of the player's 140 progress through the stream.
The player 140 can receive input to seek to a point in the stream between time t₀and t _PUBLISHED 404. For example, the player 140 can receive instruction to seek to t _SEEK 370 after having played the stream from t₀to t_PLAY.
In those implementations of the technology including update time in the cue point list, the player 140 can determine if the seek point is to a time less than or equal to the cue point list update time 408. If the seek point is beyond the cue point list update time, then the player 140 can deny the seek point 410. For example, in FIG. 3, t_SEEK<t_{UPDATE CUE POINT LIST} 347, so the technology will not deny the seek point and will proceed.
In each implementation of the present technology, the player 140 can determine the unplayed ad pods having a cue time between t₀and the t _SEEK 412. For example, in FIG. 3, CP2, CP3, and CP4 indicate unplayed ad pods between t₀and t_SEEK.
The player 140 then can present at least one of the determined ads 414. In some embodiments, the ad pod at the beginning of the stream section containing t_sEEKis played. Ads can be presented by implementations of the technology using methods known to those of skill in the relevant art. For example: ads can be retrieved from an ad server and played; the player 140 can seek to cue points in the stream 134 to play ads embedded in the stream. In some implementations, the player disables controls, e.g., seek, mute, minimize, while playing the ads. In some embodiments, “seek forward” is disabled. After playing the determined ads, the player can resume playback from the seek point 416.
As another example of implementations of the technology, consider a live event that has a planned duration of one (1) hour began at 1:00 p.m. and has been running for thirty-two (32) minutes. The player, a player of the Provisional Application, can enter the stream at that point and seek backwards in time to the 2-minute mark. At this point the player can present the archived stream thirty (30) minutes before the “live” point. Ads are scheduled to be presented every ten (10) minutes during this live event. An XML file representing the cue point history can be pushed to the player at the time the player entered the stream. In this example, the XML file will contain information for three (3) cue points: the one that occurred at the 10 minute mark, the one that occurred at the 20 minute mark, and the one that occurred at the 30 minute mark. If the player continues to play the archived stream, then eight (8) minutes in the first ad break will be encountered. The player can receive a message from the player's Flash NetStream object that a cue point has been encountered. The player can check whether this cue point has previously been made known through the pushed XML file. If for some reason the player does not know about the cue point it can add the information about when the cue point occurred to the player's own list of cue point information.
At this point the player can send an event to notify the player skin that an ad(s) has started. The skin can then remove the progress bar user interface (UI) so that the user will not be able to fast forward and skip the ad(s). When all the ads to be shown at that ad break are finished, the player can mark in its list of cue point information that the ad has been played and it can send an event to the player skin alerting the skin that the scheduled ads have finished and the skin will reinstate the progress bar UI allowing the user once again to seek to different points in the archived stream.
In this scenario the player continues playing until the 27 minute mark in the archived stream. The player will now have played the ads that occurred at the 10 minute and 20 minutes marks of the archived stream. At this point the live event is now at the 57 minute mark. Cue points will have occurred in real time at the 40 and 50 minute mark. At each of these points in real time the cue point information can be updated and pushed to the skin and then into player. The user now decides to seek ahead 20 minutes in time. This should position the player at the 47 minute mark in the archived stream—ten (10) minutes behind the live point. However, because the player has an accurate list of the cue points that have occurred in the live stream, the player can determine which ads were scheduled at the 30 minute and 40 minute marks. The player can determine the cue point immediately preceding the requested time, in this case the cue point at the 40 minute mark, and confirm that the player has not played the ads at this point in the stream. The player can force the archived stream to seek to that position (or to a point just before that cue point). When the cue point is detected soon thereafter, the same chunk of code that was invoked earlier in the scenario can alert the skin that an ad is starting and the skin can disable the progress bar in the UI, so that the player plays the ad without responding to inputs to skip the ad. Once all the ads scheduled for the 40 minute mark in the stream have been played, the player will mark that these ads have been played and seek to the point in the archived stream (47 minutes) that the user initially requested.
After watching for another minute the user now attempts to seek backwards in time 10 minutes to minute 38:00 of the archived stream. Again the player can look at the cue point that occurred previous to this time, discover that the ads scheduled at that time (30 Minutes) have not been played and can seek to a point in the archived stream to play those ads. After the ads are played the player can seek to the originally requested time (the 38:00 mark).
Now the user attempts to seek back another ten (10) minutes in time (to the 28 minute mark). This time when the player examines the cue point previous to the requested time, it discovers that this set of ads has already been played and the requested seek is allowed. If the player continues to play another two (2) minutes, the cue point at the 30 minute mark will be encountered. Since these ads have been played, the skin application can, depending on the business rules of the skin, remove the progress bar UI and force the user to watch the ads again, or keep the progress bar UI available so that the user can skip these previously viewed ads or make an internal seek request to UVP to seek to the point in the stream just after this set of ads has completed.
The present technology can take the forms of hardware, software or both hardware and software elements. In some implementations, the technology is implemented in software, which includes but is not limited to firmware, resident software, microcode, a Field Programmable Gate Array (FPGA), graphics processing unit (GPU), or Application-Specific Integrated Circuit (ASIC), etc. In particular, for real-time or near real-time use, an FPGA or GPU implementation would be desirable.
Furthermore, portions of the present technology can take the form of a computer program product comprising program modules accessible from computer-usable or computer-readable medium storing program code for use by or in connection with one or more computers, processors, or instruction execution system. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The medium can be non-transitory (e.g., an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device)) or transitory (e.g., a propagation medium). Examples of a non-transitory computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk-read only memory (CD-ROM), compact diskread/write (CD-R/W) and DVD. Both processors and program code for implementing each as aspect of the technology can be centralized or distributed (or a combination thereof) as known to those skilled in the art.
Referring to FIG. 5, a data processing system (e.g., 500) suitable for storing a computer program product of the present technology and for executing the program code of the computer program product can include at least one processor (e.g., processor resources 512) coupled directly or indirectly to memory elements through a system bus (e.g., 518 comprising data bus 518 a, address bus 518 b, and control bus 518 c). The memory elements can include local memory (e.g., 516) employed during actual execution of the program code, bulk storage (e.g., 560), and cache memories (e.g., including cache memory as part of local memory or integrated into processor resources) that provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution. Input/output or I/O devices (including but not limited to keyboards 550, displays 530, pointing devices 520, etc.) can be coupled to the system either directly or through intervening I/O controllers (e.g., 514). Network adapters can also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters. Such systems can be centralized or distributed, e.g., in peer-to-peer and client/server configurations. In some implementations, the data processing system is implemented using one or both of FPGAs and ASICs.

Claims

1. A computer-implemented method for managing playback of a stream of streaming media; the stream having ads associated therewith, the stream characterized by a start at t₀; the method comprising:

receiving a list indicating the location of each of at least one ad pod in the stream;

receiving instruction to play the stream forward from a seek point;

determining unplayed stream ads associated with locations from the received list between t₀and the seek point; and

playing at least one determined ad.

2. The method of claim 1 further comprising:

playing the stream from the seek point after playing the at least one determined ad.

3. The method of claim 1 wherein:

the list is a list of cue points.

4. The method of claim 1 wherein:

playing at least one determined ad comprises playing the ad pod at the start of the stream section containing the seek point.

5. A computer-implemented method for managing playback of a stream of streaming media; the stream having ads associated therewith, the stream characterized by a start at t₀; the method comprising:

receiving a list indicating the location of each of at least one ad pod in the stream and indicating a list update time;

receiving instruction to play the stream forward from a seek point;

upon determining that the list update time is greater than or equal to the time of the seek point:

determining unplayed stream ads associated with locations from the received list between t₀and the seek point;

playing at least one determined ad; and

upon determining that the list update time is less than the time of the seek point:

denying the seek point.

6. The method of claim 5 further comprising:

after playing at least one determined ad, playing the stream from the seek point after playing the at least one determined ads.

7. The method of claim 5 wherein:

the list is a list of cue points.

8. The method of claim 5 wherein:

9. A computer program product for managing playback of a stream of streaming media; the stream having ads associated therewith, the stream characterized by a start at t₀, the computer program product comprising:

a non-transitory computer-readable medium encoded with instructions that when executed by processor resources:

receive a list indicating the location of each of at least one ad pod in the stream;

receive instruction to play the stream forward from a seek point;

determine unplayed stream ads associated with locations from the received list between t₀and the seek point; and

play at least one determined ad.

10. The computer program product of claim 9 further comprising:

play the stream from the seek point after playing the at least one determined ads.

11. The computer program product of claim 9 wherein:

the list is a list of cue points.

12. The computer program product of claim 9 wherein:

13. A computer program product for managing playback of a stream of streaming media; the stream having ads associated therewith, the stream characterized by a start at t₀, the computer program product comprising:

receive a list indicating the location of each of at least one ad pod in the stream and indicating a list update time;

receive instruction to play the stream forward from a seek point;

determine unplayed stream ads associated with locations from the received list between t₀and the seek point;

play at least one determined ad; and

deny the seek point.

14. The computer program product of claim 13 further comprising:

15. The computer program product of claim 13 wherein:

the list is a list of cue points.

16. The computer program product of claim 13 wherein:

17. A system for managing playback of a stream of streaming media; the stream having ads associated therewith, the stream characterized by a start at t₀, the system comprising:

processor resources;

a non-transitory computer-readable medium:

in communication with processor resources, and

encoded with instructions that when executed by a processor:

receive instruction to play the stream forward from a seek point;

play at least one determined ad.

18. The system of claim 17 further comprising:

19. The system of claim 17 wherein:

the list is a list of cue points.

20. The system of claim 17 wherein:

21. A system for managing playback of a stream of streaming media; the stream having ads associated therewith, the stream characterized by a start at t₀, the system comprising:

processor resources;

a non-transitory computer-readable medium:

in communication with processor resources, and

encoded with instructions that when executed by a processor:

receive instruction to play the stream forward from a seek point;

play at least one determined ad; and

deny the seek point.

22. The computer program product of claim 21 further comprising:

23. The computer program product of claim 21 wherein:

the list is a list of cue points.

24. The computer program product of claim 21 wherein: