With over 2 billion videos streamed every day and the biggest category of video being music, YouTube is the heavyweight champion of music streaming services. When Joe Bloggs wants to listen to a track heʼs never heard before, itʼs likely heʼll type it into YouTubeʼs search box. Even if he uses Google to search for the track, one of the top results is likely to be a YouTube video (if thereʼs a video available).
With that in mind, it makes a lot of sense for labels to upload clips of their new releases to YouTube, and of course many labels already do this. Itʼs a good way to build hype for your new release without the audio getting ripped and shared pre-release, and since developing their Partnership Programme, it creates a way for labels to generate income from their videos being streamed. YouTube have said that the payments they make to content owners have more than doubled in the last year and they expect them to more than double again in the coming year.
We looked at countless examples of taster videos on YouTube and spoke to clients about if and how they create them. Itʼs not beyond the capabilities of a creative person to put one together, but it does involve design, audio editing, video editing, and a fair bit of experimentation to discover the best formats and techniques to use. We decided to try to make the process easier and this is what we came up with.
The making of… (warning: contains geek-speak)
Work on the the project involved some interesting challenges. We wanted to build a browser-based video and audio editor (and compiler) to produce professional release taster videos.
Eventually, and rather predictably, we hit a fatal stumbling block with using our old friends HTML and CSS to lay out the videos. Pixel-perfection of fonts x-browser is pretty much an impossible dream. Even pixel perfection of fonts across different HTML elements in the same browser is fairly tricky! We also wanted to use CSS3ʼs
@font-face. These videos were going to be rendered to video and so we would not have to be bound by using web fonts. We can use any fonts we want! Great news, but again, differences in the support for
@font-face mean that you have to supply different font files to different browsers, and this only escalated the non-pixel-perfection mentioned above. It was critical that after a client builds a video in their browser and the data is sent to the server, we need to be able to render exactly the same images that the client was seeing. There was no way we could guarantee this was going to be the case. In the end, the only way we could guarantee consistent fonts and pixel perfection of fonts x-browser was to use Flash for the text; a decision nobody was thrilled with, but a solution that was going to work.
The next stage of the development was audio editing. We wanted an interface that lets the client choose the exact clip of the track that they want included in the video: where it starts, how long it is, and how it fades in and out. We made a simple click-and-drag interface for this, along with input fields for even greater control.
We wanted to make these videos look great so we started thinking about how to add some interest to them. An obvious solution was to add some sort of visualisation of the audio playing through the video, and the obvious technology to use for that was the new HTML5
tag. We decided to see what the new tag is capable of. Itʼs not yet supported in all browsers and amongst the browsers that do support it, thereʼs no common ground for what audio formats it will play. Ogg vorbis, mp3, wav all have varied support, but none is common to all browsers. Ugh! We really didnʼt want to send different formats of audio to the client based on what browser theyʼre using, and in the end we decided to drop the
tag and do the audio analysis server-side. Unfortunately, this meant losing a real preview of the visualisation while building a video. We try to embrace emerging technologies and the opportunities they bring, but thereʼs only so much you can do.
Getting the YouTube specs right was another challenge, and it has to be said, the YouTube docs are very lacking. This may be intentional to allow them the freedom to change specs whenever they want, but it can be a bit annoying from a userʼs perspective. We went through a process of uploading dozens of different format videos, waiting for them to be processed, then analysing the quality of picture and sound the various formats produced. While going through that process, I couldnʼt help but wonder how many other people have done the exact same thing to try to figure out what formats to use.
At the time of writing, the Video Virals creator only works in Firefox 3.6+ and Webkit (Chrome and Safari) browsers. Whether or not weʼll add support for other browsers in the future remains to be seen. Windows, OSX and Linux clients all have options for using the feature and weʼd prefer to not be too restricted by missing or badly supported browser features. Weʼre really happy that browsers are advancing to a point that allows some really cool stuff to be done, and while itʼs easy to talk about the inconsistencies and lack of support for standards, the truth is that things are getting a lot better and some of this stuff couldnʼt have been done a year or two ago.
Where to go from here with the Video Virals is going to depend a lot on client feedback. The possibilities of what can be done are endless and as always, weʼre welcoming suggestions from clients. For now, we hope that the feature proves to be useful and makes the process of getting taster releases up on YouTube simple.