I’d been using Boxed Ice’s excellent guide on the subject, and they mention the developer identity instead of the production one. That guide is still tremendously useful, just make sure to go through the process of creating certs twice–once for Dev and once for Production!

But I digress. After I wasted a part of my life watching this slop, I spent about an hour crafted a review (review, rant, whatever) to post up on Netflix, only to discover upon hitting Send that Netflix has a 2,000 character limit. This is most certainly longer than that. So instead of contain my rage to those bright red pages, I’ll share with my general readership instead. All two of you.

One star is an undeserved compliment to this filthy excuse for a documentary. Ben Stein is a dishonest, plodding, parody of a man seeking any sort of truthful understanding. I say this not to attack Ben Stein personally and baselessly, but to inform any potential viewer of the habits and intent of the film as propped up by the man placing himself in front of the camera and telling the story.

Defying his ridiculous claim to remain logical when Darwinian scientists cannot, Stein frequently relies purely on an appeal to emotion. Hell gleefully make a very strong connection between Darwin and Hitler, never wasting an opportunity to display Nazi footage when he speaks of the atrocities of Darwin’s successors. He questions what the world would be like if PZ Myers world of without religion were to occur. His immediate response is to remind us that it was Darwin that led directly to Hitler, heavily implying that it is Darwin’s (and by natural extension, all of science’s) fault that six million jews were exterminated by one man. The intent is to force the ignorant viewer into believing that Hitler was the puppet of the real “one man” that started it all, Charles Darwin. Let us not forget that religion has led directly to countless atrocities throughout all human history, and shows no sign of slowing down. (This isn’t the same ridiculously dishonest speculation in which Stein engages. Read your history. Read your religion! It’s pretty bloody! Good luck finding any of that in this unbiased documentary.) Yes, humans are violent, territorial, xenophobic things. Guess what? So are apes! So are most other animals! Evolution at work, giving the world better and better killing machines that are better and better at surviving! Its an ugly truth, sure, but there’s hardly any doubting it if one is able to take a real, honest look at the world.

It’s hard to discuss Ben Steins vile attempt at an unbiased portrayal of this one-sided, woe-is-the-creationist war between “Darwinians” and the open-minded in a calm and composed way because he so cheerfully ignores his own demand that we be logical and above the “establishment’s” bias. He appears utterly incapable of this, and he proves it time and time and time again. What he is capable of is making purely emotional claims, backed by his confidence that you will be frightened by what you see, because you are so stupid, so brainless that you will see all that Nazi imagery, see his forced tears, hear all about his “needing time to think,” hear all his holocaust tales, that you will forget the blatant logical inconsistencies of his argument (or never realize they’re there in the first place) and be convinced that science is some world-wide old boys network that will bar any sort of open minded inquiry. This also requires a willful ignorance of both the process and the history of science, a method of understanding nature that is steeped in self-doubt. That’s quite simply how science works, no matter what Stein’s monotone droning insists. It’s hard to discuss this logically because Stein so brazenly refuses to be logical. His arguments are rarely anything but emotional, so that is what he threatens to reduce me to. I’ll save that for another review, but take this from my ranting: If you are looking for a movie that takes an honest, balanced look at the idea of “intelligent design” and especially at Darwin’s theory of evolution (a theory that has itself continued to mature and evolve since it first hit the science scene), this is absolutely, one hundred percent, NOT your documentary. It’s offensive to even label it a documentary. This film is only good for the hopelessly religious, because it will certainly galvanize them in their institutional ignorance, and the logical-minded masochist (like myself apparently) who feels like watching something so shockingly evil that you’ll feel inspired to write your first-ever movie review.

Hopefully there aren’t many like the latter, because I feel filthy just adding one to the count of fools duped into watching this whole thing. Please, Ben Stein, stop doing what you’re doing. No more religious films dishonestly disguised as documentaries, and no more implying that a scientist is a closet Nazi. This film is an embarrassment.

VideoDisplay has no doubt been the source of many headaches and much wasted time for any developer that has touched it. A lot has been written about it, and here’s my contribution, which is an evolutionary improvement over others’ work. It’s a fix that adds video smoothing and a source propert setter that doesn’t break the component and still allow you to set autoPlay. (This will all make sense in a minute.)

First I watched my friend Justin Stander (appallingly lacking a website to point to) do what I’ve known has been happening for a while by adding smoothing to VideoDisplay, which for some odd reason is absent from Adobe’s code. Then Ryan Taylor goes and writes about his VideoDisplay tweaks, adding in the ability to use a playlist without rendering VideoDisplay useless. This was a great improvement that would have saved me more time than I’d care to admit, had I paid attention to that post a month ago. Basically, the problem with Adobe’s class is that when you change the source, it calls a private method autoPlaying(), which immediately tries seeking the video. During this process, chaos ensues and the VideoDisplay instance gets stuck in an unresponsive state, metadata breaks, video controls rebel, and your girlfriend leaves you. Ryan’s code prevents all of that, but forces you to ditch the ability to turn autoPlay off. And here we are now, ready to add autoPlay back in.

Let’s take a look at the code.

package com.themathiseasy.ui.video
{
	import flash.events.Event;
 
	import mx.controls.VideoDisplay;
	import mx.core.mx_internal;
 
	use namespace mx_internal;
 
	/**
	 * Dispatched when the <code>smoothing</code> property
	 * changes.
	 */	
	[Event(name="smoothingChanged",type="flash.events.Event")]
 
	/**
	 * VideoDisplay mutation that fixes some of the original components flaws.
	 * @author danielwilliams
	 * 
	 */	
	public class CustomVideoDisplay extends VideoDisplay
	{
		/**
		 * @private
		 * 
		 * A workaround for the weird VideoDisplay bug, this replaces
		 * VideoDisplay's _autoPlay property.
		 */		
		private var _customAutoPlay:Boolean = true;
 
		/**
		 * @private
		 * 
		 * Internal storage for <code>smoothing</code> to be applied on the
		 * instance of <code>VideoPlayer</code>. 
		 */		
		private var _smoothing:Boolean;
 
		/**
		 * @private
		 * 
		 * Flag indicating that the <code>smoothing</code> property has changed.
		 */
		private var smoothingChanged:Boolean;
 
		/**
		 * Constructor 
		 * 
		 */		
		public function CustomVideoDisplay()
		{
			super();
 
			// damn you, broken autoplay.
			super.autoPlay = false;
		}
 
		[Inspectable]
		[Bindable("smoothingChanged")]
		/**
		 * Allows you to choose between performance and the pretty.
		 * @return Boolean
		 * 
		 */		
		public function get smoothing():Boolean{ return _smoothing; }
		public function set smoothing( value:Boolean ):void
		{
			if( _smoothing != value )
			{
				_smoothing = value ;
				smoothingChanged = true;
				invalidateProperties();
				dispatchEvent( new Event("smoothingChanged") );
			}
		}
 
		[Bindable]
		/**
		 * @inheritDoc
		 * @return 
		 * 
		 */		
		override public function get source():String
		{
			return super.source;
		}
 
		override public function set source(value:String):void
		{
			super.source = value;
			if( _customAutoPlay ) play();
		}
 
		[Inspectable(category="General", defaultValue="true")]
		/**
		 * @inheritDoc
		 * 
		 */		
		override public function get autoPlay():Boolean
		{
			return _customAutoPlay;
		}
 
		override public function set autoPlay(value:Boolean):void
		{
			_customAutoPlay = value;
		}
 
		/**
		 * @inheritDoc 
		 * 
		 */		
		override protected function commitProperties():void
		{
			super.commitProperties();
 
			if( smoothingChanged )
			{
				if( mx_internal::videoPlayer != null )
				{
					smoothingChanged = false ;
					mx_internal::videoPlayer.smoothing = _smoothing ;
				}
			}
		}
	}
 
}

Most of this is lifted almost directly from Ryan’s custom video class, so let’s take a look at the one real addition:

/**
 * @private
 * 
 * A workaround for the weird VideoDisplay bug, this replaces
 * VideoDisplay's _autoPlay property.
 */		
private var _customAutoPlay:Boolean = false;
 
[Inspectable(category="General", defaultValue="true")]
/**
 * @inheritDoc
 * 
 */		
override public function get autoPlay():Boolean
{
	return _customAutoPlay;
}
 
override public function set autoPlay(value:Boolean):void
{
	_customAutoPlay = value;
}

In VideoDisplay, autoPlay is the essentially the culprit in the playlisting bug, so here I handle autoPlay on my own by leaving _autoPlay alone once I set that value (via super.autoplay = false in my constructor) so that super.source doesn’t bother calling autoPlaying(). The last thing to do is make use of our autoPlay in source’s method like so:

override public function set source(value:String):void
{
	super.source = value;
	if( _customAutoPlay ) play();
}

And that’s it. Now, on top of smoothing and correcting VideoDisplay’s faulty source/autoPlay logic, we now have a video component that can run through a playlist and look good doing it. And your girlfriend will take you back, too.^*

I just wasted an hour trying to track down the cause of a VideoDisplay-related bug, and I’m posting the very simple solution here to hopefully save one or two people (including future Daniel) some headaches.

I’m throwing together a very quick performance demo in which I’m throwing many videos on a very, very large display, programmatically, and delivering as an AIR app. The problem that I’m experiencing is this:

"Error: 1000: Unable to make connection to server or to find FLV on server."

No matter what I did, no matter what file type I used (H.264 or anything older), this was happening. The problem, quite simply, is the order of commands.

currentVideo.source = videoSource;
currentVideo.play();
videoContainer.addChild( currentVideo );

That breaks Flash. This does not:

videoContainer.addChild( currentVideo );
currentVideo.source = videoSource;
currentVideo.play();

So there you have it. When you’re dealing with VideoDisplay programmatically, make sure the VideoDisplay instance is part of your displaylist before giving it a source and playing it!

A long time ago, I had another blog under the monicker Daniel Does Dallas. Like this blog, I didn’t do much with it and eventually a fiasco with 1&1 caused me to lose the domain altogether. Because 1&1 is a terrible, terrible company. But I digress. The only post that generated any interest was this one, so I’m reposting it here.

My job lately has been a whole lot of dealing with FLVPlayback, reskinning it, adding functionality, etc. It has been something very short of a nightmare, not counting those two nights where there really were nightmares.

I could easily spend ages writing about the things I’ve learned, but for now I’m going to restrict myself to just one component: the SeekBar. In Flash CS3, open the components dialog and drag a SeekBar component onto the stage. If you also drag an FLVPlayback component on the stage and give it a source and set its “skin” parameter to “none,” you should have a working SeekBar complete with a load progress bar (which happens too fast if you’re testing locally) and a little moving handle icon that lets you scrub through the video by dragging it.

Well, it’s not quite complete then, is it? What video player doesn’t have a play progress bar? And when scrubbing, why not allow a user to press anywhere on the entire bar as opposed to just that tiny little handle icon? It’s insane, I tell you! My only guess is that, while these things are extremely common these days, the AS3 FLVPlayback component is little more than a straightforward port from the old old AS2 version. You know, the old days when Flash players were more rugged and it was a wild and uncharted land.

Anyway, let’s add these features in.

First, we’ll add the play progress bar. Double click the SeekBar instance on the stage. You’re going to see four layers: script, assets, progress, and outline. Create a layer in between assets and progress and call it something like play progress. In here, create a movieclip symbol similar to the progress bar, but maybe a different color. The documentation is kind of vague here, but there’s something called Fullness for FLVPlayback controls. It’s intended to be used for the Volume control, and what it does is sort of has a bar follow the location of the control’s handle. So for volume Fullness is filled to the player’s volume. Simple enough, right? Well it can do the same sort of thing inside SeekBar, too, and since the handle’s job here is to indicate current play progress, Fullness becomes a play progress bar. To hook your new movieclip instance into FLVPlayback, just give your new symbol the instance name “fullness_mc” and that’s it! The one thing you’ll want to be careful of here when implementing this solution is that no matter what, you need that SeekBarHandle instance in frame 2 of the assets layer. Fullness depends on that being there, and without it everything breaks.

Next is the full-bar hit area. This is also something that isn’t very well documented, but also really easy to implement. Above your new play progress layer, create a new layer called hit area. Place a new movieclip instance that covers the entire area of the SeekBar component and give it the instance name “hit_mc”. Easy as that.

So there you have it, a super-simple solution to expanding the stock SeekBar component’s capabilities. Things will inevitably get trickier when you start connecting Flash’s video components to custom classes, but with these tricks in mind, things’ll probably go a lot smoother. I have no idea why all this information wasn’t laid out clearly somewhere before (and maybe it is and I was just never able to find it), but there you have it. Go knock yourself out.

I’ve uploaded a couple example files. One with an included FLV (990kb) for testing, and one without (328kb).

Every time I try opening Flex Builder up again, I was immediately met with a daunting error. JVM Terminated! All from switching my workspace? Obviously this isn’t normal behavior. A week ago, I was required to change my machine’s version of Java SDK to work with a simulator required for my current project. The computer was using what seemed to be a special version of 1.5, and the simulator app required 1.6. In OS X, there is a sym link at /System/Library/Frameworks/JavaVM.framework/Versions called Current. Originally, that was pointing at something called A, and I don’t know what that means, because in the same directory there’s also the 1.5 sdk, and they look pretty much the same. That was switched to 1.6.0 and the simulator worked. I switched (and when I say “I” here, I mean our resident Java guy) that sym link from 1.6 back to 1.5, still getting the error. Then I switched it back to A, and all is well.

So! Lesson learned. Flex Builder will give me problems if I mess with Java. Seems like kind of a bad thing, though, if ever I want to do any Java programming, right?

So here’s my first perspective test:

The cluster of two circles at the top is pretty straightforward. The two more subtle and uncertain things I spent more time playing with were the background and the sphere at the bottom. The background cloud has a bit of distortion that Should make the bottom clouds seem closer, but I’m not really sure if that’s happening. And for the sphere, I’m trying to play with lighting to make it seem like you’re looking at the same object from the perspective of each individual eyeball. Because the lighting is on the left side of the ball, your right eye should be seeing a little less of it. Playing with this has been weird, as the further I take the light from the same spot, the more confused the image gets. I’m not sure what I’m doing wrong yet.

Ok, so I got all into the wiggle stereoscopy idea after typing all this up, so I decided to go ahead and learn a little more about Photoshop. Yes, folks, I have clearly caught up with the rest of the internet. I’m coding like it’s 1997, and here I present you with my first ever animated .gif. Enjoy.

And that is my emo moment for the month.

This is simply a really quick note, and a reminder that whenever you’re starting to jump through hoops with code in Flex to accomplish something that should already be there, it probably is. Check the documentation.

So ViewStack lets you switch between different containers visually. By default, the ViewStack takes on the height of the first container within it and does not adjust height when it changes what it’s showing. Why this is the default behavior, I have no idea. But there’s a property that address this.

resizeToContent = "true"

Done. And duh.