Fixing a problem with received video in Skype when using the AMD Catalyst (FGLRX) driver in Linux

Some users of Skype for Linux have reported that the bottom half of the received video image is corrupted in installations that use the closed-source video driver for ATI GPUs (the AMD Catalyst proprietary Linux driver, also known as the ‘FGLRX’ driver). One user described the lower half of the video image as “covered in small coloured squares like a chequer board”.

From what I have read in a few forums, it seems the problem does not occur when the open-source Radeon driver is used. My own experience corroborates that: I use the Radeon driver on one of my laptops, and received video in Skype is fine.

My main laptop has an AMD ATI Mobility Radeon HD 5650 GPU and I am using the Catalyst driver under Gentoo Linux. In this case there was a problem with received video in most Skype sessions. Either of the following effects usually occurred:

Snapshot 1 - Extract of received video image in Skype, showing an example of the corrupted image

Snapshot 1 - Extract of received video image in Skype, showing an example of the corrupted image

Snapshot 2 - Extract of received video image in Skype, showing another example of the corrupted image

Snapshot 2 - Extract of received video image in Skype, showing another example of the corrupted image

As shown in Snapshot 1, the lower half of the received video image was covered in a grid of thin green lines with areas tinged with purple, blue or green, whereas there was no grid of lines in the upper half of the image but some areas were tinged with red or blue.

As shown in Snapshot 2, the lower half of the received video image was covered in a grid of thin red lines, with a purple tinge in some areas, whereas there was no grid of lines in the upper half of the image, which looked reasonable but had some red-, green- or blue-tinged areas.

In all cases Skype’s thumbnail of my Webcam’s video image looked fine, and the person on the other end of the call said the video image received from me looked fine too.

Because of a bug in a previous version of the Catalyst driver a few years ago — see my blog posts Playing QuickTime videos in Firefox and Chromium + XVideo bug in AMD Catalyst 11.11 and 11.12 driver and AMD Catalyst for Linux driver 12.2 fixes the XVideo bug that crashed X.Org Server 1.11.x — I happen to know that Sykpe uses X11 overlays with the XVideo extension (xv), rather than using the OpenGL renderer (gl) or X11 with the SHM extension (x11). This made me wonder whether the use of XVideo with the Catalyst driver was causing the current problem. Unlike media players such as MPlayer and VLC, it is not possible to configure Skype to use gl or x11 instead of xv, so I thought it would not be possible to test whether the use of gl or x11 instead of xv would make a difference. Until, that is, I came upon a ‘trick’ posted by openSUSE user queequeg in 2009 during the period when an earlier version of the Catalyst driver had the aforementioned bug:

Skype Video Workaround for ATI

Anybody trying to make a video call with Skype and ATI fglrx drivers has had problems due to Skype using the “xv” video mode with the driver can’t handle. For anyone interested that is affected by this, there is a workaround:

1. Run the xvinfo command and look at the number of xv sessions available. Some cards have only 1, some have as many as 4. This is the number of xv occurances that the card can do at one time.
2. “Use up” all these xv sessions by opening videos in your favorite video player making sure to use xv for the video output. The videos can then be paused.
3. Once this (or they) are open, skype can be started and will default to X11 video and work properly with video calls.

I know this is a goofy way to get around this issue, but until fglrx can handle xv or skype allows an option to choose X11 for video render, I don’t know of any other way to do it.

(From what I hear, the 11.1 fglrx drivers can handle xv, but I haven’t confirmed this.)

So I tried his work-around. I had to launch four media players in order to use all available XVideo sessions. Lo and behold, when I launched Skype and made a video call the received video image was perfect. So it appeared that the Catalyst driver is not able to handle well the XVideo output from Skype. However, playing and pausing four videos every time I want to make a video call in Skype would hardly be practical, would it? And that is not the only downside: when I maximised a Firefox window during the Skype video call, my laptop spontaneously rebooted (I assume the X.Org server crashed).

I did also wonder whether just disabling compositing would solve the problem, so I disabled KWin Desktop Effects, but that didn’t make any difference.

I had also read in several forums that enabling or disabling the TexturedVideo and/or VideoOverlay options in the xorg.conf file have an effect on the video image produced by the Catalyst driver, but I could not find a post mentioning the use of either of those options to fix the specific problem I was seeing. So I decided not to pursue the xorg.conf route.

In my searches of the Web I came across a post somewhere that mentioned using GTK+ UVC Viewer (guvcview) to adjust video properties and improve video in Skype. I thought guvcview was only for adjusting the video image from a Webcam connected to my machine, i.e. adjusting the outgoing video image, and would not have any effect on received video. Nevertheless, I decided to install and launch guvcview to see if I could adjust both incoming and outgoing video properties. To my surprise, guvcview appeared to have fixed the problem with the received video. These are the steps I followed:

  1. I launched Skype and started a video call. The received video image had a grid of thin red lines and purple/green/blue tinting (similar to Snapshot 2).
  2. I Installed guvcview using the package manager.
  3. I launched guvcview in a Konsole (terminal) window. After guvcview created the file /home/fitzcarraldo/.config/guvcview/video0 and checked various video and audio settings it exited because my Webcam was being used by Skype (‘libv4l2: error setting pixformat: Device or resource busy‘).
  4. I clicked on the Webcam icon in the Skype call window, to turn my Webcam off.
  5. I launched guvcview again. The lower half of the received video image in Skype changed from a grid of thin red lines to a continuous green-coloured band, and the upper half of the image now looked reasonable but still had some red- or blue-tinged areas (see Snapshot 3 below).
  6. Snapshot 3 - Extract of received video image in Skype after I launched guvcview again

    Snapshot 3 - Extract of received video image in Skype after I launched guvcview again

  7. On the ‘Image Controls’ tab in the ‘GUVCViewer Controls’ window I changed the video frequency from 60 Hz to 50 Hz then back to 60 Hz again. I was just tinkering, and I believe this had no bearing on the outcome.
  8. I clicked on the ‘Quit’ button in the guvcview window to terminate the application.
  9. I clicked on the Webcam icon in the Skype call window to turn on again the Webcam, and the received Skype video image changed to a perfect image (see Snapshot 4 below).
  10. Snapshot 4 - Extract of received video image in Skype after I turned on again my Webcam in Skype

    Snapshot 4 - Extract of received video image in Skype after I turned on again my Webcam in Skype

It appears that guvcview had an effect on the received video image in Skype, although, if it did, I do not understand how. To check if the fix was permanent I ended the Skype video call, signed out of Skype and quit the application, rebooted and made a new Skype video call. The received video image in Skype was again perfect. I even deleted the guvcview configuration file and repeated this check, just in case the configuration file was somehow being used even though I had not launched guvcview, but the received video in yet another Skype video call was still perfect. I also clicked on the Webcam icon in the Skype call window several times during each call in order to turn my Webcam off and on several times; the received video image of the other person remained perfect.

So there you have it: when using an AMD ATI GPU and the Catalyst driver, it seems that guvcview can be used — at least in my case — to eliminate the type of image corruption in received Skype video shown in Snapshots 1 and 2. So, if you are also using the AMD Catalyst for Linux driver and are experiencing a similar problem, try guvcview. It might just do the trick.

Not all laptops are designed equal

Over time it is common for fans in laptops to become clogged with dust, fluff and even hair. The symptoms are usually a hotter laptop and a noisier fan that runs more frequently. The solution is to open up the laptop’s body in order to get at the fan and remove the crud with tweezers and by blowing. However, dismantling many laptops to access the fan makes the Mission Impossible break-in look simple, and this seems to be getting worse as laptop prices continue to decrease. If you are not confident you can unblock the fan yourself, you’ll have to find a local computer repair shop and you may find it’s not cheap. For some models the dismantling procedure can be so complicated that people post videos on YouTube. Often it is necessary to remove numerous screws, ribbon cables, jumper leads, plastic strips and the keyboard. In some cases you have to disassemble the laptop almost entirely. Fortunately, in the case of RAM modules there is often a hatch in the laptop’s base to facilitate access, but even adding or replacing RAM modules can sometimes be a major task (I used to own an Acer laptop that required the laptop base and keyboard to be removed in order to access the RAM modules).

Not long ago I had the misfortune to have to dismantle an Acer Aspire 5536-643G25Mn and a Toshiba Satellite C660-1J2 to remove accumulated fluff from the fans. I had to study YouTube videos carefully and could not believe how difficult it was to get access to the fan in the Acer Aspire. Dismantling the Toshiba Satellite to access the fan was not quite as bad as the Acer Aspire but was still a major task and, despite being as careful as possible, I still managed to break a fragile plastic lug on one of the base panels.

Last week my main laptop, a Compal NBLB2, seemed to be running a little hotter than usual, so I decided it was time to check if its fan also needed cleaning. What a pleasure that was in comparison to the other manufacturers’ laptops. The NBLB2 has a large plate in the base that, by removing only three screws (see the first photograph below), allows easy access to the fan and RAM modules. In less than five minutes I was able to remove a wad of fluff from the fan, replace the plate and power up the laptop again. Hats off to Compal for thinking about maintenance when designing this laptop. I only wish other laptop manufacturers did the same.

So, next time you need to buy a new laptop, do some research on how easy it will be to access the fan in case it needs to be cleaned. Look at the laptop’s base and check on the Web for a service manual, a YouTube video of it being disassembled, and comments in laptop/notebook forums. At least then you’ll know whether you stand a chance of avoiding paying a repair shop just to remove crud that inevitably builds up over time in the fan.

Base of Compal NBLB2 showing screws removed from main base plate

Base of Compal NBLB2 showing the 3 screws removed from the main base plate.

Base of Compal NBLB2 with main plate removed

Base of Compal NBLB2 with main plate removed. Notice how easy it is to access the fan and RAM modules.

AMD Catalyst for Linux driver 12.2 fixes the XVideo bug that crashed X.Org Server 1.11.x

Just a brief ‘heads up’ for users of the closed-source FGLRX driver in Linux: In a previous blog post I mentioned a bug in the AMD Catalyst driver for Linux that caused X.Org Server 1.11.x to crash if you tried to play a video and your media player was configured to use XVideo (Xv) output. The bug also meant that people talking to you via Skype could not enable their Web cams or X.Org Server 1.11.x would crash on your machine, as Skype uses XVideo.

The problem occurred with versions 11.11, 11.12 and 12.1 of the FGLRX driver (the package x11-drivers/ati-drivers). Well, today I installed version 12.2 of the driver and am pleased to report that I can again set media players to use Xv output without causing the X.Org Server to crash (I’m currently using xorg-server-1.11.4). Likewise, other people who I am talking to via Skype can again enable their Web cams without causing the X.Org Server on my machine to crash.

Follow

Get every new post delivered to your Inbox.

Join 52 other followers