Crashing competing media players on Android

Hardware-acceleration of video decoding on Android is really a mess...<p>In addition to the point of the article (asserting on a file that is not processed correctly, instead of slowly bailing out), every piece of CPU&#x2F;GPU behave differently and the Android test suite is extremely limited. On top of that, there are many layers (OMX IL, stagefright, MediaCodec, OMX AL, Java Media) that interact together in a complex way and everyone messes in those layers in a different way...<p>For example, fora long time, even after mediacodec API was out (4.1), you could get the data back from the codec, but the frame format was not standardized and there were no tests in the Android validation! So every GPU was doing something differently.<p>On top of that, the hw decoders don&#x27;t even give the profile and level they support, so you have to guess them.<p>And even those days, there is no way to get a YUV 420 surface that works on most devices, even when using KitKat APIs.<p>And so many joyful things :)

Honestly, media on Android is so bad it doesn&#x27;t need any help crashing. I worked on a large production app that played sound files in the background when running and about once in a thousand the Android media calls to play the file would just permanently hang. The only way to reliably handle media on Android is to have a watchdog process that checks when your own is hung in the Android code and kills and restarts it from saved state files. This was a call to play just never returning, so there was no error to catch or anything that could be done.

All video on Android seems to be a mess (except YouTube). For example, I can&#x27;t figure out what streaming video formats are supported, and&#x2F;or which apps work best. Does anyone have enough experience to say whether HLS or RTSP is better supported on Android?

&quot;Since your average Android application does not have sufficient permission to access &#x2F;dev&#x2F;* entries on your system, you must use a proxy called the mediaserver in order to communicate with HW codecs.&quot;<p>This is incorrect. Application access to hardware de&#x2F;encoders isn&#x27;t a matter of permissions. You can&#x27;t get at them directly because the api isn&#x27;t in the SDK&#x2F;NDK. However, if you&#x27;re willing to pull in headers from AOSP, and fool around with dlopen&#x2F;dlsym you can develop and build against libstagefright.