YuMeWrapper is an ActionScript 3 wrapper around YuMe Network’s library SWF for publishers. It provides a consistent abstraction of their ActionScript 3 SDK, as well as much more thorough documentation of the YuMe SDK than what YuMe themselves provide.
This wrapper supports all of the standard YuMe library functionality, including pre-roll, mid-roll, overlay, and post-roll advertisements, with two exceptions: midroll playlist prefetching is not supported, and extra fullscreen options are not supported. It also provides loads of additional fixes and functionality that does not exist in the YuMe library core.
If you are trying to use asdoc and all it does is spit out a completely useless “Error: null”, check to make sure that there are no Mac OS resource fork files (file starting with ._) hanging around in the source directories that you are trying to document. asdoc barfs on them and will throw this error if they exist. (No data is stored in the resource fork of ActionScript files anyway, so delete away!)
I had a need for abcdump, which is a bytecode decompiler for ActionScript 3. Unfortunately, most of the instructions on the Web right now regarding how to compile this particular piece of software seem to refer to older versions of the Tamarin codebase and so no longer work. It took about an hour to piece together information to get the compilation process working again. So, here are some up-to-date instructions on how to compile abcdump from source. (No doubt that these instructions will become wrong too at some point in the future!)
Follow the official Tamarin Build Documentation to get a working version of avmshell (formerly known as avmplus). You may need to modify the Makefile that configure.py generates, changing -fstrict-aliasing to -fno-strict-aliasing, in order to get it to compile successfully. (This is required only if you get the error “dereferencing type-punned pointer will break strict-aliasing rules”.)
Re-compile the builtin library: cd tamarin-central/core; java -ea -DAS3 -Xmx200m -DAVMPLUS -classpath ../utils/asc.jar macromedia.asc.embedding.ScriptCompiler -d -builtin -out builtin builtin.as Math.as Error.as RegExp.as Date.as XML.as. Failing to do this will result in “The definition of base class Object was not found.” on the next step.
Compile the ByteArray library: cd tamarin-central; java -jar utils/asc.jar -import core/builtin.abc shell/ByteArray.as
Following these instructions, you should now have a stand-alone, executable abcdump.exe in the utils directory. One caveat to note is that you will need to pass “--” as the first argument when you try to run the stand-alone executable, since otherwise the virtual machine interprets the arguments as its own instead of passing them to the application. Happy hacking!
Despite this documentation to the contrary, Event.EXIT_FRAME does not exist in Flash Player 9/AIR 1.0. It was introduced in Flash Player 10/AIR 1.5. If you are writing a SWF that targets Flash Player 9, attempting to use the Event constant will fail, but if you hard-code the “exitFrame” string, it will appear to work—until you start getting complaints from people that still haven’t updated to Flash Player 10 that your events aren’t firing.
I suppose it raises a question about why one would ever choose to use the EXIT_FRAME event. According to Johannes Tacskovics, the EXIT_FRAME event occurs at the end of the lifecycle of constructing the current frame before it is displayed. This seems somewhat counter-intuitive, in that the name implies that the event would occur just before a frame is destroyed.
Either way, since I was looking for an event that would provide me with the ability to perform frame-exact synchronisation to MP4 video, this event was no more useful than ENTER_FRAME. (Adobe, for some reason, decided not to implement onCuepoint for MP4 playback.) Unfortunately, frame events like ENTER_FRAME don’t appear to correspond precisely to when a video frame is rendered, and Flash’s timers are not precise enough either, so the ultimate result was a player with overlays that were sometimes out-of-sync by one frame. Bad, but not disastrous. Still, it would be nice if there was a way to get frame-exact synchronisation with MP4s. Maybe someday…
I’ve run a problem multiple times now with Flash Player and animating the alpha property of an object that contains text. For some reason, when using “Anti-alias for readability” or “Custom anti-alias”, there is a noticeable jump in appearance between 0.78515625 (201/256) and 0.7890625 (202/256), as though it is actually changing the method that is used to blend the sub-pixels at that point. It is highly distracting, and makes it impossible to smoothly change the opacity of text fields. Here is an example that shows the abrupt change between these two alpha levels:
One solution is to change the anti-aliasing mode to “Anti-alias for animation”, but then the letterforms get muddy and pretty ugly to view. Another option is to change the layer mode to “lighten” or “darken”, but this only works in cases where the text is black or white.
Has anyone else discovered a real solution to this problem? I haven’t seen it discussed anywhere, but maybe my Google-fu is simply failing me.