4

I've created a service that uses android.media.MediaPlayer, it works fine with 3.1+ devices and as expected doesn't fully work with older android versions as HTTPS and live streaming are not supported. There's no problem with local files.

What I want to do is to use android.media.MediaPlayer for 3.1+ devices and I'll have to create an alternative for others (base SDK is 8, Android 2.2).

I found a single somewhat useful article which I guess will not work for live-streams (as it records data to file) and I'm not really sure if it's a good approach for HTTPS progressive streaming.

I'd like to use a memory buffer with a limited size; caching of loaded content and ability to seek for location is not as important as ability to start playback at all. Unfortunately there's just no information I was able to find in regards to memory-bufering for android.media.MediaPlayer or any native alternative of android.media.MediaPlayer itself.

So the question is, are there any alternatives to android.media.MediaPlayer supporting low-level datasource (like stream or buffer) or any other workaround for HTTPS and live-streams ? If nothing like this is part of SDK 8+, maybe there's an opensource project to fork.

There's a bit similar question android mediaplayer alternative?, it asks for the features which I don't need and doesn't request the features I need.

Community
  • 1
  • 1
A-Live
  • 8,904
  • 2
  • 39
  • 74

1 Answers1

0

I don't know if you're still looking for a way to do this, but I'm guessing a local proxy server will solve your problem. See my answer here for a bit about that. Of course, as you noted, you should disable any seek/trickplay functionality unless you plan to implement it through the proxy. You should be able to implement the server so that the MediaPlayer only sees HTTP content. At that point it shouldn't have a problem.

Community
  • 1
  • 1
Dave
  • 4,282
  • 2
  • 19
  • 24
  • Thanks for the input. We ended up with "forcing" http for 2.2-3.1 devices by replacing URL's prefixes. The decision was based on a huge dev and support cost of other solutions and the fact that 3.1+ devices is a major part of target audience hardware, also the services we wanted to support accepted http replacements. – A-Live Sep 07 '13 at 14:44