<br><br><div class="gmail_quote">On Jan 23, 2008 8:51 AM, Daniel Kristjansson <<a href="mailto:danielk@cuymedia.net">danielk@cuymedia.net</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Wed, 2008-01-23 at 12:13 +0000, Oliver Maunder wrote:<br>> I'm using the official VIA drivers because the Openchrome doesn't yet<br></div><div class="Ih2E3d">> I've tracked this down to DRM VSync calls. Commenting out the line<br>
> TESTVIDEOSYNC(DRMVideoSync) in VideoSync::BestMethod (in<br>> libs/libmythtv/vsync.cpp) cures the problem.<br>><br>> This leads to a second issue where video works but the colours are<br>> messed up because MythTV is using I420 encoding which the driver<br>
> doesn't seem to like. This can be fixed by uncommenting the line<br>> #define USE_ATI_PROPRIETARY_DRIVER_XVIDEO_HACK<br>> in videoout_xv.cpp in 0.2.20. This #define isn't the SVN version,<br>> but a similar one-line fix will work.<br>
</div>The SVN version defaults to using the reversed I420 encoding that<br>the AIT hack enabled. Unfortunately it seems many video card driver<br>writers don't test I420 before shipping the drivers.<br><div class="Ih2E3d">
<br>> submit a patch, but I don't know what the policy is about hacking<br>> around driver issues. The code would need to test for the VIA driver<br>> and use the workarounds if it's founds. Is this sort of thing done<br>
> elsewhere in the code?<br></div>Hacking around driver issues is something we do but don't like doing.<br>When we do it we vastly prefer using a method that tests for the broken<br>driver at run time and only applies the patch if needed.<br>
<br>The GrabSuitibleXvPort() function in libs/libmythtv/videoout_xv.cpp<br>queries the adaptor name, something like that could be used to test<br>for the presence of the VIA drivers.<br><br>-- Daniel<br><br></blockquote><div>
<br>I've managed to catch up to the same point as Oliver -- installed on Ubuntu and MythTV 0.20.2 and made patches as indicated in first e-mail. Although this does allow the board to work, it does not get MPEG-2 hardware acceleration. I get the following errors now:<br>
<br>2008-01-31 23:32:51.236 VideoOutputXv: XvMCTex: Init failed<br>2008-01-31 23:32:51.238 VideoOutputXv: XVideo Adaptor Name: 'XV_SWOV'<br>2008-01-31 23:32:54.872 TV: Changing from None to WatchingLiveTV<br>2008-01-31 23:32:54.932 Using realtime priority.<br>
2008-01-31 23:32:55.165 Video timing method: RTC<br>2008-01-31 23:32:55.550 VideoOutputXv Error: XvMC output requested, but is not supported by display.<br>Xlib: extension "XVideo-MotionCompensation" missing on display ":0.0".<br>
<br>I already configured /etc/XvMCConfig to point to /usr/lib/libviaXvMCPro.so , so that's not the issue. Also, I know the machine is capable since Via's version of mplayer (VeMP) is working fine with HDTV sources on this machine at relatively low CPU (~30%). Any ideas where to go from here? Other debugging steps to take? Any reason to believe SVN would be better?<br>
</div></div><br>