<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>H265.net &#187; Research</title>
	<atom:link href="http://www.h265.net/category/research/feed" rel="self" type="application/rss+xml" />
	<link>http://www.h265.net</link>
	<description>Witness the development of H.265</description>
	<lastBuildDate>Sun, 05 Feb 2012 02:39:13 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>Analysis of Coding Tools in HEVC Test Model (HM 1.0) – Inter Prediction</title>
		<link>http://www.h265.net/2010/12/analysis-of-coding-tools-in-hevc-test-model-hm-inter-prediction.html</link>
		<comments>http://www.h265.net/2010/12/analysis-of-coding-tools-in-hevc-test-model-hm-inter-prediction.html#comments</comments>
		<pubDate>Tue, 07 Dec 2010 08:55:38 +0000</pubDate>
		<dc:creator>Yu Liu</dc:creator>
				<category><![CDATA[Research]]></category>
		<category><![CDATA[HEVC]]></category>
		<category><![CDATA[HM]]></category>
		<category><![CDATA[JCT-VC]]></category>
		<category><![CDATA[MCP]]></category>
		<category><![CDATA[Software]]></category>

		<guid isPermaLink="false">http://www.h265.net/?p=921</guid>
		<description><![CDATA[<p style="text-align: justify"><em>[Update on 2011-02-15] The 12-tap DCT-based interpolation filter (high efficiency configuration) and 6-tap directional interpolation filter (low complexity configuration) for 1/4 luma sample will be replaced by 8-tap DCT-based interpolation filter for both HE and LC (JCTVC-D344) in the upcoming HM2.0. In addition, the bilinear interpolation filter for 1/8 chroma sample will be replaced by 4-tap DCT-based interpolation filter (JCTVC-D347) in the HM2.0.</em></p>
<p style="text-align: justify">Tools adopted in HM0.9 include 12-tap DCT-based interpolation filter (high efficiency configuration) and 6-tap directional interpolation filter (low complexity configuration) for 1/4 luma sample, bilinear interpolation filter for 1/8 chroma sample (both HE and LC), advanced motion vector prediction, bi-direction rounding control, bi-directional prediction for temporal level 0.</p>
<li><strong>12-tap DCT-based Interpolation Filter for luma (HE)</strong></li>
<p style="text-align: justify">Motion compensation is the key factor for high efficient video compressing, where fractional pel accuracy requir[......]</p><p class='read-more'><a href='http://www.h265.net/2010/12/analysis-of-coding-tools-in-hevc-test-model-hm-inter-prediction.html'>Read More...</a></p>]]></description>
		<wfw:commentRss>http://www.h265.net/2010/12/analysis-of-coding-tools-in-hevc-test-model-hm-inter-prediction.html/feed</wfw:commentRss>
		<slash:comments>5</slash:comments>
		</item>
		<item>
		<title>Analysis of Coding Tools in HEVC Test Model (HM 1.0) – Intra Prediction</title>
		<link>http://www.h265.net/2010/12/analysis-of-coding-tools-in-hevc-test-model-hm-intra-prediction.html</link>
		<comments>http://www.h265.net/2010/12/analysis-of-coding-tools-in-hevc-test-model-hm-intra-prediction.html#comments</comments>
		<pubDate>Wed, 01 Dec 2010 02:42:12 +0000</pubDate>
		<dc:creator>Yu Liu</dc:creator>
				<category><![CDATA[Research]]></category>
		<category><![CDATA[HEVC]]></category>
		<category><![CDATA[HM]]></category>
		<category><![CDATA[Intra Prediction]]></category>
		<category><![CDATA[JCT-VC]]></category>
		<category><![CDATA[Software]]></category>

		<guid isPermaLink="false">http://www.h265.net/?p=877</guid>
		<description><![CDATA[<p style="text-align: justify">The current intra prediction in HM unified two directional intra prediction methods, Arbitrary Direction Intra (ADI) introduced in <a href="http://wftp3.itu.int/av-arch/jctvc-site/2010_04_A_Dresden/JCTVC-A124.zip">JCTVC-A124 </a>and Angular Intra Prediction introduced in <a href="http://wftp3.itu.int/av-arch/jctvc-site/2010_04_A_Dresden/JCTVC-A119.zip">JCTVC-A119</a>, with simplification for parallel processing possibility, leading to a simplified unified intra prediction (<a href="http://wftp3.itu.int/av-arch/jctvc-site/2010_07_B_Geneva/JCTVC-B100.zip">JCTVC-B100</a>, <a href="http://phenix.int-evry.fr/jct/doc_end_user/documents/3_Guangzhou/wg11/JCTVC-C042-m18063-v1-JCTVC-C042.zip">JCTVC-C042</a>).</p>
<p style="text-align: justify">In current HM, unified intra prediction provides up to 34 directional prediction modes for different PUs. With the PU size of 4&#215;4, 8&#215;8, 16&#215;16, 32&#215;32, 64&#215;64, there are 17, 34, 34, 34, and 5 prediction modes available respectively. The prediction directions in the unified intra prediction have the angles of +/- [0, 2, 5, 9, 13, 17, 21, 26, 32]/32. The angle is given by displacement of the bottom row of the PU and the reference row above the PU in case of vertical prediction, or displacement of the rightmost column of the PU and the reference column left from the PU in case of horizontal prediction. Figure 1 shows an example of prediction directions for 32&#215;32 block size. Instead of different accuracy for different sizes, the reconstruction of the pixel uses the linear interpolation of the reference top or left samples at 1/32th pixel accuracy for all block size.</p>
<p style="text-align: center"><img class="aligncenter" style="float: none;margin-left: auto;margin-right: auto;border-width: 0px" src="http://www.h265.net/wp-content/uploads/2010/12/unified_intra_pred.png" border="0" alt="HM Decoder" width="640" />Figure 1. Available prediction directions in the unified intra prediction</p>
<p style="text-align: justify">Two arrays of reference samples are used in the unified intra prediction, corresponding to the row of samples lying above the current PU to be predicted, and the column of samples lying to the left of the same PU. Given a dominant prediction direction (horizontal or vertical), one of the reference arrays is defined to be the main array and the other array the side array. In the case of vertical prediction, the reference row above the PU is called the main array and the reference column to the left of the same PU is called the side array. In the case of horizontal prediction, the reference column to the left of the PU is called the main array and the reference row above the PU is called the side array.</p>
<p style="text-align: justify">When the intra prediction angle is positive, blue lines in Figure 1, only the samples from the main array are used for prediction. When the intra prediction angle is negative, red lines in Figure 1, a per-sample test should be performed to determine whether samples from the main or the side array should be used for prediction, as shown in Figure 2 (a). Additionally when the side array is used, the computation of the index into the side array requires a division operation. In order to remove the division operation, the lookup-table (LUT) technique is used for the negative angular prediction process in the calculation of the y-intercept in the case of vertical prediction or the x-intercept in the case of horizontal prediction. Normally, the integer and fractional parts of the intercept between are calculated using the following equations respectively:</p>
<p style="text-align: justify"><em>deltaIntSide = (256*32*(l+1)/absAng)&#62;&#62;8</em></p>
<p style="text-align: justify"><em>deltaFractSide = (256*32*(l+1)/absAng)%256</em></p>
<p style="text-align: justify">where <em>absAng</em> is the absolute value of intra prediction angle (=[ 2,    5,   9,  13,  17,  21,  26,  32]) and <em>l</em> is x/y pixel location for vertical/horizontal prediction. With LUT technique, the above equations can be replaced with the following equations:</p>
<p><em>deltaIntSide = (invAbsAngTable[absAngIndex]*(l+1))&#62;&#62;8</em></p>
<p><em>deltaFractSide = (invAbsAngTable[absAngIndex]*(l+1))%256</em></p>
<p style="text-align: justify">where invAbsAngTable = [4096, 1638, 910, 630, 482, 390, 315, 256]. By using LUT, there is no division operation during the computation of the index into the side array. However, there still exists the per-sample test to determine the main or the side array for prediction. To simplify this process, the main array is extended by projecting samples from the side array onto it according to the prediction direction, as shown in Figure 2 (b). During the projection, the fractional part of the intercept is omitted and the intercept is rounded to the nearest integer:</p>
<p><em>deltaInteger = (invAbsAngTable[absAngIndex]*(l+1)+128)&#62;&#62;8</em></p>
<p style="text-align: justify">Finally, the prediction process only uses the extended main array and the same simple linear interpolation formula to predict all samples in the PU. Figure 2 shows an example of simplified intra prediction with direction angle VER-8.</p>
<p style="text-align: center"><img class="aligncenter" style="float: none;margin-left: auto;margin-right: auto;border-width: 0px" src="http://www.h265.net/wp-content/uploads/2010/12/simplified_intra_pred.png" border="0" alt="HM Decoder" width="223" /></p>
<p style="text-align: center">Figure 2. An example of simplified intra prediction with direction angle VER-8</p>
<p style="text-align: justify">When DC mode is used in the intra prediction, the mean value of samples from both top row and left column is used for the DC prediction.</p>
<p style="text-align: justify">Table 1 summarizes the physical and logical mode indexes used in the bitstream and prediction functions respectively. Depending on the PU size, different numbers of prediction modes are available respectively, as listed in Table 2.</p>
<p style="text-align: center"> Table 1. Physical and logical mode indexes used in the bitstream and prediction functions respectively</p>
<table style="text-align: center" border="1" width="640">
<tbody>
<tr>
<td><strong>Index</strong></td>
<td>0</td>
<td>1</td>
<td>2</td>
<td>3</td>
<td>4</td>
<td>5</td>
<td>6</td>
<td>7</td>
<td>8</td>
<td>9</td>
<td>10</td>
<td>11</td>
</tr>
<tr>
<td><strong>Physical</strong></td>
<td>VER</td>
<td>HOR</td>
<td>DC</td>
<td>VER-8</td>
<td>VER-4</td>
<td>VER+4</td>
<td>VER+8</td>
<td>HOR-4</td>
<td>HOR+4</td>
<td>HOR+8</td>
<td>VER-6</td>
<td>VER-2</td>
</tr>
<tr>
<td><strong>Logical </strong></td>
<td>DC</td>
<td>VER-8</td>
<td>VER-7</td>
<td>VER-6</td>
<td>VER-5</td>
<td>VER-4</td>
<td>VER-3</td>
<td>VER-2</td>
<td>VER-1</td>
<td>VER</td>
<td>VER+1</td>
<td>VER+2</td>
</tr>
</tbody>
</table>
<p style="text-align: justify">[......]</p><p class='read-more'><a href='http://www.h265.net/2010/12/analysis-of-coding-tools-in-hevc-test-model-hm-intra-prediction.html'>Read More...</a></p>]]></description>
		<wfw:commentRss>http://www.h265.net/2010/12/analysis-of-coding-tools-in-hevc-test-model-hm-intra-prediction.html/feed</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>Analysis of Coding Tools in HEVC Test Model (HM 1.0) – Coding Structure</title>
		<link>http://www.h265.net/2010/11/analysis-of-coding-tools-in-hevc-test-model-hm-coding-structure.html</link>
		<comments>http://www.h265.net/2010/11/analysis-of-coding-tools-in-hevc-test-model-hm-coding-structure.html#comments</comments>
		<pubDate>Tue, 30 Nov 2010 07:28:24 +0000</pubDate>
		<dc:creator>Yu Liu</dc:creator>
				<category><![CDATA[Research]]></category>
		<category><![CDATA[HEVC]]></category>
		<category><![CDATA[HM]]></category>
		<category><![CDATA[JCT-VC]]></category>
		<category><![CDATA[Software]]></category>

		<guid isPermaLink="false">http://www.h265.net/?p=848</guid>
		<description><![CDATA[<p style="text-align: justify">The HEVC test model (HM) still belongs to block-based hybrid video coding framework, except that the macroblock is extended to larger size (up to 64&#215;64) compared with H.264/AVC. In order to facilitate syntax representation of block hierarchy, three block concepts are introduced: coding unit (CU), prediction unit (PU), and transform unit (TU). The overall coding structure is characterized by the various sizes of CU, PU and TU in a recursive manner, once the size of largest coding unit (LCU) and the hierarchical depth of CU are defined.</p>
<p style="text-align: justify">CU, the basic coding unit like the macroblock and sub-macroblock in H.264/AVC, can have various sizes but is restricted to be a square shape. Given the size and hierarchical depth of LCU, CU can be expressed in a recursive quadtree representation adapted to the picture. Figure 1 (b) shows maximum possible recursive CU structure in HM (LCU size = 64 and hierarchical depth = 4). In HM, the coding unit tree structure is limited from 8&#215;8 to 64&#215;[......]</p><p class='read-more'><a href='http://www.h265.net/2010/11/analysis-of-coding-tools-in-hevc-test-model-hm-coding-structure.html'>Read More...</a></p>]]></description>
		<wfw:commentRss>http://www.h265.net/2010/11/analysis-of-coding-tools-in-hevc-test-model-hm-coding-structure.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Analysis of Coding Tools in HEVC Test Model (HM 1.0) – Overview</title>
		<link>http://www.h265.net/2010/11/analysis-of-coding-tools-in-hevc-test-model-hm-overview.html</link>
		<comments>http://www.h265.net/2010/11/analysis-of-coding-tools-in-hevc-test-model-hm-overview.html#comments</comments>
		<pubDate>Wed, 17 Nov 2010 17:19:15 +0000</pubDate>
		<dc:creator>Yu Liu</dc:creator>
				<category><![CDATA[Research]]></category>
		<category><![CDATA[HEVC]]></category>
		<category><![CDATA[HM]]></category>
		<category><![CDATA[JCT-VC]]></category>
		<category><![CDATA[Software]]></category>

		<guid isPermaLink="false">http://www.h265.net/?p=808</guid>
		<description><![CDATA[<p style="text-align: justify;">The HEVC test model (HM) was formally established in the 3rd JCT-VC meeting in Guangzhou, China. HM only contains the minimum set of well tested tools together from a coherent design that is confirmed to show good capability, meanwhile it also follows the “one tool one functionality“ approach. It expects to closely resemble the performance of best–performing proposals, as TMuC did, and plans to contain different clusters of tools (could become a seed for profile in future) with as much commonality as possible. Currently, two configurations of typical coding tools are suggested: High Efficiency and Low Complexity, as listed in the following table.</p>
<p style="text-align: center;">Table 1. Structure of tools forming the high efficiency and low complexity configurations of the HM</p>



<strong>High Efficiency</strong>
<strong>Low Complexity</strong>


Coding unit tree structure (8&#215;8 up to 64&#215;64 luma samples)


Prediction units


Transform unit tree structure (maximum of 3 levels)
Transform unit tree structure (maximum of 2 levels)


Transform bloc[......]<p class='read-more'><a href='http://www.h265.net/2010/11/analysis-of-coding-tools-in-hevc-test-model-hm-overview.html'>Read More...</a></p>]]></description>
		<wfw:commentRss>http://www.h265.net/2010/11/analysis-of-coding-tools-in-hevc-test-model-hm-overview.html/feed</wfw:commentRss>
		<slash:comments>23</slash:comments>
		</item>
		<item>
		<title>Two Loop Filters in KTA</title>
		<link>http://www.h265.net/2010/08/two-loop-filters-in-kta.html</link>
		<comments>http://www.h265.net/2010/08/two-loop-filters-in-kta.html#comments</comments>
		<pubDate>Sun, 01 Aug 2010 02:00:09 +0000</pubDate>
		<dc:creator>Jie Dong</dc:creator>
				<category><![CDATA[Research]]></category>
		<category><![CDATA[Adaptive Filtering]]></category>
		<category><![CDATA[KTA]]></category>
		<category><![CDATA[Loop Filter]]></category>

		<guid isPermaLink="false">http://www.h265.net/?p=753</guid>
		<description><![CDATA[<p style="text-align: justify;">KTA employs two concatenating loop filters: the deblocking loop filter and the adaptive loop filter.</p>
<p style="text-align: justify;">The deblocking loop filter, inherited from H.264/AVC, alleviates the blocking artifacts caused by the block-based DCT+MCP video coding framework. It uses a bank of low-pass filters, which are adaptively applied to block boundaries according to the boundary strength (BS), and provides better visual quality and improved capability to predict other pictures.</p>
<p style="text-align: justify;">Adaptive loop filter (ALF; click <a href="http://www.h265.net/2009/08/adaptive-post-loop-filters-in-jmkta-part-2.html">here</a> for introduction) is placed in the MCP loop after the deblocking process, and is used to restore the degraded picture (caused by compression) such that the MSE between the reconstructed and source frames is minimized. The coefficients of ALF are calculated and transmitted on a frame basis and the <a href="http://en.wikipedia.org/wiki/Minimum_mean-square_error">minimum mean squared error (MMSE) estimator</a> is used. For each degraded frame, ALF can be applied to the entire frame or to local areas. The former is known as frame-based ALF. In the latter case, additiona[......]</p><p class='read-more'><a href='http://www.h265.net/2010/08/two-loop-filters-in-kta.html'>Read More...</a></p>]]></description>
		<wfw:commentRss>http://www.h265.net/2010/08/two-loop-filters-in-kta.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Adaptive Interpolation Filter for Video Coding</title>
		<link>http://www.h265.net/2010/07/adaptive-interpolation-filter-for-video-coding.html</link>
		<comments>http://www.h265.net/2010/07/adaptive-interpolation-filter-for-video-coding.html#comments</comments>
		<pubDate>Wed, 21 Jul 2010 10:10:13 +0000</pubDate>
		<dc:creator>Jie Dong</dc:creator>
				<category><![CDATA[Research]]></category>
		<category><![CDATA[Adaptive Filtering]]></category>
		<category><![CDATA[KTA]]></category>
		<category><![CDATA[MCP]]></category>

		<guid isPermaLink="false">http://www.h265.net/?p=248</guid>
		<description><![CDATA[<p style="text-align: left"><strong>Why use interpolation in video coding?</strong>  </p>
<p style="text-align: justify">Motion-compensated prediction (MCP) is the key to the success of the modern video coding standards, as it removes the temporal redundancy in video signals and reduces the size of bitstreams significantly. With MCP, the pixels to be coded are predicted from the temporally neighboring ones, and only the prediction errors and the motion vectors (MV) are transmitted. However, due to the finite sampling rate, the actual position of the prediction in the neighboring frames may be out of the sampling grid, where the intensity is unknown, so the intensities of the positions in between the integer pixels, called sub-positions, must be interpolated and the resolution of MV is increased accordingly.  </p>
<p style="text-align: justify"><strong>Interpolation in H.264/AVC</strong>  </p>
<p style="text-align: justify">In H.264/AVC, for the resolution of MV is quarter-pixel, the reference frame is interpolated to be 16 times the size for MCP, 4 times both sides. As shown in Fig. 1(a), the interpolation defined in H.264 includes two stages, inter[......]</p><p class='read-more'><a href='http://www.h265.net/2010/07/adaptive-interpolation-filter-for-video-coding.html'>Read More...</a></p>]]></description>
		<wfw:commentRss>http://www.h265.net/2010/07/adaptive-interpolation-filter-for-video-coding.html/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Introduction to Test Model under Consideration (TMuC)</title>
		<link>http://www.h265.net/2010/06/introduction-to-tmuc.html</link>
		<comments>http://www.h265.net/2010/06/introduction-to-tmuc.html#comments</comments>
		<pubDate>Sun, 27 Jun 2010 04:37:19 +0000</pubDate>
		<dc:creator>Jie Dong</dc:creator>
				<category><![CDATA[Research]]></category>
		<category><![CDATA[HEVC]]></category>
		<category><![CDATA[JCT-VC]]></category>
		<category><![CDATA[Software]]></category>
		<category><![CDATA[TMuC]]></category>

		<guid isPermaLink="false">http://www.h265.net/?p=552</guid>
		<description><![CDATA[<p style="text-align: justify;">TMuC is the initial test model of JCT-VC, but it is not formally adopted as a test model of the draft standard, as no thorough testing has been performed for such a possible combination of tools. The coding tools in TMuC will be further tested to confirm their effectiveness, before adopted in a formal test model.</p>
<p style="text-align: justify;">TMuC provides more flexibility than H.264/AVC. The  basic coding unit, called coding tree block (CTB), which has a similar role to the macroblocks in H.264/AVC, can have variable sizes (a power of 2). The sizes of the largest and smallest CTBs are specified in the sequence parameter set (SPS). A frame is divided into non-overlapped largest CTBs (LCTB), e.g., 128&#215;128, and then each LCTB can be further divided in a recursive tree representation.</p>
<p style="text-align: justify;">Each CTB has its own prediction type (intra/inter) and prediction partition. The partition can be symmetric, just as in H.264/AVC, or asymmetric, e.g., 64&#215;64 block can be partitioned into 64&#215;16/64&#215;48 or 16&#215;64/48&#038;[......]</p><p class='read-more'><a href='http://www.h265.net/2010/06/introduction-to-tmuc.html'>Read More...</a></p>]]></description>
		<wfw:commentRss>http://www.h265.net/2010/06/introduction-to-tmuc.html/feed</wfw:commentRss>
		<slash:comments>11</slash:comments>
		</item>
		<item>
		<title>Mode-Dependent Directional Transform (MDDT) in JM/KTA</title>
		<link>http://www.h265.net/2009/09/mode-dependent-directional-transform-mddt-in-jmkta.html</link>
		<comments>http://www.h265.net/2009/09/mode-dependent-directional-transform-mddt-in-jmkta.html#comments</comments>
		<pubDate>Tue, 22 Sep 2009 14:51:20 +0000</pubDate>
		<dc:creator>Jie Dong</dc:creator>
				<category><![CDATA[Research]]></category>
		<category><![CDATA[KTA]]></category>
		<category><![CDATA[Transform]]></category>

		<guid isPermaLink="false">http://www.h265.net/?p=255</guid>
		<description><![CDATA[<p style="text-align: justify;">The intra prediction in H.264/AVC is a type of spatial domain directional prediction, which means different intra prediction modes represent different prediction directions, such as horizontal, vertical, and diagonal. An intra-coded MB can be partitioned into 4&#215;4, 8&#215;8, or 16&#215;16 intra prediction blocks. The 4&#215;4 and 8&#215;8 intra prediction blocks have nine prediction directions, respectively, and the 16&#215;16 block has four. Hence, totally 22 (9+9+4) intra prediction modes are used in H.264/AVC. The residue usually has high energy along the direction of prediction, as edges are more difficult to be predicted than smooth areas.</p>
<p style="text-align: justify;">Mode-dependent directional transform (MDDT) was proposed to compact the residue produced by intra prediction. It consists of a series of pre-defined separable transforms; each transform is efficient in compacting energy along one of the prediction directions, thus favoring one of the intra modes. The type of MDDT is coupled with the selected[......]</p><p class='read-more'><a href='http://www.h265.net/2009/09/mode-dependent-directional-transform-mddt-in-jmkta.html'>Read More...</a></p>]]></description>
		<wfw:commentRss>http://www.h265.net/2009/09/mode-dependent-directional-transform-mddt-in-jmkta.html/feed</wfw:commentRss>
		<slash:comments>15</slash:comments>
		</item>
		<item>
		<title>Adaptive Post/Loop Filters in JM/KTA &#8211; Part 2</title>
		<link>http://www.h265.net/2009/08/adaptive-post-loop-filters-in-jmkta-part-2.html</link>
		<comments>http://www.h265.net/2009/08/adaptive-post-loop-filters-in-jmkta-part-2.html#comments</comments>
		<pubDate>Sat, 22 Aug 2009 16:49:40 +0000</pubDate>
		<dc:creator>Yu Liu</dc:creator>
				<category><![CDATA[Research]]></category>
		<category><![CDATA[Adaptive Filtering]]></category>
		<category><![CDATA[KTA]]></category>
		<category><![CDATA[Loop Filter]]></category>

		<guid isPermaLink="false">http://www.h265.net/2009/08/adaptive-postloop-filters-in-jmkta-part-2.html</guid>
		<description><![CDATA[<p><strong>3. Adaptive Loop Filter</strong></p>
<p>As far as adaptive loop filter (ALF) is concerned, there are three types of ALF: frame-based, block-based and quadtree-based ALFs. All of them are based on wiener filter, but with different filtering control basis. In frame-based ALF [VCEG-C437/<a href="http://wftp3.itu.int/av-arch/video-site/0807_Ber/VCEG-AI14.zip">AI14</a>, C402], only one picture level flag is used to signal the decision of filtering or non-filtering.</p>
<p>Although wiener filter can restore the reconstructed picture to the original picture globally, there are degraded pixels locally. Since the degraded area reduce the filtering efficiency, if these areas are not filtered, the capabilities of picture restoration and loop filtering are improved. Therefore, block-based ALF [<a href="http://wftp3.itu.int/av-arch/video-site/0807_Ber/VCEG-AI18.zip">VCEG-AI18</a>/<a href="http://wftp3.itu.int/av-arch/video-site/0810_San/VCEG-AJ13.zip">AJ13</a>] use explicit flags for filtering on-off on block by block basis, while quadtree-based ALF [<a href="http://ftp.h265.net/C181.doc">VCEG-C181</a>/<a href="http://wftp3.itu.int/av-arch/video-site/0904_Yok/VCEG-AK22.zip">AK22</a>] introduces a quadtree data structure to carry out the variable-size block filtering.</p>
<p><strong>3.1 Block-based Adaptive Loop Filter</strong></p>
<p>Block-based ALF is an improvement of frame-based ALF. Figure 2[......]</p><p class='read-more'><a href='http://www.h265.net/2009/08/adaptive-post-loop-filters-in-jmkta-part-2.html'>Read More...</a></p>]]></description>
		<wfw:commentRss>http://www.h265.net/2009/08/adaptive-post-loop-filters-in-jmkta-part-2.html/feed</wfw:commentRss>
		<slash:comments>12</slash:comments>
		</item>
		<item>
		<title>Adaptive Post/Loop Filters in JM/KTA &#8211; Part 1</title>
		<link>http://www.h265.net/2009/08/adaptive-post-loop-filters-in-jmkta-part-1.html</link>
		<comments>http://www.h265.net/2009/08/adaptive-post-loop-filters-in-jmkta-part-1.html#comments</comments>
		<pubDate>Sat, 22 Aug 2009 15:39:40 +0000</pubDate>
		<dc:creator>Yu Liu</dc:creator>
				<category><![CDATA[Research]]></category>
		<category><![CDATA[Adaptive Filtering]]></category>
		<category><![CDATA[KTA]]></category>
		<category><![CDATA[Loop Filter]]></category>

		<guid isPermaLink="false">http://www.h265.net/?p=192</guid>
		<description><![CDATA[<p><strong>1. Introduction</strong></p>
<p>The basic idea of adaptive post/loop filter is the same. Both of them use adaptive wiener filtering technique to improve the quality of reconstructed picture which is degraded by compression. The difference between them is whether the filtering process is applied in or out of the core coding loop, as shown in Figure 1,  to improve the quality of reconstructed picture or just displayed picture.</p>
<p><img style="display: block; float: none; margin-left: auto; margin-right: auto; border-width: 0px;" title="kta_diagram" src="http://www.h265.net/wp-content/uploads/2009/08/kta_diagram.jpg" border="0" alt="kta_diagram" width="640" height="300" /></p>
<p>Figure 1. Block diagram of JM/KTA</p>
<p><strong>2. Adaptive Post Filter</strong></p>
<p>In H.264/AVC, there is already an existing post-filter hint SEI message [<a href="http://wftp3.itu.int/av-arch/jvt-site/2006_04_Geneva/JVT-S030.zip">JVT-S030</a>/<a href="http://wftp3.itu.int/av-arch/jvt-site/2006_07_Klagenfurt/JVT-T039.zip">T039</a>/<a href="http://wftp3.itu.int/av-arch/jvt-site/2006_10_Hangzhou/JVT-U035.zip">U035</a>] which provides the coefficients of a post-filter or correlation information for the design of a post-filter for potential use in post-processing of the output decoded pictures to obtain improved displayed quality.</p>
<p>To find the coefficients of adaptive wiener filter, the following cost function based on the whole frame is minimized:</p>
<p><img title="Eq1" src="http://www.h265.net/wp-content/uploads/2009/08/Eq1.jpg" alt="Eq1" width="455" height="64" /> (1)</p>
<p>where <em>R</em> is the reconstructed picture, <em>R&#8217;</em> is the filtered picture, and <em>I</em> is the original pic[......]</p><p class='read-more'><a href='http://www.h265.net/2009/08/adaptive-post-loop-filters-in-jmkta-part-1.html'>Read More...</a></p>]]></description>
		<wfw:commentRss>http://www.h265.net/2009/08/adaptive-post-loop-filters-in-jmkta-part-1.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

