GNOME Bugzilla – Bug 658292
aspect ratio of movie clips is incorrect
Last modified: 2014-12-18 07:44:32 UTC
I have a 1920x1080 screen, two of them (laptop and DVI) actually. But, when I maximise a 16:9 movie clip (e.g. 1280x720) on the screen, the video will be pillarboxed. Not too much, but the black bars on the sides of the screen are about 2 cm wide. mplayer and vlc work perfectly fine. This is on Fedora 15 x86_64, running gnome shell and nvidia 280.13 binary drivers. $ rpm -qa | grep gstreamer | sort gstreamer-0.10.34-1.fc15.i686 gstreamer-0.10.34-1.fc15.x86_64 gstreamer-devel-0.10.34-1.fc15.x86_64 gstreamer-ffmpeg-0.10.11-2.fc15.x86_64 gstreamer-plugins-bad-0.10.22-1.fc15.x86_64 gstreamer-plugins-bad-free-0.10.22-1.fc15.x86_64 gstreamer-plugins-bad-nonfree-0.10.22-1.fc15.x86_64 gstreamer-plugins-base-0.10.33-1.fc15.i686 gstreamer-plugins-base-0.10.33-1.fc15.x86_64 gstreamer-plugins-base-devel-0.10.33-1.fc15.x86_64 gstreamer-plugins-good-0.10.29-1.fc15.x86_64 gstreamer-plugins-ugly-0.10.18-1.fc15.x86_64 gstreamer-python-0.10.19-2.fc15.x86_64 gstreamer-rtsp-0.10.8-1.fc15.x86_64 gstreamer-tools-0.10.34-1.fc15.x86_64 PackageKit-gstreamer-plugin-0.6.17-1.fc15.x86_64 phonon-backend-gstreamer-4.5.1-1.fc15.i686 phonon-backend-gstreamer-4.5.1-1.fc15.x86_64 $ rpm -qa | grep totem | sort totem-3.0.1-2.fc15.x86_64 totem-nautilus-3.0.1-2.fc15.x86_64 totem-pl-parser-2.32.4-1.fc15.x86_64
Could you please run: xdpyinfo | grep dimensions My guess is that the dimensions of the screen don't have the same ratio as the pixel count, therefore the pixels aren't square (if the screen doesn't lie), therefore you should have black bars for a 16:9 film.
You might be right. With no external displays: $ xdpyinfo | grep dimensions dimensions: 1920x1080 pixels (351x191 millimeters) With both enabled: $ xdpyinfo | grep dimensions dimensions: 3840x1080 pixels (701x190 millimeters) The first one seems about right, but if you measure the screen with a tape it seems a few milimeters off (345x195 mm without taking out the caliper). The second value is clearly wrong, since the external screen is a 23" tv and is much larger than what xdpyinfo shows. It seems like some nvidia binary driver peculiarity.
The point is that in neither cases do you have square pixels, so you will get black borders. I just tested on my system, and I have no black borders whatsoever. $ xdpyinfo | grep dimension dimensions: 1920x1080 pixels (508x285 millimeters) Try with the nouveau driver. But, unless I'm very mistaken, both VLC and mplayer are wrong to not show any black borders, as they disregard the physical dimension of the device, and only use the resolution.
This is with nouveau: $ xdpyinfo | grep dimensions dimensions: 1920x1080 pixels (508x285 millimeters) The problem is that these dimensions are almost certainly wrong. There is no pillarboxing though. It might be worth mentioning that I have no hardware acceleration due to this laptop sporting a 485M, which is an NVC0 hardware AFAIK.
The screen seems to be lying. If you use the dimensions I measured and calculate the diagonal using Pythagorean theorem, you get 15.60 inches (which is what the screen is advertised as). On the other hand, the ones reported by nvidia driver yield 15.73 inches.
Created attachment 198477 [details] display's edid Hmm, to me it seems that the 351x191 comes from recalculation of bits 21 and 22 from edid, which are given in centimeters and thus inaccurate.
parsing the above edid with monitor-edid gives the correct size - it must be the driver's fault then $ monitor-parse-edid edid.bin EISA ID: LGD0215 EDID version: 1.3 EDID extension blocks: 0 Screen size: 34.5 cm x 19.4 cm (15.58 inches, aspect ratio 16/9 = 1.78) Gamma: 2.2 Digital signal # Monitor preferred modeline (59.9 Hz vsync, 66.6 kHz hsync, ratio 16/9, 141 dpi) ModeLine "1920x1080" 138.5 1920 1968 2000 2080 1080 1083 1088 1111 -hsync +vsync # Monitor supported modeline (59.9 Hz vsync, 66.6 kHz hsync, ratio 16/9, 141 dpi) ModeLine "1920x1080" 138.5 1920 1968 2000 2080 1080 1083 1088 1111 -hsync +vsync
Hopefully the nouveau driver works by now. Feel free to reopen if the problem still happens with the nouveau driver, or whether the NVidia driver got this fixed.
Yup, it works with nouveau, but nouveau does not report the right size either: $ xdpyinfo | grep dimensions dimensions: 1920x1080 pixels (508x285 millimeters) This gives roughly a 23 inch screen, which is way off. It just happens to work since the aspect ratio is more close to the correct one. Would an option to disable the use of the reported screen dimensions (even if hidden in gsettings) be too much to ask for?
I'm afraid so. The code is complicated enough handling the video's aspect ratio, the monitor aspect ratio and resolution, I really don't want to make this any more complicated.
Let me reopen this. nvidia driver got proper xrandr 1.3 support recently. Here is what I get with no external displays connected: $ xdpyinfo | grep dimensions dimensions: 1920x1080 pixels (351x191 millimeters) $ xrandr | grep LVDS-0 LVDS-0 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 345mm x 194mm The size xrandr reports is right, but totem still tries to use the crude dimensions coming from xdpyinfo. Plugging in the second screen gives the following: $ xdpyinfo | grep dimensions dimensions: 3840x1080 pixels (1016x286 millimeters) $ xrandr Screen 0: minimum 8 x 8, current 3840 x 1080, maximum 16384 x 16384 DVI-I-0 disconnected (normal left inverted right x axis y axis) LVDS-0 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 345mm x 194mm 1920x1080 59.9*+ HDMI-0 disconnected (normal left inverted right x axis y axis) DVI-I-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 510mm x 287mm 1920x1080 60.0*+ 1680x1050 60.0 1600x1200 60.0 1440x900 75.0 59.9 1280x1024 75.0 60.0 1280x960 60.0 1280x800 59.8 1152x864 75.0 1024x768 75.0 70.1 60.0 800x600 75.0 72.2 60.3 56.2 640x480 75.0 72.8 59.9 DP-0 disconnected (normal left inverted right x axis y axis) Again, xrandr sizes are right and xdpyinfo wrong. Finally, disconnecting the second screen: $ xdpyinfo | grep dimensions dimensions: 1920x1080 pixels (508x286 millimeters) $ xrandr Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 16384 x 16384 DVI-I-0 disconnected (normal left inverted right x axis y axis) LVDS-0 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 345mm x 194mm 1920x1080 59.9*+ HDMI-0 disconnected (normal left inverted right x axis y axis) DVI-I-1 disconnected (normal left inverted right x axis y axis) DP-0 disconnected (normal left inverted right x axis y axis) xrandr correct, xdpyinfo not. Keep in mind that in the last 2 cases totem works fine because the completely off dimensions xdpyinfo reports have the correct aspect ratio. This is on Fedora 17 x86_64, 304.32 nvidia driver and totem-3.4.3-1.fc17.x86_64.
The code in set_display_pixel_aspect_ratio() (and its caller) assumes only one screen and one monitor which is obviously pretty broken. We could obviously call gdk_screen_get_monitor_at_window() to figure out which monitor the window is on. But I don't have the foggiest clue how we would handle moving the window between 2 monitors with the different display aspect ratios. I'll attach a patch now for you to test (should apply to older versions of Totem), which I've also committed to master. Let me know if this works.
Created attachment 239173 [details] [review] backend: Fix calculating the display aspect ratio Based on the size of the monitor where the video is being displayed, as opposed to the full "GdkScreen" (which might include multiple monitors). This doesn't handle moving the video between 2 displays with different display aspect ratio, but should fix the worst case scenarios in dual head setups.
Julian: Did the patch in comment 13 work and fix the issue?
The patch's been in versions of Totem since 3.10. Let's consider this closed.