Why should we be Stage-Fright Compliant.

[ajitabh saxena]

Hi All,
         I am in the process of adding hardware acceleration for media playback for my platform. I think the shortest route for me is to write a player at the same level as stage fright expose all the interfaces equivalent to that exposed by StageFright and then hook up my hardware below this player.
          I have been told that this is not the right approach and we should write OpenMAX IL layer to do this. My question is "Why?". If Google is not going to change StageFright interface to higher layer I should be fine writing my own StageFright, isn't it?

I really appreciate any information here.

Thanks,
- Ajitabh 

[ajitabh saxena]

HI There,
   I need to following the right design so please shed some light on this one.

Thanks,
AJ

[Gabriel M. Beddingfield]

I am not a lawyer... but yes, I believe that it is technically it's
possible for you to replace Stagefright on your device and still be able
to market it as "Android."

But here's why it's a bad idea:

1. It's freaking done. It's well tested, quality controlled, and
handles corner cases that you can't even imagine yet.

2. I wonder how easy it will be to pass CTS with your own
Stagefright implementation.

3. You have to implement more than just the MediaPlayer interface.
Several components (like Gallery player, camera) link directly to
Stagefright. So you also have to implement its binary interface.

4. Stagefright provides more than just "video." It is the focal
point of all things "media" -- audio, video, decoding, encoding,
A/V sync, etc. You'll have to re-implement all of that.

So, if you have a couple years to spend on this -- knock yourself out!
Otherwise, you can provide an OMX interface to your video layer and ship
somewhat sooner.

-gabriel

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

[Glenn Kasten]

See http://www.joelonsoftware.com/articles/fog0000000069.html

Of course, Stagefright itself is a rewrite of a previous media framework,

but even that replacement was done incrementally, not in one fell swoop. 

[vvravikanth .]

Hi ajitab,

Using OpenMAX IL enables you to expose your platform not only to StageFright or Android, but beyond. OpenMAX is one of the accepted and widely supported architecture for Multimedia Integration.  Hence for a long term platform evolution and design choice point of you it makes more sense to use OpenMAX IL.  Also you don't need to build a complete media player and integrating properly into the audio flinger (for audio routing) and surface flinger for video rendering situations (in embedde web browser case) etc. 

Hence, it makes more sense to expose your media assets to the upper level stacks through OpenMAX IL rather than building a complete media player, especially if you are starting from scratch.

But, if your platform is not for a standard Google Device (Mobile, Tablet) and  you already have a media player which is already hardware accelerated in another framework (say Gstreamer)  and if all the hardware acclerations are well proven, validated on your platform for your product family (say a TV platform) with all the audio/video randerings and routings are well baked, and you are trying to use Android as a SmartTV interface   then you could use use your own media player framework.   This also fits into the concept that - "Do not throw away your existing working code".

Of course you might run the risk of not getting a CTS compliance, if you want it to be a Tablet or a Phone device. 

You could follow a hybrid approach.  You could actually develop your own Media Player application, which will use your own Media Framework for those media codecs which are part of your framework (say MPEG-2 decode)  and use the StageFright for the standard usecases and codecs (non accelerated).  There are few DRM protected music player apps do this.  

So it all depends on what is your platform and what is the your current situation. 

I do agree with the recommendations 

     "don't re-invent code which is already working and tested"

     "Implement for more general platform than for a custom platform to target more application domains in future"

Regards,

Ravikanth