It's useful enough already to be used in other elements for audio aggregation,
let's give people the opportunity to use it and give it some API testing.
https://bugzilla.gnome.org/show_bug.cgi?id=760733
rename gst-launch --> gst-launch-1.0
replace old elements with new elements(ffmpegcolorspace -> videoconvert, ffenc_** -> avenc_**)
fix caps in examples
https://bugzilla.gnome.org/show_bug.cgi?id=759432
New subclass with a similar behaviour as the old liveadder, but
a slightly different API as the latency is in nanoseconds, not
milliseconds. Also, the new liveadder has a effective latency that
is latency + output-buffer-duration. In practice, just setting a non-zero
latency with the new audiomixer gives you the right behavior in 99% of the
cases.
Build error due to wrong argument type in debug message
aagg->priv->offset and next_offset are of type int64, but uint64
formatter is being used in logs. Changing all those to int64
https://bugzilla.gnome.org/show_bug.cgi?id=756065
While creating caps in audiointerleave tests, bitmask is being set as 0x9
This is resulting in segmentation fault. Fix the same by typecasting to guint64
https://bugzilla.gnome.org/show_bug.cgi?id=755840
We might've queued up a GAP buffer that is only partially inside the current
output buffer (i.e. we received it too late!). In that case we should only
skip the part of the GAP buffer that is inside the current output buffer, not
also the remaining part. Otherwise we forward this pad too far into the future
and break synchronization.
We have to queue buffers based on their running time, not based on
the segment position.
Also return running time from GstAggregator::get_next_time() instead of
a segment position, as required by the API.
Also only update the segment position after we pushed a buffer, otherwise
we're going to push down a segment event with the next position already.
https://bugzilla.gnome.org/show_bug.cgi?id=753196
In the case where you have a source giving the GstAggregator smaller
buffers than it uses, when it reaches a timeout, it will consume the
first buffer, then try to read another buffer for the pad. If the
previous element is not fast enough, it may get the next buffer even
though it may be queued just before. To prevent that race, the easiest
solution is to move the queue inside the GstAggregatorPad itself. It
also means that there is no need for strange code cause by increasing
the min latency without increasing the max latency proportionally.
This also means queuing the synchronized events and possibly acting
on them on the src task.
https://bugzilla.gnome.org/show_bug.cgi?id=745768
We need to sync the pad values before taking the aggregator and pad locks
otherwise the element will just deadlock if there's any property changes
scheduled using GstController since that involves taking the aggregator and pad
locks.
Also add a test for this.
https://bugzilla.gnome.org/show_bug.cgi?id=749574
A bitmask is 64 bits, but integer immediates are passed as int
in varargs, which happen to be 32 bit with high probability.
This triggered a valgrind jump-relies-on-uninitalized-value
report well away from the site, since it doesn't trigger on
stack accesses, and there must have been enough zeroes to stop
g_object_set at the right place.
Also:
- Don't modify size on early buffer
The size is the size of the buffer, not of remaining part.
- Use the input caps when manipulating the input buffer
Also store in in the sink pad
- Reply to the position query in bytes too
- Put GAP flag on output if all inputs are GAP data
- Only try to clip buffer if the incoming segment is in time or samples
- Use incoming segment with incoming timestamp
Handle non-time segments and NONE timestamps
- Don't reset the position when pushing out new caps
- Make a number of member variables private
- Correctly handle case where no pad has a buffer
If none of the pads have buffers that can be handled, don't claim to be EOS.
- Ensure proper locking
- Only support time segments
https://bugzilla.gnome.org/show_bug.cgi?id=740236
