Author: admin

Finally, FW SDK 2.6 is out! Changelog:

- Android: Attemp to fix an issue on some Android devices which could cause distorted texture both in video and on screen, when capturing in realtime mode(using GLES). This was very hard to reproduce so the fix isn't fixed with 100% confidence.
- Android: Fixed a random null error at the end of recording, which often froze your app before recording even started. This was caused by multithreading issues, which were fixed.
- Android: Fixed a random deadlock which caused freezing only when audio recording was enabled.
- Android: Added x86 target.
- iOS: Fixed reported ANE collision with other ANE's.
- iOS: Added x86 target for testing on iOS Simulator (software capture mode works reliably, hardware seems not not at this point).
- iOS: Refactored all of the code, watch out for possible bugs resulting from lots of code changes.
- OSX: Added a new ANE without symlinks(*_nosymlinks.ane). Use this when building from Adobe IDE's (such as Animate / Flash Pro). The ANE symlinks in the standard ANE are not resolved correctly on OSX, which causes build errors when debugging from IDE's. Use the normal ANE for building the production dmg installer.
- Android / iOS: Added realtime permissions for microphone for AIR 24 / Android 6.0 runtime permission changes.
- Android / iOS: Added realtime permissions for gallery saving for AIR 24 / Android 6.0.
- All platforms: Added dev build scripts for exampleCamera - you'll need to modify those(the paths inside in particular), but they might be handy for quickly building the example without relying on any particular IDE - you'll just need the AIR SDK.
- Known issue: Audio recording doesn't work with OGG recording in Flash, the encoder doesn't initialize properly, works only with AUDIO_OFF. However, MP4 for Flash works, so use that instead. If you need a working ogg, try reverting to FW 2.55.

This release fixes some tricky issues on Android, which were related to multithreading and appeared pretty randomly.

Looking foward – FW is using some pretty low level video SDK’s, which on iOS have been greatly simplified for real-time recording.  Android seems to be going the same direction, but they do not provide support for recording audio, which is a shame.

I’ve been waiting for the right moment and step away for a bit from the sometimes overly complex concept of FW to instead create light SDK’s only for AIR realtime mobile video recording.  This would simply capture what you see on the screen, no quality or other settings. On the other hand, it should “just work” as the high level Android / iOS video capture SDK’s are bound to be pretty stable.

I still plan to support the current FW at least during 2018, though.

As you’ve probably heard, Flash web player is going to be “dead” officially in couple years. I don’t think that cross-compiled JS is a viable alternative still. I’ll need full workers support to rebuild FW for web, last time I checked it was still in experimental phase. But, it should be technically possible, if the demand is there.

Right now, FW is on the edge, I’ll be supporting it and looking out for new opportunities, but I don’t plan to do anything rapid in terms of new features, except the possibility of FW Lite.

Have a great 2018!

This is a short update on FlashyWrappers. Everything is well, I’ve been just busy with fixing an old Android bug that has been with FW for a long time. I was never able to figure it out, because I’ve never been able to reproduce it on my devices.

Until now, on my new Lenovo phone. The bug causes the whole screen image (both in video and in app) to be horribly distorted. I think I’m reasonably close to fixing this (after spending hours and hours on that yesterday as well), and that will get me unstuck on other stuff!

Earlier, I’ve refactored FW for iOS completely, making it ready for the Unity port which is in the plans for all platforms.

Also be aware that the current zip package contains some bugs which were fixed in the meantime – more specifically FW for Windows contains a bug which causes random crashes during recording with audio(most visible on Windows 7 for some reason). If you plan to use FW 2.55 for Windows in a production environment, please get in touch and I’ll send you an updated ANE with bugfix.

Thanks for your patience!

After a pause, FW is getting back on track.

The support is resuming and there will be some improvements and new features pretty soon, though cleaning up the code is a priority right now, before fully resuming. Also FW will be ported to Unity3D.

One of the biggest ongoing pains used to be Android, but hopefully as the phones are improving and the obscure encoders implementations on older Android versions are becoming more rare, this issue auto corrected itself significantly during the last year.

Nevertheless, Android will still remain in alpha as we’ll work on making sure it goes into beta as fast as possible.

Hello everyone – Since last year there has been info on FW website mentioning the free support and version updates for 1 year as part of pricing. This info is not new, it has also been contained within the FW package license since FW 2.2.

So far, everyone had free access to the latest versions of FW – this will change with the next release though. For those purchasing FW 2.2 or later (released Oct 2014), the 1 year period was over few months ago.  We’ve still left offset of few months to cover for those first few months where that info might not have been apparent on the website even it was always contained inside the license.

That being said, all customers purchasing between end of Oct 2014 and end of March 2015 will need to re-purchase FW license to get access to new updates and high priority e-mail support.

All customers purchasing before Oct 2014(including), will get an additional extra year of free updates, but we won’t be able to support those customers after that period unless they re-purchase their licenses. There is no 1 year limit in the pre Oct-2014 licenses, but also no promised free updates.

We will be still supporting everyone with product-wide bugs of course, regardless if you re-purchase your license or not, as working product is in the best interest of everybody. You’ll still be able to use older FW versions without repurchasing new licenses, at your own risk however.

The info about how to login to the new update system will be emailed to all customers once the system is ready.

New version of FW was released, accumulating feedback we’ve had – this release is exclusively mobile focused and includes stability fixes / new features for both Android and iOS.

The most notable news about Android is, FW was tested on range of devices, and there has been an issue with its GL shaders discovered which prevented FW from working properly on number of devices. This has been fixed so FW should be more reliable on Android now.

While testing, there has been particular set of issues discovered, which have to do with Mediatek encoders (on devices from brands such as Meizu or Lenovo). Recording currently seems to work reliably only in 1280×720 resolution with this encoder. FW is therefore trying to detect this encoder automatically and force 1280×720 resolution. It also offers you a way to detect / react to this encoder from AS3 (maybe you’ll want to disable recording completely).

On iOS, a pretty significant memory leak has been fixed, photo permissions are now detectable and dispatched as events – for more changes and fixes see the changelog below and / or the updated API docs.

FlashyWrappers 2.55
------------------
- Android: Fixed an issue on various devices caused by shader optimizing out an attribute. The recording wouldn't work at all - the shader attributes are now assigned manually to prevent this from happening.
- Android: On devices using Mediatek encoder(such as Lenovo, Meizu), video encoding appears to work reliably only in 1280x720 with the current FW version. FW will force video dimensions to 1280x720 when this encoder is detected. You can adjust your video frames dimensions if needed, by using "if (myEncoder.getAndroidEncoderQuirks() == "quirk_mtk") {...}".
- Android: Fixed an issue with 2nd recording with microphone failing on some devices by completely releasing AudioRecorder instead of just stopping it.                                                                                                                                                                                                  
- Android / iOS: The video filename can be now modified easily on both platforms by setting myEncoder.mobileFilename = 'somefile.mp4';
- All platforms: FW now checks if the audio data is empty or not to prevent unexpected errors when sending audio data with zero length.
- All platforms: FW now checks if the ByteArray isn't overflowing in addVideoFrame to avoid subsequent issues in the encoders.
- All platforms: addSoundtrack on Android is being added at the start in non-realtime mode.
- iOS: Killed the video composing in final video recording phase, this significantly shortens the final phase time and also allows to finish the recording even when the app is suspended.
- iOS: As a result of the change above, the video bitrate setting has effect in realtime mode too (before it had effect only in non-realtime mode).
- iOS: Fixed a memory leak, after each recording approx +6-10MB of memory was consumed by texture cache which wasn't cleared properly. This could have resulted in low memory warnings and application shutdown if recording many times in row.
- iOS: Video foler is marked as preventBackup = true, to prevent backing it up to the iCloud.
- iOS: Added photo gallery permissions status events to allow you reading those permissions and displaying the permissions popup earlier than just before the video is trying to get saved. For more see API docs.

Hi everyone, new version of FlashyWrappers SDK is out. Apart from more fixes, the most notable new feature of this version allows you to capture rectangular video areas on iOS and Android. It also adds 64-bit support to OS X and first iteration of the on-line API docs.

64-bit OS X support

The 2.5 release also includes the 64-bit ANE build for Macs. It still includes 32-bit ANE build but this will most likely be discontinued unless there is a need to fallback to older AIR versions because of some issues in AIR 20.

Rectangular capture

This feature works in two modes and each method has its advantages and drawbacks.

1) Calculate

This method assumes your stage scale mode is set to NO_SCALE, and your stage alignment is TOP_LEFT. That is the biggest drawback of this method – however if you meet these criteria(should be true for all Starling and similar apps), this method should capture the exact area you specify.

2) Visual

This method doesn’t mind which stage scale or alignment mode is set. It places visual markers (2×2 mini rectangle), of the color you choose (it must be unique for at least couple of frames – up to 10 to be safe), at 2 corners of the capture area. This allows FW to measure the actual OpenGL coordinates despite all of the scaling / shifting of stage AIR might be doing, depending on the device, your stage size and so on.

Apart from plotting the markers for a short time, other drawbacks currently include the possibility of the markers deforming after AIR scales itself and the masurement not going exact – so you should always keep offsets around the capture area when using this method.

Note that there are some simple precautions done to prevent bad marker reading if its too scaled up or down, but it wasn’t fully tested on all possible devices so use the visual method with caution.

API docs

You can access the API docs online at http://flashywrappers.com/asdoc/  (or through the standard menu on the main website). This is automatically generated and it will be updated on each new release.

The API docs will hopefully fill in the blanks into the PDF docs, which are more explanatory and short examples but do not cover 100% of the API.

Full changelog:

FlashyWrappers 2.5
------------------
- All platforms: addSoundtrack now generates a warning when used in realtime mode. Using this method in realtime WILL cause desync. For any realtime & synced audio you should use FWSoundMixer. - DONE
- All platforms: setRealtime method added to avoid the need to set it in the start method.
- All platforms: The comments in AS3 wrapper were rewritten to be compatible with automatic documentation system & API docs added.
- All platforms: Added checks for dimensions being a multiply of 16, warning will be generated if it is not.
- All platforms: Added checks for valid H.264 resolutions, error will be thrown if the resolution is wrong.
- All platforms: Added checks for valid AAC bitrates, error will be thrown if the bitrate is wrong.
- Mac: Added OS X 64-bit ANE version for AIR 20+. The 32-bit ANE will be still kept in this release, for compatibility reasons, but beginning next release it won't be.
- Windows: Fixed a crash caused by addSoundtrack on Windows 7.
- Windows: Code was completely refactored.
- iOS: Fixed recording capturing black screen only on iOS (this was happening on random devices) with depthAndStencil and high resolution both enabled.
- Android: setDimensions now forces video resolution in relatime mode, exactly like on iOS. 
- iOS / Android: The "default" library was erased from iOS. For testing on desktop simply use FW for desktop.
- iOS / Android: Added setCaptureRectangle for mobile to capture rectangular area in two modes (visual and calculation method). See API docs for more details.

 

It’s the complete API doc, both offline and online – coming up soon!

Some of the other changes coming up:

– Capture rectangular area of target DisplayObject on mobile in OpenGL mode (to workaround the unability to capture DisplayObjects in this mode).

– API giving you better hints to avoid non-sensical or dangerous parameters when initializing the encoder.

– Video replay classes for desktop & mobile.

– Implementing new video recording API’s for mobile allowing you to leverage the latest in mobile video recording on iOS / Android while still supporting the low-level video recording API’s.

– Better audio support through FWSoundMixer & addAudioSoundtrack

– Improving Android.

And more…

All the best with your projects for the next year to everyone, especially all of our  FlashyWrappers customers!

Thanks to your support FlashyWrappers is alive and well, and will continue so through to the next year. Apologies if the work has been a bit slower these last two weeks – the Christmas period had its impact.

Rest assured there’s already a changelog for FW 2.5 existing, with 19 pre-written changes / fixes / new features which should make it in the next release. Also keep in mind we do listen to your feedback and sometimes the new features we’re adding come from merely you asking questions. For example, there has been a question / request if the FWSoundMixer implements only some of the SoundMixer / Sound methods – and it really doesn’t implement almost anything. Seeing how difficult it is with enabling native audio recording we’re thinking that it would be actually a good focus to instead finish FWSoundMixer properly by adding some more important methods to control the volume for example. Native audio recording is still on our list but seeing its not what most of our customers need (usually microphone or soundmixer are enough), it’s not as high priority as it used to be.  So here you can see just one example of how even your questions can affect our thinking / focus.

Granted, sometimes we need to push your requests or questions for later as there might be higher priority work to be done – its nothing personal though, many times its simply because more people request something else, or something more serious is needed for the product in the big picture – or simply, it doesn’t align with the general direction and goals we see as a good trend for our SDK.

The next release is targeted at sometime in January, and will be focused on further tightening the reliability, ease of use and getting rid some of the known frustrations. Also we’ll be on the lookout to improve Android support all the time.  The Mac / iOS is about to get internal API overhaul too, similar to what Android got this / last month (you won’t see much of that externally though).

Overall, we’ll try to bring much more polished experience and make the SDK the best possible video encoding SDK for AIR / Flash possible. Hopefully, by the end of next year there will be nothing major to add or change and we can just expand on extra features such as integrated video replays and seamless support for the new video API’s.

See you in 2016!

 

The latest release fixes some issues found by customers in the 2.4 release. It also features refactored Android ANE. All customers can use the links they used for purchasing to obtain v2.45.

A bit of non-feature at first: We’ve added full ReplayKit support for iOS, but found out AIR for Windows still doesn’t support iOS9 frameworks so decided not to add the AS3 endpoints (otherwise Windows users would be unable to compile with the new iOS ANE).

One of the more notable features which were added in this release are a new audio recording mode in Flash trying to address desync, which happens only in Flash and only on some hardware based on what we’ve heard. As this appears hardware / Flash related it might not fix the issue but the latest known “pain” of the realtime Flash recorder was the audio. On all other platforms, the audio is using system time for its timestamps, but in Flash this was causing issues, as the Flash timer is not accurate and basically depends on fps. That’s why the Flash recorder was using a mix of realtime timestamps for video but monotonic timestamps for audio. That might have been a cause of audio desync under some conditions where audio starts arriving too early / late. The new experimental recording mode still uses monotonic timestamps but also compares with system time and when the delta is too high it corrects the monotonic timestamps to prevent them drifting apart too much.

In case the desync issue is in how Flash works with the microphone on a given platform, this won’t fix anything unfortunately(there is no way FW can “inspect” the audio data and determine if its content is too “late” or “early” – its just bunch of numbers to FW). It can fix the case where the audio as a whole was starting to come in too late / early since the command to record was given.

A new iOS feature which should be ported to Android in the next release is being able to set any video resolution, in realtime mode. Until now, the video resolution was hardcoded to whatever AIR asked iOS to use for your app (on iPad typically 1024×768). In case of high resolution (2048×1536 in this case) however, the videos were still recorded at 1024×768 by FW. This is no longer the case and the videos will be recorded at 2048×1536. Plus, you can now override the resolution with setDimensions like in non-realtime. You can use almost any resolution – iOS might not like certain dimensions and refuse to encode or save to camera roll. To be safe make sure your dimensions can be divided by 16.

This release was otherwise mostly about maintenance after the exhausting 3-phase 2.4 release. We’ll still do that during 2016 of course plus finally get to add support classes for AIR, such as a class for easily recording a webcam on all platforms or replaying recorded videos. We’ll also finally join all the platforms into a single ANE (that is an understandable request we’ve heard several times). Mac 64 bit support is also high in priorities(we are aware of this for AIR 20+). More work on Android is expected as well. As always let us know what you personally would like to see in the following releases –

The v2.45 changelog:

- Flash: Added a new, more robust audio recording mode, which uses both "assumed" and "realtime" timestamps to determine the pts. This is an experimental mode trying to get rid of random audio desync reported in Flash. To use the mode call myEncoder.setAudioRealtime(true).
- Flash: Fixed too early initialization issue both in realtime and non-realtime mode, resulting in number of other issues, including audio soundtrack not being added or other unpredictable behavior.
- Flash (MP4's only): After encoding, the moov atom in mp4's is being moved to the start now, allowing the recorded videos to be streamable (using ffmpeg's "faststart" option).
- Mac / Flash: (non-realtime) Fixed addSoundtrack issue with calculating pts resulting in the audio tack not being hearable.             
- iOS: Implemented the new ReplayKit framework, unfortunately because AIR for Windows doesn't support it yet we didn't enable it in this version(otherwise you would be unable to build any apps on Windows AIR with our ANE).
- iOS: Fixed a bug with ANE reporting "stopped" event even when the app was minimized but no recording was going on.
- iOS: iOS realtime mode respects resolution now. If you publish your AIR project in highres, normally it was scaled down(for example 2048x1536 was scaled down to 1024x768 video). Now, the video will be truly recorded at 2048x1536 - you can still force downscaling however through setDimensions(1024x768).
- iOS: saveToGallery doesn't create the default "FlashyWrappers" album anymore, when no arguments are specified in saveToGallery. It behaves like iOS_saveToCameraRoll did now instead without arguments
- Windows: better error logging added to addVideoFrame based on some reports with Windows encoder issues
- Android: refactored all of the source code into new classes, moved the video recorder into its own GLES context to avoid switching contexts.
- Android: errors are detected when starting FW and on any error FW forces the recording to not continue (it returns instantly from the FW recording method if you're still trying to call it). This is trying to prevent the app from breaking while recording and also for a cleaner exit.
- Android: saveToGallery without arguments will use "Videos" as default album name now
- Android: fixed a freeze which would sometimes happen when finishing audio thread because there were no input buffers available and FW would way indefinitely for a free buffer, to send the "finishing" audio data. Additional drain was added to fix the issue.

Even the main focus is Android these days, we’re not forgetting iOS either. In iOS 9, a new video recording API was introduced, called ReplayKit. We are preparing support for this API. The main advantage, besides the ease of use when implementing the native code (which is not a concern for AIR devs anyway), is full audio recording support (at least if the videos we saw don’t lie). It should be possible to include microphone as well, but otherwise what the game is playing out of speakers appears to be recorded in the video.

ReplayKit is completely separate from the FW video capture path which uses AVFoundation & OpenGL ES, so there are some disadvantages as well. You won’t be able to configure the video quality or resolution (this is also an upcoming feature of the next FW version, see below).

The biggest downside however appers to be the inability to access the video mp4 file (or the ByteArray with the video as a result). Instead, Apple offers a default dialog to share the video to social networks. Thats why ReplayKit cannot fully replace FW for now. We’ll be offering it only as part of FW iOS ANE, for those who prefer to capture audio without FWSoundMixer and don’t mind the missing video file access (& are happy with the social sharing support).

Another big downside currently has to do with AIR. AIR doesn’t support ReplayKit framework in its latest version still. Even it is possible to workaround this on Mac, you can’t workaround that on Windows. Likely Adobe will need to rebuild their version of ld64 Apple linker, as the frameworks including ReplayKit now work with different stub formats than they used to.

We’ll see how long this takes, hopefully not too long. In the meantime it will be possible to build ReplayKit supported projects only on Mac.

Custom resolutions

As mentioned, FW iOS will start supporting custom resolutions when recording in realtime mode. Until now, you were stuck with harcoded resolution depending on what AIR requested from iOS. This was also a default when recording from highres apps. But not anymore – if your app is highres and you wish to record for example to 1920 x 1080 – or, on the other hand, you wish to make the final video really lowres (400 x 300) to send it faster over the network, you are free to do so. Just specify the dimensions as usual with setDimensions(w, h) or within start and FW will scale the video as needed.

If you don’t specify any dimensions FW will behave as usual to not break backward compatibility.