A few weeks ago, I was tasked to create a little program that would generate a random set of numbers in a specified range for a Christmas party in a very limited time (in a span of less than 4 hours).

A quick search in Google showed Flanture’s random number generator. It had 3 digits and when the roll button was pressed, a random number from 000 to 999 would be generated.

I wanted more flare and some fancy effects to go with the random number generator (for one, I needed a specific range of random numbers). And it was a 4 digit number, not just a 3 digit number.

Modifying the flash and actionscript was simple enough.

I added some modifications to add flashvars to the original code such as:
ftitle: Title shown to the flash app (value below is “Christmas Raffle”)
minval: minimum value in the range to be shown (value below is “3000″)
maxval: maximum value in the range to be shown (value below is “5000″)

If you want the modified source code (with other effects and range of random numbers), you can get the source code here.

We all have our favorite plug-ins for our browsers. Many people can’t live without their flash plug-in for their games and watching Hulu and YouTube videos. Other people use Java applets for their enterprise applications. Still, others use Quicktime for watching .mov videos on the browser.

What happens if a rogue plug-in runs in your browser? This is when sandboxing plug-ins become apparent.

Sandboxing applications have had it’s purpose and use in Java applications, especially plug-ins, where the program is placed in a restrictive environment that is not allowed to access system functions unless it is given access to.

This allows the plug-in to run in it’s own environment without harming the other browser or system processes.

How is sandboxing applied? Either through the plug-in itself (like java, and in a lesser way, flash), or through the browser.

Newer browsers such as Google Chrome separate their browser windows through threads, allowing rogue plug-ins to crash the affected window only. Other browsers implement some sort of sandboxing of their plug-ins. Which is better?

Since most people are in the fad of flash-bashing these days, let us make a sample of a rogue flash application that crashes the browser. Here is the link.

Mind you, I would say that flash has its uses; however as someone who dabbled in ActionScript one time or the other knows that the Flash runtime has a number of quirks and bugs that are really downright bad. In my opinion, this example is one of them.

Browsers who do not sandbox their plug-ins or separate their windows as separate threads would find this page crashes their browser really bad.

This includes Firefox, IE and Safari.

The only way to avoid spectacular crashes is to use a browser which implements some sort of separation between the plug-in and the browser itself.

Opera and Google Chrome passes this test admirably.

Interestingly, due to the flash plug-in running in a separate process in 64 bit systems in Linux (through nspluginwrapper), only the nspluginwrapper crashes, and does not take the whole browser in it.

To end, this is what I like to see implemented in all browsers. Running plug-ins in a separate process, as well as limiting it’s scope in relation to access to the underlying operating system.

We’ve all seen the html 5 upcoming features and admittedly, it is very exciting.

Features such as canvas, and even a way for communication between servers (like a chat client), and geolocation are just one of the few highlights that html 5 offers.

One of the most anticipated features is the <video> tag which allows for embedding video without the use of an external browser plugin (ie flash).

Many pundits would say that it is the beginning of the end for Adobe Flash.  And I would agree, to an extent.  I believe that Flash’s days as a premium source of progressively streaming video content are numbered somewhat.

Things to keep in mind though:

1. HTML 5 does not include options for LIVE video streaming.  We can say that there is H264 streaming by the open source darwin server (created by apple).  But let’s be real.  Quicktime is a resource hog, and it’s frankly, its awful in windows.  And flash is practically present in over 90% of the computers worldwide – computers are then mostly live streaming content ready.

2. Games and RIA – Canvas and javascript have some neat tricks in HTML 5 (freeciv.net comes to mind).  One thing that flash trumps HTML 5 is how flash makes it easy for developers to create games (and elaborate ones at that!), with sound and effects to boot.  Flash simply trumps HTML 5 in Rich Internet Application features.

3. HTML 5 final draft is on 2022.  What would happen here is that as browsers race to implement HTML 5 features this early, they will have their own implementation.  We have already seen this in the implementation of the <video> tag.  Safari, Chrome support H264.  Firefox and Opera support Theora – IE has no support for the <video> tag.  From experience, I have to contend with different implementations of javascript, dhtml, and even css for different browsers.  What I am hoping is that HTML 5 will not descend into a web developer’s nightmare of supporting different browsers.  For flash, backwards compatibility is largely maintained: AS2 will still run on the newest Flash runtime, and developers will just develop flash applications without worrying that their applications won’t run on linux, windows or macs.

4. One thing about the video tag is that the actual video file is linkable, and thus, downloadable.  Content providers don’t like their videos readily downloadable by users, especially for premium video content.  Although not perfect, Flash offers a way hamper downloads of video content by users.  We live in the real world, and the fact is, however we want our videos to be openly available, content providers would think otherwise.

5. Concerning the video tag, is Firefox’s and Opera’s refusal to support H264.  Fact of the matter is, H264 is patent encumbered, and in order for Firefox and Opera to use H264, they would have to shelve off H264 licensing fees.  As a blog of a Mozilla developer states: “In other words, if you’re an end user in a country where software patents (or method patents) are enforceable, and you’re using software that encodes or decodes H.264 and the vendor is not on the list of licensees, the MPEG LA reserves the right to sue you, the end user, as well as the software vendor or distributor.” – Flash on the other hand, has licensed H264 for use in their player.

6. Flash has some excellent authoring tools available, which makes development easy.  One thing which bugs me in the Open Source world is that IDEs are found mostly wanting.  I wouldn’t mind an open source IDE as good as Visual Studio – Eclipse comes close, but I hate the bloatedness of the application, causing me to have out of memory errors for large amounts of source code (and that was during my Java coding days).

In short, will HTML 5 obsolete Flash completely?  My answer: in some ways, yes, in other ways, not.  What I believe is that both technologies will coexist together for quite some time, until of course, a new version of the HTML spec comes, which may drive Flash into obsolescence once and for all.

The religious community that I’m in delves into media. In fact we have a website that showcases video and audio materials for free.

We use the ever popular video/media flash player made by Longtail Video to stream our mp3 and video files to be distributed and seen by people in the web.

As we host our mp3 files in mypodcast.com, the rss feed that is delivered my the site isn’t exactly compatible with the player – so I had to parse the rss feed and re encode it into an rss feed that the longtail player recognizes.

In order to not reinvent the wheel in reading rss feeds, I used the ever popular open source (BSD-licensed) php feed reader, simplepie.

Below this page is the quick and dirty code that I used. I hope this will help you get started in the world of podcasting!


<?
require_once('simplepie.inc');

$feed = new SimplePie(‘http://host/rss.xml’);
set_cache_location($_SERVER['DOCUMENT_ROOT'] . ‘/cache/’);

$feed->handle_content_type();

?>

rss feed name
get_items() as $item)
{
$title = $item->get_title();
$date = $item->get_date();
if ($enclosure = $item->get_enclosure())
{
$media = $enclosure->get_link();
$length = $enclosure->get_duration(true);
}
$subtitle = $item->subtitle;
$description = $item->get_description();
//print_r($enclosure);
$desc = explode(“”,”",$image);
echo ”

$title
$author

“;
}
?>

Heywatch is a cool video encoding web service that is being used by different clients like Sony, Fotolia, Kickapps, MTv, among others for their video conversion needs.

One nice thing about this service is that it has a REST based API that is simple to implement in php. However, the documentation that comes with heywatch shows only how to access the API using PEAR – this becomes a disadvantage if your shared hosted webhost doesn’t have PEAR installed. I also personally think that using PEAR just to call this api is basically overkill.

Why not use curl instead? I basically changed the PEAR functions in the API documentation to that of php curl functions (which are basically native and available in practically all shared php webhosting)


<?
$video_url = "http://osaddict.com/files/elephantsdream-480-h264-st-aac.mov";
$format_id = "1086"; // 1086 for flash h264, 31 for flash flv
$ftp = "ftp://username:password@ftphost.com";
$ping_after_encode = "http://host/heywatch/success.php?myvideoid=5&myuserid=1";
$ping_if_error = "http://host/heywatch/error.php";
$ch = curl_init();
$your_username = "";
$your_password = "";
$arr = array($video_url,"format_id"=>$format_id,"automatic_encode"=>"true","ftp_directive"=>$ftp,"title"=>"My Video Title","keep_video_size"=>"true");
curl_setopt($ch, CURLOPT_USERPWD, $your_username.':'.$your_password);
curl_setopt($ch, CURLOPT_POSTFIELDS,$arr);

$data = curl_exec($ch);

if (curl_errno($ch)) {
print curl_error($ch);
exit;
} else {
curl_close($ch);
}

header(“Content-Type: text/xml;charset=UTF-8″);
header(“Pragma: no-cache”);
echo $data;
?>

What this code does is to download a video, convert it to h264 flash format, then upload it to a select ftp host in just one step (success.php and error.php are ping functions where the developer is notified if conversion was successful or not).

One thing to take note is that heywatch doesn’t like special characters in the ftp url, if you place such characters in the $ftp variable, heywatch upload fails.

Have fun!