It appears that when embedding Quicktime in a webpage, being viewed by Safari 4 in Snow Leopard, Quicktime no longer passes cookies to the server. So, if you’re having the Quicktime plugin load a file that uses cookie data to verify permissions, you’ll need to move to a query string model.
This only happens when Safari is running in 64bit mode, so I imagine it has to do with the “plugins running as separate entities” crash protection that Snow Leopard adds.
This does not appear to impact the Flash plugin.

I’ve been working on documenting the REST api that PCP2 uses for client server communication as part of a new project. I thought it might be useful to other folks. Consider this a work in progress – I’ve only documented the workflow for doing a multisource recording so far. Follow the job for the info.

Continue reading →

If all of this scheduled publishing stuff has worked, you’ll find a handful of posts about Podcast Producer 2 below.
I just took all of the notes I’ve collected while working on a PCP2 project over the last month or so, and wrote them up. It’s entirely possible that there are all sorts of things I’m missing, or misunderstanding. Now that the NDA is expired, hopefully some more folks will go public with their own discoveries.
So, if you’re coming across these posts and you know things I don’t about this strange world of ruby and media, please let me know in the commments!

If you try to use an Epiphan VGA2USB LR as a remote camera with Podcast Producer 2, you’ll quickly discover that the quality is awful – washed out and gross.
You’ll also find that, no matter how you modify your preferences, it still sucks.
The reason? The podcast agent isn’t running under your user, so the epiphan quicktime capture component never looks at your plist. In fact, it doesn’t even look in the /Library/Preferences folder. Instead, it loads the plist from:
/private/var/root/Library/Preferences
So, you need to tweak your settings the way you like them (for example, using the Epiphan application). Then, quit System Preferences. In terminal, head to your “/Users/yourusername/Library/Preferences/” folder and copy epiphan to the above path. You’ll probably have to use ‘sudo’ to do that. Restart your computer and marvel that your preferences are now being respected.

Podcast Producer 2 includes a great GUI for building workflows. But sometimes you’d like to be able to do things outside the workflow. For example, say you’ve tweaked your settings to output the video chapters to an XML – you might want to transfer that XML file to a remote server.
No problem – you can export a workflow from the GUI tool. This will give you a .pwf bundle on disk. If you drill down into that, you’ll find that most of the workflow lives within the “template.plist” file. For example, here’s the chunk I added to copy my chapter xml to a remote server:
<key>publish-plugin-filetransfer-2dad7a83f29809dceba9ef969b3ff774</key>
<dict>
<key>arguments</key>
<array>
<string>upload</string>
<string>–prb=$$GLOBAL::Library Bundle Path$$</string>
<string>–input=chapterize.xml</string>
<string>–url=$$ACCOUNT::F7E7978E-CB3B-4146-96A6-94007C60CBA7::URL$$</string>
<string>–destination_basename=$$Title$$-2dad7a83f29809dceba9ef969b3ff773-$$Recording UUID$$</string>
<string>–username=$$ACCOUNT::F7E7978E-CB3B-4146-96A6-94007C60CBA7::Username$$</string>
<string>–password=nope</string>
<string>–outfile=publish-plugin-filetransfer-2dad7a83f29809dceba9ef969b3ff774.yaml</string>
</array>
<key>command</key>
<string>/usr/bin/pcastaction</string>
<key>dependsOnTasks</key>
<array>
<string>edit-core-annotate</string>
</array>
</dict>
What you’ll find those is that podcast producer gets grumpy when you try and re-import that workflow. Why? Because your workflow bundles keeps a hash of itself, and knows when you’ve changed things.
Solution? Kill the “verifier” key within the accounts.plist file in your workflow. Then, all is well.

Podcast Producer (or, specifically, the “podcast capture” application) gives you a simple “good,” “better,” “best” set of options for selecting compression codecs.
If you’re on a machine with Apple Intermediate Codec installed (IE, any machine with iLife), the “best” preset will use AIC. That’s great in terms of CPU overhead, but not so great in terms of harddisk space.
Ideally, if you’re recording off a screen capture device, you want to record device native (say, 1024×768) with light H.264 compression. Luckily, there are a couple ways to modify the presets that podcast producer uses.
If you poke into the Podcast Capture plist:
/Library/Preferences/com.apple.PodcastProducerCompressionSettings.plist
you’ll find the settings living there. Three for screen, three for audio and three for video. Unfortunately, if you go changing that file willy-nilly, you’ll find your changes quickly reverted. The secret? Add:
<key>custom</key>
<true/>
your changes will stick.
That plist doens’t give you a ton of control over the size of the video. To adjust that, you can go one step up the chain and modify:
/System/Library/Frameworks/QTKit.framework/Versions/A/Resources/compressionPresets.plist
Within “PodcastProducerCompressionSettings.plist” you’ll see references to things like “QTCompressionOptionsPrivateH264Video” – that just points to entries within compressionPresets.plist.
You can look at the entries already in there to understand how the ‘sizeMode’ key relates to setting the width, etc. It may be possible to set that in the PodcastProducerCompressionSettings plist, but I haven’t had success.

The chapterize command has the option of outputting an XML in addition to (but not instead of) modifying the source quicktime. You can take advantage of this in cases where you’d like the raw chapter data, perhaps for creating your own thumbnail gallery.
Just add the -xml flag and specify a file. You can modify the:
/usr/lib/podcastproducer/actions/pip.rb
file to do this automatically, and then have your workflow take care of moving the files around. No need to specify a path, it’ll end up in the Content folder with the rest of your media. So, here’s what my pip.rb has ended up looking like, from line 125 to 139:
args = [ “/usr/libexec/podcastproducer/chapterize”,
“–input”,
chapterized_primary_input_path,
“–xml”,
“chapterize.xml”,
“–threshold”,
“10.0”,
“–tolerance”,
“3”,
“–reduce”,
“12”,
“–window”,
“0.3”
]
do_system(*args)

Podcast Producer 2 has a really neat tool to automatically create a chapter marker each time a slide is changed in a screen recording of a powerpoint or other presentation. It does that by detecting the change between images, with some boundaries.
The default settings are a bit too aggressive in my opinion – more than a few times I’ve ended up with hundreds of chapter markers in a presentation that only consisted of a few slides. Also, if you’re using an Epiphan screen recorder instead of the podcast producer screencapture tool, you’re likely to have additional noise in the feed which could confused it.
Luckily, you can override the default settings. Chapterization takes advantage of a tool called ‘chapterize’ that lives in /usr/libexec/podcastproducer/. What I’d suggest doing is creating a few sample recordings in your typical environment and then playing with chapterize switches to find the right combination.
Chapterize adds chapters to the movie itself, rather than creating a copy, so you’ll want to backup your file before running it. You can run the command directly to see all of the switches.
I’m working with 1024×768 screen recordings, and I found that bumping up the –reduce ratio number to 8 or 12 substantially reduces the false positives.
Once you’ve found the right combination of settings, you’ll want to modify /usr/lib/podcastproducer/actions/pip.rb, chapterize.rb and qtimport.rb – just search the file for chapterize, it should be pretty self explanatory.