Remove all the bus watch and main loop code from the block_deadlock
test, it's not needed: neither pipeline will ever post an EOS or ERROR
message on the bus, and we're the only ones posting an error, from a
timeout. Might just as well just sleep for a bit and then do whatever
we want to do.
Don't gratuitiously set tcase timeout, just use whatever is the
default (or set via the environment).
Make individual pipeline runs shorter.
Check for valgrind and only do a handful iterations when running
in valgrind, not 100 (each iteration takes about 4s on a core i7).
Make videotestsrc output smaller buffers than the default resolution,
we don't care about the buffer contents here anyway.
Fixes test timeouts when run in valgrind.
On slower systems, or under high system load (e.g. check-valgrind),
the sending_buffers_with_9_gstmemories test would sometimes fail,
because the read call only returns 32 bytes instead of the full
36 bytes expected. This is because multisocketsink might end up
doing a partial write of 32 bytes first, and then write the
missing 4 bytes later, but since we don't wait for all of data
to be written, there's a short window where our read call in the
unit test might then only receive the 32 bytes written so far,
which makes it deeply unhappy.
Instead, make sure we loop to read all bytes.
We don't expect clients to send us any data, but if they do, just
ignore it. Web browsers might send us an HTTP request for example,
but some will still be happy if we just send them data without
a proper HTTP response.
There was a bug in the reading code path. We only have a small
read buffer and would provoke an EWOULDBLOCK trying to read
because we don't bail out of the loop early enough.
https://bugzilla.gnome.org/show_bug.cgi?id=743834
This test sets a rather short timeout, increase this when
we run under valgrind. Also add a short sleep to the
fakesrc ! fakesink pipeline to avoid thrashing the CPU,
which would often not stop the main loop when it should.
Also fix wrong (0.10) return value from pad probe callback.
Bypass g_convert/iconv if there's nothing to convert. That way,
conversion won't fail on systems where iconv doesn't support
converting utf-8 to latin1 and there's nothing to convert.
https://bugzilla.gnome.org/show_bug.cgi?id=723252
When a stream has a skeleton index, the stream time is taken from that
index. However, when part of the stream is captured, the index is
invalid as its offsets are now wrong. To avoid this, we ignore the index
when the last offset points beyond the end of the stream (when its
byte length is known).
https://bugzilla.gnome.org/show_bug.cgi?id=744070
When deltax is large enough to cause the text to push past the
width of the frame, it would disappear due to a bug in setting
the layout width.
While there, fix a log printing an incorrect width to set.
https://bugzilla.gnome.org/show_bug.cgi?id=739689
oggmux keeps a cached buffer per pad, and pulls buffers from
collectpads to this cached buffer for all pads before processing
the best pad. In some cases, the move from collectpads buffer
to cached buffer is delayed till next call. However, when there
is only one pad, this can't be delayed till next call as there
will be a deadlock since collectpads has no other pad to push to.
https://bugzilla.gnome.org/show_bug.cgi?id=740565
When shutting down the chain, we can get a deadlock when removing
a pad, if that chain was being busy streaming but blocked (eg, while
waiting for a queue to have free space).
https://bugzilla.gnome.org/show_bug.cgi?id=746480
memcmp will blindly compare the reserved fields, as well as any
padding the compiler may choose to sprinkle in GstSegment.
Fixes valgrind complaints in unit tests, as well as some found via
https://bugzilla.gnome.org/show_bug.cgi?id=738216
A previous patch increased allocations by 15 bytes in order to ensure
16 byte alignment for g_malloc blocks. However, shared memory is
already block aligned, and this extra 15 bytes caused allocation
to fail when we were already allocating to the shared memory limit,
which is a lot smaller than typical available RAM.
Fix this by removing the alignment slack when allocating shared
memory.
https://bugzilla.gnome.org/show_bug.cgi?id=706066
A previous patch increased allocations by 15 bytes in order to ensure
16 byte alignment for g_malloc blocks. However, shared memory is
already block aligned, and this extra 15 bytes is not needed. Since
shared memory limits are low compared to RAM, we remove this waste.
https://bugzilla.gnome.org/show_bug.cgi?id=727236
In case upstream does not provide videorate with framerate information,
it will detect the current framerate from the buffer it received,
but if downstream forces the use of variable framerate (most probably
through the use of a caps filter with framerate = 0 / 1), videorate will
respect that.
And add some unit tests
https://bugzilla.gnome.org/show_bug.cgi?id=734424
In the case the framerate is variable (represented by framerate=0/1),
we currently end up loop pushing the first buffer and then recompute
diff1 and diff2 without updating the videorate->next_ts at all
leading to infinitely looping pushing that first buffer.
In the case of variable framerate, we should just compute the next_ts
as previous_pts + previous_duration.
https://bugzilla.gnome.org/show_bug.cgi?id=734424
The patch calculates a second channel mixing matrix from the current one. The
matrix contains the original values * (2^10) as integers. This matrix is used
when integer-formatted channels are mixed.
On a ARM Cortex-A8, single core, 800MHz this improves performance in a
testcase from 29s to 9s for downmixing 6 channels to stereo.
https://bugzilla.gnome.org/show_bug.cgi?id=747005
The spec for this does not say nor imply how this should be
interpreted. The previous code would try to shift by 64 bits,
which is undefined.
Coverity 1195119
https://bugzilla.gnome.org/show_bug.cgi?id=727955
When generating segment, we can't assume the first buffer is actually
the first expected one. If it's not, we need to adjust the segment to
start a bit before.
Additionally, we if don't know when the stream is suppose to have
started (no clock-base in caps), it means we need to keep everything in
running time and only rely on jitterbuffer to synchronize.
https://bugzilla.gnome.org/show_bug.cgi?id=635701
If a new pad is added after playbin has been put to READY/NULL it
should ignore new pads as it is shutting down.
This can happen when the pipeline fails to preroll (is still in READY)
and the user gives up on waiting or an error that doesn't reach
the demuxer occurs (on some event handling) and it will continue to
work and exposing pads while playbin has been put to NULL.
Without this check an input-selector is created and set to PAUSED
state, preventing playbin from properly shutting down in case it
has data blocked inside it.
audio_convert_convert unpacks to default format (signed) before calling
quantize, and the unsigned variants were equivalent to signed anyway,
so we just get rid of them.
Since range size is always 2^n, we can simply use modulo (implemented
with a bitmask).
The previous implementation used 64-bit integer division, which is
done in software on ARMv7. Although the divisor was constant, the
division could not be transformed into "multiplication by magic number"
since the dividend was 64-bit.
The now-unused and not-so-fast gst_fast_random_(u)int32_range functions
were removed.
Also, implementing bug fixes:
1) ADD_DITHER_TPDF_HF_I no longer discards bias.
2) We change TPDF's noise range to be the same as RPDF's. Previously,
RPDF's noise ranged:
{ bias - dither, bias + dither }
while TPDF's noise ranged:
{ bias/2 - dither/2, bias/2 + dither/2 - 1 } +
{ bias/2 - dither/2, bias/2 + dither/2 - 1 } =
{ bias - dither, bias + dither - 2 }
Now, both range:
{ bias - dither, bias + dither - 1 }
https://bugzilla.gnome.org/show_bug.cgi?id=746661
This fixes a race where the use-buffering property on a multiqueue was
set before the queue depth was changed from it's high preroll limits to
lower playback limits. This resulted in buffering messages being emitted
by the multiqueue in the short window between use-buffering being
set and the queue depth being reset.
https://bugzilla.gnome.org/show_bug.cgi?id=744308
