10.5 is out. come and get it.

[WildcatWhiz]

You are making yourself look even more like a noob. The tearing is part of the video output on the media player, not the CPU. Set your output module to OpenGL and set Vsync inside Catalyst to "On, unless otherwise specified" and watch tearing magically disappear. BTW, I am not trying to belittle you, but you might want to do a bit more research before posting.

Calling me a "noob" isn't belittling?

Fact: On Windows 7, which has full GPU-decoding of H.264 content, I experience no tearing.

Fact: On Linux, where GPU-decoding is not supported (hence all decoding of h.264 content is handled by the CPU) I do experience tearing, even with OpenGL/Vsync enabled. The HD5xxx cards don't support GPU-decoding in Linux. Plain and simple. Unless someone figures out how to tap into xvba, I'm screwed.

What doesn't make sense to you?

[bwat47]

Calling me a "noob" isn't belittling?

Fact: On Windows 7, which has full GPU-decoding of H.264 content, I experience no tearing.

Fact: On Linux, where GPU-decoding is not supported (hence all decoding of h.264 content is handled by the CPU) I do experience tearing, even with OpenGL/Vsync enabled. The HD5xxx cards don't support GPU-decoding in Linux. Plain and simple. Unless someone figures out how to tap into xvba, I'm screwed.

What doesn't make sense to you?

Well I dont think the fact that it doesnt have gpu decoding is the issue... Its that fglrx has crap vsync.

I use the OSS drivers which support absolutely no gpu acceleration for videos of any kind and I get no tearing at all in compiz or videos by default.

[bridgman]

WildcatWhiz, it's equally true to say :

Fact. On Windows 7, which has a "W" in its name, you experience no tearing

Fact. On Linux, which does not have a "W" in its name, you experience tearing.

Video decode acceleration does not have anything to do with video rendering, except in the occasional case where your choice of a decode component limits/affects your choice of a render output path (which is not the case here).

If you are running a compositor, turn it off for a minute, confirm that you are using GL output for video playback, confirm that you are using sync-to-vblank with a nominally 60 Hz display refresh rate (or whatever is appropriate for the video standard you are using), and that should give you tear-free video playback *without* decode acceleration.

[WildcatWhiz]

Well I dont think the fact that it doesnt have gpu decoding is the issue... Its that fglrx has crap vsync.

I use the OSS drivers which support absolutely no gpu acceleration for videos of any kind and I get no tearing at all in compiz or videos by default.

Could be. Either way, whether it be the lack of GPU-decoding, or the crappiness of Vsync, the flgrx driver is giving me all sorts of displeasure when it comes to watching movies. I bought an Ati card because I heard that AMD/Ati was more cooperative with the Linux community. Now, I appreciate the efforts (it truly seems like they're trying) but this is rather disappointing.

And no, I'm not just flaming Ati because fglrx has a history of having a bad rap. And no, I'm not going to jump ship and buy and Nvidia card. I'll be patient, hoping that the Ati team will fix these issues. Lord knows they're going up against the market forces when they devote time to writing Linux code as opposed to Windows code. I just hope these things get fixed, that's all.

If anyone knows about the progress of xvba, or any sort of GPU decoding on Linux, please let me know

[WildcatWhiz]

WildcatWhiz, it's equally true to say :

Fact. On Windows 7, which has a "W" in its name, you experience no tearing

Fact. On Linux, which does not have a "W" in its name, you experience tearing.

Video decode acceleration does not have anything to do with video rendering, except in the occasional case where your choice of a decode component limits/affects your choice of a render output path (which is not the case here).

If you are running a compositor, turn it off for a minute, confirm that you are using GL output for video playback, confirm that you are using sync-to-vblank with a nominally 60 Hz display refresh rate (or whatever is appropriate for the video standard you are using), and that should give you tear-free video playback *without* decode acceleration.

My problems with this are:

1. Windows has GPU decode. Why can't Linux? I shouldn't have to compromise.

2. Why should I have to turn of my compositor? You're saying that I'd have to disable Compiz or Kwin just to watch a movie?

I don't think we're asking for a lot here. I don't understand why I can't have similar functionality to Windows.

[mirv]

My problems with this are:

1. Windows has GPU decode. Why can't Linux? I shouldn't have to compromise.

2. Why should I have to turn of my compositor? You're saying that I'd have to disable Compiz or Kwin just to watch a movie?

I don't think we're asking for a lot here. I don't understand why I can't have similar functionality to Windows.

I think the comment was more to check that vsync works on your computer (base line test to see what's causing the issue).

[WildcatWhiz]

I think the comment was more to check that vsync works on your computer (base line test to see what's causing the issue).

I understand, and I appreciate the help. The fact that folks like Bridgman are hanging out on this forum to help people like you and me is outstanding.

I'm just frustrating is all. It's a known issue that flgrx+window compositor=video tearing.

I don't think there is a solution. I supposing I'm just /ranting.

[bridgman]

1. OK, separate issue. You *want* video decode, that's fair. The point I'm trying to make is that the presence or absence of decode acceleration is not related to tearing.

OSes with the largest market share tend to get new features first, then those features trickle down to OSes with lesser market share over time. Video decode acceleration is mid-trickle.

2. You need to turn off your compositor for testing, so you can feel confident that tearing and video decode acceleration are not linked. Then you can turn it back on again.

I'm not sure what the exact deal is with compositors and vsync; opinions seem to vary between compositor bugs which need driver hacks to work around them to missing, but unspecified features in the driver which *would* be used if they were present. Then again, my focus is on the open source side so I haven't really looked into fglrx + compositing + video.

[bwat47]

1. OK, separate issue. You *want* video decode, that's fair. The point I'm trying to make is that the presence or absence of decode acceleration is not related to tearing.

OSes with the largest market share tend to get new features first, then those features trickle down to OSes with lesser market share over time. Video decode acceleration is mid-trickle.

2. You need to turn off your compositor for testing, so you can feel confident that tearing and video decode acceleration are not linked. Then you can turn it back on again.

I'm not sure what the exact deal is with compositors and vsync; opinions seem to vary between compositor bugs which need driver hacks to work around them to missing, but unspecified features in the driver which *would* be used if they were present. Then again, my focus is on the open source side so I haven't really looked into fglrx + compositing + video.

I've been told its because fglrx uses indirect rendering for compositing which does not work with vsync at all. The open source driver seems to use direct rendering.

With fglrx setting vsync to always on, and/or setting compiz to sync to vblnank has zero effect and compiz tears quite noticeably. I can get video to not tear with compiz if I set ccc to always vsync, output video in opengl, use undirect fullscreen windows in compiz and play the vid in fullscreen but the opengl output looks like crap for me.

[bwat47]

omg I hate the one minute edit limit on these forums so much. Anyway was gonna ad at the end of my post:

With compiz off I also have to use opengl + ccc vsync to get no tearing.