Totem-gstreamer: Aspect ratio not correctly detected

Bug #38946 reported by Rounan
18
This bug affects 1 person
Affects Status Importance Assigned to Milestone
totem (Ubuntu)
Invalid
Medium
Ubuntu Desktop Bugs

Bug Description

Using totem-gstreamer in an up to date Dapper system, the aspect ratio seems to default to "square" for all videos. The correct aspect ratio for any video I tested with (a couple dozen) was 4:3, so the default results in very tall-looking people.

Once you set the aspect ratio to 4:3 it looks fine, but the setting isn't preserved - you have to do it every time you run totem. The default was correctly detected in Breezy, and I'll bet a lot of users won't know how to change this setting.

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

Can you include a link to one of the videos that shows this problem? On my system the aspect ratio is set to automatic and totem seems to get it right...

Changed in totem:
status: Unconfirmed → Needs Info
Changed in totem:
assignee: nobody → desktop-bugs
Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

Rounan:

Any luck finding a link?

Revision history for this message
Rounan (nrcavan) wrote :

Sorry for the late reply.

This isn't a problem with a specific video, or even one batch of
encodings. I've tried dozens of .avi files, encoded with xvid, divx and
ffmpeg.

On closer inspection, neither "square", which is detected by default,
nor 4:3 produce the right aspect ratio. Both produce videos that are the
right width, but square makes them too tall while 4:3 makes them too
short.

Attached are two screenshots illustrating this. For some reason, I
couldn't get totem to display its video in the screenshot. On my screen,
the two windows are playing the same frame of video. But you can see by
the size of the black area that the sizes are off.

Again, this happens for every video I've tried. And I've tried a LOT.

Cheers,
Neil Cavan

Revision history for this message
Rounan (nrcavan) wrote : 4 to 3 distortion

Video is too short

Revision history for this message
Rounan (nrcavan) wrote : square distortion

video is too tall

Revision history for this message
Andreas Behr (andybehr) wrote :

I have the same (or at least equal in effect) issue.
I have a Dualscreen Xinerama Setup. I assume it has something to do with that, because it used to work before the dualhead setup.

Andy

Revision history for this message
Sebastien Bacher (seb128) wrote :

What is the issue exactly. When you start playing a moving the totem window is automatically resized but to something wrong (not a correct ratio)? Do you use a xinerama setup too? Is that a new issue?

Revision history for this message
Andreas Behr (andybehr) wrote :

I have an ATI fglrx dual head screen setup.
The screen size is recognized as 2560x1024 (in the gnome settings to change the resolution, "Bildschirmauflösungseinstellungen" in German), but it is really two screens, each with 1280x1024.
The gnome-panel is only on the first head, so I assume, the xinerama setup was identified correctly. (so it is *not* like ATI-BigDesktop)
In totem-xine, the ratio is totally off, and all videos are vertically short but very wide, so I switched to totem-gstreamer.

Here the ratio is nearly correct, but not quite.
I only watch videos in fullscreen mode.
But still the video is vertically too short, about 20-30 pixel on the bottom and the top. And I am not talking about the black border that is there because the TV ratio is different than my PC screen ratio, this is on top of that.

If you need more information or screenshots, please let me know.

Andy

Revision history for this message
Sebastien Bacher (seb128) wrote :

do you still have the issue? some gstreamer bugs have been fixed since ...

Revision history for this message
Daniel Holbach (dholbach) wrote :

Your bug lacks information we would need to investigate further. We
are now going to close the bug - please reopen if you have more
information at hand.

Changed in totem:
status: Needs Info → Rejected
Revision history for this message
Robin Sheat (eythian) wrote :

I'm seeing this in totem right now after an upgrade to gutsy. Files that played by default in the correct aspect ratio are now squished horizontally.

I'm looking at a video now with dimensions 624 x 352, however it is showing 377x377, or something very close to that. If I force the aspect ratio to DVB, it shows as 627x491, which is closer but still wrong. VLC shows the files correctly by default.

I am running with twinview, although switching off the second monitor appears to make no difference, and it worked in this same configuration previously.

I've tried with a number of video files from different sources, they all show this (though, they're all .avi so probably DivX or XviD or similar)

A quick check with totem-xine shows similar issues.

Revision history for this message
Robin Sheat (eythian) wrote :

Here's an example of the problem, in this case with a WMV embedded in a webpage (using mms streaming). The totem browser plugin displays it incorrectly, same if you right-click->open in movie player, however opening it in VLC shows it fine:

http://www.cbc.ca/marketplace/2007/10/03/geeks/

MMS URL:
mms://a101.v8752d.c8752.g.vm.akamaistream.net/7/101/8752/1191440118000/origin.media.cbc.ca/windows/marketplace/geeks.wmv

Revision history for this message
Robin Sheat (eythian) wrote :

I've just found that gv does the same thing when showing a PDF. So I don't think it's specifically totem's fault. I'm running with one screen above the other, and xdpyinfo says:
screen #0:
  dimensions: 1280x1568 pixels (625x231 millimeters)
  resolution: 52x172 dots per inch

whereas a regular screen says something more like:
screen #0:
  dimensions: 1024x768 pixels (347x260 millimeters)
  resolution: 75x75 dots per inch

Curiously, xrandr -q gives different measurements in mm:
Screen 0: minimum 1280 x 800, current 1280 x 1568, maximum 2560 x 1568
default connected 1280x1568+0+0 0mm x 0mm
I don't know if this means anything though.

I can't find a quick way of changing the DPI of the monitor (is this even possible on a running X session?), but it seems to that if I could, the problem would go away.

Revision history for this message
Robin Sheat (eythian) wrote :

(Reopening so it gets seen by someone who can reassign it appropriately or whatever)

Changed in totem:
status: Invalid → New
Revision history for this message
Sebastien Bacher (seb128) wrote :

could you open a new bug rather than reopen a closed one which will send mails to the user already subscribed to an issue which might be a different one?

Changed in totem:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.