readium / readium-sdk

A C++ ePub renderer SDK
BSD 3-Clause "New" or "Revised" License
385 stars 164 forks source link

Very large videos sometimes cannot render on Android #254

Open rkwright opened 7 years ago

rkwright commented 7 years ago

This issue is a Bug

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

None

Expected Behaviour

Should render (i.e. play) all valid videos even if very large

Observed behaviour

Instead, some very large videos apparently crash or throw an exception.

Steps to reproduce

  1. Load one of this EPUB with a video into Android
  2. Then do this
  3. etc.

    Test file(s)

See link above. In fact there are 3 videos in that folder the smallest loads without problems but the two larger (one compressed video the other un-compressed do not play).

Product

This same behaviour can apparently be reproduced with the same video resources in a web-page, which strongly suggests it is a problem with the underlying browser engine and/or platform.

rkwright commented 7 years ago

Reproduced in the Mantano application on Android by Jean-Marie Geffroy:

OK, en effet cela crashe bien... [Indeed, it certainly crashes]

8-03 20:07:29.016 23673-22898/? A/libc: Fatal signal 6 (SIGABRT), code -6 in tid 22898 (AsyncServer)
08-03 20:07:29.086 1320-1320/? I/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
08-03 20:07:29.086 1320-1320/? I/DEBUG: Build fingerprint:   'samsung/hltexx/hlte:5.0/LRX21V/N9005XXUGBOK6:user/release-keys'
08-03 20:07:29.086 1320-1320/? I/DEBUG: Revision: '8'
08-03 20:07:29.086 1320-1320/? I/DEBUG: ABI: 'arm'
08-03 20:07:29.086 1320-1320/? I/DEBUG: pid: 23673, tid: 22898, name: AsyncServer  >>> com.mantano.reader.android <<<
08-03 20:07:29.086 1320-1320/? I/DEBUG: signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
08-03 20:07:29.136 1320-1320/? I/DEBUG:     r0 00000000  r1 00005972  r2 00000006  r3 00000000
08-03 20:07:29.136 1320-1320/? I/DEBUG:     r4 975ffdb8  r5 00000006  r6 0000000c  r7 0000010c
08-03 20:07:29.136 1320-1320/? I/DEBUG:     r8 92653cc0  r9 96317d28  sl 00000000  fp 00000000
08-03 20:07:29.136 1320-1320/? I/DEBUG:     ip 00005972  sp 975f90a8  lr b6eebfd5  pc b6f0f1c0  cpsr 600f0010
08-03 20:07:29.136 1320-1320/? I/DEBUG: backtrace:
08-03 20:07:29.136 1320-1320/? I/DEBUG:     #00 pc 000371c0  /system/lib/libc.so (tgkill+12)
08-03 20:07:29.136 1320-1320/? I/DEBUG:     #01 pc 00013fd1  /system/lib/libc.so (pthread_kill+52)
08-03 20:07:29.136 1320-1320/? I/DEBUG:     #02 pc 00014bef  /system/lib/libc.so (raise+10)
08-03 20:07:29.136 1320-1320/? I/DEBUG:     #03 pc 00011531  /system/lib/libc.so (__libc_android_abort+36)
08-03 20:07:29.136 1320-1320/? I/DEBUG:     #04 pc 0000fcbc  /system/lib/libc.so (abort+4)
08-03 20:07:29.136 1320-1320/? I/DEBUG:     #05 pc 0018a36b   /data/app/com.mantano.reader.android-2/lib/arm/libepub3.so  (__gnu_cxx::__verbose_terminate_handler()+226)
08-03 20:07:29.136 1320-1320/? I/DEBUG:     #06 pc 00153c91  /data/app/com.mantano.reader.android-2/lib/arm/libepub3.so (__cxxabiv1::__terminate(void (*)())+4)
08-03 20:07:29.136 1320-1320/? I/DEBUG:     #07 pc 001530bf  /data/app/com.mantano.reader.android-2/lib/arm/libepub3.so
08-03 20:07:29.136 1320-1320/? I/DEBUG:     #08 pc 0015383f  /data/app/com.mantano.reader.android-2/lib/arm/libepub3.so
08-03 20:07:29.136 1320-1320/? I/DEBUG:     #09 pc 0019830b  /data/app/com.mantano.reader.android-2/lib/arm/libepub3.so
08-03 20:07:29.136 1320-1320/? I/DEBUG:     #10 pc 0019843b  /data/app/com.mantano.reader.android-2/lib/arm/libepub3.so (__gnu_Unwind_RaiseException+86)
08-03 20:07:29.136 1320-1320/? I/DEBUG:     #11 pc 00198b6f  /data/app/com.mantano.reader.android-2/lib/arm/libepub3.so (_Unwind_RaiseException+22)
danielweck commented 7 years ago

I am not able to reproduce this issue on my Android Nexus 6P (official OTA build of Nougat Android 7.0). I successfully tested the 3x provided video clips. I am getting weird error messages in the logcat, but this does not seem to affect playback / performance.

System.err: !!! ResourceInputStream int readX(int length, byte[] barray)
libepub3 [SDKLauncher-Android\readium-sdk\Platform\Android\epub3\src\maJNI --- GetBytes_ 1: 262144 - 262144
libepub3 [SDKLauncher-Android\readium-sdk\Platform\Android\epub3\src\maJNI --- GetBytes_ FilterChainByteStream
libepub3 [SDKLauncher-Android\readium-sdk\Platform\Android\epub3\src\maJNI --- GetBytes_ 2: 262144
rkwright commented 7 years ago

I tried both the HTML with video directly in the Chrome browser on Android 6.0.1 on a Nexus and in the current (0.25-alpha) build of our Launcher. Both work fine.

@"remi-praud": Can you verify the version of Android OS and Readium where you see the crash? Have you tried it in our SDKLauncher-Android or only in your app based on Readium?

remipraud commented 7 years ago

Here is a short list of several tests we made on the latest SDKLauncher-Android Git commit (2016-08-25) :

Nexus 10 - Android 4.4 : OK (2Go RAM) Nexus 6P - Android 7.0 : OK (Done by Daniel) (3Go RAM) Nexus 7 (2nd Gen) - Android 6.0 : OK (Done by Ric) (2Go RAM) Nexus 5 - Android 6.0 : KO (2Go RAM) Galaxy Tab S - Android 5.0 : KO (3Go RAM) Galaxy Tab 4 - Android 5.0 : KO (1.5Go RAM) LG G4 - Android 5.0 : OK (3Go RAM)

We have the same behavior on our custom reader.

To me it appears that it's not Core, memory or OS version dependent. Could it be manufacturer overlay dependent ?

rkwright commented 7 years ago

@remipraud I am assuming that KO means crash (as you may know KO is an acronym for "knockout" as in boxing) An apt description...

Certainly doesn't appear to seem clearly related to any of the factors you list. And most tablet producers, AFAIK, DO perform some customization on their software (sometimes a lot of customization). Do the ones that crash also crash when you play just the HTML and video in the browser?

danielweck commented 7 years ago

Well, the Nexus 5 (Android 6 Marshmallow), just like my Nexus 6P (Android 7 Nougat) is "vanilla" AOSP ROM, with no vendor framework customisations. Yet, your test on Nexus 5 failed. I will try on my wife's Nexus 5 at the nearest opportunity (probably in the second half of next week).

remipraud commented 7 years ago

Yes Ric, by KO I mean Crash. Thank you Daniel, Could it be a server streaming management issue ? It looks like the whole video is loaded at the beginning when it crashes.

danielweck commented 7 years ago

Yes, I never understand why in some cases the underlying media engine (on any OS platform) requests a single byte or the full binary length for a given audio/video asset, especially as subsequent HTTP requests are for partial byte ranges only. In ReadiumSDK we just "naively" build responses including large buffers of binary data without checking safety heuristics such as "maximum memory allocation" rules. But if we don't supply the requested amount of data, then the OS media backend fails to render the media resource. It's a catch-22 situation. Any ideas?

remipraud commented 7 years ago

After a long time, just an update to close this issue !! We finally found the bug and as expected it was not on our (Readium SDK or overlay) side.

The bug has been fixed for the latest WebView update, on September 20th, 2016. Can't be more detailed, but be aware that the webview has been updated and it now fixes this issue.

Latest Version: Android System WebView 53.0.2785.124 APK (Updated: September 20, 2016) Bug fixes and speedy performance improvements Old Version: Android System WebView 52.0.2743.98 APK (Updated: August 3, 2016) Bug fixes and speedy performance improvements

Once again thank you for your time !

danielweck commented 7 years ago

Hallelujah :)