There is new code that ensures that we renegotiate after an
uploader transition if the negotiated caps have changed.
The problem is that the raw uploader will not really try and
fixate the input caps, but instead of return a subset with the
only the supported target texture.
This had two effect, raw uploads was always done renegotiated
once and the raw upload unit test was now failing as it didn't
expect a renegotiation.
As it's a valid check, simply relax the gst_caps_is_equal() check
and use a gst_caps_is_subset() instead.
https://bugzilla.gnome.org/show_bug.cgi?id=783521
The direct dmabuf upload does color conversion, so when it transforms
the caps, it replaces the format with all formats found through the
format query. When this uploader can't be used, it makes the upstream
source pick a unsupported format.
To fix this, we only append the caps with a list of format. So the
source will only pick one of these formats if the downstream preferred
format is not supported. A negotiation failure after this would be
normal.
This fixes pipelines without a glcolorconvert element.
https://bugzilla.gnome.org/show_bug.cgi?id=783521
The unit test makes mixed usage of ret value. Sometimes its does
stores an enum and at other moment a boolean. Also fix test
using boolean instead of the correct enum value.
https://bugzilla.gnome.org/show_bug.cgi?id=783521
This new property controls the synchronisation offset between the text and video
streams. Positive values make the text ahead of the video and negative values
make the text go behind the video.
https://bugzilla.gnome.org/show_bug.cgi?id=797134
This new property controls the synchronisation offset between the text and video
streams. Positive values make the text ahead of the video and negative values
make the text go behind the video.
https://bugzilla.gnome.org/show_bug.cgi?id=797134
When the playsink contains a text chain this property controls the
synchronisation of the subtitles and video by controlling the underlying
subtitleoverlay::subtitle-ts-offset property.
https://bugzilla.gnome.org/show_bug.cgi?id=797134
The idea is that some GPUs (like the Vivante series) can actually
perform the YUV->RGB conversion internally, so no custom conversion
shaders are needed. To make use of this feature, we need an additional
uploader that can import DMABUF FDs and also directly pass the pixel
format, relying on the GPU to do the conversion.
Based on patches from Nicolas Dufresne <nicolas.dufresne@collabora.com> and
Carlos Rafael Giani <dv@pseudoterminal.org>.
https://bugzilla.gnome.org/show_bug.cgi?id=783521
Without this, a buffer is dropped if glupload indicates that it is
necessary to reconfigure.
Avoid this by explicitly reconfiguring immediately and uploading the buffer
again.
https://bugzilla.gnome.org/show_bug.cgi?id=783521
If a upload method is selected then use it exclusively in transform_caps().
Also, reconfigure if the current caps don't match the current upload
method.
https://bugzilla.gnome.org/show_bug.cgi?id=783521
This should not be necessary, but currently not all plugins that provide
dmabuf memory announce this with caps features, e.g. v4l2.
The static caps already contain the system memory. It didn't break before
because other upload methods provide the necessary transformation.
https://bugzilla.gnome.org/show_bug.cgi?id=783521
Reconfigure will trigger a set_caps which clears the upload method.
Remember the method in this case and start with it.
Wrap around once to try all methods if necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=783521
The colorspace conversion happens during the upload so the necessary hints
must be provided to ensure that the conversion works correctly.
At least the Mesa Intel driver will create a texture without error but
produces an incorrect result. Use eglQueryDmaBufModifiersEXT() to check if
non-external upload is supported for the given format.
Based on a patch from Carlos Rafael Giani <dv@pseudoterminal.org>.
https://bugzilla.gnome.org/show_bug.cgi?id=783521
gst_gl_memory_setup_buffer() was not properly using the number
of pointers to wrapped. This also fixes the validation, as we
only support 1 wrapper per view, or num_planes * views wrapper.
https://bugzilla.gnome.org/show_bug.cgi?id=783521
This removes the crossfade-ratio property and replaces it with an
operator property. Currently this implements the following operators:
- SOURCE: Copy over the source and don't look at the destination
- OVER: Default blending of the source over the destination
- ADD: Like OVER but simply adding the alpha instead
See the example for how to implement crossfading with this.
https://bugzilla.gnome.org/show_bug.cgi?id=797169
The previous failure was a timeout which was due to the sending pipeline
pushing test buffer *before* the remote client was accepted. We would
therefore never get the buffer on the other side.
While the client socket would indeed appear as "connected", this doesn't
mean that the remote server side did "accept" it (which is where we then
add it to the list of remote parties to which data will be sent).
The problem isn't with the element implementation, but to the nature of
TCP 3-way handshake.
In order to make the test reliable, wait for the sink to have accepted
the remote client (by checking the number of handles) before sending out
test buffers.
rtsp_connection_send takes care of adding those already,
and some reverse proxies such as nginx will reject the request
altogether if the Authorization header is present twice,
even with the same value.
https://bugzilla.gnome.org/show_bug.cgi?id=797272
Add a source-info property that will read/write meta to the buffers
about RTP source information. The GstRTPSourceMeta can be used to
transport information about the origin of a buffer, e.g. the sources
that is included in a mixed audio buffer.
A new function gst_rtp_base_payload_allocate_output_buffer() is added
for payloaders to use to allocate the output RTP buffer with the correct
number of CSRCs according to the meta and fill it.
RTPSourceMeta does not make sense on RTP buffers since the information
is in the RTP header. So the payloader will strip the meta from the
output buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=761947
