Kodi Community Forum - [LINUX] Video tearing in xbmc not reproducible in mplayer or vlc

Pages: 1 2

Distro: Gentoo amd64 stable
XBMC: SVN r30341 (from xbmc-9999.ebuild)
Kernel: 2.6.33
xorg-server:1.7.6
xorg-x11: 7.4-r1
Driver: xf86-video-ati-6.12.6
Log: http://pastebin.com/JbNtzw5J

I have an ATi Xpress 200M video card and I use the radeon driver. When watching video in XBMC I get a reasonable amount of horizontal tearing, enough to be noticeable when there is any significant sideways movement in the video. I see it equally in low-quality and up to 720p video (I can't play 1080p video at all, but that's because the hardware isn't capable). I cannot produce the same problem in MPlayer or in VLC (with video output set as xv or x11 in mplayer).

One would think that the solution to this is to enable VSync in xbmc, however if I do this xbmc hangs. Well, not hangs per se, just takes a very long time to respond to a keyboard press to navigate the menus (and turn vsync off again). If it has a hard time rendering menus in this state, you can imagine how it struggles with video.

Here's a log with me attempting to enable vsync: http://pastebin.com/VcYKaNwv

I'm thinking this is the relevant line for that problem:

Code:
ERROR: PresentRenderImpl - glXWaitVideoSyncSGI - Returned error

What appears to be the same thing happens when I try to run MPlayer using the gl video output:

Code:
do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.

Try adjusting the vblank_mode configuration parameter.

vsync appears to be enabled at a driver level. Or at least xvattr reports that it is for xv video output. Which would explain why I don't get vsync issues using mplayer.

Code:
Found Xv 2.2

XV_VSYNC = 1

Simple question: Is there a way to essentially pass '-vo xv' to xbmc?
Painful question: If not, is there any way I can fix my gl output, short of buying an actual graphics card (and a machine to put it in, this being a laptop) that better supports it?

Otherwise it looks like I'm stuck using plain mplayer, and just using xbmc to keep track of what I have and haven't watched.

jw5801 Wrote:Simple question: Is there a way to essentially pass '-vo xv' to xbmc?

No, that would mean rewriting half of xbmc.

bobo1on1 Wrote:No, that would mean rewriting half of xbmc.

I thought that might be the case. Bugger. So I guess I have to try and work out why OpenGL is failing on vsync. Any suggestions?

The GLX_SGI_video_sync extension isn't working correctly.

Is that something I can fix with settings? Or is it a driver problem, or a hardware problem?

glxinfo reports that the extension is available:

Code:
name of display: :0.0 

display: :0  screen: 0 

direct rendering: Yes 

server glx vendor string: SGI 

server glx version string: 1.2 

server glx extensions: 

    GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, 

    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, 

    GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_swap_control, 

    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 

    GLX_SGIX_visual_select_group 

client glx vendor string: Mesa Project and SGI 

client glx version string: 1.4 

client glx extensions: 

    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 

    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, 

    GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, 

    GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, 

    GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, 

    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 

    GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap 

GLX version: 1.2 

GLX extensions: 

    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 

    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, 

    GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, 

    GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, 

    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 

    GLX_SGIX_visual_select_group 

...

I'm not sure how to move forward here.

See if you can force vsync on in the driver and then set the vsync in xbmc to let driver decide.

I thought I had. Not sure how else I can force it.

man radeon:

Code:
Option "EXAVSync" "boolean"

       This option attempts to avoid tearing  by  stalling  the  engine

       until  the display controller has passed the destination region.

       It reduces tearing at the cost of performance and has been  know

       to cause instability on some chips.  The default is off.

xorg.conf:

Code:
...

Section "Device"

        Identifier  "Card0"

        Driver      "ati"

        VendorName  "All"

        BoardName   "All"

        Option      "AccelMethod" "EXA"

        Option      "EXAVSync" "on"

EndSection

...

xorg.0.log: http://pastebin.com/vSivaLHX
Or after a quick grep for VSync:

Code:
...

(**) RADEON(0): Option "EXAVSync" "on"

...

(WW) RADEON(0): LVDS Info:

XRes: 1280, YRes: 800, DotClock: 72250

HBlank: 160, HOverPlus: 48, HSyncWidth: 32

VBlank: 23, VOverPlus: 2, VSyncWidth: 6

...

(II) RADEON(0): EXA VSync enabled

...

What happens if you turn that off.

It doesn't appear to really make a difference either way. The output of glxinfo doesn't change.

Hmm... perhaps I should have mentioned earlier, but the laptop is connected to my TV (it's a Panasonic TH-P50X10A plasma, if that's relevant) over VGA (that's the only output this laptop has). I had tested video on both the TV and the laptop monitor and saw tearing on both. However, I had not tried turning on VSync in xbmc with only the laptop monitor running. I can enable VSync just fine if the TV is not connected, and then I don't see any tearing.

So it seems like the card isn't getting the signal it wants back from the TV before it generates an interrupt, hence I get a hang when attempting to use VSync on the TV. There's nothing fancy there, I just use xrandr to turn the laptop monitor off after I'm logged in and set a reasonable resolution on the TV. And since xv doesn't have a problem with vsync on the TV, it appears to be possible. Can you see a way around it?

Apart from filing a bugreport to the developers or fixing the driver yourself I don't know any solution for this.

bobo1on1 Wrote:Apart from filing a bugreport to the developers or fixing the driver yourself I don't know any solution for this.

I had to go to work, but I will do some more diagnostics (I'm curious to see what happens if I have both monitors displaying the same thing) and file a bug report once I get home this evening.

jw5801 Wrote:man radeon:

Code:
Option "EXAVSync" "[b]boolean[/b]" This option attempts to avoid tearing by stalling the engine until the display controller has passed the destination region. It reduces tearing at the cost of performance and has been know to cause instability on some chips. The default is off.

xorg.conf:

Code:
... Section "Device" Identifier "Card0" Driver "ati" VendorName "All" BoardName "All" Option "AccelMethod" "EXA" Option "EXAVSync" "[b]TRUE[/b]" EndSection ...

A boolean in most cases means "true" or "false", but "on" and "off" can also be a boolean I think. However, in xorg.conf they tend to use True and False. So I tried what you suggested above exept w/ TRUE instead of ON. But results are hor-ri-ble. Screen blanks out every half second or so. And the hor. tearing issues aren't gone either.

Indeed, it is strange that mplayer with xv as video output works so good and GL as video out doesn't. Aaaaarghhh.

I've searched the internet and these forums, but can anybody explain why Ati/AMD cards work so badly w/ XBMC? Otherwise they seem to function just fine w/ the newer open source drivers (i.e. radeon or radeonhd for newer cards).

xbmcuser01 Wrote:A boolean in most cases means "true" or "false", but "on" and "off" can also be a boolean I think. However, in xorg.conf they tend to use True and False. So I tried what you suggested above exept w/ TRUE instead of ON. But results are hor-ri-ble. Screen blanks out every half second or so. And the hor. tearing issues aren't gone either.

Indeed, it is strange that mplayer with xv as video output works so good and GL as video out doesn't. Aaaaarghhh.

I've searched the internet and these forums, but can anybody explain why Ati/AMD cards work so badly w/ XBMC? Otherwise they seem to function just fine w/ the newer open source drivers (i.e. radeon or radeonhd for newer cards).

That setting makes no difference whatsoever to video playback in xbmc. The vsync setting within xbmc is the only thing that will change playback.

The bug I am seeing here is specifically a bug in the radeon OpenGL implementation which causes the GLX_SGI_video_sync extension not to work correctly over VGA (at least with my card). If this is the problem you are replicating, then you should add some more information (on your setup) to my bug report, here.

If you're not running over VGA and don't see similar output as I've reported from mplayer when you run it with -vo gl, or in xbmc when you enable vsync then you are likely having a different issue.

jw5801 Wrote:That setting makes no difference whatsoever to video playback in xbmc. The vsync setting within xbmc is the only thing that will change playback.

The bug I am seeing here is specifically a bug in the radeon OpenGL implementation which causes the GLX_SGI_video_sync extension not to work correctly over VGA (at least with my card). If this is the problem you are replicating, then you should add some more information (on your setup) to my bug report, here.

Submitted a comment to aforementioned bugreport. I have no idea what exactly the problem is, but Google goes back to 2006 if one types in "vblank_mode". Aaaaarghhh.

Chances seem nil the prob. will ever be fixed. So its either bye bye XBMC or bye bye Ati cards.

Problem appeared to be Ati driversa in Linux. Older cards do not support TV out w/ vert. sync quite well. I now have an (old) NVidia card and all my probs are gone. Bye bye Ati: for ever. Sad

Pages: 1 2