<br><br><div><span class="gmail_quote">On 1/13/06, <b class="gmail_sendername">MagicITX</b> <<a href="mailto:magicitx@gmail.com">magicitx@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I was having trouble with VLC on a VIA EPIA system using the openchrome
Xv driver.  While working to resolve it with Thomas Hellstrom of
the openchrome project he reported: "It seems that VLC doesn't format
the Xv images as the X server tells it to do. In particular, it doesn't
adhere to pitches. This makes YV12 produce rendering errors on widths
that are not multiples of 32, but YUY2 is OK for widths that are
multiples of 16. (when dmablit is on, otherwise the openchrome driver
requests that strides and widths are the same). This should really be
communicated to the VLC developers."<br clear="all"><span class="sg"><br>-- <br><br>Tim<br><a href="http://www.magicitx.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">www.magicitx.com</a>
<br>

</span></blockquote></div><br>I updated the openchrome driver and via
drm driver but vlc had green tint on the bottom lines of the
image.  That is the effect of the above bug.  Thomas added:<br>
<br>
"<span class="q">That's the VLC bug. (3 above). The via driver tells
vlc to use 368 for chroma stride, but it uses 360. Hence there is no
chroma data for the last lines, and if you look closely the rest of the
picture is in black and white with diagonal misrendered colors on it.
It works when not using PCI DMA, because then the via driver tells VLC
to use 360, which it does anyway.<br><br>A temporary workaround for 720 width is to use YUY2, but the best thing would be if you communicated this to VLC developers."<br>
<br>
I'll take a look at the vlc code and see if I can fix it.<br clear="all">
</span><br>-- <br><br>Tim<br><a href="http://www.magicitx.com">www.magicitx.com</a><br>