On the ODroid C1+ the H265 and H264 have the same name but are listed as two
different codecs. We have to handle them as the same one that supports both,
as otherwise we will register the same GType name twice which fails and we
then only have H265 support and not H264 support.
ahssrc is a new plugin that enables Gstreamer to read from the
android.hardware.Sensor Android sensors. These sensors are treated as
buffers and can be passed through and manipulated by the pipeline.
https://bugzilla.gnome.org/show_bug.cgi?id=768110
The calculation of the offset table was done base on a plane size
estimation. This does not always work. Instead, use memory offset the
same we as it's implement in GstVideoMeta map functions.
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
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.
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
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.
strcasecmp is not defined on MSVC, so just use the glib wrapper. Also pretend to
be Windows XP explicitly since the API we use was deprecated and removed
(ifdef-ed) from the SDK after this version of Windows. This will be especially
relevant once we stop supporting Windows XP soon:
https://bugzilla.gnome.org/show_bug.cgi?id=756866
The URI must already be escaped by the caller, we don't support passing around
invalid (unescaped) URIs via the GstURIHandler interface.
Also it will escape too much of the URI in this case, e.g.
ipod-library://item/item.m4a?id=3143338395173862951
becomes
ipod-library://item/item.m4a%3Fid%3D3143338395173862951
https://bugzilla.gnome.org/show_bug.cgi?id=767492
Move calling gst_vtdec_push_frames_if_needed from ::set_format to ::negotiate so
that we always drain even when renegotiation is triggered by downstream.
vtdec specifies sysmem; GLMemory as template caps. When negotiating, we used to
call gst_pad_peer_query_caps (..., filter) with our template caps as filter. The
query does gst_caps_intersect (filter, peercaps) internally which gives
precedence to the order of the filter caps. While we want to output sysmem by
default, when negotiating with glimagesink which returns GLMemory; sysmem; we
do want to do GL, so we now query using a NULL filter and intersect the result
with our template caps giving precedence to downstream's caps.
tl;dr: make sure we end up negotiating GLMemory with glimagesink
If for some reason the avdtpsink element can't go READY then the
gsta2dpsink can't either and so should release the ressources it
allocates when trying to do so.
Fix a leak with the generic/states test.
https://bugzilla.gnome.org/show_bug.cgi?id=767161
Similar to vtdec_hw, this commit adds a vtenc_h264_hw element that fails
caps negotiation unless a hardware encoder could actually be acquired.
This is useful in situations where a fallback to a software encoder
other than the vtenc_h264 software encoder is desired (e.g. to x264enc).
https://bugzilla.gnome.org/show_bug.cgi?id=767104
When renegotiating mid stream - for example with variable bitrate
streams - and therefore destroying and recreating VTSessions, the
hw decoder might become temporarily unavailable.
To deal with this and avoid erroring out on bitrate changes,
vtdec_hw now falls back to using the software decoder if the hw
one was available at some point but isn't anymore. At
renegotiation/bitrate change time, it will still retry to open
the hardware one.
::negotiate can be called several times before the CAPS event is sent downstream
so use the currently configured output state caps instead of the pad current
caps when deciding whether to recreate the VTSession or not.
This leads to creating/destroying less VTSessions which makes renegotiation more
reliable especially when using hw decoding.
There's no need for an end-of-list marker in the filter
PIDs array if full, as the absolute maximum number of
elements (MAX_FILTERS) is known.
CID #1362441
This bug was found via cppcheck static analysis.
If android.hardware.Camera.getParameters returns NULL, then object will
be NULL, and we won't allocate params. This means that the GST_DEBUG
statement referencing params->object will be invalid. Fix this by
exiting early if android.hardware.Camera.getParameters returns NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=766638
There is no way to tell one over the other when parameters
seem valid for DVB-T and DVB-T2 and the adapter supports
both. Reason to go with the former here is that, from
experience, most DVB-T2 channels out there seem to use
parameters that are not valid for DVB-T, like QAM_256
https://bugzilla.gnome.org/show_bug.cgi?id=765731
DVB-T/T2 have the same number of fields so we were
wrongly assuming DVB-T for DVB-T2 broadcasts. Not
setting the delivery system here allows for dvbsrc
to make an informed guess based on the channel
parameters.
When there's no explicit delivery system information
for a channel in the channel configuration file and
the user hasn't selected one via setting the delsys
property, we *guessed* it by selecting the last
supported delsys reported by the driver. This change
provides the basis for smarter delsys auto detection
and implements a rule for DVB-T2. Rules for other
delivery systems can be added in _guess_delsys() in
a similar way.
Additionally: Store list of adapter-supported
delivery systems instead of querying the driver each
time this information is needed.
Related to:
https://bugzilla.gnome.org/show_bug.cgi?id=765731
The device name and descriptions returned are in the locale encoding, not
UTF8. Our device name property is in UTF8 though, so we need to convert.
https://bugzilla.gnome.org/show_bug.cgi?id=756948
The only mandatory frontend information for our use case
is its status. Make sure we output what we know instead
of choking at the first error getting SNR, BER or any of
the other informational parameters.
