The output size of a buffer does not depend on the input size but simply on the
caps of the output buffers. Don't let the base implementation deal with
unit_sizes, because input buffers might not be a multiple of that when they have
padding or non-default strides. instead, implement a transform size function
that simply calculate the natural size of an output buffer based on the caps.
fix build errors:
gsttypefindfunctions.c:248:25: error: 'low' may be used uninitialized in this function [-Werror=uninitialized]
gsttypefindfunctions.c:239:24: error: 'high' may be used uninitialized in this function [-Werror=uninitialized]
Signed-off-by: Alexey Fisher <bug-track@fisher-privat.net>
audioresample is derived from GstBaseTransform, and one of
GstBaseTransform's traits is that if the derived element does not
produce an output buffer from some input buffer then the first output
buffer after that gets flaged as a discontinuity, whether or not the
buffer actually is discontinuous from the output buffer that preceded
it. When downsampling, the audioresample element requires more than
one input sample for each output sample, and if the ratio of input to
output sample rates is high enough and the input buffers short enough
it can come to pass that the resampler does not receive enough samples
on its input to produce any output. Currently the resampler returns
GST_BASE_TRANSFORM_FLOW_DROPPED from the transform() method in this case,
causing the next buffer to be flagged as a discontinuity. If subsequent
elements in the pipeline reset themselves on disconts, this can cause
clicks and other undesireable behaviour.
Fixes bug #665004.
After preroll the multiqueue limits are still set to the preroll
limits if use-buffering is set to TRUE. In that case we only want
time limits on the multiqueue if upstream is seekable.
Such streams were detected as seekable, as the query on the typefind
element was testing the m3u8 file listing the actual streams, and
not going through the demuxer(s).
We now check for seekability for each multiqueue following a demuxer,
so the query will flow through the elements which might prevent seeking.
https://bugzilla.gnome.org/show_bug.cgi?id=647769
API: GstVideoRate:force-fps
Changing the framerate during playback is not possible
with a capsfilter downstream if upstream is not using
gst_pad_alloc_buffer(). In that case there's no way in
0.10 to signal to videorate that the preferred framerate
has changed.
This new property will force the output framerate to
a specific value and can be changed during playback.
The ghostpad acceptcaps functions are not valid in this case because
we don't only accept the caps accepted by the target but could also
insert converters. Fixes bug #663892.
