 Okay, so all the talks today have focused on the internet as a collection of text, which is primarily what the internet used to be. It even has it embedded in its most base protocols. It's the hypertext transfer protocol, right? So this talk by Zeno from Jillian is going to be about video, specifically about the advancements that have been made in the last couple of years, I would say, because browsers have now far more capabilities. You can actually do native rendering of videos within browsers. You can put things on top of videos. You can work with videos in very interesting ways. Bandwidth has also made videos more accessible to the rest of the world. So today is going to be a story about Sublime Video, which is a product as well as a service that Jillian offers, and also talking about HTML5 video and the new capabilities there. One, two, three, yeah. Okay, hello everybody. My name is Zeno. I'm a front-end developer, and I work for a small company called Jillian that I co-founded three years ago. This is our team, and we are based in Switzerland. Today I'd like to talk to you about video and video players on the web, and specifically about HTML5 video. We happened to be there at the very beginning between 2009 and 2010, just before HTML5 video took off, and we have been working with this technology and followed its evolution very, very closely in the last three years. So I thought I would share some of the challenges that we faced, and why we made some of the decisions that we made. And so I will also use the story of our startup and of our product, Sublime Video, to give this talk. And at the end I will talk specifically about the latest announcement that we did. But first of all, a little bit of background about HTML5 video. This is the HTML5 video element, or a video tag, and it's the core of the HTML5 video specification, and it's been created basically to become the standard way of showing a video on the web without plugging. Just curious how many of you have already played around with the video tag? Yeah, I would say more than 50% of the audience, nice. So it looks pretty simple, but there is a question I would like you to think about, and you know the tag is called video, but is this a video or is it a player, or is it both? And you probably never thought about this, but I think it's pretty interesting to get the difference. So let me simplify the video element just a little bit. You shouldn't write it like that, but just for the sake of example, I removed one of the sources so you can write it as one line and show it along an image tag that you know very well. And you can definitely see the symmetry there, the image, video, and the source. And you know very well that the first image tag, you can directly download and render the image on screen directly and you will see it immediately. But if you load a page with the video tag below, you won't see anything. I mean, at best you are going to see a rectangle with the first still frame of the video, but you will not be able to watch the video. And that's because to watch a video, you need, what do you need? A player, yeah. It will get more complex than this. And fortunately, in the HTML5 video specification, there is a way to turn on and to display the default video player that is built into the browser. And you do that by adding the controls attribute. And so it will look like this in Chrome. So we have our player, it looks so simple, the video will play, it's awesome. In reality, you will see it's a little bit more complex than that. So yeah, this will, at least will allow us to watch the video. But you know, these default video players have been in browsers now for, I don't know, more than three years. And if you think about it, yeah, actually it was looking like this before in Chrome, maybe. But if you think about it, you don't see them very often, right? And the reality is that few people, few web publishers and a few designers are satisfied by that. And there are different reasons. I give you two. One is inconsistency. So every browser has a different default player built in. You know, designers don't like that. And another problem you have is that you have really basic playback functionalities. So you have a play post, a volume, and if you are lucky, a full screen button. But let's say you want to add, you know, an HD button to switch the source quality. Like you will probably see 99% of all the flash video players that you are used to see every day. Well, you cannot do that here. So if you remove the controls attribute, you are left with this simple video and a very important part, the HTML5 video API. And with that, you can actually build your own custom player on top of the video. And that is what we did. We started to play around with a video tag and the HTML5 video API around the end of 2009. And we were actually the first to show a demo page of a custom HTML5 video player. And, you know, we did this just as a side project. But we were pretty excited because it was the first time that we could build our own player exactly like we wanted without using Flash. It was simply not possible before. And in addition to that, we had something that was displaying consistently across all the browsers. And we could add this custom feature, for instance, that you could not add in the default bar, you know? And so we were pretty excited internally. But frankly, we didn't expect so many geeks and so many other people to be excited about these two. And in fact, we tweeted about that demo page in January 2010. And the thing went pretty viral. So we were completely unknown at that time. We had like 40 or 50 followers on Twitter. And then in like one week, we got over 3,500 followers up to 8,000, which is for a startup with Switzerland, you know, it's pretty big. And also the page after a couple of months got over one million unique visitors. So we clearly got a push from all those users to basically turn that demo page into a real product. And that's what we did. But at the beginning, we didn't know it would have been so complicated. So I will tell you about the challenges that we faced. Because in this process, we learned that HTML5 video, despite all its amazing awesome potentials, it's really something that is not as simple and works flawlessly as you would think. So the first problem is API bugs. The HTML5 video API has really a lot of bugs. And it's a mix of bugs and stuff that is missing because it's still not completely implemented everywhere. But the bugs are unbelievable. I mean, I don't think other specifications in HTML5 are so buggy. And I believe it's because video is maybe a little bit more complex because the API has to interface with lower level to do the video decoding and stuff. It's maybe complicated, but you won't believe even today there is no simple, no browser, even the latest Chrome or Firefox that has absolutely no bugs with this. And I won't bore you with the list, but I have many if you are interested. You can come by after the talk. And so these are being fixed progressively, a little bit slow, but they are being fixed. But the problem then is that you have mobile devices that stick around for some time and they are not updated like Android devices. And I mean, we have to provide a serious solution that plays video everywhere. We cannot ignore those problems. So it's pretty difficult to handle all the cases. Which brings me to the next point, which is device fragmentation. Probably a lot of talks in this conference about this. We are in the middle of a huge explosion of mobile devices that supports HTML5. I mean, this year in 2013 there will be over a billion sold worldwide. It's amazing. And you have different mobile platforms, iOS, Android, Blackberry, Windows Phone and with their upgrade, mobile OS upgrades. And potentially every device or every mobile OS upgrades has the potential to introduce new inconsistency or bugs in the way the HTML5 video specification is implemented. So every new device that comes out, we have to test it and be sure that the thing works. And believe me, it's not something that it's simple. Another big problem is video formats. Let me just give you a little background. Right now we have essentially three video formats that people use to do video with HTML5 on the web. MPEG4, WebM and OGG. For your information, the value in bold is called the container format. And then next to it I put the video codec slash the audio codec that are used inside the container. And the problem is that not a single one of those formats works across all browsers. And can you imagine it? I mean, it's like having an image tag here is the browser support. It's like having an image tag that, you know, for which you cannot use it, for instance, JPEG. Just JPEG. It's like for every image that you want to embed, you have to add a JPEG and maybe a PNG version. It's really painful. But it's even worse than that, because at least with images you could convert them like that in another format. But video to encode a video into another format is really a slow process and painful process. So people do not want to encode in different formats. It's painful. And if they are going to choose one format, it's difficult. But it's probably going to be MPEG 4, because there is where you have the mobile and iOS support. Because, you know, the mobile devices have hardware chips that do the decoding. And so you can have it on as a little phone. You can have a full HD video decoding. And so this gets really tricky, because now imagine the situation that we are in. We have an HTML5 video player cutting edge. And then we have two great HTML5 browsers like Firefox and Opera that do not support the MPEG 4. And our HTML5 video player will not work if the user just put an MPEG 4. And so it's difficult. And fortunately, there is a flash that supports MPEG 4. And so basically what we did is that we build a second version of the player completely in flash. And for this reason, and we made them look identical. So the end user will not even see the difference. And so for instance, if you are on Opera or Firefox and the user just specified a video tag with an MPEG 4, you will get the flash version of our player. But you start to see that it's pretty difficult to, you know, to provide a complete solution that works everywhere. The other challenge that we have is conflicts with existing JavaScript and CSS code in the page. Now if you have a flash video player, you know, it doesn't care about the CSS rules that you have in the rest of the page. It's pretty isolated. But if you are building an HTML5 video player with DOM nodes and CSS, of course the UI can get really messed up with existing CSS in the page. Especially if you do it without an iFrame like we do. And so it's been, you know, one thing is to do an HTML5 player that works in one page like that demo page that we did. Another thing is doing a video player of HTML5 that has to work on every page out there. Every page and with every condition of CSS and JavaScript. And it's been very difficult. Now for all these reasons, because of all these challenges, because of the continuous evolution of HTML5 videos, the bugs that fix the new devices that come out almost every week, you know, we were, just before we announced the final product, we were thinking, well, if we provide it as a zip file that the developer will download and then will install it himself in his web server. Well, that player will become obsolete in a matter of days. And if it doesn't, you know, every time we do an update, it forgets to download the updates, but the video will stop working on some devices. So we said, well, we need to deliver this player as a service in the cloud. And so this is what we did. And we are still doing it today and it's working really, really well and our users are extremely happy about it. Basically, it works like this. You just, in addition to the video tags, you know, you have to provide one line of JavaScript, just one line. And no installation, no download required. You get your player up and running in minutes. And then if you, if we detect a new platform to support, we just perform an update and you don't have to do anything. And we do this for thousands of websites. And if there is a problem somewhere, for instance, in a particular device, in a particular browser or in a particular page, we can perform the maintenance and then update all of our users in real time globally. And this is really nice because it makes the solution stronger and stronger every day. So basically, you see that from that demo page, we basically end up building a player that can play video on any platform, on any browser, on any web page without high frame, plus a cloud infrastructure to deliver it and to keep it always up to date. And we launched this on March 2011 and it's been working really well. We have happy customers. Here are a few examples. But there is a, but we wanted to push this further because if you look at all those sites that are using our player and you look the player, it's basically always the same player. Let me just zoom it to, it's this player. Same look, black and white, same basic features. And I already explained that just to do that, that it appears very simple for the end user. In reality, behind the scenes, it's very complex. But the problem is that we wanted to go beyond that because users were asking more features. And, you know, they were asking, I don't know, subtitles support or they want to add social sharing features in the player. Or some people want a different look of the player. Others want to change the colors of the player. It's all things that were easy to do with Flash when there was Flash and no mobile devices, only desktop computer. But now with the architecture that we had at that point, which by the way is the same that other serious services like YouTube and Vimo are using, it's basically, the architecture in the player is basically involves having multiple separate code bases. So as I explained before, we have an HTML5 player for the desktop, this one. Then we build a Flash player. And then we have also mobile players for iPad and so different code base. And it's pretty difficult to make that architecture scale if people want to all these different features. And that's why we basically spend last year, actually more than over a year, trying to solve this problem, which is really difficult, specifically for video players. And we developed a framework that unifies all these different technologies and abstract them away and extract away all the differences between these technologies. And basically allow us to create, it's called Sublime Video Horizon, and basically allow us to create any possible video player we can imagine in terms of design and features. Here are a few examples. They are all existing players that we build with our framework and they are not the bookups, you can see them on our website. And they are not a Flash player, they are HTML5 video players. This is a player we did for Sony, they will use on all the Sony Europe website. And this is an HTML5 branded player that we built just for demo purposes. And very importantly, this player are now built with a single code base. And the framework will take care of making them work and graphically render exactly the same in all browsers, really all. We have, this is the branded player, HTML5 branded player working on Chrome. We can even go down to IE8 and even IE6. You know, the CSS is completely, you can see that the CSS is broken but our player says pretty rock solid. I will explain how we can do that. And then it works also on mobile, on the latest mobile platform Android and here the iPad. And we actually have some nice touches to make the UI slightly bigger to be touch friendly but that's a detail. Now, this framework is a pretty rich technology that covers almost every aspect of creating a video player. You are not able probably to read. This is an architecture diagram. You can find it on our website. But to conclude my talk, I just wanted to quickly talk about one of those aspects which is the graphics library that is blinking over there. And I also choose that because it will be a nice transition to the final talk that Vincent will give on the graphical webs. And I will be getting maybe a little bit off topic from video because I will be talking about graphics. But it's a really important part of our framework because basically this library allows us to draw all of our player UI using vector graphics. So all the players that you saw in the latest ones do not use images. So they will look just beautiful on every screen or writing a display even on touch devices when you pinch to zoom. You won't see pixelization. It's really great. And the problem, the really challenging problem that we had is that you don't have a single drawing engine that will work across all browsers. You have different ways of doing that but not a single one will work across browsers. And so we have to use different techniques. We mainly use SVG for modern browsers and it's great but SVG doesn't work everywhere. For instance, you have some browsers which are still used that supports SVG but do not support the latest version of SVG that has filters that allow us to draw shadows like this. It's iOS 5 and i9 for instance. So for instance on i9 we use Canvas which as Vincent will probably tell you it's a completely different technology than SVG. And to make it work on i8 and 6 we actually use Flash to draw the little layers and the little views composing the UI which is also another completely different technology. But the nice thing of this library is that we don't have to code with Flash or ActionScript or even Canvas or SVG. We just use our unified drawing API, it's a JavaScript simple API and we draw the player once with it and then the framework will take care of automatically translating to the appropriate rendering engine. Now we use this technology internally to build and write all the players that we do that you can see on our website but we want to add many different things to this framework and right now this technology is not yet ready for you to use directly to develop your own players but we are definitely considering all possible options to give developer access to this technology and if you are interested to know more about it just come by after the talk and I can give more details. So thank you very much. How, am I going first? Go ahead. How do you test it across all the different devices? You have to come to our office. So, you know, yeah, I mean there is absolutely no other way. On iOS you could, you know, at the very beginning in 2009 we had the iOS simulator but you just can't use the Android emulator on the other device. It's just not possible. You have to have the real device so we have lots of them. And you know, yeah, we use all the tools that people already mentioned during this talk but there is of course also some manual things going on, for mobile especially. So, you know, clicking and seeing actually that your UI is working. Yeah, we had the same issue with HistoryJS and we're just like, I don't know. It's a pain, yeah. I'll chat to you afterwards maybe. Absolutely. But you know, since we know how much painful it is and we know that other people that would have to do that so we think we bring value with our solution, you know, exactly for that reason. Zeno? Yes. Could I use your drawing API to draw something else than a player? Very good question. So, yeah, absolutely. I mean the whole framework has been thought specifically for video players but if I show you, basically you will have to, you can go to the side and see this but the basic framework here has absolutely nothing, there is no relation with a video player, you know. It's just composed by libraries, generic libraries, so a graphic library, a module library, a library to manage media, audio and video but it's not, the video player code is not in there. So, absolutely, in theory that a graphic library could be used to build, I don't know, a slide share player to visualize slides, you know. It's typically, I think it's, you don't want to use it to build a full website but it would be great if you have to build something that is afterwards embeddable like in a rectangle to embed in other sites so that it would be great, yeah. Yeah, I have one, here. So, I have one question. Who is, yes, hi. So, my question is, do you support the video editing or annotating the video feature as of now? Annotating? Annotating the video. So, no, but what do you mean exactly? Automatically or you mean for subtitles or captioning support? Yeah, probably subtitle or adding some note at a particular slice of time that I want to add extra comment to that video. Yeah, so basically, we are actually right now, the team is with us and maybe not today but we are developing the subtitle support and captioning support, basically the support for the truck element which is a part of the HTML5 video and it's really nice, it supports subtitle captioning but also chapters, description and metadata and we are integrating all that and then, I mean, we cannot do automatic transcription but if there are other technologies that do that and they can output some captioning file that we are able to integrate into the player and then we have a pretty powerful public JavaScript API with which you can control the player and, for instance, we will release very soon a Q-Point API that basically you can add actions to a specific time in the player. So, you could have, for instance, having the text of the video below the player and then seeing the words that are being said in the video you can see that graphically advance below. Okay, and another question. From an end user, I'm not able to understand the difference between this as a video player against the YouTube. Yeah, absolutely. It's because you are totally right. So, YouTube is absolutely great and when I showed you the slides with our customers most of those were just before we announced our latest player that we announced it in December last year and those were all customers that already for some reason they didn't want it to go on YouTube because there are different reasons because you want to keep control on your sources. You don't want maybe the social aspect of it people adding comments or maybe for business or commercial reasons. So, that's why our customers are not the end user our customers are web publishers and maybe they already decided they don't want to use YouTube but having said that, more and more people are using YouTube actually offer a pretty amazing integration with YouTube that you can check out on our website and basically you can take any video on YouTube and just with one line you provide the YouTube ID in the video tag and when you use our player you can put basically our player design on top of a YouTube video. So, we actually now integrate with that. There are some limitations. There is a video that is monetized that is showing ads. I will tell you the details afterwards. There are some problems with the API. Just one clarification, by integration do you mean that I can integrate all my videos in my YouTube account if I am having your player in my site I can get all the YouTube videos to that? Absolutely, I show you an example if I have the connection so you can, it's sublimevideo.net slash YouTube. So, basically for instance here, ah, sorry. So, this is, now I have a very slow connection. It's okay, I just show, the video is not working but basically the video is hosted on YouTube and this is our player. And here we have another one, it's our video with the simple player that you show in the slides and the video is hosted on YouTube but you can have our player with our custom feature on it. And it will work on the iPad also and all the platforms. I have a question. I'm here. Yes. So, this is like kind of a cloud service, right? Sorry? Is this like a kind of a cloud service? Sorry, I didn't understand. Is it a cloud hosted service? Ah, okay. At the moment it's a cloud-only service, yes. Okay. And where will the videos be hosted in our end or in your end? The video, we, you know, we say we are a cloud service but it's just to deliver the player files. So, the video assets, you can put them wherever you want. Generally, most of the customers, they use a CDN. It can be S3 with CloudFront, it can be Akamai or anything. And then, so, we just use our CDN to deliver you as fast as possible the player files. So, as an enterprise, if we have a private intranet and if we need to use this, so what do you say about that? Yeah, so, if you are an enterprise customer and we could maybe have a look into it and provide a self-hosted license but, you know, it's, we don't do it right now but we might consider it for an enterprise customer, yes. And last question. Do you have any open source developers like me who can try playing around and contributing? That's, so, I mean, the play, we have a JavaScript API that it's documented and you can use it to control the player and to interact with the rest of the page. But to use the framework that I presented at the end of the talk, this is what I was saying is not yet ready but we definitely want to give some sort of access. It could be via an SDK or open sourcing and right now we are open to all, we need feedback and we are open to all options. Hi, hi, hey. Yes, I have so many questions. I got a question. Could you describe more deeply about the technologies you use in your framework? Is it writing completely on JavaScript, not just, or what's the technology it's based on? Yeah, so basically it's JavaScript. It's actually based on CoffeeScript so you would write every, to write a player like this you code it in CoffeeScript. So the, your horizon framework is completely writing in JavaScript. And another question I really think I should read it about in your side but I'll ask, do you have some commercial licenses for this? So the question is where you get this bunch of money your company, where is the money taken from for developing all this crazy stuff? So I didn't understand the last part of the question. How do we make money? That's okay, very easy, no problem. So basically, you know, you know, but basically the modular player is the one that everybody can use. You just click this and now I'm already logged in but otherwise there is a sign up button up there. You sign up and you already get for free a lot of value but when you use the player for free we add a sublime video logo for a couple of seconds in the corner of the video at the beginning. And then you can basically buy features, you know. So for free you get already a lot but you can, for instance, the YouTube integration is free but, for instance, if you want to add a social sharing feature you can buy the add-ons to add that feature, you know. So we basically monetize the add-ons and because this framework is completely modular it allows us to add these features in a modular way and so we can basically say this feature is free we built it into the player, this feature will be a paid feature. And then we have another way of making money is for more enterprise customers where we can basically provide them with a custom tailor-made player like the one that we did for Sony, you know. It's a completely tailor-made player and that also it's a custom pricing that we do for them. Hi, I have a question. Over here. Yeah, hi. So what you actually achieved is something like taking the disparities in the frameworks and different browsers and creating a unique solution, one solution for it and, you know, try to and run it pretty well, basically. So, but there's also another aspect to video streaming is like the video streaming servers, the different types of encoding platforms like as you mentioned, a couple of them. So are you guys thinking on the lines of actually creating a unified solution for that part of the problem because I know some of the codecs are paid in proprietary items and some are open-sourced. So have you thought about that layer of the problem also? I mean, I'm really, really sorry, but I think I understood the 50% of... I'm really bad, I'm really, really sorry. I didn't understand the... Okay, I'm very fast, I think. Sorry? Are you open to video streaming service? No, no, no, no, no, no. Okay, I'll try to be slower this time. That's like an end-flow from the built-in build time. Yes, exactly, absolutely. Yeah, okay. Sorry, I'm really sorry. I'll tell you the question again. So I'm saying, so you get a unified solution for different types of browsers and to provide a different kind of, same kind of experience on all browsers and you're monetizing it. Another layer which a company's, a layer problem which companies face is the encoding of videos. I think there are some copyrights around the encoders. And also you have to pay some royalty to use some codecs. And also the problem of streaming, streaming servers and all. So are you trying, are you thinking of going that side of the problem also providing not just a video hosting solution, but also a unified encoding format which is for all companies to support? Okay, maybe I understood something, sorry. Should the guy with the Aussie accent explain it? Are you looking at doing encoding solutions because encoding is a pain in the ass? Yeah. I mean, but I mean it wasn't his question, right? That was your question, wasn't it? Okay, so okay, so I mean basically one way would be to use an existing service like YouTube or Vimeo Pro that handles the encoding for you very well and we integrate with both YouTube or Vimeo Pro, you know? But if you want to own your, to have access to your sources yourself, not that I'm sorry for my English it's becoming worse and worse. But if you want to have control on your sources there are cloud services that offer encoding and there is one very good which is called a ZenCoder and it's basically, they have an API and you can basically it's encoding in the cloud, you know? You don't want to do that with handbrake or manually in the terminal of your computer because it's really a pain in the butt to do. So if I don't, later after the talk, just come to me and I will try to exactly answer your question, okay? If it was not right. Sorry. So how is your cloud service different from hotlinking? Is it just hotlinking with a bunch of paid features like optional paid features? No, it's not just hotlinking because basically there is all the user management built into it so basically you have first of all you have a user account then in your user account you can create your sites and basically for every site that you create we build a player that will only work in your site because we don't want that you know, people just come to your site, they steal the loader and they use it on their site so there is a license check going on and then there is also another part that I didn't talk about it's all the analytics that we can do so the players can send analytics and we display them for you usage and video place so you can basically see the that's who That makes sense, cool Thank you, thank you Zino Thank you