Don't use g_assert() for error handling, even if they're highly unlikely.
Either we *know* that something can't happen, in which case we
should just not handle it, or we think something can happen, but it is
very very unlikely that it will ever happen, in which case we should
handle it like any other error instead of asserting.
g_assert() is best left for conditions we have control of, like checking
internal consistency of our code, not checking return values of external
code.
Fixes a bunch of warnings when compiling with -DG_DISABLE_ASSERT:
gstrtpgsmpay.c: In function 'gst_rtp_gsm_pay_handle_buffer':
gstrtpgsmpay.c:130:17: warning: variable 'rtpgsmpay' set but not used
gstspeexenc.c: In function 'gst_speex_enc_encode':
gstspeexenc.c:904:19: warning: variable 'written' set but not used
pulsesink.c: In function 'gst_pulsesink_change_state':
pulsesink.c:2725:9: warning: variable 'res' set but not used
pulsesrc.c: In function 'gst_pulsesrc_change_state':
pulsesrc.c:1253:7: warning: variable 'e' set but not used
GCC 4.6.x spits warnings about such usage of variables. The variables in
raw1394 were marked with G_GNUC_UNUSED as this seemed omre appropriate.
The others were removed.
Instead only store them inside the flac metadata. There's
no point in storing them twice and the flac metadata is
still the official way to store image tags inside flac.
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.
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.
If we did not know how many frames to expect, then we get an unexpected
end of stream when trying to decode more frames that are there, if there
are leftover bits to pad to the next byte
Looking at the remaining bits in the bitstream after decoding a
single frame can't be used as loop condition. The remaining
bits might not give a complete frame and the speex decoder will
then output nothing but access uninitialized memory, which leads
to valgrind warnings.
Fixes bug #644669.
Allows applications to connect to the "draw" signal of
the element and do their custom drawing there.
Includes an example application demonstrating usage.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=595520
Not doing so can result in a deadlock when two threads enter
gst_pulseringbuffer_open_device at the same time, as
pa_threaded_mainloop_wait releases the mainloop lock while waiting,
allowing another thread to take it, resulting in a deadlock as two
threads waits for the lock the other is holding.
https://bugzilla.gnome.org/show_bug.cgi?id=643087
By allowing larger chunks to be sent, PulseAudio will have a
lower CPU usage. This is especially important on low-end machines,
where PulseAudio can crash if packets are coming in at a higher
rate than PulseAudio can process them.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
After starting the ringbuffer, we wait for enough data to arrive before
uncorking the stream. This will cause the pipeline to stall if we get an
EOS (or otherwise need to flush the stream) before sufficient data
becomes available. This patch makes sure that the stream is uncorked
while flushing to avoid this problem.
Fixes issue with a webkit unit test testing reverse playback of
an MP4 H.264/AAC file.
https://bugzilla.gnome.org/show_bug.cgi?id=639740
This makes the call to pa_stream_cork() during ringbuffer pause()
synchronous, which makes sure that the clock does not advance after we
take a snapshot for start_time.
https://bugzilla.gnome.org/show_bug.cgi?id=639240
