Am Montag, den 04.05.2009, 14:13 +0200 schrieb Nicolas Huillard:
Rolf Ahrenberg a écrit :
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.
16:10 is also a common device aspect ratio these days ;-)
It may be a common aspect ratio for display devices, but not for video material. Movies and TV shows are mostly produced in 4:3, 16:9 or 2.21:1.
The OSD should adopt to the size of the video material. If that is scaled to some non TV screen size, the OSD is scaled by the same factor.
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.
I strongly second that. Add the fact that some (most ?) of the channels here mess / cheat with aspect ratio / resolution, and I currently (VDR 1.6, SDTV, xineliboutput) have a unextricable aspect/resolution/OSD problem. I'm not even trying to solve it...
I'd also suggest the maximum OSD size is 1920x1200 instead of 1920x1080, as this 16:10 resolution is very common in computer land. That's also the maximum a DVI single link can output.