Archive for February, 2009
Back From The Dead
Whoo, that was rough! My burn out seems to be behind me finally. I am catching up on emails slowly but surely and even managed to squeeze in a few blog posts this evening. I have been nose-deep in both Flash and iPhone apps at work, so I am feeling motivated to do that iPhone tutorial sometime soon. No need to give me grief, I am well aware of the fact that I promised it nearly four months ago.
By the way, if you missed my presentation on Pixel Bender at Adobe MAX last year, it has been posted on Adobe TV for your viewing pleasure. Apparently my crutch word is “uh”; I lost count of how many times I said it.
On a final note, my peers are pressuring me more and more into joining Twitter. People are losing the fight all around me (Mr. Doob, David, Grant). Should I follow suit and conform or hold strong?
6 commentsDealing With ‘Unable To Resolve Asset For Transcoding’ Errors
Awhile back, I wrote a similar post titled Cure For The ‘Unable To Resolve Asset For Transcoding’ Compiler Error. Though old, the post continues to get a lot of hits, so I thought I would post another entry on a similar issue which you may have encountered.
Have you ever been working on a project and went to do a build, only to be slapped with a bunch of ‘Unable To Resolve (asset path/name) For Transcoding’ errors? Perhaps you are reading this post because it just happened to you and you have no idea why. Continue reading.
The reason this occurs is because you have some assets somewhere in your project that are now missing; whether it be because they were moved and their references in your CSS were never updated or possibly because they were deleted by mistake. Whatever the reason, they are no longer at the location specified in your CSS and that is causing the entire embed process to fail. The tricky part is figuring out which assets are the problems. Unlike the rest of errors, the actual problematic assets will read ‘Unable To Transcode (asset path/name)’. If you do not see any errors with this message in your Eclipse ‘Problems’ panel, it is because it only shows 100 errors by default and you may have many more than that depending on the size of your project.
To change this, click the little arrow in the top right-hand corner of the panel and select ‘Preferences…’ from the menu. In the pop up window that appears, find the line that reads ‘Limit visible items per group to:’ and change the number next to it from 100 to a larger value, such as 200. Repeat this process if you still aren’t seeing all of the errors. Once they are all visible, you should be able to find the errors which call out the assets that are causing the problem. Make the appropriate changes and re-build; your problems should be gone at this point.
No commentsFlex VideoDisplay Tweaks
If you have ever worked with the Flex VideoDisplay component, you are no doubt aware of the fact that its long list of conveniences come at the expense of some limitations and bugs. While the intention of this post is to cover a simple workaround for a few issues, I encourage you to share additional bugs and workarounds that you have had to implement in the comments below.
NOTE: Before getting started, I highly recommend that the minimum version of the Flex SDK that you target be 3.2.0.3958 due to a variety of video related fixes have been made in builds prior to this.
The issue that I would like to address is when you attempt to play a list of videos using the VideoDisplay component. What happens is that upon the 'complete' event being dispatched, you then update the component's 'source' property to reference the next video that you would like to play. Upon doing so, you will likely find that the component falls into an unresponsive state. More specifically the 'stateResponsive' property gets locked up with a value of 'false', rendering the object useless. If you do some Googeling, you will find posts that describe this occurrence and others that also occur as the result of race conditions internally within the component.
Fortunately, you can bypass this problem fairly simply by disabling a few things and creating a subclass of VideoDisplay. While you're at it, you can add an implicit getter and setter for toggling video smoothing; something that was unfortunately left out of the VideoDisplay API for some reason. Let's begin by examining a simple subclass:
-
package
-
{
-
import mx.controls.VideoDisplay;
-
-
public class MyVideoDisplay extends VideoDisplay
-
{
-
[Bindable]
-
override public function get source():String
-
{
-
return super.source;
-
}
-
-
override public function set source(value:String):void
-
{
-
super.source = value;
-
-
play();
-
}
-
-
public function MyVideoDisplay()
-
{
-
super();
-
}
-
}
-
}
All I am doing here is overriding the implicit getter/setter for 'source' and adding a call to the 'play' method each time the source it set. Now in your view, be sure to disable 'autoPlay' and 'autoRewind':
-
<local:MyVideoDisplay
-
id="myVideoDisplay"
-
autoPlay="false"
-
autoRewind="false"
-
source="{ModelLocator.myVideoModel.currentVideo.url}" />
If you prefer, this could be handled in your subclass instead; for the sake of example, I am showing it in MXML. This is an important step though; it is the combination of the additions in the subclass and these two settings being disabled that will allow your video list to play one-by-one without encountering the bug.
Now, since you have a subclass ready to go, why not add access to the smoothing capabilities of the underlying VideoPlayer? To do so, you will need to gain access to the VideoPlayer instance by using the 'mx_internal' namespace. Simply add a getter/setter for smoothing to your class, then reference the example below for actually applying the changes:
-
package
-
{
-
import flash.events.Event;
-
-
import mx.controls.VideoDisplay;
-
import mx.core.mx_internal;
-
-
use namespace mx_internal;
-
-
[Event(name="smoothingChanged", type="flash.events.Event")]
-
-
public class MyVideoDisplay extends VideoDisplay
-
{
-
private var _smoothing:Boolean;
-
-
private var _smoothingChanged:Boolean;
-
-
[Bindable("smoothingChanged")]
-
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]
-
override public function get source():String
-
{
-
return super.source;
-
}
-
-
override public function set source(value:String):void
-
{
-
super.source = value;
-
-
play();
-
}
-
-
public function MyVideoDisplay()
-
{
-
super();
-
}
-
-
override protected function commitProperties():void
-
{
-
super.commitProperties();
-
-
if (_smoothingChanged)
-
{
-
if (mx_internal::videoPlayer)
-
{
-
_smoothingChanged = false;
-
-
mx_internal::videoPlayer.smoothing = _smoothing;
-
}
-
}
-
}
-
}
-
}
Two birds with one stone, but a shame that any of this was necessary in the first place. As I mentioned earlier, if you have any other VideoDisplay workarounds for these issues or others and you would like to share them, please do so in the comments below.
5 commentsDreamsocket Re-launched
Friend and local Flash enthusiast Kenny Bunch relaunched his company's site today. A lot of time and love has been invested in the Media Framework that he is offering; I definitely suggest you consider it if your company is in need of something super robust and well-written.
Congrats on the new site, Kenny!
1 comment
