[mythtv-users] General help needed with XvMC, MPEG-2

[deanv at cox.net]

The situation: 

I have created a PVR using Linux (Gentoo 2.6.5 kernel), MythTV, and a Shuttle SFF system (Athlon XP2500), with on-board NVidia Nforce2 chipset, including the IGP (Geforce4 MX-440 equivalent).  I am using a Hauppauge PVR-250 for a capture device.  I am a DirectTV subscriber, so I cannot use the 250’s embedded TV tuner. Instead, I capture the S-video feed along with an analog audio feed output from my satellite decoder box.  My connected TV is a Samsung DLP with DVI, RGB, S-video, component video, and composite video inputs.  My satellite box is connected to the TV using the DVI, so as a *next best* option, I have connected the PVR to the TV using the RGB inputs, thus, the TV appears as a “monitor” to my PVR/PC.  Oh yeah, the satellite decoder is an HDTV device, including the capability to tune local OTA HD channels, which I do.

After some installation headaches, I finally have this all *working*, but comparing my resulting performance with many of the performance claims I have been reading (“quality is as good as live TV”, “quality exceeds that of my ReplayTV”, etc.), there is significant room for improvement within my setup.  I have recently moved to XvMC in an attempt to offload my CPU, and utilize the built-in “motion compensation” within my video card (chipset).

The PVR-250 has only composite or S-video inputs, and so I have selected the best of these, the S-video input, to capture the video from my satellite box source.  This means that REGARDLESS of the source format (HD local, HD satellite, SD satellite), I can only capture NTSC format 480interlaced video (I know, this is a large source of quality degradation, but it is what I have, for now).  However, I think that if I understood more about the entire video path (from capture input to video card output) I would be in a better position to diagnose the source of my issues and (perhaps) even address them.

Starting with the video input, it is my understanding that I receive, in sequence, two “fields” (a “top field”, and a “bottom field”), one every 1/60th of a second, consisting of on the order of 262 lines of data to display.  These two fields combine to form a “frame” consisting of 525 lines (480 intended to be visible) by ??? pixels wide.  So, I get one full frame every 1/30th of a second.  Now for my first questions…Does the MPEG-2 compression implemented within the PVR-250 hardware COMBINE the fields into a single frame, then compress, or does it compress the fields separately?   If the two fields are taken 1/60th of a second apart, doesn’t this virtually guarantee (if there is motion captured) some “combing effect” in any single full frame?

I have configured MythTV to capture a 16x9 source.  Following this, I am allowed to specify the capture resolution, up to a maximum of 720x480.  Note that 720x480 does not represent 16x9 (at least not if a pixel can be considered equally “high” and “wide”), so again, I am confused.  Later, when I reconstruct an image via MPEG-2/XvMC decodong, does the original 16x9 ratio drive the “shape” of my output, or does the 720x480 control it?

Assume that the MPEG-2 encode-decode cycle recovers a faithful representation of the input “frame” or “fields”.  My video card and my TV have been instructed to create a 1280x720 “display”, so at some point, my video card must “scale” the output to match this.  Does this *scaling* occur using a full “frame” (including built-in combing), or are the two “fields” scaled separately?  Using my TV “monitor”, my video card wants to output a “progressive” pattern, that is, one full frame each 1/60th of a second.  Of course, I do not have that much source data (in fact, I have only ½ that), so the video card must accommodate this somehow.  Does my card simply output the same full “frame” twice, or is there some interpolated “intra-frame” version generated?  Does it maybe output a scaled version of each field in succession?

Perhaps my results could give a clue.  When using XvMC, no deinterlace is possible with MythTV (0.15.1).  What I see has very good tonal quality, with reasonably smooth movement, BUT it also has a very noticeable “combing” effect, thus leading me to believe that my card is outputting full frames (including 2 offset images) at twice the capture rate.  Aside from the combing, the recovered display of original HD content is truly remarkable, given the S-video and MPEG-2 compromises that must occur.  If I de-select XvMC and instead insert a de-interlace (kerneldeint, for example), I see almost no combing, but the picture now starts to look like “old film”, instead of live video.  Not nearly as impressive overall.

So, more questions… 

1)      Could anything that I am seeing result from “scaling artifacts”, and if so, could I achieve improvement by shrinking my display to 720x480?  I could do this using a custom modeline (720x480 within 1280x720 timings), but of course, the image would be smaller.  If I used a standard 720x480 modeline, in a 720x480 mode, my TV would do the scaling, with perhaps different results.  Is this worth investigating?  Seems to me that I would still have the combing effects regardless of which device does the scaling.

2)      Is there a way to cause either the capture side or the replay side to treat each “field” as a full frame, thus creating some weak form of deinterlace?

3)      Is there a way to induce any form of deinterlace with PVR-250 capture and XvMC display? 
4)      My video card supports an s-video input to my TV.  Instead of the RGB, I could use this to allow me to output interlaced content, and hopefully remove the combing, but I think the quality I will lose will more than outweigh the gain.  One side of me says this is indeed the way to go, as ALL of my content has already endured one pass through the s-video limits, so another pass should result in almost no more degradation.  The other side says that clearly the more faithful representation will be achieved with the RGB, given its more direct signal interface.  Any opinions?

I know that there are many of you reading this that have been faced with these same issues.  Again, a better understanding of what is actually happening to the video signal through this process would really help me focus a potential solution.  Any help, any advice, any sharing of knowledge would be appreciated.

-dvh