<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	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/"
		>
<channel>
	<title>Comments on: R-D Performance of 1/8-pel MCP on HD Sequences</title>
	<atom:link href="http://www.h265.net/2009/06/r-d-performance-of-18-pel-mcp-on-hd-sequences.html/feed" rel="self" type="application/rss+xml" />
	<link>http://www.h265.net/2009/06/r-d-performance-of-18-pel-mcp-on-hd-sequences.html</link>
	<description>Witness the development of H.265</description>
	<lastBuildDate>Thu, 09 Sep 2010 02:35:48 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
	<item>
		<title>By: Carlos</title>
		<link>http://www.h265.net/2009/06/r-d-performance-of-18-pel-mcp-on-hd-sequences.html/comment-page-1#comment-2380</link>
		<dc:creator>Carlos</dc:creator>
		<pubDate>Mon, 14 Sep 2009 09:18:14 +0000</pubDate>
		<guid isPermaLink="false">http://www.h265.net/?p=30#comment-2380</guid>
		<description>Many thanks for your reply.

Yes, more bits are required to represent the higher precision MVs, but is that possible to have a situation like the &quot;Station&quot; sequence that having a 16.15% bitrate increase? Since it is only one bit per motion vector.

I read some comment from the Internet that suggest that it may be due to the mismatch of SATD(or SAD) used in MV search with the SSD used in RDO, how do you think about that?</description>
		<content:encoded><![CDATA[<p>Many thanks for your reply.</p>
<p>Yes, more bits are required to represent the higher precision MVs, but is that possible to have a situation like the &#8220;Station&#8221; sequence that having a 16.15% bitrate increase? Since it is only one bit per motion vector.</p>
<p>I read some comment from the Internet that suggest that it may be due to the mismatch of SATD(or SAD) used in MV search with the SSD used in RDO, how do you think about that?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jie Dong</title>
		<link>http://www.h265.net/2009/06/r-d-performance-of-18-pel-mcp-on-hd-sequences.html/comment-page-1#comment-2378</link>
		<dc:creator>Jie Dong</dc:creator>
		<pubDate>Mon, 14 Sep 2009 07:42:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.h265.net/?p=30#comment-2378</guid>
		<description>MV&#039;s resolution is increased, which means that more bits are needed to represent the same displacement, compared with 1/4-pixel MCP.</description>
		<content:encoded><![CDATA[<p>MV&#8217;s resolution is increased, which means that more bits are needed to represent the same displacement, compared with 1/4-pixel MCP.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Carlos</title>
		<link>http://www.h265.net/2009/06/r-d-performance-of-18-pel-mcp-on-hd-sequences.html/comment-page-1#comment-2377</link>
		<dc:creator>Carlos</dc:creator>
		<pubDate>Mon, 14 Sep 2009 03:40:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.h265.net/?p=30#comment-2377</guid>
		<description>Your result is compared to the &quot;anchor&quot; configuration, right?

I&#039;m curious that why there is negative effect of using 1/8-pel MCP compared to 1/4-pel, since 1/8-pel MCP just search more sub-positions. I think the result should be &quot;same or better&quot;, no matter how bad are the 1/8-pel sub-positions interpolated. 

Any ideas or hints?</description>
		<content:encoded><![CDATA[<p>Your result is compared to the &#8220;anchor&#8221; configuration, right?</p>
<p>I&#8217;m curious that why there is negative effect of using 1/8-pel MCP compared to 1/4-pel, since 1/8-pel MCP just search more sub-positions. I think the result should be &#8220;same or better&#8221;, no matter how bad are the 1/8-pel sub-positions interpolated. </p>
<p>Any ideas or hints?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mihai Moise</title>
		<link>http://www.h265.net/2009/06/r-d-performance-of-18-pel-mcp-on-hd-sequences.html/comment-page-1#comment-2286</link>
		<dc:creator>Mihai Moise</dc:creator>
		<pubDate>Thu, 25 Jun 2009 04:02:44 +0000</pubDate>
		<guid isPermaLink="false">http://www.h265.net/?p=30#comment-2286</guid>
		<description>Images have order-3 patterns. A better way of doing interpolation at 1/8-pixel sub positions would be to fit a 3rd-order polynomial through the 4 neighboring pixels on the same line, then use the polynomial to interpolate.</description>
		<content:encoded><![CDATA[<p>Images have order-3 patterns. A better way of doing interpolation at 1/8-pixel sub positions would be to fit a 3rd-order polynomial through the 4 neighboring pixels on the same line, then use the polynomial to interpolate.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mack</title>
		<link>http://www.h265.net/2009/06/r-d-performance-of-18-pel-mcp-on-hd-sequences.html/comment-page-1#comment-2267</link>
		<dc:creator>Mack</dc:creator>
		<pubDate>Fri, 12 Jun 2009 08:12:06 +0000</pubDate>
		<guid isPermaLink="false">http://www.h265.net/?p=30#comment-2267</guid>
		<description>Optimizing an algorithm for PSNR will deprive output quality of what it could&#039;ve had if it was optimized for something like SSIM. I haven&#039;t checked out VQM but it&#039;s cool as long as they take the step up from PSNR. It is NOT consistent for perceived quality in my experience.</description>
		<content:encoded><![CDATA[<p>Optimizing an algorithm for PSNR will deprive output quality of what it could&#8217;ve had if it was optimized for something like SSIM. I haven&#8217;t checked out VQM but it&#8217;s cool as long as they take the step up from PSNR. It is NOT consistent for perceived quality in my experience.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jie Dong</title>
		<link>http://www.h265.net/2009/06/r-d-performance-of-18-pel-mcp-on-hd-sequences.html/comment-page-1#comment-2254</link>
		<dc:creator>Jie Dong</dc:creator>
		<pubDate>Mon, 08 Jun 2009 11:29:34 +0000</pubDate>
		<guid isPermaLink="false">http://www.h265.net/?p=30#comment-2254</guid>
		<description>Yes. PSNR has some problems. But in the framework of hybrid video coding, where distortion is caused by quantization in the transform domain, PSNR correlates well with the perceived quality, although not strictly increasing with it. 

The experiment herein follows the test condition and the evaluation criterion specified by VCEG. Now, VCEG is considering using VQM to evaluate the subjective quality. But I think PSNR will be relevant in quality measurement for quite a long time.</description>
		<content:encoded><![CDATA[<p>Yes. PSNR has some problems. But in the framework of hybrid video coding, where distortion is caused by quantization in the transform domain, PSNR correlates well with the perceived quality, although not strictly increasing with it. </p>
<p>The experiment herein follows the test condition and the evaluation criterion specified by VCEG. Now, VCEG is considering using VQM to evaluate the subjective quality. But I think PSNR will be relevant in quality measurement for quite a long time.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mack</title>
		<link>http://www.h265.net/2009/06/r-d-performance-of-18-pel-mcp-on-hd-sequences.html/comment-page-1#comment-2253</link>
		<dc:creator>Mack</dc:creator>
		<pubDate>Mon, 08 Jun 2009 08:30:47 +0000</pubDate>
		<guid isPermaLink="false">http://www.h265.net/?p=30#comment-2253</guid>
		<description>Why measure quality with PSNR? That metric blows.</description>
		<content:encoded><![CDATA[<p>Why measure quality with PSNR? That metric blows.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
