A payload of 0x80 0x80 means that it's padding. It's not a good idea to
throw this away though, because of the cc_valid field.
According to CEA 10-B section 25.2.1, if cc_valid is zero, the run-in
clock and start bit should not be generated. In practice, this means
that any closed captions will be erased and the end-user TV will show
that captions are not available for this stream. This might have
undesired consequences, e.g. we were just showing a long line of
captions and we disable it before the user has had time to read it, or
you can't enable closed captions during silence/music intervals.
We cannot reliably detect whether there's a currently-silent closed
caption stream or just nothing, but we have this information coming from
upstream, so we can at least not discard it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5508>
This pair of elements, inspired from shmsink/shmsrc, send unix file
descriptors (e.g. memfd, dmabuf) from one sink to multiple source
elements in other processes.
The unixfdsink proposes a memfd/shm allocator, which causes for example
videotestsrc to write directly into memories that can be transfered to
other processes without copying.
Sponsored-by: Netflix Inc.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5328>
Sending an EOS event is actually really bad because rtpbin doesn't
handle that very well. It was only being used as a way to notify
webrtcbin to check if re-negotiation is needed.
We don't need that anymore, since changing the direction is enough to
notify webrtcbin to check for re-negotiation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5045>
There's no reason to release GstMemory manually at all.
If we do release GstMemory, corresponding GstBuffer will be
discarded by GstBufferPool baseclass because the size is changed
to zero.
Actual cause of heavy CPU usage in case of fixed-size pool
(i.e., decoder output buffer pool) and if we remove GstMemory from
GstBuffer is that GstBufferPool baseclass is doing busy wait in acquire_buffer()
for some reason. That needs to be investigated though, discarding
and re-alloc every GstBuffer is not ideal already.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4935>
Adding Direct3D11 backend Qt6 QML videosink element, qml6d3d11sink.
Implementation details are similar to the qt6 plugin in -good
but there are a few notable differences.
* qml6d3d11sink accepts all GstD3D11 supported video formats (e.g., NV12).
* Scene graph (owned by qml6d3d11sink) will hold dedicated and sharable
RGBA texture which belongs to Qt6's Direct3D11 device, instead of sharing
GStreamer's own texture with Qt6.
* All rendering operations will be done by using GStreamer's Direct3D11 device.
Specifically, upstream texture will be copied (in case of RGBA)
or converted to the above mentioned Qt6's sharable texture.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3707>
Allow a project to use gstreamer-full as a static library
and link to create a binary without dependencies.
Introduce the option 'gst-full-target-type' to
select the build type, dynamic(default) or static.
In gstreamer-full/static build configuration gstreamer (gst.c)
needs the symbol gst_init_static_plugins which is defined
in gstreamer-full.
All the tests and examples are linking with gstreamer but the
symbol gst_init_static_plugins is only defined in the gstreamer-full
library. gstreamer-full can not be built first as it needs to know what plugins
will be built.
One option would be to build all the examples and tests after
gstreamer-full as the tools.
Disable tools build in subprojects too as it will be built at the end of
build process.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4128>
Depending on the exact output format, 0x00 may be a better default for
padding than 0x80. 0x00 is the recommended padding value when used in
CDP (and cc_data) but is not when used in s334-1a. See CTA-708-E 4.3.5
amd SMPTE 334-1-2007 5.3.2.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4578>
On MacOS with homebrew, the openssl library is not
properly detected with pkg-config.
So disable the test compilation if openssl
is not properly detected along with libcrypto.
libcrypto is detected but it uses the system one
which leads to the error:
your binary is not an allowed client of /usr/lib/libcrypto.dylib for
architecture x86_64
See more details from Apple:
https://developer.apple.com/forums/thread/124782
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4481>
Similar to cairooverlay element but this element emits "draw"
signal with Direct3D11 render target view, so that an application
can render/overlay/blend on the given render target view
without any copy operation
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4415>
Running tests with Vulkan Validation enabled show an error on vkimage tests:
Code 0 : Validation Error: [ VUID-VkImageViewCreateInfo-image-04441 ]
Object 0: VK_NULL_HANDLE, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle
= 0x50000000005, type = VK_OBJECT_TYPE_IMAGE;
| MessageID = 0xb75da543
| Invalid usage flag for VkImage 0x50000000005[] used by vkCreateImageView(). In
this case, VkImage should have VK_IMAGE_USAGE_SAMPLED_BIT |
VK_IMAGE_USAGE_STORAGE_BIT | VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT |
VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT |
VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT | VK_IMAGE_USAGE_INPUT_ATTACHMENT_BIT |
VK_IMAGE_USAGE_FRAGMENT_SHADING_RATE_ATTACHMENT_BIT_KHR |
VK_IMAGE_USAGE_FRAGMENT_DENSITY_MAP_BIT_EXT |
VK_IMAGE_USAGE_VIDEO_DECODE_DST_BIT_KHR |
VK_IMAGE_USAGE_VIDEO_DECODE_DPB_BIT_KHR |
VK_IMAGE_USAGE_VIDEO_ENCODE_SRC_BIT_KHR |
VK_IMAGE_USAGE_VIDEO_ENCODE_DPB_BIT_KHR | VK_IMAGE_USAGE_SAMPLE_WEIGHT_BIT_QCOM
| VK_IMAGE_USAGE_SAMPLE_BLOCK_MATCH_BIT_QCOM set during creation.
The Vulkan spec states: image must have been created with a usage value
containing at least one of the usages defined in the valid image usage list for
image views
This patch adds VK_IMAGE_USAGE_SAMPLED_BIT to the usage bits in test.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4296>
H.265 NAL always have 2 bytes of headers. Unlike the H.264 parser, this parser
will simply return that there is NO_NAL if some of these bytes are missing.
This is then properly special cased by parsers and decoders. Add a test to
ensure we don't break this in the future.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3234>
The appropriate return value for incomplete NAL header should be
GST_H264_PARSER_NO_NAL_END. This tells the parser element to
gather more data. Previously, it would assume the NAL is corrupted
and would drop the data, potentially causing stream corruption.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3234>
As specified in EIA/CEA-608-B section 8.4:
When closed captioning is used on line 21, field 2, it shall conform
to all of the applicable specifications and recommended practices as
defined for field 1 services with the following differences:
a) The non-printing character of the miscellaneous control-character pairs
that fall in the range of 14h, 20h to 14h, 2Fh in field 1, shall be replaced
with 15h, 20h to 15h, 2Fh when used in field 2.
b) The non-printing character of the miscellaneous control-character pairs
that fall in the range of 1Ch, 20h to 1Ch, 2Fh in field 1, shall be replaced
with 1Dh, 20h to 1Dh, 2Fh when used in field 2.
This means simply switching the "field" field in the caps isn't enough for
converting raw 608 from one field to another, some control codes also
need to be amended.
+ Adds simple test
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4126>
The previous implementation was a bit primitive, assuming the subclass
had registered a template name starting with sink_ . Instead make
the effort of parsing the actual template name, and use that to generate
the final pad name.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4032>
Raw 608 caps can now contain a "field" field. On the input side it
signifies that the input raw 608 is attached to either field 0 or 1,
on the output side it allows selecting whether to extract the raw 608
data for field 0 or 1 for field-aware formats.
In addition, it is also allowed to use ccconverter to "convert" 608
field 0 to 608 field 1 (and conversely), this is passthrough as the
change only needs to happen in the caps.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4031>
