The problem is that after a discont, set_min_frame_size(1024) is called when
detect_stream returns FALSE. However, detect_stream calls check_adts_frame
which sets the frame size on its own to something larger than 1024. This is the
same situation as in the beginning, so the base class ends up calling
check_valid_frame in an endless loop.
Baseparse internaly breaks the semantics of a _chain function by calling it with
buffer==NULL. The reson I belived it was okay to remove it was that there is
also an unchecked access to buffer later in _chain. Actually that code is wrong,
as it most probably wants to set discont on the outgoing buffer.
1) We need to lock and get a strong ref to the parent, if still there.
2) If it has gone away, we need to handle that gracefully.
This is necessary in order to safely modify a running pipeline. Has been
observed when a streaming thread is doing a buffer_alloc() while an
application thread sends an event on a pad further downstream, and from
within a pad probe (holding STREAM_LOCK) carries out the pipeline plumbing
while the streaming thread has its buffer_alloc() in progress.
If we get GAP samples, there is no need to transmitt it.
In some situations, microphone is muted, we can drop net traffick
usage to ~1 kbit/s. Without patch it will stay ~20 kbit/s
Parse session control attributes when no media control attribute is
present. Threat * control attributes as an empty string, just like the
spec says.
Fixes#646800
... 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.
