Adding new subtitle overlay element. It's a bin which is wrapping
two internal elements dwritesubtitlemux and dwritetextoverlay.
* dwritesubtitlemux: A new internal element to aggregate subtitle
buffers and to attach the aggregated subtitle buffers on
video buffer as meta.
* dwritetextoverlay: Extracts/renders the subtitle meta and
discard the meta after rendering.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4934>
In the current implementation, we support for most pixel format left
and top padding by changing the offset in the video meta. Though, to
align driver bytesused to the offset, we recalculate the offset, which
removed the modification we did before.
Instead, save the plane size, and truncate the driver reported bytesused
to the expected size, which ensures that the offsets still match. This
should also fix issues were the buffer size ended up bigger then the
pool size due to driver introduced padding.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4920>
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>
Fixes test: validate.uridecodebin.expose_raw_pad_caps
testsrcbin (currently part of debugutilsbad) is an useful element for
validate tests.
validate.uridecodebin.expose_raw_pad_caps makes use of it.
Unfortunately, because validate tests with GStreamer only run with
whitelisted plugins and `debugutilsbad` wasn't in the whitelist, the
test was failing and being auto-skipped.
This patch adds debugutilsbad to the whitelists used by validate tests
in subprojects with a validate/meson.build.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4931>
The current way of using gst_video_info_set_format() will change all
fields of the GstVideoInfo. We only need to change its format, stride
and offset fields.
In order to keep the consistency with th common drm API, we rename the
gst_va_video_info_from_dma_info() into gst_va_dma_drm_info_to_video_info().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4883>
The current way only selects the best video format from the first
structure of the caps. The caps like:
video/x-raw(memory:VAMemory),drm-format=(string)NV12; \
video/x-raw(memory:VAMemory),format=(string){ NV12, Y210 }
Will just choose NV12 as the result, even the bitstream is 10 bits.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4928>
ges-timeline-element property getter handler was using
g_value_take_object() with internal pointers of the element as
arguments, instead of g_value_set_object().
g_value_take_object() moves the ownership of the reference; hence,
when reading "timeline" the reference ownership of timeline is moved
away from the ges-timeline-element and into the GValue.
Since GValues are temporaries that are often discarded quickly after,
this can easily lead to a double free. This was causing
gst-editing-services / pythontests to crash when running
TestTrackElements.test_ungroup_regroup() because of an innocent read of
`clip2.props.timeline` around the end of the test.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4924>
Some NLE tests were calling ges_init() from the test suite
initialization function. This was causing them to deadlock when running
with glib 2.76.3.
ges_init() causes a GThreadPool to be initialized. Even if GES at this
point doesn't request any thread to be created, since glib 2.63.4+
(see 8aeca4fa64)
the first time a GThreadPool is initialized a "pool-spawner" thread is
created, which is later used by g_thread_pool_push().
The default behavior of the GStreamer check tests is to fork for every
test case. This is not safe if any thread has been created at this
point. In this particular case, GThreadPool preserves the state that
says a "pool-spawner" thread has been created, and will have access to
its mutex and condition variable, but their queues will have different
contents as the memory has been forked. In consequence, calls to
g_thread_pool_push() will deadlock.
The deadlock will not occur if running the tests with CK_FORK=no.
This patch modifies the affected tests to only call ges_init() from
inside the test cases, fixing the deadlock.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4915>
A significant portion of the NLE test suite was often timing out due to
the tests taking way longer than necessary because the sinks were
synchronizing to the clock, which is the default behavior for
fakevideosink and fakeaudiosink.
Notable was the case of nleoperation.c:test_pyramid_operations, that ran
through a 10 second stream twice. As the default timeout is 20 seconds,
this made the test flaky.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4914>
Refusing an incoming segment in < GST_MATROSKA_READ_STATE_DATA should only be
done if the incoming segment is not in GST_FORMAT_TIME.
In GST_FORMAT_TIME, we are just storing the values and returning, so we can
invert the order of the checks.
Fixes proper segment propagation in matroska/webm DASH use-cases
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3914>
Is a seek is done on stream-collection post, there are no selected streams
yet. Therefore none would be chosen to adjust the key-unit seek.
If no streams are selected, fallback to a default stream (i.e. one which has
track(s) with GST_STREAM_FLAG_SELECT).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3914>
When seeking is handled by the collection posting thread, there is a possibility
that some leftover data will be pushed by the stream thread.
Properly detect and reject those early segments (and buffers) by comparing it to
the main segment seqnum
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3914>