HW Video Acceleration in Chrom{e,ium}{,OS}

Ami Fischman <fischman@chromium.org>

Status as of 2014/06/06: Up-to-date

(could use some more details)

Introduction

Design

Implementation Details

Current Status

Decode

Encode

Results

Introduction

Video decode (e.g. YouTube playback) and encode (e.g. video chat applications) are some of the most complex compute operations on the modern web.  Moving these operations from software running on general-purpose CPUs to dedicated hardware blocks means lower power consumption, longer battery life, higher quality (e.g. HD instead of SD), and better interactive performance as the CPU is freed up to work on everything else it needs to do.

Design

media::VideoDecodeAccelerator (VDA) and media::VideoEncodeAccelerator (VEA) (with their respective Client subclasses) are the interfaces at the center of all video HW acceleration in Chrome.  Each consumer of HW acceleration implements the relevant Client interface and calls an object of the relevant V[DE]A interface.

In general the classes that want to encode or decode video live in the renderer process (e.g. the <video> player, or WebRTC’s video encoders & decoders) and the HW being utilized is not accessible from within the renderer process, so IPC is used to bridge the renderer<->GPU process gap.

Implementation Details

The main consumers of the acceleration APIs are: <video> pipeline (what plays media on the web), WebRTC (enabling plugin-free real-time video chat on the web), and Pepper API (offering HW acceleration to pepper plugins such as Adobe Flash).

The implementations of the acceleration APIs are specific to the OS (and sometimes HW platform) due to radically different options offered by the OS and drivers/HW present.

(not pictured: obsolete OpenMAX-IL-based OVDA, and never-launched MacVDA).

Current Status

New devices are released all the time so this list is likely already out of date, but as of early June 2014, existing (public) support includes:

Decode

  • Windows: starting with Windows 7, HW accelerated decode of h.264 is used via DXVAVDA.

  • CrOS/Intel (everything post-Mario/Alex/ZGB): HW accelerated decode of h.264 is used via VAVDA

  • CrOS/ARM: HW accelerated decode of VP8 and h.264 is available via V4L2VDA

  • Android: HW accelerated decode of VP8 is available on N10, N5, some S4’s, and a bunch of other devices.  (note that on Android this only applies to WebRTC, as there is no PPAPI and <video> uses the platform’s player)

Encode

  • CrOS/ARM: HW accelerated encode of h.264 (everywhere) and VP8 (2014 devices) is available via V4L2VEA

  • Android: HW accelerated encode of VP8 is available on N5.

Results

Generally speaking offloading encode or decode from CPU to specialized HW has shown an overall battery-life extension of 10-25% depending on the platform, workload, etc.  For some data examples see:

Chromium Graphics: HW Video Acceleration in Chrom{e,ium}{,OS}的更多相关文章

  1. 【Chromium中文文档】Chrom{e,ium}{,OS}中的硬件视频加速

    Chrom{e,ium}{,OS}中的硬件视频加速 转载请注明出处:https://ahangchen.gitbooks.io/chromium_doc_zh/content/zh//General_ ...

  2. HW Video Acceleration in Chrome/Chromium HTML5 video 视频播放硬件加速

    Introduction Video decode (e.g. YouTube playback) and encode (e.g. video chat applications) are some ...

  3. Chromium Graphics: Video Playback and Compositor

    Video Playback and Compositor Authors: jamesr@chromium.org, danakj@chromium.org The Chromium composi ...

  4. Chromium Graphics : GPU Accelerated Compositing in Chrome

    GPU Accelerated Compositing in Chrome Tom Wiltzius, Vangelis Kokkevis & the Chrome Graphics team ...

  5. Chromium Graphics: Compositor Thread Architecture

    Compositor Thread Architecture <jamesr, enne, vangelis, nduca> @chromium.org Goals The main re ...

  6. Chromium Graphics: GPUclient的原理和实现分析之间的同步机制-Part II

    摘要:Part I探析GPUclient之间的同步问题,以及Chromium的GL扩展同步点机制的基本原理.本文将源码的角度剖析同步点(SyncPoint)机制的实现方式. 同步点机制的实现主要涉及到 ...

  7. Chromium Graphics Update in 2014(滑动)

    原创文章,转载请注明为链接原始来源对于http://blog.csdn.net/hongbomin/article/details/40897433. 摘要:Chromium图形栈在2014年有多项改 ...

  8. Chromium Graphics: GPUclient的原理和实现分析之间的同步机制-Part I

    摘要:Chromium于GPU多个流程架构的同意GPUclient这将是这次访问的同时GPU维修,和GPUclient这之间可能存在数据依赖性.因此必须提供一个同步机制,以确保GPU订购业务.本文讨论 ...

  9. Chromium Graphics: Aura

    Aura (obsolete) This document is still good for a high level overview, with contact information, but ...

随机推荐

  1. 在oracle中采用connect by prior来实现递归查询

    注明:该文章为引用别人的文章,链接为:http://blog.csdn.net/apicescn/article/details/1510922 , 记录下来只是为了方便查看 原文: connect ...

  2. Linux 进程间通信(IPC)

    Linux 进程间通信(IPC): Linux系统中除了进程和进程之间通信,我想大家也应该关注用户空间与内核空间是怎样通信的.例如说netlink等等. 除了传统进程间通信外像Socket通信也须要掌 ...

  3. hdu 1166 敌兵布阵 (线段树单点更新)

    敌兵布阵                                                         Time Limit: 2000/1000 MS (Java/Others)  ...

  4. less04 运算符、命名空间

    less //.wp{ // margin: 0 auto; // background: forestgreen; // width: 450px + 450; //有一个有单位就可以 // hei ...

  5. zzulioj--1817--match number(水题)

    1817: match number Time Limit: 1 Sec  Memory Limit: 128 MB Submit: 98  Solved: 45 SubmitStatusWeb Bo ...

  6. Format operator

    The argument of write has to be a string, so if we want to put other values in a file, we have to co ...

  7. Find and counter

    Find: In a sense, find is the opposite of the [] operator. Instead of taking an index and extracting ...

  8. 数据库表的连接(Left join , Right Join, Inner Join)用法详解

    转自:http://blog.csdn.net/jetjetlinuxsystem/article/details/6663218 Left Join, Inner Join 的相关内容,非常实用,对 ...

  9. FLUME KAFKA SOURCE 和 SINK 使用同一个 TOPIC

    FLUME KAFKA SOURCE 和 SINK 使用同一个 TOPIC 最近做了一个事情,过滤下kakfa中的数据后,做这个就用到了flume,直接使用flume source 和 flume s ...

  10. 机器学习(四) 机器学习(四) 分类算法--K近邻算法 KNN (下)

    六.网格搜索与 K 邻近算法中更多的超参数 七.数据归一化 Feature Scaling 解决方案:将所有的数据映射到同一尺度 八.scikit-learn 中的 Scaler preprocess ...