The condition was inverted - the loop is supposed to sleep in 10 ms
increments. A one second msleep in practice slept for about 50 seconds.

Previously, if t.tv_nsec (the amount we actually sleep) was less than
ts.tv_nsec (the amount we should sleep in total), we actually slept the
full duration, but only subtracted 10 ms from the total time to sleep.

This fixes cases where the application hung with "can't get output
picture" at the end, if using hw decoding, and fixes audio output
with hw decoders on Samsung Galaxy S II when using the OpenSLES
aout, where the msleep(CLOCK_FREQ) hung for a very long time.

Signed-off-by: Martin Storsjö <martin@martin.st>

(java.net.URL doesn't even recognize rtsp for instance)

the control will eventually come back later as an option

Edward Wang authored Mar 31, 2012 and Rafaël Carré committed Mar 31, 2012

Signed-off-by: Rafaël Carré <funman@videolan.org>

Edward Wang authored Mar 16, 2012 and Jean-Baptiste Kempf committed Mar 16, 2012

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

They do not really make any sense on Android

Edward Wang authored Mar 09, 2012 and Rafaël Carré committed Mar 10, 2012

Signed-off-by: Rafaël Carré <funman@videolan.org>

Edward Wang authored Mar 10, 2012 and Rafaël Carré committed Mar 10, 2012

Signed-off-by: Rafaël Carré <funman@videolan.org>

The code comes from Android ICS
ABI didn't change since it was committed in 2.2

Tested on ICS, 2.2, 2.1

I am not sure which functions are executed when those are present in libc.so

They are used by pthread-rwlocks.c

Checkout this hash in 'android' branch.
Using reset --hard could delete work without noticing it.