I am currently playing around with the HTML5 FileSystem API, and have a need to test my files served via a web server. I could setup a virtual director for my local apache server, but given the number of simple tests and experiments I do, I wanted something easier that required little to no configuration and setup.

So, I put together a super simple script that uses python’s SimpleHTTPServer class.

Here is the script (requires that python is installed and in your path)

#!/bin/bash
 
python -m SimpleHTTPServer $1

To use it, just switch the the directory that contains your files and run:

http

This will open a simple webserver on port 8000.

You can optionally pass in the port like so:

http 2030

Which will start a simple web server listening on port 2030.

Again, this is something really simple, but also very useful. If you need to quickly test a file, just switch to the directory and run the script.

Btw, another work around for playing with the FileSystem APIs would be to pass the:

--allow-file-access-from-files

to Chrome when launching it.

Just as we did in Europe a couple of weeks ago, Lee Brimelow and I are doing a series of Flash get togethers in North America over the next couple of weeks. I will be talking about the roadmap for the Flash runtimes, and leading a discussion around recent development in the Flash world. Lee will be showing off some of the new stuff we are working on around gaming.

Here are the cities and dates:

• Denver : April 3
• Nashville : April 9
• Atlanta : April 10
• St Paul, April 11
• New York, April 12

We will also be doing meetings in San Francisco, LA, Chicago and Mexico City. Ill update this post once we finalize the details for those cities.

In addition to these events, Lee Brimelow is doing some additional events in Las Vegas and Tempe. Check out his blog for more info.

We have just posted a new whitepaper on Adobe.com. The whitepaper, titled Adobe roadmap for the Flash runtimes lays out the 1 to 2 year roadmap for the Flash runtimes (primarily Adobe AIR and Flash Player). This includes information on specific planned releases, longer term player work, and supported platforms.

This is actually the third Flash platform white paper that we have released in the past week (Adobe’s view of Flex and its commitments to Flex in the future, Adobe Flash Player and Adobe AIR security), and is a part of a larger process of trying to provide clear and open communications around our thinking and plans for the Flash platform.

The primary goal of the whitepaper is to have a single definitive resource that provides clear insight into Adobe’s plans and thinking around the roadmap for the Flash runtimes.

While in the past we have been open around our plans for the Flash runtimes, there was never a single resource where developers could find all of the latest thinking and plans around those runtimes. News and information was often spread across multiple resources, including the Adobe website, Adobe blogs, personal blogs, forum posts, and even tweets. We will still leverage these various means of communications, but they will build on top of the whitepaper. As our thinking and plans around the Flash runtimes evolve, we will update the whitepaper with those new plans.

This is also part of some more extensive changes at Adobe to help us avoid some of the communication missteps which have caused so much consternation and frustration over the past couple of months. Not only does the publication of the whitepaper give us a clear and concise way to publish information and plans around the Flash runtimes, it also provides developers with a definitive resources on where to get the most current information around the Flash platform.

This speaks to another goal of the whitepapers. We understand that we have damaged our trust and credibility with the community over how we have communicated some of the recent changes around the Flash platform and that trying to regain that trust is a long term process. We have to be clear and open around our plans around the Flash runtimes, and then demonstrate that we can follow up those plans with actions. This whitepaper lays the foundation of the first part of that, and hopefully our actions and runtime releases over the next 6 to 12 months will demonstrate the second part.

Finally, as part of the release of the whitepaper, I and some other members of the Flash and evangelist teams will be visiting user groups world wide. This will be an opportunity to go over the roadmap in more detail, have a frank and open discussion around recent changes around Flash, as well as discuss Flash’s role on the web and how it related to HTML5. The first set of meetings are over the next two weeks in Europe, and we will announce more for North and South America, and Asia over the next couple of weeks. If you would be interested in hosting a meeting, just shoot me an email at mesh@adobe.com.

We are already planning an update for the whitepaper in a couple of weeks, so if you find anything is not clear, or would like it to cover other topics, please post them in the comments, or shoot me an email.

If you follow me on twitter, then you may have noticed that I have been working on a white-paper laying out the roadmap and strategy for the Flash runtimes (Flash Player and Adobe AIR). The white-paper is going through internal review now, and should be available in the next 7 to 10 days.

As part of the release of the white-paper, I, along with Lee Brimelow, and Thibault Imbert will be spending two weeks in Europe meeting with the Flash community and laying out Adobe’s vision and strategy for the Flash runtimes. This will be a good opportunity to speak directly with Adobe, ask questions, and general discuss recent changes around the Flash Player.

Here are the cities we will be visiting. Click through the links to find more information and to register for the events.

• February 22 : Paris
• February 23 : London
• February 26 : FITC Amsterdam
• February 29 : Hamburg
• March 02 : Lisbon

In addition to discussing the Flash roadmap, we will be showing off the latest Flash and Adobe AIR content, give some sneak peaks on upcoming releases, and setting aside plenty of time for open discussions and Q&A.

The Flex team will be in Europe at the same time, discussing the future of Adobe Flex under the Apache organization. You can find information on the Flex tour here.

We plan similar tours over the next couple of months for North and South America, and Asia. Ill post more info here once we have more details.

I have worked with Flash and been part of the Flash community for about 12 or 13 years (over 10 of those with Macromedia and Adobe). Over that time there have been a lot of ups and down, but I think that the past couple of days have been some of the most difficult of my career. I wanted to make a post which will hopefully clarify some of the news from the past couple of days, and provide some more context around what is going on.

First, and foremost, a couple of days ago Adobe announced the following:

1. We are focusing work around the Flash Platform on:
   
   • Mobile Applications created with Adobe AIR.
   • Expressive content (particularly games and video) in the browser on the desktop via the Flash Player.
2. We are further increasing the amount of resources (both money and engineer) toward HTML5 tools, solutions and browsers.
3. We are no longer going to be actively developing the Flash Player for Mobile Browsers.

It is this last point which received the most attention, caused the most confusion, and essentially overshadowed all of the other information. Given the very public recent history of the Flash Player on devices this was understandable. However, it is clear that we did not do a good job of communicating why we are are making this shift in strategy. I know how frustrating this has been for the Flash community, and for that I want to apologize. Our goal was to be very clear about WHAT we were doing, but in doing so, we didn’t pay enough attention to explaining WHY we were doing it.

So, please bear with me as this may up being a long post, but I want to talk about the why, as well as discuss what we see as the role of Flash on the web (especially in relation to HTML5).

First, I want to make it very clear that we are continuing to work on Adobe AIR for mobile applications, and have seen an increasing number of successful applications created with Adobe AIR. What we are halting is further development on the Flash Player plugin for mobile browsers. We will continue to provide critical bug fixes and security updates for existing device configuration, as well as continue to distribute the current player. At the same time, we are further increasing our investment (both in resources and engineers) in HTML5. I am not going to go into too much detail on this today, but, in general, we are shifting some resources from the Flash Platform and towards HTML5.

The decision to stop development of the Flash Player plugin for mobile browsers was part of a larger strategic shift at Adobe, one which includes a greater shift in focus toward HTML5, as well as the Adobe Creative Cloud and the services that it provides. I am not going to go into detail on that today (I’ll save that for another post), but you can get in-depth information on Adobe’s strategy as a company by watching the Financial Analyst meeting (summary, videos) from a couple of days ago (it is long, but worth it).

Why did Adobe Decide to no longer develop the Flash Player for Mobile Browsers?

Considering how politically charged the issue has been, the decision to stop development of the Flash Player for Mobile Browsers was not an easy decision. However, at the end of the day, there were a number of items that made it clear that putting resources towards its continued development would not be the best use of resources.

The Flash Player was not going to achieve the same ubiquity on mobile as it has on the desktop

This one should be pretty apparent, but given the fragmentation of the mobile market, and the fact that one of the leading mobile platforms (Apple’s iOS) was not going to allow the Flash Player in the browser, the Flash Player was not on track to reach anywhere near the ubiquity of the Flash Player on desktops.

This effectively meant that if you wanted to use Flash to deliver a rich web experience in the browser on mobile devices you would have to provide both a Flash based, as well as HTML5 based solution. Given the strong support for HTML5 across modern mobile devices, it simply made more sense to create an HTML5 based solution. Now, there are some exceptions to this, especially around advanced video content, but it is very clear that HTML5 is the solution to turn to if you want to provide a richer browser based experience that works across browsers on mobile devices.

Just to be very clear on this. No matter what we did, the Flash Player was not going to be available on Apple’s iOS anytime in the foreseeable future.

Ubiquity of HTML5 on mobile browsers

Related to the point above, HTML5 has very strong support on modern mobile devices and tablets. Indeed, on mobile devices, it has a level of ubiquity similar to what the Flash Player has on the desktop. While performance and implementations haven’t always been great or consistent across devices, they have continued to improve at a pretty dramatic rate (just look at the insane Canvas performance increases between iOS 4 and 5).

This new generation of smart phones and tablets (ushered in by the original Apple iPhone) are only a couple of years old. Because of this, the rendering engines deployed on these devices (most WebKit based) were all also relatively new and modern. The end result is that when developing for mobile devices and tablets today, you don’t have to deal with legacy browsers as you do on the desktop.

On mobile devices HTML5 provides a similar level of ubiquity that the Flash Player provides on the desktop. It is the best technology for creating and deploying rich content to the browser across mobile platforms.

Our goal has always been to obtain the same level of ubiquity for the Flash Player on mobile browsers, but, at the end of the day, it is something that did not, and was not going to happen.

Differences in how users consume rich content on mobile devices compared to the desktop

On the desktop, users are used to consuming rich content (such as games and applications) via both the browser and native applications. However, on mobile devices users are much more likely to look exclusively toward applications for consuming rich content. The mobile platforms make it very easy to discover new content and applications by providing tight integration between the app stores (Apple App Store, Android Marketplace, etc..) and the mobile operating system. In general, users do not look to the web on mobile devices for finding and consuming rich content (such as games and applications).

There are a number of reasons for this, including:

• Differences in screen sizes, resolution and interaction models between mobile devices and desktop PCs
• Generally slower, and higher latency network connections (which is often metered) on mobile devices, which makes it cumbersome, sometimes expensive, and sometimes impossible to repeatedly load rich content from the web on demand.
• The tight integration with the underlying operating systems that native applications provide.
• The tight integration between mobile app stores and the mobile operating systems, which removes most of the friction for discovering new content.

When a user wants to play a game on a mobile device they turn to the app store for their platform. This makes it very easy for them to discover and install new content. This content can then be quickly accessed regardless of their network connectivity.

Essentially, users’ preferences to consume rich content on mobile devices via applications means that there is not as much need or demand for the Flash Player on mobile devices as there is on the desktop.

Scalability of developing plugins for mobile browsers

Developing the Flash Player for mobile browsers has proven to require much more resources than we anticipated. When building the player for desktop browsers, we can target well defined plugin APIs provided by the browsers. While we do have close relationships will all of the browser vendors (including Google, Apple, Firefox, Microsoft), as a general rule we can do most of our development using the existing APIs.

However, in the mobile ecosystem, we have to work very closely with other companies engineers on a number of levels:

1. Mobile Operating System Vendors (such as Google and RIM)
2. Hardware Device Manufacturers (such as Motorola and Samsung)
3. Component Manufacturers (such as NVIDIA)

While we have good relationships on all levels of this ecosystem, having to do specific work for different combinations of OS, Hardware and event components has taken a significant amount of resources. For each new device, browser and operating system released, the resources required to develop, test and maintain the Flash Player also increases. This is something that we realized is simply not scalable or sustainable.

I have seen a couple of questions asking how Adobe AIR is different. There are a couple of differences which make AIR development significantly less resource intensive, including a more well defined API that we can target, as well as not needing to worry about differences in browsers or new browser versions. Ultimately though, developers are building successful applications with Adobe AIR, and thus it makes sense for us to continue to invest in it.

Shifting some Resources from Flash to HTML5

Finally, given the growth of HTML5 on both mobile and desktop browsers, we decided to more evenly balance our resources dedicate between Flash and HTML5.

Halting development on the Flash Player for mobile devices frees up resources for HTML5 development (tooling, frameworks, browsers).

I understand that not everyone may not agree with all of the conclusions drawn above. However, given these points, along with the increasing complexity and costs of developing the Flash Player for mobile browsers, we decided that further development was not the best use of our engineering resources.

What does this mean for the Flash Platform in General?

While there was some frustration around our dropping development of the Flash Player for mobile browsers, the main thing I saw was concern and confusion about how this would affect the Flash Platform as a whole. Were we still committed to it? Would we stop developing the Flash Player for the desktop? Is Flash really dead?

So, just to be very clear, contrary to what many have declared, Flash is not dead. It’s role and focus has shifted but we feel that it still fills important roles both on the web and mobile platforms.

Adobe AIR

We are continuing to develop Adobe AIR for both the desktop and mobile devices. Indeed, we have seen wide adoption of Adobe AIR for creating mobile applications and there have been a number of blockbuster mobile applications created using Adobe AIR. Some recent examples of applications created for mobile devices using Adobe AIR are Machinarium, Watch ESPN and my personal favorite, tweet hunt.

Flash Player for Desktop Browsers

We feel that Flash continues to play a vital role of enabling features and functionality on the web that are not otherwise possible. As such, we have a long term commitment to the Flash Player on desktops, and are actively working on the next Flash Player version.

Of course, with the growth and continued improved browser support of HTML5, the role of Flash will change. We feel that for the foreseeable future, Flash is particularly strong in delivering advanced video, as well as providing a robust, and graphically rich gaming platform. We are focusing our Flash Player efforts around these areas.

Some of the features currently being worked on for the Flash Player:

• Mouse Lock Support
• ActionScript Workers / Concurrency APIs
• Telemetry / Monocle Support
• Audio API improvements, especially for better handling of low latency audio
• New Datatypes for ActionScript 3

We are also making some long term, and significant architectural changes, which will benefit the Flash Player (and developers) for years to come. This is still in the early stages, and we will have more information in the coming months.

Adobe Flex

I know there are a lot of questions around Adobe Flex. We are writing a separate blog post focused just on Flex which should be up shortly. I will update this post when it is live.

Update : The Flex Team has posted more info here.

Flash Professional

I discussed the future of Flash Professional in a separate blog post yesterday, so I am not going go into detail on it here. As I stated yesterday, we are actively working on the next version of Flash Professional and have a long term commitment to it’s continued development.

HTML5 and Flash

Finally, I want to touch on some of my thoughts on Flash and HTML5.

From its beginning, Flash’s primary role has been to enable things on the web that were not otherwise possible. Over its history, this has included things such as animation, vector graphics, sound, video, webcam and microphone support, and more. Because of its ubiquity and fast rate of adoption, it was uniquely suited to quickly introduce new features to the web.

Overtime, many of these Flash features were added to the browser. Time and time again, as the browsers matured things which were once done exclusively in Flash, were eventually done in the browser. The Flash Player would then add new features and the cycle would continue. This has happened over the entire history of Flash, and I expect, will continue to happen. This was something that was good for users (who got richer content earlier), Adobe (who got to sell tools and technologies), and browser vendors (who could focus their efforts on features which the Flash Player had proven to be popular and viable).

The key point is this. If a Flash feature is successful, it will eventually be integrated into the browser, and developers and users will access it more and more via the browser and not Flash.

With the renewed competition in the browser market and the subsequent acceleration of new HTML5 features being added to browsers, the number of things possible in the browser has dramatically increased. This includes a lot of overlap with features that were once exclusive to the Flash Player. While it will still be a while before HTML5 / CSS3 features have the same ubiquity as the Flash Player currently has, the trend is very clear. A lot of the things that you have done via Flash in the past, will increasingly be done via HTML5 and CSS3 directly in the browser.

I think that is important enough that I should repeat it.

A lot of the things that you have done via Flash in the past, will increasingly be done via HTML5 and CSS3 directly in the browser.

I know that this is a bit scary for a lot of people who have made their career working with Flash. I completely get that. However, I think it is a HUGE opportunity for the Flash community. As browser support for richer content and motion graphics improves, so will demand for designers and developers who have experience working with motion graphics on the web. The Flash community has been doing this type of work on the web for over a decade and is uniquely qualified to fill demand for similar work in the browser. I don’t think it is a coincidence that some of the most cutting edge motion graphics work being done in HTML5 today is being done by developers and agencies with extensive experience in Flash (such as Grant Skinner, Branden Hall, Big Spaceship, etc…).

I am not suggesting that all Flash content should or will be done in HTML5. You have to look at each project on a case by case basis and make a decision based on development costs, target platforms and user experience. Regardless, your customers are going to ask about HTML5, and you should put yourself in a position to best meet their needs, regardless of technology or platform.

This has ended up much longer than I had expected, but I wanted to share a lot of stuff that has been going through my head over the past couple of days. Again, I understand the frustration about how all of this was originally communicated, and I want to apologize for that. I think it is pretty clear that we did not communicate the news and our views around Flash as clearly as we should have.

Please post and questions / comments below. Please keep all comments constructive and on topic (or else they may be moderated).

Yesterday was probably one of the most overwhelming days of my entire career. First, Adobe informed developers that we are going to stop developing the Flash Player for mobile browsers, then news came out that there were layoffs at Adobe, and finally, Adobe held a financial analyst meeting where we spelled out the Creative Cloud, and the fundamental strategic shift Adobe is making.

All of this news is a lot to digest at once, and I know that there are a lot of questions and concerns from the community about what all of this means. I am working on another blog post which will address this from the Flash community’s standpoint, but I wanted to make a quick post and debunk a rumor that has been going around about the future of Flash Professional.

I have seen a couple of versions of it, but basically, the rumor is that the entire Flash Authoring team was laid off and that we are no longer developing Flash Professional.

Both of these rumors are false.

We are actively working on the next version of Flash Professional and have a long term commitment to it’s continued development.

While there were layoffs on the team (as there were on a lot of other teams), we still have a team actively working on future versions of the tool. The Flash Professional team continues to have offices around the world, just as they did prior to the announcements. The core team, including product management and engineering members, continue and will continue to be based in San Francisco.

I can’t go into a ton of detail about all of the new features and improvements included in the next version of Flash Professional (we gave a sneak of some of them at FOTB Brighton last month), but some of the new features include:

• SpriteSheet export for both Starling and HTML5 / Canvas. Lee Brimelow has a sneak here.
• Support for packaging and exporting AIR applications for mobile that leverage native extensions.
• Mobile prototyping and simulation for AIR apps.

In addition to working on new features, we are also in the process of a pretty fundamental re-factoring and modernization of the tool’s code base, which, among other things includes a de-carbonization of the tool on the mac platform. This is longer term project, being done in parallel with CS 6.0 development.

I am going to be speaking at FITC Tokyo in a couple of weeks, and will be showing some of the latest stuff we have been working on in Flash Professional.

I understand the confusion and frustration around everything that has been going on, and I know how difficult the past couple of days have been (probably the most difficult of my entire career). As I mentioned above, I am working on a broader blog post to discuss some of the news from yesterday, which will hopefully provide more information and clarification around all of the changes going on.

Please post any questions in the comments, and please keep comments on topic.

UPDATE : Just a quick reminder, but please keep comments on topic (about Flash Professional). I know there are a lot of questions about just about everything Flash, and I am working on a post to address them.

UPDATE : Added some clarification around team composition.

I am in Tokyo for the week and just spoke at the Tokyo HTML5 Camp, giving a talk on some of the lessons learned from working on theexpressiveweb.com, and talking about Adobe and HTML. I have posted the slides with notes online.

Download Slides (26mb pdf).

If you have any questions or suggestions please post them in the comments.

I have been playing around a lot lately with motion graphics created using HTML5 and / or CSS3. One of my favorite new features is CSS Transitions, which makes it super simple to animate element properties between two states.

However, I ran into a gotcha the other day, and wanted to make a quick blog post in case anyone else runs into it in the future. Basically, if you change a property that a CSS Transition is monitoring in the same script loop that you add the element to the DOM, the CSS Transition will not take affect. Instead, the element will be drawn with the new properties, and will not animate to those properties.

Here is an example that shows the issue, as well as how to fix it.

First the relevant styles for the CSS Transition:

.box
{
	/*...*/
	-webkit-transition: all 0.7s ease;
	-moz-transition: all 0.7s ease;
	-o-transition: all 0.7s ease;
	transition: all 0.7s ease;
}

Notice how when you click the example the cirlce just appears on the right, instead of appearing on the left, and then animating to the right as it should.

Here is the relevant code that creates the div and updates it position:

function onMouseClick()
{
	if(box)
	{
		//remove existing box from dom
		document.body.removeChild(box);
	}
 
	//create the div
	box = document.createElement("div");
	box.className = "box";
 
	//add to dom
	document.body.appendChild(box);
 
	//position in middle / left of screen
	box.style.left = "10px";
	box.style.top = (window.innerHeight / 2) + "px";
 
	//set position we want div to animate to (using the CSS Transition)
	//NOTE : This will not animate, but will instead just be moved / drawn
	//in the final position
	//need to delay this call by 20 ms
	box.style.left = (window.innerWidth - 100) + "px";
}

View / Download Code

The solution, is to delay changing the properties that you want to animate by a short time interval. I have found that for most browsers a delay of as little as one second is enough to allow the CSS transition to take effect. However, for Firefox, the first time an element is added, I had to add a delay of 20ms in order to ensure the element animated correctly. However, subsequent animations could use a 1 ms delay. I am not sure if the delay interval is browser specific, or is related to how fast the users CPU is.

Setting the delay can be done using setTimeout.

Here is the update example, and code:

function onMouseClick()
{
	if(box)
	{
		//remove existing div from dom
		document.body.removeChild(box);
	}
 
	//create the div
	box = document.createElement("div");
	box.className = "box";
 
	//add to dom
	document.body.appendChild(box);
 
	//position in middle / left of screen
	box.style.left = "10px";
	box.style.top = (window.innerHeight / 2) + "px";
 
	//delay updating position so it will animate correctly
	setTimeout(moveBox, 20, box);
}
 
function moveBox(box)
{
	box.style.left = (window.innerWidth - 100) + "px";
}

View / Download Code

The only change, is that we moved the code to update the divs position to its own function. This allows us to then use setTimeout to delay the code from being called for 1 ms. By doing this, the div will be added to the dom, and positioned in the correct initial position, and then animate to its new position.

Here is another example that uses setTimeout to animate newly created DIVs.

View / Download Code

Post in the comments if you have any questions or suggestions.

UPDATE : June 6, 2012 : Due to a change in the Justin.tv APIs, this extension no longer works with Twitch.tv accounts. I have created a new extension, called Twitch Live which works with Twitch.tv accounts. Sorry about the hassle.

Since I started playing Starcraft 2, I have become a pretty big fan of e-sports, and in particular, of watching streams of games. The most popular site for streaming is Justin.tv, where you can find tons of high level gamers streaming their gameplay. However, Justin.tv’s site does not make it easy to find out which of your favorite streams are live at any particular time.

So, to solve this problem, I created JTV Live, a Google Chrome extension for helping you track which of your favorite Justin.tv streams are live.

Using the extension is pretty simple. Once you install it, a small TV / Monitor icon will be placed in the top right of your browser bar. Right click on the icon, select options, and enter your Justin.tv user name.

Once you have done this, you can click the icon, and it will show you a list of which of your favorite Justin.tv streams are currently online as well as how many people are viewing each stream.

Big thanks to Ben Griffith for working on the design of the extension and creating the icon.

If you run into any issues, or have any suggestions please post them in the comments.

I have been playing a lot of Starcaft 2 lately, and really getting into the entire community. One part of the community that I recently discovered has been live streams of games (some from pros) via sites like justin.tv and ustream.com. There are plenty of articles online talking about how to stream your desktop on Windows based machines, but virtually none on how to do it from a Mac. This article will show how to use Adobe Flash Media Live Encoder (and a couple of other tools) to live stream your desktop to justin.tv (although the setup would also work for other streaming sites).

I am going to divide the article up into a couple of sections. The first part will show how to get a basic desktop stream going, including system sound. The second section will show a more advanced sound setup that allows you to also broadcast your microphone, and audio from other apps such as skype.

Basic Desktop Streaming Setup

The basic setup will allow us to stream our desktop and system audio to justin.tv. This requires the following software:

• Adobe Flash Media Live Encoder (FMLE) 3.2 for Mac : Encodes and streams video and audio to justin.tv
• CamTwist : Used to capture desktop as a video source
• Soundflower : Utility used to capture and redirect system output
• justin.tv config file : Only required if you are streaming to justin.tv (link provided below)

The basic setup is pretty simple, and essentially requires setting up CamTwist to capture your desktop as a video source, and have Flash Media Live Encoder take that video source, combine it with the system audio, and stream it to the server (in this case justin.tv).

A Note on Performance

Keep in mind that encoding and broadcasting live video feeds can be very CPU intensive, and thus may require significant system resources. Depending on what you are streaming, this may affect other applications running on your system, or even the quality of the stream.

Configuring CamTwist

First, download and install CamTwist. Once it is installed, open it up, and under the Step 1 section, double click “Desktop” (not “Desktop+”). “Desktop+” allows you to select a specific window to broadcast, but since we are going to be broadcasting our entire desktop, we will just use the Desktop preset.

You can save these settings by clicking the “Save Setup” button.

Do not select any effects in Step 2.

In Step 3 make sure that “Desktop” is included and checked. In the settings window, make sure that screen is set to “Main Screen”. This ensures that only the main screen will be broadcast (which only matters if you have multiple monitors).

Also make sure that “Full Screen” and “Show mouse pointer (simulated)” are selected.

Once you have set all of these settings, you can save them by clicking the “Save Setup” button.

Now, open the preferences (CamTwist > Preferences), and select the “General Tab”. Set the frame rate to the same frame rate you plan to encode at. I am using 24 FPS. The higher the FPS, the smoother the video, but the more bandwidth and CPU required to encode and transmit it.

Set video size to “Custom” and set it to your desktop resolution. In my case, I have it set to 1920 x 1200, which is my native desktop resolution. Set it to the native resolution even if you are going to broadcast at a lower resolution. We will have Adobe Flash Media Live Encoder scale the video down, as my experience has been that it does it much more efficiently than CamTwist.

Once you have set the preferences, close the window and restart CamTwist. Make sure the “Desktop” section is selected. You can test that everything is working by selecting Tools > Preview, which will give you a small preview of the video being captured.

Configuring Audio with Soundflower

In order to capture audio, we need a way to capture the system’s audio output, and make it an input for Flash Media Live encoder. Mac OS X does not have native support for doing this, but the free Soundflower utility enabled this.

Soundflower is a utility that can combine multiple audio outputs and redirect them into a single audio output. We can use this to capture system audio, and pass it on to FMLE to include the audio for our video stream.

First, download and install Soundflower. Once it is installed, launch it. It won’t open an application window, but will add a small menu item icon (a flower) on the top right of the menu bar.

We need to tell OS X to direct system audio output to Soundflower. Open Sound preferences (System Preferences > Sound > Output) and select “Soundflower (2ch)”.

Basically, anything that you would hear through your speakers will now be directed first through Soundflower.

Next, click the Soundflower icon on the menu bar, and for “Soundflower (2ch)” select what you would normally have set as your system output (such as headphone, or Line-Out). This will redirect the audio through Soundflower, and pass it through your normal output so you can still hear it. However, because it is first directed through Soundflower, we can now also use that as an input source in FMLE.

There is a lot more advanced stuff we can do with Soundflower, which we will cover later in the article.

Configuring Adobe Flash Media Live Encoder

Adobe Flash Media Live Encoder (FMLE) is a free tool provided by Adobe that can take a video and audio feed, and create either a VP6 or H.264 encoded video stream that can be streamed to servers and sites such as justin.tv.

Download and install the latest version of FMLE (this article is using version 3.2). If CamTwist is not already running, go ahead and open it. Once FMLE is installed, open it up.

Now, before we start changing settings, we need to first download a config file for our specific justin.tv account. This will include information specific to our account that justin.tv uses to determine which account the stream is associated with. If you are not using justin.tv, you may to skip this section, although you may need to look up docs on how to configure the stream for your specific server.

Log into your justin.tv account, and then visit this page. At the bottom of the page is section for “Flash Media Encoder”. Click the “Config File” button. This is the XML config file for FMLE specific for your justin.tv account. Click the button and download the file to your desktop.

Note : This file will allow anyone who has it to stream to your justin.tv account, so be careful to protect it.

Once you have downloaded the file, we are ready to import it into FMLE. Switch to FMLE and select File > Open Profile. You may get a warning that some tags are not support, and defaults are being used. Just ignore this.

If you look in the output panel on the right side of FMLE, you should see the FMS URL set to something like: rtmp://live.justin.tv/app, and the stream attribute have a value similar to: live_12345678_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.

Again, this second string is specific to your account, and will allow anyone to stream to your justin.tv account. You can hide the panel it is shown in (so it wont be displayed on your stream), by selecting “Panel Options” and setting it to “Meta Data” (so the panel wont be displayed). Note that you may need to do this each time your start FMLE.

We are now ready to set up the encoding options for FMLE. First, we will setup the video encoding settings. Some of the settings may vary depending on your system, but I will point out where and why you might want to tweak them.

FMLE : Video Settings

First, in the video panel, make sure that “Video” is checked. For “Device”, select “CamTwist”. If “CamTwist” does not appear as an option, make sure that CamTwist is running and is set to broadcast the desktop. If it isn’t, start it, and then restart FMLE.

Once you have selected CamTwist, you can confirm that it is working by making sure “Input Video” is selected in the “Preview” panel at the top. With this selected, you should see the video feed preview of your desktop.

Next, we need to set the video codec we will be encoding to as well as its options. There is a choice between H.264 and VP6. I am not going to go into a discussion about which is better. In general though H.264 offers higher quality at lower bitrates, with slightly higher CPU usage, while VP6 offers lower quality, with higher bitrates and slightly lower CPU usage. For this article, I will be using H.264 to stream to the server.

Select “H.264″ as the Format, and click the little wrench icon. This will open a panel where we can set additional setting specific to the codec.

Set the profile to “Main”.

The “Level” value will vary depending on the resolution you will be encoding at. In our case, I will be encoding at 720p (1280 x 720) at 24 FPS, so I need to set the level to “3.1″. You can find a list of levels and resolutions / FPS in the H.264 wikipedia article.

Finally, we need to set the Keyframe Frequency. This determines how frequently keyframes (complete captures of the image) are inserted into the stream. We will use the default of “5″.

Once you have set the codec settings, click the “OK” button.

Back in FMLE, set the Frame Rate to “24.00″ fps. Higher framerates provide smoother video, but require more CPU and bandwidth. Lower framerates provide choppier video, but require less CPU and bandwidth. I think that 24 FPS is a good middle ground, but feel free to experiment. Just remember that if you change this, you should also change it in the CamTwist preferences, so they are the same.

Set “Input Size” to the size that you will be broadcasting / encoding at. We do this, even though the input received from CamTwist is a higher resolution. FMLE will scale the video to the appropriate size. It has been my experience that this uses less CPU that having CamTwist do the scaling.

We could set input size to the full resolution of the input stream, and then have the output size as a scaled down stream. However, in my case, i have a 16:10 stream resolution which FMLE currently doesn’t support, which would result in part of the stream being chopped at the top and bottom. By having the scaling done at the Input Size, I was able to get the content scaled correctly, without having any part of the stream cropped. (If anyone has more feedback on this, please post it in the comments.).

Make sure that “Maintain Aspect Ratio” is also checked for “Input Size”. This prevents the video from being skewed when it is scaled.

Now, FMLE can encode and output multiple streams and sizes (which I believe justin.tv supports), however, we will just be broadcasting one stream.

Make sure the first stream is checked, and set the “Bit Rate” to “1000″ kbps. This setting basically specifies how much data is included in the stream. The higher the value, the clearer the image (less compression) and the more bandwidth required. The main thing to consider when setting this is how much upstream bandwidth you have available. You can get a general idea by doing a speed test and looking at the upload results. On the right of the stream section in FMLE, will be an estimate of the total bandwidth required to stream at the current setting. You want to make sure that you have some buffer between what you are sending, and what your upstream bandwidth is. Otherwise, viewers of your stream may see frequent drops and stutters.

To start with, I would set it at 1000, test, and then move the value up (in increments of 500) until you find a good balance between bandwidth usage and video quality.

Set the “Output Size” to the output size you want to stream at. For this article, we will be streaming at 720p (“1280 x 720″), which is a standard HD resolution, and I feel provides a good tradeoff for providing high quality stream for the bandwidth required. Again, adjusting the resolution will affect the amount of bandwidth required for the stream.

You can leave both “Deinterlace” (since we are running at 720p) and “Timecode” unchecked.

FMLE : Audio Settings

Audio settings are a bit less involved than video settings, and mostly requires finding a balance between quality and bandwidth required.

Make sure that “Audio” is checked at the top of the Audio section.

For “Device”, select “Soundflower (2ch)”. If this does not appear, make sure Soundflower is running. If it is not, start it and restart FMLE.

Once it is set, you can test that is is working by checking “Audio” in the preview panel and thenm play an audio source on your system. You should see the audio levels reflected in the preview panel (on the right). You should also be able to hear the audio through your headphones / speakers. If you dont, make sure that you have set the output correctly in Soundflower (see above).

For Format, select “Mp3″, and set “Channels” to “Stereo” and “Sample Rate” to “44100″.

The “Bit Rate” setting determines how much data is used to encode the audio. Higher values mean clearer audio / less compression but require more bandwidth. Unless you are streaming high quality audio / music, then 128 Kbps should be fine, and depending on your bandwidth, you may want to set it slightly lower.

Turn the volume all the way up.

At this point, look at the bandwidth required estimate under the Volume setting. Make sure this is not too high in relation to your upstream bandwidth. You want to ensure there is some padding for data spikes, or if your available bandwidth goes down a bit. If the bandwidth required is too high, then go through and tweak the settings (see above) until you get the bandwidth to an acceptable level. You may need to do some live testing to find the best compromise between audio / video quality and required bandwidth.

Now that we have entered all of the settings, we want to save our FMLE profile, so we can easily use it again. Select File > Save Profile and save the profile onto your system. By default, FMLE will open with the last settings used, but you can also open the saved profile by going to File > Open Profile.

All that is left to do, is to start the stream, and make sure everything is working with justin.tv. Click the green “Start” button and switch over to your justin.tv channel. You should see your desktop and audio being streamed on your channel (there may be some delay between your desktop and the playback on the stream).

Make sure audio and video quality are good. If they are not, then stop the stream, tweak the settings and try again.

If you run into any errors, just check the “Encoding Log” panel in FMLE (which will open when you start the stream). You can also get general statistics on your stream in the Encoding pane which can be useful for trying to track down issues.

General Trouble Shooting

Audio Not working

If audio is not working, make sure:

• Soundflower is running
• Soundflower was launched before FMLE was opened
• Soundflower is set correctly as the Output in system Sound preferences
• Try stopping and starting the stream in FMLE

If audio is working on stream, but not locally, make sure that:

• Correct output is set in Soundflower

Video not working

If the video stream is not working:

• Make sure that CamTwist is running, and is configured to output the desktop
• Make sure that CamTwist was started before FMLE was started
• Make sure that Video is selected in FMLE
• Make sure you you downloaded and loaded the justin.tv config file
• Try stopping and starting the stream in FMLE

If video is choppy on justin.tv

• Adjust audio and video settings in FMLE
  • Video output resolution
  • Video output Bit Rate
  • Audio output Bit Rate
  • Increase Keyframe interval for H.264
• Check system resources (view in Activity Monitor) and make sure your system has enough resources to encode and stream audio in real time
• Close any applications not necessary to streaming
• Turn off “Video Input”, “Video Output”, and “Audio” previews in FMLE.

Advanced Configuration for Streaming your desktop on Mac OS X

The information above is all you need if you just want to stream your desktop and system audio to a remote server (such as justin.tv). However, if you want be able to also stream your microphone input or entire skype calls / conversations, then there are a couple of more steps you need to take.

For this section, we will be using all of the software above, along with:

• LineIn : Allows you to redirect system audio inputs to audio outputs.

By using LineIn, in conjunction with the applications above, you can have very advanced control over how you mix your audio on the desktop, including which audio outputs are included in your stream, and on your desktop.

For this example, we will be setting up our system so that:

• Microphone input is included in the stream, but not included in the local system output
• Skype conversations (both local and remote) are included in the stream

First, download LineIn, and copy it to your applications folder. We are going to need to use two instances of LineIn, and since Mac OS X will only allow us to launch one instance of an app at a time, we need to make a copy of the app and rename it. So, copy the LineIn application, and rename the copy to LineIn2.

Launch both LineIn and LineIn2 (their windows may overlap when they launch).

One feature of Soundflower which we did not discuss above, it that it creates two separate output channel (one with 2 channels, and one with 16 channels). We can use this, in conjunction with LineIn, to provide different audio feeds for the desktop and the stream.

In the first LineIn window, set the “Input from” to your local microphone input. Then, set the “Output to” “Soundflower (2ch)”. This basically takes the input from your microphone, and redirects it to the Soundflower (2ch) output (being used by FMLE).

Next, click the “Pass Thru” button to enable the changes we just made.

At this point, if you have configured your streaming according the the instructions above, your microphone input will now be included in the audio for your stream. However, if you test this, you will also notice that the microphone input is also output to your system audio (since system Sound output is set to Soundflower (2ch)). Hearing yourself in your speakers / headphone as you speak can be very confusing and distracting (not to mention annoying), so we need to configure things so microphone input is not output locally.

This is where the second instance of LineIn comes in. If you havent already, launch LineIn2. Set the “Input from” to “Soundflower (16ch)” and set the “Output to” to “Soundflower (2ch)”. Once you have done this, click the “Pass Thru” button to enable the changes.

Next, we need to set all system audio output to go to “Soundflower (16ch)”. Open system Sound Output settings (System Preferences > Sound > Output) and set output to “Soundflower (16ch)”. Now, all system audio output will go to “Soundflower (16ch)”, which is then being redirected (by LineIn) to “Sunflower (2ch)”.

At this point, we now have two separate Soundflower channels. One (“Soundflower (2ch)”) includes both system audio and microphone input, and one (“Soundflower 16ch”) includes all system audio, minus the microphone input.

We don’t need to change anything in FMLE, since it is already set to use Soundflower (2ch) as its audio input. However, in order to hear the correct audio locally, we need to change the Soundflower local output. Click the Soundflower icon on the menu bar. Set “Soundflower (2ch)” to “None (Off)”, and set “Soundflower (16ch)” to the local output you want to use (which ever output your speakers / headphone is connected to).

You should now be able to hear all system audio locally without hearing the microphone. However, the stream includes the audio from both the local system and microphone.

At this point, anything you output to “Soundflower (16ch)” will be included in the stream (and played locally). This means you can set other applications, such as Skype, to also output to Soundflower (16ch) in order to include them in the stream.

Configuring this in Skype is easy. Just open Skype, and launch the Audio / Video preferences (Skype > Preferences > Audio / Video). Set the “Speakers” to “Soundflower (16ch)” and close the preferences. Now any audio that comes through Skype, will be included in the stream.

You can do this with any application that allows you to specify sound output. You just need to keep in mind that you only have 16 channels total (which should be plenty).

With this setup, you can stream your desktop, system audio, local microphone and skype conversations all of the same time (useful, for example, if you are streaming multiple player games while playing / chatting with friends).

Conclusion

While setting up desktop streaming on Mac OS X can seem a bit daunting at first, it is not too difficult. Once you do get it setup with the configuration describe in this article, you have a lot of flexibility in how things are broadcast, including which audio sources are included / excluded.

Additional Resources

Applications

• Adobe Flash Media Encoder 3.2
• CamTwist
• Soundflower
• LineIn

Articles / Resources

• Beginners Guide to Desktop Streaming : Great walkthrough for streaming your desktop from Windows
• Using CamTwist with Justin.tv
• Adobe Flash Media Live Encoder Documentation
• How To Make Your Own Web TV Show : Great video series by Sean “Day[9]” Plott.
• Justin.tv forums
• Adobe Flash Media Live Encoder Forums
• TeamLiquid Forums Stream Quality Guide

If you have any questions or suggestions, then post them in the comments.