Date: Tuesday 9th February 2010 Time: 21:17 Category: Adobe Flash Views: 155 Comments: No comments
Objective
We’ve been spending a lot of time recently examining the different video codecs available for Flash and conducting various tests. Our objective has been to choose the best quality video format which also enables pseudostreaming – without using custom servers such as Lighttpd.
What is pseudostreaming?
Pseudostreaming means imitating the behaviour of a RTMP streaming server such as Red5 or Flash Media Server by simply using a PHP script such as xmoov.php. Using such a solution does not enable the broadcast live webcam streams, for example, but it does allow jumping ahead to parts of a video which have not yet downloaded. This is probably the benefit most people seek from a streaming server solution and it is much easier to set up than a streaming server. It is the choice of YouTube and Google Video.
What’s required for pseudostreaming?
Pseudostreaming requires a video format which supports it and a video player which supports it too. Two leading open source video players, JW Player and Flowplayer both support it, because they send a request indicating how much of the video file should be sent back.
Flowplayer requires a plugin SWF. This player is configured using JSON. JSON is not especially complicated but we found this config method fairly verbose. It also uses its own flash embed routine. You have to get the config exactly right for pseudostreaming via xmoov to work with Flowplayer. There are scarce resources on the web. The main one points to this page, which is now outdated, but it can be done, and if you need to know how, ask us.
We find JW Player easier to configure for pseudostreaming with xmoov. The info page is here and after we pointed out a fault with the player, here, the latest release works properly with pseudostreaming.
Comparing video formats
Okay, so perhaps we will use JW Player as our player, but we’re still no closer to deciding which video format to use.
H.264 & F4V
It seems safe to say that the best quality format for the web at the moment is the H.264 standard. We are seeking to encode video using Adobe Media Encoder, which is included with Creative Suite 4. This program uses the MainConcept H.264 Video codec and using this codec it can encode into either MP4 format or F4V format. At least Flash Player 9.0.115.0 is required to play back this standard.
F4V was created by Adobe in order to address shortcomings in the FLV format. It determines additional file meta data and enables the embedding of H.264 video in this custom format.
At the time of writing, according to our research, you can forget about using H.264 for pseudostreaming unless you have shell access to your Linux server and wish to try compiling a PHP module like this or you are using lighttpd as your web server.
Neither Flowplayer nor JW Player support pseudostreaming of either F4V or MP4 videos using the H.264 standard along with xmoov.php.
Eric Lorenzo Benjamin Jr of xMoovStream also offers his own video player, which looks good, and a separate streaming server solution. This can stream MP4 (H.264) files to Apple’s iPhone and Quicktime, but not to Flash Player. We’re still limited to FLVs with this player.
F4V problems
A little more about F4Vs while we are on the topic: it currently appears to be faulty – at least when encoded by Adobe Media Encoder CS4:
It does not add keyframes at navigation cue point times
It does not trigger cue point event listeners in the expected manner
It does not respect custom keyframe intervals
Some more reasons not to use this format yet, perhaps, despite Adobe having urged everybody to switch to it. If you wish to have high quality video without xmoov pseudostreaming, use MP4 instead for now. (Under our tests, MP4s embed seekpoints correctly whereas F4Vs do not.)
We’re left only with trusty old FLV as the format we can pseudostream.
Setting up FLVs for pseudostreaming
Choosing a codec
You have a choice of two different codecs when exporting FLVs using Adobe Media Encoder: Sorenson Spark or On2 VP6. The latter is the later, recommended, codec.
Choosing a keyframe interval
Notice the option to “Set Keyframe Distance” in the Export Settings under Video → Advanced Settings. When using pseudostreaming the player can only jump to the closest keyframe. The more keyframes, the more precise your pseudostreaming will be, but the larger your file will be.
The default is a keyframe interval of 30. If you take this down to 10 you will see a lot more precision and about a 17% rise in file size. If you take it down to 1, though, you will see a 1000% rise in file size along with your optimal precision. You will also find that the video player takes a long time reading the meta data of the FLV before it plays it. We are happy with the compromise of a keyframe interval of 10.
So you export the video using whatever quality you like, and this keyframe interval. You stream it into your player using referring to the config links above. You try seeking to a part of the video which has not yet downloaded. The playhead simply jumps back to the beginning of the video. What’s going on?
Inserting meta data
Well, it’s not enough to have the keyframes in the video. What Adobe Media Encoder unfortunately does not do is insert meta data in the FLV indicating where those frames are. This is vital for php pseudostreaming to work. (Adobe: please provide the option for this in the next release of AME.)
Luckily, there is quite a dated freeware tool from Buraks, of the ActionScript Viewer, which still does the job well: FLVMDI. There is even a GUI available so you don’t need to start working on the command line, and another tool enabling you to view the meta data without tracing it out using Flash.
Once you have exported your FLV file with the ideal keyframe interval, you’ll need to run it through FLVMDI to insert the meta data. Be sure to tick the “Include ‘keyframes’ object” option. It performs this task quickly, then, when you use the file with JWPlayer and xmoov, you should find you can move the playhead to any location and the file will “stream” from there.
Conclusion
The conclusions to be drawn at this point, we believe, are as follows:
F4V is a no-go area as there are problems with the format.
MP4 (H.264) is the optimal format if you do not require pseudostreaming via xmoov.
FLV remains the best format to use if you do wish to pseudostream using these players.
Since pseudostreaming is highly desirable, then, and xmoov is a quick and easy solution, we find FLV to be still the best format.
Here’s a table presenting most of our findings:
CAPABILITIES / FORMAT
FLV
F4V
MP4
Can use H.264 standard codec
Works with xmoov.php
Embeds cuepoints (correctly)
Can have embedded keyframe meta data
Requires separate injection of the meta data
Respects custom keyframe interval
Supports alpha channel
We hope this article helps get you up and running with Flash video including pseudostreaming. If you spot any problems with it do let us know, and if the article proves popular we may expand on it and insert relevant images.
Note that we set the fourth parameter, useWeakReference, to true. This ensures that if this listener is the the only reference to the myButton remaining, myButton can still be garbage collected if required.
The trouble with this is that every time myButton is clicked, the same URL will open. We can’t easily pass a parameter to the function which is acting as a listener. How can the same function be used by many buttons to open a different URL for each button? How can we pass a parameter?
Solution 1: Custom events (won’t work):
It would be nice if we could dispatch a custom event on mouse click. Custom events extend the event class enabling us to dispatch an event with additional properties (like a URL). This event is received by the handler then the property is accessed. The trouble is this approach won’t work here because the Flash Player automatically dispatches MouseEvents, we don’t dispatch them ourselves. (If anyone sees a way this may be done, please comment below.)
Solution 2: Embed the function call (not advised):
An interesting strategy is used here, whereby a call to a function is used as the event handler, and this returns the function to use, including the desired parameter. The trouble with this approach is that it is not really good form, in that there is no way we can reference the handler if we did want to remove it using removeEventListener().
We’re beginning to see that there is actually no way to “pass” a parameter, really. We have to rather detect the button-specific value by “association”. The following solutions all achieve this by using the MouseEvent’s target property:
Solution 3: Use a switch statement on the event’s target property
When the button is clicked, providing there is no further mouse-enabled object inside it, that button is the event’s target. We can say it dispatched the event. We can access the target object that dispatched the event using a property of the event itself:
myButton.addEventListener(MouseEvent.CLICK, openURL, false, 0, true);
private function openURL(e:MouseEvent):void
{
trace(e.target + "dispatched this event!");
navigateToURL(new URLRequest("http://www.mysite.com"), "_blank");
}
If we can access the target we can decide what to do in the handler depending on the target:
myButton.addEventListener(MouseEvent.CLICK, openURL, false, 0, true);
private function openURL(e:MouseEvent):void
{
var u:URLRequest = new URLRequest;
switch(e.target)
{
case myButton:
u.url = "http://www.mysite.com";
break;
case myOtherButton:
u.url = "http://www.myothersite.com";
break;
default:
throw new Error("No URL set for " + e.target);
return;
}
navigateToURL(u, "_blank");
}
This works well.
Solution 4: Use a public custom property inside the dispatching object
We could avoid a switch statement and instead have a property inside the dispatching class which can then be detected. So if our button extends Sprite, let’s say, we could have an instance property in there called url and we could detect that, as follows:
myButton.addEventListener(MouseEvent.CLICK, openURL, false, 0, true);
private function openURL(e:Event):void
{
var u:URLRequest = new URLRequest;
navigateToURL(new URLRequest(e.target.url), "_blank");
}
This is fine too, but we might need to throw an error if the object dispatching the event doesn’t have a url property.
Solution 5: Use a dictionary object to track variables
Dictionary objects in ActionScript are similar to associative arrays but they can accept complex objects, as opposed to strings, as their keys. After creating our button we could push a reference to it into a dictionary and specify a value to associate with it, like this:
var dict:Dictionary = new Dictionary(true); // use weak references to the objects
var myButton:Sprite = new Sprite;
dict[myButton] = "http://www.mysite.com";
addChild(myButton);
myButton.addEventListener(MouseEvent.CLICK, openURL, false, 0, true);
private function openURL(e:MouseEvent):void
{
navigateToURL(new URLRequest(dict[e.target]), "_blank");
}
This is perfectly workable too.
Solutions 3, 4 and 5 all seem equally good solutions to this problem. There is just one final option, which is to avoid the problem altogether by using separate listeners for each button. But that, of course, is what we were trying to solve in the first place.
Date: Thursday 31st December 2009 Time: 18:56 Category: Adobe Flash Views: 182 Comments: No comments
Something we use here is the Google Maps API for Flash, which is delivered as an SWC file. SWC files are ActionScript classes which have been pre-compiled into an SWF. The fact they are pre-compiled means you don’t have to re-compile them every time you export your application. Another benefit of SWCs is that they enable you to deliver functionality while keeping your source code obfuscated to some degree.
In their instructions, Google say you should install the SWC files to the following location:
What if you’re using Flash CS4? Well, in this version of Flash the ActionScript 3.0 Settings dialogue has changed (both the publish settings version and the global preferences version). You can specify a “library path” – this may be any folder on your computer. This is supposed to be a repository for your SWC files; you can set this and drop an SWC in here.
This will allow you to access the classes compiled into the SWC, however the SWC does not show up in the Components panel in Flash. If you are working visually in the Flash IDE and would like it to do so, you will need to forget about the library path option and instead drop SWCs into this folder: