V001_MPEG-DASH_Video_FINAL-mobile Male Voice: So, DASH is about two things. First thing is feature richness; second is openness. Feature richness comes from the fact that it's a revolutionary technology, and it builds upon the experiences from that previous proprietary [unintelligible 00:00:33] systems. And openness comes from the fact that it is an open standard. It relies on open standards. It's compatible with the current, existing infrastructure. And, lastly, it imposes a minimal amount of restrictions. For instance, it's agnostic to things like DRMs and codecs. So, streaming interpretability is about [inaudible 00:01:03] and about the stability. What you used to do is, you used to integrate for a specific deployment between several vendors or clients and several vendors or DRMs and so on. Now, what you can do is define an interpretability point, which is, essentially, a contract between a client/vendor and [accounting 00:01:28] publisher. They both are going to implement and to use a very well-defined, specific set of features. And what we did in DASH Industry Forum is, we published implementation guidelines and a list of such interpretability points. And we're [back at top 00:01:48] by having test content and verification. Feature richness and freedom - freedom, in terms of freedom from vendor locking - it's an open standard. It's developed through a transparent international process, and if you compare it to existing proprietary systems, it's the difference between a [rule by decree 00:02:23] of an enlightened monarch and a representative of democracy. There is by the industry and for the industry. So, this actually allows an operator to mix and match vendors of his choice without being locked in. If you look back two years ago, it was about [rising promise 00:02:53]. A year ago, it was about early adoption and venture endorsement. Now it's about deployments, and now is the time to deploy it. To recognize the promise of DASH at the stage when it was only a promise - and since then, we contributed to the standard development. A major contributor is an MPEG. On the more practical side, we are very active in DASH Industry Forum, and our user-adaptive video client also relies on MPEG-DASH. So, second edition was driven by early implementation experiences. So, firstly, it corrects errors and clarifies some of the ambiguities of the specification. And secondly, it brings a set of newer features that were mainly driven by 24/7 linear programming and by dynamic ad insertion. The most visible of these features is DASH events, which are essentially time clocks. They can be used for two different purposes. One is notifying a client of asynchronous events - for instance, that it needs to update. And second, conveying messages to the client - application-specific messages, such as information on upcoming ad breaks. So, there are two ways to implement DASH ad insertion. One is something that relies only on native tools, and we call it server-driven. All the ad server interaction is done only at the server side, and generic DASH tools, such as Periods and XLink - and some of the DASH events can be used to make this possible. Another architecture is app-driven. This is very similar to what we used to have in cable and IPTV systems. And you use DASH as a transport for [Q 00:05:12] messages, and you have advertisement client that interprets the messages, and communicates with the actual ad server. The same benefit as a general interpretability - so in order to make interpretable ad insertion possible, in DASH Industry Forum, we're working on guidelines for interpretable ad insertion on interpretability points and on test vectors for these. And we are going to publish a document this summer, and it will be backed by test content.