If there's no known value in the best caps then the functions to convert
them to strings will return NULL. Having the fields not in the caps is
not a problem, having them with a NULL value however will cause
negotiation failures.
In prepare_frame, it is not enough for the target info
(conversion_info) to not have changed to decide not to update
the converter, as the vpad info may have changed as well.
Fixes#714
This marker is optional, its name refer to RTP marker bit. This mark can
be use to reduce latency in various use cases. With the split between
finish_frame() and finish_subframe() we will now be able to identitfy
the last subframe with no latency.
In order to detail the use of GST_BUFFER_FLAG_MARKER in a video
use case, the flag GST_VIDEO_BUFFER_FLAG_MARKER has been introduced
with a proper documentation clarifying marker's role.
Introduce a new API so encoders can split the encoding in subframes.
This can be useful to reduce the overall latency as we no longer need to
wait for the full frame to be encoded to start decoding or sending it.
The matrices were in the wrong order.
Instead of the conversion matrix being
_ XYZ_TO_RGB_output * RGB_TO_XYZ_input * input_RGB
It was
_ RGB_TO_XYZ_input * XYZ_TO_RGB_output * input_RGB
I'm going to use this new API in gst-omx so an encoder can request
v4l2src to produce buffers matching the encoder stride and slice heights
preventing copies of incoming buffers.
Especially for interlaced input make sure to
a) never mix both fields
b) never read lines after the end of the input frame
c) allocate enough space in the temporary lines to not write outside
the allocated memory area
This fixes various memory corruptions and rescaling artefacts.
At the moment, we only posted QoS messages when frame_drop() was
called, but not in finish_frame() when QoS triggered a late push.
This should fix applications that tries to account the dropped
frames. We also emit a warning on drops so it's more clear what is
happening.
By adding this field, buffer producers can now explicitly set the exact
geometry of planes, allowing users to easily know the padded size and
height of each plane.
GstVideoMeta is always heap allocated by GStreamer itself so we can
safely extend it.
When using gst_video_info_align() user had no easy way to retrieve the
padded size and height of each plane.
This can easily be implemented in fill_planes() as it's already called
in align() with the padded height.
Ideally we'd add a plane_size field to GstVideoInfo but the remaining
padding is too small so that would be an ABI break.
Fix#618
We want to round up when halfing height.
I do have a test for this but it relies on my new video-align tests so
it's part of the next commit. Recording the fix separately if we want to
backport this fix to the stable branch.
We need to provide twice as many lines as usual to the scaling function
as every second lines would be skipped.
Without this we read from random memory and produce colorful output and
crashes.
Without this, scaling e.g. interlaced UYVY causes corrupted output with
lines as follows: f1 f1 f2 f2, i.e. two lines of each field and only
then the other field.
* Fix typo
s/nunormalized/normalized/g
* Update GstVideoMasteringDisplayInfo description
Each values are not array.
* Add missing newline between arguments description and
detailed comment.
The caps and thus the video info have preference. If the field order is
set in there then it applies to all frames.
This works around issues where the tff field order is only set in the
caps but not additionally in the buffer flags.
... and also as known as ITU-T H.273.
The conversion has been handled per plugin for now. That causes
code duplication a lot also some plugins might not be updated with newly introduced
color{matrix,transfer,primaries} enum value(s).
Instead of handling it per plugin, centralized handling can remove such
code duplication and make plugins be up-to-dated.
The "field-order" is related for all interlace_mode modes except the
"progressive" mode. So instead of or'ing each mode we can use the
already supported GST_VIDEO_INFO_IS_INTERLACED macro.
gst_meta_api_type_register() assumes that the last tags element is null, but it wasn't
==17422==ERROR: AddressSanitizer: global-buffer-overflow on address 0x7f4e2a67c998 at pc 0x7f4e2a0c92ac bp 0x7ffcc41f80b0 sp 0x7ffcc41f80a0
READ of size 8 at 0x7f4e2a67c998 thread T0
#0 0x7f4e2a0c92ab in gst_meta_api_type_register ../subprojects/gstreamer/gst/gstmeta.c:94
#1 0x7f4e2a5582c3 in gst_video_afd_meta_api_get_type ../subprojects/gst-plugins-base/gst-libs/gst/video/video-anc.c:1146
#2 0x404c7c in invoke_get_type (/home/ubuntu/gst-build/build/tmp-introspect5gv1rovo/GstVideo-1.0+0x404c7c)
#3 0x406b5c in dump_irepository (/home/ubuntu/gst-build/build/tmp-introspect5gv1rovo/GstVideo-1.0+0x406b5c)
#4 0x407089 in main (/home/ubuntu/gst-build/build/tmp-introspect5gv1rovo/GstVideo-1.0+0x407089)
#5 0x7f4e295b4b6a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x26b6a)
#6 0x404479 in _start (/home/ubuntu/gst-build/build/tmp-introspect5gv1rovo/GstVideo-1.0+0x404479)
0x7f4e2a67c998 is located 40 bytes to the left of global variable 'tags' defined in '../subprojects/gst-plugins-base/gst-libs/gst/video/video-anc.c:1232:25' (0x7f4e2a67c9c0) of size 24
0x7f4e2a67c998 is located 0 bytes to the right of global variable 'tags' defined in '../subprojects/gst-plugins-base/gst-libs/gst/video/video-anc.c:1141:25' (0x7f4e2a67c980) of size 24
SUMMARY: AddressSanitizer: global-buffer-overflow ../subprojects/gstreamer/gst/gstmeta.c:94 in gst_meta_api_type_register
Since we started depending on GLib 2.44, we can be sure this macro is
defined (it will be a no-op on compilers that don't support it). For
plugins we should just start using `G_DECLARE_FINAL_TYPE` which means we
no longer need the macro there, but for most types in base/gst-libs we
don't want to break ABI, which means it's better to just keep it like it
is (and use the `#ifdef` instead).
The problem is that Gobject Introspections does not understand the const
gfloat matrix[16] as an matrix but as an array of gfloasts but as just
one gfloat.
To fix this i added the annotation to the parameter
descriptions.
This came up in the case where v4l2 sets caps with colorimetry=NULL, and
then tries to parse back the colorimetry, causing a crash in
gst_video_get_colorimetry() because of g_str_equal(). We fix this by
making sure the only caller of the function never calls it with a null
colorimetry string.
SMPTE ST 2084 transfer characteristics (a.k.a ITU-R BT.2100-1 perceptual quantization, PQ)
is used for various HDR standard.
With ST 2084, we can represent BT 2100 (Rec. 2100). BT 2100 defines
various aspect of HDR such as resolution, transfer functions, matrix, primaries
and etc. It uses BT2020 color space (primaries and matrix) with PQ or HLG
transfer functions.
Packed 10 bits per each R, G and B channel with MSB 2bits alpha channel.
This format is mapped to Windows' DXGI_FORMAT_R10G10B10A2_UNORM format which is
required for 10bits HDR rendering.
Note that this RGB10A2_LE format is R - B channel swapped version of BGR10A2_LE
... if subclass didn't update values. Note that the mastering-display-info
and content-light-level might be updated by user defined value (e.g., encoding option).
Introduce HDR signalling methods
* GstVideoMasteringDisplayInfo: Representing display color volume info.
Defined by SMPTE ST 2086
* GstVideoContentLightLevel: Representing content light level specified in
CEA-861.3, Appendix A.
Closes https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/400
video-anc.h💯 Error: GstVideo: identifier not found on the first line:
* Active Format Description (AFD) support
^
video-anc.h:207: Error: GstVideo: identifier not found on the first line:
* Bar data support
^
video-anc.h:228: Warning: GstVideo: "@top_bar_flag" parameter unexpected at this location:
* @top_bar_flag : flag indicating presence of top bar field
^
This is inconsistent with other add_meta methods such as
gst_buffer_add_video_meta , which will return NULL without
logging when gst_video_info_set_format fails.
It is up to the caller to check the return value of the
function, and log if appropriate.
It's invalid to have a 'interlace-mode=alternate' without the Interlaced caps
feature as well.
Modify gst_video_info_from_caps() to reject such case so we can easily
spot them in bugged elements.
The ->skip_buffer implementation in videoaggregator replicates
the behaviour of the aggregate method to determine whether a
buffer can be skipped
(https://bugzilla.gnome.org/show_bug.cgi?id=781928).
This fixes a typo that made it so the start time of the buffer
was calculated against the output segment, not the segment of
the relevant sinkpad, which caused buffers to be skipped when
for example a sinkpad had received a segment which base had
been modified by a pad offset somewhere along the way.
This simply makes the calculation of the buffer start time
identical to the calculation in aggregate()
gst_video_decoder_negotiate_default_caps() is meant to pick a default output
format when we need one earlier because of an incoming GAP.
It tries to use the input caps as a base if available and fallback to a default
format (I420 1280x720@30) for the missing fields.
But the framerate and pixel-aspect were not explicitly passed to
gst_video_decoder_set_output_state() which is solely relying on the input format
as reference to get the framerate anx pixel-aspect-ratio.
So there is no need to manually handling those two fields as
gst_video_decoder_set_output_state() will already use the ones from
upstream if available, and they will be ignored anyway if there are not.
This also prevent confusing debugging output where we claim to use a
specific framerate while actually none was set.
The start_time and end_time in this context have already
been adjusted for the input's rate by converting them to running
time above. What is needed afterwards is to compare these
with the output's start/stop running time, which also takes
into account the rate, so we are comparing equal things.
Multiplying these with the output's rate here is only breaking
this logic. In most cases the input and output rate is the same,
so this multiplication effectively reverses the rate adjustment
that happened while converting to running time, which is why
we see the video playing with the original rate in tests.
Fixes#541
We make an allocator for temporary lines and then use this for all
the steps in the conversion that can do in-place processing.
Keep track of the number of lines each step needs and use this to
allocate the right number of lines.
Previously we would not always allocate enough lines and we would
end up with conversion errors as lines would be reused prematurely.
Fixes#350
It breaks all the calculations. While it can make sense during
initialization, there's very little API that can be called with such
timecodes without ending up with wrong results.
The old API would only assert or return an invalid timecode, the new API
returns a boolean or NULL. We can't change the existing API
unfortunately but can at least deprecate it.
CEA608_IN_CEA708_RAW is the same format as CEA708_RAW. It's only
difference is that it must contain only CEA608 and a format like this
does not exist in practice. In practice every element that handles raw
cc_data triplets must check each triplet for their actual content and
handle them accordingly.
For CC-only streams a parser could signal the existence of CEA608 and/or
CEA708 inside the caps but for metas this can only potentially be
signalled via the ALLOCATION query for negotiation purposes.
A separate format for this is not very useful and instead it should be a
format qualifier.
CEA608_S334_1A is the format defined by SMPTE S334-1 Annex A and which
is used for transferring CEA608 over SDI instead of CEA708 CDP packets.
Pull in video frame fields into local variables. Without this the
compiler must assume that they could've changed on every use and read
them from memory again.
This reduces the inner loop from 6 memory reads per pixels to 4, and the
number of writes stays at 3.
If we use the main loop it might happen that the caller (e.g. our unit
test) already shut down the loop once the result was received and in
that case the pipeline would never ever be shut down (and our unit test
would hang).
While this creates a circular reference between the pipeline and the
context, this ensures that the context stays alive for as long as any
callbacks could be called on it. The circular reference is broken once
the conversion is finished (or error, or timeout), which will then cause
everything to be freed.
Previously it was possible that a callback could be called on the
context right after it was freed already.
Also use only a single context structure, the second structure does not
simplify anything and duplicates storage.
The Y210 format was added in the middle of the formats enum and list,
introducing an ABI break.
This issue was detected thanks to the gstreamer-rs test harness.
We assume here the same data format for the user data as for the
DID/SDID: 10 bits with parity in the upper 2 bits. In theory some
standards could define this differently and even have full 10 bits of
user data but there does not seem to be a single such standard after
all these years.
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
