Google statement on codecs(ietf.org) |
Google statement on codecs(ietf.org) |
Yeah, that'll fly.
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
http://www.ietf.org/mail-archive/web/rtcweb/current/msg04938...
No other companies so far, apparently.
Has anyone blogged the feasibility of hardware acceleration of Opus? I know they have an integer implementation already, but it seems we still don't even have Vorbis support anywhere...
But considering WebRTC could potentially ruin much of Skype's business, a cynical guess would be that they won't make this easy.
WebRTC is likely to increase Skype's business (assuming the do a WebRTC implementation), at the expense of traditional telecoms and conference call providers.
How so? Are their servers for sale and somehow they can license them so web clients can conference via them. Otherwise I don't get. Or are you assuming they will buckle and would be forced to implement the WebRTC protocol.
How?
Apparently Microsoft plans to use WebRTC in the Skype Web client [1]
Will Opus replace Vorbis in WebM as well, though?
Is Opus Mozilla's codec? I didn't know that. I thought it was Xiph's with an effort to create an IETF draft for it.
Isn't it closer now to "Microsoft's codec" since it uses SILK (Skype's codec) for speech mode. Last time I looked at it I thought it was Xiph's codec with an effort do create an IETF standard...
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."
WebRTC increases the potential market for all of those things by decreasing the friction - people won't even need to install the Skype client anymore.
If WebM became a mandatory codec, they'd implement it, but they'd prefer not to.