Move the conversion code used in videoconvert to the video library
and expose a simple but generic API to do arbitrary conversion. It can
currently do colorspace conversion but the plan is to add videoscale to
it as well.
See https://bugzilla.gnome.org/show_bug.cgi?id=732415
Adds a new test to textoverlay to make sure it can properly handle
elements that have ANY caps but fail to add the overlay meta in
the allocation query.
This test verifies that textoverlay won't use the caps features even
knowing that the overlay meta is accepted when querying the downstream
caps because it also needs downstream to confirm by putting the meta
in the allocation query.
https://bugzilla.gnome.org/show_bug.cgi?id=735800
Make textoverlay negotiate caps more correctly.
1) Check what caps we received in the video-sink
2) If it already has the overlay meta -> use it directly
3) If it doesn't, textoverlay try adding the overlay meta and using it,
if downstream doesn't support it, just use what is received in the
video-sink
4) Check if the allocation query also supports the meta to enable
really using it
Before it wasn't really doing renegotiation of any kind, just
re-checking if it should use the overlay meta or not
Also had to update the caps in the test as memory:SystemMemory seems
to be required when you use a caps feature otherwise intersection/subset
checks will fail.
https://bugzilla.gnome.org/show_bug.cgi?id=733916
Set up a fakesink with a pad probe to replace the missing encoder to detect
if encoding was really required and only error out in this case. Otherwise
just let passthrough branch work.
This delays the error posting from the set_state function to when buffers
are really flowing. Unit test updated accordingly
https://bugzilla.gnome.org/show_bug.cgi?id=650652
Make the MIKEY message and payload objects miniobjects so that they have
a GType and are refcounted.
We can reuse the dispose method to clear our payload objects.
Add some annotations.
Implement a copy function for the MIKEY message.
Fix the unit test.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=732589
With most decoder libraries, and especially when accessing codecs via
OpenMAX or similar APIs, we don't have the ability to properly related
the output buffers to a number of input samples. And could e.g. get
a fractional number of input buffers decoded at a time.
Previously this would in the end lead to an error message and stopped
playback. Change it to a warning message instead and try to handle it
gracefully. In theory the subclass can now get timestamp tracking
wrong if it completely misuses the API, but if on average it behaves
correct (and gst-omx and others do) it will continue to work properly.
Also add a test for the new behaviour.
We don't change it in the encoder yet as that requires more internal logic
changes AFAIU and I'm not aware of a case where this was a problem so far.
Aggregate buffering messages to only post the lower value
to avoid setting pipeline to playing while any multiqueue
is still buffering.
There are 3 scenarios where the entries should be removed from
the list:
1) When decodebin is set to READY
2) When an element posts a 100% buffering (already implemented)
3) When a multiqueue is removed from decodebin.
For item 3 we don't need to handle it because this should only
happen when either 1 is hapenning or when it is playing a
chained file, for which number 2 should have happened for the
previous stream to finish
https://bugzilla.gnome.org/show_bug.cgi?id=726423
playbin's buffer-size property takes a gint, not a gint64,
so only pass the bits expected to the vararg function, or
the terminator might not be found, leading to crashes, esp.
with negative numbers.
Spotted by Ravi Kiran K N <ravi.kiran@samsung.com>
https://bugzilla.gnome.org/show_bug.cgi?id=729617
