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 wrote:
> I can't think of any right
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 wrote:
> Hi Ravi,
>
> Regarding the missing Content-Length header, this was on different
> streams. The test cas
Here is the commit for the fix for high bitrate streaming issue:
http://android.git.kernel.org/?p=platform/external/opencore.git;a=commitdiff;h=9d144af75a60c4cf66e340bc9147e27e3d32a7b9
On May 13, 11:14 am, SDS wrote:
> Ravi, I'm not seeing your commit for the timing fix on
> android.git.kernel.or
Ravi, I'm not seeing your commit for the timing fix on
android.git.kernel.org. Am I looking in the wrong place?
On May 13, 10:47 am, SDS wrote:
> Hi Ravi,
>
> Regarding the missing Content-Length header, this was on different
> streams. The test case you have has the Content-Length header (whic
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
ov
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
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 observati
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 wrote:
> Hi,
>
> I was able to reproduce the problem, and it is definitely timing
> dependent. For the eclair codebase, I fo
Hi,
I was able to reproduce the problem, and it is definitely timing
dependent. For the eclair codebase, I found a problem in OpenCORE'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
On 22 nov, 18:28, Moto wrote:
> Range in http means start giving me the video data but start from x
> offset...
>
> Since the MediaPlayer already has this data downloaded up to x...
in fact my concern was more on why the players close the current
connection and opens a new connection while this c
Range in http means start giving me the video data but start from x
offset...
Since the MediaPlayer already has this data downloaded up to x...
-Moto
On Nov 20, 12:52 pm, "sbw.android" wrote:
> hi,
> when a video is played over http (progressivedownload), in some
> cases, the application stops
fala70 wrote:
> Anybody know if is possible use directly OpenCore from java or native
> with NDK ?
Multimedia functionality in the Android SDK is through the
android.media.* packages. I would not describe any of those as using
OpenCORE directly.
Questions about the NDK are best asked on a list
The current G1 software uses the OpenCORE software codecs except for H.
264 where the hardware codec is used.
On Mar 25, 3:38 am, wangxianjian8311 wrote:
> hi all!
> i want to know whether the g1 use the pv omxcore in opencore . if i do
> not have any hardware codec.
> if i just use the pv
13 matches
Mail list logo
