[Android] On the road to 0.0.9

[Rafaël Carré]

Hello,

Le 24/01/2013 16:39, Jean-Baptiste Kempf a écrit :
> On 23 Jan, Jean-Baptiste Kempf wrote :
>> On the road to 0.0.9
> 
> So, after quite a few hours of testing:
>  - OpenSL ES lipsync drift increases by quite a bit, the longer you
>    watch a video. A 20 minutes TBBT shows it quite clearly, in the end.
>    Seeking works fine.

Sorry but I still can't reproduce, so I don't know what is the problem
exactly (not enough details, I can only guess and j-b mistakes my
requests of more details for disdain).

Here is what I did:
- Played the mentioned TBBT sample for 20 minutes on the Galaxy Note II,
and lipsync was still good.
Sample is on
http://streams.videolan.org/misc/The%20Big%20Bang%20Theory%20-%20S05E24.mp4

Played "U-Turn (Oliver Stone) French.avi" for one hour on Galaxy Note II
and lipsync was still good.
codec info: MPEG4-Video 25fps 720x384 - MPEG Audio layer 1/2/3 stereo 48kHz

Played BILLY.ELLIOT.francais.divx5.03.lame.mp3.avi for one hour on HP
Touchpad and lipsync was still perfect.


I will give you billy elliot sample because with music (piano) and
several music changes at the exact same time of scene changes make it
easy to watch for lipsync.
You can let it run for a while with volume at 0 and look back to see if
lipsync is ok.


I also ask if you can uncomment the msg_Dbg in TimeGet() function of
opensles_android.c before testing.

It will be very very very verbose though so you should compress adb
logcat output:
adb logcat | grep VLC - | bzip2 > log.bz2


Since I can't reproduce the bug here, please send me as much info as you
can including but not limited to:
- your hardware
- version of android (and/or cyanogenmod)
- logcat
- direction of the drift (audio before or after video)
- amount of drift (in fortnights, hours, seconds, milliseconds...)
- speed of drift (looks like 1s after 20 mins, 2s after 40 mins, 3s
after 60mins?)
- video recording of a device suffering from the drift bug would help me
because so far I have not witnessed it with my own eyes. If you can give
me this I will stop pretending the bug doesn't exist and it will make
j-b happy. I am not kidding on that one, this would really help.

Maybe it sounds a lot but since I can't reproduce the problem here (and
I am likely the one who will fix the bug if it is in opensles) so we
need to identify the difference in our testing methods.

If by chance you can put your hands on 2 identical devices you could
start the 2 at the same time with 2 different aouts and see how it
evolves over time.




I am the first person who wants to see lipsync bugs fixed because I have
spent lot of time on it and don't want to see that time wasted.

Let me be clear though: I don't think there's a bug in OpenSLES because
I've reviewed that code many times and it worked fine so far for
everyone for small movies, and fine for me for long movies. (Admittedly
we should have tested longer movies during/after the audio workshop).

I am not calling you liars either, so I guess the issue is somewhere else.
Bad comments on the market about broken lipsync in 0.0.8 help to think
the issue is somewhere else than in opensles.
The fact that users have known methods for working around broken lipsync
as well: http://imgur.com/R8O07MF (note that this method works on
android as well according to you).

I am not perfect either and there could really be a bug in opensles.c
but I looked, tested, and so far it still looks correct.

BTW there is only one place with rounding error in the code:

    *drift = (CLOCK_FREQ * OPENSLES_BUFLEN * st.count / 1000)
        + sys->samples * CLOCK_FREQ / sys->rate;

vlc_config.h:#define CLOCK_FREQ INT64_C(1000000)
st.count is integer between 0 and 255 so no rounding error here:

    *drift = X + sys->samples * 1000000 / sys->rate

sys->samples is an integer number of samples contained in each block, so
rounding error (which is inferior to 1 microsecond) doesn't accumulate
with time.


I definitely want to help find the problem, although I hope you
understand I am not convinced by a 3 lines summary that opensles is broken.

P.S. if I was wrong about opensles I won't be mad AT ALL.
Really trying to be objective here although I also want my little baby
opensles_android.c to be the default.

>  - Thumbnails are still hard to kill.

I need to have a fresh look at this, we probably missed something.