The previous code would run out of sync if there was packet lost
or clock skews. When that happened, the echo cancellation feature would
completely stop working. As this is crucial for audio calls, this patch
re-implement synchronization completely.
Instead of letting it drift until next discont, we now synchronize
against the record data at every iteration. This way we simply never
let the stream drift for longer then 10ms period. We also shorter the
delay by using the latency up the probe (basically excluding the sink
latency. This is a decent delay to avoid starving in the probe queue.
https://bugzilla.gnome.org/show_bug.cgi?id=768009
When echo cancel is enabled, we now fail the pipeline if there is
not echo probe. For this reason there is no need to check if probe
pointer is set anymore.
Calling glUniformMatrix before the shader is bound is invalid and
would result in errors like:
GL_INVALID_OPERATION in glUniformMatrix(program not linked)
Move glUniformMatrix() to after the gst_gl_shader_use() call.
Without setting the DRM_CLIENT_CAP_UNIVERSAL_PLANES capability bit, only
overlay planes are made available for compatibility with legacy clients.
But if a CRTC doesn't have an overlay plane associated, then kmssink is
not able to find a plane for the CRTC and the pipeline will fail, i.e:
ERROR kmssink gstkmssink.c:482:gst_kms_sink_start:<kmssink0> Could not find a plane for crtc
If no overlay planes were found for a given CRTC, fallback to universal
planes so DRM will also return primary planes that can be used instead.
https://bugzilla.gnome.org/show_bug.cgi?id=768183
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Without setting the DRM_CLIENT_CAP_UNIVERSAL_PLANES capability bit, only
overlay planes are made available for compatibility with legacy clients.
But if a CRTC doesn't have an overlay plane associated, then kmssink is
not able to find a plane for the CRTC and the pipeline will fail, i.e:
ERROR kmssink gstkmssink.c:482:gst_kms_sink_start:<kmssink0> Could not find a plane for crtc
This patch adds a plane-id property to the kmssink element so a specific
plane can be used in case that a CRTC has only a primary plane associated.
https://bugzilla.gnome.org/show_bug.cgi?id=768183
The byte-stream to avc conversion did not consider NAL sizes bigger than 2^16,
multiple layers, multiple NALs per layer, and various other things. This
caused corrupted streams in higher bitrates and other circumstances.
Let's just forward byte-stream as generated by the encoder and let h264parse
handle conversion to avc if needed. That way we only have to keep around one
version of the conversion and don't have to fix it in multiple places.
When skipping data, check if they are filler bytes. If so, drop the
data instead of skipping. We don't want to output filler bytes, but they
shouldn't cause a discontinuity.
https://bugzilla.gnome.org/show_bug.cgi?id=768125
Rather than assuming something. e.g. zerocopy on iOS with GLES3 requires
the use of Luminance/Luminance Alpha formats and does not work with
Red/RG textures.
Take the used texture type from the memory instead.
Fixes conversion from multi-planar YUV formats with two components per plane
(NV12, NV21, YUY2, UYVY, GRAY16_*, etc) with Luminance Alpha input textures.
This is also needed for zerocopy decoding on iOS with GLES 3.x.
The intention was to assert if both maj and min were NULL (as there would be no
point calling the function). Instead if either maj or min were NULL, the assert
would occur.
Fix that.
Some names were incorrect. Authoritative source for
the dvbv5 format taken from v4l-utils' lib/libdvbv5/dvb-v5.c
Aditionally, add the missing setter mapping for the
modulation param.
This change makes ATSC work.
https://bugzilla.gnome.org/show_bug.cgi?id=764957
If the input alignment claims AU alignment, each received
buffer should contain a complete video frame, so never hold over parts
of buffers for later processing. Also reduces latency, as packets
are parsed/converted and output immediately instead of 1 buffer
later.
Fixes a problem where an (arguably disallowed) padding byte on the
end of a buffer is detected as an extra byte in the following
start code, and messes up the timestamping that should apply to
that start code.
The saved timestamp is used to compute the delay of the probe data.
As it's used at the following incoming buffer, it needs to be offset
with the duration of the buffer to represent the end position. Also,
properly initialize the saved timestamp and protect against TIME_NONE.
Until now, we were synchronizing both DSP and Probe adapter by
waiting and clipping the probe adapter data. This increases the CPU
usage, can cause copies if the audio is not 10ms aligned and the worst
is that it prevents the processing from compensating for inaccurate
latency. This is also a step forward toward supporting playback
filters.
The hardware decoder can become (temporarily) unavailable across
VTDecompressionSessionCreate/Destroy calls. During negotiation if the currently
configured caps are still accepted by downstream we keep using them so we don't
have to destroy and recreate the decoding session.
This indirectly fixes https://bugzilla.gnome.org/show_bug.cgi?id=767429, by
making vtdec stick to GLMemory.
The current state of c++ ABI's on Window's and Gst's/Qt's conflicting
mingw builds means that we cannot use mingw for building the qt plugin.
Instead, a qmake .pro file is provided that is expected to be used with the
msvc binaries provided by Qt like so:
(with the PATH environment variable containing the path to the qt biniaries
and PKG_CONFIG_PATH containing the path to GStreamer modules)
cd /path/to/sources/gst-plugins-bad/ext/qt
qmake -tp vc
Then open the resulting VS project and build the library. Then
cp debug/libgstqtsink.dll /path/to/prefix/lib/gstreamer-1.0/libgstqtsink.cll
https://bugzilla.gnome.org/show_bug.cgi?id=761260
This is an automatic update with manual merges of running
"make update" in the doc/plugins directory. This should help
later maintenance of the plugins doc. A lot of plugin are
not referenced yet in the doc. Will come later.
