Playback of high bitrate FLAC streams may fail (pre Android-N) #4057
Comments
|
I've been sending you the music on the #4055 question. |
|
What device does this occur on? It looks likely that this is a device specific issue. Please capture and attach a full bug report, as is clearly requested in the issue template. |
|
there is a complete Log |
|
I'm fairly sure this is a device specific issue. You should report it to the device manufacturer. Do you know if the device also has |
|
I saw the flow of FLAC playing, and finally FLAC music was broadcast to Android system in audio_raw mode, and the Android system had a soft solution OMX.google.raw.decoder. Or the FLAC bitstream is too high to cause the Android system to fail to play, causing the internal error of the Android system. But I don't have the source code of Android system, so I can't provide more information to you. Can you use other machine to reappear the problem? |
|
there is a flac music。 |
|
The decoder that's failing is I think this issue is likely device specific. The device you're using looks pretty obscure to me. Is that accurate? |
|
The source code location to the problem is the 181 line of http://androidxref.com/4.4.4_r1/xref/frameworks/av/media/libstagefright/codecs/raw/SoftRaw.cpp, because the maximum length of inputBuffer allowed by the system is 37268, while the music one frame data is 49152, and how I allow the system to allow the maximum length inputBuffer is 64K, then the music is It can be played normally. So when ExoPlayer enters inputBuffer, it is necessary to judge the maximum inputbuffer allowed by the Android system. Only in this way, the system will not run out. This problem should be the common problem of Android. |
|
This issue is really confusing. The decoder with the issue in the initial report does not appear to be the decoder you're now referring to. Are there two issues that are being conflated here? The issue you refer to in your most recent post is fixed in more recent versions of Android (definitely by Nougat, I'm less sure about Marshmallow). |
|
The first thing to confirm is to use OMX.google.raw.decoder, because flacExtractor is to output a PCM flow to play the Android system. Maybe this native crash error Log output is problematic, showing gle.raw.decoder. This is not related to the Android version of the system. I checked the data. It looks like the latest version of Android system inputbuffer is also 32K. So in this case, either do not export PCM stream to Android system, or native crash will happen |
|
But the occurrence of crash is a disastrous consequence for app, so I suggest Exoplayer to judge the system inputbuffer. |
The problem isn't that the input buffer is only 32K. I took a more detailed look at This issue was fixed in Android N, in this change. So what we need to do to fix this issue, is for Marshmallow and earlier, either:
|
Playback will still fail if an input sample is larger than 32K, but will now fail gracefully. Issue: #4057 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=193951955
|
(1) is implemented as described in my response above. We've not done (2), and this is likely to be considered low priority. |
ojw28
changed the title
|
I don't think we're ever going to do (2). It's not high enough priority. @andrewlewis - Although for a different use case, is the audio offload work likely to produce a code path that can be used to bypass the decoder and "just fix this"? If not, I think we can close this. |
|
Yes. I experimented with using the raw decoder path for offload to keep the code simple, but unfortunately this used significantly more power than fully bypassing the |
|
This should be fixed by 5342576. |
I pulled the latest 2.7.2 code, which restored the bug of #3514, but it caused a more serious crash. When I played the FLAC music with larger rate, APP native crash occurred.
demo-withExtensions-debug.apk.zip
The text was updated successfully, but these errors were encountered: