Doug Larrick wrote:
Daniel Thor Kristjansson wrote:
I've attached a patch that makes the fix and also ads two super verbose
VB_PLAYBACK macros that should help me debug the problems people
encounter.
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:
src_h -= 100; // (halfLineSrc) ? 1 : 0;
As you can see this exaggeration shows that the two fields are
stretched differently and can't possibly line up no matter how
you move them relative to each other. When stretching by one
pixel, you can get the lower half of the screen to line up but
the upper part will be off. If the upper is good, the lower will
be ghosted.
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 should not be changed, just the dest_y needs to be moved
a little, that's all. Everything else should be the same as the
top field. BTW the floating point math for halfLineSrc doesn't
need to be redone for every single PrepareFrame =).
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. If the capture is 480
and the display was 960, the bottom field should be moved by two
pixels rather than one. This should do the job.
int vline = (int) (disph / (float) imgh + 0.5);
Of course, this too doesn't need to be calculated every time
through PrepareFrame nor does there really need to be separate
XvShmPutImage for the bob fields. However, attached is a quick
patch for testing.
Since this is a good
workaround, I don't think it's worth worrying about for the release.
I think this needs to be resolved or backed out before the release.
-- bjm
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
