오늘 MPEG-4 메일링 리스트로 날라온 글…

http://www.streamingmedia...d-VP8-Compared-67266.aspx

소렌슨 인코더를 이용하여 H.264/AVC의 베이스라인 프로파일로 인코딩된 파일과 VP8을 이용하여 인코딩된 파일을 비교하고 있다.

사실 H.264/AVC는 화질이 충분히 훌륭하지 못하다는 이유로 디즈니 등에서 사용을 거부 당했었고, 이런 점을 보완하기 위해 FRExt(Fidelity Range Extension)를 추가했었다. 그 결과 베이스라인 프로파일과 FRExt 등이 적용된 High profile은 굉장한 성능차가 있음에도 Baseline profile만을 이용하여 성능을 비교했다는 점은 조금 아쉽다.

어떻게 생각하면 전력으로 승부한 VP8과 2진으로 승부한 H.264/AVC였다고 할 수 있을 듯…

어쨌든 위 사이트에선 움직임이 적은 영상에선 VP8 쪽이 좋았다고 이야기 하고 (골든 프레임이 배경을 잘 예측하기 위한 기술이니 어찌보면 가능할 수도 있는 얘기란 생각) 움직임이 클 때는 H.264/AVC가 좋았다고 얘기하고 있다. 그런데 내 눈엔 스케이트 보드나 피자 도우 만드는 영상에선 H.264/AVC가 훨씬 좋아보이고 나머지 영상은 별 차이가 없어보인다.

High profile로 비교했다면 어떤 결과가 나올지 조금 궁금하지만 제목들이 First … 식으로 시작하는 걸 보니 곧 또 다른 성능 비교가 올라오지 않을까 하는 생각 중…

뭐 그리고 그와는 별도로 아랫 글에서 인용하는 걸 까먹었던 구문…

3. How likely is VP8 to actually be free of patents? Even if VP8 is worse than H.264, being patent-free is still a useful attribute for obvious reasons. But as noted in my previous post, merely being published by Google doesn’t guarantee that it is. Microsoft did similar a few years ago with the release of VC-1, which was claimed to be patent-free — but within mere months after release, a whole bunch of companies claimed patents on it and soon enough a patent pool was formed.

3. VP8이 정말 특허에서 자유로워보이나? H.264보다 VP8의 성능이 떨어진다 하더라도 특허에서 자유롭다면 분명 유용할 것이지만 예전 포스트에서 말했듯이 구글에서 말하는 것 만으로는 특허에서 자유롭다는 것을 보장할 수 없다. 마이크로소프트도 몇 년 전에 VC-1을 특허에서 자유로운 코덱이라 주장했지만 결국 몇 달 후 많은 회사들이 자신의 특허권을 주장했고, 곧 특허 풀이 형성되었다.

from The first in-depth technical analysis of VP8

http://b.mytears.org/2010/05/2216

 

Posted on Aug 27, 2010 4:30 am by Lex Friedman, Macworld.com

Similar Articles:

MPEG LA, the firm that controls licensing for a number of video and other standards, announced on Thursday that it will never charge any royalties for Internet video encoded using the H.264 standard that Apple favors, as long as that video is free to end-users.

This is great news, even if it’s wrapped in some technical language. When you watch video on your Mac (or your iPhone, iPad, or any other device), it’s been encoded using one of many standards. Just as with popular audio formats like MP3 and AAC, video formats aim to find the sweet spot between video quality and file size—they want to get as high as they can on the former, and as low as they can on the latter.

Much of the video on the Web these days is presented via Adobe’s Flash technology—for example, YouTube’s standard, ubiquitous video player. As most iOS users know, Flash video doesn’t work with iPhones and iPads. And even on your Mac, watching Flash video requires use of Adobe’s Flash plug-in, which many Mac users (including famous ones) find a bit buggy.

As Apple has pointed out, many popular Websites have made the move to support HTML5 video alongside or, in some cases, instead of Flash. HTML5 is the latest and greatest version of the Web’s core markup language. The new HTML5 standard makes it possible for Websites to embed video that your computer can play without requiring a third-party plugin (like Flash).

Representatives from browser makers like Apple, Mozilla, and Firefox were involved in the Working Group that advised editor Ian Hickson as he worked on the HTML5 “spec”—the document that governs what is and isn’t valid HTML5. (You don’t want to know too much about the process of creating these specs; I imagine it’s worse than a trip to the sausage factory.) The unfortunate takeaway was this: the big browser developers couldn’t agree on which video format the new tag in HTML5 should use: some sided with H.264, others with a format called Ogg Theora.

As Hickson summarized the situation in an e-mail to the Web-standards body WHATWG, Apple refused to implement Ogg Theora in QuickTime—which Safari uses to decode video—”citing lack of hardware support and an uncertain patent landscape.” Mozilla and Opera both refused to implement H.264, expressing concerns about its licensing requirements. Google implemented both H.264 decoding (which Apple and QuickTime do support) and Ogg Theora in Chrome, but expressed concern about the quality-per-bit of Ogg Theora video.

Without getting too detailed about all these licensing and patent objections, the gist is simply that video standards are often patented, and the use of those standards requires a license. The MPEG LA group, which owns the H.264 video codec, had declared that it wouldn’t charge any royalty fees until 2016, but Mozilla and Opera were worried about what those future costs might be. Should H.264 video become a de facto Web standard in the meantime, the MPEG LA group would be in a position to charge a healthy fee for browser developers to keep using the format.

While Mozilla and others believed that the Ogg Theora format wasn’t encumbered by such patents (and potential licensing fees), Apple and Steve Jobs remained unconvinced. Microsoft later announced that Internet Explorer 9 would support H.264 video, and not Ogg Theora.

Thus, Hickson wrote, “I have reluctantly come to the conclusion that there is no suitable codec that all vendors are willing to implement and ship.”

That unfortunate sequence of events meant that providers of Web video—and, to a certain extent, their consumers—got the short end of the stick. For full HTML5 video support, media providers now must encode their videos in multiple formats to make all browsers and platforms happy—that’s time- and resource-consuming for content producers.

Earlier this year, Google acquired On2, the company that initially developed what later became the Ogg Theora format. Back in May, Google made On2’s new format, called VP8, royalty-free to use. That would be a third possible HTML5 video format. Chrome, Firefox, and Opera offer varying levels of support for the VP8; Microsoft announced tentative plans to do so by the time Internet Explorer 9 ships, but Apple was silent on the subject.

All that background brings us back to Thursday’s announcement by MPEG LA that it will never charge any royalties for Internet video encoded using the H.264 standard, when the video is free to consumers. That December 31, 2015 expiration date for royalty-free use of H.264 is now history, and anyone can decode Internet video encoded in the format freely, in perpetuity.

There’s plenty of reason to rejoice at that, not least because oodles of HTML5 Web video is already using H.264. YouTube uses it in its HTML5 player, and any YouTube video you watch on your iPad or iPhone is encoded in the format. The same is true of Vimeo’s HTML5 player, and CNN’s, and ESPN’s, and Major League Baseball’s, and so on. And, of course, if Thursday’s announcement means that the Web will soon get even more H.264 HTML5 video, that’s more video you can consume with your iPhone and iPad, or other Flash-free mobile devices (which, at present, is many of them).

One hopes that with MPEG LA’s announcement, Mozilla and Opera will now feel comfortable supporting the H.264 codec, and HTML5 Web video can standardize on the format. That would mean that it would become easier and cheaper for publishers to create cross-platform, cross-browser HTML5 video; further reduce the Web’s reliance on proprietary Flash video; and make Flash-free mobile and desktop video-watching easier for browser makers, publishers, and consumers alike. Of course, folks like Ian Hickson would probably suggest that you never make assumptions about how browser makers will act.

But should Mozilla and Opera offer H.264 decoding in future versions of their browsers, the Web will finally have a universally-accepted, royalty-free, high-quality video codec for use everywhere.

http://www.macworld.com/article/153692/2010/08/h264_royalties.html

'Audio, Video Codec 라이센스' 카테고리의 다른 글

Sorenson / H.263 코덱 라이센스  (0) 2011.02.18
DivX® media format  (0) 2011.02.18
Xvid  (0) 2011.02.18
Adaptive Multi-Rate audio codec  (0) 2011.02.18
주관적 화질 평가: H.264/AVC vs VP8  (0) 2011.02.18

 

작성자
들풀

작성일
2011-02-15 (화) 17:28

ㆍ추천: 0  ㆍ조회: 55    

IP: 121.xxx.76

Samsung's Galaxy S II Preliminary Performance: Mali-400MP Benchmarked

출처 : http://www.anandtech.com/show/4177/samsungs-galaxy-s-ii-preliminary-performance-mali400-benchmarked

by Anand Lal Shimpi & Brian Klug on 2/14/2011 12:38:00 PM
Posted in Smartphones , Samsung , Galaxy S II , Orion , Exynos , ARM , Mali 400

There's a lot of speculation about the SoC used in Samsung's Galaxy S II,
thankfully through process of elimination and some snooping around we've been able to figure it out.
We know for sure it's not NVIDIA's Tegra 2 or Qualcomm. That leaves Samsung or TI.
A quick look at GLBenchmark2's output gives us the GPU string: ARM Mali 400.
TI's OMAP 4 uses a PowerVR SGX, so it's out of the running. This leaves one and only SoC:
Samsung's own Exynos 4210 (formerly Orion).
Exynos has two ARM Cortex A9 cores running at 1GHz. As a result, general performance
of the Galaxy S II is competitive with phones based on NVIDIA's Tegra 2.
The Galaxy S II runs Android 2.3.1 compared to 2.2.1 used by the Tegra 2 phones,
and as a result has better Javascript performance which we see in some of our benchmarks.

SunSpider Javascript Benchmark 0.9

Rightware BrowserMark

Physical Comparison

Apple iPhone 4
Samsung Galaxy
S Fascinate
LG Optimus 2X
Motorola Atrix 4G
Samsung Galaxy S II

Height
115.2 mm
(4.5")
106.17 mm
(4.18")
123.9 mm
(4.87")
117.8mm
125.3mm

Width
58.6 mm
(2.31")
63.5 mm
(2.5")
63.2 mm
(2.48")
63.5mm
66.1mm

Depth
9.3 mm ( 0.37")
9.91 mm (0.39")
10.9 mm (0.43")
10.95mm
8.48mm

Weight
137 g (4.8 oz)
127 grams
(4.5 oz)
139.0 grams
(4.90 oz)
135.0 grams
116 grams

CPU
Apple A4 @
~800MHz
1 GHz Samsung
Hummingbird
NVIDIA Tegra 2
Dual-Core
Cortex-A9
(AP20H) @ 1 GHz
NVIDIA Tegra 2
Dual-Core
Cortex-A9 (AP20H)
@ 1 GHz
Samsung Exynos
4210 Dual-Core
Cortex A9 @ 1GHz

GPU
PowerVR SGX 535
PowerVR SGX
540
ULV GeForce @
100-300 MHz
ULV GeForce @
100-300 MHz
ARM Mali-400 MP

RAM
512MB LPDDR1 (?)
512 MB LPDDR1
512 MB LPDDR2
@ 600 MHz
data rate
1024 MB LPDDR2
@ 600 MHz
data rate
1GB

NAND
16GB or 32GB
integrated
2 GB, 16 GB
microSD
(Class 2)
8 GB integrated
(5.51 GB internal SD,
1.12 phone storage),
up to 32 microSD
16 GB integrated,
up to 32 microSD
16 GB integrated,
up to 32 microSD

Camera
5MP with LED
Flash + Front
Facing Camera
5 MP with auto
focus
and LED flash
8 MP with
autofocus,
LED flash,
1080p24
video recording,
1.3 MP front facing
5 MP with
autofocus,
LED flash,
720p video
recording,
VGA MP front
facing
8 MP with
autofocus,
LED flash,
1080p video
recording,
2MP front facing

Screen
3.5" 640 x 960
LED backlit LCD
4" Super
AMOLED
800 x 480
4" IPS LCD
800 x 480
4" PenTile LCD
960 x 540
4.3" Super
AMOLED
Plus 800x480

The GPU accelerated UI used in Android 2.3.1 makes the Galaxy S II feel a bit faster than the Tegra 2 phones,
however that's not always the case. While web page loading feels comparable between the Atrix 4G
and the Samsung Galaxy S II, Tegra 2 appears to handle flash a bit better than Samsung's Exynos.

Flash Performance
This is a pretty significant difference in our Flash benchmark, however it does translate into
a somewhat less smooth experience when scrolling around web pages with Flash.
We managed to run GLBenchmark2 on the Samsung Galaxy S II and compared it to our recently
reviewed/previewed Tegra 2 smartphones.

GLBenchmark 2.0 - Egypt

GLBenchmark 2.0 - PRO
The Mali-400 MP performs pretty well in GLBenchmark2, however it's still a bit behind NVIDIA's Tegra 2.
Note that the Galaxy S II runs at 800 x 480 so its direct competitor in this case would be the Optimus 2X.
These results don't tell us a lot about the GPU's performance other than the combination of hardware and
drivers isn't quite up to par with what NVIDIA has today - at least under GLBenchmark2.
There's so much that can be done with driver optimizations that it's difficult to draw any meaningful conclusions yet

http://www.kandroid.org/board/board.php?board=HTCDream&command=body&no=132

+ Recent posts