diff --git a/src/devices/devices_toc.cs b/src/devices/devices_toc.cs
index 0dc2b03..9674d2b 100644
--- a/src/devices/devices_toc.cs
+++ b/src/devices/devices_toc.cs
@@ -395,6 +395,7 @@
         <ul>
           <li><a href="<?cs var:toroot ?>devices/tech/display/dnd.html">Do Not Disturb</a></li>
           <li><a href="<?cs var:toroot ?>devices/tech/display/multi-window.html">Multi-Window</a></li>
+          <li><a href="<?cs var:toroot ?>devices/tech/display/hdr.html">HDR Video</a></li>
         </ul>
       </li>
 
diff --git a/src/devices/tech/display/hdr.jd b/src/devices/tech/display/hdr.jd
new file mode 100644
index 0000000..2062a37
--- /dev/null
+++ b/src/devices/tech/display/hdr.jd
@@ -0,0 +1,700 @@
+page.title=HDR Video Playback
+@jd:body
+
+<!--
+    Copyright 2015 The Android Open Source Project
+
+    Licensed under the Apache License, Version 2.0 (the "License");
+    you may not use this file except in compliance with the License.
+    You may obtain a copy of the License at
+
+        http://www.apache.org/licenses/LICENSE-2.0
+
+    Unless required by applicable law or agreed to in writing, software
+    distributed under the License is distributed on an "AS IS" BASIS,
+    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+    See the License for the specific language governing permissions and
+    limitations under the License.
+-->
+<div id="qv-wrapper">
+  <div id="qv">
+    <h2>In this document</h2>
+    <ol id="auto-toc">
+    </ol>
+  </div>
+</div>
+
+<p>High dynamic range (HDR) video is the next frontier in high-quality
+video decoding, bringing unmatched scene reproduction qualities. It does
+so by significantly increasing the dynamic range of the luminance component
+(from the current 100 cd/m<sup>2</sup> to 1000s of cd/m<sup>2</sup>) and by using a much wider
+color space (BT 2020). This is now a central element of the 4K UHD evolution
+in the TV space.</p>
+
+<p>In Android 7.0, initial HDR support has been added, which includes the
+creation of proper constants for the discovery and setup of HDR video
+pipelines. That means defining codec types and display modes and specifying
+how HDR data must be passed to MediaCodec and supplied to HDR decoders. HDR
+is only supported in tunneled video playback mode.</p>
+
+<p>The purpose of this document is to help application developers support HDR stream
+playback, and help OEMs and SOCs enable the HDR features on Android 7.0.</p>
+
+<h2 id="technologies">Supported HDR technologies</h2>
+
+<p>As of Android 7.0 release, the following HDR technologies are supported.
+
+<table>
+<tbody>
+<tr>
+<th>Technology
+</th>
+<th>Dolby-Vision
+</th>
+<th>HDR10
+</th>
+<th>VP9-HLG
+</th>
+<th>VP9-PQ
+</th>
+</tr>
+<tr>
+<th>Codec
+</th>
+<td>AVC/HEVC
+</td>
+<td>HEVC
+</td>
+<td>VP9
+</td>
+<td>VP9
+</td>
+</tr>
+<tr>
+<th>Transfer Function
+</th>
+<td>ST-2084
+</td>
+<td>ST-2084
+</td>
+<td>HLG
+</td>
+<td>ST-2084
+</td>
+</tr>
+<tr>
+<th>HDR Metadata Type
+</th>
+<td>Dynamic
+</td>
+<td>Static
+</td>
+<td>None
+</td>
+<td>Static
+</td>
+</tr>
+</tbody>
+</table>
+
+<p>In Android 7.0, <b>only HDR playback via tunneled mode is defined</b>,
+but devices may add support for playback of HDR on SurfaceViews using opaque
+video buffers. In other words:</p>
+<ul>
+<li>There is no standard Android API to check if HDR playback is supported
+using non-tunneled decoders.</li>
+<li>Tunneled video decoders that advertise HDR playback capability must
+support HDR playback when connected to HDR-capable displays.</li>
+<li>GL composition of HDR content is not supported by the AOSP Android
+7.0 release.</li>
+</ul>
+
+<h2 id="discovery">Discovery</h2>
+
+<p>HDR Playback requires an HDR-capable decoder and a connection to an
+HDR-capable display. Optionally, some technologies require a specific
+extractor.</p>
+
+<h3 id="display">Display</h3>
+
+<p>Applications shall use the new <code>Display.getHdrCapabilities</code>
+API to query the HDR technologies supported by the specified display. This is
+basically the information in the EDID Static Metadata Data Block as defined
+in CTA-861.3:</p>
+
+<ul>
+<li><code>public Display.HdrCapabilities getHdrCapabilities()</code><br>
+Returns the display's HDR capabilities.</li>
+
+<li><code>public Display.HdrCapabilities getHdrCapabilities()</code><br>
+Returns the display's HDR capabilities.</li>
+
+<li><code>Display.HdrCapabilities</code><br>
+Encapsulates the HDR capabilities of a given display. For example, what HDR
+types it supports and details about the desired luminance data.</li>
+</ul>
+
+<p><b>Constants:</b></p>
+
+<ul>
+<li><code>int HDR_TYPE_DOLBY_VISION</code><br>
+Dolby Vision support.</li>
+
+<li><code>int HDR_TYPE_HDR10</code><br>
+HDR10 / PQ support.</li>
+
+<li><code>int HDR_TYPE_HLG</code><br>
+Hybrid Log-Gamma support.</li>
+
+<li><code>float INVALID_LUMINANCE</code><br>
+Invalid luminance value.</li>
+</ul>
+
+<p><b>Public Methods:</b></p>
+
+<ul>
+<li><code>float getDesiredMaxAverageLuminance()</code><br>
+Returns the desired content max frame-average luminance data in cd/cd/m<sup>2</sup> for
+this display.</li>
+
+<li><code>float getDesiredMaxLuminance()</code><br>
+Returns the desired content max luminance data in cd/cd/m<sup>2</sup> for this display.</li>
+
+<li><code>float getDesiredMinLuminance()</code><br>
+Returns the desired content min luminance data in cd/cd/m<sup>2</sup> for this display.</li>
+
+<li><code>int[] getSupportedHdrTypes()</code><br>
+Gets the supported HDR types of this display (see constants). Returns empty
+array if HDR is not supported by the display.</li>
+</ul>
+
+<h3 id="decoder">Decoder</h3>
+
+<p>Applications shall use the existing 
+<a href="https://developer.android.com/reference/android/media/MediaCodecInfo.CodecCapabilities.html#profileLevels">
+<code>CodecCapabilities.profileLevels</code></a> API to verify support for the 
+new HDR capable profiles:</p>
+
+<h4>Dolby-Vision</h4>
+
+<p><code>MediaFormat</code> mime constant:
+<blockquote><pre>
+String MIMETYPE_VIDEO_DOLBY_VISION
+</pre></blockquote></p>
+
+<p><code>MediaCodecInfo.CodecProfileLevel</code> profile constants:</p>
+<blockquote><pre>
+int DolbyVisionProfileDvavPen
+int DolbyVisionProfileDvavPer
+int DolbyVisionProfileDvheDen
+int DolbyVisionProfileDvheDer
+int DolbyVisionProfileDvheDtb
+int DolbyVisionProfileDvheDth
+int DolbyVisionProfileDvheDtr
+int DolbyVisionProfileDvheStn
+</pre></blockquote>
+
+<p>Dolby Vision video layers and metadata must be concatenated into a single
+buffer per frames by video applications. This is done automatically by the
+Dolby-Vision capable MediaExtractor.</p>
+
+<h4>HEVC HDR 10</h4>
+
+<p><code>MediaCodecInfo.CodecProfileLevel</code> profile constants:<p>
+<blockquote><pre>
+int HEVCProfileMain10HDR10
+</pre></blockquote>
+
+<h4>VP9 HLG & PQ</h4>
+
+<p><code>MediaCodecInfo.CodecProfileLevel</code> profile
+constants:</p>
+<blockquote><pre>
+int VP9Profile2HDR
+int VP9Profile3HDR
+</pre></blockquote>
+
+<p>If a platform supports an HDR-capable decoder, it shall also support an
+HDR-capable extractor.</p>
+
+<p>Only tunneled decoders are guaranteed to play back HDR content. Playback
+by non-tunneled decoders may result in the HDR information being lost and
+the content being flattened into an SDR color volume.</p>
+
+<h3 id="extractor">Extractor</h3>
+
+<p>The following containers are supported for the various HDR technologies
+on Android 7.0:</p>
+
+<table>
+<tbody>
+<tr>
+<th>Technology
+</th>
+<th>Dolby-Vision
+</th>
+<th>HDR10
+</th>
+<th>VP9-HLG
+</th>
+<th>VP9-PQ
+</th>
+</tr>
+<tr>
+<th>Container
+</th>
+<td>MP4
+</td>
+<td>MP4
+</td>
+<td>WebM
+</td>
+<td>WebM
+</td>
+</tr>
+</tbody>
+</table>
+
+<p>Discovery of whether a track (of a file) requires HDR support is not
+supported by the platform. Applications may parse the codec-specific data
+to determine if a track requires a specific HDR profile.</p>
+
+<h3 id ="summary">Summary</h3>
+
+<p>Component requirements for each HDR technology are shown in the following table:</p>
+
+<div style="overflow:auto">
+<table>
+<tbody>
+<tr>
+<th>Technology
+</th>
+<th>Dolby-Vision
+</th>
+<th>HDR10
+</th>
+<th>VP9-HLG
+</th>
+<th>VP9-PQ
+</th>
+</tr>
+<tr>
+<th>Supported HDR type (Display)
+</th>
+<td>HDR_TYPE_DOLBY_VISION
+</td>
+<td>HDR_TYPE_HDR10
+</td>
+<td>HDR_TYPE_HLG
+</td>
+<td>HDR_TYPE_HDR10
+</td>
+</tr>
+<tr>
+<th>Container (Extractor)
+</th>
+<td>MP4
+</td>
+<td>MP4
+</td>
+<td>WebM
+</td>
+<td>WebM
+</td>
+</tr>
+<tr>
+<th>Decoder
+</th>
+<td>MIMETYPE_VIDEO_DOLBY_VISION
+</td>
+<td>MIMETYPE_VIDEO_HEVC
+</td>
+<td>MIMETYPE_VIDEO_VP9
+</td>
+<td>MIMETYPE_VIDEO_VP9
+</td>
+</tr>
+<tr>
+<th>Profile (Decoder)
+</th>
+<td>One of the Dolby profiles
+</td>
+<td>HEVCProfileMain10HDR10
+</td>
+<td>VP9Profile2HDR or
+VP9Profile3HDR
+</td>
+<td>VP9Profile2HDR or
+VP9Profile3HDR
+</td>
+</tr>
+</tbody>
+</table>
+</div>
+<br>
+
+<p>Notes:</p>
+<ul>
+<li>Dolby-Vision bitstreams are packaged in an MP4 container in a way defined
+by Dolby. Applications may implement their own Dolby-capable extractors as
+long as they package the access units from the corresponding layers into a
+single access unit for the decoder as defined by Dolby.</li>
+<li>A platform may support an HDR-capable extractor, but no corresponding
+HDR-capable decoder.</li>
+</ul>
+
+<h2 id="playback">Playback</h2>
+
+<p>After an application has verified support for HDR playback, it can play
+back HDR content nearly the same way as it plays back non-HDR content,
+with the following caveats:</p>
+
+<ul>
+<li>For Dolby-Vision, whether or not a specific media file/track requires
+an HDR capable decoder is not immediately available. The application must
+have this information in advance or be able to obtain this information by
+parsing the codec-specific data section of the MediaFormat.</li>
+<li><code>CodecCapabilities.isFormatSupported</code> does not consider whether
+the tunneled decoder feature is required for supporting such a profile.</li>
+</ul>
+
+<h2 id="enablinghdr">Enabling HDR platform support</h2>
+
+<p>SoC vendors and OEMs must do additional work to enable HDR platform
+support for a device.</p>
+
+<h3 id="platformchanges">Platform changes in Android 7.0 for HDR</h3>
+
+<p>Here are some key changes in the platform (Application/Native layer)
+that OEMs and SOCs need to be aware of.</p>
+
+<h3 id="display">Display</h3>
+
+<h4>Hardware composition</h4>
+
+<p>HDR-capable platforms must support blending HDR content with non-HDR
+content. The exact blending characteristics and operations are not defined
+by Android as of release 7.0, but the process generally follows these steps:</p>
+<ol>
+<li>Determine a linear color space/volume that contains all layers to be
+composited, based on the layers' color, mastering, and potential dynamic
+metadata.
+<br>If compositing directly to a display, this could be the linear space
+that matches the display's color volume.</li>
+<li>Convert all layers to the common color space.</li>
+<li>Perform the blending.</li>
+<li>If displaying through HDMI:
+<ol style="list-style-type: lower-alpha">
+<li>Determine the color, mastering, and potential dynamic metadata for the
+blended scene.</li>
+<li>Convert the resulting blended scene to the derived color
+space/volume.</ol></li>
+<li>If displaying directly to the display, convert the resulting blended
+scene to the required display signals to produce that scene.
+</ol></li>
+</ol>
+
+<h4>Display discovery</h4>
+
+<p>HDR display discovery is only supported via HWC2. Partners must selectively
+enable the HWC2 adapter that is released with Android 7.0 for this feature
+to work. Therefore, platforms must add support for HWC2 or extend the AOSP
+framework to allow a way to provide this information. HWC2 exposes a new
+API to propagate HDR Static Data to the framework and the application.</p>
+
+<h4>HDMI</h4>
+
+<ul>
+<li>A connected HDMI display advertises
+its HDR capability through HDMI EDID as defined in CTA-861.3
+section 4.2.</li>
+<li>The following EOTF mapping shall be used:<ul>
+<li>ET_0 Traditional gamma - SDR Luminance Range: not mapped to any HDR
+type</li>
+<li>ET_1 Traditional gamma - HDR Luminance Range: not mapped to any HDR
+type</li>
+<li>ET_2 SMPTE ST 2084 - mapped to HDR type HDR10</ul></li>
+<li>The signaling of Dolby Vision or HLG support over HDMI is done as defined
+by their relevant bodies.</li>
+<li>Note that the HWC2 API uses float desired luminance values, so the 8-bit
+EDID values must be translated in a suitable fashion.</ul></li>
+</ul>
+
+<h3 id="decoders">Decoders</h3>
+
+<p>Platforms must add HDR-capable tunneled decoders and advertise their HDR
+support. Generally, HDR-capable decoders must:</p>
+<ul>
+<li>Support tunneled decoding (<code>FEATURE_TunneledPlayback</code>).</li>
+<li>Support HDR static metadata
+(<code>OMX.google.android.index.describeHDRColorInfo</code>) and its
+propagation to the display/hardware composition. For HLG, appropriate metadata
+must be submitted to the display.</li>
+<li>Support color description
+(<code>OMX.google.android.index.describeColorAspects</code>) and its
+propagation to the display/hardware composition.</li>
+<li>Support HDR embedded metadata as defined by the relevant standard.</li>
+</ul>
+
+<h4>Dolby Vision decoder support</h4>
+
+<p>To support Dolby Vision, platforms must add a Dolby-Vision capable
+HDR OMX decoder. Given the specifics of Dolby Vision, this is normally a
+wrapper decoder around one or more AVC and/or HEVC decoders as well as a
+compositor. Such decoders must:</p>
+<ul>
+<li>Support mime type "video/dolby-vision."</li>
+<li>Advertise supported Dolby Vision profiles/levels.</li>
+<li>Accept access units that contain the sub-access-units of all layers as
+defined by Dolby.</li>
+<li>Accept codec-specific data defined by Dolby. For example, data containing
+Dolby Vision profile/level and possibly the codec-specific data for the
+internal decoders.</li>
+<li>Support adaptive switching between Dolby Vision profiles/levels as
+required by Dolby.</li>
+</ul>
+
+<p>When configuring the decoder, the actual Dolby profile is not communicated
+to the codec. This is only done via codec-specific data after the decoder
+has been started. A platform could choose to support multiple Dolby Vision
+decoders: one for AVC profiles, and another for HEVC profiles to be able to
+initialize underlying codecs during configure time. If a single Dolby Vision
+decoder supports both types of profiles, it must also support switching
+between those dynamically in an adaptive fashion.</p>
+<p>If a platform provides a Dolby-Vision capable decoder in addition to the
+general HDR decoder support, it must:</p>
+
+<ul>
+<li>Provide a Dolby-Vision aware extractor, even if it does not support
+HDR playback.</li>
+<li>Provide a decoder that supports at least Dolby Vision profile X/level
+Y.</li>
+</ul>
+
+<h4>HDR10 decoder support</h4>
+
+<p>To support HDR10, platforms must add an HDR10-capable OMX decoder. This
+is normally a tunneled HEVC decoder that also supports parsing and handling
+HDMI related metadata. Such a decoder (in addition to the general HDR decoder
+support) must:</p>
+<ul>
+<li>Support mime type "video/hevc."</li>
+<li>Advertise supported HEVCMain10HDR10. HEVCMain10HRD10 profile support
+also requires supporting the HEVCMain10 profile, which requires supporting
+the HEVCMain profile at the same levels.</li>
+<li>Support parsing the mastering metadata SEI blocks, as well as other HDR
+related info contained in SPS.</li>
+</ul>
+
+<h4>VP9 decoder support</h4>
+
+<p>To support VP9 HDR, platforms must add a VP9 Profile2-capable HDR OMX
+decoder. This is normally a tunneled VP9 decoder that also supports handling
+HDMI related metadata. Such decoders (in addition to the general HDR decoder
+support) must:</p>
+<ul>
+<li>Support mime type "video/x-vnd.on2.vp9."</li>
+<li>Advertise supported VP9Profile2HDR. VP9Profile2HDR profile support also
+requires supporting VP9Profile2 profile at the same level.</li>
+</ul>
+
+<h3 id="extractors">Extractors</h3>
+
+<h4>Dolby Vision extractor support</h4>
+
+<p>Platforms that support Dolby Vision decoders must add Dolby extractor
+(called Dolby Extractor) support for Dolby Video content.</p>
+<ul>
+<li>A regular MP4 extractor can only extract the base layer from a file,
+but not the enhancement or metadata layers. So a special Dolby extractor is
+needed to extract the data from the file.</li>
+<li>The Dolby extractor must expose 1 to 2 tracks for each Dolby video track
+(group):
+<ul>
+<li>A Dolby Vision HDR track with the type of "video/dolby-vision" for the
+combined 2/3-layers Dolby stream. The HDR track's access-unit format, which
+defines how to package the access units from the base/enhancement/metadata
+layers into a single buffer to be decoded into a single HDR frame, is to be
+defined by Dolby.</li>
+<li>If a Dolby Vision video track contains a separate (backward compatible)
+base-layer (BL), the extractor must also expose this as a separate "video/avc"
+or "video/hevc" track. The extractor must provide regular AVC/HEVC access
+units for this track.</li>
+<li>The BL track must have the same track-unique-ID ("track-ID") as the
+HDR track so the app understands that these are two encodings of the same
+video.</li>
+<li>The application can decide which track to choose based on the platform's
+capability.</li>
+</ul>
+</li>
+<li>The Dolby Vision profile/level must be exposed in the track format of
+the HDR track.</li>
+<li>If a platform provides a Dolby-Vision capable decoder, it must also provide
+a Dolby-Vision aware extractor, even if it does not support HDR playback.</li>
+</ul>
+
+<h4>HDR10 and VP9 HDR extractor support</h4>
+
+<p>There are no additional extractor requirements to support HDR10 or VP9
+HLG. Platforms must extend MP4 extractor to support VP9 PQ in MP4. HDR
+static metadata must be propagated in the VP9 PQ bitstream, such that this
+metadata is passed to the VP9 PQ decoder and to the display via the normal
+MediaExtractor =&gt; MediaCodec pipeline.</p>
+
+<h3 id="stagefright">Stagefright extensions for Dolby Vision support</h3>
+
+<p>Platforms must add Dolby Vision format support to Stagefright:</p>
+<ul>
+<li>Support for port definition query for compressed port.</li>
+<li>Support profile/level enumeration for DV decoder.</li>
+<li>Support exposing DV profile/level for DV HDR tracks.</li>
+</ul>
+
+<h2 id="implementationnotes">Technology-specific implementation details</h2>
+
+<h3 id="hdr10decoder">HDR10 decoder pipeline</h3>
+
+<p><img src="../images/hdr10_decoder_pipeline.png"></p>
+
+<p class="img-caption"><strong>Figure 1.</strong> HDR10 pipeline</p>
+
+<p>HDR10 bitstreams are packaged in MP4 containers. Applications use a regular
+MP4 extractor to extract the frame data and send it to the decoder.</p>
+
+<ul>
+<li><b>MPEG4 Extractor</b><br>
+HDR10 bitstreams are recognized as just a normal HEVC stream by a
+MPEG4Extractor and the HDR track with the type "video/HEVC" will be
+extracted. The framework picks an HEVC video decoder that supports the
+Main10HDR10 profile to decode that track.</li>
+
+<li><b>HEVC Decoder</b><br>
+HDR information is in either SEI or SPS. The HEVC decoder first receives
+frames that contain the HDR information. The decoder then extracts the HDR
+information and notifies the application that it is decoding an HDR video. HDR
+information is bundled into decoder output format, which is propagated to
+the surface later.</li>
+</ul>
+
+<h4>Vendor actions</h4>
+<ol>
+<li>Advertise supported HDR decoder profile and level OMX type. Example:<br>
+<code>OMX_VIDEO_HEVCProfileMain10HDR10</code> (and <code>Main10</code>)</li>
+<li>Implement support for index:
+'<code>OMX.google.android.index.describeHDRColorInfo</code>'</li>
+<li>Implement support for index:
+'<code>OMX.google.android.index.describeColorAspects</code>'</li>
+<li>Implement support for SEI parsing of mastering metadata.</li>
+</ol>
+
+<h3 id="dvdecoder">Dolby Vision decoder pipeline</h3>
+
+<p><img src="../images/dolby_vision_decoder_pipleline.png"></p>
+
+<p class="img-caption"><strong>Figure 2.</strong> Dolby Vision pipeline</p>
+
+<p>Dolby-bitstreams are packaged in MP4 containers as defined by
+Dolby. Applications could, in theory, use a regular MP4 extractor to extract
+the base layer, enhancement layer, and metadata layer independently; however,
+this does not fit the current Android MediaExtractor/MediaCodec model.</p>
+
+<ul>
+<li>DolbyExtractor:
+<ul>
+<li>Dolby-bitstreams are recognized by a DolbyExtractor, which exposes the
+various layers as 1 to 2 tracks for each dolby video track (group):
+<ul>
+<li>An HDR track with the type of "video/dolby-vision" for the combined
+2/3-layers dolby stream. The HDR track's access-unit format, which defines
+how to package the access units from the base/enhancement/metadata layers
+into a single buffer to be decoded into a single HDR frame, is to be defined
+by Dolby.</li>
+<li>(Optional, only if the BL is backward compatible) A BL track contains
+only the base layer, which must be decodable by regular MediaCodec decoder,
+for example, AVC/HEVC decoder. The extractor should provide regular AVC/HEVC
+access units for this track. This BL track must have the same track-unique-ID
+("track-ID") as the Dolby track so the application understands that these
+are two encodings of the same video.</li>
+</ul>
+<li>The application can decide which track to choose based on the platform's
+capability.</li>
+<li>Because an HDR track has a specific HDR type, the framework will pick
+a Dolby video decoder to decode that track. The BL track will be decoded by
+a regular AVC/HEVC video decoder.</li>
+</ul>
+
+<li>DolbyDecoder:
+<ul>
+<li>The DolbyDecoder receives access units that contain the required access
+units for all layers (EL+BL+MD or BL+MD)</li>
+<li>CSD (codec specific data, such as SPS+PPS+VPS) information for the
+individual layers can be packaged into 1 CSD frame to be defined by
+Dolby. Having a single CSD frame is required.</li>
+</ul>
+</ul>
+
+<h4>Dolby actions</h4>
+<ol>
+<li>Define the packaging of access units for the various Dolby container
+schemes (e.g. BL+EL+MD) for the abstract Dolby decoder (i.e. the buffer
+format expected by the HDR decoder).</li>
+<li>Define the packaging of CSD for the abstract Dolby decoder.</li>
+</ol>
+
+<h4>Vendor actions</h4>
+<ol>
+<li>Implement Dolby extractor. This can also be done by Dolby.</li>
+<li>Integrate DolbyExtractor into the framework.  The entry point is
+<code>frameworks/av/media/libstagefright/MediaExtractor.cpp</code>.</li>
+<li>Declare HDR decoder profile and level OMX
+type. Example: <code>OMX_VIDEO_DOLBYPROFILETYPE</code> and
+<code>OMX_VIDEO_DOLBYLEVELTYP</code>.</li>
+<li>Implement support for index:
+<code>'OMX.google.android.index.describeColorAspects</code>'</li>
+<li>Propagate the dynamic HDR metadata to the app and surface in each
+frame. Typically this information must be packaged into the decoded frame
+as defined by Dolby, because the HDMI standard does not provide a way to
+pass this to the display.</li>
+</ol>
+
+<h3 id="v9decoder">VP9 decoder pipeline</h3>
+
+<p><img src="../images/vp9-pq_decoder_pipleline.png"></p>
+
+<p class="img-caption"><strong>Figure 3.</strong> VP9-PQ pipeline</p>
+
+<p>VP9 bitstreams are packaged in WebM containers in a way defined by WebM
+team. Applications need to use a WebM extractor to extract HDR metadata from
+the bitstream before sending frames to the decoder.</p>
+
+<ul>
+<li>WebM Extractor:
+<ul>
+<li>WebM Extractor extracts the HDR <a
+href="http://www.webmproject.org/docs/container/#colour">metadata</a>
+and frames from the <a
+href="http://www.webmproject.org/docs/container/#location-of-the-colour-element-in-an-mkv-file">
+container</a>.</li>
+</ul>
+
+<li>VP9 Decoder:
+<ul>
+<li>Decoder receives Profile2 bitstreams and decodes them as normal VP9
+streams.</li>
+<li>Decoder receives any HDR static metadata from the framework.</li>
+<li>Decoder receives static metadata via the bitstream access units for VP9
+PQ streams.</li>
+<li>VP9 decoder must be able to propagate the HDR static/dynamic metadata
+to the display.</li>
+</ul>
+</ul>
+
+<h4>Vendor Actions</h4>
+
+<ol>
+<li>Implement support for index:
+<code>OMX.google.android.index.describeHDRColorInfo</code></li>
+<li>Implement support for index:
+<code>OMX.google.android.index.describeColorAspects</code></li>
+<li>Propagate HDR static metadata</li>
+</ol>
diff --git a/src/devices/tech/images/dolby_vision_decoder_pipleline.png b/src/devices/tech/images/dolby_vision_decoder_pipleline.png
new file mode 100644
index 0000000..86cda40
--- /dev/null
+++ b/src/devices/tech/images/dolby_vision_decoder_pipleline.png
Binary files differ
diff --git a/src/devices/tech/images/hdr10_decoder_pipeline.png b/src/devices/tech/images/hdr10_decoder_pipeline.png
new file mode 100644
index 0000000..f0cf7dc
--- /dev/null
+++ b/src/devices/tech/images/hdr10_decoder_pipeline.png
Binary files differ
diff --git a/src/devices/tech/images/vp9-pq_decoder_pipleline.png b/src/devices/tech/images/vp9-pq_decoder_pipleline.png
new file mode 100644
index 0000000..a6fde12
--- /dev/null
+++ b/src/devices/tech/images/vp9-pq_decoder_pipleline.png
Binary files differ