Volume Number: 26
Issue Number: 01
Column Tag: Podcasting

Unlocking Podcast Producer v2: Under the Hood

Customizing and extending workflows

by Michele (Mike) Hjörleifsson

In the last article in this series, we took a the structure of a workflow in Podcast Composer, the new GUI tool in Snow Leopard creating workflows for Podcast Producer. Podcast Composer's export, publish and notification options will suite most administrators requirements, but its worth a review of what these are and what does an administrator do if they need to extend a workflow with other tools.

The default export options provide formats for iPod/iPhone, Apple TV, Computer, Audio Only, Mobile streaming and output to Compressor. The first five are accomplished using QuickTime X to transcode the video/audio into the appropriate format then hand them to the publishing stage. The Compressor option assumes that Compressor from Final Cut Studio is installed on the servers that will be doing the output and extends the number of types of transcoding an administrator can accomplish by leveraging the huge library of default Compressor output options as well as any plug-ins purchased from companies like TeleStream for output to Microsoft or Adobe Flash formats. Additionally utilizing Compressor allows administrators to leverage QMaster clustering technology to divide the transcoding operations to multiple computers running as QMaster agents. QMaster is included with Final Cut Studio (FCS) and does not require an additional license to be installed on any number of computers that form the cluster. With a single license of FCS and administrator can enable a large cluster of servers to handle these transcoding options.

Once the export stage is performed the output is handed to the publishing stage of the workflow where the podcast producer library receives the file by default (and is required for this stage), and the administrator has the additional options of sending notifications and/or export content to the Apple Wiki, File Transfer, Final Cut Server watch folder, a folder on the file system or even another workflow. Let's examine some of the options here.

The first option, Apple Wiki allows posting of content to the users default group wiki (default group is determined by Workgroup Manager or Active Directory), you must specify which user credentials are used to post the content. Which content type(s) to post (from the export types specified in the previous stage), or you can specify a custom blog or wiki to post to. For instance, if you have a blog called Daily Podcasts that has today's daily briefings you can post the podcasts directly to that blog versus the users blog or some other group wiki.

File transfer allows the administrator to pick the method that the exported item is being transmitted via: ftp, ftps, sftp, webdav or webdavs. This transfer can take place to another server on your network or across the world. As expected you would need to provide credentials appropriate to the service you select.

The next option allows you to export to a watch folder for Final Cut Server (FCS), where FCS will take the exported file and perform it's own workflow on that content, such as notifying editors, making a proxy copy of the content for laptop editing or any of a myriad of options supplied by FCS.

An administrator can also use the Folder publish option which simply drops the specified output(s) to a folder on a local or remote (must be previously mounted and accessible by all servers in the Podcast Producer cluster) file system for review or further processing. If you're experienced with Apple Script or Automator, you can attach additional actions to that folder that execute once content is placed there by Podcast Producer.

The last option allows you to create cascading workflows by submitting the output of one workflow to another workflow. Why would an administrator want to send content from one workflow to another? Well lets say you want all of your content archived onto a SAN in your data center, you can create a workflow that simply drops the files onto your SAN and then have all your other workflows call that as part of their workflow option. This would be more prevalent when administrators allow content publishers to create their own workflows but wants to standardize some of the output or notification options.

The next stage of the workflow, Notification allows the administrator to notify users and groups that the content is ready by email, iChat, iTunes Directory posting, iTunesU posting, or posting to a Web Service. Let's look at the options here:

Email Notification allows the workflow creator to specify whether to send the email notification to the Podcast Producer Administrator, the submitting user, both and or others. You will need to provide an email address and email server information so the service can facilitate delivery of the email. If you would like to change the format or design of the emails, you can. Please refer to the Podcast Administrator document located here:

http://images.apple.com/server/macosx/docs/Podcast_Producer_Admin_v10.6.pdf

iChat Notification allows the workflow creator to select the Podcast Producer Administrator, the submitting user, both and or others be notified by iChat. An iChat server id, password and the iChat message to send need to be specified.

iTunes Podcast Directory, this feature will post your podcast content to iTunes. For this notification to work, you must setup your feeds and be registered with iTunes. When this notification is sent to iTunes, the iTunes podcast repository syncs with your Podcast Library as soon as possible to reflect all changes.

The iTunesU feature is strictly for educational institutions that are setup with an iTunesU site(s). Simply specify the iTunes U site that you would like the workflow to update and that is all there is to it.

The Service setting allows the workflow creator to specify an external web service that is designed to accept publication notifications.

Podcast Composer provides a fairly comprehensive set of options for administrators to choose from, but what if your organization needs to take it a step further? For instance, what if your podcasts are actually testimonial depositions for a legal case and you need to digitally sign them to ensure their authenticity for potential court proceedings at a later time? What if you have to create some other format that isn't included as a QuickTime or Compressor option? Podcast workflows are simply an OS X bundle, similar to an application or other type of OS X bundle. So you can open the workflow's contents and examine and modify it, but before you go hacking away let's take a look at the bundle itself and the ramifications of editing one.

Create a new workflow with a few options in Podcast Composer and save it to your desktop. You must specify at least a few options for Podcast Composer to create the directories and files we are going to look at. Once created, Ctrl Click or right click and select Show Package contents to view the contents of the bundle. You will find a single folder labeled Contents. Open this folder and you will see 2 more items, Info.plist and a Resources folder. The Info.plist file contains an identifier for the bundle, its name, language, and other house keeping information including some unique identifier strings. While you could create a workflow totally from scratch the values in this file are somewhat of a pain to collect and may change with any OS X update, so it is preferable to create the majority of your workflow in Podcast Composer then edit a couple of files and locations. Opening the Resource folder exposes the items we are truly looking for.

As you can see in the screenshot there are several plist files and directories in the Resource folder. Primarily you will only modify a few items here. Namely, the template.plist and the Tools, Presets, Images, or Movies directories. The template.plist specifies the workflow tasks, dependencies and order of actions. This is where you would add any additional steps you require to perform during your podcast workflow, we will explore this in more detail in just a moment. The Images and Movies directories are where you would add any custom movie or image files your scripts or additional workflow tasks may need. You do not need to put leading or trailing videos in these directories, it's easier to specify those in Podcast Composer. Though you could easily change all your leading/trailing videos for all your workflows by writing a script to replace the old intro movie with a new intro movie in the Movie directory of all your workflows, of course you would need to ensure the permissions stay consistent. The Presets directory stores preset encoding to use for each of your selected export options, the defaults usually do the trick. The Compositions directory stores Quartz Composer compositions that are used in the workflow, typically the title introduction and movements of dual source videos. The Templates directory is used to hold any modified templates for your email, iChat or other notifications; by default this directory is empty and the standard system-wide templates will be used. Delving into the plist files in alphabetical order:

accounts.plist - doesn't seem to be used at this time but is designed to store credential information used by Podcast Composer.

configuration.plist - Stores the configurations of the Import, Edit, Export, Notify, and Publish stages of Podcast Composer.

sources.plist - Specifies the type of content processed by the workflow.

template.plist - Specifies the tasks to execute and the order of execution.

Extending your workflow to execute a predetermined script or other action is simply a matter of putting that script in the Tools directory and modifying the template.plist file to add the step for that script into the workflow. Opening the templates.plist file with Plist Editor (included as part of Xcode) reveals the contents and structure of the file as seen below.

Moving from top to bottom, there is the root of the plist file, then a dictionary named Item 0. Clicking the disclosure triangle to expose the contents of Item 0 exposes the heart of the plist file. The plist file is divided into four sections. artConditions, artSpecifications, taskSpecifications, and userRequirements. There are two additional items in the base of Item 0, name for the Xgrid job and notification email of an administrator.

The "art" prefixed files are used by Xgrid and should not be modified when creating a customized workflow. The userRequirements specify the required input from the user submitting the workflow and provide the default Title and Description though additional information could be required and added to this section.

The main section we are concerned with is the taskSpecifications, this is where the item-by-item execution of the workflow is read, prerequisites determined and then executed. The order of the items listed here serves as a graphical indicator of the order of execution though the prerequisites of each of the task items must be met prior to their execution or they will fail. Each task represents a UNIX shell script command and consists of the following elements:

arguments - Lists the arguments required by the command.

command - Specifies the command to run (including the path).

dependsOnTasks - (Optional) Lists the tasks that must be completed before this command runs.

So it's that easy: we just specify the command line of our script, arguments and any dependency on prior steps right? Wrong. There is one UNIX command called pcastaction that has been built to handle the majority of heavy lifting for the standard processing, export, and notifications options. So how do you specify a shell script, python, ruby or other command line executable that you want to use to customize your workflow? Enter pcastaction shell there is an argument you can pass to pcastaction called shell that specifies that you want to execute a shell command after which you can specify the arguments to send to that command like the filename to process etc. There are two-dozen or so replacement keys that can be specified to pass information to your script.Table 1 is a comprehensive list.

How would this work if we wanted to add a processing step to our workflow that executed a shell script called changeme.py to make some changes to our content? First place the changeme.py in the Tools directory and check to ensure its permissions follow the permissions of the balance of the directory. Second open the template.plist with Plist Editor, click the disclosure triangle on Root, click the disclosure triangle on Item 0 and click the disclosure triangle on taskSpecifications. Click on the word taskSpecification and a branching icon will appear to the right, click that to create a new branch (also called child) as seen here.

Change the entry's name from "New Item" to something more appropriate to your script, lets call that "generate-videoxml" for right now, change the type to "Dictionary" and drag it down to the bottom of the taskSpecification list (be careful not to drag it into the userRequirements branch.) Create 3 branches/children to your new generate-videoxml task item. Name the first one dependsOnTasks, the second one arguments and the third one command and set their types to Array, Array and String respectively. The processing is case sensitive so be aware of your case. So now we have a task with dependencies, arguments and command properties, lets edit these and enter some details for our workflow step.

Click the dependsonTasks and create a child/branch called Item 0 (the default name) of type string and put preflight in the value. This will tell Podcast Producer that this step requires the execution of the preflight step first. You can modify this to whatever step your workflow may require for your script to have the proper content as its input. Next, click on command and enter /usr/bin/pcastaction as the command's value. Now onto the heart of the matter, the arguments. Click on arguments and create 4 items of type string they will name themselves automatically as Item 0 à Item 3 which is fine for our purposes.

In Item 0, enter the value shell to tell Podcast producer that we will be executing a shell script, then in Item 1 enter the value $$Workflow Resource Path$$/Tools/changeme.py to tell Podcast producer where our script is actually located. Now you can add as many arguments you need to pass to your script as you deem necessary. The standard notation for the arguments is to preface them with a double hyphen (i.e. —description=$$Description$$ ). Your script will need to be able to parse these arguments and process them accordingly. Once you have completed your editing you can save your plist file. Now you have a workflow that executes a few steps set in Podcast Composer then your custom step. Unfortunately you can no longer open this workflow with Podcast Composer so you will have to manually verify and submit your new workflow.

Verifying the workflow is a fairly simple process, and will check the validity of your template.plist and the existence of the script specified but NOT that it will actually execute properly so some post install debugging may be needed and the Podcast Producer Application Error Log and /Library/Logs/pcastserverd/Diagnostic Reports/ are good areas to look at to trace your workflow's execution and success or failure. To verify your workflow zip up the workflow bundle. copy it to your server, unzip then execute

sudo pcastconfig -validate_workflow_at_path <Path to your workflow>

This will validate the xml formatting of template.plist and location any specified scripts. Once validated you can install the workflow by executing the pcast command:

sudo pcast -install_workflow -path <path to your workflow>

You will see some progress indications that your workflow has been copied up to the Podcast Producer service and installed. You may have to restart Podcast Producer from server admin or the command line:

sudo serveradmin stop pcastserverd
sudo serveradmin start pcastserverd

This will cause the workflow list to repopulate and your workflow will be available from the Podcast Capture application and web interface.

From the default configuration options available with Podcast Composer and the ability to add your own scripts to extend these workflows to anything your heart desires Podcast Producer provides a powerful media production streamlining and distribution tool for a myriad of uses from simple podcasting of lectures to complex multi-dimensional output. If your organization utilizes custom teleconferencing gear like Tandberg or other manufacturers you can, with a little work integrate these into your Podcast Producer workflow by examining the man pages for the various services and determining the appropriate method for submitting your content file to your custom workflow, the opportunities are endless. Well that is all for Podcast Producer for now, Till next time... Happy tech'ng.

Michele (Mike) Hjörleifsson has been programming Apple computers since the Apple II+, and implementing network and remote access security technologies since the early '90s. He has worked with the nation's largest corporations and government institutions. Mike is currently a certified Apple trainer and independent consultant. Feel free to contact him at mhjorleifsson@me.com