Audio Streaming and position (seekTo)

[finneapps]

Hi. I am working on an Android app that streams audio. I am currently using Android MediaPlayer. If I seek to a certain position in the audio file while streaming and at the same time seek to the same position in the same audio file that has been downloaded to my mac (using QuickTime Player), I don't come to the same audio position. The display says that I am at the same position (02:49:54) but the audio is not playing the same sound (the streaming server is 20-40 seconds behind the correct position). I tried the Exoplayer Demo app and replaced one of the static urls with my own streaming url. The same thing happens with Exoplayer. My friend that works as an iOS developer has no problem seeking to the right position while streaming (using the same streaming server). I also have the issue that sometimes the streaming stops seconds before the actual audio streaming is done (that makes sense if I am 20-40 seconds behind all the time). I hoped that Exoplayer would solve my issues, since the old MediaPlayer seems to be a bit buggy. Does anyone have any idea on why I am having these issues? I can provide you with a link to the streaming server.

[finneapps]

I can provide test project with a url to the streaming server. Start the streaming in Firefox/Chrome and start the streaming in the demo app. The audio position is not the same when you seek

[finneapps]

So it might be something with the khz setting. the audio file mix_197m47s (audio-joiner.com).mp3 works fine. I can seek to the correct postion. But if I execute this command to reduce the size of the mp3: lame -m m --preset cbr 48 mix_197m47s\ (audio-joiner.com).mp3 bomben.mp3

Then the output file has the "seekTo" error. Here is the mediainfo for the two files:

General Complete name : mix_197m47s (audio-joiner.com).mp3 Format : MPEG Audio File size : 362 MiB Duration : 3h 17mn Overall bit rate mode : Constant Overall bit rate : 256 Kbps

Audio Format : MPEG Audio Format version : Version 1 Format profile : Layer 3 Duration : 3h 18mn Bit rate mode : Constant Bit rate : 256 Kbps Channel(s) : 2 channels Sampling rate : 44.1 KHz Compression mode : Lossy Stream size : 362 MiB (100%)

finne$ mediainfo bomben.mp3 General Complete name : bomben.mp3 Format : MPEG Audio File size : 67.9 MiB Duration : 3h 17mn Overall bit rate mode : Constant Overall bit rate : 48.0 Kbps Writing library : LAME3.99r

Audio Format : MPEG Audio Format version : Version 1 Format profile : Layer 3 Duration : 3h 17mn Bit rate mode : Constant Bit rate : 48.0 Kbps Channel(s) : 1 channel Sampling rate : 32.0 KHz Compression mode : Lossy Stream size : 67.9 MiB (100%) Writing library : LAME3.99r Encoding settings : -m m -V 4 -q 3 -lowpass 11.3 -b 48

[finneapps]

I have fixed the issue by added -t to the command. If you add -t option then no extra LAME info is written to the audio file: Kaspers-MacBook-Pro:Bomben finne$ mediainfo bomben2.mp3 General Complete name : bomben2.mp3 Format : MPEG Audio File size : 67.9 MiB Duration : 3h 17mn Overall bit rate mode : Constant Overall bit rate : 48.0 Kbps

Audio Format : MPEG Audio Format version : Version 1 Format profile : Layer 3 Duration : 3h 17mn Bit rate mode : Constant Bit rate : 48.0 Kbps Channel(s) : 1 channel Sampling rate : 32.0 KHz Compression mode : Lossy Stream size : 67.9 MiB (100%)

But still this should be fixed, since it works fine on iOS. Now you can reproduce the error by running: lame -m m --preset cbr 48 source.mp3 output.mp3

and then to make it work:

lame -t -m m --preset cbr 48 source.mp3 output.mp3

[finneapps]

I have filed this bug also: https://code.google.com/p/android/issues/detail?id=158627&thanks=158627&ts=1425655288

[ojw28]

Thanks for this. Could you send a version of the problematic media file to olly.exoplayer@gmail.com?

[finneapps]

I have shared 2 audio files with you on Google Drive

[ojw28]

We have now added our own MP3 extractor (in dev). Using it, rather than relying on MediaExtractor, should resolve this issue. The samples with TYPE_MP3 in the demo app show how to do this. We'll push these changes to master next week.

[akhilspillai]

Hi, I think the issue still exists. When I play this song via exoplayer seek to doesn't seek to a very precise location. When I seek to say for example 8:29 which is 509 seconds(Which is a time important to me in the playback) exoplayer is 1 - 1.5 sec behind what I get when I play the same through sonic visualizer or any other music player. I am using Mp3Extractor and also tried downloading and playing the song from the external memory. Still the problem persists. As I am working on something which needs at least seconds level precision, exoplayer is not working out very well for me. Can anybody help me regarding this?

[ojw28]

The media linked in the post above isn't well suited for exact seeking to non-integer-percentage increments of the total media duration. This is due to the type of header that it uses to provide the seek information (XING), which only defines the byte offsets in the stream at integer-percentage positions. If you have control over the media then you should definitely prefer to package it as MP4 rather than MP3, which will resolve the issue that you're seeing (the MP4 container defines the byte offset of every sample in the stream).

Currently, ExoPlayer implements seeking with XING headers by interpolating between the nearest two integer-percentage positions, which is non-exact if the stream bitrate varies significantly between those points. An alternative might be to request data from the integer-percentage position that precedes the requested position and then drop media up to the exact position requested, however that would be inefficient for very long pieces of media where a single percentage of the stream might be quite large, so it's unclear whether that's actually good idea. We could consider doing that, but it's a separate discussion. Please open a new issue if you think it's a discussion that's worth having.

[akhilspillai]

Thank you for looking into the issue. Will raise a bug if we couldn't do anything else about it.

[hezhisu]

@akhilspillai do you have some idea about this issue, i have the same problem

[finneapps]

http://stackoverflow.com/questions/28749610/mediaplayer-exoplayer-and-audio-streaming Maybe this will help