GNOME Bugzilla – Bug 561342
ximagesink with force-aspect-ratio loses the original aspect ratio after some resizes
Last modified: 2011-05-19 09:06:21 UTC
Please describe the problem: ${summary} Steps to reproduce: 1. gst-launch filesrc location=blah.mov ! decodebin ! ffmpegcolorspace ! videoscale ! ximagesink force-aspect-ratio=true 2. resize the video window horizontally between 20px and 100px back and forth Actual results: after a few resizes, the video is completely squished vertically to 1px Expected results: Does this happen every time? yes, but apparently only some video formats are affected. I can reproduce this with .mov and .flv files, while Jan (thaytan) couldn't reproduce with .flv Other information:
Created attachment 122932 [details] gst-inspect log with GST_DEBUG=ximagesink:4 output log from the above command with GST_DEBUG=ximagesink:4 selected excerpts from this log : line 12 : width=(int)320, height=(int)239 (which make a 1.34 ratio) line 1612 : width=(int)80, height=(int)13 (which make a 6.15 ratio) I closed the video at this point but if I resize back up to a width of 320, the aspect ratio will indeed be stay very big.
I just found that if I take a 352x288 video with the pipeline above and then shrink it vertically until it's quite small, and then make it bigger again, it does indeed come back with an incorrect (vertically stretched) aspect ratio. Also, if I then keep stretching it vertically, I get a crash inside videoscale, which is possibly unrelated, but maybe not.
This doesn't crash anymore but the aspect ratio is not kept. This happens because videoscale will do the scaling to the width/height of the ximagesink window and it only tries to keep the aspect-ratio as good as possible. If you set the add-borders property of videoscale to TRUE this will work as expected.