Obsolete
Status Update
Comments
sa...@audials.com <sa...@audials.com> #2
Hi,
when a interface will be added to adjust the buffer size regarding your needs?
Thanks,
Gerhard Waidelich
when a interface will be added to adjust the buffer size regarding your needs?
Thanks,
Gerhard Waidelich
at...@gmail.com <at...@gmail.com> #3
I was able to cut down the buffering time by not returning Content-Length. It's still unnecessarily long but much less than before. Tested on 4.0.4 Samsung S3
lu...@gmail.com <lu...@gmail.com> #4
The minimal buffer size grew by the factor 8 in frameworks/base/media/libstagefright/include/NuCachedSource2.h
between Android 2.3.7 and 4.0.4
from:
kLowWaterThreshold = 512 * 1024,
to:
kDefaultLowWaterThreshold = 4 * 1024 * 1024,
between Android 2.3.7 and 4.0.4
from:
kLowWaterThreshold = 512 * 1024,
to:
kDefaultLowWaterThreshold = 4 * 1024 * 1024,
at...@gangverk.is <at...@gangverk.is> #5
[Comment deleted]
at...@gmail.com <at...@gmail.com> #6
We ended up playing back via AudioTrack instead. It's infuriating that you have to write your own "MediaPlayer" to be able to do something as simple as this but there it is.
ha...@gmail.com <ha...@gmail.com> #7
You cannot set your own buffering ?!?!?!?! I now get a 5 seconds delay on real time audio while using another player it is less than 1 second. Anyone has working code to fix this?
de...@gmail.com <de...@gmail.com> #8
Why hard-coded :-((((
ma...@gmail.com <ma...@gmail.com> #9
I have the same problem. In an environment with slow network but little video bandwidth if I have to wait 20 seconds. I need to lower the buffer anyway ... is there any way? Or I have to develop my own MediaPlayer in C. (NDK) only because of reducing buffer.
[Deleted User] <[Deleted User]> #11
It's interesting, #10. I'll have a look at it soon.
[Deleted User] <[Deleted User]> #12
[Comment deleted]
[Deleted User] <[Deleted User]> #13
#5, so, you abandoned stream proxy solution and implemented AudioTrack + MP3 decoder, is that correct? If so, can you please share which MP3 decoder you had used?
at...@gangverk.is <at...@gangverk.is> #14
#13 we used FFmpeg. I would seriously consider GStreamer if I was doing it today
[Deleted User] <[Deleted User]> #15
#14 Thanks for the answer. Why would you consider GStreamer instead of FFmpeg?
And has anyone here had a look at the new MediaCodec class which came with the Jelly Bean?
And has anyone here had a look at the new MediaCodec class which came with the Jelly Bean?
at...@gangverk.is <at...@gangverk.is> #16
#15 Mainly because it appears the good folks at GStreamer have put a lot of work into integrating with Android. The FFMPEG integration I had to write from scratch.
js...@gmail.com <js...@gmail.com> #17
In case anyone at Google is reading this. This MediaPlayer bug is still in KitKat. On my app, which streams live audio from an IceCast server, a 128kbit/sec stream buffers for 15 seconds before audio is played back. That's bad enough. What's even worse is that a 24kbit/sec stream from the same server takes nearly a full minute! One would expect that the lower bitrate streams to require *less* buffering. I'm guessing that the buffering expects a fixed number of bytes independent of the the actual stream bitrate. It would be nice to see this fixed some day and/or an option for developers to have control of this.
go...@gordonedwards.net <go...@gordonedwards.net> #18
Sad to say that this bug exists in Android "L" Preview as well.
ro...@gmail.com <ro...@gmail.com> #19
Ability to set/override default buffer sizes would be nice, as using a 32k AAC stream for a radio app it takes way to long to buffer when in reality it shouldn't
ba...@gmail.com <ba...@gmail.com> #20
Please fix this issue.. Provide an API for developers to set this buffering time
du...@gmail.com <du...@gmail.com> #21
please set automatically the buffer size depending on the stream bitrate
de...@pulsepoint.org <de...@pulsepoint.org> #22
Please fix buffer size to adjust to sample/bitrate. We encourage our media partners to send low bitrate to save bandwidth for our users. What happens is that you are penalized for doing so since a 44100Htz 128 kbps stream will play immediately, but a 22050Hz 16kbps feed will buffer for 40 seconds! This is completely counter-intuitive to users. The priority for this bug should be High.
cl...@gmail.com <cl...@gmail.com> #23
Can't believe it's been 2 years already and the problem persist. The stream I'm consuming takes 20 seconds to start, not acceptable at all.
pi...@gmail.com <pi...@gmail.com> #24
there isn't any solution yet? :(
ch...@gmail.com <ch...@gmail.com> #25
I think the solution is to implement your own MediaPlayer. Gstreamer might be a good alternative you should be able to (fairly) easily integrate and build upon.
en...@google.com <en...@google.com>
at...@gangverk.is <at...@gangverk.is> #26
You'd think we deserve at least a comment as to why this is now obsolete and from what version onwards is this fixed?
al...@gmail.com <al...@gmail.com> #27
So... is this fixed now?
Is there any sane solution for previous versions?
And from which version should we expect it to work?
Is there any sane solution for previous versions?
And from which version should we expect it to work?
cl...@gmail.com <cl...@gmail.com> #28
Project Member: please explain why this was marked as obsolete.
pi...@gmail.com <pi...@gmail.com> #29
Here's another one that wants to see this resolved :)
[Deleted User] <[Deleted User]> #30
Some explanation would be nice.
ch...@gmail.com <ch...@gmail.com> #31
Yes explanation plz. We're not sure if it's fixed in a previous or future release of Android or if we're supposed to not use MediaPlayer class (which would be a shame because then Google basically is saying "Yea we created this mediaplayer class but you should write your own" :)
ra...@gmail.com <ra...@gmail.com> #32
I would consider this particular issue obsolete if the code that is causing it has been deprecated. The NuPlayer found in Lollipop may not have this same issue? Google generally doesn't fix older versions of Android. When was the last time 4.0.x was given an update...? That just doesn't happen often. This means, for the bug to NOT be obsolete, the code would need to be active functionality in the current version of Android AND not be scheduled near term for replacement.
The code causing this defect very well could be no longer under development and in fact considered dead in Lollipop in favor of NuPlayer. Though... I question how much thought was put into question of obsolescence of this defect.
On a side note, e...@google.com has been systematically obsoleting old bugs.
The code causing this defect very well could be no longer under development and in fact considered dead in Lollipop in favor of NuPlayer. Though... I question how much thought was put into question of obsolescence of this defect.
On a side note, e...@google.com has been systematically obsoleting old bugs.
jm...@gmail.com <jm...@gmail.com> #33
"obsolete" is not fixed. google has a script that automatically marks bugs as obsolete when it decides the bug has been open too long. most likely no one has ever looked at this bug at all.
i've never seen anyone from google comment on a bug once it has been marked obsolete. anyone still hoping for an official response should open a new bug for this issue.
i suspect the only solution is going to be not to use MediaPlayer.
i've never seen anyone from google comment on a bug once it has been marked obsolete. anyone still hoping for an official response should open a new bug for this issue.
i suspect the only solution is going to be not to use MediaPlayer.
al...@gmail.com <al...@gmail.com> #34
#34 is right. I saw too many real issues automatically marked as obsolete without any comment from Google.
Alessandro
Alessandro
ol...@gmail.com <ol...@gmail.com> #35
this is still not fixed? hilarious!
na...@inf.co.il <na...@inf.co.il> #36
We are developing an android application for a big car company,
our application will be the only application for radio
in each and every manufactured car of this company (hundai size +-)
also integrating with Samsung-SmartTv, but thats less importent,
TO THE POINT, the folks that should fix this bug needs to wake up,
we have waiting times of 20 seconds on certain devices,
with no way to change the buffer.
In case someone there thought "Oh...that's not so important."
our application will be the only application for radio
in each and every manufactured car of this company (hundai size +-)
also integrating with Samsung-SmartTv, but thats less importent,
TO THE POINT, the folks that should fix this bug needs to wake up,
we have waiting times of 20 seconds on certain devices,
with no way to change the buffer.
In case someone there thought "Oh...that's not so important."
ch...@gmail.com <ch...@gmail.com> #37
For the Android API 16+ scenario, there's ExoPlayer which gives complete control over buffer size and basically everything else. Check it out! https://github.com/google/exoplayer
pa...@gmail.com <pa...@gmail.com> #38
developers should be able to control buffer
pa...@gmail.com <pa...@gmail.com> #39
why is this obsolete google?
ha...@gmail.com <ha...@gmail.com> #40
[Comment deleted]
Description
I'm using a socket as a proxy to the MediaPlayer so I can download and decrypt mp3 audio before writing it to the socket. This is similar to the example shown in the NPR news app however I'm using this for all Android version 2.1 - 4 atm.
NPR StreamProxy code -
My issue is that playback is fast for 2.1 - 2.3, but in Android 4.0 ICS the MediaPlayer buffers too much data before firing the onPrepared listener.
An example amount of data written to the Socket OutputStream before onPrepared():
On SGS2 with 2.3.4 - onPrepared() after ~ 133920 bytes
On Nexus S with 4.0.4 - onPrepared() after ~ 961930 bytes
This also occurs on the Galaxy Nexus.
Weirdly the 4.0 emulator doesn't buffer as much data as 4.0 devices. Anyone experience a similar issue with the MediaPlayer on ICS?
Here's how the proxy is writing to the socket. In this example it's from a CipherInputStream loaded from a file, but the same occurs when it's loaded from the HttpResponse.
final Socket client = (setup above)
// encrypted file input stream
final CipherInputStream inputStream = getInputStream(file);
// setup the socket output stream
final OutputStream output = client.getOutputStream();
// Writing the header
final String httpHeader = buildHttpHeader(file.length());
final byte[] buffer = httpHeader.getBytes("UTF-8");
output.write(buffer, 0, buffer.length);
int writtenBytes = 0;
int readBytes;
final byte[] buff = new byte[1024 * 12]; // 12 KB
while (mIsRunning && (readBytes = inputStream.read(buff)) != -1) {
output.write(buff, 0, readBytes);
writtenBytes += readBytes;
}
output.flush();
output.close();
The HTTP Headers that are written to the MediaPlayer before the audio..
private String buildHttpHeader(final int contentLength) {
final StringBuilder sb = new StringBuilder();
sb.append("HTTP/1.1 200 OK\r\n");
sb.append("Content-Length: ").append(contentLength).append("\r\n");
sb.append("Accept-Ranges: bytes\r\n" );
sb.append("Content-Type: audio/mpeg\r\n");
sb.append("Connection: close\r\n" );
sb.append("\r\n");
return sb.toString();
}
I've looked around for alternate implementations but as I have encrypted audio and the MediaPlayer does not support InputStreams as a data source my only option (I think..) is to use a proxy such as this.
Again, this is working fairly well Android 2.1 - 2.3 but in ICS the MediaPlayer is buffering a huge amount of this data before playing.
Further testing is showing that this is also an issue on the SGS2 once upgraded to Android 4.0.3. So it seems like the MediaPlayer's buffering implementation has changed significantly in 4.0. This is frustrating as the API provides no way to alter the behaviour.
Lookforward to hearing a response from the alliance.