<br><br>
<div><span class="gmail_quote">On 28/01/2008, <b class="gmail_sendername">Mark Kendall</b> <<a href="mailto:mark.kendall@gmail.com">mark.kendall@gmail.com</a>> 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, Mark Kendall <<a href="mailto:mark.kendall@gmail.com">mark.kendall@gmail.com</a>> wrote:<br>
><br>> Try the attached (against svn). This should give you a new CPU based<br>> 'Interlaced (2x)' deinterlacer option. Not tested extensively, and<br>> still needs some refinement, but appears to be working as expected.<br>
<br>Actually...<br><br>I just went back to basics as I was looking into why my patch didn't<br>get a sync 100% of the time. So I went back to bobdeint and it just<br>works - seemingly 100% of the time.<br><br>So the question is, why can't you use bobdeint with your modeline? I'm<br>
guessing (because I've seen the same problem) that X is reporting a<br>slightly erroneous refresh rate (i.e. slightly too low) and hence bob<br>gets rejected.<br><br>A slightly cleaner way to do this would be to adapt a 2x onefield<br>
filter - which would eliminate any osd flicker etc and might just<br>improve picture quality as there would be no bob adjustment or<br>scaling.<br><br>Ah. The never ending joy of tinkering with mythtv!<br><br>Mark<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>Mark,</div>
<div> </div>
<div>Yes on 0.20.2 (that I'm using) it's a mystery why bob works at all!</div>
<div>Why?</div>
<div> </div>
<div>Well (remember I'm using a standard Interlace CRT TV with RGB-SCART drive), when I try to play</div>
<div>full frame, non-scaled interlaced PAL content WITHOUT BOB, it doesn't get the sync to FRAME correctly.</div>
<div> </div>
<div>Theorectically BOB deint would also need to sync to FRAME correctly, otherwise you'd get some wierd combing effects</div>
<div>I suspect when the FIELDS are shown out of order. But on my system it just works, so presumeably the BOB code is able to sync to FRAME (with my driver/card/myth/X combination) but the normal (non filtered) code isn't!</div>
<div> </div>
<div>Of course, BOB is required whenever you do scaling (because bob enforces the order of fields, you can scale the fields then display them in the correct order).</div>
<div> </div>
<div>Unfortunately I won't be able to try your patch for some time (weeks) I'm afraid....first I'd have to move to SVN! And I'd like to guard my regression path whilst I do it, as decent output is more important to me than the whizz bang features of SVN.</div>
<div> </div>
<div>>So the question is, why can't you use bobdeint with your modeline? I'm<br>>guessing (because I've seen the same problem) that X is reporting a<br>>slightly erroneous refresh rate (i.e. slightly too low) and hence bob<br>
>gets rejected</div>
<div>Well in 0.20 bobdeint rejects any mode where the FRAME rate is less than 2x the signal framerate i.e. 50hz in PAL land.</div>
<div>I suppose it's a question of semantics! The FRAME rate is still 25 but you can change the picture at 50hz. The 0.20 doesn't</div>
<div>take this into account (that it can display the diff fields at 50hz on an interlaced display). Viktor's patc just fools the code into thinking the FRAME rate of the display is twice what it is, the correct method is simply to fix bobdeint itself so it realises the difference.</div>
<div> </div>
<div>>A slightly cleaner way to do this would be to adapt a 2x onefield<br>>filter - which would eliminate any osd flicker etc and might just<br>>improve picture quality as there would be no bob adjustment or<br>
>scaling.<br> </div>
<div>Actually yes 2x onefield (NOT the SAME field!) is exactly what's needed with an interlaced display.</div>
<div>Basically it goes:</div>
<div> </div>
<div><FRAME SYNC> 1st FIELD ---> Scale as appropriate ----> Display</div>
<div><field sync> 2nd FIELD --> Scale as appropriate ---> Display.</div>
<div>
<div><FRAME SYNC> 1st FIELD ---> Scale as appropriate ----> Display</div>
<div><field sync> 2nd FIELD --> Scale as appropriate ---> Display.</div>
<div>etc. etc.</div>
<div> </div>
<div>Where "Scale as appropriate" means doing the necessary to display 16:9 on an 4:3 etc.</div>
<div> </div>
<div>So I am talking about 2xOnefield(with different fields) or BOBdeint here? I don't know. But that's the effect I'm after.</div>
<div>(Maybe it should be called 2xBOTHfields!?!? But isn't that the same as bob?)</div>
<div> </div>
<div>Of course I'm sure you know all this several times over!</div>
<div> </div>
<div>>Re-reading the above, it has also occurred to me that you won't be<br>>able to use XvMC with this as you can't filter an XvMC/partially<br>>decoded frame. But see what results you get and get back to me.<br>
</div>
<div>That's interesting, I'm obviously missing some subtleties with how XvMC/bobdeint works here, but currently I'm using</div>
<div>XvMC+Bobdeint+ViktorsHack on an interlaced display and it works. Has this changed from 0.20->0.21?</div>
<div> </div>
<div> </div>
<div>Cheers</div>
<div> </div>
<div>Steve</div>
<div> </div></div>
<div> </div>