We've run into an issue where a CTS test case is failing because seeks
do not happen immediately. I think the test case should be updated,
but how do I go about that?
Details...
This is the test case:
run cts -c android.media.cts.MediaPlayerTest -m
testVideoSurfaceResetting
After playing for some time, the test then seeks (without stopping) to
1.5 sec in the media. It then sleeps for .5 sec. It then checks that
the media is at 2.0 sec (+/- 150 ms). However, the audio playback
latency on our device is around 320 ms, and so we fail this test case.
The latency makes a difference because the hardware and software
fifo's between stagefright and the speakers are full... with about 320
ms of data. If we start writing /new/ data now, it will be 320 ms
before it is heard.[1] In fact, I believe the 150 ms tolerance is
because of AOSP's default latency... which is 120-160 ms.
Possible resolutions:
a. CTS test should stop, seek, start.
b. StageFright should flush buffers on seek.[2] In practice we can
only flush half, which makes our latency compensation less accurate.
c. Force our latency compensation logic to lie after a seek.
I would prefer (a) because I think the test case is a little naive.
The docs for MediaPlayer[3] seekTo() even warn about this. If the
test case were to be modified to wait for completion of the seek, then
the tolerance could be reduced and the work-arounds (b and c) can be
avoided.
N.B. In my sandbox, there seem to be some cases where OnSeekComplete
is not firing after seekTo(). I've not determined why.
-gabriel
[1] We also have some enhancements that compensate for the latency
within about 40 ms.
[2] libstagefright's AudioPlayer does call flush() on seek, but
because the audio is playing it doesn't actually do anything.
[3] http://developer.android.com/reference/android/media/MediaPlayer.html
--
unsubscribe: [email protected]
website: http://groups.google.com/group/android-porting
