Chris Jones has put together a demo video of a super-early stage Gecko-driven browser that’s multi-process. It’s super-duper early and realizing that we’re only in Phase I of the roadmap is important but it’s great to see such speedy progress. Release early, release often!
Today Dailymotion, one of the world’s largest video sites, announced support for open video. They’ve put out a press release, a blog post on the new openvideo site as well as a demo site where you can see some of the things that you can do with open video and Firefox 3.5. They are automatically transcoding all of the content that their Motion Makers and Official Users create and expect to have around 300,000 videos transcoded into the open Ogg Theora and Vorbis formats. You can view the site they have up at openvideo.dailymotion.com.
I’d like to personally thank the wonderful people at Dailymotion, along with Paul and Tristan who helped bring this project to the point where it is today. Dailymotion has been an excellent test case for us because they haven’t just encoded with the formats that we support but also built a full-fledged player using HTML, CSS and JavaScript that looks, feels and acts like the flash-based players we see on the web today. They also make it possible to embed open video using an clever <object> tag that loads the video content safely in an HTML page.
Standing on the twin pillars of the HTML5 video API and royalty-free codecs, the movement to bring open video to the web is well underway. Dailymotion, along with Wikipedia and the Internet Archive, have all committed to start serving up open video. The free encoders are getting better and better over time and we’re starting to see more interest in the technologies.
Dailymotion, Mozilla and a large number of other partners will be at the Open Video Conference on June 19th and 20th. If you’re interested in talking with us you might want to come down to the conference and learn what’s happening with video on the web.
Monty posted another update on the work that’s been going on to improve the Theora encoder. It’s worth re-posting here because I think that it includes some compelling images and graphs that show you improvements. So I would suggest that people wander over and have a look at his update.
The headlines include:
1. They have made substantial improvements to Theora’s encoder. The images which I include below really show off the improvements in sharpness at the same bitrate.
2. That the encoder is now creating higher-quality streams than H.264 at many bitrates. The data includes some comparison with x264 without ffmpeg bugs which show on this test that x264 does do better than Theora in this particular test. However, there’s an important side note worth reading on this topic.
3. That the original tests that gave Theora such a bad name were done with incredibly bad tools. See the squiggly line on the graph in monty’s post for evidence of that.
Anyway, a picture speaks a thousand words so I’ll include them here. Open them up in two tabs and switch between them for the full effect.
Theora 1.0:
Theora.next:
Monty points out that this was largely other people’s work and they should get most of the credit. So Greg, Tim and many others - thanks. Keep up the great work.
As posted by Lawrence Lessig, you can now download Rip: A Remix Manifesto. I had the chance to see it a few months ago at a private event and I really enjoyed it.
Another really great thing: you pay what you want for it. So pick an amount - $5 or $7 for example - download it and enjoy it. (I paid $20.) If nothing else the music is fantastic. Enjoy the trailer on blip.tv or embedded below.
Sarah and Francesca rock pretty hard. Update: Now available on the Mozilla Community Store!
Paul and Joe also had their bliz-shirts. Because they are awesome. Everyone else wanted to know where you can buy the t-shirt. You can get them on Monty’s t-shirt shop.
I have mentioned this t-shirt before. And because you’ve gotten this far:
It’s earth day so I thought today might be a good day to post this. I’ve been sitting on a set of tabs in my browser for a long time now - months I think - and I think that it’s enough to be able to share with people.
Over the last few months I’ve been working hard to wrap my head around the issues of climate change and what it might take to be able to deal with it. As of late I’ve become a pretty data-driven person. That is, I want to have a decent amount of information about how to measure a problem, but also what it’s going to take to solve it. I thought that I might share what I’ve seen out there that’s really put things into perspective for me.
The Size of the Problem
I’m going to share three links here that I think underscore the scope and scale of the problem. The first two are from Stewart Brand, the last is quoted by Michael Parekh but is from another article. The assumptions that underlie this set are that:
- That fossil fuels, and our increasing use of them, is contributing to a rise in the concentration of carbon dioxide and other greenhouse gasses.
- That rising concentrations will eventually cause us to reach tipping points where we will start to do serious damage to the ecosystem that supports the lives we lead. The very scary tipping points to me include rising sea levels, melting of the permafrost, the destruction of the rain forest and its ecosystem and last but not least the acidification and warming of the oceans. Each of these are likely to result in vast quantities of otherwise stored carbon to be released accelerating the process to where we can’t stop it.
- That the effects from those changes will cause a huge amount of damage to the planet but will also result in damage to humanity as well. A sudden scarcity of resources might result in us doing some terrible things to each other - more than what we see today. It’s a pretty terrifying thought.
So that being said, here are some links that I’ve used to understand the problem.
Quoting Stewart Brand:
The world currently runs on about 16 terawatts (trillion watts) of energy, most of it burning fossil fuels. To level off at 450 ppm of carbon dioxide, we will have to reduce the fossil fuel burning to 3 terawatts and produce all the rest with renewable energy, and we have to do it in 25 years or it’s too late. Currently about half a terrawatt comes from clean hydropower and one terrawatt from clean nuclear. That leaves 11.5 terawatts to generate from new clean sources.
…
“Two terawatts of photovoltaic would require installing 100 square meters of 15-percent-efficient solar cells every second, second after second, for the next 25 years. (That’s about 1,200 square miles of solar cells a year, times 25 equals 30,000 square miles of photovoltaic cells.) Two terawatts of solar thermal? If it’s 30 percent efficient all told, we’ll need 50 square meters of highly reflective mirrors every second. (Some 600 square miles a year, times 25.) Half a terawatt of biofuels? Something like one Olympic swimming pools of genetically engineered algae, installed every second. (About 15,250 square miles a year, times 25.) Two terawatts of wind? That’s a 300-foot-diameter wind turbine every 5 minutes. (Install 105,000 turbines a year in good wind locations, times 25.) Two terawatts of geothermal? Build 3 100-megawatt steam turbines every day-1,095 a year, times 25. Three terawatts of new nuclear? That’s a 3-reactor, 3-gigawatt plant every week-52 a year, times 25.”
In other words, the land area dedicated to renewable energy (”Renewistan”) would occupy a space about the size of Australia to keep the carbon dioxide level at 450 ppm. To get to Hanson’s goal of 350 ppm of carbon dioxide, fossil fuel burning would have to be cut to ZERO, which means another 3 terawatts would have to come from renewables, expanding the size of Renewistan further by 26 percent.
Reading the whole mail is important and eye-opening. You should do it. I think that this message alone puts into perspective the sheer mind-numbing amount of work that has to happen to be able to effectively protect our planet from ourselves. When I hear about eight or even fifty billion dollars aside to help with these problems I chuckle. Because it’s only a small portion of the amount of our own efforts that’s required to be able to make steady progress against this growing problem. More on that in the “Making it Personal” section below.
2. Climate Change, Recalculated
This is a pretty long presentation, but thumbing through it is worth your time. He goes into talking about the basics of energy, what a “watt” is, etc. It’s a pretty important concept for everyone to understand - not just because they need to be able to measure their own energy footprint, but also how various technologies offset that footprint.
He also takes the time to talk about the scale required to solve the problem. Talking about the US industrial output, what it was during WWII and how that might relate to us starting down the path to fix it. You should take the time to thumb through this - slowly. It will really alter your perspective.
3. Michael Parekh on “The Hummer of Food”
The livestock sector is estimated to account for 18 percent of global greenhouse gas emissions and beef is the biggest culprit.
Even though beef only accounts for 30 percent of meat consumption in the developed world it’s responsible for 78 percent of the emissions, Pelletier said Sunday at a meeting of the American Association for the Advancement of Science.
That’s because a single kilogram of beef produces 16 kilograms carbon dioxide equivalent emissions: four times higher than pork and more than ten times as much as a kilogram of poultry, Pelletier said.
So yeah, I guess the lesson here is eat less beef. It’s a pretty simple idea, too. I just thought that pointing out that even small changes in lifestyle can still have a pretty big impact on the world - if we all do it.
Making it Personal
So by now you’ve spent the time to read through this and you have a better sense of both what it’s going to take to fix the problem but you don’t have a sense of what it takes to start making a difference in your daily life. My suggestion? Wander over to WattzOn and start building your own energy profile.
They have compiled a huge database of products, services and personal action and how those things translate into your energy footprint. For example, building a car requires a huge amount of energy so if you own one that should be counted in your energy footprint. If you replace your car every 6 years instead of every 3, that saves energy. Where you live and how you get to work affects it. And of course, the stuff that’s pretty easy to measure - home heating and electricity. All of that is collected together and you can create a profile. I did this and it was pretty eye-opening.
Here’s my profile as an example:
As you can see it turns out that since I work at home I have almost no commuting cost but it turns out that my flying around the world lifestyle accounts for nearly half of my wattage. Also it turns out that heat and electricity only make up a small amount of my footprint. I was not expecting this when I started the process, which is why I encourage everyone to do it themselves. It also means that I understand how much turning off a lightbulb means in the grant scheme of things and what an incandescent (100W) vs. an energy-saving bulb (20W) really means - not much, but enough to encourage me to do it anyway.
So how much would it cost to offset that footprint with clean energy?
So let’s talk about that roughly 10,000 watt lifestyle - what does it mean? What would it take for me to offset it? I sat down and figured out that I would have to purchase a whopping $275,000 in solar panels (installation not included!) to offset 10,000 watts. Not a small amount of money.
Yes, it’s a strange way to measure it and it doesn’t map to things like air travel but it puts a dollar value on clean generation to drive my daily life. But it takes my personal footprint and makes me understand the amount that I would have to invest to offset it. And it lets me put a dollar value in my head on the value of saving energy through lifestyle changes.
So it’s earth day. Why not sit down and figure out what it’s going to take for you to make the earth a better place?
Google has announced the availability of a plugin that implements 3D technology and makes it available over the web. You can read about the announcement in in the Google Code Blog and in an excellent article by Ryan Paul in Ars Technica.
Ryan points out that there are significant differences between what Google has built here and what we’ve built. I thought it might be worth it to expand on that a bit since it isn’t explained in depth in the Ars article.
Google’s 3D work is a plugin. So much like how Flash or Silverlight works you get a rectangle in the browser to draw into. They provide a high level scene graph API which uses the COLLADA format for loading objects underneath. It’s a very large chunk of code. If you take a look at the API and click around at the packages and classes you can see that there’s a lot there. Their use case is games and game-like things - virtual worlds. So it’s a great piece of work, but it’s also at a very high level.
Mozilla’s current proposal to Khronos is a very simple API that’s a wrapper around OpenGL ES 2.0. It’s currently available as an extension to Firefox 3.5 and is likely to be rolled into a version of Firefox after 3.5. The proposal is very focused on 3D. For example, we didn’t try to include video or audio because those are being covered by other web standards and we’re interested in making sure they are well integrated instead of trying to wrap those into a 3D spec. We’ve bound it to the canvas element so you can use it in much the same way you use the current canvas 2D context. Things like asset loading (via COLLADA or other systems) are things we haven’t dealt with because those can be handled entirely outside of the 3D api and layered on top of it. (Later in this post you’ll understand why this is important.) But the important thing is that it’s something that you can easily mix with the rest of the open web. Open Video and Audio, CSS, HTML, Canvas 2D, Canvas 3D, etc - you should be able to mix them all together and that’s our goal.
So these two 3D things from Mozilla and Google are pretty different. Not really competitive, either, because they have such different goals. The Google software is a very high level API 3D graphics API and what we’re proposing is more akin to the low level graphics API that those high-level systems are built on.
Given the title of the google blog post (”Towards an open web standard for 3D graphics”) it’s important to point out these differences since they affect how the standards process might look, and what the output might be. We’ve been through this a few times with different standards and it’s easy to point out what the key success factors are to build a successful standard. Here’s a quick iteration on those principals in my mind:
1. It’s important to keep the scope as small as possible.
The smaller the scope of the standard, the easier it is to understand the interaction of the various parts, what your goals are and what it takes to build an interoperable implementation. It’s also the easiest thing you can do to remain as future-proof as possible. It’s easier to add new APIs later if your scope is very very small.
2. Clear rules for interaction with the rest of content.
How does it work with the rest of the HTML spec? CSS? Video? Images? How can you copy content in and out? Can you use them as textures? These are just some of the questions that you have to raise as a way to describe how something like this might work with content. Once again, this is gated on #1 above - if the functionality is simple then the interactions can generally be pretty simple as well.
3. Allow the scope to change slowly over time.
Understanding that technology - especially on the web - does not exist in a vacuum outside of time. Standards do change over time and understanding how people use technology in the real world is the best possible way to understand how something should change and improve. Understanding that standards are an iterative process is important. Note that in #1 above - controlling scope - I mention that it’s important to keep things future-proofed via small and simple APIs. This is why - because you know that you will need to improve that API once you understand how people are using it in the field.
4. Allow most of the innovation to happen next to and on top of your API.
Last point - your standard should allow as much iteration and work to happen on top of your API as possible. This allows you to learn as much as possible about how people are using your software and gives them huge amounts of freedom to experiment and teach you about what you need to improve in the next iteration. If people are stretching your APIs and finding gaps in performance, you can add convenience APIs to make things faster - as long as they are simple APIs. We saw this in the real world with the JS libraries (dojo, jQuery) - we’ve been optimizing our engines and APIs over time to assist them as they have pushed our browsers to the limits. But we would not have known had we tried to implement everything that the libraries could have possibly done at the browser level.
OK, so those are the things that we think make for a successful standards process. I’ll point out one particular example of a dichotomy that I believe illustrates these rules so that people understand what I’m talking about: Canvas vs. SVG + SMIL.
Canvas is a very simple API (more info), much like what we’ve proposed to Khronos for 3D support. It’s well-scoped, well understood and integrates very well with other web technologies. And it’s been getting a huge amount of traction on the web. People are writing all kinds of really neat technology on top of it, including useful re-usable libraries for visualization. Have a look through Google’s own promotional site for Chrome - a huge number of them use canvas. It has traction. And we’ve gone through a couple of iterations - we’ve added support for text and a couple of other odds and ends once we understood what people were trying to do with it.
Now compare this to SVG and SMIL. Each of those specs are multi-hundred page documents with very large APIs and descriptions of how to translate their retained-mode graphics into something that’s usable on the web. (SVG 1.1 is a 719 page PDF. SVG 1.2 Tiny is 449 pages. The spec for SMIL is a 2.7MB HTML file.) We’ve seen some implementation of SVG and SMIL in browsers, but it’s been slow in coming and hasn’t seen full interoperability testing nor any real pick up on the web. The model for these specs was wrong, and I think it shows.
So I’ve spent some time talking about the context for standardization and what makes standards successful. How does this related to our stuff or Google’s stuff? Well, quite a bit actually. If we want something that browser vendors can easily implement, we need to understand that context and what we’re trying to standardize. Much of the work that Google did happened before browsers got as fast as they have, so there’s a good reason why they felt that they needed to implement so much of the code as native code and deliver it as a plugin. Their API is a good example of what a scenegraph API would look like on top of Canvas 3D. JS engines have gotten a lot faster since they started their plug-in and we think that it’s time that we start using them. Hence a low-level API that we can build on.
There’s a lot of great stuff going on with 3D on the web. We’ll be working with Google (and others!) via the Khronos group to try and standardize on a low-level API that browsers can support. It’s going to be a really fun year and I’m happy that we’re working to drive the web forward.
I’ll be speaking at the O’Reilly Velocity Conference on June 23rd in San Jose, CA. There’s a presentation/panel on What Makes Browsers Performant that I’ll be part of. We’ll have reps from both Google and Microsoft there as well. Should be fun!
If you want to attend, use this code: “vel09cmb” - it will get you an extra 15% off the price.
[ See Vlad's post on this topic, Arun's post in the Mozilla standards blog and the official Mozilla blog post. ]
Today Mozilla and the Khronos group announced that Mozilla will be leading an initiative to bring accelerated 3D to the web. This is a pretty big deal for us and for the web, and is really a reflection of the continued acceleration of open web technology well beyond just the classic HTML and JavaScript that we’ve seen in the past. It’s our intention to include this as base functionality in the release after Firefox 3.5, assuming all goes well on the standards front.
We’ve started to see more and more libraries being built to support use cases with Canvas in a 2D context but we really want to take things to the next level and start to allow people to use 3D capabilities as well. Accelerated 3D graphics with the super-fast next-generation JavaScript engines from nearly every web browser vendor means that we’re going to be able to start to see more and more advanced applications written using open web technologies. 3D is a huge part of that story and we’re happy to bring our proposal to the table.
The proposed spec (found in one of vlad’s post on 3D Canvas) is a pretty light wrapper on top of OpenGL ES 2.0, with some changes to support some JavaScript pleasantries. OpenGL ES is a decent starting point, which is why we picked it. OpenGL is supported as part of every major operating system and in it’s being picked up as a standard on mobile devices as well. Compared to the full OpenGL spec, the ES variant is a smaller subset that reflects the reality of what’s being used on the ground and most hardware and software vendors have actually been re-tooling to support OpenGL ES with support for older versions of full OpenGL emulated on top of OpenGL ES. Mixed with the fact that there’s a decent amount of knowledge out there in the industry of how to use OpenGL, we think that this smooths the integration between the current set of OpenGL users and larger web developer community.
Expect to see some releases of the code to start with in the form of the Canvas3D extension. Vlad has made releases of it in the past and we’ll be able to have something that works as an extension as part of Firefox 3.5 for people to start experimenting with.
Become a Friend of Gnome!
Watch as I Grow
interesting stuff
- Web Video Codecs — Anne’s Weblog July 3, 2009
- [whatwg] Codecs for and July 1, 2009
- Firefox 3.5 Is Now Available. Here’s What It Can Do. - Gadgetwise Blog - NYTimes.com June 30, 2009
- Mozilla rolls out new version of Firefox browser - Technology Live - USATODAY.com June 30, 2009
- Firefox 3.5 - At A Glance - Reviews by PC Magazine June 30, 2009