[mythtv-users] pcHDTV with PVR-350 for output

[Dan Lanciani]

Doug Larrick <doug at ties.org> wrote:

|Dan Lanciani wrote:
|> |> Right, I got that.  And I think it is the correct approach since it
|> |> preserves maximum information.  However, I somehow had the idea that it
|> |> would transcode and scale as necessary near the output.  (In my defense,
|> |> there is a lot of code in MythTV proper and a rather large number of
|> |> libraries.  It isn't immediately obvious that it doesn't do this. :)
|> |
|> |If you tell it to transcode, it will.
|> 
|> How would I tell it to transcode in this situation?
|> 
|> |It won't be realtime, though.
|> 
|> What prevents it from being real time?
|
|It's way too compute intensive.  Probably by a factor of at least 2.  It 
|would have to decode, resample, and re-encode.  Doing this in software 
|is beyond the capabilities of current general-purpose computing hardware.

Hmm.  From reading the hardware requirements documentation I had gotten the
(mis?)impression that even machines slower than "state of the art" could
handle a dumb capture card and software display decoding at the same time.
That's the same number of MPEG encode/decode steps.  I don't have a good feel
for the cost of resampling, but I would think that going from 480p to 480i
(which should take care of any SD stream?) would not require much computation
since it's only re-arranging scan lines.  Am I missing something?

|There's also the small matter that what Myth stores for HDTV is an 
|MPEG-TS (transport stream) file, not an MPEG-PS (program stream) as 
|expected by the PVR-350.

I'm not clear on how the on-disk format enters into it.  Is there some
architectural reason that there can't be any post-processing after reading
the data?  In any case, storing the whole transport stream might be something
to rethink eventually, especially if multicasting pay services take off.  No
sense saving stuff you can't even watch...

|This is aside from the frame-size limitations 
|mentioned by others.

The frame size capabilities happen to line up nicely with the capabilities of
the display devices that can be connected, so I guess the conversion has to
happen somewhere. :)

|Nothing in MythTV is set up to account for any of 
|this at all.

Yes, I completely misunderstood this before.  I thought that the intent was
to support arbitrary capture and display devices in any combination.  I didn't
realize that playback was constrained by the source.  As I mentioned, this
will probably be a problem for the other thing I was hoping to have (FireWire
in and out).

|To do what you want to do, you're better off using an nVidia MX-440 or 
|FX5200 and using its svideo output, since you *do* have the horsepower 
|to decode ATSC-sized frames in realtime.  Then the video card would do 
|the scaling (in hardware), and you're good to go. An MX-440 is less than 
|$50.

I have an FX5200 in the machine now.  Historically I haven't been pleased
with the results from TV-out-supporting video cards.  It always seemed like
the NTSC mode was an afterthought and the timing was never quite right,
leading to the need for tweaks specific to each television.  (My ultimate
goal is to feed the output of the PVR box into my house's distribution
system in place of--or in addition to--the current off-the-shelf Panasonic
PVR which is analog-only.)  However, I played mainly with ATI and Matrox cards
before.

If I have to I can just decode to the PVR-350's frame buffer device.  This
keeps up fine, but something is confused about the aspect ratios.

				Dan Lanciani
				ddl at danlan.*com