Posts Tagged ‘quirks’

Bugs and Quirks: Capabilities.playerType

Posted in Article, Bugs on January 17th, 2011 by Ian Ford – Be the first to comment

This isn’t technically a bug, but it is a strange quirk in ActionScript 3. I’ve discussed the Capabilities class before. I still like it. I still think it’s very useful.

I have one problem.

The Capabilities class has no public string constants. I was looking for an article or document explaining why you should use string constants, but I couldn’t find one so I suppose I’ll write my own later.

Anyway, most every other class that passes string values around uses constants to store those values. The Capabilities class does not. This results in code like the following:

if (pt == "ActiveX" || pt == "PlugIn") {
  //...
} else if (pt == "External" || pt == "StandAlone") {
  //...
}

Remember, it should be “PlugIn,” not “Plugin,” “plugin,” or “plugIn.” If you use any of the latter three your SWF will publish just fine without any compile errors to let you know something is amiss. It won’t be until your conditional fails to select either option that you start scratching your head wondering what went wrong.

I propose that adobe add a PlayerType class to the flash.system package. The class would simply contain four static values:

public static const ACTIVEX:String = “ActiveX”;

public static const PLUGIN:String = “PlugIn”;

public static const EXTERNAL:String = “External”;

public static const STANDALONE:String = “StandAlone”;

The benefit of having such a class is that as long as you used those values, if you committed a typo or some other minor error the compiler would let you know. Wouldn’t that be nice? I’ve submitted this as an issue in the Flash Player Bug management system. Go vote on it.

Bugs and Quirks: SWFStudio 3.7 and Windows 7

Posted in Article, Bugs, Downloads, SWF Studio on March 27th, 2010 by Ian Ford – 3 Comments

I spent the last week or so developing a kiosk application for a client that had to prevent users from exiting the application using ctrl+alt+delete, alt+f4, or any other such method.

Because I had worked with it in the past for a similar project, I advised the client that we could use Northcode’s SWFStudio to lock the application down and to record registration data without requiring an internet connection. This should have all been very simple. Create the application, load up SWFStudio, and convert my final SWF to an EXE with all the parameters configured.

In practice things weren’t so simple. You wouldn’t know this unless you dug around, but SWFStudio 3.7 doesn’t play nicely with Windows 7, and for the $300 licensing fee you’d hope they would take the trouble to make this point more prominent. To give you an idea of this problem, I’d like to demonstrate the sequence of steps you need to complete to figure out why your perfectly functional kiosk craps out after you push it through SWFStudio.


Step 1

First, you have to go to Northcode’s website. When you get there, click on the “swf studio” link at the top of the page. Don’t click “blog” and whatever you do, don’t click “support.”


Step 2

Once you get to the “swf studio” page, click to continue reading the article on making your applications work with Windows 7. Don’t bother with the “Known Problems” link in the side bar, as even though they thought to post an article about the issue (separate from their blog and their support page no less), it’s not a problem they’re aware of.


Step 3

You’re almost done! You’ve found the document explaining how to fix your problems in Windows 7. Of course, there’s no patch or software update. You have to copy the grayed out text above into a panel in SWF Studio to get everything functioning properly.

What makes me even angrier about this is the text of the article. The summary, shown in step 2, contains the following text:

Windows 7 adds support for a new section in your application manifests called Compatibility and if you want your SWF Studio applications to behave properly on Windows 7 then you’d better pay attention!

They even use an exclamation mark! I’d better pay attention if I expect their $300 application to function correctly. That might even be ok if they displayed the information prominently on their homepage, or in any of the sections you’d expect it to be in. To give you an idea of how poorly placed this content is, as I was sitting down to write this post it took me 15 minutes digging around their site to find the document in question again.

For my own satisfaction, and for the sake of anybody else who runs into problems with this software, I’ve taken the following liberties:

  1. I’m offering this code to you below so there’s a second place to find it if anybody ever needs it.
  2. I’m offering this code for download so you can keep your own copy if need be.
  3. I’m recommending a slight redesign to Northcode’s home page.

The code looks like this.

<br><br>&lt;?xml version="1.0" encoding="UTF-8" standalone="yes"?&gt;<br><br>&lt;assembly  xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"&gt;<br><br> &lt;assemblyIdentity  version="1.0.0.0" processorArchitecture="X86" name="stub.exe"  type="win32" /&gt;<br><br> &lt;description&gt;stub&lt;/description&gt;<br><br> &lt;dependency&gt;<br> &lt;dependentAssembly&gt;<br> &lt;assemblyIdentity<br> type="win32"<br> name="Microsoft.Windows.Common-Controls"<br> version="6.0.0.0"<br> processorArchitecture="X86"<br> publicKeyToken="6595b64144ccf1df"<br> language="*" /&gt;<br> &lt;/dependentAssembly&gt;<br> &lt;/dependency&gt;<br><br> &lt;trustInfo xmlns="urn:schemas-microsoft-com:asm.v2"&gt;<br> &lt;security&gt;<br> &lt;requestedPrivileges&gt;<br> &lt;requestedExecutionLevel  level="asInvoker" uiAccess="false"/&gt;<br> &lt;/requestedPrivileges&gt;<br> &lt;/security&gt;<br> &lt;/trustInfo&gt;<br><br> &lt;compatibility  xmlns="urn:schemas-microsoft-com:compatibility.v1"&gt;<br> &lt;application&gt;<br> &lt;!-- the ID below indicates the application supports Windows 7  --&gt;<br> &lt;supportedOS  Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/&gt;<br> &lt;/application&gt;<br> &lt;/compatibility&gt;<br><br>&lt;/assembly&gt;<br><br>

You can download a file with this information here: SWF Studio Manifest for Windows 7 Projects

And my suggestion for a redesign of Northcode’s homepage is below.


The Corrected Northcode.com!

Bugs and Quirks – RichFLV Metadata

Posted in Article, Bugs, FLV, Tips, Video on March 1st, 2010 by Ian Ford – 4 Comments

If you’ve been reading things around here recently, you may recall that I posted an entry filled with glowing praise for RichFLV. I had been aware of the application for some time (it was one of the first AIR apps I saw receiving significant praise/attention), but had only started using it several weeks prior in my own development efforts.

In the time since then, my company began making heavy use of RichFLV for a large project I’ve been developing. The project required tons of external video and animation, and I had decided that the best way to synchronize the two was to use FLV embedded cuepoints as controllers for external SWF content (FLV, SWF, cuepoint -> frame label). Because of the volume of video we’ve been dealing with (around 2gb), the idea of being able to dynamically modify cuepoints without having to rebuild video seemed like an obvious win for us.

To say the least, there have been complications. I have three complaints with RichFLV at this point. One of them is a minor inconvenience and the other two are potential deal breakers.


Really? No Native Drag and Drop?



The first problem is quite simple and amounts to more of an inattention to detail than anything. RichFLV doesn’t support native drag and drop for playing video files. It may sound like I’m nitpicking, but when you’re dealing with several hundred video files buried in a complex folder structure, having to go to the “file -> open” dialogue to change files becomes a quick annoyance.


Cuepoint Confusion?



The second problem is that, once in a while, RichFLV completely screws up your cuepoints. On the one hand, it will often duplicate cuepoints at incorrect time codes (see cue12, appearing twice, the first of which has the same timecode as cue 11), and on the other hand it frequently refuses to designate cuepoints correctly as event or navigation points (see the final cue12). Generally we give our cuepoints distinct, meaningful names so that when they fire we can respond to them intelligently. It’s easy to see how the problems highlighted above prevent that.


Funky Metadata?



The final problem has to do with the metadata that RichFLV generates. There’s a little bit of backstory required for this one.

At the same time that this project was starting, I and my colleagues had taken an interest in the Open Source Media Framework and had planned to build a new video player around it to use with projects in the future. The inclusion, specifically, of Parallel and Serial media elements built into OSMF seemed like a great fit for the needs of this project. We decided to proceed with development of our video player and to deploy it in this project as it reached a usable state.

It didn’t take long before we were having major problems (with our Video Player!). We were consistently unable to get the OSMF to play videos with embedded cuepoints, even though we’d seen plenty of examples of it doing just that. The specific error we were receiving was as follows:

Error #2044: Unhandled AsyncErrorEvent:. text=Error #2095: org.osmf.net.dynamicstreaming.DynamicNetStream was unable to invoke callback onMetaData. error=TypeError: Error #1034: Type Coercion failed: cannot convert Object@3ca86769 to Array.

You’ll notice that the framework was unable to correctly invoke it’s “onMetaData” handler. Generally when you deploy video in Flash, you first wait for metadata to be made available so you can scan it for important information about the file, and for information about cuepoints. When attempting to playback FLV files in which cuepoints had been embedded with RichFLV, we received this error every single time. In fact, it didn’t even matter if we went back and stripped all of the cuepoints from the video. Once RichFLV touched the metadata, the video was effectively “broken.” We struggled with this error for days before eventually dropping the idea of moving forward with OSMF. Instead we had to fall back on another (self-created but very outdated) video player to complete the project.

Now, I have little (if any) experience with generating or encoding video, but I was so frustrated by all of this that I spent some time today digging  through the flv file format specification. The first thing I noticed was that RichFLV was providing incorrect values for the CodecID property of the FLV file format (specifically 4 for On2 VP6 rather than 5 for On2VP6 with alpha). Furthermore, I discovered that if I reencoded my FLVs using Adobe Media Encoder (which should understand the FLV format) rather than RichFLV, all of my problems disappeared. Go figure.

None of the above is necessarily meant to dissuade you from using RichFLV if you find it useful. As far as I can tell, the original developer hasn’t released a new version of it in well over a year, and this thing has been around since AIR was still called Apollo. Hopefully these bugs will get more public attention and the developer will be prompted to update the app or disseminate the source code so somebody else can pick up development on what otherwise has been a great and useful application.

Bugs and Quirks – Path Resolution Inconsistencies

Posted in Article, Bugs, Documentation, Flash, Tips on February 26th, 2010 by Ian Ford – Be the first to comment

So, I thought I’d bring attention to a strange inconsistency I run into on a very regular basis while developing applications in Adobe Flash.

Much of the work that I do in flash has to do with displaying and managing video. To date, I have probably created at least 50 different playlist enabled video players, by which I mean video players with a list of either links, thumbnails, or both that allow you to play other videos in the same container without leaving the page. For example, something like this…


A Generic Video Player


…with a playlist that allows you to select other videos, like this…


Video Player with Playlist


This is all well and good. Because I try to build in a way that’s generalized for client accessibility and ease-of-use (and because I don’t want to be solely responsible for updating these things myself), the standard way to go about creating something like this would be to have an external XML document that contains all of the information required to build the playlist. The application is responsible for loading that document and extracting that information from it, which it uses to build a clickable, interactive playlist. This is all quite simple. The XML could look something like this:

<playlist>
	<item>
		<uid>1</uid>
		<title>Video 1</title>
		<video>PATH TO VIDEO</video>
		<thumbnail>Image for video</thumbnail>
	</item>
	<item>
		<uid>2</uid>
		<title>Video 2</title>
		<video>PATH TO VIDEO</video>
		<thumbnail>Image for video</thumbnail>
	</item>
	<!-- and on, and on, and on -->
</playlist>

The folder structure for such an application could (and would) conceivably look like this:


FLA Folder



Within our document root, we have an FLA folder to hold our source files.

FLV Folder



We have an FLV folder for holding video assets.

SWF Folder



We have a SWF folder for holding all of our compiled application SWFs.

XML Folder



And finally we have an XML folder for holding any XML documents we’ll be loading in the application. The index file resides in the document root.

Here’s where things get screwy.

In my application, when I’m ready to load my external XML in order to build a playlist, my code will look like this:

var req:URLRequest = new URLRequest("xml/playlist.xml");
var loader:URLLoader = new URLLoader();
loader.addEventListener(Event.COMPLETE, _playlistHandle, false, 0, true);
loader.load(req);

After I’ve loaded my playlist, suppose I want to play the first video. For the sake of brevity, we will suppose that I have an instance of a video player class that will allow me to simply pass the path to the FLV in to begin playing it, and that it’s already been instantiated and configured under the name “_player.”

function _playlistHandle(e:Event):void {
	var loader:URLLoader = e.target as URLLoader;
	var xml:XML = XML(loader.data);
	_player.play(xml.item.video[0].toString());
}

What do you suppose the path to my video is going to be, within my xml doc? If you look above, you’ll see I loaded the xml from the document root, and it would be natural for you to assume that the path to the first video is “flv/video.flv.” In this instance, you would be incorrect.

The correct path to the video file would be “../flv/video.flv.” Why is this? The relative path to an asset, in flash, varies according to what type of asset it is you’re accessing. In the case of XML you load your file from the location in which the SWF file is running, which in our example is the document root. When you’re loading video, however, you have to load your file from the physical location of the swf, not from where it’s running. In our example, that means our video file must be loaded as if the application is running from within our “swf” subfolder.

Why is this the case? I honestly have no idea. I can only imagine that in some obtuse way it’s meant to protect video content from being exploited by external domains or malicious third parties, though I can’t see exactly how.

Hopefully if you find yourself developing such an application, and you can’t figure out why the paths to your videos won’t resolve correctly, you’ll remember reading about the issue here. If anyone has a good explanation for why this is the case, I’d also be very curious to be informed.