Sending the flush-start event forward before taking the stream lock actually
works, in contrast to deadlocking in downstream preroll_wait (hunk 1).
After that we get the chain function being stuck in a busy loop. This is fixed
by updating the minimum frame size inside the synchronization loop because the
subclass asks for more data in this way (hunk 2).
Finally, this leads to a very probable crash because the subclass can find a
valid frame with a size greater than the currently available data in the
adapter. This makes the subsequent gst_adapter_take_buffer call return NULL,
which is not expected (hunk 3).
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.
Original commit message from CVS:
* tests/check/Makefile.am:
* tests/check/elements/aacparse.c:
* tests/check/elements/amrparse.c:
Add unit tests for new parsers.
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
Speex has build in silence detection. If speex_encode_int returns 0,
than there is silence and sample do not need to be transmitted.
This work only if vbr=1 and dtx=1 optionas are enabled.
So if we get 0, we add GAP flag to the sample.
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.
Pulsesink was recently changed to defer uncorking until there is data
to write. This condition will however never occur when EOS in being
rendered (since that marks the end of data). Changing to PAUSED state
while EOS is being waited on results in a hang: pausing corks the
stream, which will never be undone since there is no more data when
going back to PLAYING. If pulsesink is the clock provider, deadlock
ensues since time doesn't continue in corked state and the clock id
for EOS wait never fires.
Fixes#645961.
