... by forcing a state changed to PLAYING, which should otherwise be a
no-op as elements should already be in that state.
In particular, jitterbuffer needs new base_time as soon as possible to perform
proper timing (e.g. eos timeout handling) and can't wait for the new base_time
that will be distributed when the whole pipeline returns to PLAYING.
See bug #646397.
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.
Previously the chain function was working sample frame based. In each cycle it
was checking if it is time to run a fft or if it is time to send a message.
Now we changed the data transform functions to work on a block of data and
calculate the max length until either {end-of-data, do-fft, do-msg}. This allows
us also to avoid the duplicated code for the single and multi-channel case (as
the transformers have the same signature now).
Even though we wrap around the accumulated second, we still need to add the
error in the same cycle. Increase the todo in the same conditional as afterwards
the accumulated error will be below one second.
AUTHOR only existed in an old version of the spec and ARTIST is
the new replacement for this. We are still reading both to still
be compatible with old files.
Fixes bug #644875.
Before it was possible that we run an extra fft when the time for sending a new
message is due. Only do this if we have not run the fft for the interval at all.
Don't check the format for each sample frame to read. We can make that decission
in _setup already. This is still not ideal as we call the function per frame.
Ideally we determine how many samples we can copy and have a loop in the input
reader. As an alternative we might also consider to use the fft variants for the
various formats and not convert to float for all cases - we would still need to
mix or deinterleave though.
In case server-side fails to perform seek, i.e. PLAY at non-zero requested
position, recovery so far would arrange for streaming to continue, albeit
having lost position tracking in the process. So, query position prior
to seek and use upon failed seek.
Add a boolean multi-channel property with a default of FALSE. When set to TRUE
the element won't mix all input channels to mono, but instead run a FFT on each
channel. In that case the result message would contain a 2 dimensional array
of channel x data for magnitude and phase.
API: GstSpectrum:multi-channel
https://bugzilla.gnome.org/show_bug.cgi?id=593482
Use a separate function to read a sample frame into a ringbuffer slot. In the
future we can use format-specific function pointer to avoid the reoccuring
format checks.
We now keep the fft data that is related to one channel in a separate structure
to prepare for multichannel support. We also refactor the code to operate more
often on the channel context.
