Rich Media Hacker (RSS)
Race Conditions in Flex VideoDisplay
The Flex mx.controls.VideoDisplay object is a double edged sword. If you’ve used it for anything complex, you’ve likely noticed that it gets very finicky under certain conditions. Thats really a shame, since it provides many useful features, like rtmp vs http connection management, bandwidth detection, and various optimizations to connection speeds to name a few.
On the Fan, we’ve occasionally had problems with playing lists of videos with VideoDisplay, and we’ve had to jump through a few hoops in order to continue to use it so that we’d still get all its benefits. The problem generally consists of the VideoDisplay getting into a state where it stops responding to subsequent calls to load() & play().
We had worked around most of these by moving around our code to avoid apparent race conditions in VideoDisplay, and we even had to monkey-patch the VideoDisplay & VideoPlayer classes to get around a problem were it would load the netstream twice for the same video and you’d get a double/echoing audio stream. While working with one of our partners recently, we came up against another bug in VideoDisplay that we couldn’t get around. This time it was throwing an error like this:
ArgumentError: Error #2126: NetConnection object must be connected. at flash.net::NetStream/construct()at flash.net::NetStream() at VideoPlayerNetStream()[E:\dev\flex_201_borneo\sdk\frameworks\mx\controls\videoClasses\VideoPlayer.as:2883] at mx.controls.videoClasses::VideoPlayer/createStream()[E:\dev\flex_201_borneo\sdk\frameworks\mx\controls\videoClasses\VideoPlayer.as:2712] at mx.controls.videoClasses::VideoPlayer/_load()[E:\dev\flex_201_borneo\sdk\frameworks\mx\controls\videoClasses\VideoPlayer.as:2170] at mx.controls.videoClasses::VideoPlayer/load()[E:\dev\flex_201_borneo\sdk\frameworks\mx\controls\videoClasses\VideoPlayer.as:1486] at mx.controls::VideoDisplay/load()[E:\dev\flex_201_borneo\sdk\frameworks\mx\controls\VideoDisplay.as:1361]
It actually involves not only VideoDisplay but also VideoPlayer (which VideoDisplay has an instance of) and even NCManager (which does some of the stuff mentioned above). My counterpart at the other company wasn’t seeing this error in his test environment, but eventually we realized what the crucial difference was: autoplay was set to false in the Fan, while it was left to its default (true) in his test player.
Since he had it working with no problem, i decided to see what would happen if i left autoplay at its default value of true.
Well, there were some side effects related to videos playing before i was ready for them, however the broken state of VideoDisplay went away! Now I simply pause the VideoDisplay right after i set the source to simulate having autoplay set to false. This has the added benefit of buffering the movie right away instead of later on, so i’m pretty happy with the solution (although i think VideoDisplay should do that anyway if it was written properly)
Update: here’s the code we used to patch mx.controls.videoClasses.VideoPlayer:
public function ncConnected():void {
if (_ncMgr == null || _ncMgr.netConnection == null)
setState(CONNECTION_ERROR);
else{
if (!alreadyLoaded) {
alreadyLoaded = true;
createStream();
setUpStream();
}
}
}
Obviously we also added a variable declaration for alreadyLoaded, and we also reset it to false in the _load function (you can’t miss it, there’s a ton of variables getting reset in the function)
Update: here’s a screenshot of my project structure showing how to “underride” the adobe class.