HLS/H264 stream crashes in libstagefright on Galaxy Nexus #2607
Comments
|
The content will play if MediaFormat.KEY_MAX_INPUT_SIZE is set to 0: |
alexbirkett
changed the title
|
It's a bit of a pain setting KEY_MAX_INPUT_SIZE to 0, because those classes make extensive use of private/protected/final modifiers etc... So a few classes need to be copied/extended. The solution works for me (I had an issue with Galaxy Nexus and HLS/Dash). Is this not a recognized issue that needs to be fixed in the main repository? I'm surprised that it doesn't get much attention, apparently. |
|
We should fix the issue for Galaxy Nexus specifically, as reported here. I'm not aware of other devices that see this kind of native crash. If you're aware of specific devices, please let us know. |
|
Apart from Galaxy Nexus I haven't seen another device personally (however, I have tested only 5 devices so far, and I don't want to let my users test it and wait for crash reports...). Found on the internet: You can also see it set to 0 in this project https://github.com/begeekmyfriend/yasea (with someone suggesting that it's probably in order to "fix MediaCodec bug on Android 4.1"). I tried to pin down the reason, but wasn't able to. A possible clue is that all of the mentioned devices have PowerVR GPU's (SGX540, SGX544MP3). References: |
If the codec isn't adaptive, there's no need to accommodate the width/height/input-size of streams that don't have the same resolution as the current stream. This is because we'll always need to instantiate a new codec anyway. Issue: #2607 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=155194458
|
I think the issue is less that we're setting KEY_MAX_INPUT_SIZE at all, and more that we're just setting the value to be unnecessarily high. Codecs on these API levels are not adaptive (i.e. cannot handle seamless resolution switching). Hence ExoPlayer releases the codec and instantiates a new instance when a resolution switch occurs, which is why resolution switching isn't completely seamless on older devices. However in V2 it appears we're setting KEY_MAX_INPUT_SIZE on the basis that the decoder might be adaptive. Importantly, this means we'll use the max input size for the highest resolution stream when configuring the codec for one of the lower resolutions. The codec may choose to instantiate more input buffers at lower resolutions than at higher ones, and hence when configuring for a lower resolution the issue may cause more memory to be allocated than would actually be needed to configure at the higher resolution. I've pushed a change that tweaks our logic to correctly take into account whether the decoder is adaptive. Please give it a try on the |
|
Thanks for the explanation and the change! I think it makes perfect sense. (I cannot comment on the code changes due to my limited knowledge here) It works on my Galaxy Nexus (and a few other devices that didn't have the issue in the first place). I find the playback indistinguishable from the "KEY_MAX_INPUT_SIZE==0" fix on the Nexus. I imagine that your fix may have advantages on other devices or different test videos, since it is cleaner. Once difference that I noticed is on the emulator. On some occasions I see improved performance in an emulator with API 17. Both fixes make the playback on one of my test videos pretty choppy (dropping almost half of the frames). But with your fix it plays smoothly sometimes. I'm still trying to figure out when and why. Of course, this is not a real issue if it's limited to the emulator. |
|
Great. We'll try and do a bugfix release sometime in the next couple of weeks (picking up this change and a couple of others). |
If the codec isn't adaptive, there's no need to accommodate the width/height/input-size of streams that don't have the same resolution as the current stream. This is because we'll always need to instantiate a new codec anyway. Issue: #2607 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=155194458
Issue description
HLS stream crashes on Samsung Galaxy Nexus running Android 4.2.2 with following backtrace
Reproduction steps
https://github.com/alexbirkett/ExoPlayer/tree/hls_bug_galaxy_nexusExpected results
Actual results
Link to test content
See
https://github.com/alexbirkett/ExoPlayer/tree/hls_bug_galaxy_nexusVersion of ExoPlayer being used
2.3.0
Device(s) and version(s) of Android being used
Galaxy Nexus 4.2.2
The text was updated successfully, but these errors were encountered: