If the application is using the new ART runtime it will otherwise
load dalvik and start a dalvik VM next to the ART VM.
Does not work very well obviously.
Add a new function to calculate video stream framerate which rely on
SPS, slice header and pic timing using formula:
time_scale 1 1
fps = ----------------- x --------------- x ------------------------
num_units_in_tick DeltaTfiDivisor (field_pic_flag ? 2 : 1)
See section E2.1 of H264 specification for definition of variables.
https://bugzilla.gnome.org/show_bug.cgi?id=723352
c400eef377 introduced some defines to handle
older kernel headers. However, the check is done before the corresponding
kernel header (dvb/frontend.h) is included. As a result the macros are
always defined with results in 'redefined' errors with newer kernel
headers.
Move the check after the include to fix this.
https://bugzilla.gnome.org/show_bug.cgi?id=730570
In a pipeline like so:
videotestsrc ! gleffects ! videoconvert ! sink
gleffects was simply passing the videoconvert bufferpool to videotestsrc
and not creating a glbufferpool. videobufferpool would then fail
to allocate from the glallocator.
From d4bcef3204 on, using a RGBA
texture to hold the data causes the glmemory to have half width
and a scaling of [2, 1]. Using a LA texture solves this problem
however cannot be attached to the framebuffer for copying into
a RGBA texture. Which will be solved by moving to EXT_texture_rg.
https://bugzilla.gnome.org/show_bug.cgi?id=728890
Expose one more libcurl option: CURLOPT_SSH_HOST_PUBLIC_KEY_MD5.
This allows authenticating the server by the MD5 fingerprint of
the server's public key.
https://bugzilla.gnome.org/show_bug.cgi?id=723167
gstfreeverb.c:781:29: error: using integer absolute value function 'abs' when
argument is of floating point type [-Werror,-Wabsolute-value]
if (abs (out_l2) > 0 || abs (out_r2) > 0)
We need to sleep a bit before destroying the player object
because of a bug in Android in versions < 4.2.
OpenSLES is using AudioTrack for rendering the sound. AudioTrack
has a thread that pulls raw audio from the buffer queue and then
passes it forward to AudioFlinger (AudioTrack::processAudioBuffer()).
This thread is calling various callbacks on events, e.g. when
an underrun happens or to request data. OpenSLES sets this callback
on AudioTrack (audioTrack_callBack_pullFromBuffQueue() from
android_AudioPlayer.cpp). Among other things this is taking a lock
on the player interface.
Now if we destroy the player interface object, it will first of all
take the player interface lock (IObject_Destroy()). Then it destroys
the audio player instance (android_audioPlayer_destroy()) which then
calls stop() on the AudioTrack and deletes it. Now the destructor of
AudioTrack will wait until the rendering thread (AudioTrack::processAudioBuffer())
has finished.
If all this happens with bad timing it can happen that the rendering
thread is currently e.g. handling underrun but did not lock the player
interface object yet. Then destroying happens and takes the lock and waits
for the thread to finish. Then the thread tries to take the lock and waits
forever.
We wait a bit before destroying the player object to make sure that
the rendering thread finished whatever it was doing, and then stops
(note: we called gst_opensles_ringbuffer_stop() before this already).
