197 captures
28 Mar 2012 - 19 Jul 2026
Mar
APR
May
18
2020
2021
2022
success
fail
About this capture
COLLECTED BY
Collection:
Wikipedia Eventstream
TIMESTAMPS
The Wayback Machine - https://web.archive.org/web/20210418090800/https://blog.chromium.org/2011/01/
Chromium Blog
News and developments from the open source browser project
Cloud printing on the go
Monday, January 24, 2011
Last month, we
opened Google Cloud Print
to users in the Chrome notebook pilot program.
Google Cloud Print
allows printing from any app on any device, OS or browser without the need to install drivers. Today, we are very pleased to announce the beta launch of Google Cloud Print for mobile documents and Gmail for mobile, which we will be rolling out to users throughout the next few days. To read more about how to use Google Cloud Print for these mobile use cases, read more in the
Google Mobile blog
.
Posted by Tyler Odean, Product Manager
More about the Chrome HTML Video Codec Change
Friday, January 14, 2011
There has been a lot of discussion regarding this week’s
announcement
of upcoming changes to HTML video codec support in Chrome. The future of web video is an important topic, we welcome the debate, and want to address some of the questions raised.
Why is Google supporting WebM for the HTML
<video>
tag?
This week’s announcement was solely related to the HTML
<video>
tag, which is part of the emerging set of standards commonly referred to as “HTML5.” We believe there is great promise in the
<video>
tag and want to see it succeed. As it stands, the organizations involved in defining the HTML video standard are at an impasse. There is no agreement on which video codec should be the baseline standard. Firefox and Opera support the open WebM and Ogg Theora codecs and will not support H.264 due to its licensing requirements; Safari and IE9 support H.264. With this status quo, all publishers and developers using the
<video>
tag will be forced to support multiple formats.
This is not an ideal situation and we want to see a viable baseline codec that all browsers can support. It is clear that there will not be agreement to specify H.264 as the baseline codec in the HTML video standard due to its licensing requirements. Furthermore, we genuinely believe that core web technologies need to be open and community developed to enable the same great innovation that has brought the web to where it is today. These facts led us to join the efforts of the web community and invest in an open alternative, WebM.
Why didn’t you select H.264 as the baseline codec for the HTML
<video>
tag in Chrome?
We acknowledge that H.264 has broader support in the publisher, developer, and hardware community today (though
support
across the ecosystem for WebM is growing rapidly). However, as stated above, there will not be agreement to make it the baseline in the HTML video standard due to its licensing requirements. To use and distribute H.264, browser and OS vendors, hardware manufacturers, and publishers who charge for content must pay significant royalties—with no guarantee the fees won’t increase in the future. To companies like Google, the license fees may not be material, but to the next great video startup and those in emerging markets these fees stifle innovation.
But it's not just the license fees; an even more important consideration is the pace of innovation and what incentives drive development. No community development process is perfect, but it’s generally the case that the community-driven development of the core web platform components is done with user experience, security and performance in mind. When technology decisions are clouded by conflicting incentives to collect patent royalties, the priorities and outcome are less clear and the process tends to take a lot longer. This is not good for the long term health of web video. We believe the web will suffer if there isn't a truly open, rapidly evolving, community developed alternative and have made significant investments to ensure there is one.
Does this mean I will no longer be able to play H.264 videos in Chrome?
H.264 plays an important role in video and the vast majority of the H.264 videos on the web today are viewed in plug-ins such as Flash and Silverlight. These plug-ins are and will continue to be supported in Chrome. Our announcement was only related to the
<video>
tag, which is part of the emerging HTML platform. While the HTML video platform offers great promise, few sites use it today and therefore few users will be immediately impacted by this change.
Isn’t this just an effort by Google to control the web video format?
WebM is backed by many in the web community. Google views its role like any other community member and has no desire or intent to control the WebM format. Our goal is to see the HTML
<video>
tag become a first-class video platform. As with many other web platform efforts, we expect the majority of organizations and individuals contributing to WebM won’t be affiliated with Google or any single entity.
Developers have already
created
high-quality alternative (yet compatible) implementations of WebM, and we think that kind of choice is great for everyone.
Won’t this decision force publishers to create multiple copies of their videos?
Some have expressed concern that our announcement will force publishers and developers to maintain multiple copies of their content when they otherwise would not have had to. Google is among the largest publishers of video content in the world, and as such we are sympathetic to this concern. Remember, Firefox and Opera have never supported H.264 due to its licensing requirements, they both support WebM and Ogg Theora. Therefore, unless publishers and developers using the HTML
<video>
tag don’t plan to support the large portion of the desktop and mobile web that use these browsers, they will have to support a format other than H.264 anyway (which is why we are working to establish a baseline codec for HTML video). More broadly, given the proliferation of devices, platforms, and connectivity types used to access the web, most content providers already produce multiple versions of their videos to optimize for these devices. We’re confident that the rapid evolution of HTML video and WebM over the coming year will make the combination a compelling solution for content providers and developers and the proliferation of WebM capable devices will make their investments highly leveraged.
Bottom line, we are at an impasse in the evolution of HTML video. Having no baseline codec in the HTML specification is far from ideal. This is why we're joining others in the community to invest in WebM and encouraging every browser vendor to adopt it for the emerging HTML video platform (the WebM Project team will soon release plugins that enable WebM support in Safari and IE9 via the HTML standard
<video>
tag). Our choice was to make a decision today and invest in open technology to move the platform forward, or to accept the status quo of a fragmented platform where the pace of innovation may be clouded by the interests of those collecting royalties. Seen in this light, we are choosing to bet on the open web and are confident this decision will spur innovation that benefits users and the industry.
Posted by Mike Jazayeri, Product Manager
Updated: Clarified that the Safari and IE9 plug-ins to be released by the WebM Project Team enable WebM playback via the HTML standard
<video>
tag canPlayType interface and not an alternate non-standard method.
HTML Video Codec Support in Chrome
Tuesday, January 11, 2011
The web’s open and community-driven development model is a key factor in its rapid evolution and ubiquitous adoption. The
WebM Project
was
launched
last year to bring an open, world-class video codec to the web. Since the launch, we’ve seen first-hand the benefits of an open development model:
Rapid
performance improvements
in the video encoder and decoder thanks to contributions from dozens of developers across the community
Broad
adoption
by browser, tools, and
hardware vendors
Independent
(yet compatible) implementations that not only bring additional choice for users, publishers, and developers but also foster healthy competition and innovation
We expect even more rapid innovation in the web media platform in the coming year and are focusing our investments in those technologies that are developed and licensed based on open web principles. To that end, we are changing Chrome’s HTML5
<video>
support to make it consistent with the codecs already supported by the open Chromium project. Specifically, we are supporting the WebM (VP8) and Theora video codecs, and will consider adding support for other high-quality open codecs in the future. Though H.264 plays an important role in video, as our goal is to enable open innovation, support for the codec will be removed and our resources directed towards completely open codec technologies.
These changes will occur in the next couple months but we are announcing them now to give content publishers and developers using HTML
<video>
an opportunity to make any necessary changes to their sites.
Posted by Mike Jazayeri, Product Manager
Labels
$200K
1
10th birthday
4
abusive ads
1
abusive notifications
2
accessibility
3
ad blockers
1
ad blocking
2
advanced capabilities
1
android
2
anti abuse
1
anti-deception
1
background periodic sync
1
badging
1
benchmarks
1
beta
67
better ads standards
1
billing
1
birthday
4
blink
2
browser
2
browser interoperability
1
bundles
1
capabilities
6
capable web
1
cds
1
cds18
2
cds2018
1
chrome
34
chrome 81
1
chrome 83
2
chrome 84
2
chrome ads
1
chrome apps
5
chrome beta
1
Chrome dev
1
chrome dev summit
1
chrome dev summit 2018
1
chrome dev summit 2019
1
chrome developer
1
Chrome Developer Center
1
chrome developer summit
1
chrome devtools
1
Chrome extension
1
chrome extensions
3
Chrome Frame
1
Chrome lite
1
Chrome on Android
2
chrome on ios
1
Chrome on Mac
1
chrome privacy
4
chrome releases
1
chrome security
6
chrome web store
32
chromedevtools
1
chromeframe
3
chromeos
4
chromeos.dev
1
chromium
6
cloud print
1
coalition
1
coalition for better ads
1
contact picker
1
content indexing
1
cookies
1
core web vitals
2
csrf
1
css
1
cumulative layout shift
1
custom tabs
1
dart
8
dashboard
1
Data Saver
3
Data saver desktop extension
1
day 2
1
deceptive installation
1
declarative net request api
1
design
2
developer dashboard
1
Developer Program Policy
2
developer website
1
devtools
13
digital event
1
discoverability
1
DNS-over-HTTPS
4
DoH
4
emscriptem
1
enterprise
1
extensions
27
Fast badging
1
faster web
1
features
1
feedback
2
field data
1
first input delay
1
form controls
1
frameworks
1
fugu
2
fund
1
funding
1
gdd
1
google earth
1
google event
1
google io 2019
1
google web developer
1
googlechrome
12
harmful ads
1
html5
11
HTTP/3
1
HTTPS
1
iframes
1
images
1
incognito
1
insecure forms
1
intent to explain
1
ios
1
ios Chrome
1
javascript
5
lab data
1
labelling
1
largest contentful paint
1
launch
1
lazy-loading
1
lighthouse
2
linux
2
Lite Mode
2
Lite pages
1
loading interventions
1
loading optimizations
1
mac
1
manifest v3
2
metrics
2
microsoft edge
1
mixed forms
1
mobile
2
na
1
native client
8
native file system
1
New Features
5
notifications
1
octane
1
open web
4
origin trials
2
pagespeed insights
1
pagespeedinsights
1
passwords
1
payment handler
1
payment request
1
payments
2
performance
6
performance tools
1
permission UI
1
permissions
1
play store
1
portals
3
prefetching
1
privacy
2
privacy sandbox
3
private prefetch proxy
1
Profile Guided Optimization
1
progressive web apps
2
Project Strobe
1
protection
1
pwa
1
QUIC
1
quieter permissions
1
releases
3
removals
1
rlz
1
safe browsing
1
Secure DNS
2
security
35
site isolation
1
slow loading
1
sms receiver
1
spam policy
1
spdy
2
spectre
1
speed
3
ssl
2
store listing
1
strobe
2
subscription pages
1
suspicious site reporter extension
1
TCP
1
the fast and the curious
3
TLS
1
tools
1
transparency
1
trusted web activities
1
twa
2
user agent string
1
user data policy
1
v8
6
video
2
wasm
1
web
1
web apps
1
web assembly
1
web developers
1
web intents
1
web packaging
1
web payments
1
web platform
1
web request api
1
web vitals
1
web.dev
1
web.dev live
1
webapi
1
webassembly
1
webaudio
3
webgl
7
webkit
5
WebM
1
webmaster
1
webp
5
webrtc
6
websockets
5
webtiming
1
writable-files
1
yerba beuna center for the arts
1
Archive
2021
Apr
Mar
Feb
Jan
2020
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2019
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2018
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2017
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2016
Dec
Nov
Oct
Sep
Aug
Jun
May
Apr
Mar
Feb
Jan
2015
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2014
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2013
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2012
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2011
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2010
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2009
Dec
Nov
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2008
Dec
Nov
Oct
Sep
Feed
Follow @ChromiumDev
Give us feedback in our
Product Forums
.
