The current code was ignoring the par/dar aspect when transforming
from window coordinates to stream coordinates resulting in incorrect
coordinates being sent upstream in the navigation events.
https://bugzilla.gnome.org/show_bug.cgi?id=744763
Add a pivot vector for setting the origin of rotations and scales.
With the pivot point the rotation and scale operations can have
different origins. This adds the ability to rotate around different points.
Currently the default (0, 0) pivot point is possible,
a rotation around the center, and zooming into and out of the center.
With an pivot point this is optional.
I defined the following image coordinates for the pivot point:
(-1,1) ------------------------- (1,1)
| |
| |
| |
| (0,0) |
| |
| |
| |
(-1,-1) ------------------------- (1,-1)
Example:
Rotate the video at the bottom left corner
gst-launch-1.0 videotestsrc \
! gltransformation \
scale-x=0.5 \
scale-y=0.5 \
rotation-z=25.0 \
pivot-x=-1.0 \
pivot-y=-1.0 \
! glimagesink
The pivot-z option defines the pivot point in 3D space.
This only affects rotation, since we have no Z data to scale.
With this option a video can be rotated around a point in 3D space.
Example:
Rotate around point behind the video:
gst-launch-1.0 videotestsrc \
! gltransformation \
rotation-x=10.0 \
pivot-z=-4.0 \
! glimagesink
The ref_object and object parameters were the wrong way around.
For the typical use case where an application is setting a
GstControlBinding on the returned ghost pad:
1. our control binding would be removed when the new one was set
2. sync_values calls were not being forwarded from the internal
pad to the ghost pad.
If an application attempts to perform other control binding
operations (get_* family of functions) on the internal pad, they
will also be forwarded to the ghost pad where a possible
GstControlBinding will provide the necessary values.
This is used to proxy GstControlBinding to the pad on the
parent object. This avoid having to sync the values in the proxy pad,
this is too early if you have a queue between the pad and the actual
aggregation operation.
https://bugzilla.gnome.org/show_bug.cgi?id=734060
When the sink does not know the window size (e.g not created yet)
it will not add any param to the the composition meta. This is no
reason not to forward this meta API. Fixes issue where it could not
attach until we resize the window.
https://bugzilla.gnome.org/show_bug.cgi?id=745107
The coordinate are relative to the texture dimension and not
the window dimension now. There is no need to pass the window
dimension or to update the overlay if the dimension changes.
https://bugzilla.gnome.org/show_bug.cgi?id=745107
Adds an GST_VIDEO_OVERLAY_COMPOSITION_META_API_TYPE query to glupload
and glimagesink. Detects the query from the downstream elements, so
it is executed only when downstream supports the overlay API.
This makes pipelines with textoverlay ! glupload ! gldownload ! xvimagesink possible.
Uses allocation meta struct for passing the window size upstream.
https://bugzilla.gnome.org/show_bug.cgi?id=745107
I notice that if you stop the pipeline during a renegotiation
the upload may be NULL while an allocation query is being run.
In that scenario, returning FALSE to the allocation query is the
best thing.
Support video with multiview info in the caps, transform
it to mono anaglyph by default, but allow for configuring
other output modes and handoff to the app via
the draw signal.
https://bugzilla.gnome.org/show_bug.cgi?id=611157
We now know that pool caching can cause renegotiation issues
when an element in the pipeline change from passthrough to not
passthrough. As it's not needed, don't cache existing pools.
https://bugzilla.gnome.org/show_bug.cgi?id=748344
Previously when compiling GstGL with both GL and GLES2,
GL_RGBA8 was picked from GL/gl.h. But a clash may happen at
runtime when one is selecting GLES2.
gst_gl_internal_format_rgba allows to check at runtime
if it should use GL_RGBA or GL_RGBA8.
