Re: [rtcweb] Discussion on codec choices from a developer who doesn't come to IETF

This "SW encoding chews battery" claim is often mentioned, but in a video
chat, the power draw from the screen and network are often 10x the CPU
power draw, which is typically < 1W (for ARM). So there is very little
impact on talk time between HW and SW encode.

Mobile devices are often limited in terms of what resolutions they can
encode in software, because they have less overall compute power than PCs.
In my experience, that is the factor to consider, not battery life.

On Fri, May 4, 2012 at 6:56 PM, Bernard Aboba <bernard_aboba@hotmail.com>wrote:

>
> > I am more worried about the guy implementing a WebRTC security camera
> > that uses an embedded Linux kernel and a software video encoder. Each
> > unit might "produce" video 24x7. But there is no MPEG-LA licensed
> > browser or OS or encoder chip to fall back on. The whole product might
> > sell for less than it might cost him to license the codec.
>
> [BA]  We are rapidly moving toward inclusion of hardware video
> encode/decode by default on battery-powered devices (mobile handsets,
> tablets, etc.).
>
> Since software encode/decode is processor (and battery) intensive, the
> latest generation of webcams have video encode/decode built-in.  For
> example, see:
>
> http://www.ehomeupgrade.com/2011/06/02/skype-certified-webcams-tote-built-in-720p-h-264-video-encoders/
>
> When handled purely in software, it is quite difficult to enable video
> sessions of substantial duration without draining the battery.
>
> While my assumption is that hardware support for encode/decode will become
> less codec-specific over time,  that is typically not the case today.
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>