On 05.04.2013 21:35, Udo Richter wrote:
Am 05.04.2013 19:37, schrieb Lucian Muresan:
I wrote a patch for the ScaleVideo implementation in the dvbhddevice,
for keeping the actual aspect ratio of the video material when scaling.
My initial thought on the code was that it seemed to unnecessary do too
many double to int conversions, plus not doing any of them with proper
rounding. But I also thought, this might turn out simpler when
transforming it a bit. So I just did some math transforms, and it came
out quite embarrassingly simple:
// Scale to units of 1/1000 osd, with rounding
int x = (Rect.X() * 1000 + osdWidth / 2) / osdWidth;
int y = (Rect.Y() * 1000 + osdHeight / 2) / osdHeight;
int w = (Rect.Width() * 1000 + osdWidth / 2) / osdWidth;
int h = (Rect.Height() * 1000 + osdHeight / 2) / osdHeight;
// make aspect corrections
if (w > h) {
x += (w - h) / 2;
w = h;
}
else if (w < h) {
y += (h - w) / 2;
h = w;
}
mHdffCmdIf->CmdAvSetVideoWindow(0, true, x, y, w, h);
This should be functionally identical to the original code, except for
less rounding errors. I haven't tested it though.
Am I getting this right? cDvbHdFfDevice::ScaleVideo() apparently sets the
video window in units of 1/1000 of the OSD width and height, respectively.
Since this resolution is less than the possible acual OSD width or height,
the rectangle actually used in this function might be different from the
one given in the Rect parameter. While this is, of course, allowed, shouldn't
the same calculations also be done in cDvbHdFfDevice::CanScaleVideo(), to return
the correct rectangle to the skin?
Klaus
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
