False positive for the three variables but some warnings like:
../tests/check/elements/matroskamux.c:875:10:
warning: 'chapters_offset' may be used uninitialized in this function [-Wmaybe-uninitialized]
*index = chapters_offset;
~~~~~~~^~~~~~~~~~~~~~~~~
The above is false positive as there is a gboolean to check if it was
initialized or not (found_chapters_declaration).
This reverts commit dcd3ce9751.
This functionality was implemented for gstopenwebrtc, but it
turned out this was not actually needed for webrtc bundling
support, as shown in webrtcbin. It also doesn't correspond
to any standards.
This is an API break, but nothing should actually depend on
this, at least not for its initial purpose.
Changes in rtpbin.c were reverted manually, to preserve some
refactoring that had occurred in the original commit.
Fixes#537
Bus message handler of tags checking unit test uses gst_message_parse_error()
in case of GST_MESSAGE_ERROR and GST_MESAGE_WARNING.
If gst_message_parse_error() is called in case of GST_MESSAGE_WARNING, assert occurs.
So modified to use gst_message_parse_warning() in case of GST_MESSAGE_WARNING.
Allow run some unit tests on Windows.
* Remove hardcoded path separator in whitelist env for Meson to choose
OS-specific separator automatically (i.e., ';' for windows and ':' for *nix)
* Add dependency explicitly for some test cases, otherwise plugins couldn't be
loaded on uninstalled environment of Windows.
gstreamer!55 makes some changes to how the `error-after` counter works
which breaks this test. This change makes the test not rely on the
ability to alter `error-after` at runtime and explicitly stops and
starts the harness before pushing data.
An alternative would be to add another argument to
`harness_rtpulpfecdec` to set `error-after` on construction but that's
slightly more long-winded. so I went for this approach instead.
Fixes#532, even though that's already closed.
The initial mission statement for this test was:
* demonstrate usage of the request-aux-* signals in rtpbin
* test the rtx elements
We have examples that serve the first use case, and better
(harnessed) tests for the second use case.
This test is slow and racy, it served its purpose but can now
be removed.
Fixes#533
When the EOS event is received, run all timers immediately and avoid
pushing the EOS downstream before this has been run. This ensures that
the lost packet statistics are accurate.
The teardown of the pads checks the refcount, but there are timers
inside the jitterbuffer that can push things, so if we're not lucky,
things could be pushed while the pads are being shut down. Putting the
jitterbuffer to NULL first avoids this.
Always wait with starting the RTCP thread until either a RTP or RTCP
packet is sent or received. Special handling is needed to make sure the
RTCP thread is started when requesting an early RTCP packet.
We want to wait with starting the RTCP thread until it's needed in order
to not send RTCP packets for an inactive source.
https://bugzilla.gnome.org/show_bug.cgi?id=795139