The same symbol also exists in libgstgl, although marked as private and
internal. This has no effect when doing static linking and there's a
symbol conflict.
glvideomixer does not support it currently and it needs special support
for handling this correctly, and is rather non-trivial to implement for
all formats.
Facilities are given to create fbo's and attach GL memory (renderbuffers
or textures). It also keeps track of the renderable size for use with
effective use with glViewport().
Provide a function to get the affine matrix in the meta in terms of NDC
coordinates and use as a standard opengl matrix.
Also advertise support for the affine transformation meta in the allocation
query.
We weren't using the result of find_best_format at all.
Also, move the find_best_format usage to the default update_caps() to make
sure that it is also overridable.
https://bugzilla.gnome.org/show_bug.cgi?id=764363
We want to iterate over all the pads, not just the first one. Fix by returning
TRUE in the GstAggregatorPadForeachFunc.
Removes a GST_IS_GL_CONTEXT() assertion on shutdown with >2 inputs
using gst-launch.
Allows the subclass to completely override the chosen src caps.
This is needed as videoaggregator generally has no idea exactly
what operation is being performed.
- Adds a fixate_caps vfunc for fixation
- Merges gst_video_aggregator_update_converters() into
gst_videoaggregator_update_src_caps() as we need some of its info
for proper caps handling.
- Pass the downstream caps to the update_caps vfunc
https://bugzilla.gnome.org/show_bug.cgi?id=756207
Allows more blending options than just A over B
e.g. frame comparisons are now possible.
glvideomixer name=m
sink_0::zorder=0
sink_1::zorder=1
sink_1::blend-equation-rgb={subtract,reverse-subtract}
sink_1::blend-function-src-rgb=src-color
sink_1::blend-function-dst-rgb=dst-color
! glimagesinkelement
videotestsrc pattern=checkers-4 ! m.sink_0
videotestsrc pattern=checkers-8 ! m.sink_1
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
