Desktop Video corruption & VDPAU playback freeze w/180.44 and 185.19 on 8400GS

[oldcpu]

This post is intended to be a bug report (I hope this is the correct forum for it) on the 180.44 driver and 185.19 driver. Please delete thread if this is not appropriate location.

Problem:

On openSUSE-11.1 with KDE-3.5.10 desktop with BFG 8400GS PCI 256MB (not PCI-e) card on 9 year old Athlon-1100 (1GB RAM) , with both 180.44 driver and 185.19 driver, obtain the same anomalous behaviour.

• The behaviour on the desktop is corruption in the openSUSE desktop theme (KDE classic theme lasts many minutes longer before corruption - but still occurs) , especially if large icons are chosen on desktop, but still occurs with small icons. Corruption is also icon independant. Example screen shot: http://img218.imageshack.us/img218/4...th18519scr.jpg
  Problem does not occur when using VESA driver
• the VDPAU anomalous behaviour is a freeze of the video after a short period of playing the video under the Packman packaged mplayer MPlayer-1.0rc2_r29116-2.pm.2 This occurs playing HD Videos and also playing DVD compliant MPEG files created by application tovid tovid-0.40-2777.pm.svn20081205_1 (which uses mencoder and ffmpeg). Playing mpeg files back with mplayer without vdpau option works fine. (Of course HD definition videos do not play back without vdpau)

Examples of vdpau error messages:

lee@stonehenge01:~/computer/camcorder/test/h264clips> mplayer -vo vdpau -vc ffh264vdpau Serenity\ -\ HD\ DVD\ Trailer.mp4
MPlayer dev-SVN-r29116-4.3-openSUSE Linux 11.1 (i686)-Packman (C) 2000-2009 MPla
yer TeamCan't open joystick device /dev/input/js0: No such file or directory
Can't init input joystick
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing Serenity - HD DVD Trailer.mp4.
libavformat file format detected.
[lavf] Video stream found, -vid 0
[lavf] Audio stream found, -aid 1
VIDEO:  [avc1]  1280x720  24bpp  23.976 fps    0.0 kbps ( 0.0 kbyte/s)
Clip info:
 name: Serenity - HD DVD Trailer
 author: Universal Pictures
==========================================================================
Forced video codec: ffh264vdpau
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
[VD_FFMPEG] XVMC-accelerated MPEG-2.
Selected video codec: [ffh264vdpau] vfm: ffmpeg (FFmpeg H.264 (VDPAU))
==========================================================================
==========================================================================
Opening audio decoder: [faad] AAC (MPEG2/4 Advanced Audio Coding)
FAAD: compressed input bitrate missing, assuming 128kbit/s!
AUDIO: 48000 Hz, 2 ch, s16le, 128.0 kbit/8.33% (ratio: 16000->192000)
Selected audio codec: [faad] afm: faad (FAAD AAC (MPEG-2/MPEG-4 Audio))
==========================================================================
AO: [oss] 48000Hz 2ch s16le (2 bytes per sample)
Starting playback...
[VD_FFMPEG] XVMC-accelerated MPEG-2.
VDec: vo config request - 1280 x 720 (preferred colorspace: H.264 VDPAU accelera
tion)
VDec: using H.264 VDPAU acceleration as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
VO: [vdpau] 1280x720 => 1280x720 H.264 VDPAU acceleration
[vdpau] Error when calling vdp_presentation_queue_block_until_surface_idle: The
display was pre-empted, or a fatal error occurred.
[vdpau] Error when calling vdp_video_mixer_render: An invalid handle value was provided.
[vdpau] Error when calling vdp_presentation_queue_display: An invalid handle value was provided.
[vdpau] Failed VDPAU decoder rendering: An invalid handle value was provided.
[vdpau] Error when calling vdp_presentation_queue_block_until_surface_idle: An invalid handle value was provided.
[vdpau] Error when calling vdp_video_mixer_render: An invalid handle value was provided.
[vdpau] Error when calling vdp_presentation_queue_display: An invalid handle value was provided.
[vdpau] Failed VDPAU decoder rendering: An invalid handle value was provided.
[vdpau] Error when calling vdp_presentation_queue_block_until_surface_idle: An invalid handle value was provided.
[vdpau] Error when calling vdp_video_mixer_render: An invalid handle value was provided.
[vdpau] Error when calling vdp_presentation_queue_display: An invalid handle value was provided.
[vdpau] Failed VDPAU decoder rendering: An invalid handle value was provided.

Some notes - the Athlon-1100 PC in which this runs has a 350 watt original power supply, and is 9 years old. The BFG 8400GS card requires a 300 watt power supply. I assume the power supply is still adequate after 9 years. I note same problem with desktop graphic corruption does not occur with VESA driver hence giving me faith in power supply. There is no evidence of over heating in the PC, as fans are clean and functioning well.

Attached are nvidia-bug-report.log files from both 180.44 and 185.19 occurrences of the problem on this same PC.

[mathog]

Originally Posted by oldcpu

Some notes - the Athlon-1100 PC in which this runs has a 350 watt original power supply, and is 9 years old. The BFG 8400GS card requires a 300 watt power supply. I assume the power supply is still adequate after 9 years. I note same problem with desktop graphic corruption does not occur with VESA driver hence giving me faith in power supply. There is no evidence of over heating in the PC, as fans are clean and functioning well.

Your assumptions may not be valid. Due to capacitor degradation with time your motherboard may be drawing more power than it once did, for the same reason the power supply may not be able to provide as much power as before (or less clean power at higher wattage). The VESA driver may not push the graphics card nearly as hard as the Nvidia driver. I once had a set of computers with power supply capacity "on the edge", these ran fine up until SpecViewPerf started, when some of them would crash. The fault moved around with the power supplies. They were all apparently within a few percent of capacity, some just over, some just under. In that case adding a single 80mm case fan was enough to switch some machines from working with SpecViewPerf to not working. Similarly, unplugging all the case fans on some of those that were failing was enough to get them working again.

[cehoyos]

Originally Posted by oldcpu

• The behaviour on the desktop is corruption in the openSUSE desktop theme (KDE classic theme lasts many minutes longer before corruption - but still occurs) , especially if large icons are chosen on desktop, but still occurs with small icons. Corruption is also icon independant. Example screen shot: http://img218.imageshack.us/img218/4...th18519scr.jpg
  Problem does not occur when using VESA driver
• the VDPAU anomalous behaviour is a freeze of the video after a short period of playing

I'd like to confirm that I did see the very same issues (although desktop image corruption was much worse), but cannot reproduce them at present, neither on a Core2, an Athlon XP or a Katmai.
A possible fix for the corruption problem was the removal/change of other PCI cards.
Driver version may not be the cause, because I just tested with 180.37 (and regularly use newer versions).

Attached are nvidia-bug-report.log files from both 180.44 and 185.19 occurrences of the problem on this same PC.

Please read http://www.nvnews.net/vbulletin/showthread.php?t=123819 and post a full bug report here for the pre-emption problem.

Carl Eugen

[Stephen Warren]

FYI, I have previously tested "h264info.com/serenity_hd_dvd-trailer.zip/Serenity - HD DVD Trailer.mp4" on all our supported video HW, and it works fine with recent driver releases. If you're still having the problem with 185.19, I suspect it's HW related.

[jyavenard]

Originally Posted by mathog

Your assumptions may not be valid. Due to capacitor degradation with time your motherboard may be drawing more power than it once did, for the same reason the power supply may not be able to provide as much power as before (or less clean power at higher wattage). T

Since when will a 8400gs uses 300W of power?

50W max most likely

[mathog]

Originally Posted by oldcpu

BFG 8400GS PCI 256MB (not PCI-e) card on 9 year old Athlon-1100 (1GB RAM)

Life on on the trailing edge can be nearly as bloody as on the leading edge.

What kind of PCI slot is it? At 9 years old it may not be a very fast. Possibly the Nvidia driver occasionally needs to move data faster than it can handle.

Is the IRQ for the graphics card shared with another device? If so perhaps you can set a jumper or move cards around to remedy that.

Since this is an Athlon, is "athcool" running? That software installs by default on many (most) newish Linux distros and it can cause all sorts of odd problems, typically sound issues and a decrease in network throughput, but with an old PCI slot, graphics problems are not out of the question.

[oldcpu]

Originally Posted by cehoyos

Please read http://www.nvnews.net/vbulletin/showthread.php?t=123819 and post a full bug report here for the pre-emption problem.

OK, I finally was able to get some time on this.

I asserted:

# If you use bash:
export VDPAU_TRACE=1
export VDPAU_NVIDIA_DEBUG=3

and then played the "h264info.com/serenity_hd_dvd-trailer.zip/Serenity - HD DVD Trailer.mp4" video. The vdpau playback problem (which is easily reproduceable) occurred again, and I posted the bash shell output when the error occured and the output of running nvidia-bug-report.sh as root as attachments to this post.

Reference the desktop corruption that also occurs, I note now that is specific to the desktop background, ... other openSUSE users have reported something similar in kde3 and kde4, and it may be associated with problems noted in this openSUSE thread:
http://forums.opensuse.org/hardware/...kde-login.html
In my case it does occur immediately if an openSUSE desktop theme is used (it takes minutes to occur with the classic KDE theme) and the background corruption also occurs quickly if large icons are used. ... whether that corruption problem also leads to the vdpau problem, I can't say.

Reference the 300 watt requirement for the 8400GS PCI card, I'm no expert in this. That requirement is straight off of the BFG GeForce 8400 GS PCI (512MB) specification sheet, where under minimum system requirements, they specifically state "300 W system power supply".

I do not have MS-Windows on this PC (an athlon-1100 with an MSI KT3 Ultra motherboard and 1GB RAM), so I can not test it under MS-Windows. However I may in the course of the next few weeks move the PCI card to another slightly newer PC (4 year old Asus A7N8X Deluxe with 2GB RAM) and I'll report on the results with that.

[oldcpu]

Originally Posted by oldcpu

OK, I finally was able to get some time on this.

Further to this I tested the same video on same PC with same 8400GS graphic card, using:

mplayer -vo vdpau -vc ffh264vdpau video.mp4

where freeze problem occurs.

I also tested it under

mplayer -vo vdpau -vc ffh264 video.mp4

where freeze problem occurs in both cases (and video lags audio significantly)
and

mplayer video.mp4

with no freeze problem, but video lags audio signficantly

were video.mp4 is the Serenity video noted above in a previous post.

[oldcpu]

Originally Posted by mathog

What kind of PCI slot is it? At 9 years old it may not be a very fast. Possibly the Nvidia driver occasionally needs to move data faster than it can handle.

Is the IRQ for the graphics card shared with another device? If so perhaps you can set a jumper or move cards around to remedy that.

I believe it is a PCI-2.0 (32-bit PCI bus slot, supports 3.3V/5V PCI bus interface), where the card puportedly works in such an old PCI slot.

Reference interrupts, that is possible ... I note IRQ 16 has the graphic card:

lee@stonehenge01:~> cat /proc/interrupts
           CPU0
  0:        125   IO-APIC-edge      timer
  1:       1747   IO-APIC-edge      i8042
  3:          2   IO-APIC-edge
  4:          2   IO-APIC-edge
  6:          5   IO-APIC-edge      floppy
  7:          0   IO-APIC-edge      parport0
  8:          0   IO-APIC-edge      rtc0
  9:          0   IO-APIC-fasteoi   acpi
 12:      67535   IO-APIC-edge      i8042
 14:      24926   IO-APIC-edge      pata_via
 15:       4196   IO-APIC-edge      pata_via
 16:      89734   IO-APIC-fasteoi   ehci_hcd:usb3, nvidia
 18:       4960   IO-APIC-fasteoi   uhci_hcd:usb1
 19:       3062   IO-APIC-fasteoi   uhci_hcd:usb2, eth0
 21:          0   IO-APIC-fasteoi   uhci_hcd:usb4, uhci_hcd:usb5
 22:      19125   IO-APIC-fasteoi   VIA8233A
NMI:          0   Non-maskable interrupts
LOC:     252235   Local timer interrupts
RES:          0   Rescheduling interrupts
CAL:          0   function call interrupts
TLB:          0   TLB shootdowns
TRM:          0   Thermal event interrupts
SPU:          0   Spurious interrupts
ERR:          0
MIS:          0

... as noted .. hopefully sometime soon I'll find the time to test it in another slightly newer PC.

[oldcpu]

Originally Posted by mathog

Since this is an Athlon, is "athcool" running?

I don't think it is. "lsmod | grep athcool" yields nothing, and "rpm -qa | grep athcool" also yields no rpm by that name. ... but I'm not familiar with "athcool" and I may be looking in the wrong place.

[cehoyos]

Originally Posted by oldcpu

mplayer -vo vdpau -vc ffh264vdpau video.mp4

Is there any difference between this command line and the one in your earlier post where you added the (sadly incomplete) mplayer output?

mplayer -vo vdpau -vc ffh264 video.mp4

mplayer video.mp4

These obviously only make sense with -speed 0.3 on a slow computer.
(Additionally, note that your command lines are identically for latest MPlayer svn, so either they do not make any difference, or you are testing an old version.)

Carl Eugen

[oldcpu]

Originally Posted by cehoyos

Is there any difference between this command line and the one in your earlier post where you added the (sadly incomplete) mplayer output?

These obviously only make sense with -speed 0.3 on a slow computer.
(Additionally, note that your command lines are identically for latest MPlayer svn, so either they do not make any difference, or you are testing an old version.)

Carl Eugen

The "video freeze" anomalous symptoms are the same between

mplayer -vo vdpau -vc ffh264vdpau video.mp4

and

mplayer -vo vdpau -vc ffh264 video.mp4

I did not compare the output error messages in the bash shell. However the second mplayer command (with "ffh264" instead of "ffh264vdpau" ) plays the video VERY slow.

Apologies for any complete mplayer output. When the error appears, the bash shell gets flooded with the same error over and over again. I need to quickly press <CTRL><C> to stop the scrolling, else I miss the transition from proper execution (of the graphic card with vdpau) to where the error occurs. What part am I missing that you wish to see? This is not difficult to run again.

When I play the video with

mplayer video.mp4

the video plays even slower (audio is ok) and there is no freezing of the video. But of course the audio ends, and the video is still dragging on in slow motion.