Even though this parameter is not used, it should be const to fit in with the
coding standards for other similar parameters. Client code already passes in
const strings under the expectation that they won’t be modified.
https://bugzilla.gnome.org/show_bug.cgi?id=710442
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.
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
Since the refactoring of GstContext (commits
qc9fa2771b508e9aaeecc700e66e958190476f,
a7f5dc8b8a,
690326f906dc82e41ea58b81cdb2e3e88b754,
d367dc1b0d4ecb37f4d27267e03d7bf0c6c06a6, and
82d158aed3f2e8545e1e7d35085085ff58f18) I am no longer able to get
a shared context for an element that is used twice in a pipeline.
I used the documentation and eglglessink as my reference for
implementing the GstContext logic.
As the code was tied to a hardware decoder, I have ported the
GstContext code to fakesink to show the problem. Using the old
API a single ExampleMgr instance is created, but using the new
API each element is creating its own instance.
pads->data is the public list. It is dynamically rebuilt at each call to
check_collected, in check_pads to be specific. When you add a pad and
collectpads have been started, it is not added to the public list.
Thus there exists a possible race where :
1) You would add a pad to collectpads while running.
2) You set collectpads to flushing before check_collected has been called again
-> the pad is not set to flushing
3) the pad starts pushing data as downstream might not be prepared, in the case
of adder it then returns FLOW_FLUSHING.
4) elements like demuxers, when they get a FLOW_FLUSHING, stop their tasks,
never to be seen again.
https://bugzilla.gnome.org/show_bug.cgi?id=708636
