[kalleboo]

I don't know why this got downvoted - we all know it's true, even if we don't want it to be.

Does anyone really believe Apple are going to support a codec that they can't hand off to power-saving silicone?

edit: it was gray when I replied

[spot]

why can't apple hand off vp8 to silicon?

http://www.webmproject.org/hardware/

[jfb]

Why should they, if they have to support H.264 encode/decode in hardware already? WebM hardware support would be an extra cost, and you'd better believe that they've got those parts spec'd down to the fraction of a cent. WebM offers nothing to Apple -- certainly not video quality, and they participate in the MPEGLA patent pools, so they're not paying for the licensing.

If WebM became a mandatory codec, they'd implement it, but they'd prefer not to.

[ksec]

Being in Patents Pools doesn't mean they dont need to pay licensing. It just means they are on both paying and receiving ends. Since there are thousands of patents on H.264, Apple are only recieiving a tiny amount compared to what they paid out.

[wmf]

Does the A4/A5 support WebM?

[ZeroGravitas]

The Google WebRTC team argue that differential between encoding and decoding video at web-conferencing rates is negligible compared with having the screen turned on and sending and receiving data so I wouldn't accept that argument from Apple without some numbers.

[ZeroGravitas]

And the latest post to the mailing list provides some numbers for the other side:

http://www.ietf.org/mail-archive/web/rtcweb/current/msg04980...

"To summarize, using a single core of the iPad3's dual core processor, software decoding of HEVC (forthcoming H.265) at 720p30 resolution and 1.5 Mbit/s bitrate is possible. A fully charged battery is empty after 8 hours. This compares to 10 hours when decoding H.264 using hardware acceleration. My take from this data point is that battery life is not all that much affected by hardware-based decoding, at least not for tablets and larger devices. If your screen and battery are considerably smaller, but your processing demands similar, hardware decoding may become more beneficial, relatively speaking. However, if you scale down video resolution with screen size, things ought to be approximately in the same ballpark.

While at this discussion, let me reiterate two other points made in the meeting. First, AFAIK, there are no hardware-accelerated encoders in today's products that could meaningfully be used for conversational applications; encoders run software-only, and their complexity is necessarily considerably higher than that of a decoder (because an encoder includes all features of a decoder exept the entropy decoding, plus all the search/mode decision mechanics, forward transform/quantization, assorted filters i.e. for motion compensation, and the entropy encoder). And second, today's hardware based decoding is not well suited for video conference decoding use, as it does not offer functionalities such as error control or concealment beyond re-sychronization after IDR pictures—and one should avoid IDR pictures in conversational applications because of their size and resulting delay."