Align the calculations for the number of samples per block with the
calculations in adpcmdec.
For MS ADPCM we have in adpcmdec:
samples = (blocksize - 7 * dec->channels) * 2 + 2 * dec->channels;
outsize = 2 * samples;
outbuf = gst_buffer_new_and_alloc (outsize);
This gives us the total output byte size in 16 bits samples. To get back
to the samples, dividing by the channels and 2, we get the right samples per
block as:
int spb = ((strf->blockalign / strf->channels) - 7) * 2 + 2;
Which we can then use to calculate the bitrate in riff-media.
A similar calculation for DVI ADPCM is needed to get the right bitrate
in all cases.
Tested with the sample in https://bugzilla.gnome.org/show_bug.cgi?id=636245
and another (failing before this patch) sample.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9082>
At the moment we are always accepting the input events to forward into
GStreamer infrastructure. This works but we might have other uses for
such events elsewhere in the QtQuick scene so allow opting out to this
behaviour.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9085>
After gst-validate-1.0 notices the first expected error on the bus, it will
queue the completion of that action while the pipeline is still processing the
error and getting to the basesrc for the second error.
Mark the second error as 'sometimes=true', as it's not critical to the test.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9060>
There is a small window during stopping when tasks have been add
to the transfer_requests queue, but never transfered to the
active_transfers array and causes the fallowing error:
GTask 0x7f2c4400e930 (source object: (nil), source tag: (nil)) finalized
without ever returning (using g_task_return_*()).
This potentially indicates a bug in the program.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9060>
- Unset stream ids if a collection does not contain them
- Automatically select a default stream of a type if the stream type is
enabled but no stream is selected yet when receiving the stream collection
- Warn if there's a collection update via streams-selected and if there are
unexpected streams being selected, or actually selected streams not being
found
- Improve debug output a bit
Among other things this also makes sure that we don't forget a selected stream
id when disabling a track so that when enabling it again later the same one can
be enabled again.
See https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/4344
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9081>
The part of the code that is commented with:
```
/* gst_validate_action_set_done() does not finish the action
* immediately. Instead, it posts a task to the main thread to do most
* of the work in _action_set_done().
*
* While the EOS handling lock guarantees that if an action had to call
* gst_validate_action_set_done() it has done so, it does not guarantee
* that _action_set_done() has been called.
*
* Is it possible that this handler is run before _action_set_done(), so
* we check at this point for actions that have a pending_set_done and
* call it before continuing. */
```
was not being executed in the case where the scenario was 'ignoring EOS'
while it was also required.
Also fix potential use after free in that specific code path.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9014>
Now that we have the monorepo, we always have a checkout
of gstreamer and we don't need to explicitly clone it again.
cbuild in ci-templates will always clone the repository in
/tmp/clone and we can use that to initialize the cache.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8994>
In the rare case when we get EOS on all pads before we get any buffer we
would finish the file without writing headers, i.e. the file would be
corrupt. This patch makes sure that a header is always written.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9061>
The build files had quite a few things wrong:
* Not using the method: kwarg, which can cause the wrong Qt to be
used for building
* There was no way to enable the build for them
* Qt was being detected multiple times, differently
* Unnecessary check for libGL
* have_cxx was being used incorrectly
* Qt tool detection was outdated
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9046>
