Interestingly, Coverity implies that close takes an unsigned
argument, while my close(2) man page shows it taking a signed
argument. I guess it may be platforms specific.
Coverity 1214602
New approach attempts to be more accurate by measuring
the elapsed time by iteration. Also:
* Use a 10 seconds default timeout and a half a second
polling step. New values should better match the tuning
process on real-life scenarios.
* Correct elapsed_time computation.
* Add _retry_ioctl() to avoid bailing out on temporary
ioctl EINTR failures (no need to check for EAGAIN cause
we are opening the frontend on blocking mode)
* Small corrections to fail condition handling
Check if libnativehelper is loaded in the process and if
it has these awful wrappers for JNI_CreateJavaVM and
JNI_GetCreatedJavaVMs that crash the app if you don't
create a JniInvocation instance first. If it isn't we
just fail here and don't initialize anything.
See this code for reference:
https://android.googlesource.com/platform/libnativehelper/+/master/JniInvocation.cpp
* Drop remaining sleep() logic in favor of polling
* Use best guess delivery system if none is set
* Make tuning/locking timeout configurable
* Add signals for tuning start, done and fail
* Drop gst_dvbsrc_frontend_status(). It was used only
for signal LOCK checking. This is now part of the
tuning/locking loop
* Break up frontend configuration and tuning
on separate functions
Plus:
* Add some more useful DEBUG/TRACE messages
* Move over misplaced DVB API message
* Fix wrong comment for default DVB buffer size (http://linuxtv.org/downloads/v4l-dvb-apis/dmx_fcalls.html#DMX_SET_BUFFER_SIZE)
This patch builds up on previous work done by
Fabrizio (Misto) Milo <mistobaan@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=641204
On Samsung Galaxy S4 it is impossible to have more than one
hardware decoder at the same time. If we do not release it
explicitly the GC only releases it whenever the whole application
is finished not whenever the activity is finished and thus a player
will not be able to work correctly
gst_amc_color_format_copy will copy in/out a frame resides at a
GstAmcBuffer. Lots of codes in gst_amc_video_*_fill_buffer are moved to
this new function.
Some hack logic needs also to be present in create_src|sink_caps, for
working around some broken codecs. These hacks are hidden
in color_format/video_format conversion -- the prototypes of these
functions are also changed to include more args for hack judgement.
Also in case of multi-color_formats mapped to one video_format, then
map that video_format back will not give the original color_format, which
causes gst_amc_codec_configure failed with something like
'does not support color format N'.
The new prototype involves with GstAmcCodecInfo and mime, which
ensures the converted color_format is supported by the codec.
A COLOR_FormatYCbYCr to GST_VIDEO_FORMAT_YUY2 mapping is also added, in
order to work around bugs in OMX.k3.video.decoder.avc(which incorrectly
reports supporting COLOR_FormatYCbYCr, which is actually
COLOR_FormatYUV420SemiPlanar). There are already hacks for this in
gst_amc_video_format_to_color_format, gst_amc_color_format_to_video_format
and gst_amc_color_format_info_set, but the codec will still not work(be
ignored because of "has unknown color formats") without adding this mapping.
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.
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
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).
