[mythtv-users] Transcoding SD MPEG2 to H.264---recommendations?

[f-myth-users at media.mit.edu]

I have a large number of PVR-x50 recordings that I'd like to transcode
to H.264 to save disk space [1], for eventual playback under VDPAU on
a GeForce 9500 GT-class device (and, eventually, maybe a GT220-class
device if that would help [2]).

Two questions:
(a) What's the current favorite way to do this?  I'd like to run some
tests standalone, and then I'd like to integrate this going forward
as a user job under Myth.  Command lines and/or scripts that have
worked for you would be an excellent starting point; the search space
of transcoders and options for them is rather large.

(b) What sort of performance, in both space and time, might I expect?
I know there are a ton of variables here, so anecdotes of what's
worked for you would be fine.  For a given CPU of the last year or
so, would it be reasonable to expect that I could do this in real
time?  1/10th realtime?  10x realtime?  Would multiple cores be
helpful if I'm doing multiple separate files in parallel?  (I'm
expecting that to be "yes", since I doubt I'd saturate the memory
bus and the disk I/O rate should be pretty small, but I figured
I'd check on whether lots of cores would speed this up.)

If you say "this transcoded X in Y seconds", please give me a clue
about your transcoding options, CPU speed, and how many cores were
participating; I'd like a ballpark figure so I can do some hardware
estimating.

Thanks!

[1] Yes, I know disk is cheap, but my use case is a bit unusual.
I'm hoping to cut the space by a factor of 2 or even 3 if I can
do it without noticeable sacrifices in quality.  Much of the video
is (essentially) STB-quality; some is extracted from archival VHS
and will (I'm guessing) want to be denoised somewhere (either where
it would help the most, in transcoding, or perhaps under VDPAU if
necessary).

[2] If they come out with a fanless one---I last checked a while back,
the ones with fans were too loud for my tastes, and cards without fans
tended to be enormous and eat adjacent PCI slots; I haven't re-researched
this in a few months.