Understood Ravi, was just answering your questions from earlier.

We'll seek an alternative solutions for streaming MP3's over HTTP that
doesn't involve MediaPlayer or OpenCore engine...

Thanks again for your attention to this matter.

On May 14, 8:32 am, rktb <yend...@pv.com> wrote:
> I can't think of any right now. Unfortunately, I can't spend a lot of
> time on an older codebase, especially if the problem has been fixed on
> the latest.
>
> -Ravi
>
> On May 13, 9:47 am, SDS <sstrea...@gmail.com> wrote:
>
>
>
> > Hi Ravi,
>
> > Regarding the missing Content-Length header, this was on different
> > streams.  The test case you have has the Content-Length header (which
> > is one reason I provided that test case specifically, to simplify the
> > issue).
>
> > Believe it or not, I'm having success with 128kbps MP3's to the device
> > over 3G.  Same goes with 192kbps and 256kbps.  At 320kbps the problem
> > becomes apparent again.  What I find most strange about this is that
> > the test case I sent you was at 192kbps but I'm still having problems
> > with that particular track.  The tracks I'm tsting with today are
> > being transcoded on the fly by FFmpeg, so bitrate aside the encoder
> > may be the notable difference there.
>
> > Your thoughts?
>
> > On May 12, 10:01 pm, rktb <yend...@pv.com> wrote:
>
> > > Hi,
>
> > > I was actually able to see the content length in the http response.
> > > Here is a snippet from my log:
> > > PVLOG:TID(0xe9bf8):Time=830:HttpParsingBasicObject::parseResponse()
> > > file size = 5346201
>
> > > But, yes, the auto-pause/auto-resume does indeed depend on whether or
> > > not the content length is present in the header.
>
> > > If you try to put the newOpenCOREcode under your application, you
> > > would need to write a new MIO [media input/output component] that
> > > would dump the raw PCM data back to the java layer, which would then
> > > use the AudioTrack API to render the data. But, I think that this
> > > would be a bit involving.
>
> > > I am still trying to think what other properties could be a factor.
> > > Did you try:
> > > - "smaller" content?
> > > - lower bitrate content?
>
> > > -Ravi
>
> > > On May 12, 8:39 pm, SDS <sstrea...@gmail.com> wrote:
>
> > > > Hi Ravi,
>
> > > > Thank you kindly for your responses.
>
> > > > I've tried MP3 streams without ID3v2, but I should point out a
> > > > difference that may or may not be significant in the context of this
> > > > defect.  The HTTP headers for the MP3 streams were without a Content-
> > > > Length header.  In terms of the initial observations I reported, the
> > > > intermittent behavior is identical but without the increasing buffer %
> > > > callbacks.  I'm assuming this is expected, but I'll let you decide.
>
> > > > Regarding deployment of the latest code forOpenCOREwith our
> > > > application, so that we can take advantage of your fix, what would be
> > > > involved from a development perspective, and how would you compare
> > > > that level of effort with us rolling our own HTTP streaming / MP3
> > > > decoding framework using native code?
>
> > > > On May 12, 9:33 pm, rktb <yend...@pv.com> wrote:
>
> > > > > One thing to try is to encode a clip without Id3v2, and see the
> > > > > behavior. That would reduce the probability of "insufficient data" by
> > > > > a bit.
>
> > > > > -Ravi
>
> > > > > On May 12, 5:02 pm, rktb <yend...@pv.com> wrote:
>
> > > > > > Hi,
>
> > > > > > I was able to reproduce the problem, and it is definitely timing
> > > > > > dependent. For the eclair codebase, I found a problem inOpenCORE's
> > > > > > mp3 parser node. That, however, has been fixed on the latest 
> > > > > > codebase
> > > > > > available at kernel.org.
>
> > > > > > Now, for applications that are being written for existing Android 
> > > > > > SDK
> > > > > > releases, I don't have a way out yet.
>
> > > > > > -Ravi
>
> > > > > > On May 12, 12:47 pm, SDS <sstrea...@gmail.com> wrote:
>
> > > > > > > I’m experiencing an intermittent and very frustrating issue with
> > > > > > > MediaPlayer on Android when streaming MP3 over HTTP.  I’ve done as
> > > > > > > much research and debugging as I possibly can to try and find a
> > > > > > > solution, but am coming up short.  I can’t find reference to this
> > > > > > > issue anywhere, including b.android.com.
>
> > > > > > > Essentially, what’s happening is MediaPlayer will not come out of 
> > > > > > > the
> > > > > > > preparing state.  The device is receiving audio data during this 
> > > > > > > time,
> > > > > > > as indicated by network sniffs and the MediaPlayer buffering 
> > > > > > > callback
> > > > > > > being invoked repeatedly with increasing percentage values, but
> > > > > > > eventually the buffer appears to become full and stops receiving.
> > > > > > > Because prepare() never returns, or more accurately when
> > > > > > > prepareAsync() is used and the onPrepared callback is never 
> > > > > > > invoked,
> > > > > > > and neither the onError() nor onInfo() callbacks are invoked, the
> > > > > > > application can neither call MediaPlayer.start() nor make any 
> > > > > > > sort of
> > > > > > > recovery.
>
> > > > > > > Other notable observations:
>
> > > > > > > -       The problem is intermittent, meaning that subsequent 
> > > > > > > attempts to
> > > > > > > play the exact same MP3 stream from the exact same server may 
> > > > > > > exhibit
> > > > > > > this behavior or not
> > > > > > > -       The problem seems to be exasperated when the device is 
> > > > > > > connected via
> > > > > > > 3G versus wifi
> > > > > > > -       The problem occurs on different MP3’s encoded by 
> > > > > > > different software
> > > > > > > -       The problem occurs when streaming from different HTTP 
> > > > > > > servers
> > > > > > > -       The problem cannot be reproduced on any of the Android 
> > > > > > > SDK emulators
> > > > > > > -       The problem can be reproduced on the HTC Incredible, 
> > > > > > > Verizon
> > > > > > > Motorola DROID, and HTC Touch
> > > > > > > -       When MediaPlayer successfully returns from the preparing 
> > > > > > > state,
> > > > > > > there is an info message (what=1, extra=44) received.  This info
> > > > > > > message is not received during the problematic case.
>
> > > > > > > Anyone ever experienced this, or even find a solution?
>
> > > > > > > Thank you in advance.
>
> > > > > > > --
> > > > > > > You received this message because you are subscribed to the Google
> > > > > > > Groups "Android Developers" group.
> > > > > > > To post to this group, send email to 
> > > > > > > android-developers@googlegroups.com
> > > > > > > To unsubscribe from this group, send email to
> > > > > > > android-developers+unsubscr...@googlegroups.com
> > > > > > > For more options, visit this group 
> > > > > > > athttp://groups.google.com/group/android-developers?hl=en
>
> > > > > > --
> > > > > > You received this message because you are subscribed to the Google
> > > > > > Groups "Android Developers" group.
> > > > > > To post to this group, send email to 
> > > > > > android-developers@googlegroups.com
> > > > > > To unsubscribe from this group, send email to
> > > > > > android-developers+unsubscr...@googlegroups.com
> > > > > > For more options, visit this group 
> > > > > > athttp://groups.google.com/group/android-developers?hl=en
>
> > > > > --
> > > > > You received this message because you are subscribed to the Google
> > > > > Groups "Android Developers" group.
> > > > > To post to this group, send email to 
> > > > > android-developers@googlegroups.com
> > > > > To unsubscribe from this group, send email to
> > > > > android-developers+unsubscr...@googlegroups.com
> > > > > For more options, visit this group 
> > > > > athttp://groups.google.com/group/android-developers?hl=en
>
> > > > --
> > > > You received this message because you are subscribed to the Google
> > > > Groups "Android Developers" group.
> > > > To post to this group, send email to android-developers@googlegroups.com
> > > > To unsubscribe from this group, send email to
> > > > android-developers+unsubscr...@googlegroups.com
> > > > For more options, visit this group 
> > > > athttp://groups.google.com/group/android-developers?hl=en
>
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "Android Developers" group.
> > > To post to this group, send email to android-developers@googlegroups.com
> > > To unsubscribe from this group, send email to
> > > android-developers+unsubscr...@googlegroups.com
> > > For more options, visit this group 
> > > athttp://groups.google.com/group/android-developers?hl=en
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Android Developers" group.
> > To post to this group, send email to android-developers@googlegroups.com
> > To unsubscribe from this group, send email to
> > android-developers+unsubscr...@googlegroups.com
> > For more options, visit this group 
> > athttp://groups.google.com/group/android-developers?hl=en
>
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscr...@googlegroups.com
> For more options, visit this group 
> athttp://groups.google.com/group/android-developers?hl=en

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Reply via email to