[mythtv-users] VDPAU field report

Yeechang Lee ylee at pobox.com
Tue Feb 10 06:50:28 UTC 2009


    Mr. Madison, what you've just said is one of the most insanely
    idiotic things I have ever heard. At no point in your rambling,
    incoherent response were you even close to anything that could be
    considered a rational thought. Everyone in this room is now dumber
    for having listened to it. I award you no points, and may God have
    mercy on your soul.
    	-Principal, _Billy Madison_

I quote the above because, as it turns out, my original message in
this thread is largely inaccurate. There were a few things I
overlooked that threw most--OK, almost all--of my findings off. So,
let's start over; this message will be attached to the original so
people will see both, at least.

I am using the ATrpms 180.22 drivers and an Asus 8400GS (G98 core)
with 512MB
(<URL:http://www.newegg.com/Product/Product.aspx?Item=N82E16814121235>
with my more than three years-old frontend running CentOS 5.2. For
MythTV recordings I only have HD and SD MPEG-2 recordings from ATSC
and FireWire, with the exception of a few old MPEG-4 files from
mythtranscode. VDPAU comes from Jean-Yves Avenard's unofficial and
unsupported backport to 0.21-fixes, so keep in mind that trunk is
already different.

Playback settings:
>1280x720 - VDPAU, One field (1x) deinterlacing, no OSD fade
<=1280x720 to >720x576 - VDPAU, no deinterlacing, no OSD fade
<=720x576 - VDPAU, Advanced (2x) deinterlacing, no OSD fade
>0x0 - Standard decoding/VDPAU renderer, One field (1x) deinterlacing,
no OSD fade

OpenGL sync
CC off by default

I also have Composite disabled in xorg.conf.

(Before VDPAU I used:
>1280x720 - Standard decoding, Xv renderer, Bob (2x) deinterlacing, OSD fade
<=1280x720 to >720x576 - Standard decoding, Xv, no deinterlacing, OSD fade
<=720x576 - VDPAU decoding, Xv, Yadif (2x) deinterlacing, OSD fade

No OpenGL sync (i.e., RTC)
CC on by default)

I use one field because, as others have reported, my 8400GS can't use
the Advanced or Temporal 1x or 2x deinterlacers (Note that 1x has
since disappeared from trunk because Nvidia no longer recommends
it). I can use Bob, but only with noticeable tearing/ghost after
images during pans and movement. One field works very well, albeit
with some occasional very minor tearing in the top 20% during movement
(the two clips I mention at
<URL:http://www.gossamer-threads.com/lists/mythtv/users/351830#351830>,
for example). From Isaac Richards and Jean-Yves Avenard's reports it's
quite possible that a newer Nvidia driver will fix my issue with Bob,
so I look forward to trying Bob again once Nvidia releases a stable
>180.22A driver and ATrpms follows suit.

OpenGL OSD fades are disabled because, even during SD playback, fades
tend to briely stutter playback. As when using the OpenGL renderer,
the fonts are smaller than with Xv. Otherwise, the OSD performs
exactly as expected. I've also disabled captions on by default
because, with VDPAU, they cause playback to stutter with "Writeaudio:
Buffer underrun" error messages in the log with certain recordings,
such as 720p from History HD or FOX even though they don't need
deinterlacing at all. VDPAU also does not seem to obey gamma settings
in xorg.conf or in nvidia-settings. One-frame skips during playback
first jump a few frames, then jump back to the correct one, which is
somewhat disconcerting but harmless. I presume it has something to do
with how segments of the video are offloaded to the GPU.

(Another oddity is that any DPMS setting, whether standby or off,
hangs the display; SSH still works, and X is killable. I've
accordingly disabled DPMS in ~/.xscreensaver. This is a peculiarity of
the 8400GS plus the 180.22 driver, and not related to VDPAU per se;
this did not happen with 18022 and a 7300LE.)

CPU usage for ATSC/FireWire HD MPEG-2 MythTV-recordings playback is,
as advertised, 5-10%, with occasional spikes to >10%. For HD-PVR h.264
recordings (such as 13.5.mpg) from MythVideo, it runs up to 15%. For
Apple Quicktime 1080p videos (such as bbc_cctv_1080p20070914.mov),
it's again 5-10%. Playback of mythtranscode-produced MPEG-4 versions
of MPEG-2 recordings, and Xvid DVD rips from MythVideo, sees 30-50%
CPU; VDPAU offloading is all or nothing and I guess it has nothing to
offer these formats.

Stability has been excellent, even considering the newness of the
code. In the past 10 days I have played many hundreds of MPEG-2 MythTV
recordings, seeing exactly one crash of mythfrontend in a situation I
haven't been able to reproduce so don't know if VDPAU is responsible
at all. In MythVideo, the two _I am Legend_ trailers at
<URL:http://www.h264info.com/clips.html> both hang mythfrontend and
wedge X (sort of like an app that gets stuck when an NFS mount goes
down) at about 15 seconds in, with several "NVRM: Xid (0001:00): 48,
CCMDs 00000005 000088b1 ffffffff ffffffff" error messages in
dmesg. SSH works and telinit 3; rmmod nvidia; telinit 5 works once
mythfrontend finishes killing itself (which might take up to about 30
seconds).

VDPAU within mythfrontend has performed superbly and I see no reason
why I can't continue to use it on an everyday basis. It really is
everything promised, and code maturity on both the driver and MythTV
sides is astoundingly high; if this is "alpha level" code, we should
have more such! There is no question in my mind that VDPAU
conclusively solves any lack-of-horsepower issues with playing even
the highest-bitrate HD-PVR recordings
(<URL:http://www.gossamer-threads.com/lists/mythtv/users/315909#315909>).
My thanks to Nvidia, Isaac Richards and Mark Kendall for the amazing
turnaround time on implementing a brand-new API, Jean-Yves Avenard for
the backport, and everyone else for their work in bringing true
hardware-based video offloading to MythTV and Linux.

-- 
Frontend/backend:	P4 3.0GHz, 1.5TB software RAID 5 array
Backend:		Quad-core Xeon 1.6GHz, 6.6TB sw RAID 6
Video inputs:		Four high-definition over FireWire/OTA
Accessories:		47" 1080p LCD, 5.1 digital, and MX-600




More information about the mythtv-users mailing list