MediaPlayer / MediaRecorder API - Playback and Recording from streams

[Gergely Kis]

Hi,

Is streams support for the record / playback API in the MediaPlayer /
MediaRecorder scheduled for the foreseeable future?

It seems that this is a feature that is really missing for a number of
reasons. Cupcake made an improvement on the audio front by allowing
access to raw PCM streams. However, this means that if you want to use
codecs other than PCM, you are on your own and the hardware
accelerated codecs are not available for you.

I posted the hack on my blog with the trick to allow recording to a
stream by passing a file descriptor to a socket or a pipe. This works,
although the recorded data does need some post processing.

For playback, the situation is not so nice, because the media player
engine assumes that the passed file descriptor is seekable, and
returns with an error if it is not.

This limitation is quickly becoming a problem. There are ISVs, who are
already hacking with internal native APIs to get their software work
on Android, and are ready to pay the price of maintenance hell...

I think that if this becomes standard practice with multimedia
applications, it will harm the whole platform, because regular users
will not make a distinction why their favorite application is not
working on their newest gadget.

So the concrete questions are:
1. Are you working on this? Is it scheduled to be included in Donut or
a future platform update?

2. If you are not working on it and the community would happen to
provide patches, would it be possible to include it in the official
"Donut" or a later official platform update?

3. If you would accept patches to be included in
$next_official_major_platform_update, are there any code freeze
deadlines that should be met by the community patches? I know you
can't say anything specific, but a "hurry up", "if it had been ready
for last friday" type of statement also helps. :)
Also, I know about the "jetlag" between the public and the internal
trees, but since this part of the code has not changed in the public
trees since March, and assuming that you are not working on this
internally, I think that the merging overhead would be reasonable.

4. Do you have a preferred API? My current plan would be to keep
things simple, and not change the Java API side. Instead change the
mediaplayer service to check if the passed file descriptor is
seekable, and add support for non-seekable file descriptors. In my
opinion this is a less intrusive change, Java APIs remain binary
compatible ... etc.

If such relatively simple and self-contained community improvement
could flow into the official platform, then we ("the community") could
start and think big, and work together to create frameworks for adding
new codecs, filters ... etc.

What do you think?

Best Regards,
Gergely

[Gergely Kis]

Hi,

Nobody is interested in this? (Which is surprising, since I get
questions about these issues almost every day...)

Or it is only summer / vacation time and the people who could comment
on this are on well-deserved vacation?

Best Regards,
Gergely

[dario]

Hello Gergely,

I'm certainly interested as I'm sure are others who as you mention are
resorting to native solutions and I may have to as well. Maybe we're
all just waiting on a comment from an authoritative source? ;-)

It wasn't clear from Google I/O conference why this is an issue in the
first place (I originally thought it was licensing) but apparently it
has just not been a priority as it was mentioned that it may have to
wait for the eclair release. Although my understanding now is that
before a release Google can cherry pick fixes from many branch
including master so technically we could add improvements there. (?)

I'm curious as to what other approaches others have taken if they
don't mind sharing. I like your proposal as it certainly would not
break the Java API but by the same token it's been just introduced
with cupcake and could use improvements e.g. adding ability to get an
audiotrack from the mediaplayer. In other words, perhaps avoid if
possible native code changes that could possibly delay this much
needed feature even further.

btw, what's the link to your blog?
Dario

On Aug 5, 2:16 pm, Gergely Kis <gergely....@gmail.com> wrote:
> Hi,
>
> Nobody is interested in this?  (Which is surprising, since I get
> questions about these issues almost every day...)
>
> Or it is only summer / vacation time and the people who could comment
> on this are on well-deserved vacation?
>
> Best Regards,
> Gergely
>

[Gergely Kis]

Hello Dario,

Thank you for your reply.

Let's hope that we get an authoritative answer. :)

I have not yet followed all the codepaths, but from what I have seen
until now, it should be relatively straightforward to implement my
proposal. With a slight abuse of the NDK, it might be possible to
release unofficial, application level support for Cupcake or even
Donut, if this change would only make it to Eclair.

About making API changes: probably the community should start
collecting requirements in an organized way, maybe into Jira or
b.android.com, so that they can be tracked.

My blog entry: http://www.mattakis.com/blog/kisg/20090708/broadcasting-video-with-android-without-writing-to-the-file-system

Best Regards,
Gergely

[RaviY]

I can put forth my thoughts ...

"you" is dangerous :). I am positive that this is -not- something that
the media folks are actively working on. And, for sure, this will not
be included in Donut. This is something that has been discussed, but
probably not prioritized.

>
> 2. If you are not working on it and the community would happen to
> provide patches, would it be possible to include it in the official
> "Donut"  or a later official platform update?

Any (well, almost) contribution that enhances the platform, without
breaking existing features, will surely be acknowledged and included.

>
> 3. If you would accept patches to be included in
> $next_official_major_platform_update, are there any code freeze
> deadlines that should be met by the community patches? I know you
> can't say anything specific, but a "hurry up", "if it had been ready
> for last friday" type of statement also helps. :)
> Also, I know about the "jetlag" between the public and the internal
> trees, but since this part of the code has not changed in the public
> trees since March, and assuming that you are not working on this
> internally, I think that the merging overhead would be reasonable.

I would have to defer to someone else for specifics, but the general
rule is to get it in at the earliest.

>
> 4. Do you have a preferred API? My current plan would be to keep
> things simple, and not change the Java API side. Instead change the
> mediaplayer service to check if the passed file descriptor is
> seekable, and add support for non-seekable file descriptors. In my
> opinion this is a less intrusive change, Java APIs remain binary
> compatible ... etc.

I would agree with this.