<?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: Why the Digital TV Delay May be a Good Thing</title>
	<atom:link href="http://www.robglidden.com/2009/02/digital-tv-delay-may-be-good/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.robglidden.com/2009/02/digital-tv-delay-may-be-good/</link>
	<description>My blog</description>
	<lastBuildDate>Wed, 26 May 2010 22:08:33 -0600</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Rob Glidden</title>
		<link>http://www.robglidden.com/2009/02/digital-tv-delay-may-be-good/comment-page-1/#comment-44</link>
		<dc:creator>Rob Glidden</dc:creator>
		<pubDate>Sat, 14 Feb 2009 18:33:07 +0000</pubDate>
		<guid isPermaLink="false">http://www.robglidden.com/?p=256#comment-44</guid>
		<description>Yes, any IPR-aware methodology would be well-served to start from a sure foundation of demonstrably-known intellectual property rights.

It is intuitively much easier, and FUD-resistant, to &quot;add only royalty-free bricks to a royalty-free foundation&quot;, particularly in domains that have evolved over decades and already have developed multiple solutions and algorithms.  Royalty-free oriented standards groups recognize this, as do product developers in patent-oriented domains.

Expired patents, public domain technologies, known prior art are some starting points.</description>
		<content:encoded><![CDATA[<p>Yes, any IPR-aware methodology would be well-served to start from a sure foundation of demonstrably-known intellectual property rights.</p>
<p>It is intuitively much easier, and FUD-resistant, to &#8220;add only royalty-free bricks to a royalty-free foundation&#8221;, particularly in domains that have evolved over decades and already have developed multiple solutions and algorithms.  Royalty-free oriented standards groups recognize this, as do product developers in patent-oriented domains.</p>
<p>Expired patents, public domain technologies, known prior art are some starting points.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joshua Cogliati</title>
		<link>http://www.robglidden.com/2009/02/digital-tv-delay-may-be-good/comment-page-1/#comment-41</link>
		<dc:creator>Joshua Cogliati</dc:creator>
		<pubDate>Fri, 13 Feb 2009 15:00:14 +0000</pubDate>
		<guid isPermaLink="false">http://www.robglidden.com/?p=256#comment-41</guid>
		<description>I agree with you that interlacing is not needed for new implementations.  I also agree with you that it probably is possible to implement a royalty free digital tv standard with interlacing and forward error correction.  I think it would be very expensive to patent clear it.   For example, MPEG-1 video at least has age on its side, and Wikipedia, Redhat and Ubuntu don&#039;t consider it clear enough of patents to support it.</description>
		<content:encoded><![CDATA[<p>I agree with you that interlacing is not needed for new implementations.  I also agree with you that it probably is possible to implement a royalty free digital tv standard with interlacing and forward error correction.  I think it would be very expensive to patent clear it.   For example, MPEG-1 video at least has age on its side, and Wikipedia, Redhat and Ubuntu don&#8217;t consider it clear enough of patents to support it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rob Glidden</title>
		<link>http://www.robglidden.com/2009/02/digital-tv-delay-may-be-good/comment-page-1/#comment-40</link>
		<dc:creator>Rob Glidden</dc:creator>
		<pubDate>Thu, 12 Feb 2009 19:09:33 +0000</pubDate>
		<guid isPermaLink="false">http://www.robglidden.com/?p=256#comment-40</guid>
		<description>Interlacing in TV is of course old as the hills, commercially deployed starting in the 1930&#039;s, see http://en.wikipedia.org/wiki/Interlace, which makes it a questionable leg of a patent-extension stool.  Challenges have long been widespread, quoting from July, 1996: &quot;Opponents see continuing interlace as anywhere from a bureaucratic disaster to a nefarious plan to milk interlace patents.&quot;

Similarly forward error correction techniques long predated MPEG: see http://en.wikipedia.org/wiki/Forward_error_correction for a few citations.

MPEG Systems patent 5,457,701, http://www.mpegla.com/m2s/m2s-patentlist.cfm, recognizes this and states &quot;Description of the Prior Art .... Essentially, a forward error correction code is appended to each packet&quot;.  Perhaps this may provide insight into why a much more modest technique of &#039;a one bit field of each header is pre-defined as a &quot;packet error indicator&quot;&#039; is described in the patent and claims and is included in the pool.  One might characterize as a &quot;damaged in transit&quot; flag -- simply notification of &quot;an uncorrectable error occurred&quot;, not error correction.</description>
		<content:encoded><![CDATA[<p>Interlacing in TV is of course old as the hills, commercially deployed starting in the 1930&#8217;s, see <a href="http://en.wikipedia.org/wiki/Interlace" rel="nofollow">http://en.wikipedia.org/wiki/Interlace</a>, which makes it a questionable leg of a patent-extension stool.  Challenges have long been widespread, quoting from July, 1996: &#8220;Opponents see continuing interlace as anywhere from a bureaucratic disaster to a nefarious plan to milk interlace patents.&#8221;</p>
<p>Similarly forward error correction techniques long predated MPEG: see <a href="http://en.wikipedia.org/wiki/Forward_error_correction" rel="nofollow">http://en.wikipedia.org/wiki/Forward_error_correction</a> for a few citations.</p>
<p>MPEG Systems patent 5,457,701, <a href="http://www.mpegla.com/m2s/m2s-patentlist.cfm" rel="nofollow">http://www.mpegla.com/m2s/m2s-patentlist.cfm</a>, recognizes this and states &#8220;Description of the Prior Art &#8230;. Essentially, a forward error correction code is appended to each packet&#8221;.  Perhaps this may provide insight into why a much more modest technique of &#8216;a one bit field of each header is pre-defined as a &#8220;packet error indicator&#8221;&#8216; is described in the patent and claims and is included in the pool.  One might characterize as a &#8220;damaged in transit&#8221; flag &#8212; simply notification of &#8220;an uncorrectable error occurred&#8221;, not error correction.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joshua Cogliati</title>
		<link>http://www.robglidden.com/2009/02/digital-tv-delay-may-be-good/comment-page-1/#comment-36</link>
		<dc:creator>Joshua Cogliati</dc:creator>
		<pubDate>Wed, 11 Feb 2009 13:24:32 +0000</pubDate>
		<guid isPermaLink="false">http://www.robglidden.com/?p=256#comment-36</guid>
		<description>I think that anyone would be hard pressed to design a digital tv standard that supported efficient video forward error correction and interlacing without hitting the patent thicket that the companies designing MPEG-2 created.  As I understand this OMS gets around this by basically supporting neither (which is quite acceptable for video for computer screens that is using a reliable transport).    That said the ATSC probably could have used technology that had less patents and patents that expired sooner.</description>
		<content:encoded><![CDATA[<p>I think that anyone would be hard pressed to design a digital tv standard that supported efficient video forward error correction and interlacing without hitting the patent thicket that the companies designing MPEG-2 created.  As I understand this OMS gets around this by basically supporting neither (which is quite acceptable for video for computer screens that is using a reliable transport).    That said the ATSC probably could have used technology that had less patents and patents that expired sooner.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
