My friend Jan has a great article on H.264 video production on his site. You can read the first part below, and catch the rest on his blog.

Introduction
As a producer of video on the web, you know that you're judged by the quality of your video. In this regard, many producers are considering converting from the venerable On2 VP6 codec to H.264. H.264 offers better visual quality than VP6, and the AAC audio codec offers much better quality than the MP3 codec paired with VP6. Starting with Adobe Flash Player 9 Update 3, you could play back files encoded in H.264/AAC formats. As of September 2008, the penetration of H.264/AAC-compatible players exceeded 89% in all Internet-connected PCs. No wonder they're switching over.

This article first discusses the issues involved in such a changeover, including the potential requirement for royalties. I then describe the H.264-specific encoding parameters offered by most encoding programs. Finally, I cover how you can produce H.264 video with Adobe Media Encoder CS4 and Adobe Flash Media Encoding Server 3.5.

The following post has been sitting in my drafts folder for a while and I wasn't sure whether to publish or not. Today I decided I would, and it was after reading a very interesting article by Mike Slinn on InsideRIA. It talks about Adobe's lack of focus on its developer community, and how a shift in startegy may mean winning the RIA market for Adobe.

I'm always hesitant posting an article such as the one that follows as it will most likely be perceived as mainly negative by Adobe and its employees, many of which I know personally and rate very highly. I realise that there are people behind the software that this corporate behemoth churns out and it is for that reason that I'd like to say upfront that everything posted here has Adobe best interests in mind. I desperately want Adobe to succeed in the RIA market (and commonly they are doing a good job - but could do better...) and it is frustrating to see them making decisions that I think are not in their best long term interest.

One of my recent posts to the FlashMedia List seems to have struck a nerve when I asked if anyone there had tried out a Java application called JScrCap yet. According to its author, a developer can 'put this Java code on your web site as a Java applet and get browser-independent, platform-independent screen sharing solution with minimal installation efforts from end users'.

Note: off topic post coming up.

I've just come across a link that describes how to enable tethering on the iPhone 3G using the 3.0 software update that was released yesterday. Most of the guides I found seemed a bit complex and involved messing around in the Terminal - something that a lot of users find intimidating. But then I came across the following link (which you should access directly from your iPhone's web browser): http://help.benm.at/tethering.php
From the list that shows select your country (I chose UK), and your network provider (for most this would be O2). I installed the profile when prompted - do this at your own risk. Saying that, it's just a bunch of network profile settings so you can't really break anything much on your phone. But still, don't blame me, it's your phone.

Now that the network settings are updated you need to pair your phone with your computer via Bluetooth. To use the iPhone as a modem with a Mac, it must be running Mac OS X version 10.5.7 or later. I used my old Macbook Pro for this and the steps were as follows:

The release of the RTMP specs by Adobe yesterday has thrown up some questions on the nologies. And free Adobe tech support too - I suggest you FlashMedia List, and several people are asking themselves if it is a good idea to actually read them as doing so (or even simply downloading the specs) will mean that you agree to be bound to the RTMP license. In particular, the license includes a section about prohibited uses:

"Prohibited Uses
The rights and licenses granted by Adobe in the RTMP Specification, including those granted in the Patent License, are conditioned upon Your agreement to use the RTMP Specification for only streaming video, audio and/or data content and not to make, have made, use, sell, offer to sell, import or distribute: (i) any technology that intercepts streaming video, audio and/or data content for storage in any device or medium; or (ii) any technology that circumvents technological measures for the protection of audio, video and/or data content, including any of Adobe's secure RTMP measures. No right or license to any Adobe intellectual property is granted for such prohibited uses."

A long thread started on the list, and it was great to see not only community members participating but also several Adobe employees, including FMS engineers and even the product manager himself. Regardless of what you think of the RTMP license (I personally think it's a huge step in the right direction and underlines Adobe's commitment to removing barriers in this field) I think this level of engagement is rarely (ever?) seen by a multi-billion dollar company. Not only did Adobe engage, but they posted a wealth of information around the intricacies of RTMP/E/S security - many thanks to Kevin, Matthew, Asa, Jody and Brad (hope I didn't miss anyone) for regularly participating.

Further proof then (as if I didn't know) that the FlashMedia List is the place to be for the latest info on FMS, Flash video and its related technologies. And free Adobe tech support too - I suggest you subscribe right now :)
Once subscribed you can access the list archives here.

Today Adobe released the specification for Real Time Messaging Protocol (RMTP). The protocol documentation is available for Free, and describes how to use the messaging, chunking and handshake used by Flash Media Server. Adobe's secure protection measures are not exposed in this specification.

Adobe also announced a new product offering called the FMS Connector for C++ SDK, that is also available today for licensing. No details around the license terms have been made public yet, but anyone who is interested in the product can contact FMSOEMinquiries@adobe.com. The connector can be used to publish live audio, video and metadata into Flash Media Server.

I'm not sure if I have or haven't blogged this once before, but a second time can't hurt anyway. I've just spent another half hour trying to get a simple SMIL file to work in conjunction with the FLVPlayback component. Normally this should be quite easy: you establish the rtmp address of the video you want to play, assign this as the source property of the FLVPlayback component and you're done. Like so:
To transfer this to a SMIL file (handy if you are looking to support Dynamic Streaming in FMS) you would do this:

Looks plausible doesn't it? Shame then this DOES NOT WORK. Did you spot the error? Yeah, I'm such a noob, it's obvious isn't it?

I've noticed two separate presentations having been posted by separate authors, both covering the Peer-to-Peer features in Flash Player 10 in combination with Stratus.

The first, shorter video tutorial was authored by Tom Krcha of Adobe and guides you through building a simple P2P application leveraging Stratus. Watch it here.

The second presentation is an hour long session by Danny Patterson and goes into more depth than the previous tutorial. I haven't watched it in full but the part that I have seen looked very interesting and I definitely recommend you check it out.

It should be noted that Stratus is still in beta and detecting failed P2P connections can be a quite tricky. I would not recommend the P2P features for production use yet, instead you may want to rely on AFCS to handle the RTMP fallover for you.

Sumner Paine, Product Manager of the new Strobe media framework, recently presented on this very topic to the FMS User Group. You can see the recording here.

If you haven't heard about Strobe yet, the official summary is: "Strobe provides new delivery and monetization options for video distribution. Anyone can develop modules that plug into Strobe media players and enable things like advertising insertion, content delivery and syndication, micropayments, viewer authentication, transaction handling, and business model controls. With an open framework, the future of web video monetization can be developed collaboratively with lower costs and faster turnaround."

Watch the recording here.

My friend Jan was recently asked by a client for a list of H.264-related references. And Jan figured that if these references are worthwhile to his client, perhaps they might be worthwhile for you, so here they are. For much more great content around all things streaming check out Jan's Streaminglearningcenter.com.

General H.264

Wikipedia - it all starts with Wikipedia, but you probably knew that. Here you can find all you need to know about profiles, levels and entropy encoding (oh, my!).

The Future's So Bright: H.264 Year in Review. Before you recommend H.264 to a client, or for internal use, you need to know that H.264 comes with some baggage, in the form of royalties (yes, royalties). In fact, depending upon how you're currently deploying H.264 encoded video, you might already have triggered a royalty obligation. Read all about it here, as well as why H.264 adaption has been relatively slow among major broadcasters and corporations.

StreamingLearningCenter will be running two one-week streaming production courses to be taught by my friend Jan Ozer of streaminglearningcenter.com. The two hands-on courses, to be held at Stanford University in Palo Alto, CA (July 20-24) and Harvard in Boston, MA (July 27-31) and will cover streaming production from set design to encoding using equipment from vendors like Sony, Bogen and Photoflex, and production software from Adobe and Apple. Class sizes are limited to ensure active participation for all students.