GNOME Bugzilla – Bug 725418
videoscale ignores add-borders property - Always maintains aspect ratio.
Last modified: 2014-03-03 18:42:01 UTC
I have a simple need to take a calibration video and resize it to fill a monitor screen, regardless of changes to aspect ratio. The only extant element that performs video resizing is videoscale, and there appears no way to make it modify the aspect-ratio of its incoming video. Logically, the add-borders property should control this, as the only time one would ever need to add borders as part of a rescaling is so as to maintain the aspect ratio of input content while conforming to the aspect ratio of the outgoing video frame. In practice I have not been able to find any behavioral differences in videoscale between when add-borders is operational and when it is not. In fact, I've never even managed to get it to provide a visible border... Here are two example pipelines only differing in the add-border property of videoscale, and what I think they should display: gst-launch-1.0 videotestsrc ! "video/x-raw, width=1920, height=1080" ! videocrop right=960 ! videoscale add-borders=true method=0 ! "video/x-raw,width=1920,height=1080" ! videoconvert ! xvimagesink display=:2 The pipeline above using the (default) true setting for add-borders takes a test video, crops it to half width, and then asks it to be resized to full width. I would expect the result to be the left half of my test video, centered with black borders on the right and left so as to once again be full width. In fact what is produced appears to be the left half of my video with the right half replaced (I assume) with a transparent alpha border. When we use this pipeline: gst-launch-1.0 videotestsrc ! "video/x-raw, width=1920, height=1080" ! videocrop right=960 ! videoscale add-borders=false method=0 ! "video/x-raw,width=1920,height=1080" ! videoconvert ! xvimagesink display=:2 The results are identical to the first pipeline, while what I expected to see was the left half of my test video stretched horizontally to fill the entire output frame. So, in summary, neither setting for add-borders appears to do what it should, nor, in fact, does it appear to do anything at all.
Try setting a pixel-aspect-ratio in the caps downstream of videoscale. videoscale tries to preserve the display aspect ratio in any case as good as possible, and if downstream supports any pixel-aspect-ratio (like xvimagesink does) it will use that to preserve the display aspect ratio.
Okay, I can confirm that setting pixel-aspect-ratio=1/1 downstream of the videoconvert causes the two cases above to give exactly the output I expected. However I am baffled as to WHY that is the case. Surely pixel-aspect-ratio is a physical property of the pixels of the output device, and should be set by xvimagesink, no? Why do I have to set it, and why does setting it to the expected default do what I want???
The default, and most common use case in GStreamer is to preserve aspect ratio. So let's have a look at some caps: gst-launch-1.0 -v videotestsrc ! video/x-raw,width=300,height=300 ! videoscale ! video/x-raw,width=600,height=300 ! xvimagesink videotestsrc will produce, 300x300 with 1/1 aspect ratio. videoscale Will scale width from 300 to 600 and set aspect ratio to 2/1 xvimagesink will respect ratio, and will display a 300x300 window by scaling down gst-launch-1.0 -v videotestsrc ! video/x-raw,width=300,height=300 ! videoscale ! video/x-raw,width=600,height=300,pixel-aspect-ratio=1/1 ! xvimagesink Now we addup a constraint, we fixed the display aspect ratio. videotestsrc will do the same, but videoscale will still want to keep aspect ratio and will add black porders. gst-launch-1.0 -v videotestsrc ! video/x-raw,width=300,height=300 ! videoscale add-borders=0 ! video/x-raw,width=600,height=300,pixel-aspect-ratio=1/1 ! xvimagesink This time, with add-borders to zero, video scale is forced to break the display aspect ratio (what you want) in order to comply with the downstream requirement. So videoscale will scale the width from 300 to 600, but pixel-aspect-ratio will remain 1/1. Basically breaking the aspect ratio will only be done at last resort, but is still better then failing the pipeline. Forcing videoscale to break aspect ratio isn't easy, and setting downstream caps is the way forward.
And the PAR is not only a property of the display device (and actually things like xvimagesink can handle every PAR) but generic metadata about how pixels should be interpreted.