VDR developer version 1.7.7 is now available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.7.7.tar.bz2
A 'diff' against the previous version is available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.7.6-1.7.7.diff
WARNING: ========
This is a *developer* version. Even though *I* use it in my productive environment. I strongly recommend that you only use it under controlled conditions and for testing and debugging.
IMPORTANT: ==========
If you use a full featured DVB card for replay you need the DVB driver version from
http://linuxtv.org/hg/~endriss/v4l-dvb
in order to replay TS recordings! Users of full featured DVB cards also need to use a new firmware, available at
http://www.escape-edv.de/endriss/firmware
Note that the header files in the latest driver versions may be broken. If you get compiler error messages like
/usr/include/sys/types.h:52: error: conflicting declaration 'typedef __ino64_t ino_t' /usr/include/linux/types.h:14: error: 'ino_t' has a previous declaration as 'typedef __kernel_ino_t ino_t'
when compiling VDR, you need to put the driver header files back to how they were before they got broken. One way of doing this is to apply the patch from
ftp://ftp.cadsoft.de/vdr/Developer/v4l-dvb-header-fix.diff
(I'm not claiming that this is the right way to fix this, since the driver developers may have had good reasons for making that change. However, both the driver and VDR compile and work fine with this).
The changes since version 1.7.6:
- The new function cDevice::GetVideoSize() returns the size and aspect ratio of the video material currently displayed. This function is used to determine the proper size of the OSD. Plugin authors should implement this function in classes derived from cDevice, if they are able to replay video. - The OSD and font sizes are now defined in percent of the actual video display size. The maximum OSD size has been raised to 1920x1080, to allow full screen OSD on HD systems. - The OSD size is now automatically adjusted to the actual video display (provided the output device implements the GetVideoSize() function). - cFrameDetector::Analyze() now syncs on the TS packet sync bytes (thanks to Oliver Endriss for reporting broken index generation after a buffer overflow).
Have fun!
Klaus
Do you mean aspect ratio 2.21:1 ?
+const char *VideoAspectString[] = { "4:3", + "16:9", + "2.21:9" + };
Tomas Berglund
----- Original Message ----- From: "Klaus Schmidinger" Klaus.Schmidinger@cadsoft.de To: vdr@linuxtv.org Sent: Sunday, May 03, 2009 5:15 PM Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.7
VDR developer version 1.7.7 is now available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.7.7.tar.bz2A 'diff' against the previous version is available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.7.6-1.7.7.diffWARNING:
This is a *developer* version. Even though *I* use it in my productive environment. I strongly recommend that you only use it under controlled conditions and for testing and debugging.
IMPORTANT:
If you use a full featured DVB card for replay you need the DVB driver version from
http://linuxtv.org/hg/~endriss/v4l-dvb
in order to replay TS recordings! Users of full featured DVB cards also need to use a new firmware, available at
http://www.escape-edv.de/endriss/firmware
Note that the header files in the latest driver versions may be broken. If you get compiler error messages like
/usr/include/sys/types.h:52: error: conflicting declaration 'typedef __ino64_t ino_t' /usr/include/linux/types.h:14: error: 'ino_t' has a previous declaration as 'typedef __kernel_ino_t ino_t'
when compiling VDR, you need to put the driver header files back to how they were before they got broken. One way of doing this is to apply the patch from
ftp://ftp.cadsoft.de/vdr/Developer/v4l-dvb-header-fix.diff
(I'm not claiming that this is the right way to fix this, since the driver developers may have had good reasons for making that change. However, both the driver and VDR compile and work fine with this).
The changes since version 1.7.6:
- The new function cDevice::GetVideoSize() returns the size and aspect
ratio of the video material currently displayed. This function is used to determine the proper size of the OSD. Plugin authors should implement this function in classes derived from cDevice, if they are able to replay video.
- The OSD and font sizes are now defined in percent of the actual video
display size. The maximum OSD size has been raised to 1920x1080, to allow full screen OSD on HD systems.
- The OSD size is now automatically adjusted to the actual video display
(provided the output device implements the GetVideoSize() function).
- cFrameDetector::Analyze() now syncs on the TS packet sync bytes (thanks
to Oliver Endriss for reporting broken index generation after a buffer overflow).
Have fun!
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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.
BR, -- rofa
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 ;-)
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.
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.
On Mon, May 4, 2009 at 4:19 PM, Falk Spitzberg post@spitzberg.de wrote:
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.
Isn't that precisely what people would like to avoid? Since most of the material being broadcast is still SD, but more and more people have HD (Ready) displays, it would make sense to separate OSD and video size from each other.
-Petri
On Mon, 4 May 2009, Falk Spitzberg wrote:
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.
I still disagree. If you scale down your OSD to video resolution (i.e. 544x576) and afterwards scale up the both video and OSD to output resolution (i.e. 1280x720), the OSD really looks crap due to scaling artefacts.
BR, -- rofa
and what about anamorphic material? A 16:9 SD broadcast in fact still is 4:3 but is streached by the TV to 16:9 to look ok (no egg-heads). Wouldn't it be correct also to draw the OSD anamorphic so that is not screached by the TV?
Did you get the point? It's somehow difficult to describe this topic for me.
Regards, Matthias
2009/5/4 Rolf Ahrenberg rahrenbe@cc.hut.fi:
On Mon, 4 May 2009, Falk Spitzberg wrote:
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.
I still disagree. If you scale down your OSD to video resolution (i.e. 544x576) and afterwards scale up the both video and OSD to output resolution (i.e. 1280x720), the OSD really looks crap due to scaling artefacts.
BR,
rofa
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Matthias Becker a écrit :
and what about anamorphic material? A 16:9 SD broadcast in fact still is 4:3 but is streached by the TV to 16:9 to look ok (no egg-heads). Wouldn't it be correct also to draw the OSD anamorphic so that is not screached by the TV?
Did you get the point? It's somehow difficult to describe this topic for me.
With today's pixel-displays, we'd like to avoid all scaling, stretching, etc. done by the panel itself. ie. like Rolf said, always output from the computer at panel resolution, with 1:1 pixel mapping. Video would be scaled, but not the OSD.
Regards, Matthias
2009/5/4 Rolf Ahrenberg rahrenbe@cc.hut.fi:
On Mon, 4 May 2009, Falk Spitzberg wrote:
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.
I still disagree. If you scale down your OSD to video resolution (i.e. 544x576) and afterwards scale up the both video and OSD to output resolution (i.e. 1280x720), the OSD really looks crap due to scaling artefacts.
I agree that OSD should be set to the output of the device's resolution. Not the video content it self. Would really love to see that change happen.
On 04/05/2009, Nicolas Huillard nicolas@huillard.net wrote:
Matthias Becker a écrit :
and what about anamorphic material? A 16:9 SD broadcast in fact still is 4:3 but is streached by the TV to 16:9 to look ok (no egg-heads). Wouldn't it be correct also to draw the OSD anamorphic so that is not screached by the TV?
Did you get the point? It's somehow difficult to describe this topic for
me.
With today's pixel-displays, we'd like to avoid all scaling, stretching, etc. done by the panel itself. ie. like Rolf said, always output from the computer at panel resolution, with 1:1 pixel mapping. Video would be scaled, but not the OSD.
Regards, Matthias
2009/5/4 Rolf Ahrenberg rahrenbe@cc.hut.fi:
On Mon, 4 May 2009, Falk Spitzberg wrote:
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.
I still disagree. If you scale down your OSD to video resolution (i.e. 544x576) and afterwards scale up the both video and OSD to output resolution (i.e. 1280x720), the OSD really looks crap due to scaling artefacts.
--
NH
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
2009/5/4 Nicolas Huillard nicolas@huillard.net:
Matthias Becker a écrit :
Did you get the point? It's somehow difficult to describe this topic for me.
With today's pixel-displays, we'd like to avoid all scaling, stretching, etc. done by the panel itself. ie. like Rolf said, always output from the computer at panel resolution, with 1:1 pixel mapping. Video would be scaled, but not the OSD.
Who is "we", at least my (and most other TV I have seen) rescale 16:9 (anamorphic) material to display it with the right aspect. This results in a wrong display of the OSD. This should be fixed. An ordinary user will not understand, why the OSD looks sometimes normal and sometimes "broad" (stretched).
Best Regards, Joachim.
I think what is being asked for is that the OSD always displays at the screens full physical extent even if the TV channel being watched is only 4:3 in the centre for example. Andrew
On Tue, May 5, 2009 at 6:58 PM, Joachim Wilke joachim.wilke@gmail.comwrote:
2009/5/4 Nicolas Huillard nicolas@huillard.net:
Matthias Becker a écrit :
Did you get the point? It's somehow difficult to describe this topic for
me.
With today's pixel-displays, we'd like to avoid all scaling, stretching, etc. done by the panel itself. ie. like Rolf said, always output from the computer at panel resolution, with 1:1 pixel mapping. Video would be scaled, but not the OSD.
Who is "we", at least my (and most other TV I have seen) rescale 16:9 (anamorphic) material to display it with the right aspect. This results in a wrong display of the OSD. This should be fixed. An ordinary user will not understand, why the OSD looks sometimes normal and sometimes "broad" (stretched).
Best Regards, Joachim.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On Mon, 04 May 2009 19:30:36 +0200 Nicolas Huillard nicolas@huillard.net wrote:
With today's pixel-displays, we'd like to avoid all scaling, stretching, etc. done by the panel itself. ie. like Rolf said, always output from the computer at panel resolution, with 1:1 pixel mapping. Video would be scaled, but not the OSD.
On my TV video looks better at 1280x720 than at the native resolution of 1360x768 for two reasons:
Its picture mode presets are optimised for video in 720p modes and PC/text in 1360x768.
Nearly everything I watch is 25fps and the TV only supports 60Hz at 1360x768.
OTOH ISTM even 576 line SDTV looks better displayed in a 720p mode than in 576p.
On Mon, 4 May 2009, Nicolas Huillard wrote:
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 ;-)
Well, those values (taken from H.264 specs) were for the video aspect ratio and not the output aspect ratio. IIRC, the H.264 contains also so called extended aspect ratio, that could contain almost anything.
BR, -- rofa
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
I keep seeing mention of people using computer monitors and that VDR should be designed to accommodate their aspect ratios. I'd like to point out that plenty of users don't use VDR with a computer monitor at all. Like many others, I have an hdtv (60" in my case) and would love to have an osd that 1920x1080 always, regardless of the content I'm watching. Why? Because my tv can handle it so why not? My main VDR box is in my living room, tucked away behind my tv with no keyboard, no mouse, no monitor, no anything. I do have a test box connected to a 19" monitor but certainly our primary VDR use is on a real tv so that's where our main concern/interests are.
I'm not sure what the best way to deal with this situation is but I strongly urge patience and proper design so nothing is force while looking ok for some people but like crap for others. Not everyone uses computer monitors for their output device, and not everyone uses a tv (of whatever size/aspect ratio). Surely there's a sane & reasonable solution that works for *. Maybe some user settings are required so people can tweak the osd to look good with their specific display type?
Best regards, Derek
-
Andrew Herron -
Falk Spitzberg -
Joachim Wilke -
Klaus Schmidinger -
Matthias Becker -
Nicolas Huillard -
Petri Helin -
Rolf Ahrenberg -
Theunis Potgieter -
Tomas Berglund -
Tony Houghton -
VDR User