The source buffer currently has a thread for each track that feeds the track
with all data in the track buffer until EOS is reached.
Each pass over the track buffer currently waits for the EOS to appear when it's
done iterating the track buffer which is too restrictive.
When the source buffer reaches the end of the track buffer, it should wait for
any new data to be processed -- not just an EOS -- then check for cancellation
if the deadline expires without new data.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8512>
Both operations now work on coded frame groups (GOPs). This simplifies queueing
of video data. There is rarely any point of dealing with individual video frames
when iterating in DTS order, it's most meaningful to decode or delete whole
coded frame groups at a time, so the sample map will now do that when iterating
by DTS. When iterating in PTS order, the existing behavior is preserved since
that is used for informational purposes, not media processing.
A new private boxed type for coded frame groups was added to provide each data
item to the source buffer. Another possible solution would be creation of a new
GstSample representing the whole group by merging all the samples in a group
into a single sample containing a GstBufferList.
Also, start time filtering was removed from the API since gst_iterator_filter()
can be used by callers to achieve the same result.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8512>
h265parser defers linking parameter sets until slice header is parsed.
Thus valid SPS/PPS parsed by h265parser can have no linked
parent parameter set. Apply this behavior to
gst_h265_parser_update_{sps,pps} too
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8673>
When dynamic caps change in the pipeline leads to a new buffer pool
getting negotiated, the change is not propagated to Qt6GLWindow, which
keeps using the old, now defunct, pool.
Unset current pool on Qt6GLWindow in decide_allocation(). This will
trigger a switch to the new pool inside create().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8676>
gst_video_time_code_to_date_time() simply calculated the date time based on
adding the hours/minutes/seconds to the daily jam. This causes a gap every full
minute (except for every 10th minute) with drop-frame timecodes as the first 2
(29.97fps) or 4 (59.94fps) timecodes are skipped (not frames!), e.g. with
29.97fps:
timecode: 12:00:59;28 12:00:59;29 12:01:00;02 12:01:00;03
time : 12:00:59.950 12:00:59.983 12:01:00.017 12:01:00.050
and not
time : 12:00:59.934 12:00:59.968 12:01:00.067 12:01:00.100
|-- gap of 2 frames --|
The correct calculation would be to use gst_video_time_code_nsec_since_daily_jam()
and add that to the daily jam.
Also add a test for this.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8649>
Fixes an issue where the webrtcbin would hangup when finalizing due
to the sctpenc hanging up when finalizing. This occurred when the
webrtcbin chose to use a sctp association ID already in use.
The sctpenc would fail to reach the paused state, but startup a task
anyways that was never stopped.
This commit modifies the behavior to not choose sctp association IDs
randomly, and instead only choose one that is free. It also prevents the
sctpenc from starting up that task if it fails to reach the paused state.
Fixes: #4188
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8607>
On Windows, if the path to gst-plugin-scanner.exe contained
whitespace, gstreamer would via CreateProcessW attempt to execute
several files "up" the path tree; e.g. if the scanner path was
"C:\Program Files\gstreamer app\gst-plugin-scanner.exe", it would try
to execute C:\Program, C:\Program.exe, C:\Program Files\gstreamer.exe"
and so on.
This is how CreateProcessW behaves with unquoted whitespace arguments
in lpCommandLine if lpApplicationName is NULL.
By passing the binary path as lpApplicationName instead, the problem
is avoided.
Also quote arguments to gst-plugin-scanner.exe as they are paths as well.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8614>
PyGObject 3.52.0 moved OverridesProxyModule _introspection_module to __slots__,
causing Segmentation Faults when accessing the field.
Since _introspection_module is used to get Gst.Element but is never actually
used afterward, we fix the issue by removing this part.
Fixes#4314
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8653>
There are 3 32bit integers per entry and not one more for all but the last.
Fixes a regression introduced in 5a9e80c01b4b49c6c7630a6d08b600114f38c0db
when playing back files that have one sample table entry per audio sample.
Merging the sample tables would've always failed because of the too strict size
check and one audio sample per GStreamer buffer would've been output, which
doesn't perform very well.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8657>
They're not privileged so won't work anymore.
Using kvm tag for now as per discussion on IRC,
until a better solution comes along in future.
Keep placeholder-job tag on trigger job and
pre-commit checks jobs.
Add kvm tag to fluster job.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8677>
The GST_TRACER_POOL_BUFFER_(DE)QUEUED macros used when tracer hooks are
disabled took only one argument, causing compile errors when building
with tracer hooks disabled.
Change-Id: I0958c0b018f1fc4a6d84ab0bdd9e42895ae1fe77
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8638>
VT supports changing properties on the fly, and old code attempted to
support that. Perhaps 10 years ago that worked, but these days
VTSessionSetProperty will always wait for the output callback to finish
before proceeding. This means that it's very prone to deadlocking, as
property setters will take the object lock, the callback thread will
take the stream lock, and the main (streaming) thread attempts to take
both, resulting in a deadlock.
New version uses something similar to other encoders (e.g. x264enc) -
changing a property when a session is already created will just flag it
to be reconfigured upon the next encode call. This is done in similar
fashion to how restarting the session upon an error works.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8597>
v4l2object->ioctl can either be set to v4l2_ioctl() or ioctl().
v4l2_ioctl() always takes the request number as unsigned long int, but ioctl()
may take (at least) unsigned long int, int, or unsigned, depending on libc.
This means that there isn't one function pointer type that can be used for
v4l2object->ioctl that will always be able to accomodate being set to either of
v4l2_ioctl() and ioctl(). It's therefore necessary to wrap one of them so that
both options can have the same type. This fixes an assignment from incompatible
pointer type error when building for musl.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8613>
It's not used by anything in the monorepo, only used when
rebuilding the gstreamer-rs image (used by gst-plugins-rs
where the gtk4 plugin lives).
Doesn't make sense to build all of gtk4 on every CI run that
touches the relevant files just to make sure it still works
for the image rebuild, and it's a problem for users with long
filenames (such as `gstreamer-backport-bot`) where the pipeline
will simply not pass because the gtk glib-mkenums command line
length exceeds 32767 characters.
Better to set up a scheduled pipeline for that.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8636>
This reverts commit dcd11f0a104964f7fc02c38104ed57fd0aa794a2.
In dcd11f0a104964f7fc02c38104ed57fd0aa794a2 we started making use
of gitlab's changes:compare_to in hopes of addressing #3780
However compare_to seems to have different behavior based on:
* The type of the branch
* If the repo is a fork or not
* If the pipeline is a branch or MR pipeline
* If the commit is force pushed or not
* If the pipeline is associated with a "push" event,
* Manual and scheduled pipelines are not.
If we leave compare_to underfined and to its default value,
it causes issues with branch pipelines, as:
* If you push a new branch, it doesn't have anything to compare
against and changes: either will trigger or not, depending on the
gitlab version
* If you push to an existing branch, it only compares against the
previous commit.
* if you force push to a branch, it doesn't work at all it seems. [1]
Thankfully for merge request pipelines, it always seems to compare
against the Merge Request Target tree. But also if there is a Merge
Request open, and the value of compare_to isn't defined (say if it's a
force push or it's the first branch pipeline of the branch) it will
fallback to using the tree from the Merge Request Target, making it even
more confusing.
But if we try to overide it to fix the behavior for branches, we end up
breaking merge request. There seems to be a bug in gitlab (unclear if
its intended or not) where if you have access to the upstream
repository, gitlab will compaee_to against that in the MR pipeleine, but
otherwise it will try to compare against your fork's branch which will
certainly be outdated. Additionally it didn't seem to error out if the
branch specified doesn't exist only in one of the two places so its very
hard to reverse engineer the behavior.
[1] https://gitlab.com/gitlab-org/gitlab/-/issues/349694
Long story short, this is way more complicated than its worth, and has
caused a lot of issues since it was introduced. Revert the change and
try again another time.
Related https://gitlab.com/gitlab-org/gitlab/-/issues/389808Close#3965
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8563>
`parsebin` is potentially added by a `typefind` callback.
That `typefind` was activated by a `READY_TO_PAUSED` state change on `urisourcebin`
We want to ensure that it is the "setup_parsebin_for_slot" method that activates
the underlying `parsebin`, and not the external state-change.
Otherwise we would risk a potential deadlock where elements activating in
`parsebin`, and which would cause the upstream `typefind` to switch scheduling
mode, would not be able to acquire the STREAM_LOCK of the `typefind` task.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/4225
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8511>
