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

On 08.04.2013 19:42, Lucian Muresan wrote:

On 08.04.2013 10:36, Klaus Schmidinger wrote:

...

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?

I think if the actual cDvbHdFfDevice::CanScaleVideo implementation would have really calculated something, it should have only converted internally to whatever needed (1/1000 in this case), and back to Osd pixel dimensions before returning the value. Since it doesn't (as it just returns the input rectangle, possibly because the device "is" able to handle any size within the limits, maybe nothing should be changed. Or maybe checking against the limits could be done, changed the size to a reasonable default (like Null for full size) and log an error if the input size wasn't within the Osd limits. Udo's variant looks well, but for all this maybe Andreas Regel should also be consulted. Btw, I sent him a PM on vdr-portal.de, he did not react so far.

Regards, Lucian

Hi,

I will look into this shortly.

Best regards Andreas