<br><br>
<div><span class="gmail_quote">On 28/01/2008, <b class="gmail_sendername">Mark Kendall</b> &lt;<a href="mailto:mark.kendall@gmail.com">mark.kendall@gmail.com</a>&gt; wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">On 28/01/2008, Steve Smith &lt;<a href="mailto:st3v3.sm1th@gmail.com">st3v3.sm1th@gmail.com</a>&gt; wrote:<br>
<br>&gt; I suspect when the FIELDS are shown out of order. But on my system it just<br>&gt; works, so presumeably the BOB code is able to sync to FRAME (with my<br>&gt; driver/card/myth/X combination) but the normal (non filtered) code isn&#39;t!<br>
<br>I&#39;m starting to wonder whether it has something to do with the XV/XvMC<br>code and the nvidia driver(don&#39;t know about ati etc) somehow knowing<br>which is the first field of a frame. Alternatively it could just be<br>
that presenting one field at a time allows the tv to figure it out -<br>though looking at the pal specs, there is some specific signalling<br>that tells the tv which is the first field of the frame.<br><br>&gt; &gt;So the question is, why can&#39;t you use bobdeint with your modeline? I&#39;m<br>
&gt; &gt;guessing (because I&#39;ve seen the same problem) that X is reporting a<br>&gt; &gt;slightly erroneous refresh rate (i.e. slightly too low) and hence bob<br>&gt;&nbsp;&nbsp;&gt;gets rejected<br>&gt; Well in 0.20&nbsp;&nbsp;bobdeint rejects any mode where the FRAME rate is less than 2x<br>
&gt; the signal framerate i.e. 50hz in PAL land.<br>&gt; I suppose it&#39;s a question of semantics! The FRAME rate is still 25 but you<br>&gt; can change the picture at 50hz. The 0.20 doesn&#39;t<br>&gt; take this into account (that it can display the diff fields at 50hz on an<br>
&gt; interlaced display). Viktor&#39;s patc just fools the code into thinking the<br>&gt; FRAME rate of the display is twice what it is, the correct method is simply<br>&gt; to fix bobdeint itself so it realises the difference.<br>
<br>The code will/should only reject display modes where it believes the<br>display refresh rate (50Hz ideally) cannot support doubling the source<br>frame rate ie. from 25Hz to 50Hz.<br><br>What I see on at least one frontend (using both 720p and 1080i<br>
modelines) is that xorg is actually returning a refresh rate of<br>something like 49.95Hz and hence bob (or any other framerate doubling<br>deinterlacer) is rejected.<br><br>This doesn&#39;t appear to be a mythtv issue (admittedly, it would be<br>
better if the code gave a small amount of leeway) and the way I have<br>worked around it is to fire up xvidtune and tweak the modeline<br>slightly to increase the refresh rate.<br><br>You might just find this works for you without hacking mythtv.<br>
<br>&gt; &gt;A slightly cleaner way to do this would be to adapt a 2x onefield<br>&gt; &gt;filter - which would eliminate any osd flicker etc and might just<br>&gt; &gt;improve picture quality as there would be no bob adjustment or<br>
&gt;&nbsp;&nbsp;&gt;scaling.<br>&gt;<br>&gt; Actually yes 2x onefield (NOT the SAME field!) is exactly what&#39;s needed with<br>&gt; an interlaced display.<br>&gt; Basically it goes:<br>&gt;<br>&gt; &lt;FRAME SYNC&gt; 1st FIELD ---&gt;&nbsp;&nbsp;Scale as appropriate ----&gt; Display<br>
&gt; &lt;field sync&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2nd FIELD --&gt; Scale as appropriate ---&gt; Display.<br>&gt; &lt;FRAME SYNC&gt; 1st FIELD ---&gt;&nbsp;&nbsp;Scale as appropriate ----&gt; Display<br>&gt; &lt;field sync&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2nd FIELD --&gt; Scale as appropriate ---&gt; Display.<br>
&gt; etc. etc.<br>&gt;<br>&gt; Where &quot;Scale as appropriate&quot; means doing the necessary to display 16:9 on an<br>&gt; 4:3 etc.<br>&gt;<br>&gt; So I am talking about 2xOnefield(with different fields) or BOBdeint here? I<br>
&gt; don&#39;t know. But that&#39;s the effect I&#39;m after.<br>&gt; (Maybe it should be called 2xBOTHfields!?!? But isn&#39;t that the same as bob?)<br><br>Well, either my code is broken (not unlikely) or there is more to it<br>
than that because bob seems to be working very well (apart from the<br>osd flicker) whereas 2x Onefield works intermittently.<br><br>Need to clear head!<br>_______________________________________________<br>mythtv-users mailing list<br>
<a href="mailto:mythtv-users@mythtv.org">mythtv-users@mythtv.org</a><br><a href="http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users">http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users</a><br></blockquote></div>
<div><br>&gt;I&#39;m starting to wonder whether it has something to do with the XV/XvMC<br>&gt;code and the nvidia driver(don&#39;t know about ati etc) somehow knowing<br>&gt;which is the first field of a frame. Alternatively it could just be<br>
&gt;that presenting one field at a time allows the tv to figure it out -<br>&gt;though looking at the pal specs, there is some specific signalling<br>&gt;that tells the tv which is the first field of the frame.</div>
<div>&nbsp;</div>
<div>Actually the first field 2nd field thing is all done using timing (both for NTSC and PAL).</div>
<div>The first thing to realise is that the scanlines on a CRT TV are slightly sloped downwards so that the left end of the line is 2 pixels higher than the right.</div>
<div>The first field is sent with its 312 lines, and then a HALF line is sent. Then Vsync is trigged to </div>
<div>get the electron beam up to the top of the screen and the next FIELD is sent starting at the begginning of the</div>
<div>next line. </div>
<div>It&#39;s the HALF line at the end of the first field which together with the slight slope of the lines themselves which</div>
<div>causes the electron beam to end up halfway between the scan lines of the previous frame, so that the 2nd field lines&nbsp;are interlaced between the first field&#39;s lines.</div>
<div>Clever eh?</div>
<div>What this means is that the video card decides which is the first field and which is the 2nd. The TV doesn&#39;t really have any concept of it (for a normal CRT TV, LCD&#39;s have to figure it out from that half line I expect!)</div>

<div>&nbsp;</div>
<div>&nbsp;</div>
<div>So for every FRAME with an interlaced signal you can potentially have two Vertical Syncs what I refer to as a FRAME Sync and a FIELD sync (which is the vertical sync after the half line).</div>
<div>It&#39;s very difficult from the literature available to see if the Nvidia drivers send:</div>
<div>&nbsp;&nbsp;&nbsp; i) Only a FRAME sync.</div>
<div>&nbsp;&nbsp;&nbsp;ii) FIELD syncs (with no indication of Frames)</div>
<div>&nbsp;&nbsp; iii) FIELD and FRAME syncs with indication of which is a frame.</div>
<div>&nbsp;</div>
<div>To get interlaced output to work properly we need either&nbsp; iii) or i)&nbsp; (I assume we can time the field sync in between frames realiably in software).</div>
<div>&nbsp;</div>
<div>So what&#39;s wierd is that in mine (and other) setups, bob deint can figure out the frames.&nbsp;Whilst&nbsp;when no&nbsp;deinterlacer is selected it&nbsp;can&#39;t.</div>
<div>Where&#39;s the bug? Who knows? Myth, X, nvidia or somewhere else?</div>
<div>In either case you do actually need some form of bob like action in order to do scaling correctly.</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>&gt;The code will/should only reject display modes where it believes the<br>&gt;display refresh rate (50Hz ideally) cannot support doubling the source<br>&gt;frame rate ie. from 25Hz to 50Hz.</div>
<div>&nbsp;</div>
<div>This is where I think the misunderstanding comes in, because (X reporting the refresh rate wrong aside) I believe that</div>
<div>for an ***INTERLACED*** display mode (not progressive display mode) &nbsp;****you only need the refresh rate to be 25hz.****</div>
<div>WHY?</div>
<div>&nbsp;</div>
<div>Refresh = FRAME rate = 25hz.</div>
<div>Interlaced&nbsp; THEReFORE&nbsp; = 2x Fields per frame =&nbsp; 50hz.&nbsp;&nbsp;&nbsp; Note as I say above there are now 2x potential vertical syncs per frame.</div>
<div>So on the first VSYNC (I call the frame sync) you paint the top fields.</div>
<div>On the 2nd VSYNC you paint the bottom fields.</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>i.e. when the display mode is INTERLACED you can repaint the picture 2x per frame. This allows you to treat each frame</div>
<div>as two consecutive (in time) pictures, scale them appropriately and display one at a time always ensuring the TOP field aligns with the FRAME sync. i.e. Interlaced display mode is a special case!</div>
<div>&nbsp;</div>
<div>X reports the Refresh/Frame rate NOT the field rate.</div>
<div>&nbsp;</div>
<div>I seem to be discussing myself into circles.... ;-)</div>
<div>&nbsp;</div>
<div>RE: OSD flicker, would that mean that the OSD is inserted into the final picture in only one field. BTW I have no OSD flicker with my bob deint ;-)!</div>
<div>&nbsp;</div>
<div>Cheers</div>
<div>&nbsp;</div>
<div>Steve</div>
<div><br>&nbsp;</div>
<div>&nbsp;</div>