After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 739566 - gdkpixbufoverlay: Fix relative-x/y and widen their range to support scolling images in/out of frame with GstController
gdkpixbufoverlay: Fix relative-x/y and widen their range to support scolling ...
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal enhancement
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2014-11-03 14:16 UTC by Lazar Claudiu
Modified: 2014-12-25 15:41 UTC
See Also:
GNOME target: ---
GNOME version: ---

Fix relative-x/y and change their range (2.39 KB, patch)
2014-11-03 14:17 UTC, Lazar Claudiu
none Details | Review
Fix positioning (1.29 KB, patch)
2014-11-21 14:18 UTC, Lazar Claudiu
rejected Details | Review
Added absolute properties (3.69 KB, patch)
2014-11-21 17:05 UTC, Lazar Claudiu
reviewed Details | Review

Description Lazar Claudiu 2014-11-03 14:16:46 UTC
Range change reason : sliding an image in and out of the video frame with GstController

relative-x was relative to overlay size not video frame size.
Comment 1 Lazar Claudiu 2014-11-03 14:17:16 UTC
Created attachment 289896 [details] [review]
Fix relative-x/y and change their range
Comment 2 Lazar Claudiu 2014-11-03 15:01:11 UTC
Right now "xpos" tries to center the text and CLAMPs it :

      *xpos = (gint) (overlay->width * overlay->xpos) - width / 2;
      *xpos = CLAMP (*xpos, 0, overlay->width - width);

This conflicts with GstController usage mostly because of the CLAMP but also because it doesn't offer precise positioning since text width is variable

I propose we add a "center-on-xpos" property that makes xpos behave like it does now but when set to FALSE it removes the CLAMP and just sets xpos to "overlay->width * overlay->xpos"

Same should be done for ypos and for gdkpixbufoverlay's relative-x/y
Comment 3 Lazar Claudiu 2014-11-04 21:35:19 UTC
Upon further thought I think implementing a new non-property-range based controller would make more sense
Comment 4 Tim-Philipp Müller 2014-11-17 00:16:11 UTC
Got a new suggestion then?
Comment 5 Lazar Claudiu 2014-11-21 14:17:10 UTC
There's a positioning bug when offset-x is negative.

Test :

gst-launch-1.0 videotestsrc num-buffers=100 ! gdkpixbufoverlay offset-x=-50 location=/home/claudiu/overlay.png ! x264enc ! mp4mux ! filesink location=/tmp/out.mp4
Comment 6 Lazar Claudiu 2014-11-21 14:18:23 UTC
Created attachment 291175 [details] [review]
Fix positioning
Comment 7 Tim-Philipp Müller 2014-11-21 16:15:48 UTC
Comment on attachment 291175 [details] [review]
Fix positioning

Well, the problem is that it's clearly not a positioning bug, but on purpose as per the property description: "For positive value, horizontal offset of overlay image in pixels from left of video image. For negative value, horizontal offset of overlay image in pixels from right of video image".

So you're just changing this to suit your own needs, but someone else might be relying on the previous interpretation of negtive values.
Comment 8 Lazar Claudiu 2014-11-21 17:05:30 UTC
Created attachment 291193 [details] [review]
Added absolute properties
Comment 9 Tim-Philipp Müller 2014-12-25 15:41:31 UTC
Thanks for the patch. After further discussion on IRC we decided to go or a positioning-mode property after all, so that we don't add even more offset properties, but just change the interpretation of the existing one:

commit f0e8821f76e3b82027e21a3b6f261d378d3aa906
Author: Tim-Philipp Müller <>
Date:   Thu Dec 25 14:58:12 2014 +0000

    tests: gdkpixbufoverlay-test: use absolute positioning to fix demo

commit b76595d67eb8c56830ab7c1cb55a45c660b3394f
Author: Tim-Philipp Müller <>
Date:   Thu Dec 25 14:53:09 2014 +0000

    gdkpixbufoverlay: add "positioning-mode" property to allow absolute positions
    Set positioning-mode=pixels-absolute to allow positioning with
    absolute coordinates, meaning negative x/y offsets will be
    interpreted as being to the left/above the video frame instead
    of being interpreted as relative to the right/bottom edge of
    the video frame (which is a silly default, but that's how it is).
    This means we can nicely slide images into and out of the frame,
    see gdkpixbufoverlay-test.

Now what's still missing is the direct/absolute support for GstController :)