Movatterモバイル変換
[0]
ホーム
URL:
画像なし
夜間モード
Chromium Blog
News and developments from the open source browser project
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.
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
83
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
35
chrome 81
1
chrome 83
2
chrome 84
2
chrome ads
1
chrome apps
5
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 OS
1
chrome privacy
4
chrome releases
1
chrome security
10
chrome web store
32
chromedevtools
1
chromeframe
3
chromeos
4
chromeos.dev
1
chromium
9
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
emoji
1
emscriptem
1
enterprise
1
extensions
27
Fast badging
1
faster web
1
features
1
feedback
2
field data
1
first input delay
1
Follow
1
fonts
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
4
iframes
1
images
1
incognito
1
insecure forms
1
intent to explain
1
ios
1
ios Chrome
1
issue tracker
3
jank
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
lock icon
1
long-tail
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
20
performance tools
1
permission UI
1
permissions
1
play store
1
portals
3
prefetching
1
privacy
2
privacy sandbox
4
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
root program
1
safe browsing
2
Secure DNS
2
security
36
site isolation
1
slow loading
1
sms receiver
1
spam policy
1
spdy
2
spectre
1
speed
4
ssl
2
store listing
1
strobe
2
subscription pages
1
suspicious site reporter extension
1
TCP
1
the fast and the curious
23
TLS
1
tools
1
tracing
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
2
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
Follow @ChromiumDev
Give us feedback in our
Product Forums
.
[8]
ページ先頭
©2009-2025
Movatter.jp
