[mythtv] bob deint issue with latest cvs

[Daniel Thor Kristjansson]

On Fri, 4 Feb 2005, Bruce Markey wrote:
]Doug Larrick wrote:
]> FYI, I see some weirdness (seems like one field scaled more than the
]> other) on my main Myth box when in any of the zoom modes that scale
]> vertically.  I can't seem to reproduce it on my dev box, so I'm not sure
]> what's going on.  This appears when displaying 480i to a 540p screen,
]> but goes away if I display to a 480p screen.
]You are correct. I fixed it for myself last night before I saw
]any of today's discussion in this thread. The problem is here:
]   src_h -= (halfLineSrc) ? 1 : 0;
]This will change the source height of the bottom field causing it
]to be stretched and scaled differently than the top field. Try this:

This along scaling the output allows us to paint a few fewer lines 
in the XvPut calls. The problem was that I didn't scale the output 
image correctly, but this is fixed in CVS.

The code in CVS now for XV has been tested with material at 
480i with a screen at 540p.


]I think there are some other good intentions that may be the
]result of some misunderstanding. The only thing that needs to
]be different is that the bottom field needs to be moved down
]by one line (virtual line, more later). I think the tweak to
]disphoff is an attempt to compensate for the mismatched stretch.
This was intenentional, you need to adjust disphoff for this not to 
happen, but I had to multiply halfLineSrc by two, which I hadn't done
in the first patch in CVS. 

I was to clever by half in trying to avoid losing a few lines of 
resolution. But now I do mask off the bottom, so we don't need the
src_h and disphoff to avoid a colorkey line at the bottom.


]There was mention of the possibility that the offset needs to
]be more than one pixel if the display size is much larger than
]the capture size. That's an excellent idea.

My horizontal resolution is 1440 px, so that was the entire point of the 
patch really. Eliminating the colorkey lines was just a bonus. ;)

]  int vline = (int) (disph / (float) imgh + 0.5);
]Of course, this too doesn't need to be calculated every time
]through PrepareFrame

The cost of the floating point is somewhere between 0 and 350 cycles 
depending on whether your architecture, mostly on whether you have a 
FPU. In the scheme of things it is free, we might as well keep the code 
from getting too ugly in light of this.


]nor does there really need to be separate XvShmPutImage for the bob 
]fields.

This is true, esp considering what I just said about floating point 
being practically free in this context ;) But I'd like to keep the code 
static for a couple days until the release, assuming the current CVS
fix works for everyone.


]However, attached is a quick patch for testing.

Please try the CVS as of this afternoon, if it works for you lets table 
this until after the release.


]I think this needs to be resolved or backed out before the release.

It's resolved for XV in CVS and a mirroring patch has been sent for XvMC.

I'll send a beautification patch to Issac after 0.17 which gets rid of 
the scaling or the masked out lines at the bottom of the screen or 
if possible both. Then if there are problems we fix them but they don't 
go into the release.

My guess is you can avoid the scaling and the extra masking, but I'm 
being conservative with the masking to avoid another patch just before 
the release.

-- Daniel