When using deeply nested timelines with the `ges:` protocol the
formatters ends up trying to do discovery from the same thread current
discovery happens, leading to infinite freeze as GstDiscoverer can't run
several discoveries at the same time.
By ensuring that when calling `gst_discoverer_discover_uri_async` no
`GstDiscoverer` is set as "thread discoverer" we know that another
discoverer will be created if discovery recurses, effectively removing
the freeze.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5608>
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>
When decoding stream using hardware V4L2 decoder element, in any of the
currently supported formats, the decoding will fail once frame number
1000000 is reached. The reported error clearly indicates a wrap-around
occured, instead of receiving decoded frame 1000000, frame 0 is received
from the hardware V4L2 decoder driver.
The problem is actually not in the driver itself, but rather in gstreamer,
which uses `struct v4l2_buffer` member `.timestamp` in a special way. The
timestamp of buffers with encoded data added to the SINK (input) queue of
the driver is copied by the driver into matching buffers with decoded data
added to the SOURCE (output) queue of the driver. In fact, the timestamp
is not a timestamp at all, but rather in this special case, only part of
it is used as an incrementing frame counter.
The `.timestamp` is of type `struct timeval`, which is defined in
`sys/time.h` [1]. Only the `tv_usec` member of this structure is used
for the incrementing frame counter. However, suseconds_t tv_usec [2]
may be limited to range [-1, 1000000]:
"
[XSI] The type suseconds_t shall be a signed integer type capable of
storing values at least in the range [-1, 1000000].
"
Therefore, once frame 1000000 is reached, a rollover occurs and decoding
fails.
Fix this by using both `struct timeval` members, `.tv_sec` and `.tv_usec`
with matching modular arithmetic, this way the failure would occur again
just short of 2^84 frames, which should be plenty.
[1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_time.h.html
[2] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html
A test case using stateless hardware h264 decoder, the WARN/ERROR output
in gstreamer log indicates a failure occurred. With this change, that
error no longer occurs and the WARN/ERROR are not present:
```
pc$ gst-launch-1.0 videotestsrc num-buffers=1001001 pattern=6 ! \
video/x-raw,width=16,height=16,format=I420 ! \
x264enc ! filesink location=/tmp/test.h264
dut$ GST_DEBUG="*:3" gst-launch-1.0 filesrc location=/tmp/test.h264 ! \
h264parse ! v4l2slh264dec ! fakesink
...
0:03:51.393677606 12111 0x370df400 WARN \
v4l2codecs-decoder gstv4l2decoder.c:1157:gst_v4l2_request_set_done:<v4l2decoder2> \
Requested frame 1000000, but driver returned frame 0.
0:03:51.394140597 12111 0x370df400 WARN \
v4l2codecs-decoder gstv4l2decoder.c:1157:gst_v4l2_request_set_done:<v4l2decoder2> \
Requested frame 1000001, but driver returned frame 1.
0:03:51.394425216 12111 0x370df400 WARN \
v4l2codecs-decoder gstv4l2decoder.c:1157:gst_v4l2_request_set_done:<v4l2decoder2> \
Requested frame 1000002, but driver returned frame 2.
0:03:51.394665211 12111 0x370df400 WARN \
v4l2codecs-decoder gstv4l2decoder.c:1157:gst_v4l2_request_set_done:<v4l2decoder2> \
Requested frame 1000003, but driver returned frame 3.
0:03:51.394785833 12111 0x370df400 WARN \
v4l2codecs-h264dec gstv4l2codech264dec.c:1059:gst_v4l2_codec_h264_dec_output_picture:<v4l2slh264dec0> \
error: Failed to decode frame 1000000
ERROR: from element /GstPipeline:pipeline0/v4l2slh264dec:v4l2slh264dec0: Failed to decode frame 1000000
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5598>
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>
There is no guarantee that g_get_user_runtime_dir() is in a tmpfs. Using
an explicit shared memory API seems safer for all POSIX platforms.
Note that Android does not have shm_open() and only added memfd_create()
since API level 30 (Android 11).
Sponsored-by: Netflix Inc.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5328>
Detail a bit the intention behind GST_ALLOCATOR_FLAG_CUSTOM_ALLOC, even
if implementation does not currently fully follow that usage. Introduce
a new flag specifically for copying memories using the default system
allocator.
Sponsored-by: Netflix Inc.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5328>
The src caps of the libde265 is now fixed to I420, and so if the
stream is other format, such as 4:4:4 or 10 bits format, the pipeline
will crash because the dowstream element accesses the video buffer as
I420 format.
We now restrain the input caps to "main" profile, which only contains
4:2:0 8 bits stream.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5573>
While the minimum timeout duration is 5s, checking only every 5s means
that we would notice this 4.9s too late in the worst case.
Checking once a second reduces this considerably while keeping the
number of wakeups still low.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5520>
Otherwise it can happen that we regularly switch back and forth between
clocks under certain circumstances for no good reason.
Also remove redundant comparison when comparing the steps removed between two
clocks.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5520>
This can happen with the dummy "noopenh264" library that the freedesktop
flatpak runtime ships, and Fedora is planning on shipping as well. In
both cases the dummy implementation gets replaced with the actual
openh264 library that's downloaded directly from Cisco, but just to be
on safe side, this patch makes it careful to check the return values to
avoid crashing if the underlying library hasn't been swapped out yet.
The patch is taken from freedesktop-sdk and was originally written by
Valentin David <valentin.david@codethink.co.uk>.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5581>
- Fixes a crash in tutorial 5, which happened when going back from video playback to the 'library' view, due to
ui_delegate already being destroyed at that point.
- Updates layouts to avoid navigation bar overlapping play/pause buttons. Colours are now correctly updated
based on light/dark mode being enabled, overall look and feel is improved with bigger buttons and paddings.
New button types are used, so target version is now iOS 15.0.
- Disables debug log coloring, as the default terminal in XCode does not render that anyway, so logs are now
more readable there.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5473>
The local glib subproject doesn't exist so the glib/glib.supp file
cannot be included.
As it is needed for the do_lookup_by_name() function call, let's add the
system wide suppression file so that its version matches the installed glib
version.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5434>
If users update geometry related properties very frequently
for a stream to be animated, redrawing on every update
can make rendering choppy or can be a performance bottleneck.
To address the issue, adding a property to control the behavior
of redrawing scene when geometry related properties are updated.
Also, do not resize swapchain on such property update, since
re-allocating backbuffer and multi-sampled render target is
unnecessary in that case.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5575>
Other Windows applications allow window switching even when
an application window is in fullscreen mode. Also fixing
regression introduced in 15248d8b84
which makes restored window is always located at topmost
since we do not call SetWindowPos() anymore when restoring
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5574>
ISimpleAudioVolume controls volume of corresponding audio session
and there would be only single input/output audio session
in case of share-mode, which means that it controls audio volume of the
process. Instead, use IAudioStreamVolume interface which controls
volume of the stream.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5549>
Ignore alpha component of source (mouse cursor texture)
when blending alpha channel, otherwise the background area of source
(which has zeros) will be written to render target. Then it will result
in black rectangle if output texture is converted to premultiplied alpha
texture
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5566>
In snapshot mode pngenc should output exactly one frame
and then return FLOW_EOS to upstream. If upstream sends
more input frames before shutting down, it should keep
returning FLOW_EOS but not output any more encoded frames.
After a flushing seek it should output frames again though.
Fixes#3069.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5546>
It's a bad idea trying to mix the Options from GStramer and
GTK, in addition with cli argument being a bit wonky thing for
GUI applications in general. In the rare, now, occasion
that an application wants to parse arguments, its preferable
to parse them manually and use library apis afterwards
rather than trying to combine the option groups and hope it
works.
In addition, applications should be opening files using
`g_application_open` instead of parsing random arguments.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4788>
When hotdoc documentation is enabled and opencv plugin is set as
auto-detected, but the library isn't installed, meson configuration fails
with this message:
../subprojects/gst-plugins-bad/docs/meson.build:139:21: ERROR: Unknown variable "gstopencv_dep".
This patch fixes this case defined gstopencv_dep as disabler() when
dependencies aren't found.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5560>
Current codes try derive image in _update_image_info first, if
derive returns no error, the va_allocator->info is the one from derived
image, but in va_map_unlocked, we disable derive manner for d3d backend
because it doesn't seem to work, this will cause issue for d3d path,
i.e. possibly using derived info in va_get_image to do mapping...
This patch disables derive image for d3d backend in _update_image_info,
to ensure we only use info from va_create_image for d3d path.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5495>
An operation is an arbitrary amount of work to be executed on the host, a
device, or an external entity such as a presentation engine.
The purpose of this object is to help on the operation's synchronization
through declaring explicit execution dependencies, and memory dependencies
between two sets of operations defined by the command’s two synchronization
scopes.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5079>
While VkPipelineStageFlags is an enum (arguably backed as uint32 in 32bit
platforms), VkPipelineStageFlags2 is a redefinition of guint64; likewise for
VkAccessFlags and VkAccessFlags2.
This patch types both members in GstVulkanBarrierMemoryInfo as guint64 for
compatibility, so it could be used with or without synchronization2 vulkan
extension.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5079>
