| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
|
|
|
| |
Start with some basic tests.
|
|
|
|
| |
Add a few comments. Tell in the results, which number are from which test.
|
|
|
|
|
| |
make sure that pending events are pushed when caps are already
set when a buffer is received
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Store the eos event seqnum and use it when creating the
new eos event to be pushed downstream. To know if the eos
was caused by the eos events received on send_event, a
'forced_eos' flag is used to use the correct seqnum on
the event pushed downstream.
Useful if the application wants to check if the EOS message
was generated from its own pushed EOS or from another source
(stream really finished).
Also adds a test for this
https://bugzilla.gnome.org/show_bug.cgi?id=722791
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=710034
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=711138
|
| |
|
|
|
|
|
| |
Also convert some comments about valgrind warnings to
FIXME comments. These were leaking since some time already.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=710034
|
|
|
|
|
|
|
|
|
| |
Baseparse stores buffers for reverse playback to push on the next
DISCONT, the issue was that it wouldn't ever check for a discont
on passthrough mode as it skips all real parsing. This test
was create to verify this issue and prevent it from happening again
https://bugzilla.gnome.org/show_bug.cgi?id=721941
|
|
|
|
| |
Just a small test to check that basic playback works
|
| |
|
|
|
|
|
| |
Add a unit test to check that positive and negative offsets are applied
correctly in various cases.
|
|
|
|
|
|
|
| |
And make sure that these new probes are actually called if they should
instead of silently blocking the pad forever.
https://bugzilla.gnome.org/show_bug.cgi?id=721289
|
|
|
|
| |
inlining used
|
|
|
|
|
|
|
|
| |
Checking twice the lower bound is great (you never know, it might change
between the two calls by someone using emacs butterfly-mode), but it's a bit
more useful to check the higher bound are also identical.
Detected by Coverity
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=720029
|
|
|
|
|
|
| |
g_source_remove() works on the default main context, and
we're doing things with a custom context. Fixes warning
with newer GLib versions.
|
|
|
|
|
|
| |
Otherwise caps containing f={X, X} are not compatible with f=X
https://bugzilla.gnome.org/show_bug.cgi?id=709253
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=708416
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=708416
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=708416
|
|
|
|
|
|
|
|
| |
Used for setting the default system clock that is obtained through
gst_system_clock_obtain(), which is sometimes needed for unit
testing.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=711269
|
|
|
|
| |
Also add a unit tests
|
|
|
|
|
|
|
| |
Also remove incorrect comment about code possibly not being reachable
that is now exercised by the filesrc unit test.
https://bugzilla.gnome.org/show_bug.cgi?id=709831
|
|
|
|
|
|
|
|
|
|
| |
gst_parse_launchv, gst_parse_launchv_full and gst_parse_launch_full
all return floating refs, the same as gst_parse_launch, which just
calls gst_parse_launch_full internally anyway.
Add a unit test assertion to check it's true.
Spotted by nemequ on IRC.
|
|
|
|
|
| |
In the docs and the autocompletion logic the maximum
value jumped incongruently between 5 and 9.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=709253
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=709253
|
|
|
|
|
| |
So that we get a warning in the output that reminds us that
something needs to be fixed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The check itself is racy.
(CK_FORK=no GST_CHECK=test_output_order make elements/multiqueue.forever).
The problem is indeed the test and not the actual element behaviour.
The objects to push are being pulled out of the single internal queues in the
right order and at the right time...
But between:
* the moment the global multiqueue lock is released (which was used to detect
if we should pop and push downstream the next buffer)
* and the moment it is received by the source pad (which does the check)
=> another single queue (like the unlinked pad) might pop and push a buffer
downstream
What should we do ? Putting a bigger margin of error (say 5 buffers) doesn't
help, it'll eventually fail.
I can't see how we can detect this reliably.
https://bugzilla.gnome.org/show_bug.cgi?id=708661
|
|
|
|
|
|
|
|
| |
Wrap caps strings so that it can handle serialization and deserialization
of caps inside caps. Otherwise the values from the internal caps are parsed
as if they were from the upper one
https://bugzilla.gnome.org/show_bug.cgi?id=708772
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=708668
|
|
|
|
|
|
|
| |
Make the testclock return GST_CLOCK_UNSCHEDULED when an unscheduled entry is
used for gst_clock_wait() or gst_clock_wait_async().
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=708605
|
| |
|
| |
|
| |
|
|
|
|
| |
Reset the write position to 0 and truncate the file on FLUSH_STOP.
|
| |
|
|
|
|
|
|
| |
Also add unit tests for gst_buffer_memcmp
https://bugzilla.gnome.org/show_bug.cgi?id=706162
|
| |
|
|
|
|
|
|
|
| |
Interfaces can have new members added without breaking ABI, so
remove it from the check.
https://bugzilla.gnome.org/show_bug.cgi?id=623799
|
|
|
|
| |
Include regression test
|
|
|
|
| |
API: gst_adapter_take_fast()
|
| |
|
|
|
|
|
| |
Don't special case segment/caps, just push all sticky events when they are
received on the currently active pad or when the active pad changes.
|
| |
|
|
|
|
|
|
|
| |
Added a new function gst_check_setup_events_with_stream_id(), since
gst_check_setup_events() does not work with multiple pads.
https://bugzilla.gnome.org/show_bug.cgi?id=703377
|