Android – hardware acceleration & MP4 first test

The very first version of Android hardware accelerated encoder utilizing MediaCodec is working. This is rough and not fit for release yet, but it proves the same simple concept implemented on iOS works on Android as well.

This ANE, though not guaranteed to work as fast as the iOS version at first, will be still a significant upgrade to the current software based Android ANE. Based on the initial test ($100 ASUS 4.3 tablet):


  • 1024×768 video of AIR stage recorded
  • Stage set to 20fps, no visible lag observed


  • 400×300 video of AIR stage recorded
  • Observed stage speed when recording drops to ~2-3fps

Finally, the video being recorded is MP4. No H.264 / AAC license issues since we’re using the device encoders instead of software encoders. Which means, the video can be replayed right away.

Otherwise, the whole concept of the ANE is similar to iOS – fullscreen init, capturing AIR’s OpenGL content directly via captureFullscreen and internally sending it straight to video. FlashyWrappers is using advanced features of Android 4.3+, such as render to video from OpenGL surface to achieve this. Finally, here’s a short test video to celebrate the first Android fully accelerated test!



Adobe fixed Flash Player bug!

Great news everyone! Adobe just fixed the Flash Player bug affecting FlashyWrappers since FP 16, which caused multithreading to not work(which broke realtime recording pretty much, and it also broke the online demo).  This fix comes also as a result of your votes, so thanks to that FlashyWrappers will work normally again since version 17.0.134!

This version is still not officially “out”, but it shouldn’t take long now. The most important thing is we know it’s coming. Time to return to Flash Player issues & requests!

FlashyWrappers 2.25 demo is out (full version coming soon)

Finally, FW 2.25 demo is out! Instead of releasing both demo and full versions at the same time, I’ve decided to rather wait for a bit seeing what the feedback would be to have a chance fixing any major issue possibly popping up.

It should only take few days now though in case nothing major appears. The links for new versions will be sent out to current FlashyWrappers customers. If we’re working closely together though and you’re being given updated FW there shouldn’t be much new for you.

So what’s new since the last release? This is the biggest update since FlashyWrappers 2 was released. Not only does it contain many iOS fixes (some of them major, ie. fixing app crashes), but also some new iOS features / optimizations. It’s not all about the iOS though. All desktop AIR platforms(Windows / Mac) and Flash Player are getting the promised OpenH264 codec, which means one important thing: MP4 support.

For Windows and Mac OpenH264 was linked in dynamically, which means you can download it from CISCO as well & avoid having to pay royalties for H.264. For Flash Player downloading is not possible as CISCO doesn’t provide any kind of OpenH264 “SWC”, so you will still fall into the licensing trap (for small apps it doesn’t mean automatically royalties payment though, be sure to reserach the H.264 subject if interested).

For all platforms, the API has changed and simplified slightly as well, wiping out the need to use some methods completely (see changelog), renaming others.

There’s still intensive work going on, primarily working on iOS as there are still some issues needing to be solved before it can be considered really stable. At the same time, my attention was turning towards Flash Player & dealing with video replays, BUT, then the Flash Player 16 bug happened and all of that lost priority until Adobe fixes its multithreading (very sad). If you didn’t vote yet for the bug mentioned in the previous post, please do! It’s very important to get this fix done.

So until Adobe fixes that, the next thing to do will be trying to recompile FFmpeg for Android with hardware acceleration support. This might be kind of a “shortcut” before introducing fully accelerated Android encoding. I’d say it could be at about 40-50% the encoding speed of iOS (compared to like 5-10% of what it is now), so it would still be a nice step.

Anyway, getting HW accelerated encoding is important for Android, also because this will produce native MP4 videos! Which will close MP4 support on all platforms.

Work is going on FlashyWrappers practically every day, it’s mostly bug fixing so not many updates are given on this blog, but be assured that the library is improved all the time. Also the website backend was improved (had to deploy totally new payment backend because of new EU VAT rules). That sort of work is not really visible but needs to happen to keep the  FlashyWrappers project going.

Get FW 2.25 demo at the product page (use the blue download button):

Here’s a detailed changelog of FW 2.25:

FlashyWrappers 2.25
- !! NEW CODECS SUPPORT ADDED: Flash Player, Windows, Mac - added support for: MP4 container, OpenH264 video, AAC audio. This means you can record MP4 files in AIR Windows, Mac and Flash Player as well (not Android, HW encoders which will come will output MP4's natively). Note, those are all BSD or LGPL codec implementations, however they still involve patents.
- New known issue: Flash Player 16 and above multithreading broken. There's a known bug breaking multithreading support in Flash Player 16+ for all Crossbridge apps/libs, including FlashyWrappers. Please force Adobe to fix this by voting here
- All platforms: Removed getVideoFramesSent(), added getEncodingProgress() which returns Number 0-1 to report on encoding progress.
- All platforms: setFrames() renamed to setTotalFrames(), and it's now needed only when in non-multithreaded mode to set in advance how many frames are expected. Multithreaded mode doesn't need this method anymore. iOS doesn't need this as well, like in previous versions
- All platforms: new method naming rules - methods exclusively available on platforms are named "platform_method()". For example "captureFullscreen()" becomes "iOS_captureFullscreen()", "saveToCameraRoll()" becomes "iOS_saveToCameraRoll()" and so on. This is part of the general API cleanup.
- All platforms(except iOS as there's iOS_captureFullscreen available): captureStage3D now has a new 2nd argument called "flushToEncoder", set to true by default. This simply means that captureStage3D() now captures frame as expected, without the need to call flushFrame() afterwards. If you still need to capture stage3D and MovieClip layer on top, in one frame, do it like this: captureStage3D(context3D, false); captureMC(YourMCLayer);. If you're only capturing Stage3D use captureStage3D(context3D) or captureStage3D(context3D, true).
- All platforms: In the wake of the change above with captureStage3D there's no need to expose flushFrame() anymore so it was switched from public to private. If you're using this with stage3D capturing simply erase this call
- Mac: Recompiled with the latest FFmpeg 2.5.4 & YASM support (everything should be faster due to optimizations)
- Mac: Fixed long issue when developing on Mac in Flash CSX IDE(and probably other IDE's). When IDE's were unzipping the ANE, its symlinks were being destroyed, causing undefined errors on launch. In standalone published builds this was fine. Now FlashyWrappers ANE automatically fixes the symlinks after launching from IDE on Mac. The only disadvantage is, the error still appears, but only once. If you rebuild and launch again everything should work just fine and the ANE will stay fixed (unless the IDE's cache is erased).
- iOS: Added 64-bit support, also added 64-bit FWSoundMixer beta inside this package for Hungry Hero iOS demo
- iOS: Added native method to mix audio tracks instead of addSoundtrack's current "Flash" method to avoid "extract()" method of Flash Sound class, which creates delay/freezeup on iOS. The method is still called addSoundTrack, just does the mixing differently internally on iOS now
- iOS: The addSoundtrack method also "knows" when you are calling it. If you call it at some point *after* starting video recording, it will insert itself at that time in the final video. You can stop it with stopSoundtrack() at any point while recording video, and it will cut the soundtrack in the resulting video accordingly. In other words, addSoundtrack on iOS is capable to start for example 20 seconds after starting video recording and end at 22 seconds, just based on the time you called them(addSoundtrack at 20secs, stopSoundtrack at 22secs after starting to record)
- iOS: Added cleaner handling of the final video encoding(export) interruption - after encodeIt is called and before video is exported. Before it would just throw error, now it detects suspension, cancels the encoding cleanly and throws 'encoding_cancel' event. You should deal with the event accordingly.
- iOS: Added more detailed logging in multiple sensitive places for easier debugging
- iOS: Fixed a bug when on second recording the fps of the video decreased in case the video fps was different from the stage fps
- iOS: Fixed some recoverable errors crashing the app anyway(throwing exception from completion block basically, which terminated the extension and the app as well)
- iOS: Fixed crashing when app was suspended while recording. FlashyWrappers stops and cleans up all recorders, and dispatches "stopped" event when the app is reactivated so that your app can properly deal with the unexpected stop instead of trying to resume recording
- iOS: Fixed crashing on saving videos when user didn't allow saving to camera roll. FlashyWrappers class now throws 'cameraroll_failed' if the permission wasn't given but you're still trying to save the video
- iOS: Fixed audio tracks possibly overflowing video track slightly, causing the final video export freeze or crash
- iOS: Fixed incorrectly set durations for audio tracks and video composition layer track, which might have caused random issues
- iOS: Added progress report method for the "encodeIt()" which can take a while (call myEncoder.getEncodingProgress() after encodeIt() until getting 'encoded' event)
- iOS: Added the plug for native microphone recording by the upcoming FWSoundMixer for iOS. FlashyWrappers is now looking for microphone m4a file to mix into the final video
- Internal: Merged Flash Player wrapper with iOS wrapper, will allow smoother & faster framework updates