The Flash instability we’ve discovered causing FW (and other Worker / Alchemy related code) to crash the Flash plugin was reportedly fixed by Adobe yesterday. No info yet as when this fix will be available in a public Flash Player release.
We think it might be available with FP 19 but are actively trying to find out from Adobe.
Just to confirm we know about this issue and are currently working with Adobe to fix – it’s high priority for them at this point.
The issue started appearing with 18.0.0.232 Flash update (and is further present in FP 19 beta). Unfortunately it causes apps running with FW to crash the whole Flash plugin, on OS X in particular (but we had a report from Windows as well).
We’ve been working hard since last Friday to provide a minimum crashing example to Adobe to accelerate the debug proccess – that example was sent yesterday and we’re still actively looking for any kind of workaround. Note that the crashing example does not contain any FlashyWrappers code. Which means it confirms, those crashes are not caused by FW in the first place (even if there was a faulty code though, Flash should not crash). So far the crashing seems to cease or at least minimize itself if FW is in non-realtime mode (or not using multithreading in 2.3). Also no crashes for earlier Flash Player versions.
This issue is pretty big so as you can imagine it has delayed the next FW 2.4 release until this is 100% resolved & confirmed to be resolved by our customers.
The bug should not affect AIR as it seems connected to Crossbridge (Alchemy) and Adobe’s changes to that in 18.0.0.232, where they were fixing other Alchemy related issues. Crossbridge is a cross-compiler used to build FW for Flash.
The next release of FW 2.4 is almost ready. The biggest blocker was the new FW for Android. Finally, the situation has improved as we’ve met our goal to reintroduce audio. We’ve managed to add audio recording from microphone and keep pretty solid fps (40-47 in 60fps app). The microphone recording is 100% native and seems much faster than the alternative of sending audio frames from AIR as on the other platforms (we’re still trying to find out why Android hates this method – it causes lags and freezes). FW gained about 10 fps just by going native with microphone recording.
In any case, to use this is again very simple & same as on the other platforms, just start FW with AUDIO_MICROPHONE mode.
The code was also refactored, taking advantage of multithreading when working with both audio and video encoders. The biggest thing thats left for Android is adding “non-realtime” mode support & fully resolving the audio. Also note that its still “alpha”, recommended to test but not into full release (we’ll be happy to work with you on stabilizing Android on your test devices though).
There are small changes on other platforms and to the API as well. Most notably “started” status event was added because start was made async. This eliminated some lag start was causing in Flash – most of it is executed on background thread now.
So to summarize, whats left is the usual finishing works(pretty much packaging everything up, update the docs, examples etc.) which will still take few days, but all the features for this release are closed!
After some initial feedback from the first prerelease, prerelease 2 is on its way. This will very likely be the last one before the final release. We’ve fixed the new Windows ANE’s crash on Windows 7 and added better logging to all FW platforms (logging level can also be set to verbose in prerelase 2). There will be an updated documentation describing how to do this. We have plans to improve the logging even more, but this is the first step to give users control over logging levels.
Another change coming by popular demand is the ability to force parts of FW behavior. In particular, the newly introduced realtime and non-realtime modes automatically switch various behaviors of FW. Most users probably won’t mind and will appreciate the simplicity compared to FW 2.3, but for advanced users this might not be great.
So we’ve made a compromise – the realtime and non-realtime mode of course stays, but you can now also force (non)realtime PTS calculations method or force framedropping off. This can be useful in situations such as:
The current focus before releasing FW2.4 Prerelease 2 is Android – getting the audio to work again and possibly increasing the overall performance.
Even after Android is a bit more stabilized, that won’t be “it”. There’s still so much work & improvements to do, including better / faster capture methods (particularly on mobile but even on desktop). So don’t think we’re satisfied with FlashyWrappers at this point.
Just to name a few other things on our TODO list: native audio capture, video replay component, Android fallback mechanisms, API improvements, custom classes for simple FW integration (one-liner webcam recording class) and of course stability and less bugs – this should improve all the time.