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.
This commit basically puts _get_caps() in sync with accept_caps().
If we don't have a master pad OR the master pad caps aren't negotiated
then we just return the downstream allowed caps.
If we have a master pad with negotiated caps, we return those caps
with a free range of width/height/framerate
They are the same as the mm0-mm7 MMX registers and will be overwritten
by the assembly code if gcc doesn't know about the MMX registers.
Note: They're all added to the list of clobbered registers in all cases
and not only when __MMX__ is not defined just to make sure that no other
bugs happen with this code just because some compiler version gets things
wrong.
Fixes bug #614466.
When the pad with the highest framerate goes EOS, instead of not timestamping
output buffers, intepollate timestamps and durations from the last seen ones.
Fixes#608026
This avoids the "bad register name `%dil'" compilation errors on 32bit where
because of 'r' gcc puts the value in a general purpose register and then tries
to access the lower part as %dil/%sil which is not existing on 32bit. 'q' requests
a-d registers
This drops frames if they're too late anyway before blending and all
that starts but QoS events are not forwarded upstream. In the future
the QoS events should be transformed somehow and forwarded upstream.
