Media Overlay behavior in Google Chrome and Android WebView

[tddpirate]

This issue is a Bug

Related issue(s) and/or pull request(s)

None.

Expected Behaviour

Automatic page flipping when the highlights reach the visible pages' end.

Observed behaviour

Media player stops playing at the pages' end.
When two pages are displayed, and when Media player reaches the first page's end, it continues with the second page. However when the second page ends, Media player stops.

Steps to reproduce

1. Check out readium-js-viewer and build it from the develop branch (I used commit d0769f0).
   Include the 'highlights' module using the following readium-js-viewer/readium-js/readium-shared-js/plugins/plugins-override.cson:
   plugins:
   include: [
   'highlights'
   ]
   exclude: [
   'example'
   ]

2. Start HTTP server using 'ntp run http' from readium-js-viewer.

3. Open a Fixed Layout EPUB with Media Overlay.

4. Activate the Media player.

Test file(s)

Private EPUB. Will test again if I know about a public EPUB which is Fixed Layout and with Media Overlay. This EPUB uses audio format MP3.
The output of the 'file' command:
Audio file with ID3 version 2.3.0, contains: MPEG ADTS, layer III, v1, 192 kbps, 44.1 kHz, JntStereo

Product

• readium-js-viewer, develop branch, commit d0769f0.
• Google Chrome Version 63.0.3239.84 (Official Build) (64-bit)
• Running under: Linux 4.9.0-0.bpo.3-amd64 Update Gemfile for a later version of eventmachine #1 SMP Debian 4.9.30-2+deb9u5~bpo8+1 (2017-09-28) x86_64 GNU/Linux (Debian Jessie, 8.9).

Additional information

When running the Readium engine inside Android WebView (Version 63.0.3239.111), Media player starts working but usually gets stuck after highlighting the first phrase.
When the Media player gets stuck, I see the following messages in the instrument's Logcat:
E/chromium: [ERROR:render_media_log.cc(30)] MediaEvent: MEDIA_ERROR_LOG_ENTRY {"error":"FFmpegDemuxer: open context failed"}
E/chromium: [ERROR:render_media_log.cc(30)] MediaEvent: PIPELINE_ERROR DEMUXER_ERROR_COULD_NOT_OPEN

The instrument in question is a Nexus 5, running Android 6.0.1
The audio_player actually tested on the Android is a modified version, but I saw similar behavior when trying an unmodified version.

[danielweck]

Back when the Media Overlay's HTML5 audio player (
https://github.com/readium/readium-shared-js/blob/develop/js/views/audio_player.js ) was being tested and improved for Android, the target browser engine was the early Chromium integration in KitKat 4.4. I remember facing all kinds of obscure problems related to timing, buffering, prefetching, seeking, etc. There are therefore Android-specific tweaks in the Javascript code, which were not needed on iOS (WebKit) and other desktop platforms. Based on your bug report, it would appear that this problem space must
be revisited once again :(

On the plus side, now that modern Android distributions use the same Chromium webview for both the Chrome web browser app and the system-level embedded webview API, we can probably test code changes using the cloud / web reader instead of a native app, which would make experimenting different audio playback strategies by trial and error a lot easier and quicker ((1) edit Javascript code + (2) reload the
cloud reader webpage).

At the moment, the time I can personally allocate to this is thin. We need to give this issue some visibility on the GitHub issue tracker so that (hopefully) other developers will join the maintenance /
troubleshooting effort.