Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I have been back with Windows 7 for quite some time, after zipping between Windows and Linux since 2008, and having a brief balk at Windows 10, but think that Gnome 3 is starting to shape up, and am once again hardening to MS's business practice and aesthetics. I've been meddling with some distros - currently typing this in Mint Mate 17.1 on an old Thinkpad - and thinking I may pass my W7 license on to a nephew to finally force making the break for good to Linux, but my stumbling block even when I can ignore other things that annoy me is always tearing in videos/ DVD. (I don't own a TV or TV facilities and watch a film several nights a week on the PC.) I have a quite reasonable £75 video card, an ATI Radeon 6670 which does well in Windows with a 27 inch Acer monitor, but the tearing is back trying out Linux isos today. I've never had any luck getting rid of it altogether. What is it about? Is it not so bad with nVidia? (There is a very modest nVidia chip with my desktop PC's motherboard but i'd consider buying better if it'll solve this.) I'm sure I never cured it with onboard Intel graphics either. Is it present still with very expensive or at least cards double or treble the price of mine? I've used open source and proprietary drivers. As you can imagine, I've read up on this at each version of this battle I've attempted. As of February 2016, has there been a breakthrough?
What it comes down to is that hardware decoding uses a video overlay which is not exactly aware of your displays refresh rate and tends to push frames out of sync (this was my experience on an old ass macbook pro with a nvidia chipset) . It required setting a few env vars to make mplayer and vdpau aware of which screen to sync to . My memory is hazy as to which ones but they are mentioned in the mplayer docs. Pretty sure that there is something similar in ATI Land.
Tearing on video playback is present when the presentation method does not use vsync. It is not related to the video decoding per se, it is related the chosen method of presentation.
Best tear-free solutions:
1. Use a presentation mode that is vsynced by default
- VDPAU - The nvidia proprietary and amd open source drivers have the VDPAU hardware decoding and presentation implemented. This is composed of 2 parts:
- the hardware decoding which is the method used to offload the decoding of the video stream to the video card's dedicated decoder chips. Note that not all formats can be decoded by hardware (the card's firmware has a list of formats it can decode - and in case of the amd OSS drivers the driver implementation further reduces this list) - use the vdpauinfo command to list them. But generally the h264 streams can be decoded.
- the presentation which is the overlay method used to display the decoded stream. This is a tear-free solution.
The above 2 components of VDPAU can be used separately, but best is to use them together.
Notes:
- The hardware decoding and presentation can be used ONLY by progras that have explicitly written, its not and "automatic" solution.
vlc, mplayes, mpv, xbmc/kodi have vdpau support among others. No web browser to date has hardware decoding capability (although Chrome/Chromium reports GPU hardware decoding capabilities they dont actually use them).
- If you have a 5xxx or newer series AMD card used with the OSS drivers, for this to work you have to install the non-free firmware (on Debian/Ubuntu this is either firmware-linux-nonfree or, more recently, firmware-amd-graphics package).
- VAAPI - This is Intel's hardware decoding and presentation method, used obviously with Intel cards (but you need an i series generation card, older cards are very limited). This is actually has more features than VDPAU - besides hardware decoding and presentation it can actually do encoding (encoding was working only with transmageddon on a 3000 and a 4600 Intel card). Note that Intel's drivers have an issue with tearing nowadays.
- as for VDPAU, VAAPI has access to the video cards dedicated video decode components, has a pre defined list of formats that can be decoded and needs the program support it.
- It has a presentation layer is, but this is not used in all programs. Vlc for example has no vaapi video out module. But kodi and mpv have it and its tear free.
Generic video playback methods (playback only)
- XV - This is only a presentation method, the oldest de-facto Linux video playback method. This uses acceleration and is generally vsynced but not always - for example most drivers can have issues with tearing using xv. I had tearing issues with Intel's drivers, AMD's drivers and alsi NVIDIA's drivers using xv for playback. Sometimes it did work well but not always and for me its flaky especially with newer mesa and x servers.
- Opengl - This method (used in browsers if you check the "use hw acceleration" buttons can be used in pretty much any video player. Its basically a hardware-accelerated overlay that used the cards opengl capabilities. But its not consistent as sometimes can have tearing issues regardless of vsync settings.
2. Force vsync on the X server itself:
Intel and amd OSS drivers with newer X servers have a TearFree option that has to be set from xorg.conf, its off by default. This option forces EVERYTHING to be vsynced including even non-hardware accelerated windows.
Note that have a fairly new X server (1.18.1, the standard now in Debian Testing) on my laptop with Intel 4600 and on my desktop with AMD and 1.16 version on my personal laptop with Intel 3000 (this laptop has Debian Stable on it with kernels and video drivers from backports).
- Behavior on Intel - generally works, but in some cases it just "loses" the vsync for some reason on my Testing rig.
- Behavior on AMD - it works beautifully. On my desktop rig i have a built in AMD video card (named Radeon HD 8570D, but its a 6000 series based chip using the r600g driver) and i use this TearFree option and EVERYTHING is perfectly vsynced, every video in all browsers, and even every game (i hate tearing in games). Note that i also use glamor for acceleration but this option seems to work the same way with the default EXA acceleration.
what driver is your card currently using?
output of
Code:
lspci -k | grep -A5 VGA
if it uses radeon, i think it might benefit from the proprietary driver, but there can be some snitches with amd/ati/radeon.
please consult linux mint / ubuntu wiki.
also, please disable compositing completely (usally under window manager tweaks in the settings ui).
if it uses radeon, i think it might benefit from the proprietary driver, but there can be some snitches with amd/ati/radeon.
please consult linux mint / ubuntu wiki.
For his card (r600g driver) OSS radeon should work really well. fglrx only helps if you explicitly need better OpenGl compliance (gaming). But that too only appies to some games, not all.
For any other thing, the opensource radeon is better, including video playback where is net superior since it actually provides a dedicated interface for tear free playback.
fglrx on the other hand doesnt have this feature and has tearing issues unless you set its own tearfree setting (from Catalyst Control Center) and that sometimes make playback choppy.
And yes fglrx it can do hardware decoding, but its done via a proprietary method (xvba) and there are no video players that support it directly (xbmc was, at some point but the xvba support was dropped when OSS radeon-vdpau appeared). Only way is to use the xvba plugin under vaapi and that is way less effective than using it directly and also leads to decoding artifacts and program crashes. VDPAU on the OSS driver is much better since it talks directly to the UVD unit and uses less resources.
Quote:
Originally Posted by ondoho
also, please disable compositing completely (usally under window manager tweaks in the settings ui).
+1 to this.
In fact i recommend using a desktop environment that doesnt use compositing at all. I used xfce and mate on my computer and they are rock solid with the radeon driver on my AMD Radeon HD 8570D IGP (which is 6000 series based, not GCN).
so it seems to be a general case of "hardware barely coping", and maybe also a case where window (7) handles itself better.
i see now from post #1 that you, tpprynn, are using gnome3 - i'm sure your assessment of its development is right but it is hardly the desktop for aging hardware.
esp. in regard to compositing; i'm not sure gnome3 can even run or work properly without compositing (i know unity can't).
Yeah, DEs that REQUIRE compositing and re invent the "desktop" add complications for no real reason whatsoever.
"OOh, look at that terminal background transparency and how windows are fading in and out. Umm, now lets search Google how to switch between windows. Damn, the login screen again. Linux sucks."
Sorry, I might have misunderstood something. When you mention OSS Radeon is that a third option, a third driver aside from the automatically chosen fglrx that for example Ubuntu install uses and the proprietary AMD driver, or is this OSS [etc] an option in various video software? I may have been thrown by the acronym as I remember audio drivers using it.
I downloaded the proprietary driver today, as a .run file direct from the AMD site. Do I need it for a tear-free experience/ is it best avoided?
I should add that despite my current tinkering invooving Gnome 3 I also have a perverse liking for Fluxbox so I will try out video and DVDs using that too. The spec of my desktop PC isn't too bad though. Quad core, 3ghz, 4gb ram, an SSD and the HD 6670 card mentioned. Not top of the range stuff of course but above average I had thought.
Just gone midnight here and I'm a bit delirious so I'll work with this tomorrow.
- Open Source (comes with the Linux kernel and uses user-space libraries mesa and drm).
Can be referred to as radeon, radeon OSS, open source amd driver. "OSS" is from open source (as opposed to proprietary), has nothing to do with the deprecated OSS audio interface. This is what i recommend for this scenario.
- Proprietary. Has to be installed and compiled separately. During installation it will create a kernel module named fglrx.
Referred to as catalyst (from its Catalyst Control Center), fglrx or amd proprietary driver
*Note that this driver's ".run" generic uninstaller overwrites libraries that come with the system during installation. Sometimes the kernel module installation fails and you will be left with a crippled system (the helper libraries are copied before the kernel module installation). The uninstaller script doesnt always work (mostly not) in recovering the replaced files, the recovery method is to force reinstall certain packages.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.