VDPAU testing tool

[Stephen Warren]

morrillo, is that the entire set of errors you get? My initial guess would be that there were also some "unknown type" messages. Perhaps you have old VDPAU headers installed that don't define the MPEG-4 Part 2 types. Try the latest NVIDIA driver, or open-source libvdpau.

[wiz561]

Thanks for the tool; it gives me an idea of if things are working or not.

I'm just taking my results and averaging it with other answers on here. But can somebody comment on what you should be seeing?

Here's what I'm getting...
----
qvdpautest 0.5
AMD Athlon(tm) 64 X2 Dual Core Processor 4200+
NVIDIA GPU GeForce 9500 GT (G96) at PCI:7:0:0 (GPU-0)

VDPAU API version : 1
VDPAU implementation : NVIDIA VDPAU Driver Shared Library 195.30 Fri Dec 18 17:11:08 PST 2009

SURFACE GET BITS: 731.105 M/s
SURFACE PUT BITS: 779.474 M/s

MPEG DECODING (1920x1080): 77 frames/s
MPEG DECODING (1280x720): 153 frames/s
H264 DECODING (1920x1080): 44 frames/s
H264 DECODING (1280x720): 96 frames/s
VC1 DECODING (1440x1080): 116 frames/s

MIXER WEAVE (1920x1080): 598 frames/s
MIXER BOB (1920x1080): 1036 fields/s
MIXER TEMPORAL (1920x1080): 246 fields/s
MIXER TEMPORAL + IVTC (1920x1080): 169 fields/s
MIXER TEMPORAL + SKIP_CHROMA (1920x1080): 328 fields/s
MIXER TEMPORAL_SPATIAL (1920x1080): 93 fields/s
MIXER TEMPORAL_SPATIAL + IVTC (1920x1080): 77 fields/s
MIXER TEMPORAL_SPATIAL + SKIP_CHROMA (1920x1080): 103 fields/s
MIXER TEMPORAL_SPATIAL (720x576 video to 1920x1080 display): 351 fields/s

MULTITHREADED MPEG DECODING (1920x1080): 72 frames/s
MULTITHREADED MIXER TEMPORAL (1920x1080): 212 fields/s

---

[dk75]

qvdpautest 0.5
Intel(R) Atom(TM) CPU  330   @ 1.60GHz
NVIDIA GPU ION (C79) at PCI:3:0:0 (GPU-0)

VDPAU API version : 1
VDPAU implementation : NVIDIA VDPAU Driver Shared Library  195.30  Fri Dec 18 17:11:08 PST 2009

SURFACE GET BITS: 208.328 M/s
SURFACE PUT BITS: 167.427 M/s

MPEG DECODING (1920x1080): 56 frames/s
MPEG DECODING (1280x720): 134 frames/s
H264 DECODING (1920x1080): 51 frames/s
H264 DECODING (1280x720): 109 frames/s
VC1 DECODING (1440x1080): 67 frames/s

MIXER WEAVE (1920x1080): 277 frames/s
MIXER BOB (1920x1080): 391 fields/s
MIXER TEMPORAL (1920x1080): 104 fields/s
MIXER TEMPORAL + IVTC (1920x1080): 67 fields/s
MIXER TEMPORAL + SKIP_CHROMA (1920x1080): 143 fields/s
MIXER TEMPORAL_SPATIAL (1920x1080): 31 fields/s
MIXER TEMPORAL_SPATIAL + IVTC (1920x1080): 24 fields/s
MIXER TEMPORAL_SPATIAL + SKIP_CHROMA (1920x1080): 36 fields/s
MIXER TEMPORAL_SPATIAL (720x576 video to 1920x1080 display): 115 fields/s

MULTITHREADED MPEG DECODING (1920x1080): 56 frames/s
MULTITHREADED MIXER TEMPORAL (1920x1080): 84 fields/s

[crisalide]

Originally Posted by morrillo

mpeg4decoder.cpp: In member function ‘VdpVideoSurface MPEG4Decoder::getNextFrame()’:
mpeg4decoder.cpp:80: error: request for member ‘backward_reference’ in ‘frame->MPEG4Frame::info’, which is of non-class type ‘void*’
mpeg4decoder.cpp:81: error: request for member ‘forward_reference’ in ‘frame->MPEG4Frame::info’, which is of non-class type ‘void*’
mpeg4decoder.cpp:82: error: request for member ‘vop_coding_type’ in ‘frame->MPEG4Frame::info’, which is of non-class type ‘void*’
mpeg4decoder.cpp:83: error: request for member ‘forward_reference’ in ‘frame->MPEG4Frame::info’, which is of non-class type ‘void*’
mpeg4decoder.cpp:84: error: request for member ‘vop_coding_type’ in ‘frame->MPEG4Frame::info’, which is of non-class type ‘void*’
mpeg4decoder.cpp:85: error: request for member ‘forward_reference’ in ‘frame->MPEG4Frame::info’, which is of non-class type ‘void*’
mpeg4decoder.cpp:86: error: request for member ‘backward_reference’ in ‘frame->MPEG4Frame::info’, which is of non-class type ‘void*’
mpeg4decoder.cpp:97: error: request for member ‘vop_coding_type’ in ‘frame->MPEG4Frame::info’, which is of non-class type ‘void*’
make: *** [mpeg4decoder.o] Error 1

My bad.
I should remember to not code anything when sick
I will fix this soon.

[Enigma2175]

Results for Sparkle 9400 GT PCI:
qvdpautest 0.5
AMD Athlon(tm) Processor
NVIDIA GPU GeForce 9400 GT (G96) at PCI:2:0:0 (GPU-0)

VDPAU API version : 1
VDPAU implementation : NVIDIA VDPAU Driver Shared Library 195.30 Fri Dec 18 14:22:27 PST 2009

SURFACE GET BITS: 88.276 M/s
SURFACE PUT BITS: 54.3193 M/s

MPEG DECODING (1920x1080): 57 frames/s
MPEG DECODING (1280x720): 135 frames/s
H264 DECODING (1920x1080): 44 frames/s
H264 DECODING (1280x720): 94 frames/s
VC1 DECODING (1440x1080): 64 frames/s
Profile unsupported.

MIXER WEAVE (1920x1080): 280 frames/s
MIXER BOB (1920x1080): 466 fields/s
MIXER TEMPORAL (1920x1080): 139 fields/s
MIXER TEMPORAL + IVTC (1920x1080): 99 fields/s
MIXER TEMPORAL + SKIP_CHROMA (1920x1080): 182 fields/s
MIXER TEMPORAL_SPATIAL (1920x1080): 73 fields/s
MIXER TEMPORAL_SPATIAL + IVTC (1920x1080): 58 fields/s
MIXER TEMPORAL_SPATIAL + SKIP_CHROMA (1920x1080): 84 fields/s
MIXER TEMPORAL_SPATIAL (720x576 video to 1920x1080 display): 244 fields/s

MULTITHREADED MPEG DECODING (1920x1080): 44 frames/s
MULTITHREADED MIXER TEMPORAL (1920x1080): 118 fields/s

This card will decode using VDPAU, but it is basically unusable because it gets constant pre-emption errors (at least within MythTV). Seeing all the reports of problems from people with Sparkle 9400 GTs both here and elsewhere leads me to believe that Sparkle royally messed up on this card. The only solution I have been able to find in my searching is "return it" which isn't really an option for me. Does anyone have any workarounds for using this card? Is underclocking the card likely to change the amount of errors I get or is it more likely that this is a problem with poor design that will not get better with new drivers or software? If anyone does have a Sparkle 9400 GT PCI card working with VDPAU is there anything special you did to configure it? Are the low scores for the get bits/put bits tests (I assume the low bandwidth of the PCI bus is causing this) likely to cause problems or should that be "fast enough"?

[morrillo]

Stephen,

Thanks a lot for your quick reply, I did what you told me to do and now it works.

Just FYI, this is what I got:

qvdpautest 0.5
Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz
NVIDIA GPU GeForce 9500 GT (G96) at PCI:1:0:0 (GPU-0)

VDPAU API version : 1
VDPAU implementation : NVIDIA VDPAU Driver Shared Library 190.53 Wed Dec 9 16:28:38 PST 2009

SURFACE GET BITS: 973.156 M/s
SURFACE PUT BITS: 1021.38 M/s

MPEG DECODING (1920x1080): 78 frames/s
MPEG DECODING (1280x720): 156 frames/s
H264 DECODING (1920x1080): 45 frames/s
H264 DECODING (1280x720): 98 frames/s
VC1 DECODING (1440x1080): 122 frames/s
Profile unsupported.

MIXER WEAVE (1920x1080): 1008 frames/s
MIXER BOB (1920x1080): 1512 fields/s
MIXER TEMPORAL (1920x1080): 350 fields/s
MIXER TEMPORAL + IVTC (1920x1080): 222 fields/s
MIXER TEMPORAL + SKIP_CHROMA (1920x1080): 479 fields/s
MIXER TEMPORAL_SPATIAL (1920x1080): 108 fields/s
MIXER TEMPORAL_SPATIAL + IVTC (1920x1080): 89 fields/s
MIXER TEMPORAL_SPATIAL + SKIP_CHROMA (1920x1080): 115 fields/s
MIXER TEMPORAL_SPATIAL (720x576 video to 1920x1080 display): 408 fields/s


Thanks again for your help!

[cehoyos]

Originally Posted by Enigma2175

This card will decode using VDPAU, but it is basically unusable because it gets constant pre-emption errors (at least within MythTV).

Could you confirm that you get pre-emptions even when playing recorded media (from harddisk)? I can only get the pre-emptions for a specific motherboard, and only if I use specific hardware (DVB card) at the same time.
(And please test MPlayer, if possible.)

Is underclocking the card likely to change the amount of errors I get or is it more likely that this is a problem with poor design that will not get better with new drivers or software?

AFAIR, underclocking (and using different slots and different AGP-options) made no difference.
I would still be careful with "poor design" - after all, my card works without problems (while receiving HDTV from DVB) on my Pentium 3 500. What motherboard do you use?

Are the low scores for the get bits/put bits tests (I assume the low bandwidth of the PCI bus is causing this) likely to cause problems or should that be "fast enough"?

That is fast enough for 1080i25 decoding with VDPAU.

Carl Eugen

[Enigma2175]

Originally Posted by cehoyos

Could you confirm that you get pre-emptions even when playing recorded media (from harddisk)? I can only get the pre-emptions for a specific motherboard, and only if I use specific hardware (DVB card) at the same time.
(And please test MPlayer, if possible.)

AFAIR, underclocking (and using different slots and different AGP-options) made no difference.
I would still be careful with "poor design" - after all, my card works without problems (while receiving HDTV from DVB) on my Pentium 3 500. What motherboard do you use?

That is fast enough for 1080i25 decoding with VDPAU.

Carl Eugen

This particular motherboard is a MSI KT3 Ultra 2, I have also tried this card with a MSI Hetis 915 (Intel 82915G chipset) and a Asus Pundit PH1. All 3 systems gave me similar results. This system has one other PCI card, a 3com network card.

For this test, I played a ATSC recorded file with mplayer and MythTV. I have attached logs for both programs with preemption errors. Both programs will take longer to error if I have deinterlacing disabled. I was unable to get any of the hardware deinterlacers to work proplerly with mplayer, using anything but one-field resulted in AV sync loss, getting progressively worse. The attached log for mplayer is with temporal deinterlacing enabled.

Mplayer recovers a lot more gracefully than Myth at the "VDPAU nvidia: Error detected 0 5916" errors, but the "0 481" errors kill the display and require a machine restart to re-enable the card. Different drivers sometimes have slightly different behavior when encountering an error but the 180*, 190* and 195* drivers all had issues.

vdpau-trace-mplayer.txt.gz

vdpau-trace-mythtv.txt.gz

[cehoyos]

Originally Posted by Enigma2175

This particular motherboard is a MSI KT3 Ultra 2

which is a KT333 mainboard, exactly as the ones that fail for me.

I have also tried this card with a MSI Hetis 915 (Intel 82915G chipset) and a Asus Pundit PH1.

These aren't. I don't think your problem was reported before.

For this test, I played a ATSC recorded file with mplayer and MythTV. I have attached logs for both programs with preemption errors. Both programs will take longer to error if I have deinterlacing disabled. I was unable to get any of the hardware deinterlacers to work proplerly with mplayer, using anything but one-field resulted in AV sync loss, getting progressively worse.

This is unrelated, but surprises me. What is the refresh rate of your screen?
Since you successfully hide your MPlayer version number, could you try latest svn? I have recently committed changes that improved de-interlacing performance around 10% for me.

Mplayer recovers a lot more gracefully than Myth at the "VDPAU nvidia: Error detected 0 5916" errors

Is it always this error (or the following) and how does dmesg look like? I ask because I get random numbers with pre-emptions.

but the "0 481" errors kill the display and require a machine restart to re-enable the card. Different drivers sometimes have slightly different behavior when encountering an error but the 180*, 190* and 195* drivers all had issues.

@Stephen: Does the following line (from the logs) indicate a problem with how MPlayer tries to recover from display pre-emption?

VDPAU trace: Multiple devices created; will return get_proc_address results from the latest only

Carl Eugen

[Stephen Warren]

Originally Posted by cehoyos

@Stephen: Does the following line (from the logs) indicate a problem with how MPlayer tries to recover from display pre-emption?

VDPAU trace: Multiple devices created; will return get_proc_address results from the latest only

That's just a message from the trace library indicating that when the application calls get_proc_address on the nth VdpDevice create, the trace library will return results from querying that function on the first VdpDevice instead of the nth.

In NVIDIA's VDPAU implementation, we always return the same value for a given VdpFuncId for all VdpDevices created. In theory, another vendors' implementation could behave differently.

So, you can ignore this message.

[Enigma2175]

Originally Posted by cehoyos

This is unrelated, but surprises me. What is the refresh rate of your screen?

Hmmmm, never thought to check that before but it appears that it is at 50 Hz. I am outputting through S-Video to an NTSC set, I guess that I had assumed that it was running at 60 Hz. Any attempts to change it have been futile, xrandr fails and setting the mode to 1024x768_60 in xorg.conf fails. Am I mistaken in assuming that I should be outputting at 60 Hz for NTSC?

Originally Posted by cehoyos

Since you successfully hide your MPlayer version number, could you try latest svn? I have recently committed changes that improved de-interlacing performance around 10% for me.

I will try this when I get a chance, compiling mplayer from source is not just something I can do on a whim

My current mplayer reports "MPlayer UNKNOWN-4.4.1", dpkg says it is "2:1.0-svn29964-0ubuntu3"

Originally Posted by cehoyos

Is it always this error (or the following) and how does dmesg look like? I ask because I get random numbers with pre-emptions.

I get a few different errors, with a few different behaviors. The errors with debug enabled are:

VDPAU nvidia: Error detected 0 5916
VDPAU nvidia: Error detected 0 5009
VDPAU nvidia: Error detected 0 481

Different error behaviors:

1) Screen will blank for a moment, mplayer will usually recover, Myth will sometimes recover but X display is fine.

2) Screen will blank permanently, sometimes audio will continue in the background. Restarting X will restore display.

3) Display will go an all pinkish color (under 195.x) or pixels will randomly change color and move (under 180.x and 190.x). Restarting X will not fix this problem, the machine needs to be rebooted before X will work again.

I don't know if the behaviors listed are correlated with the specific errors but I suspect that they are. When the display errors I usually get NVRM errors in the syslog, here are some sample errors:

[ 170.652293] NVRM: Xid (0002:00): 6, PE0004 <-- Normal recoverable error???
[ 382.369619] NVRM: Xid (0002:00): 13, 0004 00000000 00008297 00001348 00146214 00000005
[ 533.740558] NVRM: Xid (0002:00): 13, 0004 00000000 0000502d 00000200 00146214 0000000c
[ 546.924525] NVRM: Xid (0002:00): 6, PE0004
[ 596.991798] NVRM: Xid (0002:00): 6, PE0004
[ 606.072152] NVRM: Xid (0002:00): 8, Channel 00000004 <-- I think the display dies with a #3 type error here
[ 619.072149] NVRM: Xid (0002:00): 8, Channel 00000001
[ 628.072153] NVRM: Xid (0002:00): 8, Channel 00000001

[cehoyos]

Originally Posted by Enigma2175

Hmmmm, never thought to check that before but it appears that it is at 50 Hz.

So I hope you agree MPlayer has a hard job to de-interlace (=double the frame-rate) of your 30Hz input material. This also makes testing the newer, slightly better performing version pointless.
If you really think that "half-rate" is the answer, please try to convince me it is: I am on 85Hz, and some things are just difficult to understand...

I will try this when I get a chance, compiling mplayer from source is not just something I can do on a whim

Hmm (EDIT: Building MPlayer is apparently currently broken, but that should be fixed in the next 36 hours - patch welcome!)

• svn co svn://ffmpeg.org/mplayer/trunk mplayer
• cd mplayer
• ./configure
• make

(I never install)

You will probably want a few library headers, but note 1) except for xv-devel they are probably all useless and 2) even that should not take too long (and I believe there is an incantation to just install all the headers MPlayer likes).

Carl Eugen