<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.2.2" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Confusion and video editing</title>
	<link>http://eugenia.gnomefiles.org/2008/01/22/confusion-and-video-editing/</link>
	<description></description>
	<pubDate>Sat, 22 Nov 2008 18:23:05 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.2.2</generator>

	<item>
		<title>By: Eugenia</title>
		<link>http://eugenia.gnomefiles.org/2008/01/22/confusion-and-video-editing/#comment-5464</link>
		<author>Eugenia</author>
		<pubDate>Tue, 22 Jan 2008 23:40:28 +0000</pubDate>
		<guid>http://eugenia.gnomefiles.org/2008/01/22/confusion-and-video-editing/#comment-5464</guid>
		<description>For pixel aspect ratios all it needs for people to get it, is a visual representation as to how things change when they choose a different ratio. Vegas' project properties is very good for what it is, but a visual representation would make it even better.</description>
		<content:encoded><![CDATA[<p>For pixel aspect ratios all it needs for people to get it, is a visual representation as to how things change when they choose a different ratio. Vegas&#8217; project properties is very good for what it is, but a visual representation would make it even better.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Cesar</title>
		<link>http://eugenia.gnomefiles.org/2008/01/22/confusion-and-video-editing/#comment-5461</link>
		<author>Cesar</author>
		<pubDate>Tue, 22 Jan 2008 17:32:31 +0000</pubDate>
		<guid>http://eugenia.gnomefiles.org/2008/01/22/confusion-and-video-editing/#comment-5461</guid>
		<description>Deinterlacing is the most difficult thing to get it done right when your footage is a high motion 60 fields per second scene.</description>
		<content:encoded><![CDATA[<p>Deinterlacing is the most difficult thing to get it done right when your footage is a high motion 60 fields per second scene.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dominique</title>
		<link>http://eugenia.gnomefiles.org/2008/01/22/confusion-and-video-editing/#comment-5459</link>
		<author>Dominique</author>
		<pubDate>Tue, 22 Jan 2008 16:06:34 +0000</pubDate>
		<guid>http://eugenia.gnomefiles.org/2008/01/22/confusion-and-video-editing/#comment-5459</guid>
		<description>Thanks.

As a starting hobbyist, I appreciate your of outlining some of the minor pitfalls.</description>
		<content:encoded><![CDATA[<p>Thanks.</p>
<p>As a starting hobbyist, I appreciate your of outlining some of the minor pitfalls.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Richard</title>
		<link>http://eugenia.gnomefiles.org/2008/01/22/confusion-and-video-editing/#comment-5456</link>
		<author>Richard</author>
		<pubDate>Tue, 22 Jan 2008 13:50:00 +0000</pubDate>
		<guid>http://eugenia.gnomefiles.org/2008/01/22/confusion-and-video-editing/#comment-5456</guid>
		<description>And the really tricky part is designing a User Interface for setting Pixel-Aspect Ratios and such stuff. Especially if you are totally sure that the majority of the users won't have the slightest clue what the Application is asking.

I've recently posted a proposal for a "User Interface" solution to this problem to the cinelerra Mailinglist:


So, Framesize, Interlacing and Pixel-Aspect are hard problems. In my humble Opinion the only serious attempt to solve that problem in a fashion that is at least somehow universial, is the following.

You need several tools, One Tool would be like the unix "file" utility. A tool that scans a  video source and makes a good guess about what kind of Interlacing and Pixel-Aspect is being used.

The Second Tool is some kind of machine readable Knowledge-Database, that is filled with rules and heuristics about common frame-sizes, their assorted pixel-aspects, and how and when and when certain formats are used, and how they should be converted to other formats when necessary. This information will likely be useful to the "Source-Analysis-Tool" as well, as mentioned in the paragraph above.

Additionally the Knowledge Base should also be sprinkled with human readable information, Such as: "You are exporting a 24p file to 29.97i, a 3:2 Pulldown will be performed for conversion, for more information about that, click here...".

Ideally the knowledge base should have information available for most of the common cases. In case there are conflicting rules, or two equally likely options, the database should have enough information available to ask the user the question whether he prefers A or B.

--8</description>
		<content:encoded><![CDATA[<p>And the really tricky part is designing a User Interface for setting Pixel-Aspect Ratios and such stuff. Especially if you are totally sure that the majority of the users won&#8217;t have the slightest clue what the Application is asking.</p>
<p>I&#8217;ve recently posted a proposal for a &#8220;User Interface&#8221; solution to this problem to the cinelerra Mailinglist:</p>
<p>So, Framesize, Interlacing and Pixel-Aspect are hard problems. In my humble Opinion the only serious attempt to solve that problem in a fashion that is at least somehow universial, is the following.</p>
<p>You need several tools, One Tool would be like the unix &#8220;file&#8221; utility. A tool that scans a  video source and makes a good guess about what kind of Interlacing and Pixel-Aspect is being used.</p>
<p>The Second Tool is some kind of machine readable Knowledge-Database, that is filled with rules and heuristics about common frame-sizes, their assorted pixel-aspects, and how and when and when certain formats are used, and how they should be converted to other formats when necessary. This information will likely be useful to the &#8220;Source-Analysis-Tool&#8221; as well, as mentioned in the paragraph above.</p>
<p>Additionally the Knowledge Base should also be sprinkled with human readable information, Such as: &#8220;You are exporting a 24p file to 29.97i, a 3:2 Pulldown will be performed for conversion, for more information about that, click here&#8230;&#8221;.</p>
<p>Ideally the knowledge base should have information available for most of the common cases. In case there are conflicting rules, or two equally likely options, the database should have enough information available to ask the user the question whether he prefers A or B.</p>
<p>&#8211;8</p>
]]></content:encoded>
	</item>
</channel>
</rss>
