GNOME Bugzilla – Bug 601020
Totem plays video using DAR instead of PAR
Last modified: 2010-05-31 11:36:03 UTC
NTSC DVD's are played with the width reduced instead of height increased, i.e 640x480 instead of 720x540. Also, MP4's are played at inconsistent sizes as if PAR's are not being respected. Example: 2 MP4's encoded from one source, but cropped to different sizes (702x380 and 702x400) using par 16:15. The larger MP4 plays at a smaller size in both directions than the smaller one. (Source: PAL DVD) Also, if I crop only 4 pixels from the right hand side, the encoded MP4 plays at full width as if the par is being ignored, and the dar (4:3) is being maintained). This is producing inconsistent and undesirable results. I have tested this with both Totem and Kaffeine and the results are the same. Totem xine, vlc, and mplayer do not exhibit this behaviour.
Totem has a complicated algorithm for deciding on the pixel size of a video. This is not related to GStreamer, so I'm reassigning the bug to totem. It's generally considered more correct to scale horizontally (and not vertically) when converting to square pixels. The primary reason is to preserve any interlacing (which would be destroyed by vertical resampling), and the secondary reason is that if the video originated from a square pixel sensor, it was probably resampled horizontally to get to the non-square pixels, so re-resampling it horizontally will give the best results. However, since this only really affects the "1:1 window resizing" feature of Totem, I don't think the exact details of *what* size it goes to is that important. It's merely a user interface nicety, and I imagine that most users resize or full-screen the window, thus making "1:1 window" size details moot.
Despite your generalization, the other players don't do this: vlc, mplayer, and totem xine. And because totem xine doesn't do it, I thought it was a gstreamer bug. But that doesn't explain my 2 MP4's (see my previous example). I have encoded them using 4 different methods and the results are the same. Also, it does not explain why if I crop only 4 pixels from one side, the encoded MP4 plays at the original width, as if the dar has priority over par. Affecting only 1:1 windows makes it more important as 9/10 times the video is smaller than it should be. And I also imagine you're right about users resizing the window because of this very issue. It would only be a moot point if all players did this, but they do not.
Can you please post a link to (or e-mail me) these MP4 files?
Aside from copyright, I see no point as this happens to too many file types regardless of source. I'd prefer it if you didn't blame the video files, and consider the fact that this only happens with gstreamer based video players. The only file types that appear 'safe' are ones with a 1:1 par.
(In reply to comment #4) > Aside from copyright, I see no point as this happens to too many file types > regardless of source. I'd prefer it if you didn't blame the video files, and > consider the fact that this only happens with gstreamer based video players. > The only file types that appear 'safe' are ones with a 1:1 par. Yay! Completely bogus claim! I tested aspect ratio being missing in GStreamer using avi files lacking OPML data using Totem. So I'm not sure your point would stick. Provide us with a way to reproduce the problem, and I'll make sure to look at it. In the meanwhile, prrrt.
Bogus? How so? My point is based on my observations and extensive testing. If you had read my previous posts you would see how to reproduce the issue. Besides, I don't remember saying that the aspect was wrong, but only that the resizing was. And I don't like your tone Bastien. Not what you should expect from a developer.
(In reply to comment #6) > Bogus? How so? My point is based on my observations and extensive testing. If > you had read my previous posts you would see how to reproduce the issue. > Besides, I don't remember saying that the aspect was wrong, but only that the > resizing was. > > And I don't like your tone Bastien. Not what you should expect from a > developer. And I don't like the fact that you 1) insult the application by making claims I believe unfounded, 2) continually refuse to provide test files. I did test Totem with a number of files that have non-square pixels, and I believe that it works as expected. It's possible that the problem you see could come from: - the decoders not making the PAR available - the decoders making the wrong PAR available - Totem GStreamer backend bugs where the PAR would get updated after we set the window size etc. So I'd like to see those test files to reproduce the problem. You don't have to make the whole file available, or make it available to everyone. Alternatively, feel free to find a file that reproduces the problem at http://samples.mplayerhq.hu/.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!