EMBEDDING DATA IN MEDIA METADATA TRACKS DURING PLAYBACK

Abstract

Data is embedded onto new or existing media metadata tracks during playback of a media stream. A content server provides a media stream to a mobile device. Data associated with the playback of the media stream on the mobile device is obtained by the content server and saved to the media stream itself. Data may include playback statistics, viewing characteristics, channel changes, comment logs, etc. The information can be stored in a time-correlated manner to allow extraction and analysis of data.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

The present invention claims priority to co-pending provisional U.S. patent application No. 61/049,739, filed May 1, 2008, which is incorporated herein by reference in its entirety.

TECHNICAL FIELD

The present disclosure relates to embedding data in media metadata tracks during playback.

DESCRIPTION OF RELATED ART

A variety of conventional mechanisms obtain data and statistics associated with the playback of media streams. In many instances, the information is logged to allow later retrieval and analysis of statistics. The statistics may include viewing characteristics, network performance information, user settings, etc.

However, conventional mechanisms for maintaining information associated with the playback of media streams are limited. Consequently, it is desirable to provide improved techniques and mechanisms for maintaining information associated with the playback of media streams.

BRIEF DESCRIPTION OF THE DRAWINGS

The disclosure may best be understood by reference to the following description taken in conjunction with the accompanying drawings, which illustrate particular embodiments.

FIG. 1 illustrates an exemplary system for use with embodiments of the present invention.

FIG. 2 illustrates one example of a Real-Time Transport Protocol (RTP) packet.

FIG. 3 illustrates one example of an RTP stream.

FIG. 4 illustrates one example of modification of an RTP stream including removal and insertion of packets.

FIG. 5 illustrates one example of embedding data in a media stream.

FIG. 6 illustrates an example of modifying a media stream based on data embedded in a track.

FIG. 7 illustrates one example of a content server.

DESCRIPTION OF EXAMPLE EMBODIMENTS

Reference will now be made in detail to some specific examples of the invention including the best modes contemplated by the inventors for carrying out the invention. Examples of these specific embodiments are illustrated in the accompanying drawings. While the invention is described in conjunction with these specific embodiments, it will be understood that it is not intended to limit the invention to the described embodiments. On the contrary, it is intended to cover alternatives, modifications, and equivalents as may be included within the spirit and scope of the invention as defined by the appended claims.

For example, the techniques of the present invention will be described in the context of particular networks and devices. However, it should be noted that the techniques of the present invention apply to a variety of networks and devices. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. Particular example embodiments of the present invention may be implemented without some or all of these specific details. In other instances, well known process operations have not been described in detail in order not to unnecessarily obscure the present invention.

Various techniques and mechanisms of the present invention will sometimes be described in singular form for clarity. However, it should be noted that some embodiments include multiple iterations of a technique or multiple instantiations of a mechanism unless noted otherwise. For example, a system uses a processor in a variety of contexts. However, it will be appreciated that a system can use multiple processors can while remaining within the scope of the present invention unless otherwise noted. Furthermore, the techniques and mechanisms of the present invention will sometimes describe a connection between two entities. It should be noted that a connection between two entities does not necessarily mean a direct, unimpeded connection, as a variety of other entities may reside between the two entities. For example, a processor may be connected to memory, but it will be appreciated that a variety of bridges and controllers may reside between the processor and memory. Consequently, a connection does not necessarily mean a direct, unimpeded connection unless otherwise noted.

Overview

Data is embedded onto new or existing media metadata tracks during playback of a media stream. A content server provides a media stream to a mobile device. Data associated with the playback of the media stream on the mobile device is obtained by the content server and saved to the media stream itself. Data may include playback statistics, viewing characteristics, channel changes, comment logs, etc. The information can be stored in a time-correlated manner to allow extraction and analysis of data.

Example Embodiments

In many systems, a content server provides a media stream to a mobile device. Numerous mobile devices playing the media stream generates a large amount of data that can be transmitted back to the content server. In many instances, the content server collects user characteristics such as channel changes, offers selected, volume light/dark controls, etc., as well as network characteristics such as packet loss, throughput, retransmission, etc. As media streams are played by multiple users in different environments, the amount of data becomes substantial and potentially unwieldy for analysis, particularly real-time playback analysis.

Streaming servers typically use logging to maintain data associated with media stream playback on devices such as mobile phones. Some network devices also log network performance metrics to track packet loss, throughput, retransmission rates, etc. However, no existing systems allow efficient storage and management of data associated with media stream playback.

The media streams that are delivered usually include at least an audio track and a video track, but the media streams may include additional tracks. For example, media streams may also include captions, subtitles, and real-time metadata describing activity relating directly to the content presented on the other tracks.

According to various embodiments, a content server or other network device records data to a new or existing track in a media stream in real-time or near real-time as the media stream is being played by one or more users. According to various embodiments, the data includes channel changes, configuration selections, volume and screen brightness changes, option selections, chat logs, packet drops, throughput, retransmission rate, etc. Location, temperature, battery condition, network performance, local-time, and/or anything else happening on the device itself may be reported to a content server or other network device and embedded onto a media stream in a track. The data may be recorded in a time-correlated manner on the media stream. For example, indications that many users adjusted the volume when a particular program ends may be recorded in the track corresponding to the point in the media stream where the program ends.

According to various embodiments, a particularly high number of channel changes may be recorded at the point where a commercial begins. In other embodiments, a large number of packet drops may be recorded at the beginning of a program sequence. In particular embodiments, network transmission rates and commercial selection can be modified during playback to account for user feedback. The modifications can be made during particular points of media stream play back based on the data embedded in the media track.

According to various embodiments, as media is played, available metadata is analyzed to allow a content server to dynamically modify the media stream provided to a mobile device. Commercials identified by a data track as unappealing by particular demographic groups are replaced with alternate commercials.

In particular embodiments, more appropriate advertising can be provided based on real-time feedback. Programs and commercials can be better produced/validated/verified. According to various embodiments, parameters collected from a media playback experience can be tightly bound to the media stream itself. Instead of using separate systems to deliver data and generate logs and summaries, collected data can be correlated directly to media being played. According to various embodiments, data derived from a variety of sources can be embedded in new or existing tracks within the media stream itself. In particular embodiments, the recording and retrieval of the data happens in real-time or near real-time on every playback of a particular media stream so that data can be used to adjust current playback parameters of the media as it is played a subsequent time.

In a particular example, if a particular network condition was observed in the last playback of a media segment that indicated packet loss, packetization of the media segment can be adjusted to prevent future packet loss. In yet another example, contents of a chat server are correlated with events in a media stream. Ratings buttons or other question and answer responses are elicited. The chat session and questionnaire statistics can be stored with the media stream and used later for search, replay, archival or other ratings and analysis purposes. By placing data associated with playback in the media stream itself, cumbersome correlation of events across different streams can be reduced. The embedded data can be continuously modified and/or expanded as needed. In some examples, playback options such as charts and graphs can be dynamically generated during playback.

FIG. 1 is a diagrammatic representation illustrating one example of a system that can use the techniques and mechanisms of the present invention. According to various embodiments, content servers 119, 121, 123, and 125 are configured to provide media content to a mobile device 101 using protocols such as RTP and RTCP. Although a mobile device 101 is shown, it should be recognized that other devices such as set top boxes and computer systems can also be used. In particular examples, the content servers 119, 121, 123, and 125 can themselves establish sessions with mobile devices and stream video and audio content to mobile devices.

According to various embodiments, the content servers 119, 121, 123, and 125 have access to a campaign server 143. The campaign server 143 provides profile information for various mobile devices 101. In some examples, the campaign server 143 is itself a content server or a controller. The campaign server 143 can receive information from external sources about devices such as mobile device 101. The information can be profile information associated with various users of the mobile device including interests and background. The campaign server 143 can also monitor the activity of various devices to gather information about the devices. The content servers 119, 121, 123, and 125 can obtain information about the various devices from the campaign server 143. In particular examples, a content server 125 uses the campaign server 143 to determine the types of media clips a user on a mobile device 101 would be interested in viewing.

According to various embodiments, the content servers 119, 121, 123, and 125 are receiving media streams from content providers such as satellite providers or cable providers, manipulating the streams, and sending the streams to devices using RTP 131. In particular examples, content servers 119, 121, 123, and 125 access database 141 to obtain desired content that can be used to supplement streams from satellite and cable providers. According to various embodiments, the content servers also read, write, and analyze track data in real-time or near real-time as media content is being streamed. In one example, a mobile device 101 requests a particular stream. A controller 107 establishes a session with the mobile device 101 using RTSP 133 and the content server 125 begins streaming the content to the mobile device 101 using RTP 131. Another controller 105 connected to a load balancer may also be used. In particular examples, the content server 125 obtains profile information from campaign server 143.

In some examples, the content server 125 can also obtain profile information from other sources, such as from the mobile device 101 itself. Using the profile information, the content server can select a clip from a database 141 to provide to a user. In some instances, the clip is injected into a live stream without affecting mobile device application performance. In other instances, the live stream itself is replaced with another live stream. The content server handles processing to make the transition between streams and clips seamless from the point of view of a mobile device application. In still other examples, advertisements from a database 141 can be intelligently selected from the database 141 using profile information from a campaign server 143 and used to seamlessly replace default advertisements in a live stream. Content servers 119, 121, 123, and 125 have the capability to manipulate RTP packets to allow introduction and removal of media content.

According to various embodiments, the content server 125 continually obtains information from a variety of sources. In particular embodiments, the content server 125 obtains statistical information from mobile device 101 including time duration, channel switching events and frequency, screen brightness, volume settings, commercial interest levels, etc. The content server 125 may also obtain network statistics such as packet transmission rates, throughput, latency, etc. According to various embodiments, the content server 125 can store this information in a database. However, the techniques of the present invention recognize that much of this information is time dependent. For example, it may be useful to store information about how many channel changes occur when programming changes or a particular commercial is shown. The techniques and mechanisms of the present invention allow storage of this information in an efficient and easily accessible manner. In particular embodiments, time dependent information can be embedded in a media stream in an existing track or a new track. According to various embodiments, an RTP stream is modified to include statistical information aggregated from numerous sources, such as the average number of users in a particular market viewing a program or the average packet transmission rates for a specific sequence. In particular embodiments, the data is stored in a time-correlated manner. For example, the number of channel changes occurring when a commercial begins can be recorded in the media track at the location when the commercial begins.

The content server records the information in real time or near real-time to allow extraction of the information during analysis or subsequent playback. In particular embodiments, the content server may determine that packet drop rates at a particular point in a stream are too high and the content server may switch to a lower transmission rate stream. In another example, the content server may determine that a large percentage of viewers change channels when a particular commercial is played and may insert an alternative commercial. According to various embodiments, RTP streams and packets may be manipulated based on information embedded in media tracks.

FIG. 2 illustrates one example of an RTP packet. An RTP packet 201 includes a header 211. According to various embodiments, the header 211 includes information such as the version number, amount of padding, protocol extensions, application level, payload format, etc. The RTP packet 201 also includes a sequence number 213. Client applications receiving RTP packets expect that the sequence numbers for received packets be unique. If different packets have the same sequence number, erroneous operation can occur. RTP packets also have a timestamp 215 that allows jitter and synchronization calculations. Fields 217 and 219 identify the synchronization source and the contributing source. Extensions are provided in field 221. Data is provided at 223.

According to various embodiments, data 231 holds actual media data such as MPEG frames. In some examples, a single RTP packet 201 holds a single MPEG frame. In many instances, many RTP packets are required to hold a single MPEG frame. In instances where multiple RTP packets are required for a single MPEG frame, the sequence numbers change across RTP packets while the timestamp 215 remains the same across the different RTP packets. Different MPEG frames include I-frames, P-frames, and B-frames. I-frames are intraframes coded completely by itself. P-frames are predicted frames which require information from a previous I-frame or P-frame. B-frames are bi-directionally predicted frames that require information from surrounding I-frames and P-frames.

Because different MPEG frames require different numbers of RTP packets for transmission, two different streams of the same time duration may require different numbers of RTP packets for transmission. Simply replacing a clip with another clip would not work, as the clips may have different numbers of RTP packets and having different impacts on the sequence numbers of subsequent packets.

According to various embodiments, each track of metadata can be represented in a stream of RTP packets for transport/recording and playback within a subsequent RTSP session. As background, the client player negotiates which RTP tracks to set up during negotiation of an RTSP session with a RTSP/RTP server. In particular embodiments, the client player has the ability to synchronize and use tracks it is requesting. It should be recognized that a variety of mechanisms can be used to packetize media in their native track formats into RTP, and many ways to record new metadata back into a file are contemplated. It should be noted that a new metadata track can be added to the disk content as new streams of RTP packets are synchronized to the audio and video RTP packet streams. Recording metadata tracks can occur on a client recording during playback or on the server during delivery, or in combination.

FIG. 3 illustrates one example of an RTP packet stream that may be used with the techniques of the present invention. An RTP packet stream 301 includes individual packets having a variety of fields and payload data. According to various embodiments, the fields include a timestamp 303, sequence 305, marker 307, etc. The packets also include payload data 309 holding MPEG frames such as I, P, and B-frames. Timestamps for different packets may be the same. In particular examples, several packets carrying portions of the same I-frame have the same time stamp. However, sequence numbers are different for each packet. Marker bits 307 can be used for different purposes, such as signaling the starting point of an advertisement.

According to various embodiments, packets with sequence numbers 4303, 4304, and 4305 carrying potions of the same I-frame and have the same timestamp of 6. Packets with sequence numbers 4306, 4307, 4308, and 4309 carry P, B, P, and P-frames and have timestamps of 7, 8, 9, and 10 respectively. Packets with sequence numbers 4310 and 4311 carry different portions of the same I-frame and both have the same timestamp of 11. Packets with sequence numbers 4312, 4313, 4314, 4315, and 4316 carry P, P, B, P, and B-frames respectively and have timestamps 12, 13, 14, 15, and 16. It should be noted that the timestamps shown in FIG. 3 are merely representational. Actual timestamps can be computed using a variety of mechanisms.

For many audio encodings, the timestamp is incremented by the packetization interval multiplied by the sampling rate. For example, for audio packets having 20 ms of audio sampled at 8,000 Hz, the timestamp for each block of audio increases by 160. The actual sampling rate may also differ slightly from this nominal rate. For many video encodings, the timestamps generated depend on whether the application can determine the frame number. If the application can determine the frame number, the timestamp is governed by the nominal frame rate. Thus, for a 30 f/s video, timestamps would increase by 3,000 for each frame. If a frame is transmitted as several RTP packets, these packets would all bear the same timestamp. If the frame number cannot be determined or if frames are sampled a periodically, as is typically the case for software codecs, the timestamp may be computed from the system clock

While the timestamp is used by a receiver to place the incoming media data in the correct timing order and provide playout delay compensation, the sequence numbers are used to detect loss. Sequence numbers increase by one for each RTP packet transmitted, timestamps increase by the time “covered” by a packet. For video formats where a video frame is split across several RTP packets, several packets may have the same timestamp. For example, packets with sequence numbers 4317 and 4318 have the same timestamp 17 and carry portions of the same I-frame.

FIG. 4 illustrates one example of RTP packet stream modification. An RTP packet stream 401 includes individual packets having a variety of fields and payload data. According to various embodiments, the fields include a timestamp 403, sequence 405, marker 407, etc. The packets also include payload data 409 holding MPEG frames such as I, P, and B-frames. Timestamps for different packets may be the same. In particular examples, several packets carrying portions of the same I-frame have the same time stamp. However, sequence numbers are different for each packet. Marker bits 407 can be used for different purposes, such as signaling the starting point of an advertisement. According to various embodiments, metadata searches allow the introduction of targeted advertising that can be inserted seamlessly into an RTP stream.

According to various embodiments, packets with sequence numbers 4303, 4304, and 4305 carrying potions of the same I-frame and have the same timestamp of 6. Packets with sequence numbers 4306, 4307, 4308, and 4309 carry P, B, P, and P-frames and have timestamps of 7, 8, 9, and 10 respectively. According to various embodiments, a content server removes multiple packets from an RTP packet stream 401, including packets with sequence numbers 4310 through 4316. The packets with sequence numbers 4310 and 4311 carry different portions of the same I-frame and both have the same timestamp of 11.

Packets with sequence numbers 4312, 4313, 4314, 4315, 4316 carry P, P, B, P, and B-frames respectively and have timestamps 12, 13, 14, 15, and 16. The spliced stream now ends at packet with sequence number 4309 carrying a P-frame. A B-frame is included in packet having sequence number 4307. It should be noted that B-frames sometimes may depend on information included in a subsequent I-frame which has been removed. Although having a few B-frames lacking reference frames is not extremely disruptive, it can sometimes be noticed. Therefore, the techniques of the present invention recognize that in some embodiments, the last packets left in a stream prior to splicing should be an I-frame or a P-frame.

According to various embodiments, now that a portion of the RTP stream has been removed, an RTP sequence 411 can be inserted. In particular examples, the RTP sequence inserted 411 begins with an I-frame for subsequent P and B-frames to reference. Without an I-frame for reference, an RTP sequence inserted may begin with a partial or incomplete picture. The packets for insertion are modified to have sequence numbers following the last sequence number of spliced packet stream 401. RTP insertion sequence 411 has sequence numbers 4310 -4317 corresponding to packets carrying I, I, I, B, P, P, B, B, frames respectively, with the I-frame carried in three packets with the same time stamp of 11 and the B, P, P, B, an B-frames having timestamps of 12-16 respectively.

For example, packets with sequence numbers 4317 and 4318 have the same timestamp 17 and carry portions of the same I-frame. In some instances, the number of packets in the RTP sequence removed 421 will be exactly the same as the number of packets in the RTP sequence for insertion 411. However, in many instances, the number of packets removed and inserted will differ. For example, some frames may require more than one packet for transmission. Although timestamps can be configured to be the same, so that a 5 second clip can be replaced with another 5 second clip, the number of packets and consequently the sequence numbers can be thrown askew. According to various embodiments, packet with sequence number 4309 is referred to herein as a data stream end point packet. Packet with sequence number 4318 is referred to herein as a data stream restart point packet. Packets with sequence numbers 4310 and 4316 in removed sequence are referred to herein as the removed sequence start packet and the removed sequence end packet respectively. Packets with sequence numbers 4310 and 4316 in the insertion sequence are referred to herein as the insertion sequence start packet and the insertion sequence end packet respectively.

Consequently, the content server maintains a current sequence number per RTP data stream and modified subsequent packets after removing and inserting streams. For example, packets having timestamp 17 are modified to have sequence numbers 4318 and 4319 instead of 4317 and 4318. The content server then proceeds to update subsequent timestamps in the RTP data stream. According to various embodiments, this operation is uniquely performed at a content server because the content server has information about individual mobile devices and also is able to know information about the sequence numbers of an entire content stream. A content provider may not know information about individual mobile devices, whereas a network device or network switch may not receive all data packets in a sequence. Some packets may have been dropped while others may have been transmitted on different paths.

FIG. 5 is a process flow diagram showing one technique for embedding data in media tracks. At 501, metadata content for a media stream is extracted and analyzed. At 503, the data is obtained from client devices. The data may include user device configurations, user events, channel changes, notes, volume and brightness settings, client player information, client feedback, etc. At 505, network data is obtained from network devices. Network data may also be obtained from client devices as well. Network data my include transmission rates, packet drop rates, throughput, etc. At 509, data is aggregated from client and network devices. In particular embodiments, data may also be received from other sources, such as chat servers with information corresponding to particular programming. Data is aggregated and written in a time-correlated manner to a new or existing track in the media stream at 511. The data may be written in real-time or near real-time. At 513, the media stream is stored. In some examples, media stream may continually have new data written as track information. In particular instances, it may be useful to prune some of this data to allow efficient retrieval and access during subsequent playback and analysis.

FIG. 6 is a process flow diagram showing a technique for modifying a media stream based on information embedded in a track. At 601, metadata content for a particular media stream is analyzed. According to various embodiments, analysis is done for only metadata content for an immediate time period such as 10 minutes of a most recently presented stream. At 603, a media stream is modified based on metadata content. In particular embodiments, advertisements corresponding to search patterns, tags, strings, and sequences may be selected and inserted into the media stream based on user data and network data included in the media stream. For example, if user data indicates that a large percentage of users changed channels when a particular advertisement was shown, an alternative advertisement may be selected. In particular embodiments, user data for a particular demographic or geographic group may indicate that an alternative advertisement should be selected. At 605, alternative advertising is selected. At 607, media stream with different transmission rates may be selected. According to various embodiments, network data may indicate that a particular sequence in a media stream causes a large number of packet drops. A lower bit rate stream may be selected for transmission to user devices in a seamless and efficient manner. At 609, the media stream is provided for subsequent playback.

FIG. 7 illustrates one example of a content server that can perform live stream modification. According to particular embodiments, a system 700 suitable for implementing particular embodiments of the present invention includes a processor 701, a memory 703, an interface 711, and a bus 715 (e.g., a PCI bus or other interconnection fabric) and operates as a streaming server. When acting under the control of appropriate software or firmware, the processor 701 is responsible for modifying and transmitting live media data to a client. Various specially configured devices can also be used in place of a processor 701 or in addition to processor 701. The interface 711 is typically configured to end and receive data packets or data segments over a network.

Particular examples of interfaces supports include Ethernet interfaces, frame relay interfaces, cable interfaces, DSL interfaces, token ring interfaces, and the like. In addition, various very high-speed interfaces may be provided such as fast Ethernet interfaces, Gigabit Ethernet interfaces, ATM interfaces, HSSI interfaces, POS interfaces, FDDI interfaces and the like. Generally, these interfaces may include ports appropriate for communication with the appropriate media. In some cases, they may also include an independent processor and, in some instances, volatile RAM. The independent processors may control such communications intensive tasks as packet switching, media control and management.

According to various embodiments, the system 700 is a content server that also includes a transceiver, streaming buffers, an program guide information. The content server may also be associated with subscription management, logging and report generation, and monitoring capabilities. In particular embodiments, functionality for allowing operation with mobile devices such as cellular phones operating in a particular cellular network and providing subscription management. According to various embodiments, an authentication module verifies the identity of devices including mobile devices. A logging and report generation module tracks mobile device requests and associated responses. A monitor system allows an administrator to view usage patterns and system availability. According to various embodiments, the content server 791 handles requests and responses for media content related transactions while a separate streaming server provides the actual media streams.

Although a particular content server 791 is described, it should be recognized that a variety of alternative configurations are possible. For example, some modules such as a report and logging module 753 and a monitor 751 may not be needed on every server. Alternatively, the modules may be implemented on another device connected to the server. In another example, the server 791 may not include an interface to an abstract buy engine and may in fact include the abstract buy engine itself. A variety of configurations are possible.

In the foregoing specification, the invention has been described with reference to specific embodiments. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the invention as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of invention.

Claims

1. A method, comprising:

receiving a media stream, the media stream including a video track and an audio track;

transmitting the media stream to a plurality of user devices over a network including a plurality of network devices;

receiving user data from the plurality of user devices;

embedding the user data in a time-correlated manner in a track associated with the media stream;

storing the media stream for subsequent playback.

2. The method of claim 1, wherein user data comprises channel changes and device settings.

3. The method of claim 2, wherein the user data is embedded in a new track in the media stream.

4. The method of claim 1, further comprising receiving network data from the plurality of network devices.

5. The method of claim 4, wherein network data comprises transmissions rates.

6. The method of claim 5, wherein the network data is embedded in a new track in the media stream.

7. The method of claim 1, further comprising receiving network data from the plurality of network devices.

8. The method of claim 1, wherein the user data indicates the percentages of user devices switching channels when a particular portion of the media stream is played.

9. The method of claim 1, wherein user data comprises commercial feedback and user ratings.

10. A system, comprising:

means for receiving a media stream, the media stream including a video track and an audio track;

means for transmitting the media stream to a plurality of user devices over a network including a plurality of network devices;

means for receiving user data from the plurality of user devices;

means for embedding the user data in a time-correlated manner in a track associated with the media stream;

means for storing the media stream for subsequent playback.

11. The system of claim 10, wherein user data comprises channel changes and device settings.

12. The system of claim 11, wherein the user data is embedded in a new track in the media stream.

13. The system of claim 10, further comprising means for receiving network data from the plurality of network devices.

14. The system of claim 13, wherein network data comprises transmissions rates.

15. The system of claim 14, wherein the network data is embedded in a new track in the media stream.

16. The system of claim 10, further comprising means for receiving network data from the plurality of network devices.

17. The system of claim 10, wherein the user data indicates the percentages of user devices switching channels when a particular portion of the media stream is played.

18. The system of claim 10, wherein user data comprises commercial feedback and user ratings.

19. A computer readable medium having computer code embodied therein, the computer readable medium comprising:

computer code for receiving a media stream, the media stream including a video track and an audio track;

computer code for transmitting the media stream to a plurality of user devices over a network including a plurality of network devices;

computer code for receiving user data from the plurality of user devices;

computer code for embedding the user data in a time-correlated manner in a track associated with the media stream;

computer code for storing the media stream for subsequent playback.

20. The computer readable medium of claim 19, wherein user data comprises channel changes and device settings.