Video playback stops working on low end devices after multiple simultaneous videos played.
Categories
(Core :: Audio/Video: Playback, defect)
Tracking
()
People
(Reporter: joel_1st, Assigned: jhlin)
Details
(Whiteboard: [geckoview])
Attachments
(4 files)
After attempting to play multiple videos (either stored locally on the device, or files hosted on a remote server) Geckoview is no longer able to play videos (the <video> element is completely transparent) until the application process is closed and restarted. It should be noted that the 'media' process itself doesn't exit/die, it just stops logging to log cat/playing videos.
The easiest way to reproduce this is to run this html (after it performs the window.location.reload() 4-5 times the videos fail to show/log to logcat from that point onwards). You will also need to set up a permission delegate to allow auto play of videos :
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Video test</title>
<script>
setTimeout(() => {
window.location.reload()
}, 5000)
</script>
</head>
<body>
Testing testing
<video autoplay loop muted style="width: 400px" src="http://commondatastorage.googleapis.com/gtv-videos-bucket/sample/ForBiggerBlazes.mp4" ></video>
<video autoplay loop muted style="width: 400px" src="http://commondatastorage.googleapis.com/gtv-videos-bucket/sample/ForBiggerEscapes.mp4" ></video>
<video autoplay loop muted style="width: 400px" src="http://commondatastorage.googleapis.com/gtv-videos-bucket/sample/ForBiggerFun.mp4" ></video>
</body>
</html>
I was able to reproduce this on two low end devices running android 4.4.4 and android 5.1.1. The logs attached are from the Android 4.4.4 device.
The device specs (android 4.4.4): https://www.philips.com.au/p-p/55BDL5057P_00/signage-solutions-p-line-display
|
||
Updated•5 years ago
|
|
Assignee | |
Comment 1•5 years ago
|
||
Hi Joel,
Thanks a lot for reporting this bug.
The log shows OMX codec error 05-23 06:54:44.382 24062-24145/com.example.app:media E/ACodec: [OMX.rk.video_decoder.avc] ERROR(0x80001000) where 0x80001000 is OMX_ErrorInsufficientResources
It is my understanding that low end devices usually supported limited concurrent video decoders and it could be that the Philips display is just not powerful enough to handle this scenario. Could you please help to do more tests to help clarify if that's the case?
- instead of close and restart the application process, just close the tab and wait a few seconds after it's closed to ensure all existing video decoders are released. Then check if video works again
- play and reload repeatedly ONLY ONE video to make sure that no more than 2 active video decoders at the same time. See if the issue still happens
|
|
Assignee | |
Updated•5 years ago
|
|
Reporter | |
Comment 2•5 years ago
|
||
|
|
Reporter | |
Comment 3•5 years ago
•
|
||
(In reply to John Lin [:jhlin][:jolin] from comment #1)
Hello John,
No problem, and thanks for your reply.
Yes I agree that likely the issue is caused by the Phillips device not supporting that quantity of concurrent video decoders. I guess the question then becomes is there a way to recover from the issue without requiring a complete application restart?
In regards to the tests you requested:
- instead of close and restart the application process, just close the tab and wait a few seconds after it's closed to ensure all existing video decoders are released. Then check if video works again
This does not resolve the issue (the videos continue to not work). I have attempted this with the geckoview_example app (via tabs + with autoplay setting turned on) as well as a custom app where I clear/release the session, wait 5 seconds, and then create a new session. - play and reload repeatedly ONLY ONE video to make sure that no more than 2 active video decoders at the same time. See if the issue still happens
I was unable to reproduce the issue in this case on the phillips device (video playback continues to work), however on the 5.1.1 device I was able to reproduce this.
I'm not sure if I should create a new bug, but the logs on the 5.1.1 device are actually quite different to that of the Phillips device. The 5.1.1 device (http://www.rikomagic.com/en/product/showpro_id_59_pid_19.html) also appears to crash (the geckoview application) rather than just stop playing video. It may also be worth noting, that the 5.1.1 player handles playing the three videos in the HTML example above without any visible frameloss/jitter for over an hour. I have attached the logcat output above (unfortunately I don't have the complete output for the session, but hopefully it is of use).
|
|
Reporter | |
Comment 4•5 years ago
|
||
|
|
Reporter | |
Comment 5•5 years ago
|
||
(In reply to John Lin [:jhlin][:jolin] from comment #1)
As per my logcat attachment above:
I just reran the 1 video repeating html, on the 5.1.1 and this time the application did not crash, but it did stop playing videos after a couple of hours (the same behaviour as the initial bug report).
|
|
Assignee | |
Comment 6•5 years ago
|
||
Finally reproduced it on Moto G5 running Android 7 after failing on Pixel 2 running Android 9 for a while.
All logs show EMFILE (Too many open files) which suggests there are files not properly closed. It turns out SamplePool doesn't call SampleBuffer.dispose() in some cases. It seems on more recent Android versions, the system will close mmap()ed files when the MemoryFile object is GCed (probably because of [1]) so the file descriptors never exhaust. I'll upload a patch later to close those leakages.
[1] https://android.googlesource.com/platform/frameworks/base/+/dea6a027610951541981467276d8cd8ba8abc28b
|
|
Reporter | |
Comment 7•5 years ago
|
||
(In reply to John Lin [:jhlin][:jolin] from comment #6)
Finally reproduced it on Moto G5 running Android 7 after failing on Pixel 2 running Android 9 for a while.
All logs show
EMFILE (Too many open files)which suggests there are files not properly closed. It turns outSamplePooldoesn't callSampleBuffer.dispose()in some cases. It seems on more recent Android versions, the system will closemmap()ed files when theMemoryFileobject is GCed (probably because of [1]) so the file descriptors never exhaust. I'll upload a patch later to close those leakages.[1] https://android.googlesource.com/platform/frameworks/base/+/dea6a027610951541981467276d8cd8ba8abc28b
Great find! I'm glad you managed to reproduce it.
Thanks for looking into it.
|
|
Assignee | |
Comment 8•5 years ago
|
||
|
||
Updated•5 years ago
|
|
||
Comment 10•5 years ago
|
||
Backed out changeset f8d39b8ed5dc (bug 1640369) for android lint failure on SamplePool.java.
https://hg.mozilla.org/integration/autoland/rev/7cdc65d4dd1a4387b974cff9eb271d22861cd55b
Failure log:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=308372791&repo=autoland&lineNumber=1035
|
||
Comment 11•5 years ago
|
||
|
||
Comment 12•5 years ago
|
||
| bugherder | ||
|
||
Comment 13•5 years ago
|
||
John, would you mind uplifting this to beta?
|
|
Assignee | |
Comment 14•5 years ago
|
||
Comment on attachment 9160997 [details]
Bug 1640369 - always close memory files in case GC doesn't. r?agi
Beta/Release Uplift Approval Request
- User impact if declined: video playback stops working or browser crashes on older versions of Android.
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): The change is small and straightforward.
- String changes made/needed:
|
||
Comment 15•5 years ago
|
||
Comment on attachment 9160997 [details]
Bug 1640369 - always close memory files in case GC doesn't. r?agi
Approved for 79.0b5.
|
|
||
Comment 16•5 years ago
|
||
| bugherder uplift | ||
Description
•