No, the compiliation was most likely correct, but the video accelleration was not selected. You just don't need to specify the extra disable/enable options, those are autodetected.
When I originally wrote the VDPAU test support, the checking of the VDPAU header files within MPlayer wasn't automatic and the build support would then fail if they weren't present. I also want to leave those in for externally checking the existence of the header files as eventually that will be passed back to PTS so that it will dynamically build the option list of what test formats are supported as options with that build.
Basically for h264 and vc1 it does not matter if you use vdpau or vaapi. I only had problems using the divx accelleration with b-frames. There the mplayer vaapi needed a patch - even for the vdpau mode when the mplayer-vdpau.patch was used. If you do not need that -va switch for vdpau you can leave out that one and use the older -vc override instead. You will only notice a diff with divx however.
That may be interesting too, i usally only test with KDE 3 without compiz. As xv output is basically useless gl output might be nice to compare - with forced vsync in amdcccle/nvidia-settings - otherwise it does not look nice.
I definitely believe the results for X-Video, but the XvBA results are rediculous. Normally, for XvBA, my computer stays at ~3% CPU. Yes, I know it wasn't the point of the article, I just think it is a bit misleading.