There could be a case where:
1) you do a new set_caps after buffers have been processed.
2) ts_offset gets set to a different value, eg 0.033333333
3) your pads get EOS, but the check dor that doesn't work
because you use ts_offset + a truncated value < segment.stop
4) so in the next collected, you end up comparing for example:
0.9999999999 > 1., which is false and means you don't send EOS.
Also adds scale_round in two other places where it potentially could
have caused problems.
We'll have to pop buffer from collectpads and store it
internally only to get the timestamp of the next buffer.
If we continue to keep it in collectpads, no new buffer
to calculate the end time will ever arrive.
https://bugzilla.gnome.org/show_bug.cgi?id=703743
When the segment start is not 0, this created a situation where
the output_end_time is inferior to output_start_time, and the duration
of the next buffer ended up underflowing.
https://bugzilla.gnome.org/show_bug.cgi?id=701385
There is no reason to send a flush-stop when receiving a seek event.
In the case of a flushing seek, we could eventually want to, but in
the code path were we check if the seek is "flushing", we have the
following comment that makes sense:
"we can't send FLUSH_STOP here since upstream could start pushing data
after we unlock mix->collect.
We set flush_stop_pending to TRUE instead and send FLUSH_STOP after
forwarding the seek upstream or from gst_videomixer_collected,
whichever happens first."
https://bugzilla.gnome.org/show_bug.cgi?id=684237
This reverts commit 84ae670ab4.
Actually this is not how it is supposed to work. videomixer
creates a [0,-1] segment and then puts frames of the different
streams there based on their running times in their own segments.
This could have prevented images showing that should have when the
source height is greater than its width.
When width exceeds height, as is common, it probably only caused a
miniscule amount of unnecessary work. I haven't tested.
If both pads receive data at the same time, they will both get their
sink_setcaps called which will call the src_setcaps, but there is
a race condition where the second one might not be called.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=683842
gst_video_frame_map() increases the refcount, which makes
the buffer not writable any more technically, so calling
gst_buffer_memset() on it will cause nasty warnings.
Unit test disabled because it very rarely (for me)
fails, possibly negotiation-related.
https://bugzilla.gnome.org/show_bug.cgi?id=684398
In the current implementation, the custom pad query function is not called.
This patch, set that query function on the GstCollectPads to avoid this
shadowing.
See https://bugzilla.gnome.org/show_bug.cgi?id=684237
Add private replacements for deprecated functions such as
g_mutex_new(), g_mutex_free(), g_cond_new() etc., mostly
to avoid the deprecation warnings. We'll change these
over to the new API once we depend on glib >= 2.32.
Remove the android/ top dir
Fixe the Makefile.am to be androgenized
To build gstreamer for android we are now using androgenizer which generates the needed Android.mk files.
Androgenizer can be found here: http://git.collabora.co.uk/?p=user/derek/androgenizer.git
This option allows the videomixer2 element to output a valid alpha
channel when the inputs contain a valid alpha channel. This allows
mixing to occur in multiple stages serially.
The following pipeline shows an example of such a pipeline:
gst-launch videotestsrc background-color=0x000000 pattern=ball ! video/x-raw-yuv,format=\(fourcc\)AYUV ! videomixer2 background=transparent name=mix1 ! videomixer2 name=mix2 ! ffmpegcolorspace ! autovideosink videotestsrc ! video/x-raw-yuv,format=\(fourcc\)AYUV ! mix2.
The first videotestsrc in this pipeline creates a moving ball on a
transparent background. It is then passed to the first videomixer2.
Previously, this videomixer2 would have forced the alpha channel to
1.0 and given a background of checker, black, or white to the
stream. With this patch, however, you can now specify the background
as transparent, and the alpha channel of the input will be
preserved. This allows for further mixing downstream, as is shown in
the above pipeline where the a second videomixer2 is used to mix in a
background of an smpte videotestsrc. So the result is a ball hovering
over the smpte test source. This could, of course, have been
accomplished with a single mixer element, but staged mixing is useful
when it is not convenient to mix all video at once (e.g. a pipeline
where a foreground and background bin exist and are mixed at the final
output, but the foreground bin needs an internal mixer to create
transitions between clips).
Fixes bug #639994.
There's no need to call orc_init() unless you're using the Orc
API directly. All code created by orcc is guaranteed to work
without calling orc_init().
This is based on collectpads2 and is synchronizing
all streams based on the running time.
New features compared to old videomixer:
* Synchronizing frames on the running time
* Improved and simplified negotiation
* Full QoS support
* Variable framerate support
Fixes bug #626048, #624905.
