Month: December 2015

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.