For each lib we build export its own API in headers when we're
building it, otherwise import the API from the headers.
This fixes linker warnings on Windows when building with MSVC.
The problem was that we had defined all GST_*_API decorators
unconditionally to GST_EXPORT. This was intentional and only
supposed to be temporary, but caused linker warnings because
we tell the linker that we want to export all symbols even
those from externall DLLs, and when the linker notices that
they were in external DLLS and not present locally it warns.
What we need to do when building each library is: export
the library's own symbols and import all other symbols. To
this end we define e.g. BUILDING_GST_FOO and then we define
the GST_FOO_API decorator either to export or to import
symbols depending on whether BUILDING_GST_FOO is set or not.
That way external users of each library API automatically
get the import.
While we're at it, add new GST_API_EXPORT in config.h and use
that for GST_*_API decorators instead of GST_EXPORT.
The right export define depends on the toolchain and whether
we're using -fvisibility=hidden or not, so it's better to set it
to the right thing directly than hard-coding a compiler whitelist
in the public header.
We put the export define into config.h instead of passing it via the
command line to the compiler because it might contain spaces and brackets
and in the autotools scenario we'd have to pass that through multiple
layers of plumbing and Makefile/shell escaping and we're just not going
to be *that* lucky.
The export define is only used if we're compiling our lib, not by external
users of the lib headers, so it's not a problem to put it into config.h
Also, this means all .c files of libs need to include config.h
to get the export marker defined, so fix up a few that didn't
include config.h.
This commit depends on a common submodule commit that makes gst-glib-gen.mak
add an #include "config.h" to generated enum/marshal .c files for the
autotools build.
https://bugzilla.gnome.org/show_bug.cgi?id=797185
The gst_video_decoder_clip_and_push_buf() now drops the internal stream
lock while pushing. This means, the output_queued list could be modififed
during that time. To make the code safe again, we delete the link before
pushing the data. The walk pointer will later be updated with the list
head, which makes it safe in case the list was modififed.
https://bugzilla.gnome.org/show_bug.cgi?id=715192
Release STREAM_LOCK before calling gst_pad_push() and take it
back afterward so that upstream isn't blocked while output
buffer is being pushed downstream.
https://bugzilla.gnome.org/show_bug.cgi?id=715192
Release STREAM_LOCK before calling gst_pad_push() and take it
back afterward so that upstream isn't blocked while output
buffer is being pushed downstream.
https://bugzilla.gnome.org/show_bug.cgi?id=715192
Add a new macro that gives you the rate of the fields, which is the
numerator of the field-rate for ALTERNATE interlacing video and FPS for
progressive and other interlacing formats.
https://bugzilla.gnome.org/show_bug.cgi?id=796106
Add a variant of gst_video_decoder_set_output_state() that allows the user
to pass an interlacing mode as well. This is needed to ensure that
gst_video_info_set_interlaced_format() is used instead so that
GstVideoInfo.size is correctly initialized.
https://bugzilla.gnome.org/show_bug.cgi?id=796106
Add a new macro that gives you the height of a field. It returns the
height of the full frame unless split-field (alternate) interlacing is
in use. Also GST_VIDEO_INFO_COMP_HEIGHT macro now uses this new macro to
get the height for its calculation.
https://bugzilla.gnome.org/show_bug.cgi?id=796106
Add a helper to set the interlacing mode while creating the GstVideoInfo
in addition to format and resolution. Using this helper will ensure that
size is correctly calculated for split-field interlacing mode.
https://bugzilla.gnome.org/show_bug.cgi?id=796106
Add a new interlace mode enum to represent buffers containing a single
field of an interlaced video in a buffer. The name is based on the
equivalent video format in the V4L2 API, V4L2_FIELD_ALTERNATE:
https://01.org/linuxgraphics/gfx-docs/drm/media/uapi/v4l/field-order.html
Since caps fields are optional, we also introduce a new caps feature,
"format:Interlaced" that always goes with "alternate" interlace mode to ensure
that caps for this incompatible format are incompatible with other interlaced
and progressive video caps.
https://bugzilla.gnome.org/show_bug.cgi?id=796106
V4L2 and OMX decoder don't support draining and keeping reference
frames. As a side effect, these decoder just stops working on
gaps/discont. When this drain was introduced, the commit stated that
this was for TRICKMODE_KEY_UNITS, so only drain if running in this mode.
https://bugzilla.gnome.org/show_bug.cgi?id=796771
This pixel format is a fully packed variant of NV12_10LE32,
a luma pixel would take 10bits in memory, without any
filled bits between pixels in a stride. The color range
follows the BT.2020 standard.
In order to get a better performance in hardware memory
operation, it may expend the stride, append zero data at the
end of echo lines.
Pack function by Nicolas Dufresne.
https://bugzilla.gnome.org/show_bug.cgi?id=795462
Signed-off-by: Nicolas Dufresne <nicolas@ndufresne.ca>
Signed-off-by: ayaka <ayaka@soulik.info>
This moves all the conversion related code to a single place, allows
less code-duplication inside compositor and makes the glmixer code less
awkward. It's also the same pattern as used by GstAudioAggregator.
This is only used for caching reasons and should never actually be in
the public API. If this is ever a bottleneck later, caching around a
class private struct could be implemented.
The aggregated_frame is now called prepared_frame and passed to the
prepare_frame and cleanup_frame virtual methods directly. For the
currently queued buffer there is a method on the video aggregator pad
now.
The problem is that even though the functions we are calling are
in-place transformation, orc automatically puts the restrict keyword
on all arguments. To silence that warning just create yet-another
variable containing the same value.
https://bugzilla.gnome.org/show_bug.cgi?id=795765
This pixel format is a fully packed variant of NV12, a luma
pixel would take 10bits in memory, without any filled bits
between pixels in a stride. The color range follows
the BT.2020 standard.
In order to get a performance in hardware memory
operation, it may expend the stride, append zero data at the
end of echo lines.
Signed-off-by: ayaka <ayaka@soulik.info>
https://bugzilla.gnome.org/show_bug.cgi?id=795462
the meta initialization function is provided *after* the base implementation
fields have been set so do *NOT* reset them otherwise it would result
in corrupted GstMeta.
Instead explicitely set our fields to the default values we actually want.
This commits add common elements for Ancillary Data and Closed
Caption support in GStreamer:
* A VBI (Video Blanking Interval) parser that supports detection
and extraction of Ancillary data according to the SMPTE S291M
specification. Currently supports the v210 and UYVY video
formats.
* A new GstMeta for Closed Caption : GstVideoCaptionMeta. This
supports the two types of CC : CEA-608 and CEA-708, along with
the 4 different ways they can be transported (other systems
are super-set of those).
https://bugzilla.gnome.org/show_bug.cgi?id=794901
We need different export decorators for the different libs.
For now no actual change though, just rename before the release,
and add prelude headers to define the new decorator to GST_EXPORT.
We need different export decorators for the different libs.
For now no actual change though, just rename before the release,
and add prelude headers to define the new decorator to GST_EXPORT.
The current GstVideoRegionOfInterestMeta API allows elements to detect
and name ROI but doesn't tell anything about how this information is
meant to be consumed by downstream elements.
Typically, encoders may want to tweak their encoding settings for a
given ROI to increase or decrease their quality.
Each encoder has its own set of settings so that's not something that
can be standardized.
This patch adds encoder-specific parameters to the meta which can be
used to configure the encoding of a specific ROI.
A typical use case would be: source ! roi-detector ! encoder
with a buffer probe on the encoder sink pad set by the application.
Thanks to the probe the application will be able to tell to the encoder
how this specific region should be encoded.
Users could also develop their specific roi detectors meant to be used with a
specific encoder and directly putting the encoder parameters when
detecting the ROI.
https://bugzilla.gnome.org/show_bug.cgi?id=793338
The source offset (soff) was not incremented for each component and then
each group of 3 components were inverted. This was causing a staircase
effect combined with some noise.
https://bugzilla.gnome.org/show_bug.cgi?id=789876
This adds a 10 bit variant for NV16 packed into 32 bits little endian
words. The MSB 2 bits are padding. This format is used on Xilinx SoC and
identified with the FOURCC XV20.
https://bugzilla.gnome.org/show_bug.cgi?id=789876
This add a 10bit variant of gray scale packed into 32bits little endian
words. The MSB 2 bits are padding and should be ignored. This format is
used on Xilinx SoC and is identified with the FOURCC XV10.
https://bugzilla.gnome.org/show_bug.cgi?id=789876
This adds a 10bit variant for NV12 which packs 3 10bit components
into little endian 32bit words. The MSB 2 bits are padding and should be
ignored. This format is used on Xilinx SoC and is identified with there
with the FOURCC XV15
https://bugzilla.gnome.org/show_bug.cgi?id=789876
The lock is already taken before calling the flush method and can lead to
deadlock for some encoders that need to take the same lock from another
thread while flushing
https://bugzilla.gnome.org/show_bug.cgi?id=787311
It allows encoders to detect and drop input frames which are already
late to increase the chance of the pipeline to catch up.
The QoS logic and code is directly copied from gstvideodecoder.c.
https://bugzilla.gnome.org/show_bug.cgi?id=582166
This is used to indicate upstream the requirement in buffers
while no buffer pool can be provided. In this case, only
configure the pool with caps/size/min/max if we have caps,
which we only parsed when there was no allocation pool.
https://bugzilla.gnome.org/show_bug.cgi?id=730758
__gst_video_element_proxy_caps is called by
__gst_video_element_proxy_getcaps with caps set to the caps
allowed downstream. As we didn't set colorimetry or
chroma-site on the resulting caps, upstream considered it
possible to use whatever values it wanted, leading to
not negotiated errors later on.
As the description for that function is:
"Takes caps and copies its video fields to tmpl_caps",
it seems legitimate to set these fields there.
https://bugzilla.gnome.org/show_bug.cgi?id=786172
The goal here is to minimize the work needed to bring all images
to a common format. A better criteria than the number of pads
with a given format is the number of pixels with a given format.
https://bugzilla.gnome.org/show_bug.cgi?id=786078
Crossfading is a bit more complex than just having two pads with the
right keyframes as the blending is not exactly the same.
The difference is in the way we compute the alpha channel, in the case
of crossfading, we have to compute an additive operation between
the destination and the source (factored by the alpha property of both
the input pad alpha property and the crossfading ratio) basically so
that the crossfade result of 2 opaque frames is also fully opaque at any
time in the crossfading process, avoid bleeding through the layer
blending.
Some rationnal can be found in https://phabricator.freedesktop.org/T7773.
https://bugzilla.gnome.org/show_bug.cgi?id=784827
When the pad has received EOS, its buffer may still be mixed
any number of times, when the pad's framerate is inferior
to the output framerate.
This was introduced by my patch in
https://bugzilla.gnome.org/show_bug.cgi?id=782962, this patch
also correctly addresses the initial issue.
When the input is TRICKMODE_KEY_UNITS, we expect to only receive keyframes
which we want to decode/push immediately. Therefore don't queue them.
If upstream didn't send just keyframes (which is the ideal situation), two
different things can happen:
1) Either the subclass checks the segment flags and properly configures
the decoder implementation to only decode/output keyframes,
2) Or the subclass really decodes and outputs everything, in which case
the reverse frames will end up arriving "late" downstream (and will
be dropped). If upstream did properly send GOP in reverse order, we
still end up just showing keyframes (but at the overhead of decoding
everything).
https://bugzilla.gnome.org/show_bug.cgi?id=777094
When caps changes while streaming, the new caps was getting processed
immediately in videoaggregator, but the next buffer in the queue that
corresponds to this new caps was not necessarily being used immediately,
which resulted sometimes in using an old buffer with new caps. Of course
there used to be a separate buffer_vinfo for mapping the buffer with its
own caps, but in compositor the GstVideoConverter was still using wrong
info and resulted in invalid reads and corrupt output.
This approach here is more safe. We delay using the new caps
until we actually select the next buffer in the queue for use.
This way we also eliminate the need for buffer_vinfo, since the
pad->info is always in sync with the format of the selected buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=780682
Always put multiview-caps onto the output caps, assuming
mono if we've got no other information. It's still easy for
downstream elements to override using a capssetter or event
probe if desired.
https://bugzilla.gnome.org/show_bug.cgi?id=776172
When entering this code path, we know that:
We received EOS on this pad.
We consumed all its buffers.
In any case, we want to replace vaggpad->buffer with NULL,
otherwise we will end up mixing the same buffer twice.
https://bugzilla.gnome.org/show_bug.cgi?id=781037
The GSource for dealing with timeouts in
gst_video_convert_sample_async() might be attached to a non-default
context, so we should not be using g_source_remove() on the returned ID.
The correct thing to do is to keep a reference to the actual GSource and
then call g_source_destroy() on it.
https://bugzilla.gnome.org/show_bug.cgi?id=780297
Track how long it takes to generate the first buffer after a flush
as a simple measure of how efficient the decoder is at skipping /
rushing to get to the first decode.
When initializing a timecode from a GDateTime, and the remaining time
until the new second is less than half a frame (according to the given
frame rate), it would lead to the creation of an invalid timecode, e.g.
00:00:00:25 (at 25 fps) instead of 00:00:01:00. Fixed.
https://bugzilla.gnome.org/show_bug.cgi?id=779866
