Hi,
I wrote a patch for the ScaleVideo implementation in the dvbhddevice, for keeping the actual aspect ratio of the video material when scaling. It was tested by users at vdr-portal.de which also reported the distortions (I don't own such a device), and they said it works [1]. You can test it with the nOpacity skin and/or with the upcoming yaepghd-0.0.4 plugin [2].
Regards, Lucian
[1] http://www.vdr-portal.de/board1-news/board2-vdr-news/p1137059-announce-nopac... [2] http://sourceforge.net/projects/vdryaepghd/files/
It's a shame truecolor support still hasn't been added to this plugin. Also, last I spoke with bball he had lost his password to vdr-developer so it's not exactly that he had abandoned it as is being claimed. None the less thanks for bothering enough to fork it and continuing work. Would be nice if all the work people have done was consolidated but we can't have everything I guess. :)
On Fri, Apr 5, 2013 at 10:37 AM, Lucian Muresan < lucianm@users.sourceforge.net> wrote:
Hi,
I wrote a patch for the ScaleVideo implementation in the dvbhddevice, for keeping the actual aspect ratio of the video material when scaling. It was tested by users at vdr-portal.de which also reported the distortions (I don't own such a device), and they said it works [1]. You can test it with the nOpacity skin and/or with the upcoming yaepghd-0.0.4 plugin [2].
Regards, Lucian
[1]
http://www.vdr-portal.de/board1-news/board2-vdr-news/p1137059-announce-nopac... [2] http://sourceforge.net/projects/vdryaepghd/files/
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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.
Cheers,
Udo
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 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
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
Am 08.04.2013 19:42, schrieb Lucian Muresan:
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.
Hi,
I tested the scaling myself using the nopacity skin. I integrated Udo's patch as is a bit clearer and directly points to the main requirement for correct aspect ratio: The width and height values must be equal as they represent percentages.
Best regards, Andreas
-
Andreas Regel -
Klaus Schmidinger -
Lucian Muresan -
Udo Richter -
VDR User