On 04.05.2009 08:00, Rolf Ahrenberg wrote:
> On Sun, 3 May 2009, Tomas Berglund wrote:
>
>> Do you mean aspect ratio 2.21:1 ?
>>
>> +const char *VideoAspectString[] = { "4:3",
>> + "16:9",
>> + "2.21:9"
>> + };
>
> Besides of that typo, there're plenty of video aspect ratios missing:
> 1:1, 12:11, 10:11, 16:11, 40:33, 24:11, 20:11, 32:11, 80:33, 18:11,
> 15:11, 64:33, 160:99, 3:2, 2:1.
>
> Anyway, I'm not very fond of this new interface addition. After a little
> playing with xineliboutput plugin in the past, the OSD scaling to video
> size is a total mess and hence the HUD mode was developed, where the
> OSD resolution is the same as the output resolution and the video is
> scaled to that resolution. I'd strongly suggest to implement
> "cDevice::GetOSDSize()", so the output plugins can correctly set their
> OSD resolution with minimal scaling artefacts.
>
> Of course, you could misuse the current GetVideoSize always to result an
> output (OSD) resolution, but that would break i.e. all skin plugins that
> will certaily make use of this new method.
Looks like the name of this function wasn't very well chosen, sorry.
It's probably best to go for a
cDevice:GetOsdSize(int &Width, int &Height, double &Aspect);
through which the output device can tell VDR which size the OSD
shall have, and Aspect being a double value allows the device to
give VDR a hint whether the OSD shall be "stretched" (default
is 1.0, and it's not mandatory that the OSD actually uses this hint).
The existing GetVideoSize() could still be left in there, returning
the actual video size of the displayed matierial, which might be
displayed by some plugin.
Klaus
_______________________________________________
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
