Flowplayer and Podcast Producer 2: The Code

I’ve received quite a few comments about my previous post “Adding Flowplayer to Podcast Producer 2.” I’m pleasantly surprised by this feedback regarding my workaround to what is, in my opinion, a significant deficiency in Snow Leopard Server. I’ve responded to a couple of these commenters by direct e-mail, but perhaps it would be more efficient if I just shared the relevant code and provided some step-by-step directions.

Let me begin by speaking to this “significant deficiency in Snow Leopard Server.” As I said in my previous post: while there “might be valid reasons for Apple sticking with the Quicktime plugin rather than using a more modern-looking javascript player…I can’t think of any reasons that would excuse Apple from not providing its Snow Leopard Server customers with the option to make videos look as good as on Apple’s site.” I am still hopeful that Apple will come to the realization that they should share with their Server customers the javascript player code they use on their own site to present videos. It would be in their best interests to do so, especially given the recent comments by Steve Jobs that Adobe Flash is a “CPU Hog” and the source of 90% of Safari crashes. Committing Apple to standards-compliant HTML 5 is noble, and I agree that Flash deserves to be criticized. Flash does hog CPU cycles, and I’m a believer in the future of HTML 5.

But as a practical matter, Apple’s SL Server customers need to be able to deploy videos on the web NOW, and to be able to have those videos viewed by ordinary people using ordinary web browsers on ordinary computers…including the vast numbers of ordinary Windows computers out there. And the Quicktime plugin doesn’t cut it as a Flash player replacement. Isn’t that why Apple’s own web site uses javascript extensively to present videos without using Flash players? Apple doesn’t rely on the Quicktime plugin to present videos on its web site, so why do they sell a server product that uses the Quicktime plugin to present videos on the web? It isn’t for lack of javascript in SL Server: there’s oodles of it all over the pages produced by Wiki Server. And I suppose Apple could say you could roll your own javascript player to mimic what Apple does on their own web site, but why should we have to reinvent the wheel?

I suspect one reason why we don’t see the slick javascript used by Apple on its website integrated into Wiki Server is because Apple’s own web developers don’t talk much with the developers of Apple’s Server software. And that’s a shame. Steve Jobs, if you’re listening…could you get these two groups together for an afternoon of sharing? If you really want to wean the world off of Flash, why don’t you start by giving your server customers a real alternative to Flash—a full-featured javascript player—rather than relying on the Quicktime plugin in your server product?

Until Apple delivers a real alternative to a Flash player in their server product, here is my detailed description of the workaround I’ve developed. In essence, I have modified the javascript in Wiki Server so that videos are presented using Flowplayer (a very nice Flash player) rather than the Quicktime plugin. Here’s how I did it:

Step 1: Download Flowplayer from http://flowplayer.org/, and upload it to a directory on your web site. As I write this, a basic download of Flowplayer will include the files flowplayer-3.1.5.swf (the core flash player) and flowplayer.controls-3.1.5.swf (the core flash controller bar). It will also include (inside the example folder) the flowplayer-3.1.4.min.js file, which is some basic javascript you need to load into the pages where you want to use Flowplayer. (Technically, Flowplayer will work without this bit of javascript, but in most cases you will want to have this javascript loaded onto your pages so that you can use Flowplayer’s javascript API.) So in order to add this javascript reliably, I add a SCRIPT tag that references this file in a custom theme, which is the next step…

Step 2: Create a Wiki theme that includes a reference to the Flowplayer javascript. The easiest way to do this is to copy an existing theme and make changes to the copy. You’ll find these themes in /Library/Application Support/Apple/WikiServer/Themes/. I used the Snowleoplard theme as the basis for my custom theme. I opened a terminal window, changed to the theme directory, and used the ditto command as root to make an exact copy like this…


cd /Library/Application\ Support/Apple/WikiServer/Themes/
sudo ditto snowleopard.wikitheme/ customthemename.wikitheme/

Replace “customthemename” with a descriptive name of your choice (no spaces). In my case, I called my new theme “snowleopard-wcu.” If you have the “Wiki Server Administration” manual handy, you might want to refer to chapter 3 for more information about creating a custom theme. There you’ll see that an important step is to edit the theme.plist file so that your new custom theme can be selected in the wiki settings. At the very least, you’ll want to change the “display name” and “name” values to match your new theme. Here’s what my custom theme’s plist file looks like…


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>displayName</key>
<string>WCU Theme</string>
<key>name</key>
<string>com.apple.snowleopard-wcu</string>
<!--
<key>mobileHeaderColor</key>
<string>#3772bc</string>
-->
<key>commentSortDirection</key>
<string>DESC</string>
<key>version</key>
<string>2</string>
</dict>
</plist>

Now I need to add a line to the theme’s default.xsl file that inserts the Flowplayer javascript file. Below is the relevant portion of my default.xsl file (with the vertical ellipses indicating there is code above and below this snippet):

.
.
.
<xsl:template match="page">
<html lang="{context/locale}">
<head>
<script src="http://communication.wcupa.edu/flowplayer/flowplayer-3.1.4.min.js" language="JavaScript" type="text/javascript"></script>
<!-- meta tags -->
.
.
.

Of course, you’ll want the URL in the src attribute to point to where you’ve saved your flowplayer-3.1.4.min.js file (please don’t point to mine!). Now save the default.xsl file, and reboot the wiki server by issuing this command in a terminal window…

sudo serveradmin stop teams; sudo serveradmin start teams;

Alternatively, just issue the stop command, wait for confirmation, then issue the start command. Once the wiki (teams) service has restarted, go into a wiki that you want to change to the new theme. Login, click on settings, and click the “choose themes” button (on the Blog tab). If all went well, your new custom theme should be available in the list. Select it and click OK.

Now you have a theme that will include this all important little bit of Flowplayer javascript on every page. Wherever you want Flowplayer, use this theme. If it’s important that you have Flowplayer in all of your themes, I suppose you could make the changes I describe above to all of your themes. But keep in mind that Apple could overwrite the stock themes that come with SL Server in a software update. If you want to insure Flowplayer works even after a software update, I recommend that you use a custom theme.

Step 3: Edit the wiki.js and compressed_wiki.js files to use Flowplayer instead of the Quicktime plugin. These two files are essentially the same, although the compressed file isn’t formatted with a lot of spaces and indents. It’s a lot easier to edit the wiki.js file, and then just use your favorite text editor to do a search and replace to make the exact same changes in the compressed file.

First, make a backup of these files, just in case. Both of these files are located in usr->share->collaboration->javascript. Make a backup of the files using your favorite method (using ditto in the terminal or just copy using the finder). Put the backups in a safe place. I can’t stress this enough: save a backup of the original files in case you need to revert to them.

Next, open wiki.js in your favorite text editor (I use TextMate). We’re going to change the value of the variable objectHTML. Here is what this variable looks like before our edit…


var objectHTML = '<object classid="clsid:02BF25D5-8C17-4B23-BC80-D3488ABDDC6B" width="'+img.width+'" height="'+(img.height+(extendHeight?16:0))+'" codebase="http://www.apple.com/qtactivex/qtplugin.cab"><param name="SRC" value="/collaboration/fake.qti"><param name="QTSRC" value="'+fullSrc+'?sessionID='+server().sessionID+'"><param name="TYPE" value="video/quicktime"><param name="SCALE" value="aspect"><param name="AUTOPLAY" value="true"><param name="CONTROLLER" value="true"><param name="TARGET" value="myself"><param name="BGCOLOR" value="'+backgroundColor+'"></object>';
// Firefox wants only an embed tag, and it has to be written using innerHTML. Also, have to hide image *first*
if (MozillaFixes.isGecko) {
Element.hide(img);
embed.innerHTML = '<embed src="/collaboration/fake.qti" qtsrc="'+fullSrc+'?sessionID='+encodeURIComponent(server().sessionID)+'" type="video/quicktime" autoplay="true", controller="true" target="myself" bgcolor="'+backgroundColor+'" width="'+img.width+'" height="'+(img.height+(extendHeight?16:0))+'" pluginspage="http://www.apple.com/quicktime/download/" scale="aspect" />';
}

…and here is what this variable looks like after my edit…

var objectHTML = '<object width="'+img.width+'" height="'+(img.height+(extendHeight?16:0))+'" data="http://communication.wcupa.edu/flowplayer/flowplayer.commercial-3.1.4.swf" type="application/x-shockwave-flash"><param name="movie" value="http://communication.wcupa.edu/flowplayer/flowplayer.commercial-3.1.4.swf" /><param name="allowfullscreen" value="true" /><param name="allowscriptaccess" value="always" /><param name="flashvars" value=\'config={"plugins":{"controls":{"height":"16","backgroundColor":"#330033","timeColor":"#eeee99", "progressColor":"#cccc99","bufferColor":"#774477","sliderColor":"#777777","timeBgColor":"#222222"}},
"key":"#####","clip":{"url":"'+fullSrc+'?sessionID='+server().sessionID+'"}, "canvas":{"backgroundColor":"#550055"}}\' /></object>';
// Firefox wants only an embed tag, and it has to be written using innerHTML. Also, have to hide image *first*

if (MozillaFixes.isGecko) {
Element.hide(img);
embed.innerHTML = '<embed src="http://communication.wcupa.edu/flowplayer/flowplayer.commercial-3.1.4.swf" allowFullScreen="true" bgcolor="#333333" width="'+img.width+'" height="'+(img.height+(extendHeight?16:0))+'" align="middle" type="application/x-shockwave-flash" pluginspage=http://www.macromedia.com/go/getflashplayer" flashvars=\'config={"plugins":{"controls":{"height":"16","backgroundColor":"#330033","timeColor":"#eeee99", "progressColor":"#cccc99","bufferColor":"#774477","sliderColor":"#777777","timeBgColor":"#222222"}},
"key":"#####","clip":{"url":"'+fullSrc+'?sessionID='+server().sessionID+'"}, "canvas":{"backgroundColor":"#550055"}}\' />';
}

Note that you’ll want to change the src values to point to the URL of the location of the Flowplayer swf file that you’re using on your site. I’m using the commercial version on my site, although I’ve changed the key value in this post to just #####. I don’t think the Flowplayer folks would like me sharing my key value, and besides, I don’t think it would work outside of my domain anyway. If you’re not using the commercial version of Flowplayer, take out this key value. I’m not sure if all of the “flashvar” options I’ve set here will work in the same way with the noncommercial version, but I think most will, as I don’t think I’m doing anything too exotic. You might want to change the color values of the player to match the look of your site, and fiddle with the flashvars to taste.

Once you’ve changed the value of the objectHTML variable in wiki.js (and in compressed_wiki.js), I would suggest backing up these modified files, and saving them in a safe place. That way, if a software update ever overwrites these javascript files, you can easily copy back your modified files. Of course, I’m hoping that one of these days, a software update to SL Server will modify this variable so that it doesn’t use the Quicktime plugin, but until that day comes, you can use the method I’ve described here to use Flowplayer instead.

You may need to restart your server after making these changes. And you may need to study my code and the example code on Flowplayer.org to get Flowplayer looking just right on your site. But with patience and determination, you should be able to get Flowplayer running on your site without too much trouble.

I hope this helps those of you who commented on my previous posts, and anyone else in a similar situation who stumbles across this post. And if you discover any additional tweaks or insights into this process, please consider sharing in a comment.

Why iWant iPad

Apple has officially announced the iPad. And iWant one.

The iPad hasn’t even been officially released, and it’s already being panned by critics who just don’t get it. Moments after the iPad announcement, Fake Steve Jobs (Dan Lyons) called it “underwhelming.” Many see it as just a big iPod Touch or an “iPhone on steroids.” Others compare it to Tablet PCs, which have been largely unsuccessful. Some wonder if the iPad will be just a newer Newton, one of Apple’s biggest flops. There are those who are disappointed by the lack of a camera. Or the apparent inability to support Flash content. Or the big bezel around the 4:3 ratio display. Or the onscreen keyboard. Or a host of other nitpicking criticisms that, in my mind, miss the whole point of iPad.

And that point is best summed up by Jonathan Ive in the opening lines of the promotional video: “When something exceeds your ability to understand how it works, it sorta becomes magical. And that’s exactly what the iPad is.”

Yes, the whole point of the iPad is to be magical. Sure, one can already do much of what the iPad can do on a laptop or an iPhone or an iPod Touch. And many of the initial criticisms of the iPad have come from comparisons to other things that can do what the iPad can do.

But I don’t want an iPad because of what it can do. I want an iPad because of how it will do it. And from what I’ve seen, it does indeed look like magic. Understated elegance. Intuitive interface. Brilliant display. Screaming fast. Amazing price. Serious magic.

And iWant that magic.

I don’t want the iPad to replace my MacBook. Nor do I want it to replace my iPhone or iPod. And I don’t expect it to. Yes, I will probably use the iPad to read my email, keep my calendar, show off my photos, listen to my tunes, watch some videos, and surf the web. But I don’t want an iPad just to do those things. I want an iPad because I want to do those things (and more) in a new way, a fun way, even a magical way.

And iWant what could be the iPad’s killer app: iBooks and the iBooks Store. I’ve been holding off on getting a Kindle. I was really tempted to buy a Nook. But I’ll put down my money for an iPad, so I can read books in full color, on a bright, backlit screen. I know there are those who say it will be hard on the eyes, that monochrome e-ink displays are better. I don’t think so. I’ve spent some time with a friend’s Kindle, and I didn’t find it particularly easy on the eyes. If anything, I found it harder to adjust to an e-ink display after spending most of the day looking at a computer screen. Maybe my eyes are different. Or maybe I just don’t buy the argument that a black-and-white display is somehow better than one in full, glorious color. Go figure.

And even if my eyes do tire after an hour or two of reading iBooks on an iPad, at least I can do something else with it besides read books. A whole lot more than I could do with a Kindle, or a Nook. And for not a lot more money.

It would be nice if Apple gave an educational discount on the iPad. Apple typically does give a small price break to educators and students. It wouldn’t surprise me if they didn’t give one on the iPad, at least not at first. But I would be very surprised if Apple didn’t eventually have some kind of promotion to make the iPad even more affordable for the education market. Perhaps in their next “back to school” promotion, in time to get iPads in the hands of college students everywhere. Who knows? Maybe the iPad will even make reading textbooks fun again. OK, maybe reading textbooks was never fun. But I’ll take anything I can get that would help my students get more out of reading them.

So let the naysayers and critics write all the negative reviews they want. I’ve heard this kind of reaction to Apple products before. Some people have been calling the Mac a “toy” since the day it came out in 1984. Some people predicted the iPod would never catch on, and that the iTunes store would never be successful. Some people even thought the iPhone would be a flop. And some people today think the iPad will be a failure.

Some people never learn. If there’s one thing Apple can do, and do well, it’s create products that people want. And I firmly believe that people are going to want the iPad. Lots of people.

I know iWant one.

The Haiti Earthquake and Journalistic Choices

Yesterday, a tremendous earthquake struck Haiti, one of the poorest nations in the world. I’ve been thinking a lot about this tragedy in the last 24 hours, praying for the victims and survivors, and hoping that the relief effort will be swift, compassionate and comprehensive. As I write this, the extent of death and destruction is not yet clear. But from what I’ve heard from news reports, the Haiti Earthquake of January 2010 appears to be one of the worst natural disasters of this century, possibly even more devastating than the Indian Ocean Tsunami of December 2004.

I’ve also been observing how journalists, and especially broadcast journalists, have been covering this story. I first heard of the news on CNN. Wolf Blitzer broke the story during his “Situation Room” broadcast a few minutes after 5 p.m. My wife was watching CNN when the first announcement was made, and soon both of us were scanning the various news channels for updates. We checked out the Fox News Channel and MSNBC, but we kept coming back to CNN, since, for at least the first few hours after the earthquake, CNN had the most comprehensive and detailed reports.

Indeed, I was a bit shocked by how little attention this story received on Fox News Channel and MSNBC during the first few hours after the earthquake hit. CNN was covering the story nonstop from when the news broke shortly after 5 p.m. Fox had a brief “Fox News Alert” around 5:30 during the Glenn Beck show, but didn’t provide any extensive coverage of the story. MSNBC broke the story a bit later than Fox with an update during “Hardball.” But again, MSNBC, like FNC, didn’t give much more than a brief mention about the tragedy unfolding a few hundred miles southeast of Florida.

CNN did what a news channel should do when a big story like this hits: interrupt regular programming, stick with the story and provide as much information as you can to viewers. Both Fox News Channel and MSNBC instead relied mostly on their pre-recorded talk programs. On Fox News Channel, Bill O’Reilly interviewed Sarah Palin, who recently became a regular contributor to Fox News. The only mention of the Haiti Earthquake I noticed on FNC during the O’Reilly show was in the scrolling ticker at the bottom of the screen. Similarly, I didn’t hear Keith Olbermann mention the tragedy at all during his show on MSNBC. To her credit, Rachel Maddow did spend a significant part of her show covering the Haiti earthquake, but by then CNN had been covering it nonstop for nearly 4 hours.

I’m rather disappointed that the only cable news channel that stayed with this story from the beginning was CNN. I can understand why MSNBC might have a hard time covering breaking news, as they have the most limited news resources among the three major news channels. But one would think Fox News Channel could have broke away from their routine prime-time lineup to cover a story of this magnitude. While FNC might not have quite the same number of reporters in the field as does CNN, I think they could have pulled out the stops if they had wanted to do so. They certainly could afford to do so. Fox News Channel is watched by more people than CNN, and those higher ratings have helped swelled the bank accounts of Rupert Murdoch and the News Corporation, which owns Fox (as well as the Wall Street Journal and many other media properties).

So why didn’t Fox News Channel, the broadcast news flagship of a company called the “News” Corporation, break away from their pre-recorded prime-time lineup of commentary shows to provide breaking news coverage of the earthquake in Haiti? One can only assume this reflects contrasting “gatekeeping” philosophies, about what is newsworthy and what isn’t. Last night on Fox News Channel, Sarah Palin’s debut as an FNC contributor was news. Last night on CNN, the earthquake in Haiti was news. With all due respect to Ms. Palin, I think CNN made the better journalistic choice.

Adding Flowplayer to Podcast Producer 2

Today I had another breakthrough in my implementation of Podcast Producer 2, a core part of Snow Leopard Server. As noted in my previous posts, PP2 is “still a work in progress,” but it is also a vast improvement in many ways over my previous video transcoding system based on ffmpeg and Drupal. I’ve been consistently impressed with the quality of the videos produced by PP2, although the file sizes are a bit larger than what I squeezed out of ffmpeg. But one thing that hasn’t impressed me is the “plain vanilla” look and minimal functionality of videos presented using the Quicktime plugin.

I realize there might be valid reasons for Apple sticking with the Quicktime plugin rather than using a more modern-looking javascript player. But for the life of me, I can’t think of any reasons that would excuse Apple from not providing its Snow Leopard Server customers with the option to make videos look as good as on Apple’s site. Almost everywhere you look on Apple’s website, you see snazzy-looking Quicktime presented in cross-platform stable players, typically built in javascript. Even the new Quicktime player that is included with Snow Leopard client gives you a javascript option when exporting a video for the web. So why didn’t Apple provide a javascript player option with Podcast Producer 2? At the very least, Apple could have provided some configuration hooks to make it easier to do something other than present videos using the Quicktime plugin.

But where there’s a will…there’s got to be a way. And my “breakthrough” today was in finally finding that way. It isn’t using one of the various javascript players you can find on Apple’s site. Those aren’t at all well-documented, and trying to piece together something workable from the clues found in page sources is not my idea of a fun afternoon. No, the player I’m using to present the Quicktime videos produced by Podcast Producer 2 is Flowplayer, a really great little Flash-based player.

With my previous ffmpeg/Drupal system, I had been using a Flash-based player to present the videos: the venerable JW Player (now a product of Long Tail Video). But for a variety of reasons, I couldn’t get this player to work right with the m4v Quicktime files produced by the PP2 system. And the look of JW Player is getting a bit dated, although not nearly as dated as the look of the Quicktime plugin. Flowplayer, on the other hand, is modern-looking, clean and well-documented. The key to getting Flowplayer to work with PP2/Wiki server was finding just where to put the code…something that I mentioned at the end of my last post.

So today, after editing some code in the wiki.js and compressed_wiki.js files (both located in usr->share->collaboration->javascript), I now have Flowplayer injected instead of the Quicktime plugin whenever a user clicks on a thumbnail. The main edit was to the objectHTML variable (quoted in my previous post). In essence, instead of referencing the Quicktime plugin, I referenced the SWF player file included in Flowplayer, and passed to it the same parameters that had been going to the plugin. To keep things in line with the way the Quicktime plugin had been injected, I used the OBJECT method of inserting Flowplayer. To keep Firefox happy, I echoed this change using the EMBED method found in the embed.innerHTML variable in the code right below the objectHTML variable. I also tweaked the height adjustment, adding 24 pixels to video files and 8 pixels to audio files (using extendHeight?24:8) to accommodate the slightly higher control bar of Flowplayer. And to get the Flowplayer javascript file loaded, I added a call to this file in the head of the default.xsl file in the Wiki theme folder (and in the enclosed compressed folder). And that’s pretty much it.

Now videos on my site look so much better, with a decent looking control bar that I can customize to my heart’s content. Time indicators? Check. Slick color instead of boring monochrome? Check. Volume slider you actually notice? Check. Seek bar with time points? Check. Big bold play and replay buttons? Check. Options galore for tweaking things just right? Check.

It did take some effort to get my head around the code I needed to adjust in Apple’s javascript files. And yes, my changes will most likely be overwritten by a software update, so I’m being careful to backup my edits. But now that I understand where to make the changes, and how, I think I will continue to use Flowplayer instead of relying on the stock Quicktime plugin to present PP2-produced videos.

At least until Apple does the right thing and finally brings to their Server product a decent javascript player…like the ones that have been used for a long time on Apple’s own web sites.

Getting Podcast Producer 2 to Play Nice With Windows

In my last post, I wrote about my experiences with Podcast Producer 2: the good, the bad and the downright ugly. Well, I had a bit of a breakthrough today in getting Podcast Producer 2 to “play nice with Windows,” so I’m posting my “new and improved” workaround.

As I described earlier, the main problem is the way PP2 posts videos to user blogs maintained by Wiki Server (which is a core part of Snow Leopard server). The primary culprits are the width and height tags that are included in the IMG tag that is written to the blog entry. If the video files were of a small resolution, PP2 would typically write out height tags that were empty, which breaks Internet Explorer on Windows, since IE assumes an empty height tag means a height of zero. But even if the video files were at a larger resolution, PP2 would write out width tags that were narrower than the actual width of the video file, presumably to make the thumbnail smaller than the video. That breaks any browser on Windows, since the Quicktime plugin for Windows doesn’t seem to be able to scale videos to fit within the dimensions defined by smaller-than-actual width and height tags. It works fine on a Mac, since it appears that the Quicktime plugin for Mac can shrink videos to fit into whatever dimensions are defined in a web browser.

My workaround was to manually edit these entries, removing the width and height tags. This would make the thumbnails full size, the same size as the associated video files denoted in the ALT attribute of the IMG file (a rather non-standard use of the ALT attribute, but that’s another issue). This workaround was a lot of work: manually editing the HTML of each and every video file produced by my server had become a daily chore. In the last month, I had edited over 1,000 blog entries. But at least the videos would play on Windows.

I had originally thought I should be able to fix this by changing the code found in the “_podcast.html” file found in the WikiTemplates folder in Library->Application Support->Apple->WikiServer. After all, this file looks like the exact template used by PP2 when it posts to WikiServer. But even though I removed the width and height attributes from this template file, it had no effect on the blog entries posted by PP2. I have since found that these templates are not used by PP2; they are used by WikiServer itself. That is, when you go to a user blog, click the plus sign to manually add a blog entry, and select the option to add podcast content, the resulting code is drawn from the _podcast.html file in the WikiTemplates folder. So PP2 must be getting the code from somewhere else.

Today I found out where: in a line of code in /usr/lib/podcastproducer/actions/wikiserver.rb. Near the top of this file is the following line…

MOVIE_ERB_TEMPLATE = "<%= h($properties[\"Description\"]) %> <br> <br> <img src=\"<%= poster_image_url %>\" alt=\"<%= published_url %>\" width=\"<%= width %>\" height=\"<%= height %>\" class=\"aligncenter posterimg\" />"

Bingo. I just took out the width and height tags from this line and restarted the server. Now PP2 doesn’t write out the width and height tags when it posts video podcasts. And I no longer have to manually edit the posts produced by PP2 to enable them to work on Windows. Hallelujah.

While studying this file, I think I discovered what may be the reason why PP2 is mucking up the dimension attributes. Further in this file are these lines of code…

if width > 480
height = PcastQT.info(input_published_path, "height").to_i * 480 / width
width = 480.0
end

So if I understand this correctly, what this does is check if a video is wider than 480, and if so, force it to stay at a width of 480 and adjust the height downward proportionally. That is, if a video has standard “VGA” dimension of 640 wide by 480 high, this bit of code forces it to be 480 wide by 360 high (the original height 480 multiplied by 0.75, or 480/640). And again, this scaling of the thumbnail downward is what seems to be breaking the Quicktime plugin on Windows.

I’m still not sure why videos that are smaller that 480 wide are being posted by PP2 with an empty height attribute, but I have a theory. I notice that in this section of code that the width is explicitly defined by this line of code:

width = PcastQT.info(input_published_path, "width").to_i

But height is not explicitly defined UNLESS the “if width > 480″ is evaluated true. This could be why I’ve discovered that for smaller submitted videos (say at a resolution of 320 by 240) the code being posted by PP2 has an empty height attribute (specifically, height=””). But whether or not this theory is correct, I’m happy that I’ve discovered a fix. By removing the width and height attributes completely from the MOVIE_ERB_TEMPLATE line of code, I’ve effectively addressed both the empty height attribute problem and the scaled-down width attribute problem.

Of course, Apple is likely to rewrite this file with a software update. Here’s hoping they correct this problem, so that I don’t have to hack the same file in the future. But just in case, I’ve documented my fix here for my reference, and potentially for the benefit of others frustrated trying to get Podcast Producer 2 to play nice with Windows.

UPDATE: I think I’ve discovered where the code lives that swaps out the video file for the thumbnail when you click on it. It appears to be in the javascript file wiki.js at /usr/share/collaboration/javascript/wiki.js. Near the bottom of this file is an “expandMedia” function that’s part of the QTMediaExpander class. The “objectHTML” variable appears to contain the code that embeds the Quicktime object…

var objectHTML = '<object classid="clsid:02BF25D5-8C17-4B23-BC80-D3488ABDDC6B" width="'+img.width+'" height="'+(img.height+(extendHeight?16:0))+'" codebase="http://www.apple.com/qtactivex/qtplugin.cab"><param name="SRC" value="/collaboration/fake.qti"><param name="QTSRC" value="'+fullSrc+'?sessionID='+server().sessionID+'"><param name="TYPE" value="video/quicktime"><param name="SCALE" value="aspect"><param name="AUTOPLAY" value="true"><param name="CONTROLLER" value="true"><param name="TARGET" value="myself"><param name="BGCOLOR" value="'+backgroundColor+'"></object>'

I don’t think I should try to hack something here now, not with a PP2 server filled with 1200 videos and counting. But perhaps between semesters or over the summer break I’ll poke around here to see if I can’t get a prettier javascript Quicktime player instead of the plain vanilla Quicktime interface provided by the Quicktime plugin. Many people have requested a player that displays the elapsed time of the video, something I know is possible since Apple has such players on their own website (including here, for example).

Podcast Producer 2: Still a work in progress

I was eager to install Snow Leopard (SL) Server on the Mac OS X server I manage at work, primarily because of Podcast Producer 2 (PP2). This component of SL Server represents a major advance in functionality over the first version of Podcast Producer, which was introduced in Leopard Server. Unfortunately, after creating over 500 podcast episodes with PP2 so far, I’m convinced it’s still a work in progress. I’ve uncovered numerous little bugs that should have been caught in beta. I’ve reported these using Apple’s bug reporter (bugreport.apple.com), and so far I’ve heard back on exactly one of my bug reports with a terse message that it was a “known issue.”

Don’t get me wrong, I still think this is a great program. It’s much easier to configure and tweak than the first Podcast Producer, which was essentially unusable for my purposes. One great feature is the new Podcast Composer application, which makes it a breeze to create new workflows. The quality of the finished video podcasts is significantly better than what I was able to do previously with a combination of Drupal modules and the open source “Swiss Army Knife” of web video applications, ffmpeg. So all things considered, I think Podcast Producer 2 is worth the upgrade to Snow Leopard Server.

But I’ve discovered the hard way that it isn’t perfect, and some of the deficiencies are serious. I’m hopeful that Apple will soon release an update that addresses at least some of the issues I’ve identified. Until then, let me share a few of the annoying bugs I’ve found, and some of the workarounds I’ve discovered. I know from experience that when things go south, a webmaster’s best friend is Google, so perhaps some kindred webmaster will come across this blog entry and appreciate my documentation.

Earlier this month I documented three of these bugs with short videos that I posted to my MobileMe Gallery . If a picture is worth a thousand words, a video must be worth at least a few thousand more, so if you’re interested, I’d encourage you to check out these clips.

One of the biggest problems: PP2 doesn’t create episodes that reliably play back on Windows computers. This probably doesn’t come as a surprise; after all, this is a Mac program. But it’s a Mac Server program, and Mac Servers need to service Windows clients, so I would have hoped that this would have been better tested in beta.

Essentially, if you create a podcast from a video file using PP2, using a workflow that posts the podcast to the submitting user’s blog, the result is a blog entry that looks and works great on a Mac, but not on Windows computers with the latest Quicktime plugin installed. At first I thought this was an issue with Internet Explorer, and to some extent, the issues are greater with IE. But I believe the primary culprit is the Quicktime plugin, since I’m able to reproduce this bug with IE, Firefox and Safari for Windows. Yes, this bug even affects Apple’s own browser.

Thankfully, I’ve discovered a fix. The root of the problem seems to be the way that the podcasts are posted to the user’s blog. Rather than using an EMBED or OBJECT method, PP2 (and the SL Wiki Server that manages the blog service) links to the podcast via an ALT attribute to the IMG tag of the thumbnail, with a ROLE attribute added so that the thumbnail acts as a button for the video file. This is pretty slick coding, except for the fact that it doesn’t quite work right on Windows IF the HEIGHT or WIDTH attributes don’t match the dimensions of the video. And PP2 doesn’t insert the full HEIGHT or WIDTH attributes, presumably because the goal was to provide a thumbnail, not a full-size image. On a Mac, this is not a problem, as Quicktime on a Mac can play back fine within the scaled-down dimensions. But it’s a deal-breaker with the Quicktime plugin for Windows. If you click on one of these thumbnails on a Windows machine, the file loads, but you only hear the audio; no video appears. As best as I can tell, this is because the video doesn’t scale down to the dimensions provided in the IMG tag. Audio doesn’t have to scale so it comes through, but what’s the point of a video podcast if you can’t see the video?

The workaround is to delete the width and height attributes. While the result are full-size thumbnails, at least they work on Windows. Since I’m only deploying the iPod/iPhone resolution files (640 x 480), the thumbnails aren’t that huge. But it is a rather huge task to manually have to delete these width and height attributes. I would like to just delete this in the templates so that I didn’t have to do this every time a podcast is posted. And I can see where the templates are on the server. Unfortunately, editing the templates available in the Wiki Templates folder does not have an effect on the resulting code. Apparently, PP2 (or perhaps Wiki server) doesn’t read the contents of this templates folder when creating the pages. Perhaps there is some way to synchronize changes in the templates with the actual code produced (one would think there would be) but I’ve yet to discover it. If I find out, I’ll be sure to post an update. Until then, I’m manually editing the code of each podcast so that the majority of users who use Windows can actually see the videos.

It also would have been nice if the developers had included (or at least made available as an option) a Javascript player for the Quicktime videos posted to the user blogs by PP2. I find it interesting that nearly everywhere you see a Quicktime video on Apple’s own website, it’s presented in a Javascript player. Note only do such players look a heck of lot more “Web 2.0-like” than the standard OS 9 look of the Quicktime plugin, a more modern player might have alleviated the big problem of cross-platform playback. Indeed, one of my early efforts to develop a workaround for this problem was to present the videos using a Flash-based player (Dash Player by TMT Media). The Quicktime videos produced by PP2 will indeed playback quite nicely in an embedded Flash player (at least one that can handle MP4 files). But because making such a change would require extensively rewriting the code produced by PP2/Wiki Server, I eventually settled on the much easier (although still time-consuming) method of deleting the width and height attributes. I can understand why Apple wouldn’t include a Flash player with SL Server, but they could have at least put in a Javascript player.

Another small annoyance (and an almost humorous faux pas) is the fact that the “Subscribe in iTunes” link that is posted prominently on a podcast-enabled blog page doesn’t actually work. The workaround I’m using for that is to simply delete the button in the Theme files (which are honored by Wiki Server, at least if you’re careful to follow the rules carefully). For those users who want to subscribe to a podcast using iTunes, I send or post a link that does work, using an appropriate RSS feed from the Podcast Library (another nice addition to PP2).

One very serious bug I discovered has to do with overwriting files. I’ve always felt that one of the cardinal sins of programming is to create something that destroys data. But if you’re not careful, PP2/Wiki Server can do just that. It probably won’t happen very often, but given the volume on my server (between 500 and 1000 videos a month), it didn’t take long for me to find this bug. If a user submits a video with the same name as a video submitted earlier in the day, the older video is overwritten by the newer one. Actually, the older video still exists in the Podcast Library, just not in the podcast directory that is referenced in the code posted to the user blog. The workaround here is to manually edit the entry to point to the correct video in the Podcast Library. I’ve also taken some steps to try to enforce some naming conventions on PP2 users to help prevent this, although really, I shouldn’t have to do this. PP2/Wiki Server should be smart enough to not overwrite files, and I would hope Apple would squash this bug quickly, as it is genuinely serious.

Again, all things considered, I’m quite pleased with the advancements made with Podcast Producer 2. To be fair, most of the bugs I’ve found aren’t necessarily with PP2 per se, but rather reflect deficiencies in how PP2 works with Wiki server when writing podcasts to user blogs. My guess is that PP2 and Wiki Server (two very important components of SL Server) had largely separate developer teams working on them in Cupertino (or wherever the developers are located). Even so, one would hope the quality control teams at Apple would have tested this better before releasing it to the world. It would have been nice if “real world” users such as myself could have participated in the beta testing. As it is, I guess I am helping to beta test this product, since in some key areas, Podcast Producer 2 is still a work in progress.