In adaptive streaming, it is desirable to control what content a streaming client needs to play out, for how long, and for how often. This is important especially for streaming advertisement-supported content. In content streaming, there are situations where content is streamed without allowing skipping or bypassing of content. One example is when a user watches advertisement-supported content with ad content that needs to be streamed in its entirety or a specified portion (e.g., an initial 5 seconds at least) prior to the streaming and display of the main or desired media content. In this advertisement supported scenario, for example, an ad may be inserted at the start (pre-roll), in the middle (mid-roll), and/or towards the end (post-roll) of the main media content, and watching or skipping the ad may help determine whether the user is allowed to watch the associated media content, and/or which (low or high quality) version of it.
Another example includes mandatory training materials streamed online or through an information delivery service where it is desirable to ensure that the user actually views the content and receives the information contained within the streaming content, either as evidence that suggests the information is actually delivered or that the streaming service is actually provided to the user. This kind of streaming content can be content accompanied with other content.
Many existing approaches for dealing with these issues are largely client-managed. That is, these approaches are dependent on passing the controlling information to the client and letting the client behave accordingly. For instance, in order to have a forced play-out of a piece of content, playing a segment can be made dependent on processing or play-out of its preceding segment. A way to accomplish this is to prepare a chain of encrypted content segments, each of which hides a decryption key for its next segment, and thus for the client to play a segment, the client is required to process its preceding segment and is consequently “forced” to play out all the segments in a sequential order. Unfortunately, these solutions are often ineffective, largely because the client may not be trustworthy itself, or it may operate within a hostile environment.
In addition, there are a number of other efficacy issues with these client-managed approaches to controlling client behaviors. In addition to the assumption that the client is trustworthy and compliant with viewing protocols, which may not be the case in practice when the client (and by extension a user) has access to all the segments to manipulate, the client also needs to become more complex when being able to discover and process the controlling information, and it is rather difficult to define all kinds of controlling information in a standard manner.
Dynamic Adaptive Streaming over HTTP (DASH) is a popular adaptive bitrate streaming technique for high quality streaming of multimedia content over the Internet delivered from conventional HTTP web servers. DASH streaming typically partitions media content into a sequence of small file segments, each segment containing a portion of the media content in a short interval of playback time. Typically, the content is made available with a media presentation description (MPD) file, which describes segment information (such as timing, URL, media characteristics such as video resolution and bit rates). One or more representations (i.e., versions of the same segments at different resolutions, bit rates, or other factors) of the media content are typically available, and a selection can be made (typically automatically) based on network conditions, device capabilities and user preferences, enabling adaptive streaming and Quality of Experience (QOE) restrictions. For example, generally when content is played by a DASH client, the client automatically selects from the available segments the next segment to download with the highest bit rate possible that can be downloaded in time for play back without causing pauses or rebuffering events in the playback.
However, DASH streaming presents additional problems to client-managed adaptive streaming. For example, since DASH implementations may not mandate client behavior, there may be no guarantee in presenting a coherent user experience of a same piece of streaming content across devices with different DASH client implementations. This may be undesirable, especially from content owner's perspectives. Additionally, it may be difficult to regulate adaptation logic of the client in a dynamic manner, for instance, according to how a service provider wants the content being streamed to different classes of subscribers. Moreover, as dynamic adaptation is also managed by the client, the content information at all levels including potential periods, adaptation sets, representations and segments has to be prescribed in an MPD and communicated to the client prior to the time the client starts streaming. This issue becomes significant and even un-resolvable when it comes to streaming dynamic events: e.g., emergency alerts; dynamic content: e.g., live advertisement insertion; irregularly updated content: e.g., a basketball game with irregular time-outs; and/or large, or even unlimited, number of potential representations among which adaptation can happen dynamically.